CloudWatch Logs Insights para segurança: consultas úteis em investigações AWS
Logs coletados só ajudam se você consegue consultá-los rápido. Veja consultas defensivas para investigação na AWS.
Coletar logs é metade do trabalho; a outra metade é conseguir fazer perguntas a eles sob pressão. O CloudWatch Logs Insights permite consultar logs com uma linguagem própria, o que é especialmente útil quando o CloudTrail está sendo enviado para o CloudWatch Logs. Em uma investigação, a capacidade de filtrar rapidamente por evento, identidade e origem faz a diferença entre entender o incidente e ficar no escuro.
Este guia mostra, de forma defensiva, como usar o Logs Insights para investigação na AWS: que campos do CloudTrail importam, consultas por padrão de atividade, como transformar uma consulta em alerta e como interpretar os resultados. O foco é análise autorizada do seu próprio ambiente, para detecção e resposta.
Campos do CloudTrail que importam
Eventos do CloudTrail trazem campos que respondem às perguntas centrais de uma investigação. O eventName diz qual ação ocorreu, o sourceIPAddress de onde veio, o userIdentity quem agiu, o awsRegion onde, e o errorCode indica tentativas negadas. Cruzar esses campos revela padrões, como uma identidade agindo de um IP incomum ou uma sequência de ações negadas que sugere enumeração.
fields @timestamp, eventName, userIdentity.arn, sourceIPAddress
| filter eventSource = "iam.amazonaws.com"
| sort @timestamp desc
| limit 50Extrair e agrupar com parse e stats
Além de filtrar, o Logs Insights agrega. O comando stats resume a atividade, e o bin agrupa por janela de tempo, o que ajuda a ver rajadas. Um pico súbito de um único IP ou identidade em uma janela curta costuma ser mais revelador do que uma lista longa de eventos individuais.
fields @timestamp, userIdentity.arn
| stats count(*) as eventos by bin(5m), userIdentity.arn
| sort eventos descConsultas por padrão de atividade
Algumas consultas se repetem em investigações. Listar tentativas negadas ajuda a detectar enumeração e abuso de permissão. Agrupar ações por IP de origem mostra de onde a atividade veio. Filtrar eventos sensíveis, como criação de usuários, chaves e mudanças de política, revela tentativas de persistência.
fields @timestamp, eventName, userIdentity.arn, errorCode
| filter ispresent(errorCode)
| stats count(*) as tentativas by userIdentity.arn, errorCode
| sort tentativas descSinais de abuso de credencial e persistência
Alguns eventos merecem uma consulta própria porque marcam abuso de sessão ou preparação de acesso persistente. Chamadas de AssumeRole e GetSessionToken em volume incomum, criação de access keys e mudança de política de confiança de role são exemplos. Filtrar por esses nomes de evento, cruzando com a identidade e o IP de origem, ajuda a separar operação normal de atividade suspeita.
fields @timestamp, eventName, userIdentity.arn, sourceIPAddress
| filter eventName in ["AssumeRole", "GetSessionToken", "CreateAccessKey"]
| stats count(*) as vezes by userIdentity.arn, eventName
| sort vezes desc- Filtrar eventos de IAM sensíveis (criar usuário, chave, política)
- Agrupar atividade por sourceIPAddress para ver origens
- Listar errorCode para detectar enumeração e abuso
- Observar AssumeRole e GetSessionToken em volume incomum
- Buscar uso da conta root e desabilitação de serviços
- Restringir a janela de tempo para focar o incidente
Da consulta ao alerta
Investigar depois do fato é útil, mas o ideal é que alguns padrões avisem sozinhos. Quando o CloudTrail está no CloudWatch Logs, você pode criar um metric filter que conta ocorrências de um padrão e associá-lo a um alarme. Assim, eventos como uso de root ou parada do CloudTrail geram notificação em vez de esperar por uma consulta manual.
{ $.userIdentity.type = "Root" &&
$.userIdentity.invokedBy NOT EXISTS &&
$.eventType != "AwsServiceEvent" }Direcione o alarme para um canal com dono e prazo de resposta, não apenas para um painel. Reserve o Logs Insights para a investigação ágil, quando você precisa explorar e reconstruir a linha do tempo, e deixe os metric filters cuidarem dos padrões conhecidos e recorrentes.
Limitações e boas práticas
O Logs Insights consulta o que está no grupo de logs, então sua utilidade depende de o CloudTrail estar realmente sendo enviado ao CloudWatch e da retenção configurada. Consultas cobram por volume de dados varridos, então restringir a janela de tempo reduz custo e acelera o resultado. Para volumes muito grandes ou janelas longas, um data lake com consultas pode ser mais econômico. Padronize consultas reutilizáveis para não improvisar no meio de um incidente.
Checklist prático
- Enviar o CloudTrail para o CloudWatch Logs quando precisar de consulta ágil
- Definir retenção adequada do grupo de logs
- Padronizar consultas reutilizáveis de investigação
- Usar stats e bin para ver rajadas por identidade e IP
- Filtrar eventos de IAM sensíveis
- Observar AssumeRole, GetSessionToken e criação de chaves
- Listar tentativas negadas para detectar enumeração
- Restringir a janela de tempo ao incidente para custo e velocidade
- Criar metric filters e alarmes para padrões críticos
- Buscar uso de root e desabilitação de serviços
- Avaliar data lake para volumes e janelas grandes
Boas práticas
- Prepare consultas antes do incidente, não durante
- Cruze evento, identidade e origem para achar padrões
- Use stats e bin para destacar rajadas de atividade
- Use tentativas negadas como sinal de enumeração
- Transforme padrões conhecidos em metric filters com alarme
- Mantenha retenção compatível com o tempo de descoberta
- Restrinja a janela de tempo para controlar custo de consulta
Erros comuns
CloudTrail não enviado ao CloudWatch quando se precisa consultar
A consulta ágil não encontra os eventos necessários na investigação.
Retenção curta do grupo de logs
Eventos relevantes já expiraram quando o incidente é descoberto.
Improvisar consultas durante o incidente
Tempo perdido e risco de não encontrar o que importa sob pressão.
Ignorar errorCode
Sinais de enumeração e abuso de permissão passam despercebidos.
Consultar janelas enormes sem foco
Custo e lentidão sem ganho de clareza na análise.
Depender só de consulta manual, sem metric filter
Padrões críticos ficam esperando alguém olhar em vez de gerar alerta.
Quando procurar apoio especializado
Estruturar coleta, consultas e alertas para investigação é o foco do serviço de Monitoramento e Resposta da GUARDIASEC, que define casos de uso de detecção e fluxos de investigação prontos para usar quando o incidente acontece.
Perguntas frequentes
Preciso enviar o CloudTrail para o CloudWatch para usar o Logs Insights?
O Logs Insights consulta grupos de logs do CloudWatch, então sim, para consultar eventos do CloudTrail por lá é preciso enviá-los ao CloudWatch Logs. Uma alternativa para grandes volumes é consultar os logs do CloudTrail diretamente em um data lake. O importante é ter um caminho ágil de consulta definido antes de precisar dele.
Quais campos do CloudTrail são mais úteis em uma investigação?
Os principais são eventName, que diz qual ação ocorreu, sourceIPAddress, que mostra a origem, userIdentity, que identifica quem agiu, awsRegion e errorCode, que revela tentativas negadas. Cruzar esses campos permite reconstruir a linha do tempo e detectar padrões como atividade de um IP incomum ou sequências de ações negadas.
Como transformo uma consulta recorrente em alerta?
Consultas do Logs Insights são feitas sob demanda e não disparam alertas por si só. Para alertar de forma contínua, crie um metric filter no grupo de logs que conta ocorrências de um padrão, como uso de root ou parada do CloudTrail, e associe um alarme do CloudWatch a ele. Assim o padrão gera notificação automática, enquanto o Logs Insights fica para a investigação exploratória.
A consulta do Logs Insights tem custo?
Sim. O Logs Insights cobra pela quantidade de dados varridos em cada consulta. Por isso, restringir a janela de tempo e filtrar cedo reduz tanto o custo quanto o tempo de resposta. Para janelas muito longas ou volumes muito grandes, avaliar um data lake com consultas costuma ser mais econômico do que varrer grupos de log enormes repetidas vezes.
Logs Insights substitui um SIEM?
Não. O Logs Insights é ótimo para investigação ágil dentro do CloudWatch, mas um SIEM correlaciona fontes diversas, incluindo aplicações, rede e endpoints, com regras e alertas mais ricos. Eles se complementam: o Logs Insights resolve consultas rápidas no ambiente AWS, enquanto o SIEM dá visão correlacionada mais ampla.
Como uso o Logs Insights de forma responsável?
O uso é para análise do seu próprio ambiente, de forma autorizada, com foco defensivo: detecção, investigação e resposta. As consultas leem logs que você já coleta; não há exploração de terceiros envolvida. A boa prática é padronizar consultas, restringir janelas de tempo e transformar padrões frequentes em alertas.
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.