Raccomandazioni sulle procedure consigliate per le identità gestite
Le identità gestite per le risorse di Azure sono una funzionalità di Microsoft Entra ID. Tutti i servizi di Azure che supportano le identità gestite per le risorse di Azure sono soggetti alla sequenza temporale di tali entità. Prima di iniziare, assicurarsi di esaminare lo stato di disponibilità delle identità gestite per la risorsa e i problemi noti.
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. Vedere la tabella seguente per alcuni scenari e le raccomandazioni per l'assegnazione dell'utente o assegnata dal 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 verrà ridotto, perché 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 | Elemento consigliato | 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 con una propria identità assegnata dal sistema, è possibile superare il limite di frequenza per le creazioni di oggetti Microsoft Entra e la richiesta avrà 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, verrà conteggiata in base al limite fino a quando non vengono eliminati completamente dopo 30 giorni. La distribuzione delle risorse associate a una singola identità assegnata dall'utente richiederà la creazione di un'unica entità servizio in Microsoft Entra ID, evitando il limite di frequenza. L'uso di una singola identità creata in anticipo ridurrà anche il rischio di ritardi di replica che potrebbero 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 nel tempo, quindi deve essere 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, verranno 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 funzionalità del modello di Resource Manager delle 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 agli insiemi di credenziali delle chiavi, a seconda dell'identità assegnata dall'utente usata durante l'autenticazione.
Nell'esempio seguente "Macchina virtuale 4" ha un'identità assegnata dall'utente, concedendole l'accesso sia agli account di archiviazione che agli insiemi di credenziali delle chiavi, 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 un'identità gestita viene usata per leggere i dati da un account di archiviazione, non è necessario consentire a tale identità di scrivere anche i dati nell'account di archiviazione. Concedendo autorizzazioni aggiuntive, ad esempio, rendendo l'identità gestita un collaboratore in una sottoscrizione di Azure quando non è necessaria, aumenta il raggio di esecuzione della sicurezza associato 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 una risorsa di Azure, ad esempio un'app per la logica di Azure, una funzione di Azure o una macchina virtuale e così via. 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) è stato concesso l'accesso in lettura/scrittura a StorageAccount7755 ed è stato assegnato a LogicApp3388, Alice, che non ha accesso diretto all'account di archiviazione, ma ha l'autorizzazione per eseguire il codice all'interno di LogicApp3388 può anche leggere/scrivere dati in/da 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.
Gestione
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 verranno visualizzate con "Identità non trovata" quando visualizzata nel portale. Altre informazioni.
Le assegnazioni di ruolo che non sono più associate a un utente o a un'entità servizio verranno visualizzate con il ObjectType valore Unknown. Per rimuoverli, è possibile inviare tramite pipe diversi comandi di Azure PowerShell per ottenere prima tutte le assegnazioni di ruolo, filtrare solo quelli con un ObjectType valore e Unknown quindi 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 Ruoli app, che consente di dichiarare ruoli specifici di 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 Controllo di accesso (Controllo degli accessi in base al ruolo di Azure) usa 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. Il controllo degli accessi in base al ruolo di Azure usa queste attestazioni per valutare ulteriormente le regole di autorizzazione per consentire o negare 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 che in genere non è un problema, perché un utente può acquisire un nuovo token di accesso disconnettendosi e 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 requisiti, prendere 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 Collaboratore identità gestita e Operatore identità gestita.