Sécurité au niveau des lignes dans Power BI : accès aux données multi-locataires

La sécurité au niveau des lignes (RLS) est le mécanisme qui garantit que chaque utilisateur ne voit que les données auxquelles il est autorisé à accéder. Dans un environnement multi-locataires ou multi-départements, RLS n'est pas facultatif : c'est la différence entre une plateforme d'analyse gouvernée et une violation de données imminente. Pourtant, la télémétrie d'utilisation de Microsoft suggère que moins de 30 % des organisations disposant de Power BI Premium ont implémenté RLS sur leurs ensembles de données de production.

La raison n’est pas que le RLS soit conceptuellement difficile. La raison en est que les détails d'implémentation sont nuancés, le processus de test est manuel et l'interaction entre RLS et d'autres fonctionnalités de Power BI (DirectQuery, modèles composites, intégration, agrégations) crée des cas extrêmes qui prennent les équipes au dépourvu. Ce guide couvre tous les aspects de la mise en œuvre de RLS, du rôle statique le plus simple à la sécurité dynamique complexe avec l'intégration d'Azure Active Directory.

---

Points clés à retenir

• La sécurité au niveau des lignes dans Power BI filtre les données au niveau du modèle à l'aide d'expressions DAX, garantissant ainsi que les utilisateurs ne peuvent pas contourner la sécurité en modifiant des rapports ou des visuels.
• Les codes durs RLS statiques filtrent les valeurs (adaptées aux petits groupes d'utilisateurs stables), tandis que le RLS dynamique utilise des fonctions DAX telles que USERNAME() et USERPRINCIPALNAME() pour filtrer dynamiquement en fonction de l'utilisateur connecté.
• RLS ne fonctionne qu'en modes Importation et DirectQuery --- il ne s'applique pas aux connexions en direct à Analysis Services (qui ont leur propre RLS)
• La sécurité au niveau de l'objet (OLS) masque des tables ou des colonnes entières, complétant RLS pour les scénarios dans lesquels les utilisateurs ne devraient même pas savoir que certaines données existent
• Le test de RLS nécessite la fonctionnalité « Afficher en tant que » dans Power BI Desktop et Service --- ne présumez jamais que RLS fonctionne sans tests explicites pour chaque rôle
• RLS dans les scénarios intégrés (Power BI Embedded) nécessite de transmettre l'identité effective dans le jeton intégré, ce qui est une source courante d'erreurs d'implémentation.
• L'impact sur les performances de RLS est généralement inférieur à 5 % pour les modèles bien conçus, mais des filtres DAX mal écrits peuvent dégrader les performances de 50 % ou plus.

---

Comprendre la sécurité au niveau des lignes

Que fait RLS

RLS applique des expressions de filtre DAX à une ou plusieurs tables dans un modèle de données Power BI. Lorsqu'un utilisateur ouvre un rapport, Power BI évalue les règles RLS et filtre silencieusement les lignes que l'utilisateur n'est pas autorisé à voir. L'utilisateur reçoit un rapport normal : il ne peut tout simplement pas voir les données en dehors de son champ d'application.

Il est important de noter que RLS fonctionne au niveau de la couche de modèle de données, et non au niveau de la couche de rapport. Cela signifie :

• Les utilisateurs ne peuvent pas contourner RLS en créant leurs propres rapports sur le même ensemble de données
• Les filtres RLS se propagent à travers les relations (un filtre sur Dim_Region filtre automatiquement Fact_Sales à travers la relation)
• Les mesures DAX respectent le contexte RLS (CALCULATE, SUMX et d'autres fonctions fonctionnent sur le sous-ensemble filtré)
• L'exportation vers Excel, CSV ou PowerPoint exporte uniquement les données que l'utilisateur est autorisé à voir

RLS par rapport à d'autres mécanismes de sécurité

RLS est le seul mécanisme qui contrôle les lignes de données spécifiques auxquelles un utilisateur peut accéder. Les autres mécanismes contrôlent l'accès au niveau de l'espace de travail, du rapport ou de l'objet.

---

Sécurité statique au niveau des lignes

Le RLS statique attribue aux utilisateurs des rôles avec des valeurs de filtre codées en dur. Il s'agit de l'implémentation la plus simple et elle fonctionne bien pour les scénarios avec un petit nombre de régions, de départements ou d'unités commerciales fixes.

Création d'un rôle statique

Dans Power BI Bureau :

1. Accédez à Modélisation, puis Gérer les rôles
2. Cliquez sur Créer pour ajouter un nouveau rôle
3. Nommez le rôle (par exemple, « Ventes en Amérique du Nord »)
4. Sélectionnez la table à filtrer (par exemple, Dim_Region)
5. Écrivez l'expression du filtre DAX :

[Region] = "North America"

Cette expression signifie : lorsqu'un utilisateur se voit attribuer le rôle "Ventes en Amérique du Nord", chaque table liée à Dim_Region n'affichera que les lignes où la région est l'Amérique du Nord. Un utilisateur consultant un rapport de ventes ne verra que les ventes nord-américaines. Un utilisateur consultant un tableau de bord RH (s'il se connecte via une dimension régionale) ne verra que les employés nord-américains.

Rôles multiples

Vous pouvez créer plusieurs rôles avec différents filtres :

• Ventes EMEA : [Region] = "EMEA"
• Ventes APAC : [Region] = "APAC"
• Global Executive : aucun filtre (voit toutes les données)

Un utilisateur peut être affecté à plusieurs rôles. Lorsqu'ils sont attribués à plusieurs rôles, les filtres se combinent avec la logique OU : l'utilisateur voit l'union des données de tous les rôles. Par exemple, un utilisateur affecté à la fois aux « Ventes en Amérique du Nord » et aux « Ventes EMEA » voit les données des deux régions.

Limites du RLS statique

Le RLS statique devient ingérable lorsque :

• Vous avez plus de 10 à 15 valeurs de filtre distinctes (créer et maintenir plus de 15 rôles est fastidieux)
• Les affectations utilisateur-rôle changent fréquemment (chaque changement nécessite un administrateur Power BI)
• La logique de filtrage est plus complexe qu'une simple égalité (par exemple, les managers doivent voir les données de leur équipe plus les leurs)
• Vous avez des centaines d'utilisateurs répartis dans des dizaines d'unités commerciales

Pour ces scénarios, le RLS dynamique est la solution.

---

Sécurité dynamique au niveau des lignes

Dynamic RLS utilise des fonctions DAX qui évaluent au moment de l'exécution pour déterminer l'utilisateur connecté et appliquer les filtres appropriés. Les deux fonctions clés sont :

• USERNAME() — Renvoie le domaine\nom d'utilisateur ou UPN de l'utilisateur actuel
• USERPRINCIPALNAME() — Renvoie l'e-mail/UPN de l'utilisateur actuel (recommandé pour les déploiements cloud)

Configuration du RLS dynamique

Étape 1 : Créer une table de mappage de sécurité

Ce tableau mappe les utilisateurs à leur étendue de données autorisée. Il peut être stocké dans la source de données (base de données), une liste SharePoint ou un fichier Excel :

Importez cette table dans votre modèle Power BI sous le nom SecurityMapping.

Étape 2 : Créer le rôle RLS

Créez un rôle unique (par exemple, « DynamicSecurity ») avec un filtre DAX sur la table de mappage de sécurité :

[UserEmail] = USERPRINCIPALNAME()
    || [UserEmail] = "ALL"

Étape 3 : Créer des relations

Établissez des relations entre SecurityMapping et vos tables de dimensions :

• SecurityMapping[Région] vers Dim_Region[Région]
• SecurityMapping[Département] vers Dim_Department[Département]
• SecurityMapping[CompanyId] vers Dim_Company[CompanyId]

Ces relations doivent être un à plusieurs, de la dimension à la table de mappage de sécurité, ou vous pouvez utiliser un filtre croisé bidirectionnel. Cependant, les filtres bidirectionnels ont des implications en termes de performances : une meilleure approche utilise CROSSFILTER ou TREATAS dans l'expression DAX.

Étape 4 : Alternative sans relations (approche TREATAS)

Au lieu de créer des relations à partir de la table de mappage de sécurité, vous pouvez utiliser TREATAS dans l'expression RLS sur la table de faits directement :

VAR CurrentUser = USERPRINCIPALNAME()
VAR UserRegions =
    CALCULATETABLE(
        VALUES(SecurityMapping[Region]),
        SecurityMapping[UserEmail] = CurrentUser
            || SecurityMapping[UserEmail] = "ALL"
    )
RETURN
    [Region] IN UserRegions

Cette approche évite la complexité des relations supplémentaires et maintient la logique de sécurité autonome.

RLS dynamique avec hiérarchie des managers

Une exigence courante est que les responsables aient accès aux données de l’ensemble de leur chaîne hiérarchique. Cela nécessite une hiérarchie parent-enfant dans la table des employés ou des utilisateurs.

Approche 1 : fonction PATH

Si votre table utilisateur comporte une colonne ManagerId, utilisez la fonction PATH de DAX :

UserPath = PATH(Users[UserId], Users[ManagerId])

Puis dans l'expression RLS :

VAR CurrentUserId =
    LOOKUPVALUE(Users[UserId], Users[Email], USERPRINCIPALNAME())
RETURN
    PATHCONTAINS([UserPath], CurrentUserId)

Cette expression renvoie TRUE pour les propres données de l'utilisateur actuel et toutes les données appartenant à ses rapports directs et indirects.

Approche 2 : Tableau de sécurité aplati

Précalculez la hiérarchie dans votre processus ETL et créez un mappage de sécurité plat dans lequel chaque responsable est répertorié avec toutes les étendues de données de ses rapports. Ceci est plus performant au moment de la requête car cela évite la surcharge de l'évaluation PATH.

---

Sécurité au niveau de l'objet (OLS)

La sécurité au niveau des objets masque des tables ou des colonnes entières aux utilisateurs. Contrairement à RLS, qui filtre les lignes, OLS rend les tables ou les colonnes complètement invisibles : elles n'apparaissent pas dans la liste des champs, et tout référencement visuel à un champ masqué affiche une erreur.

Quand utiliser OLS

• Masquage des colonnes de salaire dans les ensembles de données RH pour les utilisateurs non RH
• Masquer les tableaux liés aux coûts aux équipes commerciales qui ne devraient voir que les revenus
• Cacher les informations personnelles des clients (e-mail, téléphone, adresse) aux analystes qui n'ont besoin que de données agrégées
• Masquer les colonnes de tarification stratégique aux utilisateurs généraux

Configuration d'OLS

OLS est configuré via l’éditeur tabulaire (un outil externe) ou les points de terminaison XMLA, et non via l’interface utilisateur de Power BI Desktop.

Dans l'éditeur tabulaire :

1. Ouvrez le modèle via le ruban des outils externes
2. Accédez à la table ou à la colonne que vous souhaitez restreindre
3. Dans le volet Propriétés, recherchez Autorisations de table ou Autorisations de colonne sous chaque rôle.
4. Définissez l'autorisation sur « Aucun » (la valeur par défaut est « Lecture »)

Par exemple, pour masquer la colonne Salaire de la table Employés du rôle « Ventes » :

• Rôle : Ventes
• Tableau : Employés
• Colonne : Salaire
• Autorisation : Aucune

Les utilisateurs affectés au rôle Ventes ne verront pas la colonne Salaire dans la liste des champs et ne pourront pas la référencer dans les calculs DAX.

Limites du système OLS

• OLS nécessite Power BI Premium ou Pro avec les points de terminaison XMLA activés
• OLS ne peut pas être configuré dans l'interface utilisateur native de Power BI Desktop
• OLS est uniquement au niveau des métadonnées --- il ne filtre pas les lignes
• Si une mesure fait référence à une colonne masquée, la mesure elle-même générera une erreur pour les utilisateurs restreints

---

## RLS avec DirectQuery

RLS fonctionne avec DirectQuery, mais son comportement est différent du mode Importation sur des points importants.

Comment ça marche

En mode DirectQuery, Power BI traduit le filtre RLS DAX en clause SQL WHERE et l'envoie à la source de données. La source de données effectue le filtrage et seules les lignes autorisées sont renvoyées.

Pass-Through d'authentification unique (SSO)

Lorsque vous utilisez DirectQuery avec SSO sur une base de données comme Azure SQL ou Azure Synapse, Power BI transmet l'identité de l'utilisateur à la base de données. Si la base de données dispose de sa propre sécurité au niveau des lignes (par exemple, CREATE SECURITY POLICY de SQL Server), cette sécurité s'applique en plus du RLS de Power BI.

Important : Si vous activez le relais SSO, le RLS de Power BI est contourné car la base de données gère la sécurité. Vous devez choisir l'un ou l'autre :

• Power BI RLS (défini dans DAX, géré dans Power BI)
• RLS au niveau de la base de données (défini en SQL, géré dans la base de données)
• Les deux (Power BI RLS ET la base de données RLS s'appliquent --- l'utilisateur voit l'intersection)

Considérations sur les performances

Les filtres RLS dans DirectQuery ajoutent des clauses WHERE à chaque requête. Si les colonnes de filtre ne sont pas indexées dans la base de données, les performances peuvent se dégrader considérablement. Assurez-vous que :

• Les colonnes de filtre RLS ont des index de base de données
• L'expression du filtre DAX est suffisamment simple pour être traduite en SQL efficace
• Vous testez les performances des requêtes avec le "Performance Analyzer" dans Power BI Desktop

---

RLS dans Power BI Embedded

Power BI Embedded (intégration de rapports dans des applications personnalisées) a des exigences RLS uniques, car les utilisateurs finaux peuvent ne pas disposer de comptes Power BI ou Azure AD.

Scénario de données appartenant à l'application

Dans le modèle d’intégration « L’application possède les données », un principal de service ou un compte principal s’authentifie auprès de Power BI et l’application transmet l’identité de l’utilisateur dans le jeton d’intégration.

Génération d'un jeton d'intégration avec RLS :

Lorsque vous appelez l’API REST Power BI pour générer un jeton d’intégration, incluez le paramètre identities :

{
  "datasets": [
    {
      "id": "dataset-guid-here"
    }
  ],
  "reports": [
    {
      "id": "report-guid-here"
    }
  ],
  "identities": [
    {
      "username": "[email protected]",
      "roles": ["DynamicSecurity"],
      "datasets": ["dataset-guid-here"]
    }
  ]
}

La valeur username est ce que USERPRINCIPALNAME() renvoie dans l'expression DAX. Le tableau roles spécifie les rôles RLS à appliquer. Vous pouvez transmettre n’importe quelle chaîne comme nom d’utilisateur : il n’est pas nécessaire qu’il s’agisse d’un véritable compte Azure AD.

Erreurs d'intégration courantes

Erreur 1 : ne pas transmettre l'identité effective. Si vous générez un jeton intégré sans le paramètre identities, le rapport intégré affiche toutes les données. Il s’agit de l’erreur d’intégration RLS la plus courante.

Erreur 2 : transmettre les rôles mais pas le nom d'utilisateur. Le nom d'utilisateur est requis pour le RLS dynamique. Sans cela, USERPRINCIPALNAME() renvoie un contenu vide et le filtre DAX ne correspond à aucune ligne : le rapport apparaît vide.

Erreur 3 : Utiliser l'identité du principal du service. Le principal du service est un administrateur d'espace de travail et contourne RLS. Vous devez explicitement transmettre l'identité de l'utilisateur final.

Erreur 4 : codage en dur des rôles dans le jeton d'intégration pour le RLS dynamique. Si vous utilisez le RLS dynamique avec un seul rôle (par exemple, "DynamicSecurity"), transmettez toujours ce nom de rôle. Ne créez pas de rôles distincts pour chaque utilisateur, ce qui va à l'encontre de l'objectif du RLS dynamique.

---

Test de la sécurité au niveau des lignes

Afficher en tant que rôle (Power BI Desktop)

Dans Power BI Desktop, accédez à Modélisation, puis Afficher en tant que :

1. Sélectionnez le(s) rôle(s) à tester
2. Entrez éventuellement un nom d'utilisateur pour tester le RLS dynamique (cela simule la valeur USERPRINCIPALNAME())
3. Cliquez sur OK

Le rapport affiche désormais les données comme si vous étiez l'utilisateur spécifié avec le rôle spécifié. Vérifiez :

• Les cartes KPI affichent les totaux filtrés corrects
• Les tableaux affichent uniquement les lignes dans le champ d'application de l'utilisateur
• Les graphiques reflètent les données filtrées
• Le filtrage croisé entre les visuels respecte les limites RLS
• Les pages d'exploration conservent le contexte RLS

Afficher en tant que (service Power BI)

Dans le service Power BI, ouvrez les paramètres du jeu de données et sélectionnez Sécurité. Vous pouvez tester les rôles directement en sélectionnant « Tester en tant que rôle » et en saisissant un nom d'utilisateur.

Liste de contrôle des tests automatisés

Créez une matrice de test avec les scénarios suivants :

---

Optimisation des performances pour RLS

Mesurer l'impact

Avant et après la mise en œuvre de RLS, utilisez l’analyseur de performances dans Power BI Desktop pour mesurer les temps de requête. Ouvrez le volet Performance Analyzer, démarrez l'enregistrement, interagissez avec le rapport et comparez les temps de requête DAX avec et sans RLS.

Une implémentation RLS bien conçue ajoute moins de 5 % de surcharge. Si vous constatez une dégradation supérieure à 10 %, étudiez les expressions du filtre DAX.

Techniques d'optimisation

Gardez les expressions de filtre simples. L'expression RLS idéale est une comparaison sur une seule colonne :

[Region] = USERPRINCIPALNAME()

Évitez les expressions complexes avec plusieurs appels CALCULATE, FILTER ou LOOKUPVALUE dans le filtre RLS lui-même.

Utilisez des clés entières au lieu de comparaisons de texte. Le filtrage sur [CompanyId] = 1 est plus rapide que sur [CompanyName] = "ECOSIRE Private Limited". Mappez les e-mails des utilisateurs avec des clés entières dans le tableau de mappage de sécurité.

Réduisez le nombre de tables avec les filtres RLS. Appliquez RLS aux tables de dimensions et laissez la propagation des relations gérer les tables de faits. L’application directe de RLS à de grandes tables de faits oblige Power BI à évaluer le filtre sur chaque ligne de la table de faits.

Pré-agrégé lorsque cela est possible. Si un utilisateur n'a besoin que de données de niveau résumé, envisagez de créer un tableau pré-agrégé avec le filtre de sécurité appliqué lors de l'ETL. Cela réduit le volume de données que Power BI doit filtrer au moment de la requête.

Évitez les filtres croisés bidirectionnels. Les relations bidirectionnelles augmentent la complexité des requêtes et peuvent entrer en conflit avec RLS. Utilisez des relations unidirectionnelles (de la dimension au fait) et appliquez RLS du côté de la dimension.

---

Pièges courants et solutions

Piège 1 : RLS non appliqué aux administrateurs de l'espace de travail

Les administrateurs de l’espace de travail et les membres disposant de l’autorisation Modifier contournent RLS. Ils voient toujours toutes les données. C'est intentionnel : les administrateurs ont besoin d'un accès complet pour gérer l'espace de travail.

Solution : Utilisez le rôle « Observateur » pour les utilisateurs professionnels qui doivent être soumis au RLS. Only grant Admin/Member/Contributor roles to the BI team.

Piège 2 : ALL() Suppression des filtres RLS

La fonction DAX ALL() supprime tous les filtres d'une table, y compris les filtres RLS. Si une mesure utilise ALL() sur une table filtrée par RLS, elle peut exposer des données que l'utilisateur ne devrait pas voir.

-- DANGEROUS: This measure ignores RLS on Dim_Region
Total Global Sales =
CALCULATE(SUM(Fact_Sales[Revenue]), ALL(Dim_Region))

Solution : Utilisez ALLSELECTED() au lieu de ALL() lorsque vous souhaitez supprimer les filtres slicer/visuels mais conserver les filtres RLS :

-- SAFE: This measure preserves RLS filters
Total Sales for Context =
CALCULATE(SUM(Fact_Sales[Revenue]), ALLSELECTED(Dim_Region))

Piège 3 : CALCULER le remplacement du RLS

CALCULATE avec des arguments de filtre explicites peut remplacer RLS dans certains scénarios, notamment avec REMOVEFILTERS :

-- DANGEROUS: REMOVEFILTERS is equivalent to ALL
Total Revenue All Regions =
CALCULATE(SUM(Fact_Sales[Revenue]), REMOVEFILTERS(Dim_Region[Region]))

Solution : Auditez toutes les mesures DAX pour l'utilisation de ALL, REMOVEFILTERS et ALLEXCEPT. Assurez-vous qu’ils ne font pas référence à des colonnes filtrées par RLS.

Piège 4 : modèles composites et RLS

Dans les modèles composites (mélangant Import et DirectQuery), RLS doit être défini séparément pour les tables Import et DirectQuery. Un seul rôle RLS peut contenir des filtres pour les deux, mais le comportement diffère :

• Importer des tables : le filtre RLS est évalué par le moteur Power BI
• Tables DirectQuery : le filtre RLS est traduit en SQL et envoyé à la source

Si la source DirectQuery ne prend pas en charge la fonction DAX utilisée dans le filtre RLS, la requête échouera.

Piège 5 : rapports paginés ignorant le RLS

Les rapports paginés Power BI (créés dans le Générateur de rapports) peuvent contourner le RLS de l'ensemble de données s'ils se connectent directement à la source de données. Pour appliquer RLS, les rapports paginés doivent se connecter via l’ensemble de données Power BI (pas directement à la base de données) et l’utilisateur doit disposer d’un rôle RLS attribué.

---

Modèle d'architecture RLS d'entreprise

Pour les grandes organisations, ECOSIRE recommande une architecture RLS standardisée :

Conception de la couche de sécurité

1. Table de mappage de sécurité stockée dans une base de données centrale (liste Azure SQL ou SharePoint)
2. Rôle RLS unique nommé "DynamicSecurity" à l'aide de USERPRINCIPALNAME()
3. Synchronisation de groupe Azure AD qui remplit automatiquement le tableau de mappage de sécurité en fonction de l'appartenance au groupe
4. Prise en charge de la hiérarchie à l'aide d'une table parent-enfant pré-aplatie
5. Piste d'audit enregistrant quels utilisateurs ont accédé à quelles données (via les journaux d'activité Power BI et l'API REST)

Processus de gouvernance

1. Les gestionnaires de données maintiennent la table de mappage de sécurité
2. Les modifications sont examinées et approuvées via un processus de gestion du changement
3. Des audits mensuels comparent les affectations Power BI RLS au système d'enregistrement RH
4. Des tests d'intrusion trimestriels vérifient l'efficacité du RLS

Cette architecture s'adapte à des milliers d'utilisateurs sur des centaines d'ensembles de données tout en conservant un point unique d'administration de la sécurité.

---

##FAQ

RLS fonctionne-t-il avec les licences gratuites Power BI ?

Non. RLS nécessite des licences Power BI Pro ou Premium par utilisateur pour tous les utilisateurs consommant des rapports protégés par RLS. Les utilisateurs de licence gratuite ne peuvent accéder au contenu que dans un espace de travail de capacité Premium, et même dans ce cas, ils ont besoin d'une licence Pro ou PPU pour se voir attribuer des rôles RLS. Dans les scénarios Power BI Embedded, les utilisateurs finaux n'ont pas besoin de licences Power BI --- RLS est appliqué via le jeton d'intégration.

Can I implement RLS based on Azure AD groups instead of individual users?

Pas directement. Le RLS de Power BI évalue les expressions DAX par rapport à USERPRINCIPALNAME(), qui renvoie l'e-mail de l'utilisateur individuel. Toutefois, vous pouvez créer une table de mappage de sécurité qui mappe les groupes Azure AD aux étendues de données et la remplir à l’aide de l’API Microsoft Graph ou de la synchronisation des membres des groupes Azure AD. L'expression DAX filtre toujours en fonction de l'e-mail de l'utilisateur, mais la table de mappage de sécurité fournit le mappage groupe-données.

Que se passe-t-il si un utilisateur n'est affecté à aucun rôle RLS ?

Si RLS est défini sur un ensemble de données et qu’un utilisateur n’est affecté à aucun rôle, l’utilisateur ne voit aucune donnée. Le rapport se charge mais tous les visuels sont vides ou nuls. Il s’agit de la valeur sécurisée par défaut --- Power BI ne suppose aucun accès sauf autorisation explicite. Cependant, les administrateurs de l'espace de travail et les membres disposant de l'autorisation Modifier contournent RLS et voient toujours toutes les données, quelles que soient les attributions de rôles.

RLS peut-il filtrer les données dans les tableaux de bord en temps réel ?

Oui. RLS fonctionne avec les modes Import et DirectQuery. En mode DirectQuery, le filtre RLS est traduit en clause SQL WHERE et envoyé à la base de données avec chaque requête, de sorte que le filtrage s'effectue en temps réel. En mode Importation, le filtrage est appliqué en mémoire lorsque l'utilisateur ouvre le rapport. Les deux modes offrent la même garantie de sécurité : l'utilisateur ne voit que les données autorisées.

Comment puis-je vérifier qui a accédé à quelles données via RLS ?

Power BI fournit des journaux d'activité via le centre d'administration Microsoft 365 et l'API REST Power BI. Ces journaux enregistrent les vues de rapports, les actualisations des ensembles de données et les opérations d'exportation, y compris l'identité de l'utilisateur. Cependant, les journaux n'enregistrent pas les lignes spécifiques consultées par un utilisateur. Pour un audit détaillé de l'accès aux données, activez l'audit au niveau de la base de données (par exemple, l'audit PostgreSQL pgaudit ou Azure SQL) pour enregistrer les requêtes réelles générées par DirectQuery avec les filtres RLS appliqués.