Amazon SCS-C02: Detecção de Ameaças e Alertas — 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.

Centralizando o GuardDuty em uma Organização

O Amazon GuardDuty é um serviço de detecção contínua de ameaças que analisa eventos de gerenciamento e de dados do CloudTrail, VPC Flow Logs, logs de consulta DNS, logs de auditoria do EKS, atividade de login do RDS e telemetria de runtime. Ele produz findings classificados por propósito da ameaça (Backdoor, CryptoCurrency, Recon, UnauthorizedAccess, PenTest, Policy, Stealth, Trojan, Impact) e tipo de recurso (EC2, IAMUser, S3, Kubernetes, RDS, Lambda, Runtime).

Operar o GuardDuty conta por conta não é uma abordagem escalável. A arquitetura correta em um ambiente do AWS Organizations é designar um administrador delegado (delegated administrator) — geralmente a conta dedicada de segurança ou auditoria — usando a conta de gerenciamento do Organizations. A partir do administrador delegado, você habilita o GuardDuty para toda a organização e ativa a habilitação automática (auto-enable) para que novas contas-membro e novas Regiões sejam protegidas automaticamente à medida que são criadas. Sem a habilitação automática, uma conta recém-provisionada permanece sem visibilidade até que um operador habilite manualmente a detecção, que é exatamente a brecha que os invasores exploram durante o processo de integração.

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

Cenário: A Meridian Financial opera um ambiente AWS multi-conta com 28 contas para produção, desenvolvimento e serviços compartilhados. Sua conta de gerenciamento governa as contas através do AWS Organizations, com logging centralizado de CloudTrail e S3, mas os alertas de segurança e os dados de investigação estão dispersos entre as contas-membro, tornando a triagem de incidentes lenta e inconsistente.

Desafio: Uma detecção recente de movimento lateral em uma conta produziu findings do GuardDuty que não ficaram visíveis para as ferramentas centrais do SOC com rapidez suficiente, atrasando a contenção e a investigação forense.

Abordagem Recomendada:

Designar um administrador delegado do GuardDuty na conta de gerenciamento e habilitar o GuardDuty em toda a organização via AWS Organizations para que todas as contas-membro encaminhem os findings para um detector central.
Ativar o AWS Security Hub centralizado na conta de gerenciamento como o agregador e habilitar o Security Hub para todas as contas e regiões para normalizar os findings do GuardDuty juntamente com outros padrões de segurança.
Configurar regras do Amazon EventBridge na conta de gerenciamento para capturar findings do GuardDuty e do Security Hub e encaminhá-los para destinos centralizados, como o Amazon SNS para envio de alertas (paging), o Amazon Kinesis Data Firehose para o S3 para arquivamento, ou entrega direta ao seu SIEM.
Implantar respondedores Lambda acionados pelo EventBridge para ações de contenção automatizadas (por exemplo, isolar uma instância EC2 via API do EC2 e criar um incidente no AWS Systems Manager) e marcar os findings para investigação.
Integrar o Amazon Detective para investigação centralizada e encaminhar os findings arquivados no S3 para sua ferramenta de análise/SIEM para correlação e relatórios de longo prazo.

Justificativa: Usar um administrador delegado do GuardDuty com o Security Hub e o EventBridge centraliza a detecção, normaliza os alertas e permite respostas automatizadas e auditáveis, seguindo as melhores práticas da AWS para detecção de ameaças em toda a organização e resposta a incidentes em tempo hábil.

# From the Organizations management account
aws organizations enable-aws-service-access \
  --service-principal guardduty.amazonaws.com

aws guardduty enable-organization-admin-account \
  --admin-account-id 111122223333

# From the delegated admin
aws guardduty update-organization-configuration \
  --detector-id abc123 \
  --auto-enable-organization-members ALL \
  --features '[{"Name":"RDS_LOGIN_EVENTS","AutoEnable":"NEW"},
               {"Name":"EKS_AUDIT_LOGS","AutoEnable":"NEW"},
               {"Name":"RUNTIME_MONITORING","AutoEnable":"NEW"}]'

O GuardDuty é Regional, portanto, a relação de administrador delegado e as configurações de habilitação automática devem ser estabelecidas em cada Região em que você opera. Esta é uma fonte frequente de pontos cegos — uma equipe habilita o GuardDuty em us-east-1 e assume que a cobertura é global.

Proteções Específicas do Serviço

O GuardDuty básico cobre as fontes de dados fundamentais, mas vários planos de proteção devem ser habilitados explicitamente porque adicionam custo e ingestão de telemetria adicional:

Proteção de RDS: analisa a atividade de login nos mecanismos Aurora MySQL/PostgreSQL e RDS, gerando findings como CredentialAccess:RDS/AnomalousBehavior.SuccessfulLogin quando usuários desconhecidos se autenticam em um endpoint de banco de dados. Esta é a fonte correta para detectar logins suspeitos no banco de dados — não crie filtros de métrica personalizados do CloudWatch em logs de auditoria de banco de dados quando a Proteção de RDS já emite o finding nativamente.
Proteção de EKS: ingere logs de auditoria do Kubernetes para detectar acesso anômalo à API, criação de pods privilegiados e uso de dashboards expostos.
Monitoramento de Runtime: implanta um agente leve baseado em eBPF em EC2, ECS/Fargate ou EKS para expor eventos de processo, arquivo e rede — necessário para detectar malware sem arquivo (fileless) ou shells reversos em tempo de execução.
Proteção contra Malware: escaneia snapshots de volumes EBS anexados a instâncias sinalizadas por outros findings, ou faz varreduras sob demanda de objetos S3 no momento do upload.
Proteção de Lambda e Proteção de S3: cobrem padrões de invocação de funções e acesso ao plano de dados (data-plane) do S3, respectivamente.

