Che cosa sono i gruppi di gestione di Azure?

Se l'organizzazione ha molte sottoscrizioni di Azure, potrebbe essere necessario un modo per gestire in modo efficiente l'accesso, i criteri e la conformità per tali sottoscrizioni. I gruppi di gestione forniscono un ambito di governance sopra le sottoscrizioni. Le sottoscrizioni sono organizzate in gruppi di gestione; le condizioni di governance applicate a catena in base all'ereditarietà a tutte le sottoscrizioni associate.

I gruppi di gestione offrono una gestione di livello aziendale su larga scala, indipendentemente dal tipo di sottoscrizioni che si potrebbe avere. 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). Questo criterio verrà applicato a tutti i gruppi di gestione annidati, alle sottoscrizioni e alle risorse e consente 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.

Diagramma di un gruppo di gestione radice che contiene sia i gruppi di gestione che le sottoscrizioni. Alcuni gruppi di gestione figlio contengono gruppi di gestione, alcuni contengono sottoscrizioni e alcuni contengono entrambi. Uno degli esempi nella gerarchia di esempio è quattro livelli di gruppi di gestione, con il livello figlio che corrisponde a tutte le sottoscrizioni.

È possibile creare una gerarchia che applica un criterio, ad esempio, che limita le posizioni delle macchine virtuali all'area Stati Uniti occidentali nel gruppo di gestione denominato "Corp". Questo criterio erediterà tutte le sottoscrizioni Enterprise Agreement (EA) discendenti di tale gruppo di gestione e verranno applicate a tutte le macchine virtuali in tali sottoscrizioni. Questo criterio di sicurezza non può essere modificato dal proprietario della risorsa o della sottoscrizione, consentendo una migliore governance.

Nota

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

Un altro scenario in cui è utile usare gruppi di gestione è per fornire 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 si ripieghino su di esso. 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 l'account come proprietario del gruppo di gestione radice.

Fatti importanti sul gruppo 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 si ripieghino in un 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 qualsiasi ruolo di Azure ad altri utenti per gestirlo.

Importante

Qualsiasi assegnazione di accesso utente o criteri nel gruppo di gestione radice si applica a tutte le risorse all'interno della 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 ha alcuna azione sul gruppo di gestione, ma erediterà in tutte le macchine virtuali nel 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 Create Rinominare Spostamento** Delete Assegnare l'accesso Assegnare un criterio Lettura
Proprietario X X X X X X X
Collaboratore X X X X X
Collaboratore gruppo di gestione* X X X X X
Reader 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 tali 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 di ruolo personalizzata 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 dei ruoli personalizzati e dei 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.

Il diagramma è incentrato sul gruppo di gestione radice con le zone di destinazione figlio e i gruppi di gestione sandbox. Il gruppo di gestione delle zone di destinazione ha due gruppi di gestione figlio denominati Corp e Online, mentre il gruppo di gestione sandbox ha due sottoscrizioni figlio.

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 tenta di spostare una di queste sottoscrizioni come figlio del gruppo di gestione Corp, questo spostamento interromperà 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 la definizione possa essere raggiunta da entrambi i rami della gerarchia.
  • Creare un altro ruolo personalizzato definito nell'altro ramo. Questo nuovo ruolo richiede anche la modifica dell'assegnazione di ruolo nella sottoscrizione.

Limitazioni

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.
  • Le azioni del piano dati del provider di risorse non possono essere definite nei ruoli personalizzati del gruppo di gestione. Questa restrizione è prevista perché si verifica un problema di latenza con l'aggiornamento dei provider di risorse del piano dati. Questo problema di latenza è in fase di analisi e queste azioni verranno disabilitate dalla definizione del ruolo per ridurre eventuali rischi.
  • 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 un ID del gruppo di gestione non corretto elencato, 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 e scrittura delle assegnazioni di ruolo per la sottoscrizione 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. Poiché il gruppo di gestione radice è il punto di destinazione predefinito per tutti i nuovi gruppi di gestione e 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 in un altro gruppo di gestione in cui si ha il ruolo Proprietario . Non è possibile spostarlo in un gruppo di gestione in cui si è un collaboratore perché si perde la proprietà della sottoscrizione. Se si è assegnati direttamente al ruolo Proprietario per la sottoscrizione (non ereditato dal gruppo di gestione), è possibile spostarlo in qualsiasi gruppo di gestione a cui è assegnato 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 riflessa nella 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 assegnazioni di ruolo o le modifiche all'assegnazione dei criteri apportate a 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}".

Nota

Usando l'API REST di Azure Resource Manager, è possibile abilitare le impostazioni di diagnostica in un gruppo di gestione per inviare voci del log attività di Azure correlate a un'area di lavoro Log Analytics, Archiviazione di Azure o Hub eventi di Azure. Per altre informazioni, vedere Impostazioni di diagnostica del gruppo di gestione - Creazione o aggiornamento.

Passaggi successivi

Per altre informazioni sui gruppi di gestione, vedere: