Basisprincipes van MariaDB Server-databaseversleuteling

Encryptie is een van de belangrijkste beveiligingsfuncties om uw gegevens zo veilig mogelijk te houden. Afhankelijk van de gegevens die u verwerkt, is het niet altijd een must, maar u moet het hoe dan ook beschouwen als een beveiligingsverbetering in uw organisatie, en het wordt zelfs aanbevolen om gegevensdiefstal of ongeautoriseerde toegang te voorkomen.

In deze blog zullen we twee basistypen van codering beschrijven en hoe deze te configureren op een MariaDB-server.

Wat is gegevenscodering?

Er zijn twee basistypen gegevensversleuteling:in rust en in-transit. Laten we eens kijken wat ze bedoelen.

Data-at-rest-codering

Gegevens die in een systeem zijn opgeslagen, worden data-at-rest genoemd. De codering van deze gegevens bestaat uit het gebruik van een algoritme om tekst of code onleesbaar te maken. U moet een coderingssleutel hebben om de gecodeerde gegevens te decoderen.

Het versleutelen van een volledige database moet met de nodige voorzichtigheid gebeuren, aangezien dit ernstige gevolgen kan hebben voor de prestaties. Het is daarom verstandig om alleen individuele velden of tabellen te versleutelen.

Het versleutelen van data-at-rest beschermt de data tegen fysieke diefstal van harde schijven of ongeautoriseerde toegang tot bestandsopslag. Deze codering voldoet ook aan de voorschriften voor gegevensbeveiliging, vooral als er financiële of gezondheidsgegevens zijn opgeslagen op het bestandssysteem.

Data-in-Transit-codering

Gegevens die worden overgedragen of tussen transacties worden verplaatst, worden data-in-transit genoemd. De gegevens die tijdens het browsen op webpagina's tussen de server en de client worden verplaatst, zijn een goed voorbeeld van dit soort gegevens.

Omdat het altijd onderweg is, moet het worden beschermd met de juiste codering om diefstal of wijziging van de gegevens te voorkomen voordat het zijn bestemming bereikt.

De ideale situatie om data-in-transit te beschermen, is om de data te versleutelen voordat ze worden verplaatst en pas worden gedecodeerd wanneer ze de eindbestemming bereiken.

MariaDB Data-at-Rest-codering

De codering van tabellen en tabelruimten is toegevoegd in MariaDB vanaf versie 10.1, en ondersteunt codering voor XtraDB-, InnoDB- en Aria-opslagengines, en ook voor binaire logbestanden.

U kunt verschillende manieren kiezen om te coderen:

Alle tafels
Individuele tabellen
Alles, behalve individuele tabellen

Volgens de documentatie heeft het gebruik van codering een overhead van ongeveer 3-5%, dus het is belangrijk om een testomgeving te hebben om deze te benadrukken en te zien hoe deze reageert, om problemen in de productie te voorkomen.

Data-at-rest-codering configureren op MariaDB

Laten we een bestaande "stad"-tabel in een MariaDB-database controleren:

$ strings city.ibd |head

infimum

supremum

infimum

supremum

3ABW

3KHM

infimum

supremum

Kabul                              AFGKabol

Qandahar                           AFGQandahar

Zoals je kunt zien, kun je daar zonder problemen gegevens van lezen met bijvoorbeeld het Linux-commando strings. Laten we nu eens kijken hoe we het kunnen versleutelen.

Genereer een encryptiesleutel met het openssl rand commando:

$ mkdir -p /etc/mysql/encryption

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

Bewerk het gegenereerde bestand /etc/mysql/encryption/keyfile en voeg de sleutel-ID's toe waarnaar wordt verwezen bij het maken van versleutelde tabellen. Het formaat moet als volgt zijn:

<encryption_key_id1>;<hex-encoded_encryption_key1>

<encryption_key_id2>;<hex-encoded_encryption_key2>

Je kunt het als volgt bewerken met het sed linux-commando:

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

Het bestand zou er dus ongeveer zo uit moeten zien:

$ cat /etc/mysql/encryption/keyfile

