Comprendre les politiques relatives aux tables de clean room¶

Les salles blanches peuvent mettre en œuvre des politiques de données pour contrôler la manière dont les données sont utilisées par les collaborateurs. Celles-ci s’ajoutent aux politiques de table Snowflake définies sur les tables sous-jacentes liées à la salle blanche.

Chaque collaborateur d’une salle blanche peut définir des politiques sur ses propres données. Vos politiques ne s’appliquent qu’aux demandes provenant d’autres utilisateurs ; elles ne s’appliquent pas à vos propres requêtes. Par exemple, si votre politique de jointure autorise uniquement les jointures sur la colonne A, les autres utilisateurs sont limités à la jointure sur la colonne A, mais vous pouvez effectuer des jointures sur n’importe laquelle de vos colonnes.

Les politiques Clean room peuvent être paramétrées à l’aide de l’API ou l’UI de la clean room.

Pour mettre en œuvre des contrôles de politique, les conditions suivantes doivent être remplies :

Le propriétaire des données doit définir une politique dans sa salle blanche. Vous pouvez définir des politiques à l’aide de l’API ou de l’UI. Chaque type de politique est défini séparément. La salle blanche implémente nativement des politiques de colonnes, des politiques de lignes et des politiques d’activation. Les politiques de salle blanche ne sont pas cumulables : lorsque vous définissez une politique de salle blanche, toutes les valeurs précédentes sont supprimées.
```
-- Sets a join policy on column HASHED_EMAIL.
CALL samooha_by_snowflake_local_db.provider.set_join_policy(
  'my_provider_cleanroom',
  ['my_db.my_sch.T1:HASHED_EMAIL']);

-- Replaces the previous join policy. Now the only column in the join policy is AGE_BND.
CALL samooha_by_snowflake_local_db.provider.set_join_policy(
  'my_provider_cleanroom',
  ['my_db.my_sch.T1:AGE_BAND']);
```
Copy
Le modèle doit vérifier la politique à l’endroit approprié dans celui-ci. Une politique de salle blanche n’est vérifiée que si le filtre de politique approprié est appliqué à la colonne du modèle. Si vous définissez une politique de salle blanche pour protéger vos données, vous devez examiner le modèle pour confirmer qu’il applique vos politiques comme prévu. Le modèle suivant vérifie si col1 est autorisé par la politique de colonnes du propriétaire des données :
```
SELECT
  IDENTIFIER( {{ col1 | column_policy }} )
FROM {{ source_table[0] }} AS c;
```
Copy
Le modèle suivant ne vérifie pas si col1 dispose d’une politique de salle blanche :
```
SELECT
  IDENTIFIER( {{ col1 }})
FROM {{ source_table[0] }} AS c;
```
Copy
Les salles blanches prennent en charge un filtre de modèle différent pour chaque type de politique. Toutefois, la sémantique du filtre n’est pas vérifiée, seule la présence de la colonne dans la politique pour ce type de filtre est vérifiée. Par exemple, dans l’extrait suivant, la politique de jointure est vérifiée pour col1, même si la colonne n’est pas jointe. Si col1 figure dans la politique de jointure du propriétaire de données, la requête peut aboutir ; si col1 ne figure pas dans la politique de jointure du propriétaire de données, la requête sera bloquée.
```
SELECT
  IDENTIFIER( {{ col1 | join_policy }})
FROM {{ source_table[0] }} AS c;
```
Copy

Note

Les contrôles de la politique de colonnes sont effectués lorsque le modèle JinjaSQL est analysé. Les requêtes comportant des caractères génériques peuvent ne pas être prises en compte par ces contrôles, et il convient de faire preuve de discernement lors de la conception du modèle d’analyse. Si certaines colonnes ne doivent jamais faire l’objet d’une requête, envisagez de créer une vue de votre table source qui élimine ces colonnes sensibles, et créez un lien dans cette vue à la place.

Politiques de Snowflake dans les salles blanches¶

