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

Resumo

• Limite confirmado da campanha:A Mandiant atribuiu uma campanha financeiramente motivada ao UNC5537 e afirmou que todos os incidentes da campanha que ela tratou diretamente tiveram origem em credenciais de clientes comprometidas. Não encontrou evidências de que o acesso não autorizado de clientes decorreu de uma violação do ambiente empresarial da Snowflake. A Snowflake também disse que não encontrou evidências de vulnerabilidade, configuração incorreta 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 da 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 sobre responsabilidade compartilhada:Os clientes controlavam seus usuários, papéis, rotação de senhas, ativação de MFA, políticas de rede, higiene de endpoints e minimização de dados. A Snowflake controlava quais proteções existiam, como eram apresentadas e definidas por padrão, quais sinais entre clientes a plataforma podia ver e com que rapidez os avisos e um comportamento de linha de base mais forte chegavam à base instalada. Essas responsabilidades são concorrentes, não mutuamente exclusivas.
• Conclusão sobre soberania:Escolher uma região da Snowflake determina onde o armazenamento e a computação da conta estão localizados; a documentação da Snowflake diz 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 se mostrou violada, mas a relação de serviço foi testada

A primeira disciplina neste caso é o vocabulário. Uma instância de cliente da Snowflake não era a mesma coisa que o ambiente empresarial da própria 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 conta de cliente. Não apoiam um comprometimento técnico em toda a plataforma.

Orelatório da campanha UNC5537 da Mandianté excecionalmente direto nesse ponto. Para todos os incidentes associados à campanha que a própria Mandiant tratou, a causa raiz foram credenciais de clientes comprometidas. Sua investigação não encontrou evidências de que o acesso não autorizado a contas de clientes decorreu de uma violação do ambiente empresarial da Snowflake. O próprioaviso de investigação e reforço da Snowflakeseparou de forma semelhante as contas de clientes visadas da plataforma de produção e deu aos clientes consultas e indicadores para investigar os seus próprios ambientes. A CISA amplificou essa orientação numalerta de 3 de junho de 2024.

Essa conclusão negativa é importante. Chamar o evento de violação da plataforma da Snowflake pode implicar que um defeito no código ou infraestrutura partilhados abriu todos os inquilinos, ou que a Snowflake perdeu uma credencial mestre que desbloqueava os clientes. O registo revisto não estabelece nenhum dos dois. Também obscureceria as ações que os clientes precisavam de tomar imediatamente: identificar utilizadores apenas com senha, rodar credenciais, inspecionar o histórico de login e consultas, restringir redes, reduzir privilégios de papéis e preservar evidências.

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

O facto de um controlo decisivo ser configurável pelo cliente determina quem tinha o dever operacional de o configurar. Não responde se as predefinições, avisos, deteção e aplicação de regras do provedor eram proporcionais à concentração de dados no seu serviço.

OFormulário 10-Kdo ano fiscal de 2025 da Snowflake formaliza a sua posição. Afirma que a Snowflake é responsável pela segurança da plataforma e da infraestrutura de nuvem subjacente, enquanto os clientes selecionam e configuram controlos para os seus ambientes. Atribui o acesso de maio de 2024 à falha dos clientes em cumprir obrigações como MFA e políticas de rede, enquanto regista processos judiciais, investigações regulatórias, consultas de legisladores, danos reputacionais e a possibilidade de disputas de indenização. Essa é uma evidência material da empresa sobre o modelo declarado da Snowflake e a exposição do negócio. Não é uma adjudicação independente de que toda a responsabilidade ou reclamação legal pertence ao lado do cliente.

A pergunta útil é, portanto, mais restrita do que "Quem foi violado?" e mais ampla do que "De quem foi roubada a senha?" É: em cada etapa, desde o segredo roubado até aos dados descarregados, que ator podia prevenir, detetar, interromper, reconstruir ou alertar sobre a ação? A responsabilidade segue o controlo sobre essas etapas.

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

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

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

Cada termo na última frase precisa de proteção contra inflação. "Aproximadamente" marca uma estimativa. "Potencialmente expostas" descreve uma população de notificação, não 165 conclusões forenses completas. "Organizações" não significa contas, bases de dados, pessoas ou registos. 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 global 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 na nuvem em 2024 podia começar com uma infeção de endpoint anos antes. A Mandiant descobriu que a maioria das credenciais usadas pelo UNC5537 estava presente em resultados históricos de infostealer, com a infeção associada mais antiga observada em novembro de 2020. Pelo menos 79,7% das contas aproveitadas pelo ator tinham exposição prévia de credenciais. Essa percentagem aplica-se às contas usadas pelo ator na campanha analisada, não a todos os clientes da Snowflake ou a todas as 165 organizações notificadas.

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

Juntas, formaram um caminho de autorização durável: conhecer o localizador da conta, nome de utilizador e senha ainda válida; conectar a partir de um sistema controlado pelo atacante; receber uma sessão; herdar o papel atribuído; consultar o que esse papel pode ler.

A dimensão do endpoint também era mais distribuída do que a narrativa convencional de laptop de funcionário sugere. Em várias investigações, a Mandiant encontrou a infeção anterior por infostealer em sistemas de contratantes que também eram usados para atividades pessoais, incluindo jogos ou downloads pirateados. Um dispositivo de contratante pode estar fora da frota de endpoints gerida pelo cliente enquanto transporta 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 utilizador 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 na nuvem. A credencial é roubada de um endpoint, talvez fora da frota da Snowflake ou do proprietário dos dados. A credencial é aceite por um serviço global. O papel pode alcançar um armazém consolidado contendo anos de registos de vários sistemas de negócio. O atacante já não precisa de comprometer esses sistemas fonte um a 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 controlo 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.

Funcionalidades suportadas tornaram-se um caminho de exfiltração

A campanha não parou na autenticação. A Mandiant observou acesso através de Snowsight, SnowSQL, drivers e ferramentas de base de dados. O ator listou utilizadores, papéis, sessões, nomes de organizações, bases de dados, esquemas e tabelas. Usou operações SQL familiares para selecionar dados, criar estágios temporários, copiar resultados de consultas para ficheiros comprimidos e recuperar esses ficheiros para uma máquina local. Em vários casos, 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 utilizador e senha válidos do cliente estabeleceram uma sessão.
2. A sessão herdou papéis e privilégios de objeto atribuídos pelo cliente.
3. Reconhecimento identificou tabelas valiosas e estágios disponíveis.
4. Consultas selecionaram registos que o papel tinha permissão para ler.
5. Estágios temporários eCOPY INTOconverteram resultados em ficheiros descarregáveis.
6. GETmoveu ficheiros para um cliente controlado pelo atacante.

Nenhum passo nessa cadeia exigiu que a base de dados funcionasse mal. É por isso que a encriptação em repouso, embora necessária, não foi o controlo decisivo. Adocumentação de encriptação de ponta a ponta da Snowflakeafirma que os dados do cliente são encriptados em repouso e durante o transporte com TLS, mas também explica que a Snowflake descripta os dados durante transformações ou operações de tabela e permite que os utilizadores descarreguem resultados. A encriptação protege ficheiros e transporte de partes que não têm autorização ou chaves. Não impede que uma identidade aceite com um papel permitido peça ao serviço para devolver resultados legíveis.

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

O design de papéis, portanto, controlou o raio após o login. Omodelo de controlo de acessoatual da Snowflake suporta controlos de acesso baseados em papéis e discricionários, propriedade, hierarquia de papéis e privilégios de objeto. Uma credencial atribuída apenas a uma base de dados ou vista estreita apresenta uma consequência diferente de uma que detémACCOUNTADMIN, uso amplo de armazém ou acesso seletivo a 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. O papel temporário de um contratante deve expirar com o contrato, em vez de permanecer dormente com uma senha válida.

As políticas de proteção de dados podem restringir o resultado mesmo quando um papel é comprometido. Adocumentação de classificação de dados sensíveis da Snowflakeliga a descoberta de colunas pessoais e sensíveis a políticas de mascaramento e acesso a linhas. Essa é uma descrição de capacidade atual, não uma evidência de que todos os clientes afetados classificaram ou mascararam os 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 vistas aprovadas?

A exportação é, por si só, uma função de negócio privilegiada e deve ser governada como tal. Um armazém de dados frequentemente precisa de descarregamentos em massa para pipelines legítimos, backups, treino de modelos e sistemas downstream. Uma proibição geral raramente é realista. Mas criar um estágio, descarregar um resultado invulgarmente 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 um papel de exportação separado.

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

O cliente detinha a definição; a Snowflake detinha a linha de base

