Journaliser les accès sans conserver d'adresse IP en clair

Les journaux d'accès d'un serveur consignent, ligne après ligne, l'adresse de chaque visiteur. Cette information sert au diagnostic, à la détection d'abus et à l'analyse de l'exploration par les moteurs, et elle constitue une donnée personnelle au sens des textes applicables en Europe. Sa conservation prolongée en clair, sans finalité définie ni durée limitée, est une situation courante et rarement examinée. Il existe pourtant plusieurs façons de garder des journaux réellement utiles tout en réduisant fortement ce que l'on conserve. Nous ne sommes pas juristes et cet article n'est pas un avis juridique : il décrit ce que permettent techniquement les différentes méthodes et ce que chacune fait perdre.

Pourquoi l'adresse est une donnée sensible

Le sujet paraît théorique tant qu'on n'a pas mesuré ce qu'une adresse permet de faire. Elle identifie une ligne d'abonnement, donc un foyer ou une entreprise, et se rattache à une personne physique dans un grand nombre de cas. Croisée avec l'horodatage et les pages consultées, elle reconstitue un parcours détaillé. Sur un site abordant des sujets sensibles, santé, opinions, situation financière, ce parcours en dit beaucoup sur la personne. Cette qualification comme donnée personnelle est établie de longue date dans la jurisprudence européenne, ce qui a des conséquences sur la durée de conservation et sur les mesures de protection à mettre en place. Le cadre général de ces obligations est présenté dans notre article sur le RGPD et ce que dit la loi pour être en conformité.

Les journaux ne sont pas la seule source concernée. Les tables applicatives conservant les tentatives de connexion, les enregistrements de commandes, les soumissions de formulaires, les fichiers de cache de sécurité et les sauvegardes contiennent souvent la même information. Traiter les journaux du serveur en oubliant ces autres emplacements ne règle qu'une partie du sujet. Un inventaire des endroits où l'adresse est écrite constitue donc le premier travail, et il réserve régulièrement des surprises. Les extensions de sécurité, en particulier, conservent volontiers des historiques de plusieurs années sans que personne ne l'ait demandé.

Il faut aussi reconnaître que la conservation se justifie dans plusieurs cas. La détection d'attaques, le diagnostic d'incidents, la lutte contre la fraude et certaines obligations de conservation propres à des activités réglementées constituent des finalités reconnues. La question n'est donc pas de tout supprimer mais de déterminer, pour chaque usage, quelle précision et quelle durée sont réellement nécessaires. Poser cette question fait apparaître que la plupart des usages se contentent de beaucoup moins que ce qui est conservé. C'est cette marge qui rend le sujet praticable sans rien perdre d'utile. Une équipe qui découvre qu'elle conservait cinq ans de journaux pour un usage portant sur quarante huit heures accepte généralement la réduction sans discussion.

Le raisonnement se mène usage par usage plutôt que globalement. Détecter une attaque en cours demande une adresse exacte pendant quelques heures. Analyser l'exploration par un moteur ne demande pas d'adresse du tout, un identifiant d'agent suffisant. Mesurer la fréquentation demande de distinguer les visiteurs sans savoir qui ils sont. Répondre à un incident survenu la semaine dernière demande une trace, pas nécessairement une adresse complète. Cette décomposition oriente directement le choix de la méthode, et elle évite le débat stérile entre tout garder et tout jeter. Elle a aussi le mérite de produire une réponse écrite et défendable, ce qui n'est pas le moindre de ses avantages.

Tronquer l'adresse

La troncature consiste à remplacer la fin de l'adresse par des zéros, ce qui la ramène à un réseau plutôt qu'à une ligne. C'est la méthode la plus simple, la plus répandue et celle qui préserve le mieux les usages statistiques. Un dernier groupe de chiffres retiré sur une adresse de quatrième génération laisse un réseau de deux cent cinquante six adresses possibles, ce qui suffit à empêcher l'identification directe dans la plupart des cas. La transformation se fait à l'écriture du journal, avant tout stockage, ce qui est le point essentiel : une donnée jamais écrite ne pose aucune question de conservation. C'est la différence essentielle avec une purge appliquée plus tard, qui laisse subsister la donnée dans les sauvegardes intermédiaires et dans tout ce qui a pu la lire entre temps.

