ヘッダーをスキップ
Oracle Databaseセキュリティ・ガイド
11g リリース1(11.1)
E05730-05
  目次
目次
索引
索引

戻る
戻る
 
次へ
次へ
 

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

この章の内容は、次のとおりです。

権限とロールの概要

認可には、主に次の2つのプロセスがあります。

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

ロールは、ユーザー(通常は管理者)が権限や他のロールをグループ化するために作成します。ロールを使用すると、複数の権限またはロールをユーザーに簡単に付与できます。

ここでは、次の一般的なカテゴリについて説明します。

権限付与の対象者

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

ユーザーは次の2つの方法で権限を受け取ることができます。

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


関連項目:


システム権限の管理

この項の内容は、次のとおりです。

システム権限の概要

システム権限とは、特定のアクションを実行する権限、または特定のタイプのスキーマ・オブジェクトに対してアクションを実行する権限のことです。たとえば、表領域を作成する権限や、データベース内の任意の表から行を削除する権限などがシステム権限です。

システム権限には100以上の種類があります。各システム権限によって、ユーザーは特定のデータベース操作、またはあるクラスのデータベース操作を実行できます。システム権限は非常に強力な権限であることに注意してください。システム権限は、必要な場合のみ、データベースのロールと信頼できるユーザーに付与してください。システム権限の完全なリストとその詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

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

システム権限は非常に強力であるため、通常のユーザー(管理者以外)がデータ・ディクショナリに対してANYシステム権限(UPDATE ANY TABLEなど)を行使できないようにデータベースを構成する必要があります。システム権限の制限に関するその他のガイドラインは、「ユーザー・アカウントと権限の保護に関するガイドライン」を参照してください。

データ・ディクショナリの保護によるシステム権限の制限

データ・ディクショナリを保護するには、O7_DICTIONARY_ACCESSIBILITY初期化パラメータをFALSE(デフォルト)に設定します。この機能を、ディクショナリ保護メカニズムと呼びます。

O7_DICTIONARY_ACCESSIBILITY初期化パラメータは、Oracle Databaseリリース7からOracle8i以上のリリースにアップグレードした場合の、システム権限に対する制限を制御します。このパラメータをTRUEに設定すると、SYSスキーマ内のオブジェクトへのアクセスが可能になります(Oracle Databaseリリース7の動作)。ANY権限はデータ・ディクショナリに適用されるため、ANY権限を持つ不正なユーザーがデータ・ディクショナリ表にアクセスし、変更する危険性があります。

O7_DICTIONARY_ACCESSIBILTY初期化パラメータを設定するには、initSID.oraファイルでそのパラメータを変更します。または、SYS /AS SYSDBAでSQL*Plusにログインし、ALTER SYSTEM文を入力します。これは、サーバー・パラメータ・ファイル(SPFILE)を使用して、データベースを起動している場合を想定しています。

例4-1では、SQL*PlusのALTER SYSTEM文を発行して、O7_DICTIONARY_ACCESSIBILTY初期化パラメータをFALSEに設定する方法を示しています。

例4-1 O7_DICTIONARY_ACCESSIBILITYのFALSEへの設定

ALTER SYSTEM SET O7_DICTIONARY_ACCESSIBILITY=FALSE SCOPE=SPFILE;

O7_DICTIONARY_ACCESSIBILITYFALSEに設定すると、任意のスキーマのオブジェクトにアクセスできるシステム権限(たとえば、CREATE ANY PROCEDUREなどのANY権限)では、SYSスキーマ内のオブジェクトにアクセスできません。これは、SYSスキーマ内のオブジェクト(データ・ディクショナリ・オブジェクト)へのアクセスが、SYSで接続しているユーザーまたはSYSDBA権限を使用して接続しているユーザーに制限されることを意味します。

前述のユーザー以外は、他のスキーマ内のオブジェクトへのアクセスを提供するシステム権限があっても、SYSスキーマ内のオブジェクトにはアクセスできません。たとえば、SELECT ANY TABLE権限を持つユーザーは、他のスキーマのビューや表にはアクセスできますが、ディクショナリ・オブジェクト(動的パフォーマンス・ビューの実表、通常のビュー、パッケージおよびシノニム)は選択できません。ただし、これらのユーザーは、明示的なオブジェクト権限を付与することで、SYSスキーマ内のオブジェクトにアクセスできるようになります。

O7_DICTIONARY_ACCESSIBILITY初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

権限受領者のスキーマで実行するスケジューラ・ジョブの保護

CREATE EXTERNAL JOB権限は、データベースの外部でオペレーティング・システムのジョブを実行できるように、権限受領者ユーザーのスキーマ内に自動的に作成されます。この権限は、下位互換性を維持するためにCREATE JOB権限を持つ既存のユーザーすべてにデフォルトで付与されます。セキュリティを強化するために、CREATE EXTERNAL JOB権限は、SYS、データベース管理者および必要なユーザーのみに付与してください。

SYSスキーマ内のオブジェクトへのアクセスの許可

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

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

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

ロール 説明

SELECT_CATALOG_ROLE

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

EXECUTE_CATALOG_ROLE

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

DELETE_CATALOG_ROLE

このロールを付与されたユーザーは、システム監査表(AUD$)からレコードを削除できます。


また、SYSスキーマ内に作成された表へのアクセスが必要なユーザーには、SELECT ANY DICTIONARYシステム権限を付与できます。このシステム権限によって、SYSスキーマ内に作成された、表などの任意のオブジェクトに対して問合せを実行できます。このシステム権限は、この権限を必要とする各ユーザーに個別に付与する必要があります。この権限はGRANT ALL PRIVILEGESには含まれていませんが、ロールを介して付与できます。


注意:


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

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

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

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

  • SQL文のGRANTおよびREVOKE

  • Oracle Enterprise Manager Database Control

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

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

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

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

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

ANY権限とPUBLIC権限の概要

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

PUBLIC権限は、Oracleデータベースのすべてのユーザーに付与され、ロールに付与したり、ユーザーとして付与することができます。PUBLIC権限を使用して作成されたオブジェクトは誰でもアクセスできるため、ANYオブジェクトと同様にセキュリティ上のリスクが発生する可能性があります。たとえば、CREATE PUBLIC SYNONYM権限が付与されているMALCOEURは、誰でも使用することがわかっているインタフェースを再定義し、作成したPUBLIC SYNONYMでそのインタフェースを指し示すことができます。ユーザーは、正しいインタフェースにアクセスするかわりに、MALCOEURが作成したインタフェースにアクセスすることになります。その結果、ユーザーのログイン資格証明の盗用などの不正な活動が実行される可能性があります。

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

ANY権限を持つユーザーに対してSYSのデータ・ディクショナリを保護するには、O7_DICTIONARY_ACCESSIBILITY初期化パラメータをFALSEに設定します。このパラメータは、ALTER SYSTEM文(例4-1「O7_DICTIONARY_ACCESSIBILITYのFALSEへの設定」を参照)を使用するか、またはinitSID.oraファイルを変更することで設定できます。その他のガイドラインは、「データベースのインストールと構成の保護に関するガイドライン」を参照してください。

ユーザー・ロールの管理

この項の内容は、次のとおりです。

ユーザー・ロールの概要

ロールを使用すると、権限の管理と制御が容易になります。ロールは、関連する権限のグループに名前を付けたもので、ユーザーや他のロールに付与します。各ロール名はデータベース内で一意にする必要があり、どのユーザー名または他のどのロール名とも同一にはできません。スキーマ・オブジェクトとは異なり、ロールはスキーマに含まれているわけではありません。そのため、ロールを作成したユーザーを削除しても、そのロールに影響はありません。

この項の内容は、次のとおりです。

ロールの機能

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

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

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

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

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

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

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

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

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

特性 説明

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

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

動的な権限管理

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

権限の選択的な可用性

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

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

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

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

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


データベース・アプリケーションについてのロールは、通常、データベース管理者が作成します。管理者は、アプリケーションの実行に必要なすべての権限をセキュア・アプリケーション・ロールに付与します。その後、このセキュア・アプリケーション・ロールを別のロールや特定のユーザーに付与できます。アプリケーションは複数の異なるロールを持つことができます。各ロールには、アプリケーションの使用時におけるデータ・アクセスの量を考慮して、異なる権限の集合を付与します。

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


関連項目:


プロシージャに関する制限の詳細は、「ロールによるDDL使用の支援または制限」を参照してください。

ロールの一般的な使用方法

通常は、次のいずれかの目的でロールを作成します。

図4-1とその後の各項で、ロールの2通りの使用方法について説明します。

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

ロールの一般的な使用方法


アプリケーション・ロールの一般的な使用方法

アプリケーション・ロールには、特定のデータベース・アプリケーションを実行するために必要な権限をすべて付与します。次に、そのセキュア・アプリケーション・ロールを、他のロールや特定のユーザーに対して付与します。1つのアプリケーションに対して複数の異なるロールを設定し、アプリケーション使用時のデータ・アクセスの量や範囲にあわせて異なる権限セットを各ロールに割り当てることができます。

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

ユーザー・ロールは、共通の権限要件を持つデータベース・ユーザーのグループのために作成されるロールです。ユーザーの権限は、セキュア・アプリケーション・ロールと権限をユーザー・ロールに付与し、そのユーザー・ロールを適切なユーザーに付与することで管理できます。

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

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

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

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

PL/SQLブロック内でのロールの使用方法は、そのブロックが無名ブロックであるか、名前付きブロック(ストアド・プロシージャ、ファンクションまたはトリガー)であるか、および定義者権限または実行者権限のどちらで実行されるかによって異なります。

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

定義者権限で実行される名前付きPL/SQLブロック(ストアド・プロシージャ、ファンクションまたはトリガー)では、すべてのロールは使用禁止になっています。ロールは権限チェックに使用されず、定義者権限プロシージャ内ではロールを設定できません。

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


関連項目:


『Oracle Databaseリファレンス』

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

実行者権限で実行される名前付きPL/SQLブロックと、無名PL/SQLブロックは、使用可能なロールを介して付与された権限に基づいて実行されます。実行者権限を持つPL/SQLブロック内での権限チェックにはカレント・ロールが使用され、動的SQLを使用してセッション中にロールを設定できます。


関連項目:

  • 実行者権限と定義者権限の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

  • PL/SQLの動的SQLの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。


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

ユーザーがDDL文を正常に実行するには、その文に応じて1つ以上の権限が必要になります。たとえば、表を作成するには、CREATE TABLEまたはCREATE ANY TABLEシステム権限が必要です。別のユーザーに属する表のビューを作成するには、CREATE VIEWまたはCREATE ANY VIEWシステム権限のみでなく、その表に対するSELECT object権限またはSELECT ANY TABLEシステム権限も必要です。

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

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

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

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


    注意:


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

  • DDL文の発行に必要なDML操作の実行をユーザーに許可するすべてのシステム権限およびオブジェクト権限は、ロールを介して受け取った場合は使用不可。たとえば、表に対するSELECT ANY TABLEシステム権限やSELECT object権限がロールを介して付与されているユーザーは、それらの権限では別のユーザーに属する表のビューを作成できません。

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

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

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

  • employees表に対するSELECT object権限を持つロールが付与されていますが、employees表に対するSELECT object権限は間接的な付与となります。

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

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

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

  • このユーザーには、employees表のCREATE VIEW権限とSELECT権限がロールを介して付与されていますが、employees表のSELECT object権限がロールを介して付与されていたため、employees表に基づいた使用可能なビューは作成できません。作成されたビューにアクセスすると、エラーになります。

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

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

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


関連項目:


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

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

分散データベース環境でロールを使用する場合は、必要なすべてのロールを分散(リモート)セッションのデフォルト・ロールとして設定する必要があります。ローカル・データベース・セッション内からリモート・データベースに接続しているときは、これらのロールを使用可能にすることはできません。たとえば、ユーザーは、リモート・サイトでロールを使用可能にしようとするリモート・プロシージャを実行できません。


関連項目:


『Oracle Database Heterogeneous Connectivity管理者ガイド』

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

Oracle Databaseには、データベース管理を容易にする一連の事前定義ロールが用意されています。 表4-3に示すこれらのロールは、データベース作成の一部である標準スクリプトの実行時に、Oracleデータベースに対して自動的に定義されます。他のオプションや製品をインストールすると、他の事前定義のロールが作成される場合があります。ユーザー定義のロールと同様に、これらの事前定義ロールに対しても、権限とロールの付与および取消しができます。

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

事前定義のロール 説明

AQ_ADMINISTRATOR_ROLE

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

AQ_USER_ROLE

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

AUTHENTICATEDUSER

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

CONNECT

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

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

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

関連項目: DBA_SYS_PRIVSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

CSW_USR_ROLE

Oracle SpatialのCatalog Services for the Web(CSW)コンポーネントを管理するユーザー権限を提供します。

関連項目: 詳細は、『Oracle Spatial開発者ガイド』を参照してください。

CTXAPP

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

関連項目: 詳細は、『Oracle Textアプリケーション開発者ガイド』を参照してください。

CWM_USER

Oracleデータ・ウェアハウスおよび意思決定支援で使用されるリポジトリ標準であるCommon Warehouse Metadata(CWM)の管理権限を提供します。

関連項目: 詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

DATAPUMP_EXP_FULL_DATABASE

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

関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。

DATAPUMP_IMP_FULL_DATABASE

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

関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。

DBA

WITH ADMIN OPTION句を指定したすべてのシステム権限を提供します。

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

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

関連項目: DBA_SYS_PRIVSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

DELETE_CATALOG_ROLE

システム監査表(AUD$)に対するDELETE権限を提供します。

EJBCLIENT

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

EXECUTE_CATALOG_ROLE

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

EXP_FULL_DATABASE

データベースの全エクスポート/インポートおよび増分エクスポート/インポートを実行するために必要な権限を提供します。必要な権限には、SELECT ANY TABLEBACKUP ANY TABLEEXECUTE ANY PROCEDUREEXECUTE ANY TYPEADMINISTER RESOURCE MANAGER、および表SYS.INCVIDSYS.INCFILおよびSYS.INCEXPに対するINSERTDELETEおよびUPDATEが含まれます。ロールEXECUTE_CATALOG_ROLEおよびSELECT_CATALOG_ROLEも含まれます。

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

関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。

GATHER_SYSTEM_STATISTICS

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

関連項目: オプティマイザ統計の管理の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

GLOBAL_AQ_USER_ROLE

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

関連項目: 詳細は、『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド』を参照してください。

HS_ADMIN_ROLE

Oracle Database異機種間サービスを介してDBAロールを使用する必要があるDBAに対して、データ・ディクショナリの適切な表にアクセスするための権限を提供します。

異機種間サービス(HS)データ・ディクショナリ表(SELECTを付与)およびパッケージ(EXECUTEを付与)へのアクセスを保護するために使用します。一般的なデータ・ディクショナリへのアクセス権を持つユーザーでもHSデータ・ディクショナリにアクセスできるように、SELECT_CATALOG_ROLEおよびEXECUTE_CATALOG_ROLEにこのロールが付与されています。

関連項目: 詳細は、『Oracle Database Heterogeneous Connectivity管理者ガイド』を参照してください。

IMP_FULL_DATABASE

全データベース・インポートを実行するための権限を付与します。システム権限の詳細リスト(権限を表示するにはビューDBA_SYS_PRIVSを使用)と、ロールEXECUTE_CATALOG_ROLEおよびSELECT_CATALOG_ROLEが含まれます。

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

関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。

JAVADEBUGPRIV

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

