| Oracle® Databaseセキュリティ・ガイド 11gリリース2 (11.2) B56285-13 |
|
 前 |
 次 |
認可には、主に次の2つのプロセスがあります。
データへのアクセス、処理または変更を特定のユーザーにのみ許可します。
ユーザーによるアクセスまたは操作に様々な制限を適用します。ユーザーに適用(または除外)する制限は、スキーマ、表または行などのオブジェクトや、時間(CPU、接続またはアイドル時間)などのリソースに適用できます。
ユーザー権限とは、特定タイプのSQL文を実行する権利、別のユーザーのオブジェクトにアクセスする権利、PL/SQLパッケージを実行する権利などを指します。権限のタイプは、Oracle Databaseによって定義されています。
ロールは、ユーザー(通常は管理者)が権限や他のロールをグループ化するために作成します。ロールを使用すると、複数の権限またはロールをユーザーに簡単に付与できます。
ここでは、次の一般的なカテゴリについて説明します。
システム権限。この権限の受領者は、データベースで標準的な管理作業を実行できます。権限受領者は信頼できるユーザーのみに制限してください。システム権限の詳細は、「システム権限の管理」を参照してください。
ユーザー・ロール。ロールでは、複数の権限やロールがグループ化されるため、複数のユーザーに対して権限を同時に付与したり、取り消すことができます。ユーザーによるロールの使用を可能にするには、そのユーザーに対してロールを使用可能にしておく必要があります。詳細は、「ユーザー・ロールの管理」を参照してください。
オブジェクト権限。オブジェクトの各タイプには、オブジェクト権限が対応付けられています。異なるタイプのオブジェクト権限を管理する方法は、「オブジェクト権限の管理」を参照してください。
権限をユーザーに付与すると、そのユーザーはそれぞれの業務に必要な作業を実行できます。なお、権限は、必要な作業を実行する上でその権限が必要なユーザーにのみ付与してください。必要でない権限まで付与すると、セキュリティを維持できなくなる可能性があります。たとえば、管理作業を実行しないユーザーには、SYSDBA管理権限またはSYSOPER権限を付与しないでください。
ユーザーは次の2つの方法で権限を受け取ることができます。
権限を明示的にユーザーに付与します。たとえば、employees表にレコードを挿入する権限を、ユーザーpsmithに明示的に付与できます。
権限をロール(名前付きの権限グループ)に付与した上で、そのロールを1人以上のユーザーに付与します。たとえば、employees表からレコードを選択、挿入、更新および削除する権限を、clerkという名前のロールに付与し、このロールをユーザーpsmithやrobertに付与できます。
ロールを使用することで権限の管理が容易になり、改善されるため、通常は権限を個々のユーザーではなくロールに付与してください。
|
関連項目:
|
強力な権限同様、SYSDBAおよびSYSOPER管理権限は信頼できるユーザーにのみ付与してください。ただし、名前に非ASCII文字(HÜBERという名前に含まれるウムラウトなど)を使用しているユーザーには制限があります。こうしたユーザーに管理権限を付与することは可能ですが、Oracle Databaseインスタンスが停止した場合、名前に非ASCII文字を使用しているユーザーには、付与されている権限を使用した認証がサポートされません。データベース・インスタンスが稼働中であれば、この認証はサポートされます。
この項の内容は、次のとおりです。
システム権限とは、特定のアクションを実行する権限、または特定のタイプのスキーマ・オブジェクトに対してアクションを実行する権限のことです。たとえば、表領域を作成する権限や、データベース内の任意の表から行を削除する権限などがシステム権限です。
システム権限には100以上の種類があります。各システム権限によって、ユーザーは特定のデータベース操作、またはあるクラスのデータベース操作を実行できます。システム権限は非常に強力な権限であることに注意してください。システム権限は、必要な場合のみ、データベースのロールと信頼できるユーザーに付与してください。システム権限の完全なリストとその詳細は、『Oracle Database SQL言語リファレンス』を参照してください。ユーザーに付与されているシステム権限を検索するには、DBA_SYS_PRIVSデータ・ディクショナリ・ビューを問い合せてください。
システム権限は非常に強力であるため、データベースは、通常のユーザー(管理者以外)がデータ・ディクショナリに対して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ファイルで変更します。あるいは、サーバー・パラメータ・ファイル(SPFILE)を使用してデータベースを起動した場合は、SYSDBA権限を持つユーザーSYSとしてSQL*PlusにログインしてからALTER SYSTEM文を入力することもできます。
例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スキーマ内のオブジェクト(データ・ディクショナリ・オブジェクト)へのアクセスがSYSDBA権限を使用して接続するユーザーに制限されていることを意味します。SYSユーザーはSYSDBA権限とSYSOPER権限のどちらかでログインする必要があることに注意してください。それ以外の場合、 ORA-28009「SYSでの接続はSYSDBAまたはSYSOPERで行う必要があります」エラーが発生します。O7_DICTIONARY_ACCESSIBILITYをTRUEに設定すると、データベースにユーザーSYSとしてログインできるようになり、SYSDBA権限やSYSOPER権限を指定する必要もありません。
他のスキーマのオブジェクトへのアクセスを提供するシステム権限で、他のユーザーがSYSスキーマ内のオブジェクトにアクセスすることはできません。たとえば、SELECT ANY TABLE権限を持つユーザーは、他のスキーマのビューや表にはアクセスできますが、ディクショナリ・オブジェクト(動的パフォーマンス・ビューの実表、通常のビュー、パッケージおよびシノニム)は選択できません。ただし、これらのユーザーは、明示的なオブジェクト権限を付与することで、SYSスキーマ内のオブジェクトにアクセスできるようになります。
O7_DICTIONARY_ACCESSIBILITY初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。
明示的なオブジェクト権限のあるユーザーまたは管理権限で接続しているユーザー(SYSDBA)は、SYSスキーマ内のオブジェクトにアクセスできます。
表4-1に、SYSスキーマ内のオブジェクトへのアクセスが必要なユーザーに対して付与できるロールをリストします。
表4-1 SYSスキーマ・オブジェクトにアクセスできるロール
| ロール | 説明 |
|---|---|
|
このロールを付与されたユーザーには、データ・ディクショナリ・ビューに対する |
|
|
このロールを付与されたユーザーには、データ・ディクショナリ内にあるパッケージとプロシージャに対する |
|
|
このロールを付与されたユーザーは、システム監査表 |
さらにSELECT ANY DICTIONARYシステム権限を、SYSスキーマで作成された表にアクセスが必要なユーザーに付与できます。このシステム権限により、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権限を持つユーザーが作成したオブジェクトの動作は、そのオブジェクトが作成されたスキーマに限定されません。たとえば、ユーザーJSMITHにはCREATE ANY PROCEDURE権限があり、プロシージャをスキーマJONESに作成すると、そのプロシージャはJONESとして実行されることになります。ただし、JONESはJSMITHによって作成されたプロシージャがJONESとして機能していることに気付かない可能性があります。JONESにDBA権限が付与されている場合は、JSMITHがJONESとしてプロシージャを実行することで、セキュリティ違反が発生する可能性があります。
PUBLICロールは、データベース・ユーザー・アカウントが作成されるときすべてのアカウントに自動的に与えられる特別なロールです。デフォルトでは付与されている権限がありませんが、多数の付与があり、ほとんどがJavaオブジェクトに対する付与です。PUBLICロールは削除できません。また、ユーザー・アカウントは常にこのロールを前提とするため、このロールの手動の付与や取消しは意味がありません。PUBLICロールはすべてのデータベース・ユーザー・アカウントが前提とするため、DBA_ROLESおよびSESSION_ROLESデータ・ディクショナリ・ビューには表示されません。
PUBLICロールに権限を付与できますが、付与した権限はOracleデータベースのすべてのユーザーが利用できるようになることに注意してください。このため、PUBLICロールに権限を付与するとき、特にANY権限やシステム権限のように強力な権限の場合は注意してください。たとえば、JSMITHがCREATE PUBLIC SYNONYMシステム権限を持っている場合、他の誰もが使用するとわかっているインタフェースを再定義し、それから自分で作成したPUBLIC SYNONYMでこのインタフェースを指し示すことができます。ユーザーは正しいインタフェースではなくJSMITHのインタフェースにアクセスし、ユーザーのログイン資格証明が盗まれるなど、不正な行為が実行される可能性があります。
この種の権限は非常に強力であるため、不適切な個人に付与するとセキュリティ上のリスクが発生する可能性があります。ANYまたはPUBLICを使用した権限の付与には注意が必要です。他のすべての権限と同様に、これらの権限をユーザーに付与する場合は、「最低限の権限」を付与する原則に従ってください。
強力なANYシステム権限を1つ以上持つユーザーからデータ・ディクショナリ(SYSスキーマの内容)を保護するには、O7_DICTIONARY_ACCESSIBILITY初期化パラメータをFALSEに設定します。このパラメータは、ALTER SYSTEM文(例4-1「O7_DICTIONARY_ACCESSIBILITYのFALSEへの設定」を参照)を使用するか、またはinitSID.oraファイルを変更することで設定できます。その他のガイドラインは、「データベースのインストールと構成の保護に関するガイドライン」を参照してください。
権限の管理と制御は、ロールを使用すると簡単になります。ロールとは、関連する権限のグループに名前を付けたもので、ユーザーや他のロールに付与します。データベース内では、各ロール名を一意にする必要があり、すべてのユーザー名や他のすべてのロール名とは異なる名称にする必要があります。スキーマ・オブジェクトとは異なり、ロールはいずれのスキーマにも含まれません。したがって、ロールを作成するユーザーを、ロールに影響をおよぼすことなく削除できます。
この項の内容は、次のとおりです。
ロールとは、ユーザーに権限を素早く簡単に付与するために便利なものです。Oracle Databaseで定義されているロールを使用することもできますが、必要な権限のみを含む独自のロールを作成すると、より継続的な制御が可能になります。Oracle Database定義ロールの権限は変更または削除される場合があります。たとえばCONNECTロールの場合、現在持っている権限はCREATE SESSION権限のみです。以前は、CONNECTロールには他に8個の権限がありました。
ロールには、システム権限またはオブジェクト権限を付与できます。
任意のロールを任意のデータベース・ユーザーに付与できます。
ユーザーに付与した各ロールは、任意の時点で使用可能または使用禁止にできます。ユーザーのセキュリティ・ドメインには、そのユーザーに対して現在使用可能になっているすべてのロールの権限が含まれており、ユーザーに対して現在使用禁止になっているロールの権限は除外されています。権限を選択的に使用できるように、Oracle Databaseでは、データベース・アプリケーションとユーザーがロールを使用可能または使用禁止にできます。
1つのロールを別のロールにも付与できます。ただし、ロールをそのロール自体に付与したり、循環的に付与することはできません。たとえば、role2があらかじめロールrole1に付与されている場合、ロールrole1をロールrole2に付与することはできません。
ロールがパスワード認証ロールまたはセキュア・アプリケーション・ロールでない場合は、ユーザーに間接的に付与できます。間接的に付与するロールとは、ユーザーにすでに付与されている別のロールを通じて同じユーザーに付与するロールのことです。たとえば、ユーザーpsmithにrole1ロールを付与するとします。その後、role2ロールとrole3ロールをrole1ロールに付与します。これで、role2とrole3の2つのロールは、role1に含まれることになります。つまり、psmithには、直接付与されたrole1に加え、role2ロールとrole3ロールが間接的に付与されたことになります。psmithに対して、直接付与されたロールrole1を使用可能にすると、間接的に付与されたロールrole2およびrole3も同様に使用可能になります。
必要に応じて、直接付与されたロールをデフォルト・ロールにできます。直接付与されたロールに対してデフォルト・ロール・ステータスを使用可能または使用禁止にするには、ALTER USER文のDEFAULT ROLE句を使用します。DEFAULT ROLE句は、ユーザーに直接付与されたロールのみを示すようにしてください。ユーザーに直接付与されたロールを検索するには、DBA_ROLE_PRIVSデータ・ディクショナリ・ビューを問い合せます。このビューには、ユーザーに間接的に付与されたロールは含まれません。他のロールに付与されたロールを検索するには、ROLE_ROLE_PRIVSビューを問い合せます。
ロールがパスワード認証ロールまたはセキュア・アプリケーション・ロールの場合は、ユーザーに間接的に付与することも、デフォルト・ロールにすることもできません。このタイプのロールは、ユーザーに直接付与する必要があります。通常、パスワード認証ロールまたはセキュア・アプリケーション・ロールを使用可能にするには、SET ROLE文を使用します。
表4-2では、データベース内での権限管理をさらに容易にする、ロールの特性について説明します。
表4-2 ロールの特性とその説明
| 特性 | 説明 |
|---|---|
|
権限管理に要する労力の削減 |
複数のユーザーに対して同一の権限セットを明示的に付与するかわりに、関連するユーザー・グループのための権限をまとめて1つのロールに付与しておき、そのグループの各メンバーにはそのロールを付与するだけですみます。 |
|
動的な権限管理 |
あるグループの権限を変更する必要がある場合、修正が必要なのは、そのロールの権限のみです。グループのロールを付与した全ユーザーのセキュリティ・ドメインには、そのロールに対して加えられる変更が自動的に反映されます。 |
|
権限の選択的な可用性 |
あるユーザーに付与したロールを、選択的に使用可能または使用禁止にできます。この機能によって、どのような状況でもユーザー権限を個々に制御できます。 |
|
アプリケーションによる認識 |
ロールの存在はデータ・ディクショナリに記録されます。したがって、ユーザーが特定のユーザー名でアプリケーションを実行したときに、アプリケーションがディクショナリに問い合せ、自動的に特定のロールを使用可能(または使用禁止)にするようにアプリケーションを設計できます。 |
|
アプリケーション固有のセキュリティ |
ロールの使用はパスワードを使用して保護できます。正しいパスワードを入力するとロールが使用可能になるようなアプリケーションを作成できます。パスワードを知らないユーザーは、ロールを使用可能にできません。 |
データベース管理者は、データベース・アプリケーションのロールを頻繁に作成します。セキュア・アプリケーション・ロールに対して、アプリケーションを実行するために必要なすべての権限を付与する必要があります。それから保護アプリケーション・ロールを他のロールやユーザーに付与できます。1つのアプリケーションは複数の異なるロールを持つことができ、各ロールには異なる権限のセットが付与され、アプリケーション使用中のデータ・アクセスの可否が決定されます。
DBAはパスワード付きのロールを作成することで、そのロールに付与されている権限が無許可で使用されるのを防止できます。通常、アプリケーションは起動時に適切なロールが使用可能になるように設計されます。そのため、アプリケーション・ユーザーは、アプリケーション・ロールのパスワードを知る必要がありません。
データベース・アプリケーションに対する権限の管理(「アプリケーション・ロールの一般的な使用方法」を参照)
ユーザー・グループに対する権限の管理(「ユーザー・ロールの一般的な使用方法」を参照)
図4-1とその後の各項で、ロールの2通りの使用方法について説明します。
アプリケーション・ロールには、特定のデータベース・アプリケーションを実行するために必要な権限をすべて付与します。次に、そのセキュア・アプリケーション・ロールを、他のロールや特定のユーザーに対して付与します。1つのアプリケーションに対して複数の異なるロールを設定し、アプリケーション使用時のデータ・アクセスの量や範囲にあわせて異なる権限セットを各ロールに割り当てることができます。
各ロールと各ユーザーには、それぞれ独自のセキュリティ・ドメインがあります。ロールのセキュリティ・ドメインには、ロール自体に付与されている権限と、そのロールに付与されたロールに対して付与されている権限が含まれます。
ユーザーのセキュリティ・ドメインには、対応するスキーマ内のすべてのスキーマ・オブジェクトに対する権限、ユーザーに付与された権限、そして現在使用可能なユーザーに付与されたロールの権限が含まれます。(ロールをあるユーザーに対して使用可能にすると同時に、他のユーザーに対して使用禁止にできます。)このドメインには、ロールPUBLICに付与された権限とロールも含まれます。PUBLICロールは、データベース内のすべてのユーザーを表します。
PL/SQLブロック内でのロールの使用方法は、そのブロックが無名ブロックであるか、名前付きブロック(ストアド・プロシージャ、ファンクションまたはトリガー)であるか、および定義者権限または実行者権限のどちらで実行されるかによって異なります。
定義者権限で実行される名前付きPL/SQLブロック(ストアド・プロシージャ、ファンクションまたはトリガー)では、すべてのロールは使用禁止になっています。ロールは権限チェックに使用されず、定義者権限プロシージャ内ではロールを設定できません。
SESSION_ROLESビューには、現在使用可能なすべてのロールが表示されます。定義者権限で実行される名前付きPL/SQLブロックでSESSION_ROLESを問い合せると、その問合せは行を戻しません。
|
関連項目: 『Oracle Databaseリファレンス』 |
実行者権限を使用して実行する名前付きPL/SQLブロックと無名PL/SQLブロックは、使用可能なロールを通じて付与された権限に基づいて実行されます。現行ロールは、実行者権限PL/SQLブロック内での権限チェックに使用されます。動的SQLを使用して、セッション内にロールを設定できます。
|
関連項目:
|
ユーザーが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権限
表に対するREFERENCESオブジェクト権限は、ロールを介して付与されている場合、表の外部キー定義には使用できません。
DDL文を発行するために必要なDML操作をユーザーが実行できるようにするすべてのシステム権限とオブジェクト権限は、ロールを通じて受け取った場合には使用できません。CREATE VIEW文が使用されているとき、セキュリティ・ドメインにはロールが含まれません。たとえばユーザーはSELECT ANY TABLEシステム権限を付与されている場合、または表に対するSELECT object権限をロールを通じて付与されている場合、これらの権限のどちらを使用しても他のユーザーに属する表でビューは作成できません。これは、ビューが定義者権限のオブジェクトであり、ビューを作成するとき、自分にロールを通じて付与された権限はいずれも(システム権限もオブジェクト権限も)使用できないためです。権限が直接自分に付与されている場合は、この権限を使用できます。しかし権限が後で取り消されると、ビュー定義は無効になり(エラーとなり)、再度使用する前に再コンパイルする必要があります。
ロールを介して受け取った権限の使用許可と使用制限について、次の例で具体的に説明します。
次のようなユーザーを想定します。
CREATE VIEWシステム権限を持つロールが付与されています。
employees表に対するSELECT object権限を持つロールが直接付与されています。
departments表に対するSELECT object権限が直接付与されています。
前述の権限がこのユーザーに直接的および間接的に付与されているとすると、
このユーザーはemployees表とdepartments表の両方に対してSELECT文を発行できます。
このユーザーには、employees表のCREATE VIEW権限とSELECT権限がロールを介して付与されていますが、employees表のSELECT object権限がロールを介して付与されていたため、employees表のビューは作成できません。
このユーザーにはCREATE VIEW権限がロールを介して付与され、departments表のSELECT権限が直接付与されているため、departments表のビューは作成できます。
環境によっては、オペレーティング・システムを使用してデータベース・セキュリティを管理できます。オペレーティング・システムを使用して、データベース・ロールの付与と取消し、パスワードの認証を管理できます。この機能は、すべてのオペレーティング・システムで利用できるとはかぎりません。
|
関連項目: オペレーティング・システムによるロールの管理方法の詳細は、そのオペレーティング・システム固有のOracle Databaseマニュアルを参照してください。 |
分散データベース環境でロールを使用する場合は、必要なすべてのロールを分散(リモート)セッションのデフォルト・ロールとして設定する必要があります。ローカル・データベース・セッション内からリモート・データベースに接続しているときは、これらのロールを使用可能にすることはできません。たとえば、ユーザーは、リモート・サイトでロールを使用可能にしようとするリモート・プロシージャを実行できません。
|
関連項目: 『Oracle Database Heterogeneous Connectivityユーザーズ・ガイド』 |
Oracle Databaseには、データベース管理を容易にする一連の事前定義ロールが用意されています。表4-3に示すこれらのロールは、データベース作成の一部である標準スクリプトの実行時に、Oracleデータベースに対して自動的に定義されます。他のオプションや製品をインストールすると、他の事前定義のロールが作成される場合があります。
表4-3 Oracle Databaseの事前定義ロール
| 事前定義のロール | 説明 |
|---|---|
|
関連項目: DBMS_PARALLEL_EXECUTE PL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』 |
|
|
アドバンスト・キューイングを管理するための権限を提供します。 |
|
|
使用されていませんが、主にリリース8.0との互換性のために残されています。 |
|
|
システムにログインしたユーザーを定義するために、XDBプロトコルで使用されます。 |
|
|
情報ライフサイクル管理(ILM)、階層ストレージおよび他のアプリケーションを実装する場合に使用されるパッケージへのアクセスを提供します。 関連項目: 『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』 |
|
|
このロールは、Oracle Databaseの以前のリリースとの互換性を考慮して用意されています。このロールに組み込まれている権限は、 注意: このロールに依存せずに、データベース・セキュリティ用に独自のロールを設計することをお薦めします。このロールは、将来のリリースのOracle Databaseでは自動生成されない可能性があります。 関連項目: DBA_SYS_PRIVSビューの詳細は、 |
|
|
Oracle SpatialのCatalog Services for the Web(CSW)コンポーネントを管理するユーザー権限を提供します。 関連項目: 詳細は、『Oracle Spatial開発者ガイド』を参照してください。 |
|
|
Oracle Textの索引および索引プリファレンスの作成権限およびPL/SQLパッケージの使用権限を提供します。このロールはOracle Textユーザーに付与される必要があります。 関連項目: 詳細は、『Oracle Textアプリケーション開発者ガイド』を参照してください。 |
|
|
Oracleデータ・ウェアハウスおよび意思決定支援で使用されるリポジトリ標準であるCommon Warehouse Metadata(CWM)の管理権限を提供します。 関連項目: 詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。 |
|
|
Oracle Data Pumpを使用してOracleデータベースからデータをエクスポートする権限を提供します。 注意: このロールは非常に強力であり、データベース内の任意のスキーマの任意のデータへのユーザー・アクセスを提供します。このロールをユーザーに付与する場合は注意が必要です。 関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
|
|
Oracle Data Pumpを使用してOracleデータベースにデータをインポートする権限を提供します。 注意: このロールは非常に強力であり、データベース内の任意のスキーマの任意のデータへのユーザー・アクセスを提供します。このロールをユーザーに付与する場合は注意が必要です。 関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
|
|
このロールは、Oracle Databaseの以前のリリースとの互換性を考慮して用意されています。このロールに組み込まれている権限は、 注意: このロールに依存せずに、データベース・セキュリティ用に独自のロールを設計することをお薦めします。このロールは、将来のリリースのOracle Databaseでは自動生成されない可能性があります。 関連項目: DBA_SYS_PRIVSビューの詳細は、 |
|
|
DBFS(データベース・ファイルシステム)パッケージおよびオブジェクトへのアクセスを提供します。 関連項目: 『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』 |
|
|
システム監査表( |
|
|
Javaストアド・プロシージャからEJBに接続する権限を提供します。 |
|
|
データ・ディクショナリ内のオブジェクトに対する |
|
|
エクスポート・ユーティリティ(後継はOracle Data Pump)を使用してデータベースの全インポートおよび増分エクスポートを実行するために必要な権限を提供します。含まれる権限は、 このロールは、エクスポート・ユーティリティおよびインポート・ユーティリティを簡単に使用できるように用意されています。 注意: このロールは非常に強力であり、データベース内の任意のスキーマの任意のデータへのユーザー・アクセスを提供します。このロールをユーザーに付与する場合は注意が必要です。 関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
|
|
関連項目: オプティマイザ統計の管理の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。 |
|
|
Oracle Streams AQで使用されるLDAPサーバーへの接続を確立する権限を提供します。 関連項目: 詳細は、『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド』を参照してください。 |
|
|
異機種間サービス(HS)PL/SQLパッケージの使用を希望するユーザーに対して 関連項目: 詳細は、『Oracle Database Heterogeneous Connectivityユーザーズ・ガイド』を参照してください。 |
|
|
異機種間サービス(HS)PL/SQLパッケージの使用権限およびHS関連のデータ・ディクショナリ・ビューの問合せ権限を提供します。 関連項目: 詳細は、『Oracle Database Heterogeneous Connectivityユーザーズ・ガイド』を参照してください。 |
|
|
異機種間サービスのデータ・ディクショナリ・ビューの問合せ権限を提供します。 関連項目: 詳細は、『Oracle Database Heterogeneous Connectivityユーザーズ・ガイド』を参照してください。 |
|
|
インポート・ユーティリティ(後継はOracle Data Pump)を使用してデータベースの全インポートを実行するために必要な権限を提供します。システム権限の詳細リスト(権限を表示するにはビュー このロールは、エクスポート・ユーティリティおよびインポート・ユーティリティを簡単に使用できるように用意されています。 注意: このロールは非常に強力であり、データベース内の任意のスキーマの任意のデータへのユーザー・アクセスを提供します。このロールをユーザーに付与する場合は注意が必要です。 関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
|
|
Oracle Database Javaアプリケーション・デバッガの実行権限を提供します。 関連項目: Oracle Javaアプリケーションのセキュリティ管理の詳細は、『Oracle Database Java開発者ガイド』を参照してください。 |
|
|
このリリースでは非推奨となりました。 |
|
|
Oracle JVMで保護されたパッケージの更新を含む、Java 2を使用するための主要な権限を提供します。 関連項目: Oracle Javaアプリケーションのセキュリティ管理の詳細は、『Oracle Database Java開発者ガイド』を参照してください。 |
|
|
Java 2を使用するための制限された権限を提供します。 関連項目: Oracle Javaアプリケーションのセキュリティ管理の詳細は、『Oracle Database Java開発者ガイド』を参照してください。 |
|
|
Oracle Database Javaアプリケーションのポリシー表を更新する管理権限を提供します。 関連項目: Oracle Javaアプリケーションのセキュリティ管理の詳細は、『Oracle Database Java開発者ガイド』を参照してください。 |
|
|
関連項目: 詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。 |
|
|
データベース・セッションでJMXエージェントを起動およびメンテナンスする権限を提供します。 関連項目: Oracle Javaアプリケーションの管理の詳細は、『Oracle Database Java開発者ガイド』を参照してください。 |
|
|
関連項目: 詳細は、『Oracle Label Security管理者ガイド』を参照してください。 |
|
|
SQL Apply(ロジカル・スタンバイ・データベース)環境を管理する管理権限を提供します。 関連項目: 詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
|
|
|
|
|
関連項目: 詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。 |
|
|
Oracle Enterprise Managerの管理エージェント・コンポーネントで必要とされる、データベースを監視および管理する権限を提供します。 関連項目: 詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。 |
|
|
Oracle OLAPの異なるスキーマでディメンション・オブジェクトを作成する管理権限を提供します。 関連項目: 詳細は、『Oracle OLAPユーザーズ・ガイド』を参照してください。 |
|
|
アプリケーション開発者に対し、Oracle OLAPの独自のスキーマでディメンション・オブジェクトを作成する権限を提供します。 関連項目: 詳細は、『Oracle OLAPユーザーズ・ガイド』を参照してください。 |
|
|
Oracle OLAPのセキュリティの管理権限を提供します。 関連項目: 詳細は、『Oracle OLAPユーザーズ・ガイド』を参照してください。 |
|
|
Oracle Multimedia DICOMの管理権限を提供します。 関連項目: 『Oracle Multimedia DICOM開発者ガイド』 |
|
|
プロジェクト、モジュール、表、ビュー、マップなどの作成のように、Oracle Warehouse Builderの標準クライアント関連タスクを実行する権限を提供します。Warehouse Builderでは、このロールが作業領域のすべての所有者およびユーザーに自動的に付与されます。(つまり、Warehouse Builderを使用する必要があるユーザーにのロールを明示的に付与する必要がないということになります。)セキュリティ上の理由から、 関連項目: 詳細は、『Oracle Warehouse Builderインストレーションおよび管理ガイド』を参照してください。 |
|
|
登録されたOracle Warehouse BuilderユーザーがWarehouse Builderパブリック・ビューを問い合せるための、データベース・レベルの権限( 関連項目: 詳細は、『Oracle Warehouse Builderインストレーションおよび管理ガイド』を参照してください。 |
|
|
Oracle Warehouse Builder作業領域を作成および所有する権限を提供します。作業領域の所有者がこの作業領域にその他のデータベース・ユーザーを登録した場合、Oracle Databaseによりこのロールがこれらのユーザーに付与されます。このロールが付与されたユーザーは、Warehouse Builder Control Centerパブリック・ビューおよびその他のControl Centerユーティリティにもアクセスできます。Oracle Warehouse Builderでは、すべてのWarehouse Builderユーザーにこのロールが付与されます。 関連項目: 詳細は、『Oracle Warehouse Builderインストレーションおよび管理ガイド』を参照してください。 |
|
|
リカバリ・カタログの所有者の権限を提供します。 |
|
|
このロールは、Oracle Databaseの以前のリリースとの互換性を考慮して用意されています。このロールに組み込まれている権限は、 注意: このロールに依存せずに、データベース・セキュリティ用に独自のロールを設計することをお薦めします。このロールは、将来のリリースのOracle Databaseでは自動生成されない可能性があります。 関連項目: DBA_SYS_PRIVSビューの詳細は、 |
|
|
権限受領者が 関連項目: DBMS_SCHEDULERパッケージに関する詳細は、 |
|
|
データ・ディクショナリ内のオブジェクトに対する |
|
|
Enterprise Managerの管理エージェントで使用されます。 |
|
|
Oracle SpatialのCatalog Services for the Web(CSW)コンポーネントを管理する管理権限を提供します。 関連項目: 詳細は、『Oracle Spatial開発者ガイド』を参照してください。 |
|
|
Oracle SpatialのWeb Feature Service(WFS)コンポーネントを管理する管理権限を提供します。 関連項目: 詳細は、『Oracle Spatial開発者ガイド』を参照してください。 |
|
|
Oracle SpatialのWeb Feature Service(WFS)コンポーネントに対するユーザー権限を提供します。 関連項目: 詳細は、『Oracle Spatial開発者ガイド』を参照してください。 |
|
|
Oracle Workspace Managerの管理権限を提供します。これにより、ユーザーは 関連項目: 詳細は、『Oracle Database Workspace Manager開発者ガイド』を参照してください。 |
|
|
権限受領者がXMLスキーマを、その所有者のみが使用したりアクセスするために登録するのではなく、グローバルに登録できるようにします。また権限受領者がOracle XML DB Repositoryにアクセスしているときはアクセス制御リスト(ACL)チェックを回避できるようにもします。 関連項目: XMLスキーマとXML DBリポジトリの詳細は、『Oracle XML DB開発者ガイド』を参照してください。 |
|
|
権限受領者が実行者権限ハンドラを定義して、XMLリポジトリのトリガーのリソース構成を作成または更新できるようにします。デフォルトでは、このロールは 関連項目: Oracle DatabaseのXMLリポジトリのトリガーの詳細は、『Oracle XML DB開発者ガイド』を参照してください。 |
|
|
権限受領者がHTTPSを使用してOracle DatabaseのWebサービスにアクセスできるようにします。ただし、パブリックなデータベース内のオブジェクトに対するユーザー・アクセスは提供されません。パブリック・アクセスを許可するには、ユーザーに 関連項目: Oracle DatabaseのWebサービスの詳細は、『Oracle XML DB開発者ガイド』を参照してください。 |
|
|
権限受領者がHTTPを使用してOracle DatabaseのWebサービスにアクセスできるようにします。ただし、パブリックなデータベース内のオブジェクトに対するユーザー・アクセスは提供されません。パブリック・アクセスを許可するには、ユーザーに 関連項目: Oracle DatabaseのWebサービスの詳細は、『Oracle XML DB開発者ガイド』を参照してください。 |
|
|
権限受領者が、Oracle DatabaseのWebサービスを介してパブリック・オブジェクトにアクセスできるようにします。 関連項目: Oracle DatabaseのWebサービスの詳細は、『Oracle XML DB開発者ガイド』を参照してください。 |
|
注意: 各インストールで独自のロールが作成されて、必要な権限のみが割り当てられます。このようにして、使用中の権限の詳細な制御が維持されます。このプロセスにより、Oracle Databaseで定義されるロールがOracle Databaseで変更や削除されたとき、既存のロール、権限、またはプロシージャを調整する必要もなくなります。 |
ロールはCREATE ROLE文を使用して作成できますが、そのためにはCREATE ROLEシステム権限が必要です。通常、このシステム権限はセキュリティ管理者のみが持っています。
作成した直後のロールには、権限は対応付けられていません。次のステップで、新しいロールに権限または他のロールを付与します。
作成する各ロールには、データベースの既存のユーザー名やロール名とは異なる、一意の名前を指定する必要があります。ロールはどのユーザーのスキーマ内にも格納されません。マルチバイト・キャラクタ・セットを使用するデータベースでは、各ロール名に少なくとも1つのシングルバイト・キャラクタを含めることをお薦めします。ロール名がマルチバイト・キャラクタのみの場合、暗号化されたロール名とパスワードの組合せの安全性は大幅に低くなります。パスワードのガイドラインは、「パスワードの保護に関するガイドライン」のガイドライン1を参照してください。
例4-2では、clerkロールを作成しています。
IDENTIFIED BY句を使用して、パスワードによってロールを認可します。CREATE ROLE文のIDENTIFIED BY句は、このロールを付与された特定ユーザーがロールを使用する前に、どの認可方式で認可される必要があるかを指定します。この句を指定しないか、またはNOT IDENTIFIEDを指定すると、認可がなくてもロールが使用可能になります。ロールには、必要な認可方式として次の方式を指定できます。
パスワードを使用したデータベースによる認可
指定のパッケージを使用したアプリケーションによる認可
オペレーティング・システム、ネットワークまたはその他の外部ソースによる外部認可
エンタープライズ・ディレクトリ・サービスによるグローバル認可
これらの認可については、次の各項で説明します。
パスワードで保護されたロールの作成の代替手段として、セキュア・アプリケーション・ロールの使用をお薦めします。詳細は、「セキュア・アプリケーション・ロールを使用したロール権限の保護」を参照してください。
ロールの認可方式を設定または変更するには、ALTER ROLE文を使用します。 セキュア・アプリケーション・ロールまたはパスワード認証ロールはユーザーに直接付与する必要があることに注意してください。
例4-3は、clerkロールの変更方法を示しています。これによって、ロールを使用可能にするには、ユーザーが外部ソースによって認可されている必要があることが指定されます。
ロールの認可方式を変更するには、ALTER ANY ROLEシステム権限またはADMINオプション付きのロールが付与されている必要があります。
|
関連項目: ロールと権限の管理に使用するSQL文の構文、制限事項および認可情報は、『Oracle Database SQL言語リファレンス』を参照してください。 |
ここでは、ロールの認可方式について説明します。ロールを使用するには、ユーザーに対してロールを使用可能にする必要があります。
この項の内容は、次のとおりです。
データベースによって認可されたロールを、ロール・パスワードを割り当てることで保護できます。パスワードで保護されたロールがユーザーに付与された場合、SET ROLE文でそのロールの正しいパスワードを入力することでロールを使用可または使用禁止にできます。パスワード認証ロールをデフォルト・ロールのリストに追加した場合でも、このパスワード認証ロールをログオン時に認証することはできません。SET ROLE文で必須パスワードを使用して、明示的に使用可能にする必要があります。
例4-4は、SET ROLE文を使用してパスワード認証ロールを設定する方法を示しています。
例4-2「パスワードによって認可されるユーザー・ロールの作成」は、clerkというロールを作成するCREATE ROLE文を示しています。このロールを使用可能にするには、パスワードを入力する必要があります。
|
注意: マルチバイト・キャラクタ・セットを使用するデータベースの場合も、ロールのパスワードにはシングルバイト・キャラクタのみを使用してください。マルチバイト・キャラクタのパスワードは受け入れられません。パスワードのガイドラインは、「パスワードの保護に関するガイドライン」のガイドライン1を参照してください。 |
アプリケーション・ロール(セキュア・アプリケーション・ロール)を使用可能にできるのは、認可されたPL/SQLパッケージを使用するアプリケーションのみです。アプリケーション開発者は、アプリケーション内部にパスワードを埋め込むことによってロールを保護する必要はありません。かわりに、アプリケーション・ロールを作成して、ロールを使用可能にすることを認可するPL/SQLパッケージを指定できます。
認可されたPL/SQLパッケージによって使用可能になるロールを作成するには、CREATE ROLE SQL文でIDENTIFIED USING package_name句を使用します。
例4-5では、ロールadmin_roleがアプリケーション・ロールであり、このロールは、PL/SQLパッケージhr.admin内に定義されているモジュールによってのみ使用可能にできることを示しています。
セキュア・アプリケーション・ロールの詳細は、次の各項を参照してください。
『Oracle Database 2日でセキュリティ・ガイド』
外部ロールは、データベースにローカルに定義できますが、グローバル・ユーザー、グローバル・ロールまたはデータベース内の他のロールには付与できません。オペレーティング・システムまたはネットワーク・クライアントによって認可されるロールを作成できます。
例4-6では、accts_recという名前のロールを作成しています。このロールを使用可能にするには、その前に、ユーザーが外部ソースによって認可されている必要があります。
オペレーティング・システムによるロール認証が有効となるのは、そのオペレーティング・システムによって、オペレーティング・システム権限をアプリケーションと動的にリンクできる場合のみです。ユーザーがアプリケーションを開始すると、オペレーティング・システムはオペレーティング・システム権限をそのユーザーに付与します。付与されたオペレーティング・システム権限は、アプリケーションに対応付けられたロールと一致します。この時点で、アプリケーションはアプリケーション・ロールを使用可能にできます。アプリケーションが終了すると、先に付与されたオペレーティング・システム権限は、そのユーザーのオペレーティング・システム・アカウントから取り消されます。
ロールをオペレーティング・システムによって認可する場合は、オペレーティング・システム・レベルで各ユーザーの情報を構成する必要があります。この操作は、オペレーティング・システムによって異なります。
ロールがオペレーティング・システムによって付与されている場合は、そのオペレーティング・システムによるロールの認可は不要です。
ユーザーがデータベースにOracle Net経由で接続する場合、オペレーティング・システムはデフォルトではユーザーのロールを認証できません。この接続ではOracle Netが必要となるため、共有サーバー構成を介した接続が含まれます。リモート・ユーザーはネットワーク接続を介して別のオペレーティング・システム・ユーザーになりすますおそれがあるため、デフォルトでこのような制限が適用されています。REMOTE_OS_ROLESをFALSE(デフォルト)に設定することをお薦めします。
このようなセキュリティの危険性の心配がないときに、ネットワーク・クライアントに対してオペレーティング・システムのロール認証を使用する場合は、データベース初期化パラメータ・ファイル内の初期化パラメータREMOTE_OS_ROLESをTRUEに設定します。この変更は、次回インスタンスを起動して、データベースをマウントするときに有効となります。
ロールはグローバル・ロールとして定義できます。この場合、そのロールを使用するために(グローバル)ユーザーはエンタープライズ・ディレクトリ・サービスによる認可を受ける必要があります。グローバル・ロールは、権限とロールを付与することによってデータベース内でローカルに定義しますが、グローバル・ロール自体をそのデータベース内のユーザーや他のロールに付与することはできません。グローバル・ユーザーがデータベースへの接続を試みると、エンタープライズ・ディレクトリへの問合せが実行され、そのユーザーに対応付けられたグローバル・ロールが取得されます。
例4-7では、グローバル・ロールを作成しています。
グローバル・ロールは、エンタープライズ・ユーザー・セキュリティの構成要素の1つです。グローバル・ロールは1つのデータベースにのみ適用されますが、エンタープライズ・ディレクトリに定義されたエンタープライズ・ロールに付与できます。エンタープライズ・ロールは複数データベースのグローバル・ロールを含んだディレクトリ構造であり、エンタープライズ・ユーザーに付与できます。
ユーザーのグローバル認証とグローバル認可、およびエンタープライズ・ユーザー管理におけるロールの概要については、「グローバルなユーザー認証と認可の構成」を参照してください。
|
関連項目: エンタープライズ・ユーザー管理の実装の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。 |
この項の内容は、次のとおりです。
|
関連項目:
|
システム権限やオブジェクト権限をロールに付与できます。そしていずれのロールも任意のデータベース・ユーザーや他のロールに付与できます(ただしそのロール自体に付与することはできません)。ただし、ロールを循環的に付与することはできません。つまり、ロールYがすでにロールXに付与されている場合は、ロールXをロールYに付与することはできません。
権限を選択的に使用できるように、Oracle Databaseでは、データベース・アプリケーションとユーザーがロールを使用可能または使用禁止にできます。ユーザーに付与した各ロールは、任意の時点で使用可能または使用禁止にできます。ユーザーのセキュリティ・ドメインには、そのユーザーに対して現在使用可能になっているすべてのロールの権限が含まれており、ユーザーに対して現在使用禁止になっているロールの権限は除外されています。
ロールに対して付与されたロールは、間接的に付与されたロールと呼ばれます。この種のロールは、ユーザーに対して明示的に使用可能または使用禁止にできます。ただし、別のロールを含んだロールを使用可能にすると、直接的に付与されたロールに含まれる間接的に付与されたロールは、すべて暗黙のうちに使用可能になります。
ユーザーや別のロールに対してロールを付与したり、取り消すには、次のいずれかの方法を使用します。
ロールに対して権限を付与または取り消す場合にも同じオプションを使用します。
セキュアなロール(つまりIDENTIFIED BYロール、IDENTIFIED USINGロールまたはIDENTIFIED EXTERNALLYロール)を非セキュアなロールに付与することはできません。SET ROLE文を使用して、セッションに対してセキュアなロールを有効化できます。
GRANT ANY ROLEシステム権限を持っているユーザーであれば、グローバル・ロールを除くあらゆるロールを、データベースの他のユーザーやロールに付与または取り消すことができます。(グローバル・ロールはOracle Internet Directoryなどのディレクトリ内で管理されますが、その権限は単一のデータベース内に含まれます。)デフォルトでは、SYSまたはSYSTEMユーザーがこの権限を持っています。このシステム権限は非常に強力であるため、付与する場合は控えめに設定する必要があります。
ADMIN OPTION付きでロールを付与されたユーザーは、データベースの他のユーザーやロールに対してロールを付与したり、そのロールを取り消すことができます。つまり、このオプションによって、選択的なロール付与の管理が可能になります。
|
関連項目: グローバル・ロールの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。 |
状況によっては、データベースからロールを削除した方がよい場合があります。削除したロールを付与されていたすべてのユーザーとロールのセキュリティ・ドメインは、削除したロール権限がなくなったことを反映するために、ただちに変更されます。削除したロールによって間接的に付与されていたロールもすべて、関連するセキュリティ・ドメインから削除されます。ロールを削除することによって、すべてのユーザーのデフォルト・ロール・リストからそのロールが自動的に削除されます。
オブジェクトの存在はロールを介して受け取った権限に依存しないため、ロールが削除されても、表や他のオブジェクトは削除されません。
ロールは、SQL文DROP ROLEを使用して削除します。ロールを削除するには、DROP ANY ROLEシステム権限またはADMINオプション付きのロールが付与されている必要があります。
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表のデータの問合せや変更を自由に実行できます。
PRODUCT_USER_PROFILE表(これはSYSTEMスキーマです)を使用して、特定のSQLおよびSQL*Plusコマンドを各ユーザーのSQL*Plus環境で使用禁止にできます。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ロールのみを使用できます。また、GinnyがSET ROLE文を発行しようとすると、SET ROLEの使用を禁止するPRODUCT_USER_PROFILE表のエントリが原因で、発行を明示的に禁止されます。
PRODUCT_USER_PROFILE表は、様々な理由からセキュリティが完全には保証されないことに注意してください。前述の例では、SET ROLEがSQL*Plusで禁止されていますが、Marlaに直接付与されているその他の権限がある場合、MarlaはSQL*Plusを使用してそれらの権限を使用できます。
|
関連項目: PRODUCT_USER_PROFILE表の詳細は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください。 |
ストアド・プロシージャは、ビジネス・ロジックによって権限の使用をカプセル化し、適正なビジネス・トランザクションのコンテキストでのみ権限が実行されるようにします。たとえば、アプリケーション開発者は、employees表にある従業員の名前および住所を、通常の勤務時間内にのみ更新するプロシージャを作成できます。また、セキュリティ管理者は、人事部門の担当者にemployees表のUPDATE権限を付与するのではなく、プロシージャのみに権限を付与できます。これによって、人事部門の担当者が権限を使用できるのはプロシージャのコンテキスト内のみになり、employees表を直接更新できなくなります。
セキュア・アプリケーション・ロールは、認可されたPL/SQLパッケージ(またはプロシージャ)でのみ使用可能にできるロールです。PL/SQLパッケージ自体には、アプリケーションへのアクセスを制御するために必要なセキュリティ・ポリシーが反映されます。
この方法でロールを作成すると、起動対象アプリケーションに対してこのタイプのロールを使用可能にする場合に制限が加えられます。たとえば、アプリケーションはユーザーがプロキシを介して接続しているかどうかをチェックするなど、認証およびカスタマイズ認可を実行できます。
このタイプのロールでは、パスワードがアプリケーションのソース・コードに埋め込まれたり、表に格納されることがないため、セキュリティが強化されます。このように、データベースが実行する処理は、セキュリティ・ポリシーの実装に基づいており、その定義は1箇所(アプリケーション内ではなくデータベース内)に格納されます。ポリシーの変更が必要な場合は、アプリケーションを修正することなく1箇所の変更で済みます。ポリシーはロールと結び付けられているため、ユーザーがデータベースに接続する方法に関係なく、結果は常に同じです。
セキュア・アプリケーション・ロールを使用可能にするには、ユーザーがセキュア・アプリケーション・ロールによって付与された権限を行使する前のログイン時に、基礎となるパッケージをアプリケーションから直接起動して実行する必要があります。ログイン・トリガーを使用してセキュア・アプリケーション・ロールを使用可能にすることも、このタイプのロールをデフォルト・ロールにすることもできません。
セキュア・アプリケーション・ロールを使用可能にすると、認可されたPL/SQLパッケージがコール・スタックにあることが検証されます。つまり、認可されたPL/SQLパッケージがロールを使用可能にするコマンドを発行しているかどうかが検証されます。
セキュア・アプリケーション・ロールは、データベース接続の存在を保証するために使用できます。セキュア・アプリケーション・ロールはパッケージによって実装されるロールであるため、このパッケージによって、ユーザーが中間層を介して、または特定のIPアドレスからデータベースに接続できることを検証できます。この方法により、セキュア・アプリケーション・ロールは、ユーザーがアプリケーション外のデータにアクセスすることを防ぎます。ユーザーは、付与されているアプリケーション権限のフレームワーク内で作業するように規定されます。
この項の内容は、次のとおりです。
オブジェクト権限は、データベース・オブジェクトに対してユーザーに認める権利です。たとえば、次のことをする権利がオブジェクト権限です。
エディションの使用
表の更新
他のユーザーの表からの行の選択
他のユーザーのストアド・プロシージャの実行
|
関連項目: オブジェクト権限とそれぞれで許可されている操作のリストは、『Oracle Database SQL言語リファレンス』を参照してください。 |
オブジェクトの各タイプには、異なるオブジェクト権限が対応付けられています。
ALL [PRIVILEGES]を指定して、オブジェクトに対するすべての使用可能なオブジェクト権限の付与または取消しが可能です。ALLは権限ではなくショートカットのようなもので、つまり1つのGRANT文またはREVOKE文ですべてのオブジェクト権限を付与または取消しするための方法です。すべてのオブジェクト権限がALLショートカットを使用して付与された場合でも、権限を個別に取り消すことができます。
同様に、個別に付与した権限をALLを指定してすべて取り消すこともできます。ただし、REVOKE ALLによって整合性制約が削除される場合(整合性制約は取り消そうとしているREFERENCES権限に依存しているため)は、REVOKE文にCASCADE CONSTRAINTSオプションを指定する必要があります。
例4-8では、CASCADE CONSTRAINTSを使用してHRスキーマ内の注文表に対するすべての権限を取り消しています。
オブジェクト権限では、特定のスキーマ・オブジェクトに対して特定のアクションを実行する権限を付与します。
各タイプのスキーマ・オブジェクトごとに、異なるオブジェクト権限があります。オブジェクト権限の例には、departments表から行を削除する権限があります。
クラスタ、索引、トリガー、データベース・リンクなど、一部のスキーマ・オブジェクトには、対応付けられたオブジェクト権限がありません。これらのオブジェクトの使用は、システム権限によって決定されます。たとえば、クラスタを変更するには、ユーザーはそのクラスタを所有しているか、またはALTER ANY CLUSTERシステム権限が必要です。
次の各項では、このような権限の付与と取消しについて説明します。
次の各項では、特定のスキーマ・オブジェクトに適用されるオブジェクト権限について説明します。
順序(『Oracle Database管理者ガイド』の順序の管理に関する項を参照)
ファンクションとパッケージ(『Oracle Database管理者ガイド』のオブジェクト依存性の管理に関する項を参照)
オブジェクト権限は、ユーザーとロールに対して付与したり、取り消すことができます。オブジェクト権限をロールに付与した場合は、その権限を選択的に使用可能にできます。
ユーザーとロールに対するオブジェクト権限の付与と取消しには、次のいずれかの方法を使用できます。
SQL文のGRANTおよびREVOKE
Oracle Enterprise Manager Database Control
|
関連項目: Database Controlの詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。 |
ユーザーは、自分のスキーマに含まれているスキーマ・オブジェクトに関しては、すべてのオブジェクト権限が自動的に付与されています。GRANT ANY OBJECT PRIVILEGEを持つユーザーは、GRANT文のWITH GRANT OPTION句を使用してもしなくても、指定したオブジェクト権限を別のユーザーに付与できます。また、GRANT ANY OBJECT PRIVILEGEを持つユーザーは、その権限を使用して、オブジェクト所有者またはGRANT ANY OBJECT PRIVILEGE権限を持つ他のユーザーによって付与されたオブジェクト権限を取り消すことができます。この句を指定しない場合、権限受領者はその権限を使用できますが、別のユーザーには付与できません。
|
関連項目: GRANTおよびGRANT ANY OBJECT PRIVILEGEの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 |
CREATE SYNONYM文を使用して、表、ビュー、順序、演算子、プロシージャ、ストアド・ファンクション、パッケージ、マテリアライズド・ビュー、Javaクラス・スキーマ・オブジェクト、ユーザー定義オブジェクト・タイプのシノニム、または他のシノニムを作成できます。ユーザーにシノニムを使用する権限を付与すると、基礎オブジェクトで付与されたオブジェクト権限は、ユーザーがベース・オブジェクトを名前で参照するかシノニムを使用して参照するかに関係なく適用されます。
たとえば、ユーザーOEが次のシノニムをCUSTOMERS表に作成するとします。
CREATE SYNONYM customer_syn FOR CUSTOMERS;
それから、OEはcustomer_synシノニムに対するSELECT権限をユーザーHRに付与します。
GRANT SELECT ON customer_syn TO HR;
ユーザーHRは、次のどちらかの問合せを試みます。
SELECT COUNT(*) FROM OE.customer_syn; SELECT COUNT(*) FROM OE.CUSTOMERS;
どちらの問合せも同じ結果になります。
COUNT(*)
----------
319
シノニムを他のユーザーに権限付与すると、権限付与はシノニム自体に適用されるのでなく、シノニムが表す基礎オブジェクトに適用されることに注意してください。たとえば、ユーザーHRが自分の権限についてALL_TAB_PRIVSデータ・ディクショナリ・ビューを問い合せると、次のことを知ります。
SELECT TABLE_SCHEMA, TABLE_NAME, PRIVILEGE
FROM ALL_TAB_PRIVS
WHERE TABLE_SCHEMA = 'OE';
TABLE_SCHEMA TABLE_NAME PRIVILEGE
------------ ---------- ----------
OE CUSTOMER SELECT
OE ORDERS UPDATE
結果にはこのユーザーが、他の権限に加えて、customer_synシノニムの基礎オブジェクト、つまりOE.CUSTOMER表に対するSELECT権限を持っていることが示されます。
この時点でユーザーOEがcustomer_synシノニムに対するSELECT権限をHRから取り消した場合に、HRが自分の権限を再度調べたときの結果を次に示します。
TABLE_SCHEMA TABLE_NAME PRIVILEGE ------------ ---------- --------- OE ORDERS UPDATE
ユーザーHRは、OE.CUSTOMER表に対するSELECT権限を失っています。このユーザーがOE.CUSTOMERS表を問い合せると、次のエラーが表示されます。
SELECT COUNT(*) FROM OE.CUSTOMERS; ERROR at line 1: ORA-00942: table or view does not exist
表に対するオブジェクト権限によって、DML(データ操作言語)またはDDL(データ定義言語)操作レベルでの表のセキュリティが実現します。
次の各項では、表に対する権限とDMLおよびDDL操作について説明します。
表またはビューでDELETE、INSERT、SELECTおよびUPDATEの各DML操作を使用する権限を付与できます。これらの権限は、表のデータの問合せや操作が必要なユーザーとロールに対してのみ付与してください。
表に対するINSERT権限とUPDATE権限は、表の特定の列に制限できます。選択的なINSERT権限を付与されたユーザーは、選択した列に値を持つ行を挿入できます。他のすべての列には、NULLまたはその列のデフォルト値が挿入されます。選択的なUPDATE権限によって、ユーザーは行の特定の列に限ってその値を更新できます。機密データに対するユーザー・アクセスを制限するには、INSERT権限とUPDATE権限を選択的に使用します。
たとえば、データ入力ユーザーにemployees表のsalary列を変更させないようにするには、そのsalary列を除外した選択的なINSERT権限またはUPDATE権限を付与できます。また、salary列を除外したビューによって、同じ制限をさらに高いセキュリティ・レベルで実現できます。
|
関連項目: DML操作の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 |
ALTER、INDEXおよびREFERENCESの各権限は、表に対するDDL操作の実行を許可します。これらの権限によって、他のユーザーは表への依存性を変更または作成できるため、権限の付与は控えめに行う必要があります。
表に対してDDL操作を実行するユーザーには、さらに他のシステム権限やオブジェクト権限が必要な場合があります。たとえば、表にトリガーを作成するには、その表に対するALTER TABLEオブジェクト権限とCREATE TRIGGERシステム権限の両方が必要です。
INSERT権限やUPDATE権限と同様に、REFERENCES権限は、表の特定の列を対象として付与できます。REFERENCES権限を付与されたユーザーは、付与の対象となった表を、自分の表の中に作成する外部キーの親キーとして使用できます。外部キーの存在によって、親キーに対して実行できるデータ操作と表の変更が制限されるため、このアクションは特殊な権限によって制御されます。列固有のREFERENCES権限によって、権限受領者が使用できるのは、指定された列(この列には、当然、親表の主キーまたは一意キーが最低1つ含まれている)に制限されます。
|
関連項目: 主キー、一意キーおよび整合性制約の詳細は、『Oracle Database概要』のデータ整合性に関する項を参照してください。 |
この項の内容は、次のとおりです。
ビューとは、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句付きの適切なシステム権限を持っている必要があります。これらの権限を持っていない場合は、自分のビューに対するアクセス権を他のユーザーに付与できません。付与しようとすると、 ORA-01720「object_nameに対するGRANTオプションは存在しません。」エラーが発生します。object_nameはビューの基礎となるオブジェクトを参照しており、ユーザーにはこのオブジェクトに対する十分な権限がありません。
|
関連項目: 『Oracle Database SQL言語リファレンス』 |
ユーザーがビューを使用するには、ビュー自体に対する適切な権限のみが必要であり、ビューの基礎となるオブジェクトに対する権限は不要です。ただし、ビューの基礎となるオブジェクトに対するアクセス権限が削除されると、ユーザーはアクセスできなくなります。このように動作するのは、ユーザーがビューを問い合せるときに使用されるセキュリティ・ドメインが、そのビューの定義者のセキュリティ・ドメインであるためです。基礎となるオブジェクトに対する権限がビューの定義者によって取り消されると、そのビューは無効になり、いかなるユーザーも使用できなくなります。したがって、ビューに対するアクセス権が付与されているユーザーでも、ビューの基礎となるオブジェクトに対する定義者権限が取り消された場合は、そのビューを使用できません。
たとえば、ユーザーAがビューを作成するとします。ユーザーAは、ビューの基礎となるオブジェクトに対する定義者権限を持っています。この場合、ユーザーAがそのビューに対するSELECT権限をユーザーBに付与すると、ユーザーBがそのビューの問合せを実行できるようになります。ただし、ユーザーAがそのビューの基礎となるオブジェクトにアクセスできなくなった場合は、ユーザーBも同様にアクセスできなくなります。
ビューの場合は、次のように、表に対してさらに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オブジェクト権限があるユーザーは、そのプロシージャを実行したり、それを参照するプログラム・ユニットをコンパイルできます。PL/SQLユニットのコール時には、Oracle Databaseによって実行時権限チェックが実行されます。EXECUTE ANY PROCEDUREシステム権限があるユーザーは、データベース内の任意のプロシージャを実行できます。プロシージャの実行権限は、ロールを介してユーザーに付与できます。
|
関連項目: Oracle Databaseの実行時権限チェックの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。 |
定義者と呼ばれるプロシージャの所有者は、参照オブジェクトに対する必要なオブジェクト権限をすべて所有している必要があります。プロシージャ所有者が別のユーザーにそのプロシージャを使用する権限を付与すると、(プロシージャで参照されるオブジェクトに対する)プロシージャ所有者の権限が、権限受領者ユーザーのプロシージャ実行に適用されます。プロシージャの定義者の権限は、ロールを介してではなく、ユーザーに直接付与する必要があります。このような権限は、定義者権限と呼ばれます。
所有者以外のプロシージャのユーザーは、実行者と呼ばれます。実行者権限プロシージャの場合は、参照オブジェクトに対する追加の権限が必要ですが、定義者権限プロシージャの場合は不要です。
定義者権限プロシージャのユーザーに必要なのは、そのプロシージャを実行する権限のみで、そのプロシージャでアクセスする基礎となるオブジェクトに対する権限は不要です。これは、定義者権限プロシージャは、その実行者に関係なく、プロシージャを所有するユーザーのセキュリティ・ドメインの下で動作するためです。プロシージャの所有者は、参照オブジェクトに対する必要なオブジェクト権限をすべて所有している必要があります。定義者権限プロシージャのユーザーに付与する権限は、できるかぎり控えめに付与してください。これによって、データベース・アクセスを厳密に制御できます。
定義者権限プロシージャを使用すると、プライベート・データベース・オブジェクトへのアクセスを制御し、データベースのセキュリティ・レベルを強化できます。定義者権限プロシージャを記述し、ユーザーにEXECUTE権限のみを付与することによって、そのプロシージャを介さない場合には、ユーザーが参照オブジェクトにアクセスできないように規定できます。
実行時には、定義者権限ストアド・プロシージャの所有者の権限によってそのプロシージャの参照オブジェクトへのアクセスが許可されているかどうかが、プロシージャの実行前にチェックされます。参照オブジェクトに対して必要な権限が、定義者権限プロシージャの所有者から取り消されていると、所有者もその他のユーザーも、プロシージャを実行できません。
実行者権限プロシージャは、すべての実行者権限で実行されます。実行者の使用可能な任意のロールを介してその実行者に付与された権限は、定義者権限プロシージャによって実行者権限プロシージャが直接または間接的にコールされないかぎり有効です。実行者権限プロシージャのユーザーには、そのプロシージャが実行者のスキーマ内で解決される外部参照を介してアクセスする、オブジェクトに対する権限(直接またはロールを介して付与されたもの)が必要です。
実行者には、DML文または動的SQL文に埋め込まれているプログラム参照にアクセスする権限が実行時に必要です。これは、この種のプログラム参照は実質的に実行時に再コンパイルされるためです。
PL/SQLファンクションの直接コールなど、他のすべての外部参照の場合、所有者権限はコンパイル時にチェックされ、実行時にはチェックされません。したがって、実行者権限プロシージャのユーザーには、DML文や動的SQL文の外側にある外部参照に対する権限は不要です。また、実行者権限プロシージャの開発者による権限の付与が必要なのは、プロシージャ自体に対する権限付与のみで、その実行者権限プロシージャによって直接参照されるすべてのオブジェクトに対する権限付与は必要ありません。
複数のプログラム・ユニットからなり、そのうちのいくつかは定義者権限、その他は実行者権限とするソフトウェア・バンドルを作成して、プログラム・エントリ・ポイントを制限できます(制御されたステップイン)。エントリ・ポイント・プロシージャの実行権限があるユーザーは、内部プログラム・ユニットも間接的に実行できますが、内部プログラムを直接コールすることはできません。問合せ処理を厳密に制御するには、PL/SQLパッケージ仕様を明示的なカーソルを使用して作成できます。
|
関連項目:
|
自分のスキーマ内でプロシージャを作成または置換するには、CREATE PROCEDUREシステム権限が必要です。別のユーザーのスキーマ内でプロシージャを作成または置換するには、CREATE ANY PROCEDUREシステム権限が必要です。
プロシージャを所有するユーザーには、プロシージャ本体で参照されるスキーマ・オブジェクトに対する権限も必要です。プロシージャを作成するには、そのプロシージャによって参照されるすべてのオブジェクトに対する必要な権限(システム権限やオブジェクト権限)が明示的に付与されている必要があります。これらの必要な権限は、ロールを介して取得することはできません。これには、作成中のプロシージャ内でコールするプロシージャに対するEXECUTE権限も含まれます。
|
注意: トリガーの場合、参照オブジェクトに対する権限をトリガーの所有者に直接付与する必要があります。権限が明示的に、またはロールを介して付与されていても、無名PL/SQLブロックでは任意の権限を使用できます。 |
スタンドアロン・プロシージャをコンパイルするには、COMPILE句を使用してALTER PROCEDURE文を実行します。パッケージの一部であるプロシージャをコンパイルするには、ALTER PACKAGE文を実行します。
例4-9に、スタンドアロン・プロシージャをコンパイルする方法を示します。
スタンドアロン・プロシージャまたはパッケージ・プロシージャが別のユーザーのスキーマ内にある場合、プロシージャを再コンパイルするにはALTER ANY PROCEDURE権限が必要です。自分のスキーマ内にあるプロシージャは、権限なしで再コンパイルできます。
パッケージに対するEXECUTEオブジェクト権限を保持するユーザーは、そのパッケージ内の任意のパブリック・プロシージャまたはファンクションを実行し、任意のパブリック・パッケージ変数の値へのアクセスや変更を実行できます。パッケージの各構成メンバーに、特定のEXECUTE権限を付与することはできません。したがって、データベース・アプリケーションのプロシージャ、ファンクションおよびパッケージを開発する場合は、セキュリティの確立に関して2つの選択肢を考慮してください。これらの選択肢について、次の例で説明します。
プロシージャに対する権限およびパッケージとパッケージ・オブジェクト: 例1
例4-10では、2つのパッケージの本体に4つのプロシージャを作成しています。
例4-10 プロシージャに対する権限の影響を受けるパッケージ・オブジェクト
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システム権限が必要になります。これらの権限は、明示的にまたはロールを介して取得できます。
型の所有者には、その型の定義内で参照されている他のすべての型にアクセスするための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ロールの使用を中断する必要があります。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権限がチェックされます。
クライアントの第三世代言語アプリケーションのオブジェクトの属性を変更すると、Oracle Databaseでオブジェクト全体の更新が行われます。そのため、ユーザーにはオブジェクト表に対するUPDATE権限が必要になります。オブジェクト表の特定列に対してのみUPDATE権限を持つことは、アプリケーションがこれらの列に対応した属性のみ変更する場合でも、十分とはいえません。そのため、Oracle Databaseではオブジェクト表の列レベルの権限をサポートしていません。
プロシージャや表などのストアド・オブジェクトと同様に、他のオブジェクトから参照される型を依存性があると呼びます。表が依存する型については、特殊な問題点がいくつかあります。表には、アクセス用の型定義に依存するデータが含まれているため、その型を変更すると、格納されているすべてのデータにアクセスできなくなります。変更によってこのような結果になるのは、型を使用するために必要な権限が取り消された場合や、型または依存型が削除された場合です。いずれかのアクションが発生すると、表は無効になり、アクセスできなくなります。
必要な権限が再び付与されると、権限がないために無効になった表は自動的に有効になり、アクセスできるようになります。依存型が削除されたことで無効になった表は、アクセス不能のままで、実行できるアクションは表の削除のみです。
型に対する権限の取消しや型の削除は重大な影響があるため、デフォルトでは、SQL文のREVOKEとDROP TYPEは限定されたセマンティクスで実装されます。つまり、どちらの文でも、名前付きの型が表または型に依存している場合は、エラーが戻されて文は取り消されます。ただし、どちらの文も、FORCE句を使用すると常に正常終了します。依存する表がある場合、その表は無効になります。
|
関連項目: REVOKE、DROPTYPEおよびFORCE句の使用方法の詳細は、『Oracle Databaseリファレンス』を参照してください。 |
この項の内容は、次のとおりです。
ロールは、中間層またはプロキシを介して接続したユーザーにも付与できます。この操作については、「中間層サーバーを使用したプロキシ認証」を参照してください。
システム権限とロールを他のユーザーやロールに付与するには、GRANT SQL文を使用します。次の権限が必要です。
システム権限を付与するには、ユーザーにADMINオプション付きのシステム権限またはGRANT ANY PRIVILEGEシステム権限が付与されている必要があります。
ロールを付与するには、ユーザーにADMINオプション付きのロールまたはGRANT ANY ROLEシステム権限が付与されている必要があります。
例4-11では、システム権限CREATE SESSIONとaccts_payロールをユーザーjwardに付与しています。
例4-11 では、exec_dirディレクトリ・オブジェクトに対するEXECUTE権限をユーザーjwardに付与しています。
|
注意: オブジェクト権限は、同じGRANT文でシステム権限やロールと同時に付与することはできません。 |
ユーザーまたはロールに権限またはロールを付与するときにWITH ADMIN OPTION句を指定すると、権限受領者は、次の拡張機能を使用できるようになります。
権限受領者は、データベース内の他のユーザーまたはロールに対して、システム権限またはロールの付与または取消しができます。ただし、自分自身からロールを取り消すことはできません。
権限受領者は、ADMINオプション付きのシステム権限やロールを付与できます。
ロールの権限受領者は、そのロールを変更または削除できます。
例4-13では、new_dbaロールをWITH ADMIN OPTION句付きでユーザーmichaelに付与しています。
ユーザーmichaelは、new_dbaロール内の権限をすべて暗黙的に使用できることに加え、必要に応じてnew_dbaロールを付与、取消しおよび削除できます。このように、ADMINオプションは非常に強力な機能であるため、このオプションを付けてシステム権限やロールを付与する際は、十分に注意してください。通常、これらの権限はセキュリティ管理者向けに用意されており、システム内の他の管理者やユーザーに付与することはほとんどありません。
|
注意: ユーザーがロールを作成すると、そのロールは自動的にADMINオプション付きでその作成ユーザーに付与されます。 |
Oracle Databaseでは、GRANT文を使用して新しいユーザーを作成できます。IDENTIFIED BY句を使用してパスワードを指定することで、ユーザー名がデータベースに存在しない場合も、指定したユーザー名とパスワードで新しいユーザーが作成されます。
例4-14では、新規ユーザーとしてpsmithを作成し、CREATE SESSIONシステム権限をpsmithに付与しています。
GRANT文を使用すると、ロールとユーザーにオブジェクト権限を付与できます。オブジェクト権限を付与するには、次のいずれかの条件を満たしている必要があります。
指定するオブジェクトを所有している。
GRANT ANY OBJECT PRIVILEGEシステム権限を付与されている。この権限を使用すると、オブジェクト所有者のかわりに権限の付与と取消しを実行できます。
オブジェクト権限が付与されるときに、WITH GRANT OPTION句が指定されている。
|
注意: 同じGRANT文で、オブジェクト権限とともにシステム権限とロールを付与することはできません。 |
例4-15では、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の有無を問わずオブジェクト権限を付与でき、そしてデータベース内の任意のロールに付与できます。
次の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, GRANTOR, PRIVILEGE, GRANTABLE FROM DBA_TAB_PRIVS WHERE TABLE_NAME = 'EMPLOYEES' and OWNER = 'HR'; GRANTEE GRANTOR PRIVILEGE GRANTABLE -------- ------- ----------- ---------- BLAKE HR SELECT YES
ここで、ユーザーblakeにもGRANT ANY OBJECT PRIVILEGEシステム権限があると想定します。このユーザーが次の文を発行します。
GRANT SELECT ON HR.EMPLOYEES TO clark;
この場合は、DBA_TAB_PRIVSビューを再び問い合せると、blakeが権限付与者として表示されます。
GRANTEE GRANTOR PRIVILEGE GRANTABLE -------- -------- --------- ---------- BLAKE HR SELECT YES CLARK 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オプション付きでシステム権限またはロールを付与されているユーザーは、他のデータベース・ユーザーまたはロールから権限またはロールを取り消すことができます。取消しを行うユーザーは、権限やロールを最初に付与したユーザーでなくてもかまいません。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 GRANTOR PRIVILEGE GRANTABLE -------- ------- ----------- ---------- BLAKE HR SELECT YES CLARK BLAKE SELECT NO CLARK HR SELECT NO
ユーザーblakeが次のREVOKE文を発行します。
REVOKE SELECT ON HR.EMPLOYEES FROM clark;
ユーザーblakeがユーザーclarkに付与したオブジェクト権限のみが削除されます。オブジェクト所有者HRによる権限付与はそのまま残ります。
GRANTEE GRANTOR PRIVILEGE GRANTABLE -------- ------- ----------- ---------- BLAKE HR SELECT YES CLARK HR SELECT NO
blakeが再度REVOKE文を発行すると、今度は(HRのかわりに)adamsがGRANT ANY OBEJCT PRIVILEGEシステム権限を使用して付与したオブジェクト権限が削除されます。
表やビューの列を指定して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文によって、human_resourcesロールに対して、dname列のUPDATE権限の付与がやりなおし、リストアまたは再発行されます。
権限のタイプによっては、権限の取消しによって連鎖的な影響が発生する場合があります。次の各項で、これについて説明します。
DDL操作に関連するシステム権限を取り消すときには、この権限がADMINオプション付きで付与されたか無しで付与されたかに関係なく、連鎖的な影響はありません。たとえば、次のような場合を考えてみます。
セキュリティ管理者が、ADMIN optionを指定して、ユーザーjfeeにCREATE TABLEシステム権限を付与します。
ユーザーjfeeが表を作成します。
ユーザーjfeeが、ユーザーtsmithに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付きのemp表に対するSELECTオブジェクト権限を付与されているuser1が、user2に対してemp表に対するSELECT権限を付与したとします。その後、user1からSELECT権限を取り消します。このREVOKE文はuser2にも連鎖します。user1とuser2の取り消されたSELECT権限に依存するオブジェクトもすべて、前述のように影響を受ける可能性があります。
ALTERまたはINDEXオブジェクト権限を取り消しても、ALTERおよびINDEX DDLの各オブジェクト権限を必要とするオブジェクト定義には影響を与えません。たとえば、別のユーザーに属する表に索引を作成したユーザーからINDEX権限を取り消しても、その索引はそのまま残ります。
ロールPUBLICに対して、権限とロールの付与および取消しを実行できます。PUBLICにはすべてのデータベース・ユーザーがアクセスできるため、PUBLICに対して付与されたすべての権限またはロールには、すべてのデータベース・ユーザーがアクセスできます。
セキュリティ管理者とデータベース・ユーザーは、すべてのデータベース・ユーザーが権限またはロールを必要としている場合のみ、PUBLICに権限またはロールを付与してください。これによって、各データベース・ユーザーには常に、現在のグループ・タスクの正常実行に必要な権限のみが付与されているという一般規則が保証されます。
PUBLICから権限を取り消すと、かなりの規模で影響が連鎖する可能性があります。DML操作に関連する任意の権限をPUBLICから取り消すと(たとえばSELECT ANY TABLEまたはUPDATE ON emp)、データベース内のファンクションとパッケージを含むすべてのプロシージャが再認可されるまで再び使用できなくなります。したがって、DMLに関連する権限をPUBLICに付与したり、取り消す場合には注意が必要です。
この項の内容は、次のとおりです。
セキュリティ管理者がGRANT文とREVOKE文を使用して、ユーザーに対し明示的にデータベース・ロールを付与または取り消すかわりに、Oracle Databaseが稼働しているオペレーティング・システムによって、接続時にユーザーにロールを付与できます。つまり、オペレーティング・システムを使用してロールを管理し、ユーザーのセッション作成時にOracle Databaseにそのロールを渡すことができます。このメカニズムの一部として、ユーザーのデフォルト・ロールや、ADMINオプション付きでユーザーに付与するロールを識別できます。オペレーティング・システムを使用してロールを使用するユーザーを認可する場合は、必ずすべてのロールをデータベース内に作成し、GRANT文を使用してそのロールに権限を割り当てる必要があります。
ロールは、ネットワーク・サービスを介しても付与できます。
ユーザーのデータベース・ロールを識別するためにオペレーティング・システムを使用する方法の利点は、Oracleデータベースの権限管理をデータベースの外部で実施できることです。オペレーティング・システムに組み込まれたセキュリティ機能によって、ユーザーの権限が制御されます。また、このオプションを使用すると、いくつかのシステム・アクティビティのセキュリティを集中管理できるため、次のような状況で役立ちます。
MVS版Oracleの管理者が、データベース・ユーザーのロールを識別するためにRACFグループを使用する場合
UNIX版Oracleの管理者が、データベース・ユーザーのロールを識別するためにUNIXグループを使用する場合
VMS版Oracleの管理者が、データベース・ユーザーのロールを識別するために権限識別子を使用する場合
ユーザーのデータベース・ロールを識別するためにオペレーティング・システムを使用する方法の主なデメリットは、権限管理がロール・レベルでしか実施できないことです。個々の権限は、オペレーティング・システムを使用して付与することはできません。ただし、GRANT文を使用してデータベース内で付与することは可能です。
この機能を使用する際の第2のデメリットは、オペレーティング・システムがロールを管理している場合に、デフォルトではユーザーが共有サーバーまたはその他のネットワーク接続を介してデータベースに接続できないことです。ただし、このデフォルトは「オペレーティング・システムによるロール管理使用時のネットワーク接続の使用」の説明に従って変更できます。
|
注意: この項で説明されている機能は、一部のオペレーティング・システムでしか使用できません。これらの機能が使用できるかどうかを確認するには、使用しているオペレーティング・システム固有のOracle Databaseマニュアルを参照してください。 |
セッションの作成時に、データベースがオペレーティング・システムを使用して各ユーザーのデータベース・ロールを識別するように、初期化パラメータOS_ROLESをTRUEに設定します(インスタンスが実行中の場合は再起動が必要)。ユーザーがデータベースとのセッションを作成しようとすると、Oracle Databaseはオペレーティング・システムによって識別されるデータベース・ロールを使用して、そのユーザーのセキュリティ・ドメインを初期化します。
ユーザーのデータベース・ロールを識別するためには、各Oracle Databaseユーザーのオペレーティング・システム・アカウントが、どのデータベース・ロールをユーザーが使用できるようになるかを示すオペレーティング・システム識別子(これらはグループ、権限識別子、または他の類似した名前で呼ばれる場合があります)を持っている必要があります。ロールの指定は、どのロールがユーザーのデフォルト・ロールであるか、どのロールがADMINオプションで使用可能かを示すことも可能です。どのオペレーティング・システムを使用している場合も、オペレーティング・システム・レベルでのロールの指定は次の形式になります。
ora_ID_ROLE[[_d][_a][_da]]
次のように値を指定します。
IDの定義は、オペレーティング・システムが異なると変わります。たとえばVMSでは、IDはデータベースのインスタンス識別子、VMSではコンピュータ・タイプ、UNIXではシステムIDです。
|
注意: IDは、ORACLE_SIDと照合する際に大/小文字が区別されます。ROLEでは、大/小文字は区別されません。 |
ROLEは、データベース・ロールの名前です。
dは、このロールがデータベース・ユーザーのデフォルト・ロールであることを示すオプション文字です。
aは、このロールがADMINオプション付きでユーザーに付与されることを示すオプション文字です。このオプション文字を指定することによって、ユーザーはこのロールを他のロールにのみ付与できるようになります。オペレーティング・システムを使用してロールを管理している場合は、ユーザーにロールを付与できません。
|
注意: 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オプション付きで付与されます。
オペレーティング・システムによって管理されているロールを使用する場合は、データベース・ロールがオペレーティング・システムのユーザーに付与されることに注意してください。オペレーティング・システム・ユーザーが接続できるデータベース・ユーザーは、認可されたデータベース・ロールを使用できます。このため、OS_ROLES = TRUEを使用している場合は、権限が付与されているオペレーティング・システム・アカウントにデータベース・アカウントを対応付けるために、すべてのOracle DatabaseユーザーをIDENTIFIED EXTERNALLYとして定義することを考慮してください。
OS_ROLESパラメータがTRUEに設定されている場合は、ユーザーに対するロールの付与と取消しがオペレーティング・システムによって完全に管理されます。それまでにGRANT文によってユーザーに付与されたロールは適用されません。ただし、それらのロールはデータ・ディクショナリには残っています。オペレーティング・システム・レベルでのユーザーへのロールの付与のみが適用されます。この場合も、ユーザーは権限をロールとユーザーに付与できます。
|
注意: オペレーティング・システムによってADMINオプション付きでロールが付与された場合、ユーザーはそのロールを他のロールにのみ付与できます。 |
OS_ROLES初期化パラメータがTRUEに設定されている場合、オペレーティング・システムによって付与されたロールは、SET ROLE文を使用して動的に使用可能にできます。ロールがパスワードやオペレーティング・システムによる認可を必要とするように定義されていた場合でも、この文は適用されます。ただし、ユーザーのオペレーティング・システム・アカウントで識別されないロールは、SET ROLE文では指定できません。これは、OS_ROLES = FALSEのときにGRANT文を使用してロールを付与していた場合でも同じです。(このようなロールを指定しても無視されます。)
OS_ROLESがTRUEに設定されている場合、ユーザーは最大148個のロールを使用可能にできます。この数には、ロールに付与されている可能性のある他のロールも含まれることに注意してください。
オペレーティング・システムでロールを管理する場合、ユーザーは、デフォルトでは共有サーバーを介してデータベースに接続できません。リモート・ユーザーは保護されていない接続を介して別のオペレーティング・システム・ユーザーになりすますおそれがあるため、デフォルトでこのような制限が適用されています。
このようなセキュリティに対する危険性の心配がない場合は、初期化パラメータREMOTE_OS_ROLESをTRUEに設定することで、共有サーバーまたはその他のネットワーク接続でオペレーティング・システムのロール管理を使用できます。この変更は、次回インスタンスを起動して、データベースをマウントするときに有効になります。このパラメータのデフォルト設定はFALSEです。
付与と取消しがいつ有効になるかは、付与または取り消す対象によって異なります。
任意の対象(ユーザー、ロールおよびPUBLIC)に対するシステム権限とオブジェクト権限の付与および取消しは、即時に有効になります。
任意の対象(ユーザー、他のロール、PUBLIC)に対するロールの付与および取消しが有効になるのは、その付与および取消しの実行後、ロールを再度使用可能にするために現行のユーザー・セッションでSET ROLE文を発行したとき、あるいはその付与または取消しを実行した後に新しくユーザー・セッションを作成したときです。
現在使用可能なロールは、SESSION_ROLESデータ・ディクショナリ・ビューを問い合せることによって確認できます。
ユーザーまたはアプリケーションは、ユーザー・セッション中にSET ROLE文を何度でも使用して、現在そのセッションで使用可能になっているロールを変更できます。ユーザーには、SET ROLE文で指定したロールが、事前に付与されている必要があります。
例4-16では、すでに付与されているロールclerkを使用可能にして、パスワードを指定しています。
passwordを安全なパスワードに置き換えます。パスワードの最低要件については、「パスワードの最低要件」を参照してください。
例4-17は、SET ROLEを使用してすべてのロールを使用禁止にする方法を示しています。
ユーザーがログインすると、そのユーザーに明示的に付与されている権限と、そのユーザーのデフォルト・ロールに含まれる権限が、すべて使用可能になります。
ユーザーのデフォルト・ロールのリストは、ALTER USER SQL文を使用して設定および変更できます。ALTER USER文では、ユーザーがデータベースに接続するときに使用可能になるロールを指定します。この場合、ユーザーにこれらのロールがGRANT文で直接付与されているか、これらのロールがCREATE ROLE権限を持つユーザーによって作成されている必要があります。ALTER USER文のDEFAULT ROLE句の制限事項は、『Oracle Database SQL言語リファレンス』を参照してください。
例4-18では、ユーザーjaneに対してデフォルト・ロールのpayclerkとpettycashを設定しています。
CREATE USER文ではユーザーのデフォルト・ロールを設定できません。ユーザーを最初に作成すると、デフォルトのユーザー・ロール設定はALLであり、ユーザーにその後に付与されるすべてのロールがデフォルト・ロールになります。デフォルトのユーザー・ロールを制限するには、ALTER USER文を使用します。
|
注意: (グローバル・ロールやアプリケーション・ロール以外の)ロールを作成すると、このロールが自分に暗黙的に付与され、自分のデフォルト・ロールのセットが新しいロールを含むように更新されます。ユーザー・セッションで有効にできるロールは148個のみであることに注意してください。DBAロールのような集計ロールがユーザーに付与されると、そのロールに付与されるロールはユーザーが持っているロール数に含まれます。たとえば、あるロールには20個のロールが付与されており、そのロールをユーザーに付与すると、そのユーザーは21個の追加ロールを持っていることになります。したがって、新しいロールをユーザーに付与するときは、ALTER USER文のDEFAULT ROLE句を使用してそのユーザーのデフォルト・ロールとして指定されるロールが多すぎないよう確認してください。 |
ユーザーが使用可能にできるロール数は148個までです。ユーザーには必要な数だけロールを付与できますが、ユーザーに付与するロール数は、ユーザーが必要な最小限のロール数に制限する必要があります。ユーザーへのロール付与に関する追加ガイドラインは、「ロールの保護に関するガイドライン」を参照してください。
PL/SQLパッケージUTL_TCP、UTL_SMTP、UTL_MAIL、UTL_HTTP、UTL_INADDR、DBMS_LDAPおよびHttpUriType型を介した外部ネットワーク・サービスおよびウォレットへのユーザー・アクセスの制御を構成できます。
データベースから外部ネットワーク・サービスへのアクセスが必要なユーザーやロールに、ファイングレイン・アクセス・コントロールを構成します。これによって、特定のユーザー・グループは、付与されている権限に基づいて1つ以上のホスト・コンピュータに接続できます。通常、この機能は、特定のホスト・アドレスで実行されるアプリケーションへのアクセスを制御するために使用します。
パスワードまたはクライアント証明書認証を必要とするHTTPリクエストを処理するために、Oracleウォレットにファイングレイン・アクセス・コントロールを構成します。この機能により、Oracleウォレットに格納されているパスワードとクライアント証明書を使用するユーザーに、保護されている外部HTTPリソースにUTL_HTTPパッケージを介してアクセスする権限を付与できます。たとえば、アプリケーションで資格証明をハードコードするかわりに、ウォレットに格納されている資格証明を使用するようにアプリケーションを構成できます。ウォレットを使用してパスワードと資格証明を格納する方法の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。
この項の内容は、次のとおりです。
外部ネットワーク・サービスに対するファイングレイン・アクセス・コントロールを構成するために、Oracle XML DBに保管されるアクセス制御リスト(ACL)を作成します。アクセス制御リストは、Oracle XML DBそのものを使用するか、DBMS_NETWORK_ACL_ADMINおよびDBMS_NETWORK_ACL_UTILITY PL/SQLパッケージを使用して作成できます。このマニュアルでは、これらのパッケージを使用してアクセス制御リストを作成および管理する方法について説明します。Oracle XML DBを使用してアクセス制御リストを作成する場合の説明とアクセス制御リストに関する全体的な概念情報は、『Oracle XML DB開発者ガイド』を参照してください。
この機能を使用することで、データベース・ユーザーがPL/SQLネットワーク・ユーティリティ・パッケージUTL_TCP、UTL_SMTP、UTL_MAIL、UTL_HTTP、UTL_INADDR、PL/SQLパッケージDBMS_LDAPおよびHttpUriType型を使用して接続できる外部ネットワーク・ホストが制限されるため、ネットワーク接続のセキュリティが強化されます。この機能を使用しない場合、デフォルトでは、PL/SQLユーティリティ・パッケージは、PUBLICユーザーに付与されるEXECUTE権限付きで作成されるため、データベースへのアクセス権を獲得した侵入者が故意にネットワークを攻撃する可能性があります。これらのPL/SQLネットワーク・ユーティリティ・パッケージおよびDBMS_NETWORK_ACL_ADMINとDBMS_NETWORK_ACL_UTILITYパッケージは、IPバージョン4(IPv4)アドレスとIPバージョン6(IPv6)アドレスの両方をサポートしています。このマニュアルでは、両方のバージョンに対してアクセス制御を管理する方法について説明します。Oracle DatabaseでのIPv4およびIPv6表記法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。
リモートのWebサーバーで保護されているWebページにアクセスする際、ユーザーはOracleウォレットに格納されているパスワードとクライアント証明書を使用して認証を行うことができます。Oracleウォレットでは、ユーザーのパスワードとクライアント証明書を安全に格納できます。
ウォレットに対するアクセス制御を構成するには、次のコンポーネントが必要です。
Oracleウォレット。Oracleウォレットは、Oracle DatabaseのmkstoreユーティリティまたはOracle Wallet Managerを使用して作成できます。HTTPリクエストでは、外部パスワード・ストアまたはウォレット内のクライアント証明書を使用してユーザーが認証されます。
ユーザーにウォレットの使用権限を付与するアクセス制御リスト。アクセス制御リストは、DBMS_NETWORK_ACL_ADMIN PL/SQLパッケージを使用して作成します。
ウォレットとアクセス制御リストを関連付ける方法。DBMS_NETWORK_ACL_ADMIN PL/SQLパッケージを使用します。
ウォレットを使用すると、保護されているWebページへのアクセスに必要なパスワードとクライアント証明書を安全に格納できます。
Oracle Database 11g リリース1(11.1)より前のリリースからアップグレードしているときに、アプリケーションがPL/SQLネットワーク・ユーティリティ・パッケージUTL_TCP、UTL_SMTP、UTL_MAIL、UTL_HTTP、UTL_INADDR、PL/SQLパッケージDBMS_LDAPまたはHttpUriType型に依存している場合は、そのアプリケーションの実行を試みたときに、次のエラーが発生する可能性があります。
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プロシージャを使用して、アクセス制御リストの内容を作成します。内容は、アクセス制御リストの名前、簡単な説明、そしてアクセス制御リストに対応付ける1つのユーザーまたはロールの権限設定からなります。アクセス制御リストでは、各ユーザーまたはロールの権限はアクセス制御エントリ(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',
ユーザー・アカウントまたはロールの名前は大/小文字を区別して入力します。たとえば、ロール名ACCT_MGRがすべて大文字でデータベースに格納されている場合は、大文字と小文字の両方を使用したり、小文字で入力しても機能しません。DBA_USERSビューとDBA_ROLESデータ・ディクショナリ・ビューを問い合せることで、現行のデータベース・インスタンス内のユーザー・アカウントとロールを確認できます。通常、ユーザー名とロールは大文字で保存されます。
複数のユーザーを入力する場合、またはこのユーザーまたはロールに追加の権限を付与する場合、このアクセス制御リストのXMLファイルを作成した後、次に説明するDBMS_NETWORK_ACL.ADD_PRIVILEGEプロシージャを使用します。
is_grant: TRUEまたはFALSEを入力し、権限を付与するか拒否するかを示します。例:
is_grant => TRUE,
privilege: connectまたはresolveを入力します。この設定は、大/小文字が区別されるため、必ず小文字で入力してください。例:
privilege => 'connect',
connect権限は、外部ホストのネットワーク・サービスに接続する権限をユーザーに付与します。resolve権限は、ネットワーク・ホスト名またはIPアドレスを解決する権限をユーザーに付与します。
UTL_TCP、UTL_SMTP、UTL_MAIL、UTL_HTTP、DBMS_LDAPのパッケージおよびHttpUriType型を使用してホストに接続するデータベース・ユーザーには、外部ネットワークのホスト・コンピュータへの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');
アクセス制御リストにユーザーまたはロールを追加するか、1つのユーザーまたはロールに追加の権限を付与するには、DBMS_NETWORK_ACL.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',
localhostを指定し、ローカル・ホストが想定されている状況でPL/SQLパッケージUTL_INADDRおよびUTL_HTTPを使用してホスト名が指定されていない場合、これらのパッケージは、host設定のlocalhostが割り当てられているACLを検索して使用します。
アクセス制御リスト割当てにおけるネットワーク・ホスト・コンピュータの動作の詳細は、次の各項を参照してください。
lower_port:(オプション)TCP接続に対するポート範囲の下限を入力します。この設定は、connect権限の場合にのみ使用し、resolve権限の場合は省略します。デフォルトはnullで、ポート制限がない(つまり、すべてのポートにACLが適用される)ことを意味します。ポート番号の範囲は1から65535です。
例:
lower_port => 80,
upper_port:(オプション)TCP接続に対するポート範囲の上限を入力します。この設定は、connect権限の場合にのみ使用し、resolve権限の場合は省略します。デフォルトはnullで、ポート制限がない(つまり、すべてのポートにACLが適用される)ことを意味します。ポート番号の範囲は1から65535です。
例:
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パッケージおよびタイプ・リファレンス』を参照してください。
この方法では、Oracleウォレットに保管されるパスワードとクライアント証明書に対するアクセス権をユーザーに付与して、ユーザーが外部のWebサーバーに対して自身を認証できるようにします。これにより、ユーザーは保護されたWebページをWebサーバーから取得できるようになります。
この項の内容は、次のとおりです。
ウォレットは、mkstoreコマンドライン・ユーティリティまたはOracle Wallet Managerユーザー・インタフェースを使用して作成できます。ウォレットにパスワードを格納するには、mkstoreを使用する必要があります。標準ウォレット・タイプとPKCS11ウォレット・タイプのどちらも使用可能で、必要であればウォレットを自動ログイン・ウォレットにすることもできます。ウォレットの作成の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。
ウォレットを作成するには、次のようにします。
ウォレットがファイルにエクスポートされていることを確認します。
ウォレットを作成したディレクトリを書き留めておきます。このディレクトリ・パスは、このセクションの手順の終了後に必要になります。
ウォレットを作成した後、HTTP認証でウォレットのパスワード資格証明を使用する際にユーザーが必要なパスワードまたはクライアント証明書権限を割り当てるアクセス制御リストを作成できます。
例:
BEGIN DBMS_NETWORK_ACL_ADMIN.CREATE_ACL ( acl => 'file_name.xml', description => 'description', principal => 'user_or_role', is_grant => TRUE|FALSE, privilege => 'privilege'; ... END;
次のように値を指定します。
acl: ACLの名前を入力し、この名前を書き留めておきます。この名前は、「手順3: ウォレットへのアクセス制御リストの割当て」で必要になります。このファイルは、データベースのXML DBリポジトリにある/sys/aclsディレクトリに作成されます。.xml拡張子を指定してください。例:
acl => 'hr_access_wallet_acl.xml',
description: ファイルの目的に関する簡単な説明を入力します。例:
description => 'Wallet ACL for the hr_access application',
principal: 権限を付与または拒否するユーザー・アカウントまたはロールを入力します。例:
principal => 'HR_CLERK',
この名前は、大/小文字を区別して入力します。たとえば、ロール名HR_CLERKがすべて大文字でデータベースに格納されている場合は、大文字と小文字の両方を使用したり、小文字で入力しても機能しません。DBA_USERSビューとDBA_ROLESデータ・ディクショナリ・ビューを問い合せることで、現行のデータベース・インスタンス内のユーザー・アカウントとロールを確認できます。通常、ユーザー名とロールは大文字で保存されます。
複数のユーザーを追加する場合、またはこのユーザーに追加の権限を付与する場合、このアクセス制御リストのXMLファイルを作成した後、DBMS_NETWORK_ACL.ADD_PRIVILEGEプロシージャを使用できます。
is_grant: TRUEまたはFALSEを入力し、権限を付与するか拒否するかを示します。例:
is_grant => TRUE,
privilege: 次のいずれかの設定を、小文字とハイフンを使用して入力します。権限名は大/小文字が区別されることに注意してください。
use-passwords: ウォレットのパスワードを使用する権限をユーザーに付与します。
use-client-certificates: ウォレットのクライアント証明書でユーザーを認証します。
例:
privilege => 'use-client-certificates');
この手順では、このアクセス制御リストを先に作成したウォレットに割り当てます。この結果、DBA_WALLET_ACLSデータ・ディクショナリ・ビューを問い合せて設定を確認できるようになります。
例:
BEGIN ... DBMS_NETWORK_ACL_ADMIN.ASSIGN_WALLET_ACL ( acl => 'file_name.xml', wallet_path => 'file:path_to_directory_containing_wallet'); END;
次のように値を指定します。
acl: 前のセクションの「手順2: ウォレット権限を付与するアクセス制御リストの作成」でウォレットに作成した名前を入力します。例:
acl => 'hr_access_wallet_acl.xml',
wallet_path: ウォレットが格納されているディレクトリのパスを入力します。ウォレットのパスを指定する際は、絶対パスを使用し、ディレクトリ・パスの前にfile:を入れる必要があります。$ORACLE_HOMEなどの環境変数を使用したり、file:の後およびパス名の前にスペースを挿入することはできません。例:
wallet_path => 'file:/oracle/wallets/hr_access_access'
この手順では、UTL_HTTP PL/SQLパッケージを使用して、HTTPリクエストとそのレスポンスで個別に使用されるリクエスト・コンテキスト・オブジェクトを作成します。UTL_HTTPパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
例:
DECLARE
req_context UTL_HTTP.REQUEST_CONTEXT_KEY;
req UTL_HTTP.REQ;
BEGIN
req_context := UTL_HTTP.CREATE_REQUEST_CONTEXT (
wallet_path => 'file:path_to_directory_containing_wallet',
wallet_password => 'wallet_password'|NULL);
req := UTL_HTTP.BEGIN_REQUEST(
url => 'URL_to_application',
request_context => 'request_context'|NULL);
...
END;
次のように値を指定します。
req_context: UTL_HTTP.CREATE_REQUEST_CONTEXT_KEYデータ型を使用して、リクエスト・コンテキスト・オブジェクトを作成します。このオブジェクトには、Oracle Databaseがリクエスト・コンテキストの識別に使用する、ランダムに生成された数値キーが格納されています。UTL_HTTP.CREATE_REQUEST_CONTEXTファンクションは、リクエスト・コンテキスト自体を作成します。
req: UTL_HTTP.REQデータ型を使用して、HTTPリクエストを開始するためのオブジェクトを作成します。このオブジェクトは後で、パスワードで保護されたWebページにアクセスするために、ウォレットからユーザー名とパスワードを設定する際に参照します。
wallet_path: ウォレットが格納されているディレクトリのパスを入力します。このパスは、前のセクションの「手順3: ウォレットへのアクセス制御リストの割当て」でアクセス制御リストを作成したときに指定したパスと同じであることを確認してください。ディレクトリ・パスの前にfile:を含める必要があります。$ORACLE_HOMEなどの環境変数を使用しないでください。
例:
wallet_path => 'file:/oracle/wallets/hr_access_access',
wallet_password: ウォレットを開くためのパスワードを入力します。デフォルトはNULLで、自動ログイン・ウォレットに使用します。例:
wallet_password => NULL);
url: ウォレットを使用するアプリケーションのURLを入力します。
例:
url => 'www.hr_access.example.com',
request_context: このセクションの前の方で作成したリクエスト・コンテキスト・オブジェクトの名前を入力します。このオブジェクトにより、ウォレットは同一データベース・セッション内の他のアプリケーションとは共有されなくなります。
例:
request_context => req_context);
他のアプリケーションとセッションを共有している場合に、リクエスト・コンテキストを使用してウォレットを保留
他のアプリケーションとデータベース・セッションを共有している場合は、リクエスト・コンテキストを使用してウォレットを保留にする必要があります。アプリケーションがデータベース・セッションを排他的に使用している場合は、かわりにSET_WALLETプロシージャを使用してデータベース・セッションでウォレットを保留できます。
例:
DECLARE
req UTL_HTTP.REQ;
BEGIN
UTL_HTTP.SET_WALLET(
path => 'file:path_to_directory_containing_wallet',
password => 'wallet_password'|NULL);
req := UTL_HTTP.BEGIN_REQUEST(
url => 'URL_to_application');
...
END;
要求された保護されているURLが、認証にユーザー名とパスワードを必要とする場合は、SET_AUTHENTICATION_FROM_WALLETプロシージャを使用してウォレットからユーザー名とパスワードを設定して認証します。
クライアント証明書のみを使用する認証
要求された保護されているURLが、認証にクライアント証明書のみを必要とする場合、BEGIN_REQUESTファンクションはウォレットに割り当てられているACLでユーザーにuse-client-certificates権限が付与されているものと見なして、ウォレットから必要なクライアント証明書を送信します。認証はリモートWebサーバーで成功し、ユーザーはGET_RESPONSEファンクションを使用してHTTP応答を取得できます。
パスワードを使用した認証
要求された保護されているURLが、認証にユーザー名とパスワードを必要とする場合は、SET_AUTHENTICATION_FROM_WALLETプロシージャを使用してウォレットからユーザー名とパスワードを設定して認証する必要があります。
例:
DECLARE req_context UTL_HTTP.REQUEST_CONTEXT_KEY; req UTL_HTTP.REQ; BEGIN ... UTL_HTTP.SET_AUTHENTICATION_FROM_WALLET( r => HTTP_REQUEST, alias => 'alias_to_retrieve_credentials_stored_in_wallet', scheme => 'AWS|Basic', for_proxy => TRUE|FALSE); END;
次のように値を指定します。
r: 前のセクションで作成したUTL_HTTP.BEGIN_REQUESTプロシージャで定義したHTTPリクエストを入力します。例:
r => req,
alias: Oracleウォレットに格納されているユーザー名とパスワード資格証明を識別および取得するための別名を入力します。たとえば、このユーザー名とパスワード資格証明を識別するための別名がhr_accessであるとします。
alias => 'hr_access',
scheme: 次のいずれかを入力します。
AWS: Amazon Simple Storage Service(S3)スキームを指定します。このスキームは、Amazon.comのWebサイトへのアクセスを構成する場合にのみ使用します。(この設定の詳細は、Amazonにお問い合せください。)
Basic: HTTP basic認証を指定します。デフォルトはBasicです。
例:
scheme => 'Basic',
for_proxy: HTTP認証情報がWebサーバーではなくHTTPプロキシ・サーバーへのアクセス用かどうかを指定します。デフォルトはFALSEです。
次に例を示します。
for_proxy => TRUE);
ウォレットのユーザー名とパスワードを使用するには、ウォレットに割り当てられているACLでユーザーにuse-passwords権限が付与されている必要があります。
|
関連項目: 管理者がUTL_MAIL PL/SQLパッケージを使用して電子メール・アラートを構成する必要がある場合の、アクセス制御リストの使用方法を示した例については、『Oracle Database Vault管理者ガイド』 |
例4-19は、us-example-com-permissions.xmlというアクセス制御リストの作成方法を示しています。このアクセス制御リストは、ACCT_MGRロールを持つユーザーに対して、ホストus.example.comで実行されるネットワーク・サービスへのアクセス権を付与します。
例4-19 1つのロールと1つのネットワーク接続を割り当てるアクセス制御リストの作成
-- 1. 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', -- Must be in upper case is_grant => TRUE, privilege => 'connect'); END; / -- 2. 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-20は、us-example-com-permissions.xmlアクセス制御リストより少し複雑なリストの作成方法を示しています。この例では、複数のロール権限とその優先順位を指定し、複数のホスト・コンピュータに割り当てます。
ホスト名の詳細は、「ネットワーク・ホスト・コンピュータのグループの指定」および「複数のアクセス制御リスト割当てでのホスト・コンピュータの優先順位」を参照してください。アクセス制御リストXMLファイル内の複数のACE要素の順序を判断するには、「単一アクセス制御リスト内の複数のユーザーとロールに対する優先順位の設定」も参照してください。
例4-20 複数のロールと複数のネットワーク接続を割り当てるアクセス制御リストの作成
-- 1. 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', -- Must be in upper case 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; / -- 2. 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-21は、前述のアクセス制御リストで付与された権限をDBA_NETWORK_ACL_PRIVILEGESデータ・ディクショナリ・ビューに表示する方法を示しています。
例4-21 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-22は、アクセス制御リストのホスト割当てをDBA_NETWORK_ACLSデータ・ディクショナリ・ビューに表示する方法を示しています。
例4-22 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ロールは最初のホストに対するresolve権限を持っており、ACCT_CLERKロールは1番目と2番目のターゲット・ホストに対する接続権限を持っています。ACCT_MGRロールは2番目のホストに対するresolve権限を持っていませんが、これはポート範囲が2番目のホストに対する割当てで指定されているためです。
SQL*Plusを使用してアクセス制御リストの内容をチェックする方法は、『Oracle XML DB開発者ガイド』を参照してください。
例4-23では、人事部門の2つのロール、hr_clerkとhr_managerによるウォレットへのアクセスを構成しています。これらのロールは、use-passwords権限を使用して、ウォレットに格納されているパスワードにアクセスします。この例では、ウォレットは同一データベース・セッション内の他のアプリケーションとは共有されません。
例4-23 非共有ウォレットのパスワードを使用するACLアクセスの構成
/* 1. At a command prompt, create the wallet. The following example uses the user name hr_access as the alias to identify the user name and password stored in the wallet. You must use this alias name when you call the SET_AUTHENTICATION_FROM_WALLET procedure later on. */ $ mkstore -wrl $ORACLE_HOME/wallets/hr_access_access -create Enter password: password Enter password again: password $ mkstore -wrl $ORACLE_HOME/wallets/hr_access_access -createCredential hr_access hr_usr Your secret/Password is missing in the command line Enter your secret/Password: password Re-enter your secret/Password: password Enter wallet password: password /* 2. In SQL*Plus, create an access control list to grant privileges for the wallet. The following example grants the use-passwords privilege to the hr_clerk and hr_manager roles, and then it assigns this ACL to the wallet.*/ BEGIN DBMS_NETWORK_ACL_ADMIN.CREATE_ACL( acl => 'hr_access_wallet_acl.xml', description => 'Wallet ACL for hr_access application', principal => 'HR_CLERK', -- Must be in upper case is_grant => TRUE, privilege => 'use-passwords'); DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE( acl => 'hr_access_wallet_acl.xml', principal => 'HR_MANAGER', is_grant => TRUE, privilege => 'use-passwords'); DBMS_NETWORK_ACL_ADMIN.ASSIGN_WALLET_ACL( acl => 'hr_access_wallet_acl.xml', wallet_path => 'file:/oracle/wallets/hr_access_access'); END; / COMMIT; /* 3. Create a request context and request object, and then set the authentication for the wallet. */ DECLARE req_context UTL_HTTP.REQUEST_CONTEXT_KEY; req UTL_HTTP.REQ; BEGIN req_context := UTL_HTTP.CREATE_REQUEST_CONTEXT( wallet_path => 'file:/oracle/wallets/hr_access_access', wallet_password => NULL, enable_cookies => TRUE, max_cookies => 300, max_cookies_per_site => 20); req := UTL_HTTP.BEGIN_REQUEST( url => 'www.hr_access.example.com', request_context => req_context); UTL_HTTP.SET_AUTHENTICATION_FROM_WALLET( r => req, alias => 'hr_access'), scheme => 'Basic', for_proxy => FALSE); END; /
例4-24は、ウォレットを共有データベース・セッションに使用するように構成し、現在のデータベース・セッション内のすべてのアプリケーションがこのウォレットへのアクセス権を持つ点を除いて、例4-23とほぼ同じです。
例4-24 共有データベース・セッションに使用するウォレットのACLアクセスの構成
/* Follow these steps: 1. Use Oracle Wallet Manager to create the wallet and add the client certificate. See Oracle Database Advanced Security Administrator's Guide for detailed information about using Oracle Wallet Manager. 2. In SQL*Plus, create an access control list to grant privileges for the wallet. The following example grants the use-client-certificates privilege to the hr_clerk and hr_manager roles, then it assigns this ACL to the wallet. */ BEGIN DBMS_NETWORK_ACL_ADMIN.CREATE_ACL( acl => 'hr_access_wallet_acl.xml', description => 'Wallet ACL for hr_access application', principal => 'HR_CLERK', -- Must be in upper case is_grant => TRUE, privilege => 'use-client-certificates'); DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE( acl => 'hr_access_wallet_acl.xml', principal => 'HR_MANAGER', is_grant => TRUE, privilege => 'use-client-certificates'); DBMS_NETWORK_ACL_ADMIN.ASSIGN_WALLET_ACL( acl => 'hr_access_wallet_acl.xml', wallet_path => 'file:/oracle/wallets/hr_access_access'); END; / COMMIT; /* 3. Create a request object to handle the HTTP authentication for the wallet.*/ DECLARE req UTL_HTTP.req; BEGIN UTL_HTTP.SET_WALLET( path => 'file: $ORACLE_HOME/wallets/hr_access_access', password => NULL); req := UTL_HTTP.BEGIN_REQUEST( url => 'www.hr_access.example.com', method => 'POST', http_version => NULL, request_context => NULL); END; /
アクセス制御リストをネットワーク・ホスト・コンピュータのグループに割り当てる場合は、アスタリスク(*)ワイルドカード文字を使用できます。たとえば、ドメインに属しているホスト・コンピュータには*.example.comを入力し、IPサブネットに属しているIPv4アドレスには192.0.2.*を入力します。アスタリスク・ワイルドカードは、最初(ドメインのピリオド(.)の前)または最後(IPサブネットのピリオド(.)の後)に配置する必要があります。たとえば、*.example.comは有効ですが、*example.comや*.example.*は無効です。ワイルドカード文字の使用は、同じホスト・コンピュータに割り当てられている複数のアクセス制御リストの優先順位に影響を与えることに注意してください。IPv6アドレスには、ワイルドカード文字を使用できません。
クラスレス・ドメイン間ルーティング(CIDR)表記法では、インターネット上でのIPパケット・ルーティングにおけるIPv4アドレスとIPv6アドレスの分類が定義されています。DBMS_NETWORK_ACL_ADMINパッケージは、IPv4アドレスとIPv6アドレスの両方に対してCIDR表記法をサポートしています。このパッケージでは、IPv4射影IPv6アドレスまたはサブネットは、IPv4ネイティブ・アドレスまたはサブネットと同等であるとみなします。たとえば、::ffff:192.0.2.1は192.0.2.1と同等で、::ffff:192.0.2.1/120は192.0.2.*と同等です。
ホスト・コンピュータとそのドメインに割り当てられている複数のアクセス制御リストでは、ホスト・コンピュータに割り当てられているアクセス制御リストが、ドメインに割り当てられているアクセス制御リストよりも優先されます。ドメインに割り当てられているアクセス制御リストの優先順位は、サブ・ドメインに割り当てられているアクセス制御リストの優先順位よりも低くなります。
たとえば、ホストserver.us.example.comに割り当てられているアクセス制御リストが、そのドメインに割り当てられている他のアクセス制御リストに先行して最初に選択されます。追加のアクセス制御リストがサブ・ドメインに割り当てられていた場合、優先順位は次のようになります。
server.us.example.com
*.us.example.com
*.example.com
*.com
*
同様に、IPアドレス(IPv4とIPv6の両方)とIPアドレスが所属するサブネットに割り当てられている複数のアクセス制御リストでは、IPアドレスに割り当てられているアクセス制御リストが、サブネットに割り当てられているアクセス制御リストよりも優先されます。サブネットに割り当てられているアクセス制御リストの優先順位は、サブネットに含まれる小さいサブネットに割り当てられているアクセス制御リストの優先順位よりも低くなります。
たとえば、IPアドレス192.0.2.3に割り当てられているアクセス制御リストが、そのIPアドレスが所属するサブネットに割り当てられている他のアクセス制御リストに先行して最初に選択されます。追加のアクセス制御リストがサブネットに割り当てられていた場合、優先順位は次のようになります。
192.0.2.3(または::ffff:192.0.2.3)
192.0.2.3/31(または::ffff:192.0.2.3/127)
192.0.2.3/30(または::ffff:192.0.2.3/126)
192.0.2.3/29(または::ffff:192.0.2.3/125)
...
192.0.2.3/24(または::ffff:192.0.2.3/120または192.0.2.*)
...
192.0.2.3/16(または::ffff:192.0.2.3/112または192.0.*)
...
192.0.2.3/8(または::ffff:192.0.2.3/104または192.*)
...
::ffff:192.0.2.3/95
::ffff:192.0.2.3/94
...
*
ポート範囲の指定があるアクセス制御リストがホスト・コンピュータ、ドメインまたは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ファンクションを使用して、2つのホスト、ドメインまたはサブネットが同じかどうか、あるいはホスト、ドメインまたはサブネットが他のホスト、ドメインまたはサブネットと同じ、または他のホスト、ドメインまたはサブネットに含まれるかどうか、を判断します。
EQUALS_HOST: 2つのホスト、ドメインまたはサブネットが同じかどうかを示す値を戻します。
CONTAINS_HOST: ホスト、ドメインまたはサブネットが他のホスト、ドメインまたはサブネットと同じかどうか、または他のホスト、ドメインまたはサブネットに含まれるかどうかを示す値を示します。また、ACL割当てのために、含まれているドメインまたはサブネットの相対的な優先順位も示します。
IPv6アドレスを使用しない場合、データベース管理者およびユーザーは、次のDBMS_NETWORK_ACL_UTILITYファンクションを使用して、ホストが所属しているドメインまたはIPv4サブネットのリストを生成し、ホストの割当てに従って優先順位別にアクセス制御リストをソートできます。
DOMAINS: アクセス制御リストが、指定のネットワーク・ホスト、サブドメインまたはIPサブネットに対する権限に影響を与える可能性があるドメインまたはIPサブネットのリストを戻します。
DOMAIN_LEVEL: 指定のホストのドメイン・レベルを戻します。
次の各項では、ユーザーがネットワーク・ホストに接続したり、ドメイン名を解決する際に必要な権限について、データベース管理者およびユーザーがチェックする方法を説明します。
データベース管理者は、DBA_NETWORK_ACLSビューを問い合せて、指定のホスト・コンピュータについてアクセス制御リストがあるかどうかを判断できます。このビューには、ネットワーク接続またはドメインへのアクセスを決定するアクセス制御リストが表示され、各アクセス制御リストについて、ユーザーのアクセス権限が付与されている(GRANTED)か、拒否されている(DENIED)か、あるいは適用外(NULL)かを確認できます。このビューの問合せを実行できるのは、データベース管理者のみです。
次の各項では、データベース管理者による、ネットワーク接続とドメイン名解決に関するユーザー権限のチェック方法について例を示します。
データベース管理者によるユーザーの接続権限のチェック
例4-25は、ユーザーprestonによるwww.us.example.comへの接続について、データベース管理者がユーザーの権限をチェックする方法を示しています。CHECK_PRIVILEGE_ACLIDプロシージャのuserパラメータに入力するユーザー名は、大/小文字が区別されることに注意してださい。この例では、ユーザー名prestonというユーザー名は正しい入力ですが、Prestonおよびprestonは誤りとなります。
次のように、DBA_USERSデータ・ディクショナリ・ビューを問い合せることで、現行のデータベース・インスタンス内のユーザーを確認できます。
SELECT USERNAME FROM DBA_USERS;
例4-25 管理者によるネットワーク・ホスト接続に関するユーザー権限のチェック
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 (SELECT HOST, LOWER_PORT, UPPER_PORT, ACL, ACLID,
DBMS_NETWORK_ACL_UTILITY.CONTAINS_HOST('www.us.example.com',
HOST) PRECEDENCE
FROM DBA_NETWORK_ACLS)
WHERE PRECEDENCE IS NOT NULL
ORDER BY PRECEDENCE DESC,
LOWER_PORT NULLS LAST,
UPPER_PORT NULLS LAST;
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-26は、ユーザーprestonによるホストwww.us.example.comのドメイン名の解決について、データベース管理者がユーザーの権限をチェックする方法を示しています。この例では、ポート範囲を指定せずにホストに割り当てられているアクセス制御リストのみが表示されています。これは、resolve権限はポート範囲が指定されているアクセス制御リストでは無効なためです。(CHECK_PRIVILEGE_ACLIDのuserパラメータに入力するユーザー名は、大/小文字が区別されることに注意してください。)
例4-26 管理者によるドメイン名解決権限のチェック
SELECT HOST, ACL,
DECODE(
DBMS_NETWORK_ACL_ADMIN.CHECK_PRIVILEGE_ACLID(ACLID, 'PRESTON',
'resolve'),
1, 'GRANTED', 0, 'DENIED', NULL) PRIVILEGE
FROM (SELECT HOST, LOWER_PORT, UPPER_PORT, ACL, ACLID,
DBMS_NETWORK_ACL_UTILITY.CONTAINS_HOST('www.us.example.com',
HOST) PRECEDENCE
FROM DBA_NETWORK_ACLS
WHERE LOWER_PORT IS NULL AND UPPER_PORT IS NULL)
WHERE PRECEDENCE IS NOT NULL
ORDER BY PRECEDENCE 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の場合、ユーザーはアクセス制御リストが自分に適用されないときは知る必要がないため、除外されます。言い換えるとOracle Databaseが提示するのは、Oracle Databaseによってアクセス権が明示的に付与または拒否されるネットワーク・ホスト上のユーザーのみです。そのため出力には、データベース管理者固有のDBA_NETWORK_ACLSビューからの出力に見られる*.example.comおよび*は表示されません。
次の各項では、データベース管理者による、ネットワーク接続とドメイン名解決に関するユーザー権限のチェック方法について例を示します。
ユーザーによる各自のネットワーク接続権限のチェック
例4-27は、ユーザーprestonが、www.us.example.comへの接続について、自分の権限をチェックする方法を示しています。
例4-27 ユーザーによるネットワーク・ホスト接続に関する権限のチェック
SELECT HOST, LOWER_PORT, UPPER_PORT, STATUS PRIVILEGE
FROM (SELECT HOST, LOWER_PORT, UPPER_PORT, STATUS,
DBMS_NETWORK_ACL_UTILITY.CONTAINS_HOST('www.us.example.com',
HOST) PRECEDENCE
FROM USER_NETWORK_ACL_PRIVILEGES
WHERE PRIVILEGE = 'connect')
WHERE PRECEDENCE IS NOT NULL
ORDER BY PRECEDENCE DESC,
LOWER_PORT NULLS LAST,
UPPER_PORT NULLS LAST;
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-26は、ユーザーprestonが、www.us.example.comのドメイン名の解決について、自分の権限をチェックする方法を示しています。
例4-28 ユーザーによるドメイン名解決権限のチェック
SELECT HOST, STATUS PRIVILEGE
from (SELECT HOST, STATUS,
DBMS_NETWORK_ACL_UTILITY.CONTAINS_HOST('www.us.example.com',
HOST) PRECEDENCE
FROM USER_NETWORK_ACL_PRIVILEGES
WHERE PRIVILEGE = 'resolve' AND
LOWER_PORT IS NULL AND UPPER_PORT IS NULL)
WHERE PRECEDENCE IS NOT NULL
ORDER BY PRECEDENCE DESC;
HOST PRIVILEGE
-------------------- ---------
www.us.example.com GRANTED
デフォルトでは、ユーザーとロールに対する権限は、そのユーザーとロールのアクセス制御リスト内での物理的な位置に基づいて付与または拒否されます。1番目にリストされているユーザーまたはロールに対して権限が最初に付与または拒否され、2番目にリストされているユーザーまたはロールが次に処理され、その後も順に処理されます。たとえば、例4-20のコードで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 権限とロールに関する情報を表示するデータ・ディクショナリ・ビュー
| ビュー | 説明 |
|---|---|
|
|
オブジェクト所有者、権限付与者または権限受領者が現行ユーザーまたは |
|
|
オブジェクト所有者または権限付与者が現行ユーザーである列オブジェクトの権限付与がリストされます。 |
|
|
権限受領者が現行ユーザーまたは |
|
|
権限受領者がユーザーまたは |
|
|
現行ユーザーが行ったオブジェクトの権限付与、または現行ユーザーが所有するオブジェクトに対する権限付与がすべてリストされます。 |
|
|
権限受領者がユーザーまたは |
|
|
データベース内の列オブジェクトの権限付与がすべて表示されます。 |
|
|
別のユーザー権限の使用が許可されたデータベース・アクセス記述子(DAD)が表示されます。 |
|
|
データベース内のすべてのオブジェクトに対するすべての権限付与がリストされます。 |
|
|
|
|
|
ユーザーとロールに直接付与されているロールがリストされます。 |
|
|
ユーザーとロールに付与されているシステム権限がリストされます。 |
|
|
他のロールに付与されているロールがリストされます。表示される情報は、ユーザーがアクセス可能なロールに関するもののみです。 |
|
|
ロールに付与されているシステム権限がリストされます。表示される情報は、ユーザーがアクセス可能なロールに関するもののみです。 |
|
|
ロールに付与されているオブジェクト権限がリストされます。表示される情報は、ユーザーがアクセス可能なロールに関するもののみです。 |
|
|
ユーザーに対して現在使用可能になっている権限がリストされます。 |
|
|
現在のユーザーに対して使用可能になっているすべてのロールがリストされます。 |
|
|
オブジェクト所有者、権限付与者または権限受領者が現行ユーザーである列オブジェクトの権限付与が表示されます。 |
|
|
オブジェクト所有者が現行ユーザーである列オブジェクトの権限付与が表示されます。 |
|
|
権限受領者が現行ユーザーである列オブジェクトの権限付与が表示されます。 |
|
|
別のユーザー権限の使用が許可されたデータベース・アクセス記述子(DAD)が表示されます。 |
|
|
現行ユーザーに直接付与されているロールがリストされます。 |
|
|
権限受領者が現行ユーザーであるすべてのオブジェクトの権限付与がリストされます。 |
|
|
現行ユーザーに付与されているシステム権限がリストされます。 |
|
|
現行ユーザーが所有しているすべてのオブジェクトの権限付与がリストされます。 |
|
|
権限受領者が現行ユーザーであるオブジェクトの権限付与がリストされます。 |
ここでは、これらのビューの使用例をいくつか示します。各例では、次の文がすでに発行されていることを前提としています。
CREATE ROLE security_admin IDENTIFIED BY password;
GRANT CREATE PROFILE, ALTER PROFILE, DROP PROFILE,
CREATE ROLE, DROP ANY ROLE, GRANT ANY ROLE, AUDIT ANY,
AUDIT SYSTEM, CREATE USER, BECOME USER, ALTER USER, DROP USER
TO security_admin WITH ADMIN OPTION;
GRANT SELECT, DELETE ON SYS.AUD$ TO security_admin;
GRANT security_admin, CREATE SESSION TO swilliams;
GRANT security_admin TO system_administrator;
GRANT CREATE SESSION TO jward;
GRANT SELECT, DELETE ON emp TO jward;
GRANT INSERT (ename, job) ON emp TO swilliams, jward;
|
関連項目: これらのデータ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。 |
次の問合せを実行すると、ロールとユーザーに対して付与されているシステム権限がすべて表示されます。
SELECT * FROM DBA_SYS_PRIVS; GRANTEE PRIVILEGE ADM -------------- --------------------------------- --- SECURITY_ADMIN ALTER PROFILE YES SECURITY_ADMIN ALTER USER YES SECURITY_ADMIN AUDIT ANY YES SECURITY_ADMIN AUDIT SYSTEM YES SECURITY_ADMIN BECOME USER YES SECURITY_ADMIN CREATE PROFILE YES SECURITY_ADMIN CREATE ROLE YES SECURITY_ADMIN CREATE USER YES SECURITY_ADMIN DROP ANY ROLE YES SECURITY_ADMIN DROP PROFILE YES SECURITY_ADMIN DROP USER YES SECURITY_ADMIN GRANT ANY ROLE YES SWILLIAMS CREATE SESSION NO JWARD CREATE SESSION NO
DBA_SYS_PRIVSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
次の問合せを実行すると、ユーザーと他のロールに対して付与されているロールがすべて表示されます。
SELECT * FROM DBA_ROLE_PRIVS; GRANTEE GRANTED_ROLE ADM ------------------ ------------------------------------ --- SWILLIAMS SECURITY_ADMIN NO
DBA_ROLE_PRIVSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
次の問合せを実行すると、特定のユーザーに対して付与されているオブジェクト権限(列固有の権限を除く)がすべて表示されます。
SELECT TABLE_NAME, PRIVILEGE, GRANTABLE FROM DBA_TAB_PRIVS
WHERE GRANTEE = 'jward';
TABLE_NAME PRIVILEGE GRANTABLE
----------- ------------ ----------
EMP SELECT NO
EMP DELETE NO
付与されている列固有の権限をすべて表示するには、次の問合せを使用します。
SELECT GRANTEE, TABLE_NAME, COLUMN_NAME, PRIVILEGE
FROM DBA_COL_PRIVS;
GRANTEE TABLE_NAME COLUMN_NAME PRIVILEGE
----------- ------------ ------------- --------------
SWILLIAMS EMP ENAME INSERT
SWILLIAMS EMP JOB INSERT
JWARD EMP NAME INSERT
JWARD EMP JOB INSERT
DBA_TAB_PRIVSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
次の問合せを実行すると、発行者が現在使用できるロールがすべてリストされます。
SELECT * FROM SESSION_ROLES;
ユーザーswilliamsに対してsecurity_adminロールが使用可能になっている場合に、この問合せを実行すると、Oracle Databaseから次の情報が戻されます。
ROLE ------------------------------ SECURITY_ADMIN
次の問合せを実行すると、発行者のセキュリティ・ドメインで現在使用可能なシステム権限がすべて表示されます。これには、明示的に付与されている権限と使用可能なロールから付与された権限の両方が含まれています。
SELECT * FROM SESSION_PRIVS;
ユーザーswilliamsに対してsecurity_adminロールが使用可能になっている場合に、この問合せを実行すると、Oracle Databaseから次の結果が戻されます。
PRIVILEGE ---------------------------------------- AUDIT SYSTEM CREATE SESSION CREATE USER BECOME USER ALTER USER DROP USER CREATE ROLE DROP ANY ROLE GRANT ANY ROLE AUDIT ANY CREATE PROFILE ALTER PROFILE DROP PROFILE
ユーザーswilliamsに対してsecurity_adminロールが使用禁止になっている場合、最初の問合せでは何も表示されず、2番目の問合せではCREATE SESSION権限の付与に関する行が1行のみ表示されます。
SESSION_ROLESビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
DBA_ROLESデータ・ディクショナリ・ビューを使用すると、データベースのすべてのロールと各ロールに対して使用されている認証を表示できます。たとえば、次の問合せを実行すると、データベース内のすべてのロールが表示されます。
SELECT * FROM DBA_ROLES; ROLE PASSWORD ---------------- -------- CONNECT NO RESOURCE NO DBA NO SECURITY_ADMIN YES
DBA_ROLESビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
ROLE_ROLE_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リファレンス』を参照してください。
