認可には、主に次の2つのプロセスがあります。
データへのアクセス、処理または変更を特定のユーザーにのみ許可します。
ユーザーによるアクセスまたは操作に様々な制限を適用します。ユーザーに適用(または除外)する制限は、スキーマ、表または行などのオブジェクトや、時間(CPU、接続またはアイドル時間)などのリソースに適用できます。
ユーザー権限とは、特定タイプのSQL文を実行する権利、別のユーザーのオブジェクトにアクセスする権利、PL/SQLパッケージを実行する権利などを指します。権限のタイプは、Oracle Databaseによって定義されています。
ロールは、ユーザー(通常は管理者)が権限や他のロールをグループ化するために作成します。ロールを使用すると、複数の権限またはロールをユーザーに簡単に付与できます。
ここでは、次の一般的なカテゴリについて説明します。
システム権限。この権限の受領者は、データベースで標準的な管理作業を実行できます。権限受領者は信頼できるユーザーのみに制限してください。システム権限の詳細は、「システム権限の管理」を参照してください。
ユーザー・ロール。ロールでは、複数の権限やロールがグループ化されるため、複数のユーザーに対して権限を同時に付与したり、取り消すことができます。ユーザーによるロールの使用を可能にするには、そのユーザーに対してロールを使用可能にしておく必要があります。詳細は、「ユーザー・ロールの管理」を参照してください。
オブジェクト権限。オブジェクトの各タイプには、オブジェクト権限が対応付けられています。異なるタイプのオブジェクト権限を管理する方法は、「オブジェクト権限の管理」を参照してください。
権限をユーザーに付与すると、そのユーザーはそれぞれの業務に必要な作業を実行できます。なお、権限は、必要な作業を実行する上でその権限が必要なユーザーにのみ付与してください。必要でない権限まで付与すると、セキュリティを維持できなくなる可能性があります。たとえば、管理作業を実行しないユーザーには、SYS
権限またはSYSDBA
権限を付与しないでください。
ユーザーは次の2つの方法で権限を受け取ることができます。
権限を明示的にユーザーに付与します。たとえば、employees
表にレコードを挿入する権限を、ユーザーpsmith
に明示的に付与できます。
権限をロール(名前付きの権限グループ)に付与した上で、そのロールを1人以上のユーザーに付与します。たとえば、employees
表からレコードを選択、挿入、更新および削除する権限を、clerk
という名前のロールに付与し、このロールをユーザーpsmith
やrobert
に付与できます。
ロールを使用することで権限の管理が容易になり、改善されるため、通常は権限を個々のユーザーではなくロールに付与してください。
この項の内容は、次のとおりです。
システム権限とは、特定のアクションを実行する権限、または特定のタイプのスキーマ・オブジェクトに対してアクションを実行する権限のことです。たとえば、表領域を作成する権限や、データベース内の任意の表から行を削除する権限などがシステム権限です。
システム権限には100以上の種類があります。各システム権限によって、ユーザーは特定のデータベース操作、またはあるクラスのデータベース操作を実行できます。システム権限は非常に強力な権限であることに注意してください。システム権限は、必要な場合のみ、データベースのロールと信頼できるユーザーに付与してください。システム権限の完全なリストとその詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
システム権限は非常に強力であるため、通常のユーザー(管理者以外)がデータ・ディクショナリに対してANY
システム権限(UPDATE ANY TABLE
など)を行使できないようにデータベースを構成する必要があります。システム権限の制限に関するその他のガイドラインは、「ユーザー・アカウントと権限の保護に関するガイドライン」を参照してください。
データ・ディクショナリを保護するには、O7_DICTIONARY_ACCESSIBILITY
初期化パラメータをFALSE
(デフォルト)に設定します。この機能を、ディクショナリ保護メカニズムと呼びます。
O7_DICTIONARY_ACCESSIBILITY
初期化パラメータは、Oracle Databaseリリース7からOracle8i以上のリリースにアップグレードした場合の、システム権限に対する制限を制御します。このパラメータをTRUE
に設定すると、SYS
スキーマ内のオブジェクトへのアクセスが可能になります(Oracle Databaseリリース7の動作)。ANY
権限はデータ・ディクショナリに適用されるため、ANY
権限を持つ不正なユーザーがデータ・ディクショナリ表にアクセスし、変更する危険性があります。
O7_DICTIONARY_ACCESSIBILTY
初期化パラメータを設定するには、init
SID
.ora
ファイルでそのパラメータを変更します。または、SYS
/AS SYSDBA
でSQL*Plusにログインし、ALTER SYSTEM
文を入力します。これは、サーバー・パラメータ・ファイル(SPFILE)を使用して、データベースを起動している場合を想定しています。
例4-1では、SQL*PlusのALTER SYSTEM
文を発行して、O7_DICTIONARY_ACCESSIBILTY
初期化パラメータをFALSE
に設定する方法を示しています。
例4-1 O7_DICTIONARY_ACCESSIBILITYのFALSEへの設定
ALTER SYSTEM SET O7_DICTIONARY_ACCESSIBILITY=FALSE SCOPE=SPFILE;
O7_DICTIONARY_ACCESSIBILITY
をFALSE
に設定すると、任意のスキーマのオブジェクトにアクセスできるシステム権限(たとえば、CREATE ANY PROCEDURE
などのANY
権限)では、SYS
スキーマ内のオブジェクトにアクセスできません。これは、SYS
スキーマ内のオブジェクト(データ・ディクショナリ・オブジェクト)へのアクセスが、SYS
で接続しているユーザーまたはSYSDBA
権限を使用して接続しているユーザーに制限されることを意味します。
前述のユーザー以外は、他のスキーマ内のオブジェクトへのアクセスを提供するシステム権限があっても、SYS
スキーマ内のオブジェクトにはアクセスできません。たとえば、SELECT ANY TABLE
権限を持つユーザーは、他のスキーマのビューや表にはアクセスできますが、ディクショナリ・オブジェクト(動的パフォーマンス・ビューの実表、通常のビュー、パッケージおよびシノニム)は選択できません。ただし、これらのユーザーは、明示的なオブジェクト権限を付与することで、SYS
スキーマ内のオブジェクトにアクセスできるようになります。
O7_DICTIONARY_ACCESSIBILITY
初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。
CREATE EXTERNAL JOB
権限は、データベースの外部でオペレーティング・システムのジョブを実行できるように、権限受領者ユーザーのスキーマ内に自動的に作成されます。この権限は、下位互換性を維持するためにCREATE JOB
権限を持つ既存のユーザーすべてにデフォルトで付与されます。セキュリティを強化するために、CREATE EXTERNAL JOB
権限は、SYS
、データベース管理者および必要なユーザーのみに付与してください。
明示的なオブジェクト権限のあるユーザーまたは管理権限で接続しているユーザー(SYSDBA
)は、SYS
スキーマ内のオブジェクトにアクセスできます。
表4-1に、SYS
スキーマ内のオブジェクトへのアクセスが必要なユーザーに対して付与できるロールをリストします。
表4-1 SYSスキーマ・オブジェクトにアクセスできるロール
ロール | 説明 |
---|---|
このロールを付与されたユーザーには、データ・ディクショナリ・ビューに対する |
|
このロールを付与されたユーザーには、データ・ディクショナリ内にあるパッケージとプロシージャに対する |
|
このロールを付与されたユーザーは、システム監査表( |
また、SYS
スキーマ内に作成された表へのアクセスが必要なユーザーには、SELECT ANY DICTIONARY
システム権限を付与できます。このシステム権限によって、SYS
スキーマ内に作成された、表などの任意のオブジェクトに対して問合せを実行できます。このシステム権限は、この権限を必要とする各ユーザーに個別に付与する必要があります。この権限はGRANT ALL PRIVILEGES
には含まれていませんが、ロールを介して付与できます。
注意: これらのロールおよび SELECT ANY DICTIONARY システム権限は、悪用されるとシステムの整合性が損なわれる危険があるため、付与する際には十分な注意が必要です。 |
システム権限は、ユーザーとロールに対して付与したり、取り消すことができます。システム権限をロールに付与すると、そのロールを使用してシステム権限を行使できます。たとえば、ロールを使用すると権限を選択的に使用できるようになります。「ロールの保護に関するガイドライン」で説明する業務分離のガイドラインに従っていることを確認してください。
ユーザーやロールに対するシステム権限の付与と取消しには、次のいずれかの方法を使用します。
SQL文のGRANT
およびREVOKE
Oracle Enterprise Manager Database Control
他のユーザーにシステム権限を付与したり、他のユーザーのシステム権限を取り消すことができるのは、次のタイプのユーザーのみです。
ADMIN
OPTION
によって特定のシステム権限を付与されているユーザー
GRANT
ANY
PRIVILEGE
システム権限を付与されているユーザー
そのため、これらの権限は信頼できるユーザーにのみ付与してください。
ANY
キーワードを使用するシステム権限を使用すると、データベース内のオブジェクトのカテゴリ全体に対して権限を設定できます。たとえば、CREATE ANY PROCEDURE
システム権限を使用すると、ユーザーはデータベース内のどこにでもプロシージャを作成できます。ANY
権限を持つユーザーが作成したオブジェクトの動作は、そのオブジェクトが作成されたスキーマに限定されません。たとえば、ユーザーMALCOEUR
にはCREATE ANY PROCEDURE
権限があり、プロシージャをスキーマJONES
に作成すると、そのプロシージャはJONES
として実行されることになります。ただし、JONES
はMALCOEUR
によって作成されたプロシージャがJONES
として機能していることに気付かない可能性があります。JONES
にDBA
権限が付与されている場合は、MALCOEUR
がJONES
としてプロシージャを実行することで、セキュリティ違反が発生する可能性があります。
PUBLIC
権限は、Oracleデータベースのすべてのユーザーに付与され、ロールに付与したり、ユーザーとして付与することができます。PUBLIC
権限を使用して作成されたオブジェクトは誰でもアクセスできるため、ANY
オブジェクトと同様にセキュリティ上のリスクが発生する可能性があります。たとえば、CREATE PUBLIC SYNONYM
権限が付与されているMALCOEUR
は、誰でも使用することがわかっているインタフェースを再定義し、作成したPUBLIC SYNONYM
でそのインタフェースを指し示すことができます。ユーザーは、正しいインタフェースにアクセスするかわりに、MALCOEUR
が作成したインタフェースにアクセスすることになります。その結果、ユーザーのログイン資格証明の盗用などの不正な活動が実行される可能性があります。
このように、この種の権限は非常に強力であるため、不適切な個人に付与するとセキュリティ上のリスクが発生する可能性があります。ANY
またはPUBLIC
を使用した権限の付与には注意が必要です。他のすべての権限と同様に、これらの権限をユーザーに付与する場合は、「最低限の権限」を付与する原則に従ってください。
ANY
権限を持つユーザーに対してSYS
のデータ・ディクショナリを保護するには、O7_DICTIONARY_ACCESSIBILITY
初期化パラメータをFALSE
に設定します。このパラメータは、ALTER SYSTEM文(例4-1「O7_DICTIONARY_ACCESSIBILITYのFALSEへの設定」を参照)を使用するか、またはinit
SID
.ora
ファイルを変更することで設定できます。その他のガイドラインは、「データベースのインストールと構成の保護に関するガイドライン」を参照してください。
ロールを使用すると、権限の管理と制御が容易になります。ロールは、関連する権限のグループに名前を付けたもので、ユーザーや他のロールに付与します。各ロール名はデータベース内で一意にする必要があり、どのユーザー名または他のどのロール名とも同一にはできません。スキーマ・オブジェクトとは異なり、ロールはスキーマに含まれているわけではありません。そのため、ロールを作成したユーザーを削除しても、そのロールに影響はありません。
この項の内容は、次のとおりです。
ロールには、システム権限またはスキーマ・オブジェクト権限を付与できます。
1つのロールを別のロールに付与できます。ただし、ロールをそのロール自体に付与したり、循環的に付与することはできません。たとえば、ロールB
があらかじめロールA
に付与されている場合、ロールA
をロールB
に付与することはできません。
任意のロールを任意のデータベース・ユーザーに付与できます。
ユーザーに付与した各ロールは、任意の時点で使用可能または使用禁止にできます。ユーザーのセキュリティ・ドメインには、そのユーザーに対して現在使用可能になっているすべてのロールの権限が含まれており、ユーザーに対して現在使用禁止になっているロールの権限は除外されています。権限を選択的に使用できるように、Oracle Databaseでは、データベース・アプリケーションとユーザーがロールを使用可能または使用禁止にできます。
間接的に付与されたロールとは、ロールに対して付与されたロールのことです。この種のロールは、ユーザーに対して明示的に使用可能または使用禁止にできます。ただし、別のロールを含んだロールを使用可能にすると、直接的に付与されたロールに含まれる間接的に付与されたロールは、すべて暗黙のうちに使用可能になります。
表4-2では、データベース内での権限管理をさらに容易にする、ロールの特性について説明します。
表4-2 ロールの特性とその説明
特性 | 説明 |
---|---|
権限管理に要する労力の削減 |
複数のユーザーに対して同一の権限セットを明示的に付与するかわりに、関連するユーザー・グループのための権限をまとめて1つのロールに付与しておき、そのグループの各メンバーにはそのロールを付与するだけですみます。 |
動的な権限管理 |
あるグループの権限を変更する必要がある場合、修正が必要なのは、そのロールの権限のみです。グループのロールを付与した全ユーザーのセキュリティ・ドメインには、そのロールに対して加えられる変更が自動的に反映されます。 |
権限の選択的な可用性 |
あるユーザーに付与したロールを、選択的に使用可能または使用禁止にできます。この機能によって、どのような状況でもユーザー権限を個々に制御できます。 |
アプリケーションによる認識 |
ロールの存在はデータ・ディクショナリに記録されます。したがって、ユーザーが特定のユーザー名でアプリケーションを実行したときに、アプリケーションがディクショナリに問い合せ、自動的に特定のロールを使用可能(または使用禁止)にするようにアプリケーションを設計できます。 |
アプリケーション固有のセキュリティ |
ロールの使用はパスワードを使用して保護できます。正しいパスワードを入力するとロールが使用可能になるようなアプリケーションを作成できます。パスワードを知らないユーザーは、ロールを使用可能にできません。 |
データベース・アプリケーションについてのロールは、通常、データベース管理者が作成します。管理者は、アプリケーションの実行に必要なすべての権限をセキュア・アプリケーション・ロールに付与します。その後、このセキュア・アプリケーション・ロールを別のロールや特定のユーザーに付与できます。アプリケーションは複数の異なるロールを持つことができます。各ロールには、アプリケーションの使用時におけるデータ・アクセスの量を考慮して、異なる権限の集合を付与します。
DBAはパスワード付きのロールを作成することで、そのロールに付与されている権限が無許可で使用されるのを防止できます。通常、アプリケーションは起動時に適切なロールが使用可能になるように設計されます。そのため、アプリケーション・ユーザーは、アプリケーション・ロールのパスワードを知る必要がありません。
データベース・アプリケーションに対する権限の管理(「アプリケーション・ロールの一般的な使用方法」を参照)
ユーザー・グループに対する権限の管理(「ユーザー・ロールの一般的な使用方法」を参照)
図4-1とその後の各項で、ロールの2通りの使用方法について説明します。
アプリケーション・ロールには、特定のデータベース・アプリケーションを実行するために必要な権限をすべて付与します。次に、そのセキュア・アプリケーション・ロールを、他のロールや特定のユーザーに対して付与します。1つのアプリケーションに対して複数の異なるロールを設定し、アプリケーション使用時のデータ・アクセスの量や範囲にあわせて異なる権限セットを各ロールに割り当てることができます。
各ロールと各ユーザーには、それぞれ独自のセキュリティ・ドメインがあります。ロールのセキュリティ・ドメインには、ロール自体に付与されている権限と、そのロールに付与されたロールに対して付与されている権限が含まれます。
ユーザーのセキュリティ・ドメインには、対応するスキーマ内のすべてのスキーマ・オブジェクトの権限、そのユーザーに付与されている権限、およびそのユーザーに付与されている現在使用可能なロールの権限が含まれます(1つのロールをあるユーザーに対して使用可能にし、別のユーザーに対しては使用禁止にすることもできます)。このドメインには、ユーザー・グループPUBLIC
に対して付与されている権限とロールも含まれます。PUBLIC
ユーザー・グループは、データベース内のすべてのユーザーを表します。
PL/SQLブロック内でのロールの使用方法は、そのブロックが無名ブロックであるか、名前付きブロック(ストアド・プロシージャ、ファンクションまたはトリガー)であるか、および定義者権限または実行者権限のどちらで実行されるかによって異なります。
定義者権限で実行される名前付きPL/SQLブロック(ストアド・プロシージャ、ファンクションまたはトリガー)では、すべてのロールは使用禁止になっています。ロールは権限チェックに使用されず、定義者権限プロシージャ内ではロールを設定できません。
SESSION_ROLES
ビューには、現在使用可能なすべてのロールが表示されます。定義者権限で実行される名前付きPL/SQLブロックでSESSION_ROLES
を問い合せると、その問合せは行を戻しません。
ユーザーがDDL文を正常に実行するには、その文に応じて1つ以上の権限が必要になります。たとえば、表を作成するには、CREATE
TABLE
またはCREATE
ANY
TABLE
システム権限が必要です。別のユーザーに属する表のビューを作成するには、CREATE VIEW
またはCREATE
ANY
VIEW
システム権限のみでなく、その表に対するSELECT
object
権限またはSELECT
ANY
TABLE
システム権限も必要です。
Oracle Databaseでは、特定のDDL文での特定の権限の使用を制限することで、ロールを介して受け取った権限への依存性を回避します。次の規則は、DDL文に関する権限の制限を示しています。
DDL操作の実行をユーザーに許可するすべてのシステム権限およびスキーマ・オブジェクト権限は、ロールを介して受け取った場合でも使用可能。次に例を示します。
システム権限: CREATE
TABLE
、CREATE
VIEW
およびCREATE
PROCEDURE
権限
スキーマ・オブジェクト権限: 表に対するALTER
およびINDEX
権限
DDL文の発行に必要なDML操作の実行をユーザーに許可するすべてのシステム権限およびオブジェクト権限は、ロールを介して受け取った場合は使用不可。たとえば、表に対するSELECT
ANY
TABLE
システム権限やSELECT
object
権限がロールを介して付与されているユーザーは、それらの権限では別のユーザーに属する表のビューを作成できません。
ロールを介して受け取った権限の使用許可と使用制限について、次の例で具体的に説明します。
次のようなユーザーを想定します。
CREATE
VIEW
システム権限を持つロールが付与されています。
employees
表に対するSELECT
object
権限を持つロールが付与されていますが、employees
表に対するSELECT
object
権限は間接的な付与となります。
departments
表に対するSELECT
object
権限が直接付与されています。
前述の権限がこのユーザーに直接的および間接的に付与されているとすると、
このユーザーはemployees
表とdepartments
表の両方に対してSELECT
文を発行できます。
このユーザーには、employees
表のCREATE
VIEW
権限とSELECT
権限がロールを介して付与されていますが、employees
表のSELECT
object
権限がロールを介して付与されていたため、employees
表に基づいた使用可能なビューは作成できません。作成されたビューにアクセスすると、エラーになります。
このユーザーにはCREATE
VIEW
権限がロールを介して付与され、departments
表のSELECT
権限が直接付与されているため、departments
表のビューは作成できます。
環境によっては、オペレーティング・システムを使用してデータベース・セキュリティを管理できます。オペレーティング・システムを使用して、データベース・ロールの付与と取消し、パスワードの認証を管理できます。この機能は、すべてのオペレーティング・システムで利用できるとはかぎりません。
関連項目: オペレーティング・システムによるロールの管理方法の詳細は、そのオペレーティング・システム固有のOracle Databaseマニュアルを参照してください。 |
Oracle Databaseには、データベース管理を容易にする一連の事前定義ロールが用意されています。 表4-3に示すこれらのロールは、データベース作成の一部である標準スクリプトの実行時に、Oracleデータベースに対して自動的に定義されます。他のオプションや製品をインストールすると、他の事前定義のロールが作成される場合があります。ユーザー定義のロールと同様に、これらの事前定義ロールに対しても、権限とロールの付与および取消しができます。
表4-3 Oracle Databaseの事前定義ロール
注意: インストールごとに独自のロールを作成し、必要な権限のみを割り当てる必要があります。これにより、使用している権限を詳細に制御できます。この処理により、Oracle Databaseが定義するロールをOracle Databaseが変更または削除するたびに、既存のロール、権限またはプロシージャを調整する必要もなくなります。たとえば、 CONNECT ロールが現在保持している権限は、CREATE SESSION のみです。CONNECT およびRESOURCE の各ロールはともに、将来のOracle Databaseのリリースでは使用不可になる予定です。 |
ロールはCREATE ROLE
文を使用して作成できますが、そのためにはCREATE ROLE
システム権限が必要です。通常、このシステム権限はセキュリティ管理者のみが持っています。
注意: 作成した直後のロールには、対応付けられた権限はありません。新しいロールに権限を対応付けるには、その新しいロールに権限や他のロールを付与する必要があります。 |
作成する各ロールには、データベースの既存のユーザー名やロール名とは異なる、一意の名前を指定する必要があります。ロールはどのユーザーのスキーマ内にも格納されません。マルチバイト・キャラクタ・セットを使用するデータベースでは、各ロール名に少なくとも1つのシングルバイト・キャラクタを含めることをお薦めします。ロール名がマルチバイト・キャラクタのみの場合、暗号化されたロール名とパスワードの組合せの安全性は大幅に低くなります。パスワードのガイドラインは、「パスワードの保護に関するガイドライン」のガイドライン1を参照してください。
例4-2では、clerk
ロールを作成しています。
IDENTIFIED BY
句は、このロールを付与された特定ユーザーがロールを使用する前に、どの認可方式で認可される必要があるかを指定します。この句を指定しないか、またはNOT IDENTIFIED
を指定すると、認可がなくてもロールが使用可能になります。ロールには、必要な認可方式として次の方式を指定できます。
パスワードを使用したデータベースによる認可
指定のパッケージを使用したアプリケーションによる認可
オペレーティング・システム、ネットワークまたはその他の外部ソースによる外部認可
エンタープライズ・ディレクトリ・サービスによるグローバル認可
これらの認可については、次の各項で説明します。
ロールの認可方式を設定または変更するには、ALTER ROLE
文を使用します。
例4-3は、clerk
ロールの変更方法を示しています。これによって、ロールを使用可能にするには、ユーザーが外部ソースによって認可されている必要があることが指定されます。
ロールの認可方式を変更するには、ALTER ANY ROLE
システム権限またはADMIN OPTION
付きのロールが付与されている必要があります。
ここでは、ロールの認可方式について説明します。ロールを使用するには、ユーザーに対してロールを使用可能にする必要があります。
この項の内容は、次のとおりです。
データベースによって認可されたロールは、そのロールにパスワードを割り当てることで保護できます。パスワードで保護されたロールがユーザーに付与されている場合、そのロールは、適切なパスワードをSET ROLE
文で指定することで、使用可能または使用禁止にできます。ただし、ロールがデフォルト・ロールで、接続時に使用可能な場合は、パスワードの入力は不要です。
例4-2「パスワードによって認可されるユーザー・ロールの作成」は、clerk
というロールを作成するCREATE ROLE
文を示しています。このロールを使用可能にするには、パスワードmorework2do
を入力する必要があります。
注意: マルチバイト・キャラクタ・セットを使用するデータベースの場合も、ロールのパスワードにはシングルバイト・キャラクタのみを使用してください。マルチバイト・キャラクタのパスワードは受け入れられません。パスワードのガイドラインは、「パスワードの保護に関するガイドライン」のガイドライン1を参照してください。 |
アプリケーション・ロール(セキュア・アプリケーション・ロール)を使用可能にできるのは、認可されたPL/SQLパッケージを使用するアプリケーションのみです。アプリケーション開発者は、アプリケーション内部にパスワードを埋め込むことによってロールを保護する必要はありません。かわりに、アプリケーション・ロールを作成して、ロールを使用可能にすることを認可するPL/SQLパッケージを指定できます。
認可されたPL/SQLパッケージによって使用可能になるロールを作成するには、CREATE ROLE
SQL文でIDENTIFIED USING
package_name
句を使用します。
例4-4では、ロールadmin_role
がアプリケーション・ロールであり、このロールは、PL/SQLパッケージhr.admin
内に定義されているモジュールによってのみ使用可能にできることを示しています。
ログイン時に、ユーザー・プロファイルで指定されたユーザーのデフォルト・ロールを使用可能にすると、アプリケーション・ロールはチェックされません。
セキュア・アプリケーション・ロールの詳細は、次の各項を参照してください。
オペレーティング・システムまたはネットワーク・クライアントによって認可されるロールを作成できます。
例4-5では、accts_rec
という名前のロールを作成しています。このロールを使用可能にするには、その前に、ユーザーが外部ソースによって認可されている必要があります。
オペレーティング・システムによるロール認証が有効となるのは、そのオペレーティング・システムによって、オペレーティング・システム権限をアプリケーションと動的にリンクできる場合のみです。ユーザーがアプリケーションを開始すると、オペレーティング・システムはオペレーティング・システム権限をそのユーザーに付与します。付与されたオペレーティング・システム権限は、アプリケーションに対応付けられたロールと一致します。この時点で、アプリケーションはアプリケーション・ロールを使用可能にできます。アプリケーションが終了すると、先に付与されたオペレーティング・システム権限は、そのユーザーのオペレーティング・システム・アカウントから取り消されます。
ロールをオペレーティング・システムによって認可する場合は、オペレーティング・システム・レベルで各ユーザーの情報を構成する必要があります。この操作は、オペレーティング・システムによって異なります。
ロールがオペレーティング・システムによって付与されている場合は、そのオペレーティング・システムによるロールの認可は不要です。
ユーザーがOracle Netを介してデータベースに接続する場合、デフォルトでは、そのユーザーのロールはオペレーティング・システムによって認証できません。これには、共有サーバー構成による接続が含まれます。共有サーバー構成での接続はOracle Netを必要とするためです。リモート・ユーザーはネットワーク接続を介して別のオペレーティング・システム・ユーザーになりすますおそれがあるため、デフォルトでこのような制限が適用されています。REMOTE_OS_ROLES
はFALSE
(デフォルト)に設定することをお薦めします。
このようなセキュリティの危険性の心配がないときに、ネットワーク・クライアントに対してオペレーティング・システムのロール認証を使用する場合は、データベース初期化パラメータ・ファイル内の初期化パラメータREMOTE_OS_ROLES
をTRUE
に設定します。この変更は、次回インスタンスを起動して、データベースをマウントするときに有効となります。
ロールはグローバル・ロールとして定義できます。この場合、そのロールを使用するために(グローバル)ユーザーはエンタープライズ・ディレクトリ・サービスによる認可を受ける必要があります。グローバル・ロールは、権限とロールを付与することによってデータベース内でローカルに定義しますが、グローバル・ロール自体をそのデータベース内のユーザーや他のロールに付与することはできません。グローバル・ユーザーがデータベースへの接続を試みると、エンタープライズ・ディレクトリへの問合せが実行され、そのユーザーに対応付けられたグローバル・ロールが取得されます。
例4-6では、グローバル・ロールを作成しています。
グローバル・ロールは、エンタープライズ・ユーザー・セキュリティの構成要素の1つです。グローバル・ロールは1つのデータベースにのみ適用されますが、エンタープライズ・ディレクトリに定義されたエンタープライズ・ロールに付与できます。エンタープライズ・ロールは複数データベースのグローバル・ロールを含んだディレクトリ構造であり、エンタープライズ・ユーザーに付与できます。
ユーザーのグローバル認証とグローバル認可、およびエンタープライズ・ユーザー管理におけるロールの概要については、「グローバルなユーザー認証と認可の構成」を参照してください。
ロールには、システム権限またはスキーマ・オブジェクト権限を付与できます。任意のロールを任意のデータベース・ユーザーまたは別のロールに付与できます。ただし、ロールをそのロール自体に付与することはできません。また、ロールを循環的に付与することもできません。つまり、ロールY
があらかじめロールX
に付与されている場合、ロールX
をロールY
に付与することはできません。
権限を選択的に使用できるように、Oracle Databaseでは、データベース・アプリケーションとユーザーがロールを使用可能または使用禁止にできます。ユーザーに付与した各ロールは、任意の時点で使用可能または使用禁止にできます。ユーザーのセキュリティ・ドメインには、そのユーザーに対して現在使用可能になっているすべてのロールの権限が含まれており、ユーザーに対して現在使用禁止になっているロールの権限は除外されています。
ロールに対して付与されたロールは、間接的に付与されたロールと呼ばれます。この種のロールは、ユーザーに対して明示的に使用可能または使用禁止にできます。ただし、別のロールを含んだロールを使用可能にすると、直接的に付与されたロールに含まれる間接的に付与されたロールは、すべて暗黙のうちに使用可能になります。
ユーザーや別のロールに対してロールを付与したり、取り消すには、次のいずれかの方法を使用します。
ロールに対して権限を付与または取り消す場合にも同じオプションを使用します。
GRANT
ANY
ROLE
システム権限があるユーザーは、グローバル・ロールを除き、他のユーザーの任意のロールまたはデータベースのロールを付与したり、取り消すことができます。(グローバル・ロールは、Oracle Internet Directoryなどのディレクトリで管理されますが、グローバル・ロールの権限は単一のデータベース内に格納されます)。デフォルトでは、この権限はSYS
またはSYSTEM
ユーザーに付与されます。このシステム権限は非常に強力であるため、付与する際は注意が必要です。
ADMIN
OPTION
付きでロールを付与されたユーザーは、データベースの他のユーザーやロールに対してロールを付与したり、そのロールを取り消すことができます。つまり、このオプションによって、選択的なロールの管理が可能になります。
状況によっては、データベースからロールを削除した方がよい場合があります。削除したロールを付与されていたすべてのユーザーとロールのセキュリティ・ドメインは、削除したロール権限がなくなったことを反映するために、ただちに変更されます。削除したロールによって間接的に付与されていたロールもすべて、関連するセキュリティ・ドメインから削除されます。ロールを削除することによって、すべてのユーザーのデフォルト・ロール・リストからそのロールが自動的に削除されます。
オブジェクトの作成はロールを介して受け取った権限に依存しないため、ロールが削除されても、表や他のオブジェクトは削除されません。
ロールは、SQL文DROP ROLE
を使用して削除します。ロールを削除するには、DROP ANY ROLE
システム権限またはADMIN OPTION
付きのロールが付与されている必要があります。
DROP ROLE clerk;
この項では、SQL*Plusユーザーによるデータベース・ロールの使用を制限する機能について説明します(これによって、セキュリティに関わる深刻な問題を回避できます)。
事前作成データベース・アプリケーションは、アプリケーション使用中にユーザー・ロールを使用可能および使用禁止にすることも含めて、ユーザーのアクションを明示的に制御します。一方、SQL*Plusなどの非定型の問合せツールを使用すると、ユーザーは付与されたロールを使用可能および使用禁止にする文も含めて、あらゆるSQL文を発行できます(正常終了する場合としない場合があります)。
アプリケーションのユーザーは、そのアプリケーションに付加された権限を使用し、非定型ツールによってデータベース表に破壊的なSQL文を発行する恐れがあります。
たとえば、次の使用例を考えてみます。
Vacation(休暇)アプリケーションには、それに対応するvacation
ロールがあります。
このvacation
ロールには、emp_tab
表に対してSELECT
、INSERT
、UPDATE
およびDELETE
文を発行する権限が含まれています。
Vacationアプリケーションは、vacation
ロールを介して取得した権限の使用を制御します。
ここで、vacation
ロールを付与されたユーザーを考えてみます。このユーザーが、Vacationアプリケーションを使用するかわりに、SQL*Plusを実行するとします。この時点でユーザーが制限を受けるのは、明示的に付与された権限またはロール(vacation
ロールを含む)を介して付与されている権限からのみです。SQL*Plusは非定型の問合せツールであるため、設計されたデータベース・アプリケーションを使用する場合のように、ユーザーは一連の事前定義アクションに制限されることはありません。ユーザーは、emp_tab
表のデータの問合せや変更を自由に実行できます。
SQL*Plus環境で特定のSQLおよびSQL*Plusコマンドをユーザーごとに使用禁止にするには、PRODUCT_USER_PROFILE
表を使用します。この表はSYSTEM
スキーマにあります。Oracle DatabaseではなくSQL*Plusが、このセキュリティを規定します。GRANT
、REVOKE
およびSET ROLE
コマンドへのアクセスを制限して、ユーザーによるデータベース権限の変更を制御することもできます。
PRODUCT_USER_PROFILE
表を使用すると、ユーザーがアプリケーションでアクティブにできないロールをリストできます。また、様々なコマンド(SET ROLE
など)の使用を明示的に禁止できます。
たとえば、PRODUCT_USER_PROFILE
表にエントリを作成して、次の処理を実行できます。
SQL*Plusで、clerk
およびmanager
ロールの使用を禁止できます。
SQL*Plusで、SET ROLE
の使用を禁止できます。
ユーザーMarlaが、SQL*Plusを使用してデータベースに接続するとします。Marlaには、clerk
、manager
およびanalyst
のロールがあります。前述のPRODUCT_USER_PROFILE
のエントリによって、Marlaは、SQL*Plusでanalyst
ロールのみを使用できます。また、MarlaがSET ROLE
文を発行しようとすると、PRODUCT_USER_PROFILE
表にあるエントリによってSET ROLE
の使用が禁止されているため、Marlaによるこの文の発行は明示的に禁止されます。
PRODUCT_USER_PROFILE
表は、様々な理由からセキュリティが完全には保証されないことに注意してください。前述の例では、SET ROLE
がSQL*Plusで禁止されていますが、Marlaに直接付与されているその他の権限がある場合、MarlaはSQL*Plusを使用してそれらの権限を使用できます。
ストアド・プロシージャは、ビジネス・ロジックによって権限の使用をカプセル化し、適正なビジネス・トランザクションのコンテキストでのみ権限が実行されるようにします。たとえば、アプリケーション開発者は、employees
表にある従業員の名前および住所を、通常の勤務時間内にのみ更新するプロシージャを作成できます。また、セキュリティ管理者は、人事部門の担当者にemployees
表のUPDATE
権限を付与するのではなく、プロシージャのみに権限を付与できます。これによって、人事部門の担当者が権限を使用できるのはプロシージャのコンテキスト内のみになり、employees
表を直接更新できなくなります。
セキュア・アプリケーション・ロールは、認可されたPL/SQLパッケージ(またはプロシージャ)でのみ使用可能にできるロールです。PL/SQLパッケージ自体には、アプリケーションへのアクセスを制御するために必要なセキュリティ・ポリシーが反映されます。
この方法でロールを作成すると、アプリケーションを起動するロールの有効化が制限されます。たとえば、アプリケーションはユーザーがプロキシを介して接続しているかどうかをチェックするなど、認証およびカスタマイズ認可を実行できます。
このタイプのロールでは、パスワードがアプリケーションのソース・コードに埋め込まれたり、表に格納されることがないため、セキュリティが強化されます。このように、データベースが実行する処理は、セキュリティ・ポリシーの実装に基づいており、その定義は1箇所(アプリケーション内ではなくデータベース内)に格納されます。ポリシーの変更が必要な場合は、アプリケーションを修正することなく1箇所の変更で済みます。ポリシーはロールと結び付けられているため、データベースに接続するユーザー数に関係なく、結果は常に同じです。
セキュア・アプリケーション・ロールを使用可能にするには、ユーザーがセキュア・アプリケーション・ロールによって付与された権限の使用を必要とする前のログイン時に、基礎となるパッケージをアプリケーションから直接起動して実行する必要があります。ログイン・トリガーを使用してセキュア・アプリケーション・ロールを使用可能にすることはできません。
セキュア・アプリケーション・ロールを使用可能にすると、認可されたPL/SQLパッケージがコール・スタックにあることが検証されます。つまり、認可されたPL/SQLパッケージがロールを使用可能にするコマンドを発行しているかどうかが検証されます。また、デフォルトのユーザー・ロールを使用可能にすると、アプリケーション・ロールに対するチェックは実行されません。したがって、ロールを付与する前にセキュリティ・ポリシーによるチェックが実行されるように、セキュア・アプリケーション・ロールをユーザーのデフォルト・ロールにしないことが重要です。
セキュア・アプリケーション・ロールは、データベース接続を保証するために使用できます。セキュア・アプリケーション・ロールはパッケージによって実装されるロールであるため、このパッケージによって、ユーザーが中間層を介して、または特定のIPアドレスからデータベースに接続できることを検証できます。この方法により、セキュア・アプリケーション・ロールは、ユーザーがアプリケーション外のデータにアクセスすることを防ぎます。ユーザーは、付与されているアプリケーション権限のフレームワーク内で作業するように規定されます。
この項の内容は、次のとおりです。
オブジェクト権限は、特定のタイプのSQL文を実行するか、または別のユーザーのオブジェクトにアクセスするための権利です。たとえば、次のことをする権利が権限です。
データベースへの接続(セッションの作成)
表の作成
他のユーザーの表からの行の選択
他のユーザーのストアド・プロシージャの実行
オブジェクトの各タイプには、異なるオブジェクト権限が対応付けられています。
ALL
[PRIVILEGES
]を指定すると、オブジェクトに対して使用可能なすべてのオブジェクト権限を付与したり、取り消すことができます。ALL
は権限ではなくショートカットです。つまり、GRANT
文およびREVOKE
文において1語ですべてのオブジェクト権限を付与したり、取り消すための手段です。ALL
を使用してすべてのオブジェクト権限を付与した場合も、権限を個別に取り消すことができます。
同様に、個別に付与した権限をALL
を指定してすべて取り消すこともできます。ただし、REVOKE ALL
によって整合性制約が削除される場合(整合性制約は取り消そうとしているREFERENCES
権限に依存しているため)は、REVOKE
文にCASCADE CONSTRAINTS
オプションを指定する必要があります。
例4-7では、CASCADE CONSTRAINTS
を使用してHR
スキーマ内の注文表に対するすべての権限を取り消しています。
A スキーマ・オブジェクト権限とは、特定のスキーマ・オブジェクトに対して特定のアクションを実行する権限です。
各タイプのスキーマ・オブジェクトごとに、異なるオブジェクト権限があります。オブジェクト権限の例には、departments
表から行を削除する権限があります。
クラスタ、索引、トリガー、データベース・リンクなど、一部のスキーマ・オブジェクトには、対応付けられたオブジェクト権限がありません。これらのオブジェクトの使用は、システム権限によって決定されます。たとえば、クラスタを変更するには、ユーザーはそのクラスタを所有しているか、またはALTER
ANY
CLUSTER
システム権限が必要です。
次の各項では、このような権限の付与と取消しについて説明します。
次の各項では、特定のスキーマ・オブジェクトに適用されるオブジェクト権限について説明します。
スキーマ・オブジェクト権限は、ユーザーとロールに対して付与したり、取り消すことができます。オブジェクト権限をロールに付与した場合は、その権限を選択的に使用可能にできます。
ユーザーとロールに対するオブジェクト権限の付与と取消しには、次のいずれかを使用できます。
SQL文のGRANT
およびREVOKE
Oracle Enterprise Manager Database Control
ユーザーは、自分のスキーマに含まれているスキーマ・オブジェクトに関しては、すべてのオブジェクト権限が自動的に付与されています。ユーザーは、自分が所有するスキーマ・オブジェクトに対するオブジェクト権限を、他のユーザーやロールに付与できます。GRANT
ANY
OBJECT
PRIVILEGE
があるユーザーは、GRANT
文のGRANT
OPTION
句を使用してもしなくても、他のユーザーに対して指定のオブジェクト権限を付与したり取り消すことができます。この句を指定しない場合、権限受領者はその権限を使用できますが、別のユーザーには付与できません。
スキーマ・オブジェクトとそのシノニムは、権限に関しては等価です。つまり、表、ビュー、順序、プロシージャ、ファンクションまたはパッケージについて付与されるオブジェクト権限は、その基礎となるオブジェクトを名前で参照するかシノニムを使用するかにかかわらず、適用されます。
たとえば、jward.emp
という表にjward.employee
というシノニムがあると仮定します。ユーザーjward
が次の文を発行するとします。
GRANT SELECT ON emp TO swilliams;
ユーザーswilliams
は、名前またはシノニムjward.employee
を使用して表を参照することによって、jward.emp
を問い合せることができます。
SELECT * FROM jward.emp; SELECT * FROM jward.employee;
表、ビュー、順序、プロシージャ、ファンクションまたはパッケージに対するオブジェクト権限を、そのオブジェクトのシノニムに付与した場合の結果は、シノニムを使用しない場合と同じです。たとえば、jward
がemp
表に対するSELECT
権限をswilliams
に付与する場合、jward
は次のどちらの文でも使用できます。
GRANT SELECT ON emp TO swilliams; GRANT SELECT ON employee TO swilliams;
シノニムが削除された場合は、そのシノニムを指定して権限が付与されていた場合でも、基礎になるスキーマ・オブジェクトに対して付与された権限はすべて有効なままです。
表に対するスキーマ・オブジェクト権限によって、DML(データ操作言語)またはDDL(データ定義言語)操作レベルでの表のセキュリティが実現します。
次の各項では、表に対する権限とDMLおよびDDL操作について説明します。
表またはビューでDELETE
、INSERT
、SELECT
およびUPDATE
の各DML操作を使用する権限を付与できます。これらの権限は、表のデータの問合せや操作が必要なユーザーとロールに対してのみ付与してください。
表に対するINSERT
権限とUPDATE
権限は、表の特定の列に制限できます。選択的なINSERT
権限を付与されたユーザーは、選択した列に値を持つ行を挿入できます。他のすべての列には、NULL
またはその列のデフォルト値が挿入されます。選択的なUPDATE
権限によって、ユーザーは行の特定の列に限ってその値を更新できます。機密データに対するユーザー・アクセスを制限するには、INSERT
権限とUPDATE
権限を選択的に使用します。
たとえば、データ入力ユーザーにemployees
表のsalary
列を変更させないようにするには、そのsalary
列を除外した選択的なINSERT
権限またはUPDATE
権限を付与できます。また、salary
列を除外したビューによって、同じ制限をさらに高いセキュリティ・レベルで実現できます。
ALTER
、INDEX
およびREFERENCES
の各権限は、表に対するDDL操作の実行を許可します。これらの権限によって、他のユーザーは表への依存性を変更または作成できるため、権限の付与は控えめに行う必要があります。
表に対してDDL操作を実行するユーザーには、さらに他のシステム権限やオブジェクト権限が必要な場合があります。たとえば、表にトリガーを作成するには、その表に対するALTER
TABLE
オブジェクト権限とCREATE
TRIGGER
システム権限の両方が必要です。
INSERT
権限やUPDATE
権限と同様に、REFERENCES
権限は、表の特定の列に付与できます。REFERENCES
権限を付与されたユーザーは、付与の対象となった表を、自分の表の中に作成する外部キーの親キーとして使用できます。外部キーの存在によって、親キーに対して実行できるデータ操作と表の変更が制限されるため、このアクションは特殊な権限によって制御されます。列固有のREFERENCES
権限によって、権限受領者が使用できるのは、指定された列(この列には、当然、親表の主キーまたは一意キーが最低1つ含まれている)に制限されます。
この項の内容は、次のとおりです。
ビューとは、1つ以上の表から選択されたデータを表現したもので、他のビュ-が含まれていることもあります。ビューには、基礎となる表の構造が表示されます。ビューに表示されたデータは、ストアド・クエリーの結果とみなすことができます。ビュー内に実際のデータはなく、表示する内容は基礎となる表とビューから導出されます。ビューを問い合せて、表示するデータを変更できます。ビュー内のデータは更新または削除でき、新規データも挿入できます。これらの操作は、ビューの基礎である表を直接変更するため、実表の整合性制約とトリガーに従います。
DMLオブジェクト権限は、表の場合と同様にビューに対しても適用できます。ビューに対するスキーマ・オブジェクト権限は、ビューの導出元の実表に実際に影響を与える様々なDML操作を許可します。
次のどちらかのシステム権限が、明示的に、またはロールを介して付与されている必要があります。
CREATE
VIEW
システム権限(自分のスキーマ内にビューを作成するため)
CREATE
ANY
VIEW
システム権限(別のユーザーのスキーマ内にビューを作成するため)
次のいずれかの権限が明示的に付与されている必要があります。
ビューの基礎となるすべてのベース・オブジェクトに対するSELECT
、INSERT
、UPDATE
またはDELETE
オブジェクト権限
SELECT
ANY
TABLE
、INSERT
ANY
TABLE
、UPDATE
ANY
TABLE
またはDELETE
ANY
TABLE
システム権限
さらに、ビューに対するアクセス権を他のユーザーに付与する場合は、ベース・オブジェクトに対するオブジェクト権限がGRANT
OPTION
句付きで付与されているか、またはADMIN
OPTION
句によって適切なシステム権限が付与されている必要があります。これらの権限がユーザーにない場合、権限受領者はそのユーザーのビューにアクセスできません。
ビューを使用するために必要な権限は、ビュー自体に対する適切な権限のみです。ビューの基礎となるベース・オブジェクトに対する権限は必要ありません。
ビューの場合は、表に対してさらに2つのセキュリティ・レベル(列レベルと値ベースのセキュリティ)が追加されます。
ビューは、実表の中から選択した列へのアクセスを提供できます。たとえば、employees
表の中からemployee_id
列、last_name
列およびmanager_id
列のみを表示するようにビューを定義できます。
CREATE VIEW employees_manager AS SELECT last_name, employee_id, manager_id FROM employees;
ビューでは、表の情報に対して、値ベースのセキュリティを実現できます。ビュー定義でWHERE
句を使用すると、実表の中から選択した行のみが表示されます。次の2つの例を考えてみます。
CREATE VIEW lowsal AS SELECT * FROM employees WHERE salary < 10000;
lowsal
ビューでは、employees
表のうち給与値が10000未満のすべての行にアクセスできます。lowsal
ビューでは、employees
表のすべての列にアクセスできることに注目してください。
CREATE VIEW own_salary AS SELECT last_name, salary FROM employees WHERE last_name = USER;
own_salary
ビューでは、last_name
がビューの現行のユーザーに一致している行にのみアクセスできます。 own_salary
ビューはuser
疑似列を使用します。この疑似列の値は、常に現行のユーザーを参照します。このビューでは、列レベルと値ベースのセキュリティを結合しています。
この項の内容は、次のとおりです。
スタンドアロン・プロシージャ、ファクションおよびパッケージを含め、プロシージャに対するスキーマ・オブジェクト権限は、EXECUTE
のみです。この権限は、プロシージャの実行、または必要なプロシージャをコールする他のプロシージャのコンパイルが必要なユーザーにのみ付与してください。
特定プロシージャに対するEXECUTE
オブジェクト権限があるユーザーは、そのプロシージャを実行したり、それを参照するプログラム・ユニットをコンパイルできます。このプロシージャのコール時に、実行時権限チェックは実行されません。EXECUTE
ANY
PROCEDURE
システム権限があるユーザーは、データベース内の任意のプロシージャを実行できます。プロシージャの実行権限は、ロールを介してユーザーに付与できます。
定義者と呼ばれるプロシージャの所有者は、参照オブジェクトに対する必要なオブジェクト権限をすべて所有している必要があります。プロシージャの所有者が別のユーザーにそのプロシージャを使用する権限を付与すると、プロシージャで参照されるオブジェクトに対するオブジェクト権限の所有者が、そのユーザーのプロシージャ実行に適用されます。このような権限は、定義者権限と呼ばれます。
所有者以外のプロシージャのユーザーは、実行者と呼ばれます。実行者権限プロシージャの場合は、参照オブジェクトに対する追加の権限が必要ですが、定義者権限プロシージャの場合は不要です。
定義者権限プロシージャのユーザーに必要なのは、そのプロシージャを実行する権限のみで、そのプロシージャでアクセスする基礎となるオブジェクトに対する権限は不要です。これは、定義者権限プロシージャは、その実行者に関係なく、プロシージャを所有するユーザーのセキュリティ・ドメインの下で動作するためです。プロシージャの所有者は、参照オブジェクトに対する必要なオブジェクト権限をすべて所有している必要があります。定義者権限プロシージャのユーザーに付与する権限は、できるかぎり控えめに付与してください。これによって、データベース・アクセスを厳密に制御できます。
定義者権限プロシージャを使用すると、プライベート・データベース・オブジェクトへのアクセスを制御し、データベースのセキュリティ・レベルを強化できます。定義者権限プロシージャを記述し、ユーザーにEXECUTE
権限のみを付与することによって、そのプロシージャを介さない場合には、ユーザーが参照オブジェクトにアクセスできないように規定できます。
実行時には、定義者権限ストアド・プロシージャの所有者の権限が、プロシージャの実行前にチェックされます。参照オブジェクトに対して必要な権限が、定義者権限プロシージャの所有者から取り消されていると、所有者もその他のユーザーも、プロシージャを実行できません。
実行者権限プロシージャは、すべての実行者権限で実行されます。ロールは、定義者権限プロシージャによって実行者権限プロシージャが直接または間接的にコールされないかぎり有効です。実行者権限プロシージャのユーザーには、そのプロシージャが実行者のスキーマ内で解決される外部参照を介してアクセスする、オブジェクトに対する権限が(直接、またはロールを介して)必要です。
実行者には、DML文または動的SQL文に埋め込まれているプログラム参照にアクセスする権限が実行時に必要です。これは、この種のプログラム参照は実質的に実行時に再コンパイルされるためです。
PL/SQLファンクションの直接コールなど、他のすべての外部参照の場合、所有者権限はコンパイル時にチェックされ、実行時にはチェックされません。したがって、実行者権限プロシージャのユーザーには、DML文や動的SQL文の外側にある外部参照に対する権限は不要です。 また、実行者権限プロシージャの開発者による権限の付与が必要なのは、プロシージャ自体に対する権限付与のみで、その実行者権限プロシージャによって直接参照されるすべてのオブジェクトに対する権限付与は必要ありません。
複数のプログラム・ユニットで構成したソフトウェア・バンドルを作成し、一部のプログラム・ユニットには定義者権限を、残りのプログラム・ユニットには実行者権限を付与すると、プログラムのエントリ・ポイントを限定できます(コントロール・ステップイン)。エントリ・ポイント・プロシージャの実行権限があるユーザーは、内部プログラム・ユニットも間接的に実行できますが、内部プログラムを直接コールすることはできません。 問合せ処理を厳密に制御するには、PL/SQLパッケージ仕様を明示的なカーソルを使用して作成できます。
プロシージャを作成するユーザーには、CREATE
PROCEDURE
またはCREATE
ANY
PROCEDURE
システム権限が必要です。プロシージャを変更する、つまりプロシージャを手動で再コンパイルするユーザーは、そのプロシージャを所有しているか、ALTER
ANY
PROCEDURE
システム権限が必要です。
プロシージャを所有するユーザーには、プロシージャ本体で参照されるスキーマ・オブジェクトに対する権限も必要です。プロシージャを作成するには、そのプロシージャによって参照されるすべてのオブジェクトに対する必要な権限(システム権限やオブジェクト権限)が明示的に付与されている必要があります。これらの必要な権限は、ロールを介して取得することはできません。これには、作成中のプロシージャ内でコールするプロシージャに対するEXECUTE
権限も含まれます。
注意: また、トリガーでは、参照オブジェクトに対する権限をトリガーの所有者に対して明示的に付与することが必要です。権限が明示的に、またはロールを介して付与されていても、無名PL/SQLブロックでは任意の権限を使用できます。 |
パッケージに対するEXECUTE
オブジェクト権限を保持するユーザーは、そのパッケージ内の任意のパブリック・プロシージャまたはファンクションを実行し、任意のパブリック・パッケージ変数の値へのアクセスや変更を実行できます。パッケージの各構成メンバーに、特定のEXECUTE
権限を付与することはできません。したがって、データベース・アプリケーションのプロシージャ、ファンクションおよびパッケージを開発する場合は、セキュリティの確立に関して2つの選択肢を考慮してください。これらの選択肢について、次の例で説明します。
プロシージャに対する権限およびパッケージとパッケージ・オブジェクト: 例1
例4-8では、2つのパッケージの本体に4つのプロシージャを作成しています。
例4-8 プロシージャに対する権限の影響を受けるパッケージ・オブジェクト
CREATE PACKAGE BODY hire_fire AS PROCEDURE hire(...) IS BEGIN INSERT INTO employees . . . END hire; PROCEDURE fire(...) IS BEGIN DELETE FROM employees . . . END fire; END hire_fire; CREATE PACKAGE BODY raise_bonus AS PROCEDURE give_raise(...) IS BEGIN UPDATE employees SET salary = . . . END give_raise; PROCEDURE give_bonus(...) IS BEGIN UPDATE employees SET bonus = . . . END give_bonus; END raise_bonus;
次のGRANT EXECUTE
文を発行すると、big_bosses
ロールとlittle_bosses
ロールが適切なプロシージャを実行できるようになります。
GRANT EXECUTE ON hire_fire TO big_bosses; GRANT EXECUTE ON raise_bonus TO little_bosses;
注意: EXECUTE 権限をパッケージに対して付与することで、すべてのパッケージ・オブジェクトへの均一なアクセスが提供されます。 |
プロシージャに対する権限およびパッケージとパッケージ・オブジェクト: 例2
この例は、単一のパッケージ本体にある4つのプロシージャ定義を示しています。2つの追加スタンドアロン・プロシージャと1つのパッケージが特別に作成され、メイン・パッケージ内に定義されているプロシージャへのアクセスを提供します。
CREATE PACKAGE BODY employee_changes AS PROCEDURE change_salary(...) IS BEGIN ... END; PROCEDURE change_bonus(...) IS BEGIN ... END; PROCEDURE insert_employee(...) IS BEGIN ... END; PROCEDURE delete_employee(...) IS BEGIN ... END; END employee_changes; CREATE PROCEDURE hire BEGIN employee_changes.insert_employee(...) END hire; CREATE PROCEDURE fire BEGIN employee_changes.delete_employee(...) END fire; PACKAGE raise_bonus IS PROCEDURE give_raise(...) AS BEGIN employee_changes.change_salary(...) END give_raise; PROCEDURE give_bonus(...) BEGIN employee_changes.change_bonus(...) END give_bonus;
この方法を使用すると、実際に作業を実行するプロシージャ(employee_changes
パッケージ内のプロシージャ)が1つのパッケージ内に定義され、宣言されたグローバル変数やカーソルなどを共有できます。トップ・レベルのプロシージャであるhire
とfire
、および追加のパッケージraise_bonus
を宣言することによって、選択的なEXECUTE
権限をメイン・パッケージ内のプロシージャに対して付与できます。
GRANT EXECUTE ON hire, fire TO big_bosses; GRANT EXECUTE ON raise_bonus TO little_bosses;
次の各項では、型、メソッドおよびオブジェクトに対する権限の使用について説明します。
表4-4に、名前付きの型(オブジェクト型、VARRAY
およびネストした表)に対するシステム権限のリストを示します。
表4-4 名前付きの型に対するシステム権限
権限 | 許可される操作 |
---|---|
|
名前付きの型を自分のスキーマ内に作成できます。 |
|
名前付きの型を任意のスキーマ内に作成できます。 |
|
任意のスキーマにある名前付きの型を変更できます。 |
|
任意のスキーマにある名前付きの型を削除できます。 |
|
任意のスキーマにある名前付きの型を使用および参照できます。 |
RESOURCE
ロールには、CREATE
TYPE
システム権限が含まれています。DBA
ロールには、これらの権限すべてが含まれています。
名前付きの型に適用されるオブジェクト権限は、EXECUTE
のみです。名前付きの型に対するEXECUTE
権限があるユーザーは、その型を使用して次の操作を実行できます。
表の定義
リレーショナル表への列の定義
名前付きの型の変数またはパラメータの宣言
EXECUTE
権限によって、ユーザーは、型コンストラクタも含めて、その型のメソッドを起動できます。これは、ストアドPL/SQLプロシージャに対するEXECUTE
権限と同じです。
自分のスキーマに型を作成するには、CREATE
TYPE
システム権限が必要です。他のユーザーのスキーマに型を作成するには、CREATE
ANY
TYPE
システム権限が必要です。この2つの権限は、明示的に、またはロールを介して取得できます。
型の所有者には、その型の定義内で参照されている他のすべての型にアクセスするためのEXECUTE
オブジェクト権限が明示的に付与されているか、EXECUTE
ANY
TYPE
システム権限が付与されている必要があります。所有者は、ロールを介して必要な権限を取得することはできません。
型の所有者が型へのアクセス権を他のユーザーに付与する場合、その所有者には、参照される型に対するEXECUTE
権限(GRANT
OPTION
付きで指定)またはEXECUTE
ANY
TYPE
システム権限(ADMIN
OPTION
付きで指定)が必要です。どちらの権限もない型の所有者は、権限不足のため、型へのアクセス権を他のユーザーに付与できません。
型を使用して表を作成するには、表の作成要件と次の要件を満たす必要があります。
表の所有者には、その表で参照されているすべての型にアクセスするためのEXECUTE
オブジェクト権限が明示的に付与されているか、EXECUTE
ANY
TYPE
システム権限が付与されている必要があります。所有者は、ロールを介して必要な権限を取得することはできません。
表の所有者が表へのアクセス権を他のユーザーに付与する場合、その所有者には、参照される型に対するEXECUTE
権限(GRANT
OPTION
付きで指定)またはEXECUTE
ANY
TYPE
システム権限(ADMIN
OPTION
付きで指定)が必要です。どちらの権限もない表の所有者は、権限不足のため、型へのアクセス権を他のユーザーに付与できません。
CONNECT
ロールとRESOURCE
ロールを持つ次の3名のユーザーが存在するとします。
user1
user2
user3
次のDDLは、user1
のスキーマで実行されます。
CREATE TYPE type1 AS OBJECT ( attr1 NUMBER); CREATE TYPE type2 AS OBJECT ( attr2 NUMBER); GRANT EXECUTE ON type1 TO user2; GRANT EXECUTE ON type2 TO user2 WITH GRANT OPTION;
次のDDLは、user2
のスキーマで実行されます。
CREATE TABLE tab1 OF user1.type1; CREATE TYPE type3 AS OBJECT ( attr3 user1.type2); CREATE TABLE tab2 ( col1 user1.type2);
次の文は、正常に実行されます。user2
には、user1.type2
に対するGRANT
OPTION
付きのEXECUTE
権限があるためです。
GRANT EXECUTE ON type3 TO user3; GRANT SELECT on tab2 TO user3;
ただし、次の権限付与は正しく実行されません。user2
には、user1.type1
に対するGRANT
OPTION
付きのEXECUTE
権限がないためです。
GRANT SELECT ON tab1 TO user3;
次の文は、user3
によって正常に実行されます。
CREATE TYPE type4 AS OBJECT ( attr4 user2.type3); CREATE TABLE tab3 OF type4;
注意: CONNECT およびRESOURCE ロールは、将来のOracle Databaseのリリースで使用不可になる予定のため、使用しないでください。CONNECT ロールが現在保持している権限は、CREATE SESSION のみです。 |
DML文に対する列レベルと表レベルの既存の権限は、列オブジェクトと行オブジェクトの両方に適用されます。
表4-5に、オブジェクト表に対する権限をリストします。
表4-5 オブジェクト表に対する権限
権限 | 許可される操作 |
---|---|
|
オブジェクトとその属性に表からアクセスできます。 |
|
表の行を構成するオブジェクトの属性を変更できます。 |
|
表に新規オブジェクトを作成できます。 |
|
行を削除できます。 |
同様に、列オブジェクトには表に対する権限と列に対する権限が適用されます。インスタンスの取得のみでは、型情報は明らかになりません。ただし、クライアントは、型インスタンスのイメージを解釈する際に名前付きの型の情報にアクセスする必要があります。クライアントが型情報を要求すると、その型に対するEXECUTE
権限がチェックされます。
次のスキーマを考えてみます。
CREATE TYPE emp_type ( eno NUMBER, ename CHAR(31), eaddr addr_t); CREATE TABLE emp OF emp_t;
さらに、次の2つの問合せについて考えます。
SELECT VALUE(emp) FROM emp; SELECT eno, ename FROM emp;
どちらの問合せの場合も、Oracle Databaseは、emp
表に対するユーザーのSELECT
権限をチェックします。最初の問合せの場合、ユーザーは、emp_type
の型情報を取得してデータを解釈する必要があります。問合せによってemp_type
型がアクセスされると、ユーザーのEXECUTE
権限がチェックされます。
ただし、2番目の問合せの実行では、名前付きの型が含まれていないため、型の権限はチェックされません。
さらに、user3
は、前の項のスキーマを使用して次の問合せを実行できます。
SELECT tab1.col1.attr2 FROM user2.tab1 tab1; SELECT attr4.attr3.attr2 FROM tab3;
どちらのSELECT
文でも、user3
には基礎となる型に対する明示的な権限がありませんが、文には成功することに注意してください。これは、型の所有者と表の所有者に、GRANT
OPTION
を備えた必要な権限があるためです。
Oracle Databaseは、次のイベントに対する権限をチェックし、アクションに対する権限がクライアントにない場合はエラーを戻します。
オブジェクトのREF
値を使用してオブジェクト・キャッシュ内でオブジェクトを確保すると、Oracle Databaseは、そのオブジェクトが含まれているオブジェクト表に対するSELECT
権限をチェックします。
既存のオブジェクトを修正したり、オブジェクト・キャッシュからオブジェクトをフラッシュしたりすると、Oracle Databaseは目的のオブジェクト表に対するUPDATE
権限をチェックします。
新しいオブジェクトをフラッシュすると、Oracle Databaseは目的のオブジェクト表に対するINSERT
権限をチェックします。
オブジェクトを削除すると、Oracle Databaseは目的の表に対するDELETE
権限をチェックします。
名前付きの型のオブジェクトを確保すると、そのオブジェクトに対するEXECUTE
権限がチェックされます。
クライアントの第3世代言語アプリケーション内でオブジェクトの属性を変更すると、Oracle Databaseはオブジェクト全体を更新します。したがって、ユーザーにはオブジェクト表に対するUPDATE
権限が必要です。オブジェクト表の特定の列のみに対するUPDATE
権限では不十分です。これは、アプリケーションによる変更の対象がこれらの特定列に対応する属性のみの場合にも同じです。したがって、Oracle Databaseは、オブジェクト表に対する列レベルの権限はサポートしていません。
プロシージャや表などのストアド・オブジェクトと同様に、他のオブジェクトから参照される型を依存性があると呼びます。表が依存する型については、特殊な問題点がいくつかあります。表には、アクセス用の型定義に依存するデータが含まれているため、その型を変更すると、格納されているすべてのデータにアクセスできなくなります。変更によってこのような結果になるのは、型に必要な権限が取り消された場合や、型または依存型が削除された場合です。いずれかのアクションが発生すると、表は無効になり、アクセスできなくなります。
必要な権限が再び付与されると、権限がないために無効になった表は自動的に有効になり、アクセスできるようになります。依存型が削除されたことで無効になった表は、アクセス不能のままで、実行できるアクションは表の削除のみです。
型に対する権限の取消しや型の削除は重大な影響があるため、デフォルトでは、SQL文のREVOKE
とDROP
TYPE
は限定されたセマンティクスで実装されます。つまり、どちらの文でも、名前付きの型が表または型に依存している場合は、エラーが戻されて文は取り消されます。ただし、どちらの文も、FORCE
句を使用すると常に正常終了します。依存する表がある場合、その表は無効になります。
この項の内容は、次のとおりです。
ロールは、中間層またはプロキシを介して接続したユーザーにも付与できます。この操作については、「中間層サーバーを使用したプロキシ認証」を参照してください。
システム権限とロールを他のユーザーやロールに付与するには、GRANT
SQL文を使用します。次の権限が必要です。
システム権限を付与するには、ユーザーにADMIN OPTION
付きのシステム権限またはGRANT ANY PRIVILEGE
システム権限が付与されている必要があります。
ロールを付与するには、ユーザーにADMIN OPTION
付きのロールまたはGRANT ANY ROLE
システム権限が付与されている必要があります。
例4-9では、システム権限CREATE SESSION
とaccts_pay
ロールをユーザーjward
に付与しています。
注意: オブジェクト権限は、同じ GRANT 文でシステム権限やロールと同時に付与することはできません。 |
WITH ADMIN OPTION
句を指定して権限またはロールを付与されたユーザーまたはロールは、次のような拡張機能を使用できます。
権限受領者は、データベース内の任意のユーザーまたは他のロールに対して、システム権限またはロールの付与または取消しができます。ただし、自分自身からロールを取り消すことはできません。
権限受領者は、ADMIN OPTION
付きのシステム権限やロールを付与できます。
ロールの権限受領者は、そのロールを変更または削除できます。
例4-10 では、new_dba
ロールをWITH ADMIN OPTION
句付きでユーザーmichael
に付与しています。
ユーザーmichael
は、new_dba
ロール内の権限をすべて暗黙的に使用できることに加え、必要に応じてnew_dba
ロールを付与、取消しおよび削除できます。このように、ADMIN OPTION
は非常に強力な機能であるため、このオプションを付けてシステム権限やロールを付与する際は、十分に注意してください。通常、これらの権限はセキュリティ管理者向けに用意されており、システム内の他の管理者やユーザーに付与することはほとんどありません。
注意: ユーザーがロールを作成すると、そのロールは自動的に ADMIN OPTION 付きでその作成ユーザーに付与されます。 |
Oracle Databaseでは、GRANT
文を使用して新しいユーザーを作成できます。IDENTIFIED BY
句を使用することで、ユーザー名またはパスワードがデータベースに存在しない場合も、指定したユーザー名とパスワードで新しいユーザーが作成されます。
例4-11では、新規ユーザーとしてpsmith
を作成し、CREATE SESSION
システム権限をpsmith
に付与しています。
GRANT
文を使用すると、ロールとユーザーにオブジェクト権限を付与できます。オブジェクト権限を付与するには、次のいずれかの条件を満たしている必要があります。
指定するオブジェクトを所有している。
GRANT ANY OBJECT PRIVILEGE
システム権限を付与されている。この権限を使用すると、オブジェクト所有者のかわりに権限の付与と取消しを実行できます。
所有者からオブジェクト権限を付与されるときに、WITH GRANT OPTION
句が指定されている。
注意: 同じ GRANT 文で、オブジェクト権限とともにシステム権限とロールを付与することはできません。 |
例4-12では、emp
表のすべての列に対するSELECT
、INSERT
およびDELETE
のオブジェクト権限をユーザーjfee
とtsmith
に付与しています。
salary
ビューのすべてのオブジェクト権限をユーザーjfee
に付与するには、次の例のようにALL
キーワードを使用します。
GRANT ALL ON salary TO jfee;
注意: 権限受領者は、最初の権限付与に GRANT OPTION が含まれていないかぎり、オブジェクトへのアクセス権を再度付与することはできません。したがって、前述の例では、jfee はGRANT 文を使用してオブジェクト権限を他の誰かに付与することができません。 |
GRANT
文にWITH GRANT OPTION
句を指定すると、権限受領者はオブジェクト権限を他のユーザーやロールに付与できます。スキーマ内にオブジェクトを格納しているユーザーには、関連するすべてのオブジェクト権限がGRANT OPTION
付きで自動的に付与されます。この特別な権限によって、権限受領者の権限は次のように拡張されます。
権限受領者は、データベース内の任意のユーザーに対して、GRANT OPTION
付きまたはGRANT OPTION
なしでオブジェクト権限を付与できます。また、データベース内の任意のロールに対してもオブジェクト権限を付与できます。
次の2つの条件が成立する場合、権限受領者は表に対するビューを作成し、そのビューの対応する権限をデータベース内の任意のユーザーまたはロールに対して付与できます。
権限受領者が、表に対するGRANT OPTION
付きのオブジェクト権限を受領している。
権限受領者に、CREATE VIEW
またはCREATE ANY VIEW
システム権限がある。
GRANT ANY OBJECT PRIVILEGE
システム権限を持つユーザーは、オブジェクト所有者のかわりに、すべてのオブジェクト権限の付与と取消しを実行できます。この権限によって、データベース管理者やアプリケーション管理者は、スキーマに接続せずにスキーマ内のオブジェクトへのアクセス権を付与できます。この権限を持つスキーマ所有者のログイン資格証明はメンテナンスする必要がなく、構成時に必要な接続数が減少します。
このシステム権限はOracle Databaseに用意されているDBA
ロールに付属しているため、AS SYSDBA
で接続するユーザー(ユーザーSYS
)に(ADMIN OPTION
付きで)付与されます。 他のシステム権限と同様に、GRANT ANY OBJECT PRIVILEGE
システム権限を付与できるのは、ADMIN OPTION
権限を持っているユーザーのみです。
オブジェクトに対するアクセス権の権限付与者として記録されるのは、オブジェクトの所有者またはGRANT ANY OBJECT PRIVILEGE
システム権限の行使者のいずれかです。GRANT ANY OBJECT PRIVILEGE
を保持する権限付与者にGRANT OPTION
付きのオブジェクト権限がない場合は、オブジェクト所有者が権限付与者として表示されます。権限付与者がGRANT OPTION
付きのオブジェクト権限を持っている場合は、その権限付与者が付与者として記録されます。
注意: GRANT 文によって生成された監査レコードには、常に権限付与を実際に実行したユーザーが示されます。 |
たとえば、次の使用例を考えてみます。 ユーザーadams
にGRANT ANY OBJECT PRIVILEGE
システム権限があります。 他の付与権限は所持していないとします。このユーザーが次の文を発行します。
GRANT SELECT ON HR.EMPLOYEES TO blake WITH GRANT OPTION;
DBA_TAB_PRIVS
ビューを調べると、hr
が権限付与者として表示されていることがわかります。
SELECT GRANTEE, OWNER, GRANTOR, PRIVILEGE, GRANTABLE FROM DBA_TAB_PRIVS WHERE TABLE_NAME = 'EMPLOYEES' and OWNER = 'HR'; GRANTEE OWNER GRANTOR PRIVILEGE GRANTABLE -------- ----- ------- ----------- ---------- BLAKE HR HR SELECT YES
ユーザーblake
にもGRANT ANY OBJECT PRIVILEGE
システム権限があり、このユーザーが次の文を発行します。
GRANT SELECT ON HR.EMPLOYEES TO clark;
この場合は、DBA_TAB_PRIVS
ビューを再び問い合せると、blake
が権限付与者として表示されます。
GRANTEE OWNER GRANTOR PRIVILEGE GRANTABLE -------- ----- -------- -------- ---------- BLAKE HR HR SELECT YES CLARK HR BLAKE SELECT NO
これは、blake
がすでにhr.employees
に対してGRANT OPTION
付きのSELECT
権限を持っているためです。
表の個々の列に対してINSERT
、UPDATE
またはREFERENCES
権限を付与できます。
注意: 列固有の INSERT 権限を付与する前に、NOT NULL 制約が定義されている列が表に含まれているかどうかを確認してください。挿入できる列を選んで権限を付与したときにNOT NULL 列が抜けていると、ユーザーは表に行を挿入できません。このような状況を回避するには、各NOT NULL 列が挿入可能であること、またはNULL 以外のデフォルト値があることを確認してください。そうでない場合、権限受領者は表に行を挿入できず、エラーが発生します。 |
次の文は、accounts
表のacct_no
列に対するINSERT
権限をpsmith
に付与しています。
GRANT INSERT (acct_no) ON accounts TO psmith;
次の例では、emp
表のename
およびjob
列に対するオブジェクト権限が、ユーザーjfee
およびtsmith
に付与されます。
GRANT INSERT(ename, job) ON emp TO jfee, tsmith;
この項の内容は、次のとおりです。
システム権限およびロールを取り消すには、SQL文REVOKE
を使用します。 ADMIN OPTION
付きでシステム権限またはロールを付与されているユーザーは、他のデータベース・ユーザーまたはロールから権限またはロールを取り消すことができます。取消しを行うユーザーは、権限やロールを最初に付与したユーザーでなくてもかまいません。GRANT ANY ROLE
を保持しているユーザーは、任意のロールを取り消すことができます。
次の文は、psmith
からCREATE TABLE
システム権限とaccts_rec
ロールを取り消します。
REVOKE CREATE TABLE, accts_rec FROM psmith;
オブジェクト権限を取り消すには、次のどちらかの条件を満たしている必要があります。
以前にユーザーまたはロールにオブジェクト権限を付与している。
オブジェクト所有者のかわりに権限を付与したり取り消すことができるGRANT ANY OBJECT PRIVILEGE
システム権限を所持している。
取り消すことができるのは、権限付与者として直接認可した権限のみで、GRANT OPTION
を付与した他のユーザーによる権限付与を取り消すことはできません。ただし、連鎖的な影響があります。権限付与者のオブジェクト権限を取り消すと、GRANT OPTION
を使用して伝播されたオブジェクト権限も取り消されます。
最初の権限付与者が次の文を発行すると、ユーザーjfee
とpsmith
からemp
表のSELECT
権限とINSERT
権限が取り消されます。
REVOKE SELECT, INSERT ON emp FROM jfee, psmith;
次の文は、最初にhuman_resource
ロールに付与したdept
表に対するすべてのオブジェクト権限を取り消します。
REVOKE ALL ON dept FROM human_resources;
注意: オブジェクト権限の GRANT OPTION を選択的に取り消すことはできません。オブジェクト権限を取り消してから、同じオブジェクト権限をGRANT OPTION を指定せずに再度付与する必要があります。ユーザーが自分自身からオブジェクト権限を取り消すことはできません。 |
GRANT ANY OBJECT PRIVILEGE
システム権限を使用すると、オブジェクト所有者が権限付与者である指定のオブジェクト権限を取り消すことができます。この操作を実行できるのは、オブジェクト所有者によって、または所有者のかわりにGRANT ANY OBJECT PRIVILEGE
システム権限を持つユーザーによって、オブジェクト権限が付与されている場合です。
オブジェクト権限が、オブジェクト所有者とREVOKE
文を実行するユーザー(特定のオブジェクト権限とGRANT ANY OBJECT PRIVILEGE
システム権限の両方を持つユーザー)の両方によって付与されている場合は、REVOKE
文を発行したユーザーによって付与されたオブジェクト権限のみが取り消されます。この使用例については、「オブジェクト所有者にかわるオブジェクト権限の付与」の例を使用して説明します。
ここでは、blake
がHR.EMPLOYEES
に対するSELECT
権限をclark
に付与しているとします。blake
はGRANT ANY OBJECT PRIVILEGE
システム権限のみでなく特定のオブジェクト権限も持っているため、この権限付与はblake
に帰属します。ここでは、ユーザーHR
もHR.EMPLOYEES
に対するSELECT
権限をユーザーclark
に付与しているとします。DBA_TAB_PRIVS
ビューの問合せでは、HR.EMPLOYEES
表について次の権限付与が有効であることが表示されています。
GRANTEE OWNER GRANTOR PRIVILEGE GRANTABLE -------- ----- ------- ----------- ---------- BLAKE HR HR SELECT YES CLARK HR BLAKE SELECT NO CLARK HR HR SELECT NO
ユーザーblake
が次のREVOKE
文を発行します。
REVOKE SELECT ON HR.EMPLOYEES FROM clark;
ユーザーblake
がユーザーclark
に付与したオブジェクト権限のみが削除されます。オブジェクト所有者hr
による権限付与はそのまま残ります。
GRANTEE OWNER GRANTOR PRIVILEGE GRANTABLE -------- ----- ------- ----------- ---------- BLAKE HR HR SELECT YES CLARK HR HR SELECT NO
blake
が再度REVOKE
文を発行すると、今度はhr
によって付与されたオブジェクト権限が削除されます。
表やビューの列を選択してINSERT
、UPDATE
およびREFERENCES
権限を付与することは可能ですが、同じようなREVOKE
文を使用して、列固有の権限を選択的に取り消すことはできません。かわりに、権限付与者は表またはビューの全列に対するオブジェクト権限を取り消してから、残しておく列固有の権限を選択的に再度付与する必要があります。
たとえば、human_resources
ロールには、dept
表のdeptno
列およびdname
列に対するUPDATE
権限が付与されているとします。このUPDATE
権限をdeptno
列のみから取り消すには、次の2つの文を発行します。
REVOKE UPDATE ON dept FROM human_resources; GRANT UPDATE (dname) ON dept TO human_resources;
このREVOKE
文によって、ロールhuman_resources
からdept
表の全列に対するUPDATE
権限が取り消されます。次にGRANT
文によって、dname
列のUPDATE
権限がhuman_resources
ロールに再度付与されます。
権限のタイプによっては、権限の取消しによって連鎖的な影響が発生する場合があります。次の各項で、これについて説明します。
DDL操作に関連するシステム権限を取り消しても、影響は連鎖しません。この場合、権限を付与したときにADMIN OPTION
を指定したかどうかは関係ありません。たとえば、次のような場合を考えてみます。
セキュリティ管理者が、ADMIN OPTION
を指定して、ユーザーjfee
にCREATE TABLE
システム権限を付与します。
ユーザーjfee
が表を作成します。
ユーザーjfee
が、ユーザーpsmith
にCREATE TABLE
システム権限を付与します。
ユーザーtsmith
が表を作成します。
セキュリティ管理者が、ユーザーjfee
からCREATE TABLE
システム権限を取り消します。
ユーザーjfee
が作成した表はそのまま残ります。ユーザーtsmith
の表とCREATE TABLE
システム権限はそのまま残ります。
連鎖的な影響は、DML操作に関連するシステム権限を取り消したときに発生する場合があります。ユーザーのSELECT ANY TABLE
権限を取り消すと、そのユーザーのスキーマ内に存在し、この権限に依存しているすべてのプロシージャは、権限が再度認可されないかぎり、正常に実行できません。
オブジェクト権限を取り消すと、連鎖的な影響が発生する場合があります。次のことに注意してください。
DMLオブジェクト権限を取り消すと、そのDMLオブジェクト権限に依存するオブジェクト定義にまで影響が及ぶ可能性があります。たとえば、test
プロシージャの本体に、emp
表のデータを問い合せるSQL文が記述されているとします。test
プロシージャの所有者からemp
表のSELECT
権限を取り消すと、それ以降そのプロシージャを正常に実行できなくなります。
表に対するREFERENCES権限をユーザーから取り消すと、そのユーザーが定義した外部キー整合性制約の中で、取り消されたREFERENCES権限を必要とする制約が自動的に削除されます。たとえば、ユーザーjward
にdept
表のdeptno
列に対するREFERENCES
権限が付与されているとします。このユーザーが、emp
表のdeptno
列に、dept
表のdeptno
列を参照する外部キーを作成します。dept
表のdeptno
列に対するREFERENCES
権限を取り消すと、同じ操作でemp
表のdeptno
列に対する外部キー制約も削除されます。
GRANT OPTIONを使用して伝播されたオブジェクト権限付与は、権限付与者のオブジェクト権限が取り消されると取り消されます。たとえば、GRANT OPTION
付きのSELECT
オブジェクト権限を付与されているuser1
が、user2
に対してemp
表のSELECT
権限を付与したとします。その後、user1
からSELECT
権限を取り消します。このREVOKE
文はuser2
にも連鎖します。user1
とuser2
の取り消されたSELECT
権限に依存するオブジェクトもすべて、前述のように影響を受ける可能性があります。
ALTER
またはINDEX
オブジェクト権限を取り消しても、ALTER
およびINDEX DDL
の各オブジェクト権限を必要とするオブジェクト定義には影響を与えません。たとえば、別のユーザーに属する表に索引を作成したユーザーからINDEX
権限を取り消しても、その索引はそのまま残ります。
ユーザー・グループPUBLIC
に対して、権限とロールの付与および取消しを実行できます。PUBLIC
にはすべてのデータベース・ユーザーがアクセスできるため、PUBLIC
に対して付与されたすべての権限またはロールには、すべてのデータベース・ユーザーがアクセスできます。
セキュリティ管理者とデータベース・ユーザーは、すべてのデータベース・ユーザーが権限またはロールを必要としている場合のみ、PUBLIC
に権限またはロールを付与してください。これによって、各データベース・ユーザーには常に、現在のグループ・タスクの正常実行に必要な権限のみが付与されているという一般規則が保証されます。
PUBLIC
から権限を取り消すと、かなりの規模で影響が連鎖する可能性があります。DML操作に関連する権限(SELECT ANY TABLE
、UPDATE ON
emp
など)をPUBLIC
から取り消した場合、再度使用するには、ファンクションとパッケージも含めてデータベース内のすべてのプロシージャを再認可する必要があります。したがって、DMLに関連する権限をPUBLIC
に付与したり、取り消す場合には注意が必要です。
この項の内容は、次のとおりです。
セキュリティ管理者がGRANT
文とREVOKE
文を使用して、ユーザーに対し明示的にデータベース・ロールを付与または取り消すかわりに、Oracle Databaseが稼働しているオペレーティング・システムによって、接続時にユーザーにロールを付与できます。つまり、オペレーティング・システムを使用してロールを管理し、ユーザーのセッション作成時にOracle Databaseにそのロールを渡すことができます。このメカニズムの一部として、ユーザーのデフォルト・ロールや、ADMIN OPTION
付きでユーザーに付与するロールを識別できます。オペレーティング・システムを使用してロールを使用するユーザーを認可する場合は、必ずすべてのロールをデータベース内に作成し、GRANT
文を使用してそのロールに権限を割り当てる必要があります。
ロールは、ネットワーク・サービスを介しても付与できます。
ユーザーのデータベース・ロールを識別するためにオペレーティング・システムを使用する方法の利点は、Oracleデータベースの権限管理をデータベースの外部で実施できることです。オペレーティング・システムに組み込まれたセキュリティ機能によって、ユーザーの権限が制御されます。 また、このオプションを使用すると、いくつかのシステム・アクティビティのセキュリティを集中管理できるため、次のような状況で役立ちます。
MVS版Oracleの管理者が、データベース・ユーザーのロールを識別するためにRACFグループを使用する場合
UNIX版Oracleの管理者が、データベース・ユーザーのロールを識別するためにUNIXグループを使用する場合
VMS版Oracleの管理者が、データベース・ユーザーのロールを識別するために権限識別子を使用する場合
ユーザーのデータベース・ロールを識別するためにオペレーティング・システムを使用する方法の主なデメリットは、権限管理がロール・レベルでしか実施できないことです。個々の権限は、オペレーティング・システムを使用して付与することはできません。ただし、GRANT
文を使用してデータベース内で付与することは可能です。
この機能を使用する際の第2のデメリットは、オペレーティング・システムがロールを管理している場合に、デフォルトではユーザーが共有サーバーまたはその他のネットワーク接続を介してデータベースに接続できないことです。ただし、このデフォルトは「オペレーティング・システムによるロール管理使用時のネットワーク接続の使用」の説明に従って変更できます。
注意: この項で説明されている機能は、一部のオペレーティング・システムでしか使用できません。これらの機能が使用できるかどうかを確認するには、使用しているオペレーティング・システム固有のOracle Databaseマニュアルを参照してください。 |
セッションの作成時に、データベースがオペレーティング・システムを使用して各ユーザーのデータベース・ロールを識別するように、初期化パラメータOS_ROLES
をTRUE
に設定します(インスタンスが実行中の場合は再起動が必要)。ユーザーがデータベースとのセッションを作成しようとすると、Oracle Databaseはオペレーティング・システムによって識別されるデータベース・ロールを使用して、そのユーザーのセキュリティ・ドメインを初期化します。
ユーザーのデータベース・ロールを識別するために、各Oracle Databaseユーザーのオペレーティング・システム・アカウントには、そのユーザーが使用できるデータベース・ロールを示すオペレーティング・システム識別子が必要です。この識別子は、グループ、権限識別子またはこれに類似する名前で呼ばれています。ロールの指定では、ユーザーのデフォルト・ロールやADMIN OPTION
付きのロールを示すこともできます。オペレーティング・システム・レベルでのロールの指定形式は、次のとおりです。この形式は、どのオペレーティング・システムを使用している場合でも同じです。
ora_ID_ROLE[_[d][a]]
次のように値を指定します。
ID
の定義は、オペレーティング・システムによって異なります。たとえば、VMSでは、ID
はデータベースのインスタンス識別子です。MVSではコンピュータ・タイプ、UNIXではシステムID
です。
注意: ID は、ORACLE_SID と照合する際に大/小文字が区別されます。ROLE では、大/小文字は区別されません。 |
ROLE
は、データベース・ロールの名前です。
d
は、このロールがデータベース・ユーザーのデフォルト・ロールであることを示すオプション文字です。
a
は、このロールがADMIN OPTION
付きでユーザーに付与されることを示すオプション文字です。このオプション文字を指定することによって、ユーザーはこのロールを他のロールにのみ付与できるようになります。オペレーティング・システムを使用してロールを管理している場合は、ユーザーにロールを付与できません。
注意: d またはa のいずれかを指定する場合は、その文字の直前にアンダースコア(_)を指定してください。 |
たとえば、オペレーティング・システム・アカウントが、プロファイルで識別される次のロールを持っているとします。
ora_PAYROLL_ROLE1 ora_PAYROLL_ROLE2_a ora_PAYROLL_ROLE3_d ora_PAYROLL_ROLE4_da
対応するユーザーがOracle Databaseのpayroll
インスタンスに接続すると、role3
とrole4
がデフォルト・ロールになり、role2
とrole4
がADMIN OPTION
付きで付与されます。
オペレーティング・システムによって管理されているロールを使用する場合は、データベース・ロールがオペレーティング・システムのユーザーに付与されることに注意してください。オペレーティング・システム・ユーザーが接続できるデータベース・ユーザーは、認可されたデータベース・ロールを使用できます。このため、OS_ROLES = TRUE
を使用している場合は、権限が付与されているオペレーティング・システム・アカウントにデータベース・アカウントを対応付けるために、すべてのOracle DatabaseユーザーをIDENTIFIED EXTERNALLY
として定義することを考慮してください。
OS_ROLES
パラメータがTRUE
に設定されている場合は、ユーザーに対するロールの付与と取消しがオペレーティング・システムによって完全に管理されます。それまでにGRANT
文によってユーザーに付与されたロールは適用されません。ただし、それらのロールはデータ・ディクショナリには残っています。オペレーティング・システム・レベルでのユーザーへのロールの付与のみが適用されます。この場合も、ユーザーは権限をロールとユーザーに付与できます。
注意: オペレーティング・システムによって ADMIN OPTION 付きでロールが付与された場合、ユーザーはそのロールを他のロールにのみ付与できます。 |
OS_ROLES
初期化パラメータがTRUE
に設定されている場合、オペレーティング・システムによって付与されたロールは、SET ROLE
文を使用して動的に使用可能にできます。ロールがパスワードやオペレーティング・システムによる認可を必要とするように定義されていた場合でも、この文は適用されます。ただし、ユーザーのオペレーティング・システム・アカウントで識別されないロールは、SET ROLE
文では指定できません。これは、OS_ROLES = FALSE
のときにGRANT
文を使用してロールを付与していた場合でも同じです(このようなロールを指定しても無視されます)。
OS_ROLES = TRUE
の場合、ユーザーは初期化パラメータMAX_ENABLED_ROLES
で指定されている数までロールを使用可能にできます。
オペレーティング・システムでロールを管理する場合、ユーザーは、デフォルトでは共有サーバーを介してデータベースに接続できません。リモート・ユーザーは保護されていない接続を介して別のオペレーティング・システム・ユーザーになりすますおそれがあるため、デフォルトでこのような制限が適用されています。
このようなセキュリティに対する危険性の心配がない場合は、初期化パラメータREMOTE_OS_ROLES
をTRUE
に設定することで、共有サーバーまたはその他のネットワーク接続でオペレーティング・システムのロール管理を使用できます。この変更は、次回インスタンスを起動して、データベースをマウントするときに有効になります。このパラメータのデフォルト設定はFALSE
です。
付与と取消しがいつ有効になるかは、付与または取り消す対象によって異なります。
任意の対象(ユーザー、ロールおよびPUBLIC
)に対するシステム権限とオブジェクト権限の付与および取消しは、即時に有効になります。
任意の対象(ユーザー、他のロール、PUBLIC
)に対するロールの付与および取消しが有効になるのは、その付与および取消しの実行後、ロールを再度使用可能にするために現行のユーザー・セッションでSET ROLE
文を発行したとき、あるいはその付与または取消しを実行した後に新しくユーザー・セッションを作成したときです。
現在使用可能なロールは、SESSION_ROLES
データ・ディクショナリ・ビューを問い合せることによって確認できます。
ユーザーまたはアプリケーションは、ユーザー・セッション中にSET ROLE
文を何度でも使用して、現在そのセッションで使用可能になっているロールを変更できます。ユーザーには、SET ROLE
文で指定したロールが、事前に付与されている必要があります。同時に使用可能にできるロールの数を指定するには、初期化パラメータMAX_ENABLED_ROLES
を設定します。
例4-13では、すでに付与されているロールclerk
を使用可能にして、パスワードを指定しています。
password
を安全なパスワードに置き換えます。パスワードの最低要件については、「パスワードの最低要件」を参照してください。
例4-14は、SET ROLE
を使用してすべてのロールを使用禁止にする方法を示しています。
ユーザーがログインすると、そのユーザーに明示的に付与されている権限と、そのユーザーのデフォルト・ロールに含まれる権限が、すべて使用可能になります。
ユーザーのデフォルト・ロールのリストは、ALTER USER
SQL文を使用して設定および変更できます。このALTER USER
文は、ユーザーがデータベースに接続するときに、ロールのパスワードを指定しなくても使用可能になるロールを指定します。ユーザーには、そのロールがGRANT
文で直接付与されている必要があります。ディレクトリ・サービスなどの外部サービスによって管理されているロール(外部ロールやグローバル・ロール)は、デフォルト・ロールとして指定できません。
例4-15では、ユーザーjane
に対してデフォルト・ロールのpayclerk
とpettycash
を設定しています。
ユーザーのデフォルト・ロールは、CREATE USER
文では設定できません。最初にユーザーを作成したときに、ユーザーのデフォルト・ロールはALL
に設定されます。これによって、その後ユーザーに付与されるロールはすべてデフォルト・ロールになります。ユーザーのデフォルト・ロールを制限するには、ALTER USER
文を使用します。
ユーザーは、初期化パラメータMAX_ENABLED_ROLES
で指定された数のロールを使用可能にできます。間接的に付与され、1次ロールが使用可能になった結果として使用可能になるロールもすべてその数に含まれます。データベース管理者(DBA)は、このパラメータの値を変更することによって、この制限を変更できます。各ユーザー・セッションで同時に使用可能にするロール数を増やすには、大きい値を設定します。ただし、この値を大きくすると、各ユーザー・セッションでは、より多くのメモリー領域が必要になります。これは、ユーザー・セッションごとのプログラム・グローバル領域(PGA)サイズがロール当たり4バイト必要となるためです。1人のユーザーが同時に使用可能にできるロールの最大数を決定し、その値をMAX_ENABLED_ROLES
パラメータに使用してください。
MAX_ENABLED_ROLES
初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。
データベースから外部ネットワーク・サービスへのアクセスが必要なユーザーやロールには、ファイングレイン・アクセス・コントロールを構成できます。これによって、特定のユーザー・グループは、付与されている権限に基づいて1つ以上のホスト・コンピュータに接続できます。通常、この機能は、特定のホスト・アドレスで実行されるアプリケーションへのアクセスを制御するために使用します。
この項の内容は、次のとおりです。
データベース・ネットワーク・サービスに対するファイングレイン・アクセスを構成するには、アクセス制御リスト(ACL)を作成します。このACLはOracle XML DBに格納されます。アクセス制御リストは、Oracle XML DB自体を使用するか、DBMS_NETWORK_ACL_ADMIN
およびDBMS_NETWORK_ACL_UTILITY
のPL/SQLパッケージを使用して作成できます。ここでは、これらのパッケージを使用してアクセス制御リストを作成および管理する方法を説明します。Oracle XML DBを使用したアクセス制御リストの作成方法およびアクセス制御リストに関する一般的な概念は、『Oracle XML DB開発者ガイド』を参照してください。
この機能を使用することで、データベース・ユーザーがUTL_TCP
、UTL_SMTP
、UTL_MAIL
、UTL_HTTP
、UTL_INADDR
などのPL/SQLネットワーク・ユーティリティ・パッケージを使用して接続できる外部ネットワーク・ホストが制限されるため、ネットワーク接続のセキュリティが強化されます。この機能を使用しない場合、デフォルトでは、PL/SQLユーティリティ・パッケージは、PUBLIC
ユーザーに付与されるEXECUTE
権限付きで作成されるため、データベースへのアクセス権を獲得した侵入者が故意にネットワークを攻撃する可能性があります。
以前のOracle Databaseリリースからアップグレードしているときに、アプリケーションがUTL_TCP
、UTL_SMTP
、UTL_MAIL
、UTL_HTTP
、UTL_INADDR
などのPL/SQLネットワーク・ユーティリティ・パッケージに依存している場合は、そのアプリケーションの実行を試みたときに、次のエラーが発生する可能性があります。
ORA-24247: network access denied by access control list (ACL)
その場合は、この項に記載されている手順を使用してアプリケーションのネットワーク・アクセスを再構成してください。PL/SQLネットワーク・ユーティリティ・パッケージに依存しているアプリケーションの互換性に関する問題については、『Oracle Databaseアップグレード・ガイド』も参照してください。ネットワーク・ユーティリティ・パッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
ネットワーク接続用にアクセス制御リストを作成する場合は、共通するユーザー(例: 特定のホスト・コンピュータ上の特定のアプリケーションにアクセスする必要があるユーザー)のグループ専用に1つのアクセス制御リストを作成してください。管理の容易性と良好なシステム・パフォーマンスを確保するために、アクセス制御リストは必要以上に多く作成しないでください。同じユーザー・グループがアクセスできる複数のネットワーク・ホストで、同じアクセス制御リストを共有する必要があります。
DBMS_NETWORK_ACL_ADMIN
パッケージを使用してアクセス制御リストを作成する手順は、次のとおりです。
アクセス制御リストの内容を作成するには、DBMS_NETWORK_ACL_ADMIN.CREATE_ACL
プロシージャを使用します。アクセス制御リストには、そのリストの名前、簡単な説明、およびそのリストに関連付ける単一のユーザーまたはロールの権限設定が格納されます。アクセス制御リストでは、各ユーザーまたはロールの権限がアクセス制御エントリ(ACE)としてグループ化されます。アクセス制御リストには、少なくとも1つのユーザーまたはロールに対する権限設定が必要です。
注意: アクセス制御リストの設定は、Oracle Databaseのインポートまたはエクスポート・ユーティリティ(Oracle Data Pumpなど)を使用してインポートまたはエクスポートすることはできません。 |
BEGIN DBMS_NETWORK_ACL_ADMIN.CREATE_ACL ( acl => 'file_name.xml', description => 'file description', principal => 'user_or_role', is_grant => TRUE│FALSE, privilege => 'connect│resolve', start_date => null│timestamp_with_time_zone, end_date => null│timestamp_with_time_zone); END;
次のように値を指定します。
acl
: アクセス制御リストのXMLファイル名を入力します。このファイルは、データベースのXML DBリポジトリにある/sys/acls
ディレクトリに作成されます。.xml
拡張子を指定してください。次に例を示します。
acl => 'us-example-com-permissions.xml',
description
: ファイルの目的に関する簡単な説明を入力します。次に例を示します。
description => 'Network connection permission for ACCT_MGR role',
principal
: 権限を付与または拒否する最初のユーザー・アカウントまたはロールを入力します。次に例を示します。
principal => 'ACCT_MGR',
ユーザー・アカウントまたはロールの名前は大/小文字を区別して入力します。たとえば、ユーザー名preston
がすべて大文字でデータベースに格納されている場合は、大文字と小文字の両方を使用したり、小文字で入力しても機能しません。DBA_USERS
ビューとDBA_ROLES
ビューを問い合せることで、現行のデータベース・インスタンス内のユーザー・アカウントとロールを確認できます。通常、ユーザー名とロールは大文字となります。
複数のユーザーを入力する必要がある場合、このアクセス制御リストのXMLファイルを作成した後、次に説明するDBMS_NETWORK_ACL.ADD_PRIVILEGE
プロシージャを使用します
is_grant
: TRUE
またはFALSE
を入力し、権限を付与するか拒否するかを示します。次に例を示します。
is_grant => TRUE,
privilege
: connect
またはresolve
を入力します。この設定は、大/小文字が区別されるため、必ず小文字で入力してください。次に例を示します。
privilege => 'connect',
UTL_TCP
、UTL_HTTP
、UTL_SMTP
およびUTL_MAIL
のユーティリティ・パッケージを使用してホストに接続するデータベース・ユーザーには、外部ネットワークのホスト・コンピュータへのconnect
権限が必要です。かわりに、UTL_INADDR
パッケージを使用して、ホストのIPアドレスが指定されたホスト名またはホスト名が指定されたIPアドレスを解決するには、データベース・ユーザーにresolve
権限を付与します。
既存の権限とネットワーク接続の詳細を検索するには、「アクセス制御リストに関する情報の検索」で説明しているデータ・ディクショナリ・ビューを使用できます。
start_date
: (オプション)アクセス制御エントリ(ACE)の開始日をTIMESTAMP WITH TIME ZONE
書式(YYYY-MM-DD HH:MI:SS.FF TZR)で入力します。開始日を指定すると、アクセス制御エントリは指定日以降にのみ有効になります。デフォルトはnull
です。たとえば、開始日を米国カリフォルニア州サンフランシスコ(太平洋タイムゾーン)の2008年2月28日午前6時30分に設定するには、次のように指定します。
start_date => '2008-02-28 06:30:00.00 US/Pacific',
NLS_TIMESTAMP_FORMAT
初期化パラメータは、デフォルトのタイムスタンプ書式を設定します。詳細は、『Oracle Databaseリファレンス』を参照してください。
end_date
: (オプション)アクセス制御エントリ(ACE)の終了日をTIMESTAMP WITH TIME ZONE
書式(YYYY-MM-DD HH:MI:SS.FF TZR)で入力します。終了日を指定すると、アクセス制御エントリは指定日を経過すると無効になります。end_date
には、start_date
以降の日時を設定する必要があります。デフォルトはnull
です。
たとえば、終了日を米国カリフォルニア州サンフランシスコ(太平洋タイムゾーン)の2008年12月10日午後11時59分に設定するには、次のように指定します。
end_date => '2008-12-10 23:59:00.00 US/Pacific');
ユーザーまたはロールをアクセス制御リストに追加するには、DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE
プロシージャを使用します。構文は、次のとおりです。
BEGIN DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE ( acl => 'file_name.xml', principal => 'user_or_role', is_grant => TRUE│FALSE, privilege => 'connect│resolve', position => null│value, start_date => null│timestamp_with_time_zone, end_date => null│timestamp_with_time_zone); END;
このように、権限を追加するためのパラメータは、CREATE_ACL
プロシージャのパラメータに類似していますが、description
がないことと、複数のユーザーまたはロールの優先順位を設定するposition
パラメータが追加されている点が異なります。ここでは、複数のユーザーやロールを追加しているため、優先順位の設定が必要となる可能性があります。詳細は、「単一アクセス制御リスト内の複数のユーザーとロールに対する優先順位の設定」を参照してください。
この手順で使用できる他のDBMS_NETWORK_ACL_ADMIN
プロシージャには、DELETE_PRIVILEGE
およびDROP_ACL
があります。
これまでの手順で、ネットワーク・ホストへの接続に必要な権限を定義するアクセス制御リストを作成しました。ただし、このアクセス制御リストは、手順2: 1つ以上のネットワーク・ホストへのアクセス制御リストの割当てを完了するまでは無効です。
作成したアクセス制御リストは、1つ以上のネットワーク・ホスト・コンピュータに割り当てることができます。この割当てには、DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL
プロシージャを使用します。
次に例を示します。
BEGIN DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL ( acl => 'file_name.xml', host => 'network_host', lower_port => null│port_number, upper_port => null│port_number); END;
次のように値を指定します。
acl
: ネットワーク・ホストに割り当てるアクセス制御リストのXMLファイル名を入力します(「手順1: アクセス制御リストとその権限の定義の作成」)。このファイルは、データベースのXML DBリポジトリにある/sys/acls
ディレクトリに作成されます。.xml
拡張子を指定してください。次に例を示します。
acl => 'us-example-com-permissions.xml',
host
: このアクセス制御リストを割り当てるネットワーク・ホストを入力します。この設定には、ネットワーク・ホストの名前またはIPアドレスを使用できます。ホスト名は大/小文字が区別されます。次に例を示します。
host => 'us.example.com',
アクセス制御リスト割当てにおけるネットワーク・ホスト・コンピュータの動作の詳細は、次の各項を参照してください。
lower_port
:(オプション)TCP接続に対するポート範囲の下限を入力します。この設定は、connect
権限の場合にのみ使用し、resolve
権限の場合は省略します。デフォルトはnull
で、ポート制限がない(つまり、すべてのポートにACLが適用される)ことを意味します。次に例を示します。
lower_port => 80,
upper_port
:(オプション)TCP接続に対するポート範囲の上限を入力します。この設定は、connect
権限の場合にのみ使用し、resolve
権限の場合は省略します。デフォルトはnull
で、ポート制限がない(つまり、すべてのポートにACLが適用される)ことを意味します。次に例を示します。
upper_port => 3999);
lower_port
に値を入力してupper_port
をnull
のままに(または省略)すると、upper_port
の設定は、lower_port
と同じ設定とみなされます。たとえば、lower_port
を80
に設定し、upper_port
を省略すると、このupper_port
の設定は80
とみなされます。
アクセス制御リスト割当てにポート範囲が指定されている場合、アクセス制御リストのresolve
権限は機能しません。
ホスト・コンピュータ、ドメイン、IPサブネットまたはTCPポート範囲(指定されている場合)に対して指定できるアクセス制御リストは、1つのみです。新しいアクセス制御リストをネットワーク・ターゲットに割り当てると、同じターゲットに割り当てられていた以前のアクセス制御リストの割当ては解除されます。ただし、アクセス制御リストは削除されません。アクセス制御リストを削除するには、DROP_ACL
プロシージャを使用します。アクセス制御リスト割当てを解除するには、UNASSIGN_ACL
プロシージャを使用します。
アクセス制御リストの作成方法やメンテナンス方法によっては、2つの手順が重複する可能性があります。たとえば、5人のユーザーに対する権限を記載したアクセス制御リストを作成し、そのリストを2台のホスト・コンピュータに適用します。その後、異なる(または追加の)ユーザーと権限を保持するようにこのアクセス制御リストを変更し、異なる(または追加の)ホスト・コンピュータにそのリストを適用します。
アクセス制御リストの変更は、ネットワーク・ホストへの割当ても含めて、すべてトランザクションです。変更内容は、トランザクションがコミットされるまで無効です。
既存の権限とネットワーク接続に関する情報は、表4-6「アクセス制御リストに関する情報を表示するデータ・ディクショナリ・ビュー」に説明されているデータ・ディクショナリ・ビューを使用して確認できます。
DBMS_NETWORK_ACL_ADMIN
パッケージの使用方法は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
例4-16は、us-example-com-permissions.xml
というアクセス制御リストの作成方法を示しています。このアクセス制御リストは、ACCT_MGR
ロールを持つユーザーに対して、ホストus.example.com
で実行されるネットワーク・サービスへのアクセス権を付与します。
例4-16 1つのロールと1つのネットワーク接続を割り当てるアクセス制御リストの作成
-- First, create the access control list, which includes one role: BEGIN DBMS_NETWORK_ACL_ADMIN.CREATE_ACL ( acl => 'us-example-com-permissions.xml', description => 'Network connection permission for ACCT_MGR', principal => 'ACCT_MGR', is_grant => TRUE, privilege => 'connect'); END; -- Second, assign the access control list a network host: BEGIN DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL ( acl => 'us-example-com-permissions.xml', host => 'www.us.example.com', lower_port => 80, upper_port => 80); END;
この例では、us-example-com-permissions.xml
ファイルが/sys/acls
ディレクトリに作成されます。これはデフォルトの位置です。XMLファイルは、次のようになります。
<acl description="Network connection permission for ACCT_MGR" xmlns="http://xmlns.oracle.com/xdb/acl.xsd" xmlns:plsql="http://xmlns.oracle.com/plsql" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/xdb/acl.xsd http://xmlns.oracle.com/xdb/acl.xsd"> <security-class>plsql:network</security-class> <ace> <grant>true</grant> <principal>ACCT_MGR</principal> <privilege><plsql:connect/></privilege> </ace> </acl>
xmlns
要素とxsi
要素は固定です。テキスト・エディタなどで変更しないでください。
アクセス制御リストの内容はSQL*Plusでチェックできます。例については、『Oracle XML DB開発者ガイド』を参照してください。
例4-17は、us-example-com-permissions.xml
アクセス制御リストより少し複雑なリストの作成方法を示しています。この例では、複数のロール権限とその優先順位を指定し、複数のホスト・コンピュータに割り当てます。
ホスト名の詳細は、「ネットワーク・ホスト・コンピュータでのワイルドカード文字の使用」および「複数のアクセス制御リスト割当てでのホスト・コンピュータの優先順位」を参照してください。アクセス制御リストXMLファイル内の複数のACE
要素の順序を判断するには、「単一アクセス制御リスト内の複数のユーザーとロールに対する優先順位の設定」も参照してください。
例4-17 複数のロールと複数のネットワーク接続を割り当てるアクセス制御リストの作成
-- Create the access control list: BEGIN DBMS_NETWORK_ACL_ADMIN.CREATE_ACL ( acl => 'us-example-com-permissions.xml', description => 'Network connection permission for ACCT_MGR and ACCT_CLERK', principal => 'ACCT_MGR', is_grant => TRUE, privilege => 'resolve'); DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE ( -- Creates the second role privilege acl => 'us-example-com-permissions.xml', principal => 'ACCT_CLERK', is_grant => TRUE, privilege => 'connect', position => null); END; -- Assign the access control list to hosts: BEGIN DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL ( -- Creates the first target host acl => 'us-example-com-permissions.xml', host => '*.us.example.com'); DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL ( -- Creates the second target host acl => 'us-example-com-permissions.xml', host => '*.uk.example.com', lower_port => 80, upper_port => 99); END;
us-example-com-permissions.xml
は、次のようになります。
<acl description="Network connection permission for ACCT_MGR and ACCT_CLERK" xmlns="http://xmlns.oracle.com/xdb/acl.xsd" xmlns:plsql="http://xmlns.oracle.com/plsql" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/xdb/acl.xsd http://xmlns.oracle.com/xdb/acl.xsd"> <security-class>plsql:network</security-class> <ace> <grant>true</grant> <principal>ACCT_MGR</principal> <privilege><plsql:resolve/></privilege> </ace> <ace> <grant>true</grant> <principal>ACCT_CLERK</principal> <privilege><plsql:connect/></privilege> </ace> </acl>
例4-18は、前述のアクセス制御リストで付与された権限をDBA_NETWORK_ACL_PRIVILEGES
データ・ディクショナリ・ビューに表示する方法を示しています。
例4-18 DBA_NETWORK_ACL_PRIVILEGESビューを使用した付与権限の表示
ACL ACLID PRINCIPAL PRIVILEGE IS_GRANT INVERT START_DATE END_DATE ------------------------------------------ -------------------------------- ---------- ------- -------- ------- ---------- ---------- /sys/acls/us-example-com-permissions.xml 2EF86135D0E29B2AE040578CE4043250 ACCT_ MGR resolve true false /sys/acls/us-example-com-permissions.xml 2EF86135D0E29B2AE040578CE4043250 ACCT_ CLERK connect true false
例4-19は、アクセス制御リストのホスト割当てをDBA_NETWORK_ACLS
データ・ディクショナリ・ビューに表示する方法を示しています。
例4-19 DBA_NETWORK_ACLSビューを使用したホスト割当ての表示
HOST LOWER_PORT UPPER_PORT ACL ACLID -------------------- ---------- ---------- ------------------------------------------ -------------------------------- *.us.example.com /sys/acls/us-example-com-permissions.xml 2EF86135D0E29B2AE040578CE4043250 *.uk.example.com 80 99 /sys/acls/us-example-com-permissions.xml 2EF86135D0E29B2AE040578CE4043250
これらの例では、ACCT_MGR
ロールには第1のホストに対するresolve
権限があり、ACCT_CLERK
ロールには第1および第2のターゲット・ホストに対するconnect権限があります。ACCT_MGR
ロールには、第2のホストに対するresolve
権限がありません。これは、第2のホストへの割当てにはポート範囲が指定されているためです。
SQL*Plusを使用してアクセス制御リストの内容をチェックする方法は、『Oracle XML DB開発者ガイド』を参照してください。
アクセス制御リストをネットワーク・ホスト・コンピュータのグループに割り当てる場合は、アスタリスク(*)ワイルドカード文字を使用できます。たとえば、ドメインに属しているホスト・コンピュータには*.example.com
を入力し、IPサブネットに属しているIPアドレスには192.0.2.*
を入力します。アスタリスク・ワイルドカードは、最初(ドメインのピリオド(.)の前)または最後(IPサブネットのピリオド(.)の後)に配置する必要があります。たとえば、*.example.com
は有効ですが、*example.com
や*.example.*
は無効です。
ワイルドカード文字の使用は、同じホスト・コンピュータに割り当てられている複数のアクセス制御リストの優先順位に影響を与えることに注意してください。
ホスト・コンピュータとそのドメインに割り当てられている複数のアクセス制御リストでは、ホスト・コンピュータに割り当てられているアクセス制御リストが、ドメインに割り当てられているアクセス制御リストよりも優先されます。ドメインに割り当てられているアクセス制御リストの優先順位は、サブ・ドメインに割り当てられているアクセス制御リストの優先順位よりも低くなります。
たとえば、ホストserver.us.example.com
に割り当てられているアクセス制御リストが、そのドメインに割り当てられている他のアクセス制御リストに先行して最初に選択されます。追加のアクセス制御リストがサブ・ドメインに割り当てられていた場合、優先順位は次のようになります。
server.us.example.com
*.us.example.com
*.example.com
*.com
*
同様に、IPアドレス192.0.2.4
に対する優先順位は、次のようになります。
192.0.2.4
192.0.2.*
192.0.*
192.*
*
ポート範囲の指定があるアクセス制御リストがホスト・コンピュータ、ドメインまたはIPサブネットに割り当てられている場合、そのアクセス制御リストは、同じホスト、ドメインまたはIPサブネットに割り当てられているポート範囲の指定がないアクセス制御リストよりも優先されます。
たとえば、server.us.example.com
のポート80から99のいずれかのポートへのTCP接続では、ポート範囲外のserver.us.example.com
に割り当てられている他のアクセス制御リストに先行して、server.us.example.com
でポート80から99が割り当てられているアクセス制御リストが最初に選択されます。
データベース管理者は、DBA_NETWORK_ACL_PRIVILEGES
データ・ディクショナリ・ビューを使用して、アクセス制御リストでデータベース・ユーザーまたはロールに対して付与または拒否したネットワーク権限を問い合せ、それらの権限が特定の期間のみ有効かどうかを問い合せることができます。現時点でユーザーに権限が付与されているかどうか、ユーザーに割り当てられているロール、アクセス制御エントリの順序などを判断するために、ビューで提供される情報を使用したデータの組合せが必要になる場合があります。このような権限の評価を簡素化するために、次のDBMS_NETWORK_ACL_ADMIN
ファンクションを使用して、アクセス制御リストでユーザーに付与した権限をチェックできます。
CHECK_PRIVILEGE
: アクセス制御リストで、指定された権限が指定のユーザーに対して付与されているか、拒否されているかどうかをチェックします。このプロシージャは、アクセス制御リストをXML DBリポジトリ内のパスで識別します。パスが判明している単一のアクセス制御リストを評価する場合は、CHECK_PRIVILEGE
を使用します。
CHECK_PRIVILEGE_ACLID
: アクセス制御リストのオブジェクトIDを指定できること以外は、CHECK_PRIVILEGE
プロシージャと同じです。CHECK_PRIVILEGE_ACLID
データ・ディクショナリ・ビューを問い合せる際に複数のアクセス制御リストを評価する必要がある場合は、DBA_NETWORK_ACLS
を使用します。各アクセス制御リストについてCHECK_PRIVILEGE
を個別に使用するよりも、複数のアクセス制御リストについてCHECK_PRIVILEGE_ACLID
をコールするほうが高いパフォーマンスを確保できます。
データベース管理者権限のないユーザーには、アクセス制御リストにアクセスしたり、DBMS_NETWORK_ACL_ADMIN
の各ファンクションを起動する権限はありません。ただし、データベース管理者権限のないユーザーは、USER_NETWORK_ACL_PRIVILEGES
データ・ディクショナリ・ビューを問い合せて各自の権限をチェックすることはできます。
データベース管理者およびユーザーは、次のDBMS_NETWORK_ACL_UTILITY
ファンクションを使用して、ホストが所属しているドメインまたはIPサブネットのリストを生成し、ホストの割当てに従って優先順位別にアクセス制御リストをソートできます。
DOMAINS
: アクセス制御リストが、指定のネットワーク・ホスト、サブドメインまたはIPサブネットに対する権限に影響を与える可能性があるドメインまたはIPサブネットのリストを戻します。
DOMAIN_LEVEL
: 指定のホストのドメイン・レベルを戻します。
次の各項では、ユーザーがネットワーク・ホストに接続したり、ドメイン名を解決する際に必要な権限について、データベース管理者およびユーザーがチェックする方法を説明します。
データベース管理者は、DBA_NETWORK_ACLS
ビューを問い合せて、指定のホスト・コンピュータについてアクセス制御リストがあるかどうかを判断できます。このビューには、ネットワーク接続またはドメインへのアクセスを決定するアクセス制御リストが表示され、各アクセス制御リストについて、ユーザーのアクセス権限が付与されている(GRANTED
)か、拒否されている(DENIED
)か、あるいは適用外(NULL
)かを確認できます。このビューの問合せを実行できるのは、データベース管理者のみです。
ここでは、データベース管理者による、ネットワーク接続とドメイン名解決に関するユーザー権限のチェック方法について例を示します。
データベース管理者によるユーザーの接続権限のチェック
例4-20は、ユーザーpreston
によるwww.us.example.com
への接続について、データベース管理者がユーザーの権限をチェックする方法を示しています。CHECK_PRIVILEGE_ACLID
プロシージャのuser
パラメータに入力するユーザー名は、大/小文字が区別されることに注意してださい。この例では、PRESTON
というユーザー名は正しい入力ですが、Preston
やpreston
は誤りとなります。
次のように、DBA_USERS
データ・ディクショナリ・ビューを問い合せることで、現行のデータベース・インスタンス内のユーザーを確認できます。
SELECT USERNAME FROM DBA_USERS;
例4-20 管理者によるネットワーク・ホスト接続に関するユーザー権限のチェック
SELECT HOST, LOWER_PORT, UPPER_PORT, ACL, DECODE( DBMS_NETWORK_ACL_ADMIN.CHECK_PRIVILEGE_ACLID(aclid, 'PRESTON', 'connect'), 1, 'GRANTED', 0, 'DENIED', null) PRIVILEGE FROM DBA_NETWORK_ACLS WHERE host IN (SELECT * FROM TABLE(DBMS_NETWORK_ACL_UTILITY.DOMAINS('www.us.example.com'))) ORDER BY DBMS_NETWORK_ACL_UTILITY.DOMAIN_LEVEL(host) DESC, LOWER_PORT, UPPER_PORT; HOST LOWER_PORT UPPER_PORT ACL PRIVILEGE -------------------- ---------- ---------- -------------------- --------- www.us.example.com 80 80 /sys/acls/www.xml GRANTED www.us.example.com 3000 3999 /sys/acls/www.xml GRANTED www.us.example.com /sys/acls/www.xml GRANTED *.example.com /sys/acls/all.xml * /sys/acls/all.xml
この例では、ユーザーpreston
には、www.us.example.com
に対して検出されたすべてのネットワーク・ホスト接続について権限が付与されています。 ただし、preston
には、ポート80でのホスト接続についてはアクセス権が付与され、ポート3000から3999でのホスト接続についてはアクセス権が拒否されていると仮定した場合は、ポート80でのホスト接続用に1つのアクセス制御リストを作成し、ポート3000から3999でのホスト接続用に別のアクセス制御リストを作成する必要があります。
データベース管理者によるユーザーのドメイン名解決権限のチェック
例4-21は、ユーザーpreston
によるホストwww.us.example.com
のドメイン名の解決について、データベース管理者がユーザーの権限をチェックする方法を示しています。この例では、ポート範囲を指定せずにホストに割り当てられているアクセス制御リストのみが表示されています。これは、resolve
権限はポート範囲が指定されているアクセス制御リストでは無効なためです(CHECK_PRIVILEGE_ACLID
のuser
パラメータに入力するユーザー名は、大/小文字が区別されることに注意してください)。
例4-21 管理者によるドメイン名解決権限のチェック
SELECT HOST, ACL, DECODE( DBMS_NETWORK_ACL_ADMIN.CHECK_PRIVILEGE_ACLID(aclid, 'PRESTON', 'resolve'), 1, 'GRANTED', 0, 'DENIED', null) privilege FROM DBA_NETWORK_ACLS WHERE host IN (SELECT * FROM TABLE(DBMS_NETWORK_ACL_UTILITY.DOMAINS('www.us.example.com'))) AND LOWER_PORT IS NULL AND UPPER_PORT IS NULL ORDER BY DBMS_NETWORK_ACL_UTILITY.DOMAIN_LEVEL(host) DESC; HOST ACL PRIVILEGE -------------------- -------------------- --------- www.us.example.com /sys/acls/www.xml GRANTED *.example.com /sys/acls/all.xml * /sys/acls/all.xml
ユーザーは、USER_NETWORK_ACL_PRIVILEGES
ビューを問い合せて、各自のネットワークおよびドメインに関する権限をチェックできます。USER_NETWORK_ACL_PRIVILEGES
ビューはPUBLIC
です。したがって、このビューはすべてのユーザーが選択できます。
このビューにはアクセス制御リストは表示されません。このビューでは、ユーザーの権限ステータス(GRANTED
またはDENIED
)が評価され、NULL
の場合は除外されます。これは、ユーザーにとって、アクセス制御リストが適用されない時期は知る必要がないためです。つまり、アクセスが明示的に付与または拒否されているネットワーク・ホストのみがユーザーに表示されます。したがって、この出力には、データベース管理者向けのDBA_NETWORK_ACLS
ビューの出力に表示される*.example.com
および*
は表示されません。
ここでは、ユーザーによる、ネットワーク接続とドメイン名解決に関するユーザー権限のチェック方法について例を示します。
ユーザーによる各自のネットワーク接続権限のチェック
例4-22は、ユーザーpreston
が、www.us.example.com
への接続について、自分の権限をチェックする方法を示しています。
例4-22 ユーザーによるネットワーク・ホスト接続に関する権限のチェック
SELECT HOST, LOWER_PORT, UPPER_PORT, STATUS PRIVILEGE FROM USER_NETWORK_ACL_PRIVILEGES WHERE host IN (SELECT * FROM TABLE(DBMS_NETWORK_ACL_UTILITY.DOMAINS('www.us.example.com'))) AND PRIVILEGE = 'connect' ORDER BY DBMS_NETWORK_ACL_UTILITY.DOMAIN_LEVEL(host) DESC, LOWER_PORT; HOST LOWER_PORT UPPER_PORT ACL PRIVILEGE -------------------- ---------- ---------- -------------------- --------- www.us.example.com 80 80 /sys/acls/www.xml GRANTED www.us.example.com 3000 3999 /sys/acls/www.xml GRANTED www.us.example.com /sys/acls/www.xml GRANTED
ユーザーによる各自のドメイン名解決権限のチェック
例4-23は、ユーザーpreston
が、www.us.example.com
のドメイン名の解決について、自分の権限をチェックする方法を示しています。
例4-23 ユーザーによるドメイン名解決権限のチェック
SELECT host, status privilege FROM user_network_acl_privileges WHERE host IN (SELECT * FROM TABLE(DBMS_NETWORK_ACL_UTILITY.DOMAINS('www.us.example.com'))) AND privilege = 'resolve' ORDER BY DBMS_NETWORK_ACL_UTILITY.DOMAIN_LEVEL(host) DESC; HOST PRIVILEGE -------------------- --------- www.us.example.com GRANTED
デフォルトでは、ユーザーとロールに対する権限は、そのユーザーとロールのアクセス制御リスト内での物理的な位置に基づいて付与または拒否されます。1番目にリストされているユーザーまたはロールに対して権限が最初に付与または拒否され、2番目にリストされているユーザーまたはロールが次に処理され、その後も順に処理されます。たとえば、例4-17のコードでACCT_MGR
というロールと、sebastian
およびpreston
という2人のユーザーが定義され、次の順序でアクセス制御リストXMLファイルに記載されているとします。
<acl ...> ... <ace> <principal>ACCT_MGR</principal> <grant>true</grant> <privilege><plsql:connect/></privilege> </ace> <ace> <principal>SEBASTIAN</principal> <grant>false</grant> <privilege><plsql:connect/></privilege> </ace> <ace> <principal>PRESTON</principal> <grant>false</grant> <privilege><plsql:connect/></privilege> </ace> </acl>
最初にACCT_MGR
に権限が付与され、次にsebastian
への権限が拒否され、その後preston
への権限が拒否されます。ただし、sebastian
とpreston
にACCT_MGR
ロールが付与されている場合は、そのACCT_MGR
ロールがリストの最初に記載されるため、この2人のユーザーはログインできます。
この2人のユーザーにはacct_mgr
ロールが付与されていますが、それぞれの固有のジョブでは、www.example.com
ホストに対するアクセス権は不要です。位置が逆の場合(sebastian
とpreston
の後にacct_mgr
ロールが記載されている場合)は、これらのユーザーに対するネットワーク接続権限は拒否されることになります。CREATE_ACL
文およびADD_PRIVILEGE
文で、ACE
要素の物理的な位置に関係なく優先順位を設定するには、position
属性を使用します。
たとえば、次の文では、結果のXMLファイルにACE
要素が設定される順序は、次のようになります。
最初にsebastian
のACE
要素が記載されます。
次にpreston
のACE
要素が記載されます。
最後にacct_mgr
ロールが記載されます。
この場合、FALSE
に設定されている2人の付与権限はacct_mgr
ロールより前に評価されるため、いずれのユーザーも接続できません。
BEGIN DBMS_NETWORK_ACL_ADMIN.CREATE_ACL ( acl => 'us-example-com-permissions.xml', description => 'Network connection permission for ACCT_MGR and users'); principal => 'ACCT_MGR', is_grant => TRUE, privilege => 'connect'); DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE ( acl => 'us-example-com-permissions.xml' principal => 'SEBASTIAN', is_grant => FALSE, privilege => 'connect', position => 1); DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE ( acl => 'us-example-com-permissions.xml' principal => 'PRESTON', is_grant => FALSE, privilege => 'connect', position => 2); END;
表4-6に、既存のアクセス制御リストに関する情報の検索に使用できるデータ・ディクショナリ・ビューをリストします。これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
表4-6 アクセス制御リストに関する情報を表示するデータ・ディクショナリ・ビュー
ビュー | 説明 |
---|---|
ネットワーク・ホストに対するアクセス制御リスト割当てが表示されます。このビューの |
|
ネットワーク・ホストに現在割り当てられ、すべてのアクセス制御リストに定義されているネットワーク権限が表示されます。このビューの |
|
現行ユーザーがネットワーク・ホストにアクセスするためのネットワーク権限のステータスが表示されます。このビューの |
表4-7に、権限とロールの付与に関する情報を入手するために問合せ可能なデータ・ディクショナリ・ビューをリストします。これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
表4-7 権限とロールに関する付与情報が表示されるビュー
ビュー | 説明 |
---|---|
|
オブジェクト所有者、権限付与者または権限受領者が現行ユーザーまたは |
|
オブジェクト所有者または権限付与者が現行ユーザーである列オブジェクトの権限付与がリストされます。 |
|
権限受領者が現行ユーザーまたは |
|
権限受領者がユーザーまたは |
|
現行ユーザーが行ったオブジェクトの権限付与、または現行ユーザーが所有するオブジェクトに対する権限付与がすべてリストされます。 |
|
権限受領者がユーザーまたは |
|
データベース内の列オブジェクトの権限付与がすべて表示されます。 |
|
データベース内のすべてのオブジェクトに対するすべての権限付与がリストされます。 |
|
|
|
ユーザーとロールに付与されているロールがリストされます。 |
|
ユーザーとロールに付与されているシステム権限がリストされます。 |
|
このビューには、他のロールに付与されているロールが表示されます。表示される情報は、ユーザーがアクセス可能なロールに関するもののみです。 |
|
このビューには、ロールに付与されているシステム権限に関する情報が含まれています。表示される情報は、ユーザーがアクセス可能なロールに関するもののみです。 |
|
このビューには、ロールに付与されているオブジェクト権限に関する情報が含まれています。表示される情報は、ユーザーがアクセス可能なロールに関するもののみです。 |
|
オブジェクト所有者、権限付与者または権限受領者が現行ユーザーである列オブジェクトの権限付与が表示されます。 |
|
権限付与者が現行ユーザーである列オブジェクトの権限付与が表示されます。 |
|
権限受領者が現行ユーザーである列オブジェクトの権限付与が表示されます。 |
|
現行ユーザーに付与されているロールがリストされます。 |
|
権限受領者が現行ユーザーであるすべてのオブジェクトの権限付与がリストされます。 |
|
現行ユーザーに付与されているシステム権限がリストされます。 |
|
現行ユーザーが所有しているすべてのオブジェクトの権限付与がリストされます。 |
|
権限受領者が現行ユーザーであるオブジェクトの権限付与がリストされます。 |
|
ユーザーに対して現在使用可能になっている権限がリストされます。 |
|
ユーザーに対して現在使用可能になっているロールがリストされます。 |
ここでは、これらのビューの使用例をいくつか示します。各例では、次の文がすでに発行されていることを前提としています。
CREATE ROLE security_admin IDENTIFIED BY password;
GRANT CREATE PROFILE, ALTER PROFILE, DROP PROFILE,
CREATE ROLE, DROP ANY ROLE, GRANT ANY ROLE, AUDIT ANY,
AUDIT SYSTEM, CREATE USER, BECOME USER, ALTER USER, DROP USER
TO security_admin WITH ADMIN OPTION;
GRANT SELECT, DELETE ON SYS.AUD$ TO security_admin;
GRANT security_admin, CREATE SESSION TO swilliams;
GRANT security_admin TO system_administrator;
GRANT CREATE SESSION TO jward;
GRANT SELECT, DELETE ON emp TO jward;
GRANT INSERT (ename, job) ON emp TO swilliams, jward;
次の問合せを実行すると、ロールとユーザーに対して付与されているシステム権限がすべて表示されます。
SELECT * FROM DBA_SYS_PRIVS; GRANTEE PRIVILEGE ADM -------------- --------------------------------- --- SECURITY_ADMIN ALTER PROFILE YES SECURITY_ADMIN ALTER USER YES SECURITY_ADMIN AUDIT ANY YES SECURITY_ADMIN AUDIT SYSTEM YES SECURITY_ADMIN BECOME USER YES SECURITY_ADMIN CREATE PROFILE YES SECURITY_ADMIN CREATE ROLE YES SECURITY_ADMIN CREATE USER YES SECURITY_ADMIN DROP ANY ROLE YES SECURITY_ADMIN DROP PROFILE YES SECURITY_ADMIN DROP USER YES SECURITY_ADMIN GRANT ANY ROLE YES SWILLIAMS CREATE SESSION NO JWARD CREATE SESSION NO
次の問合せを実行すると、ユーザーと他のロールに対して付与されているロールがすべて表示されます。
SELECT * FROM DBA_ROLE_PRIVS; GRANTEE GRANTED_ROLE ADM ------------------ ------------------------------------ --- SWILLIAMS SECURITY_ADMIN NO
次の問合せを実行すると、特定のユーザーに対して付与されているオブジェクト権限(列固有の権限を除く)がすべて表示されます。
SELECT TABLE_NAME, PRIVILEGE, GRANTABLE FROM DBA_TAB_PRIVS WHERE GRANTEE = 'jward'; TABLE_NAME PRIVILEGE GRANTABLE ----------- ------------ ---------- EMP SELECT NO EMP DELETE NO
付与されている列固有の権限をすべて表示するには、次の問合せを使用します。
SELECT GRANTEE, TABLE_NAME, COLUMN_NAME, PRIVILEGE FROM DBA_COL_PRIVS; GRANTEE TABLE_NAME COLUMN_NAME PRIVILEGE ----------- ------------ ------------- -------------- SWILLIAMS EMP ENAME INSERT SWILLIAMS EMP JOB INSERT JWARD EMP NAME INSERT JWARD EMP JOB INSERT
次の問合せを実行すると、発行者が現在使用できるロールがすべてリストされます。
SELECT * FROM SESSION_ROLES;
ユーザーswilliams
に対してsecurity_admin
ロールが使用可能になっている場合に、この問合せを実行すると、Oracle Databaseから次の情報が戻されます。
ROLE ------------------------------ SECURITY_ADMIN
次の問合せを実行すると、発行者のセキュリティ・ドメインで現在使用可能なシステム権限がすべて表示されます。これには、明示的に付与されている権限と使用可能なロールから付与された権限の両方が含まれています。
SELECT * FROM SESSION_PRIVS;
ユーザーswilliams
に対してsecurity_admin
ロールが使用可能になっている場合に、この問合せを実行すると、Oracle Databaseから次の結果が戻されます。
PRIVILEGE ---------------------------------------- AUDIT SYSTEM CREATE SESSION CREATE USER BECOME USER ALTER USER DROP USER CREATE ROLE DROP ANY ROLE GRANT ANY ROLE AUDIT ANY CREATE PROFILE ALTER PROFILE DROP PROFILE
ユーザーswilliams
に対してsecurity_admin
ロールが使用禁止になっている場合、最初の問合せでは何も表示されず、2番目の問合せではCREATE SESSION
権限の付与に関する行が1行のみ表示されます。
DBA_ROLES
データ・ディクショナリ・ビューを使用すると、データベースのすべてのロールと各ロールに対して使用されている認証を表示できます。たとえば、次の問合せを実行すると、データベース内のすべてのロールが表示されます。
SELECT * FROM DBA_ROLES; ROLE PASSWORD ---------------- -------- CONNECT NO RESOURCE NO DBA NO SECURITY_ADMIN YES
ROLE_ROLE_PRIVS
、ROLE_SYS_PRIVS
およびROLE_TAB_PRIVS
の各データ・ディクショナリ・ビューには、ロールの権限ドメインに関する情報が含まれています。たとえば、次の問合せを実行すると、system_admin
ロールに付与されているロールがすべて表示されます。
SELECT GRANTED_ROLE, ADMIN_OPTION FROM ROLE_ROLE_PRIVS WHERE ROLE = 'SYSTEM_ADMIN'; GRANTED_ROLE ADM ---------------- ---- SECURITY_ADMIN NO
次の問合せを実行すると、security_admin
ロールに付与されているシステム権限がすべて表示されます。
SELECT * FROM ROLE_SYS_PRIVS WHERE ROLE = 'SECURITY_ADMIN'; ROLE PRIVILEGE ADM ----------------------- ----------------------------- --- SECURITY_ADMIN ALTER PROFILE YES SECURITY_ADMIN ALTER USER YES SECURITY_ADMIN AUDIT ANY YES SECURITY_ADMIN AUDIT SYSTEM YES SECURITY_ADMIN BECOME USER YES SECURITY_ADMIN CREATE PROFILE YES SECURITY_ADMIN CREATE ROLE YES SECURITY_ADMIN CREATE USER YES SECURITY_ADMIN DROP ANY ROLE YES SECURITY_ADMIN DROP PROFILE YES SECURITY_ADMIN DROP USER YES SECURITY_ADMIN GRANT ANY ROLE YES
次の問合せを実行すると、security_admin
ロールに付与されているオブジェクト権限がすべて表示されます。
SELECT TABLE_NAME, PRIVILEGE FROM ROLE_TAB_PRIVS WHERE ROLE = 'SECURITY_ADMIN'; TABLE_NAME PRIVILEGE --------------------------- ---------------- AUD$ DELETE AUD$ SELECT
ROLE_ROLE_PRIVS
、ROLE_SYS_PRIVS
およびROLE_TAB_PRIVS
の各ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。