Шифроването е една от най-важните функции за сигурност, за да запазите данните си възможно най-сигурни. В зависимост от данните, които обработвате, това не винаги е задължително, но поне трябва да го разглеждате като подобрение на сигурността във вашата организация и всъщност се препоръчва да избягвате кражба на данни или неоторизиран достъп.
В този блог ще опишем два основни типа криптиране и как да го конфигурирате на MariaDB сървър.
Какво е криптиране на данни?
Има два основни типа криптиране на данни:в покой и по време на пренос. Да видим какво означават.
Шифроване на данни в покой
Данните, съхранявани в система, са известни като данни в покой. Шифроването на тези данни се състои в използване на алгоритъм за преобразуване на текст или код в нечетими. Трябва да имате ключ за криптиране, за да декодирате криптираните данни.
Криптирането на цяла база данни трябва да се извършва с повишено внимание, тъй като може да доведе до сериозно въздействие върху производителността. Следователно е разумно да се криптират само отделни полета или таблици.
Криптирането на данни в покой защитава данните от физическа кражба на твърди дискове или неоторизиран достъп до съхранение на файлове. Това криптиране също е в съответствие с разпоредбите за сигурност на данните, особено ако във файловата система се съхраняват финансови или здравни данни.
Шифроване на данни при транспорт
Данните, прехвърлени или преместени между транзакции, са известни като данни в транзит. Данните, които се движат между сървъра и клиента, докато разглеждате уеб страници, са добър пример за този вид данни.
Тъй като винаги е в движение, той трябва да бъде защитен с подходящо криптиране, за да се избегне кражба или промяна на данните, преди да достигне местоназначението си.
Идеалната ситуация за защита на пренасяните данни е данните да са криптирани преди да се преместят и да се дешифрират само когато достигнат крайната дестинация.
Криптиране на данни в покой на MariaDB
Криптирането на таблици и пространства за таблици беше добавено в MariaDB от версия 10.1 и поддържа криптиране за XtraDB, InnoDB и Aria машини за съхранение, както и за двоични регистрационни файлове.
Можете да изберете различни начини за криптиране:
- Всички таблици
- Отделни маси
- Всичко, с изключение на отделните таблици
Според документацията използването на криптиране има режийни разходи от приблизително 3-5%, така че е важно да имате тестова среда, за да я подчертаете и да видите как реагира, за да избегнете проблеми в производството.
Как да конфигурирате криптиране на данни в покой на MariaDB
Нека проверим съществуваща таблица „град“ в база данни на MariaDB:
$ strings city.ibd |headinfimumsupremuminfimumsupremum3ABW3KHMinfimumsupremumKabul AFGKabolQandahar AFGQandahar Както можете да видите, можете да четете данни от там без проблем, като използвате командата strings Linux например. Сега нека видим как да го криптираме.
Генерирайте ключове за криптиране с помощта на командата openssl rand:
$ mkdir -p /etc/mysql/encryption$ за i в {1..4}; do openssl rand -hex 32>> /etc/mysql/encryption/keyfile; готово; Редактирайте генерирания файл /etc/mysql/encryption/keyfile и добавете идентификаторите на ключове, които ще бъдат посочени при създаване на криптирани таблици. Форматът трябва да бъде както следва:
<предварителен><идентификатор_на_ключ_за_шифроване1>;<хекс-кодиран_ключ_за_шифроване1><идентификатор_на_ключ_за_шифроване2>;<шенадесетичен_кодиран_ключ_за_шифроване2> Можете да го редактирате с помощта на командата sed linux по този начин:
$ за i в {1..4}; do sed -i -e "$i s/^/$i;/" ключов файл; готово
Така че файлът трябва да бъде нещо подобно:
$ cat /etc/mysql/encryption/keyfile1;f237fe72e16206c0b0f6f43c3b3f4accc242564d77f5fe17bb621de388c193af2;0c0819a10fb366a5ea657a71759ee6a950ae8f25a5ba7400a91f59b63683edc53;ac9ea3a839596dbf52492d9ab6b180bf11a35f44995b2ed752c370d920a101694;72afc936e16a8df05cf994c7902e588de0d11ca7301f9715d00930aa7d5ff8ab
Сега генерирайте произволна парола, като използвате подобна команда openssl, която видяхте по-рано:
$ openssl rand -hex 128> /etc/mysql/encryption/keyfile.key
Преди да преминете към следващата стъпка, важно е да знаете следните подробности за криптирането на файла с ключ:
- Единственият алгоритъм, който 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 файл:/etc/mysql/encryption/keyfile.key -in /etc/mysql/encryption/keyfile -out /etc/mysql/encryption /keyfile.enc
Накрая трябва да добавите следните параметри във вашия конфигурационен файл my.cnf (намиращ се в /etc/ на базирана на RedHat OS или /etc/mysql/ на базирана на Debian OS):
[mysqld]…#################### ШИФИРАНЕ НА БАЗА ДАННИ ################### ##plugin_load_add =file_key_managementfile_key_management_filename =/etc/mysql/encryption/keyfile.encfile_key_management_filekey =FILE:/etc/mysql/encryption/keyfile.keyfile_key_management_encryption_algorithm =aes_cbcencrypt_binlog =1innodb_encrypt_tables =ONinnodb_encrypt_log =ONinnodb_encryption_threads =4innodb_encryption_rotate_key_age =0 …
И рестартирайте услугата MariaDB, за да приемете промените:
$ systemctl рестартирайте mariadb
В този момент всичко е готово за използване на функцията за криптиране. Нека криптираме същата таблица, която показахме по-рано, „град“. За това трябва да използвате израза ALTER TABLE, задаващ параметъра ENCRYPTED в YES:
MariaDB [свят]> ALTER TABLE city ENCRYPTED=ДА;Заявката ОК, 0 засегнати реда (0,483 сек)Записи:0 Дубликати:0 Предупреждения:0
Сега, ако се опитате да получите достъп до таблицата директно от файловата система, ще видите нещо подобно:
$ strings city.ibd |headPU%O!ybN)b9,{9WB4T3uG:?oiN,35sz8g)Qo(oq_A1k=-w
Както виждате, таблицата е нечетлива. Можете също да посочите идентификатора на ключа за криптиране, като добавите параметъра ENCRYPTION_KEY_ID = в командата MySQL, където е идентификационният номер от създадения по-рано ключов файл.
Новите таблици ще бъдат криптирани по подразбиране, тъй като ние задаваме параметъра innodb_encrypt_tables във ON в конфигурационния файл my.cnf.
Криптиране на данни по време на транспортиране в MariaDB
MariaDB ви позволява да шифровате пренос на данни между сървъра и клиентите с помощта на протокола за сигурност на транспортния слой (TLS), известен преди като Secure Socket Layer или SSL.
На първо място, трябва да се уверите, че вашият MariaDB сървър е компилиран с поддръжка на TLS. Можете да проверите това, като изпълните следния оператор SHOW GLOBAL VARIABLES:
MariaDB [(няма)]> ПОКАЗВАНЕ НА ГЛОБАЛНИ ПРОМЕНИ КАТО 'version_ssl_library';+---------------------+------ ---------------------+| Име на променлива | Стойност |+---------------------+--------------------- ---+| версия_ssl_library | OpenSSL 1.1.1 11 септември 2018 г. |+---------------------+------------------- ---------+1 ред в комплект (0,001 сек)
И проверете дали не се използва в момента, като използвате израза SHOW VARIABLES:
MariaDB [(няма)]> ПОКАЗВАНЕ НА ПРОМЕНЛИВИ КАТО '%ssl%';+---------------------+----- -----------------------+| Име на променлива | Стойност |+---------------------+--------------------- ---+| have_openssl | ДА || имам_ssl | ИЗКЛЮЧЕНО || ssl_ca | || ssl_capath | || ssl_cert | || ssl_cipher | || ssl_crl | || ssl_crlpath | || ssl_key | || версия_ssl_library | OpenSSL 1.1.1 11 септември 2018 г. |+---------------------+------------------- ---------+10 реда в комплект (0,001 сек)
Можете също да проверите състоянието на SSL с помощта на командата status MariaDB:
MariaDB [(няма)]> status--------------mysql версия 15.1 Distrib 10.4.13-MariaDB, за debian-linux-gnu (x86_64) с помощта на readline 5.2 Идентификатор на връзката:22 Текуща база данни:Текущ потребител:[email protected]:Не се използва Текущ пейджър:stdoutUsing outfile:''Използване на разделител:;Сървър:MariaDBServer версия:10.4.13-MariaDB-1:10.4.13-maria~bionic log mariadb.org binary distributionProtocol версия:10Connection:Localhost през UNIX socketServer набор от символи:latin1Db набор от символи:latin1Client characterset:utf8Conn. набор от символи:utf8UNIX сокет:/var/lib/mysql/mysql.sockUptime:4 часа 28 мин. 25 сек. Нишки:11 Въпроси:111668 Бавни заявки:0 Отваряния:92 Изчистване на таблици:1 Отворени таблици:83 g Запитвания в секунда:83g Запитвания в секунда ------------
Как да конфигурирате шифроване на данни по време на транспортиране в MariaDB
Нека създадем директорията на сертификати за съхраняване на всички сертификати:
$ mkdir -p /etc/mysql/certs
Сега нека генерираме CA сертификатите, които ще бъдат конфигурирани да криптират връзката:
$ openssl genrsa 2048> ca-key.pem$ openssl req -new -x509 -nodes -days 365000 -key ca-key.pem -out ca-cert.pem
Тази последна команда ще ви помоли да попълните следната информация:
Име на държава (2 буквен код) [AU]:Име на щат или провинция (пълно име) [Some-State]:Име на населено място (напр. град) []:Име на организация (напр. компания) [Интернет Widgits Pty Ltd]:Име на организационна единица (напр. секция) []:Общо име (напр. FQDN на сървъра или ВАШЕТО име) []:Имейл адрес []:
Сега трябва да генерирате сървърните сертификати:
$ openssl req -newkey rsa:2048 -nodes -keyout server-key.pem -out server-req.pem
Тази команда ще ви помоли да попълните същата информация, както преди, плюс незадължителна парола за сертификат.
$ 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 -nodes -keyout client-key.pem -out client-req.pem
Това също така ще ви помоли да попълните информацията и незадължителна парола за сертификат.
$ openssl rsa -in client-key.pem -out client-key.pem$ openssl x509 -req -in client-req.pem -CA ca-cert.pem -CAkey ca-key.pem - set_serial 01 -out client-cert.pem
Уверете се, че използвате различно общо име за всеки сертификат, в противен случай няма да работи и ще получите съобщение като:
ГРЕШКА 2026 (HY000):Грешка при SSL връзката:самоподписан сертификат
В този момент ще имате нещо подобно:
$ ls /etc/mysql/certs/ca-cert.pem ca-key.pem client-cert.pem client-key.pem client-req.pem server-cert.pem server-key.pem server-req.pem
И можете да потвърдите сертификатите, като използвате следната команда:
$ openssl verify -CAfile ca-cert.pem server-cert.pem client-cert.pemserver-cert.pem:OKclient-cert.pem:OK
Така че сега нека го конфигурираме в конфигурационния файл my.cnf (намира се в /etc/ на базирана на RedHat OS или /etc/mysql/ на базирана на Debian OS):
[mysqld]ssl_ca=/etc/mysql/certs/ca-cert.pemssl_cert=/etc/mysql/certs/server-cert.pemssl_key=/etc/mysql/certs/server-key.pem[ client-mariadb]ssl_ca =/etc/mysql/certs/ca-cert.pemssl_cert=/etc/mysql/certs/client-cert.pemssl_key=/etc/mysql/certs/client-key.pem
Уверете се, че го добавяте в съответния раздел (mysqld и client-mariadb).
Променете собственика на сертификата и рестартирайте услугата за база данни:
$ chown mysql.mysql /etc/mysql/certs/$ systemctl рестартирайте mariadb
След това, ако погледнете изхода SHOW VARIABLES, трябва да имате това:
MariaDB [(няма)]> ПОКАЗВАНЕ НА ПРОМЕНЛИВИ КАТО '%ssl%';+---------------------+----- ----------------------------+| Име на променлива | Стойност |+---------------------+--------------------- ---------+| have_openssl | ДА || имам_ssl | ДА || ssl_ca | /etc/mysql/certs/ca-cert.pem || ssl_capath | || ssl_cert | /etc/mysql/certs/server-cert.pem || ssl_cipher | || ssl_crl | || ssl_crlpath | || ssl_key | /etc/mysql/certs/server-key.pem || версия_ssl_library | OpenSSL 1.1.1 11 септември 2018 г. |+---------------------+------------------- ---------------+10 реда в комплект (0,001 сек)
Сега нека създадем потребител с параметъра REQUIRE SSL, за да го използва:
MariaDB [(none)]> ПРЕДОСТАВЯТЕ ВСИЧКИ ПРИВИЛЕГИИ НА *.* НА 's9s'@'%' ИДЕНТИФИЦИРАНА ОТ 'root123' ИЗИСКВА SSL; Заявката ОК, 0 засегнати реда (0,005 сек)
Ако използвате този потребител за достъп до базата данни и проверите командата status, ще видите, че се използва SSL:
MariaDB [(няма)]> status--------------mysql версия 15.1 Distrib 10.4.13-MariaDB, за debian-linux-gnu (x86_64) с помощта на readline 5.2 Идентификатор на връзката:15Текуща база данни:Текущ потребител:[email protected]:Използваният шифър е TLS_AES_256_GCM_SHA384Текущ пейджър:stdoutUsing outfile:''Използване на разделител:;Сървър:MariaDBServer версия:10.4.4.13:13.4.4.13.13. bionic-log mariadb.org binary distributionProtocol версия:10Връзка:127.0.0.1 чрез TCP/IPServer набор от символи:latin1Db набор от символи:latin1Client характерен набор:utf8Conn. набор от символи:utf8TCP порт:3306Uptime:16 сек. Нишки:11 Въпроси:136 Бавни заявки:0 Отваряния:17 Изтриване на таблици:1 Отворени таблици:11 Средно заявки в секунда:8.500--------------
Как да активирате SSL криптиране с ClusterControl
Друг и дори по-лесен начин за активиране на SSL във вашата база данни MariaDB е чрез ClusterControl. Ще приемем, че имате инсталиран ClusterControl и управлявате своята база данни MariaDB, като я използвате, така че отидете на ClusterControl -> Изберете вашия MariaDB Cluster -> Security -> SSL Encryption -> Enable.
И това е всичко, ще имате активирано вашето SSL криптиране във вашата база данни MariaDB без никакви ръчни задачи.
Ограничения за криптиране в покой в MariaDB
Има някои ограничения, свързани с криптирането на MariaDB в покой, които трябва да се вземат предвид:
- Метаданните (например .frm файлове) и данните, изпратени до клиента, не са криптирани.
- Само сървърът на MariaDB знае как да дешифрира данните, по-специално
- mysqlbinlog може да чете криптирани двоични регистрационни файлове само когато се използва --read-from-remote-server.
- Percona XtraBackup не може да архивира екземпляри, които използват криптиран InnoDB. Въпреки това, Mariabackup може да архивира криптирани екземпляри.
- Базираният на диск Galera gcache не е криптиран в общностната версия на MariaDB Server, но този файл е криптиран в MariaDB Enterprise Server 10.4.
- Приставката Audit не може да създава криптиран изход. Изпратете го в syslog и вместо това конфигурирайте защитата там.
- Базираният на файлове общ регистър на заявките и дневник на бавните заявки не могат да бъдат криптирани.
- Регистърът на Aria не е криптиран. Това засяга само невременните таблици Aria.
- Регистърът за грешки на MariaDB не е криптиран. Регистърът на грешките може да съдържа текст на заявка и данни в някои случаи, включително сривове, неуспехи на твърдения и случаи, когато InnoDB/XtraDB записва изход на монитора в дневника, за да помогне при отстраняване на грешки. Може да се изпрати и в системния журнал, ако е необходимо.
Заключение
Защитата на данни в пренос е също толкова важна, колкото и защитата на данните в покой и дори да не е задължителна във вашата организация, трябва да помислите за прилагането й, тъй като може да ви помогне да избегнете данни кражба или неоторизиран достъп.
MariaDB има доста лесен начин да го приложи, следвайки стъпките, споменати по-рано, но със сигурност е още по-лесно да използвате ClusterControl.
