日本語PDF

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

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

• 共通およびローカルに付与される権限の管理
  マルチテナント環境では、CDB全体またはアプリケーション・コンテナに対する共通の権限を付与したり、特定のPDBに対してローカルで権限を付与したりできます。
• 共通ロールおよびローカル・ロールの管理
  共通ロールはルートで作成されるロールであり、ローカル・ロールはPDBで作成されます。
• PDBロックダウン・プロファイルを使用したPDBでの操作の制限
  マルチテナント環境でPDBロックダウン・プロファイルを使用して、プラガブル・データベース(PDB)の一連のユーザー操作を制限できます。
• PDBのオペレーティング・システム・ユーザーの構成
  DBMS_CREDENTIAL.CREATE_CREDENTIALプロシージャで、ユーザー・アカウントを、プラガブル・データベース(PDB)のオペレーティング・システム・ユーザーになるように構成します。
• マルチテナント環境でのアプリケーション・コンテキストの使用
  アプリケーション・コンテキストにはユーザーIDが格納されており、これに基づいてデータベースのデータにユーザーがアクセスできるかを否かを決定できます。
• マルチテナント環境でのOracle Virtual Private Databaseの使用
  Oracle Virtual Private Database (VPD)を使用すると、データにアクセスするユーザーをフィルタ処理できます。
• マルチテナント環境でのTransport Layer Securityの使用
  Transport Layer Security (TLS)はアプリケーション・コンテナのマルチテナント環境で使用できます。
• マルチテナント環境におけるOracle Data Redaction
  マルチテナント環境では、Oracle Data Redactionポリシーは、現在のプラガブル・データベース(PDB)内のオブジェクトのみに適用されます。
• マルチテナント環境での監査の概要
  監査とは、構成済のデータベース・アクション(データベース・ユーザーと非データベース・ユーザーの両方からのアクション)を監視して記録することです。非データベース・ユーザーとは、CLIENT_IDENTIFIER属性を使用してデータベースで認識されるアプリケーション・ユーザーのことです。

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

マルチテナント環境では、CDB全体またはアプリケーション・コンテナに対する共通の権限を付与するか、または特定のPDBに対してローカルで権限を付与できます。

• Oracleマルチテナント・オプションが権限に影響を与えるしくみ
  マルチテナント環境では、共通ユーザーを含むすべてのユーザーは、現在のコンテナ内でのみ権限を実行できます。
• 共通およびローカルに付与される権限について
  マルチテナント環境では、共通ユーザーとローカル・ユーザーの両方は、相互に権限を付与できます。
• 共通に付与されるシステム権限の使用方法
  ユーザーは、システム権限が付与されているPDB内でのみシステム権限を実行できます。
• 共通に付与されるオブジェクト権限の使用方法
  共通オブジェクトのオブジェクト権限は、オブジェクト自体とそのオブジェクト上の関連するすべてのリンクに適用されます。
• PDBへのアクセス権限の付与または取消し
  マルチテナント環境では、PDBアクセスに対する権限の付与および取消を実行できます。
• 例: マルチテナント環境での権限の付与
  マルチテナント環境で権限を付与するには、GRANT文を使用できます。
• 共通ユーザーによるCONTAINER_DATAオブジェクトの情報の表示
  共通ユーザーは、ルート内のCONTAINER_DATAオブジェクトや特定のPDB内のデータに関する情報を表示できます。

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のデータを問い合せる共通ユーザーの有効化
  特定のPDBに関するデータへのアクセスを共通ユーザーに許可するには、ユーザーのCONTAINER_DATA属性を調整します。

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

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

