W tym blogu przedstawiamy sposób przeniesienia istniejącej bazy danych najpierw do stanu zaszyfrowanego, a następnie, jak przenieść bazę danych do stanu niezaszyfrowanego.
Aby korzystać z szyfrowania, musisz załadować wtyczkę do zarządzania kluczami szyfrowania. Zobacz aktualnie obsługiwane wtyczki szyfrowania. Każdy klucz używa 32-bitowej liczby całkowitej jako identyfikatora klucza (key_id) i rzeczywistego klucza. Klucze można wersjonować, aby dane były ponownie szyfrowane ze starszego klucza do nowszej wersji klucza. W tym blogu użyjemy wtyczki do zarządzania kluczami plików jako przykładu (patrz Zarządzanie kluczami szyfrowania). Zakładamy również, że używasz najnowszej wersji MariaDB Server (w tym blogu założono, że MDEV-15566 jest naprawiony, tzn. wersja MariaDB powinna być 10.1.33, 10.2.15 lub 10.3.6).
Przenoszenie bazy danych do stanu zaszyfrowanego lub niezaszyfrowanego odbywa się za pomocą key_rotation. Rotacja kluczy przenosi bazę danych z istniejącego stanu zaszyfrowania do innego. Zauważ, że tutaj obszar tabel może nie mieć stanu zaszyfrowanego (tj. Obszar tabel jest niezaszyfrowany) lub obszar tabel może mieć stan szyfrowania, który jest przenoszony do stanu niezaszyfrowanego. Rotacja kluczy może odbywać się okresowo (na podstawie zmiennej konfiguracyjnej innodb-encryption-rotate-key-age tj. jak stary może być klucz przed jego rotacją), o który poprosił administrator bazy danych (np. wydając set global innodb_encrypt_tables=ON; ) lub przez system zarządzania kluczami szyfrowania (patrz np. rotacja kluczy).
Administratorzy baz danych muszą podjąć decyzję, czy wystarczy zaszyfrować tylko pojedyncze tabele (zobacz szyfrowanie danych dla InnoDB), czy całą bazę danych, w tym systemowy obszar tabel. Zwróć uwagę, że dane tabeli są również zapisywane w celu ponownego rejestrowania i cofania rejestrowania. Tak więc, jeśli baza danych zawiera tabele zawierające bardzo wrażliwe dane innodb-encrypt-log powinna być również włączona. W tym blogu pokazujemy, jak zaszyfrować całą bazę danych.
Przenoszenie bazy danych do stanu zaszyfrowanego
Zanim baza danych zostanie przeniesiona do stanu zaszyfrowania, musimy dodać konfigurację wtyczki szyfrującej do pliku konfiguracyjnego (patrz szczegółowy opis parametrów):
# 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
Po ponownym uruchomieniu postęp operacji szyfrowania można monitorować z tabeli INFORMATION_SCHEMA.INNODB_TABLESPACES_ENCRYPTION. W poniższym przykładzie zapytamy o nazwę obszaru tabel, bieżącą stronę pod rotacją kluczy i maksymalną stronę w obszarze tabel dla tych tabel, które nie są jeszcze zaszyfrowane:
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)
Oczywiście możesz również zapytać o stan wszystkich tabel:
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)
Z tego widać, że obszar tabel systemowych jest już zaszyfrowany, ale klient tabeli z bazy danych tpcc1000 jest obecnie szyfrowany. Jeśli Twój system ma zasoby sprzętowe, a proces szyfrowania wydaje się powolny, możesz wypróbować następujące parametry:
# 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;
Szyfrowanie bazy danych kończy się, gdy nie ma tabel w stanie niezaszyfrowanym:
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)
Aby to zweryfikować, wypisz wszystkie zaszyfrowane tabele:
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)
Jak widać, wszystkie przestrzenie tabel używają ENCRYPTION_SCHEME=1 (zaszyfrowane) i MIN_KEY_VERSION=1 . Po tej fazie administrator bazy danych powinien rozważyć zmniejszenie liczby używanych wątków szyfrujących i rotacji iopów. Ponadto należy również wziąć pod uwagę potrzebę dalszej rotacji kluczy, ponieważ wtyczka do zarządzania kluczami plików nie obsługuje prawdziwej rotacji kluczy. Rotację kluczy można wyłączyć za pomocą innodb-encryption-rotate-key-age=0 . Pamiętaj, że nawet przy tej konfiguracji wszystkie nowo utworzone tabele są brane pod uwagę do szyfrowania.
Przenoszenie bazy danych do stanu niezaszyfrowanego
Tutaj zakładamy, że masz zaszyfrowaną bazę danych i nie ma już potrzeby szyfrowania danych lub ochrona danych odbywa się w inny sposób. Użyjemy tej samej bazy danych jako przykładu, jak przy przenoszeniu bazy danych do stanu zaszyfrowanego. W tym momencie nie ma potrzeby restartowania serwera. Zamiast tego przeniesienie bazy danych do stanu niezaszyfrowanego można wykonać jako operację online. Najpierw administrator bazy danych powinien sprawdzić, czy nie ma tabel używających jawnego szyfrowania, tj. istnieje tabela, w której utwórz tabelę użyto opcji tabeli ENCRYPTED=YES. Teraz przeniesienie bazy danych do stanu niezaszyfrowanego można łatwo wykonać, wydając:
SET GLOBAL innodb_encrypt_tables=OFF;
Rozpocznie się odszyfrowywanie wszystkich obszarów tabel, w tym obszaru tabel systemowych, a postęp tej operacji może być monitorowany przez:
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)
Z tego widać, że tabela order_line z bazy danych tpcc1000 jest obracana. Operacja kończy się, gdy nie ma tabel korzystających z szyfrowania, tj. mają 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)
Jeśli konfiguracja szyfrowania musi zostać usunięta z konfiguracji, teraz nadszedł czas, aby zamknąć serwer. Jeśli konfiguracja używa ponownego szyfrowania dziennika, tj. innodb-encrypt-log=ON weź kopie zapasowe z bazy danych, w tym pliki dziennika InnoDB, a następnie usuń pliki dziennika InnoDB, ponieważ nie nadają się do użytku, jeśli zawierają zaszyfrowane dane.
rm -rf ib_logfile*
Usuń konfigurację szyfrowania z konfiguracji i uruchom ponownie serwer. Teraz masz instancję bazy danych, w której nie jest używane szyfrowanie.
Wniosek
Przeniesienie bazy danych do stanu zaszyfrowanego, jak pokazano powyżej, wymaga ponownego uruchomienia serwera i starannej konfiguracji wtyczki szyfrującej. Czas trwania tej operacji zależy od liczby stołów i wielkości tych stołów. Przedstawiliśmy sposób monitorowania tego postępu i przyspieszenia go, jeśli używany sprzęt ma wystarczające zasoby. Przeniesienie bazy danych do stanu niezaszyfrowanego wymaga ustawienia tylko jednej zmiennej globalnej. Jeśli jednak szyfrowanie jest już potrzebne i istnieje potrzeba usunięcia wszystkich odniesień do niego, konieczne jest jednokrotne ponowne uruchomienie. Pokazaliśmy, jak monitorować to przejście i jak całkowicie usunąć konfigurację szyfrowania zarówno z bazy danych, jak i konfiguracji.