A MFA é o teste mais agudo de responsabilidade partilhada porque ambos os lados podem afirmar um facto verdadeiro. O administrador do cliente podia e esperava-se que a ativasse. A Snowflake oferecia MFA desde 2015 e políticas de rede desde 2016. Ao mesmo tempo, as contas bem-sucedidas de 2024 conseguiram 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. Uma funcionalidade de segurança pode ser gratuita, documentada, recomendada e ainda assim ausente das sessões que importam. Os administradores enfrentam integrações antigas, utilizadores de serviço não interativos, contratantes, contas de recurso, múltiplos clientes e medo de bloqueio. Essas restrições explicam a fricção de adoção; não justificam deixar o acesso humano privilegiado dependente de uma senha reutilizável. Também dão a um provedor a informação necessária 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 da Snowflake passou da recomendação para padrões mais fortes. O seuanúncio do compromisso Secure by Designde julho de 2024 enfatizou controlos de política de MFA e verificações do Trust Center. Em setembro de 2024, a Snowflake afirmou que aMFA seria aplicada por padrãopara utilizadores humanos em contas criadas a partir de outubro de 2024, recomendando SSO com MFA do provedor de identidade para humanos e autenticação OAuth ou par de chaves para serviços. A distinção entre contas novas e existentes é importante. Uma predefinição segura protege a criação futura; não retira automaticamente todos os caminhos de senha herdados na base instalada.

A Snowflake introduziu mais tarde aProteção de Senhas Vazadas, que usa feeds de inteligência de ameaças para testar senhas vazadas relatadas num processo que preserva a privacidade e desativa uma senha quando confirmada como ainda válida. Esse controlo do lado do provedor aborda diretamente uma das vantagens do UNC5537: credenciais antigas de infostealer que permaneciam utilizáveis. É também evidência de que a responsabilidade partilhada pode evoluir. Os clientes ainda têm de gerir identidades e rotações, mas o provedor pode usar inteligência entre serviços para fazer com que uma senha roubada pare de funcionar antes de cada cliente a encontrar independentemente.

Adocumentação atual de políticas de autenticaçãopermite que os administradores controlem métodos e clientes permitidos e exijam MFA ao nível da conta ou do utilizador. Também alerta que as 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 sobre pares de chavesdá aos utilizadores de serviço uma alternativa a senhas estáticas. Essas páginas descrevem capacidades disponíveis até 2026; não devem ser lidas retroativamente como prova das funcionalidades, predefinições ou estado de aplicação exatos para cada cliente em abril de 2024.

As normas ajudam a explicar por que as predefinições do provedor pertencem à análise. Aorientação atual de autenticação e gestão de autenticadores do NISTtrata as senhas como não resistentes a replay e define a resistência a phishing como uma propriedade de protocolo que não depende da vigilância do utilizador. Ocompromisso Secure by Design da CISAde 2024 identifica especificamente a MFA por padrão, cutucadas persistentes no produto, suporte de SSO de linha de base e publicação de métricas de adoção como formas de os fabricantes de software aumentarem mensuravelmente o uso de MFA. A Snowflake assinou esse compromisso voluntário após a campanha. O compromisso não é um veredito legal sobre o design da 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. Os administradores humanos devem usar MFA resistente a phishing ou uma identidade federada fortemente governada. As cargas de trabalho de serviço devem usar credenciais de trabalho que possam ser escopadas, rotacionadas e atribuídas sem fingir que um robô pode responder a uma notificação push. O acesso de recurso deve ser raro, monitorizado, limitado no tempo e testado. As identidades de contratantes devem ter um proprietário, expiração, postura de dispositivo aprovada e sem reutilização de credenciais entre clientes.

Todas as exceções devem aparecer num painel cujo denominador são todas as identidades, não apenas os funcionários ativos.

A política de rede era 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. As 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íticas de rede da Snowflaketorna a predefinição explícita: sem uma política, os utilizadores podem conectar-se de qualquer computador ou dispositivo. Os clientes podem permitir ou bloquear intervalos de IP e endpoints privados, aplicar controlos ao nível da conta ou do utilizador e restringir o acesso a estágios internos com configuração adicional. A conetividade privada e os controlos de acesso público podem fortalecer ainda mais contas de alta sensibilidade.

