22 監査ポリシーの構成

統合監査では、カスタム統合監査ポリシー、事前定義の統合監査ポリシーおよびファイングレイン監査がサポートされます。

22.1 監査タイプの選択

一般的なアクティビティ(SQL文のアクションなど)や一般的に使用される監査アクティビティ、ファイングレイン監査のシナリオを監査できます。

22.1.1 SQL文、権限および他の一般アクティビティの監査

SQL文やOracle Database VaultなどのOracle Databaseコンポーネントまで、様々なタイプのオブジェクトを監査できます。

また、条件を使用するポリシーも作成できます。ただし、特定の列を監査したり、イベント・ハンドラを使用する場合は、ファイングレイン監査を使用する必要があります。

このタイプの監査を実行する一般的なステップは次のとおりです。

  1. ほとんどの場合は、CREATE AUDIT POLICY文を使用して監査ポリシーを作成します。アプリケーション・コンテキスト値を監査する必要がある場合は、AUDIT文を使用します。

    統合監査ポリシーおよびAUDIT文を使用したアクティビティの監査の関連するカテゴリを参照してください。

  2. 監査ポリシーを作成する場合は、AUDIT文を使用して有効にし、オプションで、SYSDBA管理権限でログインする管理ユーザー(SYSなど)を含む、1人以上のユーザーに監査設定を適用(または除外)します。

    AUDITでは、アクションの成功または失敗(あるいは両方)時に監査レコードを作成することもできます。

    統合監査ポリシーの有効化およびユーザーとロールへの適用を参照してください。

  3. UNIFIED_AUDIT_TRAILビューを問い合せ、生成された監査レコードを検索します。

    追加のビューについては、監査ポリシーのデータ・ディクショナリ・ビューも参照してください。

  4. 監査証跡の内容を定期的にアーカイブして削除します。

    「監査証跡レコードの削除」を参照してください。

22.1.2 一般的に使用されるセキュリティ関連アクティビティの監査

Oracle Databaseには、デフォルトの統合監査ポリシーが用意されており、これらは一般的に使用されるセキュリティ関連の監査用に選択できます。

このタイプの監査を実行する一般的なステップは次のとおりです。

  1. デフォルトの監査ポリシーについて学習するには、事前定義の統合監査ポリシーを使用したアクティビティの監査を参照してください。
  2. AUDIT文を使用してポリシーを有効にし、1人以上のユーザーに監査設定をオプションで適用(または除外)します。
  3. UNIFIED_AUDIT_TRAILビューを問い合せ、生成された監査レコードを検索します。

    追加のビューについては、監査ポリシーのデータ・ディクショナリ・ビューも参照してください。

  4. 監査証跡の内容を定期的にアーカイブして削除します。

    「監査証跡レコードの削除」を参照してください。

22.1.3 特定のファイングレイン・アクティビティの監査

個々の列を監査またはイベント・ハンドラを使用する場合は、ファイングレイン監査を使用します。

このタイプの監査では、統合監査ポリシーで使用可能なすべての機能が提供されます。

ファイングレイン監査を実行する一般的なステップは次のとおりです。

  1. ファイングレイン監査を使用した特定のアクティビティの監査を参照し、特定のアクティビティの監査の詳細を把握します。
  2. DBMS_FGA PL/SQLパッケージを使用して、ファイングレイン監査ポリシーを構成します。DBMS_FGA PL/SQLパッケージを使用したファイングレイン監査ポリシーの管理を参照してください。
  3. UNIFIED_AUDIT_TRAILビューを問い合せ、生成された監査レコードを検索します。

    追加のビューについては、監査ポリシーのデータ・ディクショナリ・ビューも参照してください。

  4. 監査証跡の内容を定期的にアーカイブして削除します。

    「監査証跡レコードの削除」を参照してください。

22.2 統合監査ポリシーおよびAUDIT文を使用したアクティビティの監査

CREATE AUDIT POLICY文とAUDIT文を使用して、統合監査ポリシーを使用できます。

22.2.1 統合監査ポリシーおよびAUDITを使用したアクティビティの監査について

統合監査ポリシーおよび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イベントを自動的に取得します。

22.2.2 統合監査ポリシーの作成のベスト・プラクティス

データベースで複数のポリシーを一度に有効にできますが、有効にするポリシーの数を制限することが理想的です。

統合監査ポリシーの構文は、データベースで必要なすべての監査設定を網羅する1つのポリシーを作成できるように設計されています。複数の小さいポリシーを作成するのではなく、関連するオプションを1つのポリシーにグループ化することをお薦めします。これにより、ポリシーをより簡単に管理できるようになります。たとえば、事前定義の統合監査ポリシーを使用したアクティビティの監査で説明されているデフォルトの監査ポリシーには、それぞれ1つの統合監査ポリシーに複数の監査設定が含まれています。

ユーザー・セッションで有効な監査ポリシーの数を制限すると、次の利点が得られます。

  • 監査ポリシーの詳細をセッションのUGAメモリーにロードすることに伴うログオン・オーバーヘッドを軽減します。有効なポリシーの数が減ると、ポリシー情報のロードにかかる時間が短縮します。

  • UGAメモリーにキャッシュするのに必要なポリシーの数が減るため、セッションのUGAメモリー消費量が減ります。

  • 関連するイベントの監査レコードを生成するかどうかを決定する内部監査チェック機能が効率的になります。

22.2.3 統合監査ポリシーの作成の構文

統合監査ポリシーを作成するには、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人以上のユーザーに対してポリシーの適用または除外を実行したり、監査アクションの成功または失敗(あるいは両方)時に監査レコードが書き込まれるかどうかを指定できます。統合監査ポリシーの有効化およびユーザーとロールへの適用を参照してください。

22.2.4 ロールの監査

CREATE AUDIT POLICY文を使用して、データベース・ロールを監査できます。

22.2.4.1 ロールの監査について

ロールを監査すると、このロールに直接付与されたすべてのシステム権限がOracle Databaseによって監査されます。

ユーザー定義のロールを含むすべてのロールを監査できます。ROLES監査オプションでロールに対して共通の統合監査ポリシーを作成する場合、ロール・リストで共通ロールのみを指定する必要があります。このようなポリシーが有効な場合、Oracle Databaseは、共通ロールに対して共通のシステム権限と共通ロールに直接付与されているシステム権限をすべて監査します。共通ロールに対してローカルに付与されているシステム権限は監査されません。ロールが共通に付与されているかどうかを確認するには、DBA_ROLESデータ・ディクショナリ・ビューを問い合せます。ロールに付与された権限が共通に付与されたかどうかを確認するには、ROLE_SYS_PRIVSビューを問い合せます。

22.2.4.2 ロールの統合監査ポリシーの構成

ロールの使用を取得する統合監査ポリシーを作成するには、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文を使用して有効にする必要があります。

22.2.4.3 例: マルチテナント環境でのDBAロールの監査

マルチテナント環境で、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;

22.2.5 システム権限の監査

CREATE AUDIT POLICY文を使用して、システム権限を監査できます。

22.2.5.1 システム権限監査について

システム権限の監査では、システム権限を正常に使用するアクティビティ(READ ANY TABLEなど)を監査します。

この種の監査では、正常終了するために監査対象の権限を必要とするSQL文が記録されます。

1つの統合監査ポリシーに、権限監査およびアクション監査の両方のオプションを含めることができます。SYSなどの管理ユーザーの権限の使用は監査しないでください。かわりに、オブジェクト・アクションを監査してください。

ノート:

システム権限、オブジェクト、データベース・イベントなどを監査できます。ただし、データベース権限の使用状況(たとえば、指定のロールに付与されている権限はどれが使用されているか)を検索し、使用されている権限と使用されていない権限のレポートを生成する必要がある場合は、権限キャプチャを作成できます。詳細は、『Oracle Database Vault管理者ガイド』を参照してください。

22.2.5.2 監査できるシステム権限

ほとんどのシステム権限の使用を監査できます。

監査可能なシステム権限のリストを検索するには、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つのみ書き込まれます。

権限監査は、アクションが既存の所有者およびオブジェクト権限によってすでに許可されている場合は実行されません。権限監査がトリガーされるのは、権限が不十分な場合、つまりアクションを可能にする権限がシステム権限である場合のみです。たとえば、ユーザーSCOTTSELECT ANY TABLE権限が付与されており、SELECT ANY TABLEが監査対象であるとします。SCOTTが自分の表(たとえば、SCOTT.EMP)を選択した場合、SELECT ANY TABLE権限は使用されません。自分自身のスキーマ内でSELECT文を実行したため、監査レコードは生成されません。一方、SCOTTが他のスキーマ(たとえばHR.EMPLOYEES表)から選択すると、監査レコード生成されます。SCOTTは自分自身のスキーマ外にある表を選択したため、SELECT ANY TABLE権限を使用する必要がありました。

22.2.5.3 監査できないシステム権限

次のシステム権限は監査できません。

これらの権限は、次のとおりです。

  • INHERIT ANY PRIVILEGE

  • INHERIT PRIVILEGE

  • TRANSLATE ANY SQL

  • TRANSLATE SQL

22.2.5.4 システム権限の使用を取得するための統合監査ポリシーの構成

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文を使用して有効にする必要があります。

22.2.5.5 例: ANY権限を持つユーザーの監査

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;
22.2.5.6 例: 条件を使用するシステム権限の監査

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;
22.2.5.7 監査証跡でのシステム権限の統合監査ポリシーの表示方法

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オブジェクト権限を実行したかによって監査証跡で取得されるアクションが影響を受けます。

22.2.6 管理ユーザーの監査

統合監査ポリシーを作成して、SYSなどの管理ユーザー・アカウントのアクションを取得できます。

22.2.6.1 監査可能な管理ユーザー・アカウント

Oracle Databaseでは、管理権限に関連付けられている管理ユーザー・アカウントが用意されています。

表22-1に、デフォルトの管理ユーザー・アカウントと、通常関連付けられている管理権限を示します。

表22-1 管理ユーザーおよび管理権限

管理ユーザー・アカウント 管理権限

SYS

SYSDBA

PUBLIC脚注1

SYSOPER

SYSASM

SYSASM

SYSBACKUP

SYSBACKUP

SYSDG

SYSDG

SYSKM

SYSKM

脚注1

PUBLICはユーザーPUBLICを示し、SYSOPER管理権限でログインしている場合に有効なユーザーです。これはPUBLICロールを示しません。

22.2.6.2 管理者アクティビティを取得するための統合監査ポリシーの構成

CREATE AUDIT POLICY文で、管理ユーザーを監査できます。

  • 管理ユーザーを監査する場合は、統合監査ポリシーを作成して、非管理ユーザーに適用する場合と同じように、このポリシーをユーザーに適用します。管理ユーザーによるトップ・レベルの文は、データベースを開くまで強制的に監査されます。

22.2.6.3 例: SYSユーザーの監査

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;

22.2.7 オブジェクト・アクションの監査

CREATE AUDIT POLICY文を使用して、オブジェクト・アクションを監査できます。

22.2.7.1 オブジェクト・アクションの監査について

HR.EMPLOYEES表のUPDATE文など、特定のオブジェクトで実行されるアクションを監査できます。

監査は、オブジェクトに使用されたDDLおよびDML文を含むことができます。1つの統合監査ポリシーに、権限監査およびアクション監査の両方のオプションと、複数のオブジェクトの監査オプションのセットを含めることができます。

22.2.7.2 監査できるオブジェクト・アクション

オブジェクト・アクションの監査では、監査の対象を拡大または限定できます(すべてのユーザー・アクションの監査または一部のユーザー・アクションに限定した監査など)。

表22-2に、オブジェクト・レベルの標準データベース・アクションのオプションを示します。SELECT SQL文に対する監査ポリシーでは、SELECTアクションだけでなくREADアクションも取得されます。

表22-2 オブジェクト・レベルの標準データベース・アクションの監査オプション

オブジェクト 監査できるSQLアクション

ALTERAUDITCOMMENTDELETEFLASHBACKGRANTINDEXINSERTLOCKRENAMESELECTUPDATE

ビュー

AUDITCOMMENTDELETEFLASHBACKGRANTINSERTLOCKRENAMESELECTUPDATE

順序

ALTERAUDITGRANTSELECT

プロシージャ(トリガーを含む)

AUDIT, EXECUTE, GRANT

ファンクション

AUDIT, EXECUTE, GRANT

パッケージ

AUDIT, EXECUTE, GRANT

マテリアライズド・ビュー

ALTERAUDITCOMMENTDELETEINDEXINSERTLOCKSELECTUPDATE

マイニング・モデル

AUDITCOMMENTGRANTRENAMESELECT

ディレクトリ

AUDIT, GRANT, READ

ライブラリ

EXECUTE, GRANT

オブジェクト型

ALTER, AUDIT, GRANT

Javaスキーマ・オブジェクト(ソース、クラス、リソース)

AUDIT, EXECUTE, GRANT

22.2.7.3 オブジェクト・アクションの統合監査ポリシーの構成

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文を使用して有効にする必要があります。

22.2.7.4 例: SYSオブジェクトでのアクションの監査

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;
22.2.7.5 例: 1つのオブジェクトでの複数のアクションの監査

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;
22.2.7.6 例: オブジェクトでのアクションと権限の両方の監査

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アクセス・ドライバで使用されるプリプロセッサ・プログラムを含むディレクトリ・オブジェクトを作成するとします。ディレクトリ・オブジェクト内のこのプログラムを実行するすべてのユーザーを監査できます。

22.2.7.7 例: 表でのすべてのアクションの監査

CREATE AUDIT POLICY文で、表でのすべてのアクションを監査できます。

ALLキーワードを使用してすべてのアクションを監査できます。すべてのアクションの監査は機密オブジェクトに対してのみ実行することをお薦めします。ALLは、間接的なSELECT操作を取得する場合に便利です。例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;
22.2.7.8 例: データベースでのすべてのアクションの監査

CREATE AUDIT POLICY文で、データベースでのすべてのアクションを監査できます。

この監査ポリシー構成のすべての再帰的アクションであっても、多数の監査レコードが生成されてすぐに監査証跡がいっぱいになることを回避するには、CREATE AUDIT POLICY文にONLY TOPLEVEL句を含めます。ONLY TOPLEVELのかわりに、条件を使用してACTIONS ALLポリシーを作成し、レコードのサブセットのみを取得できます。

例22-10に、データベース全体ですべてのアクションを監査する方法を示します。

例22-10 データベースでのすべてのアクションの監査

CREATE AUDIT POLICY all_actions_pol ACTIONS ALL ONLY TOPLEVEL;

AUDIT POLICY all_actions_pol;
22.2.7.9 監査証跡でのオブジェクト・アクションの統合監査ポリシーの表示方法

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
22.2.7.10 ファンクション、プロシージャ、パッケージおよびトリガーの監査

ファンクション、プロシージャ、PL/SQLパッケージおよびトリガーを監査できます。

監査可能な領域は次のとおりです。

  • スタンドアロン・ファンクション、スタンドアロン・プロシージャおよびPL/SQLパッケージは個別に監査できます。

  • PL/SQLパッケージを監査すると、パッケージ内のすべてのファンクションおよびプロシージャが監査されます。

  • すべての実行の監査を使用可能にすると、データベース内のすべてのトリガーおよびPL/SQLパッケージ内のすべてのファンクションとプロシージャが監査されます。

  • PL/SQLパッケージ内のファンクションまたはプロシージャを個別に監査することはできません。

  • PL/SQLストアド・プロシージャまたはストアド・ファンクションでのEXECUTE操作を監査する場合は、監査目的での操作の成否を判断する際に、プロシージャまたはファンクションを検索してその実行を認証する機能のみが監査対象となります。したがって、WHENEVER NOT SUCCESSFUL句を指定すると、無効なオブジェクト・エラー、存在しないオブジェクト・エラー、および認証の失敗が監査されます。プロシージャまたはファンクションの実行時に検出されたエラーは監査されません。WHENEVER SUCCESSFUL句を指定すると、実行時にエラーが検出されたかどうかに関係なく、無効なオブジェクト・エラー、存在しないオブジェクト・エラー、および認証の失敗が監査されます。

22.2.7.11 Oracle Virtual Private Databaseの述語の監査

統合監査証跡では、Oracle Virtual Private Database (VPD)のポリシーで使用される述語を自動的に取得します。

VPD述語監査情報を取得するために統合監査ポリシーを作成する必要はありません。

このタイプの監査では、DML操作の一部として実行された述語式を識別できるため、DML操作の一部として生じる可能性のある他のアクションを識別するために役立ちます。たとえば、VPD述語を使用してデータベースに対して悪意のある攻撃が行われた場合、統合監査証跡を使用してその攻撃を追跡できます。ユーザーが作成したVPDポリシーの述語に加えて、Oracle Label SecurityおよびOracle Real Application Securityのポリシーの内部述語も取得されます。たとえば、Oracle Label Securityは、OLSポリシーを表に適用する一方で、VPDポリシーを内部的に作成します。Oracle Real Application Securityは、Oracle RASポリシーを有効にする一方で、VPDポリシーを生成します。

統合監査証跡では、この述語情報がUNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューのRLS_INFO列に書き込まれます。ファイングレイン監査ポリシーを使用している場合、これらのビューのRLS_INFO列にVPD述語情報も取得されます。

監査証跡では、オブジェクトに対して複数のVPDポリシーが実施されている場合、述語とその述語が対応するポリシー名を取得できます。監査証跡ではポリシー・スキーマとポリシー名が取得されるため、異なるポリシーから生成された述語を区別することができます。この情報はデフォルトでRLS_INFO列に連結されますが、Oracle Databaseに用意されたDBMS_AUDIT_UTIL PL/SQLパッケージのファンクションを使用すると、結果を読みやすい形式に再フォーマットできます。

次の例は、VPDポリシーの述語を監査する方法を示しています。

  1. 次のVPDポリシー関数を作成します。

    CREATE OR REPLACE FUNCTION auth_orders( 
      schema_var IN VARCHAR2,
      table_var  IN VARCHAR2
     )
     RETURN VARCHAR2
     IS
      return_val VARCHAR2 (400);
     BEGIN
      return_val := 'SALES_REP_ID = 159';
      RETURN return_val;
     END auth_orders;
    /
  2. 次のVPDポリシーを作成します。

    BEGIN
      DBMS_RLS.ADD_POLICY (
        object_schema    => 'oe',
        object_name      => 'orders',
        policy_name      => 'orders_policy',
        function_schema  => 'sec_admin',
        policy_function  => 'auth_orders',
        statement_types  => 'select, insert, update, delete'
       );
     END;
    /
  3. 次の統合監査ポリシーを作成して有効にします。

    CREATE AUDIT POLICY oe_pol 
     ACTIONS SELECT ON OE.ORDERS;
    
    AUDIT POLICY oe_pol;
  4. ユーザーOEとして接続し、OE.ORDERS表を問い合せます。

    CONNECT OE
    Enter password: password
    
    SELECT COUNT(*) FROM ORDERS;
  5. AUDIT_ADMINロールを付与されたユーザーとして接続し、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せます。

    CONNECT sec_admin
    Enter password: password
    
    SELECT RLS_INFO FROM UNIFIED_AUDIT_TRAIL;

    次のような出力が表示されます。

    ((POLICY_TYPE=[3]'VPD'),(POLICY_SCHEMA=[9]'SEC_ADMIN'),(POLICY_NAME=[13]'ORDERS_POLICY'),(PREDICATE=[16]'SALES_REP_ID=159'));
  6. これらの詳細を抽出して該当する列に追加するために、DBMS_AUDIT_UTIL PL/SQLパッケージの適切なファンクションを実行します。

    統合監査の場合、DBMS_AUDIT_UTIL.DECODE_RLS_INFO_ATRAIL_UNIファンクションを実行する必要があります。

    例:

    SELECT DBUSERNAME, ACTION_NAME, OBJECT_NAME, SQL_TEXT, 
      RLS_PREDICATE, RLS_POLICY_TYPE, RLS_POLICY_OWNER, RLS_POLICY_NAME 
      FROM TABLE (DBMS_AUDIT_UTIL.DECODE_RLS_INFO_ATRAIL_UNI 
      (CURSOR (SELECT * FROM UNIFIED_AUDIT_TRAIL)));
    

    再フォーマットされた監査証跡の出力は、次のようになります。

    DBUSERNAME ACTION_NAME OBJECT_NAME SQL_TEXT
    ---------- ----------- ----------- ---------------------------
    RLS_PREDICATE       RLS_POLICY_TYPE RLS_POLICY_OWNER RLS_POLICY_NAME
    ------------------ ---------------  ---------------- ---------------
    OE         SELECT      ORDERS      SELECT COUNT(*) FROM ORDERS 
    SALES_REP_ID = 159  VPD             SEC_ADMIN        ORDERS_POLICY

