Microsoft AZ-500: Risposta agli incidenti, ripristino e resilienza — Guida allo studio

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

Fa parte della Microsoft Azure Security Engineer Associate AZ-500 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

La risposta agli incidenti, il ripristino e la resilienza in Azure costituiscono una capacità continua che combina procedure operative ben collaudate con controlli nativi della piattaforma. Un programma efficace anticipa guasti o compromissioni, rileva e classifica rapidamente, contiene il raggio d’impatto (blast radius) con l’automazione, ripristina il servizio secondo obiettivi definiti, conserva prove immutabili e infine rafforza (hardening) l’ambiente in base a quanto appreso. I servizi nativi di 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 — forniscono gli elementi costitutivi. L’imperativo di progettazione è predisporre la telemetria corretta, i percorsi di emergenza per le identità (identity break-glass) e l’applicazione automatizzata delle policy, in modo che i team possano intervenire in pochi minuti, non in ore.

Ciclo di vita della risposta agli incidenti e operazioni di Sentinel

• Preparazione

  • Definire chi fa cosa, quando e con quali strumenti. Pre-configurare le aree di lavoro di Microsoft Sentinel, connettere le origini dati (Activity Log, log delle risorse, log di flusso NSG, log di accesso/audit di Microsoft Entra, segnali di Defender) e implementare i controlli di accesso e RBAC per analisti, soccorritori (responder) e comandanti degli incidenti.
  • Creare playbook (Logic Apps) per azioni di contenimento comuni come l’isolamento di VM, la revoca di token utente o la rotazione delle chiavi. Predisporre NSG di quarantena e sottoscrizioni dedicate all’analisi forense.
  • Stabilire la conservazione immutabile dei log tramite le Impostazioni di Diagnostica (Diagnostic Settings) verso Log Analytics e un account Azure Storage con immutabilità (WORM).

• Rilevamento

  • In Sentinel, abilitare le regole di analisi per il furto di credenziali, pattern di accesso anomali, esecuzione di processi sospetti, abuso di Key Vault ed esfiltrazione di dati. Integrare con regole UEBA e di fusione per correlare eventi benigni in incidenti significativi. Calibrare le soglie e la soppressione delle regole per ridurre al minimo l’affaticamento da alert (alert fatigue).

• Contenimento

  • Eseguire azioni pre-approvate: mettere in quarantena le NIC tramite NSG, disabilitare service principal compromessi, revocare i token di aggiornamento di Entra, ruotare i segreti, disabilitare gli endpoint pubblici in ingresso o impostare il WAF in modalità di prevenzione. Utilizzare le regole di automazione di Sentinel per instradare in base alla gravità, aggiungere tag, assegnare proprietari e attivare i playbook.

• Sradicamento

  • Rimuovere la persistenza (attività di avvio, processi pianificati, script cloud-init, estensioni dannose), ruotare le credenziali, ridistribuire le immagini golden e applicare le patch alle vulnerabilità segnalate da Defender for Cloud. Per gli incidenti legati all’identità, richiedere il reset delle password e rafforzare l’Accesso Condizionale (Conditional Access).

• Ripristino

  • Ripristinare da Azure Backup su VNet pulite; eseguire il failover utilizzando i piani di ripristino di ASR; convalidare l’integrità e reidratare segreti e configurazioni da fonti sicure (template IaC, Key Vault con eliminazione temporanea/protezione dall’eliminazione definitiva). Assicurarsi che RTO e RPO siano rispettati.

• Lezioni apprese

  • Condurre una revisione senza colpe (blameless review). Aggiornare le regole e i playbook di Sentinel, le assegnazioni di Azure Policy, le immagini di base e i runbook. Codificare le correzioni in IaC e imporle tramite i gruppi di gestione (management groups).

Classificazione, raccolta prove, indagine e gestione dei casi in Sentinel

• Classificazione (Triage)

  • Dare priorità agli incidenti per gravità, criticità degli asset e raggio d’impatto (blast radius) utilizzando l’arricchimento delle entità (host, utente, IP) e le watchlist. Utilizzare il raggruppamento degli incidenti per ridurre i duplicati e la vista cronologica (timeline) per comprendere la sequenza.

• Raccolta delle prove

  • Aggiungere ai segnalibri gli eventi importanti, esportare i log grezzi su storage immutabile, creare snapshot dei dischi delle VM interessate per l’analisi offline e catturare gli alberi dei processi tramite le integrazioni con Defender for Endpoint. Preservare la catena di custodia (chain-of-custody) memorizzando gli hash e limitando l’accesso a un gruppo di risorse dedicato all’analisi forense.

