ヘッダーをスキップ

Oracle Database セキュリティ・ガイド
10gリリース2(10.2)

B19269-04
目次
目次
索引
索引

戻る 次へ

5 認可: 権限、ロール、プロファイルおよびリソースの制限

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

この章では、この種の制限を個々のユーザーまたはユーザー・グループに対して適用または除外するための基本概念とメカニズムについて説明します。この章の内容は、次のとおりです。

トピックのカテゴリ  トピックへのリンク 

権限の取得と使用方法 

権限の概要
システム、スキーマ、オブジェクト、表、
プロシージャなどの権限について説明します。 

ロールの取得、使用および制限方法 

ロールの概要 

リソース制限をユーザーに適用する方法と理由 

ユーザー・リソースの制限 

プロファイルの決定と使用方法 

プロファイル 

関連項目:

DBAやアプリケーション・プログラマなどを含めたユーザーの権限、ロールおよびプロファイルの構成と管理方法については、第11章「ユーザー権限、ロールおよびプロファイルの管理」を参照してください。 

権限の概要

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

権限をユーザーに付与すると、そのユーザーはそれぞれの業務に必要な作業を実行できるようになります。 なお、権限は、必要な作業を実行する上でその権限が必要なユーザーにのみ付与してください。必要でない権限まで付与すると、セキュリティを維持できなくなる可能性があります。ユーザーは次の2つの方法で権限を受け取ることができます。

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

関連項目:

 

権限には、次の6つの主な分類があり、一部の権限はさらに細かく分類されます。

システム権限

システム権限とは、特定のアクションを実行する権限、または特定のタイプのスキーマ・オブジェクトに対してアクションを実行する権限のことです。たとえば、表領域を作成する権限や、データベース内の任意の表から行を削除する権限などがシステム権限です。 管理対象のシステム権限には100以上の種類があります。次の各項で詳細を説明します。

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

システム権限は、ユーザーとロールに対して付与したり取り消すことができます。システム権限をロールに付与すると、そのロールを使用してシステム権限を管理できます。たとえば、ロールを使用すると権限を選択的に使用できるようになります。


注意:

通常、システム権限を付与するのは、管理者とアプリケーション開発者に対してのみです。エンド・ユーザーは一般的に、システム権限に関連する機能を必要としません。  


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

システム権限を付与または取消しできるユーザー

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

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

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

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

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

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

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

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

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

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

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

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

たとえば、ユーザーSCOTTが表t2の所有者の場合:

SQL>GRANT GRANT ANY OBJECT PRIVILEGE TO u1; 
SQL> CONNECT u1/u1 
Connected. 
SQL> GRANT SELECT ON scott.t2 TO u2; 
SQL> SELECT GRANTEE, OWNER, GRANTOR, PRIVILEGE, GRANTABLE FROM DBA_TAB_PRIVS 
 WHERE TABLE_NAME = 'employees'; 

GRANTEE                        OWNER 
------------------------------ ------------------------------ 
GRANTOR                        PRIVILEGE                                GRA 
------------------------------ ---------------------------------------- --- 
U2                             SCOTT 
SCOTT                          SELECT                                   NO  

関連項目:

『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操作

表またはビューで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操作を許可します。次の各項では、これらの権限について説明します。

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

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

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

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

ビューの場合は、表に対してさらに2つのセキュリティ・レベル(列レベルと値ベースのセキュリティ)が追加されます。

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

スタンドアロン・プロシージャ、ファクションおよびパッケージを含め、プロシージャに対するスキーマ・オブジェクト権限は、EXECUTEのみです。この権限は、プロシージャの実行、または必要なプロシージャをコールする他のプロシージャのコンパイルが必要なユーザーにのみ付与してください。プロシージャに対する権限を作成し、その安全かつ効率的な使用を管理するには、次の項目を理解する必要があります。

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

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

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

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

関連項目:

「PL/SQLブロックとロール」 

定義者権限

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

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

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


