Impacto crítico de los HSM y KMS en la seguridad de los datos en la nube.

Cuando las organizaciones trasladan cargas de trabajo sensibles a la nube, el cifrado suele considerarse el problema más complejo. En realidad, el cifrado es la parte fácil: todos los principales proveedores de servicios en la nube cifran los datos en reposo y en tránsito por defecto, y los algoritmos empleados son robustos y bien conocidos. La pregunta verdaderamente difícil, la que determina si sus datos están realmente bajo su control, es mucho más sencilla de plantear y mucho más difícil de responder: ¿quién controla las claves, en qué hardware y qué sucede cuando ese hardware falla?

Publicado: mayo de 2026. Actualizado: agosto de 2026. Revisado por el equipo de Servicios HSM de Encryption Consulting.

El cifrado transforma los datos legibles en texto cifrado que carece de sentido sin la clave correspondiente. En cualquier sistema cifrado, la protección de los datos depende de la clave que los descifra. Quien controla la clave controla los datos. Si un atacante obtiene la clave, el cifrado no ofrece ninguna protección. Si un tercero, como un proveedor de servicios en la nube o un gobierno con autoridad legal sobre dicho proveedor, puede obtener acceso a la clave, podrá acceder a los datos, independientemente de la robustez del algoritmo de cifrado o de la ubicación física de los datos cifrados.

La clave de esta respuesta reside en dos tecnologías: los Módulos de Seguridad de Hardware (HSM) y los Servicios de Gestión de Claves (KMS). Este artículo explica la función de cada uno, sus diferencias en cuanto a la validación FIPS y el despliegue, cuándo elegir un HSM dedicado frente a un KMS nativo de la nube o un KMS en la nube con soporte para HSM, y las realidades operativas, los protocolos clave, la alta disponibilidad, los requisitos de integración y los modos de fallo que determinan si una arquitectura de seguridad de datos en la nube resiste la presión.

¿Qué son los HSM y los KMS en la nube, y en qué se diferencian?

Estas dos tecnologías cumplen funciones principales distintas. Un HSM proporciona protección de claves mediante hardware. Un KMS gestiona el ciclo de vida de las claves de forma escalable. Comprender la función de cada una permite saber cuándo usar una, la otra o ambas.

Módulo de seguridad de hardware (HSM)

Un módulo de seguridad de hardware (HSM) es un dispositivo especializado y a prueba de manipulaciones, diseñado para generar, almacenar y utilizar claves criptográficas dentro de un entorno protegido física y lógicamente. De esta forma, la clave privada nunca se encuentra en texto plano fuera de dicho entorno. Cuando se realiza una operación criptográfica, como firmar datos o descifrar un valor, esta se lleva a cabo dentro del HSM: los datos o su hash se introducen, el HSM realiza la operación utilizando la clave que contiene y solo se obtiene el resultado. Incluso si todos los sistemas circundantes se ven comprometidos, la clave permanece protegida dentro del módulo.

La contrapartida de estas garantías es la complejidad operativa y el coste. Las instancias dedicadas de HSM en la nube suelen costar más de 1,000 dólares al mes por HSM, y la gestión de la infraestructura de HSM, incluyendo la redundancia, las copias de seguridad y el riesgo de que la pérdida del quórum administrativo pueda provocar un bloqueo permanente, requiere conocimientos especializados.

Servicio de administración de claves (KMS)

Un servicio de administración de claves (KMS) gestiona el ciclo de vida completo de las claves criptográficas: generación, almacenamiento, rotación, política de acceso y retirada. Algunos ejemplos nativos de la nube son AWS KMS , Azure Key Vault y Google Cloud KMS . Su principal ventaja reside en la escalabilidad y la facilidad de integración: un desarrollador puede cifrar datos con unas pocas llamadas a la API, y el KMS gestiona automáticamente el almacenamiento, los calendarios de rotación y la integración con otros servicios en la nube.

