I denne blog præsenterer vi en måde at flytte en eksisterende database først til en krypteret tilstand og derefter, hvordan du flytter din database til en ukrypteret tilstand.
For at bruge kryptering skal du indlæse et plugin til at administrere krypteringsnøglerne. Se aktuelt understøttede krypteringsplugins. Hver nøgle bruger et 32-bit heltal som nøgleidentifikator (key_id) og faktisk nøgle. Nøgler kan versioneres, så data genkrypteres fra ældre nøgle til nyere version af nøglen. I denne blog vil vi bruge plugin til filnøglestyring som et eksempel (se håndtering af krypteringsnøgler). Vi antager også, at du bruger den seneste version af MariaDB Server (denne blog forudsætter, at MDEV-15566 er rettet, dvs. MariaDB-versionen skal være 10.1.33, 10.2.15 eller 10.3.6).
Flytning af en database til en krypteret tilstand eller til en ukrypteret tilstand udføres ved hjælp af en nøglerotation. Nøglerotation flytter databasen fra en eksisterende krypteret tilstand til en anden. Bemærk, at her kunne tablespace ikke have nogen krypteret tilstand (dvs. tablespace er ukrypteret), eller tablespace kan have en krypteringstilstand, der flyttes til en ukrypteret tilstand. Nøglerotation kan ske periodisk (baseret på konfigurationsvariablen innodb-encryption-rotate-key-age dvs. hvor gammel nøgle kan være, før den roteres), anmodet af databaseadministrator (f.eks. ved at udstede set global innodb_encrypt_tables=ON; ) eller ved hjælp af krypteringsnøglestyringssystem (se f.eks. roter nøgler).
Databaseadministratorer skal træffe beslutningen, om det er nok kun at kryptere individuelle tabeller (se kryptering af data for InnoDB) eller hele databasen inklusive systemtablespace. Bemærk, at tabeldata også skrives til at gentage log og fortryde log. Således, hvis databasen indeholder tabeller, der indeholder meget følsomme data innodb-encrypt-log skal også være aktiveret. I denne blog viser vi, hvordan man krypterer hele databasen.
Flytter database til krypteret tilstand
Før databasen kan flyttes til en krypteret tilstand, skal vi tilføje en krypteringsplugin-konfiguration til konfigurationsfilen (se detaljeret beskrivelse af parametre):
# 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
Efter genstart kan fremskridt for krypteringsoperationen overvåges fra tabellen INFORMATION_SCHEMA.INNODB_TABLESPACES_ENCRYPTION. I det følgende eksempel forespørger vi navnet på tablespacet, den aktuelle side under nøglerotation og den maksimale side i tablespacet for de tabeller, der endnu ikke er krypteret:
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)
Du kan naturligvis også forespørge om status for alle tabeller:
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)
Fra dette kan vi se, at systemtablespace allerede er krypteret, men tabelkunde fra databasen tpcc1000 krypteres i øjeblikket. Hvis dit system har hardwareressourcer, og krypteringsprocessen virker langsom, kan du prøve følgende parametre:
# 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;
Databasekryptering er færdig, når der ikke er nogen tabeller i ukrypteret tilstand:
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)
Og for at bekræfte, skal du liste alle tabeller, der er krypteret:
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)
Som det kan ses, bruger alle tablespaces ENCRYPTION_SCHEME=1 (krypteret) og MIN_KEY_VERSION=1 . Efter denne fase bør databaseadministratoren overveje at reducere antallet af brugte krypteringstråde og rotation iops. Desuden bør behovet for yderligere nøglerotation også overvejes, da filnøglestyringsplugin'et ikke understøtter reel nøglerotation. Nøglerotation kan deaktiveres ved hjælp af innodb-encryption-rotate-key-age=0 . Bemærk, at selv med den opsætning betragtes alle nye tabeller, der oprettes, for kryptering.
Flytter database til ukrypteret tilstand
Her går vi ud fra, at du har en database, der er krypteret, og der ikke længere er behov for at kryptere data, eller databeskyttelsen gøres anderledes. Vi vil bruge den samme database som et eksempel som ved at flytte databasen til krypteret tilstand. På dette tidspunkt er det ikke nødvendigt at genstarte serveren. Flytning af databasen til ukrypteret tilstand kan i stedet udføres som en online operation. For det første bør databaseadministratoren kontrollere, at der ikke er nogen tabeller, der bruger eksplicit kryptering, dvs. der er en tabel, hvor der er oprettet tabel, der bruges ENCRYPTED=YES tabelmulighed. Nu kan det nemt gøres at flytte databasen til en ukrypteret tilstand ved at udstede:
SET GLOBAL innodb_encrypt_tables=OFF;
Dette vil begynde at ukryptere alle tablespaces inklusive system tablespace, og forløbet af denne operation kan overvåges af:
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)
Ud fra dette kan vi se, at tabellen order_line fra databasen tpcc1000 bliver roteret. Operationen er afsluttet, når der ikke er nogen tabeller, der bruger kryptering, dvs. har 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)
Hvis krypteringsopsætningen skal fjernes fra konfigurationen, er det nu, du skal lukke serveren ned. Hvis konfigurationen bruger gentag logkryptering, dvs. innodb-encrypt-log=ON tag sikkerhedskopier fra din database, inklusive InnoDB-logfiler, og fjern derefter InnoDB-logfiler, da de er ubrugelige, hvis de indeholder krypterede data.
rm -rf ib_logfile*
Fjern krypteringsopsætningen fra konfigurationen og genstart serveren. Nu har du en databaseinstans, hvor der ikke bruges kryptering.
Konklusion
At flytte en database til en krypteret tilstand som set ovenfor kræver, at serveren genstartes og kræver en omhyggelig konfiguration af krypteringsplugin. Hvor lang tid denne operation tager afhænger af antallet af borde og hvor store disse borde er. Vi har præsenteret en måde at overvåge dette fremskridt på, og hvordan man kan fremskynde det, hvis den anvendte hardware har tilstrækkelige ressourcer. At flytte en database til en ukrypteret tilstand kræver kun indstilling af én global variabel. Men hvis kryptering er på længere nødvendig, og der er behov for at fjerne alle referencer til den, er der behov for én genstart. Vi har vist, hvordan man overvåger denne overgang, og hvordan man fjerner krypteringsopsætningen fuldstændigt fra både databasen og konfigurationen.