Amazon SCS-C02: Logging, Auditoria e Forense — Guia de estudos

By Laurynas Brazys · 24 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Faz parte do AWS Security Specialty SCS-C02 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Achados e Remediação do Amazon GuardDuty

O GuardDuty é um serviço gerenciado de detecção de ameaças que ingere continuamente três fluxos de telemetria nos bastidores: eventos de gerenciamento do CloudTrail (e opcionalmente eventos de dados do S3), VPC Flow Logs e logs de consulta DNS do Route 53. Você não precisa habilitar, entregar ou pagar por essas fontes de log separadamente para que o GuardDuty as consuma — o serviço lê um fluxo duplicado diretamente. É por isso que o GuardDuty pode ser ativado com uma única chamada de API e começar a gerar achados em minutos, sem nenhuma engenharia de pipeline de logs.

Os achados carregam um valor de severidade entre 0.1 e 8.9, mapeado para Baixa (Low, 0.1–3.9), Média (Medium, 4.0–6.9) e Alta (High, 7.0–8.9). Achados acionáveis típicos incluem UnauthorizedAccess:EC2/SSHBruteForce, Backdoor:EC2/C&CActivity.B!DNS, CryptoCurrency:EC2/BitcoinTool.B e Recon:IAMUser/MaliciousIPCaller. Os padrões de remediação variam por achado: um comprometimento baseado em EC2 geralmente justifica o isolamento da instância com um security group de quarentena, a criação de snapshots dos volumes para análise forense e o encerramento da instância; um achado baseado no IAM requer a rotação das chaves de acesso e a revisão da atividade recente do principal no CloudTrail.

Para ambientes com múltiplas contas, habilite o GuardDuty via AWS Organizations e designe uma conta de administrador delegado (comumente a conta de Ferramentas de Segurança, ou Security Tooling). O administrador delegado pode habilitar automaticamente o GuardDuty em todas as contas-membro existentes e novas, em todas as Regiões onde o serviço está ativado. Sem a configuração de administrador delegado, os achados do GuardDuty de cada conta permanecem isolados em cada membro — habilitar os detectores individualmente não os agrega de forma centralizada.

AWS Security Hub e Agregação entre Contas

O Security Hub é a camada de normalização e agregação. Ele ingere achados do GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, Config e de dezenas de produtos de parceiros, convertendo-os para o formato AWS Security Finding Format (ASFF). Ele também executa seus próprios controles em relação a padrões como CIS AWS Foundations, AWS Foundational Security Best Practices, PCI DSS e NIST 800-53.

A agregação entre contas e entre Regiões funciona da mesma forma que no GuardDuty: registre o Security Hub com o administrador delegado do Organizations e, em seguida, designe uma Região de agregação para que os achados de outras Regiões sejam replicados nesse painel único. Um erro comum é habilitar o Security Hub em cada conta e esperar uma visão consolidada — sem o administrador delegado e a Região de agregação, cada conta continua vendo apenas seus próprios achados.

O Security Hub não envia e-mails por si só. Notificações e automações são construídas combinando eventos de achados do Security Hub no barramento de eventos padrão (default event bus) do EventBridge e encaminhando-os para o SNS, Lambda, Step Functions ou documentos do Systems Manager Automation.

CloudTrail: Eventos de Gerenciamento vs. Eventos de Dados

O CloudTrail registra duas categorias de atividade, e confundi-las é a lacuna mais comum na cobertura de detecção.

• Eventos de gerenciamento: operações de plano de controle — RunInstances, CreateBucket, AttachRolePolicy, PutBucketAcl. Habilitados por padrão em qualquer nova trilha (trail).

• Eventos de dados: operações de alto volume no nível do recurso — chamadas no nível de objeto do S3 (GetObject, PutObject, DeleteObject, PutObjectAcl), Invoke do Lambda, chamadas de API no nível de item do DynamoDB. Desabilitados por padrão e cobrados separadamente.

