Campanha de roubo de credenciais do Snowflake e os limites da responsabilidade compartilhada

Resumo

• Limite confirmado da campanha:A Mandiant atribuiu uma campanha com motivação financeira à UNC5537 e afirmou que todo incidente da campanha que tratou diretamente teve origem em credenciais de clientes comprometidas. Não encontrou evidências de que o acesso não autorizado a clientes tenha surgido de uma violação do ambiente empresarial do Snowflake. O Snowflake também afirmou que não encontrou evidências de vulnerabilidade, má configuração ou violação de sua plataforma que causasse a atividade.
• Cadeia de controle observada:As contas bem-sucedidas não possuíam autenticação multifator, mantinham credenciais expostas em registros históricos de infostealer e não possuíam listas de permissão de rede. Os atacantes usaram então clientes suportados do Snowflake e operações SQL para enumerar dados, prepará-los, compactá-los e baixá-los. Aproximadamente 165 organizações foram notificadas como potencialmente expostas; isso não é uma contagem de violações confirmadas, pessoas ou registros.
• Conclusão de responsabilidade compartilhada:Os clientes controlavam seus usuários, funções, rotação de senhas, ativação de MFA, políticas de rede, higiene de endpoints e minimização de dados. O Snowflake controlava quais proteções existiam, como eram apresentadas e padronizadas, quais sinais entre clientes a plataforma podia ver e com que rapidez os avisos e o comportamento básico mais forte alcançavam a base instalada. Essas responsabilidades são concorrentes, não mutuamente exclusivas.
• Conclusão de soberania:Escolher uma região do Snowflake determina onde o armazenamento e a computação da conta estão localizados; a documentação do Snowflake afirma expressamente que isso não limita o acesso do usuário. Nesta campanha, uma identidade válida podia transformar um conjunto de dados armazenado regionalmente em uma cópia baixada. A localidade dos dados sem controles de identidade, saída e evidência é uma decisão de posicionamento, não um controle de soberania completo.

A plataforma não foi comprovadamente violada, mas a relação de serviço foi testada

A primeira disciplina neste caso é o vocabulário. A instância de um cliente do Snowflake não era a mesma coisa que o ambiente empresarial do próprio Snowflake ou a plataforma de produção compartilhada. Uma pessoa com credenciais válidas podia entrar na conta de um cliente sem cruzar para outro inquilino, explorar uma vulnerabilidade de software, obter uma conta de administrador do provedor ou quebrar a infraestrutura que separava os clientes. As evidências públicas apoiam o comprometimento de contas de clientes. Não apoiam um comprometimento técnico abrangente da plataforma.

Orelatório da campanha UNC5537da Mandiant é incomumente direto nesse ponto. Para cada incidente associado à campanha que a própria Mandiant tratou, a causa raiz foi credenciais de clientes comprometidas. Sua investigação não encontrou evidências de que o acesso não autorizado a contas de clientes tenha decorrido de uma violação do ambiente empresarial do Snowflake. O próprioaviso de investigação e endurecimentodo Snowflake também separou as contas de clientes visadas da plataforma de produção e forneceu consultas e indicadores para os clientes investigarem seus próprios ambientes. A CISA amplificou essa orientação em umalerta de 3 de junho de 2024.

Essa constatação negativa é importante. Chamar o evento de violação da plataforma do Snowflake pode implicar que um defeito no código compartilhado ou na infraestrutura abriu todos os inquilinos, ou que o Snowflake perdeu uma credencial mestra que desbloqueou os clientes. O registro analisado não estabelece nenhuma das duas coisas. Também obscureceria as ações que os clientes precisavam tomar imediatamente: identificar usuários apenas com senha, rotacionar credenciais, inspecionar histórico de login e consulta, restringir redes, reduzir privilégios de função e preservar evidências.

O erro oposto é tratar a ausência de uma violação da plataforma como ausência de uma questão de responsabilidade do provedor. Um serviço de nuvem não é meramente um disco neutro no qual um cliente coloca bits. O Snowflake construiu e executou os endpoints de autenticação que aceitaram as credenciais, as interfaces que os atacantes usaram, o mecanismo de consulta que processou seus comandos, a telemetria que registrou as sessões e os controles do produto que poderiam ter exigido um segundo fator ou restringido a origem da rede. O Snowflake também tinha visibilidade entre clientes que nenhum cliente individual possuía.

O fato de um controle decisivo ser configurável pelo cliente determina quem tinha o dever operacional de configurá-lo. Não responde se os padrões, avisos, detecção e aplicação do provedor eram proporcionais à concentração de dados em seu serviço.

O Formulário 10-K do ano fiscal de 2025 do Snowflake formaliza sua posição. Diz que o Snowflake é responsável pela segurança da plataforma e da infraestrutura de nuvem subjacente, enquanto os clientes selecionam e configuram controles para seus ambientes. Atribui o acesso de maio de 2024 à falha dos clientes em cumprir obrigações como MFA e políticas de rede, enquanto registra processos judiciais, investigações regulatórias, consultas de legisladores, danos à reputação e a possibilidade de disputas de indenização. Essa é uma evidência material da empresa sobre o modelo declarado e a exposição comercial do Snowflake.

Não é uma adjudicação independente de que toda responsabilidade ou reivindicação legal pertence ao lado do cliente.

Portanto, a questão útil é mais restrita do que "Quem foi violado?" e mais ampla do que "De quem foi a senha roubada?" É: em cada etapa, desde o segredo roubado até os dados baixados, qual ator poderia prevenir, detectar, interromper, reconstruir ou alertar sobre a ação? A responsabilidade segue o controle sobre essas etapas.

A campanha uniu roubo antigo de endpoint à autoridade atual da nuvem

