Comportamento inesperado na IA Cortex do Snowflake

1. Introdução

IA em todo lugar, mas a que custo?

A IA está se infiltrando em todos os cantos da tecnologia, desde chatbots em ferramentas de análise de negócios até modelos generativos que impulsionam a descoberta de dados. Essas inovações oferecem eficiências incríveis e crescimento empresarial próspero, mas também trazem armadilhas de segurança inexploradas. Um risco particularmente preocupante é a exposição inesperada de dados. Seja o M365 Co-Pilot, Snowflake Cortex AI ou qualquer outro serviço de IA, sua segurança é tão boa quanto as políticas de acesso que você configurou.

Neste post, examinaremos como o CORTEX Search Service da Snowflake, uma ferramenta de busca e recuperação de ponta impulsionada por IA, pode acabar expondo dados sensíveis dentro da sua base de usuários do Snowflake, mesmo em um ambiente seguro com políticas de acesso e mascaramento rigorosamente configuradas.

No final da postagem, explicamos como a Cyera pode ajudar a proteger contra esse problema. Se você precisar de mais ajuda, entre em contato conosco pelo e-mail support@cyera.com.

Queremos agradecer a toda a equipe da Snowflake por sua transparência, capacidade de resposta e colaboração durante todo o processo, realmente apreciamos seu apoio.

2. Caso de Uso: Uso Indevido da Pesquisa CORTEX para Mostrar Dados Sensíveis

2.1 Mascaramento dinâmico no Snowflake

Mascaramento dinâmico de dados é o método do Snowflake de restringir como os dados são apresentados, com base em quem está consultando. Normalmente, você define uma política de mascaramento em colunas sensíveis, assim:

• ADMIN função vê dados reais (val).
• Todos os outros veem dados mascarados (*****).

Isso é crucial para aderir aos requisitos de conformidade—por exemplo, proteger PII ou informações financeiras no momento da consulta sem duplicar dados.

2.2 O Serviço de Pesquisa CORTEX

O CORTEX Search da Snowflake foi projetado para oferecer suporte a casos de uso de busca difusa e RAG (Retrieval Augmented Generation) orientado por LLM.

Na prática:

• CORTEX é executado sob uma função com o privilégio CREATE CORTEX SEARCH SERVICE.
• Os usuários não precisam de privilégios SELECT diretos nas tabelas subjacentes.
• Um usuário pode consultar dados através do CORTEX SEARCH desde que tenha USAGE no serviço.

2.3 DIREITOS DOS CHAMADORES vs DIREITOS DOS PROPRIETÁRIOS

Um dos conceitos mais importantes em segurança de banco de dados é a diferença entre direitos do chamador e direitos do proprietário.

Direitos do chamador: O processo ou função é executado com os mesmos privilégios do usuário que o invoca. Se você tiver privilégios limitados, as capacidades da função serão igualmente limitadas.

Exemplo do Mundo Real: Pense em um usuário comum em uma ferramenta de colaboração que não pode ver uma pasta privada. Qualquer script que ele execute a partir de sua conta ainda não terá acesso a essa pasta privada—está vinculado aos direitos **dele**.

Direitos do proprietário: O processo ou função é executado com os privilégios do proprietário do objeto, independentemente de quem o chama. Se o proprietário tiver privilégios elevados ou de administrador, a função poderá fazer coisas que o próprio chamador normalmente não pode.

Exemplo do Mundo Real: Em alguns sistemas, como certas plataformas SaaS ou procedimentos armazenados avançados, um recurso é executado com as permissões de uma função privilegiada (como uma função de administrador). Mesmo que um usuário comum inicie a ação, o código é executado com o acesso elevado da função de serviço e pode ler ou gravar dados que o usuário normalmente não teria permissão para acessar.

Em muitos sistemas de banco de dados, os recursos são executados sob direitos do chamador para preservar o princípio do menor privilégio. No entanto, no cenário do CORTEX Search do Snowflake, assim como em outros recursos dentro do Snowflake, o código é executado sob os direitos do proprietário do serviço—frequentemente uma função poderosa como CORTEX_ROLE ou até mesmo ACCOUNTADMIN. Isso significa que qualquer pessoa que possa chamar o serviço herda os privilégios potencialmente de nível superior do proprietário durante essa execução. Quando usada adequadamente, a semântica de direitos do proprietário pode ser usada para facilitar a adesão ao princípio do menor privilégio, como no caso de procedimentos armazenados, onde o proprietário pode delegar tarefas administrativas específicas, como limpar dados antigos, para outra função (o chamador) sem conceder a essa função privilégios mais gerais, como privilégios para excluir todos os dados de uma tabela específica. Para o Cortex search, isso poderia ajudar a fornecer acesso a colunas selecionadas de uma tabela sem conceder acesso à tabela inteira.

Por Que Isso Importa:

• Se o CORTEX Search (ou qualquer serviço com estado) receber amplo acesso a dados (direitos de proprietário), então qualquer usuário que puder invocá-lo ganhará acesso de leitura semelhante ao proprietário que criou o índice. Mesmo que não tenham privilégio SELECT direto em uma tabela, eles podem recuperar dados sem máscara porque a consulta é executada como o proprietário.
• Por outro lado, se um serviço usasse os direitos dos chamadores, ele retornaria apenas os dados que o usuário real tem permissão para ver, mantendo o mascaramento dinâmico e os controles de acesso intactos.

