Politiques de masquage basées sur les balises¶

Privilège¶

Les exigences en matière de privilèges varient selon que vous choisissez de définir la politique de masquage basée sur des balises sur une base de données, un schéma ou une table.

Avec le masquage basé sur des balises sur une base de données ou un schéma, le rôle actuel ou un rôle dans la hiérarchie des rôles actuels doit hériter des privilèges comme indiqué dans l’une des deux options suivantes.

Option 1:

Le rôle doit disposer des privilèges globaux APPLY MASKING POLICY et APPLY TAG. Par exemple, accordez ces privilèges au rôle personnalisé data_engineer :

USE ROLE ACCOUNTADMIN;

GRANT APPLY MASKING POLICY ON ACCOUNT TO ROLE data_engineer;

GRANT APPLY TAG ON ACCOUNT TO ROLE data_engineer;

Copy

Il s’agit de l”approche la plus centralisée pour protéger les colonnes avec une politique de masquage basée sur des balises dans un schéma ou une base de données.

Option 2:

Le propriétaire d’un schéma (c’est-à-dire un rôle doté du privilège OWNERSHIP sur le schéma) peut bénéficier du privilège global APPLY MASKING POLICY et du privilège APPLY sur la balise. Par exemple, si la balise est nommée governance.tags.schema_mask et que le rôle personnalisé propriétaire du schéma est schema_owner :

USE ROLE ACCOUNTADMIN;

GRANT APPLY MASKING POLICY ON ACCOUNT TO ROLE schema_owner;

GRANT APPLY ON TAG governance.tags.schema_mask TO ROLE schema_owner;

Copy

Cette approche offre plus de souplesse en déléguant la protection des colonnes aux propriétaires des schémas.

Avec le masquage basé sur les balises sur les tables et les vues, un rôle doté du privilège global APPLY MASKING POLICY peut affecter et remplacer une politique de masquage sur une balise.

Par exemple, accordez le privilège global APPLY MASKING POLICY au rôle personnalisé tag_admin :

USE ROLE SECURITYADMIN;

GRANT APPLY MASKING POLICY ON ACCOUNT TO ROLE tag_admin;

Copy

Affecter une politique de masquage à une balise¶

L’attribution d’une politique de masquage basée sur des balises sur un schéma ou une base de données suit la même procédure que la définition d’une politique de masquage basée sur des balises sur une table :

1. Créez une balise à l’aide de la commande CREATE TAG.

2. Créez une politique de masquage à l’aide de la commande CREATE MASKING POLICY.

   Vous pouvez éventuellement utiliser les fonctions système SYSTEM$GET_TAG_ON_CURRENT_COLUMN et SYSTEM$GET_TAG_ON_CURRENT_TABLE dans les conditions de la politique de masquage.

3. Définissez la politique de masquage sur la balise à l’aide d’une commande ALTER TAG.

4. Définissez la balise sur l’objet en fonction de la manière dont vous souhaitez protéger vos données à l’aide de l’une des commandes suivantes :

   • ALTER DATABASE

   • ALTER SCHEMA

   • ALTER TABLE

En plus des notes sur l’utilisation d’ALTER TAG, notez ce qui suit :

• Une balise ne peut avoir qu’une seule politique de masquage par type de données. Par exemple, une politique pour le type de données STRING, une politique pour le type de données NUMBER, et ainsi de suite.

• Si une politique de masquage protège déjà une colonne et qu’une balise avec une politique de masquage est définie sur la même colonne, la politique de masquage directement attribuée à la colonne est prioritaire sur la politique de masquage attribuée à la balise.

• Une balise ne peut pas être détruite si elle est affectée à une politique de masquage.

• Une politique de masquage ne peut pas être détruite si elle est assignée à une balise.

Pour plus d’informations sur la gestion des politiques de masquage et des balises, voir :

• Gestion de la sécurité au niveau des colonnes

• Gestion des balises

Remplacer une politique de masquage sur une balise¶

Après avoir défini une politique de masquage sur une balise, il existe deux manières différentes de remplacer la politique de masquage sur la balise par une autre politique de masquage. L’instruction ALTER TAG doit spécifier le nom de la politique de masquage comme indiqué dans les options suivantes.

Option 1:

Annulez la politique d’une balise dans une instruction, puis définissez une nouvelle politique sur la balise dans une autre instruction :

ALTER TAG security UNSET MASKING POLICY ssn_mask;

ALTER TAG security SET MASKING POLICY ssn_mask_2;

Copy

Option 2:

