6 定義者権限および実行者権限のセキュリティの管理
ユーザー作成プロシージャの実行権限へのアクセス制御で実行者権限および定義者権限を使用すると、セキュリティ上のメリットが得られます。
- 定義者権限および実行者権限について
定義者権限および実行者権限は、ユーザー作成プロシージャまたはプログラム・ユニットの実行に必要な権限へのアクセスを制御するときに使用されます。 - プロシージャに対する権限が定義者権限に与える影響
定義者と呼ばれるプロシージャの所有者は、プロシージャが参照するオブジェクトに対する必要なオブジェクト権限を所有している必要があります。 - プロシージャに対する権限が実行者権限に与える影響
実行者権限プロシージャは、すべての実行者権限で実行されます。 - 実行者権限プロシージャを作成する場合
特定の状況で実行者権限プロシージャを作成することをお薦めします。 - プロシージャ・コールおよびビュー・アクセスの実行者権限の制御
INHERIT PRIVILEGES
権限およびINHERIT ANY PRIVILEGES
権限は、実行者権限プロシージャの実行時に使用される権限を規制します。 - ビューの定義者権限および実行者権限
CREATE VIEW
SQL文でBEQEATH
句を使用して、ユーザー作成ビューで定義者権限と実行者権限を制御できます。 - 定義者権限および実行者権限のコード・ベース・アクセス制御の使用
データベース・ロールをPL/SQLファンクション、プロシージャまたはパッケージに付与するときに使用するコード・ベース・アクセス制御は、定義者権限および実行者権限のプロシージャと一緒に使用すると効果的です。 - データベース・リンクの定義者権限の制御
アプリケーションでデータベース・リンクと定義者権限プロシージャが使用されている場合は、定義者権限プロシージャの権限付与を制御できます。
親トピック: ユーザー認証および認可の管理
6.1 定義者権限および実行者権限について
定義者権限および実行者権限は、ユーザー作成プロシージャまたはプログラム・ユニットの実行に必要な権限へのアクセスを制御するときに使用されます。
定義者権限プロシージャでは、プロシージャが所有者の権限で実行されます。権限は、作成されたスキーマにバインドされます。実行者の権限プロシージャは現行ユーザー(プロシージャを実行するユーザー)の権限で実行されます。
たとえば、ユーザーbixby
が表cust_records
を変更するために設計されるプロシージャを作成し、このプロシージャのEXECUTE
権限をユーザーrlayton
に付与するとします。bixby
が定義者権限でプロシージャを作成した場合、プロシージャはbixby
のスキーマの表cust_records
を検索します。プロシージャが実行者権限で作成された場合、rlayton
が実行すると、プロシージャはrlayton
のスキーマの表cust_records
を検索します。
デフォルトでは、すべてのプロシージャは、定義者権限とみなされます。作成時または変更時に、AUTHID CURRENT_USER
句を使用してプロシージャを実行者権限プロシージャに指定するか、AUTHID DEFINER
句を使用して定義者権限プロシージャに変更できます。
関連項目:
-
定義者権限プロシージャおよび実行者権限プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
-
定義者権限および実行者権限プロシージャの権限の使用を取得する権限分析ポリシーを作成する方法の詳細は、Oracle Database Vault管理者ガイドを参照してください
親トピック: 定義者権限および実行者権限のセキュリティの管理
6.2 プロシージャに対する権限が定義者権限に与える影響
定義者と呼ばれるプロシージャの所有者は、プロシージャが参照するオブジェクトに対する必要なオブジェクト権限を所有している必要があります。
プロシージャ所有者が別のユーザーにそのプロシージャを使用する権限を付与すると、(プロシージャで参照されるオブジェクトに対する)プロシージャ所有者の権限が、権限受領者のプロシージャ実行に適用されます。プロシージャの定義者の権限は、ロールを介してではなく、プロシージャ所有者に直接付与する必要があります。これらは、定義者権限と呼ばれます。
所有者以外のプロシージャのユーザーは、実行者と呼ばれます。実行者権限プロシージャの場合は、参照オブジェクトに対する追加の権限が必要ですが、 定義者権限プロシージャの場合は不要です。
定義者権限プロシージャのユーザーに必要なのは、そのプロシージャを実行する権限のみで、そのプロシージャでアクセスする基礎となるオブジェクトに対する権限は不要です。これは、定義者権限プロシージャは、その実行者に関係なく、プロシージャを所有するユーザーのセキュリティ・ドメインの下で動作するためです。プロシージャの所有者は、参照オブジェクトに対する必要なオブジェクト権限をすべて所有している必要があります。定義者権限プロシージャのユーザーに付与する権限は、できるかぎり控えめに付与してください。これによって、データベース・アクセスを厳密に制御できます。
定義者権限プロシージャを使用すると、プライベート・データベース・オブジェクトへのアクセスを制御し、データベースのセキュリティ・レベルを強化できます。定義者権限プロシージャを記述し、ユーザーにEXECUTE
権限のみを付与することによって、そのプロシージャを介さない場合には、このユーザーが参照オブジェクトにアクセスできないように規定できます。
実行時には、定義者権限プロシージャの所有者の権限によってそのプロシージャの参照オブジェクトへのアクセスが許可されているかどうかが、プロシージャの実行前にチェックされます。参照オブジェクトに対して必要な権限が、定義者権限プロシージャの所有者から取り消されていると、所有者を含むユーザーは、プロシージャを実行できません。
定義者権限プロシージャを使用する場合の例は次のとおりです。表へのアクセスが制限されていないプロシージャを持つAPIを作成する必要があるとします。ただし、一般ユーザーが表のデータを直接選択し、INSERT
文、UPDATE
文およびDELETE
文を使用して変更しないようにする必要があります。これを実行するには、個別の権限の弱いスキーマで、APIを構成する表およびプロシージャを作成します。デフォルトでは各プロシージャは定義者権限ユニットであるため、作成時にAUTHID DEFINER
を指定する必要がありません。次に、EXECUTE
権限をこのAPIを使用する必要があるユーザーに付与しますが、データ・アクセスを許可する権限を付与しないでください。この解決策は、API動作の完全な制御およびユーザーが基礎オブジェクトにアクセスする方法を提供します。
独自のスキーマで、定義者権限プロシージャおよびこれらのプロシージャにアクセスするビューを作成することをお薦めします。このスキーマに非常に弱い権限を付与するか、権限を付与しません。これによって、他のユーザーがこれらのプロシージャまたはビューを実行する場合、このスキーマの不要な高い権限にアクセスしません。
ノート:
トリガーの処理は、定義者権限プロシージャと同じパターンに従います。ユーザーは、実行権限があるSQL文を実行します。このSQL文の実行結果として、トリガーが起動されます。トリガーされたアクション内の文は、そのトリガーを所有するユーザーのセキュリティ・ドメインで一時的に実行されます。トリガーの概要は、『Oracle Database概要』を参照してください。
関連トピック
親トピック: 定義者権限および実行者権限のセキュリティの管理
6.3 プロシージャに対する権限が実行者権限に与える影響
実行者権限プロシージャは、すべての実行者権限で実行されます。
実行者の使用可能な任意のロールを介してその実行者に付与された権限は、定義者権限プロシージャによって実行者権限プロシージャが直接または間接的にコールされないかぎり有効です。実行者権限プロシージャのユーザーには、そのプロシージャが実行者のスキーマ内で解決される外部参照を介してアクセスする、オブジェクトに対する権限(直接またはロールを介して付与されたもの)が必要です。実行者が実行者権限プロシージャを実行する場合、このユーザーは、実行者のすべての権限を一時的に保持します。
実行者には、DML文または動的SQL文に埋め込まれているプログラム参照にアクセスする権限が実行時に必要です。これは、この種のプログラム参照は実質的に実行時に再コンパイルされるためです。
PL/SQLファンクションの直接コールなど、他のすべての外部参照の場合、所有者権限はコンパイル時にチェックされ、実行時にはチェックされません。したがって、実行者権限プロシージャのユーザーには、DML文や動的SQL文の外側にある外部参照に対する権限は不要です。したがって、実行者権限プロシージャの開発者による権限の付与が必要なのは、プロシージャ自体に対する権限付与のみで、その実行者権限プロシージャによって直接参照されるすべてのオブジェクトに対する権限付与は必要ありません。
複数のプログラム・ユニットからなり、そのうちのいくつかは定義者権限、その他は実行者権限とするソフトウェア・バンドルを作成して、プログラム・エントリ・ポイントを制限できます(制御されたステップイン)。エントリ・ポイント・プロシージャの実行権限があるユーザーは、内部プログラム・ユニットも間接的に実行できますが、内部プログラムを直接コールすることはできません。問合せ処理を厳密に制御するには、PL/SQLパッケージ仕様を明示的なカーソルを使用して作成できます。
親トピック: 定義者権限および実行者権限のセキュリティの管理
6.4 実行者権限プロシージャを作成する場合
特定の状況で実行者権限プロシージャを作成することをお薦めします。
これらの状況は次のとおりです。
-
権限の高いスキーマのPL/SQLプロシージャを作成する場合。権限の弱いユーザーがプロシージャを起動する場合、それらのユーザーが実行を許可された部分のみ実行できます。つまり、実行者権限プロシージャは、実行するユーザーの権限で実行されます。
-
PL/SQLプロシージャがSQLを含まず、PL/SQLプロシージャを他のユーザーが使用できる場合。
DBMS_OUTPUT
PL/SQLパッケージは、SQLを含まないすべてのユーザーが使用できるPL/SQLサブプログラムの例です。この状況で実行者権限プロシージャを使用する必要がある理由は、ユニットが実行時にSQL文を発行しないので、実行時システムが権限をチェックする必要がないためです。AUTHID
CURRENT_USER
を指定すると、実行者権限プロシージャがコール・スタックを使用する場合にCURRENT_USER
およびCURRENT_SCHEMA
の値と現在有効なロールが変更されないため、プロシージャの起動がより効率的になります。
関連項目:
-
Oracle Databaseで名前の解決を処理する方法と、実行者権限および定義者権限を使用して実行時の権限チェックを処理する方法の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
-
実行者権限と定義者権限のユニットの違いの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
-
CREATE PACKAGE
文で明示的なカーソルを定義する方法の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: 定義者権限および実行者権限のセキュリティの管理
6.5 プロシージャ・コールおよびビュー・アクセスの実行者権限の制御
INHERIT PRIVILEGES
権限およびINHERIT ANY PRIVILEGES
権限は、実行者権限プロシージャの実行時に使用される権限を規制します。
- スキーマの権限が実行者権限プロシージャの使用に与える影響
権限の低いユーザーが権限の高いユーザーが所有するプロシージャを実行するような場合は、実行者権限プロシージャが便利です。 - INHERIT [ANY] PRIVILEGES権限による権限アクセスの制御方法
INHERIT PRIVILEGES
およびINHERIT ANY PRIVILEGES
権限を使用して、実行者権限プロシージャを保護します。 - 他のユーザーへのINHERIT PRIVILEGES権限の付与
デフォルトで、すべてのユーザーにINHERIT PRIVILEGES
ON USER
newuser
TO PUBLIC
が付与されます。 - 例: 実行するユーザーのINHERIT PRIVILEGESの付与
GRANT
文で、実行するユーザーのINHERIT PRIVILEGES
権限をプロシージャ所有者に付与できます。 - 例: INHERIT PRIVILEGESの取消し
REVOKE
文で、ユーザーのINHERIT PRIVILEGES
権限を取り消すことができます。 - 他のユーザーへのINHERIT ANY PRIVILEGES権限の付与
デフォルトでは、ユーザーSYS
は、INHERIT ANY PRIVILEGES
システム権限を持ち、この権限を他のデータベース・ユーザーまたはロールに付与できます。 - 例: 信頼できるプロシージャ所有者へのINHERIT ANY PRIVILEGESの付与
GRANT
文で、INHERIT ANY PRIVILEGES
権限を信頼できるプロシージャ所有者に付与できます。 - INHERIT PRIVILEGESおよびINHERIT ANY PRIVILEGESの管理
デフォルトでは、PUBLIC
は、新しいユーザー・アカウントおよびアップグレードされたユーザー・アカウントのINHERIT PRIVILEGE
権限を持ち、SYS
ユーザーは、INHERIT ANY PRIVILEGES
権限を持ちます。
親トピック: 定義者権限および実行者権限のセキュリティの管理
6.5.1 スキーマの権限が実行者権限プロシージャの使用に与える影響
権限の低いユーザーが権限の高いユーザーが所有するプロシージャを実行するような場合は、実行者権限プロシージャが便利です。
ユーザーが実行者権限プロシージャ(またはAUTHID CURRENT_USER
句で作成されたPL/SQLプログラム・ユニット)を実行する場合、プロシージャの実行中に実行するユーザーのすべての権限を一時的に継承します。
その期間中に、プロシージャ所有者は、プロシージャを通じて、この実行するユーザーの権限にアクセスできます。次の使用例を考えてみます。
-
ユーザー
ebrown
は、check_syntax
実行者権限プロシージャを作成し、ユーザーjward
にそのEXECUTE
権限を付与します。 -
準プログラマのユーザー
ebrown
は、仕事に必要な最低限のセットの権限のみです。check_syntax
プロシージャは、ebrown
のスキーマにあります。 -
マネージャのユーザー
jward
は、ユーザーebrown
よりさらに強力なセットの権限を持ちます。 -
ユーザー
jward
がcheck_syntax
実行者権限プロシージャを実行する場合、プロシージャは実行中にユーザーjward
より高い権限を継承します。 -
ユーザー
ebrown
がcheck_syntax
プロシージャを所有するため、jward
がcheck_syntax
プロシージャを実行するたびに、ユーザーjward
の権限にアクセスできます。
jward
がプロシージャを実行するたびに権限の弱いebrown
のプロシージャがjward
の高い権限にアクセスできるこのタイプの状況の危険性は、プロシージャ所有者が実行するユーザーの高い権限を悪用できるリスクがあることです。たとえば、ユーザーebrown
は、check_syntax
プロシージャをリライトしてebrown
を上げるかebrown
の不良なパフォーマンス評価レコードを削除して、jward
の高い権限を使用する可能性があります。また、ebrown
は、元から定義者権限プロシージャとしてプロシージャを作成し、EXECUTE
権限をjward
に付与して、後でjward
に通知することなく不正な可能性のある実行者権限プロシージャに変更できた可能性があります。アプリケーション・ユーザーなどのランダムなユーザーが実行者権限プロシージャを使用するデータベースにアクセスできる場合、これらのタイプのリスクが増加します。
ユーザーjward
がebrown
の実行者権限プロシージャを実行する場合、信頼要素が含まれます。ebrown
がjward
の権限にアクセスする場合に悪質な方法でcheck_syntax
プロシージャを使用しないことを確認する必要があります。INHERIT PRIVILEGES
およびINHERIT ANY PRIVILEGES
権限は、ユーザーjward
に対してユーザーebrown
のプロシージャがjward
の権限にアクセスできるかどうかの制御をサポートできます。ユーザーは、実行する実行者権限プロシージャのユーザーへのINHERIT PRIVILEGES
権限を付与または取り消すことができます。SYS
ユーザーは、INHERIT ANY PRIVILEGES
権限を管理します。
6.5.2 INHERIT [ANY] PRIVILEGES権限による権限アクセスの制御方法
INHERIT PRIVILEGES
およびINHERIT ANY PRIVILEGES
権限を使用して、実行者権限プロシージャを保護します。
INHERIT PRIVILEGES
およびINHERIT ANY PRIVILEGES
権限は、ユーザーが実行者権限プロシージャを実行するか、実行者権限プロシージャを参照するBEQUEATH CURRENT_USER
ビューに問い合せる場合に使用される権限を規制します。
ユーザーが実行者権限プロシージャを実行する場合、Oracle Databaseは、プロシージャ所有者が実行するユーザーのINHERIT PRIVILEGES
権限を持っているか、所有者にINHERIT ANY PRIVILEGES
権限が付与されているかを確認します。権限チェックに失敗した場合、Oracle Databaseは、 ORA-06598: INHERIT PRIVILEGES権限が不十分です
エラーを戻しません。
これらの2つの権限の利点は、実行者権限プロシージャを実行するか、BEQUEATH CURRENT_USER
ビューに問い合せる場合、実行するユーザーに権限にアクセスできるユーザーの制御を提供することです。
6.5.3 他のユーザーへのINHERIT PRIVILEGES権限の付与
デフォルトで、すべてのユーザーにINHERIT PRIVILEGES
ON USER
newuser
TO PUBLIC
が付与されます。
付与が行われるのは、ユーザー・アカウントの作成時または以前に作成されたアカウントが現在のリリースにアップグレードされたときです。
実行するユーザーは、他のユーザーのINHERIT PRIVILEGE
権限を取り消して、信頼するユーザーにのみ付与できます。
INHERIT PRIVILEGES
権限の付与の構文は次のとおりです。
GRANT INHERIT PRIVILEGES ON USER invoking_user TO procedure_owner;
詳細は、次のとおりです。
-
invoking_user
は、実行者権限プロシージャを実行するユーザーです。このユーザーは、データベース・ユーザー・アカウントである必要があります。 -
procedure_owner
は、実行者権限プロシージャを所有するユーザーです。この値は、データベース・ユーザー・アカウントである必要があります。INHERIT PRIVILEGES
権限をプロシージャの所有者に付与するかわりに、プロシージャに付与されるロールに権限を付与できます。
次のユーザーまたはロールは、実行者権限プロシージャを実行するユーザーによって付与されるINHERIT PRIVILEGES
権限を持つ必要があります。
-
実行者権限プロシージャを所有するユーザーまたはロール
-
BEQUEATH CURRENT_USER
ビューを所有するユーザーまたはロール
6.5.4 例: 実行するユーザーのINHERIT PRIVILEGESの付与
GRANT
文で、実行するユーザーのINHERIT PRIVILEGES
権限をプロシージャ所有者に付与できます。
例6-1は、実行するユーザーjward
がユーザーebrown
にINHERIT PRIVILEGES
権限を付与する方法を示しています。
例6-1 プロシージャ所有者への実行するユーザーのINHERIT PRIVILEGESの付与
GRANT INHERIT PRIVILEGES ON USER jward TO ebrown;
この文により、jward
が実行するとき、ebrown
が書き込むまたは今後書き込む実行者権限プロシージャがjward
の権限にアクセスできます。
6.5.5 例: INHERIT PRIVILEGESの取消し
REVOKE
文で、ユーザーのINHERIT PRIVILEGES
権限を取り消すことができます。
例6-2は、ユーザーjward
がebrown
の権限の使用を取り消す方法を示しています。
例6-2 INHERIT PRIVILEGESの取消し
REVOKE INHERIT PRIVILEGES ON USER jward FROM ebrown;
6.5.6 他のユーザーへのINHERIT ANY PRIVILEGES権限の付与
デフォルトでは、ユーザーSYS
は、INHERIT ANY PRIVILEGES
システム権限を持ち、この権限を他のデータベース・ユーザーまたはロールに付与できます。
すべてのANY
権限と同様に、信頼できるユーザーまたはロールにのみこの権限を付与します。ユーザーまたはロールにINHERIT ANY PRIVILEGES
権限が付与されると、このユーザーの実行者権限プロシージャは、実行するユーザーの権限にアクセスできます。DBA_SYS_PRIVS
データ・ディクショナリ・ビューを問い合せて、INHERIT ANY PRIVILEGES
権限を付与されたユーザーを確認できます。
6.5.7 例: 信頼できるプロシージャ所有者へのINHERIT ANY PRIVILEGESの付与
GRANT
文で、INHERIT ANY PRIVILEGES
権限を信頼できるプロシージャ所有者に付与できます。
例6-3は、ユーザーebrown
へのINHERIT ANY PRIVILEGES
権限の付与方法を示しています。
例6-3 信頼できるプロシージャ所有者へのINHERIT ANY PRIVILEGESの付与
GRANT INHERIT ANY PRIVILEGES TO ebrown;
強力なユーザーのINHERIT ANY PRIVILEGES
権限の取消しに注意してください。たとえば、ユーザーSYSTEM
が一連の実行者権限プロシージャを作成したとします。SYSTEM
のINHERIT ANY PRIVILEGES
を取り消す場合、INHERIT PRIVILEGE
権限を特に付与しないかぎり、他のユーザーはプロシージャを実行できません。
6.5.8 INHERIT PRIVILEGESおよびINHERIT ANY PRIVILEGESの管理
デフォルトでは、PUBLIC
は、新しいユーザー・アカウントおよびアップグレードされたユーザー・アカウントのINHERIT PRIVILEGE
権限を持ち、SYS
ユーザーは、INHERIT ANY PRIVILEGES
権限を持ちます。
デフォルトでは、様々なOracleで定義されているユーザーの権限の悪用に対して保護できるよう設計されている一連のINHERIT PRIVILEGES
の付与を構成します。
顧客が定義するユーザーのINHERIT PRIVILEGES ON USER
user_name
TO PUBLIC
のデフォルトの付与を取り消して、その特定のユーザーに応じて詳細な付与のINHERIT PRIVILEGES
を付与できます。INHERIT ANY PRIVILEGES
権限を付与されたユーザーを確認するには、DBA_SYS_PRIVS
データ・ディクショナリ・ビューを問い合せます。
監査ポリシーを作成してこれらの2つの権限の付与および取消しを監査できますが、失敗したINHERIT PRIVILEGES権限チェックによって発生する実行時エラーは監査できません。
関連項目:
-
SQLインジェクション攻撃の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
-
GRANT
文およびデフォルトの権限の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
6.6 ビューの定義者権限および実行者権限
CREATE VIEW
SQL文でBEQEATH
句を使用して、ユーザー作成ビューで定義者権限と実行者権限を制御できます。
- ビューの定義者権限および実行者権限の制御について
ユーザー定義ビューを構成して、ビューで参照される実行者権限関数に対応できます。 - CREATE VIEW文のBEQUEATH句の使用
BEQUEATH
は、実行ユーザーの権限を使用してどのように実行者権限関数を実行するかを制御します。 - 実行するユーザーのユーザー名またはユーザーIDの確認
実行者権限または定義者権限を使用するかどうかに基づいて、PL/SQLファンクションを使用して、実行するユーザーを確認できます。 - BEQUEATH DEFINERおよびBEQUEATH_CURRENT_USERビューの確認
ビューがBEQUEATH DEFINER
またはBEQUEATH CURRENT_USER
ビューであるかどうかを確認できます。
親トピック: 定義者権限および実行者権限のセキュリティの管理
6.6.1 ビューの定義者権限および実行者権限の制御について
ユーザー定義ビューを構成して、ビューで参照される実行者権限関数に対応できます。
ユーザーがIDまたは権限依存のSQL関数または実行者権限のPL/SQLまたはJava関数を起動すると、現在のスキーマ、現在のユーザーおよび操作の実行内の現在有効なロールがビューの所有者に設定することなく問い合せたユーザーの環境から継承できます。
この構成は、ビュー自体から実行者権限のオブジェクトに変更しません。ビュー内での名前解決は、引き続きビューの所有者のスキーマを使用して処理され、ビューの権限チェックは、ビューの所有者の権限で実行されます。ただし、実行時に、ビューで参照される関数は、ビュー所有者ではなく実行するユーザーの権限で実行されます。
この機能の利点は、関数をビューで参照する場合に一貫した結果を戻すために実行するユーザーに正確な情報を戻す必要がある SYS_CONTEXT
や USERENV
などの関数を有効にすることです。
親トピック: ビューの定義者権限および実行者権限
6.6.2 CREATE VIEW文のBEQUEATH句の使用
BEQUEATH
は、実行ユーザーの権限を使用してどのように実行者権限関数を実行するかを制御します。
ビューを参照するSQLを発行するユーザーの権限を使用して実行者権限関数を実行するには、CREATE VIEW
文で、BEQUEATH
句をCURRENT_USER
に設定します。
ビューに対するSQL問合せまたはDML文を発行する場合、ビュー所有者は、実行するユーザーのINHERIT
PRIVILEGES
権限を付与するか、INHERIT ANY PRIVILEGES
権限を持つ必要があります。そうしないと、SELECT
問合せまたはDML文がBEQUEATH
CURRENT_USER
ビューを含む場合、実行時システムは、エラー「ORA-06598: INHERIT PRIVILEGES権限が不十分です」
を表示します。
-
BEQUEATH CURRENT_USER
句を使用して、実行者権限を使用して実行するビューの関数を設定します。
たとえば:
CREATE VIEW MY_OBJECTS_VIEW BEQUEATH CURRENT_USER AS SELECT GET_OBJS_FUNCTION;
ビューの所有者の権限を使用してビュー内の関数を実行する場合、BEQUEATH
句を省略するか、DEFINER
に設定します。
たとえば:
CREATE VIEW my_objects_view BEQUEATH DEFINER AS SELECT OBJECT_NAME FROM USER_OBJECTS;
関連項目:
-
INHERIT PRIVILEGE
権限の使用方法の詳細は、プロシージャ・コールおよびビュー・アクセスの実行者権限の制御を参照してください -
INHERIT
PRIVILEGES
およびINHERIT
ANY
PRIVILEGES
権限の付与の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 -
Oracle Database Real Application Securityアプリケーションでの
BEQUEATH CURRENT_USER
ビューの使用方法の詳細は、『Oracle Database Real Application Security管理者および開発者ガイド』を参照してください。
親トピック: ビューの定義者権限および実行者権限
6.6.3 実行するユーザーのユーザー名またはユーザーIDの確認
実行者権限または定義者権限を使用するかどうかに基づいて、PL/SQLファンクションを使用して、実行するユーザーを確認できます。
-
実行者権限または定義者権限のどちらを使用するかに基づいて、
ORA_INVOKING_USER
関数またはORA_INVOKING_USERID
関数を使用して、実行するユーザーを確認します。-
ORA_INVOKING_USER
: この関数を使用して、現在の文またはビューを実行しているユーザーの名前を戻します。この関数は、介在しているビューをBEQUEATH
句で指定されたとみなします。実行するユーザーがOracle Database Real Application Securityで定義されているユーザーの場合、この関数はXS$NULL
を戻します。 -
ORA_INVOKING_USERID
: この関数を使用して、現在の文またはビューを実行しているユーザーの識別子(ID)を戻します。この関数は、介在しているビューをBEQUEATH
句で指定されたとみなします。実行するユーザーがOracle Database Real Application Securityで定義されているユーザーである場合、この関数は、すべてのReal Application Securityセッションに共通でデータベース・ユーザーのIDとは異なるIDを戻します。たとえば:
CONNECT HR Enter password: password SELECT ORA_INVOKING_USER FROM DUAL; ORA_INVOKING_USER -------------------- HR
-
関連項目:
Oracle Database Real Application Securityアプリケーションに使用される類似の関数の詳細は、『Oracle Database Real Application Security管理者および開発者ガイド』を参照してください。
親トピック: ビューの定義者権限および実行者権限
6.6.4 BEQUEATH DEFINERおよびBEQUEATH_CURRENT_USERビューの確認
ビューがBEQUEATH DEFINER
またはBEQUEATH CURRENT_USER
ビューであるかどうかを確認できます。
-
ビューが
BEQUEATH DEFINER
またはBEQUEATH CURRENT_USER
ビューであるかどうかを確認するには、そのビューの*_VIEWS
または*_VIEWS_AE
静的データ・ディクショナリ・ビューのBEQUEATH
列を問い合せます。
関連項目:
-
静的データ・ディクショナリ・ビュー
*_VIEWS
の詳細は、『Oracle Databaseリファレンス』を参照してください。 -
静的データ・ディクショナリ・ビュー
*_VIEWS_AE
の詳細は、『Oracle Databaseリファレンス』を参照してください。
たとえば:
SELECT BEQUEATH FROM USER_VIEWS WHERE VIEW_NAME = 'MY_OBJECTS'; BEQUEATH ------------ CURRENT_USER
親トピック: ビューの定義者権限および実行者権限
6.7 定義者権限および実行者権限のコード・ベース・アクセス制御の使用
データベース・ロールをPL/SQLファンクション、プロシージャまたはパッケージに付与するときに使用するコード・ベース・アクセス制御は、定義者権限および実行者権限のプロシージャと一緒に使用すると効果的です。
- アプリケーションのコード・ベース・アクセス制御の使用について
コード・ベース・アクセス制御(CBAC)を使用すると、定義者権限のプログラム・ユニットの管理を向上できます。 - コード・ベースのアクセス制御ロールをプログラム・ユニットに付与できる者
次のすべての条件を満たした場合、コード・ベースのアクセス制御ロールをプログラム・ユニットに付与できます。 - コード・ベース・アクセス制御による実行者権限のプログラム・ユニットの処理方法
コード・ベース・アクセス制御では、実行ユーザーのコンテキストで、そのコンテキストに関連付けられたロールを使用してプログラム・ユニットを実行できます。 - コード・ベース・アクセス制御による定義者権限のプログラム・ユニットの処理方法
コード・ベース・アクセス制御を使用して定義者権限を保護できます。 - CBAC付与のためのユーザーへのデータベース・ロールの付与
GRANT
文のDELEGATE
オプションで、CBAC付与を行うユーザーによるロールへの権限付与を制限できます。 - プログラム・ユニットに対するデータベース・ロールの付与と取消し
GRANT
およびREVOKE
文で、プログラム・ユニットに対するデータベース・ロールの付与または取消しを行うことができます。 - チュートリアル: コード・ベース・アクセス制御による機密データへのアクセス制御
このチュートリアルでは、コード・ベース・アクセス制御を使用して、HR
スキーマの機密データへのアクセスを制御する方法を示します。
親トピック: 定義者権限および実行者権限のセキュリティの管理
6.7.1 アプリケーションのコード・ベース・アクセス制御の使用について
コード・ベース・アクセス制御(CBAC)を使用すると、実行者権限のプログラム・ユニットの管理を向上できます。
アプリケーションは、昇格した権限を必要とする一方で、コール側の環境でプログラム・ユニットを頻繁に実行する必要があります。従来PL/SQLプログラムは、定義者権限を使用してプログラムの権限を一時的に昇格します。
ただし、定義者権限ベースのプログラム・ユニットは、実行者のコンテキストではなくプログラム・ユニットの定義者または所有者のコンテキストで実行されます。また、定義者権限ベースのプログラムを使用すると、多くの場合にプログラム・ユニットが必要以上の権限を取得します。
コード・ベース・アクセス制御(CBAC)は、PL/SQLファンクション、プロシージャまたはパッケージへのデータベース・ロールのアタッチを可能にして、解決策を提供します。これらのデータベース・ロールは実行時に有効で、呼び出すユーザーの環境の必要な権限でプログラム・ユニットを実行できます。
関連項目:
CBACロールの権限の使用を取得する権限分析ポリシーを作成する方法の詳細は、Oracle Database Vault管理者ガイドを参照してください
6.7.2 コード・ベースのアクセス制御ロールをプログラム・ユニットに付与できる者
次のすべての条件を満たした場合、コード・ベースのアクセス制御ロールをプログラム・ユニットに付与できます。
これらの条件は次のとおりです。
-
権限付与者は、ユーザー
SYS
、またはプログラム・ユニットの所有者です。 -
権限付与者がプログラム・ユニットを所有する場合、権限付与者は
GRANT ANY ROLE
システム権限を持つか、プログラム・ユニットに付与するロールに対してADMIN
またはDELEGATE
オプションを持つ必要があります。 -
付与対象のロールは、所有者に対して直接付与されるロールです。
-
付与対象のロールは、標準データベース・ロールです。
これらの3つの条件が満たされない場合、1番目の条件が満たされないときは、エラーORA-28702: プログラム・ユニットの文字列が権限付与者によって所有されていません
が生成され、2番目と3番目の条件が満たされないときは、エラーORA-1924: ロールの文字列は付与されていないか、存在していません
が生成されます。
6.7.3 コード・ベース・アクセス制御による実行者権限のプログラム・ユニットの処理方法
コード・ベース・アクセス制御では、実行ユーザーのコンテキストで、そのコンテキストに関連付けられたロールを使用してプログラム・ユニットを実行できます。
2つのアプリケーション・ユーザー1および2が存在するシナリオを検討します。アプリケーション・ユーザー
2
は、実行者権限のプログラム・ユニットを作成し、データベース・ロール2
を実行者権限ユニットに付与して、実行者権限ユニットの実行権限をアプリケーション・ユーザー1
に付与します。
図6-1に、アプリケーション・ユーザー1
および2
に付与されるデータベース・ロール1
および2
と実行者権限のプログラム・ユニットを示します。
付与は次のとおりです。
-
アプリケーション・ユーザー
1
に直接データベース・ロール1
および4
が付与されます。 -
アプリケーション・ユーザー
2
に直接アプリケーション・ロール3
および4
を含むデータベース・ロール2
が付与されます。 -
実行者権限のプログラム・ユニットにデータベース・ロール
2
が付与されます。
アプリケーション・ユーザー1
がログインして実行者権限のプログラム・ユニットを実行する場合、実行者権限ユニットは、ユーザー1
の結合されたデータベース・ロールおよび実行者権限ユニットに付加されたデータベース・ロールで実行されます。
図6-2は、実行者権限ユニットが実行されるセキュリティ・コンテキストを示しています。アプリケーション・ユーザー1
が最初にログオンする場合、アプリケーション・ユーザー1
は、データベースPUBLIC
ロール(デフォルト)およびそれに付与されたデータベース・ロール1
および4
を持ちます。次に、アプリケーション・ユーザー1
は、アプリケーション・ユーザー2
によって作成された実行者権限のプログラム・ユニットを実行します。
実行者権限のユニットは、アプリケーション・ユーザー1
のコンテキストで実行され、それに付加される追加のデータベース・ロール2
を持ちます。データベース・ロール2
の一部であるため、データベース・ロール3
および4
が含まれます。実行者権限ユニットを終了した後、アプリケーション・ユーザー1
のみ、それに付与されたアプリケーション・ロール、PUBLIC
、ロール1
およびロール4
を持ちます。
6.7.4 コード・ベース・アクセス制御による定義者権限のプログラム・ユニットの処理方法
コード・ベース・アクセス制御を使用して定義者権限を保護できます。
コード・ベース・アクセス制御は、定義するユーザーの権限で動作するプログラム・ユニットを有効にすることで定義者権限のプログラム・ユニットと連携し、このユーザーに関連付けられるデータベース・ロールを組み合せた権限で機能します。
アプリケーション・ユーザー2
が定義者権限のプログラム・ユニットを作成し、定義者権限のプログラム・ユニットにロール2
を付与して、定義者権限のプログラム・ユニットのEXECUTE
権限をアプリケーション・ユーザー1
に付与するシナリオを検討します。
図6-3に、アプリケーション・ユーザー1
および2
に付与されるデータベース・ロールと定義者権限のプログラム・ユニットを示します。
付与は次のとおりです。
-
アプリケーション・ユーザー
1
に直接データベース・ロール1
および4
が付与されます。 -
アプリケーション・ユーザー
2
に直接データベース・ロール3
および4
を含むデータベース・ロール2
が付与されます。 -
定義者権限のプログラム・ユニットにデータベース・ロール
2
が付与されます。
アプリケーション・ユーザー1
がログインして定義者権限のプログラム・ユニットを実行する場合、定義者権限ユニットは、アプリケーション・ユーザー2
の結合されたデータベース・ロールおよび定義者権限ユニットに付加されたデータベース・ロール(ロール2
、3
および4
)で実行されます。
図6-4は、定義者権限のプログラム・ユニットが実行されるセキュリティ・コンテキストを示しています。アプリケーション・ユーザー1
が最初にログオンする場合、アプリケーション・ユーザー1
は、データベースPUBLIC
ロール(デフォルト)およびそれに付与されたデータベース・ロール1
および4
を持ちます。次に、アプリケーション・ユーザー1
は、アプリケーション・ユーザー2
によって作成された定義者権限のプログラム・ユニットを実行します。
定義者権限のプログラム・ユニットは、アプリケーション・ユーザー2
のコンテキストで実行され、それに付加される追加のデータベース・ロール2
を持ちます。データベース・ロール2
の一部であるため、データベース・ロール3
および4
が含まれます。定義者権限ユニットを終了した後、アプリケーション・ユーザー1
のみ、それに付与されたデータベース・ロール(PUBLIC
、ロール1
およびロール4
)を持ちます。
6.7.5 CBAC付与のためのユーザーへのデータベース・ロールの付与
GRANT
文のDELEGATE
オプションで、CBAC付与を行うユーザーによるロールへの権限付与を制限できます。
データベース・ロールをCBAC付与を行うユーザーに付与する場合、GRANT
文にDELEGATE
オプションを含めて、権限受領者にロールに対する追加権限が付与されないようにすることができます。
DELEGATE
オプションを使用すると、ロールはプログラム・ユニットに付与されますが、他のプリンシパルまたはロール自体の管理にロールを付与することはできません。他のプリンシパルへのロールの付与を可能にするADMIN
オプションを付与に使用することもできます。ADMIN
とDELEGATE
オプションは共存できます。オプションごとに別のGRANT
文で付与する必要はありますが、両方をユーザーに付与することができます。これらのオプション付きでユーザーにロールが付与されているかどうかを確認するには、ユーザーのUSER_ROLE_PRIVS
またはDBA_ROLE_PRIVS
のDELEGATE_OPTION
列またはADMIN_OPTION
列を問い合せます。
DELEGATE
およびADMIN
オプションを使用するための構文は次のとおりです。
GRANT role_list to user_list WITH DELEGATE OPTION; GRANT role_list to user_list WITH ADMIN OPTION;
たとえば:
GRANT cb_role1 to usr1 WITH DELEGATE OPTION; GRANT cb_role1 to usr1 WITH ADMIN OPTION; GRANT cb_role1, cb_role2 to usr1, usr2 with DELEGATE OPTION; GRANT cb_role1, cb_role2 to usr1, usr2 with ADMIN OPTION;
マルチテナント環境では、ADMIN
オプションの場合と同様に共通ロールの共通ユーザーへの付与などの共通付与にDELEGATE
オプションを使用できます。
たとえば:
GRANT c##cb_role1 to c##usr1 WITH DELEGATE OPTION CONTAINER = ALL;
CBAC付与自体は、PDBでローカルにのみ行えることに注意してください。
関連項目:
ADMIN
オプションの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
6.7.6 プログラム・ユニットに対するデータベース・ロールの付与と取消し
GRANT
およびREVOKE
文で、プログラム・ユニットに対するデータベース・ロールの付与または取消しを行うことができます。
次の構文を使用して、PL/SQLファンクション、プロシージャまたはパッケージのデータベース・ロールを付与または取り消します。
GRANT role_list TO code_list REVOKE {role_list | ALL} FROM code_list
詳細は、次のとおりです。
role_list ::= code-based_role_name[, role_list] code_list ::= { {FUNCTION [schema.]function_name} | {PROCEDURE [schema.]procedure_name} | {PACKAGE [schema.]package_name} }[, code_list]
たとえば:
GRANT cb_role1 TO FUNCTION func1, PACKAGE pack1; GRANT cb_role2, cb_role3 TO FUNCTION HR.func2, PACKAGE SYS.pack2; REVOKE cb_role1 FROM FUNCTION func1, PACKAGE pack1; REVOKE ALL FROM FUNCTION HR.func2, PACKAGE SYS.pack2;
6.7.7 チュートリアル: コード・ベース・アクセス制御による機密データへのアクセス制御
このチュートリアルでは、コード・ベース・アクセス制御を使用して、HR
スキーマの機密データへのアクセスを制御する方法を示します。
- このチュートリアルについて
このチュートリアルでは、自分の部門のために特定の従業員情報に対するアクセス権が必要なユーザーを作成します。 - ステップ1: ユーザーを作成してHRにCREATE ROLE権限を付与
開始するには、"Finance"
ユーザー・アカウントを作成し、このHR
ユーザーにCREATE ROLE
権限を付与する必要があります。 - ステップ2: print_employees実行者権限プロシージャを作成
print_employees
実行者権限プロシージャは、現在のユーザーの部門内の従業員情報を表示します。 - ステップ3: hr_clerkロールを作成して権限を付与
次に、hr_clerk
ロールを作成し、print_employees
プロシージャに対するEXECUTE
権限を付与する必要があります。 - ステップ4: コード・ベース・アクセス制御HR.print_employeesプロシージャのテスト
コード・ベース・アクセス制御HR.print_employees
プロシージャをテストする準備が整いました。 - ステップ5: view_emp_roleロールを作成して権限を付与
ここでは、ユーザーHR
でview_emp_role
ロールを作成し、このロールに権限を付与する必要があります。 - ステップ6: HR.print_employeesプロシージャの再テスト
適切な権限がある場合、ユーザー"Finance"
は、HR.print_employees
プロシージャを再試行できます。 - ステップ7: このチュートリアルのコンポーネントの削除
このチュートリアルのコンポーネントが不要になった場合、それらを削除できます。
6.7.7.1 このチュートリアルについて
このチュートリアルでは、自分の部門のために特定の従業員情報に対するアクセス権が必要なユーザーを作成します。
ただし、HR.EMPLOYEES
表には従業員給与などの機密情報が含まれており、ユーザーにはアクセスできないようにする必要があります。アクセス制御は、コード・ベース・アクセス制御を使用して実装します。従業員データは、実行者権限プロシージャを通じてユーザーに表示されます。SELECT
権限をユーザーに直接付与するかわりに、データベース・ロールを通じてSELECT
権限を実行者権限プロシージャに付与します。このプロシージャでは、給与のような機密情報を非表示にします。このプロシージャは実行者権限プロシージャであるため、プロシージャ内で呼出し元のコンテキストがわかります。この場合、呼出し元のコンテキストは財務部門です。ユーザーの名前は"Finance"
であるため、ユーザーは財務部門に勤務する従業員のデータのみにアクセス可能です。
6.7.7.2 ステップ1: ユーザーを作成してHRにCREATE ROLE権限を付与
開始するには、"Finance"
ユーザー・アカウントを作成し、このHR
ユーザーにCREATE ROLE
権限を付与する必要があります。
6.7.7.3 ステップ2: print_employees実行者権限プロシージャを作成
print_employees
実行者権限プロシージャは、現在のユーザーの部門内の従業員情報を表示します。
6.7.7.4 ステップ3: hr_clerkロールを作成して権限を付与
次に、hr_clerk
ロールを作成し、print_employees
プロシージャに対するEXECUTE
権限を付与する必要があります。
"Finance"
に付与する必要があります。
6.7.7.5 ステップ4: コード・ベース・アクセス制御HR.print_employeesプロシージャのテスト
コード・ベース・アクセス制御HR.print_employees
プロシージャをテストする準備が整いました。
HR.print_employees
プロシージャをテストするには、ユーザー"Finance"
がHR.EMPLOYEES
表を問い合せて、HR.print_employees
プロシージャの実行を試みる必要があります。
6.7.7.6 ステップ5: view_emp_roleロールを作成して権限を付与
ここでは、ユーザーHR
でview_emp_role
ロールを作成し、このロールに権限を付与する必要があります。
HR
がSELECT
権限HR.EMPLOYEES
とHR.DEPARTMENTS
をview_emp_role
ロールに付与し、HR.EMPLOYEES
とHR.DEPARTMENTS
のSELECT
をview_emp_role
ロールに付与します。
6.7.7.7 ステップ6: HR.print_employeesプロシージャの再テスト
適切な権限がある場合、ユーザー"Finance"
は、HR.print_employees
プロシージャを再試行できます。
6.8 データベース・リンクの定義者権限の制御
アプリケーションでデータベース・リンクと定義者権限プロシージャが使用されている場合は、定義者権限プロシージャの権限付与を制御できます。
- データベース・リンクの定義者権限の制御について
定義者権限プロシージャがデータベース・リンクに接続する場合、データベース・リンク上の操作でプロシージャ所有者の資格証明を使用する必要があります。 - 他のユーザーへのINHERIT REMOTE PRIVILEGES権限の付与
INHERIT REMOTE PRIVILEGES
権限は、現行ユーザーがデータベースの接続ユーザーを介して明示的な権限を持つことを可能にします。 - 例: 接続ユーザーのINHERIT REMOTE PRIVILEGESの付与
接続ユーザーのINHERIT REMOTE PRIVILEGES
権限を現行ユーザーに付与できます。 - 他のユーザーへのINHERIT ANY REMOTE PRIVILEGES権限の付与
INHERIT ANY REMOTE PRIVILEGES
権限により、権限受領ユーザーはconnected_user
データベース・リンクを任意のユーザーとしてオープンできます。 - INHERIT [ANY] REMOTE PRIVILEGES権限の取消し
INHERIT REMOTE PRIVILEGES
権限とINHERIT ANY REMOTE PRIVILEGES
権限とでは取消方法が異なります。 - 例: INHERIT REMOTE PRIVILEGES権限の取消し
REVOKE
SQL文で、INHERIT REMOTE PRIVILEGES
権限を取り消すことができます。 - 例: PUBLICからのINHERIT REMOTE PRIVILEGES権限の取消し
REVOKE
SQL文で、PUBLIC
および個々のプロシージャ所有者のINHERIT REMOTE PRIVILEGES
を取り消すことができます。 - チュートリアル: 定義者権限プロシージャでのデータベース・リンクの使用
このチュートリアルでは、データベース・リンクを使用する定義者権限プロシージャでのINHERIT REMOTE PRIVILEGES
権限の使用方法を示します。
親トピック: 定義者権限および実行者権限のセキュリティの管理
6.8.1 データベース・リンクの定義者権限の制御について
定義者権限プロシージャがデータベース・リンクに接続する場合、データベース・リンク上の操作でプロシージャ所有者の資格証明を使用する必要があります。
INHERIT REMOTE PRIVILEGES
およびINHERIT ANY REMOTE PRIVILEGES
権限は、接続ユーザー・データベース・リンクが定義者権限プロシージャで使用される場合に適用されます。これらの権限により、定義者権限プロシージャでの接続ユーザー・データベース・リンクの操作で、ログインしているユーザーの資格証明の使用が可能になります。
定義者権限プロシージャを実行するユーザーが定義者権限ブロック内で接続ユーザー・データベース・リンクを使用できるように、INHERIT REMOTE PRIVILEGES
およびINHERIT ANY REMOTE PRIVILEGES
権限を付与できます。定義者権限プロシージャは、プロシージャ所有者の権限で実行されます。ただし、接続ユーザー・データベース・リンクの操作には、ログインしているユーザーの資格証明が必要です。したがって、定義者権限内でデータベース・リンクの操作を可能にするには、INHERIT REMOTE PRIVILEGES
およびINHERIT ANY REMOTE PRIVILEGES
権限を付与する必要があります。
アップグレード中にINHERIT REMOTE PRIVILEGES
およびINHERIT ANY REMOTE PRIVILEGES
権限はデフォルトで既存のユーザーに付与されないことに注意してください。
INHERIT REMOTE PRIVILEGES
およびINHERIT ANY REMOTE PRIVILEGES
権限は、ユーザーが定義者権限プロシージャでユーザー・データベース・リンクに接続を試みる状況にのみ適用されます。また、これらの権限は、プライベート、パブリックを問わず、作成されたデータベース・リンクに適用されます。デフォルトでは、データベース・リンクはプライベート・リンクとして作成されます。さらに、デフォルトではINHERIT REMOTE PRIVILEGES
はPUBLIC
に付与されません。
これらの権限を付与する方法は次のとおりです。
-
GRANT INHERIT REMOTE PRIVILEGES ON USER dbuser_1 TO dbuser_2
: このシナリオでは、dbuser_1
が明示的にINHERIT REMOTE PRIVILEGE
権限をdbuser_2
に付与し、ユーザーdbuser_2
が所有する定義者権限プロシージャを使用します。 -
GRANT INHERIT REMOTE PRIVILEGES ON USER dbuser_1 TO PUBLIC
。このシナリオでは、dbuser_1
がINHERIT REMOTE PRIVILEGE
権限をpublicに付与します。この付与により、dbuser_1
は他のユーザーが所有する定義者権限プロシージャを使用できます。 -
GRANT INHERIT ANY REMOTE PRIVILEGES TO dbuser_2
: このシナリオでは、いずれのユーザーもdbuser_2
が所有する定義者権限プロシージャを使用できます。
INHERIT REMOTE PRIVILEGE
権限のないユーザーが定義者権限を実行しようとすると、ORA-25433: ユーザーにはINHERIT REMOTE PRIVILEGESがありません
エラーが表示されます。
親トピック: データベース・リンクの定義者権限の制御
6.8.2 他のユーザーへのINHERIT REMOTE PRIVILEGES権限の付与
INHERIT REMOTE PRIVILEGES
権限は、現行ユーザーがデータベースの接続ユーザーを介して明示的な権限を持つことを可能にします。
INHERIT REMOTE PRIVILEGES
権限を付与する構文は次のとおりです。
GRANT INHERIT REMOTE PRIVILEGES ON USER connected_user TO current_user:
詳細は、次のとおりです。
-
connected_user
は、定義者権限プロシージャを実行するユーザーです。 -
current_user
は、定義者権限プロシージャを所有するユーザーです。この値は、データベース・ユーザー・アカウントである必要があります。INHERIT REMOTE PRIVILEGES
権限をプロシージャの所有者に付与するかわりに、プロシージャに付与されるロールに権限を付与できます。
定義者権限プロシージャを所有するユーザーまたはロールは、定義者権限プロシージャを実行するユーザーによって付与されるINHERIT REMOTE PRIVILEGES
権限を持つ必要があります。
いずれのユーザーも、自分が実行する定義者権限プロシージャを所有するユーザーに対して、自分の持つINHERIT REMOTE PRIVILEGES
権限の付与または取消しを行うことができます。
親トピック: データベース・リンクの定義者権限の制御
6.8.3 例: 接続ユーザーのINHERIT REMOTE PRIVILEGESの付与
接続ユーザーのINHERIT REMOTE PRIVILEGES
権限を現行ユーザーに付与することができます。
この例では、接続ユーザーjward
は、現行ユーザーebrown
のリモート権限を持つ必要があります。これにより、jward
は、ebrown
が作成した定義者権限プロシージャを実行できます。
例6-4に、管理者(またはユーザーjward
)がユーザーjward
のINHERIT REMOTE PRIVILEGES
をユーザーebrown
に付与する方法を示します。この権限付与により、ebrown
が記述する(または今後記述する予定の)定義者権限プロシージャが、そのプロシージャの実行時にebrown
の権限にアクセスできるようになります。
例6-4 現行ユーザーへの接続ユーザーのINHERIT REMOTE PRIVILEGESの付与
GRANT INHERIT REMOTE PRIVILEGES on user jward to ebrown;
親トピック: データベース・リンクの定義者権限の制御
6.8.4 他のユーザーへのINHERIT ANY REMOTE PRIVILEGES権限の付与
INHERIT ANY REMOTE PRIVILEGES
権限により、権限受領ユーザーはconnected_user
データベース・リンクを任意のユーザーとしてオープンできます。
すべてのANY
権限と同様に、INHERIT ANY REMOTE PRIVILEGES
は、信頼できるユーザーのみに付与する必要がある強力な権限です。デフォルトでは、ユーザーSYS
がINHERIT ANY REMOTE PRIVILEGES
システム権限WITH GRANT OPTION
を持っています。INHERIT ANY REMOTE PRIVILEGES
権限を付与されたユーザーを確認するには、DBA_SYS_PRIVS
データ・ディクショナリ・ビューを問い合せます。
マルチテナント環境でのセキュリティ向上のため、PDBロックダウン・プロファイルでINHERIT ANY REMOTE PRIVILEGES
権限を保護することをお薦めします。PDBロックダウン・プロファイルは、ローカル・プラガブル・データベース(PDB)ユーザーが持っているINHERIT REMOTE PRIVILEGE
の種類に関係なく、PDBユーザーが接続ユーザー・データベース・リンクを共通ユーザーとしてオープンすることを防ぎます。PDBがPDBロックダウン・プロファイルによって保護されている場合、GRANT INHERIT REMOTE PRIVILEGES
およびGRANT INHERIT ANY REMOTE
権限などの付与は成功しますが、これらの付与の影響は、PDBロックダウンが継続しているかぎり適用されません。
INHERIT ANY REMOTE PRIVILEGES
権限を付与する構文は次のとおりです。
GRANT INHERIT ANY REMOTE PRIVILEGES TO current_user;
ここで、current_user
は、定義者権限プロシージャを所有するユーザーです。
親トピック: データベース・リンクの定義者権限の制御
6.8.5 INHERIT [ANY] REMOTE PRIVILEGES権限の取消し
INHERIT REMOTE PRIVILEGES
権限とINHERIT ANY REMOTE PRIVILEGES
権限とでは取消方法が異なります。
INHERIT REMOTE PRIVILEGES
権限は、ユーザーが別のユーザーから取り消すことができます。INHERIT ANY REMOTE PRIVILEGES
権限は管理権限を持つユーザーが取り消す必要があります。
取消しの構文は次のとおりです
REVOKE INHERIT REMOTE PRIVILEGES ON USER connected_user FROM current_user;
詳細は、次のとおりです。
-
connected_user
は、定義者権限プロシージャを実行するユーザーです。 -
current_user
は、定義者権限プロシージャを所有するユーザーです。
INHERIT REMOTE PRIVILEGES
またはINHERIT ANY REMOTE PRIVILEGES
権限をユーザーから取り消す場合、次のように標準の取消し構文を使用します。
REVOKE INHERIT REMOTE PRIVILEGES FROM connected_user; REVOKE INHERIT ANY REMOTE PRIVILEGES FROM current_user;
親トピック: データベース・リンクの定義者権限の制御
6.8.6 例: INHERIT REMOTE PRIVILEGES権限の取消し
REVOKE
SQL文で、INHERIT REMOTE PRIVILEGES
権限を取り消すことができます。
INHERIT REMOTE PRIVILEGES
権限を取り消すと、ユーザーjward
がjward
所有の定義者権限プロシージャを実行する場合、jward
がebrown
に対して、jward
の資格証明を使用して接続ユーザー・データベース・リンクをオープンする権限を明示的に拒否しているため、定義者権限プロシージャ内での接続ユーザー・データベース・リンクの操作はすべて失敗します。
例6-5に、接続ユーザーjward
のINHERIT REMOTE PRIVILEGES
プロシージャをプロシージャ所有者ebrown
から取り消す方法を示します。
例6-5 INHERIT REMOTE PRIVILEGES権限の取消し
REVOKE INHERIT REMOTE PRIVILEGES ON USER jward FROM ebrown;
親トピック: データベース・リンクの定義者権限の制御
6.8.7 例: PUBLICからのINHERIT REMOTE PRIVILEGES権限の取消し
REVOKE
SQL文で、PUBLIC
および個々のプロシージャ所有者のINHERIT REMOTE PRIVILEGES
を取り消すことができます。
例6-6に、PUBLIC
から権限を取り消す方法を示します。
例6-6 PUBLICからのINHERIT REMOTE PRIVILEGES権限の取消し
REVOKE INHERIT REMOTE PRIVILEGES FROM PUBLIC;
親トピック: データベース・リンクの定義者権限の制御
6.8.8 チュートリアル: 定義者権限プロシージャでのデータベース・リンクの使用
このチュートリアルでは、データベース・リンクを使用する定義者権限プロシージャでのINHERIT REMOTE PRIVILEGES
権限の使用方法を示します。
- このチュートリアルについて
このチュートリアルでは、INHERIT REMOTE PRIVILEGES
権限の付与と取消しをテストします。 - ステップ1: ユーザー・アカウントの作成
データベース・リンクを含む定義者権限プロシージャを作成するユーザーと、そのプロシージャを実行するユーザーを作成します。 - ステップ2: ユーザーIDを格納する表の作成(ユーザーdbuser2として)
この表のユーザーIDは、データベース・リンクで使用するIDです。 - ステップ3: データベース・リンクおよび定義者権限プロシージャの作成(ユーザーdbuser1として)
ユーザーdbuser1
は、データベース・リンクに加えて、そのデータベース・リンクを参照する定義者権限プロシージャを作成できます。 - ステップ4: 定義者権限プロシージャのテスト
定義者権限プロシージャをテストする前に、ユーザーdbuser2
がdbuser1
にINHERIT REMOTE PRIVILEGES
を付与する必要があります。 - ステップ5: このチュートリアルのコンポーネントの削除
このチュートリアルのコンポーネントが不要になった場合、それらを削除できます。
親トピック: データベース・リンクの定義者権限の制御
6.8.8.1 このチュートリアルについて
このチュートリアルでは、INHERIT REMOTE PRIVILEGES
権限の付与と取消しをテストします。
これを行うには、2人のユーザーを作成する必要があります。1人はデータベース・リンクを参照する定義者権限プロシージャを作成するユーザー、もう1人はこの定義者権限プロシージャを実行するユーザーです。いずれのユーザーも自分のスキーマで同一のルックアップ表を作成します。定義者権限プロシージャでは、定義者権限ユーザーに属するルックアップ表を2人目のユーザーが問い合せることを可能にする必要があります。
6.8.8.4 ステップ3: データベース・リンクおよび定義者権限プロシージャの作成(ユーザーdbuser1として)
ユーザーdbuser1
は、データベース・リンクに加えて、そのデータベース・リンクを参照する定義者権限プロシージャを作成できます。
6.8.8.5 ステップ4: 定義者権限プロシージャのテスト
定義者権限プロシージャをテストする前に、ユーザーdbuser2
がdbuser1
にINHERIT REMOTE PRIVILEGES
を付与する必要があります。