À quelles épreuves les journaux d’audit du secteur public doivent-ils réellement résister
Une agence peut généralement produire un journal d’accès lorsqu’un organisme de contrôle le demande. Mais rares sont celles capables de répondre à une question plus délicate : une personne disposant d’un accès administrateur aurait-elle pu modifier ce journal discrètement avant de le transmettre ? Si la réponse est oui, même en théorie, le journal ne constitue pas une preuve. Il s’agit alors d’un document que toute personne disposant des bons identifiants aurait pu rédiger pour y inscrire ce qu’elle voulait sur les accès à un dossier citoyen.
Cet article explique ce qui rend réellement une traçabilité fiable comme preuve pour une agence du secteur public, et pourquoi la plupart des journaux d’accès échouent discrètement à ce test.
Résumé exécutif
L’utilité d’une traçabilité pour un organisme de contrôle ou un enquêteur interne repose entièrement sur la confiance dans son intégrité, et cette confiance ne peut pas se limiter à une règle interne. Si un accès administrateur au stockage du journal permet techniquement de le modifier, le fait qu’une politique l’interdise ne suffit pas : ce n’est pas la même chose que rendre l’action impossible. Pour les responsables IT et conformité, la vraie exigence est d’ordre architectural : une personne, même administrateur système, peut-elle réellement modifier l’enregistrement ?
Résumé des points clés
- Un journal qu’un administrateur peut modifier ou supprimer n’est pas une preuve, quelle que soit sa précision.
- L’accès au stockage du journal doit être restreint au niveau de l’architecture, et non par une simple règle interne.
- La séparation des tâches est aussi importante que la restriction des accès. La personne qui accède à un dossier citoyen et celle qui contrôle cet accès ne doivent pas occuper le même rôle.
- L’exhaustivité et l’instantanéité font partie de la fiabilité, elles n’en sont pas dissociables.
- Les organismes de contrôle demandent de plus en plus comment un journal est protégé, et pas seulement ce qu’il contient.
Pourquoi « Nous avons des journaux détaillés » n’est pas le bon point de départ pour les agences
La plupart des discussions sur la traçabilité portent sur la couverture. C’est important, mais cela ne répond pas à la première question essentielle.
Le détail sans intégrité n’est qu’une belle histoire
Un journal détaillé sur les accès à un dossier citoyen n’est digne de confiance que si l’on peut garantir qu’il n’a pas été modifié après coup.
La vraie question : qui aurait pu modifier ce journal ?
La première question à se poser n’est pas ce qu’un journal enregistre, mais qui a la capacité technique de le modifier une fois écrit.
Ce qui rend l’intégrité d’un journal architecturale plutôt que procédurale
Une règle qui interdit aux administrateurs de modifier les journaux repose sur leur bonne volonté. Un contrôle architectural supprime la possibilité technique de faire autrement.
Aucun accès permanent au stockage du journal
La version la plus solide de ce contrôle consiste à ce que ni les administrateurs IT de l’agence ni le fournisseur de la plateforme n’aient d’accès ordinaire au système d’exploitation ou à la base de données où sont stockés les journaux.
Les exceptions doivent rester des exceptions, pas des portes dérobées
Ce qui distingue une exception justifiée d’une porte dérobée, c’est que cet accès soit temporaire, nécessite une double autorisation, et soit lui-même entièrement tracé.
La séparation des tâches comme deuxième garantie indépendante
Si le même rôle peut à la fois accéder à un dossier citoyen et contrôler les accès à ce dossier, il existe un conflit d’intérêts évident.
Celui qui agit ne doit pas être celui qui contrôle
Une vraie séparation des tâches confie la conformité, l’audit et la gestion des règles à des rôles distincts de l’administration opérationnelle.
Mettre en place la norme avant qu’un organisme de contrôle ne l’exige
Le test concret consiste à se demander honnêtement qui pourrait techniquement modifier les journaux d’audit de l’agence, et si les rôles opérationnels et de contrôle sont réellement séparés.
Comment un Data Control Plane intègre l’intégrité des preuves dans l’architecture
Le Data Control Plane de Kiteworks fonctionne sur une architecture durcie où ni Kiteworks ni les administrateurs IT de l’agence n’ont d’accès ordinaire au système d’exploitation ou à la base de données sous-jacente, y compris le stockage du journal d’audit ; tout accès support est temporaire, à double autorisation, et entièrement tracé. Des rôles dédiés à la conformité et à l’audit séparent l’administration opérationnelle des fonctions d’audit, et chaque action sur chaque canal est capturée immédiatement et intégralement dans un journal d’audit inviolable et non limité qui alimente directement les outils SIEM.
Les agences qui souhaitent vérifier si leur traçabilité actuelle résiste à la question « un administrateur aurait-il pu modifier ce journal ? » peuvent réserver une démo personnalisée.
Foire aux questions
Une traçabilité n’est fiable que si son intégrité est garantie par l’architecture, c’est-à-dire qu’aucune personne — y compris les administrateurs système — ne peut techniquement modifier ou supprimer les enregistrements une fois écrits. Une simple règle interne ne suffit pas si la modification reste possible.
La richesse des détails sur les accès n’a de valeur que si l’on garantit que le journal ne peut pas être modifié après coup. Sans restriction architecturale, un journal détaillé n’est qu’une histoire bien rédigée qu’une personne ayant les bons identifiants aurait pu inventer.
La séparation des tâches garantit que le rôle qui accède aux dossiers citoyens est distinct de celui qui contrôle ou audite ces accès. Cela évite les conflits d’intérêts et confie la conformité et l’audit à des rôles séparés de l’administration opérationnelle.
Parmi ces caractéristiques : aucun accès permanent au stockage du journal pour les administrateurs IT ou les fournisseurs, des exceptions temporaires à double autorisation qui sont elles-mêmes tracées, et la capture immédiate et complète de chaque action dans un journal inviolable alimentant directement les systèmes SIEM.