02 • 34 • 09 • 31 • 70
Power BI est une solution complète d’analyse et de restitution de données dans le cloud qui offre plusieurs fonctionnalités pour répondre à vos exigences de sécurité.
La grande force de Power BI c’est qu’il s’appuie sur l’annuaire Azure AD pour gérer l’authentification des utilisateurs. Une fois les règles d’accès identifiées, vous pouvez les implémenter sur plusieurs niveaux :
- Espaces de travail : Attribuer un droit d’accès sur l’ensemble des artefacts (Dashboards, Rapports, Jeux de données, Dataflows) de l’espace de travail
- Applications : Attribuer les droits de lecture aux utilisateurs (ou groupe d’utilisateurs) sur une application
- Rapports
- Jeux de données
- Objets d’un jeu de données : OLS pour Object Level Security (Colonnes, ...)
- Lignes d’une table d’un jeu de données : RLS pour Row Level Security
Le but de cet article est de faire un focus sur les fonctionnalités de Row Level Security (RLS) dans Power BI et présenter les différentes méthodes envisageables.
Cas d'utilisation et données test dans Power BI
Pour illustrer les différents cas de figure, nous avons simulé un jeu de données très basique :
- Une table de fait avec des montants par agence et par projet
- Une table de dimension avec la liste des agences
- Une table de dimension avec la listes des projets
L’objectif est de sécuriser l’accès aux données (Montants) en fonction du périmètre auquel accède chaque profil utilisateur. Indépendamment de la solution, il faudra passer par principalement 3 étapes :
- Créer les rôles adéquats depuis Power BI Desktop
- Définir dans chaque rôle les filtres que Power BI doit appliquer pour effectuer les restrictions d’accès attendues.
- Après déploiement du jeu de données, déclarer dans les rôles les membres (utilisateurs ou groupes d’utilisateurs Azure AD) auxquels Power BI devra appliquer les restrictions d’accès. Ce paramétrage s'effectue depuis le portail Power BI Service, en allant sur les propriétés du jeu de données puis dans le menu "Sécurité" :
Méthode statique
La méthode statique consiste à créer un rôle pour chaque agence puis définir à chaque rôle un filtre sur l’agence en question.
Pour ce faire, aller dans le menu “Modélisation” puis “Gérer les rôles” :
Créer un rôle pour chaque agence : 2 dans notre cas
Pour l’agence A1 filtrer sur le code “A1” et pour l’agence A2 filtrer sur le code “A2”.
Pour tester les nouveaux rôles avant de publier le jeu de données dans Power Service, Power BI Desktop propose la fonction “Voir comme” depuis le menu “Modélisation”.
Après avoir effectué les tests nécessaires, il faut publier le jeu de données Power BI dans Power BI Service puis déclarer les membres du rôle depuis les paramètres de sécurité du jeu de données.
Cette méthode n’est pas simple à maintenir surtout quand il s’agit de sécuriser une dimension à forte cardinalité comme les projets, dans notre exemple, où on peut se retrouver potentiellement à gérer une centaine de rôles voire des milliers (un rôle pour chaque projet). Pour pallier à cela, nous expliquerons dans la suite de cet article la méthode dite dynamique.
Méthode dynamique
L’objectif de cette méthode est d’optimiser le nombre de rôles et d’éviter d’en créer un par agence mais plutôt un seul pour toutes les agences.
Reprenons dans cet exemple la sécurisation de l’axe “Agence”. Nous avons donc besoin d’établir la liste des utilisateurs avec les agences auxquelles ils auront accès. Les utilisateurs doivent être représentés dans cette matrice par leurs comptes Azure AD :
La méthode RLS dynamique consiste à intégrer dans le modèle de données cette matrice d’accès dont les données doivent être constituées en amont. Plusieurs options sont possibles pour gérer ces données :
- Intégrées spécialement aux sources de données pour répondre aux besoins de votre projet Power BI
- Gérées d’une manière plus transverse dans des annuaires d’entreprise. Dans cet exemple, il est possible de gérer l’appartenance des utilisateurs aux agences dans l’annuaire Azure AD puis récupérer ces informations avec Power Query qui propose un connecteur “Active Directory” pour construire la matrice de sécurité.
La matrice de sécurité “Secu-Agence” doit être ensuite reliée au reste du modèle via la table “Agence”. La relation doit être de type “double sens” avec activation de l’option “Appliquer le filtre de sécurité dans les deux directions”.
L’objectif maintenant est de créer un seul rôle “Viewers-Agence” permettant de restreindre l’accès à tous ses membres déjà déclarés dans la matrice de sécurité “Secu-Agence” en fonction de leurs périmètres.
Chaque utilisateur membre de ce rôle, le compte sous forme “
Dans notre exemple, quand l’utilisateur 1 se connecte au jeu de données, son compte “
Pour tester le nouveau rôle avant de publier le jeu de données dans Power Service et comme expliqué précédemment, il est possible d’utiliser la fonction “Voir comme” depuis le menu “Modélisation”.
Après avoir effectué les tests nécessaires, il faut publier le jeu de données Power BI dans Power BI Service puis déclarer les membres du rôle depuis les paramètres de sécurité du jeu de données.
Méthode dynamique : Voir toutes les lignes
Le problème se pose pour les utilisateurs ayant le droit de voir toutes les lignes d’une table. Dans notre exemple, prenons le cas de la table “Projet” où l’utilisateur “
Pour éviter de déclarer un par un tous les projets pour cet utilisateur dans la matrice de sécurité “Secu-Projet”, il est possible de se baser sur un projet générique pour signifier “tous les projets”. Dans cet exemple, nous avons utilisé “*” :
Comme pour les agences, la matrice de sécurité “Secu-Projet” doit être reliée au reste du modèle via la table “Projet”. La relation doit être de type “double sens” avec activation de l’option “Appliquer le filtre de sécurité dans les deux directions”.
L’objectif ensuite est de mettre à jour le rôle précédent “Viewers-Agence” en le renommant en “Viewers-AgenceProjet” pour prendre en compte les restrictions déclarées dans la matrice de sécurité “Secu-Projet” en plus des restrictions de la matrice “Secu-Agence”.
Pour prendre en compte le caractère “*” et annuler l’effet de filtre quand “*” est déclarée nous proposons d’effectuer un contrôle sur la présence d'au moins une ligne avec “*” pour l’utilisateur connecté d’où la présence du test de nombre de lignes qui doit être strictement supérieur à 0 :
0 < COUNTROWS(
FILTER('Secu-Projet','Secu-Projet'[Projet]="*"
&& 'Secu-Projet'[User]=USERPRINCIPALNAME()
)
)
Conclusion
La sécurité d’accès à la ligne est simple à implémenter dans Power BI.
Ci-dessous un résumé des étapes à suivre :
- Choisir la bonne méthode : Statique vs Dynamique
- (Uniquement pour la méthode Dynamique) : il faut définir la meilleure manière de gérer les données matrice de sécurité en amont :
- Gestion spécifique au projet Power BI
- Utilisation de l’annuaire d’entreprise
- Qui est responsable de l’administration des données de la matrice de sécurité ?
- ....
- (Uniquement pour la méthode Dynamique) : Intégrer la matrice de sécurité correctement dans le modèle de données.
- Créer les rôles nécessaires dans le gestionnaire de rôles depuis Power BI Desktop.
- Définir les filtres nécessaires pour chaque rôle. Power BI propose d’implémenter ces filtres avec des expressions DAX et profiter de la puissance de ce langage pour pouvoir aller très loin dans la prise en compte des logiques métiers complexes (attention aux temps de réponse du modèle).
- Tester les rôles implémentés directement dans Power BI Desktop avec la fonction “Voir comme”.
- Publier le jeu de données dans Power BI Services
- Depuis les paramètres de sécurité du jeu de données publié déclarer les membres des rôles créés.
Ainsi s'achève notre article sur la sécurité d'accès à la ligne dans Power BI ! Suivez notre Wiki pour ne rien manquer de nos trucs, astuces et nouvautés des éditeurs. Retrouvez également plein de tutos sur la chaîne Youtube de Next Decision !
Un projet Power BI ? Un besoin de formation Power BI ? Nos consultants experts certifiés Power BI sont à votre écoute ! Contactez-nous !