Personalizzare l'architettura della zona di destinazione di Azure per soddisfare i requisiti

Come parte delle linee guida per la zona di destinazione di Azure, sono disponibili diverse opzioni di implementazione di riferimento:

• Zona di destinazione di Azure con la rete WAN virtuale di Azure
• Zona di destinazione di Azure con hub e spoke tradizionali
• Fondazione della landing zone di Azure
• Zona di destinazione di Azure per piccole imprese

Queste opzioni consentono all'organizzazione di iniziare rapidamente usando le configurazioni che offrono l'architettura concettuale della zona di destinazione di Azure e le procedure consigliate nelle aree di progettazione.

Le implementazioni di riferimento si basano sulle procedure consigliate e sull'apprendimento dei team Microsoft dagli impegni con clienti e partner. Questa conoscenza rappresenta il lato "80" della regola 80/20. Le varie implementazioni prendono posizioni sulle decisioni tecniche che fanno parte del processo di progettazione dell'architettura.

Poiché non tutti i casi d'uso sono gli stessi, non tutte le organizzazioni possono usare un approccio di implementazione esattamente come previsto. È necessario comprendere le considerazioni quando viene identificato un requisito per la personalizzazioni.

Che cos'è un archetipo di zona di destinazione nelle zone di destinazione di Azure?

Un archetipo di zona di destinazione descrive cosa deve essere vero per garantire che una zona di destinazione (sottoscrizione di Azure) soddisfi i requisiti dell'ambiente e di conformità previsti in un ambito specifico. Gli esempi includono:

• Assegnazioni di Criteri di Azure.
• Assegnazioni di controllo degli accessi in base al ruolo.
• Risorse gestite centralmente, ad esempio la rete.

Prendere in considerazione ciascun gruppo di gestione nella gerarchia delle risorse come contributo alla definizione dell'output archetipico finale della zona di destinazione per il modo in cui funziona l'ereditarietà delle regole in Azure. Quando si progettano i livelli inferiori, considerare ciò che viene applicato ai livelli superiori della gerarchia di risorse.

Esiste una stretta relazione tra i gruppi di gestione e gli archetipi della zona di destinazione, ma un gruppo di gestione da solo non è un archetipo della zona di destinazione. Fa invece parte dell'infrastruttura utilizzata per implementare ciascun tipo di zona di atterraggio nel tuo ambiente.

È possibile visualizzare questa relazione nell'architettura concettuale della zona di destinazione di Azure. Le assegnazioni di criteri vengono create nel gruppo di gestione radice intermedio, ad esempio Contoso, per le impostazioni che devono essere applicate a tutti i carichi di lavoro. Vengono create più assegnazioni di criteri a livelli inferiori della gerarchia per requisiti più specifici.

Il posizionamento delle sottoscrizioni all'interno della gerarchia dei gruppi di gestione determina l'insieme risultante di assegnazioni di Criteri di Azure e di controllo di accesso (IAM) che vengono ereditate, applicate e imposte a quella specifica zona di approdo (sottoscrizione di Azure).

Potrebbero essere necessari più processi e strumenti per garantire che una zona di destinazione disponga delle risorse gestite centralmente necessarie. Alcuni esempi includono:

• Impostazioni di diagnostica per inviare i dati del log attività a uno spazio di lavoro di Log Analytics.
• Impostazioni di esportazione continua per Microsoft Defender for Cloud.
• Rete virtuale con spazi di indirizzi IP gestiti per i carichi di lavoro dell'applicazione.
• Collegamento di reti virtuali a una protezione DDoS (Distributed Denial of Service).

Archetipi predefiniti per l'architettura concettuale della zona di destinazione di Azure

L'architettura concettuale include archetipi di zona di destinazione di esempio per carichi di lavoro dell'applicazione, ad esempio corp e online. Questi archetipi possono essere applicati all'organizzazione e soddisfare i requisiti. È possibile apportare modifiche a questi archetipi o crearne di nuovi. La decisione dipende dalle esigenze e dai requisiti dell'organizzazione.

È anche possibile creare modifiche altrove nella gerarchia delle risorse. Quando si pianifica la gerarchia per l'implementazione delle zone di destinazione di Azure per l'organizzazione, seguire le linee guida nelle aree di progettazione.

Gli esempi di archetipo della zona di destinazione seguenti dell'architettura concettuale consentono di comprendere lo scopo e l'uso previsto:

Scenari in cui potrebbe essere necessaria la personalizzazioni

Come accennato, vengono forniti archetipi comuni della zona di atterraggio nell'architettura concettuale di Azure. Sono corp e online. Questi archetipi non sono fissi e non sono gli unici archetipi di zona di destinazione consentiti per i carichi di lavoro dell'applicazione. Potrebbe essere necessario personalizzare gli archetipi della zona di destinazione in base alle esigenze e ai requisiti.