A Mandiant obteve pela primeira vez inteligência de ameaças em abril de 2024 sobre registros de banco de dados posteriormente rastreados até a instância Snowflake de uma vítima. Essa vítima contratou a Mandiant, que concluiu que o intruso usou credenciais previamente roubadas por malware infostealer. A conta relevante não tinha MFA ativado. Em 22 de maio, após identificar inteligência apontando para uma campanha mais ampla, a Mandiant contatou o Snowflake e começou a notificar potenciais vítimas. O Snowflake publicou orientações de detecção e endurecimento para clientes em 30 de maio.

No relatório de junho, a Mandiant e o Snowflake haviam notificado aproximadamente 165 organizações que estavam potencialmente expostas.

Cada termo nessa última frase precisa de proteção contra inflação. "Aproximadamente" marca uma estimativa. "Potencialmente expostas" descreve uma população notificada, não 165 conclusões forenses completas. "Organizações" não significa contas, bancos de dados, pessoas ou registros. Algumas organizações podem operar várias contas Snowflake, e uma conta pode conter dados sobre uma população muito maior. O relatório não fornece um total da campanha de organizações confirmadas, indivíduos afetados, bytes exportados ou pagamentos de extorsão.

O histórico de credenciais explica por que um login em nuvem em 2024 poderia começar com uma infecção de endpoint anos antes. A Mandiant descobriu que a maioria das credenciais usadas pela UNC5537 estava presente em saídas históricas de infostealer, com a infecção associada mais antiga observada em novembro de 2020. Pelo menos 79,7% das contas utilizadas pelo ator tinham exposição prévia de credenciais. Essa porcentagem se aplica às contas usadas pelo ator na campanha analisada, não a todos os clientes Snowflake ou às 165 organizações notificadas.

Três condições repetidamente transformaram segredos expostos em acesso funcional. As contas impactadas não estavam configuradas com MFA. Senhas encontradas em registros de infostealer permaneceram válidas, às vezes por anos. As instâncias de clientes afetadas não possuíam listas de permissão de rede que restringiriam conexões a origens confiáveis. Nenhuma dessas condições é uma exploração nova.

Juntas, formaram um caminho de autorização durável: saber o localizador da conta, nome de usuário e senha ainda válida; conectar-se a partir de um sistema controlado pelo atacante; receber uma sessão; herdar a função atribuída; consultar o que essa função puder ler.

A dimensão do endpoint também era mais distribuída do que uma narrativa convencional de laptop de funcionário sugere. Em várias investigações, a Mandiant encontrou a infecção anterior por infostealer em sistemas de contratantes que também eram usados para atividades pessoais, incluindo jogos ou downloads piratas. Um dispositivo de contratante pode estar fora da frota de endpoints gerenciados do cliente enquanto carrega credenciais para vários clientes. Também pode conter uma conta administrativa porque contratantes especializados são frequentemente contratados para construir ou operar plataformas de dados.

O cliente que criou o usuário continua responsável pela identidade e seus privilégios, mas a exposição pode ser invisível para as ferramentas de endpoint do próprio cliente.

Este é um multiplicador de dependência de nuvem. A credencial é roubada de um endpoint, talvez fora da frota do Snowflake ou do proprietário dos dados. A credencial é aceita por um serviço global. A função pode alcançar um armazém consolidado contendo anos de registros de vários sistemas de negócios. O atacante não precisa mais comprometer esses sistemas de origem um por um. O valor analítico que tornou o armazém útil para o cliente também tornou o acesso bem-sucedido valioso para um ator de extorsão.

Os atacantes têm responsabilidade direta por roubar, comprar, testar e usar credenciais; entrar em ambientes de clientes sem autorização; levar dados; e tentar venda ou extorsão. Descrever as falhas de controle que tornaram esses crimes possíveis não dilui essa responsabilidade. Explica por que a mesma técnica criminosa teve sucesso em escala e onde a recorrência pode ser reduzida.

Recursos suportados se tornaram um caminho de exfiltração

A campanha não parou na autenticação. A Mandiant observou acesso através do Snowsight, SnowSQL, drivers e ferramentas de banco de dados. O ator listou usuários, funções, sessões, nomes de organizações, bancos de dados, esquemas e tabelas. Usou operações SQL familiares para selecionar dados, criar estágios temporários, copiar saída de consulta em arquivos compactados e recuperar esses arquivos para uma máquina local. Em várias instâncias, comandos semelhantes apareceram em diferentes ambientes de clientes.

Essa sequência torna o incidente legível como funcionalidade comum usada sob identidade não autorizada:

1. Um nome de usuário e senha válidos do cliente estabeleceram uma sessão.
2. A sessão herdou funções e privilégios de objeto atribuídos pelo cliente.
3. Reconhecimento identificou tabelas valiosas e estágios disponíveis.
4. Consultas selecionaram registros que a função tinha permissão para ler.
5. Estágios temporários eCOPY INTOconverteram resultados em arquivos baixáveis.
6. GETmoveu arquivos para um cliente controlado pelo atacante.

Nenhum passo nessa cadeia exigiu que o banco de dados funcionasse mal. É por isso que a criptografia em repouso, embora necessária, não foi o controle decisivo. Adocumentação de criptografia de ponta a pontado Snowflake diz que os dados do cliente são criptografados em repouso e sob TLS em trânsito, mas também explica que o Snowflake descriptografa os dados enquanto transformações ou operações de tabela são realizadas e permite que os usuários descarreguem e baixem resultados. A criptografia protege arquivos e transporte de partes que não têm autorização ou chaves. Não impede que uma identidade aceita com uma função permitida peça ao serviço para retornar resultados legíveis.

O mesmo princípio se aplica a chaves gerenciadas pelo cliente. O controle de chaves pode abordar cenários de provedor, armazenamento e revogação, mas uma conta em execução deve usar sua hierarquia de chaves para atender consultas autorizadas. A menos que uma política de chaves esteja conectada a uma decisão separada que rejeite a sessão ou operação, o banco de dados não pode distinguir o proprietário da conta de um intruso que satisfez a política de autenticação configurada pelo proprietário.

