Веб-приложение использует Amazon CloudFront с двумя пользовательскими источниками (origin): один источник перенаправляет запросы к Amazon API Gateway HTTP API (который использует авторизатор JWT), а другой источник перенаправляет запросы к Application Load Balancer (ALB). Приложение использует поставщика удостоверений OpenID Connect (OIDC) (IdP). Аудит безопасности показал, что API защищен авторизатором JWT, но ALB принимает неаутентифицированные запросы. Как архитектор решений может гарантировать, что оба бэкенд-источника принимают запросы только от аутентифицированных пользователей?

Правильный ответ — настроить ALB для аутентификации. Application Load Balancer (ALB) поддерживает прямую интеграцию с поставщиками удостоверений OpenID Connect (OIDC) для аутентификации пользователей. Это позволяет ALB проверять токены OIDC и пропускать только аутентифицированные запросы к бэкенд-сервисам, обеспечивая защиту, аналогичную JWT-авторизатору для API Gateway. Изменение конфигурации CloudFront для использования подписанных URL-адресов не подходит, так как подписанные URL-адреса используются для контроля доступа к содержимому, а не для аутентификации пользователей к бэкенд-сервисам. Создание веб-ACL AWS WAF для фильтрации неаутентифицированных запросов не является эффективным решением, так как WAF не предназначен для выполнения аутентификации пользователей на основе OIDC. Включение логирования CloudTrail и создание Lambda для анализа логов — это реактивный подход к мониторингу, а не проактивное решение для предотвращения неаутентифицированных запросов.