Sécurité au niveau des colonnes dans Snowflake – Development

Sécurité au niveau des colonnes dans Snowflake – Development


Snowflake est heureux d’annoncer, en avant-première aujourd’hui, la disponibilité de politiques de masquage des données qui améliorent la sécurité au niveau des colonnes dans Snowflake Cloud Data Platform. Les politiques de masquage facilitent la gestion et l’interrogation des PII, PHI et d’autres types de données sensibles. Les politiques permettent aux utilisateurs autorisés de visualiser les données sensibles en texte brut tout en empêchant les utilisateurs non autorisés de visualiser les données complètement ou à différents niveaux de rédaction. Le masquage comprend de nombreuses techniques d’obscurcissement telles que le masquage partiel, le masquage complet, le hachage, le chiffrement ou le remplacement par des valeurs tokenisées.

Electronic Arts est l’un des clients à accès anticipé utilisant cette fonctionnalité pour les charges de travail d’analyse RH. Lis ça comment poster par l’architecte BI en chef d’Electronic Arts, Vlad Valeyev, pour plus de détails.

« La plupart des plates-formes de données ne parviennent pas à protéger les données sensibles contre les super-utilisateurs disposant de droits d’administrateur, obligeant ces données à être conservées dans un silo physique, accessible uniquement à quelques-uns. La nouvelle fonctionnalité de masquage dynamique des données de Snowflake, combinée aux fonctionnalités existantes de Secure View, relève ce défi avec seulement quelques lignes de code. Aucune modification n’est requise pour le reste de la logique métier tout en gardant les données sécurisées et accessibles pour l’analyse en libre-service.
—Vlad Valeyev, architecte en chef BI, Electronic Arts.

En quoi cette solution est-elle différente de l’utilisation de vues sécurisées ?

De nombreux clients utilisent des vues sécurisées dans Snowflake pour gérer les données sensibles en masquant entièrement les colonnes sensibles aux utilisateurs non autorisés ou en les masquant à l’aide de fonctions définies par l’utilisateur (UDF). Bien que cette approche fonctionne pour certains cas d’utilisation, elle ne résout pas les problèmes suivants.

  • Les propriétaires d’objets (propriétaires de vues sécurisées) et les utilisateurs avec des rôles privilégiés ont toujours accès aux données dans les colonnes sensibles.
  • Les données chargées sous forme pré-tokénisée ne peuvent pas être détokénisées au moment de la requête.
  • Les vues sécurisées supplémentaires et les tableaux de bord BI construits dessus (dans certains cas, des milliers d’entre eux) ajoutent une charge de gestion.

Snowflake est une entreprise obsédée par le client. Nous avons entendu vos commentaires et sommes heureux d’annoncer la solution aux problèmes mentionnés ci-dessus et plus encore grâce à l’introduction de politiques de masquage des données.

Scénarios de cas d’utilisation

Les stratégies de masquage peuvent être utilisées dans les deux scénarios suivants :

Masquage dynamique des données : Les données sensibles en texte brut sont chargées dans Snowflake, et elles sont dynamiquement masquées/chiffrées au moment de la requête pour les utilisateurs non autorisés, comme illustré à la Figure 1.

Policies

Figure 1 : Exemple de masquage dynamique des données.

Tokénisation externe : Les données sensibles sont tokenisées/chiffrées en externe à l’aide de solutions partenaires ou de solutions internes développées par le client avant d’être chargées dans Snowflake. Ensuite, au moment de la requête, les données sont détokénisées/déchiffrées pour les utilisateurs autorisés via des politiques de masquage qui appellent le service de tokenisation externe à l’aide de fonctions externes. Voir Figure 2. Plusieurs partenaires ont intégré leurs solutions à Snowflake pour fournir cette fonctionnalité.

Tokenized data

Figure 2 : Exemple de tokenisation externe.

Utilisation des politiques de masquage des données

Il n’y a que trois étapes pour utiliser les politiques de masquage :

  1. Définir une politique de masquage
  2. Appliquer la stratégie à une ou plusieurs colonnes
  3. Interroger les données

