La sécurité est aujourd'hui primordiale dans l'ensemble de l'informatique. De temps en temps, nous entendons parler d'attaques de rançongiciels ou de fuites de données qui trouvent leur origine dans des bases de données ou une infrastructure informatique non sécurisées. Vous vous demandez peut-être :quelles sont les meilleures pratiques en matière d'architecture de l'environnement MySQL afin que vous puissiez vous sentir en sécurité avec vos données ? Si oui, ce blog est fait pour vous. Veuillez garder à l'esprit que nous ne couvrirons pas entièrement le sujet - cela conviendrait davantage à un livre blanc qu'à un blog. Nous ferons de notre mieux pour mentionner les aspects les plus importants de la sécurisation de votre base de données MySQL. L'idée derrière ce blog est que le lecteur sache ce qu'il ne sait pas et aide à identifier les sujets et les mots-clés pour des recherches ultérieures. Nous allons l'illustrer avec des captures d'écran de notre produit, ClusterControl, qui est livré avec un vaste ensemble de fonctionnalités, dont certaines autour de la sécurité des bases de données.
Réseau
Tout d'abord, nous devons déployer MySQL quelque part. Qu'il s'agisse d'une instance autonome, d'une réplication asynchrone primaire-réplica ou de l'une des topologies de réplication synchrone les plus avancées comme Galera ou InnoDB Cluster. Quoi qu'il en soit, il doit être protégé au niveau du réseau. La base de données contient les données qui, assez souvent, constituent l'atout le plus précieux de toute une organisation.
Sécuriser l'accès
Les instances de base de données ne doivent jamais être situées sur le réseau public. Les segments de réseau dans lesquels les bases de données sont configurées ne doivent être accessibles qu'à partir d'un nombre limité d'autres réseaux. La règle générale est la suivante :un nœud donné doit-il pouvoir accéder au réseau de la base de données ? Si la réponse est non, les réseaux doivent être séparés.
Bien sûr, tout dépend de la configuration exacte, mais dans les cas les plus courants, où vous avez des couches d'application, de proxy, de cache et de base de données, la configuration la plus typique serait que seul le proxy devrait pouvoir pour accéder à la base de données. Toutes les autres entités doivent être configurées de manière à accéder à la base de données uniquement via la couche proxy. Cette conception est bonne à bien des égards. En plus de la sécurité accrue, cela permet également de masquer la complexité du niveau base de données de l'application.
La couche proxy doit suivre la topologie de la base de données et doit gérer les défaillances des nœuds de la base de données et les changements de topologie. L'application, se connectant à la couche proxy, doit toujours être en mesure d'atteindre un nœud de base de données fonctionnel correspondant au type de la demande. Il en va de même avec la couche de cache. Il peut être implémenté dans la couche proxy, certains proxys comme ProxySQL autorisent les requêtes de cache dans le proxy, mais s'il s'agit d'une couche distincte construite autour, par exemple, de Memcache ou de Redis, elle doit toujours atteindre la base de données via la couche proxy.
Les autres types de nœuds qui peuvent avoir besoin d'un accès direct à la couche de base de données sont les nœuds de gestion - ceux qui sont utilisés par les équipes opérationnelles pour gérer les bases de données. La raison est simple :certaines tâches de maintenance peuvent nécessiter un accès direct aux bases de données. Il peut s'agir de scripts d'automatisation de tâches, de déploiement de playbooks Ansible sur l'ensemble du parc de bases de données ou d'autres tâches. Dans ce cas, évidemment, des mesures de sécurité doivent être en place pour s'assurer que seules les personnes qui y ont accès peuvent se connecter à ce nœud de gestion.
Un autre type possible de nœuds (bien que les nœuds de gestion puissent également être utilisés pour cela) qui peuvent nécessiter un accès à la base de données sont les nœuds impliqués dans la collecte des métriques et leur présentation aux utilisateurs - nous parlons ici de surveillance et activités d'alerte.
VPN
Pour tout type de niveau de base de données couvrant plusieurs centres de données, vous devriez envisager d'utiliser un VPN pour les connecter. Les connexions ouvertes et non chiffrées sur le réseau WAN sont quelque chose qui ne devrait jamais arriver. Même la configuration du cryptage SSL n'est pas la meilleure option car cela nécessiterait d'ouvrir l'accès entre le niveau de la base de données et le WAN - les connexions SSL entre les nœuds de la base de données nécessitent qu'ils puissent se connecter directement. Le VPN résout ce problème en ajoutant un intermédiaire qui crée un moyen sécurisé de connecter les segments du réseau de niveau base de données.
Le VPN devrait également être obligatoire pour tout type d'accès utilisateur au réseau de l'organisation car il met en œuvre une connectivité sécurisée entre un poste de travail et le réseau de production.
Pare-feu
Bien sûr, tout en sécurisant le réseau, nous devrions envisager d'utiliser le pare-feu. De manière générale, chaque nœud de base de données ne doit recevoir que des connexions provenant d'un ensemble défini de sources - noms d'hôte et ports. Même les segments de réseau « requis » ne doivent pas avoir un accès complet au réseau de la base de données, mais uniquement aux ports requis. Si le proxy n'a besoin que de se connecter au port de la base de données, il n'y a aucune raison pour qu'il puisse accéder à un autre port sur les nœuds de la base de données. Veuillez également noter que vous ne devez pas utiliser les ports par défaut. C'est, évidemment, la sécurité par l'obscurité - après tout, le port est ouvert quelque part, mais cela aide à faire face à au moins certaines des intrusions de sécurité qui utilisent des scripts automatisés. Cela n'empêchera pas quelqu'un qui est déterminé à obtenir l'accès, mais peut le ralentir (lorsqu'il est associé à la détection de l'analyse des ports et aux mesures anti-analyse) tout en empêchant les attaques automatisées de réussir.
Sécurité de la base de données
Le réseau est la première ligne de défense, il existe d'autres mesures de sécurité et bonnes pratiques que vous pouvez utiliser pour améliorer encore plus votre sécurité. Certains d'entre eux peuvent être implémentés sur la base de données elle-même.
Utilisateurs et hôtes
Les bases de données elles-mêmes peuvent être utilisées pour implémenter le contrôle d'accès et les restrictions. Pour commencer, vous pouvez implémenter un contrôle d'accès basé sur l'hôte, empêchant les hôtes autres que la courte liste de nœuds de se connecter à la base de données. Bien sûr, si vous avez utilisé un pare-feu pour limiter l'accès, cela peut ressembler à un doublon, mais c'est toujours une bonne idée de limiter l'accès à la base de données elle-même - vous ne savez jamais quand, par accident, un pare-feu sera désactivé. Dans ce cas, vous disposez toujours d'une deuxième couche de protection.
Ce que vous voulez implémenter ici est une liste d'utilisateurs et d'hôtes de base de données autorisés à accéder à la base de données. Très probablement, vous devriez finir par avoir un ou plusieurs utilisateurs autorisés à accéder à partir d'hôtes situés dans la couche proxy. Le degré de détail du contrôle d'accès que vous pouvez avoir dépend du système de base de données dont vous disposez. MySQL, par exemple, ne permet pas un contrôle détaillé des masques de réseau - il utilise simplement /32, /24, /16 ou /8. Dans PostgreSQL, en revanche, vous pouvez utiliser n'importe quel type de masque de réseau.
Subventions
Si c'est ce que votre base de données autorise, chacun des utilisateurs doit avoir un ensemble défini d'autorisations - en s'assurant que les privilèges qui leur sont attribués sont le minimum requis pour que l'utilisateur puisse effectuer les actions qu'il doit faire . Les systèmes de base de données peuvent avoir différents ensembles de privilèges et différents niveaux de ceux-ci. En règle générale, nous avons plusieurs niveaux de privilèges - globaux, affectant l'ensemble du serveur de base de données, niveau schéma - un utilisateur donné peut avoir différents privilèges attribués à différents schémas. Vous pouvez avoir des privilèges au niveau d'une table ou même d'une colonne. Comme nous l'avons mentionné précédemment, l'objectif est de créer l'ensemble minimal de privilèges pour chaque utilisateur. Vous voudrez probablement avoir au moins un utilisateur avec des privilèges élevés - il serait utilisé pour gérer la base de données. Un tel utilisateur doit être strictement limité en matière de connectivité. Il ne devrait pas (et en fait aucun des utilisateurs ne devrait pas) être autorisé à se connecter depuis n'importe quel endroit - il devrait s'agir soit d'un hôte local, soit d'un nœud de gestion particulier, dédié à l'exécution d'opérations sur la base de données.
Gestion des mots de passe
Chaque utilisateur de la base de données doit avoir un mot de passe défini. C'est une évidence. Le mot de passe doit être stocké sous la forme d'un hachage. Vous devez vous assurer que pour stocker les mots de passe, vous utilisez l'algorithme de hachage le plus sûr offert par votre base de données. Les mots de passe ne doivent pas être faciles à deviner ni être vulnérables à l'attaque par dictionnaire. Certains systèmes de bases de données, comme MySQL, vous permettent de définir précisément les exigences auxquelles vos mots de passe doivent répondre pour pouvoir être utilisés. Lettres minuscules et majuscules, chiffres, caractères spéciaux, longueur du mot de passe - tout cela est important et si vous pouvez appliquer certaines politiques concernant la force du mot de passe, vous devriez le faire. Un autre élément important est la rotation des mots de passe. Les mots de passe ne doivent pas être créés une seule fois pour toute la durée de vie de la base de données, vous devez avoir une politique de rotation des mots de passe. Encore une fois, certains des systèmes de base de données peuvent appliquer cela pour vous. L'utilisateur administratif peut être en mesure de créer de nouveaux comptes d'utilisateurs avec la rotation des mots de passe appliquée. Il peut également être en mesure d'imposer la rotation des mots de passe pour un utilisateur donné.
Journaux d'audit
Certains des systèmes de base de données proposent des journaux d'audit - l'idée est de collecter autant d'informations que possible sur l'activité dans la base de données. Qui et quand a fait quoi ? Quelle requête a été exécutée, par qui ? Qui a tenté de se connecter mais a échoué ? De quel hébergeur ? Idéalement, les journaux contenant ces informations seraient stockés en dehors des nœuds de la base de données. Vous pouvez les diffuser sur votre serveur de journaux central pour les conserver, les traiter ultérieurement et améliorer les capacités de recherche.
Sécurité SQL
Nous avons mentionné les utilisateurs et les hôtes, mais l'attaque peut également provenir d'une source différente. Si votre application n'est pas correctement sécurisée et que l'entrée n'est pas correctement validée, vous pouvez être confronté à des attaques provenant de votre site Web. On parle ici d'injection SQL. Dans ce cas, les pare-feu ne sont pas vraiment utiles étant donné que la requête provient d'une source valide (votre serveur Web puis le nœud proxy). L'attribution de subventions peut en fait aider à prévenir certaines de ces types d'attaques, mais ce n'est pas une solution idéale - après tout, votre application, dans la majorité des cas, aura besoin d'un utilisateur qui peut supprimer ou modifier le contenu de la base de données. Un tel utilisateur, lorsqu'il est exploité, peut être utilisé pour faire du mal. Il existe plusieurs façons d'essayer de contrer la friandise.
Pare-feu SQL
La façon la plus simple de le faire est d'implémenter un pare-feu SQL. Elle peut être accomplie à différents niveaux et à différents endroits. L'une des options consiste à utiliser des équilibreurs de charge pour cela. Certains d'entre eux sont livrés avec cette fonctionnalité au moins facilement réalisable si elle n'est pas déjà implémentée. L'idée sous-jacente est de créer une liste de requêtes que votre application exécute, puis de configurer votre proxy pour qu'il ne passe que par ce type de trafic. Ce n'est pas idéal car vous devrez le maintenir dans le temps, en ajoutant de nouvelles requêtes et en supprimant les anciennes qui ne sont plus utilisées. En revanche, un tel ensemble de règles empêchera toute requête non autorisée d'atteindre la base de données.
Détection d'injection SQL
Une autre option possible serait d'implémenter la détection d'injection SQL dans la couche proxy. Il existe quelques solutions, ProxySQL entre autres, qui peuvent être configurées pour tenter de détecter l'injection SQL dans le trafic qui les traverse. Bien sûr, tout cela est basé sur des heuristiques, ce qui peut entraîner des faux positifs, mais cela peut être un bon ajout au pare-feu SQL.
Dans le passé, nous avons discuté de la manière dont vous pouvez implémenter un pare-feu SQL et une détection d'injection SQL à l'aide de ProxySQL, un équilibreur de charge pouvant être déployé à partir de ClusterControl :
https://severalnines.com/database-blog/how-protect-your-mysql-or-mariadb-database-sql-injection-part-one
https://severalnines.com/database-blog/how-protect-your-mysql-or-mariadb-database-sql-injection-part-two
Sécurité des données
Enfin, la sécurité des données. Nous avons discuté jusqu'à présent de la manière de renforcer la base de données, d'en limiter l'accès et d'empêcher différents types d'attaques provenant de l'application elle-même. Nous devrions toujours envisager la protection des données elles-mêmes. Celui-ci peut avoir plusieurs couches. Sécurité physique - si vous êtes propriétaire du centre de données, assurez-vous qu'il est correctement verrouillé. Si vous utilisez des FAI externes ou des fournisseurs de cloud, assurez-vous qu'ils ont mis en place des protocoles de sécurité appropriés lorsqu'il s'agit d'accéder au matériel. Ensuite, nous avons un serveur, une machine virtuelle ou tout ce que vous utilisez. Les données se trouvent sur le disque, stockées localement sur le serveur. Les données sont transférées entre l'application, le proxy et la base de données. Les données sont transférées entre les nœuds de la base de données au moyen de la réplication. Les données sont stockées hors site en tant que sauvegardes. Ces données doivent être protégées.
Sauvegardes
Les sauvegardes doivent toujours être chiffrées. La clé de cryptage doit être conservée avec soin et renouvelée régulièrement.
Données en transit
Les données transférées doivent être cryptées. Assurez-vous d'avoir configuré votre application, la couche proxy et la base de données pour utiliser SSL ou TSL. Tous les moyens de transfert des données entre les nœuds de la base de données doivent également être sécurisés et cryptés. L'objectif est de rendre tout type de reniflage de réseau inutile.
Données au repos
Enfin, les données elles-mêmes, stockées sur le nœud de la base de données. Il doit également être crypté. Il existe plusieurs méthodes que vous pouvez utiliser lorsque vous abordez ce sujet. Tout d'abord, le chiffrement au niveau de l'hôte. Le volume sur lequel la base de données a son répertoire de données peut être chiffré (et déchiffré au démarrage). Les bases de données ont également tendance à être dotées de capacités de cryptage. Ce qui peut être chiffré dépend de la solution exacte et du type et de la version de la base de données, mais dans certains cas, les options sont assez étendues. Chiffrement des tablespaces, chiffrement des logs, parfois même chiffrement des structures en mémoire. Si vous le faites correctement, accéder au nœud de la base de données ne suffira pas pour accéder aux données.
Conclusion
Comme nous l'avons mentionné précédemment, ce blog n'est pas destiné à être un guide pratique de la sécurité des bases de données, mais nous avons abordé la majorité des aspects que vous devez prendre en compte lors de l'architecture de votre environnement de base de données et nous espérons vous trouverez ce guide utile.
