Plusieurs d’entre vous m’avez approché récemment pour mettre en place une situation complexe de rôles RLS (Row Level Security) dans Power BI.
Un cas qui revient souvent est le suivant :
Une hiérarchie de produits ou de centres de coûts ou de centres de profits est en place dans l’entreprise.
- La haute direction de la compagnie doit avoir accès à l’intégralité des données
- Les directeurs de chaque groupe doivent avoir accès à leurs données respectives
- Les vendeurs doivent avoir accès seulement à leur produit.
Pour éviter de créer un rôle de sécurité par personne, on doit bien réfléchir la configuration du rôle et de la hiérarchie des Produits/Centres de coûts/Centre de profits (Appelés « Produits » pour le reste de l’article).
Avant de se lancer, rappelons que les rôles de sécurité par lignes dans Power BI (rôles RLS) fonctionnent comme un « Filtre » sur nos données sources. Pour en savoir plus sur la création et le fonctionnement des rôles RLS.
Configuration d’un rôle RLS complexe pas à pas
1. L’importance du modèle de données
On doit donc s’assurer que le modèle de données soit construit selon les meilleurs pratiques d’affaires pour réussir à y appliquer les rôles RLS. Dans notre cas, le modèle de données initial ressemblait à ceci.
Pour appliquer une sécurité par produit, je vais devoir appliquer un « filtre » sur la table DimProducts. La table de commandes sera ensuite automatiquement filtrée selon les produits accessibles à chaque usager.
2. Créer une table de produits
Pour éviter de céer un rôle de sécurité par usager, je vais créer une table qui contient chaque produit accessible pour chaque usager. Les données sources provenant du système du client ressemblent à ceci.
La colonne « Accès » nous donne l’information pertinent concernant le niveau d’accès de chaque personne. Par exemple, Orlando Gee doit avoir accès à tous les produits. Janet Gates doit avoir accès à tous les produits dont le code débute par 8. Kathleen Garza doit avoir accès à tous les produits dont le code débute par 74. Finalement, Johnny Caprio doit avoir accès seulement au produit 835.
Vous devez analyser de grandes quantités de données et les présenter dans des rapports et tableaux de bord, avec des indicateurs de performance pertinents ? Développez vos compétences avec nos formations Power BI en français ou en anglais. |
|---|
3. Transformer la table dans Power Query
Je cherche à obtenir une table qui liste tous les produits accessibles par personne. Je vais donc transformer la table d’accès dans Power Query. Tout d’abord, j’ajoute une colonne à cette table qui contient tous les produits de la table DimProduits.
Ensuite je peux développer la colonne ProductID de la table DimProduits pour obtenir une liste complète de tous les produits pour chaque utilisateur.
Je duplique ensuite la colonne « Acces » et enlève le symbole « * ». Je peux ensuite créer une colonne conditionnelle qui ramène uniquement les codes de produits qui débutent par la valeur de la nouvelle colonne « Accès ». De cette façon, je peux en une seule étape obtenir tous les produits pour tous les niveaux d’accès des rôles RLS.
En filtrant la colonne « Personnalisé » sur les lignes qui contiennent des valeurs, j’obtiens donc une liste exhaustive des produits qui doivent être accessibles pour chaque usager.
On peut maintenant valider que les résultats obtenus dans la table d’accès par usager sont adéquats. Par exemple, si je filtre la table d’accès pour l’usager Kathleen Garza qui doit avoir accès à tous les produits dont le code débute par 74. On est en mesure de confirmer que tous les produits sous son nom débutent par 74.
Le modèle de données final ressemble à ceci :
4. Appliquer un filtre de sécurité
Lors de la création de la relation entre la table d’accès et la table de produit, il faut s’assurer que le filtre de sécurité soit appliqué dans les deux directions.
5. Créer un rôle de sécurité
On peut maintenant tester le résultat en créant un rôle de sécurité basé sur une adresse courriel. Pour apprendre comment créer un rôle de sécurité, vous pouvez consulter cet article où Sophie vous détaille les étapes à suivre.
Avant d’appliquer le rôle, le rapport ressemble à ceci :
Lorsqu’on visualise le rapport avec le rôle nouvellement créé, le résultat est adapté pour conserver uniquement les produits qui débutent par 74.
6. Modifier le rôle de sécurité
On veut maintenant que le rôle s’ajuste à l’usager qui consulte le rapport plutôt que de créer un rôle de sécurité par usager. Pour y arriver, j’utilise la fonction DAX UserName ou UserPrincipalName qui renvoient l’adresse courriel de l’usager lorsque le rapport est publié dans le Service.
Je vais donc modifier le rôle de sécurité pour que le filtre s’ajuste en fonction de l’adresse courriel de l’usager actif.
En publiant sur le Service, il ne vous restera qu’à attribuer le rôle de sécurité à vos usagers et le tour est joué ! N’hésitez pas à nous partager comment les rôles RLS vous simplifient le partage de vos rapports Power BI dans la zone de commentaires !
Fichier d’accompagnement VIP à télécharger
Pour télécharger le fichier utilisé dans ce tutoriel, devenez membre VIP du CFO masqué.
Formation complémentaire
Pour une introduction au langage DAX, utilisé par Power Pivot et par Power BI Desktop, qui permet de créer des tableaux de bord flexibles et faciles à mettre à jour en plus de créer des visualisations de données évoluées et pertinentes, suivez la formation Introduction au langage DAX (Power BI et Power Pivot).
Voici quelques commentaires d’apprenants ayant suivi cette formation :
La mission du CFO masqué est de développer les compétences techniques des analystes et des contrôleurs de gestion en informatique décisionnelle avec Excel et Power BI et favoriser l’atteinte de leur plein potentiel, en stimulant leur autonomie, leur curiosité, leur raisonnement logique, leur esprit critique et leur créativité.
