Microsoft AZ-305: Identità, Governance e Conformità — Guida allo studio

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

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

Panoramica

Identità, governance e conformità in Azure si basano su una progettazione coerente che attraversa Microsoft Entra ID (precedentemente Azure AD), guardrail basati su policy e accesso con privilegi minimi sia a livello di utente umano che di workload. Una soluzione ben architettata bilancia l’elevazione dei privilegi just-in-time per gli amministratori, i controlli adattivi basati sul rischio per gli utenti, la governance standardizzata delle risorse su larga scala e un accesso esterno fluido per partner e clienti, il tutto senza sacrificare l’agilità operativa.

Accesso con Privilegi e Controlli Adattivi del Rischio

Privileged Identity Management (PIM) converte l’accesso amministrativo permanente in autorizzazioni limitate nel tempo e verificabili. Assegnare i ruoli con privilegi come idonei (eligible) anziché attivi (active) per minimizzare l’esposizione; gli utenti devono attivare i ruoli idonei, operazione che tipicamente innesca l’autenticazione a più fattori, l’inserimento di un ticket/giustificazione, workflow di approvazione opzionali e una durata di attivazione limitata. Le impostazioni del ruolo definiscono gli approvatori, i requisiti di MFA, le notifiche e i ticket di incidente. Combinare questo approccio con i gruppi di accesso con privilegi (privileged access groups) in modo che i ruoli di Azure AD e i ruoli delle risorse di Azure possano essere governati tramite l’appartenenza a un gruppo soggetta all’attivazione PIM, producendo un unico piano di controllo con auditing completo. Utilizzare le verifiche di accesso (access reviews) all’interno di PIM per convalidare continuamente chi mantiene le assegnazioni idonee o attive per ruoli, gruppi e applicazioni aziendali. Le verifiche possono applicare automaticamente i risultati e rimuovere l’accesso per chi non risponde, consentendo un’attestazione periodica senza interventi manuali.

Identity Protection applica il rilevamento del rischio basato su machine learning a utenti e accessi. Le policy di rischio utente (user risk policies) valutano la probabilità di credenziali compromesse e possono richiedere una modifica sicura della password o bloccare l’accesso fino alla risoluzione; le policy di rischio di accesso (sign-in risk policies) analizzano il contesto della sessione corrente (spostamento impossibile, proprietà di accesso non familiari, IP collegati a malware) e possono richiedere l’MFA o bloccare i tentativi rischiosi. Configurare le azioni di rimedio in modo che i rischi medi e alti attivino l’MFA o il reset della password, mentre il rischio basso potrebbe essere solo monitorato. Inviare i segnali a Conditional Access anziché utilizzare l’MFA per singolo utente; questo centralizza l’applicazione delle policy, supporta le eccezioni (account di emergenza “break-glass”) e riduce la deriva amministrativa.

Conditional Access unifica le decisioni contestuali. Le “named locations” (posizioni denominate) consentono di classificare intervalli di indirizzi come reti aziendali attendibili o geolocalizzazioni da bloccare o per cui richiedere controlli aggiuntivi; sfruttare IP attendibili verificati e regole basate sui paesi per mitigare i rischi provenienti da aree geografiche ad alto rischio. La conformità dei dispositivi (device compliance) si integra con Microsoft Intune in modo da poter richiedere un dispositivo conforme o uno stato “hybrid Azure AD joined” prima di concedere l’accesso ad app sensibili, e opzionalmente incorporare il rischio rilevato da Defender for Endpoint. Le restrizioni applicate dalle app (app-enforced restrictions) riducono il rischio di esfiltrazione dei dati restituendo un’esperienza web limitata in SharePoint Online ed Exchange Online che disabilita il download e la sincronizzazione per i dispositivi non gestiti. I controlli di sessione (session controls) regolano la durata delle sessioni e la frequenza con cui è richiesta una nuova autenticazione; impostare la frequenza di accesso (sign-in frequency) per i workload regolamentati, disabilitare le sessioni persistenti del browser per i chioschi condivisi e utilizzare Conditional Access App Control (tramite Defender for Cloud Apps) per monitorare e controllare le attività all’interno della sessione, come bloccare il download di file sensibili pur consentendone la visualizzazione nel browser. Combinati con le policy basate sul rischio, questi controlli forniscono sfide di autenticazione rafforzate solo quando necessario, preservando la produttività dell’utente.

Identità Esterne e dei Consumatori

Azure AD B2C separa l’IAM (Identity and Access Management) dei clienti dall’IAM della forza lavoro e fornisce un accesso scalabile per le app destinate ai consumatori. I flussi utente (user flow) integrati coprono la registrazione/accesso, la modifica del profilo e il ripristino della password con una configurazione minima. Quando sono necessarie orchestrazioni complesse — claims personalizzati, percorsi condizionali, verifica dell’identità o arricchimento dei claims tramite API REST — utilizzare le policy personalizzate (Identity Experience Framework). B2C supporta molti identity provider: account locali (email o telefono), provider OpenID Connect e OAuth 2.0 (Microsoft, Google, Apple), identity provider SAML 2.0 e federazione aziendale. La personalizzazione dei token include l’emissione di attributi personalizzati, claims opzionali e la trasformazione dei claims per le app downstream, il controllo della durata dei token e l’aggiunta di connettori API per convalidare o arricchire i dati utente nei punti decisionali critici.

Per la collaborazione B2B, Entitlement Management standardizza l’onboarding degli utenti esterni e minimizza la proliferazione degli account. I pacchetti di accesso (access package) incapsulano chi ottiene l’accesso (gruppi, app, siti SharePoint), chi può richiederlo e come viene approvato. Le “connected organizations” (organizzazioni connesse) formalizzano la fiducia con i tenant dei partner, consentendo ai loro utenti di richiedere pacchetti senza creare preventivamente account guest. Le policy del ciclo di vita assicurano che l’accesso non persista indefinitamente: impostare scadenze, richiedere verifiche di accesso periodiche, rimuovere automaticamente le assegnazioni alla scadenza o in caso di fallimento della verifica, e revocare l’accesso guest residuo se un utente perde tutte le sue assegnazioni. Questo modello si allinea al principio del privilegio minimo e riduce la gestione manuale del ciclo di vita degli utenti guest.

La pubblicazione esterna di applicazioni web interne è risolta al meglio con Azure AD Application Proxy. Connettori leggeri installati on-premise aprono solo connessioni in uscita (outbound) verso Azure, eliminando la necessità di aprire porte in entrata sul firewall. Raggruppare i connettori per scalabilità e affinità. Scegliere la pre-autenticazione di Azure AD per applicare Conditional Access prima che il traffico raggiunga la propria rete; ricorrere alla modalità Passthrough solo per scenari di nicchia. Per le app legacy che utilizzano l’Autenticazione Integrata di Windows (Integrated Windows Authentication), configurare la Kerberos Constrained Delegation in modo che il connettore possa ottenere un ticket Kerberos per il backend per conto dell’utente, abilitando un SSO trasparente dal cloud all’ambiente on-premise.

Governance su larga scala: Policy, Blueprint e Management Group

Azure Policy codifica i guardrail. Una definizione di policy utilizza condizioni ed effetti con parametri, in modo che la stessa regola possa essere riutilizzata in ambienti diversi. Organizza le definizioni correlate in iniziative per semplificare l’assegnazione e il reporting. Assegna le policy allo scope corretto — management group per una governance ampia, sottoscrizione per l’allineamento della piattaforma, resource group per override locali — e sfrutta l’ereditarietà per propagare i controlli verso il basso. Gli effetti principali includono:

Deny per bloccare le distribuzioni non conformi
Audit per contrassegnare le risorse per il reporting di conformità
Append per aggiungere proprietà come i tag richiesti
Modify per mutare le proprietà delle risorse alla creazione/aggiornamento
DeployIfNotExists per distribuire automaticamente o configurare le dipendenze
AuditIfNotExists e Disabled per esigenze specializzate Abbina DeployIfNotExists e Modify con attività di remediation. Assegna un’identità gestita (managed identity) a livello di assegnazione e concedile i ruoli minimi necessari per eseguire la remediation; avvia i processi di remediation per correggere retroattivamente il drift. Utilizza le esenzioni (exemption) con giustificazioni documentate per gestire le eccezioni senza disabilitare la governance.

