SQL Server - Introduction à la Gestion des Droits

Voici un scénario courant lors de la mise en place d'un Système d'Information :

• au départ, on analyse les besoins utilisateur
• ensuite on identifie les différentes fonctionnalités (les tâches que l'application doit effectuer) et éventuellement quelques rôles (qui fait quoi dans l'application)
• lors du développement, on concentre ses efforts sur la mise en place des différentes fonctionnalités plutôt que sur la gestion des droits (les utilisateurs ayant une notion plutôt vague de ce qu'est la "sécurité", les chefs de projet préfèrent généralement les se concentrer sur le nombre de fonctionnalités implémentées)
• une fois le développement bien avancé, le chef de projet fait de la gestion des droits une priorité (parce que le mot "sécurité" revient à la mode au sein du service)

A partir de ce moment là, le développeur est confronté aux difficultés suivantes :

• le nombre d'objets en base et dont il faut sécuriser l'accès est généralement important
• l'analyse des besoins en termes de sécurité est souvent superficielle
• le développeur n'a que peu de temps pour implémenter les droits et a souvent d'autres choses à faire (tester l'application et corriger les bugs, entre autres…)

Toute ressemblance avec des situations existantes ou ayant existé serait loin d'être fortuite… C'est pourquoi il est nécessaire de disposer d'une méthode pour affecter les droits nécessaires et suffisant à une application existante. C'est justement le but de ce paragraphe, dans le cadre d'une application .Net.

La première étape consiste à dresser la liste des appels aux différents objets de la base de données à partir de l'application.

Sous Visual Studio 2005, on procède ainsi :

1. repérez dans le code un appel au constructeur de SqlCommand
2. effectuez un click droit au dessus du constructeur de SqlCommand. Un menu contextuel apparaît. Sélectionnez "Find All References" (1) dans ce menu
3. la liste de tous les appels au constructeur de SqlCommand apparaît alors.

Ceci permet de dresser la liste des requêtes SQL et des appels à des procédures stockées effectués par l'application, ainsi que le contexte dans lequel sont ces appels apparaissent. Connaissant cela, il est possible d'affecter les droits de manière précise.

La deuxième étape consiste à affecter les droits, c'est-à-dire que l'on définit quels rôles ont le droit d'accéder à quelles vues / tables (2) / procédure stockée.

Important :
Ceci tend à montrer qu'il est beaucoup plus facile de mettre en place une gestion des droits efficace si on la définit dès le départ et qu'on l'implémente au fur et à mesure du développement. Si on s'y prend trop tard, cela devient beaucoup plus difficile et laborieux (il faut relire tout le code à la recherche d'appels à des requêtes SQL à un moment critique où le temps vient à manquer).

Le but ici est d'affecter les droits en respectant la règle : "Pour chaque rôle, on ne doit fournir que les droits nécessaires et suffisants à l'exécution des différentes tâches".

Pour cela, nous allons utiliser deux connections différentes à la base de données : La première nous servira à affecter les droits La deuxième nous servira à vérifier les droits d'un utilisateur particulier

1. Ouvrez une première connexion (utilisateur dont on veut vérifier les droits) :

• cliquez sur "Connect"
• entrez les informations de connection (serveur, login, mot de passe...)

Sauf cas particuliers, les objets qui apparaissent sont ceux pour lesquels l'utilisateur connecté a les droits d'accès.

Si l'utilisateur a le droit VIEW DEFINITION (octroyé par l'instruction GRANT VIEW DEFINITION), l'utilisateur aura en plus la possibilité de voir des objets auxquels il n'a pas accès (c'est un des cas particuliers mentionné précédemment).

Si un objet n'apparaît pas, c'est que l'utilisateur n'a pas les droits suffisants. Nous allons donc ouvrir une autre connection afin d'affecter les droits manquants.

2. Ouvrez une deuxième connexion (utilisateur avec pouvoirs) :

• cliquez sur "Connect"
• loguez-vous en tant que super utilisateur ("sa", ou autre utilisateur avec pouvoirs)

Grâce à cette connexion, il est possible de gérer les droits (voir section 3 sur la Gestion des droits)

Après avoir modifiez les droits, vous pouvez vérifier que l'utilisateur en question a bien accès aux objets désirés. Pour cela, sélectionnez la première connexion (utilisateur dont on veut vérifier les droits), et rafraîchissez l'affichage (bouton droit > Propriétés > Refresh).

Grâce à cette technique (utilisation de deux connexions : l'une pour affecter les droits, l'autre pour vérifier que les droits affectés sont les bons), il est possible d'affecter les droits de manière très fine (et de ne donner que les droits nécessaires).

Dans SQL Server, il existe un certain nombre de vues systèmes qui permettent de connaître les droits affectés. Par exemple grâce aux vues sys.database_principals et sys.database_role_members, il est possible de savoir à quels rôles appartiennent les différents utilisateurs.

Ceci peut se révéler utile au niveau applicatif : en fonction des différents rôles attribués, on peut activer ou désactiver certaines options dans l'interface utilisateur.