Comprendre la sécurité au niveau des colonnes

Cette rubrique fournit une présentation générale de la sécurité au niveau des colonnes et décrit les fonctionnalités et la prise en charge communes au masquage dynamique des données et à la tokenisation externe.

Qu’est-ce que la sécurité au niveau des colonnes ?

La sécurité au niveau des colonnes dans Snowflake permet l’application d’une politique de masquage à une colonne dans une table ou une vue. Actuellement, la sécurité au niveau des colonnes comprend deux fonctionnalités :

  1. Masquage dynamique des données

  2. Tokenisation externe

Le masquage dynamique des données est une fonctionnalité de sécurité au niveau des colonnes qui utilise des politiques de masquage pour masquer sélectivement les données en texte brut dans les tables et voir les colonnes au moment de la requête.

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.

Politiques de masquage : de quoi s’agit-il ?

Snowflake prend en charge les politiques de masquage en tant qu’objet de niveau schéma pour protéger les données sensibles contre les accès non autorisés tout en permettant aux utilisateurs autorisés d’accéder aux données sensibles lors de l’exécution de la requête. Cela signifie que les données sensibles dans Snowflake ne sont pas modifiées dans une table existante (c’est-à-dire pas de masquage statique). Au contraire, lorsque les utilisateurs exécutent une requête dans laquelle une politique de masquage s’applique, les conditions de politique de masquage déterminent si les utilisateurs non autorisés voient les données masquées, partiellement masquées, floutées ou tokenisées. Le masquage des politiques en tant qu’objet au niveau du schéma offre également une flexibilité dans le choix d’une approche de gestion centralisée, décentralisée ou hybride. Pour plus d’informations, consultez Gestion de la sécurité au niveau des colonnes (dans cette rubrique).

Les politiques de masquage peuvent inclure des conditions et des fonctions pour transformer les données lors de l’exécution de la requête lorsque ces conditions sont remplies. L’approche basée sur les politiques prend en charge la séparation des tâches pour permettre aux équipes de sécurité de définir des politiques qui peuvent limiter l’exposition des données sensibles, y compris par rapport aux propriétaires d’un objet (c’est-à-dire le rôle avec le privilège OWNERSHIP sur l’objet, comme une table ou une vue) et qui ont normalement un accès complet aux données sous-jacentes.

The masking policy admin can apply masking policies to tables and views.

Par exemple, les administrateurs de politiques de masquage peuvent implémenter une politique de masquage de sorte que les analystes (c’est-à-dire les utilisateurs avec le rôle ANALYST personnalisé) ne puissent afficher que les quatre derniers chiffres d’un numéro de téléphone et aucun du numéro de sécurité sociale, tandis que les représentants du support client (par exemple, les utilisateurs avec le rôle SUPPORT personnalisé) peuvent afficher l’intégralité du numéro de téléphone et du numéro de sécurité sociale pour les cas d’utilisation de vérification client.

Masking policy results for authorized and unauthorized roles.

Une politique de masquage consiste en un seul type de données, une ou plusieurs conditions et une ou plusieurs fonctions de masquage.

  • Vous pouvez appliquer la politique de masquage à une ou plusieurs colonnes de table/vue avec le type de données correspondant. Par exemple, vous pouvez définir une politique pour une adresse e-mail une fois et l’appliquer aux milliers de colonnes de messagerie dans les bases de données et les schémas.

  • Les conditions de politique de masquage peuvent être exprimées à l’aide de Fonctions d’expressions conditionnelles et Fonctions contextuelles ou en interrogeant une table de droits personnalisée. Vous pouvez utiliser les fonctions de contexte INVOKER_ROLE et INVOKER_SHARE pour une utilisation avec les vues et les partages, respectivement.

  • Les fonctions de masquage peuvent être n’importe lesquelles des fonctions intégrées (par exemple REGEXP_REPLACE, SHA2 , SHA2_HEX), Fonctions définies par l’utilisateur (UDFs) ou Fonctions externes (pour la dé-tokenisation à l’aide d’un fournisseur de tokenisation externe).

Alors que Snowflake propose des vues sécurisées pour restreindre l’accès aux données sensibles, les vues sécurisées présentent des défis de gestion en raison du grand nombre de vues et de tableaux de bord décisionnels en découlant (BI) de chaque vue. Les politiques de masquage résolvent ce défi de gestion en évitant une explosion de vues et de tableaux de bord à gérer.

Les politiques de masquage prennent en charge la séparation des tâches (SoD) grâce à la séparation des rôles entre les administrateurs de politiques et les propriétaires d’objets. Les vues sécurisées n’ont pas de SoD, ce qui constitue une limitation profonde de leur utilité. Cette séparation des rôles conduit aux paramètres par défaut suivants :

  • Les propriétaires d’objets (c’est-à-dire le rôle qui a le privilège OWNERSHIP sur l’objet) n’ont pas le privilège de désactiver les politiques de masquage.

  • Les propriétaires d’objets ne peuvent pas afficher les données de colonnes dans lesquelles une politique de masquage s’applique.

