MariaDB
 sql >> Database >  >> RDS >> MariaDB

Crittografia completa di MariaDB a riposo e in transito per la massima protezione dei dati - Parte prima

In questa serie di blog, ti forniremo una guida completa su come configurare un server MariaDB completamente crittografato per la crittografia a riposo e in transito, per garantire la massima protezione dei dati dall'essere rubato fisicamente o durante il trasferimento e la comunicazione con altri host. L'idea di base è trasformare la nostra distribuzione "semplice" in una replica MariaDB completamente crittografata, come semplificato nel diagramma seguente:

Stiamo per configurare una serie di componenti di crittografia:

  • Crittografia in transito, che consiste in:
    • Crittografia client-server
    • Crittografia della replica
  • Crittografia a riposo, che consiste in:
    • Crittografia dei file di dati
    • Crittografia del registro binario/relè.

Nota che questo post del blog copre solo la crittografia in transito. Tratteremo la crittografia a riposo nella seconda parte di questa serie di blog.

Questa procedura dettagliata di distribuzione presuppone che abbiamo già un server di replica MariaDB già in esecuzione. Se non ne hai uno, puoi utilizzare ClusterControl per distribuire una nuova replica MariaDB in pochi minuti, con meno di 5 clic. Tutti i server sono in esecuzione su MariaDB 10.4.11 su sistema CentOS 7.

Crittografia in transito

I dati possono essere esposti a rischi sia in transito che a riposo e richiedono protezione in entrambi gli stati. La crittografia in transito protegge i tuoi dati se le comunicazioni vengono intercettate mentre i dati si spostano tra host attraverso la rete, dal tuo sito e dal provider cloud, tra servizi o tra client e server.

Per MySQL/MariaDB, i dati sono in movimento quando un client si connette a un server di database o quando un nodo slave replica i dati da un nodo master. MariaDB supporta connessioni crittografate tra client e server utilizzando il protocollo TLS (Transport Layer Security). TLS è talvolta indicato come SSL (Secure Sockets Layer) ma MariaDB in realtà non utilizza il protocollo SSL per le connessioni crittografate perché la sua crittografia è debole. Maggiori dettagli su questo nella pagina della documentazione di MariaDB.

Crittografia client-server

In questa configurazione utilizzeremo certificati autofirmati, il che significa che non utilizziamo parti esterne come Google, Comodo o qualsiasi provider di autorità di certificazione popolare per verificare la nostra identità. In SSL/TLS, la verifica dell'identità è il primo passaggio che deve essere superato prima che il server e il client si scambino i certificati e le chiavi.

MySQL fornisce uno strumento molto utile chiamato mysql_ssl_rsa_setup che si occupa della generazione della chiave e del certificato automaticamente. Sfortunatamente, non esiste ancora uno strumento del genere per il server MariaDB. Pertanto, dobbiamo preparare e generare manualmente i file relativi a SSL per le nostre esigenze TLS di MariaDB.

Quello che segue è un elenco dei file che genereremo utilizzando lo strumento OpenSSL:

  • Chiave CA - Chiave privata RSA in formato PEM. Deve essere tenuto segreto.
  • Certificato CA - Certificato X.509 in formato PEM. Contiene la chiave pubblica e i metadati del certificato.
  • CSR del server - Richiesta di firma del certificato. Il nome comune (CN) durante la compilazione del modulo è importante, ad esempio CN=mariadb-server
  • Chiave del server - Chiave privata RSA. Deve essere tenuto segreto.
  • Certificato del server - Certificato X.509 firmato da chiave CA. Contiene la chiave pubblica e i metadati del certificato.
  • CSR del cliente - Richiesta di firma del certificato. Deve utilizzare un nome comune (CN) diverso dal CSR del server, ad esempio CN=client1 
  • Chiave client - Chiave privata RSA. Deve essere tenuto segreto.
  • Certificato cliente - Certificato X.509 firmato da chiave CA. Contiene la chiave pubblica e i metadati del certificato.

Prima di tutto, crea una directory in cui archiviare i nostri certificati e chiavi per la crittografia in transito:

$ mkdir -p /etc/mysql/transit/
$ cd /etc/mysql/transit/

Solo per darti un'idea del motivo per cui chiamiamo la directory come menzionato è perché nella parte successiva di questa serie di blog, creeremo un'altra directory per la crittografia a riposo in /etc/mysql/rest.

Autorità di certificazione

Genera un file chiave per la nostra autorità di certificazione (CA):

$ openssl genrsa 2048 > ca-key.pem
Generating RSA private key, 2048 bit long modulus
.......................+++
...............................................................................................................................................................................................................................................+++
e is 65537 (0x10001)

Genera un certificato per la nostra autorità di certificazione (CA) in base al ca-key.pem generato in precedenza con scadenza di 3650 giorni:

$ 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]

Ora dovremmo avere ca-key.pem e ca.pem in questa directory di lavoro.

Chiave e certificato per il server

Avanti, genera la chiave privata per il server MariaDB:

