Politiques de masquage basées sur les balises

Cette rubrique fournit des concepts sur les politiques de masquage basées sur les balises et des exemples de politiques de masquage basées sur les balises pour protéger les données des colonnes.

Dans ce chapitre :

Vue d’ensemble

Une politique de masquage basée sur les balises combine les fonctions de balisage d’objets et de politique de masquage pour permettre de définir une politique de masquage sur une balise à l’aide d’une commande ALTER TAG. Lorsque le type de données dans la signature de la politique de masquage et le type de données de la colonne correspondent, la colonne balisée est automatiquement protégée par les conditions de la politique de masquage. Cela simplifie les efforts de protection des données, car les données de la colonne qui doivent être protégées ne nécessitent plus une politique de masquage appliquée manuellement à la colonne pour protéger les données. Une colonne peut être protégée par une politique de masquage directement attribuée à une colonne et par une politique de masquage basée sur des balises. Si une colonne fait référence à ces deux politiques de masquage, la politique de masquage qui est directement affectée à la colonne a la priorité sur la politique de masquage basée sur les balises.

La balise peut prendre en charge une politique de masquage pour chaque type de données pris en charge par Snowflake. Pour simplifier les efforts initiaux de protection des données de la colonne, créez une politique de masquage générique pour chaque type de données (par exemple, STRING, NUMBER, TIMESTAMP_LTZ) qui permet aux rôles autorisés de voir les données brutes et aux rôles non autorisés de voir une valeur masquée fixe.

Les conditions de la politique de masquage peuvent être écrites pour protéger les données de la colonne en fonction de la politique affectée à la balise ou pour protéger les données de la colonne en fonction de la valeur de la chaîne de balises de la balise affectée à la colonne, en fonction des décisions de l’administrateur de la politique, de l’administrateur des balises et du responsable des données.

Pour des exemples de politiques de masquage basées sur les balises, voir la section Utilisation des politiques de masquage basées sur les balises (dans cette rubrique).

Avantages

Facilité d’utilisation

L’attribution d’une ou plusieurs politiques de masquage à une balise est simple. Les administrateurs de politiques peuvent ajouter ou remplacer des politiques sans interrompre les flux de travail existants.

Évolutivité

Les politiques basées sur des balises permettent aux administrateurs de politiques de rédiger une politique une fois, d’affecter une politique à une balise une fois et, selon le niveau auquel la balise est définie, de faire en sorte que la politique s’applique à de nombreux objets. Cela permet de réduire considérablement l’affectation manuelle d’une politique unique à une colonne unique chaque fois qu’une nouvelle colonne est créée ou remplacée.

Exhaustivité

Les administrateurs de politiques peuvent créer une politique pour chaque type de données et affecter toutes ces politiques à une seule balise. Une fois que la balise est appliquée au niveau de la table, toutes les colonnes de la table sont protégées, à condition que le type de données de la colonne corresponde au type de données spécifié dans la politique.

Protéger les objets futurs

L’affectation d’une politique de masquage basée sur des balises à une table applique automatiquement la politique de masquage à toutes les nouvelles colonnes de la table. Ce comportement est analogue à celui des autorisations futures.

Flexibilité

Les politiques de masquage basées sur les balises offrent une alternative à la spécification de la politique de masquage dans une instruction CREATE TABLE, ce qui contribue à simplifier la gestion des DDL de tables. Les administrateurs peuvent choisir d’affecter la politique de masquage soit à la création de la table, soit en affectant la politique à la balise, qui utilise le lignage de balise.

Considérations

  • Dans le cas d’une politique de masquage basée sur des balises, où la balise est stockée dans un schéma différent de celui de la politique et de la table de masquage, le clonage du schéma contenant la politique et la table de masquage fait que la table clonée est protégée par la politique de masquage dans le schéma source et non dans le schéma cloné.

    Cependant, pour une politique de masquage basée sur une balise, où la balise, la politique de masquage et la table existent toutes dans le schéma, le clonage du schéma fait que la table est protégée par la politique de masquage dans le schéma cloné, et non dans le schéma source.

  • En ce qui concerne la réplication et les politiques de masquage basées sur les balises, voir les considérations sur la réplication des politiques.

  • Pour plus de détails sur Partage des données sécurisé dans Snowflake et cette fonctionnalité, voir :

Limites

Toutes les limitations existantes de la politique de masquage s’appliquent aux politiques de masquage basées sur les balises.

Notez les limitations supplémentaires suivantes lors de l’utilisation de politiques de masquage basées sur les balises :

Types de données

Une balise peut prendre en charge une politique de masquage pour chaque type de données. Par exemple, si une balise possède déjà une politique de masquage pour le type de données NUMBER, vous ne pouvez pas attribuer une autre politique de masquage avec le type de données NUMBER à la même balise.

Balises système

Une politique de masquage ne peut pas être assignée à un système de balises.

Destruction d’objets

Ni la politique de masquage ni la balise ne peuvent être détruites si la politique de masquage est attribuée à une balise. De même, le schéma et la base de données parents contenant la balise et la politique de masquage ne peuvent pas être détruits si la politique est affectée à une balise. Pour plus d’informations, voir Affectation (dans cette rubrique).

Vues matérialisées

Une vue matérialisée ne peut pas être créée si la table sous-jacente est protégée par une politique de masquage basée sur des balises. Pour plus de détails, voir Politiques de masquage et vues matérialisées.

Si une vue matérialisée existe et qu’une politique de masquage basée sur des balises est ajoutée ultérieurement à la table sous-jacente, la vue matérialisée ne peut pas être interrogée ; la vue matérialisée est désormais invalidée. Pour continuer à utiliser la vue matérialisée, désactivez la politique de masquage basée sur les balises, recréez ou relancez, puis interrogez la vue matérialisée.

Politiques d’accès aux lignes

Une colonne de table ou de vue donnée peut être spécifiée soit dans une signature de politique de masquage, soit dans une signature de politique d’accès aux lignes. En d’autres termes, la même colonne ne peut pas être spécifiée à la fois dans une signature de politique de masquage et dans une signature de politique d’accès aux lignes.

Colonnes conditionnelles

Une colonne masquée ne peut pas être utilisée comme colonne conditionnelle dans une politique de masquage.

Tables de mappage

Une table contenant une colonne protégée par une politique de masquage basée sur des balises ne peut pas être utilisée comme table de mappage.

Colonnes virtuelles

Bien que l’on puisse attribuer une balise à une colonne virtuelle, on ne peut pas lui attribuer une politique de masquage basée sur des balises. Si une politique basée sur des balises est affectée à une colonne virtuelle, la requête sur la colonne échoue au moment de l’exécution.

Gestion des politiques de masquage basées sur les balises

Les privilèges existants pour les politiques de masquage et les balises, ainsi que le DDL pour gérer les politiques de masquage et les balises, s’appliquent aux politiques de masquage basées sur les balises.

Cependant, il y a des mises à jour supplémentaires du privilège APPLY MASKING POLICY, de la commande ALTER TAG et des opérations DROP/REPLACE lorsque la politique et la balise se trouvent dans la même base de données/le même schéma parent.

Privilège

Un rôle doté du privilège global APPLY MASKING POLICY peut définir une politique de masquage sur une balise et supprimer une politique de masquage d’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;

Affectation

Utilisez une commande ALTER TAG pour définir une politique de masquage sur une balise ou pour annuler une politique de masquage d’une balise. Notez que la syntaxe de la commande ALTER TAG permet d’assigner plusieurs politiques de masquage à une balise dans une seule instruction :

ALTER TAG <tag_name> SET MASKING POLICY <masking_policy_name> [ , MASKING POLICY <masking_policy_2_name> , ... ]

ALTER TAG <tag_name> UNSET MASKING POLICY <masking_policy_name> [ , MASKING POLICY <masking_policy_2_name> , ... ]

Par exemple, assignez la politique de masquage nommée ssn_mask à la balise nommée security :

-- set
alter tag security set masking policy ssn_mask;

-- unset

alter tag security unset masking policy ssn_mask;

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 :

Base de données et schéma parents

L’activation du groupe de changement de comportement 2022_07 empêche les 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.

L’activation du groupe affecte les quatre commandes suivantes :

  • DROP DATABASE

  • DROP SCHEMA

  • CREATE OR REPLACE DATABASE

  • CREATE OR REPLACE SCHEMA

Pour plus de détails, voir l’annonce.

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.

Utilisation de politiques de masquage basées sur des balises

Les sous-sections ci-dessous fournissent les informations suivantes :

  • Une procédure commune à utiliser avec les politiques de masquage basées sur des balises pour la protection et la validation des données.

  • Étapes préalables à effectuer avant de mettre en œuvre des politiques de masquage basées sur les balises.

  • Une liste d’hypothèses communes pour les exemples.

  • Exemples représentatifs de l’utilisation d’une politique de masquage basée sur des balises, y compris l’utilisation des fonctions système suivantes :

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épannage 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;
    
  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;
    

    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;
    
  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;
    
  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';
    
  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' )
    );
    

    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;
    

    Renvoie :

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

    Non autorisé :

    use role analyst;
    select* from finance.accounting.name_number;
    

    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;
    
  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;
    

    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;
    

    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;
    
  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';
    
  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' )
    );
    

    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;
    

    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.

Important

Notez que vous ne pouvez pas affecter de politique d’accès aux lignes à la balise.

Au lieu de cela, affectez la politique d’accès aux lignes à la table directement en utilisant une commande ALTER 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();
    

    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);
    

    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;
    

    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;
    
  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;
    

    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;
    
  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;
    
  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';
    

    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;
    

    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';
    

    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;
    

    Renvoie :

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

Dépannage des politiques de masquage basées sur les balises

Le tableau suivant répertorie certains messages d’erreur que Snowflake peut renvoyer lors de l’utilisation de politiques de masquage basées sur des balises :

Comportement

Message d’erreur

Action de dépannage

Impossible d’interroger une colonne : trop de politiques.

Erreur d’exécution SQL : la colonne <nom_col> est mappée à plusieurs politiques de masquage par des balises. Veuillez contacter votre administrateur local pour résoudre le problème.

Une colonne donnée ne peut être protégée que par une seule politique de masquage.

Appelez la fonction POLICY_REFERENCES pour identifier les politiques de masquage définies sur la colonne. Modifiez les balises en désactivant la politique de masquage de la balise afin que la colonne soit protégée par une seule politique.

Impossible d’interroger une colonne : aucune colonne conditionnelle.

Erreur d’exécution SQL : la colonne <nom_col> est mappée à une politique de masquage où la table n’a pas de colonne pour un nom d’argument secondaire de la politique. Veuillez contacter votre administrateur local pour résoudre le problème.

Une politique de masquage qui utilise des arguments conditionnels doit avoir toutes les colonnes spécifiées dans la même table ou vue. Effectuez l’une des actions suivantes pour protéger les données de la colonne :

  • Attribuez une politique différente à la colonne directement.

  • Modifiez la balise en assignant une politique de masquage différente à la balise.

Les données de la colonne ne sont pas masquées en raison d’une inadéquation entre le type de données de la colonne et la politique.

Erreur d’exécution SQL : la colonne <nom_col> est mappée à une politique de masquage où la table possède une colonne avec un type de donnée différent pour le nom d’argument secondaire. Veuillez contacter votre administrateur local pour résoudre le problème.

Pour masquer les données de la colonne, le type de données de la colonne et le type de données de la signature de la politique de masquage doivent correspondre. Effectuez l’une des actions suivantes pour protéger les données de la colonne :

  • Attribuez une politique différente à la colonne directement.

  • Attribuez une politique de masquage à la balise, en veillant à ce que le type de données de la politique et le type de données de la colonne correspondent.

Revenir au début