HSM basados ​​en la nube vs. locales

Publicado: 22 de enero de 2020. Actualizado: agosto de 2026. Revisado por el equipo de asesoría de HSM de Encryption Consulting.

¿Qué es un HSM y por qué es importante el modelo de implementación?

La adopción de la infraestructura de clave pública (PKI) ha ido en aumento de forma constante en todos los sectores industriales. Mecanismos como la autenticación basada en certificados, la comunicación cifrada, la gestión de certificados y la firma de código se combinan para mantener la seguridad de una empresa. Sin embargo, todas las ventajas que ofrece la PKI y cualquier sistema criptográfico pueden verse comprometidas si las claves privadas que la sustentan se ven afectadas. El almacenamiento y la gestión seguros de estas claves son factores críticos para el éxito y, a la vez, el principal punto de fallo en cualquier sistema criptográfico. Este es el problema que resuelve un módulo de seguridad de hardware (HSM) .

Un HSM es un dispositivo certificado, dedicado y a prueba de manipulaciones, diseñado para el ciclo de vida completo de las claves criptográficas: generación, almacenamiento, gestión e intercambio. Los HSM también descargan las operaciones criptográficas de los servidores de aplicaciones, incluyendo la autenticación, el cifrado , el descifrado y la firma digital. Mientras que el hardware de servidor de propósito general puede firmar unos pocos miles de transacciones por segundo, un HSM diseñado específicamente para este fin puede firmar millones, a la vez que proporciona resistencia a manipulaciones físicas y lógicas certificadas, registro de eventos y API seguras.

Tradicionalmente, los HSM se implementaban localmente en un centro de datos empresarial. La computación en la nube cambió esto. Hoy en día, la funcionalidad HSM también está disponible como "HSM en la nube" o "HSM como servicio", ofrecido desde la infraestructura de un proveedor de nube o un servicio especializado de terceros. La tecnología criptográfica en ambos modelos es prácticamente la misma; lo que cambia es quién controla el dispositivo físico, quién comparte el hardware subyacente y cómo se factura y opera el servicio. Esta diferencia es precisamente la razón por la que la verdadera pregunta es "¿qué modelo de implementación se adapta mejor a su organización?", más que "¿qué HSM es mejor?".

¿Qué niveles de validación FIPS son importantes para la selección de HSM?

Cualquier HSM, ya sea local o en la nube, debe estar certificado según estándares reconocidos como los Criterios Comunes y los Estándares Federales de Procesamiento de Información (FIPS) emitidos por el NIST. FIPS 140 define los requisitos de seguridad para módulos criptográficos en cuatro niveles crecientes de protección física y lógica, desde el Nivel 1 (algoritmos básicos aprobados, sin seguridad física dedicada) hasta el Nivel 4 (el módulo responde activamente a manipulaciones físicas y ataques ambientales). La mayoría de los HSM empresariales utilizados para PKI, firma de código y gestión de claves están dirigidos al Nivel 2 o al Nivel 3.

FIPS 140-3 es la versión actual del estándar y ya ha sucedido a FIPS 140-2. Según el Programa de Validación de Módulos Criptográficos (CMVP) del NIST, FIPS 140-3 entró en vigor el 22 de septiembre de 2019, y el CMVP dejó de aceptar nuevas solicitudes de FIPS 140-2 el 1 de abril de 2022. Los certificados FIPS 140-2 existentes siguen siendo utilizables para los sistemas actualmente implementados, pero todos los certificados FIPS 140-2 pasarán a la lista histórica del CMVP el 21 de septiembre de 2026. Después de esa fecha, las agencias y organizaciones reguladas deben considerar la validación FIPS 140-2 como un estado heredado para las nuevas adquisiciones, y cualquier HSM adquirido en adelante debe contar con un certificado FIPS 140-3 activo al nivel que requiera su programa de cumplimiento. Consulte nuestra guía de transición a FIPS 140-3 para obtener un desglose completo de los cambios y las personas afectadas.

Más allá del nivel de certificación, evalúe los algoritmos que admite un HSM. Debe ser compatible con los algoritmos simétricos y asimétricos que sus aplicaciones utilizan (AES, RSA, ECC) y, cada vez más, con la criptoagilidad para algoritmos post-cuánticos como ML-KEM y ML-DSA, para que el dispositivo no se convierta en un obstáculo para la migración en el futuro. La certificación demuestra que el dispositivo cumple con un requisito básico; sin embargo, no es, por sí sola, una justificación suficiente para su compra.

¿En qué se diferencian los modelos de amenazas entre los HSM en la nube y los HSM locales?

La certificación de seguridad indica que el dispositivo en sí es seguro. No indica quién puede acceder a él, quién más lo usa ni quién controla en última instancia las claves que contiene, y ahí es donde los dos modelos de implementación realmente divergen.

Custodia física. Un HSM local se ubica en un centro de datos controlado por su organización, sujeto a sus políticas de acceso físico, registros de credenciales y procedimientos de acompañamiento. El hardware físico de un HSM en la nube se encuentra en una instalación controlada por el proveedor. Los proveedores de renombre aplican estrictos controles físicos y de personal, pero la cadena de custodia física ya no está completamente bajo su control, lo cual es importante para las organizaciones con requisitos regulatorios o contractuales que exigen un control físico exclusivo y demostrable de material clave.

Multitenencia. Las soluciones HSM en la nube se dividen en dos categorías: instancias de un solo inquilino (dedicadas), donde su organización es el único cliente que utiliza ese dispositivo físico, y servicios multiinquilino, donde el hardware subyacente puede estar lógicamente particionado entre varios clientes. Los modelos multiinquilino suelen ser más económicos y fáciles de implementar, pero conllevan un riesgo de infraestructura compartida: una vulnerabilidad en la capa de particionamiento o administración podría, en teoría, exponer a más de un inquilino. Las instancias HSM dedicadas en la nube (a veces comercializadas como "HSM como servicio" con garantías de un solo inquilino) solucionan la mayor parte de este problema, eliminando al mismo tiempo la necesidad de hardware local.

Custodia y control de claves. La pregunta clave es: ¿quién puede acceder, exportar o duplicar sus claves, y bajo qué proceso legal? Los HSM locales mantienen esta autoridad completamente dentro de la ceremonia de claves y los controles de quórum de su organización. Los servicios HSM en la nube varían: algunos están diseñados de manera que el proveedor no tenga acceso al material de clave no cifrado (claves en poder del cliente, el proveedor no puede extraerlas), mientras que otros conservan el acceso administrativo bajo condiciones específicas definidas en el contrato de servicio. Lea atentamente el modelo de custodia de claves del proveedor y cualquier disposición sobre acceso gubernamental antes de considerar un HSM en la nube como equivalente a un dispositivo local a efectos regulatorios.

¿Cuáles son las ventajas y desventajas en términos de rendimiento e interoperabilidad?

Latencia. Un HSM local ubicado en el mismo centro de datos o rack que la aplicación que realiza la llamada evita por completo los viajes de ida y vuelta de la red. Para la firma de transacciones de alto volumen, los procesos de firma de código o el cifrado de bases de datos, donde cada milisegundo se acumula en millones de operaciones, esa proximidad local puede ser decisiva. Un HSM en la nube introduce latencia de red entre la aplicación y el punto final del servicio; esto es manejable para la mayoría de las cargas de trabajo, pero debe someterse a pruebas de carga con el patrón de tráfico real, en lugar de ignorarlo.

Rendimiento. Ambos modelos ofrecen un alto rendimiento en transacciones, pero los dispositivos locales permiten aprovisionar hardware dedicado dimensionado con precisión para una carga máxima conocida, mientras que el rendimiento de los HSM en la nube puede ser compartido, medido o limitado según el nivel de servicio. Las organizaciones con cargas de trabajo impredecibles o intermitentes suelen encontrar que la elasticidad del modelo en la nube compensa un pequeño coste de latencia; las organizaciones con cargas de trabajo constantes, predecibles y de volumen extremadamente alto suelen encontrar que la capacidad local dedicada es más rentable por transacción.

Integración con la infraestructura de clave pública (PKI) y la gestión de claves existentes. Un módulo de seguridad de hardware (HSM) rara vez funciona de forma aislada. Necesita integrarse con su autoridad de certificación (CA), su sistema de gestión de claves (KMS) y cualquier aplicación que realice firmas o descifrados. Los HSM locales suelen exponer interfaces estándar como PKCS#11, KMIP y API específicas del proveedor que el software de CA establecido (incluido Microsoft AD CS) ya admite. Las soluciones de HSM y KMS en la nube se integran estrechamente con el ecosistema de su propio proveedor (identidad, almacenamiento, computación), pero pueden requerir ingeniería adicional para conectarse a una PKI local existente o a una estrategia de gestión de claves multi-nube. Confirme la compatibilidad de integración con su plataforma de CA específica, KMS y cualquier requisito multi-nube antes de comprometerse.

¿Cómo son en la práctica las implementaciones de HSM en la nube y las implementaciones de HSM locales?

