Rotazione di chiavi e token

1) Perché è necessaria la rotazione

Le chiavi e i token sono inevitabilmente «invecchiati», ovvero l'esposizione in cassetti/cassetti, i rischi di insider, le vulnerabilità delle librerie, le perdite nei partner. La rotazione riduce il tempo di vita dei rischi e permette la gestione degli incidenti. L'obiettivo è costruire cicli di rotazione prevedibili e meccanismi di ritiro rapido senza interruzioni.

2) Area: cosa rotiamo esattamente

Le chiavi di firma/crittografia sono JWT (JWS/JWE), OAUTH/OIDC, SAML, webhook (HMAC), licenze.
I segreti delle integrazioni sono chiavi API, client secret, password della tecnologia. utenti.
TLS/mTLS: certificati server/client, CA radice/intermedia.
Chiavi dati: KEK/CMK in KMS/HSM, DEK (encryption).
Токены: access/refresh, service-to-service (mTLS, HMAC), short-lived session.

3) Memorizzazione, versioni, etichette

KMS/HSM/Vault come fonte di verità. Non è consentito memorizzare chiavi private in git/ENG/file di immagine.
Versioning: «key _ id »/« variante» + etichette: «purpose = jwt-sign», «ev = prod», «alg = ES256», «created _ at», «ratates _ at».
Criteri di accesso: principio dei diritti minimi necessari (least privilege), separazione dei doveri (SoD).
Controllo: chi ha creato/letto/firmato; registri immutabili.

4) Pattern di rotazione di base

4. 1 Finestre sovrapposte (graceful rollover)

Pubblichiamo la nuova chiave in JWKS/Distribuiamo il certificato.
Finestra di sovrapposizione: convalida con chiavi vecchie e nuove, firma solo nuova.
Dopo la scadenza del periodo grace - Rimuoviamo il vecchio dal set di fiducia.

4. 2 Doppia versione (dual-run)

Un breve periodo in cui alcune istanze sono firmate da vecchie, una parte da nuove (per flirt di grandi dimensioni).
Richiede una JWKS rigorosamente sincronizzata e il monitoraggio della percentuale di validazioni per «kid».

4. 3 Rotate-on-schedule vs rotate-on-use

Programmato ogni N giorni/settimane (chiavi di firma, TLS).
Se utilizzato, i token refresh sono usa e getta per ogni scambio di un nuovo rilascio (rotazione «scorrevole»).

5) JWT/JWKS: pratica

5. 1 Intestazioni e ID

Usa «kid» nell'intestazione JWS per selezionare la chiave di verifica.
Minimo clim, breve «exp», corretti «aud/iss/nbf».

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

5. 2 Pubblicazione JWKS

JWKS deve contenere tutte le chiavi di convalida attive (vecchia + nuova nella finestra grace).
JWKS Cache client: TTL breve (ad esempio 5-15 min).
Durante la compromissione - Rimuove la chiave compromessa da JWKS (brusca) e la cache in forza-invalidità.

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 Cadence e scadenze

Firma JWT: rotazione della chiave ogni 3-6 mes (o più frequentemente per high-risk).
'exp'access-token: 5-30 min; refresh - 7-30 giorni (con «rotate-on-use»).
Collaggio forzato con PoP/DPoP (vedere l'articolo 8) per ridurre il rischio di furto.

6) Rotazione HMAC (webhoop/firme)

Mantenere i segreti attivi e canarini; Accettate entrambe le firme.
Intestazioni: 'X-Signature' + 'X-Timestamp'; vincolo della finestra © 300s.
Disattivazione completa del vecchio - dopo che il mittente è stato attivato.
Per i partner, pubblicare data e ora di cambio e endpoint convalida.

7) TLS/mTLS e catene di fiducia

ACME/auto-renew per certificati server pubblici (Le's Encrypt o CA aziendale).
mTLS: certificati client brevi (7-30 giorni), rotazione automatica via canale (SPIFFE/SPIRE/mesh).
Rotazione CA intermedio/radice - solo attraverso ancoraggi di fiducia sovrapposti (trust bundle) e lungo canary.
Controlla OCSP/CRL e clock-skew. Nel covo c'è il motivo per cui la convalida è fallita.

8) PoP/DPoP e token↔klyuch del cliente

DPoP (Demonstration of Proof-of-Position) - Il token è associato a un client public-key. riduce il rischio di replay.
Rotazione della chiave client = rilascio di una nuova chiave DPoP, token per un breve periodo.
Per il servizio-a-servizio è preferibile il mTLS (il dispositivo/worker «porta» la chiave in HSM/TPM).

9) Token refresh: rotate-on-use

Token refresh monouso: ogni scambio → un nuovo refresh + access.
L'elenco di «jti »/« sid» ritirati è memorizzato con TTL = durata della vita refresh.
Oggetto di riutilizzo (re-play): revoca immediata della sessione/dispositivo, alert.

10) Revoca e liste di blocco

JWT senza introspezione: usa un breve «exp» + «black list» «jti» per le valigette critiche (locale/in Redis, charding su hashtag).
OAUth introspection: server di stato centralizzato nella cache «active = false/true» con TTL breve.
Chiavi API: memorizza hash chiave (come password), etichette proprietario/tenante, scope, data di creazione/ultimo accesso la recensione è istantanea.

11) Chiavi dati: crittografia invelope

CMK/KEK (KMS/HSM) protegge DEK; la rotazione CMK avviene senza sovrascrivere i dati: pene-wrap DEK.
DEK per ogni oggetto/tenente/partitura; KDF/HKDF per chiavi derivate.
Criteri di distruzione (crypto-shredding) - Elimina KEK = illeggibilità dei dati in caso di compromissione.

12) Procedure di incidente (compromissione)

1. Congelare, disattivare il rilascio dei token su una chiave compromessa, trasferire il rilascio su una nuova.
2. Ritira: rimuovi «kid» da JWKS, annulla certificati (OCSP/CRL), blocca chiavi API nell'elenco.
3. Riduci TTL: riduce temporaneamente gli «exp» dei token, rafforza il controllo dei PoP/DPoP.
4. Forzare logout - Disabilita sessioni (revoke 'sid '/' jti').
5. Forenzica e rendicontazione: timeline, copertura, chi/cosa ha sofferto; Aggiorna le playbook.

13) Pipline e rollout

13. 1 Generazione e pubblicazione

Generare le chiavi in HSM/KMS; esportare una chiave privata è vietato.
Pubblicazione automatica di JWKS/certificati con verifiche e test.
Rilascio canario: 1-5% dei clienti → 100%.

13. 2 Controllo della salute

Metriche: percentuale di validazioni per «kid», errori di firma/certificato, deriva dell'orologio.
Alert: picco 401/403 a causa della firma, OCSP/CRL non disponibile certificati in scadenza (T-30/T-7/T-1).

14) Confighi e esempi

14. 1 Esempio di criterio Vault/KMS (pseudo)

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

14. 2 Esempio di piano di rotazione JWT

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 Avvoy: aggiornamento JWKS forzato (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) Osservazione e verifica

Метрики: `jwt_verify_fail_total{reason}`, `jwks_refresh_total`, `jwks_kid_share{kid}`, `token_revoked_total`, `refresh_rotations_total`, `dpop_fail_total`.
Логи: `kid`, `jti`, `sid`, `reason`, `client_id`, `tenant`, `trace_id` (без PII).
Dashboard: carta di quota «kid», certificati in scadenza, frequenza di richiamo, firme non veloci per regione.

16) Antipattern

JWT a lunga vita senza richiamo e senza breve «exp».
Nessuna chiave di convalida «kid» e «manuale».
Memorizzazione dei segreti in EV/k8s-Secret senza KMS e senza crittografia a livello etcd.
token refresh non rotanti; riutilizzo refresh senza dettaglio.
Un'unica chiave API globale «su tutti».
Rilascio silenzioso di nuove chiavi senza pubblicazione di JWKS e monitoraggio.
Le finestre di sovrapposizione zero (sostituzione istantanea) sono di massa 401/403.

17) Specificità iGaming/finanza

Regolatori e verifiche: logici di rotazioni/recensioni invariati; la prova del tempo e degli attori.
Partner PSP/KYC: singole chiavi per partner/giurisdizione; recensione rapida in caso di violazione di SLA/sicurezza.
Multiutility: chiavi API per-tenant con scope; isolamento delle chiavi delle marche e delle regioni.
Alto rischio: PoP/DPoP per operazioni critiche, brevi «exp», mTLS tra servizi interni.
Backoffice: SSO/OIDC, brevi sessioni, token hardware (FIDO2), rotate-on-schedule.

18) Assegno-foglio prod-pronto

• Tutte le chiavi private in KMS/HSM/Vault; esportazione non consentita.
• JWKS viene pubblicato e memorizzato nella cache con TTL breve; nelle intestazioni JWT c'è «kid».
• Piano di rotazione con finestra sovrapposta e rollout automatico.
• Token refresh usa e getta; l'elenco dei «jti» ritirati con TTL.
• HMAC-segreti: attivo + canarino; accettazione da entrambe; Tempo di cambio T annunciato.
• TLS/mTLS: auto-renew, alert T-30/T-7/T-1, trust bundle per il cambio CA.
• Crittografia evelope: KEK/CMK rotano senza interruzione, DEK per oggetto/tenante.
• Metriche/alert per firma, JWKS, recensioni; dashbord'kid ', dashboard'.
• Playbook incidenti (compromissione) e esercitazioni regolari.
• Test canary e repliche di convalida con nuove chiavi/SA.

19) TL; DR

Tenete le chiavi in KMS/HSM, firmate JWT con «kid» e pubblicate JWKS. Rotare le chiavi e i certificati sovrapposti, tenere traccia delle quote di validazione per «kid». Refresh - rotate-on-use e brevi «exp»; per le operazioni critiche, PoP/DPoP e mTLS. Per i dati, utilizzare la crittografia envelope con rotazione KEK senza interruzioni. Incorporare metriche/alert, playbook di incidenti e rotazioni canarie regolari.