Une application de sondage en ligne s'exécute en tant que microservices dans un cluster Amazon ECS à mise à l'échelle automatique derrière un Application Load Balancer (ALB). L'ALB est une origine personnalisée pour une distribution Amazon CloudFront. Un sondage recueille des données sensibles qui doivent être chiffrées pendant leur transit dans l'application. Seul le microservice de traitement des données doit être capable de déchiffrer ces données. Quelle solution répond à ces exigences ?

La bonne réponse est de générer une paire de clés RSA et d'utiliser le chiffrement au niveau du champ CloudFront. Le chiffrement au niveau du champ permet à CloudFront de chiffrer des données spécifiques dans les requêtes HTTPS avant de les transférer à votre origine. Vous téléchargez la clé publique RSA vers CloudFront, et CloudFront l'utilise pour chiffrer les données. Seul le microservice de traitement des données, qui détient la clé privée correspondante, peut déchiffrer ces données sensibles. Les autres options sont incorrectes car : L'utilisation d'une clé KMS symétrique ne permettrait pas de garantir que seul le microservice de traitement des données puisse déchiffrer les données, car la même clé serait utilisée pour le chiffrement et le déchiffrement, et elle devrait être accessible à CloudFront. Lambda@Edge n'est pas la solution appropriée pour le chiffrement au niveau du champ. Le chiffrement au niveau du champ est une fonctionnalité native de CloudFront conçue spécifiquement pour ce cas d'utilisation. Chiffrer avec la clé privée RSA dans Lambda@Edge est incorrect ; la clé privée est utilisée pour le déchiffrement, non pour le chiffrement des données sensibles envoyées par les utilisateurs.