Prima di personalizzare gli archetipi della zona di destinazione, è importante comprendere i concetti e visualizzare anche l'area della gerarchia che è consigliabile personalizzare. Il diagramma seguente mostra la gerarchia predefinita dell'architettura concettuale della zona di destinazione di Azure.

Vengono evidenziate due aree della gerarchia. Uno è sotto le zone di destinazione e l'altro è sotto piattaforma.

Adattare gli archetipi della zona di destinazione dell'applicazione

Si noti l'area evidenziata in verde sotto il gruppo di gestione Landing Zones. È il posto più comune e più sicuro nella gerarchia per aggiungere più archetipi per soddisfare nuovi o più requisiti che non possono essere aggiunti come più assegnazioni di criteri a un archetipo esistente usando la gerarchia esistente.

Ad esempio, potrebbe essere necessario ospitare un set di carichi di lavoro dell'applicazione che devono soddisfare i requisiti di conformità PCI (Payment Card Industry). Tuttavia, questo nuovo requisito non deve essere applicato a tutti i carichi di lavoro nell'intero ambiente.

Esiste un modo semplice e sicuro per soddisfare questo nuovo requisito. Creare un nuovo gruppo di gestione denominato PCI sotto il gruppo di gestione Zone di destinazione nella gerarchia. È possibile assegnare altri criteri come l'iniziativa dei criteri di conformità alle normative di Microsoft Defender for Cloud per PCI v3.2.1:2018 al nuovo gruppo di gestione PCI . Questa azione costituisce un nuovo archetipo.

È ora possibile inserire sottoscrizioni di Azure nuove o spostare le sottoscrizioni di Azure esistenti nel nuovo gruppo di gestione PCI per renderlo ereditare i criteri necessari e formare il nuovo archetipo.

Un altro esempio è Microsoft Sovereign Cloud, che aggiunge gruppi di gestione per il confidential compute ed è allineato per l'uso nei settori regolamentati. Microsoft Sovereign Cloud fornisce strumenti, linee guida e protezioni per l'adozione del cloud pubblico con controlli di sovranità appropriati.

Archetipi personalizzati della zona di approdo della piattaforma

È anche possibile personalizzare l'area evidenziata in arancione sotto il gruppo di gestione della piattaforma . Le zone in questa area sono note come zone di destinazione della piattaforma.

Ad esempio, potresti avere un team SOC dedicato che richiede il proprio archetipo per ospitare i carichi di lavoro. Questi carichi di lavoro devono soddisfare requisiti di assegnazione di Criteri di Azure e controllo di accesso in base al ruolo diversi da quelli del gruppo di gestione Management.

Creare un nuovo gruppo di gestione della sicurezza sotto il gruppo di gestione Piattaforma nella gerarchia. È possibile assegnare i criteri di Azure e le assegnazioni di controllo degli accessi in base al ruolo necessarie.

Ora è possibile inserire sottoscrizioni di Azure nuove o spostare le sottoscrizioni di Azure esistenti nel nuovo gruppo di gestione della sicurezza per renderlo ereditare i criteri necessari e formare il nuovo archetipo.

Esempio di gerarchia della zona di destinazione di Azure personalizzata

Il diagramma seguente illustra una gerarchia personalizzata della zona di destinazione di Azure. Usa esempi del diagramma precedente.

Elementi da considerare:

Quando si pensa di personalizzare l'implementazione degli archetipi della zona di destinazione di Azure nella gerarchia, tenere presente quanto segue:

• La personalizzazione della gerarchia non è obbligatoria. Gli archetipi e la gerarchia predefiniti forniti sono adatti per la maggior parte degli scenari.

• Non ricreare la gerarchia organizzativa, i team o i reparti in archetipi.

• Cercare sempre di costruire sugli archetipi e sulla gerarchia esistenti per soddisfare nuovi requisiti.

• Crea nuovi archetipi solo quando sono veramente necessari.

  Ad esempio, un nuovo requisito di conformità come PCI è necessario solo per un subset di carichi di lavoro dell'applicazione e non deve essere applicato a tutti i carichi di lavoro.

• Creare nuovi archetipi solo nelle aree evidenziate mostrate nei diagrammi precedenti.

• Evitare di andare oltre una profondità gerarchia di quattro livelli per evitare complessità e esclusioni non necessarie. Espandere archetipi orizzontalmente anziché verticalmente nella gerarchia.

• Non creare archetipi per ambienti come sviluppo, test e produzione.

  Per altre informazioni, vedere Come si gestiscono le zone di destinazione del carico di lavoro di sviluppo/test/produzione nell'architettura concettuale delle zone di destinazione di Azure?

• Se si proviene da un ambiente brownfield o si sta cercando un approccio per ospitare le sottoscrizioni nel gruppo di gestione delle landing zone con criteri in modalità di applicazione "solo verifica", vedere Scenario: Transizione di un ambiente duplicando un gruppo di gestione delle landing zone