Comment sécuriser votre base de données?

Votre serveur de base de données contient souvent vos données les plus sensibles, telles que les informations confidentielles des utilisateurs. Il est important de mettre en œuvre les meilleures pratiques de sécurité pour minimiser le risque qu'un attaquant accède à votre base de données.

Ce guide s’appliquera en particulier à MySQL, car il s’agit de la base de données la plus courante, mais la plupart de ces concepts s’appliqueront à n’importe quel type de base de données.

Assurez-vous d'exécuter mysql_secure_installation

MySQL a un outil intégré qui peut gérer quelques tâches de sécurité de base. Après avoir installé MySQL, exécutez la commande suivante dans votre terminal:

mysql_secure_installation

Cela vous guidera à travers quelques tâches: définir un nouveau mot de passe, supprimer des utilisateurs anonymes et des bases de données de test, et désactiver la connexion root à distance. Ensuite, il rechargera la configuration de MySQL pour vous, vous devriez donc voir les changements immédiatement.

Verrouiller SSH

Cela n’a techniquement rien à voir avec la base de données elle-même; cependant, votre base de données n'est aussi sécurisée que le serveur sur lequel elle s'exécute. Vous souhaiterez donc prendre les mesures nécessaires pour verrouiller SSH et empêcher la plupart des vecteurs d'attaque courants.

Vous pouvez lire notre guide complet sur la sécurité SSH pour en savoir plus, mais l'essentiel est de quelques étapes:

• Désactivez la connexion par mot de passe, utilisez uniquement les clés SSH.
• La limite de débit a échoué les tentatives de connexion denyhosts pour empêcher la force brute.
• Accès à la liste blanche aux adresses IP de confiance.
• Désactivez la connexion root via SSH. De cette façon, les attaquants doivent connaître votre nom d'utilisateur.
• Configurez l'authentification multifacteur pour SSH si vous êtes vraiment paranoïaque.

Exécuter une base de données autonome dans un sous-réseau privé

Plutôt que d'exécuter une base de données locale sur le même serveur que nginx est en cours d'exécution, il est préférable pour la sécurité d'exécuter votre base de données dans un sous-réseau privé qui n'est accessible que par d'autres serveurs de votre cloud privé. De nombreux fournisseurs de cloud, y compris AWS, offrent ces fonctionnalités.

La configuration ressemble à ceci:

Votre cloud privé virtuel (VPC) est simplement le conteneur dans lequel toutes vos ressources AWS s'exécutent. Les éléments de ce cloud peuvent communiquer entre eux sur leurs adresses IP privées, tout comme les appareils de votre maison interagiraient.

Les serveurs du sous-réseau public auront des adresses IP publiques et seront directement accessibles par n'importe qui. Les serveurs du sous-réseau privé n'ont pas d'adresse IP publique, mais uniquement privée. Cependant, ils peuvent toujours accéder à Internet en utilisant la traduction d'adresses réseau, la même méthode qui donne à votre ordinateur l'accès derrière un routeur domestique.

Cela signifie que tous les serveurs lancés dans le sous-réseau privé seront entièrement inaccessible d'attaquants extérieurs. La seule façon d'accéder à votre base de données est si le serveur Web est compromis, et même dans ce cas, il faudrait toujours une élévation de privilèges.

En plus des avantages de sécurité, cette configuration est également beaucoup plus facile à mettre à l'échelle. Par exemple, vous pouvez avoir quatre serveurs Web exécutant WordPress qui se connectent tous à un seul serveur de base de données faisant autorité. De cette façon, les quatre serveurs Web sont synchronisés et vous pouvez facilement augmenter et réduire la demande pour répondre à la demande, sans vous soucier de la base de données. Cela peut entraîner des problèmes de performances en raison de la surcharge réseau, mais avec une mise en cache multicouche appropriée, le problème est minime par rapport aux avantages architecturaux.

Pour que MySQL n'accepte que les connexions provenant de connexions privées, vous souhaiterez utiliser un masque de réseau dans votre instruction GRANT. Cela ne fonctionne pas avec la notation CIDR, mais uniquement avec le masque de réseau complet.

