Restreindre l’accès aux données de modèle Power BI
En tant que modeleur de données, vous configurez RLS en créant un ou plusieurs rôles. Un rôle a un nom unique dans le modèle et comprend généralement une ou plusieurs règles. Les règles appliquent des filtres au niveau des tables du modèle en utilisant des expressions de filtre DAX (Data Analysis Expressions).
Notes
Par défaut, un modèle de données n’a pas de rôle. Et quand un modèle de données est dépourvu de rôles, les utilisateurs (qui ont l’autorisation d’interroger le modèle de données) ont accès à toutes les données du modèle.
Conseil
Il est possible de définir un rôle qui ne comporte pas de règles. Dans ce cas, le rôle donne accès à l’ensemble des lignes de toutes les tables du modèle. Cette définition de rôle conviendrait pour un utilisateur administrateur autorisé à visualiser toutes les données.
Vous pouvez créer, valider et gérer des rôles dans Power BI Desktop. En ce qui concerne les modèles Azure Analysis Services et SQL Server Analysis Services, vous pouvez créer, valider et gérer des rôles à l’aide de SQL Server Data Tools (SSDT).
Vous pouvez également créer et gérer des rôles à l’aide de SQL Server Management Studio (SSMS) ou d’un outil tiers comme Tabular Editor.
Pour mieux comprendre comment la manière dont RLS limite l’accès aux données, regardez l’image animée suivante.
Appliquer les principes de conception des schémas en étoile
Nous vous recommandons d’appliquer les principes de conception des schémas en étoile pour produire un modèle comprenant des tables de dimension et de faits. Il est courant de configurer Power BI pour appliquer des règles qui filtrent les tables de dimensions, ce qui permet aux relations de modèle de propager efficacement ces filtres aux tables de faits.
L’image suivante est le diagramme de modèle du modèle de données d’analyse des ventes d’Adventure Works. Elle présente une conception de schéma en étoile comprenant une table de faits unique nommée Sales. Les autres tables sont des tables de dimensions qui prennent en charge l’analyse des ventes mesurées par date, territoire de vente, client, revendeur, commande, produit et vendeur. Notez que les relations du modèle connectent toutes les tables. Ces relations propagent les filtres (directement ou indirectement) à la table Sales.
Cette conception de modèle prend les exemples présentés dans cette unité.
Définir des règles
Les expressions des règles sont évaluées dans le contexte de ligne. Cela signifie que l’expression est évaluée pour chaque ligne utilisant les valeurs de colonne de cette ligne. Quand l’expression retourne TRUE, l’utilisateur peut « voir » la ligne.
Conseil
Pour en savoir plus sur le contexte de ligne, parcourez le module Ajouter des tables et des colonnes calculées à des modèles Power BI Desktop. Bien que ce module porte essentiellement sur l’ajout de calculs de modèle, il comporte une unité qui présente et décrit le contexte de ligne.
Vous pouvez définir des règles statiques ou dynamiques.
Règles statiques
Les règles statiques utilisent des expressions DAX qui font référence à des constantes.
Prenons l’exemple de la règle suivante appliquée à la table Region, qui limite l’accès aux données de ventes pour le Midwest.
'Region'[Region] = "Midwest"
Les étapes suivantes expliquent comment Power BI applique la règle. Elle effectue les actions suivantes :
Filtre la table Region, ce qui a pour conséquence d’afficher une seule ligne visible (pour le Midwest).
Utilise la relation de modèle pour propager le filtre de la table Region à la table State, ce qui a pour effet d’afficher 14 lignes visibles (la région du Midwest comprend 14 États).
Utilise la relation du modèle pour propager le filtre de la table State à la table Sales, ce qui a pour effet d’afficher plusieurs milliers de lignes visibles (faits de ventes pour les États qui appartiennent à la région Midwest).
La règle statique la plus simple qui peut être créée limite l’accès à toutes les lignes de table. Examinez la règle suivante qui s’applique à la table Sales Details (non représentée dans le diagramme du modèle).
FALSE()
Cette règle vise à empêcher les utilisateurs d’accéder aux données de table. Cela peut être utile quand les commerciaux sont autorisés à consulter les résultats généraux des ventes (de la table Sales), mais pas les détails au niveau des commandes.
La définition de règles statiques est simple et efficace. Envisagez de les employer quand vous ne devez en créer que quelques-unes, comme ce pourrait être le cas chez Aventure Works qui ne compte que six régions. Cependant, sachez que les règles statiques présentent des inconvénients. Leur création et leur configuration peuvent demander beaucoup d’efforts. L’intégration de nouvelles régions nécessiterait de mettre à jour et de republier le jeu de données.
Si vous avez un grand nombre de règles à configurer et que vous prévoyez d’ajouter de nouvelles règles à l’avenir, envisagez de créer plutôt des règles dynamiques.
Règles dynamiques
Les règles dynamiques utilisent des fonctions DAX spécifiques qui retournent des valeurs environnementales (et non des constantes). Les valeurs environnementales sont retournées à partir de trois fonctions DAX spécifiques :
USERNAME ou USERPRINCIPALNAME : retourne l’utilisateur authentifié Power BI en tant que valeur de texte.
CUSTOMDATA : retourne la propriété CustomData transmise dans la chaîne de connexion. Des outils de création de rapports non Power BI qui se connectent au jeu de données à l’aide d’une chaîne de connexion peuvent définir cette propriété, comme Microsoft Excel.
Notes
Sachez que la fonction USERNAME retourne l’utilisateur au format DOMAINE\nom_utilisateur quand elle est utilisée dans Power BI Desktop. En revanche, quand elle est utilisée dans le service Power BI, elle retourne le format de nom d’utilisateur principal (UPN) de l’utilisateur, comme username@adventureworks.com. Vous pouvez aussi utiliser la fonction USERPRINCIPALNAME, qui retourne systématiquement l’utilisateur au format de nom d’utilisateur principal.
Envisagez une conception de modèle revue qui comprend désormais la table AppUser (masquée). Chaque ligne de la table AppUser décrit un nom d’utilisateur et une région. Une relation de modèle à la table Region propage les filtres de la table AppUser.
La règle suivante qui s’applique à la table AppUser limite l’accès aux données des régions de l’utilisateur authentifié.
'AppUser'[UserName] = USERPRINCIPALNAME()
La définition de règles dynamiques est simple et efficace quand une table de modèle stocke les valeurs de nom d’utilisateur. Ils vous permettent d’appliquer une conception de sécurité au niveau des lignes pilotée par les données. Par exemple, quand des commerciaux sont ajoutés ou supprimés dans la table AppUser (ou sont affectés à différentes régions), cette approche de conception fonctionne.
Valider les rôles
Quand vous créez des rôles, il est important de les tester pour vérifier qu’ils appliquent les bons filtres. Pour les modèles de données créés dans Power BI Desktop, la fonction Voir comme vous permet d’afficher le rapport avec différents rôles appliqués et différentes valeurs de nom d’utilisateur transmises.
Configurer des mappages de rôles
Les mappages de rôles doivent être configurés avant que les utilisateurs accèdent au contenu Power BI. Le mappage de rôles implique l’attribution d’objets de sécurité Microsoft Entra aux rôles. Les objets de sécurité peuvent être des comptes d’utilisateurs ou des groupes de sécurité.
Conseil
Dans la mesure du possible, il est recommandé de mapper les rôles à des groupes de sécurité. De cette façon, il y aura moins de mappages, et vous pourrez déléguer la gestion des appartenances aux groupes aux administrateurs réseau.
Pour les modèles Power BI Desktop, le mappage de rôle s’effectue généralement dans le service Power BI. Pour les modèles Azure Analysis Services ou SQL Server Analysis Services, le mappage de rôles s’effectue généralement dans SSMS.
Pour plus d’informations sur la configuration de la sécurité au niveau des lignes, consultez :
Utiliser une authentification unique (SSO) pour les sources DirectQuery
Lorsque votre modèle de données comprend des tables DirectQuery dont la source de données prend en charge SSO, la source de données peut appliquer des autorisations d’accès aux données. Ainsi, la base de données applique RLS, et les jeux de données et rapports Power BI respectent la sécurité de la source de données.
Prenez en compte le fait qu’Adventure Works dispose d’une base de données Azure SQL Database pour les opérations de vente, qui réside dans le même locataire que Power BI. La base de données applique RLS pour contrôler l’accès aux lignes dans différentes tables de base de données. Vous pouvez créer un modèle DirectQuery qui se connecte à cette base de données sans rôles, et le publier dans le service Power BI. Lorsque vous définissez des informations d’identification de source de données dans le service Power BI, vous activez SSO. Lorsque les consommateurs de rapports ouvrent des rapports Power BI, Power BI transmet leur identité à la source de données. La source de données applique ensuite RLS en fonction de l’identité du consommateur de rapports.
Pour plus d’informations sur la sécurité au niveau des lignes d’Azure SQL Database, consultez Sécurité au niveau des lignes.
Notes
Les tables et les colonnes calculées qui font référence à une table DirectQuery à partir d’une source de données avec authentification unique (SSO) ne sont pas prises en charge dans le service Power BI.
Pour plus d’informations sur les sources de données qui prennent en charge SSO, consultez Authentification unique (SSO) pour les sources DirectQuery.