Gestión de claves y secretos: ciclo de vida, rotación y límites de exposición

Qué es “gestión de claves y secretos” en sistemas reales

En producción, la seguridad de la criptografía suele fallar no por el algoritmo, sino por cómo se crean, almacenan, usan y retiran las claves y los secretos. “Clave” (key) y “secreto” (secret) no son sinónimos: una clave criptográfica se usa por un algoritmo (cifrado, firma, HMAC), mientras que un secreto puede ser una credencial o material sensible (tokens, API keys, contraseñas de servicio, cadenas de conexión). La gestión correcta define un ciclo de vida, controles de acceso, auditoría, rotación y recuperación ante incidentes, minimizando el tiempo y el lugar donde el material sensible existe en claro.

Ciclo de vida de claves: fases y decisiones

1) Generación segura

• Fuente de aleatoriedad: genere claves con un CSPRNG del sistema operativo o dentro de un KMS/HSM. Evite generar claves “a mano” o derivarlas de identificadores.
• Longitud y tipo: defina tamaños según el tipo de clave (DEK simétrica, clave de firma, clave HMAC, etc.) y su política interna.
• Etiquetado y metadatos: asigne key_id, propósito, entorno (prod/stage), propietario, fecha de creación, fecha de expiración, y política de rotación. Esto habilita auditoría y automatización.

2) Almacenamiento

• Preferencia: almacene claves maestras y material de alto valor en KMS/HSM. Evite archivos locales, repositorios, wikis o gestores de contraseñas genéricos para claves de cifrado de datos.
• Separación de responsabilidades: quien despliega no debería poder extraer claves; quien administra claves no debería poder leer datos. Use roles distintos.
• Política de exportación: para claves críticas, configure “no exportable” (especialmente en HSM). Si una clave puede extraerse, asuma que eventualmente se filtrará.

3) Uso

• Principio de mínimo privilegio: el servicio debe tener permisos para usar la clave (encrypt/decrypt/sign/verify) pero no para administrarla (disable/delete/rotate) salvo necesidad.
• Contexto de uso: aplique “binding” a contexto (por ejemplo, encryption_context o AAD) para evitar que un ciphertext válido en un servicio sea aceptado en otro.
• Evitar exposición: no imprima claves/secretos en logs, no los pase por parámetros de URL, no los serialice en errores.

4) Rotación

• Rotación planificada: periódica (cumplimiento) o por riesgo (incidente, sospecha de filtración, cambio de personal).
• Rotación sin caída: use versionado de claves y compatibilidad de lectura con versiones antiguas (ver sección “Diseño de rotación sin pérdida de disponibilidad”).

5) Revocación / deshabilitación

• Revocar significa impedir el uso futuro. En KMS suele ser “disable” o “schedule deletion”.
• Respuesta a incidentes: ante sospecha, deshabilite primero, rote credenciales dependientes (tokens), y luego planifique re-cifrado si aplica.

6) Destrucción

• Destrucción lógica: eliminar o programar borrado en KMS/HSM con retención controlada.
• Destrucción física: para HSM o medios, siga procedimientos de borrado seguro y cadena de custodia.
• Dependencias: no destruya una KEK si todavía hay DEKs envueltas por ella sin plan de migración.

Separación de claves por propósito (y por qué importa)

Una regla operativa: una clave, un propósito. Reutilizar material para distintos usos crea riesgos de confusión, escalada de impacto y errores de implementación.

• Claves de cifrado (DEK): cifran datos (p. ej., registros, blobs). Deben rotar con frecuencia razonable y minimizar exposición. Normalmente son simétricas y de vida corta o media.
• Claves de firma: producen firmas (autoría/no repudio). Su protección es crítica; la rotación suele ser menos frecuente, pero con procedimientos estrictos. La verificación puede ser pública (clave pública distribuida).
• Claves HMAC: autentican mensajes entre componentes que comparten secreto. No deben reutilizarse como claves de cifrado. Rotación coordinada entre emisor y receptor.
• Claves de sesión: efímeras, derivadas o negociadas por sesión/operación. Deben vivir lo mínimo posible y no almacenarse.

