Microsoft AZ-801: Microsoft Defender for Cloud e Sicurezza degli Endpoint — 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 Defender for Cloud e Microsoft Defender for Endpoint formano uno stack coeso per l’hardening degli ambienti ibridi Windows Server, il rilevamento delle minacce e l’applicazione del principio del privilegio minimo (least-privilege). In Azure e on-premise (tramite Azure Arc), forniscono gestione della postura di sicurezza (posture management), correzione automatizzata (automated remediation) e rilevamento e risposta degli endpoint (EDR). Comprendere i piani di Defender for Servers, l’automazione dei flussi di lavoro, i controlli di accesso, il monitoraggio dell’integrità e le protezioni per i container è essenziale per costruire una baseline di sicurezza coerente e per rendere operativa la risposta agli incidenti.

Postura di Sicurezza Cloud e Piani per i Server

Il Secure Score di Defender for Cloud quantifica il livello di conformità delle risorse con le best practice di sicurezza e gli standard normativi mappati tramite Azure Policy. Ogni controllo di sicurezza contribuisce con una quota ponderata al punteggio ed è supportato da una o più raccomandazioni. Il Secure Score viene migliorato implementando le raccomandazioni relative a risorse di calcolo, rete, identità e dati. Il flusso di lavoro di correzione (remediation) inizia analizzando in dettaglio una raccomandazione, esaminando le risorse interessate e i passaggi per la correzione, e utilizzando le soluzioni rapide (quick fix) dove disponibili. Ad esempio, l’abilitazione della protezione degli endpoint è un’implementazione con un solo clic, legata a una policy, che può effettuare il provisioning automatico degli agenti. È possibile assegnare proprietari alle raccomandazioni, impostare scadenze e monitorare le attività di correzione. Laddove una raccomandazione non sia applicabile, è possibile creare un’esenzione con una giustificazione e una scadenza opzionale, che aggiorna il Secure Score senza mascherare rischi non correlati. Le viste sulla conformità normativa (ad es. Azure Security Benchmark, CIS) proiettano gli stessi controlli in valutazioni specifiche per standard, utili per gli auditor e per il monitoraggio continuo.

Defender for Servers fornisce protezioni a più livelli tramite due piani:

Piano 1 (circa 5 $/server/mese, con variazioni regionali) si concentra sulle protezioni a livello di endpoint includendo Microsoft Defender for Endpoint Piano 2 per i server. Fornisce funzionalità EDR con rilevamenti comportamentali, capacità di base per la gestione di minacce e vulnerabilità (threat and vulnerability management), raccomandazioni per la riduzione della superficie di attacco e baseline di sicurezza esposte tramite MDE. Il Piano 1 è ideale per chi desidera un EDR potente con funzionalità di hardening native di Azure ridotte al minimo.
Piano 2 (circa 15 $/server/mese, a seconda della regione) include tutto ciò che è presente nel Piano 1 e aggiunge funzionalità di hardening e monitoraggio native di Azure: accesso just-in-time (JIT) alle VM, controlli adattivi delle applicazioni (adaptive application controls), hardening adattivo della rete (adaptive network hardening), monitoraggio dell’integrità dei file (FIM), valutazione delle vulnerabilità dei server (tramite Qualys integrato o Defender Vulnerability Management basato su MDE), integrazioni per la scoperta di dati sensibili e rilevamenti delle minacce più approfonditi provenienti sia dal contesto dell’host che da quello del cloud. Il Piano 2 è l’opzione completa per le aziende che standardizzano l’uso di Defender for Cloud sia per la prevenzione che per il rilevamento.

Entrambi i piani supportano i server Azure e quelli abilitati per Azure Arc. L’onboarding a livello di sottoscrizione o di workspace consente a Defender for Cloud di effettuare il provisioning automatico degli agenti e delle estensioni necessarie utilizzando identità gestite e Azure Policy, garantendo un’implementazione coerente su larga scala.

Gestione degli Endpoint e delle Vulnerabilità

L’onboarding di Windows Server su Microsoft Defender for Endpoint è semplificato tramite Defender for Cloud. Per le VM Azure, abilita l’auto-provisioning; per ambienti on-premise o altri cloud, connetti le macchine con Azure Arc (agente Azure Connected Machine), quindi abilita Defender for Servers per installare automaticamente l’agente unificato MDE sulle versioni supportate di Windows Server. Convalida l’onboarding confermando la connettività del sensore e la generazione di avvisi da rilevamenti di prova.

