Seguridad

Introducción

Esta guía recoge un conjunto de directrices y recomendaciones técnicas destinadas a reforzar la seguridad en entornos restringidos que hacen un uso intensivo de los HSM DINAMO de material criptográfico sensible. Estos entornos son especialmente críticos en instituciones financieras y proveedores de servicios que gestionan sistemas como el SPB (Sistema de Pagos Brasileño) y Pix, en los que la integridad de las claves y los certificados institucionales es un requisito innegociable para la continuidad de los servicios y para la confianza depositada por los clientes, las contrapartes y los organismos reguladores.

Las prácticas aquí descritas se basan en el principio de la defensa en profundidad: se superponen múltiples capas de control de tal forma que el fallo aislado de una de ellas no comprometa el conjunto. El texto que sigue está organizado en bloques temáticos, comenzando por los controles más generales de la infraestructura y avanzando progresivamente hacia las particularidades del funcionamiento seguro de los HSM.

Nota

Consulte también el apartado «Procedimientos de seguridad para el operario».

Controles generales de infraestructura

Antes de abordar los aspectos específicos de la criptografía, es imprescindible que el entorno en el que se encuentra el HSM cumpla con unos controles básicos de seguridad. Un HSM que funcione dentro de una red poco segura, con equipos cliente mal protegidos y políticas de acceso poco estrictas, ve reducido su valor de forma significativa, ya que el atacante rara vez tendrá que enfrentarse directamente al HSM, sino que le bastará con comprometer lo que lo rodea.

Aislamiento de red

El entorno debe estar aislado en una red dedicada, protegida por cortafuegos configurados para permitir únicamente el tráfico estrictamente necesario para el funcionamiento. El acceso administrativo debe realizarse exclusivamente a través de servidores bastión o servidores de enlace debidamente supervisados, y en ningún caso debe haber una exposición directa del HSM o de los equipos operativos a Internet o a redes corporativas de uso general. Siempre que sea posible, las interfaces de gestión del HSM deben residir en una VLAN distinta de la VLAN utilizada por las aplicaciones cliente, separando así el plano de control del plano de datos.

Filtro IP

El HSM cuenta con una función por la que todo acceso, ya sea para operaciones transaccionales o para tareas de administración, debe pasar por listas de control de acceso basadas en la dirección IP de origen (y, opcionalmente, en el usuario + IP). Esta restricción debe aplicarse tanto a nivel del cortafuegos como, preferiblemente, en la propia configuración del HSM, creando así una doble barrera. El filtro de IP elimina una amplia gama de ataques oportunistas y reduce drásticamente el margen para los intentos de fuerza bruta y de escaneo. Se recomienda revisar periódicamente estas listas, con el fin de eliminar las entradas de equipos desactivados o de empleados que hayan dejado la empresa.

Política de contraseñas

La institución debe contar con una política de contraseñas formalizada, aplicable a todas las cuentas de usuario del HSM y de los sistemas relacionados. Dicha política debe incluir, como mínimo:

1. Control de errores de autenticación, con bloqueo temporal o permanente de la cuenta tras un número definido de intentos fallidos consecutivos, lo que evita los ataques de fuerza bruta y genera alertas que debe gestionar el equipo de respuesta a incidentes;

2. Tamaño mínimo y requisitos de complejidad compatibles con lo establecido en el manual, es decir, un máximo de 16 caracteres que representen 128 bits, donde se recomienda generar nuevas contraseñas mediante un generador con distribución uniforme que utilice caracteres base62, evitando así contraseñas predecibles y dificultando al máximo los ataques por diccionario;

3. Rotación periódica a intervalos definidos, complementada con una rotación extraordinaria siempre que se sospeche de un fallo o una desconexión de los dispositivos de custodia; este aspecto no es una característica del HSM, sino una práctica arquitectónica de diseño para su uso.

La política de contraseñas, por sí sola, es insuficiente como medida de protección, pero constituye la base sobre la que se asientan el resto de controles.

