Шифрование In Transit

Шифрование In Transit

1) Определение и границы контроля

Шифрование in transit — это защита данных на всем пути сетевой передачи (браузер ↔ сервер, сервис ↔ сервис, агент ↔ брокер, база ↔ приложение, датацентр ↔ датацентр), чтобы пассивное перехватывание и активные атаки на канал не раскрывали содержимое и не позволяли его модифицировать без детектирования.

Что покрываем: публичные и приватные API (HTTP/HTTPS, gRPC), стриминг и брокеры (Kafka, NATS, RabbitMQ), WebSocket, базы и кэши по сети, служебный трафик внутри кластеров, VPN/между-ЦОД и облаками, DNS-запросы, мобильные/IoT-клиенты.

Чего не покрываем полностью: атаки на конечные точки (компрометация хоста/браузера), уязвимости приложений, утечки из логов/дампов. Это решается отдельными контролями (A&A, минимизация прав, шифрование at rest, безопасное логирование).

2) Модель угроз и цели

Риски: перехват/подмена трафика (MITM), даунгрейд протокола/шифросуит, поддельные сертификаты/CA, утечка ключей, атаки на SNI/метаданные, смешанный контент, неверное терминирование TLS на балансерах, небезопасные межсервисные соединения.

1. Конфиденциальность + целостность с криптографической аутентификацией.

2. Противостояние даунгрейду (строгая политика и конфиг).

3. Идентификация сторон (серверная, при необходимости — взаимная).

4. Управляемый жизненный цикл сертификатов/ключей и аудит.

5. Профиль производительности без компромиссов безопасности.

3) Базовые принципы

TLS везде по умолчанию. Внешний и внутренний трафик — шифруем.
Современные версии. TLS 1.3 как стандарт; TLS 1.2 — только при строгих политиках. Отключить 1.0/1.1.
AEAD-шифросуиты с PFS. AES-GCM или ChaCha20-Poly1305; PFS через (EC)DHE.
Кривые/кей-эксчейндж. X25519 (предпочтительно) или secp256r1 (P-256). RSA-ключи ≥2048, лучше ECDSA (P-256).
mTLS там, где доверия мало. Межсервисные каналы, админ-API, брокеры, базы — через взаимную аутентификацию.
HSTS для веб. Принудительный HTTPS + preload для публичных доменов.
«Шифруем-и-снова-шифруем» осознанно. TLS-терминация на периметре + ре-шифрование до бэкендов либо сквозной passthrough — выбираем по модели угроз.
Crypto-agility. Возможность менять кривые/суиты/версии с нулевым простоем.

4) Стек протоколов и сценарии

4.1 HTTP/2, HTTP/3 (QUIC), gRPC, WebSocket

ALPN: h2 для HTTP/2, h3 для HTTP/3; запрет h2c (без TLS).
HTTP/3/QUIC: снижает латентность, встроенные 0-RTT и миграция соединений; 0-RTT разрешать выборочно (риск реплея).
gRPC: поверх h2/h3; обязательно TLS, опционально mTLS + пер-RPC авторизация.
WebSocket: только wss://; в прокси/балансерах — корректный апгрейд и TLS-пиннинг домена.

4.2 Межсервисный трафик и сервис-меши

Sidecar-модель (Istio/Linkerd и пр.). Автоматический mTLS, политики разрешения, ротация сертификатов.
SPIFFE/SPIRE. Децентрализованные идентичности сервисов (SPIFFE ID), SVID-сертификаты, короткие TTL.
Параметры TLS централизуются. Минимизировать разнобой конфигов в коде сервисов.

4.3 Брокеры/стриминг/очереди

Kafka/NATS/RabbitMQ: TLS для клиент↔брокер и брокер↔брокер; по возможности — mTLS.
SASL поверх TLS: если мTLS невозможен, аутентификация — по токенам/логинам, но канал шифровать.
ACL и авторизация тем. Шифрование ≠ контроль доступа.