Se um requisito de segurança é “detectar quando alguém torna um objeto S3 público via PutObjectAcl”, uma trilha simples de eventos de gerenciamento não o capturará, porque alterações de ACL em objetos individuais são eventos de dados. Da mesma forma, a saída de dados (egress) via GetObject de um bucket sensível é invisível sem eventos de dados. PutBucketAcl (nível do bucket) é um evento de gerenciamento e seria registrado; PutObjectAcl (nível do objeto) não é.

Use uma trilha da organização (organization trail) criada na conta de gerenciamento ou na conta de administrador delegado para que os eventos de todas as contas-membro sejam capturados em um único bucket S3 e não possam ser desabilitados por principais das contas-membro. Proteja a trilha com:

• Criptografia SSE-KMS no bucket de destino, com uma política de chave do KMS que negue a descriptografia não autorizada.

• Uma política de bucket que negue s3:PutObject sem o principal de serviço do CloudTrail e negue a exclusão.

• Validação da integridade dos arquivos de log habilitada, que produz arquivos de resumo (digest) horários assinados com SHA-256 para que adulterações possam ser comprovadas.

Exemplo de criação:

aws cloudtrail create-trail \
  --name org-trail \
  --s3-bucket-name central-ct-logs \
  --is-organization-trail \
  --is-multi-region-trail \
  --enable-log-file-validation \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...

aws cloudtrail put-event-selectors \
  --trail-name org-trail \
  --event-selectors '[{"ReadWriteType":"All","IncludeManagementEvents":true,
                       "DataResources":[{"Type":"AWS::S3::Object",
                                         "Values":["arn:aws:s3:::sensitive-bucket/"]}]}]'

EventBridge e Alertas com SNS

O EventBridge é a malha de roteamento que conecta os achados a respondedores humanos e automatizados. Cada achado do GuardDuty, cada atualização de achado do Security Hub e cada evento derivado do CloudTrail chega ao barramento de eventos padrão (default event bus). As regras usam padrões de evento JSON para filtrar e depois distribuem para um ou mais alvos (targets) (SNS, Lambda, SQS, Kinesis Data Firehose, Step Functions, Systems Manager).

Um padrão canônico para achados de alta severidade do GuardDuty, encaminhado tanto para um tópico SNS para e-mail quanto para um stream de entrega do Firehose que alimenta o OpenSearch para análises:

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": { "severity": [ { "numeric": [ ">=", 7 ] } ] }
}

Para achados CRÍTICOS (CRITICAL) do Security Hub roteados para e-mail:

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": { "Label": ["CRITICAL"] },
      "Workflow": { "Status": ["NEW"] }
    }
  }
}

O endpoint de e-mail é uma simples assinatura (subscription) do SNS; o assinante deve confirmar através do link enviado por e-mail antes que a entrega comece. Uma única regra pode ter até cinco alvos, de modo que o alerta e as análises downstream não exijam regras duplicadas.

Ao criar os padrões, lembre-se de que os eventos de gerenciamento do CloudTrail chegam com "detail-type": "AWS API Call via CloudTrail", enquanto os eventos de dados não aparecem no barramento padrão, a menos que você configure uma trilha que publique para o CloudWatch Logs e use um filtro de métrica ou se inscreva através da integração de eventos de dados do CloudTrail no EventBridge. Escrever uma regra do EventBridge que corresponda a "eventName": "PutObjectAcl" no barramento padrão sem habilitar os eventos de dados resulta em zero correspondências.

CloudWatch Logs, Insights, Filtros de Métrica e Alarmes

Enviar logs do CloudTrail (e VPC Flow Logs, e logs de aplicação) para o CloudWatch Logs habilita a detecção quase em tempo real. Filtros de métrica (Metric filters) verificam cada evento de log recebido com base em um padrão e incrementam uma métrica personalizada do CloudWatch; um alarme do CloudWatch (CloudWatch alarm) nessa métrica aciona o SNS.

Exemplo: alarme para falhas repetidas de login no console.

