Utiliser la confidentialité différentielle

Ce document fournit des informations générales sur la confidentialité différentielle pour BigQuery. Pour en savoir plus sur la syntaxe, consultez la clause de confidentialité différentielle. Pour obtenir la liste des fonctions que vous pouvez utiliser avec cette syntaxe, consultez la page Fonctions d'agrégation différentielle privée.

Qu'est-ce que la confidentialité différentielle ?

La confidentialité différentielle est une norme pour les calculs portant sur des données qui limitent les informations personnelles divulguées par une sortie. La confidentialité différentielle est couramment utilisée pour partager des données et permettre des inférences sur des groupes de personnes tout en empêchant une personne d'apprendre des informations sur une personne.

La confidentialité différentielle est utile:

  • En cas de risque de restauration de l'identification.
  • Pour quantifier le compromis entre les risques et l'utilité des analyses

Pour mieux comprendre la confidentialité différentielle, prenons un exemple simple.

Ce graphique à barres montre la fréquentation d'un petit restaurant un soir particulier. De nombreux clients arrivent à 19h, et le restaurant est complètement vide à 1h du matin :

Le graphique montre l'afflux de gens dans un petit restaurant en mappant les clients à des heures spécifiques de la journée.

Ce graphique semble utile, mais il existe un problème. Lorsqu'un nouveau client arrive, cela se voit immédiatement sur le graphique à barres. Dans le graphique suivant, il est clair qu'un nouveau client est arrivé à environ 1h :

Le graphique montre des anomalies dans les arrivées.

Afficher ces informations n'est pas idéal du point de vue de la confidentialité, car les statistiques anonymes ne doivent pas révéler de contributions individuelles. Le fait de placer ces deux graphiques côte à côte rend les choses plus évidentes : le graphique à barres orange a un client supplémentaire qui est arrivé vers 1h :

La comparaison des graphiques met en évidence une contribution individuelle

Là encore, cette représentation n'est pas idéale. Pour éviter ce type de problème de confidentialité, vous pouvez ajouter un bruit aléatoire aux graphiques à barres en utilisant la confidentialité différentielle. Dans le graphique de comparaison suivant, les résultats sont anonymisés et ne révèlent plus de contributions individuelles.

La confidentialité différentielle est appliquée aux comparaisons.

Fonctionnement de la confidentialité différentielle sur les requêtes

L'objectif de la confidentialité différentielle est de limiter le risque qu'un utilisateur puisse obtenir des informations sur un individu à partir d'un ensemble de données. La confidentialité différentielle établit un juste équilibre entre la nécessité de protéger la confidentialité et la nécessité du point de vue de l'analyse statistique. À mesure que la confidentialité augmente, l'utilité de l'analyse statistique diminue, et inversement.

Avec GoogleSQL pour BigQuery, vous pouvez transformer les résultats d'une requête avec des agrégations différentielles privées. Lorsque la requête est exécutée, elle effectue les opérations suivantes:

  1. Elle calcule les agrégations par entité pour chaque groupe si des groupes sont spécifiés avec une clause GROUP BY. Elle limite le nombre de groupes auxquels chaque entité peut contribuer, en fonction du paramètre de confidentialité différentielle max_groups_contributed.
  2. Elle limite chaque contribution d'agrégation par entité pour se trouver dans les marges de limitation. Si les marges de limitation ne sont pas spécifiées, elles sont calculées implicitement de manière différentielle privée.
  3. Elle agrège les contributions agrégées par entité pour chaque groupe.
  4. Elle ajoute du bruit à la valeur globale finale pour chaque groupe. L'échelle du bruit aléatoire est une fonction de l'ensemble des limites et des paramètres de confidentialité restreints.
  5. Elle calcule un nombre d'entités bruyantes pour chaque groupe et élimine les groupes contenant peu d'entités. Un nombre d'entités bruyantes aide à éliminer un ensemble non déterministe de groupes.

Le résultat final est un ensemble de données dans lequel chaque groupe comporte des résultats agrégés bruyants et où les petits groupes ont été éliminés.

Pour en savoir plus sur la confidentialité différentielle et ses cas d'utilisation, consultez les articles suivants:

Générer une requête différentielle privée

Les règles suivantes doivent être remplies pour que la requête différentielle soit valide:

Définir une colonne d'unité de confidentialité

Une unité de confidentialité est l'entité d'un ensemble de données protégé qui utilise la confidentialité différentielle. Une entité peut être une personne, une entreprise, un emplacement ou n'importe quelle colonne que vous choisissez.

Une requête différentiellement privée doit inclure une seule colonne d'unités de confidentialité. Une colonne d'unité de confidentialité est un identifiant unique pour une unité de confidentialité et peut exister dans plusieurs groupes. Étant donné que plusieurs groupes sont acceptés, le type de données de la colonne d'unité de confidentialité doit être groupable.

Vous pouvez définir une colonne d'unité de confidentialité dans la clause OPTIONS d'une clause de confidentialité différentielle avec l'identifiant unique privacy_unit_column.

Dans les exemples suivants, une colonne d'unité de confidentialité est ajoutée à une clause de confidentialité différentielle. id représente une colonne provenant d'une table appelée students.

SELECT WITH DIFFERENTIAL_PRIVACY
  OPTIONS (epsilon=10, delta=.01, privacy_unit_column=id)
  item,
  COUNT(*, contribution_bounds_per_group=>(0, 100))
