4.2 · Sécurité au niveau des lignes (RLS)

Niveau 4 · Expert : design, sécurité & performance

4.2Sécurité au niveau des lignes (RLS)

Objectif : définir des rôles et des filtres RLS pour que chaque utilisateur ne voie que ses données.
Temps estimé : 20 min

Un même rapport, des lectures différentes : le commercial de Lyon ne voit que Lyon, la directrice voit tout. C'est la sécurité au niveau des lignes (RLS) : des rôles définis dans Desktop avec des filtres DAX (ex. Ventes[Ville] = "Lyon"), testés par « Afficher comme », puis assignés aux utilisateurs dans le Service. La version dynamique — un seul rôle qui filtre selon l'identité connectée via USERPRINCIPALNAME() — industrialise le tout.

Vous créerez des rôles statiques, les testerez, puis monterez la RLS dynamique avec sa table de correspondance utilisateur → périmètre : le standard des déploiements sérieux.

Vocabulaire de la section

RLS (Row-Level Security)
Filtrer les LIGNES visibles selon l'utilisateur connecté : un rapport, des périmètres de données différents.
Rôle
Un jeu de filtres DAX nommé (Modélisation → Gérer les rôles) : « Commercial Lyon » = Ventes[Ville]="Lyon".
Afficher comme
Le test dans Desktop (Modélisation → Afficher comme) : voir le rapport avec les yeux d'un rôle avant publication.
USERPRINCIPALNAME()
La fonction qui renvoie l'e-mail de l'utilisateur connecté : la clé de la RLS dynamique.
Table de sécurité
La table de correspondance e-mail → périmètre (ville, agence…) : un seul rôle dynamique la traverse pour filtrer.
Vérifiez votre compréhension

La RLS (sécurité au niveau des lignes) permet…

Sécurité au niveau des lignes (RLS)
Vidéo hébergée sur YouTube — ouvrir dans un nouvel onglet ↗
Tutos « 4.2 » Power BI sécurité niveau ligne RLS row level security (recherche)
Cliquer pour voir les résultats à jour ↗

En pratique — Du rôle statique à la RLS dynamique

  1. Modélisation → Gérer les rôles → Nouveau : « Lyon uniquement » avec le filtre DAX Ventes[Ville] = "Lyon" (sur la dimension Ville si vous en avez une — meilleur).
  2. Testez : Modélisation → Afficher comme → cochez le rôle : tout le rapport se restreint à Lyon. Quittez le mode test.
  3. Version dynamique : créez une table Sécurité (Email, Ville) avec 2-3 lignes, reliez-la à la dimension Ville, puis un rôle « Dynamique » avec le filtre : Securite[Email] = USERPRINCIPALNAME().
  4. Testez encore avec « Afficher comme » en spécifiant un e-mail de la table : le périmètre suit l'identité. (L'assignation réelle des utilisateurs se fait dans le Service — niveau 5.)
La RLS maîtrisée dans ses deux formes — la brique sécurité exigée de tout déploiement d'entreprise (et de la PL-300).

Points clés à retenir

  • La RLS filtre les données par utilisateur : un rapport unique, des visions multiples.
  • Filtrez les DIMENSIONS (le filtre se propage aux faits par la relation) plutôt que les faits directement.
  • « Afficher comme » avant toute publication : la RLS se teste, toujours.
  • La RLS dynamique (USERPRINCIPALNAME + table de sécurité) évite un rôle par personne : le standard pro.

Questions fréquentes

La RLS s'applique-t-elle aussi à moi, l'auteur ?

Dans Desktop non (sauf en mode test) ; dans le Service, les administrateurs/membres de l'espace de travail ne sont PAS soumis à la RLS — elle joue pour les lecteurs. À savoir pour ne pas conclure trop vite qu'elle « ne marche pas ».

La RLS protège-t-elle contre l'export des données ?

Elle filtre tout ce que l'utilisateur voit ET exporte : l'export respecte le périmètre. Mais elle ne remplace pas les permissions d'accès au rapport lui-même (qui peut l'ouvrir) — les deux couches se complètent.

Autres ressources