Rotación de claves y tokens

1) Por qué se necesita la rotación

Las claves y los tokens «envejecen» inevitablemente: exposición en los logotipos/backups, riesgos de información privilegiada, vulnerabilidades de las bibliotecas, filtraciones de socios. La rotación reduce el «tiempo de vida de riesgo» y da capacidad de manejo en incidentes. El objetivo es construir ciclos de rotación predecibles y mecanismos de revocación rápida sin downtime.

2) Área: qué rotamos exactamente

Claves de firma/cifrado: JWT (JWS/JWE), OAuth/OIDC, SAML, webhooks (HMAC), licencias.
Secretos de integración: claves API, secreto de cliente, contraseñas de tecnología. usuarios.
TLS/mTLS: certificados de servidor/cliente, CA raíz/intermedio.
Claves de datos: KEK/CMK en KMS/HSM, DEK (envelope encryption).
Токены: access/refresh, service-to-service (mTLS, HMAC), short-lived session.

3) Almacenamiento, versiones, etiquetas

KMS/HSM/Vault como fuente de la verdad. Está prohibido almacenar claves privadas en git/ENV/archivos de imagen.
Versionar: 'key _ id '/' version' + etiquetas: 'purpose = jwt-sign',' env = prod', 'alg = ES256', 'created _ at', 'rotates _ at'.
Políticas de acceso: principio de derechos mínimos necesarios (privilegio least), reparto de responsabilidades (SoD).
Auditoría: quién creó/leyó/firmó; registros inmutables.

4) Patrones de rotación básicos

4. 1 Ventanas superpuestas (graceful rollover)

La nueva clave → publicamos en JWKS/distribuimos el certificado.
Ventana de superposición: validación con llaves antiguas y nuevas, la firma es sólo nueva.
Después de que el período de gracia haya expirado - eliminar el antiguo del conjunto de confianza.

4. 2 Doble liberación (dual-run)

El corto periodo en el que una parte de las instancias firma la antigua, la parte es nueva (para los grandes flitos).
Requiere un JWKS estrictamente sincronizado y monitorear la proporción de validaciones por 'kid'.

4. 3 Rotate-on-schedule vs rotate-on-use

Según lo programado: una vez cada N días/semanas (llaves de firma, TLS).
Cuando se utiliza: refresh-tokens son desechables, por cada intercambio de liberación de nuevo (rotación «deslizante»).

5) JWT/JWKS: práctica

5. 1 Encabezados e identificadores

Utilice 'kid' en el encabezado JWS para seleccionar una clave de verificación.
Un mínimo de climas, un corto 'amb', correctos 'aud/iss/nbf'.

json
{ "alg": "ES256", "kid": "jwt-2025-10", "typ": "JWT" }

5. 2 Publicación JWKS

JWKS debe contener todas las claves de validación activas (antiguo + nuevo en la ventana grace).
Almacenamiento en caché JWKS en clientes: TTL corto (por ejemplo, 5-15 min).
Cuando se compromete, quita la clave comprometida de JWKS (drásticamente), la memoria caché con discapacidad de fuerza.

json
{
"keys": [
{ "kty":"EC","crv":"P-256","kid":"jwt-2025-10","use":"sig","alg":"ES256","x":"...","y":"..." },
{ "kty":"EC","crv":"P-256","kid":"jwt-2025-07","use":"sig","alg":"ES256","x":"...","y":"..." }
]
}

5. 3 Cadencia y plazos

Firma JWT: rotación de la clave cada 3-6 meses (o más comúnmente para alto riesgo).
El token de acceso de 'amb': 5-30 min; refresh - 7-30 días (con «rotate-on-use»).
Forzar el «pegado» con PoP/DPoP (ver § 8) para reducir el riesgo de robo.

6) Rotación HMAC (webhooks/firmas)

Mantenga los secretos activos y canarios; Acepte las firmas de ambos.
Títulos: 'X-Signature' + 'X-Timestamp'; restricción de ventana ± 300s.
Desactivación total de la antigua - después de que el remitente haya cambiado confirmadamente.
Para socios: publique la fecha-hora de cambio y la verificación de endpoint.

7) TLS/mTLS y cadenas de confianza

ACME/auto-renew para certificados de servidor público (Let's Encrypt o CA corporativo).
mTLS: certificados de cliente cortos (7-30 días), rotación automática por canal (SPIFFE/SPIRE/mesh).
La rotación de CA intermedia/raíz es sólo a través de anclajes de confianza superpuestos (trust bundle) y canario de larga duración.
Siga OCSP/CRL y clock-skew. En los registros, las razones de la denegación de la validación.

8) PoP/DPoP y conjunto de token↔klyuch del cliente

DPoP (Demonstration of Proof-of-Possession): el token está enlazado a la clave pública del cliente; reduce el riesgo de replay.
Rotación de la clave del cliente = liberación de la nueva clave DPoP, tokens - por un corto tiempo.
Para el servicio a servicio, mTLS es preferido (el dispositivo/worker «lleva» la clave en HSM/TPM).

9) Refresh-tokens: rotate-on-use

Tokens de refresh desechables: cada intercambio → un nuevo refresh + access.
Lista de revocados 'jti '/' sid' almacenar con TTL = vida útil refresh.
Detecto de reutilización (re-play): revocación inmediata de la sesión/dispositivo, alerta.

10) Revocación y listas de bloqueo

JWT sin introspección: use el corto 'amb' + «listas negras» 'jti' para casos críticos (localmente/en Redis, charding por hash).
OAuth introspection: servidor de estado centralizado; caché «active = false/true» con una TTL corta.
Claves API: almacene el hash de clave (como contraseñas), las etiquetas propietario/tenant, scope, fecha de creación/último acceso; retroalimentación - instantánea.

