1. セキュリティ・ガイド
  2. ユーザー認証および認可の管理
  3. 権限とロール認可の構成

4 権限とロール認可の構成

権限とロールの認可によって、ユーザーが毎日のタスクを実行するために保持する権限が制御されます。

親トピック: ユーザー認証および認可の管理 

4.1 権限とロールについて

認可とは、データへのアクセス、処理または変更を特定のユーザーに許可するほか、ユーザーのアクセスやアクションに関する制限を作成するものです。

ユーザーに対して課せられる(または除外される)制限は、スキーマ、表全体または表の行などのオブジェクトに適用できます。

ユーザー権限とは、特定タイプのSQL文を実行する権利、別のユーザーのオブジェクトにアクセスする権利、PL/SQLパッケージを実行する権利などを指します。権限のタイプは、Oracle Databaseによって定義されています。

ロールは、ユーザー(通常は管理者)が権限や他のロールをグループ化するために作成します。ロールを使用すると、複数の権限またはロールをユーザーに簡単に付与できます。ユーザーおよび他のロールにロールを付与する以外に、コード・ベースのアクセス制御(CBAC)を使用して、ロールをプログラムに割り当てることができます。

権限は、次の一般的なカテゴリに分類されます。

  • 管理権限。管理権限は、バックアップおよびリカバリ操作の実行など、一般的に実行される管理タスク用に設計されています。Oracle Databaseには、透過的データ暗号化タスクを実行するためのSYSKM管理権限など、特定の管理タスクに応じて調整された管理権限が用意されています。

  • システム権限。システム権限を使用すると、ユーザーはスキーマ・オブジェクトに対してアクションを実行できます。システム権限の例には、表または表領域を作成および更新する機能があります。

  • ロール。ロールでは、複数の権限やロールがグループ化されるため、複数のユーザーに対して権限を同時に付与したり、取り消すことができます。ユーザーによるロールの使用を可能にするには、そのユーザーに対してロールを使用可能にしておく必要があります。SET ROLE PL/SQL文を使用して、ロールを埋め込むことができます。『Oracle Database SQL言語リファレンス』を参照してください。

  • オブジェクト権限。オブジェクトの各タイプには、オブジェクト権限が対応付けられています。オブジェクトは、表や索引などのスキーマ・オブジェクトです。オブジェクト権限のカテゴリは次のとおりです。

    • 表権限。これらの権限によって、DML (データ操作言語)またはDDL (データ定義言語)レベルでセキュリティが有効になります。DML操作は、表に対するALTER、INDEXおよびREFERENCES操作です。DDL操作は、表およびビューに対するDELETE、INSERT、SELECTおよびUPDATE操作です。

    • 表示権限。DMLオブジェクト権限は、表の場合と同様にビューに対しても適用できます。

    • プロシージャ権限。スタンドアロン・プロシージャ、ファンクションを含め、プロシージャにはEXECUTE権限を付与できます。

    • タイプ権限。システム権限は名前付きタイプ(オブジェクト・タイプ、VARRAYおよびネストした表)に付与できます。

  • 読取り専用ユーザーおよびセッション権限。ユーザーまたはセッションの読取り/書込み操作または読取り専用操作のどちらを有効にするかを構成できます。

関連トピック

親トピック: 権限とロール認可の構成

4.2 CDBにおける権限およびロールの付与

CDBにおける権限およびロールの付与の範囲は、ロールが使用されている場所によって異なります。

親トピック: 権限とロール認可の構成

4.2.1 CDBでの権限およびロール付与について

CDBのユーザー・アカウントは、ロールおよび権限を付与したり、付与されたりできます。ただし、CDB内のロールおよび権限は、ローカルに付与されたものか、共通に付与されたもののいずれかです。

ローカルに付与された権限またはロールは、それが付与されたPDBでのみ実行可能です。共通に付与された権限またはロールは、付与された対象のコンテナ(CDBまたはアプリケーション・コンテナ)の既存および将来のどのPDBにおいても実行可能です。

ユーザーおよびロールは、共通の場合もローカルの場合もあります。ただし、権限は、それ自体は共通でもローカルでもありません。ユーザーがCONTAINER=CURRENT句を使用してローカルに権限を付与した場合、権限受領者は現行コンテナ内でのみ実行可能な権限を持ちます。ユーザーがCDBルートまたはアプリケーション・ルートのいずれかに接続している場合、そしてこのユーザーがCONTAINER=ALL句を使用して共通に権限を付与した場合、権限受領者は現在のコンテナ内の既存または将来のPDBでこの権限を持ちます。

親トピック: CDBにおける権限およびロールの付与

4.2.2 CDBにおける権限およびロールの付与の原則

CDBでは、付与の行為は、ローカルか共通かに関係なく、すべてコンテナの内部で起こります。コンテナはCDBルート、アプリケーション・ルートまたはPDBになります。

現在のコンテナがCDBルートの場合、共通に付与することはCDBのすべてのコンテナに付与することを意味します。しかし、現在のコンテナがアプリケーション・ルートの場合、共通に付与することは現在のアプリケーション・コンテナのすべてのPDBに付与することを意味します。

付与の基本原則は、次のとおりです。

  • 共通およびローカルのどちらの現象も、ローカルに付与および受領できます。

  • 共通に付与または受領できるのは、共通の現象のみです。

ローカルのユーザー、ロールおよび権限は、特定のPDBに制限されます。したがって、ローカル・ユーザーは、共通のロールおよび権限を付与することはできず、ローカルのロールおよび権限は共通に付与されることはありません。

次の各項では、前述の原則の意味を説明します。

親トピック: CDBにおける権限およびロールの付与

4.2.3 CDBでローカルに付与される権限およびロール

ロールおよび権限は、受領者、付与者または付与されるロールがローカルか共通かに関係なく、ユーザーおよびロールにローカルに付与できます。

次の表では、ローカルに付与されたロールおよび権限の有効な可能性について説明します。

表4-1 ローカルな付与

現象 ローカルな付与が可能 ローカルな受領が可能 ローカルに付与されたロールまたは権限の受領が可能

共通ユーザー

はい

なし

はい

ローカル・ユーザー

はい

なし

はい

共通ロール

なし

はい(ただし、このロールでの権限は、権限がロールにローカルに付与されたか共通に付与されたかに関係なく、被付与者にとってロールが付与されたコンテナでのみ使用可能)

はい

ローカル・ロール

なし

はい(ただし、このロールでの権限は、被付与者にとってロールが付与され作成されたコンテナでのみ使用可能)

はい

権限

なし

はい

なし

親トピック: CDBにおける権限およびロールの付与

4.2.4 ロールまたは権限がローカルに付与される条件

ロールまたは権限をローカルに付与するには、CONTAINER=CURRENT句(デフォルト)を含むGRANT文を使用します。

具体的には、次の条件を満たした場合にのみ、ロールまたは権限がローカルに付与されます。

  • 付与者に、指定したロールまたは権限を付与するために必要な権限がある。

    システム権限およびロールの場合、付与者には付与するロールまたは権限に対するADMIN OPTIONが必要です。オブジェクト権限の場合、付与者には付与する権限に対するGRANT OPTIONが必要です。

  • 付与は1つのコンテナに対してのみ適用される。

    GRANT文には、権限またはロールがローカルに付与されることを示すCONTAINER=CURRENT句がデフォルトで含まれています。

例4-1 ローカルでの権限の付与

この例で、SYSTEMおよびc##hr_adminは両方とも共通ユーザーです。この例ではSYSTEM(管理者権限を持つ)としてhrpdbに接続し、employees表での読取り権限をローカルにc##hr_adminに付与します。この付与は、他のPDB内ではなくhrpdb内のc##hr_adminのみに適用されます。 

CONNECT SYSTEM@hrpdb
Enter password: password
Connected.

GRANT READ ON employees TO c##hr_admin CONTAINER=CURRENT;

親トピック: CDBにおける権限およびロールの付与

4.2.5 ローカルに付与されるロールおよび権限

ユーザーまたはロールは、ローカルに付与された権限である可能性があります(CONTAINER=CURRENT)。

たとえば、hrpdbのローカルまたは共通ユーザーに対してローカルに付与されたREAD ANY TABLE権限は、この PDB内のこのユーザーに対してのみ適用されます。

ユーザーまたはロールは、ローカルに付与されたロールである可能性があります(CONTAINER=CURRENT)。共通ロールが、ローカルに付与された権限を受領できます。たとえば、共通ロールc##dbaは、hrpdbでREAD ANY TABLE権限をローカルに付与される可能性があります。c##cdb共通ロールにローカルな権限がある場合、それらの権限はロールの付与先のコンテナでのみ適用されます。この例では、c##cdbaロールを持つ共通ユーザーは、権限がこのロールに対してhrpdbでローカルに付与されたものであるため、この権限をhrpdb以外のどのPDBでも実行する権利はありません。

親トピック: CDBにおける権限およびロールの付与

4.2.6 CDBで共通に付与されるロールおよび権限

権限および共通ロールは、共通に付与される可能性があります。

ユーザー・アカウントまたはロールに対してロールおよび権限を共通に付与できるのは、権限受領者と権限付与者がどちらも共通である場合のみです。ロールを共通に付与する場合は、そのロール自体が共通である必要があります。次の表では、共通の付与の可能性について説明します。

表4-2 共通の付与

現象 共通の付与が可能 共通の受領が可能 共通に付与されたロールおよび権限の受領が可能

共通ユーザー・アカウント

はい

なし

はい

ローカル・ユーザー・アカウント

いいえ

なし

いいえ

共通ロール

なし

はい脚注1

はい

ローカル・ロール

なし

いいえ

いいえ

権限

なし

はい

なし

脚注1

共通ロールに共通に付与された権限は、すべてのコンテナで被付与者が使用できます。さらに、共通ロールに対してローカルに付与された権限はどれも、その権限が共通ロールに付与されたコンテナでのみ、被付与者が使用できます。

親トピック: CDBにおける権限およびロールの付与

4.2.7 付与が共通になる条件

CONTAINER=ALL句は、権限またはロールが共通に付与されることを指定します。

ロールまたは権限は、次の条件を満たしたとき、共通に付与されます。

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

    付与を実行するユーザーは、CDB自体または特定のアプリケーション・コンテナのいずれかに共通します。

  • 被付与者は、共通ユーザーまたは共通ロールである。

    付与の受領者は、CDB自体または特定のアプリケーション・コンテナのいずれかに共通します。

  • 付与者に、指定したロールまたは権限を付与するために必要な権限がある。

    システム権限およびロールの場合、付与者には付与するロールまたは権限に対するADMIN OPTIONが必要です。オブジェクト権限の場合、付与者には付与する権限に対するGRANT OPTIONが必要です。

  • 付与は、付与が発生したコンテナ(CDBまたはアプリケーション・コンテナのいずれか)内のすべてのPDBに適用されます。

    GRANT文には、権限またはロールが共通に付与されることを指定するCONTAINER=ALL句が含まれます。

  • ロールが付与される場合、それは共通であり、オブジェクト権限が付与される場合は、権限が付与される対象のオブジェクトが共通であることが必要。

例4-2 共通での権限の付与

この例で、SYSTEMおよびc##hr_adminは両方とも共通ユーザーです。SYSTEMはCDBルートに接続して、CREATE ANY TABLE権限をc##hr_adminに共通に付与します。この場合、c##hr_adminはCDBのどのPDBにも表を作成できるようになります。 

CONNECT SYSTEM@root 
Enter password: password
Connected.

GRANT CREATE ANY TABLE TO c##hr_admin CONTAINER=ALL;

親トピック: CDBにおける権限およびロールの付与

4.2.8 共通に付与されるロールおよび権限

共通ユーザー・アカウントまたはロールには、権限を共通に付与できます(CONTAINER=ALL)。

CDBルートまたはアプリケーション・ルートのいずれかのコンテキスト内で、現在のコンテナ内の既存および将来のすべてのPDBにおいて、権限がこの共通ユーザー・アカウントまたはロールに付与されます。たとえば、SYSTEMがCDBルートに接続して、SELECT ANY TABLE権限をCDB共通ユーザー・アカウントc##dbaに共通に付与した場合、ユーザーc##dbaはCDBのすべてのPDBでこの権限を保持します。共通に付与されたロールまたは権限をローカルに取り消すことはできません。

ユーザーまたはロールは、共通に付与された共通ロールを受領する可能性があります。共通ロールが、ローカルに付与された権限を受領できます。したがって、共通ユーザーには共通ロールを付与でき、このロールにはローカルに付与された権限が含まれる可能性があります。

たとえば、共通ロールc##adminは、hrpdbに対してローカルなSELECT ANY TABLE権限を付与される可能性があります。共通ロールでローカルに付与された権限は、その権限が付与されたコンテナでのみ適用されます。したがって、c##adminロールを持つ共通ユーザーには、salespdbまたはhrpdb以外のどのPDBでも、hrpdbに含まれる権限を実行する権利はありません。

親トピック: CDBにおける権限およびロールの付与

4.2.9 CDBでのPUBLICへの付与

CDBでは、PUBLICは共通ロールです。PDBでは、PUBLICに対してローカルに付与された権限により、すべてのローカルおよび共通ユーザー・アカウントがこのPDBでのみこれらの権限を実行できるようになります。

Oracle提供のユーザーおよびロールに付与される権限およびロールはいずれも共通に付与されますが、PUBLICに付与されるシステム権限のみはローカルに付与されます。この例外は、Oracle Databaseにデフォルトで含まれている一部の付与(SYS.UTL_FILEに対するEXECUTEなど)を取り消すことができるように設けられています。

ローカル・ユーザー・アカウントhrがhrpdbに存在するとします。このユーザーは、hr.employeesでのSELECT権限を、PUBLICに対してローカルに付与します。hrpdbの共通およびローカル・ユーザーは、PUBLICに付与された権限を実行できます。salespdbまたはその他のPDBのユーザー・アカウントには、hrpdbでhr.employeesを問い合せる権限はありません。

PUBLICに対して共通に付与され権限により、すべてのローカル・ユーザーは、それぞれのPDBで付与された権限を実行でき、すべての共通ユーザーは、アクセス権限を持つPDBでこの権限を実行できます。ユーザーは、PUBLICに対しては、権限およびロールを共通に付与しないことをお薦めします。

親トピック: CDBにおける権限およびロールの付与

4.2.10 権限およびロールの付与: シナリオ

このシナリオでは、SYSTEMは共通ユーザーc##dbaを作成し、hrpdbのhrスキーマで表を問い合せるためにこのユーザー権限を付与しようとします。

このシナリオは、CONTAINER句がロールおよび権限の付与にどのような影響を与えるかを示しています。最初の列には、CDB$ROOTでの操作が示されています。2番目の列には、hrpdbでの操作が示されています。

表4-3 CDBのロールおよび権限の付与

t CDB$ROOTでの操作 hrpdbでの操作 説明

t1

 
SQL> CONNECT SYSTEM@root
Enter password: *******
Connected.

なし

共通ユーザーSYSTEMは、ルート・コンテナに接続します。

t2

 
SQL> CREATE USER c##dba 
IDENTIFIED BY password 
CONTAINER=ALL;

なし

SYSTEMは、共通ユーザーc##dbaを作成します。CONTAINER=ALL句により、ユーザーが共通ユーザーになります。

t3

 
SQL> GRANT CREATE SESSION 
  TO c##dba;

なし

SYSTEMは、CREATE SESSIONシステム権限をc##dbaに付与します。CONTAINER=ALL句がないため、この権限はローカルに付与され、したがって現行のコンテナであるルートに対してのみ適用されます。

t4

 
SQL> CREATE ROLE c##admin 
  CONTAINER=ALL;

なし

SYSTEMは、c##adminという共通ロールを作成します。CONTAINER=ALL句により、ロールは共通ロールになります。

t5

 
SQL> GRANT SELECT ANY TABLE 
  TO c##admin;
Grant succeeded.

なし

SYSTEMは、SELECT ANY TABLE権限をc##adminロールに付与します。CONTAINER=ALL句がないため、権限はルートに対してローカルになります。したがって、この共通ロールには、ルートでのみ実行可能な権限が含まれます。

t6

 
SQL> GRANT c##admin TO c##dba;
SQL> EXIT;

なし

SYSTEMは、c##adminロールをc##dbaに付与します。CONTAINER=ALL句がないため、ロールは、共通ロールであっても、現行のコンテナに対してのみ適用されます。c##dbaがPDBに接続すると、c##dbaにこのロールはありません。

t7

なし

 
SQL> CONNECT c##dba@hrpdb
Enter password: *******
ERROR: ORA-01045: user c##dba
lacks CREATE SESSION privilege;
logon denied

c##dbaは、t3での付与がルートに対してローカルであったため、hrpdbへの接続に失敗します。

t8

なし

 
SQL> CONNECT SYSTEM@hrpdb
Enter password: *******
Connected.

SYSTEMは、hrpdbに接続します。

t9

なし

 
SQL> GRANT CONNECT, RESOURCE TO c##dba;
Grant succeeded.
SQL> EXIT

SYSTEMは、CONNECTロールおよびRESOURCEロールを共通ユーザーc##dbaに付与します。CONTAINER=ALL句がないため、付与はhrpdbに対してローカルです。

t10

なし

 
SQL> CONNECT c##dba@hrpdb
Enter password: *******
Connected.

共通ユーザーc##dbaは、hrpdbに接続します。

t11

なし

 
SQL> SELECT COUNT(*)
FROM hr.employees;
select * from hr.employees
                 *
ERROR at line 1:
ORA-00942: table or view does
not exist

c##dbaはhrpdb内の表に対してSELECT権限がないため、hr.employeesの問合せからは、まだエラーが戻されます。t5でローカルに付与されたSELECT ANY TABLE権限は、ルートに限定されるため、hrpdbには適用されません。

t12

 
SQL> CONNECT SYSTEM@root
Enter password: *******
Connected.

なし

共通ユーザーSYSTEMは、ルート・コンテナに接続します。

t13

 
SQL> GRANT SELECT ANY TABLE
 TO c##admin CONTAINER=ALL;
Grant succeeded.

なし

SYSTEMは、SELECT ANY TABLE権限をc##adminロールに付与します。CONTAINER=ALLが存在するため、この権限は共通に付与されます。

t14

なし

 
SQL> SELECT COUNT(*) FROM 
  hr.employees;
select * from hr.employees
                 *
ERROR at line 1:
ORA-00942: table or view does
not exist

hr.employeesの問合せでは、まだエラーが戻されます。これは、t6でc##admin共通ロールが、ルートでのみc##dbaに付与されたためです。

t15

 
SQL> GRANT c##admin TO c##dba
  CONTAINER=ALL;
Grant succeeded.

なし

SYSTEMは、CONTAINER=ALLを指定して、c##adminという共通ロールをc##dbaに付与します。これでユーザーc##dbaは、ルートのみでなく、すべてのコンテナでこのロールを持つことになります。

t17

なし

 
SQL> SELECT COUNT(*)
  FROM hr.employees;

  COUNT(*)
----------
       107

問合せに成功します。

親トピック: CDBにおける権限およびロールの付与

4.3 権限付与の対象者

権限をユーザーに付与すると、そのユーザーはそれぞれの業務に必要な作業を実行できます。

なお、権限は、必要な作業を実行する上でその権限が必要なユーザーにのみ付与してください。必要でない権限まで付与すると、セキュリティを維持できなくなる可能性があります。たとえば、管理作業を実行しないユーザーには、SYSDBA管理権限またはSYSOPER権限を付与しないでください。

権限は、次の2つの方法でユーザーに付与できます。

  • 権限を明示的にユーザーに付与します。たとえば、employees表にレコードを挿入する権限を、ユーザーpsmithに明示的に付与できます。

  • 権限をロール(名前付きの権限グループ)に付与した上で、そのロールを1人以上のユーザーに付与します。たとえば、employees表からレコードを選択、挿入、更新および削除する権限を、clerkという名前のロールに付与し、このロールをユーザーpsmithやrobertに付与できます。

ロールを使用することで権限の管理が容易になり、改善されるため、通常は権限を個々のユーザーではなくロールに付与してください。

関連項目:

親トピック: 権限とロール認可の構成

4.4 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のデータベース管理者の意図に反した動作をします。

関連トピック

親トピック: 権限とロール認可の構成

4.5 管理権限の管理

一般的なデータベース操作と特定のデータベース操作の両方に管理権限を使用できます。

親トピック: 権限とロール認可の構成

4.5.1 管理権限について

Oracle Databaseではより適切な作業分担を実現するため、一般的に実施される各管理タスク用の管理権限が用意されています。

これらのタスクには、バックアップおよびリカバリ操作、Oracle Data GuardおよびTransparent Data Encryption (TDE)のための暗号化キーの管理などが含まれます。

ユーザーが持つ管理権限は、V$PWFILE_USERS動的ビューを問い合せるとわかります。このビューにはパスワード・ファイル内のユーザーがリストされます。

以前のリリースでは、これらのタスクを実行するSYSDBA管理権限が必要でした。下位互換性をサポートするには、これらのタスクのSYSDBA権限を引き続き使用できますが、この項で説明する管理権限を使用することをお薦めします。

管理権限を付与されたユーザーを、スキーマ限定アカウントに変更できます。

管理権限の使用は強制的に監査されます。

関連トピック

親トピック: 管理権限の管理

4.5.2 ユーザーへの管理権限の付与

すべての強力な権限と同様に、管理権限は信頼できるユーザーのみに付与してください。

ただし、名前に非ASCII文字(HÜBERという名前に含まれるウムラウトなど)を使用しているユーザーには制限があります。こうしたユーザーに管理権限を付与することは可能ですが、Oracle Databaseインスタンスが停止した場合、名前に非ASCII文字を使用しているユーザーには、付与されている権限を使用した認証がサポートされません。データベース・インスタンスが稼働中であれば、この認証はサポートされます。

親トピック: 管理権限の管理

4.5.3 標準データベース操作のためのSYSDBAおよびSYSOPER権限

SYSDBAおよびSYSOPER管理権限を使用すると、標準データベース操作を実行できます。

これらのデータベース操作には、データベースの起動および停止、サーバー・パラメータ・ファイル(SPFILE)の作成またはデータベース・アーカイブ・ログの変更などのタスクがあります。SYSDBAおよびSYSOPER管理権限をアプリケーション共通ユーザーに付与できます(CDB共通ユーザーには付与できません)。

デフォルトでは、SYSDBAおよびSYSOPERの基礎となるスキーマはディクショナリ保護されています。この保護により、他のユーザーはこれらのスキーマに対してシステム権限(ANY権限を含む)を使用することができなくなります。また、これらのスキーマにオブジェクトを作成することはできません。

ローカル(PDB)レベル、CDBルート、またはアプリケーション・ルートの管理権限がユーザーに付与されているかどうかを確認するには、V$PWFILE_USERS動的ビューのSCOPE列を問い合せます。

認証なしで作成されたユーザーにSYSDBAおよびSYSOPER管理権限を付与できます。

親トピック: 管理権限の管理

4.5.4 SYSDBAとしてのログイン時のoracleユーザーに対するパスワード入力の強制

ユーザーがSYSDBA管理権限を使用してOracleデータベースにログインするときに、oracleユーザーにパスワードの入力を強制できます。

  1. $ORACLE_HOME/network/admin/sqlnet.oraファイルを編集します。
  2. SQLNET.AUTHENTICATION_SERVICESパラメータを次のように設定します。
    sqlnet.authentication_services=none

    SQLNET.AUTHENTICATION_SERVICESは、設定されていない場合は、デフォルトでALLに設定されます。

親トピック: 管理権限の管理

4.5.5 バックアップおよびリカバリ操作のSYSBACKUP管理権限

Oracle Recovery Manager (RMAN)またはSQL*Plusを使用したバックアップおよびリカバリ操作を実行するには、SYSBACKUP管理権限を使用します。

デフォルトでは、SYSBACKUPの基礎となるスキーマはディクショナリ保護されています。この保護により、他のユーザーはこのスキーマに対してシステム権限(ANY権限を含む)を使用することができなくなります。また、このスキーマにオブジェクトを作成することはできません。

パスワードを使用してSYSBACKUPとしてデータベースに接続するには、そのパスワード・ファイルを作成する必要があります。

認証なしで作成されたユーザーにSYSBACKUP管理権限を付与できません。

この権限では、次の操作を実行できます。

  • STARTUP

  • SHUTDOWN

  • ALTER DATABASE

  • ALTER SYSTEM

  • ALTER SESSION

  • ALTER TABLESPACE

  • CREATE CONTROLFILE

  • CREATE ANY DIRECTORY

  • CREATE ANY TABLE

  • CREATE ANY CLUSTER

  • CREATE PFILE

  • CREATE RESTORE POINT(GUARANTEEDリストア・ポイントを含む)

  • CREATE SESSION

  • CREATE SPFILE

  • DROP DATABASE

  • DROP TABLESPACE

  • DROP RESTORE POINT(GUARANTEEDリストア・ポイントを含む)

  • FLASHBACK DATABASE

  • RESUMABLE

  • UNLIMITED TABLESPACE

  • SELECT ANY DICTIONARY

  • SELECT ANY TRANSACTION

  • SELECT

    • X$表(つまり、固定表)

    • V$およびGV$ビュー(つまり、動的パフォーマンス・ビュー)

    • APPQOSSYS.WLM_CLASSIFIER_PLAN

    • SYSTEM.LOGSTDBY$PARAMETERS

  • DELETE/INSERT

    • SYS.APPLY$_SOURCE_SCHEMA

    • SYSTEM.LOGSTDBY$PARAMETERS

  • EXECUTE

    • SYS.DBMS_BACKUP_RESTORE

    • SYS.DBMS_RCVMAN

    • SYS.DBMS_DATAPUMP

    • SYS.DBMS_IR

    • SYS.DBMS_PIPE

    • SYS.SYS_ERROR

    • SYS.DBMS_TTS

    • SYS.DBMS_TDB

    • SYS.DBMS_PLUGTS

    • SYS.DBMS_PLUGTSP

  • SELECT_CATALOG_ROLE

また、SYSBACKUP権限では、データベースをオープンしていない場合でもデータベースに接続できます。

関連トピック

親トピック: 管理権限の管理

4.5.6 Oracle Data Guard操作のSYSDG管理権限

SYSDG管理権限があるSYSDGユーザーとしてログインして、Data Guard操作を実行できます。

デフォルトでは、SYSDGの基礎となるスキーマはディクショナリ保護されています。この保護により、他のユーザーはこのスキーマに対してシステム権限(ANY権限を含む)を使用することができなくなります。また、このスキーマにオブジェクトを作成することはできません。

Data Guard BrokerまたはDGMGRLコマンドライン・インタフェースでこの権限を使用できます。パスワードを使用してSYSDGとしてデータベースに接続するには、そのパスワード・ファイルを作成する必要があります。

認証なしで作成されたユーザーにSYSYSDG管理権限を付与できません。

SYSDG権限では、次の操作を実行できます。

  • STARTUP

  • SHUTDOWN

  • ALTER DATABASE

  • ALTER SESSION

  • ALTER SYSTEM

  • CREATE RESTORE POINT(GUARANTEEDリストア・ポイントを含む)

  • CREATE SESSION

  • DROP RESTORE POINT(GUARANTEEDリストア・ポイントを含む)

  • FLASHBACK DATABASE

  • SELECT ANY DICTIONARY

  • SELECT

    • X$表(つまり、固定表)

    • V$およびGV$ビュー(つまり、動的パフォーマンス・ビュー)

    • APPQOSSYS.WLM_CLASSIFIER_PLAN

  • DELETE

    • APPQOSSYS.WLM_CLASSIFIER_PLAN

  • EXECUTE

    • SYS.DBMS_DRS

また、SYSDG権限では、データベースをオープンしていない場合でもデータベースに接続できます。

関連トピック

親トピック: 管理権限の管理

4.5.7 透過的データ暗号化のSYSKM管理権限

SYSKM管理権限により、SYSKMユーザーは、透過的データ暗号化(TDE)のウォレット操作を管理できます。

デフォルトでは、SYSKMの基礎となるスキーマはディクショナリ保護されています。この保護により、他のユーザーはこのスキーマに対してシステム権限(ANY権限を含む)を使用することができなくなります。また、このスキーマにオブジェクトを作成することはできません

パスワードを使用してSYSKMとしてデータベースに接続するには、そのパスワード・ファイルを作成する必要があります。

認証なしで作成されたユーザーにSYSKM管理権限を付与できません。

SYSKM管理権限では、次の操作を実行できます。

  • ADMINISTER KEY MANAGEMENT

  • CREATE SESSION

  • SELECT(データベースをオープンしている場合のみ)

    • SYS.V$ENCRYPTED_TABLESPACES

    • SYS.V$ENCRYPTION_WALLET

    • SYS.V$WALLET

    • SYS.V$ENCRYPTION_KEYS

    • SYS.V$CLIENT_SECRETS

    • SYS.DBA_ENCRYPTION_KEY_USAGE

また、SYSKM権限では、データベースをオープンしていない場合でもデータベースに接続できます。

関連トピック

親トピック: 管理権限の管理

4.5.8 Oracle Real Application ClustersのSYSRAC管理権限

SYSRAC管理権限はOracle Real Application Clusters (Oracle RAC)のClusterwareエージェントによって使用されます。

デフォルトでは、SYSRACの基礎となるスキーマはディクショナリ保護されています。この保護により、他のユーザーはこのスキーマに対してシステム権限(ANY権限を含む)を使用することができなくなります。また、このスキーマにオブジェクトを作成することはできません。

SYSRAC管理権限は、日常的なOracle RAC操作の実行に必要な最小限の権限のみを提供します。たとえば、この権限はSRVCTLなどのOracle RACユーティリティに使用します。

認証なしで作成されたユーザーにSYSRAC管理権限を付与できません。

SYSRAC管理権限では、次の操作を実行できます。

  • STARTUP

  • SHUTDOWN

  • ALTER DATABASE MOUNT

  • ALTER DATABASE OPEN

  • ALTER DATABASE OPEN READ ONLY

  • ALTER DATABASE CLOSE NORMAL

  • ALTER DATABASE DISMOUNT

  • ALTER SESSION SET EVENTS

  • ALTER SESSION SET _NOTIFY_CRS

  • ALTER SESSION SET CONTAINER

  • ALTER SYSTEM REGISTER

  • ALTER SYSTEM SET local_listener|remote_listener|listener_networks

これらの権限に加えて、SYSRACユーザーは次のビューにアクセスできます。

  • V$PARAMETER

  • V$DATABASE

  • V$PDBS

  • CDB_SERVICE$

  • DBA_SERVICES

  • V$ACTIVE_SERVICES

  • V$SERVICES

SYSRACユーザーには、次のPL/SQLパッケージのEXECUTE権限が付与されます。

  • DBMS_DRS

  • DBMS_SERVICE

  • DBMS_SERVICE_PRVT

  • DBMS_SESSION

  • DBMS_HA_ALERTS_PRVT

  • メッセージのデキューSYS.SYS$SERVICE_METRICS

関連トピック

親トピック: 管理権限の管理

4.6 システム権限の管理

スキーマ・オブジェクトに対するアクションを実行するには、適切なシステム権限が付与されている必要があります。

親トピック: 権限とロール認可の構成

4.6.1 システム権限について

システム権限とは、スキーマ・オブジェクトに対して1つまたは複数の操作を実行する権限です。

たとえば、表領域を作成する権限や、データベース内の任意の表から行を削除する権限などがシステム権限です。

システム権限には様々な種類があります。各システム権限によって、ユーザーは特定のデータベース操作、またはあるクラスのデータベース操作を実行できます。システム権限は非常に強力な権限であることに注意してください。システム権限は、必要な場合のみ、データベースのロールと信頼できるユーザーに付与してください。ユーザーに付与されたシステム権限を検索するには、DBA_SYS_PRIVSデータ・ディクショナリ・ビューを問い合せます。

システム権限を特定のスキーマに制限する場合は、スキーマ権限としてそれを付与します。スキーマ権限を使用すると、スキーマ内のすべてのオブジェクトに対して権限付与を実行することなく、スキーマに対して特定のシステム権限を付与できます。

SELECT ANY TABLEなどのシステム権限は、DICTIONARY PROTECTEDとマークされたスキーマが所有しているSYSオブジェクトやその他のオブジェクトでは機能しません。

関連トピック

親トピック: システム権限の管理

4.6.2 システム権限を付与したり、取り消すことができるユーザー

他のユーザーにシステム権限を付与したり、他のユーザーのシステム権限を取り消すことができるのは、次の2つのタイプのユーザーのみです。

これらのユーザーは次のとおりです。

  • ADMIN OPTIONによって特定のシステム権限を付与されているユーザー

  • GRANT ANY PRIVILEGEシステム権限を付与されているユーザー

そのため、これらの権限は信頼できるユーザーにのみ付与してください。

親トピック: システム権限の管理

4.6.3 システム権限を制限することが重要な理由

システム権限はかなり強力であるため、信頼できるユーザーのみに権限を付与してください。さらに、データ・ディクショナリおよびSYSスキーマ・オブジェクトを保護する必要があります。

親トピック: システム権限の管理

4.6.3.1 システム権限の制限の重要性について

システム権限は非常に強力であるため、データベースは、通常のユーザー(管理者以外)がANYシステム権限を行使できないようにデフォルトで構成されています。

たとえば、ユーザーは、データ・ディクショナリに対してUPDATE ANY TABLEなどのANYシステム権限を行使できなくなっています。

4.6.3.2 SYSスキーマのオブジェクトへのユーザー・アクセス

明示的なオブジェクト権限のあるユーザーまたは管理権限で接続しているユーザー(SYSDBA)は、SYSスキーマ内のオブジェクトにアクセスできます。

次の表に、SYSスキーマ内のオブジェクトへのアクセスが必要なユーザーに対して付与できるロールをリストします。

表4-4 SYSスキーマ・オブジェクトにアクセスできるロール

ロール 説明

SELECT_CATALOG_ROLE

このロールを付与されたユーザーには、データ・ディクショナリ・ビューに対するSELECT権限が与えられます。

EXECUTE_CATALOG_ROLE

このロールを付与されたユーザーには、データ・ディクショナリ内にあるパッケージとプロシージャに対するEXECUTE権限が与えられます。

さらにSELECT ANY DICTIONARYシステム権限を、SYSスキーマで作成された表にアクセスが必要なユーザーに付与できます。このシステム権限により、SYSスキーマのあらゆるオブジェクト(そのスキーマに作成された表を含む)への問合せアクセスが可能になります。このシステム権限は、これを必要とする各ユーザーへ個別に付与する必要があります。これはGRANT ALL PRIVILEGESには含まれていませんが、ロールを通じて付与できます。

ノート:

これらのロールおよびSELECT ANY DICTIONARYシステム権限は、悪用されるとシステムの整合性が損われる危険があるため、付与する際には十分な注意が必要です。

4.6.4 システム権限の付与と取消し

システム権限は、ユーザーとロールに対して付与したり、取り消すことができます。

システム権限をロールに付与すると、そのロールを使用してシステム権限を行使できます。たとえば、ロールを使用すると権限を選択的に使用できるようになります。ロールの保護に関する業務分離のガイドラインに従っていることを確認してください。

ユーザーやロールに対するシステム権限の付与と取消しには、次のいずれかの方法を使用します。

  • SQL文のGRANTおよびREVOKE

  • Oracle Enterprise Manager Cloud Control

関連トピック

親トピック: システム権限の管理

4.6.5 ANY権限とPUBLICロールについて

ANYキーワードを使用するシステム権限を使用すると、データベース内のオブジェクトのカテゴリ全体に対して権限を設定できます。

たとえば、CREATE ANY PROCEDUREシステム権限により、ユーザーはデータベース内のどこにでもプロシージャを作成可能になります。ANY権限を持つユーザーが作成したオブジェクトの動作は、そのオブジェクトが作成されたスキーマに限定されません。たとえば、ユーザーJSMITHにはCREATE ANY PROCEDURE権限があり、プロシージャをスキーマJONESに作成すると、そのプロシージャはJONESとして実行されることになります。ただし、JONESはJSMITHによって作成されたプロシージャがJONESとして機能していることに気付かない可能性があります。JONESにDBA権限が付与されている場合は、JSMITHがJONESとしてプロシージャを実行することで、セキュリティ違反が発生する可能性があります。

PUBLICロールは、データベース・ユーザー・アカウントが作成されるときすべてのアカウントに自動的に与えられる特別なロールです。デフォルトでは付与されている権限がありませんが、多数の付与があり、ほとんどがJavaオブジェクトに対する付与です。PUBLICロールは削除できません。また、ユーザー・アカウントは常にこのロールを前提とするため、このロールの手動の付与や取消しは意味がありません。PUBLICロールはすべてのデータベース・ユーザー・アカウントが前提とするため、DBA_ROLESおよびSESSION_ROLESデータ・ディクショナリ・ビューには表示されません。

PUBLICロールに権限を付与できますが、付与した権限はOracleデータベースのすべてのユーザーが利用できるようになることに注意してください。このため、PUBLICロールに権限を付与するとき、特にANY権限やシステム権限のように強力な権限の場合は注意してください。たとえば、JSMITHがCREATE PUBLIC SYNONYMシステム権限を持っている場合、JSMITHは他の誰もが使用するとわかっているインタフェースを再定義し、その後、JSMITHが作成したPUBLIC SYNONYMでこのインタフェースを指し示すことができます。ユーザーは正しいインタフェースではなくJSMITHのインタフェースにアクセスし、ユーザーのログイン資格証明が盗まれるなど、不正な行為が実行される可能性があります。

この種の権限は非常に強力であるため、不適切な個人に付与するとセキュリティ上のリスクが発生する可能性があります。ANYまたはPUBLICを使用した権限の付与には注意が必要です。他のすべての権限と同様に、これらの権限をユーザーに付与する場合は、「最低限の権限」を付与する原則に従ってください。

関連トピック

親トピック: システム権限の管理

4.7 スキーマ権限の管理

スキーマ権限により、スキーマに対して特定のシステム権限を付与できます。

親トピック: 権限とロール認可の構成

4.7.1 スキーマ権限の管理について

スキーマ権限がスキーマに付与されると、権限受領者は、権限付与が行われたスキーマ内のすべてのオブジェクトに対するシステム権限を保持します。

システム権限は、スキーマ内の現在と将来の両方のオブジェクトに適用されます。たとえば、HRスキーマで使用するために、CREATE ANY TABLEシステム権限をユーザーpsmithに付与するとします。ユーザーpsmithは、HRスキーマに表を作成でき、psmithに権限がない他のスキーマには作成できません。スキーマ権限は、ユーザーまたはロールに付与できます。スキーマ権限付与は、広範なシステム権限に対して使用できますが、全部ではありません。また、SYSスキーマではスキーマ権限を使用できません。この権限付与により、権限受領者に強力な権限が与えられるため、信頼できるユーザーにのみスキーマ権限を付与する必要があります。

ユーザー・スキーマ権限の付与には、次の利点があります。

  • システム権限ではなくスキーマ権限を付与すると、最小権限の原則を使用できます。システム権限の付与は、データベース内のどのスキーマのどのオブジェクトに対しても同じ権限が許可されるため、不必要に寛容になる可能性があるのに対して、スキーマ権限のみをユーザーまたはロールに付与すると、そのユーザーまたはロールにはタスクを達成するために必要な最小権限が付与されます。したがって、この手法によってデータベースの安全性が高まります。
  • このタイプの権限付与により、権限の付与がずっと簡単になります。システム権限またはオブジェクト権限をユーザーに個別に付与する必要がなく、管理者が権限をスキーマに付与して、スキーマ内のすべてのオブジェクトにユーザーがアクセスできるようすることが可能です。

スキーマ権限を付与または取り消すには、GRANT ANY SCHEMA PRIVILEGEまたはGRANT ANY PRIVILEGEシステム権限が必要です。

スキーマ権限付与に含めることができるANYシステム権限は、オブジェクトの作成、変更、実行、削除などの操作を対象とします。

スキーマ権限として付与できる使用可能なシステム権限のリストは、『Oracle Database SQL言語リファレンス』を参照してください。

スキーマ権限付与に関する情報を確認するには、次のデータ・ディクショナリ・ビューを問い合せます。

  • DBA_SCHEMA_PRIVS
  • ROLE_SCHEMA_PRIVS
  • USER_SCHEMA_PRIVS
  • SESSION_SCHEMA_PRIVS
  • V$ENABLEDSCHEMAPRIVS

関連トピック

親トピック: スキーマ権限の管理

4.7.2 スキーマ権限付与から除外される権限

多くの管理権限およびシステム権限は、スキーマ権限付与で使用できません。

次の管理権限は、スキーマ権限付与から除外されます。

  • SYSDBA
  • SYSOPER
  • SYSASM
  • SYSBACKUP
  • SYSDG
  • SYSKM

次の表に、スキーマ権限付与から除外されるシステム権限を示します。

表4-5 スキーマ権限から除外されるシステム権限

システム権限タイプ 権限

アドバイザ・フレームワーク
  • ADVISOR
  • ADMINISTER SQL TUNING SET

アプリケーション・コンテキスト
  • CREATE ANY CONTEXT
  • DROP ANY CONTEXT

アプリケーション・コンティニュイティ
  • KEEP DATE TIME
  • KEEP SYSGUID

データベース変更通知

  • CHANGE NOTIFICATION

データベース・リンク
  • CREATE DATABASE LINK
  • CREATEPUBLICDATABASELINK
  • DROPPUBLIC DATABASELINK

データベース・トリガー
  • ADMINISTER DATABASE TRIGGER

デバッグ
  • DEBUG CONNECT SESSION

ディクショナリ保護
  • SELECT ANY DICTIONARY
  • ANALYZE ANY DICTIONARY

ディレクトリ
  • CREATE ANY DIRECTORY
  • DROP ANY DIRECTORY
  • READ
  • WRITE

エディション
  • CREATE ANY EDITION
  • DROP ANY EDITION

エクスポートおよびインポート
  • EXPORT FULL DATABASE
  • IMPORT FULL DATABASE

フラッシュバック
  • FLASHBACK ARCHIVE ADMINISTER
  • SELECT ANY TRANSACTION

キー管理
  • ADMINISTER KEY MANAGEMENT

LogMiner
  • LOGMINING

計画管理
  • ADMINISTER SQL MANAGEMENT OBJECT

プラガブル・データベース
  • CREATE PLUGGABLE DATABASE
  • SET CONTAINER

プロファイル
  • CREATE PROFILE
  • ALTER PROFILE
  • DROP PROFILE

パブリック・シノニム
  • CREATE PUBLIC SYNONYM
  • DROP PUBLIC SYNONYM

ごみ箱
  • PURGE DBA_RECYCLEBIN

リソース管理
  • ADMINISTRATE RESOURCE MANAGER

再開可能領域割当て
  • RESUMABLE

ロール
  • CREATE ROLE
  • DROP ANY ROLE
  • GRANT ANY ROLE
  • ALTER ANY ROLE

ロールバック・セグメント
  • CREATE ROLLBACK SEGMENT
  • ALTER ROLLBACK SEGMENT
  • DROP ROLLBACK SEGMENT

セッション
  • CREATE SESSION
  • ALTER SESSION
  • RESTRICT SESSION

ストアド・アウトライン
  • CREATE ANY OUTLINE
  • ALTER ANY OUTLINE
  • DROP ANY OUTLINE

システム
  • ALTER DATABASE
  • ALTER SYSTEM
  • AUDIT SYSTEM
  • ALTER RESOURCE COST

表領域
  • CREATE TABLESPACE
  • ALTER TABLESPACE
  • MANAGE TABLESPACE
  • DROP TABLESPACE
  • UNLIMITED TABLESPACE

トランザクション
  • FORCE TRANSACTION
  • FORCE ANY TRANSACTION

ユーザー
  • CREATE USER
  • BECOME USER
  • ALTER USER
  • DROP USER

親トピック: スキーマ権限の管理

4.7.3 スキーマ権限の付与

GRANT文を使用すると、ユーザーまたはロールにスキーマ権限を付与できます。

  1. GRANT ANY SCHEMA PRIVILEGEまたはGRANT ANY PRIVILEGEシステム権限が付与されたユーザーとして、CDBルートまたはPDBにログインします。
  2. 付与できる使用可能なスキーマ権限を確認するには、『Oracle Database SQL言語リファレンス』を参照してください
  3. ユーザーまたはロールにスキーマ権限を付与します。
    たとえば、HRスキーマで使用するために、SELECT ANY TABLEシステム権限をユーザーpsmithに付与するとします。ユーザーpsmithは、HRスキーマに作成された既存および将来の表から選択できます。 
    GRANT SELECT ANY TABLE ON SCHEMA HR TO psmith;

    GRANT ANY SCHEMA PRIVILEGE WITH ADMIN OPTION権限がある場合は、さらに次の2つのタイプの権限付与を実行できます。

    • GRANT ANY SCHEMA PRIVILEGEを別のユーザーに付与します。
    • スキーマ権限WITH ADMIN OPTIONを付与し、ユーザーがスキーマ権限を別のユーザーに付与できるようにします。

親トピック: スキーマ権限の管理

4.7.4 スキーマ権限の取消し

REVOKE文を使用すると、ユーザーまたはロールからスキーマ権限を取り消すことができます。

  1. WITH ADMIN OPTIONとともにGRANT ANY SCHEMA PRIVILEGEシステム権限が付与されたユーザーとして、CDBルートまたはPDBにログインします。
  2. ユーザーまたはロールに付与されているスキーマ権限を確認するには、次のような問合せを実行します。
    たとえば:
    SELECT PRIVILEGE, SCHEMA FROM DBA_SCHEMA_PRIVS
WHERE GRANTEE = 'PSMITH';
    次のような出力が表示されます。
    
PRIVILEGE             SCHEMA
–-------------------- –-----------
SELECT ANY TABLE      HR
  3. ユーザーまたはロールからスキーマ権限を取り消します。
    たとえば、ユーザーpsmithからSELECT ANY TABLEスキーマ権限を取り消すには、次のようにします。 
    REVOKE SELECT ANY TABLE ON SCHEMA HR FROM psmith;

親トピック: スキーマ権限の管理

4.8 スキーマ・セキュリティ・ポリシーの管理

行レベル・セキュリティ、ファイングレイン監査およびOracle Data Redactionのスキーマ・セキュリティ・ポリシーを管理するには、ユーザーに適切なシステム権限を付与する必要があります。

親トピック: 権限とロール認可の構成

4.8.1 スキーマ・システム・セキュリティ・ポリシーの管理について

行レベル・セキュリティ、ファイングレイン監査およびOracle Data Redactionのセキュリティ・ポリシーには、特別なスキーマ関連のシステム権限が必要です。

ユーザーに付与する必要があるシステム権限およびそれに対応するPL/SQLパッケージは次のとおりです。

  • ADMINISTER ROW LEVEL SECURITY POLICYシステム権限: DBMS_RLS PL/SQLパッケージとともに使用
  • ADMINISTER FINE GRAINED AUDIT POLICYシステム権限: DBMS_FGA PL/SQLパッケージとともに使用
  • ADMINISTER REDACTION POLICYシステム権限: DBMS_REDACT PL/SQLパッケージとともに使用

セキュリティ・ポリシーに必要なその他の権限(任意のPL/SQLパッケージに対するEXECUTE権限など)に加えて、システム権限をユーザーに付与する必要があります。システム権限は、次のいずれかの方法で付与できます。

  • セキュリティ・ポリシーをデータベース全体でSYS以外のすべてのスキーマに適用する場合は、次の構文を使用します。
    GRANT system_privilege TO grantee;
  • セキュリティ・ポリシーを特定のスキーマに制限する場合は、次の構文を使用します。 
    GRANT system_privilege ON SCHEMA schema TO grantee;

親トピック: スキーマ・セキュリティ・ポリシーの管理

4.8.2 管理者へのスキーマ・セキュリティ・ポリシーの付与

GRANT文を使用すると、ユーザーまたはロールにスキーマ・システム権限を付与できます。

  1. WITH ADMIN OPTIONとともにGRANT ANY SCHEMA PRIVILEGEシステム権限が付与されたユーザーとして、CDBルートまたはPDBにログインします。
  2. セキュリティ・ポリシーを管理するために、PL/SQLパッケージに対するEXECUTE権限(およびその他の必要な権限)をユーザーに付与します。
    たとえば、行レベルのセキュリティ・ポリシーの作成を担当するユーザーの場合、次のようにします。 
    GRANT EXECUTE ON DBMS_RLS TO preston;
  3. スキーマ・システム権限をユーザーに付与します。
    たとえば、行レベルのセキュリティ・ポリシーをHRスキーマに制限するには、次のようにします。
    GRANT ADMINISTER ROW LEVEL SECURITY POLICY ON SCHEMA HR TO preston;

    ユーザーがデータベース内のSYS以外のスキーマでポリシーを作成できるようにするには、次のようにします。 

    GRANT ADMINISTER ROW LEVEL SECURITY POLICY TO preston;

親トピック: スキーマ・セキュリティ・ポリシーの管理

4.8.3 管理者からのセキュリティ・ポリシーの取消し

REVOKE文を使用すると、ユーザーまたはロールからスキーマ・システム権限を取り消すことができます。

  1. WITH ADMIN OPTIONとともにGRANT ANY SCHEMA PRIVILEGEシステム権限が付与されたユーザーとして、CDBルートまたはPDBにログインします。
  2. ユーザーまたはロールに付与されているシステム権限を確認するには、次のような問合せを実行します。
    たとえば:
    SELECT PRIVILEGE FROM DBA_SYS_PRIVS_ALL WHERE GRANTEE = 'PRESTON';
    次のような出力が表示されます。
    
PRIVILEGE 
–---------------------–--------------
ADMINISTER ROW LEVEL SECURITY POLICY
  3. ユーザーまたはロールからシステム権限を取り消します。
    たとえば:
    REVOKE ADMINISTER ROW LEVEL SECURITY POLICY ON SCHEMA HR FROM preston;

    または:

    REVOKE ADMINISTER ROW LEVEL SECURITY POLICY FROM preston;
  4. 関連するPL/SQLパッケージに対するEXECUTE権限など、必要に応じてその他の権限を取り消します。
    たとえば:
    REVOKE EXECUTE ON DBMS_RLS FROM preston;

親トピック: スキーマ・セキュリティ・ポリシーの管理

4.9 診断を有効にする権限の管理

SYSDBA管理権限またはENABLE_DIAGNOSTICSシステム権限を持つユーザーのみが診断を有効にできるようにすることができます。

制御を制限できる診断の種類には次のものがあります。ALTER SESSIONおよびALTER SYSTEM操作を介したデバッグ・イベント(イベント++、エラー番号)とデバッグ・アクション。
  • ユーザーがこのようなタイプの診断を実行する機能を制御するには、初期化ファイルでDIAGNOSTICS_CONTROL初期化パラメータを設定します。
    DIAGNOSTICS_CONTROLの値は次のとおりです。
    • ERROR: SYSDBAまたはENABLE DIAGNOSTICS権限を持たないユーザーが診断を有効にしようとすると、その試行は失敗し、ORA-01031: insufficient privilegesエラーが表示されます。
    • WARNING: SYSDBAまたはENABLE DIAGNOSTICS権限を持たないユーザーは診断を有効にできますが、アラート・ログに警告メッセージが書き込まれます。警告メッセージは次のようになります。 
      User 'USERNAME' has set the following debug-event(s) on the event-group 'session':

1357 trace name context forever, level 2

      このメッセージでは、ユーザーがALTER SESSION文を実行した場合、sessionキーワードが使用されます。ユーザーがALTER SYSTEM文を実行した場合、キーワードはsystemになります。

    • IGNORE: エラー・メッセージが表示されることなく、ユーザーは診断タスクを実行できます。これはデフォルト設定です。

親トピック: 権限とロール認可の構成

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

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

親トピック: 権限とロール認可の構成

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

共通ユーザーとローカル・ユーザーは両方とも、相互に権限を付与できます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

関連トピック

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

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

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

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

システム権限は、ルートでのみ適用可能で、次の要件を満たしている場合は、既存および将来のすべての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;

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

4.10.3 共通に付与されるオブジェクト権限の使用方法

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

このリンクには、すべてのメタデータ・リンクおよびデータ・リンク(旧称オブジェクト・リンク)のほか、ルートやコンテナに属するすべての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;

関連トピック

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

4.10.4 PDBへのアクセス権限の付与または取消し

PDBアクセスの権限を付与することや取り消すことができます。

PDBでの権限を付与するか取り消すには、GRANT文またはREVOKE文にCONTAINER句を含めます。

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

関連トピック

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

4.10.5 例: 共通ユーザーへの権限の付与

共通ユーザーに権限を付与するには、ルートでGRANT文を使用する必要があります。

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

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

CONNECT SYSTEM
Enter password: password
Connected.

GRANT CREATE TABLE TO c##hr_admin CONTAINER=ALL;

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

4.10.6 共通ユーザーによるCONTAINER_DATAオブジェクトの情報の表示

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

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

4.10.6.1 ルートに接続中のルート、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
4.10.6.2 特定のPDBのデータを問い合せる共通ユーザーの有効化

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

共通ユーザーが特定のPDBについてのデータにアクセスできるようにするには、次のようにします。

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

例4-4 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;

4.11 ユーザー・ロールの管理

ユーザー・ロールは、作成したり他のユーザーに割り当てることができる権限の名前付きコレクションです。

親トピック: 権限とロール認可の構成

4.11.1 ユーザー・ロールについて

DDLの使用を制限するなど、ユーザー・ロールは様々な目的で利用できます。

親トピック: ユーザー・ロールの管理

4.11.1.1 ユーザー・ロールの概要

ユーザー・ロールは、ユーザーまたは他のロールに一括で付与できる関連権限の名前付きグループです。

権限の管理および制御は、ロールを使用すると容易になります。

データベース内では、各ロール名を一意にする必要があり、すべてのユーザー名や他のすべてのロール名とは異なる名称にする必要があります。スキーマ・オブジェクトとは異なり、ロールはいずれのスキーマにも含まれません。したがって、ロールを作成するユーザーを、ロールに影響をおよぼすことなく削除できます。

4.11.1.2 ロールの機能

ロールとは、ユーザーに権限を素早く簡単に付与するために便利なものです。

Oracle Databaseで定義されているロールを使用することもできますが、必要な権限のみを含む独自のロールを作成すると、より継続的な制御が可能になります。Oracle Databaseで定義されているロールの権限は、Oracleによって変更または削除される場合があります。

ロールは、次の機能を備えています。

  • ロールには、システム権限またはオブジェクト権限を付与できます。

  • 任意のロールを任意のデータベース・ユーザーに付与できます。

  • ユーザーに付与した各ロールは、任意の時点で使用可能または使用禁止にできます。ユーザーのセキュリティ・ドメインには、そのユーザーに対して現在使用可能になっているすべてのロールの権限が含まれており、ユーザーに対して現在使用禁止になっているロールの権限は除外されています。権限を選択的に使用できるように、Oracle Databaseでは、データベース・アプリケーションとユーザーがロールを使用可能または使用禁止にできます。

  • 1つのロールを別のロールにも付与できます。ただし、ロールをそのロール自体に付与したり、循環的に付与することはできません。たとえば、role2があらかじめロールrole1に付与されている場合、ロールrole1をロールrole2に付与することはできません。

  • ロールがパスワード認証ロールまたはセキュア・アプリケーション・ロールでない場合は、ユーザーに間接的に付与できます。間接的に付与するロールとは、ユーザーにすでに付与されている別のロールを通じて同じユーザーに付与するロールのことです。たとえば、ユーザーpsmithにrole1ロールを付与するとします。その後、role2ロールとrole3ロールをrole1ロールに付与します。これで、role2とrole3の2つのロールは、role1に含まれることになります。つまり、psmithには、直接付与されたrole1に加え、role2ロールとrole3ロールが間接的に付与されたことになります。psmithに対して、直接付与されたロールrole1を使用可能にすると、間接的に付与されたロールrole2およびrole3も同様に使用可能になります。

  • 必要に応じて、直接付与されたロールをデフォルト・ロールにできます。直接付与されたロールに対してデフォルト・ロール・ステータスを使用可能または使用禁止にするには、ALTER USER文のDEFAULT ROLE句を使用します。DEFAULT ROLE句は、ユーザーに直接付与されたロールのみを示すようにしてください。ユーザーに直接付与されたロールを検索するには、DBA_ROLE_PRIVSデータ・ディクショナリ・ビューを問い合せます。このビューには、ユーザーに間接的に付与されたロールは含まれません。他のロールに付与されたロールを検索するには、ROLE_ROLE_PRIVSビューを問い合せます。

  • ロールがパスワード認証ロールまたはセキュア・アプリケーション・ロールの場合は、ユーザーに間接的に付与することも、デフォルト・ロールにすることもできません。このタイプのロールは、ユーザーに直接付与する必要があります。通常、パスワード認証ロールまたはセキュア・アプリケーション・ロールを使用可能にするには、SET ROLE文を使用します。

