La journalisation des événements de sécurité permet de détecter des anomalies et de reconstituer un incident. Le guide ANSSI de référence pour l’architecture d’un système de journalisation a été publié le 28 janvier 2022. La politique précise les sources, les événements, l’horodatage, l’accès, l’intégrité et la durée adaptée à chaque usage. Guide ANSSI.
La CNIL recommande généralement une période glissante de six mois à un an, avec une analyse des situations justifiant une adaptation. Il ne s’agit ni d’une durée universelle inscrite dans le RGPD ni d’une obligation générale d’acheter un SIEM. CNIL : tracer les opérations.
Ce guide s’adresse au RSSI ou au DSI qui doit arbitrer entre ce qu’il faut journaliser, ce qu’il ne faut surtout pas journaliser, et combien de temps conserver le reste. Il croise les recommandations de l’ANSSI, la position de la CNIL sur les durées, et les conséquences RGPD d’un dispositif de traçabilité — car les journaux constituent eux-mêmes un traitement de données personnelles. La politique de journalisation n’a de sens qu’adossée à une PSSI qui fixe les responsabilités et à une cartographie du système d’information qui identifie les sources à couvrir.
Points clés
- Identifiez les événements utiles et les données à exclure avant de collecter.
- Protégez les journaux contre les accès et modifications non autorisés.
- Vérifiez toute la chaîne : émission, collecte, analyse et prise en charge de l’alerte.
- Justifiez la conservation et vérifiez la purge des copies et exportations.
- Prévoyez les responsabilités et la continuité du dispositif pendant un incident.
1. Cadre juridique de la journalisation
L’article 32 du RGPD impose des mesures de sécurité appropriées au risque. La journalisation peut contribuer à cette obligation, mais ses propres données doivent respecter les principes de finalité, minimisation, conservation et transparence. Les exigences sectorielles doivent être identifiées séparément dans votre périmètre ; un numéro d’article consacré à un autre sujet ne suffit pas à justifier une durée.
2. Référence ANSSI et guides spécialisés
Le guide d’architecture ANSSI de janvier 2022 décrit les prérequis et la conception d’un système de journalisation, avec des annexes sur les événements, les architectures et la détection. Il se distingue des guides spécialisés pour un environnement technique. Lorsqu’une recommandation Windows ou Active Directory est utilisée, consignez son titre, sa version et les catégories d’audit effectivement activées. Ne mélangez pas l’identifiant d’un guide avec le contenu d’un autre.
3. Événements à journaliser : la liste minimale
Pour préparer votre collecte, examinez notamment ces six familles opérationnelles :
- Authentification : succès, échec, déverrouillage, changement mot de passe
- Autorisation : accès refusé, élévation de privilèges, sudo
- Administration : création/suppression compte, modification droits, GPO
- Configuration système : modification de politique, désactivation antivirus
- Réseau : flux refusés (firewall), connexions VPN, requêtes DNS suspectes
- Application : accès aux données sensibles, exports massifs, requêtes SQL anormales
Pour Active Directory, sélectionnez les événements selon les scénarios et la documentation de la version utilisée. Vérifiez leur émission effective : une liste d’identifiants ne suffit pas si la catégorie d’audit correspondante est désactivée.
Pour chaque événement, cinq attributs constituent un point de départ à compléter selon le scénario : l’horodatage avec fuseau, l’identifiant de la source (machine, service, adresse), l’identité de l’acteur, l’action tentée, et le résultat (succès ou échec). Un journal qui n’enregistre que les succès est aveugle exactement là où l’attaquant se manifeste d’abord : dans la séquence d’échecs qui précède la compromission.
Ce qu’il ne faut jamais journaliser
C’est la moitié manquante de toutes les politiques de journalisation, et la source d’un contentieux fréquent : un journal trop bavard transforme une mesure de sécurité en manquement au RGPD. Le principe de minimisation de l’article 5 §1 c) s’applique aux journaux comme au reste.
| À proscrire dans les journaux | Pourquoi | Que faire à la place |
|---|---|---|
| Mots de passe, même erronés | Les utilisateurs se trompent de champ : le journal capture le mot de passe en clair | Journaliser l’événement d’échec, jamais le secret saisi |
| Jetons de session, clés d’API, secrets | Un journal compromis devient un accès valide | Empreinte tronquée ou identifiant de jeton |
| Numéros de carte bancaire, cryptogrammes | Risque de divulgation de données de paiement sans nécessité pour tracer un accès | Utiliser une référence technique ; vérifier séparément les exigences de paiement applicables |
| Contenu des communications (messages, pièces jointes) | Peut divulguer du contenu sans nécessité pour tracer un accès | Métadonnées : qui, quand, quel objet, quel volume |
| Données sensibles de l’article 9 issues des champs métier | Un log applicatif recopiant un dossier médical crée un second traitement de santé | Identifiant technique de l’enregistrement consulté |
| Corps complet des requêtes SQL ou HTTP en production | Réplique la base dans les journaux | Requête normalisée, sans les valeurs |
La règle opérationnelle tient en une phrase : un journal doit permettre de reconstituer qui a fait quoi, jamais de reconstituer les données elles-mêmes. Cette distinction est aussi ce qui rend un dispositif de traçabilité acceptable vis-à-vis des représentants du personnel : on trace les accès, pas le contenu du travail.
4. Centralisation : choisir une architecture exploitable
Un collecteur central, une plateforme d’analyse ou un service opéré peuvent répondre à des besoins différents. Comparez les sources supportées, la recherche, les droits, la protection des flux, les délais d’alerte et la réversibilité. Le nombre de postes ne suffit pas à imposer un produit ou une gamme de prix. Demandez une démonstration avec un événement représentatif et son traitement jusqu’à la personne d’astreinte.
5. Horodatage et qualité des événements
Utilisez une référence temporelle maîtrisée et cohérente entre les sources et les collecteurs. Vérifiez le fuseau, la dérive, les changements d’heure et le comportement en cas d’indisponibilité du service de temps. Deux événements correctement collectés mais datés de manière incohérente peuvent conduire à reconstruire une mauvaise chronologie. Le choix technique doit être adapté à l’architecture et aux menaces.
6. Intégrité et accès aux journaux
Protégez les journaux contre l’effacement, l’altération et l’accès injustifié. Selon le risque, cela peut inclure la centralisation dans une zone séparée, des contrôles d’accès, des mécanismes d’intégrité et un stockage empêchant certaines modifications. Aucune combinaison technique ne garantit à elle seule l’admissibilité ou la force probante en justice : le contexte de collecte, la procédure et les règles applicables comptent également.
La séparation des rôles est la mesure la moins coûteuse et la plus souvent absente. Un administrateur système qui peut effacer les journaux du serveur qu’il administre annule à lui seul l’intérêt du dispositif : plus rien ne prouve ce qui s’est passé, et la traçabilité ne vaut que ce que vaut la loyauté du dernier administrateur. Le modèle cible tient en trois règles. Un, la collecte pousse les événements vers un collecteur distinct, dans une zone réseau que les systèmes journalisés ne peuvent pas atteindre en écriture au-delà du flux de journalisation lui-même. Deux, les droits sur la plateforme de journalisation sont détenus par une équipe différente de celle qui exploite les systèmes surveillés — en pratique le SOC ou la fonction sécurité, pas la production. Trois, les accès aux journaux sont eux-mêmes journalisés, sur un support que leurs détenteurs ne contrôlent pas.
Ajoutez-y une purge automatique à échéance : la sécurité des journaux ne consiste pas seulement à empêcher leur modification, elle consiste aussi à garantir leur disparition à la date prévue. Une conservation indéfinie « par oubli » est un manquement, même quand elle résulte d’une bonne intention. Les mêmes exigences de disponibilité s’appliquent d’ailleurs aux journaux qu’au reste du système : leur restauration doit être testée dans le cadre du plan de continuité d’activité, faute de quoi l’investigation post-incident se fera sans eux.
7. Rétention : combien de temps conserver ?
La CNIL recommande généralement six mois à un an pour les événements visés par sa fiche de sécurité. La durée doit être adaptée lorsqu’une obligation légale, une finalité spécifique ou un besoin documenté l’exige. La recommandation détaillée de la CNIL présente les situations à analyser. Ne convertissez pas une hypothèse d’exploitation en « durée NIS 2 » universelle.
| Situation | Décision à documenter |
|---|---|
| Traçabilité générale des accès | Durée retenue dans le contexte et justification de toute adaptation |
| Données sources conservées peu longtemps | Références minimales dans les journaux pour éviter de recopier les données expirées |
| Incident ou contentieux identifié | Extraction limitée, accès restreint, motif et date de réexamen |
| Contrôle interne spécifique | Finalité, risques et procédures d’analyse soutenant la durée choisie |
| Statistiques réellement anonymes | Vérification de l’anonymisation avant de conclure à la sortie du champ des données personnelles |
Une investigation ne justifie pas une conservation « indéfinie » de tous les journaux. Délimitez les sources, dates et événements utiles, puis réexaminez les copies de travail. Vérifiez également les exportations et sauvegardes : la durée de conservation annoncée doit correspondre à ce qui reste effectivement accessible.
Une organisation peut séparer un stockage rapidement consultable et une archive moins accessible, si cela répond à son besoin. Les durées de chaque niveau, les permissions et la restauration doivent être décrites. Contrôlez la date du plus ancien événement et le traitement des erreurs de purge, plutôt que de vous contenter de la présence d’une tâche automatique.
8. Logs et RGPD : protéger ce que vous collectez
Les logs contiennent des données personnelles (login, IP, horodatage). À ce titre :
- Mention dans le registre des traitements (RGPD art. 30)
- Information des utilisateurs (charte informatique, RH)
- Accès restreint (RSSI, SOC, audit)
- Durée de conservation justifiée dans la politique
- Sécurité renforcée (chiffrement, WORM)
Le point le plus souvent oublié est la base légale. Un dispositif de journalisation repose en général sur l’intérêt légitime de l’article 6 §1 f) — assurer la sécurité du système d’information — ou sur l’obligation légale lorsqu’un texte sectoriel l’impose. Le consentement est souvent inadapté à la relation de travail lorsque le salarié ne dispose pas d’une liberté de choix réelle. L’intérêt légitime suppose un test de mise en balance écrit, qui documente précisément ce qui rend le dispositif proportionné : périmètre limité aux événements de sécurité, absence de contenu, durée bornée, accès restreint, absence d’usage disciplinaire hors procédure.
Deux conséquences pratiques en découlent. D’une part, l’information des personnes doit être spécifique : une ligne dans la charte informatique décrivant les événements journalisés, la durée et les destinataires, plus l’information-consultation du CSE au titre de l’article L. 2312-38 du code du travail avant la mise en place de tout moyen permettant un contrôle de l’activité. L’information des salariés et les obligations de consultation doivent être examinées indépendamment de la qualité technique des traces ; la recevabilité d’une preuve ne se déduit pas automatiquement de cette seule caractéristique. D’autre part, les journaux relèvent du droit d’accès : une personne peut demander les traces la concernant, et l’organisation doit pouvoir extraire ces traces sans divulguer celles des autres. C’est un argument de plus en faveur d’une indexation propre plutôt que d’un stockage en vrac.
La journalisation ne doit pas être réutilisée pour surveiller la productivité ou reconstruire le contenu du travail sans analyse distincte. La collecte excessive et l’absence de traces utiles créent des risques différents : documentez les scénarios, les finalités et les garanties au lieu de rechercher une quantité maximale d’événements.
9. Organisation humaine de l’analyse
Définissez qui examine les alertes, dans quel délai opérationnel et avec quel remplacement en cas d’absence. La couverture dépend des risques et des engagements applicables ; il n’existe pas un effectif universel de quatre ou douze personnes pour toute organisation. Si vous externalisez, distinguez détection, supervision et réponse à incident et vérifiez le périmètre exact du service contracté.
10. Détection : règles SIEM essentielles
Top 10 des règles à implémenter en priorité :
- Multiples échecs d’authentification (brute force)
- Connexion depuis pays inhabituel (geo-velocity)
- Élévation de privilèges
- Création de compte admin
- Désactivation antivirus / EDR
- Export inhabituel au regard des volumes et usages autorisés
- Requête DNS vers domaine malveillant (threat intel)
- Connexion VPN hors horaire
- PowerShell encodé / obfusqué
- Accès massif aux fichiers (signature ransomware)
Passer d’un événement collecté à une alerte prise en charge
Pour chaque cas d’usage retenu, le RSSI et l’exploitation peuvent préparer une fiche courte : source attendue, événement recherché, règle de détection, destinataire de l’alerte, première vérification et décision d’escalade. Indiquez aussi qui reprend la demande si le destinataire est absent. Cela permet de suivre le chemin complet entre l’application surveillée et la personne chargée d’agir.
Dans un exemple fictif, une application envoie les échecs de connexion au collecteur, mais l’alerte aboutit dans une boîte que personne ne consulte. La collecte fonctionne ; la prise en charge reste à organiser. Sur un compte de démonstration et dans un créneau convenu, l’équipe vérifie successivement la présence de l’événement à la source, sa réception centrale, le déclenchement de la règle et l’accusé de prise en charge. Elle ne copie ni mot de passe ni contenu métier dans le compte rendu.
Conservez la référence de l’événement utilisé, les heures observées à chaque étape, le nom du responsable et la correction décidée. Si les horloges divergent ou si un champ manque, l’écart doit pouvoir être attribué à une étape précise. Un essai de collecte réussi ne valide pas à lui seul la pertinence de toutes les règles : les faux positifs et les situations non détectées restent à examiner avec les analystes.
Pour les événements d’authentification, rapprochez cette fiche de la politique de mots de passe et d’authentification. Pour une alerte confirmée, précisez le relais vers la gestion de crise cyber. Ces deux liens donnent à l’analyste le contexte de l’accès et le contact à mobiliser après sa première analyse.
11. Dossier de preuve et contrôle périodique
La politique doit indiquer les événements collectés, leurs finalités, leurs durées et leurs destinataires. Ajoutez les résultats des vérifications, les incidents de collecte et les corrections. Une politique signée ne supprime pas le risque si les sources ne remontent plus ou si personne ne traite les alertes. Pour préparer un contrôle, sélectionnez un événement et reconstruisez son parcours sans divulguer le contenu métier.
12. Erreurs fréquentes en audit
- Journaux uniquement locaux, sans protection adaptée contre l’effacement.
- Horloges divergentes ou champs insuffisants pour relier les événements.
- Conservation choisie sans justification ou purge qui ignore les exportations.
- Alertes sans destinataire, remplaçant ou consigne d’escalade.
- Données et secrets copiés dans les traces sans nécessité.
- Absence de vérification de l’efficacité des règles et des mesures correctives.
FAQ
Quelle durée minimale de conservation des logs ?
La référence générale de la CNIL est une période de six mois à un an, avec adaptation documentée selon les situations décrites dans ses recommandations. Il n’existe pas de tableau universel imposant trois ans pour tout compte administrateur ou cinq ans pour tout journal. Vérifiez la finalité et le texte spécifique éventuellement applicable. CNIL.
Un SIEM est-il obligatoire ?
Une obligation de sécurité ou de gestion des incidents ne permet pas, à elle seule, de conclure qu’un produit nommé SIEM doit être acheté. Évaluez les fonctions nécessaires, les moyens et les exigences applicables. Un outil sans analyste ni procédure ne démontre pas une capacité de traitement des alertes.
Comment protéger les journaux ?
Traitez ensemble confidentialité, intégrité et disponibilité : flux et stockages protégés, droits limités, prévention de l’altération, supervision de la collecte et restauration vérifiée. Choisissez les mesures selon les risques ; aucune ne doit être présentée comme garantissant à elle seule la conformité ou une preuve judiciaire incontestable.