Acceso dun socio ao HSM a través dunha VPN: defina as operacións de clave

Alguén no socio ten que asinar un documento cunha clave designada, e a solicitude chega formulada como un asunto de rede: necesitan chegar ao HSM. Trate esa frase como o síntoma dun contrato de servizo sen definir e non como un problema de encamiñamento, porque un túnel que chega ao aparello non concede nada por si mesmo. Tres portas están detrás da solicitude: alcanzabilidade, identidade do HSM e política de claves, e cada unha adminístrase nun lugar distinto por un equipo distinto. Anóteas unha a unha ou acabarás concedendo unha ruta porque a conversa sobre o certificado era máis difícil.

Manteña á vista o caso concreto: o socio envía un documento aprobado para asinar cunha clave nomeada, e nada máis. Todo o que segue derívase desa única frase.

Alcanzabilidade, identidade e política de claves son tres portas

O concentrador VPN decide quen pode abrir un túnel e que enderezos pode tocar. O HSM decide por si mesmo que rexistro de usuario presentado ante el pode iniciar sesión. A política de claves decide despois que pode facer ese rexistro de usuario cunha clave concreta. Pasar a primeira porta deixa as outras dúas exactamente como estaban, e por iso unha aperta de mans correcta demostra tan pouco e por iso un socio pode chegar ao aparello e fallar todas as operacións.

Asigne un responsable a cada porta antes de escribir os requisitos. Cando ninguén é responsable da segunda, o resultado habitual é que se entrega unha identidade de administrador do HSM ampla porque é a única credencial que funciona.

Porta un: a ruta de rede que recibe o socio

Nomee o cliente ou servizo aprobado, o destino que necesita e o protocolo e porto nos que escoita ese servizo. Despois limite o acceso do lado da VPN a ese par en ambos os sentidos, incluída a ruta de retorno, de xeito que a política sexa unha frase que poida lerlle ao socio. A administración da pasarela, as interfaces de xestión do HSM e os sistemas internos non relacionados deben quedar fóra do acceso habitual do socio, e non só fóra da ruta por defecto.

Un segmento dedicado fai visibles esas travesías, pero o nome dun segmento non impón nada. O tráfico ten que pasar polo control polo que vostede cre que pasa. Admitir unha conexión do socio tampouco é afirmar que todas as máquinas do socio son de confianza.

Porta dous: que se autentica realmente ante o HSM

Unha identidade VPN e unha identidade do HSM son obxectos distintos a non ser que unha integración compatible as una deliberadamente. Cun cliente PKCS#11, a aplicación realiza un inicio de sesión contra unha ranura cunha credencial almacenada nalgún lugar do host do socio, e ese inicio de sesión é o que avalia o HSM.

AWS CloudHSM é unha referencia útil porque a súa documentación mantén os dous separados: os usuarios do HSM son distintos dos usuarios de IAM, e o tipo de usuario determina o que pode facer a conta. Un oficial criptográfico xestiona usuarios e claves pero non é a identidade que realiza operacións criptográficas, mentres que un usuario criptográfico pode usar claves sen poder xestionalas. Esa separación é a forma que vostede quere mesmo no aparello doutro provedor, onde os nomes dos roles serán diferentes.

Calquera identidade que emita ten que poder retirarse e ser atribuíble coa granularidade que necesitará máis adiante. Unha única credencial operativa compartida entre varios socios dificulta a contención e a responsabilidade xustamente no incidente no que ambas máis importan.

Porta tres: que clave e que operación

Asinar, descifrar, xerar claves, envolver claves e administrar usuarios son permisos separados e deben enumerarse por separado. En termos de PKCS#11, atributos como CKA_SENSITIVE e CKA_EXTRACTABLE describen se o material da clave pode saír do módulo nunha forma utilizable, e fanse por clave e non por aparello. Lea a política real sobre a clave en vez de deducir a non exportabilidade da palabra hardware ou da presenza dun túnel.

Logo atope a aprobación de negocio. Se só se poden asinar documentos aprobados, que compoñente establece esa aprobación antes de que a solicitude chegue ao HSM? Unha interface criptográfica que acepta unha solicitude autorizada non ten idea de se o documento foi revisado, así que esa comprobación pertence ao servizo que ten diante.

Un cliente permitido que estea comprometido tamén pode facer un mal uso das operacións que a súa credencial autoriza lexitimamente sen extraer nunca unha clave privada. Protexer o material de clave almacenado e controlar o uso das claves son, por tanto, dúas condicións de aceptación, non unha.

As denegacións forman parte da proba de aceptación

Acepte a solicitude de sinatura permitida e acepte tamén as denegacións: unha identidade non autorizada, unha clave allea e unha operación de xestión desde a ruta do socio. Rexistre o chamador, a operación, o identificador da clave, a hora e o resultado, e manteña o material de clave privada, as credenciais e o contido dos documentos fóra dos rexistros de diagnóstico xerais.

Asigne un responsable para a baixa do socio, para unha compromisión sospeitada no lado do socio e para os cambios de política e a recuperación. Cambiar unha ruta non restaura a confianza nun host que pode xa estar comprometido, así que a revogación ten que chegar tamén á identidade do HSM.

Unha aperta de mans VPN completada pertence a ese rexistro. Non pode substituír un único resultado específico do HSM.