Microsoft AZ-801: Microsoft Sentinel e Monitoraggio della Sicurezza — Guida allo studio

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Fa parte della Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Microsoft Sentinel è un SIEM e SOAR cloud-native che unifica l’ingestion dei log, l’analisi, il rilevamento delle minacce, la risposta agli incidenti e la ricerca proattiva (hunting) in ambienti ibridi basati su Windows Server. Per gli scenari dell’esame AZ-801, la padronanza dell’argomento implica la connessione su larga scala di origini dati come Windows Security Events, Syslog di Linux e sorgenti CEF di terze parti, la progettazione di analisi con latenza minima, la mappatura degli avvisi alle entità per indagini accurate e l’automazione del contenimento tramite playbook basati su Logic Apps. Il successo dipende anche da un’architettura disciplinata dell’area di lavoro Log Analytics, da regole di raccolta dati (DCR) ben gestite per l’Azure Monitor Agent (AMA), da una solida strategia di conservazione dei dati e dalla competenza operativa in UEBA, watchlist, hunting e workbook.

Connettori e Ingestion dei Dati

I Windows Security Events tramite AMA sono la fonte canonica per gli eventi di accesso, creazione di processi, modifica delle policy e altri eventi di audit di Windows Server. Abilita il connettore “Windows Security Events via AMA” in Microsoft Sentinel e crea una DCR che selezioni i set di eventi appropriati per il tuo profilo di rischio (Minimo, Comune o Tutti, oppure una selezione personalizzata per ID evento). I dati vengono inseriti principalmente nella tabella SecurityEvent; i canali Windows non di sicurezza (se abilitati) vengono inseriti in WindowsEvent. Associalo a una Group Policy per garantire che la baseline di sicurezza e le sottocategorie di auditing (ad es. Logon/Logoff, Account Logon, Object Access, DS Access) siano abilitate sui server di origine per generare la telemetria necessaria.

Syslog tramite AMA raccoglie dati da server Linux e dispositivi di rete che utilizzano il protocollo Syslog. Installa l’AMA su host Linux (o su un collettore Linux dedicato) e configura una DCR per specificare le facility e i livelli di gravità da ingerire. Gli eventi vengono scritti nella tabella Syslog. Per le facility ad alto volume ma di basso valore, considera la raccolta selettiva o la trasformazione all’origine per controllare costi e rumore.

CEF tramite AMA consente l’ingestion di log di sicurezza normalizzati da prodotti di sicurezza di terze parti (firewall, IDS/IPS, proxy, EDR). Distribuisci l’AMA su un collettore Linux e configura i tuoi vendor per inoltrare i dati CEF al demone syslog locale (rsyslog/syslog-ng) su porte tipicamente 514/UDP o TCP. In Sentinel, abilita il connettore dati “CEF via AMA” e collega l’host tramite una DCR che esegue il parsing dei dati CEF. I dati analizzati (parsed) vengono inseriti nella tabella CommonSecurityLog con uno schema coerente (campi deviceVendor, deviceProduct, destination/source e attributi di estensione), semplificando l’analisi e la correlazione tra diversi vendor.

Per i Windows Server on-premise, utilizza i server abilitati per Azure Arc per creare un ponte verso Azure. Esegui l’onboarding delle macchine con l’agente Azure Connected Machine, quindi distribuisci l’estensione AMA tramite Azure Policy per operare su larga scala. Crea DCR che puntano a scope di server Arc per instradare i Windows Security Events, i log di Windows Firewall e, se si utilizza Sysmon, una DCR personalizzata per il canale Microsoft-Windows-Sysmon/Operational. Questo pattern centralizza la configurazione, il versioning e il targeting basato su scope, garantendo un’ingestion coerente senza interventi manuali su ogni singolo host.

Architettura dell’Area di Lavoro e Ciclo di Vita dei Dati

Sentinel si collega a una singola area di lavoro Log Analytics per ogni distribuzione. La progettazione dell’area di lavoro dovrebbe minimizzare la latenza e il traffico in uscita (egress) tra le region: colloca le aree di lavoro nella stessa region della maggior parte dei produttori di dati ed evita un’eccessiva frammentazione che complica le query, il triage degli incidenti e il controllo degli accessi in base al ruolo (RBAC). I pattern comuni prevedono un’unica area di lavoro di sicurezza per tenant o una per ogni region principale in cui la residenza dei dati e la latenza richiedono una separazione. Utilizza l’accesso basato sul contesto della risorsa (resource-context) ove possibile, per garantire che i team possano interrogare i log delle risorse di loro proprietà senza ampie autorizzazioni sull’area di lavoro, mentre i ruoli di Sentinel (Reader, Responder, Contributor) governano le operazioni del SOC.

