HSM basados ​​en la nube vs. locales

La decisión de implementar módulos de seguridad de hardware (HSM) en la nube o en las instalaciones determina quién tiene el control físico de las operaciones criptográficas más sensibles de su organización. Un módulo de seguridad de hardware (HSM) es un dispositivo de hardware dedicado y a prueba de manipulaciones que genera, almacena y gestiona claves criptográficas dentro de un entorno validado según la norma FIPS 140-2 Nivel 3. La elección entre implementar HSM en su propio centro de datos o utilizarlos como un servicio gestionado en la nube afecta su modelo de control de claves, perfil de latencia, nivel de cumplimiento, coste total de propiedad y gastos operativos. Esta guía abarca todos los aspectos de esta decisión para que los equipos de seguridad e infraestructura puedan seleccionar el modelo adecuado para sus necesidades específicas.

Respuesta rápida: ¿HSM basado en la nube o HSM local?

Para la mayoría de las organizaciones: los servicios HSM basados ​​en la nube ofrecen una seguridad criptográfica equivalente a la de los HSM locales, con un menor coste total de propiedad, una implementación más rápida y sin la carga operativa de gestionar el hardware físico. Elija HSM locales cuando su aplicación tenga requisitos de latencia inferiores a un milisegundo que un viaje de ida y vuelta de la red no pueda cumplir, cuando las normativas exijan que las claves nunca salgan de una instalación física o jurisdicción específica sin un servicio HSM en la nube disponible, o cuando opere en un entorno aislado sin conectividad a la nube. Para entornos multinube e híbridos que requieren una gobernanza de claves centralizada, un HSM como servicio de terceros que abarque varios proveedores suele ser la opción más práctica.

Puntos Clave

• La tecnología criptográfica es la misma: Tanto los módulos de seguridad de hardware (HSM) basados ​​en la nube como los instalados localmente utilizan hardware validado según la norma FIPS 140-2 de nivel 3, que realiza las mismas operaciones criptográficas. El modelo de implementación determina quién opera el hardware, no qué función cumple.
• La gestión de seguridad de hardware en la nube (Cloud HSM) reduce los gastos operativos, no la seguridad: Los servicios HSM en la nube eliminan las responsabilidades de su equipo en cuanto a la adquisición de hardware, el espacio en racks de centros de datos, la actualización del firmware y la administración de clústeres HSM. El límite criptográfico se mantiene protegido por hardware, independientemente de quién lo opere.
• BYOK y HYOK requieren material de clave generado por HSM: Tanto las implementaciones BYOK (Bring Your Own Key, Traiga su propia clave) como HYOK (Mantenga su propia clave) suelen utilizar un HSM local o en la nube dedicada como fuente de generación de claves, lo que convierte la elección del HSM en un componente de la estrategia de gestión de claves en la nube, y no en algo separado de ella.
• La latencia es la limitación técnica más común que favorece las soluciones locales: Las aplicaciones que requieren tiempos de respuesta de HSM inferiores a un milisegundo no pueden tolerar la latencia de red de una llamada a la API de HSM en la nube. El trading de alta frecuencia, el procesamiento de pagos a gran escala y algunas operaciones de firma PKI entran en esta categoría.
• El nivel 3 de FIPS 140-2 está disponible en ambos modelos: AWS CloudHSM, Azure Dedicated HSM y GCP Cloud HSM utilizan hardware validado según FIPS 140-2 Nivel 3. Los servicios KMS en la nube compartida sin una capa HSM dedicada utilizan el Nivel 2, no el Nivel 3. Verifique la capa de servicio exacta cuando se requiera el Nivel 3.

¿Qué es un módulo de seguridad de hardware (HSM)?

Un módulo de seguridad de hardware (HSM, por sus siglas en inglés) es un dispositivo informático físico dedicado, diseñado para proteger claves criptográficas y realizar operaciones criptográficas dentro de un entorno de hardware a prueba de manipulaciones. Los HSM están diseñados específicamente para la seguridad de claves: generan claves mediante generadores de números aleatorios de hardware, almacenan las claves en un formato no exportable dentro del entorno de hardware, realizan operaciones criptográficas (cifrado, descifrado, firma, verificación) dentro de ese entorno, de modo que el material de la clave nunca tiene que salir del dispositivo en texto plano, y detectan y responden a los intentos de manipulación física borrando el material de la clave.

La seguridad de un HSM se valida formalmente mediante el programa de certificación NIST FIPS 140-2 (Estándar Federal de Procesamiento de Información). FIPS 140-2 define cuatro niveles de seguridad: Nivel 1 (módulo criptográfico de software básico), Nivel 2 (seguridad física a prueba de manipulaciones), Nivel 3 (seguridad física resistente a manipulaciones con autenticación basada en identidad y puesta a cero de parámetros de seguridad críticos al detectar manipulación) y Nivel 4 (seguridad física completa que protege contra ataques ambientales). El Nivel 3 de FIPS 140-2 es el requisito estándar para implementaciones de HSM en entornos empresariales y regulados. NIST se encuentra actualmente en transición a FIPS 140-3, que se alinea con ISO/IEC 19790; las validaciones FIPS 140-2 existentes siguen siendo válidas durante el período de transición.

