MariaDB
 sql >> база данни >  >> RDS >> MariaDB

Проучване на различните начини за криптиране на вашите MariaDB данни

Шифроването на вашата база данни MariaDB, независимо дали е в движение или в състояние на покой, е едно от най-важните неща, които една организация трябва да вземе предвид, ако цените вашите данни.

Организациите, които се занимават с финансови транзакции, медицински досиета, поверителна информация или дори лични данни, трябва да изискват този тип защита на данните. По същество криптирането на базата данни ще трансформира вашите четими данни във формат, който е нечетлив (или поне труден за декриптиране) от всеки неупълномощен потребител.

Криптирането на вашите данни предотвратява злоупотребата или злонамерените намерения от хакери или неоторизиран персонал, които могат да навредят на вашия бизнес. Некриптираните данни са податливи на атака от хакери, които инжектират злонамерени данни, които могат да повредят вашата инфраструктура или да откраднат информация. Quartz наскоро пусна статия за най-големия пробив, който се е случил по този начин и е тревожно, че данните са били откраднати от милиарди акаунти през последните две десетилетия.

Свързани ресурси Как да шифровате резервните си копия на MySQL и MariaDB Сигурност на базата данни – Шифроване на резервно копие по време на транспортиране и в покой Актуализирано:Станете ClusterControl DBA – Управление на SSL ключове и криптиране на MySQL данни по време на пренос

В този блог ще обсъдим различни начини за криптиране на вашите данни в MariaDB, независимо дали са в състояние на покой или при пренасяне. Ще ви предоставим основно разбиране за криптирането и как да го използвате, за да можете да използвате тези подходи, за да защитите данните си.

Шифроване на MariaDB данни:при пренасяне

MariaDB не използва по подразбиране криптиране по време на предаване на данни по мрежата от сървър към клиент. Въпреки това, използването на настройката по подразбиране може да провокира потенциален хакер да подслушва незащитен/некриптиран канал. Ако работите в изолирана или силно защитена среда, това състояние по подразбиране може да е приемливо. Това обаче не е идеално, когато вашият клиент и мрежа са в различна мрежа, тъй като настройва вашата база данни за потенциална атака „човек в средата“.

За да избегнете тези атаки, MariaDB ви позволява да шифровате данни при преминаване между сървъра и клиентите, използвайки протокола за сигурност на транспортния слой (TLS) (известен преди като Secure Socket Layer или SSL). За да започнете, трябва да се уверите, че вашият MariaDB сървър е компилиран с поддръжка на TLS. Можете да проверите това, като изпълните оператор SHOW GLOBAL VARIABLES, както е показано по-долу:

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)

Може да сте объркани в това как се различават SSL и TSL. Документацията може да използва термина SSL и променливите за конфигурация използва ssl_* като префикс, но MariaDB поддържа само своите сигурни наследници и вече не по-старите версии на SSL. Може да се наложи да идентифицирате и използвате правилните версии на MariaDB, които изискват правилната поддръжка на версиите на TLS, които трябва да използвате. Например, PCI DSS v3.2 препоръчва използването на минимална протоколна версия на TLSv1.2, която старите версии на MariaDB поддържат. Въпреки това, с TLS 1.3, изисква OpenSSL 1.1.1, е по-бърз поради по-ефективно ръкостискане между двете комуникиращи системи и това се поддържа от MariaDB 10.2.16 и MariaDB 10.3.8.

За да използвате наличните шифри за конкретна версия на TLS, можете да го дефинирате с помощта на --ssl-cipher в mysqld команда или ssl-шифр променлива в конфигурационния файл. Обърнете внимание, че TLSv1.3 шифри не могат да бъдат изключени, когато се използва OpenSSL, дори при използване на системната променлива ssl_cipher.

Конфигурационни параметри за шифроване на данни при пренос

За да шифровате данните си по време на пренос, можете да изпълните последователността от команди, изброени по-долу:

Генериране на 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

Генериране на сървърен сертификат

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

Генериране на клиентски сертификат

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

Обърнете внимание, че вашето общо име (CN) в -subj Аргументът трябва да е уникален спрямо вашите CA, сървърни и клиентски сертификати, които генерирате. Технически, CA и сървърът могат да имат една и съща CN, но е най-добре да го направите уникален идентификатор за тези три. В противен случай ще получите такава грешка:

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

Добре, сертификатите и ключовете са на мястото си. Трябва да посочите пътя, като използвате променливите ssl_* във вашия конфигурационен файл на MySQL (напр. /etc/my.cnf за базирана на RHEL OS или /etc/mysql/my.cnf за Debian/Ubuntu OS). Вижте примерната конфигурация по-долу:

[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

Разбира се, трябва да посочите правилния път, където сте поставили сертификата и ключовете си.

След това поставете тези параметри под [client-mariadb] раздел на вашия конфигурационен файл като такъв по-долу:

[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

Както споменахме по-рано, можете да посочите какъв тип шифър може да използва вашата SSL/TLS конфигурация. Това може да стане, като посочите конфигурацията по-долу:

[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

Или можете да използвате следната конфигурация като такава по-долу:

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.

Последният ред обозначава еквивалента на тази команда:

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

Това ще изключи слабите шифри и онези шифри, които са във формата на префикс, като DHE-DSS-AES256-GCM-SHA384 шифър например.

Генериране на вашия сертификат с помощта на ClusterControl

Като алтернатива можете да използвате ClusterControl, за да генерирате сертификатите и ключовете вместо вас. За да направите това, можете да направите следното, както се вижда по-долу:

  1. Изберете своя MariaDB клъстер, след което отидете на Сигурност раздел и изберете SSL криптиране. В моя пример по-долу това е MariaDB Galera Cluster:
  2. Изберете SSL криптирането и го активирайте. Ще можете да създадете нов сертификат или да изберете съществуващ. За тази извадка ще избера опцията „Създаване на сертификат“:
  3. Последната стъпка е да конфигурирате дните на изтичане на вашия сертификат. Виж отдолу: Ако щракнете върху "Рестартиране на възли", ClusterControl ще извърши непрекъснато рестартиране. Имайте предвид, че ако използвате MariaDB 10.4 (която в момента е на неговата RC версия), можете да използвате SSL, без да рестартирате вашия MariaDB сървър. Просто използвайте командата FLUSH SSL, която е нова функция, добавена във версията на MariaDB 10.4.

Друг начин за работа с вашите TLS/SSL сертификати/ключове, можете също да използвате Управление на ключове под ClusterControl. Разгледайте този блог, за да научите повече за това как да направите това.

Създайте своя TLS/SSL потребител на MariaDB

В случай, че сте мислили, че сте готови, не сте. Трябва да се уверите, че вашите потребители трябва да използват SSL, когато се свързват със сървъра. От този потребител ще се изисква винаги да взаимодейства със сървъра чрез частен канал. Това е много важно, защото трябва да сте сигурни, че всичките ви клиенти ще взаимодействат с вашия сървър по много сигурен и личен начин.

За да направите това, просто направете следния пример:

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)

Уверете се, че след като се свържете с хоста на вашия клиент/приложение, копирайте сертификата, който сте генерирали въз основа на предишните стъпки.

Потвърждаване на връзката ви

Тестването на връзката ви дали е криптирана или не е много важно за определяне на състоянието. За да направите това, можете да направите следната команда по-долу:

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

Като алтернатива, OpenSSL версия 1.1.1 добави поддръжка за -starttls mysql . Има наличен статично компилиран openssl двоичен файл, който можете да получите тук https://testssl.sh/openssl-1.0.2k-dev-chacha.pm.ipv6.Linux+FreeBSD.tar.gz (или разгледайте тази презентация в PDF формат) . След това можете да направите следната команда по-долу:

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

Примерният резултат ще бъде като по-долу:

$ 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
ClusterControlЕдинична конзола за цялата ви инфраструктура на базата данни Открийте какво още е новото в ClusterControlИнсталирайте ClusterControl БЕЗПЛАТНО

Криптиране на MariaDB данни:в покой

Криптираните данни, които се съхраняват физически във вашето хардуерно хранилище (т.е. в състояние на покой), осигуряват по-голяма стабилност и защита срещу пробив на данни. Ако злонамерен нападател може да влезе във вашата база данни MariaDB, тогава той може да прочете данните в обикновен текст. Подобно на използването на команда strings в Linux, ще можете лесно да извлечете данните от базата данни. Освен това добавя по-голяма опасност, ако нападателят има задълбочено разбиране на файловия формат на пространството за таблици.

Шифроването в състояние на покой е допълнителна защита, но не е заместител на добра защитна стена, силни пароли, правилни потребителски разрешения и криптиране по време на пренос между клиента и сървъра.

Поддръжката на MariaDB за криптиране на таблици и пространства за таблици беше добавена във версия 10.1.3. Тъй като вашите таблици са криптирани, вашите данни е почти невъзможно някой да открадне. Този тип криптиране също така позволява на вашата организация да спазва правителствените разпоредби като GPDR.,

След като активирате криптирането на данни в покой в ​​MariaDB, таблиците, които са дефинирани с ENCRYPTED=YES или с innodb_encrypt_tables=ON, ще имат вашите съхранени данни криптирани. Декриптира се само при достъп през базата данни на MariaDB, в противен случай данните са нечетими.

Например, четенето на данни, които са некриптирани, ще ви покаже като такива:

$ 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

но с криптирани данни вашето пространство за таблици няма да може да се чете точно както в примера по-долу:

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

Заслужава да се отбележи също, че криптирането Data-At-Rest на MariaDB добавя обем на данните от приблизително 3-5%. MariaDB криптирането също се поддържа напълно, когато се използват двигателите за съхранение на XtraDB и InnoDB. Шифроването също се поддържа за механизма за съхранение на Aria, но само за таблици, създадени с ROW_FORMAT=PAGE (по подразбиране) и за двоичния дневник (регистрационен файл за репликация). MariaDB дори позволява на потребителя гъвкаво какво да криптира. В XtraDB или InnoDB човек може да избере да шифрова:

  • всичко — всички пространства за таблици (с всички таблици)
  • отделни таблици
  • всичко, с изключение на отделните таблици

Освен това можете да изберете да шифровате лог файловете на XtraDB/InnoDB (което е препоръчително).

MariaDB има своите ограничения. Galera Cluster gcache, например, не е криптиран, но е планиран като част от версията на MariaDB 10.4. Можете да намерите пълен списък с ограничения тук.

Как да настроите и конфигурирате MariaDB за криптиране на данни в покой

  1. Генерирайте произволни ключове за криптиране с помощта на команда openssl rand. 
    $ mkdir -p /etc/mysql/encryption
$ for i in {1..5}; do openssl rand -hex 32 >> /etc/mysql/encryption/keyfile;  done;
    Сега отворете и редактирайте файла /etc/mysql/encryption/keyfile и добавете идентификатора на ключа, който ще бъде препратка при създаване на криптирани таблици като идентификатор на ключа за криптиране. Вижте ENCRYPTION_KEY_ID за повече подробности. Следователно, следният формат трябва да бъде, както следва:
    <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. Нека създадем или генерираме произволна парола с помощта на подобна команда от стъпка 1:
    $ openssl rand -hex 128 > /etc/mysql/encryption/keyfile.key
  3. Преди да продължите към следващата стъпка, важно е да вземете под внимание следните подробности относно криптирането на файла с ключ:
    • Единственият алгоритъм, който MariaDB понастоящем поддържа за криптиране на ключовия файл, е режимът на Cipher Block Chaining (CBC) на Advanced Encryption Standard (AES).
    • Размерът на ключа за криптиране може да бъде 128-бита, 192-бита или 256-бита.
    • Ключът за криптиране се създава от SHA-1 хеша на паролата за криптиране.
    • Паролата за шифроване има максимална дължина от 256 знака.
    Сега, за да шифровате ключовия файл с помощта на команда openssl enc, изпълнете следната команда по-долу:
    $ 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. Добавете следните променливи във вашия конфигурационен файл MySQL (т.е. /etc/my.cnf на базирана на RHEL ОС Linux или /etc/mysql/my.cnf в базирана на 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
  5. Рестартирайте MariaDB Server сега 
    $ systemctl start mariadb

Проверете и тествайте криптирането

За да проверите и тествате криптирането, просто създайте примерна таблица. Например, създайте таблицата, като изпълните следните 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)

След това нека добавим малко данни към таблиците:

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

За да проверите и видите кои са шифрованите таблици, просто изпълнете следния SELECT заявка по-долу:

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)

Създаването на таблицата InnoDB не е необходимо да посочва ключова дума ENCRYPTED=YES. Създава се автоматично, както посочихме в конфигурационния файл да има innodb_encrypt_tables =ON.

Ако искате да посочите идентификатора за криптиране на използваната таблица, можете да направите и следното:

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

ENCRYPTION_KEY_ID беше взет от файла с ключ за криптиране, който генерирахме по-рано.

Освен това, ако искате повече тестове чрез shell, можете да използвате низовете команда, която ви показах по-рано.

Допълнителна информация за MariaDB криптиране

Ако вашият екземпляр на MariaDB не трябва да съдържа никакви некриптирани таблици, просто настройте променливата във вашия конфигурационен файл my.cnf в [mysqld] раздел, както следва:

innodb_encrypt_tables = FORCE.

За binlog криптиране просто добавете следното

encrypt_binlog = 1

Redo-log на InnoDB не е криптиран по подразбиране. За да го криптирате, просто добавете променливата по-долу след секцията [mysqld],

innodb-encrypt-log

Ако имате нужда от криптиране за вашите временни таблици и временни файлове на диска, можете да добавите следното:

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

  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. Как работи RTRIM_ORACLE() в MariaDB

  2. MariaDB низове за формат на дата

  3. Как да архивирате вашата Moodle MariaDB база данни

  4. MariaDB CONNECTION_ID() Обяснено

  5. Съвети за съхраняване на вашите архиви на MariaDB в облака