Lorsque vous liez des tables à une salle blanche, toutes les politiques de tables Snowflake sur les tables sources sont appliquées dans les tables liées de la salle blanche, mais ces politiques ne sont pas nécessairement signalées par l’API ou l’UI de salle blanche. Par exemple, une politique de jointure Snowflake continue d’être appliquée dans la salle blanche, mais cette politique de jointure n’est pas visible en appelant consumer.view_provider_join_policy ou consumer.view_join_policy. Par conséquent, vous devez soit supprimer les politiques des tables liées sous-jacentes, soit créer des politiques équivalentes en salle blanche (si elles existent), soit communiquer clairement l’existence de ces politiques à vos collaborateurs afin que leurs requêtes n’échouent pas ou ne se comportent pas de manière inattendue (« pourquoi ne puis-je pas effectuer de jointure sur cette colonne ?).

Toute modification des politiques Snowflake dans les tables sources est automatiquement propagée aux vues liées dans la salle blanche.

Les politiques de confidentialité de Snowflake empêchent la création d’une vue à partir d’une table protégée, de sorte que vous ne pouvez pas créer de liens dans les tables qui ont des politiques de confidentialité.

Les politiques suivantes peuvent être appliquées directement dans une salle blanche :

Politiques de jointure¶

Définissez une politique de jointure pour indiquer quelles colonnes de vos données peuvent être jointes par n’importe quel modèle dans la salle blanche. (Les politiques de jointure de Snowflake, en revanche, spécifient quelles colonnes doivent être jointes.) Les politiques de jointure s’appliquent à tous les modèles de la salle blanche.

Une colonne ne peut pas être à la fois dans une politique de jointure et dans une politique de colonnes, mais une colonne peut être à la fois dans une politique de jointure et dans une politique d’activation.

Mise en œuvre d’une politique de jonction¶

Les politiques de jointure de salle blanche sont appliquées à une colonne si le modèle applique le filtre join_policy ou join_and_column_policy à la colonne.

Si un modèle vérifie une politique de jointure pour une colonne et que la salle blanche ne dispose d’aucune politique de jointure définie, ou si la colonne ne figure pas dans la politique de jointure, la requête sera bloquée.

Le code suivant montre comment définir des politiques de jointure en tant que fournisseur ou consommateur. N’oubliez pas que les politiques s’appliquent uniquement aux requêtes exécutées par un autre compte.

-- Set join policies on two columns in a clean room where you are a provider.
CALL samooha_by_snowflake_local_db.provider.set_join_policy(
  'my_provider_cleanroom',
  ['SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:HASHED_EMAIL', 'MYDB.MYSCH.EXPOSURES:HASHED_EMAIL']);

-- Set join policies on two columns in a clean room where you are a consumer.
CALL samooha_by_snowflake_local_db.consumer.set_join_policy(
  'my_consumer_cleanroom',
  ['SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:HASHED_EMAIL', 'MYDB.MYSCH.EXPOSURES:HASHED_EMAIL']);

Copy

Les procédures suivantes permettent de voir ou de gérer les politiques de jonction dans le code :

consumer.set_join_policy
consumer.view_provider_join_policy
consumer.view_join_policy
provider.view_join_policy
provider.set_join_policy

Politiques des colonnes¶

Définissez une politique de colonnes pour indiquer lesquelles de vos colonnes peuvent être projetées dans les résultats d’analyse à partir d’un modèle spécifique. Les politiques de colonnes sont appliquées à des modèles spécifiques dans une salle blanche spécifique.

Une colonne ne peut pas figurer à la fois dans une politique de jointure et dans une politique de colonne. Une colonne peut faire partie à la fois d’une politique d’activation et d’une politique de colonne.

Mise en œuvre d’une politique des colonnes¶

Les politiques de colonnes de salle blanche sont appliquées à une colonne uniquement si le modèle utilise le filtre column_policy ou join_and_column_policy.

Si une salle blanche vérifie une politique de colonne pour une colonne et que la colonne ne figure pas dans la politique de colonne, ou si la salle blanche n’a pas de politique de colonne, la requête sera bloquée.

