Mysql
 sql >> Datenbank >  >> RDS >> Mysql

So sichern Sie Galera Cluster – 8 Tipps

Als verteiltes Datenbanksystem erfordert Galera Cluster zusätzliche Sicherheitsmaßnahmen im Vergleich zu einer zentralen Datenbank. Daten werden über mehrere Server oder vielleicht sogar Rechenzentren verteilt. Da eine erhebliche Datenkommunikation über Knoten hinweg stattfindet, kann es zu einer erheblichen Gefährdung kommen, wenn nicht die entsprechenden Sicherheitsmaßnahmen ergriffen werden.

In diesem Blogbeitrag gehen wir auf einige Tipps ein, wie Sie unser Galera-Cluster sichern können. Beachten Sie, dass dieser Blog auf unserem vorherigen Blogbeitrag aufbaut – How to Secure Your Open Source Databases with ClusterControl.

Firewall- und Sicherheitsgruppe

Folgende Ports sind für einen Galera Cluster sehr wichtig:

  • 3306 - MySQL
  • 4567 - Galera-Kommunikation und -Replikation
  • 4568 - Galera IST
  • 4444 - Galera SST

Vom externen Netzwerk aus wird empfohlen, nur den Zugriff auf MySQL-Port 3306 zu öffnen. Die anderen drei Ports können vom externen Netzwerk geschlossen werden und erlauben ihnen nur den internen Zugriff zwischen den Galera-Knoten. Wenn Sie einen Reverse-Proxy betreiben, der vor den Galera-Knoten sitzt, beispielsweise HAProxy, können Sie den MySQL-Port für den öffentlichen Zugriff sperren. Stellen Sie außerdem sicher, dass der Überwachungsport für das HAProxy-Überwachungsskript geöffnet ist. Der Standardport auf dem Galera-Knoten ist 9200.

Das folgende Diagramm veranschaulicht unser Beispiel-Setup auf einem Galera-Cluster mit drei Knoten, wobei ein HAProxy mit seinen zugehörigen Ports dem öffentlichen Netzwerk zugewandt ist:

Basierend auf dem obigen Diagramm lauten die iptables-Befehle für Datenbankknoten:

$ 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

Auf dem Load Balancer:

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

Stellen Sie sicher, dass Sie Ihre Firewall-Regeln mit „Alle verweigern“ beenden, sodass nur Datenverkehr zugelassen wird, der in den Ausnahmeregeln definiert ist. 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.

MySQL-Client-Server-Verschlüsselung

MySQL unterstützt die Verschlüsselung zwischen dem Client und dem Server. Zuerst müssen wir das Zertifikat generieren. Nach der Konfiguration können Sie Benutzerkonten dazu zwingen, bestimmte Optionen anzugeben, um sich verschlüsselt mit einem MySQL-Server zu verbinden.

Die Schritte erfordern Folgendes:

  1. Erstellen Sie einen Schlüssel für die Zertifizierungsstelle (ca-key.pem)
  2. Generieren Sie ein selbstsigniertes CA-Zertifikat (ca-cert.pem)
  3. Erstellen Sie einen Schlüssel für das Serverzertifikat (server-key.pem)
  4. Generieren Sie ein Zertifikat für den Server und signieren Sie es mit ca-key.pem (server-cert.pem)
  5. Erstellen Sie einen Schlüssel für das Client-Zertifikat (client-key.pem)
  6. Generieren Sie ein Zertifikat für den Client und signieren Sie es mit ca-key.pem (client-cert.pem)

Seien Sie immer vorsichtig mit dem privaten CA-Schlüssel (ca-key.pem) – jeder, der Zugriff darauf hat, kann ihn verwenden, um zusätzliche Client- oder Serverzertifikate zu generieren, die als legitim akzeptiert werden, wenn die CA-Verifizierung aktiviert ist. Die Quintessenz ist, dass alle Schlüssel diskret aufbewahrt werden müssen.

Sie können dann die SSL-bezogenen Variablen unter der Direktive [mysqld] hinzufügen, zum Beispiel:

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

Starten Sie den MySQL-Server neu, um die Änderungen zu laden. Erstellen Sie dann einen Benutzer mit der REQUIRE SSL-Anweisung, zum Beispiel:

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

