Microsoft AZ-204: Autenticazione, Autorizzazione e Sicurezza di Azure — Guida allo studio

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

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

Panoramica

L’autenticazione e l’autorizzazione in Azure si basano sulla Microsoft Identity Platform, che emette token per le identità (utenti, app, workload) e controlla l’accesso ad API e risorse. Le applicazioni si integrano tramite OAuth 2.0 e OpenID Connect, acquisiscono token usando MSAL e richiedono autorizzazioni dichiarate nelle registrazioni di app di Azure AD. I workload in esecuzione su Azure possono eliminare completamente le credenziali utilizzando le identità gestite e affidarsi ad Azure RBAC per accedere a servizi come Key Vault, Storage e Microsoft Graph. La gestione dei segreti è incentrata su Azure Key Vault, con una netta separazione tra l’accesso al piano dati del vault e il controllo del piano di gestione, e con solide garanzie di ripristino tramite l’eliminazione temporanea (soft delete) e la protezione dall’eliminazione definitiva (purge protection). Per lo storage, le Shared Access Signatures (SAS) forniscono una delega con ambito definito e limitata nel tempo ai client, senza esporre le chiavi dell’account.

Microsoft Identity Platform, OAuth 2.0, MSAL e registrazioni di app

La Microsoft Identity Platform supporta molteplici flussi OAuth 2.0 ottimizzati per diversi tipi di applicazione:

Flusso del codice di autorizzazione: Lo standard per web app, SPA e app native. I client pubblici devono usare PKCE per proteggere il codice di autorizzazione. Le app reindirizzano gli utenti all’endpoint di autorizzazione, ricevono un codice di autorizzazione sull’URI di reindirizzamento, quindi lo riscattano presso l’endpoint del token per ottenere un token di accesso (e, opzionalmente, un token di aggiornamento). Per le SPA, il flusso del codice di autorizzazione + PKCE sostituisce il flusso implicito legacy e mitiga la fuga di token.
Flusso delle credenziali client: Utilizzato da daemon e servizi server-to-server senza un utente. L’applicazione richiede i token utilizzando un’asserzione client (certificato) o un segreto client. In questo caso sono disponibili solo le autorizzazioni dell’applicazione (ruoli app), e la maggior parte di esse richiede il consenso dell’amministratore. Questo flusso utilizza l’ambito /.default per richiedere l’insieme delle autorizzazioni dell’applicazione configurate staticamente.
Flusso del codice dispositivo: Progettato per dispositivi o ambienti senza un browser integrato. L’app ottiene un codice utente e un URL di verifica dalla piattaforma di identità, l’utente si autentica su un dispositivo separato e l’app esegue il polling dell’endpoint del token. Si applicano le autorizzazioni delegate poiché un utente effettua l’accesso.
Flusso di concessione implicita: Storicamente utilizzato dalle SPA per ricevere i token direttamente dall’endpoint di autorizzazione. Ora è sconsigliato a favore del flusso del codice di autorizzazione con PKCE. Se utilizzato, è comunque necessario un URI di reindirizzamento durante la registrazione dell’app.

MSAL (Microsoft Authentication Library) fornisce un’acquisizione di token coerente tra linguaggi e piattaforme. Le applicazioni client pubbliche (desktop, mobile, SPA) usano AcquireTokenInteractive e AcquireTokenSilent per ottenere e memorizzare nella cache i token; le app native useranno anche AcquireTokenByDeviceCode per il flusso del codice dispositivo e AcquireTokenByAuthorizationCode per il riscatto del codice di autorizzazione in contesti di client confidenziali. I client confidenziali (web app/API/daemon) acquisiscono token con AcquireTokenForClient quando usano le credenziali client e AcquireTokenOnBehalfOf per scenari OBO (On-Behalf-Of) in cui un’API chiama API downstream con il contesto delegato di un utente.

