S2S-authentication

autentificarea S2S dovedește ce serviciu/flux de lucru face cererea și îi oferă drepturile minime necesare pentru o perioadă limitată de timp. Spre deosebire de fluxurile de utilizatori, nu există nicio persoană aici - prin urmare, durata scurtă de viață a acreditărilor, legarea criptografică la antrenament/canal și observabilitatea clară sunt critice.

1) Obiective și principii

Zero Trust în mod implicit: nu aveți încredere în rețea, doar certificarea antrenamentului și a criptografiei.
Credite de scurtă durată: minute, nu zile/luni.
Context obligatoriu: chiriaș/regiune/licență/audiență/scopuri.
Emisiune centralizată, verificare descentralizată: STS/IdP + verificare locală.
Privilegii minime și delegare explicită: numai domeniile de aplicare și auditurile necesare.
Rotație „fără durere”: ferestre cu două taste/dual-cert și automatizare.

2) Model de amenințare (minim)

Furt de secrete de lungă durată (API-chei, RT de lungă durată).
Servicii de spoofing în cadrul VPC/cluster.
Atacuri interregionale în segmentare ruptă.
Înlocuirea reluării/proxy a traficului.
Înlocuirea imaginii lanțului de aprovizionare/containerului.
Erori de configurare (reguli largi de firewall/mesh, JWKS comune pentru toți).

3) Modele de bază S2S

3. 1 mTLS (certificate reciproce)

Cine ești: dovedește de canal.
Certificate de scurtă durată (oră-zi) de la PKI intern; eliberarea/rotația este gestionată de plasă/ataș sau agent SPIRE.
Bun pentru „vecini” în același domeniu de încredere și pentru token-uri obligatorii.

3. 2 JWT-uri de serviciu (STS)

Cine ești: dovedește cu un mesaj.
Acces scurt JWT (2-5 min) cu „aud”, „scp”, „chiriaș”, „regiune”.
Semne KMS/HSM, chei publice - prin JWKS cu „copil” și de rotație.
Verificați local (fără apel de rețea IdP).

3. 3 SPIFFE/SPIRE (SVID)

Identitatea universală a lucrătorilor: 'spiffe ://trust-domain/ns/< ns >/sa/< sa>'.
X.509/JWT-SVID automată de emitere/rotație, integrare cu Istio/Linkerd.

3. 4 OAuth 2. 1 Client acreditări/Token Exchange (RFC 8693)

Clienții mașinilor primesc un jeton de la STS; pentru acțiunile „în numele” utilizatorului - OBO (token exchange).

Combinați: mTLS pentru canal, JWT pentru mesaj, SPIFFE pentru identități stabile.

4) Arhitectura de referință

[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): lansează serviciul scurt JWT/CVID, publică JWKS.
Gateway (PEP): termen de rețea, validează mTLS/JWT, îmbogățește contextul, solicită PDP.
Servicii (PEP) - apărare în profunzime, soluții PDP cache.
SPIRE/plasă: certificate auto și SVID pentru mTLS.

5) JWT format de serviciu (exemplu)

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

Semnat ES256/EdDSA, „copil” indică cheia activă.
Legare opțională la canal: pavilion, cert hash, SVID.

6) Politici de emitere (STS) și verificare

• Subiectul este preluat din registrul SVID/client/client.
• Durata de viață 2-5 min, reîmprospătați niciunul - cereți STS din nou.
• Scopurile/audiențele sunt preluate din Policy Store (GitOps), nu de la o cerere a clientului.

1. Verificați mTLS (opțional) și valabilitatea lanțului.

2. Verificați semnătura JWT de către JWKS (prin „copil”).

3. Check 'exp/nbf/iss/aud', chiriaș/regiune/licență.

4. Îmbogățiți contextul și întrebați PDP (RBAC/ABAC/ReBAC).

5. Soluție PDP cache (TTL 30-120 s), handicap eveniment.

7) Multi-chiriaș și regiuni (domenii de încredere)

Domenii de încredere separate: "spiffe ://eu. core ', "spiffe ://latam. core ".
Separat JWKS/PKI pe regiuni; interregiune - numai prin gateway-uri de încredere.
Includeți „chiriaș/regiune/licență” în ștampile și verificați conformitatea resurselor.
Jurnale de segment/audituri de către chiriași și regiuni.

8) Mesh/sidecar și modul fără plasă

Istio/Linkerd: mTLS ieșit din cutie, aplicarea politicilor la nivelul L4/L7, integrarea cu SPIRE.
Fără plasă: bibliotecă client + TLS reciproc în aplicație; mai dificil de gestionat rotația - automatizați prin intermediul agentului.

9) Chei, JWKS și rotație

Chei private numai în KMS/HSM; semnătură - prin apel la distanță/set.
Rotație la fiecare N zile; dual-cheie: vechi + noi sunt acceptate, emitentul semnează noi după încălzirea cache-urilor.
Monitorizare: ponderea consumului de către „copil”, agățat clienții pe cheia veche.

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) Legarea legăturii (DPoP/mTLS)

