Sécurité des données dans l’environnement SQL Server

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:

Vue d'ensemble de la sécurité

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

Définition de la sécurité

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

Utilisation de la sécurité

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 🙂

3 commentaires sur « Sécurité des données dans l’environnement SQL Server »

  1. Je recommande ce très bon site pour Kerberos :
    http://www.kerberos.fr/

    Comme dirait Florence : « La force de Kerberos réside pour nous dans la qualité de sa relation clients, sa réactivité et son écoute pour que ses produits correspondent aux besoins réels de ses clients. »

  2. Pour les gens perdus qui lisent les commentaires, le Kerberos de DJ Über n’a rien à voir avec le Kerberos évoqué dans l’article…

    Merci DJ pour la confusion 🙂

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s