Oracle TDE インテグレーション

適用対象:

DuoKey Cockpit v2Oracle TDEPKCS#11

このページでは、Oracle Transparent Data Encryption がCockpit v2 にどのように接続するかを説明します。レガシーの Cockpit v1 の経路については、本ガイドの Installation & Setup セクションを参照してください。

デモ動画

Oracle TDE ↔ Cockpit v2 のエンドツーエンドフローを示す簡単なデモ動画をここに追加予定です。

インテグレーションチェーン

Oracle は Cockpit v2 と直接やり取りすることはありません。DuoKey のPKCS#11 プロバイダー（ネイティブライブラリ）をロードし、各 Cryptoki 呼び出しを Cockpit v2 プロキシエンドポイントへの単一の HTTPS リクエストに変換します。プロキシは、テナントボールト / HSM に対して実際の暗号操作を実行します。

Oracle TDE → Cockpit v2 request chainTEXT


Oracle Database (ADMINISTER KEY MANAGEMENT …)
 │ PKCS#11 (Cryptoki v2.40 C_* calls)
 ▼
libdke_pkcs11.so / dke_pkcs11.dll (DuoKey PKCS#11 provider)
 │ HTTPS — one request per Cryptoki operation
 ▼
Cockpit v2 proxy endpoint
 │ encrypt / decrypt / wrap / unwrap / generate
 ▼
Tenant vault / HSM backend
 (DuoKey software keystore in dev · Securosys / HSM in production)

理解しておくべき重要な特性が2つあります。

ローカルでの暗号処理なし

PKCS#11 ライブラリは鍵を保持せず、ローカルで暗号処理を行いません。すべての操作は Cockpit v2 プロキシに転送されます。TDE のマスター鍵素材がデータベースホストに存在することはありません。

単一のエクスポートシンボル

Oracle は標準の C_GetFunctionList エントリポイントを通じてライブラリをロードし、これが Cryptoki 関数テーブル全体を返します。

Oracle TDE は AES のみを使用 — RSA でも EC でもない

Oracle TDE のマスター暗号鍵は AES256 です。Oracle のドキュメントによれば、"Master encryption keys always are AES256"（テーブル / テーブルスペース鍵を CBC モードで暗号化する）とされています。Oracle TDE はマスター鍵に RSA や楕円曲線鍵を使用しません。DuoKey PKCS#11 ライブラリは汎用の Cryptoki プロバイダーであり、他の DuoKey インテグレーション向けに RSA や EC のメカニズムも公開していますが、Oracle TDE は AES の鍵生成と暗号化/復号（ラップ/アンラップ）のパスのみを利用します。

Oracle TDE が使用する PKCS#11 操作

Oracle は以下のサブセットのみを利用します。ライブラリの完全な関数テーブル、メカニズム、属性モデルについては、独立した**PKCS#11 ライブラリ** セクションを参照してください — プロバイダーの完全なドキュメントはそちらにあります。

Cryptoki 操作	Oracle TDE における役割
`C_Initialize` / `C_Finalize`	`pkcs11.toml` 構成を読み込み、ライブラリを初期化 / 終了する。
`C_OpenSession` / `C_Login`	シリアルセッションを開き、ユーザー状態に入る — PIN は送信されず、リクエストごとのベアラートークンで認証される。
`C_FindObjectsInit` / `C_FindObjects`	`CKA_LABEL` / `CKA_ID` によって AES マスター鍵を特定する。
`C_GenerateKey`	AES256 の TDE マスター鍵を作成する。
`C_Encrypt` / `C_Decrypt`	マスター鍵の下でテーブル & テーブルスペース鍵をラップ / アンラップする。
`C_GetAttributeValue`	鍵属性を読み取る。`CKA_VALUE` は拒否される（`CKR_ATTRIBUTE_SENSITIVE`）— マスター鍵のバイト列がバックエンドの外に出ることはない。
`C_DestroyObject`	マスター鍵を廃止する。

暗号モデル

プロキシはマスター鍵（MEK）の下での認証付きエンベロープ暗号化を実行します。暗号化と復号は同じボールトプリミティブを使用するため、Cryptoki のメカニズムは助言的（拘束力なし）にすぎません — Oracle が保存する不透明な鍵ブロブについて、ラウンドトリップの整合性は保証されます。
マスター鍵のバイト列はセンシティブです。C_GetAttributeValue は CKA_VALUE を拒否します。実際の HSM バックエンドを使用する場合、鍵素材は HSM の外に存在しません。

マスター暗号鍵（MEK）のライフサイクル

各マスター鍵は、そのラベル（CKA_LABEL）、識別子（CKA_ID）、アルゴリズムと鍵サイズ、背後のボールト / HSM 鍵への参照、そしてライフサイクル状態とともに Cockpit によって追跡されます。

作成

Oracle TDE アプリが Cockpit v2 で作成されると、初期のアクティブなマスター鍵が自動的にプロビジョニングされます（ラベル TDE-MASTER-<date>）。追加の鍵は、Cockpit から、またはライブラリの鍵生成呼び出しを通じて作成できます。既定のアルゴリズムはAES-256です。

開く / 使用する

Oracle は ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY EXTERNAL STORE でキーストアを開き、C_FindObjects を通じて MEK を特定します。テーブルスペース（テーブル）鍵は MEK の下での暗号化 / 復号によって保護されます。ソフトウェアキーストアのデプロイモードでは、Cockpit の再起動後に封印された鍵素材が遅延的にボールトへ再インポートされます。HSM バックエンドの場合、鍵は HSM 内にとどまります。

ローテーション

Cockpit から鍵をローテーションすると、現在の鍵が非アクティブ化され、新しいアクティブな MEK が作成され、Oracle のローテーション SQL（ADMINISTER KEY MANAGEMENT SET KEY … WITH BACKUP）が返されます。以前にラップされたテーブルスペース鍵が引き続き復号可能であるよう、古い鍵は非アクティブのまま残されます。

状態マシン

Master-key state transitionsTEXT


pre_active → active → deactivated → revoked / destroyed

遷移はサーバー側で強制されます（pre_active 状態の鍵のみアクティブ化でき、破棄する前に非アクティブ化または失効させる必要があります）。

管理操作とプロキシ操作の認証の違い

PKCS#11 プロキシエンドポイントは、access_guid ベアラートークンのみによって認証されます。
管理操作（作成 / ローテーション / アクティブ化 / … ）には、適切なロールベースの権限を持つ Cockpit ユーザーセッションが必要であり、さらにアクセスポリシーの適用の対象となります。

API リファレンス

詳細な API エンドポイントは、Developer Docs → DKE API に別途記載されています。

次のステップ

続けて**PKCS#11 プロバイダーの構成（pkcs11.toml）** を参照し、プロバイダーを構成してください。

インテグレーションチェーン​

ローカルでの暗号処理なし

単一のエクスポートシンボル

Oracle TDE が使用する PKCS#11 操作​

暗号モデル​

マスター暗号鍵（MEK）のライフサイクル​

作成