Comprendre la tokenisation externe¶

Cette rubrique fournit une présentation générale de la fonctionnalité de tokenisation externe.

Notez qu’une politique de masquage de tokenisation externe peut être assignée à une balise pour fournir une tokenisation externe basée sur la balise. Pour plus de détails sur l’affectation d’une politique de masquage à une balise, voir Politiques de masquage basées sur les balises.

Important

La tokenisation externe nécessite des Écriture de 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 la tokenisation externe Snowflake, 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 Snowflake.

Qu’est-ce que la tokenisation externe ?
Avantages de la tokenisation externe
Limitations de la tokenisation externe
Considérations sur la tokenisation externe
Privilèges et dépendances de la tokenisation externe
Tokenisation externe - DDL
Audit de la tokenisation externe
Dépannage de la tokenisation externe
- Messages d’erreur

Qu’est-ce que la tokenisation externe ?¶

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.

Dans Snowflake, les politiques de masquage sont des objets de niveau schéma, ce qui signifie qu’une base de données et un schéma doivent exister dans Snowflake avant qu’une politique de masquage puisse être appliquée à une colonne. Actuellement, Snowflake prend en charge l’utilisation du masquage dynamique des données sur les tableaux et les vues.

Au moment de l’exécution de la requête, la politique de masquage est appliquée à la colonne à chaque emplacement où la colonne apparaît. Selon les conditions de la politique de masquage, le contexte d’exécution SQL et la hiérarchie des rôles, les opérateurs de requête Snowflake peuvent voir la valeur en texte brut, une valeur partiellement masquée ou une valeur entièrement masquée.

Pour plus de détails sur le fonctionnement des politiques de masquage, y compris le comportement d’exécution des requêtes, la création d’une politique, l’utilisation avec des tables et des vues et les approches de gestion utilisant des politiques de masquage, voir : Comprendre la sécurité au niveau des colonnes.

Pour plus de détails sur les effets du contexte d’exécution SQL et de la hiérarchie des rôles, voir Rubriques de sécurité avancées au niveau des colonnes.

La tokenisation des données avant le chargement dans Snowflake garantit que les données sensibles ne sont jamais exposées inutilement. L’utilisation de politiques de masquage avec des fonctions externes garantit que seules les audiences appropriées peuvent afficher les données dé-tokenisées lors de l’exécution de la requête.

Avantages de la tokenisation externe¶

Ce qui suit résume certains des principaux avantages de la tokenisation externe.

Précharger les données tokenisées

À l’aide d’un fournisseur de tokenisation, les données tokenisées sont préchargées dans Snowflake. Par conséquent, même sans appliquer de politique de masquage à une colonne d’une table ou d’une vue, les utilisateurs ne voient jamais la valeur réelle des données. Cela offre une sécurité des données améliorée aux données les plus sensibles de votre organisation.

Facilité d’utilisation

Vous pouvez écrire une politique une fois et la faire appliquer à 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 le rôle ACCOUNTADMIN ou SECURITYADMIN de visualiser inutilement les données.

Gestion du changement

Modifiez facilement le contenu de la politique de masquage sans avoir à réappliquer la politique de masquage à des milliers de colonnes.

Pour une comparaison des avantages entre le masquage dynamique des données et la tokenisation externe, voir : Avantages de la sécurité au niveau de la colonne.

Limitations de la tokenisation externe¶

Pour une vue d’ensemble des limitations, consultez Limitations de sécurité au niveau de la colonne.

Considérations sur la tokenisation externe¶

Pour des considérations supplémentaires sur la tokenisation externe, voir Considérations de sécurité au niveau de la colonne.

Privilèges et dépendances de la tokenisation externe¶

Le tableau suivant résume les privilèges liés aux politiques de masquage de la tokenisation externe.

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.

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.

Étant donné que la politique de masquage de tokenisation externe nécessite une fonction externe qui dépend d’une intégration API, le tableau suivant résume les privilèges que le rôle personnalisé (par exemple, MASKING_ADMIN) doit avoir sur les objets Snowflake. Notez que ces privilèges s’appliquent uniquement au rôle personnalisé et ne sont pas nécessaires pour le rôle de l’utilisateur interrogeant la colonne avec une politique de masquage.

