Politique de gestion des droits d'accès à une base de donnéesDate de publication : 26/08/2006 , Date de mise à jour : 30/08/2006
Par
Hugo Etiévant (Le CyberZoïde Qui Frétille)
Cet article aborde le problème de la gestion des droits d'accès à une base de données par les utilisateurs, les applications
et les administrateurs.
I. Introduction à la sécurité
II. Les risques encourus
III. La politique de gestion des privilèges
A. Les types d'utilisateurs
B. Contrôle des privilèges
C. Les privilèges
1. Classes d'objets et granularité
2. Classes de privilèges
D. Règles d'attribution des privilèges
IV. Conclusion
V. Voir aussi
VI. Remerciements
I. Introduction à la sécurité
La quasi totalité des applications requièrent une base de données pour le stockage de l'information métier
ou comme simple source d'informations.
La sécurité d'une application peut être compromise de multiples manières. Les applications web
sont plus particulièrement vulnérables du fait de leur architecture distribuée et leur architecture n-tiers
qui multiplient les composants autonomes représentant autant de maillons d'une chaîne de sécurité à rompre.
La compromission d'une application peut engendrer la compromission en cascade des sources de données
auxquelles elle a accès. Pour réduire le risque de compromissions en chaîne, il est nécessaire de se doter
d'une politique de gestion des privilèges drastique.
II. Les risques encourus
Les risques propres à une source de données sont les suivants :
- vol de données (perte de confidentialité)
- altération de données (perte d'intégrité)
- destruction de données (remise en cause de la continuité d'activité)
- augmentation du niveau de privilèges d'un utilisateur d'une application (sécurité, espionnage)
- ressources systèmes abusives (déni de service)
Le vol de données induit la perte de confidentialité
des données stockées. La divulgation de données financières hautement confidentielles peut avoir un
impact néfaste sur l'activité d'une entreprise : risque juridique, atteinte à l'image de marque,
perte de confiance des partenaires industriels...
L' altération de données induit une perte d' intégrité,
c'est-à-dire que les données ne sont plus dignes de confiance. En fonction de la rapidité de détection et de la qualité
des sauvegardes, les conséquences peuvent en être réduites. Mais une application fonctionnant sur des données falsifiées
peut voir son comportement fortement influencé : par exemple, un site de commerce électronique pourrait débiter
le compte d'un autre client que celui réalisant la commande !
La destruction de données remet sérieusement en cause la continuité de l'activité de l'entreprise concernée.
Privée de ses données clients, sans sauvegarde, c'est le dépôt de bilan garanti !
L'augmentation du niveau de privilèges d'un utilisateur d'une application est plus insidieux que
les risques précédents, car comme pour l'altération de données, il n'est remarqué qu'après un certain laps de temps
durant lequel le pirate peut réaliser un grand nombre d'actions malveillantes. Il peut ainsi s'attribuer
le droit d'accès à des informations confidentielles, le droit d'accès à des opérations sensibles, voire même
prendre le contrôle d'une application.
Selon le SGBD utilisé, des ressources systèmes peuvent être attribuées à chaque utilisateur
(nombre de requêtes par unité de temps...). Ces ressources peuvent être limitées par l'administrateur
système afin d'éviter l'écroulement des capacités de traitement du serveur ( déni de service)
par un utilisateur malveillant. De plus, ceci permet de limiter la porter d'une attaque
par altération ou vol de données en limitant le nombre d'opérations réalisables en un temps donné.
La conséquence d'un tel risque peut être la paralysie du serveur (perte de disponibilité).
On le voit, les risques sont variés et leurs conséquences potentiellement dramatiques.
Ainsi, il est nécessaire d'attribuer les droits d'accès avec parcimonie.
III. La politique de gestion des privilèges
A. Les types d'utilisateurs
Il faut identifier les utilisateurs ayant besoin d'un accès à la base de données, ils peuvent
être de différents types :
- administrateur
- application
- utilisateur
L'administrateur est une personne physique ayant tous les droits sur le SGBD, mais pas forcément sur
le contenu des bases de données : il peut réaliser des opérations de gestion des droits d'accès et
des ressources systèmes mais on pourra choisir d'exclure ou non les droits d'accès en lecture et/ou écriture
au contenu des bases de données. Bien que parfaitement logique d'un point de vu métier, pour la protection
de données sensibles par exemple, retirer à un administrateur les droits de lecture et d'écriture
sur le contenu d'une base de données n'a pas de sens d'un point de vu technique puisqu'il possède les
capacités techniques de s'octroyer ses droits là. De plus, les opérations de sauvegarde, de restauration
et de maintenance après incident peuvent l'amener à devoir accéder au contenu d'une base de données.
Bref, normalement, c'est l'utilisateur qui a tous les droits sur le SGBD et les bases de données hébergées.
C'est normalement une personne de confiance, compétente et prudente.
Une application peut être une application web, un outil de synchronisation entre sources d'informations
ou tout programme accédant pour lui-même à la base de données.
Ce type d'utilisateur logique n'a rien à voir avec l'utilisateur réel dénotant une personne physique ayant des besoins
particuliers. Même si une application est utilisée par des personnes physiques, on pourra
choisir de déléguer à l'application la gestion des droits d'accès à l'information en fonction des habilitation qu'elle décide
de lui attribuer. Ainsi, une application peut être vue comme un utilisateur de base de données auquel on attribut des droits
qu'elle pourra restreindre de façon transparente pour l'utilisateur final de l'application ainsi que pour le SGBD.
L' utilisateur est une personne physique se connectant directement à la base de données en ligne de commande
(commande mysql sous Linux) ou via une interface graphique (script phpMyAdmin sur un Intranet)
ou utilisant une application qui va se connecter à la base de données sous l'identité de l'utilisateur
(client lourd MySQL Query Browser).
B. Contrôle des privilèges
La principale question qui se pose lors du développement d'une application, c'est quelle stratégie adopter
vis à vis des utilisateurs : contrôle de leurs droits d'accès par l'application ou par le SGBD ?
Par le SGBD. Dans le cas où toute l'information métier repose sur une base de données comportant également toutes
les procédures stockées de contrôle de l'intégrité, de la logique métier et des actions utilisateurs, il
est logique de déléguer au SGBD le contrôle d'accès et les habilitations.
Ceci suppose que l'administrateur de bases de données réalise les opérations d'attribution des privilèges
et de synchronisation avec l'annuaire des utilisateurs du système d'information de l'entreprise.
L'application ne devient alors qu'une interface graphique ergonomique d'interrogation de la base de données métier.
Par l'application. Dans le cas où l'application gère elle-même le niveau d'accréditation des utilisateurs,
elle va se connecter sous sa propre identité logique à la base de données et décider des informations et
des opérations que l'utilisateur peut voir, modifier et réaliser. C'est la stratégie employée
par les applications dont la logique métier n'est pas intégrée directement dans la base de données et
qui gèrent plusieurs sources de données.
 Gestion des habilitations
C. Les privilèges
Il convient pour chaque compte d'accès d'identifier les privilèges minima à accorder ainsi que le niveau
de granularité adéquat.
 |
Ici, le terme utilisateur désigne une application aussi bien qu'une personne physique.
|
1. Classes d'objets et granularité
Les SGBD permettent généralement de spécifier assez finement les privilèges d'un utilisateur en fonction des
objets manipuler :
- base de données
- table (relation)
- colonne (attribut)
Ainsi, un utilisateur peut se voir attribuer un privilège pour toute une base de données, ou seulement pour quelques tables,
ou encore sur uniquement quelques colonnes de certaines tables.
2. Classes de privilèges
Les privilèges s'organisent autour de plusieurs classes :
- accès au contenu de l'information
- gestion du schéma de la base de données
- gestion des privilèges utilisateurs
- gestion des paramètres systèmes
Chaque utilisateur devra se voir attribuer des privilèges parmi ces classes.
Le tableau suivant liste les types d'utilisateurs qui devraient être habilités pour chaque classe de privilège :
| Classes de privilèges |
Types de compte |
| accès au contenu de l'information |
utilisateur,
application |
| gestion du schéma de la base de données |
administrateur,
application (parfois) |
| gestion des privilèges utilisateurs |
administrateur |
| gestion des paramètres systèmes |
administrateur |
D. Règles d'attribution des privilèges
Règle fondamentale n°1 : attribution du moindre privilège.
Les utilisateurs ne doivent avoir que le minimum de droits, ceux strictement nécessaires à l'accomplissement de leurs tâches.
Les privilèges peuvent évoluer au cours du temps car les besoins et les tâches affectées ne sont pas immuables,
mais à un moment donné, seuls les droits indispensables doivent être fournis à un utilisateur.
Règle n°2 : contrôle de la population.
Le personnel d'une entreprise bouge, il y a des départs, des arrivées, des promotions...
Les privilèges doivent êtres synchrones avec la réalité de la population : il faut supprimer
les comptes des utilisateurs quittant l'entreprise et de ceux n'étant plus affectés à telle ou telle tâche.
Règle n°3 : supervision de la délégation des tâches d'administration.
Un administrateur peut être amené à déléguer auprès d'une autre personne les tâches d'attribution des privilèges
de tout ou partie de la population des utilisateurs.
Un contrôle a posteriori doit être réalisé afin de vérifier que le résultat de cette délégation
est conforme à la politique adoptée.
Règle n°4 : contrôle physique des connexions.
La connexion d'un utilisateur à une base de données peut être réalisée depuis n'importe où dans le monde grâce à Internet.
Il est nécessaire de restreindre les connexions à des hôtes spécifiques connus.
Par exemple, le compte d'accès d'une une application hébergée sur un serveur devrait voir ses privilèges restreints
à l'hôte (ou son domaine) sur lequel elle est hébergée.
Règle n°5 : limitation des ressources utilisées.
Le SGBD offre souvent la possibilité de restreindre les ressources de calcul disponibles pour un utilisateur.
Il est recommandé de configurer ces limitations de ressources en fonction de la charge maximale
attendue pour un utilisateur. Une personne physique n'a pas besoin de réaliser 100 requêtes à la secondes,
mais au contraire, une application gérant elle-même les habilitations peut avoir de gros besoins
qui peuvent être cependant limités raisonnablement afin de ne pas compromettre les accès directs en ligne
de commande au serveur de base de données...
Règle n°6 : journaliser les comportements suspects.
Certains SGBD permettent de conserver dans des journaux de log les requêtes
non conformes aux privilèges accordés à un utilisateur. Il peut être intéressant de les surveiller
afin de détecter toute anomalie dénotant des tentatives de piratage.
Règle n°7 : restrictions sur une application en fonction du public.
Une même application web peut avoir plusieurs interfaces différentes selon le contexte d'utilisation : internet / intranet.
Par exemple, un magazine de presse en ligne propose une interface de consultation pour tous ainsi qu'un espace d'administration
sécurisé. Dans cet exemple, il sera logique d'avoir deux comptes utilisateurs différents à la base de données :
le premier en lecture seule sur les tables et colonnes concernant les articles de presse et leurs catégories,
le second en écriture. Ainsi, en cas d'attaque du site internet, seules des lectures inoffensives peuvent éventuellement
être réalisées.
L'application web choisira le compte d'accès à utiliser selon le contexte d'utilisation.
IV. Conclusion
La sécurité des accès à une base de données est une préoccupation de tous les instants.
Les privilèges doivent être restreints à l'indispensable et être actualisés régulièrement.
Quant aux applications web, vulnérables par essence, elles doivent être développées de manière
à réduire le risque d'accès frauduleux aux données.
Une collaboration étroite entre administrateur de base de données et développeur web permet
de réduire considérablement les risques liés à la sécurité des bases de données.
V. Voir aussi
Je vous recommande la lecture de ces articles :
VI. Remerciements
 
|
