Microsoft AZ-500: Gestione dell'identità e degli accessi — Guida allo studio

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

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 delle identità e degli accessi (IAM) in Microsoft Azure è incentrata su Microsoft Entra ID (precedentemente Azure AD). Questo servizio governa chi può accedere a quali risorse, a quali condizioni e con quali privilegi. Un’architettura IAM efficace minimizza i privilegi permanenti, impone un accesso condizionale e basato sul rischio, e adotta un’autenticazione moderna sia per le persone che per i carichi di lavoro (workload), supportando al contempo scenari di collaborazione ibrida ed esterna.

Costrutti di identità e ambiti di Microsoft Entra

• Tenant, utenti e gruppi
  • Un tenant rappresenta il confine di identità e il tessuto di fiducia della tua organizzazione. Gli utenti possono essere account di tipo membro o guest (B2B). Utilizzare i gruppi di sicurezza per l’autorizzazione e i gruppi di Microsoft 365 per le funzionalità di collaborazione; preferire i gruppi dinamici per ridurre la gestione manuale delle appartenenze.
• Unità amministrative (AU)
  • Le AU consentono di delegare ruoli della directory su un sottoinsieme di utenti/dispositivi (ad esempio, l’helpdesk regionale può gestire solo gli utenti europei). Questo supporta il principio del privilegio minimo per le attività della directory.
• Ruoli della directory e ambiti di assegnazione dei ruoli
  • I ruoli della directory (ad es. Global Administrator, User Administrator) si applicano alle risorse di Microsoft Entra. Assegnare l’ambito dei ruoli della directory a livello di AU quando possibile per limitare il raggio d’impatto. Il ruolo Global Administrator è necessario per configurare inizialmente Privileged Identity Management (PIM).
• Ambiti del controllo degli accessi in base al ruolo di Azure (Azure RBAC)
  • Azure RBAC governa l’accesso alle risorse di Azure. Assegnare i ruoli a livello di gruppo di gestione, sottoscrizione, gruppo di risorse o singola risorsa. L’ereditarietà si propaga verso il basso; scegliere sempre l’ambito più ristretto possibile per ridurre l’eccesso di privilegi.
• Ragionamento operativo
  • Separare i ruoli della directory (Entra) dall’Azure RBAC (autorizzazione delle risorse). Utilizzare le AU e ambiti RBAC ristretti per confinare il raggio d’azione amministrativo, ridurre le opportunità di movimento laterale e semplificare le revisioni degli accessi.

Controllo degli accessi con Azure RBAC e il principio del privilegio minimo

• Ruoli predefiniti e principio del privilegio minimo
  • Preferire il ruolo predefinito più specifico che si adatta all’attività. Esempio: fornire accesso di sola estrazione (pull) delle immagini dei container con AcrPull e accesso di caricamento/invio (push) con AcrPush, invece del più ampio ruolo Contributor. Per Key Vault, concedere il controllo amministrativo tramite RBAC solo agli amministratori del vault, utilizzando al contempo criteri di accesso granulari per operazioni specifiche sugli oggetti, come la gestione dei certificati.
• Ereditarietà delle assegnazioni di ruolo
  • Assegnare all’ambito più basso possibile. Le assegnazioni a livello di gruppo di gestione o sottoscrizione si propagano a cascata; evitare diritti ampi ed ereditati, a meno che non sia una scelta deliberata. Quando è necessario un RBAC coerente tra le sottoscrizioni, applicare in modo omogeneo le assegnazioni di ruolo tramite Azure Blueprints (o alternative IaC moderne) piuttosto che con assegnazioni manuali in PIM.
• Assegnazioni di negazione (Deny)
  • Le assegnazioni di negazione bloccano esplicitamente le azioni indipendentemente dalle assegnazioni di autorizzazione (allow) e sono tipicamente create da servizi Azure come Azure Policy o Blueprints. Utilizzarle per imporre guardrail non negoziabili (ad esempio, impedire regole di rete pubblica su risorse sensibili).
• Ruoli personalizzati
  • Quando i ruoli predefiniti sono troppo ampi, definire ruoli personalizzati con solo le azioni necessarie. Convalidare tramite test del privilegio minimo e revisioni degli accessi.

{
  "Name": "Storage Blob Reader (TagsBlocked)",
  "IsCustom": true,
  "Description": "Read blobs; no tag write",
  "Actions": [
    "Microsoft.Storage/storageAccounts/blobServices/containers/read",
    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read"
  ],
  "NotActions": [
    "Microsoft.Resources/tags/write"
  ],
  "AssignableScopes": ["/subscriptions/00000000-0000-0000-0000-000000000000"]
}

• Ragionamento operativo
  • L’uso di ambiti RBAC e ruoli personalizzati riduce i diritti eccessivi e la superficie di audit. Le assegnazioni di negazione codificano vincoli di conformità “rigidi” che non possono essere aggirati da concessioni “allow” erroneamente ampie, migliorando la resilienza della postura di sicurezza.

Accesso con privilegi, accesso condizionale e Identity Protection

• Privileged Identity Management (PIM)

  • Idoneo (eligible) vs attivo (active): le assegnazioni idonee non concedono permessi permanenti; gli utenti devono attivare l’accesso JIT per diventare attivi. Imporre approvazione, giustificazione e MFA all’attivazione; impostare durate limitate e richiedere riferimenti a ticket per la tracciabilità. Iniziare con l’individuazione dei ruoli con privilegi per comprendere l’esposizione attuale. Utilizzare revisioni periodiche degli accessi, idealmente con i proprietari delle risorse o dei gruppi come revisori, per convalidare la necessità continua.

• Accesso condizionale (CA)

  • Le assegnazioni si applicano a utenti/gruppi, identità dei carichi di lavoro, app cloud e azioni. Le condizioni includono il rischio di accesso, la piattaforma/stato del dispositivo, le posizioni, le app client e i filtri per dispositivi e app. I controlli di concessione possono richiedere MFA, dispositivi conformi o aggiunti ad Azure AD in modalità ibrida, criteri di protezione delle app o condizioni d’uso. I controlli di sessione limitano la frequenza di accesso, le sessioni persistenti e le restrizioni applicate dalle app (ad es. accesso solo web per SharePoint). Utilizzare la modalità solo report per convalidare in sicurezza l’impatto dei criteri prima di applicarli. Mantenere esclusioni per gli account di emergenza (break-glass) e implementare rollout graduali per prevenire blocchi dell’accesso.

• Identity Protection

  • Il rischio utente (user risk) riflette la probabilità che un account sia compromesso; il rischio di accesso (sign-in risk) riflette la probabilità che una sessione specifica sia rischiosa. Configurare i criteri per richiedere un risanamento sicuro:
    • Utenti con credenziali trapelate: trattare come rischio utente Alto; forzare il reset della password e bloccare fino al risanamento.
    • Accessi da IP con attività sospetta: trattare almeno come rischio di accesso Medio; richiedere una verifica con MFA o bloccare per le app sensibili.
  • Integrare con l’accesso condizionale (CA) per adattare la fiducia in tempo reale. Tracciare la cronologia dei rischi e dei risanamenti per misurarne l’efficacia.

• Ragionamento operativo

  • PIM elimina i privilegi permanenti e impone un’attivazione forte e verificabile. L’accesso condizionale (CA) e Identity Protection applicano il principio zero trust, verificando ogni tentativo di accesso in base a utente, dispositivo, sessione e rischio, riducendo il successo del furto di credenziali e del replay di token.

Identità ibride e di workload

• Opzioni di identità ibrida
  • Sincronizzazione degli hash delle password (PHS): sincronizza gli hash delle password in Entra ID. Semplice e resiliente; non applica i criteri di accesso on-premises al momento dell’autenticazione.
  • Autenticazione pass-through (PTA): convalida le password confrontandole con i DC on-prem tramite connettori leggeri; applica i criteri per le password e le restrizioni degli account on-prem in tempo reale, senza AD FS.
  • Federazione (es. AD FS): sposta l’autenticazione su un STS on-prem. Da usare solo quando richiesto per attestazioni complesse o scenari legacy; introduce più server e un maggiore overhead operativo.
  • Single Sign-On (SSO) facile: consente agli utenti di accedere da dispositivi aggiunti a un dominio all’interno della rete aziendale con un numero minimo di richieste di credenziali.
  • Scelta operativa: per applicare i criteri per le password e le restrizioni degli account on-prem riducendo al minimo i server, implementare PTA e Seamless SSO e abilitare anche PHS per la resilienza/failover di scenari non dipendenti da PTA. La sola federazione aumenta la complessità e non soddisfa l’obiettivo di “ridurre al minimo i server”.
• Autenticazione di app in Azure SQL da dispositivi Windows aggiunti in modalità ibrida
  • Usare l’autenticazione integrata di Active Directory per ridurre al minimo le richieste di credenziali e sfruttare Kerberos/SSO dove applicabile.
• Identità gestite e principali di servizio
  • Le identità gestite (assegnate dal sistema o dall’utente) sono la prima scelta per i workload ospitati in Azure perché eliminano i segreti e ruotano le credenziali automaticamente. Assegnare il ruolo RBAC con privilegi minimi all’identità a livello di risorsa (resource scope).
  • I principali di servizio supportano le registrazioni di app; usare credenziali basate su certificati invece dei segreti client e impostare la durata più breve possibile.
• Federazione delle identità di workload
  • Usare la federazione OIDC per consentire a identità di workload esterne (es. GitHub Actions, Kubernetes) di ottenere token per le app Entra senza archiviare segreti. Definire con precisione le attestazioni (claim) di issuer, subject e audience per limitare chi può scambiare i token.

az ad app federated-credential create \
  --id <app-object-id> \
  --parameters '{
    "name":"gh-actions-main",
    "issuer":"https://token.actions.githubusercontent.com",
    "subject":"repo:contoso/api:environment:prod",
    "audiences":["api://AzureADTokenExchange"]
  }'

• Accesso da AKS ad ACR
  • Concedere all’identità gestita del cluster AKS il ruolo AcrPull sul registro di destinazione usando il flusso attach-acr, che automatizza la definizione dell’ambito corretto ed evita assegnazioni errate.

az aks update -n aks-prod -g rg-aks --attach-acr myRegistry

• Ragionamento operativo
  • La combinazione PTA+PHS+Seamless SSO applica i controlli on-prem in tempo reale mantenendo la resilienza del cloud. Le identità gestite e la federazione rimuovono i segreti statici dalle pipeline e dal runtime, chiudendo le vie più comuni per il furto di credenziali.

Collaborazione Esterna, Metodi di Autenticazione e Accesso alle App

• Identità esterne e collaborazione B2B
  • Utilizzare account guest B2B con impostazioni di accesso cross-tenant, termini di utilizzo e CA mirate agli utenti guest. Limitare chi può invitare e preferire l’accesso just-in-time tramite la gestione dei diritti.
• Gestione dei diritti e pacchetti di accesso
  • Raggruppare gruppi, app e siti SharePoint in pacchetti di accesso con policy che definiscono chi può richiederli (inclusi gli utenti esterni), flussi di approvazione, durate delle assegnazioni e revisioni degli accessi. Per la selezione dei revisori, utilizzare i Group Owners per mantenere la responsabilità di business sui custodi delle risorse.
• Metodi di autenticazione e passwordless
  • Standardizzare su metodi forti: chiavi di sicurezza FIDO2, Windows Hello for Business e accesso tramite telefono con Microsoft Authenticator. Utilizzare la registrazione combinata delle informazioni di sicurezza (SSPR + MFA) e imporre la policy di registrazione MFA per tutti gli utenti. Abilitare SSPR con writeback on-premise se necessario; richiedere metodi sicuri e limitare, ove possibile, a fattori gestiti dall’azienda. Disabilitare i protocolli di autenticazione legacy/di base e bloccare l’MFA debole basata solo su SMS dove il rischio lo giustifica.
• Microsoft Entra application proxy
  • Pubblicare applicazioni web on-premise senza aprire porte firewall in ingresso. Utilizzare gruppi di connettori per l’HA, pre-autenticazione con Entra ID e applicare CA, conformità dei dispositivi e Identity Protection per un approccio zero trust sulle app legacy.
• Sicurezza della registrazione delle applicazioni
  • Richiedere flussi di lavoro per il consenso dell’amministratore; limitare chi può creare app; classificare le autorizzazioni; preferire le autorizzazioni dell’applicazione solo quando non è richiesto un contesto utente e definire l’ambito delle API al minimo indispensabile. Disabilitare l’implicit grant ove possibile, richiedere l’assegnazione per le app enterprise e preferire i certificati ai segreti con rotazione automatizzata.

az ad app update --id <app-id> --required-resource-access @permissions.json
az ad sp update --id <sp-id> --set appRoleAssignmentRequired=true