Los HSM se utilizan en una amplia gama de cargas de trabajo criptográficas: protección de claves privadas para autoridades de certificación (CA) en infraestructura PKI, generación y protección de claves de cifrado utilizadas para el cifrado transparente de datos (TDE) de bases de datos, protección de claves privadas para certificados TLS en puntos finales de alto valor, realización de operaciones de firma para la firma de código y la firma de documentos, protección de claves utilizadas para el cifrado y la verificación del PIN de tarjetas de pago y generación del material de clave BYOK importado a los servicios de administración de claves en la nube.

HSM locales: Control total, responsabilidad total

Un HSM local es un dispositivo físico que su organización compra, instala en su propio centro de datos o instalación de coubicación, configura, opera y mantiene. El hardware HSM se conecta a sus aplicaciones y a la infraestructura de gestión de claves a través de su red interna, normalmente mediante PKCS#11, JCE (Java Cryptography Extension), Microsoft CNG (Cryptography Next Generation) o API REST, según el modelo de HSM y los requisitos de integración de la aplicación.

Lo que ofrecen los HSM locales: Posesión física y control del hardware criptográfico y las claves almacenadas en él. Sin dependencia de la disponibilidad o la API de un proveedor de nube para operaciones criptográficas. Latencia de red local inferior a un milisegundo para operaciones criptográficas de alta frecuencia. Capacidad para realizar ceremonias de claves en un entorno físicamente controlado para la generación de claves privadas de CA. Cumplimiento total de los requisitos de soberanía de datos o localización que exigen que las claves permanezcan dentro de una instalación física o jurisdicción específica donde no haya ningún servicio HSM en la nube.

Costo de los HSM locales: Compra inicial de hardware (normalmente entre $20,000 y $40,000 por dispositivo, según el modelo y la capacidad de procesamiento). Unidades adicionales para clústeres de alta disponibilidad (HA) y recuperación ante desastres, que generalmente requieren un mínimo de dos unidades para la resiliencia de producción. Licencias de software de gestión. Espacio en rack del centro de datos, energía y refrigeración. Tiempo de personal especializado para la configuración inicial, actualizaciones de firmware, gestión de particiones, implementación de software cliente y operaciones continuas. Ciclos de reemplazo de hardware (normalmente de 5 a 7 años). Controles de seguridad física para el centro de datos que alberga el HSM.

Cuándo los HSM locales son la opción correcta: Aplicaciones con estrictos requisitos de latencia que no pueden tolerar un viaje de ida y vuelta a la red con un servicio en la nube (operaciones criptográficas de sub-milisegundos para operaciones de alta frecuencia, procesamiento de bloques PIN de terminales de pago o canalizaciones de firma en tiempo real); requisitos reglamentarios que exigen la custodia física de claves en una instalación o país específico donde no opera ningún servicio HSM en la nube; entornos aislados o clasificados sin conectividad a Internet; organizaciones con volúmenes muy altos de transacciones criptográficas donde el precio de las llamadas a la API en la nube es significativamente más caro que el hardware propio; y ceremonias de claves para la generación de claves raíz de CA donde se requiere presencia física y procedimientos de testigos.

Módulos de gestión de hardware (HSM) basados ​​en la nube: hardware gestionado, compartido o dedicado.

Los HSM basados ​​en la nube son dispositivos de hardware HSM validados por FIPS, operados por un proveedor de servicios en la nube o un servicio de terceros, a los que sus aplicaciones acceden mediante una API autenticada. El hardware HSM se encuentra físicamente en el centro de datos del proveedor de servicios. Sus aplicaciones nunca interactúan directamente con el hardware HSM; llaman a la API del servicio, que dirige la operación criptográfica al hardware HSM subyacente y devuelve el resultado.

Los servicios HSM basados ​​en la nube se dividen en dos categorías con modelos de seguridad significativamente diferentes:

Servicios HSM en la nube dedicados (para un solo inquilino)

Los servicios HSM en la nube dedicados proporcionan hardware HSM físico exclusivamente a su organización. Ninguna otra clave u operación criptográfica de otros clientes comparte el hardware ni las particiones HSM con las suyas. Algunos ejemplos son AWS CloudHSM (que utiliza hardware Luna Network HSM, FIPS 140-2 Nivel 3, con un coste aproximado de 1.45 $ por hora por instancia), Azure Dedicated HSM (que utiliza hardware Entrust nShield Connect, FIPS 140-2 Nivel 3) y Azure Payments HSM (que utiliza hardware Utimaco para cargas de trabajo HSM de pago). En un HSM en la nube dedicado, el proveedor de la nube gestiona la infraestructura física, pero no tiene acceso a sus claves ni a las particiones HSM; usted gestiona el software HSM, las particiones y el material de claves a través de la interfaz de gestión del propio HSM.

