Une entreprise met en œuvre AWS Organizations pour restreindre ses développeurs à n'utiliser que Amazon EC2, Amazon S3 et Amazon DynamoDB. Le compte des développeurs se trouve dans une OU dédiée. Après avoir appliqué une SCP qui ne liste que ces services, les utilisateurs IAM du compte des développeurs peuvent toujours utiliser des services non listés dans la SCP. Que doit faire l'architecte de solutions pour empêcher les développeurs d'utiliser des services en dehors de la portée de la politique ?

La SCP FullAWSAccess accorde un accès complet à tous les services et ressources AWS. Lorsqu'elle est attachée à une OU ou un compte, elle annule effectivement toute autre SCP qui tente de restreindre les autorisations. Par conséquent, même si une autre SCP est appliquée pour limiter l'accès à EC2, S3 et DynamoDB, la présence de FullAWSAccess permet toujours aux développeurs d'utiliser des services non listés. La suppression de FullAWSAccess permettra à la SCP restrictive de prendre effet. Créer une instruction Deny explicite pour chaque service non désiré serait fastidieux et difficile à maintenir, car de nouveaux services AWS sont constamment ajoutés. Modifier FullAWSAccess pour tout refuser explicitement n'est pas la bonne approche ; le but est de permettre des services spécifiques, pas de tout refuser. Ajouter une instruction Deny explicite avec un caractère générique à la fin de la SCP ne fonctionnerait pas si FullAWSAccess est toujours présente, car FullAWSAccess accorde un accès explicite.