• Indagine

  • Utilizzare i grafi di indagine e le pagine delle entità (cronologia degli accessi utente, albero dei processi dell’host). Eseguire attività di hunting con KQL su SigninLogs, AuditLogs, SecurityEvent e AzureDiagnostics. Registrare i risultati, allegare artefatti e taggare gli IOC (Indicatori di Compromissione) per il rilevamento futuro.

• Gestione dei casi

  • Standardizzare gli stati (Nuovo, Attivo, In corso, Risolto), i proprietari e i timer SLA. Integrare Sentinel con sistemi ITSM (ServiceNow/Azure DevOps) per il ticketing e il controllo delle modifiche (change control). Le regole di automazione possono chiudere automaticamente gli alert benigni noti o inoltrare (escalation) tattiche specifiche al Livello 2 (Tier 2).

Contenimento automatizzato e orchestrazione dei flussi di lavoro

• Regole di automazione di Sentinel

  • Si attivano alla creazione/aggiornamento di un incidente. Assegnano dinamicamente la proprietà, impostano la gravità, aggiungono tag (es. QuarantineCandidate) e invocano uno o più playbook. Logica: passare dal rilevamento all’azione in pochi secondi, in modo coerente con il principio del privilegio minimo (least-privilege) e con i playbook pre-approvati.

• Playbook di Logic Apps

  • Azioni comuni: applicare un NSG di quarantena a una NIC di una VM, disabilitare un utente, revocare token, bloccare un IP nel WAF o aprire un ticket ITSM con il contesto completo. Utilizzare le identità gestite (managed identities) e Azure RBAC per limitare le autorizzazioni di ogni playbook all’esatto set di risorse necessario.

• Automazione dei flussi di lavoro di Defender for Cloud

  • In risposta a raccomandazioni o alert (es. “RDP aperto su Internet”), attiva automaticamente i playbook per porre rimedio (restringere le regole NSG), taggare le risorse per il follow-up o notificare i proprietari. Logica: chiudere rapidamente l’esposizione, migliorando lo Secure Score e riducendo il tempo di permanenza dell’attaccante (attacker dwell time).

Esempio: mettere in quarantena la NIC di una VM in pochi secondi

# 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

Revoca dei token per un utente compromesso

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

Backup, replica, RTO/RPO e resilienza

Sicurezza di Azure Backup

• Insiemi di credenziali dei servizi di ripristino e insiemi di credenziali di backup

  • Utilizzare insiemi di credenziali per perimetro del carico di lavoro e per regione. Abilitare l’eliminazione temporanea (soft delete) per proteggere dall’eliminazione accidentale/malevola degli elementi di backup; impostare una finestra di conservazione appropriata e allineata alle esigenze normative. Abilitare la protezione dall’eliminazione definitiva (purge protection), dove supportata, per impedire le eliminazioni irreversibili.

• Immutabilità

  • Configurare l’immutabilità dell’insieme di credenziali. Utilizzare la modalità sbloccata (unlocked) durante la messa a punto iniziale, quindi passare alla modalità bloccata (locked) per impedire la riduzione della conservazione o la manomissione delle policy. Logica: garantisce che i backup siano di tipo write-once e a prova di modifica, un controllo chiave contro i ransomware.

• Autorizzazione multiutente (MUA)

  • Proteggere le operazioni di backup critiche (es. interrompere la protezione con eliminazione dei dati, modificare le impostazioni dell’insieme di credenziali) utilizzando Azure Backup Resource Guard in una sottoscrizione/gruppo di risorse separato e di proprietà di un team diverso. Logica: impone la separazione dei compiti (separation-of-duties); gli aggressori devono compromettere due identità in ambiti diversi per distruggere la capacità di ripristino.

• Funzionalità tra aree

  • Per gli RSV che utilizzano GRS, abilitare il ripristino tra aree (cross-region restore) per poter effettuare il recupero anche se l’area primaria non è disponibile. Verificare che anche le chiavi crittografiche utilizzate dai carichi di lavoro siano resilienti (eliminazione temporanea/protezione dall’eliminazione definitiva di Key Vault e, se necessario, pianificazione del ripristino con ridondanza geografica).

Azure Site Recovery (ASR)

• Replica

  • Da Azure ad Azure, da VMware/Hyper-V ad Azure e server fisici. Definire le policy di replica (soglia RPO, conservazione dei punti di ripristino, frequenza degli snapshot coerenti con l’applicazione). Distribuire il servizio Mobility dove richiesto.

• Piani di ripristino

  • Orchestrare il failover di applicazioni multi-tier con ordine di avvio, passaggi manuali e runbook (es. aggiornamenti DNS, inversione delle stringhe di connessione). Conservare credenziali e script in Key Vault.

