I denne blogserie vil vi give dig en komplet gennemgang af, hvordan du konfigurerer en fuldt krypteret MariaDB-server til hvile- og transitkryptering for at sikre maksimal beskyttelse af dataene mod at blive stjålet fysisk eller under overførsel og kommunikation med andre værter. Den grundlæggende idé er, at vi skal omdanne vores "almindelige" implementering til en fuldt krypteret MariaDB-replikering, som forenklet i følgende diagram:
Vi skal konfigurere en række krypteringskomponenter:
- In-transit-kryptering, som består af:
- Klient-server-kryptering
- replikeringskryptering
- Hviletid kryptering, som består af:
- Datafilkryptering
- Binær/relælogkryptering.
Bemærk, at dette blogindlæg kun dækker kryptering under transport. Vi kommer til at dække kryptering i hvile i anden del af denne blogserie.
Denne implementeringsgennemgang antog, at vi allerede har en MariaDB-replikeringsserver, der allerede kører. Hvis du ikke har en, kan du bruge ClusterControl til at implementere en ny MariaDB-replikering inden for få minutter med færre end 5 klik. Alle servere kører på MariaDB 10.4.11 på CentOS 7-systemet.
In-Transit-kryptering
Data kan blive udsat for risici både under transport og hvile og kræver beskyttelse i begge stater. Kryptering under transport beskytter dine data, hvis kommunikation opsnappes, mens data bevæger sig mellem værter gennem netværket, enten fra dit websted og cloud-udbyderen, mellem tjenester eller mellem klienter og serveren.
For MySQL/MariaDB er data i bevægelse, når en klient opretter forbindelse til en databaseserver, eller når en slavenode replikerer data fra en masternode. MariaDB understøtter krypterede forbindelser mellem klienter og serveren ved hjælp af TLS (Transport Layer Security) protokollen. TLS omtales nogle gange som SSL (Secure Sockets Layer), men MariaDB bruger faktisk ikke SSL-protokollen til krypterede forbindelser, fordi dens kryptering er svag. Flere detaljer om dette på MariaDB-dokumentationssiden.
Klient-serverkryptering
I denne opsætning kommer vi til at bruge selvsignerede certifikater, hvilket betyder, at vi ikke bruger eksterne parter som Google, Comodo eller nogen populær Certificate Authority-udbyder derude til at bekræfte vores identitet. I SSL/TLS er identitetsbekræftelse det første trin, der skal bestå, før serveren og klienten udveksler deres certifikater og nøgler.
MySQL giver et meget praktisk værktøj kaldet mysql_ssl_rsa_setup, som tager sig af nøgle- og certifikatgenerering automatisk. Desværre er der endnu ikke et sådant værktøj til MariaDB-serveren. Derfor er vi nødt til manuelt at forberede og generere de SSL-relaterede filer til vores MariaDB TLS-behov.
Det følgende er en liste over de filer, som vi vil generere ved hjælp af OpenSSL-værktøjet:
- CA-nøgle - RSA privat nøgle i PEM-format. Skal holdes hemmeligt.
- CA-certifikat - X.509-certifikat i PEM-format. Indeholder offentlig nøgle og certifikatmetadata.
- Server CSR - Anmodning om underskrift af certifikat. Fællesnavnet (CN) når du udfylder formularen er vigtigt, for eksempel CN=mariadb-server
- Servernøgle - RSA privat nøgle. Skal holdes hemmeligt.
- Servercertifikat - X.509-certifikat underskrevet af CA-nøgle. Indeholder offentlig nøgle og certifikatmetadata.
- Kunde-CSR - Anmodning om underskrift af certifikat. Skal bruge et andet fælles navn (CN) end serverens CSR, f.eks. CN=client1
- Klientnøgle - RSA privat nøgle. Skal holdes hemmeligt.
- Kundecertifikat - X.509-certifikat underskrevet af CA-nøgle. Indeholder offentlig nøgle og certifikatmetadata.
Opret først og fremmest en mappe til at gemme vores certifikater og nøgler til kryptering under transport:
$ mkdir -p /etc/mysql/transit/
$ cd /etc/mysql/transit/Bare for at give dig en idé om, hvorfor vi navngiver mappen som nævnt, er det fordi vi i den næste del af denne blogserie vil oprette endnu en mappe til hvilende kryptering på /etc/mysql/rest.
Certifikatautoritet
Generer en nøglefil til vores egen certifikatmyndighed (CA):
$ openssl genrsa 2048 > ca-key.pem
Generating RSA private key, 2048 bit long modulus
.......................+++
...............................................................................................................................................................................................................................................+++
e is 65537 (0x10001)Generer et certifikat til vores egen certifikatmyndighed (CA) baseret på ca-key.pem genereret før med udløb på 3650 dage:
$ 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]Nu skulle vi have ca-key.pem og ca.pem under denne arbejdsmappe.
Nøgle og certifikat til server
Generer derefter privat nøgle til MariaDB-serveren:
$ openssl genrsa 2048 > server-key.pem
Generating RSA private key, 2048 bit long modulus
.............................................................................................................+++
..................................................................................................................+++
e is 65537 (0x10001)Et betroet certifikat skal være et certifikat underskrevet af en certifikatmyndighed, hvorved vi her vil bruge vores egen CA, fordi vi har tillid til værterne i netværket. Før vi kan oprette et signeret certifikat, skal vi generere et anmodningscertifikat kaldet Certificate Signing Request (CSR).
Opret en CSR til MariaDB-serveren. Vi vil kalde certifikatet som server-req.pem. Dette er ikke det certifikat, vi skal bruge til MariaDB-serveren. Det endelige certifikat er det, der vil blive underskrevet af vores egen CA private nøgle (som vist i næste trin):
$ 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 []:Bemærk det almindelige navn, hvor vi specificerede "MariaDBServer". Dette kan være et hvilket som helst navn, men værdien må ikke være den samme som klientcertifikatet. Normalt, hvis applikationerne forbinder til MariaDB-serveren via FQDN eller værtsnavn (skip-name-resolve=OFF), vil du sandsynligvis angive MariaDB-serverens FQDN som fællesnavn.
Vi kan derefter generere det endelige X.509-certifikat (server-cert.pem) og underskrive CSR (server-req.pem) med CA's certifikat (ca.pem) og CA's private nøgle (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 KeyPå dette tidspunkt er dette, hvad vi har nu:
$ ls -1 /etc/mysql/transite
ca-key.pem
ca.pem
server-cert.pem
server-key.pem
server-req.pemVi behøver kun CA-certifikatet (ca.pem), serverens signerede certifikat (server-cert.pem) og serverens private nøgle (server-key.pem) til MariaDB-serveren. CSR (server-req.pem) er ikke længere påkrævet.
Nøgle og certifikat til klienten
Derefter skal vi generere nøgle- og certifikatfiler til MariaDB-klienten. MariaDB-serveren accepterer kun fjernforbindelse fra klienten, der har disse certifikatfiler.
Start med at generere en 2048-bit nøgle til klienten:
$ openssl genrsa 2048 > client-key.pem
Generating RSA private key, 2048 bit long modulus
.............................................................................................................+++
..................................................................................................................+++
e is 65537 (0x10001)Opret CSR for klienten kaldet 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ær opmærksom på det fælles navn, hvor vi angiver "Client1". Angiv ethvert navn, der repræsenterer klienten. Denne værdi skal være forskellig fra serverens fællesnavn. Til avanceret brug kan du bruge dette fællesnavn til at tillade bestemte brugere med et certifikat, der matcher denne værdi, for eksempel:
MariaDB> GRANT SELECT ON schema1.* TO 'client1'@'192.168.0.93' IDENTIFIED BY 's' REQUIRE SUBJECT '/CN=Client2';Vi kan derefter generere det endelige X.509-certifikat (client-cert.pem) og underskrive CSR (client-req.pem) med CA's certifikat (ca.pem) og CA's private nøgle (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 KeyAlle certifikater, som vi har brug for til opsætning af kryptering under transport, genereres. Bekræft, at begge certifikater er korrekt signeret af CA:
$ openssl verify -CAfile ca.pem server-cert.pem client-cert.pem
server-cert.pem: OK
client-cert.pem: OKKonfiguration af SSL til MariaDB
Opret en ny mappe på hver slave:
(slave1)$ mkdir -p /etc/mysql/transit/
(slave2)$ mkdir -p /etc/mysql/transit/Kopiér krypteringsfilerne til alle slaver:
$ scp -r /etc/mysql/transit/* [email protected]:/etc/mysql/transit/
$ scp -r /etc/mysql/transit/* [email protected]:/etc/mysql/transit/Sørg for, at ejeren af certs-mappen til "mysql"-brugeren og ændre tilladelserne for alle nøglefiler, så den ikke kan læses globalt:
$ cd /etc/mysql/transit
$ chown -R mysql:mysql *
$ chmod 600 client-key.pem server-key.pem ca-key.pemHer er, hvad du skal se, når du viser filer under "transit"-mappen:
$ 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.pemDerefter aktiverer vi SSL-forbindelsen for MariaDB. Rediger konfigurationsfilen på hver MariaDB-vært (master og slaver) og tilføj følgende linjer under [mysqld]-sektionen:
ssl-ca=/etc/mysql/transit/ca.pem
ssl-cert=/etc/mysql/transit/server-cert.pem
ssl-key=/etc/mysql/transit/server-key.pemGenstart MariaDB-serveren én node ad gangen, startende fra slaver og til sidst på masteren:
(slave1)$ systemctl restart mariadb
(slave2)$ systemctl restart mariadb
(master)$ systemctl restart mariadbEfter genstart er MariaDB nu i stand til at acceptere almindelige forbindelser ved at oprette forbindelse til den uden nogen SSL-relaterede parametre eller med krypterede forbindelser, når du angiver SSL-relateret parameter i forbindelsesstrengen.
For ClusterControl-brugere kan du aktivere klient-server-kryptering et spørgsmål om klik. Bare gå til ClusterControl -> Sikkerhed -> SSL-kryptering -> Aktiver -> Opret certifikat -> Certifikatudløb -> Aktiver SSL:
ClusterControl vil generere de nødvendige nøgler, X.509-certifikat og CA-certifikat og opsætte SSL-kryptering for klient-server-forbindelser for alle noderne i klyngen. For MySQL/MariaDB-replikering vil SSL-filerne være placeret under /etc/ssl/replikation/cluster_X, hvor X er klynge-id'et på hver databaseknude. De samme certifikater vil blive brugt på alle noder, og de eksisterende kan blive overskrevet. Noderne skal genstartes individuelt, efter at dette job er fuldført. Vi anbefaler, at du først genstarter en replikeringsslave og kontrollerer, at SSL-indstillingerne virker.
For at genstarte hver node, gå til ClusterControl -> Noder -> Node Actions -> Genstart Node. Genstart én node ad gangen, startende med slaverne. Den sidste node skal være masterknuden med kraftstopflag aktiveret:
Du kan se, om en node er i stand til at håndtere klient-server-kryptering ved at ser på det grønne låseikon lige ved siden af databasenoden i oversigtsgitteret:
På dette tidspunkt er vores klynge nu klar til at acceptere SSL-forbindelse fra MySQL brugere.
Opretter forbindelse via krypteret forbindelse
MariaDB-klienten kræver alle klientrelaterede SSL-filer, som vi har genereret inde på serveren. Kopiér det genererede klientcertifikat, CA-certifikat og klientnøgle til klientværten:
$ cd /etc/mysql/transit
$ scp client-cert.pem client-key.pem ca.pem [email protected]:~**ClusterControl genererer klientens SSL-filer under /etc/ssl/replication/cluster_X/på hver databasenode, hvor X er klynge-id'et.
Opret en databasebruger, der kræver SSL på masteren:
MariaDB> CREATE SCHEMA sbtest;
MariaDB> CREATE USER [email protected]'%' IDENTIFIED BY 'mysecr3t' REQUIRE SSL;
MariaDB> GRANT ALL PRIVILEGES ON sbtest.* to [email protected]'%';Fra klientværten skal du oprette forbindelse til MariaDB-serveren med SSL-relaterede parametre. Vi kan verificere forbindelsesstatus ved at bruge "STATUS"-sætning:
(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ær opmærksom på SSL-linjen, hvor chifferen bruges til krypteringen. Dette betyder, at klienten er forbundet med MariaDB-serveren via krypteret forbindelse.
På dette tidspunkt har vi krypteret klient-server-forbindelsen til MariaDB-serveren, som repræsenteret af den grønne to-hovedet pil i følgende diagram:
I næste del skal vi kryptere replikeringsforbindelser mellem noder.
replikeringskryptering
Opsætning af krypterede forbindelser til replikering svarer til at gøre det for klient/serverforbindelser. Vi kan bruge de samme klientcertifikater, nøgle og CA-certifikat til at lade replikeringsbrugeren få adgang til masterens server via krypteringskanal. Dette vil indirekte aktivere kryptering mellem noder, når slave IO-tråd trækker replikeringshændelser fra masteren.
Lad os konfigurere dette på én slave ad gangen. For den første slave, 192.168.0.92, skal du tilføje følgende linje under [klient]-sektionen i MariaDB-konfigurationsfilen:
[client]
ssl-ca=/etc/mysql/transit/ca.pem
ssl-cert=/etc/mysql/transit/client-cert.pem
ssl-key=/etc/mysql/transit/client-key.pemStop replikeringstråden på slaven:
(slave)MariaDB> STOP SLAVE;På masteren skal du ændre den eksisterende replikeringsbruger for at tvinge den til at oprette forbindelse ved hjælp af SSL:
(master)MariaDB> ALTER USER [email protected] REQUIRE SSL;På slaven, test forbindelsen til masteren, 192.168.0.91 via mysql kommandolinje med --ssl flag:
(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
...Sørg for, at du kan få forbindelse til hovedværten uden fejl. Angiv derefter CHANGE MASTER-sætningen på slaven med SSL-parametre som nedenfor:
(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';Start replikeringsslaven:
(slave)MariaDB> START SLAVE;Bekræft, at replikeringen kører okay med relaterede SSL-parametre:
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
...Slaven replikerer nu fra masteren sikkert via TLS-kryptering.
Gentag alle ovenstående trin på den resterende slave, 192.168.0.93. Den eneste forskel er den ændrede brugersætning, der skal udføres på masteren, hvor vi skal skifte til dens respektive vært:
(master)MariaDB> ALTER USER [email protected] REQUIRE SSL;På dette tidspunkt har vi afsluttet in-transit kryptering som illustreret af de grønne linjer fra master til slaver i følgende diagram:
Du kan bekræfte krypteringsforbindelsen ved at se på tcpdump-outputtet for interface eth1 på slaven. Følgende er et eksempel på standardreplikering uden kryptering:
(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 kernelVi kan tydeligt se teksten læst af slaven fra mesteren. Mens du er på en krypteret forbindelse, bør du se volapyk-tegn som nedenfor:
(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 kernelKonklusion
I den næste del af denne blogserie skal vi se på at færdiggøre vores fuldt krypterede opsætning med MariaDB at-rest-kryptering. Hold dig opdateret!