統合監査を構成するには、カスタム統合監査ポリシーを作成するか、事前定義の統合監査ポリシーを使用するか、ファイングレイン監査を使用します。
内容は次のとおりです。
実行する監査のタイプ、つまり一般アクティビティ(SQL文のアクションなど)、一般的に使用される監査アクティビティまたはファイングレイン監査に応じて、特定の手順を実行する必要があります。
これらのタイプの監査に加えて、Oracle Databaseではいくつかのアクティビティを強制的に監査します。詳細は、強制的に監査されるアクティビティを参照してください。
内容は次のとおりです。
SQL文やOracle Database VaultなどのOracle Databaseコンポーネントまで、様々なタイプのオブジェクトを監査できます。
また、条件を使用するポリシーも作成できます。ただし、特定の列を監査したり、イベント・ハンドラを使用する場合は、ファイングレイン監査を使用する必要があります。
このタイプの監査を実行する一般的な手順は次のとおりです。
Oracle Databaseには、デフォルトの統合監査ポリシーが用意されており、これらは一般的に使用されるセキュリティ関連の監査用に選択できます。
このタイプの監査を実行する一般的な手順は次のとおりです。
CREATE AUDIT POLICY
文とAUDIT
文を使用して、統合監査ポリシーを使用できます。
内容は次のとおりです。
関連項目:
このタイプの監査の実行に関する一般的な手順については、「SQL文、権限および他の一般アクティビティの監査」を参照してください。
統合監査ポリシーおよびAUDIT
SQL文を使用して、複数のタイプのアクティビティを監査できます。
監査できるアクティビティの種類は、次のとおりです。
ユーザー・アカウント(SYSDBA
管理権限でログインする管理ユーザーを含む)、ロールおよび権限
表の削除やプロシージャの実行などのオブジェクト・アクション
アプリケーション・コンテキスト値
Oracle Database Real Application Security、Oracle Recovery Manager、Oracle Data Mining、Oracle Data Pump、Oracle SQL*Loaderダイレクト・パス・イベント、Oracle Database VaultおよびOracle Label Securityからのアクティビティ
これを実行するには、監査する対象に応じて、次を実行します。
統合監査ポリシー。統合監査ポリシーとは、データベースでのユーザー動作の特定の部分を監査できる監査設定の名前付きのグループです。ポリシーを作成するには、CREATE AUDIT POLICY
文を使用します。ポリシーは、1ユーザーのアクティビティの監査のような単純なものにすることも、条件を使用した複雑な監査ポリシーを作成することもできます。1つのデータベースで同時に複数の監査ポリシーを有効にできます。監査ポリシーには、システム全体の監査オプションとオブジェクト固有の監査オプションの両方を含めることができます。一般的なアクティビティに対する監査の大半(標準監査を含む)に、監査ポリシーを使用する必要があります。
AUDITおよびNOAUDIT SQL文。AUDIT
およびNOAUDIT
SQL文では、それぞれ監査ポリシーを有効および無効にできます。AUDIT
文では、ポリシーに対して特定のユーザーを含めたり、除外することもできます。AUDIT
およびNOAUDIT
文では、アプリケーション・コンテキスト値を監査することもできます。
Oracle Recovery Managerの場合は、統合監査ポリシーを作成しないでください。UNIFIED_AUDIT_TRAIL
ビューでは、一般的に監査されるRecovery Managerイベントを自動的に取得します。
データベースで複数のポリシーを一度に有効にできますが、有効にするポリシーの数を制限することが理想的です。
統合監査ポリシーの構文は、データベースで必要なすべての監査設定を網羅する1つのポリシーを作成できるように設計されています。複数の小さいポリシーを作成するのではなく、関連するオプションを1つのポリシーにグループ化することをお薦めします。これにより、ポリシーをより簡単に管理できるようになります。たとえば、事前定義の統合監査ポリシーを使用したアクティビティの監査で説明されているデフォルトの監査ポリシーには、それぞれ1つの統合監査ポリシーに複数の監査設定が含まれています。
ユーザー・セッションで有効な監査ポリシーの数を制限すると、次の利点が得られます。
監査ポリシーの詳細をセッションのUGAメモリーにロードすることに伴うログオン・オーバーヘッドを軽減します。有効なポリシーの数が減ると、ポリシー情報のロードにかかる時間が短縮します。
UGAメモリーにキャッシュするのに必要なポリシーの数が減るため、セッションのUGAメモリー消費量が減ります。
関連するイベントの監査レコードを生成するかどうかを決定する内部監査チェック機能が効率的になります。
統合監査ポリシーを作成するには、CREATE AUDIT POLICY
文を使用します。
統合監査ポリシーを作成すると、Oracle Databaseによって、ポリシーを作成したユーザーのスキーマではなく、SYS
スキーマによって所有される最初のクラス・オブジェクトに格納されます。
例22-1に、CREATE AUDIT POLICY
文の構文を示します。
例22-1 CREATE AUDIT POLICY文の構文
CREATE AUDIT POLICY policy_name { {privilege_audit_clause [action_audit_clause ] [role_audit_clause ]} | { action_audit_clause [role_audit_clause ] } | { role_audit_clause } } [WHEN audit_condition EVALUATE PER {STATEMENT|SESSION|INSTANCE}] [CONTAINER = {CURRENT | ALL}];
次のように値を指定します。
privilege_audit_clause
は、権限に関連する監査オプションを記述します。詳細は、「システム権限の監査」を参照してください。権限の監査オプションを構成するための詳細な構文は、次のとおりです。
privilege_audit_clause := PRIVILEGES privilege1 [, privilege2]
action_audit_clause
およびstandard_actions
は、オブジェクト・アクションに関連する監査オプションを記述します。詳細は、「オブジェクト・アクションの監査」を参照してください。構文は次のようになります。
action_audit_clause := {standard_actions | component_actions} [, component_actions ] standard_actions := ACTIONS action1 [ ON {schema.obj_name | DIRECTORY directory_name | MINING MODEL schema.obj_name } ] [, action2 [ ON {schema.obj_name | DIRECTORY directory_name | MINING MODEL schema.obj_name } ]
component_actions
では、Oracle Label Security、Oracle Database Real Application Security、Oracle Database Vault、Oracle Data PumpまたはOracle SQL*Loaderの監査ポリシーを作成できます。詳細は、「統合監査ポリシーおよびAUDIT文を使用したアクティビティの監査」の該当する項を参照してください。構文は次のとおりです。
component_actions := ACTIONS COMPONENT=[OLS|XS] action1 [,action2 ] | ACTIONS COMPONENT=DV DV_action ON DV_object_name | ACTIONS COMPONENT=DATAPUMP [ EXPORT | IMPORT | ALL ] | ACTIONS COMPONENT=DIRECT_LOAD [ LOAD | ALL ]
role_audit_clause
では、ロールを監査できます。「ロールの監査」を参照してください。構文は次のとおりです。
role_audit_clause := ROLES role1 [, role2]
WHEN
audit_condition
EVALUATE PER
では、監査ポリシーおよび評価頻度の条件を作成するためのファンクションを指定できます。EVALUATE PER
句には、WHEN
条件を付ける必要があります。「統合監査ポリシーの条件の作成」を参照してください構文は次のとおりです。
WHEN 'audit_condition := function operation value_list' EVALUATE PER {STATEMENT|SESSION|INSTANCE}
CONTAINER
は、マルチテナント環境に使用され、ローカル監査ポリシー(ローカル・プラガブル・データベース(PDB)用)または一般的な監査ポリシーとして監査ポリシーを作成できます。「マルチテナント環境での統合監査ポリシーまたはAUDIT設定の使用」を参照してください。
この構文は、ポリシーにリストされているコンポーネントを監査するように設計されています。たとえば、次のポリシーを作成するとします。
CREATE AUDIT POLICY table_pol PRIVILEGES CREATE ANY TABLE, DROP ANY TABLE ROLES emp_admin, sales_admin;
監査証跡では、CREATE ANY TABLE
システム権限またはDROP ANY TABLE
システム権限、ロールemp_admin
に直接付与されている任意のシステム権限、またはロールsales_admin
に直接付与されている任意のシステム権限を必要とするSQL文を取得します。(監査されるのは、ロールを介して再帰的に付与されている権限ではなく、直接付与されている権限であることに注意してください。)
ポリシーを作成したら、AUDIT
文を使用して有効にする必要があります。オプションで、1人以上のユーザーに対してポリシーの適用または除外を実行したり、監査アクションの成功または失敗(あるいは両方)時に監査レコードが書き込まれるかどうかを指定できます。「ユーザーに対する統合監査ポリシーの有効化」を参照してください
CREATE AUDIT POLICY
文を使用して、データベース・ロールを監査できます。
内容は次のとおりです。
ロールを監査すると、このロールに直接付与されたすべてのシステム権限がOracle Databaseによって監査されます。
ユーザー定義のロールを含むすべてのロールを監査できます。ROLES
監査オプションでロールに対して共通の統合監査ポリシーを作成する場合、ロール・リストで共通ロールのみを指定する必要があります。このようなポリシーが有効な場合、Oracle Databaseは、共通ロールに対して共通のシステム権限と共通ロールに直接付与されているシステム権限をすべて監査します。共通ロールに対してローカルに付与されているシステム権限は監査されません。ロールが共通に付与されているかどうかを確認するには、DBA_ROLES
データ・ディクショナリ・ビューを問い合せます。ロールに付与された権限が共通に付与されたかどうかを確認するには、ROLE_SYS_PRIVS
ビューを問い合せます。
関連項目:
事前定義ロールのリストは、「Oracle Databaseのインストールで事前に定義されているロール」を参照してください。
ロールの使用を取得する統合監査ポリシーを作成するには、CREATE AUDIT POLICY
文にROLES
句を含めます。
次の構文を使用して、ロールを監査する統合監査ポリシーを作成します。
CREATE AUDIT POLICY policy_name ROLES role1 [, role2];
例:
CREATE AUDIT POLICY audit_roles_pol ROLES IMP_FULL_DATABASE, EXP_FULL_DATABASE;
条件を含む場合など、より複雑なロールの統合監査ポリシーを作成できます。ポリシーを作成したら、AUDIT
文を使用して有効にする必要があります。
関連項目:
統合監査ポリシーの作成の構文マルチテナント環境で、CREATE AUDIT POLICY
文を使用してロールを監査できます。
例22-2に、マルチテナント環境で事前定義済の共通ロールDBA
を監査する方法を示します。
例22-2 マルチテナント環境でのDBAロールの監査
CREATE AUDIT POLICY role_dba_audit_pol ROLES DBA CONTAINER = ALL; AUDIT POLICY role_dba_audit_pol;
CREATE AUDIT POLICY
文を使用して、システム権限を監査できます。
内容は次のとおりです。
システム権限の監査では、システム権限を使用するアクティビティ(READ
ANY
TABLE
など)を監査します。
この種の監査では、正常終了するために監査対象の権限を必要とするSQL文が記録されます。
1つの統合監査ポリシーに、権限監査およびアクション監査の両方のオプションを含めることができます。SYS
などの管理ユーザーの権限の使用は監査しないでください。かわりに、オブジェクト・アクションを監査してください。詳細は、オブジェクト・アクションの監査を参照してください。
注意:
システム権限、オブジェクト、データベース・イベントなどを監査できます。ただし、データベース権限の使用状況(たとえば、指定のロールに付与されている権限はどれが使用されているか)を検索し、使用されている権限と使用されていない権限のレポートを生成する必要がある場合は、権限キャプチャを作成できます。詳細は、『Oracle Database Vault管理者ガイド』を参照してください。
ほとんどのシステム権限の使用を監査できます。
監査可能なシステム権限のリストを検索するには、SYSTEM_PRIVILEGE_MAP
表を問い合せます。
例:
SELECT NAME FROM SYSTEM_PRIVILEGE_MAP; NAME ------------- ALTER ANY CUBE BUILD PROCESS SELECT ANY CUBE BUILD PROCESS ALTER ANY MEASURE FOLDER ...
アクション監査オプションと同様、権限監査では、データベース・ユーザーに付与されているシステム権限の使用を監査します。SQL文監査と権限監査の両方について類似の監査オプションを設定しても、生成される監査レコードは1つのみです。たとえば、2つのポリシーが存在しており、一方が、特にHR.PROC
プロシージャのEXECUTE PROCEDURE
を監査し、もう一方が一般的にEXECUTE PROCEDURE
(すべてのプロシージャ)を監査する場合は、監査レコードが1つのみ書き込まれます。
権限監査は、アクションが既存の所有者およびオブジェクト権限によってすでに許可されている場合は実行されません。権限監査がトリガーされるのは、権限が不十分な場合、つまりアクションを可能にする権限がシステム権限である場合のみです。たとえば、ユーザーSCOTT
にSELECT ANY TABLE
権限が付与されており、SELECT ANY TABLE
が監査対象であるとします。SCOTT
が自分の表(たとえば、SCOTT.EMP
)を選択した場合、SELECT ANY TABLE
権限は使用されません。自分自身のスキーマ内でSELECT
文を実行したため、監査レコードは生成されません。一方、SCOTT
が他のスキーマ(たとえばHR.EMPLOYEES
表)から選択すると、監査レコードが生成されます。SCOTT
は自分自身のスキーマ外にある表を選択したため、SELECT ANY TABLE
権限を使用する必要がありました。
次のシステム権限は監査できません。
これらの権限を次に示します。
INHERIT ANY PRIVILEGE
INHERIT PRIVILEGE
TRANSLATE ANY SQL
TRANSLATE SQL
CREATE AUDIT POLICY
文のPRIVILEGES
句で、システム権限の使用を監査します。
次の構文を使用して、権限を監査する統合監査ポリシーを作成します。
CREATE AUDIT POLICY policy_name PRIVILEGES privilege1 [, privilege2];
例:
CREATE AUDIT POLICY my_simple_priv_policy PRIVILEGES SELECT ANY TABLE, CREATE LIBRARY;
条件を含む場合など、より複雑な権限の統合監査ポリシーを作成できます。ポリシーを作成したら、AUDIT
文を使用して有効にする必要があります。
関連項目:
統合監査ポリシーの作成の構文CREATE AUDIT POLICY
文で、ANY
権限のユーザーを監査できます。
例22-3に、ユーザーHR_MGR
の複数のANY
権限を監査する方法を示します。
例22-3 ANY権限を持つユーザーの監査
CREATE AUDIT POLICY hr_mgr_audit_pol PRIVILEGES DROP ANY TABLE, DROP ANY CONTEXT, DROP ANY INDEX, DROP ANY LIBRARY; AUDIT POLICY hr_mgr_audit_pol BY HR_MGR;
CREATE AUDIT POLICY
文で、システム権限の監査に条件を使用する監査ポリシーを作成できます。
例22-4に、psmith
およびjrawlins
の2人のオペレーティング・システム・ユーザーによって使用される権限を監査する方法を示します。
例22-4 条件を使用するシステム権限の監査
CREATE AUDIT POLICY os_users_priv_pol PRIVILEGES SELECT ANY TABLE, CREATE LIBRARY WHEN 'SYS_CONTEXT (''USERENV'', ''OS_USER'') IN (''psmith'', ''jrawlins'')' EVALUATE PER SESSION; AUDIT POLICY os_users_priv_pol;
UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューはシステム権限の監査イベントを表示します。
必要に応じて、DBMS_AUDIT_MGMT.FLUSH_UNIFIIED_AUDIT_TRAIL
プロシージャを実行して、監査レコードをディスクに書き込みます。
EXEC DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL;
詳細は、「キュー書込みモードでの監査証跡への監査レコードの手動フラッシュ」を参照してください。
次の例では、例22-4で作成した統合監査ポリシーos_users_priv_pol
に基づいて、オペレーティング・システム・ユーザーpsmith
によって使用される権限のリストが表示されます。
SELECT SYSTEM_PRIVILEGE_USED FROM UNIFIED_AUDIT_TRAIL WHERE OS_USERNAME = 'PSMITH' AND UNIFIED_AUDIT_POLICIES = 'OS_USERS_PRIV_POL'; SYSTEM_PRIVILEGE_USED ---------------------- SELECT ANY TABLE DROP ANY TABLE
注意:
SELECT ANY TABLE
システム権限に対する監査ポリシーを作成した場合、ユーザーがREAD
オブジェクト権限を実行したか、SELECT
オブジェクト権限を実行したかによって監査証跡で取得されるアクションが影響を受けます。詳細は、SELECT、READ ANY TABLEまたはSELECT ANY TABLEの監査を参照してください。
Oracle Databaseには、SYS
などのデフォルトの管理ユーザー・アカウントのセットがあります。これらのユーザーのアクションを取得する統合監査ポリシーを作成できます。
内容は次のとおりです。
Oracle Databaseでは、管理権限に関連付けられている管理ユーザー・アカウントが用意されています。
表22-1に、デフォルトの管理ユーザー・アカウントと、通常関連付けられている管理権限を示します。
表22-1 管理ユーザーおよび管理権限
管理ユーザー・アカウント | 管理権限 |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
脚注1
PUBLIC
はユーザーPUBLIC
を示し、SYSOPER
管理権限でログインしている場合に有効なユーザーです。これはPUBLIC
ロールを示しません。
関連項目:
CREATE AUDIT POLICY
文で、管理ユーザーを監査できます。
管理ユーザーを監査する場合は、統合監査ポリシーを作成して、非管理ユーザーに適用する場合と同じように、このポリシーをユーザーに適用します。管理ユーザーによるトップ・レベルの文は、データベースを開くまで強制的に監査されます。
CREATE AUDIT POLICY
文で、SYS
ユーザーを監査できます。
例22-5に、ユーザーSYS
によるDBMS_FGA
PL/SQLパッケージの権限付与を監査する方法を示します。
例22-5 SYSユーザーの監査
CREATE AUDIT POLICY dbms_fga_grants ACTIONS GRANT ON DBMS_FGA; AUDIT POLICY dbms_fga_grants BY SYS;
CREATE AUDIT POLICY
文を使用して、オブジェクト・アクションを監査できます。
内容は次のとおりです。
HR.EMPLOYEES
表のUPDATE
文など、特定のオブジェクトで実行されるアクションを監査できます。
監査は、オブジェクトに使用されたDDLおよびDML文を含むことができます。1つの統合監査ポリシーに、権限監査およびアクション監査の両方のオプションと、複数のオブジェクトの監査オプションのセットを含めることができます。
オブジェクト・アクションの監査では、監査の対象を拡大または限定できます(すべてのユーザー・アクションの監査または一部のユーザー・アクションに限定した監査など)。
表22-2に、オブジェクト・レベルの標準データベース・アクションのオプションを示します。SELECT
SQL文に対する監査ポリシーでは、SELECT
アクションだけでなくREAD
アクションも取得されます。
表22-2 オブジェクト・レベルの標準データベース・アクションの監査オプション
オブジェクト | 監査できるSQLアクション |
---|---|
表 |
|
ビュー |
|
シーケンス |
|
プロシージャ(トリガーを含む) |
|
ファンクション |
|
パッケージ |
|
マテリアライズド・ビュー |
|
マイニング・モデル |
|
ディレクトリ |
|
ライブラリ |
|
オブジェクト型 |
|
Javaスキーマ・オブジェクト(ソース、クラス、リソース) |
|
CREATE AUDIT POLICY
文のACTIONS
句で、オブジェクト・アクションを取得するポリシーを作成します。
次の構文を使用して、オブジェクト・アクションを監査する統合監査ポリシーを作成します。
CREATE AUDIT POLICY policy_name ACTIONS action1 [, action2 ON object1] [, action3 ON object2];
例:
CREATE AUDIT POLICY my_simple_obj_policy ACTIONS SELECT ON OE.ORDERS, UPDATE ON HR.EMPLOYEES;
この例に示すように、複数のオブジェクトの複数のアクションを監査できます。
条件を含む場合など、より複雑なオブジェクト・アクションの統合監査ポリシーを作成できます。ポリシーを作成したら、AUDIT
文を使用して有効にする必要があります。
関連項目:
統合監査ポリシーの作成の構文CREATE AUDIT POLICY
文で、SYS
オブジェクトのアクションを監査できます。
例22-6では、SYS.USER$システム表でSELECT文を監査する監査ポリシーの作成方法を示します。この監査ポリシーは、
SYS
およびSYSTEM
を含むすべてのユーザーに適用されます。
例22-6 SYSオブジェクトの監査アクション
CREATE AUDIT POLICY select_user_dictionary_table_pol ACTIONS SELECT ON SYS.USER$; AUDIT POLICY select_user_dictionary_table_pol;
CREATE AUDIT POLICY
文で、1つのオブジェクト上の複数のアクションを監査できます。
例22-7に、ユーザーjrandolph
およびphawkins
によってapp_lib
ライブラリで実行される複数のSQL文の監査方法を示します。
例22-7 1つのオブジェクトでの複数のアクションの監査
CREATE AUDIT POLICY actions_on_hr_emp_pol1 ACTIONS EXECUTE, GRANT ON app_lib; AUDIT POLICY actions_on_hr_emp_pol1 BY jrandolph, phawkins;
CREATE AUDIT POLICY
文で、単一のポリシーを使用して1つのオブジェクトでの複数のアクションと権限の両方を監査できます。
例22-8に、例22-7のバリエーション(CREATE LIBRARY
権限を使用して、app_lib
ライブラリのすべてのEXECUTE
文およびGRANT
文が監査されます)を示します。
例22-8 オブジェクトでのアクションと権限の両方の監査
CREATE AUDIT POLICY actions_on_hr_emp_pol2 PRIVILEGES CREATE LIBRARY ACTIONS EXECUTE, GRANT ON app_lib; AUDIT POLICY actions_on_hr_emp_pol2 BY jrandolph, phawkins;
ディレクトリ・オブジェクトは監査可能です。たとえば、ORACLE_LOADER
アクセス・ドライバで使用されるプリプロセッサ・プログラムを含むディレクトリ・オブジェクトを作成するとします。ディレクトリ・オブジェクト内のこのプログラムを実行するすべてのユーザーを監査できます。
CREATE AUDIT POLICY
文で、表でのすべてのアクションを監査できます。
キーワードALL
を使用してすべてのアクションを監査できます。例22-9に、HR.EMPLOYEES
表ですべてのアクション(ユーザーpmulligan
によるアクションを除く)を監査する方法を示します。
例22-9 表でのすべてのアクションの監査
CREATE AUDIT POLICY all_actions_on_hr_emp_pol ACTIONS ALL ON HR.EMPLOYEES; AUDIT POLICY all_actions_on_hr_emp_pol EXCEPT pmulligan;
CREATE AUDIT POLICY
文で、データベースでのすべてのアクションを監査できます。
例22-10に、データベース全体ですべてのアクションを監査する方法を示します。
例22-10 データベースでのすべてのアクションの監査
CREATE AUDIT POLICY all_actions_pol ACTIONS ALL; AUDIT POLICY all_actions_pol;
UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューはオブジェクト・アクションの監査イベントを表示します。
必要に応じて、DBMS_AUDIT_MGMT.FLUSH_UNIFIIED_AUDIT_TRAIL
プロシージャを実行して、監査レコードをディスクに書き込みます。
EXEC DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL;
詳細は、「キュー書込みモードでの監査証跡への監査レコードの手動フラッシュ」を参照してください。
例:
SELECT ACTION_NAME, OBJECT_SCHEMA, OBJECT_NAME FROM UNIFIED_AUDIT_TRAIL WHERE DBUSERNAME = 'SYS'; ACTION_NAME OBJECT_SCHEMA OBJECT_NAME ----------- ------------- ------------ SELECT HR EMPLOYEES
ファンクション、プロシージャ、PL/SQLパッケージおよびトリガーを監査できます。
監査可能な領域は次のとおりです。
スタンドアロン・ファンクション、スタンドアロン・プロシージャおよびPL/SQLパッケージは個別に監査できます。
PL/SQLパッケージを監査すると、パッケージ内のすべてのファンクションおよびプロシージャが監査されます。
すべての実行の監査を使用可能にすると、データベース内のすべてのトリガーおよびPL/SQLパッケージ内のすべてのファンクションとプロシージャが監査されます。
PL/SQLパッケージ内のファンクションまたはプロシージャを個別に監査することはできません。
PL/SQLストアド・プロシージャまたはストアド・ファンクションでのEXECUTE
操作を監査する場合は、監査目的での操作の成否を判断する際に、プロシージャまたはファンクションを検索してその実行を認証する機能のみが監査対象となります。したがって、WHENEVER NOT SUCCESSFUL
句を指定すると、無効なオブジェクト・エラー、存在しないオブジェクト・エラー、および認証の失敗が監査されます。プロシージャまたはファンクションの実行時に検出されたエラーは監査されません。WHENEVER SUCCESSFUL
句を指定すると、実行時にエラーが検出されたかどうかに関係なく、無効なオブジェクト・エラー、存在しないオブジェクト・エラー、および認証の失敗が監査されます。
監査によって動的VPDポリシーや静的VPDポリシー、コンテキスト依存VPDポリシーが影響を受けることがあります。
動的ポリシー: ポリシー関数が2回(SQL文の解析時に1回と実行時に1回)評価されます。結果として、各評価で2つの監査レコードが生成されます。
静的ポリシー: ポリシー関数が1回評価され、SGA内にキャッシュされます。これにより、監査レコードは1つのみ生成されます。
状況依存ポリシー: ポリシー関数が文の解析時に1回実行されます。これにより、監査レコードは1つのみ生成されます。
エディション付きオブジェクトに統合監査ポリシーが付加されている場合、そのオブジェクトが表示されるすべてのエディションにそのポリシーが適用されます。
エディション付きオブジェクトが実現化されると、そのオブジェクトに付加されている統合監査ポリシーが新しい実際のオブジェクトに新たに付加されます。継承されたエディション付きオブジェクトに新たに統合監査ポリシーを適用すると、そのオブジェクトが実現化されます。
監査対象のオブジェクトが表示されるエディションを調べるには、UNIFIED_AUDIT_TRAIL
データ・ディクショナリ・ビューのOBJECT_NAME
およびOBJ_EDITION_NAME
列を問い合せます。
関連項目:
エディションの詳細は、『Oracle Database開発ガイド』を参照してください。
CREATE AUDIT POLICY
文を使用して、SELECT
文とREAD ANY TABLE
権限またはSELECT ANY TABLE
権限を監査できます。
内容は次のとおりです。
READ ANY TABLE
システム権限の使用を取得する統合監査ポリシーを作成できます。
ユーザーが実行しようとしたアクションおよびユーザーに付与されていた権限に基づいて、UNIFIED_AUDIT_TRAIL
データ・ディクショナリ・ビューのSYSTEM_PRIVILEGE_USED
列にREAD ANY TABLE
システム権限またはSELECT ANY TABLE
システム権限が記録されます。たとえば、ユーザーにSELECT ANY TABLE
権限が付与されていて、表に対する問合せを実行するとします。監査証跡に、ユーザーがSELECT ANY TABLE
システム権限を使用したことが記録されます。ユーザーにREAD ANY TABLE
が付与されていて、同じ問合せを実行した場合、READ ANY TABLE
権限が記録されます。
READ
オブジェクト権限操作を取得する統合監査ポリシーを作成できます。
READ
オブジェクト操作を取得する統合監査ポリシーを作成する場合、READ
文ではなくSELECT
文に対するポリシーを作成します。
例:
CREATE AUDIT POLICY read_hr_employees ACTIONS SELECT ON HR.EMPLOYEES;
統合監査証跡では、ユーザーにREAD ANY TABLE
またはSELECT ANY TABLE
権限が付与されているかどうかに基づいてSELECT
動作が取得されます。
表22-3は、統合監査証跡によるこれらのアクションの取得方法を示しています。
表22-3 READ ANY TABLEおよびSELECT ANY TABLEに対する監査動作
ユーザーが発行した文 | ユーザーに付与されている権限 | 監査されるシステム権限 | 予期されるUNIFIED_AUDIT_TRAILの動作 |
---|---|---|---|
|
|
|
|
|
|
|
レコードなし |
|
|
|
|
|
|
|
レコードなし |
|
|
|
レコードなし |
|
|
|
|
|
|
|
|
|
|
|
レコードなし |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
レコードなし |
|
|
|
レコードなし |
|
|
|
レコードなし |
|
|
|
レコードなし |
|
|
|
レコードなし |
|
|
|
|
|
|
|
レコードなし |
|
|
|
|
|
|
|
レコードなし |
|
|
|
レコードなし |
|
|
|
レコードなし |
|
|
|
レコードなし |
|
|
|
レコードなし |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
レコードなし |
|
|
|
レコードなし |
|
|
|
レコードなし |
|
|
|
レコードなし |
|
|
|
レコードなし |
統合監査ポリシーを作成して、複数層環境のクライアントのアクティビティを監査できます。
複数層環境では、クライアントの識別情報をすべての層を通して保持できます。したがって、クライアントにかわって中間層アプリケーションにより行われたアクションを、ポリシーのAUDIT
文の中でBY
user
句を使用することで監査できます。監査は、プロキシ・セッションを含むすべてのユーザー・セッションに適用されます。
中間層では、データベース・セッションでユーザーのクライアント識別情報を設定し、中間層アプリケーションでエンド・ユーザーのアクションを監査することもできます。そうすることにより、エンド・ユーザーのクライアント識別情報が監査証跡に記録されます。
次の例は、ユーザーjackson
によって発行されたSELECT TABLE
文を監査する方法を示しています。
CREATE AUDIT POLICY tab_pol PRIVILEGES CREATE ANY TABLE ACTIONS CREATE TABLE; AUDIT tab_pol BY jackson;
複数層環境でユーザー・アクティビティを監査できます。監査を開始した後で、UNIFIED_AUDIT_TRAIL
データ・ディクショナリ・ビューを問い合せることで、これらのアクティビティを確認できます。
図22-1に、UNIFIED_AUDIT_TRAIL
ビューのPROXY_SESSIONID
、ACTION_NAME
およびSESSION_ID
列を問い合せることで、プロキシ・ユーザーを監査する方法を示します。このシナリオでは、データベース・ユーザーとプロキシ・ユーザーの両方のアカウントがデータベースに認識されます。セッション・プーリングを使用できます。
図22-2に、DBA_AUDIT_TRAIL
データ・ディクショナリ・ビューのCLIENT_ID
列を問い合せることで、複数のデータベース・セッションにわたるクライアント識別子情報を監査する方法を示します。この例では、クライアント識別子はCLIENT_A
に設定されています。図22-1に示すプロキシ・ユーザー/データベース・ユーザーの例と同様に、セッション・プーリングを使用できます。
関連項目:
複数層環境でのユーザー認証の詳細は、複数層環境でのユーザー識別情報の保持を参照してください
CREATE AUDIT POLICY
文を使用すると、統合監査ポリシーの条件を作成できます。
内容は次のとおりです。
SYS_CONTEXT
ネームスペースと属性のペアを使用して条件を指定する統合監査ポリシーを作成できます。
たとえば、監査条件を満たす可能性のある特定のユーザーや、監査条件を満たすコンピュータ・ホストにこの監査条件を適用します。
監査条件が満たされると、Oracle Databaseによってイベントのレコードが監査されます。条件定義の一部として、監査条件が文の発生、セッションまたはデータベース・インスタンスごとに評価されるかどうかを指定する必要があります。
注意:
監査条件では、安全なアプリケーション・コンテキストと安全でないアプリケーション・コンテキストの両方を使用できます。
CREATE AUDIT POLICY
文のWHEN
句で、監査ポリシーの条件を定義します。
次の構文を使用して、条件を使用する統合監査ポリシーを作成します。
CREATE AUDIT POLICY policy_name action_privilege_role_audit_option [WHEN function_operation_value_list_1 [[AND | OR] function_operation_value_list_n] EVALUATE PER STATEMENT | SESSION | INSTANCE];
次のように値を指定します。
action_privilege_role_audit_option
は、システム・アクション、オブジェクト・アクション、権限およびロールの監査オプションを示します。
WHEN
は、条件を定義します。この項では、次のコンポーネントについて説明します。
function
は、次のタイプの関数を使用します。
数値関数: BITAND
、CEIL
、FLOOR
、LN
POWER
など
文字値を戻す文字関数: CONCAT
、LOWER
、UPPER
など
数値を戻す文字関数: LENGTH
、INSTR
など
環境および識別子関数: SYS_CONTEXT
、UID
など。SYS_CONTEXT
では、ほとんどの場合、『Oracle Database SQL言語リファレンス』に説明されているUSERENV
ネームスペースを使用できます。
operation
には、AND
、OR
、IN
、NOT IN
、=
、<
、>
、<>
の演算子を使用できます。
value_list
は、テストする条件を示します。
function_operation_value_list
セットごとに、AND
またはOR
で区切られた追加の条件を含めることができます。
WHEN
句を記述する場合は、次のガイドラインに従います。
function operation value
設定全体を一重引用符で囲みます。句内では、引用符で囲まれたそれぞれの構成要素を、2つのペアの一重引用符で囲みます。二重引用符は使用しないでください。
WHEN
条件は4000バイトを超えないでください。
EVALUATE PER
は、次のオプションを示します。
STATEMENT
は、発生する監査可能な関連する各文の条件を評価します。
SESSION
は、セッション中に1回のみ条件を評価し、セッションの残りで結果をキャッシュして再利用します。Oracle Databaseでは、ポリシーが最初に使用されるときに条件を評価し、結果をUGAメモリーに後で保存します。
INSTANCE
は、データベース・インスタンスのライフタイム中に1回のみ条件を評価します。Oracle Databaseは条件を評価した後、インスタンスの残りのライフタイムで結果をキャッシュして再利用します。SESSION
評価と同様、評価は最初に必要になるときに実行され、結果は後でUGAメモリーに保存されます。
例:
CREATE AUDIT POLICY oe_orders_pol ACTIONS UPDATE ON OE.ORDERS WHEN 'SYS_CONTEXT(''USERENV'', ''IDENTIFICATION_TYPE'') = ''EXTERNAL''' EVALUATE PER STATEMENT;
ポリシーを作成したら、AUDIT
文を使用して有効にする必要があります。
関連項目:
条件で使用可能な関数の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。CREATE AUDIT POLICY文で、SQL*Plusへのアクセスを監査できます。
例22-11に、HR
およびOE
というユーザーによるSQL*Plusを使用したデータベース・アクセスを監査する方法を示します。
例22-11 SQL*Plusへのアクセスの監査
CREATE AUDIT POLICY logon_pol ACTIONS LOGON WHEN 'INSTR(UPPER(SYS_CONTEXT(''USERENV'', ''CLIENT_PROGRAM_NAME'')), ''SQLPLUS'') > 0' EVALUATE PER SESSION; AUDIT POLICY logon_pol BY HR, OE;
CREATE AUDIT POLICY
文で、特定のホストにはないアクションを監査できます。
例22-12に、OE.ORDERS
表の2つの監査アクション(UPDATE
およびDELETE
文)を監査する方法を示します(ホスト名sales_24
およびsales_12
は監査から除く)。監査はセッション単位で実行され、失敗した場合にのみ監査レコードが書き込まれます。
例22-12 特定のホストにはないアクションの監査
CREATE AUDIT POLICY oe_table_audit1 ACTIONS UPDATE ON OE.ORDERS, DELETE ON OE.ORDERS WHEN 'SYS_CONTEXT (''USERENV'', ''HOST'') NOT IN (''sales_24'',''sales_12'')' EVALUATE PER SESSION; AUDIT POLICY oe_table_audit1 WHENEVER NOT SUCCESSFUL;
CREATE AUDIT POLICY
文で、システム全体のアクションおよびスキーマ固有のアクションの両方を監査できます。
例22-13に、UPDATE
文がシステム全体で監査される例22-12のバリエーションを示します。DELETE
文の監査は、OE.ORDERS
表に固有です。
例22-13 システム全体のアクションおよびスキーマ固有のアクションの両方の監査
CREATE AUDIT POLICY oe_table_audit2 ACTIONS UPDATE, DELETE ON OE.ORDERS WHEN 'SYS_CONTEXT (''USERENV'', ''HOST'') NOT IN (''sales_24'',''sales_12'')' EVALUATE PER SESSION; AUDIT POLICY oe_table_audit2;
CREATE AUDIT POLICY
文で、条件を監査できます。
例22-14に、OE.ORDERS
表のDELETE
文の各発生に基づいて条件を監査する方法を示します(ユーザーjmartin
は監査から除く)。
例22-14 文の発生ごとの条件の監査
CREATE AUDIT POLICY sales_clerk_pol ACTIONS DELETE ON OE.ORDERS WHEN 'SYS_CONTEXT(''USERENV'', ''CLIENT_IDENTIFIER'') = ''sales_clerk''' EVALUATE PER STATEMENT; AUDIT POLICY sales_clerk_pol EXCEPT jmartin;
SYS_CONTEXT
関数を使用してセッションIDを確認できます。
例22-15に、管理ユーザーの現在のユーザー・セッションの統合監査セッションIDの確認方法を示します。
例22-15 現在の管理ユーザー・セッションの統合監査セッションID
CONNECT SYS AS SYSDBA
Enter password: password
SELECT SYS_CONTEXT('USERENV', 'UNIFIED_AUDIT_SESSIONID') FROM DUAL;
次のような出力が表示されます。
SYS_CONTEXT('USERENV','UNIFIED_AUDIT_SESSIONID') -------------------------------------------------------------------------------- 2318470183
混合モード監査では、USERENV
ネームスペースのUNIFIED_AUDIT_SESSIONID
値はSESSIONID
パラメータで記録される値とは異なります。このため、混合モード監査を使用し、正しい監査セッションIDを確認する場合、SESSIONID
パラメータではなくUSERENV UNIFIED_AUDIT_SESSIONID
パラメータを使用します。完全な統合監査では、SESSIONID
とUNIFIED_AUDIT_SESSIONID
の値は同じです。
SYS_CONTEXT
関数を使用して、現在の非管理ユーザー・セッションのセッションIDを確認できます。
例22-16に、非管理ユーザーの現在のユーザー・セッションの統合監査セッションIDの確認方法を示します。
例22-16 現在の非管理ユーザー・セッションの統合監査セッションID
CONNECT mblake -- Or, CONNECT mblake@hrpdb for a PDB
Enter password: password
SELECT SYS_CONTEXT('USERENV', 'UNIFIED_AUDIT_SESSIONID') FROM DUAL;
次のような出力が表示されます。
SYS_CONTEXT('USERENV','UNIFIED_AUDIT_SESSIONID') -------------------------------------------------------------------------------- 2776921346
統合監査ポリシーからの監査レコードの条件は、監査証跡には表示されません。
条件がtrueと評価され、レコードが書き込まれると、レコードは監査証跡に表示されます。UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せることで、監査証跡をチェックできます。
関連項目:
その他の監査証跡については、監査ポリシーのデータ・ディクショナリ・ビューを参照してくださいAUDIT
文を使用して、アプリケーション・コンテキスト値を監査できます。
内容は次のとおりです。
統合監査証跡でアプリケーション・コンテキスト値を取得できます。
この機能では、監査対象の文の実行中にデータベース・アプリケーションによって設定されるアプリケーション・コンテキスト値を取得します。
Oracle Label Securityを監査する場合は、この機能により、データベース監査証跡のセッション・ラベルのアクティビティが取得されます。監査証跡では、指定したコンテキストと属性値のペアで取得されたすべての値が記録されます。
アプリケーション・コンテキストの監査設定または監査ポリシーには、セッションの静的セマンティクがあります。つまり、ユーザーに対して新しいポリシーが有効になると、後続のユーザー・セッションにこのコマンドの結果が表示されます。セッションが確立されると、ポリシーとコンテキストの設定がロードされ、このセッションは後続のAUDIT
文の影響を受けません。
マルチテナント環境では、アプリケーション・コンテキストの監査ポリシーは現在のPDBのみに適用されます。
関連項目:
アプリケーション・コンテキストの詳細は、「アプリケーション・コンテキストを使用したユーザー情報の取得」を参照してください。
Oracle Label Securityの詳細は、『Oracle Label Security管理者ガイド』を参照してください。
CONTEXT
キーワードを使用したAUDIT
文で、アプリケーション・コンテキスト値の監査を構成します。
このタイプの監査では、統合監査ポリシーを作成しません。
次の構文を使用して、アプリケーション・コンテキスト値の監査を構成します。
AUDIT CONTEXT NAMESPACE context_name1 ATTRIBUTES attribute1 [, attribute2] [, CONTEXT NAMESPACE context_name2 ATTRIBUTES attribute1 [, attribute2]] [BY user_list];
次のように値を指定します。
context_name1
: オプションでCONTEXT
の名前と属性のペアを1つ追加できます。
user_list
は、データベース・ユーザー・アカウントのオプションのリストです。複数の名前はカンマで区切ります。この設定を省略すると、Oracle Databaseによって、すべてのユーザーにアプリケーション・コンテキスト・ポリシーが構成されます。各ユーザーがログインすると、関連するすべてのアプリケーション・コンテキストと属性のリストがユーザー・セッションでキャッシュされます。
例:
AUDIT CONTEXT NAMESPACE clientcontext3 ATTRIBUTES module, action, CONTEXT NAMESPACE ols_session_labels ATTRIBUTES ols_pol1, ols_pol3 BY appuser1, appuser2;
現在構成されているアプリケーション・コンテキストの監査設定のリストを検索するには、AUDIT_UNIFIED_CONTEXTS
データ・ディクショナリ・ビューを問い合せます。
NOAUDIT
文で、アプリケーション・コンテキストの監査設定を無効にします。
アプリケーション・コンテキストの監査設定を無効にするには、NOAUDIT
文でネームスペースと属性設定を指定します。属性は任意の順序で入力できます(対応するAUDIT CONTEXT
文で使用される順序に一致させる必要はありません)。
例:
NOAUDIT CONTEXT NAMESPACE client_context ATTRIBUTES module, CONTEXT NAMESPACE ols_session_labels ATTRIBUTES ols_pol1, ols_pol3 BY appuser1, appuser2;
現在監査されているアプリケーション・コンテキストを検索するには、AUDIT_UNIFIED_CONTEXTS
データ・ディクショナリ・ビューを問い合せます。
AUDIT CONTEXT NAMESPACE
文で、アプリケーション・コンテキスト値を監査できます。
例22-17に、ユーザーappuser1
によるmodule
およびaction
属性のclientcontext
アプリケーション値の監査方法を示します。
例22-17 デフォルト・データベースでのアプリケーション・コンテキスト値の監査
AUDIT CONTEXT NAMESPACE clientcontext ATTRIBUTES module, action BY appuser1;
AUDIT CONTEXT NAMESPACE
文で、Oracle Label Securityのアプリケーション・コンテキスト値を監査できます。
例22-18に、属性ols_pol1
およびols_pol2
に対して、ols_session_labels
という名前のOracle Label Securityのアプリケーション・コンテキストの監査方法を示します。
例22-18 Oracle Label Securityのアプリケーション・コンテキスト値の監査
AUDIT CONTEXT NAMESPACE ols_session_labels ATTRIBUTES ols_pol1, ols_pol2;
UNIFIED_AUDIT_POLICIESデータ・ディクショナリ・ビューはアプリケーション・コンテキストの監査イベントを表示します。
必要に応じて、DBMS_AUDIT_MGMT.FLUSH_UNIFIIED_AUDIT_TRAIL
プロシージャを実行して、監査レコードをディスクに書き込みます。
EXEC DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL;
詳細は、「キュー書込みモードでの監査証跡への監査レコードの手動フラッシュ」を参照してください。
UNIFIED_AUDIT_TRAIL
データ・ディクショナリ・ビューのAPPLICATION_CONTEXTS
列には、アプリケーション・コンテキストの監査データが表示されます。アプリケーション・コンテキストは、セミコロンで区切られた値のリストとして表示されます。
例:
SELECT APPLICATION_CONTEXTS FROM UNIFIED_AUDIT_TRAIL WHERE UNIFIED_AUDIT_POLICIES = 'app_audit_pol'; APPLICATION_CONTEXTS ---------------------------------------------------------- CLIENT_CONTEXT.APPROLE=MANAGER;E2E_CONTEXT.USERNAME=PSMITH
CREATE AUDIT POLICY
文を使用して、Oracle Database Real Application Securityイベントを監査できます。
内容は次のとおりです。
関連項目:
Oracle Database Real Application Securityの詳細は、『Oracle Database Real Application Security管理者および開発者ガイド』を参照してください
Oracle Database Real Application Securityイベントを監査するには、AUDIT_ADMIN
ロールが必要です。
監査証跡にアクセスするには、Real Application Security固有の列がXS_
で始まるUNIFIED_AUDIT_TRAIL
データ・ディクショナリ・ビューを問い合せます。
Real Application Security固有のビューは次のとおりです。
DBA_XS_AUDIT_TRAIL
では、監査されたReal Application Securityイベントの詳細情報が提供されます。
DBA_XS_AUDIT_POLICY_OPTIONS
では、Real Application Securityの統合監査ポリシーに定義された監査オプションを記述します。
DBA_XS_ENB_AUDIT_POLICIES
では、Real Application Securityの統合監査ポリシーが有効なユーザーのリストを表示します。
Oracle Databaseには、CREATE USER
、UPDATE USER
など、Real Application Securityの監査可能なイベントが用意されています。
監査可能なReal Application Securityイベントのリストを検索するには、次のように、AUDITABLE_SYSTEM_ACTIONS
データ・ディクショナリ・ビューのCOMPONENT
およびNAME
列を問い合せます。
SELECT NAME FROM AUDITABLE_SYSTEM_ACTIONS WHERE COMPONENT = 'XS'; NAME ------------- CREATE USER UPDATE USER DELETE USER ...
統合監査証跡では、ユーザー、権限およびロールについてOracle Database Real Application Securityのイベントを取得できます。
表22-4では、これらのイベントについて説明します。
表22-4 Oracle Database Real Application Securityのユーザーおよびロールの監査イベント
監査イベント | 説明 |
---|---|
|
|
|
次のプロシージャを使用してOracle Database Real Application Securityのユーザー・アカウントを更新します。
|
|
|
|
|
|
次のプロシージャを使用してOracle Database Real Application Securityのロールを更新します。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
統合監査証跡では、Oracle Database Real Application Securityのセキュリティ・クラスおよびACLの監査イベントを取得できます。
表22-5では、これらのイベントについて説明します。
表22-5 Oracle Database Real Application Securityのセキュリティ・クラスおよびACLの監査イベント
監査イベント | 説明 |
---|---|
|
|
|
次のプロシージャを使用してセキュリティ・クラスを作成します。
|
|
|
|
|
|
次のプロシージャを使用してACLを更新します。
|
|
|
|
|
|
次のプロシージャを使用してデータ・セキュリティ・ポリシーを更新します。
|
|
|
|
|
|
|
統合監査証跡では、Oracle Database Real Application Securityのセッションの監査イベントを取得できます。
表22-4では、これらのイベントについて説明します。
表22-6 Oracle Database Real Application Securityのセッションの監査イベント
監査イベント | 説明 |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
次のプロシージャを使用してネームスペース属性を更新します。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
統合監査証跡では、Oracle Database Real Application SecurityのALL
イベントを取得できます。
表22-7では、これらのイベントについて説明します。
表22-7 Oracle Database Real Application SecurityのALLイベント
監査イベント | 説明 |
---|---|
|
Real Application Securityのすべてのアクションを取得します。 |
CREATE AUDIT POLICY
文で、Oracle Real Application Securityの統合監査ポリシーを作成できます。
次の構文を使用して、Oracle Database Real Application Securityの統合監査ポリシーを作成します。
CREATE AUDIT POLICY policy_name ACTIONS COMPONENT=XS component_action1 [, action2];
例:
CREATE AUDIT POLICY audit_ras_pol ACTIONS COMPONENT=XS SWITCH USER, DISABLE ROLE;
条件を含む場合など、より複雑なポリシーを作成できます。ポリシーを作成したら、AUDIT
文を使用して有効にする必要があります。
関連項目:
統合監査ポリシーの作成の構文CREATE AUDIT POLICY
文で、Real Application Securityのユーザー・アカウントの変更を監査できます。
例22-19に、ユーザーbhurst
によるユーザーの切替えとロールの無効化の試行を監査する方法を示します。
例22-19 Real Application Securityのユーザー・アカウントの変更の監査
CREATE AUDIT POLICY ras_users_pol ACTIONS COMPONENT=XS SWITCH USER, DISABLE ROLE; AUDIT POLICY ras_users_pol BY bhurst;
CREATE AUDIT POLICY
文で、Real Application Securityの統合監査ポリシーの条件を設定できます。
例22-20に、nemosity
コンピュータ・ホストからのアクションのみに監査を適用するReal Application Securityの統合監査ポリシーを作成する方法を示します。
例22-20 Real Application Securityの統合監査ポリシーでの条件の使用
CREATE AUDIT POLICY ras_acl_pol ACTIONS DELETE ON OE.CUSTOMERS ACTIONS COMPONENT=XS CREATE ACL, UPDATE ACL, DELETE ACL WHEN 'SYS_CONTEXT(''USERENV'', ''HOST'') = ''nemosity''' EVALUATE PER INSTANCE; AUDIT POLICY ras_acl_pol BY pfitch;
DBA_XS_AUDIT_TRAILデータ・ディクショナリ・ビューはOracle Real Application Securityの監査イベントを表示します。
必要に応じて、DBMS_AUDIT_MGMT.FLUSH_UNIFIIED_AUDIT_TRAIL
プロシージャを実行して、監査レコードをディスクに書き込みます。
EXEC DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL;
詳細は、「キュー書込みモードでの監査証跡への監査レコードの手動フラッシュ」を参照してください。
次の例では、Real Application Security固有のビューのDBA_XS_AUDIT_TRAIL
を問い合せます。
SELECT XS_USER_NAME FROM DBA_XS_AUDIT_TRAIL WHERE XS_ENABLED_ROLE = 'CLERK'; XS_USER_NAME ------------- USER2
CREATE AUDIT POLICY
文を使用して、Oracle Recovery Managerイベントを監査できます。
内容は次のとおりです。
関連項目:
『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』
UNIFIED_AUDIT_TRAIL
データ・ディクショナリ・ビューでは、Oracle Recovery Managerの監査イベントをRMAN_
columnに自動的に格納します。
他のOracle Databaseコンポーネントと異なり、Oracle Recovery Managerのイベントには統合監査ポリシーを作成しません。
ただし、UNIFIED_AUDIT_TRAIL
ビューを問い合せて、これらのイベントを確認するには、AUDIT_ADMIN
またはAUDIT_VIEWER
ロールが必要です。SYSBACKUP
またはSYSDBA
管理権限がない場合は、V$RMAN_STATUS
やV$RMAN_BACKUP_JOB_DETAILS
などのビューを問い合せて、Recovery Managerジョブに関する追加情報を検索できます。
関連項目:
『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』
統合監査証跡では、Oracle Recovery Managerのイベントを取得します。
表22-8では、これらのイベントについて説明します。
表22-8 UNIFIED_AUDIT_TRAILビューのOracle Recovery Manager列
Recovery Managerの列 | 説明 |
---|---|
|
Recovery Managerのセッション識別子。この列と |
|
セッションのタイムスタンプ。この列と |
|
ジョブによって実行されるRecovery Manager操作。Recovery Managerのセッション内の操作ごとに行が1つ追加されます。たとえば、バックアップ・ジョブには、 |
|
Recovery Managerのセッションに含まれるオブジェクトのタイプ。これには、次のいずれかの値が含まれます。Recovery Managerのセッションがこれらの複数を満たさない場合は、プリファレンスが次の順序(リストの上から下)で指定されます。
|
|
Recovery Managerのセッションに関連付けられているデバイス。この列は、 |
UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューはOracle Recovery Managerの監査イベントを表示します。
必要に応じて、DBMS_AUDIT_MGMT.FLUSH_UNIFIIED_AUDIT_TRAIL
プロシージャを実行して、監査レコードをディスクに書き込みます。
EXEC DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL;
詳細は、「キュー書込みモードでの監査証跡への監査レコードの手動フラッシュ」を参照してください。
表22-8に、Oracle Recovery Manager固有の監査データを検索するために問合せ可能な、
UNIFIED_AUDIT_TRAIL
データ・ディクショナリ・ビューの列を示します。
例:
SELECT RMAN_OPERATION FROM UNIFIED_AUDIT_TRAIL WHERE RMAN_OBJECT_TYPE = 'DB FULL'; RMAN_OPERATION --------------- BACKUP
Oracle Database Vault環境で、CREATE AUDIT POLICY
文を使用してDatabase Vaultアクティビティを監査できます。
内容は次のとおりです。
関連項目:
Oracle Database Vaultの監査ポリシーの詳細は、『Oracle Database Vault管理者ガイド』を参照してください
すべての統合監査と同様、Oracle Database Vaultのイベントを監査するには、AUDIT_ADMIN
ロールが必要です。
Oracle Database Vaultの統合監査ポリシーを作成するには、CREATE AUDIT POLICY
文のCOMPONENT
句をDV
に設定し、Rule Set Failure
などのアクションおよびルール・セットの名前などのオブジェクトを指定します。
監査証跡にアクセスする場合は、次のビューを問い合せることができます。
UNIFIED_AUDIT_TRAIL
SYS.DV$CONFIGURATION_AUDIT
SYS.DV$ENFORCEMENT_AUDIT
UNIFIED_AUDIT_TRAIL
ビューでは、Oracle Database Vault固有の列はDV_
で始まります。UNIFIED_AUDIT_TRAIL
ビューを問い合せるには、AUDIT_VIEWER
ロールが必要です。
これらのビューに加えて、Database Vaultレポートでは、Database Vault固有の統合監査ポリシーの結果も取得します。
関連項目:
Oracle Database Vaultの監査ポリシーの詳細は、『Oracle Database Vault管理者ガイド』を参照してください。
Oracle Database Vaultの監査対象ユーザーには、Database Vault管理者、およびアクティビティがDatabase Vaultの規定ポリシーに影響するユーザーが含まれます。
これらのユーザーは次のとおりです。
Database Vault管理者。Oracle Database Vaultに対して行われるすべての構成変更は、強制的に監査されます。監査では、レルム、ファクタ、コマンド・ルール、ルール・セット、ルールなどの作成、変更、削除などのアクティビティを取得します。SYS.DV$CONFIGURATION_AUDIT
データ・ディクショナリ・ビューでは、Database Vault管理者によって実行された構成変更を取得します。
アクティビティがOracle Database Vaultの規定ポリシーに影響するユーザー。SYS.DV$ENFORCEMENT_AUDIT
データ・ディクショナリ・ビューでは、規定関連の監査を取得します。
関連項目:
SYS.DV$CONFIGURATION_AUDIT
およびSYS.DV$ENFORCEMENT_AUDIT
データ・ディクショナリ・ビューの詳細は、Oracle Database Vault管理者ガイドを参照してください
Oracle Database Vault環境の監査証跡は、すべての構成変更やDatabase Vaultポリシーの変更の試行を取得します。
これは、既存のDatabase Vaultのポリシーに対するユーザーの違反も取得します。
次の種類のOracle Database Vaultイベントを監査できます。
Oracle Database Vaultのポリシーに対するすべての構成変更または変更の試行。Database Vault管理者による変更および権限のないユーザーによる試行の両方が取得されます。
既存のDatabase Vaultのポリシーに対するユーザーの違反。たとえば、ユーザーが作業時間以外に特定のスキーマ表にアクセスできないようにするポリシーを作成すると、監査証跡によって、このアクティビティが取得されます。
統合監査証跡によってOracle Database Vaultのレルムのイベントが取得されます。
表22-9では、これらのイベントについて説明します。
表22-9 Oracle Database Vaultのレルムの監査イベント
監査イベント | 説明 |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
統合監査証跡では、Oracle Database Vaultのルール・セットおよびルールの監査イベントを取得できます。
表22-10では、これらのイベントについて説明します。
表22-10 Oracle Database Vaultのルール・セットおよびルールの監査イベント
監査イベント | 説明 |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
統合監査証跡では、Oracle Database Vaultのコマンド・ルールの監査イベントを取得できます。
表22-11では、これらのイベントについて説明します。
表22-11 Oracle Database Vaultのコマンド・ルールの監査イベント
監査イベント | 説明 |
---|---|
|
|
|
|
|
|
統合監査証跡では、Oracle Database Vaultのファクタ・イベントを取得できます。
表22-12では、これらのイベントについて説明します。
表22-12 Oracle Database Vaultのファクタの監査イベント
監査イベント | 説明 |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
統合監査証跡では、Oracle Database Vaultのセキュア・アプリケーション・ロールの監査イベントを取得できます。
表22-13では、これらのイベントについて説明します。
表22-13 Oracle Database Vaultのセキュア・アプリケーション・ロールの監査イベント
監査イベント | 説明 |
---|---|
|
|
|
|
|
|
|
|
統合監査証跡では、Oracle Database Vault Oracle Label Securityの監査イベントを取得できます。
表22-14では、これらのイベントについて説明します。
表22-14 Oracle Database Vault Oracle Label Securityの監査イベント
監査イベント | 説明 |
---|---|
|
|
|
|
|
|
|
|
|
|
統合監査証跡では、Oracle Database Vault Oracle Data Pumpの監査イベントを取得できます。
表22-15では、これらのイベントについて説明します。
表22-15 Oracle Database Vault Oracle Data Pumpの監査イベント
監査イベント | 説明 |
---|---|
|
|
|
|
統合監査証跡では、Oracle Database Vaultの有効および無効な監査イベントを取得できます。
表22-16では、これらのイベントについて説明します。
表22-16 Oracle Database Vaultの有効および無効な監査イベント
イベント | 説明 |
---|---|
|
|
|
|
CREATE AUDIT POLICY
文のACTIONS
およびACTIONS COMPONENT
句で、Oracle Database Vaultイベントの統合監査ポリシーを作成できます。
次の構文を使用して、Oracle Database Vaultの統合監査ポリシーを作成します。
CREATE AUDIT POLICY policy_name ACTIONS action1 [,action2 ] ACTIONS COMPONENT= DV DV_action ON DV_object [,DV_action2 ON DV_object2]
次のように値を指定します。
DV_action
は次のいずれかになります。
Realm Violation
、Realm Success
、Realm Access
Rule Set Failure
、Rule Set Success
、Rule Set Eval
Factor Error
、Factor Null
、Factor Validate Error
、Factor Validate False
、Factor Trust Level Null
、Factor Trust Level Neg
、Factor All
DV_objects
は次のいずれかになります。
Realm_Name
Rule_Set_Name
Factor_Name
オブジェクトが小文字または大/小文字が混在して作成された場合は、DV_objects
を二重引用符で囲みます。オブジェクトをすべて大文字で作成した場合は、引用符を省略できます。
たとえば、Database Vaultアカウント管理レルムのレルム違反を監査するには、次のようにします。
CREATE AUDIT POLICY audit_dv ACTIONS CREATE TABLE, SELECT ACTIONS COMPONENT=DV Realm Violation ON "Database Vault Account Management";
条件を含む場合など、より複雑なポリシーを作成できます。ポリシーを作成したら、AUDIT
文を使用して有効にする必要があります。
CREATE AUDIT POLICY
文で、複数のOracle Database Vaultイベントを監査できます。
例22-21に、レルム違反およびルール・セット失敗の監査方法を示します。
例22-21 2つのOracle Database Vaultイベントの監査
CREATE AUDIT POLICY audit_dv ACTIONS CREATE TABLE, SELECT ACTIONS COMPONENT=DV REALM VIOLATION ON "Oracle Enterprise Manager", Rule Set Failure ON "Allow Sessions"; AUDIT POLICY audit_dv EXCEPT psmith;
CREATE AUDIT POLICY
文で、Oracle Database Vaultのファクタを監査できます。
例22-22に、1つのファクタで2つのタイプのエラーを監査する方法を示します。
例22-22 Oracle Database Vaultのファクタ設定の監査
CREATE AUDIT POLICY audit_dv_factor ACTIONS COMPONENT=DV FACTOR ERROR ON "Database_Domain", Factor Validate Error ON "Client_IP"; AUDIT POLICY audit_dv_factor;
UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューはOracle Database Vaultの監査イベントを表示します。
必要に応じて、DBMS_AUDIT_MGMT.FLUSH_UNIFIIED_AUDIT_TRAIL
プロシージャを実行して、監査レコードをディスクに書き込みます。
EXEC DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL;
詳細は、「キュー書込みモードでの監査証跡への監査レコードの手動フラッシュ」を参照してください。
UNIFIED_AUDIT_TRAIL
ビューのDV_
*列は、Oracle Database Vault固有の監査データを示します。
例:
SELECT DV_RULE_SET_NAME FROM UNIFIED_AUDIT_TRAIL WHERE ACTION_NAME = 'UPDATE'; DV_RULE_SET_NAME ----------------------- Allow System Parameters
Oracle Label Securityが有効な場合、CREATE AUDIT POLICY
文を使用してOracle Label Securityイベントを監査できます。
内容は次のとおりです。
関連項目:
Oracle Label Securityのデータ・ディクショナリ・ビューの詳細は、『Oracle Label Security管理者ガイド』を参照してください。Oracle Label Security (OLS)のイベントを監査するには、AUDIT_ADMIN
ロールが必要です。
Oracle Label Securityの統合監査ポリシーを作成するには、CREATE AUDIT POLICY
文のCOMPONENT
句をOLS
に設定する必要があります。
ユーザー・セッション情報を監査するには、AUDIT
文を使用して、アプリケーション・コンテキスト値を監査します。
監査証跡にアクセスするには、UNIFIED_AUDIT_TRAIL
データ・ディクショナリ・ビューを問い合せます。このビューには、名前がOLS_
で始まるOracle Label Security固有の列が含まれます。
統合監査証跡では、Oracle Label Securityの監査イベントを取得できます。
監査可能なOracle Label Securityのイベントのリストを検索するには、次のように、AUDITABLE_SYSTEM_ACTIONS
データ・ディクショナリ・ビューのCOMPONENT
列およびNAME
列を問い合せます。
例:
SELECT NAME FROM AUDITABLE_SYSTEM_ACTIONS WHERE COMPONENT = 'Label Security'; NAME ------------- CREATE POLICY ALTER POLICY DROP POLICY ...
表22-17に、Oracle Label Securityの監査イベントを示します。
表22-17 Oracle Label Securityの監査イベント
監査イベント | 説明 |
---|---|
|
|
|
|
|
|
|
|
|
|
|
Oracle Label Securityの権限を含むOracle Label Securityのすべての認可を含み、ユーザーまたは信頼できるストアド・プロシージャのいずれかにラベルを使用します。 |
|
Oracle Label Securityの権限のユーザーを必要とするアクションを含みます。これらのアクションは、ログオン、 |
|
次のプロシージャを使用して、Oracle Label Securityのポリシーを有効にします。
|
|
次のプロシージャを使用して、Oracle Label Securityのポリシーを無効にします。
|
|
|
|
|
|
|
|
|
|
|
|
次のプロシージャを使用して、Oracle Label Securityのコンポーネントを作成します。
|
|
次のプロシージャを使用して、Oracle Label Securityのコンポーネントを変更します。
|
|
次のプロシージャを使用して、Oracle Label Securityのコンポーネントを削除します。
|
|
Oracle Label Securityのすべてのアクションの監査を有効にします。 |
ORA_OLS_SESSION_LABELS
アプリケーション・コンテキストで、各Oracle Databaseイベントのユーザー・セッション・ラベルの使用状況を取得できます。
このアプリケーション・コンテキストで使用される属性は、Oracle Label Securityのポリシーを示します。
構文は、アプリケーション・コンテキストの監査設定の構成で説明されているアプリケーション・コンテキストの監査に使用される構文と同じです。次に例を示します。
AUDIT CONTEXT NAMESPACE ORA_SESSION_LABELS ATTRIBUTES policy1, policy2;
セッション・ラベルの記録はユーザー・セッション固有ではないため、BY
user_list
句は、Oracle Label Securityのアプリケーション・コンテキストには不要です。
ユーザー・セッション・ラベル情報の監査を無効にするには、NOAUDIT
文を使用します。たとえば、ポリシーpolicy1
およびpolicy2
の監査を停止するには、次の文を入力します。
NOAUDIT CONTEXT NAMESPACE ORA_SESSION_LABELS ATTRIBUTES policy1, policy2;
CREATE AUDIT POLICY
文のACTIONS
およびACTIONS COMPONENT
句を使用して、Oracle Label Securityイベントの監査ポリシーを作成できます。
次の構文を使用して、Oracle Label Securityの統合監査ポリシーを作成します。
CREATE AUDIT POLICY policy_name ACTIONS action1 [,action2 ] ACTIONS COMPONENT=OLS component_action1 [, action2];
例:
CREATE AUDIT POLICY audit_ols ACTIONS SELECT ON OE.ORDERS ACTIONS COMPONENT=OLS ALL;
条件を含む場合など、より複雑なポリシーを作成できます。ポリシーを作成したら、AUDIT
文を使用して有効にする必要があります。
関連項目:
統合監査ポリシーの作成の構文AUDIT CONTEXT NAMESPACE
文で、Oracle Label Securityのセッション・ラベル属性を監査できます。
例22-23に、Oracle Label Securityのポリシーusr_pol1
およびusr_pol2
のORA_OLS_SESSION_LABELS
アプリケーション・コンテキスト属性を監査する方法を示します。
例22-23 Oracle Label Securityのセッション・ラベル属性の監査
AUDIT CONTEXT NAMESPACE ORA_SESSION_LABELS ATTRIBUTES usr_pol1, usr_pol2;
CREATE AUDIT POLICY
文で、ポリシーからユーザーを除外できます。
例22-24に、ユーザーols_mgr
からアクションを除外する統合監査ポリシーを作成する方法を示します。
例22-24 Oracle Label Securityポリシーからのユーザーの除外
CREATE AUDIT POLICY auth_ols_audit_pol ACTIONS SELECT ON HR.EMPLOYEES ACTIONS COMPONENT=OLS DROP POLICY, DISABLE POLICY; AUDIT POLICY auth_ols_audit_pol EXCEPT ols_mgr;
CREATE AUDIT POLICY
文で、Oracle Label Securityのポリシー・アクションを監査できます。
例22-25に、DROP POLICY
、DISABLE POLICY
、UNSUBSCRIBE OID
イベント、およびHR.EMPLOYEES
表のUPDATE
およびDELETE
文を監査する方法を示します。次に、ポリシーがHR
およびLBACSYS
ユーザーに適用され、監査アクションが成功すると、監査レコードが統合監査証跡に書き込まれます。
例22-25 Oracle Label Securityのポリシー・アクションの監査
CREATE AUDIT POLICY generic_audit_pol ACTIONS UPDATE ON HR.EMPLOYEES, DELETE ON HR.EMPLOYEES ACTIONS COMPONENT=OLS DROP POLICY, DISABLE POLICY, UNSUBSCRIBE OID; AUDIT POLICY generic_audit_pol BY HR, LBACSYS WHENEVER SUCCESSFUL;
UNIFIED_AUDIT_TRAIL問合せでLBACSYS.ORA_GET_AUDITED_LABEL
関数を使用して、監査済Oracle Label Securityセッション・ラベルを確認できます。
例22-26に、UNIFIED_AUDIT_TRAIL
データ・ディクショナリ・ビューの問合せでLBACSYS.ORA_GET_AUDITED_LABEL
ファンクションを使用する方法を示します。
例22-26 監査対象のOracle Label Securityセッション・ラベルの問合せ
SELECT ENTRY_ID, SESSIONID, LBACSYS.ORA_GET_AUDITED_LABEL( APPLICATION_CONTEXTS,'GENERIC_AUDIT_POL1') AS SESSION_LABEL1, LBACSYS.ORA_GET_AUDITED_LABEL( APPLICATION_CONTEXTS,'GENERIC_AUDIT_POL2') AS SESSION_LABEL2 FROM UNIFIED_AUDIT_TRAIL; / ENTRY_ID SESSIONID SESSION_LABEL1 SESSION_LABEL2 -------- --------- -------------- -------------- 1 1023 SECRET LEVEL_ALPHA 2 1024 TOP_SECRET LEVEL_BETA
UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューはOracle Label Securityの監査イベントを表示します。
必要に応じて、DBMS_AUDIT_MGMT.FLUSH_UNIFIIED_AUDIT_TRAIL
プロシージャを実行して、監査レコードをディスクに書き込みます。
EXEC DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL;
詳細は、「キュー書込みモードでの監査証跡への監査レコードの手動フラッシュ」を参照してください。
UNIFIED_AUDIT_TRAILビューのOLS_*
列は、Oracle Label Security固有の監査データを示します。次に例を示します。
SELECT OLS_PRIVILEGES_USED FROM UNIFIED_AUDIT_TRAIL WHERE DBUSERNAME = 'psmith'; OLS_PRIVILEGES_USED ------------------- READ WRITEUP WRITEACROSS
監査証跡で取得されるセッション・ラベルは、UNIFIED_AUDIT_TRAIL
ビューのAPPLICATION_CONTEXTS
列に格納されます。LBACSYS.ORA_GET_AUDITED_LABEL
ファンクションを使用して、APPLICATION_CONTEXTS
列に格納されているセッション・ラベルを取得できます。このファンクションは、UNIFIED_AUDIT_TRAIL.APPLICATION_CONTEXTS
列値、およびOracle Label Securityポリシー名を引数として受け入れ、指定したポリシーの列に格納されているセッション・ラベルを返します。
関連項目:
ORA_GET_AUDITED_LABEL
ファンクションの詳細は、『Oracle Label Security管理者ガイド』を参照してください。
CREATE AUDIT POLICY
文を使用して、Oracle Data Miningイベントを監査できます。
内容は次のとおりです。
Oracle Data Miningイベントを監査するには、AUDIT_ADMIN
ロールが必要です。
監査証跡にアクセスするには、UNIFIED_AUDIT_TRAIL
データ・ディクショナリ・ビューを問い合せます。
関連項目:
Oracle Data Miningの詳細は、『Oracle Data Mining概要』を参照してください。
統合監査証跡では、Oracle Data Miningの監査イベントを取得できます。
表22-18では、これらのイベントについて説明します。
表22-18 Oracle Data Miningの監査イベント
監査イベント | 説明 |
---|---|
|
データ・マイニング・モデルの監査レコードを生成します。 |
|
データ・マイニング・モデルにコメントを追加します。 |
|
データ・マイニング・モデルへのアクセス権をユーザーに付与します。 |
|
データ・マイニング・モデルの名前を変更します。 |
|
データ・マイニング・モデルを適用またはその署名を表示します。 |
CREATE AUDIT POLICY
文のACTIONS
およびON MINING MODEL
句を使用して、Oracle Data Miningイベントの統合監査ポリシーを作成できます。
次の構文を使用して、Oracle Data Miningの統合監査ポリシーを作成します。
CREATE AUDIT POLICY policy_name ACTIONS {operation | ALL} ON MINING MODEL schema_name.model_name;
例:
CREATE AUDIT POLICY dm_ops ACTIONS RENAME ON MINING MODEL hr.dm_emp;
条件を含む場合など、より複雑なポリシーを作成できます。ポリシーを作成したら、AUDIT
文を使用して有効にする必要があります。
関連トピック
CREATE AUDIT POLICY
文で、複数のOracle Data Mining操作を監査できます。
例22-27に、ユーザーpsmith
による複数のOracle Data Mining操作を監査する方法を示します。イベントごとにON MINING MODEL
schema_name.model_name
句を含み、それぞれカンマで区切ります。この例では、両方のアクションで同じschema_name.model name
を指定しますが、スキーマおよびデータ・モデルごとに異なるschema_name.model_name
設定を構文で指定できます。
例22-27 ユーザーによる複数のOracle Data Mining操作の監査
CREATE AUDIT POLICY dm_ops_pol ACTIONS SELECT ON MINING MODEL dmuser1.nb_model, ALTER ON MINING MODEL dmuser1.nb_model; AUDIT POLICY dm_ops_pol BY psmith;
CREATE AUDIT POLICY
文で、ユーザーによる失敗したOracle Data Miningの操作を監査できます。
例22-28に、ユーザーpsmith
による失敗したすべてのOracle Data Mining操作を監査する方法を示します。
例22-28 ユーザーによる失敗したすべてのOracle Data Mining操作の監査
CREATE AUDIT POLICY dm_all_ops_pol ACTIONS ALL ON MINING MODEL dmuser1.nb_model; AUDIT POLICY dm_all_ops_pol BY psmith WHENEVER NOT SUCCESSFUL;
UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューはOracle Data Miningの監査イベントを表示します。
必要に応じて、DBMS_AUDIT_MGMT.FLUSH_UNIFIIED_AUDIT_TRAIL
プロシージャを実行して、監査レコードをディスクに書き込みます。
EXEC DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL;
詳細は、「キュー書込みモードでの監査証跡への監査レコードの手動フラッシュ」を参照してください。
次の例に、UNIFIED_AUDIT_TRAIL
データ・ディクショナリ・ビューを問い合せて、データ・マイニングの監査イベントを確認する方法を示します。
SELECT DBUSERNAME, ACTION_NAME, SYSTEM_PRIVILEGE_USED, RETURN_CODE, OBJECT_SCHEMA, OBJECT_NAME, SQL_TEXT FROM UNIFIED_AUDIT_TRAIL; DBUSERNAME ACTION_NAME SYSTEM_PRIVILEGE_USED RETURN_CODE ---------- -------------------- ------------------------- ----------- OBJECT_SCHEMA OBJECT_NAME -------------------- -------------------- SQL_TEXT -------------------------------------------------------------------------------- DMUSER1 CREATE MINING MODEL CREATE MINING MODEL 0 DMUSER1 BEGIN dbms_data_mining.create_model(model_name => 'nb_model', mining_function => dbms_data_mining.classification, data_table_name => 'dm_data', case_id_column_name => 'case_id', target_column_name => 'target'); END; DMUSER1 SELECT MINING MODEL 0 DMUSER1 NB_MODEL select prediction(nb_model using *) from dual DMUSER2 SELECT MINING MODEL 40284 DMUSER1 NB_MODEL select prediction(dmuser1.nb_model using *) from dual DMUSER1 ALTER MINING MODEL 0 DMUSER1 NB_MODEL BEGIN dbms_data_mining.rename_model('nb_model', 'nb_model1'); END; DMUSER2 ALTER MINING MODEL 40284 DMUSER1 NB_MODEL BEGIN dbms_data_mining.rename_model('dmuser1.nb_model1', 'nb_model'); END; DMUSER2 ALTER MINING MODEL 40284 DMUSER1 NB_MODEL BEGIN dbms_data_mining.rename_model('dmuser1.nb_model1', 'nb_model'); END;
CREATE AUDIT POLICY
文を使用して、Oracle Data Pumpを監査できます。
内容は次のとおりです。
Oracle Data Pumpの統合監査ポリシーを作成するには、CREATE AUDIT POLICY
文のCOMPONENT
句をDATAPUMP
に設定する必要があります。
Data Pumpのエクスポート(expdp
)およびインポート(impdp
)操作を監査できます。
すべての統合監査と同様、Oracle Data Pumpのイベントを監査するには、AUDIT_ADMIN
ロールが必要です。
監査証跡にアクセスするには、UNIFIED_AUDIT_TRAIL
データ・ディクショナリ・ビューを問い合せます。このビューのData Pump固有の列はDP_
で始まります。
関連項目:
Oracle Data Pumpの詳細は、『Oracle Databaseユーティリティ』を参照してください。
統合監査証跡によってOracle Data Pumpのイベントを取得できます。
統合監査証跡では、エクスポート(expdp
)およびインポート(impdp
)の両方の操作に関する情報を取得します。
CREATE AUDIT POLICY
文のACTIONS COMPONENT
句を使用して、Oracle Data Pumpイベントの統合監査ポリシーを作成できます。
次の構文を使用して、Oracle Data Pumpの統合監査ポリシーを作成します。
CREATE AUDIT POLICY policy_name
ACTIONS COMPONENT=DATAPUMP { EXPORT | IMPORT | ALL };
例:
CREATE AUDIT POLICY audit_dp_export_pol ACTIONS COMPONENT=DATAPUMP EXPORT;
条件を含む場合など、より複雑なポリシーを作成できます。ポリシーを作成したら、AUDIT
文を使用して有効にする必要があります。
関連項目:
統合監査ポリシーの作成の構文CREATE AUDIT POLICY
文で、Oracle Data Pumpのインポート操作を監査できます。
例22-29に、Oracle Data Pumpのすべてのインポート操作を監査する方法を示します。
例22-29 Oracle Data Pumpのインポート操作の監査
CREATE AUDIT POLICY audit_dp_import_pol ACTIONS COMPONENT=DATAPUMP IMPORT; AUDIT POLICY audit_dp_import_pol;
CREATE AUDIT POLICY
文で、Oracle Data Pumpのすべての操作を監査できます。
例22-30に、Oracle Database Pumpのエクスポートおよびインポートの両方の操作を監査する方法を示します。
例22-30 Oracle Data Pumpのすべての操作の監査
CREATE AUDIT POLICY audit_dp_all_pol ACTIONS COMPONENT=DATAPUMP ALL; AUDIT POLICY audit_dp_all_pol BY SYSTEM;
UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューはOracle Data Pumpの監査イベントを表示します。
必要に応じて、DBMS_AUDIT_MGMT.FLUSH_UNIFIIED_AUDIT_TRAIL
プロシージャを実行して、監査レコードをディスクに書き込みます。
EXEC DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL;
詳細は、「キュー書込みモードでの監査証跡への監査レコードの手動フラッシュ」を参照してください。
UNIFIED_AUDIT_TRAIL
ビューのDP_*
列は、Oracle Data Pump固有の監査データを示します。次に例を示します。
SELECT DP_TEXT_PARAMETERS1, DP_BOOLEAN_PARAMETERS1 FROM UNIFIED_AUDIT_TRAIL WHERE AUDIT_TYPE = 'DATAPUMP'; DP_TEXT_PARAMETERS1 DP_BOOLEAN_PARAMETERS1 ---------------------------------------------- ---------------------------------- MASTER TABLE: "SCOTT"."SYS_EXPORT_TABLE_01", MASTER_ONLY: FALSE, JOB_TYPE: EXPORT, DATA_ONLY: FALSE, METADATA_JOB_MODE: TABLE_EXPORT, METADATA_ONLY: FALSE, JOB VERSION: 12.1.0.0, DUMPFILE_PRESENT: TRUE, ACCESS METHOD: DIRECT_PATH, JOB_RESTARTED: FALSE DATA OPTIONS: 0, DUMPER DIRECTORY: NULL REMOTE LINK: NULL, TABLE EXISTS: NULL, PARTITION OPTIONS: NONE
(この出力は、読みやすくするために変更が加えられています。)
CREATE AUDIT POLICY
文を使用して、Oracle SQL*Loaderダイレクト・ロード・パス・イベントを監査できます。
内容は次のとおりです。
Oracle SQL*Loaderダイレクト・パス・イベントを監査するには、AUDIT_ADMIN
ロールが必要です。
SQL*Loaderの統合監査ポリシーを作成するには、CREATE AUDIT POLICY
文のCOMPONENT
句をDIRECT_LOAD
に設定する必要があります。監査できるのは、従来のパス・ロードなどの他のSQL*Loaderロードではなく、ダイレクト・パス・ロードのみです。
監査証跡にアクセスするには、UNIFIED_AUDIT_TRAIL
データ・ディクショナリ・ビューのDIRECT_PATH_NUM_COLUMNS_LOADED
列を問い合せます。
関連項目:
Oracle SQL*Loaderの詳細は、『Oracle Databaseユーティリティ』を参照してください。
統合監査証跡によってSQL*Loaderダイレクト・ロード・パスのイベントを取得できます。
統合監査証跡では、SQL*Loaderで実行されるダイレクト・パス・ロードに関する情報を取得します(SQL*LoaderのコマンドラインまたはSQL*Loaderの制御ファイルでdirect=true
に設定した場合)。
また、ダイレクト・パスAPIを使用するOracle Call Interface (OCI)プログラムも監査します。
関連項目:
Oracle SQL*Loaderのダイレクト・パス・ロードの詳細は、『Oracle Databaseユーティリティ』を参照してください。
CREATE AUDIT POLICY
文のACTIONS COMPONENT
句では、Oracle SQL*Loaderダイレクト・パス・イベントの統合監査ポリシーを作成できます。
次の構文を使用して、Oracle SQL*Loaderの統合監査ポリシーを作成します。
CREATE AUDIT POLICY policy_name
ACTIONS COMPONENT=DIRECT_LOAD { LOAD };
例:
CREATE AUDIT POLICY audit_sqlldr_pol ACTIONS COMPONENT=DIRECT_LOAD LOAD;
条件を含む場合など、より複雑なポリシーを作成できます。ポリシーを作成したら、AUDIT
文を使用して有効にする必要があります。
関連項目:
統合監査ポリシーの作成の構文CREATE AUDIT POLICY
文で、Oracle SQL*Loaderダイレクト・パス・ロード操作を監査できます。
例22-29に、SQL*Loaderダイレクト・パス・ロード操作を監査する方法を示します。
例22-31 Oracle SQL*Loaderダイレクト・パス・ロード操作の監査
CREATE AUDIT POLICY audit_sqlldr_load_pol ACTIONS COMPONENT=DIRECT_LOAD LOAD; AUDIT POLICY audit_sqlldr_load_pol;
UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューはSQL*Loaderダイレクト・パス・ロードの監査イベントを表示します。
必要に応じて、DBMS_AUDIT_MGMT.FLUSH_UNIFIIED_AUDIT_TRAIL
プロシージャを実行して、監査レコードをディスクに書き込みます
詳細は、「キュー書込みモードでの監査証跡への監査レコードの手動フラッシュ」を参照してください。
UNIFIED_AUDIT_TRAIL
ビューのDIRECT_PATH_NUM_COLUMNS_LOADED
列は、SQL*Loaderダイレクト・パス・ロード・メソッドを使用してロードされた列の数を示します。次に例を示します。
SELECT DBUSERNAME, ACTION_NAME, OBJECT_SCHEMA, OBJECT_NAME, DIRECT_PATH_NUM_COLUMNS_LOADED FROM UNIFIED_AUDIT_TRAIL WHERE AUDIT_TYPE = 'DIRECT PATH API'; DBUSERNAME ACTION_NAME OBJECT_SCHEMA OBJECT_NAME DIRECT_PATH_NUM_COLUMNS_LOADED ----------- ----------- ------------- ------------ ------------------------------ RLAYTON INSERT HR EMPLOYEES 4
マルチテナント環境では、ルートとPDBの両方に統合監査ポリシーを作成できます。
内容は次のとおりです。
関連項目:
マルチテナント環境での一般的な監査構成の詳細は、『Oracle Database概要』を参照してください。
ローカル監査ポリシーまたはCDB共通監査ポリシーである監査ポリシー。
ローカル監査ポリシー。このタイプのポリシーは、ルートまたはPDBに存在します。ルートに存在するローカル監査ポリシーには、ローカル・オブジェクトと共通オブジェクトの両方用のオブジェクト監査オプションを含めることができます。AUDIT_ADMIN
ロールが付与されているローカル・ユーザーおよび共通ユーザーは、両方ともローカル・ポリシーを有効にできます(ローカル・ユーザーはPDBから、共通ユーザーは権限のあるルートまたはPDBから有効にできます)。ルートに接続している場合は、オブジェクト監査オプションを指定できますが、権限またはロールの監査オプションは指定できません。
共通監査ポリシー。このタイプのポリシーは、マルチテナント環境のすべてのPDBに使用できます。共通監査ポリシーを作成および保持できるのは、AUDIT_ADMIN
ロールが付与されている共通ユーザーのみです。共通監査ポリシーは、共通ユーザーのみに対して有効にできます。共通監査ポリシーは、ルートにのみ作成する必要があります。このタイプのポリシーには、共通オブジェクトのみのオブジェクト監査オプションを含めることができ、共通ユーザーのみに対して有効にできます。
デフォルトでは、監査ポリシーは現在のPDBにローカルです。
従来型の監査(統合監査ではない)では、AUDIT
およびNOAUDIT
文で、マルチテナント環境の文と権限を監査できます。
ローカル監査ポリシーまたは共通監査ポリシーになるように監査ポリシーを構成するには、作成または変更の他のSQL文に対して一般的に行うように、CONTAINER
句を含める必要があります。監査レコードは、アクションを実行するコンテナに作成されることになります。
AUDIT
またはNOAUDIT
文を現在のPDBに適用する場合は、PDBでCONTAINER
をCURRENT
に設定する必要があります。次に例を示します。
AUDIT DROP ANY TABLE BY SYSTEM BY ACCESS CONTAINER = CURRENT;
AUDIT
またはNOAUDIT
文をマルチテナント環境全体に適用する場合は、ルートでCONTAINER
をALL
に設定する必要があります。次に例を示します。
AUDIT DROP ANY TABLE BY SYSTEM BY ACCESS CONTAINER = ALL;
関連項目:
従来のAUDIT
およびNOAUDIT
SQL文の詳細は、Oracle Database SQL言語リファレンスを参照してください
CONTAINER
句の使用はマルチテナント環境限定で、CREATE AUDIT POLICY
文で使用します。
次の構文を使用して、ローカル統合監査ポリシーまたは共通統合監査ポリシーを作成します。
CREATE AUDIT POLICY policy_name action1 [,action2 ] [CONTAINER = {CURRENT | ALL}];
次のように値を指定します。
CURRENT
は、監査ポリシーを現在のPDBにローカルになるように設定します。
ALL
は、監査ポリシーを共通監査ポリシー(マルチテナント環境全体で使用可能にする)にします。
たとえば、共通統合監査ポリシーの場合は次のようになります。
CREATE AUDIT POLICY dict_updates ACTIONS UPDATE ON SYS.USER$, DELETE ON SYS.USER$, UPDATE ON SYS.LINK$, DELETE ON SYS.LINK$ CONTAINER = ALL;
次のことに注意してください。
統合監査ポリシーの場合は、ALTER AUDIT POLICY
またはDROP AUDIT POLICY
ではなく、CREATE AUDIT POLICY
文にCONTAINER
句を設定できます。この設定を使用するように既存の統合監査ポリシーの範囲を変更する場合は、ポリシーを削除してから再作成します。
AUDIT
文の場合は、リリース12.x
の監査機能にまだ移行していないOracleデータベースがある場合など、監査設定のみにCONTAINER句を設定します。統合監査ポリシーを有効にするために使用するAUDIT
文には、CONTAINER
句を使用できません。
PDBにいる場合、CONTAINER
句に設定できるのはALL
ではなくCURRENT
のみです。PDBにいる場合に設定を省略すると、デフォルトはCONTAINER = CURRENT
になります。
ルートにいる場合は、CONTAINER
句を、ポリシーをルートのみに適用する場合はCURRENT
に、ポリシーをCDB全体に適用する場合はALL
に設定できます。CONTAINER
句を省略すると、デフォルトはCONTAINER = COMMON
になります。
オブジェクトの場合:
共通監査ポリシーには共通オブジェクトのみ、ローカル監査ポリシーにはローカル・オブジェクトのみを含めることができます。
関係するオブジェクトがローカルの場合は、CONTAINER
をALL
に設定することはできません。共通オブジェクトにする必要があります。
権限の場合:
関係するユーザー・アカウントがローカル・アカウントと共通アカウントの混在の場合は、CONTAINER
をCURRENT
に設定(またはCONTAINER
句を省略)できます。これにより、現在のPDBのみに適用されるローカル監査構成が作成されます。
関係するユーザーがローカル・ユーザーの場合は、CONTAINER
をALL
に設定することはできません。共通ユーザーにする必要があります。
CONTAINER
をALL
に設定し、ユーザー・リストを指定しない場合(BY
句をAUDIT
文に使用)、構成が各PDBのすべての共通ユーザーに適用されます。
CREATE AUDIT POLICY文で、ルートまたはPDBにローカル統合監査ポリシーを作成できます。
ルートでローカル統合監査ポリシーを作成すると、マルチテナント環境全体ではなく、ルートにのみ適用されます。
例22-32に、共通ユーザーc##sec_admin
によってPDBから作成され、共通ユーザーc##hr_admin
に適用されているローカル統合監査ポリシーを示します。
例22-32 ローカル統合監査ポリシー
CONNECT c##sec_admin@hrpdb
Enter password: password
Connected.
CREATE AUDIT POLICY table_privs
PRIVILEGES CREATE ANY TABLE, DROP ANY TABLE
CONTAINER = CURRENT;
AUDIT POLICY table_privs BY c##hr_admin;
CREATE AUDIT POLICY文で、CDB共通統合監査ポリシーを作成できます。
例22-33に、共通ユーザーc##sec_admin
によってルートから作成され、共通ユーザーc##hr_admin
に適用されている共通統合監査ポリシーを示します。
例22-33 共通統合監査ポリシー
CONNECT c##sec_admin
Enter password: password
Connected.
CREATE AUDIT POLICY admin_pol
ACTIONS CREATE TABLE, ALTER TABLE, DROP TABLE
ROLES c##hr_mgr, c##hr_sup
CONTAINER = ALL;
AUDIT POLICY admin_pol BY c##hr_admin;
ルートまたはアクションが発生したPDBから、統合監査ポリシー・ビューを問い合せることができます。
次のタイプの問合せを実行できます。
すべてのPDBからのレコードを監査する。監査証跡には、PDBで実行された監査アクションが反映されます。たとえば、PDB1
のユーザーlbrown
が、共通監査ポリシーまたはローカル監査ポリシーのいずれかによって監査されたアクションを実行すると、監査証跡によってこのアクションが取得されます。UNIFIED_AUDIT_TRAIL
データ・ディクショナリ・ビューのDBID
列は、監査アクションが実行され、ポリシーが適用されるPDBを示します。すべてのPDBからの監査レコードを確認する場合は、ルートからCDB_UNIFIED_AUDIT_TRAIL
データ・ディクショナリ・ビューを問い合せる必要があります。
共通監査ポリシーからのレコードを監査する。この場所は、共通監査ポリシーが監査レコードになる場所です。アクションが実際に発生した場所に応じて、マルチテナント環境(ルートまたはPDB)の任意の場所で監査レコードを生成できます。たとえば、共通監査ポリシーfga_pol
は、DBMS_FGA
PL/SQLパッケージのEXECUTE
権限を監査し、このアクションがPDB1
で発生すると、監査レコードはルートではなく、PDB1
に生成されます。このため、監査レコードはPDB1に表示できます。
PDBポリシー名にWHERE
句を使用している場合は(例: WHERE UNIFIED_AUDIT_POLICIES = 'FGA_POL'
)、ポリシーについて、ルートまたはPDBのいずれかからUNIFIED_AUDIT_TRAIL
データ・ディクショナリ・ビューを問い合せることができます。
次の例は、共通統合監査ポリシーの結果を検索する方法を示します。
CONNECT c##sec_admin@root
Enter password: password
Connected.
SELECT DBID, ACTION_NAME, OBJECT_SCHEMA, OBJECT_NAME FROM CDB_UNIFIED_AUDIT_TRAIL WHERE DBUSERNAME = 'c##hr_admin';
DBID ACTION_NAME OBJECT_SCHEMA OBJECT_NAME
----------- ----------- ------------- -----------
653916017 UPDATE HR EMPLOYEES
653916018 UPDATE HR JOB_HISTORY
653916017 UPDATE HR JOBS
注意:
監査証跡で最新の監査レコードを表示するには、必要に応じて次のプロシージャを実行して、レコードをディスクに書き込みます。
EXEC DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL;
詳細は、「キュー書込みモードでの監査証跡への監査レコードの手動フラッシュ」を参照してください。
ALTER AUDIT POLICY
文を使用して、統合監査ポリシーを変更できます。
内容は次のとおりです。
統合監査ポリシーでは、CONTAINER
設定を除いたほとんどのプロパティを変更できます。
マルチテナント環境では統合監査ポリシーを変更できません。たとえば、共通統合監査ポリシーをローカル統合監査ポリシーにすることはできません。
既存の統合監査ポリシーを検索するには、AUDIT_UNIFIED_POLICIES
データ・ディクショナリ・ビューを問い合せます。有効な統合監査ポリシーのみを検索する場合は、AUDIT_UNIFIED_ENABLED_POLICIES
ビューを問い合せます。有効な監査ポリシーと無効な監査ポリシーの両方を変更できます。有効な監査ポリシーを変更する場合は、変更後も有効なままです。
オブジェクトの統合監査ポリシーを変更すると、アクティブおよび後続の両方のユーザー・セッションで新しい監査設定が即座に実行されます。システムの監査オプションを変更する場合やポリシーの条件を監査する場合は、現在のユーザー・セッションではなく、新しいユーザー・セッションに対してアクティブになります。
ALTER AUDIT POLICY
文で、統合監査ポリシーを変更できます。
統合監査ポリシーを変更するために次の構文を使用し、ALTER AUDIT POLICY
文を使用します。
ALTER AUDIT POLICY policy_name [ADD [privilege_audit_clause][action_audit_clause] [role_audit_clause]] [DROP [privilege_audit_clause][action_audit_clause] [role_audit_clause]] [CONDITION {DROP | audit_condition EVALUATE PER {STATEMENT|SESSION|INSTANCE}}]
次のように値を指定します。
ADD
では、次の設定を変更できます。
privilege_audit_clause
は、権限に関連する監査オプションを記述します。詳細は、「システム権限の監査」を参照してください。権限の監査オプションを構成するための詳細な構文は、次のとおりです。
ADD privilege_audit_clause := PRIVILEGES privilege1 [, privilege2]
action_audit_clause
およびstandard_actions
は、オブジェクト・アクションに関連する監査オプションを記述します。詳細は、「オブジェクト・アクションの監査」を参照してください。構文は次のようになります。
ADD action_audit_clause := {standard_actions | component_actions} [, component_actions ] standard_actions := ACTIONS action1 [ ON {schema.obj_name | DIRECTORY directory_name | MINING MODEL schema.obj_name } ] [, action2 [ ON {schema.obj_name | DIRECTORY directory_name | MINING MODEL schema.obj_name } ]
role_audit_clause
では、ロールのポリシーを追加または削除できます。「ロールの監査」を参照してください。構文は次のとおりです。
ADD role_audit_clause := ROLES role1 [, role2]
DROP
では、ADD
句で説明されているのと同じコンポーネントを削除できます。次に例を示します。
DROP role_audit_clause := ROLES role1 [, role2]
CONDITION {DROP...
では、ポリシーの条件を追加または削除できます。既存の条件を変更する場合は、EVALUATE PER
句を条件に含める必要があります。「統合監査ポリシーの条件の作成」を参照してください構文は次のとおりです。
CONDITION 'audit_condition := function operation value_list' EVALUATE PER {STATEMENT|SESSION|INSTANCE}
条件を削除する場合は、条件の定義およびEVALUATE PER
句を省略します。次に例を示します。
CONDITION DROP
ALTER AUDIT POLICY文で、統合監査ポリシーの条件を変更できます。
例22-34に、既存の統合監査ポリシーの条件を変更する方法を示します。
例22-34 統合監査ポリシーの条件の変更
ALTER AUDIT POLICY orders_unified_audpol ADD ACTIONS INSERT ON SCOTT.EMP CONDITION 'SYS_CONTEXT(''ENTERPRISE'', ''GROUP'') = ''ACCESS_MANAGER''' EVALUATE PER SESSION;
ALTER AUDIT POLICY
文で、監査ポリシーのOracle Label Securityコンポーネントを変更できます。
例22-35に、監査ポリシーでOracle Label Securityコンポーネントを変更する方法を示します。
例22-35 統合監査ポリシーでのOracle Label Securityコンポーネントの変更
ALTER AUDIT POLICY audit_ols ADD ACTIONS SELECT ON HR.EMPLOYEES ACTIONS COMPONENT=OLS DROP POLICY, DISABLE POLICY, REMOVE POLICY;
ALTER AUDIT POLICY
文で、統合監査ポリシーのロールを変更できます。
例22-36に、共通統合監査ポリシーにロールを追加する方法を示します。
例22-36 統合監査ポリシーのロールの変更
CONNECT c##sec_admin
Enter password: password
Connected.
ALTER AUDIT POLICY RoleConnectAudit
ADD ROLES c##role1, c##role2;
ALTER AUDIT POLICY
文で、統合監査ポリシーから条件を削除できます。
例22-37に、既存の統合監査ポリシーから条件を削除する方法を示します。
例22-37 統合監査ポリシーからの条件の削除
ALTER AUDIT POLICY orders_unified_audpol CONDITION DROP;
AUDIT POLICY
文を使用して、ユーザーに対する統合監査ポリシーを有効にして適用できます。
内容は次のとおりです。
POLICY
句を含むAUDIT
文で、統合監査ポリシーを有効にして、オブジェクト・レベルのオプションを含むすべてのタイプの監査オプションに適用します。
監査ユーザーがデータベース・インスタンスにログインするまで、ポリシーは有効となりません。言い方を変えると、監査ユーザーのログイン中にポリシーを作成して有効化すると、ポリシーは監査データを収集できません。監査を開始する前に、ユーザーはログアウトしてから再ログインする必要があります。セッションが監査で設定されると、設定はユーザー・セッションの間継続し、セッションの終了時に終了します。
監査の結果を確認するには、UNIFIED_AUDIT_TRAIL
データ・ディクショナリ・ビューを問い合せます。既存の統合監査ポリシーのリストを検索するには、AUDIT_UNIFIED_POLICIES
データ・ディクショナリ・ビューを問い合せます。
AUDIT
文では、次のオプションの追加設定を指定できます。
統合監査ポリシーを1人以上のユーザーに適用するかどうか。SYSDBA
管理権限(SYS
など)でログインする管理ユーザーを含む、1人以上のユーザーにポリシーを適用するには、BY
句を使用します。
次に例を示します。
AUDIT POLICY role_connect_audit_pol BY SYS, SYSTEM;
統合監査ポリシーからユーザーを除外するかどうか。監査ポリシーからユーザーを除外するには、EXCEPT
句を含めます。
次に例を示します。
AUDIT POLICY role_connect_audit_pol EXCEPT rlee, jrandolph;
アクティビティが成功または失敗した場合に、監査レコードを作成するかどうか。この監査方法は、監査証跡が減少するため、特定のアクションに重点を置きやすくなります。これにより、データベースの良好なパフォーマンスを維持できます。次のいずれかの句を入力します。
WHENEVER SUCCESSFUL
は、ユーザーのアクティビティの実行が成功した場合のみ監査します。
WHENEVER NOT SUCCESSFUL
は、ユーザーのアクティビティの実行が失敗した場合のみ監査します。異常終了したSQL文を監視することで、アクセス違反や不当な処理を行っているユーザーを判別できます。ただし、異常終了したSQL文の原因はそのどちらでもない場合がほとんどです。
次に例を示します。
AUDIT POLICY role_connect_audit_pol WHENEVER NOT SUCCESSFUL;
この句を省略すると、失敗および成功した両方のユーザー・アクティビティが監査証跡に書き込まれます。
次のことに注意してください。
統合監査ポリシーには、BY
句またはEXCEPT
句のみを含めることができますが、同じポリシーに両方を含めることはできません。
複数のAUDIT
文を同じ統合監査ポリシーで実行し、異なるBY
ユーザーを指定すると、Oracle Databaseによってこれらのユーザーのすべてが監査されます。
複数のAUDIT
文を同じ統合監査ポリシーで実行し、異なるEXCEPT
ユーザーを指定すると、Oracle Databaseによって、前述のリストのユーザーではなく、最新の例外ユーザー・リストが使用されます。つまり、前のAUDIT POLICY ... EXCEPT
文の影響は最新のAUDIT POLICY ... EXCEPT
文によってオーバーライドされます。
共通統合監査ポリシーは、共通ユーザーのみに対して有効にできます。
マルチテナント環境では、共通監査ポリシーはルートからのみ、ローカル監査ポリシーは、ローカル監査ポリシーが適用されるPDBからのみ有効にできます。
AUDIT POLICY
文で、統合監査ポリシーを有効にできます。
次のように値を指定します。
policy_auditing
は、次のコンポーネントを示します。
統合監査ポリシーの名前。既存のポリシーをすべて検索するには、AUDIT_UNIFIED_POLICIES
データ・ディクショナリ・ビューを問い合せます。現在有効なポリシーを検索するには、AUDIT_UNIFIED_ENABLED_POLICIES
を問い合せます。
統合監査ポリシーが適用されるユーザー。ポリシーを1人以上のユーザー(ユーザーSYS
を含む)に適用するには、BY
句を入力します。次に例を示します。
BY psmith, rlee
統合監査ポリシーから除外するユーザー。ポリシーから1人以上のユーザーを除外するには、EXCEPT
句を入力します。次に例を示します。
EXCEPT psmith, rlee
必須の監査レコードは、AUDIT POLICY
SQL文でUNIFIED_AUDIT_TRAIL
データ・ディクショナリ・ビューに取得されます。除外されたユーザーを監査レコードで検索するには、UNIFIED_AUDIT_TRAIL
ビューのEXCLUDED_USER
列を問い合せることで、除外されたユーザーをリストできます。
同じ文のBY
句、BY USERS WITH GRANTED ROLES
句およびEXCEPT
句で、同じ監査ポリシーを有効にすることはできません。このアクションにより、句が競合して、後続のAUDIT
文でエラーがスローされます。
WHENEVER [NOT] SUCCESSFUL
では、ユーザーのアクションが成功したか失敗したかに基づいて、ポリシーで監査レコードを生成できます。詳細は、統合監査ポリシーの有効化についてを参照してください。
統合監査ポリシーを有効にして、ポリシーがレコードを生成している場合は、UNIFIED_AUDIT_TRAIL
データ・ディクショナリ・ビューを問い合せることで、監査レコードを検索できます。
AUDIT POLICY文で、WHENEVER NOT SUCCESSFUL
などの条件を使用して統合監査ポリシーを有効にできます。
例22-38に、ユーザーdv_admin
による失敗したアクションのみを統合監査ポリシーで記録できるようにする方法を示します。
例22-38 統合監査ポリシーの有効化
AUDIT POLICY dv_admin_pol BY tjones WHENEVER NOT SUCCESSFUL;
NOAUDIT POLICY
文を使用して、統合監査ポリシーを無効にすることができます。
内容は次のとおりです。
NOAUDIT
文とPOLICY
句を組み合せることにより、統合監査ポリシーを無効にできます。
NOAUDIT
文では、EXCEPT
ユーザー・リストではなく、BY
ユーザー・リストを指定できます。統合監査ポリシーを無効にすると、後続のユーザー・セッションに反映されます。
既存の統合監査ポリシーのリストを検索するには、AUDIT_UNIFIED_POLICIES
データ・ディクショナリ・ビューを問い合せます。
マルチテナント環境では、共通監査ポリシーはルートからのみ、ローカル監査ポリシーは、ローカル監査ポリシーが適用されるPDBからのみ無効にできます。
NOAUDIT
文により、統合監査ポリシーを無効にできます。
次の構文を使用して、統合監査ポリシーを無効にします。
NOAUDIT POLICY {policy_auditing | existing_audit_options};
次のように値を指定します。
policy_auditing
は、ポリシーの名前です。現在有効なポリシーをすべて検索するには、AUDIT_UNIFIED_ENABLED_POLICIES
データ・ディクショナリ・ビューを問い合せます。この指定の一部として、EXCEPT
句ではなく、BY
句をオプションで含めることができます。詳細は、統合監査ポリシーの有効化についてを参照してください。
existing_audit_options
は、次のようなOracle Database 12cリリース1 (12.1)より前のリリースで使用可能だったAUDIT
オプションを示します。
SELECT ANY TABLE, UPDATE ANY TABLE BY SCOTT, HR
UPDATE ON SCOTT.EMP
NOAUDIT POLICY文で、ユーザー名などのフィルタを使用して統合監査ポリシーを無効にします。
例22-39に、ユーザーの統合監査ポリシーを無効にする方法を示します。
例22-39 統合監査ポリシーの無効化
NOAUDIT POLICY dv_admin_pol BY tjones;
DROP AUDIT POLICY
文を使用して、統合監査ポリシーを削除できます。
内容は次のとおりです。
DROP AUDIT POLICY
文を使用して、統合監査ポリシーを削除できます。
統合監査ポリシーがすでにセッションで有効な場合、ポリシーを削除しても、既存のこのセッションには影響しません。この時点まで、統合監査ポリシーの設定は有効のままです。ただし、オブジェクト関連の監査ポリシーの場合、影響は即座に反映されます。
既存の統合監査ポリシーのリストを検索するには、AUDIT_UNIFIED_POLICIES
データ・ディクショナリ・ビューを問い合せます。
監査ポリシーを削除する前に無効化する場合は、有効化に使用した設定と同じ設定を使用して無効化してください。たとえば、logon_pol
ポリシーを次のように有効化したとします。
AUDIT POLICY logon_pol BY HR, OE;
このポリシーを削除する前に、次のようにNOAUDIT
文にHR
およびOE
ユーザーが含まれている必要があります。
NOAUDIT POLICY logon_pol BY HR, OE;
マルチテナント環境では、共通監査ポリシーはルートからのみ、ローカル監査ポリシーは、ローカル監査ポリシーが適用されるPDBからのみ削除できます。
統合監査ポリシーを削除するには、最初に無効にし、DROP AUDIT POLICY
文を実行して削除します。
次の構文を使用して、統合監査ポリシーを削除します。
DROP AUDIT POLICY policy_name;
マルチテナント環境では、統合監査ポリシーの削除は現在のPDBに適用されます。統合監査ポリシーが共通統合監査ポリシーとして削除された場合は、ローカルのPDBから削除することはできません。共通統合監査ポリシーの詳細は、「マルチテナント環境での統合監査ポリシーまたはAUDIT設定の使用」を参照してください。
NOAUDIT POLICY
文およびDROP AUDIT POLICY
文では、統合監査ポリシーを無効化して削除できます。
例22-40に、共通統合監査ポリシーを無効化および削除する方法を示します。
例22-40 統合監査ポリシーの無効化および削除
CONNECT c##sec_admin
Enter password: password
Connected.
NOAUDIT POLICY dv_admin_pol;
DROP AUDIT POLICY dv_admin_pol
Oracle Databaseには、よく使用されるセキュリティ関連の監査設定を対象とする、事前定義の統合監査ポリシーが5つあります。
内容は次のとおりです。
関連項目:
このタイプの監査の実行に関する一般的な手順については、一般的に使用されるセキュリティ関連アクティビティの監査を参照してください
ORA_LOGON_FAILURES
統合監査ポリシーは、失敗したログオンのみを追跡し、その他のログオンは追跡しません。
新規データベースの場合、このポリシーは、完全な統合監査モードと混合モードの両方の監査環境で、デフォルトで有効です。デフォルトでは、このポリシーは有効になっていません。
次のCREATE AUDIT POLICY
文は、ORA_LOGON_FAILURES
統合監査ポリシー定義を示しています。
CREATE AUDIT POLICY ORA_LOGON_FAILURES ACTIONS LOGON;
ORA_LOGON_FAILURES
統合監査ポリシーは、次のように有効にします。
AUDIT POLICY ORA_LOGON_FAILURES WHENEVER NOT SUCCESSFUL;
ORA_SECURECONFIG
統合監査ポリシーには、セキュアな構成監査オプションがすべて用意されています。
新規データベースの場合、このポリシーは、完全な統合監査モードと混合モードの両方の監査環境で、デフォルトで有効です。デフォルトでは、このポリシーは有効になっていません。
次のCREATE AUDIT POLICY
文は、ORA_SECURECONFIG
統合監査ポリシー定義を示しています。
CREATE AUDIT POLICY ORA_SECURECONFIG PRIVILEGES ALTER ANY TABLE, CREATE ANY TABLE, DROP ANY TABLE, CREATE ANY PROCEDURE, DROP ANY PROCEDURE, ALTER ANY PROCEDURE, GRANT ANY PRIVILEGE, GRANT ANY OBJECT PRIVILEGE, GRANT ANY ROLE, AUDIT SYSTEM, CREATE EXTERNAL JOB, CREATE ANY JOB, CREATE ANY LIBRARY, EXEMPT ACCESS POLICY, CREATE USER, DROP USER, ALTER DATABASE, ALTER SYSTEM, CREATE PUBLIC SYNONYM, DROP PUBLIC SYNONYM, CREATE SQL TRANSLATION PROFILE, CREATE ANY SQL TRANSLATION PROFILE, DROP ANY SQL TRANSLATION PROFILE, ALTER ANY SQL TRANSLATION PROFILE, TRANSLATE ANY SQL, EXEMPT REDACTION POLICY, PURGE DBA_RECYCLEBIN, LOGMINING, ADMINISTER KEY MANAGEMENT ACTIONS ALTER USER, CREATE ROLE, ALTER ROLE, DROP ROLE, SET ROLE, CREATE PROFILE, ALTER PROFILE, DROP PROFILE, CREATE DATABASE LINK, ALTER DATABASE LINK, DROP DATABASE LINK, CREATE DIRECTORY, DROP DIRECTORY, CREATE PLUGGABLE DATABASE, DROP PLUGGABLE DATABASE, ALTER PLUGGABLE DATABASE, EXECUTE ON DBMS_RLS;
関連項目:
この項で説明しているSQL文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
ORA_DATABASE_PARAMETER
ポリシーでは、よく使用されるOracle Databaseのパラメータ設定を監査します。
次のCREATE AUDIT POLICY
文は、ORA_DATABASE_PARAMETER
統合監査ポリシー定義を示しています。デフォルトでは、このポリシーは有効になっていません。
CREATE AUDIT POLICY ORA_DATABASE_PARAMETER ACTIONS ALTER DATABASE, ALTER SYSTEM, CREATE SPFILE;
ORA_ACCOUNT_MGMT
ポリシーでは、よく使用されるユーザー・アカウントおよび権限の設定を監査します。
次のCREATE AUDIT POLICY
文は、ORA_ACCOUNT_MGMT
統合監査ポリシー定義を示しています。デフォルトでは、このポリシーは有効になっていません。
CREATE AUDIT POLICY ORA_ACCOUNT_MGMT ACTIONS CREATE USER, ALTER USER, DROP USER, CREATE ROLE, DROP ROLE, ALTER ROLE, SET ROLE, GRANT, REVOKE;
ORA_CIS_RECOMMENDATIONS
ポリシーは、Center for Internet Security (CIS)で推奨される監査を実行します。
次のCREATE AUDIT POLICY
文は、ORA_CIS_RECOMMENDATIONS
統合監査ポリシー定義を示しています。デフォルトでは、このポリシーは有効になっていません。
CREATE AUDIT POLICY ORA_CIS_RECOMMENDATIONS PRIVILEGES SELECT ANY DICTIONARY, CREATE ANY LIBRARY, DROP ANY LIBRARY, CREATE ANY TRIGGER, ALTER ANY TRIGGER, DROP ANY TRIGGER, ALTER SYSTEM ACTIONS CREATE USER, ALTER USER, DROP USER, CREATE ROLE, DROP ROLE, ALTER ROLE, GRANT, REVOKE, CREATE DATABASE LINK, ALTER DATABASE LINK, DROP DATABASE LINK, CREATE PROFILE, ALTER PROFILE, DROP PROFILE, CREATE SYNONYM, DROP SYNONYM, CREATE PROCEDURE, DROP PROCEDURE, ALTER PROCEDURE;
事前定義の統合監査ポリシーをOracle Database Real Application Securityのイベントに使用できます。デフォルトでは、これらのポリシーは有効になっていません。
内容は次のとおりです。
ORA_RAS_POLICY_MGMT
の事前定義の統合監査ポリシーでは、アプリケーション・ユーザー、ロールおよびポリシーのOracle Real Application Securityのすべて管理アクションのポリシーを監査します。
次のCREATE AUDIT POLICY
文は、ORA_RAS_POLICY_MGMT
統合監査ポリシー定義を示しています。デフォルトでは、このポリシーは有効になっていません。
CREATE AUDIT POLICY ORA_RAS_POLICY_MGMT ACTIONS COMPONENT=XS CREATE USER, UPDATE USER, DELETE USER, CREATE ROLE, UPDATE ROLE, DELETE ROLE, GRANT ROLE, REVOKE ROLE, ADD PROXY, REMOVE PROXY, SET USER PASSWORD, SET USER VERIFIER, SET USER PROFILE, CREATE ROLESET, UPDATE ROLESET, DELETE ROLESET, CREATE SECURITY CLASS, UPDATE SECURITY CLASS, DELETE SECURITY CLASS, CREATE NAMESPACE TEMPLATE, UPDATE NAMESPACE TEMPLATE, DELETE NAMESPACE TEMPLATE, CREATE ACL, UPDATE ACL, DELETE ACL, CREATE DATA SECURITY, UPDATE DATA SECURITY, DELETE DATA SECURITY, ENABLE DATA SECURITY, DISABLE DATA SECURITY, ADD GLOBAL CALLBACK, DELETE GLOBAL CALLBACK, ENABLE GLOBAL CALLBACK;
ORA_RAS_SESSION_MGMT
の事前定義の統合監査ポリシーでは、Oracle Real Application Securityのすべてのランタイム・セッション・アクションおよびネームスペース・アクションのポリシーを監査します。
次のCREATE AUDIT POLICY
文は、ORA_RAS_SESSION_MGMT
統合監査ポリシー定義を示しています。デフォルトでは、このポリシーは有効になっていません。
CREATE AUDIT POLICY ORA_RAS_SESSION_MGMT ACTIONS COMPONENT=XS CREATE SESSION, DESTROY SESSION, ENABLE ROLE, DISABLE ROLE, SET COOKIE, SET INACTIVE TIMEOUT, SWITCH USER, ASSIGN USER, CREATE SESSION NAMESPACE, DELETE SESSION NAMESPACE, CREATE NAMESPACE ATTRIBUTE, GET NAMESPACE ATTRIBUTE, SET NAMESPACE ATTRIBUTE, DELETE NAMESPACE ATTRIBUTE;
事前定義のORA_DV_AUDPOL
統合監査ポリシーはOracle Database Vaultのスキーマ・オブジェクトを監査します。
ORA_DV_AUDPOL
ポリシーは、Oracle Database VaultのDVSYS
およびDVF
スキーマ・オブジェクトと、Oracle Label SecurityのLBACSYS
スキーマ・オブジェクトに対して実行されるすべてのアクションを監査します。DVF
スキーマのF$
*ファクタ・ファンクションに関するアクションは取得しません。デフォルトでは、このポリシーは有効になっていません。
次のCREATE AUDIT POLICY
文は、ORA_DV_AUDPOL
統合監査ポリシー定義を示しています。
CREATE AUDIT POLICY ORA_DV_AUDPOL ACTIONS AUDIT ON DVF.DBMS_MACSEC_FUNCTION;
ファイングレイン監査では、非常に詳細なレベルで監査ポリシーを作成できます。
内容は次のとおりです。
関連項目:
このタイプの監査の実行に関する一般的な手順については、特定のファイングレイン・アクティビティの監査を参照してください
ファイングレイン監査では、ポリシーを作成して、監査が実行される特定の条件を定義できます。
ファイングレイン監査を使用して統合監査ポリシーは作成できませんが、データのアクセス時間の監査など、詳細にカスタマイズされた監査設定はファイングレイン監査を使用して作成できます。
これにより、内容に基づいてデータ・アクセスを監視できるようになります。問合せと、INSERT
、UPDATE
、およびDELETE
操作に対して詳細な監査を提供します。ファイングレイン監査を使用すると、次のタイプのアクションを監査できます。
午後9時から午前6時の間、または土曜日と日曜日に表にアクセスする場合
社内ネットワーク外部のIPアドレスを使用する場合
表の列を選択または更新する場合
表の列の値を変更する場合
通常、ファイングレイン監査ポリシーは、選択的監査の条件である、表オブジェクトに対する単純なユーザー定義SQL述語に基づいています。フェッチ中に行がポリシーの条件を満たすと、その問合せが監査対象となります。
統合監査ポリシーおよびAUDIT文を使用したアクティビティの監査で説明されている監査ポリシーでは、次のアクションを除き、ファイングレイン監査ポリシーで実行可能な大部分の操作を実行できます。
特定の列の監査。給与や社会保障番号など、機密情報が格納されている特定の関連する列を監査できます。
イベント・ハンドラの使用。たとえば、夜中に変更されないようにする必要がある監査対象の列が更新された場合に、セキュリティ管理者に電子メール・アラートを送信する関数を作成できます。
注意:
ファイングレイン監査は、コストベースの最適化でのみサポートされています。ルールベースの最適化を使用する問合せでは、行フィルタを適用する前にファイングレイン監査が行われるため、不要な監査イベント・トリガーが発生します。
フラッシュバック問合せに含まれるオブジェクトで現在有効なポリシーが、指定したフラッシュバック・スナップショット(時間またはシステム変更番号(SCN)に基づく)から戻されたデータに適用されます。
ファイングレイン監査を使用して直接ロードされるデータを監査する場合(たとえばOracle Warehouse Builderを使用してDML文を実行する場合)、Oracle Databaseは透過的にデータベース・インスタンスで実行されているすべてのダイレクト・ロードを従来型ロードにします。データのダイレクト・ロードを保持する場合は、かわりに統合監査ポリシーの使用を検討してください。
ファイングレイン監査のレコードは、AUDSYS
スキーマに格納されます。
これらの監査レコードは、デフォルトでSYSAUX
表領域に格納されます。DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION
プロシージャを使用して、新しい表領域を指定できます。この表領域は暗号化された表領域にできます。有効な監査ポリシーに対して生成されたレコードを検索するには、UNIFIED_AUDIT_TRAIL
データ・ディクショナリ・ビューを問い合せます。
監査証跡では、SQL文内の表またはビューの参照ごとに監査レコードが取得されます。たとえば、HR.EMPLOYEES
表を2回参照するUNION
文を実行した場合、文の監査ポリシーによって2つ(HR.EMPLOYEES
表へのアクセスごとに1つ)の監査レコードが生成されます。
関連項目:
DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
UNIFIED_AUDIT_TRAIL
データ・ディクショナリ・ビューの詳細は、Oracle Databaseリファレンスを参照
Oracleには、ファイングレイン監査ポリシーを作成したり、ファイングレイン監査ポリシーのデータを表示および分析するために必要な権限のロールが用意されています。
ファイングレイン監査には、次の権限があります。
ファイングレイン監査ポリシーを作成するには、AUDIT_ADMIN
ロールまたはDBMS_FGA
パッケージに対するEXECUTE
権限が付与されている必要があります。
ファイングレイン監査データを表示および分析するには、AUDIT_VIEWER
ロールが付与されている必要があります。
PL/SQLパッケージにはAUDIT_ADMIN
ロールがすでに付与されています。すべての権限と同様に、これらのロールは信頼できるユーザーにのみ付与してください。DBA_ROLE_PRIVS
データ・ディクショナリ・ビューを問い合せることで、ユーザーに付与されているロールを確認できます。
この監査証跡は、Oracle VPDポリシーに含まれているファイングレイン監査表またはビューからVPD述語を取得します。
この動作は、統合監査証跡で統合監査ポリシーのVPD述語を取得する場合の動作に似ています。
述語情報は、UNIFIED_AUDIT_TRAIL
データ・ディクショナリ・ビューのRLS_INFO
列に格納されます。
同じ表またはビューに適用されるVPDポリシーが複数ある場合、これらのポリシーの述部は、デフォルトでRLS_INFO
列に連結されます。各述語が各自の行内(対応するVPDポリシー名などの情報で特定)になるように出力を再フォーマットするには、ORA_GET_RLS_PREDICATE
ファンクションを使用します
ファイングレイン監査ポリシーはルートまたはPDBに作成できます。
次のことに注意してください。
SYS
オブジェクトではポリシーを作成できません。
ルートにポリシーを作成する場合、すべてのPDBにポリシーを適用することはできません。ポリシーはルート内のオブジェクトにのみ適用されます。(つまり、共通のファイングレイン監査ポリシーは存在しません。)すべてのPDBで共通オブジェクトのアクセスを監査するようにファイングレイン監査ポリシーを作成する場合は、監査ポリシーを各PDBで明示的に作成し、PDBでアクセス可能にする共通オブジェクトに対してそのポリシーを有効化する必要があります。
PDBでポリシーを作成する場合、ポリシーはPDB内のオブジェクトにのみ適用されます。
エディション・ベースの再定義のアプリケーションを作成し、アプリケーションが編集ビューで使用する各表を対象とすることができます。
これを行う場合、編集ビューに対してこれらの表を保護するファイングレイン監査ポリシーを移動する必要があります。DBA_EDITIONSデータ・ディクショナリ・ビューを問い合せることで、現在構成されているエディションについて情報を確認できます。ファイングレイン監査ポリシーに関する情報を確認するには、DBA_AUDIT_POLICIESを問い合せます。
DBMS_FGA
PL/SQLパッケージで、ファイングレイン監査ポリシーを管理します。
内容は次のとおりです。
DBMS_FGA
PL/SQLパッケージを使用して複数の文を1つのポリシーにまとめ、その他のファイングレイン監査管理タスクを実行できます。
ただし、列レベルの監査を実行しない場合や、イベント・ハンドラと監査ポリシーを使用しない場合は、統合監査ポリシーおよびAUDIT文を使用したアクティビティの監査で説明されているように、監査ポリシーを作成する必要があります。
DBMS_FGA
PL/SQLパッケージを使用すると、SELECT
、INSERT
、UPDATE
およびDELETE
文のすべての組合せを1つのポリシーに追加できます。また、基礎となるアクションのINSERT
およびUPDATE
を監査することによって、MERGE
文も監査できます。MERGE
文を監査するには、INSERT
およびUPDATE
文に対するファイングレイン・アクセスを構成します。成功したMERGE
操作についてポリシーごとにレコードが1つのみ生成されます。
ファイングレイン監査ポリシーを管理するには、AUDIT_ADMIN
ロールを付与する必要があります。DBMS_FGA
パッケージのEXECUTE
権限は強制的に監査されることにも注意してください。
監査ポリシーは、監査ポリシーを作成した表にバインドされます。これにより、それぞれのアプリケーションではなく、データベースで一度だけポリシーを変更すればよいため、監査ポリシーの管理が容易です。また、データベースへの接続方法(接続元がアプリケーション、Webインタフェース、SQL*PlusやOracle SQL Developerのいずれであるか)に関係なく、ポリシーに影響を与えるアクションがすべて記録されます。
問合せから戻された行が定義した監査条件と一致すると、ファイングレイン監査証跡に監査エントリが挿入されます。このエントリでは、通常の監査証跡でレポートされるすべての情報が除外されます。つまり、TRUEと評価されたすべてのファイングレイン監査ポリシーに対して、1行の監査情報のみが監査証跡に挿入されます。
関連項目:
DBMS_FGA
パッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してくださいエディション環境で使用するためのDBMS_FGA
ポリシーを作成できます。
DBMS_FGA
パッケージ・ポリシーを異なる複数のエディションで使用する場合、ポリシーの結果を制御できます。つまり、結果をすべてのエディションで同一にするか、またはポリシーが使用されているエディションに固有にできます。
詳細は、エディションがグローバル・アプリケーション・コンテキストのPL/SQLパッケージの結果に与える影響を参照してください。
マルチテナント環境では、DBMS_FGA
PL/SQLパッケージは現在のローカルPDBのみに適用されます。
マルチテナント環境全体に1つのポリシーを作成することはできません。PDB内でオブジェクトにポリシーを指定する必要があります。PDBを確認するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。
DBMS_FGA.ADD_POLICY
プロシージャでは、ファイングレイン監査ポリシーを作成できます。
内容は次のとおりです。
DBMS_FGA.ADD_POLICY
プロシージャで、指定された述語を監査条件として使用し、監査ポリシーを作成します。
デフォルトでは、ポリシーを作成したユーザーの権限で、ポリシーの述語がOracle Databaseによって実行されます。表オブジェクトまたはビュー・オブジェクトに設定可能なファイングレイン・ポリシーの最大数は256です。Oracle Databaseでは、ポリシーはデータ・ディクショナリ表に格納されますが、SYS
スキーマ内に存在しない表またはビューに関するポリシーを作成できます。マルチテナント環境では、ファイングレイン・ポリシーはローカルPDBでのみ作成されます。
ファイングレイン監査ポリシーを作成後に変更することはできません。ポリシーを変更する必要がある場合は、削除してから再作成します。
ファイングレイン監査ポリシーに関する情報を検索するには、ALL_AUDIT_POLICIES
、DBA_AUDIT_POLICIES
およびALL_AUDIT_POLICIES
ビューを問い合せます。UNIFIED_AUDIT_TRAIL
ビューには、FGA_POLICY_NAME
という名前の列が含まれ、この列を使用すると、特定のファイングレイン監査ポリシーを使用して生成された行をフィルタできます。
表の列にファイングレイン監査ポリシーが含まれている場合は、(UPDATE
文を使用して)この列を暗号化することも復号化することもできないことに注意してください。実行した場合、ORA-28133「完全な表アクセスがファイングレイン・セキュリティによって制限されています」
エラーが発生します。列を更新する場合は、まずファイングレイン監査ポリシーを一時的に無効にし、それから列を暗号化または復号化します。その後に、ファイングレイン監査ポリシーを再有効化します。詳細は、「ファイングレイン監査ポリシーの無効化」を参照してください。
DBMS_FGA.ADD_POLICY
プロシージャには、複雑な監査のハンドラを使用する機能など、様々な設定が含まれています。
DBMS_FGA.ADD_POLICY
プロシージャの構文は次のとおりです。
DBMS_FGA.ADD_POLICY( object_schema IN VARCHAR2 DEFAULT NULL object_name IN VARCHAR2, policy_name IN VARCHAR2, audit_condition IN VARCHAR2 DEFAULT NULL, audit_column IN VARCHAR2 DEFAULT NULL handler_schema IN VARCHAR2 DEFAULT NULL, handler_module IN VARCHAR2 DEFAULT NULL, enable IN BOOLEAN DEFAULT TRUE, statement_types IN VARCHAR2 DEFAULT SELECT, audit_trail IN BINARY_INTEGER DEFAULT NULL, audit_column_opts IN BINARY_INTEGER DEFAULT ANY_COLUMNS, policy_owner IN VARCHAR2 DEFAULT NULL);
次のように値を指定します。
object_schema
には、監査するオブジェクトのスキーマを指定します。(NULL
の場合、現行のログオン・ユーザーのスキーマと想定されます。)
object_name
には、監査するオブジェクトの名前を指定します。
policy_name
には、作成するポリシーの名前を指定します。この名前は必ず一意にしてください。
audit_condition
には、行のブール条件を指定します。NULL
も指定できます(TRUE
として機能します)。詳細は、特定の列および行の監査を参照してください。監査条件にNULL
を指定するか、何も指定しない場合は、そのポリシーが設定された表に対するアクションが行われると、行が戻されるかどうかに関係なく監査レコードが作成されます。
次のガイドラインに従ってください。
ファンクションは、同じ実表で監査可能な文を実行するため、audit_condition
設定に含めないでください。たとえば、HR.EMPLOYEES
表に対してINSERT
文を実行するファンクションを作成するとします。ポリシーのaudit_condition
には、このファンクションが含まれていて、これは(statement_types
により設定される)INSERT
文のポリシーです。このポリシーが使用されると、ファンクションはシステムのメモリーが足りなくなるまで再帰的に実行します。これにより、 ORA-1000: 最大オープン・カーソル数を超えました。
または ORA-00036: 再帰的SQLレベルの最大値(50)を超えました
のエラーが発生する場合があります。
DBMS_FGA.ENABLE_POLICY
文またはDBMS_FGA.DISABLE_POLICY
文を、ポリシーの条件に含まれるファンクションから発行しないでください。
audit_column
には、監査対象の1つ以上の列(非表示列も含む)を指定します。NULL
に設定するかまたは省略すると、すべての列が監査されます。Oracle Label Securityの非表示列やオブジェクト・タイプ列も対象になります。デフォルトのNULL
の場合、アクセスまたは影響を受ける列があれば監査が行われます。
handler_schema
: ポリシーに違反した場合の応答のトリガーにアラートが使用される場合は、イベント・ハンドラが含まれているスキーマの名前を指定します。デフォルトのNULL
では、現行のスキーマが使用されます。例: ファイングレイン監査ポリシーへの電子メール・アラートの追加も参照してください。
handler_module
には、イベント・ハンドラの名前を指定します。イベント・ハンドラが含まれるパッケージも対象になります。このファンクションは、問合せの監査条件と一致する最初の行が処理された後でのみ実行されます。
次のガイドラインに従ってください。
再帰的ファイングレイン監査ハンドラを作成しないでください。たとえば、HR.EMPLOYEES
表に対してINSERT
文を実行するハンドラを作成するとします。このハンドラに関連付けられるポリシーは、(statement_types
パラメータにより設定される)INSERT
文のポリシーです。このポリシーが使用されると、ハンドラはシステムのメモリーが足りなくなるまで再帰的に実行します。これにより、 ORA-1000: 最大オープン・カーソル数を超えました。
または ORA-00036: 再帰的SQLレベルの最大値(50)を超えました
のエラーが発生する場合があります。
DBMS_FGA.ENABLE_POLICY
文またはDBMS_FGA.DISABLE_POLICY
文をポリシー・ハンドラから発行しないでください。これらの文を発行すると、 ORA-28144: ファイングレイン監査ハンドラの実行に失敗しました
エラーが発生する場合があります。
enable
は、TRUEまたはFALSEを使用してポリシーを使用可能または使用禁止にします。省略した場合、ポリシーは使用可能になります。デフォルトはTRUE
です。
statement_types
: 監査対象のSQL文を指定します。INSERT
、UPDATE
、DELETE
またはSELECT
のみです。MERGE
操作を監査する場合は、statement_types
を'INSERT,UPDATE'
に設定します。デフォルト値はSELECT
です。
audit_trail
: 統合監査に移行している場合は、Oracle Databaseによってこのパラメータは無視され、監査レコードが統合監査証跡に即座に書き込まれます。統合監査に移行している場合は、このパラメータを省略します。
クレジット・カード情報などの機密データもクリアテキストで記録できることに注意してください。
audit_column_opts
: audit_column
パラメータで複数の列を指定した場合は、すべての列を監査するか特定の列を監査するかをこのパラメータで決定します。詳細は、特定の列および行の監査を参照してください。
policy_owner
は、ファイングレイン監査ポリシーを所有するユーザーです。ただし、この設定はユーザー指定の引数ではありません。Oracle Data Pumpクライアントは、この設定を内部で使用して、ファイングレイン監査ポリシーを適宜再作成します。
関連項目:
DBMS_FGA.ADD_POLICY
の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください条件が一致した場合の監査対象を関連列と呼ばれる特定の列にすることで、監査動作を細かく調節できます。
これを実行するには、audit_column
パラメータを使用して、機密情報が含まれた列を1つ以上指定します。また、audit_condition
パラメータを使用してブール条件を定義すると、特定の行のデータを監査できます。(ただし、ポリシーで条件の監査のみが必要な場合は、統合監査ポリシーの条件の作成で説明されている監査ポリシー条件の使用を検討してください。)
例22-41では、次の設定によって部門50(DEPARTMENT_ID = 50
)のユーザーがSALARY
およびCOMMISSION_PCT
列にアクセスしようとしたときに監査を実行できます。
audit_condition => 'DEPARTMENT_ID = 50', audit_column => 'SALARY,COMMISSION_PCT,'
この機能は非常に有用です。監査対象を特定の重要なデータ・タイプに限定できるだけでなく、社会保障番号、給与情報、診断書などの機密データを含む列をより強力に保護できます。
audit_column
に複数の列がリストされている場合は、audit_column_opts
パラメータを使用すると、文の監査が、audit_columnパラメータで指定されたいずれかの
列が問合せで参照されたときに実行されるか、またはすべての列が参照されたときにのみ実行されるかを指定できます。たとえば、次のようにします。
audit_column_opts => DBMS_FGA.ANY_COLUMNS, audit_column_opts => DBMS_FGA.ALL_COLUMNS,
関連列を指定しない場合、監査はすべての列に適用されます。
DBMS_FGA.ADD_POLICY
プロシージャ内のaudit_condition
、audit_column
およびaudit_column_opts
パラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。その項のADD_POLICY
プロシージャの使用方法も参照してください。
DBMS_FGA.ADD_POLICY
プロシージャで、複数の文タイプを使用してファイングレイン監査ポリシーを作成できます。
例22-41に、表HR.EMPLOYEES
に対する文INSERT
、UPDATE
、DELETE
およびSELECT
を監査する方法を示します。
この例では、audit_column_opts
パラメータが必須パラメータではないため省略されていることに注意してください。
例22-41 DBMS_FGA.ADD_POLICYを使用してファイングレイン監査ポリシーを作成する方法
BEGIN DBMS_FGA.ADD_POLICY( object_schema => 'HR', object_name => 'EMPLOYEES', policy_name => 'chk_hr_employees', audit_column => 'SALARY', enable => TRUE, statement_types => 'INSERT, UPDATE, SELECT, DELETE'); END; /
ポリシーを作成した後、DBA_AUDIT_POLICIES
ビューを問い合せると、新しいポリシーがリストされることを確認できます。
SELECT POLICY_NAME FROM DBA_AUDIT_POLICIES; POLICY_NAME ------------------------------- CHK_HR_EMPLOYEES
その後、次のようなSQL文を発行すると、監査イベント・レコードが記録されます。
SELECT COUNT(*) FROM HR.EMPLOYEES WHERE COMMISSION_PCT = 20 AND SALARY > 4500; SELECT SALARY FROM HR.EMPLOYEES WHERE DEPARTMENT_ID = 50; DELETE FROM HR.EMPLOYEES WHERE SALARY > 1000000;
DBMS_FGA.DISABLE_POLICY
プロシージャで、ファイングレイン監査ポリシーを無効にします。
次の構文を使用して、ファイングレイン監査ポリシーを無効にします。
DBMS_FGA.DISABLE_POLICY(
object_schema VARCHAR2,
object_name VARCHAR2,
policy_name VARCHAR2);
たとえば、例22-41で作成されたファイングレイン監査ポリシーを無効にするには、次のようにします。
BEGIN DBMS_FGA.DISABLE_POLICY( object_schema => 'HR', object_name => 'EMPLOYEES', policy_name => 'chk_hr_employees'); END; /
関連項目:
DISABLE_POLICY
の構文の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してくださいDBMS_FGA.ENABLE_POLICY
プロシージャで、ファイングレイン監査ポリシーを有効にします。
次の構文を使用して、ファイングレイン監査ポリシーを有効にします。
DBMS_FGA.ENABLE_POLICY(
object_schema VARCHAR2,
object_name VARCHAR2,
policy_name VARCHAR2,
enable BOOLEAN);
たとえば、DBMS_FGA.ENABLE_POLICY
プロシージャを使用してchk_hr_emp
ポリシーを再度使用可能にするとします。
BEGIN DBMS_FGA.ENABLE_POLICY( object_schema => 'HR', object_name => 'EMPLOYEES', policy_name => 'chk_hr_employees', enable => TRUE); END; /
関連項目:
ENABLE_POLICY
の構文の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してくださいDBMS_FGA.DROP_POLICY
プロシージャで、ファイングレイン監査ポリシーを削除します。
DBMS_FGA.ADD_POLICY
プロシージャのobject_name
パラメータで指定されたオブジェクトを削除した場合、または監査ポリシーを作成したユーザーを削除した場合は、Oracle Databaseでは監査ポリシーが自動的に削除されます。
次の構文を使用して、ファイングレイン監査ポリシーを削除します。
DBMS_FGA.DROP_POLICY( object_schema VARCHAR2, object_name VARCHAR2, policy_name IVARCHAR2);
たとえば、DBMS_FGA.DROP_POLICY
プロシージャを使用して、ファイングレイン監査ポリシーを手動で削除する方法を示します。
BEGIN DBMS_FGA.DROP_POLICY( object_schema => 'HR', object_name => 'EMPLOYEES', policy_name => 'chk_hr_employees'); END; /
関連項目:
DROP_POLICY
の構文の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してくださいこのチュートリアルでは、ユーザーがポリシーに違反したときに電子メールのアラートを生成するファイングレイン監査ポリシーの作成方法を示します。
内容は次のとおりです。
このチュートリアルでは、ユーザー(または侵入者)がポリシーに違反したときに実施される電子メールのアラートをファイングレイン監査ポリシーに追加する方法を示します。
注意:
このチュートリアルを完了するには、SMTPサーバーが備わったデータベースを使用する必要があります。
マルチテナント環境を使用している場合、このチュートリアルは現在のPDBのみに適用されます。
電子メール・アラートをファイングレイン監査ポリシーに追加するには、最初にアラートを生成するプロシージャを作成し、次に示すDBMS_FGA.ADD_POLICY
パラメータを使用して、ユーザーがこのポリシーに違反した場合に、このファンクションをコールする必要があります。
handler_schema
: ハンドラ・イベントが格納されるスキーマ
handler_module
: イベント・ハンドラの名前
アラートは、電子メールまたはポケベルによる通知や、特定のファイルまたは表の更新など、環境に適した形式で生成できます。アラートを作成すると、California Senate Bill 1386などの特定のコンプライアンス規制を満たすことも可能です。この例では、電子メール・アラートを作成します。
この例では、セキュリティ管理者に対して、人事部門の担当者がHR.EMPLOYEES
表内の給与情報を選択または変更しようとしていることを通知する電子メール・アラートを作成します。担当者はこの表を変更することを許可されていますが、コンプライアンス規制を満たすために、表内の給与情報に対するすべての選択および変更操作に関するレコードを作成できます。
UTL_MAIL
PL/SQLで、添付ファイル、CCおよびBCCなど一般に使用される電子メール機能が組み込まれた電子メールを管理します。
アクセス制御リスト(ACL)ファイルを使用して、外部ネットワーク・サービスへのファイングレイン・アクセスを有効にできます。
UTL_MAIL
などのPL/SQLネットワーク・ユーティリティ・パッケージを使用するには、このタイプのアクセス制御リスト(ACL)ファイルを構成する必要があります。
関連項目:
アクセス制御リスト(ACL)ファイルの構成の詳細は、「PL/SQLパッケージおよびタイプでのファイングレイン・アクセスの管理」を参照してください。電子メール・セキュリティ・アラートPL/SQLプロシージャは、違反について説明するメッセージを生成し、このメッセージを適切なユーザーに送信します。
ユーザーfga_admin
で、次のプロシージャを作成します。
CREATE OR REPLACE PROCEDURE email_alert (sch varchar2, tab varchar2, pol varchar2) AS msg varchar2(20000) := 'HR.EMPLOYEES table violation. The time is: '; BEGIN msg := msg||TO_CHAR(SYSDATE, 'Day DD MON, YYYY HH24:MI:SS'); UTL_MAIL.SEND ( sender => 'youremail@example.com', recipients => 'recipientemail@example.com', subject => 'Table modification on HR.EMPLOYEES', message => msg); END email_alert; /
この例の説明は、次のとおりです。
CREATE OR REPLACE PROCEDURE ...AS
: 次の手順で監査ポリシーに定義するスキーマ名(sch
)、表名(tab
)および監査プロシージャ名(pol
)を表す署名を指定する必要があります。
sender
およびrecipients
: youremail@example.com
を自分の電子メール・アドレス、recipientemail@example.com
を通知の受信対象者の電子メール・アドレスに置き換えます。
Oracle Databaseには、監査情報を提供するデータ・ディクショナリ・ビューおよび動的ビューが用意されています。
表22-19に、これらのビューを示します。これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
ヒント:
監査ポリシーに関するエラー情報を検索するには、トレース・ファイルを確認します。USER_DUMP_DEST
初期化パラメータは、トレース・ファイルの位置を示します。
表22-19 監査アクティビティに関する情報を表示するビュー
ビュー | 説明 |
---|---|
|
すべてのファイングレイン監査ポリシーに関する情報が表示されます。 |
|
オブジェクトの作成時に適用されるデフォルトのオブジェクト監査オプションがリストされます。 |
|
監査証跡で取得されるように構成されているアプリケーション・コンテキスト値が表示されます。 |
|
データベースで有効なすべての統合監査ポリシーが表示されます。 |
|
データベースで作成されたすべての統合監査ポリシーが表示されます。 |
|
|
|
監査可能なシステム・アクション番号がアクション名にマップされます。 |
|
|
|
ファイングレイン監査ポリシーに関する情報が表示されます。 |
|
ユーザーによって実行される監査対象のOracle Label Securityイベントが表示され、ユーザーのアクションが成功したか失敗したかが示されます。 |
|
Oracle Database Real Application Securityに関連する監査証跡の情報が表示されます。 |
|
Oracle Database Vault管理者による構成変更が表示されます。 |
|
Oracle Database Vaultポリシーによって影響を受けるユーザー・アクティビティが表示されます。 |
|
権限(監査オプション)型コードが表示されます。この表を使用して、権限(監査オプション)の型番号を型名にマップできます。 |
|
現行ユーザーによって所有される表およびビューのすべてのファイングレイン監査ポリシーに関する情報が表示されます。 |
|
すべての監査レコードが表示されます。 |
|
統合監査の |
|
XML形式のファイルに書き込まれた標準監査、ファイングレイン監査、 |