S2S-Authentifizierung

Die S2S-Authentifizierung belegt, welcher Dienst/Workload die Anfrage stellt und gibt ihm für eine begrenzte Zeit die minimal erforderlichen Rechte. Im Gegensatz zu User-Streams gibt es hier keine Person - daher sind die kurze Lebensdauer der Anmeldeinformationen, die kryptographische Bindung an die Vorkloade/den Kanal und die klare Beobachtbarkeit kritisch.

1) Ziele und Grundsätze

Zero Trust Standard: Vertrauen Sie dem Netzwerk nicht, nur Vorkload-Bescheinigungen und Kryptographie.
Kurzlebige Credits: Minuten, nicht Tage/Monate.
Kontextreferenz: tenant/region/licence/audience/scopes.
Zentrale Ausgabe, dezentrale Verifikation: STS/IdP + lokale Verifikation.
Mindestprivilegien und explizite Delegierung: Nur die erforderlichen Scopes und Audits.
Rotation „schmerzfrei“: Dual-Key/Dual-Cert Fenster und Automatisierung.

2) Bedrohungsmodell (Minimum)

Diebstahl langlebiger Geheimnisse (API-Keys, Long-Lived RT).
Service-Ersetzung innerhalb eines VPC/Clusters.
Interregionale Angriffe mit gebrochener Segmentierung.
Replay/Datenverkehr durch Proxy ersetzen.
Supply-chain/Ersetzen des Container-Images.
Konfigurationsfehler (breite Firewall/Mesh-Regeln, allgemeines JWKS für alle).

3) Grundmuster S2S

3. 1 mTLS (gegenseitige Zertifikate)

Wer Sie sind: beweist Kanal.
kurzlebige Zertifikate (Stunde-Tag) aus der internen PKI; Release/Rotation wird von Mesh/Sidecar oder SPIRE Agent gesteuert.
Gut für „Nachbarn“ in einer Trust-Domain und für Binding-Token.

3. 2 Service JWT (STS)

Wer Sie sind: beweist die Botschaft.
Kurzer Zugang JWT (2-5 min) mit 'aud',' scp', 'tenant', 'region'.
Signiert KMS/HSM, öffentliche Schlüssel - über JWKS mit 'kid' und Rotation.
Lokal prüfen (kein IdP-Netzwerkanruf).

3. 3 SPIFFE/SPIRE (SVID)

Die universelle Identität der Vorkloaden lautet: 'spiffe ://trust-domain/ns/< ns >/sa/< sa>'.
Automatische Issuance/Rotation X.509/JWT-SVID, Integration mit Istio/Linkerd.

3. 4 OAuth 2. 1 Client Credentials / Token Exchange (RFC 8693)

Maschinenkunden erhalten ein Token von STS; für Aktionen „im Namen“ des Benutzers - OBO (Token Exchange).

Wir kombinieren: mTLS für den Kanal, JWT für die Botschaft, SPIFFE für nachhaltige Identitäten.

4) Referenzarchitektur

[KMS/HSM]       [Policy Store / PDP]

[STS/IdP (issuer)] ── JWKS ──[Gateway/PEP] ─────[Services/PEP]
│
SVID/JWT │         │    │      │
(SPIRE/Istio)│      mTLS/DPoP  │    mTLS/DPoP
│         │    │      │
[Workload/Sidecar]─────────┴───────┴────────────┘

Issuer (STS/IdP): produziert kurze Service-JWT/CVID, veröffentlicht JWKS.
Gateway (PEP): Begriff Netzwerke, validiert mTLS/JWT, bereichert mit Kontext, fordert PDP an.
Services (PEP): erneute Überprüfung (defense in depth), PDP-Entscheidungscache.
SPIRE/mesh: Auto-Zertifikate und SVID für mTLS.

5) JWT-Service-Format (Beispiel)

json
{
"iss": "https://sts. core",
"sub": "svc. catalog, "//service identity
"aud": ["svc. search"] ,//target service/domain
"exp": 1730390100, "iat": 1730389800,
"tenant": "brand_eu",
"region": "EE",
"scp": ["catalog:read:public","catalog:read:tenant"],
"mtls": { "bound": true, "spiffe": "spiffe://core/ns/prod/sa/catalog" }
}

Signiert ES256/EdDSA, 'kid' gibt den aktiven Schlüssel an.
Optional Bindung an den Kanal: Flagge, Hash cert, SVID.

6) Auslieferungsrichtlinien (STS) und Verifizierung