関連項目:

22.2.7.12 Oracle Virtual Private Databaseポリシー関数の監査ポリシー

監査によって動的VPDポリシーや静的VPDポリシー、コンテキスト依存VPDポリシーが影響を受けることがあります。

  • 動的ポリシー: ポリシー関数が2回(SQL文の解析時に1回と実行時に1回)評価されます。結果として、各評価で2つの監査レコードが生成されます。

  • 静的ポリシー: ポリシー関数が1回評価され、SGA内にキャッシュされます。これにより、監査レコードは1つのみ生成されます。

  • 状況依存ポリシー: ポリシー関数が文の解析時に1回実行されます。これにより、監査レコードは1つのみ生成されます。

22.2.7.13 統合監査とエディション付きオブジェクト

エディション付きオブジェクトに統合監査ポリシーが付加されている場合、そのオブジェクトが表示されるすべてのエディションにそのポリシーが適用されます。

エディション付きオブジェクトが実現化されると、そのオブジェクトに付加されている統合監査ポリシーが新しい実際のオブジェクトに新たに付加されます。継承されたエディション付きオブジェクトに新たに統合監査ポリシーを適用すると、そのオブジェクトが実現化されます。

監査対象のオブジェクトが表示されるエディションを調べるには、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューのOBJECT_NAMEおよびOBJ_EDITION_NAME列を問い合せます。

関連項目:

エディションの詳細は、『Oracle Database開発ガイド』を参照してください。

22.2.8 READ ANY TABLEおよびSELECT ANY TABLE権限の監査

CREATE AUDIT POLICY文で、READ ANY TABLE権限とSELECT ANY TABLE権限を監査できます。

22.2.8.1 READ ANY TABLEおよびSELECT ANY TABLE権限の監査について

READ ANY TABLEおよびSELECT 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権限が記録されます。

22.2.8.2 READオブジェクト権限操作を取得する統合監査ポリシーの作成

READオブジェクト権限操作を取得する統合監査ポリシーを作成できます。

  • すべてのREADオブジェクト操作を取得する統合監査ポリシーを作成する場合、READ文ではなくSELECT文に対するポリシーを作成します。

例:

CREATE AUDIT POLICY read_hr_employees
 ACTIONS SELECT ON HR.EMPLOYEES;

監査できる他のオブジェクト・アクションの場合と同様に、SELECTオブジェクトの操作に対しても、SELECT文に関するポリシーを作成します。

22.2.8.3 統合監査証跡でのREAD ANY TABLEおよびSELECT ANY TABLEの取得方法

統合監査証跡では、ユーザーにREAD ANY TABLEまたはSELECT ANY TABLE権限が付与されているかどうかに基づいてSELECT動作が取得されます。

表22-3は、統合監査証跡によるこれらのアクションの取得方法を示しています。

表22-3 READ ANY TABLEおよびSELECT ANY TABLEに対する監査動作

ユーザーが発行した文 ユーザーに付与されている権限 監査されるシステム権限 予期されるUNIFIED_AUDIT_TRAILの動作

SELECT

SELECT ANY TABLE

SELECT ANY TABLE

SYSTEM_PRIVILEGE_USEDに挿入されるレコード:

SELECT ANY TABLE

SELECT

SELECT ANY TABLE

READ ANY TABLE

レコードなし

SELECT

SELECT ANY TABLE

SELECT ANY TABLEREAD ANY TABLEの両方

SYSTEM_PRIVILEGE_USEDに挿入されるレコード:

SELECT ANY TABLE

SELECT

SELECT ANY TABLE

SELECT ANY TABLEREAD ANY TABLEも対象外

レコードなし

SELECT

READ ANY TABLE

SELECT ANY TABLE

レコードなし

SELECT

READ ANY TABLE

READ ANY TABLE

SYSTEM_PRIVILEGE_USEDに挿入されるレコード:

READ ANY TABLE

SELECT

READ ANY TABLE

SELECT ANY TABLEREAD ANY TABLEの両方

SYSTEM_PRIVILEGE_USEDに挿入されるレコード:

READ ANY TABLE

SELECT

READ ANY TABLE

SELECT ANY TABLEREAD ANY TABLEも対象外

レコードなし

SELECT

SELECT ANY TABLEREAD ANY TABLEの両方

SELECT ANY TABLE

READ ANY TABLEがアクセスに使用されたため、レコードなし

SELECT

SELECT ANY TABLEREAD ANY TABLEの両方

READ ANY TABLE

SYSTEM_PRIVILEGE_USEDに挿入されるレコード:

READ ANY TABLE

SELECT

SELECT ANY TABLEREAD ANY TABLEの両方

SELECT ANY TABLEREAD ANY TABLEの両方

SYSTEM_PRIVILEGE_USEDに挿入されるレコード:

READ ANY TABLE

SELECT

SELECT ANY TABLEREAD ANY TABLEの両方

SELECT ANY TABLEREAD ANY TABLEも対象外

レコードなし

SELECT

SELECT ANY TABLEREAD ANY TABLEも対象外

SELECT ANY TABLE

レコードなし

SELECT

SELECT ANY TABLEREAD ANY TABLEも対象外

READ ANY TABLE

レコードなし

SELECT

SELECT ANY TABLEREAD ANY TABLEも対象外

SELECT ANY TABLEREAD ANY TABLEの両方

レコードなし

SELECT

SELECT ANY TABLEREAD ANY TABLEも対象外

SELECT ANY TABLEREAD ANY TABLEも対象外

レコードなし

SELECT ... FOR UPDATE

SELECT ANY TABLE

SELECT ANY TABLE

SYSTEM_PRIVILEGE_USEDに挿入されるレコード:

SELECT ANY TABLE

SELECT ... FOR UPDATE

SELECT ANY TABLE

READ ANY TABLE

レコードなし

SELECT ... FOR UPDATE

SELECT ANY TABLE

SELECT ANY TABLEREAD ANY TABLEの両方

SYSTEM_PRIVILEGE_USEDに挿入されるレコード:

SELECT ANY TABLE

SELECT ... FOR UPDATE

SELECT ANY TABLE

SELECT ANY TABLEREAD ANY TABLEも対象外

レコードなし

SELECT ... FOR UPDATE

READ ANY TABLE

SELECT ANY TABLE

レコードなし

SELECT ... FOR UPDATE

READ ANY TABLE

READ ANY TABLE

レコードなし

SELECT ... FOR UPDATE

READ ANY TABLE

SELECT ANY TABLEREAD ANY TABLEの両方

レコードなし

SELECT ... FOR UPDATE

READ ANY TABLE

SELECT ANY TABLEREAD ANY TABLEも対象外

レコードなし

SELECT ... FOR UPDATE

SELECT ANY TABLEREAD ANY TABLEの両方

SELECT ANY TABLE

SYSTEM_PRIVILEGE_USEDに挿入されるレコード:

SELECT ANY TABLE

SELECT ... FOR UPDATE

SELECT ANY TABLEREAD ANY TABLEの両方

READ ANY TABLE

READ ANY TABLEがアクセスに使用されたため、レコードなし

SELECT ... FOR UPDATE

SELECT ANY TABLEREAD ANY TABLEの両方

SELECT ANY TABLEREAD ANY TABLEの両方

SYSTEM_PRIVILEGE_USEDに挿入されるレコード:

SELECT ANY TABLE

SELECT ... FOR UPDATE

SELECT ANY TABLEREAD ANY TABLEの両方

SELECT ANY TABLEREAD ANY TABLEも対象外

レコードなし

SELECT ... FOR UPDATE

SELECT ANY TABLEREAD ANY TABLEも対象外

SELECT ANY TABLE

レコードなし

SELECT ... FOR UPDATE

SELECT ANY TABLEREAD ANY TABLEも対象外

READ ANY TABLE

レコードなし

SELECT ... FOR UPDATE

SELECT ANY TABLEREAD ANY TABLEも対象外

SELECT ANY TABLEREAD ANY TABLEの両方

レコードなし

SELECT ... FOR UPDATE

SELECT ANY TABLEREAD ANY TABLEも対象外

SELECT ANY TABLEREAD ANY TABLEも対象外

レコードなし

22.2.9 複数層環境におけるSQL文および権限の監査

統合監査ポリシーを作成して、複数層環境のクライアントのアクティビティを監査できます。

複数層環境では、クライアントの識別情報をすべての層を通して保持できます。したがって、クライアントにかわって中間層アプリケーションにより行われたアクションを、ポリシーの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_SESSIONIDACTION_NAMEおよびSESSION_ID列を問い合せることで、プロキシ・ユーザーを監査する方法を示します。このシナリオでは、データベース・ユーザーとプロキシ・ユーザーの両方のアカウントがデータベースに認識されます。セッション・プーリングを使用できます。

図22-1 プロキシ・ユーザーの監査

図22-1の説明が続きます
「図22-1 プロキシ・ユーザーの監査」の説明

図22-2に、DBA_AUDIT_TRAILデータ・ディクショナリ・ビューのCLIENT_ID列を問い合せることで、複数のデータベース・セッションにわたるクライアント識別子情報を監査する方法を示します。この例では、クライアント識別子はCLIENT_Aに設定されています。図22-1に示すプロキシ・ユーザー/データベース・ユーザーの例と同様に、セッション・プーリングを使用できます。

図22-2 複数のセッションにわたるクライアント識別子情報の監査

図22-2の説明が続きます
「図22-2 複数のセッションにわたるクライアント識別子情報の監査」の説明

22.2.10 統合監査ポリシーの条件の作成

CREATE AUDIT POLICY文を使用すると、統合監査ポリシーの条件を作成できます。

22.2.10.1 統合監査ポリシーについて

SYS_CONTEXTネームスペースと属性のペアを使用して条件を指定する統合監査ポリシーを作成できます。

たとえば、監査条件を満たす可能性のある特定のユーザーや、監査条件を満たすコンピュータ・ホストにこの監査条件を適用します。

監査条件が満たされると、Oracle Databaseによってイベントのレコードが監査されます。条件定義の一部として、監査条件が文の発生、セッションまたはデータベース・インスタンスごとに評価されるかどうかを指定する必要があります。

ノート:

監査条件では、安全なアプリケーション・コンテキストと安全でないアプリケーション・コンテキストの両方を使用できます。

22.2.10.2 条件を使用した統合監査ポリシーの構成

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は、次のタイプの関数を使用します。

      数値関数: BITANDCEILFLOORLN POWERなど

      文字値を戻す文字関数: CONCATLOWERUPPERなど

      数値を戻す文字関数: LENGTHINSTRなど

      環境および識別子関数: SYS_CONTEXTUIDなど。SYS_CONTEXTでは、ほとんどの場合、『Oracle Database SQL言語リファレンス』に説明されているUSERENVネームスペースを使用できます。

    • operationには、ANDORINNOT 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言語リファレンス』を参照してください。
22.2.10.3 例: SQL*Plusへのアクセスの監査

CREATE AUDIT POLICY文で、SQL*Plusへのアクセスを監査できます。

例22-11に、ロールemp_adminおよびsales_adminが直接付与されたユーザーによる、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 USERS WITH GRANTED ROLES emp_admin, sales_admin;
22.2.10.4 例: 特定のホストにはないアクションの監査

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;
22.2.10.5 例: システム全体のアクションおよびスキーマ固有のアクションの両方の監査

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;
22.2.10.6 例: 文の発生ごとの条件の監査

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;
22.2.10.7 例: 現在の管理ユーザー・セッションの統合監査セッションID

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パラメータを使用します。完全な統合監査では、SESSIONIDUNIFIED_AUDIT_SESSIONIDの値は同じです。

22.2.10.8 例: 現在の非管理ユーザー・セッションの統合監査セッションID

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
22.2.10.9 監査証跡での条件からの監査レコードの表示方法

統合監査ポリシーからの監査レコードの条件は、監査証跡には表示されません。

条件がtrueと評価され、レコードが書き込まれると、レコードは監査証跡に表示されます。UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せることで、監査証跡をチェックできます。

22.2.11 アプリケーション・コンテキスト値の監査

AUDIT文を使用して、アプリケーション・コンテキスト値を監査できます。

22.2.11.1 アプリケーション・コンテキスト値の監査について

統合監査証跡でアプリケーション・コンテキスト値を取得できます。

この機能では、監査対象の文の実行中にデータベース・アプリケーションによって設定されるアプリケーション・コンテキスト値を取得します。

Oracle Label Securityを監査する場合は、この機能により、データベース監査証跡のセッション・ラベルのアクティビティが取得されます。監査証跡では、指定したコンテキストと属性値のペアで取得されたすべての値が記録されます。

アプリケーション・コンテキストの監査設定または監査ポリシーには、セッションの静的セマンティクがあります。つまり、ユーザーに対して新しいポリシーが有効になると、後続のユーザー・セッションにこのコマンドの結果が表示されます。セッションが確立されると、ポリシーとコンテキストの設定がロードされ、このセッションは後続のAUDIT文の影響を受けません。

マルチテナント環境では、アプリケーション・コンテキストの監査ポリシーは現在のPDBのみに適用されます。

関連項目:

22.2.11.2 アプリケーション・コンテキストの監査設定の構成

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データ・ディクショナリ・ビューを問い合せます。

22.2.11.3 アプリケーション・コンテキストの監査設定の無効化

NOAUDIT文で、アプリケーション・コンテキストの監査設定を無効にします。

  • アプリケーション・コンテキストの監査設定を無効にするには、NOAUDIT文でネームスペースと属性設定を指定します。属性は任意の順序で入力できます(対応するAUDIT CONTEXT文で使用される順序に一致させる必要はありません)。

例:

NOAUDIT CONTEXT NAMESPACE client_context ATTRIBUTES module,
 CONTEXT NAMESPACE ols_session_labels ATTRIBUTES ols_pol1, ols_pol3
 BY USERS WITH GRANTED ROLES emp_admin;

現在監査されているアプリケーション・コンテキストを検索するには、AUDIT_UNIFIED_CONTEXTSデータ・ディクショナリ・ビューを問い合せます。

22.2.11.4 例: デフォルト・データベースでのアプリケーション・コンテキスト値の監査

AUDIT CONTEXT NAMESPACE文で、アプリケーション・コンテキスト値を監査できます。

例22-17に、ユーザーappuser1によるmoduleおよびaction属性のclientcontextアプリケーション値の監査方法を示します。

例22-17 デフォルト・データベースでのアプリケーション・コンテキスト値の監査

AUDIT CONTEXT NAMESPACE clientcontext ATTRIBUTES module, action 
BY appuser1;
22.2.11.5 例: Oracle Label Securityのアプリケーション・コンテキスト値の監査

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;
22.2.11.6 監査証跡での監査対象のアプリケーション・コンテキストの表示方法

UNIFIED_AUDIT_POLICIESデータ・ディクショナリ・ビューはアプリケーション・コンテキストの監査イベントを表示します。

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

22.2.12 Oracle Database Real Application Securityイベントの監査

CREATE AUDIT POLICY文を使用して、Oracle Database Real Application Securityイベントを監査できます。

22.2.12.1 Oracle Database Real Application Securityイベントの監査について

Oracle Database Real Application Securityイベントを監査するには、AUDIT_ADMINロールが必要です。

監査証跡にアクセスするには、Real Application Security固有の列がXS_で始まるUNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せます。Oracle Real Application Securityポリシーが有効なときに作成される、内部的に生成されたVPD述語に関する監査情報を確認する場合は、RLS_INFO列を問い合せることができます。

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の統合監査ポリシーが有効なユーザーのリストを表示します。

22.2.12.2 Oracle Database Real Application Securityの監査可能なイベント

Oracle Databaseには、CREATE USERUPDATE 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
...
22.2.12.3 Oracle Database Real Application Securityのユーザー、権限およびロールの監査イベント

統合監査証跡では、ユーザー、権限およびロールについてOracle Database Real Application Securityのイベントを取得できます。

表22-4では、これらのイベントについて説明します。

表22-4 Oracle Database Real Application Securityのユーザー、権限およびロールの監査イベント

監査イベント 説明

CREATE USER

XS_PRINCIPAL.CREATE_USERプロシージャを使用してOracle Database Real Application Securityのユーザー・アカウントを作成します。

UPDATE USER

次のプロシージャを使用してOracle Database Real Application Securityのユーザー・アカウントを更新します。

  • XS_PRINCIPAL.SET_EFFECTIVE_DATES

  • XS_PRINCIPAL.SET_USER_DEFAULT_ROLES_ALL

  • XS_PRINCIPAL.SET_USER_SCHEMA

  • XS_PRINCIPAL.SET_GUID

  • XS_PRINCIPAL.SET_USER_STATUS

  • XS_PRINCIPAL.SET_DESCRIPTION

DELETE USER

XS_PRINCIPAL.DELETE_PRINCIPALプロシージャを使用してOracle Database Real Application Securityのユーザー・アカウントを削除します。

AUDIT_GRANT_PRIVILEGE

GRANT_SYSTEM_PRIVILEGE権限を監査します

AUDIT_REVOKE_PRIVILEGE

REVOKE_SYSTEM_PRIVILEGE権限を監査します

CREATE ROLE

XS_PRINCIPAL.CREATE_ROLEプロシージャを使用してOracle Database Real Application Securityのロールを作成します。

UPDATE ROLE

次のプロシージャを使用してOracle Database Real Application Securityのロールを更新します。

  • XS_PRINCIPAL.SET_DYNAMIC_ROLE_SCOPE

  • XS_PRINCIPAL.SET_DYNAMIC_ROLE_DURATION

  • XS_PRINCIPAL.SET_EFFECTIVE_DATES

  • XS_PRINCIPAL.SET_ROLE_DEFAULT

DELETE ROLE

XS_PRINCIPAL.DELETE_ROLEプロシージャを使用してOracle Database Real Application Securityのロールを削除します

GRANT ROLE

XS_PRINCIPAL.GRANT_ROLESプロシージャを使用してOracle Database Real Application Securityのロールを付与します。

REVOKE ROLE

