Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à :
SQL Server Analysis Services
Azure Analysis Services
Fabric/Power BI Premium
Les utilisateurs non administratifs ont accès aux cubes, dimensions et modèles d’exploration de données au sein d’une base de données SQL Server Analysis Services en étant membres d’un ou plusieurs rôles de base de données. Les administrateurs de SQL Server Analysis Services créent ces rôles de base de données, accordent des autorisations de lecture ou de lecture/écriture sur les objets SQL Server Analysis Services et attribuent les utilisateurs et les groupes Microsoft Windows à chaque rôle.
SQL Server Analysis Services détermine les autorisations effectives d’un utilisateur ou d’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 ne donne pas à un utilisateur ou un groupe l’autorisation d’afficher une dimension, une mesure ou un attribut, mais qu’un autre rôle de base de données donne à cet utilisateur ou groupe l’autorisation d’afficher l’objet.
Important
Les membres du rôle Administrateur de serveur SQL Server Analysis Services et membres d’un rôle de base de données disposant d’autorisations 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. De plus, les membres du rôle serveur SQL Server Analysis Services ne peuvent pas être refusés d'accéder à un objet dans une base de données, et les membres d'un rôle de base de données SQL Server Analysis Services disposant d'autorisations Contrôle total (Administrateur) au sein d'une base de données ne peuvent pas être refusés d'accéder à un objet au sein de cette base de données. Les opérations administratives spécialisées, telles que le traitement, peuvent être autorisées via des rôles distincts avec moins d’autorisations. Pour plus d’informations, consultez Accorder des autorisations de processus (Analysis Services ).
Répertorier les rôles définis pour votre base de données
Les administrateurs peuvent exécuter une requête DMV simple dans SQL Server Management Studio pour obtenir la liste de tous les rôles définis sur le serveur.
Dans SSMS, cliquez avec le bouton droit sur une base de données et sélectionnez New Query | MDX.
Tapez la requête suivante et appuyez sur F5 pour exécuter :
Select * from $SYSTEM.DBSCHEMA_CATALOGSLes 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. À l’aide de ces informations comme point de départ, vous pouvez passer à des bases de données individuelles pour vérifier l’appartenance et les autorisations d’un rôle spécifique.
Aperçu général des autorisations dans Analysis Services de haut en bas
Cette section décrit le flux de travail de base pour la configuration des autorisations.
Étape 1 : Administration du serveur
Pour commencer, décidez qui aura des droits d’administrateur au niveau du serveur. Pendant l’installation, l’administrateur local qui installe SQL Server est tenu de spécifier un ou plusieurs comptes Windows en tant qu’administrateur de serveur Analysis Services. Les administrateurs de serveur disposent de toutes les autorisations possibles sur un serveur, notamment l’autorisation d’afficher, de modifier et de supprimer n’importe quel objet sur le serveur ou d’afficher les données associées. Une fois l’installation terminée, un administrateur de serveur peut ajouter ou supprimer des comptes pour modifier l’appartenance à ce rôle. Pour plus d’informations sur ce niveau d’autorisation, consultez Accorder des droits d’administrateur de serveur à une instance Analysis Services .
Étape 2 : Administration de base de données
Ensuite, après avoir créé une solution tabulaire ou multidimensionnelle, déployez-la sur le serveur en tant que base de données. Un administrateur de serveur peut déléguer des tâches d’administration de base de données en définissant un rôle disposant d’autorisations Contrôle total pour la base de données. Les membres de ce rôle peuvent traiter ou interroger des objets dans la base de données, ainsi que créer des rôles supplémentaires pour accéder à des cubes, des dimensions et d’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 au cube ou au modèle pour les charges de travail de requête et de traitement
Par défaut, seuls les administrateurs de serveur et de base de données ont accès aux cubes ou aux modèles tabulaires. Pour mettre ces structures de données à la disposition d’autres personnes de votre organisation, attribuez des rôles supplémentaires qui mappent Windows comptes d’utilisateur et de groupe à des cubes ou des modèles, ainsi que des autorisations qui spécifient des privilèges de lecture. Pour plus d'informations, veuillez consulter la section Accorder des autorisations sur un cube ou un modèle (Analysis Services).
Vous pouvez isoler les tâches de traitement d’autres fonctions administratives. Cette isolation permet aux administrateurs de serveurs et de bases de données de déléguer cette tâche à d’autres personnes, ou de configurer un traitement sans intervention en spécifiant des comptes de service qui exécutent un logiciel de planification. Pour plus d’informations, consultez Accorder des autorisations de traitement (Analysis Services).
Note
Les utilisateurs n'ont pas besoin d'autorisations pour les tables relationnelles dans la base de données relationnelle sous-jacente à partir de laquelle SQL Server Analysis Services charge ses données. Ils n'ont également pas besoin d'autorisations au niveau du fichier sur l'ordinateur sur lequel l'instance de SQL Server Analysis Services est en cours d'exécution.
Étape 4 (Facultatif) : Autoriser ou refuser l’accès aux objets de cube intérieur
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 varier les autorisations en fonction de l’identité de l’utilisateur. Cette variante est souvent appelée sécurité dynamique et est implémentée à l’aide de la fonction UserName (MDX ).
Meilleures pratiques
Pour mieux gérer les autorisations, utilisez une approche similaire aux étapes suivantes :
Créez des rôles par fonction (par exemple, dbadmin, cubedeveloper, processadmin) afin que les personnes qui conservent les rôles puissent voir en un clin d’œil ce que le rôle autorise. Comme indiqué ailleurs, vous pouvez définir des rôles dans la définition de modèle, préservant ainsi ces rôles sur les déploiements de solutions suivants.
Créez un groupe de sécurité Windows correspondant dans Active Directory, puis conservez le groupe de sécurité dans Active Directory pour vous assurer qu’il contient les comptes individuels appropriés. Cette approche place la responsabilité de l’appartenance au groupe de sécurité sur les spécialistes de la sécurité qui ont déjà une maîtrise des outils et des processus utilisés pour la maintenance des comptes dans votre organisation.
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 Octroyer des autorisations de cube ou de modèle (Analysis Services).
Adoptez une convention d’affectation de noms qui reflète l’étendue et l’appartenance au rôle. Les noms de rôles sont visibles uniquement dans les outils de conception et d’administration. Utilisez donc une convention d’affectation de noms qui est logique pour vos spécialistes de la sécurité de cube. Par exemple, processadmin-windowsgroup1 indique l’accès en lecture, ainsi que les droits de traitement, aux personnes de votre organisation dont les comptes d’utilisateur Windows individuels sont membres du groupe de sécurité windowsgroup1 .
L’inclusion des informations de compte peut vous aider à suivre les comptes utilisés dans différents rôles. Étant donné que les rôles sont additifs, les rôles combinés associés à windowsgroup1 constituent le jeu d’autorisations effectif pour les personnes appartenant à ce groupe de sécurité.
Les développeurs de cube nécessitent des autorisations Contrôle total pour les modèles et les bases de données en cours de développement, mais n’ont besoin d’autorisations de lecture qu’une fois qu’une base de données est déployée sur un serveur de production. N’oubliez pas de développer des définitions et des affectations de rôle pour tous les scénarios, notamment les déploiements de développement, de test et de 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 à une instance Analysis Services
Rôles et autorisations (Analysis Services)
Méthodologies d’authentification prises en charge par Analysis Services