MongoDB
 sql >> Base de données >  >> NoSQL >> MongoDB

Comment sécuriser le serveur ClusterControl

Dans notre précédent article de blog, nous vous avons montré comment vous pouvez sécuriser vos bases de données open source avec ClusterControl. Mais qu'en est-il du serveur ClusterControl lui-même ? Comment le sécurisons-nous ? Ce sera le sujet du blog d'aujourd'hui. Nous supposons que l'hôte est uniquement destiné à l'utilisation de ClusterControl, sans qu'aucune autre application ne s'exécute dessus.

Groupe Pare-feu et sécurité

Tout d'abord, nous devons fermer tous les ports inutiles et n'ouvrir que les ports nécessaires utilisés par ClusterControl. En interne, entre ClusterControl et les serveurs de base de données, seul le port netcat compte, où le port par défaut est 9999. Ce port doit être ouvert uniquement si vous souhaitez stocker la sauvegarde sur le serveur ClusterControl. Sinon, vous pouvez le fermer.

Depuis le réseau externe, il est recommandé d'ouvrir uniquement l'accès à HTTP (80) ou HTTPS (443) pour l'interface utilisateur ClusterControl. Si vous exécutez la CLI ClusterControl appelée 's9s', le point de terminaison CMON-TLS doit être ouvert sur le port 9501. Il est également possible d'installer des applications liées à la base de données sur le serveur ClusterControl, comme HAProxy, Keepalived, ProxySQL et autres. Dans ce cas, vous devez également ouvrir les ports nécessaires pour ceux-ci. Veuillez vous référer à la page de documentation pour une liste des ports pour chaque service.

Pour configurer des règles de pare-feu via iptables, sur le nœud ClusterControl, faites :

$ iptables -A INPUT -p tcp --dport 9999 -j ACCEPT
$ iptables -A INPUT -p tcp --dport 80 -j ACCEPT
$ iptables -A INPUT -p tcp --dport 443 -j ACCEPT
$ iptables -A INPUT -p tcp --dport 9501 -j ACCEPT
$ iptables -A OUTPUT -p tcp --dport 22 -j ACCEPT

Les commandes ci-dessus sont les plus simples. 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.

Semblable à l'exécution de la configuration dans le cloud, voici un exemple de règles de groupe de sécurité entrantes pour le serveur ClusterControl sur AWS :

Différents fournisseurs de cloud proposent différentes implémentations de groupes de sécurité, mais les règles de base sont similaires.

Cryptage

ClusterControl prend en charge le cryptage des communications à différents niveaux, pour garantir que les tâches d'automatisation, de surveillance et de gestion sont effectuées de la manière la plus sécurisée possible.

Fonctionnement sur HTTPS

Le script d'installation (install-cc.sh) configurera par défaut un certificat SSL auto-signé pour l'utilisation HTTPS. Si vous choisissez cette méthode d'accès comme point de terminaison principal, vous pouvez bloquer le service HTTP simple s'exécutant sur le port 80 à partir du réseau externe. Cependant, ClusterControl nécessite toujours un accès à CMONAPI (une ancienne interface Rest-API) qui s'exécute par défaut sur le port 80 sur l'hôte local. Si vous souhaitez bloquer le port HTTP partout, assurez-vous de modifier l'URL de l'API ClusterControl sous Enregistrements de cluster page pour utiliser HTTPS à la place :

Le certificat auto-signé configuré par ClusterControl a une validité de 10 ans (3650 jours). Vous pouvez vérifier la validité du certificat en utilisant la commande suivante (sur le serveur CentOS 7) :

$  openssl x509 -in /etc/ssl/certs/s9server.crt -text -noout
...
        Validity
            Not Before: Apr  9 21:22:42 2014 GMT
            Not After : Mar 16 21:22:42 2114 GMT
...

Notez que le chemin absolu vers le fichier de certificat peut être différent selon le système d'exploitation.

Cryptage client-serveur MySQL

ClusterControl stocke les données de surveillance et de gestion dans les bases de données MySQL sur le nœud ClusterControl. Étant donné que MySQL lui-même prend en charge le cryptage SSL client-serveur, ClusterControl est capable d'utiliser cette fonctionnalité pour établir une communication cryptée avec le serveur MySQL lors de l'écriture et de la récupération de ses données.

Les options de configuration suivantes sont prises en charge à cette fin :

  • cmondb_ssl_key - chemin vers la clé SSL, pour le chiffrement SSL entre CMON et la base de données CMON.
  • cmondb_ssl_cert - chemin d'accès au certificat SSL, pour le cryptage SSL entre CMON et la base de données CMON
  • cmondb_ssl_ca - chemin vers SSL CA, pour le chiffrement SSL entre CMON et la base de données CMON

Nous avons couvert les étapes de configuration dans cet article de blog il y a quelque temps.

Il y a cependant un hic. Au moment de la rédaction, l'interface utilisateur de ClusterControl a une limitation d'accès à la base de données CMON via SSL à l'aide de l'utilisateur cmon. Comme solution de contournement, nous allons créer un autre utilisateur de base de données pour l'interface utilisateur ClusterControl et ClusterControl CMONAPI appelé cmonui. Cet utilisateur n'aura pas SSL activé sur sa table de privilèges.

mysql> GRANT ALL PRIVILEGES ON *.* TO 'cmonui'@'127.0.0.1' IDENTIFIED BY '<cmon password>';
mysql> FLUSH PRIVILEGES;

Mettez à jour les fichiers de configuration ClusterControl UI et CMONAPI situés respectivement dans clustercontrol/bootstrap.php et cmonapi/config/database.php avec l'utilisateur de base de données nouvellement créé, cmonui :

# <wwwroot>/clustercontrol/bootstrap.php
define('DB_LOGIN', 'cmonui');
define('DB_PASS', '<cmon password>');
# <wwwroot>/cmonapi/config/database.php
define('DB_USER', 'cmonui');
define('DB_PASS', '<cmon password>');

Ces fichiers ne seront pas remplacés lorsque vous effectuerez une mise à niveau via le gestionnaire de packages.

Cryptage CLI

ClusterControl est également livré avec une interface de ligne de commande appelée « s9s ». Ce client analyse les options de ligne de commande et envoie une tâche spécifique au service du contrôleur qui écoute sur le port 9500 (CMON) ou 9501 (CMON avec TLS). Ce dernier est celui recommandé. Le script d'installation par défaut configurera la CLI s9s pour utiliser 9501 comme port de point de terminaison du serveur ClusterControl.

Contrôle d'accès basé sur les rôles

ClusterControl utilise le contrôle d'accès basé sur les rôles (RBAC) pour restreindre l'accès aux clusters et à leurs fonctionnalités respectives de déploiement, de gestion et de surveillance. Cela garantit que seules les demandes des utilisateurs autorisés sont autorisées. L'accès aux fonctionnalités est précis, ce qui permet de définir l'accès par organisation ou utilisateur. ClusterControl utilise un cadre d'autorisations pour définir comment un utilisateur peut interagir avec la fonctionnalité de gestion et de surveillance, après avoir été autorisé à le faire.

L'interface utilisateur RBAC est accessible via ClusterControl -> Gestion des utilisateurs -> Contrôle d'accès :

Toutes les fonctionnalités sont explicites, mais si vous souhaitez une description supplémentaire, veuillez consulter la page de documentation.

Si vous avez plusieurs utilisateurs impliqués dans l'opération de cluster de base de données, il est fortement recommandé de définir des contrôles d'accès pour eux en conséquence. Vous pouvez également créer plusieurs équipes (organisations) et leur attribuer zéro ou plusieurs clusters.

Exécution sur des ports personnalisés

ClusterControl peut être configuré pour utiliser des ports personnalisés pour tous les services dépendants. ClusterControl utilise SSH comme principal canal de communication pour gérer et surveiller les nœuds à distance, Apache pour servir l'interface utilisateur de ClusterControl et également MySQL pour stocker les données de surveillance et de gestion. Vous pouvez exécuter ces services sur des ports personnalisés pour réduire le vecteur d'attaque. Les ports suivants sont les cibles habituelles :

  • SSH – 22 par défaut
  • HTTP - la valeur par défaut est 80
  • HTTPS - la valeur par défaut est 443
  • MySQL - la valeur par défaut est 3306

Il y a plusieurs choses que vous devez changer pour exécuter les services ci-dessus sur des ports personnalisés pour que ClusterControl fonctionne correctement. Nous avons couvert cela en détail dans la page de documentation, Exécution sur un port personnalisé.

Autorisation et propriété

Les fichiers de configuration de ClusterControl contiennent des informations sensibles et doivent rester discrets et bien protégés. Les fichiers doivent être autorisés uniquement pour l'utilisateur/le groupe root, sans autorisation de lecture pour les autres. Dans le cas où l'autorisation et la propriété ont été mal définies, la commande suivante permet de les restaurer à l'état correct :

