Automatizzare le zone di destinazione di Azure in più tenant
Se l'organizzazione ha più tenant di Microsoft Entra con zone di destinazione di Azure (ALZ) in ognuna di esse, una o più volte, l'automazione è fondamentale. L'automazione consente di gestire e gestire correttamente la distribuzione di ALZ su larga scala in tutti i tenant. Esistono molti approcci per automatizzare le distribuzioni di alz tra più tenant. L'approccio adottato dipende dai motivi per cui l'organizzazione ha più tenant di Microsoft Entra.
Ad esempio, si potrebbero avere più tenant di Microsoft Entra se si è un fornitore di software indipendente. È probabile che si voglia mantenere separati i tenant Microsoft Entra per le soluzioni Aziendali e SaaS. Il rischio di un'operazione o di una distribuzione che interessa l'altro tenant, sia intenzionale che per errore, riduce.
Le sezioni seguenti forniscono diagrammi e indicazioni sugli approcci che è possibile adottare. Scegliere l'approccio migliore in base ai requisiti, alle considerazioni e alle raccomandazioni per automatizzare le distribuzioni delle zone di destinazione di Azure quando si gestiscono più tenant di Microsoft Entra.
Nota
Esaminare prima gli articoli seguenti per ottenere una panoramica dei tenant di Microsoft Entra:
Approcci
Esistono due approcci per automatizzare la distribuzione delle zone di destinazione di Azure in più tenant di Microsoft Entra.
Approccio 1: l'isolamento completo è l'approccio più comune negli scenari multi-tenant. Questo approccio mantiene la separazione e l'isolamento necessari tra i tenant di Microsoft Entra, che è il requisito più comune quando si usa un approccio multi-tenant.
Approccio 2: la registrazione di applicazioni condivise (multi-tenant) con più entità servizio viene comunemente usata negli scenari msp (Managed Service Provider). In questo approccio, è possibile usare un modello di stamp di distribuzione per automatizzare la distribuzione di un'architettura quasi identica in più tenant su larga scala.
Entrambi questi approcci vengono forniti come esempi e ispirazione. È possibile combinare e abbinare gli approcci nelle distribuzioni in base ai requisiti dell'organizzazione.
Importante
Questo articolo illustra l'automazione della distribuzione e del funzionamento delle zone di destinazione di Azure come piattaforma in ogni tenant di Microsoft Entra di cui dispone l'organizzazione. Gli approcci, le raccomandazioni e le considerazioni in questo articolo non devono essere usati dai team delle applicazioni che distribuiscono e gestiscono i servizi e le applicazioni nelle zone di destinazione (sottoscrizioni). Per altre informazioni sui diversi tipi di zone di destinazione, vedere Piattaforme e zone di destinazione dell'applicazione.
Approccio 1: isolamento completo
In questo approccio, l'obiettivo principale consiste nel mantenere ogni tenant di Microsoft Entra isolato l'uno dall'altro in tutti i componenti di automazione, ad esempio:
- Repository Git.
- GitHub Actions o Azure Pipelines (inclusi gli strumenti di esecuzione self-hosted, se usati).
- Identità usate per eseguire attività dall'automazione, ad esempio identità gestite assegnate a strumenti di esecuzione self-hosted, nomi di entità servizio (SPN), utenti o amministratori.
In questo approccio sono disponibili più componenti da gestire che vengono duplicati per ogni tenant di Microsoft Entra. Alcune organizzazioni potrebbero avere controlli di conformità alle normative applicati a loro che impongono questo tipo di separazione e isolamento.
Nota
Se l'organizzazione consente solo l'uso di identità gestite per l'automazione della piattaforma, è necessario usare questo approccio o un approccio che esegue l'accesso a ogni tenant singolarmente. Le identità gestite non supportano scenari tra tenant. Per altre informazioni, vedere le domande frequenti.
Identità per amministratori e sviluppatori della piattaforma - Approccio 1
In questo approccio, le identità devono anche essere isolate in ogni tenant di Microsoft Entra, il che significa che ogni amministratore della piattaforma o sviluppatore richiede un account utente separato all'interno di ogni tenant per eseguire operazioni all'interno di tale tenant. Questi account vengono usati anche per accedere agli strumenti di sviluppo, ad esempio GitHub o Azure DevOps, per ognuno dei tenant. Considerare attentamente gli effetti della produttività degli amministratori e degli sviluppatori seguendo questo approccio.
È possibile usare Microsoft Entra B2B e/o Azure Lighthouse, ma questa opzione pone domande sul motivo di avere tenant Microsoft Entra separati.
Approccio 2: registrazione di applicazioni condivise (multi-tenant) con più entità servizio
In questo approccio viene creata una registrazione dell'applicazione nel tenant di Microsoft Entra. In ogni tenant di Microsoft Entra che si vuole gestire, viene creato un nome dell'entità servizio (SPN) in tale tenant, in base alla registrazione dell'applicazione. Questa azione consente ai ruoli di lavoro che eseguono le attività della pipeline e i passaggi di accedere a uno dei tenant di Microsoft Entra con un singolo set di credenziali.
Suggerimento
Per informazioni sulla relazione tra le registrazioni dell'applicazione e le applicazioni aziendali (principi di servizio), vedere Oggetti applicazione e entità servizio in Microsoft Entra ID.
Importante
In questo approccio, la registrazione delle singole applicazioni e le applicazioni aziendali associate (entità servizio) devono essere monitorate per qualsiasi attività anomala negli strumenti siem (Security Information and Event Management) perché si tratta di un account con privilegi elevati. Deve inviare avvisi e potenzialmente intervenire automaticamente, a seconda della gravità dell'avviso.
Nell'esempio precedente, una singola registrazione dell'app si trova nel contoso.onmicrosoft.com tenant Di Microsoft Entra e un'applicazione aziendale si trova in ognuno dei tenant di Microsoft Entra collegati alla registrazione dell'app. Questa configurazione consente a una pipeline di eseguire l'autenticazione e l'autorizzazione a tutti i tenant di Microsoft Entra usando la registrazione della singola app. Per altre informazioni, vedere Creazione del multi-tenant dell'applicazione.
Quando si usa una pipeline centralizzata, potrebbe essere necessario creare una piccola tabella di mapping contenente dati correlati ai tenant di Microsoft Entra e ad altri metadati, ad esempio l'ambiente, le sottoscrizioni associate, il nome dell'organizzazione e l'ID oggetto identity usati per l'autenticazione e l'autorizzazione. Questi dati possono essere chiamati durante l'esecuzione della pipeline in un passaggio che usa alcune condizioni e logica per controllare il tenant di Microsoft Entra in cui viene distribuito e con quali identità. I dati possono essere archiviati in servizi, ad esempio Azure Cosmos DB o Archiviazione tabelle di Azure.
Quando si gestiscono più ambienti, ad esempio sviluppo, test o produzione, possono essere controllati nello stesso modo usando le stesse registrazioni delle applicazioni e le applicazioni aziendali con pipeline.
È possibile decidere di avere pipeline separate per ogni tenant di Microsoft Entra o usare una singola pipeline. La scelta è basata sulle proprie esigenze.
Nota
Azure Lighthouse funziona in modo simile a questo approccio, ma Azure Lighthouse non consente l'assegnazione del proprietario del controllo degli accessi in base al ruolo, dell'amministratore dell'accesso utente e dei ruoli con autorizzazioni DataActions. Per altre informazioni, vedere Supporto dei ruoli per Azure Lighthouse.
I ruoli di proprietario e accesso utente sono in genere necessari in tutti gli scenari di distribuzione della zona di destinazione di Azure. Questo requisito rimuove Azure Lighthouse come opzione per l'intero aspetto della distribuzione dell'automazione della piattaforma delle zone di destinazione di Azure, ma è comunque utile in alcuni scenari. Per altre informazioni, vedere Uso di Azure Lighthouse in ALZ multi-tenant.
Identità per amministratori e sviluppatori della piattaforma - Approccio 2
In questo approccio, gli amministratori e gli sviluppatori della piattaforma devono in genere accedere solo al tenant di Microsoft Entra. Questo accesso concede loro l'accesso agli strumenti di sviluppo, ad esempio GitHub o Azure DevOps, da cui vengono distribuiti e gestiti tutti i tenant.
Potrebbero avere accesso agli altri tenant di Microsoft Entra tramite Microsoft Entra B2B o Azure Lighthouse. Usano lo stesso account dal tenant di gestione oppure possono avere account separati, come nell'esempio nel primo approccio.