データベース暗号化
7 つのデータベース暗号化エンジンを支える外部キーカストディアンとしての DuoKey — エンジンネイティブな TDE から、クライアントサイド、列単位、フィールド単位の暗号化まで。
この製品ファミリーとは
Cockpit のカタログにあるデータベース暗号化アプリは、いずれも同じ根本的な課題を異なる方法で解決します。データベースエンジン（またはそのクライアントドライバー）は、ローカルに保存したくない暗号化キーを必要とし、DuoKey はそのキーをテナント vault から、データベース側がすでに話せる標準プロトコル — 通常は KMIP — を通じて提供します。
この傘の下には、2 つの異なる暗号化モデルがあります。
- エンジンネイティブな Transparent Data Encryption（TDE）。 データベースエンジン自身が暗号化を担います。エンジンは DuoKey からプリンシパルキーまたはマスターキーを取得し（あるいは取得するように設定され）、ディスク上のデータファイル、テーブルスペース、SSTable、コミットログを透過的に暗号化します。アプリケーションやクエリは暗号化が行われていることを意識しません。DuoKey がテーブルのデータを見ることはなく、預かるキーマテリアルだけを扱います。Percona PostgreSQL TDE、MySQL/MariaDB TDE、Cassandra TDE、Couchbase の Encryption at Rest はすべてこのカテゴリーに該当します。
- クライアントサイド/アプリケーションレベルの暗号化。 データベースエンジンは平文を一切見ません。クライアントドライバーまたはライブラリが、DuoKey から（間接的に）取得したキーを使って特定のフィールドや列をアプリケーションから出る前に暗号化し、戻ってくる際に復号します。データベースが保存・インデックス化するのは暗号文です。MongoDB Client-Side Field-Level Encryption（CSFLE）、MongoDB Queryable Encryption、SQL Server Always Encrypted がこのカテゴリーに該当します。ここでの DuoKey の役割は、最上位のラッピングキー（Customer Master Key またはそれに相当するもの）を預かることに絞られ、レコードごとの暗号化キーそのものを扱うことはありません。
SQL Server Always Encrypted（本セクション）は、SQL EKM（SQL Server TDE を対象とする既存の別製品）とは異なる統合です。直接的な比較は SQL Always Encrypted のページを参照してください。
各エンジンはすでに話せるプロトコル — TDE エンジンと Couchbase は KMIP、クライアントサイドのエンジンはドライバーネイティブな呼び出し — で Cockpit に到達し、Cockpit にリンクされた vault がキーマテリアルの存在する唯一の場所です。
7 つのエンジン
| エンジン | 暗号化モデル | オンボーディング | 実証ステータス |
|---|---|---|---|
| Percona PostgreSQL TDE | エンジンネイティブな TDE（KMIP プリンシパルキー） | 詳細ページ | エンドツーエンドで実証済み — 実際の Percona 17.5 コンテナに対して、ライブの KMIP ラウンドトリップとディスク上の暗号文を検証済み |
| MySQL / MariaDB TDE | エンジンネイティブな TDE（キーリングプラグイン） | ウィザード | デプロイと設定の生成は実物。セルフテストは現時点ではシミュレーション |
| Cassandra TDE | エンジンネイティブな TDE（ノードごとの KMIP キープロバイダー） | 詳細ページ | デプロイ成果物とローテーションのランブックは実物。ローリング展開はオペレーターが実行するランブックであり、まだ自動化されていません |
| MongoDB CSFLE | クライアントサイドのフィールドレベル暗号化（不透明な暗号文） | ウィザード | デプロイと設定の生成は実物。セルフテストは現時点ではシミュレーション |
| MongoDB Queryable Encryption | クライアントサイドのフィールドレベル暗号化（クエリ可能 — 等価/範囲） | 詳細ページ | 出力される encryptedFieldsMap と CMK 参照は実物。セルフテストは現時点ではシミュレーション |
| Couchbase Encryption at Rest | KMIP 経由のエンジンネイティブな DEK/KEK ラップ | 詳細ページ | KEK のプロビジョニングと KMIP 登録バンドルは実物。Couchbase 側での適用はオペレーターによる手動作業 |
| SQL Server Always Encrypted | クライアントサイドの列暗号化（CMK/CEK） | 詳細ページ | CMK パスと T-SQL の生成は実物。セルフテストは現時点ではシミュレーション |
現時点でライブかつ自動化されたエンドツーエンドの実証があるのは Percona PostgreSQL TDE だけです。Cockpit が実行する本物の KMIP サーバー、TTLV/mTLS 経由でプリンシパルキーを登録・取得する本物の pg_tde クライアント、そしてライブのコンテナに対してディスク上の暗号文を grep する統合テストがあります。他の 6 つのエンジンは、実際に使用可能なデプロイ成果物 — 設定スニペット、T-SQL、CQL、KMIP 登録バンドル — を生成し、テナント vault にすでに保持されている実在のキーにリンクします（Couchbase の登録ステップはさらに進んで、専用の KEK を直接プロビジョニングします）。ただし、それらのセルフテスト/ヘルスチェックのエンドポイントは現時点ではシミュレーション結果を返し、対象データベースに対するライブのラウンドトリップを実行していません。この点は各ページで明示しています。これは、基盤となるキーカストディや成果物の生成が偽物であることを意味するのではなく、ヘルスチェックがまだライブのプローブに接続されていないというだけです。
アプリカタログでの位置づけ
ここで扱うすべてのエンジンは、Cockpit のアプリカタログの database カテゴリーに登録されたエントリです。いずれかをデプロイすると、テナントにスコープされたアプリが作成され、そのアプリは次のいずれかを行います。
- Cockpit の KMIP サーバー経由でラップ/提供される vault キーにリンクする（TDE エンジン、およびクライアントサイドエンジンの CMK）、または
- 対象システムが KMIP 識別子で参照する専用のキー暗号化キー（KEK）をプロビジョニングする（Couchbase）。
一部のエンジンはガイド付きのマルチステップウィザードでオンボードされ（MySQL TDE、MongoDB CSFLE）、残りはアプリの詳細ページで直接設定します。これは、汎用ウィザードがまだモデル化していないフィールドが必要であるか、オンボーディングが本質的に「プロビジョニングしてオペレーターにバンドルを渡す」一度きりのフローであるためです（Cassandra TDE、MongoDB Queryable Encryption、Couchbase、SQL Always Encrypted）。Percona PostgreSQL TDE も詳細ページからオンボードしますが、これはより豊富な設定項目（コネクションプーリング、フェイルオーバー、レプリカホスト）を反映したものです。
すべてのアプリは、オンボーディングの経路にかかわらず同じライフサイクル、すなわちデプロイ → 有効化/無効化 → ヘルスチェック → セルフテスト → 削除を提供し、これに加えてエンジン固有の操作（Percona のプリンシパルキーローテーション、Always Encrypted の CEK 作成、Couchbase のクラスター登録、Cassandra のレプリケーションを考慮したキーローテーション）を備えます。
Percona PostgreSQL TDE
エンドツーエンドで実証済みの旗艦統合。
MySQL / MariaDB TDE
ウィザードによるキーリングプラグイン方式の TDE。
Cassandra TDE
デュアルアクティブキーのローテーションランブックを備えたレプリケーションクラスター向け TDE。
MongoDB CSFLE
クライアントサイドのフィールドレベル暗号化。
MongoDB Queryable Encryption
クエリ可能なクライアントサイドのフィールド暗号化。
Couchbase Encryption at Rest
Couchbase ネイティブの DEK/KEK モデルに対する KMIP 経由の KEK。
SQL Server Always Encrypted
SQL EKM とは異なる、クライアントサイドの列暗号化。