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 Azure rete WAN virtuale
• Zona di destinazione di Azure con hub e spoke tradizionali
• Base della zona di destinazione 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 true per garantire che una zona di destinazione (sottoscrizione di Azure) soddisfi i requisiti di conformità e dell'ambiente previsti in un ambito specifico. Alcuni esempi:

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

Prendere in considerazione ogni gruppo di gestione nella gerarchia delle risorse come contributo all'output archetipo finale della zona di destinazione a causa del funzionamento dell'ereditarietà dei criteri 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 del framework usato per implementare ogni archetipo della zona di destinazione nell'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 il set risultante di assegnazioni Criteri di Azure e di controllo di accesso (IAM) ereditate, applicate e applicate a tale zona di destinazione specifica (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 un'area di lavoro Log Analytics.
• Impostazioni di esportazione continua per Microsoft Defender per il 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).

Nota

Nelle implementazioni di riferimento della zona di destinazione di Azure i criteri di Azure con gli DeployIfNotExists effetti e Modifyvengono usati per ottenere la distribuzione di alcune delle risorse precedenti. Seguono il principio di progettazione della governance basata su criteri.

Per altre informazioni, vedere Adottare protezioni guidate dai criteri.

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.

Suggerimento

Per esaminare gli archetipi della zona di destinazione nell'acceleratore di zona di destinazione di Azure, vedere Gruppi di gestione nell'acceleratore di zona di destinazione di Azure.

È 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:

Archetipo della zona di destinazione (gruppo di gestione)	Scopo o uso
Corp	Gruppo di gestione dedicato per le zone di destinazione aziendali. Questo gruppo è riservato a carichi di lavoro che richiedono una connettività o connettività ibrida con la rete aziendale tramite l'hub nella sottoscrizione di connettività.
Online	Gruppo di gestione dedicato per le zone di destinazione online. Questo gruppo è riservato a carichi di lavoro che potrebbero richiedere una connettività internet diretta in ingresso/uscita o per carichi di lavoro che potrebbero non richiedere una rete virtuale.
Sandbox	Gruppo di gestione dedicato per le sottoscrizioni che verrà usato solo per il test e l'esplorazione da parte di un'organizzazione. Queste sottoscrizioni verranno disconnesse in modo sicuro dalle zone di destinazione aziendali e online. Le sandbox hanno anche un set meno restrittivo di criteri assegnati per abilitare il test, l'esplorazione e la configurazione di servizi di Azure.

Scenari in cui potrebbe essere necessaria la personalizzazioni

Come accennato, vengono forniti archetipi comuni della zona di destinazione nell'architettura concettuale della zona di destinazione 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 blu sotto il gruppo di gestione Zone di destinazione. È 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 Microsoft Defender per il 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 Cloud for Sovranità, che aggiunge gruppi di gestione per il confidential compute ed è allineato per l'uso nei settori regolamentati. Microsoft Cloud for Sovranità fornisce strumenti, linee guida e protezioni per l'adozione del cloud pubblico con controlli di sovranità appropriati.

Suggerimento

È necessario sapere cosa considerare e cosa accade quando si spostano le sottoscrizioni di Azure tra gruppi di gestione in relazione al controllo degli accessi in base al ruolo e Criteri di Azure. Per altre informazioni, vedere Eseguire la transizione di ambienti di Azure esistenti all'architettura concettuale della zona di destinazione di Azure.

Archetipi della zona di destinazione della piattaforma su misura

È 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, potrebbe essere disponibile un team SOC dedicato che richiede il proprio archetipo per ospitare i carichi di lavoro. Questi carichi di lavoro devono soddisfare i requisiti di assegnazione di Criteri di Azure e controllo degli accessi in base al ruolo diversi da quelli del gruppo di gestione gestione.

Creare un nuovo gruppo di gestione della sicurezza sotto il gruppo di gestione Piattaforma nella gerarchia. È possibile assegnare le assegnazioni di Criteri di Azure e 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 personalatura 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.

• Provare sempre a creare gli archetipi e la 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 proviene da un ambiente brownfield o si sta cercando un approccio per ospitare le sottoscrizioni nel gruppo di gestione delle zone di destinazione con criteri in modalità di imposizione "solo controllo", vedere Scenario: Transizione di un ambiente duplicando un gruppo di gestione della zona di destinazione