Che cosa sono i gruppi di gestione di Azure?

Articolo
04/20/2023

Se l'organizzazione conta molte sottoscrizioni di Azure, può essere necessario individuare una soluzione per gestire in modo efficiente l'accesso, i criteri e la conformità per tali sottoscrizioni. I gruppi di gestione offrono un ambito di governance superiore alle sottoscrizioni. Le sottoscrizioni sono organizzate in gruppi di gestione e le condizioni di governance applicate vengono trasferite a cascata a tutte le sottoscrizioni associate tramite ereditarietà.

I gruppi di gestione offrono opzioni di gestione di livello aziendale su larga scala, indipendentemente dal tipo di sottoscrizioni a disposizione. Tuttavia, tutte le sottoscrizioni all'interno di un singolo gruppo di gestione devono considerare attendibile lo stesso tenant di Azure Active Directory (Azure AD).

Ad esempio, è possibile applicare a un gruppo di gestione criteri che limitano le aree disponibili per la creazione di macchine virtuali (VM). Questi criteri verranno applicati a tutti i gruppi di gestione, alle sottoscrizioni e alle risorse annidati e consentono la creazione di macchine virtuali solo nelle aree autorizzate.

Gerarchia di gruppi di gestione e sottoscrizioni

È possibile creare una struttura flessibile di gruppi di gestione e sottoscrizioni, in modo da organizzare le risorse in una gerarchia per la gestione unificata di accesso e criteri. Il diagramma seguente mostra un esempio di creazione di una gerarchia per la governance tramite gruppi di gestione.

Diagramma di una gerarchia di gruppi di gestione di esempio.

È possibile creare una gerarchia per applicare, ad esempio, criteri che limitano le località delle macchine virtuali all'area Stati Uniti occidentali nel gruppo di gestione denominato "Corp". Questi criteri erediteranno tutte le sottoscrizioni EA (Enterprise Agreement) discendenti del gruppo di gestione e verranno applicati a tutte le macchine virtuali all'interno di tali sottoscrizioni. Questi criteri di sicurezza, inoltre, non possono essere modificati dal proprietario della risorsa o della sottoscrizione e garantiscono così una governance migliore.

Nota

I gruppi di gestione non sono attualmente supportati nelle funzionalità di Gestione costi per le sottoscrizioni di Contratto del cliente Microsoft (MCA).

I gruppi di gestione sono utili anche per offrire agli utenti l'accesso a più sottoscrizioni. Spostando più sottoscrizioni all'interno del gruppo di gestione, è possibile creare una assegnazione di ruolo di Azure nel gruppo di gestione, che eredita l'accesso a tutte le sottoscrizioni. Una sola assegnazione nel gruppo di gestione può consentire agli utenti di accedere a tutte le risorse necessarie invece di eseguire script di controllo degli accessi in base al ruolo di Azure per diverse sottoscrizioni.

Informazioni importanti sui gruppi di gestione

Una singola directory può supportare 10.000 gruppi di gestione.
L'albero di un gruppo di gestione può supportare fino a sei livelli di profondità.
- Questo limite non include il livello radice o il livello sottoscrizione.
Ogni gruppo di gestione e sottoscrizione può supportare un solo elemento padre.
Ogni gruppo di gestione può avere molti elementi figlio.
Tutte le sottoscrizioni e i gruppi di gestione si trovano all'interno di una singola gerarchia in ogni directory. Vedere Informazioni importanti sul gruppo di gestione radice.

Gruppo di gestione radice per ogni directory

A ogni directory viene assegnato un singolo gruppo di gestione di primo livello denominato gruppo di gestione radice . Il gruppo di gestione radice è integrato nella gerarchia in modo che tutti i gruppi di gestione e le sottoscrizioni vi possano confluire. Il gruppo di gestione radice permette l'applicazione di criteri globali e assegnazioni di ruolo di Azure a livello di directory. Inizialmente l'Amministratore globale di Azure AD deve elevare se stesso al ruolo Amministratore Accesso utenti di questo gruppo radice. Dopo aver elevato l'accesso, l'amministratore può assegnare qualsiasi ruolo di Azure ad altri utenti o gruppi della directory per gestire la gerarchia. Gli amministratori possono assegnare il proprio account come proprietario del gruppo di gestione radice.

