Szyfrowanie tranzytu

W szyfrowaniu tranzytu

1) Definicja i granice kontroli

Szyfrowanie tranzytowe to ochrona danych wzdłuż całej ścieżki transmisji sieciowej (przeglądarka, serwer, usługa, agent, broker, aplikacja, centrum danych, centrum danych), tak aby przechwytywanie pasywne i aktywne ataki na kanał nie ujawniały zawartości i nie pozwalały na jej modyfikację bez wykrywania.

Dotyczy to: publicznych i prywatnych interfejsów API (HTTP/HTTPS, gRPC), streamingu i brokerów (Kafka, NATS, RabbitMQ), WebSocket, baz danych i buforów w sieci, ruchu usług w ramach klastrów, VPN/między centra danych i chmury, żądania DNS, klienci mobilni/IoT.

Co nie w pełni obejmuje: ataki na punkty końcowe (kompromis hosta/przeglądarki), luki w aplikacji, wycieki z kłód/porzuceń. Jest to rozwiązywane przez oddzielne sterowanie (A&A, minimalizacja praw, szyfrowanie w spoczynku, bezpieczne rejestrowanie).

2) Model zagrożenia i cele

Ryzyko: przechwytywanie/spoofing ruchu (MITM), protokół downgrade/cipher suite, fałszywe certyfikaty/CA, wyciek klucza, ataki SNI/metadane, mieszane treści, złamanie TLS na balancerach, niepewne połączenia usługowe.

1. Poufność + integralność z uwierzytelnianiem kryptograficznym.

2. Sprzeciw wobec obniżenia oceny (ścisła polityka i konfiguracja).

3. Identyfikacja stron (serwer, jeśli to konieczne - wzajemne).

4. Zarządzany certyfikat/kluczowy cykl życia i audyt.

5. Profil wydajności bez kompromisów.

3) Podstawowe zasady

TLS jest domyślnie wszędzie. Ruch zewnętrzny i wewnętrzny - szyfrowanie.
Nowoczesne wersje. TLS 1. 3 standardowo; TLS 1. 2 - tylko w ramach ścisłej polityki. Wyłączyć 1. 0/1. 1.
Apartamenty z szyframi AEAD z PFS. AES-GCM lub ChaCha20-Poly1305; PFS za pośrednictwem DHE (WE).
Krzywe/ X25519 badania klucza (najlepiej) lub secp256r1 (P-256). Klawisze RSA ≥ 2048, lepsze niż ECDSA (P-256).
mTLS, gdzie brak zaufania. Kanały międzyresortowe, admin API, brokerzy, bazy danych - poprzez wzajemne uwierzytelnianie.
HSTS dla sieci. Wymuszone wstępne obciążenie HTTPS + dla domen publicznych.
„Szyfrowanie i szyfrowanie ponownie” świadomie. TLS-termination na obwodzie + ponowne szyfrowanie do backendów lub end-to-end passsthrough - wybierz według modelu zagrożenia.
Kryptowaluta. Możliwość zmiany krzywych/apartamentów/wersji z zerowym przestojem.

4) Stos protokołu i skrypty

4. 1 HTTP/2, HTTP/3 (QUIC), gRPC, WebSocket

ALPN: h2 dla HTTP/2, h3 dla HTTP/3; h2c inhibitor (bez TLS).
HTTP/3/QUIC: zmniejsza opóźnienia, wbudowane 0-RTT i migrację złożoną; 0-RTT wybiórczo (powtórzyć ryzyko).
gRPC: powyżej h2/h3; obowiązkowe TLS, opcjonalne zezwolenie mTLS + per-RPC.
WebSocket: tylko wsi ://; w serwerach proxy/równoważnikach - poprawne uaktualnienie i przypięcie TLS domeny.

4. 2 Ruch międzyresortowy i oczka usługowe

Model Sidecar (Istio/Linkerd itp.). Automatyczny mTLS, zasady uprawnień, rotacja certyfikatów.
SPIFFE/SPIRE. Zdecentralizowane identyfikatory usług (SPIFFE ID), certyfikaty SVID, krótkie TTL.
Parametry TLS są scentralizowane. Zminimalizuj rozbieżności konfiguracyjne w kodzie serwisowym.

