L'un des points essentiels à aborder avant de se plonger dans la question de la confidentialité d'un jeu de données est la notion de pseudonymisation par rapport à celle d'anonymisation. Ces termes sont souvent utilisés de manière interchangeable, mais sont en fait très différents en termes de protection des individus.
Notons que la pseudonymisation est une étape nécessaire avant l'anonymisation, car les identifiants directs n'apportent aucune valeur à un ensemble de données.
Pour être considéré comme anonyme, un jeu de données doit satisfaire les trois critères identifiés par le Comité Européen de Protection des Données (CEPD, anciennement connu sous le nom de G29). Pour mesurer le respect de ces critères, il faut toujours comparer le jeu de données original à sa version traitée, le traitement étant toute technique visant à améliorer la confidentialité de l'ensemble de données (ajout de bruit, modèles génératifs, Avatar).
Avant de nous plonger dans les mesures spécifiques et la façon dont elles sont mesurées, nous devons clarifier ce que nous essayons réellement d'empêcher.
Nous allons prendre les critères officiels du CEPD et ajouter quelques exemples pour mettre en évidence les principales différences entre les trois.
Ces critères sont les suivants :
Exemple : vous travaillez dans une compagnie d'assurance et vous disposez d'un ensemble de données sur vos clients et leurs véhicules. Vous supprimez simplement les identifiants personnels, c'est-à-dire leur nom. Mais, étant donné que la combinaison des autres valeurs est unique (type de véhicule, marque, âge du véhicule, couleur), vous êtes en mesure d'identifier directement chacun de vos clients, même sans leur nom.
Exemple : dans le jeu de données d'une agence de recrutement, les clients et leur salaire, ainsi que d'autres informations, sont répertoriées. Dans une base de données distincte, accessible au public (par exemple LinkedIn), vous recueillez des informations telles que l'intitulé du poste, la ville et l'entreprise. Grâce à ces informations, vous êtes en mesure de relier chaque individu d'un ensemble de données à l'autre, ce qui vous permet d'obtenir de nouvelles informations, comme le salaire.
Exemple : une industrie pharmaceutique possède un jeu de données sur les personnes ayant participé à un essai clinique. Si vous savez qu'un individu particulier est un homme, et que tous les hommes de l'ensemble de données sont en surpoids, vous pouvez en déduire que cet individu spécifique est en surpoids, sans pour autant le distinguer.
La première famille de métriques que nous allons maintenant présenter vise à évaluer la protection d'un jeu de données contre les attaques d'individualisation. Ces attaques peuvent prendre différentes formes, ce qui nécessite différentes mesures complémentaires. Certaines mesures d'individualisation sont indépendantes du modèle et peuvent donc être utilisées sur n'importe quelle paire de jeux de données originaux et traités. D'autres métriques nécessitent de conserver temporairement un lien entre les individus originaux et traités.
Nous présentons maintenant deux métriques simples qui peuvent être utilisées sur des jeux de données traités par n'importe quelle technique. Ces métriques sont particulièrement utiles lorsqu'il s'agit de comparer les résultats de différentes approches.
Un jeu de données présentant un DTC et un CDR élevés garantira que le traitement qui a été appliqué aux données a modifié les caractéristiques des individus. Cependant, même si les avatars sont éloignés des originaux, il reste un risque que les individus originaux puissent être associés à leur homologue synthétique le plus similaire.
Chez Octopize, notre traitement génère des données synthétiques anonymisées. Nous avons développé des mesures supplémentaires, nous plaçant dans le pire des scénarios où un attaquant dispose à la fois des données originales et des données anonymes. Bien que peu probable en pratique, cette approche est recommandée par le CEPD. Le hidden rate et le local cloaking sont des métriques qui permettent ici de mesurer la protection des données contre les attaques d'individualisation basées sur la distance. Ces deux métriques nécessitent que le lien entre chaque individu et sa version synthétique soit disponible.
Pour illustrer ces métriques, regardons un exemple simplifié où une cohorte d'animaux (pourquoi pas ! ?) serait anonymisée (avec notre solution Avatar par exemple).
Avec les solutions d'anonymisation centrées sur l'individu, un individu synthétique est généré à partir d'un original. Le lien entre les originaux et les individus synthétiques peut être utilisé pour mesurer le niveau de protection contre les attaques basées sur la distance. Dans notre exemple, nous voyons que le chat roux a été anonymisé en tant que guépard alors que l'individu synthétique créé à partir du tigre est un chat noir.
Une attaque basée sur la distance suppose que la mise à l'écart peut être effectuée en associant un original à son individu synthétique le plus similaire. Dans notre exemple, un lien basé sur la distance associerait le chat roux au chat noir, le tigre au guépard et ainsi de suite.
Le Hidden Rate actuel mesure la probabilité qu'un attaquant commette une erreur lorsqu'il associe un individu à son individu synthétique le plus similaire. Dans cette illustration, nous voyons que la plupart des correspondances basées sur la distance ne sont pas correctes et que Hidden Rate est donc élevé, ce qui illustre une bonne protection contre les attaques de singularisation basées sur la distance.
Dans cette figure, nous illustrons comment le local cloaking est calculé pour un seul individu original, ici le chat roux. Grâce au lien que nous gardons temporairement, nous savons que l'individu synthétique réel généré à partir du chat roux est le guépard. Son local cloaking est le nombre d'individus synthétiques entre lui et le guépard. Dans cet exemple, il n'y a qu'un seul individu synthétique : le chat noir, ce qui signifie que le local cloaking du chat roux est de 1. Le même calcul est effectué pour tous les originaux.
Les quatre métriques que nous venons de voir fournissent une bonne couverture de la protection contre les attaques d'individualisation mais comme nous l'avons vu au début de cet article, il existe d'autres types d'attaques contre lesquelles les données personnelles doivent être protégées.
Les métriques qui répondent au critère de corrélation répondent à un scénario d'attaque plus courant et plus probable.
L'attaquant dispose d'un jeu de données traitées et d'une base de données d'identification externe (par exemple, un registre des électeurs) contenant des informations communes avec les données traitées (par exemple, l'âge, le sexe, le code postal). Plus il y a d'informations en commun entre les deux bases de données, plus l'attaque sera efficace.
Le taux de protection contre les corrélations (Correlation Protection Rate) évalue le pourcentage d'individus qui ne seraient pas reliés avec succès à leur homologue synthétique si l'attaquant utilisait une source de données externe. Les variables sélectionnées comme étant communes aux deux bases de données doivent être susceptibles d'être trouvées dans une source de données externe. (Par exemple, l'age devrait être pris en compte alors que la concentration_insuline_D2 ne devrait pas l'être). Pour couvrir le pire des scénarios, nous supposons que les mêmes individus sont présents dans les deux bases de données. En pratique, certains individus de la base de données anonymisée ne sont pas présents dans la source de données externe et vice versa. Cette métrique repose également sur le fait que le lien entre l'original et le synthétique est conservé temporairement. Ce lien est utilisé pour mesurer combien d'appariements sont incorrects.
Les métriques qui répondent au critère d'inférence répondent à un autre type d'attaque où l'attaquant cherche à déduire des informations supplémentaires sur un individu à partir des données anonymisées disponibles.
Notre solution, Avatar, calcule toutes les métriques ci-dessus et plus encore. Nous nous donnons pour mission de générer des jeux de données anonymes avec un modèle entièrement explicable et des mesures de confidentialité concrètes qui nous permettent de mesurer le degré de protection.
Pour ce faire, il y a beaucoup de choses à prendre en considération et rendre un jeu de données anonyme ne doit pas être pris à la légère, il y a de nombreux pièges que l'on peut rencontrer qui pourraient mener à des fuite accidentelles d’informations. C'est pourquoi, en plus des mesures et de la garantie de confidentialité associée, nous produisons un rapport d'anonymisation qui décrit clairement les différentes mesures, ainsi que les critères d'évaluation qu'elles visent à mesurer, à l'instar de ce que nous avons exposé ci-dessus. Le rapport explique, en termes simples, toutes les mesures et présente des statistiques sur les jeux de données, avant et après l'anonymisation.
En pratique, l'anonymisation d'un jeu de données est toujours un compromis entre la garantie de la confidentialité et la préservation de l'utilité. Un jeu de données totalement aléatoire est privé, mais ne sert à rien.
Nous examinerons comment mesurer l'utilité d'un jeu de données, avant et après une anonymisation, dans un prochain article.
Intéressés par notre solution ? Contactez-nous !
Rédaction : Tom Crasset & Olivier Regnier-Coudert
