Microsoft AZ-900: Governance e Conformità — Guida allo studio

By Laurynas Brazys · 23 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

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

La governance in Azure allinea l’utilizzo del cloud con i requisiti aziendali, di sicurezza e normativi attraverso un insieme stratificato di controlli: struttura organizzativa, policy, distribuzioni standardizzate, protezione contro le modifiche accidentali e auditing continuo. Queste funzionalità operano nativamente nel control plane di Azure Resource Manager e scalano da una singola sottoscrizione a grandi ambienti multi-tenant. Una buona governance riduce la deriva della configurazione, impone la coerenza e fornisce prove di conformità senza ostacolare la velocità degli sviluppatori. La conformità dipende da un inventario solido e da una cronologia delle modifiche. Azure fornisce visibilità quasi in tempo reale delle risorse tra le sottoscrizioni, mappature normative prescrittive e strumenti di data discovery per individuare e classificare le informazioni sensibili. Il risultato è una postura cloud difendibile in cui gli standard vengono definiti una sola volta, applicati automaticamente, comprovati continuamente e corretti su larga scala.

Azure Policy: definizioni, iniziative, controlli sulla posizione e remediation

Azure Policy definisce dei guardrail (barriere di protezione) che valutano le configurazioni delle risorse durante la creazione/aggiornamento (e regolarmente in seguito) e impongono gli stati desiderati. Una definizione di policy utilizza condizioni ed effetti per valutare le proprietà delle risorse esposte dai resource provider. Gli effetti principali includono Deny, Audit, Append, Modify, DeployIfNotExists, AuditIfNotExists e Disabled. Le policy possono essere assegnate a livello di management group, sottoscrizione, gruppo di risorse o singola risorsa, e l’ereditarietà assicura che le assegnazioni più ampie vengano applicate verso il basso, a meno che non vengano escluse tramite notScopes. Le iniziative raggruppano definizioni di policy correlate in un unico pacchetto con parametri per un’assegnazione coerente e ripetibile. Ad esempio, un’iniziativa di baseline per la sicurezza può includere policy che richiedono impostazioni di diagnostica, limitano gli endpoint pubblici, impongono l’uso di tag e verificano la mancanza di backup. L’assegnazione dell’iniziativa applica tutte le policy incluse con un’unica azione e produce una singola vista di conformità. Le policy predefinite “Allowed locations” limitano dove i gruppi di risorse e le risorse possono essere creati, impedendo la distribuzione in aree non approvate e aiutando con la residenza e la sovranità dei dati. Quando una richiesta di creazione punta a un’area proibita, l’effetto Deny blocca l’operazione prima che raggiunga il resource provider, garantendo una conformità rigorosa. Quando viene scoperta una deriva della configurazione, le attività di remediation riportano le risorse in conformità su larga scala. Per le policy DeployIfNotExists e Modify, l’identità gestita (managed identity) di un’assegnazione di policy viene utilizzata per riconfigurare le risorse non conformi (ad esempio, abilitando le impostazioni di diagnostica sugli account di archiviazione o aggiungendo i tag richiesti). I processi di remediation possono avere un ambito ristretto o essere eseguiti su intere sottoscrizioni, e i risultati di conformità emergono per singola policy e per singola risorsa per la tracciabilità dell’audit.

• Scopo
  • Definizione di Policy: Singola regola che valuta le proprietà delle risorse
  • Iniziativa (Policy Set): Pacchetto di definizioni di policy con parametri condivisi
  • Ambito di Assegnazione: Management group, sottoscrizione, gruppo di risorse o risorsa
  • Effetti Comuni: Deny, Audit, Append, Modify, DeployIfNotExists, AuditIfNotExists
  • Requisiti di Remediation: Identità gestita (managed identity) sull’assegnazione; applicabile a Modify/DeployIfNotExists
• Caso d’uso
  • Definizione di Policy: Imporre SKU, TLS, tag, endpoint privati
  • Iniziativa (Policy Set): Applicare una baseline di sicurezza o di governance
  • Ambito di Assegnazione: Applicazione su larga scala con ereditarietà ed esclusioni
  • Effetti Comuni: Applicazione rigorosa (hard enforcement) o auditing solo come prova
  • Requisiti di Remediation: Permessi sufficienti per modificare le risorse di destinazione

