Que vous utilisiez SQL Server de Microsoft (bientôt sous Linux) ou MySQL open source, vous devez verrouiller vos bases de données pour garder vos données privées et sécurisées. Ces 11 étapes vous guideront à travers certains des principes de base de la sécurité des bases de données et comment les mettre en œuvre. Associé à une configuration de serveur Web renforcée, un serveur de base de données sécurisé empêchera une application de devenir un point d'entrée sur votre réseau et empêchera vos données de se retrouver déversées sur Internet. Lors du provisionnement d'un nouveau serveur SQL, n'oubliez pas de prendre en compte la sécurité dès le début ; Cela devrait faire partie de votre processus habituel et non être appliqué de manière rétroactive, car certaines mesures de sécurité clés nécessitent des modifications fondamentales de la configuration pour les applications et les serveurs de bases de données installés de manière non sécurisée.
1. Isolez le serveur de base de données
Les serveurs de bases de données de production doivent être isolés autant que possible des autres applications et services. Les serveurs de bases de données dédiés occupent moins d'espace et ont donc une surface d'attaque plus petite, et il n'y a pas lieu de s'inquiéter des ressources concurrentes ou du trafic conflictuel. Les systèmes d'exploitation doivent être agiles, avec uniquement les services nécessaires installés et exécutés. N'installez pas d'autres applications à moins qu'elles ne soient requises par le serveur de base de données.
En fonction de la taille de votre environnement, vous devez envisager de placer votre serveur SQL sur un segment VLAN/réseau restreint afin que seul le trafic autorisé puisse passer. En règle générale, seul un serveur d'applications ou un serveur Web communiquera directement avec la base de données. Des politiques réseau assez restrictives peuvent donc être mises en œuvre pour empêcher les connexions illicites. Cela devrait aller de soi, mais vous ne devez jamais ouvrir votre serveur de base de données à Internet sur les ports 1433/1434 (MSSQL) et 3306/3307 (MySQL).
2. Adaptez l'installation de la base de données
MSSQL et MySQL offrent tous deux des tonnes de fonctionnalités supplémentaires, dont vous n'aurez probablement pas besoin pour la plupart dans un cas particulier. En supprimant les pièces dont vous n'avez pas besoin, vous réduisez les raids potentiels à des fins d'exploitation. Si vous souhaitez conserver une fonctionnalité que vous n'utilisez pas déjà, faites-le dans un environnement de test ou de développement ; Il est préférable de maintenir la production verrouillée autant que possible, surtout avant de déterminer les effets qu'un nouveau module peut avoir sur votre environnement.
3. Gardez-le à jour
MSSQL et MySQL reçoivent périodiquement des correctifs, alors assurez-vous de garder votre version à jour. La plupart des vulnérabilités exploitées sont connues depuis plus d'un an, donc l'installation de correctifs de sécurité en temps opportun peut empêcher la plupart des attaques en colmatant simplement ces failles. Disposer d'un calendrier et d'un protocole de mise à jour réguliers peut aider à déployer des mises à jour dans un environnement de test afin que tout effet négatif puisse être découvert sans perturber la production. De nombreux magasins n'ont pas ce luxe et volent par leurs propres moyens, installant les mises à jour directement en production et espérant le meilleur. Habituellement, cela fonctionne, heureusement, mais lorsque ce n'est pas le cas, il peut tomber en panne rapidement, alors comprenez au moins les options et la procédure de restauration, ainsi que ce que le correctif change exactement.
4. Restreindre les processus de base de données
L'utilisateur sous lequel le service de base de données s'exécute détermine l'accès dont disposent les processus de base de données au reste du serveur, y compris le système de fichiers, la possibilité d'exécuter des programmes, etc. Comme pour la plupart des applications Linux, MySQL s'exécutera généralement avec un compte utilisateur MySQL dédié avec des autorisations minimales sur le reste du serveur. Vous pouvez vérifier cela avec une simple commande ps et vous assurer que MySQL n'a pas été configuré pour s'exécuter en tant que root, ce qui arrive certainement, surtout dans des circonstances extrêmes, lors du dépannage d'un problème de panne, par exemple, et ne se reconfigure pas une fois la crise évitée.
Mais sur les installations Windows, MSSQL est souvent exécuté en tant que système local ou en tant que compte administrateur, permettant un accès complet aux processus de base de données, y compris les procédures stockées et les interfaces de shell de commande telles que xp_cmdshell. Idéalement, MSSQL devrait fonctionner en tant que compte local dédié, non administrateur et le moins privilégié. Les assistants d'installation MS les plus récents peuvent même automatiser cette étape, donc si vous installez un nouveau serveur, assurez-vous de configurer cette option. D'autres services SQL, tels que SQL Agent, doivent également s'exécuter en tant que comptes locaux restreints, avec des autorisations accordées si nécessaire, par exemple sur un répertoire de sauvegarde.
Le non-respect de cette étape peut permettre à un serveur de base de données compromis de compromettre le reste de la machine et éventuellement d'infiltrer le réseau.
5. Restreindre le trafic SQL
Comme mentionné à la première étape, les serveurs de bases de données n'ont généralement qu'un seul autre serveur (ou plusieurs) connecté. Si tel est le cas, l'accès au serveur sur les ports de la base de données doit être bloqué ailleurs. En autorisant uniquement le trafic SQL vers et depuis les adresses IP désignées, vous pouvez être sûr qu'un acteur malveillant ou un client infecté à l'intérieur du pare-feu n'attaquera pas votre serveur. Dans certains cas, les clients devront se connecter directement au serveur de base de données, par exemple avec une application client lourd. La même logique s'applique ici, limitant ces connexions SQL aux adresses IP spécifiques (ou au moins au segment IP) qui en ont besoin. Puisqu'il s'agit de points de terminaison, assurez-vous de les protéger correctement, car les logiciels malveillants peuvent analyser et attaquer les serveurs SQL. Vous pouvez gérer cela avec iptables sous Linux, le pare-feu Windows ou, de préférence, un pare-feu dédié.
6. Utilisez le moindre privilège lors de l'attribution d'autorisations
Les utilisateurs de bases de données, comme les utilisateurs de n’importe quel système, ne devraient avoir que l’accès dont ils ont besoin pour effectuer leurs tâches, également connu sous le nom de principe du moindre privilège. Si possible, évitez toutes les autorisations dans MySQL et l'adhésion au rôle d'administrateur système dans MSSQL. Envisagez d'accorder un accès en lecture aux vues plutôt que directement aux tables, afin de protéger les champs sensibles si nécessaire. Les procédures stockées, les plans de maintenance et autres tâches automatisées doivent être exécutés en tant qu'utilisateurs dédiés disposant de l'ensemble d'autorisations approprié. Cette mesure empêche toute partie du serveur de base de données, ou tout utilisateur malveillant ou compromis, de détruire l'intégralité du système. Plusieurs fois, les instructions de l'application vous demanderont de placer vos utilisateurs dans un rôle d'administrateur à accès complet. Cela va à l'encontre des meilleures pratiques générales et représente généralement une programmation bâclée qui nécessite plus d'accès qu'elle ne le devrait, ou un désir de supprimer la sécurité des considérations de prise en charge, qui ne tiennent pas compte du meilleur intérêt de vos données. Il faut donc toujours réfléchir à l'impact de la mise en œuvre de comptes d'application sur votre résilience globale.
7. Définissez un mot de passe administrateur fort
Dans MSSQL, le compte sa est utilisé chaque fois que l'authentification en mode mixte est sélectionnée. Microsoft recommande d'utiliser l'authentification Windows intégrée, mais de nombreuses applications nécessitent un mode mixte pour prendre en charge les utilisateurs de leur base de données et leurs chaînes de connexion. Si l'authentification en mode mixte est activée, veillez à protéger le compte sa avec un mot de passe complexe pour éviter qu'il ne soit forcé.
De même, l'utilisateur root MySQL doit disposer d'un mot de passe complexe. Si quelqu'un analyse votre serveur de base de données, la première chose qu'il fera est d'essayer de se connecter avec le compte administrateur par défaut, donc si vous ne le bloquez pas, vous pouvez totalement compromettre votre système.
8. Auditer les connexions à la base de données
Une partie de votre journalisation et de votre surveillance globales doit inclure un audit de connexion pour votre base de données SQL. Au minimum, ces journaux s'avéreront utiles dans des situations médico-légales, mais s'ils sont surveillés régulièrement ou même intégrés dans un système de notification automatisé, les échecs de connexion répétés peuvent vous alerter des attaques et d'autres problèmes avant qu'ils ne deviennent critiques, vous permettant de désactiver les utilisateurs compromis ou de modifier leurs mots de passe, tandis que la journalisation des connexions réussies conserve une trace des administrateurs, des utilisateurs et des applications connectés, vous aidant ainsi à résoudre les problèmes et à gérer les modifications.
9. Sécurisez vos sauvegardes
Devinez quoi? Vos sauvegardes contiennent les mêmes données que vos bases de données de production et doivent être protégées avec autant de soin que le serveur lui-même. Cela peut impliquer de verrouiller les répertoires de sauvegarde, de restreindre l'accès au serveur ou au stockage qui héberge les données, de sécuriser physiquement les supports amovibles, l'accès réseau aux sauvegardes et de vérifier qui a accès pour effectuer et accéder aux sauvegardes. N'oubliez pas que les sauvegardes font partie de votre écosystème de données en matière de sécurité ou que quelqu'un pourrait simplement franchir la fenêtre ouverte pour contourner la porte barricadée.
10. Protéger contre l'injection SQL
Lorsqu'une application Web accepte les entrées de l'utilisateur et les envoie à la base de données, des données non nettoyées peuvent « injecter » du code malveillant dans le serveur et effectuer des tâches non autorisées, notamment obtenir un accès complet au shell, en fonction de la configuration du serveur. Appelée injection SQL, il existe plusieurs façons d'atténuer ces attaques, y compris l'étape 6 ci-dessus, qui restreint la capacité des utilisateurs à effectuer des tâches non autorisées, mais il n'existe en réalité qu'une seule façon de les empêcher : utiliser des procédures stockées au lieu de requêtes SQL directes pour l'interaction avec les applications Web.
Les procédures stockées n'acceptent que des paramètres prédéfinis et ne peuvent exécuter que des fonctions très spécifiques, évitant ainsi l'injection de données dans une requête SQL brute. Il s'agit d'une bonne pratique depuis de nombreuses années, mais de nombreuses applications de production exécutent encore du code comportant des vulnérabilités SQL, l'une des vulnérabilités les plus couramment exploitées sur Internet.
11. Visibilité continue
Tout configurer en toute sécurité peut vous éviter bien des ennuis à l’avenir. Mais la seule façon de garantir la sécurité de votre système de base de données est d’avoir une visibilité constante sur son état de configuration, en exécutant des tests basés sur une politique que vous créez. De cette façon, vous serez averti lorsque quelque chose change, par exemple si un nouvel utilisateur de base de données est ajouté en tant qu'administrateur système ou si des autorisations de propriétaire de base de données sont accordées. Sans quelque chose comme ça, vous supposez essentiellement que rien n'a changé depuis votre dernière vérification, ou même si vous voulez en être sûr, vous devez collecter manuellement vos informations de configuration, ce qui prend du temps et finalement inutile, car effectuer la même vérification à l'avenir nécessiterait une réplication de cet effort. UpGuard offre une visibilité continue sur vos systèmes de bases de données SQL, ainsi que sur le reste de vos serveurs et périphériques réseau.
