Intégrité des journaux et preuve de falsification : comment construire des journaux signés en append-only avec archivage vérifiable hors site

Qui considère les logs uniquement comme un outil de «recherche d’erreurs» sous-estime leur valeur en cas d’incident. Dès qu’un incident, un cas d’insider ou un audit survient, un log devient un élément de la chaîne de preuve. C’est précisément là que intervient l’intégrité des logs : la capacité de démontrer que les données de logs sont complètes et n’ont pas été modifiées a posteriori sans être détectées. Dans la pratique, il s’agit moins d’une immuabilité parfaite (rare dans les systèmes complexes) que de la détection des manipulations : toute modification laisse des traces vérifiables en dehors du système compromis.

Cet article montre comment construire des logs signés, en mode append-only, et un archivage vérifiable hors-site de manière opérationnelle : avec des prérequis clairs, des écueils typiques, des étapes de vérification, un pattern d’architecture exploitable et une stratégie de repli. L’objectif n’est pas un outil unique, mais un mécanisme robuste que vous pouvez implémenter avec des composants existants (Syslog/journald, forwarder de logs, stockage objet, dépôt de sauvegarde, SIEM).

Ce que «l’intégrité des logs» signifie réellement en exploitation

Dans le quotidien, l’intégrité est souvent confondue avec «lecture seule». Pour les logs, c’est insuffisant. Un attaquant n’a pas forcément besoin d’éditer des fichiers ; il suffit souvent d’arrêter des sources de logs, de filtrer sélectivement ou de falsifier des horodatages. L’intégrité des logs est donc un ensemble de trois objectifs :

• Inaltérabilité détectable : les entrées individuelles ne doivent pas pouvoir être modifiées sans laisser de traces détectables (détection des manipulations).
• Complétude : les trous doivent être repérables (par ex. via des séquences ou des chaînes de hachage).
• Preuve vérifiable : la preuve doit pouvoir être réalisée en dehors de l’environnement compromis (vérification hors-site).

Important : « append-only » (ajout uniquement) est un modèle d’écriture, pas une preuve de sécurité. Si un hôte est compromis, un attaquant peut souvent contourner le «append-only» en agissant ailleurs (reconfigurer le forwarder, vider une file, détourner des identifiants de stockage). Vous avez donc besoin en plus d’un chaînage cryptographique et d’un ancrage hors-site.

Modèle de menace : contre quoi protègent les logs signés, append-only — et contre quoi pas ?

Un design solide commence par le modèle de menace. La détection des manipulations cible typiquement les classes suivantes :

• Dissimulation post-compromission : après une intrusion, des traces sont supprimées ou modifiées pour masquer une persistance ou une exfiltration de données.
• Manipulation interne : un administrateur ou un prestataire disposant de droits modifie les pistes d’audit.
• Pression réglementaire : vous devez démontrer de manière traçable que les logs n’ont pas été «retouchés».

Contre quoi cela ne protège pas automatiquement :

• Contenu frauduleux : si une application génère elle‑même des lignes de log incorrectes, votre système les signera aussi. L’intégrité n’est pas une vérification de vérité fonctionnelle.
• Absence d’enregistrement : si la source ne journalise pas ou que le logging est désactivé, aucune signature ne pourra compenser cela. Vous pouvez seulement rendre les lacunes visibles.
• Perte totale des clés : si les clefs de signature et les ancres de vérification sont compromis, la preuve perdra sa valeur. L’architecture des clés est donc un élément central.

Pattern d’architecture : append-only + chaîne de hachage + signature + ancre hors-site

En pratique, un schéma multi‑étapes s’est avéré efficace et fonctionne indépendamment de produits spécifiques :

1. Collecte : les logs sont générés par des sources (Linux journald/syslog, Windows Event Logs, appliances, APIs d’audit SaaS).
2. Transport avec tampon : un Forwarder (agent ou relais) transporte de manière fiable, idéalement avec file d’attente/backpressure (pour éviter la perte de données en cas de problèmes réseau).
3. Stockage en append-only : un chemin similaire au write‑once, p. ex. stockage d’objets avec Object Lock (WORM) ou un stockage doté d’une fonctionnalité d’immuabilité.
4. Preuve d’intégrité : chaîne de hachage (chaque ligne/lot contient le hachage du précédent) plus signatures numériques (asymétriques, p. ex. Ed25519/ECDSA/RSA) par fenêtre temporelle/bucket.
5. Ancre hors site : un emplacement externe et sécurisé séparément où vous déposez périodiquement une « empreinte » (Root-Hash/Manifest-Signatur), afin d’empêcher qu’une plateforme de logging compromise ne soit réécrite rétroactivement à l’insu de tous.

Brève mise en contexte des termes : une chaîne de hachage relie cryptographiquement des blocs de données ; toute modification d’un bloc rompt la chaîne. Une signature numérique utilise une clé privée pour signer et une clé publique pour vérifier ; ainsi, tout vérificateur peut attester de l’authenticité sans disposer de droits d’écriture. Une ancre hors site est un point de vérification indépendant (autre compte, autre fournisseur, support hors ligne, tenant de sécurité séparé).

Pourquoi « append-only » seul ne suffit pas (et où cela reste utile)

L’append-only reste utile car il augmente l’effort requis pour la manipulation et réduit les modifications accidentelles. Implémentations typiques :

• Flags append-only du système de fichiers (p. ex. sous Linux) – utile contre les suppressions accidentelles, mais non fiable en cas de compromission du root.
• Stockage d’objets avec immuabilité (WORM/Object Lock) – nettement plus robuste, car même les administrateurs du même compte ne peuvent généralement pas supprimer tant que la rétention est active.
• Supports write-once (p. ex. bande, exports hors ligne) – très robustes comme dernier filet de sécurité, mais plus lents pour la recherche/indexation.

La faiblesse principale : si un attaquant obtient l’accès suffisamment tôt, il peut tenter, avant que la rétention ne prenne effet, d’empêcher l’enregistrement des données (arrêter le Forwarding) ou de rediriger les chemins d’écriture. Vous devez donc prévoir la complétude (trous) et la vérification hors site.

Logs signés en pratique : que signe-t-on exactement

Beaucoup d’équipes ne butent pas sur la cryptographie mais sur la question : « Signons‑nous chaque ligne ? » Ce n’est rarement nécessaire et coûte souvent cher en exploitation (CPU, overhead, opérations sur les clés). Une approche par batch s’est avérée efficace :

• Les logs sont découpés en fenêtres temporelles courtes (p. ex. 1 minute ou 5 minutes) ou en fenêtres de taille (p. ex. 50–200 Mo).
• Pour chaque fenêtre, un manifest est généré (liste des hashes des fichiers/chunks, plus des métadonnées telles que période, source, numéros de séquence).
• Ce manifest est signé numériquement.
• De plus, un Root-Hash (p. ex. Merkle-Root ou hash du manifest) est ancré offsite.

Cela permet : la manipulation d’un fichier individuel est détectable (le hash ne correspond pas), et la manipulation de l’ensemble de l’historique est également détectable (l’Offsite-Anchor ne correspond plus). En parallèle, la pipeline de logs reste performante.

Piège : la synchronisation temporelle comme brèche d’intégrité cachée

L’intégrité dépend fortement du temps. Si les systèmes ont des horloges différentes, des lacunes apparentes ou des ordres incorrects apparaissent. Pour les administrateurs, c’est souvent la première erreur lors des audits. Le minimum est une configuration cohérente de NTP/Chrony/PTP (services de temps), ainsi qu’un monitoring de la dérive. Pour des preuves hautement critiques, certaines équipes utilisent en outre un service d’horodatage (Trusted Timestamping) : il confirme cryptographiquement qu’un hash existait à un instant donné. Ceci est particulièrement utile si vous déposez un Offsite-Anchor dans un système externe et devez prouver ultérieurement qu’il n’a pas été « créé a posteriori ».

Archivage vérifiable offsite : séparez le chemin d’écriture, le chemin de lecture et l’auditeur

« Offsite » ne signifie pas seulement « autre centre de données ». Dans le sens de la détection de manipulation, il s’agit d’une indépendance administrative :

• Compte/Tenant séparé : la journalisation écrit dans un storage dont la rétention est gérée par un compte Security ou Compliance distinct.
• Clés séparées : les clés de signature ne résident pas sur les serveurs de logs ; les clés de vérification sont largement distribuées (Read-only).
• Rôle d’auditeur en lecture seule : la vérification doit pouvoir se faire sans droits de modification, idéalement depuis un système isolé (Jump Host/Forensik-VM).

L’objectif est un modèle de pouvoir asymétrique : la production peut fournir, mais pas modifier rétroactivement. Les auditeurs peuvent vérifier, mais pas manipuler.

Schéma d’implémentation concret (indépendant des outils) avec structure de fichiers et manifest

Un schéma pratique, applicable à de nombreux environnements, repose sur une structure claire et prédictible. Exemple d’un arbre journalier par source :

/archive/logs/<source>/YYYY/MM/DD/HH/part-000123.log.gz
/archive/logs/<source>/YYYY/MM/DD/HH/manifest-YYYYMMDDHH.json
/archive/logs/<source>/YYYY/MM/DD/HH/manifest-YYYYMMDDHH.sig
/archive/anchors/YYYY/MM/DD/anchor-YYYYMMDDHH.txt

Le manifest (JSON) contient les hashes des parties de logs et l’information de chaînage. Exemple de structure :

{
  "source": "vpn-gateway-01",
  "window": {
    "start": "2026-08-09T10:00:00Z",
    "end":   "2026-08-09T11:00:00Z"
  },
  "sequence": {
    "first": 12001,
    "last":  12067
  },
  "prev_manifest_hash": "b5f6...",
  "chunks": [
    {"file": "part-00012001.log.gz", "sha256": "0c1a..."},
    {"file": "part-00012002.log.gz", "sha256": "9f3e..."}
  ],
  "manifest_sha256": "(optional self-hash)"
}

Pourquoi cela fonctionne : la séquence rend les lacunes visibles, le prev_manifest_hash constitue une chaîne sur les fenêtres temporelles, et les hashes des chunks protègent les fichiers. Même si quelqu’un remplace des fichiers isolés, le manifest ne correspond plus ; s’il remplace le manifest et les fichiers conjointement, il devra falsifier la chaîne des Offsite-Anchor.

Gestion des clés : la raison la plus fréquente pour laquelle les signatures sont inutiles en audit

Les logs signés dépendent du modèle de clés. Une séparation claire est essentielle :

• Clé de signature (clé privée) : Seul le service de signature doit l’utiliser. Elle ne devrait pas se trouver sur le même système que la collecte des logs. Idéal : HSM (Hardware Security Module) ou Cloud-KMS avec API de signature ; en alternative, un hôte de signature isolé avec un accès strict.
• Clé de vérification (clé publique) : Peut être largement distribuée (auditeurs, forensique, validateur SIEM), puisqu’elle ne fait que vérifier.
• Rotation : Planifiez la rotation des clés (p. ex. annuelle ou semestrielle) et conservez les anciennes clés publiques pour la vérification des données historiques.

Piège : si la même équipe d’administration peut à tout moment exporter la clé privée et resigner, la preuve est vulnérable. Vérifiez donc au niveau organisationnel : qui a accès à la clé privée, qui gère la rétention, et qui exploite l’instance de vérification ?

How-to: Vérification d’intégrité (Runbook) avec OpenSSL et listes de hachage

Vous avez besoin d’au moins deux preuves vérifiables : (1) la vérification de la signature du manifeste et (2) la vérification des hachages des chunks. Le déroulé suivant est générique et fonctionne pour de nombreux formats de signature (exemple : le hash du manifeste a été signé avec une clé privée, vérification avec la clé publique).

1) Vérifier la signature

# Dateien
MANIFEST="manifest-2026080910.json"
SIG="manifest-2026080910.sig"
PUBKEY="log-signing-public.pem"

# Prüfen (Beispiel RSA/ECDSA über SHA256)
openssl dgst -sha256 -verify "$PUBKEY" -signature "$SIG" "$MANIFEST"

Résultat attendu : „Verified OK“. Sinon, soit le manifeste a été modifié, soit la mauvaise version de la clé publique est utilisée, soit l’algorithme de signature ne correspond pas à la clé. Documentez précisément ces erreurs en exploitation (ID de clé, algorithme, périodes de validité).

2) Vérifier les hachages des Chunks

Extrayez la liste des hachages depuis le manifeste (p. ex. avec jq) et vérifiez les fichiers. Exemple :

# Hashliste aus Manifest erzeugen: <sha256>  <filename>
jq -r '.chunks[] | "(.sha256)  (.file)"' "$MANIFEST" > checksums.sha256

# Prüfen
sha256sum -c checksums.sha256

Si des fichiers sont manquants ou si les hachages ne correspondent pas, l’intégrité est compromise ou la structure de l’archive n’est plus correcte. Vous devez alors vérifier en outre s’il s’agit d’un problème de transport/rétention (p. ex. perte dans la file) ou d’une manipulation (p. ex. suppression sélective).

Dépannage : causes typiques des lacunes et des erreurs d’intégrité

1) Queue/Backpressure pas correctement résolus

Beaucoup de flèches de logs semblent correctes dans le diagramme, mais échouent en cas de charge de pointe : le Forwarder rejette des événements ou bloque des applications. Veillez à de véritables persistenz-Queues (disk-backed) et à des seuils clairs. Signaux d’alerte : « dropped messages », « queue full », « retry storm ».

Étapes de vérification :

• Métriques du Forwarder : Drop-Count, Retry-Count, taux de remplissage de la Queue.
• Latence du stockage : si l’Object-Storage/Index est lent, le Forwarder doit pouvoir mettre en mémoire tampon.
• Capacité : volume de logs par jour, croissance, rétention.

2) Rotation/Compression en conflit avec les fenêtres de signature

Si vous signez d’abord des fichiers puis les modifiez plus tard par rotation/compression (p. ex. gzip après coup), la vérification de la signature sera logiquement rompue. Règle : Signez le format final, pas des états intermédiaires. Soit : normaliser/comprimer d’abord, puis hasher et signer. Soit : signez le flux brut, mais archivez précisément ce flux brut sans le modifier.

3) Dérive temporelle et mélange DST/Timezone

Si une partie du parc utilise l’heure locale (CET/CEST) et d’autres l’UTC, apparaissent des « heures manquantes » ou des fenêtres dupliquées. Opérationnellement, l’UTC est le plus robuste pour les chemins d’archivage. Retirez la conversion de fuseau horaire de la pipeline de logs : stockez en UTC, affichez/corrélez dans les outils selon les besoins.

4) Autorisations : le Logging peut supprimer, alors qu’il ne devrait pas

Une erreur de conception fréquente est que le Log-Writer dispose aussi des droits de suppression, parce que c’est « plus simple ». Pour la preuve d’altération (tamper-evidence), c’est toxique. Mieux : Write-only (Put), éventuellement List pour le diagnostic, mais pas de Delete. La Retention est gérée par une voie admin séparée.

Checkliste: Mindestanforderungen für manipulationssichere Log-Archivierung

• QuellenaBDEckung: Welche Systeme liefern Audit-Logs (AD, VPN, Firewall, IAM, Cloud Control Plane, Datenbanken, Business-Software, Admin-Portale)?
• Zeitkonsistenz: NTP/Chrony aktiv, Drift-Monitoring, UTC im Archiv.
• Transport: TLS-gesichert, persistente Queue, definierte Retry-Strategie.
• Append-only Storage: Object Lock/WORM oder äquivalente Immutability, Retention dokumentiert.
• Integritätslayer: Hash-Kette + signiertes Manifest pro Zeitfenster/Bucket.
• Offsite-Anchor: Root-Hash/Manifest-Signatur in separatem Tenant/Account oder Offline.
• Schlüsselmodell: Private Key isoliert, Rotation geplant, alte Public Keys aufbewahren.
• Verifikation: Wiederholbare Prüfschritte (Runbook), automatisierte Stichproben.
• Alarmierung: Lücken, Signaturfehler, Queue-Überlauf, Retention-Änderungen.

Umsetzung in Etappen: So kommen Sie ohne Big-Bang ans Ziel

In bestehenden Umgebungen ist ein Big-Bang selten sinnvoll. Ein stufenweises Vorgehen reduziert Risiko und hilft bei Akzeptanz:

Etappe 1: Offsite-Archiv + Immutability

Faites sortir les logs de manière fiable du domaine de production, y compris la rétention. C’est la base pour éviter « serveur disparu, logs perdus » et pour se prémunir contre les ransomwares qui chiffrent les serveurs de logs locaux. Utilisez d’abord la pipeline de logs existante, mais durcissez le stockage et les autorisations.

Étape 2 : Manifest + Hashes

Générez pour chaque fenêtre temporelle un manifest avec des hashes. Ce n’est pas encore une signature, mais cela permet des vérifications de cohérence et vous oblige à définir des limites de fichiers et des fenêtres.

Étape 3 : Signatures et ancrage hors site

Ajoutez des signatures et ancrez les hashes hors site. À partir de là, c’est auditsafe si la gestion des clés et les rôles sont correctement séparés.

Étape 4 : Vérification automatisée et intégration aux incidents

Automatisez des contrôles aléatoires (p. ex. quotidiennement 10 fenêtres choisies au hasard) et intégrez les erreurs de vérification comme une classe d’incident (Runbook, Ownership, SLAs). La preuve d’altération n’est utile que si les indicateurs de manipulation sont traités au niveau opérationnel.

Stratégie de repli : que faire si la vérification de la signature échoue ?

Une erreur de vérification n’est pas automatiquement un « attaque ». Il s’agit souvent d’erreurs opérationnelles. Néanmoins, procédez comme pour un incident de sécurité, mais avec une escalade pragmatique :

1. Déterminer la portée : S’agit-il d’une fenêtre, d’une source ou de toutes ? Corrélez avec les déploiements/modifications (Forwarder-Update, Storage-Policy).
2. Isoler la cause : Il manque un fichier (transport) ? Un hash ne correspond pas (modification/bitrot/erreur de processus) ? Seule la signature est invalide (clé/algorithme/format) ?
3. Vérifier l’ancrage hors site : Les hashes ancrés externement correspondent-ils ? Si oui, le système hors site est probablement intact ; si non, montez davantage l’escalade.
4. Vérifier l’état des sources : Les sources ont-elles continué à logger ? Y a-t-il des métriques de perte, des débordements de queue, disque plein ?
5. Sauvegarde forensique : Sauvegardez les artefacts concernés (manifest, signature, chunks affectés, métadonnées) en lecture seule, avant de « réparer ».
6. RESTauration : Si c’était une erreur opérationnelle, reconstituez autant que possible à partir des sources originales ou des chemins de logs secondaires (p. ex. SIEM-ingest, relais Syslog).

Important : évitez de « resigner pour que tout redevienne vert ». C’est exactement le schéma qui rend les audits méfiants. Si une correction est nécessaire, elle doit RESTer visible comme une correction (nouvelle fenêtre, nouvelle signature, motif documenté).

Bonnes pratiques pour l’exploitation de WordPress et des portails d’administration : où la preuve d’altération est particulièrement utile

Dans les environnements proches de WordPress (portails admin, systèmes de rédaction, APIs pour connexion/SSO, plugins, reverse-proxies), la situation des logs est souvent hétérogène. Sources typiques que vous devriez placer au centre du contrôle d’intégrité :

• Webserver/Proxy : accès, erreurs, décisions WAF (important pour le brute-force, les tentatives d’exploitation, les chemins inhabituels).
• Auth/SSO : logs IdP (connexion, MFA, émission de tokens), notamment pour les utilisateurs privilégiés.
• WordPress-Audit-Events : actions admin (installation de plugins, modifications de thèmes, rôles utilisateurs, clés API), si disponibles.
• Base de données : connexions admin, requêtes privilégiées (selon la configuration DB et les politiques).
• Système : sudo/SSH, installations de paquets, redémarrages de services, Cron/timers systemd.

Conseil pratique : adoptez dans ces domaines deux perspectives : (1) journaux d’applications / web et (2) journaux d’infrastructure / d’identité. Un attaquant peut plus facilement influencer une perspective que les deux. La preuve d’altération vous aide alors à montrer quelle perspective est restée cohérente.

Vérification hors site : comment tester régulièrement si votre preuve est réellement indépendante

La vérification hors site n’est crédible que si vous la testez. Un exercice simple et reproductible (mensuel ou trimestriel) se déroule ainsi :

1. Choisissez une période (p. ex. une heure) et une source critique.
2. Téléchargez les fichiers d’archive en lecture seule depuis le stockage hors site.
3. Vérifiez la signature du manifeste et les hashs des chunks comme indiqué ci‑dessus.
4. Contrôlez l’ancre hors site (p. ex. Root-Hash) par rapport à votre dépôt indépendant.
5. Documentez le résultat, l’ID de clé, les outils utilisés et les hashs dans une attestation de vérification.

Si cela paraît trop manuel : automatisez les étapes, mais conservez au moins un drill manuel pendant lequel un opérateur sans connaissances spécialisées exécute strictement le runbook. Cela s’avère inestimable en cas d’incident.

Conclusion : la preuve d’altération est un processus opérationnel, pas une fonctionnalité

Les journaux signés en append-only avec archivage vérifiable hors site ne sont pas un luxe, mais une réponse robuste à une question opérationnelle réelle : « Pouvons‑nous encore faire confiance à nos propres journaux si quelque chose tourne mal ? » La clé est une conception multicouche : stockage append-only, chaînes de hachage et manifestes signés pour la détection de manipulations, plus une ancre hors site indépendante du domaine de production. Si vous combinez cela avec la stabilité des files d’attente, la cohérence temporelle, une gestion propre des clés et une stratégie de repli, vous obtenez non seulement une meilleure auditabilité, mais aussi plus de sécurité dans la réponse aux incidents et l’analyse forensique.

Au quotidien, cela porte ses fruits surtout si vous opérationnalisez la vérification d’intégrité : contrôles ponctuels, alertes en cas de lacunes, responsabilités clairement définies et un runbook qui fonctionne aussi à 03:00. Alors l’intégrité des journaux n’est pas seulement une promesse, mais un état vérifiable.