Webmaster Stack — хостинг, CDN, безопасность

TLS termination: где держать сертификат и где не тащить его на каждый сервер

TLS termination: где держать сертификат и где не тащить его на каждый сервер

Если сайт сидит за Cloudflare, Bunny.net или любым reverse proxy, терминация TLS на edge обычно разумнее: меньше возни с сертификатами, проще ротация, быстрее включать HSTS и единые правила по TLS. Для статического сайта, WordPress с кешем и лендингов это самый практичный вариант.

Но если у вас чувствительные данные, внутренние панели, checkout или сложная сегментация сети, держите TLS до origin и шифруйте трафик между прокси и бэком тоже. Иначе вы получаете «защиту до первой точки входа», а внутри сети запрос уже идёт открытым текстом.

Дальше смотрите на операционку:
— один домен и один origin: можно terminate на прокси;
— несколько бэкендов и балансировка: terminate на L7, а до origin — повторный TLS;
— строгая изоляция: mTLS между сервисами или хотя бы HTTPS до каждого hop;
— нужен IP ACL и WAF до приложения: терминация на edge, origin доступен только с доверенных IP.

Ошибка, которую вижу чаще всего: сертификат живёт и на CDN, и на Nginx, и на апстриме, но никто не знает, где заканчивается доверие. Нарисуйте цепочку: кто принимает внешний TLS, кто видит заголовки, кто идёт по внутреннему каналу. Тогда и аудит, и инциденты, и замена прокси будут без сюрпризов.

Практика простая: для публичных сайтов terminаte на edge, для критичных сервисов — TLS везде, где есть hop.
Этот пост опубликован в Telegram-канале Webmaster Stack — хостинг, CDN, безопасность. Подписаться можно по ссылке: @webmaster_stack.
tech

Свежие посты в категории «Tech Infrastructure»

Все каналы категории →

start

Готовы запустить рекламу через сеть public.tg?

Новый оффер, продукт, GEO, кейс, событие или партнёрский запуск — соберём маршрут под задачу и отдадим медиаплан.

Telegram для медиаплана: @AFFtop_connect. Быстрый тест: $20 за канал, $1000 за пакет по сети.