API-Verschlüsselung und Schutz: TLS, HSTS, PFS, Secret Rotation

1) Bedrohungsbild und Ziele

API unter MitM-Angriff, Traffic-Abfangen, Downgrade-Angriffe, Token-Fälschungen, Schlüssellecks und Missbrauch langlebiger Geheimnisse. Schutzziele:

Vertraulichkeit und Integrität (TLS 1. 3 + starke Chiffren).
Schutz vor Downgrade/Stripping (HSTS, verbotene Versionen/Chiffren).
Minimierung von Kompromittierungsschäden (PFS, kurze TTL, schnelle Rotation).
Zuverlässige Client/Service-Authentifizierung (mTLS/Token) und Traceability.

2) TLS als Basis (Server und Service-to-Service)

Versionen und Chiffren:

Standardmäßig ist TLS 1. 3; TLS 1 zulassen. 2 nur aus Kompatibilitätsgründen. 1. Deaktivieren. 1/1. 0.

Vorrangige TLS-Verschlüsselungen 1. 3:

`TLS_AES_128_GCM_SHA256`, `TLS_AES_256_GCM_SHA384`, `TLS_CHACHA20_POLY1305_SHA256`.
Für TLS 1. 2: nur ECDHE mit AES-GCM/ChaCha20 und ECDSA/RSA-Signatur (z. B. „ECDHE-ECDSA-AES128-GCM-SHA256“).

Schlüssel und Zertifikate:

Server-Schlüssel: ECDSA P-256/P-384 (schneller und kürzer) oder RSA 2048 +/3072.
Clientschlüssel für mTLS: ECDSA P-256; Ausgabe über Ihre eigene CA oder Zahlung HSM/KMS.
Aktivieren Sie OCSP-Stapeln, vorzugsweise mit einem Must-Staple-Flag, und ALPN (HTTP/2/3).

PFS (Perfect Forward Secrecy):

Wird durch ephemeren Austausch (ECDHE) bereitgestellt - selbst wenn der Serverschlüssel undicht ist, können vergangene Sitzungen nicht entschlüsselt werden.
Deaktivieren Sie die statische DH/RSA-Schlüsselvereinbarung.

Moderne Ergänzungen:

ECH (Encrypted Client Hello), wenn Front/CDN unterstützt wird, blendet SNI aus.
HTTP/2/3 nur mit starken Chiffren; Verbot von ungeschütztem HTTP, Umleitung auf HTTPS.

3) HSTS gegen TLS-Stripping

Aktivieren Sie HTTP Strict Transport Security auf der Stammdomäne und den Subdomänen:


Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Platzieren Sie Ihre Domain in der HSTS preload Liste.

Achten Sie vor der Veröffentlichung auf Korrektheit (Rollback schwierig).

4) Gegenseitige Authentifizierung: mTLS und/oder Token

mTLS zwischen Microservices/internen APIs: bilaterale Zertifikate, automatische Rotation über Service Mesh (Istio/Linkerd) oder eigene PKI.

API-Clients (Mobile/Affiliate-Integrationen): Token (OAuth2/OIDC, JWT), optional mTLS für High-Risk.

Für öffentliche Fronten: TLS + kurzlebige OAuth2/OIDC Token mit Gerätebezug/DPoP.

5) Zertifikats- und Lebenszyklusmanagement

ACME-Automatisierung (z.B. Let's Encrypt/Organizational CA) mit Auto-Update 30 Tage vor Ablauf.

Kurze Lebensdauer von Zertifikaten (≤ 90 Tage) + Timing-Monitoring, Alerts und kanarische Deploy-Pakete.

Zentrale PKI: Root/Intermediate CA, CRL/OCSP, Release und Recall Audit.

Beispiel nginx (Fragment):

nginx ssl_protocols TLSv1. 3 TLSv1. 2;
ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256;
ssl_prefer_server_ciphers on;
ssl_ecdh_curve X25519:P-256:P-384;
ssl_stapling on; ssl_stapling_verify on;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

6) Rotation der Geheimnisse: Prinzipien und Muster

Rotationsziele: Begrenzung des „Explosionsradius“ von Lecks, Reduzierung der Missbrauchszeiten, Sicherstellung nahtloser Freigaben.

Grundregeln:

Speichern von Geheimnissen nur im Secret Manager (KMS/Vault/Cloud SM). Keine Geheimnisse in Git/Bildern.
Kurze TTLs und automatische Rotation: Signaturschlüssel, DB-Passwörter, Provider-API-Schlüssel.
Doppel-Publishing (Dual-Key-Fenster): Alte und neue Schlüssel sind gleichzeitig für die Rolldauer aktiv.
Versionierung + kid (für JWT/JWKS), „grace“ Fenster zur Validierung alter Token.

Was regelmäßig rotieren:

JWT-Schlüssel (Signatur/Verschlüsselung), HMAC-Geheimnisse von Webhooks und Callbacks, Passwörter/DB-Konten, Credits für Caches (Redis), CI/CD-Token, Anbietergeheimnisse (KYC/AML, Zahlungen, SMS/E-Mail), SSH Automatisierungsschlüssel.

Auslöser der außerplanmäßigen Rotation: Verdacht auf Leck, Kündigung von Mitarbeitern mit Zugang, Lieferantenwechsel, regulatorische Anforderungen.

7) JWT/JWKS: Sicheres Rollenspiel-Overlay

Veröffentlichen Sie den JWKS-Endpunkt mit dem aktuellen und zukünftigen Schlüssel ('kid' ist erforderlich).

Rotationsverfahren:

1. Generieren Sie einen neuen Schlüssel → fügen Sie ihn als „zweiten“ JWKS hinzu.

2. Unterzeichner aktualisieren → neue Token mit einem neuen Schlüssel freigeben.

3. Warten Sie auf die TTL der alten Token → entfernen Sie den alten Schlüssel aus dem JWKS.

Installieren Sie kurze TTL-Token (z. B. 5-15 Minuten) + Refresh-Streams mit zusätzlicher Validierung.

8) Secret Management in der Praxis

KMS + envelope encryption: Der Hauptschlüssel im HSM/KMS, die Daten werden mit „wrapped“ DEK verschlüsselt.

Vault/Cloud Secret Manager: dynamische Credits für die DB (Ausgabe von Wissenschaftlern mit TTL), periodische Rotation.

Kubernetes: External Secrets/Secrets Store CSI; Verschlüsselung von etcd; RBAC; Verbot der Protokollierung von Geheimnissen.

Zugriff nach Rolle: IAM/ABAC, Prinzip der geringsten Privilegien, Hardware-Grenzen (HSM, TPM).

Vollständiges Audit: wer, was, wann, warum gelesen/geändert.

9) Transportschutz innerhalb des Perimeters

Vertrauen Sie nicht dem „internen Netzwerk“: TLS/mTLS (Zero-Trust) ist überall.

Service mesh automatisiert Zertifikate, Neustart und Rotation, Beobachtbarkeit (mTLS default).

Minimieren Sie TLS-Terminierungen: entweder nur auf Edge + verschlüsselte Ost-West oder Ende-zu-Ende-Verschlüsselung.

10) API-Sicherheitsrichtlinien über TLS

Rate Limiting/DoS-Schutz, Überprüfung der Signatur von Webhooks (HMAC mit Secret Rotation).

Content-Security-Policy/Referrer-Policy/X-Content-Type-Options для фронта.

mTLS für kritische Endpunkte (Auszahlungen, Admin), IP-Allow-Liste nach Partnern.

Replay-Schutz: timestamp + nonce in signierten Abfragen, Fenster nicht länger als 5 Minuten.

11) Überwachung und Tests

TLS-Beobachtbarkeit: Versionen/Chiffren in Metriken, Warnungen bei Downgrade-Versuchen, Zunahme von Handshake-Fehlern.

Scanner (in CI/CD und regelmäßig in der Produktion): Überprüfung der unterstützten Chiffren, Zertifikate, HSTS, OCSP.

Chaos/DR-Übungen: Zertifikat verfallen, Secret Manager fällt, Signaturschlüssel kompromittiert - Reaktionspläne prüfen.

12) Reaktionsverfahren

Schlüsselkompromittierung: sofortiger Widerruf des Zertifikats/Entfernen des Schlüssels aus JWKS, Fallback, erzwungene Token-Regeneration.

Ablauf ohne Verlängerung: vorübergehende Degradierung (nur interner Datenverkehr), automatische Neuinstallation von Zertifikaten.

Incident Report: Timeline, Betroffene, Tech. Details, Korrekturmaßnahmen.

13) Checkliste zur Schnellprüfung (prod-ready)

Nur TLS 1. 3 (+ 1. 2 für Legacy), eine strenge Liste von Chiffren.
HSTS с `preload`, OCSP stapling, ALPN.
ECDHE für PFS; ECDSA P-256/384 oder RSA 3072
mTLS innerhalb eines Clusters/zwischen kritischen Diensten.
JWKS + kid, kurze TTL-Token, Rotationsplan.
Secrets - nur in KMS/Vault, automatische Rotation von DBs/Providern.
Automatische Erneuerung von Zertifikaten (ACME), Alerts in 30 Tagen.
CI/CD-Validierung von Sicherheitstiteln und anfälligen Chiffren.
Dokumentierte runbooks' und: Rotation, Rückruf, Vorfälle.

Zusammenfassung

Zuverlässiger API-Schutz ist eine Kombination aus TLS 1. 3 + HSTS + PFS als obligatorisches Minimum und ausgereifte Schlüssel- und geheime Managementprozesse. Fügen Sie mTLS zwischen den Diensten hinzu, automatisieren Sie die Freigabe/Rotation über KMS/Vault/Mesh, halten Sie kurze TTLs und „Doppelfenster“, wenn Sie die Schlüssel wechseln - und Sie minimieren die Risiken des Abfangens, Downgrades und Missbrauchs ausgetretener Geheimnisse, ohne die Verfügbarkeit und Geschwindigkeit des Produkts zu beeinträchtigen.