Azure Blueprints impacchetta una landing zone distribuibile e versionata. Gli artefatti includono assegnazioni di policy, assegnazioni di ruolo, template ARM/Bicep e lo scaffolding dei resource group. Al momento dell’assegnazione, i parametri di input legano un blueprint versionato a un ambiente. Le modalità di blocco delle risorse (DoNotDelete o ReadOnly) proteggono le risorse fondamentali da modifiche accidentali, imponendo una separazione tra le responsabilità della piattaforma e quelle del carico di lavoro (workload).

I Management Group forniscono la gerarchia portante per la governance su scala enterprise. Progetta una struttura ad albero chiara — tipicamente piattaforma, landing zone per linea di business o regione, e sandbox — in modo che l’ereditarietà delle policy e di RBAC rifletta i confini operativi. L’RBAC assegnato a un management group si propaga a tutte le sottoscrizioni e i resource group figli, minimizzando le assegnazioni di ruolo ripetitive. I conflitti si risolvono in base all’ordine di valutazione e alla semantica degli effetti; un deny da una policy non può essere sovrascritto da RBAC. Usa questa struttura per applicare standard globali (baseline di sicurezza, tagging) ai livelli superiori, personalizzando al contempo i livelli inferiori con iniziative parametrizzate.

Autorizzazioni avanzate e federazione delle identità dei carichi di lavoro

Microsoft Entra Permissions Management (CIEM) rileva le identità umane e macchina e le loro autorizzazioni effettive su Azure, AWS e Google Cloud. Costruisce un grafo delle autorizzazioni basato sull’attività per identificare combinazioni di privilegi non utilizzate, eccessive e dannose. Utilizza gli insight per dimensionare correttamente i ruoli, rimuovere gli accessi inattivi e applicare il principio del privilegio minimo per service principal, identità gestite e utenti. Access Explorer mostra chi può fare cosa e su quale risorsa; i flussi di lavoro di remediation automatizzata possono rimuovere i diritti non necessari su larga scala, riducendo il raggio d’impatto (blast radius) e soddisfacendo gli audit di conformità.

La Workload Identity Federation elimina i segreti per i carichi di lavoro non-Azure che devono chiamare le API di Azure. Invece di archiviare i segreti client nel CI/CD, si crea una credenziale federata su una registrazione di app/principal di servizio che si fida di un emittente (issuer) esterno specifico (ad esempio, GitHub Actions OIDC) e limita i claim di soggetto (subject) e destinatario (audience) (ad esempio, repo, branch o ambiente). Il carico di lavoro esterno scambia il suo token OIDC di breve durata con un token di accesso Azure per assumere l’identità del principal di servizio. Ciò fornisce credenziali effimere e con ambito definito (scoped), senza l’overhead della rotazione dei segreti e con confini di fiducia granulari. Per Kubernetes, si abbina la federazione con Azure Workload Identity in modo che i pod ricevano token OIDC proiettati, legati a service account che mappano su credenziali federate, riducendo ulteriormente la gestione dei segreti.

Scenario pratico

Starbucks deve modernizzare la gestione delle identità e la governance, abilitando al contempo un accesso sicuro per i partner e preservando il SSO verso le applicazioni on-premise. L’azienda gestisce più sottoscrizioni Azure in diverse region, esegue applicazioni legacy SAP e intranet on-premise utilizzando la Integrated Windows Authentication, sviluppa app mobile per i consumatori e usa GitHub Actions per il CI/CD.

Stabilire una gerarchia di management group e controlli di base