• Ragionamento operativo
  • I pacchetti di accesso e l’app proxy forniscono un accesso esterno governato e verificabile. I metodi di autenticazione forti e passwordless aumentano la resistenza al phishing. Controlli rigorosi sulla registrazione delle app prevengono consensi eccessivamente ampi e riducono la possibilità di impersonificazione delle app.

Scenario di Problema Pratico

Adobe Inc. deve concedere a un fornitore di terze parti un accesso amministrativo temporaneo a un sottoinsieme di risorse Azure e pubblicare un’app web legacy interna per il fornitore, imponendo un’autenticazione forte e il principio di zero privilegi permanenti.

1. Definire l’ambito e modellare l’accesso

• Creare un gruppo di risorse rg-vendor-ops e spostarvi solo le risorse necessarie. Assegnare i ruoli RBAC di Azure minimi (es. Contributor su rg-vendor-ops; Reader su un gruppo di risorse di diagnostica).
• Razionale: Un ambito ristretto previene i movimenti laterali. L’ereditarietà dei ruoli è confinata a rg-vendor-ops, contenendo il raggio d’impatto (blast radius).

2. Governare l’identità e l’attivazione con PIM

• Rendere gli amministratori del fornitore idonei (eligible), non permanenti, per i ruoli richiesti; richiedere approvazione, ID del ticket, MFA all’attivazione e limitare l’attivazione a 4 ore. Iniziare eseguendo la funzione “Discover privileged roles” di PIM per definire una baseline delle assegnazioni esistenti.
• Razionale: Le assegnazioni idonee eliminano i privilegi permanenti. L’approvazione e l’MFA impongono un accesso JIT allineato alle finestre di supporto e forniscono un controllo verificabile.

3. Applicare l’Accesso Condizionale e le policy di rischio

• Creare una policy di CA mirata al gruppo del fornitore e al portale di Azure e alle API ARM, richiedendo MFA, dispositivo conforme/hybrid-joined e bloccando l’accesso da posizioni rischiose. Abilitare prima la modalità solo report (report-only); poi applicarla. Configurare Identity Protection: bloccare il rischio utente Alto (credenziali trapelate) fino al reset della password; richiedere MFA per il rischio di accesso Medio (IP sospetto).
• Razionale: La CA lega l’accesso alla fiducia del dispositivo e al rischio in tempo reale. La modalità solo report previene interruzioni durante il rollout. Le policy di rischio risolvono automaticamente le sessioni e gli account compromessi.

4. Pubblicare l’app legacy con Microsoft Entra application proxy

• Distribuire due connettori in subnet separate esposte al fornitore per l’HA. Configurare la pre-autenticazione con Entra ID, richiedere l’assegnazione all’app enterprise e applicare la stessa policy di CA. Utilizzare i pacchetti di accesso per concedere agli utenti del fornitore un accesso a tempo determinato sia all’app enterprise che ai ruoli del RG; impostare i Group Owners come revisori.
• Razionale: L’App proxy elimina l’esposizione in ingresso e centralizza l’autenticazione. La gestione dei diritti standardizza l’onboarding/offboarding e garantisce revisioni periodiche da parte dei proprietari delle risorse.

5. Mettere in sicurezza i workload e le credenziali delle app

• Sostituire eventuali client secret con credenziali basate su certificati per i service principal; per il CI/CD, utilizzare la workload identity federation invece di archiviare segreti. Per i workload AKS che necessitano di immagini, collegare l’ACR al cluster per concedere il ruolo AcrPull all’identità gestita.
• Razionale: La rimozione di segreti statici chiude un vettore di violazione comune; la federazione e le identità gestite forniscono un accesso con privilegi minimi e a rotazione automatica.

6. Proteggere gli account di emergenza (break-glass) e monitorare

• Escludere due account di emergenza (break-glass) dalla CA, ma proteggerli con password lunghe e casuali conservate offline. Abilitare le revisioni degli accessi trimestralmente ed esportare i log di PIM e CA in un workspace di Log Analytics con avvisi su attivazioni anomale.
• Razionale: L’account di emergenza previene il blocco del tenant pur essendo operativamente sicuro. Il monitoraggio continuo rileva rapidamente gli abusi, mantenendo la conformità e la prontezza nella risposta agli incidenti.

Tutti i domini · Architettura della sicurezza di rete →

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

Sfoglia Microsoft →