Autorisation de l'accès à des objets et des opérations (Analysis Services)

S’applique à : SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

L’accès utilisateur non administratif aux cubes, aux dimensions et aux modèles d’exploration de données au sein d’une base de données SQL Server Analysis Services est accordé via l’appartenance à un ou plusieurs rôles de base de données. SQL Server Analysis Services administrateurs créent ces rôles de base de données, accordent des autorisations de lecture ou de lecture/écriture sur SQL Server Analysis Services objets, puis attribuent des utilisateurs et des groupes Microsoft Windows à chaque rôle.

SQL Server Analysis Services détermine les autorisations effectives pour un utilisateur ou un groupe Windows spécifique en combinant les autorisations associées à chaque rôle de base de données auquel appartient l’utilisateur ou le groupe. Par conséquent, si un rôle de base de données n'autorise pas un utilisateur ou un groupe à afficher une dimension, une mesure ou un attribut et qu'un autre rôle de base de données autorise l'utilisateur ou le groupe, l'utilisateur ou le groupe peut afficher l'objet.

Important

Les membres du rôle Administrateur de serveur SQL Server Analysis Services et les membres d’un rôle de base de données disposant d’autorisations de contrôle total (administrateur) peuvent accéder à toutes les données et métadonnées de la base de données et n’ont pas besoin d’autorisations supplémentaires pour afficher des objets spécifiques. En outre, les membres du rôle serveur SQL Server Analysis Services ne peuvent pas se voir refuser l’accès à un objet dans une base de données, et les membres d’un rôle de base de données SQL Server Analysis Services qui dispose d’autorisations de contrôle total (administrateur) au sein d’une base de données ne peuvent pas se voir refuser l’accès à n’importe quel objet de cette base de données. Les opérations d'administration spécifiques, telles que le traitement, peuvent être autorisées via des rôles séparés avec des autorisations moins élevées. Pour plus d’informations, consultez Accorder des autorisations de processus (Analysis Services).

Lister les rôles définis pour votre base de données

Les administrateurs peuvent exécuter une simple requête DMV dans SQL Server Management Studio pour obtenir une liste de tous les rôles définis sur le serveur.

1. Dans SSMS, cliquez avec le bouton droit sur une base de données et sélectionnez Nouvelle requête | MDX.

2. Tapez la requête suivante et appuyez sur F5 pour l'exécuter :

   Select * from $SYSTEM.DBSCHEMA_CATALOGS  
   

   Les résultats incluent le nom de la base de données, la description, le nom du rôle et la date de dernière modification. En vous servant de ces informations comme point de départ, vous pouvez vérifier les appartenances et les autorisations d'un rôle spécifique pour des bases de données individuelles.

Vue d'ensemble verticale de l'autorisation Analysis Services

Cette section traite du flux de travail de base pour la configuration des autorisations.

Étape 1 : Administration du serveur

En guise de première étape, identifiez qui disposera de droits d'administrateur au niveau du serveur. Pendant l'installation, l'administrateur local qui installe SQL Server doit spécifier un ou plusieurs comptes Windows en tant qu'administrateur serveur Analysis Services. Les administrateurs de serveur disposent de toutes les autorisations possibles sur un serveur, notamment l'autorisation pour afficher, modifier et supprimer les objets sur le serveur ou afficher les données associées. Une fois l'installation terminée, un administrateur de serveur peut ajouter ou supprimer des comptes pour changer l'appartenance de ce rôle. Pour plus d’informations sur ce niveau d’autorisation, consultez Accorder des droits d’administrateur de serveur à un instance Analysis Services.

Étape 2 : Administration de bases de données

Ensuite, une fois qu'une solution tabulaire ou multidimensionnelle a été créée, elle est déployée sur le serveur en tant que base de données. Un administrateur de serveur peut déléguer les tâches d'administration de base de données en définissant un rôle qui dispose des autorisations Contrôle total pour la base de données en question. Les membres de ce rôle peuvent traiter ou interroger les objets dans la base de données, et créer des rôles supplémentaires pour accéder aux cubes, dimensions et autres objets au sein de la base de données elle-même. Pour plus d’informations, consultez Accorder des autorisations de base de données (Analysis Services).

Étape 3 : Activer l’accès à un cube ou à un modèle pour les charges de travail de requête et de traitement

