Sécurisation des SGBDR

CELAR/CASSI
étude des logiciels libres
Rapport d'étude 7-9 : Sécurisation des SGBDR

Auteur :

Patrick BON

éric LEMIÈRE

Version :

1.0

Date :

30/06/2000

état :

Approuvée

Approbateur :

Guy AUTIER

Philippe CHAPSAL

Historique des révisions

Date

Auteur

Contenu

0.1

23/05/00

Patrick BON

Création

0.2

25/05/00

Patrick BON

Prise en compte des relectures internes.

0.3

27/06/00

Patrick BON

Rédaction du rapport.

1.0

30/06/00

Patrick BON

Prise en compte des relectures internes.

Table des matières

1. Introduction *

1.1 Objet du document *

1.2 Documents de référence *

1.3 Structure du document *

2. Présentation préliminaire des objets de l'étude *

2.1 SGBD étudiés *

2.1.1 Caractéristiques générales de MySQL *

2.1.2 Caractéristiques générales de PostgreSQL *

2.1.3 Comparaison succincte des deux produits *

2.2 Critères de sécurité *

3. évaluation des produits *

3.1 Fonctions natives de sécurité des produits *

3.1.1 Identification / authentification des utilisateurs *

3.1.2 Contrôle d'accès aux données *

3.1.3 Contrôle d'accès aux services d'administration *

3.1.4 Protection des échanges réseau *

3.1.5 Protection des données stockées *

3.1.6 Intégrité du logiciel *

3.1.7 Services d'audit *

3.2 éléments de robustesse des produits *

3.2.1 Tolérance aux anomalies *

3.2.2 Tolérance à la congestion *

3.2.3 Qualité du code source *

3.2.4 Problèmes connus et corrections *

3.3 Extensions fonctionnelles des produits *

3.3.1 Extensions dynamiques *

3.3.2 Modification du code source *

3.4 Résultats de l'évaluation *

3.4.1 Tableau d'évaluation des produits *

3.4.2 Synthèse sur les lacunes et vulnérabilités *

3.4.3 Synthèse sur les solutions pour améliorer la sécurité *

3.4.4 Préconisations *

4. Maquette *

4.1 Objectifs de la maquette *

4.1.1 Orientation générale *

4.1.2 Mécanisme d'authentification mis en oeuvre *

4.2 Organisation de la maquette *

4.3 Scénario de démonstration *

4.4 Résultats *

5. Conclusions de l'étude *



1. Introduction

Le document présente successivement :

MySQL est un serveur de base de données SQL multi-utilisateurs et multi-threads. Les principaux objectifs de MySQL sont la rapidité, la robustesse et la facilité d'utilisation.

MySQL a été développé par la société suédoise TcX, initialement pour répondre au besoin d'un serveur SQL qui puisse gérer des grandes bases de données, sur du matériel bon marché, de manière plus rapide que ce que pouvaient offrir les SGBD commerciaux de l'époque. Des bases de données MySQL sont opérationnelles depuis 1996 et le produit continue à évoluer. Le produit est disponible gratuitement sous Unix et pour les clients Windows. Le serveur est également disponible sous Windows NT, sous forme de shareware (une contribution annuelle de 200 dollars, incluant le support de TcX, est demandée au delà de 30 jours d'utilisation).

MySQL est architecturé selon une architecture client/serveur, sur la base d'un process démon serveur mysql, de programmes clients et de librairies. Le stockage des données est réalisé sous forme de B-Tree, à l'aide d'un gestionnaire ISAM.

Quelques caractéristiques intéressantes de MySQL :

La principale limitation de MySQL concerne l'absence de services transactionnels (avec " roll back " en cas d'incident lors de l'exécution d'une transaction). Ce qui fait que, de ce point de vue, il ne s'agit pas d'un véritable SGBD relationnel. MySQL ne dispose pas non plus de vues, ni de " triggers ".

La version de MySQL étudiée dans le présent document est la version 2.23.

2.1.2- Caractéristiques générales de PostgreSQL

PostgreSQL est un SGBD " relationnel-objet " développé à l'origine à Berkeley, sous le nom de Postgres, par l'équipe du professeur Stonebraker, créateur de INGRES dans les années 80. Le développement (financé par la DARPA, la NSF et quelques autres grosses agences américaines) a été abandonné à Berkeley en 1994, et est maintenant poursuivi par une équipe de volontaires, à la mode " Open Source ". Vis-à-vis des systèmes d'exploitation, PostgreSQL a été validé avec la plupart des UNIX et avec Windows NT (à l'aide des bibliothèques RedHat/Cygnus pour la partie serveur).

