Confidentialité différentielle dans Snowflake¶
La confidentialité différentielle est une norme largement reconnue en matière de confidentialité des données qui limite le risque qu’un utilisateur puisse divulguer des informations sensibles à partir d’un ensemble de données sensibles. Elle protège l’identité et les informations des entités individuelles dans les données, par exemple les personnes, les entreprises et les emplacements. Bien que les informations de chaque entité individuelle soient protégées, la confidentialité différentielle permet toujours aux consommateurs de données d’apprendre des statistiques, des tendances et des comportements sur des groupes d’individus.
La confidentialité différentielle offre une protection solide contre la ré-identification, particulièrement efficace contre les attaques de confidentialité ciblées. Cette protection vous permet de partager des données sensibles entre équipes, en dehors de votre organisation et au-delà des limites réglementaires. La confidentialité différentielle atténue le risque accru de réidentification associé à la jonction de deux ensembles de données sensibles, à l’ajout de nouveaux champs, au démasquage de champs existants ou à la fourniture de lignes individuelles au lieu de données pré-agrégées.
Contrairement à d’autres méthodologies de confidentialité, la confidentialité différentielle effectue les opérations suivantes :
Protège contre les attaques ciblées de confidentialité, par exemple les attaques de différenciation et d’amplification.
Quantifie et gère le compromis entre confidentialité et utilité, c’est-à-dire contrôle la quantité d’informations non sensibles que les consommateurs peuvent apprendre sur les données.
Élimine la nécessité pour les fournisseurs de données de transformer les données sensibles pour réduire le risque de ré-identification (par exemple, masquage, rédaction et compartimentation).
Comment la confidentialité différentielle protège-t-elle les informations sensibles ?¶
Dans le cadre de la confidentialité différentielle, les résultats de la requête ne doivent pas révéler d’informations qui pourraient être utilisées pour identifier une entité individuelle. Snowflake effectue les opérations suivantes pour appliquer la confidentialité différentielle :
Agrégats bruyants¶
Les requêtes différentiellement privées doivent regrouper les données pour renvoyer des résultats ; les requêtes au niveau des lignes comme SELECT *
sont bloquées. Ces agrégats sont bruyants ; ils ne sont pas le résultat exact d’un calcul. Du bruit (c’est-à-dire une variation ou une randomisation) est introduit dans le résultat pour masquer si une ligne ou une entité particulière a été incluse dans l’agrégation.
L’ajout de bruit protège contre les attaques de confidentialité telles que le découpage fin et la différenciation. La quantité de bruit ajoutée au résultat de la requête dépend de plusieurs facteurs qui influencent la sensibilité de la requête, notamment le nombre d’enregistrements interrogés, le type d’agrégat et les types de transformations de données. Snowflake calcule la sensibilité d’une requête sur la base de mathématiques rigoureuses, mais elle peut être comprise de manière vague comme le potentiel de la requête à divulguer des informations sur une entité individuelle. En général, les requêtes moins sensibles ont moins de bruit, potentiellement à un point statistiquement négligeable. Les requêtes très sensibles, par exemple une requête qui tente d’isoler une entité individuelle, comportent une grande quantité de bruit pour éviter la fuite d’informations sensibles.
Snowflake n’introduit pas de bruit dans les agrégations intermédiaires qui se produisent avant l’agrégation finale de la requête ; le bruit n’est introduit qu’une seule fois par requête.
Snowflake considère que le nombre de lignes de la table protégée par la confidentialité est public. Par exemple, l’exécution de SELECT COUNT(*) FROM t
, où la table t
est protégé par une politique de confidentialité, renvoie un résultat exact sans entraîner de perte de confidentialité.
Pour plus d’informations sur la façon de comprendre le niveau de bruit, voir Comprendre les résultats de la requête.
Limiter la perte de confidentialité¶
Chaque requête sur un ensemble de données protégé peut entraîner l’exposition d’informations privées associées à un individu, y compris les résultats agrégés bruyants que produisent les requêtes différentiellement privées. Dans la confidentialité différentielle, cette divulgation d’informations est connue sous le nom de perte de confidentialité et constitue une unité de mesure quantifiable. Plus une requête révèle d’informations privées, plus la perte de confidentialité associée à cette requête est élevée. Étant donné que la perte de confidentialité est quantifiable, Snowflake peut utiliser la confidentialité différentielle pour protéger les données sensibles sur un historique de requêtes jusqu’à un certain degré de confiance statistique.
La perte de confidentialité s’accumule à mesure qu’un utilisateur exécute des requêtes sur les données protégées. Lorsque la perte de confidentialité cumulée atteint un certain seuil, le fait de permettre ultérieurement à l’utilisateur de voir davantage de résultats lui permettrait théoriquement d’identifier des individus avec un niveau de confiance inacceptable. Un budget de confidentialité définit une limite à la perte de confidentialité acceptable. Snowflake comptabilise la perte de confidentialité des requêtes exécutées par un utilisateur ou un groupe d’utilisateurs et s’assure que ce décompte ne dépasse jamais le budget de confidentialité associé à ces utilisateurs. Snowflake propose un budget de confidentialité personnalisable avec une valeur par défaut préconfigurée qui définit le seuil de perte de confidentialité.
Snowflake utilise une politique de confidentialité, qui est un objet de niveau schéma, pour associer un budget de confidentialité à un utilisateur ou à un groupe d’utilisateurs. Lorsqu’un administrateur attribue cette politique de confidentialité à une table ou à une vue, celle-ci devient protégée par la confidentialité. Lorsqu’un utilisateur exécute une requête sur une table protégée par la confidentialité, Snowflake utilise la politique de confidentialité pour déterminer quel budget de confidentialité est associé à l’utilisateur et garantit que la perte de confidentialité subie par la requête ne dépassera pas la limite du budget.
Confidentialité différentielle en théorie et en pratique¶
La norme de confidentialité différentielle provient de la littérature universitaire et a été formulée pour offrir de solides garanties de confidentialité mathématiquement prouvées, en particulier contre les attaques théoriques de confidentialité. En particulier, les paramètres de confidentialité tels que le budget de confidentialité sont définis de manière plus conservatrice lorsqu’ils sont discutés dans des contextes universitaires. Ces paramètres favorisent une forte protection pour contrer les attaques théoriques contre la confidentialité, au détriment de l’utilité des données (fidélité analytique, précision et disponibilité). Lorsque vous envisagez le compromis entre confidentialité et utilité pour votre cas d’utilisation, y compris pour des données hautement sensibles comme PII et PHI, considérez ce qui suit :
Les attaques pratiques contre la confidentialité ne sont pas aussi efficaces que les attaques théoriques contre la confidentialité décrites dans la littérature universitaire qui supposent que les attaquants disposent de ressources de calcul illimitées et d’un accès à tous les ensembles de données, à l’exception de celui qu’ils attaquent.
Les consommateurs de données ne souhaitent généralement pas lancer intentionnellement d’attaques, car le fournisseur de données peut révoquer l’accès aux données du consommateur et la valeur analytique des données est trop élevée pour qu’ils risquent de les perdre.
Snowflake a sélectionné des paramètres par défaut qui équilibrent raisonnablement la protection de la confidentialité et l’utilité en fonction des objectifs des cas d’utilisation du monde réel, mais vous pouvez toujours définir des paramètres différents pour répondre à vos besoins spécifiques.
Flux de travail de confidentialité différentielle¶
Le flux de travail suivant comprend des tâches effectuées par le fournisseur de données qui protège ses données avec une confidentialité différentielle et des tâches pour un analyste qui interroge les données après leur protection.
Fournisseurs de données :
Si vous souhaitez mettre en œuvre la confidentialité au niveau de l’entité, structurez vos données pour répondre aux exigences.
Créez une politique de confidentialité qui associe les budgets de confidentialité aux utilisateurs en fonction de facteurs tels que le rôle ou le compte.
Attribuez la politique de confidentialité à une table ou à une vue afin que les requêtes soient différentiellement privées.
Définissez un domaine de confidentialité pour les colonnes numériques et catégorielles dans la table ou la vue protégée par la confidentialité.
Accordez des privilèges aux analystes afin qu’ils puissent accéder aux données protégées par la confidentialité.
Lorsque les analystes exécutent des requêtes sur les données protégées par la confidentialité, vous pouvez gérer les budgets de confidentialité associés aux utilisateurs.
Analyste :
Affichez les domaines de confidentialité que le fournisseur de données a défini pour les colonnes de la table protégée par la confidentialité afin de mieux comprendre le contenu de la colonne.
Si le fournisseur de données a oublié de définir un domaine de confidentialité pour une colonne que vous souhaitez utiliser dans une agrégation ou dans une clause GROUP BY, spécifiez le domaine de confidentialité pour la colonne.
Exécutez des requêtes différentiellement privées sur les tables et les vues protégées par la confidentialité.
Utilisez l’intervalle de bruit pour aider à comprendre les résultats d’une agrégation.
Si vous le souhaitez, réduisez le domaine de confidentialité du fournisseur de données pour essayer d’améliorer les résultats de la requête.
Limitations¶
Lorsqu’une table est protégée par la confidentialité, les analystes ne peuvent interroger que les types de données suivants :
Types de données de chaîne. Les types binaires ne sont pas pris en charge.
Types de données de date et heure. Pour les horodatages, uniquement TIMESTAMP_NTZ est pris en charge.
Certaines fonctionnalités de Snowflake ne sont actuellement pas prises en charge lors de l’utilisation de la confidentialité différentielle. Pour plus de détails, voir Interactions avec les fonctionnalités Snowflake.
La fonctionnalité de requête est limitée afin de protéger la confidentialité. Pour obtenir une liste des opérateurs pris en charge, de la syntaxe de requête et des fonctions, voir Référence SQL de confidentialité différentielle.
Lorsqu’une requête est exécutée sur une table protégée par la confidentialité, Snowflake calcule d’abord les statistiques qui influencent la quantité de bruit qui sera ajoutée, puis il exécute la requête. Si les données changent entre ces deux étapes, la quantité de bruit ajoutée peut être incorrecte. Snowflake recommande aux fournisseurs de données de planifier les mises à jour des données afin qu’elles ne se produisent pas lorsque les analystes peuvent exécuter des requêtes.
Prochaines étapes¶
Si vous êtes un fournisseur de données qui utilise la confidentialité différentielle pour protéger votre ensemble de données, voir Mise en œuvre de la confidentialité différentielle.
Si vous êtes un analyste qui interroge un ensemble de données protégé par la confidentialité différentielle, voir Interrogation de données protégées par la confidentialité différentielle.