1. 管理者ガイド
  2. マルチテナント環境の管理
  3. マルチテナント環境のセキュリティの管理

18 マルチテナント環境のセキュリティの管理

SQL*PlusおよびOracle Enterprise Managerを使用して、マルチテナント環境の共通およびローカルのユーザーとロールを管理できます。

この章のトピックは、次のとおりです:

親トピック: マルチテナント環境の管理

マルチテナント環境のセキュリティの管理

SQL*PlusまたはSQL Developerを使用して、マルチテナント環境の共通およびローカルのユーザーとロールを管理できます。

この項では、次の項目について説明します。

親トピック: マルチテナント環境のセキュリティの管理

共通およびローカルに付与される権限の管理

親トピック: マルチテナント環境のセキュリティの管理

Oracleマルチテナント・オプションが権限に影響を与えるしくみ

マルチテナント環境では、共通ユーザーを含むすべてのユーザーは、現在のコンテナ内でのみ権限を実行できます。

ただし、ルートに接続されているユーザーは、他のプラガブル・データベース(PDB)に影響を与える特定の操作を実行できます。これらの操作には、ALTER PLUGGABLE DATABASE、CREATE USER、CREATE ROLEおよびALTER USERが含まれます。共通ユーザーは、これらの操作を可能にする、共通に付与される権限を持つ必要があります。ルートに接続されている共通ユーザーは、ビューにアクセスするために必要な権限を付与されていて、様々なPDBに関するデータを表示できるようにCONTAINER_DATA属性が設定されている場合、ルートのコンテナ・データ・オブジェクト(たとえば、マルチテナント・コンテナ・データベース(CDB)・ビューやV$ビューなど)を介してPDBに関するメタデータを確認できます。共通ユーザーは、PDBの表またはビューに問合せできません。

共通ユーザーは、他のPDBの権限を実行できません。必要なPDBに最初に切り替えて、そこから権限を実行する必要があります。異なるコンテナに切り替えるには、共通ユーザーにSET CONTAINER権限が必要です。SET CONTAINER権限は、共通に付与するか、ユーザーが切替えを試みるコンテナに付与する必要があります。また、共通ユーザーは、そのPDBのCREATE SESSION権限に応じて、現在の初期コンテナがこのユーザーが必要とするコンテナである新しいデータベース・セッションを開始できます。

共通に付与される権限が個々のPDBに構成されたセキュリティを妨げる場合があるので注意してください。たとえば、アプリケーションPDBのデータベース管理者がPDBのいずれのユーザーも特定のアプリケーション共通オブジェクトを変更できないようにするとします。PUBLICまたはオブジェクトの共通ユーザーもしくは共通ロールに共通に付与された権限(UPDATEなど)は、PDBのデータベース管理者の意図に反した動作をします。

共通およびローカルに付与される権限について

マルチテナント環境では、共通ユーザーとローカル・ユーザーの両方は、相互に権限を付与できます。

権限自体は、共通でもローカルでもありません。権限がどのように適用されるかは、権限が共通に付与されるか、ローカルに付与されるかによって異なります。

共通に付与される権限の場合:

  • 共通に付与される権限は、既存および将来のすべてのコンテナで使用できます。

  • 権限を共通に付与できるのは共通ユーザーのみで、権限受領者が共通の場合のみです。

  • 共通ユーザーは、他の共通ユーザーまたは共通ロールに権限を付与できます。

  • 権限付与者は、ルートに接続して、GRANT文のCONTAINER=ALLを指定する必要があります。

  • システム権限とオブジェクト権限は、どちらも共通に付与できます。(オブジェクト権限は、指定したオブジェクトに関してのみ実現化します。)

  • 共通ユーザーを指定されたコンテナに接続または切り替える場合、様々なアクティビティ(表の作成など)を実行するユーザーの機能は、共通に付与された権限および特定のコンテナでローカルに付与された権限によって制御されます。

  • PUBLICには権限を共通に付与しないでください。

ローカルに付与される権限

  • ローカルに付与された権限は、それが付与されたコンテナでのみ使用できます。権限がルートで付与されている場合は、ルートにのみ適用されます。

  • 共通ユーザーおよびローカル・ユーザーは、どちらも権限をローカルに付与できます。

  • 共通ユーザーおよびローカル・ユーザーは、他の共通ロールまたはローカル・ロールに権限を付与できます。

  • 権限付与者は、コンテナに接続して、GRANT文のCONTAINER=CURRENTを指定する必要があります。

  • ユーザーは、他のユーザーまたはロール(共通およびローカルの両方)あるいはPUBLICロールにローカルに権限を付与できます。

共通に付与されるシステム権限の使用方法

ユーザーは、システム権限が付与されているPDB内でのみシステム権限を実行できます。

たとえば、PDB B内の共通ユーザーAにシステム権限がローカルに付与されている場合、ユーザーAは、PDB Bに接続されている間のみ、その権限を実行できます。

システム権限は、ルートでのみ適用可能で、次の要件を満たしている場合は、既存および将来のすべてのPDBで適用できます。

  • システム権限付与者が共通ユーザーで、権限受領者が共通ユーザー、共通ロールまたはPUBLICロールです。事実上すべてのユーザーがシステム権限を使用できるようになるため、システム権限をPUBLICロールに共通に付与しないでください。

  • システム権限付与者は、共通に付与される権限に対してADMIN OPTIONを所有しています。

  • GRANT文には、CONTAINER=ALL句を含める必要があります。

次の例は、共通ユーザーc##hr_adminに権限を共通に付与する方法を示しています。 

CONNECT SYSTEM 
Enter password: password
Connected.

GRANT CREATE ANY TABLE TO c##hr_admin CONTAINER=ALL;
共通に付与されるオブジェクト権限の使用方法

共通オブジェクトのオブジェクト権限は、オブジェクト自体とそのオブジェクト上の関連するすべてのリンクに適用されます。

