Politiques de jointure

Une politique de jointure est un objet de niveau schéma qui contrôle l’exigence de jointure d’une table lors d’une requête. Lorsqu’une politique de jointure est appliquée à une table, les requêtes portant sur cette table nécessitent ou non une jointure. Lorsque des jointures sont exigées, elles peuvent être limitées à certaines colonnes de jointure.

Vous pouvez utiliser ce type de politique pour imposer des jointures pour les requêtes portant sur certaines tables et vues, afin de trouver des informations communes à des tables partagées. Une table ou une vue à laquelle une politique de jointure a été attribuée est dite protégée ou soumise à des contraintes de jointure.

Vue d’ensemble

Une fonctionnalité principale de Snowflake consiste à permettre le partage d’ensembles de données avec d’autres entités. Les politiques de jointure permettent à un fournisseur (propriétaire des données) d’exercer un contrôle sur ce qui peut être fait de ses données, même après qu’elles ont été partagées avec un consommateur. Plus précisément, le fournisseur peut exiger du consommateur d’une table qu’il joigne les données à une autre table plutôt que de récupérer les enregistrements d’une seule table. Cette exigence facilite le partage de données entre des partenaires à confiance limitée qui disposent d’ensembles de données communs. La sélection de données à partir d’une seule table n’est généralement pas utile ; des données significatives sont disponibles lorsque la table d’un propriétaire est jointe à une table similaire appartenant à un consommateur ou à un partenaire.

Après l’application de la politique de jointure à une table ou à une vue, une requête doit :

  • Joindre la table ou la vue à une autre table ou vue.

  • Spécifier un type de jointure pris en charge.

  • Spécifier une condition de jointure avec les colonnes de jointure autorisées.

Au moins une table ou une vue participant à la jointure doit être non protégée. Cette restriction empêche les attaquants de contourner la politique de jointure en joignant deux tables protégées qui sont partagées par la même organisation et dont les valeurs des clés correspondent.

Bien que les politiques de jointure contrôlent l’accès aux tables jointes, elles ne garantissent pas qu’un acteur malveillant ne puisse pas utiliser des requêtes soigneusement construites pour obtenir des données sensibles à partir d’une table soumise à des contraintes de jointure. Avec suffisamment de tentatives de requêtes, un acteur malveillant pourrait potentiellement contourner les exigences de jointure. Les politiques de jointure conviennent mieux aux partenaires et aux clients avec lesquels vous avez déjà un certain niveau de confiance. En outre, les fournisseurs doivent être vigilants quant à d’éventuelles utilisations abusives de leurs données (par exemple, en examinant l’historique des accès à leurs annonces).

Créer et mettre en œuvre des politiques de jointure

Pour créer et mettre en œuvre une politique de jointure :

  1. Créez la politique en elle-même.

  2. Appliquez la politique à une table ou à une vue nouvelle ou existante.

  3. Exécutez quelques requêtes pour vérifier le comportement attendu de la politique.

Ces étapes sont expliquées dans les sections suivantes.

Vous pouvez également vouloir modifier une politique existante et vérifier que le comportement attendu change.

Vous pouvez à tout moment consulter les politiques de jointure de votre compte en utilisant les commandes SHOW JOIN POLICIES et DESCRIBE JOIN POLICY. Pour connaître la définition réelle d’une politique, effectuez une requête sur la vue JOIN_POLICIES. Pour savoir quelles tables et quelles vues sont rattachées aux politiques, effectuez une requête sur la fonction de table de Information Schema POLICY_REFERENCES.

Pour obtenir des informations sur la gestion des politiques, y compris sur la définition d’un rôle personnalisé d’administration des politiques, voir Gérer les politiques de jointure.

Créer une politique de jointure

La forme la plus simple de politique de jointure exige que les utilisateurs joignent toujours une table ou une vue à une autre table ou vue. En d’autres termes, les requêtes portant sur une seule table, sans spécification de jointure, ne sont pas autorisées. Par exemple, créez une politique nommée jp1 :

CREATE JOIN POLICY jp1
  AS () RETURNS JOIN_CONSTRAINT -> JOIN_CONSTRAINT(JOIN_REQUIRED => TRUE);
