CDEがEC2にあるときの暗号化 — TDEの自前管理とCipherTrust等サードパーティ鍵管理

前回のTDE×PCI-DSSの記事はマネージドのRDSを主に扱いました。しかし現実には、要件や制約からCDE（カード会員データ環境）をEC2上に構築するケースがあります。この瞬間、暗号化と鍵管理は「AWSが面倒を見てくれるもの」から「自分で組み立てるもの」に変わります。ここで多くの現場がサードパーティ製品を必要とします。その理由と選定の勘所を書きます。

01まず切り分け — RDSかEC2か

CDEを載せるDBが、マネージドのRDSか、EC2上の自前DBかで、暗号化の責任分界がまるで違います。

• RDS — TDEやストレージ暗号化がサービスの枠組みで提供され、鍵管理もAWSの仕組み（KMS等）に乗る。楽だが制御は限定的
• EC2上の自前DB — 暗号化の方式も鍵管理もすべて自分の責任。自由度は高いが、PCI-DSSに耐える暗号化・鍵管理スタックを自分で組む必要がある

「特殊なDB構成が必要」「SYSDBAが要る」「マネージドの制約を受けたくない」といった理由でEC2を選んだ瞬間、この記事の世界に入ります。

02EBS暗号化（KMS）だけでは足りないことがある

EC2のディスクはEBS暗号化（KMSバックド）で保存時暗号化できます。これは有用で必須級ですが、ボリューム丸ごとの暗号化であり、PCI-DSSが求める「カード会員データそのものの暗号化」と「厳格な鍵管理」を、そのままフル充足するとは限りません。

• EBS暗号化はボリューム層。DBの中の特定データ（PAN）を狙って暗号化・アクセス制御する粒度ではない
• PCI-DSSの鍵管理要件——鍵のローテーション、職務分離（二重管理・分割知識）、鍵管理者の権限分離、監査——を、KMSの標準運用だけでどこまで満たすかは、要件解釈とQSAの判断による
• アプリ層・DB層での暗号化（TDEやカラム暗号化）を、EBS暗号化に「加えて」求められることがある

03Oracle TDEを自前で回す — ウォレットと鍵の運用

EC2上のOracleでカード情報を暗号化するなら、Oracle TDE（表領域/カラム暗号化）を自分で構成・運用することになります。マネージドのRDSと違い、マスター鍵を保持するウォレット（キーストア）の作成・保護・バックアップ・ローテーションを、すべて自分の手順として設計しなければなりません。

そして、そのウォレットをEC2のローカルに平置きするのは、PCI-DSSの鍵管理の観点で弱い。鍵をどこで、どう守るか——ここでハードウェアセキュリティモジュール（HSM）や外部の鍵管理が視野に入ります。

04サードパーティの出番 — CipherTrust等の透過暗号化＋鍵管理

EC2上のCDEで、PCI-DSSに耐える暗号化・鍵管理を組むとき、Thales CipherTrust（旧Vormetric）のようなサードパーティ製品が有力な選択肢になります。これらが提供するのは、単なる暗号化ではなく「透過的な暗号化」＋「集中管理された鍵管理」＋「職務分離と監査」の一式です。

• ファイル/ボリューム/DBレベルの透過暗号化を、アプリを改修せずにかける
• 鍵を一元管理し、ローテーション・アクセス制御・監査ログを製品として提供（KMIP対応など）
• 鍵管理者とシステム管理者の権限を分離し、PCI-DSSが求める職務分離を実現しやすい
• Oracle TDEの鍵管理バックエンドとして外部鍵管理（Oracle Key Vaultや対応する外部KMS/HSM）を使う構成もある

※製品の具体的な機能・対応範囲・PCI-DSSへの適合は、バージョンと構成、そしてQSAの判断により異なります。導入前に要件との突き合わせを必ず行ってください。

05CloudHSMという選択肢と、KMSとの組み合わせ

AWS側の選択肢としては、専有のハードウェアHSMであるCloudHSMがあります。FIPS準拠のHSMで鍵を保持し、KMSのカスタムキーストアのバックエンドにする構成や、アプリ/DBの暗号鍵をCloudHSMで管理する構成が取れます。

判断はおおむね、①マネージドで済むならRDS＋KMS、②EC2上のCDEで強い鍵管理と職務分離が要るならCipherTrust等のサードパーティ、またはCloudHSMベース、という整理になります。鍵管理の強度・職務分離・監査・QSA受容性が、どこに寄せるかを決める軸です。

06選定の軸

• 暗号化の粒度 — ボリューム／ファイル／DBカラム、どの層が要件か
• 鍵管理の強度 — ローテーション自動化、職務分離、分割知識・二重管理
• HSMバッキング — FIPS準拠のHSMで鍵を守る必要があるか
• 監査と可視化 — 鍵の利用・アクセスの証跡（PCIスコープと地続き）
• 性能オーバーヘッド — 透過暗号化のI/O影響を本番同等で検証
• QSAの受容性 — その構成で監査を通せるか。これが最終判断

—まとめ

CDEをEC2に置いた瞬間、暗号化と鍵管理は自分の責任になります。EBS暗号化は土台の1枚にすぎず、PCI-DSSが求める鍵管理の強度・職務分離・監査までを満たすには、Oracle TDEの自前運用に加え、CipherTrust等のサードパーティや、CloudHSMといった鍵管理の柱が要ることが多い。マネージドのRDSなら見えなかったこの一式を、EC2では自分で設計・選定・検証しなければなりません。「暗号化しているから大丈夫」で済まないのがCDE-on-EC2の世界です。要件とQSAを起点に、鍵管理から逆算して設計してください。