Architecture de journalisation d’audit immuable centralisée

Un log applicatif décrit ce qu’un processus a choisi de raconter. Un audit trail fiable établit qu’un événement a été reçu, dans un ordre donné, et qu’il n’a pas été réécrit ensuite par l’administrateur qui aurait intérêt à le faire disparaître. La différence paraît sémantique jusqu’au premier incident où le serveur compromis nettoie ses propres traces avec une discipline quasi administrative.

→ Lire l’explication complète de la marmotte

Audit trail immuable : ce qui doit être garanti

Un audit trail est une suite d’événements destinée à établir des faits opposables techniquement : identité observée, action demandée, ressource visée, décision prise, résultat, heure et contexte d’exécution. Il ne sert pas à déboguer une exception Java à 02:17. Pour cela, les logs applicatifs restent très bien, surtout quand ils contiennent trois gigaoctets de traces de pile et une clé d’API par mégarde.

L’immuabilité signifie qu’après acceptation, un événement ne peut ni être modifié ni supprimé par une identité disposant des droits habituels sur la source, l’agent de collecte ou le stockage opérationnel. Ce mot impose un modèle de menace. Un volume ext4 monté en lecture seule n’est pas immuable : root peut le remonter. Une politique de rétention sur un bucket contrôlé par le même compte cloud que la production n’est pas immuable non plus : l’identité compromise peut modifier la politique avant de supprimer les objets.

La garantie attendue repose sur quatre propriétés distinctes :

Intégrité : toute modification d’un événement stocké est détectable.
Complétude relative : les événements attendus arrivent réellement au collecteur, ou une absence est détectée.
Ordre et datation : la séquence et l’heure des événements peuvent être vérifiées.
Séparation des pouvoirs : compromettre une source ne donne pas le pouvoir d’effacer sa trace centralisée.

Aucune de ces propriétés ne crée la vérité absolue. Un attaquant ayant pris le contrôle d’un processus avant l’émission peut forger un événement mensonger ou éviter son émission. Un audit trail prouve ce qui a été capturé par son périmètre, pas l’intention secrète d’un binaire compromis. La télémétrie réseau, les journaux d’identité et les traces d’infrastructure restent nécessaires pour croiser les versions. L’observabilité aide à détecter un comportement ; l’audit doit permettre de l’attribuer et de le conserver.

Le compromis central est net : plus l’acceptation distante est synchrone et indépendante, plus l’audit résiste à la compromission de la source ; plus le système paie en latence, en disponibilité et en exploitation. Pour les actes sensibles, création de privilèges, export de données, changement de politique, accès administrateur, il faut accepter ce coût. Pour les événements volumineux ou à faible valeur probatoire, une livraison asynchrone avec alerte de rupture est raisonnable. Mélanger les deux dans le même flux revient à appeler « critique » tout ce qui produit du JSON.

Pipeline centralisé hors de portée de la source

L’architecture minimale comporte quatre zones d’autorité séparées :

la source produit l’événement au plus près du point de décision ;
un agent de collecte persistant lit une source append-only locale et transmet les enregistrements ;
un collecteur central authentifie la source, attribue un numéro de réception et écrit dans un stockage append-only ;
un coffre d’archivage reçoit une réplication immédiate avec rétention verrouillée, sous une identité et un domaine d’administration distincts.

La séparation doit être réelle. Mettre un collecteur dans le même cluster Kubernetes, avec les mêmes administrateurs et le même fournisseur d’identité, réduit la distance réseau, pas le rayon d’explosion. Une compromission d’administration doit exiger au moins deux franchissements : environnement source puis domaine d’audit. Les comptes de production ne doivent pas administrer la rétention, les clés de signature ni la suppression d’archives.

Sur Linux, journaliser les actions d’administration via auditd et systemd-journald donne une base exploitable, à condition de rendre le stockage local persistant et de remonter les pertes. La page sur Linux et les fondations système complète ce point. L’agent doit conserver une file locale chiffrée, bornée et surveillée. Cette file absorbe une coupure, mais ne constitue pas la preuve : un attaquant local peut encore l’effacer avant transmission.

Pour réduire cette fenêtre, transmettre en flux authentifié et demander un accusé de réception signé ou au minimum corrélé à un identifiant monotone du collecteur. Les événements critiques doivent échouer fermement si le collecteur est indisponible, ou basculer vers une procédure dégradée explicitement auditée. Autoriser silencieusement une élévation de privilège quand l’audit est en panne, c’est choisir une zone aveugle exactement au moment où elle coûte le plus cher.

La centralisation sans expédition immédiate est un faux contrôle classique. Une rotation locale toutes les heures suivie d’un transfert par lot laisse une heure entière à un attaquant pour modifier, tronquer ou supprimer les fichiers. Un système source ne doit jamais avoir le dernier mot sur ce qui part au collecteur.

Intégrité cryptographique et horodatage vérifiable

Le collecteur doit calculer un condensat cryptographique, ou hash, de chaque lot reçu avec SHA-256 (Secure Hash Algorithm 256 bits) ou SHA-512. Chaque lot inclut le condensat du lot précédent. Cette chaîne détecte une modification au milieu de l’historique : modifier un événement invalide les liens suivants.

Une chaîne seule ne détecte pas la troncature en fin de journal. Supprimer les derniers lots laisse une chaîne valide. Il faut donc publier périodiquement un point de contrôle hors du domaine du collecteur : condensat racine, numéro de séquence final et heure. Un arbre de Merkle permet de produire une racine unique couvrant un ensemble de lots, puis de prouver l’inclusion d’un lot sans exporter toute l’archive.

L’horodatage doit provenir d’une autorité d’horodatage, ou TSA (Time Stamping Authority), indépendante du collecteur. La TSA signe le condensat et l’heure observée. Elle ne prouve pas qu’un événement est vrai ; elle prouve qu’un certain état du journal existait au plus tard à cette date. C’est précisément ce qui rend une falsification a posteriori détectable.

Protéger les clés de signature dans un HSM (Hardware Security Module) ou, à défaut, dans un service de gestion de clés isolé. La clé utilisée pour signer les checkpoints ne doit jamais être exportable par le collecteur. Prévoir une KEK (Key Encryption Key) pour protéger les clés de chiffrement de données, et séparer cette KEK des droits de suppression d’archives. Le chiffrement des journaux protège leur confidentialité ; il ne les rend ni complets ni immuables. Ces propriétés ont la fâcheuse habitude de ne pas apparaître par magie au fond d’un seau chiffré.

La synchronisation temporelle via NTP (Network Time Protocol) avec plusieurs serveurs authentifiés reste nécessaire pour la corrélation. Elle ne remplace pas l’horodatage externe : une source compromise peut mentir sur son horloge. Enregistrer l’heure source et l’heure de réception permet de détecter les dérives, les rejouements et les périodes de déconnexion.

Exemple de collecte Linux avec transport chiffré

L’exemple suivant configure rsyslog pour lire le journal systemd et l’expédier vers un collecteur utilisant RELP (Reliable Event Logging Protocol) sur TLS (Transport Layer Security). Il ne remplace pas le stockage immuable côté collecteur : il réduit la perte entre source et réception.

# Lire le journal systemd persistant, incluant les événements auditd transmis au journal.
module(load="imjournal" PersistStateInterval="100")

# Transport RELP chiffré avec authentification mutuelle par certificat.
global(
  DefaultNetstreamDriver="gtls"
  DefaultNetstreamDriverCAFile="/etc/rsyslog.d/ca-audit.pem"
)

# La file disque survit à un redémarrage local. Elle doit être surveillée :
# une file pleine signifie que la preuve n'atteint plus le collecteur.
action(
  type="omrelp"
  target="audit-collector.internal"
  port="6514"
  tls="on"
  tls.mycert="/etc/rsyslog.d/source-audit.pem"
  tls.myprivkey="/etc/rsyslog.d/source-audit.key"
  tls.permittedpeer="audit-collector.internal"
  queue.type="LinkedList"
  queue.filename="audit-relp"
  queue.maxdiskspace="2g"
  queue.saveonshutdown="on"
  action.resumeRetryCount="-1"
)

Activer ensuite Storage=persistent dans journald et vérifier que l’agent ne peut pas accepter un certificat émis par une autorité de certification de production générale. Une autorité dédiée à l’audit limite l’impact d’une émission abusive de certificat. Le collecteur doit rejeter les sources inconnues, enregistrer les échecs d’authentification dans un autre domaine et alerter sur toute interruption de séquence.

Rétention verrouillée, supervision et reprise

Un stockage WORM (Write Once Read Many) applique une rétention pendant laquelle les objets ne peuvent pas être supprimés ou modifiés. Cette propriété n’a de valeur que si la rétention est verrouillée de façon irréversible pour la période définie, et si le rôle qui écrit ne peut pas modifier cette configuration. Une rétention gouvernable par un administrateur global est une option de confort, pas une barrière contre cet administrateur.

La réplication doit être immédiate, ou au moins déclenchée à l’acceptation du lot, vers un compte, un tenant ou un site distinct. Tester la réplication avec une suppression volontaire dans l’environnement source. Tester seulement la restauration d’un objet déjà présent ne démontre pas que le mécanisme résiste à une identité compromise.

Superviser quatre écarts : absence d’événements d’une source attendue, trou de séquence, dérive entre heure source et réception, échec de réplication ou de vérification de signature. Une volumétrie stable ne prouve rien : un agent compromis peut expédier une absence parfaitement régulière. Les alertes doivent être envoyées à une équipe distincte de l’exploitation source, avec accès lecture aux archives mais sans droit de purge.

La reprise impose de sauvegarder les configurations de collecteurs, les autorités de certification, les politiques de rétention, les métadonnées d’index et les clés publiques de vérification. Ne jamais restaurer une clé privée de signature depuis une sauvegarde non contrôlée sans procédure de révocation et de rotation : une clé ressuscitée permet de fabriquer des checkpoints historiques. Les pratiques de séparation d’identité rejoignent celles décrites dans les architectures IAM, même si le mot de passe magique du trimestre promet de tout simplifier.

🐝 Ce qui arrive si on s’en passe

Sans journal d’audit immuable et centralisé, la réponse à incident perd sa borne temporelle : faute de pouvoir dater le premier accès illégitime, il devient impossible de désigner une sauvegarde saine. Il faut alors traiter chaque restauration comme suspecte, reconstruire plus large et faire tourner l’ensemble des secrets et des comptes au lieu de ceux réellement exposés. L’attribution devient réfutable : un administrateur légitime ne peut pas démontrer qu’une action ne vient pas de lui, et un attaquant disposant de droits d’écriture peut insérer des événements forgés qui désignent une autre identité, sans qu’aucune empreinte ni horodatage externe ne permette de trancher. La durée de présence d’un intrus reste inconnue, ce qui empêche de délimiter les données effectivement consultées ou exportées.

🦫 Explication de la marmotte 🍫

Un système doit enregistrer les actions qui comptent : connexion d’un administrateur, ajout d’un droit, modification d’une règle, export de données ou changement de configuration. L’événement est créé au moment de l’action, avec l’identité observée, l’action, son résultat et l’heure indiquée par la machine.

Cet événement est envoyé sans attendre vers un système séparé. Le système qui a produit l’événement ne doit pas pouvoir supprimer la copie centrale. S’il perd la connexion, il garde temporairement les événements dans une file locale et signale que cette file grandit. Pour certaines actions très sensibles, l’action doit être refusée si la copie centrale ne peut pas confirmer sa réception.

Le système central range les événements dans un stockage où l’écriture est autorisée mais où la modification et la suppression sont bloquées pendant une durée fixée. Il envoie aussi une copie vers un autre emplacement administré séparément.

Pour détecter une modification, le système calcule une empreinte mathématique des événements et la relie à l’empreinte précédente. Une modification casse cette relation. Il fait régulièrement dater cette empreinte par un service extérieur, ce qui montre que l’état du journal existait déjà à ce moment-là.

Si une machine attaquée efface ses fichiers avant l’envoi, des événements peuvent manquer. Le système doit alors détecter l’absence attendue, les numéros manquants ou l’arrêt de transmission. Le journal ne garantit donc pas que tout mensonge est impossible : il garantit que les traces reçues ne peuvent pas être discrètement réécrites ensuite.

Pages voisines

La citent

Architecture de journalisation d’audit immuable centralisée

Elle cite

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

Architecture de journalisation d’audit immuable centralisée

Architecture de journalisation d’audit immuable centralisée

Audit trail immuable : ce qui doit être garanti

Pipeline centralisé hors de portée de la source

Intégrité cryptographique et horodatage vérifiable

Exemple de collecte Linux avec transport chiffré

Rétention verrouillée, supervision et reprise

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines