Gestire la configurazione del tenant di Microsoft 365 con Microsoft365DSC e Azure DevOps

Azure DevOps
Azure Key Vault
Macchine virtuali Windows in Azure
Microsoft 365

Questo articolo descrive una soluzione per la gestione delle modifiche apportate dagli amministratori del servizio ai tenant Microsoft 365. La soluzione usa un processo basato su repository per esaminare e approvare le modifiche di configurazione prima della distribuzione. Questo processo crea un audit trail per le modifiche inviate tramite il repository e consente di applicare le configurazioni approvate in modo coerente in più tenant Microsoft 365.

Architettura

Diagramma che mostra l'architettura per automatizzare le modifiche apportate alle configurazioni del tenant Microsoft 365 usando Microsoft365DSC e Azure Pipelines.

Il flusso di lavoro passa da sinistra a destra ed è organizzato in nove passaggi numerati. Il lato sinistro del diagramma è incentrato sulla creazione e sulle attività di controllo del codice sorgente, la sezione centrale mostra i processi di compilazione e distribuzione automatizzati e il lato destro mostra la distribuzione in Microsoft 365 ambienti di gestione temporanea e produzione. Il passaggio 1 inizia con un amministratore con l'etichetta Admin 1. L'amministratore 1 aggiunge, modifica o elimina le impostazioni in un file di configurazione. Una freccia punta da Admin 1 a un'icona del documento con etichetta File di configurazione. Nel passaggio 2 le modifiche di configurazione vengono sottoposte a commit e sincronizzate con un fork personale di un repository. Il fork è rappresentato da un'icona del repository Git con l'etichetta Fork admin 1. Una freccia connette il file di configurazione al repository con fork. Il passaggio 3 mostra l'amministratore che crea una richiesta pull dal repository con fork a un repository centrale. Una freccia orizzontale punta da Fork admin 1 a un repository Git con etichetta Main repository. La freccia è etichettata Crea richiesta pull. Il passaggio 4 introduce una fase di convalida automatizzata. Una freccia verso il basso dal processo di richiesta pull punta a Azure Pipelines. La freccia è etichettata Controlla richiesta pull. Il passaggio 5 mostra un gruppo di amministratori che esamina le modifiche proposte. Una freccia punta dal gruppo di amministratori verso il repository principale ed è etichettata Revisione codice e richiesta pull unione. Dopo aver unito la richiesta pull, il flusso di lavoro continua dal repository principale a una pipeline a più fasi rappresentata da un'icona Azure Pipelines. Il passaggio 6 mostra la pipeline in più fasi che recupera le credenziali da Azure Key Vault. Una freccia verticale punta verso l'alto dalla pipeline all'icona Key Vault. La connessione viene etichettata Come ottenere le credenziali per la compilazione di file MOF (Managed Object Format). Il passaggio 7 mostra la pipeline in più fasi passando i dati di configurazione compilati a Microsoft365DSC, rappresentato da un'icona Microsoft 365. La connessione viene etichettata Deploy changes from MOF files via PowerShell task (Distribuisci modifiche dai file MOF tramite l'attività powerShell). Da Microsoft365DSC, due percorsi di distribuzione si diramano verso l'esterno. Il percorso superiore distribuisce le modifiche a un ambiente di staging Microsoft 365. La freccia che connette Microsoft365DSC alla gestione temporanea è denominata Deploy (Distribuisci). Il passaggio 8 mostra un gruppo di amministratori che convalidano le modifiche nell'ambiente di gestione temporanea. Una freccia punta dagli amministratori al tenant di staging Microsoft 365 e viene etichettata Convalida modifiche. Al termine della convalida, il passaggio 9 mostra agli amministratori che approvano la distribuzione nell'ambiente di produzione. Il gruppo di amministratori viene posizionato accanto all'ambiente di produzione. Il testo a cui si accompagna legge Approva modifica per la distribuzione. Una freccia di distribuzione si estende da Microsoft365DSC verso l'ambiente di produzione Microsoft 365. La freccia è denominata Distribuisci. Una seconda freccia connette il passaggio di approvazione dell'amministratore all'ambiente di produzione.

Scaricare un file di Visio di questa architettura.

Flusso di lavoro

  1. L'amministratore 1 aggiunge, aggiorna o elimina una voce in un fork di un file di configurazione Microsoft 365. Ad esempio, l'amministratore 1 modifica i criteri di autorizzazione per un'app Microsoft Teams.
  2. L'amministratore 1 esegue il commit e sincronizza le modifiche nel repository con fork.
  3. Admin 1 crea una richiesta pull per unire le modifiche nel repository principale.
  4. In Azure Pipelines, una pipeline di compilazione viene eseguita nella richiesta pull.
  5. Altri amministratori esaminano il codice e uniscono la richiesta pull.
  6. La richiesta pull unita attiva una pipeline per compilare i file MOF (Managed Object Format). La pipeline chiama Azure Key Vault per recuperare le credenziali usate nei file MOF.
  7. Un'attività di Azure PowerShell in una pipeline a più fasi usa i file MOF compilati per distribuire le modifiche di configurazione tramite Microsoft365DSC.
  8. Gli amministratori convalidano le modifiche in un tenant di Microsoft 365 a fasi.
  9. Gli amministratori ricevono notifiche sul processo di approvazione in Azure DevOps per il tenant di Microsoft 365 di produzione. Gli amministratori approvano o rifiutano le modifiche.

Componenti

  • Azure Pipelines è un servizio Azure DevOps per l'integrazione continua e il recapito continuo (CI/CD). È possibile usare Azure Pipelines per testare e compilare il codice e spedirlo a qualsiasi destinazione. È anche possibile usare Azure Pipelines per implementare controlli di qualità per garantire la distribuzione delle modifiche in modo controllato e coerente.
  • Key Vault migliora la sicurezza dell'archiviazione per token, password, certificati, chiavi API e altri segreti. Fornisce inoltre un accesso strettamente controllato a questi segreti. Questo carico di lavoro di esempio usa Key Vault per archiviare le credenziali usate da entità servizio per distribuire le modifiche di configurazione ai tenant Microsoft 365. Esempi di queste credenziali includono segreti client e certificati.
  • Microsoft365DSC è un progetto open source che fornisce automazione per la distribuzione, la configurazione e il monitoraggio dei tenant Microsoft 365 tramite PowerShell Desired State Configuration (DSC). È possibile usare Microsoft365DSC per distribuire le modifiche di configurazione ai tenant Microsoft 365 tramite Azure Pipelines.
  • Windows PowerShell DSC è una piattaforma di gestione in PowerShell. È possibile usarla per gestire l'infrastruttura di sviluppo usando una configurazione come modello di codice. Questo modello è la tecnologia sottostante usata da Microsoft365DSC.

Alternative

  • È possibile usare DSC in Automazione di Azure per archiviare le configurazioni DSC in una posizione centrale. Automazione di Azure può anche fornire report sulla conformità delle configurazioni del tenant con uno stato desiderato specificato.

  • Questa architettura usa Key Vault per archiviare i certificati usati per l'autenticazione nel tenant Microsoft 365. Key Vault offre scalabilità gestendo centralmente i certificati e fornendo supporto per carichi di lavoro che usano più certificati, ad esempio alcuni carichi di lavoro Exchange e SharePoint. In alternativa a Key Vault, per una pipeline con ambito limitato, è possibile usare le variabili della pipeline contrassegnate come segrete. Le variabili della pipeline possono ridurre la complessità delle risorse, ma in Azure Pipelines, l'approccio consigliato consiste nella gestione delle variabili segrete in Key Vault. Se si usano variabili della pipeline, limitare l'accesso a gruppi di variabili, ruotare i segreti e non scrivere segreti nei log o argomenti della riga di comando.

  • Usando una macchina virtuale (VM) di Azure per Windows e DSC, è possibile applicare e monitorare una configurazione ai tenant di Microsoft 365 che usano Microsoft365DSC. La macchina virtuale Azure Windows può usare Microsoft365DSC per rilevare la deviazione della configurazione. È possibile usare Azure gruppi di azioni per inviare messaggi di posta elettronica agli amministratori Microsoft 365 ogni volta che viene rilevata la deriva. Un gruppo di azioni Azure può anche eseguire un webhook per attivare un runbook Azure. Il runbook può generare un report di deviazione della configurazione all'interno di Microsoft 365 tenant.

  • Come soluzione alternativa, è possibile usare le API Gestione configurazione tenant (TCM), una soluzione ufficiale supportata Microsoft. Queste API disponibili a livello generale non sostituiscono completamente Microsoft365DSC, perché attualmente supportano snapshot di configurazione e rilevamento della deriva, non distribuzione o correzione. Microsoft365DSC rimane un progetto open source basato sulla community.

Dettagli dello scenario

Molte aziende impostano l'obiettivo di applicare le procedure DevOps alla gestione della configurazione del tenant Microsoft 365. L'adozione di DevOps per Microsoft 365 può causare i problemi comuni seguenti:

  • Configurazioni errate
  • Problemi con il rilevamento delle modifiche alla configurazione
  • Nessun processo di approvazione per le modifiche del tenant

Usare la soluzione descritta in questo articolo per automatizzare le modifiche apportate alle configurazioni dei tenant Microsoft 365 usando Azure DevOps e Microsoft365DSC. Microsoft365DSC è un modulo DSC di PowerShell . Usarlo per configurare e gestire Microsoft 365 tenant in uno stile DevOps reale che usa la configurazione come codice.

Potenziali casi d'uso

Questa soluzione consente di gestire Microsoft 365 configurazione del tenant in modo controllato e automatizzato usando strumenti e procedure DevOps. Microsoft365DSC può gestire centinaia di proprietà all'interno di Microsoft 365, ad esempio Exchange regole di trasporto, criteri delle app di Teams e impostazioni di condivisione SharePoint. Per un elenco completo ed esempi di configurazioni, vedere gli esempi nel repository Microsoft365DSC in GitHub.

Ecco alcuni scenari in cui è possibile usare Microsoft365DSC:

  • Usare strumenti e procedure DevOps in ambienti di sviluppo, test, accettazione e produzione.
  • Gestire più tenant dei clienti, ad esempio in uno scenario di provider di servizi gestiti.
  • Rilevare la deriva della conformità e della configurazione di vari carichi di lavoro Microsoft 365, ad esempio Exchange, Teams e SharePoint carichi di lavoro.
  • Eseguire la migrazione delle configurazioni da un tenant a un altro.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che è possibile usare per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Well-Architected Framework.

La maggior parte dei principianti di PowerShell DSC ha rilevato che ci vuole del tempo per imparare a usare questa piattaforma. Una conoscenza approfondita di PowerShell e dell'esperienza con la creazione di script semplifica questo processo.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'uso improprio dei dati e dei sistemi preziosi. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per la sicurezza.

Le entità servizio sono il metodo di autenticazione preferito per Microsoft365DSC. Le entità servizio evitano conflitti di autenticazione a più fattori intrinseci con l'autenticazione con nome utente/password. Le entità servizio eseguono anche l'autenticazione come identità di app dedicata senza superficie di accesso interattivo e supportano le autorizzazioni API con privilegi minimi con la gestione delle credenziali controllabile in Microsoft Entra ID.

I file MOF compilati possono contenere credenziali. Considerare i file MOF come artefatti sensibili: limitare l'accesso e la conservazione, non pubblicarli su larga scala e proteggere le password dei certificati o i segreti dell'applicazione che contengono.

Se si compila una soluzione Microsoft365DSC in Azure DevOps, è anche possibile sfruttare la sicurezza in Azure Pipelines e un processo di approvazione per proteggere la distribuzione nel tenant di produzione.

Ottimizzazione dei costi

L'ottimizzazione dei costi è incentrata sui modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per Ottimizzazione costi.

Per informazioni sui prezzi di Azure DevOps, vedere Prezzi per Azure DevOps. Se si incorpora Key Vault nella soluzione, vedere Prezzi di Key Vault.

È anche possibile usare il calcolatore prezzi Azure per stimare i costi per questa soluzione.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'eccellenza operativa.

Alcuni team operativi considerano Azure DevOps essere uno strumento per gli sviluppatori. Tuttavia, i team operativi possono anche trarre vantaggio dall'uso di Azure DevOps per le attività seguenti:

  • Archiviare gli script in un repository e aggiungere il controllo del codice sorgente e il controllo delle versioni.
  • Automatizzare la distribuzione degli script.
  • Usare bacheche per tenere traccia di attività e progetti.

L'uso di una configurazione come modello di codice non è un'attività monouso. Comporta un cambiamento nel modo di lavorare e un cambiamento fondamentale per tutti i membri del team. Anziché apportare modifiche manualmente, implementarle negli script e distribuirle automaticamente. Tutti i membri del team devono avere le competenze necessarie per affrontare questo cambiamento.

È possibile usare questa soluzione quando si lavora con più ambienti, più carichi di lavoro o più team. È possibile configurare il processo di convalida in modo che gli esperti debbano approvare ogni carico di lavoro. È anche possibile estendere la soluzione per la distribuzione in più tenant per scenari quali scenari di sviluppo, test, accettazione e produzione o per più organizzazioni.

Distribuire lo scenario

Per i passaggi dettagliati che illustrano come distribuire questo scenario, vedere il white paper Microsoft 365 DSC, Managing Microsoft 365 in true DevOps style with Microsoft365DSC and Azure DevOps.

Collaboratori

Microsoft mantiene questo articolo. I seguenti collaboratori hanno scritto questo articolo.

Autore principale:

  • Derek Smay | Architetto senior di soluzioni cloud

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

centro architetture e soluzioni Microsoft 365