Étant donné qu’une stratégie de masquage peut être appliquée à plusieurs colonnes sur des tables et des vues dans plusieurs bases de données et schémas (voir la figure 3), vous pouvez mettre à jour un algorithme de masquage et des règles d’accès de manière centralisée, et les modifications seront appliquées immédiatement à toutes les colonnes où cette stratégie est appliqué.

Masking Policy

Figure 3 : Exemple de stratégie de masquage appliquée à plusieurs colonnes dans les tables et les vues.

POLITIQUE DE MASQUAGE est un nouvel objet dans Snowflake qui capture les conditions et les fonctions à utiliser lorsque des conditions spécifiques sont remplies, comme illustré à la figure 4.

Masking Policy

Figure 4 : Spécification des conditions d’application d’une stratégie de masquage.

Dans la figure 4, les utilisateurs avec le current_role() de PII_ROLE dans la session sont autorisés à afficher les données brutes, et les utilisateurs avec le rôle SUPPORT peuvent afficher des données partiellement masquées (telles que la partie domaine d’un e-mail), tandis que le reste du les utilisateurs verront « ***MASKED*** » lorsque la politique email_mask est appliquée à une colonne sensible.

Cette approche basée sur des règles, associée au contrôle d’accès basé sur les rôles (RBAC), vous permet d’empêcher même les propriétaires de tables/vues et les utilisateurs dotés de rôles privilégiés de consulter des données sensibles.

Voici d’autres exemples de politique de masquage pour vous aider à mieux comprendre comment les politiques de masquage peuvent être utilisées pour divers scénarios.

Masking Policy


Nouvelles fonctions contextuelles intégrées

Pour aider à définir diverses conditions de politique, Snowflake introduit quatre nouvelles fonctions contextuelles intégrées :

  • est_role_in_session() Utilisez cette fonction pour vérifier si un rôle donné fait partie de la session en cours. Il compare non seulement les rôle actuel() mais aussi tous les rôles enfants qui font partie du rôle actuel() hiérarchie.
  • invocateur_role() Cette fonction retourne le rôle d’exécution du contexte d’exécution courant. Imaginez qu’une politique de masquage soit appliquée à une colonne de table qui utilise invocateur_role() dans la condition de police. Lorsqu’un utilisateur interroge la vue créée sur la table, la invocateur_role() La fonction renvoie le « rôle du propriétaire de la vue » car la table est en cours d’exécution dans le contexte d’exécution de la vue.
  • is_granted_to_invoker_role() Cette fonction vérifie si le rôle donné correspond au invocateur_role() ou l’un de ses rôles enfants dans la hiérarchie des rôles.
  • invoquer_partage() Cette fonction est destinée à être utilisée dans les scénarios de partage de données où le fournisseur souhaite partager des données sensibles avec les consommateurs de données.

Exécution de la requête d’exécution

La meilleure partie de la solution de masquage des données est que les utilisateurs finaux interrogent simplement les données sans savoir si la politique de masquage est définie sur la colonne ou non. Snowflake réécrit de manière transparente la requête au moment de l’exécution chaque fois qu’il trouve une colonne avec une stratégie de masquage attachée. Pour les utilisateurs autorisés, les résultats de la requête renvoient des données sensibles en texte brut, tandis que pour les utilisateurs non autorisés, les données sensibles sont masquées, chiffrées ou tokenisées.

Vous trouverez ci-dessous quelques exemples de requête soumise par un utilisateur et de requête exécutée après que Snowflake a réécrit automatiquement la requête.

User Query

La réécriture est effectuée à tous les endroits où la colonne protégée est présente dans la requête, comme dans les « projections », les clauses « where », les prédicats « join », les instructions « group by » ou « order by ».

Si vous souhaitez réécrire de manière sélective une requête afin que les prédicats de « jointure » ​​ne soient pas réécrits, vous pouvez créer une vue et appliquer des stratégies aux colonnes de la vue au lieu de la table d’origine.

Lorsque les vues sont exécutées, Snowflake exécute une politique imbriquée en commençant par la table de base et remonte la chaîne de vues, comme illustré à la figure 5.

Policy table view

Figure 5 : Exemples d’exécution de politique.

En fonction du cas d’utilisation, vous pouvez décider d’appliquer la stratégie uniquement à la colonne de la table de base, à la colonne de la vue ou aux deux.

Par exemple, si vous souhaitez que certains rôles autorisent l’accès à la valeur agrégée, mais pas aux informations sensibles individuelles, vous pouvez appliquer une stratégie sur la colonne de la table à l’aide de invocateur_role() et appliquez une deuxième stratégie sur la colonne d’agrégation de la vue à l’aide de la rôle actuel().

Politiques de masquage pour le partage de données

Les fournisseurs de données peuvent désormais masquer/obscurcir les données sensibles lorsqu’ils les partagent avec leurs consommateurs en appliquant simplement des politiques de masquage à la table partagée ou aux colonnes de la vue sécurisée. De plus, avec l’introduction du nouveau invoquer_partage() fonction de contexte, différentes règles de masquage peuvent être appliquées à la même colonne lorsqu’elle est utilisée dans plusieurs partages, comme le montre la figure 6. Cela donne aux fournisseurs de données une flexibilité supplémentaire dans la façon dont ils fournissent des données aux consommateurs tout en étant facile à gérer de manière centralisée.

Provider Acct

Figure 6 : Exemple de fourniture de différentes règles de masquage à une colonne faisant partie de plusieurs partages.

Gestion des politiques de masquage des données

Déterminer qui peut créer des politiques de masquage et les appliquer aux colonnes est contrôlé par de nouveaux privilèges RBAC. Différentes organisations ont des exigences différentes quant à la manière dont elles souhaitent gérer les stratégies. Certaines organisations souhaitent que les politiques soient gérées de manière centralisée, d’autres souhaitent que la gestion des politiques soit une fonction décentralisée, et d’autres organisations se situent entre les deux.

Snowflake prend en charge un continuum de tels cas d’utilisation de déploiement, comme illustré à la Figure 7. Un responsable de la sécurité/de la confidentialité peut gérer et appliquer des politiques de manière centralisée, ou le responsable de la sécurité/de la confidentialité peut définir des politiques et désigner des gestionnaires de données au sein d’équipes individuelles responsables de l’application des politiques à leurs ensembles de données. Une troisième option consiste à laisser les gestionnaires de données d’équipe définir et appliquer des politiques.

Centralized Mgmt

Figure 7 : Options de création et d’application de politiques de masquage des données.

Quelques éléments à garder à l’esprit

  1. Les politiques de masquage ne peuvent pas être appliquées aux colonnes virtuelles. Cette limitation vise à empêcher les utilisateurs de contourner la stratégie en utilisant directement l’expression sous-jacente. Si vous devez appliquer une stratégie de masquage des données à une colonne virtuelle, vous pouvez créer une vue sur les colonnes virtuelles et appliquer des stratégies aux colonnes de la vue.
  2. Étant donné que toutes les colonnes d’une table externe sont virtuelles, à l’exception de la colonne de variante VALUE, vous ne pouvez appliquer une politique de masquage des données qu’à la colonne VALUE.
  3. Les vues matérialisées ne peuvent pas être créées sur des colonnes de table avec des règles de masquage appliquées. De même, les règles ne peuvent pas être appliquées aux colonnes de table si des vues matérialisées existent sur ces colonnes. Cependant, vous pouvez appliquer des politiques de masquage aux colonnes de vue matérialisée tant qu’il n’y a pas de politique de masquage sur les colonnes sous-jacentes.
  4. Les politiques de masquage s’appliquent aux objets clonés.
  5. Le cache de l’ensemble de résultats n’est pas utilisé pour les requêtes contenant des colonnes avec des stratégies de masquage.

Conclusion

Importez vos données sensibles dans Snowflake et commencez à les interroger à l’aide du masquage dynamique des données et de la tokenisation externe. Voir Documentation sur les flocons de neige pour plus de détails. Veuillez également partager vos commentaires ou demander des améliorations via le Communauté de flocon de neige.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.