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

Erkunden der verschiedenen Möglichkeiten zum Verschlüsseln Ihrer MariaDB-Daten

Das Verschlüsseln Ihrer MariaDB-Datenbank, ob während der Übertragung oder im Ruhezustand, ist eines der wichtigsten Dinge, die ein Unternehmen berücksichtigen sollte, wenn Sie Ihre Daten wertschätzen.

Organisationen, die sich mit Finanztransaktionen, Krankenakten, vertraulichen Informationen oder sogar personenbezogenen Daten befassen, müssen diese Art von Datenschutz verlangen. Grundsätzlich wandelt die Datenbankverschlüsselung Ihre lesbaren Daten in ein Format um, das von unbefugten Benutzern nicht gelesen (oder zumindest schwer entschlüsselt) werden kann.

Die Verschlüsselung Ihrer Daten verhindert den Missbrauch oder die böswillige Absicht von Hackern oder nicht autorisiertem Personal, die Ihrem Unternehmen schaden könnten. Unverschlüsselte Daten sind anfällig für Angriffe durch Hacker, die schädliche Daten einschleusen, die Ihre Infrastruktur beschädigen oder Informationen stehlen könnten. Quartz hat vor Kurzem einen Artikel über die größte Datenschutzverletzung in dieser Richtung veröffentlicht, und es ist alarmierend, dass in den letzten zwei Jahrzehnten Daten von Milliarden von Konten gestohlen wurden.

Verwandte Ressourcen So verschlüsseln Sie Ihre MySQL- und MariaDB-Sicherungen Datenbanksicherheit – Sicherungsverschlüsselung während der Übertragung und im Ruhezustand Aktualisiert:Become a ClusterControl DBA – SSL Key Management and Encryption of MySQL Data in Transit

In diesem Blog werden wir verschiedene Möglichkeiten zum Verschlüsseln Ihrer MariaDB-Daten erörtern, unabhängig davon, ob sie ruhen oder übertragen werden. Wir vermitteln Ihnen ein grundlegendes Verständnis der Verschlüsselung und ihrer Verwendung, damit Sie diese Ansätze zum Schutz Ihrer Daten nutzen können.

MariaDB-Daten verschlüsseln:In-Transit

MariaDB verwendet standardmäßig keine Verschlüsselung während der Datenübertragung über das Netzwerk vom Server zum Client. Die Verwendung der Standardkonfiguration könnte jedoch einen potenziellen Hacker dazu bringen, einen ungesicherten / unverschlüsselten Kanal zu belauschen. Wenn Sie in einer isolierten oder hochsicheren Umgebung arbeiten, kann dieser Standardzustand akzeptabel sein. Dies ist jedoch nicht ideal, wenn sich Ihr Client und Ihr Netzwerk in unterschiedlichen Netzwerken befinden, da Ihre Datenbank dadurch auf einen potenziellen „Man-in-the-Middle“-Angriff vorbereitet wird.

