Administración de claves y rotación

Las claves son las «raíces de la confianza» de la plataforma. Un robusto sistema de gestión de claves (KMS/HSM + procesos + telemetría) transforma la criptografía de una única integración en una operación diaria: las claves se actualizan regularmente, su uso es transparente, las comprometedoras se localizan y los clientes experimentan un cambio de clave sin downtime.

1) Objetivos y principios

Crypto agility: posibilidad de cambiar el algoritmo/longitud de la clave sin grandes migraciones.
Exposición Least: las claves privadas no salen de KMS/HSM; Operaciones de firma/descifrado: eliminadas.
Short-lived artifacts: tokens/claves de sesión viven minutos-horas, no semanas.
Dual-key/Dual-cert ventanas: rotaciones sin problemas.
Regional & tenant isolation: las claves se dividen por región y arrendatario.
Auditabilidad completa: registro de operaciones inmutable, certificación HSM, control de acceso.

2) Clasificación de claves

Root CA/Master Key (Root CA/Master Key): un uso extremadamente raro, se mantiene en HSM, se aplica para liberar claves intermedias o envoltorios de clave de datos.
Operativo: firma JWT/eventos, TLS, firma de webhooks, cifrado de configuraciones/PII.
Sesión/temporal: DPoP, mTLS-binding, salida ECDH para canal/diálogo.
Integración: claves de socios (públicas) y secretos de HMAC.
Llaves de datos (DEK): utilizan cifrado envelope bajo KEK, no se almacenan explícitamente.

3) Identificación de claves y política de uso

yaml key:
kid: "eu-core-es256-2025-10"
alg: "ES256"         # или EdDSA, RSA-PSS, AES-GCM, XChaCha20-Poly1305 purpose: ["jwt-sign","webhook-sign"]
scope: ["tenant:brand_eu","region:EE"]
status: "active"       # active      next      retiring      revoked created_at: "2025-10-15T08:00:00Z"
valid_to:  "2026-01-15T08:00:00Z"

Reglas: «un objetivo es una clave» (mínimo de sharing), áreas de aplicación explícitas y plazos.

4) Ciclo de vida de clave (KMS/HSM)

1. Generate: en HSM/KMS, con política de exportación = prohibido.
2. Publish: para asimetría - JWKS/certificado con 'kid'.
3. Use: operaciones remotas (sign/decrypt) con IAM controlado.
4. Rotate: ejecuta la clave 'next' y habilita el dual-accept.
5. Retire: traducir el antiguo a 'retiring', luego 'revoked'.
6. Destroy: destruir el material (con el protocolo de purge) después de una ventana de controversia.

5) Rotación: estrategias

Scheduled: calendario (por ejemplo, cada 1-3 meses para la firma JWT, 6-12 meses para TLS-sert).
Rolling: cambio gradual de consumidores (JWKS ya contiene una nueva clave; el emisor comienza a firmar nuevo después de calentar los cachés).
Fuerza (seguridad): rotación inmediata cuando se compromete; ventana corta de dual-accept, expiración agresiva de artefactos.
Staggered per region/tenant: para no «aplaudir» al mundo entero al mismo tiempo.

Regla de oro: primero la publicación, luego la firma es nueva, y sólo después de la expiración es la revocación de la antigua.

6) Ventana Dual-key (cambio sin problemas)

Publicamos JWKS con el viejo y nuevo 'kid'.
Los verificadores aceptan ambos.
El emisor, después de N minutos/horas, comienza a firmar con el nuevo.
Monitorim fracción de las inspecciones en el antiguo/nuevo 'kid'.
Al llegar a la fracción objetivo, Retairim es viejo.

yaml jwks:
keys:
- kid: "eu-core-es256-2025-10" # new alg: "ES256"
use: "sig"
crv: "P-256"
x: "<...>"; y: "<...>"
- kid: "eu-core-es256-2025-07" # old alg: "ES256"
use: "sig"
...

7) Políticas de firma y validación

Algoritmos predeterminados: ES256/EdDSA para la firma; RSA-PSS donde se requiere.
Prohibición de 'ninguno '/algoritmos débiles; whitelisting en el lado de la verificación.
Clock skew: permitimos ± 300 c, lógica las desviaciones.
Key pinning (servicios internos) y corto TTL JWKS-caché (30-60 s).

8) Encriptación Envelope y KDF

ciphertext = AEAD_Encrypt(DEK, plaintext, AAD=tenant    region    table    row_id)
DEK = KMS. Decrypt (KEK, EncryptedDEK )//on access
EncryptedDEK = KMS. Encrypt (KEK, DEK )//on write

KEK (Key Encryption Key) se almacena en KMS/HSM, se rota regularmente.
DEK se crea en un objeto/lote; al rotar KEK, realizamos re-wrap (rápidamente, sin volver a cifrar los datos).
Para subprocesos, ECDH + HKDF para la salida de claves de canal de breve vida.

9) Regionalidad y multi-tenant

Las claves y JWKS son preregionales: 'eu-core', 'latam-core' son diferentes conjuntos de claves.
División de IAM/auditoría por tenant/región; las claves no «fluyen» entre las residencias.
'kid' codifica con el prefijo de dominio de confianza: 'eu-core-es256-2025-10'.

