Rôles
s’applique à :
SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium
Les rôles dans les modèles tabulaires définissent des autorisations de membre pour un modèle. Les membres du rôle peuvent effectuer des actions sur le modèle comme défini par l’autorisation de rôle. Les rôles définis avec des autorisations de lecture peuvent également fournir davantage de sécurité au niveau des lignes à l’aide de filtres au niveau des lignes.
Pour les modèles sémantiques Azure Analysis Services et Power BI, les utilisateurs doivent se trouver dans votre ID Microsoft Entra. Les noms d’utilisateur et les groupes sont spécifiés par adresse e-mail organisationnelle ou par nom d’utilisateur principal (UPN). Pour SQL Server Analysis Services, les rôles contiennent des membres d’utilisateur spécifiés par le nom d’utilisateur Windows ou par le groupe Windows et les autorisations (lecture, processus, administrateur).
Important
Si vous utilisez Visual Studio pour créer des rôles et ajouter des utilisateurs à un projet de modèle tabulaire qui sera déployé sur Azure Analysis Services ou Power BI, utilisez espace de travail intégré.
Important
Pour que les utilisateurs se connectent à un modèle déployé à l’aide d’une application cliente de création de rapports, vous devez créer au moins un rôle qui a au moins l’autorisation Lecture. Ajoutez des utilisateurs de l’application cliente de création de rapports au rôle en tant que membres.
Les informations contenues dans cet article sont destinées aux auteurs de modèles tabulaires qui définissent des rôles à l’aide de la boîte de dialogue Gestionnaire de rôles dans SSDT. Les rôles définis pendant la création de modèle s’appliquent à la base de données de l’espace de travail du modèle. Une fois qu’une base de données de modèle est déployée, les administrateurs de base de données de modèle peuvent gérer (ajouter, modifier, supprimer) des membres de rôle à l’aide de SSMS.
Présentation des rôles
Les rôles sont utilisés dans Analysis Services pour gérer l’accès aux données de modèle. Il existe deux types de rôles :
Le rôle serveur est un rôle fixe qui fournit un accès administrateur à une instance de serveur Analysis Services. Les rôles serveur ne s’appliquent pas à Power BI. Au lieu de cela, Power BI utilise rôles d’espace de travail.
Les rôles de base de données sont définis par les auteurs de modèles et les administrateurs pour contrôler l’accès à une base de données et données de modèle pour les utilisateurs.
Les rôles définis pour un modèle tabulaire sont des rôles de base de données. Ces rôles contiennent des utilisateurs ou des groupes disposant d’autorisations spécifiques qui définissent l’action que ces membres peuvent entreprendre sur la base de données de modèle. Un rôle est créé en tant qu’objet distinct dans la base de données et s’applique uniquement à la base de données dans laquelle le rôle est créé. L’auteur du modèle ajoute des utilisateurs et des groupes au rôle. Par défaut, l’auteur du modèle dispose des autorisations d’administrateur sur le serveur de base de données de l’espace de travail ; pour un modèle déployé, les membres de rôle sont ajoutés par un administrateur.
Les rôles dans les modèles tabulaires peuvent être définis avec des filtres de lignes, également appelés de sécurité au niveau des lignes. Les filtres de lignes utilisent des expressions DAX pour définir les lignes d’une table et toutes les lignes associées dans les nombreuses directions qu’un utilisateur peut interroger. Les filtres de lignes utilisant des expressions DAX ne peuvent être définis que pour les autorisations Lecture et Lecture et traitement. Dans Power BI, les rôles de modèle sont définis dans Power BI Desktop et s’appliquent uniquement à la sécurité au niveau des lignes. Pour plus d’informations, consultez filtres de lignes plus loin dans cet article.
Par défaut, lorsque vous créez un projet de modèle tabulaire, le projet n’a pas de rôles définis. Les rôles sont définis à l’aide de la boîte de dialogue Gestionnaire de rôles dans SSDT. Lorsque les rôles sont définis lors de la création de modèles, ils sont appliqués à la base de données de l’espace de travail du modèle. Lorsque le modèle est déployé, les mêmes rôles sont appliqués au modèle déployé. Une fois qu’un modèle est déployé, les membres du rôle serveur (Administrateur Analysis Services) et les administrateurs de base de données peuvent gérer les rôles associés au modèle et les membres associés à chaque rôle à l’aide de SSMS.
Autorisations
Les autorisations de rôle décrites dans cette section s’appliquent uniquement à Azure Analysis Services et SQL Server Analysis Services. Dans Power BI, les autorisations sont définies pour le modèle sémantique. Pour plus d’informations, consultez Gérer l’accès au modèle sémantique.
Chaque rôle dispose d’une autorisation de base de données définie unique (à l’exception de l’autorisation de lecture et de processus combinée). Par défaut, un nouveau rôle a l’autorisation Aucun. Lorsque les membres sont ajoutés à un rôle disposant de l’autorisation None, ils ne peuvent pas modifier la base de données, exécuter une opération de processus, interroger des données ou voir la base de données, sauf si une autre autorisation est accordée.
Un groupe ou un utilisateur peut être membre d’un nombre quelconque de rôles, chaque rôle ayant une autorisation différente. Lorsqu’un utilisateur est membre de plusieurs rôles, les autorisations définies pour chaque rôle sont cumulatives. Par exemple, si un utilisateur est membre d’un rôle avec l’l’autorisation Lecture, ainsi qu’un membre d’un rôle disposant d’une autorisation None, cet utilisateur dispose d’autorisations lecture.
Chaque rôle peut avoir l’une des autorisations suivantes définies :
| Autorisations | Description | Filtres de lignes à l’aide de DAX |
|---|---|---|
| Aucun | Les membres ne peuvent apporter aucune modification au schéma de base de données du modèle et ne peuvent pas interroger de données. | Les filtres de lignes ne s’appliquent pas. Aucune donnée n’est visible pour les utilisateurs dans ce rôle |
| Lire | Les membres sont autorisés à interroger des données (basées sur des filtres de lignes), mais ne peuvent pas voir la base de données de modèle dans SSMS, ne peuvent apporter aucune modification au schéma de base de données du modèle et l’utilisateur ne peut pas traiter le modèle. | Les filtres de lignes peuvent être appliqués. Seules les données spécifiées dans la formule DAX du filtre de ligne sont visibles par les utilisateurs. |
| Lecture et processus | Les membres sont autorisés à interroger des données (basées sur des filtres au niveau des lignes) et à exécuter des opérations de processus en exécutant un script ou un package qui contient une commande de processus, mais ne peuvent apporter aucune modification à la base de données. Les utilisateurs disposant d’autorisations ne peuvent pas afficher la base de données de modèle dans SSMS. | Les filtres de lignes peuvent être appliqués. Seules les données spécifiées dans la formule DAX du filtre de ligne peuvent être interrogées. |
| Processus | Les membres peuvent exécuter des opérations de processus en exécutant un script ou un package qui contient une commande de processus. Les membres ne peuvent pas modifier le schéma de base de données de modèle, ne peuvent pas interroger de données et ne peuvent pas interroger la base de données de modèle dans SSMS. | Les filtres de lignes ne s’appliquent pas. Aucune donnée ne peut être interrogée dans ce rôle |
| Administrateur | Les membres peuvent apporter des modifications au schéma du modèle et interroger toutes les données dans le concepteur de modèles, le client de création de rapports et SSMS. | Les filtres de lignes ne s’appliquent pas. Toutes les données peuvent être interrogées dans ce rôle. |
Note
Les membres disposant d’autorisations Lecture et Lecture et Processus peuvent interroger des données en fonction des filtres de lignes, mais ne peuvent pas voir la base de données de modèle dans SSMS. Les membres ne peuvent pas apporter de modifications au schéma de base de données du modèle et ne peuvent pas traiter le modèle. Toutefois, dans SQL Server Analysis Services 2019 et versions antérieures, les membres peuvent utiliser DMV pour déterminer les définitions de mesures. SQL Server Analysis Services 2022 et versions ultérieures bloquent l’accès aux DMV pour améliorer la sécurité.
Filtres de lignes
Les filtres de lignes, communément appelés sécurité au niveau des lignes dans Power BI, définissent les lignes d’une table qui peuvent être interrogées par les membres d’un rôle particulier. Les filtres de lignes sont définis pour chaque table d’un modèle à l’aide de formules DAX.
Les filtres de lignes ne peuvent être définis que pour les rôles avec des autorisations Lecture et Lecture et Traitement. Par défaut, si un filtre de lignes n’est pas défini pour une table particulière, les membres d’un rôle disposant d’une autorisation Lecture ou Lecture et Processus peuvent interroger toutes les lignes de la table, sauf si le filtrage croisé s’applique à partir d’une autre table.
Une fois qu’un filtre de lignes est défini pour une table particulière, une formule DAX qui prend la valeur TRUE/FALSE, définit les lignes pouvant être interrogées par les membres de ce rôle particulier. Les lignes non incluses dans la formule DAX ne peuvent pas être interrogées. Par exemple, pour les membres du rôle Sales, si la table Customers contient l’expression de filtre de lignes suivante, =Customers [Country] = « USA », les membres du rôle Sales verront uniquement les clients aux États-Unis.
Les filtres de lignes s’appliquent aux lignes spécifiées ainsi qu’aux lignes associées. Lorsqu’une table a plusieurs relations, les filtres appliquent la sécurité de la relation active. Les filtres de lignes sont croisés avec d’autres fichiers de lignes définis pour les tables associées, par exemple :
| Table | Expression DAX |
|---|---|
| Région | =Region[Country]="USA » |
| ProductCategory | =ProductCategory[Name]="Bikes » |
| Transactions | =Transactions[Année]=2020 |
L’effet net de ces autorisations sur la table Transactions est que les membres peuvent interroger des lignes de données où le client se trouve aux États-Unis, et la catégorie de produit est des vélos, et l’année est 2020. Les utilisateurs ne peuvent interroger aucune transaction en dehors des États-Unis, ni les transactions qui ne sont pas des vélos, ni les transactions non effectuées en 2020, sauf s’ils sont membres d’un autre rôle qui accorde ces autorisations.
Vous pouvez utiliser le filtre, =FALSE(), pour refuser l’accès à toutes les lignes d’une table entière.
Pour en savoir plus sur les rôles de modèle dans Power BI, consultez sécurité au niveau des lignes dans Power BI.
Sécurité dynamique
La sécurité dynamique vous permet de définir la sécurité au niveau des lignes en fonction du nom d’utilisateur de l’utilisateur actuellement connecté ou de la propriété CustomData retournée à partir d’une chaîne de connexion. Pour implémenter la sécurité dynamique, vous devez inclure une table avec des valeurs de connexion (nom d’utilisateur Windows) pour les utilisateurs, ainsi qu’un champ qui peut être utilisé pour définir une autorisation particulière dans votre modèle. Par exemple, incluez une table dimEmployees avec un ID de connexion (domaine\nom d’utilisateur) ainsi qu’une valeur de service pour chaque employé dans le modèle.
Pour implémenter la sécurité dynamique, vous pouvez utiliser les fonctions suivantes dans le cadre d’une formule DAX pour renvoyer le nom d’utilisateur de l’utilisateur actuellement connecté ou la propriété CustomData dans une chaîne de connexion :
| Fonction | Description |
|---|---|
| fonction USERNAME (DAX) | Retourne le domaine\nom d’utilisateur de l’utilisateur actuellement connecté. |
| fonction CUSTOMDATA (DAX) | Renvoie la propriété CustomData dans une chaîne de connexion. |
Vous pouvez utiliser la fonction LOOKUPVALUE pour retourner des valeurs pour une colonne où le nom d’utilisateur Windows est le même que le nom d’utilisateur retourné par la fonction USERNAME ou une chaîne retournée par la fonction CustomData. Les requêtes peuvent être restreintes lorsque les valeurs retournées par LOOKUPVALUE correspondent à des valeurs dans la même table ou associée.
Par exemple, à l’aide de cette formule :
='dimDepartment'[DepartmentId]=LOOKUPVALUE('dimEmployees'[DepartmentId], 'dimEmployees'[LoginId], USERNAME(), 'dimEmployees'[LoginId], 'dimDepartment'[DepartmentId])
La fonction LOOKUPVALUE retourne des valeurs pour la colonne dimEmployees[DepartmentId] où le dimEmployees[LoginId] est identique à l’ID de connexion de l’utilisateur actuellement connecté, retourné par USERNAME et les valeurs de dimEmployees[DepartmentId] sont identiques aux valeurs de dimDepartment[DepartmentId]. Les valeurs de DepartmentId retournées par LOOKUPVALUE sont ensuite utilisées pour restreindre les lignes interrogées dans la table dimDepartment et toutes les tables associées par DepartmentId. Seules les lignes où DepartmentId se trouvent également dans les valeurs de DepartmentId retournées par la fonction LOOKUPVALUE sont retournées.
dimEmployees
| LastName | FirstName | LoginId | DepartmentName | DepartmentId |
|---|---|---|---|---|
| Marron | Kevin | Adventure-works\kevin0 | Marketing | 7 |
| Bradley | David | Adventure-works\david0 | Marketing | 7 |
| Dobney | JoLynn | Adventure-works\JoLynn0 | Production | 4 |
| Baretto DeMattos | Paula | Adventure-works\Paula0 | Ressources humaines | 2 |
dimDepartment
| DepartmentId | DepartmentName |
|---|---|
| 1 | Corporatif |
| 2 | Général exécutif et administration |
| 3 | Gestion des stocks |
| 4 | Fabrication |
| 5 | Assurance qualité |
| 6 | Recherche et développement |
| 7 | Ventes et marketing |
Test des rôles
Lorsque vous créez un projet de modèle dans Visual Studio, vous pouvez utiliser la fonctionnalité Analyser dans Excel pour tester l’efficacité des rôles que vous avez définis. Dans le menu Modèle dans le concepteur de modèles, sélectionnez Analyser dans Excel. Avant d’ouvrir Excel, la boîte de dialogue Choisir les informations d’identification et perspective s’affiche. Dans cette boîte de dialogue, vous pouvez spécifier le nom d’utilisateur actuel, un nom d’utilisateur différent, un rôle et une perspective que vous utiliserez pour vous connecter au modèle d’espace de travail en tant que source de données. Pour plus d’informations, consultez Analyser dans Excel.
Rôles de script
Les rôles pour les modèles déployés et les modèles sémantiques peuvent être scriptés à l’aide de TMSL (Tabular Model Scripting Language) pour créer ou modifier l’objet rôles . Les scripts TMSL peuvent être exécutés dans SSMS ou avec l’applet de commande PowerShell Invoke-ASCm d.
Voir aussi
créer et gérer des rôles
perspectives
Analyser dans Excel
fonction USERNAME (DAX)
fonction LOOKUPVALUE (DAX)
fonction CUSTOMDATA (DAX)