Identità gestite e registrazioni delle app in Azure: differenze chiave e procedure consigliate

By Mirko Peters · 2026-04-28

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

Se in questi giorni stai creando o proteggendo qualcosa di importante in Azure, capire a fondo le identità gestite e le registrazioni delle app è un requisito imprescindibile. Entrambe hanno un ruolo fondamentale nella gestione delle identità e degli accessi per le tue app, le automazioni e i servizi. Ma se confondi quale modello va usato in quale situazione, ti ritroverai con problemi inutili, falle di sicurezza o una gestione dei segreti decisamente eccessiva.

Questa guida spiega cosa sono le identità gestite e le registrazioni delle app, come si integrano con Entra ID (ex Azure AD) e perché scegliere l'approccio giusto è importante per la postura di sicurezza e per le attività quotidiane. Troverai definizioni essenziali, scenari pratici, consigli per migrare eliminando i segreti e suggerimenti concreti per la risoluzione dei problemi e la governance. L'obiettivo è aiutarti a gestire un ambiente cloud Microsoft più solido, più sicuro e più efficiente, soprattutto ora che gli attacchi aumentano e le procedure consigliate per Entra ID cambiano.

Capire identità gestite e registrazioni delle app

Partiamo chiarendo cosa fanno davvero le identità gestite e le registrazioni delle app in Azure e in Entra ID. Entrambe permettono ad attori non umani, come app, script o automazioni, di autenticarsi e accedere alle risorse nel cloud Microsoft. Ma il modo in cui lo fanno e i problemi quotidiani che risolvono (o che possono causare) sono piuttosto diversi.

Le identità gestite sono la risposta di Azure all'autenticazione senza segreti. Invece di gestire password e certificati delle app, puoi assegnare a una risorsa Azure (per esempio una macchina virtuale, un'app del servizio app o un'app per la logica) una propria identità in Entra ID. Questa identità è gestita automaticamente da Azure: viene creata quando crei la risorsa, viene eliminata se elimini la risorsa e, cosa più importante, non ti espone mai allo scambio di segreti tradizionali. Esistono due tipi di identità gestite: quelle assegnate dal sistema (una per risorsa, con accesso molto limitato) e quelle assegnate dall'utente (riutilizzabili su più risorse).

Le registrazioni delle app rappresentano l'approccio classico. Registrare un'app in Entra ID crea un oggetto applicazione e ti fornisce un ID client, con segreti o certificati facoltativi per l'autenticazione. Se la tua app deve accedere ai servizi Microsoft, usare l'API Graph o funzionare al di fuori di Azure (oppure su più di una risorsa), probabilmente userai una registrazione dell'app. Però ne sei responsabile: devi gestire i suoi segreti, la sicurezza e il ciclo di vita, e questo comporta alcuni compromessi.

Scegliere lo strumento giusto non è solo una decisione tecnica. È un calcolo del rischio: i segreti sono bersagli molto appetibili per gli attaccanti, mentre le identità gestite, che non usano segreti, eliminano intere classi di vulnerabilità. Per capire perché questo è importante, leggi questo approfondimento sull'abuso del consenso OAuth in Entra ID. Gli attaccanti sanno come restare nell'ambiente quando le basi non sono curate, quindi il primo passo è impostare correttamente l'identità.

Differenze principali: ciclo di vita, sicurezza e integrazione con Azure

Qui la teoria incontra la pratica. Sia le identità gestite sia le registrazioni delle app assegnano ad app o script i loro "cartellini identificativi" digitali, che permettono di accedere alle risorse. Però il modo in cui si ottiene quel cartellino, come lo si gestisce e come lo si elimina cambia parecchio.

Le identità gestite sono il massimo del "configura e dimentica" nel cloud. Crei una risorsa Azure, richiedi un'identità gestita e hai finito: Azure crea l'identità per te, la collega a Entra ID e mantiene sincronizzato il back-end. Se elimini la risorsa, anche l'identità scompare. Non c'è alcuna gestione dei segreti, nessuna rotazione delle password, e i team di sicurezza dormono più tranquilli.

Le registrazioni delle app richiedono molto più lavoro. Devi creare manualmente la registrazione dell'app in Entra ID, tenere traccia del suo ID client e generare segreti o certificati per l'autenticazione. Col tempo i segreti scadono (o possono essere divulgati), e spetta a te verificare quali app li usano. Ruotare i segreti, monitorare le credenziali in scadenza ed eliminare le registrazioni orfane è un lavoro a sé stante, ed è il motivo per cui i team di sicurezza chiedono sempre l'automazione del ciclo di vita.

Quando si parla di sicurezza, il contrasto è netto: le identità gestite usano un'autenticazione senza segreti legata alle risorse di Azure, mentre le registrazioni di app si affidano a segreti statici o certificati. Per questo le identità gestite sono preferibili ovunque i segreti rappresentino un rischio, o dove l'automazione è la priorità.

Questi contrasti nel ciclo di vita e nella sicurezza hanno implicazioni importanti per automazione, conformità e per il mantenimento di ambienti cloud sotto controllo. Se vuoi capire come criteri di governance e controlli incidono sulla proliferazione delle identità e sulla deriva della sicurezza, dai un'occhiata a questa guida sulla strategia di governance di Azure: è una lettura obbligata per chiunque sia responsabile di ambienti Azure grandi e in crescita.

Entità di servizio, ruoli RBAC e autorizzazioni di Microsoft Graph

Ora scostiamo un po' il sipario. In background, sia le identità gestite sia le registrazioni di app utilizzano entità di servizio in Entra ID. Pensa all'entità di servizio come all'identità reale e operativa che Entra ID conosce: che provenga da un'identità gestita o da una registrazione di app, è questo oggetto a ricevere autorizzazioni e accessi nel tuo tenant.

Per le registrazioni di app, quando aggiungi una nuova app, Entra crea un'entità di servizio corrispondente per ogni tenant a cui la assegni. È l'identità che userai per assegnare ruoli RBAC di Azure, come Collaboratore o Lettore, e per concedere autorizzazioni API di Graph, delegate o a livello di applicazione.

Le identità gestite sono leggermente diverse, ma si basano sulle stesse fondamenta. Abilitare un'identità gestita per una risorsa di Azure indica a Entra di creare un'entità di servizio dedicata, che vive e muore insieme alla risorsa. Poi assegni i ruoli RBAC (come Lettore di Key Vault) direttamente a questa identità, e la risorsa ottiene l'accesso tramite token in background: nessuna modifica al codice, nessun segreto in circolazione.

Concedere le autorizzazioni è il momento della verità. Entrambi i modelli usano l'RBAC di Azure per l'accesso a livello di risorsa, ma il modo in cui si concedono le autorizzazioni di Graph è diverso. Le registrazioni di app consentono di approvare l'accesso alle API di Graph tramite consenso esplicito o approvazione dell'amministratore; alle identità gestite si possono assegnare autorizzazioni di applicazione per Graph senza accesso interattivo, il che le rende perfette per l'automazione che deve recuperare dati utente, verificare la sicurezza o avviare flussi di lavoro.

Assegnare l'accesso e monitorare la conformità di queste identità, però, non è esattamente un'operazione del tipo "configura e dimentica". Un'assegnazione accurata dei ruoli RBAC, verifiche periodiche e strumenti come Microsoft Defender for Cloud ti aiutano a tenere sotto controllo chi fa cosa, a individuare configurazioni errate e a ridurre al minimo la deriva. Vuoi approfondire la governance delle identità? Non perdere questa guida sulla governance enterprise di Azure oppure questo approfondimento sul monitoraggio della conformità in Microsoft Defender for Cloud, con consigli pratici per una sicurezza continua.

Scegliere il modello giusto: scenari, migrazione e governance

Tutto questo contesto è importante, ma ciò che la maggior parte dei team vuole sapere davvero è questo: quando usare identità gestite e quando registrazioni di app? E come migrare o governare queste identità perché le cose non vadano storte man mano che si scala?

Le identità gestite danno il meglio con i carichi di lavoro che girano direttamente in Azure e che hanno bisogno di accedere solo all'interno dello stesso tenant: pensa alle VM che eseguono script, alle App Service che comunicano con Key Vault o alle app per la logica che interrogano Microsoft Graph. La sicurezza è migliore, la configurazione è più rapida e c'è meno gestione dei segreti da fare. Ma se hai SaaS, soluzioni multi-tenant o configurazioni ibride (per esempio app locali che comunicano con API cloud), le registrazioni di app restano la scelta standard grazie alla loro flessibilità e a una compatibilità più ampia.

La migrazione dalle registrazioni di app alle identità gestite è un tema molto dibattuto. Il processo inizia con una valutazione di prontezza: quali carichi di lavoro possono effettivamente passare al nuovo modello e quali dipendenze o limitazioni esistono? Per le applicazioni già basate su registrazioni di app, conviene procedere per fasi, testare a fondo e prevedere piani di ripristino per evitare interruzioni o sorprese nell'autenticazione.

Gli ambienti ibridi e multi-cloud richiedono un po' di creatività. A volte devi usare entrambi i modelli insieme: si parla di identità ibrida. Il trucco è ridurre al minimo i segreti, limitare le autorizzazioni e documentare con chiarezza quale identità fa cosa. E sì, gli audit periodici sono indispensabili per individuare identità obsolete o orfane che creano rischi nascosti.

Criteri di governance solidi tengono insieme l'intera strategia. Usare Azure Policy, Privileged Identity Management e controlli di conformità periodici ti permette di applicare il principio del privilegio minimo, individuare le deviazioni e allinearti al modello zero trust. Per un confronto con la realtà su account di servizio e vere identità dei carichi di lavoro (e sul motivo per cui gli approcci tradizionali non bastano), leggi questa analisi sul rischio legato alle identità non umane e alle Microsoft Entra Workload Identities. Cerchi una panoramica completa sui fondamenti della governance? La risorsa sulla strategia di governance aziendale raccoglie numerose best practice.