🎯

Objectif de ce tutoriel

Dans ce tutoriel, nous allons voir comment appliquer du “Row level security” à un tableau de bord Looker Studio branché sur Google BigQuery. C’est à dire, à faire en sorte que sur un tableau de bord donné chaque utilisateur n’ai accès qu’à la donnée à laquelle il est supposé avoir accès en fonction de ses droits. Par exemple, dans une organisation mondiale, les personnes en Europe auraient accès uniquement à la donnée Europe, alors que les personnes au niveau groupe auraient accès à la donnée du monde entier.

Introduction

💡

Définition : qu’est-ce le “row level security ?” Le “row level security designe le fait de gérer les accès non pas au niveau d’une table ou d’un dataset, mais plutôt d’ouvrir les accès à un dataset à tout le monde, en limitant les lignes qui peuvent être lues ou requêtées pour chaque personne.

Voici quelques cas d’usage dans lesquels vous pouvez utiliser le RLS :

Différents services d’une même entreprise qui partagent la même infrastructure tout en ayant besoin d’un accès isolé à leurs données par département.

Différents rôles au sein d’un même service qui ne doivent pas voir le même niveau d’accès aux données du service.

Des rôles similaires mais dans une organisation internationale, où les utilisateurs français n’ont pas forcément à voir les données utilisateurs allemands, et vice versa.

Des utilisateurs travaillant sur différents projets. Ces utilisateurs n’auront besoin d’avoir accès uniquement aux projets qui les concerne et non pas à tous les projets de l’entreprise.

En clair, il peut exister autant de cas d’usage qu’il peut exister d’entreprise.

👉 Dans ce tutoriel, nous allons voir les étapes suivantes :

Créer une liste de droits avec les accès associés dans Google Sheet (pour faire simple)

Filtrer une table dans Google BigQuery en fonction de l’utilisateur qui la consulte

Brancher un tableau de bord Looker Studio sur cette table, et regarder le résultat

Ce tutoriel est simple, et à but illustratif. Il ne représente pas la manière dont cela serait géré dans une organisation réelle. En particulier, la gestion des droits ne se ferait pas dans un Google Sheet comme ici.

1. Situation de départ

Nous avons une table BigQuery avec les résultats de tests automatiques que nous menons sur nos clients pour vérifier que les tags se déclenchent correctement. Nous avons plusieurs dimesions dans cette table, mais celle qui va nous intéresser ici es la “client”.

En parallèle de cela, nous avons branché cette table BigQueyr à un tableau de bord Looker Studio dans lequel se trouvent les résultats de l’outils de tous nos clients.

💡

Nous souhaitons ici que chaque consultants n’aient accès qu’aux données des clients auxquels il a le droit d’avoir accès.

Pour cela, nous allons créer un fichier Google Sheet permettant de faire la correspondance entre les consultants et les clients qui y sont rattachés.

2. Création des correspondances

Création d’une table de correspondance, avec les email ainsi que les projets affectés aux consultants.

Cette feuille GSheet est ensuite importée dans BigQuery afin de pouvoir la travailler dans le même environnement.

3. Création d’une “authorized view” avec la fonction `SESSION_USER()`

💡

La fonction session_user()

Cette fonction renvoie en réponse l’adresse mail de la personne qui fait la requête. Que ce soit directement dans l’interface BigQuery, ou bien dans Looker Studio

👉 Créer la “authorized view”

Nous allons simplement faire une jointure entre les deux tables avec comme clé commune la colonne clients, tout en filtrant sur l’adresse mail de l’utilisateur.

sql
SELECT * FROM `MA-TABLE-DE-RÉSULTATS` a

JOIN `MA-TABLE-DE-CORRESPONDANCE` b
  ON SESSION_USER() = b.email
WHERE a.client = b.client

Maintenant, en lançant cette requête avec le compte de Nicolas, et les résultats sont bien filtrés sur un seul client (UnNest ici en l’occurence) qui était attribué à Nicolas dans la table de correspondance.

En faisant la même requête avec notre adresse générique UnNest, à laquelle nous avons affecté tous les comptes dans le tableau de correspondance, alors les données requêtées sont plus larges car ce compte a plus de droits que celui de Nicolas.

💡

Pour finir, nous créons simplement une vue à partir de cette requête

4. Connexion à Looker Studio

Il ne reste plus qu’à connecter Looker Studio sur la page qui avait déjà été créée :

💡

Étape très importante : Dans votre source de données créée, il faut choisir “Data credentials” = “Viewer’s credentials”, sinon la vue sera filtré sur les droits de la personne qui a créé la source de données, et pas sur celle de la personne qui consulte le rapport.

Votre rapport est alors partageable à vos utilisateurs.

Conclusion et limites de la fonctionnalité

Nous constatons que cette fonctionnalité fonctionne aussi pour les tableaux de bord qui sont “embed” dans une application. Ce qui peut-être très pratique lorsque vous intégrez “embed” votre rapport dans des applications/sites tierces.

La limite principale provient du fait que la requête n’est qu’une authorized view, et donc ni BigQuery ni Looker Studio ne peuvent utiliser de cache ou accélérer les requêtes. Sur de gros volumes de données, cela peut avoir un impact non négligeable sur le temps de chargement des tableaux de bord.

La principale limite provient du fait que s’agissant d’une authorized View, ni BigQuery ni Looker Studio ne peuvent utiliser de cache ou “accélérer” les requêtes.