O cliente conhece os seus escritórios aprovados, cargas de trabalho na nuvem, VPNs, contratantes e endpoints de integração, por isso o cliente deve definir a lista de permissões utilizável. A Snowflake não pode inferir todas as origens legítimas sem interromper o negócio. No entanto, o provedor controla a alcançabilidade predefinida, a sintaxe da política, a capacidade de simular uma alteração, a proteção contra bloqueio, a registo e se um administrador é avisado quando não existe política de conta.

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 a partir de um dispositivo de contratante aprovado, encaminhar 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 as listas estáticas difíceis. A conetividade privada pode excluir ferramentas SaaS que não a suportam. Essas são razões para emparelhar controlos de rede com identidade forte e deteção de comportamento, não razões para os omitir.

A campanha demonstra o valor de portões independentes. A rotação de senhas teria invalidado credenciais históricas. A 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. Os controlos de exportação poderiam ter interrompido a preparação. A deteção poderia ter encurtado o tempo de permanência. Nenhuma medida isolada é perfeita; o atacante conseguiu onde várias estavam simultaneamente ausentes ou permissivas.

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

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

Um cliente individual podia inspecionar os seus próprios logins bem-sucedidos e falhados, clientes, endereços IP, texto de consultas, papéis, estágios e movimento de dados. A Snowflake podia correlacionar padrões entre contas: a mesma infraestrutura, clientes invulgares, reconhecimento repetido, comandos de preparação semelhantes, um aumento de logins apenas com senha ou credenciais correspondentes a feeds de inteligência de ameaças. Esta assimetria é a responsabilidade não contratual mais importante do provedor. É criada por operar o serviço à escala.

Avista LOGIN_HISTORYatual da Snowflake retém um ano de tentativas de login e inclui utilizador, IP de origem, cliente reportado, primeiro e segundo fatores, sucesso e detalhe de risco relacionado, com latência documentada. AQUERY_HISTORYretém um ano de atividade de consulta e liga uma consulta ao evento de autenticação, sessão, utilizador, papel, texto, bytes de resultado, linhas descarregadas e bytes enviados pela rede. Os clientes Enterprise podem usar aACCESS_HISTORYpara reconstruir tabelas, vistas, colunas, estágios, políticas e objetos modificados acedidos. Esses esquemas fornecem a matéria-prima para uma investigação de alta qualidade.

O histórico bruto não é o mesmo que deteção. Um cliente tem de conceder acesso a analistas, exportar ou consultar os dados, compreender o comportamento normal, escrever alertas, encaminhá-los, retê-los além das janelas nativas se necessário e ter pessoal para responder. Uma latência de telemetria de duas horas pode ser aceitável para revisão retrospetiva, mas demasiado lenta para algumas decisões de exportação em massa. Uma limitação do Enterprise Edition no histórico de acesso ao nível da coluna também pode afetar a precisão com que um cliente pode delimitar a exposição.

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

OTrust Centeratual da Snowflake verifica a ativação de MFA, a política de rede da conta, papéis privilegiados, utilizadores dormentes, inícios de sessão arriscados, endereços IP invulgares e grandes transferências de dados através de scanners de segurança e inteligência de ameaças. A documentação atual também afirma limitações: alguns pacotes devem ser ativados; algumas deteções podem chegar dentro de uma hora; e a existência de uma política configurada não prova que o seu conteúdo atinge o objetivo pretendido. Mais uma vez, a capacidade atual não é evidência do que um determinado cliente ou a Snowflake detetou 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 alerta deve operar em duas camadas. Na camada do inquilino, os clientes precisam de eventos imediatos e exportáveis e controlos para bloquear ou suspender atividade. Na camada do provedor, a Snowflake precisa de análises de campanha e um processo praticado para notificar os clientes com evidência suficiente para agir. Uma notificação útil inclui identificadores de conta e utilizador, 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 preparação, volume de transferência estimado, estado de contenção e confiança.

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

A intervenção do provedor também precisa de governação. 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 continuado. O design deve, portanto, definir limiares de risco, suspensões temporárias, canais de escalada do cliente, contactos de emergência e um processo de anulação rápido 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é ao contacto com o cliente, o tempo até à contenção e a proporção de clientes notificados que conseguem recuperar um pacote de evidência completo.

A localidade dos dados não tornou o acesso local

