Modificare un'architettura della zona di destinazione di Azure per soddisfare i requisiti in più posizioni

Le organizzazioni in molti settori sono soggette a requisiti normativi, tra cui residenza dei dati, sicurezza dei dati e requisiti di sovranità dei dati. Alcune organizzazioni devono rispettare normative in conflitto in più posizioni geografiche. In questo caso, è necessario modificare l'architettura della zona di destinazione di Azure in conformità a tutte le normative applicabili.

Ad esempio, potrebbero esserci due normative in conflitto, regolamento A e regolamento B. Il regolamento A potrebbe richiedere la residenza dei dati nel paese o nell'area A e la regolamentazione B potrebbe richiedere la residenza dei dati nel paese o nell'area B.

Tali conflitti normativi possono essere applicati a:

• Organizzazioni multinazionali, ad esempio multinazionali o organizzazioni non governative (ONG), che devono rispettare le normative locali nei paesi o nelle regioni in cui operano.

• Fornitori di software indipendenti (ISV) che forniscono soluzioni alle organizzazioni in più posizioni e la soluzione deve essere conforme alle normative locali in ogni località.

• ISV che forniscono soluzioni alle organizzazioni multinazionali che devono rispettare le normative locali di ogni paese o area geografica in cui operano.

Se è sufficiente soddisfare un singolo set di requisiti normativi, vedere Adattare l'architettura della zona di destinazione di Azure per soddisfare i requisiti.

Considerazioni sulle normative

I requisiti normativi sono in genere correlati alla protezione dei dati, alla residenza dei dati, ai trasferimenti di dati, all'isolamento o all'autorizzazione del personale. Questi requisiti possono essere in conflitto tra più posizioni geografiche. Ad esempio, una regolamentazione dell'Unione europea (UE) potrebbe richiedere la residenza dei dati in un paese dell'UE, mentre un regolamento del Regno Unito potrebbe richiedere la residenza dei dati nel Regno Unito.

Se le normative comportano controlli dei criteri in conflitto, è necessario modificare di conseguenza l'architettura della zona di destinazione di Azure e le assegnazioni di criteri. Per altre informazioni, vedere la sezione in questo articolo Scenari che richiedono modifiche.

Quando si applicano più normative, non è necessario modificare l'architettura della zona di destinazione di Azure se:

• Più normative richiedono assegnazioni di Criteri di Azure identiche.

• I controlli in un unico regolamento sono un superset di un altro regolamento. I controlli superset si applicano automaticamente a entrambe le normative.

• I controlli in più normative non si sovrappongono. Quando si implementano più set di controlli, una singola implementazione copre tutte le normative. Criteri di Azure assegnazioni sono complementari.

• Varie normative hanno diversi tipi di implementazione. Dal punto di vista normativo, non è importante quale implementazione si sceglie. Ad esempio, potrebbero esserci due normative con un modello di autorizzazione diverso, ma entrambi i modelli di autorizzazione sono accettabili. È possibile scegliere l'implementazione più adatta all'organizzazione.

Suggerimento

È consigliabile cercare di avere il minor numero possibile di assegnazioni di criteri ed eccezioni o esenzioni.

Considerazioni per gli ISV

Sono disponibili tre modelli di distribuzione per isv.

• Pure software as a Service (SaaS): l'ISV fornisce la soluzione come servizio.

• Distribuzione del cliente: il cliente distribuisce la soluzione nel proprio ambiente.

• SaaS a doppia distribuzione: questo modello combina il modello distribuito dal cliente e il modello SaaS puro.

In un modello SaaS puro, l'ISV è responsabile della gestione della conformità per conto del cliente. L'ISV deve dimostrare la conformità al cliente e potenzialmente ai revisori o alle autorità di regolamentazione. Se si usa il modello SaaS, l'architettura potrebbe essere soggetta a più normative in conflitto. L'ISV deve gestire la conformità per queste diverse normative. Per altre informazioni, vedere la sezione in questo articolo Scenari che richiedono modifiche.

In un modello distribuito dal cliente, il cliente è responsabile della gestione della conformità. Per questo modello, l'ISV non deve modificare le zone di destinazione. Tuttavia, la soluzione viene distribuita in una zona di destinazione distribuita dal cliente, inclusi i controlli dei criteri e i criteri personalizzati.

Suggerimento

Gli ISV possono indirizzare le iniziative dei criteri a requisiti di conformità specifici per testare una soluzione. Questa procedura consente di ridurre al minimo le probabilità di conflitti con i criteri usati dai clienti per soddisfare i requisiti di conformità.

