Dimensionner un cluster HSM à forte charge transactionnelle

Un cluster HSM (Hardware Security Module) à forte charge ne se dimensionne pas avec le nombre de nœuds annoncé sur une fiche constructeur. La capacité dépend de l’opération cryptographique exacte, du protocole client, de la concurrence et surtout de la latence admissible au percentile élevé.

→ Lire l’explication complète de la marmotte

Débit cryptographique : mesurer l’opération, pas la boîte

Le compromis central est brutal : acheter de la capacité cryptographique réduit la latence et le risque de saturation, mais augmente le coût matériel, les licences et la complexité d’exploitation. Pour du paiement ou de la signature de masse, il faut surdimensionner la capacité utile, pas viser le débit maximal de laboratoire. La recommandation est de maintenir une charge nominale sous 60 % du débit mesuré pour l’opération réelle. Au-delà, la latence de queue prend le contrôle et le cluster devient une machine à fabriquer des incidents très chers.

Une signature RSA (Rivest, Shamir, Adleman) avec une clé de 3 072 bits, une signature ECDSA (Elliptic Curve Digital Signature Algorithm) sur P-256 et un chiffrement AES (Advanced Encryption Standard) ne consomment pas les mêmes ressources internes. Les chiffres « opérations par seconde » des constructeurs mélangent souvent des mécanismes rapides, des tailles de clés modestes et une concurrence optimiste. Une valeur AES ne prédit rien sur un service de signature RSA. Ce serait pratique, donc naturellement ce n’est pas le cas.

La capacité à mesurer est celle de la chaîne entière :

acquisition d’une session PKCS#11 (Public-Key Cryptography Standards #11) ;
authentification éventuelle auprès du module ;
recherche ou ouverture de l’objet de clé ;
opération cryptographique ;
retour réseau, sérialisation et traitement applicatif.

Le débit de signature doit être exprimé par mécanisme, taille de clé, politique de signature et taille de message. Pour un paiement, distinguer notamment les opérations de vérification de code d’authentification, de chiffrement de PIN (Personal Identification Number) et de calcul de MAC (Message Authentication Code). Pour une autorité de certification ou une plateforme documentaire, isoler les signatures RSA-PSS (Probabilistic Signature Scheme), RSA PKCS#1 v1.5 et ECDSA. Une clé activée sous politique de double contrôle ou soumise à une validation distante ne suit pas le même profil qu’une clé de service librement accessible.

La formule de capacité doit inclure la marge de défaillance :

capacité_nécessaire =
  pic_opérations_seconde
  × marge_de_croissance
  × marge_de_bascule
  / taux_d_utilisation_cible

Exemple :
20 000 signatures/s × 1,30 × 2 / 0,60 = 86 667 signatures/s installées

Le facteur de bascule vaut 2 lorsqu’un site ou un groupe de modules doit absorber seul le trafic critique. Répartir 40 000 signatures/s sur quatre modules qui n’en tiennent chacun que 12 000 n’est pas de la haute disponibilité, c’est une démonstration de physique appliquée à l’astreinte.

L’architecture HSM haute disponibilité traite la redondance, la synchronisation et les bascules. Ici, la règle supplémentaire est que la redondance doit porter la charge de pointe avec la marge définie, pas seulement répondre à un test de ping.

Latence de queue, sessions PKCS#11 et concurrence applicative

Le débit moyen masque le défaut qui casse les plateformes transactionnelles : la latence au percentile 99,9. Une moyenne de 5 millisecondes peut coexister avec des pointes à plusieurs secondes lorsque les requêtes attendent une session, un verrou de clé ou un créneau matériel. En paiement synchrone, ces pointes produisent des expirations côté acquéreur, des rejouements et parfois des doublons métier. Le HSM ne sait rien du doublon métier, il signe avec le même sérieux une première demande et sa cousine revenue trois fois.

Chaque processus client doit disposer d’un pool de sessions borné. Ouvrir une session par requête détruit le débit par surcoût de création et peut épuiser la limite du module. Partager une session PKCS#11 entre threads sans garantie explicite du fournisseur introduit des erreurs intermittentes, les plus élégantes parce qu’elles disparaissent dès qu’on active la journalisation.

Dimensionner séparément :

le nombre de connexions réseau vers chaque HSM ;
le nombre de sessions PKCS#11 ouvertes ;
le nombre de requêtes concurrentes par session ;
la taille maximale de la file d’attente applicative ;
le délai d’expiration de bout en bout.

