APRENDER. PRATICAR. EVOLUIR.1. Restringir a ação e compreender o impacto
Uma sessão suspeita pode continuar válida enquanto as permissões aplicáveis mudam. A autorização é avaliada por pedido; a validade do token não congela os Allows originais. Confirma a propagação e o efeito observado no percurso relevante. Se uma role é partilhada, uma negação ampla pode interromper consumidores saudáveis. Examina as entidades anexadas antes de editar uma customer managed policy comum. Um seletor aws:userid dirigido a uma sessão reduz âmbito, mas o nome pode mudar num salto posterior de role. A investigação precisa de mapear sessões derivadas e concessões por recursos. Não encerres contenção apenas porque removeste um Allow de uma identity policy quando existe outro caminho de acesso aplicável.
2. Preservar num sistema que substitui recursos
Produção procura reparar instâncias unhealthy; investigação pode precisar de preservar exatamente uma dessas instâncias. DisableApiTermination protege contra certas terminações pela API EC2, mas não impede o Auto Scaling de terminar o recurso. Scale-in protection também não cobre substituição por health check. Identifica os mecanismos de ciclo de vida antes de escolher o controlo e coordena uma capacidade limpa para o serviço. A medida temporária deve ter owner, âmbito e condição de saída. Num fecho de fundos fictício, preservar um nó sem capacidade alternativa pode prejudicar o processamento, enquanto usar a imagem suspeita para criar substitutos pode espalhar a condição comprometida. O gestor técnico deve tornar estas dependências visíveis à decisão, sem substituir evidência de segurança por pressão de calendário.
3. Saber o que um snapshot contém
O snapshot EBS representa dados escritos no volume no momento do pedido. A transferência pode continuar enquanto o estado é pending; isso não transforma a captura numa janela que inclui todas as escritas até completed. Dados apenas em cache não estão garantidos nesse artefacto. Equilibra necessidades de consistência, recolha volátil e contenção, registando o que cada artefacto efetivamente cobre. O estado de cifragem é herdado do volume: uma origem não cifrada produz um snapshot não cifrado, sendo necessária uma cópia cifrada se esse for o requisito. Mantém controlo sobre as duas versões e sobre as chaves necessárias para leitura futura. No inventário, regista instante do pedido, conclusão, identidade do volume e limitações conhecidas da captura.
4. Conter mantendo um percurso de investigação
Uma NACL deny-all na subnet tem âmbito partilhado e pode atingir nós saudáveis. Uma VPC de isolamento é uma opção de arquitetura, mas uma instância EC2 existente não muda simplesmente de VPC enquanto continua em execução. O plano precisa de tratar preservação, relançamento e acessos autorizados de investigação. Se usas EC2 Triage, ter SendCommand no responder não demonstra que o agente do alvo está contactável. Testa permissões e comunicação antes de depender desse percurso numa crise. Para análise forense, protege o original e usa uma cópia de trabalho, especialmente quando a ferramenta pode modificar metadados. Hashes ajudam a verificar transferências, mas não provam que o sistema de origem estava íntegro nem que recolheste tudo o que interessa.
5. Separar aprovação, pedido e resultado
Uma automação precisa de representar três perguntas: a ação foi autorizada, o pedido foi aceite e o resultado esperado foi observado? Um gate aws:approve exige a decisão configurada; notificação entregue ou silêncio até timeout não são aprovação. Define o caminho de falha e a escalada quando o aprovador não está disponível. Depois de pedir uma operação assíncrona, usa uma observação do estado, por exemplo com aws:waitForAwsResourceProperty, antes de avançar. Escolhe propriedade, valor esperado, prazo e falha coerentes com o critério. Um sleep fixo ou um ID devolvido não demonstra conclusão. O modelo local abaixo mantém estas três dimensões separadas e trata falta de observação como estado por esclarecer, sem executar qualquer ação AWS.
6. Recuperar e entregar um serviço confiável
Erradicação deve tratar a causa e os recursos afetados. Reconstruir a partir da mesma imagem vulnerável pode restaurar serviço e a condição de entrada ao mesmo tempo. Usa uma base limpa e corrigida, preservando antes a evidência necessária. A recuperação exige responsáveis do cliente para restaurar e validar aplicações; o serviço AWS Security Incident Response fornece orientação, sem executar diretamente todos os restauros. Define verificações técnicas e de negócio, observação reforçada e critérios para retirar medidas temporárias. No exercício, calcula o resultado esperado para aprovação ausente, pedido falhado, estado desconhecido, pending e completed. No handover real, entrega resultados e exceções com owners, em vez de um único indicador verde. A conclusão precisa de demonstrar o objetivo operacional acordado.
# Original local evidence-gate model; not an SSM executor or incident policy.
# No credentials, network calls, or AWS changes.
def gate(approved, request_accepted, observed_state):
if not approved:
return "approval-required"
if not request_accepted:
return "request-failed"
if observed_state is None:
return "observation-required"
if observed_state == "pending":
return "wait"
if observed_state == "completed":
return "ready"
return "escalate"
cases = [
(False, False, None, "approval-required"),
(True, False, None, "request-failed"),
(True, True, None, "observation-required"),
(True, True, "pending", "wait"),
(True, True, "completed", "ready"),
(True, True, "error", "escalate"),
]
for approved, accepted, state, expected in cases:
assert gate(approved, accepted, state) == expected
print("six evidence-gate cases passed")
Uma recolha foi aprovada e devolveu um ID, mas a consulta de estado falhou. O artefacto fica por confirmar e o owner de automação trata a permissão em falta.
Armadilhas comuns
Permissões congeladas; proteção EC2 como proteção universal; pending como captura contínua; aprovação como resultado; hash como prova de completude.
Tópicos relacionados: Resposta, contenção e preservação · KMS: delegação, contexto e recuperação
Confirma cada etapa com a evidência que lhe corresponde e mantém explícitos os impactos no serviço.
Referência: Disabling permissions for temporary credentials · SCS-C03