Bonnes pratiques relatives aux comptes membres

Suivez ces recommandations pour vous aider à protéger la sécurité des comptes membres de votre organisation. Ces recommandations supposent que vous respectez également les bonnes pratiques qui consistent à avoir recours à l'utilisateur racine uniquement pour les tâches qui le nécessitent vraiment.

Définir le nom et les attributs du compte

Pour vos comptes membres, utilisez une structure de dénomination et une adresse e-mail qui reflètent l'utilisation du compte. Par exemple, [e-mail] pour WorkloadsFooADev, [e-mail] pour WorkloadsFooBDev. Si vous avez défini des balises personnalisées pour votre organisation, nous vous recommandons d'attribuer ces balises à des comptes qui reflètent l'utilisation du compte, le centre de coûts, l'environnement et le projet. Cela facilite l'identification, l'organisation et la recherche des comptes.

Mise à l'échelle efficace de l'utilisation de votre environnement et de vos comptes

Au fur et à mesure de la mise à l'échelle, avant de créer de nouveaux comptes, assurez-vous qu'il n'existe pas déjà des comptes répondant à des besoins similaires, afin d'éviter toute duplication inutile. Les comptes Comptes AWS doivent être basés sur des besoins d'accès communs. Si vous prévoyez de réutiliser les comptes, comme un compte d'environnement de test (sandbox) ou équivalent, nous vous recommandons de nettoyer les ressources ou charges de travail inutiles des comptes, mais de conserver les comptes pour une utilisation ultérieure.

Avant de fermer des comptes, notez qu'ils sont soumis à des limites de quotas de fermeture. Pour de plus amples informations, veuillez consulter Quotas pour AWS Organizations. Pensez à mettre en œuvre un processus de nettoyage pour réutiliser les comptes au lieu de les fermer et d'en créer de nouveaux lorsque c'est possible. De cette façon, vous éviterez d'encourir des coûts liés à l'utilisation des ressources et d'atteindre les limites de l'API CloseAccount.

Utiliser une politique de contrôle des services (SCP) pour restreindre ce que l'utilisateur racine de vos comptes membres peut faire

Nous vous recommandons de créer une politique de contrôle des services (SCP) dans l'organisation et de l'attacher à la racine de l'organisation de manière à ce qu'elle s'applique à tous les comptes membres. Pour plus d'informations, consultez Sécurisez les informations d’identification d'utilisateur root de votre compte Organizations.

Vous pouvez refuser toutes les actions de l'utilisateur root, à l'exception d'une action spécifique que vous devez effectuer dans votre compte membre. Par exemple, le SCP suivant empêche l'utilisateur root de n'importe quel compte membre d'effectuer des appels d'API de service AWS, à l'exception de « Mise à jour d'une politique de compartiment S3 qui a été mal configurée et refuse l'accès à tous les principaux » (l'une des actions qui nécessitent des informations d'identification root). Pour plus d'informations, consultez la rubrique Tâches nécessitant des informations d'identification d'utilisateur root du Guide de l'utilisateur IAM.

{
 "Version": "2012-10-17",

    "Statement": [

        {

            "Effect": "Deny",

            "NotAction":[

            "s3:GetBucketPolicy",

            "s3:PutBucketPolicy",

            "s3:DeleteBucketPolicy"

                 ],

            "Resource": "*",

            "Condition": {
 "StringLike": { "aws:PrincipalArn": "arn:aws:iam::*:root" }

            }

        }

    ]
 }

Dans la majorité des cas, toutes les tâches administratives peuvent être exécutées par un rôle AWS Identity and Access Management (IAM) dans le compte membre disposant des autorisations d'administrateur appropriées. Tout rôle de ce type doit avoir des contrôles appropriés appliqués pour limiter, journaliser et surveiller les activités.