Gestión de Claves Criptográficas a Escala: HSM frente a Cloud KMS
Guía práctica sobre gestión de claves criptográficas para plataformas bancarias y de activos digitales en 2026: HSM frente a Cloud KMS, cifrado en sobre, ciclo de vida de claves, BYOK/HYOK y cumplimiento de PCI DSS y MiCA.
Por qué la gestión de claves es fundamental para la banca y las plataformas cripto
La criptografía protege los datos de los clientes, los registros de transacciones, los números de tarjeta y la custodia de activos digitales. Sin embargo, la criptografía solo es tan sólida como las claves que la sustentan. Una clave de firma comprometida permite falsificar transacciones. Una clave de cifrado filtrada expone todos los registros que protegía. Una clave raíz perdida puede hacer que los datos cifrados sean irrecuperables de forma permanente.
Para bancos y plataformas fintech reguladas, la gestión de claves no es una cuestión de seguridad abstracta - es un requisito de cumplimiento. PCI DSS exige procedimientos documentados para el ciclo de vida de las claves a cualquier organización que maneje datos de titulares de tarjeta. MiCA y la normativa nacional de custodia de criptoactivos requieren que las claves privadas de activos digitales estén protegidas en hardware resistente a manipulaciones o un equivalente aprobado. En España, la CNMV supervisa los prestadores de servicios sobre criptoactivos y espera que los controles de custodia de claves se alineen con las directrices de la EBA bajo MiCA.
Confidencialidad de datos
Las claves cifran datos de cuentas, registros KYC y credenciales de pago en reposo y en tránsito. Perder una clave significa datos perdidos o expuestos.
Integridad transaccional
Las claves de firma autentican mensajes de pago, llamadas API y transacciones blockchain. Una clave comprometida compromete la transacción.
Evidencia regulatoria
Auditores y reguladores como el Banco de España y la CNMV esperan políticas documentadas de claves, registros de rotación y controles de acceso.
El reto principal no es generar una clave fuerte - eso está resuelto. El reto está en gestionar las claves a escala: rotarlas sin interrupciones, otorgar acceso solo a los procesos autorizados, detectar usos indebidos y retirar las claves de forma segura al final de su vida útil.
Hablemos de tu proyecto y veamos cómo podemos lanzar tu Producto bancario digital Juntos
Solicita una demoFundamentos del HSM - qué hace un módulo de seguridad hardware
Un Hardware Security Module (HSM) es un dispositivo físico dedicado que realiza operaciones criptográficas dentro de un perímetro resistente a manipulaciones. El material de clave nunca sale del HSM en texto claro. Si se intenta abrir el dispositivo, se borra a sí mismo. Ante un corte de energía inesperado, también se borra. La clave privada solo existe dentro del chip.
La certificación de referencia para los HSM es FIPS 140-2 / FIPS 140-3, emitida por el Instituto Nacional de Estándares y Tecnología (NIST) de EE. UU. FIPS 140-2 Nivel 3 - el estándar que esperan la mayoría de los reguladores bancarios y los esquemas de tarjetas - exige evidencia física de manipulación, autenticación basada en identidad y capacidad de detectar y responder a sondas físicas.
| Nivel FIPS 140 | Requisitos físicos | Uso típico |
|---|---|---|
| Nivel 1 | Sin requisitos físicos; las implementaciones software califican | Aplicaciones de baja sensibilidad |
| Nivel 2 | Revestimientos o sellos evidentes de manipulación; autenticación por roles | Cifrado empresarial general |
| Nivel 3 | Detección y respuesta a manipulaciones; autenticación por identidad; resistencia a sondas físicas | HSM de pagos, protección PIN de tarjetas, custodia cripto |
| Nivel 4 | Respuesta a ataques ambientales (tensión, temperatura, radiación) | Entornos de máxima seguridad |
Los principales fabricantes de HSM son Thales (nShield, Luna), Utimaco y IBM. En un despliegue típico de banco de pagos, los HSM se ubican en el rack del centro de datos, conectados a los servidores de procesamiento de pagos a través de un segmento de red dedicado. La verificación del PIN de la tarjeta, la generación de claves de tarjeta y la firma de transacciones PCI HSM se realizan dentro del dispositivo.
La contrapartida es el peso operativo: planificación de capacidad, instalación física, gestión del ciclo de vida del firmware y conocimientos especializados en operaciones criptográficas. Las configuraciones de alta disponibilidad requieren un diseño cuidadoso y la recuperación ante desastres implica procedimientos de copia de seguridad de claves sincronizadas, habitualmente una ceremonia con varios custodios y tarjetas inteligentes.
Cloud KMS - capacidades y comparativa
Los servicios de Cloud KMS ofrecen gestión de claves criptográficas a través de una API, con el proveedor gestionando el hardware subyacente. Las tres opciones principales son AWS KMS, Google Cloud KMS y Azure Key Vault. Todos están respaldados por HSM validados FIPS 140-2 Nivel 3 en los centros de datos del proveedor, pero el cliente no gestiona esos HSM directamente.
| Característica | AWS KMS | GCP Cloud KMS | Azure Key Vault |
|---|---|---|---|
| Tipos de clave | Simétrica (AES-256), asimétrica (RSA, ECC), HMAC | Simétrica, asimétrica, externa (Cloud EKM) | Simétrica, asimétrica, secretos, certificados |
| Opción HSM dedicado | AWS CloudHSM | Cloud HSM | Managed HSM |
| Soporte BYOK | Sí (importar material de clave) | Sí (importar + Cloud EKM) | Sí (BYOK + HYOK con Managed HSM) |
| Rotación automática | Anual por defecto; configurable | Período de rotación configurable | Rotación basada en políticas |
La ventaja operativa es significativa: sin hardware que gestionar, sin capacidad que prever, sin firmware que parchear. Para equipos fintech cloud-native sin personal dedicado a operaciones criptográficas, Cloud KMS reduce considerablemente la barrera para hacer bien la gestión de claves. En cuanto a residencia de datos, AWS ha establecido una región en España (eu-south-1 en Madrid) que permite mantener las claves y los datos en territorio español, lo que facilita el cumplimiento con las expectativas del Banco de España y la AEPD.
HSM frente a Cloud KMS - matriz de decisión
Ninguna opción es universalmente superior. La elección correcta depende de las obligaciones regulatorias, la madurez operativa, el volumen y la sensibilidad de la carga de trabajo.
| Factor de decisión | HSM on-premises | Cloud KMS (con HSM dedicado opcional) |
|---|---|---|
| Custodia física de la clave | Usted posee el hardware y el material de clave | El proveedor posee el hardware; BYOK/HYOK para control de importación |
| Mandato regulatorio | Cumple las reglas más estrictas de custodia cripto (MiCA/CNMV, Banco de España) | Cumple la mayoría de requisitos; algunas jurisdicciones exigen custodia on-premises |
| Complejidad operativa | Alta - firmware, clustering, ceremonia DR, planificación de capacidad | Baja - API, auto-escalado, disponibilidad gestionada |
| Modelo de coste | Alto capex por dispositivo; opex predecible | Pago por uso (típicamente 0,03-1 $ por 10.000 llamadas API) |
| Mejor para | Procesamiento PIN de tarjetas, custodia de criptoactivos, requisitos de soberanía | Fintech cloud-native, plataformas SaaS, startups en crecimiento rápido |
Un patrón habitual para fintech reguladas en España: Cloud KMS para el cifrado en la capa de aplicación (datos en reposo, firma API, gestión de secretos) y un HSM dedicado o Cloud-HSM para las operaciones más sensibles (generación de claves de tarjeta, claves privadas de activos cripto, autenticación de mensajes de pago). Esto distribuye la carga operativa manteniendo el material más crítico en hardware.
Cifrado en sobre y ciclo de vida de las claves
El cifrado en sobre (envelope encryption) es el patrón estándar para cifrar grandes volúmenes de datos sin enviar todo a través de la API del KMS. En lugar de cifrar cada registro directamente con la clave maestra, se genera localmente una Clave de Cifrado de Datos (DEK) de corta duración, se cifran los datos con el DEK y luego se cifra el DEK con una Clave de Cifrado de Claves (KEK) almacenada en el KMS o HSM. El DEK cifrado viaja junto al texto cifrado. Para descifrar, se llama al KMS para desempaquetar el DEK y luego se descifra localmente.
Clave de datos (DEK)
Única por objeto o registro. Generada localmente, usada una vez o por un periodo corto, luego descartada.
Clave de cifrado de claves (KEK)
Reside en el KMS o HSM. Cifra los DEK pero nunca toca datos en bruto. Se rota periódicamente.
KEK raíz
Gobierna toda la jerarquía de claves. Almacenado en hardware HSM. Cambiarla requiere volver a cifrar todos los DEK empaquetados.
El ciclo de vida de las claves abarca cuatro fases: generación (creación del material de clave en un entorno controlado y auditado); uso activo (la clave está operativa y el acceso se registra); rotación (la nueva versión toma el relevo; la versión anterior solo descifra datos heredados); y destrucción (el material de clave se elimina de todos los almacenamientos, los registros confirman la eliminación). El Requisito 3 de PCI DSS exige que todo este ciclo de vida esté documentado en una política formal de gestión de claves.
BYOK y HYOK - control sobre quién accede a las claves
La cuestión de soberanía en la gestión de claves en la nube se reduce a dos modelos:
BYOK (Bring Your Own Key) significa que usted genera su material de clave maestra en su propio HSM (o entorno controlado localmente) y luego lo importa al KMS del proveedor cloud. El proveedor almacena y usa la clave en su nombre, pero usted la creó y conserva el original. Si necesita revocar la capacidad del proveedor para usar la clave, elimina la importación y vuelve a cifrar con una nueva clave. Esto satisface muchas interpretaciones regulatorias de "propiedad de la clave" manteniendo la operabilidad del Cloud KMS.
HYOK (Hold Your Own Key) va más lejos: el material de clave maestra nunca entra en la infraestructura del proveedor cloud. Las solicitudes de descifrado se enrutan a su HSM on-premises o a un servicio de claves de terceros. El sistema del proveedor cloud solo cifra y descifra datos cuando su HSM aprueba la operación. En GCP, esto se llama External Key Management (EKM); Azure ofrece una solución equivalente a través de Managed HSM con BYOK y políticas de acceso a claves controladas por el cliente.
Para la mayoría de los fintech cloud-native, BYOK es suficiente para satisfacer a los reguladores manteniendo la operabilidad. HYOK merece la latencia adicional y la complejidad cuando las regulaciones exigen específicamente que el proveedor cloud no pueda acceder al material de clave bajo ninguna circunstancia, como ocurre con algunas normas nacionales de custodia de criptoactivos bajo MiCA y las expectativas de la CNMV en España.
Cumplimiento normativo: PCI DSS, MiCA y custodia cripto en España y LATAM
La gestión de claves se sitúa en la intersección de varios marcos regulatorios, y los requisitos se solapan pero no son idénticos.
PCI DSS v4.0 (Requisito 3) exige: criptografía fuerte para los datos almacenados de titulares de tarjeta; procedimientos documentados de gestión de claves que cubran todo el ciclo de vida; conocimiento dividido y control dual para componentes de claves en texto claro; rotación de claves al menos anualmente o cuando un custodio de claves abandone la organización. El procesamiento de transacciones con tarjeta presente requiere HSM FIPS 140-2 Nivel 3 o aprobados por PCI.
MiCA, en vigor en la UE desde 2024-2025, exige a los Proveedores de Servicios sobre Criptoactivos (CASP) implementar políticas de custodia de claves privadas. Las directrices de la EBA bajo MiCA especifican que las carteras de custodia deben usar protección de claves respaldada por hardware y que el acceso a las claves debe requerir autorización multiparte (MPC o multi-sig). En España, la CNMV registra y supervisa a los CASP, y espera que los controles de custodia cumplan estos estándares técnicos. En LATAM, países como Brasil (a través del Banco Central) y México (CNBV/CONDUSEF) aplican marcos similares con variaciones locales.
| Regulación | Requisito de gestión de claves | Enfoque recomendado |
|---|---|---|
| PCI DSS v4.0 | Documentación de ciclo de vida, control dual, rotación anual, HSM para operaciones de tarjeta | HSM compatible con PCI para claves de pago; Cloud KMS para cifrado en capa de app |
| MiCA / CNMV | Protección de claves por hardware, MPC o multi-sig para carteras de custodia | HSM o HYOK/EKM; bibliotecas de cartera MPC en hardware |
| DORA | Marco de riesgo TIC cubre infraestructura criptográfica; recuperación probada | Procedimientos DR de copia de seguridad; ceremonia de claves documentada; failover probado |
| RGPD / LOPDGDD | El cifrado es una salvaguarda reconocida; la eliminación de claves equivale a borrado efectivo | Cifrado en sobre con eliminación de claves como mecanismo de borrado |
La plataforma de Crassula está construida de forma nativa en la nube sobre Google Cloud, lo que significa que Cloud KMS y Cloud HSM son la capa nativa de gestión de claves. Para clientes que necesiten protección de claves de pago a nivel PCI o custodia cripto conforme con MiCA/CNMV, la arquitectura de Crassula soporta integración de HSM dedicado y flujos de trabajo de importación de claves BYOK.
Preguntas frecuentes
La gestión de claves criptográficas es el conjunto de políticas y controles técnicos que rigen cómo se crean, almacenan, distribuyen, usan, rotan y destruyen las claves de cifrado. Las claves protegen los datos en reposo, en tránsito y las firmas digitales. Para plataformas financieras reguladas, la gestión de claves también implica producir registros de auditoría que demuestren el cumplimiento de PCI DSS, MiCA y las normativas del Banco de España o la CNMV.
Depende de lo que proteja y de sus obligaciones regulatorias. Cloud KMS (AWS KMS, GCP KMS, Azure Key Vault) es la opción correcta por defecto para la mayoría de los fintech cloud-native: basado en API, auto-escalable y respaldado por hardware FIPS 140-2 Nivel 3 que opera el proveedor. Un HSM dedicado tiene sentido cuando necesita custodia física del material de clave - típicamente para procesamiento de PIN de tarjetas (PCI exige un HSM aprobado), custodia de claves privadas de criptoactivos (MiCA y la CNMV exigen protección por hardware) o despliegues soberanos donde el proveedor cloud no puede acceder al material de clave. Muchas plataformas usan ambos: Cloud KMS para el cifrado en la capa de aplicación y un HSM dedicado para las operaciones más sensibles.
BYOK (Bring Your Own Key) significa que usted genera su material de clave maestra en su propio HSM o entorno controlado y lo importa al KMS del proveedor cloud. El proveedor opera la clave en su nombre, pero usted la creó y puede revocarla eliminando la importación. HYOK (Hold Your Own Key) va más lejos: el material de clave nunca entra en la infraestructura del proveedor cloud. Cada solicitud de descifrado se enruta a su HSM on-premises para su aprobación. En GCP, esto se llama External Key Management (EKM). HYOK añade latencia y complejidad operativa, pero garantiza que el proveedor no pueda acceder a su texto en claro bajo ninguna circunstancia, lo que puede ser relevante para cumplir las exigencias más estrictas de la CNMV o del Banco de España en materia de soberanía de datos.
Para pagos con tarjeta: PCI DSS v4.0 Requisito 3 exige documentación del ciclo de vida, control dual, rotación anual y HSM FIPS 140-2 Nivel 3 para operaciones de tarjeta. Para custodia de criptoactivos: MiCA (UE) y la normativa nacional exigen protección de claves por hardware y autorización multiparte. En España, la CNMV supervisa el cumplimiento de los CASP. Para resiliencia operativa: DORA exige que la infraestructura criptográfica esté cubierta por la gestión de riesgo TIC. Para protección de datos: el RGPD y la LOPDGDD reconocen el cifrado como salvaguarda, y la eliminación de claves puede servir como mecanismo de borrado técnico.
En el contexto de custodia de criptoactivos, la clave privada ES el activo. Quien controla la clave privada controla los fondos. La gestión de claves significa por tanto: generar claves dentro de hardware certificado (HSM o enclave seguro), no exponer nunca la clave privada en texto claro fuera de ese perímetro, distribuir la autoridad de firma entre varias partes (multi-firma o computación multiparte) y mantener un procedimiento de recuperación ante desastres probado para la copia de seguridad de claves. MiCA y las directrices de la EBA exigen a los CASP que documentar y auditar estos controles. La CNMV en España y los reguladores equivalentes en LATAM esperan estos estándares. El estándar del sector para custodia institucional es HSM FIPS 140-2 Nivel 3 combinado con un esquema MPC o multi-sig para que ninguna persona o máquina pueda firmar una transacción de forma unilateral.
Otras guías
Crea un banco digital en cuestión de días
Solicita una demo