Además, separe por entorno (prod/stage/dev), por tenant (multi-tenant), por región (si aplica) y por dominio de datos (PII vs. no PII) para limitar el radio de impacto.

Patrones recomendados: envelope encryption, KEK/DEK y jerarquías

Envelope encryption (cifrado por envoltura)

Patrón estándar para cifrar grandes volúmenes sin exponer una clave maestra. Se usa una DEK (Data Encryption Key) para cifrar el dato y una KEK (Key Encryption Key) para cifrar (envolver) la DEK.

• DEK: generada por objeto/archivo/registro o por lote. Se usa localmente para cifrar/descifrar.
• KEK: vive en KMS/HSM. Se usa para envolver/desenvolver DEKs. Idealmente no sale del servicio gestionado.

Flujo típico (alto nivel): 1) Generar DEK aleatoria 2) Cifrar datos con DEK (produce ciphertext + nonce + tag) 3) Envolver DEK con KEK en KMS (produce wrapped_dek) 4) Guardar: {ciphertext, nonce, tag, wrapped_dek, key_id, key_version, aad/context}

Ventajas: rotación de KEK sin re-cifrar todos los datos inmediatamente (puede re-envolver DEKs), y rotación de DEKs por objeto sin tocar la KEK.

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

Jerarquía de claves (KEK/DEK) y límites de exposición

• KEK debe tener exposición mínima: idealmente operaciones dentro de KMS/HSM, permisos restringidos, auditoría fuerte.
• DEK puede existir en memoria del servicio por instantes. Diseñe para que no se escriba a disco ni se loguee.
• Separación por dominio: distintas KEKs por tipo de dato o por tenant reduce el “blast radius”.

Uso de KMS/HSM: cuándo y cómo

Cuándo usar KMS

• Cuando necesita control centralizado de claves, rotación, políticas IAM, auditoría y operaciones criptográficas gestionadas.
• Cuando quiere evitar que claves maestras residan en servidores de aplicación.

Cuándo usar HSM

• Cuando requiere protección reforzada (claves no exportables, cumplimiento estricto, firma de alto valor, custodia de claves raíz).
• Cuando el riesgo de extracción de claves desde software es inaceptable.

Controles de acceso y auditoría (imprescindibles)

• IAM por acción: separe permisos de Encrypt/Decrypt de CreateKey/ScheduleDeletion/PutKeyPolicy.
• Condiciones: limite por red/VPC, identidad de workload, etiquetas, y contexto de cifrado (cuando el proveedor lo soporte).
• Auditoría: registre cada uso de clave (quién, cuándo, desde dónde, qué operación). Configure alertas por patrones anómalos: picos de Decrypt, uso desde identidades nuevas, regiones inesperadas.
• Break-glass: acceso de emergencia con MFA, aprobación y caducidad, auditado y probado.

Diseño de rotación sin pérdida de disponibilidad

Principio: escribir con la nueva, leer con todas las válidas

Para evitar interrupciones, la aplicación debe poder descifrar/verificar con claves antiguas durante una ventana de transición, mientras cifra/firma con la clave nueva.

Versionado de claves

Modele claves con un identificador estable y versiones:

• key_id: identifica la familia (p. ej., payments-data).
• key_version: versión concreta (p. ej., v7).
• Estado: primary (para escritura), active (para lectura), deprecated (solo lectura temporal), disabled.

En cada ciphertext, almacene key_id y key_version (o el identificador del proveedor KMS) para resolver qué clave usar al descifrar.

Rotación paso a paso (guía práctica)

