Une entreprise utilise des fonctions AWS Lambda qui doivent se connecter à une instance de base de données Microsoft SQL Server sur Amazon RDS. Il existe des environnements de développement et de production distincts ; les développeurs peuvent accéder aux informations d'identification de développement, mais les informations d'identification de production doivent être chiffrées à l'aide d'une clé que seuls les membres du groupe IAM de l'équipe de sécurité informatique peuvent utiliser. La clé doit être renouvelée régulièrement. Que doit implémenter un architecte de solutions dans l'environnement de production pour satisfaire à ces exigences ?

L'option correcte est de stocker les informations d'identification dans AWS Secrets Manager. Secrets Manager est conçu spécifiquement pour la gestion des secrets, y compris la rotation automatique des informations d'identification, ce qui répond à l'exigence de renouvellement régulier. L'utilisation d'une clé gérée par le client (CMK) AWS KMS permet de contrôler précisément l'accès, en le limitant à l'équipe de sécurité informatique. Les fonctions Lambda peuvent récupérer le secret via leurs rôles IAM, évitant ainsi de stocker les informations d'identification en clair. Les autres options sont moins appropriées : Stocker dans AWS Systems Manager Parameter Store avec SecureString est une option viable pour les secrets, mais il ne gère pas la rotation automatique des informations d'identification, ce qui est une exigence clé ici. Chiffrer avec la clé Lambda par défaut et stocker dans les variables d'environnement n'est pas idéal car les variables d'environnement chiffrées sont déchiffrées au moment de l'exécution et ne sont pas conçues pour la rotation automatique. De plus, la clé Lambda par défaut n'offre pas le même niveau de contrôle granulaire qu'une CMK. Stocker les informations d'identification directement dans les variables d'environnement, même chiffrées avec une CMK, ne permet pas la rotation automatique des informations d'identification, ce qui est une exigence.