Gruppi di gestione
Usare i gruppi di gestione per organizzare e gestire le sottoscrizioni di Azure. Man mano che aumenta il numero di sottoscrizioni, i gruppi di gestione forniscono una struttura critica all'ambiente Azure e semplificano la gestione delle sottoscrizioni. Usare le indicazioni seguenti per stabilire una gerarchia efficace dei gruppi di gestione e organizzare le sottoscrizioni in base alle procedure consigliate.
Considerazioni sulla progettazione dei gruppi di gestione
Le strutture dei gruppi di gestione all'interno di un tenant di Microsoft Entra supportano il mapping dell'organizzazione. Prendere in considerazione la struttura del gruppo di gestione accuratamente quando l'organizzazione pianifica l'adozione di Azure su larga scala.
Determinare in che modo l'organizzazione separa i servizi di cui sono proprietari o operano specifici team.
Determinare se sono presenti funzioni specifiche che è necessario mantenere separate per motivi quali requisiti aziendali, requisiti operativi, requisiti normativi, residenza dei dati, sicurezza dei dati o conformità alla sovranità dei dati.
Usare i gruppi di gestione per aggregare le assegnazioni di criteri e iniziative tramite Criteri di Azure.
Abilitare l'autorizzazione del controllo degli accessi in base al ruolo di Azure per le operazioni del gruppo di gestione per eseguire l'override dell'autorizzazione predefinita. Per impostazione predefinita, qualsiasi entità, ad esempio un'entità utente o un'entità servizio, all'interno di un tenant di Microsoft Entra può creare nuovi gruppi di gestione. Per altre informazioni, vedere Come proteggere la gerarchia delle risorse.
Considerare anche i fattori seguenti:
L'albero di un gruppo di gestione può supportare fino a sei livelli di profondità. Questo limite non include il livello radice del tenant o il livello di sottoscrizione.
Tutte le nuove sottoscrizioni vengono inserite nel gruppo di gestione radice del tenant per impostazione predefinita.
Per altre informazioni, vedere Gruppi di gestione.
Raccomandazioni per i gruppi di gestione
Mantenere la gerarchia dei gruppi di gestione ragionevolmente piatta. L'ideale è che il numero dei livelli non sia superiore a tre o quattro. In questo modo si riduce il sovraccarico e la complessità della gestione.
Non duplicare la struttura organizzativa in una gerarchia di gruppi di gestione profondamente annidata. Usare i gruppi di gestione per l'assegnazione dei criteri e per la fatturazione. Per questo approccio, usare i gruppi di gestione per lo scopo previsto nell'architettura concettuale della zona di destinazione di Azure. Questa architettura fornisce criteri di Azure per carichi di lavoro che richiedono lo stesso tipo di sicurezza e conformità nello stesso livello del gruppo di gestione.
Creare gruppi di gestione nel gruppo di gestione a livello radice per rappresentare i tipi di carichi di lavoro ospitati. Questi gruppi si basano sulle esigenze di sicurezza, conformità, connettività e funzionalità dei carichi di lavoro. Con questa struttura di raggruppamento è possibile applicare un set di criteri di Azure a livello di gruppo di gestione. Usare questa struttura di raggruppamento per tutti i carichi di lavoro che richiedono le stesse impostazioni di sicurezza, conformità, connettività e funzionalità.
Usare i tag delle risorse per eseguire query e spostarsi orizzontalmente nella gerarchia dei gruppi di gestione. È possibile usare Criteri di Azure per applicare o aggiungere tag di risorsa. È quindi possibile raggruppare le risorse per le esigenze di ricerca senza dover usare una gerarchia dei gruppi di gestione complessa.
Creare un gruppo di gestione sandbox di primo livello in modo da poter sperimentare immediatamente le risorse prima di spostarle in ambienti di produzione. Sandbox offre l'isolamento dagli ambienti di sviluppo, test e produzione.
Creare un gruppo di gestione della piattaforma nel gruppo di gestione radice per supportare i criteri comuni della piattaforma e le assegnazioni di ruolo di Azure. Questa struttura di raggruppamento garantisce che sia possibile applicare vari criteri alle sottoscrizioni nelle basi di Azure. Questo approccio centralizza anche la fatturazione per le risorse comuni in un set di sottoscrizioni di base.
Limitare il numero di assegnazioni Criteri di Azure nell'ambito del gruppo di gestione radice. Questa limitazione riduce al minimo il debug di criteri ereditati in gruppi di gestione di basso livello.
Usare i criteri per applicare i requisiti di conformità nell'ambito del gruppo di gestione o della sottoscrizione e ottenere una governance basata su criteri.
Assicurarsi che solo gli utenti con privilegi possano gestire i gruppi di gestione nel tenant. Abilitare l'autorizzazione del controllo degli accessi in base al ruolo di Azure nelle impostazioni della gerarchia del gruppo di gestione per perfezionare i privilegi utente. Per impostazione predefinita, tutti gli utenti possono creare gruppi di gestione personalizzati nel gruppo di gestione radice.
Configurare un gruppo di gestione dedicato predefinito per le nuove sottoscrizioni. Questo gruppo garantisce che non vi siano sottoscrizioni nel gruppo di gestione radice. Questo gruppo è particolarmente importante se gli utenti hanno vantaggi e sottoscrizioni di Microsoft Developer Network (MSDN) o Visual Studio. Un gruppo di gestione sandbox è un buon candidato per questo tipo di gruppo di gestione. Per altre informazioni, vedere Impostare un gruppo di gestione predefinito.
Non creare gruppi di gestione per ambienti di produzione, test e sviluppo. Se necessario, separare questi gruppi in sottoscrizioni diverse nello stesso gruppo di gestione. Per altre informazioni, vedi:
È consigliabile usare la struttura standard del gruppo di gestione della zona di destinazione di Azure per le distribuzioni con più aree. Non creare gruppi di gestione esclusivamente per modellare aree di Azure diverse. Non modificare o espandere la struttura del gruppo di gestione in base all'utilizzo dell'area o della multiregione.
Se si dispone di requisiti normativi basati sulla posizione, ad esempio residenza dei dati, sicurezza dei dati o sovranità dei dati, è necessario creare una struttura del gruppo di gestione in base alla posizione. È possibile implementare questa struttura a vari livelli. Per altre informazioni, vedere Modificare un'architettura della zona di destinazione di Azure.
Gruppi di gestione nell'acceleratore della zona di destinazione di Azure e nel repository ALZ-Bicep
Nell'esempio seguente viene illustrata una struttura del gruppo di gestione. I gruppi di gestione in questo esempio si trovano nell'acceleratore di zona di destinazione di Azure e nel modulo gruppi di gestione del repository ALZ-Bicep.
Nota
È possibile modificare la gerarchia dei gruppi di gestione nel modulo bicep della zona di destinazione di Azure modificando managementGroups.bicep.
| Gruppo di gestione | Descrizione |
|---|---|
| Gruppo di gestione radice intermedio | Questo gruppo di gestione si trova direttamente nel gruppo radice del tenant. L'organizzazione fornisce a questo gruppo di gestione un prefisso in modo che non sia necessario usare il gruppo radice. L'organizzazione può spostare le sottoscrizioni di Azure esistenti nella gerarchia. Questo approccio configura anche scenari futuri. Questo gruppo di gestione è un elemento padre di tutti gli altri gruppi di gestione creati dall'acceleratore della zona di destinazione di Azure. |
| Piattaforma | Questo gruppo di gestione contiene tutti i gruppi di gestione figlio della piattaforma, ad esempio gestione, connettività e identità. |
| Gestione | Questo gruppo di gestione contiene una sottoscrizione dedicata per la gestione, il monitoraggio e la sicurezza. Questa sottoscrizione ospita un'area di lavoro Log di Monitoraggio di Azure, incluse le soluzioni associate e un account Automazione di Azure. |
| Connettività | Questo gruppo di gestione contiene una sottoscrizione dedicata per la connettività. Questa sottoscrizione ospita le risorse di rete di Azure, ad esempio azure rete WAN virtuale, Firewall di Azure e zone private DNS di Azure, richieste dalla piattaforma. È possibile usare vari gruppi di risorse per contenere risorse, ad esempio reti virtuali, istanze del firewall e gateway di rete virtuale, distribuite in aree diverse. Alcune distribuzioni di grandi dimensioni potrebbero avere restrizioni relative alla quota di sottoscrizione per le risorse di connettività. È possibile creare sottoscrizioni dedicate in ogni area per le risorse di connettività. |
| Identità | Questo gruppo di gestione contiene una sottoscrizione dedicata per l'identità. Questa sottoscrizione è un segnaposto per le macchine virtuali (VM) di Dominio di Active Directory Services (AD DS) o Microsoft Entra Domain Services. È possibile usare vari gruppi di risorse per contenere risorse, ad esempio reti virtuali e macchine virtuali, distribuite in aree diverse. La sottoscrizione abilita anche AuthN o AuthZ per i carichi di lavoro all'interno delle zone di destinazione. Assegnare criteri di Azure specifici per rafforzare e gestire le risorse nella sottoscrizione di identità. Alcune distribuzioni di grandi dimensioni potrebbero avere restrizioni relative alla quota di sottoscrizione per le risorse di connettività. È possibile creare sottoscrizioni dedicate in ogni area per le risorse di connettività. |
| Zone di destinazione | Gruppo di gestione padre che contiene tutti i gruppi di gestione figlio della zona di destinazione. Dispone di criteri di Azure indipendenti dal carico di lavoro assegnati per garantire che i carichi di lavoro siano sicuri e conformi. |
| Online | Gruppo di gestione dedicato per le zone di destinazione online. Questo gruppo è destinato ai carichi di lavoro che potrebbero richiedere connettività internet diretta o in uscita o per carichi di lavoro che potrebbero non richiedere una rete virtuale. |
| Corp | Gruppo di gestione dedicato per le zone di destinazione aziendali. Questo gruppo è riservato a carichi di lavoro che richiedono una connettività o connettività ibrida con la rete aziendale tramite l'hub nella sottoscrizione di connettività. |
| Sandbox | Gruppo di gestione dedicato per le sottoscrizioni. Un'organizzazione usa sandbox per il test e l'esplorazione. Queste sottoscrizioni sono isolate in modo sicuro dalle zone di destinazione aziendali e online. Le sandbox hanno anche un set meno restrittivo di criteri assegnati per abilitare il test, l'esplorazione e la configurazione di servizi di Azure. |
| Disattivato | Gruppo di gestione dedicato per le zone di destinazione annullate. Le zone di destinazione annullate vengono spostate in questo gruppo di gestione e quindi azure le elimina dopo 30-60 giorni. |
Nota
Per molte organizzazioni, i gruppi predefiniti Corp e Online di gestione offrono un punto di partenza ideale.
Alcune organizzazioni devono aggiungere altri gruppi di gestione.
Per modificare la gerarchia dei gruppi di gestione, vedere Personalizzare l'architettura della zona di destinazione di Azure per soddisfare i requisiti.
Autorizzazioni per l'acceleratore della zona di destinazione di Azure
L'acceleratore di zona di destinazione di Azure:
Richiede un nome dell'entità servizio dedicato (SPN) per eseguire operazioni del gruppo di gestione, operazioni di gestione delle sottoscrizioni e assegnazioni di ruolo. Usare un nome SPN per ridurre il numero di utenti con diritti elevati e seguire le linee guida relative ai privilegi minimi.
Richiede il ruolo di Amministratore accesso utente all'ambito del gruppo di gestione radice per concedere al nome dell'entità servizio l'accesso a livello radice. Dopo che il nome SPN dispone delle autorizzazioni, è possibile rimuovere in modo sicuro il ruolo accesso utente Amministrazione istrator. Questo approccio garantisce che solo il nome SPN sia connesso al ruolo accesso utente Amministrazione istrator.
Richiede il ruolo Collaboratore per il nome SPN indicato in precedenza nell'ambito del gruppo di gestione radice, che consente operazioni a livello di tenant. Questo livello di autorizzazione garantisce che sia possibile usare il nome SPN per distribuire e gestire le risorse in qualsiasi sottoscrizione all'interno dell'organizzazione.
Passaggio successivo
Informazioni su come usare le sottoscrizioni quando si pianifica un'adozione di Azure su larga scala.
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per