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 operare e mantenere con successo 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 possiede più tenant di Microsoft Entra.
Ad esempio, si potrebbero avere più tenant di Microsoft Entra se si è un fornitore di software indipendente. È probabile che tu voglia mantenere separati i tenant Microsoft Entra per le soluzioni aziendali e SaaS. Il rischio di un'operazione o di una distribuzione che influisce sull'altro tenant, sia intenzionale che per errore, si riduce.
Le sezioni seguenti forniscono diagrammi e indicazioni sugli approcci che è possibile adottare. Scegli l'approccio migliore in base ai tuoi requisiti, considerazioni e raccomandazioni per automatizzare le distribuzioni delle Azure landing zones quando gestisci più tenant 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 landing zone 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 tratta dell'automazione della distribuzione e dell'operatività delle landing zone 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 sono destinati a essere usati dai team delle applicazioni che distribuiscono e gestiscono i servizi e le applicazioni nelle rispettive zone di destinazione (sottoscrizioni). Per ulteriori informazioni sui diversi tipi di zone di destinazione, vedere Zone di destinazione della piattaforma rispetto alle zone di destinazione dell'applicazione.
Approccio 1: isolamento completo
In questo approccio, l'obiettivo principale consiste nel mantenere ogni tenant di Microsoft Entra isolato dagli altri in tutti i componenti di automazione, ad esempio:
- Repository di Git.
- GitHub Actions o Azure Pipelines (inclusi i runner ospitati autonomamente, se utilizzati).
- Identità usate per eseguire attività dall'automazione, come identità gestite assegnate ai runner self-hosted, nomi principali di servizio (SPN), utenti o amministratori.
In questo approccio, ci sono 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 attualmente non supportano scenari tra tenant in uno stato generalmente disponibile. Per altre informazioni, vedere queste domande frequenti.
Tuttavia, questa funzionalità è ora disponibile in anteprima pubblica per le Identità gestite User-Assigned configurando un rapporto di fiducia tra l'identità gestita stessa e un'applicazione Entra ID multi-tenant. Consulta ulteriori informazioni sulla configurazione in Configurare un'applicazione per considerare attendibile un'identità gestita (anteprima). Questo può ora rendere Approccio 2 - Registrazione dell'applicazione condivisa (multi-tenant) con più entità servizio un'opzione praticabile per la distribuzione.
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 gestione di Microsoft Entra. In ogni tenant di Microsoft Entra che si desidera gestire, viene creato un nome dell'entità servizio (SPN) in quel tenant, basato sulla registrazione dell'applicazione. Questa azione consente ai lavoratori che eseguono le attività e i passaggi della pipeline di accedere a uno dei tenant di Microsoft Entra con un unico set di credenziali.
Suggerimento
Per informazioni sulla relazione tra le registrazioni delle applicazioni e le applicazioni aziendali (principali del servizio), vedere oggetti di applicazione e principali del servizio in Microsoft Entra ID.
Importante
In questo approccio, la registrazione delle singole applicazioni e le applicazioni aziendali associate (principali di 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 tenant contoso.onmicrosoft.com Microsoft Entra e un'applicazione aziendale si trova in ogni tenant di Microsoft Entra collegato alla registrazione dell'app. Questa configurazione consente a una pipeline di eseguire l'autenticazione e l'autorizzazione a tutti i tenant Microsoft Entra usando una singola registrazione dell'applicazione. Per ulteriori informazioni, vedere Configurare l'applicazione per un'architettura multi-tenant e Concedere il consenso amministrativo a livello di tenant a un'applicazione.
Suggerimento
Le identità gestite assegnate dall'utente, in anteprima pubblica, possono ora supportare scenari multi-tenant configurando un trust tra essa e un'applicazione multi-tenant Entra ID. Per altre informazioni sulla configurazione in Configurare un'applicazione per considerare attendibile un'identità gestita (anteprima).
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 richiamati durante l'esecuzione della pipeline in un passaggio che utilizza logiche e condizioni per controllare il tenant di Microsoft Entra a cui è 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, come sviluppo, test o produzione, possono essere gestiti nello stesso modo utilizzando le stesse, o separate, registrazioni delle applicazioni e 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 ruolo di proprietario RBAC, dell'amministratore dell'accesso utente e dei ruoli con autorizzazioni DataActions. Per ulteriori informazioni, vedere supporto del ruolo per in 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 nelle Azure landing zones, ma è ancora utile in alcune situazioni. Per ulteriori informazioni, vedere utilizzo di Azure Lighthouse in ALZ multitenant.
Identità per amministratori e sviluppatori della piattaforma - Approccio 2
In questo approccio, gli amministratori e gli sviluppatori della piattaforma di solito devono accedere solo al tenant gestito 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, ad esempio l'esempio nel primo approccio.