S2S-authentication

S2S uwierzytelnianie dowodzi, która usługa/przepływ pracy sprawia, że żądanie i daje mu minimalne niezbędne prawa przez ograniczony czas. W przeciwieństwie do strumieni użytkownika, nie ma tu osoby - dlatego krótka żywotność poświadczeń, wiązanie kryptograficzne z treningiem/kanałem i wyraźna obserwowalność są krytyczne.

1) Cele i zasady

Zero Trust domyślnie: nie ufaj sieci, tylko certyfikacja treningu i kryptografii.
Kredyty krótkotrwałe: minuty, nie dni/miesiące.
Powiązanie kontekstowe: najemca/region/licencja/publiczność/zakresy.
Emisja scentralizowana, weryfikacja zdecentralizowana: STS/IdP + weryfikacja lokalna.
Minimalne uprawnienia i wyraźne przekazanie uprawnień: tylko niezbędne zakresy i audyty.
„Bezbolesna” rotacja: podwójny klucz/podwójny cert okna i automatyzacja.

2) Model zagrożenia (minimum)

Kradzież długotrwałych tajemnic (klucze API, długotrwały RT).
Spoofing serwisowy w ramach VPC/klastra.
Ataki międzyregionalne w złamanej segmentacji.
Wymiana ruchu powtórnego/proxy.
Substytucja obrazu łańcucha dostaw/pojemnika.
Błędy konfiguracyjne (szeroki zapora/reguły siatki, wspólny JWKS dla wszystkich).

3) Podstawowe wzory S2S

3. 1 mTLS (certyfikaty wzajemne)

Kim jesteś: dowodzi kanałem.
Certyfikaty krótkotrwałe (godzinny dzień) z wewnętrznego PKI; uwalnianie/obracanie jest zarządzane przez siatkę/siatkę boczną lub środek SPIRE.
Dobre dla „sąsiadów” w tej samej domenie zaufania i dla wiążących żetonów.

3. 2 Usługi JWT (STS)

Kim jesteś: dowodzi z wiadomością.
Krótki dostęp JWT (2-5 min) z 'aud',' scp ',' lokator ',' region '.
Znaki KMS/HSM, klucze publiczne - przez JWKS z 'dzieciakiem' i rotacją.
Sprawdź lokalnie (brak połączenia sieciowego IdP).

3. 3 SPIFFE/SPIRE (SVID)

Uniwersalna tożsamość pracowników: „spiffe ://trust-domain/ns/< ns >/sa/< sa>”.
Automatyczne X.509/JWT-SVID emisji/rotacji, integracja z Istio/Linkerd.

3. 4 OAuth 2. 1 Poświadczenia klienta/Wymiana tokenów (RFC 8693)

Klienci maszyny otrzymują token ze STS; dla działań użytkownika „w imieniu” - OBO (wymiana tokenów).

Połączenie: mTLS dla kanału, JWT dla wiadomości, SPIFFE dla stabilnych tożsamości.

4) Architektura odniesienia

[KMS/HSM]       [Policy Store / PDP]

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

Emitent (STS/IdP): publikuje krótką obsługę JWT/CVID, publikuje JWKS.
Gateway (PEP): termin sieciowy, zatwierdza mTLS/JWT, wzbogaca kontekst, żąda PDP.
Usługi (PEP) - głębokość obrony, pamięć podręczna rozwiązań PDP.
SPIRE/mesh: automatyczne certyfikaty i SVID dla mTLS.

5) Format usługi JWT (przykład)

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" }
}

Podpisany ES256/EdDSA, „dzieciak” wskazuje aktywny klucz.
Opcjonalne powiązanie z kanałem: flaga, hash cert, SVID.

6) Zasady emisji (STS) i weryfikacja

• Obiekt pochodzi z certyfikatu SVID/klienta/rejestru klienta.
• Długość życia 2-5 min, odświeżyć żadnego - poproś o STS ponownie zamiast.
• Scopy/publiczność są pobierane ze sklepu politycznego (GitOps), a nie z żądania klienta.

1. Sprawdź mTLS (opcjonalnie) i ważność łańcucha.

2. Sprawdź podpis JWT przez JWKS (przez 'dziecko').

3. Sprawdź 'exp/nbf/iss/aud', najemca/region/licencja.

4. Wzbogacić kontekst i zapytać PDP (RBAC/ABAC/ReBAC).

5. Roztwór Cache PDP (TTL 30-120 s), niepełnosprawność imprez.

7) Wieloosobowy najemca i regiony (domeny powiernicze)

Oddzielne domeny zaufania: "spiffe ://eu. rdzeń ',' spiffe ://latam. rdzeń ".
oddzielne JWKS/PKI według regionów; interregion - tylko przez zaufane bramy.
Umieścić „najemcę/region/licencję” w znaczkach i sprawdzić zgodność z zasobami.
Dzienniki/audyty segmentów przez najemców i regiony.

8) Tryb siatki/siatki bocznej i bez oczek

Istio/Linkerd: mTLS poza ramką, egzekwowanie zasad na poziomie L4/L7, integracja ze SPIRE.
Bez siatki: biblioteka kliencka + wzajemny TLS w aplikacji; trudniej zarządzać rotacją - zautomatyzować za pośrednictwem agenta.

9) Klucze, JWKS i rotacja

Klucze prywatne tylko w KMS/HSM; podpis - przez zdalne połączenie/zestaw.
Rotacja co N dni; podwójny klucz: akceptowane są stare + nowe, znaki emitenta nowe po ociepleniu buforów.
Monitorowanie: udział konsumpcji przez „dziecko”, powiesił klientów na starego klucza.

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) Wiązanie łącza (związane DPoP/mTLS)

