Managementul și rotația cheilor

Cheile sunt rădăcinile de încredere ale platformei. "Un sistem fiabil de management al cheilor (procese KMS/HSM + + telemetrie) transformă criptografia dintr-o integrare unică într-o operațiune de zi cu zi: cheile sunt actualizate în mod regulat, utilizarea lor este transparentă, compromisurile sunt localizate, iar clienții experimentează o schimbare cheie fără întreruperi.

1) Obiective și principii

Agilitate cripto: capacitatea de a schimba algoritmul/lungimea cheii fără migrații mari.
Cea mai mică expunere: cheile private nu părăsesc KMS/HSM; operațiunile de semnătură/decriptare - eliminate.
Artefacte de scurtă durată: Jetoane/chei de sesiune live minute-ore, nu săptămâni.
Ferestre dual-key/Dual-cert: rotații sigure.
Izolarea regională și a chiriașilor: cheile sunt împărțite în funcție de regiune și chiriaș.
Auditabilitate completă: jurnal de tranzacții imuabil, calificare HSM, control acces.

2) Clasificare cheie

Root CA/Master Key: utilizare extrem de rară, păstrată în HSM, utilizată pentru a elibera chei intermediare sau ambalaje cu chei de date.
Operare: semnătură JWT/eveniment, TLS, semnătură webhook, criptare config/PII.
Sesiune/timp: DPoP, mTLS-legare, ECDH-ieșire pentru canal/dialog.
Integrare: Chei partenere (publice) și secrete HMAC.
Cheile de date (DEK): utilizați criptarea plicului sub KEK, nu sunt stocate explicit.

3) Politica cheie de identificare și utilizare

yaml key:
kid: "eu-core-es256-2025-10"
alg: "ES256"         # или EdDSA, RSA-PSS, AES-GCM, XChaCha20-Poly1305 purpose: ["jwt-sign","webhook-sign"]
scope: ["tenant:brand_eu","region:EE"]
status: "active"       # active      next      retiring      revoked created_at: "2025-10-15T08:00:00Z"
valid_to:  "2026-01-15T08:00:00Z"

Reguli: „un obiectiv - o cheie” (partajare minimă), domenii explicite de aplicare și calendar.

4) Ciclul de viață cheie (KMS/HSM)

1. Generați: în HSM/KMS, cu politica de export = negat.
2. Publish: pentru asimetrie - JWKS/certificat cu „copil”.
3. Utilizare: operații la distanță (semn/decriptare) cu IAM controlat.
4. Rotiți: executați tasta 'next' și activați dual-accept.
5. Pensionați: traduceți vechiul în „pensionare”, apoi „revocat”.
6. Distruge: distruge materialul (cu protocolul de purjare) după fereastra de dispută.

5) Rotație: Strategii

Programat: calendar (de exemplu, la fiecare 1-3 luni pentru semnătura JWT, 6-12 luni pentru TLS-serts).
Rulare: schimbarea treptată a consumatorilor (JWKS conține deja o nouă cheie; emițătorul începe să semneze nou după încălzirea cache-urilor).
Forțat (securitate): rotație imediată la compromis; scurt fereastră dual-accept, expirarea agresivă a artefactelor.
Eșalonat pe regiune/chiriaș: pentru a nu „bate” întreaga lume în același timp.

Regula de aur: mai întâi publicarea, apoi semnătura este nouă și numai după expirare - rechemarea celui vechi.

6) fereastră cu două taste

Publicăm JWKS cu vechiul şi noul „copil”.
Verificatorii le acceptă pe amândouă.
Emitter în N minute/ore începe semnarea nou.
Monitorizăm ponderea verificărilor vechiului/noului „copil”.
La atingerea cotei țintă, recuperarea este veche.

yaml jwks:
keys:
- kid: "eu-core-es256-2025-10" # new alg: "ES256"
use: "sig"
crv: "P-256"
x: "<...>"; y: "<...>"
- kid: "eu-core-es256-2025-07" # old alg: "ES256"
use: "sig"
...

7) Politici de semnare și validare

Algoritmi impliciți: ES256/EdDSA de semnătură; RSA-PSS acolo unde este necesar.
Interzicerea algoritmilor „none ”/slabi; lista albă pe partea de verificare.
Înclinare ceas: permitem ± 300 c, deviații jurnal.
Pinning cheie (servicii interne) și o scurtă memorie cache TTL JWKS (30-60 s).

8) Criptarea plicurilor și KDF

ciphertext = AEAD_Encrypt(DEK, plaintext, AAD=tenant    region    table    row_id)
DEK = KMS. Decrypt (KEK, EncryptedDEK )//on access
EncryptedDEK = KMS. Encrypt (KEK, DEK )//on write

KEK (Cheie de criptare a cheilor) este stocat în KMS/HSM, rotit în mod regulat.
DEK este creat pe obiect/lot; atunci când rotim KEK, efectuăm re-wrap (rapid, fără recriptare de date).
Pentru fluxuri - ECDH + HKDF la tastele de canal de ieșire de scurtă durată.

9) Regionalitate și multi-chiriaș

Cheile și JWKS sunt regionalizate: „eu-core”, „latam-core” sunt seturi diferite de chei.
Separarea IAM/audit pe chiriaș/regiune; cheile nu „curg” între reședințe.
"kid 'code cu prefix de domeniu de încredere:" eu-core-es256-2025-10 ".