Une file d’attente non bornée ne lisse pas un pic, elle déplace l’effondrement dans le temps. À saturation, refuser tôt avec un code explicite vaut mieux que conserver des demandes pendant trente secondes puis les signer après l’expiration métier. Le mécanisme de limitation doit se situer avant le pool de sessions, avec des quotas par service consommateur si plusieurs applications partagent le cluster.

Les objets cryptographiques doivent être adressés par identifiant stable, non par libellé textuel. Une recherche PKCS#11 par label à chaque opération force un parcours d’objets, parfois sérialisé par le middleware. Charger le handle de clé au démarrage est acceptable seulement si le fournisseur garantit sa stabilité pendant la durée de vie de la session. Sinon, conserver l’identifiant et résoudre le handle lors de la recréation de session.

Tests de charge HSM reproductibles

Un test valable rejoue le mécanisme de production : mêmes clés, même algorithme, même réseau, même bibliothèque PKCS#11 et même nombre de clients. Tester un HSM avec openssl speed sur le processeur local mesure surtout la capacité du processeur local à ne pas utiliser le HSM. C’est une information, mais pas celle recherchée.

Le test doit produire au minimum : opérations par seconde, latence médiane, percentiles 95, 99 et 99,9, erreurs PKCS#11, sessions ouvertes, profondeur de file et utilisation de chaque module. Exécuter un palier stable de quinze minutes, puis des paliers croissants jusqu’au refus ou à la violation de la latence cible. Un pic de deux minutes flatte les graphiques et ne révèle ni la dérive mémoire ni les quotas internes.

Exemple reproductible avec pkcs11-tool, pour mesurer des signatures RSA PKCS#1 v1.5 depuis un hôte de test Linux. La clé privée doit déjà exister dans le HSM et être autorisée pour la signature.

#!/usr/bin/env bash
# Dépendance : paquet opensc et bibliothèque PKCS#11 du fournisseur.
# Remplacer le chemin et l'identifiant hexadécimal de clé par ceux du token de test.
set -euo pipefail

MODULE="/opt/vendor/lib/libpkcs11.so"
KEY_ID="01"
PAYLOAD="payload.bin"

# Génère un message constant de 32 octets : le test isole la signature,
# pas le coût de génération des données applicatives.
head -c 32 /dev/zero > "${PAYLOAD}"

# Lance 16 clients, chacun avec 1 000 signatures.
# Collecter durée, erreurs et latence dans l'outil d'orchestration externe.
seq 16 | xargs -n1 -P16 sh -c '
  for n in $(seq 1 1000); do
    pkcs11-tool --module "'"${MODULE}"'" \
      --sign --mechanism RSA-PKCS \
      --id "'"${KEY_ID}"'" \
      --input-file "'"${PAYLOAD}"'" \
      --output-file /dev/null
  done
'

Ce test ne remplace pas un générateur de charge instrumenté : le démarrage d’un processus par signature fausse la latence absolue. Il reste utile pour valider le chemin PKCS#11, les droits de clé et la répartition entre modules avant d’intégrer la bibliothèque cliente à un banc de charge persistant.

Répartition, affinité de clé et limites du scale-out

Ajouter des HSM augmente le débit seulement si les requêtes peuvent être réparties. Une clé privée présente sur un seul module reste un goulot d’étranglement, même au milieu d’un rack rempli de matériel fort coûteux. La synchronisation de clé doit donc être vérifiée pour chaque domaine cryptographique, y compris après création, rotation et restauration.

Deux stratégies existent. La première duplique les clés de service sur tous les membres du groupe. Elle maximise la capacité et tolère la perte d’un module, mais agrandit la surface d’exposition administrative : chaque membre détient le même secret. La seconde affecte une clé ou un tenant à un sous-ensemble de modules. Elle réduit le rayon d’impact, mais crée des îlots de capacité et complique la bascule. Pour la signature de masse avec une même clé, la duplication contrôlée est le choix rationnel, à condition que les procédures de cérémonie de clé et de révocation soient maîtrisées.

La distribution doit être consciente de l’état. Un équilibrage réseau au hasard ne voit ni les sessions PKCS#11 ni l’affinité des clés. Préférer un client HSM ou un proxy fournisseur capable de suivre la santé cryptographique réelle : session ouverte, authentification valide, clé visible et latence mesurée. Un port TCP ouvert n’indique pas qu’une signature est possible. Un poisson rouge peut écouter sur un port TCP.

La rotation modifie aussi la capacité. Pendant une rotation, deux versions de clé peuvent devoir rester actives pour vérifier l’historique ou terminer les flux en cours. Mesurer le débit avec les deux versions chargées et avec les politiques d’accès réelles. Les principes de rotation des clés s’appliquent, mais une rotation non testée sous charge devient un événement de capacité, pas un entretien discret.

