Anonymiser les adresses IP pour faire des statistiques

Je ne sais pas vous, mais moi, j'adore faire des statistiques. Comme les adresses IP sont des données personnelles, pour bien faire, il faut d’abord les anonymiser.

Sans vouloir surveiller ses usagers individuellement, il est toujours utile de pouvoir faire quelques statistiques sur leurs activités. Que ce soit sur un site web pour avoir une idée des contenus qui marchent ou de l’origine des visites. Ou encore dans un SI sur les ressources les plus utilisées, les fichiers accédés,…

Mais pour respecter ses usagers (leurs données personnelles et accessoirement le RGPD) il faut prendre quelques précautions en anonymisant ces données.

Effacer ce qui est reconnaissable. FotografieLink @ pixabay
Effacer ce qui est reconnaissable. FotografieLink @ pixabay

Aujourd’hui, et pour faire suite à la récupération des logs d’accès aux serveurs web, je vous propose une méthode très simple pour anonymiser les adresses IP présentes dans vos journaux.

Si vous ne voulez pas vous prendre la tête sur le pourquoi du comment, deux règles sed suffisent pour ne garder que les deux premiers nombres des adresses IPv4 et les 3 premiers groupes des IPv6.

Les contraintes

Vous pourriez faire preuve de bon sens et anonymiser vos données dans votre coin mais comme il y a des contraintes légales et réglementaires, ça vaut la peine d’y jeter un œil avant, ce serait dommage de ne pas être conforme.

Avant toute chose, il faut comprendre que le RGPD, dans la suite des lois qui l’ont précédé, ne pose pas l’anonymisation comme un moyen de sortir de son périmètre mais comme une contrainte qui s’applique pour certains traitements.

Acquisition des données. Vous devez donc avoir une base légale pour collecter les données. Soit vous avez demandé le consentement libre et éclairé à vos utilisateurs, soit vous avez une obligation légale de détenir ces données. C’est à vous de voir et ça sort du sujet du jours.

Dans notre cas, OVH a l’obligation de construire ces journaux d’accès et nous avons un intérêt légitime à accéder aux journaux de la veille pour diagnostiquer et corriger des problèmes.

Compatibilité avec le traitement initial. Si les données n’ont pas reçu un consentement pour un traitement, il faut envisager sa compatibilité avec celui pour lequel les utilisateurs ont consenti.

Dans notre cas, l’Union Européenne l’a déjà prévu avec un paragraphe spécifique qui dit que les statistiques ne sont pas incompatibles avec les finalités initiales (Paragraphe 1.b de l’article 5).

Anonymisation. On a donc le droit d’utiliser nos données pour des statistiques, mais tout en respectant certaines contraintes. L’article est un peu plus long mais pour ce qui nous occupe aujourd’hui, c’est la phrase suivante qui va nous guider :

Chaque fois que ces finalités peuvent être atteintes par un traitement ultérieur ne permettant pas ou plus l'identification des personnes concernées, il convient de procéder de cette manière.

Paragraphe 1 de l’article 89

Nous allons donc devoir éviter toute identification des personnes concernées. Comme vous l’aviez anticipé, l’anonymisation répond donc à ce besoin.

TheDigitalArtist @ pixabay
TheDigitalArtist @ pixabay

Critères d’anonymisation. Pour garantir que les utilisateurs ne soit plus identifiables, on n’anonymise pas des données n’importe comment. Le G29 (les CNIL européennes) a déjà planché sur le sujet et fourni un avis contenant les trois critères suivants :

  1. L’individualisation : est-il toujours possible d’isoler un individu ?
  2. La corrélation : est-il possible de relier entre eux des ensembles de données distincts concernant un même individu ?
  3. L’inférence : peut-on déduire de l’information sur un individu ?

Si vous respectez ces trois critères, c’est anonyme et on vous laisse tranquille. Si un seul manque à l’appel, il faudra faire une analyse détaillée des risques de ré-identification.

Ma solution

Avec toutes ces contraintes en tête, on peut avancer ; on a le droit d’utiliser nos journaux pour faire des statistiques mais il faut anonymiser toutes les données personnelles. Dans notre cas, les adresses IP (puisque ce sont les seules données personnelles présentes).

IP version 4

Les adresses IP version 4 étant largement utilisées, il y a déjà des guides officiels, dont l’interprétation suivante de la CNIL :

L’adresse IP permettant de géolocaliser l’internaute ne doit pas être plus précise que l’échelle de la ville. Concrètement les deux derniers octets [soit 16 bits sur les 32] de l’adresse IP doivent être supprimés.

La CNIL, solution pour les cookies de mesure d’audience

Si vous avez suivi mes derniers articles sur la géolocalisation des adresses IP (la théorie et la pratique), vous vous êtes rendu compte qu’avec la pénurie des adresses IP, les Registre Internet Régionaux se sont mis à allouer des réseaux de plus en plus petits. Les records étant de 1024 adresses, soit un préfixe de 22 bits, 6 de plus que les 16 autorisés par la CNIL…