Der mit REQUIRE SSL erstellte Benutzer wird gezwungen, sich mit den richtigen Client-SSL-Dateien (client-cert.pem, client-key.pem und ca-cert.pem) zu verbinden.

Mit ClusterControl kann die Client-Server-SSL-Verschlüsselung einfach über die Benutzeroberfläche aktiviert werden, indem die Funktion "SSL-Verschlüsselung erstellen" verwendet wird.

Galera-Verschlüsselung

Die Aktivierung der Verschlüsselung für Galera bedeutet, dass IST ebenfalls verschlüsselt wird, da die Kommunikation über denselben Socket erfolgt. SST hingegen muss separat konfiguriert werden, wie im nächsten Abschnitt gezeigt. Alle Knoten im Cluster müssen mit SSL-Verschlüsselung aktiviert werden, und Sie können keine Mischung aus Knoten haben, bei denen einige die SSL-Verschlüsselung aktiviert haben und andere nicht. Der beste Zeitpunkt, dies zu konfigurieren, ist beim Einrichten eines neuen Clusters. Wenn Sie dies jedoch auf einem laufenden Produktionssystem hinzufügen müssen, müssen Sie den Cluster leider neu starten, und es kommt zu Ausfallzeiten.

Alle Galera-Knoten im Cluster müssen denselben Schlüssel, dasselbe Zertifikat und dieselbe Zertifizierungsstelle (optional) verwenden. Sie können auch denselben Schlüssel und dasselbe Zertifikat verwenden, die für die MySQL-Client-Server-Verschlüsselung erstellt wurden, oder nur für diesen Zweck einen neuen Satz generieren. Um die Verschlüsselung innerhalb von Galera zu aktivieren, muss man die Option und den Wert unter wsrep_provider_options in der MySQL-Konfigurationsdatei auf jedem Galera-Knoten anhängen. Betrachten Sie beispielsweise die folgende vorhandene Zeile für unseren Galera-Knoten:

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

Hängen Sie die zugehörigen Variablen innerhalb des Anführungszeichens an, getrennt durch ein Semikolon:

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

Weitere Informationen zu den SSL-bezogenen Parametern von Galera finden Sie hier. Führen Sie diese Änderung auf allen Knoten durch. Stoppen Sie dann den Cluster (jeweils einen Knoten) und führen Sie einen Bootstrap vom letzten heruntergefahrenen Knoten aus. Sie können überprüfen, ob SSL korrekt geladen wird, indem Sie in das MySQL-Fehlerprotokoll schauen:

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:

Mit ClusterControl kann die Galera-Replikationsverschlüsselung einfach mit der Funktion „Create SSL Galera Encryption“ aktiviert werden.

SST-Verschlüsselung

Wenn SST ohne Verschlüsselung erfolgt, wird die Datenkommunikation während des laufenden SST-Prozesses offengelegt. SST ist ein vollständiger Datensynchronisierungsprozess von einem Donor- zu einem Joiner-Knoten. Wenn ein Angreifer die vollständige Datenübertragung "sehen" könnte, würde die Person einen vollständigen Schnappschuss Ihrer Datenbank erhalten.

SST mit Verschlüsselung wird nur für mysqldump- und xtrabackup-v2-Methoden unterstützt. Für mysqldump muss dem Benutzer auf allen Knoten „REQUIRE SSL“ gewährt werden, und die Konfiguration ähnelt der standardmäßigen MySQL-Client-Server-SSL-Verschlüsselung (wie im vorherigen Abschnitt beschrieben). Sobald die Client-Server-Verschlüsselung aktiviert ist, erstellen Sie einen neuen SST-Benutzer mit erzwungenem SSL:

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

Für rsync empfehlen wir die Verwendung von galera-secure-rsync, einem Drop-in-SSL-gesicherten rsync-SST-Skript für Galera Cluster. Es funktioniert fast genauso wie wsrep_sst_rsync außer dass es die eigentliche Kommunikation mit SSL unter Verwendung von socat sichert. Generieren Sie die erforderlichen Client/Server-Schlüssel- und Zertifikatsdateien, kopieren Sie sie auf alle Knoten und geben Sie „secure_rsync“ als SST-Methode in der MySQL-Konfigurationsdatei an, um sie zu aktivieren:

wsrep_sst_method=secure_rsync

