MongoDB
 sql >> Datenbank >  >> NoSQL >> MongoDB

So sichern Sie den ClusterControl-Server

In unserem vorherigen Blogbeitrag haben wir Ihnen gezeigt, wie Sie Ihre Open-Source-Datenbanken mit ClusterControl sichern können. Aber was ist mit dem ClusterControl-Server selbst? Wie sichern wir es? Dies wird das Thema des heutigen Blogs sein. Wir gehen davon aus, dass der Host ausschließlich für die Nutzung von ClusterControl vorgesehen ist und keine anderen Anwendungen darauf laufen.

Firewall- und Sicherheitsgruppe

In erster Linie sollten wir alle unnötigen Ports schließen und nur die notwendigen Ports öffnen, die von ClusterControl verwendet werden. Intern zwischen ClusterControl und den Datenbankservern spielt nur der netcat-Port eine Rolle, wobei der Standardport 9999 ist. Dieser Port muss nur geöffnet werden, wenn Sie das Backup auf dem ClusterControl-Server speichern möchten. Andernfalls können Sie dies schließen.

Aus dem externen Netzwerk wird empfohlen, nur den Zugriff auf entweder HTTP (80) oder HTTPS (443) für die ClusterControl-Benutzeroberfläche zu öffnen. Wenn Sie die ClusterControl-CLI namens „s9s“ ausführen, muss der CMON-TLS-Endpunkt auf Port 9501 geöffnet werden. Es ist auch möglich, datenbankbezogene Anwendungen auf dem ClusterControl-Server zu installieren, wie HAProxy, Keepalived, ProxySQL und dergleichen. In diesem Fall müssen Sie auch für diese die erforderlichen Ports öffnen. Eine Liste der Ports für jeden Dienst finden Sie auf der Dokumentationsseite.

Um Firewall-Regeln über iptables einzurichten, gehen Sie auf dem ClusterControl-Knoten wie folgt vor:

$ 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

Die oben genannten sind die einfachsten Befehle. Sie können strenger sein und die Befehle erweitern, um Ihrer Sicherheitsrichtlinie zu folgen – zum Beispiel durch Hinzufügen von Netzwerkschnittstelle, Zieladresse, Quelladresse, Verbindungsstatus und mehr.

Ähnlich wie beim Ausführen des Setups in der Cloud ist das Folgende ein Beispiel für eingehende Sicherheitsgruppenregeln für den ClusterControl-Server auf AWS:

Unterschiedliche Cloud-Anbieter stellen unterschiedliche Implementierungen von Sicherheitsgruppen bereit, aber die Grundregeln sind ähnlich.

Verschlüsselung

ClusterControl unterstützt die Verschlüsselung der Kommunikation auf verschiedenen Ebenen, um sicherzustellen, dass die Automatisierungs-, Überwachungs- und Verwaltungsaufgaben so sicher wie möglich ausgeführt werden.

Auf HTTPS ausgeführt

Das Installationsskript (install-cc.sh) konfiguriert standardmäßig ein selbstsigniertes SSL-Zertifikat für die HTTPS-Nutzung. Wenn Sie diese Zugriffsmethode als Hauptendpunkt auswählen, können Sie den einfachen HTTP-Dienst, der auf Port 80 ausgeführt wird, vom externen Netzwerk blockieren. ClusterControl erfordert jedoch weiterhin einen Zugriff auf CMONAPI (eine alte Rest-API-Schnittstelle), die standardmäßig auf Port 80 auf dem lokalen Host ausgeführt wird. Wenn Sie den HTTP-Port komplett blockieren möchten, stellen Sie sicher, dass Sie die ClusterControl-API-URL unter Cluster-Registrierungen ändern Seite, um stattdessen HTTPS zu verwenden:

Das von ClusterControl konfigurierte selbstsignierte Zertifikat hat eine Gültigkeit von 10 Jahren (3650 Tage). Sie können die Gültigkeit des Zertifikats mit dem folgenden Befehl überprüfen (auf dem CentOS 7-Server):

$  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
...

Beachten Sie, dass der absolute Pfad zur Zertifikatsdatei je nach Betriebssystem unterschiedlich sein kann.

MySQL-Client-Server-Verschlüsselung

ClusterControl speichert Überwachungs- und Verwaltungsdaten in MySQL-Datenbanken auf dem ClusterControl-Knoten. Da MySQL selbst Client-Server-SSL-Verschlüsselung unterstützt, ist ClusterControl in der Lage, diese Funktion zu nutzen, um beim Schreiben und Abrufen seiner Daten eine verschlüsselte Kommunikation mit dem MySQL-Server herzustellen.

