Snowflake fez do reparo verificável o teste da responsabilidade compartilhada na nuvem

Resumo

• A Mandiant relatou que todas as campanhas do Snowflake que ela tratou diretamente tiveram origem em credenciais de clientes comprometidas e não encontrou evidências de que o acesso não autorizado tenha sido decorrente de uma violação do ambiente corporativo do Snowflake. Seu relatório de campanha está emhttps://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion.
• A campanha ainda testou a responsabilidade do provedor porque o Snowflake controlava superfícies de autenticação, padrões de produto, diretrizes 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 o cliente, controles de origem de rede e métricas de adoção que mostram redução de risco na 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, inscrição em MFA em contas existentes, acesso de contratados, listas de permissão de rede, minimização de dados, privilégios de exportação e prontidão para investigação.

A plataforma não foi comprovadamente violada; a linha de base era permissiva

A primeira disciplina é manter o limite exato da campanha. 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 violação do ambiente corporativo do Snowflake. As orientações do Snowflake para clientes, amplificadas pela CISA emhttps://www.cisa.gov/news-events/alerts/2024/06/03/snowflake-recommends-customers-take-steps-prevent-unauthorized-access, também direcionaram os clientes a investigar o acesso não autorizado de usuários e fortalecer os controles de identidade e rede. O registro analisado não estabelece uma exploração da plataforma Snowflake, uma fuga entre locatários ou o roubo de uma credencial mestra do provedor.

Essa constatação negativa é importante porque molda a resposta imediata. Um cliente não deve esperar por uma correção do provedor se o problema ativo for uma credencial de usuário válida sem MFA, nenhuma lista de permissão de rede e privilégios amplos de função. O cliente precisa girar as credenciais, desativar 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. O Snowflake operava o endpoint de autenticação que aceitava essas senhas. Ele fornecia a capacidade de MFA e escolheu quando mudar o comportamento padrão. Ele expunha ou ocultava campos de telemetria. Ele fornecia controles de política de rede e descobertas do Trust Center. Ele podia ver sinais entre clientes que nenhum locatário individual podia ver. Ele podia depois 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 do Snowflake emhttps://www.sec.gov/Archives/edgar/data/1640147/000164014725000052/snow-20250131.htmafirma 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 arquivamento é uma representação da empresa, não uma adjudicação. No entanto, é relevante porque o próprio Snowflake divulgou que a campanha afetou o risco de negócios além de qualquer locatário individual. A responsabilidade compartilhada tornou-se uma questão de empresa pública.

A lente do artigo, portanto, não é "Snowflake violado" ou "clientes falharam sozinhos". É reparo verificável. Após uma campanha explorar um padrão previsível de acesso apenas com senha, credenciais antigas 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 com 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. Credenciais foram roubadas por malware infostealer de sistemas não pertencentes ao Snowflake, incluindo máquinas de contratados usadas para atividades pessoais em alguns casos. Essas credenciais permaneceram válidas, às vezes por anos. As contas não tinham MFA. As instâncias dos clientes não tinham listas de permissão de rede. Os invasores conectaram-se com clientes e ferramentas padrão, realizaram reconhecimento, selecionaram dados, prepararam resultados, compactaram arquivos e os recuperaram. O padrão usava funcionalidade de banco de dados suportada sob identidade não autorizada.

Essa distinção é central para o reparo. A criptografia em repouso não era a barreira decisiva. A documentação de criptografia de ponta a ponta do Snowflake emhttps://docs.snowflake.com/en/user-guide/security-encryption-end-to-enddescreve 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 invasor 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, o design de funções, o controle de exportação e a detecção.

O controle de acesso determinava o raio de explosão após o login. A visão geral de controle de acesso do Snowflake emhttps://docs.snowflake.com/en/user-guide/security-access-control-overviewdescreve funções, privilégios, propriedade e hierarquia. Uma credencial roubada com acesso restrito é diferente de uma com privilégios amplos de leitura ou administração de conta. Uma conta de serviço construída para um pipeline é diferente de um administrador contratado. O menor privilégio não é um slogan; é a diferença entre uma sessão hostil retornando uma visão e uma sessão hostil percorrendo 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 confidenciais do Snowflake emhttps://docs.snowflake.com/en/user-guide/classify-introconecta a descoberta de colunas confidenciais 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 fluxos de trabalho de modelos. Mas uma sessão incomum criando estágios temporários, exportando grandes resultados e baixando-os de uma origem desconhecida 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, interruptíveis.