aws logs put-metric-filter \
  --log-group-name /aws/cloudtrail/org \
  --filter-name ConsoleSignInFailures \
  --filter-pattern '{ ($.eventName = "ConsoleLogin") && ($.errorMessage = "Failed authentication") }' \
  --metric-transformations metricName=ConsoleLoginFailures,metricNamespace=Security,metricValue=1

O CloudWatch Logs Insights fornece consultas ad-hoc usando uma linguagem de consulta específica, útil para resposta a incidentes após o disparo de um alarme:

fields @timestamp, userIdentity.arn, sourceIPAddress, eventName

Armadilhas Comuns

• Falta de atividade em nível de objeto do S3: PutObjectAcl, GetObject e DeleteObject são eventos de dados (data events). Uma trilha padrão captura apenas eventos de gerenciamento (management events); você deve adicionar seletores de eventos de dados, caso contrário, o finding, o alarme ou a regra do EventBridge que visa esses nomes de API simplesmente nunca será acionado.

• Visibilidade central sem administrador delegado: habilitar o GuardDuty ou o Security Hub em todas as contas não agrega os resultados. Os findings (descobertas) são centralizados apenas após registrar um administrador delegado no AWS Organizations e, para o Security Hub, escolher uma Região de agregação. Convites entre contas (cross-account) funcionam para ambientes pequenos, mas não escalam e exigem aceitação por conta.

• Confusão entre eventos de gerenciamento e de dados nos filtros: PutBucketAcl (bucket) é um evento de gerenciamento e funciona em qualquer filtro padrão do EventBridge ou filtro de métrica; PutObjectAcl (objeto) não funciona, independentemente de quão bem elaborado seja o padrão, a menos que os eventos de dados estejam habilitados e sejam entregues ao mesmo pipeline.

Problema Prático: Cenário de Caso de Uso

Cenário: A Meridian Financial opera uma AWS Organization com várias contas, incluindo uma conta dedicada à segurança e uma conta de logging centralizado. Seu ambiente inclui PII de clientes no S3, APIs transacionais em EC2/Lambda, e o CloudTrail já está gravando eventos de gerenciamento em um bucket S3 central; as equipes desejam detecção mais rápida e uma resposta coordenada entre as contas.

Desafio: Engenheiros de segurança detectaram um pico repentino de GETs no S3 e findings relacionados do GuardDuty sugerindo uma possível exfiltração de dados, mas os alertas são ruidosos (noisy) e carecem de contexto correlacionado do CloudTrail e de contenção automatizada entre contas.

Abordagem Recomendada:

1. Habilite o Amazon GuardDuty em cada conta-membro e designe a conta de segurança como o administrador delegado do GuardDuty; habilite a proteção de eventos de dados do S3 para que os findings incluam anomalias de acesso em nível de objeto.
2. Configure o CloudTrail por conta para entregar eventos de gerenciamento ao S3 central para retenção e para encaminhar eventos de dados de alto valor selecionados (S3 GetObject/PutObject/DeleteObject e Lambda Invoke) para o CloudWatch Logs na conta de segurança para inspeção de baixa latência.
3. Ative o AWS Security Hub na conta de segurança e habilite a agregação entre contas com as contas-membro para que os findings do GuardDuty, os findings derivados do CloudTrail e os resultados do Config/Inspector sejam centralizados e normalizados.
4. Crie regras no EventBridge que correspondam a findings de alta severidade do GuardDuty e do Security Hub e os encaminhe para o SNS para notificações de pager e para uma função Lambda de remediação que usa o contexto do CloudTrail para tomar ações de contenção (revogar chaves de API, remover sessão do IAM, isolar a ENI do EC2).
5. Adicione filtros de métrica do CloudWatch Logs para taxas anormais de s3:GetObject com escopo por principal do IAM e um alarme que acione o mesmo pipeline EventBridge/SNS/Lambda; use consultas do CloudWatch Logs Insights na conta de segurança para enriquecer os alertas com eventos correlacionados do CloudTrail para a triagem de incidentes.