Copy

Pour connaître la syntaxe complète de cette commande et sa fonction JOIN_CONSTRAINT, voir CREATE JOIN POLICY.

Appliquer une politique de jointure à une table ou à une vue

Après avoir créé une politique de jointure, vous la mettez en œuvre en l’affectant à une table ou à une vue spécifique :

  • Utilisez une commande ALTER TABLE ou ALTER VIEW si la table ou la vue existe déjà.

  • Utilisez une commande CREATE TABLE ou CREATE VIEW pour une nouvelle table ou vue.

Dans les deux cas, spécifiez le paramètre JOIN POLICY pour identifier la politique de jointure elle-même. Par exemple, la commande suivante affecte la politique jp à la table join_table :

CREATE OR REPLACE TABLE join_table (
  col1 INT,
  col2 VARCHAR,
  col3 NUMBER )
  JOIN POLICY jp1;
Copy

Facultativement, vous pouvez également spécifier le paramètre ALLOWED JOIN KEYS si vous souhaitez restreindre les jointures à l’utilisation de colonnes de jointure spécifiques. Voir Restreindre les jointures sur des colonnes spécifiques.

Une table ou une vue ne peut se voir attribuer qu’une seule politique de jointure à la fois. Voir Remplacer une politique de jointure.

Tester la politique de jointure en exécutant quelques requêtes

Les requêtes suivantes illustrent le comportement attendu lorsque la politique jp1 est en vigueur pour la table join_table. Il n’est pas nécessaire de charger cette table ; une table vide suffit à démontrer le comportement attendu.

Une requête sans jointure renvoie une erreur attendue :

SELECT * FROM join_table;
Copy
506037 (23001): SQL compilation error: Join Policy violation, please contact the policy admin for details

Une requête avec une jointure interne explicite sur col1 renvoie des résultats :

SELECT * FROM join_table jt1 INNER JOIN join_table_2 jt2 ON jt1.col1=jt2.col1;
Copy
+------+------+------+------+------+------+
| COL1 | COL2 | COL3 | COL1 | COL2 | COL3 |
|------+------+------+------+------+------|
+------+------+------+------+------+------+

Une requête avec une jointure interne explicite sur col2 renvoie également des résultats :

SELECT * FROM join_table jt1 INNER JOIN join_table_2 jt2 ON jt1.col2=jt2.col2;
Copy
+------+------+------+------+------+------+
| COL1 | COL2 | COL3 | COL1 | COL2 | COL3 |
|------+------+------+------+------+------|
+------+------+------+------+------+------+

Restreindre les jointures sur des colonnes spécifiques

Pour tester davantage le comportement de la politique de jointure, détachez (désactivez) la politique de la table, supprimez et recréez la politique de jointure, puis recréez join_table avec DDL qui inclut le paramètre ALLOWED JOIN KEYS.

ALTER TABLE join_table UNSET JOIN POLICY;

DROP JOIN POLICY jp1;

CREATE JOIN POLICY jp1
  AS () RETURNS JOIN_CONSTRAINT -> JOIN_CONSTRAINT(JOIN_REQUIRED => TRUE);

CREATE OR REPLACE TABLE join_table (
  col1 INT,
  col2 VARCHAR,
  col3 NUMBER )
  JOIN POLICY jp1 ALLOWED JOIN KEYS (col1);
Copy

Essayez à nouveau l’une des requêtes précédentes, avec col2 comme colonne de jointure. La requête échoue car col2 n’est pas une clé de jointure autorisée.

SELECT * FROM join_table jt1 INNER JOIN join_table_2 jt2 ON jt1.col2=jt2.col2;
Copy
506038 (23001): SQL compilation error: Join Policy violation, invalid join condition with reason: Disallowed join key used.

La même requête avec jt1.col1=jt2.col1 comme condition de jointure aboutirait. Une jointure naturelle de ces deux tables échouerait parce qu’elle tenterait de joindre col1 et col2.

Afficher et décrire les politiques de jointure

