Partager via


Autorisation de l’accès aux objets et aux opérations (Analysis Services)

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

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 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, l’utilisateur ou le groupe aura l’autorisation d’afficher l’objet.

Important

Les membres du rôle Administrateur du serveur 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 Analysis Services ne peuvent pas être refusés d’accéder à un objet dans n’importe quelle base de données, et les membres d’un rôle de base de données Analysis Services disposant d’autorisations Contrôle total (Administrateur) au sein d’une base de données ne peuvent pas être refusés à 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 ayant moins d’autorisation. 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.

  1. Dans SSMS, cliquez avec le bouton droit sur une base de données et sélectionnez New Query | MDX.

  2. Tapez la requête suivante et appuyez sur F5 pour 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. À 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.

Vue d’ensemble descendante de l’autorisation Analysis Services

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 autorisations d’administrateur de serveur (Analysis Services ).

Étape 2 : Administration de base de données

Ensuite, une fois qu’une solution tabulaire ou multidimensionnelle est 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 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 en question. 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 rendre disponibles ces structures de données à d'autres personnes de votre organisation, il est nécessaire d'effectuer des attributions de rôles supplémentaires qui associent les comptes d'utilisateur et de groupe Windows aux cubes ou aux modèles, ainsi que des autorisations qui spécifient les 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 administratives, 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 le traitement sans assistance en spécifiant des comptes de service qui exécutent des logiciels de planification. Pour plus d’informations, consultez Accorder des autorisations de processus (Analysis Services ).

Remarque

Les utilisateurs n’ont pas besoin d’autorisations pour les tables relationnelles dans la base de données relationnelle sous-jacente à partir de laquelle Analysis Services charge ses données et ne nécessitent aucune autorisation de niveau de fichier sur l’ordinateur sur lequel l’instance d’Analysis Services est en cours d’exécution.

Étape 4 (Facultatif) : Autoriser ou refuser l’accès aux objets de cube intérieur

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é de l’utilisateur. Il s’agit souvent de la sécurité dynamique et est implémenté à l’aide de la fonction UserName (MDX)

Meilleures pratiques

Pour mieux gérer les autorisations, nous vous suggérons d’adopter une approche similaire à ce qui suit :

  1. 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.

  2. 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. Cela place la responsabilité de l’appartenance au groupe de sécurité sur les spécialistes de la sécurité qui sont déjà compétents avec les outils et les processus utilisés pour 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. Consultez Accorder des autorisations de cube ou de modèle (Analysis Services) pour savoir comment générer rapidement un script.

  4. 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é.

  5. 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.

L'utilisation d'une approche semblable à celle-ci minimise le turnover dans les définitions de rôles et l'appartenance aux rôles dans le modèle, et offre une visibilité sur les attributions de rôles, ce qui facilite l'implémentation et la maintenance des autorisations concernant le cube.

Voir aussi

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