Las ofertas modernas de KMS en la nube suelen estar respaldadas por HSM, pero el nivel de seguridad depende del nivel de protección que se seleccione. AWS KMS realiza sus operaciones criptográficas dentro de hardware validado según FIPS 140-3 Nivel 3 para cada clave, sin un nivel exclusivamente de software. Google Cloud KMS permite elegir un nivel de protección de software o un nivel de protección de HSM en la nube, y solo este último se ejecuta dentro de hardware certificado según FIPS 140-2 Nivel 3. Las claves de Azure Key Vault Standard están protegidas por software; las claves de Azure Key Vault Premium y Managed HSM están protegidas por hardware y, en las generaciones actuales de plataformas HSM, cuentan con la validación FIPS 140-3 Nivel 3. La etiqueta "KMS" por sí sola no indica el nivel de protección que se está adquiriendo.

HSM vs. KMS: una visión general

Dimensión	Módulo de seguridad de hardware (HSM)	Servicio de administración de claves (KMS)
Propósito primario	Protección de claves reforzada por hardware	Gestión escalable del ciclo de vida de las claves
Fuerza del núcleo	Límite de confianza a prueba de manipulaciones	Automatización, integración y políticas a gran escala.
Tenencia	A menudo se trata de hardware dedicado para un solo inquilino.	Servicio típico para múltiples inquilinos
Aislamiento de claves	Las llaves nunca se separan del hardware.	Depende del nivel de protección seleccionado.
Gastos generales operativos	Alto; requiere conocimientos especializados.	Bajo; despliegue en minutos
Modelo de costos típico	Por instancia de HSM, por hora o por mes.	Por clave y por solicitud de API
Mejor ajuste	Cargas de trabajo soberanas, reguladas y con el máximo nivel de garantía.	Cifrado de propósito general en todos los servicios en la nube

¿Cuándo conviene usar un HSM dedicado, un KMS nativo en la nube o un KMS en la nube con respaldo de HSM?

En realidad, hay tres opciones sobre la mesa, no dos, y la opción intermedia es la que los equipos suelen pasar por alto. El KMS nativo de la nube ofrece la menor sobrecarga operativa. Un HSM dedicado y autogestionado proporciona el máximo control. El KMS en la nube con respaldo de HSM, AWS CloudHSM, Azure Managed HSM o Dedicated HSM, y GCP Cloud HSM, se sitúan entre ellos: se ofrecen en la nube, pero son de un solo inquilino y se pueden acceder directamente a través de las interfaces HSM estándar.

Opción	Tenencia	Interfaz típica	Elígelo cuando
Sistemas de gestión de claves (KMS) nativos de la nube (AWS KMS, Azure Key Vault, GCP Cloud KMS)	Multi-tenant	SDK en la nube / API REST	Cifrado de propósito general, cifrado de sobre para almacenamiento y bases de datos, rápida velocidad de desarrollo, sin necesidad de un límite de hardware controlado por el cliente.
KMS en la nube con soporte de HSM (AWS CloudHSM, Azure Managed HSM / Dedicated HSM, GCP Cloud HSM)	Vivienda única, entregada en la nube	PKCS#11, JCE, CNG/KSP, SDK en la nube	Cargas de trabajo reguladas (PCI DSS, HIPAA, gobierno), aplicaciones heredadas que se comunican directamente con PKCS#11 o JCE, migración de una infraestructura HSM local, necesidad de un quórum controlado por el cliente sobre las operaciones clave.
Módulo de seguridad de hardware (HSM) dedicado y autogestionado (en las instalaciones o en un centro de datos compartido).	De un solo inquilino y gestionado por el cliente.	PKCS#11, KMIP, SDK del proveedor	Entornos aislados o con mandato de soberanía, ceremonias de clave raíz de CA fuera de línea, cargas de trabajo donde la clave nunca debe tocar la infraestructura del proveedor de la nube (HYOK).

Una regla práctica útil: utilice por defecto KMS nativo de la nube a menos que un requisito específico le obligue a lo contrario. La propia guía de AWS es clara al respecto, recomendando CloudHSM solo cuando una aplicación requiere interfaces heredadas como PKCS#11, JCE, OpenSSL Provider o Key Storage Provider, necesita compatibilidad con algoritmos obsoletos o se está migrando desde una implementación HSM local existente con cambios mínimos en el código. La misma lógica se aplica a Azure y GCP: utilice el nivel respaldado por HSM o dedicado cuando un mandato de cumplimiento, una integración heredada o un requisito de soberanía exija específicamente un límite de hardware validado y de un solo inquilino, no por defecto.

¿Cuál es el límite FIPS 140 entre el KMS de software y el HSM de hardware?

FIPS 140-3 , “Requisitos de seguridad para módulos criptográficos”, es el estándar NIST vigente para validar el hardware y el firmware que generan, almacenan y utilizan claves. Define un “límite criptográfico”, el perímetro físico y lógico explícito dentro del cual se genera, almacena y opera el material de clave, y contra el cual un laboratorio acreditado prueba el módulo bajo el Programa de Validación de Módulos Criptográficos (CMVP). Un certificado de validación indica con precisión qué se encuentra dentro de ese límite y en qué nivel de seguridad, desde el Nivel 1 (controles básicos de software o firmware) hasta el Nivel 4 (respuesta de manipulación de hardware que borra activamente las claves ante una intrusión física). La mayoría de los HSM empresariales utilizados para la gestión de claves en la nube se validan en el Nivel 3, que requiere autenticación basada en identidad, seguridad física a prueba de manipulaciones y separación lógica entre el material de clave en texto plano y sus interfaces.

La implicación práctica para la arquitectura en la nube es que "respaldado por HSM" y "protegido por software" no son distinciones de marketing, sino que se corresponden con diferentes lados de ese límite certificado. GCP Cloud KMS le permite establecer el nivel de protección de una clave. SOFTWARE or HSM En concreto, solo la capa HSM se ejecuta en hardware validado según FIPS 140-2 Nivel 3. Las claves de Azure Key Vault Standard están protegidas por software; las claves Premium y Managed HSM se ejecutan en plataformas HSM validadas según FIPS 140-3 Nivel 3. AWS KMS es la excepción que conviene tener en cuenta: todas las claves de AWS KMS, no solo las de CloudHSM, se generan y utilizan en HSM validados según FIPS 140-3 Nivel 3, ya que AWS KMS no tiene una capa exclusivamente de software.

Hay una transición importante para quienes auditan las declaraciones de los proveedores en este momento: CMVP dejó de aceptar nuevas presentaciones FIPS 140-2 el 1 de abril de 2022, y todos los certificados FIPS 140-2 restantes se incorporarán a la Lista Histórica de CMVP el 22 de septiembre de 2026. Los módulos en la Lista Histórica siguen siendo utilizables en producción, CMVP continúa brindando soporte para su compra y uso en sistemas existentes, pero las nuevas adquisiciones y validaciones deben hacer referencia a FIPS 140-3. Si la página de cumplimiento de un proveedor aún cita un certificado FIPS 140-2 únicamente después de esa fecha, pregunte qué validación FIPS 140-3, si la hay, lo ha reemplazado.

¿Qué topologías de despliegue están disponibles para HSM y KMS?

Más allá de la elección entre HSM y KMS, el verdadero factor determinante de la soberanía es la topología de custodia de claves que se adopte, ya que esto decide quién genera las claves, dónde se almacenan físicamente y si el proveedor de la nube conserva alguna capacidad técnica para acceder a ellas.

Claves gestionadas por el proveedor (PMK): el proveedor de la nube genera, almacena, utiliza, rota y realiza copias de seguridad de las claves íntegramente dentro de su propia infraestructura. Esta es la opción predeterminada para la mayoría de los sistemas de cifrado en la nube. Su funcionamiento es sencillo y no requiere ningún esfuerzo por parte del cliente, pero el proveedor tiene acceso técnico completo a las claves y, por extensión, a los datos.

Traiga su propia clave (BYOK): el cliente genera el material de clave externamente, generalmente en su propio HSM, y lo importa de forma segura al KMS del proveedor de la nube. Esto establece al cliente como la raíz de confianza para la creación de claves, pero una vez importada, la clave reside en la infraestructura del proveedor y este conserva la capacidad técnica para usarla. BYOK mejora el control sobre el origen de las claves y la política de rotación; sin embargo, no elimina el acceso técnico del proveedor.

Control de claves propio (HYOK): el cliente mantiene las claves completamente dentro de su propia infraestructura de gestión de claves, generalmente un HSM local o en un centro de datos, y nunca transfiere material de clave al entorno del proveedor. Cuando una carga de trabajo en la nube necesita cifrar o descifrar datos, envía una solicitud a la infraestructura de claves del cliente en lugar de usar una clave en poder del proveedor. El proveedor no tiene capacidad técnica para acceder a la clave. Esta es la garantía de soberanía más sólida, ya que el proveedor no tiene ninguna clave que pueda verse obligado a usar.

Almacén de claves externo (XKS) y administrador de claves externo (EKM): los proveedores de servicios en la nube han desarrollado funciones específicas para admitir arquitecturas de tipo HYOK a gran escala. AWS External Key Store, Google Cloud External Key Manager y los patrones de clave externa equivalentes de Azure permiten realizar operaciones criptográficas utilizando claves almacenadas completamente fuera de la infraestructura del proveedor de la nube, recuperadas a través de un canal autenticado para cada operación. Estas funciones constituyen el puente técnico que hace que HYOK sea viable sin abandonar los servicios nativos de la nube.

En la práctica, la mayoría de las implementaciones reales adoptan una topología híbrida: un HSM local o en un centro de datos almacena las claves de mayor valor (claves de CA raíz, claves maestras de cifrado), una capa KMS basada en HSM en la nube gestiona las cargas de trabajo regionales que requieren baja latencia a los servicios en la nube, y un KMS nativo de la nube estándar gestiona el resto del cifrado de propósito general. La cuestión de diseño no es si se trata de una implementación local o en la nube, sino qué claves, con qué nivel de sensibilidad, corresponden a cada topología.

¿Cómo funcionan la alta disponibilidad, la agrupación en clústeres y las copias de seguridad para los módulos de seguridad de hardware (HSM)?

Un HSM almacena claves de las que depende todo lo demás, por lo que, por definición, un único HSM representa un punto único de fallo. Las plataformas HSM en la nube solucionan este problema mediante la agrupación en clústeres: se implementan varios HSM, se distribuyen entre zonas de disponibilidad y el clúster sincroniza el material de claves entre todos los miembros para que cualquier HSM pueda atender cualquier solicitud. Esto proporciona dos ventajas a la vez: rendimiento, gracias al equilibrio de carga entre los miembros, y disponibilidad, ya que la pérdida de un HSM o una zona no interrumpe el servicio. La configuración básica habitual es de al menos dos HSM en dos zonas diferentes dentro de una región; considere dos como el mínimo, no como el objetivo, para cualquier sistema que no pueda permitirse perder.

La disponibilidad y la durabilidad no son la misma garantía, y confundirlas es el error más común en la arquitectura de HSM. La disponibilidad pregunta si se puede realizar una operación en este momento; un clúster multizona responde bien a esta pregunta. La durabilidad pregunta si el material clave puede perderse permanentemente, y la replicación en un clúster activo no es una estrategia de copia de seguridad por sí sola, ya que una acción administrativa errónea, una importación corrupta o una configuración incorrecta pueden propagarse a todos los miembros sincronizados a la vez. La durabilidad requiere copias de seguridad deliberadas, independientes y probadas periódicamente, almacenadas por separado del clúster activo. Para la resiliencia entre regiones, se extiende el mismo principio: un clúster multizona protege contra la falla de una zona, no contra la pérdida total de la región, por lo que la recuperación ante desastres requiere la capacidad de restaurar un clúster en una segunda región a partir de copias de seguridad actuales, dentro de las restricciones de residencia de datos que se apliquen.

Este tema merece un análisis exhaustivo; nuestra publicación complementaria, "Agrupación de HSM y alta disponibilidad bien hecha" , explica el diseño de clústeres, la estrategia entre regiones y la disciplina de pruebas de conmutación por error que distingue una arquitectura resiliente en teoría de una que realmente resiste durante una interrupción real.

¿Qué sucede durante una ceremonia de entrega de llaves de HSM?

Una ceremonia de claves es el procedimiento formal y presenciado para generar, distribuir y proteger las claves criptográficas de mayor valor, normalmente una clave raíz de la CA o una clave maestra de cifrado, dentro de un HSM. Las claves nunca existen en texto plano fuera del módulo: se generan dentro del entorno criptográfico del HSM y permanecen allí durante toda su vida útil. Las ceremonias son importantes tanto para la seguridad como para el cumplimiento normativo, ya que estándares como WebTrust y eIDAS exigen la generación de claves documentada y auditable para las CA, y PCI DSS exige un rigor equivalente para las claves que protegen los datos de los titulares de tarjetas.

Dos elementos definen una ceremonia bien organizada. Primero, roles definidos: un administrador de sistemas, oficiales de seguridad, un administrador de CA y testigos independientes, para que ninguna persona pueda comprometer el proceso por sí sola. Segundo, control basado en quórum: las operaciones sensibles requieren un número definido de tarjetas inteligentes de oficiales de un conjunto mayor, comúnmente expresado como una política M de N, como 3 de 5, para que la confianza se distribuya entre varias personas en lugar de recaer en una sola. Cada paso está guionizado con anticipación, se registra en tiempo real y se graba en video para evidencia de auditoría.

Para obtener una guía completa paso a paso, desde la preparación de la ceremonia hasta la inicialización de Security World, la definición del quórum, la generación de claves y el sellado, consulte Inside the Key Ceremony: PKI, HSM, The Process, The People, and Why it Matters.

¿Cuáles son los requisitos previos de integración para HSM y KMS en la nube?

Para que un HSM o KMS pueda proteger una carga de trabajo real, la capa de integración debe ser la adecuada. Los requisitos previos varían según la opción que haya elegido entre las tres anteriores.

• PKCS#11: Interfaz estándar, originada por RSA y ahora mantenida por OASIS, que la mayoría de las aplicaciones heredadas, los SDK de HSM y el software PKI utilizan para comunicarse directamente con un HSM. Requerida para CloudHSM, Azure Cloud HSM y la mayoría de las integraciones de HSM locales; confirme que la versión de la biblioteca PKCS#11 de su aplicación coincida con la que admite el proveedor del HSM.
• KMIP (Protocolo de interoperabilidad para la gestión de claves): El estándar OASIS, actualmente en su versión 2.1, permite la gestión centralizada del ciclo de vida de las claves en gestores de claves y HSM heterogéneos de diferentes proveedores. Resulta relevante cuando se necesita un único plano de gestión de claves para administrar las claves que residen en múltiples plataformas HSM, en lugar de integrarlas por separado con la API propietaria de cada proveedor.
• Motores JCE, CNG/KSP y OpenSSL: Interfaces de proveedores criptográficos específicas de la plataforma (Extensión de Criptografía de Java, API de Criptografía de Windows: Próxima Generación / Proveedor de Almacenamiento de Claves, OpenSSL) que permiten que las aplicaciones existentes basadas en Java, Windows u OpenSSL descarguen las operaciones de clave a un HSM con cambios mínimos en el código. Este es el método que utilizan la mayoría de las migraciones de tipo "lift-and-shift".
• SDK en la nube y política de IAM: Para los sistemas KMS nativos de la nube y los sistemas KMS en la nube con soporte HSM, la integración se realiza a través del SDK del proveedor (AWS SDK, Azure SDK, bibliotecas cliente de Google Cloud) y se rige por la política de IAM en lugar de un cliente HSM a nivel de red. El diseño del control de acceso es tan importante como la criptografía: una clave con una política de IAM demasiado amplia no ofrece mejor protección funcional que una clave débil.
• Configuración de la red y de la confianza del cliente: Las implementaciones dedicadas y respaldadas por HSM requieren registrar cada sistema cliente que utilizará el HSM, establecer una conectividad de red con autenticación mutua y validar dicha conectividad antes de intentar cualquier operación clave. Este paso de registro suele ser la parte más larga del cronograma de implementación y es donde las reglas de firewall incompatibles o la falta de confianza en los certificados suelen retrasar el despliegue.

¿Cómo se evalúa e implementa una estrategia HSM/KMS?

Una evaluación estructurada evita los dos errores más comunes: el sobredimensionamiento de HSM dedicados para cargas de trabajo que nunca necesitaron hardware de un solo inquilino, y el subdimensionamiento de KMS nativos de la nube para cargas de trabajo que realmente requerían un límite de hardware validado o un quórum controlado por el cliente.

