Uma aplicação web usa o Amazon CloudFront com duas origens personalizadas: uma origem encaminha para uma API HTTP do Amazon API Gateway (que usa um autorizador JWT), e a outra origem encaminha para um Application Load Balancer (ALB). A aplicação usa um provedor de identidade (IdP) OpenID Connect (OIDC). Uma auditoria de segurança constata que a API é protegida por um autorizador JWT, mas o ALB aceita requisições não autenticadas. Como o arquiteto de soluções pode garantir que ambas as origens de backend aceitem requisições apenas de usuários autenticados?

A opção correta é configurar o ALB para autenticação e autorização, integrando-o diretamente com o IdP OIDC. O ALB suporta autenticação nativa com provedores de identidade OIDC, permitindo que ele exija que os usuários se autentiquem antes de encaminhar requisições para os destinos. Isso garante que ambas as origens (API Gateway e ALB) recebam apenas requisições de usuários autenticados, resolvendo a falha de segurança. Alterar o CloudFront para usar URLs assinadas não é a solução, pois as URLs assinadas são para controle de acesso a conteúdo no CloudFront, não para autenticação de usuários em origens de backend. Criar uma ACL web do AWS WAF para filtrar requisições não autenticadas no ALB é inviável, pois o WAF não tem a capacidade de realizar autenticação OIDC. Habilitar o log do CloudTrail e usar uma função Lambda para analisar e bloquear requisições é uma abordagem reativa e complexa, que não impede requisições não autenticadas de chegarem ao ALB inicialmente.