Configuration des droits d’accès aux cubes Olap SSAS 1ère partie

Il peut-être nécessaire de configurer correctement des accès aux cubes Olap SSAS, ne pas donner trop de droits à des utilisateurs qui n’ont besoin que des accès en lecture et inversement.
Nous allons donc voir comment donner accès aux données SQL au compte de service SQL, puis une configuration de base pour les accès aux cubes Olap.

Accès à la base SQL

Si vous venez d’installer votre instance SQL Server avec le serveur SSIS (Integration Services), vous devrez donner accès en lecture au compte de service SSIS à la base de données SQL contenant les données sources de vos cubes Olap SSAS.

Pour ceux qui n’ont pas touché à la configuration de base, le compte par défaut est NT SERVICE\MSSQLServerOLAP Service.

En cas de doute, vous pouvez vérifier le compte de service dans le Panneau de Configuration->Outils d’Administrations-> Services -> SQL Server Analysis Services.

Le bon compte de service retrouvé, vous pourrez créer une nouvelle Connexion dans la partie sécurité de votre base de données avec les rôles publics et db_datareader.

Le cube ne faisant que lire les données de la base, les droits de lecture sont suffisants :

Pour les plus feignants, en ligne de commande :
EXEC sp_addrolemember 'db_datareader', 'NT Service\MSSQLServerOLAPService'

Configuration des accès aux Cubes Olap SSAS

Les accès aux cubes peuvent être gérés à la cellule, ce qui donne des possibilités quasi infinies, nous allons dans un premier temps voir une configuration basique couvrant une grande majorité des cas d’utilisation. Il est évidemment possible de créer d’autres groupes avec des droits plus spécifiques selon les besoins.
Pour des utilisations simples, avec des développeurs et des utilisateurs ayants accès à la totalité des informations, deux ou trois groupes suffiront :

Rôle Admin

Destiné aux développeurs et administrateurs du serveur qui auront un accès total sur le cube.
La configuration est simple, après avoir créé le rôle, il suffira de cocher les cases « Contrôle total », « Traiter la base de données » et « Lire la définition » dans la section « Général » des propriétés :

Rôle Reader

Destiné aux utilisateurs du cube qui ne devront avoir aucun contrôle sur la structure du cube, mais uniquement un accès en lecture aux données du cube.
Dans général, toutes les options devront être décochées :

C’est dans la partie « Cubes » que vous donnerez accès en lecture aux données des différents Cubes de votre base :

Rôle Writer

Peut-être un peu moins fréquent, si vous utilisez les fonctions d’écriture dans le cube pour des commerciaux devant renseigner leurs chiffres prévisionnels ou autre, vous pouvez créer un rôle spécifique, le seul changement par rapport au rôle « Reader » sera dans la partie « Cube », où les accès seront en Lecture/Ecriture et avec la possibilité de retraiter le cube si des champs calculés se basent sur ces chiffres :

Autres possibilités

Il sera possible de moduler ces rôles ou d’en créer de nouveaux en fonction des besoins :

• Autoriser le rôle reader à lire la définition du cube pour des utilisateurs confirmés, ce qui leur permettra de vérifier directement comment sont construits les champs calculés, dimensions… Mais on arrive sur des utilisateurs développeurs qui sont assez rares.
• Il est possible de limiter les droits d’accès aux données d’un cube ou d’une dimension :
  • Données des cellules : permet de limiter l’accès à certaines cellules, la configuration se fera en MDX,
  • Dimensions : Gestion des droits en lecture/écriture sur les dimensions du cube,
  • Données de la dimension : permet de limiter l’accès à certaines données d’une dimension.

Il est donc possible de limiter à tous les niveaux les accès à un cube et à ses données. Attention toutefois, car plus les limitations à la cellule ou sur les dimensions seront complexes plus les temps de réponse du cube seront longs, celui-ci devant vérifier à chaque opération si l’utilisateur à les droits suffisants pour accéder aux données.

Must have

Si votre société possède un active directory, il est essentiel qu’aucun nom d’utilisateur ne soit visible directement dans les rôles du cube, mais que les accès soient gérés via des groupes de sécurités, ce qui permet de décharger le DBA de la gestion des droits d’accès aux cubes et donc une autonomie totale des utilisateurs une fois le système en place.

Conclusion

Les cubes sont très permissifs au niveau des droits d’accès, mais bien configurés et combinés à de l’active directory, il est possible de rendre totalement autonome les utilisateurs et gagner un temps précieux.
Il est donc important de passer un peu de temps à définir les différents niveaux d’utilisation du cube et mettre en place les différents rôles associés.