Azure Blueprints: pacchettizzare standard con policy, RBAC, gruppi di risorse e template

Azure Blueprints pacchettizza gli artefatti di governance in modo che le organizzazioni possano creare ambienti conformi in modo coerente e ripetibile. Una definizione di blueprint può includere assegnazioni di policy, assegnazioni di controllo degli accessi in base al ruolo di Azure (RBAC), definizioni di gruppi di risorse e artefatti di distribuzione come i template ARM (incluso Bicep) per il provisioning di infrastruttura standard. I parametri consentono di personalizzare ogni assegnazione preservando un’unica fonte di verità versionata. I blueprint aiutano a separare “cosa deve esistere e chi può fare cosa” dal codice del carico di lavoro (workload). Ad esempio, un blueprint di baseline può creare gruppi di risorse “spoke”, assegnare il ruolo Reader ai team di audit e Contributor ai team di piattaforma, distribuire un template di rete hub-and-spoke e assegnare iniziative per la diagnostica e la sicurezza. L’assegnazione del blueprint a una o più sottoscrizioni applica tutti gli artefatti nell’ordine corretto e registra lo stato di conformità. Il versioning supporta aggiornamenti controllati e il blocco degli artefatti (artifact locking) può proteggere i componenti critici dopo la distribuzione.

• Focus primario
  • Azure Policy: Guardrail di configurazione e conformità
  • Template ARM/Bicep: Distribuzione dichiarativa di risorse
  • Azure Blueprints: Pacchettizzazione e governance degli standard tra le sottoscrizioni
• Include RBAC
  • Azure Policy: No (assegnazione separata)
  • Template ARM/Bicep: No (assegnazione separata)
  • Azure Blueprints: Sì (assegnazioni di ruolo come artefatti)
• Include Policy
  • Azure Policy: N/D
  • Template ARM/Bicep: No (possono distribuire risorse di policy, non assegnarle)
  • Azure Blueprints: Sì (assegnazioni di policy come artefatti)
• Crea Gruppi di Risorse
  • Azure Policy: Può richiedere/imporre convenzioni di denominazione/tag
  • Template ARM/Bicep: Possono distribuire al loro interno o crearli tramite distribuzioni annidate (nested)
  • Azure Blueprints: Sì (definisce artefatti RG come parte del blueprint)
• Uso tipico
  • Azure Policy: Limitare SKU, imporre diagnostica, tag
  • Template ARM/Bicep: Provisioning di VNet, Key Vault, App Services
  • Azure Blueprints: Creare landing zone conformi con policy + RBAC + infrastruttura

Organizzazione e standard: gruppi di gestione, sottoscrizioni, gruppi di risorse, denominazione e tag

La gerarchia di gestione di Azure consente la scalabilità della governance. I gruppi di gestione si trovano al di sopra delle sottoscrizioni e forniscono un punto in cui applicare policy e RBAC che vengono ereditati da tutte le sottoscrizioni figlio. Le sottoscrizioni definiscono la fatturazione, le quote di servizio e un confine di sicurezza per la maggior parte dei controlli. I gruppi di risorse contengono risorse con ciclo di vita, permessi e logica di deployment allineati; ogni risorsa appartiene esattamente a un gruppo di risorse e a una sottoscrizione. Gli standard di denominazione e di tagging traducono l’intento di governance in chiarezza operativa. I nomi dovrebbero codificare abbreviazioni del tipo di risorsa, il carico di lavoro, l’ambiente e la regione (ad esempio, kv-payroll-prod-eus2) entro i limiti del servizio. I tag aggiungono contesto di business trasversalmente alle risorse per l’allocazione dei costi, la proprietà, la classificazione dei dati e le chiavi per l’automazione (ad esempio, costCenter=FIN, owner=ops-team@contoso.com, dataSensitivity=Confidential). Azure Policy, con gli effetti Modify e Append, impone la presenza dei tag e pattern per i loro valori, e può ereditare i tag dai gruppi di risorse alle risorse. La coerenza in questo ambito permette di ottenere report dei costi affidabili, revisioni degli accessi e automazione del ciclo di vita.