1;f237fe72e16206c0b0f6f43c3b3f4accc242564d77f5fe17bb621de388c193af

2;0c0819a10fb366a5ea657a71759ee6a950ae8f25a5ba7400a91f59b63683edc5

3;ac9ea3a839596dbf52492d9ab6b180bf11a35f44995b2ed752c370d920a10169

4;72afc936e16a8df05cf994c7902e588de0d11ca7301f9715d00930aa7d5ff8ab

Genereer nu een willekeurig wachtwoord met het vergelijkbare openssl-commando dat u eerder zag:

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

Voordat u doorgaat naar de volgende stap, is het belangrijk om de volgende details te weten over het versleutelen van het sleutelbestand:

Het enige algoritme dat MariaDB momenteel ondersteunt om het sleutelbestand te versleutelen, is de Cipher Block Chaining (CBC)-modus van Advanced Encryption Standard (AES).
De grootte van de coderingssleutel kan 128-bits, 192-bits of 256-bits zijn.
De coderingssleutel wordt gemaakt op basis van de SHA-1-hash van het coderingswachtwoord.
Het coderingswachtwoord heeft een maximale lengte van 256 tekens.

Om het sleutelbestand te coderen met de opdracht openssl enc, voer je de volgende opdracht uit:

$ 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

Ten slotte moet u de volgende parameters toevoegen aan uw my.cnf-configuratiebestand (te vinden in /etc/ op RedHat-gebaseerd besturingssysteem of /etc/mysql/ op op Debian gebaseerd besturingssysteem):

[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 

…

En herstart de MariaDB-service om de wijzigingen door te voeren:

$ systemctl restart mariadb

Op dit punt is alles klaar om de versleutelingsfunctie te gebruiken. Laten we dezelfde tabel coderen die we eerder lieten zien, "stad". Hiervoor moet u de ALTER TABLE-instructie gebruiken die de ENCRYPTED-parameter in YES:

. instelt

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

Query OK, 0 rows affected (0.483 sec)

Records: 0  Duplicates: 0  Warnings: 0

Als u nu rechtstreeks vanuit het bestandssysteem toegang tot de tabel probeert te krijgen, ziet u zoiets als dit:

$ strings city.ibd |head

PU%O

!ybN)b

9,{9WB4

T3uG:

?oiN

,35sz

8g)Q

o(o

q_A1

k=-w

Zoals je kunt zien, is de tabel onleesbaar. U kunt ook de coderingssleutel-ID opgeven door de parameter ENCRYPTION_KEY_ID = toe te voegen aan de MySQL-opdracht, waarbij het ID-nummer is van het eerder gemaakte sleutelbestand.

Nieuwe tabellen worden standaard versleuteld aangezien we de parameter innodb_encrypt_tables op ON zetten in het my.cnf-configuratiebestand.

MariaDB Data-in-Transit-codering

MariaDB stelt u in staat om data-in-transit tussen de server en clients te versleutelen met behulp van het Transport Layer Security-protocol (TLS), voorheen bekend als Secure Socket Layer of SSL.

Allereerst moet je ervoor zorgen dat je MariaDB-server is gecompileerd met TLS-ondersteuning. U kunt dit verifiëren door de volgende instructie SHOW GLOBAL VARIABLES uit te voeren:

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)

En controleer of het momenteel niet in gebruik is met de instructie SHOW VARIABLES:

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)

U kunt de SSL-status ook verifiëren met het status MariaDB-commando:

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

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

Hoe data-in-Transit-codering op MariaDB te configureren

Laten we de certs-map maken om alle certificaten op te slaan:

$ mkdir -p /etc/mysql/certs

Laten we nu de CA-certificaten genereren die worden geconfigureerd om de verbinding te coderen:

$ openssl genrsa 2048 > ca-key.pem

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

Dit laatste commando zal je vragen om de volgende informatie in te vullen:

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 []:

Nu moet u de servercertificaten genereren:

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

Deze opdracht zal u vragen dezelfde informatie in te vullen als voorheen plus een optioneel certificaatwachtwoord.

$ 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