4.11.1.3 ロールの特性とそのメリット

権限管理に要する労力の削減など、ロールにはその管理を容易にする特別なプロパティがあります。

表4-6では、データベース内での権限管理をさらに容易にする、ロールの特性について説明します。

表4-6 ロールの特性とその説明

プロパティ 説明

権限管理に要する労力の削減

複数のユーザーに対して同一の権限セットを明示的に付与するかわりに、関連するユーザー・グループのための権限をまとめて1つのロールに付与しておき、そのグループの各メンバーにはそのロールを付与するだけですみます。

動的な権限管理

あるグループの権限を変更する必要がある場合、修正が必要なのは、そのロールの権限のみです。グループのロールを付与した全ユーザーのセキュリティ・ドメインには、そのロールに対して加えられる変更が自動的に反映されます。

権限の選択的な可用性

あるユーザーに付与したロールを、選択的に使用可能または使用禁止にできます。この機能によって、どのような状況でもユーザー権限を個々に制御できます。

アプリケーションによる認識

データ・ディクショナリにはどのロールが存在するかが記録されます。したがって、ユーザーが特定のユーザー名でアプリケーションを実行しようとしたときに、ディクショナリに問い合せて自動的に特定のロールを使用可能(または使用禁止)にするようにアプリケーションを設計できます。

アプリケーション固有のセキュリティ

ロールの使用はパスワードを使用して保護できます。正しいパスワードを入力するとロールが使用可能になるようなアプリケーションを作成できます。パスワードを知らないユーザーは、ロールを使用可能にできません。

データベース管理者は、データベース・アプリケーションのロールを頻繁に作成します。セキュア・アプリケーション・ロールに対して、アプリケーションを実行するために必要なすべての権限を付与する必要があります。それから保護アプリケーション・ロールを他のロールやユーザーに付与できます。1つのアプリケーションは複数の異なるロールを持つことができ、各ロールには異なる権限のセットが付与され、アプリケーション使用中のデータ・アクセスの可否が決定されます。

DBAはパスワード付きのロールを作成することで、そのロールに付与されている権限が無許可で使用されるのを防止できます。通常、アプリケーションは起動時に適切なロールが使用可能になるように設計されます。そのため、アプリケーション・ユーザーは、アプリケーション・ロールのパスワードを知る必要がありません。

4.11.1.4 ロールの通常の使用

通常は、権限を管理するためにロールを作成します。

理由は次のとおりです。

  • データベース・アプリケーションに対する権限の管理

  • ユーザー・グループに対する権限の管理

次の図は、ロールの2つの使用方法を示しています。

図4-1 ロールの一般的な使用方法

図4-1の説明が続きます
「図4-1 ロールの一般的な使用方法」の説明
4.11.1.5 アプリケーション・ロールの一般的な使用方法

アプリケーション・ロールを使用して、アプリケーションを使用する権限を制御できます。

アプリケーション・ロールには、特定のデータベース・アプリケーションを実行するために必要な権限をすべて付与する必要があります。次に、そのセキュア・アプリケーション・ロールを、他のロールや特定のユーザーに対して付与します。

1つのアプリケーションに対して複数の異なるロールを設定し、アプリケーション使用時のデータ・アクセスの量や範囲にあわせて異なる権限セットを各ロールに割り当てることができます。

4.11.1.6 ユーザー・ロールの一般的な使用方法

共通の権限付与要件があるデータベース・ユーザーのグループに対してユーザー・ロールを作成できます。

ユーザーの権限は、セキュア・アプリケーション・ロールと権限をユーザー・ロールに付与し、そのユーザー・ロールを適切なユーザーに付与することで管理できます。

4.11.1.7 ロールがユーザーの権限範囲に与える影響

各ロールと各ユーザーには、それぞれ独自のセキュリティ・ドメインがあります。

ロールのセキュリティ・ドメインには、ロール自体に付与されている権限と、そのロールに付与されたロールに対して付与されている権限が含まれます。

ユーザーのセキュリティ・ドメインには、対応するスキーマ内のすべてのスキーマ・オブジェクトに対する権限、ユーザーに付与された権限、そして現在使用可能なユーザーに付与されたロールの権限が含まれます。(ロールをあるユーザーに対して使用可能にすると同時に、他のユーザーに対して使用禁止にできます。)このドメインには、ロールPUBLICに付与された権限とロールも含まれます。PUBLICロールは、データベース内のすべてのユーザーを表します。

4.11.1.8 PL/SQLブロックでのロールの機能

PL/SQLブロック内でのロールの動作は、ブロックのタイプと定義者権限または実行者権限によって決まります。

親トピック: ユーザー・ロールについて

4.11.1.8.1 定義者権限を持つ名前付きブロックで使用されるロール

定義者権限で実行される名前付きPL/SQLブロックでは、すべてのロールは使用禁止になっています。

名前付きPL/SQLブロックには、ストアド・プロシージャやファンクション、トリガーがあります。

ロールは権限チェックに使用されず、定義者権限プロシージャ内ではロールを設定できません。

PL/SQLブロックが定義者権限で実行される場合、SESSION_ROLESデータ・ディクショナリ・ビューには現在使用可能なすべてのロールが表示されます。定義者権限で実行される名前付きPL/SQLブロックでSESSION_ROLESを問い合せると、その問合せは行を戻しません。

4.11.1.8.2 実行者権限を持つ名前付きブロックおよび無名PL/SQLブロックで使用されるロール

実行者権限で実行される名前付きPL/SQLブロックと無名PL/SQLブロックは、使用可能なロールを通じて付与された権限に基づいて実行されます。

現行ロールは、実行者権限PL/SQLブロック内での権限チェックに使用されます。動的SQLを使用して、セッション内にロールを設定できます。

4.11.1.9 ロールによるDDL使用の支援または制限

ユーザーがDDL文を正常に実行するには、その文に応じて1つ以上の権限が必要になります。

たとえば、表を作成するには、CREATE TABLEまたはCREATE ANY TABLEシステム権限が必要です。

別のユーザーに属する表のビューを作成するには、CREATE VIEWまたはCREATE ANY VIEWシステム権限のみでなく、その表に対するSELECT object権限またはSELECT ANY TABLEシステム権限も必要です。

Oracle Databaseでは、特定のDDL文での特定の権限の使用を制限することで、ロールを介して受け取った権限への依存性を回避します。次の規則は、DDL文に関する権限の制限を示しています。

  • DDL操作の実行をユーザーに許可するすべてのシステム権限およびオブジェクト権限は、ロールを介して受け取った場合でも使用可能。たとえば:

    • システム権限: CREATE TABLE、CREATE VIEWおよびCREATE PROCEDURE権限

    • オブジェクト権限: 表に対するALTERおよびINDEX権限

      表に対するREFERENCESオブジェクト権限は、ロールを介して付与されている場合、表の外部キー定義には使用できません。

  • DDL文を発行するために必要なDML操作をユーザーが実行できるようにするすべてのシステム権限とオブジェクト権限は、ロールを通じて受け取った場合には使用できません。CREATE VIEW文が使用されているとき、セキュリティ・ドメインにはロールが含まれません。たとえばユーザーはSELECT ANY TABLEシステム権限を付与されている場合、または表に対するSELECT object権限をロールを通じて付与されている場合、これらの権限のどちらを使用しても他のユーザーに属する表でビューは作成できません。これは、ビューが定義者権限のオブジェクトであり、ビューを作成するとき、自分にロールを通じて付与された権限はいずれも(システム権限もオブジェクト権限も)使用できないためです。権限が直接自分に付与されている場合は、この権限を使用できます。しかし権限が後で取り消されると、ビュー定義は無効になり(エラーとなり)、再度使用する前に再コンパイルする必要があります。

ロールを介して受け取った権限の使用許可と使用制限について、次の例で具体的に説明します。

次のようなユーザーを想定します。

  • CREATE VIEWシステム権限を持つロールが付与されています。

  • employees表に対するSELECT object権限を持つロールが直接付与されています。

  • departments表に対するSELECT object権限が直接付与されています。

前述の権限がこのユーザーに直接的および間接的に付与されているとすると、

  • このユーザーはemployees表とdepartments表の両方に対してSELECT文を発行できます。

  • このユーザーには、 employees表のCREATE VIEW権限とSELECT権限がロールを介して付与されていますが、employees表のSELECT object権限がロールを介して付与されていたため、employees表のビューは作成できません。

  • このユーザーにはCREATE VIEW権限がロールを介して付与され、departments表のSELECT権限が直接付与されているため、departments表のビューは作成できます。

4.11.1.10 オペレーティング・システムによるロールの支援方法

環境によっては、オペレーティング・システムを使用してデータベース・セキュリティを管理できます。

オペレーティング・システムを使用して、データベース・ロールの付与と取消し、パスワードの認証を管理できます。この機能は、すべてのオペレーティング・システムで利用できるとはかぎりません。

関連項目:

オペレーティング・システムによるロールの管理方法の詳細は、そのオペレーティング・システム固有のOracle Databaseマニュアルを参照してください。

親トピック: ユーザー・ロールについて

4.11.1.11 分散環境でのロールの機能

分散データベース環境では、必要なすべてのロールを分散(リモート)セッションのデフォルト・ロールとして設定する必要があります。

ローカル・データベース・セッション内からリモート・データベースに接続しているときは、これらのロールを使用可能にすることはできません。たとえば、ユーザーは、リモート・サイトでロールを使用可能にしようとするリモート・プロシージャを実行できません。

4.11.2 Oracle Databaseのインストールで事前に定義されているロール

Oracle Databaseには、データベース管理を容易にする一連の事前定義ロールが用意されています。

これらの事前定義ロールは、データベース作成の一部である標準スクリプト(catalog.sqlやcatproc.sqlなど)の実行時に、Oracleデータベースに対して自動的に定義され、共通ロールとみなされます。他のオプションや製品をインストールすると、他の事前定義のロールが作成される場合があります。DBA_ROLESデータ・ディクショナリ・ビューのROLEおよびORACLE_MAINTAINED列を問い合せると、Oracleで作成および管理されているロールを確認できます。ORACLE_MAINTAINEDの出力がYの場合、ロールの作成時に使用したスクリプトを使用する以外の方法でロールを変更しないでください。

表4-7 Oracle Databaseの事前定義ロール

事前定義のロール 説明

ACCHK_READ

アプリケーション・コンティニュイティ保護チェック(ACCHK)を使用する権限を提供します。これには、次のデータ・ディクショナリ・ビューを問い合せる機能が含まれます。

  • DBA_ACCHK_EVENTS
  • DBA_ACCHK_EVENTS_SUMMARY
  • DBA_ACCHK_STATISTICS
  • DBA_ACCHK_STATISTICS_SUMMARY

データベース管理者およびPDB管理者は、ACCHKから結果を読み取れるようにこのロールを開発者に付与します。

ADM_PARALLEL_EXECUTE_TASK

DBMS_PARALLEL_EXECUTE PL/SQLパッケージを使用して表のデータをパラレルに更新するための権限を提供します。

AQ_ADMINISTRATOR_ROLE

アドバンスト・キューイングを管理するための権限を提供します。ENQUEUE ANY QUEUE、DEQUEUE ANY QUEUE、MANAGE ANY QUEUE、アドバンスト・キューイングの表に対するSELECT権限、およびアドバンスト・キューイングのパッケージに対するEXECUTE権限が含まれます。

AQ_USER_ROLE

サポートされていませんが、主にリリース8.0との互換性のために残されています。DBMS_AQおよびDBMS_AQINパッケージに対するEXECUTE権限を提供します。

AUDIT_ADMIN

統合およびファイングレイン監査ポリシーの作成、AUDITおよびNOAUDIT SQL文の使用、監査データの表示および監査証跡の管理を行う権限を提供します

AUDIT_VIEWER

監査データを表示および分析する権限を提供します

AUTHENTICATEDUSER

システムにログインしたユーザーを定義するために、XDBプロトコルで使用されます。

AVTUNE_PKG_ROLE

ジョブを実行できるように、デフォルトでDBMS_AVTUNEパッケージに付与されます。DBMS_AVTUNEパッケージにはロールが付与されるため、実行時にこれらの権限を持ち、ユーザーが持つ必要はありません。

BDSQL_ADMIN

DBMS_BDSQL PL/SQLパッケージを使用する権限を提供します

BDSQL_USER

Oracle Big Data SQLを使用するための権限を提供します

CAPTURE_ADMIN

権限分析ポリシーの作成および管理に必要な権限を提供します。

CDB_DBA

SET CONTAINER、SELECT ON PDB_PLUG_IN_VIOLATIONS、SELECT ON CDB_LOCAL_ADMIN_PRIVSなどのCDBの管理に必要な権限を提供します。サイトで追加の権限が必要な場合、ロール(共通またはローカル)を作成してこれらの権限に対応し、このロールをCDB_DBAロールに付与できます。

CONNECT

CREATE SESSIONシステム権限を提供します。

このロールは、Oracle Databaseの以前のリリースとの互換性を考慮して用意されています。このロールに組み込まれている権限は、DBA_SYS_PRIVSデータ・ディクショナリ・ビューを問い合せることで判別できます。

ノート: このロールに依存せずに、データベース・セキュリティ用に独自のロールを設計することをお薦めします。このロールは、将来のリリースのOracle Databaseでは自動生成されない可能性があります。

CTXAPP

Oracle Textの索引および索引プリファレンスの作成権限およびPL/SQLパッケージの使用権限を提供します。このロールはOracle Textユーザーに付与される必要があります。

DATAPUMP_EXP_FULL_DATABASE

Oracle Data Pumpを使用してOracleデータベースからデータをエクスポートする権限を提供します。

注意: このロールは非常に強力であり、データベース内の任意のスキーマの任意のデータへのユーザー・アクセスを提供します。このロールをユーザーに付与する場合は注意が必要です。

DATAPUMP_IMP_FULL_DATABASE

Oracle Data Pumpを使用してOracleデータベースにデータをインポートする権限を提供します。

注意: このロールは非常に強力であり、データベース内の任意のスキーマの任意のデータへのユーザー・アクセスを提供します。このロールをユーザーに付与する場合は注意が必要です。

DB_DEVELOPER_ROLE

アプリケーション開発者が必要とするシステム権限、オブジェクト権限、事前定義ロール、PL/SQLパッケージ権限およびトレース権限の大部分を提供します。

DBA

ANY権限(DELETE ANY TABLEなど)やGRANT ANY PRIVILEGE権限など、多数のシステム権限を提供します。

このロールは、Oracle Databaseの以前のリリースとの互換性を考慮して用意されています。このロールに組み込まれている権限は、DBA_SYS_PRIVSデータ・ディクショナリ・ビューを問い合せることで確認できます。

ノート: このロールに依存せずに、データベース・セキュリティ用に独自のロールを設計することをお薦めします。このロールは、将来のリリースのOracle Databaseでは自動生成されない可能性があります。

DBJAVASCRIPT

12.2 Oracle JVMのNashornエンジンを使用して、スキーマにJavaScriptコードを実行する権限が付与されます。サポート対象外。

DBMS_MDX_INTERNAL

DBMS_MDX_ODBO PL/SQLパッケージをサポートします。内部使用のみに対応しています。

DGPDB_ROLE

内部アカウントであるOracle Data GuardアカウントDGPDB_INTに権限を付与します

DV_ACCTMGR

Oracle Database Vault環境でユーザー・アカウントを管理する権限を提供します

DV_ADMIN

Oracle Database Vault PL/SQLパッケージを使用する権限を提供します

DV_AUDIT_CLEANUP

Oracle Database Vault環境でのパージ操作の権限を提供します

DV_DATAPUMP_NETWORK_LINK

Oracle Database Vault環境でOracle Data Pumpインポート操作を実行するための権限を提供します

DV_GOLDENGATE_ADMIN

Oracle Database Vault環境でOracle GoldenGateを構成する権限を提供します

DV_GOLDENGATE_REDO_ACCESS

Oracle Database Vault環境でOracle GoldenGateのTRANLOGOPTIONS DBLOGREADERメソッドを使用してREDOログにアクセスする権限を提供します

DV_MONITOR

Oracle Enterprise Manager Cloud ControlエージェントがOracle Database Vaultでレルムまたはコマンド・ルール定義に関する違反未遂および構成の問題を監視できるようにします

DV_OWNER

Oracle Database Vaultロールとその構成を管理する権限を提供します

DV_PATCH_ADMIN

Oracle Database Vault環境でパッチ操作を実行する権限を提供します

DV_POLICY_OWNER

限定的なOracle Database Vaultポリシーを管理する権限を提供します

DV_SECANALYST

Oracle Database Vaultレポートの分析およびOracle Database Vaultの監視権限を提供します

DV_STREAMS_ADMIN

Oracle Database Vault環境で非推奨となったOracle Streamsの構成に必要です

DV_XSTREAM_ADMIN

Oracle Database Vault環境でOracle XStreamsを構成するために必要です

DBFS_ROLE

DBFS(データベース・ファイルシステム)パッケージおよびオブジェクトへのアクセスを提供します。

EJBCLIENT

Javaストアド・プロシージャからEJBに接続する権限を提供します。

EXECUTE_CATALOG_ROLE

データ・ディクショナリ内のオブジェクトに対するEXECUTE権限を提供します。

EXP_FULL_DATABASE

エクスポート・ユーティリティ(後継はOracle Data Pump)を使用してデータベースの全インポートおよび増分エクスポートを実行するために必要な権限を提供します。含まれる権限は、SELECT ANY TABLE、BACKUP ANY TABLE、EXECUTE ANY PROCEDURE、EXECUTE ANY TYPE、ADMINISTER RESOURCE MANAGER、そして表SYS.INCVID、SYS.INCFIL、SYS.INCEXPに対するINSERT、DELETE、およびUPDATEです。EXECUTE_CATALOG_ROLEおよびSELECT_CATALOG_ROLEロールも含みます。

このロールは、エクスポート・ユーティリティおよびインポート・ユーティリティを簡単に使用できるように用意されています。

注意: このロールは非常に強力であり、データベース内の任意のスキーマの任意のデータへのユーザー・アクセスを提供します。このロールをユーザーに付与する場合は注意が必要です。

GATHER_SYSTEM_STATISTICS

DBMS_STATS.GATHER_SYSTEM_STATISTICSプロシージャを使用して収集されるシステム統計の更新権限を提供します。

GDS_CATALOG_SELECT

グローバル・データ・サービス(GDS)およびGSMADMIN_INTERNALが所有するシャーディング・カタログ表に対する読取り権限を提供します。このロールは、主にGDSおよびシャーディングのOracle Enterprise Managerサポート用に作成されましたが、ユーザーはこれを使用してGDSメタデータを使用して独自のレポートを実行できます。

GLOBAL_AQ_USER_ROLE

Oracle Database Advanced Queuingで使用されるLDAPサーバーへの接続を確立する権限を提供します

GRAPH_ADMINISTRATOR

(OSユーザーとして起動および停止操作を実行する場合と比較して) Java APIを使用してグラフ・サーバー(PGX)で操作を実行する権限を提供します

GRAPH_DEVELOPER

Java APIまたはSQLclまたはグラフ視覚化アプリケーションを使用して、グラフを作成、公開、変更、問合せおよび表示する権限を提供します

GRAPH_USER

Java API、SQLclまたはグラフ・ビジュアライゼーション・アプリケーションを使用して、グラフを問い合せて表示する権限を提供します

GSMADMIN_ROLE

GDSまたはシャーディング構成を管理できるように、グローバル・データ・サービス(GDS)およびシャーディング管理者に付与する必要があります

GSMCATUSER_ROLE

内部使用のためにOracle提供のアカウントGSMCATUSERにのみ付与されます

GSMROOTUSER_ROLE

内部使用のためにOracle提供のアカウントGSMROOTUSERにのみ付与されます

GSMUSER_ROLE

内部使用のためにOracle提供のアカウントGSMUSERにのみ付与されます

GSM_POOLADMIN_ROLE

GDSにのみ有効です(シャーディング用ではありません)。GDSプールを管理できるように、GDSプール管理者に付与する必要があります

HS_ADMIN_EXECUTE_ROLE

異機種間サービス(HS)PL/SQLパッケージの使用を希望するユーザーに対してEXECUTE権限を提供します

HS_ADMIN_ROLE

異機種間サービス(HS)PL/SQLパッケージの使用権限およびHS関連のデータ・ディクショナリ・ビューの問合せ権限を提供します

HS_ADMIN_SELECT_ROLE

異機種間サービスのデータ・ディクショナリ・ビューの問合せ権限を提供します

IMP_FULL_DATABASE

インポート・ユーティリティ(後継はOracle Data Pump)を使用してデータベースの全インポートを実行するために必要な権限を提供します。システム権限の詳細リスト(権限を表示するにはビューDBA_SYS_PRIVSを使用)と、ロールEXECUTE_CATALOG_ROLEおよびSELECT_CATALOG_ROLEが含まれます。

このロールは、エクスポート・ユーティリティおよびインポート・ユーティリティを簡単に使用できるように用意されています。

注意: このロールは非常に強力であり、データベース内の任意のスキーマの任意のデータへのユーザー・アクセスを提供します。このロールをユーザーに付与する場合は注意が必要です。

JAVADEBUGPRIV

Oracle Database Javaアプリケーション・デバッガの実行権限を提供します

JAVAIDPRIV

このリリースでは非推奨となりました

JAVASYSPRIV

Oracle JVMで保護されたパッケージの更新を含む、Java 2を使用するための主要な権限を提供します

JAVAUSERPRIV

Java 2を使用するための制限された権限を提供します

JAVA_ADMIN

Oracle Database Javaアプリケーションのポリシー表を更新する管理権限を提供します

JMXSERVER

データベース・セッションでJMXエージェントを起動およびメンテナンスする権限を提供します

LBAC_DBA

SA_SYSDBA PL/SQLパッケージの使用権限を提供します

LOGSTDBY_ADMINISTRATOR

SQL Apply(ロジカル・スタンバイ・データベース)環境を管理する管理権限を提供します

OEM_ADVISOR

DBMS_SQLTUNE PL/SQLパッケージによってSQL Tuning Setを作成、削除、選択(読取り)、ロード(書込み)および削除する権限と、ADVISOR PL/SQLパッケージを使用してアドバイザ・フレームワークにアクセスする権限を提供します

OEM_MONITOR

Oracle Enterprise Managerの管理エージェント・コンポーネントで必要とされる、データベースを監視および管理する権限を提供します

OGG_APPLY

Oracle GoldenGate Replicatを管理する権限を提供します

OGG_APPLY_PROCREP

Oracle GoldenGateプロシージャ・レプリケーションを使用するための権限を提供します

OGG_CAPTURE

Oracle GoldenGate Extractを使用する権限を提供します

OGG_CAPTURE_SHARED

GoldenGate共有取得を管理する権限を提供します

OPTIMIZER_PROCESSING_RATE

DBMS_STATSパッケージのGATHER_PROCESSING_RATE、SET_PROCESSING_RATEおよびDELETE_PROCESSING_RATEプロシージャを実行する権限を提供します。これらのプロシージャは、自動的な並列度(Auto DOP)のシステムの処理率を管理します。Auto DOPは、これらの処理率を使用して、SQL文の最適な並列度を決定します。

OSAK_ADMIN_ROLE

Oracle SQL Access to Kafka (OSAK)管理者がKafkaクラスタを構成、登録および管理するための権限を提供します

PDB_DBA

シードPDBから新しいPDBを作成する場合に作成されるローカル・ユーザーに自動的に付与されます。権限はこのロールに提供されません。

PGX_SERVER_GET_INFO

管理APIを使用して、プロパティ・グラフ(PGX)インスタンスのステータス情報を検索する権限を提供します

PGX_SERVER_MANAGE

PGXインスタンスを管理する権限を提供します

PGX_SESSION_ADD_PUBLISHED_GRAPH

構成ファイルを使用したデータベースからのロード、PGQLのCREATE PROPERTY GRAPH文の使用、別のグラフからのサブグラフの作成、またはGraphBuilderの使用によって、PGXに新しいグラフを作成する権限を提供します

PGX_SESSION_COMPILE_ALGORITHM

PGXアルゴリズムAPIを使用してアルゴリズムをコンパイルする権限を提供します

PGX_SESSION_CREATE

ServerInstance.createSession APIを使用して新しいPGXセッションを作成する権限を提供します

PGX_SESSION_GET_PUBLISHED_GRAPH

別のユーザーによってパブリック・ネームスペースに公開されたグラフを問い合せて表示する権限を提供します

PGX_SESSION_MODIFY_MODEL

PgxMLを使用してMLモデルを作成、トレーニングおよび格納する権限を提供します

PGX_SESSION_NEW_GRAPH

構成ファイルを使用したデータベースからのロード、PGQLのCREATE PROPERTY GRAPH文の使用、別のグラフからのサブグラフの作成、またはGraphBuilderの使用によって、PGXに新しいグラフを作成する権限を提供します

PGX_SESSION_READ_MODEL

PgxMLを使用してMLモデルをロードおよび使用する権限を提供します

PPLB_ROLE

内部使用のためにOracle Data GuardアカウントDGPDB_INTにのみ付与されます。このロールにより、DGPDB_INTアカウントは、新しいPDBの接続時にプリプラグイン・バックアップ表にアクセスできます。このロールをユーザーや他のロールに付与しないでください。

PROVISIONER

Oracle Database Real Applicationセッションのグローバル・コールバックを登録および更新してプリンシパルをプロビジョニングする権限を提供します。

RDFCTX_ADMIN

リソース摘要フレームワーク(RDF)グラフのセマンティック(テキスト)検索機能を使用するための権限を提供します

RECOVERY_CATALOG_OWNER

リカバリ・カタログの所有者に対して次の権限を提供します。

  • ADMINISTER DATABASE
  • ALTER SESSION
  • CREATE ANY CONTEXT
  • CREATE ANY SYNONYM
  • CREATE ANY TRIGGER
  • CREATE CLUSTER
  • CREATE DATABASE LINK
  • CREATE PROCEDURE
  • CREATE SEQUENCE
  • CREATE SESSION
  • CREATE SYNONYM
  • CREATE TABLE
  • CREATE TRIGGER
  • CREATE VIEW
  • DROP ANY SYNONYM
  • EXECUTE ON DBMS_RLS
  • QUERY REWRITE

RECOVERY_CATALOG_OWNER_VPD

リカバリ・カタログ管理の権限を提供します。

RECOVERY_CATALOG_USER

リカバリ・カタログ管理の権限を提供します。

RESOURCE

次のリソース関連のシステム権限を提供します。

  • CREATE ANALYTIC VIEW
  • CREATE ATTRIBUTE DIMENSION
  • CREATE CLUSTER
  • CREATE HIERARCHY
  • CREATE INDEXTYPE
  • CREATE MATERIALIZED VIEW
  • CREATE OPERATOR
  • CREATE PROCEDURE
  • CREATE PROPERTY GRAPH
  • CREATE SEQUENCE
  • CREATE SYNONYM
  • CREATE TABLE
  • CREATE TRIGGER
  • CREATE TYPE
  • CREATE VIEW

RESOURCEがUNLIMITED TABLESPACEシステム権限を提供しないことに注意してください。

このロールは、Oracle Databaseの以前のリリースとの互換性を考慮して用意されています。このロールに組み込まれている権限は、DBA_SYS_PRIVSデータ・ディクショナリ・ビューを問い合せることで判別できます。

ノート: このロールに依存せずに、データベース・セキュリティ用に独自のロールを設計することをお薦めします。このロールは、将来のリリースのOracle Databaseでは自動生成されない可能性があります。

SAGA_ADM_ROLE

DBMS_SAGA_ADMパッケージからAPIを起動できます。このロールは、初期設定のためにsaga管理者に必要であり、 DBMS_SAGA_ADM APIへのフル・アクセスを提供します。

