Que faut-il conserver dans un « journal d'audit » exigé dans les appels d'offres ?
Bonjour, je suis Ōtsuka, CTO chez Liberogic.
Lors de la participation à un appel d'offres pour un site web ou un service web, on trouve souvent dans les exigences des mentions telles que « être capable de générer un journal d'audit » ou « conserver les journaux pendant une période déterminée ».
Pour répondre à ces exigences, on choisit un service, on modifie un forfait ou on ajoute une option de conservation des journaux. Mais au fond, de quoi parle-t-on exactement lorsqu'on évoque un « journal d'audit » ?
Nous allons donc essayer de clarifier ces points.
Les différents types de journaux
Le terme « journal » recouvre en réalité plusieurs types de données.
Types de journaux | Principaux éléments enregistrés | Usages principaux |
|---|---|---|
Journaux d'accès | URL, date et heure, statut, origine de la connexion, etc. | Analyse de l'utilisation et investigation des pannes |
Journaux d'application | Début et fin de traitement, événements métier | Vérification du bon fonctionnement et investigation des dysfonctionnements |
Journaux d'erreurs | Exceptions, arrêts anormaux, détails des erreurs | Identification de la cause des pannes |
Journaux d'audit | qui a effectué quelle opération, quand et sur quoi | Contrôle interne et préservation des preuves |
Journaux de sécurité | Authentification, refus d'accès et détection des attaques | Enquête sur les incidents |
Il s'agit bien de journaux dans tous les cas, mais leur contenu enregistré et leur finalité diffèrent.
Par exemple, les journaux qui enregistrent qu'un administrateur a modifié les droits d'un utilisateur ou qu'un responsable a publié un contenu sont généralement ce qu'on appelle des journaux d'audit.
Distinguer l'analyse des pannes de la préservation des preuves
Les journaux poursuivent principalement deux objectifs.
Le premier consiste à journaliser les pannes et les dysfonctionnements afin d'en identifier la cause.
Ils servent à examiner des demandes telles que « le formulaire envoyé hier n'est pas arrivé » ou « une erreur s'est produite pendant une période précise ».
Le second est un journal permettant de vérifier a posteriori les actions effectuées.
Il enregistre des informations telles que « qui a modifié les paramètres », « quand le contenu a été publié » et « quelles opérations ont été effectuées dans l'interface d'administration ».
Point de comparaison | Investigation et amélioration des incidents | Audit et conservation des preuves |
|---|---|---|
Utilisateurs principaux | Développeurs, personnel d'exploitation | Auditeurs, responsables de la sécurité |
Période généralement consultée | Quelques jours à quelques semaines | de quelques mois à plusieurs années |
Points à privilégier | Facilité de recherche, quantité d'informations | Absence de lacunes et conservation sur la durée |
Fréquence de consultation | Consultation régulière | Récupération ponctuelle en cas de besoin |
Ces deux types de données ont des durées de conservation et des modes d'utilisation différents.
Conserver l'ensemble des journaux pendant une longue durée, dans un état permettant une recherche rapide, entraîne des coûts importants. À l'inverse, ne conserver que les journaux les plus récents empêche de disposer des preuves nécessaires aux audits et aux enquêtes sur incidents.
Il est préférable de les distinguer dès le départ, afin d'obtenir une conception plus cohérente et soutenable.
Traduire « besoin de journaux d'audit » en exigences
Le seul terme « journaux d'audit » ne suffit pas à définir une architecture concrète.
Nous commençons par clarifier l'objectif, puis nous définissons les enregistrements nécessaires et la manière de les conserver.
« Les journaux sont disponibles » ne suffit pas
Lorsque les journaux apparaissent dans la console d'administration d'un service cloud, on est tenté de considérer que « les journaux sont bien collectés ».
Cependant, le contenu conservé et la durée de conservation varient selon les services.
- Les erreurs sont conservées, mais pas les actions des administrateurs
- Consultables dans la console d'administration, mais supprimés après une certaine période
- Le transfert vers un système externe nécessite une offre supérieure
- Les opérations propres à l'application doivent être journalisées par nos soins
Certains registres métier, comme « qui a modifié les informations produit » ou « quelles demandes de réservation ont été traitées », ne peuvent pas toujours être retrouvés uniquement à partir des services cloud.
Si le cahier des charges d'un appel d'offres mentionne des « journaux d'audit », il est recommandé de vérifier au minimum les points suivants.
Liste de contrôle pour la définition des besoins
✅️ Quelles opérations faut-il enregistrer ?
✅️ S'agit-il d'opérations effectuées par les utilisateurs ou par les administrateurs ?
✅️ Le but est-il l'investigation des incidents ou l'audit ?
✅️ Pendant combien de temps faut-il les conserver ?
✅️ Faut-il pouvoir les rechercher régulièrement ?
✅️ Qui doit pouvoir consulter les journaux ?
✅️ Peuvent-ils contenir des données personnelles ?
Si ces points restent flous au moment de choisir les services ou les formules, l'architecture peut devenir plus lourde que nécessaire, ou, à l'inverse, certains journaux indispensables peuvent ne pas être conservés.
Dans les services web modernes, les journaux sont également dispersés
Avec les serveurs web traditionnels, il suffisait de conserver les fichiers journaux sur le serveur, une approche relativement simple à comprendre.
Aujourd'hui, les services web combinent de plus en plus de services cloud : CDN, hébergement, bases de données, headless CMS, envoi d'e-mails, etc.
Chez Liberogic, nous utilisons selon les projets non seulement AWS, mais aussi Cloudflare, Vercel, Supabase, microCMS, Kuroco, etc.
Les journaux étant également répartis entre chaque service, il faut examiner l'ensemble du système pour déterminer ce qui est réellement enregistré.
Commençons par clarifier l'objectif.
Lorsqu'on entend « des journaux d'audit sont nécessaires », on a souvent l'impression qu'il faut mettre en place un service spécial.
Bien sûr, selon les exigences, un service externe de gestion des journaux ou un dispositif de conservation à long terme peut être nécessaire. Pour autant, il n'est pas forcément judicieux de bâtir d'emblée une architecture complexe.
Il s'agit d'abord de définir quoi journaliser, dans quel but, et pendant combien de temps conserver les données.
Une fois ces points clarifiés, il est réaliste de distinguer ce qui peut être couvert par les fonctionnalités standard et ce qui nécessite la mise en place de mécanismes supplémentaires.
Dans un prochain article, nous comparerons brièvement les journaux générés par des services que nous utilisons souvent, comme AWS, Cloudflare, Vercel, Supabase ou les CMS headless.
Bref, voilà.
Pilier du département technique de Liberogic. Lorsqu'il entend une remarque du type « Ce serait pratique d'avoir ça… », il ajoute de la valeur grâce à son ingéniosité et met en œuvre la solution en un rien de temps. Très apprécié des clients pour sa grande capacité de communication, il est aussi un trésor de notre entreprise, et un grand amoureux des chats.
Sho Otsuka
Directeur technique (CTO) / Ingénieur en chef / Représentant de Nekoana LLC / Paraît étonnamment jeune