Créer une piste d’audit solide pour assurer votre défense
Un prestataire peut généralement produire un journal d’accès lorsqu’un auditeur le demande. Mais bien peu peuvent 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 simplement d’un document que toute personne ayant les bons identifiants aurait pu rédiger pour raconter ce qu’elle voulait sur l’accès à un fichier contrôlé.
Cet article examine ce qui rend réellement une traçabilité d’audit fiable comme preuve pour un prestataire de défense, et pourquoi la plupart des solutions de journalisation échouent discrètement à ce test.
Résumé exécutif
L’utilité d’une traçabilité d’audit pour un auditeur CMMC ou un enquêteur interne dépend entièrement de la confiance dans son intégrité, une confiance qui ne peut reposer uniquement sur la politique 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 à rendre l’action impossible. Pour les responsables de la sécurité des programmes, le standard à atteindre est d’ordre architectural : aucune personne, même administrateur système, ne doit pouvoir 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 par l’architecture, pas seulement par la politique.
- La séparation des rôles est aussi importante que la restriction des accès. La personne qui accède au CUI et celle qui examine la traçabilité de cet accès ne doivent pas occuper le même rôle.
- L’exhaustivité et l’immédiateté font partie de la fiabilité, elles n’en sont pas dissociées.
- Les auditeurs demandent de plus en plus comment un journal est protégé, 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 prestataires
La plupart des discussions sur la journalisation d’audit 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 riche en détails sur l’accès à un fichier contrôlé 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 une fois écrit.
Pourquoi l’intégrité du journal doit être architecturale et non procédurale
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 du journal
La version la plus robuste de ce contrôle consiste à ce que ni les administrateurs IT du prestataire ni l’éditeur de la plateforme n’aient un accès ordinaire au système d’exploitation ou à la base de données où sont stockés les journaux.
Les exceptions doivent rester exceptionnelles, pas devenir 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 une double autorisation et être lui-même entièrement tracé.
La séparation des rôles comme deuxième garantie indépendante
Si le même rôle peut accéder au CUI et examiner la traçabilité de cet accès, il existe un conflit d’intérêts évident.
Celui qui agit ne doit pas être celui qui audite
Une véritable séparation des rôles confie la conformité, l’audit et la politique à des fonctions distinctes de l’administration opérationnelle.
Mettre en place le standard avant qu’un auditeur ne le réclame
Le test pratique consiste à se demander honnêtement qui pourrait techniquement modifier les journaux d’audit du prestataire, et si les rôles opérationnels et d’audit sont réellement séparés.
Comment un Data Control Plane intègre la fiabilité probante dans l’architecture
Le Data Control Plane de Kiteworks fonctionne sur une architecture durcie où ni Kiteworks ni les administrateurs IT du prestataire n’ont un 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 de façon exhaustive et immédiate dans un journal d’audit infalsifiable et non limité alimentant directement les outils SIEM.
Les prestataires souhaitant vérifier si leur traçabilité d’audit actuelle résisterait à la question « un administrateur aurait-il pu la modifier ? » peuvent réserver une démo personnalisée.
Foire aux questions
L’utilité d’une traçabilité d’audit repose entièrement sur la confiance dans son intégrité. Cette confiance ne peut se fonder uniquement sur la politique interne ; l’accès au stockage du journal doit être restreint par l’architecture afin qu’aucune personne, y compris un administrateur système, ne puisse modifier l’enregistrement.
Un journal qu’un administrateur peut modifier ou supprimer n’est pas une preuve, quelle que soit sa précision. Si l’accès administrateur permet techniquement la modification, le journal peut être manipulé pour raconter ce que l’éditeur souhaite sur l’accès à un fichier contrôlé.
La séparation des rôles est aussi importante que la restriction des accès. La personne qui accède au CUI et celle qui examine la traçabilité de cet accès ne doivent pas occuper le même rôle, sous peine de créer un conflit d’intérêts évident.
Le Data Control Plane de Kiteworks fonctionne sur une architecture durcie où ni Kiteworks ni les administrateurs IT du prestataire n’ont un 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 support est temporaire, à double autorisation et entièrement tracé, avec des rôles dédiés à la conformité et à l’audit séparant l’administration opérationnelle des fonctions d’audit.