Plusieurs équipes de développement déploient des charges de travail de production dans un compte AWS de production partagé. Récemment, des membres d'une équipe de développement ont arrêté une instance EC2 appartenant à une autre équipe. Les développeurs utilisent la fédération SAML via AWS Organizations pour assumer des rôles. Vous devez empêcher les développeurs de gérer les instances appartenant à d'autres équipes tout en leur permettant de gérer leurs propres instances. Quelle stratégie répond à ces exigences ?

La bonne réponse utilise les balises de session AWS STS et une politique IAM avec une condition de refus. En transmettant l'attribut DevelopmentUnit comme balise de session, le principal qui assume le rôle est marqué avec son unité de développement. La politique IAM attachée au rôle de développeur peut alors utiliser une instruction Deny avec la condition StringNotEquals sur la balise de ressource DevelopmentUnit et la balise de principal aws:PrincipalTag/DevelopmentUnit. Cela empêche un développeur d'effectuer des actions sur des ressources dont la balise DevelopmentUnit ne correspond pas à sa propre balise de principal, tout en lui permettant de gérer ses propres ressources. Les autres options sont incorrectes car : Créer des UO et des SCP avec StringNotEquals sur la balise de ressource uniquement ne prend pas en compte l'identité du principal effectuant l'action. Utiliser un SCP avec une action Allow et StringEquals sur la balise de ressource et de principal pourrait ne pas être suffisant pour empêcher les actions non autorisées si d'autres autorisations existent. Il est plus sûr d'utiliser un Deny explicite. Créer des politiques IAM distinctes avec StringEquals et les attribuer via STS ne garantit pas le refus d'accès aux ressources d'autres équipes, car cela dépendrait de l'absence d'autres autorisations plus larges.