Octroyer un accès personnalisé à des données de dimension (Analysis Services)

Après avoir activé l'accès en lecture à un cube, vous pouvez définir des autorisations supplémentaires qui accordent ou refusent explicitement l'accès aux membres de dimension (y compris les mesures contenues dans la dimension de mesures contenant toutes les mesures utilisées dans un cube). Par exemple, s'il existe plusieurs catégories de revendeurs, vous pourriez définir des autorisations pour exclure les données liées à un type d'activité spécifique. L'illustration ci-dessous montre l'effet avant/après du refus de l'accès au type d'activité Warehouse dans la dimension Reseller.

Par défaut, si vous pouvez lire les données d'un cube Analysis Services, vous disposez automatiquement d'autorisations d'accès en lecture pour toutes les mesures et tous les membres de dimension associés à ce cube. Bien que ce comportement puisse suffire pour de nombreux scénarios, les exigences de sécurité nécessitent parfois une stratégie d'autorisation plus segmentée, avec différents niveaux d'accès pour différents utilisateurs sur la même dimension.

Vous pouvez restreindre l'accès en choisissant les membres auxquels accorder (AllowedSet) ou refuser (DeniedSet) l'accès. Pour cela, vous devez sélectionner ou désélectionner les membres de dimension à inclure ou à exclure du rôle.

La sécurité de dimension de base est la plus simple ; il vous suffit de sélectionner les attributs de dimension et les hiérarchies d'attributs à inclure ou à exclure du rôle. La sécurité avancée est plus complexe et nécessite des compétences d'écriture de scripts MDX. Les deux approches sont décrites ci-dessous.

Configuration préalable requise

Vous ne pouvez pas utiliser toutes les mesures, ni tous les membres de dimension dans les scénarios d'accès personnalisés. Une connexion échoue si un rôle restreint l'accès à une mesure ou un membre par défaut, ou s'il restreint l'accès à des mesures qui font partie d'expressions de mesure.

Vérifier les obstructions en matière de dimension : mesures par défaut, membres par défaut et mesures utilisées dans les expressions de mesure

1. Dans SQL Server Management Studio, cliquez avec le bouton droit sur un cube, puis sélectionnez Générer un script du cube en tant que. | ALTER To | Nouvelle fenêtre d'éditeur de requête.

2. Recherchez DefaultMeasure. Vous devriez en trouver une pour le cube, et une pour chaque perspective. Quand vous définissez la sécurité des dimensions, évitez de restreindre l'accès aux mesures par défaut.

3. Recherchez ensuite MeasureExpression. Une expression de mesure est une mesure basée sur un calcul, qui inclut souvent d'autres mesures. Vérifiez que la mesure que vous souhaitez restreindre n'est pas utilisée dans une expression. Sinon, continuez et limitez l'accès. Toutefois, veillez à exclure également toutes les références à cette mesure dans l'ensemble du cube.

4. Enfin, recherchez DefaultMember. Notez tous les attributs qui servent de membre par défaut à un attribut. Évitez d'appliquer des restrictions à ces attributs quand vous définissez la sécurité des dimensions.

Sécurité de dimension de base

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

   Le rôle doit déjà avoir un accès en lecture au cube. Si vous avez besoin d'aide pour cette étape, consultez Octroyer des autorisations de cube ou de modèle (Analysis Services).

2. Dans Données de la dimension | De base, sélectionnez la dimension pour laquelle vous définissez des autorisations.

3. Choisissez la hiérarchie d'attribut. Les attributs ne seront pas tous disponibles. Seuls les attributs ayant AttributeHierarchyEnabled figurent dans la liste Hiérarchie d'attribut.

4. Choisissez les membres auxquels accorder ou refuser l'accès. L'autorisation de l'accès, par l'intermédiaire de l'option Sélectionner tous les membres, est le choix par défaut. Nous vous suggérons de conserver ce paramètre par défaut, puis d'effacer chaque membre qui ne doit pas être visible par les comptes d'utilisateurs et de groupes Windows dans le volet Appartenance via ce rôle. Cela a comme avantage que les nouveaux membres ajoutés aux opérations de traitement ultérieures sont automatiquement accessibles aux personnes qui se connectent à l'aide de ce rôle.

   En guise d'alternative, vous pouvez Désélectionner tous les membres pour refuser tout accès, puis sélectionner les membres auxquels accorder l'accès. Lors des opérations de traitement ultérieures, les nouveaux membres ne seront visibles qu'une fois que vous aurez modifié manuellement la sécurité des données de dimension pour leur accorder l'accès.