Portanto, o design de funções controlava o raio após o login. O atualmodelo de controle de acessodo Snowflake suporta controle de acesso baseado em funções e discricionário, propriedade, hierarquia de funções e privilégios de objeto. Uma credencial atribuída apenas a um banco de dados ou visão estreita apresenta uma consequência diferente de uma que possuiACCOUNTADMIN, amplo uso de armazém ou acesso de seleção em conjuntos de dados brutos. Uma conta de serviço usada por uma integração não deve herdar o alcance exploratório de um administrador humano. A função temporária de um contratante deve expirar com o engajamento, em vez de permanecer dormente com uma senha válida.

Políticas de proteção de dados podem restringir o resultado mesmo quando uma função é comprometida. Adocumentação de classificação de dados sensíveisdo Snowflake conecta a descoberta de colunas pessoais e sensíveis com políticas de mascaramento e acesso a linhas. Essa é uma descrição de capacidade atual, não uma evidência de que todo cliente afetado classificou ou mascarou seus dados em 2024. Estabelece a questão de design: o cliente expôs tabelas históricas completas a identidades que precisavam apenas de agregados, partições recentes, campos tokenizados ou visões aprovadas?

A exportação é em si uma função de negócio privilegiada e deve ser governada como tal. Um data warehouse frequentemente precisa de descarregamentos em massa para pipelines legítimos, backups, treinamento de modelos e sistemas a jusante. Uma proibição geral raramente é realista. Mas criar um estágio, descarregar um resultado extraordinariamente grande ou usar um cliente e origem de rede desconhecidos deve ser observável e, para conjuntos de dados de alto risco, pode justificar aprovação, limites de taxa, restrições de destino, elevação de curta duração ou uma função de exportação separada.

Os comandos da campanha eram normais o suficiente para serem executados, mas incomuns o suficiente no contexto para merecer uma decisão rápida de segurança.

O cliente possuía a configuração; o Snowflake possuía a linha de base

MFA é o teste de responsabilidade compartilhada mais nítido porque ambos os lados podem afirmar um fato verdadeiro. O administrador do cliente podia e esperava-se que ativasse o MFA. O Snowflake oferecia MFA desde 2015 e políticas de rede desde 2016. Ao mesmo tempo, as contas bem-sucedidas em 2024 foram capazes de autenticar sem MFA, o que significa que a linha de base efetiva do serviço permitia um caminho apenas com senha para essas contas.

A diferença entre disponibilidade e aplicação não é semântica. Um recurso de segurança pode ser gratuito, documentado, recomendado e ainda assim ausente nas sessões que importam. Os administradores enfrentam integrações antigas, usuários de serviço não interativos, contratantes, contas de emergência, vários clientes e medo de bloqueio. Essas restrições explicam o atrito de adoção; não justificam deixar o acesso humano privilegiado dependente de uma senha reutilizável. Elas também fornecem ao provedor informações necessárias para construir ferramentas de migração, separar identidades humanas e de serviço e tornar as exceções explícitas.

Após a campanha, a direção pública do Snowflake mudou de recomendação para padrões mais fortes. Seuanúncio de compromisso Secure by Designde julho de 2024 enfatizou controles de política de MFA e verificações do Trust Center. Em setembro de 2024, o Snowflake disse queo MFA seria aplicado por padrãopara usuários humanos em contas criadas a partir de outubro de 2024, recomendando SSO com MFA do provedor de identidade para humanos e autenticação por chave OAuth ou par de chaves para serviços. A distinção entre contas novas e existentes é importante. Um padrão seguro protege futuras criações; não aposenta automaticamente todo caminho de senha herdado na base instalada.

O Snowflake posteriormente introduziu oLeaked Password Protection, que usa feeds de inteligência de ameaças para testar senhas vazadas relatadas em um processo que preserva a privacidade e desativa uma senha quando confirmada como ainda válida. Esse controle do lado do provedor aborda diretamente uma das vantagens da UNC5537: credenciais antigas de infostealer que permaneciam utilizáveis. Também é evidência de que a responsabilidade compartilhada pode evoluir. Os clientes ainda precisam gerenciar identidades e rotações, mas o provedor pode usar inteligência entre serviços para fazer uma senha roubada parar de funcionar antes que cada cliente a encontre independentemente.

Adocumentação atual de política de autenticaçãopermite que os administradores controlem métodos e clientes permitidos e exijam MFA no nível da conta ou do usuário. Também alerta que restrições de tipo de cliente são de melhor esforço e não devem ser a única fronteira de segurança. Aorientação atual de par de chavesdá aos usuários de serviço uma alternativa a senhas estáticas. Essas páginas descrevem capacidades disponíveis até 2026; não devem ser lidas de forma retroativa como prova das características exatas, padrões ou estado de aplicação para todo cliente em abril de 2024.

Os padrões ajudam a explicar por que os padrões do provedor pertencem à análise. Aorientação atual de autenticação e gerenciamento de autenticadoresdo NIST trata as senhas como não resistentes a repetição e define resistência a phishing como uma propriedade de protocolo que não depende da vigilância do usuário. Ocompromisso Secure by Designda CISA de 2024 identifica especificamente MFA padrão, estímulos persistentes do produto, suporte básico de SSO e publicação de métricas de adoção como maneiras pelas quais os fabricantes de software podem aumentar mensuravelmente o uso de MFA. O Snowflake assinou esse compromisso voluntário após a campanha. O compromisso não é um veredito legal sobre o design do Snowflake em 2024, mas rejeita a ideia de que oferecer uma caixa de seleção esgota o papel do provedor.

A linha de base responsável distingue tipos de identidade. Administradores humanos devem usar MFA resistente a phishing ou uma identidade federada fortemente governada. Cargas de trabalho de serviço devem usar credenciais de trabalho que podem ser escopadas, rotacionadas e atribuídas sem fingir que um robô pode responder a uma notificação push. O acesso de emergência deve ser raro, monitorado, limitado no tempo e testado. Identidades de contratantes devem ter um proprietário, expiração, postura de dispositivo aprovada e nenhum reúso de credenciais entre clientes.

