MySQL / MariaDB TDE

適用対象:

DuoKey Cockpit v2InnoDB を使用する MySQL / MariaDBキーリングプラグイン: keyring_okv / keyring_hashicorp / keyring_kmip

概要

MySQL と MariaDB の InnoDB ストレージエンジンは、プラグイン可能なキーリングを通じて Transparent Data Encryption をサポートします。サーバーが自身の InnoDB マスター暗号化キーをローカルで生成・保存する代わりに、キーリングプラグイン（現行の MySQL/Percona Server リリースではキーリングコンポーネント）が外部システムからそれを取得します。このアプリはそのキーリングが DuoKey 管理のキーを指すように設定するため、マスターキーがデータベースホスト上に存在することなく、InnoDB のテーブルスペースファイルが保存時に暗号化されます。

Oracle の「独自」プロトコルではありません

名前に反して、keyring_okv は汎用の KMIP クライアントとして標準の KMIP 1.1 ワイヤプロトコルを話します。もともとは Oracle Key Vault 向けに作られたものですが、keyring_okv（および新しい component_keyring_kmip）は、DuoKey Cockpit の KMIP リスナーを含め、KMIP に準拠したあらゆるサーバーと通信できます。一方 component_keyring_hashicorp は、KMIP ではなく HashiCorp Vault 独自の API を話します。

MySQL / MariaDB から DuoKey KMIP サーバーへ

MySQL / MariaDB（InnoDB）テーブルスペース暗号化redo / undo ログの暗号化

keyring_okv または component_keyring_kmip

キーリングプラグイン / コンポーネントサーバーのキーリングマニフェスト経由で起動時にロード

TLS 上の KMIP 1.1（TTLV）

DuoKey KMIP サーバーCockpit の KMIP リスナー

テナント vault / HSMInnoDB のマスター暗号化キー — データベースホストには保存されません

キーリングコンポーネントは InnoDB の初期化前にロードされるため、SQL レイヤーが接続を受け付ける前に、暗号化されたテーブルスペースを復号できます。

プロパティ	値
暗号化モデル	エンジンネイティブな TDE（InnoDB テーブルスペース暗号化）
キーのソース	キーリングプラグイン（OKV / HashiCorp / KMIP 形式、DuoKey vault が背後）
オンボーディング	ガイド付きのマルチステップウィザード
実証ステータス	デプロイと設定の生成は実物。セルフテストは現時点ではシミュレーション結果を返します — 下記参照

セルフテストに頼る前にお読みください

この統合のセルフテストとヘルスチェックのエンドポイントは、現時点ではシミュレーションされたハードコードの結果を返します。稼働中の MySQL/MariaDB インスタンスに対するライブのラウンドトリップを実行せずに成功を報告します。これは隠された制限ではなく、正直に開示している制限です。このカタログのいくつかのエンジンの現在の成熟度を反映しています（概要の実証ステータスの表を参照）。実物なのは、アプリのレコード、リンクされた vault キー、そして下記の生成されるセットアップ SQL であり、オペレーターはこれを稼働中のサーバーに対して直接実行できます。

設定

フィールド	目的
`mysql_host`	`mysql_port`	MySQL / MariaDB の接続エンドポイント（デフォルトポートは 3306）。
`keyring_plugin`	プラグインの種類: `keyring_okv`（デフォルト）、`keyring_hashicorp`、または `keyring_kmip`。
`tablespaces`	暗号化の対象とするテーブルスペースのリスト。
`redo_log_encryption`	InnoDB の redo/undo ログ暗号化も有効にするかどうか。
`linked_key_id`	キーリングを支える DuoKey vault のキー。

ウィザードによるオンボーディング

データベース

対象インスタンスの MySQL/MariaDB のホストとポートを入力します。

キーリングプラグイン

キーリングプラグインの種類とその設定を選択します。

TDE の設定

暗号化するテーブルスペースと、redo/undo ログの暗号化を有効にするかどうかを選択します。

vault とキー

キーリングプラグインが参照する DuoKey の vault とマスターキーを選択します。

レビューとデプロイ

サマリーと生成された SQL セットアップを確認し、デプロイします。

モニタリング

暗号化のステータスを追跡します。ENCRYPTION='Y' を適用した後、大きなテーブルはバックグラウンドでの暗号化に時間がかかることがあります。

セットアップ SQL

デプロイすると次のステップが生成されます。<table_name> はプレースホルダーであり、オペレーターが必要に応じてテーブルごと（またはテーブルスペースごと）に適用します。

アプリが生成するセットアップ SQLSQL

-- 1. Install the keyring plugin
INSTALL PLUGIN keyring_okv SONAME 'keyring_okv.so';

-- 2. Verify it loaded
SELECT PLUGIN_NAME, PLUGIN_STATUS
FROM INFORMATION_SCHEMA.PLUGINS
WHERE PLUGIN_NAME LIKE 'keyring%';

-- 3. Enable InnoDB encryption on a table
ALTER TABLE <table_name> ENCRYPTION='Y';

既存データの暗号化

ALTER TABLE ... ENCRYPTION='Y' は内部的にテーブルスペースを書き換えます。大きなテーブルでは、メンテナンスウィンドウ中に実行するか、MySQL/MariaDB のバージョンに応じてバックグラウンドのコピー処理が走ることを想定してください。

マスター暗号化キーのローテーション

ALTER INSTANCE ROTATE INNODB MASTER KEY は、新しいマスター暗号化キーの生成（ここでは取得）と保存をキーリングに要求します。ローテーションは高速です。既存のテーブルスペースのデータを即座に再暗号化することはありません。そのため、以前にラップされたテーブルスペースキーを復号可能に保つには、古いマスターキーを DuoKey vault 内に残しておく必要があります。

mysqld 起動時に何が起こるか

起動時のキー取得と redo ログ暗号化

1. mysqld が起動InnoDB の初期化前に、起動マニフェストからキーリングコンポーネントがロードされる

最初のキー要求

2. マスター暗号化キーを要求初回起動時、または ALTER INSTANCE ROTATE INNODB MASTER KEY 時に自動で実行

TLS 上の KMIP 1.1（TTLV）

3. DuoKey KMIP サーバークライアントを認証し、シールされたマスター暗号化キーを返す / 保存する

サーバーのメモリ上でのみ保持

4. テーブルスペースキーをラップテーブルスペースごとのキーをマスターキーの下でラップ

5. 透過的な暗号化 / 復号テーブルスペースのページ、および有効な場合は redo / undo ログのレコード

SQL レイヤーが接続を受け付ける前に、暗号化されたテーブルスペースを復号できる必要があるため、キーリングコンポーネントは InnoDB の初期化前に準備が整っていなければなりません。

ヘルスとセルフテスト

チェック	報告される内容	現時点でのライブプローブ
ヘルス	MySQL への到達性、キーリングの稼働、TDE の有効化	なし — 固定の正常ステータスエンベロープを返します
セルフテスト	MySQL への接続、キーリングプラグインの稼働、マスターキーへのアクセス可否、テーブルスペースの暗号化	なし — 4 つのチェックすべてがハードコードされた合格を返します

セルフテストをコンプライアンスの証跡として扱わないでください

このセルフテストがライブの MySQL セッションに接続されるまでは、生成されたセットアップ SQL と、ご自身の INFORMATION_SCHEMA / SHOW ... STATUS クエリを使って、対象インスタンスで暗号化が有効であることを独自に確認してください。

概要​

設定​

ウィザードによるオンボーディング​