| Oracle Databaseセキュリティ・ガイド 11g リリース1（11.1） E05730-05 |
|
 戻る |
 次へ |
認可には、主に次の2つのプロセスがあります。
データへのアクセス、処理または変更を特定のユーザーにのみ許可します。
ユーザーによるアクセスまたは操作に様々な制限を適用します。ユーザーに適用（または除外）する制限は、スキーマ、表または行などのオブジェクトや、時間（CPU、接続またはアイドル時間）などのリソースに適用できます。
ユーザー権限とは、特定タイプのSQL文を実行する権利、別のユーザーのオブジェクトにアクセスする権利、PL/SQLパッケージを実行する権利などを指します。権限のタイプは、Oracle Databaseによって定義されています。
ロールは、ユーザー（通常は管理者）が権限や他のロールをグループ化するために作成します。ロールを使用すると、複数の権限またはロールをユーザーに簡単に付与できます。
ここでは、次の一般的なカテゴリについて説明します。
システム権限。この権限の受領者は、データベースで標準的な管理作業を実行できます。権限受領者は信頼できるユーザーのみに制限してください。システム権限の詳細は、「システム権限の管理」を参照してください。
ユーザー・ロール。ロールでは、複数の権限やロールがグループ化されるため、複数のユーザーに対して権限を同時に付与したり、取り消すことができます。ユーザーによるロールの使用を可能にするには、そのユーザーに対してロールを使用可能にしておく必要があります。詳細は、「ユーザー・ロールの管理」を参照してください。
オブジェクト権限。オブジェクトの各タイプには、オブジェクト権限が対応付けられています。異なるタイプのオブジェクト権限を管理する方法は、「オブジェクト権限の管理」を参照してください。
権限をユーザーに付与すると、そのユーザーはそれぞれの業務に必要な作業を実行できます。なお、権限は、必要な作業を実行する上でその権限が必要なユーザーにのみ付与してください。必要でない権限まで付与すると、セキュリティを維持できなくなる可能性があります。たとえば、管理作業を実行しないユーザーには、SYS権限またはSYSDBA権限を付与しないでください。
ユーザーは次の2つの方法で権限を受け取ることができます。
権限を明示的にユーザーに付与します。たとえば、employees表にレコードを挿入する権限を、ユーザーpsmithに明示的に付与できます。
権限をロール（名前付きの権限グループ）に付与した上で、そのロールを1人以上のユーザーに付与します。たとえば、employees表からレコードを選択、挿入、更新および削除する権限を、clerkという名前のロールに付与し、このロールをユーザーpsmithやrobertに付与できます。
ロールを使用することで権限の管理が容易になり、改善されるため、通常は権限を個々のユーザーではなくロールに付与してください。
この項の内容は、次のとおりです。
システム権限とは、特定のアクションを実行する権限、または特定のタイプのスキーマ・オブジェクトに対してアクションを実行する権限のことです。たとえば、表領域を作成する権限や、データベース内の任意の表から行を削除する権限などがシステム権限です。
システム権限には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_ACCESSIBILITYをFALSEに設定すると、任意のスキーマのオブジェクトにアクセスできるシステム権限（たとえば、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、データベース管理者および必要なユーザーのみに付与してください。
明示的なオブジェクト権限のあるユーザーまたは管理権限で接続しているユーザー（SYSDBA）は、SYSスキーマ内のオブジェクトにアクセスできます。
表4-1に、SYSスキーマ内のオブジェクトへのアクセスが必要なユーザーに対して付与できるロールをリストします。
表4-1 SYSスキーマ・オブジェクトにアクセスできるロール
| ロール | 説明 |
|---|---|
|
このロールを付与されたユーザーには、データ・ディクショナリ・ビューに対する |
|
|
このロールを付与されたユーザーには、データ・ディクショナリ内にあるパッケージとプロシージャに対する |
|
|
このロールを付与されたユーザーは、システム監査表（ |
また、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キーワードを使用するシステム権限を使用すると、データベース内のオブジェクトのカテゴリ全体に対して権限を設定できます。たとえば、CREATE ANY PROCEDUREシステム権限を使用すると、ユーザーはデータベース内のどこにでもプロシージャを作成できます。ANY権限を持つユーザーが作成したオブジェクトの動作は、そのオブジェクトが作成されたスキーマに限定されません。たとえば、ユーザーMALCOEURにはCREATE ANY PROCEDURE権限があり、プロシージャをスキーマJONESに作成すると、そのプロシージャはJONESとして実行されることになります。ただし、JONESはMALCOEURによって作成されたプロシージャがJONESとして機能していることに気付かない可能性があります。JONESにDBA権限が付与されている場合は、MALCOEURがJONESとしてプロシージャを実行することで、セキュリティ違反が発生する可能性があります。
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はパスワード付きのロールを作成することで、そのロールに付与されている権限が無許可で使用されるのを防止できます。通常、アプリケーションは起動時に適切なロールが使用可能になるように設計されます。そのため、アプリケーション・ユーザーは、アプリケーション・ロールのパスワードを知る必要がありません。
データベース・アプリケーションに対する権限の管理（「アプリケーション・ロールの一般的な使用方法」を参照）
ユーザー・グループに対する権限の管理（「ユーザー・ロールの一般的な使用方法」を参照）
図4-1とその後の各項で、ロールの2通りの使用方法について説明します。
アプリケーション・ロールには、特定のデータベース・アプリケーションを実行するために必要な権限をすべて付与します。次に、そのセキュア・アプリケーション・ロールを、他のロールや特定のユーザーに対して付与します。1つのアプリケーションに対して複数の異なるロールを設定し、アプリケーション使用時のデータ・アクセスの量や範囲にあわせて異なる権限セットを各ロールに割り当てることができます。
各ロールと各ユーザーには、それぞれ独自のセキュリティ・ドメインがあります。ロールのセキュリティ・ドメインには、ロール自体に付与されている権限と、そのロールに付与されたロールに対して付与されている権限が含まれます。
ユーザーのセキュリティ・ドメインには、対応するスキーマ内のすべてのスキーマ・オブジェクトの権限、そのユーザーに付与されている権限、およびそのユーザーに付与されている現在使用可能なロールの権限が含まれます（1つのロールをあるユーザーに対して使用可能にし、別のユーザーに対しては使用禁止にすることもできます）。このドメインには、ユーザー・グループPUBLICに対して付与されている権限とロールも含まれます。PUBLICユーザー・グループは、データベース内のすべてのユーザーを表します。
PL/SQLブロック内でのロールの使用方法は、そのブロックが無名ブロックであるか、名前付きブロック（ストアド・プロシージャ、ファンクションまたはトリガー）であるか、および定義者権限または実行者権限のどちらで実行されるかによって異なります。
定義者権限で実行される名前付きPL/SQLブロック（ストアド・プロシージャ、ファンクションまたはトリガー）では、すべてのロールは使用禁止になっています。ロールは権限チェックに使用されず、定義者権限プロシージャ内ではロールを設定できません。
SESSION_ROLESビューには、現在使用可能なすべてのロールが表示されます。定義者権限で実行される名前付きPL/SQLブロックでSESSION_ROLESを問い合せると、その問合せは行を戻しません。
ユーザーがDDL文を正常に実行するには、その文に応じて1つ以上の権限が必要になります。たとえば、表を作成するには、CREATE TABLEまたはCREATE ANY TABLEシステム権限が必要です。別のユーザーに属する表のビューを作成するには、CREATE VIEWまたはCREATE ANY VIEWシステム権限のみでなく、その表に対するSELECT object権限またはSELECT ANY TABLEシステム権限も必要です。
Oracle Databaseでは、特定のDDL文での特定の権限の使用を制限することで、ロールを介して受け取った権限への依存性を回避します。次の規則は、DDL文に関する権限の制限を示しています。
DDL操作の実行をユーザーに許可するすべてのシステム権限およびスキーマ・オブジェクト権限は、ロールを介して受け取った場合でも使用可能。次に例を示します。
システム権限: CREATE TABLE、CREATE VIEWおよびCREATE PROCEDURE権限
スキーマ・オブジェクト権限: 表に対するALTERおよびINDEX権限
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には、データベース管理を容易にする一連の事前定義ロールが用意されています。 表4-3に示すこれらのロールは、データベース作成の一部である標準スクリプトの実行時に、Oracleデータベースに対して自動的に定義されます。他のオプションや製品をインストールすると、他の事前定義のロールが作成される場合があります。ユーザー定義のロールと同様に、これらの事前定義ロールに対しても、権限とロールの付与および取消しができます。
表4-3 Oracle Databaseの事前定義ロール
|
注意: インストールごとに独自のロールを作成し、必要な権限のみを割り当てる必要があります。これにより、使用している権限を詳細に制御できます。この処理により、Oracle Databaseが定義するロールをOracle Databaseが変更または削除するたびに、既存のロール、権限またはプロシージャを調整する必要もなくなります。たとえば、 CONNECTロールが現在保持している権限は、CREATE SESSIONのみです。CONNECTおよびRESOURCEの各ロールはともに、将来のOracle Databaseのリリースでは使用不可になる予定です。 |
ロールはCREATE ROLE文を使用して作成できますが、そのためにはCREATE ROLEシステム権限が必要です。通常、このシステム権限はセキュリティ管理者のみが持っています。
|
注意: 作成した直後のロールには、対応付けられた権限はありません。新しいロールに権限を対応付けるには、その新しいロールに権限や他のロールを付与する必要があります。 |
作成する各ロールには、データベースの既存のユーザー名やロール名とは異なる、一意の名前を指定する必要があります。ロールはどのユーザーのスキーマ内にも格納されません。マルチバイト・キャラクタ・セットを使用するデータベースでは、各ロール名に少なくとも1つのシングルバイト・キャラクタを含めることをお薦めします。ロール名がマルチバイト・キャラクタのみの場合、暗号化されたロール名とパスワードの組合せの安全性は大幅に低くなります。パスワードのガイドラインは、「パスワードの保護に関するガイドライン」のガイドライン1を参照してください。
例4-2では、clerkロールを作成しています。
IDENTIFIED BY句は、このロールを付与された特定ユーザーがロールを使用する前に、どの認可方式で認可される必要があるかを指定します。この句を指定しないか、またはNOT IDENTIFIEDを指定すると、認可がなくてもロールが使用可能になります。ロールには、必要な認可方式として次の方式を指定できます。
パスワードを使用したデータベースによる認可
指定のパッケージを使用したアプリケーションによる認可
オペレーティング・システム、ネットワークまたはその他の外部ソースによる外部認可
エンタープライズ・ディレクトリ・サービスによるグローバル認可
これらの認可については、次の各項で説明します。
ロールの認可方式を設定または変更するには、ALTER ROLE文を使用します。
例4-3は、clerkロールの変更方法を示しています。これによって、ロールを使用可能にするには、ユーザーが外部ソースによって認可されている必要があることが指定されます。
ロールの認可方式を変更するには、ALTER ANY ROLEシステム権限またはADMIN OPTION付きのロールが付与されている必要があります。
ここでは、ロールの認可方式について説明します。ロールを使用するには、ユーザーに対してロールを使用可能にする必要があります。
この項の内容は、次のとおりです。
データベースによって認可されたロールは、そのロールにパスワードを割り当てることで保護できます。パスワードで保護されたロールがユーザーに付与されている場合、そのロールは、適切なパスワードを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-5では、accts_recという名前のロールを作成しています。このロールを使用可能にするには、その前に、ユーザーが外部ソースによって認可されている必要があります。
オペレーティング・システムによるロール認証が有効となるのは、そのオペレーティング・システムによって、オペレーティング・システム権限をアプリケーションと動的にリンクできる場合のみです。ユーザーがアプリケーションを開始すると、オペレーティング・システムはオペレーティング・システム権限をそのユーザーに付与します。付与されたオペレーティング・システム権限は、アプリケーションに対応付けられたロールと一致します。この時点で、アプリケーションはアプリケーション・ロールを使用可能にできます。アプリケーションが終了すると、先に付与されたオペレーティング・システム権限は、そのユーザーのオペレーティング・システム・アカウントから取り消されます。
ロールをオペレーティング・システムによって認可する場合は、オペレーティング・システム・レベルで各ユーザーの情報を構成する必要があります。この操作は、オペレーティング・システムによって異なります。
ロールがオペレーティング・システムによって付与されている場合は、そのオペレーティング・システムによるロールの認可は不要です。
ユーザーがOracle Netを介してデータベースに接続する場合、デフォルトでは、そのユーザーのロールはオペレーティング・システムによって認証できません。これには、共有サーバー構成による接続が含まれます。共有サーバー構成での接続はOracle Netを必要とするためです。リモート・ユーザーはネットワーク接続を介して別のオペレーティング・システム・ユーザーになりすますおそれがあるため、デフォルトでこのような制限が適用されています。REMOTE_OS_ROLESはFALSE（デフォルト）に設定することをお薦めします。
このようなセキュリティの危険性の心配がないときに、ネットワーク・クライアントに対してオペレーティング・システムのロール認証を使用する場合は、データベース初期化パラメータ・ファイル内の初期化パラメータREMOTE_OS_ROLESをTRUEに設定します。この変更は、次回インスタンスを起動して、データベースをマウントするときに有効となります。
ロールはグローバル・ロールとして定義できます。この場合、そのロールを使用するために（グローバル）ユーザーはエンタープライズ・ディレクトリ・サービスによる認可を受ける必要があります。グローバル・ロールは、権限とロールを付与することによってデータベース内でローカルに定義しますが、グローバル・ロール自体をそのデータベース内のユーザーや他のロールに付与することはできません。グローバル・ユーザーがデータベースへの接続を試みると、エンタープライズ・ディレクトリへの問合せが実行され、そのユーザーに対応付けられたグローバル・ロールが取得されます。
例4-6では、グローバル・ロールを作成しています。
グローバル・ロールは、エンタープライズ・ユーザー・セキュリティの構成要素の1つです。グローバル・ロールは1つのデータベースにのみ適用されますが、エンタープライズ・ディレクトリに定義されたエンタープライズ・ロールに付与できます。エンタープライズ・ロールは複数データベースのグローバル・ロールを含んだディレクトリ構造であり、エンタープライズ・ユーザーに付与できます。
ユーザーのグローバル認証とグローバル認可、およびエンタープライズ・ユーザー管理におけるロールの概要については、「グローバルなユーザー認証と認可の構成」を参照してください。
ロールには、システム権限またはスキーマ・オブジェクト権限を付与できます。任意のロールを任意のデータベース・ユーザーまたは別のロールに付与できます。ただし、ロールをそのロール自体に付与することはできません。また、ロールを循環的に付与することもできません。つまり、ロールYがあらかじめロールXに付与されている場合、ロールXをロールYに付与することはできません。
権限を選択的に使用できるように、Oracle Databaseでは、データベース・アプリケーションとユーザーがロールを使用可能または使用禁止にできます。ユーザーに付与した各ロールは、任意の時点で使用可能または使用禁止にできます。ユーザーのセキュリティ・ドメインには、そのユーザーに対して現在使用可能になっているすべてのロールの権限が含まれており、ユーザーに対して現在使用禁止になっているロールの権限は除外されています。
ロールに対して付与されたロールは、間接的に付与されたロールと呼ばれます。この種のロールは、ユーザーに対して明示的に使用可能または使用禁止にできます。ただし、別のロールを含んだロールを使用可能にすると、直接的に付与されたロールに含まれる間接的に付与されたロールは、すべて暗黙のうちに使用可能になります。
ユーザーや別のロールに対してロールを付与したり、取り消すには、次のいずれかの方法を使用します。
ロールに対して権限を付与または取り消す場合にも同じオプションを使用します。
GRANT ANY ROLEシステム権限があるユーザーは、グローバル・ロールを除き、他のユーザーの任意のロールまたはデータベースのロールを付与したり、取り消すことができます。（グローバル・ロールは、Oracle Internet Directoryなどのディレクトリで管理されますが、グローバル・ロールの権限は単一のデータベース内に格納されます）。デフォルトでは、この権限はSYSまたはSYSTEMユーザーに付与されます。このシステム権限は非常に強力であるため、付与する際は注意が必要です。
ADMIN OPTION付きでロールを付与されたユーザーは、データベースの他のユーザーやロールに対してロールを付与したり、そのロールを取り消すことができます。つまり、このオプションによって、選択的なロールの管理が可能になります。
状況によっては、データベースからロールを削除した方がよい場合があります。削除したロールを付与されていたすべてのユーザーとロールのセキュリティ・ドメインは、削除したロール権限がなくなったことを反映するために、ただちに変更されます。削除したロールによって間接的に付与されていたロールもすべて、関連するセキュリティ・ドメインから削除されます。ロールを削除することによって、すべてのユーザーのデフォルト・ロール・リストからそのロールが自動的に削除されます。
オブジェクトの作成はロールを介して受け取った権限に依存しないため、ロールが削除されても、表や他のオブジェクトは削除されません。
ロールは、SQL文DROP ROLEを使用して削除します。ロールを削除するには、DROP ANY ROLEシステム権限またはADMIN OPTION付きのロールが付与されている必要があります。
DROP ROLE clerk;
この項では、SQL*Plusユーザーによるデータベース・ロールの使用を制限する機能について説明します（これによって、セキュリティに関わる深刻な問題を回避できます）。
事前作成データベース・アプリケーションは、アプリケーション使用中にユーザー・ロールを使用可能および使用禁止にすることも含めて、ユーザーのアクションを明示的に制御します。一方、SQL*Plusなどの非定型の問合せツールを使用すると、ユーザーは付与されたロールを使用可能および使用禁止にする文も含めて、あらゆるSQL文を発行できます（正常終了する場合としない場合があります）。
アプリケーションのユーザーは、そのアプリケーションに付加された権限を使用し、非定型ツールによってデータベース表に破壊的なSQL文を発行する恐れがあります。
たとえば、次の使用例を考えてみます。
Vacation（休暇）アプリケーションには、それに対応するvacationロールがあります。
このvacationロールには、emp_tab表に対してSELECT、INSERT、UPDATEおよびDELETE文を発行する権限が含まれています。
Vacationアプリケーションは、vacationロールを介して取得した権限の使用を制御します。
ここで、vacationロールを付与されたユーザーを考えてみます。このユーザーが、Vacationアプリケーションを使用するかわりに、SQL*Plusを実行するとします。この時点でユーザーが制限を受けるのは、明示的に付与された権限またはロール（vacationロールを含む）を介して付与されている権限からのみです。SQL*Plusは非定型の問合せツールであるため、設計されたデータベース・アプリケーションを使用する場合のように、ユーザーは一連の事前定義アクションに制限されることはありません。ユーザーは、emp_tab表のデータの問合せや変更を自由に実行できます。
SQL*Plus環境で特定のSQLおよびSQL*Plusコマンドをユーザーごとに使用禁止にするには、PRODUCT_USER_PROFILE表を使用します。この表はSYSTEMスキーマにあります。Oracle DatabaseではなくSQL*Plusが、このセキュリティを規定します。GRANT、REVOKEおよびSET ROLEコマンドへのアクセスを制限して、ユーザーによるデータベース権限の変更を制御することもできます。
PRODUCT_USER_PROFILE表を使用すると、ユーザーがアプリケーションでアクティブにできないロールをリストできます。また、様々なコマンド（SET ROLEなど）の使用を明示的に禁止できます。
たとえば、PRODUCT_USER_PROFILE表にエントリを作成して、次の処理を実行できます。
SQL*Plusで、clerkおよびmanagerロールの使用を禁止できます。
SQL*Plusで、SET ROLEの使用を禁止できます。
ユーザーMarlaが、SQL*Plusを使用してデータベースに接続するとします。Marlaには、clerk、managerおよびanalystのロールがあります。前述のPRODUCT_USER_PROFILEのエントリによって、Marlaは、SQL*Plusでanalystロールのみを使用できます。また、MarlaがSET ROLE文を発行しようとすると、PRODUCT_USER_PROFILE表にあるエントリによってSET ROLEの使用が禁止されているため、Marlaによるこの文の発行は明示的に禁止されます。
PRODUCT_USER_PROFILE表は、様々な理由からセキュリティが完全には保証されないことに注意してください。前述の例では、SET ROLEがSQL*Plusで禁止されていますが、Marlaに直接付与されているその他の権限がある場合、Marlaは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スキーマ内の注文表に対するすべての権限を取り消しています。
A スキーマ・オブジェクト権限とは、特定のスキーマ・オブジェクトに対して特定のアクションを実行する権限です。
各タイプのスキーマ・オブジェクトごとに、異なるオブジェクト権限があります。オブジェクト権限の例には、departments表から行を削除する権限があります。
クラスタ、索引、トリガー、データベース・リンクなど、一部のスキーマ・オブジェクトには、対応付けられたオブジェクト権限がありません。これらのオブジェクトの使用は、システム権限によって決定されます。たとえば、クラスタを変更するには、ユーザーはそのクラスタを所有しているか、またはALTER ANY CLUSTERシステム権限が必要です。
次の各項では、このような権限の付与と取消しについて説明します。
次の各項では、特定のスキーマ・オブジェクトに適用されるオブジェクト権限について説明します。
スキーマ・オブジェクト権限は、ユーザーとロールに対して付与したり、取り消すことができます。オブジェクト権限をロールに付与した場合は、その権限を選択的に使用可能にできます。
ユーザーとロールに対するオブジェクト権限の付与と取消しには、次のいずれかを使用できます。
SQL文のGRANTおよびREVOKE
Oracle Enterprise Manager Database Control
ユーザーは、自分のスキーマに含まれているスキーマ・オブジェクトに関しては、すべてのオブジェクト権限が自動的に付与されています。ユーザーは、自分が所有するスキーマ・オブジェクトに対するオブジェクト権限を、他のユーザーやロールに付与できます。GRANT ANY OBJECT PRIVILEGEがあるユーザーは、GRANT文のGRANT OPTION句を使用してもしなくても、他のユーザーに対して指定のオブジェクト権限を付与したり取り消すことができます。この句を指定しない場合、権限受領者はその権限を使用できますが、別のユーザーには付与できません。
スキーマ・オブジェクトとそのシノニムは、権限に関しては等価です。つまり、表、ビュー、順序、プロシージャ、ファンクションまたはパッケージについて付与されるオブジェクト権限は、その基礎となるオブジェクトを名前で参照するかシノニムを使用するかにかかわらず、適用されます。
たとえば、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（データ定義言語）操作レベルでの表のセキュリティが実現します。
次の各項では、表に対する権限と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操作を許可します。
次のどちらかのシステム権限が、明示的に、またはロールを介して付与されている必要があります。
CREATE VIEWシステム権限（自分のスキーマ内にビューを作成するため）
CREATE ANY VIEWシステム権限（別のユーザーのスキーマ内にビューを作成するため）
次のいずれかの権限が明示的に付与されている必要があります。
ビューの基礎となるすべてのベース・オブジェクトに対するSELECT、INSERT、UPDATEまたはDELETEオブジェクト権限
SELECT ANY TABLE、INSERT ANY TABLE、UPDATE ANY TABLEまたはDELETE ANY TABLEシステム権限
さらに、ビューに対するアクセス権を他のユーザーに付与する場合は、ベース・オブジェクトに対するオブジェクト権限がGRANT OPTION句付きで付与されているか、またはADMIN OPTION句によって適切なシステム権限が付与されている必要があります。これらの権限がユーザーにない場合、権限受領者はそのユーザーのビューにアクセスできません。
ビューを使用するために必要な権限は、ビュー自体に対する適切な権限のみです。ビューの基礎となるベース・オブジェクトに対する権限は必要ありません。
ビューの場合は、表に対してさらに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 ANY PROCEDUREシステム権限があるユーザーは、データベース内の任意のプロシージャを実行できます。プロシージャの実行権限は、ロールを介してユーザーに付与できます。
定義者と呼ばれるプロシージャの所有者は、参照オブジェクトに対する必要なオブジェクト権限をすべて所有している必要があります。プロシージャの所有者が別のユーザーにそのプロシージャを使用する権限を付与すると、プロシージャで参照されるオブジェクトに対するオブジェクト権限の所有者が、そのユーザーのプロシージャ実行に適用されます。このような権限は、定義者権限と呼ばれます。
所有者以外のプロシージャのユーザーは、実行者と呼ばれます。実行者権限プロシージャの場合は、参照オブジェクトに対する追加の権限が必要ですが、定義者権限プロシージャの場合は不要です。
定義者権限プロシージャのユーザーに必要なのは、そのプロシージャを実行する権限のみで、そのプロシージャでアクセスする基礎となるオブジェクトに対する権限は不要です。これは、定義者権限プロシージャは、その実行者に関係なく、プロシージャを所有するユーザーのセキュリティ・ドメインの下で動作するためです。プロシージャの所有者は、参照オブジェクトに対する必要なオブジェクト権限をすべて所有している必要があります。定義者権限プロシージャのユーザーに付与する権限は、できるかぎり控えめに付与してください。これによって、データベース・アクセスを厳密に制御できます。
定義者権限プロシージャを使用すると、プライベート・データベース・オブジェクトへのアクセスを制御し、データベースのセキュリティ・レベルを強化できます。定義者権限プロシージャを記述し、ユーザーにEXECUTE権限のみを付与することによって、そのプロシージャを介さない場合には、ユーザーが参照オブジェクトにアクセスできないように規定できます。
実行時には、定義者権限ストアド・プロシージャの所有者の権限が、プロシージャの実行前にチェックされます。参照オブジェクトに対して必要な権限が、定義者権限プロシージャの所有者から取り消されていると、所有者もその他のユーザーも、プロシージャを実行できません。
実行者権限プロシージャは、すべての実行者権限で実行されます。ロールは、定義者権限プロシージャによって実行者権限プロシージャが直接または間接的にコールされないかぎり有効です。実行者権限プロシージャのユーザーには、そのプロシージャが実行者のスキーマ内で解決される外部参照を介してアクセスする、オブジェクトに対する権限が（直接、またはロールを介して）必要です。
実行者には、DML文または動的SQL文に埋め込まれているプログラム参照にアクセスする権限が実行時に必要です。これは、この種のプログラム参照は実質的に実行時に再コンパイルされるためです。
PL/SQLファンクションの直接コールなど、他のすべての外部参照の場合、所有者権限はコンパイル時にチェックされ、実行時にはチェックされません。したがって、実行者権限プロシージャのユーザーには、DML文や動的SQL文の外側にある外部参照に対する権限は不要です。 また、実行者権限プロシージャの開発者による権限の付与が必要なのは、プロシージャ自体に対する権限付与のみで、その実行者権限プロシージャによって直接参照されるすべてのオブジェクトに対する権限付与は必要ありません。
複数のプログラム・ユニットで構成したソフトウェア・バンドルを作成し、一部のプログラム・ユニットには定義者権限を、残りのプログラム・ユニットには実行者権限を付与すると、プログラムのエントリ・ポイントを限定できます（コントロール・ステップイン）。エントリ・ポイント・プロシージャの実行権限があるユーザーは、内部プログラム・ユニットも間接的に実行できますが、内部プログラムを直接コールすることはできません。 問合せ処理を厳密に制御するには、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つのパッケージ内に定義され、宣言されたグローバル変数やカーソルなどを共有できます。トップ・レベルのプロシージャであるhireとfire、および追加のパッケージraise_bonusを宣言することによって、選択的なEXECUTE権限をメイン・パッケージ内のプロシージャに対して付与できます。
GRANT EXECUTE ON hire, fire TO big_bosses; GRANT EXECUTE ON raise_bonus TO little_bosses;
次の各項では、型、メソッドおよびオブジェクトに対する権限の使用について説明します。
表4-4に、名前付きの型（オブジェクト型、VARRAYおよびネストした表）に対するシステム権限のリストを示します。
表4-4 名前付きの型に対するシステム権限
| 権限 | 許可される操作 |
|---|---|
|
|
名前付きの型を自分のスキーマ内に作成できます。 |
|
|
名前付きの型を任意のスキーマ内に作成できます。 |
|
|
任意のスキーマにある名前付きの型を変更できます。 |
|
|
任意のスキーマにある名前付きの型を削除できます。 |
|
|
任意のスキーマにある名前付きの型を使用および参照できます。 |
RESOURCEロールには、CREATE TYPEシステム権限が含まれています。DBAロールには、これらの権限すべてが含まれています。
名前付きの型に適用されるオブジェクト権限は、EXECUTEのみです。名前付きの型に対するEXECUTE権限があるユーザーは、その型を使用して次の操作を実行できます。
表の定義
リレーショナル表への列の定義
名前付きの型の変数またはパラメータの宣言
EXECUTE権限によって、ユーザーは、型コンストラクタも含めて、その型のメソッドを起動できます。これは、ストアドPL/SQLプロシージャに対するEXECUTE権限と同じです。
自分のスキーマに型を作成するには、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 オブジェクト表に対する権限
| 権限 | 許可される操作 |
|---|---|
|
|
オブジェクトとその属性に表からアクセスできます。 |
|
|
表の行を構成するオブジェクトの属性を変更できます。 |
|
|
表に新規オブジェクトを作成できます。 |
|
|
行を削除できます。 |
同様に、列オブジェクトには表に対する権限と列に対する権限が適用されます。インスタンスの取得のみでは、型情報は明らかになりません。ただし、クライアントは、型インスタンスのイメージを解釈する際に名前付きの型の情報にアクセスする必要があります。クライアントが型情報を要求すると、その型に対する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文のREVOKEとDROP TYPEは限定されたセマンティクスで実装されます。つまり、どちらの文でも、名前付きの型が表または型に依存している場合は、エラーが戻されて文は取り消されます。ただし、どちらの文も、FORCE句を使用すると常に正常終了します。依存する表がある場合、その表は無効になります。
この項の内容は、次のとおりです。
ロールは、中間層またはプロキシを介して接続したユーザーにも付与できます。この操作については、「中間層サーバーを使用したプロキシ認証」を参照してください。
システム権限とロールを他のユーザーやロールに付与するには、GRANT SQL文を使用します。次の権限が必要です。
システム権限を付与するには、ユーザーにADMIN OPTION付きのシステム権限またはGRANT ANY PRIVILEGEシステム権限が付与されている必要があります。
ロールを付与するには、ユーザーにADMIN OPTION付きのロールまたはGRANT ANY ROLEシステム権限が付与されている必要があります。
例4-9では、システム権限CREATE SESSIONとaccts_payロールをユーザーjwardに付与しています。
|
注意: オブジェクト権限は、同じ GRANT文でシステム権限やロールと同時に付与することはできません。 |
WITH ADMIN OPTION句を指定して権限またはロールを付与されたユーザーまたはロールは、次のような拡張機能を使用できます。
権限受領者は、データベース内の任意のユーザーまたは他のロールに対して、システム権限またはロールの付与または取消しができます。ただし、自分自身からロールを取り消すことはできません。
権限受領者は、ADMIN OPTION付きのシステム権限やロールを付与できます。
ロールの権限受領者は、そのロールを変更または削除できます。
例4-10 では、new_dbaロールをWITH ADMIN OPTION句付きでユーザーmichaelに付与しています。
ユーザーmichaelは、new_dbaロール内の権限をすべて暗黙的に使用できることに加え、必要に応じてnew_dbaロールを付与、取消しおよび削除できます。このように、ADMIN OPTIONは非常に強力な機能であるため、このオプションを付けてシステム権限やロールを付与する際は、十分に注意してください。通常、これらの権限はセキュリティ管理者向けに用意されており、システム内の他の管理者やユーザーに付与することはほとんどありません。
|
注意: ユーザーがロールを作成すると、そのロールは自動的に ADMIN OPTION付きでその作成ユーザーに付与されます。 |
Oracle Databaseでは、GRANT文を使用して新しいユーザーを作成できます。IDENTIFIED BY句を使用することで、ユーザー名またはパスワードがデータベースに存在しない場合も、指定したユーザー名とパスワードで新しいユーザーが作成されます。
例4-11では、新規ユーザーとしてpsmithを作成し、CREATE SESSIONシステム権限をpsmithに付与しています。
GRANT文を使用すると、ロールとユーザーにオブジェクト権限を付与できます。オブジェクト権限を付与するには、次のいずれかの条件を満たしている必要があります。
指定するオブジェクトを所有している。
GRANT ANY OBJECT PRIVILEGEシステム権限を付与されている。この権限を使用すると、オブジェクト所有者のかわりに権限の付与と取消しを実行できます。
所有者からオブジェクト権限を付与されるときに、WITH GRANT OPTION句が指定されている。
|
注意: 同じ GRANT文で、オブジェクト権限とともにシステム権限とロールを付与することはできません。 |
例4-12では、emp表のすべての列に対するSELECT、INSERTおよびDELETEのオブジェクト権限をユーザーjfeeとtsmithに付与しています。
salaryビューのすべてのオブジェクト権限をユーザーjfeeに付与するには、次の例のようにALLキーワードを使用します。
GRANT ALL ON salary TO jfee;
|
注意: 権限受領者は、最初の権限付与に GRANT OPTIONが含まれていないかぎり、オブジェクトへのアクセス権を再度付与することはできません。したがって、前述の例では、jfeeはGRANT文を使用してオブジェクト権限を他の誰かに付与することができません。 |
GRANT文にWITH GRANT OPTION句を指定すると、権限受領者はオブジェクト権限を他のユーザーやロールに付与できます。スキーマ内にオブジェクトを格納しているユーザーには、関連するすべてのオブジェクト権限がGRANT OPTION付きで自動的に付与されます。この特別な権限によって、権限受領者の権限は次のように拡張されます。
権限受領者は、データベース内の任意のユーザーに対して、GRANT OPTION付きまたはGRANT OPTIONなしでオブジェクト権限を付与できます。また、データベース内の任意のロールに対してもオブジェクト権限を付与できます。
次の2つの条件が成立する場合、権限受領者は表に対するビューを作成し、そのビューの対応する権限をデータベース内の任意のユーザーまたはロールに対して付与できます。
権限受領者が、表に対するGRANT OPTION付きのオブジェクト権限を受領している。
権限受領者に、CREATE VIEWまたはCREATE ANY VIEWシステム権限がある。
GRANT ANY OBJECT PRIVILEGEシステム権限を持つユーザーは、オブジェクト所有者のかわりに、すべてのオブジェクト権限の付与と取消しを実行できます。この権限によって、データベース管理者やアプリケーション管理者は、スキーマに接続せずにスキーマ内のオブジェクトへのアクセス権を付与できます。この権限を持つスキーマ所有者のログイン資格証明はメンテナンスする必要がなく、構成時に必要な接続数が減少します。
このシステム権限はOracle Databaseに用意されているDBAロールに付属しているため、AS SYSDBAで接続するユーザー（ユーザーSYS）に（ADMIN OPTION付きで）付与されます。 他のシステム権限と同様に、GRANT ANY OBJECT PRIVILEGEシステム権限を付与できるのは、ADMIN OPTION権限を持っているユーザーのみです。
オブジェクトに対するアクセス権の権限付与者として記録されるのは、オブジェクトの所有者またはGRANT ANY OBJECT PRIVILEGEシステム権限の行使者のいずれかです。GRANT ANY OBJECT PRIVILEGEを保持する権限付与者にGRANT OPTION付きのオブジェクト権限がない場合は、オブジェクト所有者が権限付与者として表示されます。権限付与者がGRANT OPTION付きのオブジェクト権限を持っている場合は、その権限付与者が付与者として記録されます。
|
注意: GRANT文によって生成された監査レコードには、常に権限付与を実際に実行したユーザーが示されます。 |
たとえば、次の使用例を考えてみます。 ユーザーadamsにGRANT ANY OBJECT PRIVILEGEシステム権限があります。 他の付与権限は所持していないとします。このユーザーが次の文を発行します。
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権限を持っているためです。
表の個々の列に対してINSERT、UPDATEまたはREFERENCES権限を付与できます。
|
注意: 列固有の INSERT権限を付与する前に、NOT NULL制約が定義されている列が表に含まれているかどうかを確認してください。挿入できる列を選んで権限を付与したときにNOT NULL列が抜けていると、ユーザーは表に行を挿入できません。このような状況を回避するには、各NOT NULL列が挿入可能であること、またはNULL以外のデフォルト値があることを確認してください。そうでない場合、権限受領者は表に行を挿入できず、エラーが発生します。 |
次の文は、accounts表のacct_no列に対するINSERT権限をpsmithに付与しています。
GRANT INSERT (acct_no) ON accounts TO psmith;
次の例では、emp表のenameおよびjob列に対するオブジェクト権限が、ユーザーjfeeおよびtsmithに付与されます。
GRANT INSERT(ename, job) ON emp TO jfee, tsmith;
この項の内容は、次のとおりです。
システム権限およびロールを取り消すには、SQL文REVOKEを使用します。 ADMIN OPTION付きでシステム権限またはロールを付与されているユーザーは、他のデータベース・ユーザーまたはロールから権限またはロールを取り消すことができます。取消しを行うユーザーは、権限やロールを最初に付与したユーザーでなくてもかまいません。GRANT ANY ROLEを保持しているユーザーは、任意のロールを取り消すことができます。
次の文は、psmithからCREATE TABLEシステム権限とaccts_recロールを取り消します。
REVOKE CREATE TABLE, accts_rec FROM psmith;
オブジェクト権限を取り消すには、次のどちらかの条件を満たしている必要があります。
以前にユーザーまたはロールにオブジェクト権限を付与している。
オブジェクト所有者のかわりに権限を付与したり取り消すことができるGRANT ANY OBJECT PRIVILEGEシステム権限を所持している。
取り消すことができるのは、権限付与者として直接認可した権限のみで、GRANT OPTIONを付与した他のユーザーによる権限付与を取り消すことはできません。ただし、連鎖的な影響があります。権限付与者のオブジェクト権限を取り消すと、GRANT OPTIONを使用して伝播されたオブジェクト権限も取り消されます。
最初の権限付与者が次の文を発行すると、ユーザーjfeeとpsmithからemp表のSELECT権限とINSERT権限が取り消されます。
REVOKE SELECT, INSERT ON emp FROM jfee, psmith;
次の文は、最初にhuman_resourceロールに付与したdept表に対するすべてのオブジェクト権限を取り消します。
REVOKE ALL ON dept FROM human_resources;
|
注意: オブジェクト権限の GRANT OPTIONを選択的に取り消すことはできません。オブジェクト権限を取り消してから、同じオブジェクト権限をGRANT OPTIONを指定せずに再度付与する必要があります。ユーザーが自分自身からオブジェクト権限を取り消すことはできません。 |
GRANT ANY OBJECT PRIVILEGEシステム権限を使用すると、オブジェクト所有者が権限付与者である指定のオブジェクト権限を取り消すことができます。この操作を実行できるのは、オブジェクト所有者によって、または所有者のかわりにGRANT ANY OBJECT PRIVILEGEシステム権限を持つユーザーによって、オブジェクト権限が付与されている場合です。
オブジェクト権限が、オブジェクト所有者とREVOKE文を実行するユーザー（特定のオブジェクト権限とGRANT ANY OBJECT PRIVILEGEシステム権限の両方を持つユーザー）の両方によって付与されている場合は、REVOKE文を発行したユーザーによって付与されたオブジェクト権限のみが取り消されます。この使用例については、「オブジェクト所有者にかわるオブジェクト権限の付与」の例を使用して説明します。
ここでは、blakeがHR.EMPLOYEESに対するSELECT権限をclarkに付与しているとします。blakeはGRANT ANY OBJECT PRIVILEGEシステム権限のみでなく特定のオブジェクト権限も持っているため、この権限付与はblakeに帰属します。ここでは、ユーザーHRもHR.EMPLOYEESに対するSELECT権限をユーザーclarkに付与しているとします。DBA_TAB_PRIVSビューの問合せでは、HR.EMPLOYEES表について次の権限付与が有効であることが表示されています。
GRANTEE 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によって付与されたオブジェクト権限が削除されます。
表やビューの列を選択してINSERT、UPDATEおよびREFERENCES権限を付与することは可能ですが、同じようなREVOKE文を使用して、列固有の権限を選択的に取り消すことはできません。かわりに、権限付与者は表またはビューの全列に対するオブジェクト権限を取り消してから、残しておく列固有の権限を選択的に再度付与する必要があります。
たとえば、human_resourcesロールには、dept表のdeptno列およびdname列に対するUPDATE権限が付与されているとします。このUPDATE権限をdeptno列のみから取り消すには、次の2つの文を発行します。
REVOKE UPDATE ON dept FROM human_resources; GRANT UPDATE (dname) ON dept TO human_resources;
このREVOKE文によって、ロールhuman_resourcesからdept表の全列に対するUPDATE権限が取り消されます。次にGRANT文によって、dname列のUPDATE権限がhuman_resourcesロールに再度付与されます。
権限のタイプによっては、権限の取消しによって連鎖的な影響が発生する場合があります。次の各項で、これについて説明します。
DDL操作に関連するシステム権限を取り消しても、影響は連鎖しません。この場合、権限を付与したときにADMIN OPTIONを指定したかどうかは関係ありません。たとえば、次のような場合を考えてみます。
セキュリティ管理者が、ADMIN OPTIONを指定して、ユーザーjfeeにCREATE TABLEシステム権限を付与します。
ユーザーjfeeが表を作成します。
ユーザーjfeeが、ユーザーpsmithにCREATE TABLEシステム権限を付与します。
ユーザーtsmithが表を作成します。
セキュリティ管理者が、ユーザーjfeeからCREATE TABLEシステム権限を取り消します。
ユーザーjfeeが作成した表はそのまま残ります。ユーザーtsmithの表とCREATE TABLEシステム権限はそのまま残ります。
連鎖的な影響は、DML操作に関連するシステム権限を取り消したときに発生する場合があります。ユーザーのSELECT ANY TABLE権限を取り消すと、そのユーザーのスキーマ内に存在し、この権限に依存しているすべてのプロシージャは、権限が再度認可されないかぎり、正常に実行できません。
オブジェクト権限を取り消すと、連鎖的な影響が発生する場合があります。次のことに注意してください。
DMLオブジェクト権限を取り消すと、そのDMLオブジェクト権限に依存するオブジェクト定義にまで影響が及ぶ可能性があります。たとえば、testプロシージャの本体に、emp表のデータを問い合せるSQL文が記述されているとします。testプロシージャの所有者からemp表のSELECT権限を取り消すと、それ以降そのプロシージャを正常に実行できなくなります。
表に対するREFERENCES権限をユーザーから取り消すと、そのユーザーが定義した外部キー整合性制約の中で、取り消されたREFERENCES権限を必要とする制約が自動的に削除されます。たとえば、ユーザーjwardにdept表のdeptno列に対するREFERENCES権限が付与されているとします。このユーザーが、emp表のdeptno列に、dept表のdeptno列を参照する外部キーを作成します。dept表のdeptno列に対するREFERENCES権限を取り消すと、同じ操作でemp表のdeptno列に対する外部キー制約も削除されます。
GRANT OPTIONを使用して伝播されたオブジェクト権限付与は、権限付与者のオブジェクト権限が取り消されると取り消されます。たとえば、GRANT OPTION付きのSELECTオブジェクト権限を付与されているuser1が、user2に対してemp表のSELECT権限を付与したとします。その後、user1からSELECT権限を取り消します。このREVOKE文はuser2にも連鎖します。user1とuser2の取り消されたSELECT権限に依存するオブジェクトもすべて、前述のように影響を受ける可能性があります。
ALTERまたはINDEXオブジェクト権限を取り消しても、ALTERおよびINDEX DDLの各オブジェクト権限を必要とするオブジェクト定義には影響を与えません。たとえば、別のユーザーに属する表に索引を作成したユーザーからINDEX権限を取り消しても、その索引はそのまま残ります。
ユーザー・グループPUBLICに対して、権限とロールの付与および取消しを実行できます。PUBLICにはすべてのデータベース・ユーザーがアクセスできるため、PUBLICに対して付与されたすべての権限またはロールには、すべてのデータベース・ユーザーがアクセスできます。
セキュリティ管理者とデータベース・ユーザーは、すべてのデータベース・ユーザーが権限またはロールを必要としている場合のみ、PUBLICに権限またはロールを付与してください。これによって、各データベース・ユーザーには常に、現在のグループ・タスクの正常実行に必要な権限のみが付与されているという一般規則が保証されます。
PUBLICから権限を取り消すと、かなりの規模で影響が連鎖する可能性があります。DML操作に関連する権限（SELECT ANY TABLE、UPDATE 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_ROLESをTRUEに設定します（インスタンスが実行中の場合は再起動が必要）。ユーザーがデータベースとのセッションを作成しようとすると、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インスタンスに接続すると、role3とrole4がデフォルト・ロールになり、role2とrole4がADMIN OPTION付きで付与されます。
オペレーティング・システムによって管理されているロールを使用する場合は、データベース・ロールがオペレーティング・システムのユーザーに付与されることに注意してください。オペレーティング・システム・ユーザーが接続できるデータベース・ユーザーは、認可されたデータベース・ロールを使用できます。このため、OS_ROLES = TRUEを使用している場合は、権限が付与されているオペレーティング・システム・アカウントにデータベース・アカウントを対応付けるために、すべてのOracle DatabaseユーザーをIDENTIFIED EXTERNALLYとして定義することを考慮してください。
OS_ROLESパラメータがTRUEに設定されている場合は、ユーザーに対するロールの付与と取消しがオペレーティング・システムによって完全に管理されます。それまでにGRANT文によってユーザーに付与されたロールは適用されません。ただし、それらのロールはデータ・ディクショナリには残っています。オペレーティング・システム・レベルでのユーザーへのロールの付与のみが適用されます。この場合も、ユーザーは権限をロールとユーザーに付与できます。
|
注意: オペレーティング・システムによって ADMIN OPTION付きでロールが付与された場合、ユーザーはそのロールを他のロールにのみ付与できます。 |
OS_ROLES初期化パラメータがTRUEに設定されている場合、オペレーティング・システムによって付与されたロールは、SET ROLE文を使用して動的に使用可能にできます。ロールがパスワードやオペレーティング・システムによる認可を必要とするように定義されていた場合でも、この文は適用されます。ただし、ユーザーのオペレーティング・システム・アカウントで識別されないロールは、SET ROLE文では指定できません。これは、OS_ROLES = FALSEのときにGRANT文を使用してロールを付与していた場合でも同じです（このようなロールを指定しても無視されます）。
OS_ROLES = TRUEの場合、ユーザーは初期化パラメータMAX_ENABLED_ROLESで指定されている数までロールを使用可能にできます。
オペレーティング・システムでロールを管理する場合、ユーザーは、デフォルトでは共有サーバーを介してデータベースに接続できません。リモート・ユーザーは保護されていない接続を介して別のオペレーティング・システム・ユーザーになりすますおそれがあるため、デフォルトでこのような制限が適用されています。
このようなセキュリティに対する危険性の心配がない場合は、初期化パラメータREMOTE_OS_ROLESをTRUEに設定することで、共有サーバーまたはその他のネットワーク接続でオペレーティング・システムのロール管理を使用できます。この変更は、次回インスタンスを起動して、データベースをマウントするときに有効になります。このパラメータのデフォルト設定はFALSEです。
付与と取消しがいつ有効になるかは、付与または取り消す対象によって異なります。
任意の対象（ユーザー、ロールおよびPUBLIC）に対するシステム権限とオブジェクト権限の付与および取消しは、即時に有効になります。
任意の対象（ユーザー、他のロール、PUBLIC）に対するロールの付与および取消しが有効になるのは、その付与および取消しの実行後、ロールを再度使用可能にするために現行のユーザー・セッションでSET ROLE文を発行したとき、あるいはその付与または取消しを実行した後に新しくユーザー・セッションを作成したときです。
現在使用可能なロールは、SESSION_ROLESデータ・ディクショナリ・ビューを問い合せることによって確認できます。
ユーザーまたはアプリケーションは、ユーザー・セッション中にSET ROLE文を何度でも使用して、現在そのセッションで使用可能になっているロールを変更できます。ユーザーには、SET ROLE文で指定したロールが、事前に付与されている必要があります。同時に使用可能にできるロールの数を指定するには、初期化パラメータMAX_ENABLED_ROLESを設定します。
例4-13では、すでに付与されているロールclerkを使用可能にして、パスワードを指定しています。
passwordを安全なパスワードに置き換えます。パスワードの最低要件については、「パスワードの最低要件」を参照してください。
例4-14は、SET ROLEを使用してすべてのロールを使用禁止にする方法を示しています。
ユーザーがログインすると、そのユーザーに明示的に付与されている権限と、そのユーザーのデフォルト・ロールに含まれる権限が、すべて使用可能になります。
ユーザーのデフォルト・ロールのリストは、ALTER USER SQL文を使用して設定および変更できます。このALTER USER文は、ユーザーがデータベースに接続するときに、ロールのパスワードを指定しなくても使用可能になるロールを指定します。ユーザーには、そのロールがGRANT文で直接付与されている必要があります。ディレクトリ・サービスなどの外部サービスによって管理されているロール（外部ロールやグローバル・ロール）は、デフォルト・ロールとして指定できません。
例4-15では、ユーザーjaneに対してデフォルト・ロールのpayclerkとpettycashを設定しています。
ユーザーのデフォルト・ロールは、CREATE USER文では設定できません。最初にユーザーを作成したときに、ユーザーのデフォルト・ロールはALLに設定されます。これによって、その後ユーザーに付与されるロールはすべてデフォルト・ロールになります。ユーザーのデフォルト・ロールを制限するには、ALTER USER文を使用します。
ユーザーは、初期化パラメータ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_TCP、UTL_SMTP、UTL_MAIL、UTL_HTTP、UTL_INADDRなどのPL/SQLネットワーク・ユーティリティ・パッケージを使用して接続できる外部ネットワーク・ホストが制限されるため、ネットワーク接続のセキュリティが強化されます。この機能を使用しない場合、デフォルトでは、PL/SQLユーティリティ・パッケージは、PUBLICユーザーに付与されるEXECUTE権限付きで作成されるため、データベースへのアクセス権を獲得した侵入者が故意にネットワークを攻撃する可能性があります。
以前のOracle Databaseリリースからアップグレードしているときに、アプリケーションがUTL_TCP、UTL_SMTP、UTL_MAIL、UTL_HTTP、UTL_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パッケージを使用してアクセス制御リストを作成する手順は、次のとおりです。
アクセス制御リストの内容を作成するには、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_TCP、UTL_HTTP、UTL_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つ以上のネットワーク・ホストへのアクセス制御リストの割当てを完了するまでは無効です。
作成したアクセス制御リストは、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_portをnullのままに（または省略）すると、upper_portの設定は、lower_portと同じ設定とみなされます。たとえば、lower_portを80に設定し、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パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
例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に割り当てられているアクセス制御リストが、そのドメインに割り当てられている他のアクセス制御リストに先行して最初に選択されます。追加のアクセス制御リストがサブ・ドメインに割り当てられていた場合、優先順位は次のようになります。
server.us.example.com
*.us.example.com
*.example.com
*.com
*
同様に、IPアドレス192.0.2.4に対する優先順位は、次のようになります。
192.0.2.4
192.0.2.*
192.0.*
192.*
*
ポート範囲の指定があるアクセス制御リストがホスト・コンピュータ、ドメインまたは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_NETWORK_ACLSビューを問い合せて、指定のホスト・コンピュータについてアクセス制御リストがあるかどうかを判断できます。このビューには、ネットワーク接続またはドメインへのアクセスを決定するアクセス制御リストが表示され、各アクセス制御リストについて、ユーザーのアクセス権限が付与されている（GRANTED）か、拒否されている（DENIED）か、あるいは適用外（NULL）かを確認できます。このビューの問合せを実行できるのは、データベース管理者のみです。
ここでは、データベース管理者による、ネットワーク接続とドメイン名解決に関するユーザー権限のチェック方法について例を示します。
データベース管理者によるユーザーの接続権限のチェック
例4-20は、ユーザーprestonによるwww.us.example.comへの接続について、データベース管理者がユーザーの権限をチェックする方法を示しています。CHECK_PRIVILEGE_ACLIDプロシージャのuserパラメータに入力するユーザー名は、大/小文字が区別されることに注意してださい。この例では、PRESTONというユーザー名は正しい入力ですが、Prestonやprestonは誤りとなります。
次のように、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_ACLIDのuserパラメータに入力するユーザー名は、大/小文字が区別されることに注意してください）。
例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への権限が拒否されます。ただし、sebastianとprestonにACCT_MGRロールが付与されている場合は、そのACCT_MGRロールがリストの最初に記載されるため、この2人のユーザーはログインできます。
この2人のユーザーにはacct_mgrロールが付与されていますが、それぞれの固有のジョブでは、www.example.comホストに対するアクセス権は不要です。位置が逆の場合（sebastianとprestonの後にacct_mgrロールが記載されている場合）は、これらのユーザーに対するネットワーク接続権限は拒否されることになります。CREATE_ACL文およびADD_PRIVILEGE文で、ACE要素の物理的な位置に関係なく優先順位を設定するには、position属性を使用します。
たとえば、次の文では、結果のXMLファイルにACE要素が設定される順序は、次のようになります。
最初にsebastianのACE要素が記載されます。
次にprestonのACE要素が記載されます。
最後に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 アクセス制御リストに関する情報を表示するデータ・ディクショナリ・ビュー
| ビュー | 説明 |
|---|---|
|
ネットワーク・ホストに対するアクセス制御リスト割当てが表示されます。このビューの |
|
|
ネットワーク・ホストに現在割り当てられ、すべてのアクセス制御リストに定義されているネットワーク権限が表示されます。このビューの |
|
|
現行ユーザーがネットワーク・ホストにアクセスするためのネットワーク権限のステータスが表示されます。このビューの |
表4-7に、権限とロールの付与に関する情報を入手するために問合せ可能なデータ・ディクショナリ・ビューをリストします。これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
表4-7 権限とロールに関する付与情報が表示されるビュー
| ビュー | 説明 |
|---|---|
|
|
オブジェクト所有者、権限付与者または権限受領者が現行ユーザーまたは |
|
|
オブジェクト所有者または権限付与者が現行ユーザーである列オブジェクトの権限付与がリストされます。 |
|
|
権限受領者が現行ユーザーまたは |
|
|
権限受領者がユーザーまたは |
|
|
現行ユーザーが行ったオブジェクトの権限付与、または現行ユーザーが所有するオブジェクトに対する権限付与がすべてリストされます。 |
|
|
権限受領者がユーザーまたは |
|
|
データベース内の列オブジェクトの権限付与がすべて表示されます。 |
|
|
データベース内のすべてのオブジェクトに対するすべての権限付与がリストされます。 |
|
|
|
|
|
ユーザーとロールに付与されているロールがリストされます。 |
|
|
ユーザーとロールに付与されているシステム権限がリストされます。 |
|
|
このビューには、他のロールに付与されているロールが表示されます。表示される情報は、ユーザーがアクセス可能なロールに関するもののみです。 |
|
|
このビューには、ロールに付与されているシステム権限に関する情報が含まれています。表示される情報は、ユーザーがアクセス可能なロールに関するもののみです。 |
|
|
このビューには、ロールに付与されているオブジェクト権限に関する情報が含まれています。表示される情報は、ユーザーがアクセス可能なロールに関するもののみです。 |
|
|
オブジェクト所有者、権限付与者または権限受領者が現行ユーザーである列オブジェクトの権限付与が表示されます。 |
|
|
権限付与者が現行ユーザーである列オブジェクトの権限付与が表示されます。 |
|
|
権限受領者が現行ユーザーである列オブジェクトの権限付与が表示されます。 |
|
|
現行ユーザーに付与されているロールがリストされます。 |
|
|
権限受領者が現行ユーザーであるすべてのオブジェクトの権限付与がリストされます。 |
|
|
現行ユーザーに付与されているシステム権限がリストされます。 |
|
|
現行ユーザーが所有しているすべてのオブジェクトの権限付与がリストされます。 |
|
|
権限受領者が現行ユーザーであるオブジェクトの権限付与がリストされます。 |
|
|
ユーザーに対して現在使用可能になっている権限がリストされます。 |
|
|
ユーザーに対して現在使用可能になっているロールがリストされます。 |
ここでは、これらのビューの使用例をいくつか示します。各例では、次の文がすでに発行されていることを前提としています。
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;
次の問合せを実行すると、ロールとユーザーに対して付与されているシステム権限がすべて表示されます。
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
次の問合せを実行すると、ユーザーと他のロールに対して付与されているロールがすべて表示されます。
SELECT * FROM DBA_ROLE_PRIVS; GRANTEE GRANTED_ROLE ADM ------------------ ------------------------------------ --- SWILLIAMS SECURITY_ADMIN NO
次の問合せを実行すると、特定のユーザーに対して付与されているオブジェクト権限（列固有の権限を除く）がすべて表示されます。
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
次の問合せを実行すると、発行者が現在使用できるロールがすべてリストされます。
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行のみ表示されます。
DBA_ROLESデータ・ディクショナリ・ビューを使用すると、データベースのすべてのロールと各ロールに対して使用されている認証を表示できます。たとえば、次の問合せを実行すると、データベース内のすべてのロールが表示されます。
SELECT * FROM DBA_ROLES; ROLE PASSWORD ---------------- -------- CONNECT NO RESOURCE NO DBA NO SECURITY_ADMIN YES
ROLE_ROLE_PRIVS、ROLE_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_PRIVS、ROLE_SYS_PRIVSおよびROLE_TAB_PRIVSの各ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
