Octroi d'accès personnalisés aux données d'une dimension

Article
12/15/2008

Mis à jour : 12 décembre 2006

Après qu'un rôle de base de données Microsoft SQL Server 2005 Analysis Services (SSAS) a accordé une autorisation de lecture ou de lecture/écriture sur les dimensions d'un cube, vous pouvez définir la sécurité de chaque membre d'attribut de la dimension (appelée sécurité de dimension). Par défaut, un rôle de base de données accède à tous les membres de tous les attributs de dimension d'un cube pour lesquels ils disposent d'un accès en lecture. Vous pouvez définir un ensemble spécifique de membres d'attribut pour chaque attribut de dimension pour lequel les membres du rôle bénéficient de droits d'accès spécifiques (AllowedSet) ou pour lesquels les droits d'accès leur sont spécifiquement refusés (DeniedSet). Vous pouvez aussi définir le membre par défaut pour chaque hiérarchie d'attribut ; le membre par défaut est le membre Tous. Si vous refusez l'autorisation de lecture à certains membres d'attribut, il se peut que vous souhaitiez que la valeur du membre Tous soit l'agrégation des membres auxquels les membres du rôle ont accès, plutôt que celle de tous les membres de la hiérarchie d'attribut. Pour spécifier ce comportement, activez VisualTotals. Quand vous activez VisualTotals, l'agrégation est calculée au moment de la requête au lieu d'être extraite d'agrégations précalculées.

Remarque :
Le type d'accès dont disposent les membres d'un rôle sur une dimension dépend de l'accès accordé sur la dimension, c'est-à-dire lecture ou écriture/lecture.

Description de la propriété IsAllowed

La propriété IsAllowed détermine si le rôle de base de données peut accéder aux membres d'un attribut. Par défaut, un rôle de base de données qui peut accéder à une dimension ne peut pas accéder aux hiérarchies d'attributs.

Description de la propriété AllowedSet

La propriété AllowedSet utilise une expression MDX (Multidimensional Expressions) pour déterminer les membres d'attribut que peut afficher le rôle de base de données (jeu autorisé). Le jeu autorisé peut inclure certains membres d'un attribut, tous les membres d'un attribut ou bien aucun membre d'un attribut (valeur par défaut). Si vous autorisez l'accès à un attribut et ne définissez pas les membres du jeu autorisé, tous les membres sont accessibles. Si vous autorisez l'accès à un attribut et définissez un jeu de membres d'attribut, seuls les membres autorisés définis sont visibles. La définition d'un jeu autorisé peut limiter la visibilité des membres d'un attribut ajoutés après avoir défini un jeu autorisé.

La limitation du jeu autorisé d'un attribut affecte la visibilité des autres attributs. Supposons que le jeu autorisé de l'attribut Customer contienne uniquement certains membres et que le jeu autorisé de l'attribut City contienne tous les membres de l'attribut. Dans ce cas, les seuls membres de l'attribut City qui seront visibles sont les villes ayant des clients dans le jeu autorisé de l'attribut Customer. S'il existe une ville sans clients, les membres de l'attribut de la ville ne sont pas visibles. En d'autres termes, un membre d'attribut ne peut être visible que si le membre existe avec au moins un membre du jeu autorisé.

Remarque :
Si vous définissez un jeu vide de membres d'attribut, aucun membre de l'attribut n'est visible pour le rôle de base de données. Un jeu autorisé absent ne correspond pas à un jeu vide.

Description de la propriété DeniedSet

La propriété DeniedSet utilise une expression MDX pour déterminer les membres d'un attribut auxquels un rôle de base de données ne peut pas explicitement accéder (jeu refusé). Le jeu refusé peut inclure tous les membres d'un attribut (valeur par défaut), certains membres d'un attribut ou bien aucun membre d'un attribut. Par défaut, aucun jeu refusé n'est défini.

Lorsque le jeu refusé contient uniquement un jeu de membres d'attribut spécifiques, le rôle de données ne peut pas accéder à ces membres uniquement. La définition d'un jeu refusé peut affecter l'accessibilité des membres d'attribut ajoutés après avoir défini le jeu refusé.

Lorsque vous définissez un jeu d'attributs dans le jeu refusé, l'impact du jeu refusé sur l'accessibilité des autres attributs diffère selon que la propriété ApplyDenied est activée ou non. Supposons qu'un jeu refusé existe dans l'attribut State et que la propriété ApplyDenied soit activée. Dans ce cas, le rôle de base de données ne peut pas accéder aux attributs Customer pour ces états dans le jeu refusé.