1. Clasifique sus claves por sensibilidad y controlador de cumplimiento. Separe las claves raíz/maestras, las claves de datos regulados (PCI DSS, HIPAA) y las claves de cifrado de uso general en niveles distintos antes de elegir la infraestructura para cualquiera de ellas.
2. Asigna una topología a cada nivel. Utilice la tabla de decisiones anterior: KMS nativo de la nube para niveles de propósito general, KMS en la nube respaldado por HSM para niveles regulados o de interfaz heredada, HSM dedicados o HYOK para niveles raíz críticos para la soberanía o fuera de línea.
3. Confirme que la validación FIPS realmente cubre su caso de uso. Verifique el número de certificado específico y el nivel de protección, no solo la página de marketing, y confirme que hace referencia a FIPS 140-3 o a una entrada de la Lista Histórica de FIPS 140-2 que aún tenga soporte.
4. Diseña para la interfaz de integración que tus aplicaciones ya utilizan. PKCS#11, KMIP, JCE/CNG o SDK en la nube, elegidos en función de lo que requieran las aplicaciones existentes, en lugar de lo que sea más fácil de demostrar.
5. Planifique la agrupación y la distribución entre zonas antes de la puesta en marcha., no después de la primera interrupción; trate las implementaciones de un solo HSM como un estado temporal, no como una arquitectura.
6. Establecer procedimientos independientes de respaldo y recuperación de quórum.y documentar quién posee qué credencial, antes de la ceremonia que genera las claves de producción.
7. Ejecuta una ceremonia de clave para cualquier clave raíz o maestra., con roles definidos, quórum y registro de auditoría, independientemente de si el HSM está instalado localmente o alojado en la nube.
8. Programar las pruebas de conmutación por error y de copia de seguridad y restauración como un ejercicio recurrente.No se trata de un paso de validación único, ya que los entornos cambian y las rutas de recuperación no probadas dejan de funcionar silenciosamente.

¿Cuáles son los modos de fallo más comunes y cómo se pueden mitigar?

Modo de fallo	Lo que sucede	Mitigación
Punto único de fallo (un HSM, una zona)	Cualquier fallo de hardware o interrupción de zona deja fuera de servicio a todos los servicios dependientes a la vez.	Agrupe los HSM en un mínimo de dos zonas de disponibilidad; trate las implementaciones de instancia única como temporales.
Pérdida de quórum (pocas credenciales de oficiales supervivientes)	Las operaciones administrativas M-of-N, incluidas las acciones de recuperación, no se pueden autorizar aunque el hardware HSM esté intacto.	Establezca umbrales de quórum de forma deliberada (no solo el mínimo), almacene las tarjetas de custodia geográficamente separadas y documente un procedimiento de recuperación de credenciales antes de que sea necesario.
Fallo de partición o zona de HSM	Las cargas de trabajo vinculadas a la partición o zona que ha fallado experimentan fallos operativos hasta que se redirige el tráfico.	Confirme que la lógica de conmutación por error del cliente redirige correctamente a los miembros del clúster que funcionan correctamente; verifique con una prueba de conmutación por error programada y deliberada en lugar de asumir que funciona.
Replicación sin copia de seguridad independiente	Una importación de clave corrupta o una acción administrativa errónea se propaga a todos los miembros del clúster sincronizados simultáneamente.	Mantenga copias de seguridad independientes del clúster en funcionamiento y compruebe periódicamente que se restauran; la replicación por sí sola no garantiza la durabilidad.
Recuperación interregional no probada	Una interrupción regional total o una interrupción por parte del proveedor no deja ninguna vía verificada para restablecer el servicio.	Mantenga copias de seguridad actualizadas y restaurables en una segunda región y practique la restauración, no solo la copia de seguridad.

Limitaciones

Ninguna opción es universalmente correcta, y cada una conlleva limitaciones reales que conviene mencionar claramente. Los HSM dedicados y los HSM en la nube con soporte de HSM cuestan significativamente más que las claves protegidas por software y requieren experiencia operativa especializada; subestimar este coste es un error de planificación común. HYOK ofrece la garantía de soberanía más sólida, pero añade latencia y una nueva dependencia externa a cada operación criptográfica, ya que la carga de trabajo en la nube debe acceder a la infraestructura de claves externa en cada llamada. BYOK mejora el control sobre el origen de la clave, pero no elimina el acceso técnico del proveedor una vez importada la clave, una distinción que muchas conversaciones de adquisición pasan por alto. El KMS nativo de la nube multiusuario es operativamente sencillo, pero no es la opción adecuada cuando un mandato de cumplimiento o un término contractual exige específicamente hardware de un solo usuario controlado por el cliente. Y ninguna arquitectura de HSM o KMS, por bien diseñada que esté, sustituye la disciplina operativa de copias de seguridad probadas, conmutación por error probada y una ceremonia de clave documentada; la tecnología impone un límite, pero las personas y los procesos siguen decidiendo si ese límite se mantiene realmente.

¿Qué recomendaría Encryption Consulting?

La seguridad y la soberanía de los datos en la nube se sitúan precisamente en la intersección de la estrategia de cifrado, la arquitectura de gestión de claves y el cumplimiento normativo, que es el núcleo de la práctica de Encryption Consulting. Nuestra recomendación inicial es casi siempre la misma, independientemente del proveedor de la nube: clasifique las claves por nivel de sensibilidad antes de elegir la infraestructura, no opte por un HSM dedicado por precaución ni por un KMS sin cifrado por comodidad, y verifique la validación FIPS y el diseño del quórum antes de la puesta en marcha, en lugar de después de una auditoría.

Para las organizaciones que necesitan la seguridad de claves protegidas por hardware sin tener que construir ni operar esa infraestructura por sí mismas, nuestra oferta de HSM como servicio proporciona una solución de alta seguridad, aprobada por FIPS 140-2 Nivel 3 y PCI HSM, implementable en las instalaciones, en la nube o en un modelo híbrido, con clustering, copias de seguridad y conmutación por error integrados en el servicio, en lugar de que su equipo tenga que configurarlos. Somos independientes del proveedor, trabajando con HSM de Thales , Entrust y los principales proveedores de la nube, por lo que la arquitectura se adapta a sus requisitos en lugar de a una única línea de productos. Usted mantiene el control total sobre su material de claves y registros de auditoría en todo momento, y nosotros podemos encargarnos por completo del entorno HSM, el aprovisionamiento, la configuración, las actualizaciones y la gestión continua, o simplemente brindar soporte a su equipo donde lo necesite.

Para las organizaciones que construyen o modernizan su infraestructura de certificados sobre la capa HSM, ya sea una jerarquía de CA raíz, una PKI híbrida que abarque entornos locales y en la nube, o la migración desde infraestructuras heredadas, nuestra oferta de PKI como servicio gestiona la emisión de certificados, la automatización del ciclo de vida y el diseño de la jerarquía de CA, con las claves privadas ancladas en el mismo límite de confianza respaldado por HSM que se describe en esta publicación. Dado que el panorama regulatorio de 2026, que incluye la Ley de Datos de la UE, DORA, NIS2 y los marcos de soberanía de la nube en evolución, exige cada vez más un control técnico verificable sobre las claves criptográficas, nuestros servicios de consultoría también se centran en la elaboración de la documentación, los diagramas de arquitectura de gestión de claves, la documentación del flujo de datos y los registros de ceremonias que los reguladores y los marcos de contratación pública ahora requieren en lugar de aceptarlos sin más.

Conclusión

La seguridad en la nube, en última instancia, depende de quién controla las claves y en quién depositas tu confianza. El cifrado es necesario, pero es la arquitectura de custodia de claves basada en HSM y KMS, junto con la disciplina operativa en torno a la validación FIPS, la topología de despliegue, la alta disponibilidad, las ceremonias de claves y el diseño de la integración, lo que determina si tus datos están realmente bajo tu control o simplemente almacenados en un centro de datos mientras otra persona tiene los medios para desbloquearlos.

Los HSM proporcionan protección reforzada por hardware que garantiza que las claves nunca salgan de un perímetro validado y a prueba de manipulaciones. Los KMS ofrecen la gestión escalable del ciclo de vida, la aplicación de políticas y el registro de auditoría que hacen que la gestión de claves sea práctica a escala de nube. Los KMS en la nube con respaldo de HSM conectan ambos sistemas. Con una correcta configuración en capas, que incluye agrupación en clústeres, copias de seguridad probadas, una ceremonia de claves ejecutada correctamente y la interfaz de integración adecuada para cada aplicación, transforman el objetivo abstracto de la seguridad de datos en la nube en una realidad técnica aplicable, en lugar de una simple casilla de verificación de cumplimiento.

