Gestione e rotazione delle chiavi

Le chiavi sono le radici della fiducia della piattaforma. Un sistema affidabile di gestione delle chiavi (KMS/HSM + processi + telemetria) trasforma la crittografia da una singola integrazione a un'operazione quotidiana: le chiavi vengono aggiornate regolarmente, utilizzate in modo trasparente, le compromissioni vengono localizzate e i clienti subiscono un cambio di chiave senza downtime.

1) Obiettivi e principi

Crypto agility: possibilità di cambiare algoritmo/lunghezza della chiave senza grandi migrazioni.
Least exposure: le chiavi private non lasciano KMS/HSM; Le operazioni di firma/decriptazione sono cancellate.
Short-lived artists: token/chiavi di sessione vivono minuti-ore, non settimane.
Finestra dual-key/Dual-cert - Rotazioni senza interruzioni.
Regione & tenant isolation: le chiavi sono suddivise per regione e per affittacamere.
Full auditability: registro delle operazioni invariato, certificazione HSM, controllo degli accessi.

2) Classificazione chiavi

Radici (Root CA/Master Key) - Un uso estremamente raro, mantenuto in HSM, viene utilizzato per il rilascio di chiavi intermedie o data-key.
Operativi: firma JWT/eventi, TLS, firma webhoop, crittografia configh/PII.
Sessione/Temporaneo: DPoP, mTLS-binding, output ECCH per canale/interazione.
Integrazioni: le chiavi dei partner (pubbliche) e i segreti HMAC.
Data Keys (DEK) - Utilizzano la crittografia envelope sotto KEK e non vengono memorizzati esplicitamente.

3) Identificazione chiavi e criteri di utilizzo

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"

Regole: «Un obiettivo è una sola chiave» (minimo di sharing), applicazioni esplicite e tempi.

4) Ciclo di vita chiave (KMS/HSM)

1. Generate: in HSM/KMS, con criterio di esportazione = non consentito.
2. Publish - Per l'asimmetria - JWKS/certificato con «kid».
3. Usa - Operazioni remote (sign/decrypt) con IAM controllato.
4. Rotate: avvia la chiave «next» e attiva il dual-accept.
5. Retire: tradurre il vecchio in «retiring», quindi «revoked».
6. Destroy - Distrugge il materiale (con il protocollo purge) dopo la finestra delle controversie.

5) Rotazione: strategie

Scheduled è un calendario (ad esempio, ogni 1-3 mesi per la firma JWT, 6-12 mes per i sarti TLS).
Rolling: failover dei consumatori (JWKS contiene già una nuova chiave; l'emettitore inizia a firmare nuovo dopo aver riscaldato le caselle).
Forced (security): rotazione immediata durante la compromissione; breve finestra dual-accept, terminazione aggressiva degli artefatti.
Staggered per region/tenant per non «applaudire» il mondo contemporaneamente.

Regola d'oro: prima la pubblicazione, poi la firma nuova, e solo dopo la scadenza, il richiamo del vecchio.

6) Finestra di dialogo Dual-key (cambio inattivo)

Pubblichiamo JWKS con il vecchio e il nuovo «kid».
I collaudatori accettano entrambi.
L'emittente inizia a firmare tra minuti e ore.
Monitor la quota di controlli del vecchio/nuovo «kid».
Al raggiungimento del target retairim è vecchio.

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) Criteri di firma e convalida

Algoritmi predefiniti: ES256/EdDSA per la firma; RSA-PSS se necessario.
Proibizione dì none "/algoritmi deboli; whitelisting sul lato della verifica.
Clock skew - Tolleriamo © 300 c, logifichiamo le deviazioni.
Key pinning (servizi interni) e TTL breve cache JWKS (30-60 s).

8) Crittografia envelope e 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 (Key Encryption Key) viene memorizzato in KMS/HSM, rotabile regolarmente.
DEK viene creato su un oggetto/partitura; durante la rotazione di KEK eseguiamo re-wrap (rapidamente, senza e-crittografia dei dati).
Per i thread - ECCH + HKDF per visualizzare le chiavi di canale a breve durata.

9) Regionalità e multi-tenente

Le chiavi e JWKS sono peroregionali: «eu-core», «latam-core» sono diversi set di chiavi.
Suddivisione IAM/verifica per tenant/region; Non ci sono chiavi tra i residenti.
«kid» codifica con il prefisso del dominio di fiducia: «eu-core-es256-2025-10».

10) I segreti delle integrazioni (HMAC, API)

Memorizza in KMS-backed Secret Store tramite short-lived client secret (rotation policy da 90 giorni).
Supporta due segreti attivi (dual-secret) durante la rotazione.

Per i webhoop - timestamp + HMAC firma corpo; finestra di tempo 5 minuti

11) Controllo dell'accesso e dei processi

Matrice IAM: chi può «generate», «sign», «decrypt», «rotate», «destroy» (minimo ruoli).
Principio a quattro occhi: le operazioni sensibili richiedono due conferme.
Change windows - Le finestre di abilitazione della nuova chiave e le aree canarie di prova.
Runbooks - Modelli di procedure per le rotazioni scheduled e forced.

12) Osservazione e verifica

• `sign_p95_ms`, `decrypt_p95_ms`, `jwks_skew_ms`,
• consumo «kid», «old _ kid _ usage _ ratio»,
• `invalid_signature_rate`, `decrypt_failure_rate`.

• Ogni operazione di firma/decriptazione: 'who/what/when/where/kid/purpose'.
• Cronologia degli stati delle chiavi e delle richieste di rotazione/rotazione.
• Certificazione HSM, registri di accesso ai materiali chiave.

13) Playbook (incidenti)

1. Compromettere la chiave di firma

Revoke immediato del vecchio «kid» (o traduzione in «retiring» con finestra minima), pubblicazione di un nuovo JWKS, TTL TTL token, forza-logout/invalidità RT, comunicazioni ai proprietari delle integrazioni, controllo retro.

2. «INVALID _ SIGNATURE» di massa dopo la rotazione

Controlla la cache JWKS/clock skew, restituisce dual-accept, estende la finestra e invia ai clienti.

3. Aumento della latitanza KMS/HSM

Impossibile attivare la cache locale delle firme. invece - batch/queue all'emittente, autoscaling proxy HSM, priorità dei flussi critici.

4. Rifiuto di una regione

Attivare le procedure di isolamento regionale; non «tirare» le chiavi da altre regioni; degradare le funzioni legate alle firme in una regione caduta.

14) Test

Contract: correttezza JWKS, corretti «kid »/alg/use, compatibilità client.
Negative: firma falsa, «kid» obsoleto, alg sbagliato, clock skew.
Chaos: rotazione immediata, indisponibilità di KMS, «deriva» del tempo.
Load: picco di firme (JWT/webhooks), picco di decifrazione (PII/pagamento).
E2E: finestra dual-key: rilascio - convalida - trasferimento del traffico - Decollatura del vecchio.

15) Esempio di configurazione (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) Esempio di JWKS e marcatori nei manufatti

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-pattern

Chiavi a lunga vita «anni» e comuni a tutte le regioni.
Rotazione in un momento senza dual-accept.
Esportazione di chiavi private da KMS/HSM per la rapidità.
Combinazione di attività: firma JWT con una sola chiave e cifra i dati.
Nessun registro/certificato HSM e restrizioni IAM.
Nessun meccanismo re-wrap per DEK durante la rotazione KEK.
«Segreti» manuali, invece del Secret Store.

18) Foglio di assegno prima della vendita

• Tutte le chiavi private in KMS/HSM; Matrice IAM e principio a 4 occhi sono configurati.
• I criteri degli algoritmi, la lunghezza delle chiavi e la durata della vita sono approvati.
• È stato attivato un processo dual-key con il monitoraggio della quota «kid».
• JWKS viene pubblicato con una TTL corta e una macchia riscaldata; I clienti accettano le chiavi ≥2.
• Crittografia evelope: KEK rotabile, DEK re-wrap senza interruzione.
• Isolamento regionale e set di chiavi separati per tenanti.
• playbook di compromissione/rolling/forza rotazione; Prove di addestramento.
• Le metriche ('old _ kid _ usage _ ratio', 'invalid _ firma _ rate') e gli alert sono inclusi.
• Set di test contract/negative/chaos/load/E2E completato.
• Documentazione per le integrazioni: come gestire il cambio «kid», quali finestre e codici di errore.

Conclusione

La gestione delle chiavi è una disciplina operativa: KMS/HSM come fonte di verità, rotazioni regolari e sicure con dual-key, isolamento regionale e tenante, crittografia envelope e osservabilità. Seguendo queste regole, si ottiene un cryptocontorno che è scalabile, resistente agli incidenti e facile da spiegare al revisore - e gli sviluppatori e gli integratori stanno vivendo qualsiasi cambiamento senza dolore.