Politique de gestion des droits d'accès à une base de données

Hugo Etiévant

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.

- Titre : Politique de gestion des droits d'accès à une base de données

- Auteur : Hugo Etiévant

- Parution : 26 août 2006

- Mise à jour : 9 mai 2020

- Licence : Copyright ® 2006 Hugo Etiévant (cyberzoide). 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.

Sommaire

- I. Introduction à la sécurité

- II. Les risques encourus

- III. La politique de gestion des privilèges

- III-A. Les types d'utilisateurs

- III-B. Contrôle des privilèges

- III-C. Les privilèges

- III-C-1. Classes d'objets et granularité

- III-C-2. Classes de privilèges

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

Cet article vise un public d'administrateurs de bases de données et de développeurs d'applications accédant à des bases de données.

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ème 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 insidieuse 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 prendre le contrôle d'une application.

Selon le SGBD utilisé, des ressources système 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 portée 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

III-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ème, 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 vue 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 vue technique puisqu'il possède les capacités techniques de s'octroyer ces 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 habilitations qu'elle décide de lui attribuer. Ainsi, une application peut être vue comme un utilisateur de base de données auquel on attribue 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).

III-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

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

III-C-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 manipulés :

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

III-C-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ème.

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èges :

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

III-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 être 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 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 seconde, 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 :

- SQL : La gestion des privilèges de SQLPro

- Sécurisation d'une base Oracle de Leo Anderson

- MySQL 5 : Commande de gestion des comptes utilisateurs du Manuel de Référence de MySQL

VI - Remerciements

Merci à Xavier Vlieghe pour ses remarques constructives.