Vous pouvez utiliser les commandes SHOW JOIN POLICIES et DESCRIBE JOIN POLICY pour obtenir des informations de base sur les politiques de jointure existantes dans votre compte. Pour obtenir des informations plus détaillées sur les politiques de jointure, voir Superviser les politiques de jointure.

SHOW JOIN POLICIES;
Copy
+-------------------------------+------+---------------+----------------+-------------+--------------+---------+-----------------+---------+
| created_on                    | name | database_name | schema_name    | kind        | owner        | comment | owner_role_type | options |
|-------------------------------+------+---------------+----------------+-------------+--------------+---------+-----------------+---------|
| 2024-12-04 15:15:49.591 -0800 | JP1  | POLICY1_DB    | POLICY1_SCHEMA | JOIN_POLICY | POLICY1_ROLE |         | ROLE            |         |
+-------------------------------+------+---------------+----------------+-------------+--------------+---------+-----------------+---------+

DESCRIBE JOIN POLICY jp1;
Copy
+------+-----------+-----------------+----------------------------------------+
| name | signature | return_type     | body                                   |
|------+-----------+-----------------+----------------------------------------|
| JP1  | ()        | JOIN_CONSTRAINT | JOIN_CONSTRAINT(JOIN_REQUIRED => TRUE) |
+------+-----------+-----------------+----------------------------------------+

Créer et appliquer des politiques de jointure conditionnelle

Les administrateurs de politiques peuvent définir l’expression SQL d’une politique de jointure afin que différentes requêtes soient soumises à des restrictions différentes en fonction de facteurs tels que le rôle de l’utilisateur qui exécute la requête. Cette stratégie peut permettre à un utilisateur d’interroger une table sans restriction tout en exigeant des autres qu’ils utilisent des jointures.

Par exemple, la politique de jointure suivante donne aux utilisateurs ayant les rôles ACCOUNTADMIN, FINANCE_ROLE ou HR_ROLE un accès illimité à une table tout en exigeant de tous les autres utilisateurs qu’ils spécifient une jointure.

CREATE JOIN POLICY my_join_policy
  AS () RETURNS JOIN_CONSTRAINT ->
    CASE
      WHEN CURRENT_ROLE() = 'ACCOUNTADMIN'
          OR CURRENT_ROLE() = 'FINANCE_ROLE'
          OR CURRENT_ROLE() = 'HR_ROLE'
        THEN JOIN_CONSTRAINT(JOIN_REQUIRED => FALSE)
      ELSE JOIN_CONSTRAINT(JOIN_REQUIRED => TRUE)
    END;
Copy

Astuce

Vous pouvez utiliser les fonctionnalités suivantes lorsque vous utilisez des fonctions contextuelles telles que CURRENT_ROLE dans une politique conditionnelle :

  • Les fonctions contextuelles 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.

  • La fonction POLICY_CONTEXT vous aide à évaluer si un corps de politique renvoie la bonne valeur lorsqu’une fonction contextuelle renvoie une certaine valeur. La fonction POLICY_CONTEXT simule les résultats d’une requête en fonction d’une valeur spécifiée d’une ou plusieurs fonctions contextuelles.

Exigences relatives aux requêtes de jointure

Les requêtes portant sur une table ou une vue soumise à des contraintes de jointure doivent respecter les exigences suivantes pour qu’une politique de jointure prenne effet :

Types de jointures pris en charge

Les types de jointures explicites suivants sont pris en charge pour les tables soumises à des contraintes de jointure :

  • INNER JOIN (avec le mot-clé facultatif INNER ; JOIN est obligatoire)

  • LEFT OUTER JOIN et RIGHT OUTER JOIN, où la table soumise à des contraintes de jointure est la table « opposée ». Si la table soumise à des contraintes de jointure est la première table ou la table « gauche », la jointure externe doit être une RIGHT OUTER JOIN. Si la table soumise à des contraintes de jointure est la deuxième table ou la table « droite », la jointure externe doit être une LEFT OUTER JOIN.

  • NATURAL JOIN (jointure interne sur les colonnes avec des noms communs)

Les jointures internes et externes doivent être spécifiées explicitement dans la clause FROM, avec les conditions de jointure ON ou USING. Ces jointures ne peuvent pas être spécifiées dans la clause WHERE.