Dazu werden folgende Konfigurationsmöglichkeiten unterstützt:

  • cmondb_ssl_key - Pfad zum SSL-Schlüssel, für die SSL-Verschlüsselung zwischen CMON und der CMON-DB.
  • cmondb_ssl_cert - Pfad zum SSL-Zertifikat, für die SSL-Verschlüsselung zwischen CMON und der CMON-DB
  • cmondb_ssl_ca - Pfad zur SSL-CA, für die SSL-Verschlüsselung zwischen CMON und der CMON-DB

Wir haben die Konfigurationsschritte vor einiger Zeit in diesem Blogbeitrag behandelt.

Es gibt jedoch einen Haken. Zum Zeitpunkt des Verfassens dieses Artikels hat die ClusterControl-Benutzeroberfläche eine Einschränkung beim Zugriff auf die CMON-DB über SSL unter Verwendung des cmon-Benutzers. Als Problemumgehung werden wir einen weiteren Datenbankbenutzer für die ClusterControl-Benutzeroberfläche und die ClusterControl-CMONAPI mit dem Namen cmonui erstellen. Für diesen Benutzer ist SSL in seiner Berechtigungstabelle nicht aktiviert.

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

Aktualisieren Sie die ClusterControl-UI- und CMONAPI-Konfigurationsdateien unter clustercontrol/bootstrap.php bzw. cmonapi/config/database.php mit dem neu erstellten Datenbankbenutzer 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>');

Diese Dateien werden nicht ersetzt, wenn Sie ein Upgrade über den Paketmanager durchführen.

CLI-Verschlüsselung

ClusterControl wird auch mit einer Befehlszeilenschnittstelle namens 's9s' geliefert. Dieser Client analysiert die Befehlszeilenoptionen und sendet einen bestimmten Auftrag an den Controllerdienst, der Port 9500 (CMON) oder 9501 (CMON mit TLS) überwacht. Letzteres ist das empfohlene. Das Installationsskript konfiguriert standardmäßig die s9s-CLI so, dass sie 9501 als Endpunktport des ClusterControl-Servers verwendet.

Rollenbasierte Zugriffskontrolle

ClusterControl verwendet rollenbasierte Zugriffskontrolle (RBAC), um den Zugriff auf Cluster und ihre jeweiligen Bereitstellungs-, Verwaltungs- und Überwachungsfunktionen einzuschränken. Dadurch wird sichergestellt, dass nur autorisierte Benutzeranfragen zugelassen werden. Der Zugriff auf die Funktionalität ist feinkörnig, sodass der Zugriff von der Organisation oder dem Benutzer definiert werden kann. ClusterControl verwendet ein Berechtigungs-Framework, um zu definieren, wie ein Benutzer mit der Verwaltungs- und Überwachungsfunktion interagieren darf, nachdem er dazu autorisiert wurde.

Auf die RBAC-Benutzeroberfläche kann über ClusterControl -> User Management -> Access Control zugegriffen werden :

Alle Funktionen sind selbsterklärend, aber wenn Sie eine zusätzliche Beschreibung wünschen, sehen Sie sich bitte die Dokumentationsseite an.

Wenn mehrere Benutzer am Datenbank-Cluster-Betrieb beteiligt sind, wird dringend empfohlen, die Zugriffskontrollen für sie entsprechend festzulegen. Sie können auch mehrere Teams (Organisationen) erstellen und ihnen null oder mehr Cluster zuweisen.

Auf benutzerdefinierten Ports ausgeführt

ClusterControl kann so konfiguriert werden, dass benutzerdefinierte Ports für alle abhängigen Dienste verwendet werden. ClusterControl verwendet SSH als Hauptkommunikationskanal, um Knoten aus der Ferne zu verwalten und zu überwachen, Apache, um die ClusterControl-Benutzeroberfläche bereitzustellen, und auch MySQL, um Überwachungs- und Verwaltungsdaten zu speichern. Sie können diese Dienste auf benutzerdefinierten Ports ausführen, um den Angriffsvektor zu reduzieren. Die folgenden Ports sind die üblichen Ziele:

  • SSH - Standard ist 22
  • HTTP - Standard ist 80
  • HTTPS - Standard ist 443
  • MySQL - Standard ist 3306

Es gibt mehrere Dinge, die Sie ändern müssen, um die oben genannten Dienste auf benutzerdefinierten Ports auszuführen, damit ClusterControl ordnungsgemäß funktioniert. Wir haben dies ausführlich auf der Dokumentationsseite Running on Custom Port behandelt.

Erlaubnis und Eigentum

ClusterControl-Konfigurationsdateien enthalten vertrauliche Informationen und sollten diskret und gut geschützt aufbewahrt werden. Die Dateien müssen nur für den Benutzer/die Gruppe root zulässig sein, ohne Leseberechtigung für andere. Falls die Berechtigung und der Besitz falsch eingestellt wurden, hilft der folgende Befehl, sie wieder in den richtigen Zustand zu versetzen:

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

