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

５．データベースの暗号化を考える上での留意点

（1）暗号化はアクセス制御ではない：

特定の人に「見せたい」「見せたくない」という区別・制御を暗号機能で実現しようと考える方々を時折見かけますが、このような制御はアクセスコントロール機能によって行うべきです。そもそも暗号の「見せるか見せないか」という制御方法では「参照・更新・挿入・削除」といった多くの権限を制御しなければならないデータベースにおいて適切な権限管理はできません。加えてアクセスコントロール機能のほうが通常、性能への影響は小さくてすみます。

（2）厳密な暗号鍵の管理：

パスワードと同じで暗号鍵が漏えいしてしまうと復号（「復号化」と言わないことに注意）できてしまうため、定期的に交換（変更）することが望ましいとされています。PCIDSSの要件にも最低1年に1度は暗号鍵を交換しなければならないという記述があり、運用上の留意が必要な点となっています。

また鍵を紛失するとすべての暗号文が復号できなくなってしまうので、確実な保管とバックアップが必要です（もちろん暗号文を含んだデータベースそのもののバックアップデータと同じメディアに保管すると意味がないので、物理的に別のメディアにバックアップすることが必須です）。

こういった鍵管理については専用のアプライアンス製品なども存在します。金融機関など、高いセキュリティレベルを求められる場合、システムの要件によっては利用を考えても良いでしょう。

（3）性能に対する影響：

データベースに暗号化を適用した場合に最も気になるのが性能に対する影響です。そこで性能への影響を最小限にとどめるためには次のような考慮をする必要があります。

1. 暗号化対象の絞り込みを行う

性能への影響を最小限にするためには何でも暗号化するのではなく、漏えいした場合の影響や損害の大きさなどを考慮して暗号化対象を必要な部分だけに絞っていくことが重要です。通常データベースの暗号機能はデータファイル、表領域、表、列などかなり細かい単位まで設定できることが多いので、なるべく無駄な暗号化をしないような配慮が必要です。

2. アルゴリズムや鍵長、アーキテクチャを検討する

基本的には同一のアルゴリズムであれば、鍵の長さ（ビット長）が長くなるほど処理の負担が大きくなり性能に及ぼす影響が大きくなります。ただし暗号アルゴリズム自体の改善によって、AESでは古くから使われているDES、3DESと比べて、長い鍵長（256ビットなど）でも同等以上の性能を出すことができると言われています。
またアルゴリズムや鍵長が同じであっても、暗号機能のアーキテクチャ自体が違うと性能に対する影響は変わってきます。例えばアプリケーションから外部パッケージなどのプログラムを呼び出す方式をとるよりも、データベースの内部に実装されている方式が一般的に性能面では有利です。
こうした暗号機能自体のアーキテクチャ、利用するアルゴリズムと鍵長を加味して性能要件を満たすような設計をする必要があります。

3. ハードウエアとの組み合わせを検討する

最近、暗号機能の高速化を目的としてサーバーのCPUに暗号アルゴリズムAESを基本命令セットとして搭載したり、専用のアクセラレーション機能を備えたりする製品が登場しました。例えばインテル Xeonプロセッサー X5680に搭載されたAES-NI（Advanced Encryption Standard New Instructions）を使うと過去のCPUに比べて大幅な性能向上ができると言われており、従来暗号機能を利用しにくかった性能要件が厳しいデータベースについても適用できると期待されています。

６．2010年問題について

この記事が掲載される頃（2010年11月）には、そろそろ2010年もゴールが見えてくる時期だと思いますが、ときおり話題にのぼる「暗号の2010年問題」について、データベースの暗号化との関連を最後に付け加えておきたいと思います。

１）2010年問題とは？

NIST（米国立標準技術研究所）が米国連邦政府機関における利用暗号アルゴリズムを変更し、2010年をもって危殆化（きたいか）したアルゴリズムの使用を中止し、 移行することを各種ガイドラインとして示していることに起因して、「暗号アルゴリズムを変更しなければ」という動きが世界的に広がりつつあるようです。日本でもNISC（内閣官房セキュリティセンター）が方針を出したりしています。

