Logs de segurança em cloud: o que coletar para investigar incidentes
Na hora de investigar, ou o log existe ou não existe. Veja o que coletar antes de precisar e como organizar.
Quando um incidente acontece, a primeira pergunta é sempre a mesma: o que os logs mostram? E é nessa hora que muitas organizações descobrem que o log essencial não estava habilitado, ou estava em uma região não coberta, ou foi expirado. Logs de segurança em cloud precisam ser planejados antes do incidente, porque não dá para coletar retroativamente o que não foi registrado.
Este guia mostra quais fontes de log são mais úteis para investigação em ambientes AWS, como centralizá-las e por quanto tempo retê-las. O foco é cobrir as perguntas que uma investigação faz: quem agiu, de onde, o que acessou e como o tráfego se moveu.
As fontes que mais importam
Diferentes logs respondem a diferentes perguntas. O CloudTrail responde quem fez o quê na conta. Os VPC Flow Logs mostram o tráfego de rede entre recursos, úteis para detectar movimento lateral e exfiltração. Os logs de WAF revelam o que foi bloqueado e o que passou na borda. Os logs de balanceador registram as requisições que chegaram à aplicação. GuardDuty agrega detecção de ameaças sobre várias dessas fontes.
- CloudTrail: atividade administrativa e chamadas de API
- VPC Flow Logs: tráfego de rede e movimento lateral
- WAF logs: o que foi bloqueado e o que passou na borda
- Logs de balanceador: requisições que chegaram à aplicação
- Logs de aplicação: contexto de negócio do que aconteceu
- GuardDuty: detecção de ameaças correlacionando fontes
Centralização e retenção
Logs espalhados por contas e regiões são quase inúteis sob pressão. Centralize em um destino dedicado e restrito, idealmente uma conta de log separada, para que um comprometimento na produção não permita apagar a evidência. A centralização também permite correlacionar fontes diferentes em uma linha do tempo única.
Defina retenção com base no tempo típico entre o comprometimento e a descoberta, que frequentemente é de meses. Logs com retenção curta demais expiram justamente antes de você precisar deles. Use armazenamento de baixo custo para o histórico mais antigo e mantenha os mais recentes prontos para consulta rápida.
Correlação e detecção
Coletar não é o suficiente; é preciso conseguir consultar e correlacionar. Direcione os logs para uma solução de análise, seja um data lake com consultas, o CloudWatch ou um SIEM, e crie consultas reutilizáveis para perguntas comuns de investigação. Defina alertas para eventos de alta severidade, como uso de root, desabilitar trilhas e mudanças amplas de permissão.
Sincronize horários e padronize fusos, porque correlacionar eventos de fontes diferentes exige uma referência temporal confiável. Pequenas diferenças de relógio atrapalham a reconstrução da linha do tempo.
Consultas que respondem às perguntas da investigação
Ter os logs centralizados só ajuda se você consegue perguntar a eles o que precisa saber sob pressão. Vale preparar consultas prontas para as dúvidas mais comuns de uma investigação, para não escrevê-las do zero no pior momento. Duas ferramentas nativas cobrem a maior parte dos casos na AWS: o CloudWatch Logs Insights, para logs em grupos do CloudWatch, e o Athena, para logs em S3 como os do CloudTrail.
fields @timestamp, sourceIPAddress, userIdentity.arn
| filter eventName = "ConsoleLogin"
| filter responseElements.ConsoleLogin = "Failure"
| sort @timestamp desc
| limit 50SELECT eventtime, useridentity.arn, eventname, sourceipaddress
FROM cloudtrail_logs
WHERE eventname IN ('CreateAccessKey', 'AttachUserPolicy', 'StopLogging')
ORDER BY eventtime DESC
LIMIT 100Consultas assim são de leitura e investigação: elas mostram quem agiu, de onde e sobre o quê, sem alterar nada. Mantê-las versionadas e documentadas, junto de onde cada fonte de log fica, encurta o tempo entre a suspeita e a resposta.
Integridade, acesso e custo
Um log que pode ser alterado ou apagado por quem comprometeu o ambiente perde o valor de evidência. Além de centralizar em uma conta restrita, torne os arquivos imutáveis pelo período de retenção, criptografe com uma chave dedicada e limite quem pode ler e quem pode apagar. A validação de integridade, quando a fonte oferece, prova que os registros não foram adulterados.
Custo é o que faz muita gente coletar de menos ou reter de menos. Em vez de escolher entre visibilidade e conta no fim do mês, use camadas de armazenamento: mantenha o histórico recente pronto para consulta rápida e mova o antigo para armazenamento mais barato, sem apagá-lo. Particionar os dados por data e por fonte reduz o volume varrido em cada consulta e derruba o custo de investigar.
Checklist prático
- Habilitar CloudTrail multi-region como base
- Ativar VPC Flow Logs nas redes relevantes
- Coletar logs de WAF e de balanceador
- Encaminhar logs de aplicação com contexto de negócio
- Ativar GuardDuty para detecção correlacionada
- Centralizar logs em conta dedicada e restrita
- Definir retenção compatível com o tempo de descoberta
- Direcionar logs para uma solução de análise
- Criar consultas reutilizáveis e alertas de alta severidade
- Padronizar fuso e sincronizar horários
- Manter consultas de investigação prontas para as perguntas comuns
- Tornar os logs imutáveis e criptografados, com acesso restrito
- Usar camadas de armazenamento e particionamento para controlar custo
Boas práticas
- Planeje os logs antes do incidente, não durante
- Centralize em conta separada para preservar evidência
- Cubra rede, identidade, borda e aplicação
- Retenha pelo tempo realista entre comprometimento e descoberta
- Crie consultas e alertas para as perguntas mais comuns
- Mantenha referência temporal confiável para correlação
- Deixe consultas de investigação prontas antes de precisar delas
- Proteja a integridade dos logs e restrinja quem pode apagá-los
Erros comuns
Descobrir que o log essencial não estava habilitado
A investigação fica sem evidência justamente do ponto crítico.
Logs espalhados por contas e regiões
Correlação lenta e difícil sob pressão de um incidente.
Retenção curta demais
Os logs expiram antes da descoberta do incidente.
Coletar sem capacidade de consultar
Volume de dados sem valor prático na hora de investigar.
Relógios dessincronizados
Linha do tempo inconsistente e correlação prejudicada.
Logs sem proteção contra alteração
Quem compromete o ambiente apaga ou adultera a evidência que sustentaria a investigação.
Coletar de menos por medo do custo
Sem camadas de armazenamento, corta-se justamente o log que faria falta na investigação.
Quando procurar apoio especializado
Definir o que coletar, como centralizar e como detectar é o foco do serviço de Monitoramento e Resposta da GUARDIASEC, que estrutura coleta, casos de uso de detecção e fluxos de investigação adaptados ao seu ambiente.
Perguntas frequentes
Quais logs habilitar primeiro se eu tiver pouco tempo?
Comece pelo CloudTrail multi-region, que responde quem fez o quê na conta, e pelo GuardDuty, que adiciona detecção sobre várias fontes com pouco esforço. Em seguida, adicione VPC Flow Logs e logs de borda e aplicação conforme a criticidade. Essa ordem cobre primeiro as perguntas mais frequentes de uma investigação.
Por quanto tempo devo guardar os logs?
O ideal é cobrir o tempo típico entre um comprometimento e sua descoberta, que costuma ser de meses. Muitas organizações mantêm pelo menos um ano, usando armazenamento mais barato para o histórico antigo. O risco de reter pouco é o log essencial expirar antes de você perceber que precisou dele.
Preciso de um SIEM para usar bem os logs?
Não necessariamente. Um SIEM facilita correlação e alertas, mas é possível começar com soluções nativas, como consultas sobre um data lake e alertas no CloudWatch. O essencial é centralizar, conseguir consultar e ter alertas para eventos críticos. O SIEM agrega valor à medida que a complexidade e o volume crescem.
Por que centralizar os logs em outra conta?
Porque um atacante que compromete a conta de produção normalmente tenta apagar rastros. Se os logs estão na mesma conta, ele consegue. Centralizando em uma conta de log separada e restrita, a evidência fica protegida mesmo quando o ambiente de origem foi comprometido, o que é essencial para a investigação.
Como controlo o custo de armazenar tantos logs?
Use camadas de armazenamento em vez de escolher entre visibilidade e custo. Mantenha o histórico recente pronto para consulta rápida e mova o antigo para armazenamento mais barato, sem apagá-lo antes do prazo de retenção. Particionar os dados por data e por fonte reduz o volume varrido em cada consulta, o que baixa tanto o custo quanto o tempo de investigação.
Que consultas devo ter prontas antes de um incidente?
As que respondem às perguntas mais frequentes: falhas de login, uso da conta root, criação de chaves e usuários, mudanças de política e acesso a partir de origens ou regiões incomuns. Deixá-las versionadas e documentadas evita escrevê-las do zero sob pressão. O CloudWatch Logs Insights cobre logs em grupos do CloudWatch e o Athena cobre logs em S3, como os do CloudTrail.
CloudTrail Lake, Athena ou CloudWatch Logs Insights: qual usar?
Depende de onde o log está e de quanto você quer gerenciar. O CloudWatch Logs Insights consulta grupos de log do CloudWatch e é prático para alertas e investigação rápida. O Athena consulta arquivos em S3 e escala bem para grande volume histórico, ao custo de montar tabelas e partições. O CloudTrail Lake é a opção gerenciada, com retenção longa e consulta em SQL sem manter a infraestrutura. Muitas equipes combinam mais de um conforme a fonte.
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.