In questo blog, presentiamo un modo per spostare un database esistente prima in uno stato crittografato e poi come spostare il database in uno stato non crittografato.
Per utilizzare la crittografia, è necessario caricare un plug-in per gestire le chiavi di crittografia. Vedi i plugin di crittografia attualmente supportati. Ogni chiave utilizza un numero intero a 32 bit come identificatore di chiave (key_id) e chiave effettiva. È possibile eseguire la versione delle chiavi in modo che i dati vengano nuovamente crittografati dalla chiave precedente alla versione più recente della chiave. In questo blog utilizzeremo come esempio il plug-in per la gestione delle chiavi di file (vedi gestione delle chiavi di crittografia). Presumiamo inoltre che tu stia utilizzando la versione più recente di MariaDB Server (questo blog presume che MDEV-15566 sia corretto, ovvero la versione di MariaDB dovrebbe essere 10.1.33, 10.2.15 o 10.3.6).
Lo spostamento di un database in uno stato crittografato o in uno stato non crittografato viene eseguito utilizzando una key_rotation. La rotazione delle chiavi sposta il database da uno stato crittografato esistente a un altro. Si noti che qui il tablespace potrebbe non avere uno stato crittografato (ad esempio, il tablespace non è crittografato) o il tablespace potrebbe avere uno stato di crittografia che viene spostato in uno stato non crittografato. La rotazione delle chiavi può avvenire periodicamente (in base alla variabile di configurazione innodb-encryption-rotate-key-age cioè quanti anni può avere la chiave prima che venga ruotata), richiesta dall'amministratore del database (ad es. emettendo set global innodb_encrypt_tables=ON; ) o tramite il sistema di gestione delle chiavi di crittografia (vedi ad es. rotazione delle chiavi).
Gli amministratori del database devono decidere se è sufficiente crittografare solo singole tabelle (vedi crittografia dei dati per InnoDB) o l'intero database incluso il tablespace di sistema. Si noti che i dati della tabella vengono scritti anche per ripetere il registro e annullare il registro. Pertanto, se il database contiene tabelle che contengono dati molto sensibili innodb-encrypt-log dovrebbe anche essere abilitato. In questo blog mostriamo come crittografare l'intero database.
Spostamento del database in stato crittografato
Prima che il database possa essere spostato in uno stato crittografato, è necessario aggiungere la configurazione del plug-in di crittografia al file di configurazione (vedere la descrizione dettagliata sui parametri):
# 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
Dopo il riavvio, è possibile monitorare l'avanzamento dell'operazione di crittografia dalla tabella INFORMATION_SCHEMA.INNODB_TABLESPACES_ENCRYPTION. Nell'esempio seguente, interroghiamo il nome del tablespace, la pagina corrente sotto rotazione chiave e la pagina massima nel tablespace per le tabelle che non sono ancora crittografate:
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)
Naturalmente, puoi anche interrogare lo stato di tutte le tabelle:
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)
Da questo possiamo vedere che il tablespace di sistema è già crittografato ma il cliente della tabella dal database tpcc1000 è attualmente crittografato. Se il tuo sistema ha risorse hardware e il processo di crittografia sembra lento, puoi provare i seguenti parametri:
# 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;
La crittografia del database è terminata quando non sono presenti tabelle in uno stato non crittografato:
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)
E per verificare, elenca tutte le tabelle crittografate:
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)
Come si può vedere, tutti i tablespace utilizzano ENCRYPTION_SCHEME=1 (crittografato) e MIN_KEY_VERSION=1 . Dopo questa fase, l'amministratore del database dovrebbe considerare di ridurre il numero di thread di crittografia utilizzati e di rotazione iops. Inoltre, dovrebbe essere considerata anche la necessità di un'ulteriore rotazione delle chiavi poiché il plug-in di gestione delle chiavi dei file non supporta la rotazione delle chiavi reale. La rotazione delle chiavi può essere disabilitata utilizzando innodb-encryption-rotate-key-age=0 . Nota che anche con quella configurazione tutte le nuove tabelle create vengono prese in considerazione per la crittografia.
Spostamento del database in stato non crittografato
Qui assumiamo che tu abbia un database crittografato e che non sia più necessario crittografare i dati o che la protezione dei dati venga eseguita in modo diverso. Utilizzeremo lo stesso database come esempio per lo spostamento del database nello stato crittografato. A questo punto non è necessario riavviare il server. Invece lo spostamento del database in uno stato non crittografato può essere eseguito come un'operazione online. In primo luogo, l'amministratore del database dovrebbe verificare che non ci siano tabelle che utilizzano la crittografia esplicita, ad esempio esiste una tabella in cui crea una tabella ha utilizzato l'opzione tabella ENCRYPTED=YES. Ora è possibile spostare il database in uno stato non crittografato emettendo:
SET GLOBAL innodb_encrypt_tables=OFF;
Questo avvierà la decrittografia di tutti i tablespace, incluso il tablespace di sistema e lo stato di avanzamento di questa operazione può essere monitorato da:
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)
Da questo possiamo vedere che la tabella order_line dal database tpcc1000 viene ruotata. L'operazione è terminata quando non ci sono tabelle che utilizzano la crittografia, ad esempio hanno 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)
Se l'impostazione della crittografia deve essere rimossa dalla configurazione, ora è il momento di spegnere il server. Se la configurazione utilizza la crittografia del log di ripristino, ad esempio innodb-encrypt-log=ON esegui backup dal tuo database inclusi i file di registro InnoDB e successivamente rimuovi i file di registro InnoDB poiché sono inutilizzabili se contengono dati crittografati.
rm -rf ib_logfile*
Rimuovere l'impostazione della crittografia dalla configurazione e riavviare il server. Ora hai un'istanza di database in cui non viene utilizzata la crittografia.
Conclusione
Lo spostamento di un database in uno stato crittografato come visto sopra richiede il riavvio del server e un'attenta configurazione del plug-in di crittografia. La durata di questa operazione dipende dal numero di tabelle e dalle dimensioni di queste tabelle. Abbiamo presentato un modo per monitorare questo progresso e come accelerarlo se l'hardware utilizzato dispone di risorse sufficienti. Lo spostamento di un database in uno stato non crittografato richiede solo l'impostazione di una variabile globale. Tuttavia, se la crittografia è più necessaria ed è necessario rimuovere tutti i riferimenti ad essa, è necessario un riavvio. Abbiamo mostrato come monitorare questa transizione e come rimuovere completamente l'impostazione della crittografia sia dal database che dalla configurazione.