Cuenta objetivo: la base de la confianza institucional

Dentro del HSM, la institución debe crear una o varias cuentas, denominadas «particiones» en el manual del equipo, destinadas exclusivamente a la custodia de los certificados institucionales. La segregación recomendada es la siguiente:

• En el caso del SPB, debe mantenerse una cuenta de destino por dominio o institución participante;
• Para el Pix, se debe mantener una cuenta de destino por entidad;
• En el caso de otros sistemas críticos, se aplicará la misma lógica de segregación por ámbito de responsabilidad.

La cuenta principal debe entenderse como la base de la confianza institucional dentro del HSM. Su uso cotidiano es, por su propio diseño, poco frecuente: se accede a ella esencialmente para delegar otros accesos, es decir, para autorizar que cuentas operativas subordinadas pasen a ejercer funciones en nombre de la institución. En un ciclo normal de funcionamiento, esta actividad se produce con muy poca frecuencia, a menudo a intervalos de meses o años, lo que permite aplicar controles más restrictivos sin perjudicar la agilidad operativa.

Custodia compartida

La contraseña de la cuenta en cuestión nunca debe estar íntegramente bajo el control de una sola persona. El mecanismo recomendado es el de múltiples custodios, con un mínimo de dos participantes. Esta división de responsabilidades impide las acciones unilaterales, reduce el riesgo asociado a la coacción o la mala fe individual y establece un proceso formal y verificable para cualquier acción crítica.

Restricción por usuario y dirección IP

Además de la custodia compartida, el acceso a la cuenta en cuestión debe estar condicionado a la combinación autorizada de usuario y dirección IP de origen. Esta vinculación física-lógica impide que las credenciales que pudieran filtrarse se utilicen fuera de la estación operativa autorizada originalmente, y convierte cualquier intento de uso desde un origen no previsto en un incidente de seguridad que requiere una investigación inmediata.

Es necesario supervisar periódicamente los inicios de sesión en estas cuentas mediante el análisis de los registros de los equipos.

Cuenta de inversión (App)

El funcionamiento diario del HSM, la firma de mensajes, la validación de certificados y el resto de funciones criptográficas que utilizan los sistemas internos nunca deben realizarse desde la cuenta de destino. Esa responsabilidad recae en una cuenta de aplicación, creada específicamente para este fin, con los permisos correspondientes.

Autorizaciones granulares

La cuenta de la aplicación debe configurarse según el principio del privilegio mínimo, de modo que solo disponga de permisos de lectura sobre los objetos de la cuenta de destino. Las operaciones administrativas, la creación de nuevas claves fuera del flujo previsto y el acceso a objetos de otras aplicaciones deben estar expresamente prohibidos. Cuando la institución gestiona varias aplicaciones distintas, se recomienda encarecidamente que cada una de ellas cuente con su propia cuenta de aplicación, de modo que, en caso de que una de ellas se vea comprometida, esto no se propague al resto.

Rotación de contraseñas

Las credenciales de la cuenta de la aplicación no tienen por qué ser una contraseña textual: el HSM admite el uso de una PSK (clave precompartida) de 128 bits (16 bytes), denominada ATOKEN, como mecanismo de autenticación. El ATOKEN también es renovable y, al tratarse de un secreto de alta entropía generado aleatoriamente, elimina las vulnerabilidades típicas de las contraseñas elegidas (previsibilidad, reutilización, susceptibilidad a los ataques de diccionario), por lo que es la opción preferida para la autenticación de aplicaciones.

La contraseña, o el ATOKEN, de la cuenta de la aplicación debe rotarse periódicamente, en ciclos compatibles con el nivel de criticidad de la aplicación y con la política interna de la institución. Para que esta rotación se produzca sin impacto operativo, deben existir scripts o herramientas automatizadas encargadas de generar una nueva contraseña, actualizarla en el HSM y propagarla al almacén de secretos utilizado por las aplicaciones. Este proceso debe ser auditable y resistente a fallos intermedios, es decir, capaz de recuperar un estado coherente en caso de interrupción, y debe someterse a pruebas periódicas fuera de la ventana crítica. Las contraseñas de las cuentas de aplicación nunca deben almacenarse en archivos de configuración sin cifrar, en repositorios de código ni en herramientas de colaboración.

