Microsoft AZ-500: Resposta a Incidentes, Recuperação e Resiliência — Guia de estudos

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Faz parte do Microsoft Azure Security Engineer Associate AZ-500 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

A resposta a incidentes, a recuperação e a resiliência no Azure são uma capacidade contínua que combina procedimentos operacionais bem ensaiados com controles nativos da plataforma. Um programa eficaz antecipa falhas ou comprometimentos, detecta e faz a triagem rapidamente, contém o raio de alcance (blast radius) com automação, restaura o serviço para objetivos definidos, preserva evidências imutáveis e, em seguida, fortalece o ambiente com base no que foi aprendido. Serviços nativos do Azure — Microsoft Sentinel, Defender for Cloud, Logic Apps, Azure Backup, Azure Site Recovery (ASR), DDoS Protection, Web Application Firewall (WAF), Traffic Manager/Front Door e Microsoft Entra — fornecem os componentes fundamentais. O imperativo do design é pré-configurar a telemetria correta, os caminhos de acesso de emergência (break-glass) de identidade e a aplicação automatizada de políticas para que as equipes possam executar as ações em minutos, não em horas.

Ciclo de vida da resposta a incidentes e operações do Sentinel

• Preparação

  • Defina quem faz o quê, quando e com quais ferramentas. Pré-provisione workspaces do Microsoft Sentinel, conecte fontes de dados (Activity Log, logs de recursos, logs de fluxo de NSG, logs de auditoria/entrada do Microsoft Entra, sinais do Defender) e implemente controles de acesso e RBAC para analistas, respondentes e comandantes de incidentes.
  • Crie playbooks (Logic Apps) para ações de contenção comuns, como isolamento de VM, revogação de token de usuário ou rotação de chaves. Pré-configure NSGs de quarentena e assinaturas dedicadas para “análise forense” (forensics).
  • Estabeleça a retenção de logs imutáveis por meio das Configurações de Diagnóstico (Diagnostic Settings) para o Log Analytics e para uma conta do Azure Storage com imutabilidade (WORM).

• Detecção

  • No Sentinel, habilite regras de análise para roubo de credenciais, padrões de login raros, execução de processos suspeitos, abuso do key vault e exfiltração de dados. Aumente com UEBA e regras de fusão para correlacionar eventos benignos em incidentes significativos. Calibre os limites das regras e a supressão para minimizar a fadiga de alertas.

• Contenção

  • Execute ações pré-aprovadas: coloque NICs em quarentena via NSG, desabilite service principals comprometidos, revogue tokens de atualização do Entra, rotacione segredos, desabilite endpoints públicos de entrada ou coloque o WAF em modo de prevenção. Use regras de automação do Sentinel para rotear por severidade, adicionar tags, atribuir responsáveis e acionar playbooks.

• Erradicação

  • Remova a persistência (tarefas de inicialização, trabalhos agendados, scripts cloud-init, extensões maliciosas), rotacione credenciais, reimplemente imagens douradas (golden images) e aplique patches em vulnerabilidades sinalizadas pelo Defender for Cloud. Para incidentes relacionados à identidade, exija redefinições de senha e fortaleça o Acesso Condicional (Conditional Access).

• Recuperação

  • Restaure a partir do Azure Backup para VNets limpas; faça failover usando planos de recuperação do ASR; valide a integridade e reidrate segredos e configurações de fontes conhecidamente boas (templates de IaC, Key Vault com exclusão reversível/proteção contra limpeza). Garanta que o RTO e o RPO sejam atendidos.

• Lições aprendidas

  • Conduza uma revisão sem atribuição de culpa (blameless review). Atualize as regras e playbooks do Sentinel, as atribuições do Azure Policy, as imagens de base e os runbooks. Codifique as remediações em IaC e aplique-as por meio de grupos de gerenciamento.

Triagem, coleta de evidências, investigação e gerenciamento de casos no Sentinel

• Triagem

  • Priorize incidentes por severidade, criticidade do ativo e raio de alcance (blast radius) usando o enriquecimento de entidades (host, usuário, IP) e watchlists. Use o agrupamento de incidentes para reduzir duplicatas e a visualização de linha do tempo (timeline) para entender a sequência.

• Coleta de evidências

  • Marque eventos notáveis (bookmark), exporte logs brutos para armazenamento imutável, crie snapshots de discos de VM afetados para análise offline e capture árvores de processos por meio de integrações com o Defender for Endpoint. Preserve a cadeia de custódia (chain-of-custody) armazenando hashes e limitando o acesso a um grupo de recursos de análise forense.

• Investigação

  • Use gráficos de investigação e páginas de entidade (histórico de login do usuário, árvore de processos do host). Faça buscas (hunt) com KQL em SigninLogs, AuditLogs, SecurityEvent e AzureDiagnostics. Registre as descobertas, anexe artefatos e marque IOCs para detecção futura.

• Gerenciamento de casos

  • Padronize os status (Novo, Ativo, Em Andamento, Resolvido), os responsáveis e os cronômetros de SLA. Integre o Sentinel com ITSM (ServiceNow/Azure DevOps) para emissão de tickets e controle de alterações. As regras de automação podem fechar automaticamente alertas benignos conhecidos ou escalar táticas específicas para o Nível 2 (Tier 2).

Contenção automatizada e orquestração de fluxo de trabalho

• Regras de automação do Sentinel

  • Acione na criação/atualização de um incidente. Atribua dinamicamente a responsabilidade, defina a severidade, adicione tags (ex: QuarantineCandidate) e invoque um ou mais playbooks. Justificativa: passar da detecção para a ação em segundos, de forma consistente com o princípio do menor privilégio e com playbooks pré-aprovados.

• Playbooks do Logic Apps

  • Ações comuns: aplicar um NSG de quarentena a uma NIC de VM, desabilitar um usuário, revogar tokens, bloquear um IP no WAF ou abrir um ticket de ITSM com o contexto completo. Use identidades gerenciadas e o Azure RBAC para definir o escopo das permissões de cada playbook para o conjunto exato de recursos.

• Automação de fluxo de trabalho do Defender for Cloud

  • Em recomendações ou alertas (ex: “RDP aberto para a Internet”), acione automaticamente playbooks para remediar (restringir regras de NSG), marcar recursos para acompanhamento ou notificar os responsáveis. Justificativa: fechar a exposição rapidamente, melhorando o Secure Score e diminuindo o tempo de permanência do invasor (attacker dwell time).

Exemplo: colocar uma NIC de VM em quarentena em segundos

# Create a high-priority deny-all inbound NSG rule and associate a quarantine NSG to the NIC
az network nsg rule create -g rg-prod -n QuarantineDenyAll --nsg-name nsg-quarantine \
  --priority 100 --access Deny --direction Inbound --protocol '*' --source-address-prefixes '*' \
  --source-port-ranges '*' --destination-address-prefixes '*' --destination-port-ranges '*'

az network nic update -g rg-prod -n vm1-nic --network-security-group nsg-quarantine

Revogação de token para um usuário comprometido

az rest --method POST \
  --uri "https://graph.microsoft.com/v1.0/users/user@contoso.com/revokeSignInSessions"

Backup, replicação, RTO/RPO e resiliência

Segurança do Azure Backup

• Cofres dos Serviços de Recuperação e cofres de Backup

  • Use cofres por limite de workload e por região. Habilite a exclusão reversível (soft delete) para proteger contra a exclusão acidental/maliciosa de itens de backup; defina uma janela de retenção apropriada e alinhada às necessidades regulatórias. Habilite a proteção contra limpeza (purge protection), onde for compatível, para evitar exclusões irreversíveis.

• Imutabilidade

  • Configure a imutabilidade do cofre. Use o modo desbloqueado durante o ajuste inicial e, em seguida, mude para o modo bloqueado para impedir a redução da retenção ou a adulteração da política. Justificativa: garante que os backups sejam do tipo write-once (gravação única) e à prova de modificação, um controle anti-ransomware fundamental.

• Autorização multiusuário (MUA)

  • Proteja operações críticas de backup (por exemplo, parar a proteção com exclusão de dados, alterar as configurações do cofre) usando o Azure Backup Resource Guard em uma assinatura/grupo de recursos separado, de propriedade de uma equipe diferente. Justificativa: impõe a separação de funções; os invasores precisam comprometer duas identidades em escopos diferentes para destruir a capacidade de recuperação.

• Recursos entre regiões

  • Para RSV usando GRS, habilite a restauração entre regiões para recuperar mesmo que a região primária esteja indisponível. Valide se as chaves criptográficas usadas pelas workloads também são resilientes (exclusão reversível/proteção contra limpeza do Key Vault e, se necessário, planejamento de recuperação com redundância geográfica).

Azure Site Recovery (ASR)

• Replicação

  • Azure para Azure, VMware/Hyper-V para Azure e servidores físicos. Defina políticas de replicação (limite de RPO, retenção de pontos de recuperação, frequência de snapshots consistentes com o aplicativo). Implante o serviço de Mobilidade onde for necessário.

