Opinion | Mobiliser les développeurs pour protéger les données personnelles

Le Règlement général pour la protection des données (RGPD) vient de fêter ses deux ans en mai. Les initiatives publiques et privées visant à protéger les données personnelles sont nombreuses. La Dinum (direction interministérielle du numérique) a par exemple publié début juin un outil open source utilisant une intelligence artificielle pour pseudonymiser les documents des administrations.

La pseudonymisation, un outil limité

Côté entreprises, certaines se disaient prêtes dès les débuts de l’application du règlement pour en respecter les principes, d’autres se sont vues infliger de lourdes amendes, et pour beaucoup, la prise en compte de la donnée personnelle a engendré de nombreuses difficultés dans la mise en œuvre de flux de pseudonymisation et d’anonymisation.

Le RGPD définit des droits, des principes et des degrés de gravité. Parmi les incidents liés à la gestion et au traitement des données, la fuite de données personnelles est le plus grave. La raison en est qu’il prive les individus concernés de leur droit à l’oubli. Une fois sur Internet, les données personnelles ne peuvent plus être effacées. Une fuite de données va au-delà du non-respect du droit à l’oubli : elle l’annihile purement et simplement. L’individu n’est plus en mesure d’exercer son droit, car la donnée a échappé à tout contrôle.

Pour pallier ce risque, le RGPD aborde le concept de pseudonymisation. S’il s’agit effectivement d’une mesure de protection (via des techniques comme le chiffrement ou le hachage), le problème est qu’une clé peut permettre de reconstruire les données. Or si des données pseudonymisées peuvent être reconstruites, elles redeviennent des données personnelles.

Une prise en compte de la vie privée dès la conception

Les données pseudonymisées restent donc soumises au RGPD. Dans ce contexte, seule l’anonymisation offre une porte de sortie.

La pseudonymisation et l’anonymisation sont souvent associées lorsque l’on parle de la protection des données et lorsqu’il s’agit de prendre en compte les données personnelles dès la conception. Pourtant, ces procédés ont des objectifs distincts. La principale différence est que la pseudonymisation est un processus à double sens (un utilisateur doit pouvoir déchiffrer ou re-chiffrer les données), tandis que l’anonymisation consiste en une modification définitive de l’ensemble des données.

Anonymiser des données s’avère cependant complexe à mettre en œuvre. La réidentification des individus reste souvent possible via plusieurs méthodes. La singularisation est la première de ces méthodes : dans la plupart des ensembles de données, il existe des valeurs marginales ré-identifiantes. Le salaire du Directeur général dans une entreprise, par exemple, est une donnée souvent facile à isoler.

Viennent ensuite les recoupements. En recoupant des bases de données, il est souvent possible de ré-identifier un individu. Ainsi, en croisant des données de Netflix et IMDB, il a été possible de retrouver des personnes en fonctions de leurs goûts. Croiser un registre d’hôpital et des listes électorales pourrait notamment permettre ce genre de recoupements.

Pour finir, l’inférence permet l’identification d’un sujet en retrouvant des identifiants indirects et en les associant. L’association de la date de naissance, du sexe, et du code postal génère un identifiant unique dans la quasi-totalité des cas. Or les identifiants indirects sont légion (pointure, médecin traitant, achats internet, année d’obtention d’un diplôme, plaque d’immatriculation...). Plus on s’essaie à l’exercice, plus on prend conscience qu’il est mathématiquement impossible de prouver que la réidentification n’est pas possible.

Risque raisonnable et itérations

Tout l’exercice consiste donc à mesurer le risque et à choisir le "degré raisonnable d’anonymisation". Mais cela ne suffit pas : il est indispensable de le faire de manière régulière, car le risque change de forme au gré des fuites de données qui ont lieu dans le monde. Chaque nouvel ensemble de données mis à disposition redessine les contours du risque et oblige à repenser les risques de recoupement et d’inférence.

À défaut de pouvoir garantir la sécurité parfaite des données, d’autres approches s’imposent donc : réduire la surface d’attaque en limitant le stockage et la conservation des données. Il faut s’assurer de les disperser le moins possible et les concentrer dans des lieux maîtrisés.
Et si la donnée n’est pas directement utile, il est préférable de ne pas la stocker.

Pour les besoins opérationnels, la méthode la plus sûre consiste à faire en sorte que les données ne sortent pas de la base de production, sinon de manière anonymisée.

Comprendre et limiter le risque : une responsabilité partagée

À ce stade, les entreprises se tournent volontiers vers l’administrateur de la base de données et s’attendent à ce que seul, il puisse – selon les besoins – pseudonymiser ou anonymiser.

L’attente est légitime, pourtant elle ne prend pas en compte la complexité des métiers, des ensembles de données sur lesquels ils reposent. Souvent, les liens d’inférence sont difficiles à identifier entre les différentes colonnes d’une base de données.Pour trouver la meilleure réponse aux besoins des données, il est essentiel de décloisonner les entreprises.

Disons-le clairement : les règles permettant de masquer les données devraient être écrites en directe collaboration avec les équipes en charge du développement applicatif.

Les développeurs sont ceux qui ont la meilleure connaissance et la meilleure compréhension du fonctionnement des modèles de données. Une fois que les données et leurs relations sont bien comprises et identifiées, les règles automatisant le masquage des données peuvent être implémentées directement dans le schéma de la base de données.

La protection des données personnelles est une responsabilité partagée par chacun, y compris au sein des services informatiques.

Damien Clochard est administrateur de bases de données.