Si un administrateur peut modifier le journal, il ne constitue pas une preuve : créer une piste d’audit digne de confiance pour les régulateurs

Introduction

La plupart des organisations peuvent produire un journal d’audit sur demande. Bien moins nombreuses sont celles capables de répondre à une question plus complexe : une personne disposant d’un accès administrateur aurait-elle pu modifier discrètement ce journal avant de le fournir ? Si la réponse est oui, même en théorie, ce journal ne constitue pas une preuve. Il s’agit d’un document que toute personne disposant des bons identifiants pourrait rédiger à sa guise.

Les régulateurs et les auditeurs posent désormais cette question directement, car la valeur d’une traçabilité d’audit dépend entièrement de sa capacité à refléter ce qui s’est réellement passé, et non ce qu’un administrateur aurait préféré voir apparaître. Un journal techniquement exhaustif, mais stocké dans une base de données accessible en écriture à n’importe quel administrateur, n’est pas fondamentalement différent d’un journal sans aucun contrôle d’accès. Cet article analyse ce qui rend réellement une traçabilité d’audit fiable en tant que preuve, et pourquoi la plupart des organisations échouent discrètement à ce test.

• Résumé 1 : Un journal qu’un administrateur peut modifier ou supprimer ne constitue pas une preuve, quelle que soit sa précision. Sa valeur probante dépend de la possibilité qu’il ait été altéré, et non de la quantité de données qu’il contient.
• Résumé 2 : L’accès au stockage sous-jacent du journal doit être restreint au niveau de l’architecture, et pas seulement par des règles internes. Une règle interdisant la modification des journaux n’a aucune valeur si la possibilité technique de le faire existe toujours.
• Résumé 3 : La séparation des tâches est aussi importante que la restriction des accès. La personne qui effectue une action et celle qui peut examiner ou contrôler la trace de cette action ne doivent pas occuper le même rôle.
• Résumé 4 : L’exhaustivité et l’immédiateté font partie de la fiabilité, elles n’en sont pas dissociées. Un journal qui effectue des échantillonnages en cas de charge, ou qui retarde l’enregistrement des entrées, crée une fenêtre où des événements peuvent passer inaperçus ou être effacés avant d’être capturés.
• Résumé 5 : Les régulateurs demandent de plus en plus comment un journal est protégé, et pas seulement ce qu’il contient. Une organisation incapable de dire qui aurait pu modifier une trace, et comment cela est empêché, n’est pas prête à répondre à cette question.

Résumé Exécutif

L’utilité d’une traçabilité d’audit pour un régulateur, un auditeur ou un enquêteur interne repose entièrement sur la confiance dans son intégrité, et cette confiance ne peut pas reposer uniquement sur des règles internes. Si l’accès administratif au stockage du journal permet techniquement la modification ou la suppression, le fait qu’une règle l’interdise n’est pas équivalent à l’impossibilité d’agir. Pour les responsables de la sécurité et de la conformité, la norme à appliquer est architecturale : une personne, y compris un administrateur système, peut-elle modifier la trace ? Si oui, la valeur probante du journal est compromise, peu importe son apparence. Concevoir une traçabilité d’audit fiable suppose de bâtir un modèle d’accès qui permette de répondre de façon vérifiable par la négative à la question « cela aurait-il pu être modifié ? »

Pourquoi « Nous avons des journaux détaillés » n’est pas le bon point de départ

La plupart des discussions sur la journalisation d’audit portent sur la couverture : quelles activités sont enregistrées, quel niveau de détail chaque entrée contient, sur quelle période l’historique s’étend. La couverture est importante, mais elle ne répond pas à la question essentielle.

Le détail sans intégrité n’est qu’une histoire bien racontée

Un journal riche en détails, horodatages, attribution utilisateur, adresses IP, noms de fichiers, n’est fiable que si l’on peut garantir que personne ne l’a modifié a posteriori. Un administrateur ayant accès à la base de données peut, en principe, modifier un journal très détaillé aussi facilement qu’un journal succinct. Le détail améliore l’utilité d’un journal une fois son intégrité établie. Mais il ne suffit pas à établir cette intégrité.

La vraie question : qui aurait pu modifier ceci ?

La première question à se poser pour évaluer un journal d’audit n’est pas ce qu’il enregistre, mais qui a la capacité technique de le modifier après coup. Si la réponse honnête inclut « un administrateur système, avec accès à la base de données », la fiabilité du journal comme preuve est déjà remise en cause, quelle que soit la politique interne concernant le comportement des administrateurs.

Pourquoi l’intégrité du journal relève de l’architecture et non de la procédure

Une règle qui interdit aux administrateurs de modifier les journaux est un contrôle procédural. Elle repose sur le choix des administrateurs de la respecter. Un contrôle architectural supprime la possibilité technique de faire autrement, quelle que soit l’intention.

Pas d’accès permanent au stockage du journal

La version la plus stricte de ce contrôle consiste à ce que ni les administrateurs IT de l’organisation ni l’éditeur de la plateforme n’aient d’accès ordinaire au système d’exploitation ou à la base de données où les journaux sont physiquement stockés. L’accès à la couche applicative, pour configurer les règles ou consulter les rapports, est totalement différent d’un accès au stockage sous-jacent qui permettrait de réécrire l’historique. Lorsque cet accès sous-jacent n’existe tout simplement pas pour l’administration courante, la question « un administrateur pourrait-il modifier ceci ? » trouve une réponse structurelle, et non basée sur une règle.

