Sécurité au niveau des lignes (RLS) de Power BI : Un tutoriel complet

Sécurité au niveau des lignes (RLS) dans Power BI vous permet de contrôler les lignes de données que les utilisateurs peuvent afficher en fonction de filtres. Cette fonctionnalité est particulièrement utile dans les cas où plusieurs utilisateurs doivent accéder à un rapport partagé, mais avec des vues personnalisées en fonction de leurs rôles ou de leurs services.

Dans ce tutoriel, je vous guiderai à travers une compréhension pratique et approfondie du RLS, y compris ses configurations statiques et dynamiques, les étapes de mise en œuvre pratique, les techniques avancées pour les entreprises et les pièges courants que j'ai appris à éviter. Je partagerai également les meilleures pratiques et comparerai le RLS à d'autres modèles de sécurité.

Si vous débutez avec Power BI, je vous recommande de consulter notre cursus Power BI Fundamentals, qui vous aidera à maîtriser toutes les compétences essentielles dont vous aurez besoin.

Qu'est-ce que la sécurité au niveau des lignes ?

La sécurité au niveau des lignes (RLS) est une fonctionnalité de sécurité de Power BI qui restreint l'accès aux lignes d'un tableau en fonction de l'identité de l'utilisateur qui consulte le rapport. Plutôt que de dupliquer les rapports pour différents groupes d'utilisateurs, RLS vous permet d'appliquer des filtres au niveau des données afin que chaque utilisateur ne voie que les données qu'il est autorisé à consulter.

Ceci est essentiel pour préserver la confidentialité et l'intégrité des données, en particulier dans les cas impliquant des informations sensibles ou exclusives. RLS opère dans le cadre du modèle de données Power BI et garantit que les utilisateurs non autorisés ne peuvent pas accéder aux données restreintes, même par des méthodes indirectes telles que les segments ou les explorations.

Rôles et filtres

La mise en œuvre du RLS repose sur trois éléments fondamentaux :

• Rôles: Regroupements logiques avec des règles d'accès définies.
• DAX filtres: Expressions qui déterminent les données auxquelles chaque rôle peut accéder.
• Attributions des utilisateurs: Configuration des utilisateurs ou groupes appartenant à chaque rôle.

Ces éléments fonctionnent conjointement pour évaluer chaque requête par rapport aux conditions d'accès avant de renvoyer les résultats.

Cas d'utilisation

Le RLS est largement applicable dans de nombreux secteurs et scénarios, notamment :

• s commerciales: Les responsables commerciaux ne voient que les données de performance de leur région.
• s sur les soins de santé: Les médecins ont accès uniquement aux dossiers des patients qui leur sont attribués.
• SaaS multi-locataires: Les clients ne voient que les données de leur propre organisation dans les tableaux de bord partagés.

Ce modèle de sécurité permet de garantir la sécurité des ensembles de données partagés tout en minimisant les doublons et les tâches administratives.

Architectures RLS statiques et dynamiques

La sécurité au niveau des lignes peut être divisée en deux types : statique et dynamique.

J'ai résumé leurs différences dans le tableau ci-dessous :

Conseil : Utilisez le RLS statique pour les petits groupes d'utilisateurs fixes. Utilisez le RLS dynamique pour les environnements en pleine croissance ou à grande échelle.

Je vais vous présenter ci-dessous quelques implémentations d'exemples statiques et dynamiques.

Mise en œuvre statique du RLS

Le RLS statique implique la création de rôles avec des filtres DAX codés en dur. Chaque rôle correspond à un groupe ou un segment spécifique, tel qu'une région géographique ou un service.

Voici les étapes générales pour mettre en œuvre un RLS statique :

1. Créez un rôle nommé, par exemple, « Région_Est ».
2. Appliquez un filtre tel que « [Region] = "East" » à ce rôle.
3. Veuillez attribuer des utilisateurs spécifiques au rôle dans le service Power BI.

Mise en œuvre dynamique du RLS

Le RLS dynamique utilise des fonctions telles que USERNAME() ou USERPRINCIPALNAME() combinées à des tableaux de mappage pour filtrer dynamiquement les données en fonction de l'identité de l'utilisateur.

Voici les étapes générales pour mettre en œuvre un RLS dynamique :

1. Créez un tableau de correspondance reliant les utilisateurs aux niveaux d'accès. Ceci sera votre tableau de sécurité. Ce tableau doit inclure des colonnes telles que les adresses e-mail des utilisateurs, leurs régions d'accès et leurs noms.
2. Écrivez un filtre DAX tel que : [Region] = RELATED(UserRegion[Region])
3. Filtrez ce tableau avec : UserRegion[Email] = USERPRINCIPALNAME()

Configuration de la sécurité au niveau des lignes dans Power BI Desktop

Nous allons maintenant examiner un guide rapide sur la manière de configurer la sécurité statique au niveau des lignes à l'aide d'un ensemble de données de vente simple.

1. Création d'un exemple de jeu de données à l'aide de Python

Pour tester RLS, veuillez créer un exemple de jeu de données à l'aide de Python :

import pandas as pd

data = {
    'Salesperson': ['Alice', 'Bob', 'Charlie', 'Alice', 'Bob', 'Charlie'],
    'Region': ['East', 'West', 'South', 'East', 'West', 'South'],
    'SalesAmount': [15000, 20000, 18000, 17000, 21000, 16000],
    'Email': ['alice@company.com', 'bob@company.com', 'charlie@company.com'] * 2,
    'Date': pd.date_range(start='2025-01-01', periods=6, freq='M')
}

sales_df = pd.DataFrame(data)
sales_df.to_csv('sample_sales_data.csv', index=False)

2. Importation dans Power BI et création d'une visualisation de référence

1. Veuillez ouvrir Power BI Desktop.
2. Accédez à Accueil > Obtenir des données > Texte/CSV.
3. Veuillez sélectionner le fichier « sample_sales_data.csv ».

4. Chargez les données dans le modèle.

Veuillez vous assurer que les types de données sont corrects et que la colonne « Email » correspond aux formats d'identité de connexion (généralement l'adresse e-mail).

5. Créez un graphique à colonnes empilées de base dans Power BI. Veuillez faire glisser le champ Date vers l'axe X et le champ SalesAmount vers l'axe Y.

Voici à quoi devrait ressembler votre tableau :

Pour en savoir plus sur l'utilisation de Power BI, veuillez consulter notre fiche pratiqueci-dessous.

3. Création de rôles

Ensuite, nous allons créer des rôles afin de définir quels rôles peuvent disposer de quelles autorisations.

1. Accédez à Modélisation > Gérer les rôles.

2. Cliquez sur Créer et nommez votre rôle, par exemple, SalesRegionStatic.
3. Veuillez sélectionner le tableau pertinent.
4. Veuillez saisir une expression DAX de filtre :

[Email] = “charlie@company.com”

Voici à quoi devrait ressembler votre interface :

5. Enregistrez et fermez la boîte de dialogue.

Si les modifications sont enregistrées avec succès, une barre verte s'affiche comme illustré ci-dessous.

4. Rôles de test

1. Accéder à Modélisation > Afficher en tant que rôles.

2. Sélectionnez le rôle SalesRegionStatic que nous avons créé précédemment.

3. Affichez les visuels du rapport filtrés par cette identité.

Comme vous pouvez le constater sur l'image ci-dessous, le graphique a été filtré pour n'afficher que les données où l'adresse e-mail est « charlie@company.com ».

Cela permet une validation locale avant le déploiement.

Attribution d'utilisateurs et gestion des rôles dans le service Power BI

Une fois vos rôles RLS configurés et testés dans Power BI Desktop, l'étape suivante consiste à publier le rapport dans le service Power BI. Cela vous permet d'attribuer des utilisateurs ou des groupes de sécurité spécifiques à chaque rôle, garantissant ainsi que le contrôle d'accès est appliqué lorsque le rapport est partagé.

1. Publication du rapport dans le service Power BI

1. Dans Power BI Desktop, veuillez cliquer sur Accueil > Publier > Vers Power BI.
2. Sélectionnez l'espace de travail cible dans votre service Power BI.

3. Après la publication, connectez-vous au service Power BI à l'adresse https://app.powerbi.com.

Voici à quoi ressemble le mien sur le service Power BI sur le Web.

La publication est une condition préalable à la configuration des attributions de rôles RLS, car les rôles définis dans Power BI Desktop sont transférés avec l'ensemble de données.

2. Accéder aux paramètres de sécurité

1. Sélectionnez le menu Plus d'options pour votre modèle sémantique pertinent.Cliquez sur les points de suspension (...) à côté de l'ensemble de données et sélectionnez Sécurité.
2. Vous verrez une liste des rôles définis dans Power BI Desktop.

C'est ici que vous affectez des utilisateurs ou des groupes Azure Active Directory (AAD) à chaque rôle.

3. Attribution d'utilisateurs individuels et de groupes de sécurité

