S2S-autentifikatsiya

La autenticación S2S prueba exactamente qué servicio/worcload realiza la solicitud y le otorga los derechos mínimos necesarios por un tiempo limitado. A diferencia de los flujos personalizados, no hay ninguna persona aquí - por lo tanto, el corto período de vida de las credenciales, el enlace criptográfico al worcload/canal y la observabilidad clara son críticos.

1) Objetivos y principios

Zero Trust por defecto: no confiar en la red, sólo en la certificación de worcload y criptografía.
Créditos de vida corta: minutos, no días/meses.
Referencia al contexto: tenant/region/licence/audience/scopes.
Emisión centralizada, verificación descentralizada: verificación local STS/IdP +.
Privilegios mínimos y delegación explícita: sólo los scoups y auditorías necesarios.
Rotación «sin dolor»: ventanas dual-key/dual-cert y automatización.

2) Modelo de amenazas (mínimo)

Robo de secretos duraderos (API-keys, long-lived RT).
Reemplaza el servicio dentro del VPC/clúster.
Ataques interregionales en segmentación rota.
Replay/reemplaza el tráfico en el proxy.
Supply-chain/sustitución de la imagen del contenedor.
Errores de configuración (reglas amplias de firewall/mesh, JWKS común para todos).

3) Patrones básicos S2S

3. 1 mTLS (certificados mutuos)

¿Quién eres? Prueba por el canal.
Certificados de vida corta (hora-día) de PKI interno; la liberación/rotación es controlada por un mesh/sidecar o agente SPIRE.
Bueno para los «vecinos» en el mismo dominio de confianza y para los tokens de binding.

3. 2 JWT de servicio (STS)

Quién eres: prueba con un mensaje.
Acceso corto JWT (2-5 min) con 'aud', 'scp', 'tenant', 'region'.
Firma KMS/HSM, claves públicas - a través de JWKS con 'kid' y rotación.
Validación local (sin llamada de red IdP).

3. 3 SPIFFE/SPIRE (SVID)

Identidad universal de los worcload: 'spiffe ://trust-domain/ns/< ns >/sa/< sa>'.
issuance/rotation automático X.509/JWT-SVID, integración con Istio/Linkerd.

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

Los clientes de máquinas reciben un token de STS; para acciones «en nombre» del usuario - OBO (intercambio de tokens).

Combinar: mTLS para el canal, JWT para el mensaje, SPIFFE para las identidades sostenibles.

4) Arquitectura de referencia

[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): lanza JWT/CVID de servicio corto, publica JWKS.
Gateway (PEP): el término red, valida mTLS/JWT, enriquece el contexto, solicita PDP.
Servicios (PEP): volver a validar (defense in depth), caché de soluciones PDP.
SPIRE/mesh: certificados automáticos y SVID para mTLS.

5) Formato JWT de servicio (ejemplo)

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

Firmado ES256/EdDSA, 'kid' indica la clave activa.
Opcionalmente binding al canal: bandera, hash cert, SVID.

6) Política de extradición (STS) y verificación

• Subject se extrae del certificado/registro de cliente/SVID del cliente.
• Duración de la vida 2-5 min, refresh no - en su lugar volver a pedir STS.
• Los scoops/audiencias se toman de la Policy Store (GitOps) y no de la solicitud del cliente.

1. Comprobar mTLS (opcional) y la validez de la cadena.

2. Comprobar la firma JWT por JWKS (por 'kid').

3. Para taladrar 'amb/nbf/iss/aud', tenant/region/licence.

4. Enriquecer el contexto y preguntar a PDP (RBAC/ABAC/ReBAC).

5. Almacenamiento en caché de la solución PDP (TTL 30-120 c), discapacidad por evento.

7) Multi-tenant y regiones (dominios de confianza)

Comparte el trust-domain's: 'spiffe ://eu. core`, `spiffe://latam. core`.
JWKS/PKI por regiones; interregión - sólo a través de puertas de enlace de confianza.
Incluya en los sellos 'tenant/region/licence' y compruebe la conformidad con el recurso.
Segmentar los registros/auditorías por tenantes y regiones.

8) Mesh/sidecar y modo sin mesh

Istio/Linkerd: mTLS fuera de la caja, policy-enforcement a nivel de L4/L7, integración con SPIRE.
Sin mesh: biblioteca cliente + TLS mutual en la aplicación; más difícil de controlar la rotación: automatice a través del agente.

9) Llaves, JWKS y rotación

Claves privadas sólo en KMS/HSM; firma - Llamada remota/dispositivo.
Rotación cada N días; dual-key: viejo + nuevo aceptado, issuer firma nuevo después de calentar los cachés.
Monitoreo: proporción de consumo por 'kid', clientes 'colgados' en la antigua clave.

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) Enlace de enlace (DPoP/mTLS-bound)

