SQL ステートメントを監査するための EXECUTE 区分

EXECUTE カテゴリーを使用すると、ユーザーが発行した SQL ステートメントを正確にトラッキングできます。 バージョン 9.5 以前のリリースでは、CONTEXT 区分を使用してこの情報を探さなければなりませんでした。

包括的なセキュリティー・ポリシーの一環として、ある企業が、一定の年数までさかのぼってデータベース内の特定の表に対する特定の要求の影響を分析できるような機能を必要とすることがあります。 これを行うために、企業は、選択した任意の時点でのデータベースを再構成できるように、週単位のバックアップとそれに関連するログ・ファイルをアーカイブするポリシーを確立する必要があります。 さらに、データベースに対するすべての要求についての十分なデータベース監査情報を収集する必要があります。これにより、将来の任意の時点で、該当するリストアされたデータベースに対する任意の要求を再生して分析できるようになります。 この要件は、静的 SQL ステートメントと動的 SQL ステートメントの両方を扱うことができるものです。

この EXECUTE 区分は、SQL ステートメントのテキストに加えて、コンパイル環境や、後でステートメントを再現するのに必要なその他の値もキャプチャーします。 例えば、ステートメントを再現すると、SELECT ステートメントがどの行を戻したのかを正確に知ることができます。 ステートメントを再実行するためには、まず、データベース表をステートメント発行時の状態にリストアする必要があります。

EXECUTE 区分を使用して監査を行う場合は、静的 SQL と動的 SQL の両方のステートメント・テキストが記録され、入力パラメーター・マーカーやホスト変数も記録されます。 入力値を使用するかどうかにかかわらず、EXECUTE 区分を構成して監査できます。
注: グローバル変数は監査されません。
EXECUTE イベントの監査は、イベントの完了時に行われます (SELECT ステートメントの場合は、カーソルのクローズ時に行われます)。 イベント完了時の状況も保管されます。 EXECUTE イベントは完了時に監査されるため、長時間にわたって実行される照会は、すぐには監査ログに現れません。
注: ステートメントの準備は、実行の一部とは見なされません。 ほとんどの許可検査は準備の際に実行されます (例えば SELECT 特権)。 つまり、許可エラーが原因となって準備の途中で失敗するステートメントの場合は、EXECUTE イベントは生成されません。

特定の EXECUTE レコードごとに、「Statement Value Index」、「Statement Value Type」、および「Statement Value Data」フィールドが繰り返される場合があります。 抽出によって生成されるレポート形式の場合は、各レコードに複数の値がリストされます。 区切りファイル形式の場合は、複数の行が使用されます。 最初の行には、STATEMENT のイベント・タイプが示され、値はありません。 続く行には、SQL ステートメントに関連付けられているデータ値ごとに 1 行ずつ、DATA のイベント・タイプが示されます。 STATEMENT 行と DATA 行は、イベント相関関係子とアプリケーション ID のフィールドを使用してリンクさせることができます。 「Statement Text」、「Statement Isolation Level」、および「Compilation Environment Description」の列は、DATA イベントにはありません。

監査されるステートメント・テキストと入力データ値は、ディスクに保管される際、データベース・コード・ページに変換されます (監査されたフィールドはすべてデータベース・コード・ページで保管されます)。 入力データのコード・ページとデータベース・コード・ページに互換性がなかった場合は、エラーは戻されず、変換されないままのデータが代わりにログとして記録されます。 各データベースは独自の監査ログを持っているため、異なるコード・ページを持つデータベースがあっても、問題は起こりません。

ROLLBACK および COMMIT は、アプリケーションによって実行されたときに監査されます。また、BIND などの別のコマンドの一部として暗黙的に発行されたときも監査されます。

監査されている表へのアクセスがあったために EXECUTE イベントが監査された後、作業単位内で他にどのステートメントが実行されるかに影響を与えるステートメントがすべて監査されます。 COMMIT、ROLLBACK、ROLLBACK TO SAVEPOINT、および SAVEPOINT がこのようなステートメントに該当します。

「Savepoint ID」フィールド

どのステートメントが ROLLBACK TO SAVEPOINT ステートメントの影響を受けたかは、「Savepoint ID」フィールドを使用してトラッキングできます。 通常の DML ステートメント (SELECT、INSERT など) では、現行のセーブポイント ID が監査されています。 しかし、ROLLBACK TO SAVEPOINT ステートメントの場合は、代わりにロールバック先のセーブポイント ID が監査されます。 したがって、次の例が示すように、ロールバック先の ID と同じかそれよりも大きなセーブポイント ID を持っているステートメントは、すべてロールバックされます。 表は、ステートメントの実行の順序を示しています。2 以上のセーブポイント ID を持つイベントはすべてロールバックされます。 値 3 (最初の INSERT ステートメントより) だけが、表 T1 に挿入されます。
表 1. ROLLBACK TO SAVEPOINT ステートメントの影響を示すためのステートメントのシーケンス
ステートメント Savepoint ID
INSERT INTO T1 VALUES (3) 1
SAVEPOINT A 2
INSERT INTO T1 VALUES (5) 2
SAVEPOINT B 3
INSERT INTO T1 VALUES (6) 3
ROLLBACK TO SAVEPOINT A 2
COMMIT  

WITH DATA オプション

WITH DATA オプションが指定されている場合は、すべての入力値が監査されるわけではありません。 LOB、LONG、XML、および構造化タイプのパラメーターは、NULL として示されます。

日付、時刻、およびタイム・スタンプ・フィールドは ISO フォーマットで記録されます。

