Le système de gestion de bases de données a une position « stratégique »

Dernier maillon de l’accès à l’information, le SGBD héberge toutes les données nécessaires aux applications dans leur fonctionnement. Ainsi, par exemple, dans le cas d’un site marchand, toutes les données du site et donc hébergées dans le SGBD (prix et références des articles, données bancaires des clients enregistrées, ...) doivent être correctement protégées afin de limiter le vol d’informations ou d’identité qui serait fortement préjudiciable.

Remarque : le vol d’information est souvent la résultante d’une compromission interne, au sein même de l’entreprise ! Malheureusement, le constat est bien présent. La sécurisation des bases de données n’est généralement pas ou peu prise en compte par les RSSI dans leur démarche alors qu’elles constituent le point névralgique de l’entreprise.

Quelques principes de sécurisation du SGBD

Le SGBD est souvent considéré comme le « parent pauvre » de la sécurité. En effet, les responsables de la sécurité préfèrent axer la sécurité de leur système d’information sur les couches « basses » du modèle OSI (physique, réseau, transport) au détriment des couches « hautes » (application) pour lesquelles ils ne disposent dans leurs équipes que de peu de compétences. Cette mentalité doit dorénavant changer et il est temps de prendre en compte la sécurité des bases de données et de l’inscrire dans le concept global de la défense en profondeur de son système d’information. Voici donc quelques principes non exhaustifs à appliquer pour la sécurisation des SGBD : 
 prendre en compte la sécurisation du SGBD dans la politique de sécurisation du système d’information ; 
 optimiser le niveau de sécurité du système d’exploitation sur lequel est hébergé le SGBD ; 
 maintenir en condition le SGBD (id est appliquer les mises à jour) 
 ne pas installer par défaut le SGBD (services et applications inutiles) ; choisir une authentification forte sur le SGBD ; 
 filtrer les entrées des formulaires (injection SQL) ; limiter la fuite d’informations (messages d’erreurs) ; 
 sécuriser l’accès réseau au SGBD (module « listener » sur Oracle) ; sécurisation physique ; politique des ACL pour les fichiers sensibles ; 
 formation du personnel adéquat ; sensibilisation du personnel.

La protection physique

L’isolement au niveau physique des SGBD est à la base du concept de sécurité. En effet, la base de données contenant des ressources critiques de l’entreprise, il faut empêcher que ces données soient corrompues aisément. Pour ce faire, il va falloir : 
 isoler le serveur dans une pièce sous contrôle d’accès permanent et réservée aux seuls administrateurs du SGBD ; 
 équiper la salle serveur de systèmes de détection et de lutte contre les incendies et/ou les inondations ; 
 faire vérifier régulièrement l’enregistrement des entrées sorties de la salle serveur (audit de surveillance du journal des entrées pour s’assurer qu’il n’y a pas eu d’intrusion suspecte).

« Durcir » le système d’exploitation hébergeant le SGBD

Dans le concept de sécurisation, il faut veiller à ce que tous les éléments entourant les bases de données soient eux mêmes convenablement sécurisés. En effet, chaque SGBD (Oracle, Informix, SQL Server, MySQL...) a besoin d’un système d’exploitation le plus souvent de type serveur pour pouvoir opérer. Si déjà en amont, l’OS contient plusieurs failles de sécurité, l’accès aux données en sera que plus aisé pour un attaquant potentiel. De façon usuelle, le durcissement du système d’information va se traduire par : 
 des mises à jour fréquentes ; 
 une politique d’authentification forte ; 
 par la présence d’un anti-virus à jour ; 
 par l’implémentation d’une politique d’audit interne sur le serveur ; 
 le paramétrage selon le principe du moindre privilège des services et applicatifs.

L’installation du SGBD

Lors de l’installation d’un SGBD, beaucoup de services et applicatifs sont installés par défaut (serveur Web, machine virtuelle Java, ...). Dans un souci de sécurité, il conviendra de rationnaliser ces services et de ne garder que ceux dont l’utilité est avérée. En effet, garder un serveur Web actif sur un SGBD peut conduire un individu malveillant à se servir de ce service pour tenter de compromettre la base de données.

Le maintien en condition du système