XS_PRINCIPAL.REVOKE_ROLESプロシージャを使用してOracle Database Real Application Securityのロールを取り消し、付与されたすべてのロールをXS_PRINCIPAL.REVOKE_ALL_GRANTED_ROLESプロシージャを使用して取り消します。

ADD PROXY

XS_PRINCIPAL.ADD_PROXY_USERプロシージャを使用してOracle Database Real Application Securityのプロキシ・ユーザー・アカウントを追加し、XS_PRINCIPAL.ADD_PROXY_TO_SCHEMAプロシージャを使用してデータベース・ユーザーにプロキシを追加します

REMOVE PROXY

XS_PRINCIPAL.REMOVE_PROXY_USERXS_PRINCIPAL.REMOVE_ALL_PROXY_USERSおよびXS_PRINCIPAL.REMOVE_PROXY_FROM_SCHEMA PROCEDURESを使用して、Oracle Database Real Application Securityのプロキシ・ユーザー・アカウントを削除します。

SET USER PASSWORD

XS_PRINCIPAL.SET_PASSWORDプロシージャを使用してOracle Database Real Application Securityのユーザー・アカウントのパスワードを設定します。

SET USER VERIFIER

XS_PRINCIPAL.SET_VERIFIERプロシージャを使用してOracle Database Real Application Securityのプロキシ・ユーザー・アカウントのベリファイアを設定します。

22.2.12.4 Oracle Database Real Application Securityのセキュリティ・クラスおよびACLの監査イベント

統合監査証跡では、Oracle Database Real Application Securityのセキュリティ・クラスおよびACLの監査イベントを取得できます。

表22-5では、これらのイベントについて説明します。

表22-5 Oracle Database Real Application Securityのセキュリティ・クラスおよびACLの監査イベント

監査イベント 説明

CREATE SECURITY CLASS

XS_SECURITY_CLASS.CREATE_SECURITY_CLASSプロシージャを使用してセキュリティ・クラスを作成します。

UPDATE SECURITY CLASS

次のプロシージャを使用してセキュリティ・クラスを作成します。

  • XS_SECURITY_CLASS.SET_DEFAULT_ACL

  • XS_SECURITY_CLASS.ADD_PARENTS

  • XS_SECURITY_CLASS.REMOVE_ALL_PARENTS

  • XS_SECURITY_CLASS.REMOVE_PARENTS

  • XS_SECURITY_CLASS.ADD_PRIVILEGES

  • XS_SECURITY_CLASS.REMOVE_ALL_PRIVILEGES

  • XS_SECURITY_CLASS.ADD_IMPLIED_PRIVILEGES

  • XS_SECURITY_CLASS.REMOVE_IMPLIED_PRIVILEGES

  • XS_SECURITY_CLASS.REMOVE_ALL_IMPLIED_PRIVILEGES

  • XS_SECURITY_CLASS.SET_DESCRIPTION

DELETE SECURITY CLASS

XS_SECURITY_CLASS.DELETE_SECURITY_CLASSプロシージャを使用してセキュリティ・クラスを削除します。

CREATE ACL

XS_ACL.CREATE_ACLプロシージャを使用してアクセス制御リスト(ACL)を作成します。

UPDATE ACL

次のプロシージャを使用してACLを更新します。

  • XS_ACL.APPEND_ACES

  • XS_ACL.REMOVE_ALL_ACES

  • XS_ACL.SET_SECURITY_CLASS

  • XS_ACL.SET_PARENT_ACL

  • XS_ACL.ADD_ACL_PARAMETER

  • XS_ACL.REMOVE_ALL_ACL_PARAMETERS

  • XS_ACL.REMOVE_ACL_PARAMETER

  • XS_ACL.SET_DESCRIPTION

DELETE ACL

XS_ACL.DELETE_ACLプロシージャを使用してACLを削除します。

CREATE DATA SECURITY-

XS_DATA_SECURITY.CREATE_DATA_SECURITYプロシージャを使用してデータ・セキュリティ・ポリシーを作成します。

UPDATE DATA SECURITY

次のプロシージャを使用してデータ・セキュリティ・ポリシーを更新します。

  • XS_DATA_SECURITY.CREATE_ACL_PARAMETER

  • XS_DATA_SECURITY.DELETE_ACL_PARAMETER

  • XS_DATA_SECURITY.SET_DESCRIPTION

DELETE DATA SECURITY

XS_DATA_SECURITY.DELETE_DATA_SECURITYプロシージャを使用してデータ・セキュリティ・ポリシーを削除します。

ENABLE DATA SECURITY

XS_DATA_SECURITY.ENABLE_OBJECT_POLICYプロシージャを使用して、データベース表またはビューの拡張可能データ・セキュリティを有効にします。

DISABLE DATA SECURITY

XS_DATA_SECURITY.DISABLE_XDSプロシージャを使用して、データベース表またはビューの拡張可能データ・セキュリティを無効にします。

22.2.12.5 Oracle Database Real Application Securityのセッションの監査イベント

統合監査証跡では、Oracle Database Real Application Securityのセッションの監査イベントを取得できます。

表22-4では、これらのイベントについて説明します。

表22-6 Oracle Database Real Application Securityのセッションの監査イベント

監査イベント 説明

CREATE SESSION

DBMS_XS_SESSIONS.CREATE_SESSIONプロシージャを使用してセッションを作成します。

DESTROY SESSION

DBMS_XS_SESSIONS.DESTROY_SESSIONプロシージャを使用してセッションを破棄します。

CREATE SESSION NAMESPACE

DBMS_XS_SESSIONS.CREATE_NAMESPACEプロシージャを使用してネームスペースを作成します。

DELETE SESSION NAMESPACE

DBMS_XS_SESSIONS.DELETE_NAMESPACEプロシージャを使用してネームスペースを削除します。

CREATE NAMESPACE ATTRIBUTE

DBMS_XS_SESSIONS.CREATE_ATTRIBUTEプロシージャを使用してネームスペース属性を作成します。

SET NAMESPACE ATTRIBUTE

DBMS_XS_SESSIONS.SET_ATTRIBUTEプロシージャを使用してネームスペース属性を設定します。

GET NAMESPACE ATTRIBUTE

DBMS_XS_SESSIONS.GET_ATTRIBUTEプロシージャを使用してネームスペース属性を取得します。

DELETE NAMESPACE ATTRIBUTE

DBMS_XS_SESSIONS.DELETE_ATTRIBUTEプロシージャを使用してネームスペース属性を削除します。

CREATE NAMESPACE TEMPLATE

XS_NS_TEMPLATE.CREATE_NS_TEMPLATEプロシージャを使用してネームスペース属性を作成します。

UPDATE NAMESPACE TEMPLATE

次のプロシージャを使用してネームスペース属性を更新します。

  • XS_NS_TEMPLATE.SET_HANDLER

  • XS_NS_TEMPLATE.ADD_ATTRIBUTES

  • XS_NS_TEMPLATE.REMOVE_ALL_ATTRIBUTES

  • XS_NS_TEMPLATE.REMOVE_ATTRIBUTES

  • XS_NS_TEMPLATE.SET_DESCRIPTION

DELETE NAMESPACE TEMPLATE

XS_NS_TEMPLATE.DELETE_NS_TEMPLATEプロシージャを使用してネームスペースを削除します。

ADD GLOBAL CALLBACK

DBMS_XS_SESSIONS.ADD_GLOBAL_CALLBACKプロシージャを使用してグローバル・コールバックを追加します。

DELETE GLOBAL CALLBACK

DBMS_XS_SESSIONS.DELETE_GLOBAL_CALLBACKプロシージャを使用してグローバル・コールバックを削除します。

ENABLE GLOBAL CALLBACK

DBMS_XS_SESSIONS.ENABLE_GLOBAL_CALLBACKプロシージャを使用してグローバル・コールバックを有効にします。

SET COOKIE

DBMS_XS_SESSIONS.SET_SESSION_COOKIEプロシージャを使用してセッションCookieを設定します。

SET INACTIVE TIMEOUT

DBMS_XS_SESSIONS.SET_INACTIVITY_TIMEOUTプロシージャを使用して、無効なセッションのタイムアウト時間を設定します。

SWITCH USER

DBMS_XS_SESSIONS.SWITCH_USERプロシージャを使用して、指定したユーザーで新しく初期化されたセキュリティ・コンテキストに現在の軽量ユーザー・セッションのセキュリティ・コンテキストを設定します。

ASSIGN USER

DBMS_XS_SESSIONS.ASSIGN_USERプロシージャを使用して、指定したユーザーに対して動的ロールを1つ以上割り当てまたは削除します。

ENABLE ROLE

DBMS_XS_SESSIONS.ENABLE_ROLEプロシージャを使用して、軽量ユーザー・セッションのロールを有効にします。

DISABLE ROLE

DBMS_XS_SESSIONS.DISABLE_ROLEプロシージャを使用して、軽量ユーザー・セッションのロールを無効にします。

22.2.12.6 Oracle Database Real Application SecurityのALLイベント

統合監査証跡では、Oracle Database Real Application SecurityのALLイベントを取得できます。

表22-7では、これらのイベントについて説明します。

表22-7 Oracle Database Real Application SecurityのALLイベント

監査イベント 説明

ALL

Real Application Securityのすべてのアクションを取得します。

22.2.12.7 Oracle Database 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文を使用して有効にする必要があります。

22.2.12.8 例: Real Application Securityのユーザー・アカウントの変更の監査

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;
22.2.12.9 例: Real Application Securityの統合監査ポリシーでの条件の使用

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;
22.2.12.10 監査証跡でのOracle Database Real Application Securityイベントの表示方法

DBA_XS_AUDIT_TRAILデータ・ディクショナリ・ビューはOracle Real Application Securityの監査イベントを表示します。

次の例では、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 

22.2.13 Oracle Recovery Managerイベントの監査

CREATE AUDIT POLICY文を使用して、Oracle Recovery Managerイベントを監査できます。

22.2.13.1 Oracle Recovery Managerイベントの監査について

UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューでは、Oracle Recovery Managerの監査イベントをRMAN_columnに自動的に格納します。

他のOracle Databaseコンポーネントと異なり、Oracle Recovery Managerのイベントには統合監査ポリシーを作成しません。

ただし、UNIFIED_AUDIT_TRAILビューを問い合せて、これらのイベントを確認するには、AUDIT_ADMINまたはAUDIT_VIEWERロールが必要です。SYSBACKUPまたはSYSDBA管理権限がない場合は、V$RMAN_STATUSV$RMAN_BACKUP_JOB_DETAILSなどのビューを問い合せて、Recovery Managerジョブに関する追加情報を検索できます。

22.2.13.2 Oracle Recovery Managerの統合監査証跡イベント

統合監査証跡では、Oracle Recovery Managerのイベントを取得します。

表22-8では、これらのイベントについて説明します。

表22-8 UNIFIED_AUDIT_TRAILビューのOracle Recovery Manager列

Recovery Managerの列 説明

RMAN_SESSION_RECID

Recovery Managerのセッション識別子。この列とRMAN_SESSION_STAMP列を組み合せることで、Recovery Managerジョブを一意に識別します。Recovery ManagerのセッションIDは、Recovery Managerジョブを識別する制御ファイルのRECID値です。(Recovery ManagerのセッションIDはユーザー・セッションIDと同じではありません。)

RMAN_SESSION_STAMP

セッションのタイムスタンプ。この列とRMAN_SESSION_RECID列を組み合せることで、Recovery Managerジョブを識別します。

RMAN_OPERATION

ジョブによって実行されるRecovery Manager操作。Recovery Managerのセッション内の操作ごとに行が1つ追加されます。たとえば、バックアップ・ジョブには、BACKUPRMAN_OPERATION値として含まれます。

RMAN_OBJECT_TYPE

Recovery Managerのセッションに含まれるオブジェクトのタイプ。これには、次のいずれかの値が含まれます。Recovery Managerのセッションがこれらの複数を満たさない場合は、プリファレンスが次の順序(リストの上から下)で指定されます。

  1. DB FULL (Database Full)は、データベースの全体バックアップを示します。

  2. RECVR AREAは、高速リカバリ領域を示します。

  3. DB INCR (Database Incremental)は、データベースの増分バックアップを示します。

  4. DATAFILE FULLは、データ・ファイルの全体バックアップを示します。

  5. DATAFILE INCRは、データ・ファイルの増分バックアップを示します。

  6. ARCHIVELOGは、アーカイブREDOログ・ファイルを示します。

  7. CONTROLFILEは、制御ファイルを示します。

  8. SPFILEは、サーバー・パラメータ・ファイルを示します。

  9. BACKUPSETは、バックアップ・ファイルを示します。

RMAN_DEVICE_TYPE

Recovery Managerのセッションに関連付けられているデバイス。この列は、DISKSBT (システム・バックアップ・テープ)または* (アスタリスク)になります。アスタリスクは、複数のデバイスを示します。ほとんどの場合、値はDISKおよびSBTになります。

22.2.13.3 監査証跡でのOracle Recovery Managerの監査イベントの表示方法

UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューはOracle Recovery Managerの監査イベントを表示します。

表22-8に、Oracle Recovery Manager固有の監査データを検索するために問合せ可能な、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューの列を示します。

例:

SELECT RMAN_OPERATION FROM UNIFIED_AUDIT_TRAIL 
WHERE RMAN_OBJECT_TYPE = 'DB FULL';

RMAN_OPERATION 
---------------
BACKUP 

22.2.14 Oracle Database Vaultイベントの監査

Oracle Database Vault環境で、CREATE AUDIT POLICY文を使用してDatabase Vaultアクティビティを監査できます。

22.2.14.1 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固有の統合監査ポリシーの結果も取得します。

22.2.14.2 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管理者ガイドを参照してください

22.2.14.3 Oracle Database Vaultの統合監査証跡イベントについて

Oracle Database Vault環境の監査証跡は、すべての構成変更やDatabase Vaultポリシーの変更の試行を取得します。

これは、既存のDatabase Vaultのポリシーに対するユーザーの違反も取得します。

次の種類のOracle Database Vaultイベントを監査できます。

  • Oracle Database Vaultのポリシーに対するすべての構成変更または変更の試行。Database Vault管理者による変更および権限のないユーザーによる試行の両方が取得されます。

  • 既存のDatabase Vaultのポリシーに対するユーザーの違反。たとえば、ユーザーが作業時間以外に特定のスキーマ表にアクセスできないようにするポリシーを作成すると、監査証跡によって、このアクティビティが取得されます。

22.2.14.4 Oracle Database Vaultのレルムの監査イベント

統合監査証跡によってOracle Database Vaultのレルムのイベントが取得されます。

表22-9では、これらのイベントについて説明します。

表22-9 Oracle Database Vaultのレルムの監査イベント

監査イベント 説明

CREATE_REALM

DVSYS.DBMS_MACADM.CREATE_REALMプロシージャを使用してレルムを作成します。

UPDATE_REALM

DVSYS.DBMS_MACADM.UPDATE_REALMプロシージャを使用してレルムを更新します。

RENAME_REALM

DVSYS.DBMS_MACADM.RENAME_REALMプロシージャを使用してレルムの名前を変更します。

DELETE_REALM

DVSYS.DBMS_MACADM.DELETE_REALMプロシージャを使用してレルムを削除します。

DELETE_REALM_CASCADE

DVSYS.DBMS_MACADM.DELETE_REALM_CASCADEプロシージャを使用して、レルムおよび関連するDatabase Vaultの構成情報を削除します。

ADD_AUTH_TO_REALM

DVSYS.DBMS_MACADM.ADD_AUTH_TO_REALMプロシージャを使用して、レルムに認可を追加します。

DELETE_AUTH_FROM_REALM

DVSYS.DBMS_MACADM.DELETE_AUTH_FROM_REALMプロシージャを使用して、レルムから認可を削除します。

UPDATE_REALM_AUTH

DVSYS.DBMS_MACADM.UPDATE_REALM_AUTHORIZATIONプロシージャを使用して、レルム認可を更新します。

ADD_OBJECT_TO_REALM

DVSYS.DBMS_MACADM.ADD_AUTH_TO_REALMプロシージャを使用して、レルム認可にオブジェクトを追加します。

DELETE_OBJECT_FROM_REALM

DVSYS.DBMS_MACADM.DELETE_OBJECT_FROM_REALMプロシージャを使用して、レルム認可からオブジェクトを削除します。

22.2.14.5 Oracle Database Vaultのルール・セットおよびルールの監査イベント

統合監査証跡では、Oracle Database Vaultのルール・セットおよびルールの監査イベントを取得できます。

表22-10では、これらのイベントについて説明します。

表22-10 Oracle Database Vaultのルール・セットおよびルールの監査イベント

監査イベント 説明

CREATE_RULE_SET

DVSYS.DBMS_MACADM.CREATE_RULE_SETプロシージャを使用してルール・セットを作成します。

UPDATE_RULE_SET

DVSYS.DBMS_MACADM.UPDATE_RULE_SETプロシージャを使用してルール・セットを更新します。

RENAME_RULE_SET

DVSYS.DBMS_MACADM.RENAME_RULE_SETプロシージャを使用して、ルール・セットの名前を変更します。

DELETE_RULE_SET

DVSYS.DBMS_MACADM.DELETE_RULE_SETプロシージャを使用して、ルール・セットを削除します。

ADD_RULE_TO_RULE_SET

DVSYS.DBMS_MACADM.ADD_RULE_TO_RULE_SETプロシージャを使用して、既存のルール・セットにルールを追加します。

DELETE_RULE_FROM_RULE_SET

DVSYS.DBMS_MACADM.DELETE_RULE_FROM_RULE_SETプロシージャを使用して、既存のルール・セットからルールを削除します。

CREATE_RULE

DVSYS.DBMS_MACADM.CREATE_RULEプロシージャを使用してルールを作成します。

UPDATE_RULE

DVSYS.DBMS_MACADM.UPDATE_RULEプロシージャを使用してルールを更新します。

RENAME_RULE

DVSYS.DBMS_MACADM.RENAME_RULEプロシージャを使用して、ルールの名前を変更します。

DELETE_RULE

DVSYS.DBMS_MACADM.DELETE_RULEプロシージャを使用して、ルールを削除します。

SYNC_RULES

DVSYS.DBMS_MACADM.SYNC_RULESプロシージャを使用して、Oracle Database Vaultのルールとアドバンスト・キューイング・ルール・エンジンを同期します。

22.2.14.6 Oracle Database Vaultのコマンド・ルールの監査イベント

統合監査証跡では、Oracle Database Vaultのコマンド・ルールの監査イベントを取得できます。

表22-11では、これらのイベントについて説明します。

表22-11 Oracle Database Vaultのコマンド・ルールの監査イベント

監査イベント 説明

CREATE_COMMAND_RULE

DVSYS.DBMS_MACADM.CREATE_COMMAND_RULEプロシージャを使用して、コマンド・ルールを作成します。

DELETE_COMMAND_RULE

DVSYS.DBMS_MACADM.DELETE_COMMAND_RULEプロシージャを使用して、コマンド・ルールを削除します。

UPDATE_COMMAND_RULE

DVSYS.DBMS_MACADM.UPDATE_COMMAND_RULEプロシージャを使用して、コマンド・ルールを更新します。

22.2.14.7 Oracle Database Vaultのファクタの監査イベント

統合監査証跡では、Oracle Database Vaultのファクタ・イベントを取得できます。

表22-12では、これらのイベントについて説明します。

表22-12 Oracle Database Vaultのファクタの監査イベント

