Resumo
- A Mandiant relatou que todos os incidentes da campanha Snowflake que tratou diretamente foram rastreados a credenciais de clientes comprometidas e não encontrou evidências de que o acesso não autorizado tenha origem em uma violação do ambiente empresarial da Snowflake. O relatório da campanha está emhttps://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion.
- A campanha ainda testou a responsabilidade do provedor porque a Snowflake controlava superfícies de autenticação, padrões de produto, orientações de segurança, telemetria de conta, ferramentas de política de rede, verificações do Trust Center e mudanças pós-campanha que nenhum cliente individual poderia criar sozinho.
- Reparo verificável significa mudança mensurável: MFA padrão para usuários humanos em novas contas, regras de senha mais fortes, desativação automática de senhas vazadas, pacotes de evidências para clientes, controles de origem de rede e métricas de adoção que mostram redução de risco em toda a base instalada.
- A responsabilidade do cliente continua substancial. Os clientes controlavam criação de usuários, concessões de funções, rotação de senhas, cadastro de MFA em contas existentes, acesso de contratados, listas de permissão de rede, minimização de dados, privilégio de exportação e prontidão para investigação.
A plataforma não foi demonstrada como violada; a linha de base foi demonstrada como permissiva
A primeira disciplina é manter o limite da campanha exato. O relatório da Mandiant de junho de 2024 afirmou que o acesso não autorizado nos incidentes que tratou veio de credenciais de clientes comprometidas e que não encontrou evidências de uma violação do ambiente empresarial da Snowflake. A orientação ao cliente da Snowflake, amplificada pela CISA em source: cisa.gov, direcionou igualmente os clientes a investigar o acesso não autorizado de usuários e a fortalecer os controles de identidade e rede.
O registro revisado não estabelece uma exploração da plataforma Snowflake, uma fuga entre locatários ou o roubo de uma credencial mestre do provedor.
Essa constatação negativa importa porque molda a resposta imediata. Um cliente não deve esperar por um patch do provedor se o problema ativo é uma credencial de usuário válida sem MFA, nenhuma lista de permissão de rede e amplos privilégios de função. O cliente precisa rotacionar credenciais, desabilitar contas, inspecionar o histórico de login e consultas, restringir redes de origem, revisar funções, preservar logs e notificar pessoas afetadas ou reguladores quando necessário.
O erro oposto é dizer que o provedor não tinha responsabilidade porque o primeiro segredo pertencia aos clientes. A Snowflake operava o endpoint de autenticação que aceitava essas senhas. Ela forneceu a capacidade de MFA e escolheu quando alterar o comportamento padrão. Ela expôs ou reteve campos de telemetria. Ela forneceu controles de política de rede e descobertas do Trust Center. Ela podia ver sinais entre clientes que nenhum locatário podia ver. Ela podia posteriormente construir proteção de senhas vazadas no serviço. Isso é controle real, mesmo que o cliente possuísse a conta.
O arquivo anual fiscal de 2025 da Snowflake em SEC source afirma a posição de responsabilidade compartilhada da empresa e descreve consequências legais, regulatórias e de reputação após a atividade de 2024. Um arquivo é uma representação da empresa, não uma adjudicação. No entanto, é relevante porque a própria Snowflake divulgou que a campanha afetou o risco de negócios além de qualquer locatário de cliente individual. A responsabilidade compartilhada tornou-se uma questão de empresa pública.
A lente do artigo, portanto, não é "Snowflake violada" ou "clientes sozinhos falharam". É reparo verificável. Após uma campanha explorar um padrão previsível de acesso apenas por senha, credenciais obsoletas de infostealer e restrições de rede ausentes, o provedor e os clientes precisam de evidências de que a próxima campanha semelhante terá menos credenciais viáveis, menos sessões apenas por senha, menos origens irrestritas, melhores alertas e entrega mais rápida de evidências.
O caminho da campanha usou funções comuns sob identidade hostil
A Mandiant descreveu uma cadeia prática. As credenciais foram roubadas por malware infostealer de sistemas não pertencentes à Snowflake, incluindo máquinas de contratados usadas para atividade pessoal em alguns casos. Essas credenciais permaneceram válidas, às vezes por anos. As contas não tinham MFA. As instâncias de clientes não tinham listas de permissão de rede. Os atacantes conectaram-se com clientes e ferramentas padrão, realizaram reconhecimento, selecionaram dados, prepararam resultados, compactaram arquivos e os recuperaram. O padrão usou funcionalidade de banco de dados suportada sob identidade não autorizada.
Essa distinção é central para o reparo. A criptografia em repouso não foi a barreira decisiva. A documentação de criptografia ponta a ponta da Snowflake em source: docs.snowflake.com descreve a criptografia em repouso e em trânsito, mas também explica que os dados devem ser usados durante as operações de tabela e podem ser descarregados e baixados por usuários autorizados. Um atacante que satisfaz a autenticação da conta e herda uma função pode pedir ao serviço resultados legíveis. A criptografia não substitui a garantia de identidade, design de funções, controle de exportação e detecção.
O controle de acesso determinou o raio de explosão após o login. A visão geral de controle de acesso da Snowflake em source: docs.snowflake.com descreve funções, privilégios, propriedade e hierarquia. Uma credencial roubada com acesso restrito é diferente de uma com amplos privilégios de leitura ou administração de conta. Uma conta de serviço construída para um pipeline é diferente de um administrador contratado. Menor privilégio não é um slogan; é a diferença entre uma sessão hostil retornar uma visão e uma sessão hostil percorrer as principais tabelas do cliente.
A classificação e mascaramento de dados podem reduzir a consequência. A documentação de classificação de dados sensíveis da Snowflake em source: docs.snowflake.com conecta a descoberta de colunas sensíveis com políticas de mascaramento e acesso a linhas. Isso não prova que os clientes afetados tinham tais controles. Mostra um caminho de reparo: os clientes devem identificar campos pessoais e regulados, expor visualizações em vez de tabelas brutas quando possível e separar funções de exportação de funções de leitura comuns.
O caminho de exfiltração observado também torna a exportação um controle por si só. Descarregamentos em massa são legítimos em uma plataforma de dados. Eles suportam análises, backup, processamento downstream e workflows de modelo. Mas uma sessão incomum criando estágios temporários, exportando grandes resultados e baixando-os de uma origem não familiar não é apenas "uma consulta". É um evento de movimentação de dados. O reparo deve tornar tais eventos mensuráveis, atribuíveis e, para conjuntos de dados de alto risco, interrompíveis.
Disponibilidade de MFA tornou-se resultados de MFA
O MFA estava disponível antes da campanha. As contas bem-sucedidas no relatório da Mandiant não o tinham. Essa lacuna é o coração da disputa de responsabilidade compartilhada. Um administrador de cliente poderia habilitar o MFA, e muitos não o fizeram. Um provedor pode dizer verdadeiramente que o controle estava disponível. Mas um provedor que vê muitas contas de alto valor ainda acessíveis apenas por senha não alcançou o resultado de segurança, apenas tornou a configuração disponível.
O anúncio de setembro de 2024 da Snowflake em source: snowflake.com moveu a postura do produto. Ele disse que o MFA seria aplicado por padrão para usuários humanos em contas criadas a partir de outubro de 2024 e que usuários de serviço não estariam sujeitos a esse requisito específico. Também anunciou requisitos de senha mais fortes para senhas de usuário recém-criadas e alteradas. Isso é reparo significativo porque muda o caminho padrão para contas futuras.
A distinção entre contas novas e existentes é igualmente significativa. Um padrão para contas futuras não remove automaticamente todos os caminhos apenas por senha na base instalada. Clientes existentes podem ter usuários legados, contas de serviço, contratados, contas de emergência e clientes mais antigos.
Um registro de reparo verificável deve, portanto, medir diretamente o risco legado: número e parcela de usuários humanos sem MFA, usuários humanos privilegiados sem MFA, usuários de senha com datas de último login desatualizadas, usuários com credenciais expostas conhecidas, contas de serviço usando senhas em vez de autenticação de carga de trabalho mais forte e exceções com proprietários de negócios e datas de validade.
A documentação de políticas de autenticação da Snowflake em source: docs.snowflake.com fornece aos administradores controles sobre métodos de autenticação, clientes, provedores de identidade e cadastro de MFA. Sua documentação de autenticação de par de chaves em source: docs.snowflake.com fornece às contas de serviço uma alternativa a senhas estáticas. Esses controles colocam deveres nos clientes, mas também definem a superfície de reparo do provedor: o produto deve tornar os bons padrões mais fáceis, as exceções ruins visíveis e a migração menos arriscada.
A orientação de identidade digital do NIST em source: pages.nist.gov ajuda a declarar o resultado. Senhas não são resistentes a repetição. Métodos resistentes a phishing ou criptograficamente vinculados reduzem o valor de uma senha roubada. Para clientes Snowflake, isso significa que administradores humanos devem migrar para identidade federada ou MFA forte, enquanto usuários de serviço devem usar credenciais de carga de trabalho com escopo que rotacionam e podem ser desabilitadas sem personificar uma pessoa.
Bloqueio de senhas vazadas tornou a responsabilidade compartilhada mensurável
O reparo mais direto do provedor após uma campanha de credenciais roubadas não é uma palestra sobre reutilização de senhas. É fazer com que senhas conhecidas roubadas parem de funcionar. O anúncio de dezembro de 2024 da Snowflake em source: snowflake.com disse que desativaria automaticamente senhas detectadas na dark web por meio de um processo que preserva a privacidade quando confirmadas como vazadas e ainda válidas. Esse controle aborda a vantagem central da campanha: credenciais roubadas muito antes de 2024 permaneciam aceitas pelo serviço.
A proteção de senhas vazadas não remove o dever do cliente. Os clientes ainda precisam de segurança de endpoint, governança de contratados, rotação de senhas, federação, design de usuários de serviço e menor privilégio. Mas muda a divisão do trabalho. Clientes individuais muitas vezes não conseguem ver o mercado global de infostealer tão bem quanto um provedor de nuvem pode. Um provedor pode comprar ou receber inteligência de ameaças, combinar credenciais expostas de forma controlada e desativar uma senha antes que cada cliente a descubra independentemente.
Esse é o tipo de controle em nível de provedor que transforma a responsabilidade compartilhada de uma cláusula em um comportamento do sistema.
A questão de evidência é adoção e desempenho. Quantas senhas vazadas válidas foram encontradas? Com que rapidez foram desativadas? Quantas pertenciam a usuários privilegiados? Quantas contas migraram de senha para par de chaves ou acesso federado? Quantos eventos de senha desativada levaram a atrito de suporte ou soluções inseguras? Quantos clientes ainda têm exceções? Sem métricas, a proteção de senhas vazadas continua sendo um bom anúncio. Com métricas, torna-se reparo verificável.
O compromisso Secure by Design da CISA em source: cisa.gov enquadra essa distinção. Ele pede aos fabricantes que vão além de controles opcionais em direção a resultados mensuráveis, como MFA padrão e métricas de adoção. O anúncio do compromisso de julho de 2024 da Snowflake em source: snowflake.com colocou a empresa dentro desse compromisso público. O compromisso é voluntário e não um veredito legal sobre a campanha. É relevante porque identifica o tipo de evidência que os clientes devem esperar após o evento.
Política de rede foi um segundo portão
A Mandiant identificou listas de permissão de rede ausentes como um fator recorrente. A documentação de política de rede da Snowflake em source: docs.snowflake.com afirma o padrão prático: sem uma política, os usuários podem conectar-se de qualquer computador ou dispositivo. Os clientes podem restringir o acesso por locais de rede permitidos ou bloqueados e usar padrões de conectividade privada para limites mais fortes.
O cliente é o ator mais bem posicionado para conhecer origens legítimas: escritórios, VPNs, cargas de trabalho em nuvem, desktops gerenciados de contratados e provedores de integração aprovados. A Snowflake não pode adivinhar todos os caminhos válidos sem quebrar o serviço. Mas a Snowflake controla se o acesso público irrestrito é silencioso ou visível. Um programa de reparo verificável deve relatar quais contas não têm políticas de rede, quais usuários privilegiados as ignoram, se o acesso a estágios internos é coberto e se as políticas realmente correspondem às origens aprovadas pelo negócio.
Os controles de rede não são suficientes sozinhos. Um atacante pode usar uma VPN aprovada, comprometer uma máquina de contratado já dentro de uma lista de permissão ou roubar um token após a autenticação. No entanto, a defesa deve ser em camadas. Uma senha roubada, sem MFA, sem restrição de rede, função ampla e exportação não monitorada é uma cadeia. Quebrar qualquer elo pode importar. O reparo é o processo de reduzir o número de ambientes de clientes onde todos os elos permanecem abertos juntos.
O provedor também deve tornar o gerenciamento de bloqueio seguro. Os administradores podem evitar políticas de rede porque temem bloquear usuários de negócios ou jobs de serviço. Simulação, implantação em fases, contatos de emergência, exceções temporárias e logs claros reduzem esse medo. Quanto melhor o caminho de migração, mais difícil é tratar políticas ausentes como comuns.
Telemetria é o limite da evidência
Após uma campanha de roubo de dados, os clientes precisam de mais do que garantias gerais. Eles precisam saber quem fez login, de onde, com qual fator, usando qual cliente, sob qual função, quais consultas foram executadas, quais objetos foram tocados, quais dados foram descarregados, quais estágios foram usados e quanto dado se moveu. A documentação atual da Snowflake descreve várias visualizações que podem suportar esse trabalho.
LOGIN_HISTORY em source: docs.snowflake.com fornece tentativas de login com IP de origem, cliente, sucesso e informações de fator. QUERY_HISTORY em source: docs.snowflake.com fornece atividade de consulta, usuário, função, texto da consulta, tamanho do resultado, linhas descarregadas e bytes enviados pela rede. ACCESS_HISTORY em source: docs.snowflake.com pode ajudar a reconstruir o acesso a objetos e colunas para edições elegíveis. A documentação do Trust Center em source: docs.snowflake.com descreve verificações de postura e detecções para MFA, políticas de rede, logins arriscados, endereços IP incomuns e grandes transferências.
Essas são capacidades. Capacidade não é prova de prontidão para investigação. Os clientes devem ter direitos para consultar as visualizações, exportá-las para armazenamento de segurança durável, entender latência e retenção e correlacioná-las com dados do provedor de identidade, endpoint e ticketing. Diferenças de edição podem alterar a precisão do escopo em nível de campo. As visualizações do provedor podem ter atrasos que importam para contenção ativa. O texto da consulta sozinho pode não dizer a uma equipe de privacidade quais indivíduos foram representados, a menos que o cliente tenha mapas de dados.
O reparo verificável deve, portanto, incluir pacotes de evidências. Quando a Snowflake notifica um cliente potencialmente exposto, o cliente deve receber identificadores de conta, usuários, timestamps, redes de origem, status do primeiro e segundo fator, identificadores de cliente, identificadores de sessão e consulta, funções, objetos tocados, nomes de estágios, volume de descarregamento, confiança e contenção recomendada. Um rótulo como "potencialmente exposto" é aceitável como abertura, mas deve ser seguido por dados suficientes para o cliente decidir se informações pessoais estiveram envolvidas.
A intervenção do provedor também precisa de autoridade prévia. Um provedor de nuvem pode ver atividade suspeita antes do cliente, mas bloquear automaticamente uma sessão pode interromper a produção. Deixar de agir pode permitir o roubo. O reparo deve definir limites para suspensão temporária, contatos de emergência do cliente, preservação de evidências e substituição. Os clientes devem nomear contatos de segurança que possam agir a qualquer hora. A Snowflake deve medir o tempo desde o sinal entre clientes até o aviso ao cliente e o tempo desde o aviso até a contenção.
Localidade dos dados parou no acesso
A escolha de região da Snowflake pode importar para latência, resiliência, privacidade e aquisição. A documentação de regiões suportadas em source: docs.snowflake.com diz que uma conta é hospedada em uma região e que os dados permanecem lá, a menos que os usuários os copiem, movam ou repliquem explicitamente. Também afirma o limite chave: a escolha da região não limita o acesso do usuário à Snowflake.
A campanha transformou esse limite em um problema de soberania. As tabelas de um cliente podem ter sido armazenadas em uma região aprovada. Uma identidade válida ainda poderia conectar-se de outro lugar, consultar os dados, descarregá-los para um estágio e baixar uma cópia. A colocação da conta de origem não impediu o acesso remoto ou a exportação. O registro público da campanha não estabelece os países de origem e destino para cada vítima, portanto nenhuma conclusão legal transfronteiriça universal é apoiável. A lição arquitetônica permanece: localidade de armazenamento não é localidade de acesso.
A orientação de compartilhamento entre regiões da Snowflake em source: docs.snowflake.com alerta os clientes a confirmar restrições legais e regulatórias antes de replicar dados para outra região ou país. Essa orientação diz respeito ao movimento aprovado. A exportação orientada por credenciais é diferente porque pode criar uma cópia não controlada fora da região selecionada sem alterar a região da conta de origem. Um inventário de dados que registra apenas a região de origem pode ser preciso e ainda incompleto após uma exportação.
O reparo de soberania de dados precisa, portanto, de quatro camadas: onde os dados autoritativos são hospedados, quais identidades podem conectar-se de quais dispositivos e jurisdições, quais funções de movimento podem criar cópias e quais evidências existem após um incidente. A Snowflake controla ofertas de região, autenticação, ferramentas de rede, mecânica de exportação e telemetria. Os clientes controlam base legal, campos de dados, concessões de funções, aprovações de movimento e análise de notificação. Ambos os lados precisam de evidências em seu limite.
Casos de clientes mostram consequência, não uma contagem mestre única
A forma pública da campanha foi influenciada por divulgações de empresas afetadas. Cada registro deve permanecer dentro de seus próprios fatos.
O arquivo da Live Nation de maio de 2024 em SEC source disse que a empresa identificou atividade não autorizada em um ambiente de banco de dados em nuvem de terceiros contendo principalmente dados do Ticketmaster e que um ator criminoso posteriormente ofereceu dados de usuário da empresa alegados para venda. O arquivo não nomeou a Snowflake nem forneceu uma contagem confirmada de pessoas afetadas.
A página de incidente do Ticketmaster Canadá em source: help.ticketmaster.ca descreveu um banco de dados em nuvem de terceiros isolado, possíveis campos para alguns compradores de ingressos da América do Norte e o limite de que as contas de clientes do Ticketmaster não foram afetadas. O comissário de privacidade do Canadá posteriormente identificou a Snowflake como provedora do Ticketmaster em um briefing parlamentar em source: priv.gc.ca, ao mesmo tempo em que indicava que a investigação permanecia aberta e que o Ticketmaster Canadá continuava sendo o controlador em revisão.
O arquivo da AT&T de julho de 2024 em SEC source descreveu acesso não autorizado a um espaço de trabalho da AT&T em uma plataforma de nuvem de terceiros e exfiltração de registros de interação de chamadas e textos. O arquivo não nomeou a Snowflake. É útil para entender um incidente divulgado de espaço de trabalho em nuvem de terceiros e seus limites de campo, não como atribuição independente.
Esses exemplos não criam uma contagem de pessoas em toda a campanha. As aproximadamente 165 organizações potencialmente expostas da Mandiant são uma população de notificação, não uma contagem confirmada de vítimas, contagem de registros ou contagem de indivíduos afetados. Cada cliente tinha dados, funções, retenção, regiões e deveres de notificação diferentes. O reparo verificável deve ajudar cada cliente a definir seus próprios fatos, em vez de fazer um único número em nível de plataforma fazer todo o trabalho.
Uma nota de tipografia para pacotes de evidências
Quando os clientes recebem evidências de segurança em nuvem de alta gravidade, o layout pode decidir se a pessoa certa age rapidamente. Uma tabela de sessões, fatores, funções, objetos e transferências deve ser legível sob pressão. O seguinte bloco de tipografia pertence ao corpo público porque o design da evidência faz parte do reparo.
Para clientes Snowflake, evidência legível significa timestamps em uma base de tempo, rótulos claros de usuário e função, separação de atividade confirmada de suspeita, status de MFA visível e links diretos entre consultas, estágios, volume de transferência e armazenamentos de dados afetados. Uma exportação densa de logs pode ser completa, mas inutilizável. Um pacote de evidências conciso pode ser a diferença entre uma decisão rápida de contenção e uma análise de privacidade atrasada.
Responsabilidade por controle prático
Os atacantes controlavam a atividade criminosa: usar credenciais roubadas, entrar em ambientes de clientes, preparar dados, levá-los e tentar venda ou extorsão. Eles são responsáveis por essa conduta.
Os clientes controlavam muitos portões falhos. Eles criaram usuários, atribuíram funções, escolheram se usuários humanos poderiam entrar apenas com senhas, mantiveram credenciais obsoletas, permitiram acesso de contratados, deixaram algumas contas sem políticas de rede, concederam acesso a dados e governaram exportações. Um cliente cujo warehouse de alto valor aceitou uma senha antiga de uma origem não familiar sem MFA ou funções restritas não pode transferir toda a responsabilidade para o provedor.
A Snowflake controlava a linha de base e as ferramentas de reparo. Ela controlava se novos usuários humanos tinham MFA por padrão, se senhas vazadas eram desativadas pelo provedor, quais configurações arriscadas apareciam no Trust Center, quais campos de telemetria estavam disponíveis, como os clientes eram notificados, como a orientação era escrita e com que rapidez os controles pós-campanha eram enviados. Um provedor que vê o mesmo padrão entre locatários tem o dever de reduzir o padrão em escala, não apenas dizer a cada cliente para ler o manual.
Provedores de identidade, contratados e proprietários de endpoint controlavam condições adjacentes. Dispositivos de contratados usados entre clientes podem espalhar um incidente de infostealer para vários locatários de nuvem. Provedores de identidade podem impor fatores mais fortes e acesso condicional. Endpoints gerenciados podem manter credenciais fora de máquinas pessoais. Esses atores importam, mas não apagam os deveres do cliente e do provedor sobre a própria conta Snowflake.
Reguladores, seguradoras e equipes de aquisição controlam incentivos. A orientação de cadeia de suprimentos do NIST em source: csrc.nist.gov apoia a definição de requisitos de fornecedor proporcionais à criticidade. Para um warehouse de dados, isso significa que contratos e renovações devem pedir métricas de adoção de MFA, resposta a senhas vazadas, campos de pacote de evidências, garantias de retenção, tempo de notificação, escalonamento de suporte e controles de movimento regional. Um questionário de segurança que pergunta apenas se o MFA existe é muito superficial após esta campanha.
O que provaria reparo durável
O registro de reparo deve incluir pelo menos dez resultados.
Primeiro, todos os novos usuários humanos devem usar MFA padrão ou acesso federado mais forte, e a base instalada deve mostrar uma parcela crescente de contas humanas e privilegiadas protegidas. Segundo, usuários de serviço devem migrar de senhas estáticas para par de chaves, OAuth ou outras credenciais de carga de trabalho com escopo e rotação. Terceiro, a proteção de senhas vazadas deve relatar eventos de desativação confirmados e tempo médio para desativar. Quarto, a cobertura de política de rede deve aumentar, especialmente para contas privilegiadas e estágios internos.
Quinto, as descobertas do Trust Center não devem ser apenas exibidas, mas remediadas com proprietários de exceção e datas de validade. Sexto, a retenção e exportação de telemetria devem ser suficientes para descoberta tardia e escopo de privacidade. Sétimo, descarregamentos grandes e detecções de origem incomum devem ser ajustados e direcionados a pessoas que possam agir. Oitavo, as notificações do provedor devem incluir evidências concretas de sessão, consulta, função, objeto e transferência. Nono, clientes afetados devem poder mapear consultas para pessoas e categorias de dados regulados.
Décimo, os contratos dos clientes e revisões de renovação devem incorporar evidências, em vez de confiar na redação de responsabilidade compartilhada.
O litígio pode influenciar o registro, mas não deve substituir a evidência de controle. O despacho de fase de alegações no litígio multidistrital Snowflake em source: govinfo.gov permitiu que certas alegações prosseguissem sob padrões processuais. Isso não é uma constatação final de responsabilidade. Mostra que os tribunais podem examinar os padrões do provedor, previsibilidade e causalidade mesmo quando a história pública começa com credenciais de clientes.
O problema da base instalada
Padrões seguros são mais eficazes no momento da criação. Eles são mais difíceis em uma base instalada onde os clientes já têm automação, usuários de serviço, contratados, provedores de identidade, clientes antigos e contas de emergência. A mudança de MFA padrão da Snowflake para novas contas foi um passo material, mas o risco da campanha vivia fortemente em contas existentes com hábitos existentes. O reparo verificável, portanto, precisa de uma história de migração para a base instalada, não apenas uma história de nova conta.
O problema da base instalada tem várias camadas. Primeiro, usuários humanos antigos ainda podem autenticar-se diretamente com senhas porque a federação nunca foi concluída. Segundo, usuários privilegiados podem ter exceções porque os administradores temem bloqueio. Terceiro, usuários de serviço podem ser classificados erroneamente como humanos, ou humanos podem usar credenciais de estilo de serviço. Quarto, contratados podem reter acesso após o fim de um projeto. Quinto, contas inativas ainda podem ter funções que alcançam dados sensíveis. Sexto, integrações podem falhar se regras de senha ou políticas de rede mudarem repentinamente.
O provedor pode reduzir esse atrito sem assumir o locatário do cliente. Pode mostrar aos administradores uma lista priorizada de identidades arriscadas, dividida por privilégio e alcance de dados. Pode fornecer políticas de teste que mostrem quem seria bloqueado por MFA ou restrições de rede. Pode exigir proprietários de exceção e datas de validade. Pode distinguir contas de emergência de contas legadas comuns. Pode fornecer ajudas de migração para usuários de serviço que migram para padrões de par de chaves ou OAuth. Pode enviar lembretes de produto repetidos vinculados a risco real, em vez de banners genéricos.
Os clientes então precisam agir. Um cliente que recebe um painel mostrando usuários privilegiados apenas por senha e os deixa inalterados por meses possui esse risco residual. Um cliente que não pode dizer se uma conta de contratado ainda é necessária possui uma falha de governança de identidade. Um cliente que permite que uma conta de serviço leia tabelas brutas inteiras porque "o pipeline costumava precisar" possui escopo de função excessivo. A responsabilidade compartilhada torna-se concreta quando o provedor mostra a evidência e o cliente a remedia ou registra uma exceção responsável.
O registro de reparo deve separar três estados: remediado, exceto e desconhecido. Remediado significa que a condição arriscada desapareceu. Exceto significa que um proprietário de negócios a aceitou com controles compensatórios e uma data para revisão. Desconhecido significa que ninguém assumiu responsabilidade. Um programa maduro leva a contagem desconhecida em direção a zero. A garantia pública muitas vezes ignora essa distinção; o reparo verificável depende dela.
Evidência do cliente deve conectar logs técnicos a pessoas
A Snowflake pode expor telemetria técnica rica, mas a resposta de privacidade e legal requer uma ponte de objetos técnicos para pessoas e obrigações. Um identificador de consulta, nome de função ou caminho de estágio é apenas o começo. O cliente deve saber qual tabela continha quais campos pessoais, quais titulares de dados foram representados, quais regras de país ou estado se aplicam, quais deveres contratuais de notificação existem e quais sistemas downstream receberam cópias. Sem essa ponte, o cliente pode saber que bytes saíram, mas não sabe quem notificar.
Essa ponte deve ser preparada antes de um incidente. Os proprietários de dados devem manter inventários de campos para dados regulados, propósito de negócio, período de retenção, política de mascaramento e rotas de exportação aprovadas. As equipes de segurança devem saber onde os logs da Snowflake são retidos fora da plataforma e por quanto tempo. As equipes de privacidade devem poder pedir uma lista de tabelas afetadas e receber um mapeamento para categorias de pessoas e campos. As equipes jurídicas devem saber quais regiões e contratos de cliente estão anexados a esses registros.
A evidência do provedor pode tornar isso mais fácil. Se uma notificação incluir as funções exatas, objetos, estágios e volume, o cliente pode evitar uma busca ampla e lenta. Se o provedor também rotular se o MFA estava presente, se a origem era incomum e se a proteção de senhas vazadas posteriormente desativou a credencial, o cliente pode entender causa e contenção. Se o provedor der apenas conselhos gerais, o cliente deve reconstruir a evidência enquanto o relógio para notificação e resposta a extorsão já está correndo.
A campanha também expôs uma questão de retenção para a própria telemetria. Os históricos nativos podem cobrir um ano, mas disputas legais, descoberta tardia e consultas regulatórias podem se estender por mais tempo. Clientes de alto risco devem transmitir logs para um armazenamento de segurança independente com retenção alinhada às suas obrigações. Um provedor deve tornar essa exportação prática e documentada. O cliente deve provar que funciona reconstruindo periodicamente um caminho de acesso amostral do login até a consulta e a categoria de dados.
O reparo não pode depender da vergonha do cliente
Após uma campanha de credenciais, é tentador tratar clientes sem MFA como a lição da história. Isso é parcialmente verdadeiro e ainda insuficiente. Envergonhar publicamente os clientes não desativa senhas vazadas, não redesenha padrões nem entrega pacotes de evidências. Pode até fazer com que os clientes escondam configurações fracas até que um incidente force a divulgação.
O melhor modelo é o endurecimento progressivo. O provedor começa com visibilidade, depois padrões mais fortes, depois avisos direcionados, depois governança de exceções, depois aplicação para categorias de risco onde a consequência justifica. Os clientes recebem tempo e ferramentas de migração, mas também perdem a capacidade de deixar lacunas de alto risco invisíveis. As equipes de aquisição então pedem métricas de adoção e contagens de exceções, não apenas listas de recursos.
Essa abordagem reconhece que as plataformas de nuvem são sistemas operacionais compartilhados para dados de negócios. Um provedor que torna um padrão mais seguro pode aumentar brevemente o atrito do cliente, mas também reduz o conjunto de alvos disponíveis para grupos criminosos. Um cliente que aceita a aplicação pode precisar atualizar scripts ou identidades, mas ganha uma história mais forte para reguladores, seguradoras e titulares de dados. O reparo funciona quando ambos os lados podem apontar para condições alteradas, não para mensagens alteradas.
A aquisição deve exigir telemetria de reparo
Um comprador de uma plataforma de dados de alto valor deve tratar a telemetria pós-campanha como um requisito de aquisição. A questão não é apenas se o provedor agora oferece MFA, políticas de rede, controles de senhas vazadas e descobertas do Trust Center. A questão é se o comprador pode receber evidências de que esses controles estão ativos, completos e testados na própria conta do comprador. Disponibilidade de recurso é linguagem de fornecedor. Cobertura de controle é linguagem operacional.
O registro de aquisição deve pedir um relatório de cobertura de identidade, incluindo usuários humanos, usuários privilegiados, usuários de serviço, contas inativas, contratados externos, status de federação, status de MFA e exceções de senha. Deve pedir cobertura de rede por conta, classe de usuário, estágios internos e endpoints privados. Deve perguntar se a proteção de senhas vazadas está ativada, quais notificações de evento produz e como uma senha desativada é refletida nos registros de auditoria. Deve perguntar quais descobertas do Trust Center estão disponíveis no nível contratado e por quanto tempo o histórico relevante é retido.
Os termos de incidente devem ser igualmente concretos. Uma cláusula de notificação genérica é fraca após esta campanha. Os clientes precisam de prazos para notificação de alta gravidade, campos de evidência que serão incluídos, contatos de emergência, escalonamento de suporte, preservação de logs e cooperação no escopo dos titulares de dados. Um cliente que detém dados pessoais regulados deve exigir pacotes de evidência de amostra antes da renovação, não após o roubo. Um exercício de simulação pode testar se o provedor e o cliente podem passar de login suspeito para análise de campos afetados dentro da janela necessária.
Isso não transfere todo o trabalho para a Snowflake. O cliente deve manter seus próprios mapas, reter logs e conhecer suas obrigações de privacidade. Mas o provedor controla muitos fatos necessários para que o mapa se torne utilizável. Um processo de aquisição que pede apenas atestações perderá a questão operacional. Um processo que pede telemetria de reparo revelará se a responsabilidade compartilhada está pronta para a próxima campanha.
A mesma evidência deve aparecer nas renovações. Se um cliente permanecer em acesso pesado de senha um ano após a campanha, a renovação deve forçar uma exceção nomeada ou uma migração financiada. Se um cliente não pode receber detalhes de ACCESS_HISTORY devido à edição, a renovação deve documentar se essa limitação é aceitável para os dados armazenados. Se políticas de rede estão ausentes, a renovação deve identificar claramente o bloqueio operacional. O reparo deve ser revisado antes que a alavancagem desapareça em outro termo contratual.
A evidência de renovação também deve separar a mudança de plataforma da mudança de locatário. A Snowflake pode enviar um padrão mais forte, mas a conta do cliente ainda pode conter usuários apenas por senha, funções amplas, contratados desatualizados e estágios não revisados. O comprador deve pedir o livro de exceções da própria conta, não apenas o roadmap de produto do provedor. Essa distinção evita uma deriva familiar pós-incidente: o provedor anuncia um controle, os clientes assumem que o risco mudou e a base instalada permanece materialmente exposta.
Para conselhos e equipes de privacidade, esse registro em nível de locatário é a ponte entre reparo técnico e confiança legal. Uma alegação de que "MFA está disponível" não responde se a conta afetada o usou. Uma alegação de que "políticas de rede existem" não responde se a credencial roubada poderia alcançar dados de uma origem incomum. Uma alegação de que "a telemetria é retida" não responde se a organização pode mapear consultas para campos regulados. O reparo verificável vive nessas respostas específicas da conta.
O que não inferir
Um relato contido deve evitar quatro saltos. Primeiro, a campanha não prova que a plataforma de produção da Snowflake foi violada. Segundo, não prova que toda organização notificada perdeu dados. Terceiro, não prova que todo cliente afetado tinha os mesmos campos, pessoas ou deveres legais. Quarto, mudanças de produto pós-campanha não provam por si mesmas negligência antes das mudanças. Produtos de segurança evoluem após incidentes por muitas razões, incluindo melhor inteligência de ameaças e padrões alterados.
Ao mesmo tempo, contenção não exige silêncio sobre o dever do provedor. Um provedor pode estar livre de uma constatação de violação de plataforma e ainda ser responsável pelo design padrão, qualidade da telemetria e avisos entre clientes. Um cliente pode estar em falta por controles de identidade fracos e ainda precisar dos dados do provedor para investigar. Uma ordem de litígio pode ser não final e ainda mostrar que MFA padrão e previsibilidade serão examinados. A responsabilidade equilibrada mantém todas essas proposições vivas ao mesmo tempo.
A avaliação final é de alto impacto e alta confiança. As evidências confirmadas suportam uma campanha de credenciais de clientes, não uma violação da plataforma Snowflake. Mas as evidências também mostram por que os padrões do provedor, a telemetria e a automação de segurança entre clientes fazem parte da responsabilidade. A responsabilidade compartilhada é credível apenas quando ambos os lados podem mostrar os portões que fecharam. Após esta campanha, o teste da Snowflake não é se ela pode dizer que o MFA existia.
É se menos senhas roubadas podem tornar-se sessões, menos sessões podem alcançar dados amplos e mais clientes podem provar exatamente o que aconteceu antes de os dados saírem.