Pour plus d’informations sur la gestion des rôles et des privilèges, voir Gestion de la sécurité au niveau des colonnes (dans cette rubrique) et Privilèges de contrôle d’accès.

Comment fonctionne une politique de masquage ?

Les politiques de masquage pour le masquage dynamique des données et la tokenisation externe adoptent la même structure et le même format à une exception notable : les politiques de masquage pour la tokenisation externe nécessitent l’utilisation de Fonctions externes dans le corps de la politique de masquage.

La raison de cette exception est que la tokenisation externe nécessite qu’un fournisseur de tokenisation tiers tokenize les données avant de charger les données dans Snowflake. Au moment de l’exécution de la requête, Snowflake utilise la fonction externe pour effectuer un appel API REST au fournisseur de tokenisation, qui évalue ensuite une politique de tokenisation (créée en dehors de Snowflake) pour renvoyer des données tokenisées ou détokenisées en fonction des conditions de politiques de masquage. Notez que le mappage des rôles doit exister dans Snowflake et le fournisseur de tokenisation pour garantir que les données correctes puissent être renvoyées à partir d’une requête donnée.

Snowflake prend en charge la création de politiques de masquage à l’aide de CREATE MASKING POLICY. Par exemple :

-- Dynamic Data Masking

create masking policy employee_ssn_mask as (val string) returns string ->
  case
    when current_role() in ('PAYROLL') then val
    else '******'
  end;

-- External Tokenization

  create masking policy employee_ssn_detokenize as (val string) returns string ->
  case
    when current_role() in ('PAYROLL') then ssn_unprotect(val)
    else val -- sees tokenized data
  end;

Où :

employee_ssn_mask

Nom de la politique de masquage dynamique des données.

employee_ssn_detokenize

Nom de la politique de tokenisation externe.

as (val string) returns string

Spécifie les types de données d’entrée et de sortie. Les types de données doivent correspondre.

->

Sépare la signature de la politique de son corps.

case ... end;

Spécifie les conditions du corps de la politique de masquage (c’est-à-dire l’expression SQL).

Dans ces deux exemples, si l’opérateur de requête utilise le rôle personnalisé PAYROLL dans la session en cours, l’opérateur voit la valeur non masquée/détokenisée. Sinon, une valeur masquée/tokenisée fixe est visible.

ssn_unprotect

La fonction externe pour opérer sur les données tokenisées.

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 .

La définition de la politique de masquage peut alors être mise à jour avec la commande ALTER MASKING POLICY. Cette commande ne nécessite pas la suppression d’une politique de masquage d’une colonne, si la politique de masquage est définie sur une colonne. Ainsi, une colonne qui est protégée par une politique le reste pendant la mise à jour de la définition de la politique.

Pour plus de détails sur l’utilisation des politiques de masquage, voir :

Politiques de masquage lors de l’exécution de la requête

Snowflake prend en charge les politiques de masquage imbriquées, telles qu’une politique de masquage sur une table et une politique de masquage sur une vue pour la même table. Au moment de l’exécution de la requête, Snowflake évalue toutes les politiques de masquage pertinentes pour une requête donnée dans l’ordre suivant :

  • La politique de masquage applicable à la table est toujours exécutée en premier.

  • La politique de la vue est exécutée après avoir évalué la politique de la table.

  • S’il existe des vues imbriquées (par exemple Table 1 -> Vue 1 -> Vue 2 -> … Vue n), les politiques sont appliquées dans un ordre séquentiel de gauche à droite.

Ce modèle se poursuit selon le nombre de politiques qui existent en ce qui concerne les données de la requête. Le diagramme suivant illustre la relation entre un exécutant de requête, des tables, des vues et des politiques.

Masking policies with tables and views.

Au moment de l’exécution, Snowflake réécrit la requête pour appliquer l’expression de la politique de masquage aux colonnes spécifiées dans la politique de masquage. La politique de masquage est appliquée à la colonne, quel que soit l’endroit dans une expression SQL où la colonne est référencée, notamment :

  • Projections.

  • Prédicats JOIN.

  • Prédicats de la clause WHERE.

  • Clauses ORDER BY et GROUP BY.

Important

Une politique de masquage est délibérément appliquée partout où la colonne pertinente est référencée par une construction SQL pour empêcher la désanonymisation des données via des requêtes créatives afin d’inclure les données de colonne masquées.

Par conséquent, si l’exécution d’une requête entraîne des données masquées dans une ou plusieurs colonnes, la sortie de la requête peut ne pas fournir la valeur attendue, car les données masquées empêchent d’évaluer toutes les données de sortie de la requête dans le contexte souhaité.

L’exemple suivant montre une requête soumise par l’utilisateur suivie de la réécriture de la requête d’exécution Snowflake dans laquelle la politique de masquage (c’est-à-dire <expression_SQL>) s’applique uniquement à la colonne email.

Requête simple :

SELECT email, city from customers where city = 'San Mateo';

SELECT <SQL_expression>(email), city from customers where city = 'San Mateo';

Les exemples suivants montrent une requête soumise par l’utilisateur suivie de la réécriture de la requête d’exécution Snowflake dans laquelle la politique de masquage (c’est-à-dire <expression_SQL>) s’applique à un seul côté d’une comparaison (par exemple, la colonne e-mail, mais pas la chaîne à laquelle la colonne e-mail est comparée). Les résultats de la requête ne sont pas ce que l’utilisateur voulait obtenir. Masquer un seul côté d’une comparaison est un anti-modèle courant.

Requête avec une colonne protégée dans le prédicat de clause WHERE (anti-modèle) :

SELECT email from customers where email = 'user@example.com';

SELECT <SQL_expression>(email) from customers where <SQL expression>(email) = 'user@example.com';

Requête avec une colonne protégée dans le prédicat JOIN (anti-modèle) :

select b.email, d.city from sf_tuts.public.emp_basic as b join sf_tuts.public.emp_details as d on b.email = d.email;

select <SQL_expression>(b.email), d.city from sf_tuts.public.emp_basic as b join sf_tuts.public.emp_details as d on <SQL expression>(b.email) = <SQL expression>(d.email);

Considérations relatives à l’exécution des requêtes

Snowflake recommande de prendre en compte les facteurs suivants lors de la tentative de prédiction de l’effet de l’application d’une politique de masquage à une colonne et si l’opérateur de la requête voit les données masquées :

La session en cours

Conditions de la politique de masquage avec CURRENT_ROLE.

Le rôle d’exécution

Conditions de la politique de masquage avec INVOKER_ROLE.

Hiérarchie des rôles

Conditions de la politique de masquage avec IS_ROLE_IN_SESSION ou IS_GRANTED_TO_INVOKER_ROLE.

Partage de données

Indique si les données sont partagées à l’aide de Snowflake Secure Data Sharing. Voir Limitations (dans cette rubrique).

Réplication

Voir Objets de base de données répliqués.

Sous-requêtes

Une politique de masquage peut faire référence à une sous-requête dans la définition de la politique, cependant, il y a des limites à la prise en charge de la sous-requête dans Snowflake. Pour plus d’informations, voir Utilisation des sous-requêtes.

Les trois premiers éléments sont expliqués plus en détail dans Rubriques de sécurité avancées au niveau des colonnes. Le partage de données ne s’applique qu’au masquage dynamique des données car les fonctions externes ne peuvent pas être appelées dans le contexte d’un partage.

En fin de compte, le cas d’utilisation spécifique détermine si le masquage dynamique des données ou la tokenisation externe est le mieux adapté.

Choix du masquage dynamique des données ou de la tokenisation externe

Pour choisir la fonctionnalité appropriée qui répond le mieux aux besoins de votre organisation, évaluez les principaux cas d’utilisation de vos données ainsi que les considérations et limitations pertinentes. Les deux sections suivantes résument les avantages et les limites entre les deux fonctionnalités.

Avantages

Le tableau suivant compare les avantages du masquage dynamique des données et de la tokenisation externe.

Facteur

Masquage dynamique des données

Tokenisation externe

Remarques

Préservez la valeur analytique après la désidentification.

Comme la tokenisation fournit une valeur unique pour un ensemble donné de caractères, il est possible de regrouper des enregistrements par une valeur tokenisée sans révéler les informations sensibles. Par exemple, regrouper des enregistrements médicaux par code de diagnostic avec le code de diagnostic du patient tokenisé. Les analystes de données peuvent ensuite interroger une vue sur le code de diagnostic pour obtenir un décompte du nombre de patients avec un code de diagnostic unique.

Préchargez les données tokenisées.

Les utilisateurs non autorisés ne voient jamais la valeur réelle des données. Nécessite un fournisseur de tokenisation tiers.

Préchargez les données non masquées.

Ne nécessite que la fonctionnalité intégrée de Snowflake, aucun tiers requis.

Data Sharing.

Les fonctions externes ne peuvent pas être utilisées avec Data Sharing, donc pas de tokenisation externe.

Facilité d’utilisation et gestion du changement.

Écrivez une politique une fois et appliquez-la à 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.

Réplication de base de données

Voir Objets de base de données répliqués.

Limites

Le tableau suivant décrit les limitations actuelles de la sécurité au niveau des colonnes. Une coche (c’est-à-dire ✔) indique une limitation ou un manque de prise en charge actuelle de la fonctionnalité.

Limitation

Masquage dynamique des données

Tokenisation externe

Remarques

type de données GEOGRAPHY .

Les politiques de masquage ne peuvent pas être utilisées avec ce type de données.

Objets partagés.

Pour le masquage dynamique des données, si la politique de masquage d’une colonne de table ou de vue fait référence à une fonction externe, la table ou la vue ne peut pas être partagée. . Pour la tokenisation externe, Secure Data Sharing n’est pas applicable car les fonctions externes ne peuvent pas être invoquées dans le contexte d’un partage. . Un fournisseur de partage de données ne peut pas créer une politique de masquage dans un compte de lecteur. . Un consommateur de partage de données ne peut pas appliquer une politique de masquage à une base de données ou à une table partagée. Comme solution de rechange, importez la base de données ou la table partagée et appliquez la politique de masquage à une vue locale sur cette colonne de table partagée.

Vues matérialisées (MV).

Pour un résumé complet, voir Vues matérialisées (dans ce chapitre).

DROP MASKING POLICY

Avant de détruire une politique, désactivez-la de la table ou de la colonne d’affichage à l’aide de ALTER TABLE … ALTER COLUMN ou ALTER VIEW.

DROP DATABASE et DROP SCHEMA

La destruction d’une base de données ou d’un schéma nécessite que la politique de masquage et ses mappages soient autonomes dans une base de données et un schéma. . Par exemple, database_1 contient policy_1 et policy_1 n’est utilisé que dans database_1.

Colonnes virtuelles.

Les politiques de masquage ne peuvent pas être appliquées aux colonnes virtuelles. Appliquez la politique à la colonne de la table source ou à la colonne de vue.

Tables externes

Une table externe ne peut pas être référencée comme une table de consultation (c’est-à-dire dans une sous-requête) pour déterminer si les valeurs des colonnes doivent être masquées. Pour plus d’informations, voir Tables externes (dans ce chapitre).

Différents types de données dans l’entrée et la sortie d’une définition de politique.

Une définition de politique de masquage doit avoir le même type de données pour l’entrée et la sortie. En d’autres termes, à titre d’exemple représentatif, vous ne pouvez pas définir le type de données d’entrée comme un horodatage et renvoyer une chaîne.

Gestion du changement et politique de masquage.

Vous pouvez éventuellement stocker et suivre les modifications de politiques de masquage dans un système de contrôle de version de votre choix.

Autorisations futures.

Les octrois futurs de privilèges sur les politiques de masquage ne sont pas pris en charge. . Comme solution de contournement, accordez le privilège APPLY MASKING POLICY à un rôle personnalisé pour lui permettre d’appliquer des politiques de masquage aux colonnes de tables ou de vues.

Sous-requêtes.

Une sous-requête dans le corps de la politique qui joint une colonne d’une table ou d’une vue différente n’est pas prise en charge.

Considérations

  • Faites preuve de prudence lorsque vous insérez des valeurs d’une colonne source qui a une politique de masquage sur la colonne source vers une colonne cible sans politique de masquage sur la colonne cible. Étant donné qu’une politique de masquage est définie sur la colonne source, un rôle qui visualise les données d’une colonne non masquée peut insérer des données non masquées dans une autre colonne, dans laquelle tout rôle disposant de privilèges suffisants sur la table ou la vue peut en voir la valeur.

  • Si un rôle qui voit des données masquées dans la colonne source insère ces valeurs dans une colonne cible, les valeurs insérées restent masquées. Si une politique de masquage n’est pas définie sur la colonne cible, les utilisateurs disposant de privilèges suffisants sur la table ou la vue peuvent voir une combinaison de valeurs masquées et non masquées dans la colonne cible. Par conséquent, en tant que meilleure pratique :

    • Faites preuve de prudence lorsque vous appliquez des politiques de masquage aux colonnes.

    • Vérifiez les requêtes à l’aide de colonnes qui ont des politiques de masquage avant de mettre les tables et les vues à la disposition des utilisateurs.

    • Déterminez des tables et des vues supplémentaires (c’est-à-dire des colonnes cibles) dans lesquelles les données de la colonne source peuvent apparaître.

    • Pour plus d’informations, voir Obtenir des colonnes avec une politique de masquage (dans ce chapitre).

Utilisation de la sécurité au niveau des colonnes sur les tables et les vues

Snowflake prend en charge les politiques de masquage avec des tables et des vues. Ce qui suit décrit comment les politiques de masquage affectent les tables et les vues dans Snowflake.

Appliquer des politiques de masquage aux colonnes

Il existe deux options pour appliquer une politique de masquage à une colonne dans une table ou une vue :

  1. Avec une table ou une vue nouvelle, appliquez la politique à une colonne de table avec une instruction CREATE TABLE ou à une colonne de vue avec une instruction CREATE VIEW.

  2. Avec une table ou une vue existante, appliquez la politique à une colonne de table avec une instruction ALTER TABLE … ALTER COLUMN ou à une colonne de vue avec une instruction ALTER VIEW.