Tokeny związane z mTLS: dodaj hash certyfikatu klienta do JWT; sprawdź w recepcji.
DPoP: dla klientów HTTP bez mTLS - podpisz każde żądanie kluczem DPoP, umieść odcisk kciuka DPoP w AT.

11) Błędy i polityka powrotów

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

Odpowiedź zawiera 'error _ code' i 'as _ of' (wersja klucza/polityki).

12) Obserwowalność i audyt

• 's2s _ auth _ p95 _ ms', 'verify _ jwt _ p95 _ ms', 'jwks _ skew _ ms',
• „invalid _ token _ rate”, „aud _ mismatch _ rate”, „insufficient _ scope _ rate”,
• spożycie przez „dziecko”, odsetek wniosków związanych z mTLS.

• 'subject', 'aud',' lokator ',' region ',' scp ',' kid ',' sid/svid ',' decision ',' policy _ version ',' trace _ id'.

• Emisja tokenów, rotacja kluczy, zmiany polityki, odrzucone wnioski.

13) Wydajność

Weryfikacja JWT - lokalnie, pamięć podręczna JWKS (TTL 30-60 s) z aktualizacją tła.
Łańcuchy X.509 - szpilki CA i pamięć podręczną OCSP/CRL.
Przynieś drogą walidację I/O do bramy/bocznego ekranu.
Użyj tokenów/certyfikatów prefetch (10-20 sekund przed wygaśnięciem).

14) Badanie

Kontrakt/interop: różne NP/biblioteki, zegar skew ± 300 s.
Negatywny: wygasły/fałszywy token, nieprawidłowy 'aud', niewłaściwy region/najemca, zepsuty łańcuch cert.
Chaos: nagły obrót' dziecko ", niedostępność JWKS, wygaśnięcie masowo, złamanie mTLS.
Obciążenie: szczyt na STS, zweryfikować kolce na bramie.
E2E: tylko mTLS, tylko JWT, tryb kombinowany, wymiana tokenów (OBO).

15) Playbooks (książki startowe)

1. Kompromis klucza podpisu

Natychmiastowe cofnięcie „dziecko”, wydanie nowych, skróconych żetonów TTL, audyt, poszukiwanie „powieszonych” klientów, wymuszone zaprzeczenie dla starego „dzieciaka”.

2. MASOWE „NIEPRAWIDŁOWE _ TOKEN”

Sprawdź pamięć podręczną JWKS, zegar, token pochodzenia (TTL zbyt krótki), tymczasowo rozszerzyć tolerancję skew, rozgrzać JWKS.

3. Odmowa mTLS

Sprawdź łańcuch CA, daty SVID, czas hosta; reissue awaryjny przez SPIRE/Istio, umożliwienie tras awaryjnych tylko w regionie.

4. „AUD _ NIEDOPASOWANIE”

Drift polityki publiczności: porównać politykę STS z rzeczywistymi połączeniami, tymczasowo dodać pożądane 'aud', harmonogram zmian architektury połączeń.

5. STS niedostępny/wolny

Zwiększ TTL już wydanych żetonów (grace), włącz prefetch/refresh-earlier, scale-out STS.

16) Typowe błędy

Długotrwałe klucze/sekrety API w kodzie.
Generał JWKS/PKI „dla wszystkich regionów i dla wszystkich czasów”.
Brak wiązania (mTLS/DPoP) → token jest łatwy do odebrania.
Szerokie 'aud =' i domyślnie 'admin'.
Obrót bez okresu podwójnego klucza → masa 401.
Sprawdzanie żetonów tylko na bramce (brak defensywy w głębi).
Awaria „dumb” (brak 'error _ code' i 'reason') - trudno jest debugować i trenować zespoły.

17) Mini szablony konfiguracji

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) Lista kontrolna przedsprzedaży

• Short service JWT (≤ 5 min), weryfikacja lokalna, pamięć podręczna JWKS.
• mTLS (lub DPoP) włączone; priorytet - żetony związane z mTLS.
• SPIFFE/SPIRE lub równoważne dla automatycznej emisji/rotacji certyfikatów.
• STS z polityką publiczności/zakresu; wydanie wyłącznie przez zaufaną tożsamość.
• Rozdzielenie domen zaufania i JWKS według regionów; najemca/region/znaczki licencyjne są sprawdzane.
• Zintegrowane PDP/PEP, pamięć podręczna rozwiązania + niepełnosprawność według zdarzeń.
• Okna podwójne klucze, monitorowanie zużycia „dzieciak”, wpisy do nieprawidłowego/aud niedopasowania.
• Pełne dzienniki/ S2S audytu, włączone wskaźniki wydajności/błędów.
• Kluczowe odtwarzacze kompromisowe, spadek STS, awaria mTLS.
• contract/negative/chaos/load/E2E przeszedł zestaw testowy.

Wnioski

Uwierzytelnianie S2S jest połączeniem kanału-trust (mTLS), message-trust (short JWT) i trwałej tożsamości pracownika (SPIFFE), zarządzanej przez scentralizowany STS i zweryfikowanej lokalnie. Dodaj separację domeny zaufania, rygorystyczną publiczność/zakresy, automatyczną rotację i obserwowalność - i masz zarys, który jest niezawodny, wyjaśnialny i skalowalny wraz z platformą i jej geografią.