Une application web utilise Amazon CloudFront avec deux origines personnalisées : une origine transfère vers une API HTTP Amazon API Gateway (qui utilise un autorisateur JWT), et l'autre origine transfère vers un Application Load Balancer (ALB). L'application utilise un fournisseur d'identité (IdP) OpenID Connect (OIDC). Un audit de sécurité révèle que l'API est protégée par un autorisateur JWT, mais que l'ALB accepte les requêtes non authentifiées. Comment l'architecte de solutions peut-il s'assurer que les deux origines backend acceptent les requêtes uniquement des utilisateurs authentifiés ?

L'option correcte est de configurer l'ALB pour effectuer l'authentification et l'autorisation en l'intégrant à l'IdP OIDC. L'ALB prend en charge l'authentification native avec les fournisseurs d'identité OIDC, ce qui lui permet de valider les jetons d'authentification avant de transmettre les requêtes aux cibles backend. Cela garantit que seules les requêtes d'utilisateurs authentifiés atteignent les services derrière l'ALB, résolvant ainsi la vulnérabilité de sécurité. Les URL signées CloudFront ne sont pas appropriées ici car elles contrôlent l'accès au contenu CloudFront lui-même, et non l'authentification des utilisateurs pour les backends. Une ACL web AWS WAF peut filtrer le trafic, mais elle ne gère pas l'authentification OIDC nativement pour valider les utilisateurs. L'activation de la journalisation CloudTrail et l'utilisation d'une fonction Lambda pour analyser les journaux et bloquer les requêtes est une solution réactive et complexe, moins efficace que l'authentification proactive au niveau de l'ALB.