MariaDB
 sql >> Datenbank >  >> RDS >> MariaDB

Vollständige MariaDB-Verschlüsselung im Ruhezustand und während der Übertragung für maximalen Datenschutz – Teil Eins

In dieser Blogserie geben wir Ihnen eine vollständige Anleitung zur Konfiguration eines vollständig verschlüsselten MariaDB-Servers für die Verschlüsselung im Ruhezustand und während der Übertragung, um einen maximalen Schutz der Daten vor dem Zugriff zu gewährleisten physisch oder während der Übertragung und Kommunikation mit anderen Hosts gestohlen werden. Die Grundidee ist, dass wir unsere „einfache“ Bereitstellung in eine vollständig verschlüsselte MariaDB-Replikation umwandeln, wie im folgenden Diagramm vereinfacht:

Wir werden eine Reihe von Verschlüsselungskomponenten konfigurieren:

  • Verschlüsselung während der Übertragung, bestehend aus:
    • Client-Server-Verschlüsselung
    • Replikationsverschlüsselung
  • Verschlüsselung im Ruhezustand, bestehend aus:
    • Datendateiverschlüsselung
    • Binär-/Relay-Protokollverschlüsselung.

Beachten Sie, dass dieser Blogbeitrag nur die Verschlüsselung während der Übertragung behandelt. Wir werden uns im zweiten Teil dieser Blogserie mit der Verschlüsselung im Ruhezustand befassen.

Bei dieser exemplarischen Vorgehensweise für die Bereitstellung wurde davon ausgegangen, dass wir bereits über einen bereits laufenden MariaDB-Replikationsserver verfügen. Wenn Sie keine haben, können Sie ClusterControl verwenden, um eine neue MariaDB-Replikation innerhalb von Minuten mit weniger als 5 Klicks bereitzustellen. Alle Server laufen auf MariaDB 10.4.11 auf einem CentOS 7-System.

Verschlüsselung während der Übertragung

Daten können sowohl bei der Übertragung als auch im Ruhezustand Risiken ausgesetzt sein und müssen in beiden Zuständen geschützt werden. Die Verschlüsselung während der Übertragung schützt Ihre Daten, wenn die Kommunikation abgefangen wird, während Daten zwischen Hosts über das Netzwerk übertragen werden, entweder von Ihrer Website und dem Cloud-Anbieter, zwischen Diensten oder zwischen Clients und dem Server.

Bei MySQL/MariaDB sind Daten in Bewegung, wenn ein Client eine Verbindung zu einem Datenbankserver herstellt oder wenn ein Slave-Knoten Daten von einem Master-Knoten repliziert. MariaDB unterstützt verschlüsselte Verbindungen zwischen Clients und dem Server mithilfe des TLS-Protokolls (Transport Layer Security). TLS wird manchmal als SSL (Secure Sockets Layer) bezeichnet, aber MariaDB verwendet das SSL-Protokoll eigentlich nicht für verschlüsselte Verbindungen, da seine Verschlüsselung schwach ist. Weitere Details dazu auf der MariaDB-Dokumentationsseite.

Client-Server-Verschlüsselung

In diesem Setup verwenden wir selbstsignierte Zertifikate, was bedeutet, dass wir keine externen Parteien wie Google, Comodo oder andere bekannte Anbieter von Zertifizierungsstellen verwenden, um unsere Identität zu überprüfen. Bei SSL/TLS ist die Identitätsprüfung der erste Schritt, der durchlaufen werden muss, bevor Server und Client ihre Zertifikate und Schlüssel austauschen.

MySQL bietet ein sehr praktisches Tool namens mysql_ssl_rsa_setup, das sich automatisch um die Generierung von Schlüsseln und Zertifikaten kümmert. Leider gibt es noch kein solches Tool für MariaDB-Server. Daher müssen wir die SSL-bezogenen Dateien für unsere MariaDB-TLS-Anforderungen manuell vorbereiten und generieren.