5. Si vous le souhaitez, cliquez sur Avancé pour Activer les valeurs totales affichées pour cette hiérarchie d'attribut. Cette option recalcule les agrégats en fonction des membres disponibles à l'aide du rôle.

   [!REMARQUE]

   Lors de l'application d'autorisations qui excluent des membres de dimension, les totaux agrégés ne sont pas recalculés automatiquement. Supposez que le membre All d'une hiérarchie d'attribut retourne le nombre 200 avant l'application des autorisations. Après l'application des autorisations qui refusent l'accès à certains membres, All retourne toujours 200, bien que les valeurs des membres visibles par l'utilisateur soient largement inférieures. Pour éviter toute confusion de la part des consommateurs de votre cube, vous pouvez configurer le membre All pour qu'il soit simplement l'agrégat des membres de ce rôle, plutôt que l'agrégat de tous les membres de la hiérarchie d'attribut. Pour implémenter ce comportement, vous pouvez activer Visual Totals sous l'onglet Avancé lors de la configuration de la sécurité de dimension. Une fois cette option activée, l'agrégat est calculé au moment de la requête au lieu d'être extrait à partir d'agrégats précalculés. Cela peut avoir un effet sensible sur les performances de requête. À utiliser uniquement en cas de nécessité.

Masquage de mesures

Dans Octroyer un accès personnalisé à des données de cellule (Analysis Services), nous avons expliqué que le masquage complet de tous les aspects visuels d'une mesure, et non simplement de ses données de cellules, nécessitait des autorisations sur les membres de dimension. Cette section explique comment refuser l'accès aux métadonnées d'objets d'une mesure.

1. Dans Données de la dimension | De base, faites défiler la page jusqu'à atteindre les dimensions de cube, puis sélectionnez Dimension de mesures.

2. Dans la liste des mesures, décochez la case des mesures qui ne doivent pas être visibles par les utilisateurs qui se connectent à l'aide de ce rôle.

[!REMARQUE]

Vérifiez les conditions préalables pour apprendre à identifier les mesures qui peuvent perturber la sécurité du rôle.

Sécurité de dimension avancée

Si vous connaissez MDX, une autre approche consiste à écrire des expressions MDX qui définissent les critères d'autorisation ou de refus d'accès aux membres. Cliquez sur Créer un rôle | Données de la dimension | Avancé pour fournir le script.

Vous pouvez utiliser le Générateur MDX pour écrire l'instruction MDX. Pour plus d'informations, consultez Boîte de dialogue Générateur MDX (Analysis Services - Données multidimensionnelles). L'onglet Avancé contient les options suivantes :

• Attribut
  Sélectionnez l'attribut dont vous voulez gérer la sécurité des membres.

• Jeu de membres autorisé
  Le jeu autorisé (AllowedSet) peut inclure aucun membre (valeur par défaut), tous les membres ou certains membres. 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 spécifique, seuls les membres autorisés de manière explicite sont visibles.

  La création d'un AllowedSet a un effet de cascade lorsque l'attribut participe à une hiérarchie multiniveau. Par exemple, supposez qu'un rôle accorde l'accès à l'état de Washington (dans un scénario où le rôle accorde des autorisations à la division de ventes de l'état de Washington d'une société). Pour les personnes qui se connectent avec ce rôle, les requêtes qui comprennent des ancêtres (États-Unis) ou des descendants (Seattle et Redmond) ne verront que les membres d'une chaîne incluant l'état de Washington. Les autres états n'étant pas autorisés de manière explicite, l'effet sera le même que s'ils étaient refusés.

  [!REMARQUE]

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

• Jeu de membres refusé
  La propriété DeniedSet peut être aucun membre, tous les membres (valeur par défaut) ou certains membres d'attribut. Lorsque le jeu refusé contient uniquement un jeu de membres d'attribut spécifiques, le rôle de base de données se voit refuser l'accès à ces membres uniquement, ainsi qu'aux descendants si l'attribut est dans une hiérarchie multiniveau. Prenez l'exemple de division des ventes de l'état de Washington. Si Washington est placé dans le DeniedSet, les personnes qui se connectent à l'aide de ce rôle verront d'autres états à l'exception de Washington et de ses attributs descendants.

  Rappelez-vous ce que nous avons vu dans la section précédente : le jeu refusé est une collection fixe. Si le traitement introduit par la suite de nouveaux membres auxquels l'accès doit également être refusé, vous devrez modifier ce rôle pour ajouter ces membres à la liste.

• Membre par défaut
  La propriété DefaultMember détermine le jeu 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, supposez qu'un rôle de base de données spécifie 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éfinir un membre par défaut.

• Activer les valeurs visibles
  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.

  L'affectation de la valeur True à la propriété VisualTotals peut éliminer ce risque. 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.

• Vérification
  Cliquez pour tester la syntaxe MDX définie dans cette page.

Voir aussi

Tâches

Octroyer des autorisations sur des modèles et des structures d'exploration de données (Analysis Services)

Octroyer des autorisations sur un objet de source de données (Analysis Services)

Concepts

Octroyer des autorisations de cube ou de modèle (Analysis Services)

Octroyer un accès personnalisé à des données de cellule (Analysis Services)