監査イベント 説明

CREATE_FACTOR_TYPE

DVSYS.DBMS_MACADM.CREATE_FACTOR_TYPEプロシージャを使用して、ファクタ・タイプを作成します。

DELETE_FACTOR_TYPE

DVSYS.DBMS_MACADM.DELETE_FACTOR_TYPEプロシージャを使用して、ファクタ・タイプを削除します。

UPDATE_FACTOR_TYPE

DVSYS.DBMS_MACADM.UPDATE_FACTOR_TYPEプロシージャを使用して、ファクタ・タイプを更新します。

RENAME_FACTOR_TYPE

DVSYS.DBMS_MACADM.RENAME_FACTOR_TYPEプロシージャを使用して、ファクタ・タイプの名前を変更します。

CREATE_FACTOR

DVSYS.DBMS_MACADM.CREATE_FACTORプロシージャを使用して、ファクタを作成します。

UPDATE_FACTOR

DVSYS.DBMS_MACADM.UPDATE_FACTORプロシージャを使用して、ファクタを更新します。

DELETE_FACTOR

DVSYS.DBMS_MACADM.DELETE_FACTORプロシージャを使用して、ファクタを削除します。

RENAME_FACTOR

DVSYS.DBMS_MACADM.RENAME_FACTORプロシージャを使用して、ファクタの名前を変更します。

ADD_FACTOR_LINK

DVSYS.DBMS_MACADM.ADD_FACTOR_LINKプロシージャを使用して、2つのファクタの親子関係を指定します。

DELETE_FACTOR_LINK

DVSYS.DBMS_MACADM.DELETE_FACTOR_LINKプロシージャを使用して、2つのファクタの親子関係を削除します。

ADD_POLICY_FACTOR

DVSYS.DBMS_MACADM.ADD_POLICY_FACTORプロシージャを使用して、ファクタのラベルをポリシーのOracle Label Securityラベルに含めることを指定します。

DELETE_POLICY_FACTOR

DBMS_MACADM.DELETE_POLICY_FACTORプロシージャを使用して、ポリシーのOracle Label Securityラベルとの関連付けからファクタ・ラベルを削除します。

CREATE_IDENTITY

DVSYS.DBMS_MACADM.CREATE_IDENTITYプロシージャを使用して、ファクタ・アイデンティティを作成します。

UPDATE_IDENTITY

DVSYS.DBMS_MACADM.UPDATE_IDENTITYプロシージャを使用して、ファクタ・アイデンティティを更新します。

CHANGE_IDENTITY_FACTOR

DVSYS.DBMS_MACADM.CHANGE_IDENTITY_FACTORプロシージャを使用して、アイデンティティを異なるファクタに関連付けます。

CHANGE_IDENTITY_VALUE

DVSYS.DBMS_MACADM.CHANGE_IDENTITY_VALUEプロシージャを使用して、アイデンティティの値を更新します。

DELETE_IDENTITY

DVSYS.DBMS_MACADM.DELETE_IDENTITYプロシージャを使用して、既存のファクタ・アイデンティティを削除します。

CREATE_IDENTITY_MAP

DVSYS.DBMS_MACADM.CREATE_IDENTITY_MAPプロシージャを使用して、ファクタ・アイデンティティ・マップを作成します。

DELETE_IDENTITY_MAP

DVSYS.DBMS_MACADM.DELETE_IDENTITY_MAPプロシージャを使用して、ファクタ・アイデンティティ・マップを削除します。

CREATE_DOMAIN_IDENTITY

DVSYS.DBMS_MACADM.CREATE_DOMAIN_IDENTITYプロシージャを使用して、Oracle Database Real Application Clustersデータベース・ノードをドメイン・ファクタ・アイデンティティに追加し、Oracle Label Securityポリシーに従ってラベルを付けます。

DROP_DOMAIN_IDENTITY

DVSYS.DBMS_MACADM.DROP_DOMAIN_IDENTITYプロシージャを使用して、ドメイン・ファクタ・アイデンティティからOracle RACノードを削除します。

22.2.14.8 Oracle Database Vaultのセキュア・アプリケーション・ロールの監査イベント

統合監査証跡では、Oracle Database Vaultのセキュア・アプリケーション・ロールの監査イベントを取得できます。

表22-13では、これらのイベントについて説明します。

表22-13 Oracle Database Vaultのセキュア・アプリケーション・ロールの監査イベント

監査イベント 説明

CREATE_ROLE

DVSYS.DBMS_MACADM.CREATE_ROLEプロシージャを使用して、Oracle Database Vaultのセキュア・アプリケーション・ロールを作成します。

DELETE_ROLE

DVSYS.DBMS_MACADM.DELETE_ROLEプロシージャを使用して、Oracle Database Vaultのセキュア・アプリケーション・ロールを削除します。

UPDATE_ROLE

DVSYS.DBMS_MACADM.UPDATE_ROLEプロシージャを使用して、Oracle Database Vaultのセキュア・アプリケーション・ロールを更新します。

RENAME_ROLE

DVSYS.DBMS_MACADM.RENAME_ROLEプロシージャを使用して、Oracle Database Vaultのセキュア・アプリケーション・ロールの名前を変更します。

22.2.14.9 Oracle Database Vault Oracle Label Securityの監査イベント

統合監査証跡では、Oracle Database Vault Oracle Label Securityの監査イベントを取得できます。

表22-14では、これらのイベントについて説明します。

表22-14 Oracle Database Vault Oracle Label Securityの監査イベント

監査イベント 説明

CREATE_POLICY_LABEL

DVSYS.DBMS_MACADM.CREATE_POLICY_LABELプロシージャを使用して、Oracle Label Securityのポリシー・ラベルを作成します。

DELETE_POLICY_LABEL

DVSYS.DBMS_MACADM.DELETE_POLICY_LABELプロシージャを使用して、Oracle Label Securityのポリシー・ラベルを削除します。

CREATE_MAC_POLICY

DVSYS.DBMS_MACADM.CREATE_MAC_POLICYを使用して、ファクタのラベルまたはOracle Label Securityセッション・ラベルを算出する際にラベルのマージに使用されるアルゴリズムを指定します。

UPDATE_MAC_POLICY

DVSYS.DBMS_MACADM.UPDATE_MAC_POLICYプロシージャを使用して、Oracle Label Securityのラベルのマージ・アルゴリズムを変更します。

DELETE_MAC_POLICY_CASCADE

DVSYS.DBMS_MACADM.DELETE_MAC_POLICY_CASCADEプロシージャを使用して、Oracle Label Securityポリシーに関連するOracle Database Vaultのすべてのオブジェクトを削除します。

22.2.14.10 Oracle Database Vault Oracle Data Pumpの監査イベント

統合監査証跡では、Oracle Database Vault Oracle Data Pumpの監査イベントを取得できます。

表22-15では、これらのイベントについて説明します。

表22-15 Oracle Database Vault Oracle Data Pumpの監査イベント

監査イベント 説明

AUTHORIZE_DATAPUMP_USER

DVSYS.DBMS_MACADM.AUTHORIZE_DATAPUMP_USERプロシージャを使用して、Oracle Data Pumpユーザーに権限を付与します。

UNAUTHORIZE_DATAPUMP_USER

DVSYS.DBMS_MACADM.UNAUTHORIZE_DATAPUMP_USERプロシージャを使用して、Oracle Data Pumpユーザーを認可から削除します。

22.2.14.11 Oracle Database Vaultの有効および無効な監査イベント

統合監査証跡では、Oracle Database Vaultの有効および無効な監査イベントを取得できます。

表22-16では、これらのイベントについて説明します。

表22-16 Oracle Database Vaultの有効および無効な監査イベント

イベント 説明

ENABLE_EVENT

DBMS_MACADM.ENABLE_EVENT

DISABLE_EVENT

DBMS_MACADM.DISABLE_EVENT

22.2.14.12 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は、Realm ViolationとRealm Successの両方のケースを監査します。つまり、アクセスが成功したか失敗したかに関係なく、レルム・アクセスが試行されるたびに監査します。

    • ルール・セット関連のアクション: Rule Set FailureRule Set SuccessRule Set Eval

    • ファクタ関連のアクション: Factor ErrorFactor NullFactor Validate ErrorFactor Validate FalseFactor Trust Level NullFactor Trust Level NegFactor 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文を使用して有効にする必要があります。

22.2.14.13 例: Oracle Database Vaultのレルムの監査

CREATE AUDIT POLICY文で、Oracle Database Vaultのレルムを監査できます。

例22-21に、HRスキーマに対するレルム違反の監査方法を示します。

例22-21 レルム違反の監査

CREATE AUDIT POLICY dv_realm_hr 
 ACTIONS SELECT, UPDATE, DELETE
 ACTIONS COMPONENT=DV Realm Violation ON "HR Schema Realm";

AUDIT POLICY dv_realm_hr EXCEPT psmith;
22.2.14.14 例: Oracle Database Vaultのルール・セットの監査

CREATE AUDIT POLICY文で、Oracle Database Vaultのルール・セットを監査できます。

例: Oracle Database Vaultのルール・セットの監査に、Can Maintain Accounts/Profileルール・セットの監査方法を示します。DV_ACCTMGRロールがあるため、ユーザー・アカウントおよびユーザー・プロファイルを管理する権限があるユーザーdbv_acctmgrは、この監査ポリシーから除外されます。

例22-22 ルール・セットの監査

CREATE AUDIT POLICY dv_rule_set_accts 
 ACTIONS CREATE USER, ALTER USER, ALTER PROFILE 
 ACTIONS COMPONENT=DV RULE SET FAILURE ON "Can Maintain Accounts/Profile";

AUDIT POLICY dv_rule_set_accts EXCEPT dbv_acctmgr;
22.2.14.15 例: 2つのOracle Database Vaultイベントの監査

CREATE AUDIT POLICY文で、複数のOracle Database Vaultイベントを監査できます。

例22-23に、レルム違反およびルール・セット失敗の監査方法を示します。

例22-23 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;
22.2.14.16 例: Oracle Database Vaultのファクタの監査

CREATE AUDIT POLICY文で、Oracle Database Vaultのファクタを監査できます。

例22-24に、1つのファクタで2つのタイプのエラーを監査する方法を示します。

例22-24 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;
22.2.14.17 監査証跡でのOracle Database Vaultの監査イベントの表示方法

UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューはOracle Database Vaultの監査イベントを表示します。

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

22.2.15 Oracle Label Securityイベントの監査

Oracle Label Security環境で、CREATE AUDIT POLICY文を使用してOracle Label Securityアクティビティを監査できます。

22.2.15.1 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ポリシーを表に適用するときに作成される、内部的に生成されたVPD述語に関する監査情報を特定する場合は、RLS_INFO列を問い合せることができます。

関連項目:

22.2.15.2 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の監査イベント

監査イベント 説明

CREATE POLICY

SA_SYSDBA.CREATE_POLICYプロシージャを使用して、Oracle Label Securityのポリシーを作成します。

ALTER POLICY

SA_SYSDBA.ALTER_POLICYプロシージャを使用して、Oracle Label Securityのポリシーを変更します。

DROP POLICY

SA_SYSDBA.DROP_POLICYプロシージャを使用して、Oracle Label Securityのポリシーを削除します。

APPLY POLICY

SA_POLICY_ADMIN.APPLY_TABLE_POLICYプロシージャを使用して表ポリシーを適用するか、SA_POLICY_ADMIN.APPLY_SCHEMA_POLICYプロシージャを使用してスキーマ・ポリシーを適用します。

REMOVE POLICY

SA_POLICY_ADMIN.REMOVE_TABLE_POLICYプロシージャを使用して表ポリシーを削除するか、SA_POLICY_ADMIN.REMOVE_SCHEMA_POLICYプロシージャを使用してスキーマ・ポリシーを削除します。

SET AUTHORIZATION

Oracle Label Securityの権限を含むOracle Label Securityのすべての認可を含み、ユーザーまたは信頼できるストアド・プロシージャのいずれかにラベルを使用します。SET AUTHORIZATIONイベントに対応するPL/SQLプロシージャは、SA_USER_ADMIN.SET_USER_LABELSSA_USER_ADMIN.SET_USER_PRIVSおよびSA_USER_ADMIN.SET_PROG_PRIVSです。

PRIVILEGED ACTION

Oracle Label Securityの権限のユーザーを必要とするアクションを含みます。これらのアクションは、ログオン、SA_SESSION.SET_ACCESS_PROFILEの実行、および信頼できるストアド・プロシージャの起動です。

ENABLE POLICY

次のプロシージャを使用して、Oracle Label Securityのポリシーを有効にします。

  • SA_SYSDBA.ENABLE_POLICY: ポリシーで保護されている表およびスキーマにアクセス制御を施行します。

  • SA_POLICY_ADMIN.ENABLE_TABLE_POLICY: 指定した表でOracle Label Securityポリシーを有効にします。

  • SA_POLICY_ADMIN.ENABLE_SCHEMA_POLICY: 指定したスキーマのすべての表でOracle Label Securityポリシーを有効にします。

DISABLE POLICY

次のプロシージャを使用して、Oracle Label Securityのポリシーを無効にします。

  • SA_SYSDBA.DISABLE_POLICY: Oracle Label Securityポリシーの規定を無効にします。

  • SA_POLICY_ADMIN.DISABLE_TABLE_POLICY: 指定した表でOracle Label Securityポリシーの規定を無効にします。

  • SA_POLICY_ADMIN.DISABLE_SCHEMA_POLICY: 指定したスキーマのすべての表でOracle Label Securityポリシーの規定を無効にします。

SUBSCRIBE OID

SA_POLICY_ADMIN.POLICY_SUBSCRIBEプロシージャを使用して、Oracle Internet Directory対応のOracle Label Securityポリシーをサブスクライブします。

UNSUBSCRIBE OID

SA_POLICY_ADMIN.POLICY_UNSUBSCRIBEプロシージャを使用して、Oracle Internet Directory対応のOracle Label Securityポリシーのサブスクライブを取り消します。

CREATE DATA LABEL

SA_LABEL_ADMIN.CREATE_LABELプロシージャを使用して、Oracle Label Securityのデータ・ラベルを作成します。CREATE DATA LABELは、LBACSYS.TO_DATA_LABELファンクションにも対応します。

ALTER DATA LABEL

SA_LABEL_ADMIN.ALTER_LABELプロシージャを使用して、Oracle Label Securityのデータ・ラベルを変更します。

DROP DATA LABEL

SA_LABEL_ADMIN.DROP_LABELプロシージャを使用して、Oracle Label Securityのデータ・ラベルを削除します。

CREATE LABEL COMPONENT

次のプロシージャを使用して、Oracle Label Securityのコンポーネントを作成します。

  • レベル: SA_COMPONENTS.CREATE_LEVEL

  • 区分: SA_COMPONENTS.CREATE_COMPARTMENT

  • グループ: SA_COMPONENTS.CREATE_GROUP

ALTER LABEL COMPONENTS

次のプロシージャを使用して、Oracle Label Securityのコンポーネントを変更します。

  • レベル: SA_COMPONENTS.ALTER_LEVEL

  • 区分: SA_COMPONENTS.ALTER_COMPARTMENT

  • グループ: SA_COMPONENTS.ALTER_GROUPおよびSA_COMPONENTS.ALTER_GROUP_PARENT

DROP LABEL COMPONENTS

次のプロシージャを使用して、Oracle Label Securityのコンポーネントを削除します。

  • レベル: SA_COMPONENTS.DROP_LEVEL

  • 区分: SA_COMPONENTS.DROP_COMPARTMENT

  • グループ: SA_COMPONENTS.DROP_GROUP

ALL

Oracle Label Securityのすべてのアクションの監査を有効にします。

22.2.15.3 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;
22.2.15.4 Oracle Label Securityの統合監査ポリシーの構成

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文を使用して有効にする必要があります。

22.2.15.5 例: Oracle Label Securityのセッション・ラベル属性の監査

AUDIT CONTEXT NAMESPACE文で、Oracle Label Securityのセッション・ラベル属性を監査できます。

例22-25に、Oracle Label Securityのポリシーusr_pol1およびusr_pol2ORA_OLS_SESSION_LABELSアプリケーション・コンテキスト属性を監査する方法を示します。

例22-25 Oracle Label Securityのセッション・ラベル属性の監査

AUDIT CONTEXT NAMESPACE ORA_SESSION_LABELS ATTRIBUTES usr_pol1, usr_pol2;
22.2.15.6 例: Oracle Label Securityポリシーからのユーザーの除外

CREATE AUDIT POLICY文で、ポリシーからユーザーを除外できます。

例22-26に、ユーザーols_mgrからアクションを除外する統合監査ポリシーを作成する方法を示します。

例22-26 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;
22.2.15.7 例: Oracle Label Securityのポリシー・アクションの監査

CREATE AUDIT POLICY文で、Oracle Label Securityのポリシー・アクションを監査できます。

例22-27に、DROP POLICYDISABLE POLICYUNSUBSCRIBE OIDイベント、およびHR.EMPLOYEES表のUPDATEおよびDELETE文を監査する方法を示します。次に、ポリシーがHRおよびLBACSYSユーザーに適用され、監査アクションが成功すると、監査レコードが統合監査証跡に書き込まれます。

例22-27 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;
22.2.15.8 例: 監査済のOLSセッション・ラベルの問合せ

UNIFIED_AUDIT_TRAIL問合せでLBACSYS.ORA_GET_AUDITED_LABEL関数を使用して、監査済Oracle Label Securityセッション・ラベルを確認できます。

例22-28に、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューの問合せでLBACSYS.ORA_GET_AUDITED_LABELファンクションを使用する方法を示します。

例22-28 監査対象の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
22.2.15.9 監査証跡でのOracle Label Securityの監査イベントの表示方法

UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューはOracle Label Securityの監査イベントを表示します。

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管理者ガイド』を参照してください。

22.2.16 Oracle Data Miningイベントの監査

CREATE AUDIT POLICY文を使用して、Oracle Data Miningイベントを監査できます。

22.2.16.1 Oracle Data Miningイベントの監査について

Oracle Data Miningイベントを監査するには、AUDIT_ADMINロールが必要です。

監査証跡にアクセスするには、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せます。

関連項目:

Oracle Data Miningの詳細は、『Oracle Data Mining概要』を参照してください。

22.2.16.2 Oracle Data Miningの統合監査証跡イベント

統合監査証跡では、Oracle Data Miningの監査イベントを取得できます。

表22-18では、これらのイベントについて説明します。

表22-18 Oracle Data Miningの監査イベント

監査イベント 説明

AUDIT

データ・マイニング・モデルの監査レコードを生成します。

COMMENT

データ・マイニング・モデルにコメントを追加します。

GRANT

データ・マイニング・モデルへのアクセス権をユーザーに付与します。

RENAME

データ・マイニング・モデルの名前を変更します。

SELECT

データ・マイニング・モデルを適用またはその署名を表示します。

22.2.16.3 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文を使用して有効にする必要があります。

22.2.16.4 例: ユーザーによる複数のOracle Data Mining操作の監査

CREATE AUDIT POLICY文で、複数のOracle Data Mining操作を監査できます。

例22-29に、ユーザーpsmithによる複数のOracle Data Mining操作を監査する方法を示します。イベントごとにON MINING MODEL schema_name.model_name句を含み、それぞれカンマで区切ります。この例では、両方のアクションで同じschema_name.model nameを指定しますが、スキーマおよびデータ・モデルごとに異なるschema_name.model_name設定を構文で指定できます。