Los servicios dedicados de HSM en la nube ofrecen un nivel de seguridad muy similar al de los HSM locales: validación FIPS 140-2 Nivel 3, hardware de un solo inquilino y exclusión del proveedor de la nube del acceso a las claves. Las principales diferencias con respecto a las soluciones locales radican en la latencia de red de las llamadas a la API (normalmente de 1 a 5 milisegundos frente a menos de un milisegundo en el caso de las soluciones locales), la responsabilidad de la gestión operativa (usted gestiona el software y las particiones del HSM, pero no el hardware físico) y el modelo de precios (por hora frente a inversión inicial).

Servicios HSM en la nube compartida (multiusuario)

Los servicios HSM en la nube compartida utilizan hardware HSM particionado y compartido entre varios clientes. Sus claves están lógicamente aisladas de las claves de otros clientes dentro del HSM, pero el hardware físico es compartido. Algunos ejemplos son AWS KMS con protección HSM (validado según FIPS 140-2 Nivel 2), GCP Cloud KMS con nivel de protección HSM (validado según FIPS 140-2 Nivel 3 para claves respaldadas por HSM) y Azure Key Vault Premium (claves protegidas por HSM). Estos servicios son totalmente administrados: el proveedor de la nube administra el hardware, el software HSM y la plataforma de administración de claves. Su responsabilidad se limita a la configuración de la política de claves, el control de acceso y la administración del ciclo de vida de las claves a través de la API del proveedor de la nube.

Los servicios HSM compartidos en la nube ofrecen los costos operativos más bajos. La desventaja es que el proveedor de la nube opera el hardware HSM y tiene la capacidad de acceder o migrar la infraestructura subyacente, incluso si el aislamiento de la clave lógica es sólido. Para la mayoría de los marcos de cumplimiento, un servicio HSM compartido de un proveedor de la nube respaldado por un BAA, DPA u otro control contractual es suficiente. Para cargas de trabajo que requieren acceso nulo del proveedor de la nube al material clave, es necesario un HSM dedicado en la nube o un HSM local.

Modelos de control de teclas: Nativo, BYOK y HYOK

La decisión de implementar un HSM está estrechamente ligada al modelo de control de claves que exigen sus requisitos de cumplimiento o su política de seguridad. Existen tres modelos de control de claves, y cada uno tiene diferentes implicaciones para el HSM.

Gestión nativa de claves en la nube (claves gestionadas por el proveedor)

El proveedor de la nube genera y gestiona todas las claves de cifrado en su propia infraestructura de gestión de claves. Sus claves están protegidas por hardware HSM operado por el proveedor, pero usted no tiene visibilidad ni control sobre el material físico de la clave. Puede usar, rotar, deshabilitar y eliminar claves a través de la API del proveedor, pero no puede verificar de forma independiente que el material de la clave se generó con la procedencia que exige su política. Este modelo no requiere inversión ni operación de HSM por su parte y es adecuado para la mayoría de las cargas de trabajo generales en la nube donde el registro de auditoría de gestión de claves del proveedor es suficiente para sus requisitos de cumplimiento.

BYOK (Traiga su propia llave)

BYOK significa que usted genera el material de clave de cifrado en un HSM que usted controla (local o en la nube), exporta dicho material (encapsulado para un transporte seguro) y lo importa al servicio de administración de claves del proveedor de la nube (AWS KMS, Azure Key Vault o GCP Cloud KMS). El proveedor de la nube utiliza el material de clave importado para generar las claves de cifrado de datos que protegen sus datos en la nube. Usted conserva el material de clave original en su HSM y puede eliminarlo del KMS del proveedor de la nube para revocar inmediatamente su capacidad de descifrar sus datos.

BYOK cumple con los requisitos normativos que exigen que el cliente genere las claves. Requiere un HSM local o un servicio HSM en la nube como fuente de generación de claves. El KMS del proveedor de la nube tiene acceso operativo a las claves durante su uso; BYOK ofrece capacidad de verificación de procedencia y revocación, pero no acceso cero al proveedor.

HYOK (Mantén tu propia llave)

HYOK significa que la clave de cifrado nunca ingresa a la infraestructura del proveedor de la nube. Su aplicación o biblioteca del lado del cliente cifra los datos antes de subirlos al almacenamiento en la nube, utilizando una clave que se genera y almacena en su propio HSM (local o en un servicio HSM en la nube de terceros que no sea el mismo proveedor que su almacenamiento de datos). El proveedor de la nube solo almacena el texto cifrado y no puede descifrar sus datos bajo ninguna circunstancia operativa. HYOK requiere un HSM local o un HSM como servicio de terceros que opere independientemente de sus proveedores de almacenamiento en la nube. Proporciona la máxima soberanía de datos a costa de la mayor complejidad operativa.

Dimensión	Gestión de claves nativas en la nube	BYOK (Clave generada por el cliente en KMS en la nube)	HYOK (Clave completamente externa al proveedor de la nube)
Se requiere HSM	No (HSM del proveedor)	Sí (para generar y conservar el material de clave de origen)	Sí (para generar y usar la clave en cada operación)
Modelo de despliegue de HSM	No es aplicable	HSM local o HSM dedicado en la nube	HSM local o HSM de terceros como servicio
Acceso del proveedor a la clave durante el uso	Sí:	Sí (acceso operativo)	No
Acceso del proveedor a los datos en texto plano	Sí (mediante clave)	Sí (mediante tecla durante el uso)	No
Revocación de clave independiente	Solo a través de la API del proveedor	Sí (elimine el material fuente de su HSM)	Sí (revoca inmediatamente en tu HSM)
Complejidad operativa	Bajo	Media	Alto
Ideal para	Cargas de trabajo generales en la nube	Sectores regulados que requieren una procedencia clave	Clasificado, impuesto por soberanía, confianza cero