1. Preparar: asegure que el formato de datos incluye key_version y que el código puede resolver múltiples versiones.
2. Crear nueva versión: genere v(n+1) en KMS/HSM. No cambie todavía la escritura.
3. Distribuir configuración: despliegue el cambio para que los servicios reconozcan v(n+1) como válida para lectura (aunque aún no exista ciphertext con ella).
4. Cambiar escritura: marque v(n+1) como primary. A partir de aquí, todo nuevo dato se cifra/firma con la nueva versión.
5. Re-cifrado gradual (si aplica): migre datos antiguos en segundo plano (batch/cola), re-cifrando con una nueva DEK o re-envolviendo DEKs según el patrón usado.
6. Monitorear: mida cuántos objetos siguen en v(n). Alerta si aparecen escrituras nuevas con versión antigua.
7. Deprecar: cuando el porcentaje residual sea aceptable, deje v(n) en modo solo lectura por una ventana definida.
8. Deshabilitar: deshabilite v(n) cuando ya no se necesite para lectura. Mantenga un plan de rollback documentado.

Re-cifrado gradual vs. re-envoltorio

• Re-envolver DEKs (envelope encryption): si el dato está cifrado con DEK y la DEK está envuelta por KEK, puede rotar KEK re-envolviendo la DEK sin tocar el ciphertext grande. Es más rápido y barato.
• Re-cifrar datos: necesario si cambia la DEK o si sospecha exposición de DEKs. Implica leer y escribir datos; planifique capacidad, ventanas y consistencia.

Backup, recuperación y multi-región

Backups: qué significa “recuperable” con claves

Un backup de datos cifrados es inútil si no puede descifrarse en un desastre. Diseñe backups considerando la disponibilidad de claves y políticas.

• Backups de metadatos: guarde junto al dato cifrado el key_id/key_version, el wrapped_dek (si aplica), y el contexto/AAD necesario.
• Backups de configuración: respalde políticas IAM, mapeos de claves por servicio, y configuraciones de KMS (sin exportar material secreto si es no exportable).
• Pruebas de restauración: ejecute ejercicios periódicos que incluyan descifrado real en un entorno controlado.

Multi-región

• Claves replicadas vs. independientes: si su proveedor permite claves multi-región, evalúe replicación para continuidad. Si no, use claves por región y un plan de migración de datos.
• Failover: asegure que el servicio en región secundaria tiene permisos y rutas de red para usar el KMS/HSM correspondiente.
• Consistencia de políticas: mantenga políticas equivalentes en todas las regiones; automatice con infraestructura como código.

Escenarios de recuperación

• Pérdida de acceso a KMS: defina degradación: ¿el sistema puede operar en modo lectura? ¿se bloquean operaciones que requieren descifrado?
• Compromiso de credenciales: rote credenciales de acceso al KMS (roles, tokens) y luego evalúe rotación de claves según exposición.
• Eliminación accidental: use retención y borrado programado para permitir recuperación dentro de una ventana.

Evitar secretos embebidos y fugas por configuración

Antipatrón: secretos en el código o repositorio

• Qué evitar: claves API, tokens, certificados privados, cadenas de conexión en el código, en archivos .env subidos, en ejemplos de README, o en tests.
• Patrón correcto: use un secrets manager o KMS para entregar secretos en tiempo de ejecución con identidad de workload (no con secretos estáticos).
• Controles: escaneo de secretos en CI, protección de ramas, y revisión de cambios que toquen configuración sensible.

Variables de entorno: útiles, pero peligrosas si se gestionan mal

• Riesgos: pueden filtrarse en dumps de procesos, herramientas de diagnóstico, paneles de orquestación, o logs de arranque.
• Buenas prácticas: minimice su uso para material altamente sensible; prefiera inyección desde un gestor de secretos hacia memoria del proceso; limite quién puede ver la configuración del runtime; rote y caduque.

Logs y trazas: la fuga más común

• No registrar: tokens, cabeceras de autorización, cookies de sesión, wrapped_dek si puede facilitar ataques operativos, material de claves, payloads completos con PII.
• Redacción (redaction): implemente filtros a nivel de librería de logging y de gateway (por ejemplo, enmascarar Authorization, Set-Cookie, campos password, token).
• Errores: no incluya secretos en mensajes de excepción; use IDs de correlación para depurar sin exponer datos.

Checklist operativo (para aplicar en un servicio)