データベースに関わる暗号化を考える

３．コンプライアンス要件について考える

セキュリティに関連する各種法制度・ガイドラインなどには、データの暗号化を求めているものがあります。例えばクレジットカード業界に普及しつつあるセキュリティ基準・PCIDSSではカード会員情報（カード番号など）を暗号化することや、一定期間ごとに鍵の交換を行うことなどが要求されています。

3.4 以下の手法を使用して、すべての保存場所で PAN を少なくとも読み取り不能にする（ポータブルデジタルメディア、バックアップメディア、ログのデータを含む）。
3.5 カード会員データの暗号化に使用される暗号化キーを、漏えいと誤使用から保護する。
3.6 カード会員データの暗号化に使用されるキーの管理プロセスおよび手順をすべて文書化し、実装する。
 　
出典：「 PCI（Payment Card Industry） データセキュリティ基準 PCI DSS ナビゲート （バージョン1.2）」 から抜粋

また経済産業省の個人情報保護ガイドラインにおいても、個人情報が漏えいした場合などに「高度な暗号化が行われていた場合」は本人（個人情報の持ち主）への連絡を省略しても良いとされています。このことは、万一何らかの漏えい事件・事故が発生した場合に企業が負担しなければならない対応コスト（個人に連絡するための告知や、専用フリーダイヤルの設置、メール配信など）を大幅に削減できる可能性があることを意味しており、具体的な個人情報漏えいにかかわる経済的リスクを低減できると考えられます。

例えば、以下のように、本人の権利利益が侵害されておらず、今後も権利利益の侵害の可能性がないまたは極めて小さいと考えられる場合には、本人への連絡を省略しても構わないものと考えられる。
・紛失等した個人データを、第三者に見られることなく、速やかに回収した場合
・高度な暗号化等の秘匿化が施されている場合（ただし、（オ）に定める報告の際、高度な暗号化等の秘匿化として施していた措置内容を具体的に報告すること。）
 　
出典：「個人情報の保護に関する法律についての経済産業分野を対象とするガイドライン」

これらのコンプライアンス要件を満たすためにデータベースに格納するデータを暗号化する必要が出てくるケースは今後さらに増えていくと考えられています。

４．暗号機能のしくみ

データベースが持つ暗号化機能は構造として、以下の2つに大別されます。

1. データベースのエンジン部分に内蔵されているもの
2. 外部にパッケージなどの専用プログラムを持ち、これらを呼び出して利用するもの

また、これとは別に外部的にデータベースに対して暗号機能を付加するような専用製品やアプライアンス製品なども存在します。

暗号アルゴリズムについては通常共通鍵暗号方式を利用しており、共通鍵暗号の中で現在最も主流なのは米国の国立標準技術研究所（National Institute of Standards and Technology：NIST）で標準化されているAES方式でしょう。現在市場にあるデータベース製品の多くはAESや3DESといったブロック暗号またはRC4のようなストリーム暗号のアルゴリズムをサポートしていますが、データベースは文字や数字などの比較的バイト長が短いデータ型を取り扱うことが多いことなどから、どちらかといえばブロック暗号のほうが主流になっています。

またブロック暗号には、数種類のブロック暗号モードがあり、それぞれCBC、CFB、OFB、ECBと呼ばれています。データベース製品などの機能によっては選択・設定できるものがあり、その場合はCBCモードが使われるケースが多いと思われます。

その理由は、ある平文が常に同じ暗号文になってしまうと、その出現頻度を分析するなどの攻撃方法で解読される可能性があり、暗号としての強度が下がる危険があるからです。そのためCBCモードではInitial Vector（IV）というビット列を使って同じ平文が常に異なる暗号文になるようにして暗号強度を高める実装が行われています。

暗号鍵の管理についてはデータベース製品が独自に鍵管理のしくみを持つ場合や、ツールキットなどの形で提供されてユーザー側が任意に設計・開発を行うものなどがあります。また高度な鍵管理の方法として専用の外部ハードウエア（HSM：Hardware Security Module）を利用することもできます。

いずれにしても限られたセキュリティ管理者以外は暗号鍵にアクセスできないように厳密なアクセスコントロールを行う必要があります。