Ce que la troncature préserve mérite d'être détaillé, car c'est ce qui décide de son adoption. La localisation approximative reste possible, à l'échelle d'une région et non d'une ville. La distinction entre visiteurs différents reste largement praticable sur un site de taille moyenne, deux visiteurs du même réseau étant rares. La détection d'une attaque provenant d'une plage réseau reste efficace, celles ci mobilisant en général plusieurs adresses voisines. L'analyse du comportement des robots des moteurs reste intacte, ceux ci se déclarant par leur agent et se vérifiant par résolution de nom. C'est un point important, car l'analyse de l'exploration est l'un des usages les plus fréquents des journaux sur un site professionnel.

Ce qu'elle fait perdre est tout aussi net. Bloquer une adresse précise devient impossible, puisque l'on ne dispose plus que du réseau : bannir le réseau bloquerait des visiteurs légitimes. Distinguer deux abonnés d'un même opérateur derrière une même plage devient impossible également, ce qui gêne l'analyse fine des abus. Enfin, la corrélation avec une réquisition portant sur une adresse exacte n'est plus réalisable, point qui concerne les activités soumises à des obligations particulières. Ces pertes sont acceptables pour un site ordinaire et bloquantes pour certains services. Le seul moyen de trancher consiste à lister les opérations réellement menées sur les journaux au cours des douze derniers mois, exercice qui donne souvent une liste très courte.

Le cas des adresses de sixième génération demande une attention particulière. Leur structure attribue fréquemment un préfixe entier à un seul abonné, ce qui rend une troncature légère parfaitement inefficace. La pratique établie consiste à conserver la moitié de l'adresse, ce qui correspond au préfixe de routage et supprime la partie identifiant la machine. Beaucoup d'implantations appliquent la même règle qu'en quatrième génération, ce qui ne protège rien. C'est un point à vérifier explicitement dans la configuration retenue. Le contrôle est immédiat : il suffit de regarder à quoi ressemble une ligne de journal correspondant à un visiteur en sixième génération et de compter ce qui subsiste.

Hacher plutôt que tronquer

Le hachage transforme l'adresse en une empreinte de longueur fixe, impossible à inverser directement. Il présente un avantage décisif sur la troncature : deux visites de la même adresse produisent la même empreinte, ce qui permet de distinguer les visiteurs avec exactitude sans jamais stocker l'adresse. Le comptage, la détection de répétition et la corrélation entre événements restent donc parfaitement praticables. C'est la méthode à retenir lorsque la distinction fine entre visiteurs compte, ce qui est le cas des dispositifs de sécurité. Elle convient également au comptage de visiteurs uniques, usage pour lequel la troncature produit des chiffres approximatifs difficiles à défendre.

Le hachage simple d'une adresse est cependant peu protecteur, et c'est le point que beaucoup d'implantations ignorent. L'espace des adresses possibles est suffisamment restreint pour qu'un attaquant disposant des empreintes puisse toutes les calculer en quelques heures et retrouver les adresses d'origine. Une empreinte non salée n'apporte donc qu'une protection cosmétique. L'ajout d'un sel secret, chaîne aléatoire concaténée à l'adresse avant hachage, rend ce calcul impraticable tant que le sel reste inconnu. La protection repose alors entièrement sur la confidentialité de ce sel, ce qui déplace le problème vers la gestion des secrets plutôt qu'il ne le supprime.

La rotation du sel constitue le raffinement suivant et elle change la nature de la protection. Changer le sel chaque jour, ou chaque semaine, signifie qu'une même adresse produit une empreinte différente d'une période à l'autre. La corrélation reste possible à l'intérieur d'une période, ce qui couvre les besoins de sécurité, et devient impossible au delà. L'ancien sel doit alors être détruit, sans quoi l'opération perd son sens. Cette méthode offre le meilleur compromis entre utilité opérationnelle et limitation de la conservation, et elle demande simplement un mécanisme de génération et de destruction du sel.