L’EDR in modalità di blocco (block mode) rafforza la protezione consentendo a MDE di bloccare artefatti e comportamenti malevoli anche quando un antivirus di terze parti è primario o quando Microsoft Defender Antivirus è in esecuzione in modalità passiva. Assicurati che il motore e la piattaforma di Microsoft Defender Antivirus siano presenti e aggiornati; abilita l’EDR in modalità di blocco tramite le impostazioni di sicurezza di MDE (GPO, Intune o il portale MDE). Questa modalità è particolarmente preziosa sui server in cui un AV basato su firme potrebbe non rilevare l’uso di strumenti di post-exploitation, poiché consente blocchi basati sul comportamento.

La Live response fornisce un accesso shell remoto sicuro e auditato dal portale Microsoft Defender a un server di cui è stato fatto l’onboarding, per attività di triage e contenimento. Con i ruoli appropriati, gli operatori (responder) possono raccogliere artefatti, ispezionare processi e persistenza, terminare processi malevoli, eliminare file e applicare script di mitigazione. Le sessioni di Live response vengono registrate e possono essere integrate nei runbook di incident response.

La valutazione delle vulnerabilità (vulnerability assessment) per i server è disponibile tramite due integrazioni:

Qualys integrato: Defender for Cloud distribuisce un’estensione leggera dell’agente Qualys che esegue scansioni autenticate e segnala le vulnerabilità software a Defender for Cloud. Non è richiesta una sottoscrizione Qualys separata e i risultati alimentano lo Secure Score e le raccomandazioni. Questo percorso è comunemente usato quando si preferisce un provisioning nativo di Azure con una dipendenza minima da MDE.
Microsoft Defender Vulnerability Management (tramite MDE): Utilizza il sensore MDE per fornire inventario software, valutazione CVE, raccomandazioni per la riduzione della superficie di attacco (attack surface reduction) e punteggio di esposizione (exposure scoring) senza agenti aggiuntivi. Consolida le vulnerabilità con i rilevamenti degli endpoint, abilitando flussi di lavoro di remediation unificati. Scegli la VA basata su MDE quando standardizzi su MDE e desideri un’analisi approfondita della postura dei dispositivi (device posture); scegli Qualys integrato quando MDE non è distribuito su server specifici o se richiedi parità tra Windows e Linux senza passaggi di onboarding aggiuntivi. In Defender for Servers Plan 2, è possibile selezionare una delle due origini dati a livello di scope; assicurati che solo una sia abilitata per evitare duplicazioni.

Container e Registri

Defender for Containers di Defender for Cloud protegge sia le immagini che il runtime. Per Azure Container Registry, abilitare la scansione delle immagini in modo che ogni push di immagine e le riscansioni regolari identifichino CVE, segreti esposti e problemi di configurazione (ad es., esecuzione come root). I risultati vengono presentati come raccomandazioni di Defender for Cloud e possono bloccare le distribuzioni tramite i gate della pipeline. Per registri multi-cloud o sistemi di CI, integrare lo scanner di Defender nel processo di build per applicare il principio dello “shift-left”.

In fase di runtime, abilitare l’agente Defender per Kubernetes (add-on per AKS o DaemonSet per altri cluster) per rilevare comportamenti sospetti come privilege escalation all’interno dei container, attività anomale dei processi, crypto-mining o tentativi di movimento laterale. Il sensore di runtime correla i segnali dell’host, i log di audit di Kubernetes e gli eventi dei container, generando avvisi arricchiti con metadati di pod, namespace e nodo. Eseguire l’hardening dei cluster applicando i controlli delle policy di Kubernetes raccomandati, imponendo privilegi minimi e controllando il traffico in ingresso/uscita (ingress/egress) con le network policy; allinearsi con le raccomandazioni dello Secure Score mappate sull’Azure Security Benchmark.

Scenario Pratico

Siemens AG gestisce un ambiente ibrido di Windows Server con VM Azure e server on-premise. La direzione ha la necessità di ridurre l’esposizione dovuta a porte di gestione aperte, automatizzare la reazione agli avvisi critici e ottenere visibilità continua sulle modifiche non autorizzate ai file, migliorando al contempo la conformità normativa (regulatory posture).

Eseguire l’onboarding dei server e scegliere il piano

