Gestión de claves:
rotación, KMS y HSM sin misterio
Fundamentos de criptografía | unfantasmaenelsistema.com
Los artículos sobre cifrado y firmas terminan siempre en el mismo sitio: «…y la clave privada hay que protegerla». El de gestión de secretos deja abierto el «¿y dónde guardo la clave que cifra los secretos?». Este artículo responde a esa pregunta. Porque un cifrado AES-256 impecable no vale nada si la clave está en un fichero junto al dato cifrado, y una firma Ed25519 perfecta se vuelve en contra si cualquiera puede copiar la clave de firma del servidor de compilación.
Vamos a ver el ciclo de vida completo de una clave, la técnica de cifrado en sobre que usan todos los servicios de nube, qué es exactamente un HSM y qué aporta un KMS gestionado, y los errores de gestión de claves que aparecen una y otra vez en los informes de brechas.
Qué aprenderás en este artículo
Las fases del ciclo de vida de una clave: generación, distribución, uso, rotación, archivado y destrucción · Cifrado en sobre (envelope encryption) y la jerarquía KEK / DEK · Qué es un HSM, qué significa que «la clave no sale del hardware» y qué es FIPS 140 · KMS gestionado en la nube frente a HSM dedicado: cuándo tiene sentido cada uno · Separación de funciones y registro de uso de claves · Los errores recurrentes: clave en el código, una sola clave para todo, sin plan de rotación
1. El ciclo de vida de una clave
Una clave criptográfica no es un valor que se genera una vez y se olvida: pasa por fases, y cada una tiene sus riesgos.
| Fase | Qué ocurre | Riesgo principal |
|---|---|---|
| Generación | Se crea la clave con un generador de números aleatorios de calidad criptográfica | Aleatoriedad débil o predecible = clave adivinable |
| Distribución / instalación | La clave llega a donde se va a usar | Interceptación; copias en logs, historiales o backups |
| Uso | Cifra, descifra, firma o verifica | Exposición en memoria; uso desde componentes que no deberían tener acceso |
| Rotación | Se sustituye por una nueva y el material antiguo deja de usarse para cifrar | No rotar nunca; o romper el descifrado de datos antiguos al rotar mal |
| Archivado | Una clave retirada se guarda para poder descifrar datos históricos | Guardarla con menos protección que cuando estaba activa |
| Destrucción | Se elimina de forma irreversible cuando ya no hace falta | Copias olvidadas; borrado que no es borrado real |
La rotación merece una nota. Rotar no significa poder descifrar de golpe todo lo antiguo con la clave nueva: significa que a partir de ahora se cifra con la nueva, y las claves viejas se conservan solo para leer lo ya cifrado, hasta que esos datos se reescriban o caduquen. Una rotación bien diseñada es indolora porque cada dato cifrado lleva apuntado con qué versión de clave se protegió.
2. Cifrado en sobre: no cifres los datos con la clave «buena»
Si tienes que cifrar diez millones de registros, no los cifras directamente con tu clave maestra: esa clave estaría en memoria constantemente y rotarla obligaría a redescifrar y recifrar todo. La solución es una jerarquía de dos niveles, el envelope encryption:
- DEK (Data Encryption Key): una clave simétrica que cifra un dato concreto (un fichero, un registro, un bloque). Se generan muchas y son de usar y tirar
- KEK (Key Encryption Key): la clave maestra que solo cifra las DEK, nunca datos. Vive protegida en un KMS o un HSM y no sale de ahí
- Junto a cada dato cifrado se guarda su DEK ya cifrada por la KEK. Para leer el dato: se pide al KMS que descifre la DEK, se usa la DEK en memoria un instante y se descarta
Ventajas: la KEK apenas se expone (solo hace operaciones pequeñas y rápidas), rotarla solo obliga a recifrar las DEK —que son diminutas—, y puedes tener una DEK distinta por cliente, por fichero o por día sin coste práctico. Es como funciona el cifrado en reposo de AWS, GCP, Azure y la mayoría de bases de datos.
# Patron envelope con un KMS de nube (esquema conceptual) # 1. Pedir al KMS una DEK nueva: devuelve la clave en claro Y cifrada por la KEK aws kms generate-data-key --key-id alias/datos-clientes --key-spec AES_256 # -> Plaintext: (usar en memoria para cifrar, luego borrar) # -> CiphertextBlob: (guardar junto al dato cifrado) # 2. Para leer el dato: descifrar la DEK y usarla un instante aws kms decrypt --ciphertext-blob fileb://dek.cifrada
3. HSM: la clave no sale del hardware
Un HSM (Hardware Security Module) es un dispositivo —una tarjeta, un aparato de rack o un servicio respaldado por ese hardware— diseñado para una sola cosa: generar y custodiar claves de forma que el material de la clave nunca salga en claro. Le envías datos y una orden («firma esto», «descifra esto») y te devuelve el resultado; la clave se queda dentro.
- Resistencia física: si alguien intenta abrirlo o sondearlo, borra las claves (tamper-evidence y tamper-response)
- Aleatoriedad de calidad: incorpora fuentes de entropía por hardware para generar claves fuertes
- Control de uso: exige autenticación de varios operadores para las operaciones sensibles (ver sección 4)
- Certificación FIPS 140-2 / 140-3: un estándar del NIST que acredita, por niveles (2, 3, 4), la robustez física y lógica del módulo. Muchos sectores regulados lo exigen por contrato o por norma
Casos donde un HSM es casi obligatorio: las claves raíz de una PKI, las claves de firma de código de un fabricante, las claves de una pasarela de pago (el estándar PCI lo requiere), o la KEK principal de una organización grande.
4. KMS gestionado frente a HSM dedicado
| KMS gestionado (nube) | HSM dedicado / Cloud HSM | |
|---|---|---|
| Qué es | Servicio multiinquilino de claves (AWS KMS, Cloud KMS, Azure Key Vault estándar) | Hardware de uso exclusivo (CloudHSM, Azure Managed HSM, aparato propio) |
| Operación | API sencilla; el proveedor gestiona el hardware | Tú administras el clúster, usuarios y copias |
| Control de la clave | El proveedor puede tener acceso operativo teórico; existe la opción de traer tu propia clave (BYOK) o externa (XKS) | Solo tú; ni el proveedor puede extraerla |
| Certificación | Respaldado por HSM certificados FIPS 140-2/3 | FIPS 140-2/3 nivel 3, atribuible a tu tenant |
| Coste y complejidad | Bajo, por uso | Alto (tarifa por hora del clúster + operación) |
| Cuándo | El 95 % de los casos | Requisito regulatorio, soberanía de claves, PKI raíz, firma de código |
La recomendación práctica para casi todo el mundo: empieza con el KMS gestionado de tu proveedor, usa envelope encryption, activa la rotación automática de la KEK y define políticas de acceso estrictas. Sube a HSM dedicado solo cuando una norma, un cliente o un análisis de riesgo lo pidan expresamente.
5. Separación de funciones y registro de uso
Dos controles de gestión que valen tanto como la tecnología:
- Separación de funciones (dual control / m-de-n): ninguna persona sola puede exportar, borrar o reconfigurar una clave crítica. Las operaciones peligrosas requieren la aprobación de dos o más operadores. Evita tanto al empleado malicioso como el error de una sola persona
- Least privilege sobre las claves: el servicio de facturación puede pedir descifrar DEK de facturas y nada más. No hay una identidad con «acceso a todas las claves»
- Registro de uso auditable: cada operación de cifrado, descifrado o firma queda registrada (quién, cuándo, qué clave, desde dónde). En AWS es CloudTrail sobre KMS; permite detectar un uso anómalo —un pico de descifrados, un origen nuevo— que delata una credencial comprometida
- Alarmas: en operaciones destructivas (programar el borrado de una clave, deshabilitarla) y en desviaciones del patrón normal de uso
Borrar una clave es borrar los datos
Si destruyes la KEK, todos los datos cifrados bajo ella quedan irrecuperables al instante, aunque el texto cifrado siga en disco. Esto es útil como «borrado criptográfico» deliberado (dar de baja a un cliente), pero letal por accidente. Por eso los KMS imponen un periodo de espera obligatorio (7-30 días) antes de eliminar una clave de verdad
6. Los errores recurrentes
| Error | Por qué pasa | Qué hacer en su lugar |
|---|---|---|
| Clave en el código o en el repositorio | Comodidad durante el desarrollo que se queda | KMS/secret manager + escaneo de secretos en CI (enlaza con gestión de secretos) |
| La misma clave para todo y para siempre | Nunca se planificó la rotación | KEK por entorno y dominio; rotación automática; DEK por objeto |
| Clave en una variable de entorno de un contenedor world-readable | Se copió el patrón de un tutorial | Inyección en tiempo de ejecución desde el KMS; nunca en la imagen |
| Backups de la base de datos sin cifrar (o con la clave al lado) | El cifrado se pensó solo para producción | Cifrar los backups con una KEK distinta, guardada aparte |
| Sin inventario de dónde se usa cada clave | Creció orgánicamente | Registrar clave -> propósito -> sistemas -> responsable -> fecha de rotación |
| Rotar sin versionar | Se sustituye la clave y se rompe el descifrado de lo antiguo | Etiquetar cada dato con la versión de clave; conservar versiones retiradas para lectura |
Referencias
NIST SP 800-57 (recomendaciones de gestión de claves) y SP 800-130 (marco para sistemas de gestión de claves) · FIPS 140-3 — requisitos de seguridad para módulos criptográficos · Documentación de AWS KMS, Google Cloud KMS y Azure Key Vault sobre envelope encryption y rotación · OWASP Key Management Cheat Sheet · Nuestros artículos sobre gestión de secretos, cifrado simétrico y asimétrico, firmas digitales y AWS IAM
Conclusión
Gestionar claves es tratarlas como lo que son: el activo del que depende todo lo demás. Eso significa generarlas con buena aleatoriedad, no incrustarlas nunca en el código, cifrar los datos con claves de datos desechables y reservar la clave maestra para proteger esas —el patrón de sobre—, y tener desde el principio un plan de rotación versionada.
El HSM y el KMS son las herramientas que hacen cumplir la regla de oro: que el material de la clave no salga en claro de un sitio controlado y que cada uso quede registrado. Para la inmensa mayoría de organizaciones, el KMS gestionado de su proveedor de nube con envelope encryption y rotación automática es suficiente; el HSM dedicado entra cuando lo exige una norma, un contrato o la criticidad de una PKI raíz o una clave de firma de código.
unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)