はじめに
Db2では、セキュリティや内部統制の観点から「誰が・いつ・何をしたか」を記録する監査機能が提供されています。
特に近年は、操作ログの取得だけでなく、
・特定ユーザーの操作を追跡したい
・SQL実行内容を詳細に記録したい
・監査対象を最小限に絞りたい
といった要件が増えており、柔軟な監査設計が求められます。
本記事では、Db2の監査機能の基本構造と、実務で重要となるデータベースレベル監査を中心に整理します。
Db2の監査機能の全体像
Db2の監査機能は、大きく以下の2種類に分かれます。
| 種類 | 特徴 |
|---|---|
| インスタンスレベル監査 | インスタンス全体を対象に監査 |
| データベースレベル監査 | データベース単位で個別に監査 |
また、監査は「カテゴリー」という単位で取得内容を制御します。
主なカテゴリーは以下の通りです。
| CATEGORY | 内容 |
|---|---|
| AUDIT | 監査設定の変更 |
| CHECKING | オブジェクトアクセスの検査 |
| OBJMAINT | オブジェクト作成・削除 |
| SECMAINT | 権限変更 |
| SYSADMIN | 管理者操作 |
| VALIDATE | 認証・セキュリティ情報 |
| CONTEXT | 実行コンテキスト |
| EXECUTE | SQL実行（DBレベルのみ） |
用途に応じて、必要なカテゴリーだけを選択して監査します。
データベースレベル監査の特徴
データベースレベル監査は、実務で最も利用される監査方式です。
インスタンスレベル監査との違いは以下の通りです。
| 観点 | インスタンスレベル | データベースレベル |
|---|---|---|
| 管理単位 | インスタンス単位 | DB単位 |
| ログ出力 | 1つのログに集約 | DBごとに分離 |
| 監査対象 | 全DBが対象 | 対象を限定可能 |
| 柔軟性 | 低い | 高い |
データベースレベル監査の最大の特徴は、
・特定テーブル
・特定ユーザー
・特定権限
といった単位で監査対象を絞り込める点です。
これにより、不要なログ出力を抑えながら、必要な情報だけを取得できます。
監査ポリシーと監査の設定の流れ
データベースレベル監査は、以下の流れで設定します。
| 手順 | 内容 |
|---|---|
| 1 | 監査ポリシー作成（CREATE AUDIT POLICY） |
| 2 | 対象へ適用（AUDITコマンド） |
| 3 | ログ取得 |
| 4 | アーカイブ |
| 5 | 抽出・解析 |
具体的なポイントは以下です。
・ポリシーで「何を監査するか」を定義
・AUDITコマンドで「どこに適用するか」を指定
・ログはバッファに書き込まれた後、ファイルへ出力
さらに、ログは以下の流れで処理されます。
| フェーズ | 説明 |
|---|---|
| ACTIVE | 現在書き込み中の監査ログ |
| ARCHIVE | アーカイブされたログ |
| EXTRACT | 解析用に抽出 |
この仕組みにより、監査ログを効率的に管理できます。
EXECUTEカテゴリーの役割と活用
EXECUTEカテゴリーは、SQL実行の監査に特化した重要な機能です。
従来はCONTEXTカテゴリーで対応していましたが、より詳細な情報取得が可能になっています。
主な特徴は以下の通りです。
| 項目 | 内容 |
|---|---|
| 対象 | SQLステートメントの実行 |
| 対応SQL | 動的SQL・静的SQLの両方 |
| 取得情報 | SQLテキスト、実行情報など |
さらに、WITH DATAオプションを使用すると、以下の情報も取得できます。
・入力パラメータ
・ホスト変数の値
・データ型や長さ
これにより、
「どのSQLが、どの値で実行されたか」
まで追跡可能になります。
なお、大容量データ（LOB、XMLなど）は対象外となる点に注意が必要です。
監査設計の注意点（実務で重要なポイント）
監査機能は強力ですが、設計を誤ると「ログ過多」「性能劣化」「運用負荷増大」につながります。
ここでは実務で特に重要なポイントを整理します。
ユーザ種別で監査方針を分ける
Db2にアクセスするユーザは、大きく以下の2種類に分けて考えます。
| ユーザ種別 | 用途 | 監査の考え方 |
|---|---|---|
| 運用ユーザ | 人が直接操作 | 詳細監査（操作ログ含む） |
| システムユーザ | バッチ・アプリ・監視 | 最小限（認証中心） |
このように分けることで、
・人の操作は詳細に追跡
・システム処理は必要最小限
というバランスの良い監査設計が可能になります。
すべてのユーザを同じ粒度で監査すると、ログ量が爆発的に増えるため注意が必要です。
EXECUTE + WITH DATAは慎重に使う
EXECUTEカテゴリーにWITH DATAオプションを付けると、
・SQLの実行内容
・入力パラメータ
・実際のデータ値
まで取得できます。
一見便利ですが、大量データ処理と組み合わせると問題になります。
例えば、
・バッチで大量INSERT
・一括更新処理
・データ移行
を実行した場合、そのデータがすべて監査ログに出力されます。
結果として、
・監査ログの肥大化
・ディスク圧迫
・性能低下
が発生します。
そのため、実務では以下の対応が有効です。
・大量処理前にWITH DATAを無効化（監査設定削除）
・監査対象外のユーザで処理を実施
用途に応じて使い分けることが重要です。
監査ログの肥大化とアーカイブ処理に注意
監査ログは１つのバイナリファイルに出力されるため、サイズが大きくなりやすい特徴があります。
特に注意すべきなのは、ログが数GB規模になった場合です。
この状態でアーカイブを実行すると、
・archive処理が長時間ブロックされる
・数時間応答が返らない
といった事象が発生することがあります。
このようなケースでは、
・不要な監査ログは事前に削除する
・ログを肥大化させない設計にする
といった対策が有効です。
監査は「取得すること」だけでなく、「管理すること」まで含めて設計する必要があります。
まとめ
Db2の監査機能は、柔軟かつ強力なログ取得機能です。
・インスタンスとDBレベルで監査方式が異なる
・データベースレベル監査は柔軟性が高い
・監査ポリシーで細かく制御できる
・EXECUTEカテゴリーでSQL実行を詳細に追跡可能
特に実務では、
「必要な対象だけを監査する設計」
が重要になります。
具体的なコマンドや監査ログの見方については、IBMの公式資料「Db2 for LUW セキュリティ・ガイド 監査編」を参考にしてください。
コメント