SAGA_CONNECT_ROLE

Oracle Sagaフレームワークの使用時にリモート・データベース・リンク・ユーザーに提供されます。

SAGA_PARTICIPANT_ROLE

Saga参加者サービスに必要です。Sagaプリミティブは、SAGA_PARTICIPANTロールが付与されているユーザーのみが起動できます。

SCHEDULER_ADMIN

権限受領者がDBMS_SCHEDULERパッケージのプロシージャを実行できるようにします。すべてのジョブ・スケジューラ・システム権限が含まれ、DBAロールに含まれます。

SELECT_CATALOG_ROLE

データ・ディクショナリ内のオブジェクトに対するSELECT権限を付与します。

SHARDED_SCHEMA_OWNER

シャード・スキーマ所有者が独自のスキーマでシャーディング管理タスクを実行するための権限を提供します

SODA_APP

SODA APIを使用して、特にドキュメント・コレクションを作成、削除およびリストする権限を提供します。

SQL_FIREWALL_ADMIN

SQLファイアウォールを管理するための次の権限を提供します。

  • ADMINISTER SQL FIREWALLシステム権限
  • DBMS_SQL_FIREWALL PL/SQLパッケージに対するEXECUTE権限
  • DBA_SQL_FIREWALL_*データ・ディクショナリ・ビュー用のSELECT権限

SQL_FIREWALL_VIEWER

SQLファイアウォールDBA_SQL_FIREWALL_*データ・ディクショナリ・ビュー用のSELECT権限を提供します

WM_ADMIN_ROLE

Oracle Workspace Managerの管理権限を提供します。これにより、ユーザーはDBMS_WMプロシージャをすべてのバージョン対応表、作業領域、およびセーブポイントで、それぞれの所有者に関係なく実行できるようになります。また、ユーザーはWorkspace Managerに固有のシステム・パラメータも変更できるようになります。

XDBADMIN

権限受領者がXMLスキーマを、その所有者のみが使用したりアクセスするために登録するのではなく、グローバルに登録できるようにします。また、権限受領者がOracle XML DB Repository (非推奨)にアクセスするときにアクセス制御リスト(ACL)チェックを回避できるようにもします。

XDB_SET_INVOKER

権限受領者が実行者権限ハンドラを定義して、XMLリポジトリのトリガーのリソース構成を作成または更新できるようにします。デフォルトでは、このロールはDBAロールに付与されますが、XDBADMINロールには付与されません。

XDB_WEBSERVICES

権限受領者がHTTPSを使用してOracle DatabaseのWebサービスにアクセスできるようにします。ただし、パブリックなデータベース内のオブジェクトに対するユーザー・アクセスは提供されません。パブリック・アクセスを許可するには、ユーザーにXDB_WEBSERVICES_WITH_PUBLICロールを付与する必要があります。ユーザーがこれらのWebサービスを使用するには、SYSで、Webサービスのサーブレットを使用可能にする必要があります。

XDB_WEBSERVICES_OVER_HTTP

権限受領者がHTTPを使用してOracle DatabaseのWebサービスにアクセスできるようにします。ただし、パブリックなデータベース内のオブジェクトに対するユーザー・アクセスは提供されません。パブリック・アクセスを許可するには、ユーザーにXDB_WEBSERVICES_WITH_PUBLICロールを付与する必要があります。

XDB_WEBSERVICES_WITH_PUBLIC

権限受領者が、Oracle DatabaseのWebサービスを介してパブリック・オブジェクトにアクセスできるようにします。

XSTREAM_APPLY

XStream Inを管理する権限を提供します

XSTREAM_CAPTURE

XStream Outを管理する権限を提供します

XS_CACHE_ADMIN

Oracle Database Real Application Securityでは、権限受領者が中間層キャッシュを管理できます。XSAccessControllerクラスのcheckAcl(認可)メソッドの中間層レベルでのセキュリティ・ポリシーのキャッシュに必要です。このロールをアプリケーション接続ユーザーまたはReal Application Securityディスパッチャに付与します。

XS_NAMESPACE_ADMIN

Oracle Database Real Application Securityでは、権限受領者がセッションのネームスペースおよび属性を管理および操作できます。このロールをReal Application Securityセッション・ユーザーに付与します。

XS_RESOURCE

Oracle Database Real Application Securityでは、権限受領者がXS_ACL PL/SQLパッケージを通じて付加されたスキーマのオブジェクトを管理できます。このパッケージは、アクセス制御リスト(ACL)を作成および管理するプロシージャを作成します。ADMIN SEC POLICY権限を含みます。Oracle Database RESOURCEロールと似ています。

XS_SESSION_ADMIN

Oracle Database Real Application Securityでは、権限受領者がセッションを作成、接続、切離しおよび破棄する機能を含むセッションのライフ・サイクルを管理できます。このロールをアプリケーション接続ユーザーまたはReal Application Securityディスパッチャに付与します。

ノート:

各インストールで独自のロールが作成されて、必要な権限のみが割り当てられます。このようにして、使用中の権限の詳細な制御が維持されます。このプロセスにより、Oracle Databaseで定義されるロールがOracle Databaseで変更や削除されたとき、既存のロール、権限、またはプロシージャを調整する必要もなくなります。たとえば、CONNECTロールが現在持っている権限はCREATE SESSIONの1つのみです。

親トピック: ユーザー・ロールの管理

4.11.3 ロールの作成

パスワードの有無に関係なく、認証されるロールを作成できます。外部ロールまたはグローバル・ロールも作成できます。

親トピック: ユーザー・ロールの管理

4.11.3.1 ロールの作成について

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

ロールを作成する場合、CREATE ROLEシステム権限が必要です。通常、このシステム権限はセキュリティ管理者のみが持っています。作成した直後のロールには、権限は対応付けられていません。次のステップで、新しいロールに権限または他のロールを付与します。

作成する各ロールには、データベースの既存のユーザー名やロール名とは異なる、一意の名前を指定する必要があります。ロールはどのユーザーのスキーマ内にも格納されません。マルチバイト文字セットを使用するデータベースでは、各ロール名に少なくとも1つのシングルバイト文字を含めることをお薦めします。ロール名がマルチバイト・キャラクタのみの場合、暗号化されたロール名とパスワードの組合せの安全性は大幅に低くなります。パスワードのガイドラインは、パスワードの保護に関するガイドラインのガイドライン1を参照してください。

IDENTIFIED BY句を使用して、パスワードによってロールを認可します。この句は、このロールを付与された特定ユーザーがロールを使用をする前に、どの認可方式で認可される必要があるかを指定します。この句を指定しないか、またはNOT IDENTIFIEDを指定すると、認可がなくてもロールが使用可能になります。ロールには、必要な認可方式として次の方式を指定できます。

  • パスワードを使用したデータベースによる認可

  • 指定のパッケージを使用したアプリケーションによる認可

  • オペレーティング・システム、ネットワークまたはその他の外部ソースによる外部認可

  • エンタープライズ・ディレクトリ・サービスによるグローバル認可

パスワードで保護されたロールの作成の代替手段として、セキュア・アプリケーション・ロールの使用をお薦めします。

