Mysql
 sql >> Base de données >  >> RDS >> Mysql

Comment sécuriser le cluster Galera - 8 conseils

En tant que système de base de données distribuée, Galera Cluster nécessite des mesures de sécurité supplémentaires par rapport à une base de données centralisée. Les données sont distribuées sur plusieurs serveurs ou même centres de données peut-être. Avec une importante communication de données entre les nœuds, il peut y avoir une exposition importante si les mesures de sécurité appropriées ne sont pas prises.

Dans cet article de blog, nous allons examiner quelques conseils pour sécuriser notre cluster Galera. Notez que ce blog s'appuie sur notre article de blog précédent - Comment sécuriser vos bases de données Open Source avec ClusterControl.

Groupe Pare-feu et sécurité

Les ports suivants sont très importants pour un cluster Galera :

  • 3306 - MySQL
  • 4567 - Communication et réplication Galera
  • 4568 - Galera IST
  • 4444 - Galera SST

Depuis le réseau externe, il est recommandé d'ouvrir uniquement l'accès au port MySQL 3306. Les trois autres ports peuvent être fermés depuis le réseau externe et ne leur permettent qu'un accès interne entre les nœuds Galera. Si vous exécutez un proxy inverse assis devant les nœuds Galera, par exemple HAProxy, vous pouvez verrouiller le port MySQL de l'accès public. Assurez-vous également que le port de surveillance du script de surveillance HAProxy est ouvert. Le port par défaut est 9200 sur le nœud Galera.

Le schéma suivant illustre notre exemple de configuration sur un cluster Galera à trois nœuds, avec un HAProxy faisant face au réseau public avec ses ports associés :

Sur la base du schéma ci-dessus, les commandes iptables pour les nœuds de base de données sont :

$ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dport 3306 -j ACCEPT
$ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dport 4444 -j ACCEPT
$ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dports 4567:4568 -j ACCEPT
$ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dport 9200 -j ACCEPT

Sur l'équilibreur de charge :

$ iptables -A INPUT -p tcp --dport 3307 -j ACCEPT

Assurez-vous de mettre fin à vos règles de pare-feu avec tout refuser, afin que seul le trafic tel que défini dans les règles d'exception soit autorisé. Vous pouvez être plus strict et étendre les commandes pour suivre votre politique de sécurité - par exemple, en ajoutant une interface réseau, une adresse de destination, une adresse source, un état de connexion, etc.

Cryptage client-serveur MySQL

MySQL prend en charge le chiffrement entre le client et le serveur. Nous devons d'abord générer le certificat. Une fois configuré, vous pouvez forcer les comptes d'utilisateurs à spécifier certaines options pour se connecter avec chiffrement à un serveur MySQL.

Les étapes nécessitent que vous :

  1. Créer une clé pour l'autorité de certification (ca-key.pem)
  2. Générer un certificat CA auto-signé (ca-cert.pem)
  3. Créer une clé pour le certificat du serveur (server-key.pem)
  4. Générez un certificat pour le serveur et signez-le avec ca-key.pem (server-cert.pem)
  5. Créer une clé pour le certificat client (client-key.pem)
  6. Générez un certificat pour le client et signez-le avec ca-key.pem (client-cert.pem)

Soyez toujours prudent avec la clé privée de l'AC (ca-key.pem) - toute personne y ayant accès peut l'utiliser pour générer des certificats client ou serveur supplémentaires qui seront acceptés comme légitimes lorsque la vérification de l'AC est activée. L'essentiel est que toutes les clés doivent rester discrètes.

Vous pouvez ensuite ajouter les variables liées à SSL sous la directive [mysqld], par exemple :

ssl-ca=/etc/ssl/mysql/ca-cert.pem
ssl-cert=/etc/ssl/mysql/server-cert.pem
ssl-key=/etc/ssl/mysql/server-key.pem

Redémarrez le serveur MySQL pour charger les modifications. Créez ensuite un utilisateur avec l'instruction SSL REQUIRE, par exemple :

mysql> GRANT ALL PRIVILEGES ON db1.* TO 'dbuser'@'192.168.1.100' IDENTIFIED BY 'mySecr3t' REQUIRE SSL;

