Comment AWS les régions fonctionnent avec AWS Control Tower

AWS Control Tower est actuellement pris en charge dans les AWS régions suivantes :

• USA Est (Virginie du Nord)

• USA Est (Ohio)

• USA Ouest (Oregon)

• Canada (Centre)

• Asie-Pacifique (Sydney)

• Asie-Pacifique (Singapour)

• Europe (Francfort)

• Europe (Irlande)

• Europe (Londres)

• Europe (Stockholm)

• Asie-Pacifique (Mumbai)

• Asie-Pacifique (Séoul)

• Asie-Pacifique (Tokyo)

• Europe (Paris)

• Amérique du Sud (São Paulo)

• USA Ouest (Californie du Nord)

• Asie-Pacifique (Hong Kong)

• Asie-Pacifique (Jakarta)

• Asie-Pacifique (Osaka)

• Europe (Milan)

• Afrique (Le Cap)

• Moyen-Orient (Bahreïn)

• Israël (Tel Aviv)

• Moyen-Orient (EAU)

• Europe (Espagne)

• Asie-Pacifique (Hyderabad)

• Europe (Zurich)

• Asie-Pacifique (Melbourne)

À propos de votre région d'origine

Lorsque vous créez une zone d'atterrissage, la région que vous utilisez pour accéder à la console AWS de gestion devient votre AWS région d'origine pour AWS Control Tower. Au cours du processus de création, certaines ressources sont mises à disposition dans la région d'origine. Les autres ressources, telles que les unités d'organisation et les AWS comptes, sont mondiales.

Une fois que vous avez sélectionné une région d'origine, vous ne pouvez pas la modifier.

Contrôles et régions

À l'heure actuelle, tous les contrôles préventifs fonctionnent dans le monde entier. Les contrôles Detective et proactifs ne fonctionnent toutefois que dans les régions où AWS Control Tower est pris en charge. Pour plus d'informations sur le comportement des contrôles lorsque vous activez AWS Control Tower dans une nouvelle région, consultezConfigurez vos régions AWS Control Tower.

Configurez vos régions AWS Control Tower

Cette section décrit le comportement auquel vous pouvez vous attendre lorsque vous étendez votre zone d'atterrissage AWS Control Tower à une nouvelle AWS région ou que vous supprimez une région de la configuration de votre zone d'atterrissage. En général, cette action est effectuée par le biais de la fonction Update de la console AWS Control Tower.

Note

Nous vous recommandons d'éviter d'étendre la zone de landing de votre AWS Control Tower à des AWS régions dans lesquelles vous n'avez pas besoin de vos charges de travail pour fonctionner. Le fait de vous désinscrire d'une région ne vous empêche pas de déployer des ressources dans cette région, mais ces ressources resteront en dehors de la gouvernance d'AWS Control Tower.

Lors de la configuration d'une nouvelle région, AWS Control Tower met à jour la zone d'atterrissage, ce qui signifie qu'elle définit votre zone d'atterrissage comme base de référence :

• opérer activement dans toutes les régions nouvellement sélectionnées, et

• pour cesser de gérer les ressources dans les régions désélectionnées.

Les comptes individuels au sein de vos unités organisationnelles (UO) gérés par AWS Control Tower ne sont pas mis à jour dans le cadre de ce processus de mise à jour de la zone de landing zone. Par conséquent, vous devez mettre à jour vos comptes en réenregistrant vos unités d'organisation.

Lorsque vous configurez vos régions AWS Control Tower, tenez compte des recommandations et limites suivantes :

• Sélectionnez les régions dans lesquelles vous prévoyez d'héberger des AWS ressources ou des charges de travail.

• Le fait de vous désinscrire d'une région ne vous empêche pas de déployer des ressources dans cette région, mais ces ressources resteront en dehors de la gouvernance d'AWS Control Tower.

Lorsque vous configurez votre zone d'atterrissage pour de nouvelles régions, les contrôles de détection d'AWS Control Tower respectent les règles suivantes :

• Le comportement reste le même pour les éléments existants. Que ce soit pour la détection ou la prévention, le comportement des barrières de sécurité reste le même pour les comptes existants, dans les unités d'organisation existantes et dans les régions existantes.