Le code suivant montre comment définir des politiques de colonnes pour trois colonnes lorsqu’on y accède par le modèle prod_overlap_analysis. L’exemple montre comment définir la politique à la fois en tant que fournisseur et en tant que consommateur. N’oubliez pas que les politiques s’appliquent uniquement aux requêtes exécutées par un autre compte.

-- Set column policy on prod_overlap_analysis template in a clean room where
-- you are a provider.
call samooha_by_snowflake_local_db.provider.set_column_policy(
  'my_provider_cleanroom',
  ['prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:STATUS',
   'prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:AGE_BAND',
   'prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:DAYS_ACTIVE']);

-- Set column policy on prod_overlap_analysis template in a clean room where
-- you are a consumer.
call samooha_by_snowflake_local_db.consumer.set_column_policy(
  'my_consumer_cleanroom',
  ['prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:STATUS',
   'prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:AGE_BAND',
   'prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:DAYS_ACTIVE']);

Copy

Les procédures suivantes permettent de voir ou de gérer les politiques de colonne dans le code :

consumer.set_column_policy
consumer.view_column_policy
consumer.view_provider_column_policy
provider.set_column_policy
provider.view_column_policy

Politiques d’activation¶

Définissez une politique d’activation pour indiquer lesquelles de vos colonnes peuvent être activées par un modèle d’activation. L’activation enregistre les résultats de la requête dans une table du compte Snowflake du fournisseur ou du consommateur, ou dans un connecteur d’activation tiers.

Une colonne peut faire partie d’une politique d’activation comme de toute autre politique.

Mise en œuvre d’une politique d’activation¶

Les politiques d’activation peuvent être paramétrées dans les UI de clean rooms si le modèle autorise l’activation.

Les politiques d’activation sont définies pour une colonne spécifique dans un modèle spécifique.

Les politiques d’activation sont appliquées à une colonne uniquement si le modèle applique le filtre activation_policy à la colonne.

Le code suivant montre comment définir une politique d’activation pour permettre l’activation des colonnes HASHED_EMAIL et REGION_CODE dans une salle blanche. Cette politique concerne tous les utilisateurs et tous les modèles d’activation de la salle blanche. Il existe des procédures équivalentes pour les fournisseurs et les consommateurs dans une salle blanche. Appelez la procédure qui reflète votre rôle dans la salle blanche.

-- Set activation policy on prod_overlap_analysis template in a clean room where you are a provider
call samooha_by_snowflake_local_db.provider.set_activation_policy('my_cleanroom', [
    'prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:HASHED_EMAIL',
    'prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:REGION_CODE' ]);

-- Set activation policy on prod_overlap_analysis template in a clean room where you are a consumer
call samooha_by_snowflake_local_db.consumer.set_activation_policy('my_cleanroom', [
    'prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE_NAME.DEMO.CUSTOMERS:HASHED_EMAIL',
    'prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE_NAME.DEMO.CUSTOMERS:REGION_CODE' ]);

Copy

Les procédures suivantes permettent de gérer les politiques d’activation dans le code :

consumer.set_activation_policy
provider.set_activation_policy

Politiques d’agrégation¶

Les politiques d’agrégation exigent que toutes les requêtes sur une table contiennent des agrégations (GROUP BY, COUNT, et d’autres fonctions), et spécifient également un nombre minimum de lignes par groupe de résultats, sinon le groupe sera omis dans les résultats.

Clean rooms ne dispose pas de sa propre implémentation des politiques d’agrégation ; pour appliquer des contraintes d’agrégation à vos données liées, vous devez soit appliquer une politique d’agrégation à la table source, soit implémenter des contraintes d’agrégation dans votre modèle.

Certains modèles fournis par Snowflake utilisent les paramètres threshold et threshold_value établis pour un utilisateur ou un modèle. Ces valeurs peuvent être modifiées dans les UI de clean rooms, ou en appelant provider.add_consumers ou provider/consumer.set_privacy. Si elles sont paramétrées pour un consommateur, vous pouvez accéder à ces valeurs dans votre modèle.