ロールの作成に関する次の制限に注意してください。

  • ロールとユーザーに同じ名前を付けることはできません。

  • このロールがCDB共通ロールでないかぎり、ロール名をCOMMON_USER_PREFIXパラメータの値(デフォルトではC##)で始めることはできません。

4.11.3.2 パスワードを使用して認証されるロールの作成

IDENTIFIED BY句を使用して、パスワードで認証されるロールを作成できます。

  • パスワード認証されるロールを作成するには、IDENTIFIED BY句が指定されたCREATE ROLE文を使用します。

たとえば: 

CREATE ROLE clerk IDENTIFIED BY password;

ノート:

  • パスワードで保護されるロールは、プロキシ・セッションで有効にできます。セキュア・アプリケーション・ロールとパスワードで保護されるロールの両方が、セッションでロールを有効にするための安全な方法を提供します。パスワードを維持して安全でないチャネルで転送する必要がある場合、または複数の人がパスワードを知る必要がある場合は、パスワードで保護されるロールではなく、セキュアなパスワード・ロールを使用することをお薦めします。プロキシ・セッションでパスワードで保護されるロールは、ロールを設定するために自動化が使用される状況に適しています。
  • SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータを11以上に設定する場合、IDENTIFIED BY句で作成されたロールを再作成する必要があります。
4.11.3.3 パスワード認証のないロールの作成

IDENTIFIED BY句を省略することで、パスワードを必要としないロールを作成できます。

  • 句を指定せずにCREATE ROLE文を使用して、パスワード認証のないロールを作成します。

たとえば:

CREATE ROLE salesclerk;

親トピック: ロールの作成

4.11.3.4 外部またはグローバルのロールの作成

外部ロールまたはグローバル・ロールを使用すると、データベース外部のサービスでデータベース・ロールを認証済ユーザーに関連付けることができます。

データベース外部ロールは、オペレーティング・システムとRADIUSグループに関連付けられます。このように、データベース・ユーザー認可はデータベースの外部から管理できます。

外部ユーザーは、ロールを使用可能にする前に、オペレーティング・システムやサード・パーティ・サービスなどの外部サービスによって認可されている必要があります。

グローバル・ロールは、集中管理されたユーザーまたはOracle Enterprise User Securityを使用してグローバルに認証されたユーザーによって使用されます。グローバル・ユーザーは、ログイン時にロールの使用が可能になる前に、エンタープライズ・ディレクトリ・サービスによってロールの使用を認可されている必要があります。

集中管理ユーザー(CMU)の使用に移行することをお薦めします。この機能を使用すると、データベースに対するエンタープライズ・ユーザー認証および認可のためにディレクトリ・サービスを介在させることなく、Microsoft Active Directoryに直接接続できます。Oracle Databaseがクラウドにある場合は、クラウド・アイデンティティ・プロバイダとの新しい統合のいずれかに移行することも選択できます。

  • 外部で認可されるロールを作成するには、CREATE ROLE文にIDENTIFIED EXTERNALLY句を含めます。

    たとえば:

    CREATE ROLE clerk_external IDENTIFIED EXTERNALLY;

  • グローバルに認可されるロールを作成するには、CREATE ROLE文を使用します。

    たとえば: 

    CREATE ROLE clerk_global IDENTIFIED GLOBALLY;

集中管理されたユーザーなどを含むディレクトリ・サービス・マッピングを介して、ロールをユーザーにグローバルに認可できます。

4.11.3.5 ロールの変更

ALTER ROLE文で、ロールの認可方法を変更できます。

ロールの認可方式を変更するには、ALTER ANY ROLEシステム権限またはADMINオプション付きのロールが付与されている必要があります。

セキュア・アプリケーション・ロールまたはパスワード認証ロールはユーザーに直接付与する必要があることに注意してください。ルートで共通ロールを作成する場合、それをローカル・ロールに変更できないことに注意してください。

  • ロールを変更するには、ALTER ROLE文を使用します。

    たとえば、ロールを有効にする前にユーザーが外部ソースによって認可されている必要があるように指定する目的でclerkロールを変更するとします。 

    ALTER ROLE clerk IDENTIFIED EXTERNALLY;

親トピック: ロールの作成

4.11.4 ロール認可のタイプの指定

データベースや外部ソースなどの様々なソースを通じて認可されるように、ロールを構成できます。

親トピック: ユーザー・ロールの管理

4.11.4.1 データベースを使用したロールの認可

データベースによって認可されたロールを、ロール・パスワードを割り当てることで保護できます。

パスワードで保護されたロールが付与されている場合は、SET ROLE文でそのロールの正しいパスワードを指定することで、そのロールを有効または無効にできます。パスワード認証されるロールは、そのロールがデフォルト・ロールのリストに含まれている場合でも、ログオン時に認証することはできません。SET ROLE文で必須パスワードを使用して、明示的に使用可能にする必要があります。

  1. パスワード認証されるロールを作成するには、IDENTIFIED BY句が指定されたCREATE ROLE文を使用します。
    たとえば: 
    CREATE ROLE hr_clerk IDENTIFIED BY password;

    このロールを使用可能にするには、パスワードを入力する必要があります。

  2. パスワード認証されるロールを設定するには、SET ROLE文を使用します。

    次の例は、SET ROLE文を使用してパスワード認証ロールを設定する方法を示しています。 

    SET ROLE hr_clerk IDENTIFIED BY password;
4.11.4.2 アプリケーションを使用したロールの認可

アプリケーション・ロールを使用可能にできるのは、認可されたPL/SQLパッケージを使用するアプリケーションのみです。

アプリケーション開発者は、アプリケーション内部にパスワードを埋め込むことによってロールを保護する必要はありません。かわりに、アプリケーション・ロール(セキュア・アプリケーション・ロール)を作成して、ロールを使用可能にすることを認可するPL/SQLパッケージを指定できます。

  • 認可されたPL/SQLパッケージによって使用可能になるロールを作成するには、CREATE ROLE SQL文でIDENTIFIED USING package_name句を使用します。

たとえば、ロールadmin_roleがアプリケーション・ロールであり、このロールは、PL/SQLパッケージhr.admin内に定義されているモジュールによってのみ使用可能にできることを示すとします。 

CREATE ROLE admin_role IDENTIFIED USING hr.admin;
4.11.4.3 外部ソースを使用したロールの認可

Oracle Databaseでは外部ロールの使用がサポートされますが、一定の制限があります。

外部ロールは、データベースにローカルに定義できますが、グローバル・ユーザー、グローバル・ロールまたはデータベース内の他のロールには付与できません。オペレーティング・システムまたはネットワーク・クライアントによって認可されるロールを作成できます。

  • 外部ソースを使用してロールを認可するには、IDENTIFIED EXTERNALLY句を指定してCREATE ROLE文を使用します。

たとえば: 

CREATE ROLE accts_rec IDENTIFIED EXTERNALLY;
4.11.4.4 オペレーティング・システムを使用したロールの認可

Oracle Databaseではオペレーティング・システムを通じたロール認証がサポートされますが、一定の制限があります。

オペレーティング・システムによるロール認証が有効となるのは、そのオペレーティング・システムによって、オペレーティング・システム権限をアプリケーションと動的にリンクできる場合のみです。

ユーザーがアプリケーションを開始すると、オペレーティング・システムはオペレーティング・システム権限をそのユーザーに付与します。付与されたオペレーティング・システム権限は、アプリケーションに対応付けられたロールと一致します。この時点で、アプリケーションはアプリケーション・ロールを使用可能にできます。アプリケーションが終了すると、先に付与されたオペレーティング・システム権限は、そのユーザーのオペレーティング・システム・アカウントから取り消されます。

  • ロールをオペレーティング・システムによって認可する場合は、オペレーティング・システム・レベルで各ユーザーの情報を構成します。この操作は、オペレーティング・システムによって異なります。

ロールがオペレーティング・システムによって付与されている場合は、そのオペレーティング・システムによるロールの認可は不要です。

4.11.4.5 ネットワーク・クライアントを使用したロールの認可

Oracle Databaseではネットワーク・クライアントによるロール認証がサポートされますが、一定のセキュリティ・リスクが伴います。

ユーザーがデータベースにOracle Net経由で接続する場合、オペレーティング・システムはデフォルトではユーザーのロールを認証できません。この接続ではOracle Netが必要となるため、共有サーバー構成を介した接続が含まれます。リモート・ユーザーはネットワーク接続を介して別のオペレーティング・システム・ユーザーになりすますおそれがあるため、デフォルトでこのような制限が適用されています。REMOTE_OS_ROLESをFALSE(デフォルト)に設定することをお薦めします。

  • このようなセキュリティの危険性の心配がないときに、ネットワーク・クライアントに対してオペレーティング・システムのロール認証を使用する場合は、データベース初期化パラメータ・ファイル内の初期化パラメータREMOTE_OS_ROLESをTRUEに設定します。

この変更は、次回インスタンスを起動して、データベースをマウントするときに有効になります。

4.11.4.6 エンタープライズ・ディレクトリ・サービスによるグローバル・ロールの認可

グローバル・ロールを使用すると、グローバル・ユーザーの認可の取得先をエンタープライズ・ディレクトリ・サービスに限定できます。

グローバル・ロールは、権限とロールを付与することによってデータベース内でローカルに定義しますが、グローバル・ロール自体をそのデータベース内のユーザーや他のロールに付与することはできません。グローバル・ユーザーがデータベースへの接続を試みると、エンタープライズ・ディレクトリへの問合せが実行され、そのユーザーに対応付けられたグローバル・ロールが取得されます。グローバル・ロールは、エンタープライズ・ユーザー・セキュリティの構成要素の1つです。グローバル・ロールは1つのデータベースにのみ適用されますが、エンタープライズ・ディレクトリに定義されたエンタープライズ・ロールに付与できます。エンタープライズ・ロールは複数データベースのグローバル・ロールを含んだディレクトリ構造であり、エンタープライズ・ユーザーに付与できます。

ノート:

エンタープライズ・ユーザー・セキュリティ(EUS)は、Oracle Database 23cで非推奨になりました。

集中管理ユーザー(CMU)の使用に移行することをお薦めします。この機能を使用すると、データベースに対するエンタープライズ・ユーザー認証および認可のためにディレクトリ・サービスを介在させることなく、Microsoft Active Directoryに直接接続できます。Oracle Databaseがクラウドにある場合は、クラウド・アイデンティティ・プロバイダとの新しい統合のいずれかに移行することも選択できます。

  • エンタープライズ・ディレクトリ・サービスによって認可されるグローバル・ロールを作成するには、IDENTIFIED GLOBALLY句を指定してCREATE ROLE文を使用します。

たとえば: 

CREATE ROLE supervisor IDENTIFIED GLOBALLY;

4.11.5 ロールの付与と取消し

ロールに権限を付与またはロールから権限を取り消して、そのロールをユーザーまたは別のロールに付与できます。

親トピック: ユーザー・ロールの管理

4.11.5.1 ロールの付与と取消しについて

システム権限やオブジェクト権限をロールに付与できます。そしていずれのロールも任意のデータベース・ユーザーや他のロールに付与できます。

ただし、ロールを自身に付与したり、循環的に付与することはできません。つまり、ロールYがすでにロールXに付与されている場合は、ロールXをロールYに付与することはできません。

権限を選択的に使用できるように、Oracle Databaseでは、データベース・アプリケーションとユーザーがロールを使用可能または使用禁止にできます。ユーザーに付与した各ロールは、任意の時点で使用可能または使用禁止にできます。ユーザーのセキュリティ・ドメインには、そのユーザーに対して現在使用可能になっているすべてのロールの権限が含まれており、ユーザーに対して現在使用禁止になっているロールの権限は除外されています。

ロールに対して付与されたロールは、間接的に付与されたロールと呼ばれます。この種のロールは、ユーザーに対して明示的に使用可能または使用禁止にできます。ただし、別のロールを含んだロールを使用可能にすると、直接的に付与されたロールに含まれる間接的に付与されたロールは、すべて暗黙のうちに使用可能になります。

GRANT文を使用してロールを付与し、REVOKE文を使用して取り消します。ロールに対して権限を付与または取り消す場合にも同じ文を使用します。

セキュアなロール(つまりIDENTIFIED BYロール、IDENTIFIED USINGロールまたはIDENTIFIED EXTERNALLYロール)は、他のセキュアなロールと非セキュアなロールのどちらにも付与することはできません。SET ROLE文を使用して、セッションに対してセキュアなロールを有効化できます。

4.11.5.2 ロールを付与したり、取り消すことができるユーザー

GRANT ANY ROLEシステム権限を使用して、グローバル・ロール以外の任意のロールを他のユーザーまたはロールに付与したり、それらのロールを取り消したりできます。

グローバル・ロールはOracle Internet Directoryなどのディレクトリ内で管理されますが、その権限は単一のデータベース内に含まれます。デフォルトでは、ユーザーSYSまたはSYSTEMには、GRANT ANY ROLE権限があります。このシステム権限は非常に強力であるため、付与する場合は控えめに設定する必要があります。

ADMIN OPTION付きでロールを付与されたユーザーは、データベースの他のユーザーやロールに対してロールを付与したり、そのロールを取り消すことができます。つまり、このオプションによって、選択的なロール付与の管理が可能になります。

4.11.5.3 プログラム・ユニットに対するロールの付与と取消し

関数、プロシージャおよびPL/SQLパッケージ・プログラム・ユニットにロールを付与できます。

ロールは、プログラム・ユニットの実行中に有効になります。ただし、プログラム・ユニットのコンパイル中を除きます。これにより、ロールを直接ユーザーに付与しないで、PL/SQLコードの権限を一時的にエスカレートできます。また、アプリケーションのセキュリティが強化され、最低限の権限の原則を規定できます。

  • プログラム・ユニットに対してロールを付与または取り消すには、GRANTまたはREVOKE文を使用します。

次の例は、PL/SQLパッケージcheckstats_pkgへの同じロールの付与方法を示しています。 

GRANT clerk_admin TO package psmith.checkstats_pkg;

この例は、PL/SQLパッケージcheckstats_pkgのclerk_adminロールの取消し方法を示しています。 

REVOKE clerk_admin FROM package psmith.checkstats_pkg;

次の例は、プロシージャpsmith.check_stats_procへのロールclerk_adminの付与方法を示しています。 

GRANT clerk_admin TO PROCEDURE psmith.checkstats_proc;

4.11.6 ロールの削除

ロールの削除は、そのロールを付与されていたユーザーまたはロールのセキュリティ・ドメインに影響します。

つまり、削除したロールを付与されていたすべてのユーザーとロールのセキュリティ・ドメインは、削除したロール権限がなくなったことを反映するために変更されます。

削除したロールによって間接的に付与されていたロールもすべて、関連するセキュリティ・ドメインから削除されます。ロールを削除することによって、すべてのユーザーのデフォルト・ロール・リストからそのロールが自動的に削除されます。

オブジェクトの存在はロールを介して受け取った権限に依存しないため、ロールが削除されても、表や他のオブジェクトは削除されません。

ロールを削除するには、DROP ANY ROLEシステム権限またはADMINオプション付きのロールが付与されている必要があります。

  • ロールを削除するには、DROP ROLE文を使用します。

たとえば、ロールCLERKを削除する方法は次のとおりです。 

DROP ROLE clerk;

親トピック: ユーザー・ロールの管理

4.11.7 SQL*Plusユーザーによるデータベース・ロール使用の制限

SQL*Plusユーザーによるデータベース・ロールの使用を制限することで、侵入者による攻撃からデータベースを保護できます。

親トピック: ユーザー・ロールの管理

4.11.7.1 セキュリティに関する潜在的な問題となる非定型ツールの使用

非定型ツールは、不正なユーザーがこのようなツールにアクセスできると問題が発生する可能性があります。

事前作成データベース・アプリケーションは、アプリケーション使用中にユーザー・ロールを使用可能および使用禁止にすることも含めて、ユーザーのアクションを明示的に制御します。一方、SQL*Plusなどの非定型の問合せツールを使用すると、ユーザーは付与されたロールを使用可能および使用禁止にする文も含めて、あらゆるSQL文を発行できます(正常終了する場合としない場合があります)。

アプリケーションのユーザーは、そのアプリケーションに付加された権限を使用し、非定型ツールによってデータベース表に破壊的なSQL文を発行する恐れがあります。

たとえば、次の状況を想定します。

  • Vacation(休暇)アプリケーションには、それに対応するvacationロールがあります。

  • このvacationロールには、emp_tab表に対してSELECT、INSERT、UPDATEおよびDELETE文を発行する権限が含まれています。

  • Vacationアプリケーションは、vacationロールを介して取得した権限の使用を制御します。

ここで、vacationロールを付与されたユーザーを考えてみます。このユーザーが、Vacationアプリケーションを使用するかわりに、SQL*Plusを実行するとします。この時点でユーザーが制限を受けるのは、明示的に付与された権限またはロール(vacationロールを含む)を介して付与されている権限からのみです。SQL*Plusは非定型の問合せツールであるため、設計されたデータベース・アプリケーションを使用する場合のように、ユーザーは一連の事前定義アクションに制限されることはありません。ユーザーは、emp_tab表のデータの問合せや変更を自由に実行できます。

4.11.7.2 PRODUCT_USER_PROFILEシステム表がロールを制限できるしくみ

SYSTEMスキーマPRODUCT_USER_PROFILE表で、各ユーザーのSQL*Plus環境のSQLおよびSQL*Plusコマンドを無効にできます。

Oracle DatabaseでなくSQL*Plusでこのセキュリティが実行されます。GRANT、REVOKE、およびSET ROLEコマンドへのアクセスを制限して、ユーザーによる各自のデータベース権限の変更を制御することもできます。

PRODUCT_USER_PROFILE表を使用すると、ユーザーがアプリケーションでアクティブにできないロールをリストできます。また、様々なコマンド(SET ROLEなど)の使用を明示的に禁止できます。

たとえば、PRODUCT_USER_PROFILE表にエントリを作成して、次の処理を実行できます。

  • SQL*Plusで、clerkおよびmanagerロールの使用を禁止できます。

  • SQL*Plusで、SET ROLEの使用を禁止できます。

ユーザーMarlaが、SQL*Plusを使用してデータベースに接続するとします。Marlaには、clerk、managerおよびanalystのロールがあります。前述のPRODUCT_USER_PROFILEのエントリによって、Marlaは、SQL*Plusでanalystロールのみを使用できます。また、GinnyがSET ROLE文を発行しようとすると、SET ROLEの使用を禁止するPRODUCT_USER_PROFILE表のエントリが原因で、発行を明示的に禁止されます。

PRODUCT_USER_PROFILE表は、様々な理由からセキュリティが完全には保証されないことに注意してください。(PRODUCT_USER_PROFILEは、Oracle Databaseリリース19cではサポートが終了しました。)前述の例では、SET ROLEがSQL*Plusで禁止されていますが、Marlaに直接付与されているその他の権限がある場合、MarlaはSQL*Plusを使用してそれらの権限を使用できます。

4.11.7.3 ストアド・プロシージャがビジネス・ロジックをカプセル化できるしくみ

ストアド・プロシージャは、ビジネス・ロジックによって権限の使用をカプセル化し、適正なビジネス・トランザクションのコンテキストでのみ権限が実行されるようにします。

たとえば、アプリケーション開発者は、employees表にある従業員の名前および住所を、通常の勤務時間内にのみ更新するプロシージャを作成できます。

また、セキュリティ管理者は、人事部門の担当者にemployees表のUPDATE権限を付与するのではなく、プロシージャのみに権限を付与できます。これによって、人事部門の担当者が権限を使用できるのはプロシージャのコンテキスト内のみになり、employees表を直接更新できなくなります。

4.11.8 ロール権限およびセキュア・アプリケーション・ロール

セキュア・アプリケーション・ロールを使用可能にできるのは、認可されたPL/SQLパッケージまたはプロシージャのみです。

PL/SQLパッケージ自体は、アプリケーションへのアクセスを制御するために必要なセキュリティ・ポリシーを反映します。

この方法でロールを作成すると、起動対象アプリケーションに対してこのタイプのロールを使用可能にする場合に制限が加えられます。たとえば、アプリケーションはユーザーがプロキシを介して接続しているかどうかをチェックするなど、認証およびカスタマイズ認可を実行できます。

このタイプのロールでは、パスワードがアプリケーションのソース・コードに埋め込まれたり、表に格納されることがないため、セキュリティが強化されます。このように、データベースが実行する処理は、セキュリティ・ポリシーの実装に基づいており、その定義は1箇所(アプリケーション内ではなくデータベース内)に格納されます。ポリシーの変更が必要な場合は、アプリケーションを修正することなく1箇所の変更で済みます。ポリシーはロールと結び付けられているため、ユーザーがデータベースに接続する方法に関係なく、結果は常に同じです。

セキュア・アプリケーション・ロールを使用可能にするには、ユーザーがセキュア・アプリケーション・ロールによって付与された権限を行使する前のログイン時に、基礎となるパッケージをアプリケーションから直接起動して実行する必要があります。ログイン・トリガーを使用してセキュア・アプリケーション・ロールを使用可能にすることも、このタイプのロールをデフォルト・ロールにすることもできません。

セキュア・アプリケーション・ロールを使用可能にすると、認可されたPL/SQLパッケージがコール・スタックにあることが検証されます。つまり、認可されたPL/SQLパッケージがロールを使用可能にするコマンドを発行しているかどうかが検証されます。

セキュア・アプリケーション・ロールは、データベース接続の存在を保証するために使用できます。セキュア・アプリケーション・ロールはパッケージによって実装されるロールであるため、このパッケージによって、ユーザーが中間層を介して、または特定のIPアドレスからデータベースに接続できることを検証できます。この方法により、セキュア・アプリケーション・ロールは、ユーザーがアプリケーション外のデータにアクセスすることを防ぎます。ユーザーは、付与されているアプリケーション権限のフレームワーク内で作業するように規定されます。

関連トピック

親トピック: ユーザー・ロールの管理

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

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

親トピック: 権限とロール認可の構成

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

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

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

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

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

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

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

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

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

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

  • Oracle提供ロールはすべて共通です。たとえば、事前定義DBAロール。Oracle提供のスクリプトでは、Oracle提供のユーザーおよびロールに付与されるすべての権限またはロールは共通に付与されますが、例外は、システム権限が共通ロールPUBLICに対してローカルに付与される場合です。

関連トピック

親トピック: 共通ロールおよびローカル・ロールの管理

4.12.2 CDBの共通ロール

共通ロールは、CDBルートまたはアプリケーション・ルートのいずれかに存在し、ルート・コンテナ(CDBまたはアプリケーション・コンテナのいずれか)内のあらゆるPDBに適用されます。

共通ロールは、コンテナ間の操作に便利で、共通ユーザーがすべてのPDBでロールを持つことを保証します。すべての共通ユーザーは、次のいずれかのタイプになります。

  • Oracle提供

    DBAやPUBLICなどのOracle提供ロールはすべて、CDBに共通です。

  • ユーザー作成

    共通ロールを作成するには、CDBルートまたはアプリケーション・ルートのいずれか(これによって、ロールが共通となるコンテナが決まります)でCREATE ROLE ... CONTAINER=ALLを実行します。標準の命名規則が適用されます。また、CDB共通ロールには、COMMON_USER_PREFIX初期化パラメータによって指定された文字(デフォルトではc##またはC##)で始まる名前を付ける必要があります。

ロールのスコープは、そのロールが定義されているルートのスコープです。CDB$ROOTでロールを定義すると、そのスコープはCDB全体になります。アプリケーション・ルート内でロールを定義すると、そのスコープはアプリケーション・コンテナになります。

親トピック: 共通ロールおよびローカル・ロールの管理

4.12.3 共通ロールの使用方法

共通ロールは、ルートにおいて、およびそれらのロールが定義されているコンテナの各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ロールの権限を使用できます。

親トピック: 共通ロールおよびローカル・ロールの管理

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

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

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

関連トピック

親トピック: 共通ロールおよびローカル・ロールの管理

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

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

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

親トピック: 共通ロールおよびローカル・ロールの管理

4.12.6 共通ロールの作成の規則

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

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

  • 正しいルートにいることを確認します。共通ロールを作成するには、正しいルート(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ルートまたはアプリケーション・ルートの共通ロールとして作成されます。

親トピック: 共通ロールおよびローカル・ロールの管理

4.12.7 共通ロールの作成

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;

関連トピック

親トピック: 共通ロールおよびローカル・ロールの管理

4.12.8 ローカル・ロールの作成の規則

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

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

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

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

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

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

親トピック: 共通ロールおよびローカル・ロールの管理

4.12.9 CDBのローカル・ロール

ローカル・ロールは、単一のPDBにのみ存在するため、他のPDBのローカル・ロールとは完全に独立しています。

ローカル・ロールには、そのロールが存在するコンテナで適用されるロールおよび権限のみを含めることができます。たとえば、hrpdbでローカル・ロールpdbadminを作成した場合、このロールのスコープはこのPDBに制限されます。

同じCDB、または同じアプリケーション・コンテナのPDBには、同じ名前のローカル・ロールが含まれる場合があります。たとえば、ユーザー作成のロールpdbadminは、hrpdbとsalespdbのどちらにも存在する可能性があります。ただし、これらのロールは相互に完全に独立しています。

親トピック: 共通ロールおよびローカル・ロールの管理

4.12.10 ローカル・ロールの作成

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

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

    たとえば: 

    CONNECT sec_admin@pdb_name
Enter password: password
Connected.

    CDB内の使用可能なPDBを確認するには、CDBルート・コンテナにログインし、DBA_PDBSデータ・ディクショナリ・ビューのPDB_NAME列を問い合せます。現在のコンテナを確認するには、show con_nameコマンドを実行します。

  2. CONTAINER句をCURRENTに設定してCREATE ROLE文を実行します。

    たとえば: 

    CREATE ROLE sec_admin CONTAINER=CURRENT;

親トピック: 共通ロールおよびローカル・ロールの管理

4.12.11 共通ユーザーとローカル・ユーザーに対するロールの付与と取消し

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

共通ユーザーは、他の共通ユーザーへの共通ロールの付与および取消しを行うことができます。ローカル・ユーザーは、共通ロールを共通ユーザーを含む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;

関連トピック

親トピック: 共通ロールおよびローカル・ロールの管理

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

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

親トピック: 権限とロール認可の構成

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

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

PDBロックダウン・プロファイルは、PDB内のユーザーが使用可能な機能とオプションを制限します。PDB_OS_CREDENTIAL初期化パラメータでは、PDBに一意のオペレーティング・システム・ユーザーを指定して、オペレーティング・システム・アクセスを制限できます。また、PATH_PREFIXおよびCREATE_FILE_DEST句がPDBの作成時に指定された場合は、ファイル・システム・アクセスを制限します。

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

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

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

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

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

4.13.2 PDBロックダウン・プロファイルの仕組み

PDBロックダウン・プロファイルは、共有IDを使用する機能に対して様々なレベルでアクセスを制限するように設計されています。

ユースケースとしては、高、中および低レベルのロックダウン・プロファイルの作成があります。高いレベルではアクセスが大幅に制限されますが、低いレベルではアクセスが有効になります。

CDBルートまたはアプリケーション・ルートにログインするときに、次のオプション句をサポートしているCREATE LOCKDOWN PROFILE文を発行して、ロックダウン・プロファイルを作成します。

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

  • INCLUDING dynamic_base_profileは、既存のプロファイルの値を使用して新しいロックダウン・プロファイルを作成しますが、この新しいロックダウン・プロファイルは、基本プロファイルを構成するDISABLE STATEMENTルール、および基本プロファイルへの以降の変更を継承するという点が異なります。

文を発行するユーザーは、現在のコンテナでCREATE LOCKDOWN PROFILEシステム権限を持っている必要があります。制約を追加および削除するには、ALTER LOCKDOWN PROFILE文を使用します。ユーザーはCDBルートまたはアプリケーション・ルートでALTER文を発行する必要があり、現在のコンテナでALTER LOCKDOWN PROFILEシステム権限を持っている必要があります。

ロックダウン・プロファイルは、PDB_LOCKDOWN初期化パラメータを使用して指定します。このパラメータによって、PDBロックダウン・プロファイルが指定のPDBに適用されるかどうかが決定します。このパラメータは、次のレベルで設定できます。

  • PDB

    プロファイルは、設定されるPDBにのみ適用されます。

  • アプリケーション・コンテナ

    プロファイルは、アプリケーション・コンテナ内のすべてのアプリケーションPDBに適用されます。値を変更できるのは、アプリケーション共通のSYSDBA権限または共通のALTER SYSTEM権限を持つアプリケーション共通ユーザー、あるいは共通のSYSDBA権限または共通のALTER SYSTEM権限を持つCDB共通ユーザーのみです。

  • CDB

    プロファイルはすべてのPDBに適用されます。共通のSYSDBA権限または共通のALTER SYSTEM権限を持つ共通ユーザーは、特定のPDBに対するCDB全体の設定をオーバーライドできます。

PDBのPDB_LOCKDOWNパラメータが、このPDBのコンテナ(CDBまたはアプリケーション・コンテナ)とは異なるロックダウン・プロファイルの名前に設定されている場合は、一連のルールによって制限の間の相互作用が制御されます。

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

この例では、CREATE LOCKDOWN PROFILE権限を持つ共通ユーザーとしてCDBルートに接続します。ALTER SYSTEM FLUSH SHARED POOL以外のすべてのALTER SYSTEM文を無効にする、mediumというプロファイルを作成します。 

CREATE LOCKDOWN PROFILE medium;
ALTER LOCKDOWN PROFILE medium DISABLE STATEMENT=('ALTER SYSTEM');
ALTER LOCKDOWN PROFILE medium ENABLE STATEMENT=('ALTER SYSTEM') CLAUSE=('FLUSH SHARED POOL');

同じ共通ユーザーとして、このプロファイルを必要とする各PDBに接続し、ALTER SYSTEMを使用してPDB_LOCKDOWN初期化パラメータをmediumに設定します。たとえば、hrpdbについてPDB_LOCKDOWNをmediumに設定できますが、salespdbには設定できません。

次の例では、mediumからmedium2プロファイルを作成します。 

CREATE LOCKDOWN PROFILE medium2 FROM medium;

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

4.13.3 PDB_OS_CREDENTIAL初期化パラメータ

データベースがextprocエージェントで外部プロシージャにアクセスする際に、PDB_OS_CREDENTIAL初期化パラメータはPDBからオペレーティング・システムと対話するときに採用されるオペレーティング・システム・ユーザーのIDを決定します。

PDB_OS_CREDENTIAL初期化パラメータの値として指定されている名前の資格証明によって記述されたオペレーティング・システム・ユーザーを使用することで、オペレーティング・システムとの対話を、低い権限のユーザーとして実行できます。このようにして、あるPDBに属するデータを別のPDBに接続しているユーザーからアクセスできないように保護する機能が提供されます。資格証明は、DBMS_CREDENTIALパッケージ内のCREATE_CREDENTIALプロシージャを使用して作成されるオブジェクトです。

通常、Oracleオペレーティング・システム・ユーザーは高い権限を持つユーザーです。オペレーティング・システムの対話にこのアカウントを使用することはお薦めしません。また、異なるPDBからのオペレーティング・システムの対話に同じOSユーザーを使用すると、特定のPDBに属するデータが危険にさらされる可能性があります。

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

4.13.4 PDBロックダウン・プロファイルからメリットを受ける機能

共有IDを使用する機能が、PDBロックダウン・プロファイルからメリットを受けます。

PDBがIDを共有する際、権限が上昇する可能性があります。たとえば、ネットワーク・レベルや、PDBが共通オブジェクトにアクセスする、またはデータベース・リンク経由で接続する際にIDを共有できます。セキュリティを向上するため、CDB管理者はアクセスを区画化することで、ユーザーがPDBで実行可能な操作を制限する場合があります。

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への接続を制限することができます。

  • 管理機能。たとえば、ALTER SYSTEM、ALTER SESSIONおよびALTER DATABASEの使用を制限できます。

  • データベースのオプション。たとえば、ロックダウン・プロファイルを使用して、Oracleのパーティション化やOracle Databaseアドバンスト・キューイングなどのデータベース・オプションへのアクセスを無効にできます。

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

4.13.5 PDBロックダウン・プロファイルの継承

PDBロックダウン・プロファイルには、CDBルート、アプリケーション・ルート、およびこれらに関連付けられているPDB間の継承動作があります。

  • PDBとそれぞれのルートの間の継承パスは次のとおりです。

    • CDB PDBのPDB_LOCKDOWNパラメータ設定は、CDBルートのPDB_LOCKDOWNパラメータ設定より優先されます。同様に、アプリケーションPDBのPDB_LOCKDOWN設定は、アプリケーション・ルートのPDB_LOCKDOWN設定より優先されます。

    • CDB PDB(またはアプリケーションPDB)にPDB_LOCKDOWNパラメータが設定されていない場合、PDBはCDBルート(またはアプリケーション・ルート)のPDB_LOCKDOWNパラメータの設定を継承します。

    • アプリケーション・ルートにPDB_LOCKDOWNパラメータが設定されていない場合、アプリケーション・ルートはCDBルートのPDB_LOCKDOWNパラメータの設定を継承します。

  • CDB PDBまたはアプリケーションPDBのPDB_LOCKDOWNパラメータがCDBロックダウン・プロファイルに設定されている場合、PDBはCDBルートまたはアプリケーション・ルートのPDB_LOCKDOWNパラメータによって設定されているすべてのロックダウン・プロファイルを無視します。

  • PDBロックダウン・パラメータは、自身に最も近い祖先(つまり、アプリケーション・ルートまたはCDBルート)で設定されたCDBロックダウン・プロファイルから取得された無効なルールを含む、アプリケーション・ロックダウン・プロファイルに規定されたルールを継承できます。これは、アプリケーション・ルートまたはCDBルートのPDB_LOCKDOWNパラメータがCDBロックダウン・プロファイルに設定されているときに、アプリケーションPDBのPDB_LOCKDOWNパラメータがアプリケーション・ロックダウン・プロファイルに設定されている場合に適用されます。

  • 場合によっては、CDBロックダウン・プロファイルおよびアプリケーション・ロックダウン・プロファイルを構成するルールの間に競合が発生することがあります。この場合、CDBロックダウン・プロファイルのルールが優先されます。たとえば、CDBロックダウン・プロファイルのOPTION_VALUE句の設定が、アプリケーション・ロックダウン・プロファイルのOPTION_VALUE句の設定よりも優先されます。

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

4.13.6 デフォルトの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での操作の制限

4.13.7 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での操作の制限

4.13.8 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文を実行します。
    たとえば、次の文は、すべてのPDBについてhr_profという名前のロックダウン・プロファイルを有効にします。
    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での操作の制限

4.13.9 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ロックダウン・プロファイルを使用したPDBでの操作の制限

4.14 オブジェクト権限の管理

オブジェクト権限を使用すると、表や索引などのスキーマ・オブジェクトに対するアクションを実行できます。

親トピック: 権限とロール認可の構成

4.14.1 オブジェクト権限について

オブジェクト権限では、特定のスキーマ・オブジェクトに対して特定のアクションを実行する権限を付与します。

各タイプのスキーマ・オブジェクトごとに、異なるオブジェクト権限があります。オブジェクト権限の例には、departments表から行を削除する権限があります。

クラスタ、索引、トリガー、データベース・リンクなど、一部のスキーマ・オブジェクトには、対応付けられたオブジェクト権限がありません。これらのオブジェクトの使用は、システム権限によって決定されます。たとえば、クラスタを変更するには、ユーザーはそのクラスタを所有しているか、またはALTER ANY CLUSTERシステム権限が必要です。

たとえば、次のことをする権利がオブジェクト権限です。

  • エディションの使用

  • 表の更新

  • 他のユーザーの表からの行の選択

  • 他のユーザーのストアド・プロシージャの実行

特定のスキーマ内のすべてのオブジェクトに権限付与を制限する場合は、ユーザーまたはロールにスキーマのスキーマ権限を付与します。スキーマ権限を使用すると、スキーマ内の特定のタイプのオブジェクトすべてに適用される1つの権限付与を実行できます。たとえば、スキーマに対するCREATE ANY TABLE権限の付与により、ユーザーはそのスキーマ内に任意の表を作成できます。

関連トピック

親トピック: オブジェクト権限の管理

4.14.2 オブジェクト権限を付与できるユーザー

ユーザーは、自分のスキーマに含まれているスキーマ・オブジェクトに関しては、すべてのオブジェクト権限が自動的に付与されています。

GRANT ANY OBJECT PRIVILEGEシステム権限があるユーザーは、GRANT文のWITH GRANT OPTION句を使用してもしなくても、指定したオブジェクト権限を別のユーザーに付与できます。また、GRANT ANY OBJECT PRIVILEGE権限を持つユーザーは、その権限を使用して、オブジェクト所有者またはGRANT ANY OBJECT PRIVILEGE権限を持つ他のユーザーによって付与されたオブジェクト権限を取り消すことができます。

権限受領者がGRANT ANY OBJECT PRIVILEGE権限を持っていない場合、またはGRANT文のWITH GRANT OPTION句を使用せずに権限を付与された場合、そのユーザーは権限を他のユーザーに付与できません。

WITH GRANT OPTIONは、ユーザーへのオブジェクト権限の付与でのみ使用できます。ロールへのオブジェクト権限の付与では使用できません。

関連トピック

親トピック: オブジェクト権限の管理

4.14.3 オブジェクト権限の付与と取消し

オブジェクトへの権限の付与およびオブジェクトからの権限の取消しは、ユーザーに直接またはロールを介して行うことができます。

親トピック: オブジェクト権限の管理

4.14.3.1 オブジェクト権限の付与と取消しについて

オブジェクト権限は、ユーザーとロールに対して付与したり、取り消すことができます

オブジェクト権限をロールに付与した場合は、その権限を選択的に使用可能にできます。オブジェクト権限を付与するにはGRANT文を使用し、オブジェクト権限を取り消すにはREVOKE文を使用できます。

4.14.3.2 ALL句がすべての使用可能なオブジェクト権限を付与または取り消すしくみ

オブジェクトの各タイプには異なるオブジェクト権限が対応付けられていますが、これらはALL句で制御できます。

ALL [PRIVILEGES]を指定して、オブジェクトに対するすべての使用可能なオブジェクト権限の付与または取消しが可能です。ALLは権限ではありません。ショートカットのようなもので、つまり1つのGRANT文およびREVOKE文ですべてのオブジェクト権限を付与または取り消すための方法です。すべてのオブジェクト権限がALLショートカットを使用して付与された場合でも、権限を個別に取り消すことができます。

同様に、個別に付与した権限をALLを指定してすべて取り消すこともできます。ただし、REVOKE ALLによって整合性制約が削除される場合(整合性制約は取り消そうとしているREFERENCES権限に依存しているため)は、REVOKE文にCASCADE CONSTRAINTSオプションを指定する必要があります。

例4-6では、CASCADE CONSTRAINTSを使用してHRスキーマ内の注文表に対するすべての権限を取り消しています。

例4-6 CASCADE CONSTRAINTSを使用したすべてのオブジェクト権限の取消し

REVOKE ALL 
 ON ORDERS FROM HR
 CASCADE CONSTRAINTS;

4.14.4 READオブジェクト権限とSELECTオブジェクト権限

READおよびSELECT権限で、異なる層の問合せ権限を付与できます。

親トピック: オブジェクト権限の管理

4.14.4.1 READおよびSELECTオブジェクト権限の管理について

ユーザーにREADまたはSELECTのオブジェクト権限を付与できます。

これらの権限は、ユーザーに許可するアクセス・レベルに応じて付与します。

次のガイドラインに従ってください。

  • ユーザーが表、ビュー、マテリアライズド・ビューまたはシノニムの問合せのみをできるようにする場合、READオブジェクト権限を付与する必要があります。たとえば: 

    GRANT READ ON HR.EMPLOYEES TO psmith;

  • ユーザーが、問合せの実行に加えて次のアクションを実行できるようにする場合、ユーザーにSELECTオブジェクト権限を付与する必要があります。

    • LOCK TABLE table_name IN EXCLUSIVE MODE;

    • SELECT ... FROM table_name FOR UPDATE;

    たとえば:

    GRANT SELECT ON HR.EMPLOYEES TO psmith;

いずれの場合も、ユーザーpsmithはSELECT文を使用して問合せを実行します。

4.14.4.2 データベース内の任意の表を問い合せるためのREADオブジェクト権限の使用のユーザーへの許可

READ ANY TABLEシステム権限で、データベース内の任意の表を問い合せることができるREADオブジェクト権限を付与します。

  • データベース内の任意の表に対するREADオブジェクト権限をユーザーが保持できるようにするには、そのユーザーにREAD ANY TABLEシステム権限を付与します。

たとえば:

GRANT READ ANY TABLE TO psmith;

READオブジェクト権限と同様にREAD ANY TABLEシステム権限では、ユーザーは排他モードで表をロックしたり、更新操作用に表を選択したりできません。反対に、SELECT ANY TABLEシステム権限では、ユーザーは任意の表の問合せ以外に、SELECT ... FOR UPDATE文を使用して表の行をロックしたり、表全体をロックできます。

4.14.4.3 READおよびREAD ANY TABLE権限に対する制限

READ権限とREAD ANY TABLE権限では特別な制限があります。

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

  • READオブジェクト権限は、SQL92_SECURITY標準の要件には影響を及ぼしません。SQL92_SECURITY初期化パラメータがTRUEに設定されている場合、UPDATEまたはDELETE文を実行するためにUPDATEまたはDELETE以外にSELECTオブジェクト権限をユーザーに付与する必要があるという要件が緩和されて、SELECTのかわりにREADで十分であるということにはなりません。

  • Oracle Database Vaultが有効な場合、SQL92_SECURITY初期化パラメータは自動的にTRUEに設定されることに注意してください。したがって、ユーザーにREADオブジェクト権限またはREAD ANY TABLEシステム権限のみが付与されている場合、UPDATEおよびDELETE文は失敗します。この場合、ユーザーにSELECTオブジェクト権限を付与するか、ユーザーが信頼できるユーザーの場合はSELECT ANY TABLEシステム権限を付与する必要があります。

4.14.5 シノニムでのオブジェクト権限の使用

CREATE SYNONYM文で、データベース・オブジェクトのシノニムを作成します。

表、ビュー、順序、演算子、プロシージャ、ストアド・ファンクション、パッケージ、マテリアライズド・ビュー、Javaクラス・スキーマ・オブジェクト、ユーザー定義オブジェクト・タイプのオブジェクトのシノニムに加え、別のシノニムのシノニムを作成できます。

ユーザーにシノニムを使用する権限を付与すると、基礎オブジェクトで付与されたオブジェクト権限は、ユーザーがベース・オブジェクトを名前で参照するかシノニムを使用して参照するかに関係なく適用されます。

たとえば、ユーザーOEが次のシノニムをCUSTOMERS表に作成するとします。 

CREATE SYNONYM customer_syn FOR CUSTOMERS;

それから、OEはcustomer_synシノニムに対するREAD権限をユーザーHRに付与します。 

GRANT READ ON customer_syn TO HR;

ユーザーHRは、次のどちらかの問合せを試みます。 

SELECT COUNT(*) FROM OE.customer_syn;

SELECT COUNT(*) FROM OE.CUSTOMERS;

どちらの問合せも同じ結果になります。

  COUNT(*)
----------
       319

シノニムを他のユーザーに権限付与すると、権限付与はシノニム自体に適用されるのでなく、シノニムが表す基礎オブジェクトに適用されることに注意してください。たとえば、ユーザーHRが自分の権限についてALL_TAB_PRIVSデータ・ディクショナリ・ビューを問い合せると、次のことを知ります。 

SELECT TABLE_SCHEMA, TABLE_NAME, PRIVILEGE 
FROM ALL_TAB_PRIVS 
WHERE TABLE_SCHEMA = 'OE';

TABLE_SCHEMA  TABLE_NAME  PRIVILEGE
------------  ----------  ------------------
OE            CUSTOMER    READ
OE            OE          INHERIT PRIVILEGES

結果にはこのユーザーが、他の権限に加えて、customer_synシノニムの基礎オブジェクト、つまりOE.CUSTOMER表に対するREAD権限を持っていることが示されます。

この時点でユーザーOEがcustomer_synシノニムに対するREAD権限をHRから取り消した場合に、HRが自分の権限を再度調べたときの結果を次に示します。 

TABLE_SCHEMA  TABLE_NAME  PRIVILEGE
------------  ----------  ------------------
OE            OE          INHERIT PRIVILEGES

ユーザーHRは、OE.CUSTOMER表に対するREAD権限を失っています。HRがOE.CUSTOMERS表を問い合せようとすると、次のエラーが表示されます。 

SELECT COUNT(*) FROM OE.CUSTOMERS;

ERROR at line 1:
ORA-00942: table or view does not exist

親トピック: オブジェクト権限の管理

4.14.6 アプリケーション共通オブジェクトの共有

メタデータ・リンク、データ・リンクおよび拡張データ・リンクをアプリケーション・ルートで共有できるように、データベース・オブジェクトを構成できます。

関連トピック

親トピック: オブジェクト権限の管理

4.14.6.1 メタデータリンク・アプリケーション共通オブジェクト

メタデータ・リンクを使用すると、アプリケーション・プラガブル・データベース(PDB)のデータベース・オブジェクトとアプリケーションルートのオブジェクトとの間でメタデータを共有できます。

メタデータ・リンクは、一様に定義されたオブジェクト(オラクル社提供のPL/SQLパッケージなど)について、オブジェクトのメタデータのコピー(PL/SQLパッケージのソース・コードなど)を1つのみ格納するため、ディスクとメモリーの要件を軽減するために役立ちます。これにより、このメタデータへの変更が1つの場所(アプリケーション・ルート)で行われるため、アップグレード操作のパフォーマンスが向上します。

メタデータ・リンクは、アプリケーション・ルートから構成する必要があります。DBMS_PDB.SET_MEDATADATA_LINKED PL/SQLプロシージャを使用すると、データベース・オブジェクトをメタデータ・リンクに変更できます。

次の例は、DBMS_PDB.SET_METADATA_LINKEDプロシージャを使用して、hr_mgrスキーマのupdate_emp_ratingプロシージャをメタデータリンク・アプリケーション共通オブジェクトに変更する方法を示しています。

例4-7 オブジェクトをメタデータリンク・アプリケーション共通オブジェクトに変更する方法

BEGIN
  DBMS_PDB.SET_METADATA_LINKED (
   SCHEMA_NAME => 'hr_mgr',
   OBJECT_NAME => 'update_emp_rating',
   NAMESPACE   => 1);
END;
/

いずれの共通ユーザーもメタデータ・リンクを所有できます。メタデータ・リンクは、作成者がアプリケーション・ルートで所有するアプリケーション共通オブジェクトのメタデータを共有するためにのみ使用できます。

オブジェクトにメタデータ・リンクがあるかどうかを確認するには、DBA_OBJECTSデータ・ディクショナリ・ビューのSHARING列を問い合せます。

4.14.6.2 データリンク・アプリケーション共通オブジェクト

データ・リンクにより、共通オブジェクトの参照と権限を管理します。

データ・リンク(旧称オブジェクト・リンク)は、同じアプリケーション・コンテナに属するアプリケーション・プラガブル・データベース(PDB)からアプリケーション・ルートのオブジェクトに対する参照および権限付与を可能にします。

アプリケーション共通オブジェクトを所有するアプリケーション共通ユーザーがそのオブジェクトへのアクセス権をPDBのユーザーに付与する場合、アプリケーション共通ユーザーはその共通オブジェクトを指すデータ・リンクへの権限を付与することで、これを行うことができます。たとえば、オブジェクト(表、ビュー、クラスタ、順序またはPL/SQLパッケージなど)のデータ・リンクを作成して、この操作を参照するオブジェクトに対する操作(問合せ、DML、EXECUTE文など)が、操作が実行されるコンテナに関係なく、同じオブジェクトに影響することを確認できます。

データ・リンクは、アプリケーション・ルートから構成する必要があります。DBMS_PDB.SET_DATA_LINKED PL/SQLプロシージャを使用すると、データ・リンクを変更できます。既存のオブジェクトをデータ・リンクに変換する場合にのみ、このプロシージャを使用する必要があります。

次の例は、DBMS_PDB.SET_DATA_LINKEDプロシージャを使用して、hr_mgrスキーマのemp_ratings表をデータリンク・アプリケーション共通オブジェクトに変更する方法を示しています。

例4-8 オブジェクトをデータリンク・アプリケーション共通オブジェクトに変更する方法

BEGIN
  DBMS_PDB.SET_DATA_LINKED (
   SCHEMA_NAME => 'hr_mgr',
   OBJECT_NAME => 'emp_ratings',
   NAMESPACE   => 1);
END;
/

いずれの共通ユーザーもデータ・リンクを所有できます。

オブジェクトにデータ・リンクがあるかどうかを確認するには、DBA_OBJECTSデータ・ディクショナリ・ビューのSHARING列を問い合せます。このビューのNAMESPACE列は、ネームスペースの数値を示します。

4.14.6.3 拡張データリンク・アプリケーション共通オブジェクト

拡張データ・リンクで、アプリケーションのプラガブル・データベース(PDB)とアプリケーション・ルートからのデータを組み合せることができます。

拡張データ・リンクは、PDB内の表で見つかったデータと、アプリケーション・ルートの対応する表からのデータを組み合せることができるデータ・リンクです。

拡張データ・リンクは、メタデータ・リンクとデータ・リンクのハイブリッドと考えることができます。アプリケーションPDB内の拡張データリンク・オブジェクトは、アプリケーション・ルート内の拡張データ・リンク・オブジェクトからメタデータを継承します。オブジェクトのデータはアプリケーション・ルートに格納され、オプションで各アプリケーションPDBに格納されます。拡張データ・リンクは、表およびビューに対してのみ作成できます。拡張データ・リンク・オブジェクトのDBA_OBJECTSデータ・ディクショナリ・ビューを問い合せると、このビューは、アプリケーションPDBとアプリケーション・ルートの両方から拡張データ・リンク関連の行を戻します。

拡張データ・リンクは、アプリケーション・ルートから構成する必要があります。DBMS_PDB.SET_EXT_DATA_LINKED PL/SQLプロシージャを使用すると、データベース・オブジェクトを拡張データ・リンクに変更できます。

次の例は、DBMS_PDB.SET_EXT_DATA_LINKEDプロシージャを使用して、hr_mgrスキーマのemp_salariesデータ・ディクショナリ・ビューを拡張データリンク・アプリケーション共通オブジェクトに変更する方法を示しています。

例4-9 オブジェクトを拡張データリンク・アプリケーション共通オブジェクトに変更する方法

BEGIN
  DBMS_PDB.SET_EXT_DATA_LINKED (
   SCHEMA_NAME => 'hr_mgr',
   OBJECT_NAME => 'emp_salaries',
   NAMESPACE   => 1);
END;
/

いずれの共通ユーザーも拡張データ・リンクを所有できます。

オブジェクトに拡張データ・リンクがあるかどうかを確認するには、DBA_OBJECTSデータ・ディクショナリ・ビューのSHARING列を問い合せます。

4.15 Oracle管理スキーマのディクショナリ保護の管理

AUDSYSなどのOracle管理スキーマは、ユーザーがこれらのスキーマのシステム権限を使用できないように、ディクショナリ保護を受けています。

親トピック: 権限とロール認可の構成

4.15.1 Oracle管理スキーマのディクショナリ保護の管理について

デフォルトでは、Oracle管理スキーマはディクショナリ保護を受けていますが、この保護は必要に応じて一時的に削除できます。

スキーマがディクショナリ保護されている場合、スキーマに対するシステム権限が付与されている場合でも、他のユーザーはスキーマに対してシステム権限(ANY権限を含む)を使用できません。ディクショナリ保護されたスキーマに対して使用できるのは、SELECT ANY DICTIONARYおよびANALYZE ANY DICTIONARYシステム権限のみです。ユーザーは、スキーマに対するオブジェクト権限が付与されている場合、引き続きスキーマに対してオブジェクト権限を使用できます。ディクショナリ保護済とマークされているユーザーは、データベースにログインできません。

たとえば、管理者がCREATE USERおよびALTER USERシステム権限を、ユーザーや、データベースへのユーザーの追加およびパスワードの管理を担当するOracle Identity Managerなどのツールに付与するとします。以前のリリースでは、そのアカウントには、SYSDBやSYSKMなど、より高いレベルの権限を持つアカウントのパスワードを設定するのに必要な権限が付与されていました。そのアカウントの悪意のあるユーザーは、SYSKMのパスワードを変更し、新しいパスワードを使用してSYSKMとしてログインし、通常は許可されていない情報にアクセスできます。この機能は、このような攻撃を防ぎます。

ディクショナリ保護されているスキーマを確認するには、次の問合せを実行します。 

SELECT USERNAME, DICTIONARY_PROTECTED FROM DBA_USERS WHERE DICTIONARY_PROTECTED='YES';

ALL_USERSデータ・ディクショナリ・ビューには、DICTIONARY_PROTECTED列もあります。

ほとんどの場合、これらのスキーマではディクショナリ保護を継続できるようにする必要がありますが、必要に応じて、DISABLE DICTIONARY PROTECTION句を指定してALTER USER文を使用すると、ディクショナリ保護を一時的に無効にできます。Oracle管理スキーマのディクショナリ保護を管理できるのは、SYSDBA管理権限を持つユーザーSYSとしてログインしている場合のみです。

次の管理権限の基礎となるスキーマでは、ディクショナリ保護が有効になっています。これらの権限のいずれかを付与されてユーザーがログインすると、そのユーザーは基礎となるスキーマを使用しています。

  • SYSBACKUP
  • SYSKM
  • SYSDG

親トピック: Oracle管理スキーマのディクショナリ保護の管理

4.15.2 Oracle管理スキーマのディクショナリ保護の有効化

Oracle管理スキーマに対してディクショナリ保護を有効にするには、ENABLE DICTIONARY PROTECTION句を指定してALTER USER文を使用します。

  1. SYSDBA管理権限を持つユーザーSYSとして、CDBルートまたはPDBにログインします。
    ユーザー・スキーマにディクショナリ権限を持たせることができるのは、SYSDBAを持つユーザーSYSのみです。
  2. ディクショナリ保護されていないスキーマを確認するには、次のような問合せを実行します。
    SELECT USERNAME, DICTIONARY_PROTECTED FROM DBA_USERS 
WHERE DICTIONARY_PROTECTED = 'NO' ORDER BY USERNAME;
  3. ENABLE DICTIONARY PROTECTION句を指定してALTER USER文を実行します。
    たとえば: 
    ALTER USER AUDSYS ENABLE DICTIONARY PROTECTION;
  4. スキーマが現在、ディクショナリ保護を受けていることを確認します。
    たとえば: 
    SELECT DICTIONARY_PROTECTED FROM DBA_USERS WHERE USERNAME ='AUDSYS';

親トピック: Oracle管理スキーマのディクショナリ保護の管理

4.15.3 Oracle管理スキーマのディクショナリ保護の無効化

Oracle管理スキーマからディクショナリ保護を無効にするには、DISABLE DICTIONARY PROTECTION句を指定してALTER USER文を使用します。

  1. SYSDBA管理権限を持つユーザーSYSとして、CDBルートまたはPDBにログインします。
    ユーザー・スキーマからディクショナリ権限を削除できるのは、SYSDBAを持つユーザーSYSのみです。
  2. DBA_USERSデータ・ディクショナリ・ビューを問い合せて、スキーマがディクショナリ保護を受けているかどうかを確認します。
    たとえば: 
    SELECT DICTIONARY_PROTECTED FROM DBA_USERS 
WHERE USERNAME = 'AUDSYS';

    DICTIONARY_PROTECTEDの出力がYESの場合、スキーマからディクショナリ保護を削除できます。

  3. DISABLE DICTIONARY PROTECTION句を指定してALTER USER文を実行します。
    例: 
    ALTER USER AUDSYS DISABLE DICTIONARY PROTECTION;

親トピック: Oracle管理スキーマのディクショナリ保護の管理

4.16 表権限

表に対するオブジェクト権限は、DMLまたはDDLレベルの操作に対する表セキュリティを実現します。

親トピック: 権限とロール認可の構成

4.16.1 表に対する権限がデータ操作言語操作に与える影響

表およびビューでDELETE、INSERT、SELECTおよびUPDATEの各DML操作を使用する権限を付与できます。

これらの権限は、表のデータの問合せや操作が必要なユーザーとロールに対してのみ付与してください。

表に対するINSERT権限とUPDATE権限は、表の特定の列に制限できます。選択的なINSERT権限を付与されたユーザーは、選択した列に値を持つ行を挿入できます。他のすべての列には、NULLまたはその列のデフォルト値が挿入されます。選択的なUPDATE権限によって、ユーザーは行の特定の列に限ってその値を更新できます。機密データに対するユーザー・アクセスを制限するには、INSERT権限とUPDATE権限を選択的に使用します。

たとえば、データ入力ユーザーにemployees表のsalary列を変更させないようにするには、そのsalary列を除外した選択的なINSERT権限またはUPDATE権限を付与できます。また、salary列を除外したビューによって、同じ制限をさらに高いセキュリティ・レベルで実現できます。

親トピック: 表権限

4.16.2 表に対する権限がデータ定義言語操作に与える影響

ALTER、INDEXおよびREFERENCESの各権限は、表に対するDDL操作の実行を許可します。

これらの権限によって、他のユーザーは表への依存性を変更または作成できるため、権限の付与は控えめに行う必要があります。表に対してDDL操作を実行するユーザーには、さらに他のシステム権限やオブジェクト権限が必要な場合があります。たとえば、表にトリガーを作成するには、その表に対するALTER TABLEオブジェクト権限とCREATE TRIGGERシステム権限の両方が必要です。

INSERT権限やUPDATE権限と同様に、REFERENCES権限は、表の特定の列を対象として付与できます。REFERENCES権限を付与されたユーザーは、付与の対象となった表を、自分の表の中に作成する外部キーの親キーとして使用できます。外部キーの存在によって、親キーに対して実行できるデータ操作と表の変更が制限されるため、このアクションは特殊な権限によって制御されます。列固有のREFERENCES権限によって、権限受領者が使用できるのは、指定された列(この列には、当然、親表の主キーまたは一意キーが最低1つ含まれている)に制限されます。

親トピック: 表権限

4.17 ビューに対する権限

DMLオブジェクト権限は、表の場合と同様にビューに対しても適用できます。

親トピック: 権限とロール認可の構成

4.17.1 ビューの作成に必要な権限

ビューを作成するには、特定の権限が必要です。

ビューに対するオブジェクト権限は、ビューの導出元の実表に影響を与える様々なDML操作を許可します。

ビューを作成する権限は次のとおりです。

  • 次のどちらかのシステム権限が、明示的に、またはロールを介して付与されている必要があります。

    • CREATE VIEWシステム権限(自分のスキーマ内にビューを作成するため)

    • CREATE ANY VIEWシステム権限(別のユーザーのスキーマ内にビューを作成するため)

  • 次のいずれかの権限が明示的に付与されている必要があります。

    • ビューの基礎となるすべてのベース・オブジェクトに対するSELECT、INSERT、UPDATEまたはDELETEオブジェクト権限

    • SELECT ANY TABLE、INSERT ANY TABLE、UPDATE ANY TABLEまたはDELETE ANY TABLEシステム権限

  • さらに、自分のビューへのアクセス権を他のユーザーに付与するためには、ベース・オブジェクトに対するGRANT OPTION句付きのオブジェクト権限、またはADMIN OPTION句付きの適切なシステム権限を持っている必要があります。これらの権限を持っていない場合は、自分のビューに対するアクセス権を他のユーザーに付与できません。試行すると、ORA-01720「object_nameに対するGRANTオプションは存在しません。」エラーが発生します。object_nameはビューの基礎となるオブジェクトを参照しており、ユーザーにはこのオブジェクトに対する十分な権限がありません。

関連トピック

親トピック: ビューに対する権限

4.17.2 他のスキーマのビューを問い合せるための権限

ビューが配置されているスキーマとは異なるスキーマからユーザーがビューを問い合せるには、ビューの実表に対するSELECT WITH GRANT OPTIONがビュー所有者に付与されている必要があります。

親トピック: ビューに対する権限

4.17.3 ビューの使用による表セキュリティの強化

データベース・ビューでは、ユーザーが参照できるデータを制限することによって表セキュリティを強化できます。

ユーザーがビューを使用するには、ビュー自体に対する適切な権限のみが必要であり、ビューの基礎となるオブジェクトに対する権限は不要です。ただし、ビューの基礎となるオブジェクトに対するアクセス権限が削除されると、ユーザーはアクセスできなくなります。

このように動作するのは、ユーザーがビューを問い合せるときに使用されるセキュリティ・ドメインが、そのビューの定義者のセキュリティ・ドメインであるためです。基礎となるオブジェクトに対する権限がビューの定義者によって取り消されると、そのビューは無効になり、いかなるユーザーも使用できなくなります。したがって、ビューに対するアクセス権が付与されているユーザーでも、ビューの基礎となるオブジェクトに対する定義者権限が取り消された場合は、そのビューを使用できません。

たとえば、ユーザーAがビューを作成するとします。ユーザーAは、ビューの基礎となるオブジェクトに対する定義者権限を持っています。この場合、ユーザーAがそのビューに対するSELECT権限をユーザーBに付与すると、ユーザーBがそのビューの問合せを実行できるようになります。ただし、ユーザーAがそのビューの基礎となるオブジェクトにアクセスできなくなった場合は、ユーザーBも同様にアクセスできなくなります。

ビューの場合は、次のように、表に対してさらに2つのセキュリティ・レベル(列レベルと値ベースのセキュリティ)が追加されます。

  • ビューは、実表の中から選択した列へのアクセスを提供できます。たとえば、employees表の中からemployee_id列、last_name列およびmanager_id列のみを表示するようにビューを定義できます。 

    CREATE VIEW employees_manager AS 
    SELECT last_name, employee_id, manager_id FROM employees;

  • ビューでは、表の情報に対して、値ベースのセキュリティを実現できます。ビュー定義でWHERE句を使用すると、実表の中から選択した行のみが表示されます。次の2つの例を考えてみます。 

    CREATE VIEW lowsal AS 
    SELECT * FROM employees 
    WHERE salary < 10000;

    lowsalビューでは、employees表のうち給与値が10000未満のすべての行にアクセスできます。lowsalビューでは、employees表のすべての列にアクセスできることに注目してください。 

    CREATE VIEW own_salary AS 
    SELECT last_name, salary 
    FROM employees 
    WHERE last_name = USER;

    own_salaryビューでは、このビューの現行ユーザーと一致するlast_nameの行のみにアクセスできます。own_salaryビューはuser疑似列を使用しており、この列の値は常に現行ユーザーを指します。このビューは、列レベルのセキュリティと値ベースのセキュリティの両方を兼ね備えています。

親トピック: ビューに対する権限

4.18 プロシージャ権限

EXECUTE権限は、スタンドアロンまたはパッケージ内でのプロシージャまたは関数の実行をユーザーに許可します。

親トピック: 権限とロール認可の構成

4.18.1 プロシージャ権限に対するEXECUTE権限の使用

EXECUTE権限は、注意して処理する必要がある非常に強力な権限です。

スタンドアロン・プロシージャ、ファクションおよびパッケージを含め、プロシージャに対するオブジェクト権限は、EXECUTE権限のみです。

この権限は、プロシージャの実行、または必要なプロシージャをコールする他のプロシージャのコンパイルが必要なユーザーにのみ付与してください。ユーザーに付与された権限を確認するには、DBA_SYS_PRIVSデータ・ディクショナリ・ビューに問い合せます。

親トピック: プロシージャ権限

4.18.2 プロシージャの実行とセキュリティ・ドメイン

プロシージャに対するEXECUTEオブジェクト権限を使用して、そのプロシージャを実行したり、それを参照するプログラム・ユニットをコンパイルできます。

PL/SQLユニットのコール時には、Oracle Databaseによって実行時権限チェックが実行されます。EXECUTE ANY PROCEDUREシステム権限があるユーザーは、データベース内の任意のプロシージャを実行できます。プロシージャの実行権限は、ロールを介してユーザーに付与できます。

関連トピック

親トピック: プロシージャ権限

4.18.3 プロシージャの作成または置換に必要なシステム権限

自分のスキーマ内または別のユーザーのスキーマ内でプロシージャを作成または置換するには、特定の権限が必要です。

自分のスキーマ内でプロシージャを作成または置換するには、CREATE PROCEDUREシステム権限が必要です。別のユーザーのスキーマ内でプロシージャを作成または置換するには、CREATE ANY PROCEDUREシステム権限が必要です。

プロシージャを所有するユーザーには、プロシージャ本体で参照されるスキーマ・オブジェクトに対する権限も必要です。プロシージャを作成するには、そのプロシージャによって参照されるすべてのオブジェクトに対する必要な権限(システム権限やオブジェクト権限)が明示的に付与されている必要があります。これらの必要な権限は、ロールを介して取得することはできません。これには、作成中のプロシージャ内でコールするプロシージャに対するEXECUTE権限も含まれます。

ノート:

トリガーの場合、参照オブジェクトに対する権限をトリガーの所有者に直接付与する必要があります。権限が明示的に、またはロールを介して付与されていても、無名PL/SQLブロックでは任意の権限を使用できます。

親トピック: プロシージャ権限

4.18.4 プロシージャのコンパイルに必要なシステム権限

スタンドアロン・プロシージャとパッケージの一部であるプロシージャの両方をコンパイルするには、特定の権限が必要です。

スタンドアロン・プロシージャをコンパイルするには、COMPILE句を使用してALTER PROCEDURE文を実行する必要があります。パッケージの一部であるプロシージャをコンパイルするには、ALTER PACKAGE文を実行する必要があります。

次の例は、スタンドアロン・プロシージャをコンパイルする方法を示しています。

ALTER PROCEDURE psmith.remove_emp COMPILE;

スタンドアロン・プロシージャまたはパッケージ・プロシージャが別のユーザーのスキーマ内にある場合、プロシージャを再コンパイルするにはALTER ANY PROCEDURE権限が必要です。自分のスキーマ内にあるプロシージャは、権限なしで再コンパイルできます。

親トピック: プロシージャ権限

4.18.5 プロシージャに対する権限がパッケージおよびパッケージ・オブジェクトに与える影響

強力な権限であるEXECUTE権限は、ユーザーがパッケージ内のPUBLICプロシージャやファンクションを実行することを可能にします。

親トピック: プロシージャ権限

4.18.5.1 プロシージャに対する権限がパッケージおよびパッケージ・オブジェクトに与える影響について

パッケージに対するEXECUTEオブジェクト権限は、そのパッケージ内のすべてのプロシージャまたはファンクションに適用されます。

パッケージに対するEXECUTEオブジェクト権限を保持するユーザーは、そのパッケージ内の任意のパブリック・プロシージャまたはファンクションを実行し、任意のパブリック・パッケージ変数の値へのアクセスや変更を実行できます。

パッケージの各構成メンバーに、特定のEXECUTE権限を付与することはできません。したがって、データベース・アプリケーションのプロシージャ、ファンクションおよびパッケージを開発する場合は、セキュリティの確立に関して2つの選択肢を考慮してください。これらの選択肢について、次の例で説明します。

4.18.5.2 例: 1つのパッケージ内で使用されるプロシージャ権限

CREATE PACKAGE BODY文を使用してプロシージャを含むパッケージ本体を作成し、1つのパッケージ内で使用されるプロシージャ権限を管理できます。

例4-10では、2つのパッケージの本体に4つのプロシージャを作成しています。

例4-10 1つのパッケージ内で使用されるプロシージャ権限

CREATE PACKAGE BODY hire_fire AS 
  PROCEDURE hire(...) IS 
    BEGIN 
      INSERT INTO employees . . . 
    END hire; 
  PROCEDURE fire(...) IS 
    BEGIN 
      DELETE FROM employees . . . 
    END fire; 
END hire_fire; 

CREATE PACKAGE BODY raise_bonus AS 
  PROCEDURE give_raise(...) IS 
    BEGIN 
      UPDATE employees SET salary = . . . 
    END give_raise; 
  PROCEDURE give_bonus(...) IS 
    BEGIN 
      UPDATE employees SET bonus = . . . 
    END give_bonus; 
END raise_bonus;

次のGRANT EXECUTE文を発行すると、big_bossesロールとlittle_bossesロールが適切なプロシージャを実行できるようになります。 

GRANT EXECUTE ON hire_fire TO big_bosses; 
GRANT EXECUTE ON raise_bonus TO little_bosses;
4.18.5.3 例: プロシージャ権限およびパッケージ・オブジェクト

CREATE PACKAGE BODY文でプロシージャ定義を含むパッケージ本体を作成し、プロシージャ権限とパッケージ・オブジェクトを管理できます。

例4-11は、単一のパッケージ本体にある4つのプロシージャ定義を示しています。2つの追加スタンドアロン・プロシージャと1つのパッケージが特別に作成され、メイン・パッケージ内に定義されているプロシージャへのアクセスを提供します。

例4-11: プロシージャ権限およびパッケージ・オブジェクト

CREATE PACKAGE BODY employee_changes AS 
  PROCEDURE change_salary(...) IS BEGIN ... END; 
  PROCEDURE change_bonus(...) IS BEGIN ... END; 
  PROCEDURE insert_employee(...) IS BEGIN ... END; 
  PROCEDURE delete_employee(...) IS BEGIN ... END; 
END employee_changes; 
 
CREATE PROCEDURE hire 
  BEGIN 
    employee_changes.insert_employee(...) 
  END hire; 
 
CREATE PROCEDURE fire 
  BEGIN 
    employee_changes.delete_employee(...) 
  END fire; 
 
PACKAGE raise_bonus IS 
  PROCEDURE give_raise(...) AS 
    BEGIN 
      employee_changes.change_salary(...) 
    END give_raise; 
 
  PROCEDURE give_bonus(...) 
    BEGIN 
      employee_changes.change_bonus(...) 
    END give_bonus;

この方法を使用すると、実際に作業を実行するプロシージャ(employee_changesパッケージ内のプロシージャ)が1つのパッケージ内に定義され、宣言されたグローバル変数やカーソルなどを共有できます。トップ・レベルのプロシージャであるhireとfire、および追加のパッケージraise_bonusを宣言することによって、選択的なEXECUTE権限をメイン・パッケージ内のプロシージャに対して付与できます。 

GRANT EXECUTE ON hire, fire TO big_bosses; 
GRANT EXECUTE ON raise_bonus TO little_bosses;

EXECUTE権限をパッケージに対して付与することで、すべてのパッケージ・オブジェクトへの均一なアクセスが提供されることに注意してください。

4.19 タイプ権限

型、メソッドおよびオブジェクトについて、システム権限とオブジェクト権限を制御できます。

親トピック: 権限とロール認可の構成

4.19.1 名前付きの型に対するシステム権限

名前付きの型に対するシステム権限を使用すると、ユーザーは自分のスキーマ内での名前付きの型の作成などのアクションを実行できます。

表4-8に、名前付きの型(オブジェクト型、VARRAYおよびネストした表)に対するシステム権限を示します。

表4-8 名前付きの型に対するシステム権限

権限 許可される操作

CREATE TYPE

名前付きの型を自分のスキーマ内に作成できます。

CREATE ANY TYPE

名前付きの型を任意のスキーマ内に作成できます。

ALTER ANY TYPE

任意のスキーマにある名前付きの型を変更できます。

DROP ANY TYPE

任意のスキーマにある名前付きの型を削除できます。

EXECUTE ANY TYPE

任意のスキーマにある名前付きの型を使用および参照できます。

RESOURCEロールには、CREATE TYPEシステム権限が含まれています。DBAロールには、これらの権限すべてが含まれています。

親トピック: タイプ権限

4.19.2 名前付きの型のオブジェクト権限

名前付きの型に適用されるオブジェクト権限は、EXECUTEのみです。

名前付きの型に対するEXECUTE権限があるユーザーは、その型を使用して次の操作を実行できます。

  • 表の定義

  • リレーショナル表への列の定義

  • 名前付きの型の変数またはパラメータの宣言

EXECUTE権限によって、ユーザーは、型コンストラクタも含めて、その型のメソッドを起動できます。これは、ストアドPL/SQLプロシージャに対するEXECUTE権限と同じです。

親トピック: タイプ権限

4.19.3 名前付きの型のメソッド実行モデル

名前付きの型のメソッド実行は、他のストアドPL/SQLプロシージャと同じです。

ユーザーには、EXECUTE権限など、名前付きの型を使用するための適切な権限が付与されている必要があります。すべての権限付与と同様に、これらの権限は信頼できるユーザーのみに付与してください。ユーザーに付与された権限を確認するには、DBA_SYS_PRIVSデータ・ディクショナリ・ビューに問い合せます。

関連トピック

親トピック: タイプ権限

4.19.4 型の作成と型を使用した表の作成に必要な権限

型を作成するには、適切な権限が必要です。

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

  • 自分のスキーマにタイプを作成するにはCREATE TYPEシステム権限が必要になり、他のユーザーのスキーマにタイプを作成するにはCREATE ANY TYPEシステム権限が必要になります。これらの権限は、明示的にまたはロールを介して取得できます。

  • 型の所有者には、その型の定義内で参照されている他のすべての型にアクセスするためのEXECUTEオブジェクト権限が明示的に付与されているか、EXECUTE ANY TYPEシステム権限が付与されている必要があります。所有者は、ロールを介して必要な権限を取得することはできません。

  • 型の所有者が型へのアクセス権を他のユーザーに付与する場合、その所有者には、参照される型に対するEXECUTE権限(GRANT OPTION付きで指定)またはEXECUTE ANY TYPEシステム権限(ADMIN OPTION付きで指定)が必要です。どちらの権限もない型の所有者は、権限不足のため、型へのアクセス権を他のユーザーに付与できません。

型を使用して表を作成するには、表の作成要件と次の要件を満たす必要があります。

  • 表の所有者には、その表で参照されているすべての型にアクセスするためのEXECUTEオブジェクト権限が直接付与されているか、EXECUTE ANY TYPEシステム権限が付与されている必要があります。これらの権限がロールを介して付与されている場合、所有者は必要な権限を行使できません。

  • 表の所有者が表へのアクセス権を他のユーザーに付与する場合、その所有者には、参照される型に対するEXECUTE権限(GRANT OPTION付きで指定)またはEXECUTE ANY TYPEシステム権限(ADMIN OPTION付きで指定)が必要です。どちらの権限もない表の所有者は、権限不足のため、表へのアクセス権を付与できません。

関連トピック

親トピック: タイプ権限

4.19.5 例: 型の作成と型を使用した表の作成に必要な権限

型に対するEXECUTE権限を他のユーザーに付与するには、GRANT OPTION付きのEXECUTE権限が必要です。

CONNECTロールとRESOURCEロールを持つ次の3名のユーザーが存在するとします。

  • user1

  • user2

  • user3

次のDDLは、user1のスキーマで実行されます。 

CREATE TYPE type1 AS OBJECT (
  attr1 NUMBER);

CREATE TYPE type2 AS OBJECT (
  attr2 NUMBER);

GRANT EXECUTE ON type1 TO user2;
GRANT EXECUTE ON type2 TO user2 WITH GRANT OPTION;

次のDDLは、user2のスキーマで実行されます。 

CREATE TABLE tab1 OF user1.type1;
CREATE TYPE type3 AS OBJECT (
  attr3 user1.type2);
CREATE TABLE tab2 (
  col1 user1.type2);

次の文は、正常に実行されます。user2には、user1.type2に対するGRANT OPTION付きのEXECUTE権限があるためです。

GRANT EXECUTE ON type3 TO user3;
GRANT SELECT ON tab2 TO user3;

ただし、次の権限付与は正しく実行されません。user2には、user1.type1に対するGRANT OPTION付きのEXECUTE権限がないためです。

GRANT SELECT ON tab1 TO user3;

次の文は、user3によって正常に実行されます。 

CREATE TYPE type4 AS OBJECT (
  attr4 user2.type3);
CREATE TABLE tab3 OF type4;

ノート:

CONNECTロールが現在保持している権限は、CREATE SESSIONおよびSET CONTAINER権限のみです。

親トピック: タイプ権限

4.19.6 型アクセスとオブジェクト・アクセスの権限

DML文に対する列レベルと表レベルの既存の権限は、列オブジェクトと行オブジェクトの両方に適用されます。

表4-9に、オブジェクト表に対する権限を示します。

表4-9 オブジェクト表に対する権限

権限 許可される操作

SELECT

オブジェクトとその属性に表からアクセスできます。

UPDATE

表の行を構成するオブジェクトの属性を変更できます。

INSERT

表に新規オブジェクトを作成できます。

DELETE

行を削除できます

同様に、列オブジェクトには表に対する権限と列に対する権限が適用されます。インスタンスの取得のみでは、型情報は明らかになりません。ただし、クライアントは、型インスタンスのイメージを解釈する際に名前付きの型の情報にアクセスする必要があります。クライアントが型情報を要求すると、その型に対するEXECUTE権限がチェックされます。

次のスキーマを考えてみます。

CREATE TYPE emp_type (
    eno NUMBER, ename CHAR(31), eaddr addr_t);
CREATE TABLE emp OF emp_t;

さらに、次の2つの問合せについて考えます。

SELECT VALUE(emp) FROM emp;
SELECT eno, ename FROM emp;

どちらの問合せの場合も、Oracle Databaseは、emp表に対するユーザーのSELECT権限をチェックします。最初の問合せの場合、ユーザーは、emp_typeの型情報を取得してデータを解釈する必要があります。問合せによってemp_type型がアクセスされると、ユーザーのEXECUTE権限がチェックされます。

ただし、2番目の問合せでは、名前付きの型が含まれていないため、型の権限はチェックされません。

さらに、user3は、前の項のスキーマを使用して次の問合せを実行できます。 

SELECT tab1.col1.attr2 FROM user2.tab1 tab1;
SELECT attr4.attr3.attr2 FROM tab3;

どちらのSELECT文でも、user3には基礎となる型に対する明示的な権限がありませんが、文には成功することに注意してください。これは、型の所有者と表の所有者に、GRANT OPTIONを備えた必要な権限があるためです。

Oracle Databaseは、次のイベントに対する権限をチェックし、アクションに対する権限がクライアントにない場合はエラーを戻します。

  • オブジェクトのREF値を使用してオブジェクト・キャッシュ内でオブジェクトを確保すると、Oracle Databaseは、そのオブジェクトが含まれているオブジェクト表に対するSELECT権限をチェックします。

  • 既存のオブジェクトを修正したり、オブジェクト・キャッシュからオブジェクトをフラッシュしたりすると、Oracle Databaseは目的のオブジェクト表に対するUPDATE権限をチェックします。

  • 新しいオブジェクトをフラッシュすると、Oracle Databaseは目的のオブジェクト表に対するINSERT権限をチェックします。

  • オブジェクトを削除すると、Oracle Databaseは目的の表に対するDELETE権限をチェックします。

  • 名前付きの型のオブジェクトを確保すると、そのオブジェクトに対するEXECUTE権限がチェックされます。

クライアントの第三世代言語アプリケーションのオブジェクトの属性を変更すると、Oracle Databaseでオブジェクト全体の更新が行われます。そのため、ユーザーにはオブジェクト表に対するUPDATE権限が必要になります。オブジェクト表の特定列に対してのみUPDATE権限を持つことは、アプリケーションがこれらの列に対応した属性のみ変更する場合でも、十分とはいえません。そのため、Oracle Databaseではオブジェクト表の列レベルの権限をサポートしていません。

親トピック: タイプ権限

4.19.7 型の依存性

プロシージャや表などのストアド・オブジェクトと同様に、他のオブジェクトから参照される型を依存性があると呼びます。

表が依存する型については、特殊な問題点がいくつかあります。表には、アクセス用の型定義に依存するデータが含まれているため、その型を変更すると、格納されているすべてのデータにアクセスできなくなります。変更によってこのような結果になるのは、型を使用するために必要な権限が取り消された場合や、型または依存型が削除された場合です。いずれかのアクションが発生すると、表は無効になり、アクセスできなくなります。

必要な権限が再び付与されると、権限がないために無効になった表は自動的に有効になり、アクセスできるようになります。依存型が削除されたことで無効になった表は、アクセス不能のままで、実行できるアクションは表の削除のみです。

型に対する権限の取消しや型の削除は重大な影響があるため、デフォルトでは、SQL文のREVOKEとDROP TYPEは限定されたセマンティクスで実装されます。つまり、どちらの文でも、名前付きの型が表または型に依存している場合は、エラーが戻されて文は取り消されます。ただし、どちらの文も、FORCE句を使用すると常に正常終了します。依存する表がある場合、その表は無効になります。

親トピック: タイプ権限

4.20 ユーザーへの権限とロールの付与

GRANT文は、プロシージャの実行など、特定のアクションを実行する権限をユーザーに付与します。

親トピック: 権限とロール認可の構成

4.20.1 ユーザーおよびロールへのシステム権限とロールの付与

システム権限とロールをユーザーやロールに付与する前に、これらのタイプの付与に対して権限がどのように機能するかについて注意してください。

親トピック: ユーザーへの権限とロールの付与

4.20.1.1 ユーザーおよびロールへのシステム権限とロールの付与のための権限

システム権限とロールを他のユーザーやロールに付与するには、GRANT SQL文を使用します。

次の権限が必要です。

  • システム権限を付与するには、ユーザーにADMINオプション付きのシステム権限またはGRANT ANY PRIVILEGEシステム権限が付与されている必要があります。

  • ロールを付与するには、ユーザーにADMINオプション付きのロールまたはGRANT ANY ROLEシステム権限が付与されている必要があります。

ノート:

オブジェクト権限は、同じGRANT文でシステム権限やロールと同時に付与することはできません。

4.20.1.2 例: ユーザーへのシステム権限とロールの付与

システム権限とロールをユーザーに付与するには、GRANT文を使用できます。

例4-12では、システム権限CREATE SESSIONとaccts_payロールをユーザーjwardに付与しています。

例4-12 ユーザーへのシステム権限とロールの付与

GRANT CREATE SESSION, accts_pay TO jward;
4.20.1.3 例: ディレクトリ・オブジェクトに対するEXECUTE権限の付与

ディレクトリ・オブジェクトに対するEXECUTE権限を付与するには、GRANT文を使用できます。

例4-12 では、exec_dirディレクトリ・オブジェクトに対するEXECUTE権限をユーザーjwardに付与しています。

例4-13 ディレクトリ・オブジェクトに対するEXECUTE権限の付与

GRANT EXECUTE ON DIRECTORY exec_dir TO jward;
4.20.1.4 権限受領ユーザーによる権限付与を可能にするADMINオプションの使用

WITH ADMIN OPTION句を使用して、権限付与の能力を拡張できます。

これらの機能は次のとおりです。

  • 権限受領者は、データベース内の他のユーザーまたはロールに対して、システム権限またはロールの付与または取消しができます。ただし、自分自身からロールを取り消すことはできません。

  • 権限受領者は、ADMINオプション付きのシステム権限やロールを付与できます。

  • ロールの権限受領者は、そのロールを変更または削除できます。

例4-14では、new_dbaロールをWITH ADMIN OPTION句付きでユーザーmichaelに付与しています。

例4-14 ADMINオプションの付与

GRANT new_dba TO michael WITH ADMIN OPTION;

ユーザーmichaelは、new_dbaロール内の権限をすべて暗黙的に使用できることに加え、必要に応じてnew_dbaロールを付与、取消および削除することもできます。このように、ADMINオプションは非常に強力な機能であるため、このオプションを付けてシステム権限やロールを付与する際は、十分に注意してください。通常、これらの権限はセキュリティ管理者向けに用意されており、システム内の他の管理者やユーザーに付与することはほとんどありません。ユーザーがロールを作成すると、そのロールは自動的にADMINオプション付きでその作成ユーザーに付与されることに注意してください。

4.20.1.5 GRANT文を使用した新規ユーザーの作成

1つのGRANT SQL文で、新規ユーザーを作成してこのユーザーに権限を付与できます。

ほとんどの場合、ユーザーにCREATE SESSION権限を付与します。

  • GRANT文を使用して新規ユーザーを作成するには、権限およびIDENTIFIED BY句を含めます。

たとえば、新規ユーザーとしてpsmithを作成し、CREATE SESSIONシステム権限をpsmithに付与する方法は、次のとおりです。 

GRANT CREATE SESSION TO psmith IDENTIFIED BY password;

IDENTIFIED BY句を使用してパスワードを指定することで、ユーザー名がデータベースに存在しない場合も、指定したユーザー名とパスワードで新しいユーザーが作成されます。

4.20.2 ユーザーおよびロールへのオブジェクト権限の付与

ユーザーおよびロールにオブジェクト権限を付与できるほか、権限受領者が他のユーザーにその権限を付与することを許可できます。

親トピック: ユーザーへの権限とロールの付与

4.20.2.1 ユーザーおよびロールへのオブジェクト権限の付与について

GRANT文を使用すると、ロールとユーザーにオブジェクト権限を付与できます。

オブジェクト権限を付与するには、次のいずれかの条件を満たしている必要があります。

  • 指定するオブジェクトを所有している。

  • GRANT ANY OBJECT PRIVILEGEシステム権限を付与されている。この権限を使用すると、オブジェクト所有者のかわりに権限の付与と取消しを実行できます。

  • オブジェクト権限が付与されるときに、WITH GRANT OPTION句が指定されている。

    ノート:

    同じGRANT文で、オブジェクト権限とともにシステム権限とロールを付与することはできません。

次の例では、emp表のすべての列に対するREAD、INSERTおよびDELETEのオブジェクト権限をユーザーjfeeとtsmithに付与しています。 

GRANT READ, INSERT, DELETE ON emp TO jfee, tsmith;

salaryビューのすべてのオブジェクト権限をユーザーjfeeに付与するには、次の例のようにALLキーワードを使用します。 

GRANT ALL ON salary TO jfee;

ノート:

権限受領者は、最初の権限付与にGRANT OPTIONが含まれていないかぎり、オブジェクトへのアクセス権を再度付与することはできません。したがって、前述の例では、jfeeはGRANT文を使用してオブジェクト権限を他の誰かに付与することができません。

4.20.2.2 WITH GRANT OPTION句が機能するしくみ

GRANT文でWITH GRANT OPTION句を使用すると、権限受領者はオブジェクト権限を他のユーザーに付与できるようになります。

スキーマ内にオブジェクトを格納しているユーザーには、関連するすべてのオブジェクト権限がWITH GRANT OPTION句付きで自動的に付与されます。この特別な権限によって、権限受領者の権限は次のように拡張されます。

  • 権限受領者は、データベース内の任意のユーザーにGRANT OPTIONの有無を問わずオブジェクト権限を付与でき、そしてデータベース内の任意のロールに付与できます。

  • 次の2つの条件が成立する場合、権限受領者は表に対するビューを作成し、そのビューの対応する権限をデータベース内の任意のユーザーまたはロールに対して付与できます。

    • 権限受領者が、表に対するGRANT OPTION付きのオブジェクト権限を受領している。

    • 権限受領者に、CREATE VIEWまたはCREATE ANY VIEWシステム権限がある。

ノート:

オブジェクト権限をロールに付与する場合、WITH GRANT OPTION句は無効です。Oracle Databaseでは、ロールによるオブジェクト権限の伝播を禁止しているため、ロールの権限受領者は、ロールを介して受領したオブジェクト権限を他に伝播することはできません。

4.20.2.3 オブジェクト所有者にかわるオブジェクト権限の付与

GRANT ANY OBJECT PRIVILEGEシステム権限を持つユーザーは、オブジェクト所有者のかわりに、すべてのオブジェクト権限の付与と取消しを実行できます。

この権限によって、データベース管理者やアプリケーション管理者は、スキーマに接続せずにスキーマ内のオブジェクトへのアクセス権を付与できます。この権限を持つスキーマ所有者のログイン資格証明はメンテナンスする必要がなく、構成時に必要な接続数が減少します。

このシステム権限はOracle Databaseに用意されているDBAロールに付属しているため、AS SYSDBAで接続するユーザー(ユーザーSYS)に(ADMIN option付きで)付与されます。他のシステム権限と同様に、GRANT ANY OBJECT PRIVILEGEシステム権限を付与できるのは、ADMIN option権限を持っているユーザーのみです。

オブジェクトに対するアクセス権の記録された権限付与者は、オブジェクト所有者とGRANT ANY OBJECT PRIVILEGEシステム権限を行使している個人のどちらかです。GRANT ANY OBJECT PRIVILEGEがある権限付与者にGRANT OPTION付きのオブジェクト権限がない場合、オブジェクト所有者が権限付与者として表示されます。権限付与者がGRANT OPTION付きのオブジェクト権限を持っている場合は、その権限付与者が付与者として記録されます。

ノート:

GRANT文によって生成された監査レコードには、常に権限付与を実際に実行したユーザーが示されます。

たとえば、次の使用例を考えてみます。ユーザーadamsにGRANT ANY OBJECT PRIVILEGEシステム権限があります。他の付与権限は所持していません。ユーザーadamsが次の文を発行します。 

GRANT SELECT ON HR.EMPLOYEES TO blake WITH GRANT OPTION;

DBA_TAB_PRIVSビューを調べると、HRが権限付与者として表示されていることがわかります。 

SELECT GRANTEE, GRANTOR, PRIVILEGE, GRANTABLE
  FROM DBA_TAB_PRIVS 
  WHERE TABLE_NAME = 'EMPLOYEES' and OWNER = 'HR';

GRANTEE  GRANTOR PRIVILEGE    GRANTABLE
-------- ------- -----------  ----------
BLAKE    HR       SELECT      YES

ここで、ユーザーblakeにもGRANT ANY OBJECT PRIVILEGEシステム権限があると想定します。このユーザーが次の文を発行します。 

GRANT SELECT ON HR.EMPLOYEES TO clark;

この場合は、DBA_TAB_PRIVSビューを再び問い合せると、blakeが権限付与者として表示されます。 

GRANTEE  GRANTOR  PRIVILEGE  GRANTABLE
-------- -------- ---------  ----------
BLAKE    HR       SELECT     YES       
CLARK    BLAKE    SELECT     NO

これは、blakeがすでにHR.EMPLOYEESに対してGRANT OPTION付きのSELECT権限を持っているためです。

4.20.2.4 列に対する権限の付与

表の個々の列に対してINSERT、UPDATEまたはREFERENCES権限を付与できます。

ノート:

列固有のINSERT権限を付与する前に、NOT NULL制約が定義されている列が表に含まれているかどうかを確認してください。挿入できる列を選んで権限を付与したときにNOT NULL列が抜けていると、ユーザーは表に行を挿入できません。このような状況を回避するには、各NOT NULL列が挿入可能であること、またはNULL以外のデフォルト値があることを確認してください。そうでない場合、権限受領者は表に行を挿入できず、エラーが発生します。

次の文は、accounts表のacct_no列に対するINSERT権限をpsmithに付与しています。 

GRANT INSERT (acct_no) ON accounts TO psmith;

次の例では、emp表のenameおよびjob列に対するオブジェクト権限が、ユーザーjfeeおよびtsmithに付与されます。 

GRANT INSERT(ename, job) ON emp TO jfee, tsmith;
4.20.2.5 行レベルのアクセス制御

行レベルで、つまりオブジェクト内でアクセスを制御できますが、GRANT文で行うことはできません。

このタイプのアクセス制御を実行するには、Oracle Virtual Private Database (VPD)またはOracle Label Security (OLS)のいずれかを使用する必要があります。

4.21 ユーザーからの権限とロールの取消し

システムまたはオブジェクトの権限を取り消す場合は、権限の取消しによる連鎖的な影響に注意してください。

  • システム権限とロールの取消し
    REVOKE SQL文で、システム権限およびロールを取り消します。
  • オブジェクト権限の取消し
    複数のオブジェクト権限、オブジェクト所有者のかわりに付与したオブジェクト権限、列を選択するオブジェクト権限、およびREFERENCESオブジェクト権限を取り消すことができます。
  • 権限の取消しによる連鎖的な影響
    DDL操作に関連するオブジェクト権限の取消しでは連鎖的な影響はありませんが、オブジェクト権限の取消しに関する連鎖的な影響はあります。

親トピック: 権限とロール認可の構成

4.21.1 システム権限とロールの取消し

REVOKE SQL文で、システム権限およびロールを取り消します。

ADMINオプション付きでシステム権限またはロールを付与されているユーザーは、他のデータベース・ユーザーまたはロールから権限またはロールを取り消すことができます。取消しを行うユーザーは、権限やロールを最初に付与したユーザーでなくてもかまいません。GRANT ANY ROLEがあるユーザーは、任意のロールを取り消すことができます。

例4-15は、CREATE TABLEシステム権限とaccts_recロールをユーザーpsmithから取り消します。

例4-15 ユーザーからのシステム権限とロールの取消し

REVOKE CREATE TABLE, accts_rec FROM psmith;

システム権限またはロールのADMINオプションを選択的に取り消すことはできないことに注意してください。権限またはロールを取り消してから、同じ権限またはロールをADMINオプションを指定せずに再度付与する必要があります。

親トピック: ユーザーからの権限とロールの取消し

4.21.2 オブジェクト権限の取消し

複数のオブジェクト権限、オブジェクト所有者のかわりに付与したオブジェクト権限、列を選択するオブジェクト権限、およびREFERENCESオブジェクト権限を取り消すことができます。

親トピック: ユーザーからの権限とロールの取消し

4.21.2.1 オブジェクト権限の取消しについて

オブジェクト権限を取り消す場合、ユーザーは一定の要件を満たしている必要があります。

次のいずれかの条件を満たしている必要があります。

  • 以前にユーザーまたはロールにオブジェクト権限を付与している。

  • オブジェクト所有者のかわりに権限を付与したり取り消すことができるGRANT ANY OBJECT PRIVILEGEシステム権限を所持している。

取り消すことができるのは、権限付与者として自身で直接認可した権限のみです。GRANT OPTIONを付与した他のユーザーによる権限付与を取り消すことはできません。ただし、連鎖的な影響があります。権限付与者のオブジェクト権限を取り消すと、GRANT OPTIONを使用して伝播されたオブジェクト権限も取り消されます。

4.21.2.2 複数のオブジェクト権限の取消し

REVOKE文で、1つのオブジェクトに対する複数の権限を取り消すことができます。

最初の権限付与者が次の文を発行すると、ユーザーjfeeとpsmithからemp表のSELECT権限とINSERT権限が取り消されます。 

REVOKE SELECT, INSERT ON emp FROM jfee, psmith;

次の文は、最初にhuman_resourceロールに付与したdept表に対するすべてのオブジェクト権限を取り消します。 

REVOKE ALL ON dept FROM human_resources;

ノート:

オブジェクト権限のGRANT OPTIONを選択的に取り消すことはできません。オブジェクト権限を取り消してから、同じ権限をGRANT OPTIONを指定せずに再度付与する必要があります。ユーザーが自分自身からオブジェクト権限を取り消すことはできません。

4.21.2.3 オブジェクト所有者にかわるオブジェクト権限の取消し

GRANT ANY OBJECT PRIVILEGEシステム権限を使用して、オブジェクト所有者が権限付与者であるオブジェクト権限を取り消すことができます。

この操作を実行できるのは、オブジェクト所有者によって、または所有者のかわりにGRANT ANY OBJECT PRIVILEGEシステム権限を持つユーザーによって、オブジェクト権限が付与されている場合です。

オブジェクト権限が、オブジェクト所有者とREVOKE文を実行するユーザー(特定のオブジェクト権限とGRANT ANY OBJECT PRIVILEGEシステム権限の両方を持つユーザー)の両方によって付与されている場合は、REVOKE文を発行したユーザーによって付与されたオブジェクト権限のみが取り消されます。これは、オブジェクト所有者にかわって行われたオブジェクト権限の付与の前に示した例を続行することで説明できます。

ここでは、blakeがHR.EMPLOYEESに対するSELECT権限をclarkに付与しているとします。blakeはGRANT ANY OBJECT PRIVILEGEシステム権限を所有していますが、特定のオブジェクト権限も保有しているため、この付与はblakeに帰属します。ここでは、ユーザーHRもHR.EMPLOYEESに対するSELECT権限をユーザーclarkに付与しているとします。DBA_TAB_PRIVSビューの問合せでは、HR.EMPLOYEES表について次の権限付与が有効であることが表示されています。 

GRANTEE  GRANTOR PRIVILEGE    GRANTABLE
-------- ------- -----------  ----------
BLAKE    HR       SELECT       YES       
CLARK    BLAKE    SELECT       NO        
CLARK    HR       SELECT       NO

ユーザーblakeが次のREVOKE文を発行します。 

REVOKE  SELECT ON HR.EMPLOYEES FROM clark;

ユーザーblakeがユーザーclarkに付与したオブジェクト権限のみが削除されます。オブジェクト所有者HRによる権限付与はそのまま残ります。 

GRANTEE  GRANTOR PRIVILEGE    GRANTABLE
-------- ------- -----------  ----------
BLAKE    HR       SELECT      YES       
CLARK    HR       SELECT      NO

blakeが再度REVOKE文を発行すると、今度は(HRのかわりに)adamsがGRANT ANY OBEJCT PRIVILEGEシステム権限を使用して付与したオブジェクト権限が削除されます。

4.21.2.4 列を選択するオブジェクト権限の取消し

列固有操作に対するGRANTおよびREVOKE操作には異なる権限と制約があります。

表やビューの列を指定してINSERT、UPDATEおよびREFERENCES権限を付与することは可能ですが、同じようなREVOKE文を使用して、列固有の権限を選択的に取り消すことはできません。かわりに、権限付与者は表またはビューの全列に対するオブジェクト権限を取り消してから、残しておく列固有の権限を選択的に再度付与する必要があります。

たとえば、human_resourcesロールには、dept表のdeptno列およびdname列に対するUPDATE権限が付与されているとします。このUPDATE権限をdeptno列のみから取り消すには、次の2つの文を発行します。 

REVOKE UPDATE ON dept FROM human_resources;
GRANT UPDATE (dname) ON dept TO human_resources;

このREVOKE文によって、ロールhuman_resourcesからdept表の全列に対するUPDATE権限が取り消されます。次にGRANT文によって、human_resourcesロールに対して、dname列のUPDATE権限の付与がやりなおし、リストアまたは再発行されます。

4.21.2.5 REFERENCESオブジェクト権限の取消し

REFERENCESオブジェクト権限を取り消すと、外部キー制約に影響を与えます。

REFERENCESオブジェクト権限の権限受領者がその権限を使用して外部キー制約を作成し、その制約が現在も存在している場合、権限付与者がその権限を取り消すには、REVOKE文にCASCADE CONSTRAINTSオプションを指定します。

例:

REVOKE REFERENCES ON dept FROM jward CASCADE CONSTRAINTS;

CASCADE CONSTRAINTS句を指定すると、取り消されるREFERENCES権限を使用して現在も定義されている外部キー制約が削除されます。

4.21.3 権限の取消しによる連鎖的な影響

DDL操作に関連するオブジェクト権限の取消しではカスケード効果はありませんが、オブジェクト権限の取消しに関するカスケード効果はあります。

親トピック: ユーザーからの権限とロールの取消し

4.21.3.1 システム権限の取消しによる連鎖的な影響

DDL操作に関連するシステム権限を取り消したときには連鎖的な影響は発生しません。

これは、権限がADMINオプションとともに付与されたかどうかとは関係ありません。

たとえば、次のような場合を考えてみます。

  1. セキュリティ管理者が、ADMIN optionを指定して、ユーザーjfeeにCREATE TABLEシステム権限を付与します。

  2. ユーザーjfeeが表を作成します。

  3. ユーザーjfeeが、ユーザーtsmithにCREATE TABLEシステム権限を付与します。

  4. ユーザーtsmithが表を作成します。

  5. セキュリティ管理者が、ユーザーjfeeからCREATE TABLEシステム権限を取り消します。

  6. ユーザーjfeeが作成した表はそのまま残ります。ユーザーtsmithの表とCREATE TABLEシステム権限はそのまま残ります。

連鎖的な影響は、DML操作に関連するシステム権限を取り消したときに発生する場合があります。ユーザーのSELECT ANY TABLE権限を取り消すと、そのユーザーのスキーマ内に存在し、この権限に依存しているすべてのプロシージャは、権限が再度認可されないかぎり、正常に実行できなくなります。

4.21.3.2 オブジェクト権限の取消しによる連鎖的な影響

オブジェクト権限を取り消すと、連鎖的な影響が発生する場合があります。

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

  • DMLオブジェクト権限を取り消すと、そのDMLオブジェクト権限に依存するオブジェクト定義にまで影響が及ぶ可能性があります。たとえば、testプロシージャの本体に、emp表のデータを問い合せるSQL文が記述されているとします。testプロシージャの所有者からemp表のSELECT権限を取り消すと、それ以降そのプロシージャを正常に実行できなくなります。

  • 表に対するREFERENCES権限をユーザーから取り消すと、そのユーザーが定義した外部キー整合性制約の中で、取り消されたREFERENCES権限を必要とする制約が自動的に削除されます。たとえば、ユーザーjwardにdept表のdeptno列に対するREFERENCES権限が付与されているとします。このユーザーが、emp表のdeptno列に、dept表のdeptno列を参照する外部キーを作成します。dept表のdeptno列に対するREFERENCES権限を取り消すと、同じ操作でemp表のdeptno列に対する外部キー制約も削除されます。

  • GRANT OPTIONを使用して伝播されたオブジェクト権限付与は、権限付与者のオブジェクト権限が取り消されると取り消されます。たとえば、GRANT OPTION付きのemp表に対するSELECTオブジェクト権限を付与されているuser1が、user2に対してemp表に対するSELECT権限を付与したとします。その後、user1からSELECT権限を取り消します。このREVOKE文はuser2にも連鎖します。user1とuser2の取り消されたSELECT権限に依存するオブジェクトもすべて、前述のように影響を受ける可能性があります。

ALTERまたはINDEXオブジェクト権限を取り消しても、ALTERおよびINDEX DDLの各オブジェクト権限を必要とするオブジェクト定義には影響を与えません。たとえば、別のユーザーに属する表に索引を作成したユーザーからINDEX権限を取り消しても、その索引はそのまま残ります。

4.22 PUBLICロールに対する権限の付与と取消し

ロールPUBLICに対して、権限とロールの付与および取消しを実行できます。

PUBLICにはすべてのデータベース・ユーザーがアクセスできるため、PUBLICに対して付与されたすべての権限またはロールには、すべてのデータベース・ユーザーがアクセスできます。デフォルトでは、PUBLICは付与される権限がありません。

セキュリティ管理者とデータベース・ユーザーは、すべてのデータベース・ユーザーが権限またはロールを必要としている場合のみ、PUBLICに権限またはロールを付与してください。これによって、各データベース・ユーザーには常に、現在のグループ・タスクの正常実行に必要な権限のみが付与されているという一般規則が保証されます。

PUBLICロールから権限を取り消すと、かなりの規模で影響が連鎖する可能性があります。DML操作に関連する任意の権限をPUBLICから取り消すと(たとえばSELECT ANY TABLEまたはUPDATE ON emp)、データベース内のファンクションとパッケージを含むすべてのプロシージャが再認可されるまで再び使用できなくなります。したがって、DMLに関連する権限をPUBLICに付与したり、取り消す場合には注意が必要です。

関連トピック

親トピック: 権限とロール認可の構成

4.23 オペレーティング・システムまたはネットワークを使用したロールの付与

オペレーティング・システムまたはネットワークを使用してロールを管理すると、大規模エンタープライズでのロールの一元管理が容易になります。

親トピック: 権限とロール認可の構成

4.23.1 オペレーティング・システムまたはネットワークを使用したロールの付与について

Oracle Databaseを実行するオペレーティング・システムを使用して、接続時にロールをユーザーに付与できます。

この機能を使用することでセキュリティ管理者は、ユーザーのデータベース・ロールをGRANT文やREVOKE文を使用して明示的に付与したり取り消したりする必要がなくなります。

つまり、オペレーティング・システムを使用してロールを管理し、ユーザーのセッション作成時にOracle Databaseにそのロールを渡すことができます。このメカニズムの一部として、ユーザーのデフォルト・ロールや、ADMINオプション付きでユーザーに付与するロールを識別できます。オペレーティング・システムを使用してロールを使用するユーザーを認可する場合は、必ずすべてのロールをデータベース内に作成し、GRANT文を使用してそのロールに権限を割り当てる必要があります。

ロールは、ネットワーク・サービスを介しても付与できます。

ユーザーのデータベース・ロールを識別するためにオペレーティング・システムを使用する方法の利点は、Oracleデータベースの権限管理をデータベースの外部で実施できることです。オペレーティング・システムに組み込まれたセキュリティ機能によって、ユーザーの権限が制御されます。また、このオプションを使用すると、いくつかのシステム・アクティビティのセキュリティを集中管理できるため、次のような状況で役立ちます。

  • MVS版Oracleの管理者が、データベース・ユーザーのロールを識別するためにRACFグループを使用する場合

  • UNIX版Oracleの管理者が、データベース・ユーザーのロールを識別するためにUNIXグループを使用する場合

  • VMS版Oracleの管理者が、データベース・ユーザーのロールを識別するために権限識別子を使用する場合

ユーザーのデータベース・ロールを識別するためにオペレーティング・システムを使用する方法の主なデメリットは、権限管理がロール・レベルでしか実施できないことです。個々の権限は、オペレーティング・システムを使用して付与することはできません。ただし、GRANT文を使用してデータベース内で付与することは可能です。

この機能を使用する際の第2のデメリットは、オペレーティング・システムがロールを管理している場合に、デフォルトではユーザーが共有サーバーまたはその他のネットワーク接続を介してデータベースに接続できないことです。ただし、このデフォルトは変更できます。

データベース管理者のオペレーティング・システム認証を使用できるのは、CDBルートの場合のみです。PDB、アプリケーション・ルートおよびアプリケーションPDBには使用できません。

ノート:

この項で説明されている機能は、一部のオペレーティング・システムでしか使用できません。これらの機能が使用できるかどうかを確認するには、使用しているオペレーティング・システム固有のOracle Databaseマニュアルを参照してください。

関連トピック

親トピック: オペレーティング・システムまたはネットワークを使用したロールの付与

4.23.2 オペレーティング・システムのロール識別機能

OS_ROLES初期化パラメータを使用して、オペレーティング・システムがロールをどのように識別するかを制御できます。

セッションの作成時に、データベースがオペレーティング・システムを使用して各ユーザーのデータベース・ロールを識別するように、初期化パラメータOS_ROLESをTRUEに設定します。

インスタンスが現在稼働している場合、そのインスタンスを再起動する必要があります。ユーザーがデータベースとのセッションを作成しようとすると、Oracle Databaseはオペレーティング・システムによって識別されるデータベース・ロールを使用して、そのユーザーのセキュリティ・ドメインを初期化します。

ユーザーのデータベース・ロールを識別するためには、各Oracle Databaseユーザーのオペレーティング・システム・アカウントが、どのデータベース・ロールをユーザーが使用できるようになるかを示すオペレーティング・システム識別子(これらはグループ、権限識別子、または他の類似した名前で呼ばれる場合があります)を持っている必要があります。ロールの指定は、どのロールがユーザーのデフォルト・ロールであるか、どのロールがADMINオプションで使用可能かを示すことも可能です。どのオペレーティング・システムを使用している場合も、オペレーティング・システム・レベルでのロールの指定は次の形式になります。 

ora_ID_ROLE[[_d][_a][_da]]

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

  • IDの定義は、オペレーティング・システムが異なると変わります。たとえばVMSでは、IDはデータベースのインスタンス識別子、VMSではコンピュータ・タイプ、UNIXではシステムIDです。

    IDは、ORACLE_SIDと照合する際に大/小文字が区別されます。ROLEでは、大/小文字は区別されません。

  • ROLEは、データベース・ロールの名前です。

  • dは、このロールがデータベース・ユーザーのデフォルト・ロールであることを示すオプション文字です。

  • aは、このロールがADMINオプション付きでユーザーに付与されることを示すオプション文字です。このオプション文字を指定することによって、ユーザーはこのロールを他のロールにのみ付与できるようになります。オペレーティング・システムを使用してロールを管理している場合は、ユーザーにロールを付与できません。

    dまたはaのいずれかを指定する場合は、その文字の直前にアンダースコア(_)を指定してください。

たとえば、オペレーティング・システム・アカウントが、プロファイルで識別される次のロールを持っているとします。

ora_PAYROLL_ROLE1
ora_PAYROLL_ROLE2_a
ora_PAYROLL_ROLE3_d
ora_PAYROLL_ROLE4_da

対応するユーザーがOracle Databaseのpayrollインスタンスに接続すると、role3とrole4がデフォルト・ロールになり、role2とrole4がADMINオプション付きで付与されます。

親トピック: オペレーティング・システムまたはネットワークを使用したロールの付与

4.23.3 オペレーティング・システムのロール管理機能

オペレーティング・システムによって管理されているロールを使用する場合は、データベース・ロールがオペレーティング・システムのユーザーに付与されることに注意してください。

オペレーティング・システム・ユーザーが接続できるデータベース・ユーザーは、認可されたデータベース・ロールを使用できます。このため、OS_ROLES = TRUEを使用している場合は、権限が付与されているオペレーティング・システム・アカウントにデータベース・アカウントを対応付けるために、すべてのOracle DatabaseユーザーをIDENTIFIED EXTERNALLYとして定義することを考慮してください。

親トピック: オペレーティング・システムまたはネットワークを使用したロールの付与

4.23.4 OS_ROLESがTRUEに設定されている場合のロールの付与と取消し

OS_ROLES初期化パラメータをTRUEに設定すると、ユーザーに対するロールの付与と取消しをオペレーティング・システムで管理できるようになります。

それまでにGRANT文によってユーザーに付与されたロールは適用されません。ただし、それらのロールはデータ・ディクショナリには残っています。オペレーティング・システム・レベルでのユーザーへのロールの付与のみが適用されます。この場合も、ユーザーは権限をロールとユーザーに付与できます。

ノート:

オペレーティング・システムによってADMINオプション付きでロールが付与された場合、ユーザーはそのロールを他のロールにのみ付与できます。

親トピック: オペレーティング・システムまたはネットワークを使用したロールの付与

4.23.5 OS_ROLESがTRUEに設定されている場合のロールの有効化と無効化

OS_ROLES初期化パラメータをTRUEを設定すると、オペレーティング・システムによって付与されたロールをSET ROLE文で動的に有効にできます。

ロールがパスワードやオペレーティング・システムによる認可を必要とするように定義されていた場合でも、この文は適用されます。ただし、ユーザーのオペレーティング・システム・アカウントで識別されないロールは、SET ROLE文では指定できません。これは、OS_ROLES = FALSEのときにGRANT文を使用してロールを付与していた場合でも同じです。(このようなロールを指定しても無視されます。)

OS_ROLESがTRUEに設定されている場合、ユーザーは最大148個のロールを使用可能にできます。この数には、ロールに付与されている可能性のある他のロールも含まれることに注意してください。

親トピック: オペレーティング・システムまたはネットワークを使用したロールの付与

4.23.6 オペレーティング・システムによるロール管理使用時のネットワーク接続

ロールがオペレーティング・システムによって管理されている場合、デフォルトでユーザーは共有サーバーを通じてデータベースに接続できません。

リモート・ユーザーは保護されていない接続を介して別のオペレーティング・システム・ユーザーになりすますおそれがあるため、デフォルトでこのような制限が適用されています。

このようなセキュリティに対する危険性の心配がない場合は、初期化パラメータREMOTE_OS_ROLESをTRUEに設定することで、共有サーバーまたはその他のネットワーク接続でオペレーティング・システムのロール管理を使用できます。この変更は、次回インスタンスを起動して、データベースをマウントするときに有効になります。このパラメータのデフォルト設定はFALSEです。

親トピック: オペレーティング・システムまたはネットワークを使用したロールの付与

4.24 SET ROLEおよびデフォルト・ロールの設定による権限の付与と取消しの機能

権限付与およびSET ROLE文は、付与と取消しが適用されるタイミングと方法に影響します。

親トピック: 権限とロール認可の構成

4.24.1 権限の付与と取消しが有効になるとき

付与と取消しがいつ有効になるかは、付与または取り消す権限によって異なります。

権限の付与と取消しは次のように有効になります。

  • 任意の対象(ユーザー、ロールおよびPUBLIC)に対するシステム権限とオブジェクト権限の付与および取消しは、即時に有効になります。

  • 任意の対象(ユーザー、他のロール、PUBLIC)に対するロールの付与および取消しが有効になるのは、その付与および取消しの実行後、ロールを再度使用可能にするために現行のユーザー・セッションでSET ROLE文を発行したとき、あるいはその付与または取消しを実行した後に新しくユーザー・セッションを作成したときです。

現在使用可能なロールは、SESSION_ROLESデータ・ディクショナリ・ビューを問い合せることによって確認できます。

親トピック: SET ROLEおよびデフォルト・ロールの設定による権限の付与と取消しの機能

4.24.2 SET ROLE文が付与と取消しに与える影響

ユーザーまたはアプリケーションは、ユーザー・セッション中にSET ROLE文を何度でも使用して、そのセッションで使用可能になっているロールを変更できます。

ユーザーには、SET ROLE文で指定したロールが、事前に付与されている必要があります。

次の例では、すでに付与されているロールclerkを使用可能にして、パスワードを指定しています。 

SET ROLE clerk IDENTIFIED BY password;

passwordを安全なパスワードに置き換えます。

次の例は、SET ROLEを使用してすべてのロールを使用禁止にする方法を示しています。 

SET ROLE NONE;

関連トピック

親トピック: SET ROLEおよびデフォルト・ロールの設定による権限の付与と取消しの機能

4.24.3 ユーザーのデフォルト・ロールの指定

ユーザーがログインすると、Oracle Databaseではそのユーザーに明示的に付与されている権限と、そのユーザーのデフォルト・ロールに含まれる権限が、すべて使用可能になります。

  1. デフォルト・ロールの設定対象のユーザーにロールがGRANT文で直接付与されているか、CREATE ROLE権限があるユーザーによってロールが作成されていることを確認します。
  2. ユーザーのデフォルト・ロールを指定するには、DEFAULT ROLE句を指定してALTER USER文を使用します。

たとえば、ユーザーjaneに対してデフォルト・ロールのpayclerkとpettycashを設定する方法は、次のとおりです。 

ALTER USER jane DEFAULT ROLE payclerk, pettycash;

CREATE USER文ではユーザーのデフォルト・ロールを設定できません。ユーザーを最初に作成すると、デフォルトのユーザー・ロール設定はALLであり、ユーザーにその後に付与されるすべてのロールがデフォルト・ロールになります。デフォルトのユーザー・ロールを制限するには、ALTER USER文を使用します。

ノート:

(グローバル・ロールやアプリケーション・ロール以外の)ロールを作成すると、このロールが自分に暗黙的に付与され、自分のデフォルト・ロールのセットが新しいロールを含むように更新されます。ユーザー・セッションで有効にできるロールは148個のみであることに注意してください。DBAロールのような集計ロールがユーザーに付与されると、そのロールに付与されるロールはユーザーが持っているロール数に含まれます。たとえば、あるロールには20個のロールが付与されており、そのロールをユーザーに付与すると、そのユーザーは21個の追加ロールを持っていることになります。したがって、新しいロールをユーザーに付与するときは、ALTER USER文のDEFAULT ROLE句を使用してそのユーザーのデフォルト・ロールとして指定されるロールが多すぎないよう確認してください。

関連トピック

親トピック: SET ROLEおよびデフォルト・ロールの設定による権限の付与と取消しの機能

4.24.4 ユーザーが使用可能にできるロールの最大数

ロールはいくつでもユーザーに付与できますが、任意の時点でログイン・ユーザーに対して有効にできるロール数は最大148個です。

最大148ロールには、トップレベルのロールのみでなく、他のロールに付与されるロールが含まれます。したがって、ユーザー・セッションでこのユーザーはすべての権限を使用できるわけではありません。ベスト・プラクティスとして、ユーザーに付与するロールの数を必要最小限のロールに制限します。

関連トピック

親トピック: SET ROLEおよびデフォルト・ロールの設定による権限の付与と取消しの機能

4.25 読取り専用ユーザーの構成

ユーザーに付与されている権限およびロールは、読取り専用ユーザーにすることで上書きできます。

これにより、SELECT操作が許可されますが、CREATE、INSERT、UPDATEまたはDELETEは許可されません。

この機能を使用すると、ユーザーが読取り専用に設定されているかぎり、管理者が完全なユーザー権限セットの使用をブロックできます。たとえば、データの挿入、更新および削除に対する完全な権限を付与されているデータベース・ユーザーは、読取り専用に変更されるとINSERT、UPDATEまたはDELETE操作を実行できなくなります。読取り専用制限は、スキーマまたはシステム権限を含む権限付与をオーバーライドします。読取り専用制限は、DBAロールをオーバーライドすることもできます。ユーザーがこれらのタイプの操作を実行しようとすると、「ORA-28194: 読取り操作のみを実行できます」エラーが表示されます。

読取り専用ユーザーの構成のユースケースは次のとおりです。

  • 通常、ユーザーまたはアプリケーションは、アプリケーションによって要求された、または管理者によって付与された方法でシステムにアクセスできますが、メンテナンスまたは調査の理由から、管理者はデータベースへの変更を禁止できます。その場合、ユーザーの他の権限を変更することなく、ユーザーをREAD ONLYに設定できます。
  • それ以外の場合、権限のあるユーザーはアプリケーションの一部に対する読取り専用アクセス権を持っている必要があります。アプリケーション・コードに、単純なALTER SESSION文を埋め込んで、ユーザーにREAD ONLYアクセス権を付与できます。

読取り専用ユーザーは、通常はデータへの読取りアクセスのみを必要とし、特定の条件下では読取り/書込みまで昇格する機能が必要な場合に適しています。単一のSQLコマンドを使用すると、これらのアカウントは「モード」を変更でき、データの更新を実行できます。

ユーザーの読取り専用制限を構成するには、CREATE USER文またはALTER USER文を使用します。ユーザーの読取り専用ステータスを検索するには、DBA_USERSまたはALL_USERSデータ・ディクショナリ・ビューのREAD_ONLY列を問い合せます。

表4-10読取り専用ユーザーの変更および検証手順

操作 プロシージャ

ユーザーの読取り専用での作成

 
CREATE USER user_name READ ONLY;

ユーザーの読取り専用への変更

 
ALTER USER user_name READ ONLY;

ユーザーによる読取り/書込みアクセスの再有効化

 
ALTER USER user_name READ WRITE;

ユーザーの読取り専用ステータスの検索

 
SELECT USERNAME, READ_ONLY from DBA_USERS
WHERE USERNAME = 'user_name';

次のような出力結果が表示されます。たとえば、ユーザーPFITCHに読取り専用アクセス権がある場合: 

USERNAME     READ_ONLY
–----------- –----------
PFITCH       YES

関連トピック

親トピック: 権限とロール認可の構成

4.26 ユーザー権限およびロールのデータ・ディクショナリ・ビュー

特別な問合せを使用して、様々なタイプの権限およびロール付与に関する情報を入手できます。

親トピック: 権限とロール認可の構成

4.26.1 権限およびロール付与の情報を確認するデータ・ディクショナリ・ビュー

Oracle Databaseには、権限およびロール付与に関する情報を表示するデータ・ディクショナリ・ビューが用意されています。

表4-11に、権限とロールの付与に関する情報にアクセスするために問合せ可能なビューを示します。

表4-11 権限およびロール情報を表示するデータ・ディクショナリ・ビュー

ビュー 説明

ALL_COL_PRIVS

オブジェクト所有者、権限付与者または権限受領者が現行ユーザーまたはPUBLICである列オブジェクトの権限付与がすべて表示されます。

ALL_COL_PRIVS_MADE

オブジェクト所有者または権限付与者が現行ユーザーである列オブジェクトの権限付与がリストされます

ALL_COL_PRIVS_RECD

権限受領者が現行ユーザーまたはPUBLICである列オブジェクトの権限付与が表示されます。

ALL_TAB_PRIVS

権限受領者がユーザーまたはPUBLICであるオブジェクトの権限付与がリストされます。

ALL_TAB_PRIVS_MADE

現行ユーザーが行ったオブジェクトの権限付与、または現行ユーザーが所有するオブジェクトに対する権限付与がすべてリストされます

ALL_TAB_PRIVS_RECD

権限受領者がユーザーまたはPUBLICであるオブジェクトの権限付与がリストされます。

DBA_COL_PRIVS

データベース内の列オブジェクトの権限付与がすべて表示されます。

DBA_CONTAINER_DATA

デフォルト(ユーザー・レベル)およびオブジェクト固有のCONTAINER_DATA属性が表示されます。CONTAINER_DATA句で作成されるオブジェクトには、CONTAINER_DATA属性が含まれます。

DBA_EPG_DAD_AUTHORIZATION

別のユーザー権限の使用が許可されたデータベース・アクセス記述子(DAD)が表示されます

DBA_LOCKDOWN_PROFILES

PDBロックダウン・プロファイルに関する情報が表示されます

DBA_OBJECTS

オブジェクト・リンクまたはメタデータ・リンクがあるオブジェクトがリストされます。これらのオブジェクトを確認するには、OBJECT_NAMEおよびSHARING列を問い合せます。

DBA_SCHEMA_PRIVS

データベース内のユーザーまたはロールに付与されているすべてのスキーマ権限を示します

DBA_TAB_PRIVS

データベース内のすべてのオブジェクトに対するすべての権限付与がリストされます。

DBA_ROLES

セキュア・アプリケーション・ロールを含めて、データベース内に存在するすべてのロールがリストされますPUBLICロールはリストされません

DBA_ROLE_PRIVS

ユーザーとロールに直接付与されているロールがリストされます。

DBA_SYS_PRIVS

ユーザーとロールに付与されているシステム権限がリストされます。

ROLE_ROLE_PRIVS

他のロールに付与されているロールがリストされます。ユーザーがアクセス権限を持っているロールの情報のみが得られます

ROLE_SCHEMA_PRIVS

現在のユーザーの有効なロールに付与されているすべてのスキーマ権限を示します

ROLE_SYS_PRIVS

ロールに付与されているシステム権限がリストされます。ユーザーがアクセス権限を持っているロールの情報のみが得られます

ROLE_TAB_PRIVS

ロールに付与されているオブジェクト権限がリストされます。ユーザーがアクセス権限を持っているロールの情報のみが得られます

SESSION_PRIVS

ユーザーに対して現在使用可能になっている権限がリストされます。

SESSION_SCHEMA_PRIVS

現在のユーザーに付与されているすべてのスキーマ権限と、現在のユーザーの有効なロールに付与されているスキーマ権限を示します

SESSION_ROLES

現在のユーザーに対して使用可能になっているすべてのロールがリストされます。PUBLICロールはリストされません

USER_APPLICATION_ROLES

現行ユーザーが、ユーザーに付与されているすべてのアプリケーション・ロールを表示できるようにします

USER_COL_PRIVS

オブジェクト所有者、権限付与者または権限受領者が現行ユーザーである列オブジェクトの権限付与が表示されます。

USER_COL_PRIVS_MADE

オブジェクト所有者が現行ユーザーである列オブジェクトの権限付与が表示されます。

USER_COL_PRIVS_RECD

権限受領者が現行ユーザーである列オブジェクトの権限付与が表示されます。

USER_EPG_DAD_AUTHORIZATION

別のユーザー権限の使用が許可されたデータベース・アクセス記述子(DAD)が表示されます

USER_ROLE_PRIVS

現行ユーザーに直接付与されているロールがリストされます。

USER_SCHEMA_PRIVS

現在のユーザーに付与されているすべてのスキーマ権限を示します

USER_TAB_PRIVS

権限受領者が現行ユーザーであるすべてのオブジェクトの権限付与がリストされます。

USER_SYS_PRIVS

現行ユーザーに付与されているシステム権限がリストされます。

USER_TAB_PRIVS_MADE

現行ユーザーが所有しているすべてのオブジェクトの権限付与がリストされます。

USER_TAB_PRIVS_RECD

権限受領者が現行ユーザーであるオブジェクトの権限付与がリストされます。

V$ENABLEDSCHEMAPRIVS

現在のユーザーに付与されているスキーマ権限を示します

V$PWFILE_USERS

管理権限を付与された現在のPDBのすべてのユーザーをリストします

次の表に、権限とロールの付与に関する情報にアクセスするために問合せ可能なビューを示します。

ここでは、これらのビューの使用例をいくつか示します。各例では、次の文がすでに発行されていることを前提としています。

CREATE ROLE security_admin IDENTIFIED BY password;

GRANT CREATE PROFILE, ALTER PROFILE, DROP PROFILE,
    CREATE ROLE, DROP ANY ROLE, GRANT ANY ROLE, AUDIT ANY,
    AUDIT SYSTEM, CREATE USER, BECOME USER, ALTER USER, DROP USER
    TO security_admin WITH ADMIN OPTION;

GRANT READ, DELETE ON SYS.AUD$ TO security_admin;

GRANT security_admin, CREATE SESSION TO swilliams;

GRANT security_admin TO system_administrator;

GRANT CREATE SESSION TO jward;

GRANT READ, DELETE ON emp TO jward;

GRANT INSERT (ename, job) ON emp TO swilliams, jward;

関連トピック

親トピック: ユーザー権限およびロールのデータ・ディクショナリ・ビュー

4.26.2 すべてのシステム権限の付与を表示する問合せ

DBA_SYS_PRIVSデータ・ディクショナリ・ビューは、ロールとユーザーに対して付与されているすべてのシステム権限を返します。

例: 

SELECT GRANTEE, PRIVILEGE, ADM FROM DBA_SYS_PRIVS;

GRANTEE            PRIVILEGE                         ADM
--------------     --------------------------------- ---
SECURITY_ADMIN     ALTER PROFILE                     YES
SECURITY_ADMIN     ALTER USER                        YES
SECURITY_ADMIN     AUDIT ANY                         YES
SECURITY_ADMIN     AUDIT SYSTEM                      YES
SECURITY_ADMIN     BECOME USER                       YES
SECURITY_ADMIN     CREATE PROFILE                    YES
SECURITY_ADMIN     CREATE ROLE                       YES
SECURITY_ADMIN     CREATE USER                       YES
SECURITY_ADMIN     DROP ANY ROLE                     YES
SECURITY_ADMIN     DROP PROFILE                      YES
SECURITY_ADMIN     DROP USER                         YES
SECURITY_ADMIN     GRANT ANY ROLE                    YES
SWILLIAMS          CREATE SESSION                    NO
JWARD              CREATE SESSION                    NO

関連トピック

親トピック: ユーザー権限およびロールのデータ・ディクショナリ・ビュー

4.26.3 システム権限付与を表示する問合せ

DBAロールを持つユーザーがアクセスするDBA_SCHEMA_PRIVSデータ・ディクショナリ・ビューには、データベース内のユーザーまたはロールに付与されているすべてのスキーマ権限が示されます。

例: 

SELECT GRANTEE, PRIVILEGE, SCHEMA FROM DBA_SCHEMA_PRIVS ORDER BY GRANTEE;

GRANTEE             PRIVILEGE           SCHEMA  
------------------- ------------------- –--------
PRESTON             SELECT ANY LIBRARY  HR
RLAYTON             SELECT ANY INDEX    HR

関連トピック

親トピック: ユーザー権限およびロールのデータ・ディクショナリ・ビュー

4.26.4 すべてのロール付与を表示する問合せ

DBA_ROLE_PRIVS問合せは、ユーザーと他のロールに対して付与されているロールをすべて返します。

例:

SELECT * FROM DBA_ROLE_PRIVS;

GRANTEE            GRANTED_ROLE                         ADM
------------------ ------------------------------------ ---
SWILLIAMS          SECURITY_ADMIN                       NO

関連トピック

親トピック: ユーザー権限およびロールのデータ・ディクショナリ・ビュー

4.26.5 ユーザーに付与されているオブジェクト権限を表示する問合せ

DBA_TAB_PRIVSおよびDBA_COL_PRIVSデータ・ディクショナリ・ビューには、ユーザーに付与されているオブジェクト権限が表示されます。

DBA_TAB_PRIVSデータ・ディクショナリ・ビューは、指定のユーザーに対して付与されているオブジェクト権限をすべて(列固有の権限を除く)返します。

例:

SELECT TABLE_NAME, PRIVILEGE, GRANTABLE FROM DBA_TAB_PRIVS
    WHERE GRANTEE = 'jward';

TABLE_NAME   PRIVILEGE    GRANTABLE
-----------  ------------ ----------
EMP          SELECT       NO
EMP          DELETE       NO

付与されている列固有の権限をすべて表示するには、次の問合せを使用します。

SELECT GRANTEE, TABLE_NAME, COLUMN_NAME, PRIVILEGE
    FROM DBA_COL_PRIVS;

GRANTEE      TABLE_NAME     COLUMN_NAME      PRIVILEGE
-----------  ------------   -------------    --------------
SWILLIAMS    EMP            ENAME            INSERT
SWILLIAMS    EMP            JOB              INSERT
JWARD        EMP            NAME             INSERT
JWARD        EMP            JOB              INSERT

関連トピック

親トピック: ユーザー権限およびロールのデータ・ディクショナリ・ビュー

4.26.6 セッションの現在の権限ドメインを表示する問合せ

SESSION_ROLESおよびSESSION_PRIVSデータ・ディクショナリ・ビューには、データベース・セッションの現在の権限ドメインが表示されます。

SESSION_ROLESビューでは、発行者が現在使用できるロールがすべて表示されます。

例:

SELECT * FROM SESSION_ROLES;

ユーザーswilliamsに対してsecurity_adminロールが使用可能になっている場合に、この問合せを実行すると、Oracle Databaseから次の情報が戻されます。 

ROLE
------------------------------
SECURITY_ADMIN

次の問合せを実行すると、発行者のセキュリティ・ドメインで現在使用可能なシステム権限がすべて表示されます。これには、明示的に付与されている権限と使用可能なロールから付与された権限の両方が含まれています。

SELECT * FROM SESSION_PRIVS;

ユーザーswilliamsに対してsecurity_adminロールが使用可能になっている場合に、この問合せを実行すると、Oracle Databaseから次の結果が戻されます。 

PRIVILEGE
----------------------------------------
AUDIT SYSTEM
CREATE SESSION
CREATE USER
BECOME USER
ALTER USER
DROP USER
CREATE ROLE
DROP ANY ROLE
GRANT ANY ROLE
AUDIT ANY
CREATE PROFILE
ALTER PROFILE
DROP PROFILE

ユーザーswilliamsに対してsecurity_adminロールが使用禁止になっている場合、最初の問合せでは何も表示されず、2番目の問合せではCREATE SESSION権限の付与に関する行が1行のみ表示されます。

関連トピック

親トピック: ユーザー権限およびロールのデータ・ディクショナリ・ビュー

4.26.7 データベースのロールを表示する問合せ

DBA_ROLESデータ・ディクショナリ・ビューでは、データベースのすべてのロールと各ロールに対して使用されている認証が表示されます。

例:

SELECT * FROM DBA_ROLES;

ROLE                  PASSWORD
----------------      --------
CONNECT               NO
RESOURCE              NO
DBA                   NO
SECURITY_ADMIN        YES

関連トピック

親トピック: ユーザー権限およびロールのデータ・ディクショナリ・ビュー

4.26.8 ロールの権限ドメイン情報を表示する問合せ

ROLE_ROLE_PRIVS、ROLE_SYS_PRIVSおよびROLE_TAB_PRIVSの各データ・ディクショナリ・ビューには、ロールの権限ドメインに関する情報が表示されます。

例:

SELECT GRANTED_ROLE, ADMIN_OPTION
   FROM ROLE_ROLE_PRIVS
   WHERE ROLE = 'SYSTEM_ADMIN';

GRANTED_ROLE              ADM
----------------          ----
SECURITY_ADMIN            NO

次の問合せを実行すると、security_adminロールに付与されているシステム権限がすべて表示されます。 

SELECT * FROM ROLE_SYS_PRIVS WHERE ROLE = 'SECURITY_ADMIN';

ROLE                    PRIVILEGE                      ADM
----------------------- -----------------------------  ---
SECURITY_ADMIN           ALTER PROFILE                 YES
SECURITY_ADMIN           ALTER USER                    YES
SECURITY_ADMIN           AUDIT ANY                     YES
SECURITY_ADMIN           AUDIT SYSTEM                  YES
SECURITY_ADMIN           BECOME USER                   YES
SECURITY_ADMIN           CREATE PROFILE                YES
SECURITY_ADMIN           CREATE ROLE                   YES
SECURITY_ADMIN           CREATE USER                   YES
SECURITY_ADMIN           DROP ANY ROLE                 YES
SECURITY_ADMIN           DROP PROFILE                  YES
SECURITY_ADMIN           DROP USER                     YES
SECURITY_ADMIN           GRANT ANY ROLE                YES

次の問合せを実行すると、security_adminロールに付与されているオブジェクト権限がすべて表示されます。 

SELECT TABLE_NAME, PRIVILEGE FROM ROLE_TAB_PRIVS
    WHERE ROLE = 'SECURITY_ADMIN';

TABLE_NAME                     PRIVILEGE
---------------------------    ----------------
AUD$                           DELETE
AUD$                           SELECT

関連トピック

親トピック: ユーザー権限およびロールのデータ・ディクショナリ・ビュー