日本版SOX法への対応では，データベースへのアクセス記録を証跡として残す「データベース監査ツール」が威力を発揮する。主な機能は，記録，警告，集計･レポートの3つ。記録する情報の抜けやきめ細かさをチェックする必要がある。
「個人情報保護法」と「日本版SOX法」。これらの法律に適応するには，データベース（DB）へのアクセス制御を厳格化すると同時に，アクセス記録を証跡として残す必要に迫られる。こうした背景から，「DB監査ツール」の注目度が一気に高まった。
単にDBへのアクセスを記録するだけであれば，商用DBMSの多くが搭載する「監査機能」を使えば済む。それでも現場担当者はDB監査ツールを導入している。なぜか。2005年夏，DB監査ツールの導入に踏み切ったアクサテクノロジーサービスジャパン（AXA TECH）の宮下俊之氏（サービスデリバリ テクニカルサービス インフラ戦略＆プランニングマネージャー）は，「DBMSの監査機能だけでは記録しかできない。違反を見つけて警告するとか，状況をレポートするといった機能がない。実用性に乏しいと判断した」と導入の理由を語る。
こうしたニーズの高まりを受け，製品数が増えた。これまでDBMSベンダー以外から提供されていたが，米OracleがDB監査ツール「Audit Vault」を開発中。日本では2007年前半に出荷予定だ。
三つの機能によりDBMSの監査機能を補完
DB監査ツールは，ソフトウエアか，ソフトウエアを搭載したアプライアンスとして提供される。提供形態に関係なく，DB監査ツールの多くは，「記録」「警告」「集計・レポート」という三大機能を備える（図1）。
 図1●DB監査ツールはDBMSが備える監査機能を補完する 主要な商用DBMSが搭載する監査機能では，一部の操作ログを記録できない場合があり，設定も難しい。DB監査ツールを使うと，操作内容や操作対象をきめ細かく容易に記録できる。また，記録した内容から不正な操作を監視して警告したり，月次や週次で記録内容を集計してレポートしたりすることが可能になる [画像のクリックで拡大表示] |
記録機能とは，誰が，いつ，DBのどのオブジェクト（スキーマ，テーブル，カラム，トリガーなど）に，どんなアクセスを試みたかのログを残す機能である。製品によっては，DBMSの監査機能では取得できない情報（APサーバー経由でDBサーバーにアクセスする場合の，Webアプリケーション側のアカウント名など）を取得できる。
警告機能とは，あらかじめ設定したポリシーに反するアクセスがあった際に，メールなどで監査担当者に知らせる機能である。一般に監査担当者はDB管理者とは別に任命する。こうすることで，DBの全権限を持つDB管理者によるポリシーに反するアクセスを抑止できる可能性が高まる。
集計・レポート機能は，記録した監査ログを日次や月次で集計し，監査担当者にさまざまな切り口で提示する機能である。
DBサーバーへの負荷に大差
DB監査ツールは，監査ログの取り方の違いから，（1）監査ログ利用型，（2）エージェント利用型，（3）パケット取得型――の3タイプに分類できる（図2）。タイプにより，収集できる情報に違いがあるほか，DBサーバーに与える負荷も大きく異なる。
 図2●DBへのアクセス情報を取得する方式は3種類 （1）監査ログ利用型，（2）エージェント利用型，（3）パケット取得型，の3種類。最近は，（1）をメインに（2）をサポート，（3）をメインに（2）をサポート――といった複合型の製品が増えてきた [画像のクリックで拡大表示] |
