V této sérii blogů vám poskytneme kompletní návod, jak nakonfigurovat plně šifrovaný server MariaDB pro šifrování v klidu a při přenosu, abyste zajistili maximální ochranu dat před odcizené fyzicky nebo při přenosu a komunikaci s jinými hostiteli. Základní myšlenkou je, že přeměníme naše „prosté“ nasazení na plně šifrovanou replikaci MariaDB, jak je zjednodušeno na následujícím diagramu:
Chystáme se nakonfigurovat řadu komponent šifrování:
- In-transit šifrování, které se skládá z:
- Šifrování klient-server
- Šifrování replikace
- Klidové šifrování, které se skládá z:
- Šifrování datových souborů
- Binární/přenosové šifrování protokolu.
Upozorňujeme, že tento blogový příspěvek pojednává pouze o šifrování při přenosu. V druhé části této blogové série se budeme zabývat klidovým šifrováním.
Tento návod k nasazení předpokládal, že již máme spuštěný replikační server MariaDB. Pokud žádnou nemáte, můžete použít ClusterControl k nasazení nové replikace MariaDB během několika minut, s méně než 5 kliknutími. Všechny servery běží na MariaDB 10.4.11 na systému CentOS 7.
Šifrování během přepravy
Data mohou být vystavena rizikům při přenosu i v klidu a vyžadují ochranu v obou stavech. Šifrování během přenosu chrání vaše data, pokud dojde k zachycení komunikace, zatímco se data přesouvají mezi hostiteli po síti, buď z vašeho webu a poskytovatele cloudu, mezi službami nebo mezi klienty a serverem.
U MySQL/MariaDB jsou data v pohybu, když se klient připojí k databázovému serveru nebo když podřízený uzel replikuje data z hlavního uzlu. MariaDB podporuje šifrovaná spojení mezi klienty a serverem pomocí protokolu TLS (Transport Layer Security). TLS se někdy označuje jako SSL (Secure Sockets Layer), ale MariaDB ve skutečnosti nepoužívá protokol SSL pro šifrovaná připojení, protože jeho šifrování je slabé. Další podrobnosti o tomto na stránce dokumentace MariaDB.
Šifrování klient-server
V tomto nastavení budeme používat certifikáty s vlastním podpisem, což znamená, že k ověření naší identity nepoužíváme externí strany, jako je Google, Comodo nebo jakýkoli jiný oblíbený poskytovatel certifikačních autorit. V SSL/TLS je ověření identity prvním krokem, který musí projít, než si server a klient vymění své certifikáty a klíče.
MySQL poskytuje velmi praktický nástroj zvaný mysql_ssl_rsa_setup, který se automaticky stará o generování klíče a certifikátu. Bohužel pro server MariaDB zatím žádný takový nástroj neexistuje. Proto musíme ručně připravit a vygenerovat soubory související s SSL pro naše potřeby MariaDB TLS.
Následuje seznam souborů, které vygenerujeme pomocí nástroje OpenSSL:
- Klíč CA - RSA soukromý klíč ve formátu PEM. Musí zůstat v tajnosti.
- Certifikát CA - Certifikát X.509 ve formátu PEM. Obsahuje metadata veřejného klíče a certifikátu.
- CSR serveru - Žádost o podpis certifikátu. Společný název (CN) při vyplňování formuláře je důležitý, například CN=mariadb-server
- Serverový klíč - RSA soukromý klíč. Musí zůstat v tajnosti.
- Certifikace serveru - Certifikát X.509 podepsaný klíčem CA. Obsahuje metadata veřejného klíče a certifikátu.
- CSR klienta - Žádost o podpis certifikátu. Musí použít jiný Common Name (CN) než CSR serveru, například CN=client1
- Klientský klíč - RSA soukromý klíč. Musí zůstat v tajnosti.
- Klientský certifikát - Certifikát X.509 podepsaný klíčem CA. Obsahuje metadata veřejného klíče a certifikátu.
Především vytvořte adresář pro uložení našich certifikátů a klíčů pro šifrování při přenosu:
$ mkdir -p /etc/mysql/transit/
$ cd /etc/mysql/transit/Pro představu, proč pojmenováváme adresář tak, jak je uvedeno, je to proto, že v příštím díle této série blogů vytvoříme další adresář pro klidové šifrování v /etc/mysql/rest.
Certifikační autorita
Vygenerujte soubor klíče pro naši vlastní certifikační autoritu (CA):
$ openssl genrsa 2048 > ca-key.pem
Generating RSA private key, 2048 bit long modulus
.......................+++
...............................................................................................................................................................................................................................................+++
e is 65537 (0x10001)Vygenerujte certifikát pro naši vlastní certifikační autoritu (CA) na základě dříve vygenerovaného souboru ca-key.pem s platností 3650 dní:
$ 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]Nyní bychom měli mít v tomto pracovním adresáři ca-key.pem a ca.pem.
Klíč a certifikát pro server
Dále vygenerujte soukromý klíč pro server MariaDB:
$ openssl genrsa 2048 > server-key.pem
Generating RSA private key, 2048 bit long modulus
.............................................................................................................+++
..................................................................................................................+++
e is 65537 (0x10001)Důvěryhodný certifikát musí být certifikát podepsaný certifikační autoritou, přičemž zde budeme používat naši vlastní CA, protože důvěřujeme hostitelům v síti. Než budeme moci vytvořit podepsaný certifikát, musíme vygenerovat certifikát žádosti s názvem Certificate Signing Request (CSR).
Vytvořte CSR pro server MariaDB. Certifikát budeme nazývat server-req.pem. Toto není certifikát, který budeme používat pro server MariaDB. Konečný certifikát je ten, který bude podepsán naším vlastním soukromým klíčem CA (jak je znázorněno v dalším kroku):
$ 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 []:Všimněte si běžného názvu, kde jsme zadali „MariaDBServer“. Může to být libovolný název, ale hodnota nesmí být stejná jako klientský certifikát. Obvykle, pokud se aplikace připojují k serveru MariaDB přes FQDN nebo název hostitele (skip-name-resolve=OFF), pravděpodobně budete chtít zadat FQDN serveru MariaDB jako Common Name.
Potom můžeme vygenerovat konečný certifikát X.509 (server-cert.pem) a podepsat CSR (server-req.pem) certifikátem CA (ca.pem) a soukromým klíčem CA (cca -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 KeyV tuto chvíli máme toto:
$ ls -1 /etc/mysql/transite
ca-key.pem
ca.pem
server-cert.pem
server-key.pem
server-req.pemPotřebujeme pouze certifikát CA (ca.pem), podepsaný certifikát serveru (server-cert.pem) a soukromý klíč serveru (server-key.pem) pro server MariaDB. CSR (server-req.pem) již není vyžadován.
Klíč a certifikát pro klienta
Dále musíme vygenerovat soubory klíčů a certifikátů pro klienta MariaDB. Server MariaDB bude přijímat vzdálené připojení pouze od klienta, který má tyto soubory certifikátu.
Začněte vygenerováním 2048bitového klíče pro klienta:
$ openssl genrsa 2048 > client-key.pem
Generating RSA private key, 2048 bit long modulus
.............................................................................................................+++
..................................................................................................................+++
e is 65537 (0x10001)Vytvořte CSR pro klienta s názvem client-req.pem:
$ 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 []:Věnujte pozornost běžnému názvu, kde zadáváme "Klient1". Zadejte libovolný název, který zastupuje klienta. Tato hodnota se musí lišit od běžného názvu serveru. Pro pokročilé použití můžete tento Common Name použít k povolení určitého uživatele s certifikátem odpovídajícím této hodnotě, například:
MariaDB> GRANT SELECT ON schema1.* TO 'client1'@'192.168.0.93' IDENTIFIED BY 's' REQUIRE SUBJECT '/CN=Client2';Potom můžeme vygenerovat konečný certifikát X.509 (client-cert.pem) a podepsat CSR (client-req.pem) pomocí certifikátu CA (ca.pem) a soukromého klíče CA (cca -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 KeyVygenerují se všechny certifikáty, které potřebujeme pro nastavení šifrování při přenosu. Ověřte, zda jsou oba certifikáty správně podepsány CA:
$ openssl verify -CAfile ca.pem server-cert.pem client-cert.pem
server-cert.pem: OK
client-cert.pem: OKKonfigurace SSL pro MariaDB
Vytvořte nový adresář na každém slave:
(slave1)$ mkdir -p /etc/mysql/transit/
(slave2)$ mkdir -p /etc/mysql/transit/Zkopírujte šifrovací soubory do všech slave:
$ scp -r /etc/mysql/transit/* [email protected]:/etc/mysql/transit/
$ scp -r /etc/mysql/transit/* [email protected]:/etc/mysql/transit/Ujistěte se, že vlastníkem adresáře certs je uživatel "mysql" a změňte oprávnění všech klíčových souborů, aby nebyl globálně čitelný:
$ cd /etc/mysql/transit
$ chown -R mysql:mysql *
$ chmod 600 client-key.pem server-key.pem ca-key.pemZde je to, co byste měli vidět při výpisu souborů v adresáři "transit":
$ 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.pemDále povolíme připojení SSL pro MariaDB. Na každém hostiteli MariaDB (master a slave) upravte konfigurační soubor a do sekce [mysqld] přidejte následující řádky:
ssl-ca=/etc/mysql/transit/ca.pem
ssl-cert=/etc/mysql/transit/server-cert.pem
ssl-key=/etc/mysql/transit/server-key.pemRestartujte server MariaDB jeden uzel po druhém, počínaje od podřízených a nakonec na hlavním:
(slave1)$ systemctl restart mariadb
(slave2)$ systemctl restart mariadb
(master)$ systemctl restart mariadbPo restartování je MariaDB nyní schopna přijímat jednoduchá připojení tím, že se k ní připojíte bez jakýchkoli parametrů souvisejících s SSL nebo se šifrovanými připojeními, pokud v řetězci připojení zadáte parametr související s SSL.
Pro uživatele ClusterControl můžete povolit šifrování klient-server otázkou kliknutí. Stačí přejít na ClusterControl -> Zabezpečení -> Šifrování SSL -> Povolit -> Vytvořit certifikát -> Vypršení platnosti certifikátu -> Povolit SSL:
ClusterControl vygeneruje požadované klíče, certifikát X.509 a certifikát CA a nastavit šifrování SSL pro připojení klient-server pro všechny uzly v clusteru. Pro replikaci MySQL/MariaDB budou soubory SSL umístěny pod /etc/ssl/replication/cluster_X, kde X je ID clusteru na každém databázovém uzlu. Na všech uzlech budou použity stejné certifikáty a stávající mohou být přepsány. Po dokončení této úlohy musí být uzly jednotlivě restartovány. Doporučujeme nejprve restartovat slave replikaci a ověřit, že nastavení SSL funguje.
Chcete-li restartovat každý uzel, přejděte na ClusterControl -> Nodes -> Node Actions -> Restart Node. Restartujte jeden uzel po druhém, počínaje podřízenými. Poslední uzel by měl být hlavní uzel s povoleným příznakem vynucení zastavení:
Zda je uzel schopen zpracovat šifrování klient-server, poznáte podle při pohledu na zelenou ikonu zámku hned vedle uzlu databáze v mřížce Přehled:
V tuto chvíli je náš cluster nyní připraven přijímat připojení SSL z MySQL uživatelé.
Připojení prostřednictvím šifrovaného připojení
Klient MariaDB vyžaduje všechny soubory SSL týkající se klienta, které jsme vygenerovali na serveru. Zkopírujte vygenerovaný klientský certifikát, certifikát CA a klientský klíč do klientského hostitele:
$ cd /etc/mysql/transit
$ scp client-cert.pem client-key.pem ca.pem [email protected]:~**ClusterControl generuje klientské soubory SSL pod /etc/ssl/replication/cluster_X/na každém databázovém uzlu, kde X je ID clusteru.
Vytvořte uživatele databáze, který vyžaduje SSL na hlavním serveru:
MariaDB> CREATE SCHEMA sbtest;
MariaDB> CREATE USER [email protected]'%' IDENTIFIED BY 'mysecr3t' REQUIRE SSL;
MariaDB> GRANT ALL PRIVILEGES ON sbtest.* to [email protected]'%';Z klientského hostitele se připojte k serveru MariaDB s parametry souvisejícími s SSL. Stav připojení můžeme ověřit pomocí příkazu "STATUS":
(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
...Věnujte pozornost řádku SSL, kde je šifra použita pro šifrování. To znamená, že klient je úspěšně připojen k serveru MariaDB prostřednictvím šifrovaného připojení.
V tuto chvíli jsme zašifrovali připojení klient-server k serveru MariaDB, jak je znázorněno zelenou šipkou na následujícím obrázku:
V další části budeme šifrovat replikační připojení mezi uzly.
Šifrování replikace
Nastavení šifrovaných připojení pro replikaci je podobné jako u připojení klient/server. Můžeme použít stejné klientské certifikáty, klíč a certifikát CA, abychom umožnili uživateli replikace přistupovat k hlavnímu serveru prostřednictvím šifrovacího kanálu. To nepřímo povolí šifrování mezi uzly, když podřízené IO vlákno stahuje události replikace z hlavního serveru.
Pojďme to nakonfigurovat na jednom podřízeném zařízení najednou. Pro první slave, 192.168.0.92, přidejte následující řádek do sekce [client] v konfiguračním souboru MariaDB:
[client]
ssl-ca=/etc/mysql/transit/ca.pem
ssl-cert=/etc/mysql/transit/client-cert.pem
ssl-key=/etc/mysql/transit/client-key.pemZastavit vlákno replikace na podřízeném zařízení:
(slave)MariaDB> STOP SLAVE;Na hlavním serveru změňte stávajícího uživatele replikace tak, aby se připojil pomocí SSL:
(master)MariaDB> ALTER USER [email protected] REQUIRE SSL;Na podřízeném zařízení otestujte připojení k hlavnímu serveru 192.168.0.91 pomocí příkazového řádku mysql s příznakem --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
...Ujistěte se, že se můžete bez chyby připojit k hlavnímu hostiteli. Potom na podřízeném zařízení zadejte příkaz CHANGE MASTER s parametry SSL, jak je uvedeno níže:
(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';Spusťte podřízenou replikaci:
(slave)MariaDB> START SLAVE;Ověřte, že replikace běží v pořádku se souvisejícími parametry SSL:
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
...Podřízená jednotka se nyní bezpečně replikuje z hlavní jednotky pomocí šifrování TLS.
Opakujte všechny výše uvedené kroky na zbývajícím podřízeném zařízení, 192.168.0.93. Jediný rozdíl je v příkazu alter user, který se má provést na hlavním serveru, kde se musíme změnit na jeho příslušného hostitele:
(master)MariaDB> ALTER USER [email protected] REQUIRE SSL;V tuto chvíli jsme dokončili přenosové šifrování, jak je znázorněno zelenými čarami z hlavního na podřízené v následujícím diagramu:
Šifrované připojení můžete ověřit pohledem na výstup tcpdump pro rozhraní eth1 na otroka. Následuje příklad standardní replikace bez šifrování:
(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 kernelJasně vidíme text tak, jak jej čte otrok od pána. Při šifrovaném připojení byste měli vidět nesmyslné znaky jako níže:
(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 kernelZávěr
V další části této série blogů se podíváme na dokončení našeho plně šifrovaného nastavení pomocí šifrování MariaDB v klidu. Zůstaňte naladěni!