Partagez des données protégées par une politique

Cette version en avant-première permet aux consommateurs de partage de données d’utiliser un rôle de base de données partagé pour accéder à des données partagées protégées par une politique de masquage ou une politique d’accès aux lignes.

Vue d’ensemble

Un fournisseur de partages de données peut utiliser la fonction de contexte IS_DATABASE_ROLE_IN_SESSION dans les conditions d’une politique de masquage ou d’une politique d’accès aux lignes pour permettre à un consommateur de données partagées d’accéder aux données partagées qui sont protégées par l’une ou l’autre de ces politiques. Le fournisseur dispose ainsi d’un plus grand nombre d’options pour partager les données et le consommateur peut accéder aux données sensibles que le fournisseur met à sa disposition.

Le fournisseur peut choisir de regrouper la politique et les objets partagés dans une seule base de données ou dans différentes bases de données. Lorsque les politiques et les tables protégées se trouvent dans des bases de données différentes, le fournisseur doit :

  • Partager les deux bases de données sur le compte du consommateur.

  • Créer le rôle de base de données dans la même base de données que la politique.

  • Accorder le rôle de base de données au partage contenant la politique.

Lorsque le consommateur crée une base de données à partir du partage, les rôles de base de données dans le partage sont accordés au rôle qui crée la base de données à partir du partage. Cela permet au rôle du compte du consommateur de satisfaire aux conditions de la politique qui spécifient le rôle de la base de données et d’accéder aux données partagées.

Pour accéder aux données partagées protégées par la politique, le consommateur doit spécifier la base de données contenant le rôle de base de données partagée pour rendre ce rôle actif dans la session en cours. Dans ce contexte, rendre le rôle de base de données actif signifie que le rôle de base de données est disponible dans la hiérarchie des rôles du rôle actuel de l’utilisateur. Si vous ne spécifiez pas cette base de données partagée, les utilisateurs du compte de consommateur ne peuvent pas accéder aux données partagées qui sont protégées par une politique. Vous pouvez spécifier cette base de données en utilisant l’une des options suivantes :

  • Activer la base de données dans la session avec la commande USE <objet> ou sélectionner la base de données dans la feuille de calcul. Par exemple :

    USE DATABASE mounted_db;
    
    Copy

    Notez que mounted_db est le nom de la base de données que le consommateur crée à partir du partage.

  • Pour une requête spécifique, utilisez le nom complet de l’objet qui se trouve dans la même base de données que le rôle de base de données. Par exemple :

    SELECT * FROM mounted_db.myschema.mytable;
    
    Copy

Appelez la fonction

Il existe deux façons différentes de spécifier des arguments dans la fonction contextuelle IS_DATABASE_ROLE_IN_SESSION : une chaîne littérale ou une chaîne non littérale (c’est-à-dire un nom de colonne).

  • Lorsque vous spécifiez un rôle de base de données en tant que chaîne dans la fonction de contexte IS_DATABASE_ROLE_IN_SESSION , le résultat de l’appel de la fonction dépend de la manière dont la fonction est appelée. Par exemple :

    • Dans une feuille de calcul, Snowflake examine la base de données utilisée pour la session ou la base de données spécifiée dans la requête. Cela s’applique au compte de fournisseur et au compte de consommateur.

    • Dans une politique, une UDF ou une vue, Snowflake examine la base de données dans laquelle la politique est définie lorsque la politique est partagée. Lorsque la politique n’est pas partagée, Snowflake renvoie une erreur si la recherche du rôle de base de données aboutit à ce que le rôle de la base de données soit défini dans une base de données différente.

      A Role Context Function cannot reference a DB Role in another database.
      
      Copy
  • Lorsque vous spécifiez un nom de colonne comme argument dans la fonction contextuelle IS_DATABASE_ROLE_IN_SESSION :

    • Si une requête de table appelle la fonction, la colonne correspond à l’identificateur de la table contenant la colonne. Snowflake examine ensuite les rôles de base de données contenant la table. Par exemple, pour spécifier la colonne AUTHZ_ROLE (c’est-à-dire le rôle autorisé) comme argument :

      SELECT * FROM mydb.myschema.t WHERE IS_DATABASE_ROLE_IN_SESSION(AUTHZ_ROLE);
      
      Copy
    • Si une politique de masquage, une politique d’accès aux lignes ou une UDF appelle la fonction, la recherche s’effectue dans la base de données qui contient la politique ou l’UDF.

Workflow général

Le partage de données protégées par une politique avec la fonction IS_DATABASE_ROLE_IN_SESSION dans la politique nécessite de suivre les mêmes étapes de création d’une politique pour appeler la fonction et partager les données. En résumé :

  1. Le fournisseur crée un rôle de compte.

  2. Le fournisseur crée une politique et la définit sur une table ou une colonne.

  3. Le fournisseur teste la politique avec le rôle de compte.

  4. Le fournisseur crée un rôle de base de données et teste la politique avec le rôle de base de données.

  5. Le fournisseur crée un partage et lui accorde des privilèges, y compris le rôle de base de données.

  6. Le consommateur crée une base de données à partir du partage (c’est-à-dire la base de données montée).

  7. Le consommateur interroge l’objet partagé protégé par la politique.

Exemple : tous les objets dans la même base de données

Dans cet exemple, les rôles de la base de données, la politique de masquage et la table protégée se trouvent tous dans la même base de données nommée mydb.

Pour référence :

  • Les rôles de la base de données sont mydb.analyst et mydb.support.

  • La politique de masquage est définie comme suit :

    CREATE OR REPLACE MASKING POLICY mydb.policies.email_mask
      AS (val string) RETURNS string ->
      CASE
        WHEN IS_DATABASE_ROLE_IN_SESSION('MYDB.ANALYST')
          THEN val
        WHEN IS_DATABASE_ROLE_IN_SESSION('MYDB.SUPPORT')
          THEN REGEXP_REPLACE(val,'.+\@','*****@')
        ELSE '********'
      END
      COMMENT = 'use database role for shared data'
      ;
    
    Copy
  • La colonne EMAIL se trouve dans une table nommée mydb.tables.empl_info et la politique de masquage est définie sur cette colonne.

Effectuez les étapes suivantes pour partager la base de données mydb et permettre au consommateur d’utiliser le rôle de base de données partagée pour interroger les données partagées protégées par la politique de masquage partagée. Ces étapes supposent que le fournisseur a déjà testé la politique de masquage sur la colonne EMAIL avec ses rôles de compte et de base de données.

  1. Dans le compte fournisseur, exécutez la commande CREATE SHARE pour créer un partage pour le rôle de base de données mydb.analyst_share :

    USE ROLE r1;
    CREATE SHARE analyst_share;
    
    Copy
  2. Accordez des privilèges au rôle Les mêmes privilèges sont requis pour chaque action :

    USE ROLE r1;
    GRANT USAGE ON DATABASE mydb TO SHARE analyst_share;
    GRANT USAGE ON SCHEMA mydb.policies TO SHARE analyst_share;
    GRANT USAGE ON SCHEMA mydb.tables TO SHARE analyst_share;
    GRANT SELECT ON TABLE mydb.tables.empl_info TO SHARE analyst_share;
    GRANT DATABASE ROLE mydb.analyst TO SHARE analyst_share;
    
    Copy
  3. Ajoutez un comptes de consommateur au partage :

    ALTER SHARE analyst_share ADD ACCOUNTS = consumer_account;
    
    Copy
  4. Dans le compte de consommateur, créez le rôle de compte r1 et accordez des privilèges à ce rôle pour importer le partage :

    USE ROLE ACCOUNTADMIN;
    CREATE ROLE r1;
    
    GRANT USAGE ON WAREHOUSE my_warehouse TO ROLE r1;
    GRANT CREATE DATABASE ON ACCOUNT TO ROLE r1;
    GRANT IMPORT SHARE ON ACCOUNT TO ROLE r1;
    GRANT ROLE r1 TO ROLE ACCOUNTADMIN;
    
    Copy
  5. Importez le partage :

    USE ROLE r1;
    CREATE DATABASE mounted_db FROM SHARE provider_account.analyst_share;
    
    Copy
  6. Vérifiez que le rôle de la base de données est en session :

    USE DATABASE mounted_db;
    USE SCHEMA mounted_db.tables;
    
    SELECT IS_DATABASE_ROLE_IN_SESSION('mounted_db.analyst');
    
    Copy

    L’instruction SELECT doit renvoyer True.

  7. Interrogez la table protégée :

    SELECT * FROM empl_info;
    
    Copy

    L’instruction SELECT doit renvoyer les adresses e-mail non masquées.

  8. Accordez les rôles de base de données aux rôles de compte afin que les utilisateurs dotés de ces rôles puissent interroger la table protégée et afficher les données en fonction de la définition de la politique de masquage.

    Après avoir répété les deux étapes précédentes, un utilisateur disposant du rôle de base de données mydb.support devrait voir une adresse e-mail partiellement masquée.

Exemple : politique de masquage et données protégées dans différentes bases de données

Lorsque la politique et la table protégée se trouvent dans des bases de données différentes, les deux bases de données doivent être partagées avec le consommateur.

Par exemple :

  • mydb1 contient la politique de masquage et le rôle de base de données mydb1.analyst. Vous devez regrouper la politique et le rôle de base de données dans la même base de données.

  • mydb2 contient la table nommée mydb2.tables.empl_info, qui contient la colonne EMAIL. La politique de masquage est définie sur cette colonne.

Le fournisseur suit la même procédure que dans l’exemple précédent en ce qui concerne la création d’un partage, l’attribution de privilèges au partage et l’attribution du rôle de base de données au partage.

Le consommateur suit la même procédure que dans l’exemple précédent en ce qui concerne la création d’une base de données à partir du partage. Toutefois, le consommateur doit disposer de la base de données contenant la politique utilisée pour activer le rôle de base de données. Le consommateur peut ensuite interroger la table protégée en spécifiant le nom complet de la table.

  1. Dans le compte fournisseur, exécutez la commande CREATE SHARE pour créer un partage pour chaque base de données :

    USE ROLE r1;
    CREATE SHARE analyst_policy_share;
    CREATE SHARE analyst_table_share;
    
    Copy
  2. Accordez des privilèges au partage nommé analyst_policy_share :

    USE ROLE r1;
    GRANT USAGE ON DATABASE mydb1 TO SHARE analyst_policy_share;
    GRANT USAGE ON SCHEMA mydb1.policies TO SHARE analyst_policy_share;
    GRANT DATABASE ROLE mydb1.analyst TO SHARE analyst_policy_share;
    
    Copy
  3. Accordez des privilèges au partage nommé analyst_table_share :

    USE ROLE r1;
    GRANT USAGE ON SCHEMA mydb2.tables TO SHARE analyst_table_share;
    GRANT SELECT ON TABLE mydb2.tables.empl_info TO SHARE analyst_table_share;
    
    Copy
  4. Ajoutez un comptes de consommateur au partage :

    ALTER SHARE analyst_policy_share ADD ACCOUNTS = consumer_account;
    ALTER SHARE analyst_table_share ADD ACCOUNTS = consumer_account;
    
    Copy
  5. Dans le compte de consommateur, créez le rôle de compte r1 et accordez des privilèges à ce rôle pour importer le partage :

    USE ROLE ACCOUNTADMIN;
    CREATE ROLE r1;
    
    GRANT USAGE ON WAREHOUSE my_warehouse TO ROLE r1;
    GRANT CREATE DATABASE ON ACCOUNT TO ROLE r1;
    GRANT IMPORT SHARE ON ACCOUNT TO ROLE r1;
    GRANT ROLE r1 TO ROLE ACCOUNTADMIN;
    
    Copy
  6. Importez chaque action :

    USE ROLE r1;
    CREATE DATABASE mounted_db1 FROM SHARE provider_account.analyst_policy_share;
    CREATE DATABASE mounted_db2 FROM SHARE provider_account.analyst_table_share;
    
    Copy
  7. Vérifiez que le rôle de la base de données est en session :

    USE DATABASE mounted_db1;
    USE SCHEMA mounted_db1.policies;
    
    SELECT IS_DATABASE_ROLE_IN_SESSION('mounted_db1.analyst');
    
    Copy

    L’instruction SELECT doit renvoyer True.

  8. Interrogez la table protégée :

    SELECT * FROM mounted_db2.tables.empl_info;
    
    Copy

    L’instruction SELECT doit renvoyer les adresses e-mail non masquées.

Exemple : politique d’accès aux lignes sans table de mappage

Dans cet exemple, la politique d’accès aux lignes appelle la fonction IS_DATABASE_ROLE_IN_SESSION pour rechercher le nom du rôle dans la colonne AUTHZ_ROLE (c’est-à-dire le rôle autorisé). Notez la syntaxe non littérale. Notez également que la recherche s’effectue dans la base de données qui contient la politique. Dans ce scénario, la table de mappage doit se trouver dans la même base de données que la politique d’accès aux lignes.

Créez la politique :

CREATE OR REPLACE ROW ACCESS POLICY rap_authz_role AS (authz_role string)
RETURNS boolean ->
IS_DATABASE_ROLE_IN_SESSION(authz_role);
Copy

Ajoutez la politique à un tableau :

ALTER TABLE allowed_roles
  ADD ROW ACCESS POLICY rap_authz_role ON (authz_role);
Copy

Le fournisseur peut choisir de partager des objets dans une seule base de données ou dans plusieurs bases de données, comme le montrent les exemples de politique de masquage. Le consommateur suit la même procédure pour créer une base de données à partir d’un partage pour chaque base de données mise à disposition par le fournisseur.

Exemple : politique d’accès aux lignes avec table de mappage

Dans cet exemple, la politique d’accès aux lignes appelle la fonction IS_DATABASE_ROLE_IN_SESSION pour rechercher le rôle autorisé dans une colonne de la table de mappage appelée ROLE_NAME. Notez la syntaxe non littérale. Notez également que la recherche s’effectue dans la base de données qui contient la politique. Dans ce scénario, la table de mappage doit se trouver dans la même base de données que la politique d’accès aux lignes. Après avoir créé la politique, ajoutez-la à la table contenant la colonne AUTHZ_ROLE.

Créez la politique :

CREATE OR REPLACE ROW ACCESS POLICY rap_authz_role_map AS (authz_role string)
RETURNS boolean ->
EXISTS (
  SELECT 1 FROM mapping_table m
  WHERE authz_role = m.key AND IS_DATABASE_ROLE_IN_SESSION(m.role_name)
);
Copy

Ajoutez la politique à un tableau :

ALTER TABLE allowed_roles
  ADD ROW ACCESS POLICY rap_authz_role_map ON (authz_role);
Copy

Le fournisseur peut choisir de partager des objets dans une seule base de données ou dans plusieurs bases de données, comme le montrent les exemples de politique de masquage. Le consommateur suit la même procédure pour créer une base de données à partir d’un partage pour chaque base de données mise à disposition par le fournisseur.