La sécurité des données est une préoccupation majeure dans tout projet décisionnel. Un même rapport Power BI est souvent partagé avec des dizaines, voire des centaines d’utilisateurs ayant des responsabilités différentes. Pourtant, tous ne doivent pas accéder aux mêmes informations.
Prenons un exemple simple :
- un directeur régional doit pouvoir consulter les données de toutes les agences de sa région ;
- un responsable d’agence ne doit voir que les données de son agence ;
- un employé ne doit accéder qu’aux données qui le concernent.
Créer un rapport différent pour chaque profil serait difficile à maintenir. Microsoft Power BI propose donc un mécanisme natif appelé Row-Level Security (RLS), ou sécurité au niveau des lignes, permettant d’afficher automatiquement uniquement les données auxquelles chaque utilisateur est autorisé à accéder.
Comment fonctionne le Row-Level Security ?
Le principe est relativement simple. Power BI applique un filtre directement sur les tables du modèle de données. Lorsqu’un utilisateur ouvre un rapport, seules les lignes correspondant aux règles définies pour son rôle lui sont retournées.
Autrement dit, tous les utilisateurs consultent le même rapport et le même modèle sémantique, mais chacun voit un sous-ensemble différent des données.
La mise en œuvre du RLS s’effectue en deux étapes :
- Power BI Desktop : définition des rôles et des règles de sécurité
- Power BI Service : affectation des utilisateurs aux différents rôles
Étape 1 : Définir les rôles dans Power BI Desktop
La création des rôles s’effectue depuis l’onglet Modélisation, puis Gérer les rôles.
Cette fenêtre permet :
- de créer un nouveau rôle
- de modifier un rôle existant
- de supprimer un rôle
Pour chaque rôle, on définit un filtre DAX qui sera appliqué à une ou plusieurs tables du modèle.
Il est donc indispensable de disposer d’un modèle de données correctement conçu, notamment au niveau :
- des relations entre les tables ;
- de la direction de propagation des filtres ;
- des dimensions utilisées pour filtrer les tables de faits.
Une mauvaise modélisation peut empêcher le RLS de fonctionner correctement.
Les deux approches du Row-Level Security
Le RLS statique
Le RLS statique consiste à appliquer une valeur fixe dans le filtre.Par exemple, si l’on souhaite créer un rôle destiné aux utilisateurs canadiens, on peut appliquer le filtre suivant sur la table des clients :
Tous les utilisateurs appartenant à ce rôle ne verront que les données du Canada.
Cette approche est simple à mettre en œuvre mais devient rapidement difficile à maintenir lorsqu’il existe un grand nombre de profils.
Le RLS dynamique
Le RLS dynamique est l’approche suivant laquelle, au lieu d’utiliser une valeur fixe, le filtre s’appuie sur les informations récupérées de l’utilisateur connecté. Cela, à travers une fonction DAX. Power BI met, notamment, à disposition la fonction DAX USERPRINCIPALNAME() qui retourne l’email de l’utilisateur connecté
On l’utilise généralement avec une table de sécurité contenant les correspondances entre les utilisateurs et les entités auxquelles ils ont accès (agence, région, département, etc.).
Ainsi, un seul rôle peut gérer automatiquement des centaines, voire des milliers d’utilisateurs.
Le RLS dynamique est plus flexible, plus évolutif et beaucoup plus facile à administrer.
Tester le Row-Level Security
Avant de publier le modèle, il est recommandé de tester les rôles définis. Power BI Desktop propose la fonctionnalité Voir comme (View As). Elle permet de simuler le comportement du rapport :
- pour un rôle donné ;
- ou directement pour un utilisateur spécifique dans le cas d’un RLS dynamique.
Cette étape est importante pour vérifier que les filtres produisent bien le résultat attendu.
Étape 2 : Affecter les utilisateurs dans Power BI Service
Une fois le modèle sémantique publié dans Power BI Service, les rôles créés dans Power BI Desktop sont automatiquement disponibles.
Le développeur peut alors accéder aux paramètres de sécurité du modèle sémantique et associer les utilisateurs ou groupes Microsoft Entra ID aux différents rôles.
À partir de ce moment, les règles de sécurité sont appliquées automatiquement lors de la consultation des rapports.
Une limitation importante à connaître
Le Row-Level Security ne s’applique pas à tous les utilisateurs d’un workspace.
Les utilisateurs ayant les rôles Administrateur, Membre, Contributeur au niveau de l’espace de travail, peuvent consulter l’ensemble des données du modèle.
Le RLS est appliqué uniquement aux utilisateurs disposant d’un accès de type Lecteur (Viewer) ou aux utilisateurs qui consomment les rapports via une application Power BI (App).
Cette distinction est souvent source de confusion lors des tests.
Bonnes pratiques
Pour mettre en place un RLS robuste, il est recommandé de :
- utiliser des groupes Microsoft Entra ID plutôt que d’affecter individuellement les utilisateurs ;
- maintenir une table dédiée à la gestion des droits d’accès ;
- concevoir un modèle en étoile afin de faciliter la propagation des filtres ;
- tester systématiquement les rôles avec Voir comme avant toute mise en production ;
- documenter clairement les règles de sécurité mises en place.
Conclusion
Le Row-Level Security est une fonctionnalité incontournable de Microsoft Power BI pour sécuriser le partage des rapports.
Grâce à un mécanisme de filtrage directement intégré au modèle sémantique, il permet de diffuser un même rapport à un grand nombre d’utilisateurs tout en garantissant que chacun ne visualise que les données auxquelles il est autorisé à accéder.
Bien implémenté, le RLS améliore la gouvernance des données, simplifie la maintenance des rapports et renforce la sécurité globale de votre plateforme décisionnelle.