Utilisez le mot-clé FORCE pour remplacer la politique dans une seule instruction.

Notez que l’utilisation du mot-clé FORCE remplace la politique lorsqu’une politique du même type de données est déjà définie sur la balise.

ALTER TAG security SET MASKING POLICY ssn_mask_2 FORCE;

Copy

L’option que vous sélectionnez dans la section Privilège et l’ordre des opérations dans la section Affecter une politique de masquage à une balise peuvent avoir un impact sur la gestion des balises si vous devez remplacer ou désactiver une balise sur une base de données ou un schéma.

Si le propriétaire d’un schéma définit une balise sur un schéma et qu’un autre rôle définit une politique de masquage sur la même balise, le propriétaire du schéma ne peut pas annuler la balise du schéma, sauf s’il bénéficie du privilège global APPLY MASKING POLICY. Snowflake met en échec l’opération ALTER SCHEMA… UNSET TAG pour le propriétaire du schéma. Ce scénario garantit que les données des colonnes protégées par une politique de masquage basée sur des balises restent protégées. Pour éviter ce scénario, utilisez l’option 1 dans la section Privilège.

Important

Faites preuve de prudence lorsque vous remplacez une politique de masquage sur une balise.

En fonction du moment du remplacement et de la requête sur la colonne, le choix de remplacer la politique dans deux instructions distinctes pourrait entraîner une fuite de données, car les données de la colonne ne sont pas protégées dans l’intervalle de temps entre les opérations UNSET et SET.

Toutefois, si les conditions de la politique sont différentes dans la politique de remplacement, la spécification du mot-clé FORCE pourrait entraîner une absence d’accès parce que les utilisateurs (précédents) pouvaient accéder aux données et que le remplacement ne permet plus l’accès.

Avant de remplacer une politique, consultez vos administrateurs de données internes afin de coordonner la meilleure approche pour protéger les données avec des politiques de masquage basées sur les balises, puis remplacez les politiques de masquage si nécessaire.

Mettre à jour une valeur de balise¶

Si le propriétaire d’un schéma (sch_role) définit une balise sur un schéma et qu’un autre rôle définit une politique de masquage sur la même balise (c’est-à-dire masking_admin_role), le propriétaire du schéma ne peut pas modifier la valeur de la balise. Snowflake met en échec l’opération ALTER SCHEMA … SET TAG pour le propriétaire du schéma.

Pour modifier la valeur de la balise :

1. En utilisant masking_admin_role, désactivez la politique de masquage de la balise.

2. À l’aide de sch_role, modifiez la valeur de la balise.

3. Réaffectez la politique de masquage à la balise à l’aide de masking_admin_role.

Bases de données et schémas parents¶

Vous ne pouvez pas effectuer d’opérations DROP et REPLACE sur la base de données et le schéma lorsque :

• La balise et la politique de masquage sont dans le même schéma.

• La table ou la vue se trouve dans un schéma différent.

• La colonne protégée dans la table ou la vue existe dans un schéma différent de celui qui contient la politique de masquage et la balise.

Ces quatre commandes font référence à DROP et remplacent les opérations sur la base de données et le schéma :

• DROP DATABASE

• DROP SCHEMA

• CREATE OR REPLACE DATABASE

• CREATE OR REPLACE SCHEMA

Arguments conditionnels¶

Une politique de masquage conditionnelle peut être assignée à une balise. Après avoir assigné la balise à une colonne, les arguments conditionnels correspondent à une colonne de la table par son nom si le type de données de l’argument correspond au type de données de la colonne.

Une requête échouera si une politique de masquage conditionnelle est affectée à une colonne dans les cas suivants :

• La table ne possède pas de colonne portant le même nom qu’un argument conditionnel de la politique.

• La table possède une colonne qui correspond au nom de l’argument conditionnel de la politique mais le type de données ne correspond pas.

Pour plus d’informations sur ces erreurs, voir Dépannage des politiques de masquage basées sur des balises (dans cette rubrique).

Lignée de balises¶

La balise avec la politique de masquage peut être attribuée à tous les objets de la table de base, ou la balise peut être attribuée à une colonne dans une table de base. Lorsque la politique de masquage basée sur des balises est attribuée à une table de base, les colonnes sont protégées par la politique à condition que le type de données de la colonne corresponde au type de données dans la signature de la politique de masquage.

Puisque la politique de masquage protège les colonnes de la table de base, les colonnes de la vue qui proviennent des colonnes de la table de base sous-jacente sont également protégées, en fonction des limitations, considérations et comportements actuels concernant les politiques de masquage avec les tables et les vues.

