これだけは押さえたい! データベースセキュリティ(6) 守りも万全! データベースの暗号化のポイントを考える

データベースのセキュリティについて解説する本連載。前々回、前回と2回にわたり、データベース監査の設計を紹介しましたが、今回はセキュリティと言えば、必ず検討に上がる「暗号化」、特にデータベースの暗号化について説明します。

データベースの暗号化は何を隠す?

暗号化は他人に文字列の内容を読み取れなくするためのものと言われますが、その起源は古代ローマのシーザー暗号までさかのぼります。シーザー暗号は元の文字列をずらすことで、その文字列の意味をわからなくするという暗号化です。例えば、筆者の名前「ますだ」を1文字ごとに平仮名を2つずつずらすと「むそづ」となります。こうすると元の意味はわからなくなります。

これらは、言葉遊びとしてもよくありますので有名ですね。暗号化は軍事目的で伝令が届ける命令や無線通信の内容を隠蔽化するために、さまざまな手法が時代とともに考案されてきました。そして、この通信の内容を「隠す」という目的の下、インターネット普及期にネットワークやメールの暗号化技術が発展してきたことはコンピュータの歴史としてご存じの方も多いと思います。

では、データベースの暗号化とは何を「隠す」ために使用するのでしょうか? そもそも、データベースの暗号化は必要でしょうか?

ここで言う「隠す」とは、「暗号を用いて、何らかの対象を隠す」という言葉を表します。つまり、「暗号とは、当事者間で取り決められた文字や記号をある法則の基で隠したデータを当事者間で取り交わす手法」という意図にとどめています。そのため、本稿ではステガノグラフィや電子透かしなどは含めないものとします。

さて、データベースには何が格納されているでしょうか? はい、データですね。「隠す」という目的では、データベースに格納されているデータの隠蔽化のために暗号化を使用します。

では、暗号化の必要性についてですが、第1回で説明したデータ中心の多層防御から考えてみたいと思います。

第1回の筆者は、この多層防御において、データ暗号化は「データ層を守る最後の砦」と考えています。多層防御の最下層であるデータ層まで侵入されて、さらにアクセス制御も突破されてデータが持ち出されたとしても、暗号化が適切に施されていれば、持ち出した犯人はデータを読み取れません。もし、データの暗号化がまったくされていなければLinuxのstringsコマンドなどのバイナリファイルを直接参照することが可能なコマンドでデータを読み取られる可能性があります。

こう書くと、「よし! データだけ暗号化すればよいのだね!」と思われる方もいるかもしれません。

ちょっと待ってください。データベースのデータを「隠す」には、データベースに入ってくる通信やデータベースのバックアップ・メディアといったデータのライフサイクルを考慮した対策も必要になります。もし、バックアップ・メディアの暗号化がなされていなければ、バックアップ・メディアを持ち出すことでデータを参照される可能性がありますよね?

以上の説明から、データベース暗号化の必要性を理解いただけたことと思います。次は、データベースの暗号化において何を考慮する必要があるのかについて説明します。

データベースの暗号化で考えるべきこととは?

しつこいかもしれませんが、本連載の第1回で紹介した、第1回の幼少期の著者が父親のお金を盗んだ事件を例に考えてみましょう。

子供が目論見通りに父親の部屋に侵入できたとしても、父親が金庫にお金を保管し、仮に子供が金庫本体を持ち出せたとしても「厳重に管理された金庫の中のお金」を持ち出すという目的は達成できなかったかもしれません。

なぜなら、金庫の開け方は父親しか知らないからです。しかし、この「厳重」も度を過ぎると、金庫の持ち主がお金を必要としている時、お金を手にするまでに時間がかかり利便性を失います。また、利便性を求めるあまりに金庫に簡単な管理（例:上記のシーザー暗号など）を施行していることで短時間に金庫を解錠されても困りますよね。

データベースの暗号化でもその目的を実現しつつ、システムとしての「利便性」や「可用性」を落とさずに実装するために考慮すべきポイントとして、次の4点が挙げられます。