Habilitar apenas o serviço básico e esperar que anomalias de login em bancos de dados apareçam é uma configuração incorreta comum — os tipos de finding simplesmente não são produzidos até que o recurso correspondente seja ativado.

Security Hub como o Plano de Agregação

O Security Hub ingere achados do GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, Config, Health e produtos de ISVs de terceiros, normalizando-os para o formato AWS Security Finding Format (ASFF). Ele também executa seus próprios padrões de conformidade (AWS Foundational Security Best Practices, CIS, PCI DSS, NIST 800-53).

Para centralizar em uma Organization:

Habilite o Security Hub como um serviço no Organizations e designe um administrador delegado (geralmente a mesma conta de segurança do GuardDuty).
Ative a habilitação automática para novas contas para que os membros sejam registrados automaticamente.
Configure uma Região de agregação de achados (também chamada de Região de origem ou home Region) e vincule todas as outras Regiões a ela. Sem a agregação entre Regiões, cada Região mantém uma instância independente do Security Hub e os analistas precisam alternar entre consoles.

O padrão para uma implementação organizacional global, portanto, requer duas configurações coordenadas: o vínculo da Região de agregação e a ativação da habilitação automática para toda a organização. Habilitar uma sem a outra deixa novas contas sem cobertura ou novas Regiões isoladas.

Uma limitação importante: o Security Hub agrega e prioriza, mas não remedia. Tratá-lo como uma plataforma de remediação é um erro de categoria — a remediação acontece através do EventBridge, em uma etapa posterior.

EventBridge como a Malha de Automação

Tanto o GuardDuty quanto o Security Hub publicam achados no barramento de eventos padrão. O aws.guardduty emite eventos GuardDuty Finding, e o aws.securityhub emite Security Hub Findings - Imported (criado/atualizado pelo Hub) e Security Hub Findings - Custom Action (acionado pelo operador).

Regras excessivamente amplas, como {"source": ["aws.securityhub"]}, invocam alvos a cada atualização de achado de cada provedor, inundando rapidamente tópicos do SNS e acionando engenheiros de plantão com ruído informacional. A abordagem correta é filtrar por severity.Label, ProductArn, Types ou valores específicos de Title:

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

Para um padrão centrado no Security Hub que é acionado apenas para achados de alta severidade do GuardDuty, ignorando produtos de ISVs de terceiros que geram muito ruído:

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": { "Label": ["HIGH", "CRITICAL"] },
      "ProductArn": [
        { "wildcard": "arn:aws:securityhub:*::product/aws/guardduty" }
      ],
      "Workflow": { "Status": ["NEW"] }
    }
  }
}

Alvos comuns incluem um tópico do SNS para notificação por e-mail/SMS/Slack, uma função Lambda que isola uma instância trocando seu security group, um runbook do SSM Automation ou uma máquina de estados do Step Functions orquestrando uma resposta de múltiplos passos. Para o caso de uso de anomalia de login no Aurora, o caminho de menor esforço é GuardDuty RDS Protection → regra do EventBridge filtrada pelo tipo de achado do RDS → tópico do SNS com assinatura de e-mail. Sem polling personalizado, sem Lambda, sem necessidade de um SIEM de terceiros.

Ações Personalizadas do Security Hub (Custom Actions)

Ações personalizadas são gatilhos acionados pelo operador. No console do Security Hub, um analista seleciona um ou mais achados e escolhe uma ação personalizada (por exemplo, “Quarantine EC2”). O Security Hub emite um evento Security Hub Findings - Custom Action carregando os ARNs dos achados selecionados; uma regra do EventBridge corresponde ao ARN da ação personalizada e invoca uma Lambda que executa a resposta. Isso lhe dá um botão com intervenção humana (human-in-the-loop) sem a necessidade de construir uma UI personalizada:

aws securityhub create-action-target \
  --name "Quarantine EC2" \
  --description "Attach isolation SG and snapshot volumes" \
  --id QuarantineEC2

O ARN resultante (arn:aws:securityhub:us-east-1:111122223333:action/custom/QuarantineEC2) se torna o valor de correspondência no campo resources da regra do EventBridge.

Supressão e Gerenciamento de Sinal

O gerenciamento de ruído é uma disciplina, não um filtro aplicado uma única vez. Use regras de automação do Security Hub ou regras de supressão do GuardDuty para arquivar automaticamente achados que são conhecidamente benignos (um achado esperado de Recon:EC2/Portscan de uma ferramenta de teste de penetração, por exemplo). Filtre as regras do EventBridge por ProductArn para silenciar uma integração de terceiros que gera muito ruído sem desativá-la completamente. Combine Severity.Label com Workflow.Status = NEW para que achados reabertos ou já notificados não gerem um novo alerta. O objetivo é que cada alerta que chega a um ser humano represente um evento acionável e de alta confiança — qualquer outra coisa desgasta a prontidão de resposta.

Pivô de Investigação

Quando um achado de alta severidade é disparado — por exemplo, Backdoor:EC2/C&CActivity.B!DNS — o caminho investigativo mais rápido não é escrever manualmente queries no Athena contra o CloudTrail e os Flow Logs. O Amazon Detective, quando habilitado junto com o GuardDuty, pré-constrói grafos de entidades a partir do CloudTrail, VPC Flow Logs e achados do GuardDuty. Pivotar do achado diretamente para a role do IAM ou o instance profile do EC2 no Detective expõe a atividade de API, os pares de rede (network peers) e as contagens de conexões bem-sucedidas versus falhas dentro da janela de tempo relevante, sem nenhum trabalho de escrita de queries personalizadas.

← Gerenciamento de Identidade e Acesso · Todos os domínios · Logging →

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