このリンクには、すべてのメタデータ・リンクおよびデータ・リンク(旧称オブジェクト・リンク)のほか、ルートやコンテナに属するすべてのPDB(将来のPDBを含む)内で特定の要件を満たしたときに関連付けが行われる拡張データ・リンクが含まれます。

この要件を次に示します。

  • オブジェクト権限付与者が共通ユーザーで、権限受領者が共通ユーザー、共通ロールまたはPUBLICロールです。

  • オブジェクト権限付与者は、権限に対して共通に付与されるGRANT OPTIONを所有しています

  • GRANT文には、CONTAINER=ALL句が含まれています。

次の例は、共通ユーザーc##hr_adminにオブジェクト権限を付与して、CDBルートまたは関連付けらているアクセス可能なPDBのいずれかでDBA_PDBSビューから選択できるようにする方法を示しています。 

CONNECT SYSTEM
Enter password: password
Connected.

GRANT SELECT ON DBA_OBJECTS TO c##hr_admin 
CONTAINER=ALL;
PDBへのアクセス権限の付与または取消し

マルチテナント環境では、PDBアクセスに対する権限の付与および取消を実行できます。

マルチテナント環境で権限を付与するには:

  • GRANTまたはREVOKE文にCONTAINER句を含めます。

CONTAINERをALLに設定すると、既存および将来のすべてのコンテナに権限が適用され、CURRENTに設定すると、ローカル・コンテナのみに権限が適用されます。CONTAINER句を省略すると、ローカル・コンテナに権限が適用されます。ルートからGRANT文を発行してCONTAINER句を省略すると、権限がローカルに適用されます。

例: マルチテナント環境での権限の付与

マルチテナント環境で権限を付与するには、GRANT文を使用できます。

例18-1は、既存および将来のすべてのコンテナでこの権限を使用できるように、共通ユーザーc##hr_adminにCREATE TABLE権限を共通に付与する方法を示しています。

例18-1 マルチテナント環境での権限の付与

CONNECT SYSTEM
Enter password: password
Connected.

GRANT CREATE TABLE TO c##hr_admin CONTAINER=ALL;
共通ユーザーによるCONTAINER_DATAオブジェクトの情報の表示

共通ユーザーは、ルート内のCONTAINER_DATAオブジェクトや特定のPDB内のデータに関する情報を表示できます。

親トピック: 共通およびローカルに付与される権限の管理

ルートに接続中のルート、CDBおよびPDBに関するデータの表示

共通ユーザーが問合せを実行した場合に、X$表ならびにV$、GV$およびCDB_*ビューの表示情報を制限できます。

この情報の制限は、他のPDBに関する機密情報を公開しない場合に役立ちます。この機能を有効にするために、Oracle Databaseでは、これらの表およびビューをコンテナ・データ・オブジェクトとして提供します。特定の表またはビューがコンテナ・データ・オブジェクトかどうかを確認するには、USER_|DBA_|ALL_VIEWS|TABLESディクショナリ・ビューのTABLE_NAME、VIEW_NAMEおよびCONTAINER_DATA 列を問い合せます。

デフォルト(ユーザー・レベル)およびオブジェクト固有のCONTAINER_DATA属性に関する情報を検索するには:

  1. SQL*PlusまたはSQL Developerで、rootとしてログインします。

  2. CDB_CONTAINER_DATAデータ・ディクショナリ・ビューを問い合せます。

    次に例を示します。

    COLUMN USERNAME FORMAT A15
COLUMN DEFAULT_ATTR FORMAT A7
COLUMN OWNER FORMAT A15
COLUMN OBJECT_NAME FORMAT A15
COLUMN ALL_CONTAINERS FORMAT A3
COLUMN CONTAINER_NAME FORMAT A10
COLUMN CON_ID FORMAT A6

SELECT USERNAME, DEFAULT_ATTR, OWNER, OBJECT_NAME, 
       ALL_CONTAINERS, CONTAINER_NAME, CON_ID 
FROM   CDB_CONTAINER_DATA 
ORDER BY OBJECT_NAME;

USERNAME        DEFAULT OWNER           OBJECT_NAME     ALL CONTAINERS CON_ID
--------------- ------- --------------- --------------- --- ---------- ------
C##HR_ADMIN     N       SYS             V$SESSION       N   CDB$ROOT        1
C##HR_ADMIN     N       SYS             V$SESSION       N   SALESPDB        1
C##HR_ADMIN     Y                                       N   HRPDB           1
C##HR_ADMIN     Y                                       N   CDB$ROOT        1
DBSNMP          Y                                       Y                   1
SYSTEM          Y                                       Y                   1
特定のPDBのデータを問い合せる共通ユーザーの有効化

特定のPDBに関するデータへのアクセスを共通ユーザーに許可するには、ユーザーのCONTAINER_DATA属性を調整します。

共通ユーザーによる特定のPDBのデータのアクセスを有効化するには:

  • ルートでALTER USER文を発行します。

例18-2 CONTAINER_DATA属性の設定

この例は、ALTER USER文を発行して、共通ユーザーc##hr_adminがV$SESSIONビュー(このユーザーがこのビューを問い合せることができるものと仮定します)のCDB$ROOT、SALES_PDBおよびHRPDBコンテナに関する情報を表示できるようにする方法を示しています。 

CONNECT SYSTEM
Enter password: password
Connected.

ALTER USER c##hr_admin
SET CONTAINER_DATA = (CDB$ROOT, SALESPDB, HRPDB) 
FOR V$SESSION CONTAINER=CURRENT;

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

  • SET CONTAINER_DATAは、コンテナのほか、ユーザーがアクセスできる対象に関するデータをリストします。

  • FOR V$SESSIONは、共通ユーザーc##hr_adminが問い合せるCONTAINER_DATA動的ビューを指定します。

  • ルートに接続する場合にCONTAINER=ALLがALTER USER文のデフォルトのため、CONTAINER = CURRENTを指定する必要がありますが、CONTAINER_DATA属性の変更はルートに制限する必要があります。