Informazioni importanti sui gruppi di gestione radice

Per impostazione predefinita, il nome visualizzato del gruppo di gestione radice è Il gruppo radice tenant e opera come gruppo di gestione. L'ID è lo stesso valore dell'ID tenant di Azure Active Directory (Azure AD).
Per modificare il nome visualizzato, all'account deve essere assegnato il ruolo Proprietario o Collaboratore nel gruppo di gestione radice. Vedere Modificare il nome di un gruppo di gestione per aggiornare il nome del gruppo di gestione.
A differenza degli altri gruppi di gestione, il gruppo di gestione radice non può essere spostato o eliminato.
Tutte le sottoscrizioni e i gruppi di gestione confluiscono in un unico gruppo di gestione radice all'interno della directory.
- Tutte le risorse nella directory sono ricondotte al gruppo di gestione radice ai fini della gestione globale.
- Le nuove sottoscrizioni vengono inserite automaticamente nel gruppo di gestione radice al momento della creazione.
Tutti i clienti di Azure possono vedere il gruppo di gestione radice, ma non tutti i clienti dispongono dell'accesso per gestire il gruppo di gestione radice.
- Chiunque abbia accesso a una sottoscrizione può vedere il contesto in cui tale sottoscrizione si trova nella gerarchia.
- A nessun utente viene assegnato l'accesso predefinito al gruppo di gestione radice. Gli amministratori globali di Azure AD sono gli unici utenti che possono elevare i propri privilegi per ottenere l'accesso. Dopo aver ottenuto l'accesso al gruppo di gestione radice, gli amministratori globali possono assegnare ad altri utenti qualsiasi ruolo di Azure per gestirlo.

Importante

Qualsiasi assegnazione di accesso utente o criteri nel gruppo di gestione radice si applica a tutte le risorse presenti nella directory. Per questo motivo, tutti i clienti devono valutare la necessità di disporre di elementi definiti in questo ambito. Le assegnazioni di accesso utente e di criteri devono essere "obbligatori" solo in questo ambito.

Configurazione iniziale dei gruppi di gestione

Quando un utente inizia a usare i gruppi di gestione, si verifica un processo di configurazione iniziale. Il primo passaggio è la creazione del gruppo di gestione radice nella directory. Dopo avere creato questo gruppo, tutte le sottoscrizioni esistenti nella directory diventano elementi figlio del gruppo di gestione radice. Lo scopo di questo processo è assicurarsi che esista un'unica gerarchia di gruppi di gestione all'interno di una directory. Un'unica gerarchia all'interno della directory consente ai clienti amministrativi di applicare i criteri e l'accesso globale per cui gli altri clienti all'interno della directory non possono eseguire il bypass. Qualsiasi elemento assegnato nella radice verrà applicato all'intera gerarchia, che include tutti i gruppi di gestione, le sottoscrizioni, i gruppi di risorse e le risorse all'interno del tenant di Azure AD.

Accesso ai gruppi di gestione

I gruppi di gestione di Azure supportano il controllo degli accessi in base al ruolo di Azure per tutte le definizioni di ruoli e gli accessi alle risorse. Queste autorizzazioni vengono ereditate dalle risorse figlio presenti nella gerarchia. È possibile assegnare a un gruppo di gestione qualsiasi ruolo di Azure, che verrà ereditato lungo tutta la gerarchia fino alle risorse. Ad esempio, il ruolo di Azure Collaboratore Macchina virtuale può essere assegnato a un gruppo di gestione. Questo ruolo non comporta alcuna azione sul gruppo di gestione, ma viene ereditato da tutte le macchine virtuali del gruppo di gestione.

Il grafico seguente mostra l'elenco dei ruoli e delle azioni supportate per i gruppi di gestione.

Nome del ruolo di Azure	Creazione	Rinomina	Spostamento**	Elimina	Assegnazione dell'accesso	Assegnazione dei criteri	Lettura
Proprietario	X	X	X	X	X	X	X
Collaboratore	X	X	X	X			X
Collaboratore gruppo di gestione*	X	X	X	X			X
Lettore							X
Lettore gruppo di gestione*							X
Collaboratore per i criteri delle risorse						X
Amministratore accessi utente					X	X