A 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 ativar o MFA, e muitos não o fizeram. Um provedor pode verdadeiramente dizer 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 do Snowflake emhttps://www.snowflake.com/en/blog/multi-factor-identification-default/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 os 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 é um 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 com 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 proporção de usuários humanos sem MFA, usuários humanos privilegiados sem MFA, usuários de senha com datas de último login antigas, 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ítica de autenticação do Snowflake emhttps://docs.snowflake.com/en/user-guide/authentication-policiesdá aos administradores controles sobre métodos de autenticação, clientes, provedores de identidade e inscrição em MFA. Sua documentação de autenticação por par de chaves emhttps://docs.snowflake.com/en/user-guide/key-pair-authdá às contas de serviço uma alternativa às senhas estáticas. Esses controles colocam deveres sobre os clientes, mas também definem a superfície de reparo do provedor: o produto deve tornar os bons padrões mais fáceis, as más exceções visíveis e a migração menos arriscada.

As diretrizes de identidade digital do NIST emhttps://pages.nist.gov/800-63-4/sp800-63b.htmlajudam 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 do 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 giram e podem ser desativadas sem personificar uma pessoa.

O 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 reuso de senhas. É fazer com que senhas conhecidas roubadas parem de funcionar. O anúncio de dezembro de 2024 do Snowflake emhttps://www.snowflake.com/en/blog/leaked-password-protection/disse que desativaria automaticamente senhas detectadas na dark web por meio de um processo de preservação de 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ário 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, comparar 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 atritos de suporte ou soluções alternativas 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 emhttps://www.cisa.gov/sites/default/files/2024-05/CISA%20Secure%20by%20Design%20Pledge_508c.pdfenquadra essa distinção. Pede aos fabricantes que avancem 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 do Snowflake emhttps://www.snowflake.com/en/blog/snowflake-cybersecurity-cisa-secure-by-design/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.

A política de rede era 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 do Snowflake emhttps://docs.snowflake.com/en/user-guide/network-policiesafirma 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 de contratados gerenciados e provedores de integração aprovados. O Snowflake não pode adivinhar todos os caminhos válidos sem quebrar o serviço. Mas o 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 contornam, 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 invasor 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 cliente 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 trabalhos de serviço. Simulação, implantação gradual, 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.

A 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 foi movido. A documentação atual do Snowflake descreve várias visualizações que podem apoiar esse trabalho.

LOGIN_HISTORY emhttps://docs.snowflake.com/en/sql-reference/account-usage/login_historyfornece tentativas de login com IP de origem, cliente, sucesso e informações de fator. QUERY_HISTORY emhttps://docs.snowflake.com/en/sql-reference/account-usage/query_historyfornece atividade de consulta, usuário, função, texto da consulta, tamanho do resultado, linhas descarregadas e bytes enviados pela rede. ACCESS_HISTORY emhttps://docs.snowflake.com/en/sql-reference/account-usage/access_historypode ajudar a reconstruir o acesso a objetos e colunas para edições elegíveis. A documentação do Trust Center emhttps://docs.snowflake.com/en/user-guide/trust-center/overviewdescreve 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 sistema de tickets. 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 à 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 o Snowflake notifica um cliente potencialmente exposto, o cliente deve receber identificadores de conta, usuários, carimbos de data/hora, redes de origem, status do primeiro e segundo fatores, 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 estavam 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. Não 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. O 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.

A localidade dos dados parou no acesso

A escolha de região do Snowflake pode importar para latência, resiliência, privacidade e aquisição. A documentação de regiões suportadas emhttps://docs.snowflake.com/en/user-guide/intro-regionsdiz 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 ao 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 é sustentável. A lição arquitetônica permanece: a localidade do armazenamento não é a localidade do acesso.

As orientações de compartilhamento entre regiões do Snowflake emhttps://docs.snowflake.com/en/user-guide/secure-data-sharing-across-regions-plaforms.htmlalertam os clientes para 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 assim incompleto após uma exportação.

