ヘッダーをスキップ
Oracle® Databaseセキュリティ・ガイド
12cリリース1 (12.1)
B71285-04
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

4 権限とロール認可の構成

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


関連項目:


権限とロールの概要

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

  • データへのアクセス、処理または変更を特定のユーザーにのみ許可します。

  • ユーザーによるアクセスまたは操作に様々な制限を適用します。ユーザーに適用(または除外)する制限は、スキーマ、表または行などのオブジェクトに適用できます。

ユーザー権限とは、特定タイプのSQL文を実行する権利、別のユーザーのオブジェクトにアクセスする権利、PL/SQLパッケージを実行する権利などを指します。権限のタイプは、Oracle Databaseによって定義されています。

ロールは、ユーザー(通常は管理者)が権限や他のロールをグループ化するために作成します。ロールを使用すると、複数の権限またはロールをユーザーに簡単に付与できます。

ここでは、次の一般的なカテゴリについて説明します。

  • システム権限。この権限の受領者は、データベースで標準的な管理作業を実行できます。権限受領者は信頼できるユーザーのみに制限してください。権限について説明している次の項を参照してください。

  • ロール。ロールでは、複数の権限やロールがグループ化されるため、複数のユーザーに対して権限を同時に付与したり、取り消すことができます。ユーザーによるロールの使用を可能にするには、そのユーザーに対してロールを使用可能にしておく必要があります。詳細は、次の各項を参照してください。

  • オブジェクト権限。オブジェクトの各タイプには、オブジェクト権限が対応付けられています。異なるタイプのオブジェクト権限を管理する方法は、「オブジェクト権限の管理」を参照してください。

  • 表権限。これらの権限によって、DML (データ操作言語)またはDDL (データ定義言語)レベルでセキュリティが有効になります。表権限の管理方法の詳細は、「表権限の管理」を参照してください。

  • 表示権限。DMLオブジェクト権限は、表の場合と同様にビューに対しても適用できます。詳細は、「表示権限の管理」を参照してください。

  • プロシージャ権限。スタンドアロン・プロシージャ、ファンクションを含め、プロシージャにはEXECUTE権限を付与できます。詳細は、「プロシージャ権限の管理」を参照してください。

  • タイプ権限。システム権限は名前付きタイプ(オブジェクト・タイプ、VARRAYおよびネストした表)に付与できます。詳細は、「タイプ権限の管理」を参照してください。

権限付与の対象者

権限をユーザーに付与すると、そのユーザーはそれぞれの業務に必要な作業を実行できます。なお、権限は、必要な作業を実行する上でその権限が必要なユーザーにのみ付与してください。必要でない権限まで付与すると、セキュリティを維持できなくなる可能性があります。たとえば、管理作業を実行しないユーザーには、SYSDBA管理権限またはSYSOPER権限を付与しないでください。

ユーザーは次の2つの方法で権限を受け取ることができます。

  • 権限を明示的にユーザーに付与します。たとえば、employees表にレコードを挿入する権限を、ユーザーpsmithに明示的に付与できます。

  • 権限をロール(名前付きの権限グループ)に付与した上で、そのロールを1人以上のユーザーに付与します。たとえば、employees表からレコードを選択、挿入、更新および削除する権限を、clerkという名前のロールに付与し、このロールをユーザーpsmithrobertに付与できます。

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


関連項目:

  • 権限を付与する際に従うベスト・プラクティスは、「ユーザー・アカウントと権限の保護に関するガイドライン」を参照してください。

  • 過度の権限付与が懸念される場合は、『Oracle Database Vault管理者ガイド』を参照してください。

  • システム権限の完全なリストとその詳細は、『Oracle Database SQL言語リファレンス』を参照してください。


Oracleマルチテナント・オプションが権限に影響を与えるしくみ

マルチテナント環境では、共通ユーザーを含むすべてのユーザーは、現在のコンテナ内でのみ権限を実行できます。ただし、ルートに接続されているユーザーは、他のプラガブル・データベース(PDB)に影響を与える特定の操作を実行できます。これらの操作には、ALTER PLUGGABLE DATABASECREATE USERCREATE ROLEおよびALTER USERが含まれます。共通ユーザーは、これらの操作を可能にする共通権限付与を処理する必要があります。ルートに接続されている共通ユーザーは、ビューにアクセスするために必要な権限を付与されていて、様々なPDBに関するデータを表示できるようにCONTAINER_DATA属性が設定されている場合、ルートのコンテナ・データ・オブジェクト(たとえば、マルチテナント・コンテナ・データベース(CDB)・ビューやV$ビューなど)を介してPDBに関するメタデータを確認できます。共通ユーザーは、PDBの表またはビューに問合せできません。

共通ユーザーは、他のPDBの権限を実行できません。必要なPDBに最初に切り替えて、そこから権限を実行する必要があります。異なるコンテナに切り替えるには、共通ユーザーにSET CONTAINER権限が必要です。また、共通ユーザーは、そのPDBのCREATE SESSION権限に応じて、現在の初期コンテナがこのユーザーが必要とするコンテナである新しいデータベース・セッションを開始できます。

共通ユーザーに付与された共通権限が個々のPDBに構成されたセキュリティを妨げる場合があるので注意してください。


関連項目:


管理権限の管理

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

管理権限について

業務分離を強化するために、Oracle Databaseは、バックアップおよびリカバリ、Oracle Data Guard、透過的データ管理(TDE)の暗号化鍵管理などの特定の管理タスクに応じて調整される一連の管理権限を提供します。

以前のリリースでは、これらのタスクを実行するSYSDBA管理権限が必要でした。下位互換性をサポートするには、これらのタスクのSYSDBA権限を引き続き使用できますが、この項で説明する権限を使用することをお薦めします。

管理権限の使用は強制的に監査されます。詳細は、「管理ユーザーの監査」を参照してください。

ユーザーへの管理権限の付与

すべての強力な権限と同様に、管理権限は信頼できるユーザーのみに付与してください。ただし、名前に非ASCII文字(HÜBERという名前に含まれるウムラウトなど)を使用しているユーザーには制限があります。こうしたユーザーに管理権限を付与することは可能ですが、Oracle Databaseインスタンスが停止した場合、名前に非ASCII文字を使用しているユーザーには、付与されている権限を使用した認証がサポートされません。データベース・インスタンスが稼働中であれば、この認証はサポートされます。

通常のデータベース操作のためのSYSDBAおよびSYSOPER管理権限

SYSDBAおよびSYSOPER管理権限では、データベースの起動および停止、サーバー・パラメータ・ファイル(SPFILE)の作成、データベース・アーカイブ・ログの変更などの様々な標準データベース操作を実行できます。


関連項目:

SYSDBAおよびSYSOPER管理権限の詳細は、『Oracle Database管理者ガイド』を参照してください。

バックアップおよびリカバリ操作のSYSBACKUP管理権限

Oracle Recovery Manager (RMAN)およびSQL*Plusを使用したバックアップおよびリカバリ操作を実行するには、SYSBACKUP管理権限でログインします。パスワードを使用してSYSBACKUPとしてデータベースに接続するには、そのパスワード・ファイルを作成する必要があります。パスワード・ファイルの作成の詳細は、『Oracle Database管理者ガイド』を参照してください。

この権限では、次の操作を実行できます。

  • STARTUP

  • SHUTDOWN

  • ALTER DATABASE

  • ALTER SYSTEM

  • ALTER SESSION

  • ALTER TABLESPACE

  • CREATE CONTROLFILE

  • CREATE ANY DIRECTORY

  • CREATE ANY TABLE

  • CREATE ANY CLUSTER

  • CREATE PFILE

  • CREATE RESTORE POINT(GUARANTEEDリストア・ポイントを含む)

  • CREATE SESSION

  • CREATE SPFILE

  • DROP DATABASE

  • DROP TABLESPACE

  • DROP RESTORE POINT(GUARANTEEDリストア・ポイントを含む)

  • FLASHBACK DATABASE

  • RESUMABLE

  • UNLIMITED TABLESPACE

  • SELECT ANY DICTIONARY

  • SELECT ANY TRANSACTION

  • SELECT

    • X$表(つまり、固定表)

    • V$およびGV$ビュー(つまり、動的パフォーマンス・ビュー)

    • APPQOSSYS.WLM_CLASSIFIER_PLAN

    • SYSTEM.LOGSTDBY$PARAMETERS

  • DELETE/INSERT

    • SYS.APPLY$_SOURCE_SCHEMA

    • SYSTEM.LOGSTDBY$PARAMETERS

  • EXECUTE

    • SYS.DBMS_BACKUP_RESTORE

    • SYS.DBMS_RCVMAN

    • SYS.DBMS_DATAPUMP

    • SYS.DBMS_IR

    • SYS.DBMS_PIPE

    • SYS.SYS_ERROR

    • SYS.DBMS_TTS

    • SYS.DBMS_TDB

    • SYS.DBMS_PLUGTS

    • SYS.DBMS_PLUGTSP

  • SELECT_CATALOG_ROLE

また、SYSBACKUP権限では、データベースをオープンしていない場合でもデータベースに接続できます。


関連項目:

バックアップおよびリカバリ操作の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

Oracle Data Guard操作のSYSDG管理権限

SYSDG管理権限を持つSYSDGユーザーとしてログインして、Data Guard操作を実行します。Data Guard BrokerまたはDGMGRLコマンドライン・インタフェースでこの権限を使用できます。パスワードを使用してSYSDGとしてデータベースに接続するには、そのパスワード・ファイルを作成する必要があります。パスワード・ファイルの作成の詳細は、『Oracle Database管理者ガイド』を参照してください。

SYSDG権限では、次の操作を実行できます。

  • STARTUP

  • SHUTDOWN

  • ALTER DATABASE

  • ALTER SESSION

  • ALTER SYSTEM

  • CREATE RESTORE POINT(GUARANTEEDリストア・ポイントを含む)

  • CREATE SESSION

  • DROP RESTORE POINT(GUARANTEEDリストア・ポイントを含む)

  • FLASHBACK DATABASE

  • SELECT ANY DICTIONARY

  • SELECT

    • X$表(つまり、固定表)

    • V$およびGV$ビュー(つまり、動的パフォーマンス・ビュー)

    • APPQOSSYS.WLM_CLASSIFIER_PLAN

  • DELETE

    • APPQOSSYS.WLM_CLASSIFIER_PLAN

  • EXECUTE

    • SYS.DBMS_DRS

また、SYSDG権限では、データベースをオープンしていない場合でもデータベースに接続できます。


関連項目:

Oracle Data Guardの詳細は、Oracle Data Guard概要および管理を参照

透過的データ暗号化のSYSKM管理権限

SYSKM管理権限により、SYSKMユーザーは、透過的データ暗号化のウォレット操作を管理できます。パスワードを使用してSYSKMとしてデータベースに接続するには、そのパスワード・ファイルを作成する必要があります。パスワード・ファイルの作成の詳細は、『Oracle Database管理者ガイド』を参照してください。

SYSKM管理権限では、次の操作を実行できます。

  • ADMINISTER KEY MANAGEMENT

  • CREATE SESSION

  • SELECT(データベースをオープンしている場合のみ)

    • SYS.V$ENCRYPTED_TABLESPACES

    • SYS.V$ENCRYPTION_WALLET

    • SYS.V$WALLET

    • SYS.V$ENCRYPTION_KEYS

    • SYS.V$CLIENT_SECRETS

    • SYS.DBA_ENCRYPTION_KEY_USAGE

また、SYSKM権限では、データベースをオープンしていない場合でもデータベースに接続できます。


関連項目:

透過的データ暗号化の詳細は、『Oracle Database Advanced Securityガイド』を参照してください。

システム権限の管理

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

システム権限の概要

システム権限とは、特定のアクションを実行する権限、または特定のタイプのスキーマ・オブジェクトに対してアクションを実行する権限のことです。たとえば、表領域を作成する権限や、データベース内の任意の表から行を削除する権限などがシステム権限です。

システム権限には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_ACCESSIBILITYFALSEに設定すると、任意のスキーマ内のオブジェクトへのアクセスを可能にするシステム権限(たとえば、CREATE ANY PROCEDUREのようなANY権限を持つユーザー)ではSYSスキーマ内のオブジェクトへのアクセスが許可されません。これは、SYSスキーマ内のオブジェクト(データ・ディクショナリ・オブジェクト)へのアクセスがSYSDBA管理権限を使用して接続するユーザーに制限されていることを意味します。SYSユーザーはSYSDBA権限とSYSOPER権限のどちらかでログインする必要があることに注意してください。それ以外の場合、 ORA-28009「SYSでの接続はSYSDBAまたはSYSOPERで行う必要があります」エラーが発生します。O7_DICTIONARY_ACCESSIBILITYTRUEに設定すると、データベースにユーザーSYSとしてログインできるようになり、SYSDBA権限やSYSOPER権限を指定する必要もありません。

他のスキーマのオブジェクトへのアクセスを提供するシステム権限で、他のユーザーがSYSスキーマ内のオブジェクトにアクセスすることはできません。たとえば、SELECT ANY TABLE権限を持つユーザーは、他のスキーマのビューや表にはアクセスできますが、ディクショナリ・オブジェクト(動的パフォーマンス・ビューの実表、通常のビュー、パッケージおよびシノニム)は選択できません。ただし、これらのユーザーは、明示的なオブジェクト権限を付与することで、SYSスキーマ内のオブジェクトにアクセスできるようになります。

O7_DICTIONARY_ACCESSIBILITY初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

SYSスキーマ内のオブジェクトへのアクセスの許可

明示的なオブジェクト権限のあるユーザーまたは管理権限で接続しているユーザー(SYSDBA)は、SYSスキーマ内のオブジェクトにアクセスできます。

表4-1に、SYSスキーマ内のオブジェクトへのアクセスが必要なユーザーに対して付与できるロールをリストします。

表4-1 SYSスキーマ・オブジェクトにアクセスできるロール

ロール 説明

SELECT_CATALOG_ROLE

このロールを付与されたユーザーには、データ・ディクショナリ・ビューに対するSELECT権限が与えられます。

EXECUTE_CATALOG_ROLE

このロールを付与されたユーザーには、データ・ディクショナリ内にあるパッケージとプロシージャに対するEXECUTE権限が与えられます。

DELETE_CATALOG_ROLE

このロールを付与されたユーザーは、システム監査表SYS.AUD$およびSYS.FGA_LOG$からレコードを削除できます。

注意: Oracle Database 12cリリース1 (12.1)では、DELETE_CATALOG_ROLEロールは非推奨です。


さらにSELECT ANY DICTIONARYシステム権限を、SYSスキーマで作成された表にアクセスが必要なユーザーに付与できます。このシステム権限により、SYSスキーマのあらゆるオブジェクト(そのスキーマに作成された表を含む)への問合せアクセスが可能になります。このシステム権限は、これを必要とする各ユーザーへ個別に付与する必要があります。これはGRANT ALL PRIVILEGESには含まれていませんが、ロールを通じて付与できます。


注意:

これらのロールおよびSELECT ANY DICTIONARYシステム権限は、悪用されるとシステムの整合性が損われる危険があるため、付与する際には十分な注意が必要です。

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

システム権限は、ユーザーとロールに対して付与したり、取り消すことができます。システム権限をロールに付与すると、そのロールを使用してシステム権限を行使できます。たとえば、ロールを使用すると権限を選択的に使用できるようになります。「ロールの保護に関するガイドライン」で説明する業務分離のガイドラインに従っていることを確認してください。

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

  • SQL文のGRANTおよびREVOKE

  • Oracle Enterprise Manager Cloud Control


関連項目:


システム権限を付与したり、取り消すことができるユーザー

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

  • ADMIN OPTIONによって特定のシステム権限を付与されているユーザー

  • GRANT ANY PRIVILEGEシステム権限を付与されているユーザー

そのため、これらの権限は信頼できるユーザーにのみ付与してください。

ANY権限とPUBLICロールの概要

ANYキーワードを使用するシステム権限を使用すると、データベース内のオブジェクトのカテゴリ全体に対して権限を設定できます。たとえば、CREATE ANY PROCEDUREシステム権限により、ユーザーはデータベース内のどこにでもプロシージャを作成可能になります。ANY権限を持つユーザーが作成したオブジェクトの動作は、そのオブジェクトが作成されたスキーマに限定されません。たとえば、ユーザーJSMITHにはCREATE ANY PROCEDURE権限があり、プロシージャをスキーマJONESに作成すると、そのプロシージャはJONESとして実行されることになります。ただし、JONESJSMITHによって作成されたプロシージャがJONESとして機能していることに気付かない可能性があります。JONESDBA権限が付与されている場合は、JSMITHJONESとしてプロシージャを実行することで、セキュリティ違反が発生する可能性があります。

PUBLICロールは、データベース・ユーザー・アカウントが作成されるときすべてのアカウントに自動的に与えられる特別なロールです。デフォルトでは付与されている権限がありませんが、多数の付与があり、ほとんどがJavaオブジェクトに対する付与です。PUBLICロールは削除できません。また、ユーザー・アカウントは常にこのロールを前提とするため、このロールの手動の付与や取消しは意味がありません。PUBLICロールはすべてのデータベース・ユーザー・アカウントが前提とするため、DBA_ROLESおよびSESSION_ROLESデータ・ディクショナリ・ビューには表示されません。

PUBLICロールに権限を付与できますが、付与した権限はOracleデータベースのすべてのユーザーが利用できるようになることに注意してください。このため、PUBLICロールに権限を付与するとき、特にANY権限やシステム権限のように強力な権限の場合は注意してください。たとえば、JSMITHCREATE PUBLIC SYNONYMシステム権限を持っている場合、他の誰もが使用するとわかっているインタフェースを再定義し、それから自分で作成したPUBLIC SYNONYMでこのインタフェースを指し示すことができます。ユーザーは正しいインタフェースではなくJSMITHのインタフェースにアクセスし、ユーザーのログイン資格証明が盗まれるなど、不正な行為が実行される可能性があります。

この種の権限は非常に強力であるため、不適切な個人に付与するとセキュリティ上のリスクが発生する可能性があります。ANYまたはPUBLICを使用した権限の付与には注意が必要です。他のすべての権限と同様に、これらの権限をユーザーに付与する場合は、「最低限の権限」を付与する原則に従ってください。

強力なANYシステム権限を1つ以上持つユーザーからデータ・ディクショナリ(SYSスキーマの内容)を保護するには、O7_DICTIONARY_ACCESSIBILITY初期化パラメータをFALSEに設定します。ALTER SYSTEM文を使用するか、initSID.oraファイルを変更して、このパラメータを設定できます。

共通およびローカルに付与される権限の管理

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


関連項目:

共通権限付与およびローカル権限付与の概要は、『Oracle Database概要』を参照してください。

共通およびローカルに付与される権限について

マルチテナント環境では、共通ユーザーローカル・ユーザーの両方は、相互に権限を付与できます。権限自体は、共通でもローカルでもありません。権限がどのように適用されるかは、権限が共通に付与されるか、ローカルに付与されるかによって異なります。

共通に付与される権限の場合:

  • 共通に付与される権限は、既存および将来のすべてのコンテナで使用できます。

  • 権限を共通に付与できるのは共通ユーザーのみで、権限受領者が共通の場合のみです。

  • 共通ユーザーは、他の共通ユーザーまたは共通ロールに権限を付与できます。

  • 権限付与者は、ルートに接続して、GRANT文のCONTAINER=ALLを指定する必要があります。

  • システム権限とオブジェクト権限は、どちらも共通に付与できます。(オブジェクト権限は、指定したオブジェクトに関してのみ実現化します。)

  • 共通ユーザーを指定されたコンテナに接続または切り替える場合、様々なアクティビティ(表の作成など)を実行するユーザーの機能は、共通に付与またはローカルに付与されたこのユーザーの両方の権限によって制御されます。

  • PUBLICには権限を共通に付与しないでください。

ローカルに付与される権限

  • ローカルに付与された権限は、それが付与されたコンテナでのみ使用できます。権限がルートで付与されている場合は、ルートにのみ適用されます。

  • 共通ユーザーおよびローカル・ユーザーは、どちらも権限をローカルに付与できます。

  • 共通ユーザーおよびローカル・ユーザーは、他の共通ロールまたはローカル・ロールに権限を付与できます。

  • 権限付与者は、コンテナに接続して、GRANT文のCONTAINER=CURRENTを指定する必要があります。

  • ユーザーは、他のユーザーまたはロール(共通およびローカルの両方)あるいはPUBLICロールにローカルに権限を付与できます。


関連項目:


共通に付与されるシステム権限の使用方法

ユーザーは、システム権限が付与されているPDB内でのみシステム権限を実行できます。たとえば、PDB B内の共通ユーザーAにシステム権限がローカルに付与されている場合、ユーザーAは、PDB Bに接続されている間のみ、その権限を実行できます。

システム権限は、ルートでのみ適用可能で、次の要件を満たしている場合は、既存および将来のすべてのPDBで適用できます。

  • システム権限付与者が共通ユーザーで、権限受領者が共通ユーザー、共通ロールまたはPUBLICロールです。事実上すべてのユーザーがシステム権限を使用できるようになるため、システム権限をPUBLICロールに共通に付与しないでください。

  • システム権限付与者は、共通に付与される権限に対してADMIN OPTIONを所有しています。

  • GRANT文には、CONTAINER=ALL句を含める必要があります。

例4-2は、CDBのPDBの表を作成するための共通ユーザーc##hr_adminへの共通権限の付与を実行する方法を示しています。

例4-2 共通ユーザーへのシステム権限の付与

CONNECT SYSTEM@root 
Enter password: password
Connected.

GRANT CREATE ANY TABLE TO c##hr_admin CONTAINER=ALL;

共通に付与されるオブジェクト権限の使用方法

次の要件を満たしている場合、共通オブジェクトのオブジェクト権限は、ルートおよび権限付与者が接続できるすべてのPDB (将来のPDBを含む)で共通オブジェクトに関連付けられているすべてのメタデータ・リンクまたはオブジェクト・リンクと、共通オブジェクトにのみ適用されます。

  • オブジェクト権限付与者が共通ユーザーで、権限受領者が共通ユーザー、共通ロールまたはPUBLICロールです。

  • オブジェクト権限付与者は、共通に付与される権限に対して共通に付与されるGRANT OPTIONを所有しています。

  • GRANT文には、CONTAINER=ALL句が含まれています。

例4-3は、現在のPDBのuser_data表から選択するための共通ユーザーc##hr_adminへのオブジェクト権限の付与方法を示しています。

例4-3 共通ユーザーへのオブジェクト権限の付与

CONNECT SYSTEM@hr_pdg
Enter password: password
Connected.

GRANT SELECT ON user_data TO c##hr_admin CONTAINER=CURRENT;

関連項目:


PDBへのアクセス権限の付与または取消し

マルチテナント環境で権限を付与するには、GRANTまたはREVOKE文にCONTAINER句を含めます。CONTAINERALLに設定すると、既存および将来のすべてのコンテナに権限が適用され、CURRENTに設定すると、ローカル・コンテナのみに権限が適用されます。ルートを除いて、CONTAINER句を省略すると、ローカル・コンテナに権限が適用されます。ルートからGRANT文を発行してCONTAINER句を省略すると、権限がローカルに適用されます。

例4-4は、既存および将来のすべてのコンテナでこの権限を使用できるように、共通ユーザーc##hr_adminCREATE TABLE権限を共通に付与する方法を示しています。

例4-4 マルチテナント環境での権限の付与

CONNECT SYSTEM@root
Enter password: password
Connected.

GRANT CREATE TABLE TO c##hr_admin CONTAINER=ALL;

関連項目:

GRANT文に関する詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

共通ユーザーによるコンテナ・オブジェクトの情報の表示

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

ルートに接続中のルート、CDBおよびPDBに関連するデータの表示

マルチテナント環境では、X$表、およびV$GV$およびCDB_*ビューの情報(ルートおよびCDB全体に関する情報を含む)は、共通ユーザーが問合せを実行する場合に、1つ以上のコンテナに制限できます。これは、他のPDBの機密情報を公開しない場合に便利です。この機能を有効にするために、Oracle Databaseでは、これらの表およびビューをコンテナ・データ・オブジェクトとして提供します。特定の表またはビューがコンテナ・データ・オブジェクトかどうかを確認するには、USER_|DBA_|ALL_VIEWS|TABLESディクショナリ・ビューのTABLE_NAMEVIEW_NAMEおよびCONTAINER_DATA 列を問い合せます。

デフォルト(ユーザー・レベル)およびオブジェクト固有のCONTAINER_DATA属性の情報を確認するには、例4-5に示すように、CDB_CONTAINER_DATAデータ・ディクショナリ・ビューを問い合せます。

例4-5 CONTAINER_DATA属性の情報の確認

COLUMN USERNAME FORMAT A15
COLUMN DEFAULT_ATTR FORMAT A7
COLUMN OWNER FORMAT A15
COLUMN OBJECT_NAME FORMAT A15
COLUMN ALL_CONTAINERS FORMAT A3
COLUMN CONTAINER_NAME FORMAT A10
COLUMN CON_ID FORMAT A6

SELECT USERNAME, DEFAULT_ATTR, OWNER, OBJECT_NAME, ALL_CONTAINERS, CONTAINER_NAME, CON_ID FROM CDB_CONTAINER_DATA ORDER BY OBJECT_NAME;

USERNAME        DEFAULT OWNER           OBJECT_NAME     ALL CONTAINERS CON_ID
--------------- ------- --------------- --------------- --- ---------- ------
C##HR_ADMIN     N       SYS             V$SESSION       N   CDB$ROOT        1
C##HR_ADMIN     N       SYS             V$SESSION       N   SALESPDB        1
C##HR_ADMIN     Y                                       N   HRPDB           1
C##HR_ADMIN     Y                                       N   CDB$ROOT        1
DBSNMP          Y                                       Y                   1
SYSTEM          Y                                       Y                   1

関連項目:

  • コンテナ・データ・オブジェクトの概要は、『Oracle Database概要』を参照してください。

  • DBA_CONTAINER_DATAデータ・ディクショナリ・ビューの詳細は、Oracle Databaseリファレンスを参照


共通ユーザーによる特定のPDBのデータのアクセス

共通ユーザーが特定のPDBのデータにアクセスするには、ルートでALTER USER文を実行する必要があります。

例4-6は、V$SESSIONビューを使用して、共通ユーザーc##hr_adminがアクセスできるすべてのコンテナ・データ・オブジェクトのCDB$ROOTSALES_PDBおよびhrpdbコンテナに関連する情報を表示できるALTER USER文を実行する方法を示しています。

例4-6 共通ユーザーによる特定のオブジェクト・データの表示

CONNECT SYSTEM@root
Enter password: password
Connected.

ALTER USER c##hr_admin
SET CONTAINER_DATA = (CDB$ROOT, SALESPDB, HRPDB) 
FOR V$SESSION CONTAINER=CURRENT;

次のように値を指定します。

  • CDB$ROOTSALES_PDBhrpdbは、ユーザーc##hr_adminがアクセスできるようにする必要のあるコンテナを示します。CDB$ROOTを含める必要があります。

  • FOR V$SESSIONは、共通ユーザーc##hr_adminが問い合せるCONTAINER_DATA動的ビューを指定します。

  • ルートに接続する場合にCONTAINER=ALLALTER USER文のデフォルトのため、CONTAINER = CURRENTを指定する必要がありますが、CONTAINER_DATA属性の変更はルートに制限する必要があります。


関連項目:

ALTER USER文に関する詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

共通ロールおよびローカル・ロールの管理

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

共通ロールおよびローカル・ロールの管理について

マルチテナント環境では、共通ロールとは、IDとパスワードがルートで作成されるロールで、既存および将来のすべてのコンテナで知られます。すべてのOracleから提供される事前定義ロールは共通ロールです。

ローカル・ロールは、1つのPDBにのみ存在し、このPDB内でのみ使用できます。共通に付与される権限は持ちません。

次のことに注意してください。

  • 共通ユーザーは、共通ロールを作成して、他の共通ユーザーおよびローカル・ユーザーに付与できます。

  • 共通ロールは、共通ユーザーに共通またはローカルに付与できます。

  • 共通ロールをローカル・ユーザーに付与する場合、共通ロールの権限がローカル・ユーザーのPDBにのみ適用されます。

  • ローカル・ユーザーは共通ロールを作成できませんが、共通ユーザーおよび他のローカル・ユーザーに共通ロールを付与できます。


関連項目:


共通ロールの使用方法

共通ロールは、マルチテナント環境のすべてのPDBで表示できます。次の要件を満たす場合、共通ロールに共通に付与された権限は、ルートおよび権限付与者が接続できるすべてのPDB(後で追加される可能性があるPDBを含む)で適用されます。

  • 権限付与者および権限受領者は、どちらも共通ユーザーです

  • 権限付与者は、次の権限を持ちます。

    • 共通に付与されるSET CONTAINER権限

    • 付与された共通ロールのADMIN OPTION

  • GRANT文には、CONTAINER=ALL句が含まれています。

共通ロールがローカルに付与された権限を含む場合、これらの権限は、共通ロールに付与されたPDB内にのみ適用されます。ロールがローカルの場合、共通ロールを付与できません。

たとえば、共通ユーザーc##hr_mgrに、CREATE TABLE権限が共通付与されているとします。これは、ユーザーc##hr_mgrが、ルートおよびマルチテナント環境のすべてのPDBに表を作成できるということです。一方、共通ユーザーc##hr_mgrに、hr_pdb PDBに対するCREATE TABLE権限がローカルで付与されているのみであれば、このユーザーは、hr_pdb PDBのみで表を作成できます。

マルチテナント環境でPUBLICロールが機能するしくみ

OracleによってPUBLICロールに設定されているすべての付与はローカルに実行されます。これにより、各PDBで個別にPUBLICロールに付与された権限およびロールを必要に応じて取り消すことができます。権限をPUBLICロールに付与する必要がある場合は、ローカルに付与します。PUBLICには権限を共通に付与しないでください。


関連項目:


共通ロールの作成、変更または削除に必要な権限

共通に付与されるCREATE ROLEALTER ROLEおよびDROP ROLE権限を持つ共通ユーザーのみが、共通ロールの作成、変更または削除ができます。共通ユーザーはローカル・ロールも作成できますが、作成されたPDBでのみそれらのロールを使用できます。

共通ロールの作成

共通ロールを作成するには、次のルールに従います。

  • ルートにいることを確認します。PDBから共通ロールを作成することはできません。ルートにいるかどうかを確認するには、show con_nameコマンドを実行します。CDB$ROOTと表示される必要があります。

  • 共通ロールに指定した名前は、C##またはc##で始まり、ASCIIまたはEDCDIC文字のみを含む必要があります。この要件はDBARESOURCEなど、Oracle Databaseによって提供される既存のロールの名前に適用されないことに注意してください。

  • オプションで、CONTAINER句をALLに設定します。ルートにいるかぎりは、CONTAINER = ALL句を省略しても、ロールは、デフォルトで共通ロールとして作成されます。

例4-7は、パスワード認証を行うc##sec_mgr共通ロールを作成します。

例4-7 owe

CONNECT SYSTEM@root
Enter password: password
Connected.

CREATE ROLE c##sec_admin IDENTIFIED BY password CONTAINER=ALL; 

ローカル・ロールの作成

ローカル・ロールを作成するには、次のルールに従います。

  • ローカル・ロールを作成するには、ロールを作成するPDBに接続して、CREATE ROLE権限を持つ必要があります。

  • ローカル・ロールに指定する名前を、C##またはc##で始めることはできません。

  • CREATE USER文にCONTAINER=CURRENTを含め、ローカル・ロールとしてロールを指定できます。PDBに接続しており、この句を省略すると、CONTAINER=CURRENT句が含まれます。

  • 共通ロールとローカル・ロールの名前を同じにすることはできません。ただし、異なるPDBのローカル・ロールに同じ名前を使用できます。既存のロールの名前を検索するには、CDB_ROLESおよびDBA_ROLESデータ・ディクショナリ・ビューを問い合せます。

例4-8に、ローカル・ロールの作成方法を示します。

例4-8 ローカル・ロールの作成

CONNECT SYSTEM@hrpdb
Enter password: password
Connected.

CREATE ROLE sec_admin CONTAINER=CURRENT; 

共通ロールおよびローカル・ロールの付与または取消し

共通ユーザーは、他の共通ユーザーへの共通ロールの付与および取消しを行うことができます。ローカル・ユーザーは、共通ロールを共通ユーザーを含むPDBのユーザーに付与できますが、これは、PDB内のみで適用されます。

例4/9は、共通ユーザーc##sec_adminへのすべてのコンテナで使用するAUDIT_ADMIN共通ロールの付与方法を示しています。

例4-9 すべてのコンテナでの共通ユーザーへの共通ロールの付与

CONNECT SYSTEM@root
Enter password: password
Connected.

GRANT AUDIT_ADMIN TO c##sec_admin CONTAINER=ALL;

同様に、例4-10は、ローカル・ユーザーaud_adminによる共通ユーザーc##sec_adminへのhrpdb PDB内で使用するAUDIT_ADMIN共通ロールの付与方法を示しています。

例4-10 現在のコンテナの共通ユーザーへの共通ロールの付与

CONNECT aud_admin@hrpdb
Enter password: password
Connected.

GRANT AUDIT_ADMIN TO c##sec_admin CONTAINER=CURRENT;

例4-11に、ローカル・ユーザーaud_adminがPDBからロールを取り消す方法を示します。CONTAINER句を省略すると、CURRENTが暗黙のうちに入れられます。

例4-11 ローカル・ロールの取消し

CONNECT aud_admin@hrpdb
Enter password: password
Connected.

REVOKE sec_admin FROM psmith CONTAINER=CURRENT;

ユーザー・ロールの管理

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

ユーザー・ロールの概要

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

ユーザー・ロールの概要

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

ロールの機能

ロールとは、ユーザーに権限を素早く簡単に付与するために便利なものです。Oracle Databaseで定義されているロールを使用することもできますが、必要な権限のみを含む独自のロールを作成すると、より継続的な制御が可能になります。Oracle Databaseで定義されているロールの権限は、Oracleによって変更または削除される場合があります。

ロールは、次の機能を備えています。

  • ロールには、システム権限またはオブジェクト権限を付与できます。

  • 任意のロールを任意のデータベース・ユーザーに付与できます。

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

  • 1つのロールを別のロールにも付与できます。ただし、ロールをそのロール自体に付与したり、循環的に付与することはできません。たとえば、role2があらかじめロールrole1に付与されている場合、ロールrole1をロールrole2に付与することはできません。

  • ロールがパスワード認証ロールまたはセキュア・アプリケーション・ロールでない場合は、ユーザーに間接的に付与できます。間接的に付与するロールとは、ユーザーにすでに付与されている別のロールを通じて同じユーザーに付与するロールのことです。たとえば、ユーザーpsmithrole1ロールを付与するとします。その後、role2ロールとrole3ロールをrole1ロールに付与します。これで、role2role3の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はパスワード付きのロールを作成することで、そのロールに付与されている権限が無許可で使用されるのを防止できます。通常、アプリケーションは起動時に適切なロールが使用可能になるように設計されます。そのため、アプリケーション・ユーザーは、アプリケーション・ロールのパスワードを知る必要がありません。


関連項目:

プロシージャに関する制限の詳細は、「ロールによるDDL使用の支援または制限」を参照してください。

ロールの通常の使用

通常は、次のいずれかの目的でロールを作成します。

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

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

図4-1の説明が続きます
「図4-1 ロールの一般的な使用方法」の説明

アプリケーション・ロールの一般的な使用方法

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

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

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

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

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

ユーザーのセキュリティ・ドメインには、対応するスキーマ内のすべてのスキーマ・オブジェクトに対する権限、ユーザーに付与された権限、そして現在使用可能なユーザーに付与されたロールの権限が含まれます。(ロールをあるユーザーに対して使用可能にすると同時に、他のユーザーに対して使用禁止にできます。)このドメインには、ロールPUBLICに付与された権限とロールも含まれます。PUBLICロールは、データベース内のすべてのユーザーを表します。

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

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

定義者権限を持つ名前付きブロックで使用されるロール

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

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


関連項目:

『Oracle Databaseリファレンス』

実行者権限を持つ名前付きブロックおよび無名PL/SQLブロックで使用されるロール

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


関連項目:

  • 実行者権限と定義者権限を使用して名前解決と権限チェックを行う方法については、『Oracle Database PL/SQL言語リファレンス』を参照してください。

  • PL/SQLの動的SQLの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。


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

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

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

  • DDL操作の実行をユーザーに許可するすべてのシステム権限およびオブジェクト権限は、ロールを介して受け取った場合でも使用可能。例:

    • システム権限: CREATE TABLECREATE 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のインストールで事前に定義されているロール

Oracle Databaseには、データベース管理を容易にする一連の事前定義ロールが用意されています。表4-3に示すこれらのロールは、データベース作成の一部である標準スクリプトの実行時に、Oracleデータベースに対して自動的に定義され、共通ロールとみなされます。他のオプションや製品をインストールすると、他の事前定義のロールが作成される場合があります。

表4-3 Oracle Databaseの事前定義ロール

事前定義のロール 説明

ADM_PARALLEL_EXECUTE_TASK

DBMS_PARALLEL_EXECUTE PL/SQLパッケージを使用して表のデータをパラレルに更新するための権限を提供します。

関連項目: DBMS_PARALLEL_EXECUTE PL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

AQ_ADMINISTRATOR_ROLE

アドバンスト・キューイングを管理するための権限を提供します。ENQUEUE ANY QUEUEDEQUEUE ANY QUEUEMANAGE ANY QUEUE、アドバンスト・キューイングの表に対するSELECT権限、およびアドバンスト・キューイングのパッケージに対するEXECUTE権限が含まれます。

AQ_USER_ROLE

サポートされていませんが、主にリリース8.0との互換性のために残されています。DBMS_AQおよびDBMS_AQINパッケージに対するEXECUTE権限を提供します。

AUDIT_ADMIN

統合およびファイングレイン監査ポリシーの作成、AUDITおよびNOAUDIT SQL文の使用、監査データの表示および監査証跡の管理を行う権限を提供します

関連項目: 「監査を実行できるユーザー」

AUDIT_VIEWER

監査データを表示および分析する権限を提供します

関連項目: 「監査を実行できるユーザー」

AUTHENTICATEDUSER

システムにログインしたユーザーを定義するために、XDBプロトコルで使用されます。

関連項目: このロールをDBUriServletセキュリティに使用する方法の詳細は、『Oracle XML DB開発者ガイド』を参照してください。

CAPTURE_ADMIN

権限分析ポリシーの作成および管理に必要な権限を提供します。

関連項目: 詳細は、『Oracle Database Vault管理者ガイド』を参照してください。

CDB_DBA

SET CONTAINERSELECT ON PDB_PLUG_IN_VIOLATIONSSELECT ON CDB_LOCAL_ADMIN_PRIVSなどのCDBの管理に必要な権限を提供します。サイトで追加の権限が必要な場合、ロール(共通またはローカル)を作成してこれらの権限に対応し、このロールをCDB_DBAロールに付与できます。

関連項目: CDBの管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

CONNECT

CREATE SESSIONシステム権限を提供します。

このロールは、Oracle Databaseの以前のリリースとの互換性を考慮して用意されています。このロールに組み込まれている権限は、DBA_SYS_PRIVSデータ・ディクショナリ・ビューを問い合せることで判別できます。

注意: このロールに依存せずに、データベース・セキュリティ用に独自のロールを設計することをお薦めします。このロールは、将来のリリースのOracle Databaseでは自動生成されない可能性があります。

関連項目: DBA_SYS_PRIVSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

CSW_USR_ROLE

Oracle SpatialのCatalog Services for the Web(CSW)コンポーネントを管理するユーザー権限を提供します。

関連項目: 詳細は、Oracle Spatial and Graph開発者ガイドを参照してください。

CTXAPP

Oracle Textの索引および索引プリファレンスの作成権限およびPL/SQLパッケージの使用権限を提供します。このロールはOracle Textユーザーに付与される必要があります。

関連項目: 詳細は、『Oracle Textアプリケーション開発者ガイド』を参照してください。

CWM_USER

Oracleデータ・ウェアハウスおよび意思決定支援で使用されるリポジトリ標準であるCommon Warehouse Metadata(CWM)の管理権限を提供します。

関連項目: 詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

DATAPUMP_EXP_FULL_DATABASE

Oracle Data Pumpを使用してOracleデータベースからデータをエクスポートする権限を提供します。

注意: このロールは非常に強力であり、データベース内の任意のスキーマの任意のデータへのユーザー・アクセスを提供します。このロールをユーザーに付与する場合は注意が必要です。

関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。

DATAPUMP_IMP_FULL_DATABASE