HSM basados ​​en la nube frente a HSM locales: Comparación completa

Dimensión	HSM local	HSM dedicado en la nube	Servicio HSM de nube compartida
FIPS 140-2 Nivel 3	Sí:	Sí:	Depende del nivel de servicio (Nivel 2 o 3).
Custodia física de llaves	Tu organización	Proveedor de servicios en la nube (solo hardware; sin acceso mediante clave)	Proveedor de servicios en la nube (hardware e infraestructura)
Gestión de hardware	Tu organización	Proveedor de la nube (hardware); usted gestiona el software HSM.	Proveedor de servicios en la nube (gestión completa)
Costo de capital inicial	Entre 20,000 y más de 40,000 dólares por electrodoméstico.	Ninguna	Ninguna
Modelo de costos continuos	Tiempo del personal, licencias, costos del centro de datos	Precio por hora por instancia (aprox. 1.45 $/hora para AWS CloudHSM)	Tarifa por llamada a la API + cargo por almacenamiento de clave
Tiempo de implementación	Semanas a meses (adquisición, montaje en bastidor, configuración)	Minutos a horas	Minutos
Estado latente	Submilisegundo (red local)	De 1 a 5 ms (tiempo de ida y vuelta de la API de red)	De 1 a 10 ms (API de servicio compartido)
Alta disponibilidad	Requiere varios dispositivos y configuración de alta disponibilidad.	Disponible a través de clústeres de múltiples instancias o entre zonas de disponibilidad.	Integrado en el servicio gestionado
Gastos generales operativos	Alto (firmware, particiones, administración de clústeres, personal)	Medio (software HSM y gestión de particiones)	Bajo (solo políticas clave y gestión de acceso)
Escalabilidad organizacional	Limitado por la capacidad del hardware; la expansión requiere adquisición.	Agregar instancias bajo demanda	Escala automáticamente
Soporte multinube	Sí (cualquier aplicación puede conectarse)	Limitado al ecosistema de ese proveedor.	Específico del proveedor
Responsabilidad de cumplimiento	Su organización está plenamente	Compartido (el proveedor gestiona el cumplimiento del hardware)	Proveedor principal
Entornos aislados	Sí:	No	No
Capacidad de fuente BYOK	Sí:	Sí:	Limitado (algunos proveedores lo admiten)
Ideal para	Baja latencia, aislamiento aéreo, localización estricta, HYOK	Nivel FIPS 3, BYOK (Trae tu propio dispositivo), multi-nube con hardware dedicado	Cargas de trabajo generales en la nube, simplicidad gestionada

Modelo IAM para el control de acceso HSM

Ya sea que implemente HSM locales o en la nube, el control de acceso es tan importante como el propio perímetro del hardware. Un HSM FIPS 140-2 Nivel 3 con controles de acceso permisivos no es más seguro que un almacén de claves de software. El modelo IAM para HSM separa tres roles distintos que no deben superponerse.

Rol de administrador de HSM: Crea y administra particiones de HSM, establece políticas de partición, administra la pertenencia al clúster de HSM, realiza actualizaciones de firmware y gestiona los procedimientos de ceremonia de claves. En entornos locales, este rol suele ser desempeñado por un miembro del equipo de operaciones de HSM que utiliza la autenticación de hardware del HSM (PED o tarjeta inteligente). En servicios de HSM en la nube, el administrador se autentica en la API de administración de HSM con tokens de hardware o credenciales robustas. El rol de administrador nunca debe ser utilizado por aplicaciones ni procesos automatizados.

Función de custodio de claves (oficial criptográfico): Crea, importa, exporta (cuando está permitido), rota y elimina objetos de clave dentro de una partición asignada. Esta función es responsable del ciclo de vida de las claves dentro del HSM. En un contexto de HSM en la nube, esto se corresponde con la función que administra las políticas de claves en AWS KMS, Azure Key Vault o GCP Cloud KMS. Las acciones del custodio de claves deben requerir control dual para operaciones de claves de alto valor (generación de clave raíz de CA, eliminación de clave maestra) y deben registrarse.

Rol de aplicación (usuario criptográfico): Utiliza claves dentro del HSM para realizar operaciones criptográficas (cifrar, descifrar, firmar, verificar), pero no puede crear, eliminar ni exportar claves. En los servicios KMS en la nube, esto se corresponde con otorgar a la cuenta de servicio o rol IAM de la aplicación únicamente los permisos específicos para operaciones criptográficas que necesita (kms:Decrypt para aplicaciones que solo descifran; kms:Sign para aplicaciones que solo firman), sin permisos de administración de claves. Los roles de aplicación deben estar limitados a claves específicas, no se les debe otorgar acceso general a todas las claves de una partición o almacén de claves.