関連項目: Oracle Javaアプリケーションのセキュリティ管理の詳細は、『Oracle Database Java開発者ガイド』を参照してください。

JAVAIDPRIV

このリリースでは使用不可となりました。

JAVASYSPRIV

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

関連項目: Oracle Javaアプリケーションのセキュリティ管理の詳細は、『Oracle Database Java開発者ガイド』を参照してください。

JAVAUSERPRIV

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

関連項目: Oracle Javaアプリケーションのセキュリティ管理の詳細は、『Oracle Database Java開発者ガイド』を参照してください。

JAVA_ADMIN

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

関連項目: Oracle Javaアプリケーションのセキュリティ管理の詳細は、『Oracle Database Java開発者ガイド』を参照してください。

JAVA_DEPLOY

ncompおよびdeploynsユーティリティを使用してjavavm/adminディレクトリにncomp DLLをデプロイする権限を提供します。 このロールを使用しないと、javavm/deployおよびjavavm/adminディレクトリにアクセスできません。

関連項目: 詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

JMXSERVER

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

関連項目: Oracle Javaアプリケーションの管理の詳細は、『Oracle Database Java開発者ガイド』を参照してください。

LBAC_DBA

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

関連項目: 詳細は、『Oracle Label Security管理者ガイド』を参照してください。

LOGSTDBY_ADMINISTRATOR

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

関連項目: 詳細は、『Oracle Data Guard概要および管理』を参照してください。

MGMT_USER

Oracle Enterprise Managerで様々なアクティビティを実行する管理権限を提供します。

OEM_ADVISOR

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

関連項目: 詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

OEM_MONITOR

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

関連項目: 詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

OLAPI_TRACE_USER

OLAP APIトレースの実行権限を提供します。詳細は、Oracleサポートに連絡してください。

OLAP_DBA

Oracle OLAPの異なるスキーマでディメンション・オブジェクトを作成する管理権限を提供します。

関連項目: 詳細は、『Oracle OLAPユーザーズ・ガイド』を参照してください。

OLAP_USER

アプリケーション開発者に対し、Oracle OLAPの独自のスキーマでディメンション・オブジェクトを作成する権限を提供します。

関連項目: 詳細は、『Oracle OLAPユーザーズ・ガイド』を参照してください。

OLAP_XS_ADMIN

Oracle OLAPのセキュリティの管理権限を提供します。

関連項目: 詳細は、『Oracle OLAPユーザーズ・ガイド』を参照してください。

ORDADMIN

Oracle Multimedia DICOMの管理権限を提供します。

関連項目: 『Oracle Multimedia DICOM開発者ガイド』

OWB$CLIENT

プロジェクト、モジュール、表、ビュー、マップその他の作成など、Oracle Warehouse Builderの標準クライアント関連タスクを実行する権限を提供します。Warehouse Builderでは、すべての作業領域所有者およびユーザーにこのロールが自動的に付与されます。(つまり、Warehouse Builderを使用する必要があるユーザーにこのロールを明示的に付与する必要はありません。)セキュリティ上の理由から、OWB$CLIENTロールはWarehouse Builderユーザーのデフォルトのロールではありません。Oracle Warehouse Builderによって、必要な場合にのみこのロールが使用可能になります。

関連項目: 詳細は、『Oracle Warehouse Builderユーザーズ・ガイド』を参照してください。

OWB_DESIGNCENTER_VIEW

登録されたOracle Warehouse BuilderユーザーがWarehouse Builderパブリック・ビューを問い合せるための、データベース・レベルの権限(ALL_IV_PROJECTSなど)を提供します。Warehouse Builder管理者は、Warehouse Builderセキュリティ・レベルのACCESS_PUBLICVIEW_BROWSERシステム権限を使用して、Warehouse Builderユーザーのパブリック・ビューへのアクセス権を制御できます。

関連項目: 詳細は、『Oracle Warehouse Builderユーザーズ・ガイド』を参照してください。

OWB_USER

Oracle Warehouse Builder作業領域を作成および所有する権限を提供します。作業領域の所有者がこの作業領域にその他のデータベース・ユーザーを登録した場合、Oracle Databaseによりこのロールがこれらのユーザーに付与されます。このロールが付与されたユーザーは、Warehouse Builder Control Centerパブリック・ビューおよびその他のControl Centerユーティリティにもアクセスできます。Oracle Warehouse Builderでは、すべてのWarehouse Builderユーザーにこのロールが付与されます。

関連項目: 詳細は、『Oracle Warehouse Builderユーザーズ・ガイド』を参照してください。

RECOVERY_CATALOG_OWNER

リカバリ・カタログの所有者用の権限を付与します。次の権限が含まれます。CREATE SESSIONALTER SESSIONCREATE SYNONYMCREATE VIEWCREATE DATABASE LINKCREATE TABLECREATE CLUSTERCREATE SEQUENCECREATE TRIGGERCREATE PROCEDURE

RESOURCE

CREATE CLUSTERCREATE INDEXTYPECREATE OPERATORCREATE PROCEDURECREATE SEQUENCECREATE TABLECREATE TRIGGERCREATE TYPEの各システム権限を提供します。

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

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

関連項目: DBA_SYS_PRIVSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

SCHEDULER_ADMIN

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

関連項目: DBMS_SCHEDULERパッケージに関する詳細は、『Oracle Database管理者ガイド』を参照してください。

SELECT_CATALOG_ROLE

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

SPATIAL_CSW_ADMIN

Oracle SpatialのCatalog Services for the Web(CSW)コンポーネントを管理する管理権限を提供します。

関連項目: 詳細は、『Oracle Spatial開発者ガイド』を参照してください。

SPATIAL_WFS_ADMIN

Oracle SpatialのWeb Feature Service(WFS)コンポーネントを管理する管理権限を提供します。

関連項目: 詳細は、『Oracle Spatial開発者ガイド』を参照してください。

WFS_USR_ROLE

Oracle SpatialのWeb Feature Service(WFS)コンポーネントに対するユーザー権限を提供します。

関連項目: 詳細は、『Oracle Spatial開発者ガイド』を参照してください。

WKUSER

新規Oracle Ultra Searchインスタンスをホストする必要があるユーザーに権限を提供します。

関連項目: 詳細は、『Oracle Ultra Search管理者ガイド』を参照してください。

WM_ADMIN_ROLE

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

関連項目: 詳細は、『Oracle Database Workspace Manager開発者ガイド』を参照してください。

XDBADMIN

所有者のみが使用またはアクセスできるようにXMLスキーマを登録する場合とは対照的に、権限受領者がXMLスキーマをグローバルに登録できるようにします。このロールによって、権限受領者は、Oracle XML DBリポジトリにアクセスする際のアクセス制御リスト(ACL)チェックも回避できます。

関連項目: XMLスキーマとXML DBリポジトリの詳細は、『Oracle XML DB開発者ガイド』を参照してください。

XDB_SET_INVOKER

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

関連項目: Oracle DatabaseのXMLリポジトリのトリガーの詳細は、『Oracle XML DB開発者ガイド』を参照してください。

XDB_WEBSERVICES

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

関連項目: Oracle DatabaseのWebサービスの詳細は、『Oracle XML DB開発者ガイド』を参照してください。

XDB_WEBSERVICES_OVER_HTTP

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

関連項目: Oracle DatabaseのWebサービスの詳細は、『Oracle XML DB開発者ガイド』を参照してください。

XDB_WEBSERVICES_WITH_PUBLIC

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

関連項目: Oracle DatabaseのWebサービスの詳細は、『Oracle XML DB開発者ガイド』を参照してください。



注意:


インストールごとに独自のロールを作成し、必要な権限のみを割り当てる必要があります。これにより、使用している権限を詳細に制御できます。この処理により、Oracle Databaseが定義するロールをOracle Databaseが変更または削除するたびに、既存のロール、権限またはプロシージャを調整する必要もなくなります。たとえば、CONNECTロールが現在保持している権限は、CREATE SESSIONのみです。CONNECTおよびRESOURCEの各ロールはともに、将来のOracle Databaseのリリースでは使用不可になる予定です。

ロールの作成

ロールはCREATE ROLE文を使用して作成できますが、そのためにはCREATE ROLEシステム権限が必要です。通常、このシステム権限はセキュリティ管理者のみが持っています。


注意:


作成した直後のロールには、対応付けられた権限はありません。新しいロールに権限を対応付けるには、その新しいロールに権限や他のロールを付与する必要があります。

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

例4-2では、clerkロールを作成しています。

例4-2 パスワードによって認可されるユーザー・ロールの作成

CREATE ROLE clerk IDENTIFIED BY password;

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

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

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

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

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

これらの認可については、次の各項で説明します。

ロールの認可方式を設定または変更するには、ALTER ROLE文を使用します。

例4-3は、clerkロールの変更方法を示しています。これによって、ロールを使用可能にするには、ユーザーが外部ソースによって認可されている必要があることが指定されます。

例4-3 外部ソースによる認可が必要なロールへの変更

ALTER ROLE clerk IDENTIFIED EXTERNALLY;

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


関連項目:


ロールと権限の管理に使用するSQL文の構文、制限事項および認可情報は、『Oracle Database SQL言語リファレンス』を参照してください。

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

ここでは、ロールの認可方式について説明します。ロールを使用するには、ユーザーに対してロールを使用可能にする必要があります。

この項の内容は、次のとおりです。


関連項目:


ロールを使用可能にする方法の詳細は、「権限の付与と取消しが有効になるとき」を参照してください。

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

データベースによって認可されたロールは、そのロールにパスワードを割り当てることで保護できます。パスワードで保護されたロールがユーザーに付与されている場合、そのロールは、適切なパスワードをSET ROLE文で指定することで、使用可能または使用禁止にできます。ただし、ロールがデフォルト・ロールで、接続時に使用可能な場合は、パスワードの入力は不要です。

例4-2「パスワードによって認可されるユーザー・ロールの作成」は、clerkというロールを作成するCREATE ROLE文を示しています。このロールを使用可能にするには、パスワードmorework2doを入力する必要があります。


注意:


マルチバイト・キャラクタ・セットを使用するデータベースの場合も、ロールのパスワードにはシングルバイト・キャラクタのみを使用してください。マルチバイト・キャラクタのパスワードは受け入れられません。パスワードのガイドラインは、「パスワードの保護に関するガイドライン」のガイドライン1を参照してください。

アプリケーションを使用したロールの認可

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

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

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

例4-4 PL/SQLパッケージによって認可されるアプリケーション・ロールの作成

CREATE ROLE admin_role IDENTIFIED USING hr.admin;

ログイン時に、ユーザー・プロファイルで指定されたユーザーのデフォルト・ロールを使用可能にすると、アプリケーション・ロールはチェックされません。

セキュア・アプリケーション・ロールの詳細は、次の各項を参照してください。

外部ソースを使用したロールの認可

オペレーティング・システムまたはネットワーク・クライアントによって認可されるロールを作成できます。

例4-5では、accts_recという名前のロールを作成しています。このロールを使用可能にするには、その前に、ユーザーが外部ソースによって認可されている必要があります。

例4-5 外部ソースによって認可されるロールの作成

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

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

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

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


関連項目:


オペレーティング・システムによって付与されるロールの詳細は、「オペレーティング・システムまたはネットワークを使用したロールの付与」を参照してください。

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

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

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

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

ロールはグローバル・ロールとして定義できます。この場合、そのロールを使用するために(グローバル)ユーザーはエンタープライズ・ディレクトリ・サービスによる認可を受ける必要があります。グローバル・ロールは、権限とロールを付与することによってデータベース内でローカルに定義しますが、グローバル・ロール自体をそのデータベース内のユーザーや他のロールに付与することはできません。グローバル・ユーザーがデータベースへの接続を試みると、エンタープライズ・ディレクトリへの問合せが実行され、そのユーザーに対応付けられたグローバル・ロールが取得されます。

例4-6では、グローバル・ロールを作成しています。

例4-6 グローバル・ロールの作成

CREATE ROLE supervisor IDENTIFIED GLOBALLY;

グローバル・ロールは、エンタープライズ・ユーザー・セキュリティの構成要素の1つです。グローバル・ロールは1つのデータベースにのみ適用されますが、エンタープライズ・ディレクトリに定義されたエンタープライズ・ロールに付与できます。エンタープライズ・ロールは複数データベースのグローバル・ロールを含んだディレクトリ構造であり、エンタープライズ・ユーザーに付与できます。

ユーザーのグローバル認証とグローバル認可、およびエンタープライズ・ユーザー管理におけるロールの概要については、「グローバルなユーザー認証と認可の構成」を参照してください。


関連項目:


エンタープライズ・ユーザー管理の実装の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

ロールの付与と取消し

ロールには、システム権限またはスキーマ・オブジェクト権限を付与できます。任意のロールを任意のデータベース・ユーザーまたは別のロールに付与できます。ただし、ロールをそのロール自体に付与することはできません。また、ロールを循環的に付与することもできません。つまり、ロールYがあらかじめロールXに付与されている場合、ロールXをロールYに付与することはできません。

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

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

ユーザーや別のロールに対してロールを付与したり、取り消すには、次のいずれかの方法を使用します。

  • Oracle Enterprise Manager Database Control

  • SQL文のGRANTおよびREVOKE

ロールに対して権限を付与または取り消す場合にも同じオプションを使用します。

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

GRANT ANY ROLEシステム権限があるユーザーは、グローバル・ロールを除き、他のユーザーの任意のロールまたはデータベースのロールを付与したり、取り消すことができます。(グローバル・ロールは、Oracle Internet Directoryなどのディレクトリで管理されますが、グローバル・ロールの権限は単一のデータベース内に格納されます)。デフォルトでは、この権限はSYSまたはSYSTEMユーザーに付与されます。このシステム権限は非常に強力であるため、付与する際は注意が必要です。

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


関連項目:


グローバル・ロールの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

ロールの削除

状況によっては、データベースからロールを削除した方がよい場合があります。削除したロールを付与されていたすべてのユーザーとロールのセキュリティ・ドメインは、削除したロール権限がなくなったことを反映するために、ただちに変更されます。削除したロールによって間接的に付与されていたロールもすべて、関連するセキュリティ・ドメインから削除されます。ロールを削除することによって、すべてのユーザーのデフォルト・ロール・リストからそのロールが自動的に削除されます。

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

ロールは、SQL文DROP ROLEを使用して削除します。ロールを削除するには、DROP ANY ROLEシステム権限またはADMIN OPTION付きのロールが付与されている必要があります。

次の文は、ロールCLERKを削除します。

DROP ROLE clerk;

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

この項では、SQL*Plusユーザーによるデータベース・ロールの使用を制限する機能について説明します(これによって、セキュリティに関わる深刻な問題を回避できます)。

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

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

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

たとえば、次の使用例を考えてみます。

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

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

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

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

PRODUCT_USER_PROFILE表を介したロールの制限

SQL*Plus環境で特定のSQLおよびSQL*Plusコマンドをユーザーごとに使用禁止にするには、PRODUCT_USER_PROFILE表を使用します。この表はSYSTEMスキーマにあります。Oracle DatabaseではなくSQL*Plusが、このセキュリティを規定します。GRANTREVOKEおよびSET ROLEコマンドへのアクセスを制限して、ユーザーによるデータベース権限の変更を制御することもできます。

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

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

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

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

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

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


関連項目:


PRODUCT_USER_PROFILE表の詳細は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください。

ストアド・プロシージャを使用したビジネス・ロジックのカプセル化