Description de la propriété ApplyDenied

La propriété ApplyDenied indique si les membres d'un jeu refusé sont utilisés pour déterminer si les membres d'une hiérarchie d'attribut sont accessibles au rôle de base de données. Par défaut, la propriété ApplyDenied a la valeur True (activée) pour chaque hiérarchie d'attribut.

Remarque :
Contrairement au jeu refusé dont l'impact dépend de la propriété ApplyDenied, le jeu autorisé est toujours appliqué pour déterminer si les membres d'une hiérarchie d'attribut sont accessibles au rôle de base de données.

Lorsque la propriété ApplyDenied est activée et qu'il existe un jeu refusé, le rôle de base de données ne peut pas accéder aux membres d'une hiérarchie d'attribut si la hiérarchie contient des membres du jeu refusé. Supposons que la propriété ApplyDenied soit activée et que le jeu refusé soit constitué des états de l'attribut State. Le rôle de base de données non seulement ne peut pas accéder à l'attribut State, mais il ne peut pas accéder non plus à l'attribut Customers des états du jeu refusé.

Lorsque la propriété ApplyDenied est désactivée et qu'il existe un jeu refusé, le rôle de base de données peut accéder aux membres d'une hiérarchie d'attribut, même si la hiérarchie contient des membres du jeu refusé. Supposons que la propriété ApplyDenied soit désactivée et que le jeu refusé soit constitué des états de l'attribut State. Bien que le rôle de base de données ne puisse pas accéder à l'attribut State, il peut toujours accéder à l'attribut Customers des états du jeu refusé.

Description de la propriété VisualTotals

La propriété VisualTotals indique si les valeurs de cellules agrégées affichées sont calculées en fonction de toutes les valeurs de cellules ou en fonction des valeurs de cellules auxquelles le rôle de base de données peut accéder.

Par défaut, la propriété VisualTotals est désactivée (affectée de la valeur False). Cette valeur par défaut optimise les performances, car Analysis Services peut calculer rapidement le total de toutes les valeurs de cellules au lieu de sélectionner les valeurs de cellules à calculer.

Toutefois, la désactivation de la propriété VisualTotals peut créer un problème de sécurité si un utilisateur peut utiliser les valeurs de cellules agrégées pour déduire les membres d'attribut auxquels le rôle de base de données ne peut pas accéder. Par exemple, Analysis Services utilise les valeurs de trois membres d'attribut pour calculer une valeur de cellule agrégée. Le rôle de base de données peut afficher deux de ces membres. En utilisant la valeur de cellule agrégée, un membre de ce rôle de base de données peut déduire la valeur du troisième membre de l'attribut.

Si l'utilisateur peut déduire les valeurs des membres de l'attribut auxquels son rôle de base de données n'a pas accès, la meilleure pratique de sécurité veut que vous activiez (valeur True) la propriété VisualTotals de l'attribut. Lorsque vous activez la propriété VisualTotals, un rôle de base de données peut uniquement afficher les totaux agrégés des membres de la dimension sur lesquels il dispose d'une autorisation. Par exemple, l'activation de la propriété VisualTotals implique que le rôle de base de données peut afficher un total agrégé qui contient uniquement les états (c'est-à-dire les membres de l'attribut State) auquel le rôle peut accéder. Le total agrégé ne contient pas les valeurs de tous les états.

Description de la propriété DefaultMember

La propriété DefaultMember détermine l'ensemble de données retourné au client lorsqu'un attribut n'est pas explicitement inclus dans une requête. Lorsque l'attribut n'est pas inclus explicitement, Analysis Services utilise les membres par défaut suivants pour l'attribut :

Si le rôle de base de données définit un membre par défaut pour l'attribut, Analysis Services utilise le membre par défaut.
Si le rôle de base de données ne définit pas un membre par défaut pour l'attribut, Analysis Services utilise le membre par défaut défini pour l'attribut lui-même. Le membre par défaut d'un attribut, sauf indication contraire, est le membre All (si l'attribut n'est pas défini comme ne pouvant pas faire l'objet d'une agrégation).

Par exemple, un rôle de base de données définit Male comme membre par défaut de l'attribut Gender. Si une requête n'inclut pas explicitement l'attribut Gender et ne définit pas un membre différent pour l'attribut, Analysis Services retourne un ensemble de données qui inclut uniquement les clients hommes. Pour plus d'informations sur la définition du membre par défaut, consultez Définition d'un membre par défaut.

