Journalisation : quoi journaliser et combien de temps

La journalisation consiste à enregistrer, de façon horodatée, les événements qui se produisent sur un système, un équipement réseau ou une application : connexions, accès aux données, actions d'administration, erreurs. Ces enregistrements s'appellent des journaux, ou logs. Ce chapitre explique à quoi ils servent, quels événements tracer, comment écrire une ligne de journal utile, ce qu'il ne faut jamais y mettre, combien de temps les garder et comment les mettre en place côté infrastructure et côté application.

À quoi sert un journal : détecter, comprendre, prouver

Un journal remplit trois missions.

• Détecter une attaque pendant qu'elle se produit : une rafale d'échecs de connexion, un compte qui se connecte à 3 heures du matin depuis l'étranger, un export massif de données.
• Comprendre après coup ce qui s'est passé : par où l'attaquant est entré, ce qu'il a touché, quelles données il a consultées. C'est indispensable pour corriger la bonne faille et pour remplir une notification de violation de données, qui demande la nature des données et le nombre de personnes concernées.
• Prouver : qui a fait quoi, devant la direction, un auditeur, la CNIL ou un juge. Le RGPD impose au responsable de traitement de pouvoir démontrer sa conformité (principe de responsabilité, article 5) ; les journaux en sont une pièce maîtresse.

La CNIL rattache d'ailleurs la journalisation à l'obligation de sécurité des articles 5 et 32 du RGPD, dans sa recommandation sur la journalisation (délibération n° 2021-122 du 14 octobre 2021). Un système sans journaux, c'est une boutique sans caméras ni registre de caisse : tu découvres le vol des semaines plus tard, sans savoir qui, quand, ni combien.

Les sources de journaux

Chaque couche du système d'information produit ses propres journaux.

Aucune source ne suffit seule. Une connexion VPN (pare-feu), suivie d'une ouverture de session (contrôleur de domaine), puis d'une copie massive de fichiers (serveur de fichiers) ne raconte une histoire que si l'on rapproche les trois. C'est la corrélation.

Quels événements journaliser

On ne journalise pas tout : trop de journaux noient les signaux utiles, coûtent en stockage et contiennent des données personnelles qu'il faut ensuite protéger. On journalise les événements de sécurité.

Pour les applications qui traitent des données personnelles, la recommandation de la CNIL est précise : les opérations de création, consultation, modification et suppression des données doivent être enregistrées avec l'auteur individuellement identifié, l'horodatage, la nature de l'opération et la référence des données concernées, en évitant de recopier les données elles-mêmes dans le journal.

Anatomie d'une bonne ligne de journal

Une ligne de journal exploitable répond à six questions.

Deux formats coexistent :

2026-10-13T09:14:02+02:00 INFO  event=LOGIN_FAIL user=karim.benali ip=192.168.10.31 reason=bad_password

{"ts":"2026-10-13T09:14:02+02:00","level":"INFO","event":"LOGIN_FAIL","user":"karim.benali","ip":"192.168.10.31","reason":"bad_password"}

Le texte se lit facilement dans un terminal. Le JSON structuré se lit moins bien à l'œil, mais un SIEM l'indexe sans effort, champ par champ, ce qui permet des recherches exactes (user = "karim.benali" AND event = "LOGIN_FAIL"). Dès que les journaux sont centralisés, le format structuré l'emporte.

Ce qu'on n'écrit jamais dans un journal

Un journal est souvent moins bien protégé que la base de données : il est copié, envoyé à un prestataire, lu par plus de monde. Tout ce qu'il contient doit pouvoir fuiter sans catastrophe.

• Jamais de secret : mot de passe (même erroné : c'est souvent le bon avec une faute de frappe), jeton de session, cookie, clé d'API, clé privée, code d'authentification à usage unique.
• Pas de données sensibles en clair : numéro de carte bancaire, numéro de sécurité sociale, données de santé, contenu d'un message. Utilise une référence (client:4821) ou un masque (carte=**** **** **** 4242).
• Pas de recopie des données traitées : le journal dit que le dossier 4821 a été consulté, pas ce qu'il contient.

Une autre précaution côté code : l'injection dans les journaux. Si l'identifiant saisi par l'utilisateur est écrit tel quel, un attaquant peut y glisser un retour à la ligne et fabriquer une fausse ligne (karim\n2026-10-13T09:15:00 INFO event=LOGIN_OK user=admin). On neutralise les caractères de contrôle (retours à la ligne, tabulations) avant d'écrire, ou on utilise un format structuré qui les échappe, comme le JSON.

L'horodatage : une heure juste et un fuseau clair

Rapprocher des journaux n'a de sens que si les horloges sont synchronisées. Une machine qui dérive de quatre minutes rend une chronologie fausse et fragilise la valeur de preuve.

• Synchronise toutes les machines sur une source de temps commune avec NTP : dans un domaine Windows, les postes suivent les contrôleurs de domaine, eux-mêmes calés sur une source externe fiable ; sous Linux, systemd-timesyncd ou chrony. Les équipements réseau aussi.
• Écris l'heure au format ISO 8601 avec le décalage (2026-10-13T09:14:02+02:00) ou en UTC (2026-10-13T07:14:02Z). Une heure sans fuseau est ambiguë deux fois par an, au changement d'heure.
• Pour la valeur de preuve, la CNIL recommande d'horodater et de signer les journaux dès leur création.

Les niveaux de gravité

Chaque événement porte un niveau de gravité, qui sert à filtrer et à déclencher des alertes. Le protocole syslog en définit huit, de 0 (le plus grave) à 7.

Les bibliothèques de journalisation des langages utilisent des niveaux proches (DEBUG, INFO, WARNING, ERROR, CRITICAL). Le niveau DEBUG ne doit pas rester actif en production.

Combien de temps conserver les journaux

Les journaux contiennent des données personnelles : identifiants, adresses IP, actions des salariés. Le principe de limitation de la conservation du RGPD s'applique donc à eux aussi. Il faut trouver l'équilibre entre deux risques : garder trop peu (une intrusion découverte au bout de cinq mois, et les journaux s'arrêtent à trois) et garder trop (un énorme gisement de données exposé, une surveillance excessive des salariés).

La recommandation de la CNIL de 2021 fixe un repère : conserver les journaux entre six mois et un an. Une durée plus longue peut se justifier par une obligation légale ou un risque particulier, et doit alors être documentée. La même recommandation demande :

• de conserver les journaux à part du système principal, par exemple sur des équipements distincts, accessibles en écriture seule par les applications, sans possibilité d'écraser les données existantes ;
• de restreindre l'accès aux journaux aux personnes habilitées, sur le principe de stricte nécessité, et de lever une alerte si un compte habilité modifie des journaux ;
• de ne pas les réutiliser pour un autre usage que la sécurité (surveiller la productivité d'un salarié serait un détournement de finalité) ;
• d'informer les utilisateurs de l'existence de la journalisation, de la nature des données collectées et de la durée de conservation, par exemple par un message à la connexion ou dans la charte informatique.

Protéger les journaux

Un attaquant qui prend la main sur un serveur cherche à effacer ses traces. Les journaux restés sur la machine compromise ne prouvent plus rien.

• Les exporter en continu vers un serveur de collecte distinct, que l'attaquant ne contrôle pas (chapitre 4).
• Les rendre infalsifiables : stockage en ajout seul, signature ou chaînage d'empreintes, support non réinscriptible pour les archives.
• Surveiller la journalisation elle-même : sous Windows, l'événement 1102 signale l'effacement du journal Sécurité ; une source qui se tait d'un coup doit déclencher une alerte.
• Gérer la place : la rotation (logrotate sous Linux, taille maximale des journaux sous Windows) évite qu'un disque plein arrête le service ou écrase les événements les plus anciens. La taille maximale par défaut du journal Sécurité de Windows est modeste : sur un serveur très sollicité, elle peut ne couvrir que quelques jours, voire quelques heures. On l'augmente par stratégie de groupe et, surtout, on exporte les événements.

Mettre en place la journalisation côté SISR

Sous Windows, l'audit se règle par stratégie de groupe, dans Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Configuration avancée de la stratégie d'audit. Active au minimum, en succès et en échec : l'ouverture et la fermeture de session, la gestion des comptes, la validation des informations d'identification, l'utilisation des privilèges sensibles et la création de processus. L'accès aux fichiers ne se journalise que si tu l'actives et que tu poses une liste de contrôle d'audit (SACL) sur les dossiers concernés. Vérifie la stratégie effective avec :

auditpol /get /category:*

Sous Linux, sur Debian 12 et 13, rsyslog n'est plus installé par défaut : le journal de systemd conserve les événements sur disque, dans /var/log/journal, et se lit avec journalctl. Les fichiers comme /var/log/auth.log n'existent que si tu installes rsyslog (apt install rsyslog), souvent pour envoyer les journaux vers un serveur central (voir aussi l'administration Linux). Pour surveiller un fichier sensible, le démon d'audit auditd enregistre chaque accès :

# Journaliser toute écriture ou modification d'attributs de /etc/shadow, avec une étiquette
sudo auditctl -w /etc/shadow -p wa -k shadow
# Retrouver ces événements
sudo ausearch -k shadow

Une règle posée avec auditctl disparaît au redémarrage : pour la rendre permanente, on l'écrit dans un fichier de /etc/audit/rules.d/.

Sur les équipements réseau, active l'envoi syslog du pare-feu, des commutateurs et des bornes Wi-Fi vers le serveur de collecte, et journalise au minimum les connexions d'administration, les changements de configuration et les flux bloqués.

Mettre en place la journalisation côté SLAM

Côté développement, on n'écrit pas les journaux à la main avec des echo : on utilise une bibliothèque de journalisation, qui gère les niveaux, le format, la rotation et les destinations. En PHP, la référence est Monolog ; en C#, Serilog ou NLog ; en Java, Log4j 2 ou Logback ; en Node.js, pino ou winston.

Voici comment Hugo journalise les connexions au site des Ateliers Morvan avec Monolog 3 :

<?php
use Monolog\Logger;
use Monolog\Level;
use Monolog\Handler\StreamHandler;
use Monolog\Formatter\JsonFormatter;

$handler = new StreamHandler('/var/log/morvan/securite.log', Level::Info);
$handler->setFormatter(new JsonFormatter());
$journal = new Logger('securite');
$journal->pushHandler($handler);

// Après la vérification du mot de passe
if ($connexionReussie) {
    $journal->info('LOGIN_OK', ['user' => $login, 'ip' => $_SERVER['REMOTE_ADDR']]);
} else {
    // Jamais $motDePasse ici, même en cas d'échec
    $journal->warning('LOGIN_FAIL', ['user' => $login, 'ip' => $_SERVER['REMOTE_ADDR']]);
}

Le formateur JSON place l'identifiant et l'adresse dans des champs séparés, ce qui neutralise au passage les retours à la ligne glissés dans un identifiant. Si l'application est derrière un proxy inverse, REMOTE_ADDR contient l'adresse du proxy : il faut alors lire l'en-tête transmis par le proxy, en ne lui faisant confiance que s'il vient bien du proxy.

Les journaux peuvent aussi aller dans une table de la base de données, ce qui permet de les interroger en SQL. Une table journal minimale :

CREATE TABLE journal (
  id_journal     BIGINT AUTO_INCREMENT PRIMARY KEY,
  date_heure     DATETIME NOT NULL,
  id_utilisateur INT NOT NULL,
  operation      ENUM('select', 'insert', 'update', 'delete') NOT NULL,
  nom_table      VARCHAR(64) NOT NULL,
  ip             VARCHAR(45) NOT NULL  -- 45 caractères : la forme textuelle la plus longue d'une adresse IPv6
);

Le compte de l'application ne doit avoir que le droit INSERT sur cette table, jamais UPDATE ni DELETE : une injection SQL dans l'application ne pourra pas effacer les traces (les droits avec GRANT).

Enfin, le SGBD a ses propres journaux. Le journal général de MySQL (general_log) enregistre toutes les connexions et toutes les requêtes. C'est précieux pour une enquête, mais très coûteux sur un serveur chargé, et il recopie les valeurs des requêtes, données personnelles comprises. Pour un audit durable, on préfère un greffon d'audit (celui de MySQL Enterprise ou server_audit de MariaDB), qui filtre les événements à garder.

À l'E7

La journalisation tombe sous des formes différentes selon l'option.

• SLAM, métropole 2025 (U7), cas Casterman : la mission C2 fournit une méthode Java creerEnregLog qui écrit dans un fichier de traces l'utilisateur, l'opération, la table et la date. On demande d'y ajouter l'adresse IP « en ajoutant tous les éléments nécessaires au respect des bonnes pratiques », puis d'écrire des requêtes SQL de surveillance sur une table Log : le nombre de suppressions des 30 dernières minutes, et le nombre d'ajouts depuis 8 h par utilisateur ayant fait plus de cinq ajouts.
• SLAM, métropole 2026 (U7), cas NDV : la mission A1 porte sur les journaux d'activité du SGBD MySQL, exposés par une vue construite sur la table mysql.general_log : compléter le filtrage en PHP, puis repérer dans les journaux et dans les habilitations qu'un compte applicatif se connecte depuis une autre adresse que le serveur local avec trop de droits, et corriger ces droits.
• SISR, métropole 2026 (U7), cas SPARCLE : la question B1.5 demande deux éléments à prendre en compte pour rendre conforme au RGPD l'archivage des journaux système.
• SLAM, métropole 2022 (alors E6, U6), cas Easy2Drive : le dossier B fait concevoir une base BD_RGPD_LOGS, alimentée par l'application à chaque création ou consultation de données personnelles et interrogée en lecture seule ; dès le dossier A, une question fait justifier la différence de besoin de preuve entre deux récits utilisateurs.

Les réponses attendues reprennent les mots du référentiel et de la CNIL : traçabilité, imputabilité (savoir qui), horodatage, intégrité des journaux, durée de conservation limitée, information des personnes.

Pour aller plus loin. Côté application, la journalisation insuffisante est la neuvième catégorie de l'OWASP Top 10 : voir le chapitre Journalisation (A09) et gestion des erreurs (A10) du cours Sécurité applicative. Les règles de conservation au regard du RGPD sont dans le chapitre RGPD : donnée personnelle, traitement et principes.

Exercices

2026-10-13T09:14:02+02:00 INFO event=LOGIN_OK user=dr.roux ip=10.0.0.42
2026-10-13T09:15:22+02:00 INFO event=DOSSIER_VIEW user=dr.roux ip=10.0.0.42 ressource=patient:P-0421

function creerTrace(int $idUtilisateur, string $operation, string $table): void
{
    $ligne = 'util:' . $idUtilisateur . ';operation:' . $operation
           . ';table:' . $table . ';date:' . date('d/m/Y-H:i:s');
    error_log($ligne . PHP_EOL, 3, '/var/log/appli/traces.log');
}

function creerTrace(int $idUtilisateur, string $operation, string $table, string $ip): void
{
    // Une adresse IP valide ne contient ni espace ni retour à la ligne : on refuse le reste
    if (filter_var($ip, FILTER_VALIDATE_IP) === false) {
        $ip = 'invalide';
    }
    $ligne = 'util:' . $idUtilisateur . ';operation:' . $operation
           . ';table:' . $table . ';ip:' . $ip . ';date:' . date('c');
    error_log($ligne . PHP_EOL, 3, '/var/log/appli/traces.log');
}

SELECT id_utilisateur FROM journal
WHERE nom_table = 'produit' AND operation = 'insert'
  AND date_heure >= CURDATE() + INTERVAL 8 HOUR;

SELECT COUNT(*) AS nb_suppressions
FROM journal
WHERE operation = 'delete'
  AND date_heure >= NOW() - INTERVAL 30 MINUTE;

SELECT id_utilisateur, COUNT(*) AS nb_ajouts
FROM journal
WHERE nom_table = 'produit'
  AND operation = 'insert'
  AND date_heure >= CURDATE() + INTERVAL 8 HOUR
GROUP BY id_utilisateur
HAVING COUNT(*) > 5;