InnoDB では、マスター暗号化キーとテーブルスペースキーで構成される 2 層暗号化キーアーキテクチャを使用します。 テーブルスペースが暗号化されると、テーブルスペースキーが暗号化され、テーブルスペースヘッダーに格納されます。 アプリケーションまたは認証済ユーザーが暗号化されたテーブルスペースデータにアクセスする場合、InnoDB はマスター暗号化キーを使用してテーブルスペースキーを復号化します。 復号化されたバージョンのテーブルスペースキーは変更されませんが、必要に応じてマスター暗号化キーを変更できます。 このアクションはマスターキーのローテーションと呼ばれます。

保存データ暗号化機能は、マスター暗号化キー管理のためにキーリングプラグインに依存します。

すべての MySQL エディションには、サーバーホストに対してローカルなファイルにキーリングデータを格納する keyring_file プラグインが用意されています。

MySQL Enterprise Edition には、追加のキーリングプラグインが用意されています:

セキュアで堅牢な暗号化キー管理ソリューションは、セキュリティおよび様々なセキュリティ標準への準拠に不可欠です。 保存データ暗号化機能で一元化されたキー管理ソリューションを使用する場合、この機能は 「MySQL Enterprise Transparent Data Encryption (TDE)」 と呼ばれます。

保存データ暗号化機能は、Advanced Encryption Standard (AES) ブロックベースの暗号化アルゴリズムをサポートしています。 テーブルスペースキー暗号化には電子コードブック (ECB) ブロック暗号化モードを使用し、データ暗号化には暗号ブロックチェーン (CBC) ブロック暗号化モードを使用します。

保存データ暗号化機能に関するよくある質問については、セクションA.17「MySQL 8.0 FAQ : InnoDB 保存データ暗号化」 を参照してください。

MySQL 8.0.16 では、default_table_encryption システム変数によってスキーマおよび一般テーブルスペースのデフォルトの暗号化設定が定義されます。 ENCRYPTION 句が明示的に指定されていない場合、CREATE TABLESPACE および CREATE SCHEMA 操作によって default_table_encryption 設定が適用されます。

ALTER SCHEMA および ALTER TABLESPACE の操作では、default_table_encryption 設定は適用されません。 既存のスキーマまたは一般テーブルスペースの暗号化を変更するには、ENCRYPTION 句を明示的に指定する必要があります。

default_table_encryption 変数は、個々のクライアント接続に対して設定することも、SET 構文を使用してグローバルに設定することもできます。 たとえば、次のステートメントは、デフォルトのスキーマおよびテーブルスペースの暗号化をグローバルに有効にします:

mysql> SET GLOBAL default_table_encryption=ON;

スキーマのデフォルトの暗号化設定は、次の例に示すように、スキーマの作成または変更時に DEFAULT ENCRYPTION 句を使用して定義することもできます:

mysql> CREATE SCHEMA test DEFAULT ENCRYPTION = 'Y';

スキーマの作成時に DEFAULT ENCRYPTION 句が指定されていない場合、default_table_encryption 設定が適用されます。 既存のスキーマのデフォルト暗号化を変更するには、DEFAULT ENCRYPTION 句を指定する必要があります。 それ以外の場合、スキーマは現在の暗号化設定を保持します。

デフォルトでは、テーブルは作成されたスキーマまたは一般テーブルスペースの暗号化設定を継承します。 たとえば、暗号化対応スキーマで作成されたテーブルは、デフォルトで暗号化されます。 この動作により、DBA は、スキーマおよび一般的なテーブルスペース暗号化のデフォルトを定義して強制することで、テーブル暗号化の使用を制御できます。

暗号化のデフォルトは、table_encryption_privilege_check システム変数を有効にすることで適用されます。 table_encryption_privilege_check が有効な場合、default_table_encryption 設定とは異なる暗号化設定を使用してスキーマまたは一般テーブルスペースを作成または変更するとき、またはデフォルトのスキーマ暗号化とは異なる暗号化設定を使用してテーブルを作成または変更するときに、権限チェックが発生します。 table_encryption_privilege_check が無効 (デフォルト) の場合、権限チェックは実行されず、前述の操作は警告付きで続行できます。

table_encryption_privilege_check が有効な場合、デフォルトの暗号化設定をオーバーライドするには、TABLE_ENCRYPTION_ADMIN 権限が必要です。 DBA は、この権限を付与して、スキーマまたは一般テーブルスペースの作成または変更時にユーザーが default_table_encryption 設定から逸脱したり、テーブルの作成または変更時にデフォルトのスキーマ暗号化から逸脱できるようにすることができます。 この権限では、テーブルの作成または変更時に一般テーブルスペースの暗号化から逸脱することはできません。 テーブルの暗号化設定は、テーブルが存在する一般テーブルスペースと同じである必要があります。

