Amazon добавила взаимную TLS-аутентификацию между CloudFront и origin-серверами. Это помогает убрать «доверие по IP» и сделать так, чтобы бэкенд принимал запросы только от вашей CDN — без самодельных секретных заголовков и бесконечных allowlist’ов.
Если вы используете CDN, обычно подразумевается простая мысль: «весь внешний трафик приходит через CloudFront, а значит, мы контролируем вход». На практике origin иногда можно обойти, если кто-то узнает его прямой адрес. Новая возможность CloudFront — mTLS до origin — делает такой обход заметно сложнее.
Что именно добавили
CloudFront теперь умеет устанавливать соединение с вашим origin по взаимной TLS-аутентификации (mutual TLS). Это значит, что при установлении защищённого канала проверяются обе стороны:
- origin проверяет клиентский сертификат CloudFront и принимает запрос только если доверяет ему;
- CloudFront, в свою очередь, проверяет сертификат origin, как в обычном HTTPS.
С точки зрения инфраструктуры это замена распространённой схемы «доступ к origin по IP-спискам» или «добавим секретный заголовок и будем его проверять». Проверка становится криптографической: сервер видит, кто к нему подключился, а не просто откуда пришёл трафик.
Почему это важно, даже если у вас уже есть WAF и HTTPS
CDN часто защищает “вход” (клиент → edge), но сам бэкенд остаётся уязвимым к прямым обращениям. Проблемы обычно начинаются, когда:
- origin-IP «всплывает» в логах, старых DNS-записях, ошибках конфигурации или через сторонние интеграции;
- команда держит allowlist IP-адресов CloudFront, но он меняется, и обновления превращаются в рутину;
- секретный заголовок попадает не туда (например, в сторонние прокси, трассировки, дебаг-логи).
mTLS решает базовую задачу: origin начинает доверять не сети, а идентичности. Это ложится в модель Zero Trust и хорошо подходит для API, корпоративных порталов и систем с повышенными требованиями к аудиту.
Как это выглядит на практике
Сценарий простой: у компании есть один CloudFront-дистрибутив, а за ним несколько origin’ов (например, API, админка, статические файлы). mTLS настраивается на уровне origin, поэтому можно сделать разную строгость:
- для API включить mTLS и требовать строгую проверку клиентского сертификата;
- для менее критичных origin’ов оставить текущую схему, чтобы не усложнять миграцию.
Что потребуется, если захотите включить
- Клиентский сертификат X.509v3 с назначением
clientAuth(расширенное назначение ключа). - Настройка вашего origin (Nginx/Envoy/ALB/приложение) так, чтобы он требовал клиентский сертификат и валидировал его по вашей цепочке доверия.
- В CloudFront — включить mTLS в настройках origin и привязать сертификат.
Отдельный момент: лучше избегать «вечных» сертификатов. Подход с управляемой ротацией снижает риски, если ключ когда-то утечёт или окажется в бэкапе.
Кому особенно полезно
- командам с гибридной инфраструктурой (часть origin’ов не в AWS);
- проектам с требованиями к контролю доступа и аудиту (финансы, медицина, госсектор);
- всем, кто устал поддерживать IP-allowlist’ы и «секретные заголовки» как единственный барьер.
В итоге CloudFront становится не просто ускорителем и кэшем, а полноценным элементом цепочки доверия: origin начинает принимать запросы только от того, кто может это доказать.
Источник: InfoQ