GRANT ALL ON database.* TO 'user'@'10.0.1.0/255.255.255.0' IDENTIFIED BY 'password'

Si vous envisagez d’exécuter un seul serveur, vous devez au moins lier votre base de données à localhost afin qu’elle ne soit de toute façon pas accessible depuis Internet ouvert.

Lier à Localhost si possible (ou au moins un port différent)

Si vous n’accédez pas à votre serveur de base de données à partir d’autres processus que d’autres processus exécutés sur la machine elle-même, vous pouvez le verrouiller pour qu’il ne soit pas accessible sur le réseau. Bien sûr, cela ne fonctionne que si vous avez un serveur qui exécute tout, et ce n’est pas la meilleure configuration en premier lieu.

Si vous ne pouvez pas vous lier à localhost, il est judicieux de remplacer le port par défaut par un autre.

Dans tous les cas, vous pouvez accomplir cela assez facilement en liant MySQL à localhost, ce qui signifie qu'il n'écoutera que sur l'adresse de bouclage, et non sur les ports ouverts. S'ouvrir /etc/mysql/my.conf dans votre éditeur de texte préféré et ajoutez la ligne suivante dans le (mysqld) section:

bind-address = 127.0.0.1

Vous pouvez également modifier le port par défaut à partir de cette même section:

Port=5000

Redémarrez MySQL et vous devriez voir les changements.

Regardez votre histoire Shell

La plupart des choses que vous faites sous Linux sont enregistrées. Si un attaquant parvient à accéder à ces fichiers journaux, il pourrait augmenter ses privilèges en trouvant les mots de passe qui y sont stockés.

Cela peut se produire de deux manières principales pour MySQL, qui sont toutes deux facilement évitables. Le premier est lorsque vous vous connectez au shell MySQL – vous ne voulez jamais spécifier le mot de passe comme argument sur la ligne de commande. Laissez-le toujours vide et laissez MySQL le demander.

mysql -u root -p

Sinon, il est visible à l'aide de history commander.

MySQL a également son propre fichier d'historique, stocké à ~/.mysql_history. Cela n’enregistre évidemment pas le mot de passe que vous utilisez pour vous connecter, mais si vous avez créé un nouvel utilisateur à partir de la ligne de commande MySQL, cette déclaration sera enregistrée – mot de passe et tout. Vous souhaiterez effacer ce fichier par précaution si jamais vous devez modifier des comptes d'utilisateurs.

# cat /dev/null > ~/.mysql_history

Si vous utilisez AWS, envisagez d'utiliser RDS

Le service de base de données relationnelle (RDS) d'AWS est une base de données entièrement gérée dans le cloud. Si vous ne voulez pas avoir à vous soucier de la sécurité de la base de données et que vous voulez simplement une solution déployable, RDS (et tous les autres services de base de données gérés d’AWS) vous soulagera du mal de tête.

RDS utilise le propre système de gestion des identités et des accès (IAM) d'AWS. IAM gère les autorisations pour tout ce que vous faites sur AWS. Chaque action de la console de gestion Web, des commandes CLI et des demandes d'API doit toutes passer par IAM. Toute action sera bloquée si l’utilisateur ou l’entité en cours d’exécution n’a pas explicite l'autorisation d'accéder à la ressource donnée. De plus, RDS est privé par défaut, vous n'aurez donc pas à vous soucier des attaques provenant d'Internet ouvert.

Cependant, vous finirez toujours par utiliser l'authentification par nom d'utilisateur et mot de passe MySQL standard pour vous connecter à la base de données elle-même. IAM sécurise simplement tout le reste de la base de données, comme la configuration. Cependant, vous pouvez utiliser Secrets Manager d'AWS, qui vous permet de faire constamment pivoter les clés de sécurité sans redéploiement de code, et qui a intégré l'intégration pour le démarrage de RDS.

Si vous le souhaitez, vous pouvez également activer l'authentification de base de données IAM, ce qui vous permettra de contourner complètement l'authentification par mot de passe et d'utiliser simplement IAM. Cependant, cela ajoute une surcharge et, en tant que tel, est limité à 200 nouvelles connexions par seconde pour MySQL.