Toda exceção deve aparecer em um painel cujo denominador são todas as identidades, não apenas funcionários ativos.

A política de rede foi um segundo portão, não um substituto para a identidade

O terceiro fator recorrente da Mandiant foi a ausência de listas de permissão de rede. Uma credencial válida podia, portanto, ser usada a partir de infraestrutura que não tinha razão comercial para alcançar o armazém do cliente. Restrições de rede não reparariam uma senha roubada, mas poderiam tornar essa senha insuficiente a partir de uma origem não confiável.

Adocumentação atual de política de rededo Snowflake torna o padrão explícito: sem política, os usuários podem se conectar de qualquer computador ou dispositivo. Os clientes podem permitir ou bloquear faixas de IP e endpoints privados, aplicar controles no nível da conta ou do usuário e restringir o acesso a estágios internos com configuração adicional. Conectividade privada e controles de acesso público podem endurecer ainda mais contas de alta sensibilidade.

O cliente conhece seus escritórios aprovados, cargas de trabalho em nuvem, VPNs, contratantes e endpoints de integração, portanto o cliente deve definir a lista de permissões utilizável. O Snowflake não pode inferir toda origem legítima sem interromper os negócios. No entanto, o provedor controla a acessibilidade padrão, a sintaxe da política, a capacidade de simular uma mudança, proteção contra bloqueio, registro e se um administrador é avisado quando nenhuma política de conta existe.

Uma plataforma pode preservar a escolha do cliente enquanto torna o acesso público irrestrito uma exceção visível e limitada no tempo, em vez de um estado estável silencioso.

As regras de rede também têm limites. Os atacantes podem obter uma sessão de um dispositivo de contratante aprovado, rotear através de uma VPN corporativa permitida, comprometer uma carga de trabalho dentro da nuvem permitida ou roubar um token após a autenticação. Grandes empresas podem ter endereços de saída variáveis que tornam listas estáticas difíceis. A conectividade privada pode excluir ferramentas SaaS que não a suportam. Essas são razões para emparelhar controles de rede com forte detecção de identidade e comportamento, não razões para omiti-los.

A campanha demonstra o valor de portões independentes. A rotação de senhas teria invalidado credenciais históricas. O MFA teria exigido outro fator. Uma política de rede teria rejeitado origens desconhecidas. O privilégio mínimo teria reduzido os dados visíveis. Controles de exportação poderiam ter interrompido o estágio. A detecção poderia ter encurtado o tempo de permanência. Nenhuma medida isolada é perfeita; o atacante teve sucesso onde várias estavam simultaneamente ausentes ou permissivas.

Para responsabilidade, cada portão precisa de um proprietário e uma medida de eficácia. "Política de rede suportada" é um fato do produto. "Toda conta de produção tem uma política testada cobrindo o serviço e estágios internos" é um resultado operacional. "MFA disponível" é um fato do produto. "Nenhum humano privilegiado pode estabelecer uma sessão com uma senha reutilizável sozinho" é um resultado. A responsabilidade compartilhada se torna significativa apenas quando ambas as partes podem mostrar os resultados em sua fronteira.

O provedor viu uma campanha que cada cliente podia ver apenas como um incidente

Um cliente individual podia inspecionar seus próprios logins bem-sucedidos e falhos, clientes, endereços IP, texto de consulta, funções, estágios e movimento de dados. O Snowflake podia correlacionar padrões entre contas: a mesma infraestrutura, clientes incomuns, reconhecimento repetido, comandos de estágio semelhantes, um aumento em logins apenas com senha ou credenciais correspondentes a feeds de inteligência de ameaças. Essa assimetria é a responsabilidade não contratual mais importante do provedor. É criada pela operação do serviço em escala.

Avisão LOGIN_HISTORYatual do Snowflake retém um ano de tentativas de login e inclui usuário, IP de origem, cliente reportado, primeiro e segundo fatores, sucesso e detalhes de risco relacionados, com latência documentada.QUERY_HISTORYretém um ano de atividade de consulta e conecta uma consulta ao evento de autenticação, sessão, usuário, função, texto, bytes de resultado, linhas descarregadas e bytes enviados pela rede. Clientes Enterprise podem usarACCESS_HISTORYpara reconstruir tabelas, visões, colunas, estágios, políticas e objetos modificados acessados. Esses esquemas fornecem o material bruto para uma investigação de alta qualidade.

Histórico bruto não é o mesmo que detecção. Um cliente deve conceder acesso a analistas, exportar ou consultar os dados, entender o comportamento normal, escrever alertas, roteá-los, retê-los além das janelas nativas, se necessário, e manter uma equipe de resposta. Uma latência de telemetria de duas horas pode ser aceitável para revisão retrospectiva, mas muito lenta para algumas decisões de exportação em massa. Um limite da Enterprise Edition no histórico de acesso no nível da coluna também pode afetar a precisão com que um cliente pode escopar a exposição.

Esses fatos operacionais e do produto devem ser testados durante a aquisição, não descobertos após um roubo.

O atualTrust Centerdo Snowflake verifica a ativação de MFA, política de rede da conta, funções privilegiadas, usuários inativos, logins de risco, endereços IP incomuns e grandes transferências de dados por meio de scanners de segurança e inteligência de ameaças. A documentação atual também declara limitações: alguns pacotes devem ser ativados; algumas detecções podem chegar dentro de uma hora; e a existência de uma política configurada não prova que seu conteúdo atinge o objetivo pretendido. Novamente, a capacidade atual não é evidência do que um determinado cliente ou o Snowflake detectou na primavera de 2024. Mostra o que um provedor pode transformar em produto uma vez que um padrão de falha entre clientes é compreendido.