NISTが2010年をもって移行することを表明しているのは以下のアルゴリズムです。

• 2-keyトリプルDES　→　3-keyトリプルDESまたはAES（AESのほうが今後は主流でしょう）
• RSA1024　→　RSA2048以上
• SHA-1　→　SHA-2※　（当面の暫定措置）

• ※SHA-2はSHA-224,256などの総称。ハッシュ値のビット長が異なる。

２）危殆化の意味あい

(１)暗号アルゴリズムが危殆化する、ということは概ね以下のようなことを意味します。

1. コンピュータの性能が向上したことで、「総当たり」で試しても現実的な時間とリソースで解読ができるようになってくること。
2. 暗号鍵を数学的な計算で算出して、暗号文を解読する攻撃方法が発見されること。共通鍵暗号では、さまざまな攻撃方法が既に発見されています。

（２）ハッシュアルゴリズムの危殆化とは概ね次のようなことを意味します。

1. 何らかの手段で「同じハッシュ値になる別々の元メッセージ」を算出できる場合に、元メッセージ自体の完全性に疑いが出てきてしまうこと（ハッシュ値の衝突）。意図的に同じハッシュ値となる元データの組み合わせを数学的に算出することができれば、攻撃に利用できる可能性が高くなります。SHA-1については2005年に中国人研究者によって攻撃方法が発見されています。
2. ハッシュアルゴリズムは一方向性関数で、ハッシュ値から逆に元のデータを算出することはできないわけですが、これを逆算出できてしまったら危険になります。ただし現時点でこの（数学的に）逆算する攻撃を完全に成功させたという話は聞きません。

３）データベースの暗号化と2010年問題

確かに暗号やハッシュ関数のアルゴリズムの安全性が低下しつつあることは事実ですが「2010年問題」という言い方をすると、あたかも2010年になるとそこら中の暗号が解読されてしまうかのような誤解を与えてしまう危険があります。基本的には鍵の長さを長くすることで概ね対応はできますし、攻撃方法があるといっても選択平文攻撃、既知平文攻撃などの既知の攻撃方法は、それなりに高度なスキルと一定量以上のサンプルデータが必要なので、2010年を過ぎると即座に攻撃を受けるというわけでもありません。

従って、システムの更新時や、アップグレード時などに段階的・計画的に順次移行していけば十分間に合う問題であるといえます。

また、ハッシュアルゴリズムについてNISTがSP 800-131（DRAFT）でSHA-1からの移行を表明しているのは、電子署名を生成するアプリケーションであって、それ以外は2010年以降も SHA-1を利用できることになっています。従って単にNISTの推奨事項を考えるのなら、データベースにおけるハッシュアルゴリズムの使用についてはあまり深刻に考えなくても良いと言えます。以下はSP800-131からの引用です。

NIST is proposing the following transition rules for hash functions (see Table 9).
Table 9: Hash Function Transitions

a　Includes digital signature verification, HMACs, KDFs, RNGs, and the approved integrity technique specified in Section 4.6.1 of FIPS 140-2.

表：SHA-1からのハッシュアルゴリズムの移行についてNISTが表明している内容（SP800-131より抜粋）

むしろ各アルゴリズムそのものの危殆化よりも、プログラム中での実装方法の問題に起因して暗号鍵が計算できてしまったり、ハッシュ値から平文のパスワードが逆算できてしまったりする脆弱性が生まれることのほうが、はるかに現実的で注意が必要です。

ただし「やっぱり心配」というエンドユーザがいる可能性はあるので、SIや保守・運用をされている方々は、それぞれのデータベース製品、暗号機能などで、どんなアルゴリズム・鍵長の設定ができるのかという点を一度点検してみても良いかも知れません。市場の主なデータベース製品の暗号機能ならば、ほとんどの場合設定変更などで対応できると思います。

このようにデータベースで暗号機能を使うためにはいくつかの留意点があるのは事実ですが、正しく設計・実装すれば十分に有効であり、今後さらなる活用が期待されています。