S2S-aoutentifikatsiya

L'authentification S2S prouve exactement quel service/workload fait la demande et lui donne les droits minimaux nécessaires pour un temps limité. Contrairement aux flux d'utilisateurs, il n'y a pas de personne ici - c'est pourquoi la courte durée de vie des informations d'identification, la liaison cryptographique à l'workload/canal et l'observation claire sont critiques.

1) Objectifs et principes

Zero Trust par défaut : ne pas faire confiance au réseau, seulement l'attestation de workload et la cryptographie.
Crédenshles à courte durée de vie : minutes, pas jours/mois.
Référence au contexte : tenant/region/licence/audience/scopes.
Émission centralisée, vérification décentralisée : STS/IdP + vérification locale.
Privilèges minimaux et délégation explicite : seulement les bons plans et l'audit nécessaires.
Rotation « sans douleur » : fenêtres dual-key/dual-cert et automatisation.

2) Modèle de menace (minimum)

Vol de secrets durables (API-keys, long-lived RT).
Remplacement du service dans le VPC/cluster.
Attaques interrégionales avec segmentation cassée.
Replay/échange de trafic vers un proxy.
Supply-chain/remplacement de l'image conteneur.
Erreurs de configuration (règles générales firewall/mesh partagées par JWKS pour tous).

3) Modèles de base S2S

3. 1 mTLS (certificats mutuels)

Qui êtes-vous, prouvez par le canal.
Certificats de courte durée (heure-24 heures) de l'ICP interne ; la sortie/rotation est gérée par un agent mesh/sidecar ou SPIRE.
Bon pour les « voisins » dans le même domaine trust et pour les tokens binding.

3. 2 JWT de service (STS)

Qui êtes-vous, prouvez par un message.
Court Access JWT (2-5 min) avec 'aud', 'scp', 'tenant', 'region'.
Signe KMS/HSM, clés publiques - via JWKS avec 'kid' et rotation.
Vérification locale (sans appel réseau IdP).

3. 3 SPIFFE/SPIRE (SVID)

Identité universelle des workloades : 'spiffe ://trust-domain/ns/< ns >/sa/< sa>'.
Issuance/rotation automatique X.509/JWT-SVID, intégration avec Istio/Linkerd.

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

Les clients machine reçoivent un jeton de STS ; pour les actions « au nom » de l'utilisateur - OBO (token exchange).

Nous combinons : mTLS pour le canal, JWT pour le message, SPIFFE pour les identités durables.

4) Architecture de référence

[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) : produit des JWT/C....courts de service, publié par JWKS.
Gateway (PEP) : le terme de réseau, valide mTLS/JWT, enrichit le contexte, demande le PDP.
Services (PEP) : revérification (defense in depth), cache de solutions PDP.
SPIRE/mesh : Auto-certificats et S....pour mTLS.

5) Format de service JWT (exemple)

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

Signé ES256/EdDSA, 'kid' spécifie la clé active.
En option binding au canal : drapeau, hash cert, S.....

6) Politiques d'émission (STS) et vérification

• Le sujet est prélevé à partir du S..../certificat client/registre client.
• Durée de vie 2-5 min, refresh pas - au lieu de cela, redemander STS.
• Les scoops/audiences proviennent du Policy Store (GitOps) et non de la demande du client.

1. Vérifier mTLS (en option) et la validation de la chaîne.

2. Vérifier la signature JWT par JWKS (par 'kid').

3. Vérifiez 'bou/nbf/iss/aud', tenant/region/licence.

4. Enrichir le contexte et demander au PDP (RBAC/ABAC/ReBAC).

5. Mettre en cache la décision du PDP (TTL 30-120 c), invalidité par événement.

7) Multi-tenants et régions (domaines fiduciaires)

Séparez trust-domain's : 'spiffe ://eu. core`, `spiffe://latam. core`.
JWKS/PKI séparés par région ; - uniquement via des passerelles de confiance.
Inclure « tenant/region/licence » dans la marque et vérifier la conformité avec la ressource.
Logi/audit segmentez par tenants et régions.

8) Mode Mesh/sidecar et sans mesh

Istio/Linkerd : mTLS sortie de la boîte, policy-enforcement au niveau L4/L7, intégration avec SPIRE.
Sans mesh : bibliothèque client + mutual TLS dans l'application ; il est plus difficile de gérer la rotation - automatiser via un agent.

9) Clés, JWKS et rotation

Clés privées uniquement en KMS/HSM ; signature - appel/appareil distant.
Rotation tous les N jours ; dual-key : vieux + nouveau sont acceptés, issuer signe nouveau après avoir chauffé les cajas.
Surveillance : part de la consommation par 'kid', clients « dépendants » sur l'ancienne clé.

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) Liaison au canal (DPoP/mTLS-bound)

