透過的データ暗号化（TDE）

TDEが解く問題：静止データの盗難耐性

データベースの脅威モデルには「稼働中のサーバーへの不正クエリ」だけでなく、「ディスク自体・バックアップファイル・スナップショットが盗まれる」ケースがあります。ディスクを物理的に抜き取られる、クラウドのスナップショットが誤って公開範囲を広げる、バックアップファイルが暗号化されないままオブジェクトストレージに置かれる——これらはSQLの権限制御では一切防げません。ファイルの中身がそのまま読めてしまうからです。

**透過的データ暗号化（TDE: Transparent Data Encryption）**は、この「静止データ（data at rest）」を狙う脅威に対して、ストレージエンジン自身がページ単位・ファイル単位でデータを暗号化することで応えます。「透過的」の意味は明確で、アプリケーションのSQL文もスキーマもインデックスも一切変更不要という点です。暗号化・復号はディスクI/Oの経路に挟み込まれ、バッファプールに載った時点ではすでに平文に戻っています。

鍵の階層：マスターキーとデータ暗号化キー

TDEの鍵管理は、エンベロープ暗号化と同じ二層構造を踏襲しますが、データベース製品ごとに固有の名称と実装があります。

• マスターキー（TDEプロテクタ、または暗号化の証明書）: サービス管理キーやHSM・外部KMS（Key Vault、KMSなど）で保護される最上位の鍵。頻繁には使われず、下位の鍵を保護する役割に専念する。
• データベース暗号化キー（DEK: Database Encryption Key）: データベースごとに1つ生成される対称鍵（多くはAES-256）で、実際のページ暗号化・復号を担う。DEK自体はマスターキーで暗号化（ラップ）された状態でデータベース内に保管される。

起動時にDBMSはまずマスターキーへアクセスし、暗号化されたDEKを復号してメモリに保持します。以降のページI/Oは、このメモリ上のDEKを使って行われ、マスターキーは以後の暗号化・復号処理には関与しません。

起動シーケンス:
  1. DBMSプロセスが起動
  2. マスターキー（HSM/KMS/証明書ストア）へアクセス要求
  3. 暗号化済みDEKをマスターキーで復号 → 平文DEKをメモリに保持
  4. 以降のページ読み書きはメモリ上のDEKでAES暗号化/復号

ページ書き込み経路:
  バッファプール(平文ページ) → 暗号化(DEKで) → ディスクへ書き込み(暗号文)

ページ読み込み経路:
  ディスク(暗号文) → 復号(DEKで) → バッファプール(平文ページ)

なぜページ単位・ファイル単位なのか

TDEが「行」や「値」ではなく「ページ」を暗号化単位に選ぶのには理由があります。ストレージエンジンは元々スロッテッドページや固定長ブロックの単位でI/Oを行っており、この既存のI/O境界に暗号化・復号を挟むだけで実装が完結するからです。ページ単位なら以下がすべて成立します。

• 索引構造ごと暗号化される: B+木のリーフページも内部ページも同じ経路を通るため、索引だけ平文で漏れるということがない。
• WAL（先行書き込みログ）も対象に含めやすい: ログレコードも同じディスク書き込み経路を通せば、クラッシュリカバリ用のログファイルから機微な値が漏れる経路を塞げる。
• バックアップファイルへの暗号化が自然に継続する: 物理バックアップ（ページの生コピー）はそのまま暗号化済みページをコピーするだけで済み、バックアップ先で改めて暗号化を意識する必要がない。論理バックアップ（SQLダンプなど）はサーバー内で復号された値をテキスト化するため、TDEの保護範囲外になる点には注意が必要。

パフォーマンスへの影響

TDEのオーバーヘッドは「暗号化・復号がどこで発生するか」を理解すると見積もりやすくなります。暗号化・復号はページがディスクとバッファプールの間を移動するタイミングでのみ発生し、すでにキャッシュ済みのページへの読み書きには一切コストがかかりません。したがって影響が最も出るのは次の状況です。

• バッファプールに載っていないページへの初回アクセス: ディスクからの読み込みのたびに復号処理が挟まる。
• チェックポイントやページの追い出し: ダーティページをディスクへ書き戻す際に暗号化処理が挟まる（チェックポイントの頻度が高いほど影響が積み重なる）。
• バックアップ取得・リストア: 全ページを走査するため、暗号化・復号のコストが最も顕著に表れる局面。

現代のCPUはAES-NIなどのハードウェア支援命令を持ち、AES-256の暗号化・復号をソフトウェア実装より一桁以上高速に処理できます。この支援があるハードウェアでは、TDE有効化によるオーバーヘッドは数%程度に収まることが多いとされます。逆に、AES-NIを持たない古い環境やソフトウェア実装のみの環境では、CPUバウンドなワークロードで無視できない劣化が起こり得ます。

列レベル暗号化との違い

TDEとしばしば混同されるのが**列レベル暗号化（column-level encryption）**です。両者は暗号化する単位も、失うものも異なります。

この違いは脅威モデルの違いに直結します。TDEは「ストレージ媒体そのものが漏れる」経路を塞ぎますが、SQLで接続できてしまう者（悪意ある内部関係者や、権限昇格した攻撃者）には無力です。逆に列レベル暗号化は特定カラムを強く守れますが、暗号化された値に対する等価検索以上の演算（範囲検索、LIKE、全文検索など）は原則として成立しません。暗号文は元の値の順序も部分一致も保存しないためです。実務では、TDEで基盤全体を面として守りつつ、特に機微な一部カラム（認証情報やマイナンバー相当のフィールドなど）だけ列レベル暗号化を重ねる多層防御が一般的です。

鍵ローテーション

TDEにおける鍵ローテーションは、マスターキーとDEKで意味合いが異なります。

• マスターキーのローテーション: 新しいマスターキーで既存のDEKを再ラップするだけで完了する。DEK自体は変わらず、実データの再暗号化は不要。これが二層構造の実利で、外側の鍵だけを軽量に更新できる。コンプライアンス要件（定期的な鍵更新義務）はこの操作で満たせることが多い。
• DEKのローテーション: 実データの暗号化に使う鍵そのものを変えるには、原則として全ページの復号・再暗号化が必要になる。これは全データの書き換えに等しく、コストと稼働影響が大きい。一部の実装はページごとに鍵世代（key version）を持たせ、バックグラウンドで段階的に再暗号化する仕組みを提供するが、対応は製品によって差が大きい。

マスターキーローテーション（軽量）:
  旧マスターキーでラップ済みDEK
    → 復号（旧マスターキーで）
    → 再ラップ（新マスターキーで）
  実データは無変更

DEKローテーション（重量）:
  全ページを走査
    → 旧DEKで復号 → 新DEKで再暗号化 → 書き戻し
  実質的に全データの書き換え

まとめ

TDEは、ストレージエンジンがページ・ファイル単位で暗号化を担うことで、アプリケーションやSQLに一切手を入れずに静止データを守る仕組みです。マスターキーがDEKを包む二層構造により、日常的な鍵の更新（マスターキーのローテーション）は軽量に、実データの暗号方式を変える重い操作（DEKのローテーション）とは切り離されています。性能への影響はAES-NIなどのハードウェア支援で数%程度に抑えられる一方、守れる範囲は「ディスク・バックアップの物理的漏洩」に限定され、SQL接続を通じた閲覧は防げません。列レベル暗号化とは守備範囲も検索性への影響も異なるため、両者は排他ではなく重ねて使うのが実務上の定石です。