Utilisation des politiques de confidentialité pour la confidentialité différentielle¶
Cette rubrique décrit comment un fournisseur de données utilise les politiques de confidentialité pour mettre en œuvre la confidentialité différentielle.
À propos des politiques de confidentialité¶
Avec la confidentialité différentielle, Snowflake doit vérifier chaque requête pour déterminer si elle dépassera le budget de confidentialité associé à l’utilisateur exécutant la requête. Les politiques de confidentialité rendent cela possible. Un fournisseur de données crée une politique de confidentialité qui associe les utilisateurs à des budgets de confidentialité, puis attribue cette politique aux tables et aux vues pour les protéger en termes de confidentialité.
Lorsqu’un analyste exécute une requête sur une table avec une politique de confidentialité, Snowflake évalue le corps de la politique et effectue l’une des actions suivantes :
Si la politique associe l’utilisateur à un budget de confidentialité, Snowflake s’assure que la perte de confidentialité due à la requête ne dépasse pas ce budget de confidentialité. Si la requête est correctement exécutée, Snowflake ajoute la perte de confidentialité due à la requête à la perte de confidentialité cumulée pour l’utilisateur afin que les requêtes ultérieures ne dépassent pas le budget de confidentialité.
Si la politique indique que l’utilisateur peut interroger la table sans restriction, les résultats ne contiennent pas de bruit, et Snowflake ne suit pas la perte de confidentialité due à la requête.
Meilleures pratiques en matière de politique de confidentialité¶
Vous pouvez créer une politique de confidentialité unique pour protéger une seule entité, puis attribuer la politique de confidentialité à toutes les tables et vues contenant des informations pour cette entité. Cela regroupe tous les budgets de confidentialité de cette entité sous une seule politique de confidentialité. Vous n’avez pas besoin de créer des politiques de confidentialité distinctes pour chaque table et vue.
Utilisation des politiques de confidentialité¶
La mise en œuvre de la confidentialité différentielle pour un schéma est un processus en trois étapes :
Créez une politique de confidentialité qui associe les budgets de confidentialité aux utilisateurs en fonction de conditions telles que le nom, le rôle ou le compte.
Attribuez cette politique de confidentialité à une table ou une vue pour garantir qu’une requête ou un ensemble de requêtes sur les données ne dépasse pas le budget de confidentialité associé à l’utilisateur qui exécute la requête.
Accordez des privilèges SELECT sur les données protégées par la confidentialité. N’accordez pas de privilèges avant d’attribuer une politique de confidentialité à la table ou à la vue, car l’analyste aurait un accès complet aux données.
Lorsque vous gérez votre environnement de confidentialité différentielle, vous pouvez également :
remplacer une politique de confidentialité qui est actuellement attribué à une table ou à une vue avec une autre politique ;
détacher une politique de confidentialité d’une table ou d’une vue.
Créer une politique de confidentialité¶
La syntaxe la plus basique pour créer une nouvelle politique de confidentialité est la suivante :
CREATE PRIVACY POLICY <name>
AS ( ) RETURNS PRIVACY_BUDGET -> <body>
Où :
name
est le nom de la politique de confidentialité.AS ( ) RETURNS PRIVACY_BUDGET
est la signature et le type de retour de la politique. La signature n’accepte aucun argument et le type de retour est PRIVACY_BUDGET, qui est un type de données interne. Toutes les politiques de confidentialité ont la même signature et le même type de retour.body
est une expression SQL qui détermine si la politique de confidentialité renvoie un budget de confidentialité, et si c’est le cas, lequel.L’expression SQL du corps appelle deux fonctions pour contrôler la valeur de retour de la politique :
NO_PRIVACY_POLICY
Utilisez l’expression du corps pour appeler la fonction NO_PRIVACY_POLICY lorsque vous souhaitez qu’une requête ait un accès illimité à la table ou à la vue à laquelle la politique de confidentialité est affectée.
PRIVACY_BUDGET
Utilisez l’expression du corps pour appeler la fonction PRIVACY_BUDGET lorsque vous souhaitez renvoyer un budget de confidentialité à partir de la politique.
Pour la syntaxe complète des fonctions NO_PRIVACY_POLICY et PRIVACY_BUDGET, voir CREATE PRIVACY POLICY.
Exemples de politiques de confidentialité¶
- Budget unique de confidentialité sans conditions
Créez une politique de confidentialité
my_priv_policy
qui renvoie toujours un budget de confidentialité nomméanalysts
:CREATE PRIVACY POLICY my_priv_policy AS ( ) RETURNS PRIVACY_BUDGET -> PRIVACY_BUDGET(BUDGET_NAME=> 'analysts');
- Politique de confidentialité conditionnelle
Créer une politique de confidentialité
my_priv_policy
qui donne auxadmin
un accès illimité à la table ou la vue protégée par la confidentialité tout en associant tous les autres utilisateurs au budget de confidentialitéanalysts
:CREATE PRIVACY POLICY my_priv_policy AS () RETURNS PRIVACY_BUDGET -> CASE WHEN CURRENT_USER() = 'ADMIN' THEN NO_PRIVACY_POLICY() ELSE PRIVACY_BUDGET(BUDGET_NAME => 'analysts') END;
- Politique de confidentialité conditionnelle pour le partage entre comptes
Créez une politique de confidentialité
my_priv_policy
qui fait ce qui suit :Donne aux
admin
un accès illimité à la table ou la vue protégée par la confidentialité.Associe le budget de confidentialité
analysts
aux utilisateurs du même compte.Nomme le budget de confidentialité associé aux utilisateurs de comptes externes afin qu’il puisse être facilement identifié. L’espace de noms des budgets de confidentialité est automatiquement associé à un compte externe spécifique, mais l’utilisation d’un schéma de dénomination descriptif peut aider à gérer les budgets de confidentialité.
CREATE PRIVACY POLICY my_priv_policy AS () RETURNS PRIVACY_BUDGET -> CASE WHEN CURRENT_USER() = 'ADMIN' THEN NO_PRIVACY_POLICY() WHEN CURRENT_ACCOUNT() = 'YE74187' THEN PRIVACY_BUDGET(BUDGET_NAME => 'analysts') ELSE PRIVACY_BUDGET(BUDGET_NAME => 'external.' || CURRENT_ACCOUNT()) END;
Utilisation des fonctions contextuelles dans le corps de la politique¶
Vous pouvez inclure les fonctions de contexte dans le corps d’une politique de confidentialité afin que son comportement dépende du contexte dans lequel la requête différentiellement privée est exécutée.
Vous pouvez utiliser les fonctions contextuelles suivantes dans le corps d’une politique de confidentialité :
Fonction contextuelle |
Description |
---|---|
Renvoie le localisateur de compte utilisé pour la session actuelle de l’utilisateur. |
|
Renvoie la base de données qui contient la table protégée par la politique de confidentialité. |
|
Renvoie le nom de l’organisation utilisée pour la session en cours. |
|
Renvoie le nom du rôle utilisé pour la session en cours. |
|
Renvoie le schéma qui contient la table protégée par la politique de confidentialité. |
|
Renvoie le nom de l’utilisateur qui exécute la requête. |
|
Renvoie le nom du rôle d’exécution. |
|
Renvoie le nom du partage qui a directement accédé à la table ou à la vue dans laquelle la fonction INVOKER_SHARE est invoquée. |
Astuce
Les fonctions contextuelles telles que CURRENT_USER renvoient des chaînes, de sorte que les comparaisons effectuées à l’aide de ces fonctions sont sensibles à la casse. Vous pouvez utiliser LOWER pour convertir les chaînes en minuscules si vous souhaitez effectuer une comparaison insensible à la casse.
Modifier une politique de confidentialité¶
Utilisez la commande ALTER PRIVACY POLICY pour modifier une politique de confidentialité. Vous pouvez renommer la politique, modifier son corps ou modifier un commentaire.
Par exemple, pour remplacer le corps existant d’une politique de confidentialité my_priv_policy
avec un nouveau corps qui revient toujours à un budget external_analysts
, exécutez :
ALTER PRIVACY POLICY my_priv_policy SET BODY ->
PRIVACY_BUDGET(BUDGET_NAME => 'external_analysts');
Attribuer une politique de confidentialité¶
Une politique de confidentialité peut être appliquée à une ou plusieurs tables ou vues pour les protéger avec une confidentialité différentielle. Une table ou une vue ne peut avoir qu’une seule politique de confidentialité qui lui est attribuée.
Utilisez la clause ADD PRIVACY POLICY d’une commande ALTER TABLE ou ALTER VIEW pour attribuer une politique de confidentialité à la table ou à la vue. La syntaxe est la suivante :
ALTER { TABLE | [ MATERIALIZED ] VIEW } <name> ADD PRIVACY POLICY <policy_name> { NO ENTITY KEY | ENTITY KEY ( <column_name> ) }
Où :
name
spécifie le nom de la table ou de la vue.policy_name
spécifie le nom de la politique de confidentialité.column_name
spécifie la clé d’entité pour la table ou la vue. La clé d’entité est une colonne qui identifie de manière unique une entité dans la table ou la vue.
Dans la plupart des cas, vous souhaiterez définir une clé d’entité afin de mettre en œuvre la confidentialité au niveau de l’entité, bien que vous puissiez utiliser la clause NO ENTITY KEY pour protéger des lignes individuelles sans tenir compte du fait que les données appartenant à une entité pourraient exister dans plusieurs lignes. Pour plus d’informations, voir À propos de la protection de la confidentialité au niveau de l’entité.
Par exemple, pour attribuer la politique my_priv_policy
à la table t1
où la clé d’entité est la colonne email
, exécutez :
ALTER TABLE t1 ADD PRIVACY POLICY my_priv_policy ENTITY KEY (email);
Remplacer une politique de confidentialité ou une clé d’entité¶
La méthode recommandée pour remplacer une politique de confidentialité ou une clé d’entité consiste à utiliser à la fois les clauses ADD et DROP dans la même commande ALTER TABLE ou ALTER VIEW. Cela vous permet d’effectuer le changement de manière atomique, car les deux opérations ont lieu dans la même transaction, sans faille de protection.
Pour conserver la même politique mais modifier la clé d’entité, vous devez supprimer la politique, puis l’ajouter à nouveau avec la nouvelle clé d’entité.
Par exemple, pour attribuer une nouvelle politique de confidentialité à une table qui est déjà protégée par une politique de confidentialité :
ALTER TABLE finance.accounting.customers
DROP PRIVACY POLICY priv_policy_1,
ADD PRIVACY POLICY priv_policy_2 ENTITY KEY (email);
Vous pouvez également détacher la politique de confidentialité d’une table ou d’une vue dans une instruction, puis définir une nouvelle politique sur la table ou la vue dans une autre instruction. Si vous sélectionnez cette méthode, la table n’est pas protégée par une politique de confidentialité entre le détachement d’une politique et l’affectation d’une autre. Une requête pourrait potentiellement accéder à des données sensibles pendant cette période si les utilisateurs ont encore des privilèges SELECT sur les données.
Détacher une politique de confidentialité¶
Utilisez la clause DROP PRIVACY POLICY d’une commande ALTER TABLE ou ALTER VIEW pour détacher une politique de confidentialité d’une table ou d’une vue. Après avoir exécuté cette commande, la table ou la vue n’est plus protégée par la confidentialité. La syntaxe est la suivante :
ALTER { TABLE | [ MATERIALIZED ] VIEW } <name> DROP PRIVACY POLICY <policy_name>
Où :
name
spécifie le nom de la table ou de la vue.policy_name
spécifie le nom de la politique de confidentialité.
Par exemple, pour détacher la politique de confidentialité my_priv_policy
de la table finance.accounting.customers
:
ALTER TABLE finance.accounting.customers DROP PRIVACY POLICY my_priv_policy;
Surveiller les politiques de confidentialité¶
Pour aider à surveiller l’utilisation des politiques de confidentialité, vous pouvez répertorier toutes les politiques de confidentialité de votre compte, déterminer quelles tables et vues sont protégées par une politique de confidentialité particulière ou répertorier toutes les politiques actuellement attribuées à une table ou une vue.
Répertorier toutes les politiques de confidentialité¶
Vous pouvez utiliser la vue PRIVACY_POLICIES dans le schéma Account Usage de la base de données partagée SNOWFLAKE. Cette vue est un catalogue de toutes les politiques de confidentialité de votre compte Snowflake. Par exemple :
SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.PRIVACY_POLICIES ORDER BY POLICY_NAME;
Identifier des références aux politiques de confidentialité¶
La fonction de table Information Schema POLICY_REFERENCES peut identifier les tables et les vues protégées par les politiques de confidentialité. Il existe deux options syntaxiques différentes :
Renvoie une ligne pour chaque objet (c’est-à-dire une table ou une vue) pour lequel la politique de confidentialité spécifiée est définie :
USE DATABASE my_db; USE SCHEMA information_schema; SELECT policy_name, policy_kind, ref_entity_name, ref_entity_domain, ref_column_name, ref_arg_column_names, policy_status FROM TABLE(information_schema.policy_references(policy_name => 'my_db.my_schema.privpolicy'));
Renvoie une ligne pour chaque politique affectée à la table nommée
my_table
. Utilisez la colonne POLICY_KIND pour identifier quelles politiques sont des politiques de confidentialité.USE DATABASE my_db; USE SCHEMA information_schema; SELECT policy_name, policy_kind, ref_entity_name, ref_entity_domain, ref_column_name, ref_arg_column_names, policy_status FROM TABLE(information_schema.policy_references(ref_entity_name => 'my_db.my_schema.my_table', ref_entity_domain => 'table'));
Privilèges et commandes¶
Les sous-sections suivantes fournissent des informations facilitant la gestion des politiques de confidentialité.
Privilèges des politiques de confidentialité¶
Snowflake prend en charge les privilèges suivants sur l’objet d’une politique de confidentialité.
Notez que l’exploitation d’un objet dans un schéma requiert également le privilège USAGE sur la base de données et le schéma parents.
Privilège |
Utilisation |
---|---|
APPLY |
Vous permet d’attribuer une politique de confidentialité à une table ou à une vue ou d’en détacher une. |
OWNERSHIP |
Nécessaire pour modifier la plupart des propriétés d’une politique de confidentialité. La propriété de la politique de confidentialité peut être transférée, ce qui confère un contrôle total sur la politique de confidentialité. |
Référence DDL des politiques de confidentialité¶
Snowflake prend en charge les DDL suivants pour créer et gérer les politiques de confidentialité.
Résumé des commandes, des opérations et des privilèges DDL¶
Le tableau suivant résume la relation entre les privilèges des politiques de confidentialité et les opérations DDL.
Notez que l’exploitation d’un objet dans un schéma requiert également le privilège USAGE sur la base de données et le schéma parents.
Fonctionnement |
Privilège requis |
---|---|
Créer une politique de confidentialité |
Un rôle avec le privilège CREATE PRIVACY POLICY dans le même schéma. |
Modifier une politique de confidentialité |
Le rôle avec le privilège OWNERSHIP sur la politique de confidentialité. |
Décrire la politique de confidentialité |
Un des éléments suivants :
|
Supprimer la politique de confidentialité |
Un rôle avec le privilège OWNERSHIP sur la politique de confidentialité. |
Affichez les politiques de confidentialité. |
Un des éléments suivants :
|
Attribuez une politique de confidentialité à une table ou à une vue, ou détachez-en une. |
Un des éléments suivants :
|