Pour attribuer des utilisateurs, veuillez saisir leur adresse e-mail complète dans la zone de texte sous le rôle souhaité, appuyez sur Entrée, puis cliquez sur Ajouter.

Pour attribuer des groupes AAD, veuillez utiliser le nom du groupe (par exemple, Sales_Region_East ou Finance_Team). Veuillez vous assurer que le groupe est déjà défini et géré dans Azure Active Directory.

4. Vérification de l'accès attribué

Après avoir attribué des utilisateurs ou des groupes, veuillez prendre le temps de vérifier que les données correctes sont présentées au bon groupe.

Chaque personne ne verra que les données filtrées par l'expression DAX associée à son rôle. Ils ne seront pas informés directement de l'attribution de leur rôle. Il est donc recommandé de leur communiquer les instructions d'accès une fois la vérification effectuée.

5. Tester les attributions de rôles dans le service Power BI

1. Sur la même page, cliquez sur le nom de votre RLS que vous avez défini précédemment, puis sur les points de suspension (...), et enfin sur Tester en tant que rôle.

2. Power BI ouvrira une version en lecture seule du rapport, affichant uniquement les données autorisées par le rôle sélectionné.

Pour le RLS dynamique, vous pouvez également simuler ce qu'un utilisateur spécifique verra :

• Cliquez sur Tester en tant que rôle.
• Veuillez saisir l'adresse e-mail d'un utilisateur afin de simuler son expérience.