L'utilisateur créé avec REQUIRE SSL sera obligé de se connecter avec les fichiers SSL client corrects (client-cert.pem, client-key.pem et ca-cert.pem).

Avec ClusterControl, le cryptage SSL client-serveur peut facilement être activé à partir de l'interface utilisateur, à l'aide de la fonction "Créer un cryptage SSL".

Cryptage Galera

L'activation du cryptage pour Galera signifie que IST sera également crypté car la communication se fait via le même socket. SST, d'autre part, doit être configuré séparément, comme indiqué dans la section suivante. Tous les nœuds du cluster doivent être activés avec le cryptage SSL et vous ne pouvez pas avoir un mélange de nœuds où certains ont activé le cryptage SSL et d'autres non. Le meilleur moment pour le configurer est lors de la configuration d'un nouveau cluster. Cependant, si vous devez l'ajouter sur un système de production en cours d'exécution, vous devrez malheureusement redémarrer le cluster et il y aura un temps d'arrêt.

Tous les nœuds Galera du cluster doivent utiliser la même clé, le même certificat et la même autorité de certification (facultatif). Vous pouvez également utiliser la même clé et le même certificat créés pour le chiffrement client-serveur MySQL, ou générer un nouvel ensemble à cette fin uniquement. Pour activer le chiffrement dans Galera, il faut ajouter l'option et la valeur sous wsrep_provider_options dans le fichier de configuration MySQL sur chaque nœud Galera. Par exemple, considérez la ligne existante suivante pour notre nœud Galera :

wsrep_provider_options = "gcache.size=512M; gmcast.segment=0;"

Ajoutez les variables associées à l'intérieur de la citation, délimitées par un point-virgule :

wsrep_provider_options = "gcache.size=512M; gmcast.segment=0; socket.ssl_cert=/etc/mysql/cert.pem; socket.ssl_key=/etc/mysql/key.pem;"

Pour plus d'informations sur les paramètres SSL de Galera, voir ici. Effectuez cette modification sur tous les nœuds. Ensuite, arrêtez le cluster (un nœud à la fois) et démarrez à partir du dernier nœud qui s'est arrêté. Vous pouvez vérifier si SSL est correctement chargé en consultant le journal des erreurs MySQL :

2018-01-19T01:15:30.155211Z 0 [Note] WSREP: gcomm: connecting to group 'my_wsrep_cluster', peer '192.168.10.61:,192.168.10.62:,192.168.10.63:'
2018-01-19T01:15:30.159654Z 0 [Note] WSREP: SSL handshake successful, remote endpoint ssl://192.168.10.62:53024 local endpoint ssl://192.168.10.62:4567 cipher: AES128-SHA compression:

Avec ClusterControl, le cryptage Galera Replication peut être facilement activé à l'aide de la fonction "Créer un cryptage SSL Galera".

Cryptage SST

Lorsque SST se produit sans cryptage, la communication de données est exposée pendant que le processus SST est en cours. SST est un processus de synchronisation complète des données d'un donneur à un nœud jointeur. Si un attaquant pouvait "voir" la transmission complète des données, il obtiendrait un instantané complet de votre base de données.

SST avec chiffrement est pris en charge uniquement pour les méthodes mysqldump et xtrabackup-v2. Pour mysqldump, l'utilisateur doit être accordé avec "REQUIRE SSL" sur tous les nœuds et la configuration est similaire au cryptage SSL client-serveur MySQL standard (comme décrit dans la section précédente). Une fois le chiffrement client-serveur activé, créez un nouvel utilisateur SST avec SSL appliqué :

mysql> GRANT ALL ON *.* TO 'sst_user'@'%' IDENTIFIED BY 'mypassword' REQUIRE SSL;

Pour rsync, nous vous recommandons d'utiliser galera-secure-rsync, un script SST rsync sécurisé par SSL pour Galera Cluster. Il fonctionne presque exactement comme wsrep_sst_rsync sauf qu'il sécurise les communications réelles avec SSL en utilisant socat. Générez les fichiers de clé et de certificat client/serveur requis, copiez-les sur tous les nœuds et spécifiez "secure_rsync" comme méthode SST dans le fichier de configuration MySQL pour l'activer :

