sql >> Databáze >  >> RDS >> MariaDB

Zkoumání různých způsobů šifrování dat MariaDB

Šifrování vaší databáze MariaDB, ať už je na cestě nebo v klidu, je jednou z nejdůležitějších věcí, které by organizace měla zvážit, pokud si vážíte svých dat.

Organizace, které se zabývají finančními transakcemi, lékařskými záznamy, důvěrnými informacemi nebo dokonce osobními údaji, musí tento typ ochrany údajů vyžadovat. Šifrování databáze v zásadě převede vaše čitelná data do formátu, který je nečitelný (nebo alespoň obtížně dešifrovatelný) jakýmkoli neoprávněným uživatelem.

Šifrování vašich dat zabrání zneužití nebo nekalým úmyslům hackerů nebo neoprávněných osob, které by mohly poškodit vaši firmu. Nešifrovaná data jsou náchylná k útokům hackerů, kteří vkládají škodlivá data, která by mohla poškodit vaši infrastrukturu nebo ukrást informace. Quartz nedávno zveřejnil článek o největším narušení, ke kterému došlo v tomto smyslu, a je alarmující, že za poslední dvě desetiletí byla ukradena data z miliard účtů.

Související zdroje Jak šifrovat zálohy MySQL a MariaDB Zabezpečení databáze – Šifrování záloh během přenosu a v klidu Aktualizováno:Staňte se ClusterControl DBA – Správa klíčů SSL a šifrování dat MySQL při přenosu

V tomto blogu probereme různé způsoby, jak zašifrovat vaše data MariaDB, ať už jsou v klidu nebo na cestě. Poskytneme vám základní znalosti o šifrování a o tom, jak jej používat, abyste mohli tyto přístupy využívat k zabezpečení vašich dat.

Šifrování dat MariaDB:In-Transit

MariaDB ve výchozím nastavení nepoužívá šifrování během přenosu dat přes síť ze serveru na klienta. Použití výchozího nastavení by však mohlo potenciálního hackera vyprovokovat k odposlouchávání nezabezpečeného/nešifrovaného kanálu. Pokud pracujete v izolovaném nebo vysoce zabezpečeném prostředí, může být tento výchozí stav přijatelný. To však není ideální, když jsou váš klient a síť v jiné síti, protože to nastavuje vaši databázi pro potenciální útok typu „man-in-the-middle“.

Aby se zabránilo těmto útokům, MariaDB vám umožňuje šifrovat data při přenosu mezi serverem a klienty pomocí protokolu Transport Layer Security (TLS) (dříve známého jako Secure Socket Layer nebo SSL). Chcete-li začít, musíte se ujistit, že váš server MariaDB byl zkompilován s podporou TLS. Můžete to ověřit spuštěním příkazu SHOW GLOBAL VARIABLES, jak je ukázáno níže:

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)

Možná budete zmateni tím, jak se SSL a TSL liší. Dokumentace může používat termín SSL a proměnné pro konfiguraci používají také ssl_* jako prefix, nicméně MariaDB podporuje pouze jeho bezpečné nástupce a již ne starší verze SSL. Možná budete muset identifikovat a používat správné verze MariaDB, které vyžadují správnou podporu verzí TLS, které potřebujete používat. Například PCI DSS v3.2 doporučuje používat minimální verzi protokolu TLSv1.2, kterou staré verze MariaDB podporují. S TLS 1.3 však vyžaduje OpenSSL 1.1.1, je rychlejší díky efektivnějšímu handshake mezi dvěma komunikujícími systémy a to je podporováno od MariaDB 10.2.16 a MariaDB 10.3.8.

Chcete-li využít šifry dostupné pro konkrétní verzi TLS, můžete ji definovat pomocí --ssl-cipher v mysqld příkaz nebo ssl-cipher proměnná v konfiguračním souboru. Vezměte na vědomí, že šifry TLSv1.3 nelze vyloučit při použití OpenSSL, a to ani při použití systémové proměnné ssl_cipher.

Konfigurační parametry pro šifrování dat při přenosu

Chcete-li zašifrovat svá data během přenosu, můžete provést sekvenci příkazů uvedených níže:

Vygenerujte certifikát 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.pem

Vygenerujte certifikát serveru

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.pem

Vygenerujte klientský certifikát

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.pem

Vezměte na vědomí, že vaše běžné jméno (CN) v -subj argument musí být jedinečný vůči certifikátům vaší CA, serveru a klienta, které generujete. Technicky mohou mít CA a Server stejné CN, ale je nejlepší vytvořit jedinečný identifikátor pro tyto tři. V opačném případě se zobrazí chyba jako taková:

ERROR 2026 (HY000): SSL connection error: tlsv1 alert unknown ca

Dobře, certifikáty a klíče jsou na místě. Cestu musíte zadat pomocí proměnných ssl_* v konfiguračním souboru MySQL (např. /etc/my.cnf pro OS založený na RHEL nebo /etc/mysql/my.cnf pro OS Debian/Ubuntu). Viz příklad konfigurace níže:

[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.pem

Samozřejmě musíte zadat správnou cestu, kam jste umístili svůj certifikát a klíče.

Poté umístěte tyto parametry pod [client-mariadb] části vašeho konfiguračního souboru níže:

[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.pem

Jak již bylo zmíněno dříve, můžete určit, jaký typ šifry může vaše konfigurace SSL/TLS používat. To lze provést zadáním nastavení konfigurace níže:

[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-SHA384

Nebo můžete použít následující konfiguraci jako takovou níže:

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.

Poslední řádek označuje ekvivalent tohoto příkazu:

openssl ciphers -v 'HIGH:!DSS:!RCA-SHA:!DES-CBC3-SHA:[email protected]'

Tím vyloučíte slabé šifry a ty šifry, které jsou ve tvaru předpony, jako je DHE-DSS-AES256-GCM-SHA384 například šifra.

Generování certifikátu pomocí ClusterControl

Alternativně můžete k vygenerování certifikátů a klíčů použít ClusterControl. Chcete-li to provést, můžete provést následující, jak je vidět níže:

  1. Vyberte svůj MariaDB Cluster a poté přejděte na Zabezpečení a vyberte Šifrování SSL. V mém příkladu níže se jedná o klastr MariaDB Galera:
  2. Vyberte šifrování SSL a povolte jej. Budete moci vytvořit nový certifikát nebo vybrat stávající. Pro tento příklad zvolím možnost „Vytvořit certifikát“:
  3. Posledním krokem je konfigurace dnů vypršení platnosti certifikátu. Viz. níže: Pokud kliknete na "Restartovat uzly", ClusterControl provede postupný restart. Vezměte na vědomí, že pokud používáte MariaDB 10.4 (která je aktuálně ve verzi RC), můžete použít SSL bez restartování serveru MariaDB. Stačí použít příkaz FLUSH SSL, což je nová funkce přidaná do verze MariaDB 10.4.

Dalším způsobem, jak zacházet s certifikáty/klíči TLS/SSL, můžete také použít Správu klíčů pod ClusterControl. Podívejte se na tento blog, kde se dozvíte více o tom, jak to udělat.

Vytvořte si uživatele TLS/SSL MariaDB

V případě, že jste si mysleli, že jste skončili, nemáte. Musíte zajistit, aby vaši uživatelé museli používat SSL, když se připojují k serveru. Tento uživatel bude muset vždy komunikovat se serverem prostřednictvím soukromého kanálu. To je velmi důležité, protože se musíte ujistit, že všichni vaši klienti budou s vaším serverem komunikovat velmi bezpečným a soukromým způsobem.

Chcete-li to provést, proveďte následující příklad:

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)

Ujistěte se, že po připojení k hostiteli vašeho klienta/aplikace zkopírujte certifikát, který jste vygenerovali na základě předchozích kroků.

Ověření vašeho připojení

Pro zjištění stavu je velmi důležité otestovat vaše připojení, zda je šifrované nebo ne. Chcete-li to provést, můžete provést následující příkaz:

mysql -e "status"|grep -i 'cipher'
SSL:                    Cipher in use is DHE-RSA-AES256-GCM-SHA384

Případně OpenSSL verze 1.1.1 přidala podporu pro -starttls mysql . K dispozici je staticky zkompilovaný openssl binární soubor, který můžete získat zde https://testssl.sh/openssl-1.0.2k-dev-chacha.pm.ipv6.Linux+FreeBSD.tar.gz (nebo si prohlédněte tuto prezentaci ve formátu PDF) . Potom můžete provést následující příkaz:

echo | bin/openssl.Linux.x86_64.static s_client -starttls mysql -connect localhost:3306 -CAfile /etc/ssl/galera/self-gen/ca-cert.pem

Příklad výsledku by vypadal takto:

$ 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)
---
DONE
ClusterControlSingle Console pro celou vaši databázovou infrastrukturu Zjistěte, co je ještě nového v ClusterControl Nainstalujte ClusterControl ZDARMA

Šifrování dat MariaDB:V klidu

Šifrovaná data, která jsou fyzicky uložena ve vašem hardwarovém úložišti (tj. v klidu), poskytují větší stabilitu a ochranu proti úniku dat. Pokud se škodlivý útočník může přihlásit do vaší databáze MariaDB, může číst data v prostém textu. Podobně jako pomocí příkazu strings v Linuxu budete moci snadno načíst data z databáze. Navíc zvyšuje nebezpečí, pokud má útočník pokročilé znalosti formátu souboru tabulkového prostoru.

Klidové šifrování je další ochranou, ale nenahrazuje dobrý firewall, silná hesla, správná uživatelská oprávnění a šifrování při přenosu mezi klientem a serverem.

Podpora MariaDB pro šifrování v tabulkách a tabulkových prostorech byla přidána ve verzi 10.1.3. Vzhledem k tomu, že vaše tabulky jsou šifrované, je téměř nemožné, aby někdo ukradl vaše data. Tento typ šifrování také umožňuje vaší organizaci, aby byla v souladu s vládními nařízeními, jako je GPDR.,

Jakmile povolíte šifrování dat v klidu v MariaDB, tabulky, které jsou definovány pomocí ENCRYPTED=YES nebo innodb_encrypt_tables=ON, budou mít vaše uložená data zašifrována. Dešifruje se pouze při přístupu přes databázi MariaDB, jinak jsou data nečitelná.

Například při čtení dat, která jsou nezašifrovaná, se zobrazí jako takové:

$ 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.KK

ale se zašifrovanými daty nebude váš tabulkový prostor čitelný jako v příkladu níže:

# strings user_logs.ibd |head -10
E?*Pa
[+YQ
KNmbUtQ
T_lPAW
\GbQ.
] e2
#Rsd
ywY%o
kdUY
{]~GE

Je také pozoruhodné, že šifrování Data-At-Rest od MariaDB zvyšuje režii velikosti dat zhruba o 3–5 %. Šifrování MariaDB je také plně podporováno při použití úložných enginů XtraDB a InnoDB. Šifrování je podporováno také pro úložiště Aria, ale pouze pro tabulky vytvořené pomocí ROW_FORMAT=PAGE (výchozí) a pro binární protokol (replikační protokol). MariaDB dokonce umožňuje uživateli flexibilně, co šifrovat. V XtraDB nebo InnoDB si můžete zvolit šifrování:

  • vše – všechny tabulkové prostory (se všemi tabulkami)
  • jednotlivé tabulky
  • vše, kromě jednotlivých tabulek

Navíc lze zvolit šifrování souborů protokolu XtraDB/InnoDB (což je doporučeno).

MariaDB má svá omezení. Například gcache Galera Cluster není šifrována, ale je plánována jako součást verze MariaDB 10.4. Úplný seznam omezení naleznete zde.

Jak nastavit a nakonfigurovat MariaDB pro šifrování dat v klidu

  1. Vygenerujte náhodné šifrovací klíče pomocí příkazu openssl rand. 
    $ mkdir -p /etc/mysql/encryption
$ for i in {1..5}; do openssl rand -hex 32 >> /etc/mysql/encryption/keyfile;  done;
    Nyní otevřete a upravte soubor /etc/mysql/encryption/keyfile a přidejte ID klíče, na které se bude odkazovat při vytváření šifrovaných tabulek, protože jde o ID šifrovacího klíče. Další podrobnosti naleznete v části ENCRYPTION_KEY_ID. Následující formát by tedy měl být následující:
    <encryption_key_id1>;<hex-encoded_encryption_key1>
<encryption_key_id2>;<hex-encoded_encryption_key2>
    In my example keyfile, this looks as the following:
    $ cat keyfile
1;687a90b4423c10417f2483726a5901007571c16331d2ee9534333fef4e323075
2;e7bf20f1cbde9632587c2996871cff74871890d19b49e273d13def123d781e17
3;9284c9c80da9a323b3ac2c82427942dfbf1718b57255cc0bc0e2c3d6f15ac3ac
4;abf80c3a8b10643ef53a43c759227304bcffa263700a94a996810b0f0459a580
5;bdbc5f67d34a4904c4adc9771420ac2ab2bd9c6af1ec532e960335e831f02933
  2. Pojďme vytvořit nebo vygenerovat náhodné heslo pomocí podobného příkazu z kroku 1:
    $ openssl rand -hex 128 > /etc/mysql/encryption/keyfile.key
  3. Než přejdete k dalšímu kroku, je důležité vzít na vědomí následující podrobnosti o šifrování souboru klíče:
    • Jediný algoritmus, který MariaDB v současné době podporuje pro šifrování souboru klíče, je režim Cipher Block Chaining (CBC) Advanced Encryption Standard (AES).
    • Velikost šifrovacího klíče může být 128 bitů, 192 bitů nebo 256 bitů.
    • Šifrovací klíč je vytvořen z hodnoty hash SHA-1 šifrovacího hesla.
    • Šifrovací heslo má maximální délku 256 znaků.
    Chcete-li nyní zašifrovat soubor klíče pomocí příkazu openssl enc, spusťte následující příkaz:
    $ 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
  4. Přidejte do konfiguračního souboru MySQL následující proměnné (tj. /etc/my.cnf v operačním systému Linux založeném na RHEL nebo /etc/mysql/my.cnf v operačním systému založeném na Linuxu Debian/Ubuntu) 
    [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
  5. Restartujte server MariaDB nyní 
    $ systemctl start mariadb

Ověřte a otestujte šifrování

Chcete-li ověřit a otestovat šifrování, stačí vytvořit vzorovou tabulku. Například vytvořte tabulku provedením následujících příkazů 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)

Poté do tabulek přidejte nějaká data:

MariaDB [test]> insert into a values(1),(2);
Query OK, 2 rows affected (0.001 sec)
Records: 2  Duplicates: 0  Warnings: 0
MariaDB [test]> insert into b values(1),(2);
Query OK, 2 rows affected (0.001 sec)
Records: 2  Duplicates: 0  Warnings: 0

Chcete-li zkontrolovat a zjistit, které tabulky jsou zašifrovány, stačí spustit následující SELECT dotaz níže:

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)

Při vytváření tabulky InnoDB není nutné zadávat klíčové slovo ENCRYPTED=YES. Je vytvořen automaticky, jak jsme zadali v konfiguračním souboru, aby měl innodb_encrypt_tables =ON.

Pokud chcete zadat id šifrování tabulky, která se má použít, můžete také provést následující:

MariaDB [test]> CREATE TABLE c (i int) ENGINE=InnoDB ENCRYPTION_KEY_ID = 4;
Query OK, 0 rows affected (0.003 sec)

ENCRYPTION_KEY_ID bylo převzato ze souboru šifrovacího klíče, který jsme vygenerovali dříve.

Navíc, pokud chcete více testování prostřednictvím shellu, můžete použít řetězce příkaz, který jsem vám ukázal dříve.

Další informace o šifrování MariaDB

Pokud by vaše instance MariaDB neměla obsahovat žádné nešifrované tabulky, stačí nastavit proměnnou v konfiguračním souboru my.cnf v [mysqld] oddíl takto:

innodb_encrypt_tables = FORCE.

Pro šifrování binlog stačí přidat následující

encrypt_binlog = 1

Redo-log InnoDB není ve výchozím nastavení šifrován. Chcete-li jej zašifrovat, přidejte proměnnou níže za sekci [mysqld],

innodb-encrypt-log

Pokud potřebujete šifrování pro dočasné tabulky a dočasné soubory na disku, můžete přidat následující:

encrypt-tmp-disk-tables=1
encrypt-tmp-files=1

  1. Jak odesílat e-maily ze serveru SQL (T-SQL)

  2. Výukový program DBMS:Kompletní rychlokurz o DBMS

  3. Zakažte přihlášení root v phpMyAdmin

  4. Oddělovače v MySQL