Si vous souhaitez géolocaliser au niveau du pays, vous devriez peut être le faire avant d’anonymiser les adresses IP au risque de perdre dans la précision géographique.

Pour revenir à notre cas voici une commande sed pour anonymiser les adresses IP version 4 dans les journaux d’accès web.

sed -r -e "s/^(([0-9]+\.){2})[^ ]+ /\10.1 /"

En gros, je cherche dès le début de ligne avec ^, et je capture les deux premiers nombres de l’adresse IP avec (([0-9]+\.){2}). Je laisse ensuite tomber tout ce qui suit jusqu’au premier espace [^ ]+ (qui délimite les champs dans les logs d’accès). Le remplacement reprend les deux premiers nombres avec \1 puis je rajoute 0.1 pour remplacer les octets supprimés.

IP version 6

Tout le monde a tellement freiné pour migrer à IPv6 qu’on fini toujours pas l’oublier. Tant et si bien que la CNIL n’a pas donné de critère concret sur la question.

Je me suis donc tourné vers la RFC2374 qui explique comment sont devraient être découpées et allouées les adresses IP version 6. Il est ainsi prévu que les RIR allouent des préfixes de 48 bits pour les ASN et que ceux-ci utilisent les 16 derniers bits, comme ils veulent, pour identifier leurs points d’accès.

Notez que, je ne sais pour quelle raison, certaines allocations dans les fichiers de délégation sont faite avec 64 bits, 16 de plus que les 48 préconisés.

On peut donc se restreindre aux 48 premiers bits (soit 6 octets, donc trois groupes de 4 caractères hexadécimaux). On perdra un peu en précision pour les cas limites mais ça sera compatible avec la précision d’une ville. Si la précision est importante pour vous, géolocalisez avant d’anonymiser.

Voici donc la règle sed pour ces adresses. Les options sont les mêmes que précédemment.

sed -r -e "s/^(([^:]{1,4}:){1,3})[^ ]+ /\1:1 /"

Je commence dès le début de ligne avec ^ puis je capture au maximum trois groupes hexadécimaux avec (([^:]{1,4}:){1,3}) et laisse tomber le reste jusqu’au prochain espace avec [^ ]+. Lors du remplacement, je garde le préfixe avec \1 et pour avoir une adresse valide, je lui donne la première du bloc avec :1.

Un script

Pour terminer, l’idéal est encore d’encapsuler cette méthode d’anonymisation dans un script. On peut alors oublier comment il fonctionne et s’en servir pour anonymiser des fichiers (ce sera opaque).

Ici, je n’ai pas cherché à faire bien compliqué, chaque fichier passé en argument est passé à la moulinette du sed qui va anonymiser les adresses IP version 4 et 6.

Notez que comme on remplacer par une adresse syntaxiquement valide, on peut passer le script autant de fois qu’on veut sur les fichiers. Dès la deuxième, ça ne changera plus, mais ça a un côté rassurant : si on ne sait plus si un fichier est déjà anonymisé, on peut toujours relancer le script, au pire, ça ne changera rien.

#!/bin/sh

for i in $@; do
    echo "-- Anonymize - $i"
    sed -i -r \
        -e "s/^(([0-9]+\.){2})[^ ]+ /\10.1 /" \
        -e "s/^(([^:]{1,4}:){1,3})[^ ]+ /\1:1 /"  \
        "$i"
done

Il ne reste plus qu’à ajouter un appel à ce script après la récupération de vos fichiers de logs.

Et après ?

Reste à vérifier que cette méthode répond aux contraintes d’anonymisation du G29.

L’individualisation. Comme chaque préfixe gardé englobe \(2^{16}\) adresses possibles, il n’est pas possible d’isoler l’activité d’un utilisateur dont ont connaît l’adresse IP à partir des journaux anonymisés.

La corrélation. Il reste possible d’isoler des visites en termes de requêtes très proches temporellement et éventuellement reliées à l’aide de l’en-tête REFERER (par exemple, un accès à une page, puis la récupération du CSS et des images, et parfois un rebond vers une autre page du site et ainsi de suite). Au delà de cette notion de visite, il n’est pas possible de suivre l’activité d’un utilisateur car rien ne permet de déterminer que les visites suivantes proviennent du même utilisateur et non d’un de ses \(2^{16} - 1\) voisins.

L’inférence. Sachant qu’un utilisateur est venu un jours, mis à part s’il est le seul de la journée, il n’est pas possible d’isoler ses visites de celles de ses voisins.

Les trois critères n’étant pas complètement rempli, le risque de re-identification doit être analysé :

Si vous connaissez l’adresse IP d’un utilisateur et savez déjà qu’il est venu dans une période assez courte pour être le seul de son voisinage, vous pouvez savoir ce qu’il a vu.

Ça fait beaucoup d’hypothèses difficilement réalisables : soit vous avez accès à son système informatique, soit vous avez accès à ses requêtes DNS. Dans les deux cas, et si ces accès sont légaux, c’est qu’il s’agit d’une enquête judiciaire et vous avez déjà accès aux journaux non anonymisés 😉.