Approccio di test per le zone di destinazione di Azure
Nota
Questo articolo si applica solo a Microsoft Azure e non ad altre offerte di Microsoft Cloud, ad esempio Microsoft 365 o Microsoft Dynamics 365.
Alcune organizzazioni potrebbero voler testare la distribuzione della piattaforma delle zone di destinazione di Azure per le definizioni e le assegnazioni di Criteri di Azure, i ruoli e le assegnazioni personalizzati del controllo degli accessi in base al ruolo e così via. I test possono essere completati tramite l'automazione usando i modelli di Azure Resource Manager (modelli arm), AzOps, Terraform, Bicep o manualmente tramite il portale di Azure. Queste linee guida forniscono un approccio che può essere usato per testare le modifiche e il loro impatto in una 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.
Queste linee guida sono particolarmente adatte alle organizzazioni con solidi processi di gestione delle modifiche che eseguono la governance delle modifiche alla gerarchia dei gruppi di gestione dell'ambiente 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.
Nota
Il termine canary viene usato per evitare confusione con gli ambienti di sviluppo o di test. Questo nome viene usato solo a scopo illustrativo. È possibile definire qualsiasi nome ritenuto appropriato per l'ambiente di zone di destinazione canary di Azure.
Analogamente, il termine ambiente di produzione viene usato in queste linee guida per fare riferimento alla gerarchia dei gruppi di gestione di cui l'organizzazione dispone e che contiene le sottoscrizioni e le risorse di Azure per i carichi di lavoro.
Definizione della piattaforma
Importante
Queste linee guida non sono valide per gli ambienti di sviluppo o di test che verranno usati dai proprietari di applicazioni o servizi noti come zone di destinazione, carichi di lavoro, applicazioni o servizi. Questi vengono inseriti e gestiti all'interno della gerarchia dei gruppi di gestione dell'ambiente di produzione e della governance associata (controllo degli accessi in base al ruolo e Criteri di Azure).
Queste linee guida sono destinate solo ai test a livello di piattaforma e alle modifiche nel contesto delle zone di destinazione di Azure.
La scala aziendale consente di progettare e distribuire i componenti della piattaforma Azure necessari per costruire e gestire zone di destinazione su larga scala.
Le risorse della piattaforma comprese nell'ambito di questo articolo e di questo approccio di test sono:
| Prodotto o servizio | Tipo e provider di risorse |
|---|---|
| Gruppi di gestione | Microsoft.Management/managementGroups |
| Associazione di sottoscrizioni dei gruppi di gestione | Microsoft.Management/managementGroups/subscriptions |
| Definizioni dei criteri | Microsoft.Authorization/policyDefinitions |
| Definizioni di iniziative di criteri o definizioni di set di criteri | Microsoft.Authorization/policySetDefinitions |
| Assegnazioni di criteri | Microsoft.Authorization/policyAssignments |
| Definizioni del ruolo Controllo degli accessi in base al ruolo | Microsoft.Authorization/roleDefinitions |
| Assegnazioni del ruolo Controllo degli accessi in base al ruolo | Microsoft.Authorization/roleAssignments |
| Sottoscrizioni | Microsoft.Subscription/aliases |
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.
L'uso dell'ambiente canary per testare questa modifica della piattaforma consentirà all'organizzazione di implementare ed esaminare l'impatto e il risultato della modifica a 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 alle assegnazioni di ruolo del controllo degli accessi in base al ruolo di Azure e alle appartenenze ai gruppi di Microsoft Entra. Potrebbe essere necessaria una forma di test prima che le modifiche vengano apportate nell'ambiente di produzione.
Importante
Non si tratta di un approccio o di un modello di distribuzione comune per la maggior parte dei clienti. Non è obbligatorio per le distribuzioni di zone di destinazione di Azure.
Figura 1: Gerarchia dei gruppi di gestione canary.
Come illustrato nel diagramma, l'intera gerarchia del gruppo di gestione dell'ambiente 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 devono essere univoci all'interno di un singolo tenant di Microsoft Entra.
Nota
I nomi visualizzati dei gruppi di gestione dell'ambiente di produzione canary possono essere gli stessi dei nomi visualizzati dei gruppi di gestione dell'ambiente di produzione. Ciò potrebbe generare confusione per gli utenti. Per questo, è consigliabile aggiungere il nome "canary" ai nomi visualizzati, nonché ai relativi ID.
La gerarchia dei gruppi di gestione dell'ambiente canary viene quindi usata per semplificare il test dei seguenti tipi di risorse:
- Gruppi di gestione
- Selezione delle sottoscrizioni
- RBAC
- Ruoli (predefiniti e personalizzati)
- Attività
- Criteri di Azure
- Definizioni (predefinite e personalizzate)
- Iniziative, note anche come definizioni di set
- Attività
Cosa fare se non si vuole distribuire l'intera gerarchia dei gruppi di gestione dell'ambiente canary?
Se non si vuole distribuire l'intera gerarchia del gruppo di gestione dell'ambiente canary, è possibile testare le risorse della piattaforma all'interno della gerarchia dell'ambiente di produzione usando sottoscrizioni sandbox come illustrato nel diagramma.
Figura 2: Gerarchia dei gruppi di gestione su scala aziendale che evidenzia le sandbox.
Per testare Criteri di Azure e il controllo degli accessi in base al ruolo in questo scenario, è necessaria una singola sottoscrizione di Azure con il ruolo Controllo degli accessi in base al ruolo di Proprietario assegnato all'identità con cui si vuole completare il test, ad esempio Account utente, Entità servizio o Identità del servizio gestito. Questa configurazione consente di creare, assegnare e correggere le definizioni e assegnazioni di Criteri di Azure solo nell'ambito della sottoscrizione sandbox.
Questo approccio sandbox può essere usato anche per i test del controllo degli accessi in base al ruolo all'interno della sottoscrizione, ad esempio se si sviluppa un nuovo ruolo Controllo degli accessi in base al ruolo personalizzato per concedere 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 testare l'ereditarietà del controllo degli accessi in base al ruolo e dei criteri di Azure dalla gerarchia dei gruppi di gestione.
Uso di un singolo tenant di Microsoft Entra
Le considerazioni da tenere in considerazione quando si usa un singolo tenant di Microsoft Entra sono:
- Segue le raccomandazioni di progettazione su scala aziendale per i tenant di Microsoft Entra.
- In base alle procedure consigliate di Azure per Cloud Adoption Framework, standardizzare in una singola directory e indicazioni sulle identità , i singoli tenant di Microsoft Entra sono le procedure consigliate per la maggior parte.
- In un singolo tenant di Microsoft Entra è possibile usare i diversi gruppi di Microsoft Entra sia per gli ambienti di produzione che per gli ambienti canary di destinazione di Azure, con gli stessi utenti, assegnati alla gerarchia del gruppo di gestione pertinente all'interno dello stesso tenant di Microsoft Entra.
- Costi di licenza di Microsoft Entra ID aumentati o duplicati a causa di più identità nei diversi tenant di Microsoft Entra.
- Questo punto è particolarmente rilevante per i clienti che usano le funzionalità P1 o P2 di Microsoft Entra ID.
- Le modifiche del controllo degli accessi in base al ruolo saranno più complesse sia negli ambienti canary che negli ambienti di produzione, perché è probabile che gli utenti e i gruppi non siano identici in entrambi i tenant di Microsoft Entra.
- Inoltre, gli ID utenti e gruppi non saranno gli stessi nei tenant di Microsoft Entra perché 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 eseguire i test per errore potrebbero apportare modifiche all'ambiente di produzione anziché apportarle all'ambiente canary e viceversa.
- Riduce la probabilità di errori di distribuzione e deriva di configurazione.
- Non richiede la creazione di processi di sicurezza e di accesso di emergenza aggiuntivi.
- Riduce l'attrito e il tempo necessario per implementare le modifiche alla distribuzione delle zone di destinazione di Azure.
Linee guida per l'implementazione
Di seguito sono riportate indicazioni su come implementare e usare la gerarchia dei gruppi di gestione canary per le zone di destinazione di Azure insieme a una gerarchia di gruppi di gestione dell'ambiente di produzione.
Avviso
Se si usa il portale per distribuire e gestire l'ambiente delle zone di destinazione di Azure, potrebbe essere difficile adottare e usare l'approccio canary in modo efficiente a causa di un rischio elevato sia per gli ambienti di produzione che per gli ambienti canary che per ottenere una sincronizzazione non sincronizzata spesso e pertanto non fornire una gerarchia e un ambiente di produzione simili a una replica.
Valutare la possibilità di passare a un approccio di distribuzione infrastruttura distribuita come codice per le zone di destinazione di Azure, come illustrato in precedenza, se si è in questo scenario. Oppure essere consapevoli dei potenziali rischi di deviazione della configurazione tra canary e produzione e procedere con cura.
- Usare entità servizio (SPN) separate di Microsoft Entra o identità del servizio gestite (MSI) concesse per l'ambiente di produzione pertinente o la gerarchia del gruppo di gestione dell'ambiente canary.
- Queste indicazioni seguono il principio dei privilegi minimi (PoLP)
- Usare cartelle separate all'interno di un repository Git, rami o repository per contenere l'infrastruttura come codice per le distribuzioni dell'ambiente di produzione e delle zone di destinazione canary di Azure.
- Uso delle entità servizio (SPN) o delle identità del servizio gestite (MSI) pertinenti come parte delle pipeline CI/CD a seconda della gerarchia da distribuire.
- Implementare i criteri o la sicurezza dei rami Git per l'ambiente canary così come sono stati implementati 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.
- 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’utilizzo di modelli DevOps di Azure Pipelines o modelli di flussi di lavoro GitHub Actions consentirà di rispettare il principio Don't Repeat Yourself (DRY).
- Disporre di un set di sottoscrizioni canary in un account e reparto EA separato che può essere spostato nella gerarchia dei gruppi di gestione canary in base alle esigenze.
- Potrebbe essere vantaggioso avere un set di risorse distribuito sempre nelle sottoscrizioni dell'ambiente canary.
- Potrebbe essere utile avere modelli di infrastruttura come codice, ad esempio modelli di ARM, Bicep o Terraform, che creano un set di risorse che consentono la convalida delle modifiche nell'ambiente canary.
- Inviare tutti i log attività di Azure per tutte le sottoscrizioni di Azure, incluse le sottoscrizioni dell'ambiente canary, all'area di lavoro Log Analytics di Azure nell'ambiente di produzione in base alle raccomandazioni di progettazione delle zone di destinazione di Azure.
Suggerimento
Se sono già state distribuite zone di destinazione di Azure nell'ambiente di produzione e si sta cercando di aggiungere un ambiente canary. Prendere in considerazione la clonazione della distribuzione corrente della gerarchia dell'ambiente di produzione e modificare i nomi delle risorse in modo da anteporrli allo schema di denominazione canary.
Ciò consente di assicurarsi che ciò che si sta distribuendo per abilitare l'ambiente canary sia sincronizzato con la produzione dall'inizio. Ciò si ottiene facilmente quando si usa uno strumento Infrastructure-as-Code insieme a un repository Git.
Passaggi successivi
Informazioni su come implementare gli ambienti sandbox della zona di destinazione.