Protection des données personnelles, anonymisation, sécurité des données

Comme pour de nombreux Data Labs ou plateformes Big Data, les questions de donnée personnelle, des techniques de protection et d’anonymisation représentent des enjeux vitaux pour nous.

Nous allons détailler notre approche de ces questions dans plusieurs articles, dont voici le premier.

Ces notions sont complexes et se recouvrent largement, aussi je vais m’attacher dans ce premier article à présenter comment s’articulent les différents aspects – données personnelles, usages, solutions d’anonymisation et limites.

A retenir

  • D’un point de vue réglementaire (CNIL) toutes les données de clients entrent dans la catégorie des données personnelles et doivent être manipulées avec attention ; et certaines catégories doivent être exclues (santé, vie sexuelle, appartenance syndicale, opinions…)
  • Pour être échangées, le consentement réversible du client est obligatoire quelle que soit la finalité
  • L’anonymisation parfaite est difficile, voire impossible, le croisement d’information permettant souvent de ré-identifier les individus.
  • Néanmoins, dans le cadre précis d’échanges de données sur des individus connus des deux contreparties, une stratégie laissant un large champ à l’enrichissement de la connaissance client est applicable.
  • Cette stratégie consiste en : 1/ le remplacement cryptographique des identifiants (nom, prénom, date de naissance, …) et 2/ une altération des données discriminantes pour réaliser une anonymisation de facteur k

 

Données personnelles – Un sujet sensible qui demande autorisations et précautions

La notion de « donnée personnelle » est floue, et si l’on se réfère à divers avis du G29 (groupe de travail « Article 29 » des homologues européens de la CNIL), sa définition juridique est large :

le G29 a rappelé dans son avis 4/2007 du 20 juin 2007 qu’une donnée personnelle repose sur « toute information concernant une personne physique identifiée ou identifiable ». L’avis précise que : « les données concernent une personne si elles ont trait à l’identité, aux caractéristiques ou au comportement d’une personne ou si cette information est utilisée pour déterminer ou influencer la façon dont cette personne est traitée ou évaluée ».

Avec une telle définition, et considérant les techniques de machine learning utilisées aujourd’hui dans les activités de ciblage marketing ou de segmentation client, toute donnée peut vite se retrouver dans la catégorie donnée personnelle.

La notion étant très large, il faut donc identifier différentes sous catégories pour comprendre ce qu’on peut faire ou pas.

  • Données sensibles : données de santé, relatives à la vie sexuelle, origines raciales ou ethniques, opinions religieuses ou philosophiques, appartenance syndicale. Ces données ne doivent en principe pas être exploitées à des fins commerciales, et doivent être manipulées avec suffisamment de précautions comme le rappelle la mise en demeure récente de sites de rencontres par la CNIL.
  • Données identifiantes : état civil, noms, prénoms, adresses physiques et emails, coordonnées téléphoniques… Ces données doivent être protégées à double titre, en tant que donnée personnelle, et dans un tout autre registre en tant que donnée commerciale qu’on ne souhaite pas forcément divulguer ni céder.
  • Les données comportementales sont donc un vaste ensemble de données personnelles, et à ce titre peuvent être manipulées et échangées à la condition de respecter les obligations définies par la CNIL : déclaration des fichiers par leur propriétaires ; transparence de la collecte et opt-in ; possibilité donnée au consommateur ou internaute d’être retiré des fichiers ; et dans un autre registre, mise en œuvre des pratiques à l’état de l’art concernant la sécurisation informatique des stockages, échanges et accès aux systèmes.

 

Anonymisation, pseudonymisation, dé-identification – Tous ces mots pour dire qu’il est difficile d’anonymiser de manière irréversible

De nombreux projets en Data Labs doivent gérer la question de l’anonymisation, qui est un prérequis lorsqu’il s’agit de manipuler des données de clients ou de les transférer à un prestataire quelconque, mais dont l’objectif n’est pas toujours clair. Le sujet de l’anonymisation est vaste et complexe.

Le G29 défini l’anonymisation de la façon suivante :

pour rendre des données anonymes, il faut en retirer suffisamment d’éléments pour que la personne concernée ne puisse plus être identifiée. Plus précisément, les données doivent être traitées de façon à ne plus pouvoir être utilisées pour identifier une personne physique en recourant à «l’ensemble des moyens susceptibles d’être raisonnablement mis en oeuvre», soit par le responsable du traitement, soit par un tiers. Un facteur important est que le traitement doit être irréversible.