例22-29 ユーザーによる複数の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;
22.2.16.5 例: ユーザーによる失敗したすべてのOracle Data Mining操作の監査

CREATE AUDIT POLICY文で、ユーザーによる失敗したOracle Data Miningの操作を監査できます。

例22-30に、ユーザーpsmithによる失敗したすべてのOracle Data Mining操作を監査する方法を示します。

例22-30 ユーザーによる失敗したすべての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;
22.2.16.6 監査証跡でのOracle Data Miningイベントの表示方法

UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューはOracle Data Miningの監査イベントを表示します。

次の例に、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;

22.2.17 Oracle Data Pumpイベントの監査

CREATE AUDIT POLICY文を使用して、Oracle Data Pumpを監査できます。

22.2.17.1 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ユーティリティ』を参照してください。

22.2.17.2 Oracle Data Pumpの統合監査証跡イベント

統合監査証跡によってOracle Data Pumpのイベントを取得できます。

統合監査証跡では、エクスポート(expdp)およびインポート(impdp)の両方の操作に関する情報を取得します。

22.2.17.3 Oracle Data Pumpの統合監査ポリシーの構成

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文を使用して有効にする必要があります。

22.2.17.4 例: Oracle Data Pumpのインポート操作の監査

CREATE AUDIT POLICY文で、Oracle Data Pumpのインポート操作を監査できます。

例22-31に、Oracle Data Pumpのすべてのインポート操作を監査する方法を示します。

例22-31 Oracle Data Pumpのインポート操作の監査

CREATE AUDIT POLICY audit_dp_import_pol
 ACTIONS COMPONENT=DATAPUMP IMPORT;

AUDIT POLICY audit_dp_import_pol;
22.2.17.5 例: Oracle Data Pumpのすべての操作の監査

CREATE AUDIT POLICY文で、Oracle Data Pumpのすべての操作を監査できます。

例22-32に、Oracle Database Pumpのエクスポートおよびインポートの両方の操作を監査する方法を示します。

例22-32 Oracle Data Pumpのすべての操作の監査

CREATE AUDIT POLICY audit_dp_all_pol
 ACTIONS COMPONENT=DATAPUMP ALL;

AUDIT POLICY audit_dp_all_pol BY SYSTEM;
22.2.17.6 監査証跡でのOracle Data Pumpの監査イベントの表示方法

UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューはOracle Data Pumpの監査イベントを表示します。

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 

(この出力は、読みやすくするために変更が加えられています。)

22.2.18 Oracle SQL*Loaderダイレクト・ロード・パス・イベントの監査

CREATE AUDIT POLICY文を使用して、Oracle SQL*Loaderダイレクト・ロード・パス・イベントを監査できます。

22.2.18.1 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ユーティリティ』を参照してください。

22.2.18.2 Oracle SQL*Loaderダイレクト・ロード・パスの統合監査証跡イベント

統合監査証跡によってSQL*Loaderダイレクト・ロード・パスのイベントを取得できます。

統合監査証跡では、SQL*Loaderで実行されるダイレクト・パス・ロードに関する情報を取得します(SQL*LoaderのコマンドラインまたはSQL*Loaderの制御ファイルでdirect=trueに設定した場合)。

また、ダイレクト・パスAPIを使用するOracle Call Interface (OCI)プログラムも監査します。

関連項目:

Oracle SQL*Loaderのダイレクト・パス・ロードの詳細は、『Oracle Databaseユーティリティ』を参照してください。

22.2.18.3 Oracle SQL*Loaderダイレクト・パス・イベントの統合監査証跡ポリシーの構成

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文を使用して有効にする必要があります。

22.2.18.4 例: Oracle SQL*Loaderダイレクト・パス・ロード操作の監査

CREATE AUDIT POLICY文で、Oracle SQL*Loaderダイレクト・パス・ロード操作を監査できます。

例22-31に、SQL*Loaderダイレクト・パス・ロード操作を監査する方法を示します。

例22-33 Oracle SQL*Loaderダイレクト・パス・ロード操作の監査

CREATE AUDIT POLICY audit_sqlldr_load_pol
 ACTIONS COMPONENT=DIRECT_LOAD LOAD;

AUDIT POLICY audit_sqlldr_load_pol;
22.2.18.5 監査証跡でのSQL*Loaderダイレクト・パス・ロードの監査イベントの表示方法

UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューはSQL*Loaderダイレクト・パス・ロードの監査イベントを表示します。

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

22.2.19 トップレベルの文のみの監査

トップレベルの文の監査とは、指定した監査文に対する監査レコードが1つのみになるように監査レコードをフィルタリングすることです。

22.2.19.1 トップレベルのSQL文のみの監査について

トップレベルの文は、PL/SQLプロシージャ内から実行される文ではなく、ユーザーによって直接実行される文です。

ユーザーSYSを含むすべてのユーザーからトップレベルの文を監査できます。統合監査証跡をトップレベルの文に制限する利点は、特に統合監査ポリシー内の1つの文に対して多数の監査証跡レコードが生成される場合に、監査証跡のサイズが大幅に削減されることです。この機能は、再帰的SQL文を削減するのに役立ちます。これらの監査レコードを制限することで、この機能は有用なデータを提供しないレコードの数も削減します。このシナリオの例として、200,000個を超える個別監査レコードを生成するDBMS_STATS.GATHER_DATABASE_STATS SQL文の監査などがあります。監査証跡を削減することにより、この機能でデータベース・パフォーマンスが向上し、データベース(および使用中の場合はOracle Audit Vaultリポジトリ)内の領域が節約されます。

22.2.19.2 トップレベルの文のみを取得する統合監査ポリシーの構成

CREATE AUDIT POLICY文でONLY TOPLEVEL句を指定すると、監査ポリシーの監査構成に応じてエンド・ユーザーが直接発行するSQL文のみを監査できます。

ONLY TOPLEVEL句を含むポリシーを検索するには、AUDIT_UNIFIED_POLICIESデータ・ディクショナリ・ビューのAUDIT_ONLY_TOPLEVEL列を問い合せます。
次の構文を使用して、トップレベルのSQL文のみを監査する統合監査ポリシーを作成します。
CREATE AUDIT POLICY policy_name
all_existing_options
ONLY TOPLEVEL;

たとえば、HR.EMPLOYEES表のSELECT文のトップレベル・インスタンスに監査証跡を制限するには、次のようにします。

CREATE AUDIT POLICY actions_on_hr_emp_pol
ACTIONS SELECT ON HR.EMPLOYEES
ONLY TOPLEVEL;
22.2.19.3 例: トップレベルの文の監査

CREATE AUDIT POLICY文で、任意のユーザーに対する統合監査証跡にトップレベルの文の監査レコードを含めるか除外できます。

次の例は、ユーザーSYSによって実行されるすべてのトップレベルの文を取得する監査ポリシーを示しています。

例22-34 例: ユーザーSYSによって実行されるトップレベルの文の監査

CREATE AUDIT POLICY actions_all_pol ACTION ALL
ONLY TOPLEVEL;

AUDIT POLICY actions_all_pol BY SYS;
22.2.19.4 統合監査ポリシーでのトップレベルのSQL文の取得方法

ONLY TOPLEVEL句は、個々の統合監査証跡レコードの出力には影響しません。

ONLY TOPLEVELがポリシーに及ぼす影響は、指定の統合監査ポリシーに対して生成されるレコードの数を制限することのみです。

22.2.20 マルチテナント環境での統合監査ポリシーまたはAUDIT設定

マルチテナント環境では、個々のPDBおよびルートに統合監査ポリシーを作成できます。

22.2.20.1 ローカル、CDB共通およびアプリケーション共通監査ポリシーについて

監査ポリシーは、ローカル、CDB共通またはアプリケーション共通のいずれかにすることができます。

これは統合監査ポリシーと、AUDIT SQL文を使用して作成されたポリシーの両方に適用されます。

  • ローカル監査ポリシー。このタイプのポリシーは、ルート(CDBまたはアプリケーション)またはPDB (CDBまたはアプリケーション)に存在できます。ルートに存在するローカル監査ポリシーには、ローカル・オブジェクトと共通オブジェクトの両方用のオブジェクト監査オプションを含めることができます。AUDIT_ADMINロールが付与されているローカル・ユーザーおよび共通ユーザーは、両方ともローカル・ポリシーを有効にできます(ローカル・ユーザーはPDBから、共通ユーザーは権限のあるルートまたはPDBから有効にできます)。ローカル監査ポリシーは、ローカル・ユーザーおよびロールと共通ユーザーおよびロールの両方に対して有効にすることができます。

    ローカル監査ポリシーは、アプリケーション・ローカル・オブジェクトおよびアプリケーション・ローカル・ロールのほか、システム・アクション・オプションおよびシステム権限オプションに対して作成できます。ローカル監査ポリシーをすべてのコンテナにわたり共通ユーザーに対して実行することや、共通監査ポリシーをローカル・ユーザーに対して実施することはできません。

  • CDB共通監査ポリシー。このタイプのポリシーは、マルチテナント環境のすべてのPDBに使用できます。共通監査ポリシーを作成および保持できるのは、AUDIT_ADMINロールが付与されている共通ユーザーのみです。共通監査ポリシーは、共通ユーザーのみに対して有効にできます。共通監査ポリシーは、ルートにのみ作成する必要があります。このタイプのポリシーには、共通オブジェクトのみのオブジェクト監査オプションを含めることができ、共通ユーザーのみに対して有効にできます。共通監査ポリシーは、共通ユーザーおよびロールに対してのみ有効にできます。

    共通監査ポリシーをすべてのコンテナにわたりローカル・ユーザーに対して実施することはできません。

  • アプリケーション共通監査ポリシー。CDB共通監査ポリシーと同様、このタイプのポリシーは、マルチテナント環境のすべてのPDBに使用できます。共通監査ポリシーは、アプリケーション共通オブジェクトおよびアプリケーション共通ロールのほか、システム・アクション・オプションおよびシステム権限オプションに対して作成できます。このタイプのポリシーはアプリケーション・ルート・コンテナにのみ作成できますが、アプリケーション共通ユーザーとCDB共通ユーザーの両方に対して有効にできます。オブジェクトを監査する場合は、これらのオブジェクトがアプリケーション共通オブジェクトであることを確認してください。DBA_OBJECTSデータ・ディクショナリ・ビューのSHARING列を問い合せることで、オブジェクトがアプリケーション共通オブジェクトであるかどうかを確認できます。

デフォルトでは、CDBとアプリケーションの両方のシナリオにおいて、監査ポリシーは現在のPDBに対してローカルです。

表22-19では、異なるマルチテナント環境における監査ポリシーの適用方法について説明します。

表22-19 CDBルート、アプリケーション・ルートおよび個々のPDBへの監査ポリシーの適用方法

監査オプション・タイプ CDBルート アプリケーション・ルート 個々のPDB

共通監査文または監査ポリシー

CDB共通ユーザーに適用されます

CDB共通ユーザーに適用されます

CDB共通ユーザーに適用されます

アプリケーション・コンテナの共通監査文または監査ポリシー

適用されません

  • CDB共通ユーザーに適用され、現在のアプリケーション・コンテナに対してのみ有効です

  • アプリケーション・コンテナ共通ユーザーに適用されます

  • CDB共通ユーザーに適用され、このアプリケーション・コンテナに対してのみ有効です

  • アプリケーション共通ユーザーに適用されます

ローカル監査文または監査ポリシー

ローカル構成は許可されません

ローカル構成は許可されません

  • CDB共通ユーザーに適用されます

  • アプリケーション共通ユーザーに適用されます

22.2.20.2 マルチテナント環境での従来の監査

従来型の監査(統合監査ではない)では、AUDITおよびNOAUDIT文で、マルチテナント環境の文と権限を監査できます。

ローカル監査ポリシーまたは共通監査ポリシーになるように監査ポリシーを構成するには、作成または変更の他のSQL文に対して一般的に行うように、CONTAINER句を含める必要があります。アプリケーション・コンテナを監査する場合、ローカル・ユーザーおよびロールならびに共通ユーザーおよびロールによって実行されたSQL文およびシステム権限を監査できます。監査レコードは、アクションが実行されたコンテナに作成されます。

  • AUDITまたはNOAUDIT文を現在のCDBまたはアプリケーションPDBに適用する場合は、このPDBでCONTAINERCURRENTに設定する必要があります。例:

    AUDIT DROP ANY TABLE BY SYSTEM BY ACCESS CONTAINER = CURRENT;
  • AUDITまたはNOAUDIT文をマルチテナント環境全体に適用する場合は、CDBルートでCONTAINERALLに設定する必要があります。アプリケーション・ルートの場合は、アプリケーション・ルート内に設定します。たとえば、次のようになります。

    AUDIT DROP ANY TABLE BY SYSTEM BY ACCESS CONTAINER = ALL;

従来の監査オプションがアプリケーション・コンテナでの使用を考慮して設計されているかどうかを確認するには、DBA_OBJ_AUDIT_OPTSおよびDBA_OBJECTSデータ・ディクショナリ・ビューの結合問合せを実行します。具体的には、両方のビューでOWNERおよびOBJECT_NAME列を使用し、DBA_OBJECTSAPPLICATION列を使用します。

関連項目:

従来のAUDITおよびNOAUDIT SQL文の詳細は、Oracle Database SQL言語リファレンスを参照してください

22.2.20.3 ローカル統合監査ポリシーまたは共通統合監査ポリシーの構成

CONTAINER句の使用はマルチテナント環境限定で、CREATE AUDIT POLICY文で使用します。

CDB環境またはアプリケーション・コンテナ環境でローカルまたは共通(CDBまたはアプリケーション)統合監査ポリシーを作成するには、CREATE AUDIT POLICY文にCONTAINER句を含めます。
  • 次の構文を使用して、ローカル統合監査ポリシーまたは共通統合監査ポリシーを作成します。

    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;

次のことに注意してください。

  • CONTAINER句はCREATE AUDIT POLICY文に設定できますが、ALTER AUDIT POLICYまたはDROP AUDIT POLICYには設定できません。この設定を使用するように既存の統合監査ポリシーの範囲を変更する場合は、ポリシーを削除してから再作成します。

  • AUDIT文の場合は、リリース12.xの監査機能にまだ移行していないOracleデータベースがある場合など、監査設定のみにCONTAINER句を設定します。統合監査ポリシーを有効にするために使用するAUDIT文には、CONTAINER句を使用できません。

  • PDBにいる場合、CONTAINER句に設定できるのはALLではなくCURRENTのみです。PDBにいる場合に設定を省略すると、デフォルトはCONTAINER = CURRENTになります。

  • ルートにいる場合は、CONTAINER句を、ポリシーをルートのみに適用する場合はCURRENTに、ポリシーをCDB全体に適用する場合はALLに設定できます。CONTAINER句を省略すると、デフォルトはCONTAINER = CURRENTになります。

  • オブジェクトの場合:

    • 共通監査ポリシーには共通オブジェクトのみ、ローカル監査ポリシーにはローカル・オブジェクトと共通オブジェクトの両方を含めることができます。

    • 関係するオブジェクトがローカルの場合は、CONTAINERALLに設定することはできません。共通オブジェクトにする必要があります。

  • 権限の場合:

    • 関係するユーザー・アカウントがローカル・アカウントと共通アカウントの混在の場合は、CONTAINERCURRENTに設定(またはCONTAINER句を省略)できます。これにより、現在のPDBのみに適用されるローカル監査構成が作成されます。

    • 関係するユーザーがローカル・ユーザーの場合は、CONTAINERALLに設定することはできません。共通ユーザーにする必要があります。

    • CONTAINERALLに設定し、ユーザー・リストを指定しない場合(BY句をAUDIT文に使用)、構成が各PDBのすべての共通ユーザーに適用されます。

  • アプリケーション・コンテナの場合、アプリケーションのインストール、アップグレード、パッチ適用およびアンインストールに使用されるアプリケーション・コンテナ・スクリプトから共通統合監査ポリシーを実行できます。これを行うには、次のようにします。

    1. アプリケーション・コンテナ・ルートに共通統合監査ポリシーを作成し、このポリシーをCONTAINER = ALLに設定します。または、このポリシーを次のステップで説明するスクリプトに含めることもできます。

    2. Oracle Databaseのインストール、アップグレード、パッチ適用またはアンインストールに通常使用するスクリプトのカスタム・バージョンを作成します。

    3. このスクリプト内の次の行に、監査するSQL文を含めます。

      ALTER PLUGGABLE DATABASE APPLICATION BEGIN INSTALL
      List SQL statements here. Separate each statement with a semi-colon.
      ALTER PLUGGABLE DATABASE APPLICATION END INSTALL

      スクリプトに統合監査ポリシーを含める場合は、CREATE AUDIT POLICYAUDIT POLICYの両方の文を含めるようにします。

    監査ポリシーを作成して有効にした後、監査ポリシーがデータベースで定義されたものであるか、スクリプトからのものであるかにかかわらず、アプリケーション共通オブジェクトへのすべてのユーザー・アクセスが監査されます。

  • アプリケーションのインストール、アップグレード、パッチ適用およびアンインストール操作をアプリケーション・ルートまたはアプリケーションPDBでローカルに監査するには、共通統合監査ポリシーに関する前の手順と同様の手順に従いますが、後からアプリケーションPDBを同期します。例:

    ALTER PLUGGABLE DATABASE APPLICATION application_name SYNC;

関連項目:

  • アプリケーション・コンテナ内のアプリケーションのインストール、アップグレードおよびパッチ適用の詳細は、Oracle Database管理者ガイドを参照してください

  • アプリケーション・コンテナ内のアプリケーションの同期の詳細は、Oracle Database管理者ガイドを参照してください

22.2.20.4 例: ローカル統合監査ポリシー

CREATE AUDIT POLICY文で、ルートまたはPDBにローカル統合監査ポリシーを作成できます。

ルートでローカル統合監査ポリシーを作成すると、マルチテナント環境全体ではなく、ルートにのみ適用されます。

例22-35に、共通ユーザーc##sec_adminによってPDBから作成され、共通ユーザーc##hr_adminに適用されているローカル統合監査ポリシーを示します。

例22-35 ローカル統合監査ポリシー

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;
22.2.20.5 例: CDB共通統合監査ポリシー

CREATE AUDIT POLICY文で、CDB共通統合監査ポリシーを作成できます。

例22-36に、共通ユーザーc##sec_adminによってルートから作成され、共通ユーザーc##hr_adminに適用されている共通統合監査ポリシーを示します。

例22-36 共通統合監査ポリシー

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;
22.2.20.6 例: アプリケーション共通統合監査ポリシー

アプリケーション・コンテナ共通統合監査ポリシーの場合、アクション・オプションとシステム権限オプションを監査して、共通オブジェクトおよびロールを参照できます。

アプリケーション共通監査ポリシーの作成はアプリケーション・ルートからに限定されますが、このポリシーをアプリケーション共通ユーザーとCDB共通ユーザーの両方に対して有効にできます。

例22-37に、アプリケーション・コンテナapp_pdbでアプリケーション共通ユーザーSYSTEMを監査するポリシーを作成する方法を示します。この監査ポリシーは、SYSTEM.utils_tab表に対するSELECTアクション、およびコンテナ・データベース(CDBルートを含む)内の任意のPDBに対するDROP TABLEアクションを監査します。このポリシーは、すべてのコンテナでSELECT ANY TABLEシステム権限の使用も監査します。

