データベースのセキュリティ対策を語る準備として、企業は何をしなければならないのか。セキュリティ対策を検討する際は一般的に、まずは「誰が」「何から」「何を」「どうすべきか」を整理することが大切だ。データベースセキュリティについては、

• 誰が：企業（データオーナー）が
• 何から：外部および内部の脅威から
• 何を：データベース内の情報資産（データ）を
• どうすべきか：守る（漏えいや損失をしないようにコントロール）

ということになるだろう。

　セキュリティ脅威と聞いてイメージしやすいのは、「RAT」とも呼ばれるトロイの木馬やボットを悪用した、不正アクセスや標的型攻撃といった外部からの脅威だろう。だがデータをセキュアに管理するには、外部からの脅威だけでなく、内部からの脅威に対する注意も必要だということを忘れてはならない。昨今の情報漏えい事件・事故の例を見ても、内部関係者が関与したインシデントやケースが増えている。こうした背景を鑑みれば、「性善説」を前提とした考え方は、もはや捨てなければならない。

データベースサーバのセキュリティ対策

　データベースサーバのセキュリティ対策は、いわゆる外部公開サーバのセキュリティ対策とは異なる、ということをまず認識することが必要だ（図1）。外部公開サーバは、WebサーバやDNSサーバなど、外部のクライアントに対して機能やサービスを提供するサーバのことである。

　情報漏えいを防ぐためには、ステップ3の「チェック」がスタート地点に立つための準備、前提条件となる。だからといって、ステップ1の「診断」とステップ2の「評価・改修」を軽視すべきではない。このステップ1～3は、「セキュリティレベルは日々劣化する」という考え方の下、定期的かつ繰り返し実行することが望ましい。

　ここでの診断とは、具体的には使用するデータベースサーバのバージョンに脆弱性があるかどうか、脆弱な設定で運用していないかどうかなどを調査、アセスメントすることである。ユーザー企業自身での実施が難しい場合は、有償サービスや専用ツールを利用するのも1つの手段である。専用ツールにはImperva Japanの「Scuba by Imperva」のような無償のものもある。

　アセスメントで検出された問題は、評価した上で適切な対策を取る必要がある。ただし、新規構築でもない限り、いったん稼働させるとなかなか停止できないのがデータベースサーバの宿命である。最新の侵入防御システム（IPS）やデータベースセキュリティ製品の中には、通信内容を解析して脆弱性を突く攻撃を未然に防ぎ、パッチの適用と同等の効果をもたらす「仮想パッチ」という機能を持つものがある（画面1）。こうしたセキュリティ製品を利用することも暫定対策として有効である。

　システムの脆弱性に関する問題が解決し、スタートラインに立ったところで、いよいよ具体的なコントロール施策の出番となる。今回紹介する具体的な対策例と、その目的をまとめたのが次の表だ。

アクセス制御

　データベースに対するアクセス制御と一言でいっても、レイヤーやレベルに応じて対策も効果も異なる。また、ここで紹介するアクセス制御は、多重防御の観点から必要に応じて各レイヤーで対策を取ることが望ましい。

接続元IPアドレスによる制御（ネットワークレベル）

　データベースサーバは、インターネットから直接アクセスできないセグメントに配置することが基本だ。その上で、内部IPアドレスにおいても接続元IPアドレスを基に制限する。

データベースユーザー名／パスワードによる制御（アカウントレベル）

　データベースのセキュリティ対策として最も一般的なアクセス制御の1つである。アカウントの目的ごとに必要な権限を分類し、各アカウントがアクセスできるデータ領域を必要最低限に制限する。こうした制御は、必要最小限のデータ（テーブル）と、必要最小限のアクセス内容（参照、更新、作成、削除など）を決定することが重要になる。

システム権限による制御（アカウントレベル）

　データベースサーバには、OSレベルのユーザーと、データベース内におけるユーザーそれぞれにレベルがある。具体的には、rootやAdministrator、DBAといった「特権」と呼ばれるスーパーユーザー権限と、一般ユーザーレベルのユーザー権限とに分けることができる（図2）。

　まず重要な考え方として、OS／サーバホストレベルのユーザーやその権限設定と、データベースシステム内のユーザー設定は別物である。すなわち、データベースに対する権限と、データの中身に対する権限は別物だという認識が必要だ。当然ながら、適切な権限分掌が重要になる。

テーブルレベルによる制御（アカウントレベル）

　データベースに格納されている情報は、各テーブルに応じて異なる。含まれる情報に応じて、テーブルのセキュリティレベルは変わる。例えば、個人情報やクレジットカード番号情報などの機密情報を含むテーブルに対しては、アカウントレベルによる制御と組み合わせて制御する方式が一般的である。

　システムテーブルに対して不適切なアクセス権限を与えていると、大変危険である。一般データ領域とシステム領域では、さらなるアクセス制御をしておく方がいいだろう

SQLコマンドレベルによる制御（アカウントレベル）

　データベースに対する特権を持つユーザーでも、業務で必要となる制御内容が限られているのであれば、必要最低限の権限に絞る方が望ましい（画面2）。これは情報漏えい対策の他に、人為的なオペレーションミス対策にも効果的な制御だ。

暗号化

　暗号化にも複数のポイントがある。対策の例を取り上げ、各対策の主目的と効果を紹介しておこう。

通信経路の暗号化

　データベースサーバとクライアント間の通信を暗号化する一般的な手段は、SSL暗号化だ。データベースの中には、独自実装した通信経路暗号化機能を有するものもある。クライアント／サーバ間のネットワークで通信を盗聴されることを想定した対策だ。万が一、マルウェアに感染した端末などが通信経路で盗聴されたとしても、通信経路が暗号化されていれば、現実的にはほぼ情報を窃取される心配はない。

データベース内情報の暗号化

　データベースに格納したデータは、OSレベルから見るとファイルの集合体である。データファイルを盗まれて解析されると、情報が盗聴されてしまう可能性がある。こうしたデータの“のぞき見”を助けるツールは、悪意のあるハッキングツールではなく、一般的なツールとして誰でも手に入れることができる。

　格納データを暗号化しておけば、データファイルが窃取された場合でも、内部の情報がのぞき見されるリスクを低減できる。機密性の高い情報は、暗号化してデータベースへ格納し、仮にデータファイルが盗まれても肝心の情報は得られない状態にしておく。これは、データベースの基本的かつ有効なセキュリティ対策である。

　ここで忘れてはならないのが、バックアップデータに対するケアだ。バックアップデータを暗号化しておけば、バックアップメディアの盗難などで内部情報が漏えいするのを防ぐことができる。

パスワードのハッシュ化

　データベースのパスワードはハッシュ化して管理する。仮にハッシュ化されていても、パスワードを格納したデータファイルが盗まれれば、解析されてしまう可能性はある。そのため予備的対策であるともいえるが、少なくとも解析に時間を要するため、時間稼ぎとしては機能する。

エンドユーザートレーニングや周知

　連載第2回の「ログ取得だけでは無意味　失敗しない『データアクセス監査』5カ条」で、「データアクセス監査」の重要性については認識いただけたのではないだろうか。監査機能が働いていることを広くエンドユーザーに周知することも重要だ。

　システムが適切に監査されていることをエンドユーザーに周知することで、心理的効果により、内部ユーザーによる不正行為に対する抑止効果が期待できる。

モニタリングや検知／遮断

　データベースに対するインシデントの検知には、アノーマリ（異常）をモニタリングする方法が取られることが多い。効果的にインシデントを検知するためには、何が正常で、何が異常かということをユーザー企業が把握しておく必要がある。

　情報漏えい対策の観点からは、異常を検知した場合、自動的に当該行為をブロックする機能をシステムに実装することを推奨する。現在、データベース専用のセキュリティ製品が充実してきており、それらには遮断機能が実装された製品も存在する。こうした製品を利用することで、セキュリティ監視と漏えい対策が同時にできる。

　以下、データベースに実装可能な異常検知例を紹介する。

SQLエラーの検出

　一般的に、システムやアプリケーションで利用するデータベースでは、SQLエラーが発生するケースは少ない。そのため、SQLエラーが発生した場合は、システムの不具合やアプリケーションのバグ、人為的な操作に起因する場合が多い。人為的な操作でSQLエラーが発生した場合、悪意あるユーザーがデータに不正アクセスしている可能性が高い。

抽出レコード件数による監視

　通常業務の中で発生するデータベース操作が、個人情報を1件ずつ引き出す作業ぐらいしかなければ、データの抽出件数にひも付いた閾値による制御が可能だ。その手段として有効なのが、抽出件数ベースによる検知ロジックである（画面3）。

時間単位によるモニタリング

　他にも、平日9時～18時が業務時間であるエンドユーザーに対しては、時間軸を基にしたモニタリングが有効だ（画面4）。この場合、深夜帯など業務時間ではない時間帯のアクセス状況を見ることで、データに対する不正なアクセスを検知できる。

---

　守るべき情報がどこに存在し、普段そのデータがどのような使われ方をしているか。それについて、ユーザー企業自身が正確に把握できていないケースは意外と多い。これは、筆者がデータベースサーバからの情報漏えい事件の現場に立ち会った多くの経験から分かったことだ。

　今回は、データベースにおける対策の考え方に始まり、情報漏えいに備えた対策の具体例を紹介した。情報漏えいを防ぐデータコントロールの本当の出発点は、保有する情報の棚卸しにあると考えている。つまり、どこにどのような情報を保有しているか、誰がどのような権限を与えられ、利用しているかという「As-Is」の可視化である。

　現状を正確に見える化した上で適切な監査を実施し、さらに今回紹介したようなセキュリティ対策を取ることで、真のデータコントロールによる“脱”情報漏えい体質を実現していただきたい。

---

　次回はデータセキュリティの対象をデータベースサーバからファイルサーバへ移し、ファイル、すなわち非構造化データに対するセキュリティをテーマに、機密データや重要データをいかに守るかについて掘り下げていく。