"Sécurité au niveau des lignes (RLS) : gérer les habilitations dans Power BI"

« Le directeur général doit voir toutes les ventes, les directeurs régionaux uniquement leur région, les commerciaux terrain uniquement leurs clients. » Ce besoin se traite avec la sécurité au niveau des lignes (RLS) de Power BI. Bien conçue, elle permet de gérer des dizaines de niveaux d'habilitation avec un seul rapport et un seul jeu de données ; mal conçue, elle ouvre une faille de sécurité et dégrade les performances. Cet article détaille la RLS statique et dynamique, l'usage de USERPRINCIPALNAME et les pratiques de terrain.

01. Qu'est-ce que la RLS et que résout-elle ?

La sécurité au niveau des lignes applique des filtres au modèle de données pour qu'un même rapport présente à chaque utilisateur un ensemble de lignes différent. Plutôt que de dupliquer dix rapports, on en construit un seul et on sépare rôles et filtres.

La RLS opère sur deux couches :

• La couche modèle : les lignes visibles par chaque rôle sont définies par des filtres DAX
• La couche service : l'affectation des utilisateurs aux rôles se gère dans Power BI Service

Si ces deux couches ne sont pas correctement reliées, l'utilisateur ne voit aucune donnée, ou accède à des données non autorisées.

02. La RLS statique : simple mais non extensible

En RLS statique, un filtre DAX est écrit à la main pour chaque rôle. Par exemple :

• Pour le rôle « Marmara » : [Région] = "Marmara"
• Pour le rôle « Égée » : [Région] = "Égée"
• Pour le rôle « Distributeur Istanbul » : [Région] = "Marmara" && [Ville] = "Istanbul"

Cette approche fonctionne avec peu de rôles (deux à cinq), mais devient ingérable au-delà de vingt. Chaque nouvelle région impose de modifier le modèle et de le republier.

03. La RLS dynamique : l'approche extensible

En RLS dynamique, on définit un rôle unique et le filtre s'adapte à l'utilisateur connecté. La fonction USERPRINCIPALNAME() renvoie l'adresse e-mail de la session. Cette valeur est mise en correspondance avec une table de sécurité :

• Table Utilisateurs : [E-mail], [Nom], [Région], [Code distributeur], [Rôle]
• Filtre DAX sur la dimension Région : [Région] IN CALCULATETABLE(VALUES(Utilisateurs[Région]), Utilisateurs[E-mail] = USERPRINCIPALNAME())

À l'ajout d'un utilisateur, vous ne touchez plus au modèle : vous ajoutez simplement une ligne dans la table Utilisateurs.

04. Concevoir la table de sécurité

Le cœur de la RLS dynamique est la table de sécurité. Bien conçue, elle :

• exprime clairement la relation utilisateur-accès (un utilisateur peut accéder à plusieurs régions) ;
• peut être reliée aux tables de dimensions principales ;
• se met à jour facilement (source Excel, SharePoint ou SQL) ;
• prend en charge la hiérarchie des rôles (directeur général = toutes les régions).

Pour le rôle de directeur général, la pratique courante consiste à placer un « * » ou à laisser le champ de filtre vide, la logique « si * alors tout est visible » étant traitée en DAX.

05. Le processus de test et de validation

Après avoir appliqué la RLS, il est dangereux de se dire « c'est publié, ça doit marcher ». Les étapes de test :

• Prévisualiser chaque rôle avec la fonction « Afficher en tant que rôle » dans Power BI Desktop
• Tester en conditions réelles dans le Service, en se connectant avec différents comptes
• Vérifier que le total du rapport change bien selon l'utilisateur
• Vérifier qu'un filtre appliqué à une dimension non autorisée renvoie zéro ligne
• Mesurer l'impact sur les performances (une requête avec RLS peut être 10 à 30 % plus lente)

06. La différence avec la sécurité au niveau des objets

La RLS masque des lignes, mais toutes les colonnes restent visibles. Certains scénarios exigent de masquer une colonne : par exemple, réserver aux RH la colonne des salaires dans une table de paie. C'est le rôle de la sécurité au niveau des objets (OLS).

L'OLS se définit avec un outil externe comme Tabular Editor ; Power BI Desktop n'en propose pas encore l'interface. Dans les scénarios d'entreprise, RLS et OLS s'utilisent ensemble : habilitation par ligne et masquage des colonnes sensibles par rôle.

07. Les pièges courants

Les erreurs fréquentes dans la mise en œuvre de la RLS :

• Le résultat de USERPRINCIPALNAME ne correspond pas exactement à l'e-mail de la table Utilisateurs (casse, espaces)
• Relier la table de sécurité par une relation bidirectionnelle : les performances s'effondrent
• Publier sans avoir testé la RLS sur un modèle composite (mélange DirectQuery et importation)
• Oublier l'export Excel : les données exportées depuis le rapport respectent le filtre RLS, mais un accès direct à la base par l'équipe technique le contourne
• Ne pas redéfinir la RLS après publication dans le Service pour les rapports fondés sur un modèle