HSM (Módulo de seguridad de hardware)

Un módulo de seguridad de hardware (HSM) es un dispositivo de hardware dedicado y resistente a manipulaciones que genera, almacena y utiliza claves criptográficas, de modo que el material de la clave nunca existe en texto plano fuera del dispositivo. Cada operación sensible —crear una clave, firmar, cifrar o desenvolver otra clave— ocurre dentro del límite reforzado del propio HSM.

Un HSM no trata de quién controla una clave; de eso se ocupan las claves gestionadas por el cliente. Un HSM trata de dónde reside físicamente la clave y cómo se protege. Es la raíz de confianza de hardware que a menudo se encuentra debajo de un servicio de gestión de claves (KMS): el lugar donde realmente reside «tu propia» clave.

Qué hace realmente un HSM

Un HSM concentra cuatro capacidades en un único dispositivo reforzado:

• Generación de claves. Las claves se crean en el dispositivo mediante un generador de números aleatorios verdadero (TRNG) por hardware, produciendo claves con mayor entropía que el software por sí solo.
• Almacenamiento seguro. Las claves privadas y secretas permanecen dentro del límite criptográfico y nunca se exportan en texto plano; como mucho salen envueltas (cifradas) por otra clave que tampoco sale nunca.
• Operaciones en el dispositivo. La firma, el cifrado, el descifrado y el envoltorio/desenvoltorio de claves se ejecutan dentro del HSM, de modo que la aplicación envía los datos y recibe un resultado sin manejar nunca la clave en bruto.
• Control de acceso y auditoría. Una autenticación sólida, la separación de funciones y un registro resistente a manipulaciones determinan quién puede usar cada clave y dejan constancia de cómo se utilizó.

Como la clave nunca sale en forma utilizable, robar el servidor que la rodea no proporciona la clave.

HSM frente a KMS frente a CMK/BYOK

Estos términos se usan a menudo indistintamente, pero responden a preguntas diferentes:

• KMS (servicio de gestión de claves) es el software que gestiona el ciclo de vida de las claves: creación, rotación, políticas, acceso y auditoría, normalmente expuesto como una API.
• HSM es la raíz de confianza de hardware. Con frecuencia un KMS está «respaldado por HSM», lo que significa que las claves maestras que gestiona se generan y se guardan dentro de un HSM.
• CMK / BYOK trata del control: si eres tú, y no el proveedor, quien posee y administra la clave.

En pocas palabras: la CMK decide quién controla la clave, un KMS decide cómo se gestiona la clave y un HSM decide dónde reside la clave y cuán resistente a manipulaciones es su custodia. Una clave gestionada por el cliente reside muy a menudo en un KMS respaldado por HSM.

Garantía: FIPS 140-3, resistencia a manipulaciones e interfaces

El valor de un HSM se basa en una garantía independiente de que sus protecciones realmente funcionan.

• FIPS 140-3. Es el estándar actual de EE. UU. y Canadá para módulos criptográficos, que sustituye a FIPS 140-2 (cuyas validaciones se están retirando). Define cuatro niveles de seguridad (1 a 4) de protección física y lógica creciente; los HSM suelen validarse en el Nivel 3, que añade detección y respuesta ante manipulaciones y autenticación basada en identidad.
• Resistencia a manipulaciones. Los HSM combinan la evidencia de manipulación (se aprecia que se abrió) con la respuesta ante manipulación (las claves se borran si se vulnera el límite). Muchos también se evalúan según Common Criteria.
• Interfaces estándar. Las aplicaciones se comunican con los HSM mediante PKCS#11 (una API local, también llamada Cryptoki, para dialogar con un token criptográfico) y KMIP (un protocolo de red para la gestión de claves entre un cliente y un KMS o HSM).

Appliance local, HSM en la nube y cuándo se necesita uno

Los HSM se presentan en varios formatos de implementación:

• Appliance local. Un dispositivo físico en tu propio centro de datos, que te da la custodia directa del hardware.
• HSM en la nube. Una instancia de HSM dedicada y de un solo inquilino alquilada a un proveedor de nube: sigue siendo un HSM real, solo que alojado y operado de forma remota.
• KMS respaldado por HSM. Un KMS gestionado cuyas claves maestras residen en HSM entre bastidores, lo que aporta gran parte de la garantía sin que tengas que operar el hardware.

Normalmente necesitas un HSM cuando una normativa o un contrato exige una raíz de confianza de hardware: servicios financieros y pagos (por ejemplo, PCI DSS), cargas de trabajo del sector público y defensa, e infraestructuras de clave pública como una autoridad de certificación raíz o emisora.

HSM y ARTESCA

ARTESCA no es un HSM ni contiene uno. En su lugar, ARTESCA está diseñado para mantener las claves de cifrado totalmente fuera de la cabina de almacenamiento y delegar su custodia en un gestor de claves que tú controlas, que puede estar respaldado por HSM.

ARTESCA cifra los objetos en reposo mediante cifrado del lado del servidor con cifrado de sobre: cada objeto recibe una clave de datos única, y esa clave de datos se envuelve con una clave maestra. Cuando ARTESCA se configura con un KMS externo, el material de la clave maestra nunca sale del KMS: solo se almacena una referencia (el ID de la clave) en los metadatos del objeto, y los datos del objeto nunca se envían al KMS. Los backends externos compatibles incluyen gestores de claves compatibles con KMIP (como Thales CipherTrust Manager, HashiCorp Vault y HyTrust KeyControl) y servicios compatibles con AWS KMS. Cualquiera de ellos puede, a su vez, estar respaldado por un HSM como raíz de confianza.

El resultado es una separación de confianza cero clara: tus datos residen en ARTESCA, tus claves residen en tu KMS o HSM, y ningún sistema individual posee ambos. Esto complementa las claves gestionadas por el cliente para el control de la clave y S3 Object Lock para la inmutabilidad de los datos.

Preguntas frecuentes sobre HSM

¿Cuál es la diferencia entre un HSM y un KMS?

Un KMS es software que gestiona el ciclo de vida de las claves (creación, rotación, políticas y acceso). Un HSM es el hardware resistente a manipulaciones donde las claves pueden generarse y guardarse. Son complementarios: un KMS suele estar «respaldado por HSM», usando un HSM como raíz de confianza.

¿Un HSM en la nube sigue siendo un HSM «real»?

Sí. Un HSM en la nube es un módulo de hardware dedicado y de un solo inquilino operado por un proveedor de nube en tu nombre. El hardware y su validación FIPS son reales; solo el alojamiento y la custodia física difieren de un appliance local.

¿Qué significa un nivel de FIPS 140-3?

FIPS 140-3 define cuatro niveles de protección para módulos criptográficos. Los niveles más altos añaden autenticación más sólida y protección física contra manipulaciones. Los HSM suelen validarse en el Nivel 3, que exige detección y respuesta ante manipulaciones y autenticación basada en identidad.

¿Necesito un HSM para usar claves gestionadas por el cliente?

No necesariamente. Las claves gestionadas por el cliente tratan de quién controla la clave y pueden guardarse en un KMS de software. Un HSM eleva la garantía al asegurar que el material de la clave reside en hardware resistente a manipulaciones, por lo que muchas claves gestionadas por el cliente se alojan en un KMS respaldado por HSM.

PKCS#11 o KMIP, ¿cuál es la diferencia?

PKCS#11 es una API local para que una aplicación utilice un token criptográfico o HSM en el mismo sistema. KMIP es un protocolo de red para gestionar claves entre un cliente y un KMS o HSM. Son estándares complementarios; ARTESCA se integra con gestores de claves externos a través de KMIP.