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

Grundlagen der MariaDB-Server-Datenbankverschlüsselung

Verschlüsselung ist eine der wichtigsten Sicherheitsfunktionen, um Ihre Daten so sicher wie möglich zu halten. Abhängig von den Daten, mit denen Sie umgehen, ist dies nicht immer ein Muss, aber Sie sollten es zumindest als Sicherheitsverbesserung in Ihrer Organisation betrachten, und es wird sogar empfohlen, um Datendiebstahl oder unbefugten Zugriff zu vermeiden.

In diesem Blog beschreiben wir zwei grundlegende Arten der Verschlüsselung und wie man sie auf einem MariaDB-Server konfiguriert.

Was ist Datenverschlüsselung?

Es gibt zwei grundlegende Arten der Datenverschlüsselung:im Ruhezustand und während der Übertragung. Mal sehen, was sie bedeuten.

Data-at-Rest-Verschlüsselung

In einem System gespeicherte Daten werden als ruhende Daten bezeichnet. Die Verschlüsselung dieser Daten besteht darin, einen Algorithmus zu verwenden, um Text oder Code unlesbar zu machen. Sie müssen über einen Verschlüsselungsschlüssel verfügen, um die verschlüsselten Daten zu entschlüsseln.

Das Verschlüsseln einer gesamten Datenbank sollte mit Vorsicht erfolgen, da dies zu ernsthaften Leistungseinbußen führen kann. Es ist daher sinnvoll, nur einzelne Felder oder Tabellen zu verschlüsseln.

Die Verschlüsselung ruhender Daten schützt die Daten vor physischem Diebstahl von Festplatten oder unbefugtem Zugriff auf den Dateispeicher. Diese Verschlüsselung entspricht auch den Datenschutzbestimmungen, insbesondere wenn auf dem Dateisystem Finanz- oder Gesundheitsdaten gespeichert sind.

Daten-in-Transit-Verschlüsselung

Daten, die zwischen Transaktionen übertragen oder verschoben werden, werden als Daten während der Übertragung bezeichnet. Die Daten, die beim Surfen auf Webseiten zwischen dem Server und dem Client ausgetauscht werden, sind ein gutes Beispiel für diese Art von Daten.

Da es immer unterwegs ist, muss es mit einer geeigneten Verschlüsselung geschützt werden, um einen Diebstahl oder eine Änderung der Daten zu verhindern, bevor es sein Ziel erreicht.

Die ideale Situation zum Schutz von Daten während der Übertragung besteht darin, dass die Daten verschlüsselt werden, bevor sie übertragen werden, und erst entschlüsselt werden, wenn sie das endgültige Ziel erreichen.

MariaDB Data-at-Rest-Verschlüsselung

Die Verschlüsselung von Tabellen und Tablespaces wurde in MariaDB ab Version 10.1 hinzugefügt und unterstützt die Verschlüsselung für XtraDB-, InnoDB- und Aria-Speicher-Engines sowie für Binärlogs.

Sie können verschiedene Arten der Verschlüsselung wählen:

  • Alle Tische
  • Einzelne Tabellen
  • Alles, ausgenommen einzelne Tabellen

Laut der Dokumentation hat die Verwendung von Verschlüsselung einen Overhead von ungefähr 3-5%, daher ist es wichtig, eine Testumgebung zu haben, um sie zu belasten und zu sehen, wie sie reagiert, um Probleme in der Produktion zu vermeiden.

So konfigurieren Sie Data-at-Rest-Verschlüsselung auf MariaDB

Überprüfen wir eine vorhandene „Stadt“-Tabelle in einer MariaDB-Datenbank:

$ strings city.ibd |head

infimum

supremum

infimum

supremum

3ABW

3KHM

infimum

supremum

Kabul                              AFGKabol

Qandahar                           AFGQandahar

Wie Sie sehen, können Sie Daten von dort problemlos lesen, indem Sie beispielsweise den Linux-Befehl strings verwenden. Sehen wir uns nun an, wie man es verschlüsselt.

Generieren Sie einen Verschlüsselungsschlüssel mit dem Befehl openssl rand:

$ mkdir -p /etc/mysql/encryption

$ for i in {1..4}; do openssl rand -hex 32 >> /etc/mysql/encryption/keyfile;  done;

Bearbeiten Sie die generierte Datei /etc/mysql/encryption/keyfile und fügen Sie die Schlüssel-IDs hinzu, auf die beim Erstellen verschlüsselter Tabellen verwiesen wird. Das Format sollte wie folgt sein:

<encryption_key_id1>;<hex-encoded_encryption_key1>

<encryption_key_id2>;<hex-encoded_encryption_key2>

Sie können es mit dem sed-Linux-Befehl folgendermaßen bearbeiten:

$ for i in {1..4}; do sed -i -e "$i s/^/$i;/" keyfile; done

Die Datei sollte also ungefähr so ​​aussehen:

$ cat /etc/mysql/encryption/keyfile

1;f237fe72e16206c0b0f6f43c3b3f4accc242564d77f5fe17bb621de388c193af

2;0c0819a10fb366a5ea657a71759ee6a950ae8f25a5ba7400a91f59b63683edc5

3;ac9ea3a839596dbf52492d9ab6b180bf11a35f44995b2ed752c370d920a10169

4;72afc936e16a8df05cf994c7902e588de0d11ca7301f9715d00930aa7d5ff8ab

Generieren Sie jetzt ein zufälliges Passwort mit dem ähnlichen openssl-Befehl, den Sie zuvor gesehen haben:

$ openssl rand -hex 128 > /etc/mysql/encryption/keyfile.key

Bevor Sie mit dem nächsten Schritt fortfahren, ist es wichtig, die folgenden Details zur Verschlüsselung der Schlüsseldatei zu kennen:

  • Der einzige Algorithmus, den MariaDB derzeit zum Verschlüsseln der Schlüsseldatei unterstützt, ist der Cipher Block Chaining (CBC)-Modus des Advanced Encryption Standard (AES).
  • Die Größe des Verschlüsselungsschlüssels kann 128 Bit, 192 Bit oder 256 Bit betragen.
  • Der Verschlüsselungsschlüssel wird aus dem SHA-1-Hash des Verschlüsselungskennworts erstellt.
  • Das Verschlüsselungspasswort hat eine maximale Länge von 256 Zeichen.

Führen Sie nun den folgenden Befehl aus, um die Schlüsseldatei mit dem Befehl openssl enc zu verschlüsseln:

$ openssl enc -aes-256-cbc -md sha1 -pass file:/etc/mysql/encryption/keyfile.key -in /etc/mysql/encryption/keyfile -out /etc/mysql/encryption/keyfile.enc

Schließlich müssen Sie die folgenden Parameter in Ihrer my.cnf-Konfigurationsdatei hinzufügen (befindet sich in /etc/ auf RedHat-basierten Betriebssystemen oder /etc/mysql/ auf Debian-basierten Betriebssystemen):

[mysqld]

…

#################### DATABASE ENCRYPTION ####################

plugin_load_add = file_key_management

file_key_management_filename = /etc/mysql/encryption/keyfile.enc

file_key_management_filekey = FILE:/etc/mysql/encryption/keyfile.key

file_key_management_encryption_algorithm = aes_cbc

encrypt_binlog = 1



innodb_encrypt_tables = ON

innodb_encrypt_log = ON

innodb_encryption_threads = 4

innodb_encryption_rotate_key_age = 0 

…

Und starten Sie den MariaDB-Dienst neu, um die Änderungen zu übernehmen:

$ systemctl restart mariadb

Zu diesem Zeitpunkt ist alles bereit, um die Verschlüsselungsfunktion zu verwenden. Lassen Sie uns dieselbe Tabelle verschlüsseln, die wir zuvor gezeigt haben, „Stadt“. Dazu müssen Sie die ALTER TABLE-Anweisung verwenden und den ENCRYPTED-Parameter in YES:

setzen 
MariaDB [world]> ALTER TABLE city ENCRYPTED=YES;

Query OK, 0 rows affected (0.483 sec)

Records: 0  Duplicates: 0  Warnings: 0