En Encryption Consulting, nuestros servicios de consultoría y nuestra cartera de productos están diseñados para ayudar a las organizaciones a diseñar e implementar la arquitectura de gestión de claves que exige la seguridad y la soberanía de los datos en la nube. Si está trabajando en su estrategia de control de claves en la nube, estaremos encantados de ayudarle.

Preguntas frecuentes

¿Cuál es la diferencia entre un HSM y un KMS?
Un HSM es un dispositivo de hardware a prueba de manipulaciones que protege las claves dentro de un entorno física y lógicamente aislado, y realiza operaciones criptográficas internamente. Un KMS es un servicio de software que gestiona el ciclo de vida completo de las claves: generación, almacenamiento, rotación y política de acceso, y suele ejecutarse sobre los HSM. Los HSM responden a la pregunta de «cómo se protege físicamente la clave»; los KMS responden a la pregunta de «cómo se gestiona el ciclo de vida de la clave a gran escala».

¿Está validado AWS KMS con la norma FIPS 140-3?
Sí. AWS KMS realiza operaciones criptográficas para cada clave dentro de los HSM validados según FIPS 140-3 Nivel 3; no existe una capa que solo utilice software. AWS CloudHSM utiliza el mismo nivel de validación, pero en hardware de un solo inquilino administrado por el cliente, al que se accede directamente a través de PKCS#11, JCE o KSP, en lugar de a través de la API KMS multiinquilino.

¿Cuándo debo usar CloudHSM, Azure Dedicated HSM o GCP Cloud HSM en lugar del KMS en la nube estándar?
Utilice la capa con soporte de HSM cuando una aplicación requiera una interfaz heredada como PKCS#11 o JCE directamente, cuando migre una implementación de HSM local con cambios mínimos en el código, o cuando un requisito de cumplimiento exija específicamente hardware de un solo inquilino controlado por el cliente en lugar de un servicio multiinquilino. Para el cifrado de propósito general sin esos requisitos, el KMS nativo de la nube estándar es la opción predeterminada más sencilla y económica.

¿Cuál es la diferencia entre BYOK y HYOK?
Con Bring Your Own Key (BYOK), usted genera la clave externamente y la importa al KMS del proveedor de la nube, quien conserva el acceso técnico a ella. Con Hold Your Own Key (HYOK), la clave nunca sale de su propia infraestructura; la carga de trabajo en la nube se comunica con su administrador de claves para cada operación, por lo que el proveedor nunca tiene acceso técnico a la clave. HYOK ofrece mayor soberanía; BYOK ofrece una integración más sencilla con los servicios nativos de la nube.

¿Qué ocurre si un clúster HSM pierde el quórum administrativo?
Si quedan muy pocas credenciales de oficiales para alcanzar el umbral M-of-N requerido para las operaciones administrativas, no se podrán autorizar acciones delicadas, incluidas algunas operaciones de recuperación, aunque el hardware HSM funcione correctamente. Por ello, los umbrales de quórum y el almacenamiento de tarjetas de custodia deben planificarse cuidadosamente durante la ceremonia de entrega de claves, con una ruta de recuperación documentada, en lugar de descubrirlos durante un incidente real.

Referencias

• NIST, FIPS 140-3, Requisitos de seguridad para módulos criptográficos
• NIST CSRC, Esfuerzo de transición de FIPS 140-3
• Blog de seguridad de AWS, AWS KMS o AWS CloudHSM: Elija la solución de gestión de claves adecuada.
• Microsoft Learn, Cómo elegir la solución de administración de claves de Azure adecuada
• Documentación de Google Cloud, HSM en la nube | Servicio de gestión de claves en la nube
• Documentación de Google Cloud, Niveles de protección | Servicio de gestión de claves en la nube
• OASIS Abierto, Especificación del protocolo de interoperabilidad de gestión de claves, versión 2.1
• Consejo de Normas de Seguridad PCI, Requisitos de seguridad de HSM para la seguridad de transacciones con PIN (PTS) de PCI