10gリリース2（10.2）
B19269-04
 目次 |
 索引 |
| Oracle Database セキュリティ・ガイド 10gリリース2（10.2） B19269-04 |
|
認可には、主に次の2つのプロセスにあります。
この章では、この種の制限を個々のユーザーまたはユーザー・グループに対して適用または除外するための基本概念とメカニズムについて説明します。この章の内容は、次のとおりです。
| トピックのカテゴリ | トピックへのリンク |
|---|---|
|
権限の取得と使用方法 |
権限の概要 |
|
ロールの取得、使用および制限方法 |
|
|
リソース制限をユーザーに適用する方法と理由 |
|
|
プロファイルの決定と使用方法 |
|
関連項目:
DBAやアプリケーション・プログラマなどを含めたユーザーの権限、ロールおよびプロファイルの構成と管理方法については、第11章「ユーザー権限、ロールおよびプロファイルの管理」を参照してください。 |
権限は、特定のタイプのSQL文を実行するため、または別のユーザーのオブジェクトにアクセスするための権利です。たとえば、次のことをする権利が権限です。
権限をユーザーに付与すると、そのユーザーはそれぞれの業務に必要な作業を実行できるようになります。 なお、権限は、必要な作業を実行する上でその権限が必要なユーザーにのみ付与してください。必要でない権限まで付与すると、セキュリティを維持できなくなる可能性があります。ユーザーは次の2つの方法で権限を受け取ることができます。
employees表にレコードを挿入する権限を、ユーザーSCOTTに明示的に付与できます。
employees表からレコードを選択、挿入、更新および削除する権限を、clerkという名前のロールに付与し、このロールをユーザーscottやbrianに付与できます。
ロールを使用することによって権限の管理が容易になり、改善されるため、通常、権限は個々のユーザーではなくロールに付与する必要があります。
|
関連項目:
|
権限には、次の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
スキーマ・オブジェクトとそのシノニムは、権限に関しては等価です。 つまり、表、ビュー、順序、プロシージャ、ファンクションまたはパッケージについて付与されるオブジェクト権限は、その基礎となるオブジェクトを名前で参照するかシノニムを使用するかにかかわらず、適用されます。
たとえば、jward.empという表があり、それにjward.employeeというシノニムがある場合に、ユーザーjwardが次の文を発行するとします。
GRANT SELECT ON emp TO swilliams;
ユーザーswilliamsは、名前またはシノニムjward.employeeを使用して表を参照することによって、jward.empを問い合せることができます。
SELECT * FROM jward.emp; SELECT * FROM jward.employee;
表、ビュー、順序、プロシージャ、ファンクションまたはパッケージに対するオブジェクト権限を、そのオブジェクトのシノニムに付与した場合の結果は、シノニムを使用しない場合と同じです。 たとえば、jwardがemp表に対するSELECT権限をswilliamsに付与する場合、jwardは次のどちらの文でも使用できます。
GRANT SELECT ON emp TO swilliams; GRANT SELECT ON employee TO swilliams;
シノニムが削除された場合は、そのシノニムを指定して権限が付与されていた場合でも、基礎になるスキーマ・オブジェクトに対して付与された権限はすべて有効なままです。
表に対するスキーマ・オブジェクト権限によって、データ操作言語（DML）またはデータ定義言語（DDL）操作レベルでの表のセキュリティが実現します。次の各項で詳細を説明します。
表またはビューでDELETE、INSERT、SELECTおよびUPDATEの各DML操作を使用する権限を付与できます。 これらの権限は、表のデータの問合せや操作が必要なユーザーとロールに対してのみ付与してください。
表に対するINSERT権限とUPDATE権限は、表の特定の列に制限できます。選択的なINSERT権限を付与されたユーザーは、選択した列に値を持つ行を挿入できます。 他のすべての列には、NULLまたはその列のデフォルト値が挿入されます。選択的なUPDATE権限によって、ユーザーは行の特定の列に限ってその値を更新できます。 機密データに対するユーザー・アクセスを制限するには、INSERT権限とUPDATE権限を選択的に使用します。
たとえば、データ入力ユーザーにemployees表のsalary列を変更させないようにするには、そのsalary列を除外した選択的なINSERT権限またはUPDATE権限を付与できます。また、salary列を除外したビューによって、同じ制限をさらに高いセキュリティ・レベルで実現できます。
ALTER、INDEXおよびREFERENCESの各権限は、表に対するDDL操作の実行を許可します。これらの権限によって、他のユーザーは表への依存性を変更または作成できるため、権限の付与は控えめに行う必要があります。
表に対してDDL操作を実行するユーザーには、さらに他のシステム権限やオブジェクト権限が必要な場合があります。たとえば、表にトリガーを作成するには、その表に対するALTER TABLEオブジェクト権限とCREATE TRIGGERシステム権限の両方が必要です。
INSERT権限およびUPDATE権限と同じように、表の特定の列にREFERENCES権限を付与できます。REFERENCES権限を付与されたユーザーは、付与の対象となった表を、自分の表の中に作成する外部キーの親キーとして使用できます。外部キーの存在によって、親キーに対して実行できるデータ操作と表の変更が制限されるため、このアクションは特殊な権限によって制御されます。列固有のREFERENCES権限によって、権限受領者が使用できるのは、指定された列（この列には、当然、親表の主キーまたは一意キーが最低1つ含まれている）に制限されます。
ビューとは、1つ以上の表（他のビュ-が含まれている場合がある）から選択されたデータを表現したものです。ビューは、基礎となる表の構造および選択されたデータを示すため、ストアド・クエリーの結果とみなすことができます。ビュー内に実際のデータはなく、表示する内容は基礎となる表とビューから導出されます。ビューは問い合せることができ、表示されるデータは変更できます。ビュー内のデータは更新または削除でき、新規データも挿入できます。これらの操作は、ビューの基礎である表を直接変更するため、実表の整合性制約とトリガーに従います。
表に対するDMLオブジェクト権限は、ビューに対しても同じように適用できます。ビューに対するスキーマ・オブジェクト権限は、ビューの導出元の実表に実際に影響する様々なDML操作を許可します。次の各項では、これらの権限について説明します。
ビューを作成するには、次に示す要件を満たす必要があります。
GRANT OPTION句付きで付与されているか、またはADMIN OPTION句によって適切なシステム権限が付与されている必要があります。 これらの権限がユーザーにない場合、権限受領者はそのユーザーのビューにアクセスできません。ビューを使用するために必要な権限は、ビュー自体に対する適切な権限のみです。ビューの基礎となるベース・オブジェクトに対する権限は必要ありません。
ビューの場合は、表に対してさらに2つのセキュリティ・レベル（列レベルと値ベースのセキュリティ）が追加されます。
employees表の中からemployee_id、last_nameおよびmanager_idの3列のみを表示するようにビューを定義できます。
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 ANY PROCEDUREシステム権限があるユーザーは、データベース内の任意のプロシージャを実行できます。プロシージャの実行権限は、ロールを介してユーザーに付与できます。
定義者と呼ばれるプロシージャの所有者は、参照オブジェクトに対する必要なオブジェクト権限をすべて所有している必要があります。 プロシージャの所有者が別のユーザーにそのプロシージャを使用する権限を付与すると、プロシージャで参照されるオブジェクトに対する所有者のオブジェクト権限が、そのユーザーのプロシージャ実行に適用されます。このような権限は、定義者権限と呼ばれます。
所有者以外のプロシージャのユーザーは、実行者と呼ばれます。実行者権限プロシージャの場合は、参照オブジェクトに対する追加の権限が必要ですが、定義者権限プロシージャの場合は不要です。
定義者権限プロシージャのユーザーに必要なのは、そのプロシージャを実行する権限のみで、そのプロシージャでアクセスする基礎となるオブジェクトに対する権限は不要です。これは、定義者権限プロシージャは、その実行者に関係なく、プロシージャを所有するユーザーのセキュリティ・ドメインの下で動作するためです。 プロシージャの所有者は、参照オブジェクトに対する必要なオブジェクト権限をすべて所有している必要があります。定義者権限プロシージャのユーザーに付与する権限が少ないほど、データベース・アクセスを厳密に制御できます。
定義者権限プロシージャを使用すると、プライベート・データベース・オブジェクトへのアクセスを制御し、データベースのセキュリティ・レベルを強化できます。定義者権限プロシージャを記述し、ユーザーにEXECUTE権限のみを付与することによって、そのプロシージャを介さない場合には、ユーザーが参照オブジェクトにアクセスできないように規定できます。
実行時には、定義者権限ストアド・プロシージャの所有者の権限が、プロシージャの実行前に常にチェックされます。参照オブジェクトに対して必要な権限が、定義者権限プロシージャの所有者から取り消されていると、所有者もその他のユーザーも、プロシージャを実行できません。
実行者権限プロシージャは、すべての実行者権限で実行されます。定義者権限プロシージャによって実行者権限プロシージャが直接または間接的にコールされないかぎり、ロールは有効です。実行者権限プロシージャのユーザーには、そのプロシージャが実行者のスキーマ内で解決される外部参照を介してアクセスする、オブジェクトに対する権限が（直接、またはロールを介して）必要です。
実行者には、DML文または動的SQL文に埋め込まれているプログラム参照にアクセスする権限が実行時に必要です。これは、この種のプログラム参照は実質的に実行時に再コンパイルされるためです。
PL/SQLファンクションの直接コールなど、他のすべての外部参照の場合、所有者権限はコンパイル時にチェックされ、実行時にはチェックされません。したがって、実行者権限プロシージャのユーザーには、DML文や動的SQL文の外側にある外部参照に対する権限は不要です。また、実行者権限プロシージャの開発者による権限の付与が必要なのは、プロシージャ自体に対する権限付与のみで、その実行者権限プロシージャによって直接参照されるすべてのオブジェクトに対する権限付与は必要ありません。
複数のプログラム・ユニットで構成したソフトウェア・バンドルを作成し、一部のプログラム・ユニットには定義者権限を、残りのプログラム・ユニットには実行者権限を付与すると、プログラムのエントリ・ポイントを限定できます（コントロール・ステップイン）。エントリ・ポイント・プロシージャの実行権限があるユーザーは、内部プログラム・ユニットも間接的に実行できますが、内部プログラムを直接コールすることはできません。
プロシージャを作成するユーザーには、CREATE PROCEDUREまたはCREATE ANY PROCEDUREシステム権限が必要です。プロシージャを変更する、つまりプロシージャを手動で再コンパイルするユーザーは、そのプロシージャを所有しているか、ALTER ANY PROCEDUREシステム権限が必要です。
プロシージャを所有するユーザーには、プロシージャ本体で参照されるスキーマ・オブジェクトに対する権限も必要です。プロシージャを作成するには、そのプロシージャによって参照されるすべてのオブジェクトに対する必要な権限（システム権限やオブジェクト権限）が明示的に付与されている必要があります。これらの必要な権限は、ロールを介して取得することはできません。これには、作成中のプロシージャ内でコールするプロシージャに対するEXECUTE権限も含まれます。
パッケージに対するEXECUTEオブジェクト権限があるユーザーは、そのパッケージ内の任意のパブリック・プロシージャまたはファンクションを実行し、任意のパブリック・パッケージ変数の値へのアクセスや変更を実行できます。 パッケージの各構成メンバーに、特定のEXECUTE権限を付与することはできません。したがって、データベース・アプリケーションのプロシージャ、ファンクションおよびパッケージを開発する場合は、セキュリティの確立に関して2つの選択肢を考慮してください。これらの選択肢について、次の例で説明します。
この例では、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;
この例では、単一のパッケージ本体にある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つのパッケージ内に定義され、宣言されたグローバル変数やカーソルなどを共有できます。 トップ・レベルのプロシージャであるhireとfire、および追加のパッケージraise_bonusを宣言することによって、選択的なEXECUTE権限をメイン・パッケージ内のプロシージャに対して付与できます。
GRANT EXECUTE ON hire, fire TO big_bosses; GRANT EXECUTE ON raise_bonus TO little_bosses;
次の各項では、型、メソッドおよびオブジェクトに対する権限の使用について説明します。
Oracleでは、名前付きの型（オブジェクト型、VARRAYおよびネストした表）について、表5-1のシステム権限が定義されています。
RESOURCEロールには、CREATE TYPEシステム権限が含まれています。DBAロールには、これらの権限すべてが含まれています。
名前付きの型に適用されるオブジェクト権限は、EXECUTEのみです。 名前付きの型に対するEXECUTE権限があるユーザーは、その型を使用して次の操作を実行できます。
EXECUTE権限によって、ユーザーは、型コンストラクタも含めて、その型のメソッドを起動できます。これは、ストアドPL/SQLプロシージャに対するEXECUTE権限と同じです。
メソッドの実行は、他のストアドPL/SQLプロシージャと同じです。
型を作成するには、次の要件を満たす必要があります。
CREATE TYPEシステム権限が必要です。他のユーザーのスキーマに型を作成するには、CREATE ANY TYPEシステム権限が必要です。この2つの権限は、明示的に、またはロールを介して取得できます。
EXECUTEオブジェクト権限が明示的に付与されているか、EXECUTE ANY TYPEシステム権限が付与されている必要があります。所有者が、ロールを介して必要な権限を取得することはできません。
GRANT OPTIONの参照された型へのEXECUTE権限、またはADMIN OPTIONのEXECUTE ANY TYPEシステム権限が必要です。 どちらの権限もない型の所有者は、権限不足のため、型へのアクセス権を他のユーザーに付与できません。
型を使用して表を作成するには、表の作成要件と次の要件を満たす必要があります。
EXECUTEオブジェクト権限が明示的に付与されているか、EXECUTE ANY TYPEシステム権限が付与されている必要があります。所有者が、ロールを介して必要な権限を取得することはできません。
GRANT OPTIONの参照された型へのEXECUTE権限、またはADMIN OPTIONのEXECUTE ANY TYPEシステム権限が必要です。 どちらの権限もない表の所有者は、権限不足のため、型へのアクセス権を他のユーザーに付与できません。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;
DML文に対する列レベルと表レベルの既存の権限は、列オブジェクトと行オブジェクトの両方に適用されます。 Oracleでは、オブジェクト表に対して、表5-2の権限が定義されています。
|
権限 |
許可される操作 |
|---|---|
|
|
オブジェクトとその属性に表からアクセスできます。 |
|
|
表の行を構成するオブジェクトの属性を変更できます。 |
|
|
表に新規オブジェクトを作成できます。 |
|
|
行を削除できます。 |
同様に、列オブジェクトには表に対する権限と列に対する権限が適用されます。インスタンスの取得のみでは、型情報は明らかになりません。ただし、クライアントは、型インスタンスのイメージを解釈するために、名前付きの型の情報にアクセスする必要があります。 クライアントがこのような型情報を要求すると、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は、次のイベントに対する権限をチェックし、アクションに対する権限がクライアントにない場合はエラーを戻します。
REF値を使用してオブジェクト・キャッシュ内でオブジェクトを確保すると、Oracle Databaseは、そのオブジェクトが含まれているオブジェクト表に対するSELECT権限をチェックします。
UPDATE権限をチェックします。
INSERT権限をチェックします。
DELETE権限をチェックします。
EXECUTE権限をチェックします。
クライアントの第3世代言語アプリケーション内でオブジェクトの属性を変更すると、Oracle Databaseはオブジェクト全体を更新します。 したがって、ユーザーにはオブジェクト表に対するUPDATE権限が必要です。 オブジェクト表の特定の列のみに対するUPDATE権限では不十分です。これは、アプリケーションによる変更の対象がこれらの特定列に対応する属性のみの場合にも同じです。 したがって、Oracle Databaseは、オブジェクト表に対する列レベルの権限はサポートしていません。
プロシージャや表などのストアド・オブジェクトと同様に、他のオブジェクトから参照される型を依存性があると呼びます。 表が依存する型については、特殊な問題点がいくつかあります。表には、アクセス用の型定義に依存するデータが含まれているため、その型を変更すると、格納されているすべてのデータにアクセスできなくなります。 変更によってこのような結果になるのは、型に必要な権限が取り消された場合や、型または依存型が削除された場合です。どちらかのアクションが発生すると、表は無効になり、アクセスできなくなります。
必要な権限が再び付与されると、権限がないために無効になった表は自動的に有効になり、アクセスできるようになります。依存型が削除されたために無効になった表は、アクセス不能のままで、実行できるアクションは表の削除のみです。
型に対する権限の取消しや型の削除は重大な影響が生じるため、デフォルトでは、SQL文のREVOKEとDROP TYPEは限定されたセマンティクスで実装されます。つまり、どちらの文でも、名前付きの型が表または型に依存している場合は、エラーが戻されて文は異常終了します。 ただし、どちらの文も、FORCE句を使用すると常に正常終了します。 依存する表がある場合、その表は無効になります。
ロールを使用することで、権限の管理および制御が容易になります。ロールは、関連する権限のグループに名前を付けたもので、ユーザーや他のロールに付与します。 各ロール名はデータベース内で一意にする必要があり、どのユーザー名または他のどのロール名とも同一にすることはできません。スキーマ・オブジェクトとは異なり、ロールはスキーマに含まれているわけではありません。そのため、ロールを作成したユーザーを削除しても、そのロールに影響はありません。
ロールは、エンド・ユーザーのシステム権限とスキーマ・オブジェクト権限を容易に管理できるように設計されており、多くの場合はOracle Internet Directoryでメンテナンスされます。ただし、ストアド・プログラム構成メンバーの中からスキーマ・オブジェクトにアクセスする権限は、直接付与する必要があるため、ロールは、アプリケーション開発者が使用することを目的としていません。
次の各項では、ロールの効率的な管理について説明します。
表5-3では、データベース内での権限管理をさらに容易にする、ロールの特性について説明します。
データベース・アプリケーションについてのロールは、通常、データベース管理者が作成します。DBAは、アプリケーションの実行に必要なすべての権限を保護アプリケーション・ロールに付与します。その後、DBAは、保護アプリケーション・ロールを別のロールや特定のユーザーに付与できます。アプリケーションは複数の異なるロールを持つことができます。各ロールには、アプリケーションの使用時におけるデータ・アクセスの量を考慮して、異なる権限の集合を付与します。
DBAはパスワード付きのロールを作成し、そのロールに付与された権限が無許可で使用されるのを防止できます。通常、アプリケーションは起動時に適切なロールが使用可能になるように設計されます。 そのため、アプリケーション・ユーザーは、アプリケーション・ロールのパスワードを知る必要がありません。
|
関連項目:
|
通常は、次のどちらかの目的でロールを作成します。
図5-1とその後の項で、ロールの2通りの使用方法について説明します。
アプリケーション・ロールには、特定のデータベース・アプリケーションを実行するために必要な権限をすべて付与します。そして、その保護アプリケーション・ロールを、他のロールや特定のユーザーに対して付与します。1つのアプリケーションに対して複数の異なるロールを設定し、アプリケーション使用時のデータ・アクセスの量や範囲にあわせて異なる権限セットを各ロールに割り当てることができます。
ユーザー・ロールは、共通の権限要件を持つデータベース・ユーザーのグループのために作成されるロールです。ユーザーの権限は、保護アプリケーション・ロールと権限をユーザー・ロールに付与し、そのユーザー・ロールを適切なユーザーに付与することによって管理します。
ロールには、システム権限またはスキーマ・オブジェクト権限を付与できます。任意のロールを任意のデータベース・ユーザーまたは別のロールに付与できます。ただし、ロールをそのロール自体に付与することはできません。また、ロールを循環的に付与することはできません。つまり、ロールYがあらかじめロールXに付与されている場合は、ロールXをロールYに付与することはできません。
権限を選択的に使用できるように、Oracle Databaseでは、データベース・アプリケーションとユーザーがロールを使用可能または使用禁止にできます。ユーザーに付与した各ロールは、任意の時点で使用可能または使用禁止にできます。 ユーザーのセキュリティ・ドメインには、そのユーザーに対して現在使用可能になっているすべてのロールの権限が含まれており、ユーザーに対して現在使用禁止になっているロールの権限は除外されています。
ロールに対して付与されたロールは、間接的に付与されたロールと呼ばれます。この種のロールは、ユーザーに対して明示的に使用可能または使用禁止にすることができます。ただし、別のロールを含んだロールを使用可能にすると、直接的に付与されたロールに含まれる間接的に付与されたロールは、すべて暗黙のうちに使用可能になります。
ユーザーや別のロールに対してロールを付与したり取り消すには、次のいずれかの方法を使用します。
ロールに対して権限を付与または取り消す場合にも同じオプションを使用します。 また、Oracleを実行しているオペレーティング・システムを使用したり、ネットワーク・サービスを介して、ロールをユーザーに対して付与したり取り消すことができます。
GRANT ANY ROLEシステム権限があるユーザーは、グローバル・ロールを除き、他のユーザーの任意のロールまたはデータベースのロールを付与または取り消すことができます。このシステム権限は非常に強力であるため、付与する際は注意が必要です。
ADMIN OPTION付きでロールを付与されたユーザーは、データベースの他のユーザーやロールに対してロールを付与したりそのロールを取り消すことができます。つまり、このオプションによって、選択的なロールの管理が可能になります。
各ロールと各ユーザーには、それぞれ独自のセキュリティ・ドメインがあります。 ロールのセキュリティ・ドメインには、ロール自体に付与されている権限と、そのロールに付与されたロールに対して付与されている権限が含まれます。
ユーザーのセキュリティ・ドメインには、対応するスキーマ内のすべてのスキーマ・オブジェクトの権限、そのユーザーに付与されている権限、およびそのユーザーに付与されている現在使用可能なロールの権限が含まれます（1つのロールをあるユーザーに対して使用可能にし、別のユーザーに対しては使用禁止にすることもできます）。 このドメインには、ユーザー・グループPUBLICに対して付与されている権限とロールも含まれます。
PL/SQLブロック内でのロールの使用方法は、そのブロックが無名ブロックであるか名前付きブロック（ストアド・プロシージャ、ファンクションまたはトリガー）であるか、および定義者権限または実行者権限のどちらで実行されるかによって異なります。
定義者権限で実行される名前付きPL/SQLブロック（ストアド・プロシージャ、ファンクションまたはトリガー）では、すべてのロールは使用禁止になっています。ロールは権限チェックに使用されず、定義者権限プロシージャ内ではロールを設定できません。
SESSION_ROLESビューは、現在使用可能になっているすべてのロールを示します。 定義者権限で実行される名前付きPL/SQLブロックでSESSION_ROLESを問い合せると、その問合せは行を戻しません。
実行者権限で実行される名前付きPL/SQLブロックと、無名PL/SQLブロックは、使用可能なロールを介して付与された権限に基づいて実行されます。実行者権限を持つPL/SQLブロック内での権限チェックにはカレント・ロールが使用され、動的SQLを使用してセッション中にロールを設定できます。
ユーザーがDDL文を正常に実行するには、その文に応じて1つ以上の権限が必要になります。たとえば、表を作成するには、CREATE TABLEまたはCREATE ANY TABLEシステム権限が必要です。 別のユーザーに属する表のビューを作成するには、CREATE VIEWまたはCREATE ANY VIEWシステム権限のみでなく、その表に対するSELECTオブジェクト権限またはSELECT ANY TABLEシステム権限も必要です。
Oracle Databaseでは、特定のDDL文での特定の権限の使用を制限することによって、ロールを介して受け取った権限への依存性を回避します。次の規則は、DDL文に関する権限の制限を示しています。
例外: 表に対するREFERENCESオブジェクト権限は、ロールを介して付与されている場合、表の外部キー定義には使用できません。
ロールを介して受け取った権限の使用許可と使用制限について、次の例で具体的に説明します。
次のようなユーザーを想定します。
CREATE VIEWシステム権限を持つロールが付与されています。
employees表のSELECTオブジェクト権限を含むロールが付与されていますが、このemployees表のSELECTオブジェクト権限は間接的に付与されています。
departments表に対するSELECTオブジェクト権限が直接付与されています。
前述の権限がこのユーザーに直接的および間接的に付与されているとすると、
employees表とdepartments表の両方に対してSELECT文を発行できます。
employees表のCREATE VIEW権限とSELECT権限がロールを介して付与されていますが、employees表のSELECTオブジェクト権限はロールを介して付与されているため、employees表に基づいた使用可能なビューは作成できません。作成されたビューにアクセスすると、エラーになります。
CREATE VIEW権限がロールを介して付与され、departments表のSELECT権限が直接付与されているため、departments表のビューは作成できます。
次のロールは、Oracle Databaseに対して自動的に定義されます。
これらのロールは、旧バージョンのOracle Databaseとの下位互換のために提供されており、Oracleデータベース内の他のロールと同じ方法で変更できます。
環境によっては、オペレーティング・システムでデータベース・セキュリティを管理できる場合もあります。オペレーティング・システムを使用して、データベース・ロールの付与と取消しや、パスワードの認証を管理できます。この機能は、すべてのオペレーティング・システムで利用できるとはかぎりません。
分散データベース環境でロールを使用する場合は、必要なすべてのロールを分散（リモート）セッションのデフォルト・ロールとして設定する必要があります。 ローカル・データベース・セッション内からリモート・データベースに接続しているときは、ロールを使用可能にできません。たとえば、リモート・サイトでロールを使用可能にしようとするリモート・プロシージャは実行できません。
Oracle Databaseでは、保護アプリケーション・ロールが用意されています。このロールは、認可されたPL/SQLパッケージでのみ有効にできます。このメカニズムは、アプリケーションを起動するロールの有効化を制限します。
パスワードが、アプリケーションのソース・コードに埋め込まれていない場合、または表に格納されていない場合、セキュリティは強化されます。そのかわりに、ロールの有効化を認可するPL/SQLパッケージを指定して、保護アプリケーション・ロールを作成できます。パッケージの識別は、ロールを有効化するのに十分な権限があるかどうかの決定に使用します。ロールの有効化の前に、アプリケーションはユーザーがプロキシを介して接続しているかどうかをチェックするなど、認証およびカスタマイズ認可を実行できます。
保護アプリケーション・ロールは、CREATE ROLE ... IDENTIFIED USING文を使用して作成します。次に例を示します。
CREATE ROLE admin_role IDENTIFIED USING hr.admin;
この例から次のようなことがわかります。
この文を実行するには、CREATE ROLEシステム権限が必要です。
このロールは、ユーザーに割り当てられるとそのユーザーのデフォルト・ロールになり、パッケージを使用せずにログイン時に自動的に有効になります。 デフォルト・ロールを持つユーザーは、そのロールを使用するために認証を受ける必要はありません。 たとえば、ロールに対するパスワードは不要で、要求もされません。
IDENTIFIED USING句で指定した使用方法のみにロールを制限するには、次のいずれかのアクションを実行します。
DEFAULT ROLE ALL EXCEPT role句を指定したALTER USER文を発行して、アプリケーション・ロールをroleに置き換えます。これによって、roleを使用できるのは、認可されたパッケージを実行するアプリケーションのみとなります。
role句を使用します。
実行者権限プロシージャ内で有効化されたロールは、プロシージャの終了後も有効です。そのため、ロールの有効化を処理する専用プロシージャは、セッションの終了まで使用できます。
ユーザーのセキュリティ・ドメインの一部として、各ユーザーが使用できる各種のシステム・リソースの容量に制限を設定できます。これにより、CPUタイムなどの貴重なシステム・リソースが無制限に浪費されるのを防止できます。
このリソース制限機能は、システム・リソースに多額の費用がかかる大規模なマルチ・ユーザー・システムでは非常に有効です。1人以上のユーザーが過度にリソースを使用すると、データベースの他のユーザーに有害な影響を与える可能性があります。 シングル・ユーザー・データベースや小規模なマルチ・ユーザー・データベースの場合は、ユーザーがシステム・リソースを消費しても影響は少ないため、システム・リソース機能はそれほど重要ではありません。
ユーザーのリソース制限は、データベース・リソース・マネージャを使用して管理します。パスワード管理の作業環境は、ユーザーごとに個別にプロファイルを使用して設定するか、または多数のユーザー用のデフォルト・プロファイルを使用して設定できます。それぞれのOracleデータベースに指定できるプロファイルの数に、制限はありません。Oracleにおいて、セキュリティ管理者は、プロファイルによるリソース制限の規定を全体的に使用可能または使用禁止に設定できます。
|
関連項目:
|
リソース制限を設定すると、ユーザーによるセッション作成時に、パフォーマンスがわずかに低下します。これは、各ユーザーがデータベースに接続した時点で、そのユーザーのすべてのリソース制限データがロードされるためです。
この項の内容は、次のとおりです。
Oracle Databaseでは、CPUタイムと論理読込みを含め、いくつかのタイプのシステム・リソースの使用を制限できます。 一般に、それぞれのリソースは、セッション・レベル、コール・レベル、またはその両方で制御できます。次の各項で詳細を説明します。
ユーザーがデータベースに接続するたびに、セッションが作成されます。 それぞれのセッションは、Oracle Databaseを実行するコンピュータのCPUタイムとメモリーを消費します。複数のリソース制限をセッション・レベルで設定できます。
ユーザーがセッション・レベルのリソース制限を超えると、現行の文は終了（ロールバック）し、セッションの制限に達したことを示すメッセージが戻されます。この時点では、カレント・トランザクション内のそれ以前のすべての文の結果はそのまま残っています。ユーザーが実行できる操作は、COMMIT、ROLLBACKまたは接続の切断（この場合、カレント・トランザクションはコミットされます）のみです。それ以外の操作を実行すると、エラーが発生します。トランザクションがコミットまたはロールバックされた後も、カレント・セッションではユーザーはどんな作業も完了できません。
SQL文が実行されるたびに、いくつかのステップが実行され文が処理されます。 この処理では、データベースに対して複数のコールが異なる実行フェーズの一部として発行されます。 1回のコールで過度にシステムが使用されないように、Oracle Databaseでは、複数のリソース制限をコール・レベルで設定できます。
ユーザーがコール・レベルのリソース制限を超えると、Oracle Databaseは文の処理を停止してその文をロールバックし、エラーを戻します。 ただし、カレント・トランザクションのそれ以前の文の結果はそのまま残り、そのユーザー・セッションは接続されたままになります。
SQL文やその他のタイプのコールがOracle Databaseに発行されると、そのコールを処理するために一定量のCPUタイムが必要になります。平均的なコールであれば、わずかなCPUタイムですみます。ただし、大量のデータや冗長な問合せを伴うSQL文はCPUタイムを大量にコンシュームすることがあるため、他の処理に使用できるCPUタイムが少なくなります。
CPUタイムが無制限に消費されないようにするため、1回のコール当たりのCPUタイムと、
1つのセッション中にOracleコールに使用されるCPUタイムの合計に対して、固定した制限または動的な制限を設定できます。これらの制限は、コールやセッションに使用される1/100秒（0.01秒）単位のCPUタイムで設定し、測定されます。
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_TIME、LOGICAL_READS_PER_SESSIONおよびLOGICAL_READS_PER_CALLの制限値についての情報を収集できます。
その他の制限値の統計情報は、Oracle Enterprise Manager（またはSQL*Plus）のモニター機能、特に統計モニターを使用して収集できます。
|
関連項目:
|
