Surveiller les usages anormaux d’un HSM

Un HSM (Hardware Security Module) protège la matière de clé, pas l’intention de celui qui l’emploie. Sans audit centralisé, une signature frauduleuse et une signature légitime restent deux appels réussis dans une boîte noire fort coûteuse.

→ Lire l’explication complète de la marmotte

Le compromis est net : journaliser chaque opération cryptographique augmente le volume, la charge d’export et le coût de conservation, mais réduit drastiquement le temps nécessaire pour établir ce qui s’est passé. Pour les clés de signature, de chiffrement de données ou de protection d’autres clés, il faut payer ce coût. Désactiver l’audit détaillé pour économiser quelques gigaoctets revient à installer une caméra de sécurité sans disque dur. Très moderne sur une slide, beaucoup moins après incident.

Cette fiche complète les principes exposés dans le dossier HSM et PKCS#11 et doit être articulée avec la gestion du cycle de vie des clés.

Préparer l’audit du HSM et la collecte centrale

Avant toute configuration, inventorier les partitions ou tokens, les objets cryptographiques, leurs identifiants stables, les rôles d’administration et les applications autorisées. PKCS#11 (Public-Key Cryptography Standards numéro 11) expose des attributs comme CKA_ID, CKA_LABEL et le type de mécanisme utilisé. Le libellé est destiné aux humains, pas à la corrélation : deux objets peuvent partager un même libellé. La détection doit reposer sur l’identifiant immuable de la clé, la partition et l’identité de session.

Vérifier quatre prérequis :

Le microprogramme du module doit prendre en charge un journal d’audit inviolable ou signé. Un journal réécrivable par l’administrateur local n’est pas une preuve, seulement un indicateur.
La licence ou l’option d’audit doit couvrir les opérations cryptographiques, les ouvertures de session et les échecs d’authentification. Certains matériels journalisent par défaut l’administration, puis oublient opportunément les signatures applicatives.
Le collecteur central doit accepter du Transport Layer Security, TLS, avec authentification mutuelle par certificat. Syslog en User Datagram Protocol, UDP, n’apporte ni garantie de livraison ni identité forte de l’émetteur.
Les horloges du HSM, des hôtes clients et de la plateforme de collecte doivent être synchronisées par NTP (Network Time Protocol) ou PTP (Precision Time Protocol), avec surveillance de dérive. Une alerte nocturne est inutilisable si trois équipements ne sont pas d’accord sur l’heure.

Créer un compte ou rôle d’audit distinct du rôle de sécurité et du rôle d’exploitation. Ce compte doit pouvoir lire, exporter et vérifier les journaux, jamais créer une clé, modifier une politique ou effacer l’historique. La séparation des rôles ne survit pas à un compte partagé. Vingt ans de métier apprennent aussi qu’un compte nommé audit avec le même mot de passe que admin ne sépare rien, à part les colonnes d’un tableur.

Conserver au minimum les champs suivants dans chaque événement :

horodatage avec fuseau et précision ;
identifiant du module, partition ou token ;
identité authentifiée, rôle et source réseau quand elle existe ;
identifiant immuable de la clé, jamais seulement son nom ;
opération demandée : signature, chiffrement, déchiffrement, wrap, unwrap, dérivation ou génération ;
mécanisme cryptographique, par exemple RSA-PSS ou AES-GCM ;
résultat, code d’erreur et motif de refus ;
compteur de séquence et signature ou code d’intégrité du journal.

L’adresse IP seule ne permet pas d’attribuer un usage de clé à une application lorsque plusieurs services partagent un bastion, un proxy ou une identité PKCS#11. Le lien entre session applicative, identité de charge de travail et session HSM doit être produit côté application ou middleware. Le module voit l’appel, pas la raison métier qui l’a déclenché.

Activer les événements d’audit natifs du module

Activer l’audit sur le HSM avant d’ouvrir les flux vers le collecteur. L’ordre compte : un export actif mais un audit incomplet donne l’illusion d’une couverture, ce qui est une catégorie de panne très appréciée des comités de crise.

Configurer au minimum les catégories suivantes dans la politique native du constructeur :

Authentification : ouverture et fermeture de session, échecs, verrouillages, déverrouillages, changements de rôle et élévations de privilèges.
Cycle de vie des clés : création, import, destruction, activation, désactivation, modification d’attributs et changement de politique d’usage.
Opérations cryptographiques : initialisation, succès et erreur pour signature, vérification, chiffrement, déchiffrement, wrap, unwrap et dérivation.
Administration : changement de configuration réseau, firmware, certificats de journalisation, destination d’export et politiques d’audit.
Intégrité : redémarrage, perte de connectivité, tampon saturé, échec de signature d’audit et trou de compteur de séquence.

