Pular para o conteúdo
Logs e Incidentes13 min de leituraAtualizado em Por Equipe GUARDIASEC

Resposta a incidentes na AWS: primeiros passos e cuidados críticos

Os primeiros minutos definem a investigação. Veja como conter sem destruir evidências em um incidente na AWS.

Quando há suspeita de comprometimento na AWS, a reação instintiva costuma ser desligar tudo. Esse instinto pode destruir evidências essenciais e dificultar entender o que aconteceu. Resposta a incidentes é equilibrar duas necessidades que parecem opostas: conter o dano e preservar a evidência. Os primeiros passos, feitos com calma e método, definem a qualidade de toda a investigação.

Este guia traz orientações de primeiros passos para incidentes em ambientes AWS, com foco defensivo e em preservação de evidência. Não substitui um plano de resposta formal nem uma equipe especializada, mas ajuda a não cometer os erros mais comuns nos minutos iniciais.

Preparação: decisões que não esperam o incidente

A qualidade da resposta se decide antes de o incidente começar. No meio da pressão não dá para descobrir quem aciona quem, onde estão os logs ou como isolar um recurso sem derrubar a operação. Um plano simples, escrito e conhecido pela equipe vale mais do que qualquer improviso brilhante no calor do momento.

  • Plano de resposta escrito, com fluxo de acionamento e escalonamento
  • Papéis definidos: quem coordena, quem investiga, quem comunica
  • Acesso quebra-vidro para agir quando as credenciais normais são suspeitas
  • Uma rota forense, como conta ou VPC dedicada para análise isolada
  • Contatos atualizados, incluindo jurídico e comunicação quando aplicável

Um plano que nunca foi ensaiado costuma falhar na primeira vez que é usado. Exercícios de mesa, em que a equipe percorre um cenário hipotético e testa as decisões, revelam lacunas com antecedência: um contato desatualizado, um log que ninguém sabe onde fica, uma permissão que falta. É muito mais barato descobrir isso em um ensaio do que durante um incidente real.

Isolar sem destruir

Para uma instância suspeita, prefira isolar em vez de terminar. Isolar significa restringir a rede com um Security Group restritivo, removendo a comunicação com o exterior, mas mantendo a instância de pé para análise. Terminar a instância pode apagar dados em memória e em disco que seriam cruciais para entender o ataque.

Antes de qualquer alteração destrutiva, capture um snapshot do volume para preservar o estado do disco. Documente cada ação com horário, porque a linha do tempo da resposta também faz parte da evidência.

Credenciais e identidade

Se há suspeita de credenciais comprometidas, como uma access key vazada, a contenção envolve revogar ou rotacionar a credencial e revisar o que ela pode ter feito. O CloudTrail é a fonte central para reconstruir a atividade daquela identidade: de onde veio, o que acessou e o que alterou. Verifique criação de novos usuários, novas chaves e mudanças de permissão, táticas comuns de persistência.

  • Revogar ou rotacionar credenciais suspeitas
  • Revisar atividade da identidade no CloudTrail
  • Procurar criação de usuários, chaves e roles inesperadas
  • Verificar mudanças de política e de configuração de segurança
  • Checar atividade em regiões normalmente não usadas

Fases da resposta e contenção técnica

Modelos de referência descrevem a resposta em fases: preparação, detecção e análise, contenção, erradicação, recuperação e lições aprendidas. Elas não são uma sequência rígida, mas ajudam a saber em que ponto do trabalho você está e o que não pode ser pulado. As três primeiras concentram os erros mais caros, porque é nelas que a pressa destrói evidência.

Preservar antes de conter

Antes de qualquer ação que altere o recurso, capture o estado. Um snapshot do volume preserva o disco para análise posterior, mesmo que a instância precise ser isolada logo em seguida. Registre o horário de cada comando, porque a ordem das ações também é evidência.

Preservar o estado do disco antes de agir
aws ec2 create-snapshot \
  --volume-id vol-0exemplo \
  --description "resposta-a-incidente preservacao 2026-07-24"

Isolar identidade e rede

A contenção corta o alcance do atacante sem apagar rastros. No plano de rede, troque o grupo de segurança da instância por um de isolamento, que remove a comunicação com o exterior mas mantém o recurso de pé. No plano de identidade, desative a credencial suspeita para interromper o uso enquanto a investigação segue.

Desativar uma access key suspeita (contenção de identidade)
aws iam update-access-key \
  --access-key-id AKIAEXEMPLO \
  --status Inactive \
  --user-name usuario-afetado

Depois de conter, a erradicação remove a presença do atacante e a recuperação restabelece o serviço a partir de uma base confiável. Reconstruir de uma imagem íntegra é mais seguro do que tentar limpar um sistema comprometido, e todo segredo que possa ter sido exposto precisa ser rotacionado antes de voltar à operação.

Contenção, comunicação e lições

A contenção busca impedir que o incidente avance enquanto a investigação ocorre. Comunique as pessoas certas desde cedo, segundo o plano definido, evitando tanto o silêncio quanto o pânico generalizado. Mantenha um registro central da timeline, das decisões e das evidências coletadas.