Le DCR governano quali tipi di telemetria, canali e set di eventi vengono raccolti e dove vengono inviati. Tratta le DCR come codice (as code): standardizza la nomenclatura, il controllo delle versioni e gli scope (sottoscrizioni, gruppi di risorse, tag). Raggruppa origini e destinazioni correlate e preferisci più DCR mirate rispetto a un’unica regola monolitica per semplificare il raggio d’impatto (blast radius) e la gestione del ciclo di vita. Quando i volumi di syslog e CEF sono elevati, considera l’uso di DCR separate per ottimizzare facility/gravità in modo indipendente e per supportare test graduali (staged testing).

La conservazione dei dati (retention) e i costi sono controllati a livello di tabella. Imposta la retention predefinita dell’area di lavoro per soddisfare le policy (ad es. 90-180 giorni per la ricerca attiva), quindi sovrascrivi la retention per singola tabella dove necessario. Le tabelle di alto valore (SecurityEvent, CommonSecurityLog, SecurityAlert) vengono in genere conservate più a lungo; le tabelle prolisse (Syslog con DEBUG) possono essere conservate per meno tempo. Utilizza l’archivio (archive) per la conservazione a lungo termine e a basso costo con i processi di ricerca (search jobs); promuovi i dati a “hot” quando necessario per le indagini. Ove appropriato, sposta alcune tabelle prolisse (come Syslog) su Basic Logs per ridurre i costi, tenendo conto delle limitazioni nelle query e del fatto che alcune tabelle di sicurezza (ad es. SecurityEvent) non sono idonee per la modalità Basic. Rivedi regolarmente i limiti massimi di dati (data caps), i livelli di impegno (commitment tiers) e gli andamenti dell’ingestion per prevenire il throttling e ottimizzare i costi.

Analisi, Incident e Automazione della Risposta

Le regole di analisi (analytics rules) sono il motore del rilevamento. Le regole di query pianificate (scheduled query rules) eseguono KQL secondo una pianificazione (ad es. ogni 5 minuti) su un periodo di analisi retrospettiva (lookback period, ad es. 30 minuti), supportando aggregazioni, join, arricchimenti tramite watchlist e finestre di soppressione (suppression windows). Sono ideali per pattern ben noti come accessi multipli falliti seguiti da uno riuscito, euristiche di movimento laterale o catene di processi sospette (suspicious process lineage). Le regole near-real-time (NRT) minimizzano la latenza di rilevamento elaborando continuamente i nuovi dati con esecuzioni circa ogni minuto e generando alert entro circa due minuti; progetta le regole NRT in modo che siano concise e che si basino su ingestion_time() o su finestre temporali ristrette per evitare pesanti scansioni storiche. Le regole Fusion utilizzano l’analisi degli attacchi multi-stadio (multistage attack analytics) di Microsoft per correlare alert a basso segnale (low-signal) provenienti da più prodotti (ad es. Defender for Endpoint, Defender for Identity, Entra ID Protection, CEF di terze parti) in incident ad alta fedeltà (high-fidelity) per campagne come il furto di credenziali o il ransomware. Le regole di anomalia (anomaly rules) sfruttano template di ML integrati che apprendono le baseline (ad es. posizioni di accesso insolite, esecuzione di processi rari) ed emettono deviazioni; queste regole leggono comunemente da BehaviorAnalytics e da altre fonti normalizzate.

Gli incident unificano più alert, entità e prove (evidence) in un unico caso investigativo. La gravità (severity) è assegnata dalla regola di analisi (o dinamicamente da Fusion) e può essere aumentata (escalated) o ridotta tramite le regole di automazione. La mappatura delle entità (entity mapping) è fondamentale per l’efficacia dell’indagine: nel wizard della regola, mappa le colonne della query ai tipi di entità (Account, Host, IP, URL, File, Process, CloudApplication, AzureResource). Una mappatura corretta popola il grafo di indagine (investigation graph), che visualizza le relazioni tra alert, eventi ed entità, consentendo di fare pivoting su account, host, processi e IP. Usa commenti, tag, proprietario (owner) e classificazione per registrare la valutazione dell’analista (analyst disposition) e per addestrare i flussi di lavoro di ottimizzazione (tuning workflows).