ユーザーc##hr_adminが自身がアクセス可能なすべてのCONTAINER_DATAオブジェクト内のCDB$ROOT、SALES_PDB、HRPDBコンテナに関連する情報を表示できるようにするには、FOR V$SESSIONを省略します。次に例を示します。 

ALTER USER c##hr_admin
SET CONTAINER_DATA = (CDB$ROOT, SALESPDB, HRPDB) 
CONTAINER=CURRENT;

共通ロールおよびローカル・ロールの管理

共通ロールはルートで作成されるロールであり、ローカル・ロールはPDBで作成されます。

親トピック: マルチテナント環境のセキュリティの管理

共通ロールおよびローカル・ロールの管理について

ローカル・ロールは、1つのPDBにのみ存在し、このPDB内でのみ使用できます。共通に付与される権限は持ちません。

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

  • 共通ユーザーは、共通ロールを作成して、他の共通ユーザーおよびローカル・ユーザーに付与できます。

  • ロール(ローカルまたは共通)は、ローカル・ユーザーまたはロールに対してローカルに付与できます。

  • 共通ロールをローカルに付与する場合、その共通ロールの権限は、ロールが付与されるコンテナ内にのみ適用されます。

  • ローカル・ユーザーは共通ロールを作成できませんが、共通ユーザーおよび他のローカル・ユーザーに共通ロールを付与できます。

共通ロールの使用方法

共通ロールは、ルートのほか、マルチテナント環境でそれらのロールが定義されているコンテナの各PDBで表示できます。

次の場合、権限は共通ロールに対して共通に付与されます。

  • 付与者は、共通ユーザーである。

  • 付与者は、付与される権限に対して、共通に付与されるADMIN OPTIONを所有している。

  • GRANT文には、CONTAINER=ALL句が含まれています。

共通ロールがローカルに付与された権限を含む場合、これらの権限は、共通ロールに付与されたPDB内にのみ適用されます。ローカル・ロールは共通に付与できません。

マルチテナント環境でPUBLICロールが機能するしくみ

OracleによってPUBLICロールに付与されるすべての権限はローカルに付与されます。

この機能により、各PDBで個別にPUBLICロールに付与された権限およびロールを必要に応じて取り消すことができます。権限をPUBLICロールに付与する必要がある場合は、ローカルに付与します。PUBLICには権限を共通に付与しないでください。

共通ロールの作成、変更または削除に必要な権限

共通ユーザーはローカル・ロールも作成できますが、作成されたPDBでのみそれらのロールを使用できます。

共通ロールの作成の規則

共通ロールを作成する場合は、特別な規則に従う必要があります。

この規則は次のとおりです。

共通ロールの作成

CREATE ROLE文を使用して、共通ロールを作成できます。

  1. 共通ロールを作成するCDBまたはアプリケーション・コンテナのルートに接続します。

    次に例を示します。 

    CONNECT SYSTEM
Enter password: password
Connected.
  2. CONTAINER句をALLに設定してCREATE ROLE文を実行します。

    次に例を示します。 

    CREATE ROLE c##sec_admin IDENTIFIED BY password CONTAINER=ALL;
ローカル・ロールの作成の規則

ローカル・ロールを作成するには、次の特別な規則に従う必要があります。