Depois da contenção e da recuperação, faça uma análise do que aconteceu e do que permitiu o incidente. O objetivo não é culpar, e sim corrigir a causa raiz e fortalecer os controles, para reduzir a chance de repetição.

Checklist prático

  • Isolar recursos suspeitos com rede restritiva, sem terminar de imediato
  • Capturar snapshot dos volumes antes de mudanças destrutivas
  • Revogar ou rotacionar credenciais suspeitas
  • Reconstruir a atividade da identidade no CloudTrail
  • Procurar persistência: novos usuários, chaves e roles
  • Verificar mudanças de política e atividade em regiões incomuns
  • Documentar a timeline e as decisões com horário
  • Comunicar as pessoas certas conforme o plano
  • Conter o avanço antes de partir para recuperação
  • Fazer análise de causa raiz e fortalecer controles
  • Manter plano, papéis e contatos definidos antes do incidente
  • Preparar acesso quebra-vidro e uma rota forense isolada
  • Ensaiar a resposta com exercícios de mesa
  • Reconstruir a partir de imagem confiável e rotacionar segredos expostos

Boas práticas

  • Tenha um plano de resposta definido antes do incidente
  • Prefira isolar a destruir para preservar evidência
  • Capture snapshots antes de qualquer ação destrutiva
  • Use o CloudTrail como base para a linha do tempo
  • Registre tudo de forma central e com horário
  • Encerre com análise de causa raiz, sem buscar culpados
  • Ensaie o plano com exercícios de mesa antes de precisar dele
  • Na recuperação, reconstrua de base confiável em vez de remendar

Erros comuns

  • Terminar a instância suspeita imediatamente

    Destrói evidências em memória e disco essenciais para entender o ataque.

  • Não capturar snapshot antes de agir

    O estado do disco é perdido e a análise forense fica comprometida.

  • Esquecer de procurar persistência

    O atacante mantém acesso por usuários ou chaves criados durante o incidente.

  • Não documentar a timeline

    A reconstrução fica frágil e decisões importantes se perdem.

  • Responder sem plano e sem comunicação

    Ações descoordenadas, pânico ou silêncio que agravam o impacto.

  • Não preparar acesso quebra-vidro

    Quando as credenciais normais são suspeitas, a equipe fica sem caminho seguro para agir.

  • Remendar o sistema comprometido na recuperação

    Restos de persistência sobrevivem e o atacante retoma o acesso depois.

Quando procurar apoio especializado

Um incidente real exige experiência e cabeça fria. A GUARDIASEC apoia a estruturação de detecção e resposta no serviço de Monitoramento e Resposta, definindo playbooks e fluxos de contenção antes que o incidente aconteça.

Perguntas frequentes

Devo desligar a instância comprometida imediatamente?

Em geral não. Terminar a instância pode apagar evidências em memória e disco. O recomendado é isolar a instância restringindo a rede, mantendo-a de pé, e capturar um snapshot do volume antes de qualquer ação destrutiva. Assim você contém o dano e preserva a evidência ao mesmo tempo.

Uma access key vazou. Qual o primeiro passo?

Revogue ou rotacione a credencial para conter o acesso e, em paralelo, use o CloudTrail para reconstruir tudo que aquela identidade fez. Procure sinais de persistência, como novos usuários, novas chaves e mudanças de permissão. A contenção e a investigação caminham juntas nos primeiros momentos.

Preciso de um plano de resposta mesmo sendo uma empresa pequena?

Sim. Não precisa ser extenso, mas precisa existir: quem é acionado, como isolar, onde estão os logs e como comunicar. Definir isso antes evita decisões ruins sob pressão. Um plano simples e ensaiado vale muito mais do que improvisar no meio de um incidente real.

Por que documentar a linha do tempo do incidente?

Porque a timeline é parte da evidência e da aprendizagem. Registrar cada ação com horário ajuda a entender a sequência do ataque, a avaliar a eficácia da resposta e a sustentar decisões posteriores. Também é fundamental para a análise de causa raiz e para eventuais obrigações de comunicação.

O que é acesso quebra-vidro e por que preparar antes?

Acesso quebra-vidro é uma credencial ou caminho de emergência, guardado de forma segura, que permite agir quando as identidades normais estão comprometidas ou indisponíveis. Preparar antes é essencial porque, no meio de um incidente, você pode não confiar nas credenciais de uso diário. Esse acesso deve ter uso auditado e alerta associado, para ser usado só em emergência e nunca no dia a dia.

Qual a diferença entre contenção, erradicação e recuperação?

Contenção corta o alcance do atacante sem destruir evidência, por exemplo isolando a rede da instância e desativando credenciais suspeitas. Erradicação remove a presença do atacante e a causa que permitiu a entrada. Recuperação restabelece o serviço a partir de uma base confiável e confirma que o ambiente voltou ao normal. São fases distintas, e pular da contenção direto para a recuperação costuma deixar persistência para trás.

O que é um exercício de mesa e por que fazer?

É uma simulação em que a equipe percorre um cenário de incidente hipotético e discute as decisões, sem mexer no ambiente real. Serve para testar o plano antes que ele seja necessário: revela contatos desatualizados, logs que ninguém sabe localizar e permissões que faltam. Descobrir essas lacunas em um ensaio custa muito menos do que descobri-las durante um incidente de verdade.

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.