O Snowflake Business Critical inclui um Trust Center e scanners de segurança ativos desde a abertura da conta. É uma base útil, mas incompleta: o Trust Center cobre cerca de 60% do que a sua equipe de DBA precisa monitorar. Os 40% restantes ficam no seu perímetro.
Se você é responsável de dados, DBA ou CISO numa conta Business Critical, este artigo descreve como estruturar a sua postura de segurança: um plano de maturidade em três fases, os controles a implantar e um modelo de RACI que reparte com clareza as responsabilidades entre as equipes.
1. O Shared Responsibility Model, a linha que muda tudo
Snowflake é um SaaS, não um IaaS. Isso significa que a plataforma cuida da infraestrutura, do patching, da criptografia at-rest e da disponibilidade. Você cuida de tudo o que diz respeito aos seus usuários, aos seus papéis e aos seus dados.
Essa repartição cabe em duas colunas, separadas por uma fronteira contratual.
Esquema 1 · Shared Responsibility Model da Snowflake
A Snowflake protege a plataforma, você protege o seu uso. Essa fronteira é fixada por contrato.
Essa fronteira define quem carrega a responsabilidade em caso de incidente. Uma conta ACCOUNTADMIN compartilhada entre quatro pessoas está no seu perímetro, não no da Snowflake.
2. O que o Trust Center realmente cobre
O Trust Center, disponível em GA desde o fim de 2024, é um console integrado ao Snowsight que varre em contínuo a configuração da sua conta e levanta alertas. Dois componentes para distinguir.
Esquema 2 · Os dois componentes do Trust Center
Scanners = conformidade de configuração. Alerts = detecção de eventos anormais. Os dois são úteis. Nenhum dos dois substitui um SIEM.
Na edição Business Critical, aparecem três scanners adicionais: Tri-Secret Secure, Customer Managed Keys, Private Link. Esses três não vêm ativados por padrão, mesmo em Business Critical. É preciso ir atrás deles.
Esse ferramental é útil, mas limitado em quatro dimensões.
Limite 1
Sem correlação com o seu SI. Uma conexão suspeita na Snowflake às 3h da manhã, a partir de um IP desconhecido, não será cruzada com um evento de AD ou com um ticket de ITSM. É preciso um SIEM externo (Splunk, Sentinel, Elastic, Datadog, QRadar) que ingira os logs via ACCOUNT_USAGE ou Snowpipe.
Limite 2
A classificação dos dados não é nativa. O Trust Center não sabe se a sua coluna customer_email deve ser mascarada. É preciso declarar isso por meio de tags e de policies SQL (CREATE MASKING POLICY, CREATE ROW ACCESS POLICY).
Limite 3
Rastreabilidade fina das mudanças de policies, limitada. Se alguém alterar uma masking policy em produção, você vê isso em ACCOUNT_USAGE.ACCESS_HISTORY, não no Trust Center.
Limite 4
A remediação continua manual. O scanner detecta um ACCOUNTADMIN inativo há 90 dias e não o desativa. Você precisa manter um workflow operacional rodando por trás, e documentá-lo.
Para reter
O Trust Center é uma base excelente. Ele não substitui um SIEM, nem uma política de classificação dos dados, nem um RACI. É um bloco, não uma solução completa.3. Plano de maturidade: três fases sucessivas
É nesta ordem que se protege uma conta Snowflake. Fase 1 em 2 a 4 semanas, Fase 2 em 2 a 3 meses, Fase 3 daí em diante.
Esquema 3 · Plano de maturidade em 3 fases
Três fases que se sucedem nessa ordem. A Fase 1 elimina o essencial do risco; as fases seguintes só entregam valor depois que a Fase 1 está estabilizada.
Fase 1: Quick wins (2 a 4 semanas)
As ações que eliminam 70% do risco com um esforço limitado. MFA obrigatório para todos os usuários humanos, sem exceção. Network policies restritivas sobre ACCOUNTADMIN e as contas de serviço, com whitelist de IP por padrão. Revisão das contas ACCOUNTADMIN (objetivo de 2 a 3 no máximo, nunca uma só, para evitar lockout). Ativação do Trust Center com todos os scanners padrão. Rotação das chaves RSA das contas de serviço a cada 90 dias. São controles de base, ainda ausentes em muitas contas em produção.
Fase 2: Operacional (2 a 3 meses)
A gente sai do checklist inicial para o regime de run operacional. Integração dos logs da Snowflake no SIEM: ACCOUNT_USAGE.LOGIN_HISTORY, QUERY_HISTORY, ACCESS_HISTORY. Retenção nativa da Snowflake: 365 dias. Se você precisar de mais (SOC 2 = 7 anos), externalize para o S3 ou equivalente por meio de tarefas agendadas. Alertas de negócio sob medida, além dos do Trust Center: download massivo de dados sensíveis, consulta que cruza mais de 3 tabelas com PII, uso de um warehouse fora da janela de horário, exportação para um stage externo. Tri-Secret Secure ativado se a conformidade SOC 2 exigir. Private Link para as conexões a partir do seu VPC.
Fase 3: Governança avançada (longo prazo)
Dynamic Data Masking: policies aplicadas automaticamente conforme o papel. Um analista de marketing vê j***@****.fr, um comercial sênior vê o e-mail completo. A consulta SQL é idêntica, o resultado muda conforme o papel. Row Access Policies: o mesmo princípio, mas por linha. Um comercial da região Sul vê apenas os clientes da região Sul, sem que o SQL da aplicação precise saber disso. Revisão anual do Shared Responsibility Model com a equipe de segurança, porque os serviços novos (Snowpark, Cortex, Native Apps) redefinem a fronteira.
4. Cobrir o que o Trust Center não vê
Com os três blocos no lugar (Trust Center, SIEM externo, policies SQL), a matriz de cobertura fica clara. Aqui está o que cobre o quê.
Esquema 4 · Matriz de cobertura da segurança Snowflake
Três blocos complementares. Nenhum cobre sozinho o perímetro inteiro; a cobertura completa se atinge com os três no lugar, uma vez entregue a Fase 3.
5. O que monitorar, com que frequência e por quem
Aqui está a síntese dos controles, da frequência de cada um e de quem responde por eles.
Cada linha precisa ter um responsável nomeado, não uma equipe genérica, e um suplente identificado. Se o responsável principal estiver ausente no momento em que um alerta cair, a passagem já está prevista.
6. Sem RACI, nada se sustenta
Último bloco, e de longe o mais estruturante. Numa conta Snowflake Business Critical, pelo menos sete papéis intervêm: Data Office, equipe de plataforma de dados, arquitetura, operação, infraestrutura, DBA, rede e segurança, com o CISO como aprovador nas decisões sensíveis. Sem um RACI formalizado, cada alerta do Trust Center acaba num ticket sem dono.
Estruturar o RACI em três eixos.
Por atividade. Em geral, de 15 a 20 atividades: gestão das contas, network policies, masking policies, revisão dos logs, integração com SIEM, conformidade SOC 2, gestão de incidentes, revisão dos acessos, rotação das chaves, documentação. Cada atividade tem um R (responsável), um A (aprovador), C (consultados) e I (informados).
Por fase do plano de maturidade. Fase 1 = DBA como R, CISO como A. Fase 2 = DBA e equipe de segurança como R, Data Office como C. Fase 3 = Data Office como R, DBA como C.
Por criticidade do alerta. Alerta crítico: escalada ao CISO em até 2 horas. Warning: tratamento em até 48 horas pelo DBA. Informational: revisão semanal.
Regra operacional
O RACI não é um documento para guardar na gaveta. É o primeiro entregável que precisa sair de uma iniciativa de proteção da Snowflake. Sem ele, todos os outros blocos caem no primeiro turnover.Partir para a ação
Proteger uma conta Snowflake Business Critical não se faz ativando o Trust Center e marcando as caixas dos scanners padrão. Faz-se em três fases, com um SIEM externo para a correlação, policies SQL para o dado sensível e um RACI que nomeia pessoas.
Na Bomzai, a gente acompanha equipes de dados exatamente nesses temas. Auditoria do Shared Responsibility Model na sua conta, implantação do plano de maturidade, integração com SIEM, RACI operacional assinado pelas equipes. Com a meta de entrar em produção em até três meses.
