În criptarea tranzitului

În criptarea tranzitului

1) Definiția și limitele controlului

Criptarea in-transit este protecția datelor de-a lungul întregii căi de transmisie a rețelei (browser server, service service, agent broker, aplicație de baze de date, centru de date centru de date), astfel încât interceptarea pasivă și atacurile active pe canal să nu dezvăluie conținutul și să nu permită modificarea acestuia fără detectare.

Ce acoperim: API-uri publice și private (HTTP/HTTPS, gRPC), streaming și brokeri (Kafka, NATS, RabbitMQ), WebSocket, baze de date și cache prin rețea, trafic de servicii în cadrul clusterelor, VPPn/între centre de date și nori, cereri DNS, clienți mobili/IoT.

Ce nu acoperim pe deplin: atacuri asupra punctelor finale (compromisul gazdă/browser), vulnerabilități ale aplicațiilor, scurgeri din jurnale/halde. Acest lucru este rezolvat prin controale separate (A&A, minimizarea drepturilor, criptarea în repaus, înregistrarea securizată).

2) Modelul de amenințare și țintele

Riscuri: interceptarea traficului/spoofing (MITM), downgrade protocol/cifru suită, certificate false/CA, scurgeri cheie, atacuri SNI/metadate, conținut mixt, TLS mistermination pe balancers, interconexiuni de servicii nesigure.

1. Confidențialitate + integritate cu autentificare criptografică.

2. Opoziția față de downgrade (politică strictă și configurare).

3. Identificarea părților (server, dacă este necesar - reciproc).

4. Certificat gestionat/ciclu de viață cheie și audit.

5. Profil de performanță fără compromisuri de securitate.

3) Principii de bază

TLS este peste tot în mod implicit. Trafic extern și intern - criptare.
Versiuni moderne. TLS 1. 3 ca standard; TLS 1. 2 - numai în conformitate cu politici stricte. Dezactivează 1. 0/1. 1.
AEAD cifru suite cu PFS. AES-GCM sau ChaCha20-Poly1305; SFP prin DHE (CE).
Curbe/ X25519 de examinare cheie (de preferință) sau secp256r1 (P-256). Cheile RSA ≥2048, mai bune decât ECDSA (P-256).
mTLS în cazul în care încrederea este rară. Canale inter-service, API-uri admin, brokeri, baze de date - prin autentificare reciprocă.
HSTS pentru web. HTTPS forțat + preîncărcare pentru domenii publice.
„Criptați și criptați din nou” în mod conștient. Terminarea TLS pe perimetru + re-criptare la backend sau passphrough end-to-end - selectați în funcție de modelul de amenințare.
Cripto-agilitate. Capacitatea de a schimba curbe/suite/versiuni cu zero downtime.

4) Protocol stivă și scripturi

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

ALPN: h2 pentru HTTP/2, h3 pentru HTTP/3; h2c inhibă (fără LLT).
HTTP/3/QUIC: reduce latența, 0-RTT încorporate și migrația compusă; 0-RTT permit selectiv (risc de reluare).
gRPC: peste h2/h3; obligatoriu TLS, opțional mTLS + per-RPC autorizație.
WebSocket: wss ://numai; în proxies/balancers - upgrade corect și pinning TLS al domeniului.

4. 2 Trafic interservicii și ochiuri de service

Modelul Sidecar (Istio/Linkerd etc.). Automată mTLS, politici de permisiune, rotație certificat.
SPIFFE/SPIRE. Identități de serviciu descentralizate (SPIFFE ID), certificate SVID, TTL-uri scurte.
Parametrii TLS sunt centralizați. Minimizați discrepanțele de configurare în codul de service.

4. 3 Brokeri/Streaming/Cozi

Kafka/NATS/RabbitMQ: TLS pentru kliyent↔broker și broker↔broker; mTLS, dacă este posibil.
SASL peste TLS: dacă mTLS nu este posibil, autentificarea prin jetoane/login-uri, dar criptați canalul.
ACL și autorizarea subiectului. Criptarea ≠ controlul accesului.

4. 4 Baze de date și cache-uri

PostgreSQL/MySQL/SQL Server: activați validarea TLS, CN/SAN, CA pin/root.
Redis/Memcached: utilizați ridichi stunnel/TLS; interzicerea traficului simplu în produs.

4. 5 Rețea/tuneluri

Între centrele de date/nori: IPsec (IKEv2) sau WireGuard (un set modern de primitive).
Acces admin: SSH cu KEH/cifruri moderne; fără parole, doar chei/SSO.

4. 6 protocoale DNS și auxiliare

DNS peste HTTPS (DoH )/DNS peste TLS (DoT) pentru clienți și în cadrul clusterului acolo unde este posibil.
Dezactivați conținutul mixt. Nimic la http ://pe paginile https ://.

5) Certificate, PKI și Key Management

Model PKI: pentru domenii externe - public CA; pentru traficul intern - propriul CA sau SPIRE-CA.
Automatizare: ACME/Cert-manager pentru Kubernetes, scurt TTL, auto-rotație.
OCSP capsare и CRL. Porniți capsarea la fronturi; actualizați în mod regulat lanțurile.
Pinning - cu precauție. În clienții mobile/desktop - pin CA/SPKI cu un mecanism de rulare de urgență.
Cheie de stocare: chei private în HSM/KMS/depozite secrete; expuneri minime; interzicerea exploatării forestiere.