4.4 Базы данных и кэши

PostgreSQL/MySQL/SQL Server: включить TLS, валидацию CN/SAN, pin CA/корень.
Redis/Memcached: использовать stunnel/TLS-редисы; запрет plain-трафика в проде.

4.5 Сеть/туннели

Между ЦОД/облаками: IPsec (IKEv2) или WireGuard (современный набор примитивов).
Админ-доступ: SSH с современными KEX/шифрами; запрет паролей, только ключи/SSO.

4.6 DNS и вспомогательные протоколы

DNS over HTTPS (DoH) / DNS over TLS (DoT) для клиентов и внутри кластера, где возможно.
Отключить смешанный контент. Ничего по http:// на страницах https://.

5) Сертификаты, PKI и управление ключами

PKI-модель: для внешних доменов — публичные CA; для внутреннего трафика — собственный CA или SPIRE-CA.
Автоматизация: ACME/Cert-manager для Kubernetes, короткие TTL, авто-ротация.
OCSP stapling и CRL. Включить stapling на фронтах; регулярно обновлять цепочки.
Pinning — с осторожностью. В мобильных/десктоп-клиентах — pin CA/SPKI с механизмом аварийной раскатки.
Хранение ключей: приватные ключи в HSM/KMS/secret-хранилищах; минимум экспозиций; запрет логирования.

6) Конфигурации: практические профили

• Версии: TLS 1.3 (обязательно), TLS 1.2 (fallback).

• TLS 1.3: `TLS_AES_128_GCM_SHA256`, `TLS_AES_256_GCM_SHA384`, `TLS_CHACHA20_POLY1305_SHA256`.
• TLS 1.2: `ECDHE-ECDSA-AES128-GCM-SHA256`, `ECDHE-RSA-AES128-GCM-SHA256` (+ варианты AES256/CHACHA20 при необходимости).
• Кривые: X25519, secp256r1.
• Сертификаты: ECDSA-предпочтительно, RSA-fallback.
• Безопасные заголовки: `Strict-Transport-Security`, `X-Content-Type-Options`, `X-Frame-Options` (по кейсу), `Referrer-Policy`.
• Cookies: `Secure`, `HttpOnly`, `SameSite` (Lax/Strict по дизайну).

• Обязателен клиентский сертификат.
• Короткие TTL клиентских SVID (часы/дни), автоматическая ротация.
• Политики: кто к кому может подключаться (intent-based/работа через mesh-авторизацию).

7) Производительность и надежность

Аппаратное ускорение: AES-NI/ARMv8 Crypto, предпочтение ChaCha20-Poly1305 на CPU без AES-NI.
Session resumption: TLS 1.3 tickets; продумать срок жизни (баланс между перфом и безопасностью).
0-RTT: только для идемпотентных запросов; защититься от реплея (серверные анти-replay механизмы).
Балансеры/прокси: четко выбрать termination vs passthrough; при termination — ре-шифровать к бэкенду.
Observability: метрики рукопожатий/ошибок/переговоров ALPN, процент TLS 1.3, истечения сертификатов, OCSP-статус.

8) Тестирование и верификация

Скан профиля TLS. Регулярные проверки поддерживаемых версий/суитов/кривых и HSTS/OCSP.
Негативные тесты: запрет downgrade, отклонение слабых суитов, отказ соединений без SNI/без валидного цепочечного сертификата.
Пентест канала: MITM-симуляции, проверка pinning в мобильных клиентах, попытки 0-RTT-реплея.
Chaos-тесты: истечение/отзыв сертификата, недоступность OCSP/CA.

9) Частые ошибки и как их избежать