ストアド・プロシージャは、ビジネス・ロジックによって権限の使用をカプセル化し、適正なビジネス・トランザクションのコンテキストでのみ権限が実行されるようにします。たとえば、アプリケーション開発者は、employees表にある従業員の名前および住所を、通常の勤務時間内にのみ更新するプロシージャを作成できます。また、セキュリティ管理者は、人事部門の担当者にemployees表のUPDATE権限を付与するのではなく、プロシージャのみに権限を付与できます。これによって、人事部門の担当者が権限を使用できるのはプロシージャのコンテキスト内のみになり、employees表を直接更新できなくなります。

セキュア・アプリケーション・ロールを使用したロール権限の保護

セキュア・アプリケーション・ロールは、認可されたPL/SQLパッケージ(またはプロシージャ)でのみ使用可能にできるロールです。PL/SQLパッケージ自体には、アプリケーションへのアクセスを制御するために必要なセキュリティ・ポリシーが反映されます。

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

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

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

セキュア・アプリケーション・ロールを使用可能にすると、認可されたPL/SQLパッケージがコール・スタックにあることが検証されます。つまり、認可されたPL/SQLパッケージがロールを使用可能にするコマンドを発行しているかどうかが検証されます。また、デフォルトのユーザー・ロールを使用可能にすると、アプリケーション・ロールに対するチェックは実行されません。したがって、ロールを付与する前にセキュリティ・ポリシーによるチェックが実行されるように、セキュア・アプリケーション・ロールをユーザーのデフォルト・ロールにしないことが重要です。

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

オブジェクト権限の管理

この項の内容は、次のとおりです。

オブジェクト権限の概要

オブジェクト権限は、特定のタイプのSQL文を実行するか、または別のユーザーのオブジェクトにアクセスするための権利です。たとえば、次のことをする権利が権限です。

  • データベースへの接続(セッションの作成)

  • 表の作成

  • 他のユーザーの表からの行の選択

  • 他のユーザーのストアド・プロシージャの実行

オブジェクト権限の付与または取消し

オブジェクトの各タイプには、異なるオブジェクト権限が対応付けられています。

ALL [PRIVILEGES]を指定すると、オブジェクトに対して使用可能なすべてのオブジェクト権限を付与したり、取り消すことができます。ALLは権限ではなくショートカットです。つまり、GRANT文およびREVOKE文において1語ですべてのオブジェクト権限を付与したり、取り消すための手段です。ALLを使用してすべてのオブジェクト権限を付与した場合も、権限を個別に取り消すことができます。

同様に、個別に付与した権限をALLを指定してすべて取り消すこともできます。ただし、REVOKE ALLによって整合性制約が削除される場合(整合性制約は取り消そうとしているREFERENCES権限に依存しているため)は、REVOKE文にCASCADE CONSTRAINTSオプションを指定する必要があります。

例4-7では、CASCADE CONSTRAINTSを使用してHRスキーマ内の注文表に対するすべての権限を取り消しています。

例4-7 CASCADE CONSTRAINTSを使用したすべてのオブジェクト権限の取消し

REVOKE ALL
 ON orders FROM hr
 CASCADE CONSTRAINTS;

関連項目:


GRANTオブジェクト権限の完全なリストは、『Oracle Database SQL言語リファレンス』を参照してください。

スキーマ・オブジェクト権限の管理

A スキーマ・オブジェクト権限とは、特定のスキーマ・オブジェクトに対して特定のアクションを実行する権限です。

各タイプのスキーマ・オブジェクトごとに、異なるオブジェクト権限があります。オブジェクト権限の例には、departments表から行を削除する権限があります。

クラスタ、索引、トリガー、データベース・リンクなど、一部のスキーマ・オブジェクトには、対応付けられたオブジェクト権限がありません。これらのオブジェクトの使用は、システム権限によって決定されます。たとえば、クラスタを変更するには、ユーザーはそのクラスタを所有しているか、またはALTER ANY CLUSTERシステム権限が必要です。

次の各項では、このような権限の付与と取消しについて説明します。

次の各項では、特定のスキーマ・オブジェクトに適用されるオブジェクト権限について説明します。

スキーマ・オブジェクト権限の付与と取消し

スキーマ・オブジェクト権限は、ユーザーとロールに対して付与したり、取り消すことができます。オブジェクト権限をロールに付与した場合は、その権限を選択的に使用可能にできます。

ユーザーとロールに対するオブジェクト権限の付与と取消しには、次のいずれかを使用できます。

  • SQL文のGRANTおよびREVOKE

  • Oracle Enterprise Manager Database Control


関連項目:


Database Controlの詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

スキーマ・オブジェクト権限を付与できるユーザー

ユーザーは、自分のスキーマに含まれているスキーマ・オブジェクトに関しては、すべてのオブジェクト権限が自動的に付与されています。ユーザーは、自分が所有するスキーマ・オブジェクトに対するオブジェクト権限を、他のユーザーやロールに付与できます。GRANT ANY OBJECT PRIVILEGEがあるユーザーは、GRANT文のGRANT OPTION句を使用してもしなくても、他のユーザーに対して指定のオブジェクト権限を付与したり取り消すことができます。この句を指定しない場合、権限受領者はその権限を使用できますが、別のユーザーには付与できません。


関連項目:


GRANTおよびGRANT ANY OBJECT PRIVILEGEの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

シノニムを持つ権限の使用

スキーマ・オブジェクトとそのシノニムは、権限に関しては等価です。つまり、表、ビュー、順序、プロシージャ、ファンクションまたはパッケージについて付与されるオブジェクト権限は、その基礎となるオブジェクトを名前で参照するかシノニムを使用するかにかかわらず、適用されます。

たとえば、jward.empという表にjward.employeeというシノニムがあると仮定します。ユーザーjwardが次の文を発行するとします。

GRANT SELECT ON emp TO swilliams;

ユーザーswilliamsは、名前またはシノニムjward.employeeを使用して表を参照することによって、jward.empを問い合せることができます。

SELECT * FROM jward.emp;
SELECT * FROM jward.employee;

表、ビュー、順序、プロシージャ、ファンクションまたはパッケージに対するオブジェクト権限を、そのオブジェクトのシノニムに付与した場合の結果は、シノニムを使用しない場合と同じです。たとえば、jwardemp表に対するSELECT権限をswilliamsに付与する場合、jwardは次のどちらの文でも使用できます。

GRANT SELECT ON emp TO swilliams;
GRANT SELECT ON employee TO swilliams;

シノニムが削除された場合は、そのシノニムを指定して権限が付与されていた場合でも、基礎になるスキーマ・オブジェクトに対して付与された権限はすべて有効なままです。

表に対する権限の管理

表に対するスキーマ・オブジェクト権限によって、DML(データ操作言語)またはDDL(データ定義言語)操作レベルでの表のセキュリティが実現します。

次の各項では、表に対する権限とDMLおよびDDL操作について説明します。

表に対する権限がDML操作に与える影響

表またはビューでDELETEINSERTSELECTおよびUPDATEの各DML操作を使用する権限を付与できます。これらの権限は、表のデータの問合せや操作が必要なユーザーとロールに対してのみ付与してください。

表に対するINSERT権限とUPDATE権限は、表の特定の列に制限できます。選択的なINSERT権限を付与されたユーザーは、選択した列に値を持つ行を挿入できます。他のすべての列には、NULLまたはその列のデフォルト値が挿入されます。選択的なUPDATE権限によって、ユーザーは行の特定の列に限ってその値を更新できます。機密データに対するユーザー・アクセスを制限するには、INSERT権限とUPDATE権限を選択的に使用します。

たとえば、データ入力ユーザーにemployees表のsalary列を変更させないようにするには、そのsalary列を除外した選択的なINSERT権限またはUPDATE権限を付与できます。また、salary列を除外したビューによって、同じ制限をさらに高いセキュリティ・レベルで実現できます。


関連項目:


DML操作の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

表に対する権限がDDL操作に与える影響

ALTERINDEXおよびREFERENCESの各権限は、表に対するDDL操作の実行を許可します。これらの権限によって、他のユーザーは表への依存性を変更または作成できるため、権限の付与は控えめに行う必要があります。

表に対してDDL操作を実行するユーザーには、さらに他のシステム権限やオブジェクト権限が必要な場合があります。たとえば、表にトリガーを作成するには、その表に対するALTER TABLEオブジェクト権限とCREATE TRIGGERシステム権限の両方が必要です。

INSERT権限やUPDATE権限と同様に、REFERENCES権限は、表の特定の列に付与できます。REFERENCES権限を付与されたユーザーは、付与の対象となった表を、自分の表の中に作成する外部キーの親キーとして使用できます。外部キーの存在によって、親キーに対して実行できるデータ操作と表の変更が制限されるため、このアクションは特殊な権限によって制御されます。列固有のREFERENCES権限によって、権限受領者が使用できるのは、指定された列(この列には、当然、親表の主キーまたは一意キーが最低1つ含まれている)に制限されます。


関連項目:


主キー、一意キーおよび整合性制約の詳細は、『Oracle Database概要』のデータ整合性に関する項を参照してください。

ビューに対する権限の管理

この項の内容は、次のとおりです。

ビューに対する権限の概要

ビューとは、1つ以上の表から選択されたデータを表現したもので、他のビュ-が含まれていることもあります。ビューには、基礎となる表の構造が表示されます。ビューに表示されたデータは、ストアド・クエリーの結果とみなすことができます。ビュー内に実際のデータはなく、表示する内容は基礎となる表とビューから導出されます。ビューを問い合せて、表示するデータを変更できます。ビュー内のデータは更新または削除でき、新規データも挿入できます。これらの操作は、ビューの基礎である表を直接変更するため、実表の整合性制約とトリガーに従います。

DMLオブジェクト権限は、表の場合と同様にビューに対しても適用できます。ビューに対するスキーマ・オブジェクト権限は、ビューの導出元の実表に実際に影響を与える様々なDML操作を許可します。

ビューの作成に必要な権限

ビューを作成するには、次に示す要件を満たす必要があります。

  • 次のどちらかのシステム権限が、明示的に、またはロールを介して付与されている必要があります。

    • CREATE VIEWシステム権限(自分のスキーマ内にビューを作成するため)

    • CREATE ANY VIEWシステム権限(別のユーザーのスキーマ内にビューを作成するため)

  • 次のいずれかの権限が明示的に付与されている必要があります。

    • ビューの基礎となるすべてのベース・オブジェクトに対するSELECTINSERTUPDATEまたはDELETEオブジェクト権限

    • SELECT ANY TABLEINSERT ANY TABLEUPDATE ANY TABLEまたはDELETE ANY TABLEシステム権限

  • さらに、ビューに対するアクセス権を他のユーザーに付与する場合は、ベース・オブジェクトに対するオブジェクト権限がGRANT OPTION句付きで付与されているか、またはADMIN OPTION句によって適切なシステム権限が付与されている必要があります。これらの権限がユーザーにない場合、権限受領者はそのユーザーのビューにアクセスできません。


    関連項目:


    『Oracle Database SQL言語リファレンス』

ビューによる表セキュリティの強化

ビューを使用するために必要な権限は、ビュー自体に対する適切な権限のみです。ビューの基礎となるベース・オブジェクトに対する権限は必要ありません。

ビューの場合は、表に対してさらに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疑似列を使用します。この疑似列の値は、常に現行のユーザーを参照します。このビューでは、列レベルと値ベースのセキュリティを結合しています。

プロシージャに対する権限の管理

この項の内容は、次のとおりです。

プロシージャに対するEXECUTE権限の使用

スタンドアロン・プロシージャ、ファクションおよびパッケージを含め、プロシージャに対するスキーマ・オブジェクト権限は、EXECUTEのみです。この権限は、プロシージャの実行、または必要なプロシージャをコールする他のプロシージャのコンパイルが必要なユーザーにのみ付与してください。

プロシージャの実行とセキュリティ・ドメイン

特定プロシージャに対するEXECUTEオブジェクト権限があるユーザーは、そのプロシージャを実行したり、それを参照するプログラム・ユニットをコンパイルできます。このプロシージャのコール時に、実行時権限チェックは実行されません。EXECUTE ANY PROCEDUREシステム権限があるユーザーは、データベース内の任意のプロシージャを実行できます。プロシージャの実行権限は、ロールを介してユーザーに付与できます。

プロシージャに対する権限が定義者権限に与える影響

定義者と呼ばれるプロシージャの所有者は、参照オブジェクトに対する必要なオブジェクト権限をすべて所有している必要があります。プロシージャの所有者が別のユーザーにそのプロシージャを使用する権限を付与すると、プロシージャで参照されるオブジェクトに対するオブジェクト権限の所有者が、そのユーザーのプロシージャ実行に適用されます。このような権限は、定義者権限と呼ばれます。

所有者以外のプロシージャのユーザーは、実行者と呼ばれます。実行者権限プロシージャの場合は、参照オブジェクトに対する追加の権限が必要ですが、定義者権限プロシージャの場合は不要です。

定義者権限プロシージャのユーザーに必要なのは、そのプロシージャを実行する権限のみで、そのプロシージャでアクセスする基礎となるオブジェクトに対する権限は不要です。これは、定義者権限プロシージャは、その実行者に関係なく、プロシージャを所有するユーザーのセキュリティ・ドメインの下で動作するためです。プロシージャの所有者は、参照オブジェクトに対する必要なオブジェクト権限をすべて所有している必要があります。定義者権限プロシージャのユーザーに付与する権限は、できるかぎり控えめに付与してください。これによって、データベース・アクセスを厳密に制御できます。

定義者権限プロシージャを使用すると、プライベート・データベース・オブジェクトへのアクセスを制御し、データベースのセキュリティ・レベルを強化できます。定義者権限プロシージャを記述し、ユーザーにEXECUTE権限のみを付与することによって、そのプロシージャを介さない場合には、ユーザーが参照オブジェクトにアクセスできないように規定できます。

実行時には、定義者権限ストアド・プロシージャの所有者の権限が、プロシージャの実行前にチェックされます。参照オブジェクトに対して必要な権限が、定義者権限プロシージャの所有者から取り消されていると、所有者もその他のユーザーも、プロシージャを実行できません。


注意:


トリガーの処理は、定義者権限プロシージャと同じパターンに従います。ユーザーは、実行権限があるSQL文を実行します。このSQL文の実行結果として、トリガーが起動されます。トリガーされたアクション内の文は、そのトリガーを所有するユーザーのセキュリティ・ドメインで一時的に実行されます。


関連項目:


『Oracle Database概要』のトリガーに関する項を参照してください。

プロシージャに対する権限が実行者権限に与える影響

実行者権限プロシージャは、すべての実行者権限で実行されます。ロールは、定義者権限プロシージャによって実行者権限プロシージャが直接または間接的にコールされないかぎり有効です。実行者権限プロシージャのユーザーには、そのプロシージャが実行者のスキーマ内で解決される外部参照を介してアクセスする、オブジェクトに対する権限が(直接、またはロールを介して)必要です。

実行者には、DML文または動的SQL文に埋め込まれているプログラム参照にアクセスする権限が実行時に必要です。これは、この種のプログラム参照は実質的に実行時に再コンパイルされるためです。

PL/SQLファンクションの直接コールなど、他のすべての外部参照の場合、所有者権限はコンパイル時にチェックされ、実行時にはチェックされません。したがって、実行者権限プロシージャのユーザーには、DML文や動的SQL文の外側にある外部参照に対する権限は不要です。 また、実行者権限プロシージャの開発者による権限の付与が必要なのは、プロシージャ自体に対する権限付与のみで、その実行者権限プロシージャによって直接参照されるすべてのオブジェクトに対する権限付与は必要ありません。

複数のプログラム・ユニットで構成したソフトウェア・バンドルを作成し、一部のプログラム・ユニットには定義者権限を、残りのプログラム・ユニットには実行者権限を付与すると、プログラムのエントリ・ポイントを限定できます(コントロール・ステップイン)。エントリ・ポイント・プロシージャの実行権限があるユーザーは、内部プログラム・ユニットも間接的に実行できますが、内部プログラムを直接コールすることはできません。 問合せ処理を厳密に制御するには、PL/SQLパッケージ仕様を明示的なカーソルを使用して作成できます。


関連項目:

  • 「Oracle Virtual Private Databaseポリシーの構成」

  • Oracle Databaseで名前の解決を処理する方法と、実行者権限および定義者権限を使用して実行時の権限チェックを処理する方法の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

  • CREATE PACKAGE文で明示的なカーソルを定義する方法の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。


プロシージャの作成または変更に必要なシステム権限

プロシージャを作成するユーザーには、CREATE PROCEDUREまたはCREATE ANY PROCEDUREシステム権限が必要です。プロシージャを変更する、つまりプロシージャを手動で再コンパイルするユーザーは、そのプロシージャを所有しているか、ALTER ANY PROCEDUREシステム権限が必要です。

プロシージャを所有するユーザーには、プロシージャ本体で参照されるスキーマ・オブジェクトに対する権限も必要です。プロシージャを作成するには、そのプロシージャによって参照されるすべてのオブジェクトに対する必要な権限(システム権限やオブジェクト権限)が明示的に付与されている必要があります。これらの必要な権限は、ロールを介して取得することはできません。これには、作成中のプロシージャ内でコールするプロシージャに対するEXECUTE権限も含まれます。


注意:


また、トリガーでは、参照オブジェクトに対する権限をトリガーの所有者に対して明示的に付与することが必要です。権限が明示的に、またはロールを介して付与されていても、無名PL/SQLブロックでは任意の権限を使用できます。

プロシージャに対する権限がパッケージおよびパッケージ・オブジェクトに与える影響

パッケージに対するEXECUTEオブジェクト権限を保持するユーザーは、そのパッケージ内の任意のパブリック・プロシージャまたはファンクションを実行し、任意のパブリック・パッケージ変数の値へのアクセスや変更を実行できます。パッケージの各構成メンバーに、特定のEXECUTE権限を付与することはできません。したがって、データベース・アプリケーションのプロシージャ、ファンクションおよびパッケージを開発する場合は、セキュリティの確立に関して2つの選択肢を考慮してください。これらの選択肢について、次の例で説明します。

プロシージャに対する権限およびパッケージとパッケージ・オブジェクト: 例1

例4-8では、2つのパッケージの本体に4つのプロシージャを作成しています。

例4-8 プロシージャに対する権限の影響を受けるパッケージ・オブジェクト

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;

注意:


EXECUTE権限をパッケージに対して付与することで、すべてのパッケージ・オブジェクトへの均一なアクセスが提供されます。

プロシージャに対する権限およびパッケージとパッケージ・オブジェクト: 例2

この例は、単一のパッケージ本体にある4つのプロシージャ定義を示しています。2つの追加スタンドアロン・プロシージャと1つのパッケージが特別に作成され、メイン・パッケージ内に定義されているプロシージャへのアクセスを提供します。

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つのパッケージ内に定義され、宣言されたグローバル変数やカーソルなどを共有できます。トップ・レベルのプロシージャであるhirefire、および追加のパッケージraise_bonusを宣言することによって、選択的なEXECUTE権限をメイン・パッケージ内のプロシージャに対して付与できます。

GRANT EXECUTE ON hire, fire TO big_bosses;
GRANT EXECUTE ON raise_bonus TO little_bosses;

型に対する権限の管理

次の各項では、型、メソッドおよびオブジェクトに対する権限の使用について説明します。

名前付きの型に対するシステム権限

表4-4に、名前付きの型(オブジェクト型、VARRAYおよびネストした表)に対するシステム権限のリストを示します。

表4-4 名前付きの型に対するシステム権限

権限 許可される操作

CREATE TYPE

名前付きの型を自分のスキーマ内に作成できます。

CREATE ANY TYPE

名前付きの型を任意のスキーマ内に作成できます。

ALTER ANY TYPE

任意のスキーマにある名前付きの型を変更できます。

DROP ANY TYPE

任意のスキーマにある名前付きの型を削除できます。

EXECUTE ANY TYPE

任意のスキーマにある名前付きの型を使用および参照できます。


RESOURCEロールには、CREATE TYPEシステム権限が含まれています。DBAロールには、これらの権限すべてが含まれています。

オブジェクト権限

名前付きの型に適用されるオブジェクト権限は、EXECUTEのみです。名前付きの型に対するEXECUTE権限があるユーザーは、その型を使用して次の操作を実行できます。

  • 表の定義

  • リレーショナル表への列の定義

  • 名前付きの型の変数またはパラメータの宣言

EXECUTE権限によって、ユーザーは、型コンストラクタも含めて、その型のメソッドを起動できます。これは、ストアドPL/SQLプロシージャに対するEXECUTE権限と同じです。

メソッド実行モデル

メソッドの実行は、他のストアドPL/SQLプロシージャと同じです。

型の作成と型を使用した表の作成に必要な権限

型を作成するには、次の要件を満たす必要があります。

  • 自分のスキーマに型を作成するには、CREATE TYPEシステム権限が必要です。他のユーザーのスキーマに型を作成するには、CREATE ANY TYPEシステム権限が必要です。この2つの権限は、明示的に、またはロールを介して取得できます。

  • 型の所有者には、その型の定義内で参照されている他のすべての型にアクセスするためのEXECUTEオブジェクト権限が明示的に付与されているか、EXECUTE ANY TYPEシステム権限が付与されている必要があります。所有者は、ロールを介して必要な権限を取得することはできません。

  • 型の所有者が型へのアクセス権を他のユーザーに付与する場合、その所有者には、参照される型に対するEXECUTE権限(GRANT OPTION付きで指定)またはEXECUTE ANY TYPEシステム権限(ADMIN OPTION付きで指定)が必要です。どちらの権限もない型の所有者は、権限不足のため、型へのアクセス権を他のユーザーに付与できません。

型を使用して表を作成するには、表の作成要件と次の要件を満たす必要があります。

  • 表の所有者には、その表で参照されているすべての型にアクセスするためのEXECUTEオブジェクト権限が明示的に付与されているか、EXECUTE ANY TYPEシステム権限が付与されている必要があります。所有者は、ロールを介して必要な権限を取得することはできません。

  • 表の所有者が表へのアクセス権を他のユーザーに付与する場合、その所有者には、参照される型に対するEXECUTE権限(GRANT OPTION付きで指定)またはEXECUTE ANY TYPEシステム権限(ADMIN OPTION付きで指定)が必要です。どちらの権限もない表の所有者は、権限不足のため、型へのアクセス権を他のユーザーに付与できません。


    関連項目:


    表の作成要件については、「表に対する権限の管理」を参照してください。

型の作成と型を使用した表の作成に必要な権限の例

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およびRESOURCEロールは、将来のOracle Databaseのリリースで使用不可になる予定のため、使用しないでください。CONNECTロールが現在保持している権限は、CREATE SESSIONのみです。

型アクセスとオブジェクト・アクセスの権限

DML文に対する列レベルと表レベルの既存の権限は、列オブジェクトと行オブジェクトの両方に適用されます。

表4-5に、オブジェクト表に対する権限をリストします。

表4-5 オブジェクト表に対する権限

権限 許可される操作

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権限がチェックされます。

クライアントの第3世代言語アプリケーション内でオブジェクトの属性を変更すると、Oracle Databaseはオブジェクト全体を更新します。したがって、ユーザーにはオブジェクト表に対するUPDATE権限が必要です。オブジェクト表の特定の列のみに対するUPDATE権限では不十分です。これは、アプリケーションによる変更の対象がこれらの特定列に対応する属性のみの場合にも同じです。したがって、Oracle Databaseは、オブジェクト表に対する列レベルの権限はサポートしていません。

型の依存性

プロシージャや表などのストアド・オブジェクトと同様に、他のオブジェクトから参照される型を依存性があると呼びます。表が依存する型については、特殊な問題点がいくつかあります。表には、アクセス用の型定義に依存するデータが含まれているため、その型を変更すると、格納されているすべてのデータにアクセスできなくなります。変更によってこのような結果になるのは、型に必要な権限が取り消された場合や、型または依存型が削除された場合です。いずれかのアクションが発生すると、表は無効になり、アクセスできなくなります。

必要な権限が再び付与されると、権限がないために無効になった表は自動的に有効になり、アクセスできるようになります。依存型が削除されたことで無効になった表は、アクセス不能のままで、実行できるアクションは表の削除のみです。

型に対する権限の取消しや型の削除は重大な影響があるため、デフォルトでは、SQL文のREVOKEDROP TYPEは限定されたセマンティクスで実装されます。つまり、どちらの文でも、名前付きの型が表または型に依存している場合は、エラーが戻されて文は取り消されます。ただし、どちらの文も、FORCE句を使用すると常に正常終了します。依存する表がある場合、その表は無効になります。


関連項目:


REVOKEDROP TYPEおよびFORCE句の使用方法の詳細は、『Oracle Databaseリファレンス』を参照してください。

ユーザー権限とロールの付与

この項の内容は、次のとおりです。

ロールは、中間層またはプロキシを介して接続したユーザーにも付与できます。この操作については、「中間層サーバーを使用したプロキシ認証」を参照してください。

システム権限とロールの付与

システム権限とロールを他のユーザーやロールに付与するには、GRANT SQL文を使用します。次の権限が必要です。

  • システム権限を付与するには、ユーザーにADMIN OPTION付きのシステム権限またはGRANT ANY PRIVILEGEシステム権限が付与されている必要があります。

  • ロールを付与するには、ユーザーにADMIN OPTION付きのロールまたはGRANT ANY ROLEシステム権限が付与されている必要があります。

例4-9では、システム権限CREATE SESSIONaccts_payロールをユーザーjwardに付与しています。

例4-9 ユーザーへのシステム権限とロールの付与

GRANT CREATE SESSION, accts_pay TO jward;

注意:


オブジェクト権限は、同じGRANT文でシステム権限やロールと同時に付与することはできません。

ADMIN OPTIONの付与

WITH ADMIN OPTION句を指定して権限またはロールを付与されたユーザーまたはロールは、次のような拡張機能を使用できます。

  • 権限受領者は、データベース内の任意のユーザーまたは他のロールに対して、システム権限またはロールの付与または取消しができます。ただし、自分自身からロールを取り消すことはできません。

  • 権限受領者は、ADMIN OPTION付きのシステム権限やロールを付与できます。

  • ロールの権限受領者は、そのロールを変更または削除できます。

例4-10 では、new_dbaロールをWITH ADMIN OPTION句付きでユーザーmichaelに付与しています。

例4-10 ADMIN OPTIONの付与

GRANT new_dba TO michael WITH ADMIN OPTION;

ユーザーmichaelは、new_dbaロール内の権限をすべて暗黙的に使用できることに加え、必要に応じてnew_dbaロールを付与、取消しおよび削除できます。このように、ADMIN OPTIONは非常に強力な機能であるため、このオプションを付けてシステム権限やロールを付与する際は、十分に注意してください。通常、これらの権限はセキュリティ管理者向けに用意されており、システム内の他の管理者やユーザーに付与することはほとんどありません。


注意:


ユーザーがロールを作成すると、そのロールは自動的にADMIN OPTION付きでその作成ユーザーに付与されます。

GRANT文を使用した新規ユーザーの作成

Oracle Databaseでは、GRANT文を使用して新しいユーザーを作成できます。IDENTIFIED BY句を使用することで、ユーザー名またはパスワードがデータベースに存在しない場合も、指定したユーザー名とパスワードで新しいユーザーが作成されます。

例4-11では、新規ユーザーとしてpsmithを作成し、CREATE SESSIONシステム権限をpsmithに付与しています。

例4-11 GRANT文を使用した新規ユーザーの作成

GRANT CREATE SESSION TO psmith IDENTIFIED BY password;

オブジェクト権限の付与

GRANT文を使用すると、ロールとユーザーにオブジェクト権限を付与できます。オブジェクト権限を付与するには、次のいずれかの条件を満たしている必要があります。

  • 指定するオブジェクトを所有している。

  • GRANT ANY OBJECT PRIVILEGEシステム権限を付与されている。この権限を使用すると、オブジェクト所有者のかわりに権限の付与と取消しを実行できます。

  • 所有者からオブジェクト権限を付与されるときに、WITH GRANT OPTION句が指定されている。


    注意:


    同じGRANT文で、オブジェクト権限とともにシステム権限とロールを付与することはできません。

例4-12では、emp表のすべての列に対するSELECTINSERTおよびDELETEのオブジェクト権限をユーザーjfeetsmithに付与しています。

例4-12 ユーザーへのオブジェクト権限の付与

GRANT SELECT, INSERT, DELETE ON emp TO jfee, tsmith;

salaryビューのすべてのオブジェクト権限をユーザーjfeeに付与するには、次の例のようにALLキーワードを使用します。

GRANT ALL ON salary TO jfee;

注意:


権限受領者は、最初の権限付与にGRANT OPTIONが含まれていないかぎり、オブジェクトへのアクセス権を再度付与することはできません。したがって、前述の例では、jfeeGRANT文を使用してオブジェクト権限を他の誰かに付与することができません。

GRANT OPTIONの指定

GRANT文にWITH GRANT OPTION句を指定すると、権限受領者はオブジェクト権限を他のユーザーやロールに付与できます。スキーマ内にオブジェクトを格納しているユーザーには、関連するすべてのオブジェクト権限がGRANT OPTION付きで自動的に付与されます。この特別な権限によって、権限受領者の権限は次のように拡張されます。

  • 権限受領者は、データベース内の任意のユーザーに対して、GRANT OPTION付きまたはGRANT OPTIONなしでオブジェクト権限を付与できます。また、データベース内の任意のロールに対してもオブジェクト権限を付与できます。

  • 次の2つの条件が成立する場合、権限受領者は表に対するビューを作成し、そのビューの対応する権限をデータベース内の任意のユーザーまたはロールに対して付与できます。

    • 権限受領者が、表に対するGRANT OPTION付きのオブジェクト権限を受領している。

    • 権限受領者に、CREATE VIEWまたはCREATE ANY VIEWシステム権限がある。


注意:


オブジェクト権限をロールに付与する場合、GRANT OPTIONは無効です。Oracle Databaseでは、ロールによるオブジェクト権限の伝播を禁止しているため、ロールの権限受領者は、ロールを介して受領したオブジェクト権限を他に伝播することはできません。

オブジェクト所有者にかわるオブジェクト権限の付与

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文によって生成された監査レコードには、常に権限付与を実際に実行したユーザーが示されます。

たとえば、次の使用例を考えてみます。 ユーザーadamsGRANT ANY OBJECT PRIVILEGEシステム権限があります。 他の付与権限は所持していないとします。このユーザーが次の文を発行します。

GRANT SELECT ON HR.EMPLOYEES TO blake WITH GRANT OPTION;

DBA_TAB_PRIVSビューを調べると、hrが権限付与者として表示されていることがわかります。

SELECT GRANTEE, OWNER, GRANTOR, PRIVILEGE, GRANTABLE
  FROM DBA_TAB_PRIVS
  WHERE TABLE_NAME = 'EMPLOYEES' and OWNER = 'HR';

GRANTEE  OWNER GRANTOR PRIVILEGE    GRANTABLE
-------- ----- ------- -----------  ----------
BLAKE    HR    HR       SELECT      YES