FROM students;
SELECT WITH DIFFERENTIAL_PRIVACY
  OPTIONS (epsilon=10, delta=.01, privacy_unit_column=members.id)
  item,
  COUNT(*, contribution_bounds_per_group=>(0, 100))
FROM (SELECT * FROM students) AS members;

Supprimer le bruit d'une requête différentielle privée

Dans la documentation de référence sur la syntaxe des requêtes, consultez la page Supprimer le bruit.

Ajouter du bruit à une requête différentielle privée

Dans la documentation de référence sur la syntaxe des requêtes, consultez la section Ajouter du bruit.

Limiter les groupes dans lesquels un ID de confidentialité peut exister

Dans la documentation de référence "Syntaxe des requêtes", consultez la section Limiter les groupes dans lesquels un ID d'unité de confidentialité peut exister.

Limites

Cette section décrit les limites de la confidentialité différentielle.

Implications de la confidentialité différentielle en termes de performances

Les requêtes différentielles privées s'exécutent plus lentement que les requêtes standards, car l'agrégation par entité est effectuée et la limite max_groups_contributed est appliquée. Restreindre les limites de contribution peut améliorer les performances de vos requêtes différentielles privées.

Les profils de performances des requêtes suivantes ne sont pas similaires:

SELECT
  WITH DIFFERENTIAL_PRIVACY OPTIONS(epsilon=1, delta=1e-10, privacy_unit_column=id)
  column_a, COUNT(column_b)
FROM table_a
GROUP BY column_a;
SELECT column_a, COUNT(column_b)
FROM table_a
GROUP BY column_a;

La différence de performance est due au fait qu'un niveau de regroupement supplémentaire est plus précis pour les requêtes différentielles privées, car l'agrégation par entité doit également être effectuée.

Les profils de performances des requêtes suivantes doivent être similaires, même si la requête différentielle privée est légèrement plus lente:

SELECT
  WITH DIFFERENTIAL_PRIVACY OPTIONS(epsilon=1, delta=1e-10, privacy_unit_column=id)
  column_a, COUNT(column_b)
FROM table_a
GROUP BY column_a;
SELECT column_a, id, COUNT(column_b)
FROM table_a
GROUP BY column_a, id;

La requête différentielle privée est plus lente, car elle comporte un grand nombre de valeurs distinctes pour la colonne d'unité de confidentialité.

Limites de délimitation implicites pour les petits ensembles de données

La délimitation implicite fonctionne mieux lorsqu'elle est calculée à l'aide d'ensembles de données volumineux. La délimitation implicite peut échouer lorsque les ensembles de données contiennent un faible nombre d'unités de confidentialité et qu'ils ne renvoient aucun résultat. En outre, le fait de limiter implicitement un ensemble de données avec un faible nombre d'unités de confidentialité peut limiter une grande partie des anomalies, ce qui entraîne des agrégations et des résultats sous-représentés qui sont plus modifiés par la limitation que par le bruit supplémentaire. Les ensembles de données qui ont un petit nombre d'unités de confidentialité ou sont très partitionnés doivent utiliser le processus de limitation explicite plutôt qu'implicite.

Failles de confidentialité

Tout algorithme de confidentialité différentielle, y compris celui-ci, entraîne un risque de fuite de données privées lorsqu'un analyste agit de mauvaise foi, en particulier lors du calcul des statistiques de base telles que les sommes, en raison de limites arithmétiques.

Limites de garanties de confidentialité

Bien que la confidentialité différentielle de BigQuery applique l'algorithme de confidentialité différentielle, elle ne garantit pas les propriétés de confidentialité de l'ensemble de données obtenu.

Erreurs d'exécution

Un analyste agissant de mauvaise foi avec la possibilité d'écrire des requêtes ou de contrôler les données d'entrée peut déclencher une erreur d'exécution sur des données privées.

Bruit à virgule flottante

Les failles liées aux attaques d'arrondis, d'arrondis répétés et de tri doivent être prises en compte avant d'utiliser la confidentialité différentielle. Ces failles sont particulièrement préoccupantes lorsqu'un pirate informatique peut contrôler une partie du contenu d'un ensemble de données ou l'ordre du contenu de celui-ci.

Les ajouts de bruit différentiellement privés sur les types de données à virgule flottante sont soumis aux failles décrites dans la section Sous-estimation diffuse de la sensibilité dans les bibliothèques différentielles privées et comment la corriger. Les ajouts de bruits sur les données de type entier ne sont pas soumis aux failles décrites dans l'article.

Anticiper les risques

Un analyste agissant de mauvaise foi pourrait exécuter une requête suffisamment complexe pour faire une inférence sur les données d'entrée en fonction de la durée d'exécution d'une requête.

Classification incorrecte

La création d'une requête de confidentialité différentielle suppose que vos données se présentent dans une structure bien connue et compréhensible. Si vous appliquez une confidentialité différentielle sur des identifiants incorrects, par exemple un ID de transaction plutôt qu'un ID de personne, vous risquez d'exposer des données sensibles.

Si vous avez besoin d'aide pour interpréter vos données, envisagez d'utiliser des services et des outils, tels que les suivants:

Tarifs

L'utilisation de la confidentialité différentielle n'entraîne pas de frais supplémentaires, mais les tarifs standards de BigQuery pour l'analyse s'appliquent.