Rotación de llaves con HSM

La rotación de claves en un HSM implica generar nuevo material de clave dentro del HSM para reemplazar las claves existentes según un cronograma definido. El funcionamiento de la rotación depende de si el HSM protege una clave maestra (que encapsula otras claves) o una clave de cifrado de datos (que cifra los datos directamente).

Rotación de claves maestras en KMS en la nube con respaldo HSM: Al habilitar la rotación automática de una clave administrada por el cliente en AWS KMS o Azure Key Vault, el servicio genera nuevo material de clave con respaldo HSM según la programación configurada (normalmente anual). Los datos existentes cifrados con la versión anterior de la clave siguen siendo descifrables; KMS conserva las versiones anteriores de la clave. Las nuevas operaciones de cifrado utilizan el nuevo material de clave. El ID de clave y el ARN permanecen sin cambios; la rotación es transparente para las aplicaciones.

Rotación de claves para HSM locales y BYOK: La rotación de claves en HSM locales requiere generar nuevo material de clave dentro del HSM, distribuirlo a todos los sistemas o aplicaciones que utilizan la clave, volver a encapsular o cifrar las claves de cifrado de datos protegidas por la clave maestra anterior y archivar el material de clave anterior según su política de retención. Para las claves BYOK con material importado en un KMS en la nube, la rotación automática no está disponible; debe generar nuevo material en su HSM, exportarlo y volver a importarlo al KMS en la nube, designarlo como la versión principal y gestionar el cronograma de transición en todas las cargas de trabajo dependientes.

Rotación de claves privadas de CA para PKI: Los HSM que protegen las claves privadas de CA requieren un manejo especial para la rotación, ya que esta implica la emisión de un nuevo certificado de CA y la distribución del nuevo ancla de confianza a todas las partes que confían en la CA. La rotación de claves de CA es un evento PKI planificado, no una operación automatizada rutinaria, y requiere coordinación con todos los sistemas que confían en la CA. Los procedimientos de ceremonia de claves del HSM (control dual, autenticación de quórum M-de-N) se aplican a la generación de claves de CA.

Registro de auditoría para operaciones de HSM

Los registros de auditoría de HSM son un requisito de cumplimiento según PCI DSS, FedRAMP, HIPAA y la mayoría de los demás marcos que especifican controles criptográficos. El registro debe capturar cada operación administrativa (creación de particiones, creación de claves, eliminación de claves, cambios de política) y cada operación criptográfica (firma, verificación, cifrado, descifrado, encapsulado, desencapsulado) realizada por o a través del HSM, vinculada a una identidad autenticada.

Registro de auditoría de HSM locales: Los HSM físicos generan registros de auditoría internamente y pueden enviarlos a un servidor SIEM o syslog. El propio HSM firma el registro de auditoría para detectar manipulaciones. Garantizar que los registros de auditoría se envíen a un almacén de registros a prueba de manipulaciones antes de que se llene el registro interno del HSM es un requisito operativo que los equipos de HSM locales deben gestionar explícitamente.

Registro de auditoría de HSM en la nube: Los servicios HSM y KMS en la nube se integran con el registro de auditoría nativo del proveedor de la nube. En AWS, cada llamada a la API de KMS aparece en CloudTrail, incluyendo la identidad solicitante, el ARN de la clave, el tipo de operación y la marca de tiempo. En Azure, las operaciones de Key Vault y HSM dedicado se registran en Azure Monitor. En GCP, las operaciones de KMS y HSM en la nube aparecen en los registros de auditoría de la nube. Los registros de auditoría de la nube son automáticamente a prueba de manipulaciones (el proveedor mantiene la integridad de los registros) y se enrutan fácilmente a las plataformas SIEM mediante integraciones nativas.

Se generarán alertas sobre los siguientes eventos de auditoría de HSM, independientemente del modelo de implementación: cualquier eliminación de clave o programación de eliminación; cualquier cambio de política en una clave o partición de alto valor; cualquier operación criptográfica realizada por una identidad que no se encuentre en la lista de roles de aplicación aprobados; cualquier intento de autenticación fallido contra el HSM; y cualquier intento de exportar material de clave desde una partición configurada como no exportable.

Arquitectura HSM multi-nube

Las organizaciones que operan con múltiples proveedores de nube se enfrentan a un desafío específico en materia de HSM: el servicio HSM dedicado de cada proveedor de nube está limitado a la infraestructura de ese proveedor, y los servicios HSM de los proveedores de nube no se federan entre proveedores. Una instancia de AWS CloudHSM no puede servir directamente cargas de trabajo de GCP, y un HSM dedicado de Azure no puede generar claves para la importación de AWS KMS sin herramientas adicionales. Tres patrones abordan la arquitectura HSM multi-nube:

• HSM local como autoridad clave central: Un clúster HSM local actúa como autoridad maestra de generación y almacenamiento de claves para todos los entornos. Las claves generadas en el HSM local se exportan (encapsulan) y se importan al KMS de cada proveedor de nube como claves BYOK. El HSM local es la fuente autorizada de todo el material de claves; los servicios KMS del proveedor de nube son consumidores de dicho material. Este modelo proporciona el control centralizado más sólido, pero requiere que el HSM local tenga alta disponibilidad y sea accesible para todos los entornos de nube.
• HSM como servicio de terceros que abarca proveedores de nube: Un servicio HSM de terceros, independiente de los tres principales proveedores de nube, proporciona una infraestructura HSM centralizada accesible para cargas de trabajo en todos los entornos de nube. El servicio HSM genera claves y las pone a disposición de las aplicaciones en cualquier nube a través de una API unificada. Esto elimina el problema de los silos HSM por proveedor sin necesidad de hardware local y sirve como fuente de generación de claves para BYOK en todos los proveedores de nube. HSM como servicio Este modelo cuenta con una infraestructura HSM FIPS 140-2 de nivel 3, accesible en entornos de nube.
• HSM dedicado por nube con gobernanza de claves centralizada: Implemente un servicio HSM dedicado en la nube en cada proveedor (AWS CloudHSM en AWS, Azure Dedicated HSM en Azure) y adminístrelos como autoridades de clave independientes para las cargas de trabajo en cada nube. Utilice una plataforma centralizada de gobernanza de claves para mantener la visibilidad de todas las claves en todas las instancias de HSM, aplicar políticas de claves coherentes y agregar los registros de auditoría. Este modelo es el más complejo operativamente, pero evita las dependencias de red entre nubes para las operaciones criptográficas.

Consideraciones de cumplimiento para la implementación de HSM

Los distintos marcos de cumplimiento especifican diferentes requisitos para los HSM. Adaptar la implementación de sus HSM al lenguaje específico de los requisitos evita tanto el incumplimiento (utilizar el Nivel 2 donde se requiere el Nivel 3) como la sobreinversión (implementar HSM locales cuando un servicio de HSM gestionado en la nube satisface el requisito).

PCI DSS v4.0.1 (obligatorio desde el 31 de marzo de 2025): Requiere que las claves criptográficas utilizadas para proteger los datos de los titulares de tarjetas se almacenen en la menor cantidad de ubicaciones posible. Los procesos de gestión de claves deben incluir la protección de las claves contra la divulgación y el uso indebido (Requisito 3.7.1). Los HSM se mencionan explícitamente como una tecnología de gestión de claves aceptable. PCI DSS no requiere un nivel FIPS específico para el HSM, pero sí requiere que el sistema de gestión de claves sea seguro y auditado. Los servicios HSM en la nube utilizados para el alcance de PCI deben estar dentro de la infraestructura certificada PCI DSS del proveedor.

FedRAMP (NIST SP 800-53 Rev. 5): El control SC-12 (Establecimiento y gestión de claves criptográficas) exige que las claves se produzcan, controlen y distribuyan utilizando tecnología de gestión de claves aprobada por la NSA o recomendada por el NIST. FedRAMP High también exige módulos criptográficos validados según FIPS 140-2 o FIPS 140-3 Nivel 3. AWS CloudHSM, Azure Dedicated HSM y GCP Cloud HSM con nivel de protección HSM cumplen este requisito. Los servicios KMS estándar en la nube compartida con FIPS 140-2 Nivel 2 no cumplen el requisito de Nivel 3 de FedRAMP High.

eIDAS y firmas cualificadas (UE): Las firmas electrónicas cualificadas según eIDAS requieren dispositivos cualificados para la creación de firmas (QSCD), que deben cumplir requisitos al menos equivalentes al nivel 3 de FIPS 140-2 o a los Criterios Comunes EAL4+. Para las organizaciones de la UE que emiten certificados o firmas cualificadas, se requieren módulos de seguridad de hardware (HSM) locales o HSM dedicados en la nube ubicados en la UE con las validaciones adecuadas.

HIPAA: No prescribe un requisito específico de HSM, pero exige medidas de seguridad adecuadas para las claves de cifrado que protegen la información médica electrónica protegida (ePHI). Un servicio HSM en la nube con controles de acceso documentados, registro de auditoría y un Acuerdo de Asociado Comercial (BAA) firmado con el proveedor cumple con los requisitos de seguridad técnica de HIPAA para la protección de claves.

Guía de decisiones para la implementación de HSM

Utilice los siguientes criterios para identificar el modelo de implementación de HSM adecuado para los requisitos de su organización.

