MySQL :: MySQL 8.0 リファレンスマニュアル :: 15.13 InnoDB 保存データ暗号化

version 8.0

9.1 English
9.0 English
8.4 English
8.0 English
5.7 English

MySQL 8.0 リファレンスマニュアル / InnoDB ストレージエンジン / InnoDB 保存データ暗号化

このページは機械翻訳したものです。

15.13 InnoDB 保存データ暗号化

InnoDB では、file-per-table テーブルスペース、general テーブルスペース、mysql システムテーブルスペース、redo ログおよび undo ログの保存データ暗号化がサポートされています。

MySQL 8.0.16 では、スキーマおよび一般テーブルスペースの暗号化デフォルトの設定もサポートされているため、DBA はこれらのスキーマおよびテーブルスペースで作成されたテーブルを暗号化するかどうかを制御できます。

InnoDB の保存データ暗号化の機能については、このセクションの次のトピックで説明します。

保存データの暗号化について

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

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

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

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

keyring_encrypted_file は、サーバーホストに対してローカルな暗号化されたファイルにキーリングデータを格納します。
keyring_okv には、KMIP 互換製品を鍵リングストレージのバックエンドとして使用する KMIP クライアント (KMIP 1.1) が含まれています。サポートされている KMIP 互換製品には、Oracle Key Vault、Gemalto KeySecure、Thales Vormetric キー管理サーバー、Fornetix Key Orchestration などの一元化された鍵管理ソリューションが含まれます。
keyring_aws は、キー生成のバックエンドとして Amazon Web Services Key Management Service (AWS KMS) と通信し、キーの格納にローカルファイルを使用します。
keyring_hashicorp は、バックエンドストレージのために HashiCorp Vault と通信します。

警告

keyring_file および keyring_encrypted file プラグインは、規制コンプライアンスソリューションとしては意図されていません。 PCI、FIPS などのセキュリティ標準では、キーボールトまたはハードウェアセキュリティモジュール (HSM) 内の暗号化キーを保護、管理および保護するためにキー管理システムを使用する必要があります。

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

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

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

暗号化の前提条件

キーリングプラグインをインストールして構成する必要があります。キーリングプラグインのインストールは、起動時に early-plugin-load オプションを使用して実行されます。早期ロードにより、InnoDB ストレージエンジンを初期化する前にプラグインが使用可能になります。プラグインのインストールと構成の手順については、セクション6.4.4「MySQL キーリング」を参照してください。

一度に有効にできるキーリングプラグインは 1 つだけです。複数のキーリングプラグインの有効化はサポートされていません。

重要

暗号化されたテーブルスペースが MySQL インスタンスで作成されたら、暗号化されたテーブルスペースの作成時にロードされたキーリングプラグインは、early-plugin-load オプションを使用して起動時に引き続きロードされる必要があります。そうしないと、サーバーの起動時および InnoDB のリカバリ時にエラーが発生します。

キーリングプラグインがアクティブであることを確認するには、SHOW PLUGINS ステートメントを使用するか、INFORMATION_SCHEMA.PLUGINS テーブルをクエリーします。例:
```
mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS
       FROM INFORMATION_SCHEMA.PLUGINS
       WHERE PLUGIN_NAME LIKE 'keyring%';
+--------------+---------------+
| PLUGIN_NAME  | PLUGIN_STATUS |
+--------------+---------------+
| keyring_file | ACTIVE        |
+--------------+---------------+
```
本番データを暗号化する場合は、マスター暗号化キーが失われないようにするステップを実行してください。 マスター暗号化キーが失われた場合、暗号化されたテーブルスペースファイルに格納されているデータはリカバリできません。 keyring_file または keyring_encrypted_file プラグインを使用する場合は、最初の暗号化されたテーブルスペースの作成直後、マスターキーのローテーションの前、およびマスターキーのローテーションの後に、キーリングデータファイルのバックアップを作成します。 keyring_file_data 構成オプションは、keyring_file プラグインのキーリングデータファイルの場所を定義します。 keyring_encrypted_file_data 構成オプションは、keyring_encrypted_file プラグインのキーリングデータファイルの場所を定義します。 keyring_okv または keyring_aws プラグインを使用する場合は、必要な構成が実行されていることを確認します。その手順は、セクション6.4.4「MySQL キーリング」を参照してください。

スキーマおよび一般テーブルスペースの暗号化デフォルトの定義

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 システムテーブルスペースの暗号化サポートは、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 ログの暗号化

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 ログの暗号化

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 ログファイルのヘッダーに格納されます。

