Comprendre la sécurité au niveau des colonnes

Cette rubrique fournit une présentation générale de la sécurité au niveau des colonnes et décrit les fonctionnalités et la prise en charge communes au masquage dynamique des données et à la tokenisation externe.

Pour en savoir plus sur l’utilisation d’une politique de masquage avec une balise, voir Politiques de masquage basées sur les balises.

Qu’est-ce que la sécurité au niveau des colonnes ?

La sécurité au niveau des colonnes dans Snowflake permet l’application d’une politique de masquage à une colonne dans une table ou une vue. Actuellement, la sécurité au niveau des colonnes comprend deux fonctionnalités :

  1. Masquage dynamique des données

  2. Tokenisation externe

Le masquage dynamique des données est une fonctionnalité de sécurité au niveau des colonnes qui utilise des politiques de masquage pour masquer sélectivement les données en texte brut dans les tables et voir les colonnes au moment de la requête.

La tokenisation externe permet aux comptes de tokeniser les données avant de les charger dans Snowflake et de détokeniser ces données lors de l’exécution de la requête. La tokenisation est le processus de suppression des données sensibles en les remplaçant par un jeton (token, en anglais) indéchiffrable. La tokenisation externe utilise des politiques de masquage avec des fonctions externes.

Politiques de masquage : de quoi s’agit-il ?

Snowflake prend en charge les politiques de masquage en tant qu’objet de niveau schéma pour protéger les données sensibles contre les accès non autorisés tout en permettant aux utilisateurs autorisés d’accéder aux données sensibles lors de l’exécution de la requête. Cela signifie que les données sensibles dans Snowflake ne sont pas modifiées dans une table existante (c’est-à-dire pas de masquage statique). Au contraire, lorsque les utilisateurs exécutent une requête dans laquelle une politique de masquage s’applique, les conditions de politique de masquage déterminent si les utilisateurs non autorisés voient les données masquées, partiellement masquées, floutées ou tokenisées. Le masquage des politiques en tant qu’objet au niveau du schéma offre également une flexibilité dans le choix d’une approche de gestion centralisée, décentralisée ou hybride. Pour plus d’informations, consultez Gestion de la sécurité au niveau des colonnes (dans cette rubrique).

Les politiques de masquage peuvent inclure des conditions et des fonctions pour transformer les données lors de l’exécution de la requête lorsque ces conditions sont remplies. L’approche basée sur les politiques prend en charge la séparation des tâches pour permettre aux équipes de sécurité de définir des politiques qui peuvent limiter l’exposition des données sensibles, y compris par rapport aux propriétaires d’un objet (c’est-à-dire le rôle avec le privilège OWNERSHIP sur l’objet, comme une table ou une vue) et qui ont normalement un accès complet aux données sous-jacentes.

L'administrateur de politiques de masquage peut appliquer des politiques de masquage à des tables et des vues.

Par exemple, les administrateurs de politiques de masquage peuvent implémenter une politique de masquage de sorte que les analystes (c’est-à-dire les utilisateurs avec le rôle ANALYST personnalisé) ne puissent afficher que les quatre derniers chiffres d’un numéro de téléphone et aucun du numéro de sécurité sociale, tandis que les représentants du support client (par exemple, les utilisateurs avec le rôle SUPPORT personnalisé) peuvent afficher l’intégralité du numéro de téléphone et du numéro de sécurité sociale pour les cas d’utilisation de vérification client.

Résultats des politiques de masquage pour les rôles autorisés et non autorisés.

Une politique de masquage consiste en un seul type de données, une ou plusieurs conditions et une ou plusieurs fonctions de masquage.

Alors que Snowflake propose des vues sécurisées pour restreindre l’accès aux données sensibles, les vues sécurisées présentent des défis de gestion en raison du grand nombre de vues et de tableaux de bord décisionnels en découlant (BI) de chaque vue. Les politiques de masquage résolvent ce défi de gestion en évitant une explosion de vues et de tableaux de bord à gérer.

Les politiques de masquage prennent en charge la séparation des tâches (SoD) grâce à la séparation des rôles entre les administrateurs de politiques et les propriétaires d’objets. Les vues sécurisées n’ont pas de SoD, ce qui constitue une limitation profonde de leur utilité. Cette séparation des rôles conduit aux paramètres par défaut suivants :

  • Les propriétaires d’objets (c’est-à-dire le rôle qui a le privilège OWNERSHIP sur l’objet) n’ont pas le privilège de désactiver les politiques de masquage.

  • Les propriétaires d’objets ne peuvent pas afficher les données de colonnes dans lesquelles une politique de masquage s’applique.

Pour plus d’informations sur la gestion des rôles et des privilèges, voir Gestion de la sécurité au niveau des colonnes (dans cette rubrique) et Privilèges de contrôle d’accès.

Comment fonctionne une politique de masquage ?

Les politiques de masquage pour le masquage dynamique des données et la tokenisation externe adoptent la même structure et le même format à une exception notable : les politiques de masquage pour la tokenisation externe nécessitent l’utilisation de Écriture de fonctions externes dans le corps de la politique de masquage.

La raison de cette exception est que la tokenisation externe nécessite qu’un fournisseur de tokenisation tiers tokenize les données avant de charger les données dans Snowflake. Au moment de l’exécution de la requête, Snowflake utilise la fonction externe pour effectuer un appel API REST au fournisseur de tokenisation, qui évalue ensuite une politique de tokenisation (créée en dehors de Snowflake) pour renvoyer des données tokenisées ou détokenisées en fonction des conditions de politiques de masquage. Notez que le mappage des rôles doit exister dans Snowflake et le fournisseur de tokenisation pour garantir que les données correctes puissent être renvoyées à partir d’une requête donnée.

Snowflake prend en charge la création de politiques de masquage à l’aide de CREATE MASKING POLICY. Par exemple :

-- Dynamic Data Masking

CREATE MASKING POLICY employee_ssn_mask AS (val string) RETURNS string ->
  CASE
    WHEN CURRENT_ROLE() IN ('PAYROLL') THEN val
    ELSE '******'
  END;

-- External Tokenization

  CREATE MASKING POLICY employee_ssn_detokenize AS (val string) RETURNS string ->
  CASE
    WHEN CURRENT_ROLE() IN ('PAYROLL') THEN ssn_unprotect(VAL)
    ELSE val -- sees tokenized data
  END;
Copy

Où :

employee_ssn_mask

Nom de la politique de masquage dynamique des données.

employee_ssn_detokenize

Nom de la politique de tokenisation externe.

AS (val string) RETURNS string

Spécifie les types de données d’entrée et de sortie. Les types de données doivent correspondre.

->

Sépare la signature de la politique de son corps.

case ... end;

Spécifie les conditions du corps de la politique de masquage (c’est-à-dire l’expression SQL).

Dans ces deux exemples, si l’opérateur de requête utilise le rôle personnalisé PAYROLL dans la session en cours, l’opérateur voit la valeur non masquée/détokenisée. Sinon, une valeur masquée/tokenisée fixe est visible.

ssn_unprotect

La fonction externe pour opérer sur les données tokenisées.

Astuce

Si vous souhaitez mettre à jour une politique de masquage existante et si vous avez besoin de voir la définition actuelle de cette politique, appelez la fonction GET_DDL ou exécutez la commande DESCRIBE MASKING POLICY .

La définition de la politique de masquage peut alors être mise à jour avec la commande ALTER MASKING POLICY. Cette commande ne nécessite pas la suppression d’une politique de masquage d’une colonne, si la politique de masquage est définie sur une colonne. Ainsi, une colonne qui est protégée par une politique le reste pendant la mise à jour de la définition de la politique.

Pour plus de détails sur l’utilisation des politiques de masquage, voir :