In un modello SaaS a doppia distribuzione si applicano tutte le considerazioni per il modello SaaS distribuito dal cliente e puro.

Considerazioni per le organizzazioni multinazionali

Le organizzazioni multinazionali usano varie strutture per organizzare la governance IT.

• Struttura decentralizzata: le funzioni IT vengono regolate localmente in ogni posizione geografica.

• Struttura centralizzata: le funzioni IT sono regolate da una posizione centralizzata, in genere la sede centrale dell'organizzazione.

• Struttura ibrida: le funzioni IT globali vengono fornite centralmente, mentre le funzioni IT necessarie solo in locale sono regolate in ogni posizione geografica.

In uno scenario decentralizzato , il team IT locale è responsabile della gestione della conformità e può adattare di conseguenza la propria zona di destinazione.

In uno scenario centralizzato , il team IT centrale è responsabile della gestione della conformità e deve garantire che le soluzioni soddisfino i requisiti di conformità locali di tutte le posizioni geografiche in cui opera l'organizzazione multinazionale. I requisiti di conformità di varie posizioni geografiche possono essere in conflitto e potrebbe essere necessario modificare le zone di destinazione.

In uno scenario ibrido si applicano le considerazioni per gli scenari decentralizzati e centralizzati. L'organizzazione centralizzata fornisce soluzioni che le organizzazioni locali devono distribuire nel proprio ambiente. L'organizzazione centralizzata verifica anche che tali soluzioni vengano distribuite in tutte le zone di destinazione delle organizzazioni locali.

Scenari che richiedono modifiche

Potrebbe essere necessario modificare le zone di destinazione se sono presenti set di criteri in conflitto assegnati a varie distribuzioni. Potrebbero essere presenti più soluzioni o una singola soluzione che deve essere resa disponibile a diverse posizioni geografiche o classificazioni dei dati.

La quantità di modifica necessaria dipende dal livello di isolamento richiesto dalla normativa. Maggiore è il numero di condizioni che un regolamento ha, più la zona di destinazione deve essere modificata. Ad esempio, se le normative richiedono condizioni come il personale cancellato, vari provider di identità o directory, un'infrastruttura di gestione separata o un'infrastruttura di connettività separata, la zona di destinazione richiede una modifica completa. Se le normative richiedono solo che l'infrastruttura di applicazione e connettività sia isolata, la zona di destinazione richiede modifiche minime.

Tenant di Microsoft Entra

È consigliabile usare un singolo tenant di Microsoft Entra per la maggior parte degli scenari, inclusi scenari multinazionali. Tuttavia, esistono scenari in cui è possibile preferire o richiedere più tenant di Microsoft Entra, ad esempio:

• Se è necessario separare il tenant Microsoft Entra aziendale dal tenant SaaS Microsoft Entra per migliorare la sicurezza e creare limiti chiari tra il prodotto e le operazioni aziendali.

• Se si applicano normative in conflitto ed è necessario separare i tenant di Microsoft Entra per diversi regimi normativi. Ad esempio, le normative potrebbero avere requisiti di autorizzazione e nazionalità che richiedono un isolamento completo tra i tenant di Microsoft Entra o i requisiti di residenza dei dati che richiedono tenant separati. Gli scenari comuni includono un ISV che deve distribuire istanze isolate di una soluzione SaaS o un'organizzazione multinazionale che deve distribuire istanze isolate della stessa soluzione.

Quando si collabora tra più tenant di Microsoft Entra, è necessario pianificare attentamente sfide e esigenze significative. Creare solo il numero minimo di tenant di Microsoft Entra che è necessario soddisfare i requisiti operativi o normativi. È possibile usare i gruppi di gestione e il controllo degli accessi in base al ruolo di Azure per gestire l'accesso alle sottoscrizioni e alle risorse in un singolo tenant, come descritto nella sezione successiva.

Suggerimento

Il tenant di Microsoft Entra selezionato per la zona di destinazione non influisce sull'autenticazione a livello di applicazione. È comunque possibile usare altri provider di identità indipendentemente dal tenant scelto. Per i clienti e i clienti del settore pubblico in settori regolamentati, le identità degli utenti finali vengono in genere fornite quando si integra con un provider di identità approvato, ad esempio un provider di identità di proprietà del governo o certificato.

