データベース暗号化が必要な「理由」と「3大方式」を理解する：今さら？ 今こそ！ データベースセキュリティ（5）（1/2 ページ）

本連載では、データベースセキュリティの「考え方」と「必要な対策」をおさらいし、Oracle Databaseを軸にした「具体的な実装方法」や「Tips」を紹介していきます。今回は、「なぜ、データベースを暗号化しなければならないのか」について解説します。

[福田知彦，日本オラクル株式会社]

連載バックナンバー

暗号化は万能ではない

　セキュリティ対策といえば「暗号化」を思い浮かべる人は多いでしょう。しかし、「セキュリティ対策＝（イコール）暗号化」ではありません。

　個人情報保護委員会によるセキュリティ対策ガイドライン「個人情報保護法ガイドライン（通則編）」には、「持ち運ぶ個人データの暗号化」「個人データを含む通信の経路又は内容を暗号化」というように、移動中のデータの情報漏えいを防ぐための手法の例として暗号化が示されています。しかし、保存されているデータの暗号化に関する記述まではありません。

　ただし、同じく個人情報保護委員会による対応例「個人データの漏えい等の事案が発生した場合の対応について」には、“漏えい等事案に係る個人データ又は加工方法等情報について高度な暗号化等の秘匿化がされている場合”には「実質的に個人データ又は加工方法等情報が外部に漏えいしていないと判断される」とされ、仮にデータの漏えいがあったとしても個人情報保護委員会などへの報告は「要しない」とされています。仮に情報漏えい事案が報道されるにしても、「個人情報がダダ漏れで、全部流出していました」と「暗号化していました。実質は情報は漏れてはいません」では、ブランドイメージを損ねる度合いは大きく違います。そもそも、個人情報のような重要情報は確実に暗号化すべきです。

　とはいえ、「暗号化さえしておけば万全」ではありません。暗号化だけでは対応できない脅威もあるからです。

　暗号化は、データにアクセスし、中を見られたとしても内容を推測されにくくする技術です。しかし、今やそれを推測する技術も発達しています。適切な暗号化アルゴリズムを利用していなければ、簡単に復号されてしまいます。

　また、適切なアクセス制御を行っていなければどうなるでしょう。データの漏えいは防げたとしても、別の値に書き換えられたりするデータ破壊の脅威を防げません。さらにもう1つ。データを利用するときには復号する必要があります。「常に暗号化されている状態をキープできるわけではない」ということですね。

　再度、「個人情報保護法ガイドライン（通則編）」を確認すると、個人情報の定義として「暗号化等によって秘匿化されているかどうかを問わない」と記載されています。つまり、暗号化の有無に限らず個人情報は個人情報であり、個人情報保護のための安全管理措置を講じる必要はあります。暗号化しているとしても、適切なアクセス制御など他のセキュリティ対策も必須。だから、セキュリティ対策と暗号化は、イコールではない（それだけでない）というわけです。

暗号化でしか守れない脅威

　同様に、アクセス制御だけでも脅威には対応できません。データベースへのアクセスで例えると、データベース管理システム（DBMS）のアクセス制御機能が有効なのは「データベースで問い合わせ処理を行ったとき」のみです。データベースの仕組みを使わないアクセスに対しては、データベースのアクセス制御機能では対応できません。

　再度、「個人情報保護法ガイドライン（通則編）」を確認しましょう。ガイドラインには「持ち運ぶ個人データの暗号化」と「個人データを含む通信の経路又は内容を暗号化」という手法の例示があることを前述しました。これらはまさにDBMSの仕組みを使わないケースです。

　前者は例えば、データベースからシステム連携などのためにCSVファイルなどに書き出したデータが該当します。後者はネットワーク盗聴などの不正アクセスが該当します。両方ともDBMSの仕組みを利用しません。このようなケースに対しては暗号化してデータの中身を保護することが適切な対応策となります。

　もう1つ、移動中／通信中のデータだけではなく、保存されたデータに関しても暗号化でしか守れない脅威があります。データベースに格納されたデータは、データファイルや、Oracle Databaseならば「ASM（Automatic Storage Management）」のようなデータベースのストレージ管理機能を利用してディスクに保存されています。デフォルト設定では、ディスクには暗号化されない状態で保存されます。データファイルはバイナリ型ですが、文字コードなどをきちんと合わせればテキストエディタなどでも読めてしまいます。

格納データが暗号化されていなければ、テキストエディタなどでもある程度中身を視認できてしまう（データはダミーです）

　これはどういうことでしょう。OSユーザーやストレージの管理者ならば、データベースにログインすることなく、データファイルやストレージのボリュームを直接参照して、データの中身を盗み見れてしまうということです。内部不正以外にも、例えば、交換したディスクの廃棄処理が適切でなかったら、廃棄したディスクから情報が漏えいする可能性があります。アプリケーションを運用管理するメンバーや組織と、ハードウェアやOS、場合によってはデータベースなどのインフラを管理するメンバーや組織が異なり、併せてインフラ管理は外部事業者が行っているといったように、管理者が誰かが分からない状態になっていることもあり得ます。

　こちらは、クラウドサービスを利用するシーンを想像するともう少し分かりやすいかもしれません。クラウドでは、自社の組織とは別のクラウドサービス事業者がインフラ管理をします。もしデータが暗号化されていなければ、「その中身を見ることができてしまう」可能性があるわけですね。

　それでもデータベースがデフォルトで暗号化されない背景には、そもそもデータベースは「いかに速く目的のデータを検索するか」の性能を追究してきた歴史があります。Oracle Database以外のDBMSでも同様に、2017年8月現在、ほとんどのデータベースではオーバーヘッドになり得る暗号化処理は、別途暗号化機能を提供していつつも、“デフォルトでは”行われていません。そのため、システム管理者が「暗号化対策を明示的に行う」必要があるのです。