Pour une table ou une vue nouvelle, exécutez les instructions suivantes :

-- table
create or replace table user_info (ssn_number string masking policy ssn_mask);

--view
create or replace view user_info_v (ssn number masking policy ssn_mask_v) as select * from user_info;

Pour une table ou une vue existante, exécutez les instructions suivantes :

-- table
ALTER TABLE IF EXISTS user_info MODIFY COLUMN ssn_number SET MASKING POLICY ssn_mask;

-- view
ALTER VIEW user_info_v MODIFY COLUMN ssn_number SET MASKING POLICY ssn_mask_v;

Pour plus d’informations sur la syntaxe et l’utilisation, voir ALTER TABLE … ALTER COLUMN et ALTER VIEW.

Politiques d’accès aux lignes

Une colonne de table ou de vue donnée peut être spécifiée soit dans une signature de politique de masquage, soit dans une signature de politique d’accès aux lignes. En d’autres termes, la même colonne ne peut pas être spécifiée à la fois dans une signature de politique de masquage et dans une signature de politique d’accès aux lignes.

Pour plus d’informations, voir CREATE MASKING POLICY et CREATE ROW ACCESS POLICY.

Vues matérialisées

Snowflake permet de définir une politique de masquage sur une colonne de vue matérialisée. Au moment de l’exécution de la requête, le plan de requête exécute toute politique de masquage présente avant la création de la réécriture de la vue matérialisée. Une fois la réécriture de la vue matérialisée effectuée, les politiques de masquage ne peuvent plus être définies sur aucune colonne de la vue matérialisée.

Il existe deux options pour définir une politique de masquage sur une colonne de vue matérialisée :

  1. Pour une vue matérialisée nouvelle, exécutez une instruction CREATE MATERIALIZED VIEW.

  2. Pour une vue matérialisée existante, exécutez une instruction ALTER VIEW … MODIFY COLUMN sur la vue matérialisée.

Pour une vue matérialisée nouvelle, exécutez l’instruction suivante :

create or replace materialized view user_info_mv (ssn_number masking policy ssn_mask) as select ssn_number from user_info;

Pour une vue matérialisée existante, voir l’exemple de vue dans la section Appliquer des politiques de masquage aux colonnes (dans cette rubrique).

En outre, les deux limitations suivantes existent concernant les politiques de masquage et les vues matérialisées :

  1. Une politique de masquage ne peut pas être définie sur une table ou une vue si une vue matérialisée est déjà créée à partir de la table ou de la vue sous-jacente. Snowflake renvoie le message d’erreur suivant lorsque cette tentative est effectuée :

    SQL execution error: One or more materialized views exist on the table. number of mvs=<number>, table name=<table_name>.
    
  2. Si une politique de masquage est définie sur une colonne de table ou de vue sous-jacente et qu’une vue matérialisée est créée à partir de cette table ou vue, la vue matérialisée ne contient que les colonnes qui ne sont pas protégées par une politique de masquage. Snowflake renvoie également le message d’erreur suivant si la tentative d’inclure une ou plusieurs colonnes protégées par une politique de masquage :

    Unsupported feature 'CREATE ON MASKING POLICY COLUMN'.
    

Obtenir des colonnes avec une politique de masquage

Pour obtenir une liste de colonnes avec des politiques de masquage, exécutez l’instruction suivante. Pour plus d’informations, voir POLICY_REFERENCES.

SELECT * from table(information_schema.policy_references(policy_name=>'<policy_name>'));

Exécutez une instruction DESCRIBE TABLE ou DESCRIBE VIEW pour afficher la politique de masquage sur la colonne d’une table ou d’une vue.

Fonctions de hachage, de cryptage et de chiffrement dans les politiques de masquage

Le hachage et Cryptographique/Somme de contrôle peuvent être utilisés dans les politiques de masquage pour masquer les données sensibles.

Pour plus d’informations, voir Rubriques de sécurité avancées au niveau des colonnes.

Tables externes

Vous ne pouvez pas appliquer une politique de masquage à la colonne VALUE de la table externe lorsque vous créez la table externe avec une instruction CREATE EXTERNAL TABLE car cette colonne est automatiquement créée par défaut.

Vous pouvez appliquer la politique de masquage à la colonne VALUE de table externe en exécutant une instruction ALTER TABLE … ALTER COLUMN sur la table externe.

ALTER TABLE <name> MODIFY COLUMN VALUE SET MASKING POLICY <policy_name> ;

Une politique ne peut être définie sur aucune autre colonne de table externe, y compris les colonnes virtuelles ajoutées par l’utilisateur. Si ces colonnes doivent être protégées, créez une vue sur la table externe et appliquez une politique à la colonne de la vue.

Important

Snowflake ne prend pas en charge l’utilisation d’une table externe comme table de consultation (c’est-à-dire dans une sous-requête) dans une politique de masquage. Lors du clonage d’une base de données, Snowflake clone la politique de masquage, mais pas la table externe. Par conséquent, la politique dans la base de données clonée fait référence à une table qui n’est pas présente dans la base de données clonée.

Si les données de la table externe sont nécessaires pour la politique, envisagez de déplacer les données de la table externe vers un schéma dédié de la base de données dans laquelle la politique de masquage existe avant de réaliser une opération de clonage. Mettez à jour la politique de masquage pour faire référence au nom de table entièrement qualifié afin de vous assurer que la politique fait référence à une table dans la base de données clonée.

Flux

Les politiques de masquage des colonnes d’une table sont transférées dans un flux de la même table.

Résultat : les utilisateurs non autorisés voient les données masquées ; les flux créés par des utilisateurs autorisés voient les données telles que définies par la politique de masquage.

Objets clonés

L’approche suivante permet de protéger les données des utilisateurs avec le privilège SELECT lors de l’accès à un objet cloné.

  • Le clonage d’un objet de politique de masquage individuel n’est pas pris en charge.

  • Le clonage d’un schéma entraîne le clonage de toutes les politiques de masquage au sein du schéma.

  • Une table clonée correspond aux mêmes politiques de masquage que la table source.

    • Lorsqu’une table est clonée dans le contexte de son clonage de schéma parent, si la table source a une référence à une politique de masquage dans le même schéma parent (c’est-à-dire une référence locale), la table clonée aura une référence à la politique de masquage clonée.

    • Si la table source fait référence à une politique de masquage dans un schéma différent (c’est-à-dire une référence étrangère), la table clonée conserve la référence étrangère.

Pour plus d’informations, voir CREATE <objet> … CLONE.

Instructions CREATE TABLE … AS SELECT (CTAS)

L’exécution d’une instruction CREATE TABLE… AS SELECT (CTAS) applique toutes les politiques de masquage sur les colonnes incluses dans l’instruction avant que les données soient remplies dans la nouvelle table (c’est-à-dire que les données de colonne applicables sont masquées dans la nouvelle table). Ce flux est respecté, car une table créée à l’aide d’une instruction CTAS peut avoir un ensemble de colonnes différent de celui des objets sources, et Snowflake ne peut pas appliquer implicitement des politiques de masquage aux nouvelles colonnes de table.

S’il est nécessaire de copier des données non masquées, utilisez un rôle autorisé pour les données protégées afin d’exécuter l’instruction CTAS. Après avoir créé la nouvelle table, transférez la propriété de la nouvelle table à un autre rôle et demandez à l’administrateur de politiques de masquage d’appliquer les politiques de masquage aux colonnes de la nouvelle table.

Pour plus d’informations, voir CREATE TABLE.

Requêtes utilisant des fonctions d’agrégation et des colonnes masquées

Il est possible d’utiliser Fonctions d’agrégation sur des colonnes avec des données masquées.

Un cas d’utilisation représentatif est qu’un analyste de données souhaite obtenir COUNT pour une colonne de numéros de sécurité sociale sans avoir besoin de voir les données réelles. Toutefois, si l’analyste de données exécute une requête à l’aide de SELECT sur une colonne de table masquée, la requête renvoie une valeur masquée fixe. Les utilisateurs avec le rôle personnalisé PAYROLL dans la session en cours voient les données non masquées et tous les autres utilisateurs voit les données masquées.

Pour atteindre ce résultat :

  1. Le propriétaire de la table crée une vue sur la colonne qui contient la fonction d’agrégation.

    CREATE VIEW ssn_count AS SELECT DISTINCT(ssn) FROM table1;
    
  2. Accordez au rôle ANALYST des privilèges complets sur la vue. N’accordez à l’analyste aucun privilège sur la table.

  3. Appliquez une politique de masquage à la colonne de table. Notez que la politique de table est toujours appliquée avant la politique de vue, s’il existe une politique sur une colonne de vue.

    case
      when current_role() in ('PAYROLL') then val
      else '***MASKED***'
    end;
    
  4. Exécutez une requête sur la colonne de vue.

    use role ANALYST;
    select count(DISTINCT SSN) from <view>;
    

Profil de requête

Lorsqu’elle est utilisée sur une colonne avec une politique de masquage, la sortie de la commande EXPLAIN inclut les données masquées, pas le corps de la politique de masquage.

L’exemple suivant génère le plan EXPLAIN pour une requête sur une table de numéros d’identification d’employés et de numéros de sécurité sociale. La commande de cet exemple génère l’exemple au format JSON.

La colonne contenant les numéros de sécurité sociale a une politique de masquage.

explain using json select * from mydb.public.ssn_record;
{
  "GlobalStats": {
    "partitionsTotal": 0,
    "partitionsAssigned": 0,
    "bytesAssigned": 0
  },
  "Operations": [
    [
      {
        "id": 0,
        "operation": "Result",
        "expressions": [
          "1",
          "'**MASKED**'"
        ]
      },
      {
        "id": 1,
        "parent": 0,
        "operation": "Generator",
        "expressions": [
          "1"
        ]
      }
    ]
  ]
}

Déchargement des données

L’utilisation de la commande COPY INTO <emplacement> sur une colonne dotée d’une politique de masquage entraîne l’application de la politique de masquage aux données. Par conséquent, les utilisateurs non autorisés voient les données masquées après l’exécution de la commande.

Gestion de la sécurité au niveau des colonnes

Cette section fournit des informations utiles pour déterminer votre approche de la gestion globale des politiques de masquage, décrit les privilèges requis pour gérer la sécurité au niveau des colonnes et répertorie les commandes DDL prises en charge.

Choisir une approche centralisée, hybride ou décentralisée

Pour gérer efficacement les politiques de masquage dynamique des données et de tokenisation externe, il est utile de déterminer si votre approche du masquage des données dans les colonnes doit suivre une approche de sécurité centralisée, une approche décentralisée ou un hybride de chacune de ces deux approches.

Le tableau suivant résume certaines des considérations relatives à chacune de ces deux approches.

Action de la politique

Gestion centralisée

Gestion hybride

Gestion décentralisée

Créer des politiques

Agent de sécurité

Agent de sécurité

Équipes individuelles

Appliquer des politiques aux colonnes

Agent de sécurité

Équipes individuelles

Équipes individuelles

En tant que meilleure pratique, Snowflake recommande que votre organisation rassemble toutes les parties prenantes concernées afin de déterminer la meilleure approche de gestion pour implémenter la sécurité au niveau des colonnes dans votre environnement.

Privilèges de politique de masquage

Cette section décrit les privilèges de politique de masquage de sécurité au niveau des colonnes et la façon dont ils s’appliquent à une approche de gestion centralisée, décentralisée ou hybride.

Snowflake fournit les privilèges suivants pour les politiques de masquage de sécurité au niveau des colonnes.

Privilège

Utilisation

APPLY

Permet d’appliquer les opérations non définies et définies de la politique de masquage, et d’exécuter l’opération DESCRIBE sur des tables et des vues.

OWNERSHIP

Transfère la propriété d’une politique de masquage, qui accorde un contrôle total sur la politique de masquage. Nécessaire pour modifier la plupart des propriétés d’une politique de masquage.

Note

Des opérations sur une politique de masquage nécessitent également le privilège USAGE sur la base de données et le schéma parents.

Les exemples suivants montrent comment l’octroi de privilèges s’applique à différentes approches de gestion. Après avoir accordé le privilège APPLY à un rôle, la politique de masquage peut être définie sur une colonne de table à l’aide d’une instruction ALTER TABLE … ALTER COLUMN ou définie sur une colonne de vue à l’aide d’une instruction ALTER VIEW (par un membre du rôle avec le privilège APPLY sur la politique de masquage).

Gestion centralisée

Dans une approche de gestion centralisée, seul le rôle personnalisé de l’agent de sécurité (par exemple SECURITY_OFFICER) crée et applique des politiques de masquage aux colonnes des tables ou des vues. Cette approche peut fournir la plus grande cohérence en matière de gestion des politiques de masquage et de masquage des données sensibles.

-- create a SECURITY_OFFICER custom role

use role accountadmin;
create role security_officer;

-- grant CREATE AND APPLY masking policy privileges to the SECURITY_OFFICER custom role.

grant create masking policy on schema <schema_name> to role security_officer;

grant apply masking policy on account to role security_officer;

Où :

  • nom_schéma

    Indique l’identificateur du schéma ; doit être unique pour la base de données dans laquelle le schéma est créé.

    De plus, 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. « Mon objet »). Les identificateurs entre guillemets doubles sont également sensibles à la casse.

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

Gestion hybride

Dans une approche de gestion hybride, le rôle personnalisé de l’agent de sécurité (par exemple SECURITY_OFFICER) crée des politiques de masquage et des équipes individuelles (par exemple, finances, paie, ressources humaines) les appliquent aux colonnes des tables ou des vues appartenant aux équipes. Cette approche peut conduire à la création et à la maintenance de politiques cohérentes, mais nécessite que chaque équipe ait la responsabilité accrue de masquer les données sensibles.

-- create a SECURITY_OFFICER custom role

use role accountadmin;
create role security_officer;

-- grant the CREATE masking policy privilege to the SECURITY_OFFICER role.

grant create masking policy on schema <schema_name> to role security_officer;

Le rôle personnalisé SECURITY_OFFICER accorde le privilège APPLY à l’équipe des ressources humaines (c’est-à-dire aux utilisateurs avec le rôle personnalisé HUMAN_RESOURCES) pour masquer les numéros de sécurité sociale (par exemple, la politique de masquage : ssn_mask) dans les colonnes pour les objets appartenant au rôle personnalisé HUMAN_RESOURCES.

grant apply on masking policy ssn_mask to role human_resources;

Où :

  • grant apply on masking policy nom_politique to role nom_politique;

    Utilisé par un propriétaire de politique pour décentraliser les opérations non définies et définies d’une politique de masquage donnée sur des colonnes vers les propriétaires d’objet.

    Ce privilège prend en charge le contrôle des accès discrétionnaire où les propriétaires d’objets sont également considérés comme des gestionnaires de données.

Approche décentralisée

Dans une approche de gestion décentralisée, chaque équipe crée et applique des politiques de masquage aux colonnes des tables ou des vues. Cette approche peut conduire à une gestion des politiques incohérente, avec la possibilité que les données sensibles ne soient pas correctement masquées, car chaque équipe assume l’entière responsabilité de la gestion des politiques de masquage et du masquage des données sensibles.

Dans cet exemple représentatif, l’équipe d’assistance (c’est-à-dire les utilisateurs avec le rôle personnalisé SUPPORT) et l’équipe financière (c’est-à-dire les utilisateurs avec le rôle personnalisé FINANCE) peuvent créer des politiques de masquage. Notez que ces rôles personnalisés peuvent ne pas inclure le rôle personnalisé SECURITY_OFFICER.

use role accountadmin;

-- grant masking policy privileges to the SUPPORT custom role.

grant create masking policy on schema <schema_name> to role support;

-- grant masking policy privileges to the FINANCE custom role.

grant create masking policy on schema <schema_name> to role finance;

L’équipe d’assistance accorde le privilège APPLY à l’équipe des ressources humaines (c’est-à-dire aux utilisateurs avec le rôle personnalisé HUMAN_RESOURCES) pour masquer les numéros de sécurité sociale (par exemple, la politique de masquage : ssn_mask) dans les colonnes pour les objets appartenant au rôle personnalisé HUMAN_RESOURCES.

use role support;
grant apply on masking policy ssn_mask to role human_resources;

L’équipe financière accorde le privilège APPLY à l’équipe d’audit interne (c’est-à-dire aux utilisateurs avec le rôle personnalisé AUDIT_INTERNAL) pour masquer les données de flux de trésorerie (par exemple, la politique de masquage : cash_flow_mask) dans les colonnes pour les objets appartenant au rôle personnalisé AUDIT_INTERNAL.

use role finance;
grant apply on masking policy cash_flow_mask to role audit_internal;

Pour plus d’informations sur les privilèges de politiques de masquage, voir :

DDL de politique de masquage

Snowflake fournit l’ensemble de commandes suivant pour gérer les politiques de masquage de sécurité au niveau des colonnes.

Le tableau suivant résume la relation entre les opérations DDL de masquage de sécurité au niveau des colonnes et leurs privilèges nécessaires.

Fonctionnement

Privilège

Créer une politique de masquage

Un rôle avec le privilège CREATE MASKING POLICY sur SCHEMA.

Modifier la politique de masquage

Le propriétaire de la politique de masquage (c’est-à-dire le rôle avec le privilège OWNERSHIP sur la politique de masquage).

Détruire la politique de masquage

Le propriétaire de la politique de masquage (c’est-à-dire le rôle avec le privilège OWNERSHIP sur la politique de masquage).

Afficher les politiques de masquage

L’un des éléments suivants : . Un rôle avec le privilège APPLY MASKING POLICY global, ou . Le propriétaire de la politique de masquage (c’est-à-dire le rôle avec le privilège OWNERSHIP sur la politique de masquage).

Décrire les politiques de masquage

L’un des éléments suivants : . Un rôle avec le privilège APPLY MASKING POLICY global, ou . Le propriétaire de la politique de masquage (c’est-à-dire le rôle avec le privilège OWNERSHIP sur la politique de masquage).

Liste des colonnes ayant une politique de masquage

L’un des éléments suivants : . Le rôle avec le privilège APPLY MASKING POLICY, ou . Le rôle avec le privilège APPLY sur MASKING POLICY sur une politique de masquage donnée et le privilège OWNERSHIP sur l’objet cible.

Utilisation des UDFs dans une politique de masquage

Si vous créez une nouvelle politique de masquage ou la modifiez, le rôle d’administrateur de politique doit être utilisé sur l’UDF, toutes les UDFs scalaires dans l’expression de la politique doivent avoir le même type de données et l’UDF doit exister.

Au moment de l’exécution de la requête, Snowflake vérifie si l’UDF existe ; sinon, l’expression SQL ne se résoudra pas et la requête échouera.

Chapitres suivants :