1. Identifique sus requisitos de latencia: Si su aplicación requiere tiempos de respuesta de HSM inferiores a un milisegundo, la única opción es un HSM local. Si puede tolerar tiempos de respuesta de entre 1 y 10 milisegundos, los servicios de HSM en la nube son una alternativa viable.
2. Identifique su requisito de nivel FIPS: Si se requiere el nivel 3 de FIPS 140-2 (FedRAMP High, algunos PCI, calificados por eIDAS), verifique que el servicio en la nube específico que está evaluando cumpla con el nivel 3, no solo con el nivel 2. Los servicios KMS en la nube compartida varían según el proveedor y el nivel.
3. Identifique su modelo de control clave: Si la gestión de claves nativa del proveedor es aceptable, utilice el KMS compartido del proveedor de la nube con protección HSM. Si se requiere BYOK (Bring Your Own Key), necesitará un HSM local o un HSM dedicado en la nube para generar el material de clave. Si se requiere HYOK (Hyper Your Own Key), necesitará un HSM que opere completamente fuera del proveedor de la nube que almacena sus datos.
4. Identifique sus requisitos de soberanía de datos: Si las regulaciones exigen que las claves nunca salgan de un país o instalación específicos, y no existe ningún servicio HSM en la nube que opere en esa ubicación, se requiere un HSM local. Si existe un servicio HSM en la nube que opere en la jurisdicción requerida, verifique las garantías contractuales de residencia de datos.
5. Identifique su estrategia multi-nube: Si opera con varios proveedores de nube y necesita una gobernanza de claves centralizada, evalúe un HSM como servicio de terceros o un clúster de HSM local como autoridad central de claves.
6. Calcular el coste total de propiedad: Compare los costos iniciales de hardware y operación de las soluciones locales con los precios por hora de los HSM en la nube, según su volumen de transacciones previsto. Para volúmenes bajos o moderados, los HSM en la nube ofrecen un menor costo total de propiedad (TCO). Para tasas de transacciones criptográficas muy altas (millones de operaciones por hora), el hardware local dedicado puede resultar más rentable.
7. Evaluar la capacidad operativa: La gestión de seguridad de hardware (HSM) local requiere personal con experiencia específica en HSM para su operación y mantenimiento. Los servicios de HSM en la nube reducen, pero no eliminan, este requisito. Si su organización no cuenta con personal especializado en operaciones de HSM, un servicio de HSM gestionado en la nube o una solución de HSM como servicio (HSM-as-Service) de un proveedor especializado reduce significativamente el riesgo operativo.

Cómo puede ayudar la consultoría de cifrado

Encryption Consulting es una empresa de criptografía aplicada con certificaciones ISO/IEC 27001:2022 y SOC 2. Ayudamos a las organizaciones a seleccionar, implementar y operar infraestructura HSM tanto para entornos en la nube como locales, desde la evaluación inicial de requisitos hasta la generación continua de evidencia de cumplimiento.

• HSM como servicio: Consultoría de cifrado HSM como servicio Proporciona infraestructura HSM dedicada con certificación FIPS 140-2 Nivel 3 como servicio gestionado, accesible para cargas de trabajo en diversos proveedores de nube y entornos locales. Ideal como fuente de generación de claves BYOK y HYOK, como autoridad de claves centralizada para múltiples nubes y como alternativa gestionada al despliegue y operación de hardware HSM local. Cuenta con el respaldo de operaciones certificadas según la norma ISO/IEC 27001:2022.
• Infraestructura de clave pública como servicio: Para las organizaciones que utilizan HSM para proteger las claves privadas de CA, Encryption Consulting ofrece PKI como servicio Proporciona una CA privada totalmente administrada con almacenamiento de claves de CA respaldado por HSM, emisión automatizada de certificados ACME e integración con las principales plataformas en la nube. Elimina la necesidad de operar HSM locales exclusivamente para la protección de claves de CA de PKI.
• Servicios de asesoramiento e implementación de HSM: Si está implementando HSM locales o evaluando servicios HSM en la nube, Encryption Consulting Servicios HSM Abarca la selección y el dimensionamiento de HSM, el diseño de clústeres de alta disponibilidad, la integración de PKCS#11 y la API REST con las aplicaciones, los procedimientos de la ceremonia de claves para la generación de claves raíz de CA, la documentación de cumplimiento de FIPS y el soporte operativo continuo.
• CBOM Seguro: Consultoría de cifrado CBOM seguro Descubre e inventaría todos los activos criptográficos en sus entornos locales y en la nube, incluidas las claves respaldadas por HSM, las claves KMS en la nube y los certificados. Proporciona una lista de materiales criptográficos (CBOM) en formato CycloneDX que identifica las claves sin protección HSM, las claves próximas a vencer y las claves que utilizan algoritmos obsoletos.
• Preparación para PQC: El NIST finalizó los estándares de criptografía post-cuántica FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) y FIPS 205 (SLH-DSA) en agosto de 2024. El NIST IR 8547 apunta a la desaprobación de RSA y ECC para nuevos usos alrededor de 2030. Los HSM deben admitir algoritmos post-cuánticos antes de esa transición, y no todo el hardware HSM actual se podrá actualizar solo mediante firmware. Preparación para PQC El servicio evalúa la ruta de migración post-cuántica de su infraestructura HSM y diseña la secuencia de actualización o reemplazo de HSM.

Para hablar sobre sus requisitos de implementación de HSM, póngase en contacto con Encryption Consulting.

Conclusión