Types de jointure non pris en charge

Les types de jointure suivants ne sont pas pris en charge :

  • FULL OUTER JOIN

  • ASOF JOIN

  • jointures LATERAL

  • Jointures implicites dans la clause WHERE

  • Jointures croisées (produit cartésien)

Jointures avec plusieurs tables soumises à des contraintes de jointure

Si les deux tables (ou toutes les tables) d’une requête de jointure se sont vu attribuer une politique de jointure, la requête échoue avec une erreur. Dans une jointure de deux tables, une seule peut être soumise à des contraintes de jointure.

UNION, INTERSECT et EXCEPT

  • Les opérations d’ensemble UNION et UNION ALL ne sont pas prises en charge dans les requêtes portant sur des tables soumises à des contraintes de jointure.

  • Les opérations d’ensemble INTERSECT sont prises en charge car elles sont sémantiquement équivalentes aux jointures internes.

  • Les opérations d’ensemble MINUS et EXCEPT sont prises en charge uniquement lorsque la table soumise à des contraintes de jointure se trouve du côté filtré de l’opérateur (c’est-à-dire dans le deuxième bloc de la requête).

Conversions de types de données

Une requête qui inclut une fonction de conversion de type de données dans l’instruction SELECT doit utiliser la version TRY de la fonction. Par exemple, la fonction TRY_CAST est autorisée, mais la fonction CAST est interdite. Les fonctions de conversion de type de données suivantes sont autorisées pour les types numériques :

Erreurs attendues pour les requêtes portant sur des tables soumises à des contraintes de jointure

Les exemples suivants illustrent certains des cas où les requêtes sont susceptibles d’échouer en raison de l’application d’une politique de jointure à une table ou à une vue. Pour plus d’informations, voir Exigences relatives aux requêtes de jointure. Les tables de ces requêtes ne contiennent aucune ligne, de sorte que les requêtes renvoient soit un résultat vide (réussite), soit une erreur (échec).

Les requêtes sans jointures échouent

Lorsqu’une politique de jointure est attribuée à join_table, les requêtes simples sans jointure échouent. La requête suivante renvoie une erreur.

SELECT col1, col2 FROM join_table;
Copy

Les jointures de clause WHERE sont interdites

Si join_table (alias jt1) est une table soumise à des contraintes de jointure, la jointure de la clause WHERE suivante renvoie une erreur :

SELECT *
  FROM join_table jt1, join_table_2 jt2
  WHERE jt1.col1=jt2.col1;
Copy

Les jointures externes gauche et droite dépendent de l’ordre des tables

Les exemples suivants montrent le comportement attendu avec les jointures externes, où join_table (alias jt1) est la table soumise à des contraintes de jointure. La première requête renvoie une erreur.

SELECT * FROM join_table jt1
  LEFT OUTER JOIN join_table_2 jt2 ON jt1.col1=jt2.col1;
Copy

La deuxième requête renvoie des résultats.

SELECT * FROM join_table jt1
  RIGHT OUTER JOIN join_table_2 jt2 ON jt1.col1=jt2.col1;
Copy

La jointure de deux tables soumises à des contraintes de jointure n’est pas prise en charge

Si join_table et join_table_2 disposent tous deux d’une politique de jointure, la requête de jointure suivante renvoie une erreur :

SELECT * FROM join_table jt1 JOIN join_table_2 jt2 ON jt1.col1=jt2.col1;
Copy

Les opérations d’ensemble UNION sont interdites, mais les opérations INTERSECT sont autorisées

Dans ces exemples, join_table dispose d’une politique de jointure, mais pas de join_table_3. La requête UNION échoue, mais une requête similaire INTERSECT réussit.

SELECT * FROM JOIN_TABLE
UNION
SELECT * FROM JOIN_TABLE_3;
Copy
SELECT * FROM JOIN_TABLE
INTERSECT
SELECT * FROM JOIN_TABLE_3;
Copy

Le comportement de EXCEPT dépend de l’ordre des blocs de requête

Le comportement de EXCEPT dépend de l’ordre des blocs de requête. Notez que la première requête sélectionne d’abord dans la table soumise à des contraintes de jointure et renvoie une erreur.

