Mise en œuvre de la confidentialité différentielle¶

Cette rubrique contient des informations destinées au fournisseur de données qui implémente la confidentialité différentielle pour son compte.

Lorsque vous implémentez la confidentialité différentielle pour votre ensemble de données, vos tâches impliquent trois concepts clés :

Politiques de confidentialité. Une table ou une vue n’est pas protégée par la confidentialité différentielle tant que vous ne lui attribuez pas une politique de confidentialité. Une table ou une vue avec une politique de confidentialité est considérée comme étant protégée par la confidentialité.
Budgets de confidentialité. Lorsque les analystes interrogent une table protégée par la confidentialité, vous pouvez gérer les budgets de confidentialité associés à ces analystes.
Domaines de confidentialité. Vous devez définir un domaine de confidentialité pour les colonnes de faits et de dimensions dans une table ou une vue protégée par la confidentialité.

Limitations

Vous ne pouvez pas attribuer une politique de confidentialité et une politique d’agrégation ou de masquage à la même table ou vue.
Outre l’interrogation de l”intervalle de bruit, les analystes ne savent pas s’ils interrogent une table protégée par la confidentialité. Le fournisseur de données doit donc les informer que les résultats de la requête contiennent du bruit.
Un fournisseur de données ne peut pas surveiller la perte de confidentialité subie par les analystes exécutant des requêtes dans un autre compte.
L’application de plusieurs politiques de confidentialité à une table n’est actuellement pas prise en charge. Pour cette raison, il n’est pas possible de protéger plusieurs entités avec une confidentialité différentielle au niveau de l’entité dans une seule table.
Les requêtes sur les tables répliquées ou clonées qui ont une politique de confidentialité associée à une clé d’entité sont actuellement bloquées.

À propos de la protection de la confidentialité au niveau de l’entité¶

Une entité fait référence à une classe de sujets de données qui doivent être protégés, par exemple des personnes, des organisations ou des lieux. Si chaque entité individuelle apparaissait sur une seule ligne, la confidentialité au niveau des lignes suffirait à protéger leurs identités. Toutefois, si des données appartenant à une entité individuelle apparaissent sur plusieurs lignes (par exemple, dans des données transactionnelles), la confidentialité différentielle doit être configurée pour que la confidentialité au niveau de l’entité protège correctement chaque entité.

Pour assurer la confidentialité au niveau de l’entité, Snowflake vous permet de spécifier quels attributs peuvent être utilisés pour identifier une entité (une clé d’entité). Cela permet à Snowflake d’identifier tous les enregistrements qui appartiennent à une entité particulière au sein d’un ensemble de données. Par exemple, si la clé de l’entité est définie comme la colonne email, Snowflake peut déterminer que tous les enregistrements contenant email=joe.smith@example.com appartiennent à la même entité.

Dans la plupart des cas, la confidentialité au niveau de l’entité est préférée à la confidentialité au niveau des lignes, mais la confidentialité au niveau des lignes peut être une bonne solution pour une table si les conditions suivantes sont vraies :

Aucune colonne du tableau n’identifie de manière unique les entités. La confidentialité au niveau de l’entité nécessite une colonne d’identification.
Chaque entité individuelle n’apparaît qu’une seule fois.
La table ne sera pas utilisée dans une jointure. Les jointures avec des tables protégées par la confidentialité au niveau des lignes sont possibles, mais ont des limites.

Vous choisissez d’implémenter la confidentialité au niveau de l’entité ou au niveau de la ligne lors de l’attribution d’une politique de confidentialité à une table ou à une vue. Pour plus d’informations, voir Attribuer une politique de confidentialité. Si vous choisissez de mettre en œuvre la confidentialité au niveau de l’entité, les données doivent également répondre aux exigences structurelles pour garantir que l’identifiant de l’entité est utilisé correctement.

Astuce

Si vous souhaitez protéger deux tables distinctes avec la même politique de confidentialité, mais qu’elles n’ont pas les mêmes valeurs de clé d’entité, vous pouvez créer une nouvelle table qui mappe les deux colonnes d’identification, créer une vue qui joint deux des tables et appliquer la politique de confidentialité à la vue. Par exemple, vous pouvez utiliser cette stratégie si la clé d’entité dans une table est email et user_id dans une autre table, mais que les deux font référence aux mêmes entités.

