Raccomandazioni sulle procedure consigliate per le identità gestite
Le identità gestite in Azure offrono un modo sicuro e pratico per gestire le credenziali per le applicazioni in esecuzione nelle risorse di Azure. Questo articolo illustra le procedure consigliate per la scelta tra identità gestite assegnate dall'utente e assegnate dal sistema, consentendo di ottimizzare la gestione delle identità e ridurre il sovraccarico amministrativo.
Scelta delle identità gestite assegnate dal sistema o dall'utente
Le identità gestite assegnate dall'utente sono più efficienti in una gamma più ampia di scenari rispetto alle identità gestite assegnate dal sistema. Consultare la tabella seguente per alcuni scenari possibili e le raccomandazioni per l'assegnazione all'utente o al sistema.
Le identità assegnate dall'utente possono essere usate da più risorse e i relativi cicli di vita vengono separati dai cicli di vita delle risorse a cui sono associati. Leggere le risorse che supportano le identità gestite.
Questo ciclo di vita consente di separare le responsabilità di creazione delle risorse e di amministrazione delle identità. Le identità assegnate dall'utente e le relative assegnazioni di ruolo possono essere configurate in anticipo delle risorse che le richiedono. Gli utenti che creano le risorse richiedono solo l'accesso per assegnare un'identità assegnata dall'utente, senza la necessità di creare nuove identità o assegnazioni di ruolo.
Man mano che le identità assegnate dal sistema vengono create ed eliminate insieme alla risorsa, le assegnazioni di ruolo non possono essere create in anticipo. Questa sequenza può causare errori durante la distribuzione dell'infrastruttura se l'utente che crea la risorsa non ha accesso anche per creare assegnazioni di ruolo.
Se l'infrastruttura richiede che più risorse richiedano l'accesso alle stesse risorse, è possibile assegnarle una singola identità assegnata dall'utente. L'overhead di amministrazione viene ridotto, poiché sono presenti meno identità distinte e assegnazioni di ruolo da gestire.
Se è necessario che ogni risorsa abbia una propria identità o che disponga di risorse che richiedono un set univoco di autorizzazioni e si vuole eliminare l'identità quando la risorsa viene eliminata, è necessario usare un'identità assegnata dal sistema.
| Scenario | Raccomandazione | Note |
|---|---|---|
| Creazione rapida di risorse (ad esempio, calcolo temporaneo) con identità gestite | Identità assegnata dall'utente | Se si tenta di creare più identità gestite in un breve intervallo di tempo, ad esempio la distribuzione di più macchine virtuali ognuna con la propria identità assegnata dal sistema, è possibile superare il limite di frequenza per le creazioni di oggetti Microsoft Entra e la richiesta ha esito negativo con un errore HTTP 429. Se le risorse vengono create o eliminate rapidamente, è anche possibile superare il limite per il numero di risorse in Microsoft Entra ID se si usano identità assegnate dal sistema. Anche se un'identità assegnata dal sistema eliminata non è più accessibile da alcuna risorsa, viene conteggiata ai fini del limite fino a quando non viene completamente eliminata dopo 30 giorni. La distribuzione delle risorse associate a un'identità assegnata a un utente richiede la creazione di un solo Service Principal in Microsoft Entra ID, evitando il superamento dei limiti di frequenza. L'uso di una singola identità creata in anticipo riduce il rischio di ritardi di replica che possono verificarsi se vengono create più risorse ognuna con la propria identità. Altre informazioni sui limiti del servizio di sottoscrizione di Azure. |
| Risorse/applicazioni replicate | Identità assegnata dall'utente | Le risorse che eseguono la stessa attività, ad esempio server Web duplicati o funzionalità identiche in esecuzione in un servizio app e in un'applicazione in una macchina virtuale, richiedono in genere le stesse autorizzazioni. Usando la stessa identità assegnata dall'utente, sono necessarie meno assegnazioni di ruolo che riducono il sovraccarico di gestione. Le risorse non devono essere dello stesso tipo. |
| Conformità | Identità assegnata dall'utente | Se l'organizzazione richiede che tutta la creazione di identità debba eseguire un processo di approvazione, l'uso di una singola identità assegnata dall'utente tra più risorse richiede meno approvazioni rispetto alle identità assegnate dal sistema, che vengono create man mano che vengono create nuove risorse. |
| Accesso necessario prima della distribuzione di una risorsa | Identità assegnata dall'utente | Alcune risorse possono richiedere l'accesso a determinate risorse di Azure come parte della distribuzione. In questo caso, è possibile che non venga creata un'identità assegnata dal sistema in tempo in modo che venga usata un'identità assegnata dall'utente preesistente. |
| Registrazione di controllo | Identità assegnata dal sistema | Se è necessario registrare quale risorsa specifica ha eseguito un'azione, anziché quale identità, usare un'identità assegnata dal sistema. |
| Gestione del ciclo di vita delle autorizzazioni | Identità assegnata dal sistema | Se è necessario rimuovere le autorizzazioni per una risorsa insieme alla risorsa, usare un'identità assegnata dal sistema. |
Uso delle identità assegnate dall'utente per ridurre l'amministrazione
I diagrammi illustrano la differenza tra identità assegnate dal sistema e assegnate dall'utente, se usate per consentire a diverse macchine virtuali di accedere a due account di archiviazione.
Il diagramma mostra quattro macchine virtuali con identità assegnate dal sistema. Ogni macchina virtuale ha le stesse assegnazioni di ruolo che le concedono l'accesso a due account di archiviazione.
Quando un'identità assegnata dall'utente è associata alle quattro macchine virtuali, sono necessarie solo due assegnazioni di ruolo, rispetto a otto con identità assegnate dal sistema. Se l'identità delle macchine virtuali richiede più assegnazioni di ruolo, vengono concesse a tutte le risorse associate a questa identità.
I gruppi di sicurezza possono essere usati anche per ridurre il numero di assegnazioni di ruolo necessarie. Questo diagramma mostra quattro macchine virtuali con identità assegnate dal sistema, aggiunte a un gruppo di sicurezza, con le assegnazioni di ruolo aggiunte al gruppo anziché le identità assegnate dal sistema. Anche se il risultato è simile, questa configurazione non offre le stesse capacità del modello di Resource Manager che si hanno con le identità assegnate dall'utente.
Più identità gestite
Le risorse che supportano le identità gestite possono avere sia un'identità assegnata dal sistema che una o più identità assegnate dall'utente.
Questo modello offre la flessibilità necessaria per usare un'identità assegnata dall'utente condivisa e applicare autorizzazioni granulari quando necessario.
Nell'esempio seguente, "Macchina virtuale 3" e "Macchina virtuale 4" possono accedere sia agli account di archiviazione che ai Key Vault, a seconda dell'identità assegnata dall'utente usata durante l'autenticazione.
Nell'esempio seguente, "Macchina virtuale 4" ha un'identità assegnata dall'utente, che le consente l'accesso sia agli account di archiviazione che ai key vault, a seconda dell'identità usata durante l'autenticazione. Le assegnazioni di ruolo per l'identità assegnata dal sistema sono specifiche della macchina virtuale.
Limiti
Visualizzare i limiti per le identità gestite e per le assegnazioni di ruolo e ruoli personalizzati.
Seguire il principio dei privilegi minimi quando si concede l'accesso
Quando si concede un'identità, inclusa un'identità gestita, le autorizzazioni per accedere ai servizi, concedere sempre le autorizzazioni meno necessarie per eseguire le azioni desiderate. Ad esempio, se viene usata un'identità gestita per leggere i dati da un account di archiviazione, non è necessario consentire a tale identità di scrivere anche i dati nell'account di archiviazione. Concedere autorizzazioni aggiuntive, come ad esempio rendere l'identità gestita un contributore in una sottoscrizione di Azure quando non necessario, amplia la superficie di attacco associata all'identità. È sempre necessario ridurre al minimo il raggio dell'esplosione di sicurezza in modo che la compromissione dell'identità causi danni minimi.
Prendere in considerazione l'effetto dell'assegnazione di identità gestite alle risorse di Azure e/o della concessione di autorizzazioni a un utente
È importante notare che quando a una risorsa di Azure, ad esempio un'app per la logica di Azure o una macchina virtuale, viene assegnata un'identità gestita, tutte le autorizzazioni concesse all'identità gestita sono ora disponibili per la risorsa di Azure. Questo è importante perché se un utente ha accesso per installare o eseguire codice in questa risorsa, l'utente ha accesso a tutte le identità assegnate/associate alla risorsa di Azure. Lo scopo dell'identità gestita è fornire al codice in esecuzione su una risorsa di Azure l'accesso ad altre risorse, senza che gli sviluppatori debbano gestire o inserire le credenziali direttamente nel codice per ottenere tale accesso.
Ad esempio, se a un'identità gestita (ClientId = 1234) viene concesso l'accesso in lettura/scrittura a StorageAccount7755 e viene assegnato a LogicApp3388, quindi Alice, chi non ha accesso diretto all'account di archiviazione ma ha l'autorizzazione per eseguire codice all'interno di LogicApp3388 può anche leggere/scrivere dati da e verso StorageAccount7755 eseguendo il codice che usa l'identità gestita.
Analogamente, se Alice ha le autorizzazioni per assegnare l'identità gestita stessa, può assegnarla a una risorsa di Azure diversa e avere accesso a tutte le autorizzazioni disponibili per l'identità gestita.
In generale, quando si concede a un utente l'accesso amministrativo a una risorsa che può eseguire codice (ad esempio un'app per la logica) e ha un'identità gestita, valutare se il ruolo assegnato all'utente può installare o eseguire codice nella risorsa e, se sì, assegnare tale ruolo solo se l'utente lo necessita effettivamente.
Manutenzione
Le identità assegnate dal sistema vengono eliminate automaticamente quando la risorsa viene eliminata, mentre il ciclo di vita di un'identità assegnata dall'utente è indipendente da qualsiasi risorsa a cui è associata.
È necessario eliminare manualmente un'identità assegnata dall'utente quando non è più necessaria, anche se non sono associate risorse.
Le assegnazioni di ruolo non vengono eliminate automaticamente quando vengono eliminate identità gestite assegnate dal sistema o assegnate dall'utente. Queste assegnazioni di ruolo devono essere eliminate manualmente in modo che il limite di assegnazioni di ruolo per ogni sottoscrizione non venga superato.
Le assegnazioni di ruolo associate alle identità gestite eliminate vengono visualizzate con "Identità non trovata" quando vengono visualizzate nel portale. Altre informazioni.
Le assegnazioni di ruolo che non sono più associate a un utente o a un'entità servizio vengono mostrate con un valore ObjectType pari a Unknown. Per rimuoverli, è possibile utilizzare una pipeline di diversi comandi di Azure PowerShell per ottenere innanzitutto tutte le assegnazioni di ruolo, filtrare solo quelle che hanno un valore di ObjectType, e poi rimuovere tali assegnazioni di ruolo da Azure.
Get-AzRoleAssignment | Where-Object {$_.ObjectType -eq "Unknown"} | Remove-AzRoleAssignment
Limitazione dell'uso di identità gestite per l'autorizzazione
L'uso dei gruppi ID Entra di Microsoft per concedere l'accesso ai servizi è un ottimo modo per semplificare il processo di autorizzazione. L'idea è semplice: concedere le autorizzazioni a un gruppo e aggiungere identità al gruppo in modo che ereditino le stesse autorizzazioni. Si tratta di un modello ben consolidato di vari sistemi locali e funziona bene quando le identità rappresentano gli utenti. Un'altra opzione per controllare l'autorizzazione in Microsoft Entra ID consiste nell'usare i Ruoli delle app, che consentono di dichiarare ruoli specifici a un'app (anziché gruppi, che sono un concetto globale nella directory). È quindi possibile assegnare ruoli dell'app a identità gestite (nonché utenti o gruppi).
In entrambi i casi, per le identità non umane, ad esempio Le applicazioni Microsoft Entra e le identità gestite, il meccanismo esatto di come queste informazioni di autorizzazione vengono presentate all'applicazione non è ideale oggi. L'implementazione odierna con Microsoft Entra ID e Azure Role Based Access Control (Controllo degli accessi basato sui ruoli di Azure) utilizza i token di accesso rilasciati da Microsoft Entra ID per l'autenticazione di ogni identità. Se l'identità viene aggiunta a un gruppo o a un ruolo, questa viene espressa come attestazioni nel token di accesso rilasciato da Microsoft Entra ID. Azure RBAC utilizza queste attestazioni per valutare ulteriormente le regole di autorizzazione per negare o consentire l'accesso.
Dato che i gruppi e i ruoli dell'identità sono attestazioni nel token di accesso, tutte le modifiche all'autorizzazione non diventano effettive finché il token non viene aggiornato. Per un utente umano questo in genere non è un problema, perché può acquisire un nuovo token di accesso disconnettendosi e accedendo di nuovo (o aspettando che la durata del token scada, ovvero 1 ora per impostazione predefinita). I token di identità gestiti vengono invece memorizzati nella cache dall'infrastruttura di Azure sottostante a scopo di prestazioni e resilienza: i servizi back-end per le identità gestite mantengono una cache per ogni URI di risorsa per circa 24 ore. Ciò significa che possono essere necessarie diverse ore per rendere effettive le modifiche apportate al gruppo o all'appartenenza ai ruoli di un'identità gestita. Attualmente non è possibile forzare l'aggiornamento del token di un'identità gestita prima della scadenza. Se si modifica il gruppo o l'appartenenza a un ruolo di un'identità gestita per aggiungere o rimuovere le autorizzazioni, potrebbe quindi essere necessario attendere diverse ore prima che la risorsa di Azure usi l'identità per avere l'accesso corretto.
Se questo ritardo non è accettabile per i tuoi requisiti, prendi in considerazione le alternative all'uso di gruppi o ruoli nel token. Per garantire che le modifiche alle autorizzazioni per le identità gestite abbiano effetto rapidamente, è consigliabile raggruppare le risorse di Azure usando un'identità gestita assegnata dall'utente con autorizzazioni applicate direttamente all'identità, anziché aggiungere o rimuovere identità gestite da un gruppo di Microsoft Entra con autorizzazioni. Un'identità gestita assegnata dall'utente può essere usata come un gruppo perché può essere assegnata a una o più risorse di Azure per usarla. L'operazione di assegnazione può essere controllata usando il ruolo Contributore identità gestita e il ruolo Operatore identità gestita.