El HSM adecuado. Antes de invertir.

La arquitectura separa las aplicaciones, la administración, la copia de seguridad y la custodia de claves. Una partición es una separación lógica, pero no sustituye toda separación organizativa o física. Aclaramos qué claves pueden replicarse, quién puede ampliar un clúster y qué dependencias existen entre emplazamientos. Si el HSM falla, una aplicación no debe pasar de forma inadvertida a utilizar archivos de claves sin proteger. El estado del certificado y la security policy se revisan para el módulo concreto; el nombre de un producto o la evidencia de un algoritmo no son suficientes para ello.

Antes de la aprobación definitiva probamos las operaciones típicas con la conexión de cliente prevista. Se miden el rendimiento, la latencia y el tratamiento de errores dentro del perfil acordado. El resultado incluye supuestos sobre el crecimiento, las licencias y la operación. Para empezar necesitamos un resumen de las aplicaciones, los tipos de clave existentes, los requisitos de emplazamiento y las evidencias que su organización debe aportar realmente.

Un HSM de red puede ofrecer una función criptográfica centralizada a varias aplicaciones. En ese caso, la ruta de red, la autenticación y la separación de inquilinos pasan a formar parte de la arquitectura. Una tarjeta PCIe vincula la función más estrechamente al host; un segundo equipo necesita su propio concepto de disponibilidad. En el caso de un servicio gestionado, revisamos las API disponibles y el reparto de la administración. Esta decisión no la tomamos solo por el precio de adquisición: el esfuerzo de operación, los emplazamientos disponibles, las ventanas de mantenimiento y un posible cambio posterior también forman parte de la comparación.

Para el piloto describimos un proceso de negocio completo: ¿qué llamada llega al HSM, cuántas llamadas se generan por operación y cuándo se considera tardía la respuesta? Además de los valores medios, registramos los percentiles altos de latencia y el comportamiento ante picos de carga. Una prueba con una única firma no refleja ni los clientes en paralelo, ni el establecimiento de conexión, ni la caída de un nodo. Usted recibe las condiciones medidas y el margen restante, de modo que la adquisición se base en un perfil de carga verificable.

Varias aplicaciones deben poder firmar en el futuro a través de una infraestructura común. OTOKO® asigna claves y responsabilidades a las aplicaciones, comprueba los mecanismos necesarios y compara una plataforma común con instancias separadas. En el piloto probamos no solo las firmas correctas, sino también la falta de permisos, el agotamiento de los recursos de sesión y la desconexión de un nodo. El resultado es una decisión de arquitectura fiable, con el esfuerzo de integración, la necesidad de licencias y las dependencias pendientes; no una recomendación genérica a favor del dispositivo más grande.