Autenticazione S2S

L'autenticazione S2S dimostra che tipo di servizio/worcload effettua la richiesta e gli dà i diritti minimi necessari per un tempo limitato. A differenza dei flussi definiti dall'utente, non ci sono persone - quindi sono critici i tempi di vita brevi delle credenziali, il collegamento crittografico al worcload/canale e la netta osservabilità.

1) Obiettivi e principi

Zero Trust predefinito - Non fidarsi della rete, solo la certificazione di worcload e crittografia.
I prestanome di breve durata sono minuti, non giorni/mesi.
Il riferimento al contesto è tenant/region/licence/audience/scopes.
Rilascio centralizzato, controllo decentralizzato: STS/IdP + verifica locale.
Privilegi minimi e deleghe esplicite: solo le scorciatoie e le verifiche necessarie.
Rotazione senza dolore: dual-key/dual-cert finestre e automazione.

2) Modello di minaccia (minimo)

Furto di segreti duraturi (API-keys, long-lived rt).
Sostituzione del servizio all'interno di VPC/cluster.
Attacchi interregionali con segmentazione rotta.
Replay/sostituzione del traffico con proxy.
Supply-chain/sostituzione immagine contenitore.
Errori di configurazione (ampia regola firewall/mesh, comune JWKS per tutti).

3) Pattern S2S di base

3. 1 mTLS (certificati reciproci)

Chi sei, prova il canale.
Certificati di breve durata (ore/ore) da PKI interno; il rilascio/rotazione è gestito da mesh/sidecar o SPIRE.
Buono per «vicini» in un unico dominio trust e per i token binding.

3. 2 Servizi JWT (STS)

Chi sei, prova con un messaggio.
Access JWT breve (2-5 min) con «aud», «scp», «tenant», «region».
Firma KMS/HSM, chiavi pubbliche tramite JWKS con «kid» e rotazione.
Verifica localmente (senza chiamata di rete).

3. 3 SPIFFE/SPIRE (SVID)

Identità universale dei worcload: 'spiffe ://trust-domain/ns/< ns >/sa/< sa>'.
Isuance/rotation automatica X.509/JWT-SVID, integrazione con Istio/Linkerd.

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

I clienti delle macchine ricevono il token da STS; per azioni "per conto dell'utente - OBO (token exchange).

Combiniamo: mTLS per il canale, JWT per il messaggio, SPIFFE per le identità sostenibili.

4) Architettura arbitrale

[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): rilascia JWT/CVID di servizio breve, pubblica JWKS.
Gateway (PEP) - Il termine rete, valuta il mTLS/JWT, arricchisce il contesto, chiede il PDP.
Servizi (PEP) - Riprova (defense in depth), cache delle soluzioni PDP.
SPIRE/mesh: certificati auto e SVID per il mTLS.

5) Formato JWT di servizio (esempio)

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

ES256/EdDSA firmato, kid indica la chiave attiva.
Binding opzionale al canale: flag, hash cert, SVID.

6) Criteri di emissione (STS) e convalida

• Il subject viene prelevato da SVID/certificato client/registro client.
• Durata di vita 2-5 min, no refresh - invece di chiedere di nuovo STS.
• Gli scoop/pubblico vengono dal Policy Store, non dalla richiesta del cliente.

1. Controlla la mTLS (opzionale) e la validità della catena.

2. Controlla la firma JWT per JWKS («kid»).

3. Incrocia «exp/nbf/iss/aud», tenant/region/licence.

4. Arricchisci il contesto e chiedi a PDP (RBAC/ABAC/ReBAC).

5. Cache PDP (TTL 30-120 c), disabilità eventi.

7) Multi-tenente e regioni (trust domains)

Separa trust-domain's: 'spiffe ://eu. core`, `spiffe://latam. core`.
JWKS/PKI separati per regione; L'interregione è solo attraverso le passerelle di fiducia.
Inserisci nelle etichette «tenant/region/licence» e controlla la corrispondenza della risorsa.
Segmenti/verifiche per tenanti e regioni.

8) Modalità mesh/sidecar e senza-mesh

Istio/Linkerd: mTLS da scatola, policy-enforcement a livello L4/L7, integrazione con SPIRE.
Senza mesh: libreria client + mutual TLS nell'applicazione; È più difficile gestire la rotazione.

9) Chiavi, JWKS e rotazione

Chiavi private solo in KMS/HSM; la firma è una chiamata/macchina remota.
Rotation ogni N giorni; dual-key: vecchio + nuovo accettato, issuer firma nuovo dopo aver riscaldato i caselli.
Monitoraggio: la quota di consumo per «kid», i clienti dipendenti sulla vecchia chiave.

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) Collegamento al canale (DPoP/mTLS-bound)

