対策1で取得したDB監査ログは，万一の際に情報の流出経路や犯人を後から特定するためのものだ。だが，DB監査ログにはユーザーの行為が記録されており，その情報を分析してユーザーの不正な行為をあぶり出せば，情報流出の危険性の芽を早い段階で発見できる。
定期的に“けん制球”
東京海上日動火災保険の担当者は，DB監査ログから定期的に，ユーザーID，タイム・スタンプ，実行機能の内容，保険契約を扱っている課や支社などの情報を取得し，課や支社の管理職あてにメールで送信している。「データベースが不正利用されていないかどうか，注意を促すためのもの。ユーザーに不正をさせないためのけん制効果を狙っている」（IT企画部 企画室 課長 稲葉裕一氏）。
また，DCSの竹中氏らが構築した金融機関のシステムでは，この8月から，DB監査ログからユーザーの振る舞いを分析してレポートを作成する。「どのユーザーが個人情報に多くアクセスしているのかなどを毎月集計し，不正な操作がないかどうかを確認する」（竹中氏）。
このように，DB監査ログを定期的に分析してレポートする仕組みを作れば，「個人情報に頻繁にアクセスしているユーザーはいないか？」，「権限がないのに，個人情報にアクセスしているユーザーはいないか？」ということを見極められる。不審な行為をしたユーザーに注意することもできるため，ログを単に保存するだけよりも高い抑止効果が期待できる。
データベース管理者の操作手順が正しいかどうかの確認にも応用できる。ビットワレットのデータベースの管理者は，SQL＊NetやMS Accessを使ってデータベースを操作する必要が出た場合，事前に「操作申請書」を沼上氏に提出する。この申請書に記載された内容と，ログ収集/監査ツールの「Audit Master」から出力されるレポートを毎週1回の頻度で突き合わせ，操作申請書の内容と実際のデータベース操作内容が合致するかをチェックしている。
「現場を押さえる」
DB監査ログに基づいた定期的なレポートは，過去に起きた問題を分析しているにすぎないが，監査ログを常時監視すれば不正行為をしている最中にそれを検知することも可能だ。
DCSの竹中氏らがシステム構築した金融機関では，「担当者が，不正があったらすぐに発見し，現場を押さえたいという要望を持っている。今後，不正をほぼリアルタイムに検知し，管理者に通知する仕組みを作っていくことを考えている」（DCS 竹中氏）。具体的には，DB監査ログを常時監視してユーザーの不審な行為をチェックし，不審な行為があったらメールなどでデータベース管理者やセキュリティ担当者に知らせる仕組みである。
既に，ディップやニコンカメラ販売などでは，ユーザーの不審な行為を検知する仕組みを構築し，実際に利用している。図5[拡大表示]は，電通国際情報サービスがシステム構築した人事アウトソーシング企業における，DB監査ログを利用した不正検知の例である。この企業では，RDBMSが取得した監査ログを，1分に一度IPLocksが収集。IPLocksは自動的にDB監査ログを走査し，あらかじめ決めている条件に合致する行為があったら，運用管理ツールを通じてセキュリティ担当者に警告メールを送信する。メールを受け取ったセキュリティ担当者は，メールの内容から不正行為だと判断した場合，データベースを操作したユーザーに電話などで警告したりする。
時間帯や曜日から不審と判断
このような仕組みを実現するには，どういった行為を不審とみなすかがポイントになる。ユーザーの不正な行為を検知して警告しているユーザー企業は，表2[拡大表示]のような条件を検知に利用していた。
まず条件として考えられるのが，曜日や時間帯だ。ディップの担当者は，早朝や休日にデータベースへアクセスしていると不審な行為とみなしている。ニコンカメラ販売とぷららネットワークスの担当者も同様に，勤務時間外の夜間にアクセスしていると不審な行為とみなす。
DBへの操作内容や操作頻度，取得するデータ量を，不審な行為の条件にすることも考えられる。例えば，テーブルのエクスポート操作や，顧客情報テーブルの全件検索などは，不審な行為と言えよう。
また，SQL＊Netなどの管理ツールの利用や認証の失敗などは，利用者の情報と合わせることで，不審な行為とみなすことができるだろう。例えば，管理者ではない通常のユーザーがSQL＊Netなどを使っていると不審な行為になるだろう。
このほかにも，「データベース構造を調べるための管理テーブルの参照や，権限のないテーブルにアクセスしているという行為は，不正の匂いがする“怪しい”操作」（ラック 大野氏）と見ることができそうだ。
判定が難しいのは，一定時間内に一定回数以上，個人情報を検索したというようなケースである。こういうケースは，DB監査ログのある一時点だけを見ただけでは分かりにくいので，「異常値」を決めておく必要がある。異常値は，DB監査ログに基づいた定期的なレポートのなかで，ある一定期間中のユーザーの行動を集計するなどして決めたい。
