Orion Retail stocke les informations d'identification de sa base de données dans AWS Secrets Manager dans le compte B, chiffrées avec une clé KMS gérée par le client dans le compte B. Un microservice exécuté dans le compte A (rôle : arn:aws:iam::111111111111:role/OrdersAppRole) a besoin d'un accès en lecture seule au secret. L'équipe a ajouté une politique IAM au rôle autorisant secretsmanager:GetSecretValue sur l'ARN du secret, mais reçoit toujours des erreurs AccessDenied de KMS. Que doit faire l'équipe de sécurité pour accorder un accès inter-comptes avec le moindre privilège ?

Pour qu'un rôle IAM d'un compte (Compte A) puisse accéder à un secret chiffré par KMS dans un autre compte (Compte B), deux autorisations sont nécessaires : l'autorisation d'accéder au secret lui-même et l'autorisation de déchiffrer la clé KMS. L'option correcte aborde les deux points. Premièrement, une politique basée sur les ressources doit être attachée au secret dans le Compte B pour accorder secretsmanager:GetSecretValue au rôle OrdersAppRole du Compte A. Deuxièmement, la politique de clé KMS dans le Compte B doit être mise à jour pour autoriser kms:Decrypt pour ce même rôle. Les autres options sont incorrectes car : Répliquer le secret dans le Compte A et utiliser une clé KMS par défaut ne respecte pas le principe du moindre privilège et introduit une duplication inutile. Créer des points de terminaison d'interface VPC (PrivateLink) est une solution de connectivité réseau et ne résout pas le problème d'autorisation d'accès au secret ou de déchiffrement KMS. Mettre à jour uniquement la politique IAM du rôle OrdersAppRole avec kms:Decrypt est insuffisant ; la politique de clé KMS dans le Compte B doit également accorder cette autorisation pour permettre l'accès inter-comptes. De plus, l'autorisation secretsmanager:GetSecretValue sur le secret est toujours nécessaire.