mTLS-bound tokens : ajouter le hash du certificat client à la JWT ; à la réception, vérifier.
DPoP : Pour les clients HTTP sans mTLS, signer chaque requête DPoP avec une clé, placer thumbprint DPoP dans AT.

11) Erreurs et politique de retour

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

La réponse contient machine-readable 'error _ code' et 'as _ of' (version clé/stratégie).

12) Observation et audit

• `s2s_auth_p95_ms`, `verify_jwt_p95_ms`, `jwks_skew_ms`,
• `invalid_token_rate`, `aud_mismatch_rate`, `insufficient_scope_rate`,
• consommation par 'kid', fraction mTLS-bound des requêtes.

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

• Émission de tokens, rotation des clés, modifications des stratégies, demandes rejetées.

13) Performance

Vérification JWT - local, mise en cache JWKS (TTL 30-60 s) avec mise à jour en arrière-plan.
Chaînes X.509 - Pinning CA et cache OCSP/CRL.
Retirer la validation coûteuse I/O sur gateway/sidecar.
Utilisez les jetons/certificats préfetch (10-20 s avant l'expiration).

14) Tests

Contrat/interop : Différentes sources/bibliothèques, clock skew ± 300 s.
Negative : jeton défectueux/faux, faux 'aud', mauvaise région/tenant, cert-chain cassé.
Chaos : rotation soudaine 'kid', indisponibilité de JWKS, expedition massive, falaise mTLS.
Chargement : pic d'émission sur STS, sursaut de verify sur gateway.
E2E : mTLS-only, JWT-only, mode combiné, Token Exchange (OBO).

15) Pleybooks (runbooks)

1. Compromis de la clé de signature

Revoke 'kid' immédiat, sortie d'un nouveau token TTL raccourci, vérification, recherche de clients « dépendants », mise en garde pour l'ancien 'kid'.

2. Masse 'INVALID _ TOKEN'

Vérifiez JWKS-cache, l'horloge, les origines des tokens (TTL est trop court), augmentez temporairement la tolérance de skew, réchauffez JWKS.

3. pannes mTLS

La vérification de la chaîne CA, des délais S...., de lʼheure hôte ; emergency-transfer via SPIRE/Istio, inclure les itinéraires fallback seulement à l'intérieur de la région.

4. Croissance 'AUD _ MISMATCH'

Dérive des politiques d'audience : comparer la politique STS aux appels réels, ajouter temporairement le "aud'souhaité, planifier un ajustement de l'architecture d'appel.

5. STS indisponible/ralenti

Augmenter la TTL des jetons déjà émis (grace), inclure prefetch/refresh-avant, scale-out STS.

16) Erreurs typiques

Clés API/secrets à longue durée de vie dans le bou/code.
Général JWKS/PKI « pour toutes les régions et pour tout le temps ».
L'absence de binding (mTLS/DPoP) → le jeton est facile à enlever.
Large 'aud =' et « admin » scopes par défaut.
Rotation sans double-clé période → masse 401.
Vérifie les jetons uniquement sur gateway (pas de défense dans depth).
L'échec muet (non 'error _ code' et 'reason') est difficile à débiter et à former les équipes.

17) Mini modèles de configuration

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) Chèque-liste avant la vente

• JWT de service court (≤5 min), vérification locale, cache JWKS.
• mTLS (ou DPoP) inclus ; la priorité est mTLS-bound tokens.
• SPIFFE/SPIRE ou équivalent pour l'émission automatique/rotation de certificats.
• STS avec des politiques d'audience/scope ; extradition uniquement par identité de confiance.
• Division des domaines fiduciaires et des SCEJ par région ; tenant/région/licence sont vérifiés.
• Les PDP/PEP sont intégrés, cache de solutions + handicap par événement.
• Fenêtres à double clé, surveillance de la consommation de 'kid', alertes sur invalid/aud mismatch.
• Logs complets/audit S2S, métriques de performance/erreurs incluses.
• Pleybooks sur le compromis de clé, chute STS, échec mTLS.
• Jeu de tests contract/negative/chaos/load/E2E réussi.

Conclusion

L'authentification S2S est une combinaison de canal de confiance (mTLS), de message de confiance (JWT court) et d'identité de workload stable (SPIFFE), gérée par un STS centralisé et vérifiée localement. Ajoutez une séparation des domaines de confiance, une audience/scopes rigoureuse, une rotation et une observabilité automatiques - et obtenez un contour fiable, explicatif et évolutif avec la plate-forme et sa géographie.