O reparo da 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. O Snowflake controla ofertas de região, autenticação, ferramentas de rede, mecânicas 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 arquivamento de maio de 2024 da Live Nation emhttps://www.sec.gov/Archives/edgar/data/1335258/000133525824000081/lyv-20240520.htmdisse 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 supostos dados de usuário da empresa para venda. O arquivamento não nomeou o Snowflake nem forneceu uma contagem confirmada de pessoas afetadas.

A página de incidentes do Ticketmaster Canadá emhttps://help.ticketmaster.ca/hc/en-us/articles/26420491205009-Ticketmaster-Data-Security-Incidentdescreveu 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 o Snowflake como o provedor do Ticketmaster em uma briefng parlamentar emhttps://www.priv.gc.ca/en/privacy-and-transparency-at-the-opc/proactive-disclosure/opc-parl-bp/ethi_20251006/is_20251006/, ao mesmo tempo que indicou que a investigação permanecia aberta e que o Ticketmaster Canadá continuava sendo o controlador sob revisão.

O arquivamento de julho de 2024 da AT&T emhttps://www.sec.gov/Archives/edgar/data/732717/000073271724000046/t-20240506.htmdescreveu 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 arquivamento não nomeou o 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. Aproximadamente 165 organizações potencialmente expostas da Mandiant é 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 escopo 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 de 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 do Snowflake, evidência legível significa carimbos de data/hora em uma base de tempo, rótulos claros de usuário e função, separação da atividade confirmada da 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 invasores controlavam a atividade criminosa: usar credenciais roubadas, entrar nos ambientes dos 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 criavam usuários, atribuíam funções, escolhiam se usuários humanos podiam fazer login apenas com senhas, retinham credenciais antigas, permitiam acesso de contratados, deixavam algumas contas sem políticas de rede, concediam acesso a dados e governavam exportações. Um cliente cujo armazém de alto valor aceitava uma senha antiga de uma origem desconhecida sem MFA ou funções restritas não pode transferir toda a responsabilidade para o provedor.

O Snowflake controlava a linha de base e as ferramentas de reparo. Ele controlava se novos usuários humanos tinham MFA por padrão, se senhas vazadas eram desativadas pelo provedor, se configurações arriscadas apareciam no Trust Center, quais campos de telemetria estavam disponíveis, como os clientes eram notificados, como as orientações eram escritas e com que rapidez os controles pós-campanha eram lançados. 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 endpoints controlavam condições adjacentes. Dispositivos de contratados usados em vários clientes podem espalhar um incidente de infostealer em vários locatários de nuvem. Provedores de identidade podem aplicar 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 do Snowflake.

Reguladores, seguradoras e equipes de aquisição controlam incentivos. As orientações de cadeia de suprimentos do NIST emhttps://csrc.nist.gov/pubs/sp/1305/finalapoiam a definição de requisitos de fornecedor proporcionais à criticidade. Para um armazém 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 têm MFA padrão ou acesso federado mais forte, e a base instalada mostra uma parcela crescente de contas humanas e privilegiadas protegidas. Segundo, os usuários de serviço afastam-se de senhas estáticas em direção a pares de chaves, OAuth ou outras credenciais de carga de trabalho com escopo com rotação. Terceiro, a proteção de senhas vazadas relata eventos de desativação confirmados e tempo médio para desativar. Quarto, a cobertura da política de rede aumenta, especialmente para contas privilegiadas e estágios internos.

Quinto, as descobertas do Trust Center não são apenas exibidas, mas remediadas com proprietários de exceção e datas de validade. Sexto, a retenção e exportação de telemetria são suficientes para descoberta atrasada e escopo de privacidade. Sétimo, detecções de grandes descarregamentos e origens incomuns são ajustadas e encaminhadas a pessoas que podem agir. Oitavo, as notificações do provedor incluem evidências concretas de sessão, consulta, função, objeto e transferência. Nono, os clientes afetados podem mapear consultas a pessoas e categorias de dados regulados.

Décimo, os contratos dos clientes e as revisões de renovação incorporam 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. A ordem de fase de alegações no litígio multidistrital do Snowflake emhttps://www.govinfo.gov/content/pkg/USCOURTS-mtd-2_24-md-03126/pdf/USCOURTS-mtd-2_24-md-03126-34.pdfpermitiu que certas alegações prosseguissem enquanto as tratava sob padrões processuais. Isso não é uma constatação final de responsabilidade. Mostra que os tribunais podem examinar os padrões do provedor, a previsibilidade e a causalidade mesmo quando a história pública começa com credenciais do cliente.