ユーザーblakeにもGRANT ANY OBJECT PRIVILEGEシステム権限があり、このユーザーが次の文を発行します。

GRANT SELECT ON HR.EMPLOYEES TO clark;

この場合は、DBA_TAB_PRIVSビューを再び問い合せると、blakeが権限付与者として表示されます。

GRANTEE  OWNER GRANTOR  PRIVILEGE    GRANTABLE
-------- ----- -------- --------     ----------
BLAKE    HR    HR       SELECT       YES
CLARK    HR    BLAKE    SELECT       NO

これは、blakeがすでにhr.employeesに対してGRANT OPTION付きのSELECT権限を持っているためです。

列に対する権限の付与

表の個々の列に対してINSERTUPDATEまたは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;

行レベルのアクセス制御

行レベルで、つまりオブジェクト内でアクセスを制御することもできます。これには、仮想プライベート・データベース(VPD)またはOracle Label Security(OLS)を使用します。

ユーザー権限とロールの取消し

この項の内容は、次のとおりです。

システム権限とロールの取消し

システム権限およびロールを取り消すには、SQL文REVOKEを使用します。 ADMIN OPTION付きでシステム権限またはロールを付与されているユーザーは、他のデータベース・ユーザーまたはロールから権限またはロールを取り消すことができます。取消しを行うユーザーは、権限やロールを最初に付与したユーザーでなくてもかまいません。GRANT ANY ROLEを保持しているユーザーは、任意のロールを取り消すことができます。

次の文は、psmithからCREATE TABLEシステム権限とaccts_recロールを取り消します。

REVOKE CREATE TABLE, accts_rec FROM psmith;

注意:


システム権限またはロールのADMIN OPTIONを選択的に取り消すことはできません。権限またはロールを取り消してから、同じ権限またはロールをADMIN OPTIONを指定せずに再度付与する必要があります。

オブジェクト権限の取消し

オブジェクト権限を取り消すには、次のどちらかの条件を満たしている必要があります。

  • 以前にユーザーまたはロールにオブジェクト権限を付与している。

  • オブジェクト所有者のかわりに権限を付与したり取り消すことができるGRANT ANY OBJECT PRIVILEGEシステム権限を所持している。

取り消すことができるのは、権限付与者として直接認可した権限のみで、GRANT OPTIONを付与した他のユーザーによる権限付与を取り消すことはできません。ただし、連鎖的な影響があります。権限付与者のオブジェクト権限を取り消すと、GRANT OPTIONを使用して伝播されたオブジェクト権限も取り消されます。

最初の権限付与者が次の文を発行すると、ユーザーjfeepsmithから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を指定せずに再度付与する必要があります。ユーザーが自分自身からオブジェクト権限を取り消すことはできません。

オブジェクト所有者にかわるオブジェクト権限の取消し

GRANT ANY OBJECT PRIVILEGEシステム権限を使用すると、オブジェクト所有者が権限付与者である指定のオブジェクト権限を取り消すことができます。この操作を実行できるのは、オブジェクト所有者によって、または所有者のかわりにGRANT ANY OBJECT PRIVILEGEシステム権限を持つユーザーによって、オブジェクト権限が付与されている場合です。

オブジェクト権限が、オブジェクト所有者とREVOKE文を実行するユーザー(特定のオブジェクト権限とGRANT ANY OBJECT PRIVILEGEシステム権限の両方を持つユーザー)の両方によって付与されている場合は、REVOKE文を発行したユーザーによって付与されたオブジェクト権限のみが取り消されます。この使用例については、「オブジェクト所有者にかわるオブジェクト権限の付与」の例を使用して説明します。

ここでは、blakeHR.EMPLOYEESに対するSELECT権限をclarkに付与しているとします。blakeGRANT ANY OBJECT PRIVILEGEシステム権限のみでなく特定のオブジェクト権限も持っているため、この権限付与はblakeに帰属します。ここでは、ユーザーHRHR.EMPLOYEESに対するSELECT権限をユーザーclarkに付与しているとします。DBA_TAB_PRIVSビューの問合せでは、HR.EMPLOYEES表について次の権限付与が有効であることが表示されています。

GRANTEE  OWNER GRANTOR PRIVILEGE    GRANTABLE
-------- ----- ------- -----------  ----------
BLAKE    HR    HR       SELECT       YES
CLARK    HR    BLAKE    SELECT       NO
CLARK    HR    HR       SELECT       NO

ユーザーblakeが次のREVOKE文を発行します。

REVOKE  SELECT ON HR.EMPLOYEES FROM clark;

ユーザーblakeがユーザーclarkに付与したオブジェクト権限のみが削除されます。オブジェクト所有者hrによる権限付与はそのまま残ります。

GRANTEE  OWNER GRANTOR PRIVILEGE    GRANTABLE
-------- ----- ------- -----------  ----------
BLAKE    HR    HR       SELECT      YES
CLARK    HR    HR       SELECT      NO

blakeが再度REVOKE文を発行すると、今度はhrによって付与されたオブジェクト権限が削除されます。

列を選択するオブジェクト権限の取消し

表やビューの列を選択してINSERTUPDATEおよび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文によって、dname列のUPDATE権限がhuman_resourcesロールに再度付与されます。

REFERENCESオブジェクト権限の取消し

REFERENCESオブジェクト権限の権限受領者がその権限を使用して外部キー制約を作成し、その制約が現在も存在している場合、権限付与者がその権限を取り消すには、REVOKE文に必ずCASCADE CONSTRAINTSオプションを指定する必要があります。

REVOKE REFERENCES ON dept FROM jward CASCADE CONSTRAINTS;

CASCADE CONSTRAINTS句を指定すると、取り消されるREFERENCES権限を使用して現在も定義されている外部キー制約が削除されます。

権限の取消しによる連鎖的な影響

権限のタイプによっては、権限の取消しによって連鎖的な影響が発生する場合があります。次の各項で、これについて説明します。

システム権限の取消しによる連鎖的な影響

DDL操作に関連するシステム権限を取り消しても、影響は連鎖しません。この場合、権限を付与したときにADMIN OPTIONを指定したかどうかは関係ありません。たとえば、次のような場合を考えてみます。

  1. セキュリティ管理者が、ADMIN OPTIONを指定して、ユーザーjfeeCREATE TABLEシステム権限を付与します。

  2. ユーザーjfeeが表を作成します。

  3. ユーザーjfeeが、ユーザーpsmithCREATE TABLEシステム権限を付与します。

  4. ユーザーtsmithが表を作成します。

  5. セキュリティ管理者が、ユーザーjfeeからCREATE TABLEシステム権限を取り消します。

  6. ユーザーjfeeが作成した表はそのまま残ります。ユーザーtsmithの表とCREATE TABLEシステム権限はそのまま残ります。

連鎖的な影響は、DML操作に関連するシステム権限を取り消したときに発生する場合があります。ユーザーのSELECT ANY TABLE権限を取り消すと、そのユーザーのスキーマ内に存在し、この権限に依存しているすべてのプロシージャは、権限が再度認可されないかぎり、正常に実行できません。

オブジェクト権限の取消しによる連鎖的な影響

オブジェクト権限を取り消すと、連鎖的な影響が発生する場合があります。次のことに注意してください。

  • DMLオブジェクト権限を取り消すと、そのDMLオブジェクト権限に依存するオブジェクト定義にまで影響が及ぶ可能性があります。たとえば、testプロシージャの本体に、emp表のデータを問い合せるSQL文が記述されているとします。testプロシージャの所有者からemp表のSELECT権限を取り消すと、それ以降そのプロシージャを正常に実行できなくなります。

  • 表に対するREFERENCES権限をユーザーから取り消すと、そのユーザーが定義した外部キー整合性制約の中で、取り消されたREFERENCES権限を必要とする制約が自動的に削除されます。たとえば、ユーザーjwarddept表のdeptno列に対するREFERENCES権限が付与されているとします。このユーザーが、emp表のdeptno列に、dept表のdeptno列を参照する外部キーを作成します。dept表のdeptno列に対するREFERENCES権限を取り消すと、同じ操作でemp表のdeptno列に対する外部キー制約も削除されます。

  • GRANT OPTIONを使用して伝播されたオブジェクト権限付与は、権限付与者のオブジェクト権限が取り消されると取り消されます。たとえば、GRANT OPTION付きのSELECTオブジェクト権限を付与されているuser1が、user2に対してemp表のSELECT権限を付与したとします。その後、user1からSELECT権限を取り消します。このREVOKE文はuser2にも連鎖します。user1user2の取り消されたSELECT権限に依存するオブジェクトもすべて、前述のように影響を受ける可能性があります。

ALTERまたはINDEXオブジェクト権限を取り消しても、ALTERおよびINDEX DDLの各オブジェクト権限を必要とするオブジェクト定義には影響を与えません。たとえば、別のユーザーに属する表に索引を作成したユーザーからINDEX権限を取り消しても、その索引はそのまま残ります。

PUBLICユーザー・グループに対する権限の付与と取消し

ユーザー・グループPUBLICに対して、権限とロールの付与および取消しを実行できます。PUBLICにはすべてのデータベース・ユーザーがアクセスできるため、PUBLICに対して付与されたすべての権限またはロールには、すべてのデータベース・ユーザーがアクセスできます。

セキュリティ管理者とデータベース・ユーザーは、すべてのデータベース・ユーザーが権限またはロールを必要としている場合のみ、PUBLICに権限またはロールを付与してください。これによって、各データベース・ユーザーには常に、現在のグループ・タスクの正常実行に必要な権限のみが付与されているという一般規則が保証されます。

PUBLICから権限を取り消すと、かなりの規模で影響が連鎖する可能性があります。DML操作に関連する権限(SELECT ANY TABLEUPDATE ON empなど)をPUBLICから取り消した場合、再度使用するには、ファンクションとパッケージも含めてデータベース内のすべてのプロシージャを再認可する必要があります。したがって、DMLに関連する権限をPUBLICに付与したり、取り消す場合には注意が必要です。


関連項目:


オペレーティング・システムまたはネットワークを使用したロールの付与

この項の内容は、次のとおりです。

オペレーティング・システムまたはネットワークを使用したロールの付与の概要

セキュリティ管理者がGRANT文とREVOKE文を使用して、ユーザーに対し明示的にデータベース・ロールを付与または取り消すかわりに、Oracle Databaseが稼働しているオペレーティング・システムによって、接続時にユーザーにロールを付与できます。つまり、オペレーティング・システムを使用してロールを管理し、ユーザーのセッション作成時にOracle Databaseにそのロールを渡すことができます。このメカニズムの一部として、ユーザーのデフォルト・ロールや、ADMIN OPTION付きでユーザーに付与するロールを識別できます。オペレーティング・システムを使用してロールを使用するユーザーを認可する場合は、必ずすべてのロールをデータベース内に作成し、GRANT文を使用してそのロールに権限を割り当てる必要があります。

ロールは、ネットワーク・サービスを介しても付与できます。

ユーザーのデータベース・ロールを識別するためにオペレーティング・システムを使用する方法の利点は、Oracleデータベースの権限管理をデータベースの外部で実施できることです。オペレーティング・システムに組み込まれたセキュリティ機能によって、ユーザーの権限が制御されます。 また、このオプションを使用すると、いくつかのシステム・アクティビティのセキュリティを集中管理できるため、次のような状況で役立ちます。

  • MVS版Oracleの管理者が、データベース・ユーザーのロールを識別するためにRACFグループを使用する場合

  • UNIX版Oracleの管理者が、データベース・ユーザーのロールを識別するためにUNIXグループを使用する場合

  • VMS版Oracleの管理者が、データベース・ユーザーのロールを識別するために権限識別子を使用する場合

ユーザーのデータベース・ロールを識別するためにオペレーティング・システムを使用する方法の主なデメリットは、権限管理がロール・レベルでしか実施できないことです。個々の権限は、オペレーティング・システムを使用して付与することはできません。ただし、GRANT文を使用してデータベース内で付与することは可能です。

この機能を使用する際の第2のデメリットは、オペレーティング・システムがロールを管理している場合に、デフォルトではユーザーが共有サーバーまたはその他のネットワーク接続を介してデータベースに接続できないことです。ただし、このデフォルトは「オペレーティング・システムによるロール管理使用時のネットワーク接続の使用」の説明に従って変更できます。


注意:


この項で説明されている機能は、一部のオペレーティング・システムでしか使用できません。これらの機能が使用できるかどうかを確認するには、使用しているオペレーティング・システム固有のOracle Databaseマニュアルを参照してください。

オペレーティング・システムのロール識別機能の使用

セッションの作成時に、データベースがオペレーティング・システムを使用して各ユーザーのデータベース・ロールを識別するように、初期化パラメータOS_ROLESTRUEに設定します(インスタンスが実行中の場合は再起動が必要)。ユーザーがデータベースとのセッションを作成しようとすると、Oracle Databaseはオペレーティング・システムによって識別されるデータベース・ロールを使用して、そのユーザーのセキュリティ・ドメインを初期化します。

ユーザーのデータベース・ロールを識別するために、各Oracle Databaseユーザーのオペレーティング・システム・アカウントには、そのユーザーが使用できるデータベース・ロールを示すオペレーティング・システム識別子が必要です。この識別子は、グループ、権限識別子またはこれに類似する名前で呼ばれています。ロールの指定では、ユーザーのデフォルト・ロールやADMIN OPTION付きのロールを示すこともできます。オペレーティング・システム・レベルでのロールの指定形式は、次のとおりです。この形式は、どのオペレーティング・システムを使用している場合でも同じです。

ora_ID_ROLE[_[d][a]]

次のように値を指定します。

  • IDの定義は、オペレーティング・システムによって異なります。たとえば、VMSでは、IDはデータベースのインスタンス識別子です。MVSではコンピュータ・タイプ、UNIXではシステムIDです。


    注意:


    IDは、ORACLE_SIDと照合する際に大/小文字が区別されます。ROLEでは、大/小文字は区別されません。

  • ROLEは、データベース・ロールの名前です。

  • dは、このロールがデータベース・ユーザーのデフォルト・ロールであることを示すオプション文字です。

  • aは、このロールがADMIN OPTION付きでユーザーに付与されることを示すオプション文字です。このオプション文字を指定することによって、ユーザーはこのロールを他のロールにのみ付与できるようになります。オペレーティング・システムを使用してロールを管理している場合は、ユーザーにロールを付与できません。


    注意:


    dまたはaのいずれかを指定する場合は、その文字の直前にアンダースコア(_)を指定してください。

たとえば、オペレーティング・システム・アカウントが、プロファイルで識別される次のロールを持っているとします。

ora_PAYROLL_ROLE1
ora_PAYROLL_ROLE2_a
ora_PAYROLL_ROLE3_d
ora_PAYROLL_ROLE4_da

対応するユーザーがOracle Databaseのpayrollインスタンスに接続すると、role3role4がデフォルト・ロールになり、role2role4ADMIN OPTION付きで付与されます。

オペレーティング・システムのロール管理機能の使用

オペレーティング・システムによって管理されているロールを使用する場合は、データベース・ロールがオペレーティング・システムのユーザーに付与されることに注意してください。オペレーティング・システム・ユーザーが接続できるデータベース・ユーザーは、認可されたデータベース・ロールを使用できます。このため、OS_ROLES = TRUEを使用している場合は、権限が付与されているオペレーティング・システム・アカウントにデータベース・アカウントを対応付けるために、すべてのOracle DatabaseユーザーをIDENTIFIED EXTERNALLYとして定義することを考慮してください。