Включен TLS, но без валидации хоста. Всегда проверяем CN/SAN, запрещаем `InsecureSkipVerify`.
Смешанный контент. Блокируйте http-ресурсы на https-страницах, используйте CSP.
Слабые/устаревшие версии и суиты. Отключить TLS 1.0/1.1, CBC/RC4/3DES.
Отсутствие ре-шифрования внутрь. Plain-трафик от балансера к приложению — риск.
Долгоживущие сертификаты. Делайте короткие TTL и авто-обновление.
Неверный SNI/ALPN за прокси. Корректная передача SNI/ALPN при TLS-пасс-тру/терминации.

10) Мини-рецепты (фрагменты конфигураций)

ssl_protocols      TLSv1. 3 TLSv1. 2;
ssl_ciphers       TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers on;
ssl_ecdh_curve     X25519:P-256;
ssl_stapling      on;
ssl_stapling_verify   on;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

transport_socket:
name: envoy. transport_sockets. tls typed_config:
"@type": type. googleapis. com/envoy. extensions. transport_sockets. tls. v3. DownstreamTlsContext common_tls_context:
tls_params:
tls_minimum_protocol_version: TLSv1_3 validation_context:
trusted_ca: { filename: /etc/tls/ca. crt }
tls_certificates:
certificate_chain: { filename: /etc/tls/tls. crt }
private_key:   { filename: /etc/tls/tls. key }
require_client_certificate: true

[Interface]
PrivateKey = <priv>
Address  = 10. 10. 0. 1/24
[Peer]
PublicKey = <pub>
AllowedIPs = 10. 10. 0. 0/24
Endpoint  = gw. example. com:51820
PersistentKeepalive = 25

11) Политики и соответствие

Минимальные требования: TLS 1.3 везде, где возможно; TLS 1.2 — c ограниченным набором суитов.
Регуляторика: PCI DSS/финсектор — запрет слабых версий/суитов; обязательная ротация и аудит.
Zero Trust-подход: идентичности на каждую рабочую нагрузку, непрерывная проверка и политика на уровне сервиса.

12) Эксплуатация и SLO

SLO: ≥99% успешных рукопожатий, ≥95% трафика на TLS 1.3, 0% смешанного контента.
Алерты: истечение сертификатов (<14 дней), рост отказов рукопожатий, падение доли TLS 1.3, ошибки OCSP stapling.
Процедуры: аварийная замена CA/корня, отзыв скомпрометированного ключа, отключение 0-RTT.

13) Чек-листы

• Отключены TLS 1.0/1.1 и слабые суиты, включены AEAD и PFS.
• ALPN настроен (h2/h3); запрет h2c.
• HSTS включен (для публичных доменов), mixed content отсутствует.
• Сертификаты авто-обновляются, OCSP stapling работает.
• Внутренние каналы защищены mTLS (или эквивалент WireGuard/IPsec).
• Проверена валидация хостов/цепочек в клиентах/SDK.

• Мониторинг версий TLS/ALPN/ошибок и экспираций.
• План crypto-agility (перевод на новые суиты/кривые).
• Периодические пентесты канала и ревью конфигов.

14) FAQ

В: Достаточно ли TLS только на периметре?
О: Нет. Внутренний трафик тоже должен шифроваться (mTLS/туннели/mesh), особенно в облаках и при многоарендности.

В: Нужен ли 0-RTT?
О: Включайте точечно для идемпотентных запросов, иначе — отключить из-за риска реплея.

В: Что выбрать для меж-ЦОД? IPsec или WireGuard?
О: WireGuard проще и быстрый, IPsec — зрелый и широко поддерживаемый. Оба допустимы при правильной конфигурации.

В: Как защитить вебхуки «в пути»?
О: HTTPS с современным профилем + проверка сертификата отправителя (если mTLS) + подпись полезной нагрузки и проверка таймстэмпа (см. «Гарантии доставки вебхуков», «Подпись и верификация запросов»).

• «Шифрование At Rest»
• «Аутентификация и авторизация»
• «Подпись и верификация запросов»
• «S2S-аутентификация»
• «Управление ключами и ротация»