• Gruppo di Gestione (Management Group)
  • Scopo: Governare su larga scala tra più sottoscrizioni
  • Usi Comuni: Applicare policy, RBAC e iniziative a business unit o ambienti
  • Può Contenere: Gruppi di gestione figlio e sottoscrizioni
  • Note Chiave: Fino a 6 livelli di profondità (esclusa la radice); l’ereditarietà fluisce verso il basso
• Sottoscrizione (Subscription)
  • Scopo: Confine di fatturazione e di servizio
  • Usi Comuni: Isolamento dei carichi di lavoro, segregazione dei costi, gestione delle quote
  • Può Contenere: Gruppi di risorse e risorse
  • Note Chiave: Le assegnazioni di policy/RBAC a questo livello influenzano tutti i gruppi di risorse contenuti
• Gruppo di Risorse (Resource Group)
  • Scopo: Confine di ciclo di vita e permessi per le risorse
  • Usi Comuni: Distribuire, aggiornare ed eliminare insieme le risorse correlate
  • Può Contenere: Risorse
  • Note Chiave: Una risorsa può esistere in un solo RG; gli spostamenti tra RG/sottoscrizioni hanno vincoli specifici per servizio

Blocchi delle risorse e prevenzione dell’eliminazione accidentale

I blocchi delle risorse forniscono un’ultima linea di difesa contro le modifiche non intenzionali. I blocchi vengono applicati a livello di sottoscrizione, gruppo di risorse o singola risorsa e vengono ereditati verso il basso. Esistono due tipi di blocco: CanNotDelete impedisce l’eliminazione ma consente operazioni di lettura e scrittura, e ReadOnly limita tutte le operazioni di scrittura ed eliminazione (consentendo di fatto solo le operazioni di lettura). I blocchi proteggono da azioni eseguite tramite il portale, la CLI, PowerShell, ARM/Bicep e strumenti IaC di terze parti. Utilizzare CanNotDelete su infrastrutture condivise o critiche — reti virtuali, tabelle di routing, zone DNS, Key Vault di produzione — in modo che la manutenzione possa continuare mentre le eliminazioni sono bloccate. Utilizzare ReadOnly con parsimonia per artefatti che devono rimanere completamente statici, come account di archiviazione archiviati o contenitori di prove a fini normativi; molti servizi richiedono operazioni di scrittura per il normale funzionamento e fallirebbero con un blocco ReadOnly. Solo i principal con permessi sufficienti (ad esempio, Owner con Microsoft.Authorization/locks/*) possono rimuovere un blocco, e la rimozione di un blocco è essa stessa un’operazione tracciabile nell’Activity Log.

• CanNotDelete
  • Letture: Consentite
  • Scritture/Aggiornamenti: Consentiti
  • Eliminazioni: Bloccate
  • Casi d’Uso Tipici: Proteggere VNet, tabelle di routing, Key Vault di produzione, RG critici
  • Considerazioni: Consente modifiche alla configurazione; le operazioni di eliminazione falliscono finché il blocco non viene rimosso
• ReadOnly
  • Letture: Consentite
  • Scritture/Aggiornamenti: Bloccati
  • Eliminazioni: Bloccate
  • Casi d’Uso Tipici: Preservare archivi di prove, storage di archiviazione, configurazioni immutabili
  • Considerazioni: Molti servizi non funzionano correttamente con ReadOnly; aggiornamenti e scalabilità sono bloccati

Audit, inventario e conformità normativa: Resource Graph, Activity Log, Defender for Cloud e Microsoft Purview

Azure Resource Graph fornisce query di inventario e postura rapide e su larga scala tra sottoscrizioni e gruppi di gestione utilizzando Kusto Query Language (KQL). Consente di rispondere a domande come quali account di archiviazione non dispongono di crittografia, quali VNet espongono IP pubblici e quali risorse non sono conformi ai criteri. I risultati alimentano dashboard, la sincronizzazione di CMDB e le pipeline di correzione. Resource Graph può anche far emergere gli stati di conformità ai criteri, la distribuzione dei tag e le dimensioni di attribuzione dei costi se combinato con i dati di Cost Management. Il log attività di Azure (Azure Activity Log) registra le operazioni del piano di controllo (control-plane) sulle risorse, includendo chi ha fatto cosa e quando, con una conservazione predefinita di 90 giorni. Inoltrare il log attività a Log Analytics, Azure Storage o Event Hubs per la conservazione a lungo termine, la correlazione e l’ingestione in sistemi SIEM. L’analisi della cronologia delle modifiche individua le deviazioni dalla configurazione (configuration drift), supporta la risposta agli incidenti e fornisce prove per gli audit. Microsoft Defender for Cloud traduce la postura tecnica in viste normative mappando le valutazioni (assessment) a standard come Azure Security Benchmark, ISO/IEC 27001, NIST SP 800-53, PCI DSS e CIS. La dashboard di conformità normativa mostra i controlli superati/non superati, le risorse interessate e le indicazioni per la correzione. L’abilitazione del provisioning automatico (auto-provisioning) integra agenti e criteri dove necessario, e il punteggio di sicurezza (secure score) offre una lente per la prioritizzazione. Microsoft Purview rileva, classifica e cataloga i dati tra origini Azure, multicloud e on-premise. Le scansioni identificano dati sensibili (ad esempio, finanziari, PII, sanitari) in Azure Storage, SQL, Synapse, Power BI e molti altri, applicando classificatori predefiniti o personalizzati. La mappa dati (Data Map) e il catalogo (Catalog) di Purview forniscono la derivazione dei dati (lineage), la proprietà e l’etichettatura di sensibilità che si integrano con Microsoft Information Protection, abilitando la prevenzione della perdita di dati (data loss prevention) e decisioni sulle policy di accesso in linea con gli obblighi normativi.

• Funzione principale
  • Azure Resource Graph: Query di inventario e postura su larga scala
  • Activity Log: Traccia di audit del piano di controllo per le operazioni
  • Defender for Cloud (Regulatory): Mappare la postura agli standard e prioritizzare le correzioni
  • Microsoft Purview: Rilevamento, classificazione, catalogo e derivazione dei dati
• Ambito
  • Azure Resource Graph: Tra gruppi di gestione/sottoscrizioni
  • Activity Log: Per tenant con instradamento verso LA/Storage/Event Hub
  • Defender for Cloud (Regulatory): Per sottoscrizione/tenant con assegnazioni di iniziative
  • Microsoft Purview: Tra origini dati (Azure, M365, on-premise, multicloud)
• Output tipici
  • Azure Resource Graph: Risultati di query KQL, dashboard, esportazioni
  • Activity Log: Chi/cosa/quando, stato, codici di errore
  • Defender for Cloud (Regulatory): Stato di conformità dei controlli, punteggio di sicurezza, raccomandazioni
  • Microsoft Purview: Asset di dati, etichette di sensibilità, schema, grafici di derivazione

Problema Pratico: Standardizzare landing zone conformi presso Fabrikam Retail Group

Scenario: Fabrikam Retail Group opera in Nord America e nell’UE con rigidi obblighi di residenza dei dati e di conformità PCI DSS. Diversi team applicativi distribuiscono carichi di lavoro mensilmente e le precedenti distribuzioni ad-hoc hanno portato a un tagging incoerente, a risorse in aree geografiche non approvate e alla cancellazione occasionale di componenti di rete condivisi. La direzione richiede landing zone standardizzate e conformi, prove continue dell’efficacia dei controlli e l’individuazione di dati sensibili su tutte le piattaforme di storage e di analisi.

Sfida: Progettare e implementare un approccio di governance Azure che imponga restrizioni sulle aree geografiche, standardizzi le distribuzioni con criteri e RBAC, prevenga la cancellazione accidentale dell’infrastruttura di base, mantenga un inventario e una cronologia delle modifiche, generi report di conformità a ISO 27001 e PCI DSS, e individui/classifichi i dati sensibili.

Approccio Raccomandato:

1. Creare una gerarchia di gruppi di gestione: radice /Fabrikam; figli /Corp (servizi condivisi), /NA e /EU; sotto ciascuno, aggiungere /Prod e /NonProd. Spostare le sottoscrizioni nei gruppi di gestione appropriati.
2. Creare iniziative di criteri a livello di gruppo di gestione: (a) Aree geografiche consentite per ogni zona, (b) Tag obbligatori (costCenter, owner, dataSensitivity) con effetti Modify/Append, (c) Imporre l’invio delle impostazioni di diagnostica a Log Analytics per i servizi principali, (d) Restrizioni su SKU e accesso da reti pubbliche per i servizi PaaS. Assegnare le iniziative a /NA e /EU con parametri appropriati per l’area geografica ed escludere le sottoscrizioni break-glass tramite notScopes.
3. Creare un pacchetto blueprint per la landing zone standard: gli artefatti includono la creazione di gruppi di risorse hub e per le applicazioni, assegnazioni RBAC (ruolo Network Contributor al team di piattaforma, Reader al team di audit), assegnazioni di criteri per la diagnostica e i tag, e template ARM per distribuire vNET, peering, Key Vault e Log Analytics. Versionare il blueprint e assegnarlo a tutte le sottoscrizioni Prod e NonProd.
4. Applicare blocchi delle risorse: CanNotDelete su VNet hub, tabelle di routing, zone DNS condivise e aree di lavoro Log Analytics; ReadOnly su un account di archiviazione per gli export normativi. Verificare che i proprietari (Owner) delle sottoscrizioni dei servizi condivisi possano rimuovere i blocchi con le dovute approvazioni quando sono pianificate delle modifiche.
5. Abilitare l’esportazione del Log attività da tutte le sottoscrizioni verso un’area di lavoro Log Analytics centralizzata e archiviarlo in un account di archiviazione con conservazione immutabile (basata sul tempo) per sette anni. Creare dashboard di Resource Graph che elenchino le risorse non conformi, i tag mancanti e gli asset per area geografica e per tag dataSensitivity.
6. Abilitare Microsoft Defender for Cloud su tutto il tenant. Selezionare ISO/IEC 27001 e PCI DSS come standard normativi, attivare il provisioning automatico e rivedere le raccomandazioni. Creare elementi di lavoro (work item) dai rilievi ad alta gravità e monitorare i miglioramenti del punteggio di sicurezza per ogni sottoscrizione.
7. Distribuire Microsoft Purview nella sottoscrizione dei servizi condivisi /Corp. Registrare Azure SQL, Storage, Synapse e Power BI come origini dati. Configurare scansioni pianificate con i tipi di informazioni sensibili predefiniti e classificare i set di dati. Pubblicare il catalogo dati e assegnare i proprietari dei dati. Esportare le etichette di riservatezza individuate per informare le policy di accesso condizionale e DLP.

Logica di Azure: Questo approccio parte dalla definizione dell’ambito tramite i gruppi di gestione, in modo che i criteri e l’RBAC vengano ereditati in modo prevedibile. Successivamente, impone i controlli di base con Azure Policy e le relative iniziative per prevenire la non conformità al momento della distribuzione. Il blueprint raggruppa criteri, RBAC, gruppi di risorse e template di infrastruttura per creare landing zone coerenti, consentendo al contempo la parametrizzazione per area geografica e ambiente. I blocchi delle risorse proteggono i servizi condivisi critici dalla cancellazione accidentale, senza ostacolare la configurazione quotidiana ove appropriato. La conservazione centralizzata del Log attività e Resource Graph forniscono un inventario affidabile e prove delle modifiche. Defender for Cloud offre una mappa dei controlli normativi in tempo reale e una remediation prioritizzata, mentre Microsoft Purview individua e classifica i dati sensibili per supportare i controlli PCI DSS e di residenza dei dati nell’intero patrimonio di analisi di Fabrikam.

← Gestione dei Costi ed Economia dei Servizi · Tutti i domini · Monitoraggio →

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

Sfoglia Microsoft →