透過的暗号化（TDE）とPCI-DSSが絡む移行の地獄 — ダンプが平文になる罠と鍵管理

「本番DBはTDEで暗号化しているから安全」——移行を始めた瞬間、その安全は崩れます。暗号化されたデータをどこかに取り出す作業は、それだけで平文化のリスクを生み、カード情報が絡めばPCI-DSSの監査対象が一気に広がるからです。透過的暗号化とコンプライアンスが同居する移行の、地雷を順に見ていきます。

01TDEは「保存時」だけを守る — 取り出した瞬間が穴

Oracleの透過的暗号化（TDE）は、ディスク上のデータファイルを暗号化します。DBを経由してアクセスする限り透過的に復号されるので、アプリからは暗号化を意識せず使えます。問題は移行です。データを「取り出す」作業は、暗号化の外へデータを出す作業にほかなりません。ここに最初の穴が空きます。

02最大の罠 — Data Pumpのダンプはデフォルトで平文

これを知らずに進めると事故ります。TDEで暗号化されたテーブルをData Pump（expdp）でエクスポートすると、ダンプファイルはデフォルトで暗号化されません。TDEが守っていたのは「データファイル」であって、論理エクスポートの出力ではないからです。

つまり、ステージングサーバに置かれたダンプファイルの中には、カード番号（PAN）が平文で並ぶことになります。これはPCI-DSS上、明確なリスクです。対策は、expdpの暗号化オプション（ENCRYPTION / ENCRYPTION_PASSWORD 等）を使い、ダンプ自体を暗号化すること。そして暗号化パスワードの管理も、当然コンプライアンスの対象になります。

03鍵管理の引っ越し — ウォレットはコピーできない

TDEはマスター暗号鍵をウォレット（キーストア）で管理します。移行先で暗号化を継続するには、この鍵の扱いを決めなければなりません。RDS for OracleはTDEに対応していますが、オンプレのウォレットをそのままコピーして持ち込む運用にはならず、AWS側の鍵管理の枠組み（オプショングループやマネージドのキーストア、KMS連携）に載せ替えます。

PCI-DSSは鍵管理そのものに厳しい要件（鍵のローテーション、分割知識・二重管理、鍵管理者の権限分離など）を課します。オンプレのHSM/ウォレット運用から、AWS KMS / CloudHSMベースの運用へ移ると、鍵管理の手順書と統制を、監査人（QSA）に説明できる形で作り直す必要があります。これは技術作業というより統制設計の作業です。

04ステージング環境が丸ごとPCIスコープに入る

見落とされがちですが重大です。PCI-DSSの適用範囲（スコープ）は、カード会員データに「触れる」すべての環境に及びます。移行のために立てたステージングDB、ダンプを置くS3、転送に使う踏み台、そしてデバッグのために出力したログまで、カード情報が通過しうる経路はすべてスコープです。

• ステージングDB・変換用サーバ — 本番同等のセキュリティ統制が要る
• ダンプ・中間ファイルの保管先（S3等）— 暗号化・アクセス制御・確実な削除
• CDCレプリケーション（DMS/GoldenGate）の通信 — カード情報がネットワークを流れるため、転送時暗号化が必須（CDEがEC2上にある場合の暗号化・鍵管理は専用記事へ）
• ログ・トレース — うっかりカード番号を記録していないか

05非本番環境には、本番データを入れない

移行のテストや現行比較のために「本番データのコピー」を検証環境へ——これがPCI-DSSでは原則アウトです。カード情報を含むデータを非本番に置いた瞬間、その環境もスコープに入り、統制の網をかけ続ける羽目になります。

正道は静的データマスキングです。カード番号などの機微項目を、実データと同じ性質を保ったダミー値に置き換えたうえで検証環境に配る。これによりテスト環境をスコープ外に保てます。マスキングの設計（どの項目を、業務ロジックを壊さずどう置き換えるか）は、移行計画の独立タスクとして早めに着手してください。

—まとめ

TDE＋PCI-DSSの移行は、技術より統制が主役です。ダンプは平文になる前提で暗号化し、鍵管理はKMS/CloudHSMベースで再設計してQSAに説明できる形にし、ステージングとログを含む全経路をスコープとして統制し、非本番はマスキングでスコープ外に保つ。「暗号化しているから安全」で始めた移行が、平文ダンプ1個で監査指摘の山になる——この地獄は、設計段階で全部避けられます。当社はPCI-DSS対象環境の設計・運用の経験があり、この地雷原を通した実績があります。