監査ポリシー

セキュリティー管理者は、監査ポリシーを使用することによって、必要なデータやオブジェクトに関する情報だけを収集するように監査機能を構成できます。

セキュリティー管理者は、監査ポリシーを作成して、個々のデータベース内で何を監査の対象にするかを制御することができます。監査ポリシーを関連付けることができるオブジェクトには、以下のものがあります。

データベース全体
データベース内で発生する監査可能イベントすべてが、監査ポリシーに従って監査の対象となります。
表
表 (非型付き)、MQT (マテリアライズ照会表)、またはニックネームへのデータ操作言語 (DML) アクセスおよび XQUERY アクセスは、すべて監査の対象となります。表がアクセス中になっているときは、ポリシーが他にも監査の対象となる区分を指示している場合でも、EXECUTE 区分の監査イベント (データを伴う場合と伴わない場合があります) のみが生成されます。
トラステッド・コンテキスト
特定のトラステッド・コンテキストで定義されたトラステッド接続内で発生する監査可能イベントすべてが、監査ポリシーに従って監査の対象となります。
ユーザー、グループ、またはロールを示す許可 ID
指定されたユーザーによって開始される監査可能イベントすべてが、監査ポリシーに従って監査の対象となります。

指定されたグループやロールに属しているユーザーが開始する監査可能イベントは、すべて監査ポリシーに従って監査の対象となります。他のロールやグループを介する場合など、間接的にロールに属している場合も、監査の対象になります。

同様なデータのキャプチャーは、グループのワークロードを定義してアクティビティーの詳細をキャプチャーすることにより、Work Load Management イベント・モニターでも行うことができます。なお、ワークロードのマッピングには、許可 ID だけではなく、属性も関係する場合があるので注意が必要です。このことが原因となって、監査の際に期待した細分度が得られなかったり、それらの他の属性が変更された場合には接続が別の (おそらく、モニターされていない) ワークロードにマップされてしまったりすることがあります。監査用のソリューションを使用するなら、ユーザー、グループ、またはロールの監査を確実に行うことができます。
権限 (SYSADM、SECADM、DBADM、SQLADM、WLMADM、ACCESSCTRL、DATAACCESS、SYSCTRL、SYSMAINT、SYSMON)
指定された権限を持つユーザーによって開始される監査可能イベントすべてが、そのイベントにその権限が必要であるかどうかにかかわりなく、監査ポリシーに従って監査の対象となります。

セキュリティー管理者は、複数の監査ポリシーを作成できます。例えば、会社は、機密データを監査するためのポリシーと、DBADM 権限を持つユーザーのアクティビティーを監査するためのポリシーを必要とするかもしれません。 1 つのステートメントで複数の監査ポリシーが有効になれば、それぞれの監査ポリシーで監査が必要とされるイベントすべてを (1 回の監査だけで) 監査することができます。例えば、データベースの監査ポリシーで特定の表における成功した EXECUTE イベントの監査が必要とされ、ユーザーの監査ポリシーで同じ表における EXECUTE イベントの失敗の監査が必要とされる場合は、その表へのアクセスの試行が成功した場合と失敗した場合の両方の監査が行われます。

特定のオブジェクトごとに有効にできる監査ポリシーは、1 つだけです。例えば、同じ表に複数の監査ポリシーを同時に関連付けることはできません。

監査ポリシーは、ビューや型付き表には関連付けることができません。監査ポリシーが関連付けられている表にアクセスするビューは、基礎表のポリシーに従って、監査の対象となります。

表に適用される監査ポリシーが、その表に基づいている MQT に自動的に適用されることはありません。表に監査ポリシーを関連付けている場合は、その表に基づいているすべての MQT に同じポリシーを関連付けてください。

トランザクション中に実行される監査は、監査ポリシーと、トランザクション開始時の関連付けに基づいて実行されます。例えば、セキュリティー管理者が、あるユーザーに監査ポリシーを関連付けていて、監査の時点でそのユーザーがトランザクションに入っている場合、監査ポリシーは、そのトランザクション内で実行される残りのステートメントには一切影響を与えません。また、監査ポリシーに対する変更は、コミットされるまで有効になりません。セキュリティー管理者が ALTER AUDIT POLICY ステートメントを発行する際は、そのステートメントがコミットされるまで、変更は有効になりません。

