Évitez la gouvernance mixte lors de la configuration des régions - AWS Control Tower

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.

É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 de la AWS Control Tower à une nouvelle Région AWS entité et après avoir supprimé la gouvernance de la 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 une fois que AWS Control Tower a étendu la gouvernance à une nouvelle Région AWS entité ou 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 d'atterrissage. 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 EnregistréOUs, pour les comptes qui ne sont pas encore mis à jour.

Note

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

Comportement des contrôles lors d'une gouvernance mixte
  • Dans le cadre d'une gouvernance mixte, AWS Control Tower ne peut pas déployer systématiquement 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, l'EnableControlAPIopération 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 relevant du Security Hub Service Managed Standard : AWS Control Tower ne peuvent pas signaler de conformité avec précision dans les régions où il existe un décalage entre la configuration de la zone d'atterrissage et les comptes qui ne sont pas mis à jour.

  • La gouvernance mixte ne modifie pas le comportement des contrôles SCP basés (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 telle.

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, s'ils OUs ont moins de 1 000 comptes.