*: i ruoli Collaboratore gruppo di gestione e Lettore gruppo di gestione consentono agli utenti di eseguire queste azioni solo nell'ambito del gruppo di gestione.

**: le assegnazioni di ruolo nel gruppo di gestione radice non sono necessarie per spostare una sottoscrizione o un gruppo di gestione da e verso di esso.

Per informazioni su come spostare elementi all'interno della gerarchia, vedere Gestire le risorse con i gruppi di gestione.

Definizione e assegnazione di un ruolo personalizzato di Azure

È possibile definire un gruppo di gestione come ambito assegnabile in una definizione del ruolo personalizzato di Azure. Il ruolo personalizzato di Azure sarà quindi disponibile per l'assegnazione in tale gruppo di gestione e in qualsiasi gruppo di gestione, sottoscrizione, gruppo di risorse o risorsa al suo interno. Il ruolo personalizzato erediterà la gerarchia come qualsiasi ruolo predefinito. Per informazioni sulle limitazioni con ruoli personalizzati e gruppi di gestione, vedere Limitazioni.

Definizione di esempio

La definizione e la creazione di un ruolo personalizzato non cambiano con l'inclusione di gruppi di gestione. Usare il percorso completo per definire il gruppo di gestione /providers/Microsoft.Management/managementgroups/{groupId}.

Usare l'ID del gruppo di gestione e non il nome visualizzato del gruppo di gestione. Questo errore comune si verifica poiché entrambi sono campi definiti personalizzati quando si crea un gruppo di gestione.

...
{
  "Name": "MG Test Custom Role",
  "Id": "id",
  "IsCustom": true,
  "Description": "This role provides members understand custom roles.",
  "Actions": [
    "Microsoft.Management/managementgroups/delete",
    "Microsoft.Management/managementgroups/read",
    "Microsoft.Management/managementgroup/write",
    "Microsoft.Management/managementgroup/subscriptions/delete",
    "Microsoft.Management/managementgroup/subscriptions/write",
    "Microsoft.resources/subscriptions/read",
    "Microsoft.Authorization/policyAssignments/*",
    "Microsoft.Authorization/policyDefinitions/*",
    "Microsoft.Authorization/policySetDefinitions/*",
    "Microsoft.PolicyInsights/*",
    "Microsoft.Authorization/roleAssignments/*",
    "Microsoft.Authorization/roledefinitions/*"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
        "/providers/microsoft.management/managementGroups/ContosoCorporate"
  ]
}
...

Problemi di interruzione della definizione del ruolo e del percorso della gerarchia di assegnazione

Le definizioni del ruolo sono con ambito assegnabile in qualsiasi punto all'interno della gerarchia del gruppo di gestione. È possibile definire una definizione del ruolo in un gruppo di gestione padre mentre l'assegnazione di ruolo effettiva è presente nella sottoscrizione figlio. Poiché esiste una relazione tra i due elementi, viene visualizzato un errore durante il tentativo di separare l'assegnazione dalla relativa definizione.

Esaminiamo, ad esempio, una piccola sezione di una gerarchia per un oggetto visivo.

Diagramma di un subset della gerarchia di gruppi di gestione di esempio.

Si supponga che nel gruppo di gestione Sandbox sia definito un ruolo personalizzato. Tale ruolo personalizzato viene quindi assegnato nelle due sottoscrizioni Sandbox.

Se si prova a spostare una di queste sottoscrizioni come elemento figlio del gruppo di gestione Corp, questo spostamento interrompe il percorso dall'assegnazione di ruolo della sottoscrizione alla definizione del ruolo del gruppo di gestione Sandbox. In questo scenario verrà visualizzato un errore che informa che lo spostamento non è consentito poiché interrompe questa relazione.

Sono disponibili alcune opzioni diverse per correggere questo scenario:

Rimuovere l'assegnazione di ruolo dalla sottoscrizione prima di spostare la sottoscrizione in un nuovo gruppo di gestione padre.
Aggiungere la sottoscrizione all'ambito assegnabile della definizione del ruolo.
Modificare l'ambito assegnabile all'interno della definizione del ruolo. Nell'esempio precedente è possibile aggiornare gli ambiti assegnabili da Sandbox al gruppo di gestione radice in modo che sia possibile raggiungere la definizione da entrambi i rami della gerarchia.
Creare un altro ruolo personalizzato definito nell'altro ramo. Questo nuovo ruolo richiede la modifica dell'assegnazione di ruolo anche nella sottoscrizione.

