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. Vous pouvez définir une politique de masquage basée sur des balises pour une base de données, un schéma ou une table.

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.

Choisissez une base de données, un schéma ou une table pour l’affectation de la politique

Les ingénieurs et gestionnaires de données peuvent choisir d’affecter la politique de masquage basée sur les balises à une base de données, un schéma, une table ou une colonne.

Base de données et schéma:

Lorsque vous définissez une politique de masquage basée sur des balises sur une base de données ou un schéma, vous tirez parti du lignage de balises pour protéger les colonnes des tables et des vues dans le schéma ou la base de données. La définition d’une politique de masquage basée sur des balises sur la base de données ou le schéma protège les colonnes de cette base de données ou de ce schéma lorsque le type de données de la colonne correspond au type de données de la politique de masquage définie sur la balise.

Le principal avantage de la définition d’une politique de masquage basée sur des balises dans la base de données ou le schéma est que les colonnes de toutes les tables et vues venant d’être ajoutées sont automatiquement protégées lorsque le type de données de la colonne correspond au type de données de la politique de masquage. Cette approche simplifie la gestion de la protection des données, car il n’est plus nécessaire de définir de balises sur chaque table. Résultat : la politique protège les nouvelles données dans Snowflake jusqu’à ce qu’un responsable de la protection des données décide d’attribuer soit une politique de masquage à la colonne directement, soit une politique d’accès aux lignes à la table ou à la vue.

Tables:

Lorsque vous définissez une politique de masquage basée sur des balises sur une table, la balise est définie sur toutes les colonnes de la table. La politique de masquage protège les données de la colonne lorsque le type de données de la colonne correspond au type de données de la politique de masquage.

Une colonne peut être protégée par une politique de masquage directement attribuée à la 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.

Pour des exemples de politiques de masquage basées sur les balises, voir la section Utilisez 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.

    Si la table est clonée ou déplacée vers un autre schéma ou une autre base de données et qu’elle était à l’origine protégée par une politique de masquage basée sur des balises définie sur le schéma ou la base de données, la table n’est pas protégée par la politique de masquage basée sur des balises définie sur le schéma ou la base de données source. La table est protégée par la politique de masquage basée sur les balises définie sur le schéma ou la base de données cible, s’il existe une politique de masquage basée sur les balises définie sur le schéma ou la base de données cible.

  • 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 Secure Data Sharing et cette fonctionnalité, voir :

Limitations

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 Affecter une politique de masquage à une balise (dans ce chapitre).

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.

Snowflake Native App Framework:

Pour des informations détaillées sur l’utilisation de politiques de masquage basées sur des balises avec une Snowflake Native App, voir :

Gérer des politiques de masquage basées sur les balises

Les privilèges existants pour les politiques de masquage et les balises, ainsi que les commandes pour gérer les politiques de masquage et les balises, s’appliquent aux 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 :

Astuce

Pour éviter les conflits avec les balises et les politiques de masquage lors de la définition d’une politique de masquage basée sur des balises sur un schéma ou une base de données, procédez ainsi avant d’attribuer la politique de masquage basée sur les balises :

  • Interrogez la vue TAG_REFERENCES Account Usage pour vérifier les balises existantes définies sur une table ou une colonne d’une table.

  • Interrogez la vue POLICY_REFERENCES Account Usage pour déterminer si une politique de masquage basée sur des balises est définie sur une table ou une colonne. Pour plus de détails, reportez-vous à Découverte des balises et des politiques.

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 :

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 :

Utiliser des politiques de masquage basées sur les 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é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.

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

Dépanner 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.