db2audit - 監査機能管理者用ツール・コマンド
Db2® データベース・システムは、データへの不明または予期しないアクセスの検出を支援する監査機能を提供します。 Db2 監査機能は、事前定義された一連のデータベース・イベントの監査証跡を生成し、 その保守を許可します。
この機能で生成されたレコードは、監査ログ・ファイルに保持されます。 これらのレコードを分析すると、 システムの誤用を識別する使用パターンが明らかになります。 そのようなシステム誤用を識別した場合、それを制限または除去できます。 監査機能はインスタンス・レベルとデータベース・レベルの両方で動作し、インスタンスまたはデータベースに基づいてすべてのアクティビティーを別々のログに個別に記録します。
Db2 データベース・システムには、インスタンス・レベルおよび個々のデータベース・レベルで別個に監査する機能があります。 インスタンス・レベルの監査を構成して、そのような監査情報をいつ収集するかを制御するには、db2audit ツールを使用します。 個々のデータベースの監査要件を構成して制御するには、AUDIT SQL ステートメントを使用します。 db2audit ツールを使用して、インスタンスおよびデータベースの監査ログをアーカイブしたり、いずれかの種類のアーカイブ・ログから抽出したりすることができます。 追加情報については、以下の 「関連リンク」 セクションを参照してください。
Db2 pureScale® 環境やパーティション・データベース環境などの複数メンバー・データベース環境で作業している場合、監査可能イベントの多くは、ユーザーが接続されているデータベース・メンバー (コーディネーター・メンバー) またはカタログ・メンバー (同じデータベース・メンバーでない場合) で発生します。 つまり、監査レコードは、複数のデータベース・メンバーによって生成される可能性があります。 各監査レコードの一部には、コーディネーター・メンバーおよび発信元データベース・メンバーの ID に関する情報が含まれています。
インスタンス監査ログ (db2audit.instance.log.node_number[.timestamp]) はインスタンスの security/auditdata サブディレクトリーに配置され、監査構成ファイル (db2audit.cfg) はインスタンスの security サブディレクトリーに配置されます。 データベース監査ログ名はdb2audit.db.dbname.log.node_number[.timestamp]です。 インスタンスの作成時点では、オペレーティング・システムにより、それらのファイルに対して可能な限り読み取り/書き込み権限が設定されています。 デフォルトでは、その権限はインスタンスの所有者にとってのみの読み取り/書き込み権限です。 それらの権限は変更しないようにしてください。
アーカイブ・ログ・ファイルに対して指定するデフォルトの権限は、インスタンス所有者のみの読み取り/書き込み権限です。 これらの権限を変更しないでください。
ファイルを抽出した場合、その抽出されたファイルの権限はすべてのユーザーに対して読み取り/書き込み権限となります。 ファイル名は、抽出コマンド・キーワードを使用して指定できます。 特定の名前を使用することで、ファイルの配置場所を制御できます。 抽出されたファイルを保護する場合は、読み取り/書き込み権限がインスタンス所有者にのみ定義されるように、抽出されたファイルに対するファイル権限を変更できます。
- Db2 インスタンス内で監査可能イベントの記録を開始する。 データベース・レベルの活動は、これに含まれません。
- Db2 インスタンス内で監査可能イベントの記録を停止する。
- 監査機能の振る舞いを構成する (インスタンス・レベルのみ)。
- 記録する監査可能イベントのカテゴリーを選択する (インスタンス・レベルのみ)。
- インスタンスに関する現在の監査構成の説明を要求する。
- ペンディング中の監査レコードをインスタンスからフラッシュし、 監査ログに書き込む。
- インスタンス、またはインスタンスの下のデータベースに関する現在の監査ログからアーカイブ監査レコードを生成する。
- 監査レコードを書式設定してフラット・ファイルまたは ASCII 区切りファイルにコピーすることにより、監査レコードをアーカイブ監査ログから抽出する。 抽出は、ログ・レコード分析の準備として実行されます。
許可
SYSADM
必要な接続
なし
コマンド構文
コマンド・パラメーター
- configure
- このパラメーターを使うと、インスタンスの security サブディレクトリーにある db2audit.cfg 構成ファイルを変更できます。 このファイルに対する更新は、インスタンスが停止されている場合でも発生することがあります。 インスタンスがアクティブである場合に発生する更新は、Db2 インスタンスによって実行される監査に動的に影響を与えます。 構成ファイルに対するconfigureアクションにより、監査機能が開始され、監査可能なイベントのauditカテゴリーが監査される場合、監査レコードが作成されます。 (データ・パスとアーカイブ・パスを除く) すべての構成オプションは、データベース・レベルの監査イベントではなく、インスタンス・レベルの監査イベントにのみ適用されます。 パスのオプションは、インスタンスおよびインスタンス内のすべてのデータベースに適用されます。構成ファイルに対して可能なアクションは、以下のとおりです。
- reset
- このアクションにより、構成ファイルは初期構成に戻ります(scopeコンテキストを除くすべてのカテゴリーは、各カテゴリーのstatus が障害であり、 errortypeは正常であり、インスタンスレベルのイベントの監査がオフになっています)。 オリジナルの監査構成ファイルが失われたか壊れている場合にこのアクションが実行されると、監査構成ファイルが新たに作成されます。 監査データ・パスとアーカイブ・パスはブランクになります。 このオプションは、監査ポリシー、およびデータベース・レベルでのこれらのポリシーの使用をリセットしません。
- scope
- このアクションは、どのカテゴリーを監査するか、および対象となる各カテゴリーの状況を指定します。
- status
- このアクションは、ログ記録の対象が成功したイベントだけなのか、失敗したイベントだけなのか、それとも成功したイベントと失敗したイベントの両方なのかを指定します。 status には、以下のオプションがあります。
- both
- 成功したイベントと失敗したイベントがどちらも監査されます。
- none
- このカテゴリーのイベントは監査されません。
- failure
- 失敗したイベントだけが監査されます。
- success
- 成功したイベントだけが監査されます。
注:- デフォルトのscope は、 context 以外のすべてのカテゴリーであり、レコードが迅速に生成される可能性があります。 カテゴリーの選択は、モード (同期か非同期か) と共にパフォーマンス低下の大きな原因となる可能性があり、ディスク要件がどれだけ増大するかを大きく左右することになります。 ログ記録の対象となるイベントの数と種類を可能な限り限定することをお勧めします。 そうしないと、監査ログのサイズがすぐに肥大化してしまいます。 また、このアクションを実行することにより、監査を特定の対象に絞ることができ、ログの肥大化を抑えることができます。
- contextイベントは、操作状況が認識される前に発生します。 したがって、このようなイベントは、statusがnoneでない限り、このパラメーターに関連付けられている値に関係なくログに記録されます。
- 同じカテゴリーが繰り返された場合、または all キーワードによってカテゴリーが重複して指定されている場合には、構文エラーが戻されます。
- errortype
- このアクションは、監査エラーがユーザーに戻されるのか、それとも無視されるのかを指定します。 このパラメーターの値として可能なのは、以下のとおりです。
- audit
- 監査機能内で発生したエラーを含むすべてのエラーは、 Db2 データベースによって管理され、すべての負の SQLCODE が呼び出し元に報告されます。
- normal
- db2audit によって生成されたエラーはすべて無視され、実行中の操作に関連したエラーの SQLCODE のみがアプリケーションに戻されます。
- datapath audit-data-path
- これは、Db2 データベース・システムによって生成された監査ログが書き込まれるディレクトリーです。 デフォルトは sqllib/security/auditdata (Windows ではinstance
path\instance\security\auditdata ) です。 このパラメーターは、データベース・レベルの監査を含め、インスタンス内のすべての監査に影響を与えます。 これは相対パスではなく、絶対パスでなければなりません。 インスタンス所有者は、このディレクトリーに対する書き込み権限を持っている必要があります。 Windows では、コマンドを監査する必要がある場合、ローカル・インスタンス・コマンド (例えば、 db2start、 db2audit、および db2 update dbm cfg) を発行するユーザーは、このディレクトリーに対する書き込み権限も持っている必要があります。 複数メンバー・データベース環境では、このディレクトリーとして NFS 共有ディレクトリーを指定できますが、そうする必要があるわけではありません。 非共有ディレクトリーを指定した場合、各メンバーが固有のディスクに書き込むことになるため、パフォーマンスが向上します。 パスの最大長は、UNIX または Linux® の場合は 971 バイト、Windows オペレーティング・システムの場合は 208 バイトです。パスを "" と指定した場合、パスはデフォルトに更新されます。 db2audit describe には設定されるパスが表示されず、デフォルト・パスが使用されます。 なお、シェルによって引用符が解釈されないようにするため、通常、引用符をエスケープする必要があります。例えば次のようにします。
db2audit configure datapath \"\"
データ・パスは必須です。 複数メンバー・データベース環境では、各メンバーで同じデータ・パスが使用されます。 特定のメンバーに対して固有のデータ・パスのセットを指定することはできません。ただし、データ・パス名にデータベース・メンバー式を含める場合はこれが可能です。 その使用によって、処理結果のパス名が各メンバーごとに異なるように、メンバー番号をストレージ・パスにおいて反映することができます。 データベース・メンバー式については、
自動ストレージ・データベース
を参照してください。
- archivepath audit-archive-path
- これは、アーカイブ・オプション用および抽出オプション用のデフォルト・ディレクトリーです。 複数メンバー・データベース環境では、すべてのメンバーからアクセス可能な NFS 共有ディレクトリーをこのディレクトリーとして指定することをお勧めします。 デフォルトは sqllib/security/auditdata (Windows ではsqllib\instance\security\auditdata ) です。 これは相対パスではなく、絶対パスでなければなりません。 インスタンス所有者は、このディレクトリーに対する書き込み権限を持っている必要があります。 パスの最大長は、UNIX または Linux の場合は 971 バイト、Windows オペレーティング・システムの場合は 208 バイトです。
アーカイブ・パスは必須です。 アーカイブ・パスにはデータベース・メンバー式は使用できません。
- describe
- このパラメーターは、現在のインスタンス・レベルの監査の構成情報と状況を標準出力に表示します。以下の項目が表示されます。
- 監査がアクティブかどうか。
- 各カテゴリーの状況。
- エラー・タイプ (エラーに対する SQLCA が戻されるかどうかという形式)。
- データ・パスとアーカイブ・パス。
以下に、describe 出力の例を示します。
Db2 Audit Settings: Audit active: "FALSE " Log audit events: "SUCCESS" Log checking events: "FAILURE" Log object maintenance events: "BOTH" Log security maintenance events: "BOTH " Log system administrator events: "NONE" Log validate events: "FAILURE" Log context events: "NONE" Return SQLCA on audit error: "TRUE " Audit Data Path: "/auditdata" Audit Archive Path: "/auditarchive" AUD0000I Operation succeeded.
- extract
- このパラメーターを使用すると、監査レコードを監査ログから指定された宛先に移動することができます。 監査ログは、データベースのコード・ページで作成されます。 抽出の実行時に、すべてのフィールドは現在のアプリケーション・コード・ページに変換されます。抽出時に使用できるオプションは、以下のとおりです。
- file 出力ファイル
- 抽出された監査レコードが output-file に格納されます。 ディレクトリーが指定されていない場合、output-file は現行作業ディレクトリーに書き込まれます。 ファイルが既に存在する場合、出力はそれに付加されます。 ファイル名が指定されていない場合、レコードは監査構成 ファイルに指定されたアーカイブパスのdb2audit.outにファイルに書き込まれます。
- delasc
- 抽出された監査レコードは、区切り ASCII フォーマットになります。
これは、Db2 データベースのリレーショナル表にロードするのに適しています。 出力は区分ごとに 1 つずつ独立したファイルに置かれます。 さらに、監査データに含まれるすべての LOB を保持するために、ファイルauditlobs も作成されます。 ファイル名は次のとおりです。
- audit.del
- checking.del
- objmaint.del
- secmaint.del
- sysadmin.del
- validate.del
- context.del
- execute.del
- auditlobs
ファイルが既に存在する場合、出力はそれに付加されます。 context カテゴリーまたは execute カテゴリーが抽出されると、auditlobs ファイルが作成されます。 LOBロケーション指定子は、.delファイルのLOBSを参照するためにauditlobsファイルに含まれています。
- delimiter load-delimiter
- 監査ログからの抽出時に、デフォルトの監査文字ストリング区切り (二重引用符 ") をオーバーライドできます。 監査レコード保持表にロードする準備として使われる新しい区切り文字が後に続きくように、delimiterを使ってください。 新しいロード区切り文字は、単一文字 (! など) に設置できます。 または16進数を表す4字も文字列 (
0x3b
など)。
- to delasc-path
- 区切りファイルの書き込み場所のパスを指定できます。 これが指定されない場合、監査構成ファイル内の監査アーカイブ・パス・オプションで指定されたディレクトリーにファイルが書き込まれます。
- syslog
- さまざまなタイプのシステムからのログ・データを中央リポジトリーに統合します。 このオプションは、Windows 環境ではサポートされません。
- facility.priority
- syslog デーモン (syslogd) がメッセージをログに記録するために必要な必須パラメーターであり、定義済み syslog 値のうちのいずれかでなければなりません。 facility.priority ペアおよび構成の事前定義値について詳しくは、『システム・イベント・ログ (syslog) の構成』を参照してください。syslogdと構成ファイル(/etc/syslog.conf)を確認するのはユーザーの責任です。
- syslogd が正常に動作している。
- db2audit コマンドに適用される (/etc/syslog.conf) のセレクターを検索します。
- 上記セレクターに一致する、extract syslog のための適切な facility.priority ペアを選択する。
- syslog.conf ファイル内の db2audit extract syslog の宛先を確認します。
- tag word
- 現行バッチ内のすべてのメッセージでタグとして使用される語を指定するためのオプション・パラメーター。 指定した語は、syslog バッチ内のすべての db2audit メッセージの先頭に追加されます。 この語をオペレーティング・システムの syslog ファイルで検索することにより、syslog メッセージのこのバッチ全体を一意的に識別できます。 以下の命名規則が適用されます。
- 固有で単一の語でなければなりません。
- 最大長が 16 を超えることはできません。
- word は、文字 (a から z または A から Z)、数字 (0 から 9)、下線 (_)、およびダッシュ (-) の組み合わせ (他のすべての文字を除く) にすることができます。
- splitrecordsize byte
- db2audit レコードが長すぎる場合に、オペレーティング・システムの syslog に送られるログ・メッセージの最大長を指定するためのオプション・パラメーター。 指定した値よりも長いメッセージは分割されます。 byte 値には、次の規則があります。
- 値は 32 から 8192 までの範囲の整数値でなければなりません。
'corr' + time + db2audit process ID + correlator sequence number, associated with dash '-', then followed by ":#" and a sequence number within that correlation (#n).
- category
- 監査イベントのうち指定されたカテゴリーの監査レコードが抽出されます。 これが指定されていない場合、すべてのカテゴリーが抽出対象になります。
- status
- 指定された状況の監査レコードが抽出されます。 これが指定されていない場合、すべてレコードが抽出対象になります。
- path
- アーカイブ監査ログの場所を示すパス。 これが指定されない場合、監査構成の中のアーカイブ・パスが使用されます。 ファイル名に絶対パスが含まれる場合には、このパスは使用されません。
- files
- 抽出対象の監査ログ・ファイルのリスト。 これには、単一のファイル、または複数ファイルからなるリストを指定できます。 これらのファイルは、抽出時に変更されません。 完全修飾ファイル名がまだ完全修飾されない場合は、ファイル名がpathと結合され、完全修飾ファイル名が取得されます。 リストでは、標準的なシェル・ワイルドカードを使って複数のファイルを指定できます。
- flush
- このパラメーターを使用すると、保留中の監査レコードが強制的に監査ログに書き込まれます。 さらに、監査機能がエラー状態になっている場合には、監査状態が「ログ記録不可能」から「ログ記録可能」状態にリセットされます。
- archive
- このパラメーターは、個々のデータベース用またはインスタンス用の現在の監査ログを、アーカイブ用および抽出用の新しい場所に移動します。 ファイル名には現在のタイム・スタンプが付加されます。 監査ログに現在書き込まれている途中のすべてのレコードは、レコード全体が分割されないように、ログのアーカイブ前に完了します。 アーカイブ処理中に作成されたすべてのレコードは、アーカイブが完了した後、アーカイブ・ログではなく現在の監査ログに書き込まれます。アーカイブ時に使用できるオプションは、以下のとおりです。
- database database-name
- 監査ログをアーカイブする対象のデータベースの名前。 データベース名が提供されない場合、インスタンス・レベルの監査ログがアーカイブされます。
- member
- 現在のメンバーに対してのみアーカイブ・コマンドを実行すること、および現在のメンバーはモニター・エレメント node_number によって表されることを指示します。注: 現在の member-number の使用は、 Db2 pureScale 環境およびパーティション・データベース環境ではオプションです。
db2audit archive .... node
コマンドが渡され、 DB2NODE が設定されている場合は、ノード値が使用されます。 DB2NODE が設定されていなければ、0 が使用されます。- メンバー番号
- 現在どのメンバーに実行されるかをdb2audit実行可能ファイルに通知します。注: 現在の member-number の使用は、 Db2 pureScale 環境およびパーティション・データベース環境ではオプションです。
db2audit archive .... node X
コマンドが渡されると、 DB2NODE が設定されているかどうかに関係なく、ノード値 (X) が使用されます。
- to archive-path
- アーカイブ監査ログの作成場所となるディレクトリー。 このディレクトリーは既に存在しなければならず、インスタンス所有者はこのディレクトリーに対する作成権限を持っていなければなりません。 これが提供されない場合、監査構成の中のアーカイブ・パスが使用されます。
作成されるファイル名は、次のような形式になります。- インスタンス・ログのdb2audit.instance.log.member_number[.YYYYMMDDHHMMSS]
- db2audit.db.dbname.log.member_number[.YYYYMMDDHHMMSS] (データベース・ログの場合)
ここで YYYY は年、MM は月、DD は日、HH は時間、MM は分、SS は秒です。 時刻は現地時間になります。 インスタンス監査ログにはデータベース名の部分がありません。 単一メンバー・データベース環境の場合、メンバー番号は 0 になります。 ファイルが既に存在する場合には、それに付加されます。
このタイム・スタンプは、ログ内の最後のレコードを 100% 正確に表すわけではありません。 このタイム・スタンプは、アーカイブ・コマンドが実行された時点を表します。 ログ・ファイルが移動される前に、ログ・ファイルに現在書き込まれている途中の項目が完了しなければなりません。 これらの項目のタイム・スタンプは、ファイル名のタイム・スタンプより後の時刻を表す可能性があります。
member オプションが指定されない場合、すべてのメンバーの監査ログがアーカイブされます。 この場合、データベース・サーバーが開始済みでなければなりません。 データベース・サーバーが開始されない場合は、各メンバーでアーカイブを実行しなければなりません。また、どのメンバーでarchiveを実行するかを示すためにmember オプションを指定しなければなりません (AUD0029)。
archiveこのオプションは、アーカイブが実行された各メンバーからのファイルの結果と名前を出力します。
- start
- このパラメーターにより、監査機能は、インスタンスのみのdb2audit.cfgファイルの内容に基づいてイベントの監査を開始します。 複数メンバー Db2 データベース・インスタンスの場合、この節を指定すると、すべてのデータベース・メンバーでインスタンス・レベルおよびクライアント・レベルのアクティビティーに対する監査が開始されます。 audit カテゴリーのイベントが監査対象として指定された場合、監査機能の開始時に監査レコードがログに記録されます。 これは、(AUDIT DDL ステートメントを介して制御される) データベース・レベルの監査には影響を与えません。
- stop
- このパラメーターを使用すると、インスタンスのみに対するイベント監査が監査機能によって停止されます。 複数メンバー Db2 データベース・インスタンスの場合、この節を指定すると、すべてのデータベース・メンバーでインスタンス・レベルおよびクライアント・レベルのアクティビティーに対する監査が停止されます。 監査対象としてaudit カテゴリーのイベントが指定された場合、監査機能が停止すると監査レコードがログに記録されます。 これは、(AUDIT DDL ステートメントを介して制御される) データベース・レベルの監査には影響を与えません。
- ?
- このパラメーターは、db2audit コマンドのヘルプ情報を表示します。
例
rm /auditdelasc/*.del
db2audit flush
db2audit archive database mydb to /auditarchive
(次の手順で使用されるファイルが示されます)db2audit extract delasc to /auditdelasc from files /auditarchive
/db2audit.db.mydb.log.*.20070514102856
.del ファイルを Db2 表にロードします。LOAD FROM /auditdelsac/execute.del OF DEL MODIFIED BY DELPRIORITYCHAR LOBSINFILE INSERT INTO EXECUTE
使用上の注意
- データベース・レベルの監査は、AUDIT ステートメントによって制御されます。 追加情報については、以下の 「関連リンク」 セクションを参照してください。
- インスタンス・レベルの監査機能は、明示的に停止および開始する必要があります。 開始時に監査機能は、既存の監査構成情報を使用します。 監査機能は Db2 データベース・サーバーとは独立した機能なので、インスタンスが停止した場合でもアクティブのままです。 実際、インスタンスが停止されるとき、 監査レコードが監査ログに生成される可能性があります。
- 監査のさまざまなユーティリティーを使用する前に、db2audit start コマンドを発行することによって、監査機能が確実にオンであるようにしてください。
- 生成される監査レコードにはさまざまな区分があります。 監査するために使用可能なイベントの区分に関する以下の記述では、各区分の名前に続いて、区分タイプの識別に使用される 1 つの単語のキーワードがあることに注意してください。 監査のために使用可能なイベントの区分は次のようになります。
- 監査 (audit)。 監査設定が変更されたとき、または監査ログがアクセスされたときにレコードを生成します。
- 許可検査 (checking)。 Db2 データベース・オブジェクトまたは関数へのアクセスまたは操作の試行の許可検査中にレコードを生成します。
- オブジェクト保守 (objmaint)。 データ・オブジェクトの作成時またはドロップ時にレコードを生成します。
- 安全保守 (secmaint)。オブジェクト権限、データベース権限、DBADM 権限の付与または取り消し時にレコードを生成します。 レコードは、データベース・マネージャー安全構成パラメーター sysadm_group、sysctrl_group、sysmaint_group が変更されたときにも生成されます。
- システム管理 (sysadmin)。 SYSADM、SYSMAINT、SYSCTRL 権限を必要とする操作が実行されると、レコードが生成されます。
- ユーザー検証 (validate)。 ユーザーの認証時またはシステム安全情報の取得時にレコードを生成します。
- 操作コンテキスト (context)。 インスタンス操作の実行時に操作コンテキストを示すレコードを生成します。 この区分を使用すると、監査ログ・ファイルのより良い変換処理を可能にします。 ログのイベント相関関係子フィールドを同時に使用することで、 イベントのグループを 1 つのデータベース操作に戻って関連付けることができます。
- 監査の対象として指定できるのは、失敗、成功、その両方、または「どちらも監査しない」です。
追加情報については、以下の 「関連リンク」 セクションを参照してください。
- インスタンスに対する 1 つの操作により、複数のレコードが生成されることがあります。 生成されて監査ログに移されるレコードの実際の数は、監査機能の構成での指定内容に基づいて記録されるイベントのカテゴリーの数によって異なります。 さらに、成功、失敗、またはその両方を監査するかどうかによっても異なります。 このため、監査対象のイベントの選択は重要です。
- 監査ログをクリーンアップおよび/または表示するには、定期的にarchive実行してから、アーカイブファイルでextractを実行して有用なものを保存します。 その後、ファイル・システムの標準的な削除コマンドを使って監査ログを削除できます。