Exigences structurelles pour la confidentialité au niveau de l’entité¶

La structure des données protégées par la confidentialité différentielle au niveau de l’entité doit être conforme à certaines exigences. Ces exigences doivent être respectées pour que Snowflake puisse suivre avec précision la perte de confidentialité associée aux entités.

Vous devez structurer vos données pour répondre à ces exigences avant d’appliquer des politiques de confidentialité pour mettre en œuvre la confidentialité différentielle. Snowflake ne peut pas déterminer si les données sont conformes à ces exigences structurelles, car elles concernent la signification des données et non la mise en œuvre de la confidentialité différentielle. Par exemple, si les clés d’entité de deux tables différentes sont toutes deux définies sur la colonne user_id, mais que l’une des colonnes contient des valeurs pour un identifiant numérique tandis que l’autre colonne contient des adresses e-mail, Snowflake ne peut pas lier correctement les informations d’entité entre les deux tables.

Pour garantir la confidentialité au niveau de l’entité, vos données doivent être conformes aux exigences suivantes :

Chaque ligne appartient à un seul individu au sein d’une entité — À titre d’exemple, supposons qu’une table contienne des utilisateurs et des ménages. Si l’entité qui doit être protégée est constituée des utilisateurs, le tableau ne peut pas être structuré de telle sorte que chaque ligne corresponde à un foyer et que tous les utilisateurs de ce foyer soient capturés dans d’autres colonnes. Vous devrez restructurer la table pour qu’il n’y ait qu’une seule ligne par utilisateur, avec une colonne household_id pour indiquer à quel foyer appartient un utilisateur.
Identifiant d’entité cohérent dans toutes les tables — Vous pouvez créer une politique de confidentialité qui représente la protection nécessaire pour une seule entité, puis appliquer cette politique à plusieurs tables contenant des informations sur l’entité. Lorsque vous attribuez la politique de confidentialité à chaque table, vous devez spécifier la colonne qui identifie de manière unique l’entité (c’est-à-dire la clé d’entité). La valeur qui identifie de manière unique une entité dans ces colonnes de clé d’entité doit être la même. Par exemple, supposons que la colonne email est la clé d’entité de deux tables contenant des informations sur une entité. Si l’adresse e-mail d’une entité est joe@company.com dans une table, l’adresse e-mail dans l’autre table doit également être joe@company.com.

Identifiant d’entité dans toutes les tables — Bien que cela ne soit pas obligatoire pour implémenter la confidentialité au niveau de l’entité, vous pouvez permettre aux analystes de minimiser le bruit dans les jointures de requête en incluant l’identifiant d’entité dans toutes les tables liées à une entité. Dans certains cas, vous devrez peut-être dénormaliser la colonne clé d’entité pour répondre à cette exigence. Par exemple, supposons que vous ayez les tables suivantes où l’entité correspond aux clients :

Table	Description
`customer`	Répertoire des clients, où chaque ligne correspond à un client et comporte un `customer_id`.
`transactions`	Transactions des clients, où chaque ligne est une transaction et comporte un `transaction_id`. Chaque client peut avoir plusieurs transactions.
`transaction_lines`	Articles uniques qui ont été achetés lors d’une transaction. Il peut y avoir plusieurs lignes dans une seule transaction.

Selon les meilleures pratiques de normalisation, la table transaction_lines inclurait l’identificateur transaction_id mais pas customer_id. La table transaction_lines serait liée à la table transactions, qui pourrait ensuite être liée à la table customers avec customer_id.

Cependant, pour une confidentialité différentielle, vous souhaiterez probablement optimiser les données pour l’analyste en ajoutant l’identificateur customer_id à la table transaction_lines. Cela permet à l’analyste de minimiser le bruit en incluant customer_id dans la clé de jointure lors de la jonction de la table transaction_lines avec une autre table.

Interactions avec les fonctionnalités Snowflake¶

Cette section décrit comment les objets de confidentialité différentiels suivants interagissent avec d’autres fonctionnalités Snowflake. Elle examine l’effet sur les politiques, les budgets et les domaines de confidentialité.

Réplication¶

Pour les considérations relatives à la réplication des politiques de confidentialité ainsi que des tables et vues protégées par la confidentialité, voir Politiques de confidentialité.

Note

Il existe une limitation actuelle lors de l’interrogation de tables répliquées qui ont une politique de confidentialité associée à une clé d’entité. Les requêtes sur ces tables sont bloquées jusqu’à ce que la limitation soit supprimée.

Exécution automatique inter-cloud¶

Gardez les points suivants à l’esprit lorsque vous utilisez l’exécution automatique inter-cloud pour répliquer un produit de données :

Les administrateurs du compte sur lequel le produit de données a été répliqué ne peuvent pas ajuster le budget de confidentialité.
Les administrateurs ne peuvent pas utiliser un seul compte pour visualiser la perte de confidentialité subie dans toutes les régions.

Clonage¶

Pour connaître les effets du clonage de tables et de vues protégées par la confidentialité, voir Clonage et confidentialité différentielle.

Note

Il existe une limitation actuelle lors de l’interrogation de tables clonées qui ont une politique de confidentialité associée à une clé d’entité. Les requêtes sur ces tables sont bloquées jusqu’à ce que la limitation soit supprimée.

Vues créées d’après un objet de base protégé par la confidentialité¶

Vous pouvez créer une vue d’après une table ou une vue protégée par la confidentialité. Cependant, les domaines de confidentialité de la table ou de la vue de base ne sont pas hérités. Par conséquent, notez ce qui suit :

Les domaines de confidentialité doivent être définis sur les colonnes de la nouvelle vue.
L’ajustement du domaine de confidentialité de la table de base n’affecte pas les domaines de confidentialité de la vue créée d’après celui-ci.

Vues matérialisées¶

Vous pouvez attribuer une politique de confidentialité à une vue matérialisée pour la protéger.

D’autres interactions entre les politiques de confidentialité et les vues matérialisées incluent ce qui suit :

Vous ne pouvez pas créer une vue matérialisée basée sur une table ou une vue protégée par la confidentialité.
Vous ne pouvez pas attribuer une politique de confidentialité à une table si elle est référencée comme table de base d’une vue matérialisée.

UDFs¶

Les analystes ne peuvent pas utiliser une fonction définie par l’utilisateur pour interroger une table protégée par la confidentialité.

Flux¶

Vous ne pouvez pas interroger un flux basé sur une table protégée par la confidentialité.

Vous ne pouvez pas attribuer une politique de confidentialité à un flux.

Autres politiques¶

Les politiques de confidentialité interagissent avec les autres politiques Snowflake comme suit :

Politiques de masquage: Vous ne pouvez pas attribuer une politique de confidentialité et une politique de masquage à la même table ou vue.
Politiques d’accès aux lignes: Les politiques d’accès aux lignes ont priorité sur une politique de confidentialité. Si une ligne est bloquée par la politique d’accès aux lignes, elle n’est pas incluse dans les résultats de la requête différentiellement privée.
Politiques de projection: La protection avec une politique de projection d’une table bénéficiant d’une politique de confidentialité et de ses colonnes n’est actuellement pas prise en charge. Bien que vous puissiez attribuer les politiques de cette manière, les requêtes sur la table échoueront.
Politiques d’agrégation: Vous ne pouvez pas attribuer une politique de confidentialité et une politique d’agrégation à la même table ou vue.

Tables dynamiques¶

Vous ne pouvez pas créer une table dynamique lorsque la table source référencée est protégée par la confidentialité.

Vous pouvez attribuer une politique de confidentialité à une table référencée par une table dynamique existante ; cependant, une fois la politique attribuée, la table dynamique ne s’actualisera plus.

Tables externes¶

Vous pouvez attribuer une politique de confidentialité à une table externe. Si un analyste tente une agrégation d’après une colonne VARIANT, la requête échoue. Cependant, si un analyste tente une agrégation d’après une colonne virtuelle, la requête réussit.

Time Travel¶

Pour Time Travel, lorsqu’une version précédente d’une table est copiée en tant que nouvelle table, la version actuelle d’un domaine de confidentialité est utilisée pour la table car Snowflake ne stocke pas les versions précédentes du domaine de confidentialité dans les métadonnées de la table.