アプリケーションからの透過性
暗号アルゴリズム
暗号鍵の管理
移行

以下、それぞれのポイントについて説明しましょう。

(1)アプリケーションからの透過性

「透過性」や「透過的」という言葉は、いつも直感的に意味がわかりにくいと思いながらもIT業界では定番の用語であるため、今回も使用しています。

一般的にセキュリティにおいては「人間やシステムがセキュリティのことを意識せず、負担なく施行されている状態」が安全な状態であると言われています。これを踏まえ、アプリケーションからの透過性とは「アプリケーションが暗号や何らかのセキュリティ対策が施行されていることを意識しないでセキュリティが確保されている状態」と筆者は考えます。データベースそのものが暗号化されれば、アプリケーションの改修（例:SQL変更）が不要（負担がない）になり、暗号化の導入に向けたハードルがぐっと下がり、導入コストの低減にもつながります。

(2)暗号アルゴリズム

暗号アルゴリズムに何を使用するかについては、本連載の第4回で説明したワークファクターの考えを適用できます。暗号化におけるワークファクターとは、暗号解析に対して必要な労力と考えられます。暗号アルゴリズムが強力ゆえに解析に要する時間が膨大になれば、人やモノのコストも増大し、「諦め」が生じる可能性があります。暗号アルゴリズムにどこまでの強度を求めるかは、ワークファクターをどこまで求めるかで考えることができます。

一般的なアルゴリズムガイドラインとして、暗号技術評価プロジェクト（CRYPTREC）策定のCYPTREC暗号リスト（電子政府暗号推進リスト）が参考になると思います。アルゴリズムでお悩みでしたらご参照ください。

また現在、暗号アルゴリズムはアメリカ合衆国の国立標準技術研究所（NIST）が認定した共通鍵暗号化方式「AES」を使用する場合が大半ではないでしょうか。AESを使用する場合、Intel Xeonプロセッサの5600番台から搭載されているAES-NI(Advanced Encryption Standard New Instruction)やOracle SPARCプロセッサで使用可能なCPUベースのハードウェア・アクセラレーションを利用できます。この機能は暗号化・復号処理(暗号学の世界では「暗号化と復号」と言い、「復号化」とは言いません)の性能向上に効果が大きいため、データベース暗号化を導入する場合は使用するプロセッサがこの機能に対応しているか、ぜひ確認してみてください。

(3)暗号鍵の管理

暗号化をしていても暗号鍵が容易に盗まれれば、暗号化の効果はないに等しいです。そのため、暗号鍵の管理は非常に重要です。暗号鍵の定期的な変更、暗号化データと別の場所での暗号鍵の保管、暗号鍵の適切な場所へのバックアップを検討する必要があります。暗号鍵をサーバ上で保管するのであれば、適切なアクセス権と暗号鍵へのアクセス監査の実施も重要です。暗号鍵を保管する目的のハードウェア、複数の暗号鍵を集中管理できるソフトウェア（Hardware Security Module）もあるため、暗号鍵に求められる要件によっては検討が必要です。

(4)移行

暗号化の方式や範囲によっては、既存データを再配置するといった暗号化実装のためのデータ移行が発生する場合があります。暗号化領域へのデータ格納方法や暗号化に伴うストレージ領域の増量などの暗号化領域へのデータ移行方式はデータベースがオンライン状態でできる方式とできない方式があるため、お使いのデータベース製品や導入する暗号化製品の仕様を確認して最適な移行方針を策定してみてください。併せて、暗号化領域へデータ移行後の性能テストを実施して、暗号化実施による性能影響が想定されたものか確認することをお奨めします。

いかがでしたでしょうか? 今回は、データベース暗号化について、その必要性と導入にあたって考慮すべきことについてお伝えしました。本連載を通じて、小社のコンサルタントが「アクセス制御」「物理セキュリティ」「監査」「暗号」について考えていることを限りある文章で説明させていただきました。本連載によって、多層防御によるセキュリティが非常に重要であることを理解いただけたら幸いです。