例22-37 アプリケーション共通統合監査ポリシー

CONNECT c##sec_admin@app_pdb
Enter password: password
Connected.

CREATE AUDIT POLICY app_pdb_admin_pol
 ACTIONS SELECT ON hr_app_cdb.utils_tab, DROP TABLE
 PRIVILEGES SELECT ANY TABLE
 CONTAINER = ALL;

AUDIT POLICY app_pdb_admin_pol by SYSTEM, c##hr_admin;

この例では、CONTAINERALLに設定することで、ポリシーは、アプリケーション・ルートおよびアプリケーション・ルートに属するすべてのアプリケーションPDBのすべての関連オブジェクトへのアクセスのみに適用されます。この範囲外にポリシーは適用されません。

22.2.20.7 監査証跡でのローカルまたは共通監査ポリシーまたは設定の表示方法

ルートまたはアクションが発生した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に表示できます。

    ポリシー名にWHERE句を使用している場合は(例: WHERE UNIFIED_AUDIT_POLICIES = 'FGA_POL')、ポリシーについて、ルートまたはPDBのいずれかからUNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せることができます。

次の例は、共通統合監査ポリシーの結果を検索する方法を示します。

CONNECT c##sec_admin
Enter password: password
Connected.

SELECT DBID, ACTION_NAME, OBJECT_SCHEMA, OBJECT_NAME FROM CDB_UNIFIED_AUDIT_TRAIL WHERE DBUSERNAME = 'c##hr_admin';
46892-1
DBID        ACTION_NAME  OBJECT_SCHEMA  OBJECT_NAME
----------- -----------  -------------  -----------
653916017   UPDATE       HR             EMPLOYEES
653916018   UPDATE       HR             JOB_HISTORY
653916017   UPDATE       HR             JOBS 

22.2.21 統合監査ポリシーの変更

ALTER AUDIT POLICY文を使用して、統合監査ポリシーを変更できます。

22.2.21.1 統合監査ポリシーの変更について

統合監査ポリシーでは、CONTAINER設定を除いたほとんどのプロパティを変更できます。

マルチテナント環境では統合監査ポリシーを変更できません。たとえば、共通統合監査ポリシーをローカル統合監査ポリシーにすることはできません。

既存の統合監査ポリシーを検索するには、AUDIT_UNIFIED_POLICIESデータ・ディクショナリ・ビューを問い合せます。有効な統合監査ポリシーのみを検索する場合は、AUDIT_UNIFIED_ENABLED_POLICIESビューを問い合せます。有効な監査ポリシーと無効な監査ポリシーの両方を変更できます。有効な監査ポリシーを変更する場合は、変更後も有効なままです。

オブジェクトの統合監査ポリシーを変更すると、アクティブおよび後続の両方のユーザー・セッションで新しい監査設定が即座に実行されます。システムの監査オプションを変更する場合やポリシーの条件を監査する場合は、現在のユーザー・セッションではなく、新しいユーザー・セッションに対してアクティブになります。

22.2.21.2 統合監査ポリシーの変更

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
22.2.21.3 例: 統合監査ポリシーの条件の変更

ALTER AUDIT POLICY文で、統合監査ポリシーの条件を変更できます。

例22-38に、既存の統合監査ポリシーの条件を変更する方法を示します。

例22-38 統合監査ポリシーの条件の変更

ALTER AUDIT POLICY orders_unified_audpol
 ADD ACTIONS INSERT ON SCOTT.EMP
CONDITION 'SYS_CONTEXT(''ENTERPRISE'', ''GROUP'') =  ''ACCESS_MANAGER'''
EVALUATE PER SESSION;
22.2.21.4 例: 統合監査ポリシーでのOracle Label Securityコンポーネントの変更

ALTER AUDIT POLICY文で、監査ポリシーのOracle Label Securityコンポーネントを変更できます。

例22-39に、監査ポリシーでOracle Label Securityコンポーネントを変更する方法を示します。

例22-39 統合監査ポリシーでのOracle Label Securityコンポーネントの変更

ALTER AUDIT POLICY audit_ols
 ADD ACTIONS SELECT ON HR.EMPLOYEES
 ACTIONS COMPONENT=OLS DROP POLICY, DISABLE POLICY, REMOVE POLICY;
22.2.21.5 例: 統合監査ポリシーのロールの変更

ALTER AUDIT POLICY文で、統合監査ポリシーのロールを変更できます。

例22-40に、共通統合監査ポリシーにロールを追加する方法を示します。

例22-40 統合監査ポリシーのロールの変更

CONNECT c##sec_admin
Enter password: password
Connected.

ALTER AUDIT POLICY RoleConnectAudit 
 ADD ROLES c##role1, c##role2;
22.2.21.6 例: 統合監査ポリシーからの条件の削除

ALTER AUDIT POLICY文で、統合監査ポリシーから条件を削除できます。

例22-41に、既存の統合監査ポリシーから条件を削除する方法を示します。

例22-41 統合監査ポリシーからの条件の削除

ALTER AUDIT POLICY orders_unified_audpol
CONDITION DROP;

22.2.22 統合監査ポリシーの有効化およびユーザーとロールへの適用

AUDIT POLICY文を使用すると、統合監査ポリシーを有効にして、ユーザーとロールに適用できます。

22.2.22.1 統合監査ポリシーの有効化について

POLICY句を含むAUDIT文で、統合監査ポリシーを有効にして、オブジェクト・レベルのオプションを含むすべてのタイプの監査オプションに適用します。

監査ユーザー(またはポリシーに関連付けられたロールを付与されたユーザー)がデータベース・インスタンスにログインするまで、ポリシーは有効となりません。言い方を変えると、監査ユーザーのログイン中にポリシーを作成して有効化すると、ポリシーは監査データを収集できません。監査を開始する前に、ユーザーはログアウトしてから再ログインする必要があります。セッションが監査で設定されると、設定はユーザー・セッションの間継続し、セッションの終了時に終了します。

監査ポリシーは、個々のユーザーまたはロールに対して有効にできます。監査ポリシーをロールに対して有効にすると、そのロールを直接付与されたユーザーのグループに対してポリシーを有効にできます。新規ユーザーに対してロールを直接付与すると、そのユーザーに対してポリシーが自動的に適用されます。ユーザーからロールを取り消すと、そのユーザーにポリシーは適用されなくなります。

監査の結果を確認するには、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せます。既存の統合監査ポリシーのリストを検索するには、AUDIT_UNIFIED_POLICIESデータ・ディクショナリ・ビューを問い合せます。

AUDIT文では、次のオプションの追加設定を指定できます。

  • 統合監査ポリシーを1人以上のユーザーまたは1つ以上のロールに適用するかどうか。SYSDBA管理権限(SYSなど)でログインする管理ユーザーを含む、1人以上のユーザーまたは1つ以上のロールにポリシーを適用するには、BY句を使用します。たとえば、ユーザーSYSおよびSYSTEMにポリシーを適用するには、次のようにします。

    たとえば、2人のユーザーにポリシーを適用する場合:

    AUDIT POLICY role_connect_audit_pol BY SYS, SYSTEM;

    DBAおよびCDB_DBAロールを直接付与されたユーザーにポリシーを適用するには:

    AUDIT POLICY admin_audit_pol BY USERS WITH GRANTED ROLES DBA, CDB_DBA;
  • 統合監査ポリシーからユーザーを除外するかどうか。監査ポリシーからユーザーを除外するには、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;
    

    この句を省略すると、失敗および成功した両方のユーザー・アクティビティが監査証跡に書き込まれます。

次のことに注意してください。

  • 統合監査ポリシーには、BYBY USERS WITH GRANTED ROLESまたはEXCEPT句のみを含めることができますが、同じポリシーに複数を含めることはできません。

  • 複数のAUDIT文を同じ統合監査ポリシーで実行し、異なるBYユーザーまたは異なるBY USERS WITH GRANTED ROLESロールを指定すると、Oracle Databaseによってこれらのユーザーまたはロールがすべて監査されます。

  • 複数のAUDIT文を同じ統合監査ポリシーで実行し、異なるEXCEPTユーザーを指定すると、Oracle Databaseによって、前述のリストのユーザーではなく、最新の例外ユーザー・リストが使用されます。つまり、前のAUDIT POLICY ... EXCEPT文の影響は最新のAUDIT POLICY ... EXCEPT文によってオーバーライドされます。

  • EXCEPT句はロールに対して使用できません。これはユーザーのみに適用されます。

  • 共通統合監査ポリシーは、共通ユーザーまたはロールに対してのみ有効にできます。

  • マルチテナント環境では、共通監査ポリシーはルートからのみ、ローカル監査ポリシーは、ローカル監査ポリシーが適用されるPDBからのみ有効にできます。

22.2.22.2 統合監査ポリシーの有効化

AUDIT POLICY文で、統合監査ポリシーを有効にできます。

  • 次の構文を使用して、統合監査ポリシーを有効にします。

    AUDIT POLICY { policy_auditing }
     [WHENEVER [NOT] SUCCESSFUL]
    

詳細は、次のとおりです。

  • policy_auditingは、次のコンポーネントを示します。

    • 統合監査ポリシーの名前。既存のポリシーをすべて検索するには、AUDIT_UNIFIED_POLICIESデータ・ディクショナリ・ビューを問い合せます。現在有効なポリシーを検索するには、AUDIT_UNIFIED_ENABLED_POLICIESを問い合せます。

    • 統合監査ポリシーが適用されるユーザーまたはロール。ポリシーを1人以上のユーザー(ユーザーSYSを含む)に適用するには、BY句を入力します。例:

      BY psmith, rlee
      

      ロールのリストが直接付与された1人以上のユーザーにポリシーを適用するには、BY USERS WITH GRANTED ROLES句を使用します。例:

      BY USERS WITH GRANTED ROLES HS_ADMIN_ROLE, HS_ADMIN_SELECT_ROLE
    • 統合監査ポリシーから除外するユーザー。ポリシーから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データ・ディクショナリ・ビューを問い合せることで、監査レコードを検索できます。

22.2.22.3 例: 統合監査ポリシーの有効化

AUDIT POLICY文で、WHENEVER NOT SUCCESSFULなどの条件を使用して統合監査ポリシーを有効にできます。

例22-42に、ユーザーdv_adminによる失敗したアクションのみを統合監査ポリシーで記録できるようにする方法を示します。

例22-42 統合監査ポリシーの有効化

AUDIT POLICY dv_admin_pol BY tjones
 WHENEVER NOT SUCCESSFUL;

22.2.23 統合監査ポリシーの無効化

NOAUDIT POLICY文を使用して、統合監査ポリシーを無効にすることができます。

22.2.23.1 統合監査ポリシーの無効化について

NOAUDIT文とPOLICY句を組み合せることにより、統合監査ポリシーを無効にできます。

NOAUDIT文では、BYユーザー・リストまたはBY USERS WITH GRANTED ROLESロール・リストを指定できますが、EXCEPTユーザー・リストは指定できません。統合監査ポリシーを無効にすると、後続のユーザー・セッションに反映されます。

既存の統合監査ポリシーのリストを検索するには、AUDIT_UNIFIED_POLICIESデータ・ディクショナリ・ビューを問い合せます。

マルチテナント環境では、共通監査ポリシーはルートからのみ、ローカル監査ポリシーは、ローカル監査ポリシーが適用されるPDBからのみ無効にできます。

22.2.23.2 統合監査ポリシーの無効化

NOAUDIT文で、サポートされている監査オプションを使用して統合監査ポリシーを無効にできます。

  • 次の構文を使用して、統合監査ポリシーを無効にします。

    NOAUDIT POLICY {policy_auditing | existing_audit_options};
    

    詳細は、次のとおりです。

    • policy_auditingは、ポリシーの名前です。現在有効なポリシーをすべて検索するには、AUDIT_UNIFIED_ENABLED_POLICIESデータ・ディクショナリ・ビューを問い合せます。この指定の一部として、BYまたはBY USERS WITH GRANTED ROLES句をオプションで含めることができますが、EXCEPT句を含めることはできません。詳細は、統合監査ポリシーの有効化についてを参照してください。

    • 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 logons_pol;
22.2.23.3 例: 統合監査ポリシーの無効化

NOAUDIT POLICY文で、ユーザー名などのフィルタを使用して統合監査ポリシーを無効にします。

例22-43に、ユーザーまたはロールに対して統合監査ポリシーを無効にする方法の例を示します。

例22-43 統合監査ポリシーの無効化

NOAUDIT POLICY dv_admin_pol BY tjones;

NOAUDIT POLICY dv_admin_pol BY USERS WITH GRANTED ROLES emp_admin;

22.2.24 統合監査ポリシーの削除

DROP AUDIT POLICY文を使用して、統合監査ポリシーを削除できます。

22.2.24.1 統合監査ポリシーの削除について

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からのみ削除できます。

22.2.24.2 統合監査ポリシーの削除

統合監査ポリシーを削除するには、最初に無効にし、DROP AUDIT POLICY文を実行して削除します。

  • 次の構文を使用して、統合監査ポリシーを削除します。

    DROP AUDIT POLICY policy_name;
    

マルチテナント環境では、統合監査ポリシーの削除は現在のPDBに適用されます。統合監査ポリシーが共通統合監査ポリシーとして削除された場合は、ローカルのPDBから削除することはできません。

22.2.24.3 例: 統合監査ポリシーの無効化および削除

NOAUDIT POLICY文およびDROP AUDIT POLICY文で、統合監査ポリシーを無効化して削除できます。

例22-44に、共通統合監査ポリシーを無効化および削除する方法を示します。

例22-44 統合監査ポリシーの無効化および削除

CONNECT c##sec_admin
Enter password: password
Connected.

NOAUDIT POLICY dv_admin_pol;

DROP AUDIT POLICY dv_admin_pol

22.2.25 例: 非データベース・ユーザーの監査

このチュートリアルでは、非データベース・ユーザーのアクションをクライアント識別子を使用して監査する統合監査ポリシーの作成方法を示します。

22.2.25.1 ステップ1: ユーザー・アカウントの作成とユーザーOEがアクティブであることの確認

ユーザーを作成し、ユーザーOEがアクティブであることを確認する必要があります。

  1. SYSDBA管理権限を持つユーザーSYSとしてログインします。
    sqlplus sys as sysdba
    Enter password: password
    
  2. マルチテナント環境で、適切なPDBに接続します。

    例:

    CONNECT SYS@hrpdb AS SYSDBA
    Enter password: password
    

    利用可能なPDBを検索するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。現在のPDBを確認するには、show con_nameコマンドを実行します。

  3. ファイングレイン監査ポリシーを作成するローカル・ユーザーpolicy_adminを作成します。
    CREATE USER policy_admin IDENTIFIED BY password;
    GRANT CREATE SESSION, AUDIT_ADMIN TO policy_admin;
    

    「パスワードの最低要件」のガイドラインに従って、passwordを安全なパスワードに置き換えます。

  4. このポリシーの監査証跡をチェックするローカル・ユーザー・アカウントauditorを作成します。
    CREATE USER policy_auditor IDENTIFIED BY password;
    GRANT CREATE SESSION, AUDIT_VIEWER TO policy_auditor;
    
  5. この例ではサンプル・ユーザーOEも使用するため、DBA_USERSデータ・ディクショナリ・ビューを問い合せて、OEがロックされていたり、期限切れになっていないことを確認します。
    SELECT USERNAME, ACCOUNT_STATUS FROM DBA_USERS WHERE USERNAME = 'OE';
    

    アカウント・ステータスはOPENである必要があります。DBA_USERSビューに、ユーザーOEがロックされて期限切れになっていると表示された場合は、ユーザーSYSTEMでログインし、次の文を入力して、OEアカウントのロックを解除し、新しいパスワードを作成します。

    ALTER USER OE ACCOUNT UNLOCK IDENTIFIED BY password;
    

    「パスワードの最低要件」のガイドラインに従って、passwordを安全なパスワードに置き換えます。セキュリティを向上させるため、以前のリリースのOracle Databaseと同じパスワードをOEアカウントに指定しないでください

22.2.25.2 ステップ2: 統合監査ポリシーの作成

ここでは、統合監査ポリシーを作成します。

  1. ユーザーpolicy_adminでSQL*Plusに接続します。
    CONNECT policy_admin -- Or, CONNECT policy_admin@hrpdb
    Enter password: password
    
  2. 次のポリシーを作成します。
    CREATE AUDIT POLICY orders_unified_audpol 
      ACTIONS INSERT ON OE.ORDERS, UPDATE ON OE.ORDERS, DELETE ON OE.ORDERS, SELECT ON OE.ORDERS
      WHEN 'SYS_CONTEXT(''USERENV'', ''CLIENT_IDENTIFIER'') = ''robert''' 
        EVALUATE PER STATEMENT;
    
    AUDIT POLICY orders_unified_audpol;
    

    この例では、AUDIT_CONDITIONパラメータで非データベース・ユーザーの名前がrobertであると想定しています。ポリシーでは、robertが実行するINSERTUPDATEDELETEおよびSELECT文を監視します。ポリシーに入力するユーザーのCLIENT_IDENTITIFER設定は、大文字と小文字を区別し、ここで指定する識別情報に使用される大/小文字のみがポリシーで認識されることに注意してください。つまり、後でユーザー・セッションがRobertまたはROBERTに設定されると、ポリシーの条件は満たされません。

22.2.25.3 ステップ3: ポリシーのテスト

ポリシーをテストするため、ユーザーOEOE.ORDERS表から選択します。

統合監査ポリシーは、監査中のユーザーに対する次のユーザー・セッションで有効となります。したがって、監査記録を取得する前に、ユーザーはポリシーが作成されてからデータベースに接続する必要があります。
  1. ユーザーOEで接続し、OE.ORDERS表から選択します。
    CONNECT OE -- Or, CONNECT OE@hrpdb
    Enter password: password
    
    SELECT COUNT(*) FROM ORDERS;
    

    次のような出力結果が表示されます。

      COUNT(*)
    ----------
           105
    
  2. ユーザーpolicy_auditorで接続し、監査レコードが生成されたかどうかを確認します。
    CONNECT policy_auditor -- Or, CONNECT policy_auditor@hrpdb
    Enter password: password
    
    col dbusername format a10
    col client_identifier format a20
    col sql_text format a29
    
    SELECT DBUSERNAME, CLIENT_IDENTIFIER, SQL_TEXT FROM UNIFIED_AUDIT_TRAIL 
     WHERE SQL_TEXT LIKE '%FROM ORDERS%';
    

    次のような出力結果が表示されます。

    no rows selected
    
  3. ユーザーOEで再接続し、クライアント識別子をrobertに設定し、OE.ORDERS表から再選択します。
    CONNECT OE -- Or, CONNECT OE@hrpdb
    Enter password: password
    
    EXEC DBMS_SESSION.SET_IDENTIFIER('robert');
    
    SELECT COUNT(*) FROM ORDERS;
    

    次の出力が表示されます。

      COUNT(*)
    ----------
           105
    
  4. ユーザーauditorで再接続し、監査証跡を再び確認します。
    CONNECT policy_auditor -- Or, CONNECT policy_auditor@hrpdb
    Enter password: password
    
    SELECT DBUSERNAME, CLIENT_IDENTIFIER, SQL_TEXT FROM UNIFIED_AUDIT_TRAIL 
     WHERE SQL_TEXT LIKE '%FROM ORDERS%';
    

    今回は、robertが存在し、OE.ORDERS表を問い合せたため、監査証跡ではそのアクションが取得されます。

    DBUSERNAME CLIENT_IDENTIFIER SQL_TEXT
    ---------- ----------------- ----------------------------
    OE         robert            SELECT COUNT(*) FROM ORDERS;
    
