Comment isoler les clés dans un HSM multi-tenant

Un HSM (Hardware Security Module) partagé réduit le coût matériel et centralise les opérations cryptographiques, mais il concentre aussi le risque d’administration, de disponibilité et de configuration. La bonne unité d’isolation n’est pas l’application ni l’équipe au sens organisationnel : c’est le domaine de confiance qui partage les mêmes administrateurs, exigences de rotation et conséquences en cas de compromission.

→ Lire l’explication complète de la marmotte

Partition HSM : l’unité de confiance à imposer

Une partition est un espace logique isolé dans le HSM. Elle possède généralement ses propres objets cryptographiques, identifiants d’accès, politiques d’usage et parfois ses propres clés d’authentification d’administrateur. Selon le constructeur, elle peut aussi porter un domaine de sécurité matériel distinct ou une séparation seulement appliquée par le micrologiciel. Cette différence ne relève pas du marketing, même si certaines plaquettes semblent écrites par un générateur de fumée.

La règle de base est nette : une partition par domaine de confiance, pas une partition par microservice. Une même équipe qui exploite plusieurs applications avec les mêmes opérateurs, la même procédure de sauvegarde et le même niveau de sensibilité peut partager une partition. Deux équipes dont les administrateurs ne doivent pas pouvoir exporter, supprimer ou utiliser les clés de l’autre doivent disposer de partitions distinctes.

Le compromis central est le suivant : partager un HSM apporte densité, standardisation et exploitation centralisée ; séparer les partitions limite le rayon d’explosion d’un compte compromis ou d’une erreur d’exploitation. Le prix est réel : davantage d’identités, de politiques, de sauvegardes et de contrôles. Ce prix doit être payé. Une partition unique avec des préfixes de noms du type paiement-prod- et rh-prod- n’est pas du multi-tenant, c’est une foi très optimiste dans les conventions de nommage.

Une partition ne doit jamais contenir à la fois des clés de production et de préproduction. Les environnements non productifs reçoivent d’autres partitions, avec d’autres identités et des clés sans valeur opérationnelle. Copier une clé de production pour « reproduire le bug » transforme un incident applicatif en incident cryptographique. Le bug, lui, sera probablement toujours là.

Pour les clés de chiffrement de données, la séparation doit suivre le propriétaire de la KEK (Key Encryption Key), c’est-à-dire la clé qui protège d’autres clés. Une application peut générer des DEK (Data Encryption Key), clés utilisées directement sur les données, puis les envelopper avec une KEK propre à sa partition. La stratégie d’envelope encryption reste valable, mais chaque KEK racine doit rester attachée à un seul domaine de confiance.

Identités PKCS#11 et droits par application

PKCS#11 (Public-Key Cryptography Standards numéro 11) expose les objets et opérations du HSM à travers une interface standard : ouverture de session, recherche d’objet, signature, chiffrement, dérivation ou destruction. Le standard ne définit pas à lui seul un modèle multi-tenant complet. L’isolation effective dépend du HSM, de son client logiciel, de la façon dont une application sélectionne sa partition et des rôles autorisés.

Chaque application doit disposer d’une identité distincte dans sa partition. Partager un code PIN (Personal Identification Number) d’utilisateur entre plusieurs applications interdit toute attribution fiable dans les journaux et rend la révocation brutale : couper un accès coupe tout le monde. Une identité par processus de sécurité est le minimum ; une identité par instance peut être justifiée lorsque les capacités d’audit ou de révocation du produit le permettent sans rendre l’exploitation absurde.

Les droits doivent être séparés en trois rôles :

l’administrateur de partition crée les identités, règle les politiques et déclenche les opérations de sauvegarde ;
l’opérateur de clés crée, active, désactive ou détruit les objets selon une procédure contrôlée ;
le compte applicatif ne peut utiliser que les clés nécessaires, idéalement sans export, suppression ni modification d’attributs.

Le compte applicatif ne doit pas avoir le droit de créer des clés de longue durée par défaut. La génération libre facilite les essais, puis produit des objets orphelins dont personne ne connaît l’usage. Pour une clé persistante, exiger une demande identifiée, un libellé normalisé, un propriétaire et une date de revue. Un HSM n’est pas un grenier à clés avec une jolie diode.

