2. Notions▲
2-1. Notions de base▲
Pour accéder à une base de données, un utilisateur utilise une connexion. Un utilisateur peut être soit une personne physique, soit une application (script, batch).
Une base contient de nombreux objets (tables, vues, procédures stockées, fonctions…). Pour entreprendre certaines actions sur ces objets (consulter, exécuter, modifier…) l'utilisateur doit avoir les privilèges (aussi appelés droits) nécessaires. L'utilisateur peut obtenir ces droits de manière directe ou indirecte.
Le principe de base est donc finalement très simple. La mise en place peut être un peu plus complexe, comme nous allons le voir.
2-2. Gestion des droits : principes▲
Dans cette section, nous allons comparer 2 implémentations pour la gestion des droits.
Pour que les exemples soient plus parlant, nous allons considérer une base de données avec :
- 10 utilisateurs aux droits différents suivant leur rôle
- 60 tables, vues, procédures stockées…
2-2-1. Implémentation naïve▲
Pour prendre conscience des problèmes que peut représenter une mauvaise gestion des droits, nous allons imaginer l'implémentation suivante, très simple (mais très naïve) :
- pour chaque objet (table, vue, procédure stockée) on affecte les droits de manière individuelle à chaque utilisateur
Cette implémentation posera les problèmes suivants :
- à chaque fois que l'on ajoute un objet dans la base, il faut affecter les droits pour chacun des 10 utilisateurs
- à chaque ajout d'un utilisateur, il faudra affecter les droits sur chacun des 60 objets de la base de données
En résumé, avec une implémentation aussi naïve , la gestion des droits est loin d'être aisée.
2-2-2. Implémentation plus efficace▲
Maintenant, considérons l'implémentation suivante :
- on définit la notion de rôle (= groupe d'utilisateurs partageant les mêmes droits)
- un utilisateur appartient à un ou plusieurs rôle(s)
- pour chaque objet de la base, on affecte les droits aux différents rôles. Tous les membres d'un rôle donné hériteront des droits du rôle
Avec cette implémentation :
- à chaque fois que l'on ajoute un objet dans la base, il suffit d'affecter les droits à 1 rôle pour que tous les utilisateurs du rôle bénéficient des droits d'accès
- lorsqu'on crée un nouvel utilisateur, il suffit de l'ajouter à 1 groupe d'utilisateurs (rôle) pour qu'il bénéficie de tous les droits du rôle
- pour changer les droits d'un utilisateur, il suffit de changer son appartenance aux différents rôles
La gestion des droits devient alors nettement plus facile !
2-2-3. Qu'est-ce qu'un rôle exactement ?▲
Un rôle, c'est un ensemble de responsabilités.
Dans une entreprise, les employés ont diverses responsabilités. Chacune de ces responsabilités s'accompagne d'un certain nombre de tâches et l'entreprise doit fournir à ses employés les moyens nécessaires pour accomplir leur mission. Par ailleurs les employés peuvent avoir plusieurs responsabilités et donc cumuler les tâches.
En base de données, le principe est similaire : un rôle représente un ensemble de responsabilités au sein de l'application. Chacune de ces responsabilités s'accompagne d'un certain nombre de tâches (sous la forme de procédures stockées, par exemple). Pour accomplir ces différentes tâches, les membres d'un rôle doivent pouvoir accéder à différentes données (au travers de vues, procédures stockées, etc.), ce qui implique d'avoir les droits nécessaires pour accéder à ces données.
Lors de l'analyse, on doit donc identifier:
- les utilisateurs (users)
- les responsabilités (rôles)
- les tâches à effectuer et les moyens d'accès aux données (procédures stockées, vue, tables...)
2-3. Gestion des droits : règles▲
Concernant la gestion des droits, quelques règles sont à respecter :
- Identifier les rôles
ainsi que les différents acteurs au sein de l'application - Donner le minimum de droits
Pour chaque rôle, on ne doit fournir que les droits nécessaires et suffisants à l'exécution des différentes tâches. - Interdire l'accès direct aux tables
Les tables sont le support de données et leur contenu ne devrait pas être accessible directement. Par exemple, une table "salarié" peut contenir des informations personnelles qui ne doivent être accessibles qu'à un petit groupe d'individus. C'est pourquoi on accède au contenu d'une table au moyen de vues, procédures stockées, fonctions, etc. Ceci permet également de spécifier si l'accès aux données se fait en lecture seule ou si elle autorise les modifications.
En résumé, pour accéder au contenu d'une table on crée une vue (ou une procédure stockée, ou une fonction) pour laquelle on affecte les droits aux différents rôles contenant plusieurs utilisateurs. Ceci permet un meilleur contrôle des accès. - Gérer les droits le plus tôt possible
Plus on gère les droits de manière précoce, plus cette gestion est aisée car l'ajout de droits se fait au fur et à mesure du développement, et non de manière hâtive à la fin.
Au début du développement, quelques rôles sont clairement identifiés et d'autres seront ajoutés par la suite. Idem pour les utilisateurs. A chaque ajout de fonctionnalité dans le programme, on assigne les droits nécessaires pour son exécution (si les droits ne sont pas suffisants, on s'en rend très vite compte : une exception est levée). De cette façon, on gère les droits très facilement et avec un effort réduit.
Dans la suite de cet article, nous allons découvrir comment, dans le cas d'une application .Net au développement bien avancé, identifier les appels aux objets de la base de données (vues, procédures stockées…) en vue d'assigner les droits.
2-4. Notions supplémentaires▲
2-4-1. Login / User▲
En SQL Server, on distingue d'un part la notion de login et d'autre part la notion de user.
Le login, c'est ce qui permet de se connecter à un serveur SQL Server.
Cependant un même serveur peut accueillir plusieurs bases de données et dans chacune de ces bases on définit différents users pour la gestion des droits. Il est ensuite nécessaire de faire le lien entre les logins et les users (ce que nous verrons par la suite)
2-4-2. Les Schémas▲
Auteur: rudib
Le schéma est un objet de base, au même titre que les tables. Il s'agit d'un objet intermédiaire entre le serveur et la table, qui est défini par la norme SQL. SQL Server implémentait très imparfaitement les schémas en 2000, et cette lacune a été corrigée en 2005.
Vous pouvez simplement considérer le schéma comme un espace de nom. C'est une sorte de coquille vide qui accueille des objets de base de données, tels que tables, vues, procédures, fonctions. A l'intérieur d'un schéma, un nom d'objet doit être unique. Vous pouvez par contr utiliser le même nom d'objet dans une base, s'il est dans un schéma différent.
Les schémas sont utiles pour la gestion des privilèges, car ils permettent de les attribuer sur l'étendue du schéma. Par exemple, permettre en une instruction l e privilège d'exécution sur toutes les procédures appartenant à un schéma.
2-4-3. Chaînage de propriétaire (ownership chaining)▲
Auteur: rudib
Un schéma appartient à un utilisateur de la base.
Dès lors qu'un objet de code, comme une fonction, un déclencheur, une procédure ou une vue, fait appel à des objets qui appartiennent au même utilisateur (donc, soit au même schéma, soit à des schémas qui ont le même propriétaire), les privilèges spécifiques de ces objets sous-jacents ne sont pas vérifiés par SQL Server. Il estime simplement que si un utilisateur a créé tous les objets, il sait ce qu'il fait dans son code, et donc, il ne va pas vérifier toute la chaîne des privilèges sur les objets.
Il s'agit d'une optimisation de performance, mais aussi d'une facilité pour gérer l'accès aux objets à travers procédures et vues : on donne des privilèges à ces objets seulement, et pas aux tables sous-jacentes, et donc on contrôle plus finement les accès (voir paragraphe suivant).
2-4-4. Vues et procédures stockées▲
Les vues et procédures stockées présentent plusieurs avantages pour le développeur.
Par exemple, les procédures stockées permettent de définir une suite d'instructions qui seront exécutées côté serveur (meilleure performance, limite la bande passante), en une seule transaction, et de manière paramétrable.
Du point de vue de la gestion des droits, l'utilisation de vues et de procédures stockées permettent un meilleur contrôle des droits. Par exemple, on autorise des utilisateurs à exécuter un procédure stockée mais on lui interdit l'accès direct aux données de la table.
De cette façon, le contrôle des droits d'accès s'effectue au niveau des vues et procédures stockées (qui représentent les "tâches" à effectuer au sein de la base).
Bien sûr, ceci n'est qu'une façon parmi d'autres de contrôler les droits en base de données. Par ailleurs, dans certains cas, il peut être tout à fait justifié d'autoriser les utilisateurs à accéder directement au contenu des tables. C'est le cas par exemple si, dans une application cliente .Net, on utilise des Dataset pour mettre à jour les tables.
Dans tous les cas, il est important d'essayer de n'affecter aux utilisateurs que les droits strictement nécessaires à l'exécution leurs différentes tâches. Toute disgression de cette règle doit être justifiée (ex: contraintes techniques).