Par défaut, seuls les administrateurs du serveur et de la base de données ont accès aux cubes ou aux modèles tabulaires. L'accès à ces structures de données par d'autres personnes de votre organisation nécessite des attributions de rôle supplémentaires qui correspondent aux comptes d'utilisateur et de groupe Windows aux cubes ou aux modèles, ainsi que des autorisations qui accordent des privilèges Read . Pour plus d’informations, consultez Accorder des autorisations de cube ou de modèle (Analysis Services).

Les tâches de traitement peuvent être isolées d'autres fonctions d'administration, ce qui permet aux administrateurs de serveur et de base de données de déléguer cette tâche à d'autres personnes ou de configurer un traitement sans assistance en indiquant des comptes de service qui exécutent des logiciels de planification. Pour plus d’informations, consultez Accorder des autorisations de processus (Analysis Services).

Notes

Les utilisateurs n’ont pas besoin d’autorisations sur les tables relationnelles de la base de données relationnelle sous-jacente à partir de laquelle SQL Server Analysis Services charge ses données, et n’ont pas besoin d’autorisations au niveau du fichier sur l’ordinateur sur lequel le instance de SQL Server Analysis Services est en cours d’exécution.

Étape 4 (facultative) : Accorder ou refuser l’accès à des objets de cube intérieurs

SQL Server Analysis Services fournit des paramètres de sécurité pour définir des autorisations sur des objets individuels, notamment des membres de dimension et des cellules au sein d’un modèle de données. Pour plus d’informations, consultez Accorder un accès personnalisé aux données de dimension (Analysis Services) et Accorder un accès personnalisé aux données de cellule (Analysis Services).

Vous pouvez également faire varier les autorisations en fonction de l'identité d'un utilisateur. Souvent appelée sécurité dynamique, elle est implémentée à l’aide de la fonction UserName (MDX)

Bonnes pratiques

Pour mieux gérer les autorisations, nous vous suggérons l'approche suivante :

1. Créer des rôles par fonction (par exemple, dbadmin, cubedeveloper, processadmin) afin que la personne qui est responsable de ces rôles puisse savoir d'un coup d'œil ce que ces rôles autorisent. Comme déjà indiqué, vous pouvez définir des rôles dans la définition du modèle, ce qui permet de conserver ces rôles pour d'autres déploiements de solution.

2. Créer un groupe de sécurité Windows correspondant dans Active Directory, puis tenir à jour le groupe de sécurité dans Active Directory afin qu'il contienne les comptes individuels appropriés. Les spécialistes de la sécurité sont ainsi responsables de l'appartenance au groupe de sécurité ce qui est un avantage dans la mesure où ils disposent déjà des outils et des connaissances nécessaires à la maintenance des comptes dans votre organisation.

3. Générez des scripts dans SQL Server Management Studio afin de pouvoir répliquer rapidement les attributions de rôles chaque fois que le modèle est redéployé à partir de ses fichiers sources vers un serveur. Pour plus d’informations sur la façon de générer rapidement un script, consultez Accorder des autorisations de cube ou de modèle (Analysis Services).

4. Adopter une convention d'attribution de noms qui reflète la portée et l'appartenance du rôle. Les noms de rôle sont visibles uniquement dans les outils de conception et d'administration, il est donc recommandé d'utiliser une convention d'attribution de nom qui soit parlante pour vos spécialistes de la sécurité du cube. Par exemple, processadmin-windowsgroup1 indique un accès en lecture, plus des droits de traitement, pour les personnes de votre organisation dont les comptes d’utilisateur Windows individuels sont membres du groupe de sécurité windowsgroup1 .

   L'ajout des informations de compte peut vous aider à savoir quels comptes sont utilisés dans les différents rôles. Dans la mesure où les rôles sont additifs, les rôles combinés associés à windowsgroup1 composent le jeu d'autorisations effectif pour les personnes qui appartiennent à ce groupe de sécurité.

5. Les développeurs de cube ont besoin des autorisations Contrôle total pour les modèles et les bases de données en développement, mais n'auront besoin que des autorisations Lecture une fois une base de données déployée sur un serveur de produit. N'oubliez pas de développer des définitions de rôle et des assignations pour tous les scénarios, notamment le développement, le test et les déploiements en production.

Cela permet de minimiser l'actualisation des définitions de rôle et de l'appartenance de rôle dans le modèle et fournit une meilleure visibilité sur les assignations de rôle ce qui facilite l'implémentation et la mise à jour des autorisations du cube.

Voir aussi

Accorder des droits d’administrateur de serveur à un instance Analysis Services
Rôles et autorisations (Analysis Services)
Méthodologies d'authentification prises en charge par Analysis Services