Services financiers : un problème de confiance dans leur propre traçabilité

Une banque peut généralement produire un journal d’audit lorsqu’un régulateur 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 discrètement ce journal avant de le transmettre ? Si la réponse est oui, même en théorie, ce 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 raconter ce qu’elle voulait sur l’historique des transactions d’un client.

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 fiabilité à refléter les faits réels, et non ce qu’un administrateur préférerait montrer. Cet article explique ce qui rend réellement une traçabilité d’audit fiable comme preuve pour une institution financière, et pourquoi la plupart des systèmes de journalisation échouent discrètement à ce test.

Résumé Exécutif

L’utilité d’une traçabilité d’audit pour un régulateur ou un enquêteur interne repose entièrement sur la confiance dans son intégrité, et cette confiance ne peut pas reposer uniquement sur la politique interne. Si un accès administrateur permet techniquement de modifier le stockage des journaux, interdire cette action par une règle ne suffit pas : il faut que l’action soit impossible. Pour les responsables de la sécurité et de la conformité, la norme à atteindre est architecturale : aucune personne, y compris un administrateur système, ne doit pouvoir modifier l’enregistrement.

Points Clés à Retenir

1. Un journal qu’un administrateur peut modifier ou supprimer n’est pas une preuve, quel que soit son niveau de détail. Sa valeur probante dépend du fait qu’il puisse ou non être altéré.
2. L’accès au stockage des journaux doit être restreint par l’architecture, et non seulement par la politique. Interdire la modification des journaux ne sert à rien si la possibilité technique subsiste.
3. La séparation des tâches est aussi importante que la restriction des accès. La personne qui effectue une transaction ne doit pas être celle qui contrôle ou vérifie son enregistrement.
4. L’exhaustivité et l’immédiateté font partie de la fiabilité, elles n’en sont pas dissociées. Un journal qui prélève des échantillons sous charge ou retarde l’écriture des entrées crée une fenêtre où des événements peuvent être effacés avant d’être enregistrés.
5. Les régulateurs demandent de plus en plus comment un journal est protégé, pas seulement ce qu’il contient. Une institution incapable de dire qui aurait pu modifier un enregistrement n’est pas prête à répondre à cette question.

Pourquoi « Nous avons des journaux détaillés » n’est pas le bon point de départ pour les institutions financières

La plupart des discussions sur la journalisation d’audit se concentrent sur la couverture. La couverture est importante, mais elle ne répond pas à la première question essentielle.

Le détail sans intégrité n’est qu’une belle histoire

Un journal riche en détails sur les transactions clients n’est digne de confiance que si personne ne peut le modifier 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 sommaire.

La vraie question : qui aurait pu modifier ce journal ?

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 son écriture.

Ce qui fait de l’intégrité des journaux un enjeu d’architecture et non de procédure

Une politique 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 des journaux

La version la plus solide de ce contrôle consiste à empêcher aussi bien les administrateurs IT de l’institution que le fournisseur de la plateforme d’accéder normalement 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 défendable d’une porte dérobée, c’est que cet accès doit être temporaire, nécessiter l’autorisation explicite de plusieurs parties et être lui-même entièrement journalisé.

La séparation des tâches comme deuxième garantie indépendante

Si le même rôle peut déplacer des fonds clients et contrôler l’enregistrement de cette action, il existe un conflit d’intérêts inhérent.

La personne qui agit ne doit pas être celle qui audite

Une véritable séparation des tâches confie la conformité, l’audit et la politique à des rôles distincts de l’administration opérationnelle.

Mettre en place la norme avant que le régulateur ne la réclame

Le test à réaliser consiste à se demander honnêtement qui pourrait techniquement modifier les journaux d’audit de l’institution, et si les rôles opérationnels et ceux chargés de l’audit sont réellement séparés.

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

Le Data Control Plane de Kiteworks fonctionne sur une architecture durcie où ni Kiteworks ni les administrateurs IT de l’institution n’ont d’accès ordinaire au système d’exploitation ou à la base de données sous-jacente, y compris au stockage des journaux d’audit ; tout accès de support est temporaire, doublement autorisé et entièrement journalisé. Des rôles dédiés Compliance, Auditor et RSSI séparent l’administration opérationnelle des fonctions d’audit, et chaque action sur chaque canal est enregistrée de façon complète et immédiate dans un journal d’audit infalsifiable et non limité alimentant directement les outils SIEM.

Les institutions souhaitant tester si leur traçabilité d’audit actuelle résisterait à la question « un administrateur aurait-il pu modifier ce journal ? » peuvent réserver une démo personnalisée.