Oracle Data Pumpを使用してOracleデータベースにデータをインポートする権限を提供します。

注意: このロールは非常に強力であり、データベース内の任意のスキーマの任意のデータへのユーザー・アクセスを提供します。このロールをユーザーに付与する場合は注意が必要です。

関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。

DBA

ADMINオプションを使用して作成されたすべてのシステム権限を提供します。

このロールは、Oracle Databaseの以前のリリースとの互換性を考慮して用意されています。このロールに組み込まれている権限は、DBA_SYS_PRIVSデータ・ディクショナリ・ビューを問い合せることで判別できます。

注意: このロールに依存せずに、データベース・セキュリティ用に独自のロールを設計することをお薦めします。このロールは、将来のリリースのOracle Databaseでは自動生成されない可能性があります。

関連項目: DBA_SYS_PRIVSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

DBFS_ROLE

DBFS(データベース・ファイルシステム)パッケージおよびオブジェクトへのアクセスを提供します。

関連項目: 『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』

DELETE_CATALOG_ROLE

統合監査環境以外で、システム監査表(AUD$)のDELETE権限を提供します。

注意: Oracle Database 12cリリース1 (12.1)では、DELETE_CATALOG_ROLEロールは非推奨です。

EJBCLIENT

Javaストアド・プロシージャからEJBに接続する権限を提供します。

EM_EXPRESS_ALL

ユーザーは、Oracle Enterprise Manager (EM) Expressに接続して、EM Expressによって提供されるすべての機能(すべてのEM Express機能への読取りおよび書込みアクセス)を使用できます。EM_EXPRESS_ALLロールは、EM_EXPRESS_BASICロールを含みます。

関連項目: 詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

EM_EXRESS_BASIC

ユーザーは、EM Expressに接続して、読取り専用モードでページを表示できます。EM_EXPRESS_BASICロールは、SELECT_CATALOG_ROLEロールを含みます。

関連項目: 詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

EXECUTE_CATALOG_ROLE

データ・ディクショナリ内のオブジェクトに対するEXECUTE権限を提供します。

EXP_FULL_DATABASE

エクスポート・ユーティリティ(後継はOracle Data Pump)を使用してデータベースの全インポートおよび増分エクスポートを実行するために必要な権限を提供します。含まれる権限は、SELECT ANY TABLEBACKUP ANY TABLEEXECUTE ANY PROCEDUREEXECUTE ANY TYPEADMINISTER RESOURCE MANAGER、そして表SYS.INCVIDSYS.INCFILSYS.INCEXPに対するINSERTDELETE、およびUPDATEです。EXECUTE_CATALOG_ROLEおよびSELECT_CATALOG_ROLEロールも含みます。

このロールは、エクスポート・ユーティリティおよびインポート・ユーティリティを簡単に使用できるように用意されています。

注意: このロールは非常に強力であり、データベース内の任意のスキーマの任意のデータへのユーザー・アクセスを提供します。このロールをユーザーに付与する場合は注意が必要です。

関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。

GATHER_SYSTEM_STATISTICS

DBMS_STATS.GATHER_SYSTEM_STATISTICSプロシージャを使用して収集されるシステム統計の更新権限を提供します。

関連項目: オプティマイザ統計の管理の詳細は、Oracle Database SQLチューニング・ガイドを参照してください。

GLOBAL_AQ_USER_ROLE

Oracle Streams AQで使用されるLDAPサーバーへの接続を確立する権限を提供します。

関連項目: 詳細は、『Oracle Databaseアドバンスト・キューイング・ユーザーズ・ガイド』を参照してください。

HS_ADMIN_EXECUTE_ROLE

異機種間サービス(HS)PL/SQLパッケージの使用を希望するユーザーに対してEXECUTE権限を提供します。

関連項目: 詳細は、『Oracle Database Heterogeneous Connectivityユーザーズ・ガイド』を参照してください。

HS_ADMIN_ROLE

異機種間サービス(HS)PL/SQLパッケージの使用権限およびHS関連のデータ・ディクショナリ・ビューの問合せ権限を提供します。

関連項目: 詳細は、『Oracle Database Heterogeneous Connectivityユーザーズ・ガイド』を参照してください。

HS_ADMIN_SELECT_ROLE

異機種間サービスのデータ・ディクショナリ・ビューの問合せ権限を提供します。

関連項目: 詳細は、『Oracle Database Heterogeneous Connectivityユーザーズ・ガイド』を参照してください。

IMP_FULL_DATABASE

インポート・ユーティリティ(後継はOracle Data Pump)を使用してデータベースの全インポートを実行するために必要な権限を提供します。システム権限の詳細リスト(権限を表示するにはビューDBA_SYS_PRIVSを使用)と、ロールEXECUTE_CATALOG_ROLEおよびSELECT_CATALOG_ROLEが含まれます。

このロールは、エクスポート・ユーティリティおよびインポート・ユーティリティを簡単に使用できるように用意されています。

注意: このロールは非常に強力であり、データベース内の任意のスキーマの任意のデータへのユーザー・アクセスを提供します。このロールをユーザーに付与する場合は注意が必要です。

関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。

JAVADEBUGPRIV

Oracle Database Javaアプリケーション・デバッガの実行権限を提供します。

関連項目: Oracle Javaアプリケーションのセキュリティ管理の詳細は、『Oracle Database Java開発者ガイド』を参照してください。

JAVAIDPRIV

このリリースでは非推奨となりました。

JAVASYSPRIV

Oracle JVMで保護されたパッケージの更新を含む、Java 2を使用するための主要な権限を提供します。

関連項目: Oracle Javaアプリケーションのセキュリティ管理の詳細は、『Oracle Database Java開発者ガイド』を参照してください。

JAVAUSERPRIV

Java 2を使用するための制限された権限を提供します。

関連項目: Oracle Javaアプリケーションのセキュリティ管理の詳細は、『Oracle Database Java開発者ガイド』を参照してください。

JAVA_ADMIN

Oracle Database Javaアプリケーションのポリシー表を更新する管理権限を提供します。

関連項目: Oracle Javaアプリケーションのセキュリティ管理の詳細は、『Oracle Database Java開発者ガイド』を参照してください。

JAVA_DEPLOY

ncompおよびdeploynsユーティリティを使用してjavavm/adminディレクトリにncomp DLLをデプロイする権限を提供します。このロールを使用すると、javavm/deployおよびjavavm/adminディレクトリにアクセスできます。

関連項目: 詳細は、『Oracle Database開発ガイド』を参照してください。

JMXSERVER

データベース・セッションでJMXエージェントを起動およびメンテナンスする権限を提供します。

関連項目: Oracle Javaアプリケーションの管理の詳細は、『Oracle Database Java開発者ガイド』を参照してください。

LBAC_DBA

SA_SYSDBA PL/SQLパッケージの使用権限を提供します。

関連項目: 詳細は、『Oracle Label Security管理者ガイド』を参照してください。

LOGSTDBY_ADMINISTRATOR

SQL Apply(ロジカル・スタンバイ・データベース)環境を管理する管理権限を提供します。

関連項目: 詳細は、『Oracle Data Guard概要および管理』を参照してください。

OEM_ADVISOR

DBMS_SQLTUNE PL/SQLパッケージによってSQL Tuning Setを作成、削除、選択(読取り)、ロード(書込み)および削除する権限と、ADVISOR PL/SQLパッケージを使用してアドバイザ・フレームワークにアクセスする権限を提供します。

関連項目: 詳細は、Oracle Database SQLチューニング・ガイドを参照してください。

OEM_MONITOR

Oracle Enterprise Managerの管理エージェント・コンポーネントで必要とされる、データベースを監視および管理する権限を提供します。

関連項目: 詳細は、Oracle Database SQLチューニング・ガイドを参照してください。

OLAP_DBA

Oracle OLAPの異なるスキーマでディメンション・オブジェクトを作成する管理権限を提供します。

関連項目: 詳細は、『Oracle OLAPユーザーズ・ガイド』を参照してください。

OLAP_USER

アプリケーション開発者に対し、Oracle OLAPの独自のスキーマでディメンション・オブジェクトを作成する権限を提供します。

関連項目: 詳細は、『Oracle OLAPユーザーズ・ガイド』を参照してください。

OLAP_XS_ADMIN

Oracle OLAPのセキュリティの管理権限を提供します。

関連項目: 詳細は、『Oracle OLAPユーザーズ・ガイド』を参照してください。

OPTIMIZER_PROCESSING_RATE

DBMS_STATSパッケージのGATHER_PROCESSING_RATESET_PROCESSING_RATEおよびDELETE_PROCESSING_RATEプロシージャを実行する権限を提供します。これらのプロシージャは、自動的な並列度(Auto DOP)のシステムの処理率を管理します。Auto DOPは、これらの処理率を使用して、SQL文の最適な並列度を決定します。

関連項目: 詳細は、Oracle Database SQLチューニング・ガイドを参照してください。

ORDADMIN

Oracle Multimedia DICOMの管理権限を提供します。

関連項目: 『Oracle Multimedia DICOM開発者ガイド』

PDB_DBA

シードPDBから新しいPDBを作成する場合に作成されるローカル・ユーザーに自動的に付与されます。権限はこのロールに提供されません。

関連項目: シードを使用したPDBの作成の詳細は、『Oracle Database管理者ガイド』を参照してください。

PROVISIONER

Oracle Database Real Applicationセッションのグローバル・コールバックを登録および更新してプリンシパルをプロビジョニングする権限を提供します。

関連項目: 詳細は、『Oracle Database Real Application Security管理者および開発者ガイド』を参照してください。

RECOVERY_CATALOG_OWNER

リカバリ・カタログの所有者の権限を提供します。CREATE SESSIONALTER SESSIONCREATE SYNONYMCREATE VIEWCREATE DATABASE LINKCREATE TABLECREATE CLUSTERCREATE SEQUENCECREATE TRIGGER、およびCREATE PROCEDUREが含まれます。

RESOURCE

CREATE CLUSTERCREATE INDEXTYPECREATE OPERATORCREATE PROCEDURECREATE SEQUENCECREATE TABLECREATE TRIGGERCREATE TYPEの各システム権限を提供します。

RESOURCEUNLIMITED TABLESPACEシステム権限を提供しないことに注意してください。

このロールは、Oracle Databaseの以前のリリースとの互換性を考慮して用意されています。このロールに組み込まれている権限は、DBA_SYS_PRIVSデータ・ディクショナリ・ビューを問い合せることで判別できます。

注意: このロールに依存せずに、データベース・セキュリティ用に独自のロールを設計することをお薦めします。このロールは、将来のリリースのOracle Databaseでは自動生成されない可能性があります。

関連項目: DBA_SYS_PRIVSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

SCHEDULER_ADMIN

権限受領者がDBMS_SCHEDULERパッケージのプロシージャを実行できるようにします。すべてのジョブ・スケジューラ・システム権限が含まれ、DBAロールに含まれます。

関連項目: DBMS_SCHEDULERパッケージに関する詳細は、『Oracle Database管理者ガイド』を参照してください。

SELECT_CATALOG_ROLE

データ・ディクショナリ内のオブジェクトに対するSELECT権限を付与します。

SPATIAL_CSW_ADMIN

Oracle SpatialのCatalog Services for the Web(CSW)コンポーネントを管理する管理権限を提供します。

関連項目: 詳細は、Oracle Spatial and Graph開発者ガイドを参照してください。

SPATIAL_WFS_ADMIN

Oracle SpatialのWeb Feature Service(WFS)コンポーネントを管理する管理権限を提供します。

関連項目: 詳細は、Oracle Spatial and Graph開発者ガイドを参照してください。

WFS_USR_ROLE

Oracle SpatialのWeb Feature Service(WFS)コンポーネントに対するユーザー権限を提供します。

関連項目: 詳細は、Oracle Spatial and Graph開発者ガイドを参照してください。

WM_ADMIN_ROLE

Oracle Workspace Managerの管理権限を提供します。これにより、ユーザーはDBMS_WMプロシージャをすべてのバージョン対応表、作業領域、およびセーブポイントで、それぞれの所有者に関係なく実行できるようになります。また、ユーザーはWorkspace Managerに固有のシステム・パラメータも変更できるようになります。

関連項目: 詳細は、『Oracle Database Workspace Manager開発者ガイド』を参照してください。

XDBADMIN

権限受領者がXMLスキーマを、その所有者のみが使用したりアクセスするために登録するのではなく、グローバルに登録できるようにします。また権限受領者がOracle XML DB Repositoryにアクセスしているときはアクセス制御リスト(ACL)チェックを回避できるようにもします。

関連項目: XMLスキーマとXML DBリポジトリの詳細は、『Oracle XML DB開発者ガイド』を参照してください。

XDB_SET_INVOKER

権限受領者が実行者権限ハンドラを定義して、XMLリポジトリのトリガーのリソース構成を作成または更新できるようにします。デフォルトでは、このロールはDBAロールに付与されますが、XDBADMINロールには付与されません。

関連項目: Oracle DatabaseのXMLリポジトリのトリガーの詳細は、『Oracle XML DB開発者ガイド』を参照してください。

XDB_WEBSERVICES

権限受領者がHTTPSを使用してOracle DatabaseのWebサービスにアクセスできるようにします。ただし、パブリックなデータベース内のオブジェクトに対するユーザー・アクセスは提供されません。パブリック・アクセスを許可するには、ユーザーにXDB_WEBSERVICES_WITH_PUBLICロールを付与する必要があります。ユーザーがこれらのWebサービスを使用するには、SYSで、Webサービスのサーブレットを使用可能にする必要があります。

関連項目: Oracle DatabaseのWebサービスの詳細は、『Oracle XML DB開発者ガイド』を参照してください。

XDB_WEBSERVICES_OVER_HTTP

権限受領者がHTTPを使用してOracle DatabaseのWebサービスにアクセスできるようにします。ただし、パブリックなデータベース内のオブジェクトに対するユーザー・アクセスは提供されません。パブリック・アクセスを許可するには、ユーザーにXDB_WEBSERVICES_WITH_PUBLICロールを付与する必要があります。

関連項目: Oracle DatabaseのWebサービスの詳細は、『Oracle XML DB開発者ガイド』を参照してください。

XDB_WEBSERVICES_WITH_PUBLIC

権限受領者が、Oracle DatabaseのWebサービスを介してパブリック・オブジェクトにアクセスできるようにします。

関連項目: Oracle DatabaseのWebサービスの詳細は、『Oracle XML DB開発者ガイド』を参照してください。

XS_CACHE_ADMIN

Oracle Database Real Application Securityでは、権限受領者が中間層キャッシュを管理できます。XSAccessControllerクラスのcheckAcl(認可)メソッドの中間層レベルでのセキュリティ・ポリシーのキャッシュに必要です。このロールをアプリケーション接続ユーザーまたはReal Application Securityディスパッチャに付与します。

関連項目: 詳細は、『Oracle Database Real Application Security管理者および開発者ガイド』を参照してください。

XS_NSATTR_ADMIN

Oracle Database Real Application Securityでは、権限受領者がセッションのネームスペースおよび属性を管理および操作できます。このロールをReal Application Securityセッション・ユーザーに付与します。

関連項目: Real Application Securityセッションの管理の詳細は、『Oracle Database Real Application Security管理者および開発者ガイド』を参照してください。

XS_RESOURCE

Oracle Database Real Application Securityでは、権限受領者がXS_ACL PL/SQLパッケージを通じて付加されたスキーマのオブジェクトを管理できます。このパッケージは、アクセス制御リスト(ACL)を作成および管理するプロシージャを作成します。ADMIN SEC POLICY権限を含みます。Oracle Database RESOURCEロールと似ています。

関連項目: 詳細は、『Oracle Database Real Application Security管理者および開発者ガイド』を参照してください。

XS_SESSION_ADMIN

Oracle Database Real Application Securityでは、権限受領者がセッションを作成、接続、切離しおよび破棄する機能を含むセッションのライフ・サイクルを管理できます。このロールをアプリケーション接続ユーザーまたはReal Application Securityディスパッチャに付与します。

関連項目: Real Application Securityセッションの管理の詳細は、『Oracle Database Real Application Security管理者および開発者ガイド』を参照してください。



注意:

各インストールで独自のロールが作成されて、必要な権限のみが割り当てられます。このようにして、使用中の権限の詳細な制御が維持されます。このプロセスにより、Oracle Databaseで定義されるロールがOracle Databaseで変更や削除されたとき、既存のロール、権限、またはプロシージャを調整する必要もなくなります。たとえば、CONNECTロールが現在持っている権限はCREATE SESSIONの1つのみです。

ロールの作成

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


関連項目:


ロールの作成について

ロールはCREATE ROLE文を使用して作成できますが、そのためにはCREATE ROLEシステム権限が必要です。通常、このシステム権限はセキュリティ管理者のみが持っています。

作成した直後のロールには、権限は対応付けられていません。次のステップで、新しいロールに権限または他のロールを付与します。

作成する各ロールには、データベースの既存のユーザー名やロール名とは異なる、一意の名前を指定する必要があります。ロールはどのユーザーのスキーマ内にも格納されません。マルチバイト・キャラクタ・セットを使用するデータベースでは、各ロール名に少なくとも1つのシングルバイト・キャラクタを含めることをお薦めします。ロール名がマルチバイト・キャラクタのみの場合、暗号化されたロール名とパスワードの組合せの安全性は大幅に低くなります。パスワードのガイドラインは、「パスワードの保護に関するガイドライン」のガイドライン1を参照してください。

IDENTIFIED BY句を使用して、パスワードによってロールを認可します。この句は、このロールを付与された特定ユーザーがロールを使用をする前に、どの認可方式で認可される必要があるかを指定します。この句を指定しないか、またはNOT IDENTIFIEDを指定すると、認可がなくてもロールが使用可能になります。ロールには、必要な認可方式として次の方式を指定できます。

  • パスワードを使用したデータベースによる認可

  • 指定のパッケージを使用したアプリケーションによる認可

  • オペレーティング・システム、ネットワークまたはその他の外部ソースによる外部認可

  • エンタープライズ・ディレクトリ・サービスによるグローバル認可

パスワードで保護されたロールの作成の代替手段として、セキュア・アプリケーション・ロールの使用をお薦めします。詳細は、「セキュア・アプリケーション・ロールを使用したロール権限の保護」を参照してください。

ロールの作成に関する次の制限に注意してください。

  • ロールとユーザーに同じ名前を付けることはできません。

  • このロールが共通ロールでないかぎり、ロール名をc##(またはC##)から開始できません。

パスワードの有無に関係なく認可されるロールの作成

例4-12では、パスワードが認証されるclerkロールを作成します。ただし、パスワードで保護されたロールを使用するかわりに、セキュア・アプリケーション・ロールの使用を検討してください。詳細は、「セキュア・アプリケーション・ロールを使用したロール権限の保護」を参照してください。

例4-12 パスワードによって認可されるユーザー・ロールの作成

CREATE ROLE clerk IDENTIFIED BY password;

例4-13では、パスワードが認証されないsalesclerkロールを作成します。

例4-13 パスワード認証のないユーザー・ロールの作成

CREATE ROLE salesclerk;

注意:

SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータを11以上に設定する場合、IDENTIFIED BY句で作成されたロールを再作成する必要があります。詳細は、「安全性の高いロール・パスワードの大/小文字の区別の管理」を参照してください。

外部またはグローバルのロールの作成

外部ユーザーは、ロールを使用可能にする前に、オペレーティング・システムやサード・パーティ・サービスなどの外部サービスによって認可されている必要があります。グローバル・ユーザーは、ログイン時にロールの使用が可能になる前に、エンタープライズ・ディレクトリ・サービスによってロールの使用を認可されている必要があります。

例4-14は、clerkロールの変更方法を示しています。これによって、ロールを使用可能にするには、ユーザーが外部ソースによって認可されている必要があることが指定されます。

例4-14 グローバルに認可されるロールの作成

CREATE ROLE clerk IDENTIFIED GLOBALLY;

ロールの変更

ロールの認可方式を設定または変更するには、ALTER ROLE文を使用します。 セキュア・アプリケーション・ロールまたはパスワード認証ロールはユーザーに直接付与する必要があることに注意してください。ルートに共通ロールを作成する場合、共通ロールのみがルートで許可されるため、ローカル・ロールに変更できないので注意してください。

例4-15は、clerkロールの変更方法を示しています。これによって、ロールを使用可能にするには、ユーザーが外部ソースによって認可されている必要があることが指定されます。

例4-15 外部ソースによる認可が必要なロールへの変更

ALTER ROLE clerk IDENTIFIED EXTERNALLY;

ロールの認可方式を変更するには、ALTER ANY ROLEシステム権限またはADMINオプション付きのロールが付与されている必要があります。

ロール認可のタイプの指定

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


関連項目:

ロールの使用可能の詳細は、「権限の付与と取消しが有効になるとき」を参照してください。

データベースを使用したロールの認可

データベースによって認可されたロールを、ロール・パスワードを割り当てることで保護できます。パスワードで保護されたロールがユーザーに付与された場合、SET ROLE文でそのロールの正しいパスワードを入力することでロールを使用可または使用禁止にできます。パスワード認証ロールをデフォルト・ロールのリストに追加した場合でも、このパスワード認証ロールをログオン時に認証することはできません。SET ROLE文で必須パスワードを使用して、明示的に使用可能にする必要があります。

例4-16は、SET ROLE文を使用してパスワード認証ロールを設定する方法を示しています。

例4-16 SET ROLEを使用したパスワード認証ロールの設定

SET ROLE clerk IDENTIFIED BY password;

例4-12「パスワードによって認可されるユーザー・ロールの作成」は、clerkというロールを作成するCREATE ROLE文を示しています。このロールを使用可能にするには、パスワードを入力する必要があります。


注意:

マルチバイト・キャラクタ・セットを使用するデータベースの場合も、ロールのパスワードにはシングルバイト・キャラクタのみを使用してください。マルチバイト・キャラクタのパスワードは受け入れられません。パスワードのガイドラインは、「パスワードの保護に関するガイドライン」のガイドライン1を参照してください。

アプリケーションを使用したロールの認可

アプリケーション・ロール(セキュア・アプリケーション・ロール)を使用可能にできるのは、認可されたPL/SQLパッケージを使用するアプリケーションのみです。アプリケーション開発者は、アプリケーション内部にパスワードを埋め込むことによってロールを保護する必要はありません。かわりに、アプリケーション・ロールを作成して、ロールを使用可能にすることを認可するPL/SQLパッケージを指定できます。

認可されたPL/SQLパッケージによって使用可能になるロールを作成するには、CREATE ROLE SQL文でIDENTIFIED USING package_name句を使用します。

例4-17では、ロールadmin_roleがアプリケーション・ロールであり、このロールは、PL/SQLパッケージhr.admin内に定義されているモジュールによってのみ使用可能にできることを示しています。

例4-17 PL/SQLパッケージによって認可されるアプリケーション・ロールの作成

CREATE ROLE admin_role IDENTIFIED USING hr.admin;

セキュア・アプリケーション・ロールの詳細は、次の各項を参照してください。

外部ソースを使用したロールの認可

外部ロールは、データベースにローカルに定義できますが、グローバル・ユーザー、グローバル・ロールまたはデータベース内の他のロールには付与できません。オペレーティング・システムまたはネットワーク・クライアントによって認可されるロールを作成できます。

例4-18では、accts_recという名前のロールを作成しています。このロールを使用可能にするには、その前に、ユーザーが外部ソースによって認可されている必要があります。

例4-18 外部ソースによって認可されるロールの作成

CREATE ROLE accts_rec IDENTIFIED EXTERNALLY;

オペレーティング・システムを使用したロールの認可

オペレーティング・システムによるロール認証が有効となるのは、そのオペレーティング・システムによって、オペレーティング・システム権限をアプリケーションと動的にリンクできる場合のみです。ユーザーがアプリケーションを開始すると、オペレーティング・システムはオペレーティング・システム権限をそのユーザーに付与します。付与されたオペレーティング・システム権限は、アプリケーションに対応付けられたロールと一致します。この時点で、アプリケーションはアプリケーション・ロールを使用可能にできます。アプリケーションが終了すると、先に付与されたオペレーティング・システム権限は、そのユーザーのオペレーティング・システム・アカウントから取り消されます。

ロールをオペレーティング・システムによって認可する場合は、オペレーティング・システム・レベルで各ユーザーの情報を構成する必要があります。この操作は、オペレーティング・システムによって異なります。

ロールがオペレーティング・システムによって付与されている場合は、そのオペレーティング・システムによるロールの認可は不要です。


関連項目:

オペレーティング・システムによって付与されるロールの詳細は、「オペレーティング・システムまたはネットワークを使用したロールの付与」を参照してください。

ネットワーク・クライアントを使用したロールの認可

ユーザーがデータベースにOracle Net経由で接続する場合、オペレーティング・システムはデフォルトではユーザーのロールを認証できません。この接続ではOracle Netが必要となるため、共有サーバー構成を介した接続が含まれます。リモート・ユーザーはネットワーク接続を介して別のオペレーティング・システム・ユーザーになりすますおそれがあるため、デフォルトでこのような制限が適用されています。REMOTE_OS_ROLESFALSE(デフォルト)に設定することをお薦めします。

このようなセキュリティの危険性の心配がないときに、ネットワーク・クライアントに対してオペレーティング・システムのロール認証を使用する場合は、データベース初期化パラメータ・ファイル内の初期化パラメータREMOTE_OS_ROLESTRUEに設定します。この変更は、次回インスタンスを起動して、データベースをマウントするときに有効となります。

エンタープライズ・ディレクトリ・サービスによるグローバル・ロールの認可

ロールはグローバル・ロールとして定義できます。この場合、そのロールを使用するために(グローバル)ユーザーはエンタープライズ・ディレクトリ・サービスによる認可を受ける必要があります。グローバル・ロールは、権限とロールを付与することによってデータベース内でローカルに定義しますが、グローバル・ロール自体をそのデータベース内のユーザーや他のロールに付与することはできません。グローバル・ユーザーがデータベースへの接続を試みると、エンタープライズ・ディレクトリへの問合せが実行され、そのユーザーに対応付けられたグローバル・ロールが取得されます。

例4-19では、グローバル・ロールを作成しています。

例4-19 グローバル・ロールの作成

CREATE ROLE supervisor IDENTIFIED GLOBALLY;

グローバル・ロールは、エンタープライズ・ユーザー・セキュリティの構成要素の1つです。グローバル・ロールは1つのデータベースにのみ適用されますが、エンタープライズ・ディレクトリに定義されたエンタープライズ・ロールに付与できます。エンタープライズ・ロールは複数データベースのグローバル・ロールを含んだディレクトリ構造であり、エンタープライズ・ユーザーに付与できます。

ユーザーのグローバル認証とグローバル認可、およびエンタープライズ・ユーザー管理におけるロールの概要については、「グローバルなユーザー認証と認可の構成」を参照してください。


関連項目:

エンタープライズ・ユーザー管理の実装の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

ロールの付与と取消し

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

ロールの付与と取消しについて

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

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

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

GRANT文を使用してロールを付与し、REVOKE文を使用して取り消します。ロールに対して権限を付与または取り消す場合にも同じ文を使用します。

セキュアなロール(つまりIDENTIFIED BYロール、IDENTIFIED USINGロールまたはIDENTIFIED EXTERNALLYロール)は、他のセキュアなロールと非セキュアなロールのどちらにも付与することはできません。SET ROLE文を使用して、セッションに対してセキュアなロールを有効化できます。

ロールを付与したり、取り消すことができるユーザー

GRANT ANY ROLEシステム権限を持っているユーザーであれば、グローバル・ロールを除くあらゆるロールを、データベースの他のユーザーやロールに付与または取り消すことができます。(グローバル・ロールはOracle Internet Directoryなどのディレクトリ内で管理されますが、その権限は単一のデータベース内に含まれます。)デフォルトでは、SYSまたはSYSTEMユーザーがこの権限を持っています。このシステム権限は非常に強力であるため、付与する場合は控えめに設定する必要があります。

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


関連項目:

グローバル・ロールの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

プログラム・ユニットへのロールの付与と取消し

ロールを関数、プロシージャおよびPL/SQLパッケージ・プログラム・ユニットに付与できます。ロールは、プログラム・ユニットの実行中に有効になります(ただし、プログラム・ユニットのコンパイル中を除きます)。これにより、ロールを直接ユーザーに付与しないで、PL/SQLコードの権限を一時的にエスカレートできます。また、アプリケーションのセキュリティが強化され、最低限の権限の原則を規定できます。

例4-20は、プロシージャpsmith.check_stats_procへのロールclerk_adminの付与方法を示しています。

例4-20 プログラム・ユニットへのロールの付与

GRANT clerk_admin TO procedure psmith.checkstats_proc;

次の例は、PL/SQLパッケージcheckstats_pkgへの同じロールの付与方法を示しています。

GRANT clerk_admin TO package psmith.checkstats_pkg;

この例は、PL/SQLパッケージcheckstats_pkgclerk_adminロールの取消し方法を示しています。

REVOKE clerk_admin FROM package psmith.checkstats_pkg;

ロールの削除

ロールを削除すると、削除したロールが付与されていたすべてのユーザーとロールのセキュリティ・ドメインはただちに変更されて、削除したロール権限がなくなったことが反映されます。削除したロールによって間接的に付与されていたロールもすべて、関連するセキュリティ・ドメインから削除されます。ロールを削除することによって、すべてのユーザーのデフォルト・ロール・リストからそのロールが自動的に削除されます。

オブジェクトの存在はロールを介して受け取った権限に依存しないため、ロールが削除されても、表や他のオブジェクトは削除されません。

ロールは、SQL文DROP ROLEを使用して削除します。ロールを削除するには、DROP ANY ROLEシステム権限またはADMINオプション付きのロールが付与されている必要があります。

次の文は、ロールCLERKを削除します。

DROP ROLE clerk;

SQL*Plusユーザーによるデータベース・ロール使用の制限

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

セキュリティに関する潜在的な問題となる非定型ツールの使用

事前作成データベース・アプリケーションは、アプリケーション使用中にユーザー・ロールを使用可能および使用禁止にすることも含めて、ユーザーのアクションを明示的に制御します。一方、SQL*Plusなどの非定型の問合せツールを使用すると、ユーザーは付与されたロールを使用可能および使用禁止にする文も含めて、あらゆるSQL文を発行できます(正常終了する場合としない場合があります)。

アプリケーションのユーザーは、そのアプリケーションに付加された権限を使用し、非定型ツールによってデータベース表に破壊的なSQL文を発行する恐れがあります。

たとえば、次の使用例を考えてみます。

  • Vacation(休暇)アプリケーションには、それに対応するvacationロールがあります。

  • このvacationロールには、emp_tab表に対してSELECTINSERTUPDATEおよびDELETE文を発行する権限が含まれています。

  • Vacationアプリケーションは、vacationロールを介して取得した権限の使用を制御します。

ここで、vacationロールを付与されたユーザーを考えてみます。このユーザーが、Vacationアプリケーションを使用するかわりに、SQL*Plusを実行するとします。この時点でユーザーが制限を受けるのは、明示的に付与された権限またはロール(vacationロールを含む)を介して付与されている権限からのみです。SQL*Plusは非定型の問合せツールであるため、設計されたデータベース・アプリケーションを使用する場合のように、ユーザーは一連の事前定義アクションに制限されることはありません。ユーザーは、emp_tab表のデータの問合せや変更を自由に実行できます。

PRODUCT_USER_PROFILEシステム表がロールを制限できるしくみ

PRODUCT_USER_PROFILE表(これはSYSTEMスキーマです)を使用して、特定のSQLおよびSQL*Plusコマンドを各ユーザーのSQL*Plus環境で使用禁止にできます。Oracle DatabaseでなくSQL*Plusでこのセキュリティが実行されます。GRANTREVOKE、およびSET ROLEコマンドへのアクセスを制限して、ユーザーによる各自のデータベース権限の変更を制御することもできます。

PRODUCT_USER_PROFILE表を使用すると、ユーザーがアプリケーションでアクティブにできないロールをリストできます。また、様々なコマンド(SET ROLEなど)の使用を明示的に禁止できます。

たとえば、PRODUCT_USER_PROFILE表にエントリを作成して、次の処理を実行できます。

  • SQL*Plusで、clerkおよびmanagerロールの使用を禁止できます。

  • SQL*Plusで、SET ROLEの使用を禁止できます。

ユーザーMarlaが、SQL*Plusを使用してデータベースに接続するとします。Marlaには、clerkmanagerおよび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アドレスからデータベースに接続できることを検証できます。この方法により、セキュア・アプリケーション・ロールは、ユーザーがアプリケーション外のデータにアクセスすることを防ぎます。ユーザーは、付与されているアプリケーション権限のフレームワーク内で作業するように規定されます。

オブジェクト権限の管理

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

オブジェクト権限の概要

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

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

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

たとえば、次のことをする権利がオブジェクト権限です。

  • エディションの使用

  • 表の更新

  • 他のユーザーの表からの行の選択

  • 他のユーザーのストアド・プロシージャの実行


関連項目:

オブジェクト権限とそれぞれで許可されている操作のリストは、『Oracle Database SQL言語リファレンス』を参照してください。

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

ユーザーは、自分のスキーマに含まれているスキーマ・オブジェクトに関しては、すべてのオブジェクト権限が自動的に付与されています。GRANT ANY OBJECT PRIVILEGEシステム権限を持つユーザーは、GRANT文のWITH GRANT OPTION句を使用してもしなくても、指定したオブジェクト権限を別のユーザーに付与できます。また、GRANT ANY OBJECT PRIVILEGE権限を持つユーザーは、その権限を使用して、オブジェクト所有者またはGRANT ANY OBJECT PRIVILEGE権限を持つ他のユーザーによって付与されたオブジェクト権限を取り消すことができます。

権限受領者がGRANT ANY OBJECT PRIVILEGE権限を持っていない場合、またはGRANT文のWITH GRANT OPTION句を使用せずに権限を付与された場合、そのユーザーは権限を他のユーザーに付与できません。

WITH GRANT OPTIONは、ユーザーへのオブジェクト権限の付与でのみ使用できます。ロールへのオブジェクト権限の付与では使用できません。


関連項目:

GRANTおよびGRANT ANY OBJECT PRIVILEGEの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

オブジェクト権限の付与と取消し

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

オブジェクト権限の付与と取消しについて

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

オブジェクト権限を付与するにはGRANT文を使用し、オブジェクト権限を取り消すにはREVOKE文を使用します。

ALL句がすべての使用可能なオブジェクト権限を付与または取り消すしくみ

オブジェクトの各タイプには、異なるオブジェクト権限が対応付けられています。

ALL [PRIVILEGES]を指定して、オブジェクトに対するすべての使用可能なオブジェクト権限の付与または取消しが可能です。ALLは権限ではありません。ショートカットのようなもので、つまり1つのGRANT文およびREVOKE文ですべてのオブジェクト権限を付与または取り消すための方法です。すべてのオブジェクト権限がALLショートカットを使用して付与された場合でも、権限を個別に取り消すことができます。

同様に、個別に付与した権限をALLを指定してすべて取り消すこともできます。ただし、REVOKE ALLによって整合性制約が削除される場合(整合性制約は取り消そうとしているREFERENCES権限に依存しているため)は、REVOKE文にCASCADE CONSTRAINTSオプションを指定する必要があります。

例4-21では、CASCADE CONSTRAINTSを使用してHRスキーマ内の注文表に対するすべての権限を取り消しています。

例4-21 CASCADE CONSTRAINTSを使用したすべてのオブジェクト権限の取消し

REVOKE ALL 
 ON orders FROM hr
 CASCADE CONSTRAINTS;

シノニムを持つオブジェクト権限の使用

CREATE SYNONYM文を使用して、表、ビュー、順序、演算子、プロシージャ、ストアド・ファンクション、パッケージ、マテリアライズド・ビュー、Javaクラス・スキーマ・オブジェクト、ユーザー定義オブジェクト・タイプのシノニム、または他のシノニムを作成できます。ユーザーにシノニムを使用する権限を付与すると、基礎オブジェクトで付与されたオブジェクト権限は、ユーザーがベース・オブジェクトを名前で参照するかシノニムを使用して参照するかに関係なく適用されます。

たとえば、ユーザーOEが次のシノニムをCUSTOMERS表に作成するとします。

CREATE SYNONYM customer_syn FOR CUSTOMERS;

それから、OEcustomer_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            OE          INHERIT PRIVILEGES

結果にはこのユーザーが、他の権限に加えて、customer_synシノニムの基礎オブジェクト、つまりOE.CUSTOMER表に対するSELECT権限を持っていることが示されます。

この時点でユーザーOEcustomer_synシノニムに対するSELECT権限をHRから取り消した場合に、HRが自分の権限を再度調べたときの結果を次に示します。

TABLE_SCHEMA  TABLE_NAME  PRIVILEGE
------------  ----------  ------------------
OE            OE          INHERIT PRIVILEGES

ユーザー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操作に与える影響

表またはビューでDELETEINSERTSELECTおよびUPDATEの各DML操作を使用する権限を付与できます。これらの権限は、表のデータの問合せや操作が必要なユーザーとロールに対してのみ付与してください。

表に対するINSERT権限とUPDATE権限は、表の特定の列に制限できます。選択的なINSERT権限を付与されたユーザーは、選択した列に値を持つ行を挿入できます。他のすべての列には、NULLまたはその列のデフォルト値が挿入されます。選択的なUPDATE権限によって、ユーザーは行の特定の列に限ってその値を更新できます。機密データに対するユーザー・アクセスを制限するには、INSERT権限とUPDATE権限を選択的に使用します。

たとえば、データ入力ユーザーにemployees表のsalary列を変更させないようにするには、そのsalary列を除外した選択的なINSERT権限またはUPDATE権限を付与できます。また、salary列を除外したビューによって、同じ制限をさらに高いセキュリティ・レベルで実現できます。


関連項目:

DML操作の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

表に対する権限がDDL操作に与える影響

ALTERINDEXおよびREFERENCESの各権限は、表に対するDDL操作の実行を許可します。これらの権限によって、他のユーザーは表への依存性を変更または作成できるため、権限の付与は控えめに行う必要があります。

表に対してDDL操作を実行するユーザーには、さらに他のシステム権限やオブジェクト権限が必要な場合があります。たとえば、表にトリガーを作成するには、その表に対するALTER TABLEオブジェクト権限とCREATE TRIGGERシステム権限の両方が必要です。

INSERT権限やUPDATE権限と同様に、REFERENCES権限は、表の特定の列を対象として付与できます。REFERENCES権限を付与されたユーザーは、付与の対象となった表を、自分の表の中に作成する外部キーの親キーとして使用できます。外部キーの存在によって、親キーに対して実行できるデータ操作と表の変更が制限されるため、このアクションは特殊な権限によって制御されます。列固有のREFERENCES権限によって、権限受領者が使用できるのは、指定された列(この列には、当然、親表の主キーまたは一意キーが最低1つ含まれている)に制限されます。


関連項目:

主キー、一意キーおよび整合性制約の詳細は、『Oracle Database概要』のデータ整合性に関する項を参照してください。

ビューに対する権限の管理

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

ビューに対する権限の概要

ビューとは、1つ以上の表から選択されたデータを表現したもので、他のビューが含まれていることもあります。ビューには、基礎となる表の構造が表示されます。ビューに表示されたデータは、ストアド・クエリーの結果とみなすことができます。ビュー内に実際のデータはなく、表示する内容は基礎となる表とビューから導出されます。ビューを問い合せて、表示するデータを変更できます。ビュー内のデータは更新または削除でき、新規データも挿入できます。これらの操作は、ビューの基礎である表を直接変更するため、実表の整合性制約とトリガーに従います。

DMLオブジェクト権限は、表の場合と同様にビューに対しても適用できます。ビューに対するオブジェクト権限は、ビューの導出元の実表に実際に影響を与える様々なDML操作を許可します。

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

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

  • 次のどちらかのシステム権限が、明示的に、またはロールを介して付与されている必要があります。

    • CREATE VIEWシステム権限(自分のスキーマ内にビューを作成するため)

    • CREATE ANY VIEWシステム権限(別のユーザーのスキーマ内にビューを作成するため)

  • 次のいずれかの権限が明示的に付与されている必要があります。

    • ビューの基礎となるすべてのベース・オブジェクトに対するSELECTINSERTUPDATEまたはDELETEオブジェクト権限

    • SELECT ANY TABLEINSERT ANY TABLEUPDATE 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権限のみです。 この権限は、プロシージャの実行、または必要なプロシージャをコールする他のプロシージャのコンパイルが必要なユーザーにのみ付与してください。

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

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


関連項目:


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

自分のスキーマ内でプロシージャを作成または置換するには、CREATE PROCEDUREシステム権限が必要です。別のユーザーのスキーマ内でプロシージャを作成または置換するには、CREATE ANY PROCEDUREシステム権限が必要です。

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


注意:

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

プロシージャのコンパイルに必要なシステム権限

スタンドアロン・プロシージャをコンパイルするには、COMPILE句を使用してALTER PROCEDURE文を実行します。パッケージの一部であるプロシージャをコンパイルするには、ALTER PACKAGE文を実行します。

例4-22に、スタンドアロン・プロシージャをコンパイルする方法を示します。

例4-22 プロシージャのコンパイル

ALTER PROCEDURE psmith.remove_emp COMPILE;

スタンドアロン・プロシージャまたはパッケージ・プロシージャが別のユーザーのスキーマ内にある場合、プロシージャを再コンパイルするにはALTER ANY PROCEDURE権限が必要です。自分のスキーマ内にあるプロシージャは、権限なしで再コンパイルできます。

プロシージャに対する権限がパッケージおよびパッケージ・オブジェクトに与える影響

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

プロシージャに対する権限がパッケージおよびパッケージ・オブジェクトに与える影響について

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

プロシージャに対する権限およびパッケージとパッケージ・オブジェクト: 例1

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

例4-23 プロシージャに対する権限の影響を受けるパッケージ・オブジェクト

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つのパッケージ内に定義され、宣言されたグローバル変数やカーソルなどを共有できます。トップ・レベルのプロシージャであるhirefire、および追加のパッケージraise_bonusを宣言することによって、選択的なEXECUTE権限をメイン・パッケージ内のプロシージャに対して付与できます。

GRANT EXECUTE ON hire, fire TO big_bosses; 
GRANT EXECUTE ON raise_bonus TO little_bosses; 

型に対する権限の管理

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

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

表4-4に、名前付きの型(オブジェクト型、VARRAYおよびネストした表)に対するシステム権限のリストを示します。

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

権限 許可される操作

CREATE TYPE

名前付きの型を自分のスキーマ内に作成できます。

CREATE ANY TYPE

名前付きの型を任意のスキーマ内に作成できます。

ALTER ANY TYPE

任意のスキーマにある名前付きの型を変更できます。

DROP ANY TYPE

任意のスキーマにある名前付きの型を削除できます。

EXECUTE ANY TYPE

任意のスキーマにある名前付きの型を使用および参照できます。


RESOURCEロールには、CREATE TYPEシステム権限が含まれています。DBAロールには、これらの権限すべてが含まれています。

名前付きの型のオブジェクト権限

名前付きの型に適用されるオブジェクト権限は、EXECUTEのみです。名前付きの型に対するEXECUTE権限があるユーザーは、その型を使用して次の操作を実行できます。

  • 表の定義

  • リレーショナル表への列の定義

  • 名前付きの型の変数またはパラメータの宣言

EXECUTE権限によって、ユーザーは、型コンストラクタも含めて、その型のメソッドを起動できます。これは、ストアドPL/SQLプロシージャに対するEXECUTE権限と同じです。

名前付きの型のメソッド実行モデル

名前付きの型のメソッド実行は、他のストアドPL/SQLプロシージャと同じです。

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

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

  • 自分のスキーマにタイプを作成するには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ロールが現在保持している権限は、CREATE SESSIONのみです。

型アクセスとオブジェクト・アクセスの権限

DML文に対する列レベルと表レベルの既存の権限は、列オブジェクトと行オブジェクトの両方に適用されます。

表4-5に、オブジェクト表に対する権限をリストします。

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

権限 許可される操作

SELECT

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

UPDATE

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

INSERT

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

DELETE

行を削除できます。


同様に、列オブジェクトには表に対する権限と列に対する権限が適用されます。インスタンスの取得のみでは、型情報は明らかになりません。ただし、クライアントは、型インスタンスのイメージを解釈する際に名前付きの型の情報にアクセスする必要があります。クライアントが型情報を要求すると、その型に対する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文のREVOKEDROP TYPEは限定されたセマンティクスで実装されます。つまり、どちらの文でも、名前付きの型が表または型に依存している場合は、エラーが戻されて文は取り消されます。ただし、どちらの文も、FORCE句を使用すると常に正常終了します。依存する表がある場合、その表は無効になります。


関連項目:

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

ユーザー権限とロールの付与

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


関連項目:

中間層またはプロキシを介して接続されるユーザーへのロールの付与の詳細は、「中間層サーバーを使用したプロキシ認証」を参照してください。

ユーザーおよびロールへのシステム権限とロールの付与

システム権限とロールを他のユーザーやロールに付与するには、GRANT SQL文を使用します。次の権限が必要です。

  • システム権限を付与するには、ユーザーにADMINオプション付きのシステム権限またはGRANT ANY PRIVILEGEシステム権限が付与されている必要があります。

  • ロールを付与するには、ユーザーにADMINオプション付きのロールまたはGRANT ANY ROLEシステム権限が付与されている必要があります。

例4-24では、システム権限CREATE SESSIONaccts_payロールをユーザーjwardに付与しています。

例4-24 ユーザーへのシステム権限とロールの付与

GRANT CREATE SESSION, accts_pay TO jward;

例4-24 では、exec_dirディレクトリ・オブジェクトに対するEXECUTE権限をユーザーjwardに付与しています。

例4-25 ディレクトリ・オブジェクトに対するEXECUTE権限の付与

GRANT EXECUTE ON DIRECTORY exec_dir TO jward;

注意:

オブジェクト権限は、同じGRANT文でシステム権限やロールと同時に付与することはできません。

ADMINオプションの付与

ユーザーまたはロールに権限またはロールを付与するときにWITH ADMIN OPTION句を指定すると、権限受領者は、次の拡張機能を使用できるようになります。

  • 権限受領者は、データベース内の他のユーザーまたはロールに対して、システム権限またはロールの付与または取消しができます。ただし、自分自身からロールを取り消すことはできません。

  • 権限受領者は、ADMINオプション付きのシステム権限やロールを付与できます。

  • ロールの権限受領者は、そのロールを変更または削除できます。

例4-26では、new_dbaロールをWITH ADMIN OPTION句付きでユーザーmichaelに付与しています。

例4-26 ADMINオプションの付与

GRANT new_dba TO michael WITH ADMIN OPTION;

ユーザーmichaelは、new_dbaロール内の権限をすべて暗黙的に使用できることに加え、必要に応じてnew_dbaロールを付与、取消しおよび削除できます。このように、ADMINオプションは非常に強力な機能であるため、このオプションを付けてシステム権限やロールを付与する際は、十分に注意してください。通常、これらの権限はセキュリティ管理者向けに用意されており、システム内の他の管理者やユーザーに付与することはほとんどありません。


注意:

ユーザーがロールを作成すると、そのロールは自動的にADMINオプション付きでその作成ユーザーに付与されます。

GRANT文を使用した新規ユーザーの作成

Oracle Databaseでは、GRANT文を使用して新しいユーザーを作成できます。IDENTIFIED BY句を使用してパスワードを指定することで、ユーザー名がデータベースに存在しない場合も、指定したユーザー名とパスワードで新しいユーザーが作成されます。

例4-27では、新規ユーザーとしてpsmithを作成し、CREATE SESSIONシステム権限をpsmithに付与しています。

例4-27 GRANT文を使用した新規ユーザーの作成

GRANT CREATE SESSION TO psmith IDENTIFIED BY password;

ユーザーおよびロールへのオブジェクト権限の付与

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

ユーザーおよびロールへのオブジェクト権限の付与について

GRANT文を使用すると、ロールとユーザーにオブジェクト権限を付与できます。オブジェクト権限を付与するには、次のいずれかの条件を満たしている必要があります。

  • 指定するオブジェクトを所有している。

  • GRANT ANY OBJECT PRIVILEGEシステム権限を付与されている。この権限を使用すると、オブジェクト所有者のかわりに権限の付与と取消しを実行できます。

  • オブジェクト権限が付与されるときに、WITH GRANT OPTION句が指定されている。


    注意:

    同じGRANT文で、オブジェクト権限とともにシステム権限とロールを付与することはできません。

例4-28では、emp表のすべての列に対するSELECTINSERTおよびDELETEのオブジェクト権限をユーザーjfeetsmithに付与しています。

例4-28 ユーザーへのオブジェクト権限の付与

GRANT SELECT, INSERT, DELETE ON emp TO jfee, tsmith;

salaryビューのすべてのオブジェクト権限をユーザーjfeeに付与するには、次の例のようにALLキーワードを使用します。

GRANT ALL ON salary TO jfee;

注意:

権限受領者は、最初の権限付与にGRANT OPTIONが含まれていないかぎり、オブジェクトへのアクセス権を再度付与することはできません。したがって、前述の例では、jfeeGRANT文を使用してオブジェクト権限を他の誰かに付与することができません。

WITH GRANT OPTION句が機能するしくみ

GRANT文にWITH GRANT OPTION句を指定すると、権限受領者はオブジェクト権限を他のユーザーに付与できるようになります。スキーマ内にオブジェクトを格納しているユーザーには、関連するすべてのオブジェクト権限がWITH GRANT OPTION句付きで自動的に付与されます。この特別な権限によって、権限受領者の権限は次のように拡張されます。

  • 権限受領者は、データベース内の任意のユーザーにGRANT OPTIONの有無を問わずオブジェクト権限を付与でき、そしてデータベース内の任意のロールに付与できます。

  • 次の2つの条件が成立する場合、権限受領者は表に対するビューを作成し、そのビューの対応する権限をデータベース内の任意のユーザーまたはロールに対して付与できます。

    • 権限受領者が、表に対するGRANT OPTION付きのオブジェクト権限を受領している。

    • 権限受領者に、CREATE VIEWまたはCREATE ANY VIEWシステム権限がある。


注意:

オブジェクト権限をロールに付与する場合、WITH GRANT OPTION句は無効です。Oracle Databaseでは、ロールによるオブジェクト権限の伝播を禁止しているため、ロールの権限受領者は、ロールを介して受領したオブジェクト権限を他に伝播することはできません。

オブジェクト所有者にかわるオブジェクト権限の付与

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文によって生成された監査レコードには、常に権限付与を実際に実行したユーザーが示されます。

たとえば、次の使用例を考えてみます。ユーザーadamsGRANT 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権限を持っているためです。

列に対する権限の付与

表の個々の列に対してINSERTUPDATEまたは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;

行レベルのアクセス制御

行レベルで、つまりオブジェクト内でアクセスを制御することもできます。これには、仮想プライベート・データベース(VPD)またはOracle Label Security(OLS)を使用します。

ユーザー権限とロールの取消し

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

システム権限とロールの取消し

システム権限およびロールを取り消すには、SQL文REVOKEを使用します。 ADMINオプション付きでシステム権限またはロールを付与されているユーザーは、他のデータベース・ユーザーまたはロールから権限またはロールを取り消すことができます。取消しを行うユーザーは、権限やロールを最初に付与したユーザーでなくてもかまいません。GRANT ANY ROLEがあるユーザーは、任意のロールを取り消すことができます。

例4-29は、CREATE TABLEシステム権限とaccts_recロールをユーザーpsmithから取り消します。

例4-29 ユーザーからのシステム権限とロールの取消し

REVOKE CREATE TABLE, accts_rec FROM psmith;

注意:

システム権限またはロールのADMINオプションを選択的に取り消すことはできません。権限またはロールを取り消してから、同じ権限またはロールをADMINオプションを指定せずに再度付与する必要があります。

オブジェクト権限の取消し

オブジェクト権限を取り消すには、次のどちらかの条件を満たしている必要があります。

  • 以前にユーザーまたはロールにオブジェクト権限を付与している。

  • オブジェクト所有者のかわりに権限を付与したり取り消すことができるGRANT ANY OBJECT PRIVILEGEシステム権限を所持している。

取り消すことができるのは、権限付与者として自身で直接認可した権限のみです。GRANT OPTIONを付与した他のユーザーによる権限付与を取り消すことはできません。ただし、連鎖的な影響があります。権限付与者のオブジェクト権限を取り消すと、GRANT OPTIONを使用して伝播されたオブジェクト権限も取り消されます。

最初の権限付与者が次の文を発行すると、ユーザーjfeepsmithから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文を発行したユーザーによって付与されたオブジェクト権限のみが取り消されます。この使用例については、「オブジェクト所有者にかわるオブジェクト権限の付与」の例を使用して説明します。

ここでは、blakeHR.EMPLOYEESに対するSELECT権限をclarkに付与しているとします。blakeGRANT ANY OBJECT PRIVILEGEシステム権限を所有していますが、特定のオブジェクト権限も保有しているため、この付与はblakeに起因します。ここでは、ユーザーHRHR.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のかわりに)adamsGRANT ANY OBEJCT PRIVILEGEシステム権限を使用して付与したオブジェクト権限が削除されます。

列を選択するオブジェクト権限の取消し

表やビューの列を指定してINSERTUPDATEおよび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権限の付与がやりなおし、リストアまたは再発行されます。

REFERENCESオブジェクト権限の取消し

REFERENCESオブジェクト権限の権限受領者がその権限を使用して外部キー制約を作成し、その制約が現在も存在している場合、権限付与者がその権限を取り消すには、REVOKE文に必ずCASCADE CONSTRAINTSオプションを指定する必要があります。

REVOKE REFERENCES ON dept FROM jward CASCADE CONSTRAINTS;

CASCADE CONSTRAINTS句を指定すると、取り消されるREFERENCES権限を使用して現在も定義されている外部キー制約が削除されます。

権限の取消しによる連鎖的な影響

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

システム権限の取消しによる連鎖的な影響

DDL操作に関連するシステム権限を取り消すときには、この権限がADMINオプション付きで付与されたか無しで付与されたかに関係なく、連鎖的な影響はありません。たとえば、次のような場合を考えてみます。

  1. セキュリティ管理者が、ADMIN optionを指定して、ユーザーjfeeCREATE TABLEシステム権限を付与します。

  2. ユーザーjfeeが表を作成します。

  3. ユーザーjfeeが、ユーザーtsmithCREATE TABLEシステム権限を付与します。

  4. ユーザーtsmithが表を作成します。

  5. セキュリティ管理者が、ユーザーjfeeからCREATE TABLEシステム権限を取り消します。

  6. ユーザーjfeeが作成した表はそのまま残ります。ユーザーtsmithの表とCREATE TABLEシステム権限はそのまま残ります。

連鎖的な影響は、DML操作に関連するシステム権限を取り消したときに発生する場合があります。ユーザーのSELECT ANY TABLE権限を取り消すと、そのユーザーのスキーマ内に存在し、この権限に依存しているすべてのプロシージャは、権限が再度認可されないかぎり、正常に実行できなくなります。

オブジェクト権限の取消しによる連鎖的な影響

オブジェクト権限を取り消すと、連鎖的な影響が発生する場合があります。次のことに注意してください。

  • DMLオブジェクト権限を取り消すと、そのDMLオブジェクト権限に依存するオブジェクト定義にまで影響が及ぶ可能性があります。たとえば、testプロシージャの本体に、emp表のデータを問い合せるSQL文が記述されているとします。testプロシージャの所有者からemp表のSELECT権限を取り消すと、それ以降そのプロシージャを正常に実行できなくなります。

  • 表に対するREFERENCES権限をユーザーから取り消すと、そのユーザーが定義した外部キー整合性制約の中で、取り消されたREFERENCES権限を必要とする制約が自動的に削除されます。たとえば、ユーザーjwarddept表の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にも連鎖します。user1user2の取り消されたSELECT権限に依存するオブジェクトもすべて、前述のように影響を受ける可能性があります。

ALTERまたはINDEXオブジェクト権限を取り消しても、ALTERおよびINDEX DDLの各オブジェクト権限を必要とするオブジェクト定義には影響を与えません。たとえば、別のユーザーに属する表に索引を作成したユーザーからINDEX権限を取り消しても、その索引はそのまま残ります。

PUBLICロールに対する権限の付与と取消し

ロールPUBLICに対して、権限とロールの付与および取消しを実行できます。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_ROLESTRUEに設定します(インスタンスが実行中の場合は再起動します)。ユーザーがデータベースとのセッションを作成しようとすると、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インスタンスに接続すると、role3role4がデフォルト・ロールになり、role2role4ADMINオプション付きで付与されます。

オペレーティング・システムのロール管理機能

オペレーティング・システムによって管理されているロールを使用する場合は、データベース・ロールがオペレーティング・システムのユーザーに付与されることに注意してください。オペレーティング・システム・ユーザーが接続できるデータベース・ユーザーは、認可されたデータベース・ロールを使用できます。このため、OS_ROLES = TRUEを使用している場合は、権限が付与されているオペレーティング・システム・アカウントにデータベース・アカウントを対応付けるために、すべてのOracle DatabaseユーザーをIDENTIFIED EXTERNALLYとして定義することを考慮してください。

OS_ROLESがTRUEに設定されている場合のロールの付与と取消し

OS_ROLESパラメータがTRUEに設定されている場合は、ユーザーに対するロールの付与と取消しがオペレーティング・システムによって完全に管理されます。それまでにGRANT文によってユーザーに付与されたロールは適用されません。ただし、それらのロールはデータ・ディクショナリには残っています。オペレーティング・システム・レベルでのユーザーへのロールの付与のみが適用されます。この場合も、ユーザーは権限をロールとユーザーに付与できます。


注意:

オペレーティング・システムによってADMINオプション付きでロールが付与された場合、ユーザーはそのロールを他のロールにのみ付与できます。

OS_ROLESがTRUEに設定されている場合のロールの有効化と無効化

OS_ROLES初期化パラメータがTRUEに設定されている場合、オペレーティング・システムによって付与されたロールは、SET ROLE文を使用して動的に使用可能にできます。ロールがパスワードやオペレーティング・システムによる認可を必要とするように定義されていた場合でも、この文は適用されます。ただし、ユーザーのオペレーティング・システム・アカウントで識別されないロールは、SET ROLE文では指定できません。これは、OS_ROLES = FALSEのときにGRANT文を使用してロールを付与していた場合でも同じです。(このようなロールを指定しても無視されます)。

OS_ROLESTRUEに設定されている場合、ユーザーは最大148個のロールを使用可能にできます。この数には、ロールに付与されている可能性のある他のロールも含まれることに注意してください。

オペレーティング・システムによるロール管理使用時のネットワーク接続

オペレーティング・システムでロールを管理する場合、ユーザーは、デフォルトでは共有サーバーを介してデータベースに接続できません。リモート・ユーザーは保護されていない接続を介して別のオペレーティング・システム・ユーザーになりすますおそれがあるため、デフォルトでこのような制限が適用されています。

このようなセキュリティに対する危険性の心配がない場合は、初期化パラメータREMOTE_OS_ROLESTRUEに設定することで、共有サーバーまたはその他のネットワーク接続でオペレーティング・システムのロール管理を使用できます。この変更は、次回インスタンスを起動して、データベースをマウントするときに有効になります。このパラメータのデフォルト設定はFALSEです。

権限の付与と取消しが有効になるとき

付与と取消しがいつ有効になるかは、付与または取り消す対象によって異なります。

  • 任意の対象(ユーザー、ロールおよびPUBLIC)に対するシステム権限とオブジェクト権限の付与および取消しは、即時に有効になります。

  • 任意の対象(ユーザー、他のロール、PUBLIC)に対するロールの付与および取消しが有効になるのは、その付与および取消しの実行後、ロールを再度使用可能にするために現行のユーザー・セッションでSET ROLE文を発行したとき、あるいはその付与または取消しを実行した後に新しくユーザー・セッションを作成したときです。

現在使用可能なロールは、SESSION_ROLESデータ・ディクショナリ・ビューを問い合せることによって確認できます。

SET ROLE文が付与と取消しに与える影響

ユーザーまたはアプリケーションは、ユーザー・セッション中にSET ROLE文を何度でも使用して、現在そのセッションで使用可能になっているロールを変更できます。ユーザーには、SET ROLE文で指定したロールが、事前に付与されている必要があります。

例4-30では、すでに付与されているロールclerkを使用可能にして、パスワードを指定しています。

例4-30 SET ROLEを使用したロールの付与とパスワードの指定

SET ROLE clerk IDENTIFIED BY password;

passwordを安全なパスワードに置き換えます。パスワードの最低要件については、「パスワードの最低要件」を参照してください。

例4-31は、SET ROLEを使用してすべてのロールを使用禁止にする方法を示しています。

例4-31 SET ROLEを使用した全ロールの無効化

SET ROLE NONE;

デフォルト・ロールの指定

ユーザーがログインすると、そのユーザーに明示的に付与されている権限と、そのユーザーのデフォルト・ロールに含まれる権限が、すべて使用可能になります。

ユーザーのデフォルト・ロールのリストは、ALTER USER SQL文を使用して設定および変更できます。ALTER USER文では、ユーザーがデータベースに接続するときに使用可能になるロールを指定します。この場合、ユーザーにこれらのロールがGRANT文で直接付与されているか、これらのロールがCREATE ROLE権限を持つユーザーによって作成されている必要があります。ALTER USER文のDEFAULT ROLE句の制限事項は、『Oracle Database SQL言語リファレンス』を参照してください。

例4-32では、ユーザーjaneに対してデフォルト・ロールのpayclerkpettycashを設定しています。

例4-32 ALTER USERを使用したデフォルト・ロールの設定

ALTER USER jane DEFAULT ROLE payclerk, pettycash;

CREATE USER文ではユーザーのデフォルト・ロールを設定できません。ユーザーを最初に作成すると、デフォルトのユーザー・ロール設定はALLであり、ユーザーにその後に付与されるすべてのロールがデフォルト・ロールになります。デフォルトのユーザー・ロールを制限するには、ALTER USER文を使用します。


注意:

(グローバル・ロールやアプリケーション・ロール以外の)ロールを作成すると、このロールが自分に暗黙的に付与され、自分のデフォルト・ロールのセットが新しいロールを含むように更新されます。ロールはいくつでもユーザーに付与できますが、ユーザーがデフォルトで使用可能にできるロール数は148個までであることに注意してください。この数を超えると、ユーザーはデータベースにログインできなくなり、 ORA-28031「有効なロールの最大数148を超えました」エラーが発生します。DBAロールのような集計ロールがユーザーに付与されると、そのロールに付与されるロールはユーザーが持っているロール数に含まれます。たとえば、あるロールには20個のロールが付与されており、そのロールをユーザーに付与すると、そのユーザーは21個の追加ロールを持っていることになります。したがって、新しいロールをユーザーに付与するときは、ALTER USER文のDEFAULT ROLE句を使用してそのユーザーのデフォルト・ロールとして指定されるロールが多すぎないよう確認してください。

ユーザーが使用可能にできるロールの最大数

ユーザーが使用可能にできるロール数は148個までです。ユーザーには必要な数だけロールを付与できますが、ユーザーに付与するロール数は、ユーザーが必要な最小限のロール数に制限する必要があります。ユーザーへのロール付与に関する追加ガイドラインは、「ロールの保護に関するガイドライン」を参照してください。

ユーザー権限およびロールのデータ・ディクショナリ・ビュー

表4-6に、権限とロールの付与に関する情報を入手するために問合せ可能なデータ・ディクショナリ・ビューをリストします。


関連項目:

データ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

表4-6 権限およびロール情報を表示するデータ・ディクショナリ・ビュー

ビュー 説明

ALL_COL_PRIVS

オブジェクト所有者、権限付与者または権限受領者が現行ユーザーまたはPUBLICである列オブジェクトの権限付与がすべて表示されます。

ALL_COL_PRIVS_MADE

オブジェクト所有者または権限付与者が現行ユーザーである列オブジェクトの権限付与がリストされます

ALL_COL_PRIVS_RECD

権限受領者が現行ユーザーまたはPUBLICである列オブジェクトの権限付与が表示されます。

ALL_TAB_PRIVS

権限受領者がユーザーまたはPUBLICであるオブジェクトの権限付与がリストされます。

ALL_TAB_PRIVS_MADE

現行ユーザーが行ったオブジェクトの権限付与、または現行ユーザーが所有するオブジェクトに対する権限付与がすべてリストされます

ALL_TAB_PRIVS_RECD

権限受領者がユーザーまたはPUBLICであるオブジェクトの権限付与がリストされます。

DBA_COL_PRIVS

データベース内の列オブジェクトの権限付与がすべて表示されます。

DBA_CONTAINER_DATA

マルチテナント環境では、デフォルト(ユーザーレベル)およびオブジェクト固有のCONTAINER_DATA属性を表示します。CONTAINER_DATA句で作成されるオブジェクトには、CONTAINER_DATA属性が含まれます。

DBA_EPG_DAD_AUTHORIZATION

別のユーザー権限の使用が許可されたデータベース・アクセス記述子(DAD)が表示されます

DBA_TAB_PRIVS

データベース内のすべてのオブジェクトに対するすべての権限付与がリストされます。

DBA_ROLES

セキュア・アプリケーション・ロールを含めて、データベース内に存在するすべてのロールがリストされますPUBLICロールはリストされません

DBA_ROLE_PRIVS

ユーザーとロールに直接付与されているロールがリストされます。

DBA_SYS_PRIVS

ユーザーとロールに付与されているシステム権限がリストされます。

ROLE_ROLE_PRIVS

他のロールに付与されているロールがリストされます。ユーザーがアクセス権限を持っているロールの情報のみが得られます

ROLE_SYS_PRIVS

ロールに付与されているシステム権限がリストされます。ユーザーがアクセス権限を持っているロールの情報のみが得られます

ROLE_TAB_PRIVS

ロールに付与されているオブジェクト権限がリストされます。ユーザーがアクセス権限を持っているロールの情報のみが得られます

SESSION_PRIVS

ユーザーに対して現在使用可能になっている権限がリストされます。

SESSION_ROLES

現在のユーザーに対して使用可能になっているすべてのロールがリストされます。PUBLICロールはリストされません

USER_COL_PRIVS

オブジェクト所有者、権限付与者または権限受領者が現行ユーザーである列オブジェクトの権限付与が表示されます。

USER_COL_PRIVS_MADE

オブジェクト所有者が現行ユーザーである列オブジェクトの権限付与が表示されます。

USER_COL_PRIVS_RECD

権限受領者が現行ユーザーである列オブジェクトの権限付与が表示されます。

USER_EPG_DAD_AUTHORIZATION

別のユーザー権限の使用が許可されたデータベース・アクセス記述子(DAD)が表示されます

USER_ROLE_PRIVS

現行ユーザーに直接付与されているロールがリストされます。

USER_TAB_PRIVS

権限受領者が現行ユーザーであるすべてのオブジェクトの権限付与がリストされます。

USER_SYS_PRIVS

現行ユーザーに付与されているシステム権限がリストされます。

USER_TAB_PRIVS_MADE

現行ユーザーが所有しているすべてのオブジェクトの権限付与がリストされます。

USER_TAB_PRIVS_RECD

権限受領者が現行ユーザーであるオブジェクトの権限付与がリストされます。

V$PWFILE_USERS

管理権限を付与された現在のPDBのすべてのユーザーをリストします


ここでは、これらのビューの使用例をいくつか示します。各例では、次の文がすでに発行されていることを前提としています。

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 GRANTEE, PRIVILEGE, ADM 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_PRIVSROLE_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_PRIVSROLE_SYS_PRIVSおよびROLE_TAB_PRIVSの各ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。