（1）の監査ログ利用型とは，DBMSが提供する監査機能を利用するタイプ。DBMSが生成した監査ログを定期的にDB監査サーバーに集め，DB監査サーバーで警告したり，集計・レポートしたりする。DBMSの機能を利用するので全アクセス記録を収集可能である半面，3タイプのなかでDBサーバーに一番大きな負荷を与える。DBMSの監査機能はアクセスするたびにファイルなどにログを書き出す仕組みだからである。
監査ログ利用型の製品を導入する場合には，処理能力とディスク容量の両面でDBサーバーのキャパシティ設計が欠かせない。代表的な製品は，「Audit Master」や「IPLocks」である。
（2）のエージェント利用型は，監査対象のDBサーバーに専用プログラム（＝エージェント）をインストールし，この専用プログラムからDB監査サーバーにログを転送するタイプ。DBMSの監査機能を使わないので，DBサーバーに与える負荷は小さいが，取得できる監査ログには漏れが生じる場合がある。例えば，定期的にDBMSプロセスのメモリーをチェックする方法を採用する製品の場合，チェック周期の間に実行かつ終了したアクセスの記録は残らない。また，エージェントを導入する手間もかかる。このタイプの代表的な製品は「PISO」である。
最近では，（1）の監査ログ利用型や（3）のパケット取得型も，補助的にエージェント利用型を併用できる。例えばAudit Masterは，監査ログ利用型によるDBサーバーの負荷上昇を抑えるために，オプションでエージェント利用型も選択できる。
（3）のパケット取得型は，DBサーバーに送られるパケットを監視してアクセス情報を記録するタイプ。具体的には，LANスイッチのミラー・ポートなどを使いDBサーバーへのパケットをDB監査サーバーに転送するか，DBサーバーへのアクセス回線上にDB監査サーバーをインラインで配置する。この方式は，DBサーバーに与える負荷が発生せず，稼働しているDBサーバーの構成変更が不要なために導入が容易というメリットがある。
ただし，パケット取得型は，ネットワークを介さずにDBサーバー上で直接実行した操作の記録はまったく残せないことがデメリットだ。代表的な製品である「SecureSphere Database Monitoring Gateway（SecureSphere DMG）」や「SQL Guard」は，このデメリットを解消するために（2）のエージェント利用型を併用できる。
収集ログの細かさに差使いやすさも考慮したい
DB監査ツールを選択する場合，まずはじめに監査対象のDBMSをサポートしているかどうかを確認することが欠かせない。特にオープンソースのDBMSは要注意で，正式にサポートしている製品は無いのが現状である。
そうしたうえで製品選びのポイントになるのは，監査ログの抜けの有無や細かさと，使いやすさである。今後は，防御や脆弱性検査などの付加機能が注目される可能性もある。
割り切れるならパケット取得型
製品タイプによって，記録できないアクセスがあったりなかったりする。そうした点に基づくと，タイプごとの標準的な選択基準は次のようになる。
（1）の監査ログ利用型は，「ネットワーク越しのアクセスもDBサーバーへの直接アクセスも漏れなく記録したい」という場合に適している。コストを度外視しても，とにかく“漏れなく”が重要なら，このタイプになる。
（2）のエージェント利用型は，「記録に多少の漏れがあっても，記録を残せる状態を手早く作りたい」という場合に選びたい。
（3）のパケット取得型は，「ネットワーク越しのアクセスを漏れなく記録できれば十分。DBサーバーへの直接アクセスは，OSレベルの不正操作まで記録・検出する別のツールで対処する」と割り切れる場合に向く。ネットワーク経由のアクセスに限定できるなら，パケット取得型は有力候補だ。
同じ製品タイプでも，記録のきめ細かさには違いがあるので注意したい（図3）。例えばパケット取得型であるSecureSphere DMGの場合，SQL要求とSQL応答の全文を記録できるが，ログインの成否，SQL文の実行成否，パスワード変更の成否といった記録は残せない。なぜならSecureSphere DMGは，あらかじめどのアカウントからどのオブジェクトにアクセスすることがあり得るかをポリシーとして学習させておき，このポリシーに違反したアクセスを警告ログに記録するという設計思想だからだ。
 図3●記録できる情報のきめ細かさには差がある 例えば「SQL Guard」の場合，要求時にはSQLコマンドと対象テーブル，対象カラム，応答時には実行の失敗を記録する。これに対して「SecureSphere DMG」は，SQL要求全文やSQL応答全文を記録できるが，実行の失敗は記録しない（ポリシー違反の場合は記録する） |
これに対して同じパケット取得型でもSQL Guardの場合，ログインの成否，SQL文の実行失敗，パスワード変更の成否，アクセスしたテーブルやカラムなどを記録できる。だが，SQL応答の全文は記録できず，SQL要求の全文を記録するにはオプションがいる。
「状況を把握しやすいレポートか」
監査担当者にとっての使い勝手も重要だ。設定や操作が容易か，レポートの切り口は豊富か，レポートの表現は分かりやすいか，レポートを定期的にメールで送付できるか――などがチェック・ポイントになる（図4）。
 図4●レポートの切り口や見やすさも選択のポイント アクセスの記録を集計してレポートするときの切り口が充実しているか，視覚的に見やすいか――なども，製品選定時の考慮点となる。一部の製品は，集計結果をグラフ化して表示したり（左），レポートをメールで自動送信したり（右）する機能を持つ [画像のクリックで拡大表示] |
AXA TECHの宮下氏は，「（DBMSのエキスパートでなくても）直感的に使えるユーザー・インタフェースと，一見して状況を把握しやすいレポートを出力できることを重視して製品を選んだ」。同社でDB監査ツールを使い，ポリシーを設定したり，日常的にレポートを参照したりするのは，DB管理者とは別のセキュリティ管理者である。このセキュリティ管理者が，監査ログの状況を把握したり，経営層やシステム利用部門に報告したりするときに，レポートを利用している。
セキュリティ管理者は，発行されたSQL文の詳細といった技術的な視点のレポートよりも，ポリシー違反の件数を集計してグラフで示すような業務的な視点のレポートの充実に期待することが多い。こうした点を考慮し，宮下氏はAudit Masterを選んだ。
ポリシー違反のアクセスを遮断
セキュリティを高める付加機能にも注目したい。例えば，ポリシー違反のアクセスを阻止する「防御機能」や，DBサーバーにセキュリティ上の弱点がないかを調べる「脆弱性診断機能」などがある。
ほとんどのDB監査ツールは，事前に設定したポリシーに違反するようなアクセスがあった場合に，監査担当者にメールで知らせる警告機能を搭載している。だが，これではどうしても事後対応になるので，最近の製品は防御機能を備えつつある。
防御の仕組みは3種類ある。一つは，ポリシー違反のアクセスをDB監査サーバーがリアルタイムに遮断する方法だ（方法1）。この方法はDBサーバーへのアクセス回線上にDB監査サーバーをインライン配置したときに使える。残り二つの方法は，リアルタイムに止めることはできないので未然防止にはならないが，被害を少なくできる可能性がある。ポリシー違反のDBセッションを破棄して止める方法（方法2）と，ポリシー違反のTCPコネクションをドロップする方法である（方法3）。
方法1～3のいずれも選択可能なのはSecure Sphere DMGに防御機能を加えた「SecureSphere Database Security Gateway」，方法1と方法3を選択できるのがSQL Guard。方法2だけをサポートするのは，Audit Masterと「Chakra」である。
脆弱性診断機能は，DBサーバーにセキュリティ・パッチが適用されているか，不要なアカウントがないか，悪用されると危険なプログラム（ストアド・プロシージャなど）が有効でないか，などをチェックして報告する機能である。Audit Master，IPLocks，PISO，SecureSphere DMGが標準機能として搭載するほか，SQL Guardがオプションとして提供する。
（後編へ）
