La crittografia del database MariaDB, sia in transito che a riposo, è una delle cose più importanti che un'organizzazione dovrebbe considerare se dai valore ai tuoi dati.
Le organizzazioni che si occupano di transazioni finanziarie, cartelle cliniche, informazioni riservate o anche dati personali devono richiedere questo tipo di protezione dei dati. Fondamentalmente, la crittografia del database trasformerà i tuoi dati leggibili in un formato illeggibile (o almeno difficile da decifrare) da qualsiasi utente non autorizzato.
La crittografia dei dati impedisce l'uso improprio o l'intento dannoso da parte di hacker o personale non autorizzato che potrebbero danneggiare la tua attività. I dati non crittografati sono inclini agli attacchi degli hacker che iniettano dati dannosi che potrebbero danneggiare la tua infrastruttura o rubare informazioni. Quartz ha recentemente pubblicato un articolo sulla più grande violazione avvenuta in questo senso ed è allarmante che i dati siano stati rubati da miliardi di account negli ultimi due decenni.
Risorse correlate Come crittografare i backup MySQL e MariaDB Sicurezza del database - Crittografia dei backup in transito e a riposo Aggiornato:diventa un DBA ClusterControl - Gestione delle chiavi SSL e crittografia dei dati MySQL in transitoIn questo blog, discuteremo vari modi per crittografare i tuoi dati MariaDB indipendentemente dal fatto che siano a riposo o in transito. Ti forniremo una conoscenza di base della crittografia e di come utilizzarla in modo che tu possa utilizzare questi approcci per proteggere i tuoi dati.
Crittografia dei dati MariaDB:in transito
MariaDB, per impostazione predefinita, non utilizza la crittografia durante la trasmissione dei dati sulla rete dal server al client. Tuttavia, l'utilizzo della configurazione predefinita potrebbe indurre un potenziale hacker a intercettare un canale non protetto/non crittografato. Se si opera in un ambiente isolato o altamente sicuro, questo stato predefinito potrebbe essere accettabile. Questo, tuttavia, non è l'ideale quando il client e la rete si trovano su una rete diversa poiché configura il database per un potenziale attacco "man-in-the-middle".
Per evitare questi attacchi, MariaDB consente di crittografare i dati in transito tra il server e i client utilizzando il protocollo Transport Layer Security (TLS) (precedentemente noto come Secure Socket Layer o SSL). Per iniziare, devi assicurarti che il tuo server MariaDB sia stato compilato con il supporto TLS. Puoi verificarlo eseguendo l'istruzione SHOW GLOBAL VARIABLES come mostrato di seguito:
MariaDB [(none)]> SHOW GLOBAL VARIABLES LIKE 'version_ssl_library';
+---------------------+---------------------------------+
| Variable_name | Value |
+---------------------+---------------------------------+
| version_ssl_library | OpenSSL 1.0.1e-fips 11 Feb 2013 |
+---------------------+---------------------------------+
1 row in set (0.001 sec)Potresti essere confuso nel modo in cui SSL e TSL differiscono. La documentazione può utilizzare il termine SSL e le variabili per la configurazione utilizzano anche ssl_* come prefisso, tuttavia, MariaDB supporta solo i suoi successori sicuri e non più le versioni SSL precedenti. Potrebbe essere necessario identificare e utilizzare le versioni corrette di MariaDB che richiedono il giusto supporto delle versioni TLS che è necessario utilizzare. Ad esempio, PCI DSS v3.2 consiglia di utilizzare una versione minima del protocollo di TLSv1.2 supportata dalle vecchie versioni di MariaDB. Tuttavia, con TLS 1.3, richiede OpenSSL 1.1.1, è più veloce grazie a un handshake più efficiente tra i due sistemi che comunicano e questo è supportato da MariaDB 10.2.16 e MariaDB 10.3.8.
Per utilizzare i codici disponibili per una specifica versione di TLS, puoi definirla utilizzando il --ssl-cipher in mysqld comando o cifra SSL variabile nel file di configurazione. Tieni presente che le crittografie TLSv1.3 non possono essere escluse quando si utilizza OpenSSL, anche utilizzando la variabile di sistema ssl_cipher.
Parametri di configurazione per crittografare i dati in transito
Per crittografare i tuoi dati in transito, puoi eseguire la sequenza di comandi elencata di seguito:
Genera un certificato CA
openssl genrsa 2048 > ca-key.pem
openssl req -new -x509 -nodes -days 365000 -subj "/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=CA Server" -key ca-key.pem -out ca-cert.pemGenera un certificato server
openssl req -newkey rsa:2048 -days 365000 -nodes -keyout server-key.pem -out server-req.pem -subj "/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=DB Server"
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.pemGenera un certificato cliente
openssl req -newkey rsa:2048 -days 365000 -nodes -keyout client-key.pem -out client-req.pem -subj "/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=Client Server"
openssl rsa -in client-key.pem -out client-key.pem
openssl x509 -req -in client-req.pem -days 365000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.pemPrendi nota che il tuo nome comune (CN) nella -subj l'argomento deve essere univoco rispetto ai certificati CA, server e client che stai generando. Tecnicamente, CA e Server possono avere lo stesso CN, ma è meglio renderlo un identificatore univoco per questi tre. In caso contrario, riceverai un errore come tale:
ERROR 2026 (HY000): SSL connection error: tlsv1 alert unknown caVa bene, certificati e chiavi sono a posto. È necessario specificare il percorso utilizzando le variabili ssl_* nel file di configurazione di MySQL (ad es. /etc/my.cnf per il sistema operativo basato su RHEL o /etc/mysql/my.cnf per il sistema operativo Debian/Ubuntu). Vedi la configurazione di esempio di seguito:
[msqld]
...
ssl_ca=/etc/ssl/galera/self-gen/ca-cert.pem
ssl_cert=/etc/ssl/galera/self-gen/server-cert.pem
ssl_key=/etc/ssl/galera/self-gen/server-key.pemOvviamente, devi specificare il percorso corretto in cui hai inserito il certificato e le chiavi.
Quindi inserisci questi parametri in [client-mariadb] sezione del tuo file di configurazione come tale di seguito:
[client-mariadb]
ssl_ca = /etc/ssl/galera/self-gen/ca-cert.pem
ssl_cert=/etc/ssl/galera/self-gen/client-cert.pem
ssl_key=/etc/ssl/galera/self-gen/client-key.pemCome accennato in precedenza, puoi specificare quale tipo di crittografia può utilizzare la tua configurazione SSL/TLS. Questo può essere fatto specificando l'impostazione di configurazione di seguito:
[mysqld]
…
ssl_ca=/etc/ssl/galera/self-gen/ca-cert.pem
ssl_cert=/etc/ssl/galera/self-gen/server-cert.pem
ssl_key=/etc/ssl/galera/self-gen/server-key.pem
ssl-cipher=AES256-GCM-SHA384Oppure puoi utilizzare la seguente configurazione come tale di seguito:
ssl-cipher=TLSv1.2 ### This will use all Ciphers available in TLS v1.2
ssl-cipher=HIGH:!DSS:!RCA-SHA:!DES-CBC3-SHA:[email protected] ### Will list strong ciphers available and exclude ciphers in prefix.L'ultima riga indica l'equivalente di questo comando:
openssl ciphers -v 'HIGH:!DSS:!RCA-SHA:!DES-CBC3-SHA:[email protected]'Ciò escluderà le crittografie deboli e quelle che si trovano nella forma del prefisso come DHE-DSS-AES256-GCM-SHA384 cifrario per esempio.
Generazione del tuo certificato utilizzando ClusterControl
In alternativa, puoi utilizzare ClusterControl per generare i certificati e le chiavi per te. Per fare ciò, puoi fare quanto segue come mostrato di seguito:
- Seleziona il cluster MariaDB, quindi vai a Sicurezza scheda e seleziona Crittografia SSL. Nel mio esempio qui sotto, questo è un cluster MariaDB Galera:
- Seleziona la crittografia SSL e abilitala. Potrai creare un nuovo certificato o sceglierne uno esistente. Per questo esempio, sceglierò l'opzione "Crea certificato":
- L'ultimo passaggio consiste nel configurare i giorni di scadenza del tuo certificato. Vedi sotto:
Se si fa clic su "Riavvia nodi", ClusterControl eseguirà un riavvio in sequenza. Prendi nota, se stai usando MariaDB 10.4 (che è attualmente nella sua versione RC) puoi usare SSL senza riavviare il tuo server MariaDB. Basta usare il comando FLUSH SSL che è una nuova funzionalità aggiunta nella versione 10.4 di MariaDB.
Un altro modo per gestire i tuoi certificati/chiavi TLS/SSL, puoi anche utilizzare la Gestione chiavi sotto ClusterControl. Dai un'occhiata a questo blog per saperne di più su come farlo.
Crea il tuo utente MariaDB TLS/SSL
Nel caso pensassi di aver finito, non lo sei. È necessario assicurarsi che gli utenti debbano utilizzare SSL quando si connettono al server. A questo utente sarà richiesto di interagire sempre con il server attraverso un canale privato. Questo è molto importante perché devi assicurarti che tutti i tuoi clienti interagiscano con il tuo server in modo molto sicuro e privato.
Per fare ciò, basta fare il seguente esempio:
MariaDB [(none)]> CREATE USER [email protected]'192.168.10.200' IDENTIFIED BY '[email protected]';
Query OK, 0 rows affected (0.005 sec)MariaDB [(none)]> GRANT ALL ON *.* TO [email protected]'192.168.10.200' REQUIRE SSL;
Query OK, 0 rows affected (0.005 sec)Assicurati che al momento della connessione al tuo client/host dell'applicazione, copi il certificato che hai generato in base ai passaggi precedenti.
Verifica della tua connessione
Testare la tua connessione se è crittografata o meno è molto importante per determinarne lo stato. Per farlo, puoi eseguire il seguente comando di seguito:
mysql -e "status"|grep -i 'cipher'
SSL: Cipher in use is DHE-RSA-AES256-GCM-SHA384In alternativa, OpenSSL versione 1.1.1 ha aggiunto il supporto per -starttls mysql . È disponibile un binario openssl compilato staticamente che puoi ottenere qui https://testssl.sh/openssl-1.0.2k-dev-chacha.pm.ipv6.Linux+FreeBSD.tar.gz (o dai un'occhiata a questa presentazione in formato PDF) . Quindi puoi eseguire il seguente comando di seguito:
echo | bin/openssl.Linux.x86_64.static s_client -starttls mysql -connect localhost:3306 -CAfile /etc/ssl/galera/self-gen/ca-cert.pemIl risultato dell'esempio sarebbe il seguente:
$ echo | bin/openssl.Linux.x86_64.static s_client -starttls mysql -connect localhost:3306 -CAfile /etc/ssl/galera/self-gen/ca-cert.pem
CONNECTED(00000003)
depth=1 C = PH, ST = Davao Del Sur, L = Davao City, O = Maximus Aleksandre, CN = CA Server
verify return:1
depth=0 C = PH, ST = Davao Del Sur, L = Davao City, O = Maximus Aleksandre, CN = DB Server
verify return:1
---
Certificate chain
0 s:/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=DB Server
i:/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=CA Server
1 s:/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=CA Server
i:/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=CA Server
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDTDCCAjQCAQEwDQYJKoZIhvcNAQELBQAwazELMAkGA1UEBhMCUEgxFjAUBgNV
BAgMDURhdmFvIERlbCBTdXIxEzARBgNVBAcMCkRhdmFvIENpdHkxGzAZBgNVBAoM
Ek1heGltdXMgQWxla3NhbmRyZTESMBAGA1UEAwwJQ0EgU2VydmVyMCAXDTE5MDYx
MDAyMTMwNFoYDzMwMTgxMDExMDIxMzA0WjBrMQswCQYDVQQGEwJQSDEWMBQGA1UE
CAwNRGF2YW8gRGVsIFN1cjETMBEGA1UEBwwKRGF2YW8gQ2l0eTEbMBkGA1UECgwS
TWF4aW11cyBBbGVrc2FuZHJlMRIwEAYDVQQDDAlEQiBTZXJ2ZXIwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDNwFuoqJg8YlrDinxDZN4+JjFUTGlDfhmy
9H/1C4fZToegvd3RzU9mz3/Fgyuoez4szHDgkn7o4rqmKAH6tMm9R44qtBNGlxka
fn12PPXudDvij4A9C3nVatBJJXTSvSD4/eySY33kAS1DpKsgsTgKAKOsyadcvXYU
IP5nfFc7pxX/8qZADVmyeik4M+oLxO6ryurt0wmUhOmlz5zQghh9kFZLA49l+p95
m5D53d/O+Qj4HSb2ssZD2ZaRc2k4dMCVpa87xUbdP/VVLeu0J4BE3OJiwC0N1Jfi
ZpP2DOKljsklaAYQF+tPnWi5pgReEd47/ql0fNEjeheF/MJiJM1NAgMBAAEwDQYJ
KoZIhvcNAQELBQADggEBAAz7yB+UdNYJ1O5zJI4Eb9lL+vNVKhRJ8IfNrwKVbpAT
eQk9Xpn9bidfcd2gseqDTyixZhWjsjO2LXix7jRhH1DrJvhGQ7+1w36ujtzscTgy
ydLH90CnE/oZHArbBhmyuqmu041w5rB3PpI9i9SveezDrbVcaL+qeGo8s4ATB2Yr
Y3T3OTqw6o/7cTJJ8S1aXBLTyUq5HAtOTM2GGZMSYwVqUsmBHA3d7M8i7yp20RVH
78j1H6+/hSSY4SDhwr04pSkzmm6HTIBCgOYrmEV2sQ/YeMHqVrSplLRY3SZHvqHo
gbSnasOQAE1oJnSNyxt9CRRAghM/EHEnsA2OlFa9iXQ=
-----END CERTIFICATE-----
subject=/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=DB Server
issuer=/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=CA Server
---
No client certificate CA names sent
Client Certificate Types: RSA fixed DH, DSS fixed DH, RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Peer signing digest: SHA512
Server Temp Key: DH, 2048 bits
---
SSL handshake has read 3036 bytes and written 756 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : DHE-RSA-AES256-GCM-SHA384
Session-ID: 46E0F6FA42779DB210B4DF921A68E9E4CC39ADD87D28118DB0073726B98C0786
Session-ID-ctx:
Master-Key: 2A2E6137929E733051BE060953049A0553F49C2F50A183EEC0C40F7EFB4E2749E611DF54A88417518A274EC904FB3CE6
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 4a dd f3 7f 1e b7 9e cb-77 58 b9 75 53 34 5c 61 J.......wX.uS4\a
0010 - 3a 4d 0e aa e2 6b 27 8e-11 ff be 24 ad 66 88 49 :M...k'....$.f.I
0020 - c1 ba 20 20 d8 9f d5 5c-23 9d 64 dc 97 f2 fa 77 .. ...\#.d....w
0030 - bf e6 26 1f 2c 98 ee 3b-71 66 0c 04 05 3e 54 c1 ..&.,..;qf...>T.
0040 - 88 b6 f7 a9 fd b8 f9 84-cd b8 99 9f 6e 50 3b 13 ............nP;.
0050 - 90 30 91 7d 48 ea 11 f7-3f b7 6b 65 2e ea 7e 61 .0.}H...?.ke..~a
0060 - 70 cd 4e b8 43 54 3d a0-aa dc e5 44 a7 41 3a 5e p.N.CT=....D.A:^
0070 - 3e cb 45 57 33 2b a4 8f-75 d8 ce a5 9e 00 16 50 >.EW3+..u......P
0080 - 24 aa 7a 54 f8 26 65 74-11 d7 f3 d6 66 3b 14 60 $.zT.&et....f;.`
0090 - 33 98 4a ef e2 17 ba 33-4e 7f 2b ce 46 d7 e9 11 3.J....3N.+.F...
Start Time: 1560133350
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
DONECrittografia dei dati MariaDB:a riposo
I dati crittografati archiviati fisicamente all'interno dell'archiviazione hardware (cioè a riposo) offrono maggiore stabilità e protezione contro una violazione dei dati. Se un utente malintenzionato può accedere al tuo database MariaDB, può leggere i dati in testo normale. Simile all'utilizzo di un comando strings in Linux, saresti in grado di recuperare facilmente i dati dal database. Inoltre, aggiunge più pericolo se l'attaccante ha una conoscenza avanzata del formato del file del tablespace.
La crittografia a riposo è una protezione aggiuntiva, ma non sostituisce un buon firewall, password complesse, autorizzazioni utente corrette e crittografia in transito tra client e server.
Il supporto di MariaDB per la crittografia su tabelle e tablespace è stato aggiunto nella versione 10.1.3. Con le tue tabelle crittografate, i tuoi dati sono quasi impossibili da rubare per qualcuno. Questo tipo di crittografia consente inoltre alla tua organizzazione di essere conforme alle normative governative come GPDR.,
Dopo aver abilitato la crittografia dei dati inattivi in MariaDB, le tabelle definite con ENCRYPTED=YES o con innodb_encrypt_tables=ON, avranno i dati archiviati crittografati. Viene decifrato solo quando si accede tramite il database di MariaDB, altrimenti i dati sono illeggibili.
Ad esempio, leggendo un dato non crittografato, ti mostrerà come tale:
$ strings admin_logs.ibd|head -10
=r7N
infimum
supremum
infimum
supremum/
failThe verification code you entered is incorrect.KK
elmo1234failThe password or username you entered is invalidKK
elmo1234failThe password or username you entered is invalidKK
elmoasfdfailThe verification code you entered is incorrect.KK
safasffailThe verification code you entered is incorrect.KKma con dati crittografati, il tuo tablespace non sarà leggibile proprio come nell'esempio seguente:
# strings user_logs.ibd |head -10
E?*Pa
[+YQ
KNmbUtQ
T_lPAW
\GbQ.
] e2
#Rsd
ywY%o
kdUY
{]~GEÈ anche interessante notare che la crittografia Data-At-Rest di MariaDB aggiunge un sovraccarico delle dimensioni dei dati di circa il 3-5%. La crittografia MariaDB è completamente supportata anche quando si utilizzano i motori di archiviazione XtraDB e InnoDB. La crittografia è supportata anche per il motore di archiviazione Aria, ma solo per le tabelle create con ROW_FORMAT=PAGE (impostazione predefinita) e per il log binario (log di replica). MariaDB consente anche all'utente in modo flessibile cosa crittografare. In XtraDB o InnoDB, si può scegliere di crittografare:
- tutto — tutti i tablespace (con tutte le tabelle)
- tabelle individuali
- tutto, esclusi i singoli tavoli
Inoltre, è possibile scegliere di crittografare i file di registro XtraDB/InnoDB (consigliato).
MariaDB ha i suoi limiti. Galera Cluster gcache, ad esempio, non è crittografato ma è pianificato come parte della versione MariaDB 10.4. Puoi trovare un elenco completo delle limitazioni qui.
Come configurare e configurare MariaDB per la crittografia dei dati a riposo
- Genera una chiave di crittografia casuale utilizzando il comando openssl rand.
Ora, apri e modifica il file /etc/mysql/encryption/keyfile e aggiungi gli ID chiave a cui farà riferimento durante la creazione di tabelle crittografate poiché è l'id della chiave di crittografia. Vedi ENCRYPTION_KEY_ID per maggiori dettagli. Pertanto, il seguente formato dovrebbe essere il seguente:$ mkdir -p /etc/mysql/encryption $ for i in {1..5}; do openssl rand -hex 32 >> /etc/mysql/encryption/keyfile; done;
In my example keyfile, this looks as the following:<encryption_key_id1>;<hex-encoded_encryption_key1> <encryption_key_id2>;<hex-encoded_encryption_key2>$ cat keyfile 1;687a90b4423c10417f2483726a5901007571c16331d2ee9534333fef4e323075 2;e7bf20f1cbde9632587c2996871cff74871890d19b49e273d13def123d781e17 3;9284c9c80da9a323b3ac2c82427942dfbf1718b57255cc0bc0e2c3d6f15ac3ac 4;abf80c3a8b10643ef53a43c759227304bcffa263700a94a996810b0f0459a580 5;bdbc5f67d34a4904c4adc9771420ac2ab2bd9c6af1ec532e960335e831f02933 - Creiamo o generiamo una password casuale usando il comando simile dal passaggio 1:
$ openssl rand -hex 128 > /etc/mysql/encryption/keyfile.key - Prima di procedere al passaggio successivo, è importante prendere nota dei seguenti dettagli sulla crittografia del file della chiave:
- L'unico algoritmo attualmente supportato da MariaDB per crittografare il file della chiave è la modalità Cipher Block Chaining (CBC) di Advanced Encryption Standard (AES).
- La dimensione della chiave di crittografia può essere 128 bit, 192 bit o 256 bit.
- La chiave di crittografia viene creata dall'hash SHA-1 della password di crittografia.
- La password di crittografia ha una lunghezza massima di 256 caratteri.
$ 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 - Aggiungi le seguenti variabili nel tuo file di configurazione MySQL (ad esempio /etc/my.cnf su sistema operativo Linux basato su RHEL o /etc/mysql/my.cnf su sistema operativo basato su Debian/Ubuntu Linux)
[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 # Do not rotate key - Riavvia ora il server MariaDB
$ systemctl start mariadb
Verifica e verifica la crittografia
Per verificare e testare la crittografia, basta creare una tabella di esempio. Ad esempio, crea la tabella eseguendo le seguenti istruzioni SQL:
MariaDB [test]> CREATE TABLE a (i int) ENGINE=InnoDB ENCRYPTED=YES;
Query OK, 0 rows affected (0.018 sec)MariaDB [test]> CREATE TABLE b (i int) ENGINE=InnoDB;
Query OK, 0 rows affected (0.003 sec)Quindi, aggiungiamo alcuni dati alle tabelle:
MariaDB [test]> insert into a values(1),(2);
Query OK, 2 rows affected (0.001 sec)
Records: 2 Duplicates: 0 Warnings: 0MariaDB [test]> insert into b values(1),(2);
Query OK, 2 rows affected (0.001 sec)
Records: 2 Duplicates: 0 Warnings: 0Per controllare e vedere quali sono le tabelle crittografate, esegui semplicemente il seguente SELECT interrogazione di seguito:
MariaDB [test]> SELECT * FROM information_schema.innodb_tablespaces_encryption\G
*************************** 1. row ***************************
SPACE: 4
NAME: mysql/gtid_slave_pos
ENCRYPTION_SCHEME: 1
KEYSERVER_REQUESTS: 1
MIN_KEY_VERSION: 1
CURRENT_KEY_VERSION: 1
KEY_ROTATION_PAGE_NUMBER: NULL
KEY_ROTATION_MAX_PAGE_NUMBER: NULL
CURRENT_KEY_ID: 1
ROTATING_OR_FLUSHING: 0
*************************** 2. row ***************************
SPACE: 2
NAME: mysql/innodb_index_stats
ENCRYPTION_SCHEME: 1
KEYSERVER_REQUESTS: 1
MIN_KEY_VERSION: 1
CURRENT_KEY_VERSION: 1
KEY_ROTATION_PAGE_NUMBER: NULL
KEY_ROTATION_MAX_PAGE_NUMBER: NULL
CURRENT_KEY_ID: 1
ROTATING_OR_FLUSHING: 0
*************************** 3. row ***************************
SPACE: 1
NAME: mysql/innodb_table_stats
ENCRYPTION_SCHEME: 1
KEYSERVER_REQUESTS: 1
MIN_KEY_VERSION: 1
CURRENT_KEY_VERSION: 1
KEY_ROTATION_PAGE_NUMBER: NULL
KEY_ROTATION_MAX_PAGE_NUMBER: NULL
CURRENT_KEY_ID: 1
ROTATING_OR_FLUSHING: 0
*************************** 4. row ***************************
SPACE: 3
NAME: mysql/transaction_registry
ENCRYPTION_SCHEME: 1
KEYSERVER_REQUESTS: 0
MIN_KEY_VERSION: 1
CURRENT_KEY_VERSION: 1
KEY_ROTATION_PAGE_NUMBER: NULL
KEY_ROTATION_MAX_PAGE_NUMBER: NULL
CURRENT_KEY_ID: 1
ROTATING_OR_FLUSHING: 0
*************************** 5. row ***************************
SPACE: 5
NAME: test/a
ENCRYPTION_SCHEME: 1
KEYSERVER_REQUESTS: 1
MIN_KEY_VERSION: 1
CURRENT_KEY_VERSION: 1
KEY_ROTATION_PAGE_NUMBER: NULL
KEY_ROTATION_MAX_PAGE_NUMBER: NULL
CURRENT_KEY_ID: 1
ROTATING_OR_FLUSHING: 0
*************************** 6. row ***************************
SPACE: 6
NAME: test/b
ENCRYPTION_SCHEME: 1
KEYSERVER_REQUESTS: 1
MIN_KEY_VERSION: 1
CURRENT_KEY_VERSION: 1
KEY_ROTATION_PAGE_NUMBER: NULL
KEY_ROTATION_MAX_PAGE_NUMBER: NULL
CURRENT_KEY_ID: 1
ROTATING_OR_FLUSHING: 0
6 rows in set (0.000 sec)Per creare la tabella InnoDB non è necessario specificare la parola chiave ENCRYPTED=YES. Viene creato automaticamente come specificato nel file di configurazione per avere innodb_encrypt_tables =ON.
Se vuoi specificare l'ID di crittografia della tabella da utilizzare, puoi anche fare quanto segue:
MariaDB [test]> CREATE TABLE c (i int) ENGINE=InnoDB ENCRYPTION_KEY_ID = 4;
Query OK, 0 rows affected (0.003 sec)L'ENCRYPTION_KEY_ID è stato preso dal file di chiavi di crittografia che abbiamo generato in precedenza.
Inoltre, se desideri ulteriori test tramite shell, puoi utilizzare le stringhe comando che ti ho mostrato prima.
Informazioni aggiuntive sulla crittografia MariaDB
Se la tua istanza MariaDB non deve contenere tabelle non crittografate, imposta la variabile nel tuo file di configurazione my.cnf all'interno di [mysqld] sezione come segue:
innodb_encrypt_tables = FORCE.Per la crittografia binlog, aggiungi semplicemente quanto segue
encrypt_binlog = 1Il redo-log di InnoDB non è crittografato per impostazione predefinita. Per crittografarlo basta aggiungere la variabile qui sotto dopo la sezione [mysqld],
innodb-encrypt-logSe hai bisogno della crittografia per le tabelle temporanee su disco e i file temporanei, puoi aggiungere quanto segue:
encrypt-tmp-disk-tables=1
encrypt-tmp-files=1