Éviter le filtrage sur les seules erreurs. Une extraction en masse par C_UnwrapKey ou une utilisation abusive de C_Sign peut être parfaitement autorisée et donc réussir. L’usage anormal se détecte par la séquence, le volume, l’heure et l’identité, pas par le seul code retour.

Chaque événement doit être horodaté et signé par le HSM lorsque le produit le permet. Exporter également les clés publiques ou certificats nécessaires à la vérification des signatures de journaux. Les conserver hors du HSM, dans le dépôt de preuves de l’organisation, avec leur période de validité. Une rotation du certificat d’audit sans conservation de l’ancien certificat rend les anciens événements impossibles à vérifier. C’est une forme assez élégante d’autodestruction documentaire.

Définir une rétention locale courte mais non nulle. Le tampon interne doit couvrir une indisponibilité temporaire du collecteur, puis refuser ou alerter avant écrasement. La durée exacte dépend du débit maximal et du stockage disponible, mais le comportement doit être explicite : écraser silencieusement les premiers événements est inacceptable pour une piste d’audit.

Exporter les journaux HSM vers le collecteur central

Préférer un export initié par le HSM vers un relais de journalisation dédié, puis vers le SIEM (Security Information and Event Management). Cette topologie évite d’installer un agent généraliste sur le matériel cryptographique et limite les dépendances sur un composant qui doit rester austère. Un HSM n’est pas un serveur Linux miniature destiné à recevoir la dernière pile d’agents à la mode.

Le relais doit établir une session TLS mutuelle avec le collecteur, vérifier le certificat présenté par le HSM ou son concentrateur, et mettre en file les messages en cas de coupure. Activer des files persistantes sur disque chiffré. Une file uniquement en mémoire perd les événements exactement pendant la panne réseau qu’il faudra ensuite expliquer.

Exemple de relais syslog avec file persistante

L’exemple suivant configure rsyslog pour lire un fichier alimenté par le connecteur d’audit du HSM, puis l’expédier vers un collecteur TLS. Le connecteur doit être paramétré pour écrire des événements JSON (JavaScript Object Notation) complets dans /var/log/hsm/audit.json.

# Lire les événements natifs exportés localement par le connecteur HSM.
module(load="imfile")

input(
  type="imfile"
  File="/var/log/hsm/audit.json"
  Tag="hsm-audit:"
  Facility="local6"
  Severity="info"
  PersistStateInterval="100"
)

# Conserver une file disque si le collecteur central devient indisponible.
action(
  type="omfwd"
  Target="siem.collecte.interne"
  Port="6514"
  Protocol="tcp"
  StreamDriver="gtls"
  StreamDriverMode="1"
  StreamDriverAuthMode="x509/name"
  StreamDriverPermittedPeers="siem.collecte.interne"
  QueueType="LinkedList"
  QueueFileName="hsm-audit"
  QueueSaveOnShutdown="on"
  ActionResumeRetryCount="-1"
)

Tester d’abord la chaîne de transport avec un événement de test explicitement marqué, puis vérifier dans le collecteur la conservation du JSON original, du nom du relais et de l’horodatage de réception. Ne pas normaliser trop tôt. La normalisation peut ajouter des champs pour la recherche, mais doit préserver la preuve brute, sa signature et son compteur de séquence.

Surveiller le délai d’ingestion, la profondeur de file, les rejets de certificat et les trous de séquence. Une absence de journaux doit déclencher une alerte distincte de l’absence d’activité cryptographique. Une clé inactive peut être normale ; un HSM silencieux ne l’est pas forcément.

Détecter les usages anormaux des clés

Les règles doivent être définies par clé ou par classe de clés. Une clé de signature de certificat, une clé de chiffrement de base de données et une KEK (Key Encryption Key), clé utilisée pour chiffrer d’autres clés, n’ont ni le même rythme ni la même tolérance aux écarts.

Commencer avec trois règles, puis régler les seuils sur une période représentative sans désactiver les alertes. Une période d’observation n’est pas une permission de détourner le regard.

Usage hors fenêtre attendue : alerter lorsqu’une clé est utilisée en dehors de sa plage horaire autorisée, sauf identité de secours explicitement déclarée. La règle doit utiliser le fuseau métier et les fenêtres de maintenance. Un usage nocturne d’une clé de signature de lot peut être normal ; un C_UnwrapKey nocturne depuis une identité d’administration mérite une escalade.
Volume cryptographique anormal : compter les succès par identifiant de clé, mécanisme, identité et fenêtre glissante. Déclencher si le volume dépasse à la fois un seuil absolu et un multiple de la référence historique. Un seuil uniquement relatif déclenche sur une clé rarement employée, un seuil uniquement absolu rate les usages faibles mais aberrants. Pour les opérations de wrap ou unwrap, préférer un seuil particulièrement bas : quelques dizaines d’opérations peuvent déjà indiquer une exportation massive de matériel chiffré.
Échecs d’authentification répétés : alerter sur cinq échecs en dix minutes pour un même compte, une même source ou une même partition, puis sur toute tentative réussie suivant immédiatement cette série. Corréler avec verrouillage de compte et changement de rôle. Un verrouillage sans alerte n’est qu’un bruit mécanique dans une salle serveur.

Ajouter des exclusions temporaires uniquement avec une date de fin et une référence de changement. Une exception permanente devient une règle de détection morte, avec un nom plus poli.

Tester l’alerte et organiser la réponse

Une règle non testée est une hypothèse décorative. Exécuter le test sur une clé de laboratoire dont les attributs, le mécanisme et la politique reproduisent la clé surveillée. Ne jamais provoquer volontairement une rafale sur une clé de production pour vérifier une alerte : l’exercice de sécurité qui dégrade le service mérite rarement un trophée.

Procéder dans cet ordre :

vérifier que l’événement natif est créé et signé sur le HSM ;
vérifier sa réception brute au relais ;
vérifier son indexation avec l’identifiant de clé intact ;
générer le scénario : usage hors créneau, rafale contrôlée ou authentifications erronées ;
vérifier le déclenchement, la déduplication et la priorité de l’alerte ;
vérifier l’arrivée dans la file de l’équipe d’astreinte et l’exécution du runbook.

Le runbook doit indiquer qui peut suspendre une identité applicative, désactiver une clé, isoler un client PKCS#11 et préserver les journaux. Il doit aussi préciser ce qui ne doit pas être fait : supprimer un token, réinitialiser un HSM ou redémarrer un relais avant extraction des preuves. La disponibilité du service et la conservation de preuve entrent parfois en conflit. Le choix doit être préparé, pas improvisé à 02:17 entre deux cafés tièdes.

Cette surveillance ne garantit pas que l’usage est légitime. Un compte applicatif compromis peut employer une clé dans les horaires normaux et sous un volume normal. La détection comportementale doit donc être complétée par des identités de charge de travail distinctes, des droits PKCS#11 minimaux, une segmentation réseau et une revue des autorisations. Les mécanismes de fédération et d’identité sont traités dans la section identités et contrôle d’accès.

🐝 Ce qui arrive si on s’en passe

Sans journal d’audit exporté, une clé compromise ne se mesure plus : impossible de dire quels documents ont été signés, ni pendant quelle fenêtre, donc la seule réponse restante est de révoquer et réémettre tout ce que la clé a couvert depuis sa création. La non-répudiation tombe avec elle, puisqu’aucune preuve datée et signée ne rattache une signature à une identité. Les attaques qui reposent sur des milliers d’appels réussis passent alors pour du trafic ordinaire, comme le montre la brèche « la question qui rend le module bavard », dont la signature visible est précisément un volume aberrant de déchiffrements. S’ajoute la perte de reprise : après incident, ni compteur de séquence ni horodatage fiable ne permettent de reconstituer la chronologie, et la décision de remise en service se prend à l’aveugle.

🦫 Explication de la marmotte 🍫

Un module cryptographique matériel est un appareil qui garde des clés secrètes et réalise des opérations avec elles sans les révéler. Une application lui demande par exemple de signer un document ou de chiffrer une donnée. Pour repérer un mauvais usage, l’appareil doit enregistrer chaque demande : quelle clé a été utilisée, par quelle identité, à quel moment, pour quelle action et avec quel résultat.

Ces enregistrements sont envoyés vers un système central qui reçoit aussi les journaux d’autres équipements. Le transport doit être protégé et contrôlé, sinon quelqu’un pourrait modifier ou faire disparaître les informations en route. Le système central conserve les messages bruts et cherche des comportements inhabituels.

Une alerte peut apparaître lorsqu’une clé est utilisée à une heure où elle ne devrait pas l’être, lorsqu’elle sert beaucoup plus souvent que prévu, ou lorsqu’une personne échoue plusieurs fois à s’identifier. Une alerte ne prouve pas une attaque : elle demande une vérification. L’équipe regarde alors l’identité utilisée, la machine d’origine, la clé concernée et les autres événements proches dans le temps.

Le dispositif doit être testé avec une clé de laboratoire. Si l’alerte n’arrive pas à l’équipe chargée de réagir, ou si les événements disparaissent pendant une panne réseau, la surveillance échoue. Enfin, ce contrôle ne bloque pas automatiquement une personne qui possède déjà une identité autorisée : les droits, les mots de passe, le réseau et les règles d’accès restent nécessaires.

Pages voisines

La citent

Surveiller les usages anormaux d’un HSM

Elle cite

Surveiller les usages anormaux d’un HSM

Surveiller les usages anormaux d’un HSM

Préparer l’audit du HSM et la collecte centrale

Activer les événements d’audit natifs du module

Exporter les journaux HSM vers le collecteur central

Exemple de relais syslog avec file persistante

Détecter les usages anormaux des clés

Tester l’alerte et organiser la réponse

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines