Le 21 octobre, au moment où PHP2Shell est devenu public, l'équipe de threat intelligence d'Amazon a publié une ligne que tout incident responder aurait dû lire deux fois : investiguer à partir du 17 octobre au moins. Quatre jours avant la divulgation.
Voici donc une question pour votre équipe. Avez-vous encore vos logs de serveur web du 17 octobre ?
S'ils tournent tous les sept jours, la réponse honnête à « avons-nous été touchés avant que quiconque le sache ? » est « nous ne le saurons jamais ».
Demandez maintenant à votre DPO combien de temps vous devez conserver ces logs. Réponse différente. Ils regorgent d'adresses IP, d'identifiants utilisateurs, de données de session, parfois de corps de requêtes entiers. Des données personnelles, conservées à des fins de sécurité que personne n'a écrites, pour une durée que personne n'a choisie.
Mêmes logs, deux personnes, deux craintes. Les deux légitimes.
Deux dogmes à la même table
Le dogme sécurité : tout logger, conserver indéfiniment, le stockage est bon marché et on ne sait jamais. Il vient d'une blessure réelle. Tout incident responder a déjà buté sur l'impasse où la piste s'arrête parce que les logs ont été écrasés la semaine précédente.
Le dogme vie privée : logger le moins possible, le moins longtemps possible. Une blessure réelle également. Un entrepôt de logs qui conserve tout sur tout le monde indéfiniment devient une base de données de surveillance, et l'une des cibles les plus attractives de l'entreprise. La CNIL a nommé exactement ce risque dans ses propres recommandations : des volumes de données de logs suffisamment importants pour être attaqués ou utilisés à des fins que personne n'avait prévues.
Chaque camp a raison sur son propre risque. Aucun ne fonctionne comme règle par défaut. « Indéfiniment » n'est pas une durée de conservation, et « le moins longtemps possible » n'en est pas une non plus.
Anecdote : En pratique, il y a rarement un second interlocuteur à cette table. Dans les audits ISO 27001 que je conduis, le DPO n'est presque jamais consulté sur la journalisation. Cela me surprend à chaque fois, et c'est l'une des non-conformités mineures que je soulève le plus souvent. L'équipe sécurité fixe une durée de conservation, l'outil l'applique, et la personne dont c'est le rôle de demander « pourquoi conservons-nous ceci ? » l'apprend lors de l'audit. L'article 38 du GDPR exige déjà que le DPO soit associé, de manière appropriée et en temps utile, à toute question relative aux données personnelles. Les logs en font partie.
Ce que les textes disent réellement
Voici ce qui sort de l'impasse. Aucune réglementation ne vous donne un chiffre universel. Et toutes vous demandent la même chose.
GDPR exige la minimisation des données et la limitation de la conservation. Il impose également une sécurité appropriée au titre de l'article 32, et le considérant 49 reconnaît que le traitement strictement nécessaire et proportionné à des fins de sécurité des réseaux et des systèmes d'information constitue un intérêt légitime. La journalisation est donc licite. C'est la journalisation sans finalité définie qui pose problème.
La recommandation de la CNIL de 2021, l'un des documents de guidance réglementaire les plus détaillés sur le sujet, préconise de six mois à un an pour les logs applicatifs qui tracent qui a accédé à quoi et qui a modifié quoi. Une durée plus longue est possible avec une justification, jusqu'à trois ans dans les cas courants. Lorsque les données sous-jacentes sont conservées moins de six mois, les logs ne doivent pas emporter ces données personnelles. Et la recommandation exclut explicitement de son périmètre les logs de périmètre, issus des pare-feux et des équipements réseau. Presque tous ceux qui citent « six mois » manquent cette précision.
Le règlement d'exécution NIS2 2024/2690, pour les fournisseurs d'infrastructures et de services numériques qu'il couvre, impose une liste des actifs à journaliser fondée sur les risques, un examen régulier, une protection contre la falsification et une conservation pour une durée prédéfinie. Aucun minimum n'est fixé. Le guide de mise en œuvre de l'ENISA ajoute ensuite deux lignes : supprimer à l'expiration de la durée de conservation, et ne pas conserver dans les logs des données dont la propre durée de conservation a expiré.
Relisez. Le régulateur sécurité dit ce que dit le régulateur vie privée.
L'AI Act fixe un plancher plutôt qu'un plafond. Les déployeurs de systèmes à haut risque devront conserver les logs générés par ces systèmes pendant au moins six mois.
PCI DSS exige douze mois d'historique, dont trois immédiatement disponibles. Un chiffre contractuel, pas légal.
Cinq sources, cinq réponses, une exigence commune : une durée définie, rattachée à une finalité, écrite noir sur blanc.
Décider par finalité
L'erreur habituelle consiste à fixer la conservation par outil. « Le SIEM conserve 90 jours » est une décision de licence déguisée en décision sécurité.
Fixez-la par finalité.
La détection nécessite des données récentes et interrogeables. Quelques semaines, conservées à chaud.
L'investigation nécessite suffisamment d'historique pour couvrir le délai réaliste de détection d'une compromission, plus la fenêtre de pré-divulgation que PHP2Shell vient de démontrer. Une détection lente implique une conservation longue. C'est le compromis honnête.
La traçabilité des accès privilégiés nécessite une piste plus longue, car « qui a fait ça, et en avait-il le droit ? » surgit généralement des mois après.
Les obligations légales et contractuelles fixent leur propre plancher. Vous les respectez.
Un même log peut servir plusieurs finalités. Sa durée de conservation est fixée par la finalité la plus exigeante que vous pouvez réellement justifier, et non par celle que vous souhaiteriez avoir.
Trois leviers qui dissolvent la plupart des conflits
La conservation est un curseur. La plupart des désaccords disparaissent dès lors que vous actionnez les deux autres.
Le contenu. Loggez l'événement, laissez la donnée de côté. Qui, quelle action, quand, quelle référence d'enregistrement. Omettez l'enregistrement lui-même, le corps de la requête, le champ de formulaire dans lequel quelqu'un a tapé un mot de passe par erreur. Les logs verbeux et de débogage sont là où les données personnelles s'infiltrent dans des endroits que personne ne gouverne ; donnez-leur une durée de vie de quelques jours.
Les niveaux. Un niveau chaud court pour la détection. Un niveau froid plus long pour l'investigation, chiffré et à accès restreint. Une archive étroite pour les pistes dont vous avez justifié la conservation sur plusieurs années. À chaque niveau inférieur, moins de personnes peuvent y accéder.
Les accès. Votre entrepôt de logs est probablement le registre le plus complet des activités personnelles dans l'entreprise. Traitez-le comme tel. Des rôles nommés, des accès aux logs eux-mêmes tracés, et des administrateurs qui ne peuvent pas discrètement effacer leur propre trace.
Et un garde-fou. Un log de sécurité est collecté à des fins de sécurité. Le jour où il est extrait dans le cadre d'un litige RH sans base légale distincte ni transparence appropriée, vous avez changé sa finalité, et dans plusieurs pays vous avez également fait entrer le comité d'entreprise dans la pièce.
Un exemple de tableau de conservation
Adaptez-le à votre analyse de risques et à votre droit national. C'est un point de départ, et il illustre le raisonnement que vous devrez documenter.
| Type de log | Finalité | Conservation indicative | Justification |
|---|---|---|---|
| Pare-feu, proxy, DNS, VPN | Détection, investigation | 12 mois, 90 jours à chaud | Couvre les fenêtres de détection tardive et d'exploitation en pré-divulgation |
| Authentification (SSO, annuaire, MFA) | Détection, investigation de compromission | 12 mois | Une compromission de compte s'annonce rarement dès le premier jour |
| Actions privilégiées et administratives | Traçabilité, contrôle interne | Jusqu'à 3 ans, accès restreint | Besoin de contrôle interne documenté, dans la limite haute fixée par la CNIL |
| Accès applicatifs aux données personnelles | Traçabilité | 6 à 12 mois | Plage de référence CNIL |
| Applications traitant des données à durée de vie courte | Traçabilité | 6 à 12 mois, sans les données personnelles elles-mêmes | Les logs ne doivent pas survivre aux données qu'ils décrivent |
| Logs applicatifs de débogage et verbeux | Résolution d'incidents | Jours à semaines | Aucune finalité au-delà de la correction du bug |
| Environnement cartes de paiement | PCI DSS | 12 mois, 3 en ligne | Exigence contractuelle |
Documenter la décision
Sur le point A.8.15, l'auditeur vous demandera combien de temps vous conservez vos logs. Les meilleurs demandent ensuite pourquoi.
La réponse doit exister avant la question. Une politique de journalisation avec le tableau de conservation et ses justifications. Une analyse d'intérêt légitime pour la journalisation elle-même. La journalisation inscrite dans votre registre des activités de traitement, parce que c'en est une. L'avis du DPO versé au dossier. Un responsable nommé. Une date de révision.
Cet ensemble de documents est ce qui transforme un dogme en décision. La sécurité obtient la piste dont elle a besoin. La vie privée obtient une finalité, une limite et une date de suppression. Et lorsque quelqu'un conteste l'un ou l'autre côté, il y a une signature en bas de page.
Pour conclure
Le débat entre « tout conserver » et « ne rien conserver » se termine généralement au profit de celui qui argumente le plus fort, et la durée de conservation finit par être celle que l'outil appliquait par défaut.
Aucun des deux régimes ne vous laisse vous en sortir aussi facilement. Tous deux veulent voir que quelqu'un a examiné la finalité, choisi un chiffre et écrit pourquoi.
Cela prend une après-midi. Cela vous évite deux conversations : expliquer à un cabinet de réponse à incident que les logs dont vous aviez besoin ont été supprimés par défaut, et expliquer à une autorité de protection des données pourquoi vous avez conservé sept ans de tout.
Ces deux dimensions figurent dans deux de nos formations. ISO 27001 Lead Implementer couvre la journalisation et la surveillance en tant que contrôles que vous pouvez démontrer en audit. ISO 27701 Lead Implementer couvre le volet vie privée : finalité, conservation et les documents qui les justifient.