Un processus récupère automatiquement les identifiants d'API pour plusieurs sources bancaires et invoque une fonction Lambda liée à une ressource personnalisée CloudFormation. Le développeur souhaite stocker ces identifiants d'API avec un minimum de frais opérationnels et une sécurité maximale. Quelle approche est la plus sécurisée et nécessite le moins d'effort opérationnel ?

L'option correcte est d'appeler l'API SSM PutParameter depuis la fonction Lambda pour stocker les identifiants en tant que paramètre SecureString. Cela garantit que les identifiants sont chiffrés au repos et en transit, offrant une sécurité maximale. L'utilisation d'une fonction Lambda (ressource personnalisée) pour gérer ce processus réduit les frais opérationnels car elle automatise la récupération et le stockage des identifiants sans intervention manuelle. L'ajout d'une ressource Secrets Manager GenerateSecretString au modèle CloudFormation n'est pas idéal car les identifiants sont récupérés dynamiquement et ne sont pas générés par CloudFormation. L'ajout direct d'une ressource SSM Parameter Store au modèle CloudFormation avec NoEcho ne permet pas de stocker des identifiants dynamiquement récupérés et ne garantit pas le chiffrement au repos comme SecureString. Enfin, appeler PutParameter sans spécifier SecureString ne chiffre pas les identifiants, compromettant la sécurité.