Wenn Sie nun versuchen, direkt aus dem Dateisystem auf die Tabelle zuzugreifen, sehen Sie etwa Folgendes:

$ strings city.ibd |head

PU%O

!ybN)b

9,{9WB4

T3uG:

?oiN

,35sz

8g)Q

o(o

q_A1

k=-w

Wie Sie sehen können, ist die Tabelle nicht lesbar. Sie können die Verschlüsselungsschlüssel-ID auch angeben, indem Sie den Parameter ENCRYPTION_KEY_ID = im MySQL-Befehl hinzufügen, wobei die ID-Nummer aus der zuvor erstellten Schlüsseldatei ist.

Neue Tabellen werden standardmäßig verschlüsselt, wenn wir den Parameter innodb_encrypt_tables in der Konfigurationsdatei my.cnf auf ON setzen.

MariaDB Data-in-Transit-Verschlüsselung

MariaDB ermöglicht es Ihnen, Daten während der Übertragung zwischen dem Server und den Clients mit dem Transport Layer Security Protocol (TLS), früher bekannt als Secure Socket Layer oder SSL, zu verschlüsseln.

Zunächst müssen Sie sicherstellen, dass Ihr MariaDB-Server mit TLS-Unterstützung kompiliert wurde. Sie können dies überprüfen, indem Sie die folgende SHOW GLOBAL VARIABLES-Anweisung ausführen:

MariaDB [(none)]> SHOW GLOBAL VARIABLES LIKE 'version_ssl_library';

+---------------------+----------------------------+

| Variable_name       | Value                      |

+---------------------+----------------------------+

| version_ssl_library | OpenSSL 1.1.1  11 Sep 2018 |

+---------------------+----------------------------+

1 row in set (0.001 sec)

Und prüfen Sie mit der SHOW VARIABLES-Anweisung, ob es derzeit nicht verwendet wird:

MariaDB [(none)]> SHOW VARIABLES LIKE '%ssl%';

+---------------------+----------------------------+

| Variable_name       | Value                      |

+---------------------+----------------------------+

| have_openssl        | YES                        |

| have_ssl            | DISABLED                   |

| ssl_ca              |                            |

| ssl_capath          |                            |

| ssl_cert            |                            |

| ssl_cipher          |                            |

| ssl_crl             |                            |

| ssl_crlpath         |                            |

| ssl_key             |                            |

| version_ssl_library | OpenSSL 1.1.1  11 Sep 2018 |

+---------------------+----------------------------+

10 rows in set (0.001 sec)

Sie können den SSL-Status auch mit dem Status-MariaDB-Befehl überprüfen:

MariaDB [(none)]> status

--------------

mysql  Ver 15.1 Distrib 10.4.13-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2

Connection id: 22

Current database:

Current user: [email protected]

SSL: Not in use

Current pager: stdout

Using outfile: ''

Using delimiter: ;

Server: MariaDB

Server version: 10.4.13-MariaDB-1:10.4.13+maria~bionic-log mariadb.org binary distribution

Protocol version: 10

Connection: Localhost via UNIX socket

Server characterset: latin1

Db     characterset: latin1

Client characterset: utf8

Conn.  characterset: utf8

UNIX socket: /var/lib/mysql/mysql.sock

Uptime: 4 hours 28 min 25 sec

Threads: 11  Questions: 111668  Slow queries: 0  Opens: 92  Flush tables: 1  Open tables: 85  Queries per second avg: 6.933

--------------

So konfigurieren Sie die Data-in-Transit-Verschlüsselung auf MariaDB

Lassen Sie uns das certs-Verzeichnis erstellen, um alle Zertifikate zu speichern:

$ mkdir -p /etc/mysql/certs

Generieren wir nun die CA-Zertifikate, die zum Verschlüsseln der Verbindung konfiguriert werden:

$ openssl genrsa 2048 > ca-key.pem

$ openssl req -new -x509 -nodes -days 365000 -key ca-key.pem -out ca-cert.pem

Dieser letzte Befehl fordert Sie auf, die folgenden Informationen zu vervollständigen:

Country Name (2 letter code) [AU]:

State or Province Name (full name) [Some-State]:

Locality Name (eg, city) []:

Organization Name (eg, company) [Internet Widgits Pty Ltd]:

Organizational Unit Name (eg, section) []:

Common Name (e.g. server FQDN or YOUR name) []:

Email Address []:

Jetzt müssen Sie die Serverzertifikate generieren:

$ openssl req -newkey rsa:2048 -nodes -keyout server-key.pem -out server-req.pem

Dieser Befehl fordert Sie auf, die gleichen Informationen wie zuvor sowie ein optionales Zertifikatskennwort einzugeben.

$ openssl rsa -in server-key.pem -out server-key.pem

$ openssl x509 -req -in server-req.pem -days 365000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem

Und schließlich müssen Sie die Client-Zertifikate generieren:

$ openssl req -newkey rsa:2048 -nodes -keyout client-key.pem -out client-req.pem

Dabei werden Sie auch aufgefordert, die Informationen und ein optionales Zertifikatspasswort zu vervollständigen.

$ openssl rsa -in client-key.pem -out client-key.pem

$ openssl x509 -req -in client-req.pem -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.pem

Stellen Sie sicher, dass Sie für jedes Zertifikat einen anderen Common Name verwenden, sonst funktioniert es nicht und Sie erhalten eine Nachricht wie:

ERROR 2026 (HY000): SSL connection error: self signed certificate

Zu diesem Zeitpunkt haben Sie etwa Folgendes:

$ ls /etc/mysql/certs/

ca-cert.pem  ca-key.pem  client-cert.pem  client-key.pem  client-req.pem  server-cert.pem  server-key.pem  server-req.pem

Und Sie können die Zertifikate mit dem folgenden Befehl validieren:

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

server-cert.pem: OK

client-cert.pem: OK

Nun konfigurieren wir es also in der my.cnf-Konfigurationsdatei (befindet sich in /etc/ auf RedHat-basierten Betriebssystemen oder /etc/mysql/ auf Debian-basierten Betriebssystemen):

[mysqld]

ssl_ca=/etc/mysql/certs/ca-cert.pem

ssl_cert=/etc/mysql/certs/server-cert.pem

ssl_key=/etc/mysql/certs/server-key.pem



[client-mariadb]

ssl_ca =/etc/mysql/certs/ca-cert.pem

ssl_cert=/etc/mysql/certs/client-cert.pem

ssl_key=/etc/mysql/certs/client-key.pem

Stellen Sie sicher, dass Sie es unter dem entsprechenden Abschnitt hinzufügen (mysqld und client-mariadb).

Ändern Sie den Inhaber des Zertifikats und starten Sie den Datenbankdienst neu:

$ chown mysql.mysql /etc/mysql/certs/

$ systemctl restart mariadb

Wenn Sie danach einen Blick auf die Ausgabe von SHOW VARIABLES werfen, sollten Sie Folgendes haben:

MariaDB [(none)]> SHOW VARIABLES LIKE '%ssl%';

+---------------------+----------------------------------+

| Variable_name       | Value                            |

+---------------------+----------------------------------+

| have_openssl        | YES                              |

| have_ssl            | YES                              |

| ssl_ca              | /etc/mysql/certs/ca-cert.pem     |

| ssl_capath          |                                  |

| ssl_cert            | /etc/mysql/certs/server-cert.pem |

| ssl_cipher          |                                  |

| ssl_crl             |                                  |

| ssl_crlpath         |                                  |

| ssl_key             | /etc/mysql/certs/server-key.pem  |

| version_ssl_library | OpenSSL 1.1.1  11 Sep 2018       |

+---------------------+----------------------------------+

10 rows in set (0.001 sec)

Erstellen wir nun einen Benutzer mit dem Parameter REQUIRE SSL, um ihn zu verwenden:

MariaDB [(none)]> GRANT ALL PRIVILEGES ON *.* TO 's9s'@'%' IDENTIFIED BY 'root123' REQUIRE SSL;

Query OK, 0 rows affected (0.005 sec)

Wenn Sie diesen Benutzer verwenden, um auf die Datenbank zuzugreifen, und den Statusbefehl überprüfen, sehen Sie das verwendete SSL:

MariaDB [(none)]> status

--------------

mysql  Ver 15.1 Distrib 10.4.13-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2

Connection id: 15

Current database:

Current user: [email protected]

SSL: Cipher in use is TLS_AES_256_GCM_SHA384

Current pager: stdout

Using outfile: ''

Using delimiter: ;

Server: MariaDB

Server version: 10.4.13-MariaDB-1:10.4.13+maria~bionic-log mariadb.org binary distribution

Protocol version: 10

Connection: 127.0.0.1 via TCP/IP

Server characterset: latin1

Db     characterset: latin1

Client characterset: utf8

Conn.  characterset: utf8

TCP port: 3306

Uptime: 16 sec

Threads: 11  Questions: 136  Slow queries: 0  Opens: 17  Flush tables: 1  Open tables: 11  Queries per second avg: 8.500

--------------

So aktivieren Sie die SSL-Verschlüsselung mit ClusterControl

Eine andere und noch einfachere Möglichkeit, SSL in Ihrer MariaDB-Datenbank zu aktivieren, ist die Verwendung von ClusterControl. Wir gehen davon aus, dass Sie ClusterControl installiert haben und Ihre MariaDB-Datenbank damit verwalten, also gehen Sie zu ClusterControl -> MariaDB-Cluster auswählen -> Sicherheit -> SSL-Verschlüsselung -> Aktivieren.

Und fertig, Sie haben Ihre SSL-Verschlüsselung in Ihrer MariaDB-Datenbank aktiviert ohne manuelle Aufgabe.

Beschränkungen der Verschlüsselung im Ruhezustand in MariaDB

Es gibt einige Einschränkungen in Bezug auf die MariaDB-Verschlüsselung im Ruhezustand, die berücksichtigt werden müssen:

  • Metadaten (z. B. .frm-Dateien) und an den Client gesendete Daten werden nicht verschlüsselt.
  • Nur der MariaDB-Server weiß, wie die Daten zu entschlüsseln sind, insbesondere
    • mysqlbinlog kann verschlüsselte Binärprotokolle nur lesen, wenn --read-from-remote-server verwendet wird.
    • Percona XtraBackup kann keine Instanzen sichern, die verschlüsseltes InnoDB verwenden. Mariabackup kann jedoch verschlüsselte Instanzen sichern.
  • Der festplattenbasierte gcache von Galera ist in der Community-Version von MariaDB Server nicht verschlüsselt, diese Datei ist jedoch in MariaDB Enterprise Server 10.4 verschlüsselt.
  • Das Audit-Plugin kann keine verschlüsselte Ausgabe erstellen. Senden Sie es an Syslog und konfigurieren Sie den Schutz stattdessen dort.
  • Dateibasiertes allgemeines Abfrageprotokoll und langsames Abfrageprotokoll können nicht verschlüsselt werden.
  • Das Aria-Protokoll ist nicht verschlüsselt. Dies betrifft nur nicht-temporäre Aria-Tabellen.
  • Das MariaDB-Fehlerprotokoll ist nicht verschlüsselt. Das Fehlerprotokoll kann in einigen Fällen Abfragetext und -daten enthalten, einschließlich Abstürze, Behauptungsfehler und Fälle, in denen InnoDB/XtraDB Monitorausgaben in das Protokoll schreibt, um das Debugging zu unterstützen. Es kann bei Bedarf auch an Syslog gesendet werden.

Fazit

Der Schutz von Daten während der Übertragung ist genauso wichtig wie der Schutz von Daten im Ruhezustand, und selbst wenn dies in Ihrem Unternehmen kein Muss ist, sollten Sie es in Erwägung ziehen, da es Ihnen helfen kann, Daten zu vermeiden Diebstahl oder unbefugter Zugriff.

MariaDB hat eine ziemlich einfache Möglichkeit, es zu implementieren, indem man die zuvor erwähnten Schritte befolgt, aber es ist sicher noch einfacher, ClusterControl zu verwenden.