$ chown root:root /etc/cmon.cnf /etc/cmon.d/*.cnf
$ chmod 700 /etc/cmon.cnf /etc/cmon.d/*.cnf

Pour le service MySQL, assurez-vous que le contenu du répertoire de données MySQL est autorisé pour le groupe "mysql", et que l'utilisateur peut être "mysql" ou "root":

$ chown -Rf mysql:mysql /var/lib/mysql

Pour l'interface utilisateur de ClusterControl, la propriété doit être autorisée pour l'utilisateur Apache, soit "apache" pour RHEL/CentOS, soit "www-data" pour le système d'exploitation basé sur Debian.

La clé SSH pour se connecter aux hôtes de la base de données est un autre aspect très important, car elle détient l'identité et doit être conservée avec l'autorisation et la propriété appropriées. De plus, SSH n'autorisera pas l'utilisation d'un fichier de clé non sécurisé lors du lancement de l'appel à distance. Vérifiez que le fichier de clé SSH utilisé par le cluster, à l'intérieur des fichiers de configuration générés sous le répertoire /etc/cmon.d/, est défini sur autorisé pour osuser seulement. Par exemple, considérez le osuser est "ubuntu" et le fichier clé est /home/ubuntu/.ssh/id_rsa :

$ chown ubuntu:ubuntu /home/ubuntu/.ssh/id_rsa
$ chmod 700 /home/ubuntu/.ssh/id_rsa

Utilisez un mot de passe fort

Si vous utilisez le script du programme d'installation pour installer ClusterControl, nous vous encourageons à utiliser un mot de passe fort lorsque le programme d'installation vous y invite. Il y a au plus deux comptes que le script d'installation devra configurer (selon votre configuration) :

  • Mot de passe MySQL cmon – La valeur par défaut est 'cmon'.
  • Mot de passe racine MySQL :la valeur par défaut est 'password'.

Il est de la responsabilité de l'utilisateur d'utiliser des mots de passe forts dans ces deux comptes. Le script d'installation prend en charge un tas de caractères spéciaux pour la saisie de votre mot de passe, comme indiqué dans l'assistant d'installation :

=> Set a password for ClusterControl's MySQL user (cmon) [cmon]
=> Supported special password characters: [email protected]#$%^&*()_+{}<>?

Vérifiez le contenu de /etc/cmon.cnf et /etc/cmon.d/cmon_*.cnf et assurez-vous d'utiliser un mot de passe fort dans la mesure du possible.

Modification du mot de passe "cmon" MySQL

Si le mot de passe configuré ne satisfait pas votre politique de mot de passe, pour changer le mot de passe MySQL cmon, vous devez effectuer plusieurs étapes :

  1. Modifiez le mot de passe à l'intérieur du serveur MySQL de ClusterControl :

    $ ALTER USER 'cmon'@'127.0.0.1' IDENTIFIED BY 'newPass';
$ ALTER USER 'cmon'@'{ClusterControl IP address or hostname}' IDENTIFIED BY 'newPass';
$ FLUSH PRIVILEGES;

  2. Mettez à jour toutes les occurrences des options 'mysql_password' pour le service du contrôleur dans /etc/cmon.cnf et /etc/cmon.d/*.cnf :

    mysql_password=newPass

  3. Mettez à jour toutes les occurrences des constantes 'DB_PASS' pour l'interface utilisateur de ClusterControl dans /var/www/html/clustercontrol/bootstrap.php et /var/www/html/cmonapi/config/database.php :

    # <wwwroot>/clustercontrol/bootstrap.php
define('DB_PASS', 'newPass');
    # <wwwroot>/cmonapi/config/database.php
define('DB_PASS', 'newPass');

  4. Modifiez le mot de passe sur chaque serveur MySQL surveillé par ClusterControl :

    $ ALTER USER 'cmon'@'{ClusterControl IP address or hostname}' IDENTIFIED BY 'newPass';
$ FLUSH PRIVILEGES;

  5. Redémarrez le service CMON pour appliquer les modifications :

    $ service cmon restart # systemctl restart cmon

Vérifiez si le processus cmon est démarré correctement en consultant le fichier /var/log/cmon.log. Assurez-vous d'avoir quelque chose comme ci-dessous :

2018-01-11 08:33:09 : (INFO) Additional RPC URL for events: 'http://127.0.0.1:9510'
2018-01-11 08:33:09 : (INFO) Configuration loaded.
2018-01-11 08:33:09 : (INFO) cmon 1.5.1.2299
2018-01-11 08:33:09 : (INFO) Server started at tcp://127.0.0.1:9500
2018-01-11 08:33:09 : (INFO) Server started at tls://127.0.0.1:9501
2018-01-11 08:33:09 : (INFO) Found 'cmon' schema version 105010.
2018-01-11 08:33:09 : (INFO) Running cmon schema hot-fixes.
2018-01-11 08:33:09 : (INFO) Schema auto-upgrade succeed (version 105010).
2018-01-11 08:33:09 : (INFO) Checked tables - seems ok
2018-01-11 08:33:09 : (INFO) Community version
2018-01-11 08:33:09 : (INFO) CmonCommandHandler: started, polling for commands.

Exécution hors connexion

Ressources associées Annonce de ClusterControl 1.5.1 – Chiffrement de sauvegarde pour MySQL, MongoDB et PostgreSQL Conformité PCI pour MySQL et MariaDB avec ClusterControl Comment sécuriser les serveurs MySQL/MariaDB

ClusterControl est capable de gérer votre infrastructure de base de données dans un environnement sans accès Internet. Certaines fonctionnalités ne fonctionneraient pas dans cet environnement (sauvegarde dans le cloud, déploiement à l'aide de référentiels publics, mises à niveau), les principales fonctionnalités sont là et fonctionneraient très bien. Vous avez également le choix de tout déployer initialement avec Internet, puis de couper Internet une fois que la configuration est testée et prête à servir les données de production.

En ayant ClusterControl et le cluster de bases de données isolés du monde extérieur, vous avez supprimé l'un des vecteurs d'attaque importants.

Résumé

ClusterControl peut vous aider à sécuriser votre cluster de bases de données, mais il ne se sécurise pas tout seul. Les équipes opérationnelles doivent s'assurer que le serveur ClusterControl est également renforcé du point de vue de la sécurité.