これらの規則は次のとおりです。

  • ロールを作成するPDBに接続する必要があり、CREATE ROLE権限がある必要があります。

  • ローカル・ロールに付ける名前をCOMMON_USER_PREFIXパラメータの値(デフォルトではC##)で始めることはできません。

  • CREATE ROLE文にCONTAINER=CURRENTを含め、ローカル・ロールとしてロールを指定できます。PDBに接続しており、この句を省略すると、CONTAINER=CURRENT句が含まれます。

  • 共通ロールとローカル・ロールの名前を同じにすることはできません。ただし、異なるPDBのローカル・ロールに同じ名前を使用できます。既存のロールの名前を検索するには、CDB_ROLESおよびDBA_ROLESデータ・ディクショナリ・ビューを問い合せます。

ローカル・ロールの作成

CREATE ROLE文を使用して、ロールを作成できます。

  1. ローカル・ロールを作成するPDBに接続します。

    次に例を示します。 

    CONNECT SYSTEM@hrpdb
Enter password: password
Connected.
  2. CONTAINER句をCURRENTに設定してCREATE ROLE文を実行します。

    次に例を示します。 

    CREATE ROLE sec_admin CONTAINER=CURRENT;
共通ユーザーとローカル・ユーザーに対するロールの付与と取消し

ロールの付与と取消は、共通ユーザーまたはローカル・ユーザーのアクセス範囲にのみ適用されます。

共通ユーザーは、他の共通ユーザーへの共通ロールの付与および取消しを行うことができます。ローカル・ユーザーは、共通ロールを共通ユーザーを含むPDBのユーザーに付与できますが、これは、PDB内のみで適用されます。

次の例は、共通ユーザーc##sec_adminへのすべてのコンテナで使用するAUDIT_ADMIN共通ロールの付与方法を示しています。 

CONNECT SYSTEM
Enter password: password
Connected.

GRANT AUDIT_ADMIN TO c##sec_admin CONTAINER=ALL;

同様に、次の例は、ローカル・ユーザーaud_adminによる共通ユーザーc##sec_adminへのhrpdb PDB内で使用するAUDIT_ADMIN共通ロールの付与方法を示しています。 

CONNECT aud_admin@hrpdb
Enter password: password
Connected.

GRANT AUDIT_ADMIN TO c##sec_admin CONTAINER=CURRENT;

この例は、ローカル・ユーザーaud_adminがPDBの別のユーザーからロールを取り消す方法を示しています。CONTAINER句を省略すると、CURRENTが暗黙のうちに入れられます。 

CONNECT aud_admin@hrpdb
Enter password: password
Connected.

REVOKE sec_admin FROM psmith CONTAINER=CURRENT;

PDBロックダウン・プロファイルを使用したPDBでの操作の制限

マルチテナント環境でPDBロックダウン・プロファイルを使用して、プラガブル・データベース(PDB)の一連のユーザー操作を制限できます。

この項では、次の項目について説明します。

親トピック: マルチテナント環境のセキュリティの管理

PDBロックダウン・プロファイルについて

PDBロックダウン・プロファイルは、操作グループを制御する名前付きの機能セットです。

場合によっては、操作を個別に有効または無効にできます。たとえば、PDBロックダウン・プロファイルに、ALTER SYSTEM文で使用する特定の句を無効にする設定を含めることができます。

PDBロックダウン・プロファイルは、ユーザーに対して定義されるリソース制限と同様、機能が提供する機能性へのユーザー・アクセスを制限します。名前が示すように、CDBでは、アプリケーション・コンテナ、PDBまたはアプリケーションPDBに対してPDBロックダウン・プロファイルを使用します。カスタム・プロファイルを作成して、サイトの要件に対応することができます。PDBプロファイルを使用すると、アプリケーションのカスタム・セキュリティ・ポリシーを定義できます。さらに、基本プロファイルと呼ばれる別のプロファイルに基づいて、ロックダウン・プロファイルを作成できます。このプロファイルは、基本プロファイルが変更されたときに動的に更新されるように構成するか、または基本プロファイルが更新されたときに静的になる(変更しない)ように構成できます。ロックダウン・プロファイルは、Oracle Cloudとオンプレミスの両方の環境用に設計されています。

IDがPDB間で共有される場合、昇格する権限が存在することがあります。ロックダウン・プロファイルを使用すると、この権限の昇格を防ぐことができます。IDは、次の状況で共有できます。

  • オペレーティング・システム・レベルでは、データベースがファイルやプロセスなどのオペレーティング・システム・リソースと対話するとき

  • ネットワーク・レベルでは、データベースが他のシステムと通信し、ネットワークIDが重要なとき

  • データベースの内部では、PDBが共通オブジェクトへのアクセスまたは作成を行うとき、またはデータベース・リンクなどの機能を使用してコンテナ境界を越えて通信するとき

共有IDを使用し、PDBロックダウン・プロファイルのメリットを受ける機能は、次のカテゴリに分かれます。

  • ネットワーク・アクセス機能。これはネットワークを使用してPDB外部と通信する操作です。たとえば、PL/SQLパッケージUTL_TCP、UTL_HTTP、UTL_MAIL、UTL_SNMP、UTL_INADDRおよびDBMS_DEBUG_JDWPは、この種の操作を実行します。現在、ネットワークIDを共有してこの種のアクセスを制御するためにACLが使用されています。

  • 共通ユーザーまたは共通オブジェクトのアクセス。これは、PDBのローカル・ユーザーが共通ユーザー・アカウントを介して通信したり、共通スキーマのオブジェクトにアクセスする操作です。この種の操作には、共通スキーマでのオブジェクトの追加または置換、共通オブジェクトへの権限の付与、共通ディレクトリ・オブジェクトへのアクセス、共通ユーザーへのINHERIT PRIVILEGESロールの付与、および共通ユーザーに対するユーザー・プロキシの操作が含まれます。

  • オペレーティング・システム・アクセス。たとえば、UTL_FILEまたはDBMS_FILE_TRANSFER PL/SQLパッケージへのアクセスを制限できます。

  • 接続。たとえば、共通ユーザーによるPDBへの接続を制限したり、SYSOPER管理権限を持つローカル・ユーザーによる制限モードでオープンしたPDBへの接続を制限できます。

PDBロックダウン・プロファイルを作成する一般的な手順では、最初にCREATE LOCKDOWN PROFILE文を使用してCDBルートまたはアプリケーション・ルートにプロファイルを作成した後、ALTER LOCKDOWN PROFILE文を使用してそれに制限を加えます。

PDBロックダウン・プロファイルを有効にするには、ALTER SYSTEM文を使用して、PDB_LOCKDOWNパラメータを設定できます。既存のPDBロックダウン・プロファイルに関する情報を確認するには、CDBまたはアプリケーション・ルートに接続してDBA_LOCKDOWN_PROFILESデータ・ディクショナリ・ビューを問い合せます。ローカル・ユーザーは、V$LOCKDOWN_RULES動的データ・ディクショナリ・ビューを問い合せて、PDBロックダウン・パラメータの内容を確認できます。

デフォルトのPDBロックダウン・プロファイル

デフォルトのPDBロックダウン・プロファイルは、PRIVATE_DBAAS、PUBLIC_DBAASおよびSAASです。

デフォルトでは、これらのプロファイルは空です。これらは、デプロイメント要件に応じて、構成するプレースホルダまたはテンプレートとして設計されています。

これらのプロファイルに関する詳細情報は次のとおりです。

  • PRIVATE_DBAASには、プライベート・クラウドDatabase-as-a-Service (DBaaS)のデプロイメントに適した制限が組み込まれています。これらの制限は次のとおりです。

    • 各PDBのデータベース管理者が同じである必要があります

    • 異なるユーザーによるデータベースへの接続が許可されます

    • 異なるアプリケーションが許可されます

    PRIVATE_DBAASでは、ユーザーによるPDBへの接続が許可されますが、Oracle Databaseの管理機能は使用できません。

  • SAASには、Software-as-a-Service(SaaS)デプロイメントに適した制限が組み込まれています。これらの制限は次のとおりです。

    • 各PDBのデータベース管理者が同じである必要があります

    • 異なるユーザーによるデータベースへの接続が許可されます

    • 同じアプリケーションを使用する必要があります

    SAASロックダウン・プロファイルにはPRIVATE_DBAASプロファイルよりも多くの制限があります。ユーザーは異なってもかまいませんが、アプリケーション・コードは同じです。ユーザーは、直接接続できずアプリケーションを介してのみ接続する必要があります。ユーザーは、すべての管理機能を実行する権限を与えられていません。

  • PUBLIC_DBAASには、パブリック・クラウドDatabase-as-a-Service (DBaaS)のデプロイメントに適した制限が組み込まれています。制限事項は次のとおりです。

    • 各PDBに異なるDBA

    • 異なるユーザー

    • 異なるアプリケーション

    PUBLIC_DBAASロックダウン・プロファイルは、最も制限が厳しいロックダウン・プロファイルです。

PDBロックダウン・プロファイルの作成

PDBロックダウン・プロファイルを作成するには、CREATE LOCKDOWN PROFILEシステム権限が必要です。

作成したロックダウン・プロファイルに制限を加えた後、有効にできます。
  1. CREATE LOCKDOWN PROFILEシステム権限を持つユーザーとしてCDBルートまたはアプリケーション・ルートに接続します。
    たとえば、次のようにCDBルートに接続します。
    CONNECT c##sec_admin
Enter password: password
  2. 次の構文を使用してCREATE LOCKDOWN PROFILE文を実行し、プロファイルを作成します。
    CREATE LOCKDOWN PROFILE profile_name
[FROM static_base_profile | INCLUDING dynamic_base_profile];

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

    • profile_nameはロックダウン・プロファイルを割り当てる名前です。DBA_LOCKDOWN_PROFILESデータ・ディクショナリ・ビューのPROFILE_NAMES列を問い合せて、既存の名前を検索できます。

    • FROM static_base_profileは、既存のプロファイルの値を使用して、新しいロックダウン・プロファイルを作成します。基本プロファイルへの以降の変更は、新しいプロファイルには影響しません。

    • INCLUDING dynamic_base_profileも既存の基本プロファイルの値を使用して新しいロックダウン・プロファイルを作成しますが、この新しいロックダウン・プロファイルは、基本プロファイルを構成するDISABLE STATEMENTルール、および基本プロファイルへの以降の変更を継承するという点が異なります。新規プロファイルに明示的に追加されたルールが基本プロファイル内のルールと競合する場合は、基本プロファイル内のルールが優先されます。たとえば、基本プロファイルのOPTION_VALUE句は、新しいプロファイルのOPTION_VALUE句より優先されます。

    次の2つのPDBロックダウン・プロファイル文では、継承がどのように機能するかを示しています。
    CREATE LOCKDOWN PROFILE hr_prof INCLUDING PRIVATE_DBAAS;
CREATE LOCKDOWN PROFILE hr_prof2 FROM hr_prof;

    最初の文では、hr_profはPRIVATE_DBAAS基本プロファイルへの変更内容を継承します。新しい文がPRIVATE_DBAASに対して有効になった後、hr_profに対して有効になります。2番目の文では、これとは対照的に、hr_profが変更された場合、hr_prof2はその基本プロファイルに依存しないため、変更されません。

  3. ALTER LOCKDOWN PROFILE文を実行して、プロファイルに制限を加えます。
    次に例を示します。
    ALTER LOCKDOWN PROFILE hr_prof DISABLE STATEMENT  = ('ALTER SYSTEM');
ALTER LOCKDOWN PROFILE hr_prof ENABLE STATEMENT = ('ALTER SYSTEM') clause = ('flush shared_pool');
ALTER LOCKDOWN PROFILE hr_prof DISABLE FEATURE = ('XDB_PROTOCOLS');

    前述の例は、次のとおりです。

    • DISABLE STATEMENT = ('ALTER SYSTEM')は、PDBに対するALTER SYSTEM文の使用をすべて無効にします。

    • ENABLE STATEMENT = ('ALTER SYSTEM') clause = ('flush shared_pool')は、ALTER SYSTEMのFLUSH_SHARED_POOL句の使用のみを有効にします。

    • DISABLE FEATURE = ('XDB_PROTOCOLS')は、このPDBによるXDBプロトコル(FTP、HTTP、HTTPS)の使用を禁止します

    PDBロックダウン・プロファイルを作成すると、ALTER SYSTEM SET PDB_LOCKDOWN SQL文を使用してプロファイルを有効にする準備が整います。
PDBロックダウン・プロファイルの有効化または無効化

PDBロックダウン・プロファイルを有効または無効にするには、PDB_LOCKDOWN初期化パラメータを使用します。

ALTER SYSTEM SET PDB_LOCKDOWNを使用して、次のコンテキストでロックダウン・プロファイルを有効にできます。

  • CDB (すべてのPDBに影響します)

  • アプリケーション・ルート(コンテナ内のすべてのアプリケーションPDBに影響します)

  • アプリケーションPDB

  • PDB

ノート:

プロファイルを有効にするためにインスタンスを再起動する必要はありません。ALTER SYSTEM SET PDB_LOCKDOWN文が完了すると、プロファイル・ルールは即時に有効になります。

CDBルートでPDB_LOCKDOWNを設定すると、PDB_LOCKDOWNがコンテナ・レベルで設定されていないかぎり、すべてのPDBおよびアプリケーション・ルートでこの設定が継承されます。ロックダウン・プロファイルを無効にするには、PDB_LOCKDOWNをnullに設定します。CDBルートでこのパラメータをnullに設定すると、ロックダウン・プロファイルは、PDB内でプロファイルを明示的に設定したもの以外のすべてのPDBに対して無効になります。

SYSDBA管理権限またはALTER SYSTEMシステム権限が共通に付与されたCDB共通ユーザーは、CDBルートで作成されたロックダウン・プロファイルにのみPDB_LOCKDOWNを設定できます。アプリケーション共通SYSDBA管理権限またはALTER SYSTEMシステム権限を持つアプリケーションの共通ユーザーは、アプリケーション・ルートで作成されたロックダウン・プロファイルにのみPDB_LOCKDOWNを設定できます。

  1. 共通に付与されるALTER SYSTEMまたは共通に付与されるSYSDBA権限を持つユーザーとして目的のコンテナにログインします。
    たとえば、すべてのPDBに対してプロファイルを有効にするには、CDBルートにログインします。
    CONNECT c##sec_admin
Enter password: password
  2. ALTER SYSTEM SET PDB_LOCKDOWN文を実行します。
    たとえば、次の文は、hr_profという名前のロックダウン・プロファイルをすべてのPDBに対して有効化します。
    ALTER SYSTEM SET PDB_LOCKDOWN = hr_prof;
    次の文は、PDB_LOCKDOWNパラメータをリセットします。
    ALTER SYSTEM RESET PDB_LOCKDOWN;
    前述の文のバリエーションには、SCOPE句が含まれます。
    ALTER SYSTEM RESET PDB_LOCKDOWN SCOPE = BOTH;
    次の文は、PDBレベルで明示的に設定されたものを除く、CDB内のすべてのロックダウン・プロファイルを無効化します。
    ALTER SYSTEM SET PDB_LOCKDOWN = '' SCOPE = BOTH;
    PDBロックダウン・プロファイルの名前を確認するには、DBA_LOCKDOWN_PROFILESデータ・ディクショナリ・ビューのPROFILE_NAME列を問い合せます。
  3. 必要に応じて、DBA_LOCKDOWN_PROFILESを問い合せて、プロファイルに関する情報を確認します。
    たとえば、次の問合せを実行します。
    SET LINESIZE 150
COL PROFILE_NAME FORMAT a20
COL RULE FORMAT a20
COL CLAUSE FORMAT a25

SELECT PROFILE_NAME, RULE, CLAUSE, STATUS FROM CDB_LOCKDOWN_PROFILES;

    出力例は次のように表示されます。

    PROFILE_NAME         RULE                 CLAUSE                    STATUS
-------------------- -------------------- ------------------------- -------
HR_PROF              XDB_PROTOCOLS                                  DISABLE
HR_PROF              ALTER SYSTEM                                   DISABLE
HR_PROF              ALTER SYSTEM         FLUSH SHARED_POOL         ENABLE
HR_PROF2                                                            EMPTY
PRIVATE_DBAAS                                                       EMPTY
PUBLIC_DBAAS                                                        EMPTY
SAAS                                                                EMPTY
PDBロックダウン・プロファイルの削除

PDBロックダウン・プロファイルを削除するには、DROP LOCKDOWN PROFILEシステム権限があり、CDBまたはアプリケーション・ルートにログインすることが必要です。

DBA_LOCKDOWN_PROFILESデータ・ディクショナリ・ビューを問い合せて、既存のPDBロックダウン・プロファイルの名前を検索できます。
  1. DROP LOCKDOWN PROFILEシステム権限を持つユーザーとしてCDBルートまたはアプリケーション・ルートに接続します。
    たとえば、次のようにCDBルートに接続します。
    CONNECT c##sec_admin
Enter password: password
  2. DROP LOCKDOWN_PROFILE文を実行します。
    次に例を示します。
    DROP LOCKDOWN PROFILE hr_prof2;
  3. 必要に応じて、DBA_LOCKDOWN_PROFILESを問い合せることでプロファイルの現在のリストを確認します。
    たとえば、次の問合せを実行します。
    SET LINESIZE 150
COL PROFILE_NAME FORMAT a20
COL RULE FORMAT a20
COL CLAUSE FORMAT a25

SELECT PROFILE_NAME, RULE, CLAUSE, STATUS FROM CDB_LOCKDOWN_PROFILES;

    出力例は次のように表示されます。

    PROFILE_NAME         RULE                 CLAUSE                    STATUS
-------------------- -------------------- ------------------------- -------
HR_PROF              XDB_PROTOCOLS                                  DISABLE
HR_PROF              ALTER SYSTEM                                   DISABLE
HR_PROF              ALTER SYSTEM         FLUSH SHARED_POOL         ENABLE
PRIVATE_DBAAS                                                       EMPTY
PUBLIC_DBAAS                                                        EMPTY
SAAS                                                                EMPTY

マルチテナント環境でのアプリケーション・コンテキストの使用

アプリケーション・コンテキストにはユーザーIDが格納されており、これに基づいてデータベースのデータにユーザーがアクセスできるかを否かを決定できます。

親トピック: マルチテナント環境のセキュリティの管理

アプリケーション・コンテキストとは

アプリケーション・コンテキストとは、Oracle Databaseがメモリーに格納する名前と値のペアです。

コンテキストには、ネームスペースと呼ばれるラベル(たとえば、従業員IDを取得するアプリケーション・コンテキストはempno_ctx)があります。このコンテキストにより、Oracle Databaseは認証中にデータベース・ユーザーと非データベース・ユーザーに関する情報を入手できます。

コンテキスト内は名前と値のペア(結合配列)です。名前は、値を保持するメモリー内の場所を指定します。アプリケーションはアプリケーション・コンテキストを使用して、ユーザーに関するセッション情報(ユーザーIDまたは他のユーザー固有の情報など)またはクライアントIDにアクセスして、その情報をデータベースに安全に引き渡すことができます。

この情報を使用して、ユーザーがアプリケーションを通じてデータにアクセスできるようにしたりアクセスできないようにできます。アプリケーション・コンテキストを使用して、データベース・ユーザーと非データベース・ユーザーの両方を認証できます。

関連トピック

親トピック: マルチテナント環境でのアプリケーション・コンテキストの使用

マルチテナント環境でのアプリケーション・コンテキスト

マルチテナント環境のどこでアプリケーションを作成するかによって、アプリケーション・コンテキストを作成する場所が決まります。

アプリケーション・ルートまたはCDBルートにアプリケーションがインストールされると、そのアプリケーションはアプリケーション・コンテナまたはシステム・コンテナおよび関連付けられたアプリケーションPDBからアクセスできるようになります。そのルートで共通アプリケーション・コンテキストを作成する必要があります。

アプリケーション・コンテナで使用する共通アプリケーション・コンテキストを作成する場合は、次の点に注意してください。

  • マルチテナント環境でアプリケーション・コンテキストを作成するには、CREATE CONTEXT SQL文でCONTAINER句を設定します。たとえば、アプリケーション・ルートで共通アプリケーション・コンテキストを作成するには、CONTAINERをALLに設定してCREATE CONTEXTを実行する必要があります。PDBでアプリケーション・コンテキストを作成するには、CONTAINERをCURRENTに設定します。

  • ローカル・アプリケーション・コンテキストと共通アプリケーション・コンテキストに同じ名前を使用することはできません。既存のアプリケーション・コンテキストの名前は、次の問合せを実行して検索できます。 

    SELECT OBJECT_NAME FROM DBA_OBJECTS WHERE OBJECT_TYPE ='CONTEXT';

  • 共通アプリケーション・コンテキストを管理するために作成するPL/SQLパッケージは、共通PL/SQLパッケージであることが必要です。つまり、それがアプリケーション・ルートまたはCDBルートに存在する必要があります。特定のPDBのアプリケーション・コンテキストを作成する場合、関連付けられたPL/SQLパッケージをそのPDBに格納する必要があります。

  • 共通アプリケーション・コンテキストのアプリケーション・コンテナまたはシステム・コンテナから共通セッション・アプリケーション・コンテキストの下に設定した名前と値のペアは、共通ユーザーが異なるコンテナにアクセスする場合、他のアプリケーション・コンテナまたはシステム・コンテナからアクセスできません。

  • アプリケーション・コンテナまたはシステム・コンテナから共通グローバル・アプリケーション・コンテキストの下に設定した名前と値のペアは、同じユーザー・セッションの同じコンテナ内の場合にかぎりアクセスできます。

  • アプリケーションは、アプリケーション・ルート、CDBルートまたはPDBのいずれに存在していても、アプリケーション・コンテキストの値を取得できます。

  • CDBまたはアプリケーション・コンテナへのPDBの接続操作中、共通アプリケーション・コンテキストの名前がPDBのローカル・アプリケーション・コンテキストの名前と競合する場合は、PDBを制限モードでオープンする必要があります。データベース管理者は、PDBを通常モードでオープンする前に、競合を修正する必要があります。

  • 切断操作中、共通アプリケーション・コンテキストはその共通セマンティクスを維持することで、後にそのPDBが同じ名前の共通アプリケーション・コンテキストがある別のCDBに接続する場合、引き続き共通オブジェクトのように動作します。PDBが同じ共通アプリケーション・コンテキストが存在しないアプリケーション・コンテナまたはシステム・コンテナに接続する場合、そのPDBはローカル・オブジェクトのように動作します。

アプリケーション・コンテキストがローカル・アプリケーション・コンテキストであるかアプリケーションの共通アプリケーション・コンテキストであるかを確認するには、DBA_CONTEXTまたはALL_CONTEXTデータ・ディクショナリ・ビューのSCOPE列を問い合せます。

関連トピック

親トピック: マルチテナント環境でのアプリケーション・コンテキストの使用

マルチテナント環境でのOracle Virtual Private Databaseの使用

Oracle Virtual Private Database (VPD)を使用すると、データにアクセスするユーザーをフィルタ処理できます。

この項では、次の項目について説明します。

親トピック: マルチテナント環境のセキュリティの管理

Oracle Virtual Private Database

Oracle Virtual Private Database(VPD)で、行および列レベルでデータベース・アクセスを制御するセキュリティ・ポリシーを作成します。

ノート:

Oracle Databaseリリース12cでは、VPDにかわってReal Application Security (RAS)が採用されました。アプリケーションで行レベルおよび列レベルのアクセス制御が必要な新規プロジェクトにはRASを使用することをお薦めします。

基本的には、Oracle Virtual Private Databaseのセキュリティ・ポリシーが適用された表、ビューまたはシノニムに対して発行されるSQL文に、動的なWHERE句が追加されます。

Oracle Virtual Private Databaseを使用すると、データベース表、ビューまたはシノニムに対するセキュリティを直接詳細なレベルまで規定できます。これらのデータベース・オブジェクトにセキュリティ・ポリシーを直接付加すると、ユーザーがデータにアクセスするたびにポリシーが自動的に適用されるため、セキュリティを回避できません。

ユーザーがOracle Virtual Private Databaseポリシーで保護されている表、ビューまたはシノニムに直接的または間接的にアクセスすると、Oracle DatabaseはユーザーのSQL文を動的に変更します。この変更は、セキュリティ・ポリシーを実装する関数によって戻されたWHERE条件(述語)に基づいて行われます。Oracle Databaseでは、関数内に記述された条件、または関数が戻す条件を使用して、動的かつユーザーに対して透過的に文が変更されます。Oracle Virtual Private Databaseポリシーは、SELECT、INSERT、UPDATE、INDEXおよびDELETE文に適用できます。

たとえば、ユーザーが次の問合せを実行するとします。 

SELECT * FROM OE.ORDERS;

Oracle Virtual Private Databaseポリシーにより、WHERE句の文が動的に追加されます。次に例を示します。 

SELECT * FROM OE.ORDERS 
 WHERE SALES_REP_ID = 159;

この例では、ユーザーは営業担当者159の受注のみを表示できます。

このユーザーのセッション情報(ユーザーのIDなど)に基づいてユーザーをフィルタ処理する場合は、WHERE句を作成してアプリケーション・コンテキストを使用できます。次に例を示します。 

SELECT * FROM OE.ORDERS 
 WHERE SALES_REP_ID = SYS_CONTEXT('USERENV','SESSION_USER');

ノート:

Oracle Virtual Private Databaseでは、DDL(TRUNCATE文やALTER TABLE文)のフィルタ処理はサポートされていません。

関連トピック

親トピック: マルチテナント環境でのOracle Virtual Private Databaseの使用

マルチテナント環境でのOracle Virtual Private Database

CDBの制限は、共有の状況依存ポリシーのほか、仮想プライベート・データベース・ポリシー関連のビューにも適用されます。マルチテナント環境全体に仮想プライベート・データベース・ポリシーを作成することはできません。

関連トピック

親トピック: マルチテナント環境でのOracle Virtual Private Databaseの使用

マルチテナント環境でのTransport Layer Securityの使用

Transport Layer Security (TLS)はアプリケーション・コンテナのマルチテナント環境で使用できます。

アプリケーション・コンテナのマルチテナント環境でTransport Layer Security (TLS)を使用する場合、各PDBで独自のウォレットと独自のTLS認証用の証明書を使用できることを確認する必要があります。
  • 各PDBに対して個別のsqlnet.oraファイルはないため、walletディレクトリのサブディレクトリにウォレットを置きます。サブディレクトリの名前は、ウォレットを使用するPDBのGUIDです。
    たとえば、sqlnet.oraのWALLET_LOCATIONパラメータが次のように設定されているとします。
    (SOURCE=(METHOD=FILE)(METHOD_DATA=
   (DIRECTORY=/home/oracle/wallet)))

    各PDBのウォレットを/home/oracle/walletディレクトリに置きます。既存のPDBおよびそのGUIDを確認するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。

    WALLET_LOCATIONパラメータが指定されていない場合、デフォルトのウォレット・パスのサブディレクトリにPDBウォレットを置く必要があります。サブディレクトリの名前はPDBのGUIDです。次に例を示します。 

    $ORACLE_BASE/admin/db_unique_name/wallet/PDB_GUID

    または、ORACLE_BASE環境変数が設定されていない場合は、Oracleホームを使用できます。 

    $ORACLE_HOME/admin/db_unique_name/wallet/PDB_GUID

    これらのデフォルトの場所は、LDAPの認証用にウォレットを特定するためにOracle Enterprise User Securityによって使用されるデフォルトに対応します。

関連トピック

親トピック: マルチテナント環境のセキュリティの管理

マルチテナント環境におけるOracle Data Redaction

マルチテナント環境では、Oracle Data Redactionポリシーは、現在のプラガブル・データベース(PDB)内のオブジェクトのみに適用されます。

データ・リダクション・ポリシーは、マルチテナント・コンテナ・データベース(CDB)には作成できません。これは、一般的にデータ・リダクション・ポリシーを作成するオブジェクトがPDBにあるためです。SYSDBA権限を持っている場合は、SHOW PDBSコマンドを実行して、CDB内のすべてのPDBをリストできます。

CDBルートと同様、アプリケーション・ルートにデータ・リダクション・ポリシーを作成することはできません。

親トピック: マルチテナント環境のセキュリティの管理

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

監査では、ユーザーがマルチテナント・コンテナ・データベース(CDB)で行う変更を追跡します。

この項では、次の項目について説明します。

親トピック: マルチテナント環境のセキュリティの管理

マルチテナント環境での監査について

マルチテナント環境では、統合監査を使用できます。

ポリシーのタイプに応じて、各PDBに監査設定を適用したり、CDBに監査設定を適用できます。マルチテナント環境では、ルートを含むPDBにそれぞれ独自の統合監査証跡があります。

詳細は、次の各項を参照してください。

  • CREATE AUDIT POLICYおよびAUDIT文で作成された統合監査ポリシー: ルートと個々のPDBの両方のポリシーを作成できます。

  • ファイングレイン監査ポリシー: ルートではなく、個々のPDBのポリシーのみを作成できます。

  • 監査証跡の削除: ルートと個々のPDBの両方に対して、削除操作を実行できます。

関連トピック

親トピック: マルチテナント環境での監査

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

マルチテナント環境で、CREATE AUDIT POLICY文を使用してロールを監査できます。

次の例は、マルチテナント環境で事前定義済の共通ロールDBAを監査する方法を示しています。

例18-3 マルチテナント環境でのDBAロールの監査

CREATE AUDIT POLICY role_dba_audit_pol 
 ROLES DBA
 CONTAINER = ALL;

AUDIT POLICY role_dba_audit_pol;

親トピック: マルチテナント環境での監査

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

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

親トピック: マルチテナント環境での監査

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

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

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

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

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

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

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

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

  • AUDIT DROP ANY TABLE BY SYSTEM BY ACCESS CONTAINER = CURRENT;

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

関連トピック

関連項目:

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

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

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

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

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になります。

  • オブジェクトの場合:

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

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

  • 権限の場合:

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

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

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

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

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

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

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

例18-4 ローカル統合監査ポリシー

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

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

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

例18-5 共通統合監査ポリシー

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

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

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

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

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

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;

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

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

ルートまたはアクションが発生した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

マルチテナント環境でのファイングレイン監査

マルチテナント環境におけるファイングレイン監査ポリシーには、次のような一般的なルールがあります。

  • ファイングレイン監査ポリシーは、SYSオブジェクトに対して作成できません。

  • CDBルートでファイングレイン監査ポリシーを作成する場合、すべてのPDBにポリシーを適用することはできません。ポリシーはCDBルート内のオブジェクトに適用されます。(つまり、CDBルートに対する共通のファイングレイン監査ポリシーは存在しません。)すべてのPDBで共通オブジェクトのアクセスを監査するようにファイングレイン監査ポリシーを作成する場合は、監査ポリシーを各PDBで明示的に作成し、PDBでアクセス可能にする共通オブジェクトに対してそのポリシーを有効化する必要があります。

  • PDBでファイングレイン監査ポリシーを作成する場合、ポリシーはPDB内のオブジェクトにのみ適用されます。

関連トピック

親トピック: マルチテナント環境での監査