A Snowflake comercializa e documenta a implantação regional porque os clientes têm requisitos de latência, resiliência, privacidade, regulamentação e soberania. Adocumentação de regiões suportadas da Snowflakeafirma que cada conta está alojada numa região e que os dados permanecem nessa região, a menos que os utilizadores os copiem, movam ou repliquem explicitamente. A mesma página contém o limite crítico: as regiões ditam onde os dados são armazenados e a computação é provisionada; não limitam o acesso do utilizador à Snowflake.

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

O registo público da campanha não estabelece o país de origem, país de destino ou estado legal de transferência para cada vítima, pelo que nenhuma alegação universal de transferência transfronteiriça ilegal é sustentável. A arquitetura mostra, no entanto, que a localidade do armazenamento por si só não podia impor a localidade do utilizador.

A partilha e replicação entre regiões criam um caminho de movimento legítimo separado. Aorientação de partilha entre regiões da Snowflakediz às organizações para confirmarem restrições legais e regulamentares antes de replicar dados para uma região ou país diferente. Esse é um movimento planeado 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 regista apenas a região de origem continuará a dizer "UE" ou "Canadá" mesmo depois de um atacante ter removido uma cópia.

A soberania dos dados tem, portanto, 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 conectar-se, a partir de que dispositivos, redes e jurisdições.
• Movimento:quais consultas, descarregamentos, partilhas, replicações, conectores e transferências podem criar outra cópia.
• Evidência e reparação:se a organização consegue provar de onde veio o acesso, o que saiu, quais pessoas ou registos regulados 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. Oferece regiões e mantém os dados da conta nelas. Autentica pedidos e expõe controlos de rede. Executa comandos de exportação e regista metadados de consultas. Detém visibilidade de ameaças entre clientes e pode desativar senhas vazadas. O cliente decide a sua base legal, categorias de dados, papéis, origens permitidas, mascaramento, retenção e movimento aprovado.

Um compromisso de alojamento regional sem estes controlos complementares pode satisfazer um requisito estreito de localização do data center, deixando a autoridade prática para copiar dados globalmente exposta.

É também por isso que a encriptação e a soberania não devem ser confundidas. A encriptação pode proteger um objeto armazenado do operador de infraestrutura ou de um leitor não autorizado da camada de armazenamento. Uma aplicação que deve analisar o objeto torna necessariamente os dados disponíveis num contexto de consulta autorizado. Se a garantia de identidade e o âmbito do papel forem 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 através de nomes de clientes proeminentes, mas o registo público de cada cliente tem o seu próprio âmbito, datas, dados, terminologia e confiança. É inseguro transferir os factos de uma empresa para outra ou converter uma alegação de fórum criminoso numa população verificada.

OFormulário 8-Kda Live Nation de 31 de maio de 2024 afirmou que identificou atividade não autorizada em 20 de maio num ambiente de base de dados na nuvem de terceiros contendo dados da empresa, principalmente da Ticketmaster. Disse que em 27 de maio um ator criminoso ofereceu o que alegava serem dados de utilizadores da empresa para venda, e que a Live Nation estava a notificar as autoridades policiais, reguladores e utilizadores conforme apropriado. O documento não nomeou a Snowflake, forneceu uma contagem confirmada de pessoas afetadas ou explicou o caminho de autenticação.

Apágina de incidente da Ticketmaster Canadáfornece um nível diferente de detalhe. Descreve acesso não autorizado a uma base de dados na nuvem isolada alojada por um provedor de serviços de dados terceiro, afirma que a base de dados continha informações pessoais limitadas de alguns compradores de bilhetes norte-americanos e lista campos possíveis incluindo email, número de telefone, informações de cartão encriptadas e outras informações fornecidas pelos clientes. Diz que as contas de clientes da Ticketmaster não foram afetadas. Esse último limite é importante: o comprometimento de um armazém de dados de back-end não é evidência de que o atacante obteve o login da Ticketmaster de cada pessoa ou podia transacionar através da conta do consumidor.

Aficha parlamentar de outubro de 2025do Gabinete do Comissário de Privacidade do Canadá identifica a Snowflake como o provedor terceiro usado pela Ticketmaster, dá uma janela de incidente de 2 de abril a 18 de maio de 2024 para a Ticketmaster Canadá e afirma que informações pessoais de milhões, incluindo canadianos, estavam envolvidas. Diz também que a investigação permanecia aberta e que a Ticketmaster Canadá, como controladora de dados ao abrigo da PIPEDA, era a entidade sob investigação. Este é um contexto regulatório útil, mas não uma conclusão final que resolva a adequação das salvaguardas, o timing da notificação ou a responsabilidade.

