En la custodia de activos digitales, el control de un activo equivale al control de la clave privada que autoriza su movimiento. Por eso la pieza central de cualquier arquitectura de custodia bancaria es el lugar donde se generan, se guardan y se usan esas claves. En la mayoría de las entidades, ese lugar es un módulo de seguridad hardware, o HSM.
Cuando un banco prepara su infraestructura, la discusión suele centrarse en si el HSM debe ser un equipo físico en sus centros de datos o un HSM desplegado en su nube. Es una decisión relevante, pero conviene plantearla bien: bien configurados, ambos ofrecen el mismo nivel de protección para las claves. Lo que cambia es la forma de operar, no la seguridad.
Qué hace un HSM en la custodia de activos digitales
Un HSM es un dispositivo diseñado para generar y proteger material criptográfico y ejecutar operaciones con él sin que ese material salga nunca del módulo. En la custodia de activos digitales cumple varias funciones:
- Generación de claves: las claves privadas de los clientes o de las direcciones de la entidad se generan dentro del HSM, con su propia fuente de entropía.
- Almacenamiento: las claves permanecen dentro del módulo o cifradas bajo claves que solo el módulo conoce. No se exportan en claro.
- Firma: cuando hay que mover un activo, la transacción se envía al HSM, que la firma internamente y devuelve solo la firma.
- Control de acceso: el uso de cada clave está sujeto a roles, credenciales y, cuando procede, a quórums de aprobación.
Los HSM suelen estar certificados según estándares como FIPS 140-3 o Common Criteria. Qué modelo y qué nivel de certificación se utiliza es una decisión del banco, alineada con sus políticas de seguridad y con lo que espera su supervisor.
HSM físico en las instalaciones del banco
Un HSM físico es un equipo que el banco adquiere, instala en sus centros de datos y opera con su propio personal. Muchas entidades ya lo utilizan para medios de pago o firma electrónica.
- Control directo: el banco gestiona el hardware, la ubicación, el acceso físico y las ceremonias de inicialización.
- Procesos conocidos: los equipos de seguridad suelen tener experiencia previa, procedimientos y auditorías establecidas.
- Aprovisionamiento y mantenimiento: requiere compra, instalación, actualizaciones de firmware, sustitución de equipos y planificación de capacidad.
- Redundancia: la alta disponibilidad exige varios módulos, normalmente en más de un centro de datos, con replicación segura de claves entre ellos.
HSM desplegado en la nube del banco
Un HSM en la nube es un módulo, dedicado o gestionado, que se ejecuta en la infraestructura de un proveedor de nube pero dentro del entorno contratado por el banco. En el modelo dedicado, el banco dispone de hardware asignado en exclusiva; en el gestionado, el proveedor opera la infraestructura subyacente mientras el banco conserva el control criptográfico.
- El banco sigue siendo quien controla las claves: las credenciales de administración y uso pertenecen a la entidad. El proveedor de nube opera el hardware, pero no puede utilizar las claves.
- Elasticidad: la capacidad puede ampliarse con menos plazos de aprovisionamiento.
- Redundancia geográfica: es más sencillo distribuir módulos en varias regiones dentro de los límites que marque la política de residencia de datos del banco.
- Integración con la arquitectura existente: encaja de forma natural si los sistemas que orquestan las operaciones ya se ejecutan en la nube de la entidad.
El mismo nivel de protección, distintas formas de operar
La propiedad que importa en custodia es que la clave no salga nunca del HSM y que toda firma se produzca dentro del módulo, bajo credenciales y políticas que controla el banco. Esa propiedad se cumple tanto en un HSM físico como en uno desplegado en la nube, siempre que ambos estén configurados correctamente: inicialización controlada, separación de roles, gestión rigurosa de credenciales, copias de seguridad cifradas y registros de auditoría.
Por eso la elección no debería basarse en la idea de que un modelo es más seguro que el otro. Los criterios que suelen decidirla son otros:
- Arquitectura: dónde se ejecutan los sistemas que construyen y envían las transacciones, y cuántos saltos de red hay hasta el HSM.
- Operación: qué equipos van a administrarlo, con qué procedimientos y con qué experiencia previa.
- Latencia y volumen: el número de firmas previsto y los tiempos de respuesta que exige la experiencia de cliente.
- Contratos existentes: si la entidad ya dispone de HSM físicos con capacidad disponible o de un acuerdo marco con un proveedor de nube.
- Expectativas del supervisor: cómo ha evaluado ya el supervisor la externalización de servicios en la nube del banco.
- Residencia de datos: en qué jurisdicciones pueden estar los módulos y sus copias de seguridad.
También es posible combinar ambos, siempre que las políticas sean coherentes entre ellos.
Políticas de firma, límites y auditoría
El tipo de HSM no cambia la lógica de control que rodea a cada firma. Esa lógica se define en capas que funcionan igual en ambos modelos:
- Políticas de firma: qué claves pueden firmar qué tipos de operación, hacia qué destinos y con qué importes.
- Límites: umbrales por operación, por cliente y por periodo, a partir de los cuales se exige aprobación adicional.
- Quórums y aprobaciones: operaciones sensibles, como movimientos entre direcciones de la entidad o cambios de configuración, que requieren varias personas autorizadas.
- Registros de auditoría: cada petición de firma, aprobación y resultado queda registrada de forma que pueda revisarse internamente y por el supervisor.
Así, el banco puede ampliar su despliegue de HSM sin redefinir su modelo de control.
Por qué importa que las claves estén dentro del banco
Cuando las claves se generan y se mantienen en los HSM del propio banco, no hay un custodio tercero en la cadena de control de los activos de los clientes. La entidad responde directamente de la salvaguarda, y puede demostrarlo con sus propios registros.
Esto encaja con el Reglamento DORA (Reglamento (UE) 2022/2554), aplicable desde el 17 de enero de 2025, que exige a las entidades financieras gestionar el riesgo de sus proveedores tecnológicos y mantener el control sobre sus funciones críticas. Reducir el número de terceros con capacidad de actuar sobre los activos simplifica esa gestión y la conversación con el supervisor.
Antes de decidir, conviene que el banco responda a algunas preguntas:
- ¿Existen ya HSM en la entidad y tienen capacidad para este nuevo uso?
- ¿Dónde se ejecutarán los sistemas que construyen y envían las transacciones?
- ¿Qué volumen de firmas y qué tiempos de respuesta se esperan?
- ¿Qué exige la política de residencia de datos para módulos y copias de seguridad?
- ¿Qué equipos administrarán los módulos y cómo se separarán sus funciones?
- ¿Qué ha trasladado el supervisor sobre el uso de servicios en la nube?
En Finhattan desplegamos la infraestructura de custodia sobre los HSM que elige el banco, físicos o en su nube, sin acceso a las claves. Más detalle en seguridad y control y en la solución.
Si la entidad está valorando este paso, podemos analizarlo con su equipo a través de contacto.