Stellen Sie für den MySQL-Dienst sicher, dass der Inhalt des MySQL-Datenverzeichnisses für die Gruppe „mysql“ zulässig ist und der Benutzer entweder „mysql“ oder „root“ sein kann:

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

Für die ClusterControl-Benutzeroberfläche muss der Besitz für den Apache-Benutzer zulässig sein, entweder „apache“ für RHEL/CentOS oder „www-data“ für Debian-basierte Betriebssysteme.

Der SSH-Schlüssel zum Herstellen einer Verbindung mit den Datenbankhosts ist ein weiterer sehr wichtiger Aspekt, da er die Identität enthält und mit der entsprechenden Erlaubnis und dem Besitz aufbewahrt werden muss. Darüber hinaus lässt SSH die Verwendung einer ungesicherten Schlüsseldatei beim Initiieren des Remote-Aufrufs nicht zu. Stellen Sie sicher, dass die vom Cluster verwendete SSH-Schlüsseldatei in den generierten Konfigurationsdateien im Verzeichnis /etc/cmon.d/ auf die für osuser zulässige eingestellt ist nur Option. Betrachten Sie zum Beispiel den osuser ist "ubuntu" und die Schlüsseldatei ist /home/ubuntu/.ssh/id_rsa:

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

Verwenden Sie ein sicheres Passwort

Wenn Sie das Installationsskript verwenden, um ClusterControl zu installieren, sollten Sie ein sicheres Kennwort verwenden, wenn Sie vom Installationsprogramm dazu aufgefordert werden. Es gibt höchstens zwei Konten, die das Installationsskript konfigurieren muss (abhängig von Ihrer Einrichtung):

  • MySQL-cmon-Passwort - Standardwert ist 'cmon'.
  • MySQL-Root-Passwort - Der Standardwert ist 'password'.

Es liegt in der Verantwortung des Benutzers, in diesen beiden Konten sichere Passwörter zu verwenden. Das Installationsskript unterstützt eine Reihe von Sonderzeichen für Ihre Passworteingabe, wie im Installationsassistenten erwähnt:

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

Überprüfen Sie den Inhalt von /etc/cmon.cnf und /etc/cmon.d/cmon_*.cnf und stellen Sie sicher, dass Sie nach Möglichkeit ein sicheres Passwort verwenden.

Ändern des MySQL-Passworts „cmon“

Wenn das konfigurierte Passwort Ihre Passwortrichtlinie nicht erfüllt, müssen Sie mehrere Schritte ausführen, um das MySQL-cmon-Passwort zu ändern:

  1. Ändern Sie das Passwort im MySQL-Server von 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. Aktualisieren Sie alle Vorkommen von 'mysql_password'-Optionen für den Controller-Dienst in /etc/cmon.cnf und /etc/cmon.d/*.cnf:

    mysql_password=newPass

  3. Aktualisieren Sie alle Vorkommen von „DB_PASS“-Konstanten für die ClusterControl-UI in /var/www/html/clustercontrol/bootstrap.php und /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. Ändern Sie das Passwort auf jedem von ClusterControl überwachten MySQL-Server:

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

  5. Starten Sie den CMON-Dienst neu, um die Änderungen zu übernehmen:

    $ service cmon restart # systemctl restart cmon

Überprüfen Sie, ob der cmon-Prozess korrekt gestartet wurde, indem Sie sich die Datei /var/log/cmon.log ansehen. Stellen Sie sicher, dass Sie etwas wie das Folgende haben:

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.

Offline ausführen

Verwandte Ressourcen Ankündigung von ClusterControl 1.5.1 – Mit Sicherungsverschlüsselung für MySQL, MongoDB und PostgreSQL PCI-Konformität für MySQL und MariaDB mit ClusterControl Wie man MySQL/MariaDB-Server sichert

ClusterControl ist in der Lage, Ihre Datenbankinfrastruktur in einer Umgebung ohne Internetzugang zu verwalten. Einige Funktionen würden in dieser Umgebung nicht funktionieren (Sicherung in die Cloud, Bereitstellung mit öffentlichen Repos, Upgrades), die Hauptfunktionen sind vorhanden und würden problemlos funktionieren. Sie haben auch die Möglichkeit, zunächst alles mit Internet bereitzustellen und das Internet dann zu unterbrechen, sobald die Einrichtung getestet und bereit ist, Produktionsdaten bereitzustellen.

Indem Sie ClusterControl und den Datenbank-Cluster von der Außenwelt isoliert haben, haben Sie einen der wichtigen Angriffsvektoren ausgeschaltet.

Zusammenfassung

ClusterControl kann helfen, Ihren Datenbank-Cluster zu sichern, aber es wird nicht von selbst gesichert. Ops-Teams müssen sicherstellen, dass der ClusterControl-Server auch unter Sicherheitsgesichtspunkten gehärtet ist.