mTLS-bound tokens: en JWT, añadir hash del certificado del cliente; en la recepción para hacer la prueba.
DPoP: para clientes HTTP sin mTLS - firmar cada solicitud con una clave DPoP, en AT colocar el DPoP thumbprint.

11) Errores y política de devolución

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

La respuesta contiene machine-readable 'error _ code' y 'as _ of' (versión clave/política).

12) Observabilidad y auditoría

• `s2s_auth_p95_ms`, `verify_jwt_p95_ms`, `jwks_skew_ms`,
• `invalid_token_rate`, `aud_mismatch_rate`, `insufficient_scope_rate`,
• consumo por 'kid', una fracción de las consultas mTLS-bound.

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

• Emisión de tokens, rotación de claves, cambios de directivas, solicitudes rechazadas.

13) Rendimiento

Verificación de JWT: local, almacenamiento en caché JWKS (TTL 30-60 s) con actualización en segundo plano.
Cadenas X.509 - Pinning CA y caché OCSP/CRL.
Lleve la validación costosa I/O a gateway/sidecar.
Utilice el prefetch de tokens/certificados (10-20 s antes de la expiración).

14) Pruebas

Contrato/Interop: diferentes NAP/bibliotecas, clock skew ± 300 s.
Negative: token caducado/falso, 'aud' incorrecto, región/tenant equivocado, cert-chain roto.
Chaos: rotación repentina de 'kid', inaccesibilidad de JWKS, expiración masiva, acantilado de mTLS.
Load: pico de emisión en STS, ráfaga de verify en gateway.
E2E: mTLS-only, JWT-only, modo combinado, Token Exchange (OBO).

15) Playbooks (runbooks)

1. Compromiso de clave de firma

Revoke 'kid' inmediato, lanzamiento de nuevos tokens TTL acortados, auditoría, búsqueda de clientes «dependientes», deny forzado para el viejo 'kid'.

2. Masa 'INVALID _ TOKEN'

Comprobar el caché JWKS, el reloj rassinhron, los orígenes de los tokens (TTL demasiado corto), ampliar temporalmente la tolerancia de skew, calentar JWKS.

3. fallas mTLS

Comprobación de la cadena de CA, plazos de SVID, tiempo de host; emergency-relanzamiento a través de SPIRE/Istio, incluir rutas fallback sólo dentro de la región.

4. Crecimiento de 'AUD _ MISMATCH'

Derivación de políticas de audiencia: comparar la política STS con las llamadas reales, agregar temporalmente el 'aud' deseado, programar el ajuste de la arquitectura de llamadas.

5. STS no disponible/ralentizado

Aumentar TTL de tokens ya emitidos (grace), habilitar prefetch/refresh-anterior, scale-out STS.

16) Errores típicos

Claves API de larga vida/secretos en env/código.
JWKS/PKI común «a todas las regiones y para todo momento».
Sin binding (mTLS/DPoP) → token es fácil de llevar.
Ancha 'aud =' y scopes 'admin' por defecto.
Rotación sin dual-key período → masivo 401.
Verificación de tokens sólo en gateway (no defense in depth).
El abandono «mudo» (no hay 'error _ code' y 'reason') es difícil de desbancar y entrenar a los equipos.

17) Mini plantillas de configuración

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 verificación antes de la venta

• JWT de servicio corto (≤5 min), verificación local, caché JWKS.
• mTLS (o DPoP) está habilitado; prioritariamente - mTLS-bound tokens.
• SPIFFE/SPIRE o equivalente para la emisión/rotación automática de certificados.
• STS con las políticas audience/scope; emisión sólo por identidad de confianza.
• División de los dominios de confianza y JWKS por región; se comprueban los sellos tenant/region/licence.
• PDP/PEP integrado, caché de soluciones + discapacidad por eventos.
• Ventanas dual-key, monitoreo de consumo 'kid', alertas en invalid/aud mismatch.
• Registros completos/auditoría de S2S, métricas de rendimiento/error incluidas.
• Playbooks para comprometer la clave, caída de STS, fallo de mTLS.
• Se ha completado el conjunto de pruebas contract/negative/chaos/load/E2E.

la Conclusión

La autenticación S2S es una combinación de canal de confianza (mTLS), mensaje de confianza (JWT cortos) e identidad de worcload sostenible (SPIFFE), administrada por un STS centralizado y verificada localmente. Agregue separación de dominios trust, audience/scopes rigurosos, rotación automática y observabilidad, y obtenga un contorno que sea confiable, explicable y escalable junto con la plataforma y su geografía.