Schlüsselverwaltung und Rotation

Die Schlüssel sind die „Wurzeln des Vertrauens“ der Plattform. Das robuste Key Management System (KMS/HSM + Prozesse + Telemetrie) verwandelt Kryptographie von einer einmaligen Integration in den täglichen Betrieb: Schlüssel werden regelmäßig aktualisiert, ihre Verwendung ist transparent, Kompromittierungen werden lokalisiert und Kunden erleben einen Schlüsselwechsel ohne Downtime.

1) Ziele und Grundsätze

Crypto Agility: Die Fähigkeit, den Algorithmus/die Schlüssellänge ohne große Migrationen zu ändern.
Least exposure: private Schlüssel verlassen KMS/HSM nicht; Signatur-/Entschlüsselungsvorgänge - gelöscht.
Kurzlebige Artikel: Token/Sitzungsschlüssel leben Minuten-Stunden, nicht Wochen.
Dual-Key/Dual-Cert Fenster: störungsfreie Rotationen.
Regionale & tenante Isolation: Die Schlüssel sind nach Region und Mieter aufgeteilt.
Volle Auditierbarkeit: unveränderliches Betriebsprotokoll, HSM-Zertifizierung, Zugangskontrolle.

2) Klassifizierung der Schlüssel

Root CA/Master Key (Root CA/Master Key): Extrem seltene Verwendung, im HSM gehalten, zur Freigabe von Zwischenschlüsseln oder Data-Key-Wrappern verwendet.
Operativ: JWT/Event-Signatur, TLS, Webhook-Signatur, Config/PII-Verschlüsselung.
Session/temporär: DPoP, mTLS-Bindung, ECDH-Ausgabe für Kanal/Dialog.
Integration: Partner Schlüssel (öffentlich) und HMAC Geheimnisse.
Data Keys (DEK): verwenden Envelope-Verschlüsselung unter KEK, werden nicht explizit gespeichert.

3) Schlüsselidentifizierung und Nutzungsrichtlinien

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"

Regeln: „ein Ziel - ein Schlüssel“ (Minimum an Scharfmacherei), explizite Anwendungsbereiche und Fristen.

4) Schlüssellebenszyklus (KMS/HSM)

1. Generieren: in HSM/KMS, mit Exportrichtlinie = verboten.
2. Veröffentlichung: für Asymmetrie - JWKS/Zertifikat mit 'kid'.
3. Use: Remote-Operationen (sign/decrypt) mit kontrolliertem IAM.
4. Rotate: Starten Sie den 'next' -Schlüssel und aktivieren Sie Dual-Accept.
5. Retire: Übersetzt das alte in 'retiring', dann 'revoked'.
6. Destroy: Zerstören Sie das Material (mit dem Purge-Protokoll) nach dem Streitfenster.

5) Rotation: Strategien

Geplant: kalendarisch (z.B. alle 1-3 Monate für JWT-Signatur, 6-12 Monate für TLS-Serts).
Rolling: allmählicher Wechsel der Verbraucher (JWKS enthält bereits einen neuen Schlüssel; der Emitter beginnt nach dem Aufwärmen der Caches neu zu signieren).
Forced (Security): sofortige Rotation bei Kompromittierung; kurzes Dual-Accept-Fenster, aggressives Auslaufen von Artefakten.
Staggered per region/tenant: um nicht die ganze Welt gleichzeitig zu „klatschen“.

Die goldene Regel: erst Veröffentlichung, dann Unterschrift neu, und erst nach Ablauf - Widerruf der alten.

6) Dual-Key-Fenster (fehlerfreier Wechsel)

Wir veröffentlichen JWKS mit altem und neuem 'Kid'.
Die Prüfer akzeptieren beides.
Der Emitter beginnt nach N Minuten/Stunden neu zu signieren.
Wir überwachen den Anteil der Kontrollen nach dem alten/neuen 'Kind'.
Wenn der Zielanteil erreicht ist, ist der Retayrim alt.

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) Signatur- und Validierungsrichtlinien

Standardalgorithmen: ES256/EdDSA für die Signatur; RSA-PSS wo erforderlich.
Verbot von 'none '/schwachen Algorithmen; Whitelisting auf der Verifizierungsseite.
Clock skew: Wir erlauben ± 300 c, protokollieren Abweichungen.
Schlüsselpinning (interne Dienste) und kurzer TTL-JWKS-Cache (30-60 s).

8) Envelope-Verschlüsselung und 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

Der KEK (Key Encryption Key) wird im KMS/HSM gespeichert und regelmäßig rotiert.
DEK wird pro Objekt/Partei erstellt; bei KEK-Rotation führen wir Re-Wrap durch (schnell, ohne Re-Verschlüsselung der Daten).
Für Threads - ECDH + HKDF zur Ausgabe von kurzlebigen Kanalschlüsseln.

9) Regionalität und Multi-Tenant

Schlüssel und JWKS sind überregional: 'eu-core', 'latam-core' sind unterschiedliche Schlüsselsätze.
Trennung von IAM/Audit nach Tenant/Region; Schlüssel „fließen“ nicht zwischen Residenzen.
"kid' mit dem Präfix der Vertrauensdomäne:" eu-core-es256-2025-10 ".

10) Geheimnisse der Integrationen (HMAC, API-Schlüssel)

Im KMS-backed Secret Store aufbewahren, Ausgabe über short-lived client secrets (Rotationsrichtlinie ≤ 90 Tage).
Unterstützung von zwei aktiven Geheimnissen (Dual-Secret) während der Rotation.
Für Webhooks - timestamp + HMAC Körpersignatur; Zeitfenster ≤ 5 Min.

11) Zugriffssteuerung und Prozesse

IAM-Matrix: Wer kann 'generate', 'sign', 'decrypt', 'rotate', 'destroy' (Minimum an Rollen).
4-Augen-Prinzip: Empfindliche Operationen erfordern zwei Bestätigungen.
Fenster ändern: Fenster zum Aktivieren eines neuen Schlüssels und Testkanarienregionen.
Runbooks: Prozedurvorlagen für geplante und erzwungene Rotationen.

12) Beobachtbarkeit und Audit

• `sign_p95_ms`, `decrypt_p95_ms`, `jwks_skew_ms`,
• Verbrauch durch „kid“, „old _ kid _ usage _ ratio“,
• `invalid_signature_rate`, `decrypt_failure_rate`.

• Jede Signatur-/Entschlüsselungsoperation: „who/what/when/where/kid/purpose“.
• Historie von Schlüsselzuständen und Rotations-/Revokationsanfragen.
• HSM-Zertifizierung, Zugriffsprotokolle zu Schlüsselmaterialien.

13) Playbooks (Vorfälle)

1. Kompromittierung des Signaturschlüssels

Sofortige Revoke des alten 'Kid' (oder Übersetzung in 'Retiring' mit minimalem Fenster), Veröffentlichung des neuen JWKS, verkürzte TTL-Token, höhere Logout/Invalidität RT, Kommunikation mit den Eigentümern von Integrationen, Retro-Audit.

2. Masse' INVALID _ SIGNATURE 'nach Rotation

Überprüfen Sie den JWKS/Uhr-Skew-Cache, geben Sie Dual-Accept zurück, verlängern Sie das Fenster, senden Sie an Kunden.

3. Anstieg der KMS/HSM-Latenz

Das Aktivieren des lokalen Signaturcaches ist nicht zulässig. stattdessen Batch/Queue am Emitter, Autoscaling HSM Proxy, Priorisierung kritischer Streams.

4. Ausfall einer Region

Aktivierung regionaler Isolationsverfahren; nicht „ziehen“ Schlüssel aus anderen Regionen; Funktionen zu degradieren, die an Signaturen in einer gefallenen Region gebunden sind.

14) Testen

Vertrag: JWKS-Korrektheit, korrektes' kid '/alg/use, Kundenkompatibilität.
Negativ: gefälschte Signatur, veraltetes' Kid', falsches Alg, Clock Skew.
Chaos: sofortige Rotation, KMS-Unzugänglichkeit, „Drift“ der Zeit.
Last: Spitze der Unterschriften (JWT/Webhooks), Spitze der Entschlüsselungen (PII/Auszahlungen).
E2E: Dual-Key-Fenster: Freigabe - Verifizierung - Übertragung des Datenverkehrs - Zurückweisung des alten.

15) Beispielkonfiguration (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) Beispiel für JWKS und Marker in Artefakten

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

Langlebige Schlüssel „für Jahre“ und gemeinsam für alle Regionen.
Rotation „in einem Moment“ ohne Dual-Accept.
Export privater Schlüssel aus KMS/HSM „für Schnelligkeit“.
Aufgabenmischung: Mit einem Schlüssel JWT signieren und Daten verschlüsseln.
Keine Protokolle/Bescheinigungen von HSM und IAM-Beschränkungen.
Kein Re-Wrap-Mechanismus für DEK bei KEK-Rotation.
Manuelle „Geheimnisse“ in env statt Secret Store.

18) Checkliste vor dem Verkauf

• Alle privaten Schlüssel in KMS/HSM; Die IAM-Matrix und das 4-Augen-Prinzip sind abgestimmt.
• Die Richtlinien für Algorithmen, Schlüssellängen und Lebenszeiten sind genehmigt.
• Dual-Key-Prozess mit Überwachung der Anteile durch 'kid' aktiviert.
• Die JWKS wird mit einer kurzen TTL und einer Cashet-Erwärmung veröffentlicht; Kunden akzeptieren ≥2 Schlüssel.
• Envelope-Verschlüsselung: KEK rotiert, DEK re-wrap ohne Ausfallzeiten.
• Regionale Isolation und getrennte Schlüsselsätze nach Tenanten.
• Playbooks für Kompromittierung/Rolling/höhere Rotation; Trainingsläufe.
• Metriken ('old _ kid _ usage _ ratio', 'invalid _ signature _ rate') und Alerts sind enthalten.
• Die contract/negative/chaos/load/E2E Tests sind abgeschlossen.
• Dokumentation für Integrationen: wie man die "Kid' -Schicht behandelt, welche Fenster und Fehlercodes.

Schlussfolgerung

Schlüsselmanagement ist eine operative Disziplin: KMS/HSM als Quelle der Wahrheit, regelmäßige und sichere Rotationen mit Dual-Key, regionale und tenante Isolation, Envelope-Verschlüsselung und Beobachtbarkeit. Wenn Sie diese Regeln befolgen, erhalten Sie eine Kryptokontur, die skalierbar, störungsresistent und für den Auditor leicht zu erklären ist - und Entwickler und Integratoren durchlaufen Änderungen ohne Schmerzen.