データベースの個人情報暗号化ガイド｜方式・実装手順・鍵管理まで

個人情報の漏えい事故は年々増加傾向にあります。個人情報保護委員会の令和5年度年次報告によると、2023年度の漏えい等事案の報告件数は1万3,279件と過去最多を更新しました（出典: 個人情報保護委員会 令和5年度年次報告）。データベース（DB）に格納された個人情報をどのように暗号化で守るかは、いまやあらゆる企業にとって避けて通れない課題です。

この記事では、DB暗号化の3つの方式の違いから、主要RDBMSごとの具体的な設定手順、鍵管理のベストプラクティスまでを体系的にまとめています。

データベース暗号化の基本的な仕組み

DB暗号化とは、データベースに格納されたデータを暗号アルゴリズムで変換し、正規の鍵を持たない第三者がデータを読み取れないようにする技術です。暗号化されたデータは、復号鍵がなければ意味のない文字列として表示されます。

暗号化・復号のプロセスは次の3ステップで構成されます。

1. 暗号化（Encryption）: 平文データを暗号アルゴリズムと暗号鍵を使って暗号文に変換
2. 鍵管理（Key Management）: 暗号鍵の生成・保管・ローテーション・廃棄をライフサイクル全体で統制
3. 復号（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が完全廃止）では、保存データの暗号化に関して以下の要件が定められています。

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句）は基本的に不可能となるため、設計段階での検討が欠かせません。

方式3: アプリケーション層暗号化

アプリケーション側で暗号化・復号を行い、DBにはすでに暗号化されたデータを格納する方式です。DBMSの種類やバージョンに依存せず、暗号化ロジックを自由に制御できます。

保護対象: DBストレージ、バックアップ、ネットワーク通信、メモリ上のDB側データ トレードオフ: アプリケーション改修が必須、鍵管理をアプリ側で実装する必要がある

3方式の比較一覧

用途に応じた使い分けの目安は次の通りです。

• まず導入したい場合 → TDE（最小限の変更で保存データ全体を保護）
• 特定の機密列を重点的に守りたい場合 → カラム暗号化
• DBサーバー自体が信頼できない環境の場合 → アプリ層暗号化

主要RDBMS別の暗号化実装ガイド

各RDBMSで提供されている暗号化機能と、その有効化手順を整理します。

PostgreSQLの暗号化オプション

PostgreSQLはTDEを標準機能として搭載していませんが、拡張モジュールやサードパーティソリューションで対応できます。

pgcryptoモジュールによるカラム暗号化

pgcryptoはPostgreSQLの標準拡張で、対称鍵暗号（AES）と公開鍵暗号（PGP）の両方に対応しています。

-- pgcryptoの有効化
CREATE EXTENSION IF NOT EXISTS pgcrypto;

-- AES暗号化によるデータ挿入
INSERT INTO users (name, email_encrypted)
VALUES (
  '田中一郎',
  pgp_sym_encrypt('tanaka@example.com', 'my-secret-key')
);

-- 復号して取得
SELECT name, pgp_sym_decrypt(email_encrypted::bytea, 'my-secret-key') AS email
FROM users;

TDEの実現方法

PostgreSQL本体にはTDE機能がありませんが、以下の手段で同等の保護を実現できます。

• NEC Transparent Data Encryption for PostgreSQL: 商用拡張で、テーブルスペース単位の透過暗号化を提供（出典: NEC PostgreSQL TDE）
• Fujitsu Enterprise Postgres: PostgreSQLベースの商用DBで、TDEを標準搭載（出典: Fujitsu）
• ファイルシステム暗号化（dm-crypt/LUKS）: OS層での透過暗号化

MySQLの暗号化オプション

MySQLはInnoDB Tablespace Encryption（TDE相当）と、関数による行レベル暗号化の両方をサポートしています。

InnoDB テーブルスペース暗号化（TDE）

MySQL 5.7.11以降で利用可能です。keyringプラグインと組み合わせて使用します。

-- keyringプラグインの設定（my.cnfに記載）
-- early-plugin-load=keyring_file.so
-- keyring_file_data=/var/lib/mysql-keyring/keyring

