Pistes d’audit cryptographiques : comment elles fonctionnent et pourquoi les régulateurs les exigent désormais

Le problème des journaux d’audit classiques

Tous les systèmes d’entreprise génèrent des journaux d’audit. Journaux d’accès des utilisateurs, enregistrements de gestion des changements, historiques d’appels d’API, traces des actions d’administration : les données sont là. Les régulateurs les exigent. Les auditeurs les examinent. Les équipes de réponse aux incidents s’appuient sur elles.

Il existe un problème dont presque personne ne parle : les journaux d’audit classiques sont modifiables.

Un administrateur de base de données disposant des bons privilèges peut modifier une entrée de journal. Un processus de rotation des journaux mal configuré peut supprimer des enregistrements. Un attaquant chevronné ayant compromis un compte d’administrateur peut effacer de manière sélective les traces de ses actions avant que quiconque ne les examine.

Lorsque l’article 21, paragraphe 2, point g), de NIS2 exige la « sécurité des fichiers journaux », lorsque l’article 9, paragraphe 4, point d), de DORA exige l’intégrité des journaux opérationnels TIC et lorsque l’article 12 de l’AI Act de l’UE exige des enregistrements du fonctionnement des systèmes d’IA, les régulateurs ne demandent pas des journaux classiques modifiables. Ils demandent des journaux qui ne peuvent pas être falsifiés après coup.

Les pistes d’audit cryptographiques sont la réponse technique à cette exigence.

Comment fonctionnent les pistes d’audit cryptographiques

Une piste d’audit cryptographique complète le journal classique par deux propriétés techniques :

Chaînage des empreintes. Chaque entrée de journal contient l’empreinte cryptographique (hash) de l’entrée précédente. On obtient ainsi une chaîne dans laquelle toute modification d’une entrée passée invalide toutes les entrées suivantes, ce qui rend toute modification rétroactive immédiatement détectable. C’est le même mécanisme que celui de la blockchain, appliqué spécifiquement à l’intégrité des journaux d’audit.

Ancrage externe. À intervalles réguliers (chaque minute, chaque heure, chaque lot d’événements), l’empreinte courante de la chaîne est ancrée dans un registre indépendant et immuable. On crée ainsi un point de référence externe horodaté qui ne peut pas être modifié, même si le système de journalisation principal est compromis.

Ensemble, ces deux propriétés signifient que :

• Toute modification de n’importe quelle entrée historique du journal rompt la chaîne et est immédiatement détectable
• Même si un attaquant détruit le journal principal, les ancres externes conservent une trace vérifiable de ce que contenait le journal à chaque point d’ancrage
• Les régulateurs et les auditeurs peuvent vérifier de manière indépendante qu’un journal n’a pas été modifié, sans dépendre de la déclaration de l’organisation elle-même

Voilà à quoi ressemblent, en pratique, les audits facilités avec ROOTKey : remplacer « nous avons des journaux » par « nous pouvons prouver que nos journaux sont exacts ».

import { createHash } from 'crypto';

interface AuditEntry {
  timestamp: string;
  eventType: string;
  actorId: string;
  resourceId: string;
  action: string;
  previousHash: string; // Hash of the previous entry in the chain
  entryHash: string;    // Hash of this entry including previousHash
}

function createAuditEntry(
  event: Omit<AuditEntry, 'previousHash' | 'entryHash'>,
  previousHash: string
): AuditEntry {
  const entry: Omit<AuditEntry, 'entryHash'> = {
    ...event,
    previousHash,
  };

  const entryHash = createHash('sha256')
    .update(JSON.stringify(entry))
    .digest('hex');

  return { ...entry, entryHash };
}

function verifyAuditChain(entries: AuditEntry[]): boolean {
  for (let i = 1; i < entries.length; i++) {
    const expected = entries[i].previousHash;
    const actual = entries[i - 1].entryHash;

    if (expected !== actual) {
      console.error(`Chain break detected at entry ${i}: log has been tampered with`);
      return false;
    }

    // Verify the entry's own hash
    const { entryHash, ...entryWithoutHash } = entries[i];
    const computed = createHash('sha256')
      .update(JSON.stringify(entryWithoutHash))
      .digest('hex');

    if (computed !== entryHash) {
      console.error(`Entry ${i} hash invalid: entry content has been modified`);
      return false;
    }
  }

  return true;
}

Ce que cela signifie pour votre programme de conformité

La mise en place de pistes d’audit cryptographiques apporte trois bénéfices directs en matière de conformité :

Elle respecte la lettre de la loi. NIS2, DORA et l’AI Act de l’UE exigent tous l’intégrité des journaux. Une piste d’audit cryptographique est la mise en œuvre techniquement défendable de cette exigence, contrairement à un journal classique qu’un DBA pourrait modifier.

Elle réduit le temps de préparation des audits. Lorsqu’un auditeur ou un régulateur demande la preuve que les journaux n’ont pas été falsifiés, une piste d’audit cryptographique fournit cette preuve automatiquement. Les journaux classiques imposent d’attester des contrôles de sécurité, un processus qui prend du temps et comporte un risque de mise en cause de la responsabilité.

Elle renforce les investigations sur les incidents. En cas d’incident de sécurité, une piste d’audit cryptographique fournit des preuves forensiques qui ne peuvent pas être contestées au motif qu’elles auraient été modifiées après coup. C’est crucial pour les déclarations de sinistre auprès des assureurs, les notifications réglementaires et les éventuels contentieux.

Le cas d’usage audit de ROOTKey fournit des pistes d’audit cryptographiques sous forme de service managé, intégré à vos systèmes existants. Commencez un essai gratuit et générez dès aujourd’hui votre première piste d’audit cryptographique.