L’importance capitale des bases de données dans les SI
En effet, ils assurent la persistance, la disponibilité et l’intégrité des données critiques de l’entreprise : les données produits, les données clients, les informations sur le cycle de production et même des données sur ces données (les métadonnées).
Dans le même temps, le SGBD constitue un domaine complexe :
Les compétences requises sont pointues et seuls les experts du domaine peuvent y travailler ;
Les efforts financiers consacrés à la sécurité n’impliquent pas forcément les SGBD ;
Les solutions proposées sont de nature hétérogène : stockage dans les infrastructures de l’entreprise, détenues par un tiers ou encore dans le Cloud.
En parallèle de ces éléments, l’environnement juridique et réglementaire évolue vers une exigence de transparence : les failles de sécurité doivent être tracées.
Dans ces conditions, il est légitime de s’interroger sur les menaces qui pèsent les SGBD et comment en réduire les impacts.
Mettez en place les bonnes pratiques
Gérez les accès aux BDD
La première des menaces qui pèsent sur les SGBD est relative aux accès. Dans ce domaine, je vous propose d’être particulièrement attentifs à quelques axes.
Sécurisez la connexion aux BDD
Tout d’abord, les chaînes de connexion aux BDD ne devraient pas être écrites en dur dans l’application, mais au contraire stockées dans un fichier de configuration distinct sur un système de confiance et devraient être chiffrées. Sur le plan des accès, il faut aussi garder en tête la règle de couper la connexion dès que possible.
Gérez les privilèges d'accès aux BDD
Ensuite, il convient de prévenir les abus de privilèges excessifs et de segmenter les différents privilèges en fonction des droits effectivement acquis. D’une part, en vertu du principe de moindre privilège, les applications devraient se connecter à la base de données uniquement avec le niveau de privilège minimum pour réaliser les opérations nécessaires. D’autre part, pour chaque rôle prédéfini par l’application (utilisateur, éditeur, administrateur), l’accès à la base de données doit être cloisonné.
Une autre règle à appliquer est de minimiser autant que possible les accès vers et depuis le SGBD. Il peut également être intéressant de cartographier les données et les habilitations pour définir les types de populations accédant à la base, et les parties de celle-ci qu'ils sont autorisés à consulter.
Supprimez les comptes par défaut
Enfin, sur la gestion des comptes, il convient de supprimer ou de neutraliser les comptes par défaut et de protéger les accès par des mots de passe forts associés ou non à une authentification multi-facteurs (voir le chapitre sur l'authentification et la gestion des mots de passe).
Protégez-vous des données elles-mêmes
Pour éviter les mésaventures liées aux injections en tous genres et réduire les impacts sur les bases de données, je vous recommande :
D’utiliser des requêtes paramétrées ou préparées fortement typées qui permettent de séparer la requête des données en utilisant des paramètres génériques. La structure de la requête est définie grâce aux paramètres génériques puis combinée avec les paramètres. Cette technique permet de prévenir une modification ultérieure de la requête ;
De vous assurer, côté application, que les variables sont fortement typées ;
De réaliser l’échappement systématique des entrées utilisateur comme vu dans les chapitres précédents.
Configurez avec précaution votre BDD
En premier lieu, des paramètres de compte et de configuration toujours définis par défaut sur une base de données de production peuvent être exploités par l'auteur d'une attaque. Les correctifs de sécurité doivent donc être appliqués en temps et en heure pour réduire les problèmes.
Dans un second temps, il est nécessaire de désactiver toutes les fonctionnalités de la BDD qui ne sont pas strictement nécessaires (les services ou procédures stockés, les packages superflus et les applications périphériques).
Une dernière piste de sécurisation consiste à historiser les transactions réalisées sur vos bases de données, afin de savoir quelles informations ont été traitées, quand, comment et par quel acteur. Avoir un historique des transactions permet d’appréhender les schémas d’accès et les modifications des données afin d’éviter les fuites de données et de détecter les activités suspectes en temps réel.
En résumé
Dans le prochain chapitre, je vous invite à regarder de plus près la gestion des erreurs et des logs.