Surface d’attaque et exploitation sous charge

La saturation est une attaque disponible à n’importe quel consommateur autorisé. Une avalanche de signatures légitimes suffit à priver les flux prioritaires si aucun quota n’existe. Isoler les partitions, comptes ou rôles par application, puis appliquer des limites de débit avant le HSM. Réserver une capacité dédiée aux opérations de reprise, de révocation et d’administration. Sans cette réserve, un incident de charge peut empêcher la correction qui permettrait de le traiter. Le serpent administratif se mord la queue avec une ponctualité remarquable.

Les mécanismes d’enveloppe réduisent souvent la pression sur le HSM : utiliser le module pour protéger une clé de chiffrement de données, puis chiffrer les volumes avec cette clé hors du module. Cette architecture n’est pertinente que pour le chiffrement de données et non pour une signature non exportable. La page sur l’envelope encryption détaille ce partage des rôles, et celle sur KEK et DEK précise la différence entre clé de protection et clé de données.

Un HSM ne garantit pas :

que l’appelant est autorisé au niveau métier à signer une transaction ;
que le message signé est complet, non rejoué ou correctement canonisé ;
que l’horodatage est fiable ;
que la clé compromise avant son import n’a jamais été copiée ;
que les journaux d’audit sortent du module ni qu’ils sont conservés.

L’authentification applicative, l’anti-rejeu, la validation des formats, l’horodatage et la conservation probante doivent venir des couches voisines. Le HSM protège l’usage de la clé selon sa politique, pas la qualité des décisions qui lui sont soumises.

Superviser les codes de retour PKCS#11, les échecs d’authentification, les erreurs de mécanisme, l’épuisement de sessions, les changements de rôle et les opérations administratives. Exporter les journaux vers une plateforme indépendante du cluster. Tester aussi la restauration : sauvegarder les clés enveloppées, les domaines de sécurité, les configurations de partitions et les secrets de connexion ne suffit que si une restauration sur matériel vierge a été exécutée et chronométrée.

🐝 Ce qui arrive si on s’en passe

Sans quota par service consommateur ni file bornée devant le cluster, rien ne plafonne le nombre de requêtes qu’un client autorisé, mais compromis, peut adresser à une même clé. Or plusieurs attaques cryptographiques reposent justement sur le volume : un oracle de remplissage exige des dizaines de milliers à des millions de déchiffrements RSA PKCS#1 v1.5 soumis au module, ce que décrit la brèche « la question qui rend le module bavard ». Un cluster dimensionné pour absorber n’importe quel pic, sans limitation préalable, offre à cet oracle le débit dont il a besoin, et ses dizaines de milliers d’erreurs de déchiffrement se diluent dans le trafic légitime au lieu de déclencher un seuil d’alerte par consommateur.

🦫 Explication de la marmotte 🍫

Un module matériel de sécurité conserve des clés secrètes et réalise des calculs sensibles, par exemple signer une transaction ou chiffrer une information. Pour traiter beaucoup de demandes, plusieurs modules peuvent travailler ensemble. Mais il faut mesurer chaque type de calcul séparément : signer avec une grosse clé demande plus de travail que chiffrer un petit message.

Les applications envoient des demandes aux modules par des connexions ouvertes à l’avance. Si elles créent une connexion pour chaque demande, elles perdent du temps. Si elles en créent trop, le matériel refuse les nouvelles demandes. Il faut donc fixer un nombre maximal de connexions et de demandes en attente.

La charge doit rester sous une limite choisie. Sinon, les demandes attendent dans une file, les délais augmentent et les services qui attendent une réponse abandonnent. Lorsqu’un module tombe en panne, les autres doivent pouvoir prendre sa charge maximale, pas seulement une charge normale.

Les clés nécessaires doivent être présentes sur les modules qui doivent signer. Une clé sur un seul appareil limite toute la capacité à cet appareil. Les essais doivent reproduire les vraies demandes, avec le même logiciel et le même réseau. Enfin, il faut limiter chaque application pour empêcher qu’une surcharge ou une attaque bloque les autres, surveiller les erreurs et tester la restauration des clés et des réglages après une panne.

Pages voisines

La citent

Dimensionner un cluster HSM à forte charge transactionnelle

Elle cite

: les deux pages se citent l’une l’autre.

Dimensionner un cluster HSM à forte charge transactionnelle

Dimensionner un cluster HSM à forte charge transactionnelle

Débit cryptographique : mesurer l’opération, pas la boîte

Latence de queue, sessions PKCS#11 et concurrence applicative

Tests de charge HSM reproductibles

Répartition, affinité de clé et limites du scale-out

Surface d’attaque et exploitation sous charge

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines