Journalisation native HSM pour audit externe

Un HSM (Hardware Security Module) peut protéger une clé sans produire la preuve exploitable de son usage. Pour un audit externe, la journalisation doit établir qui a demandé quelle opération, sur quel objet, depuis quel contexte, avec quel résultat, puis démontrer que cette trace n’a pas été réécrite entre-temps.

→ Lire l’explication complète de la marmotte

Journalisation native HSM : le compromis à accepter

La journalisation native est celle produite par le firmware du HSM, avant que le middleware, l’application ou le système d’exploitation puissent filtrer l’événement. C’est le bon point de départ pour démontrer qu’une opération de signature, de déchiffrement, de génération de clé ou de changement de politique a été demandée et acceptée ou refusée.

Le compromis est brutal : plus la trace décrit finement les opérations, plus elle expose des métadonnées sensibles et plus son coût d’exploitation augmente. Un journal contenant l’identifiant d’objet, le rôle authentifié, le client source, l’horodatage et le code de retour permet l’investigation. Il révèle aussi la cadence d’activité, les noms d’objets mal choisis et parfois la structure applicative. L’audit exhaustif n’autorise donc pas les libellés fantaisistes du genre cle-production-final-v2-bis. Les secrets ne sortent pas, les métadonnées bavardent très bien sans eux.

La position à retenir est nette : activer l’audit natif détaillé pour les opérations sur les clés non extractibles, les objets d’autorité de certification et les comptes d’administration. Pour les clés de chiffrement à très haute fréquence, auditer au minimum les sessions, authentifications, refus, changements de politique et événements de cycle de vie, puis compléter par une journalisation applicative corrélée. Exiger un enregistrement matériel individuel de chaque chiffrement de flux peut transformer le collecteur en pompe à incendie. Ce n’est pas une stratégie de conformité, c’est une attaque par déni de service auto-infligée.

Un événement d’audit doit porter, au minimum :

un identifiant d’événement monotone ou unique ;
l’horodatage avec fuseau ou temps universel coordonné ;
l’identité logique, le rôle et le domaine de sécurité concernés ;
l’opération demandée, l’algorithme et le mécanisme cryptographique ;
l’identifiant stable de l’objet, jamais sa valeur ;
le résultat, y compris les refus d’autorisation et les erreurs ;
l’origine réseau ou l’identifiant de processus lorsque le modèle du HSM le fournit ;
un numéro de séquence, une signature ou un mécanisme d’intégrité vérifiable.

Les opérations exposées par PKCS#11 (Public-Key Cryptography Standards #11) sont un bon référentiel de couverture : C_Login, C_Logout, C_GenerateKey, C_GenerateKeyPair, C_CreateObject, C_DestroyObject, C_WrapKey, C_UnwrapKey, C_Encrypt, C_Decrypt, C_Sign et les changements d’attributs. La page sur PKCS#11 et ses mécanismes aide à relier ces appels aux opérations observées dans les traces.

Chaîne de preuve et intégrité des journaux HSM

Un export Syslog n’est pas une preuve parce qu’il porte le mot Syslog. Entre le HSM et le stockage d’audit, chaque relais peut perdre, modifier ou rejouer un message. La chaîne de preuve doit donc être conçue comme un flux de sécurité, avec des responsabilités explicites.

Le HSM doit signer les journaux, produire des blocs chaînés ou permettre la vérification d’un compteur inviolable. Une signature numérique de lot protège l’intégrité du contenu, mais elle ne garantit pas l’absence d’un lot entier. Le numéro de séquence protège contre cette suppression si le collecteur détecte un trou. L’horodatage protège l’ordre apparent, à condition que la source de temps soit surveillée. Une horloge dérivante transforme un incident en roman expérimental.

Le collecteur doit recevoir les événements sur un canal TLS (Transport Layer Security), avec authentification mutuelle par certificat lorsque le HSM et le produit le permettent. Le certificat serveur seul chiffre le transport, mais ne prouve pas que l’émetteur est bien le HSM attendu. Les journaux doivent ensuite rejoindre un stockage en écriture append-only ou WORM (Write Once Read Many), avec rétention définie par l’exigence de contrôle concernée et non par la taille du disque disponible.

La séparation des rôles est non négociable. L’administrateur du HSM ne doit pas pouvoir effacer seul les journaux exportés, ni l’opérateur de la plateforme de journalisation modifier la politique d’audit du HSM. Une même identité disposant des deux pouvoirs peut fabriquer une histoire propre. C’est techniquement élégant, dans le sens où une fraude devient très efficace, mais rarement défendable devant un auditeur.

Prévoir aussi la conservation des éléments de vérification : certificats de signature des journaux, chaînes de certification, clés publiques, paramètres de hachage et documentation de format. Garder des journaux signés sans conserver la clé publique nécessaire à leur validation revient à archiver des cadenas sans clés. La rotation des clés HSM doit donc inclure les clés et certificats utilisés pour signer l’audit, avec chevauchement de validation.

Surface d’attaque de l’audit cryptographique

Le premier contournement consiste à réduire le niveau de journalisation avant une opération sensible, puis à le restaurer. Contrer cela impose que tout changement de politique, redémarrage, réinitialisation, passage en maintenance et modification de destination soit lui-même audité localement et exporté. Une alerte doit partir sur toute baisse de niveau, pas seulement sur les erreurs du HSM.

Le deuxième contournement vise le transport : saturation, coupure réseau, rejet du certificat du collecteur ou blocage du service de réception. Le comportement du HSM en cas d’indisponibilité doit être choisi explicitement. En mode fail-open, le HSM poursuit les opérations mais marque un trou de journalisation. En mode fail-closed, il refuse les opérations protégées tant que l’audit ne peut plus sortir. Pour une clé de signature réglementée, choisir fail-closed est généralement justifié. Pour une clé de chiffrement qui protège un service vital, un tampon local chiffré avec seuil d’alerte et durée maximale peut être acceptable. Accepter sans borne un fonctionnement sans audit ne l’est pas.

Le troisième contournement est l’abus d’identité. Un compte partagé de type crypto-admin rend la trace techniquement exacte et humainement inutile. L’authentification doit être individuelle ou fédérée avec une identité durable, puis liée à un rôle limité. Les opérations d’administration doivent exiger une séparation de connaissances ou une approbation multiple lorsque le HSM le permet. Un badge commun sur une porte sécurisée n’a jamais créé de responsabilité individuelle par magie.

Le quatrième contournement est le rejet sélectif : ne conserver que les succès masque les tentatives d’usage d’une clé interdite, les authentifications échouées et les appels avec mécanisme non autorisé. Les refus sont des événements de sécurité, pas du bruit. Ils permettent notamment de détecter une application utilisant une clé avec un mécanisme différent de celui prévu par sa politique.

Enfin, l’audit HSM ne prouve pas l’intention métier. Une entrée C_Sign prouve qu’une identité autorisée a demandé une signature sur un tampon, pas que le document signé était légitime, relu ou même intelligible. La preuve de contexte doit venir de l’application, de l’identité fédérée et de la journalisation métier. Un HSM ne lit pas les contrats, même avec une brochure particulièrement enthousiaste.

Prérequis de plateforme et politique d’exploitation

Avant l’activation, inventorier le modèle de HSM, la version de firmware, le client PKCS#11, le middleware du fournisseur et les limites documentées de débit d’audit. Certains produits ne journalisent que les opérations d’administration par défaut ; d’autres distinguent l’audit local, le journal de sécurité et la télémétrie. Confondre les trois produit des dossiers d’audit très décoratifs et très insuffisants.

Configurer deux destinations de collecte indépendantes lorsque le produit le permet : une destination primaire supervisée et une destination de secours. La redondance du HSM ne vaut pas redondance de l’audit. Dans une architecture haute disponibilité, vérifier si chaque nœud conserve un compteur propre, si les objets synchronisés gardent le même identifiant d’audit et si un basculement crée une rupture de séquence. Ces points doivent être testés avec l’architecture décrite dans la haute disponibilité HSM.

La supervision doit détecter quatre classes d’écart : absence d’événements attendus, hausse des refus, rupture de séquence et retard d’export. Une absence d’événement est souvent plus grave qu’une erreur visible. Le tableau de bord qui affiche zéro alerte parce que le collecteur est arrêté mérite la même confiance qu’un parachute rangé dans son carton.

Les sauvegardes du HSM ne remplacent pas la sauvegarde des journaux. Conserver séparément les archives d’audit, les paramètres de politique, les certificats de vérification et les procédures de restauration. Tester la restauration sur une plateforme isolée : restaurer les clés sans pouvoir reconstruire la chronologie des opérations ne satisfait pas un audit externe.

Exemple de collecte TLS avec contrôle de séquence

L’exemple suivant configure rsyslog pour recevoir les exports TLS d’un HSM sur le port 6514, écrire les événements dans un fichier dédié et refuser les émetteurs non authentifiés par une autorité de certification locale. Le format exact du message reste dépendant du firmware, mais le transport et la conservation sont reproductibles.

# Certificat du collecteur et autorité ayant signé le certificat du HSM.
global(
  DefaultNetstreamDriverCAFile="/etc/rsyslog.d/ca-hsm.pem"
  DefaultNetstreamDriverCertFile="/etc/rsyslog.d/collecteur-hsm.pem"
  DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/collecteur-hsm.key"
)

module(load="imtcp")

# Accepte uniquement un client TLS dont le certificat est validé.
input(
  type="imtcp"
  port="6514"
  StreamDriver.Name="gtls"
  StreamDriver.Mode="1"
  StreamDriver.AuthMode="x509/certvalid"
)

# Sépare le journal natif du journal système général.
if ($fromhost-ip == "192.0.2.50") then {
  action(type="omfile" file="/var/log/hsm/audit-native.log")
  stop
}

Après redémarrage du service, injecter une opération de test depuis un client autorisé, puis vérifier que l’événement contient un identifiant de séquence et le résultat de l’appel. Le contrôle doit échouer si le certificat client est absent ou invalide. Tester également une coupure du collecteur : vérifier le comportement fail-open ou fail-closed choisi, l’alerte associée et la présence d’une rupture détectable à la reprise.

Ce que la journalisation native ne garantit pas

La journalisation native ne garantit ni l’intégrité de l’application appelante, ni la légitimité de la demande métier, ni l’identité humaine lorsque l’application utilise un compte de service partagé. Elle ne remplace pas la gestion des accès, la revue des droits, le cloisonnement réseau ou l’analyse des journaux dans un SIEM (Security Information and Event Management).

Elle ne garantit pas non plus qu’une clé a été utilisée pour un objectif autorisé. Un mécanisme de signature peut signer n’importe quelle donnée fournie par une identité autorisée. Restreindre les mécanismes autorisés, les attributs d’usage et les chemins d’accès reste indispensable. La distinction entre KEK (Key Encryption Key) et DEK (Data Encryption Key), détaillée dans KEK et DEK, aide à définir quelles clés exigent un niveau d’audit maximal.

🐝 Ce qui arrive si on s’en passe

Sans journalisation native et infalsifiable du HSM, le module protège une clé sans produire la preuve de son usage. On ne peut alors établir ni qui a demandé quelle opération, ni sur quel objet, ni depuis quel contexte, ni avec quel résultat. La conséquence est directe pour un audit externe : une signature abusive ou une utilisation détournée d’une clé reste invisible, et il devient impossible de distinguer une preuve d’un récit reconstruit après coup. Sans démonstration que la trace n’a pas été réécrite entre-temps, même les journaux existants perdent leur valeur probante, car rien ne garantit qu’ils reflètent les faits. L’absence de ce registre signé retire la capacité de reconstruire les événements quand un contrôleur demande qui a manipulé quoi, laissant la protection de la clé sans la responsabilité qui devrait l’accompagner.

🦫 Explication de la marmotte 🍫

Un module matériel de sécurité garde des clés secrètes et réalise des opérations comme chiffrer, déchiffrer ou signer. Pour un audit, il doit aussi produire une trace à chaque action sensible. Cette trace indique l’heure, l’identité utilisée, l’objet concerné, l’action demandée et son résultat. Elle doit enregistrer les refus autant que les réussites, car une tentative interdite peut révéler une attaque ou une erreur de configuration.

La trace est envoyée vers un système de conservation par une connexion chiffrée qui vérifie l’identité de l’émetteur. Le module peut signer ses journaux ou numéroter chaque événement pour permettre de détecter une modification, une suppression ou un événement manquant. Le système de conservation doit empêcher la réécriture des anciens messages et alerter si la réception s’arrête.

Si le lien vers la conservation tombe, une décision doit déjà exister. Le module peut refuser toute opération sensible, ou continuer pendant un temps limité en gardant les traces localement. Le premier choix protège mieux la preuve, le second protège davantage la disponibilité du service. Les comptes doivent être individuels : une trace associée à un compte partagé ne permet pas d’identifier une personne. Enfin, cette journalisation prouve une opération technique, pas que la demande métier était légitime. Cette preuve doit venir aussi de l’application et de ses propres journaux.

Pages voisines

La citent

Journalisation native HSM pour audit externe

Elle cite

Journalisation native HSM pour audit externe

Journalisation native HSM pour audit externe

Journalisation native HSM : le compromis à accepter

Chaîne de preuve et intégrité des journaux HSM

Surface d’attaque de l’audit cryptographique

Prérequis de plateforme et politique d’exploitation

Exemple de collecte TLS avec contrôle de séquence

Ce que la journalisation native ne garantit pas

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines