Sécurité des données dans Snowflake

La politique de masquage de données est un mécanisme puissant pour sécuriser l'accès aux données sensibles. Nous nous intéresserons dans cet article à Snowflake, pour voir comment y masquer les données à l’intérieur d’une colonne, mais aussi ne pas afficher certaines lignes, en fonction du rôle de l’utilisateur.

Masque des données d'une colonne dans Snowflake

Au niveau colonne, le but est de remplacer les valeurs réelles par des valeurs masquées (par exemple, des étoiles '*'), cryptées ou anonymisées. Cela permet de limiter la visibilité des données aux rôles autorisés en protégeant la confidentialité des informations.

Le code ci-dessous va permettre de créer une politique niveau colonne  ou masking policy, en remplaçant les valeurs réelles par ‘**********’ :

Le fonctionnement est le suivant :

• Create or replace masking policy simple_mask as (val string) returns string -> : Ici, nous créons une politique de masquage appelée "simple_mask". Elle prend en entrée une colonne de type "string" nommée "val" et renvoie une colonne de type "string". La flèche "->" indique le début de la logique de masquage.
• Case when current_role() in ('DEMO_NEXT_SALES') then val else '**********' end; : Cette ligne définit la logique de masquage. Elle dit que si le rôle actuel est "DEMO_NEXT_SALES", alors laissez la valeur de la colonne inchangée ("val"). Sinon, masquez la valeur en la remplaçant par "**********".
• Alter table if exists DEMO_NEXT.DEMO_NEXT_ACCESS_POLICY.CUSTOMER modify column nom set masking policy simple_mask; : Enfin, ces deux lignes appliquent la politique de masquage "simple_mask" à deux colonnes ("nom" et "prenom") de la table "CUSTOMER" dans le schéma "DEMO_NEXT_ACCESS_POLICY". Cela signifie que seuls les utilisateurs ayant le rôle "DEMO_NEXT_SALES" pourront voir les données réelles de ces colonnes, tandis que les autres verront les données masquées.

Illustrons l’exemple avec des images.

• Avec le rôle ayant le droit de voir les données :





• Avec le rôle sans les droits :

Ici, nous allons mettre en place une regexp afin de masquer le début d’un email et garder seulement le nom de domaine :

• Create or replace masking policy mail_mask as (val string) returns string -> : Nous créons une politique de masquage nommée "mail_mask" pour les données de type "string" (dans ce cas, les adresses e-mail). Cette politique renvoie également une chaîne de caractères ("string").
• Case when current_role() in ('DEMO_NEXT_SALES') then val when current_role() like ('%READER%') then regexp_replace(val,'.+\@','*****@') -- leave email domain unmasked else '*********' end; : La logique de masquage est définie ici. Elle dit que si l'utilisateur a le rôle "DEMO_NEXT_SALES", il peut voir l'adresse e-mail complète. Si l'utilisateur a un rôle contenant "READER", alors l'adresse e-mail sera masquée, sauf le domaine de messagerie, qui restera visible. Pour tous les autres utilisateurs, l'adresse e-mail est complètement masquée.
• Alter table if exists CUSTOMER modify column mail set masking policy mail_mask; : Cette dernière ligne applique la politique de masquage "mail_mask" à la colonne "mail" de la table "CUSTOMER". Cela signifie que les règles de masquage définies seront appliquées à cette colonne pour tous les utilisateurs en fonction de leurs rôles.

• Avec le rôle ayant le droit de voir les données :





• Avec le rôle sans les droits :

Passons au numéro de téléphone afin d’afficher seulement les deux premiers numéros, en remplaçant la suite par « 00.00.00.00 ».

Concernant l’affichage :

• Avec le rôle ayant le droit de voir les données :





• Avec le rôle sans les droits :

Masque des lignes d'une table dans Snowflake

Nous allons prendre l’exemple de la même table, où nous rajoutons des informations de localisation de clients basés dans différentes villes (Lyon, Paris, Nantes, Bordeaux, etc.).

L’objectif est d’avoir des rôles ayant la visibilité sur un seul département. Cette approche garantit que seules les personnes autorisées peuvent accéder aux données d’un département spécifique.

Pour faire cela, nous allons créer une « row access policy ».

• Create or replace row access policy POLICY_ROW_ACCESS_DPT as (param_value varchar) returns boolean ->: Nous créons ici une politique de contrôle d'accès au niveau des lignes appelée "POLICY_ROW_ACCESS_DPT" : Cette politique prend un paramètre de type "varchar" (généralement un département) en entrée et renvoie une valeur booléenne ("true" ou "false").
• (current_role() IN ('ACCOUNTADMIN', 'DEMO_NEXT_SALES', 'DEMO_NEXT_READER')) : Cette partie de la politique autorise automatiquement les utilisateurs ayant les rôles "ACCOUNTADMIN", "DEMO_NEXT_SALES" ou "DEMO_NEXT_READER" à accéder à toutes les données, indépendamment du département.
• (current_role() like ('%READER%DPT_'|| left(param_value, 2))) : La deuxième partie de la politique autorise les utilisateurs ayant des rôles contenant "READER" suivi du code de département spécifié dans le paramètre. Cela signifie que seuls les utilisateurs associés à un département particulier (par exemple, "DPT_01" pour le département 01) auront accès aux données de ce département.
• alter table CUSTOMER add row access policy POLICY_ROW_ACCESS_DPT on (codepostal); : Enfin, cette ligne applique la politique de contrôle d'accès "POLICY_ROW_ACCESS_DPT" à la colonne "codepostal" de la table "CUSTOMER". Cela signifie que les règles définies dans la politique seront appliquées pour contrôler l'accès aux lignes de données en fonction des rôles des utilisateurs et des départements.

Les 2 rôles précédents ont accès à tous les départements. En revanche, le rôle DEMO_NEXT_READER ne pourra pas à la différence du rôle DEMO_NEXT_SALES voir les informations sensibles ce qui donne :

• Avec le rôle ayant tous les droits :





• Avec le rôle sans les droits sur les colonnes :





• Avec le rôle ayant accès seulement au département de l’Ain :





• Avec le rôle ayant accès seulement à Paris (75) :

Pour conclure

Il est simple et rapide de mettre en place du masking de données dans Snowflake. Nous l’avons ici fait d’une façon simpliste, mais il est aussi possible de faire de l’anonymisation ou de crypter la donnée pour certains rôles. La prochaine étape sera désormais d’industrialiser le process dans différents environnements, tout cela au travers des fonctions disponibles dans Snowflake (clone, procédure stockées, paramétrage, etc…).

Retour page précédente Retour au Wiki

Vous souhaitez bénéficier d'experts·es, de développeurs·euses, ou d'une formation- sur Snowflake ? Rendez-vous sur la page Contact.