データベースの個人情報暗号化ガイド｜方式・実装手順・鍵管理まで
個人情報の漏えい事故は年々増加傾向にあります。個人情報保護委員会の令和5年度年次報告によると、2023年度の漏えい等事案の報告件数は1万3,279件と過去最多を更新しました（出典: 個人情報保護委員会 令和5年度年次報告）。データベース（DB）に格納された個人情報をどのように暗号化で守るかは、いまやあらゆる企業にとって避けて通れない課題です。 この記事では、DB暗号化の3つの方式の違いから、主要RDBMSごとの具体的な設定手順、鍵管理のベストプラクティスまでを体系的にまとめています。 データベース暗号化の基本的な仕組み DB暗号化とは、データベースに格納されたデータを暗号アルゴリズムで変換し、正規の鍵を持たない第三者がデータを読み取れないようにする技術です。暗号化されたデータは、復号鍵がなければ意味のない文字列として表示されます。 暗号化・復号のプロセスは次の3ステップで構成されます。 暗号化（Encryption）: 平文データを暗号アルゴリズムと暗号鍵を使って暗号文に変換 鍵管理（Key Management）: 暗号鍵の生成・保管・ローテーション・廃棄をライフサイクル全体で統制 復号（Decryption）: 正当な権限を持つユーザーやアプリケーションが暗号鍵を用いてデータを元の平文に戻す 暗号化だけではセキュリティは完結しません。アクセス制御・監査ログ・ネットワーク暗号化と組み合わせた多層防御が前提となります。 個人情報保護法が求める暗号化の位置づけ 個人情報保護法そのものに「暗号化を義務付ける」条文はありません。ただし、個人情報保護委員会が公表している「個人情報の保護に関する法律についてのガイドライン（通則編）」では、安全管理措置の具体例として暗号化が繰り返し言及されています。 特に重要なのは以下の2点です。 漏えい等報告の軽減要件: 2022年4月施行の改正法により、漏えい等が発生した場合に個人情報保護委員会への報告と本人通知が義務化されました。ただし「高度な暗号化その他の個人の権利利益を保護するために必要な措置」が講じられていた場合は、報告義務の対象外となる可能性があります（出典: 個人情報保護委員会 ガイドライン通則編） 技術的安全管理措置: ガイドラインでは、個人データを含む通信やファイルの暗号化が推奨される安全管理措置の一つとして挙げられています つまり、法律上は義務ではないものの、暗号化を実施していないと漏えい時のリスクが大幅に高まります。実務上は「やらない理由がない」対策と言えます。 PCI DSS v4.0における暗号化要件 クレジットカード情報を扱う事業者はPCI DSS（Payment Card Industry Data Security Standard）への準拠が求められます。PCI DSS v4.0（2025年3月31日に旧バージョンv3.2.1が完全廃止）では、保存データの暗号化に関して以下の要件が定められています。 要件番号 内容 3.5 PAN（カード番号）は保存時に判読不能にする 3.5.1.2 ディスク暗号化の場合はリムーバブル媒体のみ単独使用可。非リムーバブル媒体では他の暗号化手段（カラム・ファイルレベル等）との併用が必要 3.6 暗号鍵の管理手順を文書化し、最小権限の原則で運用する 3.7 鍵管理ポリシーに暗号期間・ローテーション間隔を含める PCI DSS v4.0では、ディスクレベルの暗号化（BitLocker等）だけでは要件3.5.1.2を満たせません。非リムーバブル媒体のデータ保護には、カラム暗号化やファイルレベル暗号化など、より粒度の細かい暗号化手段を組み合わせる必要があります。 DB暗号化の3つの方式を比較する DB暗号化の実現手段は大きく3つに分類できます。それぞれ暗号化レイヤーが異なるため、保護範囲・パフォーマンス影響・運用負荷が変わってきます。 方式1: 透過的データ暗号化（TDE） TDE（Transparent Data Encryption）は、DBMS自身がストレージへの書き込み時に自動で暗号化し、読み取り時に自動で復号する方式です。アプリケーション側の改修は不要で、SQLクエリも通常通り実行できます。 保護対象: データファイル、バックアップファイル、トランザクションログ 保護できない範囲: メモリ上のデータ、ネットワーク上の通信データ TDEはストレージの物理的な窃取やバックアップメディアの盗難に対しては有効ですが、DBサーバーにログインできる攻撃者に対しては防御力がありません。SQLインジェクション経由のデータ窃取も防げない点に注意が必要です。 方式2: カラム（列）レベル暗号化 特定のカラムに対して暗号化を適用する方式です。氏名・電話番号・クレジットカード番号など、個人情報を含む列だけを選択的に暗号化できます。 保護対象: 指定したカラムのデータ（メモリ上を含む場合あり） トレードオフ: 暗号化されたカラムに対するインデックス検索やLIKE検索が制限される カラム暗号化の最大の課題は検索性の低下です。暗号化されたカラムに対して WHERE name = '山田太郎' のような完全一致検索を行う場合、検索値も同じ方法で暗号化してから比較する必要があります。部分一致検索（LIKE句）は基本的に不可能となるため、設計段階での検討が欠かせません。 ...