-- テーブル作成時に暗号化を指定
CREATE TABLE personal_info (
  id INT AUTO_INCREMENT PRIMARY KEY,
  full_name VARCHAR(100),
  phone VARCHAR(20),
  address TEXT
) ENCRYPTION='Y';

-- 既存テーブルへの暗号化適用
ALTER TABLE personal_info ENCRYPTION='Y';

AES_ENCRYPT/AES_DECRYPT関数によるカラム暗号化

-- 暗号化して挿入
INSERT INTO users (name, email_encrypted)
VALUES (
  '佐藤花子',
  AES_ENCRYPT('sato@example.com', 'encryption-key-here')
);

-- 復号して取得
SELECT name, AES_DECRYPT(email_encrypted, 'encryption-key-here') AS email
FROM users;

MySQLのAES_ENCRYPT関数はデフォルトでAES-128-ECBモードを使用します。ECBモードは同じ平文ブロックが同じ暗号文になるため安全性に課題があります。block_encryption_modeシステム変数をaes-256-cbcに設定することを推奨します。

Oracle Databaseの暗号化オプション

Oracle DatabaseはTDE（Transparent Data Encryption）を提供しており、列レベルとテーブルスペースレベルの暗号化が選択できます。

TDEの有効化

-- ウォレットの作成と開放
ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/opt/oracle/wallet'
  IDENTIFIED BY "wallet_password";

ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN
  IDENTIFIED BY "wallet_password";

-- マスター暗号化鍵の作成
ADMINISTER KEY MANAGEMENT SET KEY
  IDENTIFIED BY "wallet_password"
  WITH BACKUP;

-- テーブルスペース暗号化
CREATE TABLESPACE secure_ts
  DATAFILE '/opt/oracle/oradata/secure01.dbf' SIZE 100M
  ENCRYPTION USING 'AES256'
  DEFAULT STORAGE(ENCRYPT);

-- 列レベル暗号化
ALTER TABLE employees
  MODIFY (salary ENCRYPT USING 'AES256' NO SALT);

Oracle TDEの利用にはAdvanced Security Option（ASO）のライセンスが別途必要です。19c以降、ネットワーク暗号化（Native Network Encryption）はEnterprise Editionに含まれるようになりましたが、TDE（保存データ暗号化）にはAdvanced Securityライセンスが引き続き必要となります。

SQL Serverの暗号化オプション

SQL ServerはTDE、Always Encrypted、列レベル暗号化の3つの方式を提供しています。

TDEの有効化

-- マスターキーの作成
USE master;
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'StrongP@ssw0rd!';

-- 証明書の作成
CREATE CERTIFICATE TDECert WITH SUBJECT = 'TDE Certificate';

-- データベース暗号化キーの作成
USE YourDatabase;
CREATE DATABASE ENCRYPTION KEY
  WITH ALGORITHM = AES_256
  ENCRYPTION BY SERVER CERTIFICATE TDECert;

-- 暗号化の有効化
ALTER DATABASE YourDatabase SET ENCRYPTION ON;

-- 暗号化状態の確認
SELECT db.name, dm.encryption_state, dm.percent_complete
FROM sys.dm_database_encryption_keys dm
JOIN sys.databases db ON dm.database_id = db.database_id;

Always Encrypted

Always EncryptedはSQL Server 2016以降で利用できる機能で、クライアント側でデータの暗号化・復号を行います。DBサーバー管理者でさえ平文データを閲覧できないため、クラウド環境での利用に適しています。

AWS RDSの暗号化

AWS RDSでは、インスタンス作成時にKMS（Key Management Service）を使った保存時暗号化を設定できます。

重要なポイント:

• 暗号化はインスタンス作成時にのみ設定可能です（後から既存インスタンスを直接暗号化することはできません）
• 既存の暗号化なしインスタンスを暗号化するには、スナップショットを取得 → 暗号化コピー → 新インスタンスとしてリストアという手順が必要です
• RDS暗号化はAES-256を使用し、パフォーマンス影響は最小限（AWS公式ドキュメントでは「影響はほとんどない」と記載）です（出典: AWS RDS 暗号化ドキュメント）
• 2024年以降に作成される新規RDSインスタンスはデフォルトで暗号化が有効になっています