MySQL 8.0.16 の時点では、file-per-table テーブルスペースは、CREATE TABLE ステートメントで ENCRYPTION 句が明示的に指定されていないかぎり、テーブルが作成されるスキーマのデフォルトの暗号化を継承します。 MySQL 8.0.16 より前は、暗号化を有効にするために ENCRYPTION 句を指定する必要があります。

mysql> CREATE TABLE t1 (c1 INT) ENCRYPTION = 'Y';

既存の file-per-table テーブルスペースの暗号化を変更するには、ENCRYPTION 句を指定する必要があります。

mysql> ALTER TABLE t1 ENCRYPTION = 'Y';

MySQL 8.0.16 では、table_encryption_privilege_check 変数が有効になっている場合、デフォルトのスキーマ暗号化とは異なる設定で ENCRYPTION 句を指定するには、TABLE_ENCRYPTION_ADMIN 権限が必要です。 スキーマおよび一般テーブルスペースの暗号化デフォルトの定義を参照してください。

MySQL 8.0.16 では、CREATE TABLESPACE ステートメントで ENCRYPTION 句が明示的に指定されていないかぎり、default_table_encryption 変数によって、新しく作成された一般テーブルスペースの暗号化が決定されます。 MySQL 8.0.16 より前は、暗号化を有効にするために ENCRYPTION 句を指定する必要があります。

mysql> CREATE TABLESPACE `ts1` ADD DATAFILE 'ts1.ibd' ENCRYPTION = 'Y' Engine=InnoDB;

既存の一般テーブルスペースの暗号化を変更するには、ENCRYPTION 句を指定する必要があります。

mysql> ALTER TABLESPACE ts1 ENCRYPTION = 'Y';

MySQL 8.0.16 では、table_encryption_privilege_check 変数が有効になっている場合、default_table_encryption 設定とは異なる設定で ENCRYPTION 句を指定するには TABLE_ENCRYPTION_ADMIN 権限が必要です。 スキーマおよび一般テーブルスペースの暗号化デフォルトの定義を参照してください。

二重書込みファイルの暗号化サポートは、MySQL 8.0.23 の時点で使用できます。 InnoDB では、暗号化されたテーブルスペースに属する二重書込みファイルページが自動的に暗号化されます。 必要なアクションはありません。 二重書込みファイルページは、関連付けられたテーブルスペースの暗号化キーを使用して暗号化されます。 テーブルスペースデータファイルに書き込まれた同じ暗号化ページも二重書込みファイルに書き込まれます。 暗号化されていないテーブルスペースに属するファイルの二重書込みページは、暗号化されないままです。

リカバリ中、暗号化された二重書込みファイルページは暗号化されず、破損がないかどうかチェックされます。

mysql システムテーブルスペースの暗号化サポートは、MySQL 8.0.16 の時点で使用できます。

mysql システムテーブルスペースには、mysql システムデータベースおよび MySQL データディクショナリテーブルが含まれます。 デフォルトでは暗号化されていません。 mysql システムテーブルスペースの暗号化を有効にするには、ALTER TABLESPACE ステートメントでテーブルスペース名と ENCRYPTION オプションを指定します。

mysql> ALTER TABLESPACE mysql ENCRYPTION = 'Y';

mysql システムテーブルスペースの暗号化を無効にするには、ALTER TABLESPACE ステートメントを使用して ENCRYPTION = 'N'を設定します。

mysql> ALTER TABLESPACE mysql ENCRYPTION = 'N';

mysql システムテーブルスペースの暗号化を有効または無効にするには、インスタンス内のすべてのテーブル (CREATE TABLESPACE on *.*)) に対する CREATE TABLESPACE 権限が必要です。

redo ログデータの暗号化は、innodb_redo_log_encrypt 構成オプションを使用して有効にします。 redo ログの暗号化はデフォルトで無効になっています。

テーブルスペースデータと同様に、redo ログデータの暗号化は redo ログデータがディスクに書き込まれるときに行われ、復号化は redo ログデータがディスクから読み取られるときに行われます。 redo ログデータがメモリーに読み込まれると、暗号化されていない形式になります。 redo ログデータは、テーブルスペース暗号化キーを使用して暗号化および復号化されます。

innodb_redo_log_encrypt が有効な場合、ディスクに存在する暗号化されていない redo ログページは暗号化されずに残り、新しい redo ログページは暗号化された形式でディスクに書き込まれます。 同様に、innodb_redo_log_encrypt が無効な場合、ディスクに存在する暗号化された redo ログページは暗号化されたままになり、新しい redo ログページは暗号化されていない形式でディスクに書き込まれます。