Ejemplo de HSM como servicio: Una empresa SaaS de tamaño mediano necesita firmar certificados TLS para clientes y proteger las claves de cifrado de aplicaciones, pero no cuenta con un equipo interno para instalar, actualizar y mantener los dispositivos físicos. Para ello, aprovisionan una instancia de HSM en la nube dedicada (de un solo inquilino) de su proveedor principal de nube, la integran con su plataforma de gestión del ciclo de vida de certificados existente mediante API estándar y escalan la capacidad durante los picos de tráfico sin necesidad de adquirir nuevo hardware.

Ejemplo de dispositivo local: Un banco nacional opera una jerarquía de Autoridad de Certificación raíz y emisora ​​que debe cumplir con estrictas reglas de localización de datos y requisitos de auditoría interna para la custodia física exclusiva de las claves. Implementan dispositivos HSM locales en clúster dentro de sus propios centros de datos, con una ceremonia de clave M-of-N que controla la generación de la clave raíz y un proceso documentado y probado de respaldo y alta disponibilidad. Consulte nuestra guía sobre clústeres HSM y alta disponibilidad para saber cómo diseñar esta separación entre disponibilidad y durabilidad de las claves.

Ejemplo híbrido: Un fabricante global mantiene su CA raíz en un HSM local para un control máximo, mientras que emite certificados de corta duración para cargas de trabajo nativas de la nube a través de un KMS en la nube, respaldado a su vez por hardware HSM en la nube e integrado a través de su proveedor PKIaaS. Esto les permite mantener la raíz de confianza bajo custodia física directa, al tiempo que obtienen la elasticidad nativa de la nube para la emisión de grandes volúmenes.

¿Qué dependencias clave de gestión debería tener en cuenta?

Independientemente del modelo que elija, existen varias dependencias operativas que deben planificarse antes de la implementación, no después:

• Ceremonia de entrega de llaves: Las claves raíz y de alto valor deben generarse mediante una ceremonia documentada y presenciada con control de quórum M-of-N, independientemente de si el HSM se encuentra en las instalaciones o si la ceremonia se realiza en una instancia de nube dedicada.
• Copia de seguridad y alta disponibilidad (HA): Las copias de seguridad clave deben realizarse en un entorno con controles de seguridad equivalentes a los del propio HSM. Las implementaciones locales requieren una estrategia de copia de seguridad y agrupación en clústeres probada y geográficamente separada; los servicios HSM en la nube suelen ofrecer alta disponibilidad y copias de seguridad integradas, pero conviene verificar qué cubre el acuerdo de nivel de servicio (SLA) del proveedor y qué responsabilidad recae sobre el usuario.
• Integración de KMS con un proveedor de nube frente a un HSM dedicado: Un KMS en la nube es una capa de gestión de claves administrada que puede estar respaldada por hardware HSM compartido o dedicado. Un HSM dedicado en la nube ofrece un control más directo sobre el dispositivo subyacente. Es fundamental comprender qué tipo de HSM ofrece un servicio en la nube antes de asumir su responsabilidad.
• Generación de números aleatorios: Confirme que el proveedor del HSM utiliza un proceso aprobado y certificado para la generación de números aleatorios, ya que la entropía débil socava todas las claves que produce el dispositivo, independientemente del modelo de implementación.
• Costo total de propiedad (TCO): Los HSM locales requieren una mayor inversión inicial (Capex) y, por lo general, menores costos operativos. Los HSM en la nube trasladan el gasto a los costos operativos (Opex): poca o ninguna inversión inicial, pero costos de servicio recurrentes. Compare el costo total de propiedad (TCO) en un horizonte de tres a cinco años, incluyendo los costos de hardware, infraestructura de red y seguridad, personal, capacitación, soporte y cumplimiento, y no solo el precio de venta de cada modelo.

¿Cómo elegir entre un HSM en la nube y un HSM local?

Utilice esta secuencia para llegar a una decisión justificable en lugar de una basada en preferencias:

1. Evaluar los requisitos de custodia de llaves. Determine si sus obligaciones normativas, contractuales o de política interna requieren la custodia física exclusiva y demostrable del material clave, o si es aceptable un modelo gestionado por el proveedor con garantías claras de custodia de claves.
2. Mapea tus factores de cumplimiento. Identifique el nivel de validación FIPS 140-3 específico, las reglas de residencia de datos y los mandatos de la industria (como PCI DSS, HIPAA o FedRAMP) que se aplican, y confirme qué modelos de implementación pueden cumplirlos actualmente.
3. Cuantificar las necesidades de escala y latencia. Estime el volumen de transacciones, la trayectoria de crecimiento y la sensibilidad a la latencia de sus aplicaciones. Las cargas de trabajo predecibles, críticas en cuanto a latencia y de muy alto volumen se benefician de las soluciones locales; las cargas de trabajo variables o moderadas se benefician de los HSM en la nube.
4. Evaluar los requisitos de integración. Confirme que el HSM o KMS se integra con su CA, PKI y cualquier arquitectura híbrida o multinube existente sin necesidad de rediseñar la gestión del ciclo de vida de sus certificados.
5. Calcula el costo total de propiedad del modelo. Compare los elevados costes de las infraestructuras locales (Capex) con los precios de la nube basados ​​en gastos operativos (Opex) en un horizonte temporal realista de varios años.
6. Elija entre una solución local, en la nube o híbrida, y documente la decisión. Registre la justificación de los pasos 1 al 5 para que la elección pueda revalidarse a medida que cambien los requisitos.

Tabla de decisiones empresariales: HSM en la nube frente a HSM local según el escenario

Escenario	Modelo recomendado	Por qué
Industria regulada que requiere custodia total y demostrable de claves (banca, gobierno, defensa).	HSM local o un HSM en la nube dedicado para un solo inquilino	La custodia física exclusiva y el control de auditoría suelen ser un requisito de cumplimiento, no solo una preferencia.
Cargas de trabajo elásticas, mínimo personal operativo interno, rápido tiempo de implementación.	HSM como servicio (HSM en la nube)	Sin necesidad de adquirir hardware, con actualizaciones y alta disponibilidad gestionadas por el proveedor y precios de pago por uso.
Localización estricta de datos sin centro de datos en la nube local en esa jurisdicción.	HSM local	La ubicación física del material clave es un requisito indispensable que el proveedor de la nube quizás no pueda satisfacer localmente.
Estrategia multi-nube que requiere una gestión de claves coherente en todos los proveedores.	HSM en la nube de terceros o HSM como servicio	Evita la dependencia de un único proveedor de nube, al tiempo que ofrece una capa de gestión de claves coherente en todos los entornos.
Entorno híbrido: aplicaciones locales heredadas más cargas de trabajo nativas de la nube.	Híbrido: HSM raíz local más integración de KMS/HSM en la nube	Mantiene la raíz de confianza bajo custodia directa, al tiempo que proporciona a los servicios nativos de la nube una capacidad de emisión elástica.
Empresas emergentes o pymes que implementan PKI, firma de código o cifrado con un presupuesto de capital limitado.	HSM en la nube (HSM como servicio)	Baja inversión inicial, posibilidad de probar o cambiar de proveedor antes de comprometerse con el hardware.
Firma de transacciones de volumen extremadamente alto y con baja latencia (por ejemplo, firma de transacciones en tiempo real).	HSM local, ubicado junto con la aplicación.	Elimina la latencia de ida y vuelta de la red y permite dimensionar el hardware específicamente para cargas máximas.

Limitaciones

Esta guía proporciona un marco general de apoyo a la toma de decisiones, no una determinación de cumplimiento para su organización específica. El estado de validación FIPS 140-3 para modelos de productos específicos cambia con el tiempo; verifique siempre el certificado actual de un dispositivo en la lista de módulos validados por NIST CMVP antes de la compra. Las arquitecturas de custodia de claves de los proveedores de la nube, las garantías de multitenencia y los términos de SLA varían según el proveedor y cambian con las actualizaciones del producto; las categorías descritas aquí (inquilino único frente a multiinquilino, claves administradas por el proveedor frente a claves en poder del cliente) son patrones generales, no una declaración sobre la oferta actual de ningún proveedor en particular. Las comparaciones de costos son ilustrativas; los gastos de capital (Capex) y operativos (Opex) reales dependen de sus contratos específicos, descuentos por volumen e infraestructura existente. Las obligaciones regulatorias (residencia de datos, mandatos de la industria, disposiciones de acceso gubernamental) varían según la jurisdicción y el sector, y deben confirmarse con sus equipos legales y de cumplimiento antes de tomar una decisión final de implementación.

¿Qué recomendaría Encryption Consulting?

La mayoría de las empresas no eligen simplemente entre "nube" y "local" en abstracto; eligen cómo proteger claves específicas vinculadas a requisitos específicos de cumplimiento y rendimiento. Encryption Consulting suele recomendar comenzar con un ejercicio de mapeo de custodia de claves y cumplimiento (pasos 1 y 2 del proceso de decisión anterior) antes de evaluar cualquier producto específico. Para las organizaciones que necesitan actuar con rapidez sin un equipo interno de operaciones de HSM, nuestras ofertas de HSM como servicio y servicios HSM proporcionan protección de claves dedicada y validada según FIPS 140-3 con orientación de arquitectura independiente del proveedor, de modo que el modelo de implementación se adapta a su postura de cumplimiento y no al revés. Para las organizaciones que necesitan un enfoque mixto, ayudamos a diseñar arquitecturas híbridas que mantienen una raíz de confianza local a la vez que extienden la capacidad de emisión elástica a cargas de trabajo nativas de la nube y multinube.