O problema da base instalada

Os padrões seguros são mais eficazes no momento da criação. 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 do 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 precisa, portanto, de uma história de migração para a base instalada, não apenas uma história de novas contas.

O problema da base instalada tem várias camadas. Primeiro, usuários humanos antigos ainda podem autenticar 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 mal classificados como humanos ou humanos podem usar credenciais de estilo de serviço. Quarto, contratados podem reter acesso após o término de um projeto. Quinto, contas inativas ainda podem ter funções que alcançam dados confidenciais. Sexto, as integrações podem falhar se as regras de senha ou políticas de rede mudarem repentinamente.

O provedor pode reduzir esse atrito sem assumir o locatário do cliente. Ele pode mostrar aos administradores uma lista priorizada de identidades arriscadas, divididas por privilégio e alcance de dados. Ele pode fornecer políticas de simulação que mostram quem seria bloqueado por MFA ou restrições de rede. Ele pode exigir proprietários de exceção e datas de validade. Ele pode distinguir contas de emergência de contas legadas comuns. Ele pode fornecer auxílios de migração para usuários de serviço que migram para padrões de par de chaves ou OAuth.

Ele pode enviar lembretes repetidos do produto vinculados a risco real, em vez de banners genéricos.

Os clientes então têm que agir. Um cliente que recebe um painel mostrando usuários privilegiados apenas com 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 disso" possui escopo de função excessivo. A responsabilidade compartilhada torna-se concreta quando o provedor mostra a evidência e o cliente ou a remedia ou registra uma exceção responsável.

O registro de reparo deve separar três estados: remediado, exceção e desconhecido. Remediado significa que a condição arriscada se foi. Exceção 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 de desconhecidos a zero. A segurança pública muitas vezes pula essa distinção; o reparo verificável depende dela.

A evidência do cliente deve conectar logs técnicos a pessoas

O Snowflake pode expor telemetria técnica rica, mas a resposta de privacidade e legal requer uma ponte de objetos técnicos a 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 a 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, finalidade comercial, 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 do 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 vinculados a esses registros.

A evidência do provedor pode facilitar isso. 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 desativou posteriormente 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 atrasada 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 de amostra do login à consulta à 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, redesenha padrões ou entrega pacotes de evidências. Pode até fazer os clientes esconderem 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 pool 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. A disponibilidade de recursos é linguagem de fornecedor. A 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 incidentes 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 do titular de dados. Um cliente que detém dados pessoais regulados deve exigir pacotes de evidências 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 a análise de campo afetado dentro da janela necessária.

Isso não transfere todo o trabalho para o 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 atestados 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 permanece 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 em nível de ACCESS_HISTORY devido à edição, a renovação deve documentar se essa limitação é aceitável para os dados armazenados. Se as políticas de rede estão ausentes, a renovação deve identificar claramente o bloqueador operacional. O reparo deve ser revisado antes que a alavancagem desapareça em outro termo de contrato.

A evidência de renovação também deve separar a mudança de plataforma da mudança de locatário. O Snowflake pode enviar um padrão mais forte, mas a conta do cliente ainda pode conter usuários apenas com senha, funções amplas, contratados antigos e estágios não revisados. O comprador deve pedir o próprio livro de exceções da conta, não apenas o roteiro de produto do provedor. Essa distinção evita uma deriva familiar pós-incidente: o provedor anuncia um controle, os clientes presumem 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 afirmação de que "o MFA está disponível" não responde se a conta afetada o usou. Uma afirmação de que "as políticas de rede existem" não responde se a credencial roubada poderia alcançar dados de uma origem incomum. Uma afirmaçã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 do 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, as mudanças de produto pós-campanha não provam por si mesmas negligência antes das mudanças. Os 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, a 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 ser culpado 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 o MFA padrão e a 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. A evidência confirmada suporta uma campanha de credenciais de cliente, não uma violação da plataforma Snowflake. Mas a evidência também mostra 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 é crível apenas quando ambos os lados podem mostrar os portões que fecharam. Após esta campanha, o teste do Snowflake não é se pode dizer que o MFA existia.

É se menos senhas roubadas podem se tornar sessões, menos sessões podem alcançar dados amplos e mais clientes podem provar exatamente o que aconteceu antes que os dados saiam.