Criptare și protecție API: TLS, HSTS, PFS, rotație secretă

1) Imaginea amenințării și țintele

API-uri sub atac MitM, interceptarea traficului, atacuri downgrade, spoofing token, scurgeri cheie și abuz de secrete de lungă durată. Obiective de protecție:

Confidențialitate și integritate (TLS 1. 3 + cifruri puternice).
Protecție împotriva downgrade/stripping (HSTS, versiuni interzise/cifruri).
Minimizarea daunelor de compromis (PFS, TTL scurt, rotație rapidă).
Autentificare fiabilă client/serviciu (mTLS/jetoane) și trasabilitate.

2) TLS ca bază (server și service-to-service)

Versiuni și cifruri:

Implicit este TLS 1. 3; permite TLS 1. 2 numai pentru compatibilitate. Dezactivează 1. 1/1. 0.

Criptare prioritară TLS 1. 3:

'TLS _ AES _ 128 _ GCM _ SHA256', 'TLS _ AES _ 256 _ GCM _ SHA384', 'TLS _ CHACHA20 _ POLY1305 _ SHA256'.
Pentru TLS 1. 2: numai ECDHE cu AES-GCM/ChaCha20 și semnătură ECDSA/RSA (ex. „ECDHE-ECDSA-AES128-GCM-SHA256”).

Chei și certificate:

Chei de server: ECDSA P-256/P-384 (mai rapid și mai scurt) sau RSA 2048 +/3072.
Chei client pentru mTLS: ECDSA P-256; emiterea prin propriul CA sau plata HSM/KMS.
Activați capsarea OCSP, de preferință cu pavilionul Must-Capse și ALPN (HTTP/2/3).

SFP (Perfect Forward Secret):

Furnizate de schimburi efemere (ECDHE) - chiar dacă cheia serverului s-a scurs, sesiunile trecute nu pot fi decriptate.
Forțați un acord static DH/RSA cheie.

Adăugări moderne:

ECH (Encrypted Client Hello), dacă este acceptat de front/CDN, ascunde SNI.
HTTP/2/3 numai cu cifruri puternice; interzicerea HTTP neprotejat, redirecționarea către HTTPS.

3) HSTS vs TLS-stripping

Activați HTTP Strict Transport Security pe domeniul rădăcină și subdomenii:


Strict-Transport-Securitate: max-age = 63072000; includeSubDomenii; preîncărcare

Plasați domeniul în lista de preîncărcare HSTS.

Urmăriți corectitudinea înainte de publicare (rollback este dificil).

4) Autentificare reciprocă: mTLS și/sau jetoane

mTLS între microservicii/API-uri interne: certificate bidirecționale, rotație automată prin plasă de serviciu (Istio/Linkerd) sau PKI brevetat.

Clienți API (integrări mobile/partenere): jetoane (OAuth2/OIDC, JWT), mTLS opțional pentru risc ridicat.

Pentru fronturi publice: TLS + jetoane OAuth2/OIDC cu durată scurtă de viață cu legare dispozitiv/DPoP.

5) Certificat și gestionarea ciclului de viață

Automatizarea ACME (de exemplu, Let's Encrypt/Organizational CA) cu actualizare automată cu 30 de zile înainte de expirare.

Durata scurtă de viață a certificatelor (≤ 90 de zile) + monitorizarea termenelor limită, a alertelor și a pachetelor de utilizare a canarului.

PKI centralizat: rădăcină/intermediar CA, CRL/OCSP, lansări de audit și revocare.

Exemplu de nginx (fragment):

nginx ssl_protocols TLSv1. 3 TLSv1. 2;
   ;
ssl_prefer_server_ciphers pe;
   ;
ssl_stapling pe; ssl_stapling_verify pe;
add_header Strict-Transport-Securitate "max-age = 63072000; includeSubDomenii; preîncărcare" întotdeauna;

6) Rotație secretă: principii și modele

Obiectivele de rotație: limitați „raza explozivă” a scurgerilor, reduceți timpul de abuz și asigurați eliberări fără sudură.

Reguli de bază:

Stocarea secretelor numai în managerul secret (KMS/Vault/Cloud SM). Fără secrete în Git/imagini.
Scurt TTL și rotație automată: chei de semnătură, parole de baze de date, chei API furnizor.
Fereastra cu două taste: tastele vechi și noi sunt active simultan pentru perioada de rulare.
Versioning + kid (pentru JWT/JWKS), fereastră „grace” pentru validarea jetoanelor vechi.

Ce să se rotească în mod regulat:

