Acceso del socio al HSM a través de una VPN: defina las operaciones de clave

Alguien en el socio tiene que firmar un documento con una clave designada, y la petición llega formulada en términos de red: necesitan llegar al HSM. Trate esa frase como un síntoma de un contrato de servicio indefinido y no como un problema de enrutamiento, porque un túnel que llega al dispositivo no concede nada por sí mismo. Detrás de la petición hay tres puertas: accesibilidad, identidad del HSM y política de claves, y cada una se administra en un lugar distinto por un equipo distinto. Escríbalas una por una, o acabará concediendo una ruta porque la conversación sobre el certificado era más difícil.

Mantenga el caso concreto a la vista: el socio envía un documento aprobado para firmar con una clave concreta, y nada más. Todo lo que sigue se deriva de esa única frase.

Accesibilidad, identidad y política de claves son tres puertas

El concentrador VPN decide quién puede abrir un túnel y a qué direcciones puede llegar. El HSM decide por sí mismo qué registro de usuario presentado puede iniciar sesión. La política de claves decide después qué puede hacer ese registro con una clave concreta. Pasar la primera puerta deja las otras dos exactamente como estaban, por eso un saludo correcto demuestra tan poco y por eso un socio puede llegar al dispositivo y aun así fallar en cada operación.

Asigne cada puerta a un responsable antes de escribir requisitos. Cuando nadie posee la segunda, el resultado habitual es que se entrega una identidad amplia de administrador del HSM porque es la única credencial que funciona.

Primera puerta: la ruta de red que recibe el socio

Nombre el cliente o servicio aprobado, el destino que necesita y el protocolo y el puerto en los que escucha ese servicio. Luego limite el acceso del lado VPN a ese par en ambos sentidos, incluida la ruta de vuelta, para que la política sea una frase que pueda leerle al socio. La administración de la pasarela, las interfaces de gestión del HSM y los sistemas internos no relacionados deberían quedar fuera del acceso habitual del socio, no solo fuera de la ruta predeterminada.

Un segmento dedicado hace visibles esos cruces, pero el nombre de un segmento no impone nada. El tráfico tiene que pasar por el control por el que cree que pasa. Admitir una conexión del socio tampoco es una declaración de que todas las máquinas del socio sean fiables.

Segunda puerta: qué se autentica realmente ante el HSM

Una identidad VPN y una identidad del HSM son objetos separados salvo que una integración compatible las una deliberadamente. Con un cliente PKCS#11, la aplicación realiza un inicio de sesión contra una ranura con una credencial almacenada en algún lugar del host del socio, y ese inicio de sesión es lo que evalúa el HSM.

AWS CloudHSM es una referencia útil porque su documentación mantiene los dos separados: los usuarios del HSM son distintos de los usuarios de IAM, y el tipo de usuario determina qué puede hacer la cuenta. Un oficial de criptografía gestiona usuarios y claves pero no es la identidad que realiza operaciones criptográficas, mientras que un usuario de criptografía puede usar claves sin poder gestionarlas. Esa separación es la forma que usted quiere incluso en el dispositivo de otro proveedor, donde los nombres de los roles serán distintos.

Sea cual sea la identidad que emita, debe poder eliminarse y atribuirse con la granularidad que necesitará después. Una credencial operativa compartida entre varios socios dificulta la contención y la rendición de cuentas justo en el incidente en el que ambas importan más.

Tercera puerta: qué clave y qué operación

La firma, el descifrado, la generación de claves, el envoltorio de claves y la administración de usuarios son permisos separados y deben enumerarse por separado. En términos de PKCS#11, atributos como CKA_SENSITIVE y CKA_EXTRACTABLE describen si el material de clave puede salir del módulo en forma utilizable, y se establecen por clave y no por dispositivo. Lea la política real de la clave en lugar de inferir la no exportabilidad de la palabra hardware o de la presencia de un túnel.

Después busque la aprobación de negocio. Si solo pueden firmarse documentos aprobados, ¿qué componente establece esa aprobación antes de que la petición llegue al HSM? Una interfaz criptográfica que acepta una petición autorizada no sabe si el documento se revisó, así que esa comprobación corresponde al servicio que tiene delante.

Un cliente permitido que esté comprometido también puede hacer un mal uso de las operaciones que su credencial autoriza legítimamente sin extraer nunca una clave privada. Proteger el material de clave almacenado y controlar el uso de las claves son, por tanto, dos condiciones de aceptación y no una.

Los rechazos forman parte de la prueba de aceptación

Acepte la petición de firma permitida y acepte también los rechazos: una identidad no autorizada, una clave no relacionada y una operación de gestión desde la ruta del socio. Registre el solicitante, la operación, el identificador de clave, la hora y el resultado, y mantenga el material de clave privada, las credenciales y el contenido de los documentos fuera de los registros de diagnóstico generales.

Asigne un responsable para la baja del socio, para un posible compromiso en el lado del socio y para los cambios de política y la recuperación. Cambiar una ruta no restaura la confianza en un host que puede estar ya comprometido, así que la revocación tiene que llegar también a la identidad del HSM.

Un saludo VPN completado pertenece a ese registro. No puede sustituir un único resultado específico del HSM.