L’automazione combina regole di automazione (Automation rules) e Playbook. Le regole di automazione valutano i metadati dell’incident alla sua creazione o aggiornamento per assegnare proprietari, modificare la gravità, aggiungere tag, chiudere falsi positivi o invocare i playbook. I Playbook sono Azure Logic Apps costruite con i connettori di Microsoft Sentinel. I playbook attivati da incident (incident-triggered) reagiscono agli eventi del ciclo di vita dell’incident (ad es. quando un incident viene creato) e sono adatti per azioni con scope sull’incident, come notificare un team, arricchire tutte le entità o creare un ticket in ServiceNow. I playbook attivati da alert (alert-triggered) si attivano su singoli alert prima che vengano raggruppati in un incident, utili per arricchimenti specifici del fornitore o per il pre-triage. Adotta le managed identity per i playbook, concedi il principio del privilegio minimo (least-privilege) tramite Azure RBAC e le autorizzazioni API, e parametrizza gli ID del workspace, gli endpoint di ticketing e i percorsi delle block-list per promuovere il riutilizzo. Laddove sia giustificato il contenimento (containment), includi azioni che mettono in quarantena gli endpoint (Defender for Endpoint), disabilitano gli account (Entra ID), bloccano gli IP (firewall) o revocano le sessioni (Conditional Access) solo dopo che le soglie di confidenza (confidence thresholds) sono state raggiunte.

Operazioni di Sicurezza Proattive (Hunting, UEBA, Watchlist, Workbook)

Il threat hunting in Sentinel si basa sulla competenza in KQL e sul pannello (blade) di hunting. Inizia con le query di hunting integrate, organizzate per tattica; personalizzale per il tuo ambiente facendo riferimento a tabelle come SecurityEvent (audit di Windows), le tabelle Device* di Defender, CommonSecurityLog (CEF) e SigninLogs (Entra). Usa i bookmark per creare snapshot di record interessanti, annotarli e condividere il contesto con il team; più bookmark possono essere promossi a un nuovo incidente o a uno esistente. Livestream esegue continuamente un pattern KQL per rilevare nuovi eventi corrispondenti quasi in tempo reale, ideale per indagini con scadenze precise o scenari di picco improvviso. Converti le query di hunting mature in regole di analisi pianificate per rendere operative le rilevazioni.

L’UEBA (User and Entity Behavior Analytics) arricchisce il rilevamento con baseline comportamentali e punteggi di anomalia. Abilita l’UEBA dalla configurazione di Sentinel e assicurati che le origini dati di identità e attività (accessi di Microsoft Entra, Defender for Endpoint, Defender for Identity, attività di M365) siano connesse. Le pagine delle entità per utenti e host mostrano timeline, confronti con i peer, attività anomale (geolocalizzazione di accesso rara, processi insoliti) e punteggi di rischio aggregati. Gli analisti possono passare dagli incidenti alle pagine delle entità per valutare se un’azione è tipica per quella identità o dispositivo; i punteggi e le sequenze di anomalie aiutano a prioritizzare il triage e a corroborare o confutare rapidamente le ipotesi.

Le watchlist forniscono dati di riferimento veloci e gestiti dagli analisti. Crea le watchlist da upload di file CSV o da un percorso di un account di archiviazione, definisci un alias e seleziona una colonna chiave per ricerche efficienti. Usa la funzione watchlist() in KQL per le join; gli usi comuni includono liste di inclusione/esclusione (allow/deny list) di account amministrativi, host sensibili, domini autorizzati o utenti VIP. Incorpora le watchlist nelle regole di analisi per sopprimere attività note e legittime (ridurre i falsi positivi) o per aumentare la gravità quando una corrispondenza coinvolge un asset critico. Integrale con la threat intelligence unendo le watchlist alla tabella ThreatIntelligenceIndicator per ottenere contesto (es. arricchire gli IP rilevati con note interne o livelli di gravità), o convertendo feed di TI curati in una watchlist per una rapida consultazione e per eventuali override.

I workbook potenziano il monitoraggio e la visibilità a livello dirigenziale (executive). Inizia con i modelli integrati come Security Operations Efficiency, Active Directory Sign-ins, Fusion Detections e UEBA insights. Crea workbook personalizzati usando query KQL, parametri e visualizzazioni per creare dashboard per il SOC che monitorino lo stato dell’ingestion, le performance delle regole, gli SLA degli incidenti e le minacce emergenti. Applica l’RBAC sulla risorsa del workbook e parametrizza sottoscrizioni, workspace e intervalli di tempo in modo che lo stesso workbook possa essere utilizzato da team diversi. Combina i riquadri (tile) di più tabelle per correlare la postura di sicurezza (Defender for Cloud), i rilevamenti (Sentinel) e le metriche di risposta in un’unica vista.

Scenario Pratico

Spotify deve centralizzare il monitoraggio della sicurezza per 2.000 Windows Server distribuiti tra Azure e data center on-premise, oltre a firewall e proxy di terze parti. Hanno bisogno di rilevamenti a bassa latenza per l’abuso di credenziali, di un sistema automatizzato di ticketing e contenimento, e di dashboard e flussi di lavoro di hunting chiari per il SOC.

1. Onboarding dei server ibridi con Azure Arc e AMA