Les attributs PKCS#11 doivent bloquer ce qui n’est pas nécessaire. Une clé de signature doit être CKA_SIGN=true et ne pas porter CKA_DECRYPT=true. Une clé de chiffrement ne doit pas signer. CKA_EXTRACTABLE=false doit être imposé pour toute clé privée ou symétrique qui ne doit jamais sortir du module. Cette propriété ne protège toutefois pas contre l’usage abusif par une session déjà authentifiée : elle empêche l’extraction, pas l’appel à C_Sign ou C_Decrypt.

Les conventions de libellés servent à l’exploitation, pas à l’autorisation. Utiliser un identifiant immuable, un propriétaire, un environnement et une version, par exemple billing/prod/kek/v003. Ne jamais sélectionner une clé seulement par son CKA_LABEL si des doublons sont possibles. Rechercher également par identifiant binaire CKA_ID, contrôlé lors de la création.

Exemple PKCS#11 : créer une clé dans une partition dédiée

La sélection de partition est généralement réalisée par le point d’accès fourni par le constructeur, le logement logique exposé au client ou une configuration de bibliothèque. Une fois la partition sélectionnée, pkcs11-tool, fourni par OpenSC, permet de vérifier le comportement sans ajouter de code applicatif.

# Ouvrir la partition déjà exposée comme logement 2.
# Le chemin doit pointer vers la bibliothèque PKCS#11 du HSM.
export PKCS11_MODULE=/opt/hsm/lib/libvendorpkcs11.so

# Générer une clé AES de 256 bits non extractible.
# Le PIN est fourni par un mécanisme de secrets, jamais placé dans l'historique shell.
pkcs11-tool \
  --module "$PKCS11_MODULE" \
  --slot-index 2 \
  --login \
  --pin "$HSM_APP_PIN" \
  --keygen --key-type AES:32 \
  --id 62696c6c696e672d70726f642d6b656b2d303033 \
  --label "billing/prod/kek/v003" \
  --usage-wrap --usage-unwrap \
  --private

# Vérifier que la clé est visible depuis cette partition.
pkcs11-tool \
  --module "$PKCS11_MODULE" \
  --slot-index 2 \
  --login \
  --pin "$HSM_APP_PIN" \
  --list-objects --type secrkey

La commande ne rend pas automatiquement la clé non extractible : ce comportement dépend du modèle d’attributs du fournisseur et de sa politique de partition. Après création, contrôler les attributs effectifs avec l’outil constructeur ou une requête PKCS#11 adaptée. Toute différence entre l’attribut demandé et l’attribut stocké est un écart de sécurité, pas une curiosité de laboratoire.

Pour une clé de chiffrement d’enveloppe, limiter l’usage à wrap et unwrap. La page KEK et DEK détaille pourquoi une même clé ne doit pas servir à la fois à protéger des données et à protéger d’autres clés.

Surface d’attaque d’un HSM partagé

L’isolation logique réduit la lecture directe des objets entre partitions. Elle ne supprime ni le plan d’administration commun, ni la dépendance au même matériel, ni les défauts du micrologiciel. Un administrateur global compromis peut souvent recréer des identités, modifier des politiques ou rendre une partition indisponible. Cette personne doit donc être soumise à une authentification forte, à une séparation des tâches et à une journalisation exportée hors du HSM.

Le vol d’un identifiant applicatif permet d’utiliser les clés autorisées tant que la session est ouverte. La révocation du compte ne ferme pas nécessairement les sessions PKCS#11 existantes. L’application doit gérer des durées de session bornées, reconnecter après échec d’autorisation et disposer d’un mécanisme de redémarrage contrôlé. Sans cela, la révocation devient un vœu pieux avec une date de péremption inconnue.

Les attaques par déni de service sont le défaut le plus souvent oublié. Une partition bruyante peut saturer les files de signature, les sessions ou les canaux réseau partagés. Configurer des quotas de sessions et, lorsque le produit le permet, des limites d’opérations par partition. Mesurer la latence par locataire, pas seulement la latence globale du HSM. Une moyenne globale est un excellent moyen de déclarer que personne ne se noie parce que la piscine a une profondeur moyenne de 1,40 mètre.

Le middleware client est aussi dans la surface d’attaque. Une bibliothèque PKCS#11 chargée depuis un chemin modifiable peut être remplacée et récupérer les codes PIN applicatifs. Vérifier la provenance du paquet, les permissions du fichier, l’intégrité du déploiement et l’identité du processus qui charge la bibliothèque. Le chiffrement du transport vers un HSM réseau protège le canal, pas le processus déjà compromis qui demande une signature.