SELECT * FROM JOIN_TABLE
EXCEPT
SELECT * FROM JOIN_TABLE_3;
Copy

La deuxième requête aboutit.

SELECT * FROM JOIN_TABLE_3
EXCEPT
SELECT * FROM JOIN_TABLE;
Copy

Une vue sur une table soumise à des contraintes de jointure est également protégée

Supposons que la politique de jointure jp1 ait été attribuée à join_table. Créez une vue sur la table :

CREATE VIEW join_table_view AS
  SELECT * FROM join_table;
Copy

Effectuez maintenant une requête sur la vue sans spécifier de jointure :

SELECT * FROM join_table_view;
Copy

La requête échoue car elle enfreint la politique sur join_table. La requête sur la vue doit contenir une jointure. Pour plus d’informations sur le comportement des politiques de jointure avec les vues, voir Vues et vues matérialisées.

Gérer les politiques de jointure

Vous pouvez modifier, remplacer, détacher, décrire et surveiller les politiques de jointure. Les sections suivantes traitent de ces tâches de gestion.

Modifier une politique de jointure

Vous pouvez utiliser la commande ALTER JOIN POLICY pour modifier les règles de la politique de jointure. Vous pouvez également renommer une politique ou modifier son commentaire.

Avant de modifier une politique de jointure, exécutez la commande DESCRIBE JOIN POLICY ou la fonction GET_DDL pour revoir l’expression SQL actuelle de la politique.

Par exemple, exécutez la commande suivante pour mettre à jour l’expression SQL de la politique de jointure jp3 afin que les jointures ne soient pas requises :

ALTER JOIN POLICY jp3 SET BODY -> JOIN_CONSTRAINT(JOIN_REQUIRED => FALSE);
Copy

Remplacer une politique de jointure

La méthode recommandée pour remplacer une politique de jointure consiste à utiliser le paramètre FORCE dans une instruction ALTER TABLE, qui détache la politique existante et en attribue une nouvelle en une seule commande. Cette approche vous permet de remplacer atomiquement l’ancienne politique, sans laisser de vide dans la protection.

Par exemple, pour affecter une nouvelle politique de jointure à une table déjà soumise à des contraintes de jointure :

ALTER TABLE join_table SET JOIN POLICY jp2 FORCE;
Copy

Vous pouvez également détacher la politique d’une table ou d’une vue dans une instruction (à l’aide de UNSET JOIN POLICY), puis définir une nouvelle politique dans une autre instruction (à l’aide de SET JOIN POLICY). Si vous choisissez cette méthode, la table n’est pas protégée par une politique de jointure entre les deux opérations. Pendant ce temps, une requête pourrait potentiellement accéder à des données sensibles.

Détacher une politique de jointure

Utilisez la clause UNSET JOIN POLICY d’une commande ALTER TABLE ou ALTER VIEW pour détacher une politique de jointure d’une table ou d’une vue. Le nom de la politique n’est pas exigé car un objet ne peut pas avoir plus d’une politique. Par exemple :

ALTER VIEW join_view UNSET JOIN POLICY;
Copy

Superviser les politiques de jointure

Vous pouvez contrôler l’utilisation des politiques de jointure de la manière suivante :

  • Interrogez la vue JOIN_POLICIES dans le schéma Account Usage de la base de données SNOWFLAKE partagée. Cette vue est un catalogue pour toutes les politiques de jointure de votre compte Snowflake.

  • Interrogez la fonction de table Information Schema POLICY_REFERENCES pour identifier les références aux politiques de jointure et découvrir les tables et les vues auxquelles des politiques sont actuellement appliquées.

Obtenir des informations sur les politiques de jointure

Pour obtenir des informations sur les politiques de jointure existantes, interrogez la vue JOIN_POLICIES dans le schéma Account Usage de la base de données partagée SNOWFLAKE. Cette vue est un catalogue pour toutes les politiques de jointure de votre compte Snowflake. Par exemple, vous pouvez renvoyer le corps de la politique pour une politique de jointure spécifique :

SELECT policy_name, policy_body, created
  FROM SNOWFLAKE.ACCOUNT_USAGE.JOIN_POLICIES
  WHERE policy_name='JP2' AND created LIKE '2024-11-26%';
Copy
+-------------+----------------------------------------------------------+-------------------------------+
| POLICY_NAME | POLICY_BODY                                              | CREATED                       |
|-------------+----------------------------------------------------------+-------------------------------|
| JP2         | CASE                                                     | 2024-11-26 11:22:54.848 -0800 |
|             |           WHEN CURRENT_ROLE() = 'ACCOUNTADMIN'           |                               |
|             |             THEN JOIN_CONSTRAINT(JOIN_REQUIRED => FALSE) |                               |
|             |           ELSE JOIN_CONSTRAINT(JOIN_REQUIRED => TRUE)    |                               |
|             |         END                                              |                               |
+-------------+----------------------------------------------------------+-------------------------------+

Obtenir des informations sur les tables et les vues liées aux politiques de jointure

La fonction de table Information Schema POLICY_REFERENCES renvoie des informations sur les tables et les vues attachées aux politiques de jointure existantes. Vous pouvez utiliser deux options de syntaxe différentes :

  • Renvoie une ligne pour chaque objet (table ou vue) pour lequel la politique de jointure 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.jp1'));
    Copy

  • Renvoyez des informations sur la politique affectée à join_table :

    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.join_table', ref_entity_domain => 'table'));
    Copy
    +-------------+-------------+-----------------+-------------------+-----------------+----------------------+---------------+
| POLICY_NAME | POLICY_KIND | REF_ENTITY_NAME | REF_ENTITY_DOMAIN | REF_COLUMN_NAME | REF_ARG_COLUMN_NAMES | POLICY_STATUS |
|-------------+-------------+-----------------+-------------------+-----------------+----------------------+---------------|
| JP1         | JOIN_POLICY | JOIN_TABLE      | TABLE             | NULL            | [ "COL1" ]           | ACTIVE        |
+-------------+-------------+-----------------+-------------------+-----------------+----------------------+---------------+

Meilleures pratiques pour l’administration des politiques

La création d’une politique de jointure et son affectation à une table requièrent la même procédure générale que la création et l’affectation d’autres politiques, telles que les politiques de masquage, de projection et d’agrégation :

  1. Si vous utilisez une approche de gestion centralisée, créez un rôle personnalisé (tel que join_policy_admin) pour gérer la politique. Vous pouvez aussi utiliser un rôle existant.

  2. Accordez à ce rôle les privilèges de création et d’attribution d’une politique de jointure.

  3. Créez la politique de jointure.

  4. Créez ou modifiez une table afin d’affecter la politique à la table et d’autoriser la jointure des colonnes (ALLOWED JOIN KEYS).

  5. Testez quelques requêtes jointes et non jointes sur la table.

Les requêtes réussies sur la table doivent relier ses données à une autre table ou vue et doivent porter sur les colonnes autorisées.

Tâches de l’administrateur du contrôle d’accès

  1. Créez un rôle personnalisé pour gérer la politique de jointure. Vous pouvez également réutiliser un rôle existant.

    USE ROLE USERADMIN;

CREATE ROLE join_policy_admin;
    Copy

  2. Accordez au rôle personnalisé join_policy_admin les privilèges permettant de créer une politique de jointure dans un schéma et d’affecter la politique de jointure à une table ou à une vue dans le compte Snowflake.

    Cette étape suppose que la politique de jointure sera stockée dans une base de données et un schéma nommés privacy.join_policies et que cette base de données et ce schéma existent déjà :

    GRANT USAGE ON DATABASE privacy TO ROLE join_policy_admin;
GRANT USAGE ON SCHEMA privacy.join_policies TO ROLE join_policy_admin;

GRANT CREATE JOIN POLICY
  ON SCHEMA privacy.join_policies TO ROLE join_policy_admin;

GRANT APPLY JOIN POLICY ON ACCOUNT TO ROLE join_policy_admin;
    Copy

    Le rôle join_policy_admin peut maintenant être affecté à un ou plusieurs utilisateurs.

    Pour obtenir des informations sur les privilèges nécessaires pour travailler avec les politiques de jointure, voir Gérer les politiques de jointure (dans cette rubrique).