O sistema de aviso deve operar em duas camadas. Na camada do inquilino, os clientes precisam de eventos imediatos e exportáveis e controles para bloquear ou suspender a atividade. Na camada do provedor, o Snowflake precisa de análises de campanha e um processo praticado para notificar os clientes com evidências suficientes para agir. Uma notificação útil inclui identificadores de conta e usuário, carimbos de data/hora em UTC, infraestrutura de origem, fator de autenticação, IDs de sessão e consulta, comandos, objetos e colunas tocados, ações de estágio, volume de transferência estimado, status de contenção e confiança.

"Potencialmente exposto" é um rótulo de abertura apropriado apenas se for seguido pelas evidências necessárias para resolver o potencial.

A intervenção do provedor também precisa de governança. Bloquear automaticamente uma sessão de cliente pode interromper a produção e pode exceder a autoridade contratual do provedor. Não agir pode permitir roubo contínuo. Portanto, o design deve definir limites de risco, retenções temporárias, canais de escalonamento do cliente, contatos de emergência e um processo de anulação rápida com antecedência. Os clientes devem nomear pessoas que possam receber um alerta de alta gravidade a qualquer hora e autorizar a suspensão.

O provedor deve medir o tempo desde o sinal entre contas até o contato com o cliente, o tempo até a contenção e a proporção de clientes notificados que podem recuperar um pacote de evidências completo.

A localidade dos dados não tornou o acesso local

O Snowflake comercializa e documenta a implantação regional porque os clientes têm requisitos de latência, resiliência, privacidade, regulatórios e de soberania. Adocumentação de regiões suportadasdo Snowflake diz que cada conta é hospedada em uma região e que os dados permanecem nessa região, a menos que os usuários os copiem, movam ou repliquem explicitamente. A mesma página contém o limite crítico: as regiões determinam onde os dados são armazenados e a computação é provisionada; elas não limitam o acesso do usuário ao Snowflake.

Essa distinção transforma a cadeia UNC5537 em um caso de soberania. Antes da intrusão, as tabelas de um cliente podiam estar armazenadas e processadas em um país selecionado ou localização de nuvem regional. Após a autenticação bem-sucedida, o atacante podia consultar a conta regional de outro lugar, preparar os resultados e baixá-los para um cliente. A Mandiant observou o padrão técnico de recuperação local de estágios temporários.

O registro público da campanha não estabelece o país de origem, país de destino ou status de transferência legal para cada vítima, portanto nenhuma alegação universal de transferência transfronteiriça ilegal é sustentável. A arquitetura, no entanto, mostra que a localidade do armazenamento sozinha não podia impor a localidade do usuário.

O compartilhamento e a replicação entre regiões criam um caminho de movimento legítimo separado. Aorientação de compartilhamento entre regiõesdo Snowflake diz às organizações para confirmar restrições legais e regulatórias antes de replicar dados para uma região ou país diferente. Esse é um movimento planejado sob administração do cliente. A exportação baseada em credenciais é diferente: pode criar uma cópia não controlada fora do ambiente selecionado sem alterar a localização da conta de origem. Um inventário de dados que registra apenas a região de origem continuará dizendo "UE" ou "Canadá" mesmo depois que um atacante removeu uma cópia.

Portanto, a soberania de dados tem pelo menos quatro camadas:

• Posicionamento:onde os recursos autoritativos de armazenamento e computação são provisionados.
• Acesso:quais identidades humanas e de máquina podem se conectar, de quais dispositivos, redes e jurisdições.
• Movimento:quais consultas, descarregamentos, compartilhamentos, replicações, conectores e downloads podem criar outra cópia.
• Evidência e remediação:se a organização pode provar onde a origem do acesso, o que saiu, quais pessoas ou registros regulamentados estavam envolvidos e com que rapidez pode conter e notificar.

O provedor controla partes importantes de todas as quatro camadas, mesmo quando o cliente escolhe a política. Ele oferece regiões e mantém os dados da conta nelas. Ele autentica solicitações e expõe controles de rede. Ele executa comandos de exportação e registra metadados de consulta. Ele possui visibilidade de ameaças entre clientes e pode desativar senhas vazadas. O cliente decide sua base legal, categorias de dados, funções, origens permitidas, mascaramento, retenção e movimento aprovado.

Um compromisso de hospedagem regional sem esses controles complementares pode satisfazer um requisito estreito de localização do data center enquanto deixa a autoridade prática para copiar dados globalmente exposta.

É também por isso que criptografia e soberania não devem ser confundidas. A criptografia pode proteger um objeto armazenado do operador da infraestrutura ou de um leitor não autorizado da camada de armazenamento. Uma aplicação que deve analisar o objeto necessariamente torna os dados disponíveis para um contexto de consulta autorizado. Se a garantia de identidade e o escopo da função são fracos, a localidade criptográfica pode coexistir com a exfiltração operacional.

Divulgações de clientes mostram consequências diferentes, não uma violação uniforme

A campanha é frequentemente descrita por nomes de clientes proeminentes, mas o registro público de cada cliente tem seu próprio escopo, datas, dados, terminologia e confiança. É inseguro transferir os fatos de uma empresa para outra ou converter uma alegação de fórum criminal em uma população verificada.

O Formulário 8-K da Live Nation de 31 de maio de 2024 disse que identificou atividade não autorizada em 20 de maio em um ambiente de banco de dados de nuvem de terceiros contendo dados da empresa, principalmente do Ticketmaster. Disse que em 27 de maio um ator criminoso ofereceu o que alegou serem dados de usuário da empresa para venda, e que a Live Nation estava notificando as autoridades policiais, reguladores e usuários conforme apropriado. O arquivamento não nomeou o Snowflake, forneceu uma contagem confirmada de pessoas afetadas ou explicou o caminho de autenticação.

Apágina de incidentedo Ticketmaster Canadá fornece um nível diferente de detalhe. Descreve acesso não autorizado a um banco de dados de nuvem isolado hospedado por um provedor de serviços de dados terceirizado, diz que o banco de dados continha informações pessoais limitadas de alguns compradores de ingressos norte-americanos e lista possíveis campos incluindo e-mail, número de telefone, informações de cartão criptografadas e outras informações fornecidas pelos clientes. Diz que as contas de clientes do Ticketmaster não foram afetadas. Esse último limite é importante: o comprometimento de um data warehouse de back-end não é evidência de que o atacante obteve o login de cada pessoa no Ticketmaster ou podia transacionar através da conta do consumidor.

