OCI External Key Management

解決する課題

• 規制・主権要件により、暗号鍵の素材をクラウド事業者に預けたくない
• 既存のオンプレ/サードパーティ鍵管理基盤を引き続き利用しながらクラウドを使いたい
• 鍵の完全な所有・廃棄の主導権を自社に残したい（鍵を消せばクラウド側のデータも復号不能にできる）
• 複数環境で鍵管理ポリシーを一元化し、クラウド固有の鍵に分散させたくない

主要概念と用語

• External Key Management（外部鍵管理）: 鍵素材を OCI 内部の HSM ではなく、OCI 外部のサードパーティ鍵管理システムに保持したまま、OCI サービスの暗号化に利用する方式
• External KMS（外部 KMS）: 顧客側が運用する鍵管理基盤。代表例は Thales CipherTrust などの製品で、鍵素材はここに留まる
• External Key（外部鍵）: 外部 KMS 側に存在する鍵本体。OCI は鍵の参照とプロキシ呼び出しを行い、素材そのものは受け取らない
• OCI Vault との関係: OCI Vault（KMS）の鍵タイプの一つとして外部鍵を扱い、Vault が外部 KMS への暗号・復号要求を仲介する
• エンベロープ暗号化: 実データは DEK で暗号化し、その DEK の Wrap/Unwrap を外部鍵に依頼する。鍵素材は外部に留まったまま暗号操作だけが委譲される
• 接続経路（プロキシ）: OCI と外部 KMS の間を結ぶ接続。可用性と低遅延が暗号化対象サービスの動作に直結する
• OCI IAM ポリシー: manage keys / use keys などで外部鍵リソースへのアクセスを制御

仕様・制限・クォータ

• 鍵素材は外部 KMS 側に保持され、OCI には平文の鍵が渡らない（OCI は暗号操作の委譲のみ行う）
• リージョン単位のサービス。外部鍵は Vault のリソースとして該当リージョンで管理する
• 暗号化を行う各 OCI サービス（Object Storage 等のカスタマー管理鍵対応サービス）から外部鍵を参照できるが、対応サービスは限定的で、OCI 内部鍵より範囲が狭い場合がある
• 暗号・復号は外部 KMS への往復を伴うため、内部 HSM 鍵に比べ遅延が増え、スループット上限の影響を受けやすい
• 外部 KMS が停止すると暗号操作が失敗し、対象データへのアクセスが止まる。可用性は外部基盤の設計に強く依存する
• 対応する外部 KMS 製品・連携方式・上限値は変動するため、採用前に公式ドキュメントで適合性を確認する

内部の仕組み

External Key Management は、暗号操作を OCI から外部 KMS へ委譲（プロキシ）する構成です。OCI Vault は外部鍵を内部 HSM 鍵と同じ「鍵リソース」として扱いますが、暗号・復号の実体は OCI 内では完結しません。Encrypt や Decrypt、データキーの Wrap/Unwrap の要求が来ると、Vault は外部 KMS に対して当該操作を依頼し、結果だけを受け取って呼び出し元に返します。鍵素材そのものは終始外部 KMS の境界内に留まり、OCI 側に平文で渡ることはありません。

これはエンベロープ暗号化と組み合わさります。実データは高速な対称鍵（DEK）で暗号化し、その DEK のWrap（暗号化）/ Unwrap（復号）だけを外部鍵に依頼します。Object Storage のようなサービス統合では、バケットに外部鍵の OCID を指定すると、各オブジェクトの DEK の保護に外部鍵が使われます。すべての鍵参照・暗号操作は OCI Audit に記録され、「いつどの外部鍵で操作したか」を追跡できます。

設計パターン / ベストプラクティス

• 主権・規制要件で鍵素材を自社管理下に置く必要がある範囲だけ外部鍵を使い、それ以外は内部 HSM 鍵で簡素に保つ
• 外部 KMS を冗長構成にし、接続経路の障害が暗号操作全体を止めないよう可用性を設計
• IAM ポリシーで最小権限：アプリには use keys（暗号/復号のみ）、運用者には manage keys と用途で分離
• 外部 KMS 側の鍵ローテーション・廃棄ポリシーを明文化し、クラウド側の挙動（復号不能化）と整合させる
• レイテンシ影響を抑えるため、頻繁な暗号操作はDEK のキャッシュで外部 KMS 呼び出しを削減
• 重要データに使う前に、外部 KMS 停止時の影響範囲を検証環境で必ず確認する

運用・監視

• 外部鍵の参照・暗号操作は OCI Audit で監査し、必要に応じて OCI Logging / Events に連携
• 外部 KMS への接続状態・遅延・エラー率を継続監視し、しきい値超過で Notifications / Functions により通知・自動対応
• 復号失敗時は 外部 KMS の稼働状況・接続経路・IAM ポリシー・鍵の状態を切り分けて確認
• 外部 KMS 側のメンテナンスや鍵廃棄がクラウド側のデータ可用性に直結するため、変更管理を厳格化
• 災害時手順として、外部 KMS のバックアップ・フェイルオーバーと、クラウド側からの再接続手順を整備

コスト

具体的な単価は変動するため、最新の料金は公式の料金ページで確認してください。一般に、外部 KMS の運用コストと可用性確保のための投資が、OCI 内部鍵との主な差分になります。

セキュリティ

• 鍵素材は外部 KMS の境界内に留まり、OCI には平文の鍵が渡らない（クラウド事業者への鍵預託を避けられる）
• 鍵の廃棄を自社で主導でき、外部鍵を消せばクラウド側の対象データも復号不能にできる
• IAM ポリシーで最小権限を徹底し、use keys と manage keys を分離。コンパートメント単位でスコープを限定
• 外部 KMS への接続を保護し、経路の認証・暗号化と到達制御を厳格にする
• すべての外部鍵操作を OCI Audit で追跡可能にする

関連サービス・比較

外部鍵を持たない通常の鍵管理は OCI Vault（KMS）の内部 HSM 鍵が担います。両者は同じ Vault 上で扱える一方、鍵素材の所在と可用性の前提が異なります。

ハンズオン / CLI例

# 1. 外部鍵を扱う Vault を作成（外部鍵をサポートするタイプを指定）
oci kms management vault create \
  --compartment-id <compartment-ocid> \
  --display-name external-key-vault \
  --vault-type EXTERNAL

# 2. 外部 KMS 上の鍵を OCI に登録（外部鍵参照を作成）
#    --external-key-reference に外部 KMS 側の鍵 ID を指定する
oci kms management key create \
  --compartment-id <compartment-ocid> \
  --display-name app-external-key \
  --key-shape '{"algorithm":"AES","length":32}' \
  --protection-mode EXTERNAL \
  --external-key-reference '{"externalKeyId":"<external-kms-key-id>"}' \
  --endpoint <vault-management-endpoint>

# 3. 登録した外部鍵の状態を確認
oci kms management key get \
  --key-id <external-key-ocid> \
  --endpoint <vault-management-endpoint>

# 4. Object Storage バケットに外部鍵をカスタマー管理鍵として割り当て
oci os bucket update \
  --name my-bucket \
  --kms-key-id <external-key-ocid>

# 5. 外部鍵で暗号化（暗号操作は外部 KMS へ委譲される）
oci kms crypto encrypt \
  --key-id <external-key-ocid> \
  --plaintext "$(echo -n 'hello' | base64)" \
  --endpoint <vault-crypto-endpoint>