• Planos de recuperação

  • Orquestre o failover de aplicativos de várias camadas com ordem de inicialização, etapas manuais e runbooks (por exemplo, atualizações de DNS, trocas de connection strings). Mantenha credenciais e scripts no Key Vault.

• Failover de teste

  • Realize testes regulares e não disruptivos em uma VNet isolada com IPs mascarados. Use “Limpar failover de teste” para redefinir o estado. Justificativa: valida a recuperação de ponta a ponta sem impactar a produção.

• Failback

  • Após a recuperação do site primário, reproteja e faça o failback, ressincronizando as alterações. Planeje janelas de largura de banda e manutenção para atender aos SLAs de negócio.

Selecionando a arquitetura para atender ao RTO/RPO

• RPO rígido (segundos a minutos) e RTO baixo (minutos)

  • Prefira o ASR ou a replicação nativa da aplicação (por exemplo, SQL Always On, Cosmos DB multirregional) em vez de backups; mantenha um standby hot (ativo) ou warm (morno); use o Front Door/Traffic Manager para failover regional.

• RPO moderado (horas) e RTO moderado (horas)

  • Combine backups frequentes com o ASR para camadas críticas; use recursos de aceleração de backup (snapshots de restauração instantânea) para reduzir o tempo de restauração.

• RPO longo (dias) e RTO longo (dias)

  • Apenas backup com retenção mais longa; camadas de arquivamento otimizadas para custo.

Raciocínio operacional: a replicação oferece um RPO baixo a um custo contínuo mais alto; os backups oferecem retenção de longo prazo mais barata, mas com RTO/RPO mais lentos. Combine por camada para corresponder à análise de impacto nos negócios.

Defesa de rede, forense, continuidade e hardening

Resposta a DDoS do Azure, ajuste de WAF e failover de gerenciamento de tráfego

• DDoS Protection Standard

  • Associe a VNets que hospedam IPs públicos. Ele fornece mitigação adaptativa em tempo real e suporte do DDoS Rapid Response (DRR) durante ataques. Configure alertas e diagnósticos para o Sentinel. Justificativa: mitigação automática na borda antes que o tráfego alcance as cargas de trabalho.

• Ajuste de WAF

  • Use conjuntos de regras gerenciadas do OWASP e mude para o modo de prevenção. Adicione exclusões para padrões benignos conhecidos, ative a inspeção do tamanho/corpo da solicitação onde necessário e crie regras personalizadas para permitir/negar e aplicar limitação de taxa (rate limiting) em IPs ou geografias abusivas. Refine continuamente com base nos logs.

• Failover de tráfego

  • Use o Traffic Manager (baseado em DNS) com roteamento por prioridade e TTL baixo para failover de região, ou o Azure Front Door (anycast L7) para um failover mais rápido orientado por sondas de integridade (health probes) e entrada global. Sonde endpoints críticos e realize exercícios de failover regularmente.

Forense: logs e retenção imutável

• Activity Log

  • Audite ações do plano de controle (criação/exclusão/atribuições de função). Transmita para o Sentinel e para o Azure Storage com imutabilidade para retenção legal (legal hold).

• Logs de recursos

  • Habilite através das Configurações de Diagnóstico (Diagnostic Settings) para serviços essenciais (Key Vault, App Service, Storage, SQL, AKS). Roteie para o Log Analytics, Event Hub e armazenamento imutável.

• Logs de fluxo de NSG

  • Habilite no Network Watcher; analise com o Traffic Analytics para reconstruir fluxos de rede durante incidentes.

• Logs de entrada e auditoria do Microsoft Entra

  • Ingira no Sentinel para investigações de identidade. Monitore entradas de risco e resultados do acesso condicional. Estenda a retenção através do arquivamento do Log Analytics e/ou exporte para o armazenamento imutável.

Controles de emergência (break-glass) e continuidade

• Mantenha pelo menos duas contas de emergência (break-glass) de Administrador Global somente na nuvem com senhas longas e complexas, excluídas das políticas de Acesso Condicional e MFA para sobreviver a interrupções. Armazene as credenciais de forma segura offline e monitore qualquer entrada com alertas em tempo real. Atribua funções permanentes limitadas em outros locais; use o PIM para elevação just-in-time durante as operações normais.
• Documente os procedimentos de acesso de emergência, incluindo a opção “Elevar acesso para gerenciar todas as assinaturas do Azure” do Entra e os passos para atribuir a função de Proprietário (Owner) no grupo de gerenciamento raiz se o RBAC estiver corrompido.
• Proteja ativos críticos com bloqueios de gerenciamento (CanNotDelete) e restrinja o escopo da atribuição de função usando grupos de gerenciamento.