La problématique de maintien en condition des applications du système de gestion de bases de données demeure actuellement l’axe majeur de sécurité sur lesquels les entreprises doivent se focaliser. En effet, à l’instar des systèmes d’exploitation hôtes, le SGBD doit « subir » la même politique de mise à jour, c’est à dire que les correctifs de sécurité doivent être validés sur plate-forme de test et ensuite être tous appliqués sur le système en production. De plus, dans le cas d’un contrat de service avec une société tierce, il est impératif de prévoir, dans le contrat, le maintien en condition du SGBD durant la totalité de la durée d’exploitation du système d’information. Or, le retour d’expérience des différentes missions d’audits et de conseil montre que cette problématique de maintien en condition n’est pas prise en compte sérieusement par les responsables des systèmes d’information.

L’authentification

De même, lors de l’installation, les options de sécurité ne sont pas activés par défaut notamment en ce qui concerne les modules d’authentification (comptes, mots de passe, ...). C’est pourquoi, il faut veiller à activer ces paramètres. Concernant l’authentification, cela consiste à : 
 désactiver les comptes dormants (comptes invité, comptes de démonstration, comptes d’applications tierces, ...) ; 
 changer les mots de passe par défaut ; 
 choisir des mots de passe complexes ; 
 choisir des authentifications distantes sécurisées (emploi de SSL pour des authentifications via une interface Web). Remarque : il existe pour Oracle plus de 600 comptes et mots de passe par défaut ! (source : http://www.petefinnigan.com/default/default_password_checker.htm). Même si Oracle fait des efforts pour désactiver certains comptes dans les nouvelles versions, n’empêche que les administrateurs ont tendance à utiliser les mots de passes par défaut lors de l’activation de ces services (dbconsole, statspack…)

L’accès réseau au SGBD

Dans cette partie, il convient de s’attacher à décrire les principes de sécurisation des modules de connectivité des SGBD (Listener, ODBC, JDBC). Ces modules réseau constituent l’unique point d’entrée pour les clients qui veulent accéder à la base de données, c’est pourquoi il est nécessaire d’appliquer une sécurisation ad hoc. Le Listener d’Oracle 
Véritable « proxy » entre la base de données et le client, le Listener met en œuvre un processus qui utilise par defaut le port 1521/TCP. Chaque client qui essaie de se connecter au SGBD utilise ce processus. De plus, en utilisant des commandes internes à ce processus, on peut obtenir beaucoup d’informations sur la base de données. C’est pourquoi, il est absolument nécessaire de protéger l’accès au Listener par la mise en place d’un mot de passe. En outre, il est possible pour un individu ayant un client Oracle d’accéder à distance au Listener et d’obtenir des informations sur son état, voire de stopper le processus et donc ainsi de provoquer l’arrêt de l’accès au SGBD ! Remarque : à compter de la version 10g d’Oracle, l’accès au Listener n’est plus possible à distance mais seulement sur la machine hébergeant le SGBD.

La protection des données transitant par les pilotes ODBC et JDBC

Suivant le SGBD utilisé, il est possible d’utiliser des tunnels chiffrant (SSL par exemple) garantissant la confidentialité des données transitant sur le réseau par l’intermédiaire des modules ODBC et JDBC. Le concept Open DataBase Connectivity (ODBC) constitue le modèle d’accès normalisé aux SGBD. Celui ci a été défini dans le format SQL Access Group 92. Il permet surtout d’accéder à n’importe quelle ressource du SGBD avec l’application du système d’exploitation. Le pilote ODBC est ainsi multi plates-formes. Le concept Java DataBase Connectivity (JDBC) constitue lui l’équivalent de l’ODBC mais pour le langage Java. En effet, il permet l’accès, à partir des programmes Java, à des données tabulaires contenues dans les SGBD. Grâce à la portabilité du langage Java, le pilote JDBC est utilisable avec presque tous les SGBD.

Limiter la fuite d’informations sur la nature du SGBD

Lors de la connexion sur le SGBD par SQL ou par interface Web, il est possible de récupérer des informations sur le type de serveur de base de données présent dans le système d’information. En effet, en envoyant une requête mal formée à l’application, le SGBD va renvoyer un message d’erreur qui souvent va donner des informations sur la nature du logiciel. Il suffit ainsi, pour un individu malveillant qui a récupéré ce type d’information, de se focaliser sur les vulnérabilités affectant les SGBD du type. Pour contrer cette divulgation d’information, il faut alors que l’administrateur de la base de données (DBA) personnalise les messages d’erreurs envoyés aux clients en limitant cette divulgation d’informations.

Le filtrage des données d’entrées : l’injection SQL

L’injection SQL est un type d’attaque qui est fondée sur les propriétés caractéristiques syntaxiques de certaines variables dans la programmation du langage SQL. Il existe alors plusieurs formes possibles d’injection suivant le type de base de données (MySQL, Oracle, SQL Server, ...). Pour mettre en œuvre son attaque, l’individu malveillant devra tout d’abord essayer de récolter le maximum d’informations sur le type de base de données présente et ensuite passer à la phase d’injection en elle-même. De façon générale, de nombreux sites font appel aux bases de données pour gérer des accès à des pages réservées aux utilisateurs déjà enregistrés. Ceux ci en entrant un identifiant et un mot de passe peuvent alors avoir accès au site. Il est possible alors à une personne malveillante mettant en œuvre la technique d’injection SQL d’avoir un accès privilégié à ces pages. Pour ce faire, il existe plusieurs combinaisons de chaînes de caractères qui peuvent réussir à « duper » la commande d’authentification SQL suivant le type de base de données. Exemple : à l’invite d’une identification sur une page Web, essayons d’entrer les valeurs suivantes pour voir si la base est vulnérable à une injection SQL : 
 Login : test’ OR ’1’=’1 
Password : test Voici ce que va interpréter le langage SQL en aval de l’application Web : 
SELECT * FROM users where PASSWORD = ’test’ and USER= ’test’ OR ’1’ = ’1’

Ainsi, l’interprétation de la requête est toujours réalisée puisque l’assertion « 1 = 1 » est toujours vraie quelque soit la valeur des champs PASSWORD et USER saisis. L’utilisateur va ainsi avoir un accès illégitime sur l’application Web et pouvoir faire des opérations qui sont généralement réservées aux utilisateurs enregistrés. En définitive, il faut donc tirer les conclusions de sécurisation idoines face à la menace que constituent les injections syntaxiques SQL. En effet, les DBA doivent paramétrer convenablement les applications afin que les formulaires d’entrée (identifiant, mot de passe, ...) soient filtrés syntaxiquement et ainsi ne laissent pas passer des tentatives d’usurpation d’identité très faciles à mettre en œuvre.

La mise en place d’Access Control List (ACL) sur les fichiers sensibles

Dans la continuité du concept de la défense en profondeur et du principe du moindre privilège, il convient d’établir dans la politique de sécurité la liste des fichiers sensibles (fichiers de configuration, fichiers de paramétrage, ...) présents sur le SGBD. Il paraît évident que les utilisateurs doivent posséder des droits de lecture et/ou écriture différents suivant leur classification (simples utilisateurs, utilisateurs avec pouvoir, administrateurs, ...). Souvent, par défaut, les programmes d’installation accorde automatiquement le contrôle total de tous les fichiers et pour tous les comptes créés, ce qui constitue un manquement grave à la sécurité du SGBD. Pour renforcer cette sécurité à l’intérieur même du poste de travail, il sera alors nécessaire de définir en amont la liste des fichiers à protéger par le mécanisme des ACL et a posteriori de mettre en place ce contrôle d’accès.

La formation et la sensibilisation des personnels

La sensibilisation du personnel demeure l’axe majeur d’effort sur lequel il faut mettre l’accent en entreprise. En effet, les principales erreurs ont pour origine le facteur humain. Par manque de formation et d’information des utilisateurs, ceux-ci sont souvent à l’origine des « mauvaises actions » réalisées sur le système d’information. Alors que simplement à l’aide d’un programme de sensibilisation et de formations idoines au sein de l’entreprise, il est ainsi aisé d’augmenter significativement le niveau de sécurité interne...

Omniprésents dans les sites Web dynamiques actuels, les systèmes de gestion de bases de données doivent être sécurisés prioritairement car ils peuvent contenir des données privatives (numéros de cartes bancaires), des données nominatives (identités des clients) mais aussi des données confidentielles d’une société. Constituant une cible privilégiée pour des attaquants potentiels, leur sécurisation nominale passe avant tout par la prise en compte de leurs spécificités (mise en œuvre, place stratégique au sein du SI, difficulté de paramétrage, ...) par les directions des systèmes d’information de l’entreprise.