11) Claves de datos: encriptación envelope

CMK/KEK (KMS/HSM) protege DEK; la rotación de CMK se produce sin que los datos se hayan vuelto a abrir: el pere-wrap DEK.
DEK para cada objeto/tenant/lote; KDF/HKDF para claves derivadas.
Directivas de destrucción (crypto-shredding): eliminar KEK = ilegibilidad de los datos cuando se comprometen.

12) Procedimientos de incidentes (compromiso)

1. Congelar: deshabilitar la emisión de tokens en una clave comprometida, transferir la emisión a una nueva.
2. Revocar: eliminar 'kid' de JWKS, revocar certificados (OCSP/CRL), bloquear las claves API de la lista.
3. Acortar TTL: reducir temporalmente los tokens 'amb', reforzar la verificación PoP/DPoP.
4. Logout forzado: invalidar sesiones (revoke 'sid '/' jti').
5. Forenzika y reporting: timelines, cobertura, quién/qué sufrió; actualizar los playbooks.

13) Pipeline y rollout

13. 1 Generación y publicación

Generar claves en HSM/KMS; Exportar clave privada - Prohibido.
Publicación automática de certificados/JWKS con verificación y pruebas.
Lanzamiento de Canarias: 1-5% de los clientes → 100%.

13. 2 Control de la salud

Métricas: proporción de validaciones por 'kid', errores de firma/certificado, deriva del reloj.
Alertas: ráfaga 401/403 debido a la firma, OCSP/CRL no disponible, certificados caducados (T-30/T-7/T-1).

14) Confecciones y ejemplos

14. 1 Ejemplo de política Vault/KMS (pseudo)

hcl path "transit/keys/jwt-prod" {
capabilities = ["read," "update," "list"] # signature/rotation
}
path "transit/keys/jwt-prod/rotate" {
capabilities = ["update"]
}

14. 2 Ejemplo de plan de rotación JWT

T0: create a new version of the key (kid = jwt-2025-10), add to JWKS
T0 + 15m: start signing with a new kid; validate with old and new
T0 + 7d: remove old kid from JWKS
T0 + 30d: delete old private key from KMS (schedule purge)

14. 3 Envoy: actualización forzada de JWKS (pseudo)

yaml jwt_authn:
providers:
oidc:
issuer: https://auth. example. com/
remote_jwks:
http_uri:
uri: https://auth. example. com/.well-known/jwks. json cluster: jwks_cluster timeout: 2s cache_duration: 300s # короткий TTL

15) Observabilidad y auditoría

Метрики: `jwt_verify_fail_total{reason}`, `jwks_refresh_total`, `jwks_kid_share{kid}`, `token_revoked_total`, `refresh_rotations_total`, `dpop_fail_total`.
Логи: `kid`, `jti`, `sid`, `reason`, `client_id`, `tenant`, `trace_id` (без PII).
Dashboards: mapa de cuotas 'kid', certificados caducados, frecuencia de revocación, firmas no válidas por región.

16) Antipattern

Los JWT de larga vida sin revocación y sin un corto 'amb'.
Ausencia de 'kid' y selección de clave de verificación 'manual'.
Almacenar secretos en ENV/k8s-Secret sin KMS y sin cifrado a nivel etcd.
Tokens refresh no rotativos; reutilización de refresh sin detalle.
Una única clave API global «para todos».
Liberación «silenciosa» de nuevas claves sin publicación y monitoreo de JWKS.
Las ventanas de superposición cero (sustitución instantánea) → 401/403 en masa.

17) Especificidad de iGaming/finanzas

Reguladores y auditorías: registros inmutables de rotaciones/revisiones; la probabilidad del tiempo y los actores.
Afiliados PSP/KYC: claves separadas por socio/jurisdicción; revocación rápida en infracciones de seguridad/SLA.
Multiarrendamiento: claves API per-tenant con scope; aislamiento de claves de marcas/regiones.
Alto riesgo: PoP/DPoP para operaciones críticas, cortas 'amb', mTLS entre servicios internos.
Backoffice: SSO/OIDC, sesiones cortas, tokens de hardware (FIDO2), rotate-on-schedule omnipresente.

18) Lista de comprobación prod

• Todas las claves privadas en KMS/HSM/Vault; prohibida la exportación.
• JWKS se publica y se almacena en caché con una TTL corta; hay un 'kid' en los titulares de la JWT.
• Plan de rotación con ventana superpuesta y rollout automático.
• Los tokens refresh son desechables; lista de revocados 'jti' con TTL.
• Secretos HMAC: activo + canario; recepción por ambos; T-tiempo de cambio anunciado.
• TLS/mTLS: auto-renew, alertas T-30/T-7/T-1, trust bundle para el cambio de CA.
• Encriptación envelope: Los KEK/CMK se rotan sin downtime, DEK por objeto/tenant.
• Métricas/alertas por firma, JWKS, comentarios; dashboards 'kid' -doley.
• El playbook de incidentes (compromiso) y ejercicios regulares.
• Pruebas canarias y réplicas de validación con nuevas claves/CA.

19) TL; DR

Mantenga las claves en KMS/HSM, firme JWT con 'kid' y publique JWKS. Rotar claves y certificados con solapamiento, seguir las cuotas de validación por 'kid'. Refresh es un rotate-on-use y el corto 'amb'; para operaciones críticas: PoP/DPoP y mTLS. Para los datos, utilice encriptación envelope con rotación KEK sin downtime. Introduce métricas/alertas, playbucks de incidencias y rotaciones regulares en Canarias.