Automação de Resposta a Incidentes com SSM Automation, EventBridge e Quarantine SG — Guia Completo para o SCS-C03
_Category: Incident Response_
Incidentes de segurança chegam sem aviso. Quando um alerta do GuardDuty aparece, o analista responsável pode estar dormindo ou a equipe pode estar em reunião. Na segurança cloud moderna, automação não é um diferencial — é o piso mínimo. Antes de qualquer pessoa intervir, a instância já deve estar isolada, as evidências preservadas e a equipe notificada. Neste guia, percorremos todo o ciclo de resposta a incidentes na AWS — da detecção ao isolamento, coleta de evidências e recuperação — com foco nos cenários do exame SCS-C03.
---
Mentalidade de Resposta a Incidentes na Era Cloud
No ambiente on-premises, responder a um incidente de segurança significava acesso físico e trabalho manual: entrar no servidor, revirar logs, desconectar cabos de rede. Esse processo levava horas. Na AWS, três coisas mudam fundamentalmente.
Primeiro, infraestrutura é código. Isolar um EC2, tirar um EBS Snapshot e iniciar uma nova instância são todos operações de uma única chamada de API. O Lambda executa isso em segundos, sem intervenção humana. Segundo, tudo é evento. Ameaças detectadas pelo GuardDuty, ACLs públicas configuradas no S3, uso anômalo de chaves IAM — tudo flui para o EventBridge. Pense no EventBridge como o alarme automático que toca no exato momento em que algo acontece. Terceiro, infraestrutura imutável. Instâncias comprometidas não são reparadas. Elas são isoladas, documentadas com um snapshot e substituídas por instâncias limpas. É o equivalente a enviar um paciente infectado para a sala de isolamento antes de qualquer outra ação.
Essa mudança de mentalidade — de reativo e manual para proativo e automatizado — é o que o exame SCS-C03 testa em praticamente toda questão de Incident Response.
---
Ciclo de Vida IR Baseado no NIST e Mapeamento de Serviços AWS
O NIST SP 800-61 define o ciclo de resposta a incidentes em sete fases. A AWS mapeou serviços concretos para cada uma delas. O exame frequentemente pergunta qual serviço usar em determinada fase — conhecer essa tabela é essencial.
| Fase IR | Objetivo | Serviços AWS Principais | |---------|----------|-------------------------| | Prepare (Preparação) | Configurar ferramentas, permissões e Runbooks antecipadamente | Systems Manager Incident Manager, IAM Role, SSM Automation Runbook | | Detect (Detecção) | Identificar ameaças e gerar alertas | GuardDuty, Security Hub, Macie, CloudTrail, Config | | Analyze (Análise) | Determinar escopo do impacto e causa raiz | Detective, CloudTrail, CloudWatch Logs Insights, Athena | | Contain (Contenção) | Evitar propagação adicional | Quarantine SG, VPC Isolation, IAM Policy Revoke, EventBridge + Lambda | | Eradicate (Erradicação) | Remover elementos maliciosos | SSM Automation, Systems Manager Run Command, Lambda | | Recover (Recuperação) | Restaurar serviços ao estado normal | AWS Backup, AMI, CloudFormation StackSet | | Lessons Learned (Lições Aprendidas) | Prevenir recorrência | Revisão de Findings do Security Hub, reforço de Config Rules, atualização de Runbooks |
Essa tabela é o esqueleto das questões do exame. Os padrões que se repetem são: "determinar escopo de comprometimento" → Detective; "isolamento imediato" → Quarantine SG + Lambda; "automação de recuperação" → AWS Backup ou CloudFormation. A fase de Preparação é a mais crítica: sem Runbooks prontos, humanos precisam tomar decisões sob pressão, e isso custa tempo. Com SSM Automation Runbooks escritos e testados antecipadamente, toda a velocidade de resposta muda.
---
Detecção e Disparo: Findings do GuardDuty e Security Hub com EventBridge
Toda automação começa na detecção. Ameaças do GuardDuty, findings do Security Hub, chamadas de API anômalas no CloudTrail — todos esses eventos chegam ao EventBridge. O EventBridge filtra esses eventos e os roteia para Lambda, SSM Automation, Step Functions, SNS e outros destinos.
O fluxo típico é: GuardDuty Finding → EventBridge Rule (filtro por tipo e severidade) → Lambda (lógica de isolamento) → aplicação do Quarantine SG + EBS Snapshot + notificação SNS.
Ao configurar regras do EventBridge, tome cuidado para não reagir a todos os findings do GuardDuty. Falsos positivos podem provocar isolamentos desnecessários e impactar serviços legítimos. Os padrões de eventos devem ser escritos com precisão: apenas severidade HIGH ou superior, ou tipos específicos de finding como . As Custom Actions do Security Hub oferecem um caminho intermediário entre automação completa e aprovação manual: a equipe de segurança seleciona um finding no console e clica em "Iniciar Isolamento", o que dispara o EventBridge → Lambda.
Para não confundir os dois serviços de eventos, veja a comparação:
| Item | EventBridge | CloudWatch Events | |------|-------------|-------------------| | Relação | EventBridge substituiu o CloudWatch Events | Serviço de roteamento de eventos anterior ao EventBridge | | Event Bus | Bus padrão + buses customizados + buses de parceiros | Apenas bus padrão | | Integração com terceiros | Recebe eventos de parceiros SaaS (Datadog, PagerDuty etc.) | Não suportado | | Recomendação | Use EventBridge em novas arquiteturas | Legado |
Em questões sobre "disparo automático de resposta baseado em evento de incidente", sempre escolha EventBridge. O CloudWatch Events é legado e não é recomendado em arquiteturas novas.
---
Padrões de Isolamento Automático: Quarantine SG, Revogação IAM e Separação de Snapshot
A contenção é a fase onde o tempo mais importa. Cada segundo que uma instância comprometida continua se comunicando com o exterior representa dano potencial adicional.
Padrão Quarantine SG
O Quarantine SG (Security Group de quarentena) funciona como a sala de isolamento para pacientes infectados. Crie antecipadamente um Security Group que bloqueia todo tráfego de entrada e saída. Quando o Lambda é acionado, ele chama , removendo todos os SGs existentes e substituindo pelo Quarantine SG. Adicionar o Quarantine SG sem remover os existentes não resolve — as regras antigas continuam ativas. É substituição, não adição. A lista original de SGs deve ser salva separadamente para ser reaplicada na recuperação. Se a equipe de forense precisar de acesso, adicione ao Quarantine SG uma única regra de entrada permitindo apenas o IP da sub-rede de análise forense.
Revogação de IAM Role e Políticas
Revogar imediatamente o IAM Role associado à instância EC2 comprometida, ou adicionar uma política inline que restrinja as permissões, também faz parte da contenção. Em caso de exposição de chaves de acesso IAM, a desativação da chave é prioridade absoluta. Quando credenciais expostas são detectadas automaticamente, a AWS anexa a política à entidade comprometida. Se você encontrar essa política, significa que a equipe AWS Trust & Safety já detectou a exposição. Não delete essa política. O caminho correto é desativar a chave, investigar com CloudTrail o escopo do dano e emitir novas credenciais. Credenciais obsoletas (chaves sem uso por 90 dias ou mais) devem ser tratadas com uma automação periódica: Lambda agendado combinando IAM Credential Report e Access Analyzer.
Separação de EBS Snapshot e Configuração do Ambiente Forense
Imediatamente após o isolamento, preserve as evidências com um EBS Snapshot. Se a instância for encerrada primeiro, os dados do instance store são perdidos permanentemente. O snapshot vem antes do encerramento.
| Método de Isolamento | Disponibilidade do Serviço | Preservação de Evidências | Bloqueio de Rede | |----------------------|---------------------------|---------------------------|------------------| | Aplicar Quarantine SG | Mantida (instância continua rodando) | Volume EBS preservado | Bloqueio completo possível | | Encerrar instância | Auto Scaling inicia nova instância | Dados do instance store perdidos | Bloqueio completo |
Para instâncias pertencentes a um Auto Scaling Group (ASG), o fluxo correto é: primeiro desanexar do ASG sem encerrar (Detach) — isso preserva a disponibilidade, pois o ASG sobe uma nova instância automaticamente — e depois aplicar o Quarantine SG. Na análise forense, crie um novo volume EBS a partir do snapshot e monte-o em uma instância de análise dedicada. Acessar o volume original diretamente compromete a integridade das evidências.
!3 padrões de isolamento automático
Codificando Runbooks com SSM Automation e Lambda
O SSM Automation permite escrever procedimentos operacionais padrão (SOPs) como documentos YAML e executá-los automaticamente. Um Runbook de isolamento de EC2, por exemplo, seria: Etapa 1 — criar EBS Snapshot; Etapa 2 — aplicar Quarantine SG; Etapa 3 — enviar notificação SNS. Cada etapa pode ter rollback ou pular configurados para caso de falha.
Lambda e SSM Automation têm papéis distintos. Lambda é ideal para ações únicas rápidas — trocar SG, desativar chave. SSM Automation é mais adequado para workflows sequenciais com múltiplos passos. A combinação mais eficiente é: EventBridge → Lambda (isolamento rápido) → SSM Automation (coleta forense, notificações). Isso captura velocidade e completude ao mesmo tempo. Para cenários de alta complexidade que exigem execução paralela, tratamento sofisticado de erros e retries configuráveis, Step Functions oferece maior flexibilidade.
Um detalhe importante para o exame: quando a questão mencionar "aprovação humana no meio do processo", a resposta é Step Functions com um estado de espera de callback — não SSM Automation puro.
---
Systems Manager Incident Manager: Colaboração e Engajamento de Equipes
O Systems Manager Incident Manager é o serviço que estrutura a colaboração entre múltiplas equipes durante incidentes operacionais e de segurança. Três conceitos são suficientes para responder às questões do exame.
Response Plan é o plano pré-definido que distribui papéis, define quais Runbooks executar e quais canais de comunicação usar quando um i