Autenticación multifactorial de la cuenta de la aplicación (clave asimétrica + PSK)

Para aplicaciones críticas, se recomienda reforzar la autenticación de la cuenta de la aplicación a dos factores, combinando la PSK (contraseña o ATOKEN) con un certificado X.509 y su respectiva clave privada, asociados a la partición. En esta configuración, el cliente se autentica en el HSM mediante mTLS (TLS mutuo), el HSM valida el certificado presentado por la aplicación y, a continuación, solicita la PSK correspondiente, de modo que disponer de uno solo de los factores es insuficiente para establecer la sesión.

Este modelo aumenta sustancialmente el nivel de seguridad efectivo de la autenticación, ya que combina algo que la aplicación conoce (la PSK, con alta entropía cuando se genera como ATOKEN de 128 bits) con algo que la aplicación posee (la clave privada asociada al certificado). Para que no se vean mermadas las garantías del segundo factor, la clave privada utilizada en mTLS no debe residir en variables de entorno ni en archivos de configuración sin restricciones: debe almacenarse en un archivo protegido por listas de control de acceso (ACL) en el sistema de archivos, bajo una cadena de custodia distinta de la que gestiona la PSK. De este modo, un posible compromiso de uno de los factores —ya sea una filtración de la PSK del almacén de secretos o un acceso indebido a la clave privada— no es suficiente, por sí solo, para autenticarse como la aplicación.

La rotación de los dos factores debe ser independiente y automatizada, siguiendo los mismos principios descritos anteriormente. Cabe señalar que el HSM no admite todas las combinaciones posibles de factores: concretamente, la combinación de ATOKEN con PSK no es compatible por diseño; por lo tanto, la configuración recomendada para la autenticación de dos factores (2FA) en la cuenta de la aplicación es una clave asimétrica (certificado X.509) asociada a la PSK.

Relación de los miembros del equipo de seguridad

La inclusión, sustitución y eliminación de certificados en el HSM es una actividad periódica que suele estar a cargo de un equipo de seguridad especializado. Cada miembro de dicho equipo debe disponer de su propia cuenta personal y nominal en el HSM, en lugar de compartir credenciales genéricas.

La existencia de cuentas individuales aporta tres ventajas directas:

• Crea registros de auditoría precisos, en los que cada operación de manipulación de objetos se asocia a un operador identificable, lo que facilita los procesos de revisión, peritaje y rendición de cuentas.

• Permite revocar inmediatamente el acceso en caso de cese o cambio de funciones, sin los costes que conlleva cambiar las contraseñas compartidas y volver a distribuirlas.

• Crea las condiciones necesarias para la aplicación de la autenticación multifactorial (MFA) por parte del operador, combinando la contraseña con un segundo factor de posesión, como un token físico, una tarjeta inteligente o una aplicación de autenticación, lo que eleva sustancialmente el coste de un ataque que tenga éxito.

La política de seguridad de la institución debe hacer obligatorio el uso de la autenticación multifactorial (MFA) para estas cuentas, y no debe admitirse ninguna excepción bajo el pretexto de la conveniencia operativa.

Usuarios, operadores del HSM y segregación de privilegios