Portanto, como o CORTEX Search usa direitos de proprietários, ele efetivamente "empresta" todos os privilégios da função sob a qual está sendo executado, potencialmente permitindo que um usuário com menos privilégios tenha acesso de leitura aos dados indexados. O uso desse recurso por um administrador que não esteja familiarizado com esses detalhes pode resultar em divulgação não intencional de informações dentro da conta Snowflake da empresa.

3. Detalhamento Técnico

Etapa 1: Criando o serviço de pesquisa CORTEX com AccountAdmin

Você, como accountadmin, configura o Serviço de Pesquisa CORTEX para permitir que analyst_user consulte a tabela salary_info. O serviço é inicializado com a função accountadmin, que tem acesso total a todos os dados no ambiente.

Visual 1: Vídeo de Criação do Serviço CORTEX com AccountAdmin

Etapa 2: Concedendo permissões ao analyst_user

Em seguida, você concede ao analyst_user as permissões necessárias para usar o CORTEX Search Service.

Visual 2: Foto de Concessões Concedidas para analyst_user

Neste ponto, tudo parece estar bem. No entanto, o accountadmin pode estar com a impressão incorreta de que o analyst_user pode usar o CORTEX Search Service para interagir com a tabela usando suas próprias permissões (analyst_user).

Etapa 3: Explorando a configuração

Agora, analyst_user tenta consultar a tabela salary_info diretamente,

Como esperado, esses dados retornam mascarados.

Mas então, analyst_user tenta outra coisa—eles usam o CORTEX Search Service para consultar a mesma tabela:

‍DEMO COMPLETA

Demonstração completa mostrando todo o progresso desde a criação do serviço de pesquisa cortex até seu uso e contorno da política de mascaramento

4. Solução: Impedir que a IA ultrapasse seus limites

No entanto, os administradores de conta do Snowflake podem evitar essa classe de comportamento.

Para Usuários do Snowflake (Você):

✅ Não implante o CORTEX Search com funções altamente privilegiadas como ACCOUNTADMIN, a menos que você pretenda conceder seus direitos aos usuários do CORTEX search. Use uma função de serviço com privilégios mínimos com apenas o acesso SELECT mínimo necessário.

✅ Isole tabelas sensíveis de serviços de pesquisa de uso geral. Se uma tabela tiver políticas de mascaramento ou dados relevantes para conformidade, não indexe as colunas com esses dados sensíveis em um serviço Cortex Search.

✅ Tenha cuidado com concessões de USAGE no Cortex Search Service - se você for o proprietário, qualquer função à qual você conceder USAGE no serviço poderá acessar todo o seu conteúdo materializado

✅ Auditar o uso de funções: Verifique periodicamente qual função foi usada para criar cada Serviço de Pesquisa CORTEX. Se o criador tinha acesso total a tabelas confidenciais, considere revogar ou reconstruir o serviço.

Conclusão: Serviços de IA como o CORTEX Search, se mal configurados, podem resultar em divulgação não intencional de informações. Sem um escopo cuidadoso, eles podem permitir que usuários com poucos privilégios atravessem silenciosamente as barreiras de mascaramento e recuperem dados sensíveis, sem necessidade de permissão SELECT.

O princípio do menor privilégio deve ser aplicado à IA, já que a IA não apenas vê seus dados, ela fala.

5. Conclusão: Os serviços de IA não estão acima dos controles de acesso

CORTEX Search é uma ferramenta poderosa impulsionada por IA que traz pesquisa em linguagem natural para dados corporativos não estruturados. No entanto, esse poder deve ser usado com responsabilidade. Como demonstrado, o CORTEX Search é executado com direitos de proprietários, não de chamadores, o que significa que ele executa consultas usando as permissões da função privilegiada que criou o serviço, não do usuário que o está chamando.

Neste caso, os resultados esperados e as capacidades do mecanismo de mascaramento dinâmico do Snowflake podem não ser realizados. Uma coluna mascarada só é mascarada quando o controle de acesso é aplicado. Se configurado incorretamente, o CORTEX pode permitir que um usuário contorne o SELECT e ainda veja valores em texto simples.

Na prática, a IA pode se tornar um canal não intencional para expor dados dentro de uma organização. É por isso que a Cyera é importante: ela ajuda você a descobrir, classificar e proteger automaticamente dados confidenciais armazenados em seu ambiente. Em vez de adivinhar ou gastar horas fazendo uma triagem manual, você saberá exatamente o que está lá, quão sensível é e se está em risco.

Divulgação Responsável e Resposta do Fornecedor

Este problema foi divulgado de forma responsável à equipe da Snowflake, que respondeu prontamente e profissionalmente. Em colaboração com suas equipes de segurança e produto, mitigações iniciais já foram implementadas na forma de atualizações na documentação do CORTEX Search Service para esclarecer as implicações dos direitos executados pelo proprietário. Melhorias adicionais estão em andamento, incluindo a oferta de contexto de execução com direitos do chamador para casos de uso específicos da Snowflake e avisos aprimorados na interface do usuário para administradores, a fim de evitar configurações incorretas não intencionais. Agradecemos o engajamento da Snowflake e seu compromisso em fortalecer a postura de segurança da plataforma.

A Cyera está pronta para ajudá-lo a proteger seus dados com DSPM e DLP. Comece hoje mesmo com uma demonstração.