Data Sharing¶

Les politiques de masquage basées sur des balises qui sont définies sur un schéma partagé ou une base de données partagée dans le compte fournisseur sont appliquées dans le compte consommateur. Ce scénario garantit que les données protégées qui sont partagées restent protégées, même si un consommateur crée une nouvelle base de données à partir du partage.

De plus, notez ceci :

• la lignée de balises est conservée dans le compte consommateur.

  Lorsque le fournisseur définit une politique de masquage basée sur des balises sur sa base de données et partage cette base de données, Snowflake référence la base de données partagée du fournisseur dans le compte consommateur en termes de base de données qui contient la balise.

• Snowflake n’honore pas la lignée des balises avec les objets partagés lorsque les balises et les politiques de masquage basées sur les balises proviennent du compte consommateur.

  Les balises et les politiques de masquage basées sur les balises du compte consommateur ne sont pas appliquées aux objets partagés.

Snowsight¶

Vous pouvez contrôler et attribuer des politiques de masquage basées sur des balises dans Snowsight. Pour plus de détails, voir :

• Surveiller des balises avec Snowsight

• Contrôlez des politiques de masquage avec Snowsight

Découverte des balises et des politiques¶

La fonction de la table Information Schema POLICY_REFERENCES et la vue Account Usage POLICY_REFERENCES peuvent aider à déterminer si une politique de masquage et une balise font référence l’une à l’autre en examinant les colonnes suivantes :

• TAG_DATABASE

• TAG_SCHEMA

• TAG_NAME

• POLICY_STATUS

La colonne POLICY_STATUS peut avoir quatre valeurs possibles :

ACTIVE

Spécifie que la colonne (c’est-à-dire REF_COLUMN_NAME) n’est associée qu’à une seule politique par une balise.

MULTIPLE_MASKING_POLICY_ASSIGNED_TO_THE_COLUMN

Spécifie que plusieurs politiques de masquage sont affectées à la même colonne.

COLUMN_IS_MISSING_FOR_SECONDARY_ARG

Spécifie que la politique (c’est-à-dire POLICY_NAME) est une politique de masquage conditionnel et que la table (c’est-à-dire REF_ENTITY_NAME) ne possède pas de colonne portant le même nom.

COLUMN_DATATYPE_MISMATCH_FOR_SECONDARY_ARG

Spécifie que la politique est une politique de masquage conditionnel et que la table a une colonne avec le même nom, mais un type de données différent de celui de la signature de la politique de masquage.

Pour plus de détails sur les messages d’erreur associés aux valeurs possibles de la colonne POLICY_STATUS, voir Dépanner des politiques de masquage basées sur des balises (dans cette rubrique).

Étapes de protection et de validation des données¶

En général, Snowflake recommande l’approche suivante lors de l’utilisation de politiques de masquage basées sur des balises :

1. Créez toutes les balises nécessaires aux politiques de masquage basées sur des balises.

2. Créez une politique de masquage pour chaque type de données basé sur les colonnes de la table que vous avez l’intention de protéger avec les politiques de masquage basées sur les balises.

3. Affectez les politiques de masquage à la balise.

4. Affectez la balise avec les politiques de masquage à la colonne de la table directement ou à la table.

5. Vérifiez l’Information Schema pour contrôler que la politique basée sur des balises est affectée aux colonnes.

6. Interrogez les données pour vérifier que la politique de masquage basée sur des balises protège les données comme prévu.

Étapes préalables¶

1. Identifiez les balises existantes et leurs valeurs de chaînes dans votre compte Snowflake.

   • Interrogez la vue Account Usage TAG REFERENCES pour obtenir toutes les balises et les valeurs de chaîne qui leur sont attribuées.

   • En option :

     • Interrogez la vue Account Usage TAGS (c.-à-d. le catalogue de balises) pour obtenir une liste de balises afin de vous assurer que la désignation de balises en double ne se produira pas ultérieurement lors de l’utilisation de politiques de masquage basées sur des balises.

     • Comparez les résultats des requêtes TAG_REFERENCES et TAGS pour déterminer s’il existe des balises non attribuées qui peuvent être utilisées ultérieurement.

     • Créez toutes les balises qui seront nécessaires par la suite en utilisant la commande CREATE TAG. Sinon, créez des balises selon les besoins.

2. Identifiez les politiques existantes et leurs définitions dans votre compte Snowflake.

   • Exécutez la commande SHOW MASKING POLICIES pour obtenir une liste des politiques de masquage existantes.

   • Déterminez si ces politiques, dans leur forme actuelle, peuvent être attribuées à des balises. Si nécessaire, exécutez la commande DESCRIBE MASKING POLICY pour obtenir la définition de la politique. Sinon, prévoyez de créer de nouvelles politiques à affecter aux balises.

3. Déterminez comment protéger les données de la colonne avec la politique de masquage en déterminant si les conditions de la politique doivent correspondre à la valeur de la chaîne de balise qui est définie sur la colonne de la table.

Hypothèses communes avec exemples¶

Les exemples reposent sur les hypothèses suivantes :

• Les étapes préalables ont été effectuées.

• Le rôle personnalisé tag_admin dispose des privilèges suivants :

  • Le privilège CREATE TAG de niveau schéma.

  • Le privilège APPLY TAG global.

  Pour plus d’informations, voir Privilèges des balises.

• Le rôle personnalisé masking_admin dispose des privilèges suivants :

  • Le privilège CREATE MASKING POLICY de niveau schéma.

  • Le privilège USAGE sur la base de données governance et le schéma governance.masking_policies.

  • Le privilège global APPLY MASKING POLICY permettant d’affecter des politiques de masquage aux balises (voir Privilège dans cette rubrique).

  • Le privilège global APPLY TAG, pour attribuer la balise (avec les politiques de masquage) aux objets.

  Pour plus de détails, voir Privilèges des balises.

• Le rôle personnalisé row_access_admin dispose des privilèges suivants :

  • Le privilège CREATE ROW ACCESS POLICY de niveau schéma.

  • Le privilège USAGE sur la base de données governance et le schéma governance.row_access_policies.

  • Le privilège APPLY ROWACCESSPOLICY global.

  Pour plus d’informations, voir la section Privilèges de la politique d’accès aux lignes.

• Le rôle personnalisé accounting_admin dispose des privilèges suivants :

  • Le privilège USAGE sur la base de données finance et le schéma finance.accounting.

  • Le privilège SELECT sur les tables du schéma finance.accounting.

• Le rôle personnalisé analyst dispose des privilèges suivants :

  • Le privilège USAGE sur la base de données finance et sur le schéma finance.accounting.

  • Le privilège SELECT sur la table finance.accounting.name_number.

• Les rôles personnalisés décrits ci-dessus sont accordés aux utilisateurs appropriés.

  Pour plus de détails, voir Configuration du contrôle d’accès.

Exemple 1 : Protéger les données d’une colonne en fonction de la politique de masquage directement attribuée à la balise¶

Cet exemple attribue deux politiques de masquage à une balise, puis attribue la même balise à une table. Le résultat est que les politiques de masquage protègent toutes les colonnes de la table dont les types de données correspondent aux types de données des politiques.

Les étapes suivantes permettent de créer une politique de masquage basée sur les balises pour masquer les données comptables. Par exemple, considérons la table nommée finance.accounting.name_number, qui possède deux colonnes, ACCOUNT_NAME et ACCOUNT_NUMBER. Les types de données dans ces colonnes sont STRING et NUMBER, respectivement.

---------------+----------------+
  ACCOUNT_NAME | ACCOUNT_NUMBER |
---------------+----------------+
  ACME         | 1000           |
---------------+----------------+

Créez une politique de masquage basée sur les balises pour protéger les colonnes ACCOUNT_NAME et ACCOUNT_NUMBER comme suit :

1. Créez une balise nommée accounting dans le schéma nommé governance.tags.

   USE ROLE tag_admin;
   USE SCHEMA governance.tags;
   CREATE OR REPLACE TAG accounting;
   

   Copy

2. Créez différentes politiques de masquage pour protéger les colonnes ACCOUNT_NAME et ACCOUNT_NUMBER. Dans chacune de ces politiques, seul le rôle personnalisé ACCOUNTING_ADMIN peut voir les données brutes.

   Politique de nom de compte :

   USE ROLE masking_admin;
   USE SCHEMA governance.masking_policies;
   
   CREATE OR REPLACE MASKING POLICY account_name_mask
   AS (val string) RETURNS string ->
     CASE
       WHEN CURRENT_ROLE() IN ('ACCOUNTING_ADMIN') THEN val
       ELSE '***MASKED***'
     END;
   

   Copy

   Politique relative au numéro de compte :

   CREATE OR REPLACE MASKING POLICY account_number_mask
   AS (val number) RETURNS number ->
     CASE
       WHEN CURRENT_ROLE() IN ('ACCOUNTING_ADMIN') THEN val
       ELSE -1
     END;
   

   Copy