wsrep_sst_method=secure_rsync

Pour xtrabackup, les options de configuration suivantes doivent être activées dans le fichier de configuration MySQL sous la directive [sst] :

[sst]
encrypt=4
ssl-ca=/path/to/ca-cert.pem
ssl-cert=/path/to/server-cert.pem
ssl-key=/path/to/server-key.pem

Le redémarrage de la base de données n'est pas nécessaire. Si ce nœud est sélectionné par Galera en tant que donateur, ces options de configuration seront automatiquement récupérées lorsque Galera lancera le SST.

SELinux

Security-Enhanced Linux (SELinux) est un mécanisme de contrôle d'accès implémenté dans le noyau. Sans SELinux, seules les méthodes de contrôle d'accès traditionnelles telles que les autorisations de fichiers ou ACL sont utilisées pour contrôler l'accès aux fichiers des utilisateurs.

Par défaut, avec le mode d'application stricte activé, tout est refusé et l'administrateur doit créer une série de politiques d'exceptions aux éléments du système requis pour fonctionner. La désactivation complète de SELinux est devenue une mauvaise pratique courante pour de nombreuses installations basées sur RedHat de nos jours.

En fonction des charges de travail, des modèles d'utilisation et des processus, le meilleur moyen est de créer votre propre module de politique SELinux adapté à votre environnement. Ce que vous devez vraiment faire est de définir SELinux en mode permissif (journalisation uniquement sans application) et de déclencher des événements qui peuvent se produire sur un nœud Galera pour que SELinux se connecte. Plus c'est étendu, mieux c'est. Exemples d'événements comme :

  • Nœud de départ en tant que donateur ou participant
  • Redémarrer le nœud pour déclencher IST
  • Utiliser différentes méthodes SST
  • Sauvegarder et restaurer les bases de données MySQL à l'aide de mysqldump ou xtrabackup
  • Activer et désactiver les journaux binaires

Par exemple, si le nœud Galera est surveillé par ClusterControl et que la fonction de surveillance des requêtes est activée, ClusterControl activera/désactivera la variable de journal des requêtes lentes pour capturer les requêtes lentes. Ainsi, vous verriez le refus suivant dans audit.log :

$ grep -e denied audit/audit.log | grep -i mysql
type=AVC msg=audit(1516835039.802:37680): avc:  denied  { open } for  pid=71222 comm="mysqld" path="/var/log/mysql/mysql-slow.log" dev="dm-0" ino=35479360 scontext=system_u:system_r:mysqld_t:s0 tcontext=unconfined_u:object_r:var_log_t:s0 tclass=file

L'idée est de laisser tous les refus possibles être enregistrés dans le journal d'audit, qui peut ensuite être utilisé pour générer le module de stratégie à l'aide de audit2allow avant de le charger dans SELinux. Codership a couvert cela en détail dans la page de documentation, Configuration SELinux.

Compte SST et privilèges

SST est un processus de synchronisation initial effectué par Galera. Il met à jour un nœud de jointure avec le reste des membres du cluster. Le processus exporte essentiellement les données du nœud donneur et les restaure sur le nœud jointeur, avant que le jointeur ne soit autorisé à rattraper les transactions restantes de la file d'attente (c'est-à-dire celles qui se sont produites pendant le processus de synchronisation). Trois méthodes SST sont prises en charge :

  • mysqldump
  • rsync
  • xtrabackup (ou xtrabackup-v2)

Pour l'utilisation de mysqldump SST, les privilèges suivants sont requis :

  • SÉLECTIONNER, AFFICHER LA VUE, DÉCLENCHEMENT, VERROUILLER LES TABLES, RECHARGER, FICHIER

Nous n'allons pas aller plus loin avec mysqldump car il n'est probablement pas souvent utilisé en production comme méthode SST. De plus, c'est une procédure de blocage sur le donneur. Rsync est généralement un deuxième choix préféré après xtrabackup en raison d'un temps de synchronisation plus rapide et moins sujet aux erreurs par rapport à mysqldump. L'authentification SST est ignorée avec rsync, vous pouvez donc ignorer la configuration des privilèges du compte SST si rsync est la méthode SST choisie.