Utilisez des colonnes conditionnelles

Le masquage conditionnel utilise une politique de masquage pour protéger de manière sélective les données des colonnes d’une table ou d’une vue en fonction des valeurs d’une ou plusieurs colonnes différentes.

L’utilisation d’une colonne différente pour déterminer si les données d’une colonne donnée doivent être protégées offre aux administrateurs de politiques (c’est-à-dire aux utilisateurs ayant le rôle personnalisé POLICY_ADMIN) une plus grande liberté pour créer des conditions de politique.

Notez la différence entre ces deux exemples représentatifs de politiques :

Politique de masquage:

Cette politique peut être utilisée pour le masquage dynamique des données.

CREATE MASKING POLICY email_mask AS
(val string) RETURNS string ->
  CASE
    WHEN CURRENT_ROLE() IN ('PAYROLL') THEN val
    ELSE '******'
  END;
Copy

Cette politique ne spécifie qu’un seul argument, val, qui représente toute colonne contenant des données de type chaîne. Cette politique peut être créée une fois et appliquée à toute colonne contenant des données de type chaîne. Seuls les utilisateurs dont CURRENT_ROLE est le rôle personnalisé PAYROLL peuvent voir les données de la colonne. Sinon, Snowflake renvoie une valeur masquée fixe dans le résultat de la requête.

Pour plus d’informations, voir CREATE MASKING POLICY.

Politique de masquage conditionnelle:

Notez les arguments, (email varchar, visibility string), dans cet exemple.

CREATE MASKING POLICY email_visibility AS
(email varchar, visibility string) RETURNS varchar ->
  CASE
    WHEN CURRENT_ROLE() = 'ADMIN' THEN email
    WHEN VISIBILITY = 'PUBLIC' THEN email
    ELSE '***MASKED***'
  END;
Copy

Cette politique spécifie deux arguments, email et visibility, et ces arguments sont des noms de colonnes. La première colonne spécifie toujours la colonne à masquer. La deuxième colonne est une colonne conditionnelle permettant d’évaluer si la première colonne doit être masquée. Plusieurs colonnes conditionnelles peuvent être spécifiées. Dans cette politique, les utilisateurs dont CURRENT_ROLE est le rôle personnalisé ADMIN peuvent voir l’adresse e-mail. Si l’adresse e-mail a également une valeur Public dans la colonne de visibilité, alors l’adresse e-mail est visible dans le résultat de la requête. Sinon, Snowflake renvoie un résultat de requête avec une valeur masquée fixe pour la colonne e-mail.

Cette politique peut être utilisée sur plusieurs tables et vues à condition que la structure des colonnes de la table ou de la vue corresponde aux colonnes spécifiées dans la politique. Pour plus d’informations, voir CREATE MASKING POLICY.

Puisque le même type d’objet est utilisé pour chaque exemple représentatif, le comportement général des politiques devrait être similaire, y compris, mais sans s’y limiter :

  • Évaluation de l’exécution des requêtes.

  • Utilité (par exemple, protection des données sensibles, utilisation de Fonctions contextuelles).

  • Structure des privilèges.

  • Utilisation de différentes approches de gestion pour prendre en charge la séparation des tâches (SoD).

Limitations:

En plus des limitations existantes de la politique de masquage, les politiques de masquage conditionnelles présentent les limitations suivantes :

Considérations:

En plus des considérations relatives aux politiques de masquage normales, évaluez les points suivants avant d’utiliser les politiques de masquage conditionnelles :

  • Assurez-vous que toutes les colonnes spécifiées dans l’instruction CREATE MASKING POLICY résident dans la même table ou vue.

  • Réduisez au minimum le nombre d’arguments de colonne dans la définition de la politique. Snowflake doit évaluer chaque colonne au moment de l’exécution de la requête. En spécifiant moins de colonnes, les performances sont globalement plus rapides.

  • Suivez l’utilisation des colonnes conditionnelles dans une politique de masquage en appelant la fonction de table Information Schema POLICY_REFERENCES.

Pour plus de détails sur la définition de politiques de masquage avec des colonnes conditionnelles, voir Appliquez une politique de masquage conditionnelle sur une colonne (dans cette rubrique).

Politiques de masquage lors de l’exécution de la requête

Au moment de l’exécution, Snowflake réécrit la requête pour appliquer l’expression de la politique de masquage aux colonnes spécifiées dans la politique de masquage. La politique de masquage est appliquée à la colonne, quel que soit l’endroit dans une expression SQL où la colonne est référencée, notamment :

  • Projections.

  • Prédicats JOIN.

  • Prédicats de la clause WHERE.

  • Clauses ORDER BY et GROUP BY.

Important

Une politique de masquage est délibérément appliquée partout où la colonne pertinente est référencée par une construction SQL pour empêcher la désanonymisation des données via des requêtes créatives afin d’inclure les données de colonne masquées.

Par conséquent, si l’exécution d’une requête entraîne des données masquées dans une ou plusieurs colonnes, la sortie de la requête peut ne pas fournir la valeur attendue, car les données masquées empêchent d’évaluer toutes les données de sortie de la requête dans le contexte souhaité.

Masquage des politiques avec des objets imbriqués :

Snowflake prend en charge les politiques de masquage imbriquées, telles qu’une politique de masquage sur une table et une politique de masquage sur une vue pour la même table. Au moment de l’exécution de la requête, Snowflake évalue toutes les politiques de masquage pertinentes pour une requête donnée dans l’ordre suivant :

  1. La politique de masquage applicable à la table est toujours exécutée en premier.

  2. La politique de la vue est exécutée après avoir évalué la politique de la table.

  3. Si des vues imbriquées existent (par exemple, table_1 » view_1 » view_2 » … view_n), les politiques sont appliquées dans un ordre séquentiel de gauche à droite.

Ce modèle se poursuit selon le nombre de politiques qui existent en ce qui concerne les données de la requête. Le diagramme suivant illustre la relation entre un exécutant de requête, des tables, des vues et des politiques.

Politiques de masquage avec des tables et des vues.

Requêtes d’utilisateurs :

L’exemple suivant montre une requête soumise par l’utilisateur suivie de la réécriture de la requête d’exécution Snowflake dans laquelle la politique de masquage (c’est-à-dire sql_expression) s’applique uniquement à la colonne email.

SELECT email, city
FROM customers
WHERE city = 'San Mateo';

SELECT <SQL_expression>(email), city
FROM customers
WHERE city = 'San Mateo';
Copy

Requête avec une colonne protégée dans le prédicat de clause WHERE (anti-modèle) :

Les exemples suivants montrent une requête soumise par l’utilisateur suivie de la réécriture de la requête d’exécution Snowflake dans laquelle la politique de masquage (c’est-à-dire sql_expression) s’applique à un seul côté d’une comparaison (par exemple, la colonne e-mail, mais pas la chaîne à laquelle la colonne e-mail est comparée). Les résultats de la requête ne sont pas ce que l’utilisateur voulait obtenir. Masquer un seul côté d’une comparaison est un anti-modèle courant.

SELECT email
FROM customers
WHERE email = 'user@example.com';

SELECT <SQL_expression>(email)
FROM customers
WHERE <SQL_expression>(email) = 'user@example.com';
Copy

Requête avec une colonne protégée dans le prédicat JOIN (anti-modèle) :

SELECT b.email, d.city
FROM
  sf_tuts.public.emp_basic AS b
  JOIN sf_tuts.public.emp_details AS d ON b.email = d.email;

SELECT
  <SQL_expression>(b.email),
  d.city
FROM
  sf_tuts.public.emp_basic AS b
  JOIN sf_tuts.public.emp_details AS d ON <SQL_expression>(b.email) = <SQL_expression>(d.email);
Copy

Considérations relatives à l’exécution des requêtes

Snowflake recommande de prendre en compte les facteurs suivants lors de la tentative de prédiction de l’effet de l’application d’une politique de masquage à une colonne et si l’opérateur de la requête voit les données masquées :

La session en cours:

Conditions de la politique de masquage avec CURRENT_ROLE.

Le rôle d’exécution:

Conditions de la politique de masquage avec INVOKER_ROLE.

Hiérarchie des rôles:

Conditions de la politique de masquage avec IS_ROLE_IN_SESSION ou IS_GRANTED_TO_INVOKER_ROLE.

Partage de données:

Indique si les données sont partagées à l’aide de Secure Data Sharing. Pour plus de détails, voir Partage de données (dans ce chapitre).

Réplication:

Voir Réplication (dans cette rubrique).

Sous-requêtes:

Une politique de masquage peut faire référence à une sous-requête dans la définition de la politique, cependant, il y a des limites à la prise en charge de la sous-requête dans Snowflake. Pour plus d’informations, voir Utilisation des sous-requêtes.

UDFs dans une politique de masquage:

Assurez-vous que le type de données de la colonne, l’UDF, et la politique de masquage correspondent. Pour plus d’informations, voir Fonctions définies par l’utilisateur dans une politique de masquage (dans ce chapitre).

Service d’optimisation de la recherche:

Le service d’optimisation de la recherche peut améliorer les performances des requêtes sur une table qui utilise une politique de masquage ou d’accès aux lignes.

Pour plus de détails, voir Prise en charge des tables avec des politiques de masquage et des politiques d’accès aux lignes dans le service d’optimisation de la recherche.

Les trois premiers éléments sont expliqués plus en détail dans Rubriques de sécurité avancées au niveau des colonnes. Le partage de données ne s’applique qu’au masquage dynamique des données car les fonctions externes ne peuvent pas être appelées dans le contexte d’un partage.

En fin de compte, le cas d’utilisation spécifique détermine si le masquage dynamique des données ou la tokenisation externe est le mieux adapté.

Choix du masquage dynamique des données ou de la tokenisation externe

Pour choisir la fonctionnalité appropriée qui répond le mieux aux besoins de votre organisation, évaluez les principaux cas d’utilisation de vos données ainsi que les considérations et limitations pertinentes. Les deux sections suivantes résument les avantages et les limites entre les deux fonctionnalités.

Avantages

Le tableau suivant compare les avantages du masquage dynamique des données et de la tokenisation externe.

Facteur

Masquage dynamique des données

Tokenisation externe

Remarques

Préservez la valeur analytique après la désidentification.

Comme la tokenisation fournit une valeur unique pour un ensemble donné de caractères, il est possible de regrouper des enregistrements par une valeur tokenisée sans révéler les informations sensibles.

Par exemple, regrouper des enregistrements médicaux par code de diagnostic avec le code de diagnostic du patient tokenisé. Les analystes de données peuvent ensuite interroger une vue sur le code de diagnostic pour obtenir un décompte du nombre de patients avec un code de diagnostic unique.

Préchargez les données tokenisées.

Les utilisateurs non autorisés ne voient jamais la valeur réelle des données. Nécessite un fournisseur de tokenisation tiers.

Préchargez les données non masquées.

Ne nécessite que la fonctionnalité intégrée de Snowflake, aucun tiers requis.

Data Sharing.

Pour plus de détails, voir Partage de données (dans ce chapitre).

Facilité d’utilisation et gestion du changement.

Écrivez une politique une fois et appliquez-la à des milliers de colonnes dans les bases de données et les schémas.

Administration des données et SoD.

Un responsable de la sécurité ou de la confidentialité décide quelles colonnes protéger, et non le propriétaire de l’objet.

Les politiques de masquage sont faciles à gérer et prennent en charge des modèles d’administration centralisés et décentralisés.

Autorisation et gouvernance des données.

Accès aux données contextuelles par rôle ou droits personnalisés.

Prend en charge la gouvernance des données telle que la mise en œuvre par des responsables de la sécurité ou de la confidentialité et peut interdire aux utilisateurs ayant les privilèges adéquats et les rôles système ACCOUNTADMIN ou SECURITYADMIN de visualiser inutilement les données.

Réplication des bases de données et réplication des objets du compte.

Voir : Réplication (dans cette rubrique).

Limitations

Le tableau suivant décrit les limitations actuelles de la sécurité au niveau des colonnes. Une coche (c’est-à-dire ✔) indique une limitation ou un manque de prise en charge actuelle de la fonctionnalité.

Limitation

Masquage dynamique des données

Tokenisation externe

Remarques

Vues matérialisées (MV).

Pour un résumé complet, voir Vues matérialisées (dans ce chapitre).

DROP MASKING POLICY

Avant de détruire une politique, désactivez-la de la table ou de la colonne d’affichage à l’aide de ALTER TABLE … ALTER COLUMN ou ALTER VIEW.

DROP DATABASE et DROP SCHEMA

La destruction d’une base de données ou d’un schéma nécessite que la politique de masquage et ses mappages soient autonomes dans une base de données et un schéma.

Par exemple, database_1 contient policy_1 et policy_1 n’est utilisé que dans database_1.

Tables externes.

Une table externe ne peut pas être référencée comme une table de consultation (c’est-à-dire dans une sous-requête) pour déterminer si les valeurs des colonnes doivent être masquées. Pour plus d’informations, voir Tables externes (dans ce chapitre).

Différents types de données dans l’entrée et la sortie d’une définition de politique.

Une définition de politique de masquage doit avoir le même type de données pour l’entrée et la sortie. En d’autres termes, à titre d’exemple représentatif, vous ne pouvez pas définir le type de données d’entrée comme un horodatage et renvoyer une chaîne.

Gestion du changement et politique de masquage.

Vous pouvez éventuellement stocker et suivre les modifications de politiques de masquage dans un système de contrôle de version de votre choix.

Autorisations futures.

Les autorisations futures de privilèges sur les politiques de masquage ne sont pas prises en charge.

Comme solution de contournement, accordez le privilège APPLY MASKING POLICY à un rôle personnalisé pour lui permettre d’appliquer des politiques de masquage aux colonnes de tables ou de vues.

Considérations

  • Faites preuve de prudence lorsque vous insérez des valeurs d’une colonne source qui a une politique de masquage sur la colonne source vers une colonne cible sans politique de masquage sur la colonne cible. Étant donné qu’une politique de masquage est définie sur la colonne source, un rôle qui visualise les données d’une colonne non masquée peut insérer des données non masquées dans une autre colonne, dans laquelle tout rôle disposant de privilèges suffisants sur la table ou la vue peut en voir la valeur.

  • Si un rôle qui voit des données masquées dans la colonne source insère ces valeurs dans une colonne cible, les valeurs insérées restent masquées. Si une politique de masquage n’est pas définie sur la colonne cible, les utilisateurs disposant de privilèges suffisants sur la table ou la vue peuvent voir une combinaison de valeurs masquées et non masquées dans la colonne cible. Par conséquent, en tant que meilleure pratique :

    • Faites preuve de prudence lorsque vous appliquez des politiques de masquage aux colonnes.

    • Vérifiez les requêtes à l’aide de colonnes qui ont des politiques de masquage avant de mettre les tables et les vues à la disposition des utilisateurs.

    • Déterminez des tables et des vues supplémentaires (c’est-à-dire des colonnes cibles) dans lesquelles les données de la colonne source peuvent apparaître.

    • Pour plus d’informations, voir Obtenir des colonnes avec une politique de masquage (dans ce chapitre).

  • Soyez prudent(e) lors de la création du script de configuration d’une Snowflake Native App lorsque la politique de masquage existe dans un schéma versionné. Pour des informations détaillées, voir Considérations sur les schémas versionnés.

Utilisation de la sécurité au niveau des colonnes sur les tables et les vues

Snowflake prend en charge les politiques de masquage avec des tables et des vues. Ce qui suit décrit comment les politiques de masquage affectent les tables et les vues dans Snowflake.

Astuce

Appelez la fonction POLICY_CONTEXT pour simuler une requête sur une colonne protégée par une politique de masquage, une table ou une vue protégée par une politique d’accès aux lignes, ou les deux types de politiques.

Hiérarchie des rôles actifs et tables de mappage

Les conditions de la politique peuvent évaluer directement les rôles principaux et secondaires actifs de l’utilisateur dans une session, rechercher des rôles actifs dans une table de mappage ou faire les deux selon la façon dont l’administrateur de la politique veut écrire la politique. Si la politique contient une consultation de table de mappage, créez une table de mappage centralisée et stockez la table de mappage dans la même base de données que la table protégée. Ceci est particulièrement important si la politique appelle la fonction IS_DATABASE_ROLE_IN_SESSION. Pour des informations détaillées, voir les notes sur l’utilisation de la fonction.

Pour ces cas d’utilisation, Snowflake recommande d’écrire les conditions de la politique pour appeler la fonction IS_ROLE_IN_SESSION ou IS_DATABASE_ROLE_IN_SESSION selon que vous souhaitez spécifier un rôle de compte ou un rôle de base de données. Pour des exemples, voir :

Pour des exemples supplémentaires utilisant des fonctions contextuelles et des politiques de masquage, voir Rubriques de sécurité avancées au niveau des colonnes.

Appliquez des politiques de masquage aux colonnes

Lorsqu’une colonne n’est pas protégée par une politique de masquage, il existe deux options pour appliquer une politique de masquage à une colonne dans une table ou une vue :

  1. Avec une table ou une vue nouvelle, appliquez la politique à une colonne de table avec une instruction CREATE TABLE ou à une colonne de vue avec une instruction CREATE VIEW.

  2. Avec une table ou une vue existante, appliquez la politique à une colonne de table avec une instruction ALTER TABLE … ALTER COLUMN ou à une colonne de vue avec une instruction ALTER VIEW.

Pour une table ou une vue nouvelle, exécutez les instructions suivantes :

-- table
CREATE OR REPLACE TABLE user_info (ssn string masking policy ssn_mask);

-- view
CREATE OR REPLACE VIEW user_info_v (ssn masking policy ssn_mask_v) AS SELECT * FROM user_info;
Copy

Pour une table ou une vue existante, exécutez les instructions suivantes :

-- table
ALTER TABLE IF EXISTS user_info MODIFY COLUMN ssn_number SET MASKING POLICY ssn_mask;

-- view
ALTER VIEW user_info_v MODIFY COLUMN ssn_number SET MASKING POLICY ssn_mask_v;
Copy

Pour plus d’informations sur la syntaxe et l’utilisation, voir ALTER TABLE … ALTER COLUMN et ALTER VIEW.

Si la politique de masquage utilise une UDF, voir Fonctions définies par l’utilisateur dans une politique de masquage (dans cette rubrique).

Appliquez une politique de masquage conditionnelle sur une colonne

Après avoir créé une politique de masquage en utilisant des colonnes conditionnelles, il existe deux options pour définir une politique de masquage sur une colonne lorsque la colonne n’est pas déjà protégée par une politique de masquage :

  1. Pour une table ou une vue nouvelle, appliquez la politique à une colonne de table ou de vue avec l’instruction CREATE correspondante.

    Pour plus d’informations sur la syntaxe et l’utilisation, voir :

    Pour une table ou une vue nouvelle, exécutez les instructions suivantes :

    -- table
    CREATE OR REPLACE TABLE user_info (email string masking policy email_visibility) USING (email, visibility);
    
    --view
    CREATE OR REPLACE VIEW user_info_v (email masking policy email_visibility) USING (email, visibility) AS SELECT * FROM user_info;
    
    Copy
  2. Pour une table ou une vue existante, définissez la politique sur une colonne de table ou de vue avec l’instruction ALTER correspondante.

    Pour plus d’informations sur la syntaxe et l’utilisation, voir :

    Pour une table ou une vue existante, exécutez les instructions suivantes :

    -- table
    ALTER TABLE IF EXISTS user_info MODIFY COLUMN email
    SET MASKING POLICY email_visibility USING (EMAIL, VISIBILITY);
    
    -- VIEW
    ALTER VIEW user_info_v MODIFY COLUMN email
    SET MASKING POLICY email_visibility USING (email, visibility);
    
    Copy

Remplacez une politique de masquage sur une colonne

Une fois qu’une politique de masquage est définie sur une colonne, il existe deux façons de remplacer la politique de masquage sur la colonne par une politique de masquage différente sans avoir à remplacer la table ou la vue entière.

Ces exemples utilisent des commandes ALTER TABLE. La même approche s’applique aux vues avec la commande ALTER VIEW :

  • Annulez la politique d’une colonne de table dans une instruction, puis définissez une nouvelle politique sur la colonne dans une autre instruction :

    ALTER TABLE t1 MODIFY COLUMN c1 UNSET MASKING POLICY;
    
    ALTER TABLE t1 MODIFY COLUMN c1 SET MASKING POLICY p2;
    
    Copy
  • Utilisez le mot-clé FORCE pour remplacer la politique dans une seule instruction :

    ALTER TABLE t1 MODIFY COLUMN c1 SET MASKING POLICY p2 FORCE;
    
    Copy

    Remarque :

    • Le mot-clé FORCE exige que le type de données de la politique dans l’instruction ALTER TABLE (c’est-à-dire STRING) corresponde au type de données de la politique de masquage actuellement définie sur la colonne (c’est-à-dire STRING).

    • Notez que le mot clé FORCE peut être combiné avec la clause USING pour définir une politique de masquage conditionnel sur la colonne :

      ALTER TABLE t1 MODIFY COLUMN c1 SET MASKING POLICY policy1 USING (c1, c3, c4) FORCE;
      
      Copy

Important

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

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, puis remplacez les politiques de masquage si nécessaire.

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.

Ce comportement s’applique également aux colonnes utilisées comme colonnes conditionnelles dans une politique de masquage.

Pour plus d’informations, voir CREATE MASKING POLICY et CREATE ROW ACCESS POLICY.

Simulez le fonctionnement d’une politique

Appelez la fonction POLICY_CONTEXT pour simuler une requête sur une colonne protégée par une politique de masquage, une table ou une vue protégée par une politique d’accès aux lignes, ou les deux types de politiques.

Vues matérialisées

Snowflake permet de définir une politique de masquage sur une colonne de vue matérialisée. Au moment de l’exécution de la requête, le plan de requête exécute toute politique de masquage présente avant la création de la réécriture de la vue matérialisée. Une fois la réécriture de la vue matérialisée effectuée, les politiques de masquage ne peuvent plus être définies sur aucune colonne de la vue matérialisée.

Il existe deux options pour définir une politique de masquage sur une colonne de vue matérialisée :

  1. Pour une vue matérialisée nouvelle, exécutez une instruction CREATE MATERIALIZED VIEW.

  2. Pour une vue matérialisée existante, exécutez une instruction ALTER VIEW … MODIFY COLUMN sur la vue matérialisée.

Pour une vue matérialisée nouvelle, exécutez l’instruction suivante :

CREATE OR REPLACE MATERIALIZED VIEW user_info_mv
  (ssn_number masking policy ssn_mask)
AS SELECT ssn_number FROM user_info;
Copy

Pour une vue matérialisée existante, voir l’exemple de vue dans la section Appliquer des politiques de masquage aux colonnes (dans cette rubrique).

En outre, les deux limitations suivantes existent concernant les politiques de masquage et les vues matérialisées :

  1. Une politique de masquage ne peut pas être définie sur une colonne de table si une vue matérialisée est déjà créée à partir de la table sous-jacente. Snowflake renvoie le message d’erreur suivant lorsque cette tentative est effectuée :

    SQL execution error: One or more materialized views exist on the table. number of mvs=<number>, table name=<table_name>.
    
    Copy
  2. Si une politique de masquage est définie sur une colonne de table sous-jacente et qu’une vue matérialisée est créée à partir de cette table, la vue matérialisée ne contient que les colonnes qui ne sont pas protégées par une politique de masquage. Snowflake renvoie également le message d’erreur suivant si la tentative d’inclure une ou plusieurs colonnes protégées par une politique de masquage :

    Unsupported feature 'CREATE ON MASKING POLICY COLUMN'.
    
    Copy

Obtenez des colonnes avec une politique de masquage

Pour obtenir une liste de colonnes avec des politiques de masquage, exécutez l’instruction suivante. Pour plus d’informations, voir POLICY_REFERENCES.

SELECT * from table(
  INFORMATION_SCHEMA.POLICY_REFERENCES(
    policy_name=>'<policy_name>'
  )
);
Copy

Exécutez une instruction DESCRIBE TABLE ou DESCRIBE VIEW pour afficher la politique de masquage sur la colonne d’une table ou d’une vue.

Politiques de balisage et de masquage des objets

Pour plus de détails, voir Politiques de masquage basées sur les balises.

Notez qu’une politique de masquage directement affectée à une colonne a la priorité sur une politique de masquage basée sur des balises.

Fonctions de hachage, de cryptage et de chiffrement dans les politiques de masquage

Le hachage et Cryptographique/Somme de contrôle peuvent être utilisés dans les politiques de masquage pour masquer les données sensibles.

Pour plus d’informations, voir Rubriques de sécurité avancées au niveau des colonnes.

Tables externes

Vous ne pouvez pas attribuer une politique de masquage à la colonne VALUE de la table externe lorsque vous créez la table externe avec une instruction CREATE EXTERNAL TABLE car cette colonne est automatiquement créée par défaut.

Vous pouvez attribuer la politique de masquage à la colonne VALUE de table externe en exécutant une instruction ALTER TABLE … ALTER COLUMN sur la table externe. Le type de données de la politique de masquage qui protège la colonne VALUE doit être VARIANT.

ALTER TABLE t1 MODIFY COLUMN VALUE SET MASKING POLICY p1;
Copy

Vous pouvez attribuer une politique de masquage à une colonne virtuelle d’une table externe de la manière suivante :

  • Définissez la propriété EXEMPT_OTHER_POLICIES de la politique de masquage sur TRUE dans la politique de masquage qui protège la colonne VALUE dans la table externe.

    Si cette propriété n’est pas déjà définie, exécutez une instruction CREATE OR REPLACE sur la politique de masquage qui protège la colonne VALUE et spécifiez la propriété EXEMPT_OTHER_POLICIES. La colonne virtuelle hérite de la politique qui protège la colonne VALUE, et cette propriété permet à la politique de la colonne virtuelle de remplacer la politique héritée. Pour plus de détails, voir CREATE MASKING POLICY.

  • Attribuez une politique de masquage différente à la colonne virtuelle à l’aide d’une commande ALTER TABLE. Cette politique peut être moins stricte que celle de la colonne VALUE car la colonne virtuelle est moins sensible. La colonne virtuelle contient moins de données que la colonne VALUE ; la colonne VALUE contient toutes les données de chaque ligne de la table externe.

    Le type de données de la politique qui protège la colonne virtuelle dépend du type de données de la colonne virtuelle.

Concernant les colonnes conditionnelles dans une politique de masquage, une colonne virtuelle peut être répertoriée comme un argument de colonne conditionnelle pour déterminer si le premier argument de la colonne doit être masqué ou tokenisé. Cependant, une colonne virtuelle ne peut pas être spécifiée comme la première colonne à masquer ou à tokeniser.

Pour plus d’informations, voir CREATE MASKING POLICY.

Important

Snowflake ne prend pas en charge l’utilisation d’une table externe comme table de consultation (c’est-à-dire dans une sous-requête) dans une politique de masquage. Lors du clonage d’une base de données, Snowflake clone la politique de masquage, mais pas la table externe. Par conséquent, la politique dans la base de données clonée fait référence à une table qui n’est pas présente dans la base de données clonée.

Si les données de la table externe sont nécessaires pour la politique, envisagez de déplacer les données de la table externe vers un schéma dédié de la base de données dans laquelle la politique de masquage existe avant de réaliser une opération de clonage. Mettez à jour la politique de masquage pour faire référence au nom de table entièrement qualifié afin de vous assurer que la politique fait référence à une table dans la base de données clonée.

Flux

Les politiques de masquage des colonnes d’une table sont transférées dans un flux de la même table.

Résultat : les utilisateurs non autorisés voient les données masquées ; les flux créés par des utilisateurs autorisés voient les données telles que définies par la politique de masquage.

Objets clonés

L’approche suivante permet de protéger les données des utilisateurs avec le privilège SELECT sur la table ou la vue lors de l’accès à un objet cloné :

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

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

  • Une table clonée correspond aux mêmes politiques que la table source. En d’autres termes, si une politique est définie sur la table de base ou ses colonnes, la politique est attachée à la table clonée ou ses colonnes.

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

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

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

Instructions CREATE TABLE … AS SELECT (CTAS)

L’exécution d’une instruction CREATE TABLE… AS SELECT (CTAS) applique toutes les politiques de masquage sur les colonnes incluses dans l’instruction avant que les données soient remplies dans la nouvelle table (c’est-à-dire que les données de colonne applicables sont masquées dans la nouvelle table). Ce flux est respecté, car une table créée à l’aide d’une instruction CTAS peut avoir un ensemble de colonnes différent de celui des objets sources, et Snowflake ne peut pas appliquer implicitement des politiques de masquage aux nouvelles colonnes de table.

S’il est nécessaire de copier des données non masquées, utilisez un rôle autorisé pour les données protégées afin d’exécuter l’instruction CTAS. Après avoir créé la nouvelle table, transférez la propriété de la nouvelle table à un autre rôle et demandez à l’administrateur de politiques de masquage d’appliquer les politiques de masquage aux colonnes de la nouvelle table.

Pour plus d’informations, voir CREATE TABLE.

Requêtes utilisant des fonctions d’agrégation et des colonnes masquées

Il est possible d’utiliser Fonctions d’agrégation sur des colonnes avec des données masquées.

Un cas d’utilisation représentatif est qu’un analyste de données souhaite obtenir COUNT pour une colonne de numéros de sécurité sociale sans avoir besoin de voir les données réelles. Toutefois, si l’analyste de données exécute une requête à l’aide de SELECT sur une colonne de table masquée, la requête renvoie une valeur masquée fixe. Les utilisateurs avec le rôle personnalisé PAYROLL dans la session en cours voient les données non masquées et tous les autres utilisateurs voit les données masquées.

Pour atteindre ce résultat :

  1. Le propriétaire de la table crée une vue sur la colonne qui contient la fonction d’agrégation.

    CREATE VIEW ssn_count AS SELECT DISTINCT(ssn) FROM table1;
    
    Copy
  2. Accordez au rôle ANALYST des privilèges complets sur la vue. N’accordez à l’analyste aucun privilège sur la table.

  3. Appliquez une politique de masquage à la colonne de table. Notez que la politique de table est toujours appliquée avant la politique de vue, s’il existe une politique sur une colonne de vue.

    CASE
      WHEN CURRENT_ROLE() IN ('PAYROLL') THEN val
      ELSE '***MASKED***'
    END;
    
    Copy
  4. Exécutez une requête sur la colonne de vue.

    USE ROLE analyst;
    SELECT COUNT(DISTINCT ssn) FROM v1;
    
    Copy

Fonctions définies par l’utilisateur dans une politique de masquage

Une UDF peut être transmise dans les conditions de la politique de masquage.

Il est important de s’assurer que le type de données de la colonne de la table ou de la vue, l’UDF et la politique de masquage correspondent. Si les types de données sont différents, par exemple si une colonne de table et l’UDF ont un type de données VARIANT et que la politique de masquage (avec cette UDF dans les conditions de la politique) renvoie un type de données VARCHAR, Snowflake renvoie une erreur lors d’une requête sur la colonne de table lorsque cette politique de masquage est définie sur la colonne de table.

Pour un exemple représentatif de la correspondance du type de données d’une colonne de table, d’une UDF, et d’une politique de masquage, voir l’exemple Utilisation d’UDFs JavaScript sur JSON (Variante) dans CREATE MASKING POLICY.

Partage de données

Utilisation:
  • Si le fournisseur affecte une politique à une table ou à une vue partagée et que les conditions de la politique appellent la fonction CURRENT_ROLE ou CURRENT_USER, ou que les conditions de la politique appellent une UDF sécurisée, Snowflake renvoie une valeur NULL pour la fonction ou l’UDF dans le compte du consommateur.

    La raison en est que le propriétaire des données partagées ne contrôle généralement pas les utilisateurs ou les rôles du compte avec lequel la table ou la vue est partagée. Comme solution de contournement, utilisez la fonction CURRENT_ACCOUNT dans les conditions de la politique.

    En tant que fournisseur, vous pouvez également écrire les conditions de la politique pour appeler la fonction IS_DATABASE_ROLE_IN_SESSION et partager le rôle de la base de données. En tant que consommateur, accordez le rôle de base de données partagée à un rôle de compte. Pour plus de détails, voir Partagez des données protégées par une politique.

Limitations:
  • Un fournisseur de partage de données ne peut pas créer de politique dans un compte de lecteur.

  • Les consommateurs de partage de données ne peuvent pas appliquer une politique à une table ou une vue partagée. Comme solution de rechange, importez la base de données partagée et créez une vue locale à partir de la table ou de la vue partagée.

  • Les consommateurs de partage de données ne peuvent pas interroger une table ou une vue partagée qui fait référence à deux fournisseurs différents. Par exemple :

    • rap1 est une politique d’accès aux lignes qui protège la table nommée t1, où t1 est dans le partage nommé share1 d’un fournisseur.

    • Les conditions de la politique rap1 font référence à une table de mappage nommée t2, où t2 provient de share2 et d’un fournisseur différent.

    • La requête du consommateur sur t1 échoue.

    • Le fournisseur de t1 peut interroger t1.

  • Fonctions externes :

    Snowflake renvoie une erreur si :

    • La politique affectée à une table ou une vue partagée est mise à jour pour appeler une fonction externe.

    • La politique appelle une fonction externe et vous tentez d’affecter la politique à une table ou une vue partagée.

Note

Pour la tokenisation externe, Secure Data Sharing , n’est pas applicable, car les fonctions externes ne peuvent pas être invoquées dans le contexte d’un partage.

Réplication

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

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

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

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

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

Note

En cas d’utilisation des actions de basculement et de restauration, le compte Snowflake doit être Business Critical Edition ou supérieur.

Pour plus d’informations, voir Présentation de la réplication et du basculement à travers plusieurs comptes.

Profil de requête

Lorsqu’elle est utilisée sur une colonne avec une politique de masquage, la sortie de la commande EXPLAIN inclut les données masquées, pas le corps de la politique de masquage.

L’exemple suivant génère le plan EXPLAIN pour une requête sur une table de numéros d’identification d’employés et de numéros de sécurité sociale. La commande de cet exemple génère l’exemple au format JSON.

La colonne contenant les numéros de sécurité sociale a une politique de masquage.

EXPLAIN USING JSON SELECT * FROM mydb.public.ssn_record;
Copy
{
  "GlobalStats": {
    "partitionsTotal": 0,
    "partitionsAssigned": 0,
    "bytesAssigned": 0
  },
  "Operations": [
    [
      {
        "id": 0,
        "operation": "Result",
        "expressions": [
          "1",
          "'**MASKED**'"
        ]
      },
      {
        "id": 1,
        "parent": 0,
        "operation": "Generator",
        "expressions": [
          "1"
        ]
      }
    ]
  ]
}
Copy

Décharger les données

L’utilisation de la commande COPY INTO <emplacement> sur une colonne dotée d’une politique de masquage entraîne l’application de la politique de masquage aux données. Par conséquent, les utilisateurs non autorisés voient les données masquées après l’exécution de la commande.

Snowflake Native App Framework

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

Gestion de la sécurité au niveau des colonnes

Cette section fournit des informations utiles pour déterminer votre approche de la gestion globale des politiques de masquage, décrit les privilèges requis pour gérer la sécurité au niveau des colonnes et répertorie les commandes DDL prises en charge.

Choisir une approche centralisée, hybride ou décentralisée

Pour gérer efficacement les politiques de masquage dynamique des données et de tokenisation externe, il est utile de déterminer si votre approche du masquage des données dans les colonnes doit suivre une approche de sécurité centralisée, une approche décentralisée ou un hybride de chacune de ces deux approches.

Le tableau suivant résume certaines des considérations relatives à chacune de ces deux approches.

Action de la politique

Gestion centralisée

Gestion hybride

Gestion décentralisée

Créer des politiques

Agent de sécurité

Agent de sécurité

Équipes individuelles

Appliquer des politiques aux colonnes

Agent de sécurité

Équipes individuelles

Équipes individuelles

En tant que meilleure pratique, Snowflake recommande que votre organisation rassemble toutes les parties prenantes concernées afin de déterminer la meilleure approche de gestion pour implémenter la sécurité au niveau des colonnes dans votre environnement.

Privilèges de politique de masquage

Cette section décrit les privilèges de politique de masquage de sécurité au niveau des colonnes et la façon dont ils s’appliquent à une approche de gestion centralisée, décentralisée ou hybride.

Snowflake fournit les privilèges suivants pour les politiques de masquage de sécurité au niveau des colonnes.

Notez que l’exploitation d’un objet dans un schéma requiert également le privilège USAGE sur la base de données et le schéma parents.

Privilège

Utilisation

CREATE

Permet de créer une nouvelle politique de masquage dans un schéma.

APPLY

Permet d’exécuter les opérations non définies et définies pour une politique de masquage sur une colonne.

Notez que l’octroi du privilège global APPLY MASKING POLICY (c’est-à-dire APPLY MASKING POLICY sur ACCOUNT) permet d’exécuter l’opération DESCRIBE sur des tables et des vues.

Pour des exemples de syntaxe, voir Privilèges de politique de masquage.

OWNERSHIP

Permet un contrôle total de la politique de masquage. Nécessaire pour modifier la plupart des propriétés d’une politique de masquage. Un seul rôle peut détenir ce privilège sur un objet spécifique à la fois.

Note

Effectuer des opérations sur une politique de masquage nécessite également le privilège USAGE sur la base de données et le schéma parents.

Les exemples suivants montrent comment l’octroi de privilèges s’applique à différentes approches de gestion. Après avoir accordé le privilège APPLY à un rôle, la politique de masquage peut être définie sur une colonne de table à l’aide d’une instruction ALTER TABLE … ALTER COLUMN ou définie sur une colonne de vue à l’aide d’une instruction ALTER VIEW (par un membre du rôle avec le privilège APPLY sur la politique de masquage).

Gestion centralisée

Dans une approche de gestion centralisée, seul le rôle personnalisé de l’agent de sécurité (par exemple security_officer) crée et applique des politiques de masquage aux colonnes des tables ou des vues. Cette approche peut fournir la plus grande cohérence en matière de gestion des politiques de masquage et de masquage des données sensibles.

-- create a security_officer custom role

USE ROLE ACCOUNTADMIN;
CREATE ROLE security_officer;

-- grant CREATE AND APPLY masking policy privileges to the SECURITY_OFFICER custom role.

GRANT CREATE MASKING POLICY ON SCHEMA mydb.mysch TO ROLE security_officer;

GRANT APPLY MASKING POLICY ON ACCOUNT TO ROLE security_officer;
Copy

Où :

  • schema_name

    Indique l’identificateur du schéma ; doit être unique pour la base de données dans laquelle le schéma est créé.

    De plus, l’identificateur doit commencer par un caractère alphabétique et ne peut pas contenir d’espaces ou de caractères spéciaux à moins que toute la chaîne d’identificateur soit délimitée par des guillemets doubles (p. ex. « Mon objet »). Les identificateurs entre guillemets doubles sont également sensibles à la casse.

    Pour plus de détails, voir Exigences relatives à l’identificateur.

Gestion hybride

Dans une approche de gestion hybride, le rôle personnalisé de l’agent de sécurité (par exemple security_officer) crée des politiques de masquage et des équipes individuelles (par exemple, finances, paie, ressources humaines) les appliquent aux colonnes des tables ou des vues appartenant aux équipes. Cette approche peut conduire à la création et à la maintenance de politiques cohérentes, mais nécessite que chaque équipe ait la responsabilité accrue de masquer les données sensibles.

USE ROLE ACCOUNTADMIN;
CREATE ROLE security_officer;
GRANT CREATE MASKING POLICY ON SCHEMA mydb.mysch TO ROLE security_officer;
Copy

Le rôle personnalisé SECURITY_OFFICER accorde le privilège APPLY à l’équipe des ressources humaines (c’est-à-dire aux utilisateurs avec le rôle personnalisé HUMAN_RESOURCES) pour masquer les numéros de sécurité sociale (par exemple, la politique de masquage : ssn_mask) dans les colonnes pour les objets appartenant au rôle personnalisé HUMAN_RESOURCES.

USE ROLE security_officer;
GRANT APPLY ON MASKING POLICY ssn_mask TO ROLE human_resources;
Copy

Où :

  • grant apply on masking policy policy_name to role role_name;

    Utilisé par un propriétaire de politique pour décentraliser les opérations non définies et définies d’une politique de masquage donnée sur des colonnes vers les propriétaires d’objet.

    Ce privilège prend en charge le contrôle des accès discrétionnaire où les propriétaires d’objets sont également considérés comme des gestionnaires de données.

Approche décentralisée

Dans une approche de gestion décentralisée, chaque équipe crée et applique des politiques de masquage aux colonnes des tables ou des vues. Cette approche peut conduire à une gestion des politiques incohérente, avec la possibilité que les données sensibles ne soient pas correctement masquées, car chaque équipe assume l’entière responsabilité de la gestion des politiques de masquage et du masquage des données sensibles.

Dans cet exemple représentatif, l’équipe d’assistance (c’est-à-dire les utilisateurs avec le rôle personnalisé SUPPORT) et l’équipe financière (c’est-à-dire les utilisateurs avec le rôle personnalisé FINANCE) peuvent créer des politiques de masquage. Notez que ces rôles personnalisés peuvent ne pas inclure le rôle personnalisé SECURITY_OFFICER.

USE ROLE ACCOUNTADMIN;
GRANT CREATE MASKING POLICY ON SCHEMA mydb.mysch TO ROLE support;
GRANT CREATE MASKING POLICY ON SCHEMA <DB_NAME.SCHEMA_NAME> TO ROLE FINANCE;
Copy

L’équipe d’assistance accorde le privilège APPLY à l’équipe des ressources humaines (c’est-à-dire aux utilisateurs avec le rôle personnalisé HUMAN_RESOURCES) pour masquer les numéros de sécurité sociale (par exemple, la politique de masquage : ssn_mask) dans les colonnes pour les objets appartenant au rôle personnalisé HUMAN_RESOURCES.

USE ROLE support;
GRANT APPLY ON MASKING POLICY ssn_mask TO ROLE human_resources;
Copy

L’équipe financière accorde le privilège APPLY à l’équipe d’audit interne (c’est-à-dire aux utilisateurs avec le rôle personnalisé AUDIT_INTERNAL) pour masquer les données de flux de trésorerie (par exemple, la politique de masquage : cash_flow_mask) dans les colonnes pour les objets appartenant au rôle personnalisé AUDIT_INTERNAL.

USE ROLE finance;
GRANT APPLY ON MASKING POLICY cash_flow_mask TO ROLE audit_internal;
Copy

Pour plus d’informations sur les privilèges de politiques de masquage, voir :

DDL de politique de masquage

Snowflake fournit l’ensemble de commandes suivant pour gérer les politiques de masquage de sécurité au niveau des colonnes.

Le tableau suivant résume la relation entre les opérations DDL de masquage de sécurité au niveau des colonnes et leurs privilèges nécessaires.

Notez que l’exploitation d’un objet dans un schéma requiert également le privilège USAGE sur la base de données et le schéma parents.

Fonctionnement

Privilège

Créer une politique de masquage

Un rôle avec le privilège CREATE MASKING POLICY sur SCHEMA.

Modifier la politique de masquage

Le propriétaire de la politique de masquage (c’est-à-dire le rôle avec le privilège OWNERSHIP sur la politique de masquage).

Détruire la politique de masquage

Le propriétaire de la politique de masquage (c’est-à-dire le rôle avec le privilège OWNERSHIP sur la politique de masquage).

Afficher les politiques de masquage

L’un des éléments suivants : . Un rôle avec le privilège APPLY MASKING POLICY global, ou . Le propriétaire de la politique de masquage (c’est-à-dire le rôle avec le privilège OWNERSHIP sur la politique de masquage) ou . Un rôle avec le privilège APPLY sur la politique de masquage.

Décrire la politique de masquage

L’un des éléments suivants : . Un rôle avec le privilège APPLY MASKING POLICY global, ou . Le propriétaire de la politique de masquage (c’est-à-dire le rôle avec le privilège OWNERSHIP sur la politique de masquage) ou . Un rôle avec le privilège APPLY sur la politique de masquage.

Liste des colonnes ayant une politique de masquage

L’un des éléments suivants : . Le rôle avec le privilège APPLY MASKING POLICY, ou . Le rôle avec le privilège APPLY sur MASKING POLICY sur une politique de masquage donnée et le privilège OWNERSHIP sur l’objet cible.

Utilisation des UDFs dans une politique de masquage

Si vous créez une nouvelle politique de masquage ou la modifiez, le rôle d’administrateur de politique doit être utilisé sur l’UDF, toutes les UDFs scalaires dans l’expression de la politique doivent avoir le même type de données et l’UDF doit exister.

Au moment de l’exécution de la requête, Snowflake vérifie si l’UDF existe ; sinon, l’expression SQL ne se résoudra pas et la requête échouera.

Contrôlez des politiques de masquage avec SQL

Vous pouvez contrôler l’utilisation de la politique de masquage à l’aide de deux vues différentes Account Usage et d’une table Information Schema.

Il peut être utile de penser à deux approches générales pour déterminer comment surveiller l’utilisation de la politique de masquage.

Découvrez les politiques de masquage

Vous pouvez utiliser la vue MASKING_POLICIES dans le schéma Account Usage de la base de données partagée SNOWFLAKE. Cette vue est un catalogue de toutes les politiques de masquage de votre compte Snowflake. Par exemple :

SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.MASKING_POLICIES
ORDER BY POLICY_NAME;
Copy

Identifier les affectations

Snowflake prend en charge différentes options pour identifier les affectations de politiques de masquage, de balises, selon que la requête doit cibler le compte ou une base de données spécifique.

  • Requête au niveau du compte :

    Utilisez la vue Account Usage POLICY_REFERENCES pour déterminer toutes les colonnes qui ont une politique de masquage. Par exemple :

    SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.POLICY_REFERENCES
    ORDER BY POLICY_NAME, REF_COLUMN_NAME;
    
    Copy
  • Requête au niveau de la base de données :

    Chaque base de données Snowflake comprend un Schéma d’information de Snowflake. Utilisez la fonction de table Information Schema POLICY_REFERENCES pour déterminer toutes les politiques de masquage sur les colonnes d’une table donnée :

    SELECT *
    FROM TABLE(
      my_db.INFORMATION_SCHEMA.POLICY_REFERENCES(
        'my_table',
        'table'
      )
    );
    
    Copy

    Vous pouvez également utiliser cette fonction pour interroger le nom de la politique de masquage afin de trouver les objets associés à une politique de masquage donnée.

Contrôlez des politiques de masquage avec Snowsight

Vous pouvez utiliser la zone Snowsight Monitoring » Governance pour surveiller l’utilisation des politiques et des balises avec les tables, les vues et les colonnes, et établir des rapports à ce sujet. Il existe deux interfaces différentes : Dashboard et Tagged Objects.

Lors de l’utilisation de l’interface Dashboard et de l’interface Tagged Objects, il convient de tenir compte des détails suivants.

  • Les interfaces Dashboard et Tagged Objects nécessitent un entrepôt en service.

  • Snowsight met à jour le Dashboard toutes les 12 heures.

  • Le temps de latence de l’information Tagged Objects peut aller jusqu’à deux heures et les retours jusqu’à 1 000 objets.

Accès à la zone de gouvernance dans Snowsight

Pour accéder à la zone Governance , votre compte Snowflake doit être Enterprise Edition ou supérieur. En outre, vous devez effectuer l’une des opérations suivantes :

  • Utilisez le rôle ACCOUNTADMIN.

  • Utilisez un rôle de compte auquel sont directement attribués les rôles de base de données GOVERNANCE_VIEWER et OBJECT_VIEWER.

    Vous devez utiliser un rôle de compte avec ces attributions de rôle de base de données. Actuellement, Snowsight n’évalue pas les hiérarchies de rôles et les rôles de base de données définis par l’utilisateur qui ont accès aux tables, aux vues, aux politiques d’accès aux données et aux balises.

    Pour déterminer si votre rôle de compte bénéficie de ces deux rôles de base de données, utilisez une commande SHOW GRANTS :

    SHOW GRANTS LIKE '%VIEWER%' TO ROLE data_engineer;
    
    Copy
    |-------------------------------+-----------+---------------+-----------------------------+------------+-----------------+--------------+------------|
    | created_on                    | privilege | granted_on    | name                        | granted_to | grantee_name    | grant_option | granted_by |
    |-------------------------------+-----------+---------------+-----------------------------+------------+-----------------+--------------+------------|
    | 2024-01-24 17:12:26.984 +0000 | USAGE     | DATABASE_ROLE | SNOWFLAKE.GOVERNANCE_VIEWER | ROLE       | DATA_ENGINEER   | false        |            |
    | 2024-01-24 17:12:47.967 +0000 | USAGE     | DATABASE_ROLE | SNOWFLAKE.OBJECT_VIEWER     | ROLE       | DATA_ENGINEER   | false        |            |
    |-------------------------------+-----------+---------------+-----------------------------+------------+-----------------+--------------+------------|
    

    Si votre rôle de compte ne bénéficie pas de l’un ou de l’autre de ces rôles de base de données, ou n’en a aucun des deux, utilisez la commande GRANT DATABASE ROLE et exécutez de nouveau la commande SHOW GRANTS pour confirmer les attributions :

    USE ROLE ACCOUNTADMIN;
    GRANT DATABASE ROLE SNOWFLAKE.GOVERNANCE_VIEWER TO ROLE data_engineer;
    GRANT DATABASE ROLE SNOWFLAKE.OBJECT_VIEWER TO ROLE data_engineer;
    SHOW GRANTS LIKE '%VIEWER%' TO ROLE data_engineer;
    
    Copy

    Pour plus de détails sur ces rôles de base de données, consultez Rôles des bases de données SNOWFLAKE.

Tableau de bord

En tant qu’administrateur de données, vous pouvez utiliser l’interface Dashboard pour surveiller l’utilisation des balises et des politiques de la manière suivante.

  • Couverture : spécifie le nombre et le pourcentage en fonction de la présence d’une politique ou d’une balise dans une table, une vue ou une colonne.

  • Prévalence : liste et compte les politiques et les balises les plus fréquemment utilisées.

La couverture et la prévalence donnent un aperçu de la qualité de la protection et du balisage des données.

Lorsque vous sélectionnez un nombre, un pourcentage, un nom de politique ou un nom de balise, l’interface Tagged Objects s’ouvre. L’interface Tagged Objects met à jour les filtres automatiquement en fonction de votre sélection dans l’interface Dashboard.

Les informations de surveillance constituent une alternative ou un complément à l’exécution d’opérations complexes et exigeantes en requêtes sur plusieurs vues Account Usage.

Ces vues peuvent inclure, sans s’y limiter, les vues COLUMNS, POLICY_REFERENCES, TABLES, TAG_REFERENCES, et VIEWS.

Objets balisés

En tant qu’administrateur de données, vous pouvez utiliser cette table pour associer rapidement la couverture et la prévalence dans Dashboard à une liste de tables, de vues ou de colonnes spécifiques. Vous pouvez également filtrer manuellement les résultats de la table, comme suit.

  • Choisissez Tables ou Columns.

  • Pour les balises, vous pouvez filtrer avec les balises, sans les balises ou par une balise spécifique.

  • Pour les politiques, vous pouvez filtrer avec les politiques, sans les politiques ou par une politique spécifique.

Lorsque vous sélectionnez une ligne dans la table, l’onglet Table Details ou Columns de Data » Databases s’ouvre. Vous pouvez modifier les attributions des balises et des politiques si nécessaire.

Astuce

Vous pouvez utiliser Snowsight pour dépanner les affectations de politiques de masquage. Dans l’onglet Columns, la colonne MASKING POLICY affiche Policy Error lorsqu’il y a un conflit avec l’affectation de la politique de masquage sur la colonne. Vous pouvez sélectionner Policy Error pour plus d’informations.

En outre, l’onglet Data Preview n’affiche pas d’aperçu des données en cas d’erreur dans l’affectation d’une politique de masquage à une colonne. Au lieu de cela, l’onglet Data Preview renvoie le message d’erreur SQL. Ce message correspond à l’une des valeurs d’erreur de la colonne POLICY_STATUS de la vue POLICY_REFERENCES Account Usage et de la fonction de table POLICY_REFERENCES Information Schema.

Pour corriger l’erreur, utilisez le message d’erreur SQL et le message Policy Error pour modifier l’affectation de la balise ou de la politique.

Pour plus de détails, voir Découverte des balises et des politiques