3. Assignez les deux politiques de masquage à la balise accounting. Notez que les deux politiques peuvent être assignées à la balise dans une seule instruction.

   ALTER TAG governance.tags.accounting SET
     MASKING POLICY account_name_mask,
     MASKING POLICY account_number_mask;
   

   Copy

4. Assignez la balise accounting à la table finance.accounting.name_number.

   ALTER TABLE finance.accounting.name_number
     SET TAG governance.tags.accounting = 'tag-based policies';
   

   Copy

5. Vérifiez que les colonnes des tables ACCOUNT_NAME et ACCOUNT_NUMBER sont protégées par la politique de masquage basée sur les balises en appelant la fonction de la table Information Schema POLICY_REFERENCES.

   Pour chaque colonne protégée, la ligne du résultat de la requête doit spécifier les valeurs appropriées pour le nom de la colonne, le nom de la politique et le nom de la balise :

   USE ROLE masking_admin;
   SELECT *
   FROM TABLE (governance.INFORMATION_SCHEMA.POLICY_REFERENCES(
     REF_ENTITY_DOMAIN => 'TABLE',
     REF_ENTITY_NAME => 'governance.accounting.name_number' )
   );
   

   Copy

   Résultat (notez les colonnes mises à jour) :

   -------------+------------------+---------------------+----------------+-------------------+-----------------+-----------------+-------------------+-----------------+----------------------+--------------+------------+------------+---------------+
     POLICY_DB  | POLICY_SCHEMA    | POLICY_NAME         | POLICY_KIND    | REF_DATABASE_NAME | REF_SCHEMA_NAME | REF_ENTITY_NAME | REF_ENTITY_DOMAIN | REF_COLUMN_NAME | REF_ARG_COLUMN_NAMES | TAG_DATABASE | TAG_SCHEMA | TAG_NAME   | POLICY_STATUS |
   -------------+------------------+---------------------+----------------+-------------------+-----------------+-----------------+-------------------+-----------------+----------------------+--------------+------------+------------+---------------+
     GOVERNANCE | MASKING_POLICIES | ACCOUNT_NAME_MASK   | MASKING_POLICY | FINANCE           | ACCOUNTING      | NAME_NUMBER     | TABLE             | ACCOUNT_NAME    | NULL                 | GOVERNANCE   | TAGS       | ACCOUNTING | ACTIVE        |
     GOVERNANCE | MASKING_POLICIES | ACCOUNT_NUMBER_MASK | MASKING_POLICY | FINANCE           | ACCOUNTING      | NAME_NUMBER     | TABLE             | ACCOUNT_NUMBER  | NULL                 | GOVERNANCE   | TAGS       | ACCOUNTING | ACTIVE        |
   -------------+------------------+---------------------+----------------+-------------------+-----------------+-----------------+-------------------+-----------------+----------------------+--------------+------------+------------+---------------+
   

6. Interrogez les colonnes de la table avec les rôles autorisés et non autorisés pour vous assurer que Snowflake renvoie le résultat correct de la requête.

   Autorisé :

   USE ROLE accounting_admin;
   SELECT * FROM finance.accounting.name_number;
   

   Copy

   Renvoie :

   ---------------+----------------+
     ACCOUNT_NAME | ACCOUNT_NUMBER |
   ---------------+----------------+
     ACME         | 1000           |
   ---------------+----------------+
   

   Non autorisé :

   USE ROLE analyst;
   SELECT * FROM finance.accounting.name_number;
   

   Copy

   Renvoie :

   ---------------+----------------+
     ACCOUNT_NAME | ACCOUNT_NUMBER |
   ---------------+----------------+
     ***MASKED*** | -1             |
   ---------------+----------------+
   

Exemple 2 : Protéger les données d’une colonne en fonction de la valeur de la chaîne de balises de la colonne¶

Cet exemple utilise une politique de masquage basée sur les balises pour déterminer si les données doivent être masquées en fonction de la valeur de la chaîne de balises de la balise affectée à une colonne. La politique de masquage évalue dynamiquement la valeur de la chaîne de balises en appelant la fonction SYSTEM$GET_TAG_ON_CURRENT_COLUMN dans les conditions de la politique de masquage et en écrivant ces conditions pour qu’elles correspondent à la valeur de la chaîne de balises.

Les étapes suivantes permettent de créer une politique de masquage basée sur les balises pour masquer les données comptables. Par souci de concision, les colonnes de la table ont deux types de données, STRING et NUMBER, respectivement. Par exemple, une table nommée finance.accounting.name_number :

