Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Strategizzazione per l'espansione globale

AWS Security Assurance Services riceve spesso domande sull'architettura per la privacy AWS durante l'espansione a livello globale. Le domande riguardano il mantenimento della conformità a requisiti specifici in materia di privacy, come gli obblighi di sovranità dei dati o i contratti con i clienti, il tutto evitando al contempo costi aggiuntivi e spese operative. Le considerazioni di progettazione spesso includono la residenza dei dati, la limitazione dell'accesso dell'operatore, la resilienza e la capacità di sopravvivenza e l'indipendenza generale. Per ulteriori informazioni, consulta Soddisfare i requisiti di sovranità digitale su (presentazione re:Invent 2022). AWSAWS

Le seguenti domande sono comuni e solo tu puoi rispondere in base al tuo caso d'uso:

Per quanto riguarda i requisiti di residenza dei dati, implementazioni di architetture diverse potrebbero funzionare meglio per diverse organizzazioni. Alcune organizzazioni potrebbero richiedere che i dati personali dei propri clienti rimangano all'interno di una regione specifica. In tal caso, potresti essere preoccupato di come rispettare in generale le normative rispettando tali obblighi. Indipendentemente dalla situazione, quando si sceglie una strategia di implementazione con più account ci sono diverse considerazioni.

Per definire i componenti chiave della progettazione dell'architettura, collaborate a stretto contatto con i team addetti alla conformità e ai contratti per confermare i requisiti relativi a dove, quando e come i dati personali possono essere incrociati. Regioni AWS Determina cosa si qualifica come trasferimento dei dati, ad esempio spostamento, copia o visualizzazione. Inoltre, scopri se è necessario implementare controlli specifici di resilienza e protezione dei dati. Le strategie di backup e disaster recovery richiedono un failover interregionale? In tal caso, stabilite quali regioni potete utilizzare per archiviare i dati di backup. Determina se esistono requisiti per la crittografia dei dati, come un algoritmo di crittografia specifico o moduli di sicurezza hardware dedicati per la generazione di chiavi. Dopo aver consultato le parti interessate alla conformità su questi argomenti, iniziate a prendere in considerazione gli approcci di progettazione per il vostro ambiente multi-account.

È inoltre importante ricordare che la conformità alla privacy potrebbe non limitarsi alla sola sovranità dei dati. Consulta il resto di questa guida per comprendere le possibili soluzioni a molte altre sfide, come la gestione del consenso, le richieste degli interessati, la governance dei dati e i pregiudizi in materia di intelligenza artificiale.

landing zone centrale con regioni gestite

Se desideri espanderti a livello globale ma hai già stabilito un'architettura multi-account in AWS, è normale voler utilizzare la stessa landing zone multi-account (MALZ) per gestirne altri. Regioni AWS In questa configurazione, continuerai a gestire i servizi di infrastruttura come logging, account factory e amministrazione generale dalla AWS Control Tower landing zone esistente, nella regione in cui l'hai creata.

Per i carichi di lavoro di produzione, puoi gestire implementazioni regionali estendendo la AWS Control Tower landing zone in una nuova regione. In questo modo, è possibile estendere la AWS Control Tower governance alla nuova regione. In questo modo, puoi conservare gli archivi dei dati personali all'interno di una regione specifica e gestita, i dati risiedono ancora in account che beneficiano dei servizi e della AWS Control Tower governance dell'infrastruttura. Nel frattempo AWS Organizations, gli account che contengono dati personali continuano a essere raggruppati in un'unità organizzativa dedicata alla gestione dei dati personali, in cui sono implementate tutte le barriere in materia di sovranità dei dati. AWS Control Tower Inoltre, i carichi di lavoro specifici per regione sono contenuti in account dedicati, anziché creare account di produzione che possono contenere lo stesso carico di lavoro in più regioni.

Questa implementazione può essere la più conveniente in termini di costi, ma sono necessarie ulteriori considerazioni per controllare il flusso di dati personali attraverso Account AWS i confini regionali. Considera i seguenti aspetti:

Il diagramma seguente mostra una landing zone centralizzata con schieramenti regionali.

Zone di atterraggio regionali

Avere più di un MALZ può aiutarti a raggiungere requisiti di conformità più severi isolando completamente i carichi di lavoro che elaborano dati personali rispetto ai carichi di lavoro non materiali. AWS Control Tower l'aggregazione centralizzata dei log potrebbe essere configurata di default e quindi semplificata. Con questo approccio, non è necessario mantenere eccezioni per la registrazione con flussi di log separati che richiedono la redazione. Potresti anche avere un team operativo cloud locale e dedicato per ogni MALZ, il che limita l'accesso degli operatori alla residenza locale.

Molte organizzazioni hanno implementato landing zone separate negli Stati Uniti e nell'UE. Ogni landing zone regionale ha un unico sistema di sicurezza generale e una governance associata per i conti della regione. Ad esempio, la crittografia dei dati personali utilizzando un programma MALZ dedicato HSMs potrebbe non essere richiesta nei carichi di lavoro di una MALZ, ma potrebbe essere richiesta in un'altra MALZ.

Sebbene questa strategia sia scalabile per soddisfare molti requisiti attuali e futuri, è importante comprendere i costi aggiuntivi e le spese operative associati alla manutenzione di più MALZs sistemi. Per ulteriori informazioni, consultare Prezzi di AWS Control Tower.

Il diagramma seguente mostra zone di atterraggio separate in due regioni.

AWS Sovereign Cloud europeo

Alcune organizzazioni richiedono una separazione completa dei carichi di lavoro che operano nello Spazio economico europeo (SEE) e dei carichi di lavoro che operano altrove. In questa situazione, prendete in considerazione l'AWS European Sovereign Cloud. AWS European Sovereign Cloud è un nuovo cloud indipendente per l'Europa, progettato per aiutare i clienti a soddisfare le esigenze di sovranità in evoluzione della regione, tra cui rigorosi requisiti di residenza dei dati, autonomia operativa e resilienza.

Lo AWS European Sovereign Cloud è fisicamente e logicamente separato da quello esistente Regioni AWS, offrendo al contempo la stessa sicurezza, disponibilità e prestazioni. Solo AWS i dipendenti che si trovano nell'UE hanno il controllo delle operazioni e del supporto per il Sovereign Cloud AWS europeo. Se hai requisiti rigorosi in materia di residenza dei dati, AWS European Sovereign Cloud conserva tutti i metadati che crei (come i ruoli, le autorizzazioni, le etichette delle risorse e le configurazioni che utilizzano per funzionare) nell'UE. AWS Lo AWS European Sovereign Cloud dispone anche di propri sistemi di misurazione della fatturazione e dell'utilizzo.

Per questo approccio, utilizzeresti uno schema simile a quello della sezione precedente, Zone di atterraggio regionali. Tuttavia, per i servizi forniti ai clienti europei, è possibile implementare un MALZ dedicato nel Sovereign Cloud AWS europeo.