Accés del soci a l'HSM a través d'una VPN: definiu les operacions de clau

Algú del soci ha de signar un document amb una clau designada, i la petició arriba formulada en termes de xarxa: han d'arribar a l'HSM. Tracteu aquesta frase com un símptoma d'un contracte de servei indefinit i no com un problema d'encaminament, perquè un túnel que arriba a l'aparell no concedeix res per si sol. Darrere la petició hi ha tres portes: abastabilitat, identitat de l'HSM i política de claus, i cadascuna s'administra en un lloc diferent per un equip diferent. Escriviu-les una per una, o acabareu concedint una ruta perquè la conversa sobre el certificat era més difícil.

Tingueu present el cas concret: el soci envia un document aprovat per signar amb una clau concreta, i res més. Tot el que segueix es deriva d'aquella única frase.

Abastabilitat, identitat i política de claus són tres portes

El concentrador VPN decideix qui pot obrir un túnel i quines adreces pot tocar. L'HSM decideix, per si mateix, quin registre d'usuari presentat pot iniciar sessió. La política de claus decideix llavors què pot fer aquell registre amb una clau concreta. Passar la primera porta deixa les altres dues exactament com eren, i per això una encaixada de mans correcta demostra tan poc i per això un soci pot arribar a l'aparell i tot i així fallar en cada operació.

Assigneu cada porta a un responsable abans d'escriure requisits. Quan ningú no és responsable de la segona, el resultat habitual és que es lliura una identitat àmplia d'administrador de l'HSM perquè és l'única credencial que funciona.

Primera porta: el camí de xarxa que rep el soci

Anomeneu el client o servei aprovat, la destinació que necessita i el protocol i el port on escolta aquell servei. Després limiteu l'accés del costat VPN a aquesta parella en tots dos sentits, inclòs el camí de tornada, perquè la política sigui una frase que pugueu llegir al soci. L'administració de la passarel·la, les interfícies de gestió de l'HSM i els sistemes interns no relacionats haurien de quedar fora de l'accés habitual del soci, no només fora de la ruta per defecte.

Un segment dedicat fa visibles aquests encreuaments, però el nom d'un segment no imposa res. El trànsit ha de passar pel control pel qual creieu que passa. Admetre una connexió del soci tampoc no és una declaració que totes les màquines del soci siguin fiables.

Segona porta: què s'autentica realment a l'HSM

Una identitat VPN i una identitat de l'HSM són objectes separats tret que una integració compatible les uneixi deliberadament. Amb un client PKCS#11, l'aplicació fa un inici de sessió contra una ranura amb una credencial desada en algun lloc de l'amfitrió del soci, i és aquest inici de sessió el que avalua l'HSM.

AWS CloudHSM és una referència útil perquè la seva documentació manté els dos separats: els usuaris de l'HSM són diferents dels usuaris d'IAM, i el tipus d'usuari determina què pot fer el compte. Un responsable de criptografia gestiona usuaris i claus però no és la identitat que fa operacions criptogràfiques, mentre que un usuari de criptografia pot usar claus sense poder gestionar-les. Aquesta separació és la forma que voleu fins i tot en l'aparell d'un altre proveïdor, on els noms dels rols seran diferents.

Sigui quina sigui la identitat que emeteu, ha de ser eliminable i atribuïble amb la granularitat que necessitareu més endavant. Una credencial operativa compartida entre diversos socis fa més difícil la contenció i la rendició de comptes justament en l'incident en què totes dues són més importants.

Tercera porta: quina clau i quina operació

La signatura, el desxifrat, la generació de claus, l'embolcall de claus i l'administració d'usuaris són permisos separats i s'han de llistar per separat. En termes de PKCS#11, atributs com CKA_SENSITIVE i CKA_EXTRACTABLE descriuen si el material de clau pot sortir del mòdul en forma utilitzable, i s'estableixen per clau i no per aparell. Llegiu la política real de la clau en lloc d'inferir la no exportabilitat de la paraula maquinari o de la presència d'un túnel.

Després trobeu l'aprovació de negoci. Si només es poden signar documents aprovats, quin component estableix aquesta aprovació abans que la petició arribi a l'HSM? Una interfície criptogràfica que accepta una petició autoritzada no sap si el document s'ha revisat, així que aquesta comprovació pertoca al servei que té davant.

Un client permès que estigui compromès també pot fer un mal ús de les operacions que la seva credencial autoritza legítimament sense extreure mai una clau privada. Protegir el material de clau desat i controlar l'ús de les claus són, doncs, dues condicions d'acceptació i no una.

Els refusos formen part de la prova d'acceptació

Accepteu la petició de signatura permesa i accepteu també els refusos: una identitat no autoritzada, una clau no relacionada i una operació de gestió des del camí del soci. Registreu el sol·licitant, l'operació, l'identificador de clau, l'hora i el resultat, i manteniu el material de clau privada, les credencials i el contingut dels documents fora dels registres de diagnòstic generals.

Assigneu un responsable per a la baixa del soci, per a un possible compromís al costat del soci i per als canvis de política i la recuperació. Canviar una ruta no restaura la confiança en un amfitrió que pot estar ja compromès, així que la revocació ha d'arribar també a la identitat de l'HSM.

Una encaixada de mans VPN completada pertany a aquest registre. No pot substituir un únic resultat específic de l'HSM.