La sécurité est l'un des aspects les plus importants de l'exécution d'une base de données. Que vous soyez développeur ou DBA, si vous gérez la base de données, il est de votre responsabilité de sauvegarder vos données et de les protéger de tout type d'accès non autorisé. Le fait malheureux est que de nombreuses organisations ne protègent pas leurs données, comme nous l'avons vu lors de la nouvelle vague d'attaques de rançongiciels MongoDB en septembre 2017. Nous avions précédemment publié un blog sur la façon de sécuriser les bases de données MongoDB.
Dans cet article de blog, nous verrons comment sécuriser vos bases de données à l'aide de ClusterControl. Toutes les fonctionnalités décrites ici sont disponibles dans la version 1.5.1 de ClusterControl (sortie le 23 décembre 2017). Veuillez noter que certaines fonctionnalités ne sont disponibles que pour certains types de bases de données.
Cryptage de sauvegarde
ClusterControl 1.5.1 a introduit une nouvelle fonctionnalité appelée cryptage de sauvegarde. Toutes les sauvegardes chiffrées sont marquées d'une icône de cadenas à côté :
Vous pouvez utiliser cette fonctionnalité sur toutes les méthodes de sauvegarde (mysqldump, xtrabackup, mongodump, pg_dump) prises en charge par ClusterControl. Pour activer le cryptage, activez simplement le commutateur "Activer le cryptage" lors de la planification ou de la création de la sauvegarde. ClusterControl génère automatiquement une clé pour chiffrer la sauvegarde. Il utilise l'algorithme de chiffrement AES-256 (CBC) et effectue le chiffrement à la volée sur le serveur cible. La commande suivante montre un exemple de la façon dont ClusterControl effectue une sauvegarde mysqldump :
$ mysqldump --defaults-file=/etc/my.cnf --flush-privileges --hex-blob --opt --no-create-info --no-data --triggers --routines --events --single-transaction --skip-comments --skip-lock-tables --skip-add-locks --databases db1 | gzip -6 -c | openssl enc -aes-256-cbc -pass file:/var/tmp/cmon-094508-e0bc6ad658e88d93.tmp | socat - TCP4:192.168.55.170:9999'Vous verriez l'erreur suivante si vous tentiez de décompresser une sauvegarde chiffrée sans la déchiffrer au préalable avec la clé appropriée :
$ gunzip mysqldump_2018-01-03_175727_data.sql.gz
gzip: mysqldump_2018-01-03_175727_data.sql.gz: not in gzip formatLa clé est stockée dans la base de données ClusterControl et peut être récupérée à partir du fichier cmon_backup.metadata pour un jeu de sauvegarde particulier. Il sera utilisé par ClusterControl lors de la restauration. Le chiffrement des sauvegardes est fortement recommandé, en particulier lorsque vous souhaitez sécuriser vos sauvegardes hors site, comme les archiver dans le cloud.
Cryptage client-serveur MySQL/PostgreSQL
En plus de suivre les étapes de sécurité recommandées lors du déploiement, vous pouvez augmenter la fiabilité de votre service de base de données en utilisant le chiffrement SSL client-serveur. À l'aide de ClusterControl, vous pouvez effectuer cette opération d'un simple pointer-cliquer :
Vous pouvez ensuite récupérer les clés et certificats générés directement depuis l'hôte ClusterControl sous
Chiffrement de réplication de base de données
Le trafic de réplication au sein d'un cluster Galera peut être activé en un seul clic. ClusterControl utilise une clé par défaut de 2048 bits et un certificat généré sur le nœud ClusterControl, qui est transféré à tous les nœuds Galera :
Un redémarrage du cluster est nécessaire. ClusterControl effectuera une opération de redémarrage continu, en prenant un nœud à la fois. Vous verrez une icône de cadenas vert à côté du serveur de base de données (Galera indique le cryptage Galera Replication, tandis que SSL indique le cryptage client-serveur) dans la grille Hôtes de la page Présentation une fois le cryptage activé :
Toutes les clés et tous les certificats peuvent être gérés directement sous Gestion des clés, comme décrit plus bas.
Gestion des clés
Toutes les clés et tous les certificats générés peuvent être gérés directement depuis l'interface utilisateur de ClusterControl. La gestion des clés vous permet de gérer les certificats et les clés SSL qui peuvent être provisionnés sur vos clusters :
Si le certificat a expiré, vous pouvez simplement utiliser l'interface utilisateur pour générer un nouveau certificat avec la clé et l'autorité de certification (CA) appropriées, ou importer une clé et un certificat existants dans l'hôte ClusterControl.
Conseillers en sécurité
Les conseillers sont des mini-programmes qui s'exécutent dans ClusterControl. Ils effectuent des tâches spécifiques et fournissent des conseils sur la façon de résoudre les problèmes dans des domaines tels que les performances, la sécurité, la gestion des journaux, la configuration, l'espace de stockage et autres. Chaque conseiller peut être planifié comme une tâche cron et exécuté en tant qu'exécutable autonome dans l'interface utilisateur de ClusterControl. Il peut également être exécuté via le client de ligne de commande ClusterControl 's9s'.
ClusterControl active deux conseillers en sécurité pour les systèmes basés sur MySQL :
- Accès depuis n'importe quel hôte ('%') - Identifie tous les utilisateurs qui utilisent un hôte générique à partir de la table système mysql et vous permet de mieux contrôler quels hôtes peuvent se connecter aux serveurs.
- Vérifier le nombre de comptes sans mot de passe - Identifie tous les utilisateurs qui n'ont pas de mot de passe dans la table système mysql.
Pour MongoDB, nous avons les conseillers suivants :
- Authentification MongoDB activée :vérifiez si l'instance MongoDB est en cours d'exécution avec le mode d'authentification activé.
- Vérification des autorisations :vérifiez si les utilisateurs de MongoDB sont autorisés avec un rôle trop permissif pour le contrôle d'accès.
Pour plus de détails sur la façon dont ClusterControl effectue les vérifications de sécurité, vous pouvez consulter le code source de type JavaScript du conseiller sous
Interfaces réseau multiples
Le fait d'avoir plusieurs cartes réseau sur les hôtes de la base de données vous permet de séparer le trafic de la base de données du trafic de gestion. Un réseau est utilisé par les nœuds de la base de données pour communiquer entre eux, et ce réseau n'est exposé à aucun réseau public. L'autre réseau est utilisé par ClusterControl, à des fins de gestion. ClusterControl est capable de déployer une telle configuration multi-réseaux. Considérez le schéma d'architecture suivant :
Pour importer le cluster de base de données ci-dessus dans ClusterControl, il faut spécifier l'adresse IP principale des hôtes de base de données. Ensuite, il est possible de choisir le réseau de gestion ainsi que le réseau de données :
ClusterControl peut également fonctionner dans un environnement sans accès Internet, les bases de données étant totalement isolées du réseau public. La majorité des fonctionnalités fonctionneront très bien. Si l'hôte ClusterControl est configuré avec Internet, il est également capable de cloner le référentiel du fournisseur de base de données pour les serveurs de base de données sans Internet. Allez simplement dans
La mise en miroir peut prendre environ 10 à 20 minutes selon la connexion Internet, vous verrez le nouvel élément dans la liste plus tard. Vous pouvez ensuite choisir ce référentiel à la place lors de la mise à l'échelle ou du déploiement d'un nouveau cluster, sans que les hôtes de base de données aient besoin d'avoir une connexion Internet (notez que le référentiel hors ligne du système d'exploitation doit également être en place).
Gestion des utilisateurs MySQL
Le système de privilèges MySQL garantit que tous les utilisateurs ne peuvent effectuer que les opérations auxquelles ils sont autorisés. L'octroi est essentiel car vous ne voulez pas donner à tous les utilisateurs un accès complet à votre base de données, mais vous avez besoin que les utilisateurs disposent des autorisations nécessaires pour exécuter des requêtes et effectuer des tâches quotidiennes.
ClusterControl fournit une interface utilisateur interactive pour gérer les schémas et les privilèges de la base de données. Il unifie les comptes sur tous les serveurs MySQL du cluster et simplifie le processus d'octroi. Vous pouvez facilement visualiser les utilisateurs de la base de données, ce qui vous évite de faire des erreurs.
Comme vous pouvez le voir dans la capture d'écran ci-dessus, ClusterControl a grisé les privilèges inutiles si vous souhaitez uniquement accorder un utilisateur à une base de données (shopdb). "Exiger SSL ?" n'est activé que si le cryptage SSL client/serveur est activé tandis que les cases à cocher des privilèges d'administration sont totalement désactivées si une base de données spécifique est définie. Vous pouvez également inspecter l'instruction GRANT générée au bas de l'assistant, pour voir l'instruction que ClusterControl exécutera pour créer cet utilisateur. Cet assistant semble assez simple, mais la création d'utilisateurs et l'octroi de privilèges peuvent être source d'erreurs.
ClusterControl fournit également une liste des utilisateurs inactifs pour tous les nœuds de base de données du cluster, indiquant les comptes qui n'ont pas été utilisés depuis le dernier redémarrage du serveur :
Cela alerte l'administrateur des comptes inutiles qui existent et qui pourraient potentiellement endommager le serveur. L'étape suivante consiste à vérifier si les comptes ne sont plus actifs, et vous pouvez simplement utiliser l'option "Supprimer l'utilisateur sélectionné" afin de les supprimer. Assurez-vous que vous disposez d'une activité de base de données suffisante pour vous assurer que la liste générée par ClusterControl est exacte. Plus la disponibilité du serveur est longue, mieux c'est.
Toujours rester à jour
Pour une utilisation en production, il est fortement recommandé d'installer les packages liés à la base de données à partir du référentiel du fournisseur. Ne comptez pas sur le référentiel du système d'exploitation par défaut, où les packages sont généralement obsolètes. Si vous travaillez dans un environnement de cluster comme Galera Cluster, ou même MySQL Replication, vous avez toujours le choix de corriger le système avec un temps d'arrêt minimal.
ClusterControl prend en charge la mise à niveau automatique des versions mineures pour MySQL/MariaDB en un seul clic. Allez simplement dans
Les mises à niveau des versions majeures (par exemple, de MySQL 5.6 à MySQL 5.7) ne sont intentionnellement pas automatisées. Les mises à niveau majeures nécessitent généralement la désinstallation des packages existants, ce qui est une tâche risquée à automatiser. Une planification et des tests minutieux sont nécessaires pour ce type de mises à niveau.
La sécurité de la base de données est un aspect important de l'exécution de votre base de données en production. De tous les incidents que nous lisons fréquemment dans les nouvelles (et il y en a probablement beaucoup d'autres qui ne sont pas rendus publics), il est clair qu'il y a des groupes occupés avec de mauvaises intentions. Assurez-vous donc que vos bases de données sont bien protégées.
