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.
Webmaster Stack — хостинг, CDN, безопасность
@webmaster_stack
TLS termination: где держать сертификат и где не тащить его на каждый сервер
Этот пост опубликован в Telegram-канале Webmaster Stack — хостинг, CDN, безопасность. Подписаться можно по ссылке: @webmaster_stack.