• Failover di test

  • Eseguire test regolari e non dirompenti in una VNet isolata con IP mascherati. Utilizzare “Cleanup test failover” per ripristinare lo stato. Logica: convalida il ripristino end-to-end senza impattare la produzione.

• Failback

  • Dopo il ripristino del sito primario, riproteggere ed eseguire il failback, risincronizzando le modifiche. Pianificare finestre di larghezza di banda e manutenzione per rispettare gli SLA aziendali.

Selezione dell’architettura per soddisfare RTO/RPO

• RPO ridotto (da secondi a minuti) e RTO basso (minuti)

  • Preferire ASR o la replica nativa dell’applicazione (es. SQL Always On, Cosmos DB multi-region) rispetto ai backup; mantenere uno standby di tipo hot o warm; utilizzare Front Door/Traffic Manager per il failover a livello di area.

• RPO moderato (ore) e RTO moderato (ore)

  • Combinare backup frequenti con ASR per i tier critici; utilizzare funzionalità di accelerazione del backup (snapshot di ripristino istantaneo) per ridurre i tempi di ripristino.

• RPO lungo (giorni) e RTO lungo (giorni)

  • Solo backup con conservazione più lunga; tier di archiviazione ottimizzati per i costi.

Ragionamento operativo: la replica offre un RPO ridotto a un costo corrente più elevato; i backup offrono una conservazione a lungo termine più economica ma con RTO/RPO più lenti. Combinare le soluzioni per ogni tier in base all’analisi dell’impatto sul business.

Difesa della rete, forense, continuità e hardening

Risposta a DDoS in Azure, tuning del WAF e failover della gestione del traffico

• DDoS Protection Standard

  • Associare alle VNet che ospitano IP pubblici. Fornisce mitigazione adattiva in tempo reale e supporto DDoS Rapid Response (DRR) durante gli attacchi. Configurare avvisi e diagnostica verso Sentinel. Logica: mitigazione automatica perimetrale (all’edge) prima che il traffico raggiunga i carichi di lavoro.

• Tuning del WAF

  • Utilizzare i set di regole gestite OWASP e passare alla modalità di prevenzione (prevention). Aggiungere esclusioni per pattern benigni noti, attivare l’ispezione delle dimensioni/corpo della richiesta dove necessario e creare regole personalizzate di autorizzazione/negazione (allow/deny) e di limitazione della frequenza (rate limiting) per IP o aree geografiche abusivi. Affinare continuamente in base ai log.

• Failover del traffico

  • Utilizzare Traffic Manager (basato su DNS) con routing prioritario e TTL basso per il failover di regione, oppure Azure Front Door (anycast L7) per un failover più rapido guidato da health probe e per l’ingresso globale. Sondare (probe) gli endpoint critici ed eseguire esercitazioni di failover regolari.

Forense: log e conservazione immutabile

• Activity Log

  • Controllare le azioni del piano di controllo (creazione/eliminazione/assegnazione di ruoli). Inviare in streaming a Sentinel e ad Azure Storage con immutabilità per la conservazione a fini legali (legal hold).

• Log delle risorse

  • Abilitare tramite Diagnostic Settings per i servizi chiave (Key Vault, App Service, Storage, SQL, AKS). Indirizzare a Log Analytics, Event Hub e a uno Storage immutabile.

• Flow log degli NSG

  • Abilitare in Network Watcher; analizzare con Traffic Analytics per ricostruire i flussi di rete durante gli incidenti.

• Log di accesso e di audit di Microsoft Entra

  • Inserire in Sentinel per le indagini sull’identità. Monitorare gli accessi a rischio e gli esiti dell’accesso condizionale (Conditional Access). Estendere la conservazione tramite l’archivio di Log Analytics e/o l’esportazione su uno Storage immutabile.

Controlli di emergenza (break-glass) e di continuità

• Mantenere almeno due account di emergenza (break-glass) di tipo Global Administrator, solo cloud, con password lunghe e complesse, esclusi dalle policy di accesso condizionale (Conditional Access) e MFA per sopravvivere a eventuali interruzioni. Archiviare le credenziali in modo sicuro offline e monitorare ogni accesso con avvisi in tempo reale. Assegnare ruoli permanenti limitati altrove; utilizzare PIM per l’elevazione dei privilegi just-in-time durante le normali operazioni.
• Documentare le procedure di accesso di emergenza, inclusa l’opzione di Entra “Elevate access to manage all Azure subscriptions” e i passaggi per assegnare il ruolo di Owner al management group radice se l’RBAC non funziona.
• Proteggere le risorse critiche con blocchi di gestione (management lock) di tipo CanNotDelete e limitare l’ambito di assegnazione dei ruoli utilizzando i management group.

