Catégories :: Table, vue et séquence DDL

CREATE MASKING POLICY¶

Crée une nouvelle politique de masquage de sécurité au niveau des colonnes. Une politique de masquage est un objet au niveau du schéma qui peut avoir plusieurs règles et une fonction par défaut où, en fonction du contexte d’exécution (par exemple, un rôle), une règle peut être appliquée.

Snowflake évalue la politique de masquage en tant qu’expression SQL. Par conséquent, les règles sont évaluées dans l’ordre où elles sont écrites si elles sont spécifiées en tant que clauses WHEN-THEN dans une expression CASE dans le corps de la politique de masquage.

Un corps de politique de masquage est une expression SQL qui spécifie les règles. Au moment de l’exécution, Snowflake réécrit la requête pour appliquer l’expression de politique de masquage à la colonne.

Après avoir créé une politique de masquage, appliquez la politique de masquage à une colonne d’une table ou d’une vue à l’aide de ALTER TABLE … ALTER COLUMN ou ALTER VIEW.

Voir aussi :: Choisir une approche centralisée, hybride ou décentralisée, Rubriques de sécurité avancées au niveau des colonnes

Syntaxe¶

CREATE [ OR REPLACE ] MASKING POLICY [ IF NOT EXISTS ] <name> AS
(VAL <data_type>) RETURNS <data_type> -> <expression_ON_VAL>
[ COMMENT = '<string_literal>' ];

Paramètres¶

nom

Identificateur de la politique de masquage ; doit être unique pour votre schéma.

La valeur de 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. "My object"). Les identificateurs entre guillemets doubles sont également sensibles à la casse.

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

AS ( VAL type_données )

Définit le type de données à masquer. Pour plus de détails, voir Types de données.

RETURNS type_données

Définit le type de données à renvoyer. Pour plus de détails, voir Types de données.

expression_ON_VAL

Expression SQL qui transforme les données.

L’expression peut inclure Fonctions d’expressions conditionnelles pour représenter la logique conditionnelle, les fonctions intégrées ou les UDFs pour transformer les données.

Si une fonction UDF ou externe est utilisée dans le corps de la politique de masquage, le propriétaire de la politique doit avoir USAGE sur l’UDF ou la fonction externe. Les utilisateurs interrogeant une colonne à laquelle une politique de masquage est appliquée n’ont pas besoin d’avoir USAGE sur l’UDF ou sur la fonction externe.

COMMENT = 'litéral_chaine'

Ajoute un commentaire ou remplace un commentaire existant pour la politique de masquage.

Notes sur l’utilisation¶

Si vous souhaitez remplacer 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.
Pour les politiques de masquage qui incluent une sous-requête dans le corps de la politique de masquage, utilisez EXISTS dans la clause WHEN. Pour un exemple représentatif, consultez l’exemple de table de droits personnalisée dans la section Exemples.

Exemples¶

Vous pouvez utiliser Fonctions d’expressions conditionnelles, Fonctions contextuelles et des UDFs pour écrire l’expression SQL.

Voici des exemples représentatifs montrant comment créer des politiques de masquage à l’aide d’un masque complet, d’un hachage, d’une expression régulière et d’une UDF.

Masque complet :

Le rôle ANALYST peut voir la valeur en texte brut. 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;

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 JavaScript UDFs sur JSON (variante) :

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.

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

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.