Um diese Angriffe zu vermeiden, ermöglicht Ihnen MariaDB, Daten während der Übertragung zwischen dem Server und den Clients mit dem Transport Layer Security (TLS)-Protokoll (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 SHOW GLOBAL VARIABLES-Anweisung wie unten gezeigt ausführen:

MariaDB [(none)]> SHOW GLOBAL VARIABLES LIKE 'version_ssl_library';
+---------------------+---------------------------------+
| Variable_name       | Value                           |
+---------------------+---------------------------------+
| version_ssl_library | OpenSSL 1.0.1e-fips 11 Feb 2013 |
+---------------------+---------------------------------+
1 row in set (0.001 sec)

Sie könnten verwirrt sein, wie sich SSL und TSL unterscheiden. Die Dokumentation verwendet möglicherweise den Begriff SSL und Variablen für die Konfiguration verwenden ebenfalls ssl_* als Präfix, MariaDB unterstützt jedoch nur seine sicheren Nachfolger und nicht mehr die älteren SSL-Versionen. Möglicherweise müssen Sie die richtigen Versionen von MariaDB identifizieren und verwenden, die die richtige Unterstützung der TLS-Versionen erfordern, die Sie verwenden müssen. Beispielsweise empfiehlt PCI DSS v3.2 die Verwendung einer minimalen Protokollversion von TLSv1.2, die alte Versionen von MariaDB unterstützen. TLS 1.3 erfordert jedoch OpenSSL 1.1.1, ist aufgrund eines effizienteren Handshakes zwischen den beiden kommunizierenden Systemen schneller und wird seit MariaDB 10.2.16 und MariaDB 10.3.8 unterstützt.

Um die für eine bestimmte TLS-Version verfügbaren Chiffren zu nutzen, können Sie diese mit --ssl-cipher definieren im mysqld Befehl oder ssl-chiffre Variable in der Konfigurationsdatei. Beachten Sie, dass TLSv1.3-Chiffren bei der Verwendung von OpenSSL nicht ausgeschlossen werden können, auch nicht durch Verwendung der Systemvariablen ssl_cipher.

Konfigurationsparameter zum Verschlüsseln von Daten während der Übertragung

Um Ihre Daten während der Übertragung zu verschlüsseln, können Sie die unten aufgeführte Befehlsfolge ausführen:

Generieren Sie ein CA-Zertifikat

openssl genrsa 2048 > ca-key.pem
openssl req -new -x509 -nodes -days 365000 -subj "/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=CA Server"  -key ca-key.pem -out ca-cert.pem

Generieren Sie ein Serverzertifikat

openssl req -newkey rsa:2048 -days 365000 -nodes -keyout server-key.pem -out server-req.pem -subj "/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=DB Server" 
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

Generieren Sie ein Client-Zertifikat

openssl req -newkey rsa:2048 -days 365000 -nodes -keyout client-key.pem -out client-req.pem  -subj "/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=Client Server"
openssl rsa -in client-key.pem -out client-key.pem
openssl  x509 -req -in client-req.pem -days 365000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.pem

Beachten Sie, dass Ihr Common Name (CN) im -subj Das Argument muss gegenüber Ihren CA-, Server- und Client-Zertifikaten, die Sie generieren, eindeutig sein. Technisch gesehen können CA und Server denselben CN haben, aber es ist am besten, ihn zu einer eindeutigen Kennung für diese drei zu machen. Andernfalls erhalten Sie einen Fehler wie diesen:

ERROR 2026 (HY000): SSL connection error: tlsv1 alert unknown ca

In Ordnung, Zertifikate und Schlüssel sind vorhanden. Sie müssen den Pfad mithilfe der ssl_*-Variablen in Ihrer MySQL-Konfigurationsdatei angeben (z. B. /etc/my.cnf für RHEL-basierte Betriebssysteme oder /etc/mysql/my.cnf für Debian/Ubuntu-Betriebssysteme). Siehe die Beispielkonfiguration unten:

[msqld]
...
ssl_ca=/etc/ssl/galera/self-gen/ca-cert.pem
ssl_cert=/etc/ssl/galera/self-gen/server-cert.pem
ssl_key=/etc/ssl/galera/self-gen/server-key.pem

Natürlich müssen Sie den richtigen Pfad angeben, wo Sie Ihr Zertifikat und Ihre Schlüssel abgelegt haben.

Platzieren Sie diese Parameter dann unter [client-mariadb] Abschnitt Ihrer Konfigurationsdatei wie folgt:

[client-mariadb]
ssl_ca = /etc/ssl/galera/self-gen/ca-cert.pem
ssl_cert=/etc/ssl/galera/self-gen/client-cert.pem
ssl_key=/etc/ssl/galera/self-gen/client-key.pem

Wie bereits erwähnt, können Sie angeben, welche Art von Verschlüsselung Ihre SSL/TLS-Konfiguration verwenden kann. Dies kann durch Angabe des folgenden Konfigurations-Setups erfolgen:

[mysqld]
…
ssl_ca=/etc/ssl/galera/self-gen/ca-cert.pem
ssl_cert=/etc/ssl/galera/self-gen/server-cert.pem
ssl_key=/etc/ssl/galera/self-gen/server-key.pem
ssl-cipher=AES256-GCM-SHA384

Oder Sie können die folgende Konfiguration als solche unten verwenden:

ssl-cipher=TLSv1.2      ### This will use all Ciphers available in TLS v1.2
ssl-cipher=HIGH:!DSS:!RCA-SHA:!DES-CBC3-SHA:[email protected]       ### Will list strong ciphers available and exclude ciphers in prefix.

Die letzte Zeile bezeichnet das Äquivalent dieses Befehls:

openssl ciphers -v 'HIGH:!DSS:!RCA-SHA:!DES-CBC3-SHA:[email protected]'

Dadurch werden schwache Chiffren und Chiffren in Präfixform wie DHE-DSS-AES256-GCM-SHA384 ausgeschlossen Chiffre zum Beispiel.

Generieren Sie Ihr Zertifikat mit ClusterControl

Alternativ können Sie ClusterControl verwenden, um die Zertifikate und Schlüssel für Sie zu generieren. Dazu können Sie wie folgt vorgehen:

  1. Wählen Sie Ihren MariaDB-Cluster aus und gehen Sie dann zu Sicherheit und wählen Sie SSL-Verschlüsselung. In meinem Beispiel unten ist dies ein MariaDB Galera Cluster:
  2. Wählen Sie die SSL-Verschlüsselung und aktivieren Sie sie. Sie können ein neues Zertifikat erstellen oder ein vorhandenes auswählen. Für dieses Beispiel wähle ich die Option "Zertifikat erstellen":
  3. Der letzte Schritt besteht darin, die Ablauftage für Ihr Zertifikat zu konfigurieren. Siehe unten: Wenn Sie auf „Knoten neu starten“ klicken, führt ClusterControl einen fortlaufenden Neustart durch. Beachten Sie, dass Sie SSL verwenden können, wenn Sie MariaDB 10.4 (derzeit in der RC-Version) verwenden, ohne Ihren MariaDB-Server neu zu starten. Verwenden Sie einfach den SSL-Befehl FLUSH, der eine neue Funktion ist, die in der MariaDB-Version 10.4 hinzugefügt wurde.

Eine weitere Möglichkeit, Ihre TLS/SSL-Zertifikate/Schlüssel zu verwalten, ist die Schlüsselverwaltung unter ClusterControl. Sehen Sie sich diesen Blog an, um mehr darüber zu erfahren, wie das geht.

Erstellen Sie Ihren TLS/SSL-MariaDB-Benutzer

Falls Sie dachten, Sie seien fertig, sind Sie es nicht. Sie müssen sicherstellen, dass Ihre Benutzer SSL verwenden müssen, wenn sie sich mit dem Server verbinden. Dieser Benutzer muss immer über einen privaten Kanal mit dem Server interagieren. Dies ist sehr wichtig, da Sie sicherstellen müssen, dass alle Ihre Clients auf sehr sichere und vertrauliche Weise mit Ihrem Server interagieren.

Führen Sie dazu einfach das folgende Beispiel aus:

MariaDB [(none)]> CREATE USER [email protected]'192.168.10.200' IDENTIFIED BY '[email protected]';
Query OK, 0 rows affected (0.005 sec)
MariaDB [(none)]> GRANT ALL ON *.* TO [email protected]'192.168.10.200' REQUIRE SSL;
Query OK, 0 rows affected (0.005 sec)

Stellen Sie sicher, dass Sie beim Herstellen einer Verbindung mit Ihrem Client/Anwendungshost das Zertifikat kopieren, das Sie basierend auf den vorherigen Schritten generiert haben.

Bestätigen Sie Ihre Verbindung

Das Testen Ihrer Verbindung, ob sie verschlüsselt ist oder nicht, ist sehr wichtig, um den Status zu bestimmen. Dazu können Sie den folgenden Befehl unten ausführen:

mysql -e "status"|grep -i 'cipher'
SSL:                    Cipher in use is DHE-RSA-AES256-GCM-SHA384

Alternativ hat OpenSSL Version 1.1.1 Unterstützung für -starttls mysql hinzugefügt . Es gibt eine verfügbare statisch kompilierte Openssl-Binärdatei, die Sie hier herunterladen können https://testssl.sh/openssl-1.0.2k-dev-chacha.pm.ipv6.Linux+FreeBSD.tar.gz (oder sehen Sie sich diese Präsentation im PDF-Format an) . Dann können Sie den folgenden Befehl unten ausführen:

echo | bin/openssl.Linux.x86_64.static s_client -starttls mysql -connect localhost:3306 -CAfile /etc/ssl/galera/self-gen/ca-cert.pem

Das Beispielergebnis würde wie folgt aussehen:

$ echo | bin/openssl.Linux.x86_64.static s_client -starttls mysql -connect localhost:3306 -CAfile /etc/ssl/galera/self-gen/ca-cert.pem 
CONNECTED(00000003)
depth=1 C = PH, ST = Davao Del Sur, L = Davao City, O = Maximus Aleksandre, CN = CA Server
verify return:1
depth=0 C = PH, ST = Davao Del Sur, L = Davao City, O = Maximus Aleksandre, CN = DB Server
verify return:1
---
Certificate chain
 0 s:/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=DB Server
   i:/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=CA Server
 1 s:/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=CA Server
   i:/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=CA Server
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDTDCCAjQCAQEwDQYJKoZIhvcNAQELBQAwazELMAkGA1UEBhMCUEgxFjAUBgNV
BAgMDURhdmFvIERlbCBTdXIxEzARBgNVBAcMCkRhdmFvIENpdHkxGzAZBgNVBAoM
Ek1heGltdXMgQWxla3NhbmRyZTESMBAGA1UEAwwJQ0EgU2VydmVyMCAXDTE5MDYx
MDAyMTMwNFoYDzMwMTgxMDExMDIxMzA0WjBrMQswCQYDVQQGEwJQSDEWMBQGA1UE
CAwNRGF2YW8gRGVsIFN1cjETMBEGA1UEBwwKRGF2YW8gQ2l0eTEbMBkGA1UECgwS
TWF4aW11cyBBbGVrc2FuZHJlMRIwEAYDVQQDDAlEQiBTZXJ2ZXIwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDNwFuoqJg8YlrDinxDZN4+JjFUTGlDfhmy
9H/1C4fZToegvd3RzU9mz3/Fgyuoez4szHDgkn7o4rqmKAH6tMm9R44qtBNGlxka
fn12PPXudDvij4A9C3nVatBJJXTSvSD4/eySY33kAS1DpKsgsTgKAKOsyadcvXYU
IP5nfFc7pxX/8qZADVmyeik4M+oLxO6ryurt0wmUhOmlz5zQghh9kFZLA49l+p95
m5D53d/O+Qj4HSb2ssZD2ZaRc2k4dMCVpa87xUbdP/VVLeu0J4BE3OJiwC0N1Jfi
ZpP2DOKljsklaAYQF+tPnWi5pgReEd47/ql0fNEjeheF/MJiJM1NAgMBAAEwDQYJ
KoZIhvcNAQELBQADggEBAAz7yB+UdNYJ1O5zJI4Eb9lL+vNVKhRJ8IfNrwKVbpAT
eQk9Xpn9bidfcd2gseqDTyixZhWjsjO2LXix7jRhH1DrJvhGQ7+1w36ujtzscTgy
ydLH90CnE/oZHArbBhmyuqmu041w5rB3PpI9i9SveezDrbVcaL+qeGo8s4ATB2Yr
Y3T3OTqw6o/7cTJJ8S1aXBLTyUq5HAtOTM2GGZMSYwVqUsmBHA3d7M8i7yp20RVH
78j1H6+/hSSY4SDhwr04pSkzmm6HTIBCgOYrmEV2sQ/YeMHqVrSplLRY3SZHvqHo
gbSnasOQAE1oJnSNyxt9CRRAghM/EHEnsA2OlFa9iXQ=
-----END CERTIFICATE-----
subject=/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=DB Server
issuer=/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=CA Server
---
No client certificate CA names sent
Client Certificate Types: RSA fixed DH, DSS fixed DH, RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Peer signing digest: SHA512
Server Temp Key: DH, 2048 bits
---
SSL handshake has read 3036 bytes and written 756 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : DHE-RSA-AES256-GCM-SHA384
    Session-ID: 46E0F6FA42779DB210B4DF921A68E9E4CC39ADD87D28118DB0073726B98C0786
    Session-ID-ctx: 
    Master-Key: 2A2E6137929E733051BE060953049A0553F49C2F50A183EEC0C40F7EFB4E2749E611DF54A88417518A274EC904FB3CE6
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 4a dd f3 7f 1e b7 9e cb-77 58 b9 75 53 34 5c 61   J.......wX.uS4\a
    0010 - 3a 4d 0e aa e2 6b 27 8e-11 ff be 24 ad 66 88 49   :M...k'....$.f.I
    0020 - c1 ba 20 20 d8 9f d5 5c-23 9d 64 dc 97 f2 fa 77   ..  ...\#.d....w
    0030 - bf e6 26 1f 2c 98 ee 3b-71 66 0c 04 05 3e 54 c1   ..&.,..;qf...>T.
    0040 - 88 b6 f7 a9 fd b8 f9 84-cd b8 99 9f 6e 50 3b 13   ............nP;.
    0050 - 90 30 91 7d 48 ea 11 f7-3f b7 6b 65 2e ea 7e 61   .0.}H...?.ke..~a
    0060 - 70 cd 4e b8 43 54 3d a0-aa dc e5 44 a7 41 3a 5e   p.N.CT=....D.A:^
    0070 - 3e cb 45 57 33 2b a4 8f-75 d8 ce a5 9e 00 16 50   >.EW3+..u......P
    0080 - 24 aa 7a 54 f8 26 65 74-11 d7 f3 d6 66 3b 14 60   $.zT.&et....f;.`
    0090 - 33 98 4a ef e2 17 ba 33-4e 7f 2b ce 46 d7 e9 11   3.J....3N.+.F...

    Start Time: 1560133350
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
DONE
ClusterControlEine Konsole für Ihre gesamte DatenbankinfrastrukturErfahren Sie, was es sonst noch Neues in ClusterControl gibt. Installieren Sie ClusterControl KOSTENLOS

Verschlüsseln von MariaDB-Daten:At-Rest

Verschlüsselte Daten, die physisch in Ihrem Hardwarespeicher (d. h. im Ruhezustand) gespeichert sind, bieten mehr Stabilität und Schutz vor einer Datenpanne. Wenn sich ein böswilliger Angreifer bei Ihrer MariaDB-Datenbank anmelden kann, kann er die Daten im Klartext lesen. Ähnlich wie bei der Verwendung eines Zeichenfolgenbefehls in Linux können Sie die Daten einfach aus der Datenbank abrufen. Darüber hinaus erhöht es die Gefahr, wenn der Angreifer ein fortgeschrittenes Verständnis des Dateiformats des Tablespace hat.

Die Verschlüsselung im Ruhezustand ist ein zusätzlicher Schutz, aber kein Ersatz für eine gute Firewall, starke Kennwörter, korrekte Benutzerberechtigungen und Verschlüsselung während der Übertragung zwischen Client und Server.

MariaDBs Unterstützung für die Verschlüsselung von Tabellen und Tablespaces wurde in Version 10.1.3 hinzugefügt. Da Ihre Tabellen verschlüsselt sind, ist es fast unmöglich, Ihre Daten zu stehlen. Diese Art der Verschlüsselung ermöglicht es Ihrem Unternehmen auch, behördliche Vorschriften wie die DSGVO einzuhalten.,

Sobald Sie die Data-at-Rest-Verschlüsselung in MariaDB aktiviert haben, werden Tabellen, die mit ENCRYPTED=YES oder mit innodb_encrypt_tables=ON definiert sind, Ihre gespeicherten Daten verschlüsselt haben. Sie werden nur entschlüsselt, wenn über die Datenbank von MariaDB zugegriffen wird, andernfalls sind die Daten nicht lesbar.

Wenn Sie beispielsweise unverschlüsselte Daten lesen, wird es Ihnen als solche angezeigt:

$ strings admin_logs.ibd|head -10
=r7N
infimum
supremum
infimum
supremum/
failThe verification code you entered is incorrect.KK
elmo1234failThe password or username you entered is invalidKK
elmo1234failThe password or username you entered is invalidKK
elmoasfdfailThe verification code you entered is incorrect.KK
safasffailThe verification code you entered is incorrect.KK

aber mit verschlüsselten Daten ist Ihr Tablespace nicht lesbar, wie im folgenden Beispiel:

# strings user_logs.ibd |head -10
E?*Pa
[+YQ
KNmbUtQ
T_lPAW
\GbQ.
] e2
#Rsd
ywY%o
kdUY
{]~GE

Es ist auch bemerkenswert, dass die Data-at-Rest-Verschlüsselung von MariaDB einen Datengrößen-Overhead von etwa 3-5 % hinzufügt. Die MariaDB-Verschlüsselung wird auch bei Verwendung der XtraDB- und InnoDB-Speicher-Engines vollständig unterstützt. Die Verschlüsselung wird auch für die Aria-Speicher-Engine unterstützt, jedoch nur für Tabellen, die mit ROW_FORMAT=PAGE (Standardeinstellung) erstellt wurden, und für das Binärprotokoll (Replikationsprotokoll). MariaDB lässt dem Benutzer sogar flexibel, was verschlüsselt werden soll. In XtraDB oder InnoDB kann man wählen zu verschlüsseln:

  • alles — alle Tablespaces (mit allen Tabellen)
  • einzelne Tabellen
  • alles, ausgenommen einzelne Tabellen

Zusätzlich kann man sich dafür entscheiden, XtraDB/InnoDB-Protokolldateien zu verschlüsseln (was empfohlen wird).

MariaDB hat seine Grenzen. Galera Cluster gcache ist beispielsweise nicht verschlüsselt, aber als Teil der Version MariaDB 10.4 geplant. Eine vollständige Liste der Einschränkungen finden Sie hier.

Wie man MariaDB für Data-at-Rest-Verschlüsselung einrichtet und konfiguriert

  1. Generieren Sie einen zufälligen Verschlüsselungsschlüssel mit dem Befehl openssl rand.
    $ mkdir -p /etc/mysql/encryption
    $ for i in {1..5}; do openssl rand -hex 32 >> /etc/mysql/encryption/keyfile;  done;
    Öffnen und bearbeiten Sie nun die Datei /etc/mysql/encryption/keyfile und fügen Sie die Schlüssel-IDs hinzu, auf die beim Erstellen verschlüsselter Tabellen als Verschlüsselungsschlüssel-ID verwiesen wird. Weitere Einzelheiten finden Sie unter ENCRYPTION_KEY_ID. Daher sollte das folgende Format wie folgt aussehen:
    <encryption_key_id1>;<hex-encoded_encryption_key1>
    <encryption_key_id2>;<hex-encoded_encryption_key2>
    In my example keyfile, this looks as the following:
    $ cat keyfile
    1;687a90b4423c10417f2483726a5901007571c16331d2ee9534333fef4e323075
    2;e7bf20f1cbde9632587c2996871cff74871890d19b49e273d13def123d781e17
    3;9284c9c80da9a323b3ac2c82427942dfbf1718b57255cc0bc0e2c3d6f15ac3ac
    4;abf80c3a8b10643ef53a43c759227304bcffa263700a94a996810b0f0459a580
    5;bdbc5f67d34a4904c4adc9771420ac2ab2bd9c6af1ec532e960335e831f02933
  2. Lassen Sie uns mit dem ähnlichen Befehl aus Schritt 1 ein zufälliges Passwort erstellen oder generieren:
    $ openssl rand -hex 128 > /etc/mysql/encryption/keyfile.key
  3. Bevor Sie mit dem nächsten Schritt fortfahren, ist es wichtig, die folgenden Details zur Verschlüsselung der Schlüsseldatei zu beachten:
    • 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.
    Um nun die Schlüsseldatei mit dem Befehl openssl enc zu verschlüsseln, führen Sie den folgenden Befehl aus:
    $ 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
  4. Fügen Sie die folgenden Variablen zu Ihrer MySQL-Konfigurationsdatei hinzu (z. B. /etc/my.cnf auf RHEL-basierten Linux-Betriebssystemen oder /etc/mysql/my.cnf auf Debian/Ubuntu-Linux-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 # Do not rotate key
  5. MariaDB Server jetzt neu starten
    $ systemctl start mariadb

Verifizieren und testen Sie die Verschlüsselung

Um die Verschlüsselung zu überprüfen und zu testen, erstellen Sie einfach eine Beispieltabelle. Erstellen Sie beispielsweise die Tabelle, indem Sie die folgenden SQL-Anweisungen unten ausführen:

MariaDB [test]> CREATE TABLE a (i int) ENGINE=InnoDB ENCRYPTED=YES;
Query OK, 0 rows affected (0.018 sec)
MariaDB [test]> CREATE TABLE b (i int) ENGINE=InnoDB;
Query OK, 0 rows affected (0.003 sec)

Dann fügen wir einige Daten zu den Tabellen hinzu:

MariaDB [test]> insert into a values(1),(2);
Query OK, 2 rows affected (0.001 sec)
Records: 2  Duplicates: 0  Warnings: 0
MariaDB [test]> insert into b values(1),(2);
Query OK, 2 rows affected (0.001 sec)
Records: 2  Duplicates: 0  Warnings: 0

Um zu überprüfen und zu sehen, welche Tabellen verschlüsselt sind, führen Sie einfach das folgende SELECT aus Abfrage unten:

MariaDB [test]> SELECT * FROM information_schema.innodb_tablespaces_encryption\G
*************************** 1. row ***************************
                       SPACE: 4
                        NAME: mysql/gtid_slave_pos
           ENCRYPTION_SCHEME: 1
          KEYSERVER_REQUESTS: 1
             MIN_KEY_VERSION: 1
         CURRENT_KEY_VERSION: 1
    KEY_ROTATION_PAGE_NUMBER: NULL
KEY_ROTATION_MAX_PAGE_NUMBER: NULL
              CURRENT_KEY_ID: 1
        ROTATING_OR_FLUSHING: 0
*************************** 2. row ***************************
                       SPACE: 2
                        NAME: mysql/innodb_index_stats
           ENCRYPTION_SCHEME: 1
          KEYSERVER_REQUESTS: 1
             MIN_KEY_VERSION: 1
         CURRENT_KEY_VERSION: 1
    KEY_ROTATION_PAGE_NUMBER: NULL
KEY_ROTATION_MAX_PAGE_NUMBER: NULL
              CURRENT_KEY_ID: 1
        ROTATING_OR_FLUSHING: 0
*************************** 3. row ***************************
                       SPACE: 1
                        NAME: mysql/innodb_table_stats
           ENCRYPTION_SCHEME: 1
          KEYSERVER_REQUESTS: 1
             MIN_KEY_VERSION: 1
         CURRENT_KEY_VERSION: 1
    KEY_ROTATION_PAGE_NUMBER: NULL
KEY_ROTATION_MAX_PAGE_NUMBER: NULL
              CURRENT_KEY_ID: 1
        ROTATING_OR_FLUSHING: 0
*************************** 4. row ***************************
                       SPACE: 3
                        NAME: mysql/transaction_registry
           ENCRYPTION_SCHEME: 1
          KEYSERVER_REQUESTS: 0
             MIN_KEY_VERSION: 1
         CURRENT_KEY_VERSION: 1
    KEY_ROTATION_PAGE_NUMBER: NULL
KEY_ROTATION_MAX_PAGE_NUMBER: NULL
              CURRENT_KEY_ID: 1
        ROTATING_OR_FLUSHING: 0
*************************** 5. row ***************************
                       SPACE: 5
                        NAME: test/a
           ENCRYPTION_SCHEME: 1
          KEYSERVER_REQUESTS: 1
             MIN_KEY_VERSION: 1
         CURRENT_KEY_VERSION: 1
    KEY_ROTATION_PAGE_NUMBER: NULL
KEY_ROTATION_MAX_PAGE_NUMBER: NULL
              CURRENT_KEY_ID: 1
        ROTATING_OR_FLUSHING: 0
*************************** 6. row ***************************
                       SPACE: 6
                        NAME: test/b
           ENCRYPTION_SCHEME: 1
          KEYSERVER_REQUESTS: 1
             MIN_KEY_VERSION: 1
         CURRENT_KEY_VERSION: 1
    KEY_ROTATION_PAGE_NUMBER: NULL
KEY_ROTATION_MAX_PAGE_NUMBER: NULL
              CURRENT_KEY_ID: 1
        ROTATING_OR_FLUSHING: 0
6 rows in set (0.000 sec)

Beim Erstellen der InnoDB-Tabelle muss das Schlüsselwort ENCRYPTED=YES nicht angegeben werden. Es wird automatisch erstellt, da wir in der Konfigurationsdatei angegeben haben, dass innodb_encrypt_tables =ON.

ist

Wenn Sie die Verschlüsselungs-ID der zu verwendenden Tabelle angeben möchten, können Sie auch Folgendes tun:

MariaDB [test]> CREATE TABLE c (i int) ENGINE=InnoDB ENCRYPTION_KEY_ID = 4;
Query OK, 0 rows affected (0.003 sec)

Die ENCRYPTION_KEY_ID wurde der Verschlüsselungsschlüsseldatei entnommen, die wir zuvor generiert haben.

Wenn Sie darüber hinaus weitere Tests durch die Shell wünschen, können Sie die Strings verwenden Befehl, den ich Ihnen vorhin gezeigt habe.

Zusätzliche Informationen zur MariaDB-Verschlüsselung

Wenn Ihre MariaDB-Instanz keine unverschlüsselten Tabellen enthalten soll, richten Sie einfach die Variable in Ihrer my.cnf-Konfigurationsdatei innerhalb des [mysqld] ein Abschnitt wie folgt:

innodb_encrypt_tables = FORCE.

Fügen Sie für die Binlog-Verschlüsselung einfach Folgendes hinzu

encrypt_binlog = 1

Das Redo-Log von InnoDB ist standardmäßig nicht verschlüsselt. Um es zu verschlüsseln, fügen Sie einfach die folgende Variable nach dem Abschnitt [mysqld] hinzu,

innodb-encrypt-log

Wenn Sie eine Verschlüsselung für Ihre temporären Tabellen und temporären Dateien auf der Festplatte benötigen, können Sie Folgendes hinzufügen:

encrypt-tmp-disk-tables=1
encrypt-tmp-files=1