Utilisation du masquage dynamique des données¶

Cette rubrique fournit des instructions sur la configuration et l’utilisation du masquage dynamique des données dans Snowflake.

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

Utilisation du masquage dynamique des données¶

Ce qui suit répertorie les étapes de haut niveau pour configurer et utiliser le masquage dynamique des données dans Snowflake :

Accordez des privilèges de gestion des politiques de masquage à un rôle personnalisé pour un responsable de la sécurité ou de la confidentialité.
Accordez le rôle personnalisé aux utilisateurs appropriés.
Le responsable de la sécurité ou de la confidentialité crée et définit des politiques de masquage et les applique aux colonnes contenant des données sensibles.
Exécutez des requêtes dans Snowflake. Remarques :
- Snowflake réécrit dynamiquement la requête en appliquant l’expression SQL de la politique de masquage à la colonne.
- La réécriture de colonne se produit à chaque endroit où la colonne spécifiée dans la politique de masquage apparaît dans la requête (par exemple, projections, prédicat de jointure, prédicat de clause where, trier par et regrouper par).
- Les utilisateurs voient les données masquées en fonction des conditions de contexte d’exécution définies dans les politiques de masquage. Pour plus d’informations sur le contexte d’exécution dans les politiques de masquage dynamique des données, voir Rubriques de sécurité avancées au niveau des colonnes.

Appliquer des politiques de masquage dynamiques des données sur les tables Apache Iceberg interrogées à partir d’Apache Spark™¶

Snowflake prend en charge l’application de politiques de masquage dynamiques des données sur les tables Apache Iceberg que vous interrogez à partir d’Apache Spark™ via le Snowflake Horizon Catalog. Pour plus d’informations, voir Renforcer les politiques de protection des données lors de l’interrogation de tables Apache Iceberg™ Apache Spark™.

Étape 1 : accordez des privilèges de politiques de masquage au rôle personnalisé¶

Un responsable de la sécurité ou de la confidentialité doit servir d’administrateur de politiques de masquage (c’est-à-dire un rôle personnalisé : MASKING_ADMIN) et avoir les privilèges pour définir, gérer et appliquer des politiques de masquage aux colonnes.

Snowflake fournit les privilèges suivants à accorder à un responsable de la sécurité ou de la confidentialité pour les politiques de masquage de sécurité au niveau des colonnes :


Privilège	Object	Description
CREATE MASKING POLICY	Schema	This privilege controls who can create masking policies.
APPLY MASKING POLICY	Account	This privilege controls who can [un]set masking policies on columns and is granted to the ACCOUNTADMIN role by default. . This privilege only allows applying a masking policy to a column and does not provide any additional table privileges described in Privilèges de contrôle d’accès.
APPLY	Masking policy	En option. Ce privilège au niveau de la politique peut être utilisé par un propriétaire de politique pour décentraliser les opérations de définition/annulation d’une politique de masquage donnée sur des colonnes vers les propriétaires d’objet (c’est-à-dire le rôle qui a le privilège OWNERSHIP sur l’objet). . Snowflake prend en charge le contrôle d’accès discrétionnaire dans lequel les propriétaires d’objets sont également considérés comme des gestionnaires de données. . Si l’administrateur de politique fait confiance aux propriétaires d’objets pour être des gestionnaires de données pour les colonnes protégées, alors l’administrateur de politique peut utiliser ce privilège pour décentraliser l’application des opérations de définition/annulation de politiques.

L’exemple suivant crée le rôle MASKING_ADMIN et accorde des privilèges de politiques de masquage à ce rôle.

Créer un rôle personnalisé d’administrateur de politique de masquage :

use role useradmin;
CREATE ROLE masking_admin;

Accorder des privilèges au rôle masking_admin :

use role securityadmin;
GRANT CREATE MASKING POLICY on SCHEMA <db_name.schema_name> to ROLE masking_admin;
GRANT APPLY MASKING POLICY on ACCOUNT to ROLE masking_admin;

Permettre au rôle table_owner d’activer ou de désactiver la politique de masquage ssn_mask (facultatif) :

GRANT APPLY ON MASKING POLICY ssn_mask to ROLE table_owner;

Où :

