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.

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 le support de Snowflake.

Tokenisation externe sur AWS

Snowflake prend en charge deux intégrations de partenaires pour utiliser la tokénisation externe sur AWS :

Protegrity

Pour configurer et utiliser la tokenisation externe avec Protegrity, inscrivez-vous à l” expérience d’essai Protegrity + Snowflake. Après l’enregistrement, suivez toutes les instructions sur le site Web de Protegrity.

Baffle

Pour configurer et utiliser la tokénisation externe avec Baffle, suivez les étapes de la documentation Baffle.

Tokenisation externe sur Azure

Snowflake prend en charge la tokenisation externe sur Azure en utilisant une intégration partenaire avec Baffle ou une intégration personnalisée.

Baffle

Pour utiliser l’intégration Baffle, suivez les instructions du guide Baffle.

Intégration personnalisée

Utilisez la procédure représentative indiquée ci-dessous pour configurer une intégration personnalisée de tokénisation 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 : Appliquer 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_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

Snowflake prend en charge la tokenisation externe sur Google Cloud Platform (GCP) à l’aide d’intégrations personnalisées.

Voici une procédure représentative pour configurer et utiliser la tokenisation externe sur 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 : Appliquer 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_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

  • Synchronisation de systèmes. Sur AWS, il est utile de synchroniser les utilisateurs et les rôles dans le fournisseur d’identité de votre organisation (IdP) avec Snowflake et Protegrity. Si les utilisateurs et les rôles ne sont pas synchronisés, il peut y avoir des comportements inattendus, des messages d’erreur et un dépannage complexe concernant les fonctions externes, les intégrations API, les politiques de masquage et les politiques de tokenisation. Une option consiste à utiliser SCIM pour garder les utilisateurs et les rôles synchronisés avec votre IdP et Snowflake.

  • Cause racine des erreurs. Étant donné que la tokenisation externe nécessite la coordination de plusieurs systèmes (par exemple IdP, Snowflake, Protegrity, AWS, Azure, GCP), vérifiez toujours les privilèges, les limitations actuelles, les fonctions externes, l’intégration API, les politiques de masquage et les colonnes qui ont des politiques de masquage pour la tokenisation externes dans Snowflake. Pour aider à déterminer la cause première, voir :

Chapitre suivant :