Utilisation de la tokenisation externe

Cette rubrique fournit des instructions sur la configuration et l’utilisation de la tokenisation externe dans Snowflake.

Snowflake prend en charge la tokenisation externe avec AWS et Azure.

Important

La tokenisation externe nécessite des Fonctions externes, qui sont incluses dans Snowflake Standard Edition, et vous pouvez utiliser des fonctions externes avec un fournisseur de tokenisation (c’est-à-dire Protegrity).

Cependant, si vous choisissez d’intégrer votre fournisseur de tokenisation avec Snowflake Tokenisation externe, vous devez effectuer une mise à niveau vers Enterprise Edition ou une version ultérieure.

Pour en savoir plus sur la mise à niveau, veuillez contacter l’assistance de Snowflake.

Utilisation de la tokenisation externe sur AWS

Pour configurer et utiliser la tokenisation externe sur AWS avec Snowflake et Protegrity, inscrivez-vous à l” expérience d’essai Protegrity + Snowflake.

Après l’enregistrement, suivez toutes les instructions sur le site Web de Protegrity pour configurer et utiliser la tokenisation externe.

Tokenisation externe sur Azure

Voici une procédure représentative pour configurer et utiliser la tokenisation externe sur Azure.

Étape 1 : créez des fonctions externes sur Azure

Les fonctions externes nécessitent que votre environnement Azure soit configuré pour communiquer avec Snowflake.

Configurez votre environnement Azure et les fonctions externes Snowflake en utilisant ces étapes.

Note

Consultez la documentation de votre fournisseur de tokenisation pour vous assurer que toutes les étapes supplémentaires et nécessaires sont effectuées, en particulier lors de la configuration du service Gestion des API.

Étape 2 : accordez des privilèges de politiques de masquage à un 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

Description

CREATE MASKING POLICY

Ce privilège au niveau du schéma contrôle qui peut créer des politiques de masquage.

APPLY MASKING POLICY

Ce privilège au niveau du compte contrôle qui peut définir/annuler des politiques de masquage sur les colonnes et reçoit par défaut le rôle ACCOUNTADMIN. . Ce privilège permet uniquement d’appliquer une politique de masquage à une colonne et ne fournit aucun privilège de table supplémentaire décrit dans Privilèges de contrôle d’accès.

APPLY ON 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.

-- create a masking policy administrator custom role

CREATE ROLE masking_admin;

-- grant privileges to masking_admin role.

GRANT CREATE MASKING POLICY on SCHEMA <schema_name> to ROLE masking_admin;

GRANT APPLY MASKING POLICY on ACCOUNT to ROLE masking_admin;

-- allow table_owner role to set or unset the ssn_mask masking policy (optional)

GRANT APPLY ON MASKING POLICY ssn_mask to ROLE table_owner;

Où :

  • nom_schéma

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

Pour plus d’informations, voir :

Étape 3 : créez une politique de masquage

Dans cet exemple représentatif, les utilisateurs avec le rôle personnalisé ANALYST voient les valeurs des e-mails non tokenisées. Les utilisateurs sans le rôle personnalisé ANALYST voient les valeurs tokenisées.

La fonction externe permettant de détokeniser les valeurs des e-mails est de_email().

-- create masking policy

create or replace masking policy email_de_token as (val string) returns string ->
  case
    when current_role() in ('ANALYST') then de_email(val)
    else val
  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

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

-- apply the masking policy to a view column

alter view user_info_v modify column email set masking policy email_de_token;

Étape 5 : interrogez les données dans Snowflake

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

-- using the ANALYST custom role

use role ANALYST;
select email from user_info; -- should see plain text value

-- using the PUBLIC system role

use role public;
select email from user_info; -- should see tokenized value

Tokenisation externe sur Google Cloud Platform

Voici une procédure représentative pour configurer et utiliser la tokenisation externe sur Google Cloud Platform (GCP).

Étape 1 : créez des fonctions externes sur GCP

Les fonctions externes nécessitent que votre environnement GCP soit configuré pour communiquer avec Snowflake.

Configurez votre environnement GCP et les fonctions externes Snowflake en utilisant ces étapes.

Note

Consultez la documentation de votre fournisseur de tokenisation pour vous assurer que toutes les étapes supplémentaires et nécessaires sont effectuées, en particulier lors de la configuration du service API Gateway.

Étape 2 : accordez des privilèges de politiques de masquage à un 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

Description

CREATE MASKING POLICY

Ce privilège au niveau du schéma contrôle qui peut créer des politiques de masquage.

APPLY MASKING POLICY

Ce privilège au niveau du compte contrôle qui peut définir/annuler des politiques de masquage sur les colonnes et reçoit par défaut le rôle ACCOUNTADMIN. . Ce privilège permet uniquement d’appliquer une politique de masquage à une colonne et ne fournit aucun privilège de table supplémentaire décrit dans Privilèges de contrôle d’accès.

APPLY ON 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.

-- create a masking policy administrator custom role

CREATE ROLE masking_admin;

-- grant privileges to masking_admin role.

GRANT CREATE MASKING POLICY on SCHEMA <schema_name> to ROLE masking_admin;

GRANT APPLY MASKING POLICY on ACCOUNT to ROLE masking_admin;

-- allow table_owner role to set or unset the ssn_mask masking policy (optional)

GRANT APPLY ON MASKING POLICY ssn_mask to ROLE table_owner;

Où :

  • nom_schéma

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

Pour plus d’informations, voir :

Étape 3 : créez une politique de masquage

Dans cet exemple représentatif, les utilisateurs avec le rôle personnalisé ANALYST voient les valeurs des e-mails non tokenisées. Les utilisateurs sans le rôle personnalisé ANALYST voient les valeurs tokenisées.

La fonction externe permettant de détokeniser les valeurs des e-mails est de_email().

-- create masking policy

create or replace masking policy email_de_token as (val string) returns string ->
  case
    when current_role() in ('ANALYST') then de_email(val)
    else val
  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

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

-- apply the masking policy to a view column

alter view user_info_v modify column email set masking policy email_de_token;

Étape 5 : interrogez les données dans Snowflake

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

-- using the ANALYST custom role

use role ANALYST;
select email from user_info; -- should see plain text value

-- using the PUBLIC system role

use role public;
select email from user_info; -- should see tokenized value

Meilleures pratiques en matière de tokenisation externe

Chapitre suivant :