Snowflake sur Snowflake : comment nous avons renforcé la gouvernance des données à l’aide du masquage dynamique des données

Snowflake sur Snowflake : comment nous avons renforcé la gouvernance des données à l’aide du masquage dynamique des données


La gestion de l’accès aux données sensibles est le nom du jeu en matière de sécurité et de gouvernance des données. Il est nécessaire de protéger les données sensibles contre les modifications ou l’exposition non autorisées, et c’est désormais un mandat dans le cadre des réglementations sur la confidentialité telles que le GDPR et le California Consumer Privacy Act. (CCPA). Les entreprises du monde entier se concentrent désormais sur la protection des informations personnelles sensibles associées à leurs clients et employés.

Le contrôle d’accès traditionnel basé sur les rôles (RBAC) peut être utilisé pour appliquer et contrôler l’accès au moindre privilège. Mais que se passe-t-il lorsque les contrôles RBAC traditionnels ne permettent pas la bonne flexibilité ? Chez Snowflake, nous avons utilisé le nouveau Masquage dynamique des données fonctionnalité pour concevoir un modèle RBAC qui nous donne un contrôle granulaire sur les autorisations de visualisation de nos employés pour soutenir notre modèle de gouvernance des données.

Contrôle d’accès basé sur les rôles

Snowflake offre un robuste Système RBAC où les administrateurs peuvent créer des rôles personnalisés pour répondre aux exigences de leur organisation. La conception RBAC interne de Snowflake est basée sur le principe du moindre privilège, où les utilisateurs n’ont accès qu’aux privilèges requis pour leurs tâches. Les rôles sont conçus pour créer une séparation claire des tâches entre l’accès en lecture seule et l’accès en écriture. Snowflake distingue cette séparation entre les rôles d’utilisateur d’entreprise (accès en lecture seule) et les rôles administratifs (accès en écriture). Plus de détails sur cette conception feront l’objet d’un prochain article de blog.

Cependant, même si le modèle RBAC de Snowflake fournissait un cadre solide pour résoudre la plupart des exigences de contrôle d’accès, il présentait toujours des limites :

  • RBAC fonctionnait bien pour contrôler l’accès en écriture aux données, mais l’accès en lecture seule offrait un ensemble de défis différent.
  • Si les rôles et les autorisations sont trop granulaires, la gestion des rôles devient très manuelle et indisciplinée.
  • Si les rôles et les autorisations sont trop larges, ils n’adhèrent pas au modèle de moindre privilège.

La gestion de l’accès aux données sensibles à l’aide du modèle RBAC signifiait que nous devions exiger et suivre des approbations spéciales pour chaque demande d’accès. Nous pourrions créer plusieurs vues, ce qui éliminerait les informations qu’un certain groupe d’utilisateurs ne devrait pas voir. Cependant, cela nécessiterait qu’un administrateur gère l’accès à plusieurs tranches du même ensemble de données. Comme vous pouvez l’imaginer, cette approche devient rapidement désordonnée.

La pression était sur

Confrontées à la nécessité de créer un framework de contrôle d’accès puissant et flexible, nos équipes se sont concertées pour énumérer toutes les méthodes possibles. Devrions-nous révoquer l’accès aux tables et recréer des vues avec les colonnes sensibles supprimées ? Doit-on alors ajuster les permissions des rôles ? Ou devrions-nous simplement révoquer les rôles des utilisateurs et ensuite voir qui se plaint ? Ces approches pourraient-elles casser des flux de travail et des rapports existants ?

Tout semblait être une approche disparate qui causerait des perturbations et rendrait également l’environnement plus encombré et obscur. Cependant, avec Snowflake, il existe toujours un moyen plus intelligent de résoudre des défis difficiles.

Le masquage des données à la rescousse

Snowflake a récemment publié le Masque de données dynamiqueg fonctionnalité, qui permet à un administrateur désigné de créer et d’appliquer des stratégies de masquage au niveau des colonnes (voir la figure 1). Ces politiques peuvent être définies spécifiquement pour restreindre l’accès aux données dans les colonnes (de tables ou de vues) sur lesquelles la politique est appliquée. En fonction de la politique, certains rôles autorisés (rôles allumés en vert) verront les valeurs de colonne « telles quelles », tandis que les autres rôles (rôles allumés en rouge) verront des valeurs masquées. La définition de la politique permet également une grande flexibilité. Par exemple, si vous ne voulez pas élaborer les noms de chaque rôle qui ne devrait pas voir la valeur exacte de la cellule de la colonne, vous ne pouvez nommer que les rôles éclairés en vert ou en rouge. Les utilisateurs avec les rôles allumés en rouge pourraient toujours interroger la table ou la vue mais ne verraient pas les valeurs réelles de la colonne masquée.

DG post
Figure 1 : Des politiques peuvent être définies pour restreindre l’accès aux données dans les colonnes des tables ou des vues.

Cette approche était la solution que nous recherchions ! Nous pourrions créer un ensemble de politiques pour masquer chaque colonne contenant des données sensibles sur l’ensemble d’un compte. Seuls les rôles autorisés attribués aux personnes qui ont besoin d’un accès pourraient voir ces colonnes, et les autres ne verraient que la valeur définie dans la stratégie (par exemple, « 000000 »). La meilleure partie était que l’application de la nouvelle politique de masquage des données n’affectait pas négativement ou ne brisait aucune requête ou rapport. Rien n’a changé pour la majorité des utilisateurs.

Cette approche était une solution rapide, efficace et complète à un problème difficile, mise en œuvre en quelques jours au lieu de plusieurs semaines. Aucune révision du RBAC ou de la configuration actuelle des bases de données et des tables n’a été nécessaire. Au lieu de cela, nous devions simplement écrire un ensemble précis de politiques et les appliquer aux bonnes tables et aux bons rôles. Cette nouvelle fonctionnalité nous a montré la puissance de Snowflake : elle peut rendre les données accessibles et également les rendre accessibles aux bonnes personnes.

Conclusion

« Qui peut voir ce Les données? » est une question impérative à laquelle toute entreprise doit répondre. Avec Dynamic Data Masking en complément du kit RBAC traditionnel d’outils de résolution de problèmes, les administrateurs de compte et de base de données Snowflake ont des raisons de se réjouir. Cette fonctionnalité est un complément parfait à la timonerie de la sécurité et de la gouvernance des données, fonctionnant en harmonie avec le RBAC. Pour en savoir plus sur le masquage dynamique des données et sur la manière dont il peut compléter vos contrôles d’accès Snowflake existants, consultez la documentation Snowflake suivante :

Laisser un commentaire

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