22.2.25.4 ステップ4: このチュートリアルのコンポーネントの削除

このチュートリアルのコンポーネントが不要になった場合、それらを削除できます。

  1. ユーザーpolicy_adminでSQL*Plusに接続し、orders_unified_audpolポリシーを手動で無効にして削除します。
    CONNECT policy_admin -- Or, CONNECT policy_admin@hrpdb
    Enter password: password
    
    NOAUDIT POLICY orders_unified_audpol;
    DROP AUDIT policy orders_unified_audpol;
    

    (統合監査ポリシーは、作成したユーザーのスキーマではなく、SYSスキーマに存在します。)

  2. ユーザーSYSTEMとしてSQL*Plusに接続します。
    CONNECT SYSTEM -- Or, CONNECT SYSTEM@hrpdb
    Enter password: password
    
  3. ユーザーpolicy_adminおよびpolicy_auditorを削除します。
    DROP USER policy_admin;
    DROP USER policy_auditor;
    
  4. 他のユーザーがOEを使用しない場合、このアカウントはロックして期限切れにできます。
    ALTER USER OE PASSWORD EXPIRE ACCOUNT LOCK;

22.3 事前定義の統合監査ポリシーを使用したアクティビティの監査

Oracle Databaseには、よく使用されるセキュリティ関連の監査設定を対象とする、事前定義の統合監査ポリシーがあります。

22.3.1 ログオン失敗の事前定義の統合監査ポリシー

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;

22.3.2 セキュア・オプションの事前定義の統合監査ポリシー

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言語リファレンス』を参照してください。

22.3.3 Oracle Databaseパラメータ変更の事前定義の統合監査ポリシー

ORA_DATABASE_PARAMETERポリシーでは、よく使用されるOracle Databaseのパラメータ設定を監査します。

次のCREATE AUDIT POLICY文は、ORA_DATABASE_PARAMETER統合監査ポリシー定義を示しています。デフォルトでは、このポリシーは有効になっていません。

CREATE AUDIT POLICY ORA_DATABASE_PARAMETER
 ACTIONS ALTER DATABASE, ALTER SYSTEM, CREATE SPFILE;

22.3.4 ユーザー・アカウントおよび権限管理の事前定義の統合監査ポリシー

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;

22.3.5 Center for Internet Securityで推奨される事前定義の統合監査ポリシー

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;

22.3.6 Oracle Database Real Application Securityの事前定義の監査ポリシー

事前定義の統合監査ポリシーをOracle Database Real Application Securityのイベントに使用できます。

22.3.6.1 システム管理者操作の事前定義の統合監査ポリシー

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;
22.3.6.2 セッション操作の事前定義の統合監査ポリシー

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;

22.3.7 DVSYSおよびLBACSYSスキーマに対するOracle Database Vaultの事前定義の統合監査ポリシー

事前定義のORA_DV_AUDPOL統合監査ポリシーで、Oracle Database VaultのDVSYSおよびLBACSYSスキーマ・オブジェクトを監査します。

ORA_DV_AUDPOLポリシーは、Oracle Database VaultのDVSYS (DVFを含む)スキーマ・オブジェクトと、Oracle Label SecurityのLBACSYSスキーマ・オブジェクトに対して実行されるすべてのアクションを監査します。DVFスキーマのF$*ファクタ・ファンクションに関するアクションは取得しません。デフォルトでは、このポリシーは有効になっていません。

このポリシーの完全な定義を表示するには、policy_nameORA_DV_AUDPOLAUDIT_UNIFIED_POLICIESデータ・ディクショナリ・ビューを問い合せます。

22.3.8 デフォルト・レルムおよびコマンド・ルールに対するOracle Database Vaultの事前定義の統合監査ポリシー

事前定義のORA_DV_AUDPOL2の統合監査ポリシーで、Oracle Database Vaultのデフォルトのレルムおよびコマンド・ルールが監査されます。

ORA_DV_AUDPOL2ポリシーには、Oracle Database Vaultで提供されるデフォルトのレルムおよびコマンド・ルールの監査設定が定義されています。デフォルトでは、このポリシーは有効になっていません。

このポリシーの完全な定義を表示するには、policy_nameORA_DV_AUDPOL2AUDIT_UNIFIED_POLICIESデータ・ディクショナリ・ビューを問い合せます。

22.4 ファイングレイン監査を使用した特定のアクティビティの監査

ファイングレイン監査では、非常に詳細なレベルで監査ポリシーを作成できます。

22.4.1 ファイングレイン監査について

ファイングレイン監査では、ポリシーを作成して、監査が実行される特定の条件を定義できます。

ファイングレイン監査を使用して統合監査ポリシーは作成できませんが、データのアクセス時間の監査など、詳細にカスタマイズされた監査設定はファイングレイン監査を使用して作成できます。

これにより、内容に基づいてデータ・アクセスを監視できるようになります。問合せと、INSERTUPDATE、およびDELETE操作に対して詳細な監査を提供します。ファイングレイン監査を使用すると、次のタイプのアクションを監査できます。

  • 午後9時から午前6時の間、または土曜日と日曜日に表にアクセスする場合

  • 社内ネットワーク外部のIPアドレスを使用する場合

  • 表の列を選択または更新する場合

  • 表の列の値を変更する場合

通常、ファイングレイン監査ポリシーは、選択的監査の条件である、表オブジェクトに対する単純なユーザー定義SQL述語に基づいています。フェッチ中に行がポリシーの条件を満たすと、その問合せが監査対象となります。

統合監査ポリシーおよびAUDIT文を使用したアクティビティの監査で説明されている監査ポリシーでは、次のアクションを除き、ファイングレイン監査ポリシーで実行可能な大部分の操作を実行できます。

  • 特定の列の監査。給与や社会保障番号など、機密情報が格納されている特定の関連する列を監査できます。

  • イベント・ハンドラの使用。たとえば、夜中に変更されないようにする必要がある監査対象の列が更新された場合に、セキュリティ管理者に電子メール・アラートを送信する関数を作成できます。

ノート:

  • ファイングレイン監査は、コストベースの最適化でのみサポートされています。ルールベースの最適化を使用する問合せでは、行フィルタを適用する前にファイングレイン監査が行われるため、不要な監査イベント・トリガーが発生します。

  • フラッシュバック問合せに含まれるオブジェクトで現在有効なポリシーが、指定したフラッシュバック・スナップショット(時間またはシステム変更番号(SCN)に基づく)から戻されたデータに適用されます。

  • ファイングレイン監査を使用して直接ロードされるデータを監査する場合(たとえばOracle Warehouse Builderを使用してDML文を実行する場合)、Oracle Databaseは透過的にデータベース・インスタンスで実行されているすべてのダイレクト・ロードを従来型ロードにします。データのダイレクト・ロードを保持する場合は、かわりに統合監査ポリシーの使用を検討してください。

22.4.2 ファイングレイン監査レコードが格納される場所

ファイングレイン監査のレコードは、AUDSYSスキーマに格納されます。

これらの監査レコードは、デフォルトでSYSAUX表領域に格納されます。DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATIONプロシージャを使用して、新しい表領域を指定できます。この表領域は暗号化された表領域にできます。有効な監査ポリシーに対して生成されたレコードを検索するには、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せます。

監査証跡では、SQL文内の表またはビューの参照ごとに監査レコードが取得されます。たとえば、HR.EMPLOYEES表を2回参照するUNION文を実行した場合、文の監査ポリシーによって2つ(HR.EMPLOYEES表へのアクセスごとに1つ)の監査レコードが生成されます。

関連項目:

22.4.3 ファイングレイン監査の実行者

Oracleには、ファイングレイン監査ポリシーを作成したり、ファイングレイン監査ポリシーのデータを表示および分析するために必要な権限のロールが用意されています。

ファイングレイン監査には、次の権限があります。

  • ファイングレイン監査ポリシーを作成するには、AUDIT_ADMINロールまたはDBMS_FGAパッケージに対するEXECUTE権限が付与されている必要があります。

  • ファイングレイン監査データを表示および分析するには、AUDIT_VIEWERロールが付与されている必要があります。

PL/SQLパッケージにはAUDIT_ADMINロールがすでに付与されています。すべての権限と同様に、これらのロールは信頼できるユーザーにのみ付与してください。DBA_ROLE_PRIVSデータ・ディクショナリ・ビューを問い合せることで、ユーザーに付与されているロールを確認できます。

22.4.4 Oracle VPDポリシーがある表またはビューでのファイングレイン監査

この監査証跡は、Oracle VPDポリシーに含まれているファイングレイン監査表またはビューからVPD述語を取得します。

この動作は、統合監査証跡で統合監査ポリシーのVPD述語を取得する場合の動作に似ています。

監査証跡では、Oracle Label SecurityおよびOracle Real Application Securityのポリシーの内部述語も取得されます。

VPD述語監査レコードを取得するために特別な監査ポリシーを作成する必要はありません。述語情報は、DBA_FGA_AUDIT_TRAILおよびUNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューのRLS_INFO列に自動的に格納されます。

同じ表またはビューに適用されるVPDポリシーが複数ある場合、これらのポリシーの述部は、デフォルトでRLS_INFO列に連結されます。各述語がそれ自体の行(対応するVPDポリシー名などの情報で特定)に含まれるように出力を再フォーマットするには、DBMS_AUDIT_UTIL PL/SQL パッケージのファンクションを使用します。

関連項目:

22.4.5 マルチテナント環境でのファイングレイン監査

ファイングレイン監査ポリシーは、CDBルート、アプリケーション・ルート、CDB PDBおよびアプリケーションPDBで作成できます。

マルチテナント環境におけるファイングレイン監査ポリシーには、次のような一般的なルールがあります。

  • ファイングレイン監査ポリシーは、SYSオブジェクトに対して作成できません。

  • ファイングレイン監査ポリシーは(ローカルまたはアプリケーション共通を問わず)、拡張データ・リンク・オブジェクトに対して作成できません。

  • CDBルートでファイングレイン監査ポリシーを作成する場合、すべてのPDBにポリシーを適用することはできません。ポリシーはCDBルート内のオブジェクトに適用されます。(つまり、CDBルートに対する共通のファイングレイン監査ポリシーは存在しません。)すべてのPDBで共通オブジェクトのアクセスを監査するようにファイングレイン監査ポリシーを作成する場合は、監査ポリシーを各PDBで明示的に作成し、PDBでアクセス可能にする共通オブジェクトに対してそのポリシーを有効化する必要があります。

  • PDBでファイングレイン監査ポリシーを作成する場合、ポリシーはPDB内のオブジェクトにのみ適用されます。

  • アプリケーション共通ファイングレイン監査ポリシーは、アプリケーション・ルートに接続し、BEGIN/ENDブロック内にいる場合にのみ作成できます。アプリケーション・ルートに接続し、BEGIN/ENDブロック外でファイングレイン監査ポリシーを作成すると、ファイングレイン監査ポリシーはアプリケーション・ルートに作成されます。

  • アプリケーション共通ファイングレイン監査ポリシーは、ローカルPDBオブジェクトに対して作成できません。

  • アプリケーション共通ファイングレイン監査ポリシーにハンドラがある場合、このハンドラはアプリケーション共通ユーザーまたはCDB共通ユーザーによって所有されている必要があります。

  • アプリケーション・ファイングレイン監査ポリシーは、ローカル(PDB)オブジェクトおよびCDB共通オブジェクトに対して作成できます。ポリシーはそのコンテナに対してローカルであるため、ポリシーが定義されたオブジェクトは、ポリシーが定義された特定のコンテナ内でのみ監査されます。たとえば、ファイングレイン監査ポリシーをhr_pdb PDBで作成する場合、このポリシーを作成する対象のオブジェクトは、hr_pdb PDB内に存在する必要があります。

  • ローカル・ファイングレイン監査ポリシーは、アプリケーションPDB内のオブジェクト・リンク・オブジェクトおよび拡張データ・リンク・オブジェクトに対して作成できません。メタデータリンク・オブジェクトは、ファイングレイン監査ポリシーで使用できます。

  • アプリケーション・ルート・ローカル・ポリシーは、アプリケーション共通オブジェクトに対して使用できます。

  • ファイングレイン監査ポリシーを共通監査ポリシーとしてアプリケーション・ルートで作成する場合、このアプリケーション・ルートに属する各PDBで有効になります。したがって、アプリケーションPDBのアプリケーション共通オブジェクトおよびCDB共通オブジェクト(アプリケーション共通ファイングレイン監査ポリシーが定義されたもの)は、そのアプリケーションPDB内のファイングレイン監査証跡において監査されます。

  • アプリケーションのインストール、アップグレード、パッチ適用またはアンインストール操作用のスクリプトを作成する際、ALTER PLUGGABLE DATABASE app_name BEGIN INSTALLおよびALTER PLUGGABLE DATABASE app_name END INSTALLブロック内にSQL文を含めて、様々な操作を実行できます。ファイングレイン監査ポリシー文は、これらのブロック内にのみ含めることができます。

  • アプリケーション共通ファイングレイン監査ポリシーの有効化、無効化または削除の実行は、アプリケーション・ルートから、およびスクリプト内のALTER PLUGGABLE DATABASE app_name BEGIN INSTALLおよびALTER PLUGGABLE DATABASE app_name END INSTALLブロック内からに限定されます。

22.4.6 ファイングレイン監査ポリシーとエディション

エディション・ベースの再定義のアプリケーションを作成し、アプリケーションが編集ビューで使用する各表を対象とすることができます。

これを行う場合、編集ビューに対してこれらの表を保護するファイングレイン監査ポリシーを移動する必要があります。DBA_EDITIONSデータ・ディクショナリ・ビューを問い合せることで、現在構成されているエディションについて情報を確認できます。ファイングレイン監査ポリシーに関する情報を確認するには、DBA_AUDIT_POLICIESを問い合せます。

22.4.7 DBMS_FGA PL/SQLパッケージを使用したファイングレイン監査ポリシーの管理

DBMS_FGA PL/SQLパッケージで、ファイングレイン監査ポリシーを管理します。

22.4.7.1 DBMS_FGA PL/SQL PL/SQLパッケージについて

DBMS_FGA PL/SQLパッケージを使用して複数の文を1つのポリシーにまとめ、その他のファイングレイン監査管理タスクを実行できます。

ただし、列レベルの監査を実行しない場合や、イベント・ハンドラと監査ポリシーを使用しない場合は、統合監査ポリシーおよびAUDIT文を使用したアクティビティの監査で説明されているように、監査ポリシーを作成する必要があります。

DBMS_FGA PL/SQLパッケージを使用すると、SELECTINSERTUPDATEおよびDELETE文のすべての組合せを1つのポリシーに追加できます。また、基礎となるアクションのINSERTおよびUPDATEを監査することによって、MERGE文も監査できます。MERGE文を監査するには、INSERTおよびUPDATE文に対するファイングレイン・アクセスを構成します。成功したMERGE操作についてポリシーごとにレコードが1つのみ生成されます。

ファイングレイン監査ポリシーを管理するには、AUDIT_ADMINロールを付与する必要があります。DBMS_FGAパッケージのEXECUTE権限は強制的に監査されることにも注意してください。

監査ポリシーは、監査ポリシーを作成した表にバインドされます。これにより、それぞれのアプリケーションではなく、データベースで一度だけポリシーを変更すればよいため、監査ポリシーの管理が容易です。また、データベースへの接続方法(接続元がアプリケーション、Webインタフェース、SQL*PlusやOracle SQL Developerのいずれであるか)に関係なく、ポリシーに影響を与えるアクションがすべて記録されます。

問合せから戻された行が定義した監査条件と一致すると、ファイングレイン監査証跡に監査エントリが挿入されます。このエントリでは、通常の監査証跡でレポートされるすべての情報が除外されます。つまり、TRUEと評価されたすべてのファイングレイン監査ポリシーに対して、1行の監査情報のみが監査証跡に挿入されます。

22.4.7.2 DBMS_FGA PL/SQLパッケージとエディション

エディション環境で使用するためのDBMS_FGAポリシーを作成できます。

DBMS_FGAパッケージ・ポリシーを異なる複数のエディションで使用する場合、ポリシーの結果を制御できます。つまり、結果をすべてのエディションで同一にするか、またはポリシーが使用されているエディションに固有にできます。

22.4.7.3 マルチテナント環境でのDBMS_FGA PL/SQLパッケージ

マルチテナント環境では、DBMS_FGA PL/SQLパッケージは現在のローカルPDBのみに適用されます。

マルチテナント環境全体に1つのポリシーを作成することはできません。PDB内でオブジェクトにポリシーを指定する必要があります。PDBを確認するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。現在のPDBの名前を見つけるには、show con_nameコマンドを発行します。

22.4.7.4 ファイングレイン監査ポリシーの作成

DBMS_FGA.ADD_POLICYプロシージャで、ファイングレイン監査ポリシーを作成します。

22.4.7.4.1 ファイングレイン監査ポリシーの作成について

DBMS_FGA.ADD_POLICYプロシージャで、指定された述語を監査条件として使用し、監査ポリシーを作成します。

デフォルトでは、ポリシーを作成したユーザーの権限で、ポリシーの述語がOracle Databaseによって実行されます。表オブジェクトまたはビュー・オブジェクトに設定可能なファイングレイン・ポリシーの最大数は256です。Oracle Databaseでは、ポリシーはデータ・ディクショナリ表に格納されますが、SYSスキーマ内に存在しない表またはビューに関するポリシーを作成できます。マルチテナント環境では、ファイングレイン・ポリシーはローカルPDBでのみ作成されます。

ファイングレイン監査ポリシーを作成後に変更することはできません。ポリシーを変更する必要がある場合は、削除してから再作成します。

ファイングレイン監査ポリシーに関する情報を検索するには、ALL_AUDIT_POLICIESDBA_AUDIT_POLICIESおよびALL_AUDIT_POLICIESビューを問い合せます。UNIFIED_AUDIT_TRAILビューには、FGA_POLICY_NAMEという名前の列が含まれ、この列を使用すると、特定のファイングレイン監査ポリシーを使用して生成された行をフィルタできます。

22.4.7.4.2 ファイングレイン監査ポリシーの作成の構文

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文を指定します。INSERTUPDATEDELETEまたは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パッケージおよびタイプ・リファレンス』を参照してください。
22.4.7.4.3 特定の列および行の監査

条件が一致した列(関連列)を監査対象にするなど、監査動作を細かく調節できます。

これを実行するには、audit_columnパラメータを使用して、機密情報が含まれた列を1つ以上指定します。また、audit_conditionパラメータを使用してブール条件を定義すると、特定の行のデータを監査できます。(ただし、ポリシーで条件の監査のみが必要な場合は、統合監査ポリシーの条件の作成で説明されている監査ポリシー条件の使用を検討してください。)

例22-45では、次の設定によって、部門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_conditionaudit_columnおよびaudit_column_optsパラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください(その項のADD_POLICYプロシージャの使用上のノートも参照してください)。
22.4.7.5 例: DBMS_FGA.ADD_POLICYを使用してファイングレイン監査ポリシーを作成する方法

