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, imutabilidade, criptografia, quais eventos merecem alerta imediato 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. Endureça a política do bucket de destino para negar exclusão e negar escrita fora do CloudTrail, e considere o Object Lock em modo de conformidade para tornar os arquivos imutáveis pelo período de retenção. Um log que pode ser apagado por quem comprometeu a conta perde justamente o valor que deveria ter.
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. O CloudTrail Lake é a opção gerenciada da própria AWS: um repositório com retenção longa e consultas em SQL, útil quando você quer investigar sem montar a infraestrutura de análise por conta própria.
Eventos que merecem alerta imediato
A cobertura só vira detecção quando alguns eventos disparam alerta em vez de ficarem esperando por uma consulta manual. Um conjunto pequeno e bem escolhido evita a fadiga de alertas e cobre os sinais mais associados a comprometimento e a tentativa de apagar rastros.
- Uso da conta root, que deveria ser raríssimo
- StopLogging ou exclusão e alteração de uma trilha do CloudTrail
- Criação de access keys e de novos usuários com privilégio
- Mudança em política de confiança de role ou anexação de políticas amplas
- Desativação de GuardDuty, Config ou de chaves KMS
- Alterações em SCP e na estrutura da organização
Trate a desativação da própria trilha como o alerta de maior severidade, porque costuma ser o primeiro passo de quem quer operar sem deixar registro. Encaminhe esses eventos para um canal com dono e prazo de resposta, não apenas para um painel que ninguém acompanha.
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
- Tornar os arquivos imutáveis com política restritiva e Object Lock no bucket
- 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
- Alertar sobre desativação da trilha, uso de root e mudanças de IAM
- 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, o Object Lock no bucket impede apagar os arquivos antes do prazo, e a conta de log isolada evita que o comprometimento da produção alcance a evidência.
Qual a diferença entre CloudTrail Lake e enviar logs para o Athena?
Os dois permitem consultar eventos em SQL, mas o CloudTrail Lake é totalmente gerenciado: você define a retenção e consulta sem montar bucket, catálogo e tabelas por conta própria. A abordagem com S3 mais Athena dá mais controle e costuma sair mais barata em grande volume, ao custo de operar essa infraestrutura. Para muitas equipes, o Lake reduz o atrito de ter uma base investigável desde o começo.
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.