Un site web statique de production dans S3 invoque une base de données Aurora PostgreSQL via une fonction Lambda. Le site utilise un alias Lambda qui pointe vers une version spécifique de la fonction. Les identifiants de la base de données doivent être renouvelés toutes les deux semaines, et les anciennes versions déployées de Lambda doivent pouvoir accéder aux identifiants les plus récents. Quelle solution répond à ces exigences ?

La bonne réponse est de stocker les identifiants de la base de données dans AWS Secrets Manager avec la rotation activée et de faire en sorte que la fonction Lambda les récupère au moment de l'exécution. Secrets Manager est conçu pour stocker et gérer les secrets, y compris la rotation automatique, ce qui garantit que les identifiants sont régulièrement mis à jour sans intervention manuelle. La récupération au moment de l'exécution permet à toutes les versions de la fonction Lambda (y compris les anciennes versions déployées via l'alias) d'accéder aux identifiants les plus récents, répondant ainsi à l'exigence clé. Intégrer les identifiants dans le code de la fonction Lambda est une mauvaise pratique de sécurité et nécessiterait un redéploiement à chaque changement. Stocker les identifiants dans les variables d'environnement Lambda est également une mauvaise pratique de sécurité et ne prendrait pas en charge la rotation automatique ni l'accès des anciennes versions aux nouveaux identifiants sans mise à jour manuelle de chaque version. Bien que Systems Manager Parameter Store puisse stocker des identifiants, il ne gère pas la rotation automatique des identifiants de base de données comme le fait Secrets Manager, ce qui rend cette solution moins complète pour l'exigence de rotation.