Chei JWT (semnătură/criptare), secrete HMAC ale webhookurilor și apelurilor, parole/conturi de baze de date, cache-uri (Redis), jetoane CI/CD, secrete furnizor (KYC/AML, plăți, SMS/e-mail), SSH - automated chei.

Declanșatorii rotației neprogramate: suspiciunea de scurgere, concedierea angajaților cu acces, schimbarea furnizorului, cerințele autorității de reglementare.

7) JWT/JWKS: Suprapunere sigură a rolului

Publicați punctul final JWKS cu cheia actuală și viitoare („copil” necesar).

Procedura de rotație:

1. Generați o nouă cheie → adăugați-o la JWKS ca o „a doua” cheie.

2. Actualizați semnatarii → emiteți jetoane noi cu o nouă cheie.

3. Așteptați pentru TTL de jetoane vechi → a elimina cheia veche de la JWKS.

Instalați jetoane TTL scurte (de exemplu, 5-15 minute) + fluxuri de reîmprospătare cu verificare suplimentară.

8) Managementul secret în practică

KMS + criptare plic: cheie master în HSM/KMS, datele sunt criptate cu „înfășurat” DEK.

Vault/Cloud Secret Manager: credite dinamice în baza de date (emiterea de înregistrări cu TTL), rotație periodică.

Kubernetes: Secrete externe/Secrete Magazin CSI; etcd criptare; RBAC; interzicerea secretelor de exploatare forestieră.

Accesul la rol: IAM/ABAC, principiul celor mai mici privilegii, limitele hardware (HSM, TPM).

Audit complet: cine, ce, când, de ce a citit/schimbat.

9) Protecția transportului în interiorul perimetrului

Nu aveți încredere în „rețeaua internă”: peste tot TLS/mTLS (zero-trust).

Service mesh automatizează certificatele, repornirea și rotirea, observabilitatea (mTLS în mod implicit).

Minimizați terminarea TLS: fie margine + criptat numai est-vest, sau end-to-end criptare.

10) API prin politici de securitate TLS

Rata de limitare/protecție DoS, verificarea semnăturilor de cârlig web (HMAC cu rotație secretă).

Content-Security-Policy/Referrer-Policy/X-Content-Type-Options для фронта.

mTLS pentru critic endpoints (plăți, panoul de administrare), IP allow-list by partners.

Protecție replay: timestamp + nonce în cereri semnate, ferestre nu mai mult de 5 minute.

11) Monitorizare și încercări

Observabilitatea TLS: versiuni/cifruri în valori, alerte pentru încercări de downgrade, o creștere a eșecurilor de strângere de mână.

Scanere (în CI/CD și în mod regulat în vânzări): verificarea cifrurilor acceptate, certificatelor, HSTS, OCSP.

Exerciții de haos/DR: expirarea certificatului, căderea managerului secret, compromiterea cheii de semnătură - verificați planurile de reacție.

12) Proceduri de răspuns

Compromis cheie: revocarea imediată a certificatului/îndepărtarea cheii de la JWKS, inversarea la backup, regenerarea forțată a tokenului.

Expirarea fără reînnoire: degradarea temporară (numai traficul intern), reinstalarea automată a certificatelor.

Raport incident: cronologie, subiecți afectați, piese Tech., măsuri corective.

13) Verificare rapidă Listă de verificare (prod-ready)

Numai TLS 1. 3 (+ 1. 2 pentru legasi), o listă strictă de cifruri.
HSTS с „preîncărcare”, OCSP capsare, ALPN.
ECDHE pentru SFP; ECDSA P-256/384 sau RSA 3072.
mTLS în cadrul clusterului/între serviciile critice.
JWKS + copil, jetoane TTL scurte, plan de rotație.
Secretele - numai în KMS/Vault, auto-rotație de baze de date/furnizori.
Reînnoirea automată a certificatelor (ACME), alerte în 30 de zile.

Verificarea CI/CD a anteturilor de securitate și a cifrurilor vulnerabile.

Runbook documentat 'și: rotație, rechemare, incidente.

Rezumat reluare

Protecția API fiabilă este o combinație de TLS 1. 3 + HSTS + PFS ca o cheie minimă și matură obligatorie și procese de management secret. Adăugați mTLS între servicii, automatizați eliberarea/rotirea prin KMS/Vault/mesh, păstrați TTL-uri scurte și ferestre duble la schimbarea cheilor - și veți minimiza riscurile de interceptare, downgrade și abuz de scurgeri de secrete fără a rupe disponibilitatea și viteza produsului.