個人情報が社外に漏洩すると，「いつ，どの項目が漏洩したかを説明できなければならない」（ラック 研究開発本部 データベースセキュリティ研究所 上級研究員 大野祐一氏）。さらに，警察と協力して犯人や流出経路の特定もしなければならない。
これらを実施するには，データベースへのすべてのアクセスを，証拠になるようにDB監査ログに残しておく必要がある。すべてのアクセスを残しておけば，不正なユーザーによるアクセスの痕跡を残すことができる。
ただ，既存システムに影響を与えずに，DB監査ログを取得するのは難しい。また，犯人を特定するための証拠とするには，どの項目をどのように保管するかが課題になる。
DBの監査ログ機能には3つの弱点
ほとんどのRDBMS製品は監査ログの取得機能を備えている。
だが監査ログのデフォルト設定はオフになっている製品が多く（図2[拡大表示]左），明示的にオンに設定しなければ監査ログは取得されない。RDBMSの機能で監査ログを取得した場合の注意点は，処理性能への影響や，ログのデータ量，ログの管理である（同右）。アサヒビール・グループのWebサイト構築・運営を担っているアサヒインターネットサービスの向（むかい）知尋氏（システムグループ 技師）は，「全アクセスについて，Oracle DBの機能で取得できる項目のほとんどをログに保存していた。ところが，CPU使用率で20％ほど性能をロスしていた。Webサイトのアクセス数増加に伴い，Webアプリケーションが動かなくなってしまった」という経験をした。
また，DB監査ログはテーブル内のレコードやファイルとしてたまる一方。ログの削除を怠りディスクがいっぱいになると，「DBサーバーがダウンしてしまう。それが一番怖い」（ビットワレット システム企画部 システムオペレーショングループリーダー 沼上孝則氏）。
ログ管理が煩雑になる問題もある。「複数のデータベースがあると，監査ログを一元管理できなくなるし，バックアップも一度に済ませられない」（イーソリューションズ シニアアソシエイト 伊藤啓介氏）。
専用ツールでログの課題解決
そこで注目したいのが，専用のDBログ収集/監査ツールである。こうしたツールを利用すれば，RDBMSの機能を使うことによる問題の多くを解消できる。比較的新しい製品が多いが，既にニコンカメラ販売やビットワレット，ぷららネットワークスのシステム構築の担当者は，ツールの特徴に着目して導入を決めた（図3[拡大表示]）。
市販されているDBログ収集/監査ツールは，(1)DB監査ログ利用型，(2)エージェント型，(3)パケット・キャプチャ型——の3つに分類できる。
(1)DB監査ログ利用型は，RDBMSの機能で収集した監査ログを別のサーバーに集約するタイプである。ビットワレットの沼上氏は，「RDBMSの機能で監査ログを取得すると，後で監査ログを明示的に削除する必要がある。ビジネスが右肩上がりで伸びており，やるべきことが多いにもかかわらず人員は不足している。余計な手間をかけずに，自動的に監査ログを吸い上げて削除するツールが欲しかった」ので，(1)DB監査ログ利用型の「Audit Master」を選定した。このタイプは別サーバーでログを管理するため，ログ・データの管理やログへのアクセス制御の課題を解決できる。
こうしたメリットがある半面，このタイプのツールは，RDBMSの監査ログ機能を利用するためRDBMSの処理性能の低下は免れない。
処理性能への影響が少ないツールも
DBサーバーに性能面の影響を与えたくないなら，RDBMSの監査ログ機能を使わない，(2)エージェント型と(3)パケット・キャプチャ型のツールが候補になる。(2)エージェント型は，DBサーバーに導入したエージェント・ソフトが，RDBMSのメモリー空間を定期的に参照し，ログを管理サーバーへ送信するタイプ。(3)パケット・キャプチャ型は，DBサーバーにつながるネットワークに専用機器を配置し，DBサーバーへの通信内容をキャプチャするタイプである。
アサヒインターネットサービスとぷららネットワークスのシステム構築の担当者は，(2)エージェント型に該当する「Performance Insight Security for Oracle（PISO）」を選んだ。DBサーバーの性能低下を避けたかったことが主な理由だ。一方，「稼働中のデータベースに手を加えたくなかったし，短期で対応することを要求されたため，パケット・キャプチャ型の『Chakra』を，ある金融機関のDB監査ログを取得するために選んだ」（ダイヤモンドコンピューターサービス（DCS） SI技術部 技術推進グループ ITマネジャー 竹中一博氏）。
(2)エージェント型ツールの弱点は，サンプリング周期を短くしないとログを取りこぼす可能性がある点だ。一方の(3)パケット・キャプチャ型ツールの弱点は，DBサーバーに直結したキーボードからの操作を取得できないこと。特性を見極めてDBログ収集/監査ツールを選定したい。
犯人を特定するなら参照データが必要
次に，ログとして残しておくべき項目と，ログの保管方法について，詳しく見ていこう。
DB監査ログに残すべき情報の基本は，「誰が，いつ，何に，何をしたか」である。だが，これらだけでは犯人の特定が難しいケースがある。
例えば，ある顧客から「そちらのサービスでしか利用していない名前が印刷されたダイレクト・メールが別の会社から来た。漏洩したのではないか？」という問い合わせが来ても，誰が漏洩させたのかを見つけるのは困難だ。なぜなら，ログには「どんなことをしたか」という操作の履歴を残していても，その参照データは残していないからだ。RDBMS内のデータが随時変更されているなら，後から「どんなことをしたか」が分かっても，「どのデータを参照したか」を特定できない。あるいは，探し出すまでに相当長い時間がかかるだろう。
逆に言えば，漏洩したと思われるデータからの犯人特定を目的とするなら，データベースからの参照データをログとして残せばよい。実際，冒頭で紹介したトマデジは，参照データをログとして残している（トマデジのDBセキュリティ対策は別掲記事「犯人を特定することは可能」を参照）。
少なくとも「万一，大量の情報漏洩が発生した場合，犯人をある程度まで特定できる」（ぷららネットワークス 荒木氏）ようにしておきたい。そのために荒木氏らは，タイム・スタンプ（いつ），DBユーザー，アクセスしているマシン名やIPアドレス（誰が），顧客情報テーブルなどのアクセス先オブジェクト名（何に），SQL文やログイン/ログアウト（何をした）——などの項目を取得している。
何をログとして残すべきかについては，業界団体の「データベース・セキュリティ・コンソーシアム」が，「犯人特定のためにどのくらい詳細な項目が必要なのかを議論し，来春には成果物を出していく予定だ」（監査ログ・フォレンジックWGのリーダーを務める，日本オラクル システム事業推進本部 営業推進部 担当シニアマネジャー 北野晴人氏）という。
3階層ではユーザー情報が残らない
DB監査ログを保存する上で課題になるのが，(1)3階層のWebシステムでは誰がアクセスしたかが分からないことと，(2)ログそのものの正当性を確保すること——である。
3階層のWebシステムの場合，DBサーバーに直接アクセスしているのはAPサーバーであり，DBサーバーにはアプリケーションの利用者が分からない。これでは，DB監査ログに必要な「誰が」の情報が不十分だ。この問題を解消するため，ぷららネットワークスの荒木氏らは，アプリケーションを一部修正し，ユーザー情報をDB監査ログに残せるようにした（図4[拡大表示]）。
アプリケーションがOracle DBにセッションを張る際に，「DBMS_APPLICATION_INFO」というOracleのパッケージを利用した。具体的には，「DBMS_APPLICATION_INFO.SET_CLIENT_INFO」と「DBMS_APPLICATION_INFO.SET_MODULE」という2つのプロシージャを業務アプリケーションから呼び出し，Oracle DBのV$SESSION表にユーザー情報（マシン名とIPアドレス）を書き込む。この情報を，DBログ収集/監査ツールのPISOで読み取るようにした。
権限を分け，ログを改ざんさせない
ログそのものの正当性を確保しておかなければ，証拠としては不十分だ。ぷららネットワークスの荒木氏らは，日本ネットワーク・アプライアンスのNAS装置「NetApp FAS920」にDB監査ログを保管。この装置のオプションである，データ読み出しだけを許可する「SnapLock」という改ざん防止機能を利用し，ログを改ざんから守っている。さらに，DB監査ログのバックアップにはDVD-Rを使い，書き込んだら変更できないようにしている。
DBログ収集/監査ツールを使う場合，そのツールへのアクセス権をデータベース管理者に与えないことも，ログの改ざんや削除を防ぐ方法の一つである。ディップや人事アウトソーシング企業（電通国際情報サービスがシステム構築を担当），流通系企業（日立システムアンドサービスがシステム構築を担当）では，データベース管理者とは別にセキュリティ担当者を配置し，この担当者だけにIPLocksへのアクセス権限を与えている。これにより，データベース管理者によるログの改ざんを防いでいる。
|
トマデジのDBセキュリティ対策 トマデジの舟橋氏は，放送業向けASPサービス「Unified Transaction System」に，不正ユーザーにデータベース・アクセスさせない，監査ログを取得する，データを暗号化する──などの仕組みを盛り込んだ。 アプリケーションについては，不正ユーザーに利用させないためユーザー認証を強固にした。端末認証にクライアント証明書を，ユーザー認証にIDとパスワードを使うこととし，両方がそろって，はじめてASP利用企業の担当者がアプリケーションを利用できる。 アプリケーションを利用する権限を持つ正規ユーザーから万一情報が流出してもそのユーザーを特定できるよう，RDBMS，データベースとの通信内容を記録する装置，アプリケーション，の3つでDB監査ログを取得している。「いつ，誰が，何に，何をしたか，を可能な限り保存し，監査できるようにした。データベース検索の結果データも，厳重に管理・監査した状態でログとして保存している」（同氏）。これにより，万一たった1人の視聴者の情報が漏洩したとしても「犯人を特定することは可能」（同氏）という。また，これらのログの信頼性を保証するため，専用ツールで改ざんを検知する仕組みを取り入れている。 データはすべて暗号化している。テーブルの重要なカラムをデータベース管理者が参照したとしても，データの内容が分からないよう，Oracle DBの機能を使い暗号化している。視聴者ごとに暗号鍵を変えて暗号化している念の入れようだ。さらに，「データセンターへの入室権限所有者がディスクやテープを持ち出して個人情報が大量漏洩するリスクをゼロにするため」（同氏），データベースを専用装置「DataFort」で暗号化している。 想定外の事象もカバーこのように，想定できることは技術面でカバーしたが，「想定できないことも起こり得る」と舟橋氏は考えた。同社の担当者は，ASP利用企業の個人情報を操作したり閲覧したりしないのが基本である。しかし，顧客企業からの要請でやむを得ず個人情報を扱わなければならないこともある。その場合「2人1組で顧客が利用するアプリケーションを操作した上，監視カメラで行動を監視。また，社内規定に罰則を設け，悪さをしたくならないようにしている」（同氏）。 |