Aficha informativa parlamentarde outubro de 2025 do Escritório do Comissário de Privacidade do Canadá identifica o Snowflake como o provedor terceirizado usado pelo Ticketmaster, dá uma janela de incidente de 2 de abril a 18 de maio de 2024 para o Ticketmaster Canadá e diz que informações pessoais de milhões, incluindo canadenses, estavam envolvidas. Também diz que a investigação permanecia aberta e que o Ticketmaster Canadá, como controlador de dados sob a PIPEDA, era a entidade sob investigação. Este é um contexto regulatório útil, mas não uma conclusão final que resolva adequação de salvaguardas, prazo de notificação ou responsabilidade.

O Formulário 8-K da AT&T de 12 de julho de 2024 ilustra por que as fronteiras da fonte são importantes mesmo quando os incidentes são discutidos juntos. A AT&T disse que um ator acessou ilegalmente um espaço de trabalho da AT&T em uma plataforma de nuvem de terceiros e exfiltrou arquivos de 14 a 25 de abril. Os arquivos continham registros de interação de chamadas e texto para quase todos os clientes sem fio da AT&T e clientes relevantes de operadora de rede virtual móvel para períodos especificados em 2022 e um dia em 2023.

A AT&T disse que os arquivos não continham conteúdo de chamadas ou textos, números de Seguro Social, datas de nascimento ou outras informações pessoais conforme a AT&T usava esse termo. O arquivamento em si não nomeia o Snowflake ou UNC5537. Suporta os fatos do incidente da AT&T, não uma atribuição de campanha por si só.

Esses registros produzem quatro regras de disciplina. Primeiro, use o arquivamento de um cliente apenas para esse cliente. Segundo, distinga um banco de dados, conta organizacional e login do consumidor. Terceiro, distinga campos de dados do número de pessoas representadas por eles. Quarto, preserve fatos negativos como "nenhum conteúdo de mensagem" ou "conta do consumidor não afetada" junto com o impacto. A responsabilidade se torna menos credível quando a análise expande alegações dramáticas e descarta limitantes.

Os clientes permaneceram responsáveis pelos dados e identidades que delegaram

O lado do cliente na responsabilidade compartilhada é substancial. A organização criou ou aprovou usuários do Snowflake, selecionou caminhos de autenticação, atribuiu funções, carregou dados, reteve histórico, escolheu uma região, ativou integrações e decidiu quais funcionários e contratantes podiam consultar o armazém. Também mantinha o relacionamento principal com as pessoas representadas em seus dados e geralmente retinha deveres de controlador sob a lei de privacidade aplicável.

Um cliente poderia ter interrompido a campanha observada em vários pontos. Poderia rotacionar senhas após exposição de endpoint, proibir contas de serviço apenas com senha, exigir MFA para humanos, federar o acesso através de um provedor de identidade governado, restringir redes, expirar usuários contratantes, reduzir concessões de funções, classificar e mascarar campos sensíveis, isolar privilégio de exportação, monitorar histórico de login e consulta e ensaiar notificações ao provedor de nuvem.

Para conjuntos de dados regulamentados ou de alto impacto, esses são deveres operacionais básicos, não aprimoramentos opcionais delegados à aquisição.

A governança de endpoints e contratantes merece atenção particular. Um usuário com uma função de alto impacto na nuvem não deve autenticar a partir de um computador pessoal não gerenciado. Os contratantes devem usar desktops virtuais controlados pelo cliente ou dispositivos com monitoramento de endpoint quando viável. Sua identidade deve ser única por cliente, vinculada a um patrocinador e expirar automaticamente. A organização deve pesquisar feeds de exposição de credenciais para seus padrões de conta Snowflake e forçar rotação quando evidências aparecerem, sem esperar por uso confirmado.

O privilégio mínimo deve ser testado contra dados, não contra cargo. "Analista" pode soar não administrativo enquanto retém acesso de seleção a cada linha em uma tabela de clientes, funcionários ou transações. Uma revisão de função deve perguntar quais linhas e colunas podem ser retornadas, se identificadores brutos são necessários, se conjuntos de resultados em massa podem ser escritos em estágios e se a identidade pode criar novas credenciais ou integrações. Consultas de amostra sob a função são evidências mais fortes do que um nome de função de aparência limpa.

Os clientes também possuem prontidão de resposta. Eles devem ser capazes de mapear um usuário do Snowflake para um funcionário ou contratante, uma consulta para titulares de dados afetados e uma exportação para uma jurisdição e análise de notificação. Históricos nativos de um ano podem ser insuficientes para retenção legal mais longa ou descoberta tardia, portanto clientes de alto risco devem transmitir eventos relevantes para um armazenamento de segurança independente. Os alertas do provedor precisam de um caminho testado para a equipe de segurança do cliente, escritório de privacidade, proprietário do negócio e tomador de decisão executivo.

Oguia de cadeia de suprimentos do Cybersecurity Frameworkdo NIST recomenda definir e comunicar requisitos do fornecedor de acordo com a criticidade. Aplicado aqui, um cliente Snowflake deve contratar prazo de notificação de incidente, campos de evidência, retenção, escalonamento de suporte, processamento regional, visibilidade de subprocessadores, aviso de mudança de controle e acesso de garantia. Também deve manter um plano de saída ou isolamento para as funções de dados cuja perda ou comprometimento seria intolerável. A responsabilidade compartilhada deve ser escrita como interfaces testáveis, não um parágrafo que aparece apenas após um incidente.

O Snowflake permaneceu responsável pela redução de risco no nível do serviço