---------------+----------------+
  ACCOUNT_NAME | ACCOUNT_NUMBER |
---------------+----------------+
  ACME         | 1000           |
---------------+----------------+

Créez une politique de masquage basée sur les balises pour protéger les colonnes ACCOUNT_NAME et ACCOUNT_NUMBER comme suit :

1. Créez une balise nommée accounting_col_string dans le schéma nommé governance.tags.

   USE ROLE tag_admin;
   USE SCHEMA governance.tags;
   CREATE TAG accounting_col_string;
   

   Copy

2. Créez différentes politiques de masquage pour protéger les colonnes ACCOUNT_NAME et ACCOUNT_NUMBER. Dans chacune de ces politiques, les données brutes sont visibles uniquement lorsque la valeur de la chaîne de balises actuelle de la colonne est définie sur 'visible'.

   Politique de nom de compte :

   USE ROLE masking_admin;
   USE SCHEMA governance.masking_policies;
   
   CREATE MASKING POLICY account_name_mask_tag_string
   AS (val string) RETURNS string ->
     CASE
       WHEN SYSTEM$GET_TAG_ON_CURRENT_COLUMN('tags.accounting_col_string') = 'visible' THEN val
       ELSE '***MASKED***'
     END;
   

   Copy

   Politique relative au numéro de compte :

   CREATE MASKING POLICY account_number_mask_tag_string
   AS (val number) RETURNS number ->
     CASE
       WHEN SYSTEM$GET_TAG_ON_CURRENT_COLUMN('tags.accounting_col_string') = 'visible' THEN val
       ELSE -1
     END;
   

   Copy

   Note

   Ces politiques utilisent le format de nom d’objet schema_name.tag_name dans l’argument de fonction car le schéma tags et le schéma masking_policies existent tous deux dans la base de données governance. Vous pouvez également utiliser le nom entièrement qualifié de la balise dans l’argument de la fonction.

   Snowflake renvoie une erreur lors de l’exécution de la requête sur une colonne protégée par une politique de masquage basée sur les balises si l’argument de la fonction système dans les conditions de la politique contient un nom de balise qui n’est pas suffisamment qualifié. Par exemple, l’argument utilise le nom de la balise comme accounting_col_string uniquement, sans spécifier le nom du schéma ou le nom de la base de données.

   Pour plus d’informations, voir Résolution de nom d’objet.

3. Assignez les deux politiques de masquage à la balise accounting_col_string. Notez que les deux politiques peuvent être assignées à la balise dans une seule instruction.

   ALTER TAG accounting_col_string SET
     MASKING POLICY account_name_mask_tag_string,
     MASKING POLICY account_number_mask_tag_string;
   

   Copy

4. Attribuez la balise accounting_col_string à chaque colonne de la table. Dans cet exemple, la valeur de la chaîne de balises de la colonne ACCOUNT_NAME est 'visible', mais la valeur de la chaîne de balises de la colonne ACCOUNT_NUMBER est 'protect'.

   ALTER TABLE finance.accounting.name_number MODIFY COLUMN
     account_name SET TAG governance.tags.accounting_col_string = 'visible',
     account_number SET TAG governance.tags.accounting_col_string = 'protect';
   

   Copy

5. Vérifiez que les colonnes des tables ACCOUNT_NAME et ACCOUNT_NUMBER sont protégées par la politique de masquage basée sur les balises en appelant la fonction de la table Information Schema POLICY_REFERENCES.

   Pour chaque colonne protégée, la ligne du résultat de la requête doit spécifier les valeurs appropriées pour le nom de la colonne, le nom de la politique et le nom de la balise.

   SELECT *
   FROM TABLE(
    governance.INFORMATION_SCHEMA.POLICY_REFERENCES(
      REF_ENTITY_DOMAIN => 'TABLE',
      REF_ENTITY_NAME => 'finance.accounting.name_number'
      )
   );
   

   Copy

   Résultat (notez les colonnes mises à jour) :

   ------------+----------------+--------------------------------+----------------+-------------------+-----------------+-----------------+-------------------+-----------------+----------------------+--------------+------------+-----------------------+---------------+
    POLICY_DB  | POLICY_SCHEMA  | POLICY_NAME                    |  POLICY_KIND   | REF_DATABASE_NAME | REF_SCHEMA_NAME | REF_ENTITY_NAME | REF_ENTITY_DOMAIN | REF_COLUMN_NAME | REF_ARG_COLUMN_NAMES | TAG_DATABASE | TAG_SCHEMA | TAG_NAME              | POLICY_STATUS |
   ------------+----------------+--------------------------------+----------------+-------------------+-----------------+-----------------+-------------------+-----------------+----------------------+--------------+------------+-----------------------+---------------+
    GOVERNANCE | MASKING_POLICY | ACCOUNT_NAME_MASK_TAG_STRING   | MASKING_POLICY | FINANCE           | ACCOUNTING      | NAME_NUMBER     | TABLE             | ACCOUNT_NAME    | NULL                 | GOVERNANCE   | TAGS       | ACCOUNTING_COL_STRING | ACTIVE        |
    GOVERNANCE | MASKING_POLICY | ACCOUNT_NUMBER_MASK_TAG_STRING | MASKING_POLICY | FINANCE           | ACCOUNTING      | NAME_NUMBER     | TABLE             | ACCOUNT_NUMBER  | NULL                 | GOVERNANCE   | TAGS       | ACCOUNTING_COL_STRING | ACTIVE        |
   ------------+----------------+--------------------------------+----------------+-------------------+-----------------+-----------------+-------------------+-----------------+----------------------+--------------+------------+-----------------------+---------------+
   

6. Interrogez les colonnes de la table pour vous assurer que Snowflake renvoie le résultat correct de la requête, qui ne doit masquer que la valeur de la colonne ACCOUNT_NUMBER.

   USE ROLE accounting_admin;
   SELECT * FROM finance.accounting.name_number;
   

   Copy

   Renvoie :

   ---------------+----------------+
     ACCOUNT_NAME | ACCOUNT_NUMBER |
   ---------------+----------------+
     ACME         | -1             |
   ---------------+----------------+
   

Exemple 3 : Protéger une table en fonction de la valeur de la chaîne de balises de la table¶

Cet exemple utilise une politique d’accès aux lignes pour protéger une table en fonction d’une valeur de chaîne de balises attribuée à la table et une politique de masquage basée sur les balises pour protéger les colonnes de la table. Pour plus de simplicité, cet exemple utilise une balise, affecte les politiques de masquage à la balise et affecte la balise à la table. Les colonnes de la table auront automatiquement la même balise et sa valeur de chaîne en raison de la lignée de balises.

La politique d’accès aux lignes évalue dynamiquement la valeur de la chaîne de balises de la balise affectée à la table en appelant la fonction SYSTEM$GET_TAG_ON_CURRENT_TABLE dans les conditions de la politique d’accès aux lignes. Comme dans l’exemple précédent, les conditions de la politique de masquage appellent la fonction SYSTEM$GET_TAG_ON_CURRENT_COLUMN pour évaluer la valeur de la chaîne de balises sur les colonnes de la table.

La table finance.accounting.name_number possède deux colonnes, qui ont les types de données STRING et NUMBER :

---------------+----------------+
  ACCOUNT_NAME | ACCOUNT_NUMBER |
---------------+----------------+
  ACME         | 1000           |
---------------+----------------+

Protégez la table et ses colonnes à l’aide d’une politique d’accès aux lignes et d’une politique de masquage basée sur les balises, comme suit :

1. Créez une politique d’accès aux lignes qui appelle la fonction SYSTEM$GET_TAG_ON_CURRENT_TABLE dans les conditions de la politique :

   USE ROLE row_access_admin;
   USE SCHEMA governance.row_access_policies;
   
   CREATE ROW ACCESS POLICY rap_tag_value
   AS (account_number number)
   RETURNS BOOLEAN ->
   SYSTEM$GET_TAG_ON_CURRENT_TABLE('tags.accounting_row_string') = 'visible'
   AND
   'accounting_admin' = CURRENT_ROLE();
   

   Copy

   La politique spécifie que Snowflake renvoie des lignes dans le résultat de la requête uniquement lorsque la balise accounting_row_string est attribuée à la table avec une valeur de chaîne comme 'visible' et le rôle exécutant la requête sur la table ou ses colonnes est le rôle personnalisé accounting_admin.

   Snowflake ne renvoie pas de lignes dans le résultat de la requête si l’une des conditions suivantes est remplie :

   • La balise accounting_row_string n’est pas définie sur la table.

   • La balise accounting_row_string est définie sur la table, mais avec une valeur de chaîne différente.

   • Le rôle qui exécute une requête sur la table ou ses colonnes n’est pas le rôle personnalisé accounting_admin.

2. Attribuez la politique d’accès aux lignes à la table :

   ALTER TABLE finance.accounting.name_number
     ADD ROW ACCESS POLICY rap_tag_value ON (account_number);
   

   Copy

   Notez qu’à ce stade de la procédure, une requête sur la table ne devrait pas renvoyer de lignes dans le résultat de la requête pour n’importe quel rôle dans Snowflake, car la balise accounting_row_string n’est pas attribuée à la table. Ainsi, le résultat attendu d’une requête sur la table devrait être le suivant :

   USE ROLE accounting_admin;
   SELECT * FROM finance.accounting.name_number;
   

   Copy

   Renvoie :

   ---------------+----------------+
     ACCOUNT_NAME | ACCOUNT_NUMBER |
   ---------------+----------------+
                  |                |
   ---------------+----------------+
   

   En choisissant d’affecter la politique d’accès aux lignes à la table avant d’affecter la politique de masquage basée sur les balises à la table, toutes les données de la table sont protégées le plus tôt possible.

3. Créez une balise nommée accounting_row_string dans le schéma nommé governance.tags.

   USE ROLE tag_admin;
   USE SCHEMA governance.tags;
   CREATE TAG accounting_row_string;
   

   Copy

4. Créez différentes politiques de masquage pour protéger les colonnes ACCOUNT_NAME et ACCOUNT_NUMBER. Dans chacune de ces politiques, les données brutes sont visibles uniquement lorsque la valeur de la chaîne de balises actuelle de la colonne est définie sur 'visible'.

   Politique de nom de compte :

   USE ROLE masking_admin;
   USE SCHEMA governance.masking_policies;
   
   CREATE MASKING POLICY account_name_mask AS (val string) RETURNS string ->
     CASE
       WHEN SYSTEM$GET_TAG_ON_CURRENT_COLUMN('tags.accounting_row_string') = 'visible' THEN val
       ELSE '***MASKED***'
     END;
   

   Copy

   Politique relative au numéro de compte :

   CREATE MASKING POLICY account_number_mask AS (val number) RETURNS number ->
     CASE
       WHEN SYSTEM$GET_TAG_ON_CURRENT_COLUMN('tags.accounting_row_string') = 'visible' THEN val
       ELSE -1
     END;
   

   Copy

5. Assignez les deux politiques de masquage à la balise accounting_row_string. Notez que les deux politiques peuvent être assignées à la balise dans une seule instruction.

   ALTER TAG governance.tags.accounting_row_string SET
     MASKING POLICY account_name_mask,
     MASKING POLICY account_number_mask;
   

   Copy

6. Attribuez la balise accounting_row_string à la table avec la valeur de la chaîne de balises 'visible' :

   ALTER TABLE finance.accounting.name_number
     SET TAG governance.tags.accounting_row_string = 'visible';
   

   Copy

   Maintenant que la balise est attribuée à la table avec une valeur de chaîne visible, seul le rôle personnalisé accounting_admin peut voir les données de la table ; une requête effectuée par un utilisateur avec un autre rôle ne devrait pas renvoyer de lignes, comme indiqué précédemment dans cet exemple. En d’autres termes, les conditions de la politique d’accès aux lignes correspondent maintenant à Vrai.

   De même, les colonnes de la table ont également la valeur de la chaîne de la balise visible car les colonnes héritent de la balise et de sa valeur par l’intermédiaire de la lignée de balises. Résultat, lorsqu’un utilisateur avec le rôle personnalisé accounting_admin interroge la table, Snowflake renvoie des données non masquées :

   USE ROLE accounting_admin;
   SELECT * FROM finance.accounting.name_number;
   

   Copy

   Renvoie :

   ---------------+----------------+
     ACCOUNT_NAME | ACCOUNT_NUMBER |
   ---------------+----------------+
     ACME         | 1000           |
   ---------------+----------------+
   

7. Pour masquer les données de l’une ou l’autre des colonnes, mettez directement à jour la valeur de la chaîne de balises de la colonne. Par exemple, pour masquer les données de la colonne ACCOUNT_NUMBER :

   ALTER TABLE finance.accounting.name_number MODIFY COLUMN
     account_number SET TAG governance.tags.accounting_row_string = 'protect';
   

   Copy

   Maintenant, lorsqu’un utilisateur avec le rôle personnalisé accounting_admin interroge la table ou la colonne ACCOUNT_NUMBER, Snowflake renvoie des données masquées :

   USE ROLE accounting_admin;
   SELECT * FROM finance.accounting.name_number;
   

   Copy

   Renvoie :

   ---------------+----------------+
     ACCOUNT_NAME | ACCOUNT_NUMBER |
   ---------------+----------------+
     ACME         | -1             |
   ---------------+----------------+