En tot slot moet u de clientcertificaten genereren:

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

Hiermee wordt u ook gevraagd om de informatie en een optioneel certificaatwachtwoord in te vullen.

$ 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

Zorg ervoor dat je op elk certificaat een andere algemene naam gebruikt, anders werkt het niet en ontvang je een bericht als:

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

Op dit moment heb je zoiets als dit:

$ 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

En u kunt de certificaten valideren met het volgende commando:

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

server-cert.pem: OK

client-cert.pem: OK

Laten we het nu configureren in het my.cnf-configuratiebestand (te vinden in /etc/ op RedHat-gebaseerd besturingssysteem of /etc/mysql/ op op Debian gebaseerd besturingssysteem):

[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

Zorg ervoor dat u het toevoegt onder de overeenkomstige sectie (mysqld en client-mariadb).

Wijzig de eigenaar van het certificaat en start de databaseservice opnieuw:

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

$ systemctl restart mariadb

Hierna, als je kijkt naar de uitvoer van SHOW VARIABLES, zou je dit moeten hebben:

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)

Laten we nu een gebruiker maken met de REQUIRE SSL-parameter om deze te gebruiken:

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

Query OK, 0 rows affected (0.005 sec)

Als u deze gebruiker gebruikt om toegang te krijgen tot de database en het statuscommando controleert, ziet u de gebruikte 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

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

SSL-codering inschakelen met ClusterControl

Een andere manier, en zelfs een gemakkelijkere manier, om SSL in uw MariaDB-database in te schakelen, is door ClusterControl te gebruiken. We gaan ervan uit dat u ClusterControl hebt geïnstalleerd en dat u uw MariaDB-database ermee beheert, dus ga naar ClusterControl -> Selecteer uw MariaDB-cluster -> Beveiliging -> SSL-codering -> Inschakelen.

En dat is alles, u heeft uw SSL-codering ingeschakeld in uw MariaDB-database zonder enige handmatige taak.

Versleutelingsbeperkingen in rust in MariaDB

Er zijn enkele beperkingen met betrekking tot MariaDB at-rest-codering waarmee rekening moet worden gehouden:

Metadata (bijvoorbeeld .frm-bestanden) en gegevens die naar de client worden verzonden, worden niet versleuteld.
Alleen de MariaDB-server weet hoe de gegevens moeten worden ontsleuteld, in het bijzonder
- mysqlbinlog kan alleen versleutelde binaire logbestanden lezen wanneer --read-from-remote-server wordt gebruikt.
- Percona XtraBackup kan geen back-up maken van instanties die versleutelde InnoDB gebruiken. Mariabackup kan echter wel een back-up maken van versleutelde instanties.
De schijfgebaseerde Galera-gcache is niet versleuteld in de communityversie van MariaDB Server, maar dit bestand is versleuteld in MariaDB Enterprise Server 10.4.
De Audit-plug-in kan geen versleutelde uitvoer maken. Stuur het naar syslog en configureer daar de beveiliging.
Op bestanden gebaseerd algemeen querylogboek en langzame querylogboeken kunnen niet worden versleuteld.
Het Aria-logboek is niet versleuteld. Dit is alleen van invloed op niet-tijdelijke Aria-tabellen.
Het MariaDB-foutlogboek is niet versleuteld. Het foutenlogboek kan in sommige gevallen vraagtekst en gegevens bevatten, waaronder crashes, mislukte beweringen en gevallen waarin InnoDB/XtraDB monitoruitvoer naar het logboek schrijft om te helpen bij het opsporen van fouten. Het kan indien nodig ook naar syslog worden gestuurd.

Conclusie

Het beschermen van data-in-transit is net zo belangrijk als het beschermen van data-at-rest, en zelfs als het geen must is in uw organisatie, moet u overwegen het toe te passen, omdat het u kan helpen gegevens te vermijden diefstal of ongeoorloofde toegang.

MariaDB heeft een vrij eenvoudige manier om het te implementeren door de eerder genoemde stappen te volgen, maar het is zeker nog eenvoudiger om ClusterControl te gebruiken.