Für xtrabackup müssen die folgenden Konfigurationsoptionen in der MySQL-Konfigurationsdatei unter der Direktive [sst] aktiviert werden:

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

Ein Neustart der Datenbank ist nicht erforderlich. Wenn dieser Knoten von Galera als Spender ausgewählt wird, werden diese Konfigurationsoptionen automatisch übernommen, wenn Galera den SST initiiert.

SELinux

Security-Enhanced Linux (SELinux) ist ein im Kernel implementierter Zugriffskontrollmechanismus. Ohne SELinux werden nur traditionelle Zugriffskontrollmethoden wie Dateiberechtigungen oder ACL verwendet, um den Dateizugriff von Benutzern zu kontrollieren.

Standardmäßig wird bei aktiviertem strengen Erzwingungsmodus alles verweigert, und der Administrator muss eine Reihe von Ausnahmerichtlinien für die Elemente des Systems festlegen, die zum Funktionieren erforderlich sind. Das vollständige Deaktivieren von SELinux ist heutzutage für viele RedHat-basierte Installationen eine gängige schlechte Praxis geworden.

Abhängig von den Workloads, Nutzungsmustern und Prozessen ist es am besten, Ihr eigenes SELinux-Richtlinienmodul zu erstellen, das auf Ihre Umgebung zugeschnitten ist. Was Sie wirklich tun müssen, ist, SELinux in den zulässigen Modus zu versetzen (nur Protokollierung ohne Erzwingung) und Ereignisse auszulösen, die auf einem Galera-Knoten auftreten können, damit SELinux protokolliert. Je umfangreicher desto besser. Beispielereignisse wie:

  • Startknoten als Donor oder Joiner
  • Knoten neu starten, um IST auszulösen
  • Verwenden Sie verschiedene SST-Methoden
  • MySQL-Datenbanken mit mysqldump oder xtrabackup sichern und wiederherstellen
  • Aktivieren und deaktivieren Sie Binärprotokolle

Ein Beispiel ist, wenn der Galera-Knoten von ClusterControl überwacht wird und die Abfrageüberwachungsfunktion aktiviert ist, wird ClusterControl die Protokollvariable für langsame Abfragen aktivieren/deaktivieren, um die langsam laufenden Abfragen zu erfassen. Daher würden Sie im audit.log die folgende Verweigerung sehen:

$ 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

Die Idee ist, dass alle möglichen Verweigerungen in das Prüfprotokoll eingetragen werden, das später verwendet werden kann, um das Richtlinienmodul mit audit2allow zu generieren bevor Sie es in SELinux laden. Codership hat dies ausführlich auf der Dokumentationsseite SELinux Configuration behandelt.

SST-Konto und -Berechtigungen

SST ist ein anfänglicher Synchronisierungsprozess, der von Galera durchgeführt wird. Es bringt einen Joiner-Knoten mit den übrigen Mitgliedern im Cluster auf den neuesten Stand. Der Prozess exportiert im Wesentlichen die Daten aus dem Spenderknoten und stellt sie auf dem Joiner-Knoten wieder her, bevor der Joiner die verbleibenden Transaktionen aus der Warteschlange nachholen darf (d. h. diejenigen, die während des Synchronisierungsprozesses stattgefunden haben). Drei SST-Methoden werden unterstützt:

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

Für die Verwendung von mysqldump SST sind die folgenden Berechtigungen erforderlich:

  • AUSWÄHLEN, ANSICHT ZEIGEN, AUSLÖSEN, TABELLEN SPERREN, NEU LADEN, DATEI

Wir gehen nicht weiter auf mysqldump ein, da es wahrscheinlich nicht oft in der Produktion als SST-Methode verwendet wird. Außerdem ist es ein Sperrverfahren für den Spender. Rsync ist normalerweise eine bevorzugte zweite Wahl nach xtrabackup, da es schneller synchronisiert und im Vergleich zu mysqldump weniger fehleranfällig ist. Die SST-Authentifizierung wird bei rsync ignoriert, daher können Sie die Konfiguration von SST-Kontoprivilegien überspringen, wenn rsync die gewählte SST-Methode ist.

Zusammen mit xtrabackup werden die folgenden Privilegien für standardmäßige Sicherungs- und Wiederherstellungsverfahren basierend auf der Xtrabackup-Dokumentationsseite empfohlen:

  • CREATE, CREATE TABLESPACE, EVENT, INSERT, LOCK TABLE, PROCESS, RELOAD, REPLICATION CLIENT, SELECT, SHOW VIEW, SUPER