Définition des autorisations d'accès à un membre d'une dimension

Avant de définir des autorisations d'accès à un membre d'une dimension, vous pouvez consulter des exemples de l'impact de différents paramètres d'accès sur l'ensemble de résultats retourné lors de l'interrogation des membres. Les rubriques suivantes fournissent ces exemples de paramètres :

Après avoir identifié le fonctionnement des diverses autorisations d'accès, vous pouvez accorder des autorisations. Pour accorder des autorisations d'accès à un membre d'une dimension, l'utilisateur doit être membre du rôle de serveur Analysis Services ou membre d'un rôle de base de données Analysis Services disposant des autorisations Contrôle total (Administrateur).

Lorsque vous utilisez Business Intelligence Development Studio pour accorder des autorisations d'accès à un membre d'une dimension, vous devez utiliser les options standard de l'onglet De base de l'onglet Données de la dimension, ou utiliser les options plus personnalisées de l'onglet Avancé.

Important :
Si un utilisateur ou groupe Microsoft Windows appartient à plusieurs rôles de base de données, les autorisations effectives de l'utilisateur ou du groupe sont additives dans tous les rôles de base de données (union d'autorisations). Si un rôle de base de données empêche l'utilisateur d'accéder à un membre d'attribut et qu'un autre rôle de base de données permet à l'utilisateur d'accéder à ce membre, l'utilisateur peut accéder au membre.

Si un utilisateur ou groupe Microsoft Windows appartient à plusieurs rôles de base de données, les autorisations effectives de l'utilisateur ou du groupe sont additives dans tous les rôles de base de données (union d'autorisations). Si un rôle de base de données empêche l'utilisateur d'accéder à un membre d'attribut et qu'un autre rôle de base de données permet à l'utilisateur d'accéder à ce membre, l'utilisateur peut accéder au membre.

Pour utiliser l'onglet De base pour permettre à un rôle de base de données d'accéder à un membre d'une dimension

Dans SQL Server Management Studio, connectez-vous à l'instance Analysis Services, développez Rôles pour la base de données appropriée dans l'Explorateur d'objets, puis cliquez sur un rôle de base de données (ou créez un rôle de base de données).
Cliquez sur Données de la dimension dans le volet Sélectionner une page, sélectionnez la dimension dans la liste Dimension, puis sélectionnez Autoriser l'attribut dans l'onglet Avancé.

La sélection de cette option affecte à la propriété IsAllowed la valeur True.
Dans la liste Attribut, sélectionnez l'attribut dont vous voulez définir les membres que peut afficher le rôle de base de données.
Pour refuser l'accès à certains membres de l'attribut, entrez l'expression MDX des membres de l'attribut dans la zone Jeu de membres refusé. Tous les autres membres sont accessibles.
- Pour accorder l'accès uniquement à certains membres, entrez l'expression MDX des membres de l'attribut dans la zone Jeu de membres autorisé. Aucun autre membre n'est accessible.

Pour utiliser l'onglet Avancé pour permettre à un rôle de base de données d'accéder à un membre d'une dimension

Dans SQL Server Management Studio, connectez-vous à l'instance Analysis Services, développez Rôles pour la base de données appropriée dans l'Explorateur d'objets, puis cliquez sur un rôle de base de données (ou créez un rôle de base de données).
Cliquez sur Accès aux données personnalisées de la dimension dans le volet Sélectionner une page, sélectionnez la dimension dans la liste Dimension, puis sélectionnez Autoriser l'attribut dans l'onglet Avancé.

La sélection de cette option affecte à la propriété IsAllowed la valeur True.
Dans la liste Attribut, sélectionnez l'attribut dont vous voulez définir les membres que peut afficher le rôle de base de données.
Pour refuser l'accès à certains membres de l'attribut, entrez l'expression MDX des membres de l'attribut dans la zone Jeu de membres refusé. Tous les autres membres sont accessibles.

Pour accorder l'accès uniquement à certains membres, entrez l'expression MDX des membres de l'attribut dans la zone Jeu de membres autorisé. Aucun autre membre n'est accessible.

Voir aussi

Historique des modifications

Version	Historique
12 décembre 2006	Contenu modifié : Clarification de l'architecture de sécurité par défaut.

Partager via