テーブルスペース暗号化キーを含む redo ログ暗号化メタデータは、最初の redo ログファイル (ib_logfile0) のヘッダーに格納されます。 このファイルを削除すると、redo ログの暗号化は無効になります。

redo ログの暗号化が有効になると、InnoDB は起動時に redo ページをスキャンできる必要があり、redo ログページが暗号化されている場合はスキャンできないため、キーリングプラグインなしまたは暗号化キーなしで通常の再起動はできません。 キーリングプラグインまたは暗号化鍵がない場合は、redo ログ (SRV_FORCE_NO_LOG_REDO) を使用しない強制的な起動のみが可能です。 セクション15.21.2「InnoDB のリカバリの強制的な実行」を参照してください。

undo ログデータの暗号化は、innodb_undo_log_encrypt 構成オプションを使用して有効にします。 undo ログの暗号化は、undo tablespaces に存在する undo ログに適用されます。 セクション15.6.3.4「undo テーブルスペース」を参照してください。 undo ログデータの暗号化は、デフォルトで無効になっています。

テーブルスペースデータと同様に、undo ログデータの暗号化は undo ログデータがディスクに書き込まれるときに行われ、復号化は undo ログデータがディスクから読み取られるときに行われます。 undo ログデータがメモリーに読み込まれると、暗号化されていない形式になります。 undo ログデータは、テーブルスペース暗号化キーを使用して暗号化および復号化されます。

innodb_undo_log_encrypt が有効な場合、ディスクに存在する暗号化されていない undo ログページは暗号化されずに残り、新しい undo ログページは暗号化された形式でディスクに書き込まれます。 同様に、innodb_undo_log_encrypt が無効になっている場合、ディスクに存在する暗号化された undo ログページは暗号化されたままになり、新しい undo ログページは暗号化されていない形式でディスクに書き込まれます。

undo ログ暗号化メタデータ (テーブルスペース暗号化キーを含む) は、undo ログファイルのヘッダーに格納されます。

マスター暗号化キーは、定期的およびキーが危険にさらされた疑いがある場合は常にローテーションする必要があります。

マスターキーローテーションは、アトミックなインスタンスレベルの操作です。 マスター暗号化キーがローテーションされるたびに、MySQL インスタンスのすべてのテーブルスペースキーが再暗号化され、それぞれのテーブルスペースヘッダーに保存されます。 アトミック操作として、ローテーション操作が開始されたら、すべてのテーブルスペースキーに対して再暗号化が成功する必要があります。 サーバー障害によってマスターキーのローテーションが中断された場合、InnoDB はサーバーの再起動時に操作をロールフォワードします。 詳細は、暗号化とリカバリを参照してください。

マスター暗号化キーをローテーションすると、マスター暗号化キーのみが変更され、テーブルスペースキーが再暗号化されます。 関連付けられたテーブルスペースデータは復号化または再暗号化されません。

マスター暗号化キーをローテーションするには、ENCRYPTION_KEY_ADMIN 権限 (または非推奨の SUPER 権限) が必要です。

マスター暗号化キーをローテーションするには、次のコマンドを実行します:

mysql> ALTER INSTANCE ROTATE INNODB MASTER KEY;

ALTER INSTANCE ROTATE INNODB MASTER KEY では、同時 DML がサポートされます。 ただし、テーブルスペースの暗号化操作と同時に実行することはできず、同時実行によって発生する可能性のある競合を防ぐためにロックが取得されます。 ALTER INSTANCE ROTATE INNODB MASTER KEY 操作が実行中の場合は、テーブルスペースの暗号化操作を続行する前に操作を終了する必要があり、その逆も同様です。

暗号化操作中にサーバー障害が発生した場合、サーバーの再起動時に操作がロールフォワードされます。 一般的なテーブルスペースの場合、暗号化操作は最後に処理されたページからバックグラウンドスレッドで再開されます。

マスターキーのローテーション中にサーバー障害が発生した場合、InnoDB はサーバーの再起動時に操作を続行します。

InnoDB の初期化およびリカバリアクティビティがテーブルスペースデータにアクセスする前に、テーブルスペースデータページの復号化に必要な情報をテーブルスペースヘッダーから取得できるように、ストレージエンジンの初期化の前にキープラグインをロードする必要があります。 (暗号化の前提条件を参照してください。)