I diagrammi seguenti mostrano le opzioni che è possibile usare per organizzare i tenant di Microsoft Entra.

Suggerimento

Se sono presenti più tenant di Microsoft Entra per soddisfare i requisiti normativi, denominare i tenant in base alla posizione geografica anziché a normative specifiche, ad esempio contoso-ops-us.com nel diagramma di esempio.

Per altre informazioni, vedere Zone di destinazione di Azure e più tenant di Microsoft Entra e considerazioni ISV per le zone di destinazione di Azure.

Gruppi di gestione

Se non è necessario separare i tenant di Microsoft Entra per garantire un isolamento rigoroso, è consigliabile distribuire più zone di destinazione di Azure in un singolo tenant di Microsoft Entra. È possibile modificare la gerarchia dei gruppi di gestione per soddisfare i requisiti delle normative in conflitto.

È possibile distribuire un'architettura completa della zona di destinazione per ogni set di normative da separare. Questo modello richiede la quantità minima di personalizzazione e consente di sfruttare l'automazione esistente per la distribuzione.

Nota

Questo diagramma non mostra tutti i gruppi di gestione.

Condividere il gruppo di gestione della piattaforma

Se il regolamento consente, il gruppo di gestione della piattaforma può essere condiviso. È possibile creare gruppi di gestione separati nel gruppo di gestione della zona di destinazione per ogni set di normative da separare. È possibile assegnare i criteri appropriati a ognuno dei gruppi di gestione delle applicazioni. Le zone di destinazione dell'applicazione condividono i gruppi di gestione inclusi nel gruppo di gestione della piattaforma. Le risorse nei gruppi di gestione delle applicazioni possono anche essere separate dalla sottoscrizione o dal gruppo di risorse.

Questa gerarchia di gruppi di gestione è una progettazione semplice ed economica per isolare le applicazioni con normative in conflitto. Tuttavia, in questa progettazione, i gruppi di gestione della piattaforma per la connettività, l'identità/sicurezza e la gestione devono condividere lo stesso set di criteri. Potrebbero essere necessari set di criteri diversi per ogni gruppo di gestione della piattaforma se la regolamentazione impone restrizioni per la condivisione dell'infrastruttura di connettività, dei servizi di gestione delle identità, dei servizi di gestione delle chiavi o dell'infrastruttura da cui viene gestito l'intero ambiente.

Isolare identità e sicurezza

Se le normative impediscono di condividere l'infrastruttura di gestione delle identità e delle chiavi, è possibile dividere il gruppo di gestione della piattaforma. Mantenere i gruppi di gestione per la connettività e la gestione nel gruppo di gestione della piattaforma condivisa e avere un gruppo di gestione delle identità e della sicurezza associato a ogni set di normative.

Questa gerarchia dei gruppi di gestione è notevolmente più complessa di un gruppo di gestione della piattaforma completamente condiviso perché è necessario replicare parzialmente il gruppo di gestione della piattaforma. Per limitare la complessità, è possibile distribuire la gerarchia completa per ogni set di normative e l'ambiente condiviso e ignorare o eliminare i gruppi di gestione superflui.

Isolare la connettività

Molte normative hanno requisiti correlati all'elaborazione e all'archiviazione dei dati in una determinata posizione geografica, con pochi requisiti relativi al modo in cui gli utenti si connettono alle applicazioni. Per tali normative, è possibile condividere la gestione della connettività, come illustrato nell'architettura precedente. Potrebbero non esserci normative che richiedono la duplicazione dell'infrastruttura in più aree, ma potrebbe essere necessario per scopi di latenza. I criteri assegnati devono supportare la duplicazione dell'infrastruttura in più aree.

Quando le normative presentano requisiti di connettività in conflitto, è possibile creare un gruppo di gestione della connettività associato a ogni set di normative. Questa struttura è simile all'architettura precedente che associa i gruppi di gestione delle identità e della sicurezza a ogni set di normative.

Se le normative sono in conflitto per la connettività e anche l'identità e la sicurezza, è possibile usare la progettazione seguente.

Passaggi successivi

• Zone di destinazione di Azure e più tenant di Microsoft Entra
• Considerazioni isv per le zone di destinazione di Azure
• Microsoft Cloud Adoption Framework per Azure
• Id e residenza dei dati di Microsoft Entra
• Panoramica del pilastro per la sicurezza
• Consigli per la gestione delle identità e degli accessi
• Personalizzare l'architettura della zona di destinazione di Azure per soddisfare i requisiti