Justificativa: Centralizar os findings (GuardDuty + Security Hub) e enviar eventos de dados direcionados do CloudTrail para o CloudWatch habilita correlação de baixa latência, alertas e contenção automatizada via EventBridge/SNS/Lambda — alinhando-se com as melhores práticas da AWS para detecção, agregação entre contas e resposta automatizada.

CloudTrail Centralizado e Integridade dos Logs

O CloudTrail é o registro oficial da atividade de API da AWS, e a base de qualquer arquitetura de auditoria é uma única trilha multirregional (multi-Region trail) que entrega os logs para um bucket S3 centralizado, idealmente em uma conta dedicada de arquivamento de logs dentro do AWS Organizations. Uma trilha multirregional captura automaticamente eventos de gerenciamento em todas as Regiões atuais e em qualquer Região que a AWS lance posteriormente — uma trilha de Região única (single-Region) cria pontos cegos no momento em que uma carga de trabalho é iniciada em outro lugar, o que é a falha clássica de completude durante as auditorias. Quando aplicada no nível da organização, a trilha também captura os eventos de todas as contas-membro, de modo que uma nova conta que entra na organização é coberta sem qualquer configuração por conta.

Habilite a validação de arquivos de log (log file validation) na trilha. O CloudTrail então entrega um arquivo de resumo (digest file) assinado a cada hora para o mesmo bucket S3, contendo os hashes SHA-256 dos arquivos de log entregues. O comando aws cloudtrail validate-logs percorre a cadeia de resumos e detecta adulteração, exclusão ou lacunas. Sem a validação, um defensor não pode provar que os logs não foram alterados após um incidente, o que os invalida como evidência forense.

aws cloudtrail create-trail \
  --name org-trail \
  --s3-bucket-name corp-audit-logs \
  --is-multi-region-trail \
  --is-organization-trail \
  --enable-log-file-validation \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...
aws cloudtrail start-logging --name org-trail

Falhas na entrega são quase sempre problemas de permissão downstream, e não bugs do CloudTrail. O bucket S3 deve existir antes da criação da trilha, sua política de bucket (bucket policy) deve conceder s3:PutObject para cloudtrail.amazonaws.com com uma condição aws:SourceArn correspondente à trilha, e o proprietário do objeto deve ser o proprietário do bucket (bucket-owner-full-control). Se a trilha usar SSE-KMS, a política da CMK deve permitir kms:GenerateDataKey* para o principal de serviço do CloudTrail, e todo consumidor (Athena, engenheiros de segurança, parsers Lambda) deve ter a permissão kms:Decrypt nessa chave. Um modo de falha comum: os logs são entregues corretamente, mas as consultas do Athena retornam “AccessDenied” porque a role da consulta não tem a permissão Decrypt na CMK de criptografia dos logs. Corrija isso na política da chave, não desabilitando a criptografia.

CloudWatch Logs, Filtros de Métrica e Alarmes em Tempo Real

O CloudTrail entrega os logs no S3 em lotes de 5 a 15 minutos — adequado para auditoria retrospectiva, mas lento demais para detecção em tempo real. Para criar alarmes sobre eventos sensíveis, transmita a trilha para o CloudWatch Logs (uma opção da trilha) ou roteie eventos específicos via EventBridge. A abordagem com o CloudWatch Logs usa filtros de métrica (metric filters) que fazem a correspondência de padrões em eventos JSON e incrementam uma métrica do CloudWatch, que por sua vez aciona um CloudWatch Alarm e uma notificação do SNS. O exemplo clássico é o login no console com o usuário root:

{ $.eventName = "ConsoleLogin" && $.userIdentity.type = "Root" }

O EventBridge costuma ser melhor para eventos específicos e bem conhecidos (desativação de chave KMS, alterações de política do IAM), pois as regras podem acionar o Lambda ou o Step Functions diretamente, sem nenhum custo de Logs. Use filtros de métrica quando precisar de contagens agregadas ou da criação de dashboards.