4. 3 Brokerzy/Streaming/Kolejki

Kafka/NATS/RabbitMQ: TLS dla kliyent i brokera mTLS, jeśli to możliwe.
SASL over TLS: jeśli mTLS nie jest możliwe, uwierzytelnianie przez żetony/loginy, ale szyfrowanie kanału.
ACL i autoryzacja tematu. Kontrola szyfrowania.

4. 4 Bazy danych i bufory

PostgreSQL/MySQL/SQL Server: enable TLS, CN/SAN validation, CA pin/root.
Redis/Memcached: używać rzodkiewek/TLS; zakaz zwykłego ruchu w produkcie.

4. 5 Sieci/tuneli

Pomiędzy centrami danych/chmurami: IPsec (IKEv2) lub WireGuard (nowoczesny zestaw prymitywnych).
Dostęp administratora: SSH z nowoczesnymi szyframi KEH; bez haseł, tylko klucze/SSO.

4. 6 DNS i protokoły pomocnicze

DNS przez HTTPS (DoH )/DNS przez TLS (DoT) dla klientów i w klastrze w miarę możliwości.
Wyłączyć mieszane treści. Nic na http ://na stronach https ://.

5) Certyfikaty, PKI i zarządzanie kluczami

Model PKI: dla domen zewnętrznych - publiczne CA; dla ruchu wewnętrznego - własny CA lub SPIRE-CA.
Automatyzacja: ACME/Cert-manager dla Kubernetes, krótki TTL, auto-rotacja.
OCSP stapling - CRL. Włącz zszywanie na frontach; regularnie aktualizować łańcuchy.
Szpilki - z ostrożnością. W klientach mobilnych/pulpitowych - pin CA/SPKI z mechanizmem awaryjnego walcowania.
Przechowywanie kluczy: klucze prywatne w HSM/KMS/tajne magazyny; minimalne ekspozycje; zakaz pozyskiwania drewna.

6) Konfiguracje: profile praktyczne

• Wersje: TLS 1. 3 (wymagane), TLS 1. 2 (awaryjny).

• 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” (+ opcje AES256/CHACHA20 w razie potrzeby).
• Krzywe: X25519, secp256r1.
• Certyfikaty: preferowane przez ECDSA, RSA-fallback.
• Bezpieczne nagłówki: „Ścisłe bezpieczeństwo transportu”, „X-Content-Type-Options”, „X-Frame-Options” (indywidualnie), „Referrer-Policy”.
• Pliki cookie: „Bezpieczne”, „Jedynki”, „Witryna internetowa” (Lax/Strict według projektu).

• Wymagany jest certyfikat klienta.
• Krótki klient TTL SVID (godziny/dni), automatyczna rotacja.
• Polityka: kto może połączyć się z kim (intencja/praca poprzez autoryzację siatki).

7) Wydajność i niezawodność

Przyspieszenie sprzętu: AES-NI/ARMv8 Crypto, preferencje ChaCha20-Poly1305 na procesorze bez AES-NI.
Wznowienie sesji: TLS 1. 3 bilety; zastanów się nad życiem (równowaga między perfumami a bezpieczeństwem).
0-RTT: tylko dla idempotentnych zapytań; chronić przed powtórzeniem (mechanizmy anty-replay serwera).
Balancery/proxy: wyraźnie wybrać zakończenie vs passthrough; w momencie zakończenia - ponowne zaszyfrowanie do backendu.
Obserwowalność: ALPN uścisk dłoni/błąd/metryki negocjacyjne, TLS procent 1. 3, wygaśnięcie certyfikatu, status OCSP.

8) Badanie i weryfikacja

Skanowanie profilu TLS. Regularne kontrole obsługiwanych wersji/apartamentów/krzywych i HSTS/OCSP.
Testy negatywne: zakaz obniżania jakości, odrzucenie słabych kombinezonów, awaria połączeń bez SNI/bez ważnego certyfikatu łańcucha.
Kanał pentest: symulacje MITM, sprawdzanie szpilek u klientów mobilnych 0-RTT powtarzanie prób.
Testy chaosu: wygaśnięcie/cofnięcie certyfikatu, niedostępność OCSP/CA.

