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

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 Analysis Services est octroyé 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, octroient des autorisations de Lecture ou Lecture/Écriture sur des objets Analysis Services, puis assignent des groupes et des utilisateurs Microsoft Windows à chaque rôle.

Analysis Services détermine les autorisations effectives d'un utilisateur ou d'un groupe Windows en combinant les autorisations associées à chaque rôle de base de données auquel l'utilisateur ou le groupe appartient. 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 Analysis Services et les membres d'un rôle de base de données ayant des 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 de serveur Analysis Services ne peuvent pas être empêchés d'accéder aux objets d'une base de données, et les membres d'un rôle de base de données Analysis Services avec des autorisations Contrôle total (Administrateurs) dans une base de données ne peuvent pas être empêchés d'accéder aux objets de la base de données. Des opérations d'administration spécialisées, telles que les opérations de traitement, peuvent être autorisées par l'intermédiaire de rôles distincts ayant moins d'autorisations. Pour plus d'informations, consultez Octroyer des autorisations de traitement (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, puis 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. Durant l'installation, l'administrateur local qui installe SQL Server doit spécifier un ou plusieurs comptes Windows comme administrateur de serveur Analysis Services. Les administrateurs de serveur disposent de toutes les autorisations possibles sur un serveur, y compris l'autorisation d'afficher, de modifier et de supprimer tout objet sur le serveur ou d'afficher des 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 Octroyer des autorisations d'administration de serveur (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 des tâches d'administration de base de données en définissant un rôle qui dispose d'autorisations de 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 l'accès aux cubes, dimensions et autres objets dans la base de données. Pour plus d'informations, consultez Octroyer 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. La mise à disposition de ces structures de données pour d'autres membres de votre organisation requiert des assignations de rôles supplémentaires qui mappent des comptes d'utilisateurs et de groupes Windows à des cubes ou des modèles, ainsi que des autorisations qui spécifient des privilèges Read. Pour plus d'informations, consultez Octroyer des autorisations de cube ou de modèle (Analysis Services).

Les tâches de traitement peuvent être isolées des autres fonctions d'administration, ce qui permet aux administrateurs de serveur et de base de données de déléguer ces tâches à 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 Octroyer des autorisations de traitement (Analysis Services).

[!REMARQUE]

Les utilisateurs ne nécessitent pas d'autorisations pour accéder aux tables relationnelles de la base de données relationnelle sous-jacente à partir de laquelle Analysis Services charge ses données, et ils ne nécessitent pas non plus d'autorisations sur les fichiers de l'ordinateur sur lequel l'instance Analysis Services est exécutée.

Étape 4 (Facultative) : accorder ou refuser l'accès à des objets de cube intérieurs

Analysis Services fournit des paramètres de sécurité pour définir des autorisations sur des objets spécifiques, notamment des membres de dimension et des cellules dans un modèle de données. Pour obtenir des détails, consultez Octroyer un accès personnalisé à des données de dimension (Analysis Services) et Octroyer un accès personnalisé à des données de cellule (Analysis Services).

Vous pouvez également varier les autorisations en fonction de l'identité de l'utilisateur. On appelle cela la sécurité dynamique et on l'implémente à l'aide de la fonction UserName (MDX).

Meilleures pratiques

Pour mieux gérer les autorisations, nous vous suggérons d'adopter une approche semblable à la suivante :

  1. Créez des rôles par fonction (par exemple, adminbd, développeurcube, admintraitement) afin que toute personne qui assure la mise à jour des rôles puisse voir en un coup d'œil ce que le rôle autorise. Comme nous l'avons déjà mentionné, vous pouvez définir des rôles dans la définition du modèle et ainsi conserver ces rôles lors des déploiements de solution ultérieurs.

  2. Créez un groupe de sécurité Windows correspondant dans Active Directory, puis tenez ce groupe de sécurité à jour dans Active Directory pour vous assurer qu'il contient les comptes appropriés. L'appartenance au groupe de sécurité incombe ainsi à des spécialistes de la sécurité qui connaissent parfaitement les outils et processus utilisés pour la maintenance des comptes au sein de votre organisation.

  3. Générez des scripts dans SQL Server Management Studio afin de pouvoir rapidement répliquer les assignations 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).

  4. Adoptez une convention d'affectation de noms qui reflète l'étendue et l'appartenance au rôle. Les noms des rôles sont visibles uniquement dans les outils de conception et d'administration. Vous devez donc utiliser une convention d'affectation de noms logique aux yeux de vos spécialistes de la sécurité des cubes. Par exemple, admintraitement-groupewindows1 indique qu'un accès en lecture et des droits de traitement sont accordés aux membres de votre organisation dont le compte d'utilisateur Windows est membre du groupe de sécurité groupewindows1.

    Le fait d'inclure des informations sur les comptes peut aider à effectuer le suivi des comptes utilisés dans différents rôles. Les rôles étant additifs, les rôles combinés associés à groupewindows1 composent le jeu d'autorisations effectif pour les membres de ce groupe de sécurité.

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

L'adoption d'une approche telle que celle-ci minimise l'actualisation des définitions de rôles et des appartenances aux rôles dans le modèle, et fournit une visibilité des assignations de rôles qui simplifie l'implémentation et la maintenance des autorisations de cube.

Voir aussi

Tâches

Octroyer des autorisations d'administration de serveur (Analysis Services)

Concepts

Rôles et autorisations (Analysis Services)

Méthodologies d'authentification prises en charge par Analysis Services