A retenção no CloudWatch Logs tem como padrão Nunca Expirar (Never Expire), o que é caro e raramente a opção correta. Defina uma retenção explícita por grupo de logs (aws logs put-retention-policy) alinhada com o regime de conformidade — comumente 90 dias de dados “quentes” (hot) no CloudWatch, com arquivamento de longo prazo no S3 por meio de um filtro de inscrição (subscription filter) ou do Kinesis Data Firehose.

Para a higiene de dados sensíveis, aplique políticas de proteção de dados do CloudWatch Logs (data protection policies) no nível da conta. Elas usam identificadores de dados gerenciados (números de cartão de crédito, chaves secretas da AWS, SSNs) para mascarar strings correspondentes na ingestão. Crucialmente, para desmascarar os dados é necessária a permissão logs:Unmask; conceda-a apenas a uma role de emergência (break-glass role). Usuários que podem ler o grupo de logs, mas não têm a permissão Unmask, veem apenas asteriscos. Uma política em nível de conta se aplica a todos os grupos de logs atuais e futuros, o que é o controle correto — políticas por grupo podem ficar defasadas à medida que novos serviços criam novos grupos.

Consulta de Logs em Escala: Insights e Athena

Dois mecanismos de consulta atendem a diferentes camadas de dados.

• CloudWatch Logs Insights consulta dados que já estão no CloudWatch Logs usando uma linguagem de consulta própria. Ideal para dados operacionais recentes (logs do Lambda, VPC Flow Logs no Logs, logs de aplicação). É rápido, não exige configuração de esquema, mas é limitado pela retenção do CloudWatch e pelo custo por GB verificado.

• Amazon Athena executa SQL Presto/Trino em dados no S3. Ideal para consultas forenses em grande escala sobre logs do CloudTrail, logs de acesso do ALB, VPC Flow Logs armazenados no S3 e logs do CloudFront. Custa US$ 5 por TB verificado; use projeção de partição (partition projection) ou partições do Glue por data/Região para reduzir drasticamente o custo da verificação.

Um caso de uso forense típico: identificar quem desativou uma chave KMS. Como o JSON do CloudTrail é aninhado, a tabela do Athena criada pelo CloudTrail expõe userIdentity como uma struct:

SELECT eventTime,
       userIdentity.arn                                         AS principal,
       userIdentity.sessionContext.sessionIssuer.arn            AS assumed_role,
       userIdentity.sessionContext.attributes.mfaAuthenticated  AS mfa,
       sourceIPAddress,
       requestParameters
FROM   cloudtrail_logs
WHERE  eventName = 'DisableKey'
  AND  eventTime BETWEEN '2024-05-01T03:00:00Z' AND '2024-05-01T03:30:00Z';

Para análise de bots no ALB, habilite os logs de acesso do ALB para o S3, defina uma tabela do Athena sobre o prefixo dos logs, depois faça um join com uma tabela de IPs maliciosos conhecidos e visualize a agregação no QuickSight. O QuickSight lê dados do Athena, então o pipeline é: ALB → S3 → Athena → QuickSight. Enviar logs do ALB para o CloudWatch Logs Insights não é um caminho nativo suportado — os logs do ALB vão apenas para o S3.

Os VPC Flow Logs podem ir para qualquer um dos destinos: escolha o Logs para investigações táticas do tipo filter dstPort=3389 and action="REJECT", e o S3 (em formato Parquet, particionado) para consultas de tendências em escala de meses.

Coleta de Evidências com o Audit Manager

