Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Élaboration de stratégies pour une expansion mondiale
Sondage
Nous aimerions avoir de vos nouvelles. Veuillez nous faire part de vos commentaires sur le AWS PRA en répondant à un court sondage
AWS
Les services d'assurance de sécurité
Les questions suivantes sont courantes et vous êtes le seul à pouvoir y répondre pour votre cas d'utilisation :
-
Où doivent se trouver les données personnelles de mes clients ?
-
Où sont stockées les données de mes clients ?
-
Comment et où les données personnelles peuvent-elles traverser les frontières ?
-
L'accès des personnes ou des services aux données entre les régions constitue-t-il un transfert ?
-
Comment puis-je m'assurer qu'aucun gouvernement étranger n'accède aux données personnelles de mes clients ?
-
Où puis-je stocker mes sauvegardes et mes sites chauds ou froids ?
-
Pour conserver les données locales, dois-je créer une zone d' AWS atterrissage dans chaque région où je fournis des services ? Ou puis-je utiliser une zone d' AWS Control Tower atterrissage existante ?
En ce qui concerne les exigences relatives à la résidence des données, les différents déploiements d'architecture peuvent mieux fonctionner pour différentes organisations. Certaines organisations peuvent exiger que les données personnelles de leurs clients restent dans une région spécifique. Si tel est le cas, vous vous demandez peut-être comment vous conformer aux réglementations en général tout en respectant ces obligations. Quelle que soit la situation, plusieurs facteurs doivent être pris en compte lors du choix d'une stratégie de déploiement multi-comptes.
Pour définir les composants clés de la conception de l'architecture, travaillez en étroite collaboration avec vos équipes chargées de la conformité et des contrats afin de confirmer les exigences relatives au lieu, au moment et à la manière dont les données personnelles peuvent être croisées Régions AWS. Déterminez ce qui est considéré comme un transfert de données, tel que le déplacement, la copie ou l'affichage. En outre, déterminez si des contrôles spécifiques de résilience et de protection des données doivent être mis en œuvre. Les stratégies de sauvegarde et de reprise après sinistre nécessitent-elles un basculement entre régions ? Dans ce cas, déterminez les régions que vous pouvez utiliser pour stocker vos données de sauvegarde. Déterminez s'il existe des exigences en matière de chiffrement des données, telles qu'un algorithme de chiffrement spécifique ou des modules de sécurité matériels dédiés pour la génération de clés. Après avoir consulté les parties prenantes en matière de conformité sur ces sujets, commencez à envisager des approches de conception pour votre environnement multi-comptes.
Voici trois approches que vous pouvez utiliser pour planifier votre stratégie AWS multi-comptes, par ordre croissant de ségrégation des infrastructures :
Il est également important de se rappeler que le respect de la vie privée ne se limite pas à la souveraineté des données. Consultez le reste de ce guide pour comprendre les solutions possibles à de nombreux autres défis, tels que la gestion du consentement, les demandes des personnes concernées, la gouvernance des données et les biais liés à l'IA.
Zone d'atterrissage centrale avec régions gérées
Si vous souhaitez vous développer à l'échelle mondiale mais que vous avez déjà établi une architecture multi-comptes AWS, il est courant de vouloir utiliser la même zone d'atterrissage multi-comptes (MALZ) pour en gérer d'autres. Régions AWS Dans cette configuration, vous continueriez à exploiter les services d'infrastructure tels que la journalisation, l'usine de comptes et l'administration générale à partir de votre zone de AWS Control Tower landing zone existante, dans la région où vous l'avez créée.
Pour les charges de travail de production, vous pouvez effectuer des déploiements régionaux en étendant la zone AWS Control Tower d'atterrissage à une nouvelle région. Ce faisant, vous pouvez étendre la AWS Control Tower gouvernance à la nouvelle région. De cette façon, vous pouvez conserver des magasins de données personnelles dans une région gérée spécifique, les données résidant toujours dans des comptes bénéficiant des services d'infrastructure et de AWS Control Tower gouvernance. Dans AWS Organizations, les comptes contenant des données personnelles sont toujours regroupés dans une unité d'organisation dédiée aux données personnelles, dans laquelle toutes les garanties de souveraineté des données AWS Control Tower sont mises en œuvre. En outre, les charges de travail spécifiques aux régions sont contenues dans des comptes dédiés, plutôt que d'établir des comptes de production qui peuvent contenir la même charge de travail dans plusieurs régions.
Ce déploiement peut être le plus rentable, mais une attention supplémentaire est nécessaire pour contrôler le flux de données personnelles au-delà des frontières régionales Compte AWS et régionales. Éléments à prendre en compte :
-
Les journaux peuvent contenir des données personnelles. Une configuration supplémentaire peut donc être nécessaire pour contenir ou supprimer des champs sensibles afin d'empêcher le transfert entre régions lors de l'agrégation. Pour plus d'informations et pour connaître les pratiques recommandées pour contrôler l'agrégation des journaux entre les régions, consultez Stockage centralisé des journaux ce guide.
-
Tenez compte de l'isolation du trafic réseau bidirectionnel VPCs et du flux de trafic bidirectionnel approprié dans la AWS Transit Gateway conception. Vous pouvez limiter les pièces jointes de Transit Gateway autorisées et approuvées, et vous pouvez limiter les personnes ou les éléments autorisés à modifier les tables de routage VPC.
-
Vous devrez peut-être empêcher les membres de votre équipe chargée des opérations cloud d'accéder aux données personnelles. Par exemple, les journaux d'applications contenant les données des transactions des clients peuvent être considérés comme plus sensibles que les autres sources de journaux. Des approbations supplémentaires et des garde-fous techniques peuvent être nécessaires, tels que le contrôle d'accès basé sur les rôles et le contrôle d'accès basé sur les attributs. En outre, les données peuvent être soumises à des limites de résidence en ce qui concerne l'accès. Par exemple, les données d'une région A ne sont accessibles qu'à partir de cette région.
Le schéma suivant montre une zone d'atterrissage centralisée avec des déploiements régionaux.
Zones d'atterrissage régionales
Le fait de disposer de plusieurs MALZ peut vous aider à respecter des exigences de conformité plus strictes en isolant complètement les charges de travail qui traitent des données personnelles par rapport aux charges de travail non matérielles. AWS Control Tower l'agrégation de journalisation centralisée pourrait être configurée par défaut et donc simplifiée. Avec cette approche, il n'est pas nécessaire de conserver des exceptions pour la journalisation avec des flux de journaux distincts nécessitant une rédaction. Vous pourriez même avoir une équipe locale dédiée aux opérations cloud pour chaque MALZ, ce qui limite l'accès des opérateurs à la résidence locale.
De nombreuses organisations ont déployé des zones d'atterrissage distinctes aux États-Unis et dans l'UE. Chaque zone d'atterrissage régionale dispose d'un dispositif de sécurité global unique et d'une gouvernance associée pour les comptes de la région. Par exemple, le chiffrement des données personnelles à l'aide de technologies dédiées HSMs peut ne pas être requis dans les charges de travail d'un MALZ, mais il peut l'être dans un autre MALZ.
Bien que cette stratégie puisse évoluer pour répondre à de nombreuses exigences actuelles et futures, il est important de comprendre les coûts supplémentaires et les frais opérationnels associés à la maintenance de multiples MALZs. Pour en savoir plus, consultez Pricing AWS Control Tower
Le schéma suivant montre des zones d'atterrissage distinctes dans deux régions.
AWS Cloud souverain européen
Certaines entreprises exigent une séparation complète de leurs charges de travail opérant dans l'Espace économique européen (EEE) et des charges de travail opérant ailleurs. Dans ce cas, considérez le cloud souverain AWS européen
Le cloud souverain AWS européen est physiquement et logiquement distinct de l'existant Régions AWS, tout en offrant la même sécurité, la même disponibilité et les mêmes performances. Seuls AWS les employés situés dans l'UE ont le contrôle des opérations et du support du cloud souverain AWS européen. Si vous avez des exigences strictes en matière de résidence des données, le cloud souverain AWS européen conserve toutes les métadonnées que vous créez (telles que les rôles, les autorisations, les étiquettes de ressources et les configurations qu'ils utilisent pour fonctionner AWS) dans l'UE. Le cloud souverain AWS européen dispose également de ses propres systèmes de facturation et de mesure de l'utilisation.
Pour cette approche, vous devez utiliser un schéma similaire à celui de la section précédente, Zones d'atterrissage régionales. Toutefois, pour les services que vous fournissez à des clients européens, vous pouvez déployer un MALZ dédié dans le cloud souverain AWS européen.
