In deze blogserie geven we u een volledige uitleg over hoe u een volledig versleutelde MariaDB-server configureert voor versleuteling in rust en tijdens transport, om maximale bescherming van de gegevens te garanderen. fysiek gestolen of tijdens het overbrengen en communiceren met andere hosts. Het basisidee is dat we onze "gewone" implementatie gaan omzetten in een volledig versleutelde MariaDB-replicatie, zoals vereenvoudigd in het volgende diagram:
We gaan een aantal coderingscomponenten configureren:
- Encryptie tijdens het transport, die bestaat uit:
- Client-server-encryptie
- Replicatie-encryptie
- At-rest-codering, die bestaat uit:
- Encryptie van gegevensbestanden
- Binaire/relay log-encryptie.
Houd er rekening mee dat dit blogbericht alleen over codering tijdens het transport gaat. In het tweede deel van deze blogreeks gaan we de versleuteling in rust behandelen.
Bij deze implementatie-walkthrough werd aangenomen dat we al een MariaDB-replicatieserver hadden die al actief was. Als je er geen hebt, kun je ClusterControl gebruiken om binnen enkele minuten en met minder dan 5 klikken een nieuwe MariaDB-replicatie te implementeren. Alle servers draaien op MariaDB 10.4.11 op het CentOS 7-systeem.
Encryptie tijdens transport
Gegevens kunnen zowel tijdens transport als in rust worden blootgesteld aan risico's en moeten in beide staten worden beschermd. In-transit-codering beschermt uw gegevens als communicatie wordt onderschept terwijl gegevens tussen hosts via het netwerk worden verplaatst, hetzij van uw site en de cloudprovider, tussen services of tussen clients en de server.
Voor MySQL/MariaDB zijn gegevens in beweging wanneer een client verbinding maakt met een databaseserver of wanneer een slave-knooppunt gegevens van een masterknooppunt repliceert. MariaDB ondersteunt versleutelde verbindingen tussen clients en de server met behulp van het TLS-protocol (Transport Layer Security). TLS wordt soms SSL (Secure Sockets Layer) genoemd, maar MariaDB gebruikt het SSL-protocol niet echt voor versleutelde verbindingen omdat de versleuteling zwak is. Meer details hierover op de MariaDB-documentatiepagina.
Client-Server Encryptie
In deze opzet gaan we zelfondertekende certificaten gebruiken, wat betekent dat we geen externe partijen zoals Google, Comodo of een andere populaire certificeringsinstantie gebruiken om onze identiteit te verifiëren. Bij SSL/TLS is identiteitsverificatie de eerste stap die moet worden doorlopen voordat de server en de client hun certificaten en sleutels uitwisselen.
MySQL biedt een zeer handige tool genaamd mysql_ssl_rsa_setup die automatisch zorgt voor het genereren van sleutels en certificaten. Helaas is er nog geen dergelijke tool voor de MariaDB-server. Daarom moeten we de SSL-gerelateerde bestanden handmatig voorbereiden en genereren voor onze MariaDB TLS-behoeften.
Het volgende is een lijst van de bestanden die we zullen genereren met de OpenSSL-tool:
- CA-sleutel - RSA-privésleutel in PEM-indeling. Moet geheim worden gehouden.
- CA-certificaat - X.509-certificaat in PEM-formaat. Bevat openbare sleutel en metadata van certificaten.
- Server CSR - Certificaat ondertekening verzoek. De Common Name (CN) bij het invullen van het formulier is belangrijk, bijvoorbeeld CN=mariadb-server
- Serversleutel - RSA-privésleutel. Moet geheim worden gehouden.
- Servercertificaat - X.509-certificaat ondertekend met CA-sleutel. Bevat openbare sleutel en metadata van certificaten.
- Klant CSR - Certificaat ondertekening verzoek. Moet een andere algemene naam (CN) gebruiken dan de CSR van de server, bijvoorbeeld CN=client1
- Cliëntsleutel - RSA-privésleutel. Moet geheim worden gehouden.
- Cliëntcertificaat - X.509-certificaat ondertekend met CA-sleutel. Bevat openbare sleutel en metadata van certificaten.
Maak eerst en vooral een map om onze certificaten en sleutels op te slaan voor codering tijdens het transport:
$ mkdir -p /etc/mysql/transit/
$ cd /etc/mysql/transit/Om je een idee te geven waarom we de directory een naam geven zoals vermeld, is dat we in het volgende deel van deze blogreeks een andere directory voor at-rest-codering zullen maken op /etc/mysql/rest.
Certificaatautoriteit
Genereer een sleutelbestand voor onze eigen certificeringsinstantie (CA):
$ openssl genrsa 2048 > ca-key.pem
Generating RSA private key, 2048 bit long modulus
.......................+++
...............................................................................................................................................................................................................................................+++
e is 65537 (0x10001)Genereer een certificaat voor onze eigen certificeringsinstantie (CA) op basis van de ca-key.pem die eerder is gegenereerd met een vervaldatum van 3650 dagen:
$ 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 zouden we ca-key.pem en ca.pem onder deze werkdirectory moeten hebben.
Sleutel en certificaat voor server
Genereer vervolgens de persoonlijke sleutel voor de MariaDB-server:
$ openssl genrsa 2048 > server-key.pem
Generating RSA private key, 2048 bit long modulus
.............................................................................................................+++
..................................................................................................................+++
e is 65537 (0x10001)Een vertrouwd certificaat moet een certificaat zijn dat is ondertekend door een certificeringsinstantie waarbij we hier onze eigen CA gaan gebruiken omdat we de hosts in het netwerk vertrouwen. Voordat we een ondertekend certificaat kunnen maken, moeten we een aanvraagcertificaat genereren met de naam Certificate Signing Request (CSR).
Maak een CSR voor MariaDB-server. We gaan het certificaat aanroepen als server-req.pem. Dit is niet het certificaat dat we gaan gebruiken voor de MariaDB-server. Het uiteindelijke certificaat is het certificaat dat wordt ondertekend door onze eigen CA-privésleutel (zoals weergegeven in de volgende stap):
$ 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 []:Let op de algemene naam waar we "MariaDBServer" hebben opgegeven. Dit kan elke naam zijn, maar de waarde mag niet hetzelfde zijn als het clientcertificaat. Gewoonlijk, als de toepassingen verbinding maken met de MariaDB-server via FQDN of hostnaam (skip-name-resolve=OFF), wilt u waarschijnlijk de FQDN van de MariaDB-server specificeren als de algemene naam.
We kunnen dan het definitieve X.509-certificaat (server-cert.pem) genereren en de CSR (server-req.pem) ondertekenen met het CA-certificaat (ca.pem) en de privésleutel van CA (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 KeyOp dit moment hebben we dit:
$ ls -1 /etc/mysql/transite
ca-key.pem
ca.pem
server-cert.pem
server-key.pem
server-req.pemWe hebben alleen het CA-certificaat (ca.pem), het ondertekende certificaat van de server (server-cert.pem) en de privésleutel van de server (server-key.pem) nodig voor de MariaDB-server. De CSR (server-req.pem) is niet langer vereist.
Sleutel en certificaat voor de klant
Vervolgens moeten we sleutel- en certificaatbestanden genereren voor de MariaDB-client. De MariaDB-server accepteert alleen externe verbindingen van de client die deze certificaatbestanden heeft.
Begin met het genereren van een 2048-bits sleutel voor de client:
$ openssl genrsa 2048 > client-key.pem
Generating RSA private key, 2048 bit long modulus
.............................................................................................................+++
..................................................................................................................+++
e is 65537 (0x10001)CSR maken voor de klant met de naam 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 []:Let op de algemene naam waar we "Client1" specificeren. Geef een naam op die de klant vertegenwoordigt. Deze waarde moet verschillen van de algemene naam van de server. Voor geavanceerd gebruik kunt u deze algemene naam gebruiken om bepaalde gebruikers toe te staan met een certificaat dat overeenkomt met deze waarde, bijvoorbeeld:
MariaDB> GRANT SELECT ON schema1.* TO 'client1'@'192.168.0.93' IDENTIFIED BY 's' REQUIRE SUBJECT '/CN=Client2';We kunnen dan het definitieve X.509-certificaat (client-cert.pem) genereren en de CSR (client-req.pem) ondertekenen met het CA-certificaat (ca.pem) en de privésleutel van CA (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 certificaten die we nodig hebben voor het instellen van encryptie tijdens het transport worden gegenereerd. Controleer of beide certificaten correct zijn ondertekend door de CA:
$ openssl verify -CAfile ca.pem server-cert.pem client-cert.pem
server-cert.pem: OK
client-cert.pem: OKSSL configureren voor MariaDB
Maak een nieuwe map aan op elke slave:
(slave1)$ mkdir -p /etc/mysql/transit/
(slave2)$ mkdir -p /etc/mysql/transit/Kopieer de versleutelingsbestanden naar alle slaves:
$ scp -r /etc/mysql/transit/* [email protected]:/etc/mysql/transit/
$ scp -r /etc/mysql/transit/* [email protected]:/etc/mysql/transit/Zorg ervoor dat de eigenaar van de certs-map de "mysql"-gebruiker is en wijzig de machtigingen van alle sleutelbestanden zodat deze niet algemeen leesbaar zijn:
$ cd /etc/mysql/transit
$ chown -R mysql:mysql *
$ chmod 600 client-key.pem server-key.pem ca-key.pemDit is wat u zou moeten zien als u bestanden in de map "transit" opsomt:
$ 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.pemVervolgens zullen we de SSL-verbinding voor MariaDB inschakelen. Bewerk op elke MariaDB-host (master en slaves) het configuratiebestand en voeg de volgende regels toe onder de sectie [mysqld]:
ssl-ca=/etc/mysql/transit/ca.pem
ssl-cert=/etc/mysql/transit/server-cert.pem
ssl-key=/etc/mysql/transit/server-key.pemHerstart MariaDB-server één knooppunt tegelijk, beginnend bij slaves en uiteindelijk op de master:
(slave1)$ systemctl restart mariadb
(slave2)$ systemctl restart mariadb
(master)$ systemctl restart mariadbNa opnieuw opstarten kan MariaDB nu gewone verbindingen accepteren door er verbinding mee te maken zonder SSL-gerelateerde parameters of met versleutelde verbindingen, wanneer u een SSL-gerelateerde parameter opgeeft in de verbindingsreeks.
Voor ClusterControl-gebruikers kunt u met een paar klikken client-server-codering inschakelen. Ga gewoon naar ClusterControl -> Beveiliging -> SSL-codering -> Inschakelen -> Certificaat maken -> Certificaatvervaldatum -> SSL inschakelen:
ClusterControl genereert de vereiste sleutels, het X.509-certificaat en CA-certificaat en SSL-codering instellen voor client-serververbindingen voor alle knooppunten in het cluster. Voor MySQL/MariaDB-replicatie bevinden de SSL-bestanden zich onder /etc/ssl/replication/cluster_X, waarbij X de cluster-ID is op elk databaseknooppunt. Op alle knooppunten worden dezelfde certificaten gebruikt en de bestaande kunnen worden overschreven. De knoop punten moeten afzonderlijk opnieuw worden gestart nadat deze taak is voltooid. We raden u aan eerst een replicatieslave opnieuw op te starten en te controleren of de SSL-instellingen werken.
Als u elk knooppunt opnieuw wilt opstarten, gaat u naar ClusterControl -> Knooppunten -> Knooppuntacties -> Knooppunt opnieuw opstarten. Herstart één node tegelijk, te beginnen met de slaves. Het laatste knooppunt moet het hoofdknooppunt zijn met de geforceerde stopvlag ingeschakeld:
U kunt zien of een knooppunt client-server-codering kan verwerken door kijkend naar het groene slotje naast het databaseknooppunt in het overzichtsraster:
Op dit punt is ons cluster nu klaar om een SSL-verbinding van MySQL te accepteren gebruikers.
Verbinding maken via versleutelde verbinding
De MariaDB-client vereist alle client-gerelateerde SSL-bestanden die we binnen de server hebben gegenereerd. Kopieer het gegenereerde clientcertificaat, CA-certificaat en clientsleutel naar de clienthost:
$ cd /etc/mysql/transit
$ scp client-cert.pem client-key.pem ca.pem [email protected]:~**ClusterControl genereert de client-SSL-bestanden onder /etc/ssl/replication/cluster_X/op elk databaseknooppunt, waarbij X de cluster-ID is.
Maak een databasegebruiker aan die SSL vereist op de master:
MariaDB> CREATE SCHEMA sbtest;
MariaDB> CREATE USER [email protected]'%' IDENTIFIED BY 'mysecr3t' REQUIRE SSL;
MariaDB> GRANT ALL PRIVILEGES ON sbtest.* to [email protected]'%';Maak vanaf de client-host verbinding met de MariaDB-server met SSL-gerelateerde parameters. We kunnen de verbindingsstatus verifiëren met behulp van de "STATUS"-verklaring:
(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
...Let op de SSL-regel waar de cipher wordt gebruikt voor de codering. Dit betekent dat de client succesvol is verbonden met de MariaDB-server via een versleutelde verbinding.
Op dit moment hebben we de client-serververbinding met de MariaDB-server versleuteld, zoals weergegeven door de groene tweekoppige pijl in het volgende diagram:
In het volgende deel gaan we replicatieverbindingen tussen knooppunten versleutelen.
Replicatiecodering
Het instellen van versleutelde verbindingen voor replicatie is vergelijkbaar met dit voor client/server-verbindingen. We kunnen dezelfde clientcertificaten, sleutel en CA-certificaat gebruiken om de replicatiegebruiker toegang te geven tot de masterserver via een coderingskanaal. Dit zal indirect codering tussen knooppunten mogelijk maken wanneer de slave-IO-thread replicatiegebeurtenissen van de master haalt.
Laten we dit op één slave tegelijk configureren. Voeg voor de eerste slave, 192.168.0.92, de volgende regel toe onder het gedeelte [client] in het MariaDB-configuratiebestand:
[client]
ssl-ca=/etc/mysql/transit/ca.pem
ssl-cert=/etc/mysql/transit/client-cert.pem
ssl-key=/etc/mysql/transit/client-key.pemStop de replicatiethread op de slave:
(slave)MariaDB> STOP SLAVE;Wijzig op de master de bestaande replicatiegebruiker om deze te dwingen verbinding te maken via SSL:
(master)MariaDB> ALTER USER [email protected] REQUIRE SSL;Test op de slave de connectiviteit met de master, 192.168.0.91 via de mysql-opdrachtregel met --ssl-vlag:
(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
...Zorg ervoor dat je zonder fouten verbinding kunt maken met de masterhost. Specificeer vervolgens op de slave de CHANGE MASTER-instructie met SSL-parameters zoals hieronder:
(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 de replicatieslave:
(slave)MariaDB> START SLAVE;Controleer of de replicatie goed werkt met gerelateerde SSL-parameters:
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
...De slave repliceert nu veilig vanaf de master via TLS-codering.
Herhaal alle bovenstaande stappen op de resterende slave, 192.168.0.93. Het enige verschil is het alter user statement dat moet worden uitgevoerd op de master waar we moeten veranderen naar de respectievelijke host:
(master)MariaDB> ALTER USER [email protected] REQUIRE SSL;Op dit punt hebben we de codering tijdens het transport voltooid, zoals geïllustreerd door de groene lijnen van master naar slaves in het volgende diagram:
U kunt de versleutelingsverbinding controleren door naar de tcpdump-uitvoer voor interface eth1 te kijken op de slaaf. Het volgende is een voorbeeld van standaardreplicatie zonder codering:
(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 kernelWe kunnen duidelijk de tekst zien zoals gelezen door de slaaf van de meester. Tijdens een versleutelde verbinding zou u wartaal moeten zien, zoals hieronder:
(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 kernelConclusie
In het volgende deel van deze blogserie gaan we kijken naar het voltooien van onze volledig versleutelde installatie met MariaDB-versleuteling in rust. Blijf op de hoogte!