Auditoria e Rastreamento de Configuração com CloudTrail, Config e Logging Centralizado na AWS
_Category: Logging & Monitoring_
Quando um incidente de segurança acontece, a primeira pergunta que surge é: "Temos os logs?" Sem registros, é impossível saber o que aconteceu. Se os logs foram adulterados, não há como confiar neles. O SCS-C03 pergunta repetidamente: "Como registrar, como proteger e como usar os logs?" Neste post, vamos percorrer toda a arquitetura de auditoria e logging — de CloudTrail a Config, passando por CloudWatch Logs, EventBridge, Kinesis Data Firehose, Athena, VPC Flow Logs e Audit Manager.
---
O que é Auditabilidade e o que o SCS-C03 Quer Saber
Auditabilidade é a capacidade de provar, mesmo depois do fato, "quem fez o quê, quando, de onde e como". Um registro de auditoria confiável precisa ter três qualidades: completude (nada pode ficar de fora), integridade (não pode ser adulterado) e disponibilidade (precisa estar acessível quando necessário).
Veja os padrões de cenário mais comuns no SCS-C03:
"É preciso registrar todas as chamadas de API e detectar adulterações" → CloudTrail + Log File Integrity Validation + S3 Object Lock "Quando a configuração de um recurso mudar, é preciso rastrear o estado antes e depois" → AWS Config Configuration Item "A equipe de segurança precisa ser avisada imediatamente quando uma API específica for chamada" → CloudTrail + EventBridge + SNS "Os logs de diversas contas precisam ser centralizados em um único local" → Log Archive Account + Kinesis Data Firehose
CloudTrail e Config respondem a perguntas diferentes. O CloudTrail responde "o que aconteceu?" (histórico de ações via API), enquanto o Config responde "qual é o estado atual deste recurso?" (snapshot de configuração e histórico de mudanças). O exame apresenta cenários parecidos para confundir os candidatos, por isso é fundamental entender claramente a divisão de responsabilidades entre os dois serviços.
---
Os Três Tipos de Eventos do CloudTrail: Management, Data e Insights
Imagine o CloudTrail como o livro de registro de entrada e saída de um prédio corporativo — mas com três categorias distintas de registros.
| Tipo de Evento | O que registra | Ativado por padrão | Exemplos | |---------------|---------------|-------------------|----------| | Management Events | APIs de gerenciamento de recursos AWS (plano de controle) | Sim (Event History de 90 dias) | CreateBucket, RunInstances, AuthorizeSecurityGroupIngress | | Data Events | Acesso a dados dentro dos recursos (plano de dados) | Não (requer configuração manual) | S3 GetObject/PutObject, Lambda Invoke, DynamoDB GetItem | | Insights Events | Detecção automática de padrões anormais de chamadas de API | Não (requer ativação manual) | Pico repentino de chamadas TerminateInstances |
Os Management Events ficam disponíveis no console por 90 dias no Event History, sem custo e sem precisar criar uma Trail. Mas após esse período, os dados são perdidos — por isso, para retenção de longo prazo, é necessário criar uma Trail e armazenar os logs no S3.
Os Data Events são ativados seletivamente por bucket S3, função Lambda ou tabela DynamoDB. Se o Data Events do S3 não estiver habilitado, GetObject e PutObject não serão registrados. Em ambientes com alto volume de tráfego, o volume de logs pode explodir, então é preciso considerar o trade-off de custo com cuidado.
Os Insights Events usam os Management Events dos últimos 7 dias como linha de base para detectar atividade anormal automaticamente. Se uma chamada que normalmente ocorre 10 vezes por dia de repente dispara para milhares, um Insights Event é gerado. É útil para detecção precoce de ameaças internas ou roubo de credenciais.
Event History vs Trail: o Event History é gratuito, mas tem limite de 90 dias e cobre apenas uma região. A Trail permite retenção de longo prazo no S3, análise com Athena e configuração Multi-Region para concentrar eventos de todas as regiões em um único bucket.
!Os 3 tipos de evento do CloudTrail
Design de Trail: Padrões Multi-Region, Org-wide e Tamper-proof
Ao desenhar uma Trail para uso corporativo, três decisões são fundamentais.
A Multi-Region Trail, com a opção "Apply trail to all regions" ativada, centraliza os eventos de todas as regiões em um único bucket S3. Para incluir eventos de serviços globais como IAM, STS e CloudFront, é necessário também ativar "Include global service events".
A Org-wide Trail, criada na conta de gerenciamento do Organizations, é aplicada automaticamente a todas as contas membro. Isso elimina a necessidade de configurar Trails individualmente em cada conta.
O conjunto de proteções contra adulteração (Tamper-proof) é o elemento mais crítico:
| Mecanismo de proteção | Função | |----------------------|--------| | Log File Integrity Validation | Gera um arquivo Digest a cada hora (SHA-256 + assinatura RSA) — validado com | | S3 Object Lock modo Compliance | Ninguém, nem mesmo o root, pode deletar objetos durante o período de retenção — funciona como um cofre lacrado | | S3 Object Lock modo Governance | Apenas usuários com permissão especial (BypassGovernanceRetention) podem remover a proteção | | S3 MFA Delete | Exige autenticação MFA para deletar versões do S3 | | Cross-Account Log Archive | A conta operacional só tem permissão de PutObject no bucket de logs — não pode deletar | | KMS SSE-KMS | Protege a confidencialidade do conteúdo dos logs; acesso à descriptografia controlado por política de chave |
O padrão Log Archive Account se baseia na separação de contas. Uma conta dedicada concentra todos os logs de todas as contas membro em seu bucket S3, e as contas membro só têm permissão de PutObject. Mesmo que uma conta operacional seja comprometida, o atacante não conseguirá deletar ou adulterar os logs.
---
AWS Config: Rastreamento de Mudanças e Automação de Conformidade
Pense no AWS Config como um diário de mudanças dos móveis de um apartamento: registra onde cada móvel estava, quem o moveu, e verifica se está na posição correta segundo as regras do condomínio.
O Configuration Item (CI) é um snapshot do estado de um recurso. Ele inclui tipo do recurso, valores dos atributos, outros recursos relacionados e o timestamp da mudança. A cada mudança, um novo CI é gerado, formando uma linha do tempo consultável. O Configuration Recorder é o motor que rastreia automaticamente os recursos suportados e precisa ser criado individualmente por região.
O Config Aggregator consolida dados do Config de múltiplas contas e múltiplas regiões em uma conta agregadora, permitindo visualização centralizada a partir da conta de gerenciamento.
As Config Rules avaliam automaticamente se a configuração dos recursos atende às políticas definidas. Existem três categorias: Managed Rules (mais de 150 regras fornecidas pela AWS, como "restricted-ssh" e "s3-bucket-public-read-prohibited"), Custom Rules (políticas personalizadas da organização implementadas via função Lambda) e Conformance Pack (pacotes de regras agrupadas por framework regulatório, como PCI-DSS, HIPAA e NIST 800-53).
As Remediation Actions conectam recursos não conformes a documentos de automação do Systems Manager para correção automática.
| Pergunta | Serviço que responde | |----------|--------------------| | Quem alterou este recurso? | CloudTrail (chamador da API, UserAgent, IP) | | Quando e como este recurso foi alterado? | Config (linha do tempo de CIs) | | Este recurso está em conformidade com a política atual? | Config Rules |
---
CloudWatch Logs e EventBridge para Alertas em Tempo Real e Automação
Enviar logs do CloudTrail apenas para o S3 introduz uma latência de até 15 minutos. Para reação em tempo real, existem dois caminhos.
O primeiro é o caminho via CloudWatch Logs. Ao ativar "Enviar para CloudWatch Logs" na Trail, os eventos são entregues ao grupo de logs quase em tempo real. Você usa um Metric Filter para detectar padrões específicos, cria um CloudWatch Alarm e dispara uma notificação via SNS. Por exemplo, o padrão para detectar falhas de login no console é: . O Subscription Filter faz o streaming do grupo de logs em tempo real para Kinesis Data Firehose, Kinesis Data Streams ou Lambda.
O segundo é o caminho via EventBridge. O EventBridge funciona como um alarme que dispara no exato momento em que o evento acontece. Ele reage a chamadas de API em segundos, disparando Lambda, SNS, SQS, Step Functions e outros. Não exige a configuração de envio do CloudTrail para CloudWatch Logs — funciona diretamente.
Critério de escolha para o exame: detecção em tempo real de mudanças via API → CloudTrail + EventBridge. Config Rules têm latência de alguns minutos após a mudança de configuração, e não disparam alerta se o status de conformidade não mudar. O Metric Filter do CloudWatch Logs requer configuração adicional de envio do CloudTrail para o CWL.
O CloudWatch Logs Insights permite análise interativa de logs com queries no estilo SQL. As queries salvas podem ser adicionadas a dashboards ou agendadas para execução periódica.
---
Arquitetura de Logging Centralizado: Log Archive Account, Firehose, OpenSearch e Athena
Com dezenas ou centenas de contas gerando logs separadamente, ter uma visão consolidada se torna inviável. O padrão Log Archive Account resolve isso. Uma conta dedicada concentra todos os logs em seu bucket S3, com as contas membro tendo apenas permissão de PutObject. A combinação de S3 Object Lock (modo Compliance) com Org-wide Trail garante a segurança dos logs mesmo que uma conta operacional seja comprometida.
Para agregação em streaming em tempo real, usa-se o Kinesis Data Firehose. O fluxo é: CloudWatch Logs Subscription Filter → Kinesis Data Firehose → bucket S3 central ou OpenSearch. No OpenSearch, dashboards do Kibana visualizam eventos de segurança e alertas são configurados para quando limites são ultrapassados.
Para análise forense de grandes volumes após o fato, o Athena é a escolha certa. Ao criar tabelas Athena so