Microsoft AZ-500: Gestione della postura di sicurezza e governance — Guida allo studio
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 gestione della postura di sicurezza e la governance in Azure sono la disciplina che consiste nel valutare, dare priorità e applicare continuamente le configurazioni che riducono il rischio tra sottoscrizioni e cloud, mantenendo al contempo una conformità dimostrabile. Un design efficace combina Microsoft Defender for Cloud per la visibilità e la protezione della postura, Azure Policy per guardrail preventivi e correttivi, la governance delle landing zone per un’ereditarietà scalabile e la registrazione di log a livello di audit per comprovare i controlli. L’obiettivo operativo è una riduzione del rischio difendibile: le decisioni sono guidate dall’esposizione e dall’impatto, applicate tramite codice, ereditate by design e comprovate da log immutabili.
Microsoft Defender for Cloud: Architettura, Piani e Raccomandazioni
Defender for Cloud (MDC) ingerisce segnali da Azure, ambienti ibridi e multicloud, li correla in Secure Score, raccomandazioni e avvisi, e può orchestrare la remediation. Progettarlo a livello della radice del management group (MG) in modo che piani e policy vengano ereditati da tutte le sottoscrizioni; utilizzare le sottoscrizioni solo per definire l’ambito delle eccezioni. Per il multicloud, distribuire i connettori nativi di MDC per AWS e GCP a livello della radice del tenant (o in una sottoscrizione “Security” dedicata), utilizzando account con privilegi minimi e auto-provisioning centralizzato per standardizzare la distribuzione degli agent e la raccolta dei dati.
La selezione dei piani è guidata dal rischio:
- Defender for Servers: Il Piano 1 fornisce valutazione delle vulnerabilità e hardening di base; il Piano 2 aggiunge Microsoft Defender for Endpoint (MDE), accesso just-in-time (JIT) alle VM, analisi delle minacce e comportamentale e monitoraggio dell’integrità dei file. Utilizzare il Piano 2 per host esposti a Internet o con privilegi elevati; il Piano 1 per pool di server a bassa esposizione.
- Defender for Storage: Rileva accessi anomali e malware su blob, file e ADLS Gen2. Abilitare per account con scansione mirata ai container ad alto rischio (es. ingest pubblico) per gestire i costi coprendo al contempo i punti di ingresso.
- Defender for SQL: Per Azure SQL, abilita il rilevamento delle minacce e la valutazione delle vulnerabilità con deviazioni dalla baseline; per SQL su macchine (incluse quelle abilitate per Arc), aggiunge una protezione basata su agent. Abilitare ampiamente sui database di produzione; definire una baseline dei pattern normali per ridurre il rumore.
- Defender for Containers: Protegge AKS e Kubernetes abilitato per Arc con scansione delle vulnerabilità delle immagini (in ACR e a runtime), analisi degli audit di Kubernetes e rilevamento delle minacce a runtime. Applicare le policy di Kubernetes (Gatekeeper/OPA) tramite l’add-on di Azure Policy. Integrare la scansione CI/CD per bloccare le CVE critiche prima della distribuzione.
- Defender for Key Vault: Rileva accessi anomali ai segreti e pattern di esfiltrazione. Utilizzare Azure RBAC per l’amministrazione del vault e policy di accesso al data plane (o RBAC data actions) per operazioni sui segreti con privilegi minimi.
- Defender for DNS: Rileva l’esfiltrazione basata su DNS e il command-and-control. Dare priorità alle VNet spoke con traffico in uscita (egress) verso Internet; non è richiesto alcun agent.
- Defender for DevOps: Connettere le organizzazioni di Azure DevOps e GitHub per valutare repository, segreti, errori di configurazione IaC e l’hardening delle pipeline. Utilizzare policy di blocco sulle pull request per errori di configurazione ad alta gravità per anticipare (shift-left) la riduzione del rischio.
Le raccomandazioni di sicurezza unificano i risultati dei piani e le valutazioni di Azure Policy. Renderle operative tramite:
- Abilitando l’auto-provisioning dei piani a livello di MG.
- Trattando le raccomandazioni “ad alta gravità, esposte a Internet” come elementi di lavoro controllati da change management con SLO definiti.
- Documentando le eccezioni di governance come esenzioni di policy con scadenze e giustificazioni.
Secure Score, Conformità e Automazione del Workflow
Il Secure Score aggrega i “controlli” (gruppi di requisiti di sicurezza correlati) in una percentuale normalizzata. Ogni controllo ha un punteggio che viene distribuito tra le sue “azioni di miglioramento”. L’impatto sul punteggio riflette il potenziale di riduzione del rischio e l’ambito delle risorse interessate. Dare priorità in base a:
- Massimo impatto potenziale sul punteggio per unità di sforzo (Quick Win: ad es. abilitare l’MFA per i proprietari, limitare l’accesso pubblico allo storage).
- Esposizione della superficie di attacco (endpoint pubblici, identità con privilegi, confini di rete deboli).
- Obblighi normativi che corrispondono alle stesse azioni (massimizza il guadagno in termini di conformità).
Utilizzare le azioni di miglioramento con guida alla remediation, correzioni rapide (quick-fix) e automazioni tramite Logic App. Tracciare il rischio residuo tramite esenzioni di tipo “non può essere risolto” o “mitigato by design” con una scadenza per forzare una rivalutazione periodica.
La conformità normativa in MDC mappa configurazioni e raccomandazioni a standard (es. Azure Security Benchmark, CIS, NIST). Selezionare gli standard richiesti a livello di MG; evitare la deriva (drift) per singola sottoscrizione. Trattare la dashboard di conformità come un report di policy-as-code: ogni controllo verde dovrebbe essere tracciabile a una policy, un’iniziativa o una configurazione automatizzata. Per le famiglie di controlli che richiedono prove di processo (es. risposta agli incidenti), collegare visualizzazioni di workbook e ID di ticket per il supporto agli audit.
L’automazione del workflow lega la postura all’azione. Pattern tipici:
- Trigger: Una raccomandazione diventa non conforme (unhealthy) su una sottoscrizione business-critical → Azione: aprire un ticket P1, notificare il SecOps e creare automaticamente un task di remediation.
- Trigger: Nuovo avviso ad alta gravità su una risorsa di produzione → Azione: isolare l’endpoint (MDE), mettere in quarantena l’oggetto di storage o disabilitare l’accesso pubblico tramite la remediation della policy.
Governance Guidata dalle Policy e Landing Zone
Azure Policy è il sistema di guardrail preventivo e correttivo per il drift del cloud. Elementi chiave:
- Definizione: Una regola con condizioni ed un effetto. Gli effetti comuni includono Deny, Audit, Append, Modify, DeployIfNotExists, AuditIfNotExists e Disabled. Usare Deny per guardrail non negoziabili (es. non consentire IP pubblici sulle NIC). Usare DeployIfNotExists per installare automaticamente agenti o estensioni richiesti (es. antimalware o MDE).
- Iniziativa: Un insieme curato di definizioni di policy parametrizzate per un’assegnazione coerente (es. l’iniziativa Azure Security Benchmark).
- Assegnazione: Definire lo scope prima sui gruppi di gestione, poi su sottoscrizioni o gruppi di risorse per override mirati. Abilitare la “modalità di imposizione” (enforcement mode) per policy obbligatorie una volta monitorate.
- Esenzioni: Usare le categorie Waiver (rischio accettato) o Mitigated (controllo di compensazione). Impostare sempre una scadenza per garantire una nuova valutazione.
- Attività di correzione (Remediation task): Necessarie per DeployIfNotExists e Modify per configurare le risorse esistenti. Concedere all’identità gestita dell’assegnazione della policy il ruolo Contributor (e i permessi sul piano dati, se necessario) sugli scope di destinazione.
Scheletro di una policy di esempio per imporre l’estensione antimalware sulle VM Windows:
{
"properties": {
"displayName": "Deploy antimalware on Windows VMs",
"policyType": "Custom",
"mode": "Indexed",
"parameters": {},
"policyRule": {
"if": {
"allOf": [
{ "field": "type", "equals": "Microsoft.Compute/virtualMachines" },
{ "field": "Microsoft.Compute/virtualMachines/osProfile.windowsConfiguration", "exists": "true" }
]
},
"then": {
"effect": "DeployIfNotExists",
"details": {
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "IaaSAntimalware",
"roleDefinitionIds": ["/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"],
"deploymentScope": "resourceGroup",
"existenceCondition": { "field": "name", "equals": "IaaSAntimalware" },
"deployment": { "properties": { "mode": "incremental", "template": { "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#", "resources": [] } } }
}
}
}
}
}
La governance della landing zone organizza l’ereditarietà e la separazione dei compiti:
- Gruppi di gestione: Costruire una gerarchia chiara (Radice del Tenant → Piattaforma → Corp/Online → Ambienti come Prod/NonProd). Assegnare iniziative e RBAC a livello di gruppo di gestione per massimizzare l’ereditarietà e minimizzare il drift per singola sottoscrizione. Individuare e integrare i ruoli con privilegi in PIM; la configurazione di PIM richiede un Global Administrator.
- Organizzazione delle sottoscrizioni: Separare per ambiente e criticità del workload per isolare il raggio d’impatto (blast radius) e i budget. Usare archetipi (es. “Mission-Critical AKS”, “Data Platform”) con iniziative e RBAC pre-assegnati.
- Tag: Standardizzare i tag richiesti (Owner, CostCenter, DataSensitivity, Environment) e imporli tramite Modify/Append per la normalizzazione; negare la creazione di risorse quando i tag richiesti mancano in produzione.
- Blocchi delle risorse: CanNotDelete protegge i servizi condivisi critici; ReadOnly impedisce qualsiasi operazione PUT. Usare con parsimonia e solo dopo l’irrigidimento (hardening) delle policy. Notare che un blocco ReadOnly su una VM o sul suo gruppo di risorse impedisce l’avvio di VM deallocate e blocca le modifiche alla configurazione.
Per esigenze legate ai blueprint legacy, adottare un approccio “policy-as-code” con ARM/Bicep, Template Specs e assegnazioni di iniziative per ottenere deployment coerenti su larga scala, simili a quelli dei blueprint.
Inventario di sicurezza, app cloud, governance dei dati e audit
L’inventario e la conformità su larga scala utilizzano Azure Resource Graph (ARG) e i report di conformità delle policy. Le query ARG forniscono viste quasi in tempo reale della postura per milioni di risorse:
securityresources
| where type =~ 'microsoft.security/assessments'
| where properties.status.code == 'Unhealthy'
| summarize unhealthy=count() by tostring(properties.displayName)
| order by unhealthy desc
Unisci la postura delle risorse con i tag per classificarle in base alla sensibilità dei dati:
resources
| where type == 'microsoft.compute/virtualmachines'
| project id, name, resourceGroup, subscriptionId, dataSensitivity = tostring(tags['DataSensitivity'])
| join kind=leftouter (
securityresources
| where type =~ 'microsoft.security/assessments'
| where properties.status.code == 'Unhealthy'
| summarize issues=count() by tolower(tostring(properties.resourceDetails.Id))
) on $left.id == $right['tolower_tostring_properties_resourceDetails_Id']
| project name, dataSensitivity, issues = coalesce(issues, 0)
| order by issues desc
Defender for Cloud Apps (MDCA) gestisce il rischio SaaS:
- Individuazione delle app: Acquisisci i log di firewall/proxy tramite Cloud Discovery o integra con Defender for Endpoint per l’individuazione basata sugli endpoint. Classifica le app per punteggio di rischio e utilizzo; contrassegnale come approvate/non approvate per attivare l’accesso condizionale e i blocchi del proxy.
- Controlli di sessione: Utilizza Conditional Access App Control per fungere da proxy per le sessioni con azioni sensibili. Applica policy in tempo reale per bloccare i download, monitorare gli upload, redigere contenuti o applicare watermark per sessioni rischiose o dispositivi non gestiti.
- Azioni di governance: Metti in quarantena o etichetta i file in Microsoft 365, revoca il consenso alle app OAuth, rimuovi la condivisione esterna, sospendi gli utenti a rischio e notifica i proprietari delle app. Automatizza l’applicazione ricorrente per prevenire la deriva della configurazione (drift).
Microsoft Purview estende la governance ai dati:
- Mappa dei dati e scansione: Registra ed esegui la scansione di Azure Storage, SQL, Synapse e archivi multicloud per individuare asset e derivazione (lineage). Classifica con classificatori predefiniti e personalizzati.
- Etichette di riservatezza e protezione: Applica etichette con crittografia e diritti di utilizzo; etichetta automaticamente in base al contenuto e al contesto. Applica l’accesso basato su etichette in Microsoft 365 e integra con DLP per prevenire l’esfiltrazione.
- Allineamento delle policy: Mappa la sensibilità di Purview ai tag (es. DataSensitivity) e implementa controlli di compensazione tramite Azure Policy (es. richiedi Private Endpoints per gli archivi HighlyConfidential).
Gli audit trail devono essere completi e a prova di manomissione:
- Azure Activity Log: Registra le operazioni del piano di controllo a livello di sottoscrizione. Invia in streaming a Log Analytics e archivia su Storage tramite le impostazioni di diagnostica. Conserva copie a lungo termine al di fuori della sottoscrizione, in una sottoscrizione centrale “Security-Logs” per minimizzare la minaccia interna (insider threat).
- Impostazioni di diagnostica delle risorse: Abilitale per i provider critici (Key Vault, Storage, SQL, AKS, Network Security Groups) per acquisire i log del piano dati e di servizio. Indirizzali a Log Analytics per il rilevamento e a Storage per la conservazione.
- Archiviazione immutabile per i log: Utilizza Blob Storage con conservazione basata sul tempo o blocco a fini giudiziari (WORM). Abilita allowProtectedAppendWritesAll in modo che la diagnostica possa continuare ad aggiungere dati mentre l’immutabilità è applicata. Configura policy del ciclo di vita per il controllo dei costi, ma non eliminare mai i dati entro il periodo di conservazione obbligatorio. Questo è fondamentale per le prove normative e la forense degli incidenti.
Scenario pratico
Contoso, un rivenditore globale, sta attivando due nuove sottoscrizioni di produzione e deve standardizzare la postura di sicurezza, raggiungere la conformità con l’Azure Security Benchmark e conservare log immutabili per sette anni, minimizzando l’attrito operativo.
- Stabilire la governance a livello di gruppo di gestione
- Crea un gruppo di gestione Prod e inserisci entrambe le sottoscrizioni al suo interno.
- Motivazione: L’ereditarietà assicura la coerenza di policy, piani Defender e RBAC senza deriva per singola sottoscrizione e riduce il debito di configurazione.
- Assegnare iniziative di sicurezza e piani di Defender for Cloud
- Assegna l’iniziativa Azure Security Benchmark con un effetto Deny sugli IP pubblici per storage e SQL; abilita Defender for Servers Plan 2, Storage, SQL, Containers, Key Vault e DNS a livello del gruppo di gestione Prod.
- Motivazione: I piani sbloccano rilevamenti avanzati; l’iniziativa codifica i controlli come guardrail. L’assegnazione a livello di gruppo di gestione garantisce un’applicazione uniforme e un calcolo coerente del Secure Score.
- Implementare l’automazione guidata da policy e le esenzioni
- Aggiungi policy DeployIfNotExists per installare automaticamente MDE e l’agente di Log Analytics dove necessario; crea attività di correzione per le risorse esistenti. Usa esenzioni con scadenza per le VM legacy che non possono essere integrate immediatamente.
- Motivazione: DeployIfNotExists trasforma le linee guida in azioni; le esenzioni a tempo mantengono lo slancio verso la conformità senza bloccare le operazioni critiche.
- Configurare un flusso di lavoro di correzione guidato dal punteggio di sicurezza
- Crea un flusso di lavoro con Logic App in Defender for Cloud per aprire ticket P1 per qualsiasi azione di miglioramento con un impatto sul punteggio >3% che diventa non integra (unhealthy) in produzione, e notifica automaticamente i proprietari delle risorse.
- Motivazione: L’impatto sul punteggio allinea la correzione a una riduzione misurabile del rischio, e l’automazione applica gli SLO senza triage manuale.
- Centralizzare i log di audit con immutabilità
- Dall’Activity Log di ogni sottoscrizione e dalle risorse critiche (Key Vault, Storage, SQL, AKS), crea impostazioni di diagnostica per inviare i dati a un’area di lavoro Log Analytics centrale e a un account di Storage con una policy di conservazione basata sul tempo di sette anni e con allowProtectedAppendWritesAll abilitato.
- Motivazione: La centralizzazione semplifica il rilevamento e la conformità; l’archiviazione immutabile fornisce la non ripudiabilità richiesta per audit e analisi forensi.
- Gestire l’uso di SaaS e il rischio di egress
- Collega Defender for Cloud Apps a Defender for Endpoint per l’individuazione delle app; contrassegna le app ad alto rischio come non approvate e applica Conditional Access App Control per i dispositivi non gestiti che accedono alle app approvate.
- Motivazione: Riduce il rischio di shadow IT e applica controlli di sessione in tempo reale senza interrompere le esperienze sui dispositivi gestiti.
- Integrare la governance dei dati con Purview
- Registra gli asset di Storage e SQL di Contoso in Purview, esegui scansioni e applica automaticamente le etichette di riservatezza. Mappa le etichette a una policy di tag Environment e DataSensitivity che richieda Private Endpoints per gli archivi HighlyConfidential.
- Motivazione: Le policy consapevoli dei dati assicurano che il rafforzamento della rete (hardening) sia applicato automaticamente dove vengono scoperti dati sensibili, chiudendo il cerchio tra la governance dei dati e la sicurezza dell’infrastruttura.
← Gestione delle chiavi · Tutti i domini · Microsoft Sentinel e operazioni di sicurezza →
Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Supera l'esame →