Enfin, une partition n’apporte pas de confidentialité entre opérations si le constructeur ne garantit pas la résistance aux canaux auxiliaires entre locataires. Pour des domaines mutuellement hostiles, ou lorsque les exigences réglementaires imposent une séparation matérielle, utiliser des HSM distincts. L’isolation logique est un contrôle d’accès ; elle n’est pas une frontière physique déguisée en icône de console.

Rotation, sauvegarde et reprise par tenant

La rotation doit être pilotée par clé et par partition. Remplacer une KEK ne permet pas de déchiffrer automatiquement les données enveloppées par l’ancienne version. Conserver les anciennes KEK en mode déchiffrement uniquement jusqu’à la ré-enveloppe complète, puis désactiver et détruire selon une période de rétention documentée. La rotation des clés doit inclure l’inventaire des consommateurs et le test de restauration, pas seulement la génération d’une nouvelle clé.

Les sauvegardes de partition doivent rester séparées : matériel de sauvegarde, clés de domaine, procédures de restauration et détenteurs d’autorisations distincts lorsque les domaines sont distincts. Une sauvegarde globale accessible à tous les administrateurs annule l’essentiel de la segmentation. Les éléments nécessaires à une reprise doivent être testés sur une partition de restauration, sans réutiliser les secrets d’administration de production.

Superviser au minimum les échecs d’authentification, créations et destructions d’objets, changements de politique, épuisement de sessions, latence par partition et échecs de sauvegarde. Les journaux doivent contenir l’identité, la partition, le type d’opération, l’identifiant de clé et le résultat, sans enregistrer de code PIN ni de matière cryptographique. Pour la résilience de l’infrastructure commune, renvoyer à l’architecture HSM haute disponibilité. La haute disponibilité ne corrige pas une séparation de tenants ratée, elle la rend seulement disponible plus souvent.

🐝 Ce qui arrive si on s’en passe

Sans isolation par partition, un HSM partagé concentre le risque au lieu de seulement mutualiser le coût. Si les domaines de confiance ne disposent pas chacun de leur compartiment étanche, une erreur d’administration, un droit trop large ou une compromission d’un locataire peut atteindre les clés d’un autre, effaçant la séparation censée protéger chacun. La conséquence est qu’une opération légitime pour un périmètre déborde sur un autre, qu’un administrateur d’un domaine accède à des secrets qui ne le concernent pas, et qu’un incident cesse d’être confiné au compartiment d’origine. La disponibilité aussi se partage : une configuration fautive ou une saturation provoquée par un tenant se répercute sur tous ceux qui dépendent du même module. Sans découpage aligné sur les administrateurs, les exigences de rotation et les conséquences réelles d’une compromission, la mutualisation devient un mélange de responsabilités que personne ne maîtrise.

🦫 Explication de la marmotte 🍫

Un module matériel de sécurité est un appareil qui crée et utilise des clés de chiffrement sans les laisser sortir sous une forme lisible. Lorsqu’il est partagé, il contient plusieurs partitions. Une partition est une zone séparée qui regroupe les clés, les comptes et les règles d’une application ou d’une équipe.

Avant de créer une partition, il faut décider quels groupes peuvent partager des administrateurs, des sauvegardes et les conséquences d’une erreur. Chaque groupe séparé reçoit sa partition. Dans cette partition, l’application reçoit un compte propre. Ce compte peut utiliser certaines clés, mais ne doit pas pouvoir les copier, les supprimer ou modifier leurs règles.

Les clés sont créées avec un usage précis. Une clé servant à signer ne doit pas servir à déchiffrer. Une clé servant à protéger d’autres clés ne doit pas chiffrer directement les données. Les anciennes clés restent disponibles seulement le temps de lire les données protégées avant leur remplacement.

Si un compte applicatif est volé, il peut utiliser les clés auxquelles il a accès jusqu’à ce que son accès soit bloqué et que ses sessions soient fermées. Si l’administration centrale est compromise, toutes les partitions peuvent être touchées. Si l’appareil tombe en panne ou est saturé par une application, les autres applications peuvent aussi être bloquées. Il faut donc surveiller chaque partition, sauvegarder séparément ses éléments de reprise et tester régulièrement la restauration.