OFormulário 8-Kda AT&T de 12 de julho de 2024 ilustra por que as fronteiras da fonte importam mesmo quando os incidentes são discutidos em conjunto. A AT&T disse que um ator acedeu ilegalmente a um espaço de trabalho da AT&T numa plataforma de nuvem de terceiros e exfiltrou ficheiros de 14 a 25 de abril. Os ficheiros continham registos de interações de chamadas e texto para quase todos os clientes sem fios da AT&T e clientes relevantes de operadores de rede móvel virtual para períodos especificados em 2022 e um dia em 2023. A AT&T disse que os ficheiros não continham conteúdo de chamadas ou texto, números de Segurança Social, datas de nascimento ou outras informações pessoais conforme a AT&T usava esse termo. O documento em si não nomeia a Snowflake ou o UNC5537. Apoia os factos do incidente da AT&T, não uma atribuição de campanha por si só.

Estes registos produzem quatro regras de disciplina. Primeiro, usar o documento de um cliente apenas para esse cliente. Segundo, distinguir uma base de dados, conta organizacional e login de consumidor. Terceiro, distinguir campos de dados do número de pessoas representadas por eles. Quarto, preservar factos negativos como "sem conteúdo de mensagem" ou "conta de consumidor não afetada" juntamente com o impacto. A responsabilização torna-se menos credível quando a análise expande alegações dramáticas e abandona as limitadoras.

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

O lado do cliente na responsabilidade partilhada é substancial. A organização criou ou aprovou utilizadores da Snowflake, selecionou caminhos de autenticação, atribuiu papéis, 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 detinha a relação principal com as pessoas representadas nos seus dados e geralmente retinha deveres de controlador ao abrigo da lei de privacidade aplicável.

Um cliente podia ter interrompido a campanha observada em vários pontos. Podia rodar 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 utilizadores contratantes, reduzir concessões de papéis, classificar e mascarar campos sensíveis, isolar privilégio de exportação, monitorizar o histórico de login e consultas e ensaiar notificações ao provedor de nuvem. Para conjuntos de dados regulados ou de alto impacto, esses são deveres operacionais de base, não melhorias opcionais delegadas na aquisição.

A governação de endpoints e contratantes merece atenção particular. Um utilizador com um papel de nuvem de alto impacto não deve autenticar a partir de um computador pessoal não gerido. Os contratantes devem usar ambientes de trabalho virtuais ou dispositivos controlados pelo cliente com monitorização de endpoint, quando viável. A sua identidade deve ser única por cliente, ligada a um patrocinador e expirar automaticamente. A organização deve procurar feeds de exposição de credenciais para os seus padrões de conta Snowflake e forçar a rotação quando aparecerem evidências, sem esperar por uso indevido confirmado.

O privilégio mínimo deve ser testado contra os dados, não contra o título do cargo. "Analista" pode soar não administrativo enquanto mantém acesso seletivo a todas as linhas numa tabela de clientes, funcionários ou transações. Uma revisão de papéis deve perguntar quais linhas e colunas podem ser devolvidas, se são necessários identificadores brutos, 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 o papel são evidências mais fortes do que um nome de papel de aparência limpa.

Os clientes também são donos da prontidão de resposta. Devem ser capazes de mapear um utilizador Snowflake para um funcionário ou contratante, uma consulta para os titulares de dados afetados e uma exportação para uma jurisdição e análise de notificação. Os históricos nativos de um ano podem ser insuficientes para retenção legal mais longa ou descoberta tardia, pelo que os clientes de alto risco devem transmitir eventos relevantes para um repositório de segurança independente.

Os alertas do provedor precisam de um caminho testado para a equipa de segurança do cliente, gabinete de privacidade, proprietário do negócio e tomador de decisão executivo.

Oguia da cadeia de suprimentos do Cybersecurity Framework do NISTrecomenda definir e comunicar requisitos de fornecedores de acordo com a criticidade. Aplicado aqui, um cliente da Snowflake deve contratualizar o timing do aviso de incidente, campos de evidência, retenção, escalação de suporte, processamento regional, visibilidade de subprocessador, aviso de alteração de controlo e acesso de garantia. Deve também manter um plano de saída ou isolamento para as funções de dados cuja perda ou comprometimento seria intolerável. A responsabilidade partilhada deve ser escrita como interfaces testáveis, não um parágrafo que aparece apenas após um incidente.

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

