Fabrikam Games autorise son groupe DevOps à créer des rôles IAM pour les charges de travail EC2. La sécurité doit s'assurer que tout rôle qu'ils créent ne peut pas dépasser un ensemble de permissions défini (lecture seule de la table DynamoDB Scores et publication dans CloudWatch Logs), quelles que soient les politiques que DevOps attache ultérieurement. Quelle est l'approche la PLUS efficace ?

L'approche la plus efficace consiste à utiliser une limite de permissions (permissions boundary). En attachant une politique IAM au groupe DevOps qui exige une limite de permissions spécifique lors de la création ou de la mise à jour de rôles (via une condition sur iam:PermissionsBoundary), vous garantissez que tous les rôles créés par DevOps ne pourront jamais dépasser les autorisations définies dans cette limite, quelle que soit la politique d'identité attachée au rôle. L'option d'attacher une limite de permissions à chaque utilisateur DevOps est incorrecte car une limite de permissions sur un utilisateur affecte les actions que cet utilisateur peut effectuer, pas les permissions maximales des rôles qu'il crée. L'application d'une SCP à l'OU DevOps est incorrecte car les SCP limitent les permissions maximales pour tous les comptes de l'OU, mais ne peuvent pas spécifiquement contraindre les permissions des rôles IAM créés au sein de ces comptes de la manière granulaire requise. L'ajout d'une politique de ressource DynamoDB est incorrect car elle ne contrôle que l'accès à la table DynamoDB elle-même et n'empêche pas la création de rôles IAM avec des permissions excessives pour d'autres services.