Das Folgende ist eine Liste der Dateien, die wir mit dem OpenSSL-Tool generieren werden:

  • CA-Schlüssel - Privater RSA-Schlüssel im PEM-Format. Muss geheim gehalten werden.
  • CA-Zertifikat - X.509-Zertifikat im PEM-Format. Enthält Metadaten des öffentlichen Schlüssels und des Zertifikats.
  • Server-CSR - Anforderung zum Signieren eines Zertifikats. Der Common Name (CN) beim Ausfüllen des Formulars ist wichtig, zum Beispiel CN=mariadb-server
  • Serverschlüssel - Privater RSA-Schlüssel. Muss geheim gehalten werden.
  • Serverzertifikat - X.509-Zertifikat mit CA-Schlüssel signiert. Enthält Metadaten des öffentlichen Schlüssels und des Zertifikats.
  • Kunden-CSR - Anforderung zum Signieren eines Zertifikats. Muss einen anderen Common Name (CN) als den CSR des Servers verwenden, z. B. CN=client1 
  • Clientschlüssel - Privater RSA-Schlüssel. Muss geheim gehalten werden.
  • Client-Zertifikat - X.509-Zertifikat mit CA-Schlüssel signiert. Enthält Metadaten des öffentlichen Schlüssels und des Zertifikats.

Erstellen Sie zuallererst ein Verzeichnis, um unsere Zertifikate und Schlüssel für die Verschlüsselung während der Übertragung zu speichern:

$ mkdir -p /etc/mysql/transit/
$ cd /etc/mysql/transit/

Nur um Ihnen eine Vorstellung davon zu geben, warum wir das Verzeichnis wie erwähnt benennen, weil wir im nächsten Teil dieser Blogserie ein weiteres Verzeichnis für die Verschlüsselung im Ruhezustand unter /etc/mysql/rest erstellen werden.

Zertifizierungsstelle

Generieren Sie eine Schlüsseldatei für unsere eigene Zertifizierungsstelle (CA):

$ openssl genrsa 2048 > ca-key.pem
Generating RSA private key, 2048 bit long modulus
.......................+++
...............................................................................................................................................................................................................................................+++
e is 65537 (0x10001)

Generieren Sie ein Zertifikat für unsere eigene Zertifizierungsstelle (CA) basierend auf der zuvor generierten ca-key.pem mit Ablauf von 3650 Tagen:

$ openssl req -new -x509 -nodes -days 3650 -key ca-key.pem -out ca.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:SE
State or Province Name (full name) []:Stockholm
Locality Name (eg, city) [Default City]:Stockholm
Organization Name (eg, company) [Default Company Ltd]:Severalnines
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:CA
Email Address []:[email protected]

Jetzt sollten wir ca-key.pem und ca.pem in diesem Arbeitsverzeichnis haben.

Schlüssel und Zertifikat für Server

Generieren Sie als Nächstes einen privaten Schlüssel für den MariaDB-Server:

$ openssl genrsa 2048 > server-key.pem
Generating RSA private key, 2048 bit long modulus
.............................................................................................................+++
..................................................................................................................+++
e is 65537 (0x10001)

Ein vertrauenswürdiges Zertifikat muss ein von einer Zertifizierungsstelle signiertes Zertifikat sein, wobei wir hier unsere eigene Zertifizierungsstelle verwenden werden, weil wir den Hosts im Netzwerk vertrauen. Bevor wir ein signiertes Zertifikat erstellen können, müssen wir ein Anforderungszertifikat namens Certificate Signing Request (CSR) generieren.

Erstellen Sie eine CSR für den MariaDB-Server. Wir nennen das Zertifikat server-req.pem. Dies ist nicht das Zertifikat, das wir für den MariaDB-Server verwenden werden. Das endgültige Zertifikat ist dasjenige, das mit unserem eigenen privaten CA-Schlüssel signiert wird (wie im nächsten Schritt gezeigt):

