Hold Your Own Key: tus datos en AWS y Azure, tus claves en Europa

Hold Your Own Key: la nube pregunta, tú decides

Tanto AWS como Microsoft publican una forma de mantener la clave fuera de su propia infraestructura.

AWS KMS External Key Store (XKS) te permite crear claves de KMS cuyo material vive en un gestor de claves externo. Azure Key Vault Managed HSM External Key Management (EKM) hace lo mismo para los servicios de Azure que admiten claves gestionadas por el cliente.

La idea es sencilla. Tus datos se quedan donde están: en S3, EBS, Azure Storage o Azure SQL. Pero cada vez que la nube necesita cifrar o descifrar una clave de datos (en AWS), o envolverla o desenvolverla (en Azure), tiene que llamar a tu gestor de claves y pedir permiso. La clave en sí nunca entra en el proveedor cloud.

Eso te da algo que el cifrado por defecto no puede darte: un interruptor fuera de la nube. Si cortas el acceso, la nube ya no puede abrir sus claves de datos y tus datos en esa nube se vuelven ilegibles. No se borran ni se mueven. Quedan bajo llave hasta que tú decidas lo contrario.

Qué aporta QuantumAPI

QuantumAPI implementa las especificaciones públicas de proxy de AWS XKS y Azure EKM. Creas una clave externa en QuantumAPI, conectas a ella tu almacén de claves de AWS o tu Managed HSM y, a partir de ahí, AWS o Azure le preguntan a QuantumAPI cada vez que necesitan esa clave. Esto es lo que tienes a nuestro lado de la línea:

• Una clave custodiada en la UE. El material de la clave lo genera y lo guarda QuantumAPI, una empresa europea, en infraestructura de la UE. AWS y Microsoft nunca lo reciben.
• Claves nacidas de aleatoriedad cuántica. Las claves externas se generan con entropía cuántica de un servicio QRNG (ahora mismo, el ANU QRNG de la Australian National University). Si la fuente cuántica no está disponible, entra un generador criptográfico estándar (CSPRNG). En los dos casos, la fuente que se ha usado de verdad queda registrada en cada clave, así que un fallback nunca se esconde.
• Protección post-cuántica en reposo. Tu clave se guarda cifrada bajo una cadena de claves protegida con ML-KEM-768 (FIPS 203), el estándar post-cuántico del NIST.
• Cada llamada, auditada. Cada operación aparece en tu registro de actividad de claves: quién la pidió (el principal de IAM en AWS, el pool de Managed HSM en Azure), a través de qué servicio, el resultado y la latencia.
• Un interruptor de emergencia. Desactiva una clave o desconecta un almacén desde el portal y QuantumAPI empieza a rechazar las peticiones de esa nube en ese mismo momento.
• Precio por uso. Cada operación de clave correcta que hace la nube cuenta como una llamada a la API de tu plan. Las claves externas y los almacenes son gratuitos e ilimitados, como cualquier otra clave en QuantumAPI.

En AWS hay un extra. KMS usa doble cifrado: cifra primero dentro de AWS y después con tu clave externa. Ni AWS ni QuantumAPI pueden descifrar tus datos por separado. El protocolo de Azure funciona de otra manera (QuantumAPI envuelve directamente la clave de datos), así que no hacemos esa afirmación para Azure.

Lo que no hace (y preferimos decirlo nosotros primero)

La seguridad post-cuántica es toda nuestra marca, así que sería tentador venderlo como «AWS post-cuántico». No lo es, y no lo vamos a vender así.

Los protocolos de la nube son clásicos. El tráfico entre AWS o Azure y nuestro proxy usa lo que definen los proveedores: TLS, AES-256 y, en Azure, certificados de cliente basados en RSA. Ninguno negocia ML-KEM hoy. AES-256 aguanta bien frente a los ordenadores cuánticos; el intercambio de claves clásico de TLS, no, y esa parte la controla el cliente del proveedor cloud, no nosotros. Tu bucket de S3 o tu cuenta de Azure Storage no pasan a ser cuántico-seguros por esta funcionalidad. Lo que es post-cuántico es cómo guardamos nosotros tu clave.

No es un HSM. La versión 1 es un gestor de claves por software, sin certificación FIPS 140-3. Si tu política exige un HSM certificado, todavía no es el producto para ti.

El interruptor corta las peticiones nuevas, no las claves en caché. Algunos servicios cloud guardan las claves de datos en memoria durante un tiempo (S3 Bucket Keys, discos montados, Azure Storage). Esos siguen funcionando hasta que el servicio vuelve a preguntar. La revocación llega a todo dentro de ese tiempo de caché, no en el mismo segundo.

Es una preview. Si la nube no llega a QuantumAPI, no puede usar tu clave y los datos que dependen de ella quedan inaccesibles. De eso va precisamente HYOK, y por eso te pedimos que empieces con cargas de prueba o no críticas. No somos partner certificado de AWS ni de Microsoft, y Google Cloud no está soportado.

Cómo funciona

Para la nube, QuantumAPI es simplemente un gestor de claves externo. Una petición típica va así:

1. Una aplicación lee un fichero de S3, o arranca una base de datos en Azure SQL. El servicio cloud necesita su clave de datos.
2. AWS KMS o Azure Managed HSM envía una petición firmada al proxy de QuantumAPI: «descifra esto con la clave X» (AWS) o «desenvuelve esto con la clave X» (Azure).
3. QuantumAPI comprueba quién llama (la firma de AWS o el certificado de cliente de Azure), que la clave pertenece a esa conexión y que ni la clave ni la conexión están desactivadas.
4. Si todo cuadra, QuantumAPI hace la operación AES-256 con tu clave y devuelve el resultado. La llamada queda en tu registro de actividad de claves y cuenta como una llamada a la API.
5. Si has usado el interruptor, QuantumAPI se niega y la nube no puede abrir la clave de datos.

Para quién es y cómo probarlo

Los almacenes de claves externos están pensados para empresas europeas reguladas que trabajan sobre AWS o Azure y tienen que demostrar quién controla el acceso a sus datos. Piensa en DORA y sus reglas sobre riesgo de proveedores TIC para entidades financieras, en NIS2 para entidades esenciales e importantes, o en el debate sobre transferencias internacionales del RGPD que abrió Schrems II. HYOK no te hace cumplir la normativa por sí solo, pero te da una respuesta concreta y auditable a la pregunta «¿puede nuestro proveedor cloud leer nuestros datos sin nosotros?».

Un ejemplo hipotético: una aseguradora europea guarda pólizas en S3, en Fráncfort. Su equipo de riesgos quiere sacar las claves de las manos del proveedor y tener constancia de cada acceso. Con un almacén de claves externo, el bucket usa una clave de KMS respaldada por QuantumAPI. Cada descifrado aparece con el rol de IAM y el servicio que lo pidió y, si algún día la aseguradora necesita cortar el acceso, una sola acción en QuantumAPI detiene los descifrados nuevos.

¿Quieres el control completo? Instálalo en tu propio centro de datos. Si el motivo de fondo de HYOK es que nadie más controle tus claves, la configuración más sólida no es nuestro SaaS: es QuantumAPI instalado on-premises, en tu propio centro de datos. El gestor de claves, su base de datos, la generación de aleatoriedad (la fuente cuántica o su fallback), el registro de auditoría y el interruptor quedan bajo tu control, y ningún tercero, tampoco nosotros, está en medio. El soporte de almacenes de claves externos llegará a la edición on-premises; todavía no está disponible. La preview SaaS es la forma más rápida de probar la idea hoy. On-premises mantiene el mismo modelo de precio por uso: llamadas a la API y almacenamiento, nunca por usuario ni por clave.

El precio, dicho claro: si lo operas tú, la disponibilidad también es tuya. Si tu proxy se cae, la nube no puede descifrar tus datos. Eso funciona en los dos sentidos, y es el precio del control total.

Lo que hemos medido. El 24 de octubre de 2026 probamos el camino de Azure de punta a punta contra un Azure Key Vault Managed HSM real en North Europe. El ekm-connection check de Azure identificó a QuantumAPI, los ciclos de wrap y unwrap funcionaron, al pulsar Desconectar en QuantumAPI el siguiente unwrap de Azure falló al instante con «disconnected in QuantumAPI» (el Managed HSM no guarda en caché los unwrap) y al reconectar volvió el acceso. Dentro de QuantumAPI, cada wrap o unwrap tardó entre 2 y 14 ms aproximadamente con la clave ya en caché, y unos 100 ms en la primera llamada, que es la que carga la clave. Es solo el tiempo de proceso en nuestro lado: el trayecto de red hasta la nube va aparte, y el total tiene que caber en el presupuesto de 250 ms de la nube; por eso el servicio tiene que estar cerca de las regiones cloud a las que da servicio. El proxy de AWS XKS está implementado, pero todavía no lo hemos probado en real contra AWS; publicaremos esos resultados cuando los tengamos.

Los almacenes de claves externos están disponibles como preview en QuantumAPI 0.25.0. La configuración paso a paso para AWS y Azure está en docs.quantumapi.eu. Si quieres hacer un piloto o comentar tu caso, escríbenos: preferimos conocer tus requisitos ahora, mientras la funcionalidad todavía está tomando forma.