Lors d’un des derniers projets auquel j’ai participé, nous avons eu à mettre en place une sécurité à la ligne. Rien d’extraordinaire en soi, mais c’est un bon cas d’étude pour comprendre comment fonctionne la sécurité entre les différentes briques de l’environnement SQL Server.

J’ai essayé de schématiser ça en 3 dessins Visio que je laisse en téléchargement par ici (C’est la première fois que j’utilise Google Document comme ça, mailez moi si ça ne marche pas).

Pour faire court :

• Un groupe d’administration accède à une interface ASP.NET qui lui permet de définir des couples Utilisateur / Périmètre. Le périmètre s’applique sur une hiérarchie organisation, il se compose d’un niveau et du code de l’entité à ce niveau.

• Le groupe d’utilisateur accède à un reporting qui utilise un cube et des données de la base. On doit lui appliquer la sécurité définit par les administrateurs.

Pour implémenter une sécurité à la donnée, on ne peut pas donner des droits DataReader/DataWriter aux utilisateurs sur la base. En effet la granularité minimale de la sécurité sur SQL Server c’est la table, ni la ligne ni la colonne.
Il va donc falloir utiliser des procédures stockées (droits GRANT EXECUTE) et joindre les résultats sur la table qui stocke les couples Utilisateur / Périmètre.
Pour le cube, il va falloir définir un rôle qui utilise cette même table.

Le point important dans tout ça, c’est que si votre configuration n’est pas mono-serveur, c’est-à-dire si votre service SSRS n’est pas installé sur le serveur qui héberge la base et/ou le cube, il va falloir mettre en place la délégation d’autorité en utilisant Kerberos. C’est en effet la seule manière de faire propager le UserId depuis le SSRS frontal jusqu’aux cubes et aux procédures stockées. Dans le cas contraire, ce sera le compte de service de SSRS qui se propagera jusqu’aux données.

On peut contourner ce pré-requis si on n’utilise pas de cube dans la solution. Pour ce faire, il suffit de transmettre la constante User !UserId de SSRS en paramètre à la procédure stockée appelée. Ce n’est pas la best practice, mais ça marche. Cette manipulation n’est pas possible pour SSAS puisque la gestion des droits est transparente dans le cube.

Voici le premier schéma, il présente une vue d’ensemble de la configuration:

Concernant la sécurité fonctionnelle, la sécurité à la ligne, on peut utiliser un jeu de tables comme cela pour l’implémenter:

Et enfin, pour utiliser tout ça, il faut employer les scripts suivants:

Rappel : si vous voulez le VSD de ces schémas, il suffit de remonter en haut de l’article.

Ne disposant pas de la science infuse, j’apprécierai sincèrement les éventuelles corrections / améliorations que vous auriez à proposer 🙂