注意:

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


関連項目:

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

実行者権限

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

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

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

複数のプログラム・ユニットで構成したソフトウェア・バンドルを作成し、一部のプログラム・ユニットには定義者権限を、残りのプログラム・ユニットには実行者権限を付与すると、プログラムのエントリ・ポイントを限定できます(コントロール・ステップイン)。エントリ・ポイント・プロシージャの実行権限があるユーザーは、内部プログラム・ユニットも間接的に実行できますが、内部プログラムを直接コールすることはできません。

関連項目:

 

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

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

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


注意:

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


パッケージとパッケージ・オブジェクト

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

パッケージとパッケージ・オブジェクト 例1

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

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; 

このプロシージャを実行するためのアクセス権限を付与するには、次の文を使用して、パッケージに対するEXECUTE権限を付与します。

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; 

型に対する権限

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

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

Oracleでは、名前付きの型(オブジェクト型、VARRAYおよびネストした表)について、表5-1のシステム権限が定義されています。

表 5-1    名前付きの型に対するシステム権限 
権限  許可される操作 

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プロシージャと同じです。

関連項目:

「プロシージャに対する権限」

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

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

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

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

CONNECTロールとRESOURCEロールを持つ次の3名のユーザーが存在するとします。

User1は、自分のスキーマで次のDDLを実行します。

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;

User2は、自分のスキーマで次のDDLを実行します。

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文に対する列レベルと表レベルの既存の権限は、列オブジェクトと行オブジェクトの両方に適用されます。 Oracleでは、オブジェクト表に対して、表5-2の権限が定義されています。

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

権限 

許可される操作 

SELECT 

オブジェクトとその属性に表からアクセスできます。 

UPDATE 

表の行を構成するオブジェクトの属性を変更できます。 

INSERT 

表に新規オブジェクトを作成できます。 

DELETE 

行を削除できます。 

同様に、列オブジェクトには表に対する権限と列に対する権限が適用されます。インスタンスの取得のみでは、型情報は明らかになりません。ただし、クライアントは、型インスタンスのイメージを解釈するために、名前付きの型の情報にアクセスする必要があります。 クライアントがこのような型情報を要求すると、Oracle Databaseはその型に対する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型がアクセスされると、OracleはユーザーのEXECUTE権限をチェックします。

ただし、2番目の問合せの実行では、名前付きの型が含まれていないため、Oracleは型の権限をチェックしません。

さらに、user3は、前の項のスキーマを使用して次の問合せを実行できます。

SELECT tab1.col1.attr2 FROM user2.tab1 tab1;
SELECT attr4.attr3.attr2 FROM tab3;

どちらのSELECT文でも、user3には基礎となる型に対する明示的な権限がありませんが、文には成功することに注意してください。これは、型の所有者と表の所有者に、GRANT OPTIONを備えた必要な権限があるためです。

Oracle Databaseは、次のイベントに対する権限をチェックし、アクションに対する権限がクライアントにない場合はエラーを戻します。

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

型の依存性

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

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

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

関連項目:

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

ロールの概要

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

ロールは、エンド・ユーザーのシステム権限とスキーマ・オブジェクト権限を容易に管理できるように設計されており、多くの場合はOracle Internet Directoryでメンテナンスされます。ただし、ストアド・プログラム構成メンバーの中からスキーマ・オブジェクトにアクセスする権限は、直接付与する必要があるため、ロールは、アプリケーション開発者が使用することを目的としていません。

次の各項では、ロールの効率的な管理について説明します。

ロールの認証に関する考慮事項  関連項目へのリンク 

ロールのメリット 

ロールの特性 

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

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

ユーザーによるロールの取得方法
(またはロールの制限方法) 

ロールの付与と取消し 

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

ロールとユーザーのセキュリティ・ドメイン 

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

PL/SQLブロックとロール 

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

DDL文とロール 

Oracleで事前定義されているロール 

事前定義のロール 

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

オペレーティング・システムとロール 

リモート・セッションでのロールの機能 

分散環境におけるロール 

保護アプリケーション・ロールの作成と使用方法 

保護アプリケーション・ロール 

ロールの特性

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

表 5-3    ロールの特性 
特性  説明 

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

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

動的な権限管理 

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

権限の選択的な可用性 

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

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

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

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

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

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

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

関連項目:

  • プロシージャに関する制限の詳細は、「DDL文とロール」を参照してください。

  • アプリケーションからロールを使用可能にする手順は、『Oracle Databaseアプリケーション開発者ガイド-基礎編』を参照してください。

 

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

通常は、次のどちらかの目的でロールを作成します。

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

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


画像の説明

アプリケーション・ロール

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


注意:

パスワード保護または別のロールへのアプリケーション・ロールの付与は、Oracle Databaseの将来のリリースでは使用禁止になる予定です。 


ユーザー・ロール

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

ロールの付与と取消し

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

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

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

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

ロールに対して権限を付与または取り消す場合にも同じオプションを使用します。 また、Oracleを実行しているオペレーティング・システムを使用したり、ネットワーク・サービスを介して、ロールをユーザーに対して付与したり取り消すことができます。

関連項目:

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

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

  • Database Controlを使用してユーザー、ロールまたは権限を変更する方法については、Enterprise Managerのオンライン・ヘルプを参照してください。

 

ロールを付与または取消しできるユーザー

GRANT ANY ROLEシステム権限があるユーザーは、グローバル・ロールを除き、他のユーザーの任意のロールまたはデータベースのロールを付与または取り消すことができます。このシステム権限は非常に強力であるため、付与する際は注意が必要です。

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

関連項目:

グローバル・ロールについては、『Oracle Database管理者ガイド』を参照してください。 

ロールとユーザーのセキュリティ・ドメイン

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

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

PL/SQLブロックとロール

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

定義者権限を持つ名前付きブロック

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

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

関連項目:

『Oracle Databaseリファレンス』 

実行者権限を持つ無名ブロック

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

関連項目:

  • 実行者権限と定義者権限の詳細は、『PL/SQLユーザーズ・ガイドおよびリファレンス』を参照してください。

  • 『Oracle Database概要』のPL/SQLの動的SQLに関する項を参照してください。

 

DDL文とロール

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

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

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

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

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

事前定義のロール

次のロールは、Oracle Databaseに対して自動的に定義されます。

これらのロールは、旧バージョンのOracle Databaseとの下位互換のために提供されており、Oracleデータベース内の他のロールと同じ方法で変更できます。


注意:

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


オペレーティング・システムとロール

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

関連項目:

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

分散環境におけるロール

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

関連項目:

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

保護アプリケーション・ロール

Oracle Databaseでは、保護アプリケーション・ロールが用意されています。このロールは、認可されたPL/SQLパッケージでのみ有効にできます。このメカニズムは、アプリケーションを起動するロールの有効化を制限します。

パスワードが、アプリケーションのソース・コードに埋め込まれていない場合、または表に格納されていない場合、セキュリティは強化されます。そのかわりに、ロールの有効化を認可するPL/SQLパッケージを指定して、保護アプリケーション・ロールを作成できます。パッケージの識別は、ロールを有効化するのに十分な権限があるかどうかの決定に使用します。ロールの有効化の前に、アプリケーションはユーザーがプロキシを介して接続しているかどうかをチェックするなど、認証およびカスタマイズ認可を実行できます。


注意:

ユーザーが定義者権限プロシージャ内のセキュリティ・ドメインを変更できないという制限により、保護アプリケーション・ロールは実行者権限プロシージャ内でのみ有効化できます。 


保護アプリケーション・ロールの作成

保護アプリケーション・ロールは、CREATE ROLE ... IDENTIFIED USING文を使用して作成します。次に例を示します。

CREATE ROLE admin_role IDENTIFIED USING hr.admin;

この例から次のようなことがわかります。

