Conseils pour la création et la modification des ressources AWS Control Tower - 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.

Conseils pour la création et la modification des ressources AWS Control Tower

Nous vous recommandons de suivre les bonnes pratiques suivantes lorsque vous créez et modifiez des ressources dans AWS Control Tower. Ce guide peut changer lorsque le service est mis à jour. N'oubliez pas que le modèle de responsabilité partagée s'applique à votre environnement AWS Control Tower.

Conseils généraux

  • Ne modifiez ni ne supprimez aucune ressource créée par AWS Control Tower, y compris les ressources du compte de gestion, des comptes partagés et des comptes membres. Si vous modifiez ces ressources, il peut vous être demandé de mettre à jour votre zone d'atterrissage ou de réenregistrer une UO, et les modifications peuvent entraîner des rapports de conformité inexacts.

    En particulier :

    • Conservez un AWS Config enregistreur actif. Si vous supprimez votre enregistreur Config, les contrôles de détection ne peuvent ni détecter ni signaler les dérives. Les ressources non conformes peuvent être signalées comme conformes en raison d'informations insuffisantes.

    • Ne modifiez ni ne supprimez les rôles AWS Identity and Access Management (IAM) créés dans les comptes partagés de l'unité organisationnelle (UO) chargée de la sécurité. La modification de ces rôles peut nécessiter une mise à jour de votre zone de destination.

    • Ne supprimez pas le AWSControlTowerExecution rôle de vos comptes de membre, même s'il s'agit de comptes non inscrits. Dans ce cas, vous ne pourrez pas enregistrer ces comptes auprès d'AWS Control Tower, ni enregistrer leur parent OUs immédiat.

  • N'en interdisez pas l'utilisation par le Régions AWS biais de l'un SCPs ou de l'autre AWS Security Token Service (AWS STS). Cela entraînera l'entrée d'AWS Control Tower dans un état non défini. Si vous n'autorisez pas les régions avec AWS STS, vos fonctionnalités échoueront dans ces régions, car l'authentification ne sera pas disponible dans ces régions. Utilisez plutôt la capacité de refus de la région AWS Control Tower, comme indiqué dans le contrôle, de refuser l'accès en AWS fonction de la demande Région AWS, qui fonctionne au niveau de la zone d'atterrissage, ou du contrôle de refus de la région de contrôle appliqué à l'unité d'organisation, qui fonctionne au niveau de l'unité d'organisation pour restreindre l'accès aux régions.

  • Le AWS Organizations FullAWSAccess SCP doit être appliqué et ne doit pas être fusionné avec un autre SCPs. La modification de ce SCP n'est pas signalée comme une dérive ; toutefois, certaines modifications peuvent affecter les fonctionnalités d'AWS Control Tower de manière imprévisible, si l'accès à certaines ressources est refusé. Par exemple, si le SCP est détaché ou modifié, un compte peut perdre l'accès à un AWS Config enregistreur ou créer une lacune dans la CloudTrail journalisation.

  • N'utilisez pas l' AWS Organizations DisableAWSServiceAccessAPI pour désactiver l'accès du service AWS Control Tower à l'organisation dans laquelle vous avez configuré votre zone de landing zone. Dans ce cas, certaines fonctionnalités de détection de dérive d'AWS Control Tower risquent de ne pas fonctionner correctement sans l'assistance par message de AWS Organizations. Ces fonctionnalités de détection des dérives permettent à AWS Control Tower de signaler avec précision l'état de conformité des unités organisationnelles, des comptes et des contrôles de votre organisation. Pour plus d’informations, consultez .API_DisableAWSServiceAccess dans la référence de AWS Organizations l'API.

  • En général, AWS Control Tower exécute une seule action à la fois, qui doit être terminée avant qu'une autre action puisse commencer. Par exemple, si vous tentez de configurer un compte alors que le processus d'activation d'un contrôle est déjà en cours, le provisionnement du compte échouera.

    Exception :

    • AWS Control Tower autorise des actions simultanées pour déployer des contrôles optionnels. Pour plus d'informations, voir Déploiement simultané pour les contrôles facultatifs.

    • AWS Control Tower permet de créer, de mettre à jour ou d'inscrire jusqu'à dix actions simultanées sur des comptes, avec Account Factory.

Note

Pour plus d'informations sur les ressources créées par AWS Control Tower, consultezQuels sont les comptes partagés ?.

Conseils sur les comptes et OUs

  • Nous vous recommandons de limiter chaque unité d'organisation enregistrée à un maximum de 1 000 comptes, afin de pouvoir mettre à jour ces comptes avec la fonctionnalité de réenregistrement de l'unité d'organisation chaque fois que des mises à jour de compte sont nécessaires, par exemple lorsque vous configurez de nouvelles régions à des fins de gouvernance.

  • Pour réduire le temps nécessaire à l'enregistrement d'une unité d'organisation, nous vous recommandons de maintenir le nombre de comptes par unité d'organisation à environ 680, même si la limite est de 1 000 comptes par unité d'organisation. En règle générale, le temps nécessaire pour enregistrer une UO augmente en fonction du nombre de régions dans lesquelles votre UO opère, multiplié par le nombre de comptes de l'UO.

  • À titre d'estimation, une unité d'organisation avec 680 comptes peut avoir besoin de 2 heures pour s'enregistrer et activer les contrôles, et d'une heure pour se réenregistrer. En outre, l'enregistrement d'une UO comportant de nombreux contrôles prend plus de temps qu'une UO comportant peu de contrôles.

  • L'une des préoccupations liées à l'allongement du délai d'enregistrement d'une unité d'organisation est que ce processus bloque d'autres actions. Certains clients préfèrent autoriser des délais plus longs pour enregistrer ou réenregistrer une unité d'organisation, car ils préfèrent autoriser un plus grand nombre de comptes dans chaque unité d'organisation.