Ceci est utile pour vous assurer que vos filtres dynamiques (par exemple, basés sur l'USERPRINCIPALNAME()) fonctionnent correctement.

Techniques de mise en œuvre avancées

RLS peut être intégré davantage à votre flux de travail Power BI grâce à certaines techniques avancées. Voici quelques points à retenir :

1. Intégration du groupe de sécurité

L'utilisation des groupes de sécurité Azure Active Directory (AAD) vous permet d'attribuer des autorisations d'accès à des groupes entiers plutôt qu'à des utilisateurs individuels. 

Cette pratique est particulièrement utile dans les entreprises où les employés rejoignent ou quittent fréquemment des équipes, car elle élimine le besoin de mettre à jour manuellement les autorisations d'accès dans Power BI.

2. Considérations relatives aux modèles de données complexes

Lors de la création de modèles de données à grande échelle, veuillez vous assurer que la RLS n'interfère pas avec les relations et la propagation des filtres. 

Voici quelques conseils :

• Utilisez une structure en étoile pour éviter les jointures complexes.
• Limitez l'utilisation des relations bidirectionnelles, sauf si cela est nécessaire.
• Évitez les relations ambiguës qui pourraient entraîner un filtrage incorrect.
• Optimisez les performances en réduisant au minimum les colonnes calculées dans les tableaux fortement filtrés.

3. Approches hybrides

Une approche hybride de la RLS consiste à combiner des techniques statiques et dynamiques. 

Par exemple, vous pouvez définir un rôle statique pour accorder l'accès à une unité commerciale spécifique et appliquer un filtrage dynamique au sein de ce rôle en fonction des adresses e-mail ou des noms d'utilisateur individuels. Cette méthode permet une logique de sécurité multicouche et flexible.

4. Sécurité au niveau des objets (OLS)

La sécurité au niveau des objets vous permet de masquer des tableaux ou des colonnes entiers à certains rôles. Il complète le RLS en ajoutant un niveau supplémentaire de protection des données. La méthode OLS peut être utilisée pour des domaines sensibles tels que les informations salariales ou médicales.

Stratégies de test et de validation

1. Test sur ordinateur de bureau

Power BI Desktop offre un moyen pratique de simuler différentes vues utilisateur grâce à la fonctionnalité de rôle « Afficher en tant que ». Cette fonctionnalité aide les développeurs de rapports à vérifier que la logique de sécurité au niveau des lignes fonctionne correctement avant de publier le rapport.

Comment tester RLS dans Power BI Desktop :

1. Cliquez sur le bouton « Modeler » à côté de la zone de modèle. Modélisation .
2. Sélectionner Afficher sous dans le ruban.
3. Sélectionnez les rôles que vous avez configurés (par exemple, SalesRegionStatic).
4. Si vous utilisez le RLS dynamique, veuillez saisir un nom d'utilisateur/une adresse e-mail de test.
5. Cliquez sur OK et examinez comment les éléments visuels sont filtrés.

Cela simule le rapport tel qu'il serait affiché par un utilisateur affecté à ce rôle. Cela est particulièrement utile lors du test de filtres RLS dynamiques qui dépendent de fonctions DAX telles que USERPRINCIPALNAME().

2. Test des services

Une fois publié dans le service Power BI, le RLS doit être testé à nouveau dans l'environnement cloud afin de garantir son exactitude.

Comment tester RLS dans le service Power BI :

1. Accédez à l'ensemble de données dans votre espace de travail.
2. Veuillez cliquer sur le bouton « Enregistrer » situé en ... à côté de l'ensemble de données, puis sur Sécurité.
3. Sélectionnez un rôle, puis cliquez sur « Tester ». Tester en tant que rôle.
4. Veuillez utiliser l'option « Tester en tant qu'utilisateur spécifique » pour simuler des filtres RLS dynamiques.

Cela garantit que les filtres se comportent comme prévu pour les utilisateurs réels.

3. Conseils importants pour la validation

À des fins de validation, vous pouvez envisager d'utiliser des comptes de test ou des identités de service pour simuler une utilisation réelle. Tous les filtres sur les éléments visuels clés, tels que les tableaux et les graphiques, doivent également être revus périodiquement.

Veuillez également vérifier minutieusement les segments, les drillthrough et les signets afin de vous assurer qu'ils ne divulguent pas de données non autorisées.

Pièges courants et solutions

La mise en œuvre du RLS peut poser certains problèmes. Voici quelques-uns des plus courants et la manière de les résoudre.

1. Problèmes postérieurs à la publication

Après la publication dans le service Power BI, certains utilisateurs constatent que RLS ne se comporte pas comme prévu, même s'il fonctionnait dans Power BI Desktop.

Solutions :

• Veuillez vous assurer que le rapport est republié après avoir modifié les rôles ou les filtres.
• Veuillez vérifier que l'adresse e-mail utilisée dans USERPRINCIPALNAME() correspond au format du domaine de connexion dans l'ensemble de données.

2. Conflits de rôles dans l'espace de travail

Les utilisateurs disposant de certains rôles dans l'espace de travail (administrateur, membre) peuvent contourner le RLS par inadvertance.

Solutions :

• Attribuez des rôles aux utilisateurs en tant que Observateurs dans l'espace de travail pour appliquer les règles RLS.
• Évitez d'accorder des droits de contributeur/administrateur, sauf si cela est nécessaire pour le développement du contenu.

3. Limitations de la fonction DAX

Les erreurs courantes proviennent d'une mauvaise utilisation des fonctions DAX telles que « USERNAME() » et « USERPRINCIPALNAME() » :

• USERNAME() peut renvoyer un nom de compte local au lieu d'une adresse e-mail lors d'un test sur un ordinateur de bureau.
• Veuillez utiliser USERPRINCIPALNAME() pour garantir la cohérence avec le comportement de l'identité cloud.

Conseils :

• Veuillez ajouter un tableau de référence contenant des exemples d'e-mails afin de faciliter les tests locaux.
• Utilisez la logique conditionnelle ou les valeurs par défaut dans DAX pour éviter les échecs de filtrage.

4. DirectQuery et les défis liés à l'authentification unique (SSO)

La fonctionnalité RLS dynamique avec des sources DirectQuery nécessite une attention particulière, en particulier lorsqu'elle est utilisée avec l'authentification unique (SSO).

Problèmes courants :

• Une configuration incorrecte de la passerelle peut empêcher l'usurpation d'identité des utilisateurs.
• La configuration SSO avec Kerberos peut échouer si les SPN sont mal configurés.

Solutions :

• Veuillez consulter la documentation Microsoft sur l'authentification unique avec les passerelles Power BI.
• Collaborez étroitement avec les équipes informatiques et d'infrastructure pour permettre la délégation Kerberos.

Suppression ou désactivation de RLS pour l'accès public

Il peut arriver que la fonctionnalité RLS doive être désactivée temporairement (par exemple, pour des démonstrations ou des tableaux de bord ouverts) ou de manière permanente (par exemple, lors du partage de données avec des parties prenantes externes). Dans ce cas, vous devrez faire attention aux paramètres de visibilité afin d'éviter toute fuite inattendue.

Désactivation de RLS dans Power BI Desktop

Pour désactiver RLS :

1. Veuillez ouvrir votre rapport dans Power BI Desktop.
2. Accédez à Modélisation > Gérer les rôles.
3. Veuillez sélectionner et supprimer tous les rôles ou désactiver leurs filtres.
4. Enregistrez et republiez l'ensemble de données dans le service Power BI.

Une fois supprimées, tous les utilisateurs pourront accéder à l'ensemble des données, à moins que d'autres mesures de sécurité ne soient mises en place.

Partage sécurisé sans RLS

Si le RLS n'est pas possible ou nécessaire, envisagez les pratiques suivantes pour garantir la sécurité des données :

• Utilisez les autorisations au niveau de l'ensemble de données : Veuillez partager le jeu de données ou le rapport uniquement avec des utilisateurs de confiance et utiliser les autorisations de l'espace de travail (Observateur, Contributeur) de manière appropriée.
• Veuillez éviter de publier sur le Web : L'option « Publier sur le Web » supprime tous les contrôles de sécurité. Veuillez utiliser « Intégrer pour l'organisation » ou Power BI Embedded pour un partage public sécurisé.

La suppression de RLS ne signifie pas la suppression de toute sécurité. Veuillez utiliser d'autres couches de contrôle d'accès et fonctionnalités de partage dans le service Power BI afin de garantir une diffusion responsable des données.

Meilleures pratiques pour le déploiement en entreprise

Le déploiement réussi de la sécurité au niveau des lignes à l'échelle de l'entreprise nécessite une planification minutieuse, une architecture évolutive et une gouvernance adéquate. Cette section présente les meilleures pratiques éprouvées dans différents domaines de la mise en œuvre du RLS.

1. Modélisation des données

Un modèle de données bien conçu facilite la mise en place de configurations RLS efficaces et faciles à gérer.

Recommandations :

• Suivez un schéma en étoile avec des relations claires entre les tableaux de faits et de dimensions.
• Évitez les relations bidirectionnelles inutiles qui pourraient introduire une ambiguïté dans le filtrage.

2. Gestion des rôles

La gestion centralisée et cohérente des rôles RLS contribue à réduire les erreurs et à améliorer la collaboration.

Recommandations :

• Maintenez un document de définition des rôles afin de suivre la logique RLS et les expressions DAX.
• Utilisez des noms de rôle descriptifs (par exemple, « Ventes_Région_Est ») afin d'éviter toute confusion.

3. Optimisation des performances

Le RLS peut avoir un impact sur les performances des rapports, en particulier lorsque des filtres complexes ou des ensembles de données volumineux sont impliqués.

Recommandations :

• Dans la mesure du possible, préagréger les données à l'aide de tableaux récapitulatifs.
• Réduisez au minimum l'utilisation des colonnes calculées dans la logique RLS.
• Utilisez l'indexation et les requêtes optimisées dans les systèmes sources pour prendre en charge les scénarios DirectQuery.

RLS et autres modèles de sécurité

Comparons maintenant les différences entre la sécurité au niveau des lignes (RLS) et d'autres fonctionnalités de sécurité, en particulier la sécurité au niveau des objets (OLS).

1. Granularité et cas d'utilisation

RLS permet de contrôler l'accès à des lignes de données individuelles, ce qui est idéal pour filtrer les données par identité utilisateur, zone géographique, service ou unité commerciale. OLS, quant à lui, contrôle l'accès à des tableaux ou à des colonnes entiers, ce qui est utile pour masquer des informations financières ou RH sensibles (par exemple, la colonne des salaires). 

2. Mise en œuvre et adaptation dynamique

La fonctionnalité RLS peut être facilement mise en œuvre dans Power BI Desktop via des filtres DAX sur les rôles. Ces règles peuvent être statiques (filtres codés en dur) ou dynamiques (logique pilotée par l'utilisateur). OLS est configuré via l'éditeur tabulaire ou le point de terminaison XMLA. Il nécessite également un espace de travail Premium ou un ensemble de données Power BI hébergé dans Analysis Services.

J'ai rédigé un résumé comparatif dans le tableau ci-dessous :

Conclusion

En résumé, la sécurité au niveau des lignes (RLS) dans Power BI est une méthode essentielle pour garantir la gouvernance des données au sein de la plateforme. Il permet aux organisations de fournir des expériences analytiques personnalisées et sécurisées dans un seul rapport ou tableau de bord, sans compromettre la confidentialité ou l'intégrité des données sous-jacentes.

La sécurité est un facteur de plus en plus important dans la gestion et la gouvernance des données, ce qui constitue un aspect essentiel du travail avec Power BI. Pour plus d'informations sur Power BI, veuillez consulter notre Déployer et gérer des actifs dans Power BI ou notre cours Rapports dans Power BI. Pour plus d'informations, veuillez consulter nos guides sur les Hiérarchies Power BI et Tableaux de bord Power BI pourraient vous être utiles.