Mejores prácticas de gestión de claves de cifrado en 2026
Domina la gestión de claves de cifrado con prácticas probadas para la generación, almacenamiento, rotación y ciclo de vida seguro de las claves en 2026.
Gestionar claves de cifrado en 2026 exige generar claves con un CSPRNG (no /dev/urandom en VMs con baja entropía — usa getrandom() o BCryptGenRandom), almacenarlas en hardware (AWS KMS, YubiHSM 2, Thales Luna, Secure Enclave), rotarlas con un calendario acorde a la exposición al riesgo (90 días para claves de cifrado activas, anualmente para KEKs) y destruirlas mediante borrado criptográfico o destrucción física. NIST SP 800-57 Parte 1 Rev 5 define el ciclo de vida; FIPS 140-3 certifica los módulos; PCI DSS 4.0 Requisito 3.6 audita el proceso. Domina estos aspectos y los algoritmos de cifrado subyacentes (AES-256-GCM, X25519) casi nunca serán el problema.
Generación de claves fiables
La generación de claves es el punto de fallo silencioso de la criptografía. El CVE de OpenSSL en Debian (2006-2008) hizo que cada clave SSH generada en los sistemas afectados fuera predecible. Más recientemente, Fortinet distribuyó routers en 2021 con claves derivadas de fuentes de baja entropía durante el arranque. La generación segura usa el CSPRNG del sistema operativo: getrandom() en Linux 3.17+, BCryptGenRandom en Windows, SecRandomCopyBytes en macOS/iOS; o un RNG hardware en un HSM. La Web Crypto API usa crypto.getRandomValues(), que tira del CSPRNG del SO. Nunca implementes tu propio RNG, nunca uses time() o PID como semilla, y verifica al arrancar una VM que el pool está sembrado (comprueba /proc/sys/kernel/random/entropy_avail > 256).
Estructura jerárquica de claves: KEKs, DEKs y claves de sesión
Los sistemas reales utilizan capas. Una Data Encryption Key (DEK) cifra los datos con AES-256-GCM. Una Key Encryption Key (KEK) cifra las DEKs y se almacena en un HSM. Una KEK raíz cifra las KEKs en hardware resistente a manipulaciones. Rotar la DEK recifra los datos; rotar la KEK reenvuelve las DEKs (operación rápida); rotar la raíz es una operación mayor. Este patrón de sobre permite rotaciones frecuentes en las capas que lo admiten sin descifrar petabytes. AWS KMS, Google Cloud KMS y HashiCorp Vault implementan este modelo. En servicios de transferencia de archivos, la clave AES por transferencia es una DEK; la KEK derivada de contraseña (vía PBKDF2 o Argon2id) la envuelve.
Almacenamiento: HSMs, KMS y sus diferencias reales
Un Hardware Security Module (HSM) es un dispositivo resistente a manipulaciones que genera, almacena y usa claves sin exportarlas jamás. Los dispositivos FIPS 140-3 Nivel 3 (Thales Luna 7, AWS CloudHSM, YubiHSM 2) detectan manipulación física y realizan zeroización. Un Key Management Service (AWS KMS, Google Cloud KMS, Azure Key Vault) es software ejecutado sobre HSMs, accesible por API. Para la mayoría de aplicaciones, un KMS es suficiente: pagas 1 $/mes por clave, llamas a Encrypt/Decrypt sobre HTTPS y AWS gestiona el HSM. El HSM directo se necesita cuando los reguladores lo exigen (PCI DSS 4.0 Requisito 3.6.1.1 para emisión de tarjetas) o cuando no puedes confiar en la jurisdicción legal del proveedor cloud.
Calendarios de rotación acordes al riesgo
NIST SP 800-57 define los criptoperíodos: el tiempo que una clave permanece activa. Para claves simétricas que cifran datos nuevos, un máximo de 1-2 años. Para claves que solo descifran datos existentes, 3-5 años. Para KEKs raíz, 5-10 años. PCI DSS Requisito 3.7.4 exige definir el criptoperíodo. En la práctica, automatiza la rotación: AWS KMS ofrece rotación automática anual; Google KMS es configurable. En servicios de transferencia donde cada subida obtiene una clave aleatoria nueva, la rotación no aplica a las claves de datos (son de un solo uso), pero sí a los certificados TLS (90 días vía Let's Encrypt), a las claves de firma para logs de auditoría (anualmente) y a la clave maestra que envuelve los secretos por usuario.
Destrucción y borrado criptográfico
Cuando expira el criptoperíodo de una clave o hay que purgar datos por el artículo 17 del RGPD, destruye la clave. Destrucción física (destructora de tarjetas inteligentes) para tokens de respaldo offline. Borrado criptográfico para claves en la nube: cifra la clave con una wrapping key y luego destruye esa wrapping key — todos los datos cifrados bajo la primera clave se convierten en texto cifrado que nadie puede descifrar. Así es como los proveedores cloud cumplen peticiones de borrado a escala de terabytes sin sanear físicamente cada sector de disco. Documenta la destrucción en un log de auditoría con marca temporal, ID de clave (no el material) y el método empleado. NIST SP 800-88 Rev 1 cubre el saneado.
Control de acceso y separación de funciones
Ninguna persona debería poder extraer una clave de producción por sí sola. Implementa quórum m-de-n para roles de administrador de HSM: 2 de 5 responsables para exportar una clave raíz, 1 de 3 para rotar una KEK, 0 para operaciones rutinarias con DEKs. Los grants de AWS KMS permiten delegar capacidades específicas (solo cifrar, solo descifrar) mediante políticas IAM. El Shamir Secret Sharing de HashiCorp Vault divide la clave de unseal entre depositarios. Registra cada uso de clave con la identidad del llamador, la operación y el recurso. PCI DSS 3.6.2 y SOC 2 CC6.1 auditan exactamente esto.
Cifrado de sobre y BYOK
Bring Your Own Key (BYOK) permite a los clientes subir su propia KEK raíz a un KMS cloud. El proveedor envuelve las claves de datos del inquilino bajo la KEK del cliente, de modo que la revocación del cliente hace irrecuperables los datos sin intervención del proveedor. AWS KMS Import Key, Google Cloud EKM y Azure Key Vault BYOK resuelven este problema. Para servicios de transferencia que atienden a clientes regulados (sanidad, finanzas), BYOK satisface el requisito de "el cliente controla las claves" incluso en infraestructura compartida. El HSM del cliente en su propio datacenter genera la clave; el proveedor nunca ve el material de clave en texto claro.
Copia de seguridad y recuperación del material de clave
Perder claves equivale a perder datos. Haz copias de seguridad de las claves raíz mediante splits de Shamir Secret Sharing en manos de depositarios geográficamente separados. AWS KMS permite exportar material de clave solo para CMKs creadas con BYOK. YubiHSM 2 admite copia de la wrap key. Documenta el procedimiento de recuperación, pruébalo anualmente (ejecútalo de verdad, no solo léelo) y mantén al menos dos depositarios activos en todo momento — un bus factor de uno es inaceptable. Para claves menos críticas, copias de seguridad offline cifradas en medios air-gapped (cinta LTO, USB cifrado en caja fuerte) en dos o más ubicaciones. El procedimiento de recuperación debe estar en el runbook de recuperación ante desastres.
El caso especial del cifrado en el cliente
Para servicios como HexaTransfer donde los usuarios cifran en el navegador, la gestión de claves tradicional no aplica — no hay clave en el servidor que rotar porque el servidor nunca ve las claves. El navegador deriva una clave de la contraseña del usuario, la usa una vez y la descarta. La responsabilidad pasa a la educación del usuario: elige contraseñas robustas, no las reutilices, usa un gestor de contraseñas. La responsabilidad del servicio es usar una KDF robusta (Argon2id con m=64 MB, t=3, p=1, o PBKDF2 con más de 600 000 iteraciones), generar salts aleatorios correctamente y borrar el material de clave de la memoria tras su uso (mediante handles opacos de crypto.subtle o borrados explícitos de memoria WebAssembly).
Monitorización y respuesta a incidentes
El compromiso de una clave es el peor escenario posible. Monitoriza las operaciones de KMS en busca de anomalías: una clave API que normalmente realiza 100 llamadas Decrypt/hora y de repente hace 10 000 es señal de exfiltración. Alerta sobre errores de KMS (autenticación fallida, clave no encontrada, cuota superada). Vincula las alertas a un runbook que incluya rotación de claves, invalidación de credenciales y captura forense. Ten un plan de recuperación ante compromiso de clave: ¿en cuánto tiempo puedes rotar la raíz? ¿Cómo recifras terabytes de datos? Prueba el plan anualmente. Un KMS bien gestionado con un compromiso no detectado es peor que uno visiblemente roto.
Pruébalo en hexatransfer.com — gratis, sin cuenta, hasta 10 GB.
Envía archivos grandes de forma segura con cifrado de extremo a extremo
Transfiere archivos de hasta 10 GB gratis con cifrado de extremo a extremo. Sin necesidad de cuenta. Tus archivos se cifran en tu navegador antes de subirlos: nadie más puede leerlos.
Enviar un archivo