X$表およびこれらのビューには、アプリケーション・ルートおよび関連付けられたアプリケーションPDBに関する情報(CDBルートに接続している場合は、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 A13
   COLUMN DEFAULT_ATTR FORMAT A7
   COLUMN OWNER FORMAT A11
   COLUMN OBJECT_NAME FORMAT A11
   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で作成されます。

• 共通ロールおよびローカル・ロールの管理について
  マルチテナント環境では、データベース・ロールをPDBに固有にすることも、システム・コンテナまたはアプリケーション・コンテナ全体で使用することもできます。
• 共通ロールの使用方法
  共通ロールは、ルートのほか、マルチテナント環境でそれらのロールが定義されているコンテナの各PDBで表示できます。
• マルチテナント環境でPUBLICロールが機能するしくみ
  OracleによってPUBLICロールに付与されるすべての権限はローカルに付与されます。
• 共通ロールの作成、変更または削除に必要な権限
  共通に付与されるCREATE ROLE、ALTER ROLEおよびDROP ROLE権限を持つ共通ユーザーのみが、共通ロールの作成、変更または削除ができます。
• 共通ロールの作成の規則
  共通ロールを作成する場合は、特別な規則に従う必要があります。
• 共通ロールの作成
  CREATE ROLE文を使用して、共通ロールを作成できます。
• ローカル・ロールの作成の規則
  ローカル・ロールを作成するには、特別な規則に従う必要があります。
• ローカル・ロールの作成
  CREATE ROLE文を使用して、ロールを作成できます。
• 共通ユーザーとローカル・ユーザーに対するロールの付与と取消し
  ロールの付与と取消しは、共通ユーザーまたはローカル・ユーザーのアクセス範囲にのみ適用されます。

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

マルチテナント環境では、データベース・ロールをPDBに固有にすることも、システム・コンテナまたはアプリケーション・コンテナ全体で使用することもできます。

共通ロールとは、IDと(オプションの)パスワードがコンテナのルートで作成され、ルートのほか、そのコンテナに属する既存および将来のすべてのPDBで認識されるロールです。

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

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

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

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

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

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

• 共通ロールをCDBルートまたはアプリケーション・ルートで作成する場合、CONTAINER = ALL句がデフォルトです。

共通ロールの使用方法

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

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

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

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

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

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

たとえば、CDB共通ユーザーc##hr_mgrに、DBAロールが共通付与されているとします。これは、ユーザーc##hr_mgrは、マルチテナント環境のルートおよび各PDBでDBAロールに関連付けられている権限を使用できることを意味します。一方、CDB共通ユーザーc##hr_mgrに、hr_pdb PDBに対するDBAロールがローカルで付与されているのみであれば、このユーザーは、hr_pdb PDBでのみDBAロールの権限を使用できます。

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

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

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

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

共通に付与されるCREATE ROLE、ALTER ROLEおよびDROP ROLE権限を持つ共通ユーザーのみが、共通ロールの作成、変更または削除ができます。

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

共通ロールの作成の規則

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

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

• 正しいルートにいることを確認します。共通ロールを作成するには、正しいルート(CDBルートまたはアプリケーション・ルート)にいる必要があります。PDBから共通ロールを作成することはできません。正しいルートにいることを確認するには、次のいずれかを実行します。

  • CDBルートにいることを確認するには、show_con_nameコマンドを発行します。CDB$ROOTと表示される必要があります。

  • アプリケーション・ルートにいることを確認するには、次の問合せにYESが戻されることを確認します。

    SELECT APPLICATION_ROOT FROM V$PDBS WHERE CON_ID=SYS_CONTEXT('USERENV', 'CON_ID');

  • 共通ロールに付ける名前がCOMMON_USER_PREFIXパラメータの値(デフォルトではC##)で始まるようにします。この要件はDBAやRESOURCEなど、Oracle Databaseによって提供される既存のロールの名前に適用されないことに注意してください。

• オプションで、CONTAINER句をALLに設定します。ルートにいるかぎりは、CONTAINER = ALL句を省略しても、ロールは、デフォルトでCDBルートまたはアプリケーション・ルートの共通ロールとして作成されます。

共通ロールの作成

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ロックダウン・プロファイル
  Oracle Databaseには、サイトの要件にあわせてカスタマイズが可能なデフォルトのPDBロックダウン・プロファイルのセットが用意されています。
• PDBロックダウン・プロファイルの作成
  PDBロックダウン・プロファイルを作成するには、CREATE LOCKDOWN PROFILEシステム権限が必要です。
• PDBロックダウン・プロファイルの有効化または無効化
  PDBロックダウン・プロファイルを有効または無効にするには、PDB_LOCKDOWN初期化パラメータを使用します。
• PDBロックダウン・プロファイルの削除
  PDBロックダウン・プロファイルを削除するには、DROP LOCKDOWN PROFILEシステム権限があり、CDBまたはアプリケーション・ルートにログインすることが必要です。

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ロックダウン・プロファイル

Oracle Databaseには、サイトの要件にあわせてカスタマイズが可能なデフォルトのPDBロックダウン・プロファイルのセットが用意されています。

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

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

• 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

PDBのオペレーティング・システム・ユーザーの構成

DBMS_CREDENTIAL.CREATE_CREDENTIALプロシージャは、ユーザー・アカウントを、プラガブル・データベース(PDB)のオペレーティング・システム・ユーザーになるように構成します。

• PDBのオペレーティング・システム・ユーザーの構成について
  oracleオペレーティング・システム・ユーザーのかわりに、特定のユーザー・アカウントをそのPDBのオペレーティング・システム・ユーザーに設定できます。
• PDBのオペレーティング・システム・ユーザーの構成
  DBMS_CREDENTIAL.CREATE_CREDENTIALプロシージャで、PDBのオペレーティング・システム・ユーザーを設定できます。
• PDBでのデフォルトの資格証明の設定
  指定したPDBのデータベース・プロパティDEFAULT_CREDENTIALを設定できます。

PDBのオペレーティング・システム・ユーザーの構成について

oracleオペレーティング・システム・ユーザーのかわりに、特定のユーザー・アカウントをそのPDBのオペレーティング・システム・ユーザーに設定できます。

特定のユーザーをPDBのオペレーティング・システム・ユーザーとして設定しない場合、PDBではデフォルトでoracleオペレーティング・システム・ユーザーが使用されます。ルートについては、オペレーティング・システムと対話する必要がある場合、oracleオペレーティング・システム・ユーザーを使用できます。

セキュリティ向上のため、マルチテナント環境の各PDBに対して一意のオペレーティング・システム・ユーザーを設定することをお薦めします。そうすることで、oracleオペレーティング・システム・ユーザーより権限の低いユーザーとしてオペレーティング・システムとの対話を行えるほか、PDBに属するデータを、他のPDBに接続しているユーザーのアクセスから保護することにも役立ちます。

PDBのオペレーティング・システム・ユーザーの構成

DBMS_CREDENTIAL.CREATE_CREDENTIALプロシージャで、PDBのオペレーティング・システム・ユーザーを設定できます。

1. DBMS_CREDENTIAL PL/SQLパッケージに対するEXECUTE権限およびALTER SYSTEMシステム権限を持つユーザーとして、データベース・インスタンスのルートにログインします。
   次に例を示します。

   sqlplus c##sec_admin
   Enter password: password

2. DBMS_CREDENTIAL.CREATE_CREDENTIALプロシージャを実行して、オペレーティング・システム・ユーザーのOracle資格証明を作成します。
   たとえば、os_adminという名前のユーザーの資格証明を設定するには、次のようにします。

   BEGIN 
    DBMS_CREDENTIAL.CREATE_CREDENTIAL (
       credential_name => 'PDB1_OS_USER',
       username        => 'os_admin',
       password        => 'password');
   END;
   /
   

3. オペレーティング・システム・ユーザーが使用されるPDBに接続します。
   次に例を示します。

   CONNECT cc##sec_admin@hrpdb
   Enter password: password
   

   使用可能なPDBを検索するには、show pdbsコマンドを実行します。現在のPDBを確認するには、show con_nameコマンドを実行します。

4. ステップ2で資格証明を設定したユーザーに対して、PDB_OS_CREDENTIAL初期化パラメータを設定します。
   次に例を示します。

   ALTER SYSTEM SET PDB_OS_CREDENTIAL = PDB1_OS_USER SCOPE = SPFILE;

   PDB_OS_CREDENTIALパラメータは静的なパラメータであるため、SCOPE = SPFILE句を使用して設定する必要があります。

5. データベース・インスタンスを再起動します。

   SHUTDOWN IMMEDIATE
   STARTUP

PDBでのデフォルトの資格証明の設定

指定したPDBのデータベース・プロパティDEFAULT_CREDENTIALを設定できます。

デフォルトの資格証明は、オブジェクトをオブジェクト・ストアからPDBにインポートする場合に便利です。impdpの使用時に資格証明名を指定しない場合、Oracle Data Pumpとオブジェクト・ストア・モジュールは、DEFAULT_CREDENTIALオブジェクトを使用してユーザー名とパスワードを取得できます。資格証明を指定しないでimpdpを実行する場合は、ダンプ・ファイル名の前にDEFAULT_CREDENTIAL:を付ける必要があります。

デフォルトの資格証明を設定するには:

1. 管理者権限でPDBにログインします。

2. ALTER DATABASE文を使用して、デフォルトの資格証明を設定します。

   たとえば、次の文を入力して、資格証明をSYSTEM.HR_CREDに設定します。

   ALTER DATABASE PROPERTY SET DEFAULT_CREDENTIAL = 'SYSTEM.HR_CRED';

例18-3 デフォルトの資格証明を使用したデータのPDBへのインポート

この例では、デフォルトの資格証明が存在することを前提としています。次のコマンドはオブジェクト・ストアからデータをインポートし、文字列DEFAULT_CREDENTIALを使用してURLを事前に設定します。

impdp hr@pdb1 table_exists_action=replace \
  dumpfile=DEFAULT_CREDENTIAL:https://example.com/ostore/obucket/myt.dmp

関連項目:

• 「データ・ポンプを使用したCDBへのデータの移動」

• データ・ポンプ・インポートについて学習するには、『Oracle Databaseユーティリティ』を参照

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

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

• アプリケーション・コンテキストとは
  アプリケーション・コンテキストとは、Oracle Databaseがメモリーに格納する名前と値のペアです。
• マルチテナント環境でのアプリケーション・コンテキスト
  マルチテナント環境のどこでアプリケーションを作成するかによって、アプリケーション・コンテキストを作成する場所が決まります。

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

アプリケーション・コンテキストとは、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 Virtual Private Database
  アプリケーション・ルートで仮想プライベート・データベース・ポリシーを作成して、関連付けられたすべてのアプリケーションPDBで使用できます。

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

アプリケーション・ルートで仮想プライベート・データベース・ポリシーを作成して、関連付けられたすべてのアプリケーションPDBで使用できます。

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

アプリケーション・コンテナについては、仮想プライベート・データベース・ポリシーを作成して、アプリケーション・ルートに属するすべてのPDBに共通ポリシーを適用することで、アプリケーション共通オブジェクトを保護できます。つまり、アプリケーション・ルートにアプリケーションをインストールすると、共通オブジェクトを保護するすべての共通仮想プライベート・データベース・ポリシーは、アプリケーション・コンテナのすべてのPDBに適用され、即座に実施されます。

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

• アプリケーション・ルートでは共通仮想プライベート・データベース・ポリシーおよびそれに関連するPL/SQLファンクションのみを作成し、それをアプリケーション共通オブジェクトに付加することができます。ファンクションがポリシーと同じ場所にない場合、実行時にエラーが発生します。

• 共通オブジェクトに適用される仮想プライベート・データベース・ポリシーは、アプリケーションPDBからアプリケーション共通オブジェクトにアクセスする場合、アプリケーション・コンテナに属するPDBで自動的に強制される共通ポリシーと見なされます。

• アプリケーション共通仮想プライベート・データベース・ポリシーは、アプリケーション共通オブジェクトのみを保護できます。

• アプリケーション・ルートのアプリケーション共通オブジェクトに適用され、すべてのアプリケーションPDBに適用される仮想プライベート・データベース・ポリシーは、共通仮想プライベート・データベース・ポリシーと見なされます。ローカル・データベース表に適用され、1つのPDBで実施されるポリシーは、ローカル仮想プライベート・データベース・ポリシーと見なされます。

  たとえば、ポリシーVPD_P1がアプリケーション・ルートのアプリケーション共通表T1に適用される場合は、共通ポリシーと見なされます。このポリシーは各アプリケーションPDBに強制されます。VPD_P1というポリシーがPDB1のT1というローカル表に適用される場合は、ローカル・ポリシーと見なされ、PDB1のみがその影響を受けます。VPD_P1というポリシーがアプリケーション・ルートのT1というローカル表に適用される場合も、アプリケーション・ルートのみが影響を受けるため、ローカル・ポリシーと見なされます。この概念は、仮想プライベート・データベース・ポリシーの有効化、無効化および削除などの他の操作にも適用されます。

• アプリケーション共通仮想プライベート・データベース・ポリシーはアプリケーション共通オブジェクトのみを保護し、ローカル仮想プライベート・データベース・ポリシーはローカル・オブジェクトのみを保護します。

• アプリケーション・コンテキストを使用している場合は、共通データベース・セッション・ベースのアプリケーション・コンテキストおよび共通グローバル・アプリケーション・コンテキスト・オブジェクトを共通仮想プライベート・データベース構成で使用するようにしてください。

• アプリケーション・コンテナの仮想プライベート・データベース・ポリシーは、アプリケーション・ルートに格納されます。PDBにはローカル・ポリシーのみが格納されます。PDBをアプリケーション・コンテナに接続する場合、共通ポリシーはローカル・ポリシーに変換されません。かわりに、Oracle Databaseがアプリケーション・ルートからそれらをロードし、ポリシーからローカルPDBの共通オブジェクトにアクセスがあると、ローカルPDBでそれらを強制します。

マルチテナント環境での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ディレクトリに置きます。既存のPDBおよびそのGUIDを確認するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。

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

  $ORACLE_BASE/admin/db_unique_name/PDB_GUID/wallet

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

  $ORACLE_HOME/admin/db_unique_name/PDB_GUID/wallet

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

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

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

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

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

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

監査とは、構成済のデータベース・アクション(データベース・ユーザーと非データベース・ユーザーの両方からのアクション)を監視して記録することです。非データベース・ユーザーとは、CLIENT_IDENTIFIER属性を使用してデータベースで認識されるアプリケーション・ユーザーのことです。

実行されたSQL文のタイプなどの個々のアクション、またはユーザー名、アプリケーション、時間などの様々なデータの組合せをベースとして使用できます。成功したアクティビティと失敗したアクティビティの両方の監査が可能で、特定のユーザーを監査対象に含めたり、除外したりできます。マルチテナント環境では、プラガブル・データベース(PDB)の個々のアクション、またはマルチテナント・コンテナ・データベース(CDB)全体の個々のアクションを監査できます。

監査はデフォルトで有効です。監査レコードは、同一の形式で統合監査証跡に書き込まれ、UNIFIED_AUDIT_TRAILビューから使用できます。

• マルチテナント環境での統合監査
  マルチテナント環境では統合監査を使用できます。
• 例: マルチテナント環境でのDBAロールの監査
  マルチテナント環境で、CREATE AUDIT POLICY文を使用してロールを監査できます。
• マルチテナント環境での統合監査ポリシーまたはAUDIT設定
  マルチテナント環境では、個々のPDBおよびルートに統合監査ポリシーを作成できます。
• マルチテナント環境でのファイングレイン監査
  ファイングレイン監査ポリシーは、CDBルート、アプリケーション・ルート、CDB PDBおよびアプリケーションPDBで作成できます。

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

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

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

マルチテナント環境の監査設定は、次の領域に影響を与えます。

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

• SYSLOGに書き込まれた監査レコード: UNIXプラットフォームでは、CDBルートでUNIFIED_AUDIT_COMMON_SYSTEMLOG初期化パラメータを設定して、特定の統合監査証跡列がSYSLOGに書き込まれるようにできます。WindowsとUNIXの両方で、UNIFIED_AUDIT_SYSTEMLOGパラメータをルートとPDBレベルの両方で設定できます。

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

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

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

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

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

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

CREATE AUDIT POLICY role_dba_audit_pol 
 ROLES DBA
 CONTAINER = ALL;

AUDIT POLICY role_dba_audit_pol;

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

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

• ローカル、CDB共通およびアプリケーション共通監査ポリシーについて
  監査ポリシーは、ローカル、CDB共通またはアプリケーション共通のいずれかにすることができます。
• マルチテナント環境での従来の監査
  従来型の監査(統合監査ではない)では、AUDITおよびNOAUDIT文で、マルチテナント環境の文と権限を監査できます。
• ローカル統合監査ポリシーまたは共通統合監査ポリシーの構成
  CONTAINER句の使用はマルチテナント環境限定で、CREATE AUDIT POLICY文で使用します。
• 例: ローカル統合監査ポリシー
  CREATE AUDIT POLICY文で、ルートまたはPDBにローカル統合監査ポリシーを作成できます。
• 例: CDB共通統合監査ポリシー
  CREATE AUDIT POLICY文で、CDB共通統合監査ポリシーを作成できます。
• 例: アプリケーション共通統合監査ポリシー
  アプリケーション・コンテナ共通統合監査ポリシーの場合、アクション・オプションとシステム権限オプションを監査して、共通オブジェクトおよびロールを参照できます。
• 監査証跡でのローカルまたは共通監査ポリシーまたは設定の表示方法
  ルートまたはアクションが発生したPDBから、統合監査ポリシー・ビューを問い合せることができます。

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

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

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

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

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

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

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

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

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

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

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

監査オプション・タイプ	CDBルート	アプリケーション・ルート	個々のPDB
共通監査文または監査ポリシー	CDB共通ユーザーに適用されます	CDB共通ユーザーに適用されます	CDB共通ユーザーに適用されます
アプリケーション・コンテナの共通監査文または監査ポリシー	該当なし	CDB共通ユーザーに適用され、現在のアプリケーション・コンテナに対してのみ有効です アプリケーション・コンテナ共通ユーザーに適用されます	CDB共通ユーザーに適用され、このアプリケーション・コンテナに対してのみ有効です アプリケーション共通ユーザーに適用されます
ローカル監査文または監査ポリシー	ローカル構成は許可されません	ローカル構成は許可されません	CDB共通ユーザーに適用されます アプリケーション共通ユーザーに適用されます

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

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

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

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

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

• AUDITまたはNOAUDIT文をマルチテナント環境全体に適用する場合は、CDBルートでCONTAINERをALLに設定する必要があります。アプリケーション・ルートの場合は、アプリケーション・ルート内に設定します。次に例を示します:

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

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

関連項目:

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

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

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

• オブジェクトの場合:

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

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

• 権限の場合:

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

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

  • CONTAINERをALLに設定し、ユーザー・リストを指定しない場合(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 POLICYとAUDIT POLICYの両方の文を含めるようにします。

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

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

  ALTER PLUGGABLE DATABASE APPLICATION application_name SYNC;

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

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

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

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

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

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-6に、共通ユーザーc##sec_adminによってルートから作成され、共通ユーザーc##hr_adminに適用されている共通統合監査ポリシーを示します。

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

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

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 

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

ファイングレイン監査ポリシーは、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ブロック内からに限定されます。