$ openssl genrsa 2048 > server-key.pem
Generating RSA private key, 2048 bit long modulus
.............................................................................................................+++
..................................................................................................................+++
e is 65537 (0x10001)

Un certificato attendibile deve essere un certificato firmato da un'autorità di certificazione per cui qui utilizzeremo la nostra CA perché ci fidiamo degli host nella rete. Prima di poter creare un certificato firmato, dobbiamo generare un certificato di richiesta chiamato Certificate Signing Request (CSR).

Crea una CSR per il server MariaDB. Chiameremo il certificato come server-req.pem. Questo non è il certificato che useremo per il server MariaDB. Il certificato finale è quello che verrà firmato dalla nostra chiave privata CA (come mostrato nel passaggio successivo):

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

Prendi nota del nome comune in cui abbiamo specificato "MariaDBServer". Può essere qualsiasi nome, ma il valore non deve essere lo stesso del certificato client. Comunemente, se le applicazioni si connettono al server MariaDB tramite FQDN o hostname (skip-name-resolve=OFF), probabilmente si desidera specificare l'FQDN del server MariaDB come nome comune.

Possiamo quindi generare il certificato X.509 finale (server-cert.pem) e firmare la CSR (server-req.pem) con il certificato della CA (ca.pem) e la chiave privata della 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 Key

A questo punto, questo è quello che abbiamo ora:

$ ls -1 /etc/mysql/transite
ca-key.pem
ca.pem
server-cert.pem
server-key.pem
server-req.pem

Abbiamo solo bisogno del certificato CA (ca.pem), del certificato firmato del server (server-cert.pem) e della chiave privata del server (server-key.pem) per il server MariaDB. La CSR (server-req.pem) non è più necessaria.

Chiave e certificato per il cliente

Successivamente, dobbiamo generare file di chiavi e certificati per il client MariaDB. Il server MariaDB accetterà solo la connessione remota dal client che ha questi file di certificato.

Inizia generando una chiave a 2048 bit per il client:

$ openssl genrsa 2048 > client-key.pem
Generating RSA private key, 2048 bit long modulus
.............................................................................................................+++
..................................................................................................................+++
e is 65537 (0x10001)

Crea CSR per il client chiamato 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 []:

Fai attenzione al Nome comune dove specifichiamo "Client1". Specificare qualsiasi nome che rappresenti il ​​client. Questo valore deve essere diverso dal nome comune del server. Per un utilizzo avanzato, puoi utilizzare questo nome comune per consentire a determinati utenti con certificato corrispondente a questo valore, ad esempio:

MariaDB> GRANT SELECT ON schema1.* TO 'client1'@'192.168.0.93' IDENTIFIED BY 's' REQUIRE SUBJECT '/CN=Client2';

Possiamo quindi generare il certificato X.509 finale (client-cert.pem) e firmare la CSR (client-req.pem) con il certificato della CA (ca.pem) e la chiave privata della 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 Key

Tutti i certificati necessari per l'impostazione della crittografia in transito vengono generati. Verifica che entrambi i certificati siano firmati correttamente dalla CA:

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

Configurazione SSL per MariaDB

Crea una nuova directory su ogni slave:

(slave1)$ mkdir -p /etc/mysql/transit/
(slave2)$ mkdir -p /etc/mysql/transit/

Copia i file di crittografia su tutti gli slave:

$ scp -r /etc/mysql/transit/* [email protected]:/etc/mysql/transit/
$ scp -r /etc/mysql/transit/* [email protected]:/etc/mysql/transit/

Assicurati il ​​proprietario della directory certs per l'utente "mysql" e modifica i permessi di tutti i file chiave in modo che non siano leggibili a livello globale:

$ cd /etc/mysql/transit
$ chown -R mysql:mysql *
$ chmod 600 client-key.pem server-key.pem ca-key.pem

Ecco cosa dovresti vedere quando elenchi i file nella directory "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.pem

Successivamente, abiliteremo la connessione SSL per MariaDB. Su ogni host MariaDB (master e slave) modifica il file di configurazione e aggiungi le seguenti righe nella sezione [mysqld]:

ssl-ca=/etc/mysql/transit/ca.pem
ssl-cert=/etc/mysql/transit/server-cert.pem
ssl-key=/etc/mysql/transit/server-key.pem

Riavvia il server MariaDB un nodo alla volta, partendo dagli slave e infine sul master:

(slave1)$ systemctl restart mariadb
(slave2)$ systemctl restart mariadb
(master)$ systemctl restart mariadb

Dopo il riavvio, MariaDB è ora in grado di accettare connessioni semplici collegandosi ad esso senza parametri relativi a SSL o con connessioni crittografate, quando specifichi il parametro relativo a SSL nella stringa di connessione.

Per gli utenti ClusterControl, puoi abilitare la crittografia client-server con pochi clic. Basta andare su ClusterControl -> Sicurezza -> Crittografia SSL -> Abilita -> Crea certificato -> Scadenza certificato -> Abilita SSL:

ClusterControl genererà le chiavi richieste, il certificato X.509 e il certificato CA e impostare la crittografia SSL per le connessioni client-server per tutti i nodi del cluster. Per la replica MySQL/MariaDB, i file SSL si troveranno in /etc/ssl/replication/cluster_X, dove X è l'ID del cluster su ogni nodo del database. Gli stessi certificati verranno utilizzati su tutti i nodi e quelli esistenti potrebbero essere sovrascritti. I nodi devono essere riavviati singolarmente al termine di questo lavoro. Ti consigliamo di riavviare prima uno slave di replica e di verificare che le impostazioni SSL funzionino.

Per riavviare ogni nodo, vai su ClusterControl -> Nodes -> Node Actions -> Restart Node. Riavvia un nodo alla volta, iniziando dagli slave. L'ultimo nodo dovrebbe essere il nodo master con il flag di arresto forzato abilitato:

Puoi sapere se un nodo è in grado di gestire la crittografia client-server tramite guardando l'icona del lucchetto verde proprio accanto al nodo del database nella griglia Panoramica:

A questo punto, il nostro cluster è ora pronto per accettare la connessione SSL da MySQL utenti.

Connessione tramite connessione crittografata

Il client MariaDB richiede tutti i file SSL relativi al client che abbiamo generato all'interno del server. Copia il certificato client, il certificato CA e la chiave client generati nell'host client:

$ cd /etc/mysql/transit
$ scp client-cert.pem client-key.pem ca.pem [email protected]:~

**ClusterControl genera i file SSL del client in /etc/ssl/replication/cluster_X/su ogni nodo del database, dove X è l'ID del cluster.

Crea un utente del database che richiede SSL sul master:

MariaDB> CREATE SCHEMA sbtest;
MariaDB> CREATE USER [email protected]'%' IDENTIFIED BY 'mysecr3t' REQUIRE SSL;
MariaDB> GRANT ALL PRIVILEGES ON sbtest.* to [email protected]'%';

Dall'host client, connettiti al server MariaDB con parametri relativi a SSL. Possiamo verificare lo stato della connessione utilizzando l'istruzione "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
...

Prestare attenzione alla riga SSL in cui viene utilizzata la cifratura per la crittografia. Ciò significa che il client è connesso correttamente al server MariaDB tramite connessione crittografata.

A questo punto, abbiamo crittografato la connessione client-server al server MariaDB, come rappresentato dalla freccia verde a due punte nel diagramma seguente:

Nella parte successiva crittograferemo le connessioni di replica tra i nodi.

Crittografia della replica

La configurazione di connessioni crittografate per la replica è simile a quella per le connessioni client/server. Possiamo utilizzare gli stessi certificati client, chiave e certificato CA per consentire all'utente di replica di accedere al server del master tramite il canale di crittografia. Ciò consentirà indirettamente la crittografia tra i nodi quando il thread IO slave estrae gli eventi di replica dal master.

Configuriamolo su uno slave alla volta. Per il primo slave, 192.168.0.92, aggiungi la seguente riga nella sezione [client] all'interno del file di configurazione di MariaDB:

[client]
ssl-ca=/etc/mysql/transit/ca.pem
ssl-cert=/etc/mysql/transit/client-cert.pem
ssl-key=/etc/mysql/transit/client-key.pem

Interrompi il thread di replica sullo slave:

(slave)MariaDB> STOP SLAVE;

Sul master, modifica l'utente di replica esistente per forzarne la connessione tramite SSL:

(master)MariaDB> ALTER USER [email protected] REQUIRE SSL;

Sullo slave, verifica la connettività al master, 192.168.0.91 tramite la riga di comando mysql con --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
...

Assicurati di poterti connettere all'host master senza errori. Quindi, sullo slave, specificare l'istruzione CHANGE MASTER con parametri SSL come di seguito:

(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';

Avvia lo slave di replica:

(slave)MariaDB> START SLAVE;

Verifica che la replica funzioni correttamente con i relativi parametri 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
...

Lo slave ora sta replicando dal master in modo sicuro tramite crittografia TLS.

Ripetere tutti i passaggi precedenti sullo slave rimanente, 192.168.0.93. L'unica differenza è l'istruzione alter user da eseguire sul master in cui dobbiamo passare al rispettivo host:

(master)MariaDB> ALTER USER [email protected] REQUIRE SSL;

A questo punto abbiamo completato la crittografia in transito come illustrato dalle linee verdi da master a slave nel diagramma seguente:

Puoi verificare la connessione di crittografia guardando l'output di tcpdump per l'interfaccia eth1 sullo schiavo. Quello che segue è un esempio di replica standard senza crittografia:

(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 kernel

Possiamo vedere chiaramente il testo letto dallo schiavo dal padrone. Durante una connessione crittografata, dovresti vedere caratteri senza senso come di seguito:

(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 kernel

Conclusione

Nella parte successiva di questa serie di blog, esamineremo il completamento della nostra configurazione completamente crittografata con la crittografia a riposo di MariaDB. Resta sintonizzato!