Les exceptions doivent rester exceptionnelles, pas devenir des portes dérobées

Certaines solutions exigent un accès privilégié ponctuel pour des raisons de support ou de diagnostic. Ce qui distingue une exception défendable d’une porte dérobée, c’est que cet accès soit temporaire, nécessite une autorisation explicite de plusieurs personnes et soit lui-même intégralement journalisé. Un accès d’urgence permanent, unilatéral ou non journalisé n’est pas une exception au contrôle, mais l’absence de contrôle.

La séparation des tâches comme deuxième garde-fou indépendant

Restreindre l’accès au stockage des journaux comble une faille. Mais une deuxième faille s’ouvre si le même rôle peut à la fois agir et contrôler ou examiner la trace de cette action.

Celui qui agit ne doit pas être celui qui audite

Si un même rôle administratif peut à la fois réaliser des opérations sensibles et accéder ou configurer la journalisation et le reporting de conformité de ces opérations, il existe un conflit d’intérêts inhérent, qu’il soit exploité ou non. Une véritable séparation des tâches confie les fonctions de conformité, d’audit et de gestion des règles à des rôles distincts de l’administration opérationnelle, afin qu’aucun compte ne détienne à la fois la capacité d’agir et une influence unilatérale sur la manière dont l’action est enregistrée ou rapportée.

L’anonymisation par défaut protège la trace sous un autre angle

Un autre garde-fou consiste à considérer par défaut les informations identifiantes dans les journaux comme protégées, et à ne les révéler qu’à l’issue d’une démarche volontaire et traçable, plutôt que de les rendre librement consultables à toute personne ayant accès aux rapports. Cela limite la possibilité de relier facilement une entrée à une personne précise, ajoutant une couche de protection supplémentaire entre l’accès courant et la possibilité d’interpréter ou d’exploiter sélectivement la trace.

L’exhaustivité et l’immédiateté sont des gages de fiabilité

Une traçabilité d’audit avec un modèle d’accès réellement restreint peut tout de même échouer en tant que preuve si elle n’enregistre pas tout, ou si elle le fait trop lentement pour être utile.

La journalisation échantillonnée ou limitée crée des failles où un incident peut se cacher

Un système de journalisation qui omet des entrées en cas de forte charge, ou qui échantillonne au lieu d’enregistrer chaque événement, crée précisément le type de faille dans laquelle un incident, ou quelqu’un cherchant à le dissimuler, peut se glisser. Un journal conçu pour résister aux manipulations, mais incomplet à cause d’une limitation, échoue tout autant au test « ceci reflète-t-il ce qui s’est réellement passé ? », mais par un autre mécanisme.

Les écritures différées laissent une fenêtre avant l’existence de la trace

Une entrée de journal non ajoutée immédiatement laisse une fenêtre, même brève, pendant laquelle l’événement s’est produit mais aucune trace n’existe encore. Pour la plupart des usages, cette fenêtre est anodine. Mais pour constituer une preuve, tout écart entre l’événement et sa trace durable est une faille dans la chaîne de confiance que le journal est censé garantir.

Construire la norme avant que le régulateur ne la réclame

Le test à appliquer dans toute organisation consiste à se demander, honnêtement, qui pourrait techniquement modifier ses journaux d’audit, si cet accès relève d’une exception ponctuelle à double autorisation ou de l’administration courante, si les rôles opérationnels et les rôles d’audit sont réellement séparés, et si la journalisation est exhaustive et immédiate plutôt que limitée ou différée. Une organisation capable de répondre avec assurance à ces quatre points dispose d’une traçabilité d’audit qui fait foi. Une organisation qui doit réfléchir longuement à l’un d’eux ne possède qu’un journal qui en a l’apparence.

Comment un Data Control Plane intègre la valeur probante dans l’architecture

Respecter cette norme suppose que le modèle d’accès, et pas seulement la politique interne, supprime la possibilité de modifier les traces, tout en assurant la séparation des tâches, l’exhaustivité et l’immédiateté, quels que soient les choix des administrateurs.

Le Data Control Plane de Kiteworks repose sur une architecture durcie où ni Kiteworks ni les administrateurs IT du client n’ont d’accès ordinaire au système d’exploitation ou à la base de données, y compris au stockage des journaux d’audit ; tout accès de support est temporaire, à double autorisation et intégralement journalisé. Les rôles dédiés Compliance, Auditor, Policy Manager, CISO et Data Leak Investigator séparent l’administration opérationnelle des fonctions d’audit et de conformité, de sorte qu’aucun rôle n’ait à la fois la capacité d’agir et de contrôler la trace de cette action, et les journaux sont anonymisés par défaut pour ajouter une protection supplémentaire. Chaque action sur chaque canal, y compris la messagerie électronique, le partage de fichiers, les API et les agents IA, est enregistrée intégralement et en temps réel, sans limitation ni échantillonnage, et la trace ainsi produite alimente directement les outils SIEM pour une analyse indépendante.

Les organisations souhaitant tester si leur traçabilité d’audit actuelle résisterait à la question « un administrateur aurait-il pu modifier ceci ? » peuvent réserver une démo personnalisée pour voir comment l’intégrité architecturale des journaux s’applique à leur propre environnement.