Approccio di test per le zone di destinazione di Azure

Alcune organizzazioni potrebbero voler testare le definizioni e le assegnazioni di Criteri di Azure, i ruoli personalizzati e le assegnazioni del controllo degli accessi in base al ruolo (RBAC) e così via della distribuzione della piattaforma delle landing zone di Azure. I test possono essere completati tramite l'automazione usando modelli di Azure Resource Manager (modelli arm), Terraform, Bicepo manualmente tramite il portale di Azure. Queste linee guida forniscono un approccio che può essere usato per testare le modifiche e il relativo impatto sulla distribuzione della piattaforma delle zone di destinazione di Azure.

Questo articolo può essere usato anche con le linee guida di automazione della piattaforma e area di progettazione critica di DevOps poiché è correlato alle attività e ai team delle funzioni centrali e PlatformOps. Inoltre, può essere combinato con le indicazioni in Adottare guardrail basati su criteri per le tecniche di implementazione delle modifiche ai criteri in una distribuzione di Azure landing zones.

Queste linee guida sono più adatte alle organizzazioni con processi di gestione delle modifiche affidabili che regolano le modifiche alla gerarchia dei gruppi di gestione di produzione. La gerarchia dei gruppi di gestione canary può essere usata in modo indipendente per creare e testare le distribuzioni prima di distribuirle nell'ambiente di produzione.

Definizione della piattaforma

Le zone di destinazione di Azure consentono di progettare e distribuire i componenti della piattaforma Azure necessari per consentire di costruire e rendere operative le zone di destinazione su larga scala.

Le risorse della piattaforma comprese nell'ambito di questo articolo e di questo approccio di test sono:

Scenari di esempio e risultati

Un esempio di questo scenario è un'organizzazione che vuole testare l'impatto e il risultato di nuovi Criteri di Azure per eseguire la governance delle risorse e delle impostazioni in tutte le zone di destinazione, in base al principio di progettazione della governance basata su criteri. L’organizzazione non vuole apportare questa modifica direttamente all'ambiente di produzione perché è preoccupata per l'impatto che potrebbe avere.

Usare l'ambiente canary per testare questa modifica della piattaforma consentirà all'organizzazione di implementare e valutare l'impatto e i risultati della modifica di Criteri di Azure. Questo processo garantisce che vengano soddisfatti i requisiti dell'organizzazione prima di implementare Criteri di Azure nell'ambiente di produzione.

Uno scenario simile potrebbe essere una modifica delle assegnazioni dei ruoli di Azure RBAC e delle appartenenze ai gruppi di Microsoft Entra. Potrebbe essere necessaria una forma di test prima che le modifiche vengano apportate nell'ambiente di produzione.

Figura 1: Gerarchia dei gruppi di gestione Canary.

Come illustrato nel diagramma, l'intera gerarchia del gruppo di gestione di produzione delle zone di destinazione di Azure viene duplicata in Tenant Root Group. Il nome canary viene aggiunto ai nomi visualizzati e agli ID dei gruppi di gestione. Gli ID del gruppo di gestione devono essere univoci all'interno di un singolo tenant Microsoft Entra. Nel tenant, gli ID dei gruppi di gestione sono considerati gli identificatori di riferimento, pertanto devono essere univoci all’interno del tenant. È possibile mantenere i nomi visualizzati del gruppo di gestione allineati alla gerarchia del gruppo di gestione di produzione. Aggiungere anche un elemento distintivo nei nomi visualizzati, in modo che gli utenti possano distinguere visivamente la gerarchia canary dall'ambiente di produzione quando esplorano l'albero dei gruppi di gestione.

La gerarchia del gruppo di gestione canary viene quindi usata per semplificare il test dei tipi di risorse seguenti:

• Gruppi di gestione
  • Posizionamento dell'abbonamento
• RBAC
  • Ruoli (predefiniti e personalizzati)
  • Assegnazioni
• Criteri di Azure
  • Definizioni (predefinite e personalizzate)
  • Iniziative, note anche come definizioni di set
  • Assegnazioni

Cosa accade se non si vuole distribuire la gerarchia del gruppo di gestione canary?

Se non si vuole implementare la gerarchia del gruppo di gestione canary, è possibile testare le risorse della piattaforma all'interno della gerarchia dell'ambiente di produzione utilizzando sottoscrizioni sandbox, come illustrato nel diagramma.

Figura 2: Gerarchia dei gruppi di gestione delle zone di destinazione di Azure che evidenziano sandbox.

Per testare Criteri di Azure e RBAC in questo scenario, è necessaria un'unica sottoscrizione di Azure con il ruolo RBAC Owner assegnato all'identità con cui si desidera eseguire il test, ad esempio account utente, entità servizio o identità del servizio gestito. Questa configurazione consente di creare, assegnare e correggere le definizioni e le assegnazioni di Criteri di Azure solo nell'ambito della sottoscrizione di sandbox.

Questo approccio in modalità sandbox può essere usato anche per testare RBAC all'interno della sottoscrizione, ad esempio se si sta sviluppando un nuovo ruolo RBAC personalizzato per assegnare le autorizzazioni per un caso d'uso specifico. Questo test può essere completamente eseguito nella sottoscrizione sandbox e testato prima di creare e assegnare ruoli più in alto nella gerarchia.

Un vantaggio di questo approccio è che le sottoscrizioni sandbox possono essere usate quando sono necessarie e quindi eliminate dall'ambiente.

Tuttavia, questo approccio non consente di eseguire test con l'ereditarietà di RBAC e dei criteri di Azure nella gerarchia dei gruppi di gestione.

Linee guida per l'implementazione

Di seguito sono riportate indicazioni su come implementare e usare la gerarchia del gruppo di gestione canary per le zone di destinazione di Azure insieme a una gerarchia dei gruppi di gestione delle zone di destinazione di Azure nell'ambiente di produzione.

1. Usare entità servizio (SPN) separate di Microsoft Entra o identità gestite (MI) a cui vengono concesse le autorizzazioni per l'ambiente di produzione pertinente o la gerarchia dei gruppi di gestione delle zone di destinazione di Azure nell'ambiente canary.
   • Queste indicazioni seguono il principio dei privilegi minimi (PoLP)
2. Usa cartelle separate all'interno di un repository Git, di branch o di repository per ospitare l'IaC per le distribuzioni delle landing zone di Azure nell'ambiente di produzione e nell'ambiente canary.
   • Uso delle entità servizio di Microsoft Entra (SPN) o delle identità gestite (MI) pertinenti nell’ambito delle pipeline CI/CD, in base alla gerarchia da distribuire.
3. Implementa i criteri dei branch Git o le misure di sicurezza nell'ambiente canary come già avviene per l'ambiente di produzione.
   • Prendere in considerazione la possibilità di ridurre il numero di responsabili dell’approvazione e di controlli per la risposta immediata agli errori dell'ambiente canary.
4. Usare le stesse azioni GitHub o Azure Pipelines che usano le variabili di ambiente per modificare la gerarchia da distribuire. Un'altra opzione è clonare le pipeline e modificare le impostazioni hard-coded per definire la gerarchia da distribuire.
   • L'uso di modelli DevOps di Azure Pipelines o modelli di flusso di lavoro di GitHub Actions consente di rispettare il principio Don't Repeat Yourself (DRY).
5. Disporre di un gruppo di sottoscrizioni canary in un account di fatturazione separato, ad esempio un account Enterprise Agreement (EA) o una sezione della fattura di Contratto del cliente Microsoft (MCA), che possano essere spostate all'interno della gerarchia del gruppo di gestione canary secondo necessità.
   • Potrebbe essere utile avere un set di risorse sempre distribuite nelle sottoscrizioni dell'ambiente canary per velocizzare i test e la convalida delle modifiche nell'ambiente canary.
6. Avere un set di architetture di esempio per i carichi di lavoro delle applicazioni da distribuire nelle sottoscrizioni canary dell'ambiente canary per testare le modifiche ad Criteri di Azure e a RBAC. Ciò consente di convalidare le modifiche prima di distribuire e promuovere le modifiche nell'ambiente di produzione.
   • Questi carichi di lavoro di esempio possono essere distribuiti usando gli stessi modelli IaC usati per distribuire i carichi di lavoro dell'applicazione di produzione. Ciò consente di garantire che l'ambiente canary sia sincronizzato con l'ambiente di produzione e che le modifiche di cui si sta testando siano valide e applicabili all'ambiente di produzione.
   • È consigliabile esaminare e aggiornare continuamente i carichi di lavoro di esempio per assicurarsi che siano pertinenti e aggiornati con l'architettura e i modelli di progettazione più recenti dell'organizzazione.
   • Se si forniscono architetture di riferimento ai team dell'applicazione, è consigliabile distribuirli anche nell'ambiente canary. In questo modo è possibile convalidare le modifiche rispetto alle architetture di riferimento e assicurarsi che siano applicabili all'ambiente di produzione.
7. Inviare tutti i log di attività di Azure per tutte le sottoscrizioni di Azure, comprese eventuali sottoscrizioni dell'ambiente canary, all'area di lavoro Log Analytics di Azure dell'ambiente di produzione, in base alle raccomandazioni di progettazione delle zone di destinazione di Azure.
   • In questo modo, i team responsabili della sicurezza e delle operazioni possono monitorare l'ambiente canary per individuare eventuali modifiche o problemi che potrebbero derivare dal test delle modifiche di Criteri di Azure e di RBAC nell'ambiente di produzione.

Uso di un singolo tenant di Microsoft Entra

Le considerazioni da tenere in considerazione quando si usa un singolo tenant di Microsoft Entra sono:

• L'uso di un singolo tenant segue le raccomandazioni di progettazione delle zone di destinazione di Azure per i tenant di Microsoft Entra.
  • In un singolo tenant di Microsoft Entra è possibile usare i diversi gruppi di Microsoft Entra sia per gli ambienti di produzione che per le zone di destinazione canary di Azure con gli stessi utenti assegnati alla gerarchia del gruppo di gestione pertinente.
• Aumento o duplicazione dei costi di licenza di Microsoft Entra ID a causa di identità multiple distribuite tra tenant Microsoft Entra diversi. Ciò è particolarmente rilevante per i clienti che usano le funzionalità P1 o P2 di Microsoft Entra ID.
• Le modifiche RBAC sono più complesse sia negli ambienti canary sia in quelli di produzione, poiché è probabile che utenti e gruppi non siano identici tra i due tenant di Microsoft Entra.
  • Si consideri che gli ID di utenti e gruppi non saranno gli stessi tra i tenant di Microsoft Entra, poiché sono univoci a livello globale.
• Riduce la complessità e il sovraccarico di gestione causati dalla gestione di più tenant di Microsoft Entra.
  • Gli utenti con privilegi che devono mantenere l'accesso e accedere a tenant separati per effettuare test potrebbero, ad esempio, apportare modifiche accidentali all'ambiente di produzione anziché all'ambiente canary.
• Riduce il rischio di drift della configurazione e di errori di distribuzione.
• Non richiede la creazione di procedure di sicurezza aggiuntive né di procedure break-glass o di accesso di emergenza.
• Riduce l'attrito e il tempo necessario per implementare le modifiche alla distribuzione delle zone di destinazione di Azure.

Passaggi successivi

Dopo aver predisposto un ambiente canary, è possibile iniziare a testare le modifiche ad Criteri di Azure e a RBAC prima di distribuirle nella gerarchia dei gruppi di gestione delle landing zone di Azure di produzione.

Dopo aver testato le modifiche ai Criteri di Azure nell'ambiente canary, è quindi possibile promuoverle nell'ambiente di produzione seguendo lo stesso approccio descritto nella guida Adottare guardrail basati su criteri. Questa operazione viene eseguita utilizzando la funzionalità della modalità di imposizione delle assegnazioni dei criteri. L'uso dell'approccio documentato in queste linee guida consente di procedere in una fase di test aggiuntiva prima di applicare Criteri di Azure nell'ambiente di produzione nel suo effetto desiderato, che consente di acquisire fiducia nelle modifiche apportate a Criteri di Azure.

È anche possibile esaminare gli ambienti sandbox per i team delle applicazioni da usare per lo sviluppo e il test dei carichi di lavoro. Si tratta di un concetto separato per l'ambiente canary e viene usato per fornire un ambiente sicuro per i team delle applicazioni per sviluppare e testare i carichi di lavoro prima di essere distribuiti nell'ambiente di produzione.