Tâches de l’administrateur de la politique de jointure

  • Créez une politique de jointure :

    USE ROLE join_policy_admin;
USE SCHEMA privacy.join_policies;

CREATE OR REPLACE JOIN POLICY jp1
  AS () RETURNS JOIN_CONSTRAINT -> JOIN_CONSTRAINT(JOIN_REQUIRED => TRUE);
    Copy

Interaction des politiques de jointure avec d’autres fonctions Snowflake

Les sections suivantes résument la manière dont les politiques de jointure interagissent avec d’autres fonctions et services Snowflake.

Autres politiques

Cette section décrit l’interaction entre une politique de jointure et d’autres politiques, notamment les politiques de masquage, les politiques d’accès aux lignes, les politiques d’agrégation et les politiques de projection.

Vous pouvez associer d’autres politiques à une table soumise à des contraintes de jointure. Une requête réussie sur la table doit remplir les conditions de toutes les politiques.

Si une politique d’accès aux lignes est attribuée à une table soumise à des contraintes de jointure, une ligne exclue des résultats de la requête sur la base de la politique d’accès aux lignes n’est pas prise en compte lors du calcul des résultats de la jointure.

Le corps d’une politique de masquage, d’une politique d’accès aux lignes, d’une politique d’agrégation ou d’une politique de projection ne peut pas faire référence à une table soumise à des contraintes de jointure, y compris à ses colonnes.

Vues et vues matérialisées

Vous pouvez attribuer une politique de jointure aux vues et aux vues matérialisées. Lorsqu’une politique de jointure est appliquée à une vue, la table sous-jacente n’est pas soumise à des contraintes de jointure. Cette table de base peut continuer à être interrogée sans restriction.

La possibilité de créer une vue à partir d’une table à contraintes de jointure dépend du type de vue :

  • Vous pouvez créer une vue normale à partir d’une ou de plusieurs tables soumises à des restrictions de jointure ; toutefois, les requêtes portant sur cette vue doivent joindre les données d’une manière qui respecte les restrictions de ces tables de base. Vous ne pouvez pas contourner une politique de jointure sur une table protégée en créant une vue sur la table. La politique relative à la table est respectée et appliquée pour les requêtes portant sur la vue. Pour un exemple, voir Une vue sur une table soumise à des contraintes de jointure est également protégée.

  • Vous ne pouvez pas créer une vue matérialisée sur la base d’une table ou d’une vue soumise à des contraintes de jointure, ni attribuer une politique de jointure à une table ou à une vue sur laquelle une vue matérialisée est basée.

Objets clonés

L’approche suivante permet de protéger les données des utilisateurs titulaires du privilège SELECT sur une table ou une vue clonée stockée dans la base de données ou le schéma cloné :

  • Le clonage d’un objet individuel de politique de jointure n’est pas pris en charge.

  • Le clonage d’une base de données entraîne le clonage de toutes les politiques de jointure de la base de données.

  • Le clonage d’un schéma entraîne le clonage de toutes les politiques de jointure du schéma.

  • Une table clonée mappe les mêmes politiques de jointure que la table source.

    • Lorsqu’une table est clonée dans le contexte du clonage de son schéma parent, si la table source a une référence à une politique de jointure dans le même schéma parent (c’est-à-dire une référence locale), la table clonée aura une référence à la politique de jointure clonée.

    • Si la table source fait référence à une politique de jointure dans un schéma différent (c’est-à-dire une référence étrangère), la table clonée conserve la référence étrangère.

Pour plus d’informations, voir CREATE <objet> … CLONE.

Réplication

Les politiques de jointure et leurs affectations peuvent être répliquées à l’aide de la réplication de base de données et des groupes de réplication.

Pour la réplication de base de données, l’opération de réplication échoue si l’une des conditions suivantes est vraie :

  • La base de données principale se trouve dans un compte Enterprise (ou supérieur) et contient une politique, mais au moins un des comptes approuvés pour la réplication se trouve sur des éditions inférieures.

  • Une table ou une vue contenue dans la base de données principale a une référence pendante à une politique dans une autre base de données.

