Qu'est-ce qu'un Audit-Trail ?
Un Audit-Trail est l'enregistrement complet, chronologique et protégé contre toute manipulation des actions pertinentes pour la sécurité dans un système. Chaque entrée répond au moins à : qui a exécuté quelle action, quand, sur quelle cible, depuis où, avec quel résultat et, pour les modifications critiques, avec quelle validation. À la différence des logs techniques, qui servent avant tout à l'exploitation et tournent souvent après peu de temps, l'Audit-Trail est conçu pour sa valeur probante : complet, conservé durablement et non modifiable a posteriori. Il constitue ainsi la base de toute démonstration de conformité, de l'audit interne aux contrôles au titre de NIS2 ou de DORA.
L'Audit-Trail en détail
Une entrée solide contient l'acteur, l'action, la cible, l'horodatage, la source (par exemple l'adresse IP ou la session), le résultat et un contexte comme le lien vers un ticket ou une validation. Ce qui est déterminant, c'est que ces entrées naissent automatiquement, côté système : une liste de modifications tenue manuellement n'est pas un Audit-Trail, car elle est lacunaire et modifiable après coup. La protection contre la manipulation est tout aussi importante, par exemple en garantissant que même les administrateurs ne peuvent ni modifier ni supprimer les entrées.
Le terme du secteur revisionssicher (« à l'épreuve d'audit ») résume ces propriétés. Pour les entrées à caractère personnel, le RGPD s'applique également : la limitation des finalités, la restriction d'accès au Trail lui-même et des durées de conservation définies font partie du concept, car le stockage des preuves est lui-même un objet de données à protéger.
Pourquoi l'Audit-Trail compte-t-il dans l'exploitation Zscaler ?
Dans l'exploitation Zscaler, plusieurs personnes, souvent aussi des prestataires, modifient des policies ayant un impact sur toute l'entreprise. Sans Audit-Trail, il est presque impossible, après un incident, de reconstituer quelle modification est venue de qui et quand, et si elle avait été validée ; la recherche d'erreur se transforme en interrogatoire. Avec un Trail propre, la question trouve sa réponse en quelques minutes, et même les modifications légitimes peuvent à tout moment être expliquées aux personnes concernées et aux auditeurs.
NIS2 et DORA en font une obligation de preuve : toutes deux exigent des processus maîtrisés pour les modifications pertinentes pour la sécurité et leur justification ; les détails relèvent de la transposition nationale et de la pratique des autorités de contrôle. La voie coûteuse consiste à reconstituer les preuves avant chaque audit à partir des vues, des e-mails et des souvenirs. La voie économique est un Audit-Trail qui enregistre automatiquement au fil de l'activité quotidienne et produit des preuves comme sous-produit.
Sources d'erreur courantes
- Confondre logs et Audit-Trail : les logs d'exploitation tournent, sont incomplets et non protégés contre la manipulation ; ils ne remplacent aucune preuve.
- Des lacunes par des voies parallèles : les modifications effectuées directement dans une vue, en dehors du processus, n'apparaissent pas dans le Trail ; toutes les voies de modification doivent être couvertes.
- Comptes partagés : sans rattachement nominatif, chaque entrée perd sa valeur probante.
- Conservation non clarifiée : sans durées définies, le Trail entre en conflit avec le RGPD ou a déjà été supprimé au moment d'un contrôle.
L'Audit-Trail en pratique : ce qu'apporte CentaurNexus
CentaurNexus consigne automatiquement chaque action d'écriture dans l'exploitation Zscaler dans un Audit-Trail tenu en append-only : acteur, action, cible, moment et origine, validations selon le principe des quatre yeux incluses, demande et décision comprises. Un chaînage de hachage SHA-256 rend détectable toute modification a posteriori des sections scellées. Les preuves naissent comme sous-produit du travail quotidien et peuvent être utilisées lors de contrôles au titre de NIS2 ou de DORA ; Policy Health Saga ajoute sur demande un rapport PDF sur la santé de la configuration. Si le Trail atteint un volume Enterprise, l'Audit-Export l'exporte de façon asynchrone en CSV ou en JSON, par exemple pour le relier à un SIEM ou pour l'audit interne. La plateforme est hébergée en Allemagne, les données d'audit restent donc dans l'UE. Le guide suivant montre comment exploitation sans droits d'administrateur et preuve se rejoignent : Support Zscaler sans droits d'administrateur.
Termes associés
Questions fréquentes sur l'Audit-Trail
Au minimum l'acteur, l'action, la cible, l'horodatage, l'origine (par exemple l'adresse IP ou la session) et le résultat pour chaque action pertinente pour la sécurité ; pour les modifications critiques, s'y ajoute le lien de validation, c'est-à-dire qui l'a demandée et qui l'a approuvée. Les entrées doivent naître automatiquement côté système et être protégées contre toute modification a posteriori, sinon elles perdent leur valeur probante.
Revisionssicher signifie : complet, traçable chronologiquement, protégé contre toute modification a posteriori et disponible pendant la durée exigée. Même les administrateurs ne doivent pouvoir ni modifier ni supprimer les entrées. Une liste tenue manuellement ou un log d'exploitation tournant ne répond pas à ces exigences ; il faut une journalisation côté système, protégée contre la manipulation.
Les deux référentiels exigent des processus maîtrisés et démontrables pour les mesures de sécurité et les modifications ; la manière technique d'apporter la preuve n'est pas prescrite dans le détail, la transposition nationale et la pratique des autorités de contrôle font foi. En pratique, un Audit-Trail automatique est le moyen le plus fiable d'atteindre durablement la démontrabilité exigée, sans effort supplémentaire.
Les logs d'exploitation servent à la recherche d'erreurs, tournent après peu de temps et peuvent être modifiés ou filtrés. Un Audit-Trail sert de preuve : il est complet, conçu pour durer, rattachable à des personnes et protégé contre la manipulation. Les logs répondent à la question de ce que le système fait à l'instant ; l'Audit-Trail atteste qui a décidé et modifié quoi.
Il n'existe pas de durée uniforme ; elle résulte du secteur, de la réglementation et des exigences internes. L'important est de fixer et de documenter cette durée en connaissance de cause : assez longue pour les contrôles et le traitement des incidents, tout en restant compatible avec le RGPD. Qui ne définit pas de durée s'expose aux deux risques à la fois : des preuves manquantes et une conservation de données non conforme.
- Directive (UE) 2022/2555 (NIS2), obligations de gestion des risques et de preuve - eur-lex.europa.eu
- Règlement (UE) 2022/2554 (DORA), gestion du risque lié aux TIC et documentation des incidents - eur-lex.europa.eu
- Règlement (UE) 2016/679 (RGPD), principe de responsabilité selon l'art. 5, § 2 - eur-lex.europa.eu
Remarque : CentaurNexus est un produit indépendant de SourcingBlox GmbH et non une offre de Zscaler, Inc. Les noms de produits et de marques appartiennent à leurs détenteurs respectifs.
Avis juridique : Cet article reflète notre appréciation après une recherche approfondie des sources originales. Il ne remplace pas un conseil juridique. Faites vérifier par un avocat spécialisé si et comment la situation juridique décrite s'applique à votre entreprise. Mise à jour : 19.07.2026.