Schlüssel- und Token-Rotation

1) Warum Rotation notwendig ist

Schlüssel und Token „altern“ unweigerlich: Exposition in Logs/Backups, Insiderrisiken, Schwachstellen von Bibliotheken, Lecks bei Partnern. Rotation reduziert die „Risikolebensdauer“ und gibt Beherrschbarkeit bei Vorfällen. Ziel ist es, planbare Rotationszyklen und schnelle Rückrufmechanismen ohne Ausfallzeiten aufzubauen.

2) Bereich: Was genau rotieren wir

Signatur-/Verschlüsselungsschlüssel: JWT (JWS/JWE), OAuth/OIDC, SAML, Webhooks (HMAC), Lizenzen.
Geheimnisse der Integrationen: API-Schlüssel, Client-Geheimnis, technische Passwörter. Benutzer.
TLS/mTLS: Server-/Client-Zertifikate, Root/Intermediate-CAs.
Datenschlüssel: KEK/CMK in KMS/HSM, DEK (Envelope Encryption).
Токены: access/refresh, service-to-service (mTLS, HMAC), short-lived session.

3) Lagerung, Versionen, Etiketten

KMS/HSM/Vault als Quelle der Wahrheit. Es ist verboten, private Schlüssel in git/ENV/Image-Dateien zu speichern.
Versionierung: 'key _ id '/' version' + Tags: 'purpose = jwt-sign', 'env = prod', 'alg = ES256', 'created _ at', 'rotates _ at'.
Zugangsrichtlinien: Prinzip der minimal notwendigen Rechte (least privilege), Aufteilung der Verantwortlichkeiten (SoD).
Audit: wer erstellt/gelesen/unterzeichnet hat; Unveränderliche Protokolle.

4) Grundlegende Rotationsmuster

4. 1 Überlappende Fenster (graceful rollover)

→ veröffentlichen den neuen Schlüssel in JWKS/verteilen das Zertifikat.
Überlappungsfenster: Validierung mit alten und neuen Schlüsseln, Unterschrift nur mit neuen.
Nach Ablauf der Grace-Periode - entfernen Sie die alte aus dem vertrauenswürdigen Satz.

4. 2 Doppelausgabe (Dual-Run)

Eine kurze Zeit, in der ein Teil der Instanzen das Alte unterschreibt, ein Teil das Neue (für große Flöten).
Erfordert ein streng synchronisiertes JWKS und die Überwachung des Anteils der Validierungen durch "kid'.

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

Nach Zeitplan: einmal in N Tagen/Wochen (Signaturschlüssel, TLS).
Bei Verwendung: Refresh-Token - einmalig, für jeden Austausch eine neue Ausgabe („gleitende“ Rotation).

5) JWT/JWKS: Praxis

5. 1 Titel und Kennungen

Verwenden Sie' kid' im JWS-Header, um den Verifizierungsschlüssel auszuwählen.
Minimum von Climes, kurz' exp', korrekt 'aud/iss/nbf'.

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

5. 2 Veröffentlichung JWKS

JWKS muss alle aktiven Validierungsschlüssel enthalten (alt + neu im Grace-Fenster).
JWKS-Caching bei Kunden: kurze TTL (z.B. 5-15 min).
Wenn kompromittiert - Entfernen Sie den kompromittierten Schlüssel von JWKS (scharf), höhere Behinderung des 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 Kadenz und Fristen

JWT-Signatur: Schlüsselrotation alle 3-6 Monate (oder häufiger für hohes Risiko).
„exp“ -Zugangstoken: 5-30 min; refresh - 7-30 Tage (mit „rotate-on-use“).
Erzwungenes „Kleben“ mit PoP/DPoP (siehe § 8), um das Diebstahlrisiko zu reduzieren.

6) HMAC Rotation (Webhooks/Signaturen)

Bewahren Sie aktive und kanarische Geheimnisse auf; Akzeptieren Sie die Unterschriften beider.
Rubriken: „X-Signatur“ + „X-Timestamp“; Fensterbegrenzung ± 300s.
Vollständige Deaktivierung des alten - nachdem der Absender bestätigt gewechselt hat.
Für Partner: Veröffentlichen Sie Datum und Uhrzeit der Umstellung und Endpunktprüfung.

7) TLS/mTLS und Vertrauensketten

ACME/auto-renew für öffentliche Serverzertifikate (Let's Encrypt oder Enterprise CA).
mTLS: kurze Client-Zertifikate (7-30 Tage), automatische Rotation nach Kanal (SPIFFE/SPIRE/mesh).
Die Rotation der dazwischenliegenden/root CA erfolgt nur über sich überlappende Vertrauensanker (trust bundle) und einen langen Kanaren.
Achten Sie auf OCSP/CRL und Clock-Skew. In den Protokollen sind die Gründe für die Ablehnung der Validierung.

8) PoP/DPoP und Bündel token↔klyuch Client

DPoP (Demonstration of Proof-of-Possession): Das Token ist an den Public-Key des Clients gebunden; reduziert das Replay-Risiko.
Kundenschlüsselrotation = Freigabe eines neuen DPoP-Schlüssels, Token - kurzfristig.
Für Service-to-Service wird mTLS bevorzugt (Gerät/Worker „trägt“ Schlüssel im HSM/TPM).

9) Refresh-Token: rotate-on-use

Einmalige Refresh-Token: Jeder Austausch → einen neuen Refresh + Access.
Liste der zurückgezogenen 'jti '/' sid' speichern mit TTL = Lebensdauer refresh.
Wiederverwendungsdetail (Re-Play): sofortiger Rückruf der Sitzung/des Geräts, alert.

10) Widerruf und Sperrlisten

JWT ohne Introspektion: Verwenden Sie die kurze' exp'+ 'blacklists' 'jti' für kritische Fälle (lokal/in Redis, Hashing).
OAuth introspection: zentraler Statusserver; „active = false/true“ mit kurzer TTL zwischenspeichern.
API-Schlüssel: Schlüssel-Hash (als Passwörter), Besitzer/Tenant-Tags, Scope, Erstellungsdatum/letzter Zugriff speichern; Rückruf - sofort.

11) Datenschlüssel: Envelope-Verschlüsselung

CMK/KEK (KMS/HSM) schützt DEK; Die CMK-Rotation findet statt, ohne die Daten zu überlagern: DEK-Wrap.
DEK für jedes Objekt/Tenant/Partei; KDF/HKDF für abgeleitete Schlüssel.
Zerstörungsrichtlinien (Crypto-Shredding): KEK löschen = Unlesbarkeit der Daten bei Kompromittierung.

12) Verfahren für Zwischenfälle (Kompromittierung)

1. Einfrieren: Deaktivieren Sie die Ausgabe von Token auf dem kompromittierten Schlüssel, übertragen Sie die Ausgabe auf einen neuen.
2. Widerrufen: 'kid' aus JWKS entfernen, Zertifikate widerrufen (OCSP/CRL), API-Schlüssel per Liste sperren.
3. TTL reduzieren: „exp“ Token vorübergehend reduzieren, PoP/DPoP-Validierung verstärken.
4. Erzwungene Abmeldung: Sitzungen behindern (revoke' sid '/' jti').
5. Forenzika und Berichterstattung: Zeitlinien, Reichweite, wer/was betroffen ist; Playbooks aktualisieren.

13) Pipeline und Rollout

13. 1 Erzeugung und Veröffentlichung

Generieren Sie Schlüssel in HSM/KMS; Der Export des privaten Schlüssels ist verboten.
Automatische Veröffentlichung von JWKS/Zertifikaten mit Verifizierung und Tests.
Kanarische Freigabe: 1-5% der Kunden → 100%.

13. 2 Gesundheitskontrolle

Metriken: Anteil der Validierungen durch 'kid', Signatur-/Zertifikatfehler, Uhrendrift.
Alerts: 401/403 Spitze wegen Signatur, OCSP/CRL nicht verfügbar, auslaufende Zertifikate (T-30/T-7/T-1).

14) Configs und Beispiele

14. 1 Beispiel für eine Vault/KMS-Richtlinie (Pseudo)

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

14. 2 Beispiel eines JWT-Rotationsplans

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: JWKS-Update erzwingen (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) Beobachtbarkeit und Auditierung

Метрики: `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).
Dashboards: Karte der „Kid“ -Anteile, auslaufende Zertifikate, Abrufquote, nicht valide Unterschriften nach Regionen.

16) Antipatterns

Langlebige JWT ohne Rückruf und ohne kurzes' exp'.
Keine' kid' und 'manuelle' Auswahl des Verifizierungsschlüssels.
Speichern Sie Geheimnisse in ENV/k8s-Secret ohne KMS und ohne Verschlüsselung auf ETCD-Ebene.
Nicht-rotierende Refresh-Token; Wiederverwendung von refresh ohne Detect.
Ein einziger globaler API-Schlüssel „für alle“.
„Stille“ Freigabe neuer Schlüssel ohne JWKS-Veröffentlichung und Monitoring.
Null-Überlappungsfenster (sofortiger Ersatz) → Masse 401/403.

17) Spezifität von iGaming/Finanzen

Regulatoren und Audits: unveränderliche Protokolle von Rotationen/Reviews; Nachweisbarkeit von Zeit und Akteuren.
Partner PSP/KYC: separate Schlüssel pro Partner/Gerichtsbarkeit; schneller Rückruf bei SLA/Sicherheitsverletzungen.
Multiarrangement: per-tenant API-Schlüssel mit Scope; Isolierung von Markenschlüsseln/Regionen.
Hohes Risiko: PoP/DPoP für kritische Operationen, kurze' exp', mTLS zwischen internen Diensten.
Backoffice: SSO/OIDC, kurze Sitzungen, Hardware-Token (FIDO2), allgegenwärtige Rotate-on-Schedule.

18) Checkliste Prod-Ready

• Alle privaten Schlüssel in KMS/HSM/Vault; Export verboten.
• JWKS wird mit einer kurzen TTL veröffentlicht und zwischengespeichert; in den JWT-Schlagzeilen steht "kid'.
• Rotationsplan mit überlappendem Fenster und automatischem Rollout.
• Refresh-Token sind einmalig; Liste der zurückgezogenen „jti“ mit TTL.
• HMAC-Geheimnisse: aktiv + kanarienartig; Empfang von beiden; die T-Schaltzeit wird angekündigt.
• TLS/mTLS: auto-renew, alert T-30/T-7/T-1, trust bundle für CA-Wechsel.
• Envelope-Verschlüsselung: KEK/CMK rotieren ohne Ausfallzeit, DEK per Objekt/Tenant.
• Metriken/Warnungen für Signatur, JWKS, Bewertungen; Dashboards von 'Kid' -Dolls.
• Playbook der Vorfälle (Kompromittierung) und regelmäßige Übungen.
• Kanarische Tests und Validierungsreplikationen mit neuen Schlüsseln/CA.

19) TL; DR

Schlüssel im KMS/HSM aufbewahren, JWT mit 'kid' signieren und JWKS veröffentlichen. Rotieren Sie Schlüssel und Zertifikate mit Überlappung, überwachen Sie die Validierungsanteile von 'kid'. Refresh - Rotate-on-use und kurze' exp'; für kritische Operationen - PoP/DPoP und mTLS. Verwenden Sie für Ihre Daten eine Envelope-Verschlüsselung mit KEK-Rotation ohne Ausfallzeiten. Implementieren Sie Metriken/Alerts, Incident Playbooks und regelmäßige Kanarienrotationen.