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 afficher 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 le partage de données, 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.

L’administrateur de la politique de masquage peut accorder des privilèges aux propriétaires d’objets ou à d’autres rôles pour effectuer ces actions.

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.

  • ->

    Ne remplacez pas la flèche dans l’instruction de la politique de masquage par un autre caractère.

  • 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.

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.

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é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.

Limitations

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

Objets partagés.

Pour le masquage dynamique des données, en tant que consommateur de partage de données, vous ne pouvez pas appliquer une politique de masquage à une base de données ou une table partagée. . Pour contourner ce problème, importez la base de données ou la table partagée et appliquez la politique de masquage à une vue locale sur cette base de données ou cette table partagée. . Pour la tokenisation externe, Secure Data Sharing n’est pas applicable, car les fonctions externes ne peuvent pas être appelées dans le contexte d’un partage.

Vues matérialisées (MV).

Les actions suivantes ne sont pas prises en charge : association d’une politique de masquage sur une colonne MV, création d’une MV à partir d’une table qui a une politique de masquage sur une ou plusieurs de ses colonnes, et association d’une politique de masquage à une colonne de table s’il existe une MV sur cette table.

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

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.

Plusieurs colonnes dans une seule instruction.

Une seule colonne par instruction ALTER TABLE ou ALTER VIEW. Exécutez une seule instruction ALTER sur une colonne pour définir ou annuler une politique de masquage de sécurité au niveau de la colonne.

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.

Plateforme Cloud Microsoft Azure

La prise en charge de la tokenisation externe sur la plateforme Cloud Microsoft Azure est prévue.

Google Cloud Platform

La prise en charge de la tokenisation externe sur Google Cloud Platform est prévue.

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

Pour appliquer des politiques de masquage aux colonnes dans des tables ou des vues, 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.

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.

Tables externes

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

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

Vous ne pouvez pas appliquer directement la politique de masquage à une colonne virtuelle. À la place, créez une vue sur la table externe et appliquez une politique de masquage aux colonnes de la vue.

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 CLONED

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 sécurité au niveau de la colonne

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 des opérations de définition/annulation de politiques pour la politique de masquage.

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 :

Sécurité au niveau des colonnes - DDL

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

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

Fonctionnement

Privilège requis

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 la politique 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).

SET/UNSET la politique de masquage sur les colonnes

Soit : . Un rôle avec le privilège global APPLY MASKING POLICY, soit . Un rôle avec APPLY sur le privilège MASKING POLICY sur une politique de masquage donnée et le privilège OWNERSHIP sur la table/vue cible.

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 :