Une application stocke des données utilisateur sensibles et comprend une distribution CloudFront ainsi que plusieurs fonctions Lambda qui gèrent les requêtes. Chaque requête contient plus de 20 champs de données ; certains champs doivent être chiffrés et seuls des composants spécifiques de l'application doivent pouvoir les déchiffrer. Quelle solution répond à ces exigences ?

La solution correcte est d'activer le chiffrement au niveau du champ CloudFront. Cette fonctionnalité est conçue spécifiquement pour chiffrer des champs de données spécifiques dans les requêtes HTTP POST avant qu'elles n'atteignent l'origine. Elle utilise des clés publiques asymétriques stockées dans AWS KMS, ce qui permet de chiffrer des données sensibles côté client ou au niveau de CloudFront, et de les déchiffrer uniquement par les composants de l'application possédant la clé privée correspondante. Cela répond aux exigences de chiffrement de champs spécifiques et de déchiffrement par des composants désignés. L'association de CloudFront à une fonction Lambda@Edge pour un chiffrement asymétrique manuel serait plus complexe à gérer et moins optimisée que la fonctionnalité native de chiffrement au niveau du champ. L'intégration d'AWS WAF et l'utilisation de clés autogérées dans Lambda ne répondent pas directement à l'exigence de chiffrement de champs spécifiques avant l'origine et de déchiffrement sélectif. Exiger HTTPS et utiliser des URL/cookies signés protège le transport et l'accès aux fichiers, mais ne chiffre pas des champs de données spécifiques dans la requête.