この文を実行するには、CREATE ROLEシステム権限が必要です。

このロールは、ユーザーに割り当てられるとそのユーザーのデフォルト・ロールになり、パッケージを使用せずにログイン時に自動的に有効になります。 デフォルト・ロールを持つユーザーは、そのロールを使用するために認証を受ける必要はありません。 たとえば、ロールに対するパスワードは不要で、要求もされません。

IDENTIFIED USING句で指定した使用方法のみにロールを制限するには、次のいずれかのアクションを実行します。

実行者権限プロシージャ内で有効化されたロールは、プロシージャの終了後も有効です。そのため、ロールの有効化を処理する専用プロシージャは、セッションの終了まで使用できます。

関連項目:

  • 『Oracle Database SQLリファレンス』

  • 『PL/SQLユーザーズ・ガイドおよびリファレンス』

  • 『PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』

  • 『Oracle Databaseアプリケーション開発者ガイド-基礎編』

 

ユーザー・リソースの制限

ユーザーのセキュリティ・ドメインの一部として、各ユーザーが使用できる各種のシステム・リソースの容量に制限を設定できます。これにより、CPUタイムなどの貴重なシステム・リソースが無制限に浪費されるのを防止できます。

このリソース制限機能は、システム・リソースに多額の費用がかかる大規模なマルチ・ユーザー・システムでは非常に有効です。1人以上のユーザーが過度にリソースを使用すると、データベースの他のユーザーに有害な影響を与える可能性があります。 シングル・ユーザー・データベースや小規模なマルチ・ユーザー・データベースの場合は、ユーザーがシステム・リソースを消費しても影響は少ないため、システム・リソース機能はそれほど重要ではありません。

ユーザーのリソース制限は、データベース・リソース・マネージャを使用して管理します。パスワード管理の作業環境は、ユーザーごとに個別にプロファイルを使用して設定するか、または多数のユーザー用のデフォルト・プロファイルを使用して設定できます。それぞれのOracleデータベースに指定できるプロファイルの数に、制限はありません。Oracleにおいて、セキュリティ管理者は、プロファイルによるリソース制限の規定を全体的に使用可能または使用禁止に設定できます。

関連項目:

  • リソース管理については、『Oracle Database管理者ガイド』のデータベース・リソース・マネージャに関する項を参照してください。

  • パスワードについては、「パスワード管理ポリシー」を参照してください。

 

リソース制限を設定すると、ユーザーによるセッション作成時に、パフォーマンスがわずかに低下します。これは、各ユーザーがデータベースに接続した時点で、そのユーザーのすべてのリソース制限データがロードされるためです。

関連項目:

セキュリティ管理者の詳細は、『Oracle Database管理者ガイド』を参照してください。 

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

システム・リソースのタイプと制限

Oracle Databaseでは、CPUタイムと論理読込みを含め、いくつかのタイプのシステム・リソースの使用を制限できます。 一般に、それぞれのリソースは、セッション・レベル、コール・レベル、またはその両方で制御できます。次の各項で詳細を説明します。

セッション・レベル

ユーザーがデータベースに接続するたびに、セッションが作成されます。 それぞれのセッションは、Oracle Databaseを実行するコンピュータのCPUタイムとメモリーを消費します。複数のリソース制限をセッション・レベルで設定できます。

ユーザーがセッション・レベルのリソース制限を超えると、現行の文は終了(ロールバック)し、セッションの制限に達したことを示すメッセージが戻されます。この時点では、カレント・トランザクション内のそれ以前のすべての文の結果はそのまま残っています。ユーザーが実行できる操作は、COMMITROLLBACKまたは接続の切断(この場合、カレント・トランザクションはコミットされます)のみです。それ以外の操作を実行すると、エラーが発生します。トランザクションがコミットまたはロールバックされた後も、カレント・セッションではユーザーはどんな作業も完了できません。

コール・レベル