Además de las cuentas de custodia de certificados y las cuentas de aplicación, el HSM permite crear usuarios operadores, dotados de funciones administrativas de las que no disponen los usuarios comunes. Entre las funciones típicas de este perfil se encuentran la extracción y visualización de registros, la creación de nuevos usuarios, la modificación de los parámetros de configuración de los equipos y otras operaciones de mantenimiento que garantizan una gestión adecuada del equipo. La existencia de un perfil de operador diferenciado es fundamental para que las actividades administrativas rutinarias puedan llevarse a cabo sin necesidad de acceder directamente a las cuentas de destino o a las cuentas de aplicación, respetando así el principio de separación de responsabilidades. Una información importante es que no se debe utilizar el usuario master que viene por defecto en el HSM y no se puede eliminar). Este usuario tiene los mismos permisos que un operador, con la restricción (además de no poder eliminarse) de que, si se bloquea su contraseña, solo puede desbloquearse mediante una operación en la consola local conectada físicamente al HSM.

Sin embargo, es importante destacar una garantía fundamental que ofrece el HSM con respecto a estos usuarios administrativos: no existe ninguna posibilidad de que un usuario operador utilice un objeto, como una clave, perteneciente a otra partición para realizar operaciones criptográficas, a menos que se le haya concedido permiso explícito para ello. Esta propiedad es crucial, ya que significa que los privilegios administrativos no se convierten automáticamente en privilegios de uso del material criptográfico custodiado. El administrador puede gestionar el equipo sin que ello le otorgue acceso operativo a las claves de las particiones; la barrera entre el plano de administración y el plano de uso criptográfico la mantiene el propio HSM, independientemente de las buenas prácticas aplicadas por la institución. Este comportamiento, por sí solo, ya reduce sustancialmente el riesgo asociado al compromiso de las cuentas administrativas y refuerza el valor de la segregación de particiones descrita en las secciones anteriores.

Generación y gestión del material criptográfico

El tratamiento que se da a las claves es, en última instancia, lo que determina la calidad del uso del HSM. Un HSM que funciona con claves exportables, manipuladas fuera del equipo o transferidas por medios inseguros, pierde gran parte de su razón de ser.

Claves no exportables

Siempre que sea posible, las claves privadas deben generarse directamente dentro del HSM, con el atributo de no exportabilidad definido en el momento de su creación. De este modo, el material criptográfico sensible nunca sale del equipo en claro, y ni siquiera un administrador con privilegios elevados puede extraerlo. Esta es la configuración que realmente hace realidad las garantías de protección que ofrece el HSM.

Flujo adecuado para los certificados

El procedimiento recomendado para obtener un certificado operativo es el siguiente: se genera la clave privada dentro del HSM, se crea la CSR (solicitud de firma de certificado) a partir de dicha clave, también dentro del equipo, se envía la CSR a la autoridad certificadora y, por último, solo se importa el certificado firmado resultante. En ningún momento la clave privada sale del HSM. Este proceso debe documentarse paso a paso, y el equipo de seguridad debe recibir formación para rechazar flujos alternativos que impliquen la generación externa de la clave.

Transferencia entre particiones

En situaciones en las que una misma clave debe estar disponible en particiones distintas, por ejemplo, para cumplir requisitos de alta disponibilidad o para la replicación entre entornos equivalentes, la transferencia debe realizarse mediante el mecanismo de copia de seguridad y restauración de claves que ofrece el propio HSM. Este mecanismo transporta el material cifrado con una protección de alta calidad y preserva las propiedades de no exportabilidad y de control de acceso de la clave original. Nunca se debe recurrir a la exportación en claro ni a formatos intermedios inseguros para llevar a cabo esta transferencia.

Protección física y operativa de los equipos

La seguridad lógica depende de una base de seguridad física sólida. El HSM debe instalarse en un entorno con control de acceso físico auditado, preferiblemente en una sala de seguridad o en un rack cerrado con llave dentro de un centro de datos clasificado.

Tarjetas inteligentes y custodia compartida en operaciones administrativas

Las operaciones administrativas de los equipos —inicialización, modificación de parámetros, cambio de red, entre otras— deben estar protegidas mediante tarjetas inteligentes acompañadas de un PIN, que también se gestionan mediante un sistema de custodia múltiple. Esta combinación exige la presencia física simultánea de más de una persona autorizada para que se pueda llevar a cabo cualquier acción crítica, lo que reproduce en el ámbito administrativo las mismas garantías ya descritas para la cuenta objetivo.