Limiti

Esistono alcune limitazioni quando si usano i ruoli personalizzati nei gruppi di gestione.

È possibile definire un solo gruppo di gestione negli ambiti assegnabili di un nuovo ruolo. Questa limitazione è prevista per ridurre il numero di situazioni in cui le definizioni del ruolo e le assegnazioni di ruolo sono disconnesse. Questa situazione si verifica quando una sottoscrizione o un gruppo di gestione con un'assegnazione di ruolo viene spostato in un elemento padre diverso che non contiene la definizione del ruolo.
I ruoli personalizzati con DataActions non possono essere assegnati all'ambito del gruppo di gestione. Per altre informazioni, vedere Limiti dei ruoli personalizzati.
Azure Resource Manager non convalida l'esistenza del gruppo di gestione nell'ambito assegnabile della definizione del ruolo. Se è presente un errore di digitazione o se un ID gruppo di gestione elencato non è corretto, la definizione del ruolo viene comunque creata.

Spostamento di gruppi di gestione e sottoscrizioni

Affinché un gruppo di gestione o una sottoscrizione possa essere spostato in modo da essere un elemento figlio di un altro gruppo di gestione, è necessario che siano soddisfatte tre regole.

Per eseguire l'azione di spostamento, è necessario avere:

Autorizzazioni di scrittura del gruppo di gestione e delle assegnazioni di ruolo per la sottoscrizione dell'elemento figlio o il gruppo di gestione.
- Esempio di ruolo predefinito: Proprietario
Accesso in scrittura del gruppo di gestione nel gruppo di gestione padre di destinazione.
- Esempio di ruolo predefinito: Proprietario, Collaboratore, Collaboratore gruppo di gestione
Accesso in scrittura del gruppo di gestione nel gruppo di gestione padre esistente.
- Esempio di ruolo predefinito: Proprietario, Collaboratore, Collaboratore gruppo di gestione

Eccezione: se la destinazione o il gruppo di gestione padre esistente è il gruppo di gestione radice, i requisiti delle autorizzazioni non si applicano. Dal momento che il gruppo di gestione radice è il punto di destinazione predefinito per tutti i nuovi gruppi di gestione e tutte le nuove sottoscrizioni, non sono necessarie autorizzazioni per lo spostamento di un elemento.

Se il ruolo Proprietario nella sottoscrizione viene ereditato dal gruppo di gestione corrente, le destinazioni di spostamento sono limitate. È possibile spostare la sottoscrizione solo in un altro gruppo di gestione per cui si ha il ruolo Proprietario. Non è possibile spostarla in un gruppo di gestione in cui si ha il ruolo Collaboratore perché si perderebbe la proprietà della sottoscrizione. Se si è assegnati direttamente al ruolo Proprietario per la sottoscrizione (ruolo non ereditato dal gruppo di gestione), è possibile spostarla in qualsiasi gruppo di gestione per il quale si ha il ruolo Collaboratore.

Importante

Azure Resource Manager memorizza nella cache i dettagli della gerarchia dei gruppi di gestione per un massimo di 30 minuti. Di conseguenza, lo spostamento di un gruppo di gestione potrebbe non essere immediatamente visibile nel portale di Azure.

Controllare i gruppi di gestione con i log attività

I gruppi di gestione sono supportati nel log attività di Azure. È possibile cercare tutti gli eventi che si verificano per un gruppo di gestione nella stessa posizione centrale delle altre risorse di Azure. Ad esempio, è possibile visualizzare tutte le modifiche delle assegnazioni di ruolo o dei criteri apportate in un determinato gruppo di gestione.

Screenshot dei log attività e delle operazioni correlate al gruppo di gestione selezionato.

Quando si cerca di eseguire query sui gruppi di gestione all'esterno del portale di Azure, l'ambito di destinazione per i gruppi di gestione è simile a "/providers/Microsoft.Management/managementGroups/{management-group-id}".