注記

undo ログの暗号化が無効になっている場合、サーバーは、暗号化された undo ログデータを含む undo テーブルスペースが切り捨てられるまで、undo ログデータの暗号化に使用されたキーリングプラグインを引き続き必要とします。 (暗号化ヘッダーは、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 テーブルのインポート」を参照してください。

暗号化とレプリケーション

ALTER INSTANCE ROTATE INNODB MASTER KEY ステートメントは、ソースおよびレプリカがテーブルスペースの暗号化をサポートするバージョンの MySQL を実行するレプリケーション環境でのみサポートされます。
成功した ALTER INSTANCE ROTATE INNODB MASTER KEY ステートメントは、レプリカ上のレプリケーションのためにバイナリログに書き込まれます。
ALTER INSTANCE ROTATE INNODB MASTER KEY ステートメントが失敗した場合、バイナリログに記録されず、レプリカにレプリケートされません。
キーリングプラグインがソースにインストールされているが、レプリカにはインストールされていない場合、ALTER INSTANCE ROTATE INNODB MASTER KEY 操作のレプリケーションは失敗します。
keyring_file または keyring_encrypted_file プラグインがソースとレプリカの両方にインストールされているが、レプリカにキーリングデータファイルがない場合、レプリケートされた ALTER INSTANCE ROTATE INNODB MASTER KEY ステートメントは、キーリングファイルデータがメモリーにキャッシュされていないと想定して、レプリカにキーリングデータファイルを作成します。 ALTER INSTANCE ROTATE INNODB MASTER KEY では、メモリーにキャッシュされているキーリングファイルデータが使用されます (使用可能な場合)。

暗号化されたテーブルスペースおよびスキーマの識別

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「パフォーマンススキーマステージイベントテーブル」を参照してください。

stage/innodb/alter tablespace (encryption) インストゥルメントを有効にします:

mysql> USE performance_schema;
mysql> UPDATE setup_instruments SET ENABLED = 'YES'
       WHERE NAME LIKE 'stage/innodb/alter tablespace (encryption)';

ステージイベントコンシューマテーブル (events_stages_current、events_stages_history および events_stages_history_long を含む) を有効にします。
```
mysql> UPDATE setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE '%stages%';
```
テーブルスペース暗号化操作を実行します。この例では、ts1 という一般的なテーブルスペースが暗号化されます。
```
mysql> ALTER TABLESPACE ts1 ENCRYPTION = 'Y';
```

パフォーマンススキーマ events_stages_current テーブルをクエリーして、暗号化操作の進行状況を確認します。 WORK_ESTIMATED では、テーブルスペース内のページの合計数がレポートされます。 WORK_COMPLETED では、処理されたページ数がレポートされます。

mysql> SELECT EVENT_NAME, WORK_ESTIMATED, WORK_COMPLETED FROM events_stages_current;
+--------------------------------------------+----------------+----------------+
| EVENT_NAME                                 | WORK_COMPLETED | WORK_ESTIMATED |
+--------------------------------------------+----------------+----------------+
| stage/innodb/alter tablespace (encryption) |           1056 |           1407 |
+--------------------------------------------+----------------+----------------+

暗号化操作が完了すると、events_stages_current テーブルは空のセットを返します。この場合、events_stages_history テーブルをチェックして、完了した操作のイベントデータを表示できます。例:

mysql> SELECT EVENT_NAME, WORK_COMPLETED, WORK_ESTIMATED FROM events_stages_history;
+--------------------------------------------+----------------+----------------+
| EVENT_NAME                                 | WORK_COMPLETED | WORK_ESTIMATED |
+--------------------------------------------+----------------+----------------+
| stage/innodb/alter tablespace (encryption) |           1407 |           1407 |
+--------------------------------------------+----------------+----------------+

暗号化の使用上のノート

ENCRYPTION オプションを使用して既存の file-per-table テーブルスペースを変更する場合は、適切に計画します。 file-per-table テーブルスペースに存在するテーブルは、COPY アルゴリズムを使用して再構築されます。 INPLACE アルゴリズムは、一般テーブルスペースまたは mysql システムテーブルスペースの ENCRYPTION 属性を変更するときに使用されます。 INPLACE アルゴリズムでは、一般テーブルスペースに存在するテーブルに対する同時 DML が許可されます。同時 DDL はブロックされます。
一般テーブルスペースまたは mysql システムテーブルスペースが暗号化されると、テーブルスペースに存在するすべてのテーブルが暗号化されます。同様に、暗号化されたテーブルスペースに作成されたテーブルも暗号化されます。
通常の操作中にサーバーが終了または停止した場合は、以前に構成したものと同じ暗号化設定を使用してサーバーを再起動することをお薦めします。
最初のマスター暗号化キーは、最初の新規または既存のテーブルスペースが暗号化されるときに生成されます。
マスターキーローテーションでは、テーブルスペースキーは再暗号化されますが、テーブルスペースキー自体は変更されません。テーブルスペースキーを変更するには、暗号化を無効にして再度有効にする必要があります。 file-per-table テーブルスペースの場合、テーブルスペースの再暗号化はテーブルを再構築する ALGORITHM=COPY 操作です。一般テーブルスペースおよび mysql システムテーブルスペースの場合、これは ALGORITHM=INPLACE 操作であり、テーブルスペースに存在するテーブルを再構築する必要はありません。
COMPRESSION オプションと ENCRYPTION オプションの両方を使用してテーブルが作成された場合、圧縮はテーブルスペースデータが暗号化される前に実行されます。
キーリングデータファイル (keyring_file_data または keyring_encrypted_file_data で指定されたファイル) が空であるか欠落している場合、ALTER INSTANCE ROTATE INNODB MASTER KEY の最初の実行でマスター暗号化キーが作成されます。
keyring_file または keyring_encrypted_file プラグインをアンインストールしても、既存のキーリングデータファイルは削除されません。
キーリングデータファイルは、テーブルスペースデータファイルと同じディレクトリに配置しないことをお薦めします。
実行時またはサーバーの再起動時に keyring_file_data または keyring_encrypted_file_data の設定を変更すると、以前に暗号化されたテーブルスペースにアクセスできなくなり、データが失われる可能性があります。
暗号化は、FULLTEXT インデックスの追加時に暗黙的に作成される InnoDB FULLTEXT インデックステーブルでサポートされますが、暗号化された一般テーブルスペースに存在するテーブルに FULLTEXT インデックスが作成される場合にのみサポートされます。この場合、FULLTEXT インデックステーブルは、同じ暗号化された一般テーブルスペースに作成されます。関連情報については、InnoDB 全文インデックステーブルを参照してください。

暗号化の制限事項

Advanced Encryption Standard (AES) は、サポートされる唯一の暗号化アルゴリズムです。 InnoDB テーブルスペース暗号化では、テーブルスペースキー暗号化に電子コードブック (ECB) ブロック暗号化モードを使用し、データ暗号化に暗号ブロックチェーン (CBC) ブロック暗号化モードを使用します。パディングは CBC ブロック暗号化モードでは使用されません。かわりに、InnoDB は暗号化されるテキストがブロックサイズの倍数であることを確認します。
暗号化は、file-per-table テーブルスペース、general テーブルスペースおよび mysql システムテーブルスペースでのみサポートされます。一般テーブルスペースの暗号化サポートは、MySQL 8.0.13 で導入されました。 mysql システムテーブルスペースの暗号化サポートは、MySQL 8.0.16 の時点で使用できます。暗号化は、InnoDB system tablespace を含む他のテーブルスペースタイプではサポートされていません。
暗号化された file-per-table テーブルスペース、general テーブルスペースまたは mysql システムテーブルスペースから、暗号化をサポートしないテーブルスペースタイプにテーブルを移動またはコピーすることはできません。
暗号化されたテーブルスペースから暗号化されていないテーブルスペースにテーブルを移動またはコピーすることはできません。ただし、暗号化されていないテーブルスペースから暗号化されたテーブルスペースへのテーブルの移動は許可されています。たとえば、暗号化されていない file-per-table または general テーブルスペースから暗号化された一般テーブルスペースにテーブルを移動またはコピーできます。
デフォルトでは、テーブルスペースの暗号化はテーブルスペースのデータにのみ適用されます。 redo ログおよび undo ログデータは、innodb_redo_log_encrypt および innodb_undo_log_encrypt を有効にすることで暗号化できます。 redo ログの暗号化およびundo ログの暗号化を参照してください。バイナリログファイルとリレーログファイルの暗号化については、セクション17.3.2「バイナリログファイルとリレーログファイルの暗号化」を参照してください。
暗号化されたテーブルスペースに存在する、または以前に存在していたテーブルのストレージエンジンを変更することはできません。

PREV HOME UP NEXT