Hardening post-incidente

• Applicare Azure Policy a livello di management group per imporre una baseline (ad es., DeployIfNotExists per estensioni antimalware, crittografia dei dischi, impostazioni di diagnostica, accesso JIT alle VM). Rimediare alla non conformità con le attività di correzione (remediation task) delle policy.
• Migliorare il rilevamento affinando le analisi di Sentinel (aggiungere nuovi IOC, regolare le soglie), convertendo le attività di ricerca (hunt) riuscite in regole pianificate e aggiungendo regole di automazione per il triage.
• Aggiornare le baseline di sicurezza (immagini, policy di Key Vault, regole NSG/WAF). Catturare tutte le modifiche come codice (Bicep/Terraform) e convalidarle con CI/CD e controllo delle modifiche (change control). Monitorare il Secure Score e la conformità normativa per misurare i progressi.

Scenario di Problema Pratico

Starbucks riscontra un’impennata di accessi sospetti seguita da un’anomala esfiltrazione di dati (egress) dallo storage di una sottoscrizione di produzione che ospita un’API per gli ordini. Il team di sicurezza deve contenere l’incidente, investigare e ripristinare il servizio, preservando al contempo le prove e rispettando un RTO di due ore e un RPO di 15 minuti per il livello API.

1. Automatizzare il triage e contenere il raggio d’azione dell’attacco (blast radius)

• In Sentinel, una regola di automazione si attiva per incidenti ad alta gravità con entità provenienti dal resource group dell’API degli ordini, assegna l’analista di turno, etichetta l’incidente come QuarantineCandidate ed esegue un playbook per:
  • Revocare le sessioni dell’utente compromesso.
  • Applicare un NSG di quarantena alle NIC del VM scale set dell’API.
  • Aggiungere una regola personalizzata al WAF per bloccare gli intervalli IP malevoli.
• Logica: l’automazione esegue azioni pre-approvate con il minimo privilegio in pochi secondi, riducendo il tempo di permanenza dell’attaccante (dwell time) e prevenendo ulteriori esfiltrazioni di dati.

2. Preservare le prove con l’immutabilità

• Il playbook crea snapshot dei dischi del sistema operativo e dei dati delle VM interessate ed esporta i log di Activity Log, i flow log degli NSG e i log dell’account di Storage per i container di destinazione in un account Azure Storage con immutabilità basata sul tempo e conservazione a fini legali (legal hold). I segnalibri (bookmark) e le query KQL vengono allegati all’incidente di Sentinel.
• Logica: lo storage immutabile garantisce la catena di custodia (chain-of-custody); gli snapshot consentono l’analisi forense offline senza alterare i sistemi compromessi.

3. Ripristinare il servizio rispettando RTO/RPO

• Poiché il livello API è protetto da ASR con una frequenza di snapshot coerenti con l’applicazione (app-consistent) di 15 minuti, il team esegue un piano di ripristino prioritario per effettuare il failover del livello API sulla regione abbinata (paired region). Azure Front Door esegue il failover basato su health probe verso l’endpoint secondario.
• Logica: la replica soddisfa l’RPO di 15 minuti, e il failover orchestrato unito al routing di Front Door soddisfa l’RTO di due ore senza dover ripristinare da un backup.

4. Rimediare a identità e segreti

• Gli amministratori con privilegi ruotano le credenziali e le chiavi in Key Vault (con eliminazione temporanea (soft delete) e protezione dall’eliminazione definitiva (purge protection) abilitate) e disabilitano l’account compromesso, imponendo un accesso condizionale (Conditional Access) più restrittivo per i ruoli con privilegi.
• Logica: i segreti e le identità sono vettori di persistenza comuni; la rotazione rapida e controlli di accesso più severi impediscono il rientro dell’attaccante.

5. Hardening e validazione post-incidente

• Il team affina le regole gestite del WAF, aggiunge una regola personalizzata di limitazione della frequenza (rate-limiting), integra l’account di Storage in Defender for Cloud con avvisi di anomalia e distribuisce Azure Policy per imporre di default le impostazioni di diagnostica e le baseline degli NSG. Viene aggiunta una regola di analisi in Sentinel per rilevare pattern di esfiltrazione simili e viene pianificata un’esercitazione trimestrale per convalidare i piani di ripristino di ASR.
• Logica: istituzionalizzare le correzioni tramite policy e analisi riduce le recidive e garantisce che la resilienza rimanga verificabile e ripetibile.

← Sicurezza ibrida e multi-cloud · Tutti i domini

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →

Sfoglia Microsoft →