Creare una gerarchia radice con piattaforma, landing zone per business unit e sandbox. Assegnare iniziative di Azure Policy ai livelli superiori per la gestione dei tag, le restrizioni sulle region e le baseline di sicurezza. Utilizzare Azure Blueprints per distribuire landing zone con assegnazioni di policy, di ruoli per i team di piattaforma e una struttura di resource group predefinite. I lock nel blueprint proteggono le risorse della piattaforma condivisa. Scelta motivata dalla necessità di centralizzare la governance e garantire ambienti coerenti e verificabili (auditable).

Implementare un’amministrazione basata sul principio del privilegio minimo

Configurare PIM con assegnazioni idonee (eligible) per i ruoli Azure AD e i ruoli delle risorse Azure tramite gruppi di accesso con privilegi. Richiedere MFA, giustificazione e approvazione per i ruoli ad alto impatto e limitare la durata dell’attivazione. Pianificare revisioni di accesso trimestrali per i gruppi con privilegi e le app aziendali, con applicazione automatica delle decisioni. Scelta motivata dalla necessità di minimizzare i privilegi permanenti (standing privilege) e automatizzare l’attestazione.

Applicare un accesso adattivo basato sul rischio

Abilitare le policy di Identity Protection sul rischio utente e sul rischio di accesso per forzare il reset della password in caso di rischio utente elevato e richiedere l’MFA per rischi di accesso medi ed elevati. Costruire policy di Conditional Access utilizzando le named location per considerare attendibili gli IP di uscita aziendali e limitare le aree geografiche ad alto rischio; richiedere dispositivi conformi (compliant) o ibridi (hybrid-joined) per le app sensibili; applicare restrizioni imposte dalle app a SharePoint ed Exchange per limitare i download su dispositivi non gestiti; e impostare la frequenza di accesso a 8 ore per i carichi di lavoro del settore finanziario. Questa combinazione offre una sicurezza robusta senza creare attrito persistente per l’utente.

Governare l’accesso dei partner esterni

Utilizzare i pacchetti di accesso di Entitlement Management per fornitori e consulenti, includendo ruoli Azure RBAC tramite gruppi, app richieste e risorse SharePoint. Configurare le organizzazioni connesse per i tenant dei partner e impostare policy di ciclo di vita con scadenza a 90 giorni e revisioni di accesso ricorrenti che rimuovono automaticamente chi non risponde. Scelta motivata dalla necessità di automatizzare l’onboarding/offboarding senza una gestione manuale degli utenti guest.

Pubblicare in modo sicuro le applicazioni on-premise

Distribuire i connettori di Azure AD Application Proxy in due data center, inserirli in gruppi di connettori e configurare la pre-autenticazione di Azure AD. Abilitare la Kerberos Constrained Delegation per i siti SAP e intranet per preservare il SSO con IWA. Applicare il Conditional Access a queste app aziendali. Scelta motivata dalla necessità di evitare la dipendenza da VPN ed estendere i controlli moderni alle app legacy.

Mettere in sicurezza le applicazioni per i consumatori

Implementare Azure AD B2C con flussi utente predefiniti per la registrazione/accesso e il reset della password, integrando IdP social come Apple e Google. Per i casi d’uso legati ai programmi fedeltà, aggiungere policy personalizzate per chiamare API REST per la verifica dell’identità (identity proofing) e arricchire i token con attributi personalizzati. Scelta motivata dalla necessità di separare le identità dei consumatori da quelle dei dipendenti e di scalare a livello globale.

Dimensionare correttamente le autorizzazioni e rimuovere i segreti dal CI/CD

Distribuire Microsoft Entra Permissions Management per rilevare le autorizzazioni eccessive per utenti, identità gestite e principal di servizio su più cloud e applicare un dimensionamento corretto basato sull’attività (rightsizing). Configurare la Workload Identity Federation per GitHub Actions creando credenziali federate vincolate all’organizzazione/repository/branch di Starbucks e concedendo solo i ruoli necessari sulle sottoscrizioni di destinazione. Scelta motivata dalla necessità di eliminare i segreti a lunga durata e applicare continuamente il principio del privilegio minimo.

Tutti i domini · Archiviazione dei dati e soluzioni di database →

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