db_name.schema_name
Indique l’identificateur du schéma pour lequel le privilège doit être accordé.

Pour plus d’informations, voir :

Étape 2 : accordez le rôle personnalisé à un utilisateur¶

Accordez le rôle personnalisé MASKING_ADMIN à un utilisateur faisant office de responsable de la sécurité ou de la confidentialité.

GRANT ROLE masking_admin TO USER jsmith;

Étape 3 : créez une politique de masquage¶

À l’aide du rôle MASKING_ADMIN, créez une politique de masquage et appliquez-la à une colonne.

Dans cet exemple représentatif, les utilisateurs avec le rôle ANALYST voient la valeur non masquée. Les utilisateurs sans le rôle ANALYST voient un masque complet.

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

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 .

Étape 4 : appliquez la politique de masquage à une colonne de table ou de vue¶

Ces exemples supposent qu’une politique de masquage n’est pas appliquée à la colonne de la table lorsque celle-ci est créée et à la colonne de la vue lorsque celle-ci est créée. Vous pouvez éventuellement appliquer une politique de masquage à une colonne de table lorsque vous créez la table avec une instruction CREATE TABLE ou une colonne de vue avec une instruction CREATE VIEW.

Exécutez les instructions suivantes pour appliquer la politique à une colonne de table ou une colonne de vue.

-- apply masking policy to a table column

ALTER TABLE IF EXISTS user_info MODIFY COLUMN email SET MASKING POLICY email_mask;

-- apply the masking policy to a view column

ALTER VIEW user_info_v MODIFY COLUMN email SET MASKING POLICY email_mask;

Étape 5 : interrogez les données dans Snowflake¶

Exécutez deux requêtes différentes dans Snowflake, une requête avec le rôle ANALYST et une autre requête avec un rôle différent, pour vérifier que les utilisateurs sans le rôle ANALYST voient un masque complet.

-- using the ANALYST role

USE ROLE analyst;
SELECT email FROM user_info; -- should see plain text value

-- using the PUBLIC role

USE ROLE PUBLIC;
SELECT email FROM user_info; -- should see full data mask

Politique de masquage avec une fonction mémoïsable¶

Cet exemple utilise une fonction mémoïsable pour mettre en cache le résultat d’une requête sur la table de mappage qui détermine si un rôle est autorisé à voir les données PII. Un ingénieur des données utilise une politique de masquage pour protéger les colonnes d’une table.

La procédure suivante fait référence à ces objets :

Une table qui contient des données PII, employee_data :

+----------+-------------+---------------+
| USERNAME |     ID      | PHONE_NUMBER  |
+----------+-------------+---------------+
| JSMITH   | 12-3456-89  | 1555-523-8790 |
| AJONES   | 12-0124-32  | 1555-125-1548 |
+----------+-------------+---------------+

Une table de mappage qui détermine si un rôle particulier est autorisé à voir des données, auth_role_t :

+---------------+---------------+
| ROLE          | IS_AUTHORIZED |
+---------------+---------------+
| DATA_ENGINEER | TRUE          |
| DATA_STEWARD  | TRUE          |
| IT_ADMIN      | TRUE          |
| PUBLIC        | FALSE         |
+---------------+---------------+

Effectuez les étapes suivantes pour créer une politique de masquage qui appelle une fonction mémoïsable avec des arguments :

Créez une fonction mémoïsable qui interroge la table de mappage. La fonction renvoie un tableau de rôles basé sur la valeur de la colonne is_authorized :

CREATE FUNCTION is_role_authorized(arg1 VARCHAR)
RETURNS BOOLEAN
MEMOIZABLE
AS
$$
  SELECT ARRAY_CONTAINS(
    arg1::VARIANT,
    (SELECT ARRAY_AGG(role) FROM auth_role WHERE is_authorized = TRUE)
  )
$$;

Appelez la fonction mémoïsable pour mettre en cache les résultats de la requête. Dans cet exemple, transmettez la valeur TRUE comme valeur d’argument, car le tableau résultant sert de source aux rôles autorisés à accéder aux données protégées par la politique de masquage :
```
SELECT is_role_authorized(IT_ADMIN);
```
```
+---------------------------------------------+
|         is_role_authorized(IT_ADMIN)        |
+---------------------------------------------+
|                    TRUE                     |
+---------------------------------------------+
```
Créez une politique de masquage pour protéger la colonne id. La politique appelle la fonction mémoïsable pour déterminer si le rôle utilisé pour la requête dans la table est autorisé à voir les données dans la colonne protégée :
```
CREATE OR REPLACE MASKING POLICY empl_id_mem_mask
AS (val VARCHAR) RETURNS VARCHAR ->
CASE
  WHEN is_role_authorized(CURRENT_ROLE()) THEN val
  ELSE NULL
END;
```
Définissez la politique de masquage sur la table avec une commande ALTER TABLE … ALTER COLUMN :
```
ALTER TABLE employee_data MODIFY COLUMN id
  SET MASKING POLICY empl_id_mem_mask;
```
Exécuter une requête sur la table pour tester la politique :
```
USE ROLE data_engineer;
SELECT * FROM employee_data;
```
Cette requête renvoie des données non masquées.

Toutefois, si vous passez au rôle PUBLIC et que vous répétez la requête à cette étape, les valeurs de id sont remplacées par NULL.

Exemples de politiques de masquage supplémentaires¶

Voici des exemples représentatifs supplémentaires qui peuvent être utilisés dans le corps de la politique de masquage dynamique des données.

Permettre à un compte de production de voir les valeurs non masquées et à tous les autres comptes (par exemple, développement, test) de voir les valeurs masquées.

case
  when current_account() in ('<prod_account_identifier>') then val
  else '*********'
end;

Renvoi de NULL pour les utilisateurs non autorisés :

case
  when current_role() IN ('ANALYST') then val
  else NULL
end;

Renvoi d’une valeur masquée statique pour les utilisateurs non autorisés :

CASE
  WHEN current_role() IN ('ANALYST') THEN val
  ELSE '********'
END;

Renvoi d’une valeur de hachage en utilisant SHA2 , SHA2_HEX pour les utilisateurs non autorisés : L’utilisation d’une fonction de hachage dans une politique de masquage peut entraîner des collisions ; il faut donc être prudent avec cette approche. Pour plus d’informations, voir Rubriques de sécurité avancées au niveau des colonnes.

CASE
  WHEN current_role() IN ('ANALYST') THEN val
  ELSE sha2(val) -- return hash of the column value
END;

Appliquer un masque partiel ou un masque complet :

CASE
  WHEN current_role() IN ('ANALYST') THEN val
  WHEN current_role() IN ('SUPPORT') THEN regexp_replace(val,'.+\@','*****@') -- leave email domain unmasked
  ELSE '********'
END;

Utilisation des horodatages.

case
  WHEN current_role() in ('SUPPORT') THEN val
  else date_from_parts(0001, 01, 01)::timestamp_ntz -- returns 0001-01-01 00:00:00.000
end;
Important

Actuellement, Snowflake ne prend pas en charge différents types de données d’entrée et de sortie dans une politique de masquage, comme la définition de la politique de masquage pour cibler un horodatage et renvoyer une chaîne (par exemple ***MASKED***) ; les types de données d’entrée et de sortie doivent correspondre.

Une solution consiste à remplacer la valeur réelle de l’horodatage par une valeur d’horodatage fabriquée. Pour plus d’informations, voir DATE_FROM_PARTS et CAST , ::.

En utilisant une UDF :

CASE
  WHEN current_role() IN ('ANALYST') THEN val
  ELSE mask_udf(val) -- custom masking function
END;

Sur les données des variantes :

CASE
   WHEN current_role() IN ('ANALYST') THEN val
   ELSE OBJECT_INSERT(val, 'USER_IPADDRESS', '****', true)
END;

En utilisant une table de droits personnalisée. Notez l’utilisation de EXISTS dans la clause WHEN. Utilisez toujours EXISTS lors de l’inclusion d’une sous-requête dans le corps de la politique de masquage. Pour plus d’informations sur les sous-requêtes que Snowflake prend en charge, voir Utilisation des sous-requêtes.

CASE
  WHEN EXISTS
    (SELECT role FROM <db>.<schema>.entitlement WHERE mask_method='unmask' AND role = current_role()) THEN val
  ELSE '********'
END;

En utilisant DECRYPT sur des données précédemment chiffrées avec ENCRYPT ou ENCRYPT_RAW, avec une phrase secrète sur les données chiffrées :

case
  when current_role() in ('ANALYST') then DECRYPT(val, $passphrase)
  else val -- shows encrypted value
end;

En utilisant une <JavaScript UDF sur JSON (VARIANT) :

Dans cet exemple, une UDF JavaScript masque les données d’emplacement dans une chaîne JSON. Il est important de définir le type de données comme VARIANT dans l’UDF et la politique de masquage. Si le type de données dans la colonne de la table, l’UDF et la signature de la politique de masquage ne correspondent pas, Snowflake renvoie un message d’erreur, car il ne peut pas résoudre la requête SQL.

-- Flatten the JSON data

create or replace table <table_name> (v variant) as
select value::variant
from @<table_name>,
  table(flatten(input => parse_json($1):stationLocation));

-- JavaScript UDF to mask latitude, longitude, and location data

CREATE OR REPLACE FUNCTION full_location_masking(v variant)
  RETURNS variant
  LANGUAGE JAVASCRIPT
  AS
  $$
    if ("latitude" in V) {
      V["latitude"] = "**latitudeMask**";
    }
    if ("longitude" in V) {
      V["longitude"] = "**longitudeMask**";
    }
    if ("location" in V) {
      V["location"] = "**locationMask**";
    }

    return V;
  $$;

  -- Grant UDF usage to ACCOUNTADMIN

  grant ownership on function FULL_LOCATION_MASKING(variant) to role accountadmin;

  -- Create a masking policy using JavaScript UDF

  create or replace masking policy json_location_mask as (val variant) returns variant ->
    CASE
      WHEN current_role() IN ('ANALYST') THEN val
      else full_location_masking(val)
      -- else object_insert(val, 'latitude', '**locationMask**', true) -- limited to one value at a time
    END;

Utilisation du type de données GEOGRAPHY :

Dans cet exemple, une politique de masquage utilise la fonction TO_GEOGRAPHY pour convertir toutes les données GEOGRAPHY d’une colonne en un point fixe, la longitude et la latitude de Snowflake à San Mateo, en Californie, pour les utilisateurs dont CURRENT_ROLE n’est pas ANALYST.
create masking policy mask_geo_point as (val geography) returns geography ->
  case
    when current_role() IN ('ANALYST') then val
    else to_geography('POINT(-122.35 37.55)')
  end;
Définissez la politique de masquage sur une colonne avec le type de données GEOGRAPHY et définissez la valeur GEOGRAPHY_OUTPUT_FORMAT de la session sur GeoJSON :
alter table mydb.myschema.geography modify column b set masking policy mask_geo_point;
alter session set geography_output_format = 'GeoJSON';
use role public;
select * from mydb.myschema.geography;
Snowflake renvoie les résultats suivants :
---+--------------------+
 A |         B          |
---+--------------------+
 1 | {                  |
   |   "coordinates": [ |
   |     -122.35,       |
   |     37.55          |
   |   ],               |
   |   "type": "Point"  |
   | }                  |
 2 | {                  |
   |   "coordinates": [ |
   |     -122.35,       |
   |     37.55          |
   |   ],               |
   |   "type": "Point"  |
   | }                  |
---+--------------------+
Les valeurs des résultats de la requête dans la colonne B dépendent de la valeur du paramètre GEOGRAPHY_OUTPUT_FORMAT pour la session. Par exemple, si la valeur du paramètre est définie sur WKT, Snowflake renvoie les résultats suivants :
alter session set geography_output_format = 'WKT';
select * from mydb.myschema.geography;

---+----------------------+
 A |         B            |
---+----------------------+
 1 | POINT(-122.35 37.55) |
 2 | POINT(-122.35 37.55) |
---+----------------------+

Pour des exemples utilisant d’autres fonctions de contexte et la hiérarchie des rôles, voir Rubriques de sécurité avancées au niveau des colonnes.

Chapitres suivants :

Rubriques de sécurité avancées au niveau des colonnes