O Snowflake não controlava o malware no dispositivo pessoal de um contratante ou a decisão do cliente de deixar o MFA desativado. Controlava se uma senha antiga podia permanecer como único fator, se origens irrestritas eram o padrão silencioso, se configurações arriscadas produziam avisos persistentes e o que o provedor fazia depois de observar um padrão entre clientes.

A responsabilidade do provedor neste caso tem seis partes.

Linha de base segura.O acesso privilegiado humano não deve depender apenas de uma senha reutilizável. Identidades de serviço devem ter um tipo separado e métodos sem senha suportados. Novos padrões devem alcançar contas existentes de alto risco por meio de aplicação em fases, exceções explícitas e ajuda à migração, em vez de proteger apenas novos inquilinos.

Visibilidade de configuração.O provedor deve mostrar aos administradores de segurança um denominador completo: humanos sem MFA, usuários de serviço legados com senhas, contas inativas, usuários sem restrições de rede, funções privilegiadas e contas que permitem ingresso público. As conclusões devem ser visíveis no nível da organização e exportáveis para auditoria.

Detecção entre clientes.Infraestrutura reutilizada, credenciais vazadas, clientes incomuns, sequências de reconhecimento, criação de estágios temporários e exportações grandes podem formar um sinal de campanha. O provedor deve detectar na camada de serviço, contatar prováveis vítimas e definir quando atividade de alta confiança desencadeia um bloqueio temporário.

Telemetria acionável.Os clientes precisam de evidências de autenticação, consulta, objeto, estágio e transferência com retenção suficiente e latência baixa o bastante para conter um roubo ativo. Evidências de maior fidelidade não devem se tornar indisponíveis precisamente onde o serviço armazena os dados de maior impacto.

Aviso e coordenação.Um alerta ao cliente deve percorrer uma rota de emergência conhecida e carregar evidências, não apenas conselhos para revisar logs. O provedor deve rastrear confirmação, contenção e exposição recorrente, e deve apoiar solicitações de aplicação da lei e reguladores sem colapsar observações incertas em contagens de vítimas confirmadas.

Verificação pós-incidente.Recursos e padrões anunciados precisam de medidas de adoção e eficácia. As mudanças posteriores do Snowflake em direção a MFA padrão, desativação de senhas vazadas, descobertas do Trust Center e tipos de identidade mais fortes abordam o caminho observado. A questão de responsabilidade restante é a cobertura: quais usuários e clientes estão realmente protegidos, quais exceções permanecem e com que frequência um controle para uma tentativa real ou simulada?

Essa alocação não torna o Snowflake o controlador de dados para cada conjunto de dados do cliente, nem torna o provedor responsável por cada configuração do cliente. Reconhece que uma empresa de nuvem lucra com a concentração de dados e a operação de uma fronteira de segurança. A escala cria deveres que apenas o provedor pode desempenhar, especialmente correlação entre inquilinos e engenharia de linha de base.

Litígios posteriores testam a mesma fronteira sem ainda resolvê-la

O Snowflake e empresas afetadas enfrentaram litígios civis consolidados após os incidentes. Em umaordem judicial federalde 29 de outubro de 2025, o Distrito de Montana considerou que autores de instituições financeiras alegaram suficientemente certas teorias de negligência contra o Snowflake e o Ticketmaster para sobreviver a moções de rejeição. O tribunal tratou o alegado MFA padrão e previsibilidade como relevantes para dever, violação e causalidade naquela fase processual.

Essa ordem não é uma conclusão do julgamento de que o Snowflake ou o Ticketmaster foram negligentes. Em uma moção de rejeição, o tribunal testa se alegações bem fundamentadas estabelecem uma reivindicação plausível; não resolve evidências contestadas, determina o mecanismo final do incidente para todo autor ou aloca danos. O Snowflake contestou as alegações e argumentou que as falhas dos clientes em implementar MFA, políticas de rede e outras salvaguardas causaram o dano. A ordem é significativa porque mostra que descrever o MFA como uma configuração do cliente não encerrou automaticamente toda reivindicação de dever do provedor.

Não é um substituto para o registro final do mérito.

A investigação de privacidade canadense carregava uma alocação diferente. O OPC disse que o Ticketmaster Canadá permanecia o controlador e era a entidade sob investigação, enquanto o escritório contatou o Snowflake para obter informações. Isso reflete um princípio comum de privacidade: terceirizar o armazenamento não terceiriza o dever do controlador de proteger e notificar. Não significa que o provedor de serviços não tenha deveres contratuais, técnicos ou legais próprios.

O próprio 10-K do Snowflake reconheceu inúmeros processos judiciais, investigações regulatórias e consultas de legisladores, mas não relatou uma alocação final universal de responsabilidade. Até a data da publicação, as fontes públicas revisadas aqui não suportam declarar que o Snowflake foi legalmente exonerado, que todo cliente estava legalmente em falta ou que um tribunal ou regulador final adotou a alocação operacional deste artigo.

A responsabilidade operacional pode ser avaliada antes da responsabilidade final. O acesso apenas com senha era previsível? Sim. O cliente podia exigir MFA e políticas de rede? Sim. O Snowflake podia projetar padrões e detectar atividade entre clientes? Sim. Criminosos exploraram intencionalmente o caminho resultante? Sim. Essas proposições podem coexistir. O direito de responsabilidade civil, contratual, privacidade e valores mobiliários pode atribuir consequências de forma diferente por jurisdição e autor, mas a engenharia não deve esperar que um slogan vença.

Um teste mensurável de responsabilidade compartilhada

A resposta mais forte não é outro diagrama com "cliente" de um lado e "provedor" do outro. É um conjunto de controles cuja cobertura e comportamento de falha podem ser demonstrados.

Os conselhos devem receber resultados em vez de inventários de recursos. Medidas úteis incluem a porcentagem de usuários humanos protegidos por MFA resistente a phishing, o número de usuários de serviço capazes de usar senha, a idade de cada exceção de emergência, a porcentagem de contas com políticas de rede testadas, o número de identidades de contratantes privilegiadas além do prazo, tempo mediano para alertar sobre origens desconhecidas, tempo para suspender uma sessão de alta confiança e tempo para produzir um pacote de exposição no nível do campo.