DBMS_FGA.ADD_POLICYプロシージャで、複数の文タイプを使用してファイングレイン監査ポリシーを作成できます。

例22-45に、表HR.EMPLOYEESに対する文INSERTUPDATEDELETEおよびSELECTを監査する方法を示します。

この例では、audit_column_optsパラメータが必須パラメータではないため省略されていることに注意してください。

例22-45 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;
22.4.7.6 ファイングレイン監査ポリシーを使用禁止にする方法

DBMS_FGA.DISABLE_POLICYプロシージャで、ファイングレイン監査ポリシーを無効にします。

  • 次の構文を使用して、ファイングレイン監査ポリシーを無効にします。

    DBMS_FGA.DISABLE_POLICY(
       object_schema  VARCHAR2, 
       object_name    VARCHAR2, 
       policy_name    VARCHAR2); 
    

たとえば、例22-45で作成されたファイングレイン監査ポリシーを無効にするには、次のようにします。

BEGIN
 DBMS_FGA.DISABLE_POLICY(
  object_schema        => 'HR',
  object_name          => 'EMPLOYEES',
  policy_name          => 'chk_hr_employees');
END;
/
22.4.7.7 ファイングレイン監査ポリシーを使用可能にする方法

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;
/
22.4.7.8 ファイングレイン監査ポリシーの削除

DBMS_FGA.DROP_POLICYプロシージャで、ファイングレイン監査ポリシーを削除します。

DBMS_FGA.ADD_POLICYプロシージャのobject_nameパラメータで指定されたオブジェクトを削除したり、監査ポリシーを作成したユーザーを削除した場合、自動的に監査ポリシーが削除されます。

  • 次の構文を使用して、ファイングレイン監査ポリシーを削除します。

    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;
/

22.4.8 例: ファイングレイン監査ポリシーへの電子メール・アラートの追加

このチュートリアルでは、ユーザーがポリシーに違反したときに電子メールのアラートを生成するファイングレイン監査ポリシーの作成方法を示します。

22.4.8.1 このチュートリアルについて

このチュートリアルでは、ユーザー(または侵入者)がポリシーに違反したときに実施される電子メールのアラートをファイングレイン監査ポリシーに追加する方法を示します。

ノート:

  • このチュートリアルを完了するには、SMTPサーバーのあるデータベースを使用する必要があります。

  • マルチテナント環境を使用している場合、このチュートリアルは現在のPDBのみに適用されます。

ファイングレイン監査ポリシーに電子メール・アラートを追加するには、最初にアラートを生成するプロシージャを作成し、次のDBMS_FGA.ADD_POLICYパラメータを使用して、ユーザーがこのポリシーに違反した場合にこのファンクションをコールする必要があります。

  • handler_schema: ハンドラ・イベントが格納されるスキーマ

  • handler_module: イベント・ハンドラの名前

アラートは、電子メールまたはポケベルによる通知や、特定のファイルまたは表の更新など、環境に適した形式で生成できます。アラートを作成すると、California Senate Bill 1386などの特定のコンプライアンス規制を満たすことも可能です。この例では、電子メール・アラートを作成します。

この例では、セキュリティ管理者に対して、人事部門の担当者がHR.EMPLOYEES表内の給与情報を選択または変更しようとしていることを通知する電子メール・アラートを作成します。担当者はこの表を変更することを許可されていますが、コンプライアンス規制を満たすために、表内の給与情報に対するすべての選択および変更操作に関するレコードを作成できます。

22.4.8.2 ステップ1: UTL_MAIL PL/SQLパッケージのインストールおよび構成

UTL_MAIL PL/SQLで、添付、CCおよびBCCなど一般に使用される電子メール機能が組み込まれた電子メールを管理します。

このパッケージを使用するには、インストールして構成する必要があります。このコンポーネントは、デフォルトではインストールおよび構成されません。
  1. SYSDBA管理権限を持つユーザーSYSとしてログインします。
    sqlplus sys as sysdba
    Enter password: password
    
  2. マルチテナント環境で、適切なPDBに接続します。

    例:

    CONNECT SYS@hrpdb AS SYSDBA
    Enter password: password
    

    利用可能なPDBを検索するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。現在のPDBを確認するには、show con_nameコマンドを実行します。

  3. UTL_MAILパッケージをインストールします。
    @$ORACLE_HOME/rdbms/admin/utlmail.sql
    @$ORACLE_HOME/rdbms/admin/prvtmail.plb
    

    UTL_MAILパッケージにより、電子メールの管理が可能になります。

    現在、UTL_MAIL PL/SQLパッケージではSSLサーバーはサポートされていないことに注意してください。

  4. この例が終了した後に元に戻すことができるよう、SMTP_OUT_SERVER初期化パラメータの現行の値を調べてノートにとっておきます。

    例:

    SHOW PARAMETER SMTP_OUT_SERVER
    

    SMTP_OUT_SERVERパラメータがすでに設定されている場合は、次のような出力が表示されます。

    NAME                    TYPE              VALUE
    ----------------------- ----------------- ----------------------------------
    SMTP_OUT_SERVER         string            some_imap_server.example.com
    
  5. 次のALTER SYSTEM文を発行します。
    ALTER SYSTEM SET SMTP_OUT_SERVER="imap_mail_server.example.com";
    

    imap_mail_server.example.comを、電子メール・ツールのアカウント設定にあるSMTPサーバーの名前に置き換えます。これらの設定を引用符で囲んでください。例:

    ALTER SYSTEM SET SMTP_OUT_SERVER="my_imap_server.example.com";
    
    
  6. SYSOPER権限を使用してSYSとして接続し、データベースを再起動します。
    CONNECT SYS AS SYSOPER -- Or, CONNECT SYS@hrpdb AS SYSOPER
    Enter password: password
    
    SHUTDOWN IMMEDIATE
    STARTUP
    
  7. SMTP_OUT_SERVERパラメータの設定が正しいことを確認します。
    CONNECT SYS AS SYSDBA -- Or, CONNECT SYS@hrpdb AS SYSDBA
    Enter password: password
    
    SHOW PARAMETER SMTP_OUT_SERVER
    

    次のような出力が表示されます。

    NAME                    TYPE              VALUE
    ----------------------- ----------------- ----------------------------------
    SMTP_OUT_SERVER         string            my_imap_server.example.com
22.4.8.3 ステップ2: ユーザー・アカウントの作成

管理アカウントおよび監査ユーザーを作成する必要があります。

  1. SYSとしてSYSDBA管理権限で接続していることを確認し、fga_adminユーザー(ファイングレイン監査ポリシーの作成者)を作成します。

    例:

    CONNECT SYS AS SYSDBA -- Or, CONNECT SYS@hrpdb AS SYSDBA
    Enter password: password
    
    CREATE USER fga_admin IDENTIFIED BY password;
    GRANT CREATE SESSION, CREATE PROCEDURE, AUDIT_ADMIN TO fga_admin;
    GRANT EXECUTE ON UTL_TCP TO fga_admin;
    GRANT EXECUTE ON UTL_SMTP TO fga_admin;
    GRANT EXECUTE ON UTL_MAIL TO fga_admin;
    GRANT EXECUTE ON DBMS_NETWORK_ACL_ADMIN TO fga_admin;
    

    「パスワードの最低要件」のガイドラインに従って、passwordを安全なパスワードに置き換えます。

    UTL_TCPUTL_SMTPUTL_MAILおよびDBMS_NETWORK_ACL_ADMIN PL/SQLパッケージは、作成する電子メール・セキュリティ・アラートで使用されます。

  2. このポリシーの監査証跡をチェックする監査者ユーザーを作成します。
    GRANT CREATE SESSION TO fga_auditor IDENTIFIED BY password;
    GRANT AUDIT_VIEWER TO fga_auditor;
    
  3. ユーザーSYSTEMで接続します。
    CONNECT SYSTEM -- Or, CONNECT SYSTEM@hrpdb
    Enter password: password
    
  4. HRスキーマ・アカウントのロックが解除され、パスワードが付与されていることを確認します。必要に応じて、HRのロックを解除し、このユーザーにパスワードを付与します。
    SELECT USERNAME, ACCOUNT_STATUS FROM DBA_USERS WHERE USERNAME = 'HR';
    

    アカウント・ステータスはOPENである必要があります。DBA_USERSビューに、ユーザーHRがロックされて期限切れになっていると表示された場合は、次の文を入力して、HRアカウントのロックを解除し、新しいパスワードを作成します。

    ALTER USER HR ACCOUNT UNLOCK IDENTIFIED BY password;
    

    「パスワードの最低要件」のガイドラインに従って、安全なパスワードを作成します。セキュリティを向上させるため、以前のリリースのOracle Databaseと同じパスワードをHRアカウントに指定しないでください

  5. 人事部門の担当者であるSusan Mavris(アクションの監査対象)用のユーザー・アカウントを作成し、このユーザーにHR.EMPLOYEES表へのアクセス権を付与します。
    GRANT CREATE SESSION TO smavris IDENTIFIED BY password;
    GRANT SELECT, INSERT, UPDATE, DELETE ON HR.EMPLOYEES TO SMAVRIS; 
22.4.8.4 ステップ3: ネットワーク・サービス用のアクセス制御リストの構成

アクセス制御リスト(ACL)ファイルを使用して、外部ネットワーク・サービスへのファイングレイン・アクセスを有効にできます。

UTL_MAILなどのPL/SQLネットワーク・ユーティリティ・パッケージを使用するには、このタイプのアクセス制御リスト(ACL)ファイルを構成する必要があります。

  1. ユーザーfga_adminでSQL*Plusに接続します。
    CONNECT fga_admin -- Or, CONNECT fga_admin@hrpdb
    Enter password: password
    
  2. 次のアクセス制御設定とその権限定義を構成します。
    BEGIN
     DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
      host       => 'SMTP_OUT_SERVER_setting',
      lower_port => 25,
      ace        =>  xs$ace_type(privilege_list => xs$name_list('smtp'),
                                 principal_name => 'FGA_ADMIN',
                                 principal_type => xs_acl.ptype_db));
    END;
    /
    
    

    この例では、次のようになります。

    • SMTP_OUT_SERVER_setting: 「ステップ1: UTL_MAIL PL/SQLパッケージのインストールおよび構成」SMTP_OUT_SERVERパラメータに設定したSMTP_OUT_SERVER設定を入力します。この設定は、電子メール・ツールで送信サーバーに指定されている設定と完全に一致させてください。

    • lower_port: 電子メール・ツールで送信サーバーに指定されているポート番号を入力します。通常、この設定は25です。この値をlower_port設定に入力します。(現在、UTL_MAILパッケージではSSLをサポートしていません。電子メール・サーバーがSSLサーバーの場合、その電子メール・サーバーが別のポート番号を使用していても、ポート番号に25を入力します。)

    • ace: ここで権限を定義します。

関連項目:

アクセス制御リスト(ACL)ファイルの構成の詳細は、「PL/SQLパッケージおよびタイプでのファイングレイン・アクセスの管理」を参照してください。
22.4.8.5 ステップ4: 電子メール・セキュリティ・アラート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を通知の受信対象者の電子メール・アドレスに置き換えます。

22.4.8.6 ステップ5: ファイングレイン監査ポリシー設定の作成とテスト

ファイングレイン監査ポリシーは、ポリシーの違反があるとアラートをトリガーします。

  1. ユーザーfga_adminで、chk_hr_empポリシーをファイングレイン監査ポリシーとして次のように作成します。
    BEGIN
     DBMS_FGA.ADD_POLICY (
      object_schema      =>  'HR',
      object_name        =>  'EMPLOYEES',
      policy_name        =>  'CHK_HR_EMP',
      audit_column       =>  'SALARY', 
      handler_schema     =>  'FGA_ADMIN',
      handler_module     =>  'EMAIL_ALERT',
      enable             =>   TRUE,
      statement_types    =>  'SELECT, UPDATE');
    END;
    /
    
  2. データベースに加えた変更をコミットします。
    COMMIT;
    
  3. これまでに作成した設定をテストします。
    EXEC email_alert ('hr', 'employees', 'chk_hr_emp');
    

    SQL*Plusに「PL/SQL procedure successfully completed」というメッセージが表示されます。まもなく、電子メール・サーバーの速度に応じて、電子メール・アラートを受信します。

    ORA-24247「アクセス制御リスト(ACL)によりネットワーク・アクセスが拒否されました」エラーの後にORA-06512「stringstringエラーが発生した場合は、アクセス制御リスト・ファイル内の設定を確認してください。

22.4.8.7 ステップ6: アラートのテスト

コンポーネントの準備ができたら、アラートをテストします。

  1. ユーザーsmavrisでSQL*Plusに接続し、自分の給与を確認して金額を引き上げます。
    CONNECT smavris -- Or, CONNECT smavris@hrpdb
    Enter password: password
    
    SELECT SALARY FROM HR.EMPLOYEES WHERE LAST_NAME = 'Mavris';
    
    SALARY
    -----------
    6500
    
    UPDATE HR.EMPLOYEES SET SALARY = 38000 WHERE LAST_NAME = 'Mavris';
    

    ここまでの手順を実行すると、電子メール・サーバーの速度に応じて、自分自身(または通知の受信対象者)にTable modification on HR.EMPLOYEESという件名ヘッダーの電子メールが届き、HR.EMPLOYEES表の改ざんについて通知されます。違反者を検索するのに必要なのは、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せるのみです。

  2. 次のようにユーザーfga_auditorとして、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せます。
    CONNECT fga_auditor -- Or, CONNECT fga_auditor@hrpdb
    Enter password: password
    
    col dbusername format a20
    col sql_text format a66
    col audit_type format a17
    
    SELECT DBUSERNAME, SQL_TEXT, AUDIT_TYPE 
    FROM UNIFIED_AUDIT_TRAIL 
    WHERE OBJECT_SCHEMA = 'HR' AND OBJECT_NAME = 'EMPLOYEES';
    

    次のような出力が表示されます。

    DBUSERNAME  SQL_TEXT                                                          AUDIT_TYPE
    ----------  ----------------------------------------------------------------- ----------------
    SMAVRIS     UPDATE HR.EMPLOYEES SET SALARY = 38000 WHERE LAST_NAME = 'Mavris' FineGrainedAudit
    

    監査証跡では、Susan Mavrisが実行し、HR.EMPLOYEES表のSALARY列に影響を与えたSQL文が取得されます。彼女が実行した最初の文(現在の給与に関して尋ねた文)は、監査ポリシーの影響を受けなかったため、記録されませんでした。これは、Oracle Databaseでは、監査関数は自律型トランザクションとして実行され、handler_module設定のアクションのみをコミットし、ユーザー・トランザクションはコミットしないためです。この関数はユーザーのSQLトランザクションには影響を与えません。

22.4.8.8 ステップ7: このチュートリアルのコンポーネントの削除

このチュートリアルのコンポーネントが不要になった場合、それらを削除できます。

  1. SYSTEM権限を持つユーザーでSQL*Plusに接続し、ユーザーfga_admin (fga_adminスキーマ内のオブジェクトを含む)、fga_auditorおよびsmavrisを削除します。
    CONNECT SYSTEM -- Or, CONNECT SYSTEM@hrpdb
    Enter password: password
    
    DROP USER fga_admin CASCADE;
    DROP USER fga_auditor;
    DROP USER smavris;
    
  2. ユーザーHRで接続し、Susan Mavrisの引き上げた給与を元に戻します。
    CONNECT HR -- Or, CONNECT HR@hrpdb
    Enter password: password
    
    UPDATE HR.EMPLOYEES SET SALARY = 6500 WHERE LAST_NAME = 'Mavris';
    
  3. 他のユーザーがHRを使用しない場合、このアカウントはロックして期限切れにできます。
    ALTER USER HR PASSWORD EXPIRE ACCOUNT LOCK;
    
  4. 次のALTER SYSTEM文を発行して、ステップ1: UTL_MAIL PL/SQLパッケージのインストールおよび構成のステップ5からSMTP_OUT_SERVERパラメータを前の値にリストアします。
    ALTER SYSTEM SET SMTP_OUT_SERVER="previous_value";
    

    この設定は引用符で囲みます。例:

    ALTER SYSTEM SET SMTP_OUT_SERVER="some_imap_server.example.com"
    
  5. データベース・インスタンスを再起動します。

22.5 監査ポリシーのデータ・ディクショナリ・ビュー

データ・ディクショナリ・ビューおよび動的ビューを使用して詳細な監査情報を入手できます。

表22-20 に、これらのビューを示します。

ヒント:

監査ポリシーに関するエラー情報を検索するには、トレース・ファイルを確認します。USER_DUMP_DEST初期化パラメータは、トレース・ファイルの位置を示します。

表22-20 監査アクティビティに関する情報を表示するビュー

ビュー 説明

ALL_AUDIT_POLICIES

すべてのファイングレイン監査ポリシーに関する情報が表示されます。

ALL_DEF_AUDIT_OPTS

オブジェクトの作成時に適用されるデフォルトのオブジェクト監査オプションがリストされます。

AUDIT_UNIFIED_CONTEXTS

監査証跡で取得されるように構成されているアプリケーション・コンテキスト値が表示されます。

AUDIT_UNIFIED_ENABLED_POLICIES

データベースで有効なすべての統合監査ポリシーが表示されます。

AUDIT_UNIFIED_POLICIES

データベースで作成されたすべての統合監査ポリシーが表示されます。

AUDIT_UNIFIED_POLICY_COMMENTS

COMMENT SQL文を使用して統合監査ポリシーに説明が入力された場合に、各統合監査ポリシーの説明が表示されます。

AUDITABLE_SYSTEM_ACTIONS

監査可能なシステム・アクション番号がアクション名にマップされます。

CDB_UNIFIED_AUDIT_TRAIL

UNIFIED_AUDIT_TRAILビューと同様、監査レコードを表示しますが、マルチテナント環境のすべてのPDBからの監査レコードを表示します。このビューは、CDBルートのみで使用可能で、そこから問い合せる必要があります。

DBA_AUDIT_POLICIES

ファイングレイン監査ポリシーに関する情報が表示されます。

DBA_SA_AUDIT_OPTIONS

ユーザーによって実行される監査対象のOracle Label Securityイベントが表示され、ユーザーのアクションが成功したか失敗したかが示されます。

DBA_XS_AUDIT_TRAIL

Oracle Database Real Application Securityに関連する監査証跡の情報が表示されます。

DV$CONFIGURATION_AUDIT

Oracle Database Vault管理者による構成変更が表示されます。

DV$ENFORCEMENT_AUDIT

Oracle Database Vaultポリシーによって影響を受けるユーザー・アクティビティが表示されます。

SYSTEM_PRIVILEGE_MAP (表)

権限(監査オプション)型コードが表示されます。この表を使用して、権限(監査オプション)の型番号を型名にマップできます。

USER_AUDIT_POLICIES

現行ユーザーによって所有される表およびビューのすべてのファイングレイン監査ポリシーに関する情報が表示されます。

UNIFIED_AUDIT_TRAIL

すべての監査レコードが表示されます。

V$OPTION

統合監査のPARAMETER列を問い合せて、統合監査が有効かどうかを確認できます。

V$XML_AUDIT_TRAIL

XML形式のファイルに書き込まれた標準監査、ファイングレイン監査、SYS監査および必須監査のレコードが表示されます。

関連項目:

これらのビューの詳細は、Oracle Databaseリファレンスを参照してください。