セキュリティー管理者は、監査ポリシーの作成には CREATE AUDIT POLICY ステートメントを、監査ポリシーの変更には ALTER AUDIT POLICY ステートメントを使用します。これらのステートメントでは、以下を指定できます。

監査の対象とするイベントの状況値: None、Success、Failure、または Both。
指定された状況値と一致する監査可能イベントだけが監査の対象になります。
監査中にエラーが発生した場合のサーバーの振る舞い。

セキュリティー管理者は、AUDIT ステートメントを使用することにより、現行サーバーにおいて、現行のデータベースと監査ポリシーまたはデータベース・オブジェクトと監査ポリシーを関連付けることができます。オブジェクトが使用中になっているときは常に、この監査ポリシーに従って監査が行われます。

監査ポリシーを削除する場合、セキュリティー管理者は DROP ステートメントを使用します。監査ポリシーは、何らかのオブジェクトに関連付けられているとドロップできません。 AUDIT REMOVE ステートメントを使用して、残っているオブジェクトとの関連付けをすべて除去してください。監査ポリシーにメタデータを追加する場合、セキュリティー管理者は COMMENT ステートメントを使用します。

完全な接続が確立される前に生成されるイベント

接続とユーザー切り替え操作の過程で生成されるいくつかのイベントの場合、利用できる監査ポリシー情報は、データベースに関連付けられているポリシーだけになります。このようなイベントを、次の表に示します。

表 1. 接続イベント
イベント	監査カテゴリー	コメント
CONNECT	CONTEXT
CONNECT_RESET	CONTEXT
AUTHENTICATION	VALIDATE	これには、トラステッド接続内でのユーザーの接続および切り替えの両方における認証が含まれます。
CHECKING_FUNC	CHECKING	試行されるアクセスは SWITCH_USER です。

これらのイベントは、データベースに関連付けられている監査ポリシーに基づいてのみ監査され、ユーザー、ユーザーのグループ、または権限などのそれ以外のオブジェクトに関連付けられている監査ポリシーでは監査されません。接続の過程で発生する CONNECT および AUTHENTICATION イベントについては、データベースがアクティブになるまで、インスタンス・レベルの監査設定が使用されます。データベースは、最初の接続の過程で、または ACTIVATE DATABASE コマンドが発行されたときにアクティブになります。

ユーザー切り替えの影響

トラステッド接続内でユーザーの切り替えが行われる場合、元のユーザーの名残が後に残ることはありません。このような場合、元のユーザーに関連付けられていた監査ポリシーは考慮されなくなり、新しいユーザーに合わせて適合する監査ポリシーが再評価されます。なお、トラステッド接続に関連付けられている監査ポリシーは引き続き有効です。

SET SESSION USER ステートメントが使用される場合は、セッション許可 ID だけが切り替わります。元のユーザーの許可 ID (システム許可 ID) の監査ポリシーは有効なまま残り、それに加えて新しいユーザーの監査ポリシーも使用されます。セッション内で複数の SET SESSION USER ステートメントが発行される場合は、元のユーザー (システム許可 ID) と現行ユーザー (セッション許可 ID) に関連付けられている監査ポリシーだけが考慮されます。

データ定義言語に関する制約事項

以下のデータ定義言語 (DDL) ステートメントは、AUDIT 排他 SQL ステートメントと呼ばれます。

AUDIT
CREATE AUDIT POLICY、ALTER AUDIT POLICY、および DROP AUDIT POLICY
DROP ROLE および DROP TRUSTED CONTEXT (ドロップされるロールまたはトラステッド・コンテキストが監査ポリシーに関連付けられている場合)

AUDIT 排他 SQL ステートメントには、使用に際していくつかの制約事項があります。

各ステートメントの後には COMMIT または ROLLBACK を発行する必要があります。
これらのステートメントを XA トランザクションなどのグローバル・トランザクション内で発行することはできません。

コミットされていない AUDIT 排他 DDL ステートメントは、全パーティションを通じて同時に 2 つ以上存在してはなりません。コミットされていない 1 つの AUDIT 排他 DDL ステートメントが実行されている間は、後続の AUDIT 排他 DDL ステートメントは現行の AUDIT 排他 DDL ステートメントがコミットまたはロールバックされるまで待機します。