# AWS CLIでの暗号化インスタンス作成例
aws rds create-db-instance \
  --db-instance-identifier my-encrypted-db \
  --db-instance-class db.r6g.large \
  --engine postgres \
  --storage-encrypted \
  --kms-key-id arn:aws:kms:ap-northeast-1:123456789:key/your-key-id \
  --master-username admin \
  --master-user-password 'YourPassword'

暗号アルゴリズムの選定基準

DB暗号化で使用するアルゴリズムは、CRYPTREC（暗号技術検討会）の「電子政府推奨暗号リスト」に掲載されているものを選ぶのが安全です。

推奨される暗号アルゴリズム

AES-256-CBCまたはAES-256-GCMが現在の標準的な選択肢です。GCM（Galois/Counter Mode）は暗号化と認証を同時に行えるため、改ざん検知も必要な場合に適しています。

避けるべきアルゴリズム

• DES / 3DES: 鍵長が短く、現在は安全とみなされていません。NISTは2023年12月末をもって3DES（TDEA）の新規暗号化での使用を禁止しました（SP 800-67 Rev.2の撤回）
• RC4: ストリーム暗号の一種ですが、既知の脆弱性が複数報告されており使用禁止です
• ECBモード: ブロック暗号のモードの一つですが、同一平文が同一暗号文になるため暗号化パターンが漏れます

暗号鍵管理の実務ポイント

暗号化の強度は鍵管理の質で決まります。強力なアルゴリズムを使っていても、鍵の保管方法が不適切であれば暗号化の意味がなくなります。

鍵管理で守るべき5つの原則

1. 鍵とデータを分離する: 暗号化されたデータと同じストレージに暗号鍵を保管してはいけません。DBサーバーとは物理的・論理的に分離された鍵管理サーバー（KMS）やHSM（Hardware Security Module）を使います
2. 鍵のローテーション計画を立てる: 暗号鍵は定期的に更新します。PCI DSS v4.0では暗号期間（cryptoperiod）の設定を要件としています。一般的には1年ごとの更新が推奨されます
3. 鍵のバックアップを確保する: 鍵を紛失するとデータの復号が不可能になります。鍵のバックアップは暗号化した上で安全な場所に保管し、復旧手順を文書化します
4. 最小権限の原則を適用する: 暗号鍵へのアクセス権限はデータの暗号化・復号に必要な最小限の担当者・サービスアカウントに限定します
5. 鍵の廃棄手順を定める: 不要になった鍵は安全に消去します。鍵の廃棄はデータの廃棄と同義であるため、復号不可能なことを確認してから実施します

鍵管理サービスの選択肢

DB暗号化がパフォーマンスに与える影響

「暗号化するとDBが遅くなるのでは」という懸念は、DB暗号化の導入をためらう最大の理由の一つです。実際のパフォーマンス影響は方式とワークロードによって異なります。

方式別のパフォーマンス影響目安

• TDE: 一般的に3〜10%程度のオーバーヘッド。Intel AES-NI命令セットに対応した現代のCPUでは、暗号化・復号処理がハードウェアアクセラレーションで高速化されるため、体感できないレベルに収まることが多いです
• カラム暗号化: 暗号化対象のカラムへのアクセス時のみオーバーヘッドが発生。対象カラム数や暗号化方式によりますが、10〜30%程度の影響が出る場合があります
• アプリ層暗号化: アプリケーション側のCPUリソースを消費します。大量データの一括暗号化時にはバッチ処理時間が延びる可能性があります

パフォーマンス低下を抑える工夫

• AES-NI対応CPUの使用: ハードウェアレベルでAES演算を高速化。EC2の場合、ほぼ全てのインスタンスタイプが対応しています
• 暗号化対象の絞り込み: 全テーブルではなく、個人情報を含むテーブル・カラムだけを暗号化対象にすることで影響を最小限に抑えられます
• SSDストレージの活用: TDEではI/O操作に暗号化処理が加わるため、高速なSSDストレージを使用することでボトルネックを回避できます
• 接続プーリングの最適化: 暗号化・復号のセッション確立コストを抑えるために、接続プーリングの設定を見直します

DB暗号化を導入する際の注意点

暗号化だけでは守れない脅威

DB暗号化は万能ではありません。以下の脅威に対しては別の対策が必要です。

