CloudTrail na AWS: boas práticas para auditoria e investigação
Sem CloudTrail bem configurado, investigar um incidente na AWS vira adivinhação. Veja o que registrar, proteger e como analisar.
O CloudTrail é a trilha de auditoria da AWS: ele registra quem fez o quê, quando e a partir de onde. Em uma investigação, é a primeira fonte consultada para reconstruir a linha do tempo de um incidente. O problema é que muitas contas só têm o histórico de eventos padrão dos últimos 90 dias, sem uma trilha persistente, sem cobertura de todas as regiões e sem proteção contra adulteração.
Este guia mostra como configurar o CloudTrail para que ele seja confiável no momento que mais importa: durante uma investigação. Abordamos tipos de evento, abrangência, integridade, criptografia e como transformar o volume de logs em algo investigável.
Trilha multi-region e organizacional
Crie uma trilha multi-region para capturar atividade em todas as regiões, inclusive nas que você não usa de propósito. Atacantes frequentemente operam em regiões esquecidas justamente porque ninguém olha para elas. Em ambientes com várias contas, uma trilha organizacional centraliza os eventos de toda a estrutura em um único destino controlado.
O destino dos logs deve ficar em uma conta separada e restrita, idealmente uma conta de log dedicada, para que um comprometimento na conta de produção não permita apagar a própria trilha.
Management events e data events
Management events registram operações de controle, como criar uma role, alterar uma política ou abrir um security group. Eles são o mínimo indispensável. Data events registram operações sobre dados, como leitura e escrita em objetos S3 ou invocações de Lambda, e têm volume e custo bem maiores.
A recomendação é manter management events sempre ativos e habilitar data events de forma seletiva, nos buckets e funções mais sensíveis. Ativar data events em tudo gera custo e ruído; ativar em nada deixa um ponto cego justamente onde os dados vivem.
Integridade, criptografia e análise
Habilite a validação de integridade dos arquivos de log. Ela gera arquivos de digest assinados que permitem provar que os registros não foram alterados ou removidos, algo essencial para que a evidência tenha valor. Criptografe os logs com uma chave KMS dedicada e restrinja quem pode usar essa chave.
Logs que ninguém consulta não ajudam. Direcione o CloudTrail para uma solução de análise, seja CloudWatch Logs, um data lake com Athena ou um SIEM, e crie consultas e alertas para eventos críticos: uso da conta root, desabilitar o próprio CloudTrail, criação de chaves de acesso e mudanças amplas de permissão.
Checklist prático
- Criar trilha multi-region para cobrir todas as regiões
- Centralizar logs em conta dedicada e restrita
- Manter management events sempre ativos
- Habilitar data events nos buckets e funções mais sensíveis
- Ativar validação de integridade dos arquivos de log
- Criptografar os logs com chave KMS dedicada
- Restringir quem pode parar, alterar ou apagar a trilha
- Definir retenção adequada ao seu requisito de investigação
- Encaminhar eventos críticos para alertas
- Testar uma investigação real para validar a cobertura
Boas práticas
- Trate desabilitar o CloudTrail como evento de alta severidade
- Separe a conta de log do ambiente de produção
- Use data events com critério, focando o que tem valor de dado
- Padronize consultas de investigação reutilizáveis
- Defina alertas para uso de root e mudanças de IAM
- Documente onde os logs ficam e como acessá-los sob pressão
Erros comuns
Depender apenas do histórico de eventos de 90 dias
Incidentes mais antigos ficam sem evidência e a investigação trava.
Trilha limitada a uma região
Atividade maliciosa em outras regiões passa despercebida.
Logs na mesma conta de produção, sem restrição
Quem compromete a conta pode apagar a própria trilha de auditoria.
Sem validação de integridade
Não é possível provar que os registros não foram adulterados.
Logs coletados mas nunca analisados
Eventos críticos não geram alerta e o tempo de detecção dispara.
Quando procurar apoio especializado
Estruturar coleta, retenção e detecção a partir do CloudTrail, e validar isso com uma investigação real, é trabalho de operação de segurança. A GUARDIASEC atua nisso dentro do serviço de Monitoramento e Resposta, definindo casos de uso de detecção e fluxos de investigação.
Perguntas frequentes
CloudTrail e CloudWatch são a mesma coisa?
Não. O CloudTrail registra chamadas de API e atividade administrativa da conta, respondendo quem fez o quê. O CloudWatch coleta métricas e logs operacionais de recursos e aplicações. Os dois se complementam: o CloudTrail pode enviar eventos para o CloudWatch Logs, onde se criam alertas.
Preciso habilitar data events em todos os buckets?
Não é recomendado. Data events em tudo geram volume e custo altos e muito ruído. O equilíbrio é manter management events sempre ligados e habilitar data events apenas nos buckets e funções que guardam dados sensíveis ou são críticos para a operação.
Quanto tempo devo reter os logs do CloudTrail?
Depende do seu requisito de investigação e de eventuais obrigações contratuais. Como referência, muitas organizações mantêm pelo menos um ano de retenção, com armazenamento de baixo custo para o histórico mais antigo. O importante é que a janela de retenção cubra o tempo típico entre um comprometimento e sua descoberta.
Como protejo o CloudTrail de ser desativado por um atacante?
Centralize os logs em uma conta separada, restrinja por IAM e SCP quem pode parar ou alterar a trilha, e crie um alerta de alta severidade para qualquer evento de desativação. A validação de integridade ajuda a provar adulteração, e a conta de log isolada evita que o comprometimento da produção apague a evidência.
Guias relacionados
Próximo passo
Vamos avaliar os riscos do seu ambiente?
Conte seu cenário e definimos juntos o escopo certo. O objetivo é reduzir caminhos prováveis de ataque e elevar a maturidade de segurança, sem promessas absolutas.