Conclusión

No existe una respuesta universal a la pregunta de si elegir un HSM en la nube o un HSM local. Ambos modelos utilizan la misma base criptográfica certificada; la diferencia radica en quién mantiene la custodia física, cómo se escala la carga de trabajo y qué marco de cumplimiento rige la decisión. Las empresas que definen los requisitos de custodia de claves, las obligaciones de cumplimiento de FIPS 140-3 y la escala de la carga de trabajo antes de evaluar a los proveedores toman decisiones de implementación más acertadas que aquellas que se basan en el precio o la preferencia de marca. Lo que permanece constante independientemente del modelo es el requisito fundamental: las claves privadas que sustentan la estrategia de PKI y cifrado deben protegerse, y un HSM, ya sea local, en la nube o en ambos entornos, sigue siendo el mecanismo en el que confían las empresas para lograrlo.

Preguntas frecuentes

¿Cuál es la diferencia entre un HSM y un KMS? Un Módulo de Seguridad de Hardware (HSM) es el dispositivo físico o virtual que genera y almacena claves en hardware certificado y a prueba de manipulaciones. Un Sistema de Gestión de Claves (KMS) es la capa de software que administra las políticas de claves, la rotación, el control de acceso y el ciclo de vida, y suele estar respaldado por uno o más HSM. Es posible tener un KMS sin hardware HSM dedicado (claves protegidas por software), pero un HSM por sí solo, sin una capa KMS, aún requiere un proceso de gestión integrado.

¿Un HSM en la nube es tan seguro como un HSM local? El hardware criptográfico subyacente puede contar con la misma validación FIPS 140-3 en ambos modelos. La diferencia no radica en la certificación del dispositivo, sino en quién lo custodia físicamente y, en servicios multiusuario, en si el hardware es compartido. Un HSM en la nube dedicado, de un solo usuario y con un modelo de claves gestionadas por el cliente, puede cumplir con requisitos de seguridad comparables a los de un dispositivo local para muchas organizaciones; las entidades reguladas con estrictas normas de custodia física deben confirmar esto con sus requisitos de cumplimiento específicos antes de confiar únicamente en un HSM en la nube.

¿Qué nivel de validación FIPS necesito para mi HSM? La mayoría de los casos de uso de PKI empresarial, firma de código y gestión general de claves se basan en el nivel 2 o 3 de FIPS 140-3. El nivel 3 añade una detección de manipulación más estricta y controles de acceso basados ​​en la identidad, y es común para la protección de claves de CA raíz. Los entornos gubernamentales, de defensa y altamente regulados pueden requerir el nivel 3 o 4, o un producto validado específico de la lista CMVP actual; siempre confirme el nivel exacto que exige su marco de cumplimiento.

¿Puedo usar HSM locales y en la nube simultáneamente? Sí. Un modelo híbrido, que mantiene la raíz de confianza en un HSM local mientras se utiliza un HSM en la nube o la integración con KMS para emitir certificados y proteger las claves de cargas de trabajo nativas de la nube, es una arquitectura común y bien respaldada. Permite mantener las claves de mayor valor bajo custodia directa, a la vez que se aprovecha la elasticidad de la nube para operaciones de mayor volumen y menor riesgo.

¿Qué sucede con los HSM validados según FIPS 140-2 después de septiembre de 2026? El 21 de septiembre de 2026, el programa CMVP del NIST cambia el estado de todos los certificados FIPS 140-2 restantes a "Histórico". Los módulos FIPS 140-2 existentes y ya implementados generalmente pueden continuar en producción, pero el estado "Histórico" significa que el certificado ya no figura en la lista para la validación de nuevas adquisiciones, y las agencias federales, en particular, deben confirmar con sus propias directrices si se permite su uso continuado. Cualquier nueva compra de HSM a partir de esta fecha requerirá un certificado FIPS 140-3 activo.

Referencias

• NIST, FIPS 140-3: Requisitos de seguridad para módulos criptográficos
• NIST CSRC, Esfuerzo de transición de FIPS 140-3
• NIST CSRC, Lista de módulos validados por CMVP
• Consultoría en cifrado, FIPS 140-3: Lo que las organizaciones deben saber para septiembre de 2026