9) Częste błędy i jak ich uniknąć

Włączony TLS, ale brak walidacji hosta. Zawsze sprawdzamy CN/SAN, zakazujemy „InsecureSkipVerify”.
Zawartość mieszana. Blokuj zasoby http na stronach https, użyj CSP.
Słabe/przestarzałe wersje i kombinezony. Wyłączyć TLS 1. 0/1. 1, CBC/RC4/3DES.
Brak wewnętrznego ponownego szyfrowania. Zwykły ruch od balancera do aplikacji jest ryzykiem.
Długotrwałe świadectwa. Zrób krótkie TTL i automatyczne aktualizacje.
Zły SNI/ALPN za serwerem proxy. Poprawna transmisja SNI/ALPN z TLS pass/termination.

10) Mini przepisy (fragmenty konfiguracji)

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) Polityka i zgodność

Minimalne wymagania: TLS 1. 3 w miarę możliwości; TLS 1. 2 - z ograniczonym zestawem apartamentów.
Rozporządzenie: PCI DSS/sektor finansowy - zakaz słabych wersji/apartamentów; obowiązkowa rotacja i audyt.
Podejście Zero Trust: tożsamość na obciążenie pracą, ciągła walidacja i zasady poziomu usług.

12) Obsługa i SLO

SLO: ≥ 99% udanych uścisków dłoni, ≥ 95% ruchu na TLS 1. 3, 0% mieszanej zawartości.
Wpisy: wygaśnięcie certyfikatów (<14 dni), wzrost awarii uścisku dłoni, spadek udziału TLS 1. 3, błędy zszywające OCSP.
Procedury: awaryjna wymiana CA/korzenia, cofnięcie naruszonego klucza, wyłączenie 0-RTT.

13) Listy kontrolne

• Wyłączony TLS 1. 0/1. 1 i słabe apartamenty, AEAD i PFS zawarte.
• ALPN skonfigurowany (h2/h3); zakaz stosowania h2c.
• Włączony system HSTS (dla domen publicznych), bez mieszanych treści.
• Certyfikaty są automatycznie aktualizowane, działa zszywanie OCSP.
• Kanały wewnętrzne są chronione przez mTLS (lub równoważnik WireGuard/IPsec).
• Zatwierdzona walidacja hosta/łańcucha na klientach/SDK.

• Monitoruj wersje błędów i wygaśnięcia TLS/ALPN.
• Plan Crypto-Agility (tłumaczenie na nowe apartamenty/krzywe).
• Okresowe pentesty kanałów i przeglądy konfig.

14) FAQ

P: Czy TLS wystarczy tylko na obwodzie?
Och nie. Ruch wewnętrzny musi być również szyfrowany (mTLS/tunele/siatka), zwłaszcza w chmurach i w czasie wielu dzierżawy.

P: Czy potrzebujesz 0-RTT?
Odp.: Włącz spojrzenie na idempotentne żądania, w przeciwnym razie wyłączyć ze względu na ryzyko powtórzenia.

P: Co wybrać dla inter-data center? IPsec czy WireGuard?
Odp.: WireGuard jest prostszy i szybszy, IPsec jest dojrzały i szeroko obsługiwany. Oba są ważne po poprawnym skonfigurowaniu.

P: Jak chronić haki internetowe „w drodze”?
Odp.: HTTPS z nowoczesnym profilem + weryfikacja certyfikatu nadawcy (jeśli mTLS) + podpis ładunku i weryfikacja znacznika czasu (patrz Gwarancje dostawy Webhook, Żądanie podpisania i weryfikacji).

• „W odpoczynku szyfrowanie”
• „Uwierzytelnianie i autoryzacja”
• „Podpisz i zweryfikuj żądania”
• „Uwierzytelnianie S2S”
• „Kluczowe zarządzanie i rotacja”