Une entreprise utilise AWS Organizations et Control Tower pour la gouvernance et une Transit Gateway pour la connectivité VPC multi-comptes. L'équipe d'application a déployé une application web (Lambda + RDS) dans un compte d'application. Les DBA, dans un compte DBA distinct, gèrent les bases de données de manière centralisée et utilisent une instance EC2 dans le compte DBA pour accéder à une instance RDS dans le compte d'application. L'équipe d'application stocke les identifiants de la base de données dans AWS Secrets Manager dans le compte d'application et partage actuellement les secrets manuellement avec les DBA. Les secrets sont chiffrés avec la clé Secrets Manager gérée par AWS par défaut dans le compte d'application. Concevez une solution qui donne aux DBA l'accès à la base de données sans partage manuel des secrets.

La solution correcte utilise un modèle d'accès inter-comptes sécurisé via l'assomption de rôle IAM. Le compte d'application définit un rôle (DBA-Secret) avec les permissions nécessaires pour lire les secrets. Le compte DBA définit un rôle (DBA-Admin) qui est autorisé à assumer le rôle DBA-Secret dans le compte d'application. En attachant DBA-Admin à l'instance EC2 du compte DBA, les DBA peuvent temporairement assumer le rôle DBA-Secret et accéder aux secrets sans les partager manuellement, garantissant ainsi la sécurité et la conformité. L'option RAM est incorrecte car AWS Secrets Manager ne prend pas en charge le partage de secrets via AWS Resource Access Manager (RAM). L'option avec la politique de clé KMS est incorrecte car bien que la clé KMS puisse être partagée, l'accès au secret lui-même nécessite des permissions Secrets Manager, et la gestion des politiques de clé pour chaque secret serait complexe. L'option SCP est incorrecte car les SCP limitent les permissions mais ne les accordent pas, et elles ne sont pas le mécanisme approprié pour l'accès inter-comptes à des ressources spécifiques comme les secrets.