Hardening pós-incidente

• Aplique o Azure Policy nos grupos de gerenciamento para impor uma linha de base (por exemplo, DeployIfNotExists para extensões antimalware, criptografia de disco, configurações de diagnóstico, acesso JIT a VMs). Corrija a não conformidade com tarefas de remediação de política.
• Melhore a detecção ajustando as análises do Sentinel (adicione novos IOCs, ajuste limiares), convertendo investigações (hunts) bem-sucedidas em regras agendadas e adicionando regras de automação para triagem.
• Atualize as linhas de base de segurança (imagens, políticas do Key Vault, regras de NSG/WAF). Capture todas as alterações como código (Bicep/Terraform) e valide com CI/CD e controle de alterações. Acompanhe o Secure Score e a conformidade regulatória para medir o progresso.

Cenário de Problema Prático

A Starbucks enfrenta um aumento de entradas suspeitas seguido por uma saída anômala de dados do armazenamento de uma assinatura de produção que hospeda uma API de pedidos. A equipe de segurança deve conter, investigar e restaurar o serviço, preservando as evidências e cumprindo um RTO de duas horas e um RPO de 15 minutos para a camada da API.

1. Automatize a triagem e contenha o raio de alcance do ataque (blast radius)

• No Sentinel, uma regra de automação é acionada em incidentes de alta severidade com entidades do grupo de recursos da API de pedidos, atribui o incidente ao analista de plantão, marca-o como QuarantineCandidate e executa um playbook para:
  • Revogar as sessões do usuário comprometido.
  • Aplicar um NSG de quarentena às NICs do conjunto de dimensionamento de VMs da API.
  • Adicionar uma regra personalizada no WAF para bloquear os intervalos de IP ofensivos.
• Justificativa: A automação executa ações pré-aprovadas e de menor privilégio em segundos, diminuindo o tempo de permanência do invasor e impedindo mais saídas de dados.

2. Preserve evidências com imutabilidade

• O playbook tira snapshots dos discos de SO/dados das VMs afetadas e exporta o Activity Log, os logs de fluxo de NSG e os logs da conta de Armazenamento para os contêineres de destino para uma conta do Azure Storage com imutabilidade baseada em tempo e retenção legal (legal hold). Marcadores (Bookmarks) e consultas KQL são anexados ao incidente do Sentinel.
• Justificativa: O armazenamento imutável garante a cadeia de custódia; os snapshots permitem a análise forense offline sem alterar os sistemas comprometidos.

3. Recupere o serviço para atender ao RTO/RPO

• Como a camada da API está protegida pelo ASR com uma frequência de snapshots consistentes com a aplicação de 15 minutos, a equipe executa um plano de recuperação priorizado para fazer o failover da camada da API para a região pareada. O Azure Front Door realiza o failover baseado em sondas de integridade para o endpoint secundário.
• Justificativa: A replicação atende ao RPO de 15 minutos, e o failover orquestrado somado ao roteamento do Front Door atende ao RTO de duas horas sem a necessidade de restauração a partir de backup.

4. Remedeie identidades e segredos

• Administradores privilegiados rotacionam credenciais e chaves no Key Vault (com exclusão reversível (soft delete) e proteção contra limpeza (purge protection) ativadas) e desativam a conta comprometida, aplicando um Acesso Condicional mais forte para funções privilegiadas.
• Justificativa: Segredos e identidades são vetores de persistência comuns; a rotação rápida e controles de acesso mais rigorosos impedem a reentrada do invasor.

5. Hardening e validação pós-incidente

• A equipe ajusta as regras gerenciadas do WAF, adiciona uma regra personalizada de limitação de taxa (rate-limiting), integra a conta de Armazenamento ao Defender for Cloud com alertas de anomalia e implanta o Azure Policy para impor configurações de diagnóstico e linhas de base de NSG por padrão. Uma regra de análise do Sentinel é adicionada para detectar padrões de saída de dados semelhantes, e um exercício é agendado para validar os planos de recuperação do ASR trimestralmente.
• Justificativa: Institucionalizar correções por meio de políticas e análises reduz a recorrência e garante que a resiliência permaneça verificável e repetível.

← Segurança Híbrida e Multi-Cloud · Todos os domínios

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

Navegar Microsoft →