最大限のデータ保護のための完全なMariaDB暗号化の保管中および転送中-パート2-

このシリーズの最初のパートでは、MariaDBレプリケーションサーバーの転送中の暗号化構成について説明しました。ここでは、クライアントサーバーとレプリケーションの暗号化を構成しました。完全な暗号化を部分的に構成した最初の投稿（図の左側にある緑色の矢印で示されている）から取得し、このブログ投稿では、保存時の暗号化を使用して暗号化のセットアップを完了し、完全に暗号化されたMariaDBレプリケーションのセットアップ。

次の図は、現在の設定とこれから達成する最終設定を示しています。

静止暗号化

保存データの暗号化とは、保存データのようなデータファイルやログがディスク上で暗号化されることを意味し、誰かがハードディスクにアクセスしたり盗んだりして元のデータにアクセスすることをほぼ不可能にします。（キーが保護されており、ローカルに保存されていない場合）。トランスペアレントデータ暗号化（TDE）とも呼ばれる保存データ暗号化は、MariaDB10.1以降でサポートされています。暗号化を使用すると、ワークロードとクラスタータイプに応じて、約5〜10％のオーバーヘッドが発生することに注意してください。

MariaDBの場合、次のMariaDBコンポーネントを保存時に暗号化できます。

InnoDBデータファイル（共有テーブルスペースまたは個別のテーブルスペース、たとえば* .ibdおよびibdata1）
Ariaデータとインデックスファイル。
ログの取り消し/やり直し（InnoDBログファイル（ib_logfile0やib_logfile1など））
バイナリ/リレーログ。
一時ファイルとテーブル。

現在、次のファイルは暗号化できません：

メタデータファイル（たとえば、.frmファイル）。
ファイルベースの一般ログ/低速クエリログ。テーブルベースの一般ログ/低速クエリログは暗号化できます。
エラーログ。

MariaDBの保存データの暗号化には、キー管理と暗号化プラグインを使用する必要があります。このブログ投稿では、MariaDB10.1.3以降にデフォルトで提供されているファイルキー管理暗号化プラグインを使用します。このプラグインを使用すると、いくつかの欠点があることに注意してください。たとえば、MariaDBの保存データの暗号化ページで説明されているように、rootおよびMySQLユーザーがキーを読み取ることができます。

キーファイルの生成

保存中の暗号化を保存するための専用ディレクトリを作成しましょう：

$ mkdir -p /etc/mysql/rest
$ cd /etc/mysql/rest

キーファイルを作成します。これが暗号化の中核です：

$ openssl rand -hex 32 > /etc/mysql/rest/keyfile

文字列「1;」を追加しますキーファイルへのキー識別子として：

$ echo '1;' 
sed -i '1s/^/1;/' /etc/mysql/rest/keyfile

したがって、キーファイルを読み取ると、次のようになります。

$ cat /etc/mysql/rest/keyfile
1;4eb5770dcfa691bc634cbcd3c6bed9ed4ccd0111f3d3b1dae2c51a90fbf16ed7

上記は単にキー識別子1を意味し、キーは4ebです...キーファイルには、暗号化キーごとに2つの情報が含まれている必要があります。まず、各暗号化キーは、キー識別子として32ビット整数で識別される必要があります。次に、暗号化キー自体を16進暗号化形式で提供する必要があります。これらの2つの情報は、セミコロンで区切る必要があります。

上記のキーを暗号化するためのパスワードを作成します。ここでは、「keyfile.passwd」というファイル内にパスワードを保存します：

$ echo -n 'mySuperStrongPassword' > /etc/mysql/rest/keyfile.passwd

file_key_management_filekeyオプションを使用して構成ファイルで直接パスワードを指定する場合は、上記の手順をスキップできます。例：file_key_management_filekey =mySuperStrongPassword

ただし、この例では、ファイルに保存されているパスワードを読み取るため、後で構成ファイルに次の行を定義する必要があります。

file_key_management_filekey=FILE:/etc/mysql/encryption/keyfile.passwd

パスワードファイル内のパスワードを使用して、クリアテキストのキーファイルをkeyfile.encという別のファイルに暗号化します。

$  openssl enc -aes-256-cbc -md sha1 -pass file:/etc/mysql/rest/keyfile.passwd -in /etc/mysql/rest/keyfile -out /etc/mysql/rest/keyfile.enc

ディレクトリを一覧表示すると、次の3つのファイルが表示されます。

$ ls -1 /etc/mysql/rest/
keyfile
keyfile.enc
keyfile.passwd

keyfile.encのコンテンツは、単に暗号化されたバージョンのkeyfileです：

テストするには、OpenSSLを使用して暗号化されたファイルを復号化できます。パスワードファイル（keyfile.passwd）：

$ openssl aes-256-cbc -d -md sha1 -pass file:/etc/mysql/rest/keyfile.passwd -in /etc/mysql/rest/keyfile.enc
1;4eb5770dcfa691bc634cbcd3c6bed9ed4ccd0111f3d3b1dae2c51a90fbf16ed7

暗号化されたキー（.enc）をパスワードファイルと一緒に使用するため、プレーンキーを削除できます：

$ rm -f /etc/mysql/encryption/keyfile

これで、MariaDBの保存時暗号化の構成に進むことができます。

静止暗号化の構成

暗号化されたキーファイルとパスワードをスレーブに移動して、MariaDBがデータを暗号化/復号化するために使用する必要があります。そうしないと、MariaDBバックアップなどの物理バックアップを使用してマスターからバックアップされている暗号化されたテーブルで、スレーブによる読み取りに問題が発生します（キーとパスワードの組み合わせが異なるため）。 mysqldumpのような論理バックアップは、さまざまなキーとパスワードで機能するはずです。

スレーブで、保存時の暗号化を保存するディレクトリを作成します。

(slave1)$ mkdir -p /etc/mysql/rest
(slave2)$ mkdir -p /etc/mysql/rest

マスターで、暗号化されたキーファイルとパスワードファイルを他のスレーブにコピーします。

(master)$ cd /etc/mysql/rest
(master)$ scp keyfile.enc keyfile.passwd [email protected]:/etc/mysql/rest/
(master)$ scp keyfile.enc keyfile.passwd [email protected]:/etc/mysql/rest/

グローバルアクセスからファイルを保護し、所有権として「mysql」ユーザーを割り当てます：

$ chown mysql:mysql /etc/mysql/rest/*
$ chmod 600 /etc/mysql/rest/*

以下を[mysqld]または[mariadb]セクションのMariaDB構成ファイルに追加します：

# at-rest encryption
plugin_load_add              = file_key_management
file_key_management_filename = /etc/mysql/rest/keyfile.enc
file_key_management_filekey  = FILE:/etc/mysql/rest/keyfile.passwd
file_key_management_encryption_algorithm = AES_CBC

innodb_encrypt_tables            = ON
innodb_encrypt_temporary_tables  = ON
innodb_encrypt_log               = ON
innodb_encryption_threads        = 4
innodb_encryption_rotate_key_age = 1
encrypt-tmp-disk-tables          = 1
encrypt-tmp-files                = 1
encrypt-binlog                   = 1
aria_encrypt_tables              = ON

file_key_management_filekey変数に注意してください。パスワードがファイルにある場合は、パスの前に「FILE：」を付ける必要があります。または、パスワード文字列を直接指定することもできます（冗長性があるためお勧めしません）：

file_key_management_filekey=mySuperStrongPassword

スレーブから始めて、一度に1ノードずつMariaDBサーバーを再起動します。

(slave1)$ systemctl restart mariadb
(slave2)$ systemctl restart mariadb
(master)$ systemctl restart mariadb

エラーログを観察し、起動時にMariaDB暗号化がアクティブになっていることを確認します。

$ tail -f /var/log/mysql/mysqld.log
...
2019-12-17  6:44:47 0 [Note] InnoDB: Encrypting redo log: 2*67108864 bytes; LSN=143311
2019-12-17  6:44:48 0 [Note] InnoDB: Starting to delete and rewrite log files.
2019-12-17  6:44:48 0 [Note] InnoDB: Setting log file ./ib_logfile101 size to 67108864 bytes
2019-12-17  6:44:48 0 [Note] InnoDB: Setting log file ./ib_logfile1 size to 67108864 bytes
2019-12-17  6:44:48 0 [Note] InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0
2019-12-17  6:44:48 0 [Note] InnoDB: New log files created, LSN=143311
2019-12-17  6:44:48 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
2019-12-17  6:44:48 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2019-12-17  6:44:48 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2019-12-17  6:44:48 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2019-12-17  6:44:48 0 [Note] InnoDB: Waiting for purge to start
2019-12-17  6:44:48 0 [Note] InnoDB: 10.4.11 started; log sequence number 143311; transaction id 222
2019-12-17  6:44:48 0 [Note] InnoDB: Creating #1 encryption thread id 139790011840256 total threads 4.
2019-12-17  6:44:48 0 [Note] InnoDB: Creating #2 encryption thread id 139790003447552 total threads 4.
2019-12-17  6:44:48 0 [Note] InnoDB: Creating #3 encryption thread id 139789995054848 total threads 4.
2019-12-17  6:44:48 0 [Note] InnoDB: Creating #4 encryption thread id 139789709866752 total threads 4.
2019-12-17  6:44:48 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
2019-12-17  6:44:48 0 [Note] Plugin 'FEEDBACK' is disabled.
2019-12-17  6:44:48 0 [Note] Using encryption key id 1 for temporary files
...

エラーログに暗号化の初期化を示す行が表示されます。この時点で、暗号化構成の大部分が完了しています。

暗号化のテストマスターでテストするテストデータベースを作成します：

(master)MariaDB> CREATE SCHEMA sbtest;
(master)MariaDB> USE sbtest;

暗号化せずに標準テーブルを作成し、行を挿入します：

MariaDB> CREATE TABLE tbl_plain (id INT AUTO_INCREMENT PRIMARY KEY, data VARCHAR(255));
MariaDB> INSERT INTO tbl_plain SET data = 'test data';

16進ダンプツールを使用してInnoDBデータファイルを参照すると、保存されているデータをクリアテキストで表示できます。

$ xxd /var/lib/mysql/sbtest/tbl_plain.ibd | less
000c060: 0200 1c69 6e66 696d 756d 0002 000b 0000  ...infimum......
000c070: 7375 7072 656d 756d 0900 0000 10ff f180  supremum........
000c080: 0000 0100 0000 0000 0080 0000 0000 0000  ................
000c090: 7465 7374 2064 6174 6100 0000 0000 0000  test data.......
000c0a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

暗号化されたテーブルを作成し、行を挿入します：

MariaDB> CREATE TABLE tbl_enc (id INT AUTO_INCREMENT PRIMARY KEY, data VARCHAR(255)) ENCRYPTED=YES;
MariaDB> INSERT INTO tbl_enc SET data = 'test data';

暗号化されたテーブルのInnoDBデータファイルに何が保存されているかわかりません：

$ xxd /var/lib/mysql/sbtest/tbl_enc.ibd | less
000c060: 0c2c 93e4 652e 9736 e68a 8b69 39cb 6157  .,..e..6...i9.aW
000c070: 3cd1 581c 7eb9 84ca d792 7338 521f 0639  <.X.~.....s8R..9
000c080: d279 9eb3 d3f5 f9b0 eccb ed05 de16 f3ac  .y..............
000c090: 6d58 5519 f776 8577 03a4 fa88 c507 1b31  mXU..v.w.......1
000c0a0: a06f 086f 28d9 ac17 8923 9412 d8a5 1215  .o.o(....#......

メタデータファイルtbl_enc.frmは保存時に暗号化されないことに注意してください。 InnoDBデータファイル（.ibd）のみが暗号化されます。

「プレーン」なバイナリログまたはリレーログを比較すると、hexdumpツールを使用してその内容を明確に確認できます。

$ xxd binlog.000002 | less
0000560: 0800 0800 0800 0b04 726f 6f74 096c 6f63  ........root.loc
0000570: 616c 686f 7374 0047 5241 4e54 2052 454c  alhost.GRANT REL
0000580: 4f41 442c 4c4f 434b 2054 4142 4c45 532c  OAD,LOCK TABLES,
0000590: 5245 504c 4943 4154 494f 4e20 434c 4945  REPLICATION CLIE
00005a0: 4e54 2c45 5645 4e54 2c43 5245 4154 4520  NT,EVENT,CREATE
00005b0: 5441 424c 4553 5041 4345 2c50 524f 4345  TABLESPACE,PROCE
00005c0: 5353 2c43 5245 4154 452c 494e 5345 5254  SS,CREATE,INSERT
00005d0: 2c53 454c 4543 542c 5355 5045 522c 5348  ,SELECT,SUPER,SH
00005e0: 4f57 2056 4945 5720 4f4e 202a 2e2a 2054  OW VIEW ON *.* T

暗号化されたバイナリログの場合、コンテンツはぎこちなく見えます：

$ xxd binlog.000004 | less
0000280: 4a1d 1ced 2f1b db50 016a e1e9 1351 84ba  J.../..P.j...Q..
0000290: 38b6 72e7 8743 7713 afc3 eecb c36c 1b19  8.r..Cw......l..
00002a0: 7b3f 6176 208f 0000 00dc 85bf 6768 e7c6  {?av .......gh..
00002b0: 6107 5bea 241c db12 d50c 3573 48e5 3c3d  a.[.$.....5sH.<=
00002c0: 3179 1653 2449 d408 1113 3e25 d165 c95b  1y.S$I....>%.e.[
00002d0: afb0 6778 4b26 f672 1bc7 567e da96 13f5  ..gxK&.r..V~....
00002e0: 2ac5 b026 3fb9 4b7a 3ef4 ab47 6c9f a686  *..&?.Kz>..Gl...

アリアテーブルの暗号化

Ariaストレージエンジンの場合、aria_encrypt_tablesグローバルオプションに従うため、CREATE/ALTERステートメントのENCRYPTEDオプションはサポートされません。したがって、Ariaテーブルを作成するときは、ENGINE=Ariaオプションを使用してテーブルを作成するだけです。

MariaDB> CREATE TABLE tbl_aria_enc (id INT AUTO_INCREMENT PRIMARY KEY, data VARCHAR(255)) ENGINE=Aria;
MariaDB> INSERT INTO tbl_aria_enc(data) VALUES ('test data');
MariaDB> FLUSH TABLE tbl_aria_enc;

次に、16進ダンプツールを使用して、テーブルのデータファイル（tbl_aria_enc.MAD）またはインデックスファイル（tbl_aria_enc.MAI）の内容を確認できます。既存のAriaテーブルを暗号化するには、テーブルを再構築する必要があります：

MariaDB> ALTER TABLE db.aria_table ENGINE=Aria ROW_FORMAT=PAGE;

このステートメントにより、AriaはROW_FORMATテーブルオプションを使用してテーブルを再構築します。その過程で、新しいデフォルト設定を使用して、ディスクに書き込むときにテーブルを暗号化します。

一般ログ/低速クエリログの暗号化

一般的なクエリログと低速クエリログを暗号化するために、MariaDBlog_outputオプションをデフォルトの「FILE」ではなく「TABLE」に設定できます。

MariaDB> SET GLOBAL log_ouput = 'TABLE';

ただし、MariaDBはデフォルトで、MariaDBによって暗号化されていないCSVストレージエンジンを使用して必要なテーブルを作成します。ログテーブルには、CSV、MyISAM、またはAria以外のエンジンは有効ではありません。秘訣は、aria_encrypt_tablesオプションがONに設定されている場合、Ariaストレージエンジンを使用してデフォルトのCSVテーブルを再構築することです。ただし、テーブルの変更を成功させるには、それぞれのログオプションをオフにする必要があります。

したがって、一般的なログテーブルを暗号化する手順は次のとおりです。

MariaDB> SET GLOBAL general_log = OFF;
MariaDB> ALTER TABLE mysql.general_log ENGINE=Aria;
MariaDB> SET GLOBAL general_log = ON;

同様に、クエリログが遅い場合：

MariaDB> SET GLOBAL slow_query_log = OFF;
MariaDB> ALTER TABLE mysql.slow_log ENGINE=Aria;
MariaDB> SET GLOBAL slow_query_log = ON;

サーバー内の一般的なログの出力を確認します：

MariaDB> SELECT * FROM mysql.general_log;
+----------------------------+---------------------------+-----------+-----------+--------------+------------------------------+
| event_time                 | user_host                 | thread_id | server_id | command_type | argument                     |
+----------------------------+---------------------------+-----------+-----------+--------------+------------------------------+
| 2019-12-17 07:45:53.109558 | root[root] @ localhost [] |        19 |     28001 |        Query | select * from sbtest.tbl_enc |
| 2019-12-17 07:45:55.504710 | root[root] @ localhost [] |        20 |     28001 |        Query | select * from general_log    |
+----------------------------+---------------------------+-----------+-----------+--------------+------------------------------+

hexdumpツールを使用したデータディレクトリ内のAriaデータファイルの暗号化されたコンテンツ：

$ xxd /var/lib/mysql/mysql/general_log.MAD | less
0002040: 1d45 820d 7c53 216c 3fc6 98a6 356e 1b9e  .E..|S!l?...5n..
0002050: 6bfc e193 7509 1fa7 31e2 e22a 8f06 3c6f  k...u...1..*..<o
0002060: ae71 bb63 e81b 0b08 7120 0c99 9f82 7c33  .q.c....q ....|3
0002070: 1117 bc02 30c1 d9a7 c732 c75f 32a6 e238  ....0....2._2..8
0002080: d1c8 5d6f 9a08 455a 8363 b4f4 5176 f8a1  ..]o..EZ.c..Qv..
0002090: 1bf8 113c 9762 3504 737e 917b f260 f88c  ...<.b5.s~.{.`..
00020a0: 368e 336f 9055 f645 b636 c5c1 debe fbe7  6.3o.U.E.6......
00020b0: d01e 028f 8b75 b368 0ef0 8889 bb63 e032  .....u.h.....c.2

MariaDBの保存時の暗号化が完了しました。これを最初の投稿で行った転送中の暗号化と組み合わせると、最終的なアーキテクチャは次のようになります。

結論

物理的および仮想的な侵害や盗難から保護するために、暗号化を介してMariaDBデータベースを完全に保護できるようになりました。 ClusterControlは、このタイプのセキュリティを維持するのにも役立ち、ここから無料でダウンロードできます。