Stratégies d'utilisation des politiques de contrôle des services - AWS Organizations

Stratégies d'utilisation des politiques de contrôle des services

Vous pouvez configurer les politiques de contrôle des services (SCP) de votre organisation pour fonctionnent au choix comme :

  • Une liste de refus : les actions sont autorisées par défaut et vous spécifiez les services et actions interdits.

  • Une liste d'autorisations  : les actions sont interdites par défaut et vous spécifiez les services et actions autorisés.

Astuce

Vous pouvez utiliser les dernières informations consultées relatives aux services dans IAM pour mettre à jour vos politiques SCP afin d'en limiter l'accès uniquement aux services AWS dont vous avez besoin. Pour de plus amples informations, consultez Affichage des dernière informations consultées pour Organizations dans le Guide de l'utilisateur IAM.

Utilisation de politiques SCP comme une liste de refus

La configuration par défaut de AWS Organizations prend en charge l'utilisation de politiques SCP comme des listes de refus. Grâce à une politique de liste de refus, les administrateurs de compte peuvent déléguer tous les services et actions jusqu'à la création ou l'attachement d'une politique qui refuse un service spécifique ou un ensemble d'actions. Les instructions de refus demandent moins de maintenance, car vous n'avez pas besoin de les mettre à jour lorsqu'AWS ajoute de nouveaux services. Les instructions de refus utilisent généralement moins d'espace, ce qui permet de respecter plus facilement les tailles maximales des SCP. Dans une instruction où l'élément Effect a une valeur de Deny, vous pouvez également limiter l'accès à des ressources spécifiques ou définir des conditions pour le moment où les politiques de contrôle des services sont en vigueur.

Pour prendre en charge cela, AWS Organizations attache une politique de contrôle des services gérée par AWS et appelée FullWASAccess à chaque racine et unité d'organisation lors de sa création. Cette politique autorise tous les services et actions. Vous pouvez toujours l'attacher ou la détacher des entités de votre organisation si nécessaire. La politique étant une SCP gérée par AWS, vous ne pouvez pas la modifier ou la supprimer. La politique ressemble à ce qui suit :

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*" } ] }

Cette politique permet aux administrateurs de compte de déléguer des autorisations pour n'importe quel service ou opération jusqu'à ce que vous créiez et attachiez une politique SCP qui refuse un accès. Vous pouvez attacher une politique SCP qui interdit explicitement les actions que vous ne voulez pas que les utilisateurs et rôles de certains comptes effectuent.

Cette politique peut ressembler à l'exemple suivant, qui empêche les utilisateurs des comptes concernés d'exécuter des actions pour le service Amazon DynamoDB. L'administrateur de l'organisation peut détacher la politique FullAWSAccess et attacher celle-ci à la place. Cette politique de contrôle des services autorise toujours tous les autres services et leurs actions.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowsAllActions", "Effect": "Allow", "Action": "*", "Resource": "*" }, { "Sid": "DenyDynamoDB", "Effect": "Deny", "Action": "dynamodb:*", "Resource": "*" } ] }

Les utilisateurs des comptes concernés ne peuvent pas exécuter d'actions DynamoDB, car le Deny explicite de la seconde instruction remplace le Allow explicite de la première. Vous pouvez également configurer cela en conservant la politique FullAWSAccess et en attachant une deuxième politique qui ne possède que l'instruction Deny, comme illustré ici.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "dynamodb:*", "Resource": "*" } ] }

La combinaison de la politique FullAWSAccess et de l'instruction Deny dans la politique DynamoDB précédente appliquée à une racine ou unité d'organisation a le même effet que la politique unique qui contient les deux instructions. Toutes les politiques qui s'appliquent à un niveau spécifié sont combinées. Chaque instruction, quelle que soit la stratégie à l'origine, est évaluée conformément aux règles décrites précédemment (c'est-à-dire un Deny explicite remplace un Allow explicite, qui remplace le Deny implicite par défaut).

Utilisation de politiques SCP comme une liste d'autorisations

Pour utiliser des politiques SCP sous la forme d'une liste d'autorisations, vous devez remplacer la politique SCP AWS gérée par FullAWSAccess par une politique SCP qui n'autorise explicitement que les services et actions que vous souhaitez autoriser. En supprimant la politique SCP FullAWSAccess par défaut, toutes les actions de tous les services sont désormais implicitement refusées. Votre politique de contrôle des services personnalisée remplace le Deny implicite par un Allow explicite uniquement pour les actions que vous souhaitez autoriser. Pour qu'une autorisation soit activée pour un compte spécifique, chaque politique de contrôle des services depuis la racine via chaque unité d'organisation sur le chemin d'accès direct vers le compte, et même celle attachée au compte lui-même, doit autoriser cette autorisation.

Remarques
  • Une instruction Allow dans un SCP permet à l’élément Resource de ne posséder qu’une entrée "*".

  • Une instruction Allow dans une SCP ne peut pas avoir d'élément Condition du tout.

Une politique de liste d'autorisations peut ressembler à l'exemple suivant, qui permet aux utilisateurs de compte d'exécuter une opération pour Amazon Elastic Compute Cloud (Amazon EC2) et Amazon CloudWatch, mais aucun autre service. Toutes les politiques SCP des unités d'organisation parentes ou la racine doivent également octroyer explicitement ces autorisations.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:*", "cloudwatch:*" ], "Resource": "*" } ] }