Il caching dei token è parte integrante di MSAL: memorizza i token di accesso e di aggiornamento indicizzati per account, client e ambito (scope), consentendo a AcquireTokenSilent di evitare richieste interattive non necessarie. Le web app e le API in esecuzione su più istanze devono rendere persistente e proteggere la cache dei token utilizzando un archivio condiviso e crittografato (ad es. una cache distribuita con adeguata crittografia at-rest e in-transit). Gli hook di serializzazione della cache in MSAL abilitano la persistenza sicura. Gli ambiti (scope) identificano le autorizzazioni richieste da un’app. Per le autorizzazioni delegate, richiedere gli ambiti minimi e specifici della risorsa (ad es. https://graph.microsoft.com/User.Read). Per le credenziali client, richiedere l’ambito basato sulla risorsa /.default, che corrisponde alle autorizzazioni dell’applicazione concesse staticamente all’app (ad es. scope = https://graph.microsoft.com/.default). Utilizzare il consenso incrementale per richiedere gli ambiti progressivamente e semplificare l’esperienza utente.

Le registrazioni di app in Azure AD definiscono l’identità dell’applicazione, le credenziali, gli URI di reindirizzamento e le autorizzazioni. Le autorizzazioni delegate richiedono un utente che abbia effettuato l’accesso e spesso possono ricevere il consenso dagli utenti stessi per i propri dati; le autorizzazioni dell’applicazione sono concesse all’app stessa e richiedono quasi sempre il consenso di un amministratore perché si applicano a livello di tenant o in modo esteso. Le app che espongono API dichiarano gli ambiti (scope) (per le autorizzazioni delegate) e i ruoli app (per le autorizzazioni dell’applicazione) nella sezione “Expose an API”. Configurare l’accesso single-tenant o multi-tenant a seconda dei confini di attendibilità e utilizzare i certificati al posto dei segreti client per credenziali più sicure e una rotazione più semplice.

Microsoft Graph utilizza lo stesso meccanismo di emissione dei token. Autenticarsi con MSAL puntando alla risorsa Graph e richiedere gli ambiti con privilegi minimi. Gli endpoint comuni includono:

GET https://graph.microsoft.com/v1.0/me per il profilo utente con token delegati (ad es. User.Read)
GET https://graph.microsoft.com/v1.0/users e /groups per gli oggetti della directory (richiede autorizzazioni delegate o dell’applicazione appropriate come User.Read.All o Group.Read.All)
GET https://graph.microsoft.com/v1.0/sites o /drives per operazioni su SharePoint/OneDrive Quando si utilizzano le credenziali client, richiedere l’ambito /.default e assicurarsi che esista il consenso dell’amministratore per le autorizzazioni dell’applicazione richieste. Scegliere l’autorità corretta (specifica del tenant rispetto a common/organizations) per controllare dove gli utenti possono accedere e dove i token possono essere emessi.

Identità Gestite e Accesso Sicuro alle Risorse di Azure, più Riferimenti a Key Vault

Le identità gestite per le risorse di Azure eliminano i segreti consentendo ad Azure di gestire le credenziali delle entità servizio. Le identità gestite assegnate dal sistema sono legate 1:1 a una risorsa (App Service, Function App, VM, VMSS, Logic App, ecc.) e ne condividono il ciclo di vita; quando la risorsa viene eliminata, anche l’identità viene eliminata. Le identità gestite assegnate dall’utente sono create come risorse Azure autonome che possono essere associate a più risorse di calcolo ed esistere indipendentemente dal ciclo di vita di un singolo carico di lavoro. Questo modello supporta il riutilizzo dell’identità e la separazione dei compiti.

Per accedere alle risorse di Azure con un’identità gestita, assegnale il ruolo RBAC di Azure appropriato nell’ambito corretto:

Per il piano dati di Azure Storage con Azure AD, assegna ruoli come Storage Blob Data Reader/Contributor a livello di account di archiviazione, contenitore o ambito di gruppo di risorse/sottoscrizione.
Per Key Vault (modello del piano dati RBAC), assegna ruoli come Key Vault Secrets User o Key Vault Crypto Officer.
Per Microsoft Graph tramite autorizzazioni dell’applicazione, le identità gestite possono chiamare le API downstream solo dopo che è stata associata una registrazione dell’app. Utilizza la federazione delle identità del carico di lavoro o configura le autorizzazioni dell’app aziendale e il consenso dell’amministratore secondo necessità.

A runtime, utilizza l’Instance Metadata Service (IMDS) sulle VM o l’endpoint gestito da App Service per ottenere i token; gli SDK come DefaultAzureCredential di Azure Identity utilizzeranno automaticamente l’endpoint dell’identità gestita quando disponibile. Ciò elimina la necessità di archiviare segreti e supporta la rotazione da parte della piattaforma.

I riferimenti a Key Vault in App Service e Azure Functions consentono il recupero sicuro dei segreti nelle impostazioni dell’applicazione senza modifiche al codice. Nel valore di un’impostazione dell’applicazione, utilizza la sintassi di riferimento @Microsoft.KeyVault(SecretUri=https://{vault-name}.vault.azure.net/secrets/{name}/{version}). La piattaforma risolve il riferimento utilizzando l’identità gestita dell’app all’avvio e lo aggiorna periodicamente. Assicurati che l’identità gestita disponga dell’autorizzazione Get per i segreti tramite i criteri di accesso di Key Vault o il ruolo Key Vault Secrets User quando si utilizza il modello del piano dati RBAC. I riferimenti a Key Vault sono ideali per i valori di configurazione che non dovrebbero mai essere archiviati in testo semplice nell’archivio di configurazione dell’app e rimuovono la logica di gestione dei segreti dal codice dell’applicazione.

Azure Key Vault: Segreti, Chiavi, Certificati e Controllo degli Accessi

Azure Key Vault archivia tre tipi di oggetti:

Segreti: Stringhe opache come password, stringhe di connessione o chiavi API. Sono versionati; i client eseguono tipicamente operazioni Get e Set.
Chiavi: Chiavi crittografiche (RSA, EC) utilizzate per operazioni di firma/verifica, crittografia/decrittografia e wrap/unwrap. Il materiale della chiave è protetto dal servizio supportato da HSM; i client chiamano le operazioni crittografiche tramite il servizio anziché esportare il materiale della chiave privata.
Certificati: Oggetti X.509 con gestione del ciclo di vita, opzionalmente integrati con CA partner. I certificati si materializzano come un certificato più un segreto corrispondente (PFX) e, opzionalmente, una chiave gestita.

L’eliminazione temporanea (soft delete) è attiva per impostazione predefinita, conservando gli oggetti eliminati per un periodo di conservazione. Abilita la protezione dall’eliminazione definitiva (purge protection) per impedire l’eliminazione irreversibile durante il periodo di conservazione e per applicare garanzie di ripristino (spesso un requisito di conservazione di 90 giorni). Combina l’eliminazione temporanea e la protezione dall’eliminazione definitiva per soddisfare policy di ripristino rigorose. Inoltre, proteggi l’accesso di rete al vault con endpoint privati e disabilita l’accesso dalla rete pubblica ove possibile.

Il controllo degli accessi può utilizzare i criteri di accesso al vault legacy o l’RBAC di Azure per il piano dati. I criteri di accesso sono configurati per ogni vault e concedono esplicitamente autorizzazioni (Get, List, Set, Sign, Wrap) alle entità (principals); non vengono ereditati e possono diventare operativamente onerosi su larga scala. Il modello del piano dati RBAC utilizza i ruoli di Azure (ad es., Key Vault Administrator, Key Vault Secrets Officer, Key Vault Secrets User, Key Vault Crypto Officer) e supporta l’applicazione di ambiti a livello di sottoscrizione, gruppo di risorse o vault, con l’auditing integrato nell’RBAC di Azure. Scegli un modello; se l’RBAC è abilitato per il piano dati, i criteri di accesso vengono ignorati. Le operazioni del piano di gestione (creazione/aggiornamento del vault) utilizzano sempre l’RBAC di Azure.

Integra Key Vault con le applicazioni utilizzando gli SDK di Azure (ad es., SecretClient, KeyClient, CertificateClient) e DefaultAzureCredential. Preferisci le identità gestite per l’autenticazione, evita di incorporare credenziali e implementa policy di tentativi ripetuti (retry) e di limitazione del traffico (throttling) quando chiami le API del Vault.

SAS di Azure Storage e Criteri di Accesso Archiviati

Le Firme di Accesso Condiviso (Shared Access Signatures - SAS) delegano un accesso granulare e limitato nel tempo ad Azure Storage senza rivelare le chiavi dell’account:

SAS di delega utente (solo Blob): Supportata da Azure AD. L’applicazione ottiene una chiave di delega utente dal servizio Blob utilizzando le credenziali di Azure AD, quindi crea token SAS per i client. Questo è l’approccio più sicuro per scenari incentrati sull’utente perché evita l’uso delle chiavi dell’account e si allinea con l’autorizzazione basata sui ruoli.
SAS di servizio: Con ambito limitato a una risorsa specifica (blob, contenitore, messaggio di coda, entità di tabella, file). Firmata con una chiave dell’account. Supporta autorizzazioni come lettura, scrittura, aggiunta, creazione, eliminazione, elenco, impostazione dell’immutabilità e tag a seconda del servizio.
SAS dell’account: Ambito più ampio su più servizi (Blob, Queue, Table, File) e tipi di risorse. Da usare con parsimonia a causa dell’ampio raggio d’impatto.

I token SAS includono vincoli come tempo di scadenza (se), tempo di inizio (st), autorizzazioni (sp), intervalli IP (sip), protocolli consentiti (spr), risorsa firmata (sr) e, quando associati a un criterio di accesso archiviato, un identificatore firmato (si). Seguire il principio del privilegio minimo concedendo solo le autorizzazioni necessarie, mantenendo le scadenze brevi e imponendo l’uso di HTTPS (spr=https). Preferire la SAS di delega utente dove possibile; altrimenti, utilizzare una SAS di servizio con un criterio di accesso archiviato per la revoca.

I criteri di accesso archiviati risiedono su contenitori, condivisioni di file, code o tabelle e definiscono un insieme riutilizzabile di vincoli (autorizzazioni, inizio, scadenza). Quando si crea una SAS, si fa riferimento al criterio tramite il suo identificatore. Ciò consente la revoca centralizzata o la restrizione dell’ambito senza dover riemettere tutti i token SAS; l’aggiornamento o l’eliminazione del criterio influisce immediatamente su tutti i token SAS ad esso collegati. Ruotare regolarmente le chiavi dell’account se si utilizzano SAS di servizio o dell’account e monitorare l’utilizzo tramite le impostazioni di diagnostica e i log di Azure Monitor.

Scenario Pratico

Adobe sta implementando un portale multi-tenant per l’elaborazione di media su Azure. I clienti accedono con i propri tenant Microsoft Entra ID, caricano file multimediali di grandi dimensioni direttamente su Blob storage e monitorano lo stato di elaborazione. La soluzione deve evitare di archiviare segreti, centralizzare le autorizzazioni e garantire la recuperabilità dei segreti per almeno 90 giorni.

Registrare le applicazioni in Microsoft Entra ID:
- Creare una SPA per l’interfaccia utente del portale e un client riservato per l’API di backend. Esporre gli scope dell’API per l’accesso delegato e definire ruoli dell’app per i processi in background. Configurare la SPA per utilizzare il flusso con codice di autorizzazione + PKCE con URI di reindirizzamento esatti. Ciò allinea ogni client con il flusso OAuth corretto e impone limiti di consenso basati sul principio del privilegio minimo.
Implementare MSAL nella SPA e nel backend:
- La SPA acquisisce token per l’API di backend utilizzando AcquireTokenInteractive/AcquireTokenSilent con consenso incrementale. Il backend utilizza AcquireTokenOnBehalfOf per chiamare Microsoft Graph e leggere il profilo di base dell’utente che ha effettuato l’accesso. Ciò preserva il contesto dell’utente end-to-end e minimizza le richieste di autorizzazione tramite il caching dei token.
Abilitare le identità gestite assegnate dal sistema su App Service (API) e Azure Functions (processori multimediali):
- Assegnare il ruolo Storage Blob Data Contributor sul contenitore multimediale e Key Vault Secrets User sul vault. Le identità gestite eliminano la proliferazione dei segreti e consentono alla piattaforma di ruotare automaticamente le credenziali, abilitando al contempo un accesso sicuro a Storage e Key Vault tramite Azure RBAC.
Configurare Azure Key Vault con piano dati RBAC, eliminazione temporanea (soft delete) e protezione dall’eliminazione definitiva (purge protection):
- Archiviare i certificati di firma per l’asserzione del backend, le chiavi API di terze parti e qualsiasi segreto di connessione che non può essere sostituito con AAD. Imporre la protezione dall’eliminazione definitiva più l’eliminazione temporanea per garantire il recupero per 90 giorni. RBAC semplifica l’audit e si adatta a diversi ambienti rispetto ai criteri di accesso per singolo vault.
Utilizzare i riferimenti a Key Vault per la configurazione:
- Fare riferimento ai segreti nelle impostazioni delle app di App Service e Functions utilizzando @Microsoft.KeyVault(SecretUri=…). La piattaforma risolve e aggiorna i valori con l’identità gestita, eliminando modifiche al codice e impedendo che i segreti vengano archiviati nella configurazione in testo semplice.
Delegare gli upload diretti dal browser con SAS:
- Il backend emette token SAS di delega utente per un accesso di breve durata, di sola scrittura, a un percorso blob specifico, limitato per IP e HTTPS. Per gli strumenti operativi batch, creare una SAS di servizio legata a un criterio di accesso archiviato sul contenitore, in modo che i token possano essere revocati centralmente aggiornando o eliminando il criterio. Ciò consente upload ad elevato throughput da parte dei client senza esporre le chiavi dell’account e supporta la revoca di emergenza.
Integrare Microsoft Graph in modo minimale:
- Richiedere https://graph.microsoft.com/User.Read nella SPA per la visualizzazione del profilo e utilizzare https://graph.microsoft.com/.default nel backend se sono richieste autorizzazioni dell’applicazione (con previo consenso dell’amministratore). L’uso di /.default garantisce che il backend rispetti le autorizzazioni dell’applicazione concesse centralmente ed eviti di richiedere scope eccessivi in fase di esecuzione.

Questo design utilizza il flusso con codice di autorizzazione + PKCE per proteggere la SPA, OBO per preservare il contesto utente downstream, identità gestite e RBAC per eliminare i segreti, Key Vault con solide garanzie di recupero, riferimenti a Key Vault per l’igiene della configurazione, Graph con scope basati sul privilegio minimo e SAS con criteri di accesso archiviati per upload sicuri e revocabili da parte dei client.

← Soluzioni Container di Azure · Tutti i domini · Azure API Management →

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