Le comportement de la référence pendante pour la réplication des bases de données peut être évité lors de la réplication de plusieurs bases de données dans un groupe de réplication.

Privilèges et commandes

Les sous-sections suivantes fournissent des informations permettant de gérer les politiques de jointure.

Privilèges sur les politiques de jointure

Snowflake prend en charge les privilèges suivants sur l’objet de la politique de jointure.

Le privilège USAGE relatif à la base de données et au schéma parents est exigé pour effectuer des opérations sur tout objet d’un schéma.

Privilège

Utilisation

APPLY

Active les opérations de définition et d’annulation d’une politique de jointure sur une table.

OWNERSHIP

Transfère la propriété de la politique de jointure, ce qui permet d’en avoir le contrôle total. Exigence requise pour modifier la plupart des propriétés d’une politique de jointure.

Pour plus d’informations, voir Résumé des commandes, des opérations et des privilèges DDL.

Référence DDL d’une politique de jointure

Snowflake prend en charge les commandes DDL suivantes pour créer et gérer les politiques de jointure.

Résumé des commandes, des opérations et des privilèges DDL

La table suivante résume la relation entre les privilèges de la politique de jointure et les opérations DDL.

Le privilège USAGE relatif à la base de données et au schéma parents est exigé pour effectuer des opérations sur tout objet d’un schéma.

Fonctionnement

Privilège requis

Créez une politique de jointure.

Un rôle avec le privilège CREATE JOIN POLICY dans le même schéma.

Modifiez la politique de jointure.

Le rôle disposant du privilège OWNERSHIP sur la politique de jointure.

Décrire la politique de jointure

Un des éléments suivants :

  • Un rôle avec le privilège global APPLY JOINPOLICY.

  • Un rôle ayant le privilège OWNERSHIP sur la politique de jointure.

  • Un rôle ayant le privilège APPLY sur la politique de jointure.

Supprimez la politique de jointure.

Un rôle ayant le privilège OWNERSHIP sur la politique de jointure.

Affichez les politiques de jointure.

Un des éléments suivants :

  • Un rôle doté du privilège USAGE sur le schéma dans lequel la politique de jointure existe.

  • Un rôle avec le privilège APPLY JOIN POLICY sur le compte.

Définit ou annule une politique de jointure sur une table.

Un des éléments suivants :

  • Un rôle avec le privilège APPLY JOIN POLICY sur le compte.

  • Un rôle doté du privilège APPLY sur la politique de jointure et du privilège OWNERSHIP sur la table ou la vue.

Snowflake prend en charge différentes autorisations pour créer et définir une politique de jointure sur un objet.

  1. Pour une approche de gestion centralisée des politiques dans laquelle le rôle personnalisé join_policy_admin crée et définit les politiques de jointure sur toutes les tables, les autorisations suivantes sont nécessaires :

    USE ROLE securityadmin;
GRANT USAGE ON DATABASE mydb TO ROLE join_policy_admin;
GRANT USAGE ON SCHEMA mydb.schema TO ROLE join_policy_admin;
GRANT CREATE JOIN POLICY ON SCHEMA mydb.schema TO ROLE join_policy_admin;
GRANT APPLY ON JOIN POLICY ON ACCOUNT TO ROLE join_policy_admin;
    Copy

  2. Dans une approche de gestion hybride, un rôle unique dispose du privilège CREATE JOIN POLICY pour s’assurer que les politiques de jointure sont nommées de manière cohérente et des équipes ou des rôles individuels disposent du privilège APPLY pour une politique de jointure spécifique.

    Par exemple, le rôle personnalisé finance_role peut se voir accorder l’autorisation de définir la politique de jointure cost_center sur les tables et les vues dont il est propriétaire (c’est-à-dire que le rôle dispose du privilège OWNERSHIP sur la table ou la vue) :

    USE ROLE securityadmin;
GRANT CREATE JOIN POLICY ON SCHEMA mydb.schema TO ROLE join_policy_admin;
GRANT APPLY ON JOIN POLICY cost_center TO ROLE finance_role;
    Copy
Langage: Français