Шифрування In Transit

Шифрування In Transit

1) Визначення та межі контролю

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

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

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

2) Модель загроз і цілі

Ризики: перехоплення/підміна трафіку (MITM), даунгрейд протоколу/шифросуїт, підроблені сертифікати/СА, витік ключів, атаки на 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 для kliyent↔broker і broker↔broker; по можливості - mTLS.
SASL поверх TLS: якщо мTLS неможливий, аутентифікація - за токенами/логінами, але канал шифрувати.
ACL і авторизація тем. Шифрування ≠ контроль доступу.

4. 4 Бази даних і кеші

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

4. 5 Мережа/тунелі

Між ЦОД/хмарами: IPsec (IKEv2) або WireGuard (сучасний набір примітивів).
Адмін-доступ: SSH з сучасними КЕХ/шифрами; заборона паролів, тільки ключі/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.
Процедури: аварійна заміна СА/кореня, відкликання скомпрометованого ключа, відключення 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-автентифікація»
• «Управління ключами та ротація»