Segregación de espacios

Siempre que sea posible, las diferentes aplicaciones deben funcionar en HSM o particiones distintas. Se recomienda encarecidamente separar el SPB, Pix el resto de sistemas críticos, ya que esto limita el impacto de posibles vulneraciones y facilita la asignación de responsabilidades. Por su parte, la separación entre los entornos de validación y de producción es obligatoria: un HSM de producción nunca debe utilizarse para pruebas, y las claves de producción nunca deben pasar por el entorno de validación. Esta norma debe considerarse innegociable, incluso ante presiones de plazos.

Los HSM Dinamo por su rápida puesta en marcha, por lo que, mediante la configuración de red y de dominio, es posible incorporar un HSM que se haya utilizado anteriormente en otro entorno (como, por ejemplo, el de homologación) a un entorno de producción, ya sea por la sustitución de un equipo o por la ampliación del clúster. Esta operación no provoca la interrupción del entorno de producción de destino.

Continuidad operativa y recuperación ante desastres

La pérdida del acceso a las claves institucionales equivale, desde un punto de vista práctico, a la interrupción de los servicios que dependen de ellas. Por ello, la estrategia de continuidad debe planificarse con el mismo rigor que se aplica a los controles preventivos.

Se deben realizar copias de seguridad periódicas y controladas siguiendo una rutina formal que defina la periodicidad, los responsables, los lugares de almacenamiento y el plazo de conservación. Las copias de seguridad deben almacenarse en soportes seguros y físicamente separados del entorno de producción, preferiblemente en más de un lugar.

Seguimiento y auditoría continua

Ningún conjunto de controles es capaz de eliminar por completo la posibilidad de que se produzcan incidentes. La diferencia entre una institución resiliente y una vulnerable suele radicar en la rapidez con la que se detectan y se abordan las anomalías.

Los equipos HSM deben supervisarse de forma continua, preferiblemente mediante protocolos como SNMP para la recopilación de métricas y SMTP para el envío de alertas, además de integrarse con la plataforma SIEM corporativa. Deben generar alertas específicas, al menos, para los siguientes eventos:

• Creación de nuevos usuarios o particiones, una operación inusual que debe revisarse de inmediato siempre que se produzca fuera de un plan autorizado;
• Inicios de sesión fuera del horario habitual de funcionamiento, especialmente en cuentas de aplicaciones o cuentas administrativas, que indiquen un posible uso indebido de las credenciales;
• Intentos repetidos de autenticación fallidos, que pueden indicar ataques de fuerza bruta o errores de configuración importantes;
• Cambios en las políticas, la configuración o los permisos que modifiquen el perímetro de seguridad del equipo;
• Incidentes relacionados con el estado del equipo, como fallos de hardware, temperaturas anómalas omanipulaciones no autorizadas, que requieren una respuesta operativa inmediata.

Los registros generados deben conservarse durante un periodo compatible con los requisitos normativos y con la política de conservación de la institución, y deben protegerse contra cualquier manipulación indebida.

Recomendaciones finales

Las buenas prácticas descritas en esta guía no constituyen una lista estática. El panorama de amenazas evoluciona continuamente, al igual que las capacidades de los equipos, los requisitos normativos y las exigencias de las contrapartes. Por ello, se recomienda revisar este documento periódicamente, como mínimo una vez al año, o siempre que se produzcan cambios significativos en la infraestructura, en la legislación aplicable o en la cartera de aplicaciones críticas de la institución.

También se recomienda que la adopción de estas prácticas vaya acompañada de programas de formación y sensibilización dirigidos a los equipos implicados, ya que la eficacia de los controles depende directamente del grado de comprensión y adhesión de los profesionales que los manejan. La documentación técnica de los equipos debe estar siempre a disposición del equipo responsable, especialmente a la hora de planificar cambios y de responder a incidentes.