Comprendre la sécurité au niveau des colonnes¶

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.

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.

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), Vue d’ensemble des fonctions définies par l’utilisateur ou Écriture de 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.

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

Avantages¶

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

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

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

• Soyez prudent(e) lors de la création du script de configuration d’une Snowflake Native App lorsque la politique de masquage existe dans un schéma versionné. Pour des informations détaillées, voir Considérations sur les schémas versionnés.

Hiérarchie des rôles actifs et tables de mappage¶

Les conditions de la politique peuvent évaluer directement les rôles principaux et secondaires actifs de l’utilisateur dans une session, rechercher des rôles actifs dans une table de mappage ou faire les deux selon la façon dont l’administrateur de la politique veut écrire la politique. Si la politique contient une consultation de table de mappage, créez une table de mappage centralisée et stockez la table de mappage dans la même base de données que la table protégée. Ceci est particulièrement important si la politique appelle la fonction IS_DATABASE_ROLE_IN_SESSION. Pour des informations détaillées, voir les notes sur l’utilisation de la fonction.

Pour ces cas d’utilisation, Snowflake recommande d’écrire les conditions de la politique pour appeler la fonction IS_ROLE_IN_SESSION ou IS_DATABASE_ROLE_IN_SESSION selon que vous souhaitez spécifier un rôle de compte ou un rôle de base de données. Pour des exemples, voir :

• section Exemples dans la fonction IS_ROLE_IN_SESSION.

• IS_DATABASE_ROLE_IN_SESSION

• Partagez des données protégées par une politique

Pour des exemples supplémentaires utilisant des fonctions contextuelles et des politiques de masquage, voir Rubriques de sécurité avancées au niveau des colonnes.

Appliquez des politiques de masquage aux colonnes¶

Lorsqu’une colonne n’est pas protégée par une politique de masquage, 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 string masking policy ssn_mask);

-- view
CREATE OR REPLACE VIEW user_info_v (ssn masking policy ssn_mask_v) AS SELECT * FROM user_info;

Copy

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;

Copy

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

Si la politique de masquage utilise une UDF, voir Fonctions définies par l’utilisateur dans une politique de masquage (dans cette rubrique).

Appliquez une politique de masquage conditionnelle sur une colonne¶

Après avoir créé une politique de masquage en utilisant des colonnes conditionnelles, il existe deux options pour définir une politique de masquage sur une colonne lorsque la colonne n’est pas déjà protégée par une politique de masquage :

1. Pour une table ou une vue nouvelle, appliquez la politique à une colonne de table ou de vue avec l’instruction CREATE correspondante.

   Pour plus d’informations sur la syntaxe et l’utilisation, voir :

   • CREATE TABLE

   • CREATE VIEW

   • CREATE MATERIALIZED VIEW

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

   -- table
   CREATE OR REPLACE TABLE user_info (email string masking policy email_visibility) USING (email, visibility);
   
   --view
   CREATE OR REPLACE VIEW user_info_v (email masking policy email_visibility) USING (email, visibility) AS SELECT * FROM user_info;
   

   Copy

2. Pour une table ou une vue existante, définissez la politique sur une colonne de table ou de vue avec l’instruction ALTER correspondante.

   Pour plus d’informations sur la syntaxe et l’utilisation, voir :

   • ALTER TABLE

   • ALTER TABLE … ALTER COLUMN

   • ALTER VIEW

   • ALTER MATERIALIZED VIEW

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

   -- table
   ALTER TABLE IF EXISTS user_info MODIFY COLUMN email
   SET MASKING POLICY email_visibility USING (EMAIL, VISIBILITY);
   
   -- VIEW
   ALTER VIEW user_info_v MODIFY COLUMN email
   SET MASKING POLICY email_visibility USING (email, visibility);
   

   Copy

Remplacez une politique de masquage sur une colonne¶

Une fois qu’une politique de masquage est définie sur une colonne, il existe deux façons de remplacer la politique de masquage sur la colonne par une politique de masquage différente sans avoir à remplacer la table ou la vue entière.

Ces exemples utilisent des commandes ALTER TABLE. La même approche s’applique aux vues avec la commande ALTER VIEW :

• Annulez la politique d’une colonne de table dans une instruction, puis définissez une nouvelle politique sur la colonne dans une autre instruction :

  ALTER TABLE t1 MODIFY COLUMN c1 UNSET MASKING POLICY;
  
  ALTER TABLE t1 MODIFY COLUMN c1 SET MASKING POLICY p2;
  

  Copy

• Utilisez le mot-clé FORCE pour remplacer la politique dans une seule instruction :

  ALTER TABLE t1 MODIFY COLUMN c1 SET MASKING POLICY p2 FORCE;
  

  Copy

  Remarque :

  • Le mot-clé FORCE exige que le type de données de la politique dans l’instruction ALTER TABLE (c’est-à-dire STRING) corresponde au type de données de la politique de masquage actuellement définie sur la colonne (c’est-à-dire STRING).

  • Notez que le mot clé FORCE peut être combiné avec la clause USING pour définir une politique de masquage conditionnel sur la colonne :

    ALTER TABLE t1 MODIFY COLUMN c1 SET MASKING POLICY policy1 USING (c1, c3, c4) FORCE;
    

    Copy

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.

Ce comportement s’applique également aux colonnes utilisées comme colonnes conditionnelles dans une politique de masquage.

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

Simulez le fonctionnement d’une politique¶

Appelez la fonction POLICY_CONTEXT pour simuler une requête sur une colonne protégée par une politique de masquage, une table ou une vue protégée par une politique d’accès aux lignes, ou les deux types de politiques.

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;

Copy

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 colonne de table si une vue matérialisée est déjà créée à partir de la table 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>.
   

   Copy

2. Si une politique de masquage est définie sur une colonne de table sous-jacente et qu’une vue matérialisée est créée à partir de cette table, 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'.
   

   Copy

Obtenez 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>'
  )
);

Copy

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.

Politiques de balisage et de masquage des objets¶

Pour plus de détails, voir Politiques de masquage basées sur les balises.

Notez qu’une politique de masquage directement affectée à une colonne a la priorité sur une politique de masquage basée sur des balises.

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 attribuer 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 attribuer la politique de masquage à la colonne VALUE de table externe en exécutant une instruction ALTER TABLE … ALTER COLUMN sur la table externe. Le type de données de la politique de masquage qui protège la colonne VALUE doit être VARIANT.

ALTER TABLE t1 MODIFY COLUMN VALUE SET MASKING POLICY p1;

Copy

Vous pouvez attribuer une politique de masquage à une colonne virtuelle d’une table externe de la manière suivante :

• Définissez la propriété EXEMPT_OTHER_POLICIES de la politique de masquage sur TRUE dans la politique de masquage qui protège la colonne VALUE dans la table externe.

  Si cette propriété n’est pas déjà définie, exécutez une instruction CREATE OR REPLACE sur la politique de masquage qui protège la colonne VALUE et spécifiez la propriété EXEMPT_OTHER_POLICIES. La colonne virtuelle hérite de la politique qui protège la colonne VALUE, et cette propriété permet à la politique de la colonne virtuelle de remplacer la politique héritée. Pour plus de détails, voir CREATE MASKING POLICY.

• Attribuez une politique de masquage différente à la colonne virtuelle à l’aide d’une commande ALTER TABLE. Cette politique peut être moins stricte que celle de la colonne VALUE car la colonne virtuelle est moins sensible. La colonne virtuelle contient moins de données que la colonne VALUE ; la colonne VALUE contient toutes les données de chaque ligne de la table externe.

  Le type de données de la politique qui protège la colonne virtuelle dépend du type de données de la colonne virtuelle.

Concernant les colonnes conditionnelles dans une politique de masquage, une colonne virtuelle peut être répertoriée comme un argument de colonne conditionnelle pour déterminer si le premier argument de la colonne doit être masqué ou tokenisé. Cependant, une colonne virtuelle ne peut pas être spécifiée comme la première colonne à masquer ou à tokeniser.

Pour plus d’informations, voir CREATE MASKING POLICY.

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 sur la table ou la vue lors de l’accès à un objet cloné :

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

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

• Une table clonée correspond aux mêmes politiques que la table source. En d’autres termes, si une politique est définie sur la table de base ou ses colonnes, la politique est attachée à la table clonée ou ses colonnes.

  • 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 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 clonée.

  • Si la table source fait référence à une politique 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;
   

   Copy

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;
   

   Copy

4. Exécutez une requête sur la colonne de vue.

   USE ROLE analyst;
   SELECT COUNT(DISTINCT ssn) FROM v1;
   

   Copy

Fonctions définies par l’utilisateur dans une politique de masquage¶

Une UDF peut être transmise dans les conditions de la politique de masquage.

Il est important de s’assurer que le type de données de la colonne de la table ou de la vue, l’UDF et la politique de masquage correspondent. Si les types de données sont différents, par exemple si une colonne de table et l’UDF ont un type de données VARIANT et que la politique de masquage (avec cette UDF dans les conditions de la politique) renvoie un type de données VARCHAR, Snowflake renvoie une erreur lors d’une requête sur la colonne de table lorsque cette politique de masquage est définie sur la colonne de table.

Pour un exemple représentatif de la correspondance du type de données d’une colonne de table, d’une UDF, et d’une politique de masquage, voir l’exemple Utilisation d’UDFs JavaScript sur JSON (Variante) dans CREATE MASKING POLICY.

Partage de données¶

Utilisation:

• Si le fournisseur affecte une politique à une table ou à une vue partagée et que les conditions de la politique appellent la fonction CURRENT_ROLE ou CURRENT_USER, ou que les conditions de la politique appellent une UDF sécurisée, Snowflake renvoie une valeur NULL pour la fonction ou l’UDF dans le compte du consommateur.

  La raison en est que le propriétaire des données partagées ne contrôle généralement pas les utilisateurs ou les rôles du compte avec lequel la table ou la vue est partagée. Comme solution de contournement, utilisez la fonction CURRENT_ACCOUNT dans les conditions de la politique.

  En tant que fournisseur, vous pouvez également écrire les conditions de la politique pour appeler la fonction IS_DATABASE_ROLE_IN_SESSION et partager le rôle de la base de données. En tant que consommateur, accordez le rôle de base de données partagée à un rôle de compte. Pour plus de détails, voir Partagez des données protégées par une politique.

Limitations:

• Un fournisseur de partage de données ne peut pas créer de politique dans un compte de lecteur.

• Les consommateurs de partage de données ne peuvent pas appliquer une politique à une table ou une vue partagée. Comme solution de rechange, importez la base de données partagée et créez une vue locale à partir de la table ou de la vue partagée.

• Les consommateurs de partage de données ne peuvent pas interroger une table ou une vue partagée qui fait référence à deux fournisseurs différents. Par exemple :

  • rap1 est une politique d’accès aux lignes qui protège la table nommée t1, où t1 est dans le partage nommé share1 d’un fournisseur.

  • Les conditions de la politique rap1 font référence à une table de mappage nommée t2, où t2 provient de share2 et d’un fournisseur différent.

  • La requête du consommateur sur t1 échoue.

  • Le fournisseur de t1 peut interroger t1.

• Fonctions externes :

  Snowflake renvoie une erreur si :

  • La politique affectée à une table ou une vue partagée est mise à jour pour appeler une fonction externe.

  • La politique appelle une fonction externe et vous tentez d’affecter la politique à une table ou une vue partagée.

Réplication¶

Les politiques de masquage et leurs affectations peuvent être répliquées à l’aide de la réplication de bases de données et de groupes de réplication.

Pour la réplication de base de données, l’opération de réplication échoue si l’une des conditions suivantes est vraie :

• La base de données principale se trouve dans un compte Enterprise (ou supérieur) et contient une politique, mais au moins un des comptes approuvés pour la réplication se trouve sur des éditions inférieures.

• Une table ou une vue contenue dans la base de données principale fait référence pendante à une politique de masquage dans une autre base de données.

Le comportement de la référence pendante pour la réplication des bases de données peut être évité lors de la réplication de plusieurs bases de données dans un groupe de réplication.

Note

En cas d’utilisation des actions de basculement et de restauration, le compte Snowflake doit être Business Critical Edition ou supérieur.

Pour plus d’informations, voir Présentation de la réplication et du basculement à travers plusieurs comptes.

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

Snowflake Native App Framework¶

Pour des informations détaillées sur l’utilisation de politiques de masquage avec une Snowflake Native App, voir :

• Restrictions sur le partage du contenu de données contenant des politiques.

• Définir des politiques sur les vues proxy.

• Fonctions contextuelles bloquées.

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.

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.

Notez que l’exploitation d’un objet dans un schéma requiert é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 mydb.mysch TO ROLE security_officer;

GRANT APPLY MASKING POLICY ON ACCOUNT TO ROLE security_officer;

Copy

Où :

• schema_name

  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.

USE ROLE ACCOUNTADMIN;
CREATE ROLE security_officer;
GRANT CREATE MASKING POLICY ON SCHEMA mydb.mysch TO ROLE security_officer;

Copy

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.

USE ROLE security_officer;
GRANT APPLY ON MASKING POLICY ssn_mask TO ROLE human_resources;

Copy

Où :

• grant apply on masking policy policy_name to role role_name;

  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 CREATE MASKING POLICY ON SCHEMA mydb.mysch TO ROLE support;
GRANT CREATE MASKING POLICY ON SCHEMA <DB_NAME.SCHEMA_NAME> TO ROLE FINANCE;

Copy

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;

Copy

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;

Copy

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

• Utilisation du masquage dynamique des données

• Utilisation de la tokenisation externe

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.

• 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

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.

Notez que l’exploitation d’un objet dans un schéma requiert également le privilège USAGE sur la base de données et le schéma parents.

Découvrez les politiques de masquage¶

Vous pouvez utiliser la vue MASKING_POLICIES dans le schéma Account Usage de la base de données partagée SNOWFLAKE. Cette vue est un catalogue de toutes les politiques de masquage de votre compte Snowflake. Par exemple :

SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.MASKING_POLICIES
ORDER BY POLICY_NAME;

Copy

Identifier les affectations¶

Snowflake prend en charge différentes options pour identifier les affectations de politiques de masquage, de balises, selon que la requête doit cibler le compte ou une base de données spécifique.

• Requête au niveau du compte :

  Utilisez la vue Account Usage POLICY_REFERENCES pour déterminer toutes les colonnes qui ont une politique de masquage. Par exemple :

  SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.POLICY_REFERENCES
  ORDER BY POLICY_NAME, REF_COLUMN_NAME;
  

  Copy

• Requête au niveau de la base de données :

  Chaque base de données Snowflake comprend un Schéma d’information de Snowflake. Utilisez la fonction de table Information Schema POLICY_REFERENCES pour déterminer toutes les politiques de masquage sur les colonnes d’une table donnée :

  SELECT *
  FROM TABLE(
    my_db.INFORMATION_SCHEMA.POLICY_REFERENCES(
      'my_table',
      'table'
    )
  );
  

  Copy

  Vous pouvez également utiliser cette fonction pour interroger le nom de la politique de masquage afin de trouver les objets associés à une politique de masquage donnée.

Accès à la zone de gouvernance dans Snowsight¶

Pour accéder à la zone Governance , votre compte Snowflake doit être Enterprise Edition ou supérieur. En outre, vous devez effectuer l’une des opérations suivantes :

• Utilisez le rôle ACCOUNTADMIN.

• Utilisez un rôle de compte auquel sont directement attribués les rôles de base de données GOVERNANCE_VIEWER et OBJECT_VIEWER.

  Vous devez utiliser un rôle de compte avec ces attributions de rôle de base de données. Actuellement, Snowsight n’évalue pas les hiérarchies de rôles et les rôles de base de données définis par l’utilisateur qui ont accès aux tables, aux vues, aux politiques d’accès aux données et aux balises.

  Pour déterminer si votre rôle de compte bénéficie de ces deux rôles de base de données, utilisez une commande SHOW GRANTS :

  SHOW GRANTS LIKE '%VIEWER%' TO ROLE data_engineer;
  

  Copy

  |-------------------------------+-----------+---------------+-----------------------------+------------+-----------------+--------------+------------|
  | created_on                    | privilege | granted_on    | name                        | granted_to | grantee_name    | grant_option | granted_by |
  |-------------------------------+-----------+---------------+-----------------------------+------------+-----------------+--------------+------------|
  | 2024-01-24 17:12:26.984 +0000 | USAGE     | DATABASE_ROLE | SNOWFLAKE.GOVERNANCE_VIEWER | ROLE       | DATA_ENGINEER   | false        |            |
  | 2024-01-24 17:12:47.967 +0000 | USAGE     | DATABASE_ROLE | SNOWFLAKE.OBJECT_VIEWER     | ROLE       | DATA_ENGINEER   | false        |            |
  |-------------------------------+-----------+---------------+-----------------------------+------------+-----------------+--------------+------------|
  

  
  

  Si votre rôle de compte ne bénéficie pas de l’un ou de l’autre de ces rôles de base de données, ou n’en a aucun des deux, utilisez la commande GRANT DATABASE ROLE et exécutez de nouveau la commande SHOW GRANTS pour confirmer les attributions :

  USE ROLE ACCOUNTADMIN;
  GRANT DATABASE ROLE SNOWFLAKE.GOVERNANCE_VIEWER TO ROLE data_engineer;
  GRANT DATABASE ROLE SNOWFLAKE.OBJECT_VIEWER TO ROLE data_engineer;
  SHOW GRANTS LIKE '%VIEWER%' TO ROLE data_engineer;
  

  Copy

  Pour plus de détails sur ces rôles de base de données, consultez Rôles des bases de données SNOWFLAKE.

Tableau de bord¶

En tant qu’administrateur de données, vous pouvez utiliser l’interface Dashboard pour surveiller l’utilisation des balises et des politiques de la manière suivante.

• Couverture : spécifie le nombre et le pourcentage en fonction de la présence d’une politique ou d’une balise dans une table, une vue ou une colonne.

• Prévalence : liste et compte les politiques et les balises les plus fréquemment utilisées.

La couverture et la prévalence donnent un aperçu de la qualité de la protection et du balisage des données.

Lorsque vous sélectionnez un nombre, un pourcentage, un nom de politique ou un nom de balise, l’interface Tagged Objects s’ouvre. L’interface Tagged Objects met à jour les filtres automatiquement en fonction de votre sélection dans l’interface Dashboard.

Les informations de surveillance constituent une alternative ou un complément à l’exécution d’opérations complexes et exigeantes en requêtes sur plusieurs vues Account Usage.

Ces vues peuvent inclure, sans s’y limiter, les vues COLUMNS, POLICY_REFERENCES, TABLES, TAG_REFERENCES, et VIEWS.

Objets balisés¶

En tant qu’administrateur de données, vous pouvez utiliser cette table pour associer rapidement la couverture et la prévalence dans Dashboard à une liste de tables, de vues ou de colonnes spécifiques. Vous pouvez également filtrer manuellement les résultats de la table, comme suit.

• Choisissez Tables ou Columns.

• Pour les balises, vous pouvez filtrer avec les balises, sans les balises ou par une balise spécifique.

• Pour les politiques, vous pouvez filtrer avec les politiques, sans les politiques ou par une politique spécifique.

Lorsque vous sélectionnez une ligne dans la table, l’onglet Table Details ou Columns de Data » Databases s’ouvre. Vous pouvez modifier les attributions des balises et des politiques si nécessaire.

Pour plus de détails, voir Découverte des balises et des politiques