InnoDB の初期化およびリカバリが開始されると、マスターキーのローテーション操作が再開されます。 サーバー障害のため、一部のテーブルスペースキーは新しいマスター暗号化キーを使用してすでに暗号化されている可能性があります。 InnoDB は各テーブルスペースヘッダーから暗号化データを読み取り、データが古いマスター暗号化キーを使用してテーブルスペースキーが暗号化されていることを示している場合、InnoDB はキーリングから古いキーを取得し、それを使用してテーブルスペースキーを復号化します。 次に、InnoDB は新しいマスター暗号化キーを使用してテーブルスペースキーを再暗号化し、再暗号化されたテーブルスペースキーをテーブルスペースヘッダーに保存します。

テーブルスペースのエクスポートは、file-per-table テーブルスペースでのみサポートされます。

暗号化されたテーブルスペースがエクスポートされると、InnoDB によって、テーブルスペースキーの暗号化に使用される転送キーが生成されます。 暗号化されたテーブルスペースキーおよび転送キーは、tablespace_name.cfp ファイルに格納されます。 インポート操作を実行するには、このファイルと暗号化されたテーブルスペースファイルが必要です。 インポート時に、InnoDB は転送キーを使用して tablespace_name.cfp ファイルのテーブルスペースキーを復号化します。 関連情報については、セクション15.6.1.3「InnoDB テーブルのインポート」を参照してください。

MySQL 8.0.13 で導入された INFORMATION_SCHEMA.INNODB_TABLESPACES テーブルには、暗号化されたテーブルスペースの識別に使用できる ENCRYPTION カラムが含まれています。

mysql> SELECT SPACE, NAME, SPACE_TYPE, ENCRYPTION FROM INFORMATION_SCHEMA.INNODB_TABLESPACES
       WHERE ENCRYPTION='Y'\G
*************************** 1. row ***************************
     SPACE: 4294967294
      NAME: mysql
SPACE_TYPE: General
ENCRYPTION: Y
*************************** 2. row ***************************
     SPACE: 2
      NAME: test/t1
SPACE_TYPE: Single
ENCRYPTION: Y
*************************** 3. row ***************************
     SPACE: 3
      NAME: ts1
SPACE_TYPE: General
ENCRYPTION: Y

CREATE TABLE または ALTER TABLE ステートメントで ENCRYPTION オプションが指定されている場合、INFORMATION_SCHEMA.TABLES の CREATE_OPTIONS カラムに記録されます。 このカラムをクエリーすると、暗号化された file-per-table テーブルスペースに存在するテーブルを識別できます。

mysql> SELECT TABLE_SCHEMA, TABLE_NAME, CREATE_OPTIONS FROM INFORMATION_SCHEMA.TABLES
       WHERE CREATE_OPTIONS LIKE '%ENCRYPTION%';
+--------------+------------+----------------+
| TABLE_SCHEMA | TABLE_NAME | CREATE_OPTIONS |
+--------------+------------+----------------+
| test         | t1         | ENCRYPTION="Y" |
+--------------+------------+----------------+

INFORMATION_SCHEMA.INNODB_TABLESPACES をクエリーして、特定のスキーマおよびテーブルに関連付けられているテーブルスペースに関する情報を取得します。

mysql> SELECT SPACE, NAME, SPACE_TYPE FROM INFORMATION_SCHEMA.INNODB_TABLESPACES WHERE NAME='test/t1';
+-------+---------+------------+
| SPACE | NAME    | SPACE_TYPE |
+-------+---------+------------+
|     3 | test/t1 | Single     |
+-------+---------+------------+

INFORMATION_SCHEMA.SCHEMATA テーブルをクエリーすることで、暗号化対応のスキーマを識別できます。

mysql> SELECT SCHEMA_NAME, DEFAULT_ENCRYPTION FROM INFORMATION_SCHEMA.SCHEMATA
       WHERE DEFAULT_ENCRYPTION='YES';
+-------------+--------------------+
| SCHEMA_NAME | DEFAULT_ENCRYPTION |
+-------------+--------------------+
| test        | YES                |
+-------------+--------------------+

SHOW CREATE SCHEMA には、DEFAULT ENCRYPTION 句も表示されます。

Performance Schema を使用して、一般的なテーブルスペースおよび mysql システムテーブルスペースの暗号化の進行状況を監視できます。

stage/innodb/alter tablespace (encryption) ステージイベントインストゥルメントは、一般的なテーブルスペース暗号化操作に関する WORK_ESTIMATED および WORK_COMPLETED の情報をレポートします。

次の例は、stage/innodb/alter tablespace (encryption) ステージイベントインストゥルメントおよび関連するコンシューマテーブルを有効にして、一般的なテーブルスペースまたは mysql システムテーブルスペースの暗号化の進行状況を監視する方法を示しています。 パフォーマンススキーマステージイベントインストゥルメントおよび関連コンシューマについては、セクション27.12.5「パフォーマンススキーマステージイベントテーブル」 を参照してください。