Les bases de la sécurité des SGBD : un pas à pas

Les injections de code SQL et les dépassements de tampons sont des vulnérabilités classiques des SGBD qui sont exploitées depuis plus de dix ans et restent pourtant parmi les plus connus des vecteurs d’attaques de bases de données, même sur des systèmes sur lesquels ont été appliqués les derniers correctifs. Les hackers font aussi fréquemment usage du fait que les administrateurs utilisent les logins et mots de passe par défaut de la base, pendant que, dans le même temps, les administrateurs de bases de données se plaignent du coût associé à la gestion et au provisionning des comptes utilisateurs....

Enfin, on apprend régulièrement, notamment du fait des obligations de divulgation d’intrusion dans certains pays comme les Etats-Unis que des données censées être sécurisées transitent par des systèmes non sécurisées ou que des informations stockées sur des bandes non chiffrées sont égarées (le dernier paquet télécom, voté fin 2009, contient une disposition qui va contraindre les opérateurs à avertir leurs abonnés d’éventuelles intrusions touchant à leurs données privées).

Bref, il est clair que malgré les avertissements, nombre d’administrateurs négligent encore les recommandations les plus basiques en matière de sécurisation de leurs bases de données. Avant de mettre l’accent sur des technologies avancées comme le chiffrage, la corrélation ou l’investigation numérique légale (forensic analysis), les entreprises doivent donc s’assurer qu’elle respectent le b.a.-ba et qu’elles mettent en œuvre une approche claire, concrète et pragmatique de la sécurité des base de données.

Pour faire simple, nous avons recensé ci-après une liste de contrôles rapides qui couvre la configuration des bases de données, la protection des données, la gestion des comptes utilisateurs, les interactions entre OS et SGBD, ainsi que quelques éléments concernant les applications placées en frontal des bases de données. Si ces fondements ne sont pas respectés, il n’est même pas utile de se préoccuper de fonctions de sécurité avancées.

- Contrôle d’accès et gestion des autorisations

Vous pourriez être tentés de sauter cette étape car vous pensez avoir déjà mis en place des contrôles d'accès, avant d’échouer à une enquête de sécurité. Ce n’est pas parce que vous avez mis en place un système de contrôle d'accès que votre système est sécurisé. La gestion de l’authentification sur une base de données et l'authentification des utilisateurs sur un domaine sont deux choses bien différentes, et il faut prendre grand soin à coordonner ces deux formes de sécurisation de façon à ce qu’aucun utilisateur ne puisse contourner entièrement les autorisations d’accès aux bases de données.

L’authentification est la première ligne de défense pour assurer la sécurité des bases de données et des données qu’elles contiennent. Il est donc important de bien gérer les comptes utilisateurs et surtout de s’assurer de leur maintenance dans le temps.

• Tout d’abord, il est impératif de changer les mots de passe utilisateur par défaut immédiatement après l'installation de la base de données. Il est aussi important de vérifier périodiquement qu'ils n'ont pas été remis à zéro à l’occasion d’une réinstallation ou d’une mise à jour. Ensuite, il est recommandé de verrouiller les comptes utilisateurs qui ne sont pas régulièrement utilisés. Mieux, si vous êtes certain qu'ils ne seront jamais utilisés, supprimez-les. Ceci est particulièrement important pour les bases de tests, les bases de démonstration ou celle utilisées pour des tutoriaux. Souvent ces bases sont en effet configurées avec des comptes par défaut qui pourraient permettre à des utilisateurs mal intentionnés d’accéder à des fonctions de bases de données qui leur sont habituellement restreintes ;
• Une autre recommandation est d’être intransigeant dans la mise en œuvre de mots de passe forts ou mieux de systèmes d’authentification forte. Si vous utilisez les authentifications de domaine pour contrôler les accès aux bases de données, vous pouvez définir des politiques relatives aux mots de passe forts. Notre recommandation est d’exiger une rotation régulière des mots de passe, et d’éviter comme la peste l’usage de mots de passe statiques ;
• Supprimez aussi tous les comptes publics ainsi que les accès publics à tous les comptes. Il n'y a pas tout simplement aucun cas d'utilisation qui justifie le maintien d’un accès public à une base de données ;
• Pour ce qui est du mécanisme d’authentification, choisissez une fois pour toute entre l’authentification au niveau du SGBD ou l’authentification par domaine, et collez à votre décision. Evitez de mêler les deux sous peine d’introduire des confusions et de compliquer la gestion des droits ;
• Examinez les rôles et les groupes de près. Listez les autorisations des utilisateurs, les rôles et les participations aux groupes et faites en une revue en détail afin de garantir que les différents utilisateurs ont juste assez de droits pour effectuer leur travail ;
• Bien sûr cela exige du temps, d’autant plus que le nombre d’utilisateurs du SGBD est élevé. Et même lorsque des outils automatiques d’audit des autorisations sont disponibles pour inventorier les droits de chaque utilisateur, il faut tout de même revoir à la main les réglages pour détecter et corriger les problèmes. Ce n’est pas un travail drôle, et dans le cas de grandes instances de bases de données, il faut parfois passer beaucoup de temps pour s’assurer que les bons utilisateurs disposent des bonnes autorisations. La bonne nouvelle est que si ce travail est fait régulièrement, il devient bien plus simple de détecter les modifications non souhaitées et de retirer les privilèges d’accès excessifs ;
• Il est aussi important de s’assurer qu’un simple utilisateur ne peut avoir accès aux fonctions d’administration (il est prudent par exemple de ne pas déléguer les tâches donnant accès à la configuration des rôles, aux procédures stockées ou aux outils de maintenance de la base). De même il est prudent de diviser les tâches d’administration s’il y a plusieurs DBA. Chacun doit alors disposer de son propre login et mot de passe de façon à bien séparer les rôles. Dans ce contexte, verrouiller le compte maître DBA peut aussi être une bonne idée.

- Evaluer la configuration de la base de données

Ceci est très important pour déterminer la sécurité et l’intégrité opérationnelle de la base.

• Découvrez comment vos bases de données sont configurées par le biais de requêtes, d'analyse des fichiers de configuration, ou en utilisant un outil d’audit fourni avec la base. Tous les fournisseurs de bases de données ont une liste de meilleures pratiques et recommandent des configurations et des paramètres de sécurité type. Il ne faut que peu de temps pour comparer votre installation avec la norme ;
• Supprimez les modules et services dont vous n'avez pas besoin. Vous n'utilisez pas la réplication ? Désinstallez le module associé et supprimez ce package du système. Le fait que les composants que vous n’utilisez pas ne soient pas installés limite la surface d’attaque de la base de données ;
• Documentez une configuration de référence pour vos bases de données. Cette configuration servira de ligne directrice pour tous les administrateurs et permettra de détecter les systèmes non conformes. Enfin, utilisez régulièrement des outils d’audit pour inventorier vos bases de données et soyez cohérent dans la façon dont vous appliquez vos paramètres de configuration.

- Evaluez les interactions entre la base de données et la plate-forme système.

Toutes les bases fournissent des moyens pour appeler directement des commandes du système d'exploitation sous-jacent afin de réaliser des tâches administratives. Ces outils s’appuient sur des outils OS associés à des permissions système et ouvrent un chemin de communication bi-directionnel entre l’OS et la base de données. Les recommandations suivantes visent à combler les éventuelles failles de sécurité à la frontière entre ces deux composants.

• Désactivez les procédures stockées externes ou étendues ;
• Assurez-vous que le compte de base de données sur le serveur local ne dispose pas de fonctions d’administration du domaine ;
• Assurez-vous que les administrateurs de domaine ne sont pas les administrateurs de base de données ;
• Liez les outils d’importation / exportation, les scripts de démarrage, les fichiers de préférences au compte utilisateur sous lequel s’exécute le SGBD.

- Sécurisez les communications

Il est impératif de s’assurer que les communications avec la base de données s’effectuent de façon sécurisée.

• Chiffrez les sessions entre les applications et la base de données, en particulier les connexions vers les applications Web ;
• Utilisez des ports de communication non standard. Par exemple, le port TCP par défaut pour l’accès à une base Oracle est le 1521. Le remplacer par un port choisi au hasard permet d’éviter la plupart des attaques automatiques et rend plus difficile pour un attaquant de sonder votre système pour chercher d’éventuelles failles ;
• Bloquez les connexions ad-hoc. les connexions provenant de sites non désirés ou effectuées à des heures non prévues ou par des applications non approuvées peuvent être détectées et rejetées par une bonne configuration des mécanismes d'authentification, du pare-feu et de certains systèmes de contrôle d'accès.

- Appliquez régulièrement les correctifs du SGBD

Appliquer les correctifs, c’est s’appuyer sur l'expertise en sécurité du fournisseur de base de données. Cela suppose d’avoir un processus en place pour qualifier et installer les correctifs distribués par l’éditeur aussi régulièrement que possible. Pour cela, il faut typiquement :

• Créer un environnement et les processus nécessaires pour valider les fonctions d’un correctif avant son déploiement en production ;
• Ne pas autoriser le téléchargement de patchs directement par les DBA, mais disposer de copies centralisées, approuvées et vérifiées ;
• Synchroniser le cycle d’application de correctifs internes avec le cycle de publication de l’éditeur ;
• Modifier la configuration de la base au cas ou l’altération des fonctions de la base de données par le correctif s'avère inacceptable. Si possible, configurez vos pare-feu applicatifs pour bloquer la menace jusqu'à ce qu'un correctif plus approprié soit disponible.

- Contrôler l’usage du SGBD par les applications

Les applications d’entreprise et les applications Web font plus qu’employer les fonctions de stockage du SGBD et disposent de comptes utilisateurs possédant parfois de droits étendus. Il est donc important de segmenter les autorisations entre les utilisateurs communs et les comptes « applicatifs »

• Limitez les regroupements de connexions, où un compte de base de données unique est mis en œuvre par tous les utilisateurs de la base de données. Si possible, regroupez par groupe cohérents les différentes fonctions de l’application et assignez à chacun de ces groupes un compte d'utilisateur spécifique. Cela permet un bien meilleur contrôle des droits selon les processus, mais aussi facilite l’analyse des logs ;
• Modifiez vos applications pour que la connexion de base de données soit associée à un utilisateur final. Cela rend aussi l’audit et l’application des politiques utilisateurs plus simple.

- Sécurisation des supports de stockage

Protéger les supports de sauvegarde n'est pas une option, car la perte de supports est la principale cause de violations de données. Il existe plusieurs méthodes disponibles qui ne nécessitent pas une modification des processus ou des applications, y compris le chiffrement transparent de la base de données, qui est souvent offert par les fournisseurs.

- Analyse des logs et journaux d’événements

• Utilisez la journalisation si vous le pouvez ;
• Créez une politique de conservation des journaux, déterminez quels événements sont inutiles et filtrez-les ;
• Examinez les journaux périodiquement, en mettant l'accent sur les défaillances des fonctions système et des logins qui indiquent généralement des tentatives externes d’analyse de votre système ;
• Passez en revue de façon régulière les paramètres de journalisation.

- Acceptez l’insécurité !
Peu importe ce que vous faites, il n'existe pas de système sûr à 100 %. Il est donc important de planifier votre réaction en cas de faille de sécurité.

• Maintenez un inventaire de vos bases de données ;
• Découvrez et cataloguez vos données sensibles ;
• Ayez des procédures en place en cas de vol ou de perte de données (et notamment veillez à contacter les autorités compétentes en la matière ; elles peuvent être d'une aide précieuse) ;
• Ayez un plan de reprise après sinistre ;
• Créez une culture de coopération entre développeurs et DBA et assurez-vous qu'ils comprennent que tout le monde doit travailler ensemble. Si vous avez un groupe en charge du contrôle de conformité, prenez en compte son avis et ses conseils.

- Pour la conformité, surveillez le chiffrement et mettez en place une politique d‘audit

Si vous manipulez des données sensibles, il est vraisemblable que vous deviez vous conformer à certaines réglementations imposées par votre industrie ou par le gouvernement. Souvent cela implique l’usage du chiffrement de données et un audit régulier de vos systèmes et procédures. Bien sûr, il est possible de s’appuyer sur les outils standards fournis par l’éditeur de SGBD, mais étant donné la difficulté de mise en œuvre, de déploiement et d’administration de ces systèmes, il est vraisemblable que vous aurez à acheter des outils pour alléger la gestion quotidienne et les questions de performance. Utiliser les outils standards permet certes de collecter les données, mais nécessite la mise en place d’un processus interne et de rapports appropriés pour démontrer la conformité. Des outils commerciaux apportent des rapports prêts à l’emploi adaptés à de multiples réglementations et offrent souvent de meilleures performances.

Il existe de nombreuses formes de chiffrement de bases de données. Elles se répartissent en deux grandes familles: le chiffrement transparent, qui couvre toute la base et ne requiert aucune modification des processus métier, et le chiffrement utilisateurs qui ne s’applique qu’à des objets spécifiques de la base de données, mais nécessite la modification du code de l'application. Le chiffrement transparent est vraiment adapté pour protéger les données sur les supports de stockage, tels que disques durs ou bandes magnétiques. Le chiffrement utilisateur peut être utilisé à la fois pour la protection des supports et pour protéger des données d’une utilisation abusive.

Pour répondre aux contraintes réglementaires, des dispositifs comme le chiffrage transparent ne sont pas suffisants pour répondre aux exigences telles que celles de PCI DSS (Payment Card Industry Data Security Standard), même s’ils sont suffisants pour nombre d’autres applications. Comme le coût et la complexité sont radicalement différents entre ces deux options, une évaluation précise de la technologie adaptée à votre besoin est nécessaire avant de décider quelle voie choisir.

Par Adrian Lane

Adrian Lane est un analyste en sécurité conformé chez Securosis, société de conseil et de recherche en sécurité.