SQL Server - Introduction à la Gestion des Droits


précédentsommaire

4. En pratique

4.1. Répertorier les droits pour une application .Net existante

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



4.2. Affecter les droits suffisants

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



4.3. Connaître les droits au niveau applicatif

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.



Conclusion

Avec cet article, j'espère vous avoir convaincu de l'importance de la gestion des droits en base de données, mais surtout que la mise en place d'une bonne gestion des droits est grandement facilitée si celle-ci est mise en place dès le début du développement.

Je vous ai également donné les moyens de faciliter la gestion des droits:

  • définition de rôles
  • ajout des droits, création des rôles au fur et à mesure du développement
  • vérification que pour un rôle donné, on a bien les droits nécessaires et suffisants à l'exécution des différentes tâches

Maintenant, vous devriez avoir toutes les clefs en main pour mettre en place une gestion correcte des droits sans que cela nuise à la productivité.



Remerciements

Je tiens à remercier rudib et fadace pour leur contribution lors de la relecture de l'article.


précédentsommaire
Dans les versions de Visual Studio antérieures à 2005, on ne dispose malheureusement pas de la fonctionnalité "Find All References", ce qui complique énormément la tâche.
Comme expliqué en section 2.4.4, il est souvent préférable d'utiliser des vues et procédures stoquées plutôt que d'accéder directement au contenu des tables (on peut ainsi définir plus finement les droits d'accès). Néanmoins, dans la pratique, ce cas est très répandu.

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

  

Copyright © 2007 pcaboche. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.