SQL文が実行されるたびに、いくつかのステップが実行され文が処理されます。 この処理では、データベースに対して複数のコールが異なる実行フェーズの一部として発行されます。 1回のコールで過度にシステムが使用されないように、Oracle Databaseでは、複数のリソース制限をコール・レベルで設定できます。

ユーザーがコール・レベルのリソース制限を超えると、Oracle Databaseは文の処理を停止してその文をロールバックし、エラーを戻します。 ただし、カレント・トランザクションのそれ以前の文の結果はそのまま残り、そのユーザー・セッションは接続されたままになります。

CPUタイム

SQL文やその他のタイプのコールがOracle Databaseに発行されると、そのコールを処理するために一定量のCPUタイムが必要になります。平均的なコールであれば、わずかなCPUタイムですみます。ただし、大量のデータや冗長な問合せを伴うSQL文はCPUタイムを大量にコンシュームすることがあるため、他の処理に使用できるCPUタイムが少なくなります。

CPUタイムが無制限に消費されないようにするため、1回のコール当たりのCPUタイムと、
1つのセッション中にOracleコールに使用されるCPUタイムの合計に対して、固定した制限または動的な制限を設定できます。これらの制限は、コールやセッションに使用される1/100秒(0.01秒)単位のCPUタイムで設定し、測定されます。

Logical Reads(論理読取り)

I/Oは、データベース・システムで最もリソースの使用量が多い操作の1つです。 I/Oを集中的に実行するSQL文は、メモリーとディスクの使用を独占することがあるため、他のデータベース操作がこれらのリソースをめぐって競合する原因になる可能性があります。

単一の原因による過度のI/Oが発生しないようにするために、Oracle Databaseでは、1コール当たりおよび1セッション当たりの論理データ・ブロック読取り数を制限できます。論理データ・ブロック読込みには、メモリーとディスクの両方からの論理データ・ブロック読込みが含まれます。これらの制限は、1コールまたは1セッション中に実行されるブロック読込みの数として設定し、測定されます。

その他のリソース制限

Oracle Databaseでは、さらにいくつかの、その他のセッション・レベルのリソース制限が提供されています。

プロファイル

一般的に、プロファイルとはユーザーに適用される属性の集合で、それらの属性を共有する複数ユーザーの中の任意のユーザーに関する単一の参照になります。Oracle Internet Directoryのユーザー・プロファイルには、各ユーザーのディレクトリ使用と認証に関連した広範囲な属性が含まれています。同様に、Oracle Label Securityのプロファイルには、Oracle Label Securityのユーザー管理や操作管理に役立つ属性が含まれています。 プロファイル属性にはシステム・リソースに関する制限を含めることができますが、それが目的の場合はデータベース・リソース・マネージャの使用をお薦めします。

関連項目:

 

リソース制限の値の決定

プロファイルを作成し、そのプロファイルに含めるリソース制限を決定する前に、各リソース制限について適切な値を決定する必要があります。これらの値は、典型的なユーザーが実行する操作のタイプを基準として決定できます。たとえば、あるクラスのユーザーが通常は大量の論理データ・ブロック読込みを実行しない場合、LOGICAL_READS_PER_SESSIONおよびLOGICAL_READS_PER_CALLの制限は控えめに設定してください。

通常、ユーザー・プロファイルの適切なリソース制限値を決定するには、それぞれのタイプのリソースの使用状況について履歴情報を収集するのが最善です。たとえば、データベース管理者やセキュリティ管理者は、AUDIT SESSION句を使用して、CONNECT_TIMELOGICAL_READS_PER_SESSIONおよびLOGICAL_READS_PER_CALLの制限値についての情報を収集できます。

その他の制限値の統計情報は、Oracle Enterprise Manager(またはSQL*Plus)のモニター機能、特に統計モニターを使用して収集できます。

関連項目:

 


戻る 次へ
Oracle
Copyright © 2003, 2008, Oracle Corporation.
All Rights Reserved.
目次
目次
索引
索引