Los HSM basados ​​en la nube y los locales utilizan la misma tecnología de hardware criptográfico validada. El modelo de implementación determina quién opera el hardware, qué latencia y estructura de costos se aplican, y cómo se integra el HSM en su modelo de control de claves (nativo, BYOK o HYOK). Para la mayoría de las organizaciones, los servicios HSM en la nube, en particular los servicios dedicados de un solo inquilino, ofrecen una seguridad equivalente a la de los HSM locales con una sobrecarga operativa y un costo total de propiedad significativamente menores. Los HSM locales siguen siendo la opción adecuada para requisitos de latencia inferiores a un milisegundo, entornos aislados de la red y jurisdicciones donde ningún servicio HSM en la nube cumple con los requisitos de localización de datos.

La decisión no es puramente binaria. Muchas organizaciones combinan modelos: un HSM local o de terceros como autoridad de generación de claves BYOK, servicios KMS en la nube como capa operativa de gestión de claves para cargas de trabajo en la nube, y servicios HSM en la nube para cargas de trabajo específicas de alta seguridad que requieren FIPS 140-2 Nivel 3 dentro del entorno de la nube. Diseñar correctamente esa arquitectura y mantener el modelo IAM, el calendario de rotación y el registro de auditoría en todas las capas es donde reside la verdadera complejidad operativa.

Preguntas frecuentes

¿Cuál es la diferencia entre los HSM basados ​​en la nube y los HSM locales?

Los HSM basados ​​en la nube son módulos de seguridad de hardware con certificación FIPS, operados por un proveedor de servicios en la nube o un servicio de terceros en un centro de datos remoto, con acceso a través de una API de red. Los HSM locales son dispositivos físicos instalados en sus propias instalaciones. Ambos utilizan el mismo hardware criptográfico subyacente y pueden obtener la certificación FIPS 140-2 Nivel 3. La principal diferencia radica en quién opera el hardware, quién tiene acceso físico, cuál es el perfil de latencia y si los costos son de capital u operativos.

¿Qué es más seguro: los módulos de seguridad de hardware (HSM) basados ​​en la nube o los HSM locales?

Ambos pueden obtener la validación FIPS 140-2 Nivel 3. La seguridad depende más de la configuración de la implementación y las prácticas de gestión de claves que del modelo de implementación. La implementación local otorga a su organización la custodia física de las claves. Los servicios HSM en la nube dedicados y bien configurados ofrecen una seguridad comparable o superior a la de los clústeres locales con un mantenimiento deficiente. El perfil de riesgo de un HSM en la nube dedicado de un solo inquilino de un proveedor importante es comparable al de un HSM local para la mayoría de los modelos de amenazas.

¿Qué es BYOK y cómo se relaciona con la elección de HSM?

BYOK (Bring Your Own Key) implica generar el material de clave de cifrado en su propio HSM e importarlo al KMS de un proveedor de nube. Un HSM local o un HSM dedicado en la nube sirve como fuente de generación de claves BYOK. El proveedor de nube utiliza el material importado para las operaciones de cifrado, pero usted conserva la fuente. HYOK va más allá: la clave nunca ingresa a la infraestructura del proveedor de nube, lo que requiere cifrado del lado del cliente con una clave administrada completamente en su propio HSM.

¿Cuál es el costo de un HSM basado en la nube en comparación con un HSM local?

AWS CloudHSM cobra aproximadamente $1.45 por hora por instancia, alrededor de $1,040 por mes por una sola instancia o $2,100 por mes para un clúster HA de dos instancias. Los HSM locales requieren una inversión inicial de entre $20,000 y $40,000 o más por dispositivo, además de las licencias de software de administración, los costos del centro de datos y el tiempo del personal. Cloud HSM tiene un costo total de propiedad (TCO) menor para volúmenes bajos a moderados. Las soluciones locales pueden resultar más rentables para tasas de transacciones criptográficas muy altas, donde el costo de las llamadas a la API se acumula significativamente.

¿Los módulos HSM en la nube son compatibles con FIPS 140-2 Nivel 3?

Los servicios HSM dedicados en la nube sí lo hacen: AWS CloudHSM utiliza hardware Luna Network HSM con certificación FIPS 140-2 Nivel 3, Azure Dedicated HSM utiliza Entrust nShield Connect con certificación Nivel 3, y GCP Cloud HSM proporciona protección de Nivel 3 para claves respaldadas por HSM. Los servicios KMS compartidos en la nube sin una capa HSM dedicada utilizan el Nivel 2, no el Nivel 3. Siempre verifique la capa de servicio y el nivel de protección exactos cuando el Nivel 3 sea un requisito de cumplimiento específico.

¿Cuándo debería una organización optar por módulos de seguridad de hardware (HSM) locales en lugar de HSM en la nube?

Elija la solución local cuando: la aplicación requiera tiempos de respuesta criptográfica inferiores al milisegundo que una API en la nube no pueda cumplir; los requisitos normativos exijan que las claves permanezcan en una ubicación física o jurisdicción específica sin un servicio HSM en la nube disponible; el entorno esté aislado sin conexión a internet; o el volumen de transacciones criptográficas sea tan elevado que el precio de las llamadas a la API en la nube supere el coste del hardware propio. Para la mayoría de los demás casos de uso, los servicios HSM en la nube ofrecen una seguridad equivalente con una menor sobrecarga operativa.