Le stockage du sel demande les mêmes précautions qu'une clé secrète : hors du dépôt de code, hors des sauvegardes accessibles, avec des droits restreints. Un sel présent dans un fichier de configuration versionné annule toute la protection. Les mêmes principes s'appliquent que pour la journalisation applicative, sujet que nous traitons dans notre article sur la manière de journaliser une API sans stocker de données personnelles. La rigueur sur ce point conditionne tout le reste. Un sel compromis rend l'ensemble des empreintes conservées équivalent à des adresses en clair, rétroactivement.

Choisir les durées

La durée de conservation est le levier le plus efficace et le moins coûteux à actionner. Elle se décide usage par usage, en partant de la question suivante : au bout de combien de temps cette information n'a t elle plus aucune utilité opérationnelle. La réponse est généralement beaucoup plus courte que ce qui est pratiqué, la conservation par défaut étant souvent illimitée faute de décision explicite. Fixer une durée et la faire appliquer automatiquement règle une grande partie du sujet sans rien changer aux usages quotidiens. C'est aussi la mesure la plus facile à expliquer et à vérifier, ce qui la rend particulièrement adaptée à un premier chantier.

La détection d'attaque en cours travaille sur des fenêtres de quelques minutes à quelques heures. Le diagnostic d'un incident signalé porte sur les jours précédents. L'analyse de l'exploration par les moteurs s'accommode d'un ou deux mois, et elle ne nécessite pas d'adresse identifiante. L'analyse de tendance de fréquentation se satisfait de données agrégées, sans aucune adresse. Ces quatre usages couvrent la quasi totalité de ce que fait une équipe technique avec ses journaux, et aucun ne réclame une conservation de plusieurs années. Les activités soumises à des obligations spécifiques constituent l'exception, et celles ci sont en général parfaitement identifiées par les personnes concernées.

La mise en œuvre passe par une rotation automatique des fichiers, avec compression puis suppression au delà du délai retenu. Les outils systèmes prévus à cet effet font cela nativement et se configurent en quelques lignes. Le point à vérifier est que les archives compressées soient bien supprimées et non simplement déplacées ailleurs, cas fréquent qui laisse les données en place indéfiniment. Les sauvegardes du serveur doivent également être examinées, puisqu'elles contiennent les journaux de toutes les périodes sauvegardées. C'est l'angle mort le plus courant de ce type de mise en conformité. Une politique de rotation des sauvegardes, avec une durée elle aussi définie, complète donc nécessairement le dispositif.

Les journaux applicatifs et les tables de sécurité relèvent de la même logique et sont rarement traités. Une table de tentatives de connexion accumulant plusieurs millions de lignes depuis cinq ans est un cas de figure classique, sans utilité et avec un coût de sauvegarde réel. Une purge automatique, déclenchée par une tâche planifiée, supprime ce qui dépasse la durée retenue. Cette purge doit être documentée, avec sa durée et sa justification, afin de pouvoir être présentée si la question se pose. Elle sert autant la conformité que la performance de la base. Sur une table de plusieurs millions de lignes, la purge se traduit souvent par un gain de temps visible sur les opérations courantes.

Écrire la politique de journalisation

Les décisions techniques prises jusqu'ici n'ont de valeur que si elles sont écrites et opposables. Une note d'une page suffit et elle sert à trois publics distincts : l'équipe technique qui doit appliquer les règles, la direction qui doit pouvoir répondre à une question, et le successeur qui reprendra le site dans trois ans. Sans ce document, chaque intervention repose sur la mémoire de celui qui a configuré le serveur, ce qui n'est pas une base solide.

Le document doit lister, pour chaque source de journalisation, la finalité poursuivie, la transformation appliquée à l'adresse, la durée de conservation retenue et l'emplacement où les données se trouvent. Cette énumération fait apparaître les emplacements oubliés, ce qui constitue déjà un bénéfice en soi. Elle permet ensuite de vérifier périodiquement que la réalité correspond à ce qui est écrit, contrôle qui prend quelques minutes une fois par an.