La barre est placée très haut, et la notion de « moyens susceptibles d’être raisonnablement mis en œuvre » est tellement floue qu’on peut vite être amené à prendre des dispositions trop radicales.

L’anonymisation commence bien sûr par le masquage des données d’identité (nom, prénom…), mais est-suffisant ? Regardons la donnée suivante :

[table id=1 /]

Cet individu est assez facilement « ré-identifiable » malgré le masquage.

Le remplacement de l’identité par un autre ID s’appelle pseudonymisation, ou parfois « dé-identification ». Une pseudonymisation ne vaut pas anonymisation, comme on le voit, mais est-ce grave ? Pour répondre à cette question, il faut revenir à l’usage qui sera fait des données et à leur diffusion.

Si on est dans une démarche open-data par exemple, l’anonymisation des données est fondamentale. Et difficile.

Une expérience de ré-identification très connue est celle réalisée sur la base de données des clients du fournisseur de contenu vidéo Netflix. Des chercheurs ont analysé les propriétés géométriques de cette base de données composée de plus de 100 millions d’évaluations, sur une échelle de 1 à 5, attribuées à plus de 18 000 films par près de 500 000 utilisateurs, qui avait été rendue publique par la société, après avoir été «anonymisée» conformément à la politique interne de l’entreprise en matière de confidentialité, en supprimant toutes les informations d’identification des utilisateurs hormis les évaluations et les dates. Un bruit avait été ajouté dans la mesure où les évaluations avaient été légèrement augmentées ou diminuées.
Malgré ces précautions, il est apparu que 99 % des enregistrements des utilisateurs pouvaient être identifiés de manière unique dans l’ensemble de données en prenant comme critères de sélection 8 évaluations et des dates comportant une marge d’erreur de 14 jours, tandis qu’un abaissement des critères de sélection (2 évaluations, avec une marge d’erreur de 3 jours dans les dates) permettait encore d’identifier 68 % des utilisateurs
[Narayanan, A., et Shmatikov, V. (mai 2008), «Robust de-anonymization of large sparse datasets», in Security and Privacy, 2008, SP 2008, IEEE Symposium on (p. 111 à 125), IEEE. ]

Dans d’autres cas, c’est la loi qui impose l’anonymisation.

Ex : directive «vie privée et communications électroniques» (directive 2002/58/CE)
«Les données relatives au trafic concernant les abonnés et les utilisateurs [de services de communication] traitées et stockées par le fournisseur d’un réseau public de communications ou d’un service de communications électroniques accessibles au public doivent être effacées ou rendues anonymes lorsqu’elles ne sont plus nécessaires à la transmission d’une communication […]
Lorsque des données de localisation, autres que des données relatives au trafic, concernant des utilisateurs ou abonnés de réseaux publics de communications ou de services de communications électroniques accessibles au public ou des abonnés à ces réseaux ou services, peuvent être traitées, elles ne le seront qu’après avoir été rendues anonymes ou moyennant le consentement des utilisateurs ou des abonnés, dans la mesure et pour la durée nécessaires à la fourniture d’un service à valeur ajoutée. »

 

Techniques d’anonymisation – Vers une anonymisation de facteur k mais pas toujours

Il existe diverses techniques pour réaliser l’anonymisation d’un dataset, et elles sont à envisager lorsque les données sont manifestement trop sensibles pour être échangées, mais recèlent pourtant une grande valeur si l’on arrivait à les réduire à une famille de « patterns comportementaux » plutôt que des comportements individuels.

Par exemple, on pourrait envisager de monétiser des données de transactions bancaires, qui au niveau individuel sont très sensibles, mais à un niveau macro seraient utiles pour déterminer des segments (cf par exemple le challenge Axa Banque).

Toute la question est de déterminer ce « niveau macro ». Une approche possible est l’anonymation de facteur k : faire en sorte que l’analyse des données ne permette pas de revenir à un groupe d’individus de taille inférieure à k. Cette technique sera détaillée dans un prochain article à venir.

 

Un nécessaire compromis

