Identità gestita per l'autenticazione senza password

Tradizionalmente, le applicazioni si connettono a servizi Azure come Storage o Key Vault utilizzando stringhe di connessione o chiavi API archiviate nei file di configurazione o nelle variabili d'ambiente. Queste credenziali possono essere accidentalmente caricate nel controllo del codice sorgente, esposte nei log o sottratte durante una violazione. L'identità gestita elimina completamente la necessità per le applicazioni di archiviare credenziali: Azure stesso emette e rinnova un token per conto della risorsa e l'applicazione si limita a richiedere ad Azure il token corrente durante l'esecuzione.

Un'identità gestita è un service principal gestito automaticamente in Microsoft Entra ID e collegato a una risorsa Azure, ad esempio una VM, un'istanza di App Service o una Function App. La piattaforma Azure crea e gestisce le credenziali dell'identità, rinnovandole regolarmente, così il codice non gestisce mai password o segreti. Le applicazioni in esecuzione sulla risorsa chiamano l'endpoint Azure Instance Metadata Service (IMDS) all'indirizzo http://169.254.169.254 per ottenere un token OAuth a breve durata, che presentano quindi ai servizi Azure.

Esistono due tipi di identità gestita: l'identità assegnata dal sistema è associata a una singola risorsa Azure; viene creata quando la si abilita nella risorsa ed eliminata automaticamente quando la risorsa viene eliminata. L'identità assegnata dall'utente è un'identità indipendente di Entra ID che si crea separatamente e si collega quindi a una o più risorse Azure. Le identità assegnate dall'utente sono utili quando più servizi, ad esempio diverse Function App, devono condividere la stessa identità e le stesse autorizzazioni RBAC, evitando la duplicazione delle assegnazioni di ruolo.

Dopo aver abilitato un'identità gestita, è necessario concederle autorizzazioni RBAC sulla risorsa Azure di destinazione. Ad esempio, per consentire a un App Service di leggere i BLOB, assegni il ruolo Storage Blob Data Reader all'identità gestita dell'App Service nell'account di archiviazione. Le assegnazioni RBAC seguono il principio del privilegio minimo: conceda solo le autorizzazioni minime necessarie. Non assegni mai il ruolo Owner o Contributor a un'identità gestita, salvo assoluta necessità.

Azure SDK offre una classe DefaultAzureCredential che prova automaticamente diversi metodi di autenticazione in un ordine prestabilito: variabili d'ambiente, identità del carico di lavoro, identità gestita, Azure CLI, Visual Studio e altri. Quando l'applicazione viene eseguita in Azure (App Service, VM, Function App), DefaultAzureCredential utilizza automaticamente l'identità gestita senza modifiche al codice. In locale, gli sviluppatori eseguono l'autenticazione tramite la propria sessione di Azure CLI. Questa singola classe di credenziali funziona in tutti gli ambienti senza logica condizionale.

Un modello comune consiste nell'utilizzare un'identità gestita per accedere in fase di esecuzione ai segreti di Azure Key Vault. Invece di archiviare la password di un database nelle impostazioni dell'applicazione, la si archivia in Key Vault e si assegna all'identità gestita dell'app il ruolo Key Vault Secrets User nell'insieme di credenziali. All'avvio, l'applicazione recupera il segreto da Key Vault utilizzando DefaultAzureCredential. Questo modello garantisce che i segreti non vengano mai archiviati nel codice, nei file di configurazione o nelle variabili d'ambiente: esistono solo in Key Vault e vengono recuperati temporaneamente.

Azure SQL Database supporta l'autenticazione Entra ID, il che significa che un'identità gestita può autenticarsi a SQL senza nome utente e password. Per abilitarla: imposti un amministratore Entra ID nel server SQL, quindi esegua un'istruzione CREATE USER nel database di destinazione per il nome visualizzato dell'identità gestita e le assegni il ruolo database appropriato. L'applicazione si connette utilizzando DefaultAzureCredential di Azure SDK e un token di accesso con ambito https://database.windows.net/, interamente senza password.

In Azure Kubernetes Service, i singoli pod possono ottenere token di identità gestita utilizzando Workload Identity, il successore di AAD Pod Identity. Si crea un'identità gestita assegnata dall'utente, la si federa con l'emittente OIDC di AKS, si annota l'account del servizio Kubernetes e il webhook Azure Workload Identity inserisce le variabili d'ambiente necessarie affinché DefaultAzureCredential del pod possa ottenere un token. Questo estende l'autenticazione senza password ai microservizi containerizzati senza archiviare segreti negli oggetti Kubernetes Secrets.

Anche se le credenziali delle identità gestite sono invisibili agli sviluppatori, tutti gli eventi di emissione dei token e di accesso alle risorse vengono registrati. I log di accesso di Entra ID registrano ogni richiesta di token effettuata da un'identità gestita, inclusi la risorsa a cui si accede, l'ora e l'esito della richiesta. I log attività di Azure Storage e i log di controllo di Key Vault registrano le operazioni specifiche eseguite utilizzando il token. Questi log sono essenziali per gli audit di sicurezza e le indagini sugli incidenti che coinvolgono le identità gestite.

Se l'applicazione utilizza attualmente stringhe di connessione o chiavi API, esegua la migrazione all'identità gestita in tre passaggi: Passaggio 1 — Abiliti un'identità gestita nella risorsa di calcolo. Passaggio 2 — Assegni all'identità i ruoli RBAC appropriati in ogni servizio di destinazione. Passaggio 3 — Aggiorni il codice dell'applicazione per utilizzare DefaultAzureCredential al posto della stringa di connessione. Dopo aver verificato la migrazione, rimuova la stringa di connessione dalla configurazione di App Service e da Key Vault. Nelle applicazioni moderne che utilizzano Azure SDK, questa migrazione può essere generalmente completata con modifiche minime al codice.

L'identità gestita offre quattro vantaggi fondamentali in termini di sicurezza rispetto all'autenticazione basata su credenziali: Nessuna credenziale archiviata — non c'è nulla da sottrarre o caricare accidentalmente. Rinnovo automatico — Azure rinnova i certificati sottostanti senza tempi di inattività. Autorizzazioni con ambito limitato — alle identità vengono assegnati solo i ruoli RBAC necessari, secondo il principio del privilegio minimo. Traccia di audit completa — tutti i tentativi di accesso vengono registrati in Entra ID e nei log di controllo del servizio a cui si accede. Per ogni nuova integrazione con un servizio Azure, l'identità gestita dovrebbe essere l'approccio di autenticazione predefinito.

Verifichi la Sua comprensione dei concetti di Microsoft Azure Fundamentals (AZ-900) trattati in questa lezione.

In questa lezione ha imparato che: l'identità gestita elimina le credenziali memorizzate assegnando alle risorse Azure un'identità Entra ID gestita automaticamente; DefaultAzureCredential nell'Azure SDK usa in modo trasparente l'identità gestita in Azure e le credenziali dello sviluppatore in locale; infine, le assegnazioni di ruolo RBAC nei servizi di destinazione controllano le risorse a cui l'identità può accedere. Ora esamineremo Azure Service Bus per la messaggistica disaccoppiata tra i componenti dell'applicazione.