Azione: Abilitare Microsoft Defender for Servers Plan 2 sulla sottoscrizione di produzione e sul workspace centrale di Log Analytics. Connettere i server on-premise utilizzando Azure Arc e abilitare l’auto-provisioning.
Perché: Il Piano 2 fornisce JIT, controlli adattivi, FIM e vulnerability assessment oltre a MDE, allineandosi con gli obiettivi di prevenzione e rilevamento di Siemens e garantendo al contempo una distribuzione coerente dell’agente su Azure e on-premise.

Migliorare la postura di sicurezza e lo Secure Score

Azione: Rivedere lo Secure Score e dare priorità alle raccomandazioni legate a controlli ad alto rischio (es. protezione endpoint non installata, porte di gestione esposte). Assegnare responsabili e scadenze; creare esenzioni con giustificazione laddove un controllo non sia realmente applicabile (es. laboratorio air-gapped).
Perché: Lo Secure Score guida una riduzione misurabile del rischio e si mappa direttamente sui controlli normativi che Siemens deve rendicontare.

Implementare l’accesso JIT alle VM

Azione: Assicurarsi che ogni NIC/subnet di VM abbia un NSG; per quelle che ne sono sprovviste, creare NSG e associarli in modo appropriato. Configurare l’accesso JIT per RDP/SSH e porte amministrative personalizzate con finestre temporali massime di 3 ore e restrizioni sull’IP di origine limitate ai jump host di Siemens. Richiedere l’approvazione per l’ambiente di produzione.
Perché: L’accesso JIT elimina l’esposizione permanente delle porte di gestione e soddisfa il principio del privilegio minimo (least privilege) limitando l’accesso nel tempo e per origine, con tracce di audit complete.

Automatizzare la risposta con Logic Apps

Azione: Creare un playbook attivato da avvisi di sicurezza che corrispondono a “Antimalware disabled in the virtual machine”. Utilizzare una managed identity con il ruolo Virtual Machine Contributor per chiamare l’API PowerOff sulla VM interessata e notificare il team SecOps tramite Teams.
Perché: Lo spegnimento automatico degli host non conformi previene uno sfruttamento rapido e notifica gli stakeholder; l’uso di una managed identity applica il principio del privilegio minimo con azioni verificabili.

Applicare controlli adattivi delle applicazioni e della rete

Azione: Abilitare i controlli adattivi delle applicazioni in modalità audit per i gruppi di server IIS e SQL; perfezionare le allowlist per i binari firmati e i percorsi standard, quindi passare alla modalità di imposizione (enforce). Applicare le raccomandazioni di hardening adattivo della rete per restringere le regole NSG per le porte in entrata ai soli IP di gestione noti di Siemens.
Perché: L’allowlisting delle applicazioni e gli NSG con hardening riducono la superficie di attacco e bloccano eseguibili sconosciuti, allineandosi con gli standard di base di Siemens.

Configurare il monitoraggio dell’integrità dei file (FIM)

Azione: Assegnare un workspace centrale di Log Analytics, definire le directory del sistema operativo e delle applicazioni e gli hive di registro da monitorare, escludere i percorsi noti per generare rumore e abilitare gli avvisi per le modifiche non autorizzate. Inviare gli avvisi FIM a Microsoft Sentinel per la correlazione.
Perché: Il FIM fornisce un rilevamento precoce di manomissioni e deviazioni di configurazione non autorizzate, soddisfacendo i requisiti di audit e migliorando il rilevamento degli incidenti.

Standardizzare il vulnerability assessment

Azione: Utilizzare Defender Vulnerability Management basato su MDE per tutti i server con onboarding in MDE; disabilitare Qualys dove MDE è presente. Per i server legacy senza MDE, abilitare l’estensione integrata di Qualys.
Perché: Consolidare il VA su una soluzione basata su MDE semplifica le operazioni e approfondisce l’analisi; Qualys colma le lacune dove MDE non è fattibile, prevenendo la duplicazione dei dati.

Mettere in sicurezza container e registri

Azione: Abilitare la scansione delle immagini di ACR e l’agente Defender per AKS. Configurare i gate di CI per bloccare le immagini con CVE critiche e applicare i rilevamenti a runtime con l’inoltro degli avvisi al team SecOps.
Perché: Ciò garantisce che le vulnerabilità vengano risolte prima della distribuzione e che le anomalie a runtime vengano rilevate rapidamente con il contesto di Kubernetes, completando la strategia di difesa in profondità (defense-in-depth) di Siemens.

← Sicurezza e Hardening di Windows Server · Tutti i domini · Microsoft Sentinel e Monitoraggio della Sicurezza →

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