Fabricants : la question de la traçabilité que personne ne pose… jusqu’à ce qu’elle devienne incontournable
Un fabricant peut généralement produire un journal d’accès lorsqu’un client ou un auditeur en fait la demande. Mais bien peu peuvent répondre à une question plus délicate : une personne disposant d’un accès administrateur aurait-elle pu modifier ce journal en toute discrétion avant de le présenter ? Si la réponse est oui, même en théorie, ce journal ne constitue pas une preuve. Il s’agit simplement d’un document que toute personne disposant des bons identifiants aurait pu rédiger pour raconter ce qu’elle voulait sur l’accès à un fichier de conception.
Cet article explique ce qui rend réellement une traçabilité d’audit fiable en tant que preuve pour un fabricant 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 auditeur client ou un enquêteur interne repose entièrement sur la confiance dans son intégrité, et cette confiance ne peut reposer uniquement sur une règle. Si un accès administrateur au stockage sous-jacent du journal permet techniquement de le modifier, le fait qu’une règle l’interdise ne rend pas l’action impossible. Pour les responsables techniques et IT, la norme à suivre est d’ordre architectural : une personne, y compris un 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 ne constitue pas une preuve, quelle que soit sa précision.
- L’accès au stockage sous-jacent du journal doit être limité par l’architecture, et non uniquement par une règle.
- La séparation des rôles est aussi importante que la restriction des accès. La personne qui accède à un fichier de conception et celle qui contrôle l’accès à ce fichier ne doivent pas occuper le même rôle.
- L’exhaustivité et l’immédiateté participent à la fiabilité, elles n’en sont pas dissociées.
- Les clients et auditeurs 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 fabricants
La plupart des discussions sur la journalisation d’audit portent sur la couverture. La couverture compte, mais elle ne répond pas à la première question essentielle.
Un niveau de détail sans intégrité n’est qu’un récit bien écrit
Un journal riche en détails sur l’accès à un fichier de conception n’est digne de confiance que si l’on peut garantir que personne ne l’a modifié a posteriori.
La vraie question : qui aurait pu modifier ce journal ?
La première question à se poser n’est pas ce que le journal enregistre, mais qui a la capacité technique de le modifier après sa création.
Pourquoi l’intégrité des journaux relève de l’architecture et non de la procédure
Une règle qui interdit aux administrateurs de modifier les journaux repose sur leur volonté de la respecter. Un contrôle architectural supprime la possibilité technique de faire autrement.
Aucun accès permanent au stockage sous-jacent du journal
La version la plus stricte de ce contrôle consiste à ce que ni les administrateurs IT du fabricant ni l’éditeur 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 défendable d’une porte dérobée, c’est le fait que cet accès soit temporaire, nécessite une double autorisation et soit lui-même entièrement journalisé.
La séparation des rôles comme deuxième mesure de protection indépendante
Si le même rôle peut à la fois accéder à un fichier de conception et contrôler l’accès à ce fichier, il existe un conflit d’intérêts évident.
La personne qui agit ne doit pas être celle qui audite
Une véritable séparation des rôles attribue les fonctions de conformité, d’audit et de gestion des règles à des rôles distincts de l’administration opérationnelle.
Anticiper les exigences avant qu’un auditeur ne les formule
Le test à effectuer consiste à se demander, en toute honnêteté, qui pourrait techniquement modifier les journaux d’audit du fabricant, 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 garantit 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 du fabricant n’ont d’accès ordinaire au système d’exploitation ou à la base de données sous-jacente, y compris au stockage du journal d’audit ; tout accès support est temporaire, nécessite une double autorisation et est entièrement journalisé. Des rôles dédiés Compliance et Auditor séparent l’administration opérationnelle des fonctions d’audit, et chaque action sur chaque canal est enregistrée intégralement et immédiatement dans un journal d’audit infalsifiable et non limité alimentant directement les outils SIEM.
Les fabricants qui souhaitent vérifier si leur traçabilité d’audit actuelle résiste à la question « un administrateur aurait-il pu la modifier ? » peuvent réserver une démo personnalisée.
Foire aux questions
Un journal qu’un administrateur peut modifier ou supprimer ne constitue pas une preuve, quelle que soit sa précision, car l’accès administrateur au stockage sous-jacent permet techniquement de le modifier, ce qui le rend non fiable comme élément de preuve.
L’intégrité des journaux relève de l’architecture lorsque les contrôles suppriment la possibilité technique de modifier les enregistrements, par exemple en empêchant tout accès permanent au stockage sous-jacent pour les administrateurs IT ou les éditeurs, plutôt que de s’en remettre à des règles que les administrateurs doivent choisir de respecter.
La séparation des rôles garantit que la personne qui accède à un fichier de conception n’est pas celle qui contrôle cet accès, ce qui évite les conflits d’intérêts et attribue les fonctions de conformité et d’audit à des rôles distincts.
Le Data Control Plane de Kiteworks repose sur une architecture durcie où ni Kiteworks ni les administrateurs IT du fabricant n’ont d’accès ordinaire au stockage des journaux ; tout accès support est temporaire, nécessite une double autorisation et est entièrement journalisé, avec des rôles dédiés Compliance et Auditor séparant administration opérationnelle et fonctions d’audit.