Jetoane mTLS: adăugați certificat client hash la JWT; Verificaţi la recepţie.
DPoP: pentru clienții HTTP fără mTLS - semnați fiecare cerere cu o cheie DPoP, plasați o amprentă DPoP în AT.

11) Erori și politica de returnare

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

Răspunsul conține „error _ code” și „as _ of” (versiune cheie/politică) care poate fi citită automat.

12) Observabilitate și audit

• 's2s _ auth _ p95 _ ms',' verify _ jwt _ p95 _ ms', 'jwks _ skew _ ms',
• 'invalid _ token _ rate', 'aud _ mumatch _ rate', 'insuficient _ scope _ rate',
• consumul de „copil”, proporția cererilor legate de mTLS.

• 'suspect', 'aud', 'chiriaş', 'regiune', 'scp', 'kid', 'sid/svid', 'decizie', 'policy _ version', 'trace _ id'.

• Emitere token, rotație cheie, modificări de politică, cereri respinse.

13) Performanță

Verificare JWT - local, cache JWKS (TTL 30-60 s) cu actualizare de fundal.
X.509 lanțuri - CA pinning și OCSP/CRL cache.
Aduceți validarea scumpă I/O la poarta/lateral.
Utilizați jetoane/certificate prefetch (10-20 secunde înainte de expirare).

14) Testarea

Contract/interop: diferite NP/biblioteci, înclinare ceas ± 300 s.
Negativ: token expirat/fals, „aud” incorect, regiune greșită/chiriaș, lanț de cert rupt.
Haos: rotație bruscă „copil”, indisponibilitatea JWKS, expirarea en masse, mTLS rupere.
Încărcați: problema de vârf pe STS, verificați spike pe gateway.
E2E: mTLS-numai, JWT-numai, modul combinat, Token Exchange (OBO).

15) Cărți de joc (runbooks)

1. Compromisul cheii de semnătură

Revocați imediat 'kid', eliberați jetoane TTL noi, scurtate, auditați, căutați clienți „spânzurați”, refuzați forțat vechiul 'kid'.

2. Mass' INVALID _ TOKEN "

Verificați memoria cache JWKS, alinierea greșită a ceasului, originile tokenului (TTL prea scurt), extindeți temporar toleranța la înclinare, încălziți JWKS.

3. mTLS-refuzuri

Verificați lanțul CA, datele SVID, ora gazdei; emiterea de urgență prin SPIRE/Istio, permite rute de rezervă numai în regiune.

4. 'AUD _ MISMATCH' growth

Politica de audiență derivă: comparați politica STS cu apelurile reale, adăugați temporar 'aud' dorit, ajustați arhitectura apelurilor de program.

5. STS indisponibil/lent

Măriți TTL-ul tokenurilor deja emise (grație), activați prefetch/refresh-mai devreme, scalați STS.

16) Erori tipice

Chei API de lungă durată/secrete în env/code.
General JWKS/PKI „pentru toate regiunile și pentru toate timpurile”.
Lipsa legării (mTLS/DPoP) → tokenul este ușor de îndepărtat.
Broad 'aud =' și 'admin' scopes în mod implicit.
Rotație fără dublă cheie perioadă → masa 401.
Verificarea jetoanelor numai pe gateway (fără apărare în profunzime).
Eșecul „dumb” (fără „error _ code” și „reason”) - este dificil să depanezi și să antrenezi echipele.

17) Mini șabloane de configurare

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 de verificare pre-vânzare

• Serviciu scurt JWT (≤5 min), verificare locală, memorie cache JWKS.
• mTLS (sau DPoP) activat; prioritate - jetoane legate de mTLS.
• SPIFFE/SPIRE sau echivalent pentru auto-emiterea/rotirea certificatelor.
• STS cu politici de audiență/domeniu de aplicare; emiterea numai prin identitate de încredere.
• Separarea domeniilor de încredere și JWKS pe regiuni; se verifică timbrele chiriaș/regiune/licență.
• PDP/PEP integrat, soluție cache + dizabilitate de eveniment.
• Ferestre cu două taste, consumul de monitorizare 'kid', alerte la neconcordanță invalidă/aud.
• Jurnalele complete/ S2S de audit, măsurătorile de performanță/eroare activate.
• Registre de compromisuri cheie, cădere STS, eșec mTLS.
• contract/negative/chaos/load/E2E test suite trecut.

Concluzie

autentificarea S2S este o combinație de channel-trust (mTLS), mesaj-trust (JWT scurt) și identitate persistentă a lucrătorului (SPIFFE), gestionată de un STS centralizat și verificată local. Adăugați separarea domeniului de încredere, audiență/scopuri riguroase, rotație automată și observabilitate - și aveți un contur care este fiabil, explicabil și scalabil împreună cu platforma și geografia acesteia.