mTLS-bound tokens - Aggiungi un certificato client a JWT al ricevimento per controllare.
: Per i clienti HTTP senza , firmare ogni richiesta con una chiave DPoP, inserire un thumbprint in AT.

11) Errori e criteri di restituzione

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

La risposta contiene machine-readable «error _ code» e «as _ of» (versione chiave/criterio).

12) Osservazione e verifica

• `s2s_auth_p95_ms`, `verify_jwt_p95_ms`, `jwks_skew_ms`,
• `invalid_token_rate`, `aud_mismatch_rate`, `insufficient_scope_rate`,
• consumo «kid», percentuale di richieste mTLS-bound.

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

• Fornitura di token, rotazione delle chiavi, modifiche ai criteri, richieste rifiutate.

13) Prestazioni

Verifica JWT - Locale, JWKS cache (TTL 30-60 c) con aggiornamento di sfondo.
Catene X.509 - Pinning CA e cache OCSP/CRL.
Portare il costoso I/O di validazione su gateway/sidecar.
Utilizzare prefetch token/certificati (10-20 s prima della scadenza).

14) Test

Contract/interop: diversi IP/librerie, clock skew © 300 s

Negative: token scaduto/falso, «aud» sbagliato, regione/tenente sbagliato, cert-chain rotto.
Chaos: rotazione improvvisa «kid», indisponibilità JWKS, espansione massiccia, diradamento.
Load: picco di rilascio per STS, picco di verify per gateway.
E2E: mTLS-only, JWT-only, modalità combinata, Token Exchange (OBO).

15) Playbooks (runbooks)

1. Compromettere la chiave di firma

Revoke «kid» immediato, rilascio di un nuovo TTL di TTL, controllo, ricerca di client «dipendenti», deny obbligatorio per il vecchio «kid».

2. Massiccia'INVALID _ TOKEN '

Controlla JWKS-cash, rassincrone dell'orologio, origini dei token (TTL troppo breve), estende temporaneamente la tolleranza skew, scalda JWKS.

3. guasti mTLS

Verifica della catena CA, della data SVID, dell'ora host Trasferimento di emergency attraverso SPIRE/Istio, attivare percorsi fallback solo all'interno della regione.

4. Crescita dì AUD _ MISMATCH'

Deriva criteri udienza: confronta STS-policy con le chiamate effettive, aggiungi temporaneamente «aud», pianifica la regolazione dell'architettura di chiamata.

5. STS non disponibile/rallentato

Aumenta TTL dei token già emessi (grace), abilita prefetch/refresh-prima, scale-out STS.

16) Errori tipici

Chiavi API/segreti a lunga vita nel codice UV.
Comune JWKS/PKI «per tutte le regioni e per tutto il tempo».
L'assenza di binding ( ) è facile da allontanare.
Ampi «aud =» e «admini» scopes predefiniti.
Rotazione senza dual-key periodo di massa 401.
Controlla i token solo su gateway (nessun defense in depth).
«Muto» rifiuto (no «error _ code» e «reason») è difficile da ritardare e addestrare i comandi.

17) Mini modelli di configurazione

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) Foglio di assegno prima della vendita

• JWT brevi (≤5 min), convalida locale, cache JWKS.
• mTLS (o DPoP) abilitato Priorità: mTLS-bound tokens.
• SPIFFE/SPIRE o equivalente per il rilascio automatico/rotazione di certificati.
• STS con regole audio/scope; L'estradizione è solo per identità di fiducia.
• Separazione tra trust-domains e JWKS per regione; le etichette tenant/region/licence vengono controllate.
• PDP/PEP integrati, cache delle soluzioni + invalidità per eventi.
• finestre dual-key, monitoraggio del consumo «kid», alert su invalid/aud mismatch.
• Logi completi/controllo S2S, incluse metriche di prestazioni/errori.
• Playbook di compromissione chiave, caduta STS, errore di mTLS.
• Set di test contract/negative/chaos/load/E2E completato.

Conclusione

L'autenticazione S2S è una combinazione di canale-fiducia (mTLS), messaggio-fiducia (JWT corto) e identità di vorcload sostenibile (SPIFFE) gestita da STS centralizzato e verificabile localmente. Aggiungi la divisione dei domini trust, le severe udienze/scopes, la rotazione automatica e l'osservabilità e ottieni un tracciato che sia affidabile, spiegato e scalabile con la piattaforma e la sua geografia.