10) Secretos de integración (HMAC, claves API)

Almacenar en KMS-backed Secret Store, emitir a través de short-lived client secrets (política de rotación ≤ 90 días).
Admite dos secretos activos (dual-secret) en rotación.
Para webhooks - timestamp + HMAC firma corporal; ventana de tiempo ≤ 5 minutos.

11) Control de acceso y procesos

Matriz IAM: quién puede 'generate', 'sign', 'decrypt',' rotate ',' destroy '(mínimo de roles).
Principio de 4 ojos: las operaciones sensibles requieren dos confirmaciones.
Cambiar Windows: ventanas de habilitación de nuevas claves y regiones canarias de prueba.
Runbooks: plantillas de procedimientos para rotaciones scheduled y forced.

12) Observabilidad y auditoría

• `sign_p95_ms`, `decrypt_p95_ms`, `jwks_skew_ms`,
• consumo por 'kid', 'old _ kid _ usage _ ratio',
• `invalid_signature_rate`, `decrypt_failure_rate`.

• Cada operación de firma/descifrado: 'who/what/when/where/kid/purpose'.
• Historial de estados de claves y solicitudes de rotación/revocación.
• Certificación de HSM, registros de acceso a materiales clave.

13) Playbucks (incidentes)

1. Compromiso de clave de firma

Revoke inmediato del antiguo 'kid' (o traducción a 'retiring' con ventana mínima), publicación del nuevo JWKS, TTL abreviado tokens, fuerza-logout/discapacidad RT, comunicación a los propietarios de las integraciones, auditoría retro.

2. Masa 'INVALID _ SIGNATURE' después de la rotación

Comprobar la caché JWKS/clock skew, devolver el dual-accept, extender la ventana, enviar a los clientes.

3. Aumento de la latencia de KMS/HSM

No se permite habilitar la caché de firmas local; en cambio - batch/queue en emisor, autoscaling HSM proxy, priorizando hilos críticos.

4. Denegación de una región

Activar los procedimientos de aislamiento regional; no «tirar» de claves de otras regiones; degradar las funciones atadas a una firma en una región caída.

14) Pruebas

Contrato: corrección de JWKS, correcta 'kid '/alg/use, compatibilidad del cliente.
Negative: firma falsa, 'kid' obsoleto, alg incorrecto, clock skew.
Chaos: rotación instantánea, inaccesibilidad de KMS, «deriva» del tiempo.
Load: pico de firmas (JWT/webhooks), pico de transcripciones (PII/pagos).
E2E: ventana dual-key: liberación - verificación - transferencia de tráfico - rechazo de la antigua.

15) Ejemplo de configuración (YAML)

yaml crypto:
regions:
- id: "eu-core"
jwks_url: "https://sts. eu/.well-known/jwks. json"
rotation:
jwt_sign: { interval_days: 30, window_dual: "48h" }
webhook: { interval_days: 60, window_dual: "72h" }
kek:   { interval_days: 90, action: "rewrap" }
alg_policy:
sign: ["ES256","EdDSA"]
tls: ["TLS1. 2+","ECDSA_P256"]
publish:
jwks_cache_ttl: "60s"
audit:
hsm_attestation_required: true two_person_rule: true

16) Ejemplo de JWKS y marcadores en artefactos

json
{ "alg":"ES256", "kid":"eu-core-es256-2025-10", "typ":"JWT" }

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

17) Anti-patrones

Claves de larga vida «por años» y comunes a todas las regiones.
Rotación «en un momento» sin dual-accept.
Exportación de claves privadas de KMS/HSM «para la rapidez».
Mezcla de tareas: una clave para firmar JWT y cifrar los datos.
No hay registros/certificaciones de HSM y restricciones IAM.
No hay mecanismo de re-wrap para DEK cuando se gira KEK.
«Secretos» manuales en env en lugar de Secret Store.

18) Lista de verificación antes de la venta

• Todas las claves privadas en KMS/HSM; La matriz IAM y el principio de 4 ojos están personalizados.
• Se aprueban las políticas de algoritmos, longitud de claves y plazos de vida.
• Se incluye un proceso dual-key con monitoreo de fracciones por 'kid'.
• JWKS se publica con un corto TTL y un calentamiento de cachés; los clientes aceptan ≥2 claves.
• Encriptación envelope: KEK rotado, DEK re-wrap sin downtime.
• Aislamiento regional y juegos de claves separados por tenantes.
• Playbucks de compromiso/balanceo/rotación de fuerza; corridas de entrenamiento.
• Métricas ('old _ kid _ usage _ ratio', 'invalid _ signature _ rate') y alertas están habilitadas.
• Se ha completado el conjunto de pruebas contract/negative/chaos/load/E2E.
• Documentación para integraciones: cómo manejar el cambio de 'kid', qué ventanas y códigos de error.

la Conclusión

La gestión de claves es una disciplina operativa: KMS/HSM como fuente de verdad, rotaciones regulares y seguras con dual-key, aislamiento regional y tenante, encriptación envelope y observabilidad. Siguiendo estas reglas, obtienes un cifrado que se escala, es resistente a incidentes y se explica fácilmente al auditor, y los desarrolladores e integradores experimentan cualquier cambio sin dolor.