• Vous ne pouvez pas appliquer de nouveaux contrôles de détection aux unités d'organisation existantes contenant des comptes qui ne sont pas mis à jour. Lorsque vous avez configuré votre zone d'atterrissage AWS Control Tower dans une nouvelle région (en mettant à jour votre zone d'atterrissage), vous devez mettre à jour les comptes existants dans vos unités d'organisation existantes avant de pouvoir activer de nouveaux contrôles de détection sur ces unités d'organisation et ces comptes.

• Vos contrôles de détection existants commencent à fonctionner dans les régions nouvellement configurées dès que vous mettez à jour les comptes. Lorsque vous mettez à jour votre zone de landing zone AWS Control Tower pour configurer de nouvelles régions, puis que vous mettez à jour un compte, les contrôles de détection déjà activés sur l'unité d'organisation commenceront à fonctionner sur ce compte dans les régions nouvellement configurées.

Configuration des régions AWS Control Tower

1. Connectez-vous à la console AWS Control Tower à l'adresse https://console.aws.amazon.com/controltower

2. Dans le menu de navigation du volet gauche, choisissez Paramètres de la zone d'atterrissage.

3. Sur la page des paramètres de la zone d'atterrissage, dans la section Détails, cliquez sur le bouton Modifier les paramètres en haut à droite. Vous êtes dirigé vers le flux de travail de mise à jour de la zone d'atterrissage, car pour gouverner de nouvelles régions ou supprimer des régions de la gouvernance, vous devez passer à la dernière version de la zone d'atterrissage.

4. Sous AWS Régions supplémentaires pour la gouvernance, recherchez les régions que vous souhaitez gouverner (ou arrêter de gouverner). La colonne État indique les régions que vous gouvernez actuellement et celles que vous ne gouvernez pas.

5. Cochez la case correspondant à chaque région supplémentaire à gouverner. Décochez la case correspondant à chaque région dans laquelle vous supprimez la gouvernance.

   Note

   Si vous choisissez de ne pas gouverner une région, vous pouvez toujours y déployer des ressources, mais ces ressources resteront en dehors de la gouvernance d'AWS Control Tower.

6. Terminez le reste du flux de travail, puis choisissez Mettre à jour la zone d'atterrissage.

7. Lorsque la configuration de la zone d'atterrissage est terminée, réenregistrez les UO pour mettre à jour les comptes dans vos nouvelles régions. Pour de plus amples informations, veuillez consulter Quand mettre à jour les unités d'organisation et les comptes AWS Control Tower.

Une autre méthode pour approvisionner ou mettre à jour des comptes individuels après avoir configuré de nouvelles régions consiste à utiliser le framework d'API de Service Catalog et AWS CLIà mettre à jour les comptes par lots. Pour de plus amples informations, veuillez consulter Fournir et mettre à jour des comptes à l'aide de l'automatisation.

Évitez la gouvernance mixte lors de la configuration des régions

Il est important de mettre à jour tous les comptes d'une unité d'organisation après avoir étendu la gouvernance d'AWS Control Tower à une nouvelle Région AWSentité et après avoir supprimé la gouvernance d'AWS Control Tower d'une région.

La gouvernance mixte est une situation indésirable qui peut se produire si les contrôles régissant une UO ne correspondent pas totalement aux contrôles régissant chaque compte au sein d'une UO. Une gouvernance mixte se produit dans une unité d'organisation si les comptes ne sont pas mis à jour après qu'AWS Control Tower ait étendu la gouvernance à une nouvelle Région AWSentité ou ait supprimé la gouvernance.

Dans ce cas, certains comptes d'une unité d'organisation peuvent être soumis à des contrôles différents selon les régions, par rapport à d'autres comptes de l'unité d'organisation ou par rapport à la posture de gouvernance globale de la zone d'atterrissage.

Dans une unité d'organisation à gouvernance mixte, si vous créez un nouveau compte, celui-ci bénéficiera de la même posture de gouvernance de région et d'unité organisationnelle (mise à jour) que la zone de landing zone. Toutefois, les comptes existants qui ne sont pas encore mis à jour ne bénéficient pas de la nouvelle posture de gouvernance de la région.

En général, une gouvernance mixte peut créer des indicateurs de statut contradictoires ou inexacts dans la console AWS Control Tower. Par exemple, dans le cadre d'une gouvernance mixte, les régions optionnelles apparaissent avec le statut Non gouvernée, dans les unités d'organisation enregistrées, pour les comptes qui ne sont pas encore mis à jour.

Note

AWS Control Tower n'autorise pas l'activation des contrôles dans un état de gouvernance mixte.

Comportement des contrôles dans le cadre d'une gouvernance mixte

• Dans le cadre d'une gouvernance mixte, AWS Control Tower ne peut pas déployer de manière cohérente des contrôles basés sur des AWS Config règles (c'est-à-dire des contrôles de détection) dans les régions que l'unité d'organisation indique déjà comme étant gouvernées, car certains comptes de l'unité d'organisation n'ont pas été mis à jour. Il est possible que vous receviez un message FAILED_TO_ENABLE d'erreur.

• Dans le cadre d'une gouvernance mixte, si vous étendez la gouvernance de la zone d'atterrissage à une région optionnelle alors qu'aucun compte de l'unité d'organisation n'a encore été mis à jour, le fonctionnement de l'EnableControlAPI sur l'unité d'organisation échoue pour les contrôles détectifs et proactifs. Vous recevrez un message d'FAILED_TO_ENABLEerreur, car les comptes de membres non mis à jour au sein de l'UO n'ont pas encore été ajoutés à ces régions.

• Dans le cadre d'une gouvernance mixte, les contrôles qui font partie de la norme gérée par le Security Hub Service : AWS Control Tower ne peuvent pas signaler avec précision la conformité dans les régions où la configuration de la zone de landing zone ne correspond pas à celle des comptes qui ne sont pas mis à jour.

• La gouvernance mixte ne modifie pas le comportement des contrôles basés sur les SCP (contrôles préventifs), qui s'appliquent uniformément à tous les comptes d'une unité d'organisation, dans chaque région gouvernée.

Note

La gouvernance mixte n'est pas la même chose que la dérive, et elle n'est pas signalée comme une dérive.

Pour réparer la gouvernance mixte

• Choisissez Mettre à jour le compte pour chaque compte de l'unité d'organisation dont le statut de mise à jour est disponible sur la page Organizations de la console.

• Choisissez Re-Register OU sur la page Organizations, qui met automatiquement à jour tous les comptes de l'unité d'organisation, pour les unités d'organisation comptant moins de 300 comptes.

Considérations relatives au refus de contrôle des régions au niveau de l'UO

La principale considération concernant le refus de contrôle de la région au niveau de l'OU est de déterminer comment il interagira avec le refus de contrôle de la région de la zone d'atterrissage, si les deux sont activés. Pour de plus amples informations, veuillez consulter Contrôle de refus de région appliqué à l'UO.