Módulos de seguridad de hardware - Gestión dedicada de claves criptográficas con AWS CloudHSM
Explicamos la gestión dedicada de claves criptográficas con AWS CloudHSM. Presentamos el uso exclusivo de un HSM de un solo inquilino, el control directo mediante PKCS#11 y JCE, la custodia de claves y los criterios de selección frente a KMS. También presentamos la migración a la generación hsm2m.medium, y la descarga de TLS y la integración con Oracle TDE.
Requisitos de la gestión de claves criptográficas y el lugar de CloudHSM
La gestión de claves criptográficas es la base de la seguridad de la información. En AWS hay dos opciones para confinar el material de claves en hardware: AWS KMS (Key Management Service) y AWS CloudHSM. A fecha de agosto de 2026, tanto KMS como la generación actual de CloudHSM en modo FIPS manejan el material de claves sobre HSM (Hardware Security Module) validados con FIPS 140-3 Level 3. KMS protege las claves con un conjunto de HSM validados con FIPS 140-3 Security Level 3, y el material de claves en texto sin cifrar nunca sale del límite del HSM ni se escribe en disco. Los clústeres de CloudHSM en modo FIPS también han obtenido la validación FIPS 140-3 Level 3 con la generación hsm2m.medium que se describe más adelante. Por lo tanto, el criterio anterior de «elegir el que tenga el nivel de validación más alto» ya no se puede utilizar para las decisiones de selección actuales. Hoy las diferencias están en si se dispone en exclusiva de hardware dedicado a las claves, hasta qué punto se controlan las claves directamente con sus propias manos y quién tiene la custodia (la parte gestora) de las claves. Lo que proporciona CloudHSM es un HSM de propósito general de un solo inquilino, y la generación, el almacenamiento y el uso de las claves dentro del clúster se completan íntegramente dentro del HSM. Los usuarios y los roles se gestionan en el propio sistema de autenticación del HSM, fuera de IAM, por lo que el ámbito de responsabilidad que asume usted se amplía en la misma medida. AWS se encarga del aprovisionamiento del hardware, de la aplicación de parches y del almacenamiento de las copias de seguridad cifradas, pero no puede acceder a las claves del HSM, y el contenido de las comunicaciones del plano de datos tampoco es visible para AWS. KMS, por su parte, es un servicio administrado multi-tenant en el que el servicio asume la creación de claves, la rotación y la disponibilidad. CloudHSM se convierte en candidato cuando los requisitos de cumplimiento o las políticas internas exigen «uso exclusivo de hardware dedicado a las claves» o «indicación explícita de dónde reside el material de claves y quién lo gestiona».
Migración a la generación hsm2m.medium y estado actual de la validación FIPS
Los tipos de HSM de CloudHSM están en pleno cambio de generación. A continuación se describe la situación a fecha de agosto de 2026. La nueva generación hsm2m.medium pasó a disponibilidad general el 20 de agosto de 2024, y a partir de abril de 2025 ya no se pueden crear clústeres nuevos con la generación anterior hsm1.medium en ninguna región. En enero de 2026 comenzó la migración automática por parte de CloudHSM, y hsm1.medium llegó al fin del soporte el 31 de marzo de 2026. La validación FIPS también se divide por generación. hsm1.medium estaba validado con el certificado FIPS 140-2 Level 3 #4218, pero pasó a la lista historical del CMVP el 4 de enero de 2026. hsm2m.medium está validado con el certificado FIPS 140-3 Level 3 #4703. Con hsm2m.medium también cambió el diseño. Al crear un clúster se puede elegir entre el modo FIPS y el modo no FIPS, y esta configuración no se puede cambiar después de la creación. Un clúster puede almacenar en total 16,666 claves, de las cuales hasta 3,333 pueden ser claves asimétricas. El cliente y el HSM se autentican mediante TLS mutuo, y su uso requiere Client SDK 5.9.0 o posterior. Hay dos vías de migración disponibles. Una es optar por la migración administrada por CloudHSM y hacer que el clúster existente cambie de generación. La otra es crear un nuevo clúster hsm2m.medium a partir de una copia de seguridad de hsm1.medium, realizar el cambio y después eliminar el clúster antiguo. Si se elige la primera, un requisito previo es que todas las conexiones de los últimos 7 días hayan usado Client SDK 5.9 o superior (5.13 o superior si se ejecuta Verify de ECDSA). Los demás requisitos previos son que el clúster esté en estado ACTIVE y que tenga 27 HSM o menos. Las copias de seguridad no se pueden restaurar entre el modo FIPS y el modo no FIPS. En cuanto a las generaciones, solo es posible una dirección, restaurar una copia de seguridad de hsm1.medium en un clúster hsm2m.medium en modo FIPS, y no se puede devolver una copia de seguridad de hsm2m.medium a un clúster hsm1.medium. Por lo tanto, no se puede seguir una vía como sustituir un clúster que se ha operado en modo no FIPS por uno en modo FIPS.
Configuración del clúster y API estándar
CloudHSM se gestiona por clústeres. Al crear un clúster, se especifican una VPC y subredes de su propia cuenta de AWS, y cada vez que se añade un HSM, CloudHSM coloca una ENI (Elastic Network Interface) en la subred especificada. El HSM en sí se encuentra en otra VPC propiedad de CloudHSM, y las aplicaciones se comunican con el HSM a través de esta ENI. A veces se explica que «el HSM se coloca dentro de su VPC», pero, en sentido estricto, lo único que aparece en su subred es la interfaz de red. Como un HSM y su ENI correspondiente se colocan en la misma AZ, se recomienda una configuración que prepare una subred por AZ y distribuya los HSM en dos o más AZ. Las claves se sincronizan automáticamente entre los HSM del clúster, por lo que, aunque se pierda un HSM, se pueden seguir usando las claves en los HSM restantes. En el lado de la aplicación, se instala Client SDK 5 para usar el HSM. La biblioteca PKCS#11 cumple con la versión 2.40 de PKCS#11 y permite manejar claves desde aplicaciones C/C++ y desde middleware compatible con HSM. Para Java se ofrece un proveedor construido sobre el marco de proveedores de JCE (Java Cryptography Extension), que permite operar las claves del HSM desde aplicaciones Java. Para Windows se ofrecen un proveedor CNG y un KSP (Key Storage Provider), y para el uso a través de OpenSSL están disponibles OpenSSL Dynamic Engine y OpenSSL Provider. Como todas son interfaces estándar del sector, los cambios en las aplicaciones existentes suelen limitarse a la configuración de conexión y a la especificación de las claves, y casi nunca es necesario reescribir el código criptográfico. Lo habitual es instalar el software cliente en instancias EC2 dentro de la VPC, pero no tiene por qué ser EC2 siempre que el entorno pueda llegar a la ENI del HSM. El tráfico de los clientes al HSM se permite con el grupo de seguridad que se genera al crear el clúster.
Elección entre CloudHSM y KMS - Cinco criterios de selección
Ahora que el nivel de validación FIPS ya no permite separar ambos servicios, la selección se decide con los cinco criterios siguientes. El primer criterio es el uso exclusivo de un solo inquilino. Con CloudHSM se ocupan en exclusiva HSM dedicados por horas, y las claves de ese hardware solo existen en su clúster. KMS comparte una flota de HSM multi-tenant operada por AWS. El segundo criterio es el control directo. CloudHSM es adecuado cuando es necesario invocar directamente los mecanismos del HSM mediante PKCS#11, JCE, CNG/KSP u OpenSSL, o cuando el middleware existente está diseñado partiendo de una conexión a un HSM. Las operaciones de KMS se realizan a través de la API de KMS y de las integraciones con cada servicio de AWS. El tercer criterio es la custodia de claves. En CloudHSM, usted mismo crea los usuarios y los roles, y también diseña como parte de su propia operación la realización y la restauración de las copias de seguridad. En el almacén de claves estándar de KMS, AWS asume el almacenamiento y la redundancia del material de claves. Como punto intermedio entre ambos, KMS ofrece tres tipos de almacén de claves. Con la denominación de la documentación actual, existe el habitual «almacén de claves estándar». Además, existe el «almacén de claves de AWS CloudHSM», que coloca el material de claves en su propio clúster de CloudHSM mientras las operaciones se realizan con la API de KMS. También existe el «almacén de claves externo», que coloca el material de claves en un sistema de gestión de claves fuera de AWS. Si se desea combinar el cifrado del lado del servidor de servicios de AWS como S3, EBS y RDS con HSM propios, la vía estándar es pasar por este almacén de claves de AWS CloudHSM. El cuarto criterio son los requisitos de cumplimiento específicos. Si un requisito solo se refiere a «un módulo validado con FIPS 140-3 Level 3», KMS por sí solo puede cumplirlo. La diferencia aparece cuando el requisito especifica el carácter de un solo inquilino, la posesión física exclusiva de las claves o la operación de HSM bajo un esquema de auditoría concreto. Se indica que los clústeres de CloudHSM en modo FIPS se pueden utilizar para cumplir los requisitos de PCI PIN, PCI-3DS y SOC2. Además, también es necesario comprobar que las premisas cambian según la región, por ejemplo, que en KMS los HSM de las regiones de China tienen la certificación de OSCCA y no la validación del CMVP. El quinto criterio es la responsabilidad operativa y la garantía de disponibilidad. En KMS, el servicio se encarga de la disponibilidad, la aplicación de parches y el escalado. En CloudHSM, el usuario se encarga del dimensionamiento del número de HSM, la distribución entre AZ, el procedimiento de restauración desde copias de seguridad y el seguimiento de Client SDK y de las generaciones de HSM. La estructura de precios también es muy diferente, como se describe más adelante, por lo que el orden práctico es comprobar con estos cinco criterios si «el uso exclusivo y el control directo son realmente requisitos» antes de elegir CloudHSM.
Descarga de TLS y cifrado de bases de datos
Un caso de uso representativo de CloudHSM es la descarga de TLS/SSL. Las claves privadas TLS de los servidores web (Nginx, Apache) se guardan dentro de CloudHSM, y las operaciones con la clave privada durante el handshake TLS se ejecutan dentro del HSM. Como la clave privada no se carga en la memoria ni en el disco del servidor, se puede evitar el riesgo de que la propia clave privada se extraiga aunque el servidor se vea comprometido. Para Nginx y Apache se documenta oficialmente una configuración que establece CloudHSM como OpenSSL Dynamic Engine, y para Tomcat de Java se ofrece un procedimiento de descarga de TLS a través de JSSE. En el cifrado de bases de datos, se puede gestionar con CloudHSM la clave maestra de cifrado de Oracle TDE (Transparent Data Encryption). Al especificar el cliente de CloudHSM como biblioteca PKCS#11 en la configuración de Oracle Database, las claves de cifrado de la base de datos quedan protegidas dentro del HSM. Además, también hay un procedimiento de configuración oficial para el uso que configura Windows Server como entidad de certificación y guarda la clave privada de la CA en el HSM. En todos estos casos, el centro del valor está en la propiedad de no sacar la clave del HSM, y en el lado de la aplicación basta con hacer referencia a la clave a través de API estándar.
Precios de CloudHSM
Los precios unitarios que se muestran aquí son los valores de las regiones de Norte de Virginia y Tokio a fecha de agosto de 2026, y los importes mensuales se calculan considerando un mes como 730 horas. En primer lugar, organizamos los ejes de facturación. Lo único que factura CloudHSM es el tiempo de funcionamiento de los HSM aprovisionados en el clúster. Las fracciones de menos de una hora también se facturan como una hora completa, y el precio unitario varía según la región. El precio unitario no cambia con el número de usuarios ni con el número de claves almacenadas. Además, la transferencia de datos de red hacia y desde el HSM se factura por separado con las tarifas normales de transferencia de datos. Por el contrario, un clúster sin ningún HSM y el almacenamiento de las copias de seguridad cifradas que CloudHSM toma automáticamente no tienen coste. El precio unitario por cada hsm2m.medium es de 1.60 USD por hora en Norte de Virginia y de 1.81 USD por hora en Tokio. Con el cálculo de 730 horas, por cada HSM resulta en unos 1,168 USD en Norte de Virginia y unos 1,321 USD en Tokio. En una configuración de alta disponibilidad que coloca un HSM en cada una de dos AZ, el importe mensual es de unos 2,336 USD en Norte de Virginia y de unos 2,643 USD en Tokio. Como el precio unitario varía según la región, compruebe por separado los valores de la región de destino al hacer estimaciones. En cuanto a la facturación mínima y la capa gratuita, CloudHSM no tiene capa gratuita, y tampoco se ofrecen descuentos por pago anticipado como las instancias reservadas. Por otro lado, para usos que no necesitan funcionar de forma continua, como los clústeres de prueba, se indica como medida de coste reducir los HSM a cero durante los periodos sin uso y reanudar restaurando desde una copia de seguridad. Los precios de KMS son básicamente de 1 USD por clave al mes (prorrateado por horas) y 0.03 USD por cada 10,000 solicitudes, y se aplica una capa gratuita de 20,000 solicitudes al mes sumando todas las regiones. Sin embargo, GenerateDataKeyPair y GenerateDataKeyPairWithoutPlaintext, así como Sign, Verify, Encrypt, Decrypt y GetPublicKey sobre claves asimétricas, quedan fuera de la capa gratuita. En una configuración que usa un almacén de claves de AWS CloudHSM, se acumulan ambos precios. En el ejemplo publicado en la página oficial de precios de KMS, una clave, unos 1.99 millones de solicitudes facturables y dos HSM funcionando durante 31 días suman 2,387.77 USD al mes, de los cuales 2,380.80 USD corresponden al precio de funcionamiento de los HSM. En este desglose se puede ver que el coste de los HSM dedicados domina el conjunto de la configuración.
Responsabilidades operativas de la gestión dedicada
La mayor característica de CloudHSM es que permite colocar las claves criptográficas completamente bajo el control de su propia organización, pero eso significa al mismo tiempo que su organización asume la responsabilidad de la disponibilidad y las copias de seguridad de las claves. En un servicio administrado de gestión de claves, el servicio asume la redundancia y las copias de seguridad de las claves, pero con HSM dedicados es necesario realizar ese diseño por cuenta propia. Si se pierde una clave, ya no se pueden descifrar los datos cifrados con ella, por lo que es imprescindible colocar los clústeres de forma redundante en varias AZ y operar copias de seguridad seguras de las claves. El ámbito de responsabilidad no se limita a la disponibilidad de las claves. Los usuarios y los roles del HSM se gestionan fuera de IAM, por lo que también es necesario establecer procedimientos propios para emitir y revocar credenciales y para revisar los permisos. Las copias de seguridad no se pueden restaurar entre el modo FIPS y el modo no FIPS, y las generaciones están limitadas a una sola dirección, de hsm1.medium a hsm2m.medium. Por ello, los procedimientos de recuperación ante desastres deben redactarse partiendo de la generación y el modo que se usan actualmente. Además, el trabajo de seguir las generaciones de HSM y las versiones de Client SDK, como la migración de hsm1.medium a hsm2m.medium, también surge periódicamente. A cambio de obtener el control completo, surge la responsabilidad de mantenerlo. Al elegir la gestión dedicada, es importante determinar si se cuenta con un equipo capaz de asumir esta carga operativa.
Resumen - Pautas para usar CloudHSM
AWS CloudHSM es el servicio que se elige cuando se desea gestionar las claves criptográficas con el uso exclusivo de hardware de un solo inquilino. Tanto KMS como CloudHSM han pasado a generaciones que usan HSM validados con FIPS 140-3 Level 3, por lo que la decisión basada en si el nivel de validación es más alto o más bajo ya no se sostiene. Los criterios de decisión son cinco. Son el uso exclusivo del hardware, el control directo mediante PKCS#11, JCE y otros, dónde reside la custodia de las claves, si los requisitos de cumplimiento llegan a especificar el carácter de un solo inquilino y si se puede asumir la responsabilidad operativa. Si se desea colocar el material de claves en un clúster propio manteniendo la integración con los servicios de AWS, también se puede considerar la solución intermedia del almacén de claves de AWS CloudHSM de KMS. hsm2m.medium es la generación actual de tipo de HSM, y hsm1.medium llegó al fin del soporte el 31 de marzo de 2026. Por lo tanto, si se operan clústeres existentes, lo primero es comprobar el estado de la migración. El precio de una configuración de dos HSM es de un nivel considerable, de unos 2,336 USD al mes (Norte de Virginia) a unos 2,643 USD (Tokio). Por ello, recomendamos decidir la adopción después de comprobar los requisitos con los cinco criterios anteriores (a fecha de agosto de 2026).
Referencias (recursos oficiales de AWS)
Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.
- AWS CloudHSM (página oficial)
- AWS KMS (página oficial)
- AWS IAM (página oficial)
- Documentación de AWS (oficial)
Si esta página y la documentación oficial difieren, prevalece la documentación oficial.