Quando você consulta SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY ou ACCESS_HISTORY, você vê exatamente os últimos 365 dias. Nem um dia a mais. Essa retenção é codificada diretamente no share SNOWFLAKE que a Snowflake mantém para cada conta. Ela não é exposta como parâmetro, e não se negocia com seu Account Executive.
Para uma equipe de Data que gerencia o Snowflake como um data warehouse analítico clássico, isso não é bloqueante. Para uma equipe que precisa provar a um auditor quem acessou determinada tabela de dados de saúde há dois anos e meio, é uma barreira.
O teto de 365 dias não é negociável
Retenção curta demais. 365 dias frente aos 3 anos mínimos esperados em auditoria RGPD e aos prazos mais longos que certos reguladores setoriais exigem. O referencial ISO 27001 (controle A.12.4) não impõe um número, mas exige que os logs sejam conservados "por um período apropriado" e protegidos contra modificação. 365 dias, para um auditor, raramente é "apropriado".
Custo de compute oculto. Cada consulta ao ACCOUNT_USAGE consome créditos do warehouse que a executa. Em pequena escala não se percebe. A partir do momento em que se industrializam dashboards FinOps ou jobs de detecção de anomalias que escaneiam QUERY_HISTORY a cada hora, a linha orçamentária se torna visível.
Sem alertas nativos. As views ACCOUNT_USAGE são reativas. Para detectar que um usuário elevou seus privilégios há 20 minutos, é preciso consultar a view, comparar com uma baseline, disparar um alerta. Nada disso existe no Snowflake. É necessária uma camada externa, ou um SIEM.
Logs isolados. Esses logs vivem no Snowflake, consultáveis apenas em SQL. Sua equipe de cybersegurança trabalha com Elastic, Splunk ou um SIEM gerenciado. Ela não vai aprender Snowflake para correlacionar três eventos de acesso.
Veredicto Permanecer no
ACCOUNT_USAGEcomo única fonte da verdade para auditoria é fazer o Data Warehouse assumir um papel de sistema de registro legal para o qual ele não foi projetado. A externalização dos logs não é uma otimização. É um projeto de compliance por si só.
O que exportar, em que ordem
Existem cerca de vinte views no ACCOUNT_USAGE. Exportar tudo é um erro: custo de armazenamento desnecessário, complexidade de manutenção, e sobretudo ruído que afoga o sinal. Aqui está a triagem que aplicamos em nossos clientes.
A base P0 cobre 80% dos casos de auditoria: quem se conectou, quem consultou o quê, quem leu qual dado sensível. É a tríade que colocamos em produção primeiro. O P1 vem imediatamente depois porque os auditores ISO 27001 pedem sistematicamente a rastreabilidade dos privilégios, e o rastreamento do Cortex se torna crítico assim que você abre as funções de IA nativas do Snowflake para as equipes de negócio. O P2 espera até que uma necessidade FinOps concreta apareça.
A arquitetura que funciona
O padrão que funciona em produção: o Snowflake envia seus logs para um bucket S3 imutável, via uma Scheduled Task que dispara um COPY INTO em um external stage. O consumidor final, seja um SIEM, Athena para auditoria interna ou uma ferramenta de FinOps, lê o S3. O Snowflake não sabe quem consome, e não se importa.
Diagrama - Fluxo de exportação dos logs Snowflake para S3
Exportação feita pelo Snowflake, supervisionada pelo orquestrador, consumida por N ferramentas. O bucket é o único ponto de contato.
Exportação a partir do Snowflake. O padrão correto: uma Scheduled Task Snowflake disparada a cada hora, que executa um COPY INTO @external_stage para o S3. O external stage aponta para o bucket com uma storage integration configurada (IAM role assumido pelo Snowflake). O delta é feito via uma tabela de watermark mantida internamente, que armazena o timestamp da última exportação por view. Isso evita duplicatas e torna o job idempotente.
Custo do lado Snowflake: zero créditos. A view ACCOUNT_USAGE é lida por um warehouse, sim, mas usamos um XS dimensionado para rodar alguns segundos por hora. Em um mês, o gasto é inferior ao ruído estatístico do dashboard de consumo.
Armazenamento imutável (WORM). O bucket S3 é configurado em Object Lock mode Compliance. Nem mesmo a conta root da AWS pode excluir um objeto antes da expiração de seu período de retenção. Não é um recurso decorativo: é exatamente o que a ISO 27001 A.12.4.2 exige. Versioning ativado, MFA delete na configuração do bucket, e CloudTrail rastreando quem lê o quê no bucket. Os logs dos logs, sim.
Orquestração e supervisão. A Task Snowflake pode rodar sozinha, mas sempre a supervisionamos a partir de um orquestrador externo (VTOM, Airflow, n8n conforme a plataforma do cliente). Três alertas a configurar: falha de exportação, lag excedido, e volume anormalmente baixo (a Task rodou mas não escreveu nada, frequentemente é uma falha silenciosa de privilégios ou stage).
As três armadilhas que ninguém menciona no kickoff
Armadilha 1: o lag do ACCOUNT_USAGE é estrutural. As views ACCOUNT_USAGE têm uma latência de aproximadamente 45 minutos, com picos documentados de até 3 horas dependendo da carga. Se sua necessidade é detecção de intrusão em tempo real, essa arquitetura não a proporcionará. É preciso usar as Event Tables do Snowflake para os fluxos mais críticos, ou aceitar que a janela de detecção será de T+1h no mínimo. A escolha deve ser explícita e arbitrada com a equipe de cyber. Não se descobre essa restrição na fase de homologação.
Armadilha 2: o formato de arquivo depende do consumidor. Parquet é o formato padrão do lado Snowflake: nativo, compactado, ideal para S3 e Athena. Mas se seu SIEM só consegue ler JSON linha por linha ou CSV, você adiciona uma camada de transformação que não estava no plano. Antes de escrever uma linha de código, valide por escrito o formato esperado por cada consumidor. É uma questão de 15 minutos que evita 3 semanas de retrabalho.
Armadilha 3: QUERY_TEXT contém SQL bruto, portanto potencialmente PII. Um desenvolvedor que faz um WHERE email = 'jean.dupont@example.fr' acabou de escrever um dado pessoal em texto claro no QUERY_HISTORY. Esse dado vai para o S3 e se torna imutável via Object Lock. Há duas alternativas: mascarar ou hashear o conteúdo de QUERY_TEXT na exportação (perde-se valor de auditoria), ou documentar explicitamente junto ao DPO que os logs de auditoria se enquadram no motivo legítimo de compliance e não estão sujeitos ao direito ao apagamento. A segunda alternativa é juridicamente válida, mas deve ser formalizada por escrito antes da colocação em produção.
A arbitrar com o CISO antes do desenvolvimento Duração de retenção alvo (3 anos mínimo, frequentemente 7 a 10 anos para setores regulados). Formato de arquivo aceito pelo SIEM. Política de hashing ou mascaramento de
QUERY_TEXT. Ownership da chave KMS (equipe de Data ou equipe de Segurança). Sem essas quatro decisões formalizadas, não inicie a implementação.
Custo real, dimensionamento real
Para uma conta Snowflake de porte médio que gera aproximadamente 10 milhões de linhas de QUERY_HISTORY por mês:
O custo global em um ano completo fica abaixo de 200 euros/mês para a maioria das contas Snowflake de porte médio. É o argumento mais simples a apresentar em comitê: pelo equivalente a um almoço por semana, entramos em conformidade, saímos dos 365 dias, e tornamos os logs exploráveis pela cadeia de cybersegurança.
A regra que aplicamos em nossos clientes
Externalização dos logs Snowflake, três decisões tomadas desde o kickoff, nesta ordem. Duração de retenção validada pelo CISO e pelo DPO. Formato de arquivo validado com o consumidor final. Política de QUERY_TEXT (texto claro, mascarado, hasheado) decidida juridicamente. Depois, e somente depois, escrevemos a primeira linha de código.
Os projetos que falham nesse tema nunca caem por causa da técnica. Caem por um auditor que pede após 18 meses uma duração de retenção diferente, por um SIEM que não consegue ler o formato escolhido, ou por um DPO que descobre que os logs contêm PII não declarados. A base técnica se resolve em duas semanas. O enquadramento é 80% do sucesso.