注: 変更はカタログに書き込まれますが、ステートメントを発行する接続の場合でも、COMMIT まで有効になりません。

ユース・ケース

特定の表に対するアクセスすべてを監査する例

EMPLOYEE 表に極めて機密性の高い情報が含まれていて、その表のデータに対するありとあらゆる SQL アクセスを監査しようとしている企業について考えます。表に対する全アクセスのトラッキングには、EXECUTE 区分を使用できます。この区分では、SQL ステートメント、およびオプションとしてそのステートメントの実行時に提供される入力データの値を監査できます。

表でのアクティビティーのトラッキングには、2 つのステップがあります。まず最初に、セキュリティー管理者は EXECUTE 区分を指定する監査ポリシーを作成します。そして次に、そのポリシーを表に関連付けます。

CREATE AUDIT POLICY SENSITIVEDATAPOLICY
    CATEGORIES EXECUTE STATUS BOTH ERROR TYPE AUDIT
COMMIT

AUDIT TABLE EMPLOYEE USING POLICY SENSITIVEDATAPOLICY
COMMIT

特定の権限によるアクションすべてを監査する例

セキュリティー準拠の証明を完成させるには、企業は、システム管理 (SYSADM) またはデータベース管理 (DBADM) 権限を持つユーザーによるデータベース内でのありとあらゆるアクティビティーがモニター可能であることを示す必要があります。

データベース内でのすべてのアクションをキャプチャーするためには、EXECUTE 区分と SYSADMIN 区分の両方を監査する必要があります。セキュリティー管理者は、これらの 2 つの区分を監査する監査ポリシーを作成します。セキュリティー管理者は、AUDIT ステートメントを使用して、この監査ポリシーを SYSADM 権限や DBADM 権限に関連付けることができます。そして、SYSADM または DBADM 権限を保持しているすべてのユーザーについては、すべての監査可能イベントのログが記録されるようになります。次の例は、このような監査ポリシーを作成して、それを SYSADM および DBADM 権限に関連付ける方法を示しています。

CREATE AUDIT POLICY ADMINSPOLICY CATEGORIES EXECUTE STATUS BOTH,
   SYSADMIN STATUS BOTH ERROR TYPE AUDIT
COMMIT
AUDIT SYSADM, DBADM USING POLICY ADMINSPOLICY
COMMIT

特定のロールによるアクセスすべてを監査する例

自社の Web アプリケーションが自社の企業データベースにアクセスできるようにしている企業があります。その Web アプリケーションを使用している個人については、厳密なことがわかりません。使用されるロールだけがわかっており、そのロールを使用してデータベース許可を管理しています。企業は、そのロールに属している個人がデータベースにサブミットしている要求を調べて、それらのユーザーが Web アプリケーション以外からデータベースにアクセスしていないかどうかを確認するために、そのロールに属しているすべてのユーザーのアクションをモニターすることを望んでいます。

EXECUTE 区分には、この状況でユーザーのアクティビティーをトラッキングするために必要なレベルの監査が含まれています。最初のステップは、次のように、適切な監査ポリシーを作成して、Web アプリケーションで使用されるロール (この例では、TELLER と CLERK のロール) にその監査ポリシーを関連付けます。

CREATE AUDIT POLICY WEBAPPPOLICY CATEGORIES EXECUTE WITH DATA
   STATUS BOTH ERROR TYPE AUDIT
COMMIT
AUDIT ROLE TELLER, ROLE CLERK USING POLICY WEBAPPPOLICY
COMMIT

データベースの監査を使用可能にする例

ある企業は、SAMPLE という名前のデータベースで DDL の変更 (例: ALTER TABLE) を行っているユーザーを特定しようとしています。

CONNECT TO SAMPLE

CREATE AUDIT POLICY ALTPOLICY CATEGORIES AUDIT STATUS BOTH,
				OBJMAINT STATUS BOTH,  CHECKING STATUS BOTH,
				EXECUTE STATUS BOTH, ERROR TYPE NORMAL

AUDIT DATABASE USING POLICY ALTPOLICY