データベースアクセス監査ツール「WEEDS DB-Trace」
「個人情報が格納されているDBのアクセスを把握したい」
「内部統制の監査で“DBアクセスログ”について指摘されたが、どうすればいいかわからない」
「システム担当から“パフォーマンスの劣化”を危惧され、DBアクセス監査が開始できない」
「RDBMSのログは取っているが、見方がわからないため監査できない」
データベースのアクセス監査を実施しようとご検討されているお客様では、このようなお悩みがあると思われます。
2005年4月に施行された個人情報保護法対策の時から広くお客様へご提供している「WEEDS DB-Trace」であれば、様々な顧客環境に適応して、お悩みなく導入することができます。
データベースアクセス監査とは
“データベース（ＲＤＢ）アクセス”とは、“ＳＱＬ”のことを指し、そのＳＱＬには大きく“ＤＤＬ文”（テーブル作成/変更、ストアドプロシージャ登録/変更など）と“ＤＭＬ文”（データの参照/追加/更新/削除など）があります。
そして、“データベースアクセス”には、大きく２種類存在します。下図の通り、“①アプリケーションからのアクセス”と運用・メンテナンスなどでアクセスされる“②直接アクセス”です。
これらのアクセス種別を把握し、データベースへのアクセスに不正がないことを証明することがデータベースアクセス監査です。
WEEDS DB-Traceとは
WEEDS DB-Traceは、すべてのアクセスを取得するため、RDBMS（Oracle、SQL Server、DB2、Teradata）が生成するログを基に、「いつ、どのユーザーが、どこから、どの情報へ、どのようなアクセスをしたか」などの情報を取得／解析処理を行います。
WEEDS DB-Traceによって解析処理されたログは、即座にログ蓄積サーバー（ログリポジトリーサーバー）へ転送され、ログデータベースへロードされます。ログリポジトリーサーバー上では、WEEDS Log-Repository Managerによってログは管理され、監査レポートの生成やログメンテナンス（定期退避、バックアップ、リストア）を行えます。
監査対象データベースへ出力されたRDBのログは、WEEDS DB-Traceが解析処理を実行後（標準では）削除し、監査対象DBへ負担をかけないよう対処しています。
データベースアクセス監査のポイント
このデータベースアクセス監査を行う上で重要な点は以下の通りです。
・すべてのユーザーの、すべての経路からのアクセスを、漏れなく取得すること。
・いつ、どのユーザーが、どこから、どの情報へ、どのようなアクセスをしたかなど、
アクセス監査に必要な情報を保持すること。
・取得／保持したアクセスログ（監査証跡）を容易に監査できること。
アクセス監査を実施する上で、上記の環境を構築することは必須と言えます。
このポイントをすべて網羅したツールが、WEEDS DB-Traceです。
ポイント：すべてのアクセスを漏れなく取得
上記のアーキテクチャから、WEEDS DB-Traceは漏れなくアクセスログを取得できるといえます。
それは、①RDBMSが保証したログをインプットとしてアクセスログを生成しているため、漏れのないログファイルから解析処理をする機構にしているWEEDS DB-Traceにも、取得漏れがないと言えます。
例えば、アクセスログをRDBMSのメモリから取得する方法もありますが、この方法の場合、メモリから消えてしまえば取得漏れを起こす可能性があります。このような機構では“取得漏れがない”ことを証明することが難しいため、手段としては避けるべきと考えられます。
また、②RDBMSが出力したログはOS上のファイルとして出力されるものを採用しているため、万が一WEEDS DB-Traceが実行されなかったとしても、ログが消えてしまうことはありません。再度、処理実行することで、アクセスログを取得することができます。
そして、③RDBMSのログを使用していることで、どのような経路のアクセスでも、ログを取得することができます。例えば、アクセスログをネットワークパケットから取得する方法もありますが、この方法の場合、DBサーバーのコンソール（DBサーバー実機）でアクセスした場合、ネットワークを通過せずアクセスログを取得できません。
ポイント：アクセス監査に必要な情報を保持
WEEDS DB-Traceでは下記の情報をアクセスログ項目として取得することが可能です。特に重要な項目は、“アクセスしたテーブル及びフィールド”、“アクセスに利用したアプリケーション”です。
| Oracle | SQL Server | DB2 | Teradata | |||
| 取得項目 | Win | UNIX系 | Win | Win | Linux | - |
| DB名 | ● | ● | ● | ● | ● | ● |
| ログイン日付/時刻 | ● | ● | ● | ● | ● | ● |
| ログオフ日付/時刻 | ● | ● | ● | ● | ● | ● |
| ログイン失敗 | ● | ● | - | - | - | - |
| DBユーザーID | ● | ● | ● | ● | ● | ● |
| 端末ユーザーID | ● | ● | ● | ● | ● | ● |
| 端末名 | ● | ● | ● | ● | ● | ● |
| 端末IPアドレス | ● | ● | ● | ● | ● | ● |
| アプリケーション名 | ● | ● | ● | ● | ● | ● |
| SQL文（全文） | ● | ● | ● | ● | ● | ● |
| SQLのアクション | ● | ● | ● | ● | ● | ● |
| SQLでアクセスしたテーブル | ● | ● | ● | ● | ● | ● |
| SQLでアクセスしたフィールド | ● | ● | ● | ● | ● | ● |
| SQLでアクセスした際の条件 | ● | ● | ● | ● | ● | ● |
| SQL実行順序 | ● | ● | ● | ● | ● | ● |
| SQL文内コメント | ● | ● | ● | - | - | ● |
| SQL実行開始日付/時刻 | ● | ● | ● | ● | ● | ● |
| SQL実行終了日付/時刻 | ● | ● | ● | ● | ● | ● |
| データ読込量(アクション毎) | - | - | ● | - | - | - |
| データ読込量(セッション合計) | ● | ● | ● | ● | ● | - |
| データ読込件数(アクション毎) | ● | ● | - | - | - | - |
| データ書込量(アクション毎) | - | - | ● | - | - | - |
| データ書込量(セッション合計) | ● | ● | ● | ● | ● | - |
| SQL実行結果ステータス | ● | ● | ● | ● | ● | - |
ポイント：アクセスログを容易に監査できること
単純に“SQLを監査”と言っても、SQL文を1件1件人間の目で監査することは、非効率ですし、監査漏れリスクを排除できません。
また、下記のように簡単なSQL文であっても、不正か否か判断するにはSQLの知識が必要になります。
では、どのように監査すればよいのでしょうか。
上記の通り、DBアクセス監査では、SQL文を1件1件人間の目で監査することは非現実的です。
また、月次の監査では、アクセスを集計して監査したいわけですが、SQL文を文字列として保持していては、アクセスを集計することができません。
そこでWEEDS DB-Traceでは、独自にSQL文を構文解析して、“どのテーブルの”、“どのフィールドに”、“どのような条件で”、“どのようなアクセス（参照、追加、更新、削除など）をしたか”を別途ログとして保持しています。
このことで、１アクセスに対して、どのテーブルの、どのフィールドへ、どのようなアクセスであったのかが明確になります。
このようにログを保持しておくことで、大量に存在するログの中から監査の目的にあったログを抽出できるようになります。
例えば監査の目的が“個人情報保護対策”であれば“個人情報への参照”、“財務諸表の不正改ざん”であれば“財務諸表に関るテーブルの変更（挿入、更新、削除）”だけを抽出することができるようになります。
また、テーブル毎にアクセス集計することも可能になり、下図の監査レポートのように、月間でテーブル毎のアクセス集計をレポーティングできるようになります。
このようなログの蓄積をしておかないと、監査を実施することは難しいと考えられます。
WEEDS DB-Traceには以下の監査レポートが標準で装備されています。
| 監査レポート名 | 説明 | ||
|---|---|---|---|
| 日次監査レポート | 特権ユーザ操作 | 特権ユーザとして登録されたDBユーザで監査対象DBへログイン、操作すると、出力されます。 | |
| DB直接アクセス | 許可されたアプリケーション以外でDBにログイン、操作を行うと、出力されます。（アプリケーションを許可する場合は、WEB画面にて登録が必要です） | ||
| 大量データアクセス | 設定値以上のデータを参照、挿入すると、出力されます。（大量データの定義は設定できます） | ||
| ログイン失敗一覧 | 監査対象DBへログインに失敗すると、出力されます。 | ||
| SQL実行失敗 | SQLの実行に失敗すると、出力されます。 | ||
| 高負荷データアクセス | 設定値以上に、SQL実行結果の返信に時間がかかると、出力されます。（時間は設定できます） | ||
| 大量レコードアクセス | 設定値以上のレコードを参照すると、出力されます。（大量レコードの定義は設定できます） | ||
| 監視テーブルアクセス | 監視対象として登録されたテーブルにアクセス(参照、変更、その他)すると、出力されます。 | ||
| 時間外アクセス | 作業可能時間外にログイン、操作を行うと、出力されます。（作業可能時間は設定できます） | ||
| 時間外-監視テーブルアクセス | 作業可能時間外に監視対象として登録されたテーブルにアクセス(参照、変更、その他)すると、出力されます。 | ||
| DB利用申請 | 監査対象DBの利用を申請すると、出力されます。(申請はWEB画面にて行います。別途マニュアル参照) | ||
| DB未申請利用 | 監査対象DBの利用申請が行われていない時間帯、ユーザーでログイン、操作が行われた場合、出力されます。 | ||
| 月次監査レポート | ユーザ利用履歴一覧 | 現在使用しているユーザと、使用しなくなったユーザ一覧が出力されます。 | |
| 月間アクセス分布 | ログイン数 | 月間の合計ログイン数を分布図として出力します。監査対象DBへログインがあった場合出力されます。 | |
| テーブル変更数 | 「月間の合計テーブル変更数(INSERT、DELETE、UPDATE)を分布図として出力します。監査対象DBへ変更の操作があった場合出力されます。 | ||
| 月間監査項目状況一覧 | 月間のログイン数、SELECT数、取得レコード数、挿入・削除・更新数、CREATE数、ALTER数、その他SQL数を日別に表示します。監査対象DBへログイン、操作があった場合出力されます。 | ||
| 年間監査項目状況一覧 | 年間のログイン数、SELECT数、取得レコード数、挿入・削除・更新数、CREATE数、ALTER数、その他SQL数を月別に表示します。監査対象DBへログイン、操作があった場合出力されます。 | ||
| 月間アクセス 集計 |
テーブル変更 | 月間の合計テーブル変更数(INSERT、DELETE,UPDATE)を日別に出力します。監査対象DBへログイン、操作があった場合出力されます。 | |
| 年間アクセス 集計 |
テーブル変更 | 年間の合計テーブル変更数(INSERT、DELETE,UPDATE)を月別に出力します。監査対象DBへログイン、操作があった場合出力されます。 | |
| 初回アクセスリスト | 期間内に初めてログインのあったユーザ名のログインのリストを表示します。監査対象DBへログイン、該当の操作があった場合出力されます。 | ||
| 監視テーブル設定一覧 | DBの監視対象テーブルの登録状況の一覧。監視対象テーブルが登録されている場合出力されます。 | ||
| 利用分析レポート | 月間アクセス 分布 |
ログイン数 | 月間の合計ログイン数を分布図として出力します。監査対象DBへログインがあった場合出力されます。 |
| 参照コマンド数 | 月間の参照回数(SELECT)が分布図として出力されます。監査対象DBへログイン、操作があった場合出力されます。 | ||
| 追加コマンド数 | 月間の追加回数(INSERT)が分布図として出力されます。監査対象DBへログイン、操作があった場合出力されます。 | ||
| 削除コマンド数 | 月間の削除回数(DELETE)が分布図として出力されます。監査対象DBへログイン、操作があった場合出力されます。 | ||
| 更新コマンド数 | 月間の更新回数(UPDATE)が分布図として出力されます。監査対象DBへログイン、操作があった場合出力されます。 | ||
| 作成コマンド数 | 月間の作成回数(CREATE TABLE)が分布図として出力されます。監査対象DBへログイン、操作があった場合出力されます。 | ||
| 変更コマンド数 | 月間の変更回数(ALTER)が分布図として出力されます。監査対象DBへログイン、操作があった場合出力されます。 | ||
| アクセス数 | 月間のアクセス合計数が分布図として出力されます。監査対象DBへログイン、操作があった場合出力されます。 | ||
| 月間アクセス集計 | アプリケーション、端末ユーザ、DBユーザ、テーブル名別のアクセス回数を出力します。（登録したアプリケーションを除くことも可能）監査対象DBへログイン、操作があった場合出力されます。 | ||
| 年間アクセス集計 | アプリケーション、端末ユーザ、テーブル名別のアクセス回数を出力します。（登録したアプリケーションを除くことも可能）監査対象DBへログイン、操作があった場合出力されます。 | ||
| データベース アクセス 利用明細 |
ログイン一覧 | データベースへのログイン一覧。（ログイン時間別）監査対象DBへログインがあった場合出力されます。 | |
| ログイン失敗一覧 | データベースへのログイン失敗一覧。（ログイン時間別）監査対象DBへログイン失敗があった場合出力されます。 | ||
| ユーザ一覧 | データベースへの操作一覧。（ユーザ別）監査対象DBへログイン、操作があった場合出力されます。 | ||
| 実行SQL一覧 | データベースへのアクセス一覧。（実行SQL別）監査対象DBへログイン、操作があった場合出力されます。 | ||
あらかじめ監査ポリシーを登録しておくことで、システマチックに監査
上記のように“意味のあるアクセスログ”を保持すれば、属人性を排除してシステマチックに監査することが可能になります。
それは、あらかじめ“監査ポリシー”を登録しておき、膨大なアクセスログと突合させ、ポリシー違反しているログを抽出することで実現できます。
| 監査ポリシー | |
|---|---|
| 時間外設定 | 指定時間外での操作を「時間外アクセスレポート」にて自動出力 |
| 特権ユーザー設定 | 特権ユーザーでの操作履歴を「特権ユーザー操作レポート」にて自動抽出 |
| 監視テーブル・ フィールド設定 |
監視対象として登録した「テーブル」「フィールド」に該当したアクセスを 「監視テーブルアクセスレポート」にて自動抽出 |
| 大量データ設定 | 指定した読込みbite数、書込みbite数を超えたアクセスを 「大量データアクセスレポート」にて自動抽出 |
| DBアクセス負荷設定 | 指定した時間の閾値を超えたアクセスを「高負荷データアクセスレポート」 にて自動抽出 |
上記の監査ポリシーを設定することによって、“日次監査レポート”及び“月次監査レポート”がボタン一つで作成することができるようになります。
“監査対象ログ”と“監査対象外ログ”の分別
DBアクセスログを取得してみると、監査対象外と判断しても良いアクセスログが大量に収集されます。夜間自動バッチ処理のアクセスなどがそれに該当します。
夜間に自動で実行されるバッチは、人間の手によって実行されるものではないため、アクセス監査の対象外と判断されます。しかし、このアクセスログまで保持してしまうと、大量のログデータとなり、本来の監査がやりにくくなります。
そこでWEEDS DB-Traceでは、夜間自動バッチなどの監査対象外のログを分別し、ログデータとして蓄積しないことが可能です。
上記の取得ログ項目で条件を絞って夜間自動バッチとして判別します。一般的にはアプリケーション名で夜間自動バッチと判断してログを判別します。
製品仕様
| 導入効果 | 内部統制（IT全般統制対応）、監督官庁監査対応、個人情報保護法対応、 システム内部監査対応、Pマーク、ISMS対応 |
|
| エージェント モジュール | 対応DB | Oracle7以降、SQL Server Ver7以降、DB2 Ver7以降、 Teradata Ver4以降、Sybase IQ 12.7,15.2 |
| ログ取得 | RDBMS標準ログを取得 | |
| DBサーバーへ の負荷 | 標準ログ出力による負荷とエージェント実行時の負荷がありますが、 共に業務に影響なく対応可能。手法はお問合せ下さい。 |
|
| ログ | ログ取得項目 | 前述の通り |
| ログ種別 | 全SQL文（DDL、DML） | |
| 暗号化 | 独自暗号化した状態でアクセスログを生成 | |
| 転送 | エージェント実行時に転送（通常１～３回／日） | |
| ログ量 | 5kb／SQL（アクセス量によって変動します） | |
| ライセンス体系 | DB単位（Oracleはインスタンス単位） | |
| 価格 | オープン（ボリュームディスカウント有り） | |
| オプション | WebAccess オプション | Webアプリケーションに代表される3階層システムによる、アプリ ケーション経由のDBアクセスにおいて、WebサーバーのW3Cログ とWEEDS DB-TraceをHINTファイルによって突合させ、どの端末 からのアクセスかを特定させるオプション。 |
| Application オプション | アプリケーションのログインSQLからログインIDを取得し、そのDB セッションのアクセス者はそのログインIDに更新するオプション。 アプリケーションユーザーIDによってDBアクセス監査を行う場合に適用。 |
|
OracleやSQL Serverのログを保持しておけば十分か？
WEEDS DB-Traceは、RDBMS標準ログを利用していますが、そもそもRDBMS標準ログを保持しておけば、それが監査ログになりうるのでは？という質問をいただくことがあります。
しかし、RDBMS標準ログでは、監査ログとして欠落している部分や、逆にリスクを高めてしまいます。
下記に、OracleとSQL Serverの標準ログについてまとめましたので、ご参考にしてください。
| Oracle ： Auditログの課題 | |
|---|---|
| ログ | Oracle Auditログ（テーブル出力、イベントログ出力の2種類がある） |
| ログの精度 | ・管理者ユーザーのアクセスログが取得できない。（テーブル出力の場合） ・SQL文は2,000byteまでしか保持していない。 ・どのアプリケーションからのアクセスかわからない。 ・例えば１SQLで3テーブルを参照した場合、同一ログが3レコード生成される。 ・イベントログに出力する方法では、SQL文が取得できない。 （“SELECT”などのアクションのみ） |
| 安全性 | ログが暗号化されずに保持。SQL文から個人情報や機密情報が漏洩する危険がある。 （特にInsert文はデータそのもの） つまり、ログそのものが情報漏洩のリスク要因となってしまう。 |
| 監査運用 | ・バージョンによって取得項目が異なり統一した監査ができない。 ・Auditの出力先はSYSTEM表領域に限られ、パフォーマンス劣化を回避できない。 （ログ挿入とログ削除（メンテナンスで）が競合し、著しくパフォーマンスを低下） ・イベントログでは検索ができず、一覧表示も難しいため、監査運用に手間隙がかかる。 |
| SQL Server ： Traceファイルの課題 | |
|---|---|
| ログ | Traceファイル |
| ログの容量 | ログファイルは“Unicode”であるため、半角文字であっても全て2バイトの容量になる。 （つまり、SJISに変換するだけでログ量は1/2に圧縮できる） |
| 安全性 | Oracleと同様に、 ログが暗号化されずに保持。SQL文から個人情報や機密情報が漏洩する危険がある。 （特にInsert文はデータそのもの） つまり、ログそのものが情報漏洩のリスク要因となってしまう。 |
| 監査運用 | ・SQLプロファイラの画面でしか監査が出来ないため、加工や集計、絞込みが難しい。 ・画面のログ情報をExcelに貼り付けると、SQL文は２５６Byteしかコピーされない。 （SQL文全体を監査することが出来なくなる） |
ネットワークパケットや、メモリ参照によってアクセスログを取得できるか？
WEEDS DB-Traceでは、ネットワークパケットやメモリ参照によって、DBアクセスログ（SQL）を取得するアーキテクチャを採用しませんでした。
それは、アクセスログに取得漏れが発生するリスクが高い（取得漏れしていないことを証明することが不可能）からです。
詳しくは、「WEEDS COLUMN!!」にまとめておりますので、ご参考にされてください。
→本当に監査できてる？パケットキャプチャ型ツールの問題点
.jpg)