Für die SST-Nutzung von xtrabackup sind jedoch nur die folgenden Berechtigungen von Bedeutung:

  • VERARBEITEN, NEU LADEN, REPLIKATIONS-CLIENT

Daher kann die GRANT-Anweisung für SST wie folgt minimiert werden:

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

Konfigurieren Sie dann wsrep_sst_auth entsprechend in der MySQL-Konfigurationsdatei:

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

Gewähren Sie dem SST-Benutzer nur Localhost und verwenden Sie ein sicheres Kennwort. Vermeiden Sie die Verwendung des Root-Benutzers als SST-Konto, da dies das Root-Passwort in der Konfigurationsdatei unter dieser Variablen offen legen würde. Außerdem würde das Ändern oder Zurücksetzen des MySQL-Root-Passworts SST in Zukunft beschädigen.

MySQL-Sicherheitshärtung

Galera Cluster ist ein Multi-Master-Replikations-Plugin für die InnoDB-Speicher-Engine, das auf MySQL- und MariaDB-Forks läuft. Daher gelten die standardmäßigen MySQL/MariaDB/InnoDB-Sicherheitshärtungsempfehlungen auch für Galera Cluster.

Dieses Thema wurde in zahlreichen Blog-Beiträgen behandelt. Wir haben dieses Thema auch in den folgenden Blogbeiträgen behandelt:

  • Zehn Tipps zum Erzielen von MySQL- und MariaDB-Sicherheit
  • ClusterControl Tipps &Tricks:Sicherung Ihrer MySQL-Installation
  • So sichern Sie Ihre Open-Source-Datenbanken mit ClusterControl

Die obigen Blog-Beiträge fassen die Notwendigkeit der Verschlüsselung von Daten im Ruhezustand und Daten während der Übertragung, Audit-Plug-ins, allgemeine Sicherheitsrichtlinien, Best Practices für die Netzwerksicherheit und so weiter zusammen.

Verwenden Sie einen Load-Balancer

Es gibt eine Reihe von Datenbank-Load-Balancern (Reverse Proxy), die zusammen mit Galera verwendet werden können – HAProxy, ProxySQL und MariaDB MaxScale, um nur einige zu nennen. Sie können einen Load Balancer einrichten, um den Zugriff auf Ihre Galera-Knoten zu kontrollieren. Es ist eine großartige Möglichkeit, die Datenbanklast zwischen den Datenbankinstanzen zu verteilen und den Zugriff einzuschränken, z. B. wenn Sie einen Knoten zur Wartung offline nehmen oder die Anzahl der geöffneten Verbindungen auf den Galera-Knoten begrenzen möchten. Der Load Balancer sollte in der Lage sein, Verbindungen in eine Warteschlange zu stellen und daher einen gewissen Überlastungsschutz für Ihre Datenbankserver bereitzustellen.

ProxySQL, ein leistungsstarker Datenbank-Reverse-Proxy, der MySQL und MariaDB versteht, kann mit vielen nützlichen Sicherheitsfunktionen wie einer Abfrage-Firewall erweitert werden, um anstößige Abfragen vom Datenbankserver zu blockieren. Die Abfrageregel-Engine kann auch verwendet werden, um fehlerhafte Abfragen in etwas Besseres/Sichereres umzuschreiben oder sie auf einen anderen Server umzuleiten, der die Last absorbieren kann, ohne einen der Galera-Knoten zu beeinträchtigen. MariaDB MaxScale kann mit seinem Datenbank-Firewall-Filter auch Abfragen basierend auf regulären Ausdrücken blockieren.

Ein weiterer Vorteil eines Load Balancers für Ihren Galera-Cluster ist die Möglichkeit, einen Datendienst zu hosten, ohne die Datenbankebene dem öffentlichen Netzwerk auszusetzen. Der Proxy-Server kann als Bastion-Host verwendet werden, um Zugriff auf die Datenbankknoten in einem privaten Netzwerk zu erhalten. Indem Sie den Datenbank-Cluster von der Außenwelt isoliert haben, haben Sie einen der wichtigen Angriffsvektoren entfernt.

Das ist es. Bleiben Sie immer sicher und geschützt.