В този блог представяме начин да преместите съществуваща база данни първо в криптирано състояние и след това как да преместите базата си данни в некриптирано състояние.
За да използвате криптиране, трябва да заредите плъгин за управление на ключовете за криптиране. Вижте поддържаните в момента плъгини за криптиране. Всеки ключ използва 32-битово цяло число като идентификатор на ключ (key_id) и действителен ключ. Ключовете могат да бъдат версии, така че данните да се криптират отново от по-стар ключ към по-нова версия на ключа. В този блог ще използваме плъгин за управление на файлови ключове като пример (вижте управление на ключове за криптиране). Предполагаме също, че използвате най-новата версия на MariaDB Server (този блог предполага, че MDEV-15566 е фиксиран, т.е. версията на MariaDB трябва да е 10.1.33, 10.2.15 или 10.3.6).
Преместването на база данни в криптирано състояние или в некриптирано състояние се извършва с помощта на завъртане на ключ. Завъртането на ключовете премества базата данни от съществуващо криптирано състояние в друго. Имайте предвид, че тук пространството за таблици може да няма криптирано състояние (т.е. пространството за таблици е некриптирано) или пространството за таблици може да има състояние на криптиране, което се премества в некриптирано състояние. Редуването на ключовете може да се случва периодично (въз основа на конфигурационната променлива innodb-encryption-rotate-key-age т.е. колко стар ключ може да бъде преди да се завърти), поискано от администратора на базата данни (например чрез издаване на set global innodb_encrypt_tables=ON; ) или чрез система за управление на ключовете за криптиране (вижте например завъртане на ключове).
Администраторите на бази данни трябва да вземат решение дали е достатъчно да криптират само отделни таблици (вижте криптиране на данни за InnoDB) или цялата база данни, включително системното пространство за таблици. Обърнете внимание, че данните от таблицата също се записват в дневника за повторение и отмяна. По този начин, ако базата данни съдържа таблици, които съдържат много чувствителни данни innodb-encrypt-log също трябва да бъде активирана. В този блог показваме как да криптирате цялата база данни.
Преместване на базата данни в криптирано състояние
Преди базата данни да може да бъде преместена в криптирано състояние, трябва да добавим конфигурация на плъгин за криптиране към конфигурационния файл (вижте подробно описание на параметрите):
# File Key Management
plugin-load-add = file_key_management
file-key-management-filename = /mnt/flash/keys.txt
file-key-management-encryption-algorithm = aes_ctr
# InnoDB encryption setup
innodb-encrypt-tables=ON
innodb-encrypt-log=ON
innodb-encryption-rotate-key-age=1024
innodb-encryption-threads=4
innodb-tablespaces-encryption
След рестартиране напредъкът на операцията по криптиране може да се наблюдава от таблица INFORMATION_SCHEMA.INNODB_TABLESPACES_ENCRYPTION. В следващия пример ние правим заявка за име на пространството за таблици, текущата страница под завъртане на ключове и максималната страница в пространството за таблици за тези таблици, които все още не са криптирани:
MariaDB [(none)]> select name, KEY_ROTATION_PAGE_NUMBER, KEY_ROTATION_MAX_PAGE_NUMBER from information_schema.innodb_tablespaces_encryption where min_key_version = 0 or ROTATING_OR_FLUSHING = 1;
+---------------+--------------------------+------------------------------+
| name | KEY_ROTATION_PAGE_NUMBER | KEY_ROTATION_MAX_PAGE_NUMBER |
+---------------+--------------------------+------------------------------+
| innodb_system | 17641 | 1397504 |
+---------------+--------------------------+------------------------------+
1 row in set (0.000 sec)
Естествено, можете също да потърсите състоянието на всички таблици:
MariaDB [tpcc1000]> select * from information_schema.innodb_tablespaces_encryption;
+-------+-------------------+-------------------+--------------------+-----------------+---------------------+--------------------------+------------------------------+----------------+----------------------+
| SPACE | NAME | ENCRYPTION_SCHEME | KEYSERVER_REQUESTS | MIN_KEY_VERSION | CURRENT_KEY_VERSION | KEY_ROTATION_PAGE_NUMBER | KEY_ROTATION_MAX_PAGE_NUMBER | CURRENT_KEY_ID | ROTATING_OR_FLUSHING |
+-------+-------------------+-------------------+--------------------+-----------------+---------------------+--------------------------+------------------------------+----------------+----------------------+
| 0 | innodb_system | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 3 | tpcc1000/customer | 1 | 1 | 0 | 1 | 2401 | 1317888 | 1 | 1 |
+-------+-------------------+-------------------+--------------------+-----------------+---------------------+--------------------------+------------------------------+----------------+----------------------+
2 rows in set (0.000 sec)
От това можем да видим, че системното таблично пространство вече е криптирано, но клиентът на таблицата от базата данни tpcc1000 в момента се криптира. Ако вашата система има хардуерни ресурси и процесът на криптиране изглежда бавен, можете да опитате следните параметри:
# Set close to number of cores
set global innodb_encryption_threads=16;
# For SSD increase number of I/O operations used for encryption in second
set global innodb_encryption_rotation_iops=40000;
Шифроването на базата данни приключва, когато няма таблици в некриптирано състояние:
MariaDB [tpcc1000]> select name, KEY_ROTATION_PAGE_NUMBER, KEY_ROTATION_MAX_PAGE_NUMBER from information_schema.innodb_tablespaces_encryption where min_key_version = 0 or ROTATING_OR_FLUSHING = 1;
Empty set (0.001 sec)
И за да проверите, избройте всички криптирани таблици:
MariaDB [tpcc1000]> select * from information_schema.innodb_tablespaces_encryption where min_key_version != 0;
+-------+---------------------+-------------------+--------------------+-----------------+---------------------+--------------------------+------------------------------+----------------+----------------------+
| SPACE | NAME | ENCRYPTION_SCHEME | KEYSERVER_REQUESTS | MIN_KEY_VERSION | CURRENT_KEY_VERSION | KEY_ROTATION_PAGE_NUMBER | KEY_ROTATION_MAX_PAGE_NUMBER | CURRENT_KEY_ID | ROTATING_OR_FLUSHING |
+-------+---------------------+-------------------+--------------------+-----------------+---------------------+--------------------------+------------------------------+----------------+----------------------+
| 0 | innodb_system | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 3 | tpcc1000/customer | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 2 | tpcc1000/district | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 4 | tpcc1000/history | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 8 | tpcc1000/item | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 5 | tpcc1000/new_orders | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 7 | tpcc1000/order_line | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 6 | tpcc1000/orders | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 9 | tpcc1000/stock | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 1 | tpcc1000/warehouse | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
+-------+---------------------+-------------------+--------------------+-----------------+---------------------+--------------------------+------------------------------+----------------+----------------------+
10 rows in set (0.000 sec)
Както се вижда, всички пространства за таблици използват ENCRYPTION_SCHEME=1 (криптирано) и MIN_KEY_VERSION=1 . След тази фаза администраторът на базата данни трябва да обмисли намаляване на броя на използваните нишки за криптиране и ротационни операции. Освен това трябва да се има предвид и необходимостта от по-нататъшна ротация на ключове, тъй като плъгинът за управление на файлови ключове не поддържа реална ротация на ключове. Завъртането на ключовете може да бъде деактивирано чрез innodb-encryption-rotate-key-age=0 . Имайте предвид, че дори при тази настройка всички създадени нови таблици се считат за криптирани.
Преместване на базата данни в нешифровано състояние
Тук предполагаме, че имате база данни, която е криптирана и вече няма нужда от криптиране на данни или защитата на данните се извършва по различен начин. Ще използваме същата база данни като пример като при преместване на база данни в криптирано състояние. В този момент няма нужда от рестартиране на сървъра. Вместо това преместването на базата данни в некриптирано състояние може да се извърши като онлайн операция. Първо, администраторът на базата данни трябва да провери дали няма таблици, използващи изрично криптиране, т.е. има таблица, в която създаването на таблица използва опцията ENCRYPTED=YES table. Сега преместването на базата данни в некриптирано състояние може да стане лесно чрез издаване на:
SET GLOBAL innodb_encrypt_tables=OFF;
Това ще започне да дешифрира всички пространства за таблици, включително системното пространство за таблици и прогресът на тази операция може да се наблюдава от:
MariaDB [tpcc1000]> select * from information_schema.innodb_tablespaces_encryption where min_key_version != 0;
+-------+---------------------+-------------------+--------------------+-----------------+---------------------+--------------------------+------------------------------+----------------+----------------------+
| SPACE | NAME | ENCRYPTION_SCHEME | KEYSERVER_REQUESTS | MIN_KEY_VERSION | CURRENT_KEY_VERSION | KEY_ROTATION_PAGE_NUMBER | KEY_ROTATION_MAX_PAGE_NUMBER | CURRENT_KEY_ID | ROTATING_OR_FLUSHING |
+-------+---------------------+-------------------+--------------------+-----------------+---------------------+--------------------------+------------------------------+----------------+----------------------+
| 7 | tpcc1000/order_line | 1 | 1 | 1 | 1 | 76564 | 1947904 | 1 | 1 |
| 6 | tpcc1000/orders | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 9 | tpcc1000/stock | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 1 | tpcc1000/warehouse | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 10 | tpcc1000/t1 | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
+-------+---------------------+-------------------+--------------------+-----------------+---------------------+--------------------------+------------------------------+----------------+----------------------+
5 rows in set (0.001 sec)
От това можем да видим, че таблицата order_line от базата данни tpcc1000 се завърта. Операцията приключва, когато няма таблици, използващи криптиране, т.е. имат min_key_version !=0.
MariaDB [tpcc1000]> select * from information_schema.innodb_tablespaces_encryption where min_key_version != 0 or rotating_or_flushing = 1;
Empty set (0.000 sec)
Ако настройката за криптиране трябва да бъде премахната от конфигурацията, сега е моментът за изключване на сървъра. Ако конфигурацията използва криптиране на регистрационния файл за повторно изпълнение, т.е. innodb-encrypt-log=ON вземете резервни копия от вашата база данни, включително InnoDB регистрационни файлове и след това премахнете регистрационните файлове на InnoDB, тъй като те са неизползваеми, ако съдържат криптирани данни.
rm -rf ib_logfile*
Премахнете настройката за криптиране от конфигурацията и рестартирайте сървъра. Сега имате екземпляр на база данни, в който не се използва криптиране.
Заключение
Преместването на база данни в криптирано състояние, както се вижда по-горе, изисква сървърът да бъде рестартиран и изисква внимателна конфигурация на плъгин за криптиране. Колко време отнема тази операция зависи от броя на масите и колко големи са тези таблици. Представихме начин за наблюдение на този напредък и как да го ускорим, ако използваният хардуер има достатъчно ресурси. Преместването на база данни в некриптирано състояние изисква само задаване на една глобална променлива. Въпреки това, ако криптирането е необходимо по-дълго и има нужда да се премахнат всички препратки към него, има нужда от едно рестартиране. Показахме как да наблюдаваме този преход и как напълно да премахнем настройката за криптиране както от базата данни, така и от конфигурацията.