あるポリシーで WITH DATA が指定されていて、SQL ステートメントの実行に関係するオブジェクトに関連付けられている別のポリシーで WITHOUT DATA が指定されている場合は、WITH DATA が優先され、その特定のステートメントに関してデータが監査されます。 例えば、ユーザーに関連付けられている監査ポリシーでは WITHOUT DATA が指定されていて、表に関連付けられているポリシーでは WITH DATA が指定されている場合、そのユーザーがその表にアクセスするときは、ステートメントに使用される入力データが監査されます。

位置指定更新ステートメントや位置指定削除ステートメントでどの行が変更されたかは、判別できません。 ログに記録されるのは基礎となる SELECT ステートメントの実行だけで、個々の FETCH は記録されません。 ステートメントが発行されたときにカーソルがどの行にあったかを EXECUTE レコードから判別することは不可能です。 後でステートメントを再現する際に唯一可能なのは、SELECT ステートメントを発行して、どの範囲の行が影響を受けている可能性があるかを確認することだけです。

過去のアクティビティーの再現の例

この例では、ある企業が、自社の包括的なセキュリティー・ポリシーの一環として、7 年前までさかのぼってデータベース内の特定の表に対する特定の要求の影響を分析できるようにしておく必要があるとします。 これを行うために、この企業は、選択した任意の時点のデータベースを再構成できるような、週単位のバックアップをアーカイブするポリシーとそれに関連付けるログ・ファイルを設けます。 関連する、リストアされたデータベースに対するあらゆる要求を再現し、分析できるようにしておくために、データベース監査には、データベースに対して行われたすべての要求に関する十分な情報をキャプチャーさせる必要があります。 この要件は、静的 SQL ステートメントと動的 SQL ステートメントの両方を含みます。

この例は、SQL ステートメントの発行時に実施される必要のある監査ポリシーと、監査ログをアーカイブし、後でそれを抽出し、分析するためのステップを示しています。

  1. EXECUTE 区分を監査する監査ポリシーを作成して、このポリシーをデータベースに適用します。
    CREATE AUDIT POLICY STATEMENTS CATEGORIES EXECUTE WITH DATA 
   STATUS BOTH ERROR TYPE AUDIT
COMMIT

AUDIT DATABASE USING POLICY STATEMENTS
COMMIT
  2. 定期的に監査ログをアーカイブし、アーカイブ・コピーを作成します。

    一定の間隔 (ログに記録されるデータの量に応じて、週に一度、一日に一度など) で、セキュリティー管理者、または SYSPROC.AUDIT_ARCHIVE ストアード・プロシージャーの EXECUTE 特権をセキュリティー管理者によって付与されたユーザーによって、以下のステートメントが実行される必要があります。 これらのアーカイブされたファイルは、どれほどの期間でも必要なだけ保持しておくことができます。 2 つの入力パラメーターを使用して、AUDIT_ARCHIVE プロシージャーが呼び出されます。1 つはアーカイブ・ディレクトリーのパス、もう 1 つはアーカイブをすべてのメンバーで実行することを示す -2 です。

    CALL SYSPROC.AUDIT_ARCHIVE( '/auditarchive', -2 )
  3. セキュリティー管理者、または SYSPROC.AUDIT_LIST_LOGS 表関数の EXECUTE 特権をセキュリティー管理者から付与されたユーザーは、AUDIT_LIST_LOGS を使用し、2006 年 4 月以降の入手可能な監査ログをすべて調べて、どのログに必要なデータが含まれている可能性があるかを判別します。
    SELECT FILE FROM TABLE(SYSPROC.AUDIT_LIST_LOGS('/auditarchive'))
   AS T WHERE FILE LIKE 'db2audit.dbname.log.0.200604%'
FILE
--------------------------------------
...
db2audit.dbname.log.0.20060418235612
db2audit.dbname.log.0.20060419234937
db2audit.dbname.log.0.20060420235128
  4. この出力から、セキュリティー管理者は、必要なログが 1 つのファイル db2audit.dbname.log.20060419234937 に含まれていることを観察します。 タイム・スタンプは、このファイルが、監査員が確認したいと思っている日の終わりにアーカイブされたファイルであることを示しています。

    セキュリティー管理者、または SYSPROC.AUDIT_DELIM_EXTRACT ストアード・プロシージャーに対する EXECUTE 特権を付与されているユーザーは、このファイル名を AUDIT_DELIM_EXTRACT への入力として使用して、監査データを区切り文字で区切られたファイルに抽出します。 これらのファイル内の監査データを Db2® データベース表にロードして、監査員が関心のある特定のステートメントを見つけるために分析することができます。 監査員が調べているのは 1 つの SQL ステートメントだけであったとしても、そのステートメントに何らかの影響を与えるステートメントがある場合は、その作業単位内の複数のステートメントを調べることが必要になることもあります。

  5. ステートメントを再現するためには、セキュリティー管理者は以下のアクションを行う必要があります。
    • 発行する抽出ステートメントを監査レコードから判別する。
    • ステートメントを発行したユーザーを監査レコードから判別する。
    • ユーザーがステートメントを発行したときのユーザーの許可 (すべての LBAC 保護を含む) を正確に再作成する。
    • 監査レコードのコンパイル環境に関する列を SET COMPILATION ENVIRONMENT ステートメントに組み合わせて使用し、コンパイル環境を再現する。
    • ステートメントが発行されたときの正確な状態に、データベースをリストアする。
    実動システムに支障が出ないようにするため、データベースのリストアやステートメントの再現は、2 次データベース・システム上で行います。 ステートメントを発行したユーザーとして実行中のセキュリティー管理者は、「Statement Value Data」エレメントに指定された任意の入力変数をもとにステートメント・テキストから検出されたステートメントを再発行できます。