Il doit aussi préciser qui a accès à ces journaux et par quel moyen. Un fichier de journal lisible par l'ensemble des comptes du serveur, ou accessible depuis une interface d'administration sans restriction, annule une partie des précautions prises en amont. Les droits sur ces fichiers méritent le même soin que ceux appliqués aux fichiers de configuration contenant des identifiants.

La question de la sous traitance mérite enfin d'être posée. Un hébergeur, un service de diffusion de contenu ou un outil de surveillance externe conservent leurs propres journaux, avec leurs propres durées, sur lesquelles vous n'avez pas la main directe. Les identifier et vérifier ce qu'annoncent leurs conditions fait partie de l'inventaire. Nous ne sommes pas juristes et la qualification de ces relations, comme la rédaction des documents associés, relèvent d'un conseil compétent.

Ce que l'on peut encore faire

La crainte principale, lorsqu'on aborde ce sujet, est de perdre des capacités de diagnostic. Elle est largement infondée pour un site ordinaire, à condition de savoir comment remplacer chaque usage. Le détail mérite d'être examiné, car il constitue l'argument qui emporte l'adhésion des équipes techniques réticentes. Dans la plupart des cas, le remplacement est même plus pratique que l'usage d'origine. Présenter le sujet sous cet angle, plutôt que sous celui de la contrainte réglementaire, change complètement l'accueil qui lui est réservé.

La limitation des tentatives fonctionne parfaitement avec des empreintes salées : on compte les échecs par empreinte et on refuse au delà du seuil, sans jamais connaître l'adresse. Le blocage s'applique alors à l'empreinte, ce qui produit exactement le même effet pour le visiteur concerné. La seule différence tient à ce qu'un administrateur ne peut plus lire l'adresse dans l'interface, ce qui n'a d'utilité que dans de rares cas d'investigation. Les protections au niveau du serveur ou du pare feu continuent par ailleurs de travailler sur l'adresse réelle, en amont, sans la conserver. Cette répartition entre une couche qui voit et ne garde pas, et une couche qui garde sans voir, est le schéma le plus robuste.

L'analyse du comportement des robots ne dépend pas de l'adresse mais de l'agent déclaré et de la résolution inverse du nom, qui se vérifie au moment du passage plutôt que a posteriori. Consigner le résultat de cette vérification, robot authentifié ou non, plutôt que l'adresse elle même, conserve toute l'information utile. Cette approche est même supérieure à la conservation brute, puisqu'elle évite de refaire la vérification lors de chaque analyse. Elle demande un léger travail de configuration au niveau du serveur. Le format de journalisation étant paramétrable, l'ajout d'un champ calculé ne pose aucune difficulté particulière.

Le diagnostic d'un incident signalé par un visiteur se règle par un identifiant de corrélation généré à chaque requête et affiché dans le message d'erreur. La personne communique cet identifiant, qui permet de retrouver la trace exacte sans jamais avoir besoin de son adresse. Ce mécanisme est plus efficace que la recherche par adresse et horodatage, toujours approximative. Il constitue l'un des rares cas où la mesure de protection améliore réellement le travail quotidien, ce qui en fait un bon argument d'adoption. Les équipes de support l'adoptent en général avec enthousiasme, la recherche par identifiant étant infiniment plus rapide que la recherche par recoupement.

Reste la question de la localisation approximative des visiteurs, employée pour adapter la langue ou la devise. Elle se résout au moment de la requête, en déterminant le pays puis en ne conservant que celui ci, l'adresse n'étant jamais écrite. Cette information suffit à tous les usages courants et elle ne présente aucun caractère identifiant. La notion même d'adresse et son fonctionnement sont détaillés dans notre article sur l'adresse IPv4, sa définition et son fonctionnement, ce qui aide à comprendre pourquoi certaines transformations protègent réellement et d'autres pas.