Support formation Rapports Power BI

Sécurité RLS et OLS

Définir des rôles de sécurité au niveau des lignes avec l'éditeur de rôles ; affecter des utilisateurs ou des groupes dans le service ; gérer des droits multiples avec une table de correspondance ; masquer des tables ou des colonnes avec l'OLS.

Modélisation 4 - Sécurité au niveau des lignes (RLS)
Slide 11Slide 22Slide 33Slide 44Slide 55Slide 66Slide 77Slide 88Slide 99Slide 1010

Pourquoi ?

Un même rapport doit souvent montrer des données différentes selon la personne : le commercial de la région Nord ne voit que la région Nord. Plutôt que de multiplier les rapports, on définit des règles dans le modèle sémantique. Elles s'appliquent à tous les rapports, à l'analyse dans Excel et aux tableaux de bord connectés à ce modèle.

Notions clés

Ce que Power BI sait sécuriser

NiveauFonctionnalité native ?Mise en œuvre
Lignes (RLS)OuiRôles avec un filtre DAX sur une ou plusieurs tables
Objets (OLS)OuiRôles qui masquent des tables ou des colonnes, définis dans la vue TMDL ou avec Tabular Editor
PagesNonContournement par navigation, ou un rapport par public dans une application avec des audiences
VisuelsNonPas de sécurité ; les signets (partie 4) ne servent qu'à adapter l'affichage

Les règles à connaître

  • La RLS et l'OLS ne s'appliquent qu'aux personnes qui ont le rôle Lecteur dans l'espace de travail, ou qui accèdent au contenu par une application ou un partage. Les Administrateurs, Membres et Contributeurs voient toutes les données. Source
  • Affectez les rôles à des groupes de sécurité Microsoft Entra, des groupes de distribution ou des groupes à extension messagerie plutôt qu'à des personnes. Les groupes Microsoft 365 ne sont pas pris en charge.
  • La fonction USERPRINCIPALNAME() renvoie l'identifiant de connexion (UPN) de l'utilisateur, qui n'est pas toujours son adresse e-mail.
  • Un utilisateur présent dans aucun rôle ne voit aucune donnée.

Pas à pas

1 | Définir un rôle RLS dans Power BI Desktop

Dans l'exemple, chaque canal (Channel) est associé à un utilisateur ; le rapport ne doit afficher que les ventes (FactSales) de l'utilisateur connecté.

image.png
image.png

1. Onglet Modélisation > Gérer les rôles, puis Nouveau. Saisissez le nom du rôle (Canal filtré).

2. Sous Sélectionner des tables, choisissez la table à filtrer.

3. Sous Filtrer les données, l'éditeur par défaut permet de construire une règle statique sans DAX (colonne, opérateur, valeur), par exemple Région est égal à « Nord ».

[Capture : fenêtre Gérer les rôles, rôle Canal filtré sélectionné, éditeur par défaut avec une règle Région est égal à Nord]

4. Pour une règle dynamique, cliquez sur Basculer vers l'éditeur DAX et saisissez :

[Login] = USERPRINCIPALNAME ()

[Capture : fenêtre Gérer les rôles en éditeur DAX, expression [Login] = USERPRINCIPALNAME() saisie]

5. Cliquez sur Enregistrer, puis publiez le rapport dans un espace de travail.

2 | Affecter les membres dans le service

1. Dans l'espace de travail, survolez le modèle sémantique, cliquez sur Autres options (...) > Sécurité.

2. Sélectionnez le rôle, saisissez les utilisateurs ou les groupes, puis cliquez sur Ajouter et Enregistrer.

3. Vérifiez que ces personnes ont accès au rapport en tant que Lecteur (rôle d'espace de travail, application ou partage).

Sans titre.png
Sans titre.png

3 | Tester

  • Dans Power BI Desktop : Modélisation > Afficher en tant que, cochez le rôle et Autre utilisateur, puis saisissez un identifiant.
  • Dans le service : sur la page Sécurité, Plus d'options (...) à côté du rôle > Tester en tant que rôle. Ce test utilise votre propre identité pour USERPRINCIPALNAME() ; une carte affichant la mesure Utilisateur = USERPRINCIPALNAME () aide à vérifier la valeur renvoyée.

Exemple

Plusieurs périmètres par utilisateur (table de correspondance)

RLS - Table de correspondance
Slide 11Slide 22Slide 33Slide 44Slide 55Slide 66Slide 77Slide 88

En entreprise, un utilisateur voit souvent plusieurs canaux, et un canal est visible par plusieurs utilisateurs. On stocke alors les droits dans une table Droits, gérée par les métiers (fichier Excel, liste SharePoint, table SQL) :

LoginChannelKey
grady@contoso.comOnline
grady@contoso.comStore
alice@contoso.comStore
alice@contoso.comReseller

1. Reliez Droits[ChannelKey] à DimChannel[ChannelKey] en plusieurs-à-un. La relation DimChannel vers FactSales reste un-à-plusieurs, à sens unique.

2. Sur la relation Droits / DimChannel, réglez Direction du filtrage croisé sur Les deux et cochez Appliquer le filtre de sécurité dans les deux directions. Sans cette case, le filtre de sécurité ne remonte pas de Droits vers DimChannel. Elle ne peut être cochée que sur une seule relation bidirectionnelle par table.

3. Créez le rôle sur la table Droits avec le filtre [Login] = USERPRINCIPALNAME (), puis masquez la table.

Le filtrage bidirectionnel reste ainsi limité à une petite table masquée : c'est la démarche recommandée par Microsoft. Source

Variante sans relation bidirectionnelle : laissez Droits sans relation et posez le filtre sur DimChannel.

DimChannel[ChannelKey]
    IN CALCULATETABLE (
        VALUES ( Droits[ChannelKey] ),
        Droits[Login] = USERPRINCIPALNAME ()
    )

Pour la direction, créez un second rôle sans règle, qui donne accès à toutes les lignes, et affectez-y le groupe de sécurité concerné.

Masquer des objets avec l'OLS

L'OLS masque une table ou une colonne entière : pour les membres du rôle, l'objet n'existe pas, et un visuel qui l'utilise affiche une erreur de champ introuvable. Aucune capacité particulière n'est requise. Dans la vue TMDL, appliquez ce script (puis Aperçu et Appliquer) :

createOrReplace

    role 'Sans salaires'
        modelPermission: read

        tablePermission Employés
            columnPermission Salaire
                metadataPermission: none

Pour masquer toute la table, placez metadataPermission: none directement sous tablePermission. Affectez ensuite les membres du rôle dans le service, comme pour la RLS. Source

Restreindre l'accès à des pages

Power BI ne propose pas de sécurité au niveau des pages. Un contournement répandu combine une table de droits filtrée par la RLS (UtilisateurEmail, PageAutorisée), des pages masquées, une page « Accès refusé » et des boutons dont la destination est donnée par une mesure :

Nav synthèse ventes =
IF (
    "SyntheseVentes" IN VALUES ( 'Table sécurité'[PageAutorisée] ),
    "Synthèse des ventes régionales",
    "Accès refusé"
)

Ce n'est pas une sécurité : une personne qui obtient l'adresse d'une page masquée peut l'ouvrir. Pour un vrai cloisonnement, publiez un rapport par public, connecté au même modèle sémantique, et regroupez-les dans une application avec des audiences (partie 5). Protégez les données sensibles avec la RLS et l'OLS.

Pièges et bonnes pratiques

  • Dans l'éditeur DAX des rôles, séparez les arguments par des virgules, même avec des paramètres régionaux français.
  • Le filtre de sécurité bidirectionnel peut ralentir les gros modèles : gardez la table de droits compacte et mesurez avec l'analyseur de performances.
  • Dans un visuel par utilisateur, les ventes d'un canal partagé comptent pour chacun : le total n'est pas la somme des lignes.
  • Prévoyez l'ajout des nouveaux arrivants dans la table de droits ou dans les groupes.

À retenir

  • La RLS filtre les lignes, l'OLS masque les tables et les colonnes ; les deux se définissent dans des rôles du modèle.
  • L'éditeur par défaut suffit pour une règle statique ; USERPRINCIPALNAME() exige l'éditeur DAX.
  • Les rôles s'affectent dans le service, de préférence à des groupes Microsoft Entra, et ne s'appliquent qu'aux lecteurs.
  • Masquer une page ou un visuel ne sécurise pas les données.

Pour aller plus loin

  • Sécurité au niveau des lignes (RLS) avec Power BI. Source (Microsoft Learn)
  • Aide sur la sécurité au niveau des lignes dans Power BI Desktop. Source (Microsoft Learn)
  • Sécurité au niveau des objets (OLS). Source (Microsoft Learn)
  • Planifier la sécurité des consommateurs de rapports. Source (Microsoft Learn)