OS_ROLESがTRUEに設定されている場合のロールの付与と取消し

OS_ROLESパラメータがTRUEに設定されている場合は、ユーザーに対するロールの付与と取消しがオペレーティング・システムによって完全に管理されます。それまでにGRANT文によってユーザーに付与されたロールは適用されません。ただし、それらのロールはデータ・ディクショナリには残っています。オペレーティング・システム・レベルでのユーザーへのロールの付与のみが適用されます。この場合も、ユーザーは権限をロールとユーザーに付与できます。


注意:


オペレーティング・システムによってADMIN OPTION付きでロールが付与された場合、ユーザーはそのロールを他のロールにのみ付与できます。

OS_ROLESがTRUEに設定されている場合のロールの有効化と無効化

OS_ROLES初期化パラメータがTRUEに設定されている場合、オペレーティング・システムによって付与されたロールは、SET ROLE文を使用して動的に使用可能にできます。ロールがパスワードやオペレーティング・システムによる認可を必要とするように定義されていた場合でも、この文は適用されます。ただし、ユーザーのオペレーティング・システム・アカウントで識別されないロールは、SET ROLE文では指定できません。これは、OS_ROLES = FALSEのときにGRANT文を使用してロールを付与していた場合でも同じです(このようなロールを指定しても無視されます)。

OS_ROLES = TRUEの場合、ユーザーは初期化パラメータMAX_ENABLED_ROLESで指定されている数までロールを使用可能にできます。

オペレーティング・システムによるロール管理使用時のネットワーク接続の使用

オペレーティング・システムでロールを管理する場合、ユーザーは、デフォルトでは共有サーバーを介してデータベースに接続できません。リモート・ユーザーは保護されていない接続を介して別のオペレーティング・システム・ユーザーになりすますおそれがあるため、デフォルトでこのような制限が適用されています。

このようなセキュリティに対する危険性の心配がない場合は、初期化パラメータREMOTE_OS_ROLESTRUEに設定することで、共有サーバーまたはその他のネットワーク接続でオペレーティング・システムのロール管理を使用できます。この変更は、次回インスタンスを起動して、データベースをマウントするときに有効になります。このパラメータのデフォルト設定はFALSEです。

権限の付与と取消しが有効になるとき

付与と取消しがいつ有効になるかは、付与または取り消す対象によって異なります。

現在使用可能なロールは、SESSION_ROLESデータ・ディクショナリ・ビューを問い合せることによって確認できます。

SET ROLE文が付与と取消しに与える影響

ユーザーまたはアプリケーションは、ユーザー・セッション中にSET ROLE文を何度でも使用して、現在そのセッションで使用可能になっているロールを変更できます。ユーザーには、SET ROLE文で指定したロールが、事前に付与されている必要があります。同時に使用可能にできるロールの数を指定するには、初期化パラメータMAX_ENABLED_ROLESを設定します。

例4-13では、すでに付与されているロールclerkを使用可能にして、パスワードを指定しています。

例4-13 SET ROLEを使用したロールの付与とパスワードの指定

SET ROLE clerk IDENTIFIED BY password;

passwordを安全なパスワードに置き換えます。パスワードの最低要件については、「パスワードの最低要件」を参照してください。

例4-14は、SET ROLEを使用してすべてのロールを使用禁止にする方法を示しています。

例4-14 SET ROLEを使用した全ロールの無効化

SET ROLE NONE;

デフォルト・ロールの指定

ユーザーがログインすると、そのユーザーに明示的に付与されている権限と、そのユーザーのデフォルト・ロールに含まれる権限が、すべて使用可能になります。

ユーザーのデフォルト・ロールのリストは、ALTER USER SQL文を使用して設定および変更できます。このALTER USER文は、ユーザーがデータベースに接続するときに、ロールのパスワードを指定しなくても使用可能になるロールを指定します。ユーザーには、そのロールがGRANT文で直接付与されている必要があります。ディレクトリ・サービスなどの外部サービスによって管理されているロール(外部ロールやグローバル・ロール)は、デフォルト・ロールとして指定できません。

例4-15では、ユーザーjaneに対してデフォルト・ロールのpayclerkpettycashを設定しています。

例4-15 ALTER USERを使用したデフォルト・ロールの設定

ALTER USER jane DEFAULT ROLE payclerk, pettycash;

ユーザーのデフォルト・ロールは、CREATE USER文では設定できません。最初にユーザーを作成したときに、ユーザーのデフォルト・ロールはALLに設定されます。これによって、その後ユーザーに付与されるロールはすべてデフォルト・ロールになります。ユーザーのデフォルト・ロールを制限するには、ALTER USER文を使用します。


注意:


ユーザー・ロール以外のロールを作成すると、ロールを作成したユーザーにそのロールが暗黙的に付与され、デフォルト・ロールとして追加されます。MAX_ENABLED_ROLES初期化パラメータが設定されている場合は、ロールの数がMAX_ENABLED_ROLESに指定した数を超えると、ログイン時にエラーが発生します。このエラーを回避するには、ユーザーのデフォルト・ロールの数をMAX_ENABLED_ROLESより少なくします。このため、ユーザー・ロールを作成する前にSYSおよびSYSTEMDEFAULT ROLEの設定を変更する必要があります。MAX_ENABLED_ROLESの詳細は、『Oracle Databaseリファレンス』を参照してください。

ユーザーが使用可能にできるロール数の制限

ユーザーは、初期化パラメータMAX_ENABLED_ROLESで指定された数のロールを使用可能にできます。間接的に付与され、1次ロールが使用可能になった結果として使用可能になるロールもすべてその数に含まれます。データベース管理者(DBA)は、このパラメータの値を変更することによって、この制限を変更できます。各ユーザー・セッションで同時に使用可能にするロール数を増やすには、大きい値を設定します。ただし、この値を大きくすると、各ユーザー・セッションでは、より多くのメモリー領域が必要になります。これは、ユーザー・セッションごとのプログラム・グローバル領域(PGA)サイズがロール当たり4バイト必要となるためです。1人のユーザーが同時に使用可能にできるロールの最大数を決定し、その値をMAX_ENABLED_ROLESパラメータに使用してください。

MAX_ENABLED_ROLES初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

外部ネットワーク・サービスに対するファイングレイン・アクセスの管理

データベースから外部ネットワーク・サービスへのアクセスが必要なユーザーやロールには、ファイングレイン・アクセス・コントロールを構成できます。これによって、特定のユーザー・グループは、付与されている権限に基づいて1つ以上のホスト・コンピュータに接続できます。通常、この機能は、特定のホスト・アドレスで実行されるアプリケーションへのアクセスを制御するために使用します。

この項の内容は、次のとおりです。

データベース・ネットワーク・サービスに対するファイングレイン・アクセスの概要

データベース・ネットワーク・サービスに対するファイングレイン・アクセスを構成するには、アクセス制御リスト(ACL)を作成します。このACLはOracle XML DBに格納されます。アクセス制御リストは、Oracle XML DB自体を使用するか、DBMS_NETWORK_ACL_ADMINおよびDBMS_NETWORK_ACL_UTILITYのPL/SQLパッケージを使用して作成できます。ここでは、これらのパッケージを使用してアクセス制御リストを作成および管理する方法を説明します。Oracle XML DBを使用したアクセス制御リストの作成方法およびアクセス制御リストに関する一般的な概念は、『Oracle XML DB開発者ガイド』を参照してください。

この機能を使用することで、データベース・ユーザーがUTL_TCPUTL_SMTPUTL_MAILUTL_HTTPUTL_INADDRなどのPL/SQLネットワーク・ユーティリティ・パッケージを使用して接続できる外部ネットワーク・ホストが制限されるため、ネットワーク接続のセキュリティが強化されます。この機能を使用しない場合、デフォルトでは、PL/SQLユーティリティ・パッケージは、PUBLICユーザーに付与されるEXECUTE権限付きで作成されるため、データベースへのアクセス権を獲得した侵入者が故意にネットワークを攻撃する可能性があります。

PL/SQLネットワーク・ユーティリティ・パッケージに依存しているアプリケーションのアップグレード

以前のOracle Databaseリリースからアップグレードしているときに、アプリケーションがUTL_TCPUTL_SMTPUTL_MAILUTL_HTTPUTL_INADDRなどのPL/SQLネットワーク・ユーティリティ・パッケージに依存している場合は、そのアプリケーションの実行を試みたときに、次のエラーが発生する可能性があります。

ORA-24247: network access denied by access control list (ACL)

その場合は、この項に記載されている手順を使用してアプリケーションのネットワーク・アクセスを再構成してください。PL/SQLネットワーク・ユーティリティ・パッケージに依存しているアプリケーションの互換性に関する問題については、『Oracle Databaseアップグレード・ガイド』も参照してください。ネットワーク・ユーティリティ・パッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

データベース・ネットワーク・サービスに対するアクセス制御リストの作成

ネットワーク接続用にアクセス制御リストを作成する場合は、共通するユーザー(例: 特定のホスト・コンピュータ上の特定のアプリケーションにアクセスする必要があるユーザー)のグループ専用に1つのアクセス制御リストを作成してください。管理の容易性と良好なシステム・パフォーマンスを確保するために、アクセス制御リストは必要以上に多く作成しないでください。同じユーザー・グループがアクセスできる複数のネットワーク・ホストで、同じアクセス制御リストを共有する必要があります。

DBMS_NETWORK_ACL_ADMINパッケージを使用してアクセス制御リストを作成する手順は、次のとおりです。

手順1: アクセス制御リストとその権限の定義の作成

アクセス制御リストの内容を作成するには、DBMS_NETWORK_ACL_ADMIN.CREATE_ACLプロシージャを使用します。アクセス制御リストには、そのリストの名前、簡単な説明、およびそのリストに関連付ける単一のユーザーまたはロールの権限設定が格納されます。アクセス制御リストでは、各ユーザーまたはロールの権限がアクセス制御エントリ(ACE)としてグループ化されます。アクセス制御リストには、少なくとも1つのユーザーまたはロールに対する権限設定が必要です。


注意:


アクセス制御リストの設定は、Oracle Databaseのインポートまたはエクスポート・ユーティリティ(Oracle Data Pumpなど)を使用してインポートまたはエクスポートすることはできません。

アクセス制御リストを作成する構文は、次のとおりです。

BEGIN
 DBMS_NETWORK_ACL_ADMIN.CREATE_ACL (
  acl          => 'file_name.xml',
  description  => 'file description',
  principal    => 'user_or_role',
  is_grant     => TRUE│FALSE,
  privilege    => 'connect│resolve',
  start_date   => null│timestamp_with_time_zone,
  end_date     => null│timestamp_with_time_zone);
END;

次のように値を指定します。

  • acl: アクセス制御リストのXMLファイル名を入力します。このファイルは、データベースのXML DBリポジトリにある/sys/aclsディレクトリに作成されます。.xml拡張子を指定してください。次に例を示します。

    acl => 'us-example-com-permissions.xml',
    
  • description: ファイルの目的に関する簡単な説明を入力します。次に例を示します。

    description => 'Network connection permission for ACCT_MGR role',
    
  • principal: 権限を付与または拒否する最初のユーザー・アカウントまたはロールを入力します。次に例を示します。

    principal => 'ACCT_MGR',
    

    ユーザー・アカウントまたはロールの名前は大/小文字を区別して入力します。たとえば、ユーザー名prestonがすべて大文字でデータベースに格納されている場合は、大文字と小文字の両方を使用したり、小文字で入力しても機能しません。DBA_USERSビューとDBA_ROLESビューを問い合せることで、現行のデータベース・インスタンス内のユーザー・アカウントとロールを確認できます。通常、ユーザー名とロールは大文字となります。

    複数のユーザーを入力する必要がある場合、このアクセス制御リストのXMLファイルを作成した後、次に説明するDBMS_NETWORK_ACL.ADD_PRIVILEGEプロシージャを使用します

  • is_grant: TRUEまたはFALSEを入力し、権限を付与するか拒否するかを示します。次に例を示します。

    is_grant => TRUE,
    
  • privilege: connectまたはresolveを入力します。この設定は、大/小文字が区別されるため、必ず小文字で入力してください。次に例を示します。

    privilege => 'connect',
    

    UTL_TCPUTL_HTTPUTL_SMTPおよびUTL_MAILのユーティリティ・パッケージを使用してホストに接続するデータベース・ユーザーには、外部ネットワークのホスト・コンピュータへのconnect権限が必要です。かわりに、UTL_INADDRパッケージを使用して、ホストのIPアドレスが指定されたホスト名またはホスト名が指定されたIPアドレスを解決するには、データベース・ユーザーにresolve権限を付与します。

    既存の権限とネットワーク接続の詳細を検索するには、「アクセス制御リストに関する情報の検索」で説明しているデータ・ディクショナリ・ビューを使用できます。

  • start_date: (オプション)アクセス制御エントリ(ACE)の開始日をTIMESTAMP WITH TIME ZONE書式(YYYY-MM-DD HH:MI:SS.FF TZR)で入力します。開始日を指定すると、アクセス制御エントリは指定日以降にのみ有効になります。デフォルトはnullです。たとえば、開始日を米国カリフォルニア州サンフランシスコ(太平洋タイムゾーン)の2008年2月28日午前6時30分に設定するには、次のように指定します。

    start_date => '2008-02-28 06:30:00.00 US/Pacific',
    

    NLS_TIMESTAMP_FORMAT初期化パラメータは、デフォルトのタイムスタンプ書式を設定します。詳細は、『Oracle Databaseリファレンス』を参照してください。

  • end_date: (オプション)アクセス制御エントリ(ACE)の終了日をTIMESTAMP WITH TIME ZONE書式(YYYY-MM-DD HH:MI:SS.FF TZR)で入力します。終了日を指定すると、アクセス制御エントリは指定日を経過すると無効になります。end_dateには、start_date以降の日時を設定する必要があります。デフォルトはnullです。

    たとえば、終了日を米国カリフォルニア州サンフランシスコ(太平洋タイムゾーン)の2008年12月10日午後11時59分に設定するには、次のように指定します。

    end_date => '2008-12-10 23:59:00.00 US/Pacific');
    

ユーザーまたはロールをアクセス制御リストに追加するには、DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGEプロシージャを使用します。構文は、次のとおりです。

BEGIN
 DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE (
  acl         => 'file_name.xml',
  principal   => 'user_or_role',
  is_grant    => TRUE│FALSE,
  privilege   => 'connect│resolve',
  position    => null│value,
  start_date  => null│timestamp_with_time_zone,
  end_date    => null│timestamp_with_time_zone);
END;

このように、権限を追加するためのパラメータは、CREATE_ACLプロシージャのパラメータに類似していますが、descriptionがないことと、複数のユーザーまたはロールの優先順位を設定するpositionパラメータが追加されている点が異なります。ここでは、複数のユーザーやロールを追加しているため、優先順位の設定が必要となる可能性があります。詳細は、「単一アクセス制御リスト内の複数のユーザーとロールに対する優先順位の設定」を参照してください。

この手順で使用できる他のDBMS_NETWORK_ACL_ADMINプロシージャには、DELETE_PRIVILEGEおよびDROP_ACLがあります。

これまでの手順で、ネットワーク・ホストへの接続に必要な権限を定義するアクセス制御リストを作成しました。ただし、このアクセス制御リストは、手順2: 1つ以上のネットワーク・ホストへのアクセス制御リストの割当てを完了するまでは無効です。

手順2: 1つ以上のネットワーク・ホストへのアクセス制御リストの割当て

