A l´heure où cet article est publié, plus de 75 millions de sites Web seront recensés sur la planète Internet (source www.netcraft.com) avec une progression soutenue de 15 millions de nouveaux sites par an. Ainsi, nous sommes en mesure de croire que plusieurs Méga-octets (ou peut être Giga-octets) de données ayant un caractère confidentiel seront présents dans ces sites Internet. Dans la majorité des cas, les données de ces sites Web dynamiques sont hébergées au sein de systèmes appelés Systèmes de Gestion de Base de Données (SGBD).
Il est donc essentiel de protéger ces données présentes sur les sites Web pour éviter qu´elles ne se retrouvent divulguées sur le réseau mondial Internet.


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.
IMG/png/IMG_1-2.png

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 PSSI ;
- 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, MySQL, PostgreSQL, ...) 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 RSSI.

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 500 comptes et mots de passe par défaut ! (source : http://www.petefinnigan.com/default/default_password_checker.htm)

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 (lsnrct.exe) qui utilise 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 du SGBD !
Procédure sous Windows 2000 Server :
1. Lancement du processus lsnrctl.exe dans la fenêtre de commande Windows :
IMG/png/IMG2-2.png

2. Vérification du statut du Listener à l´aide de la commande STATUS ;
3. Mise en place d´un mot de passe par la commande SET PASSWORD ;
4. Relancez le processus par les commandes successives STOP et START.

NB : choisir un mot de passe complexe car les attaques de recherche exhaustives sur le mot de passe du Listener sont réalisables.
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é (PostgreSQL, MySQL), 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.

La divulgation d´informations : 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.
Dans l´exemple ci dessous, la page renvoyée par la requête renseigne sur le type de SGBD présent sur le réseau :

Requête :
IMG/png/IMG3-2.png


Réponse :
IMG/png/IMG4-2.png

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 de type Microsoft Access.
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
S´inscrivant dans les lignes directrices du rapport parlementaire du député Lasbordes sur l´état de la SSI en France (source : http://www.lasbordes.fr ou http://www.mag-securs.com/article.php3?id_article=3914), 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 formation 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.



Noter cet article (de 1 = Nul à 5 = Excellent) Valider

Dossier

Droit d’accès et comptes à privilèges

Jacques Cheminat 0 143224
Equifax, Deloitte, Uber, les récentes violations de données ont souvent des techniques de piratages différentes, mais un élément commun, obtenir l’accès à des applications critiques comme les bases de données, les bases clients, les informations bancaires. En général ces programmes sont soumis à habilitation et rattachés à des comptes à privilèges. leur protection est donc une nécessité dans un monde de plus en plus ouvert et insécurisé. Dossier publié avec le concours de Kleverware.
RSS
12



Événements SSI