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 :
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 :
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 :
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.
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:
- 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érentiellemax_groups_contributed
. - 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.
- Elle agrège les contributions agrégées par entité pour chaque groupe.
- 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.
- 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:
- Présentation conviviale et non technique de la confidentialité différentielle
- SQL privé différentiel avec contribution utilisateur limitée
- Confidentialité différentielle sur Wikipédia
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:
- Une colonne d'unité de confidentialité est définie.
- La liste
SELECT
contient une clause différentielle privée. - Seules les fonctions d'agrégation différentielle privée figurent dans la liste
SELECT
avec la clause différentielle privée.
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.