作成したアクセス制御リストは、1つ以上のネットワーク・ホスト・コンピュータに割り当てることができます。この割当てには、DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACLプロシージャを使用します。

次に例を示します。

BEGIN
 DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL (
  acl         => 'file_name.xml',
  host        => 'network_host',
  lower_port  => null│port_number,
  upper_port  => null│port_number);
END;

次のように値を指定します。

  • acl: ネットワーク・ホストに割り当てるアクセス制御リストのXMLファイル名を入力します(「手順1: アクセス制御リストとその権限の定義の作成」)。このファイルは、データベースのXML DBリポジトリにある/sys/aclsディレクトリに作成されます。.xml拡張子を指定してください。次に例を示します。

    acl => 'us-example-com-permissions.xml',
    
  • host: このアクセス制御リストを割り当てるネットワーク・ホストを入力します。この設定には、ネットワーク・ホストの名前またはIPアドレスを使用できます。ホスト名は大/小文字が区別されます。次に例を示します。

    host => 'us.example.com',
    

    アクセス制御リスト割当てにおけるネットワーク・ホスト・コンピュータの動作の詳細は、次の各項を参照してください。

  • lower_port:(オプション)TCP接続に対するポート範囲の下限を入力します。この設定は、connect権限の場合にのみ使用し、resolve権限の場合は省略します。デフォルトはnullで、ポート制限がない(つまり、すべてのポートにACLが適用される)ことを意味します。次に例を示します。

    lower_port => 80,
    
  • upper_port:(オプション)TCP接続に対するポート範囲の上限を入力します。この設定は、connect権限の場合にのみ使用し、resolve権限の場合は省略します。デフォルトはnullで、ポート制限がない(つまり、すべてのポートにACLが適用される)ことを意味します。次に例を示します。

    upper_port => 3999);
    

    lower_portに値を入力してupper_portnullのままに(または省略)すると、upper_portの設定は、lower_portと同じ設定とみなされます。たとえば、lower_port80に設定し、upper_portを省略すると、このupper_portの設定は80とみなされます。

    アクセス制御リスト割当てにポート範囲が指定されている場合、アクセス制御リストのresolve権限は機能しません。

ホスト・コンピュータ、ドメイン、IPサブネットまたはTCPポート範囲(指定されている場合)に対して指定できるアクセス制御リストは、1つのみです。新しいアクセス制御リストをネットワーク・ターゲットに割り当てると、同じターゲットに割り当てられていた以前のアクセス制御リストの割当ては解除されます。ただし、アクセス制御リストは削除されません。アクセス制御リストを削除するには、DROP_ACLプロシージャを使用します。アクセス制御リスト割当てを解除するには、UNASSIGN_ACLプロシージャを使用します。

アクセス制御リストの作成方法やメンテナンス方法によっては、2つの手順が重複する可能性があります。たとえば、5人のユーザーに対する権限を記載したアクセス制御リストを作成し、そのリストを2台のホスト・コンピュータに適用します。その後、異なる(または追加の)ユーザーと権限を保持するようにこのアクセス制御リストを変更し、異なる(または追加の)ホスト・コンピュータにそのリストを適用します。

アクセス制御リストの変更は、ネットワーク・ホストへの割当ても含めて、すべてトランザクションです。変更内容は、トランザクションがコミットされるまで無効です。

既存の権限とネットワーク接続に関する情報は、表4-6「アクセス制御リストに関する情報を表示するデータ・ディクショナリ・ビュー」に説明されているデータ・ディクショナリ・ビューを使用して確認できます。

DBMS_NETWORK_ACL_ADMINパッケージの使用方法は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

アクセス制御リストの作成例

次の各例は、アクセス制御リストの使用方法を示しています。


関連項目:


管理者がUTL_MAIL PL/SQLパッケージを使用して電子メール・アラートを構成する必要がある場合の、アクセス制御リストの使用方法を示した例については、『Oracle Database Vault管理者ガイド』を参照してください。

単純なアクセス制御リストの作成例

例4-16は、us-example-com-permissions.xmlというアクセス制御リストの作成方法を示しています。このアクセス制御リストは、ACCT_MGRロールを持つユーザーに対して、ホストus.example.comで実行されるネットワーク・サービスへのアクセス権を付与します。

例4-16 1つのロールと1つのネットワーク接続を割り当てるアクセス制御リストの作成

-- First, create the access control list, which includes one role:

BEGIN
 DBMS_NETWORK_ACL_ADMIN.CREATE_ACL (
  acl          => 'us-example-com-permissions.xml',
  description  => 'Network connection permission for ACCT_MGR',
  principal    => 'ACCT_MGR',
  is_grant     => TRUE,
  privilege    => 'connect');
END;

-- Second, assign the access control list a network host:

BEGIN
 DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL (
  acl         => 'us-example-com-permissions.xml',
  host        => 'www.us.example.com',
  lower_port  => 80,
  upper_port  => 80);
END;

この例では、us-example-com-permissions.xmlファイルが/sys/aclsディレクトリに作成されます。これはデフォルトの位置です。XMLファイルは、次のようになります。

<acl description="Network connection permission for ACCT_MGR"
  xmlns="http://xmlns.oracle.com/xdb/acl.xsd"
  xmlns:plsql="http://xmlns.oracle.com/plsql"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://xmlns.oracle.com/xdb/acl.xsd    http://xmlns.oracle.com/xdb/acl.xsd">
  <security-class>plsql:network</security-class>
  <ace>
    <grant>true</grant>
    <principal>ACCT_MGR</principal>
    <privilege><plsql:connect/></privilege>
 </ace>
</acl>

xmlns要素とxsi要素は固定です。テキスト・エディタなどで変更しないでください。

アクセス制御リストの内容はSQL*Plusでチェックできます。例については、『Oracle XML DB開発者ガイド』を参照してください。

複数のホストに複数のロールを割り当てるアクセス制御リストの例

例4-17は、us-example-com-permissions.xmlアクセス制御リストより少し複雑なリストの作成方法を示しています。この例では、複数のロール権限とその優先順位を指定し、複数のホスト・コンピュータに割り当てます。

ホスト名の詳細は、「ネットワーク・ホスト・コンピュータでのワイルドカード文字の使用」および「複数のアクセス制御リスト割当てでのホスト・コンピュータの優先順位」を参照してください。アクセス制御リストXMLファイル内の複数のACE要素の順序を判断するには、「単一アクセス制御リスト内の複数のユーザーとロールに対する優先順位の設定」も参照してください。

例4-17 複数のロールと複数のネットワーク接続を割り当てるアクセス制御リストの作成

-- Create the access control list:

BEGIN
 DBMS_NETWORK_ACL_ADMIN.CREATE_ACL (
  acl          => 'us-example-com-permissions.xml',
  description  => 'Network connection permission for ACCT_MGR and ACCT_CLERK',
  principal    => 'ACCT_MGR',
  is_grant     => TRUE,
  privilege    => 'resolve');
 DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE ( -- Creates the second role privilege
  acl          => 'us-example-com-permissions.xml',
  principal    => 'ACCT_CLERK',
  is_grant     => TRUE,
  privilege    => 'connect',
  position     => null);
END;

-- Assign the access control list to hosts:

BEGIN
 DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL ( -- Creates the first target host
  acl          => 'us-example-com-permissions.xml',
  host         => '*.us.example.com');
 DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL ( -- Creates the second target host 
  acl          => 'us-example-com-permissions.xml',
  host         => '*.uk.example.com',
  lower_port   => 80,
  upper_port   => 99);
END;

us-example-com-permissions.xmlは、次のようになります。

<acl description="Network connection permission for ACCT_MGR and ACCT_CLERK"
  xmlns="http://xmlns.oracle.com/xdb/acl.xsd"
  xmlns:plsql="http://xmlns.oracle.com/plsql"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://xmlns.oracle.com/xdb/acl.xsd    http://xmlns.oracle.com/xdb/acl.xsd">
  <security-class>plsql:network</security-class>
  <ace>
    <grant>true</grant>
    <principal>ACCT_MGR</principal>
    <privilege><plsql:resolve/></privilege>
  </ace>
  <ace>
    <grant>true</grant>
    <principal>ACCT_CLERK</principal>
    <privilege><plsql:connect/></privilege>
  </ace>
</acl>

例4-18は、前述のアクセス制御リストで付与された権限をDBA_NETWORK_ACL_PRIVILEGESデータ・ディクショナリ・ビューに表示する方法を示しています。

例4-18 DBA_NETWORK_ACL_PRIVILEGESビューを使用した付与権限の表示

ACL
ACLID                                  PRINCIPAL  PRIVILEGE IS_GRANT INVERT
START_DATE END_DATE
------------------------------------------
-------------------------------- ---------- -------   -------- -------
---------- ----------
/sys/acls/us-example-com-permissions.xml 2EF86135D0E29B2AE040578CE4043250 ACCT_
MGR   resolve   true       false
/sys/acls/us-example-com-permissions.xml 2EF86135D0E29B2AE040578CE4043250 ACCT_
CLERK connect   true       false


例4-19は、アクセス制御リストのホスト割当てをDBA_NETWORK_ACLSデータ・ディクショナリ・ビューに表示する方法を示しています。

例4-19 DBA_NETWORK_ACLSビューを使用したホスト割当ての表示

HOST                       LOWER_PORT UPPER_PORT
ACL
ACLID
-------------------- ---------- ----------
------------------------------------------
--------------------------------
*.us.example.com
/sys/acls/us-example-com-permissions.xml 2EF86135D0E29B2AE040578CE4043250
*.uk.example.com      80             99
/sys/acls/us-example-com-permissions.xml 2EF86135D0E29B2AE040578CE4043250

これらの例では、ACCT_MGRロールには第1のホストに対するresolve権限があり、ACCT_CLERKロールには第1および第2のターゲット・ホストに対するconnect権限があります。ACCT_MGRロールには、第2のホストに対するresolve権限がありません。これは、第2のホストへの割当てにはポート範囲が指定されているためです。

SQL*Plusを使用してアクセス制御リストの内容をチェックする方法は、『Oracle XML DB開発者ガイド』を参照してください。

ネットワーク・ホスト・コンピュータでのワイルドカード文字の使用

アクセス制御リストをネットワーク・ホスト・コンピュータのグループに割り当てる場合は、アスタリスク(*)ワイルドカード文字を使用できます。たとえば、ドメインに属しているホスト・コンピュータには*.example.comを入力し、IPサブネットに属しているIPアドレスには192.0.2.*を入力します。アスタリスク・ワイルドカードは、最初(ドメインのピリオド(.)の前)または最後(IPサブネットのピリオド(.)の後)に配置する必要があります。たとえば、*.example.comは有効ですが、*example.com*.example.*は無効です。

ワイルドカード文字の使用は、同じホスト・コンピュータに割り当てられている複数のアクセス制御リストの優先順位に影響を与えることに注意してください。

複数のアクセス制御リスト割当てでのホスト・コンピュータの優先順位

ホスト・コンピュータとそのドメインに割り当てられている複数のアクセス制御リストでは、ホスト・コンピュータに割り当てられているアクセス制御リストが、ドメインに割り当てられているアクセス制御リストよりも優先されます。ドメインに割り当てられているアクセス制御リストの優先順位は、サブ・ドメインに割り当てられているアクセス制御リストの優先順位よりも低くなります。

たとえば、ホストserver.us.example.comに割り当てられているアクセス制御リストが、そのドメインに割り当てられている他のアクセス制御リストに先行して最初に選択されます。追加のアクセス制御リストがサブ・ドメインに割り当てられていた場合、優先順位は次のようになります。

  1. server.us.example.com

  2. *.us.example.com

  3. *.example.com

  4. *.com

  5. *

同様に、IPアドレス192.0.2.4に対する優先順位は、次のようになります。

  1. 192.0.2.4

  2. 192.0.2.*

  3. 192.0.*

  4. 192.*

  5. *

ポート範囲指定によるアクセス制御リスト割当てでのホストの優先順位

ポート範囲の指定があるアクセス制御リストがホスト・コンピュータ、ドメインまたはIPサブネットに割り当てられている場合、そのアクセス制御リストは、同じホスト、ドメインまたはIPサブネットに割り当てられているポート範囲の指定がないアクセス制御リストよりも優先されます。

たとえば、server.us.example.comのポート80から99のいずれかのポートへのTCP接続では、ポート範囲外のserver.us.example.comに割り当てられている他のアクセス制御リストに先行して、server.us.example.comでポート80から99が割り当てられているアクセス制御リストが最初に選択されます。

ネットワーク・ホストへのユーザー・アクセスに影響を与える権限割当てのチェック

データベース管理者は、DBA_NETWORK_ACL_PRIVILEGESデータ・ディクショナリ・ビューを使用して、アクセス制御リストでデータベース・ユーザーまたはロールに対して付与または拒否したネットワーク権限を問い合せ、それらの権限が特定の期間のみ有効かどうかを問い合せることができます。現時点でユーザーに権限が付与されているかどうか、ユーザーに割り当てられているロール、アクセス制御エントリの順序などを判断するために、ビューで提供される情報を使用したデータの組合せが必要になる場合があります。このような権限の評価を簡素化するために、次のDBMS_NETWORK_ACL_ADMINファンクションを使用して、アクセス制御リストでユーザーに付与した権限をチェックできます。

  • CHECK_PRIVILEGE: アクセス制御リストで、指定された権限が指定のユーザーに対して付与されているか、拒否されているかどうかをチェックします。このプロシージャは、アクセス制御リストをXML DBリポジトリ内のパスで識別します。パスが判明している単一のアクセス制御リストを評価する場合は、CHECK_PRIVILEGEを使用します。

  • CHECK_PRIVILEGE_ACLID: アクセス制御リストのオブジェクトIDを指定できること以外は、CHECK_PRIVILEGEプロシージャと同じです。CHECK_PRIVILEGE_ACLIDデータ・ディクショナリ・ビューを問い合せる際に複数のアクセス制御リストを評価する必要がある場合は、DBA_NETWORK_ACLSを使用します。各アクセス制御リストについてCHECK_PRIVILEGEを個別に使用するよりも、複数のアクセス制御リストについてCHECK_PRIVILEGE_ACLIDをコールするほうが高いパフォーマンスを確保できます。

データベース管理者権限のないユーザーには、アクセス制御リストにアクセスしたり、DBMS_NETWORK_ACL_ADMINの各ファンクションを起動する権限はありません。ただし、データベース管理者権限のないユーザーは、USER_NETWORK_ACL_PRIVILEGESデータ・ディクショナリ・ビューを問い合せて各自の権限をチェックすることはできます。

データベース管理者およびユーザーは、次のDBMS_NETWORK_ACL_UTILITYファンクションを使用して、ホストが所属しているドメインまたはIPサブネットのリストを生成し、ホストの割当てに従って優先順位別にアクセス制御リストをソートできます。

  • DOMAINS: アクセス制御リストが、指定のネットワーク・ホスト、サブドメインまたはIPサブネットに対する権限に影響を与える可能性があるドメインまたはIPサブネットのリストを戻します。

  • DOMAIN_LEVEL: 指定のホストのドメイン・レベルを戻します。

次の各項では、ユーザーがネットワーク・ホストに接続したり、ドメイン名を解決する際に必要な権限について、データベース管理者およびユーザーがチェックする方法を説明します。

DBAによるユーザーのネットワーク接続およびドメインに対する権限のチェック方法