Rôle personnalisé	Privilège	Objet
Propriétaire de la politique de tokenisation externe	USAGE	Fonction externe
Propriétaire de la fonction externe (c’est-à-dire le rôle avec le privilège OWNERSHIP sur la fonction externe)	USAGE	Tous les objets d’intégration API référencés par la fonction externe.

Tokenisation externe - DDL¶

Snowflake fournit l’ensemble de commandes suivant pour gérer les politiques de tokenisation externe.

CREATE MASKING POLICY
ALTER MASKING POLICY (voir aussi : ALTER TABLE, ALTER TABLE … ALTER COLUMN, et ALTER VIEW)
DROP MASKING POLICY
SHOW MASKING POLICIES
DESCRIBE MASKING POLICY

Audit de la tokenisation externe¶

Snowflake fournit deux vues Account Usage pour obtenir des informations sur les politiques de masquage :

La vue MASKING POLICIES fournit une liste de toutes les politiques de masquage dans votre compte Snowflake.
La vue POLICY_REFERENCES fournit une liste de tous les objets dans lesquels une politique de masquage est définie.

La fonction de table Information Schema POLICY_REFERENCES peut être utilisée soit pour :

Renvoyer une liste de tous les objets (c.-à-d. tables, vues) dont la politique de masquage est définie sur une colonne.
Renvoyer une liste d’associations de politiques ayant le nom d’objet et le type d’objet spécifiés.

Snowflake enregistre l’exécution de la requête d’origine par l’utilisateur sur la page Historique (dans l’interface Web). La requête se trouve dans la colonne SQL Text.

Les noms de politique de masquage utilisés dans une requête spécifique se trouvent dans le profil de requête.

L’historique des requêtes est spécifique à la vue Account Usage QUERY_HISTORY uniquement. Dans cette vue, la colonne Query Text contient le texte de l’instruction SQL . Les noms de politique de masquage ne sont pas inclus dans la vue QUERY_HISTORY.

Dépannage de la tokenisation externe¶

Vous pouvez utiliser des messages d’erreur pour résoudre les problèmes de politiques de masquage.

Messages d’erreur¶

Le tableau suivant décrit les messages d’erreur que Snowflake peut renvoyer lors de l’utilisation de politiques de masquage.

Comportement	Message d’erreur	Action de dépannage
Impossible d’appliquer une politique de masquage à une fonctionnalité Snowflake.	Fonctionnalité non prise en charge `CREATE ON MASKING POLICY COLUMN`.	Les politiques de masquage ne sont actuellement pas applicables à cette fonctionnalité.
Un rôle actif ne peut pas créer ou remplacer une politique de masquage.	Erreur de contrôle d’accès SQL : privilèges insuffisants pour opérer sur le compte <nom_compte>	Accordez le privilège CREATE MASKING POLICY au rôle spécifié à l’aide de `grant create masking policy on account to role <role_name>;` . Vérifiez que le rôle dispose du privilège à l’aide de `show grants to role <role_name>` et réessayez l’instruction de masquage CREATE OR REPLACE.
Un rôle donné ne peut pas joindre une politique de masquage à une table.	Erreur de compilation SQL : la base de données <nom_base_de_données> n’existe pas ou n’est pas autorisée.	Accordez le privilège APPLY MASKING POLICY au rôle à l’aide de `grant apply masking policy on account to role <role_name>;`
Un rôle donné qui ne possède pas de politique de masquage sur une table essaie d’appliquer une politique de masquage sur une table qu’il peut utiliser.	Erreur de compilation SQL : la politique de masquage <nom_politique> n’existe pas ou n’est pas autorisée.	Accordez l’utilisation du rôle donné sur la politique de masquage à l’aide de `grant apply on masking policy <policy_name> to role <role_name>;`
Impossible de détruire ou de supprimer une politique à l’aide de `drop masking policy <policy_name>;`	Erreur de compilation SQL : la politique <nom_politique> ne peut pas être détruite/remplacée car elle est associée à une ou plusieurs entités.	Utilisez d’abord une instruction ALTER TABLE … MODIFY COLUMN ou ALTER VIEW … MODIFY COLUMN pour UNSET la politique, puis réessayez l’instruction DROP.
La restauration d’une table détruite produit une erreur de politique de masquage.	Erreur d’exécution SQL : la colonne <nom_colonne> est déjà attachée à une politique de masquage qui n’existe pas. Veuillez contacter l’administrateur de la politique.	Désactivez la politique de masquage actuellement attachée avec une instruction ALTER Table/View MODIFY COLUMN, puis appliquez à nouveau la politique de masquage à la colonne avec une instruction CREATE OR REPLACE.
Impossible d’appliquer une politique de masquage à une colonne spécifique, mais la politique de masquage peut être appliquée à une autre colonne.	La colonne spécifiée est déjà attachée à une autre stratégie de masquage. Une colonne ne peut pas être attachée à plusieurs stratégies de masquage. Veuillez détruire l’association actuelle afin d’attacher une nouvelle stratégie de masquage.	Décidez quelle politique de masquage doit s’appliquer à la colonne, mettez à jour et réessayez.
La mise à jour d’une politique avec une instruction ALTER échoue.	Erreur de compilation SQL : la politique de masquage <nom_politique> n’existe pas ou n’est pas autorisée.	Vérifiez que le nom de politique dans la commande ALTER correspond à une politique existante en exécutant `show masking policies;`
Le rôle qui possède la table clonée ne peut pas annuler une politique de masquage.	Erreur de contrôle d’accès SQL : privilèges insuffisants pour effectuer des opérations sur ALTER TABLE UNSET MASKING POLICY “<nom_politique>”	Accordez le privilège APPLY au rôle qui possède la table clonée en utilisant `grant apply on masking policy <policy_name> to role <role_name>;` .. Vérifiez que le rôle qui possède la table clonée a l’autorisation en utilisant `show grants to role <role_name>;` et essayez à nouveau l’instruction ALTER.
La mise à jour d’une politique à l’aide de IF EXISTS renvoie un résultat réussi mais ne met pas à jour la politique.	Aucun message d’erreur renvoyé ; Snowflake renvoie l’instruction exécutée avec succès.	Supprimez IF EXISTS de l’instruction ALTER et réessayez.
Lors de la création ou du remplacement d’une politique de masquage par CASE, les types de données ne correspondent pas (par exemple (chaîne VAL) -> renvoie un nombre).	Erreur de compilation SQL : l’argument de fonction de politique de masquage et le type de renvoi ne correspondent pas.	Mettez à jour la politique de masquage à l’aide de CASE avec les types de données correspondants à l’aide d’une instruction CREATE OR REPLACE ou d’une instruction ALTER MASKING POLICY .
Appliquez une politique de masquage à une colonne virtuelle.	Erreur de compilation SQL : la politique de masquage ne peut pas être attachée à une colonne VIRTUAL_COLUMN .	Appliquez la politique de masquage aux colonnes de la table source.
Application d’une politique de masquage à une vue matérialisée.	Erreur de compilation SQL : ligne d’erreur de syntaxe <number> à la position <number> “modifier” inattendu. . Erreur de compilation SQL : ligne d’erreur <number> à la position <number> identificateur non valide “<character>” . Erreur de compilation SQL : une ou plusieurs vues matérialisées existent sur la table. Nombre de mvs=<number>, nom de table=<nom_table>.	Appliquez la politique de masquage aux colonnes de la table source. Pour plus d’informations, voir Limites.
Application d’une politique de masquage à une colonne de table utilisée pour créer une vue matérialisée	Erreur de compilation SQL : la politique de masquage ne peut pas être liée à une colonne MATERIALIZED_VIEW .	Pour appliquer la politique de masquage à la colonne de la table, détruisez la vue matérialisée.
Inclusion d’une colonne masquée lors de la création d’une vue matérialisée	Fonctionnalité non prise en charge « CREATE ON MASKING POLICY COLUMN ».	Créez la vue matérialisée sans inclure les colonnes masquées ou ne définissez aucune politique de masquage sur la table ou les vues de base, créez la vue matérialisée, puis appliquez les politiques de masquage aux colonnes de la vue matérialisée.
Impossible de créer une politique de masquage avec une fonction définie par l’utilisateur (UDF) dans le corps de la politique de masquage.	Erreur de contrôle d’accès SQL : privilèges insuffisants pour effectuer des opérations sur la fonction “<nom_udf>”	Vérifiez que le rôle qui crée la politique de masquage a le privilège USAGE sur l’UDF.

Chapitres suivants :

Utilisation de la tokenisation externe
Utilisation de la tokenisation conditionnelle (Pour un exemple de politique de tokenisation externe avec des colonnes conditionnelles, voir CREATE MASKING POLICY).