O AWS Audit Manager automatiza a coleta contínua de evidências mapeadas para frameworks como PCI DSS, HIPAA, SOC 2 e CIS. Ele coleta evidências de regras do Config, achados do Security Hub, eventos do CloudTrail e inventário de recursos, e as empacota em avaliações de controle. Quando habilitado na conta de gerenciamento do Organizations ou em uma conta de administrador delegado, ele coleta evidências de todas as contas-membro, produzindo um relatório de avaliação — um pacote zipado de evidências com um manifesto — que os auditores aceitam em vez de capturas de tela manuais. Esta é a resposta correta sempre que um cenário pedir por evidências contínuas, multi-conta e alinhadas a um framework: o Config sozinho oferece conformidade de recursos, mas sem o mapeamento para um framework; o Security Hub fornece achados, mas sem o empacotamento da avaliação; um relatório caseiro com o Athena não é contínuo.

Resumo dos Pontos de Atenção

• Culpar o CloudTrail pela falta de logs geralmente está errado: o bucket pode não existir, a política do bucket pode rejeitar o principal do CloudTrail ou a propriedade do objeto pode estar configurada incorretamente. Verifique o S3 primeiro.

• Uma trilha de região única (single-Region) parece mais barata, mas produz um histórico de auditoria incompleto; a opção multirregional é a resposta correta padrão para cobertura em toda a organização.

• Logs criptografados com SSE-KMS são invisíveis para o Athena, parsers Lambda ou engenheiros, a menos que a política da CMK conceda kms:Decrypt a esses principais — desabilitar a criptografia não é a solução; corrigir a política da chave é.

Problema Prático: Cenário de Caso de Uso

Cenário: A Meridian Financial opera uma AWS Organization com várias contas, incluindo produção, homologação (staging) e uma conta dedicada para logs. O ambiente deles hospeda APIs para clientes, análises e segredos administrados pelo IAM, e eles precisam de logs centralizados e à prova de adulteração, além de ferramentas de investigação rápidas para dar suporte à resposta a incidentes e solicitações de conformidade.

Desafio: Uma sequência suspeita recente de logins no console e alterações de políticas do IAM passou despercebida por horas, e há a preocupação de que a integridade dos logs e os alertas em tempo hábil sejam inadequados para a reconstrução forense e para a coleta de evidências do Audit Manager.

Abordagem Recomendada:

1. Habilite uma trilha do AWS Organizations CloudTrail (trilha da organização) em todas as regiões, ative a validação de integridade dos arquivos de log do CloudTrail, entregue os logs e arquivos de resumo (digest files) a um bucket S3 centralizado e criptografado com uma CMK do KMS cuja política de chave restrinja a descriptografia a uma pequena equipe de segurança, e habilite o log de acesso e o versionamento do S3.
2. Configure o CloudTrail para transmitir eventos de gerenciamento e eventos de dados selecionados para o CloudWatch Logs. Em seguida, crie filtros de métrica do CloudWatch Logs para padrões de alto risco (falhas de login no console de novos IPs, CreateUser, PutRolePolicy) e anexe CloudWatch Alarms a tópicos do SNS para acionamento de alertas (paging) e um playbook automatizado com Lambda.
3. Implante dashboards do CloudWatch Logs Insights para investigação interativa de eventos recentes e defina regras de retenção e de ciclo de vida (lifecycle) na conta de logs para reter as evidências conforme a política.
4. Catalogue os objetos do CloudTrail no S3 com o AWS Glue e execute consultas no Athena (particionadas por região/data/serviço) para análises retrospectivas em larga escala e para produzir exportações de evidências em CSV para os investigadores.
5. Crie uma avaliação (assessment) no AWS Audit Manager que colete automaticamente evidências do CloudTrail, AWS Config e IAM em uma pasta de evidências e agende exportações periódicas para os revisores de conformidade (compliance).

Justificativa: Centralizar e validar o CloudTrail, transmitir para o CloudWatch para filtros de métricas e alarmes em tempo real, e usar o Athena/Logs Insights para consultas escaláveis seguem as melhores práticas da AWS para detecção, registro imutável e prontidão forense, enquanto o Audit Manager automatiza a coleta de evidências para auditorias.

← Detecção de Ameaças e Alertas · Todos os domínios · Criptografia →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Amazon →