Accès du partenaire au HSM via un VPN : définir les opérations de clé

Quelqu'un chez le partenaire doit signer un document avec une clé désignée, et la demande arrive formulée en termes de réseau : ils doivent atteindre le HSM. Traitez cette phrase comme le symptôme d'un contrat de service indéfini plutôt que comme un problème de routage, car un tunnel qui atteint l'appareil n'accorde rien en soi. Derrière la demande se trouvent trois portes : accessibilité, identité HSM et politique de clé, et chacune est administrée ailleurs par une autre équipe. Écrivez-les une par une, sinon vous finirez par accorder une route parce que la conversation sur le certificat était plus difficile.

Gardez le cas concret en vue : le partenaire soumet un document approuvé pour signature avec une clé nommée, et rien d'autre. Tout ce qui suit découle de cette seule phrase.

Accessibilité, identité et politique de clé sont trois portes

Le concentrateur VPN décide qui peut ouvrir un tunnel et quelles adresses il peut toucher. Le HSM décide seul quel enregistrement utilisateur présenté peut se connecter. La politique de clé décide ensuite ce que cet enregistrement peut faire avec une clé précise. Franchir la première porte laisse les deux autres exactement comme elles étaient, c'est pourquoi une poignée de main réussie prouve si peu et pourquoi un partenaire peut atteindre l'appareil et échouer malgré tout à chaque opération.

Associez chaque porte à un propriétaire avant d'écrire des exigences. Quand personne ne possède la deuxième, le résultat habituel est qu'une identité d'administrateur HSM large est distribuée, parce que c'est le seul justificatif qui fonctionne.

Première porte : le chemin réseau accordé au partenaire

Nommez le client ou le service approuvé, la destination dont il a besoin, ainsi que le protocole et le port sur lesquels ce service écoute. Limitez ensuite l'accès côté VPN à cette paire dans les deux sens, y compris le chemin de retour, afin que la politique soit une phrase que vous pouvez lire au partenaire. L'administration de la passerelle, les interfaces de gestion du HSM et les systèmes internes non liés devraient rester hors de l'accès ordinaire du partenaire, pas seulement hors de la route par défaut.

Un segment dédié rend ces traversées visibles, mais le nom d'un segment n'impose rien. Le trafic doit passer par le contrôle par lequel vous croyez qu'il passe. Admettre une connexion du partenaire n'est pas non plus une déclaration que chaque machine chez le partenaire est digne de confiance.

Deuxième porte : ce qui s'authentifie réellement auprès du HSM

Une identité VPN et une identité HSM sont des objets distincts, sauf si une intégration prise en charge les joint délibérément. Avec un client PKCS#11, l'application effectue une connexion à un emplacement avec un justificatif stocké quelque part sur l'hôte du partenaire, et c'est cette connexion que le HSM évalue.

AWS CloudHSM est une référence utile parce que sa documentation garde les deux à part : les utilisateurs HSM sont distincts des utilisateurs IAM, et le type d'utilisateur régit ce que le compte peut faire. Un responsable de chiffrement gère les utilisateurs et les clés mais n'est pas l'identité qui effectue les opérations cryptographiques, tandis qu'un utilisateur de chiffrement peut utiliser des clés sans pouvoir les gérer. Cette séparation est la forme que vous voulez même sur l'appareil d'un autre fournisseur, où les noms des rôles différeront.

Quelle que soit l'identité que vous délivrez, elle doit être révocable et attribuable à la granularité dont vous aurez besoin plus tard. Un justificatif opérationnel partagé entre plusieurs partenaires rend le confinement et la responsabilité plus difficiles précisément dans l'incident où les deux comptent le plus.

Troisième porte : quelle clé, et quelle opération

La signature, le déchiffrement, la génération de clés, l'emballage de clés et l'administration des utilisateurs sont des permissions distinctes et doivent être listées séparément. En termes PKCS#11, des attributs comme CKA_SENSITIVE et CKA_EXTRACTABLE décrivent si le matériel de clé peut quitter le module sous une forme utilisable, et ils sont définis par clé et non par appareil. Lisez la politique réelle sur la clé au lieu de déduire la non-exportabilité du mot matériel ou de la présence d'un tunnel.

Cherchez ensuite l'approbation métier. Si seuls des documents approuvés peuvent être signés, quel composant établit cette approbation avant que la demande n'atteigne le HSM ? Une interface cryptographique qui accepte une demande autorisée ne sait pas si le document a été relu, donc ce contrôle appartient au service qui la précède.

Un client autorisé qui est compromis peut aussi détourner les opérations que son justificatif autorise légitimement sans jamais extraire de clé privée. Protéger le matériel de clé stocké et contrôler l'usage des clés sont donc deux conditions d'acceptation, pas une.

Les refus font partie du test d'acceptation

Acceptez la demande de signature autorisée, et acceptez aussi les refus : une identité non autorisée, une clé sans rapport et une opération d'administration depuis le chemin du partenaire. Enregistrez l'appelant, l'opération, l'identifiant de clé, l'heure et le résultat, et gardez le matériel de clé privée, les justificatifs et le contenu des documents hors des journaux de diagnostic généraux.

Désignez un propriétaire pour la sortie du partenaire, pour un compromis suspecté côté partenaire, ainsi que pour les changements de politique et la reprise. Changer une route ne rétablit pas la confiance dans un hôte qui peut déjà être compromis, donc la révocation doit aussi atteindre l'identité HSM.

Une poignée de main VPN achevée appartient à cet enregistrement. Elle ne peut pas remplacer un seul résultat propre au HSM.