データベース内のデータが暗号化されている場合、たとえ流出したとしても「実質的に個人データ又は加工方法等が外部に漏えいしていないと判断される」とされるため、仮にデータの漏洩があったとしても報告の義務はない（ただし暗号化されているデータでも個人情報という扱いになるため、適切なセキュリティ対策を施さなくてはいけない）。
参考：
https://www.ppc.go.jp/files/pdf/iinkaikokuzi01.pdf
https://www.ppc.go.jp/files/pdf/guidelines01.pdf
そのため、重要な個人情報を扱う場合はデータベースの暗号化が必要となってくる。
データベースの暗号化には下記のような段階がある。
- アプリケーション側で暗号化してからデータベースに格納
- ストレージの暗号化
- データベース側の暗号化機能を使用
1. アプリケーション側で暗号化してからデータベースに格納
SELECT文などで検索する場合に、処理が複雑になり、アプリケーションの柔軟性やパフォーマンスを考慮するとなかなかすべてのデータ、アプリケーションに適用するのは難しい。
※そもそも上述のような場合には、復号化処理が必要となってくるため、アプリケーション単位で解析された場合には結局データが抜かれてしまうし、結局データベースにアクセスされた時点でさまざまなクラッキングがされる恐れがあるからアウト
よって、使い道としては、WordPressですでに導入されているようなパスワード部分などアプリケーション内で限定的な箇所の使用となる。
PHPの場合は、openssl_encrypt関数などを利用し可逆の暗号化を行う
パスワードなどは不可逆の暗号化（ハッシュ化）を「phpass」ライブラリ（WordPressで使ってる）などで実装する。
2. ストレージ暗号化
Amazon S3のストレージ暗号化など、システム（OS、ストレージ機器の機能）そのものを暗号化する方法。
内容としては、
暗号化前のデータがアプリケーションからOSに渡され、暗号キーを使用してデータを暗号化、その後データがストレージ（ファイルストレージ、データベース）に保存される。
読み込む場合は、暗号化されたデータをOSで読み込み、復号キーを利用してデータを復号、その後アプリケーションに引き渡される。
といった流れである。
つまり機器内の通信を暗号化するイメージなので、通信の盗聴しか防ぐことはできない。
OSからデータファイルを直接参照されてしまった場合には、防ぐことは不可能。
またその機能がある機器もクラウド上では多くないため、さほど使用頻度は高くない。
3. データベース側の暗号化機能を使用
透過的データ暗号化 – アプリケーションに変更を加えることなくデータベースへ格納するデータを暗号化する手法である。
データベースが内部的にデータを暗号化して格納し、暗号化されたデータを透過的に復号してアプリケーションに戻す仕組みのこと。
ただしデータベースのログデータには生のデータが保存されてしまうことがあるため、レプリケーション機構やエラー機構などのログに生データが残っていないか、またメモリ上のデータやキャッシュに注意する必要がある。
内容としては
暗号化前のデータがアプリケーションからデータベースに渡され、データベースが暗号キーによってデータを暗号化しデータベースに書き込む。
読み込む場合は、データベースが復号キーを使用してデータを復号し、そのデータをアプリケーションに引き渡すイメージ。
「2. ストレージ暗号化」がOS単位だったが、ミドルウェアであるデータベースが暗号化を担当する。
「2. ストレージ暗号化」と同様にOS単位でハックされたらデータを確認されてしまうが、「2. ストレージ暗号化」よりも対応範囲が大きく、アプリケーション側で使用を意識することはないため、手軽に導入できる。
以上から、データベースを暗号化する場合は、データベースの機能を使って暗号化し、特に重要なデータはアプリケーションベースで暗号化するというのが基本的な対応となる。