Rotație cheie și token

1) De ce este necesară rotația

Chei și jetoane inevitabil „vârstă”: expunere în jurnale/backup-uri, riscuri insider, vulnerabilități bibliotecă, scurgeri de informații de la parteneri. Rotația reduce „durata de viață a riscului” și oferă controlabilitate în incidente. Scopul este de a construi cicluri de rotație previzibile și mecanisme rapide de rechemare fără downtime.

2) Zona: ce anume ne rotim

Chei de semnătură/criptare: JWT (JWS/JWE), OAuth/OIDC, SAML, webhooks (HMAC), licențe.
Secrete de integrare: chei API, secret client, parole tech. utilizatori.
TLS/mTLS: certificate de server/client, CA-uri root/intermediare.
Chei de date: KEK/CMK în KMS/HSM, DEK (criptare plic).
Токены: acces/reîmprospătare, service-to-service (mTLS, HMAC), sesiune de scurtă durată.

3) Stocare, versiuni, etichete

KMS/HSM/Vault ca sursă de adevăr. Este interzisă stocarea cheilor private în fișierele git/ENV/image.
Versioning: 'key _ id'/' version' + labels: 'purpose = jwt-sign',' env = prod ',' alg = ES256 ',' created _ at ',' rotates _ at '.
Politici de acces: principiul drepturilor minime necesare (cel mai mic privilegiu), separarea sarcinilor (SoD).
Audit: cine a creat/citit/semnat; jurnalele imuabile.

4) Modele de rotație de bază

4. 1 Ferestre suprapuse (rollover grațios)

Publicăm noul → cheie în JWKS/distribuim certificatul.
Suprapuneți fereastra: validare cu chei vechi și noi, semnătură - numai cu altele noi.
După expirarea perioadei de grație, ștergeți-l pe cel vechi din setul de încredere.

4. 2 Dual-run

O perioadă scurtă în care o parte din cazuri semnează vechi, parte - nou (pentru flote mari).
Necesită un JWKS strict sincronizat și monitorizarea procentului de validări de către „copil”.

4. 3 Rotire la program vs rotire la utilizare

Programat: o dată la fiecare N zile/săptămâni (tastele de semnătură, TLS).
Când utilizați: reîmprospătați jetoanele - o singură dată, pentru fiecare versiune de schimb nouă (rotație „glisantă”).

5) JWT/JWKS: Practică

5. 1 Titluri și identificatori

Utilizați „kid” în antetul JWS pentru a selecta o cheie de verificare.
Clime minime, scurt „exp”, corect „aud/iss/nbf”.

json
{ "alg": "ES256", "kid": "jwt-2025-10", "typ": "JWT" }

5. 2 Publicația JWKS

JWKS trebuie să conțină toate cheile de validare active (vechi + nou în fereastra de grație).
Client JWKS cache: scurt TTL (ex. 5-15 min).
Dacă este compromisă, scoateți cheia compromisă din JWKS (brusc), forța-invaliditate a memoriei cache.

json
{
"keys": [
{ "kty":"EC","crv":"P-256","kid":"jwt-2025-10","use":"sig","alg":"ES256","x":"...","y":"..." },
{ "kty":"EC","crv":"P-256","kid":"jwt-2025-07","use":"sig","alg":"ES256","x":"...","y":"..." }
]
}

5. 3 Cadență și sincronizare

Semnătură JWT: rotire cheie la fiecare 3-6 luni (sau mai des pentru risc ridicat).
"exp 'access-token: 5-30 min; refresh - 7-30 zile (cu „rotire-la-utilizare”).
„Lipirea” forțată cu PoP/DPoP (vezi § 8) pentru a reduce riscul de furt.

6) Rotație HMAC (webhooks/semnături)

Păstrați secrete active și canare; acceptă semnături de la ambele.
Titluri: „X-Signature” + „X-Timestamp”; limitarea ferestrelor ± 30 de ani.
Deconectarea completă a celui vechi - după ce expeditorul a confirmat.
Pentru parteneri, publicați data de comutare și verificările punctului final.

7) TLS/mTLS și lanțuri de încredere

ACME/auto-reînnoire pentru certificatele de server publice (Let's Encrypt or enterprise CA).
mTLS: certificate de client scurte (7-30 zile), rotație automată prin canale (SPIFFE/SPIRE/mesh).
Rotație CA intermediară/rădăcină - numai prin suprapunerea ancorelor de încredere și a canarului lung.
Păstrați un ochi pe OCSP/CRL și ceas-skew. În jurnalele - motivele pentru eșecul de validare.

8) PoP/DPoP și pachet de token↔klyuch client

DPoP (Demonstrarea dovezii posesiei): tokenul este legat de cheia publică a clientului; reduce riscul de reluare.
Rotație cheie client = eliberarea unei noi chei DPoP, tokene - pentru o perioadă scurtă de timp.
Pentru service-to-service, se preferă mTLS (dispozitivul/lucrătorul „poartă” cheia în HSM/TPM).

9) Actualizați jetoanele: rotiți-la-utilizare

Token-uri de reîmprospătare unică: fiecare schimb → un nou acces la refresh +.
Lista magazinului „jti ”/„ sid” rechemat cu TTL = reîmprospătare pe viață.
Reutilizați detectarea (re-play): sesiune imediată/rechemare dispozitiv, alertă.

10) Rechemare și liste de blocuri

JWT fără introspecție: utilizați scurte „exp” + „liste negre” „jti” pentru cazurile critice (local/în Redis, hash sharding).
Introspecția OAuth: cache-ul serverului de stare centralizat „activ = fals/adevărat” cu un TTL scurt.
chei API: magazin cheie hash (cum ar fi parolele), etichete proprietar/chiriaș, domeniul de aplicare, crearea/ultima data de acces; rechemare - instant.

11) Chei de date: criptare plic

CMK/KEK (KMS/HSM) protejează DEK; Rotația CMK are loc fără revelarea datelor: re-wrap DEK.
DEK pentru fiecare obiect/chiriaș/parte; KDF/HKDF pentru chei derivate.
Politici de distrugere a criptelor: ștergerea KEK = date necitite atunci când sunt compromise.

12) Proceduri incidente (compromis)

1. Freeze: dezactivați emiterea tokenului pe o cheie compromisă, transferați emiterea către una nouă.
2. Revocați: eliminați 'kid' din JWKS, revocați certificatele (OCSP/CRL), blocați cheile API din listă.
3. Reduceți TTL: reduceți temporar jetoanele „exp”, consolidați verificarea PoP/DPoP.
4. Deconectare forțată: dezactivați sesiunile (revocați „sid ”/„ jti”).
5. Criminalistică și raportare: termene, acoperire, cine/ce a suferit; actualizați cărțile de redare.

13) Conducte și rollout

13. 1 Generare și publicare

Generarea cheilor în HSM/KMS; exportul privat de chei - interzis.
Publicarea automată a certificatelor JWKS/cu verificare și încercări.
Eliberare canar: 1-5% dintre clienți → 100%.

13. 2 Controlul sănătății

Valori: proporția validărilor prin „copil”, erorile de semnătură/certificat, deriva ceasului.
Alerte: 401/403 spike din cauza semnăturii, OCSP/CRL indisponibil, certificate care expiră (T-30/T-7/T-1).

14) Configurări și exemple

14. 1 Exemplu de politică privind seiful/KMS (Pseudo)

hcl path "transit/keys/jwt-prod" {
capabilities = ["read," "update," "list"] # signature/rotation
}
path "transit/keys/jwt-prod/rotate" {
capabilities = ["update"]
}

14. 2 Plan de rotație JWT Exemplu

T0: create a new version of the key (kid = jwt-2025-10), add to JWKS
T0 + 15m: start signing with a new kid; validate with old and new
T0 + 7d: remove old kid from JWKS
T0 + 30d: delete old private key from KMS (schedule purge)

14. 3 Envoy: forța JWKS actualizare (pseudo)

yaml jwt_authn:
providers:
oidc:
issuer: https://auth. example. com/
remote_jwks:
http_uri:
uri: https://auth. example. com/.well-known/jwks. json cluster: jwks_cluster timeout: 2s cache_duration: 300s # короткий TTL

15) Observabilitate și audit

Метрики: 'jwt _ verify _ fail _ total {reason}', 'jwks _ refresh _ total', 'jwks _ kid _ share {kid}', 'token _ revoced _ total', 'refresh _ rotations _ total', 'dpop _ fail _ total'.
Логи: 'kid', 'jti', 'sid', 'reason', 'client _ id',' chiriaş ',' trace _ id' (без PII).
Tablouri de bord: card de partajare „kid”, certificate care expiră, frecvență de rechemare, semnături nevalide pe regiuni.

16) Antipattern

JWT-uri de lungă durată fără rechemare și fără „exp” scurt.
Absența 'kid' și selectarea „manuală” a cheii de verificare.
Stocarea secretelor în ENV/k8s-Secret fără KMS și fără criptare la nivel etcd.
Token-uri de reîmprospătare non-rotative; refresh refresh fără detectare.
O singură cheie API globală „pentru toți”.
Eliberarea „liniștită” a noilor chei fără publicarea și monitorizarea JWKS.
Zero suprapunere ferestre (înlocuire instantanee) → masa 401/403.

17) Specificul iGaming/Finanțe

Regulatoare și audit: jurnale neschimbabile de rotații/rechemări; probabilitatea timpului și a actorilor.
Partener PSP/KYC: chei separate pentru fiecare partener/jurisdicție; rechemare rapidă pentru încălcări SLA/siguranță.
Multi-leasing: chei API per chiriaș cu domeniu de aplicare; izolarea cheilor de brand/regiune.
Risc ridicat: PoP/DPoP pentru operațiuni critice, short 'exp', mTLS între serviciile interne.
Backoffice: SSO/OIDC, sesiuni scurte, jetoane hardware (FIDO2), rotire omniprezentă la program.

18) Lista de verificare Prod Readiness

• Toate cheile private în KMS/HSM/Vault; exportul interzis.
• JWKS este publicat și cache cu scurt TTL; există un „copil” în titlurile JWT.
• Plan de rotație cu fereastră suprapusă și rollout automat.
• Jetoanele de reîmprospătare sunt de unică folosință; lista „jti” -urilor revocate cu TTL.
• Secrete HMAC: activ + canar; recepția de către ambele; Timpul de comutare T declarat.
• TLS/mTLS: auto-reînnoire, alerte T-30/T-7/T-1, pachet de încredere pentru schimbarea CA.
• Criptare plic: KEK/CMK rotit fără downtime, DEK pe obiect/chiriaș.
• Metrici/alerte după semnătură, JWKS, feedback; tablouri de bord „copil” -deals.
• Playbook incident (compromis) și exerciții regulate.
• Teste de replici canare și validare cu chei noi/CA.

19) TL; DR

Păstrați cheile în KMS/HSM, semnați JWT cu „kid” și postați JWKS. Rotiți cheile și certificatele cu suprapunere, monitorizați acțiunile de validare prin „copil”. Refresh - rotire la utilizare și scurt „exp”; pentru operațiuni critice - PoP/DPoP și mTLS. Pentru date, utilizați criptarea plicului cu rotația KEK fără întreruperi. Implementați valori/alerte, cărți de redare incidente și rotații canare regulate.