Identità gestite assegnate dal sistema e dall'utente in Azure: quale scegliere?

By Mirko Peters · 2026-10-26

Confronta le identità gestite di Azure assegnate dal sistema e quelle assegnate dall'utente. Scopri quale tipo di identità scegliere per ridurre il carico amministrativo e scalare in modo sicuro.

Automatically translated with AI from the original post. Read the English original

Scegliere tra identità gestite assegnate dal sistema e assegnate dall'utente in Azure è una delle decisioni architetturali più importanti per la sicurezza del cloud e per il carico amministrativo. Mentre le identità assegnate dal sistema sono legate direttamente al ciclo di vita di una singola risorsa di Azure, quelle assegnate dall'utente funzionano come entità autonome che possono essere condivise tra più risorse, riducendo drasticamente le assegnazioni di ruolo ridondanti ed evitando colli di bottiglia dovuti ai limiti sui token negli ambienti automatizzati.

Punti chiave

• Le identità assegnate dal sistema vengono create, gestite ed eliminate automaticamente insieme alla risorsa di Azure a cui appartengono.
• Le identità assegnate dall'utente esistono in modo indipendente come risorse di Azure autonome, quindi possono essere condivise tra più macchine virtuali, app e funzioni.
• Microsoft consiglia le identità assegnate dall'utente per la maggior parte degli scenari con più risorse, così da ridurre la gestione e le assegnazioni di ruolo complesse.
• Usare identità assegnate dal sistema in ambienti di test che scalano rapidamente o che durano poco può far accumulare identità e superare i limiti di frequenza di Azure.
• Una singola risorsa di Azure può ospitare sia un'identità assegnata dal sistema per la registrazione isolata sia una o più identità assegnate dall'utente per i carichi di lavoro condivisi.

Capire le differenze fondamentali

Quando inizi a progettare applicazioni cloud sicure senza segreti o stringhe di connessione hardcoded, devi decidere come i tuoi carichi di lavoro si autenticheranno in Microsoft Entra ID. Azure offre due tipi distinti di identità gestite: assegnate dal sistema e assegnate dall'utente. Capire come funzionano internamente ti farà risparmiare innumerevoli ore di risoluzione dei problemi e di manutenzione amministrativa al tuo team di ingegneria.

Come funzionano le identità assegnate dal sistema

Un'identità gestita assegnata dal sistema si attiva direttamente all'interno di una specifica risorsa di Azure, come una macchina virtuale di Azure, un Servizio app o un'app per le funzioni. Pensala come un'entità che nasce con la risorsa e muore con essa. Quando attivi un'identità assegnata dal sistema su una macchina virtuale, Azure crea in Microsoft Entra ID un'identità che porta esattamente il nome di quella risorsa.

Il vantaggio principale di questo approccio sono la semplicità e l'accoppiamento del ciclo di vita. Poiché l'identità è legata alla risorsa, non devi preoccuparti di identità orfane che restano nella directory dopo la dismissione di una macchina virtuale. Se elimini la risorsa, Azure elimina automaticamente anche l'identità. Questo forte accoppiamento, però, crea limitazioni architetturali se più risorse hanno bisogno delle stesse autorizzazioni di accesso.

Come funzionano le identità assegnate dall'utente

Un'identità gestita assegnata dall'utente, invece, viene creata prima di tutto come risorsa di Azure autonoma. Le assegni un nome personalizzato, la gestisci in modo indipendente all'interno dei tuoi gruppi di risorse e la colleghi esplicitamente a uno o più servizi di Azure che richiedono l'accesso. Poiché non è vincolata al ciclo di vita di una singola macchina virtuale o di un singolo Servizio app, persiste anche quando tutte le risorse collegate vengono eliminate.

Questa natura autonoma cambia il modo in cui gli architetti cloud gestiscono l'accesso su larga scala. Invece di trattare l'autenticazione come una relazione uno a uno tra un singolo server e un database, le identità assegnate dall'utente consentono di costruire modelli di autenticazione molti-a-uno, in cui cluster di microservizi condividono un unico contesto di sicurezza ben governato.

Overhead amministrativo e assegnazioni di ruolo

Le differenze pratiche tra questi due tipi di identità diventano evidenti quando si gestisce il controllo degli accessi in base al ruolo (RBAC) in ambienti di grandi dimensioni. Ogni volta che concedi a un'identità l'accesso a un account di archiviazione, a un insieme di credenziali di Key Vault o a un database, devi creare un'assegnazione di ruolo di Azure.

Immagina uno scenario aziendale comune: hai quattro macchine virtuali che devono tutte leggere dati da due account di archiviazione di Azure distinti. Se ti affidi esclusivamente alle identità assegnate dal sistema, ogni singola macchina virtuale richiede una propria identità dedicata. Per concedere l'accesso, devi configurare otto assegnazioni di ruolo separate, una per ogni macchina su ogni account di archiviazione. Se passi a venti macchine virtuali, il numero di assegnazioni di ruolo cresce in modo esponenziale, creando un incubo amministrativo.

Al contrario, se queste stesse quattro macchine virtuali condividono un'unica identità gestita assegnata dall'utente, ti bastano in totale due assegnazioni di ruolo. Ottieni esattamente lo stesso controllo granulare degli accessi con una frazione dello sforzo di gestione. Quando i membri del team lasciano l'azienda o l'infrastruttura viene ricostruita, mantenere una directory pulita diventa molto più semplice.

Insidie architetturali e casi limite

Sebbene le identità assegnate dall'utente siano generalmente più efficienti, scegliere il tipo sbagliato può introdurre attriti operativi nascosti. Un pericolo rilevante riguarda le risorse di calcolo di breve durata o gli ambienti con scalabilità automatica.

Se durante la giornata crei e rimuovi rapidamente ambienti di sviluppo, test o containerizzati usando identità assegnate dal sistema, tali identità si accumulano in Microsoft Entra ID prima che le routine di pulizia vengano eseguite. Alla fine, le organizzazioni possono raggiungere i limiti di frequenza delle richieste della directory di Azure, con la conseguenza che la piattaforma rifiuta del tutto le nuove richieste di creazione di risorse. Condividere un'identità assegnata dall'utente tra questi carichi di lavoro effimeri evita completamente questa trappola.

Viceversa, le identità assegnate dal sistema danno il meglio di sé in due scenari specifici:

• Audit e non ripudio: se i log di sicurezza devono dimostrare in modo inequivocabile quale esatta macchina virtuale ha eseguito una determinata azione, le identità assegnate dal sistema garantiscono questa attribuzione a livello di singola risorsa, perché ogni risorsa mantiene un proprio oggetto directory univoco.
• Pulizia rigorosa del ciclo di vita: se i requisiti di conformità stabiliscono che tutte le autorizzazioni di accesso debbano scomparire nell'istante esatto in cui una risorsa viene terminata, le identità assegnate dal sistema gestiscono tutto questo automaticamente, senza alcun intervento manuale.

Tieni presente che non sei obbligato a una scelta binaria assoluta. Una singola risorsa di Azure può avere sia un'identità assegnata dal sistema per operazioni private e sensibili, sia una o più identità assegnate dall'utente per flussi di lavoro aziendali condivisi.

Conclusione

Gestire l'identità nel cloud Microsoft richiede di bilanciare efficienza operativa e rigidi confini di sicurezza. Comprendendo le differenze operative tra identità assegnate dal sistema e identità assegnate dall'utente, puoi progettare architetture solide e scalabili che eliminano i segreti hardcoded senza appesantire inutilmente l'amministrazione.

Per approfondire come vengono emessi i token, come Azure Key Vault si integra senza password e quali insidie di sicurezza evitare comuni, non perdere la possibilità di ascoltare l'episodio completo del podcast, con approfondimenti di esperti e strategie pratiche.

Domande frequenti

Una singola risorsa di Azure può usare contemporaneamente identità gestite assegnate dal sistema e identità gestite assegnate dall'utente?

Sì. Una risorsa di Azure come una macchina virtuale o un'app del servizio app può avere abilitata contemporaneamente un'identità assegnata dal sistema e una o più identità assegnate dall'utente, così da combinare strategie di autenticazione dedicate e condivise.

Che cosa succede a un'identità assegnata dall'utente quando la risorsa di Azure a cui è collegata viene eliminata?

A differenza delle identità assegnate dal sistema, che vengono eliminate automaticamente quando la risorsa padre viene rimossa, le identità assegnate dall'utente persistono come oggetti autonomi indipendenti in Azure finché un amministratore non le elimina esplicitamente.

Perché Microsoft consiglia le identità assegnate dall'utente per la maggior parte degli scenari con più risorse?

Microsoft consiglia le identità assegnate dall'utente principalmente per ridurre l'overhead amministrativo e la proliferazione delle assegnazioni di ruolo. Condividere un'unica identità tra più risorse di calcolo riduce drasticamente il numero di assegnazioni RBAC da creare e gestire.

Le identità gestite comportano costi di esecuzione in Azure?

No, sia le identità gestite assegnate dal sistema sia quelle assegnate dall'utente sono funzionalità gratuite incluse in Microsoft Entra ID per le risorse di Azure, anche se possono essere applicati i costi standard dei servizi di calcolo o di archiviazione a cui accedi.