AUDIT ステートメント
AUDIT ステートメントは、現行サーバーの特定のデータベースまたはデータベース・オブジェクトで使用する監査ポリシーを決定します。 オブジェクトが使用されている場合は常に、そのポリシーに従って監査されます。
呼び出し
このステートメントは、アプリケーション・プログラムに組み込むか、あるいは対話式に発行することができます。 これは、DYNAMICRULES の実行動作がパッケージに効力を持つ場合にのみ、動的に準備できる実行可能ステートメントです (SQLSTATE 42509)。
許可
このステートメントの許可 ID が持つ特権には、SECADM 権限が含まれている必要があります。
構文
説明
- ACCESSCTRL、CREATE_SECURE_OBJECT、DATAACCESS、DBADM、SECADM、SQLADM、SYSADM、SYSCTRL、SYSMAINT、SYSMON、または WLMADM
- 指定された権限と監査ポリシーを関連付けること、またはそれから除去することを指定します。 (たとえイベントでその権限を必要としない場合でも) 指定された権限の付与されたユーザーによって開始される監査可能イベントはすべて、関連付けられている監査ポリシーに従って監査されます。
- データベース
- 監査ポリシーを現行サーバーのデータベースと関連付けること、またはそこから除去することを指定します。 データベース内で発生する監査可能イベントはすべて、関連付けられている監査ポリシーに従って監査されます。
- TABLE テーブル名
- 監査ポリシーを table-name と関連付けること、またはそれから除去することを指定します。 table-name は、現行のサーバーに存在する表、マテリアライズ照会表 (MQT)、またはニックネームを識別するものでなければなりません (SQLSTATE 42704)。 これに、ビュー、カタログ表、作成済み一時表、宣言済み一時表 (SQLSTATE 42995)、または型付き表 (SQLSTATE 42997) を指定することはできません。 表にアクセスされたときに生成されるのは EXECUTE カテゴリー監査イベントだけです (データを伴う場合と伴わない場合がある)。これは、ポリシーが他のカテゴリーを監査することを指示している場合でも同じです。
- トラステッド・コンテキスト context-name
- 監査ポリシーを context-name と関連付けること、またはそれから除去することを指定します。 context-name は現行のサーバーに存在するトラステッド・コンテキストを識別するものでなければなりません (SQLSTATE 42704)。 トラステッド・コンテキスト context-name によって定義されるトラステッド接続内で発生する監査可能イベントはすべて、関連付けられている監査ポリシーに従って監査されます。
- USER
- 許可 ID authorization-name を持つユーザーと監査ポリシーを関連付けること、またはそれから除去することを指定します。 authorization-name によって開始される監査可能イベントはすべて、関連付けられている監査ポリシーに従って監査されます。
- GROUP
- 許可 ID authorization-name を持つグループと監査ポリシーを関連付けること、またはそれから除去することを指定します。 authorization-name のメンバーであるユーザーによって開始される監査可能イベントはすべて、関連付けられている監査ポリシーに従って監査されます。 グループのユーザー・メンバーシップを判別できない場合、ポリシーはそのユーザーに適用されません。
- ROLE
- 許可 ID authorization-name を持つロールと監査ポリシーを関連付けること、またはそれから除去することを指定します。 authorization-name は現行のサーバーに存在するロールを識別するものでなければなりません (SQLSTATE 42704)。 authorization-name のメンバーであるユーザーによって開始される監査可能イベントはすべて、関連付けられている監査ポリシーに従って監査されます。 他のロールまたはグループを介した間接的なロール・メンバーシップも有効です。
- USING、REMOVE、または REPLACE
- 指定されたオブジェクトで監査ポリシーを使用、除去、または置換するかどうかを指定します。
- USING
- 指定されたオブジェクトで監査ポリシーを使用することを指定します。 このオブジェクトについて定義されている監査ポリシーが既に存在していてはなりません (SQLSTATE 5U041)。 監査ポリシーが既に存在する場合はそれを除去するかまたは置換する必要があります。
- 除去
- 指定されたオブジェクトから監査ポリシーを除去することを指定します。 監査ポリシーに従ったオブジェクト使用の監査は行われなくなります。 監査ポリシーからオブジェクトから除去されると、カタログから関連付けが削除されます。
- REPLACE
- 指定されたオブジェクトの既存の監査ポリシーを置換することを指定します。 これは REMOVE オプションと USING オプションの両方を 1 つのステップにまとめたもので、これを使用した場合、指定されたオブジェクトに監査ポリシーが未適用となる期間がないことが保証されます。 指定されたオブジェクトでポリシーが使用されていなかった場合、REPLACE は USING と同じということになります。
- POLICY ポリシー名
- 監査設定を決定するために使用する監査ポリシーを指定します。 policy-name は、現行サーバーの既存の監査ポリシーを識別するものでなければなりません (SQLSTATE 42704)。
ルール
- AUDIT 排他 SQL ステートメントの後は、COMMIT または ROLLBACK ステートメントでなければなりません (SQLSTATE 5U021)。 AUDIT 排他 SQL ステートメントは次のとおりです。
- AUDIT
- CREATE AUDIT POLICY、ALTER AUDIT POLICY、または DROP (AUDIT POLICY)
- DROP (監査ポリシーと関連付けられる場合は ROLE または TRUSTED CONTEXT)
- AUDIT 排他 SQL ステートメントをグローバル・トランザクション (例えば XA トランザクション) 内で発行することはできません (SQLSTATE 51041)。
- オブジェクトと関連付けることのできるポリシーは 1 つだけです (SQLSTATE 5U042)。
注
- 監査される表に従属するパッケージは、その表の監査ポリシーが追加または除去されると、無効になります。
- カタログに変更が書き込まれますが、COMMIT ステートメントが実行されるまでは有効になりません。
- 変更は、監査ポリシーが適用されるオブジェクトを参照する次の作業単位が適用されるまでは有効になりません。 例えば、監査ポリシーがデータベースで使用されている場合、現行の作業単位は COMMIT または ROLLBACK ステートメントが完了するまではポリシーに従って監査を開始しません。
- 監査ポリシーと関連付けられている表にビューがアクセスする場合、そのビューは基礎表のポリシーに従って監査されます。
- 監査ポリシーが表に適用される場合、その監査ポリシーはその表に基づくマテリアライズ照会表 (MQT) には適用されません。 監査ポリシーを表と関連付ける場合はそのポリシーをその表に基づく MQT にも関連付けることをお勧めします。 SQL ステートメントが基本表を参照していても、コンパイラーは MQT を自動的に使用する可能性があります。ただし、基本表で使用されている監査ポリシーは引き続き有効です。
- トラステッド・コンテキスト内でユーザーの切り替え操作が実行される際、監査ポリシーはすべて新規ユーザーに応じて再評価され、古いユーザーのポリシーは現行セッションでは使用されません。 これは特に、ユーザー、ユーザーのグループまたはロールのメンバーシップ、およびユーザーの権限と直接関連付けられている監査ポリシーに当てはまります。 例えば、切り替え前のユーザーが監査対象のロールのメンバーだったために現行セッションが監査されたとします。 切り替え先のユーザーがそのロールのメンバーではない場合、そのポリシーはセッションに適用されなくなります。
- SET SESSION USER ステートメントが実行される際、元のユーザー (およびそのユーザーのグループとロールのメンバーシップと権限) と関連付けられている監査ポリシーは、SET SESSION USER ステートメントで指定されたユーザーと関連付けられているポリシーに結合されます。 元のユーザーと関連付けられている監査ポリシーは引き続き有効となり、SET SESSION USER ステートメントで指定されたユーザーのポリシーも同じように有効となります。 1 つのセッション内で複数の SET SESSION USER ステートメントが発行される場合、元のユーザーおよび現行ユーザーと関連付けられている監査ポリシーだけが考慮されます。
- 監査ポリシーが関連付けられているオブジェクトがドロップされると、監査ポリシーとの関連付けはカタログから除去され、存在しなくなります。 その後いつかそのオブジェクトが再作成される場合、そのオブジェクトがドロップされた時点で関連付けられていたポリシーによる監査は、そのオブジェクトに対して実行されません。
- 複数のオブジェクトを指定すると、ポリシーがそれぞれに個別に適用されます。 ポリシーはステートメント内のオブジェクトの交差ではなく、それぞれのオブジェクトに適用されます。 「AND」タイプ構成を使用して複数のポリシーを結合することはできません。
例
- 例 1: 監査ポリシー DBAUDPRF を使用して、現行のサーバーのデータベースの監査設定を決定します。
AUDIT DATABASE USING POLICY DBAUDPRF - 例 2: EMPLOYEE 表から監査ポリシーを除去します。
AUDIT TABLE EMPLOYEE REMOVE POLICY - 例 3: 監査ポリシー POWERUSERS を使用して、権限 SYSADM、DBADM、SECADM、およびグループ DBAS の監査設定を決定します。
AUDIT SYSADM, DBADM, SECADM, GROUP DBAS USING POLICY POWERUSERS - 例 4: ロールの監査ポリシー TELLER を新規ポリシー TELLERPRF で置き換えます。
AUDIT ROLE TELLER REPLACE POLICY TELLERPRF - 例 5: 複数のオブジェクトを指定します。
前述のステートメントは、分離した以下のステートメントと同等です。AUDIT TABLE EMPLOYEE, ROLE TELLER USING POLICY TABLEAUDITAUDIT TABLE EMPLOYEE USING POLICY TABLEAUDIT AUDIT ROLE TELLER USING POLICY TABLEAUDIT