O Snowflake deve publicar progresso agregado onde puder fazê-lo sem expor clientes. O compromisso da CISA contempla explicitamente estatísticas de adoção por usuário e tipo de MFA. Uma declaração de que o MFA está disponível é menos informativa do que a distribuição de logins apenas com senha ao longo do tempo. Uma declaração de que o Trust Center está ativado é menos informativa do que quantas constatações críticas permanecem abertas além de um período definido. Uma declaração de que clientes suspeitos foram notificados é menos informativa do que a latência de notificação e a completude do pacote de evidências.

Os clientes devem exigir o mesmo rigor de si mesmos. Um provedor não pode salvar uma organização que cria funções amplas, ignora constatações, mantém usuários contratantes antigos e não tem ninguém atendendo o contato de emergência. O propósito de padrões mais fortes não é transferir a propriedade da segurança do cliente para o Snowflake. É tornar omissões previsíveis menos prováveis de se tornarem roubo de dados em massa.

O que o registro público ainda não estabelece

As evidências são fortes o suficiente para reconstruir um padrão de campanha, mas não todo incidente de vítima.

O registro público não identifica todas as organizações notificadas, confirma que todas as 165 sofreram acesso não autorizado ou fornece um total final da campanha de indivíduos, tabelas, registros ou bytes baixados afetados. Não mostra quais vítimas pagaram exigências de extorsão ou se a exclusão prometida ocorreu.

Não publica o tipo de usuário, hierarquia de funções, histórico de MFA, configuração de rede, proprietário do endpoint, sequência de sessão, colunas acessadas ou volume de exportação para cada organização. Constatações de dispositivos de contratantes de várias investigações não devem ser atribuídas a toda vítima. A estatística de exposição de credenciais de 79,7% não deve ser transformada em uma porcentagem de vítimas.

Não estabelece uma vulnerabilidade de software, fuga entre inquilinos, comprometimento da plataforma de produção do Snowflake, roubo de uma credencial mestre do provedor ou acesso a todo cliente Snowflake. O uso observado de clientes e comandos suportados é evidência de abuso de credenciais, não prova de que o código do produto foi explorado.

Não prova que dados regionais cruzaram uma fronteira nacional em todo incidente. A arquitetura permitia acesso remoto e download local; a análise legal de transferência exigiria fatos de origem, destino, titular de dados, contratuais e de jurisdição para cada cliente.

Não permite que os possíveis campos do Ticketmaster, o escopo de detalhes de chamada da AT&T ou qualquer contagem de fórum criminal sejam generalizados para outros clientes. O arquivamento da Live Nation não nomeou o Snowflake. O arquivamento da AT&T não nomeou o Snowflake ou UNC5537. A associação externa pode ser relevante para investigação adicional, mas os arquivamentos devem ser citados pelo que realmente estabelecem.

Finalmente, a documentação atual do Snowflake não prova a operação de controles em abril e maio de 2024. MFA padrão posterior, proteção contra senhas vazadas, detecção do Trust Center, políticas de autenticação e mudanças de identidade podem reduzir a recorrência, mas a evidência pública de adoção, cobertura de exceções, desempenho de detecção e eficácia independente permanece mais limitada do que as descrições dos recursos.

A responsabilidade compartilhada deve sobreviver ao momento em que uma recomendação é ignorada

A campanha Snowflake não é melhor compreendida como uma competição entre duas histórias absolutas. Uma história diz que a plataforma foi hackeada e apenas o provedor falhou. As evidências não a suportam. A outra diz que os clientes perderam senhas e, portanto, a questão do provedor está encerrada. Isso é tecnicamente incompleto.

UNC5537 encontrou uma junção escalável entre comprometimento de endpoint e concentração em nuvem. Senhas históricas permaneceram válidas. Identidades humanas e de serviço nem sempre foram separadas. Portões de MFA e rede estavam ausentes. Funções suportadas de consulta e estágio moveram dados rapidamente. O provedor podia ver um padrão entre inquilinos, enquanto cada cliente via apenas sua própria conta. Uma região de armazenamento escolhida podia conter os dados de origem no lugar, mesmo enquanto uma sessão autenticada criava uma cópia não controlada em outro lugar.

Os clientes tinham o dever mais claro de governar seus usuários, funções, endpoints, contratantes e dados. O Snowflake tinha o dever mais claro de proteger e observar a fronteira do serviço, tornar as proteções de alto valor fáceis e cada vez mais inevitáveis, detectar comportamento de campanha e fornecer evidências. Os atacantes tinham responsabilidade direta pelos atos criminosos. Reguladores e tribunais devem avaliar deveres legais com base nos fatos e na lei aplicável a cada organização. Essas alocações se sobrepõem porque os controles se sobrepõem.

A direção do produto pós-campanha reconhece implicitamente a lacuna entre capacidade e resultado. MFA padrão para novos usuários humanos, desativação de senhas vazadas, política de autenticação mais forte, migração de usuários de serviço e descobertas do Trust Center movem a segurança para mais perto da linha de base do provedor. Não apagam a responsabilidade do cliente. Tornam o sistema compartilhado menos dependente de todo administrador encontrar e ativar toda opção correta antes que uma senha roubada seja testada.

Esse é o teste de responsabilidade durável para uma plataforma de dados em nuvem. Suponha que um cliente perderá um aviso, um dispositivo de contratante será infectado, uma credencial permanecerá válida e um atacante usará funções comuns do produto. Então pergunte se o padrão bloqueia o login, outro portão rejeita a origem, a função revela pouco, a exportação desencadeia intervenção e a evidência chega ao cliente a tempo. A responsável compartilhada é credível apenas quando o serviço permanece defensável após o erro previsível de uma parte, e quando ambas as partes podem provar o que fizeram antes e depois dele.