Quelques caractéristiques intéressantes de PostgreSQL :

PostgreSQL connaît encore certaines limitations :

La version de PostgreSQL étudiée dans le présent document est la version 7.0.

2.1.3- Comparaison succincte des deux produits

En résumé, les caractéristiques dimensionnantes pour différencier les deux produits étudiés sont les suivantes :

En cas de mise en oeuvre de la partie serveur sous Windows NT, il est à noter que MySQL est soumis à un coût de licence (contrairement au serveur sous UNIX, aux clients et à PostgreSQL).

Vis-à-vis des services des sécurité, ces deux produits présentent des caractéristiques suffisamment proches pour permettre une analyse groupée.

Note : TcX fournit, sur le site Web de MySQL (www.mysql.com/crash-me-choose.html) une analyse comparative très détaillée des caractéristiques fonctionnelles des principaux SGBD (libres et commerciaux). Malheureusement cette analyse ne prend pas en compte les services qui impactent directement la sécurité, telle que la gestion des droits d'accès.

2.2- Critères de sécurité

La sécurisation des SGBD est analysée selon les thèmes suivants :

Pour chacun de ces thèmes, les critères suivants sont pris en compte :

Chacun des critères identifiés ci-dessus fait l'objet d'une description dans un des paragraphes du chapitre 3. La description porte sur les deux produits analysés en précisant les différences lorsque nécessaire.

Pour chaque fonction analysée sont présentées :

Pour le serveur MySQL, un client est identifié par un nom de machine (host_name ; par défaut localhost) et un nom d'utilisateur MySQL (user_name ; jusqu'à 16 caractères). Deux utilisateurs portant le même nom mais rattachés à des machines différentes sont deux utilisateurs distincts. Au niveau du client UNIX MySQL, la saisie du nom d'utilisateur est optionnelle ; par défaut c'est le nom du compte UNIX qui est utilisé. La création des utilisateurs est réalisé à l'aide de la commande GRANT ou par mise à jour directe d'une base de données système (base mysql).

L'application serveur MySQL dispose de quelques options de lancement qui rendent plus difficile, à un utilisateur externe, d'usurper l'identité d'une machine (host) déclarée :

Le client MySQL est authentifié par un mot de passe. Le mot de passe peut être saisi par l'utilisateur ou être stocké dans un fichier de configuration du client (.my.cnf). Le mot de passe peut être vide, ce qui correspond à un utilisateur se connectant sans mot de passe. Le mot de passe est stocké par le serveur et transmis par le client sous forme chiffrée. Il s'agit d'un chiffrement non réversible, qui utilise un algorithme différent de celui utilisé par UNIX. Il n'existe pas de moyen technique permettant d'imposer une politique de mise en oeuvre des mots de passe. En particulier, le mot de passe peut être vide, ce qui correspond à un utilisateur se connectant sans mot de passe.

3.1.1.2.2- Identification et authentification PostgreSQL

Les utilisateurs PostgreSQL sont identifiés par un nom (username) et par un identifiant système numérique (uid) qui n'ont pas besoin d'être connus du système d'exploitation. La gestion des utilisateurs se fait à l'aide de commandes de création (CREATE USER), de modification (ALTER USER) et de suppression (DROP USER).

Le serveur PostgreSQL met en oeuvre un programme spécialisé dans l'authentification des utilisateurs : postmaster.

L'authentification d'un utilisateur peut être autorisée :

Par défaut, seules les connexions locales sont autorisées ; il est nécessaire de lancer le l'application postmaster avec un paramètre particulier (-i) pour pouvoir autoriser des connexions réseau. Les connexions réseau peuvent être sécurisées par SSL. Pour cela, il est nécessaire de recompiler PostgreSQL avec SSL et de lancer postmaster avec une option particulière(-l).

Pour les connexions locales, l'authentification est basée sur le nom d'utilisateur (user-id) et, pour les connexions TCP/IP, est basée sur l'adresse IP.

PostgreSQL autorise diverses méthodes d'authentification. Le choix de la méthode d'authentification est précisé indépendamment pour chaque base, d'une part pour les connexions locales et, d'autre part, pour des plages d'adresses IP (adresse et masque).

Pour les connexions locales, il existe des méthodes d'authentifications " tout ou rien "  et, de manière classique, des méthodes basées sur un mot de passe :

Pour les connexions TCP/IP, PosgreSQL permet d'utiliser les mêmes méthodes que l'authentification locale, mais également les méthodes suivantes :

L'authentification des utilisateurs est un service primordial vis-à-vis de la sécurité des SGBD et comme les produits étudiés ne disposent pas, en natif, de mécanisme d'authentification forte, des améliorations doivent être apportées.

Dans certains cas d'utilisation, cette authentification forte peut être réalisée de manière périphérique, à l'aide d'une sécurité au niveau du réseau (authentification IP) et au niveau local des équipements (OS sécurisé). Lorsque cette approche n'est pas suffisante, la disponibilité des produits sous forme de source permet d'envisager l'intégration d'un mécanisme tiers.

Il s'agit de n'autoriser l'accès aux données stockées qu'aux personnes autorisées. Ce contrôle doit permettre de distinguer différents modes d'accès, au moins lecture ou écriture, et une granularité variable, par exemple au niveau d'une base, d'une table ou d'une colonne.

De manière classique, on distingue :

Ces deux types de contrôles sont complémentaires :

3.1.2.2- Fonctions natives

Les produits étudiés ne gèrent que le contrôle d'accès discrétionnaire. La gestion des droits est normalement réalisé à l'aide des requêtes SQL GRANT (ajout de privilèges) et REVOKE (suppression de privilège).

La commande GRANT , telle que spécifiée par SQL92, permet d'allouer à un utilisateur (ou à tous les utilisateurs) le droit d'effectuer une opération SQL donnée (ou toutes les opérations) sur une table, ou une colonne. Les opérations pour lesquelles des droits peuvent être alloués par GRANT regroupent :

Initialement, seul le créateur de l'objet dispose du droit d'exécuter un GRANT pour allouer des droits sur cet objet à d'autres utilisateurs. La commande GRANT comporte une option (WITH GRANT OPTION) qui autorise l'utilisateur auquel un privilège est alloué à accorder, à son tour le même privilège (ou un sous-ensemble des droits) à d'autres utilisateurs.

Les produits étudiés implémentent GRANT avec quelques spécificités :

MySQL et PostgreSQL stockent les droits des utilisateurs dans des tables système. Ainsi, tout utilisateur autorisé à modifier le contenu de ces tables peut modifier les droits alloués aux utilisateurs sans utiliser GRANT ou REVOKE.

 

Une manière particulière d'accéder aux données consiste à exporter des données de la base vers un fichier ou d'importer le contenu d'un fichier dans une base.

MySQL permet ces importations ou exportations à l'aide d'utilitaires de conversion lancés sur le serveur, depuis le système d'exploitation (par exemple importsqltext et exportsqltext pour des conversions en format texte). Le seul contrôle d'accès, vis-à-vis des données de la base, mis en oeuvre est celui de l'OS pour l'exécution de l'outil de conversion.

PostgreSQL permet d'importer et d'exporter des données à l'aide de la commande COPY. Lors du traitement de cette commande, les droits de l'utilisateur en lecture (SELECT) ou en mise à jour (UPDATE, INSERT) sont contrôlés par le SGBD.

3.1.2.3- Analyse des lacunes et failles de sécurité

Dans la pratique, toute la sécurité native des SGBD étudiés est basée sur les services de contrôle d'accès discrétionnaire. Pour ce type de service, le niveau fonctionnel est tout à fait satisfaisant. Vis-à-vis de la résistance de ce contrôle d'accès, il est à noter que :

Il reste toutefois possible d'attaquer le mécanisme de contrôle d'accès soit en modifiant directement les droits stockés sur disque (sans utiliser le SGBD), soit en substituant au logiciel serveur, un logiciel pirate qui permet de contourner les contrôles. Dans le cas de MySQL, il est également possible d'importer ou d'exporter des données, sans contrôle d'accès par le SGBD, en exécutant un utilitaire de conversion sur le serveur.

La principale lacune fonctionnelle concerne l'absence de contrôle d'accès obligatoire. Il est toutefois à noter que ce point est également vrai pour les SGBD commerciaux à de très rares exceptions près (version multi-niveaux d'ORACLE).

3.1.2.4- Solutions d'amélioration

Vis-à-vis du besoin d'améliorer l'authentification des utilisateurs, se reporter au § 3.1.1.

Vis-à-vis de la menace d'attaque des droits d'accès par modification directe de données sur disque, se reporter à la protection des données stockées (§ 3.1.5).

Vis-à-vis de la menace de contournement du contrôle d'accès par modification du logiciel, se reporter au contrôle d'intégrité du logiciel (§ 3.1.6).

Le cas particulier d'exécution d'un utilitaire de conversion sur un serveur MySQL est à traiter en tant que contrôle d'accès à une fonction d'administration des données (cf. § 3.1.3). Dans la pratique, ceci relève du contrôle d'accès de l'OS du serveur.

 

La suite de ce paragraphe traite du besoin de contrôle d'accès obligatoire.

A défaut d'un produit présentant des mécanismes d'étiquetage de sécurité des données et de contrôle d'accès obligatoire, il est possible de répondre à des besoins de base de données multi-niveaux en intégrant un étiquetage de sécurité dans le modèle de données et en le traitant dans l'applicatif.

Ce type de besoin peut être traité par une architecture adaptée du schéma de données et des applications clientes adaptées. Voici, à titre d'exemple, deux orientations possibles pour ce type d'approche.

De manière plus ambitieuse, il pourrait être envisagé de mettre à profit la disponibilité des produits sous forme de code source pour développer des extensions multi-niveaux dans le SGBD lui-même. En fait, la complexité d'une telle tâche rend cette approche peu réaliste.

3.1.2.5- Résumé

La protection, en intégrité et en confidentialité, des données gérées par le SGBD repose sur les services de contrôles d'accès discrétionnaires offerts par les produits. Les mécanismes natifs offerts par les produits présentent une granularité satisfaisante. Pour avoir une confiance suffisante dans ce service, il est nécessaire de mettre en oeuvre une authentification forte des utilisateurs et de protéger les données stockées sur le serveur ainsi que les échanges réseau, pour éviter le contournement du contrôle d'accès du SGBD.

Aucune fonction de contrôle d'accès obligatoire n'est prévue par les produits. Les besoins en la matière sont à traiter au niveau des applications utilisatrices.

Il s'agit de n'autoriser les opérations d'administration du SGBD qu'à des utilisateurs disposant de droits particuliers.

Fonctionnellement, différentes fonctions d'administration peuvent être distinguées. Nous retiendrons les trois catégories suivantes, sachant que cette répartition est nécessairement arbitraire et peut être adaptée, pour une mise en oeuvre donnée, en fonction de choix organisationnels :

Comme cela a été indiqué (au § 3.1.2.3), le contrôle d'accès aux services de gestion des utilisateurs est particulièrement important pour assurer la sécurité du SGBD.

3.1.3.2- Fonctions natives

La présente analyse ne détaille pas l'utilisation des scripts ou utilitaires d'administration fournis avec les produits ni des produits d'administration tiers qui pourraient être mis en oeuvre pour gérer et superviser les bases de données. En pratique, il s'agit d'applications clientes spécialisées qui s'appuient sur les principes basiques décrits ci-après.

MySQL et PostgreSQL comportent, tous deux, la notion de super-utilisateur (identifié par root pour MySQL et postgres pour PostgreSQL), créé lors de l'installation du serveur et qui dispose de tous les droits. Suite à l'installation du produit, le super-utilisateur est le seul utilisateur connu. C'est donc lui qui doit créer les premiers autres utilisateurs. Il est recommandé que le super-utilisateur du SGBD soit distinct du super-utilisateur du système d'exploitation (root UNIX).

Pour PostgreSQL :

Pour MySQL :

Il est à noter que le lancement de l'application serveur, qui est une application contrôlée par le système d'exploitation est une opération particulièrement sensible car :

Par ailleurs, l'exécution malveillante de commandes d'administration technique peut porter atteinte à la disponibilité du service (arrêt du serveur, suppression de process actif).

3.1.3.3- Analyse des lacunes et failles de sécurité

L'administration de la base de données repose sur l'utilisation de commandes gérées par le SGBD, mais également d'applications lancées à partir du système d'exploitation (en particulier, lancement de l'application serveur).

Pour les commandes incluses dans le SGBD, les deux produits étudiés présentent des mécanismes de contrôle d'accès discrétionnaires différents mais tous deux acceptables moyennant l'application de mesures organisationnelles :

Le contrôle d'accès aux droits d'administration est basé sur l'authentification des utilisateurs. Il n'y a aucune différence technique entre l'authentification d'un simple utilisateur ou d'un administrateur (ou du super-utilisateur). La résistance du contrôle d'accès aux services d'administration est donc directement conditionnée par la mise en oeuvre d'un mécanisme d'authentification forte suffisamment robuste. Les menaces d'attaque du contrôle d'accès aux commandes d'administration gérées par le SGBD sont les mêmes que celles présentées au § 3.1.2.3 pour le contrôle d'accès discrétionnaire aux données (modification directe des droits sur disque ou logiciel pirate).

Les commandes de contrôle du SGBD passées au niveau du système d'exploitation peuvent être particulièrement sensibles, comme cela a été cité pour les commandes de lancement de l'application serveur (cf. fin du § 3.1.3.2).

Les fonctions d'administration du SGBD se répartissent entre des fonctions accessibles depuis le système d'exploitation (notamment le lancement du serveur du SGBD) et celles accessibles à l'aide de commandes du SGBD.

La première catégorie est particulièrement sensible et suppose une sécurité suffisante au niveau du système d'exploitation.

Pour la deuxième catégorie, la problématique est similaire au contrôle d'accès discrétionnaire aux données et rien ne permet de distinguer, en terme d'identification/authentification, un administrateur d'un simple utilisateur.

 

Les solutions envisageables supposent la mise en oeuvre de services cryptographiques tels que signature électronique et/ou chiffrement.

MySQL et PostgreSQL conseillent tous deux d'utiliser une solution de protection au niveau IP, telle que SSH, et d'établir un tunnel sûr entre le client et le serveur. Ce type d'approche présente l'avantage d'être transparent aux applications et de pouvoir couvrir tout type d'échange réseau (utilisant le protocole IP) et non pas seulement le service de base de données. Les solutions de protection au niveau IP sont largement disponibles sous des formes variées :

 

Pour certaines applications, il est également possible de protéger les informations au niveau du client, sans impact sur le SGBD.

Par exemple, l'application cliente peut protéger une information structurée à l'aide d'un service de sécurisation de données tel que S/MIME. Ces données protégées peuvent être stockées en base de données accompagnées d'informations non sensibles, stockées en clair, de manière à permettre d'exécuter des requêtes de recherches dans la base. Par exemple, pour une application de gestion électronique de documents classifiés, le contenu des documents doit être stocké chiffré, mais certaines données d'indexation peuvent rester en clair. Dans cette approche, tout client peut vérifier l'origine et l'intégrité des données protégées et seuls les clients autorisés peuvent déchiffrer les données protégées en confidentialité.

Ce type de solution n'est pas toujours applicable puisqu'il suppose le développement de services de protection au niveau des applications utilisatrices de la base de données. Son principal intérêt est qu'il apporte une protection de bout en bout entre le créateur des données et les utilisateurs de ces données, sur l'ensemble de la chaîne " réseau et stockage ".

 

Il est également envisageable de modifier le comportement des requêtes SQL, à la fois côté client et côté serveur, de manière à mettre en oeuvre un SQL sécurisé (signature et, si nécessaire, chiffrement de la requête par l'émetteur ; contrôle et déchiffrement par le destinataire). Il s'agit du seul type de solution où l'utilisation d'un logiciel libre apporte un avantage (du fait de la possibilité de modifier le code source). Ce type de solution est toutefois plus coûteux à mettre en place qu'une solution de protection au niveau IP, sans apporter d'avantage notable s'il est restreint à la protection des données échangées sur le réseau. En revanche, une telle orientation pourrait présenter un intérêt si la solution est conçue pour protéger également les données stockées par le serveur (cf. § 3.1.5).

3.1.4.5- Résumé

Les produits étudiés ne sont pas conçus pour protéger, en confidentialité ou en intégrité, les échanges sur le réseau. Toutefois, une protection efficace peut généralement être apportée de manière indépendante du SGBD, en mettant en oeuvre une sécurité cryptologique au niveau du protocole IP.

Les besoins de protection des échanges réseau concernent l'intégrité et, si nécessaire, la confidentialité des données stockées, ou en cours de traitement, dans le serveur hébergeant le SGBD. Le but est de garantir que :

Les services de contrôle d'accès du système d'exploitation peut limiter les risques d'accès malveillant aux données, en réservant l'accès aux partitions ou fichiers utilisés par le SGBD à un compte privilégié. Il peut s'agir des services natifs du système d'exploitation ou de la mise en oeuvre de services de sécurité locale mettant en oeuvre des mécanismes cryptographiques (par exemple utilisation d'un service de chiffrement à la volée des accès disques, tel que celui mis en oeuvre, sous Windows NT, par le produit gouvernemental ISATIS développé dans le cadre de l'Opération MUSE).

Vis-à-vis de solution de chiffrement des données intégrées à l'O/S, il est à noter que seules les solutions indépendantes du système de gestion de fichier (par exemple driver disque chiffrant) sont applicables à coup sûr. En effet, les produits SGBD utilisent souvent des accès directs à un espace disque, indépendamment du gestionnaire de fichiers de l'O/S. Par exemple, MySQL, depuis la version 3.23, fournit son propre gestionnaire ISAM.

Ce type de solution ne permet pas de différencier les droits accordés aux différents utilisateurs du SGBD. Il doit être mis en oeuvre de manière à ce que seule l'application serveur SGBD ait le droit d'accéder directement aux données sur disque et que tout autre utilisateur doive impérativement faire appel à cette application pour accéder aux données.

 

Vis-à-vis des risques d'intrusion dans le serveur, depuis le réseau, en contournant les services du SGBD, il est possible de placer, en coupure réseau, un équipement " filtre SQL " (pare-feu spécialisé), dont le but est de rejeter toute trame IP ne correspondant pas à une requête SQL. Un tel équipement peut de plus effectuer un contrôle sur l'adresse IP de manière à n'accepter que les requêtes provenant d'adresses connues. Pour certains besoins gouvernementaux de protection d'informations classifiées, ce type de solution peut être bâtie sur la base d'un équipement FOX (pour lequel un filtre SQL pour ORACLE doit être disponible). Pour des besoins moins contraignants, il peut s'agir d'un filtre développé sur un firewall classique.

 

La mise en oeuvre de services spécialisés pour le SGBD constitue une autre orientation envisageable.

Certaines solutions identifiées dans le cadre de la protection des échanges réseau (cf. § 3.1.4.4) apportent également la protection des données stockées :

Si la protection des échanges réseau est assurée par une solution périphérique, il est également possible de modifier le comportement des requêtes SQL uniquement du côté serveur, de manière à mettre en oeuvre un SQL sécurisé destiné à protéger les données stockées. Ce type de solution suppose :

Il est à noter que ce type de solution est nécessairement très pénalisant en terme de performance, du fait des opérations cryptologiques nécessaires pour tout accès du serveur aux données de la base.

3.1.5.5- Résumé

Les produits étudiés ne sont pas conçus pour protéger, en confidentialité ou en intégrité, les données stockées sur le serveur vis-à-vis d'accès qui contourneraient les mécanismes de contrôle du SGBD.

Il est possible d'apporter une protection locale au niveau du serveur en associant sécurisation du système d'exploitation et protection en coupure sur le réseau (firewall avec filtre SQL). Dans certains cas d'emploi, c'est l'application utilisatrice qui peut être sécurisée, par mise en oeuvre de ressources cryptologiques au moins côté client.

Deux types de menaces doivent être traitées :

3.1.6.4- Solutions d'amélioration

Pour parer le premier type de menace (modification du logiciel), il est nécessaire de disposer d'un service de contrôle d'intégrité logiciel couplé au système d'exploitation. Au minimum, il peut s'agir de la mise en oeuvre d'un logiciel anti-virus. Pour une sécurité renforcée, l'utilisation de produits évalués peut être requise. A titre d'exemple, le produit ISATIS développé pour les besoins du Ministère de la défense, permet d'apporter une solution de sécurité locale de niveau gouvernementale pour les équipements exploités sous Windows NT. Par ailleurs, dans une certaine mesure, une authentification mutuelle entre le client et le serveur rend plus difficile la modification malveillante du logiciel.

Pour se protéger du deuxième type de menaces les mécanismes de contrôles d'accès des produits permettent de limiter le droit de créer ou modifier des fonctions dynamiques à des utilisateurs de confiance. La problématique de cette approche est celle du contrôle d'accès aux fonctions d'administration (cf. § 3.1.2). Une approche complémentaire intéressante consiste à développer un mécanisme de contrôle d'intégrité, par le serveur, des fonctions ou procédures dynamiques.

Ceci suppose de mettre en oeuvre :

Un tel développement est faisable, du fait de la disponibilité du logiciel serveur sous forme de sources.

3.1.6.5- Résumé

Le logiciel du SGBD doit être contrôlé en intégrité à l'aide de produits de sécurité locale (au minimum un anti-virus) sur les équipements clients et serveur.

La mise en oeuvre d'extensions dynamiques, et notamment celles qui peuvent être exécutées à l'insu des utilisateurs (triggers et règles de PostgreSQL, procédures de MySQL) doivent faire l'objet au minimum d'une politique de contrôle d'accès adaptée. De manière plus sécurisante, des évolutions du produit sont souhaitables pour contrôler les extensions dynamiques sur la base d'une signature électronique.

Les produits étudiés ne disposent d'aucun service permettant un audit de sécurité. Une fonction de journalisation est à ajouter au serveur, en tant que développement complémentaire.

Une analyse globale des fichiers source montre des caractéristiques tout à fait satisfaisantes du point de vue de leur qualité.

Serveur MySQL (version 3.22) :

Serveur PostgreSQL (version 6.5) :

3.2.4- Problèmes connus et corrections

Un examen rapide des historiques des versions successives des deux produits étudiés et des mailing lists qui leur sont consacrés sur Internet montre que :

Des efforts appréciables ont été apportés pour associer aux produits eux-mêmes des jeux de tests permettant, pour PostgreSQL, de vérifier la non régression des nouvelles versions et, pour MySQL, de tester les performances et la conformité à SQL 92. Sur ce point, se reporter au § 3.3.2.

En résumé, les produits étudiés présentent une bonne stabilité et une organisation efficace pour faire face à la correction des problèmes résiduels.

Le tableau d'évaluation présente une note pour chaque critère ou, lorsque pertinent, deux notes :

Chaque note est représentée sous forme graphique, comme suit :

M : Fonction inexistante ou mécanisme inutilisable.

L : Caractéristiques insuffisantes : par exemple fonction présentant des lacunes gênantes ou mécanisme de sécurité facile à contourner.

J : Caractéristiques exploitables (même si des améliorations peuvent être préconisées).

Thème

Critère

Note fonction/

mécanisme

Commentaire

Fonctions de sécurité

Identification et authentification des utilisateurs

J /L

Pas d'authentification forte, ni d'authentification mutuelle.

Contrôle d'accès aux données

L /J

Pas de contrôle d'accès obligatoire.

La confiance dans le contrôle d'accès suppose une approche globale de la sécurité (prise en compte des autres critères).

Contrôle d'accès aux services d'administration

L /J

Pas de distinction explicite entre administrateur et simple utilisateur.

La confiance dans le contrôle d'accès suppose une approche globale de la sécurité (prise en compte des autres critères).

Protection des échanges réseau

M

Aucun service natif.

Protection des données stockées

M

Aucun service natif.

Intégrité du logiciel

M

Aucun service natif.

Vulnérabilités particulières liées aux extensions dynamiques (triggers…).

Services d'audit

M

Aucun service natif.

éléments de robustesse

Tolérance aux erreurs

J

Outils de contrôle et réparation des bases de données. Mécanismes transactionnels de PostgreSQL.

Tolérance à la congestion

L

Pas de mécanisme particulier identifié pour éviter le déni de service. Mais bonne disponibilité constatée sur les applications opérationnelles.

Qualité du code

J

Code (C et C++) lisible et bien commenté.

Disponibilité de correctifs aux anomalies répertoriées

J

Bonne réactivité pour les corrections d'anomalies.

Extensions fonctionnelles

Ajout dynamique de fonctions ou procédures

J /L

Mécanismes à protéger en intégrité (cf. fonction " intégrité du logiciel ").

Modification du code source

J

Source disponible et licence autorisant les modifications.

 

3.4.2- Synthèse sur les lacunes et vulnérabilités

Les caractéristiques, en matière de SSI, des deux produits étudiés sont globalement semblables. On notera toutefois que l'ouverture de PostgreSQL à l'utilisation de SSL et Kerberos peut permettre d'atteindre un meilleur niveau de confiance dans les fonctions d'authentification. Cette ouverture correspond cependant à une facilité d'intégration d'un code tiers et non pas à des services disponibles de matière native dans les distributions binaires.

Toute la sécurité native des deux produits étudiés repose sur les services de contrôle d'accès discrétionnaire, or :

Par ailleurs, il est nécessaire de pouvoir disposer d'une confiance suffisante dans les administrateurs du système ce qui suppose d'une part de contrôler l'accès aux fonctions d'administration mais également de pouvoir auditer les accès au SGBD. Enfin, le logiciel du SGBD ne doit pas pouvoir être altéré de façon malveillante ; son intégrité doit être assurée.

Ceci montre la nécessité d'une approche complète prenant en compte les différents critères analysés.

Les lacunes gênantes concernent :

Enfin, aucun service de contrôle d'accès obligatoire n'est prévu (pas de multi-niveaux).

3.4.3- Synthèse sur les solutions pour améliorer la sécurité

Un nombre important de vulnérabilités peut être évité à l'aide de protections externes indépendantes du SGBD lui même :

Cependant des améliorations du logiciel SGBD sont souhaitables. Elles sont possibles, grâce à la disponibilité des sources :

Les différentes lacunes et vulnérabilités techniques peuvent être hiérarchisées (de la plus grave à la moins gênante) en prenant en compte que :

Ces considérations conduisent aux préconisations qui suivent, sachant qu'il s'agit de recommandations générales qui doivent être ajustées en fonctions des cas d'emploi.

3.4.4- Préconisations

En première priorité, les améliorations recommandées pour assurer la sécurité d'un SGBD libre sont les suivantes :

Il est également nécessaire d'assurer un contrôle d'accès efficace au système d'exploitation de l'équipement hébergeant le serveur. Dans les cas où les mesures organisationnelles (contrôle d'accès physique) et les protections natives de l'OS se révéleraient insuffisantes, le recours à un OS sécurisé et/ou à des produits de sécurité locale (indépendants du SGBD) seront nécessaires pour assurer que seuls les administrateurs peuvent accéder à l'OS et pour contrôler l'intégrité du logiciel. Dans tous les cas, la mise en oeuvre d'un anti-virus est préconisée. Lorsque la sécurité locale du serveur ne suffit pas pour éviter le risque d'un accès malveillant depuis le réseau, en contournant les contrôles du SGBD, la protection doit être renforcée par la mise en oeuvre d'un filtre SQL (firewall spécialisé).

Enfin des extensions fonctionnelles du logiciel serveur sont souhaitables pour contrôler l'intégrité des extensions dynamiques et pour disposer d'un service d'audit de sécurité.

Le système de mots passe actuellement utilisé par MySQL pose les deux problèmes suivants :

Pour résoudre ces inconvénients, voici le protocole d'authentification mis en oeuvre pour la maquette. Il nécessite une intervention (modification du code source) sur le client et une sur le serveur.

En introduisant deux aléas, à chaque requête de connexion :

           Serveur                                Client
 
                                     <-----   Sollicitation de connexion 
                                              pour login client, Aléa


 hash(password + Alea 1), Aléa 2     ----->   Le serveur est OK


 Le client est OK                    <-----   hash(password + Alea 2)


 

Notes :

Ce que le protocole résout :

Ce que ce protocole ne résout pas :

Le scénario consiste à connecter/déconnecter plusieurs fois le client au serveur et d'observer le contenu des trames IP :

4.4- Résultats

La réalisation de cette maquette a permis de confirmer l'intérêt de la disponibilité des sources pour améliorer la sécurité du SGBD.

L'implémentation du mécanisme d'authentification mis en oeuvre est très perfectible (connexions simultanées, time-out …), mais sa mise en oeuvre n'a nécessité qu'une charge réduite de développement et intégration de logiciel (quelques jours pour une personne n'ayant pas de connaissance particulière du produit). En extrapolant, l'intégration dans un SGBD libre d'un mécanisme d'authentification forte quelconque, disponible sous forme de sources ou d'API, est possible, avec une charge d'intégration logicielle réduite.

L'exemple du mécanisme d'authentification peut être élargi aux différentes améliorations identifiées par l'étude (au § 3.1) pour lesquelles une modification du source est nécessaire.

5. Conclusions de l'étude

L'étude a permis de mettre en évidence les améliorations nécessaires pour assurer la sécurité d'un SGBD libre. Une partie des préconisations (cf. § 3.4.4) peut être transposée à tout SGBD, car les solutions reposent sur des moyens externes au SGBD lui-même (par exemple protection des échanges réseau). L'intérêt des SGBD libres repose sur la disponibilité des sources et la possibilité de les modifier. Ceci permet d'envisager des solutions qui sont généralement inapplicables à un logiciel commercial.

Pour illustrer cette capacité, une maquette a permis de démontrer la faisabilité d'intégration d'un algorithme d'authentification au sein d'un SGBD libre, en remplacement du mécanisme natif.

En conclusion, les SGBD libres (et plus généralement les logiciels libres) présentent un avantage indiscutable en terme de sécurité, par rapport à leurs concurrents commerciaux, dès lors que l'intégration logicielle de fonctions SSI parfaitement maîtrisées est recherchée.