A Snowflake não controlava o malware no dispositivo pessoal de um contratante ou a decisão do cliente de deixar a MFA desativada. Controlava se uma senha antiga podia continuar a ser o único fator, se as origens irrestritas eram a predefinição silenciosa, se as 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. As identidades de serviço devem ter um tipo separado e métodos não baseados em senha suportados. Novas predefinições devem alcançar contas existentes de alto risco através de aplicação faseada, exceções explícitas e ajuda à migração, em vez de proteger apenas novos inquilinos.

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

Deteção entre clientes.Infraestrutura reutilizada, credenciais vazadas, clientes invulgares, sequências de reconhecimento, criação de estágios temporários e grandes exportações podem formar um sinal de campanha. O provedor deve detetar ao nível do serviço, contactar 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 ficar indisponíveis precisamente onde o serviço armazena os dados de maior impacto.

Aviso e coordenação.Um alerta ao cliente deve percorrer uma via de emergência conhecida e transportar evidências, não apenas conselhos para rever registos. O provedor deve acompanhar a confirmação, contenção e exposição recorrente, e deve apoiar pedidos de autoridades policiais e reguladores sem colapsar observações incertas em contagens de vítimas confirmadas.

Verificação pós-incidente.As funcionalidades e predefinições anunciadas precisam de medidas de adoção e eficácia. As alterações posteriores da Snowflake em direção à MFA por padrão, desativação de senhas vazadas, conclusões do Trust Center e tipos de identidade mais fortes abordam o caminho observado. A questão de responsabilidade restante é a cobertura: que utilizadores e clientes estão realmente protegidos, que exceções permanecem e com que frequência um controlo para uma tentativa real ou simulada?

Esta alocação não faz da 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 ao concentrar dados e operar uma fronteira de segurança. A escala cria deveres que apenas o provedor pode realizar, especialmente a correlação entre inquilinos e a engenharia de linha de base.

Litígios posteriores testam a mesma fronteira sem ainda a resolver

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

Essa ordem não é uma conclusão de julgamento de que a Snowflake ou a Ticketmaster foram negligentes. Numa moção de rejeição, o tribunal testa se as alegações bem formuladas constituem uma alegação plausível; não resolve evidências disputadas, determina o mecanismo final do incidente para cada queixoso ou aloca danos. A 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 a MFA como uma definição do cliente não terminou automaticamente todas as alegações de dever do provedor.

Não substitui o registo final do mérito.

A investigação de privacidade canadiana teve uma alocação diferente. O OPC disse que a Ticketmaster Canada permaneceu a controladora e era a entidade sob investigação, enquanto o gabinete contactou a Snowflake para obter informações. Isso reflete um princípio comum de privacidade: externalizar o armazenamento não externaliza 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 da Snowflake reconheceu numerosos processos judiciais, investigações regulatórias e consultas de legisladores, mas não reportou uma alocação final universal de responsabilidade. À data de publicação, as fontes públicas revistas aqui não apoiam declarar que a Snowflake foi legalmente exonerada, que todos os clientes estavam 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. A Snowflake podia conceber predefinições e detetar atividade entre clientes? Sim. Os criminosos exploraram intencionalmente o caminho resultante? Sim. Essas proposições podem coexistir. O direito de responsabilidade civil, contratual, de privacidade e de valores mobiliários pode atribuir consequências de forma diferente por jurisdição e queixoso, mas a engenharia não deve esperar que um slogan vença.

Um teste mensurável de responsabilidade partilhada

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

Os conselhos devem receber resultados, não inventários de funcionalidades. Medidas úteis incluem a percentagem de utilizadores humanos protegidos por MFA resistente a phishing, o número de utilizadores de serviço com capacidade de senha, a idade de cada exceção de recurso, a percentagem de contas com políticas de rede testadas, o número de identidades de contratantes privilegiados além do prazo de validade, o tempo mediano para alertar sobre origens desconhecidas, o tempo para suspender uma sessão de alta confiança e o tempo para produzir um pacote de exposição ao nível do campo.