• Subject wird aus dem SVID/Client-Zertifikat/Client-Register entnommen.
• Lebensdauer 2-5 Minuten, kein Refresh - stattdessen neu nach STS fragen.
• Scopes/Audiences stammen aus dem Policy Store (GitOps) und nicht aus einer Kundenanfrage.

1. Überprüfen Sie mTLS (optional) und die Gültigkeit der Kette.

2. Überprüfen Sie die JWT-Signatur von JWKS (von 'kid').

3. Vergleichen Sie' exp/nbf/iss/aud', tenant/region/licence.

4. Bereichern Sie den Kontext und fragen Sie nach PDP (RBAC/ABAC/ReBAC).

5. Caching PDP-Lösung (TTL 30-120 c), Behinderung durch Ereignisse.

7) Multi-Tenant und Regionen (trust domains)

Teilen Sie trust-domain's: 'spiffe ://eu. core`, `spiffe://latam. core`.
Getrennte JWKS/PKI nach Regionen; interregione - nur über vertrauenswürdige Gateways.
Fügen Sie' tenant/region/licence' in die Stempel ein und überprüfen Sie die Übereinstimmung mit der Ressource.
Logs/Audits nach Tenanten und Regionen segmentieren.

8) Mesh/Sidecar und No-Mesh-Modus

Istio/Linkerd: mTLS „out of the box“, Policy-Enforcement auf L4/L7-Ebene, Integration mit SPIRE.
Ohne Mesh: Bibliothek-Client + mutual TLS in der Anwendung; schwieriger, die Rotation zu verwalten - automatisieren durch einen Agenten.

9) Schlüssel, JWKS und Rotation

Private Schlüssel nur in KMS/HSM; Signatur - Remote-Anruf/Gerät.
Rotation alle N Tage; Dual-Key: alt + neu werden akzeptiert, issuer signiert neu nach dem Aufwärmen der Caches.
Überwachung: Anteil des Verbrauchs durch "Kid'," schwebende "Kunden auf dem alten Schlüssel.

yaml issuer:
jwks:
alg: ES256 rotation_days: 30 publish_cache_ttl: 60s sts:
access_ttl: 5m audience_policies:
- subject: "svc. catalog"
allow: ["svc. search","svc. wallet"]
scopes: ["catalog:read:"]
tenancy:
claims: ["tenant","region","licence"]
jwks_per_region: true

10) Link to Channel (DPoP/mTLS-gebunden)

mTLS-gebundene Token: Fügen Sie dem JWT ein Hash-Client-Zertifikat hinzu; an der Rezeption zu überprüfen.
DPoP: für HTTP-Clients ohne mTLS - jede Anfrage mit einem DPoP-Schlüssel signieren, in AT den DPoP-Thumbprint platzieren.

11) Fehler und Rückgaberichtlinien

• `401 INVALID_TOKEN`/`EXPIRED_TOKEN`/`AUD_MISMATCH`.
• `401 MTLS_REQUIRED`/`MTLS_CERT_INVALID`.
• `403 INSUFFICIENT_SCOPE`/`POLICY_DENY`.
• `429 RATE_LIMITED`.

Die Antwort enthält machine-readable' error _ code' und 'as _ of' (key/policy version).

12) Beobachtbarkeit und Audit

• `s2s_auth_p95_ms`, `verify_jwt_p95_ms`, `jwks_skew_ms`,
• `invalid_token_rate`, `aud_mismatch_rate`, `insufficient_scope_rate`,
• Verbrauch durch 'kid', Anteil der mTLS-gebundenen Anfragen.

• `subject`, `aud`, `tenant`, `region`, `scp`, `kid`, `sid/svid`, `decision`, `policy_version`, `trace_id`.

• Ausgabe von Token, Schlüsselrotationen, Richtlinienänderungen, abgelehnte Anfragen.

13) Produktivität

JWT-Verifikation - lokal, JWKS-Cache (TTL 30-60 s) mit Hintergrundaktualisierung.
X.509-Ketten - CA-Pinning und OCSP/CRL-Cache.
Bringen Sie ein teures validierendes I/O auf Gateway/Sidecar.
Verwenden Sie prefetch Token/Zertifikate (10-20 Sekunden vor Ablauf).

14) Testen

Vertrag/interop: verschiedene APs/Bibliotheken, clock skew ± 300 s.
Negativ: abgelaufener/gefälschter Token, falscher 'aud', falsche Region/Tenant, gebrochener Cert-Chain.
Chaos: plötzliche Rotation von 'kid', JWKS-Unzugänglichkeit, Massenauslauf, mTLS-Klippe.
Laden: Spitze der Ausgabe auf STS, Spitze verify auf Gateway.
E2E: mTLS-only, JWT-only, kombinierter Modus, Token Exchange (OBO).

15) Playbooks (Runbooks)

1. Kompromittierung des Signaturschlüssels

Sofortige Revoke' Kid', Freigabe neuer, verkürzter TTL-Token, Audit, Suche nach „schwebenden“ Kunden, erzwungene Deny für den alten 'Kid'.

2. Masse' INVALID _ TOKEN '

Überprüfen Sie den JWKS-Cache, die Synchronisation der Uhr, die Herkunft der Token (TTL ist zu kurz), erweitern Sie vorübergehend die Skew-Toleranz, wärmen Sie JWKS auf.

3. mTLS-Absagen

Überprüfung der CA-Kette, SVID-Timing, Host-Zeit; Notfall-Neuausstellung über SPIRE/Istio, Fallback-Routen nur innerhalb der Region aktivieren.

4. Wachstum von 'AUD _ MISMATCH'

Drift audience policy: Vergleichen Sie die STS-Richtlinie mit den tatsächlichen Anrufen, fügen Sie vorübergehend das gewünschte' aud' hinzu, planen Sie die Anpassung der Anrufarchitektur.

5. STS nicht verfügbar/verlangsamt

Erhöhen Sie die TTL von bereits ausgegebenen Token (grace), aktivieren Sie prefetch/refresh-früher, scale-out STS.

16) Typische Fehler

Langlebige API-Schlüssel/Geheimnisse in env/Code.
Eine gemeinsame JWKS/PKI „für alle Regionen und für alle Zeiten“.
Das Fehlen von Bindung (mTLS/DPoP) → den Token leicht wegnehmen.
Die breiten 'aud =' und 'admin' scopes sind standardmäßig.
Rotation ohne Dual-Key-Periode → Masse 401.
Überprüfung der Token nur am Gateway (keine Verteidigung in der Tiefe).
„Stumme“ Ablehnung (kein 'error _ code' und 'reason') - es ist schwierig, Befehle zu debatten und zu trainieren.

17) Mini-Konfigurationsvorlagen

yaml auth:
require_mtls: true jwks:
url: https://sts. core/.well-known/jwks. json cache_ttl: 60s claims:
required: ["iss","sub","aud","exp","tenant","region"]
tenant_in_header: "x-tenant"
pdp:
endpoint: "opa:8181/v1/data/policy/allow"
decision_cache_ttl: 60s

yaml subjects:
- id: "svc. catalog"
spiffe: "spiffe://core/ns/prod/sa/catalog"
audiences: ["svc. search","svc. wallet"]
scopes: ["catalog:read:"]
ttl: "5m"

18) Checkliste vor dem Verkauf

• Kurze Service-JWTs (≤5 min), lokale Verifizierung, JWKS-Cache.
• mTLS (oder DPoP) ist eingeschaltet; Priorität - mTLS-gebundene Token.
• SPIFFE/SPIRE oder gleichwertig für die automatische Ausstellung/Rotation von Zertifikaten.
• STS mit Audience/Scope-Richtlinien; Auslieferung nur nach vertrauenswürdiger Identität.
• Aufteilung von Treuhanddomänen und JWKS nach Regionen; Die Etiketten tenant/region/licence werden geprüft.
• PDP/PEP integriert, Entscheidungscache + Behinderung durch Veranstaltungen.
• Dual-Key-Fenster, Überwachung des Verbrauchs von 'kid', Warnungen auf invalid/aud mismatch.
• Vollständige Protokolle/Audit- S2S, Leistungs-/Fehlermetriken enthalten.
• Playbooks für Schlüsselkompromittierung, STS-Drop, mTLS-Fehler.
• Die contract/negative/chaos/load/E2E Tests sind abgeschlossen.

Schlussfolgerung

Die S2S-Authentifizierung ist eine Kombination aus Channel-Trust (mTLS), Message-Trust (kurz JWT) und Sustainable Workload Identity (SPIFFE), die von einem zentralisierten STS verwaltet und lokal validiert wird. Fügen Sie die Aufteilung von Trust-Domains, strenge Audience/Scopes, automatische Rotation und Beobachtbarkeit hinzu - und erhalten Sie eine Kontur, die zuverlässig, erklärbar und skalierbar ist, zusammen mit der Plattform und ihrer Geographie.