• SQLインジェクション: TDEを適用していても、アプリケーションの脆弱性を突かれた場合はDBの正規のアクセス経路でデータを取得されるため、暗号化データが復号された状態で漏えいします。WAF（Web Application Firewall）やパラメータ化クエリによる対策が必要です
• 内部不正: DBの正規権限を持つ管理者による不正アクセスはTDEでは防げません。Always Encryptedのようなクライアント側暗号化、または監査ログと組み合わせた運用が有効です
• メモリダンプ攻撃: TDEの場合、メモリ上のデータは平文です。Spectre/Meltdownなどのサイドチャネル攻撃や、メモリダンプの取得によって復号済みデータが漏えいするリスクがあります

バックアップとDR（災害復旧）への影響

暗号化されたDBのバックアップは、復元時にも同じ暗号鍵が必要です。以下の点を事前に確認してください。

• 暗号鍵のバックアップは別拠点に保管しているか
• DRサイトで暗号鍵にアクセスできるか
• 鍵のローテーション後も旧バックアップを復元できるか（旧鍵の保管期間を定める）

既存DBへの暗号化適用

稼働中のDBに暗号化を後から適用する場合は、ダウンタイムやデータ移行の計画が必要です。

• TDE: 多くのDBMSでオンライン（稼働中）での有効化が可能ですが、初回の暗号化変換時にI/O負荷が上がります。メンテナンスウィンドウでの実施を推奨します
• カラム暗号化: 既存データの暗号化変換（マイグレーション）が必要です。データ量に応じてバッチ処理時間を見積もります
• アプリ層暗号化: アプリケーションコードの改修とデータ移行が必要です。段階的な移行（デュアルライト方式）を検討します

暗号化対象カラムの選定方法

全てのカラムを暗号化するとパフォーマンスに大きな影響が出るため、暗号化対象を適切に選定することが重要です。

暗号化が必要なデータの分類

パスワードについては暗号化（復号可能）ではなく、bcryptやArgon2idによるハッシュ化（一方向変換）を採用するのが正しいアプローチです。パスワードは復号する必要がなく、ハッシュ値の比較で認証を行います。

導入ステップの全体像

DB暗号化プロジェクトの一般的な進め方を5段階で示します。

ステップ1: データ棚卸しと分類

DBに格納されているデータを洗い出し、個人情報や機密情報に該当するテーブル・カラムを特定します。データフロー図を作成し、暗号化が必要な箇所を可視化します。

ステップ2: 暗号化方式の選定

業務要件・パフォーマンス要件・コンプライアンス要件を踏まえ、TDE/カラム暗号化/アプリ層暗号化のいずれか（または組み合わせ）を選定します。検索要件（暗号化カラムに対する検索が必要か）が方式選定の最大のポイントです。

ステップ3: 鍵管理基盤の構築

暗号鍵の生成・保管・ローテーション・廃棄の運用フローを設計します。クラウド環境であればマネージドKMSの利用が合理的です。オンプレミス環境ではHSMの導入を検討します。

ステップ4: 検証環境での動作確認

本番環境と同等の検証環境で暗号化を有効化し、以下を確認します。

• アプリケーションの正常動作
• クエリのパフォーマンス（暗号化前後の比較）
• バックアップ・リストアの正常動作
• 鍵ローテーション時の挙動

ステップ5: 本番適用とモニタリング

メンテナンスウィンドウを設けて本番環境に暗号化を適用します。適用後はクエリレスポンスタイム・CPU使用率・ディスクI/Oを継続的にモニタリングし、異常がないか確認します。

まとめ

DB暗号化は、個人情報保護法やPCI DSSへの対応だけでなく、データ漏えい時の被害を最小化するための実践的な防御手段です。TDE・カラム暗号化・アプリ層暗号化の3方式にはそれぞれ得意な保護範囲と制約があるため、自社のデータ構成とセキュリティ要件に合った方式を選ぶ必要があります。

暗号化の実装自体は各DBMSが機能を提供しているため技術的なハードルは高くありません。むしろ、鍵管理の運用設計・暗号化対象の選定・パフォーマンス影響の評価といった「暗号化の周辺」こそが、プロジェクト成功の鍵を握るポイントです。