• Esegui l’onboarding su larga scala dei server abilitati per Azure Arc usando Azure Policy, quindi assegna la policy dell’estensione AMA all’ambito di Arc. Crea delle DCR per “Windows Security Events via AMA” (set Comune), Windows Firewall e una DCR personalizzata per Sysmon, dove installato. Questo approccio fornisce una raccolta dati coerente e gestita centralmente, senza script per singolo host, e garantisce che la tabella SecurityEvent sia popolata per l’analisi delle identità e dei processi.

2. Ingestione della telemetria di rete e degli appliance di sicurezza tramite Syslog e CEF

• Prepara una VM Linux da usare come collettore con l’AMA. Configura “Syslog via AMA” per le facility pertinenti e abilita “CEF via AMA” per effettuare il parsing dei dati CEF di firewall e proxy nella tabella CommonSecurityLog. L’uso di CEF normalizza i dati multi-vendor, consentendo la portabilità delle regole e join semplici tra le diverse origini.

3. Progettare le regole di analisi per velocità e fedeltà

• Abilita Fusion per catturare attacchi multi-stadio con una messa a punto minima. Crea regole NRT per raffiche di accessi falliti seguiti da un successo su account privilegiati, usando SecurityEvent e ingestion_time(), fornendo un rilevamento in meno di due minuti. Crea regole pianificate per i pattern di movimento laterale (es. la creazione del processo net.exe su server, unita ad account amministrativi insoliti) e per le anomalie nel traffico in uscita (egress) dai proxy, unite alle watchlist di utenti VIP e di host critici (crown-jewel). Questa combinazione minimizza l’MTTR contenendo al contempo i falsi positivi.

4. Mappare le entità e modellare gli incidenti

• In ogni regola pianificata, mappa le entità Account, Host, IP e Process dalle colonne della query. Usa le regole di automazione per assegnare gli incidenti per business unit (derivata dai tag degli host), standardizzare la gravità, aggiungere tag MITRE e chiudere automaticamente i segnali di test noti. Una mappatura corretta permette al grafo di investigazione di mostrare le relazioni attraverso cui gli analisti di Spotify possono muoversi (fare pivoting) rapidamente.

5. Automatizzare l’arricchimento, il ticketing e il contenimento con i playbook

• Crea un playbook attivato da un incidente che arricchisca tutti gli account e gli host (ricerche nel grafo, rischio del dispositivo), pubblichi un post su Teams e apra un ticket in Jira. Un playbook separato, attivato da un alert, arricchisce specifici alert CEF con le API del vendor. Usa identità gestite con RBAC basato sul principio del privilegio minimo e una logica condizionale (conditional branching) che isoli i dispositivi (tramite Defender for Endpoint) o disabiliti gli utenti (tramite Entra ID) solo quando vengono raggiunte le soglie di confidenza (es. più alert corroboranti e un punteggio UEBA elevato). Ciò preserva la continuità operativa, abilitando al contempo una risposta rapida e governata.

6. Abilitare l’UEBA e rendere operativo l’hunting

• Attiva l’UEBA e convalida le origini dati (SigninLogs, attività di M365, segnali di Defender). Forma gli analisti a passare dagli incidenti alle pagine delle entità per consultare i punteggi di anomalia e i confronti con i peer. Converti due query di hunting di alto valore — “Nuovi strumenti di amministrazione remota sui server” e “Pattern rari di esfiltrazione dati verso IP esterni” — in regole di analisi pianificate, una volta convalidate tramite bookmark e livestream. L’UEBA, unito a un hunting disciplinato, migliora il rilevamento di tecniche nuove.

7. Governare il ciclo di vita dei dati e visualizzare la postura di sicurezza

• Imposta la conservazione (retention) a 180 giorni per SecurityEvent e CommonSecurityLog, 30 giorni per i log Syslog dettagliati (verbose) con archiviazione per 1 anno, e monitora i costi con i commitment tier. Pubblica un workbook personalizzato per il SOC che tracci lo stato di salute dell’ingestion, le regole più “rumorose”, MTTA/MTTR, le code di incidenti per gravità e le anomalie UEBA nel tempo. Questo fornisce trasparenza alla leadership e guida una messa a punto continua.

Ogni strumento è stato scelto per il suo punto di forza specifico: Arc e AMA+DCR offrono un’ingestione scalabile e guidata da policy; CEF garantisce la normalizzazione dei log di sicurezza multi-vendor; Fusion e le regole NRT riducono la latenza di rilevamento senza una messa a punto eccessiva; la mappatura delle entità e il grafo di investigazione accelerano il triage; i playbook forniscono un’automazione governata e basata sull’identità; l’UEBA fornisce contesto comportamentale; gli strumenti di hunting fanno maturare i rilevamenti; e i workbook mantengono le operazioni misurabili e visibili.

← Microsoft Defender for Cloud e Sicurezza degli Endpoint · Tutti i domini · Sicurezza di Active Directory Domain Services →

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

Sfoglia Microsoft →