$ openssl req -new -key server-key.pem -out server-req.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:SE
State or Province Name (full name) []:Stockholm
Locality Name (eg, city) [Default City]:Stockholm
Organization Name (eg, company) [Default Company Ltd]:Severalnines
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:MariaDBServer
Email Address []:[email protected]

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Notieren Sie sich den Common Name, bei dem wir "MariaDBServer" angegeben haben. Dies kann ein beliebiger Name sein, aber der Wert darf nicht mit dem Client-Zertifikat übereinstimmen. Wenn sich die Anwendungen über den FQDN oder den Hostnamen (skip-name-resolve=OFF) mit dem MariaDB-Server verbinden, möchten Sie im Allgemeinen wahrscheinlich den FQDN des MariaDB-Servers als Common Name angeben.

Wir können dann das endgültige X.509-Zertifikat (server-cert.pem) generieren und die CSR (server-req.pem) mit dem CA-Zertifikat (ca.pem) und dem privaten Schlüssel der CA (ca -key.pem):

$ openssl x509 -req -in server-req.pem -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem -days 3650 -sha256
Signature ok
subject=/C=SE/ST=Stockholm/L=Stockholm/O=Severalnines/CN=MariaDBServer/[email protected]
Getting CA Private Key

Zu diesem Zeitpunkt haben wir Folgendes:

$ ls -1 /etc/mysql/transite
ca-key.pem
ca.pem
server-cert.pem
server-key.pem
server-req.pem

Für den MariaDB-Server benötigen wir nur das CA-Zertifikat (ca.pem), das signierte Zertifikat des Servers (server-cert.pem) und den privaten Schlüssel des Servers (server-key.pem). Der CSR (server-req.pem) wird nicht mehr benötigt.

Schlüssel und Zertifikat für den Client

Als nächstes müssen wir Schlüssel- und Zertifikatsdateien für den MariaDB-Client generieren. Der MariaDB-Server akzeptiert nur eine Remote-Verbindung von dem Client, der über diese Zertifikatsdateien verfügt.

Generieren Sie zunächst einen 2048-Bit-Schlüssel für den Client:

$ openssl genrsa 2048 > client-key.pem
Generating RSA private key, 2048 bit long modulus
.............................................................................................................+++
..................................................................................................................+++
e is 65537 (0x10001)

CSR für den Client namens client-req.pem erstellen:

$ openssl req -new -key client-key.pem -out client-req.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:SE
State or Province Name (full name) []:Stockholm
Locality Name (eg, city) [Default City]:Stockholm
Organization Name (eg, company) [Default Company Ltd]:Severalnines
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:Client1
Email Address []:[email protected]

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Achten Sie auf den Common Name, wo wir "Client1" angeben. Geben Sie einen beliebigen Namen an, der den Client darstellt. Dieser Wert muss sich vom Common Name des Servers unterscheiden. Für die erweiterte Verwendung können Sie diesen allgemeinen Namen verwenden, um bestimmten Benutzern mit Zertifikaten, die diesem Wert entsprechen, den Zugriff zu erlauben, zum Beispiel:

MariaDB> GRANT SELECT ON schema1.* TO 'client1'@'192.168.0.93' IDENTIFIED BY 's' REQUIRE SUBJECT '/CN=Client2';

Wir können dann das endgültige X.509-Zertifikat (client-cert.pem) generieren und die CSR (client-req.pem) mit dem CA-Zertifikat (ca.pem) und dem privaten Schlüssel der CA (ca -key.pem):

$ openssl x509 -req -in client-req.pem -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out client-cert.pem -days 3650 -sha256
Signature ok
subject=/C=SE/ST=Stockholm/L=Stockholm/O=Severalnines/CN=Client1/[email protected]
Getting CA Private Key

Alle Zertifikate, die wir für die Einrichtung der In-Transit-Verschlüsselung benötigen, werden generiert. Stellen Sie sicher, dass beide Zertifikate korrekt von der Zertifizierungsstelle signiert sind:

$ openssl verify -CAfile ca.pem server-cert.pem client-cert.pem
server-cert.pem: OK
client-cert.pem: OK

SSL für MariaDB konfigurieren

Erstelle ein neues Verzeichnis auf jedem Slave:

(slave1)$ mkdir -p /etc/mysql/transit/
(slave2)$ mkdir -p /etc/mysql/transit/

Kopieren Sie die Verschlüsselungsdateien auf alle Slaves:

$ scp -r /etc/mysql/transit/* [email protected]:/etc/mysql/transit/
$ scp -r /etc/mysql/transit/* [email protected]:/etc/mysql/transit/

Stellen Sie sicher, dass der Besitzer des certs-Verzeichnisses der "mysql"-Benutzer ist und ändern Sie die Berechtigungen aller Schlüsseldateien, damit sie nicht global lesbar sind:

$ cd /etc/mysql/transit
$ chown -R mysql:mysql *
$ chmod 600 client-key.pem server-key.pem ca-key.pem

Hier ist, was Sie sehen sollten, wenn Sie Dateien im "Transit"-Verzeichnis auflisten:

$ ls -al /etc/mysql/transit
total 32
drwxr-xr-x. 2 root  root 172 Dec 14 04:42 .
drwxr-xr-x. 3 root  root 24 Dec 14 04:18 ..
-rw-------. 1 mysql mysql 1675 Dec 14 04:19 ca-key.pem
-rw-r--r--. 1 mysql mysql 1383 Dec 14 04:22 ca.pem
-rw-r--r--. 1 mysql mysql 1383 Dec 14 04:42 client-cert.pem
-rw-------. 1 mysql mysql 1675 Dec 14 04:42 client-key.pem
-rw-r--r--. 1 mysql mysql 1399 Dec 14 04:42 client-req.pem
-rw-r--r--. 1 mysql mysql 1391 Dec 14 04:34 server-cert.pem
-rw-------. 1 mysql mysql 1679 Dec 14 04:28 server-key.pem
-rw-r--r--. 1 mysql mysql 1415 Dec 14 04:31 server-req.pem

Als Nächstes aktivieren wir die SSL-Verbindung für MariaDB. Bearbeiten Sie auf jedem MariaDB-Host (Master und Slaves) die Konfigurationsdatei und fügen Sie die folgenden Zeilen im Abschnitt [mysqld] hinzu:

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

Starten Sie den MariaDB-Server Knoten für Knoten neu, beginnend mit den Slaves und schließlich auf dem Master:

(slave1)$ systemctl restart mariadb
(slave2)$ systemctl restart mariadb
(master)$ systemctl restart mariadb

Nach dem Neustart ist MariaDB jetzt in der Lage, einfache Verbindungen zu akzeptieren, indem sie sich ohne SSL-bezogene Parameter oder mit verschlüsselten Verbindungen verbindet, wenn Sie SSL-bezogene Parameter in der Verbindungszeichenfolge angeben.

ClusterControl-Benutzer können die Client-Server-Verschlüsselung mit wenigen Klicks aktivieren. Gehen Sie einfach zu ClusterControl -> Security -> SSL Encryption -> Enable -> Create Certificate -> Certificate Expiration -> Enable SSL:

ClusterControl generiert die erforderlichen Schlüssel, das X.509-Zertifikat und das CA-Zertifikat und Richten Sie die SSL-Verschlüsselung für Client-Server-Verbindungen für alle Knoten im Cluster ein. Für die MySQL/MariaDB-Replikation befinden sich die SSL-Dateien unter /etc/ssl/replication/cluster_X, wobei X die Cluster-ID auf jedem Datenbankknoten ist. Auf allen Knoten werden dieselben Zertifikate verwendet, und die vorhandenen werden möglicherweise überschrieben. Die Knoten müssen nach Abschluss dieses Jobs einzeln neu gestartet werden. Wir empfehlen, dass Sie zuerst einen Replikations-Slave neu starten und überprüfen, ob die SSL-Einstellungen funktionieren.

Um jeden Knoten neu zu starten, gehen Sie zu ClusterControl -> Nodes -> Node Actions -> Restart Node. Starten Sie einen Knoten nach dem anderen neu, beginnend mit den Slaves. Der letzte Knoten sollte der Master-Knoten mit aktiviertem Force-Stop-Flag sein:

Sie können feststellen, ob ein Knoten Client-Server-Verschlüsselung handhaben kann, indem Sie Betrachten Sie das grüne Schlosssymbol direkt neben dem Datenbankknoten im Übersichtsraster:

An diesem Punkt ist unser Cluster nun bereit, eine SSL-Verbindung von MySQL zu akzeptieren Benutzer.

Verbinden über verschlüsselte Verbindung

Der MariaDB-Client benötigt alle clientbezogenen SSL-Dateien, die wir innerhalb des Servers generiert haben. Kopieren Sie das generierte Client-Zertifikat, das CA-Zertifikat und den Client-Schlüssel auf den Client-Host:

$ cd /etc/mysql/transit
$ scp client-cert.pem client-key.pem ca.pem [email protected]:~

**ClusterControl generiert die Client-SSL-Dateien unter /etc/ssl/replication/cluster_X/ auf jedem Datenbankknoten, wobei X die Cluster-ID ist.

Erstellen Sie einen Datenbankbenutzer, der SSL auf dem Master benötigt:

MariaDB> CREATE SCHEMA sbtest;
MariaDB> CREATE USER [email protected]'%' IDENTIFIED BY 'mysecr3t' REQUIRE SSL;
MariaDB> GRANT ALL PRIVILEGES ON sbtest.* to [email protected]'%';

Stellen Sie vom Client-Host aus eine Verbindung zum MariaDB-Server mit SSL-bezogenen Parametern her. Wir können den Verbindungsstatus mit der "STATUS"-Anweisung überprüfen:

(client)$ mysql -usbtest -p -h192.168.0.91 -P3306 --ssl-cert client-cert.pem --ssl-key client-key.pem --ssl-ca ca.pem -e 'status'
...
Current user: [email protected]
SSL: Cipher in use is DHE-RSA-AES256-GCM-SHA384
...

Achten Sie auf die SSL-Zeile, wo die Chiffre für die Verschlüsselung verwendet wird. Dies bedeutet, dass der Client erfolgreich über eine verschlüsselte Verbindung mit dem MariaDB-Server verbunden ist.

An diesem Punkt haben wir die Client-Server-Verbindung zum MariaDB-Server verschlüsselt, wie durch den grünen Doppelpfeil im folgenden Diagramm dargestellt:

Im nächsten Teil werden wir Replikationsverbindungen zwischen Knoten verschlüsseln.

Replikationsverschlüsselung

Das Einrichten verschlüsselter Verbindungen für die Replikation ähnelt dem Einrichten von Client/Server-Verbindungen. Wir können dieselben Client-Zertifikate, denselben Schlüssel und dasselbe CA-Zertifikat verwenden, damit der Replikationsbenutzer über den Verschlüsselungskanal auf den Server des Masters zugreifen kann. Dadurch wird indirekt die Verschlüsselung zwischen Knoten aktiviert, wenn der Slave-IO-Thread Replikationsereignisse vom Master abruft.

Lassen Sie uns dies auf jeweils einem Slave konfigurieren. Fügen Sie für den ersten Slave, 192.168.0.92, die folgende Zeile im Abschnitt [client] in der MariaDB-Konfigurationsdatei hinzu:

[client]
ssl-ca=/etc/mysql/transit/ca.pem
ssl-cert=/etc/mysql/transit/client-cert.pem
ssl-key=/etc/mysql/transit/client-key.pem

Stoppen Sie den Replikations-Thread auf dem Slave:

(slave)MariaDB> STOP SLAVE;

Ändern Sie auf dem Master den vorhandenen Replikationsbenutzer, um ihn zu zwingen, sich mit SSL zu verbinden:

(master)MariaDB> ALTER USER [email protected] REQUIRE SSL;

Testen Sie auf dem Slave die Konnektivität zum Master, 192.168.0.91, über die mysql-Befehlszeile mit dem Flag --ssl:

(slave)MariaDB> mysql -urpl_user -p -h192.168.0.91 -P 3306 --ssl -e 'status'
...
Current user: [email protected]
SSL: Cipher in use is DHE-RSA-AES256-GCM-SHA384
...

Stellen Sie sicher, dass Sie sich ohne Fehler mit dem Master-Host verbinden können. Geben Sie dann auf dem Slave die CHANGE MASTER-Anweisung mit den folgenden SSL-Parametern an:

(slave)MariaDB> CHANGE MASTER TO MASTER_SSL = 1, MASTER_SSL_CA = '/etc/mysql/transit/ca.pem', MASTER_SSL_CERT = '/etc/mysql/transit/client-cert.pem', MASTER_SSL_KEY = '/etc/mysql/transit/client-key.pem';

Starte den Replikations-Slave:

(slave)MariaDB> START SLAVE;

Vergewissern Sie sich, dass die Replikation mit den zugehörigen SSL-Parametern ordnungsgemäß ausgeführt wird:

MariaDB> SHOW SLAVE STATUS\G
...
              Slave_IO_Running: Yes
             Slave_SQL_Running: Yes
            Master_SSL_Allowed: Yes
            Master_SSL_CA_File: /etc/mysql/transit/ca.pem
               Master_SSL_Cert: /etc/mysql/transit/client-cert.pem
                Master_SSL_Key: /etc/mysql/transit/client-key.pem
...

Der Slave repliziert nun vom Master sicher über TLS-Verschlüsselung.

Wiederholen Sie alle obigen Schritte auf dem verbleibenden Slave, 192.168.0.93. Der einzige Unterschied ist die alter user-Anweisung, die auf dem Master ausgeführt werden muss, wo wir zu seinem jeweiligen Host wechseln müssen:

(master)MariaDB> ALTER USER [email protected] REQUIRE SSL;

An diesem Punkt haben wir die In-Transit-Verschlüsselung abgeschlossen, wie durch die grünen Linien vom Master zu den Slaves im folgenden Diagramm dargestellt:

Sie können die Verschlüsselungsverbindung überprüfen, indem Sie sich die tcpdump-Ausgabe für die Schnittstelle eth1 ansehen auf den Sklaven. Das Folgende ist ein Beispiel für eine Standardreplikation ohne Verschlüsselung:

(plain-slave)$ tcpdump -i eth1 -s 0 -l -w - 'src port 3306 or dst port 3306' | strings
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
H"-'
binlog.000008Ulw
binlog.000008Ulw
sbtest
sbtest
create table t1 (id INT AUTO_INCREMENT PRIMARY KEY, data VARCHAR(255))
binlog.000008
sbtest
BEGIN3
sbtest
test data3
Ok*Z
binlog.000008*Z

^C11 packets captured
11 packets received by filter
0 packets dropped by kernel

Wir können den Text deutlich sehen, wie er vom Sklaven vom Meister gelesen wird. Bei einer verschlüsselten Verbindung sollten Sie Kauderwelsch wie unten sehen:

(encrypted-slave)$ tcpdump -i eth1 -s 0 -l -w - 'src port 3306 or dst port 3306' | strings
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
:|f^yb#
O5~_
@#PFh
k)]O
jtk3c
@NjN9_a
!\[email protected]
NrF
?7&Y

^C6 packets captured
6 packets received by filter
0 packets dropped by kernel

Fazit

Im nächsten Teil dieser Blogserie werden wir uns mit der Vervollständigung unseres vollständig verschlüsselten Setups mit MariaDB-Verschlüsselung im Ruhezustand befassen. Bleiben Sie dran!