6) Configurații: profiluri de practică

• Versiuni: TLS 1. 3 (necesar), TLS 1. 2 (rezervă).

• 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” (+ opțiuni AES256/CHACHA20 dacă este necesar).
• Curbe: X25519, secp256r1.
• Certificate: ECDSA-preferat, RSA-rezervă.
• Antete securizate: „Strict-Transport-Security”, „X-Content-Type-Options”, „X-Frame-Options” (după caz), „Referrer-Policy”.
• Cookie-uri: 'Secure', 'HttpOnly', 'SameSite' (Lax/Strict prin design).

• Certificatul de client este necesar.
• Scurt client TTL SVID (ore/zile), rotație automată.
• Politici: cine se poate conecta la cine (pe bază de intenție/locul de muncă prin autorizație de plasă).

7) Performanță și fiabilitate

Accelerare hardware: AES-NI/ARMv8 Crypto, preferință ChaCha20-Poly1305 pe procesor fără AES-NI.
Reluarea sesiunii: TLS 1. 3 bilete; gândiți-vă la durata de viață (echilibrul dintre parfum și siguranță).
0-RTT: numai pentru interogări idempotente; protejați împotriva reluării (mecanisme anti-reluare a serverului).
Balansoare/proxy-uri: selectați în mod clar terminarea vs passthrough; la terminare - re-criptare la backend.
Observabilitate: strângere de mână ALPN/eroare/metrici de negociere, procent TLS 1. 3, expirarea certificatului, statutul OCSP.

8) Testarea și verificarea

Scanarea profilului TLS. Verificări periodice ale versiunilor/suitelor/curbelor acceptate și HSTS/OCSP.
Teste negative: interzicerea retrogradării, respingerea costumelor slabe, eșecul conexiunilor fără SNI/fără certificat în lanț valabil.
Canal pentest: simulări MITM, verificări pinning în clienții mobili, 0-RTT încercări de reluare.
Teste de haos: expirarea/revocarea certificatului, indisponibilitatea OCSP/CA.

9) Greșeli frecvente și cum să le evitați

TLS activat, dar nici o validare gazdă. Verificăm întotdeauna CN/SAN, interzicem „InsecureSkipVerify”.
Conținut mixt. Blocați resursele http pe paginile https, utilizați CSP.
Versiuni și costume slabe/învechite. Dezactivați TLS 1. 0/1. 1, CBC/RC4/3DES.
Lipsa de re-criptare interioară. Traficul simplu de la balansor la aplicație este un risc.
Certificate de lungă durată. Faceți TTL-uri scurte și actualizări automate.
Bad SNI/ALPN în spatele proxy. Transmisie SNI/ALPN corectă cu TLS pass/termination.

10) Mini rețete (fragmente de configurare)

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) Politici și conformitate

Cerințe minime: TLS 1. 3 ori de câte ori este posibil; TLS 1. 2 - cu un set limitat de apartamente.
Regulament: PCI DSS/sectorul financiar - interzicerea versiunilor/suitelor slabe; rotație obligatorie și audit.
Abordarea Zero Trust: identități per volum de muncă, validare continuă și politici la nivel de servicii.

12) Funcționare și SLO

SLO: ≥99% strângeri de mână de succes, ≥95% trafic pe TLS 1. 3, 0% conținut mixt.
Alerte: expirarea certificatelor (<14 zile), creșterea eșecurilor strângerii de mână, scăderea cotei TLS 1. 3, erori de capsare OCSP.
Proceduri: înlocuirea de urgență a CA/rădăcină, revocarea cheii compromise, dezactivarea 0-RTT.

13) Liste de verificare

• TLS 1 cu handicap. 0/1. 1 și apartamente slabe, AEAD și PFS incluse.
• ALPN configurat (h2/h3); interzicerea h2c.
• HSTS activat (pentru domeniile publice), fără conținut mixt.
• Certificatele sunt actualizate automat, capsarea OCSP rulează.
• Canalele interne sunt protejate de mTLS (sau echivalent WireGuard/IPsec).
• Validarea gazdei/lanțului validat pe clienți/SDK.

• Monitor TLS/ALPN/eroare și versiuni de expirare.
• Planul de cripto-agilitate (traducere la noi suite/curbe).
• Periodic pentests canal și recenzii config.

14) ÎNTREBĂRI FRECVENTE

Î: Este TLS suficient doar pe perimetru?
Oh, nu. Traficul intern trebuie, de asemenea, criptat (mTLS/tuneluri/plasă), în special în nori și în timpul multi-leasing.

Î: Ai nevoie de un 0-RTT?
R: Activați punctul pentru cereri idempotente, în caz contrar dezactivați din cauza riscului de reluare.

Î: Ce să alegeți pentru centrul inter-data? IPsec sau WireGuard?
R: WireGuard este mai simplu și mai rapid, IPsec este matur și suportat pe scară largă. Ambele sunt valabile atunci când sunt configurate corect.

Î: Cum protejați cârligele web „în mișcare”?
A: HTTPS cu un profil modern + verificarea certificatului de expeditor (dacă mTLS) + semnătura sarcinii utile și verificarea marcajului temporal (a se vedea garanțiile de livrare a broșurii web, semnarea și verificarea cererii).

• „La criptare de odihnă”
• „Autentificare și autorizare”
• „Semnează și verifică cererile”
• „Autentificare S2S”
• „Managementul și rotația cheilor”