10) Secretele de integrare (HMAC, chei API)

Magazin în KMS-susținute Secret Store, problema prin secrete de client de scurtă durată (politica de rotație ≤ 90 de zile).
Suport pentru două secrete active (dual-secret) în timpul rotației.
Pentru webhookuri - timestamp + semnătură corporală HMAC; fereastra de timp ≤ 5 min.

11) Controlul accesului și procesele

Matricea IAM: cine poate 'genera', 'semna', 'decripta', 'roti', 'distruge' (roluri minime).
Principiul 4-ochi: operațiile sensibile necesită două confirmări.
Schimbați ferestrele: ferestre pentru a permite o nouă cheie și regiuni canare de testare.
Runbooks: șabloane de procedură pentru rotații programate și forțate.

12) Observabilitate și audit

• 'sign _ p95 _ ms',' decrypt _ p95 _ ms', 'jwks _ skew _ ms',
• consum prin 'kid', 'old _ kid _ usage _ ratio',
• 'invalid _ signature _ rate', 'decrypt _ failure _ rate'.

• Fiecare operație de semnătură/decriptare este „cine/ce/când/unde/copil/scop”.
• Istoria statutului cheie și a cererilor de rotație/revocare.
• Calificare HSM, jurnale de acces materiale cheie.

13) Playbook-uri (incidente)

1. Compromisul cheii de semnătură

Revocarea imediată a vechiului „copil” (sau traducerea în „pensionare” cu o fereastră minimă), publicarea unui nou JWKS, scurtarea jetoanelor TTL, forțarea deconectării/dizabilității RT, comunicarea către proprietarii de integrare, auditul retro.

2. Mass' INVALID _ SEMNĂTURA 'după rotație

Verificați cache-ul JWKS/ceas, returnați dual-accept, extindeți fereastra, distribuiți clienților.

3. Creșterea latenței KMS/HSM

Nu este permisă activarea memoriei cache cu semnătură locală; în schimb - lot/coadă la emițător, autoscaling proxy HSM, prioritizarea fluxurilor critice.

4. Eșecul unei regiuni

Activarea procedurilor de izolare regională; nu „trage” cheile din alte regiuni; funcții degrade legate de semnături într-o regiune căzută.

14) Testarea

Contract: corectitudine JWKS, corectitudine 'kid '/alg/use, compatibilitate client.
Negativ: semnătură falsă, „copil” învechit, alg incorect, înclinare a ceasului.
Haos: rotație instantanee, indisponibilitate KMS, derivă în timp.
Încărcare: semnături de vârf (JWT/webhooks), decriptări de vârf (PII/plăți).
E2E: fereastră cu două taste: eliberare - verificare - transfer de trafic - respingerea celui vechi.

15) Exemplu de configurare (YAML)

yaml crypto:
regions:
- id: "eu-core"
jwks_url: "https://sts. eu/.well-known/jwks. json"
rotation:
jwt_sign: { interval_days: 30, window_dual: "48h" }
webhook: { interval_days: 60, window_dual: "72h" }
kek:   { interval_days: 90, action: "rewrap" }
alg_policy:
sign: ["ES256","EdDSA"]
tls: ["TLS1. 2+","ECDSA_P256"]
publish:
jwks_cache_ttl: "60s"
audit:
hsm_attestation_required: true two_person_rule: true

16) Exemplu de JWKS și markeri în artefacte

json
{ "alg":"ES256", "kid":"eu-core-es256-2025-10", "typ":"JWT" }

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

17) Anti-modele

Cheile de lungă durată „de ani” și comune tuturor regiunilor.
Rotație „la un moment dat” fără dual-accept.
Exportați chei private de la KMS/HSM „pentru viteză”.
Amestecarea sarcinilor: semnați JWT și criptați datele cu o singură cheie.
Absența jurnalelor/calificărilor HSM și a restricțiilor IAM.
Nu există nici un mecanism de re-wrap pentru DEK în rotația KEK.
Manual „secrete” în env în loc de Secret Store.

18) Lista de verificare pre-vânzare

• Toate cheile private în KMS/HSM; Matricea IAM și principiul 4-ochi sunt reglate.
• Politicile algoritmului, lungimile cheie și durata de viață sunt aprobate.
• A fost activat procesul cu două taste cu monitorizarea partajării „kid”.
• JWKS este publicat cu TTL scurt și încălzirea cache; clienții acceptă ≥2 cheie.
• Criptare plic: KEK se rotește, DEK re-wrap fără downtime.
• Izolare regională și seturi cheie separate de chiriași.
• Compromise/rulare/rotație forță playbooks; cursurile de instruire.
• Metrics ('old _ kid _ usage _ ratio', 'invalid _ signature _ rate') și alertele sunt activate.
• contract/negative/chaos/load/E2E test suite trecut.
• Documentație pentru integrări: cum să se ocupe de 'kid' shift, care ferestre și coduri de eroare.

Concluzie

Managementul cheie este o disciplină operațională: KMS/HSM ca sursă de adevăr, rotații regulate și sigure cu dublă cheie, izolare regională și chiriașă, criptare plicuri și observabilitate. Respectând aceste reguli, obțineți un contur cripto care scalează, este rezistent la incidente și ușor de explicat auditorului - iar dezvoltatorii și integratorii experimentează orice schimbare fără durere.