データベース管理者は、DBA_NETWORK_ACLSビューを問い合せて、指定のホスト・コンピュータについてアクセス制御リストがあるかどうかを判断できます。このビューには、ネットワーク接続またはドメインへのアクセスを決定するアクセス制御リストが表示され、各アクセス制御リストについて、ユーザーのアクセス権限が付与されている(GRANTED)か、拒否されている(DENIED)か、あるいは適用外(NULL)かを確認できます。このビューの問合せを実行できるのは、データベース管理者のみです。

ここでは、データベース管理者による、ネットワーク接続とドメイン名解決に関するユーザー権限のチェック方法について例を示します。

データベース管理者によるユーザーの接続権限のチェック

例4-20は、ユーザーprestonによるwww.us.example.comへの接続について、データベース管理者がユーザーの権限をチェックする方法を示しています。CHECK_PRIVILEGE_ACLIDプロシージャのuserパラメータに入力するユーザー名は、大/小文字が区別されることに注意してださい。この例では、PRESTONというユーザー名は正しい入力ですが、Prestonprestonは誤りとなります。

次のように、DBA_USERSデータ・ディクショナリ・ビューを問い合せることで、現行のデータベース・インスタンス内のユーザーを確認できます。

SELECT USERNAME FROM DBA_USERS;

例4-20 管理者によるネットワーク・ホスト接続に関するユーザー権限のチェック

SELECT HOST, LOWER_PORT, UPPER_PORT, ACL,
   DECODE(
     DBMS_NETWORK_ACL_ADMIN.CHECK_PRIVILEGE_ACLID(aclid,  'PRESTON', 'connect'),
     1, 'GRANTED', 0, 'DENIED', null) PRIVILEGE
FROM DBA_NETWORK_ACLS
WHERE host IN
  (SELECT * FROM
     TABLE(DBMS_NETWORK_ACL_UTILITY.DOMAINS('www.us.example.com')))
 ORDER BY
  DBMS_NETWORK_ACL_UTILITY.DOMAIN_LEVEL(host) DESC, LOWER_PORT, UPPER_PORT;

 HOST                 LOWER_PORT UPPER_PORT ACL                  PRIVILEGE
 -------------------- ---------- ---------- -------------------- ---------
 www.us.example.com           80         80 /sys/acls/www.xml    GRANTED
 www.us.example.com         3000       3999 /sys/acls/www.xml    GRANTED
 www.us.example.com                         /sys/acls/www.xml    GRANTED
 *.example.com                              /sys/acls/all.xml
 *                                          /sys/acls/all.xml

この例では、ユーザーprestonには、www.us.example.comに対して検出されたすべてのネットワーク・ホスト接続について権限が付与されています。 ただし、prestonには、ポート80でのホスト接続についてはアクセス権が付与され、ポート3000から3999でのホスト接続についてはアクセス権が拒否されていると仮定した場合は、ポート80でのホスト接続用に1つのアクセス制御リストを作成し、ポート3000から3999でのホスト接続用に別のアクセス制御リストを作成する必要があります。

データベース管理者によるユーザーのドメイン名解決権限のチェック

例4-21は、ユーザーprestonによるホストwww.us.example.comのドメイン名の解決について、データベース管理者がユーザーの権限をチェックする方法を示しています。この例では、ポート範囲を指定せずにホストに割り当てられているアクセス制御リストのみが表示されています。これは、resolve権限はポート範囲が指定されているアクセス制御リストでは無効なためです(CHECK_PRIVILEGE_ACLIDuserパラメータに入力するユーザー名は、大/小文字が区別されることに注意してください)。

例4-21 管理者によるドメイン名解決権限のチェック

SELECT HOST, ACL, DECODE(
     DBMS_NETWORK_ACL_ADMIN.CHECK_PRIVILEGE_ACLID(aclid, 'PRESTON', 'resolve'),
     1, 'GRANTED', 0, 'DENIED', null) privilege
FROM DBA_NETWORK_ACLS
WHERE host IN
 (SELECT * FROM
    TABLE(DBMS_NETWORK_ACL_UTILITY.DOMAINS('www.us.example.com'))) AND
 LOWER_PORT IS NULL AND UPPER_PORT IS NULL
ORDER BY DBMS_NETWORK_ACL_UTILITY.DOMAIN_LEVEL(host) DESC;

 HOST                 ACL                  PRIVILEGE
 -------------------- -------------------- ---------
 www.us.example.com   /sys/acls/www.xml    GRANTED
 *.example.com        /sys/acls/all.xml
 *                    /sys/acls/all.xml

ユーザーによる各自のネットワーク接続およびドメインに対する権限のチェック方法

ユーザーは、USER_NETWORK_ACL_PRIVILEGESビューを問い合せて、各自のネットワークおよびドメインに関する権限をチェックできます。USER_NETWORK_ACL_PRIVILEGESビューはPUBLICです。したがって、このビューはすべてのユーザーが選択できます。

このビューにはアクセス制御リストは表示されません。このビューでは、ユーザーの権限ステータス(GRANTEDまたはDENIED)が評価され、NULLの場合は除外されます。これは、ユーザーにとって、アクセス制御リストが適用されない時期は知る必要がないためです。つまり、アクセスが明示的に付与または拒否されているネットワーク・ホストのみがユーザーに表示されます。したがって、この出力には、データベース管理者向けのDBA_NETWORK_ACLSビューの出力に表示される*.example.comおよび*は表示されません。

ここでは、ユーザーによる、ネットワーク接続とドメイン名解決に関するユーザー権限のチェック方法について例を示します。

ユーザーによる各自のネットワーク接続権限のチェック

例4-22は、ユーザーprestonが、www.us.example.comへの接続について、自分の権限をチェックする方法を示しています。

例4-22 ユーザーによるネットワーク・ホスト接続に関する権限のチェック

SELECT HOST, LOWER_PORT, UPPER_PORT, STATUS PRIVILEGE
FROM USER_NETWORK_ACL_PRIVILEGES
WHERE host IN
   (SELECT * FROM
      TABLE(DBMS_NETWORK_ACL_UTILITY.DOMAINS('www.us.example.com'))) AND
      PRIVILEGE = 'connect'
ORDER BY DBMS_NETWORK_ACL_UTILITY.DOMAIN_LEVEL(host) DESC, LOWER_PORT;

 HOST                 LOWER_PORT UPPER_PORT ACL                  PRIVILEGE
 -------------------- ---------- ---------- -------------------- ---------
 www.us.example.com           80         80 /sys/acls/www.xml    GRANTED
 www.us.example.com         3000       3999 /sys/acls/www.xml    GRANTED
 www.us.example.com                         /sys/acls/www.xml    GRANTED

ユーザーによる各自のドメイン名解決権限のチェック

例4-23は、ユーザーprestonが、www.us.example.comのドメイン名の解決について、自分の権限をチェックする方法を示しています。

例4-23 ユーザーによるドメイン名解決権限のチェック

SELECT host, status privilege
  FROM user_network_acl_privileges
 WHERE host IN
   (SELECT * FROM
      TABLE(DBMS_NETWORK_ACL_UTILITY.DOMAINS('www.us.example.com'))) AND
      privilege = 'resolve'
ORDER BY DBMS_NETWORK_ACL_UTILITY.DOMAIN_LEVEL(host) DESC;

 HOST                 PRIVILEGE
 -------------------- ---------
 www.us.example.com GRANTED

単一アクセス制御リスト内の複数のユーザーとロールに対する優先順位の設定

デフォルトでは、ユーザーとロールに対する権限は、そのユーザーとロールのアクセス制御リスト内での物理的な位置に基づいて付与または拒否されます。1番目にリストされているユーザーまたはロールに対して権限が最初に付与または拒否され、2番目にリストされているユーザーまたはロールが次に処理され、その後も順に処理されます。たとえば、例4-17のコードでACCT_MGRというロールと、sebastianおよびprestonという2人のユーザーが定義され、次の順序でアクセス制御リストXMLファイルに記載されているとします。

<acl ...>
  ...
  <ace>
    <principal>ACCT_MGR</principal>
    <grant>true</grant>
    <privilege><plsql:connect/></privilege>
   </ace>
  <ace>
    <principal>SEBASTIAN</principal>
    <grant>false</grant>
    <privilege><plsql:connect/></privilege>
  </ace>
  <ace>
    <principal>PRESTON</principal>
    <grant>false</grant>
    <privilege><plsql:connect/></privilege>
  </ace>
</acl>

最初にACCT_MGRに権限が付与され、次にsebastianへの権限が拒否され、その後prestonへの権限が拒否されます。ただし、sebastianprestonACCT_MGRロールが付与されている場合は、そのACCT_MGRロールがリストの最初に記載されるため、この2人のユーザーはログインできます。

この2人のユーザーにはacct_mgrロールが付与されていますが、それぞれの固有のジョブでは、www.example.comホストに対するアクセス権は不要です。位置が逆の場合(sebastianprestonの後にacct_mgrロールが記載されている場合)は、これらのユーザーに対するネットワーク接続権限は拒否されることになります。CREATE_ACL文およびADD_PRIVILEGE文で、ACE要素の物理的な位置に関係なく優先順位を設定するには、position属性を使用します。

たとえば、次の文では、結果のXMLファイルにACE要素が設定される順序は、次のようになります。

  1. 最初にsebastianACE要素が記載されます。

  2. 次にprestonACE要素が記載されます。

  3. 最後にacct_mgrロールが記載されます。

この場合、FALSEに設定されている2人の付与権限はacct_mgrロールより前に評価されるため、いずれのユーザーも接続できません。

BEGIN
 DBMS_NETWORK_ACL_ADMIN.CREATE_ACL (
  acl          => 'us-example-com-permissions.xml',
  description  => 'Network connection permission for ACCT_MGR and users');
  principal    => 'ACCT_MGR',
  is_grant     => TRUE,
  privilege    => 'connect');
 DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE (
  acl          => 'us-example-com-permissions.xml'
  principal    => 'SEBASTIAN',
  is_grant     => FALSE,
  privilege    => 'connect',
  position     => 1);
 DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE (
  acl          => 'us-example-com-permissions.xml'
  principal    => 'PRESTON',
  is_grant     => FALSE,
  privilege    => 'connect',
  position     => 2);
END;

アクセス制御リストに関する情報の検索

表4-6に、既存のアクセス制御リストに関する情報の検索に使用できるデータ・ディクショナリ・ビューをリストします。これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

表4-6 アクセス制御リストに関する情報を表示するデータ・ディクショナリ・ビュー

ビュー 説明

DBA_NETWORK_ACLS

ネットワーク・ホストに対するアクセス制御リスト割当てが表示されます。このビューのSELECT権限は、SELECT_CATALOG_ROLEロールのみに付与されます。

DBA_NETWORK_ACL_PRIVILEGES

ネットワーク・ホストに現在割り当てられ、すべてのアクセス制御リストに定義されているネットワーク権限が表示されます。このビューのSELECT権限は、SELECT_CATALOG_ROLEロールのみに付与されます。

USER_NETWORK_ACL_PRIVILEGES

現行ユーザーがネットワーク・ホストにアクセスするためのネットワーク権限のステータスが表示されます。このビューのSELECT権限はPUBLICに付与されます。


ユーザー権限とロールに関する情報の検索

表4-7に、権限とロールの付与に関する情報を入手するために問合せ可能なデータ・ディクショナリ・ビューをリストします。これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

表4-7 権限とロールに関する付与情報が表示されるビュー

ビュー 説明

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_TAB_PRIVS

データベース内のすべてのオブジェクトに対するすべての権限付与がリストされます。

DBA_ROLES

このビューには、セキュア・アプリケーション・ロールを含めて、データベース内に存在するすべてのロールがリストされます。

DBA_ROLE_PRIVS

ユーザーとロールに付与されているロールがリストされます。

DBA_SYS_PRIVS

ユーザーとロールに付与されているシステム権限がリストされます。

ROLE_ROLE_PRIVS

このビューには、他のロールに付与されているロールが表示されます。表示される情報は、ユーザーがアクセス可能なロールに関するもののみです。

ROLE_SYS_PRIVS

このビューには、ロールに付与されているシステム権限に関する情報が含まれています。表示される情報は、ユーザーがアクセス可能なロールに関するもののみです。

ROLE_TAB_PRIVS

このビューには、ロールに付与されているオブジェクト権限に関する情報が含まれています。表示される情報は、ユーザーがアクセス可能なロールに関するもののみです。

USER_COL_PRIVS

オブジェクト所有者、権限付与者または権限受領者が現行ユーザーである列オブジェクトの権限付与が表示されます。

USER_COL_PRIVS_MADE

権限付与者が現行ユーザーである列オブジェクトの権限付与が表示されます。

USER_COL_PRIVS_RECD

権限受領者が現行ユーザーである列オブジェクトの権限付与が表示されます。

USER_ROLE_PRIVS

現行ユーザーに付与されているロールがリストされます。

USER_TAB_PRIVS

権限受領者が現行ユーザーであるすべてのオブジェクトの権限付与がリストされます。

USER_SYS_PRIVS

現行ユーザーに付与されているシステム権限がリストされます。

USER_TAB_PRIVS_MADE

現行ユーザーが所有しているすべてのオブジェクトの権限付与がリストされます。

USER_TAB_PRIVS_RECD

権限受領者が現行ユーザーであるオブジェクトの権限付与がリストされます。

SESSION_PRIVS

ユーザーに対して現在使用可能になっている権限がリストされます。

SESSION_ROLES

ユーザーに対して現在使用可能になっているロールがリストされます。


ここでは、これらのビューの使用例をいくつか示します。各例では、次の文がすでに発行されていることを前提としています。

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 SELECT, 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 SELECT, DELETE ON emp TO jward;

GRANT INSERT (ename, job) ON emp TO swilliams, jward;

関連項目:


これらのデータ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

付与されているすべてのシステム権限のリスト

次の問合せを実行すると、ロールとユーザーに対して付与されているシステム権限がすべて表示されます。

SELECT * 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

DBA_SYS_PRIVSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

付与されているすべてのロールのリスト

次の問合せを実行すると、ユーザーと他のロールに対して付与されているロールがすべて表示されます。

SELECT * FROM DBA_ROLE_PRIVS;

GRANTEE            GRANTED_ROLE                         ADM
------------------ ------------------------------------ ---
SWILLIAMS          SECURITY_ADMIN                       NO

DBA_ROLE_PRIVSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

ユーザーに付与されているオブジェクト権限のリスト

次の問合せを実行すると、特定のユーザーに対して付与されているオブジェクト権限(列固有の権限を除く)がすべて表示されます。

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

DBA_TAB_PRIVSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

セッションの現在の権限ドメインのリスト

次の問合せを実行すると、発行者が現在使用できるロールがすべてリストされます。

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行のみ表示されます。

SESSION_ROLESビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

データベースのロールのリスト

DBA_ROLESデータ・ディクショナリ・ビューを使用すると、データベースのすべてのロールと各ロールに対して使用されている認証を表示できます。たとえば、次の問合せを実行すると、データベース内のすべてのロールが表示されます。

SELECT * FROM DBA_ROLES;

ROLE                  PASSWORD
----------------      --------
CONNECT               NO
RESOURCE              NO
DBA                   NO
SECURITY_ADMIN        YES

DBA_ROLESビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

ロールの権限ドメイン情報のリスト

ROLE_ROLE_PRIVSROLE_SYS_PRIVSおよびROLE_TAB_PRIVSの各データ・ディクショナリ・ビューには、ロールの権限ドメインに関する情報が含まれています。たとえば、次の問合せを実行すると、system_adminロールに付与されているロールがすべて表示されます。

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

ROLE_ROLE_PRIVSROLE_SYS_PRIVSおよびROLE_TAB_PRIVSの各ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。