Le revers de la médaille à la mise en œuvre de tels algorithmes est la destruction d’une partie de l’information (réduction du signal/bruit), ce qui va à l’encontre de ce que l’on cherche à faire lors de l’acquisition de données (recherche de signaux faibles dans de nouveaux jeux de données), sans parler de la complexité de mise en œuvre. Et ces techniques ne sont pas toujours efficaces, comme le relève le G29 lui-même.

Alors, comment procéder ?

En fait, l’échange de données de connaissance client entre entreprises n’est pas de l’open-data (!), et n’est que rarement limité par des contraintes légales comme dans les exemples donnés ci-dessus.

Dans le cadre d’échange de données concernant des individus connus des 2 contreparties, ce qui compte c’est bien la pseudonymisation, de façon à protéger l’identité des individus dans les transferts, et dans les systèmes intermédiaires, puisque l’anonymat n’est pas requis d’un côté ou de l’autre. Cette pseudonymisation doit (recommendation G29) être réalisée à l’aide de fonctions cryptographiques, afin de la rendre à sens unique, et une attention particulière doit être donnée pour se prémunir des attaques par dictionnaire (sécurité du stockage ou mise en œuvre de double hachage).

Les éléments de sécurité informatique (chiffrement, sécurité des accès, notamment chez les partenaires et prestataires…) ont évidemment un rôle à jouer ici, en réduisant le risque d’une diffusion inappropriée de la donnée, et donc la nécessité d’une anonymisation forte.

 

Notre approche

Blue DME est une plateforme d’échange inter-entreprises de données comportementales de clients, personnes physiques, pros et entreprises.
Notre valeur ajoutée réside dans notre capacité à enrichir les données d’un acquéreur à l’aide des données mises en vente sur le marché, et en établissant un prix lié à la valeur apportée par cet enrichissement.

Nous agissons en tant que tiers de confiance pour organiser la transaction d’échange, en garantissant la qualité des données et leur protection. Cette position de tiers de confiance nous oblige encore davantage à organiser la protection des données personnelles.

D’une part, nous ne traitons que des données comportementales à l’exclusion des données sensibles, et pour lesquelles le consentement du client (opt-in) a été obtenu.

D’autre part, nous mettons en œuvre diverses stratégies couvrant l’ensemble des processus d’échange de données :

  • Pratiques à l’état de l’art de sécurité informatiques (stockages, échanges, habilitations, auditabilité, etc.)
  • Pseudonymisation avec masquage des identités ou des identifiants forts (emails, téléphone…) basé sur des mécanismes de hachage cryptographique. Cela nous permet d’identifier des individus communs dans les différents datasets mis en vente sans avoir à manipuler les identités réelles.
  • Analyse des risques de ré-identification des individus par combinaison de caractéristiques, et mise à disposition d’outils d’anonymisation de facteur k utilisables lorsque nécessaire
  • Manipulation de données transformées, et non brutes, afin de limiter les risques lors de leur manipulation. Ainsi, l’exemple donné plus haut
    [table id=1 /]  … sera en fait transformé vers ce format dans nos sytèmes : [table id=2 /] … et la sémantique (libéllés) est stockée de manière séparée. En effet, les algorithmes de machine learning n’ont pas besoin de la sémantique pour chercher des corrélations entre jeux de données. Ainsi, sous ce format, les fichiers sont très difficilement exploitables en cas de compromission accidentelle.

Toutes ces techniques sont un champ de recherche actif chez Blue DME. Nous étudions notamment comment appliquer l’anonymisation de facteur k de manière optimale ; et comment réaliser une pseudonymisation de niveau cryptographique tout en tolérant d’inévitables fautes de frappes dans les noms, prénoms, date de naissance, etc.

 

Conclusion

Comme on l’a vu, le sujet de la protection des données personnelles est un sujet large et complexe nécessitant une parfaite maitrise d’un cadre légal, un fort consentement du client et des techniques sophistiquée de dé-identification ou d’anonymisation. Ce sujet primordial doit être abordé au plus tôt dans le cadrage de tout projet de Data Lab ou de monétisation des données, car ses impacts sont transverses.

Nous adoptons sur ce thème une approche « Data Privacy by Design » : intégrer cette dimension dans tous les éléments de notre architecture et de nos processus, et mettre en œuvre les techniques à l’état de l’art de protection des données, afin de rendre possible l’échange de données comportementales entre entreprises.

 

2 thoughts on “Protection des données personnelles, anonymisation, sécurité des données

Les commentaires sont fermés.