Parallèlement à xtrabackup, les privilèges suivants sont conseillés pour les procédures de sauvegarde et de restauration standard basées sur la page de documentation Xtrabackup :

  • CRÉER, CRÉER UN TABLESPACE, ÉVÉNEMENT, INSÉRER, VERROUILLER LA TABLE, TRAITER, RECHARGER, CLIENT DE RÉPLICATION, SÉLECTIONNER, AFFICHER LA VUE, SUPER

Cependant, pour l'utilisation SST de xtrabackup, seuls les privilèges suivants comptent :

  • TRAITEMENT, RECHARGEMENT, CLIENT DE RÉPLICATION

Ainsi, l'instruction GRANT pour SST peut être minimisée comme :

mysql> GRANT PROCESS,RELOAD,REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost' IDENTIFIED BY '[email protected]@sTr0nG%%P4ssW0rD';

Ensuite, configurez wsrep_sst_auth en conséquence dans le fichier de configuration MySQL :

wsrep_sst_auth = sstuser:[email protected]@sTr0nG%%P4ssW0rD

Accordez uniquement l'utilisateur SST pour localhost et utilisez un mot de passe fort. Évitez d'utiliser l'utilisateur root comme compte SST, car cela exposerait le mot de passe root dans le fichier de configuration sous cette variable. De plus, la modification ou la réinitialisation du mot de passe root MySQL casserait SST à l'avenir.

Renforcement de la sécurité MySQL

Galera Cluster est un plug-in de réplication multi-maîtres pour le moteur de stockage InnoDB, qui s'exécute sur les fourches MySQL et MariaDB. Par conséquent, les recommandations standard de renforcement de la sécurité MySQL/MariaDB/InnoDB s'appliquent également à Galera Cluster.

Ce sujet a été traité dans de nombreux articles de blog. Nous avons également abordé ce sujet dans les articles de blog suivants :

  • Dix conseils pour assurer la sécurité de MySQL et MariaDB
  • Conseils et astuces pour ClusterControl :sécurisation de votre installation MySQL
  • Comment sécuriser vos bases de données Open Source avec ClusterControl

Les articles de blog ci-dessus résument la nécessité de chiffrer les données au repos et les données en transit, d'avoir des plug-ins d'audit, des directives générales de sécurité, les meilleures pratiques de sécurité réseau, etc.

Utiliser un équilibreur de charge

Il existe un certain nombre d'équilibreurs de charge de base de données (proxy inverse) qui peuvent être utilisés avec Galera - HAProxy, ProxySQL et MariaDB MaxScale pour n'en nommer que quelques-uns. Vous pouvez configurer un équilibreur de charge pour contrôler l'accès à vos nœuds Galera. C'est un excellent moyen de répartir la charge de travail de la base de données entre les instances de base de données, ainsi que de restreindre l'accès, par exemple, si vous souhaitez mettre un nœud hors ligne pour la maintenance, ou si vous souhaitez limiter le nombre de connexions ouvertes sur les nœuds Galera. L'équilibreur de charge doit pouvoir mettre les connexions en file d'attente et, par conséquent, fournir une protection contre les surcharges à vos serveurs de base de données.

ProxySQL, un puissant proxy inverse de base de données qui comprend MySQL et MariaDB, peut être étendu avec de nombreuses fonctionnalités de sécurité utiles comme le pare-feu de requête, pour bloquer les requêtes incriminées du serveur de base de données. Le moteur de règles de requête peut également être utilisé pour réécrire les mauvaises requêtes en quelque chose de meilleur/plus sûr, ou les rediriger vers un autre serveur qui peut absorber la charge sans affecter aucun des nœuds Galera. MariaDB MaxScale est également capable de bloquer les requêtes basées sur des expressions régulières avec son filtre Database Firewall.

Un autre avantage d'avoir un équilibreur de charge pour votre cluster Galera est la possibilité d'héberger un service de données sans exposer le niveau base de données au réseau public. Le serveur proxy peut être utilisé comme hôte bastion pour accéder aux nœuds de la base de données dans un réseau privé. En isolant le cluster de bases de données du monde extérieur, vous avez supprimé l'un des vecteurs d'attaque importants.

C'est ça. Restez toujours en sécurité et protégé.