A Snowflake deve publicar progresso agregado onde puder fazê-lo sem expor clientes. O compromisso da CISA contempla explicitamente estatísticas de adoção por utilizador e tipo de MFA. Uma declaração de que a MFA está disponível é menos informativa do que a distribuição de inícios de sessão apenas com senha ao longo do tempo. Uma declaração de que o Trust Center está ativado é menos informativa do que quantas conclusõ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 da notificação e a completude do pacote de evidência.

Os clientes devem exigir o mesmo rigor de si próprios. Um provedor não pode salvar uma organização que cria papéis amplos, ignora conclusões, mantém utilizadores contratantes antigos e não tem ninguém a atender o contacto de emergência. O objetivo de padrões mais fortes não é transferir a propriedade da segurança do cliente para a Snowflake. É tornar as omissões previsíveis menos prováveis de se tornarem roubo de dados em massa.

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

As evidências são suficientemente fortes para reconstruir um padrão de campanha, mas não todos os incidentes de vítimas.

O registo 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 a nível de campanha de indivíduos afetados, tabelas, registos ou bytes descarregados. Não mostra quais vítimas pagaram exigências de extorsão ou se a eliminação prometida ocorreu.

Não publica o tipo de utilizador, hierarquia de papéis, histórico de MFA, configuração de rede, proprietário do endpoint, sequência de sessão, colunas acedidas ou volume de exportação para cada organização. As conclusões sobre dispositivos de contratantes de várias investigações não devem ser atribuídas a todas as vítimas. A estatística de 79,7% de exposição de credenciais não deve ser transformada numa percentagem de vítimas.

Não estabelece uma vulnerabilidade de software, fuga entre inquilinos, comprometimento da plataforma de produção da Snowflake, roubo de uma credencial mestre do provedor ou acesso a todos os clientes da 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 os dados regionais cruzaram uma fronteira nacional em todos os incidentes. A arquitetura permitia acesso remoto e descarregamento local; a análise legal de transferência exigiria factos de origem, destino, titular de dados, contratuais e de jurisdição para cada cliente.

Não permite que os campos possíveis da Ticketmaster, o âmbito de detalhe de chamadas da AT&T ou qualquer contagem de fórum criminoso sejam generalizados a outros clientes. O documento da Live Nation não nomeou a Snowflake. O documento da AT&T não nomeou a Snowflake ou o UNC5537. A associação externa pode ser relevante para investigação adicional, mas os documentos devem ser citados pelo que realmente estabelecem.

Finalmente, a documentação atual da Snowflake não prova o funcionamento dos controlos em abril e maio de 2024. Alterações posteriores como MFA por padrão, proteção de senhas vazadas, deteçã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 deteção e eficácia independente permanece mais limitada do que as descrições de funcionalidades.

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

A campanha da Snowflake não é melhor compreendida como um concurso entre duas histórias absolutas. Uma história diz que a plataforma foi hackeada e o provedor falhou sozinho. 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.

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

Os clientes tinham o dever mais claro de governar os seus utilizadores, papéis, endpoints, contratantes e dados. A 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, detetar comportamento de campanha e fornecer evidências. Os atacantes tinham responsabilidade direta pelos atos criminosos. Os reguladores e tribunais devem avaliar os deveres legais com base nos factos e na lei aplicável a cada organização. Estas alocações sobrepõem-se porque os controlos se sobrepõem.

A direção do produto pós-campanha reconhece implicitamente a lacuna entre capacidade e resultado. A MFA por padrão para novos utilizadores humanos, a desativação de senhas vazadas, a política de autenticação mais forte, a migração de utilizadores de serviço e as conclusões do Trust Center aproximam a segurança da linha de base do provedor. Não apagam a responsabilidade do cliente. Tornam o sistema partilhado menos dependente de que cada administrador encontre e ative todas as opções corretas antes de uma senha roubada ser testada.

Esse é o teste de responsabilidade duradouro para uma plataforma de dados na nuvem. Assumir que um cliente vai perder um aviso, um dispositivo de contratante será infetado, uma credencial permanecerá válida e um atacante usará funções normais do produto. Depois perguntar se a predefinição bloqueia o login, outro portão rejeita a origem, o papel revela pouco, a exportação desencadeia intervenção e a evidência chega ao cliente a tempo. A responsabilidade partilhada é credível apenas quando o serviço permanece defensível após o erro previsível de uma das partes e quando ambas as partes podem provar o que fizeram antes e depois.