データベース監視の必要性

前回解説した「DB監査ログ取得方針」に基づき方針を決定し、DB監査ログを取得するだけで情報漏洩を防げる訳ではありません（抑止効果はあります⁠）⁠。もしも情報漏洩事故が発生した場合、犯人や被害範囲を特定することができるかもしれませんが、事故そのものは企業の信用問題となります。そのためにも「データベース監視」による情報漏洩対策を検討すべきです。

データベース監視を行うためには

データベース監視を行うためには「環境」「⁠体制」を整える必要があります。「⁠環境」は、データベースにアクセスする際のルール化や、不審なアクセスを検知するための手段（DB監査ソフトウェアの導入やその他の方法）を決めておくこと、「⁠体制」は、不審なアクセスを検知した場合のアクション、手順の明確化と担当者の配置などになります。

申請承認ベースによるアクセス運用

通常データベース監視では、運用されているアプリケーション・システムからの接続は正当なアクセスとして認めます。この接続を除いたシステム運用者やデータベース管理者が作業のために行う臨時の接続を特に監視します。そのような接続が発生した場合は、申請・承認されているものかを確認することで不審なアクセスかを判断できます。そのため事前にアクセス申請を行い責任者の許可を得てから行うという運用を徹底します。申請時の項目の例を示します。

• アクセス日時（from～to）
• アクセス時DBアカウント
• アクセス時OSアカウント
• アクセス時端末のIPアドレス（ホスト名）
• 作業内容

DB監査ログに出力された内容が申請時の項目と相違なければ、正当なアクセスとして認めることができます。当然、障害が発生した場合に緊急でデータベースへアクセスする必要があることもあります。その場合は、事後にでも必ず申請・承認を行い、記録するべきです。

データベース監視上の登場人物と役割

データベース監視の対応フローを図に示します。

データベース監視の概要

(1)システム運用者、またはデータベース管理者はデータベースにアクセス際はアクセス申請を行い、責任者より承認を得る

(2)承認後にデータベースにアクセスを行う

(3)アクセスによりデータベース監査ログが出力・収集される

(4)アプリケーション・システム以外からのアクセスの場合にアラート通知

(5)監視担当者によりアラート対応が行われる

システム運用者、データベース管理者

監視対象となるデータベースにアクセスする者。データベースセキュリティ上は、アプリケーション・システムを運用するために、アクセスするシステム運用者とデータベースサーバ、DBMSを運用するデータベース管理者は、役割を分けることが推奨されます。

システム運用者責任者、データベース管理者責任者

システム運用者やデータベース管理者がデータベースへアクセスするための申請を許可承認する者。承認なくアクセスさせないことを徹底する責任があります。

監視担当者

DB監査ソフトウェアから通知されるアラートを確認する者。アラートとなったデータベースアクセスが正当なものであるかを確認します。監視担当者は、システム運用者やデータベース管理者とは関係のない第三者で、正当なアクセスが確認できない場合は、上位組織に報告します。報告を受けた上位組織は状況により緊急対応（DBセッションの切断、データベース停止など）を実施します。

このようなデータベース監視運用を徹底させることで、データベース利用者やデータベース管理者への抑止効果も高まり、また不正なアクセスの早期発見につながります。

導入だけでは意味がないDB監査ソフトウェア

不審なアクセスを検知するために、決定した「DB監査ログ取得方針」によっては、DB監査ソフトウェア導入を選択する場合があります。DB監査ソフトウェアは、ログ収集方法にいくつか種類があります。

また、製品ごとに異なりますがログ収集・監視機能以外にも下記のような機能を提供します。

• ユーザが設定するルールやポリシーに基づき確認を行い、違反があった場合アラートを通知する
• 通知したアラートが解決したかのステータス管理
• 各種レポート機能
• DBMS脆弱性検査機能
• DB監査ログ分析機能

ただし、DB監査ソフトウェアは、登録したルール以外の不審なアクセスがあったことを通知してくれるだけで、アラート内容の確認はしてくれません。アラートを受けた場合どのようなアクションを取るべきなのかの手順や体制を確立しておくことが重要なのです。せっかくコストをかけてDB監査ソフトウェアを導入しても、アラートを正しく処理できなければ意味がありません。

不審なアクセスをインシデント管理する監視担当者

インシデント管理とはITIL（※）で表される運用手法である「サービスサポート」のひとつです。通常インシデントとは「ITサービスの中断」を意味するものです。データベース監視では「不審なアクセスが発見されてから確認が取れる（または取れない）こと」までをインシデントと捉え管理します。それ以外にも、トラブルによるデータベース監視運用の停止もインシデントとして管理します（たとえば、DB監査ソフトウェア障害により検知ができない状態になった場合など⁠）⁠。

※ITIL（Information Technology Infrastructure Library）

1980年後半に英国の政府機関が作成・文書化をしたITサービスマネジメントのベストプラクティスを集めたフレームワーク

監視担当者は、不審なアクセスが検知された時点からインシデントとして管理を始めます。以降、申請書による確認、データベース利用者やデータベース管理者への直接確認（申請漏れ、不備を想定⁠）⁠、確認が取れなかった場合などの対応、結果をすべて記録します。この管理は該当のインシデント対応が完了しクローズされるまで行います。このようなインシデント管理を繰り返し行うことで、データベースに対するアクセスの傾向も把握することができます。また、長期間に渡る障害については別途問題管理することも行います。このようにアラート検出後の運用がDB監査ソフトウェアなどではフォローされていないため、製品を導入した企業はしっかり手順を確立し運用することが重要になります。

ログ分析による監査

システム運用者やDB管理者を監視対象とした場合、申請・承認を得たアクセス中に不正行為を働く可能性も捨て切れません。その監視のために、定期的にデータベース監査ログの発生状況を押さえておき、通常と異なる兆候はないか、申請と異なる操作をしていないかなどを確認します。また、あらゆる方向（OSアカウント単位、DBアカウント単位、プログラム単位など）から分析することで、他の発見があるかもしれません。

以上のように、情報漏洩防止の積極的対策であるデータベース監視を行うことで、今まで以上に安全なデータベース運用を実現することができるでしょう。

全5回にわたり「データベースセキュリティの一般常識」として、データベースセキュリティ対策の概要を解説してきました。今後、内部統制で求められる財務報告の正当性を証明するためIT基盤のひとつであるデータベースで管理される重要情報を改ざんから守り、かつ情報漏洩を防ぐ手段を整えていく必要があり、今回提示させていただいた対策がその一助になれば幸いです。

なお、弊社ラック／データベースセキュリティ研究所では、実施すべき対策を網羅した「セキュアDBマトリクス」を公開していますので、こちらもご覧ください。

セキュアDBマトリクス

http://www.lac.co.jp/business/laboratory/dbsl/matrix/index.html