権限とロールの認可を使用すると、ユーザーが毎日のタスクを実行するために保持する権限を制御します。
内容は次のとおりです。
関連項目:
権限の使用を分析するポリシーの作成方法の詳細は、『Oracle Database Vault管理者ガイド』を参照してください。
認可とは、データへのアクセス、処理または変更を特定のユーザーに許可するほか、ユーザーのアクセスやアクションに関する制限を作成するものです。
ユーザーに対して課せられる(または除外される)制限は、スキーマ、表全体または表の行などのオブジェクトに適用できます。
ユーザー権限とは、特定タイプのSQL文を実行する権利、別のユーザーのオブジェクトにアクセスする権利、PL/SQLパッケージを実行する権利などを指します。権限のタイプは、Oracle Databaseによって定義されています。
ロールは、ユーザー(通常は管理者)が権限や他のロールをグループ化するために作成します。ロールを使用すると、複数の権限またはロールをユーザーに簡単に付与できます。
権限は、次の一般的なカテゴリに分類されます。
システム権限。この権限の受領者は、データベースで標準的な管理作業を実行できます。権限受領者は信頼できるユーザーのみに制限してください。権限について説明している次の項を参照してください。
ロール。ロールでは、複数の権限やロールがグループ化されるため、複数のユーザーに対して権限を同時に付与したり、取り消すことができます。ユーザーによるロールの使用を可能にするには、そのユーザーに対してロールを使用可能にしておく必要があります。詳細は、次の各項を参照してください。
オブジェクト権限。オブジェクトの各タイプには、オブジェクト権限が対応付けられています。異なるタイプのオブジェクト権限を管理する方法は、オブジェクト権限の管理を参照してください。
表権限。これらの権限によって、DML (データ操作言語)またはDDL (データ定義言語)レベルでセキュリティが有効になります。表権限の管理方法の詳細は、表権限を参照してください。
表示権限。DMLオブジェクト権限は、表の場合と同様にビューに対しても適用できます。詳細は、ビューに対する権限を参照してください。
プロシージャ権限。スタンドアロン・プロシージャ、ファンクションを含め、プロシージャにはEXECUTE
権限を付与できます。詳細は、「プロシージャ権限」を参照してください。
タイプ権限。システム権限は名前付きタイプ(オブジェクト・タイプ、VARRAY
およびネストした表)に付与できます。詳細は、タイプ権限を参照してください。
関連項目:
権限の使用を分析するポリシーの作成方法の詳細は、『Oracle Database Vault管理者ガイド』を参照してください。権限をユーザーに付与すると、そのユーザーはそれぞれの業務に必要な作業を実行できます。
なお、権限は、必要な作業を実行する上でその権限が必要なユーザーにのみ付与してください。必要でない権限まで付与すると、セキュリティを維持できなくなる可能性があります。たとえば、管理作業を実行しないユーザーには、SYSDBA
管理権限またはSYSOPER
権限を付与しないでください。
権限は、次の2つの方法でユーザーに付与できます。
権限を明示的にユーザーに付与します。たとえば、employees
表にレコードを挿入する権限を、ユーザーpsmith
に明示的に付与できます。
権限をロール(名前付きの権限グループ)に付与した上で、そのロールを1人以上のユーザーに付与します。たとえば、employees
表からレコードを選択、挿入、更新および削除する権限を、clerk
という名前のロールに付与し、このロールをユーザーpsmith
やrobert
に付与できます。
ロールを使用することで権限の管理が容易になり、改善されるため、通常は権限を個々のユーザーではなくロールに付与してください。
関連項目:
権限を付与する際に従うベスト・プラクティスは、ユーザー・アカウントと権限の保護に関するガイドラインを参照してください
過度の権限付与が懸念される場合は、『Oracle Database Vault管理者ガイド』を参照してください。
システム権限の完全なリストとその詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
マルチテナント環境では、共通ユーザーを含むすべてのユーザーは、現在のコンテナ内でのみ権限を実行できます。
ただし、ルートに接続されているユーザーは、他のプラガブル・データベース(PDB)に影響を与える特定の操作を実行できます。これらの操作には、ALTER PLUGGABLE DATABASE
、CREATE USER
、CREATE ROLE
およびALTER USER
が含まれます。共通ユーザーは、これらの操作を可能にする、共通に付与される権限を所有している必要があります。ルートに接続されている共通ユーザーは、ビューにアクセスするために必要な権限を付与されていて、様々なPDBに関するデータを表示できるようにCONTAINER_DATA属性が設定されている場合、ルートのコンテナ・データ・オブジェクト(たとえば、マルチテナント・コンテナ・データベース(CDB)・ビューや
V$
ビューなど)を介してPDBに関するメタデータを確認できます。共通ユーザーは、PDBの表またはビューに問合せできません。
共通ユーザーは、他のPDBの権限を実行できません。必要なPDBに最初に切り替えて、そこから権限を実行する必要があります。異なるコンテナに切り替えるには、共通ユーザーにSET CONTAINER
権限が必要です。SET CONTAINER
権限は、共通に付与するか、ユーザーが切り替えようとしているコンテナ内で付与する必要があります。また、共通ユーザーは、そのPDBのCREATE SESSION
権限に応じて、現在の初期コンテナがこのユーザーが必要とするコンテナである新しいデータベース・セッションを開始できます。
共通に付与された権限が個々のPDBに構成されたセキュリティを妨げる場合があるので注意してください。たとえば、アプリケーションPDBのデータベース管理者がPDBのいずれのユーザーも特定のアプリケーション共通オブジェクトを変更できないようにするとします。PUBLIC
またはオブジェクトの共通ユーザーもしくは共通ロールに共通に付与された権限(UPDATE
など)は、PDBのデータベース管理者の意図に反した動作をします。
関連項目:
コンテナ・データ・オブジェクトの詳細は、共通ユーザーによるCONTAINER_DATAオブジェクトの情報の表示を参照してください
CDBの権限およびロール付与の概要は、『Oracle Database概要』を参照してください
一般的なデータベース操作と特定のデータベース操作の両方に管理権限を使用できます。
内容は次のとおりです。
Oracle Databaseではより適切な作業分担を実現するため、一般的に実施される各管理タスク用の管理権限が用意されています。
これらのタスクには、バックアップおよびリカバリ操作、Oracle Data GuardおよびTransparent Data Encryption (TDE)のための暗号化鍵の管理などが含まれます。
ユーザーが持つ管理権限は、V$PWFILE_USERS
動的ビューを問い合せるとわかります。このビューにはパスワード・ファイル内のユーザーがリストされます。
以前のリリースでは、これらのタスクを実行するSYSDBA
管理権限が必要でした。下位互換性をサポートするには、これらのタスクのSYSDBA
権限を引き続き使用できますが、この項で説明する管理権限を使用することをお薦めします。
管理権限の使用は強制的に監査されます。詳細は、管理ユーザーの監査を参照してください。
すべての強力な権限と同様に、管理権限は信頼できるユーザーのみに付与してください。
ただし、名前に非ASCII文字(HÜBER
という名前に含まれるウムラウトなど)を使用しているユーザーには制限があります。こうしたユーザーに管理権限を付与することは可能ですが、Oracle Databaseインスタンスが停止した場合、名前に非ASCII文字を使用しているユーザーには、付与されている権限を使用した認証がサポートされません。データベース・インスタンスが稼働中であれば、この認証はサポートされます。
SYSDBA
およびSYSOPER
管理権限を使用すると、各種標準データベース操作を実行できます。
これらのデータベース操作には、データベースの起動および停止、サーバー・パラメータ・ファイル(SPFILE
)の作成またはデータベース・アーカイブ・ログの変更などのタスクがあります。
関連項目:
SYSDBA
およびSYSOPER
管理権限の詳細は、『Oracle Database管理者ガイド』を参照してください。
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バックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
SYSDG
管理権限を持つSYSDG
ユーザーとしてログインして、Data Guard操作を実行できます。
Data Guard BrokerまたはDGMGRL
コマンドライン・インタフェースでこの権限を使用できます。パスワードを使用してSYSDG
としてデータベースに接続するには、そのパスワード・ファイルを作成する必要があります。
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 Database管理者ガイド』を参照してください
Oracle Data Guardの詳細は、Oracle Data Guard概要および管理を参照
SYSKM
管理権限により、SYSKM
ユーザーは、透過的データ暗号化(TDE)のウォレット操作を管理できます。
パスワードを使用してSYSKM
としてデータベースに接続するには、そのパスワード・ファイルを作成する必要があります。
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管理者ガイド』を参照してください
透過的データ暗号化の詳細は、『Oracle Database Advanced Securityガイド』を参照してください。
スキーマ・オブジェクトに対するアクションを実行するには、適切なシステム権限が付与されている必要があります。システム権限はかなり強力であるため、信頼できるユーザーのみに権限を制限することが重要です。
内容は次のとおりです。
関連項目:
システム権限とは、スキーマ・オブジェクトに対して1つまたは複数の操作を実行する権限です。
たとえば、表領域を作成する権限や、データベース内の任意の表から行を削除する権限などがシステム権限です。
システム権限には100以上の種類があります。各システム権限によって、ユーザーは特定のデータベース操作、またはあるクラスのデータベース操作を実行できます。システム権限は非常に強力な権限であることに注意してください。システム権限は、必要な場合のみ、データベースのロールと信頼できるユーザーに付与してください。ユーザーに付与されたシステム権限を検索するには、DBA_SYS_PRIVS
データ・ディクショナリ・ビューを問い合せます。
関連項目:
システム権限の完全なリストとその詳細は、『Oracle Database SQL言語リファレンス』を参照してください
システム権限はかなり強力であるため、信頼できるユーザーのみに権限を付与する必要があります。さらに、データ・ディクショナリを保護して、SYS
スキーマ内のオブジェクトを制限する必要があります。
内容は次のとおりです。
システム権限は非常に強力であるため、通常(非管理)ユーザーがANY
システム権限を実行しないように、デフォルトでデータベースが構成されます。
たとえば、ユーザーは、データ・ディクショナリに対してUPDATE ANY TABLE
などのANY
システム権限を実行できません。
システム権限の制限に関するその他のガイドラインは、ユーザー・アカウントと権限の保護に関するガイドラインを参照してください。
O7_DICTIONARY_ACCESSIBILITY
初期化パラメータは、Oracle Databaseリリース7からOracle8i以上のリリースにアップグレードした場合の、システム権限に対する制限を制御します。
このパラメータをTRUE
に設定すると、SYS
スキーマ内のオブジェクトへのアクセスが可能になります(Oracle Databaseリリース7の動作)。ANY
権限はデータ・ディクショナリに適用されるため、ANY
権限を持つ不正なユーザーがデータ・ディクショナリ表にアクセスし、変更する危険性があります。
データ・ディクショナリを保護するには、O7_DICTIONARY_ACCESSIBILITY
初期化パラメータをFALSE
(デフォルト)に設定します。この機能を、ディクショナリ保護メカニズムと呼びます。
O7_DICTIONARY_ACCESSIBILTY
初期化パラメータを設定する場合は、init
SID
.ora
ファイルで変更します。あるいは、サーバー・パラメータ・ファイル(SPFILE)を使用してデータベースを起動した場合は、SYSDBA
管理権限を持つユーザーSYS
としてSQL*PlusにログインしてからALTER SYSTEM
文を入力することもできます。
例4-1では、SQL*PlusのALTER SYSTEM
文を発行して、O7_DICTIONARY_ACCESSIBILTY
初期化パラメータをFALSE
に設定する方法を示しています。
例4-1 O7_DICTIONARY_ACCESSIBILITYのFALSEへの設定
ALTER SYSTEM SET O7_DICTIONARY_ACCESSIBILITY=FALSE SCOPE=SPFILE;
O7_DICTIONARY_ACCESSIBILITY
をFALSE
に設定すると、任意のスキーマ内のオブジェクトへのアクセスを可能にするシステム権限(たとえば、CREATE ANY PROCEDURE
のようなANY
権限を持つユーザー)ではSYS
スキーマ内のオブジェクトへのアクセスが許可されません。これは、SYS
スキーマ内のオブジェクト(データ・ディクショナリ・オブジェクト)へのアクセスがSYSDBA
管理権限を使用して接続するユーザーに制限されていることを意味します。SYS
ユーザーはSYSDBA
権限とSYSOPER
権限のどちらかでログインする必要があることに注意してください。それ以外の場合、 ORA-28009「SYSでの接続はSYSDBAまたはSYSOPERで行う必要があります」
エラーが発生します。O7_DICTIONARY_ACCESSIBILITY
をTRUE
に設定すると、データベースにユーザーSYS
としてログインできるようになり、SYSDBA
権限やSYSOPER
権限を指定する必要もありません。
他のスキーマのオブジェクトへのアクセスを提供するシステム権限で、他のユーザーがSYSスキーマ内のオブジェクトにアクセスすることはできません
。たとえば、SELECT ANY TABLE
権限を持つユーザーは、他のスキーマのビューや表にはアクセスできますが、ディクショナリ・オブジェクト(動的パフォーマンス・ビューの実表、通常のビュー、パッケージおよびシノニム)は選択できません。ただし、これらのユーザーは、明示的なオブジェクト権限を付与することで、SYS
スキーマ内のオブジェクトにアクセスできるようになります。
関連項目:
O7_DICTIONARY_ACCESSIBILITY
初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください明示的なオブジェクト権限のあるユーザーまたは管理権限で接続しているユーザー(SYSDBA
)は、SYS
スキーマ内のオブジェクトにアクセスできます。
表4-1に、SYS
スキーマ内のオブジェクトへのアクセスが必要なユーザーに対して付与できるロールをリストします。
表4-1 SYSスキーマ・オブジェクトにアクセスできるロール
ロール | 説明 |
---|---|
|
このロールを付与されたユーザーには、データ・ディクショナリ・ビューに対する |
|
このロールを付与されたユーザーには、データ・ディクショナリ内にあるパッケージとプロシージャに対する |
|
このロールを付与されたユーザーは、システム監査表 注意: Oracle Database 12c リリース1 (12.1)では、 |
さらにSELECT ANY DICTIONARY
システム権限を、SYS
スキーマで作成された表にアクセスが必要なユーザーに付与できます。このシステム権限により、SYS
スキーマのあらゆるオブジェクト(そのスキーマに作成された表を含む)への問合せアクセスが可能になります。このシステム権限は、これを必要とする各ユーザーへ個別に付与する必要があります。これはGRANT ALL PRIVILEGES
には含まれていませんが、ロールを通じて付与できます。
注意:
これらのロールおよびSELECT ANY DICTIONARY
システム権限は、悪用されるとシステムの整合性が損われる危険があるため、付与する際には十分な注意が必要です。
システム権限は、ユーザーとロールに対して付与したり、取り消すことができます。
システム権限をロールに付与すると、そのロールを使用してシステム権限を行使できます。たとえば、ロールを使用すると権限を選択的に使用できるようになります。ロールの保護に関するガイドラインで説明する業務分離のガイドラインに従っていることを確認してください。
ユーザーやロールに対するシステム権限の付与と取消しには、次のいずれかの方法を使用します。
SQL文のGRANT
およびREVOKE
Oracle Enterprise Manager Cloud Control
他のユーザーにシステム権限を付与したり、他のユーザーのシステム権限を取り消すことができるのは、次の2つのタイプのユーザーのみです。
これらのユーザーは次のとおりです。
ADMIN
OPTION
によって特定のシステム権限を付与されているユーザー
GRANT
ANY
PRIVILEGE
システム権限を付与されているユーザー
そのため、これらの権限は信頼できるユーザーにのみ付与してください。
ANY
キーワードを使用するシステム権限を使用すると、データベース内のオブジェクトのカテゴリ全体に対して権限を設定できます。
たとえば、CREATE ANY PROCEDURE
システム権限により、ユーザーはデータベース内のどこにでもプロシージャを作成可能になります。ANY
権限を持つユーザーが作成したオブジェクトの動作は、そのオブジェクトが作成されたスキーマに限定されません。たとえば、ユーザーJSMITH
にはCREATE ANY PROCEDURE
権限があり、プロシージャをスキーマJONES
に作成すると、そのプロシージャはJONES
として実行されることになります。ただし、JONES
はJSMITH
によって作成されたプロシージャがJONES
として機能していることに気付かない可能性があります。JONES
にDBA
権限が付与されている場合は、JSMITH
がJONES
としてプロシージャを実行することで、セキュリティ違反が発生する可能性があります。
PUBLIC
ロールは、データベース・ユーザー・アカウントが作成されるときすべてのアカウントに自動的に与えられる特別なロールです。デフォルトでは付与されている権限がありませんが、多数の付与があり、ほとんどがJavaオブジェクトに対する付与です。PUBLIC
ロールは削除できません。また、ユーザー・アカウントは常にこのロールを前提とするため、このロールの手動の付与や取消しは意味がありません。PUBLIC
ロールはすべてのデータベース・ユーザー・アカウントが前提とするため、DBA_ROLES
およびSESSION_ROLES
データ・ディクショナリ・ビューには表示されません。
PUBLIC
ロールに権限を付与できますが、付与した権限はOracleデータベースのすべてのユーザーが利用できるようになることに注意してください。このため、PUBLIC
ロールに権限を付与するとき、特にANY
権限やシステム権限のように強力な権限の場合は注意してください。たとえば、JSMITH
がCREATE PUBLIC SYNONYM
システム権限を持っている場合、他の誰もが使用するとわかっているインタフェースを再定義し、それから自分で作成したPUBLIC SYNONYM
でこのインタフェースを指し示すことができます。ユーザーは正しいインタフェースではなくJSMITH
のインタフェースにアクセスし、ユーザーのログイン資格証明が盗まれるなど、不正な行為が実行される可能性があります。
この種の権限は非常に強力であるため、不適切な個人に付与するとセキュリティ上のリスクが発生する可能性があります。ANY
またはPUBLIC
を使用した権限の付与には注意が必要です。他のすべての権限と同様に、これらの権限をユーザーに付与する場合は、「最低限の権限」を付与する原則に従ってください。
強力なANY
システム権限を1つ以上持つユーザーからデータ・ディクショナリ(SYS
スキーマの内容)を保護するには、O7_DICTIONARY_ACCESSIBILITY
初期化パラメータをFALSE
に設定します。ALTER SYSTEM
文を使用するか、init
SID
.ora
ファイルを変更して、このパラメータを設定できます。
関連項目:
その他のガイドラインは、データベースのインストールと構成の保護に関するガイドラインを参照してください
マルチテナント環境では、権限はCDB全体に対して共通に付与するか、特定のPDBに対してローカルに付与できます。
内容は次のとおりです。
関連項目:
共通権限付与およびローカル権限付与の概要は、『Oracle Database概要』を参照してください
マルチテナント環境では、共通ユーザーとローカル・ユーザーの両方は、相互に権限を付与できます。
権限自体は、共通でもローカルでもありません。権限がどのように適用されるかは、権限が共通に付与されるか、ローカルに付与されるかによって異なります。
共通に付与される権限の場合:
共通に付与される権限は、既存および将来のすべてのコンテナで使用できます。
権限を共通に付与できるのは共通ユーザーのみで、権限受領者が共通の場合のみです。
共通ユーザーは、他の共通ユーザーまたは共通ロールに権限を付与できます。
権限付与者は、ルートに接続して、GRANT
文のCONTAINER=ALL
を指定する必要があります。
システム権限とオブジェクト権限は、どちらも共通に付与できます。(オブジェクト権限は、指定したオブジェクトに関してのみ実現化します。)
共通ユーザーを指定されたコンテナに接続または切り替える場合、様々なアクティビティ(表の作成など)を実行するユーザーの機能は、共通に付与またはローカルに付与されたこのユーザーの両方の権限によって制御されます。
PUBLIC
には権限を共通に付与しないでください。
ローカルに付与される権限
ローカルに付与された権限は、それが付与されたコンテナでのみ使用できます。権限がルートで付与されている場合は、ルートにのみ適用されます。
共通ユーザーおよびローカル・ユーザーは、どちらも権限をローカルに付与できます。
共通ユーザーおよびローカル・ユーザーは、他の共通ロールまたはローカル・ロールに権限を付与できます。
権限付与者は、コンテナに接続して、GRANT
文のCONTAINER=CURRENT
を指定する必要があります。
ユーザーは、他のユーザーまたはロール(共通およびローカルの両方)あるいはPUBLIC
ロールにローカルに権限を付与できます。
関連項目:
CDBの権限およびロール付与の概要は、『Oracle Database概要』を参照してください。
ユーザーは、システム権限が付与されているPDB内でのみシステム権限を実行できます。
たとえば、PDB B
内の共通ユーザーA
にシステム権限がローカルに付与されている場合、ユーザーA
は、PDB B
に接続されている間のみ、その権限を実行できます。
システム権限は、ルートでのみ適用可能で、次の要件を満たしている場合は、既存および将来のすべてのPDBで適用できます。
システム権限付与者が共通ユーザーで、権限受領者が共通ユーザー、共通ロールまたはPUBLIC
ロールです。事実上すべてのユーザーがシステム権限を使用できるようになるため、システム権限をPUBLIC
ロールに共通に付与しないでください。
システム権限付与者は、共通に付与される権限に対してADMIN OPTION
を所有しています。
GRANT
文には、CONTAINER=ALL
句を含める必要があります。
次の例は、共通ユーザーc##hr_admin
に対して権限を共通に付与する方法を示しています。
CONNECT SYSTEM
Enter password: password
Connected.
GRANT CREATE ANY TABLE TO c##hr_admin CONTAINER=ALL;
共通オブジェクトのオブジェクト権限は、オブジェクト自体とそのオブジェクト上の関連するすべてのリンクに適用されます。
このリンクには、すべてのメタデータ・リンクおよびデータ・リンク(旧称オブジェクト・リンク)のほか、ルートやコンテナに属するすべてのPDB(将来のPDBを含む)内で特定の要件を満たしたときに関連付けが行われる拡張データ・リンクが含まれます。
この要件を次に示します。
オブジェクト権限付与者が共通ユーザーで、権限受領者が共通ユーザー、共通ロールまたはPUBLIC
ロールです。
オブジェクト権限付与者は、共通に付与される権限に対して共通に付与されるGRANT OPTION
を所有しています。
GRANT
文には、CONTAINER=ALL
句が含まれています。
次の例は、現在のPDBのuser_data
表から選択するための共通ユーザーc##hr_admin
へのオブジェクト権限の付与方法を示しています。
CONNECT SYSTEM@hr_pdg
Enter password: password
Connected.
GRANT READ ON user_data TO c##hr_admin CONTAINER=CURRENT;
関連項目:
メタデータ・リンクおよびオブジェクト・リンクの詳細は、『Oracle Database概要』を参照してください
マルチテナント環境のオブジェクト権限の範囲の詳細は、『Oracle Database概要』を参照してください。
マルチテナント環境では、PDBアクセスに対する権限の付与および取消を実行できます。
マルチテナント環境で権限を付与するには、GRANT
またはREVOKE
文にCONTAINER
句を含めます。
CONTAINER
をALL
に設定すると、既存および将来のすべてのコンテナに権限が適用され、CURRENT
に設定すると、ローカル・コンテナのみに権限が適用されます。CONTAINER
句を省略すると、ローカル・コンテナに権限が適用されます。ルートからGRANT
文を発行してCONTAINER
句を省略すると、権限がローカルに適用されます。
関連項目:
GRANT
文に関する詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
マルチテナント環境で権限を付与するには、GRANT文を使用できます。
例4-2は、既存および将来のすべてのコンテナでこの権限を使用できるように、共通ユーザーc##hr_admin
にCREATE TABLE
権限を共通に付与する方法を示しています。
例4-2 マルチテナント環境での権限の付与
CONNECT SYSTEM
Enter password: password
Connected.
GRANT CREATE TABLE TO c##hr_admin CONTAINER=ALL;
共通ユーザーは、ルート内のCONTAINER_DATA
オブジェクトや特定のPDB内のデータに関する情報を表示できます。
内容は次のとおりです。
共通ユーザーが問合せを実行する場合の、X$
表およびV$
、GV$
およびCDB_*
ビューの情報の表示を制限できます。
X$
表およびこれらのビューには、アプリケーション・ルートおよび関連付けられたアプリケーションPDBに関する情報(CDBルートに接続している場合は、CDB全体に関する情報)が含まれます。
他のPDBの機密情報を公開しない場合は、この情報を制限すると便利です。この機能を有効にするために、Oracle Databaseでは、これらの表およびビューをコンテナ・データ・オブジェクトとして提供します。特定の表またはビューがコンテナ・データ・オブジェクトかどうかを確認するには、USER_
|DBA_
|ALL_VIEWS
|TABLES
ディクショナリ・ビューのTABLE_NAME
、VIEW_NAME
およびCONTAINER_DATA
列を問い合せます。
デフォルト(ユーザー・レベル)およびオブジェクト固有のCONTAINER_DATA
属性の情報を確認するには、CDB_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リファレンスを参照
共通ユーザーのCONTAINER_DATA
属性を調整することで、共通ユーザーが特定のPDBに関するデータにアクセスできるようにすることができます。
共通ユーザーが特定のPDBに関するデータにアクセスできるようにするには、ルートでALTER USER
文を発行します。
次の例は、ALTER USER
文を発行して、共通ユーザーc##hr_admin
がV$SESSION
ビュー(このユーザーがこのビューを問い合せることができるものと仮定します)のCDB$ROOT
、SALES_PDB
およびHRPDB
コンテナに関する情報を表示できるようにする方法を示しています。
CONNECT SYSTEM
Enter password: password
Connected.
ALTER USER c##hr_admin
SET CONTAINER_DATA = (CDB$ROOT, SALESPDB, HRPDB)
FOR V$SESSION CONTAINER=CURRENT;
次のように値を指定します。
SET CONTAINER_DATA
は、コンテナのほか、ユーザーがアクセスできる対象に関するデータをリストします。
FOR V$SESSION
は、共通ユーザーc##hr_admin
が問い合せるCONTAINER_DATA
動的ビューを指定します。
ルートに接続する場合にCONTAINER=ALL
がALTER USER
文のデフォルトのため、CONTAINER = CURRENT
を指定する必要がありますが、CONTAINER_DATA
属性の変更はルートに制限する必要があります。
ユーザーc##hr_admin
が自身がアクセス可能なすべてのCONTAINER_DATA
オブジェクト内のCDB$ROOT
、SALES_PDB
、HRPDB
コンテナに関連する情報を表示できるようにするには、FOR V$SESSION
を省略します。次に例を示します。
ALTER USER c##hr_admin SET CONTAINER_DATA = (CDB$ROOT, SALESPDB, HRPDB) CONTAINER=CURRENT;
関連項目:
ALTER USER
文に関する詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
共通ロールはルートで作成されるロールであり、ローカル・ロールはPDBで作成されます。
内容は次のとおりです。
マルチテナント環境では、データベース・ロールをPDBに固有にするか、またはコンテナ全体で使用できます。
共通ロールとは、IDとパスワードがルートで作成され、既存および将来のすべてのコンテナで認識されるロールです。すべてのOracleから提供される事前定義ロールは共通ロールです。
ローカル・ロールは、1つのPDBにのみ存在し、このPDB内でのみ使用できます。共通に付与される権限は持ちません。
次のことに注意してください。
共通ユーザーは、共通ロールを作成して、他の共通ユーザーおよびローカル・ユーザーに付与できます。
共通ロールは、共通ユーザーに共通またはローカルに付与できます。
共通ロールをローカル・ユーザーに付与する場合、共通ロールの権限がローカル・ユーザーのPDBにのみ適用されます。
ローカル・ユーザーは共通ロールを作成できませんが、共通ユーザーおよび他のローカル・ユーザーに共通ロールを付与できます。
関連項目:
事前定義ロールのリストは、「Oracle Databaseのインストールで事前に定義されているロール」を参照してください。
共通ロールおよびローカル・ロールの概要は、『Oracle Database概要』を参照してください。
共通ロールは、マルチテナント環境のすべてのPDBで表示できます。
次の要件を満たす場合、共通ロールに共通に付与された権限は、ルートおよび権限付与者が接続できるすべてのPDB(後で追加される可能性があるPDBを含む)で適用されます。
権限付与者および権限受領者は、どちらも共通ユーザーです
権限付与者は、付与された共通ロールに対してADMIN OPTION
を所有しています。
GRANT
文には、CONTAINER=ALL
句が含まれています。
共通ロールがローカルに付与された権限を含む場合、これらの権限は、共通ロールに付与されたPDB内にのみ適用されます。ローカル・ロールは共通に付与できません。
たとえば、共通ユーザーc##hr_mgr
に、DBA
ロールが共通付与されているとします。これは、ユーザーc##hr_mgr
は、マルチテナント環境のルートおよび各PDBでDBA
ロールに関連付けられている権限を使用できることを意味します。一方、共通ユーザーc##hr_mgr
に、hr_pdb
PDBに対するDBA
ロールがローカルで付与されているのみであれば、このユーザーは、hr_pdb
PDBでのみDBA
ロールの権限を使用できます。
OracleによってPUBLIC
ロールに付与されるすべての権限は、ローカルで付与されます。
この機能により、各PDBで個別にPUBLIC
ロールに付与された権限およびロールを必要に応じて取り消すことができます。権限をPUBLIC
ロールに付与する必要がある場合は、ローカルに付与します。PUBLIC
には権限を共通に付与しないでください。
関連項目:
CDBのPUBLIC
ロールの概要は、『Oracle Database概要』を参照してください。
共通ロールを作成、変更または削除するために、共通ユーザーには共通権限が必要です。
共通に付与されるCREATE ROLE
、ALTER ROLE
およびDROP ROLE
権限を持つ共通ユーザーのみが、共通ロールの作成、変更または削除ができます。
共通ユーザーはローカル・ロールも作成できますが、作成されたPDBでのみそれらのロールを使用できます。
共通ロールを作成する場合は、特別な規則に従う必要があります。
この規則は次のとおりです。
ルートにいることを確認します。PDBから共通ロールを作成することはできません。ルートにいるかどうかを確認するには、show con_name
コマンドを実行します。CDB$ROOT
と表示される必要があります。
共通ロールに指定した名前は、C##またはc##で始まり、ASCIIまたはEDCDIC文字のみを含む必要があります。この要件はDBA
やRESOURCE
など、Oracle Databaseによって提供される既存のロールの名前に適用されないことに注意してください。
オプションで、CONTAINER句をALLに設定します。ルートにいるかぎりは、CONTAINER = ALL
句を省略しても、ロールは、デフォルトで共通ロールとして作成されます。
ローカル・ロールを作成するには、次の特別な規則に従う必要があります。
これらの規則は次のとおりです。
ロールを作成するPDBに接続する必要があり、CREATE ROLE
権限がある必要があります。
ローカル・ロールに付ける名前をCOMMON_USER_PREFIX
パラメータの値(デフォルトではC##
)で始めることはできません。
CREATE ROLE
文にCONTAINER=CURRENT
を含め、ローカル・ロールとしてロールを指定できます。PDBに接続しており、この句を省略すると、CONTAINER=CURRENT
句が含まれます。
共通ロールとローカル・ロールの名前を同じにすることはできません。ただし、異なるPDBのローカル・ロールに同じ名前を使用できます。既存のロールの名前を検索するには、CDB_ROLES
およびDBA_ROLES
データ・ディクショナリ・ビューを問い合せます。
ロールの付与と取消は、共通ユーザーまたはローカル・ユーザーのアクセス範囲にのみ適用されます。
共通ユーザーは、他の共通ユーザーへの共通ロールの付与および取消しを行うことができます。ローカル・ユーザーは、共通ロールを共通ユーザーを含むPDBのユーザーに付与できますが、これは、PDB内のみで適用されます。
次の例は、共通ユーザーc##sec_admin
へのすべてのコンテナで使用するAUDIT_ADMIN
共通ロールの付与方法を示しています。
CONNECT SYSTEM
Enter password: password
Connected.
GRANT AUDIT_ADMIN TO c##sec_admin CONTAINER=ALL;
同様に、次の例は、ローカル・ユーザーaud_admin
による共通ユーザーc##sec_admin
へのhrpdb
PDB内で使用するAUDIT_ADMIN
共通ロールの付与方法を示しています。
CONNECT aud_admin@hrpdb
Enter password: password
Connected.
GRANT AUDIT_ADMIN TO c##sec_admin CONTAINER=CURRENT;
この例は、ローカル・ユーザーaud_admin
がPDBからロールを取り消す方法を示しています。CONTAINER
句を省略すると、CURRENT
が暗黙のうちに入れられます。
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
に付与することはできません。
ロールがパスワード認証ロールまたはセキュア・アプリケーション・ロールでない場合は、ユーザーに間接的に付与できます。間接的に付与するロールとは、ユーザーにすでに付与されている別のロールを通じて同じユーザーに付与するロールのことです。たとえば、ユーザーpsmith
にrole1
ロールを付与するとします。その後、role2
ロールとrole3
ロールをrole1
ロールに付与します。これで、role2
とrole3
の2つのロールは、role1
に含まれることになります。つまり、psmith
には、直接付与されたrole1
に加え、role2
ロールとrole3
ロールが間接的に付与されたことになります。psmith
に対して、直接付与されたロールrole1
を使用可能にすると、間接的に付与されたロールrole2
およびrole3
も同様に使用可能になります。
必要に応じて、直接付与されたロールをデフォルト・ロールにできます。直接付与されたロールに対してデフォルト・ロール・ステータスを使用可能または使用禁止にするには、ALTER USER
文のDEFAULT ROLE
句を使用します。DEFAULT ROLE
句は、ユーザーに直接付与されたロールのみを示すようにしてください。ユーザーに直接付与されたロールを検索するには、DBA_ROLE_PRIVS
データ・ディクショナリ・ビューを問い合せます。このビューには、ユーザーに間接的に付与されたロールは含まれません。他のロールに付与されたロールを検索するには、ROLE_ROLE_PRIVS
ビューを問い合せます。
ロールがパスワード認証ロールまたはセキュア・アプリケーション・ロールの場合は、ユーザーに間接的に付与することも、デフォルト・ロールにすることもできません。このタイプのロールは、ユーザーに直接付与する必要があります。通常、パスワード認証ロールまたはセキュア・アプリケーション・ロールを使用可能にするには、SET ROLE
文を使用します。
権限管理に要する労力の削減など、ロールにはその管理を容易にする特別なプロパティがあります。
表4-2では、データベース内での権限管理をさらに容易にする、ロールの特性について説明します。
表4-2 ロールの特性とその説明
特性 | 説明 |
---|---|
権限管理に要する労力の削減 |
複数のユーザーに対して同一の権限セットを明示的に付与するかわりに、関連するユーザー・グループのための権限をまとめて1つのロールに付与しておき、そのグループの各メンバーにはそのロールを付与するだけですみます。 |
動的な権限管理 |
あるグループの権限を変更する必要がある場合、修正が必要なのは、そのロールの権限のみです。グループのロールを付与した全ユーザーのセキュリティ・ドメインには、そのロールに対して加えられる変更が自動的に反映されます。 |
権限の選択的な可用性 |
あるユーザーに付与したロールを、選択的に使用可能または使用禁止にできます。この機能によって、どのような状況でもユーザー権限を個々に制御できます。 |
アプリケーションによる認識 |
ロールの存在はデータ・ディクショナリに記録されます。したがって、ユーザーが特定のユーザー名でアプリケーションを実行したときに、アプリケーションがディクショナリに問い合せ、自動的に特定のロールを使用可能(または使用禁止)にするようにアプリケーションを設計できます。 |
アプリケーション固有のセキュリティ |
ロールの使用はパスワードを使用して保護できます。正しいパスワードを入力するとロールが使用可能になるようなアプリケーションを作成できます。パスワードを知らないユーザーは、ロールを使用可能にできません。 |
データベース管理者は、データベース・アプリケーションのロールを頻繁に作成します。セキュア・アプリケーション・ロールに対して、アプリケーションを実行するために必要なすべての権限を付与する必要があります。それから保護アプリケーション・ロールを他のロールやユーザーに付与できます。1つのアプリケーションは複数の異なるロールを持つことができ、各ロールには異なる権限のセットが付与され、アプリケーション使用中のデータ・アクセスの可否が決定されます。
DBAはパスワード付きのロールを作成することで、そのロールに付与されている権限が無許可で使用されるのを防止できます。通常、アプリケーションは起動時に適切なロールが使用可能になるように設計されます。そのため、アプリケーション・ユーザーは、アプリケーション・ロールのパスワードを知る必要がありません。
関連項目:
プロシージャに関する制限の詳細は、ロールによるDDL使用の支援または制限を参照してください
通常は、権限を管理するためにロールを作成します。
理由は次のとおりです。
データベース・アプリケーションに対する権限の管理(アプリケーション・ロールの一般的な使用方法を参照)
ユーザー・グループに対する権限の管理(ユーザー・ロールの一般的な使用方法を参照)
図4-1とその後の各項で、ロールの2通りの使用方法について説明します。
アプリケーション・ロールを使用して、アプリケーションを使用する権限を制御できます。
アプリケーション・ロールには、特定のデータベース・アプリケーションを実行するために必要な権限をすべて付与する必要があります。次に、そのセキュア・アプリケーション・ロールを、他のロールや特定のユーザーに対して付与します。
1つのアプリケーションに対して複数の異なるロールを設定し、アプリケーション使用時のデータ・アクセスの量や範囲にあわせて異なる権限セットを各ロールに割り当てることができます。
各ロールと各ユーザーには、それぞれ独自のセキュリティ・ドメインがあります。
ロールのセキュリティ・ドメインには、ロール自体に付与されている権限と、そのロールに付与されたロールに対して付与されている権限が含まれます。
ユーザーのセキュリティ・ドメインには、対応するスキーマ内のすべてのスキーマ・オブジェクトに対する権限、ユーザーに付与された権限、そして現在使用可能なユーザーに付与されたロールの権限が含まれます。(ロールをあるユーザーに対して使用可能にすると同時に、他のユーザーに対して使用禁止にできます。)このドメインには、ロールPUBLIC
に付与された権限とロールも含まれます。PUBLIC
ロールは、データベース内のすべてのユーザーを表します。
PL/SQLブロック内でのロールの使用方法は、そのブロックが無名ブロックであるか、名前付きブロック(ストアド・プロシージャ、ファンクションまたはトリガー)であるか、および定義者権限または実行者権限のどちらで実行されるかによって異なります。
内容は次のとおりです。
定義者権限で実行される名前付きPL/SQLブロックでは、すべてのロールは使用禁止になっています。
名前付きPL/SQLブロックには、ストアド・プロシージャやファンクション、トリガーがあります。
ロールは権限チェックに使用されず、定義者権限プロシージャ内ではロールを設定できません。
PL/SQLブロックが定義者権限で実行する場合、SESSION_ROLES
データ・ディクショナリ・ビューには現在使用可能なすべてのロールが表示されます。定義者権限で実行される名前付きPL/SQLブロックでSESSION_ROLES
を問い合せると、その問合せは行を戻しません。
関連項目:
SESSION_ROLES
データ・ディクショナリ・ビューの詳細は、Oracle Databaseリファレンスを参照してください
実行者権限を使用して実行する名前付きPL/SQLブロックと無名PL/SQLブロックは、使用可能なロールを通じて付与された権限に基づいて実行されます。
現行ロールは、実行者権限PL/SQLブロック内での権限チェックに使用されます。動的SQLを使用して、セッション内にロールを設定できます。
関連項目:
実行者権限と定義者権限を使用して名前解決と権限チェックを行う方法については、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
PL/SQLの動的SQLの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
ユーザーがDDL文を正常に実行するには、その文に応じて1つ以上の権限が必要になります。
たとえば、表を作成するには、CREATE
TABLE
またはCREATE
ANY
TABLE
システム権限が必要です。
別のユーザーに属する表のビューを作成するには、CREATE VIEW
またはCREATE
ANY
VIEW
システム権限のみでなく、その表に対するSELECT
object
権限またはSELECT
ANY
TABLE
システム権限も必要です。
Oracle Databaseでは、特定のDDL文での特定の権限の使用を制限することで、ロールを介して受け取った権限への依存性を回避します。次の規則は、DDL文に関する権限の制限を示しています。
DDL操作の実行をユーザーに許可するすべてのシステム権限およびオブジェクト権限は、ロールを介して受け取った場合でも使用可能。例:
システム権限: CREATE
TABLE
、CREATE
VIEW
およびCREATE
PROCEDURE
権限
オブジェクト権限: 表に対するALTER
およびINDEX
権限
表に対するREFERENCES
オブジェクト権限は、ロールを介して付与されている場合、表の外部キー定義には使用できません。
DDL文を発行するために必要なDML操作をユーザーが実行できるようにするすべてのシステム権限とオブジェクト権限は、ロールを通じて受け取った場合には使用できません。CREATE VIEW
文が使用されているとき、セキュリティ・ドメインにはロールが含まれません。たとえばユーザーはSELECT
ANY
TABLE
システム権限を付与されている場合、または表に対するSELECT
object
権限をロールを通じて付与されている場合、これらの権限のどちらを使用しても他のユーザーに属する表でビューは作成できません。これは、ビューが定義者権限のオブジェクトであり、ビューを作成するとき、自分にロールを通じて付与された権限はいずれも(システム権限もオブジェクト権限も)使用できないためです。権限が直接自分に付与されている場合は、この権限を使用できます。しかし権限が後で取り消されると、ビュー定義は無効になり(エラーとなり)、再度使用する前に再コンパイルする必要があります。
ロールを介して受け取った権限の使用許可と使用制限について、次の例で具体的に説明します。
次のようなユーザーを想定します。
CREATE
VIEW
システム権限を持つロールが付与されています。
employees
表に対するSELECT
object
権限を持つロールが直接付与されています。
departments
表に対するSELECT
object
権限が直接付与されています。
前述の権限がこのユーザーに直接的および間接的に付与されているとすると、
このユーザーはemployees
表とdepartments
表の両方に対してSELECT
文を発行できます。
このユーザーには、employees
表のCREATE
VIEW
権限とSELECT
権限がロールを介して付与されていますが、employees
表のSELECT
object
権限がロールを介して付与されていたため、employees
表のビューは作成できません。
このユーザーにはCREATE
VIEW
権限がロールを介して付与され、departments
表のSELECT
権限が直接付与されているため、departments
表のビューは作成できます。
環境によっては、オペレーティング・システムを使用してデータベース・セキュリティを管理できます。
オペレーティング・システムを使用して、データベース・ロールの付与と取消し、パスワードの認証を管理できます。この機能は、すべてのオペレーティング・システムで利用できるとはかぎりません。
関連項目:
オペレーティング・システムによるロールの管理方法の詳細は、そのオペレーティング・システム固有のOracle Databaseマニュアルを参照してください。
Oracle Databaseには、データベース管理を容易にする一連の事前定義ロールが用意されています。
表4-3に示すこれらの事前定義ロールは、データベース作成の一部である標準スクリプトの実行時に、Oracleデータベースに対して自動的に定義され、共通ロールとみなされます。他のオプションや製品をインストールすると、他の事前定義のロールが作成される場合があります。Oracleによって作成および維持されるロールは、DBA_ROLES
データ・ディクショナリ・ビューのROLE
列とORACLE_MAINTAINED
列を問い合せることでわかります。ORACLE_MAINTAINED
の出力がY
の場合は、そのロールを変更しないでください。ただし、そのロールの作成に使用したスクリプトを実行することで変更する場合を除きます。
表4-3 Oracle Databaseの事前定義ロール
事前定義のロール | 説明 |
---|---|
|
関連項目: |
|
アドバンスト・キューイングを管理するための権限を提供します。 |
|
サポートされていませんが、主にリリース8.0との互換性のために残されています。 |
|
統合およびファイングレイン監査ポリシーの作成、 関連項目: 監査の実行者 |
|
監査データを表示および分析する権限を提供します 関連項目: 監査の実行者 |
|
システムにログインしたユーザーを定義するために、XDBプロトコルで使用されます。 関連項目: このロールを |
|
権限分析ポリシーの作成および管理に必要な権限を提供します。 関連項目: 詳細は、『Oracle Database Vault管理者ガイド』を参照してください。 |
|
関連項目: CDBの管理の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
|
このロールは、Oracle Databaseの以前のリリースとの互換性を考慮して用意されています。このロールに組み込まれている権限は、 注意: このロールに依存せずに、データベース・セキュリティ用に独自のロールを設計することをお薦めします。このロールは、将来のリリースのOracle Databaseでは自動生成されない可能性があります。 関連項目: |
|
Oracle SpatialのCatalog Services for the Web(CSW)コンポーネントを管理するユーザー権限を提供します。 関連項目: 詳細は、Oracle Spatial and Graph開発者ガイドを参照してください。 |
|
Oracle Textの索引および索引プリファレンスの作成権限およびPL/SQLパッケージの使用権限を提供します。このロールはOracle Textユーザーに付与される必要があります。 関連項目: 詳細は、『Oracle Textアプリケーション開発者ガイド』を参照してください。 |
|
Oracleデータ・ウェアハウスおよび意思決定支援で使用されるリポジトリ標準であるCommon Warehouse Metadata(CWM)の管理権限を提供します。 関連項目: 詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。 |
|
Oracle Data Pumpを使用してOracleデータベースからデータをエクスポートする権限を提供します。 注意: このロールは非常に強力であり、データベース内の任意のスキーマの任意のデータへのユーザー・アクセスを提供します。このロールをユーザーに付与する場合は注意が必要です。 関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
|
Oracle Data Pumpを使用してOracleデータベースにデータをインポートする権限を提供します。 注意: このロールは非常に強力であり、データベース内の任意のスキーマの任意のデータへのユーザー・アクセスを提供します。このロールをユーザーに付与する場合は注意が必要です。 関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
|
このロールは、Oracle Databaseの以前のリリースとの互換性を考慮して用意されています。このロールに組み込まれている権限は、 注意: このロールに依存せずに、データベース・セキュリティ用に独自のロールを設計することをお薦めします。このロールは、将来のリリースのOracle Databaseでは自動生成されない可能性があります。 関連項目: |
|
DBFS(データベース・ファイルシステム)パッケージおよびオブジェクトへのアクセスを提供します。 関連項目: 『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』 |
|
統合監査環境以外で、システム監査表( 注意: Oracle Database 12c リリース1 (12.1)では、 |
|
Javaストアド・プロシージャからEJBに接続する権限を提供します。 |
|
ユーザーは、Oracle Enterprise Manager (EM) Expressに接続して、EM Expressによって提供されるすべての機能(すべてのEM Express機能への読取りおよび書込みアクセス)を使用できます。 関連項目: 詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。 |
|
ユーザーは、EM Expressに接続して、読取り専用モードでページを表示できます。 関連項目: 詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。 |
|
データ・ディクショナリ内のオブジェクトに対する |
|
エクスポート・ユーティリティ(後継はOracle Data Pump)を使用してデータベースの全インポートおよび増分エクスポートを実行するために必要な権限を提供します。含まれる権限は、 このロールは、エクスポート・ユーティリティおよびインポート・ユーティリティを簡単に使用できるように用意されています。 注意: このロールは非常に強力であり、データベース内の任意のスキーマの任意のデータへのユーザー・アクセスを提供します。このロールをユーザーに付与する場合は注意が必要です。 関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
|
関連項目: オプティマイザ統計の管理の詳細は、Oracle Database SQLチューニング・ガイドを参照してください。 |
|
Oracle Streams AQで使用されるLDAPサーバーへの接続を確立する権限を提供します。 関連項目: 詳細は、Oracle Database SQLチューニング・ガイドを参照してください。 |
|
異機種間サービス(HS)PL/SQLパッケージの使用を希望するユーザーに対して 関連項目: 詳細は、『Oracle Database Heterogeneous Connectivityユーザーズ・ガイド』を参照してください。 |
|
異機種間サービス(HS)PL/SQLパッケージの使用権限およびHS関連のデータ・ディクショナリ・ビューの問合せ権限を提供します。 関連項目: 詳細は、『Oracle Database Heterogeneous Connectivityユーザーズ・ガイド』を参照してください。 |
|
異機種間サービスのデータ・ディクショナリ・ビューの問合せ権限を提供します。 関連項目: 詳細は、『Oracle Database Heterogeneous Connectivityユーザーズ・ガイド』を参照してください。 |
|
インポート・ユーティリティ(後継はOracle Data Pump)を使用してデータベースの全インポートを実行するために必要な権限を提供します。システム権限の詳細リスト(権限を表示するにはビュー このロールは、エクスポート・ユーティリティおよびインポート・ユーティリティを簡単に使用できるように用意されています。 注意: このロールは非常に強力であり、データベース内の任意のスキーマの任意のデータへのユーザー・アクセスを提供します。このロールをユーザーに付与する場合は注意が必要です。 関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
|
Oracle Database Javaアプリケーション・デバッガの実行権限を提供します。 関連項目: Oracle Javaアプリケーションのセキュリティ管理の詳細は、『Oracle Database Java開発者ガイド』を参照してください。 |
|
このリリースでは非推奨となりました。 |
|
Oracle JVMで保護されたパッケージの更新を含む、Java 2を使用するための主要な権限を提供します。 関連項目: Oracle Javaアプリケーションのセキュリティ管理の詳細は、『Oracle Database Java開発者ガイド』を参照してください。 |
|
Java 2を使用するための制限された権限を提供します。 関連項目: Oracle Javaアプリケーションのセキュリティ管理の詳細は、『Oracle Database Java開発者ガイド』を参照してください。 |
|
Oracle Database Javaアプリケーションのポリシー表を更新する管理権限を提供します。 関連項目: Oracle Javaアプリケーションのセキュリティ管理の詳細は、『Oracle Database Java開発者ガイド』を参照してください。 |
|
関連項目: 詳細は、『Oracle Database開発ガイド』を参照してください |
|
データベース・セッションでJMXエージェントを起動およびメンテナンスする権限を提供します。 関連項目: Oracle Javaアプリケーションの管理の詳細は、『Oracle Database Java開発者ガイド』を参照してください。 |
|
関連項目: 詳細は、『Oracle Label Security管理者ガイド』を参照してください。 |
|
SQL Apply(ロジカル・スタンバイ・データベース)環境を管理する管理権限を提供します。 関連項目: 詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
|
関連項目: 詳細は、Oracle Database SQLチューニング・ガイドを参照してください。 |
|
Oracle Enterprise Managerの管理エージェント・コンポーネントで必要とされる、データベースを監視および管理する権限を提供します。 関連項目: 詳細は、Oracle Database SQLチューニング・ガイドを参照してください。 |
|
Oracle OLAPの異なるスキーマでディメンション・オブジェクトを作成する管理権限を提供します。 関連項目: 詳細は、『Oracle OLAPユーザーズ・ガイド』を参照してください。 |
|
アプリケーション開発者に対し、Oracle OLAPの独自のスキーマでディメンション・オブジェクトを作成する権限を提供します。 関連項目: 詳細は、『Oracle OLAPユーザーズ・ガイド』を参照してください。 |
|
Oracle OLAPのセキュリティの管理権限を提供します。 関連項目: 詳細は、『Oracle OLAPユーザーズ・ガイド』を参照してください。 |
|
関連項目: 詳細は、Oracle Database SQLチューニング・ガイドを参照してください。 |
|
Oracle Multimedia DICOMの管理権限を提供します。 関連項目: 『Oracle Multimedia DICOM開発者ガイド』 |
|
シードPDBから新しいPDBを作成する場合に作成されるローカル・ユーザーに自動的に付与されます。権限はこのロールに提供されません。 関連項目: シードを使用したPDBの作成の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
|
Oracle Database Real Applicationセッションのグローバル・コールバックを登録および更新してプリンシパルをプロビジョニングする権限を提供します。 関連項目: 詳細は、『Oracle Database Real Application Security管理者および開発者ガイド』を参照してください。 |
|
リカバリ・カタログの所有者の権限を提供します。 関連項目: 詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
|
このロールは、Oracle Databaseの以前のリリースとの互換性を考慮して用意されています。このロールに組み込まれている権限は、 注意: このロールに依存せずに、データベース・セキュリティ用に独自のロールを設計することをお薦めします。このロールは、将来のリリースのOracle Databaseでは自動生成されない可能性があります。 関連項目: |
|
権限受領者が 関連項目: |
|
データ・ディクショナリ内のオブジェクトに対する |
|
Oracle SpatialのCatalog Services for the Web(CSW)コンポーネントを管理する管理権限を提供します。 関連項目: 詳細は、Oracle Spatial and Graph開発者ガイドを参照してください。 |
|
Oracle SpatialのWeb Feature Service(WFS)コンポーネントを管理する管理権限を提供します。 関連項目: 詳細は、Oracle Spatial and Graph開発者ガイドを参照してください。 |
|
Oracle SpatialのWeb Feature Service(WFS)コンポーネントに対するユーザー権限を提供します。 関連項目: 詳細は、Oracle Spatial and Graph開発者ガイドを参照してください。 |
|
Oracle Workspace Managerの管理権限を提供します。これにより、ユーザーは 関連項目: 詳細は、『Oracle Database Workspace Manager開発者ガイド』を参照してください。 |
|
権限受領者がXMLスキーマを、その所有者のみが使用したりアクセスするために登録するのではなく、グローバルに登録できるようにします。また権限受領者がOracle XML DB Repositoryにアクセスしているときはアクセス制御リスト(ACL)チェックを回避できるようにもします。 関連項目: XMLスキーマとXML DBリポジトリの詳細は、『Oracle XML DB開発者ガイド』を参照してください。 |
|
権限受領者が実行者権限ハンドラを定義して、XMLリポジトリのトリガーのリソース構成を作成または更新できるようにします。デフォルトでは、このロールは 関連項目: Oracle DatabaseのXMLリポジトリのトリガーの詳細は、『Oracle XML DB開発者ガイド』を参照してください。 |
|
権限受領者がHTTPSを使用してOracle DatabaseのWebサービスにアクセスできるようにします。ただし、パブリックなデータベース内のオブジェクトに対するユーザー・アクセスは提供されません。パブリック・アクセスを許可するには、ユーザーに 関連項目: Oracle DatabaseのWebサービスの詳細は、『Oracle XML DB開発者ガイド』を参照してください。 |
|
権限受領者がHTTPを使用してOracle DatabaseのWebサービスにアクセスできるようにします。ただし、パブリックなデータベース内のオブジェクトに対するユーザー・アクセスは提供されません。パブリック・アクセスを許可するには、ユーザーに 関連項目: Oracle DatabaseのWebサービスの詳細は、『Oracle XML DB開発者ガイド』を参照してください。 |
|
権限受領者が、Oracle DatabaseのWebサービスを介してパブリック・オブジェクトにアクセスできるようにします。 関連項目: Oracle DatabaseのWebサービスの詳細は、『Oracle XML DB開発者ガイド』を参照してください。 |
|
Oracle Database Real Application Securityでは、権限受領者が中間層キャッシュを管理できます。 関連項目: 詳細は、『Oracle Database Real Application Security管理者および開発者ガイド』を参照してください。 |
|
Oracle Database Real Application Securityでは、権限受領者がセッションのネームスペースおよび属性を管理および操作できます。このロールをReal Application Securityセッション・ユーザーに付与します。 関連項目: Real Application Securityセッションの管理の詳細は、『Oracle Database Real Application Security管理者および開発者ガイド』を参照してください。 |
|
Oracle Database Real Application Securityでは、権限受領者が 関連項目: 詳細は、『Oracle Database Real Application Security管理者および開発者ガイド』を参照してください。 |
|
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##
)から開始できません。
IDENTIFIED BY
句を使用して、パスワードで認証されるロールを作成できます。
ただし、パスワードで保護されたロールを使用するかわりに、セキュア・アプリケーション・ロールの使用を検討してください。詳細は、ロール権限およびセキュア・アプリケーション・ロールを参照してください。
パスワード認証されるロールを作成するには、IDENTIFIED BY
句が指定されたCREATE ROLE
文を使用します。
例:
CREATE ROLE clerk IDENTIFIED BY password;
注意:
SQLNET.ALLOWED_LOGON_VERSION_SERVER
パラメータを11
以上に設定する場合、IDENTIFIED BY
句で作成されたロールを再作成する必要があります。詳細は、安全性の高いロール・パスワードの大/小文字の区別の管理を参照してください。
IDENTIFIED BY
句を省略することで、パスワードを必要としないロールを作成できます。
句を指定せずにCREATE ROLE
文を使用して、パスワード認証のないロールを作成します。
例:
CREATE ROLE salesclerk;
外部ユーザーは、ロールを使用可能にする前に、オペレーティング・システムやサード・パーティ・サービスなどの外部サービスによって認可されている必要があります。
グローバル・ユーザーは、ログイン時にロールの使用が可能になる前に、エンタープライズ・ディレクトリ・サービスによってロールの使用を認可されている必要があります。
グローバルに認可されるロールを作成するには、IDENTIFIED GLOBALLY
句を指定してCREATE ROLE
文を使用します。
例:
CREATE ROLE clerk IDENTIFIED GLOBALLY;
ALTER ROLE
文で、ロールの認可方法を変更できます。
ロールの認可方式を変更するには、ALTER ANY ROLE
システム権限またはADMIN
オプション付きのロールが付与されている必要があります。
セキュア・アプリケーション・ロールまたはパスワード認証ロールはユーザーに直接付与する必要があることに注意してください。ルートで共通ロールを作成する場合、それをローカル・ロールに変更できないことに注意してください。
ロールを変更するには、ALTER ROLE
文を使用します。
たとえば、ロールを有効にする前にユーザーが外部ソースによって認可されている必要があるように指定する目的でclerk
ロールを変更するとします。
ALTER ROLE clerk IDENTIFIED EXTERNALLY;
データベース、アプリケーション、外部ソース、オペレーティング・システム、ネットワーク・クライアントまたはエンタープライズ・ディレクトリ・サービスによって認可されるようにロールを構成できます。
内容は次のとおりです。
関連項目:
ロールを有効にする方法の詳細は、SET ROLEおよびデフォルト・ロールの設定による権限の付与と取消しの機能を参照してください
データベースによって認可されたロールを、ロール・パスワードを割り当てることで保護できます。
パスワードで保護されたロールがユーザーに付与された場合、SET ROLE
文でそのロールの正しいパスワードを入力することでロールを使用可または使用禁止にできます。パスワード認証ロールをデフォルト・ロールのリストに追加した場合でも、このパスワード認証ロールをログオン時に認証することはできません。SET ROLE
文で必須パスワードを使用して、明示的に使用可能にする必要があります。
アプリケーション・ロールを使用可能にできるのは、認可されたPL/SQLパッケージを使用するアプリケーションのみです。
アプリケーション開発者は、アプリケーション内部にパスワードを埋め込むことによってロールを保護する必要はありません。かわりに、アプリケーション・ロール(セキュア・アプリケーション・ロール)を作成して、ロールを使用可能にすることを認可するPL/SQLパッケージを指定できます。
認可されたPL/SQLパッケージによって使用可能になるロールを作成するには、CREATE ROLE
SQL文でIDENTIFIED USING
package_name
句を使用します。
たとえば、ロールadmin_role
がアプリケーション・ロールであり、このロールは、PL/SQLパッケージhr.admin
内に定義されているモジュールによってのみ使用可能にできることを示すとします。
CREATE ROLE admin_role IDENTIFIED USING hr.admin;
関連項目:
『Oracle Database 2日でセキュリティ・ガイド』
Oracle Databaseでは外部ロールの使用がサポートされますが、一定の制限があります。
外部ロールは、データベースにローカルに定義できますが、グローバル・ユーザー、グローバル・ロールまたはデータベース内の他のロールには付与できません。オペレーティング・システムまたはネットワーク・クライアントによって認可されるロールを作成できます。
外部ソースを使用してロールを認可するには、IDENTIFIED EXTERNALLY
句を指定してCREATE ROLE
文を使用します。
例:
CREATE ROLE accts_rec IDENTIFIED EXTERNALLY;
Oracle Databaseではオペレーティング・システムを通じたロール認証がサポートされますが、一定の制限があります。
オペレーティング・システムによるロール認証が有効となるのは、そのオペレーティング・システムによって、オペレーティング・システム権限をアプリケーションと動的にリンクできる場合のみです。
ユーザーがアプリケーションを開始すると、オペレーティング・システムはオペレーティング・システム権限をそのユーザーに付与します。付与されたオペレーティング・システム権限は、アプリケーションに対応付けられたロールと一致します。この時点で、アプリケーションはアプリケーション・ロールを使用可能にできます。アプリケーションが終了すると、先に付与されたオペレーティング・システム権限は、そのユーザーのオペレーティング・システム・アカウントから取り消されます。
ロールをオペレーティング・システムによって認可する場合は、オペレーティング・システム・レベルで各ユーザーの情報を構成します。この操作は、オペレーティング・システムによって異なります。
ロールがオペレーティング・システムによって付与されている場合は、そのオペレーティング・システムによるロールの認可は不要です。
関連項目:
オペレーティング・システムによって付与されるロールの詳細は、オペレーティング・システムまたはネットワークを使用したロールの付与を参照してください
Oracle Databaseではネットワーク・クライアントによるロール認証がサポートされますが、一定のセキュリティ・リスクが伴います。
ユーザーがデータベースにOracle Net経由で接続する場合、オペレーティング・システムはデフォルトではユーザーのロールを認証できません。この接続ではOracle Netが必要となるため、共有サーバー構成を介した接続が含まれます。リモート・ユーザーはネットワーク接続を介して別のオペレーティング・システム・ユーザーになりすますおそれがあるため、デフォルトでこのような制限が適用されています。REMOTE_OS_ROLES
をFALSE
(デフォルト)に設定することをお薦めします。
このようなセキュリティの危険性の心配がないときに、ネットワーク・クライアントに対してオペレーティング・システムのロール認証を使用する場合は、データベース初期化パラメータ・ファイル内の初期化パラメータREMOTE_OS_ROLES
をTRUE
に設定します。
この変更は、次回インスタンスを起動して、データベースをマウントするときに有効になります。
グローバル・ロールを使用すると、グローバル・ユーザーの認可の取得先をエンタープライズ・ディレクトリ・サービスに限定できます。
グローバル・ロールは、権限とロールを付与することによってデータベース内でローカルに定義しますが、グローバル・ロール自体をそのデータベース内のユーザーや他のロールに付与することはできません。グローバル・ユーザーがデータベースへの接続を試みると、エンタープライズ・ディレクトリへの問合せが実行され、そのユーザーに対応付けられたグローバル・ロールが取得されます。グローバル・ロールは、エンタープライズ・ユーザー・セキュリティの構成要素の1つです。グローバル・ロールは1つのデータベースにのみ適用されますが、エンタープライズ・ディレクトリに定義されたエンタープライズ・ロールに付与できます。エンタープライズ・ロールは複数データベースのグローバル・ロールを含んだディレクトリ構造であり、エンタープライズ・ユーザーに付与できます。
エンタープライズ・ディレクトリ・サービスによって認可されるグローバル・ロールを作成するには、IDENTIFIED GLOBALLY
句を指定してCREATE ROLE
文を使用します。
例:
CREATE ROLE supervisor IDENTIFIED GLOBALLY;
関連項目:
ユーザーのグローバル認証とグローバル認可、およびエンタープライズ・ユーザー管理におけるロールの概要については、ユーザーのグローバル認証とグローバル認可を参照してください
エンタープライズ・ユーザー管理の実装の詳細は、『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
には、GRANT ANY ROLE
権限があります。このシステム権限は非常に強力であるため、付与する場合は控えめに設定する必要があります。
ADMIN
OPTION
付きでロールを付与されたユーザーは、データベースの他のユーザーやロールに対してロールを付与したり、そのロールを取り消すことができます。つまり、このオプションによって、選択的なロール付与の管理が可能になります。
関連項目:
グローバル・ロールの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。
関数、プロシージャおよびPL/SQLパッケージ・プログラム・ユニットにロールを付与できます。
ロールは、プログラム・ユニットの実行中に有効になります。ただし、プログラム・ユニットのコンパイル中を除きます。これにより、ロールを直接ユーザーに付与しないで、PL/SQLコードの権限を一時的にエスカレートできます。また、アプリケーションのセキュリティが強化され、最低限の権限の原則を規定できます。
プログラム・ユニットに対してロールを付与または取り消すには、GRANT
またはREVOKE
文を使用します。
次の例は、PL/SQLパッケージcheckstats_pkg
への同じロールの付与方法を示しています。
GRANT clerk_admin TO package psmith.checkstats_pkg;
この例は、PL/SQLパッケージcheckstats_pkg
のclerk_admin
ロールの取消し方法を示しています。
REVOKE clerk_admin FROM package psmith.checkstats_pkg;
次の例は、プロシージャpsmith.check_stats_proc
へのロールclerk_admin
の付与方法を示しています。
GRANT clerk_admin TO PROCEDURE psmith.checkstats_proc;
関連項目:
詳細は、定義者権限および実行者権限のコード・ベース・アクセス制御の使用を参照してください
ロールの削除は、そのロールを付与されていたユーザーまたはロールのセキュリティ・ドメインに影響します。
つまり、削除したロールを付与されていたすべてのユーザーとロールのセキュリティ・ドメインは、削除したロール権限がなくなったことを反映するために変更されます。
削除したロールによって間接的に付与されていたロールもすべて、関連するセキュリティ・ドメインから削除されます。ロールを削除することによって、すべてのユーザーのデフォルト・ロール・リストからそのロールが自動的に削除されます。
オブジェクトの存在はロールを介して受け取った権限に依存しないため、ロールが削除されても、表や他のオブジェクトは削除されません。
ロールを削除するには、DROP ANY ROLE
システム権限またはADMIN
オプション付きのロールが付与されている必要があります。
ロールを削除するには、DROP ROLE
文を使用します。
たとえば、ロールCLERK
を削除する方法は次のとおりです。
DROP ROLE clerk;
SQL*Plusでロールを使用するユーザーに起因するセキュリティ問題の可能性、PRODUCT_USER_PROFILE
システム表を使用したロールの制限方法、ストアド・プロシージャによるビジネス・ロジックのカプセル化について注意してください。
内容は次のとおりです。
非定型ツールは、不正なユーザーがこのようなツールにアクセスできると問題が発生する可能性があります。
事前作成データベース・アプリケーションは、アプリケーション使用中にユーザー・ロールを使用可能および使用禁止にすることも含めて、ユーザーのアクションを明示的に制御します。一方、SQL*Plusなどの非定型の問合せツールを使用すると、ユーザーは付与されたロールを使用可能および使用禁止にする文も含めて、あらゆるSQL文を発行できます(正常終了する場合としない場合があります)。
アプリケーションのユーザーは、そのアプリケーションに付加された権限を使用し、非定型ツールによってデータベース表に破壊的なSQL文を発行する恐れがあります。
たとえば、次の使用例を考えてみます。
Vacation(休暇)アプリケーションには、それに対応するvacation
ロールがあります。
このvacation
ロールには、emp_tab
表に対してSELECT
、INSERT
、UPDATE
およびDELETE
文を発行する権限が含まれています。
Vacationアプリケーションは、vacation
ロールを介して取得した権限の使用を制御します。
ここで、vacation
ロールを付与されたユーザーを考えてみます。このユーザーが、Vacationアプリケーションを使用するかわりに、SQL*Plusを実行するとします。この時点でユーザーが制限を受けるのは、明示的に付与された権限またはロール(vacation
ロールを含む)を介して付与されている権限からのみです。SQL*Plusは非定型の問合せツールであるため、設計されたデータベース・アプリケーションを使用する場合のように、ユーザーは一連の事前定義アクションに制限されることはありません。ユーザーは、emp_tab
表のデータの問合せや変更を自由に実行できます。
SYSTEM
スキーマPRODUCT_USER_PROFILE
表で、各ユーザーのSQL*Plus環境のSQLおよびSQL*Plusコマンドを無効にできます。
Oracle DatabaseでなくSQL*Plusでこのセキュリティが実行されます。GRANT
、REVOKE
、およびSET ROLE
コマンドへのアクセスを制限して、ユーザーによる各自のデータベース権限の変更を制御することもできます。
PRODUCT_USER_PROFILE
表を使用すると、ユーザーがアプリケーションでアクティブにできないロールをリストできます。また、様々なコマンド(SET ROLE
など)の使用を明示的に禁止できます。
たとえば、PRODUCT_USER_PROFILE
表にエントリを作成して、次の処理を実行できます。
SQL*Plusで、clerk
およびmanager
ロールの使用を禁止できます。
SQL*Plusで、SET ROLE
の使用を禁止できます。
ユーザーMarlaが、SQL*Plusを使用してデータベースに接続するとします。Marlaには、clerk
、manager
およびanalyst
のロールがあります。前述のPRODUCT_USER_PROFILE
のエントリによって、Marlaは、SQL*Plusでanalyst
ロールのみを使用できます。また、GinnyがSET ROLE
文を発行しようとすると、SET ROLE
の使用を禁止するPRODUCT_USER_PROFILE
表のエントリが原因で、発行を明示的に禁止されます。
PRODUCT_USER_PROFILE
表は、様々な理由からセキュリティが完全には保証されないことに注意してください。前述の例では、SET ROLE
がSQL*Plusで禁止されていますが、Marlaに直接付与されているその他の権限がある場合、MarlaはSQL*Plusを使用してそれらの権限を使用できます。
関連項目:
PRODUCT_USER_PROFILE表の詳細は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』
を参照してください。
ストアド・プロシージャは、ビジネス・ロジックによって権限の使用をカプセル化し、適正なビジネス・トランザクションのコンテキストでのみ権限が実行されるようにします。
たとえば、アプリケーション開発者は、employees
表にある従業員の名前および住所を、通常の勤務時間内にのみ更新するプロシージャを作成できます。
また、セキュリティ管理者は、人事部門の担当者にemployees
表のUPDATE
権限を付与するのではなく、プロシージャのみに権限を付与できます。これによって、人事部門の担当者が権限を使用できるのはプロシージャのコンテキスト内のみになり、employees
表を直接更新できなくなります。
セキュア・アプリケーション・ロールを使用可能にできるのは、認可されたPL/SQLパッケージまたはプロシージャのみです。
PL/SQLパッケージ自体は、アプリケーションへのアクセスを制御するために必要なセキュリティ・ポリシーを反映します。
この方法でロールを作成すると、起動対象アプリケーションに対してこのタイプのロールを使用可能にする場合に制限が加えられます。たとえば、アプリケーションはユーザーがプロキシを介して接続しているかどうかをチェックするなど、認証およびカスタマイズ認可を実行できます。
このタイプのロールでは、パスワードがアプリケーションのソース・コードに埋め込まれたり、表に格納されることがないため、セキュリティが強化されます。このように、データベースが実行する処理は、セキュリティ・ポリシーの実装に基づいており、その定義は1箇所(アプリケーション内ではなくデータベース内)に格納されます。ポリシーの変更が必要な場合は、アプリケーションを修正することなく1箇所の変更で済みます。ポリシーはロールと結び付けられているため、ユーザーがデータベースに接続する方法に関係なく、結果は常に同じです。
セキュア・アプリケーション・ロールを使用可能にするには、ユーザーがセキュア・アプリケーション・ロールによって付与された権限を行使する前のログイン時に、基礎となるパッケージをアプリケーションから直接起動して実行する必要があります。ログイン・トリガーを使用してセキュア・アプリケーション・ロールを使用可能にすることも、このタイプのロールをデフォルト・ロールにすることもできません。
セキュア・アプリケーション・ロールを使用可能にすると、認可されたPL/SQLパッケージがコール・スタックにあることが検証されます。つまり、認可されたPL/SQLパッケージがロールを使用可能にするコマンドを発行しているかどうかが検証されます。
セキュア・アプリケーション・ロールは、データベース接続の存在を保証するために使用できます。セキュア・アプリケーション・ロールはパッケージによって実装されるロールであるため、このパッケージによって、ユーザーが中間層を介して、または特定のIPアドレスからデータベースに接続できることを検証できます。この方法により、セキュア・アプリケーション・ロールは、ユーザーがアプリケーション外のデータにアクセスすることを防ぎます。ユーザーは、付与されているアプリケーション権限のフレームワーク内で作業するように規定されます。
関連項目:
『Oracle Database 2日でセキュリティ・ガイド』
オブジェクト権限を使用すると、表や索引などのスキーマ・オブジェクトに対するアクションを実行できます。
内容は次のとおりです。
オブジェクト権限では、特定のスキーマ・オブジェクトに対して特定のアクションを実行する権限を付与します。
各タイプのスキーマ・オブジェクトごとに、異なるオブジェクト権限があります。オブジェクト権限の例には、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
句は、すべてのオブジェクトに影響を与えます。
内容は次のとおりです。
オブジェクト権限は、ユーザーとロールに対して付与したり、取り消すことができます
オブジェクト権限をロールに付与した場合は、その権限を選択的に使用可能にできます。オブジェクト権限を付与するにはGRANT
文を使用し、オブジェクト権限を取り消すにはREVOKE
文を使用できます。
オブジェクトの各タイプには異なるオブジェクト権限が対応付けられていますが、これらはALL
句で制御できます。
ALL
[PRIVILEGES
]を指定して、オブジェクトに対するすべての使用可能なオブジェクト権限の付与または取消しが可能です。ALL
は権限ではありません。ショートカットのようなもので、つまり1つのGRANT
文およびREVOKE
文ですべてのオブジェクト権限を付与または取り消すための方法です。すべてのオブジェクト権限がALL
ショートカットを使用して付与された場合でも、権限を個別に取り消すことができます。
同様に、個別に付与した権限をALL
を指定してすべて取り消すこともできます。ただし、REVOKE ALL
によって整合性制約が削除される場合(整合性制約は取り消そうとしているREFERENCES
権限に依存しているため)は、REVOKE
文にCASCADE CONSTRAINTS
オプションを指定する必要があります。
例4-3では、CASCADE CONSTRAINTS
を使用してHR
スキーマ内の注文表に対するすべての権限を取り消しています。
例4-3 CASCADE CONSTRAINTSを使用したすべてのオブジェクト権限の取消し
REVOKE ALL ON ORDERS FROM HR CASCADE CONSTRAINTS;
READ
権限を使用すると、ユーザーは、表またはビューに対してのみ問合せを実行できます。SELECT
権限により、表やビューへの問合せの他に、追加権限がユーザーに提供されます。
内容は次のとおりです。
ユーザーにREAD
またはSELECT
のオブジェクト権限を付与できます。
これらの権限は、ユーザーに許可するアクセス・レベルに応じて付与します。
次のガイドラインに従ってください。
ユーザーが表、ビュー、マテリアライズド・ビューまたはシノニムの問合せのみをできるようにする場合、READ
オブジェクト権限を付与する必要があります。次に例を示します。
GRANT READ ON HR.EMPLOYEES TO psmith;
ユーザーが、問合せの実行に加えて次のアクションを実行できるようにする場合、ユーザーにSELECT
オブジェクト権限を付与する必要があります。
LOCK TABLE
table_name
IN EXCLUSIVE MODE;
SELECT ... FROM
table_name
FOR UPDATE;
例:
GRANT SELECT ON HR.EMPLOYEES TO psmith;
いずれの場合も、ユーザーpsmith
はSELECT
文を使用して問合せを実行します。
READ ANY TABLE
システム権限で、データベース内の任意の表を問い合せることができるREAD
オブジェクト権限を付与します。
データベース内の任意の表に対するREAD
オブジェクト権限をユーザーが保持できるようにするには、そのユーザーにREAD ANY TABLE
システム権限を付与します。
例:
GRANT READ ANY TABLE TO psmith;
READ
オブジェクト権限と同様にREAD ANY TABLE
システム権限では、ユーザーは排他モードで表をロックしたり、更新操作用に表を選択したりできません。反対に、SELECT ANY TABLE
システム権限では、ユーザーは任意の表の問合せ以外に、SELECT ... FOR UPDATE
文を使用して表の行をロックしたり、表全体をロックできます。
READ
権限とREAD ANY TABLE
権限では特別な制限があります。
これらの権限は次のとおりです。
READ
オブジェクト権限は、SQL92_SECURITY
標準の要件には影響を及ぼしません。SQL92_SECURITY
初期化パラメータがTRUE
に設定されている場合、UPDATE
またはDELETE
文を実行するためにUPDATE
またはDELETE
以外にSELECT
オブジェクト権限をユーザーに付与する必要があるという要件が緩和されて、SELECT
のかわりにREAD
で十分であるということにはなりません。
Oracle Database Vaultが有効な場合、SQL92_SECURITY
初期化パラメータは自動的にTRUE
に設定されることに注意してください。したがって、ユーザーにREAD
オブジェクト権限またはREAD ANY TABLE
システム権限のみが付与されている場合、UPDATE
およびDELETE
文は失敗します。この場合、ユーザーにSELECT
オブジェクト権限を付与するか、ユーザーが信頼できるユーザーの場合はSELECT ANY TABLE
システム権限を付与する必要があります。
CREATE SYNONYM
文で、データベース・オブジェクトのシノニムを作成します。
表、ビュー、順序、演算子、プロシージャ、ストアド・ファンクション、パッケージ、マテリアライズド・ビュー、Javaクラス・スキーマ・オブジェクト、ユーザー定義オブジェクト・タイプのオブジェクトのシノニムに加え、別のシノニムのシノニムを作成できます。
ユーザーにシノニムを使用する権限を付与すると、基礎オブジェクトで付与されたオブジェクト権限は、ユーザーがベース・オブジェクトを名前で参照するかシノニムを使用して参照するかに関係なく適用されます。
たとえば、ユーザーOE
が次のシノニムをCUSTOMERS
表に作成するとします。
CREATE SYNONYM customer_syn FOR CUSTOMERS;
それから、OE
はcustomer_syn
シノニムに対するREAD
権限をユーザーHR
に付与します。
GRANT READ 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 READ
OE OE INHERIT PRIVILEGES
結果にはこのユーザーが、他の権限に加えて、customer_syn
シノニムの基礎オブジェクト、つまりOE.CUSTOMER
表に対するREAD
権限を持っていることが示されます。
この時点でユーザーOE
がcustomer_syn
シノニムに対するREAD
権限をHR
から取り消した場合に、HR
が自分の権限を再度調べたときの結果を次に示します。
TABLE_SCHEMA TABLE_NAME PRIVILEGE ------------ ---------- ------------------ OE OE INHERIT PRIVILEGES
ユーザーHR
は、OE.CUSTOMER
表に対するREAD
権限を失っています。このユーザーがOE.CUSTOMERS
表を問い合せると、次のエラーが表示されます。
SELECT COUNT(*) FROM OE.CUSTOMERS; ERROR at line 1: ORA-00942: table or view does not exist
表に対するオブジェクト権限によって、DML(データ操作言語)またはDDL(データ定義言語)操作レベルでの表のセキュリティが実現します。
内容は次のとおりです。
表およびビューでDELETE
、INSERT
、SELECT
およびUPDATE
の各DML操作を使用する権限を付与できます。
これらの権限は、表のデータの問合せや操作が必要なユーザーとロールに対してのみ付与してください。
表に対するINSERT
権限とUPDATE
権限は、表の特定の列に制限できます。選択的なINSERT
権限を付与されたユーザーは、選択した列に値を持つ行を挿入できます。他のすべての列には、NULL
またはその列のデフォルト値が挿入されます。選択的なUPDATE
権限によって、ユーザーは行の特定の列に限ってその値を更新できます。機密データに対するユーザー・アクセスを制限するには、INSERT
権限とUPDATE
権限を選択的に使用します。
たとえば、データ入力ユーザーにemployees
表のsalary
列を変更させないようにするには、そのsalary
列を除外した選択的なINSERT
権限またはUPDATE
権限を付与できます。また、salary
列を除外したビューによって、同じ制限をさらに高いセキュリティ・レベルで実現できます。
関連項目:
DML操作の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
ALTER
、INDEX
およびREFERENCES
の各権限は、表に対するDDL操作の実行を許可します。
これらの権限によって、他のユーザーは表への依存性を変更または作成できるため、権限の付与は控えめに行う必要があります。表に対してDDL操作を実行するユーザーには、さらに他のシステム権限やオブジェクト権限が必要な場合があります。たとえば、表にトリガーを作成するには、その表に対するALTER
TABLE
オブジェクト権限とCREATE
TRIGGER
システム権限の両方が必要です。
INSERT
権限やUPDATE
権限と同様に、REFERENCES
権限は、表の特定の列を対象として付与できます。REFERENCES
権限を付与されたユーザーは、付与の対象となった表を、自分の表の中に作成する外部キーの親キーとして使用できます。外部キーの存在によって、親キーに対して実行できるデータ操作と表の変更が制限されるため、このアクションは特殊な権限によって制御されます。列固有のREFERENCES
権限によって、権限受領者が使用できるのは、指定された列(この列には、当然、親表の主キーまたは一意キーが最低1つ含まれている)に制限されます。
関連項目:
主キー、一意キーおよび整合性制約によるデータ整合性の仕組みの詳細は、Oracle Database概要を参照してください。DMLオブジェクト権限は、表の場合と同様にビューに対しても適用できます。ビューに対するオブジェクト権限は、ビューの導出元の実表に実際に影響を与える様々なDML操作を許可します。
内容は次のとおりです。
関連項目:
ビューを作成するには、特定の権限が必要です。
ビューに対するオブジェクト権限は、ビューの導出元の実表に影響を与える様々なDML操作を許可します。
ビューを作成する権限は次のとおりです。
次のどちらかのシステム権限が、明示的に、またはロールを介して付与されている必要があります。
CREATE
VIEW
システム権限(自分のスキーマ内にビューを作成するため)
CREATE
ANY
VIEW
システム権限(別のユーザーのスキーマ内にビューを作成するため)
次のいずれかの権限が明示的に付与されている必要があります。
ビューの基礎となるすべてのベース・オブジェクトに対するSELECT
、INSERT
、UPDATE
またはDELETE
オブジェクト権限
SELECT
ANY
TABLE
、INSERT
ANY
TABLE
、UPDATE
ANY
TABLE
またはDELETE
ANY
TABLE
システム権限
さらに、自分のビューへのアクセス権を他のユーザーに付与するためには、ベース・オブジェクトに対するGRANT
OPTION
句付きのオブジェクト権限、またはADMIN
OPTION
句付きの適切なシステム権限を持っている必要があります。これらの権限を持っていない場合は、自分のビューに対するアクセス権を他のユーザーに付与できません。試行すると、ORA-01720「
エラーが発生します。object_name
に対するGRANTオプションは存在しません。」object_name
はビューの基礎となるオブジェクトを参照しており、ユーザーにはこのオブジェクトに対する十分な権限がありません。
関連項目:
Oracle Database SQL言語リファレンス
データベース・ビューでは、ユーザーが参照できるデータを制限することによって表セキュリティを強化できます。
ユーザーがビューを使用するには、ビュー自体に対する適切な権限のみが必要であり、ビューの基礎となるオブジェクトに対する権限は不要です。ただし、ビューの基礎となるオブジェクトに対するアクセス権限が削除されると、ユーザーはアクセスできなくなります。
このように動作するのは、ユーザーがビューを問い合せるときに使用されるセキュリティ・ドメインが、そのビューの定義者のセキュリティ・ドメインであるためです。基礎となるオブジェクトに対する権限がビューの定義者によって取り消されると、そのビューは無効になり、いかなるユーザーも使用できなくなります。したがって、ビューに対するアクセス権が付与されているユーザーでも、ビューの基礎となるオブジェクトに対する定義者権限が取り消された場合は、そのビューを使用できません。
たとえば、ユーザーAがビューを作成するとします。ユーザーAは、ビューの基礎となるオブジェクトに対する定義者権限を持っています。この場合、ユーザーAがそのビューに対するSELECT
権限をユーザーBに付与すると、ユーザーBがそのビューの問合せを実行できるようになります。ただし、ユーザーAがそのビューの基礎となるオブジェクトにアクセスできなくなった場合は、ユーザーBも同様にアクセスできなくなります。
ビューの場合は、次のように、表に対してさらに2つのセキュリティ・レベル(列レベルと値ベースのセキュリティ)が追加されます。
ビューは、実表の中から選択した列へのアクセスを提供できます。たとえば、employees
表の中からemployee_id
列、last_name
列およびmanager_id
列のみを表示するようにビューを定義できます。
CREATE VIEW employees_manager AS SELECT last_name, employee_id, manager_id FROM employees;
ビューでは、表の情報に対して、値ベースのセキュリティを実現できます。ビュー定義でWHERE
句を使用すると、実表の中から選択した行のみが表示されます。次の2つの例を考えてみます。
CREATE VIEW lowsal AS SELECT * FROM employees WHERE salary < 10000;
lowsal
ビューでは、employees
表のうち給与値が10000未満のすべての行にアクセスできます。lowsal
ビューでは、employees
表のすべての列にアクセスできることに注目してください。
CREATE VIEW own_salary AS SELECT last_name, salary FROM employees WHERE last_name = USER;
own_salary
ビューでは、このビューの現行ユーザーと一致するlast_name
の行のみにアクセスできます。own_salary
ビューはuser
疑似列を使用しており、この列の値は常に現行ユーザーを指します。このビューは、列レベルのセキュリティと値ベースのセキュリティの両方を兼ね備えています。
ユーザーが(スタンドアロンまたはパッケージ内の)プロシージャやファンクションを実行できるようにするには、そのユーザーにEXECUTE
権限を付与する必要があります。
内容は次のとおりです。
EXECUTE権限は、注意して処理する必要がある非常に強力な権限です。
スタンドアロン・プロシージャ、ファクションおよびパッケージを含め、プロシージャに対するオブジェクト権限は、EXECUTE権限のみです。
この権限は、プロシージャの実行、または必要なプロシージャをコールする他のプロシージャのコンパイルが必要なユーザーにのみ付与してください。ユーザーに付与された権限を確認するには、DBA_SYS_PRIVSデータ・ディクショナリ・ビューに問い合せます。
プロシージャに対するEXECUTE
オブジェクト権限を使用して、そのプロシージャを実行したり、それを参照するプログラム・ユニットをコンパイルできます。
PL/SQLユニットのコール時には、Oracle Databaseによって実行時権限チェックが実行されます。EXECUTE
ANY
PROCEDURE
システム権限があるユーザーは、データベース内の任意のプロシージャを実行できます。プロシージャの実行権限は、ロールを介してユーザーに付与できます。
関連項目:
Oracle Databaseの実行時権限チェックの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
自分のスキーマ内または別のユーザーのスキーマ内でプロシージャを作成または置換するには、特定の権限が必要です。
自分のスキーマ内でプロシージャを作成または置換するには、CREATE PROCEDURE
システム権限が必要です。別のユーザーのスキーマ内でプロシージャを作成または置換するには、CREATE ANY PROCEDURE
システム権限が必要です。
プロシージャを所有するユーザーには、プロシージャ本体で参照されるスキーマ・オブジェクトに対する権限も必要です。プロシージャを作成するには、そのプロシージャによって参照されるすべてのオブジェクトに対する必要な権限(システム権限やオブジェクト権限)が明示的に付与されている必要があります。これらの必要な権限は、ロールを介して取得することはできません。これには、作成中のプロシージャ内でコールするプロシージャに対するEXECUTE
権限も含まれます。
注意:
トリガーの場合、参照オブジェクトに対する権限をトリガーの所有者に直接付与する必要があります。権限が明示的に、またはロールを介して付与されていても、無名PL/SQLブロックでは任意の権限を使用できます。
スタンドアロン・プロシージャとパッケージの一部であるプロシージャの両方をコンパイルするには、特定の権限が必要です。
スタンドアロン・プロシージャをコンパイルするには、COMPILE
句を使用してALTER PROCEDURE
文を実行する必要があります。パッケージの一部であるプロシージャをコンパイルするには、ALTER PACKAGE
文を実行する必要があります。
次の例は、スタンドアロン・プロシージャをコンパイルする方法を示しています。
ALTER PROCEDURE psmith.remove_emp COMPILE;
スタンドアロン・プロシージャまたはパッケージ・プロシージャが別のユーザーのスキーマ内にある場合、プロシージャを再コンパイルするにはALTER ANY PROCEDURE
権限が必要です。自分のスキーマ内にあるプロシージャは、権限なしで再コンパイルできます。
EXECUTE
権限は、ユーザーがパッケージ内のPUBLICプロシージャやファンクションを実行できる強力な権限です。
内容は次のとおりです。
パッケージに対するEXECUTE
オブジェクト権限は、そのパッケージ内のすべてのプロシージャまたはファンクションに適用されます。
パッケージに対するEXECUTE
オブジェクト権限を保持するユーザーは、そのパッケージ内の任意のパブリック・プロシージャまたはファンクションを実行し、任意のパブリック・パッケージ変数の値へのアクセスや変更を実行できます。
パッケージの各構成メンバーに、特定のEXECUTE
権限を付与することはできません。したがって、データベース・アプリケーションのプロシージャ、ファンクションおよびパッケージを開発する場合は、セキュリティの確立に関して2つの選択肢を考慮してください。これらの選択肢について、次の例で説明します。
CREATE PACKAGE BODY文を使用してプロシージャを含むパッケージ本体を作成し、1つのパッケージ内で使用されるプロシージャ権限を管理できます。
例4-4では、2つのパッケージの本体に4つのプロシージャを作成しています。
例4-4: 1つのパッケージ内で使用されるプロシージャ権限
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;
CREATE PACKAGE BODY文でプロシージャ定義を含むパッケージ本体を作成し、プロシージャ権限とパッケージ・オブジェクトを管理できます。
例4-5は、単一のパッケージ本体にある4つのプロシージャ定義を示しています。2つの追加スタンドアロン・プロシージャと1つのパッケージが特別に作成され、メイン・パッケージ内に定義されているプロシージャへのアクセスを提供します。
例4-5: プロシージャ権限およびパッケージ・オブジェクト
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;
EXECUTE
権限をパッケージに対して付与することで、すべてのパッケージ・オブジェクトへの均一なアクセスが提供されることに注意してください。
型、メソッドおよびオブジェクトについて、システム権限とオブジェクト権限を制御できます。
内容は次のとおりです。
名前付きの型に対するシステム権限を使用すると、ユーザーは自分のスキーマ内での名前付きの型の作成などのアクションを実行できます。
表4-4に、名前付きの型(オブジェクト型、VARRAY
およびネストした表)に対するシステム権限のリストを示します。
表4-4 名前付きの型に対するシステム権限
権限 | 許可される操作 |
---|---|
|
名前付きの型を自分のスキーマ内に作成できます。 |
|
名前付きの型を任意のスキーマ内に作成できます。 |
|
任意のスキーマにある名前付きの型を変更できます。 |
|
任意のスキーマにある名前付きの型を削除できます。 |
|
任意のスキーマにある名前付きの型を使用および参照できます。 |
RESOURCE
ロールには、CREATE
TYPE
システム権限が含まれています。DBA
ロールには、これらの権限すべてが含まれています。
名前付きの型に適用されるオブジェクト権限は、EXECUTE
のみです。
名前付きの型に対するEXECUTE
権限があるユーザーは、その型を使用して次の操作を実行できます。
表の定義
リレーショナル表への列の定義
名前付きの型の変数またはパラメータの宣言
EXECUTE
権限によって、ユーザーは、型コンストラクタも含めて、その型のメソッドを起動できます。これは、ストアドPL/SQLプロシージャに対するEXECUTE
権限と同じです。
名前付きの型のメソッド実行は、他のストアドPL/SQLプロシージャと同じです。
ユーザーには、EXECUTE権限など、名前付きの型を使用するための適切な権限が付与されている必要があります。すべての権限付与と同様に、これらの権限は信頼できるユーザーのみに付与してください。ユーザーに付与された権限を確認するには、DBA_SYS_PRIVSデータ・ディクショナリ・ビューに問い合せます。
詳細は、「プロシージャ権限」を参照してください。
型を作成するには、適切な権限が必要です。
これらの権限は次のとおりです。
自分のスキーマにタイプを作成するには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
付きで指定)が必要です。どちらの権限もない表の所有者は、権限不足のため、表へのアクセス権を付与できません。
関連項目:
表の作成要件は、「表権限」を参照してください。
型に対するEXECUTE
権限を他のユーザーに付与するには、GRANT OPTION
付きのEXECUTE
権限が必要です。
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
およびSET CONTAINER
権限のみです。
DML文に対する列レベルと表レベルの既存の権限は、列オブジェクトと行オブジェクトの両方に適用されます。
表4-5に、オブジェクト表に対する権限をリストします。
表4-5 オブジェクト表に対する権限
権限 | 許可される操作 |
---|---|
|
オブジェクトとその属性に表からアクセスできます。 |
|
表の行を構成するオブジェクトの属性を変更できます。 |
|
表に新規オブジェクトを作成できます。 |
|
行を削除できます。 |
同様に、列オブジェクトには表に対する権限と列に対する権限が適用されます。インスタンスの取得のみでは、型情報は明らかになりません。ただし、クライアントは、型インスタンスのイメージを解釈する際に名前付きの型の情報にアクセスする必要があります。クライアントが型情報を要求すると、その型に対するEXECUTE
権限がチェックされます。
次のスキーマを考えてみます。
CREATE TYPE emp_type ( eno NUMBER, ename CHAR(31), eaddr addr_t); CREATE TABLE emp OF emp_t;
さらに、次の2つの問合せについて考えます。
SELECT VALUE(emp) FROM emp; SELECT eno, ename FROM emp;
どちらの問合せの場合も、Oracle Databaseは、emp
表に対するユーザーのSELECT
権限をチェックします。最初の問合せの場合、ユーザーは、emp_type
の型情報を取得してデータを解釈する必要があります。問合せによってemp_type
型がアクセスされると、ユーザーのEXECUTE
権限がチェックされます。
ただし、2番目の問合せでは、名前付きの型が含まれていないため、型の権限はチェックされません。
さらに、user3
は、前の項のスキーマを使用して次の問合せを実行できます。
SELECT tab1.col1.attr2 FROM user2.tab1 tab1; SELECT attr4.attr3.attr2 FROM tab3;
どちらのSELECT
文でも、user3
には基礎となる型に対する明示的な権限がありませんが、文には成功することに注意してください。これは、型の所有者と表の所有者に、GRANT
OPTION
を備えた必要な権限があるためです。
Oracle Databaseは、次のイベントに対する権限をチェックし、アクションに対する権限がクライアントにない場合はエラーを戻します。
オブジェクトのREF
値を使用してオブジェクト・キャッシュ内でオブジェクトを確保すると、Oracle Databaseは、そのオブジェクトが含まれているオブジェクト表に対するSELECT
権限をチェックします。
既存のオブジェクトを修正したり、オブジェクト・キャッシュからオブジェクトをフラッシュしたりすると、Oracle Databaseは目的のオブジェクト表に対するUPDATE
権限をチェックします。
新しいオブジェクトをフラッシュすると、Oracle Databaseは目的のオブジェクト表に対するINSERT
権限をチェックします。
オブジェクトを削除すると、Oracle Databaseは目的の表に対するDELETE
権限をチェックします。
名前付きの型のオブジェクトを確保すると、そのオブジェクトに対するEXECUTE
権限がチェックされます。
クライアントの第三世代言語アプリケーションのオブジェクトの属性を変更すると、Oracle Databaseでオブジェクト全体の更新が行われます。そのため、ユーザーにはオブジェクト表に対するUPDATE
権限が必要になります。オブジェクト表の特定列に対してのみUPDATE
権限を持つことは、アプリケーションがこれらの列に対応した属性のみ変更する場合でも、十分とはいえません。そのため、Oracle Databaseではオブジェクト表の列レベルの権限をサポートしていません。
プロシージャや表などのストアド・オブジェクトと同様に、他のオブジェクトから参照される型を依存性があると呼びます。
表が依存する型については、特殊な問題点がいくつかあります。表には、アクセス用の型定義に依存するデータが含まれているため、その型を変更すると、格納されているすべてのデータにアクセスできなくなります。変更によってこのような結果になるのは、型を使用するために必要な権限が取り消された場合や、型または依存型が削除された場合です。いずれかのアクションが発生すると、表は無効になり、アクセスできなくなります。
必要な権限が再び付与されると、権限がないために無効になった表は自動的に有効になり、アクセスできるようになります。依存型が削除されたことで無効になった表は、アクセス不能のままで、実行できるアクションは表の削除のみです。
型に対する権限の取消しや型の削除は重大な影響があるため、デフォルトでは、SQL文のREVOKE
とDROP TYPE
は限定されたセマンティクスで実装されます。つまり、どちらの文でも、名前付きの型が表または型に依存している場合は、エラーが戻されて文は取り消されます。ただし、どちらの文も、FORCE
句を使用すると常に正常終了します。依存する表がある場合、その表は無効になります。
関連項目:
REVOKE
およびDROP TYPE
SQL文の使用の詳細は、Oracle Database SQL言語リファレンスを参照してください
GRANT
文を使用すると、プロシージャの実行などの特定のアクションの実行に関する権限をユーザーに付与できます。GRANT
を使用すると、権限受領者は、他のユーザーにも権限を付与できます。
内容は次のとおりです。
関連項目:
中間層またはプロキシを介して接続されるユーザーへのロールの付与の詳細は、「プロキシ認証に対する中間層サーバーの使用」を参照してください。
システム権限とロールをユーザーやロールに付与するには、これらのタイプの付与に対して権限がどのように機能するかについて注意してください。
内容は次のとおりです。
システム権限とロールを他のユーザーやロールに付与するには、GRANT
SQL文を使用します。
次の権限が必要です。
システム権限を付与するには、ユーザーにADMIN
オプション付きのシステム権限またはGRANT ANY PRIVILEGE
システム権限が付与されている必要があります。
ロールを付与するには、ユーザーにADMIN
オプション付きのロールまたはGRANT ANY ROLE
システム権限が付与されている必要があります。
注意:
オブジェクト権限は、同じGRANT
文でシステム権限やロールと同時に付与することはできません。
システム権限とロールをユーザーに付与するには、GRANT文を使用できます。
例4-6では、システム権限CREATE SESSION
とaccts_pay
ロールをユーザーjward
に付与しています。
例4-6 ユーザーへのシステム権限とロールの付与
GRANT CREATE SESSION, accts_pay TO jward;
ディレクトリ・オブジェクトに対するEXECUTE権限を付与するには、GRANT文を使用できます。
例4-6 では、exec_dir
ディレクトリ・オブジェクトに対するEXECUTE
権限をユーザーjward
に付与しています。
例4-7 ディレクトリ・オブジェクトに対するEXECUTE権限の付与
GRANT EXECUTE ON DIRECTORY exec_dir TO jward;
WITH ADMIN OPTION
句を使用して、権限付与の能力を拡張できます。
これらの機能は次のとおりです。
権限受領者は、データベース内の他のユーザーまたはロールに対して、システム権限またはロールの付与または取消しができます。ただし、自分自身からロールを取り消すことはできません。
権限受領者は、ADMIN
オプション付きのシステム権限やロールを付与できます。
ロールの権限受領者は、そのロールを変更または削除できます。
例4-8では、new_dba
ロールをWITH ADMIN OPTION
句付きでユーザーmichael
に付与しています。
例4-8 ADMINオプションの付与
GRANT new_dba TO michael WITH ADMIN OPTION;
ユーザーmichael
は、new_dba
ロール内の権限をすべて暗黙的に使用できることに加え、必要に応じてnew_dba
ロールを付与、取消しおよび削除できます。このように、ADMIN
オプションは非常に強力な機能であるため、このオプションを付けてシステム権限やロールを付与する際は、十分に注意してください。通常、これらの権限はセキュリティ管理者向けに用意されており、システム内の他の管理者やユーザーに付与することはほとんどありません。ユーザーがロールを作成すると、そのロールは自動的にADMIN
オプション付きでその作成ユーザーに付与されることに注意してください。
1つのGRANT
SQL文で、新規ユーザーを作成してこのユーザーに権限を付与できます。
ほとんどの場合、ユーザーにCREATE SESSION
権限を付与します。
GRANT
文を使用して新規ユーザーを作成するには、権限およびIDENTIFIED BY
句を含めます。
たとえば、新規ユーザーとしてpsmith
を作成し、CREATE SESSION
システム権限をpsmith
に付与する方法は、次のとおりです。
GRANT CREATE SESSION TO psmith IDENTIFIED BY password;
IDENTIFIED BY
句を使用してパスワードを指定することで、ユーザー名がデータベースに存在しない場合も、指定したユーザー名とパスワードで新しいユーザーが作成されます。
関連項目:
ユーザーおよびロールにオブジェクト権限を付与できるほか、権限受領者が他のユーザーにその権限を付与することを許可できます。
内容は次のとおりです。
GRANT
文を使用すると、ロールとユーザーにオブジェクト権限を付与できます。
オブジェクト権限を付与するには、次のいずれかの条件を満たしている必要があります。
指定するオブジェクトを所有している。
GRANT ANY OBJECT PRIVILEGE
システム権限を付与されている。この権限を使用すると、オブジェクト所有者のかわりに権限の付与と取消しを実行できます。
オブジェクト権限が付与されるときに、WITH GRANT OPTION
句が指定されている。
注意:
同じGRANT
文で、オブジェクト権限とともにシステム権限とロールを付与することはできません。
次の例では、emp
表のすべての列に対するREAD
、INSERT
およびDELETE
のオブジェクト権限をユーザーjfee
とtsmith
に付与しています。
GRANT READ, INSERT, DELETE ON emp TO jfee, tsmith;
salary
ビューのすべてのオブジェクト権限をユーザーjfee
に付与するには、次の例のようにALL
キーワードを使用します。
GRANT ALL ON salary TO jfee;
注意:
権限受領者は、最初の権限付与にGRANT OPTION
が含まれていないかぎり、オブジェクトへのアクセス権を再度付与することはできません。したがって、前述の例では、jfee
はGRANT
文を使用してオブジェクト権限を他の誰かに付与することができません。
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
文によって生成された監査レコードには、常に権限付与を実際に実行したユーザーが示されます。
たとえば、次の使用例を考えてみます。ユーザーadams
にGRANT ANY OBJECT PRIVILEGE
システム権限があります。他の付与権限は所持していないとします。このユーザーが次の文を発行します。
GRANT SELECT ON HR.EMPLOYEES TO blake WITH GRANT OPTION;
DBA_TAB_PRIVS
ビューを調べると、hr
が権限付与者として表示されていることがわかります。
SELECT GRANTEE, GRANTOR, PRIVILEGE, GRANTABLE FROM DBA_TAB_PRIVS WHERE TABLE_NAME = 'EMPLOYEES' and OWNER = 'HR'; GRANTEE GRANTOR PRIVILEGE GRANTABLE -------- ------- ----------- ---------- BLAKE HR SELECT YES
ここで、ユーザーblake
にもGRANT ANY OBJECT PRIVILEGE
システム権限があると想定します。このユーザーが次の文を発行します。
GRANT SELECT ON HR.EMPLOYEES TO clark;
この場合は、DBA_TAB_PRIVS
ビューを再び問い合せると、blake
が権限付与者として表示されます。
GRANTEE GRANTOR PRIVILEGE GRANTABLE -------- -------- --------- ---------- BLAKE HR SELECT YES CLARK BLAKE SELECT NO
これは、blake
がすでにHR.EMPLOYEES
に対してGRANT OPTION
付きのSELECT
権限を持っているためです。
表の個々の列に対してINSERT
、UPDATE
またはREFERENCES
権限を付与できます。
注意:
列固有のINSERT
権限を付与する前に、NOT NULL
制約が定義されている列が表に含まれているかどうかを確認してください。挿入できる列を選んで権限を付与したときにNOT NULL
列が抜けていると、ユーザーは表に行を挿入できません。このような状況を回避するには、各NOT NULL
列が挿入可能であること、またはNULL
以外のデフォルト値があることを確認してください。そうでない場合、権限受領者は表に行を挿入できず、エラーが発生します。
次の文は、accounts
表のacct_no
列に対するINSERT
権限をpsmith
に付与しています。
GRANT INSERT (acct_no) ON accounts TO psmith;
次の例では、emp
表のename
およびjob
列に対するオブジェクト権限が、ユーザーjfee
およびtsmith
に付与されます。
GRANT INSERT(ename, job) ON emp TO jfee, tsmith;
システム権限とオブジェクト権限をユーザーから取り消すことができます。取消しを行う場合、権限の取消しによるカスケード効果について注意してください。
内容は次のとおりです。
REVOKE
SQL文で、システム権限およびロールを取り消します。
ADMIN
オプション付きでシステム権限またはロールを付与されているユーザーは、他のデータベース・ユーザーまたはロールから権限またはロールを取り消すことができます。取消しを行うユーザーは、権限やロールを最初に付与したユーザーでなくてもかまいません。GRANT ANY ROLE
があるユーザーは、任意のロールを取り消すことができます。
例4-9は、CREATE TABLE
システム権限とaccts_rec
ロールをユーザーpsmith
から取り消します。
例4-9 ユーザーからのシステム権限とロールの取消し
REVOKE CREATE TABLE, accts_rec FROM psmith;
システム権限またはロールのADMIN
オプションを選択的に取り消すことはできないことに注意してください。権限またはロールを取り消してから、同じ権限またはロールを
ADMIN
オプションを指定せずに再度付与する必要があります。
ユーザーが所有する複数のオブジェクト権限、オブジェクト所有者のかわりに付与したオブジェクト権限、列を選択するオブジェクト権限、およびREFERENCES
オブジェクト権限を取り消すことができます。
内容は次のとおりです。
オブジェクト権限を取り消す場合、ユーザーは一定の要件を満たしている必要があります。
次のいずれかの条件を満たしている必要があります。
以前にユーザーまたはロールにオブジェクト権限を付与している。
オブジェクト所有者のかわりに権限を付与したり取り消すことができるGRANT ANY OBJECT PRIVILEGE
システム権限を所持している。
取り消すことができるのは、権限付与者として自身で直接認可した権限のみです。GRANT OPTION
を付与した他のユーザーによる権限付与を取り消すことはできません。ただし、連鎖的な影響があります。権限付与者のオブジェクト権限を取り消すと、GRANT OPTION
を使用して伝播されたオブジェクト権限も取り消されます。
REVOKE
文で、1つのオブジェクトに対する複数の権限を取り消すことができます。
最初の権限付与者が次の文を発行すると、ユーザーjfee
とpsmith
からemp
表のSELECT
権限とINSERT
権限が取り消されます。
REVOKE SELECT, INSERT ON emp FROM jfee, psmith;
次の文は、最初にhuman_resource
ロールに付与したdept
表に対するすべてのオブジェクト権限を取り消します。
REVOKE ALL ON dept FROM human_resources;
注意:
オブジェクト権限のGRANT OPTION
を選択的に取り消すことはできません。オブジェクト権限を取り消してから、同じ権限をGRANT OPTION
を指定せずに再度付与する必要があります。ユーザーが自分自身からオブジェクト権限を取り消すことはできません。
GRANT ANY OBJECT PRIVILEGE
システム権限を使用して、オブジェクト所有者が権限付与者であるオブジェクト権限を取り消すことができます。
この操作を実行できるのは、オブジェクト所有者によって、または所有者のかわりにGRANT ANY OBJECT PRIVILEGE
システム権限を持つユーザーによって、オブジェクト権限が付与されている場合です。
オブジェクト権限が、オブジェクト所有者とREVOKE
文を実行するユーザー(特定のオブジェクト権限とGRANT ANY OBJECT PRIVILEGE
システム権限の両方を持つユーザー)の両方によって付与されている場合は、REVOKE
文を発行したユーザーによって付与されたオブジェクト権限のみが取り消されます。この使用例については、オブジェクト所有者にかわるオブジェクト権限の付与の例を使用して説明します。
ここでは、blake
がHR.EMPLOYEES
に対するSELECT
権限をclark
に付与しているとします。blake
はGRANT ANY OBJECT PRIVILEGE
システム権限を所有していますが、特定のオブジェクト権限も保有しているため、この付与はblakeに起因します。ここでは、ユーザーHR
もHR.EMPLOYEES
に対するSELECT
権限をユーザーclark
に付与しているとします。DBA_TAB_PRIVS
ビューの問合せでは、HR.EMPLOYEES
表について次の権限付与が有効であることが表示されています。
GRANTEE GRANTOR PRIVILEGE GRANTABLE -------- ------- ----------- ---------- BLAKE HR SELECT YES CLARK BLAKE SELECT NO CLARK HR SELECT NO
ユーザーblake
が次のREVOKE
文を発行します。
REVOKE SELECT ON HR.EMPLOYEES FROM clark;
ユーザーblake
がユーザーclark
に付与したオブジェクト権限のみが削除されます。オブジェクト所有者HR
による権限付与はそのまま残ります。
GRANTEE GRANTOR PRIVILEGE GRANTABLE -------- ------- ----------- ---------- BLAKE HR SELECT YES CLARK HR SELECT NO
blake
が再度REVOKE
文を発行すると、今度は(HR
のかわりに)adams
がGRANT ANY OBEJCT PRIVILEGE
システム権限を使用して付与したオブジェクト権限が削除されます。
列固有操作に対するGRANT
およびREVOKE
操作には異なる権限と制約があります。
表やビューの列を指定してINSERT
、UPDATE
およびREFERENCES
権限を付与することは可能ですが、同じようなREVOKE
文を使用して、列固有の権限を選択的に取り消すことはできません。かわりに、権限付与者は表またはビューの全列に対するオブジェクト権限を取り消してから、残しておく列固有の権限を選択的に再度付与する必要があります。
たとえば、human_resources
ロールには、dept
表のdeptno
列およびdname
列に対するUPDATE
権限が付与されているとします。このUPDATE
権限をdeptno
列のみから取り消すには、次の2つの文を発行します。
REVOKE UPDATE ON dept FROM human_resources; GRANT UPDATE (dname) ON dept TO human_resources;
このREVOKE
文によって、ロールhuman_resources
からdept
表の全列に対するUPDATE
権限が取り消されます。次にGRANT
文によって、human_resources
ロールに対して、dname
列のUPDATE
権限の付与がやりなおし、リストアまたは再発行されます。
REFERENCES
オブジェクト権限を取り消すと、外部キー制約に影響を与えます。
REFERENCES
オブジェクト権限の権限受領者がその権限を使用して外部キー制約を作成し、その制約が現在も存在している場合、権限付与者がその権限を取り消すには、REVOKE
文にCASCADE CONSTRAINTS
オプションを指定します。
例:
REVOKE REFERENCES ON dept FROM jward CASCADE CONSTRAINTS;
CASCADE CONSTRAINTS
句を指定すると、取り消されるREFERENCES
権限を使用して現在も定義されている外部キー制約が削除されます。
DDL操作に関連するオブジェクト権限の取消しではカスケード効果はありませんが、オブジェクト権限の取消しに関するカスケード効果はあります。
内容は次のとおりです。
DDL操作に関連するシステム権限を取り消したときには連鎖的な影響は発生しません。
これは、権限がADMIN
オプションとともに付与されたかどうかとは関係ありません。
たとえば、次のような場合を考えてみます。
セキュリティ管理者が、ADMIN option
を指定して、ユーザーjfee
にCREATE TABLE
システム権限を付与します。
ユーザーjfee
が表を作成します。
ユーザーjfee
が、ユーザーtsmith
にCREATE TABLE
システム権限を付与します。
ユーザーtsmith
が表を作成します。
セキュリティ管理者が、ユーザーjfee
からCREATE TABLE
システム権限を取り消します。
ユーザーjfee
が作成した表はそのまま残ります。ユーザーtsmith
の表とCREATE TABLE
システム権限はそのまま残ります。
連鎖的な影響は、DML操作に関連するシステム権限を取り消したときに発生する場合があります。ユーザーのSELECT ANY TABLE
権限を取り消すと、そのユーザーのスキーマ内に存在し、この権限に依存しているすべてのプロシージャは、権限が再度認可されないかぎり、正常に実行できなくなります。
オブジェクト権限を取り消すと、連鎖的な影響が発生する場合があります。
次のことに注意してください。
DMLオブジェクト権限を取り消すと、そのDMLオブジェクト権限に依存するオブジェクト定義にまで影響が及ぶ可能性があります。たとえば、test
プロシージャの本体に、emp
表のデータを問い合せるSQL文が記述されているとします。test
プロシージャの所有者からemp
表のSELECT
権限を取り消すと、それ以降そのプロシージャを正常に実行できなくなります。
表に対するREFERENCES権限をユーザーから取り消すと、そのユーザーが定義した外部キー整合性制約の中で、取り消されたREFERENCES権限を必要とする制約が自動的に削除されます。たとえば、ユーザーjward
にdept
表のdeptno
列に対するREFERENCES
権限が付与されているとします。このユーザーが、emp
表のdeptno
列に、dept
表のdeptno
列を参照する外部キーを作成します。dept
表のdeptno
列に対するREFERENCES
権限を取り消すと、同じ操作でemp
表のdeptno
列に対する外部キー制約も削除されます。
GRANT OPTIONを使用して伝播されたオブジェクト権限付与は、権限付与者のオブジェクト権限が取り消されると取り消されます。たとえば、GRANT OPTION
付きのemp
表に対するSELECT
オブジェクト権限を付与されているuser1
が、user2
に対してemp
表に対するSELECT
権限を付与したとします。その後、user1
からSELECT
権限を取り消します。このREVOKE
文はuser2
にも連鎖します。user1
とuser2
の取り消されたSELECT
権限に依存するオブジェクトもすべて、前述のように影響を受ける可能性があります。
ALTER
またはINDEX
オブジェクト権限を取り消しても、ALTER
およびINDEX DDL
の各オブジェクト権限を必要とするオブジェクト定義には影響を与えません。たとえば、別のユーザーに属する表に索引を作成したユーザーからINDEX
権限を取り消しても、その索引はそのまま残ります。
ロールPUBLIC
に対して、権限とロールの付与および取消しを実行できます。
PUBLIC
にはすべてのデータベース・ユーザーがアクセスできるため、PUBLIC
に対して付与されたすべての権限またはロールには、すべてのデータベース・ユーザーがアクセスできます。デフォルトでは、PUBLIC
は付与される権限がありません。
セキュリティ管理者とデータベース・ユーザーは、すべてのデータベース・ユーザーが権限またはロールを必要としている場合のみ、PUBLIC
に権限またはロールを付与してください。これによって、各データベース・ユーザーには常に、現在のグループ・タスクの正常実行に必要な権限のみが付与されているという一般規則が保証されます。
PUBLIC
ロールから権限を取り消すと、かなりの規模で影響が連鎖する可能性があります。DML操作に関連する任意の権限をPUBLIC
から取り消すと(たとえばSELECT
ANY TABLE
またはUPDATE ON
emp
)、データベース内のファンクションとパッケージを含むすべてのプロシージャが再認可されるまで再び使用できなくなります。したがって、DMLに関連する権限をPUBLIC
に付与したり、取り消す場合には注意が必要です。
関連項目:
オブジェクト依存性の管理の詳細は、『Oracle Database管理者ガイド』を参照してください。
オペレーティング・システムまたはネットワークを使用して、ロールを管理できます。これは、大規模エンタープライズでのロールの一元管理に役立ちます。
内容は次のとおりです。
Oracle Databaseを実行するオペレーティング・システムを使用して、接続時にロールをユーザーに付与できます。
この機能を使用することでセキュリティ管理者は、ユーザーのデータベース・ロールをGRANT
文やREVOKE
文を使用して明示的に付与したり取り消したりする必要がなくなります。
つまり、オペレーティング・システムを使用してロールを管理し、ユーザーのセッション作成時にOracle Databaseにそのロールを渡すことができます。このメカニズムの一部として、ユーザーのデフォルト・ロールや、ADMIN
オプション付きでユーザーに付与するロールを識別できます。オペレーティング・システムを使用してロールを使用するユーザーを認可する場合は、必ずすべてのロールをデータベース内に作成し、GRANT
文を使用してそのロールに権限を割り当てる必要があります。
ロールは、ネットワーク・サービスを介しても付与できます。
ユーザーのデータベース・ロールを識別するためにオペレーティング・システムを使用する方法の利点は、Oracleデータベースの権限管理をデータベースの外部で実施できることです。オペレーティング・システムに組み込まれたセキュリティ機能によって、ユーザーの権限が制御されます。また、このオプションを使用すると、いくつかのシステム・アクティビティのセキュリティを集中管理できるため、次のような状況で役立ちます。
MVS版Oracleの管理者が、データベース・ユーザーのロールを識別するためにRACFグループを使用する場合
UNIX版Oracleの管理者が、データベース・ユーザーのロールを識別するためにUNIXグループを使用する場合
VMS版Oracleの管理者が、データベース・ユーザーのロールを識別するために権限識別子を使用する場合
ユーザーのデータベース・ロールを識別するためにオペレーティング・システムを使用する方法の主なデメリットは、権限管理がロール・レベルでしか実施できないことです。個々の権限は、オペレーティング・システムを使用して付与することはできません。ただし、GRANT
文を使用してデータベース内で付与することは可能です。
この機能を使用する際の第2のデメリットは、オペレーティング・システムがロールを管理している場合に、デフォルトではユーザーが共有サーバーまたはその他のネットワーク接続を介してデータベースに接続できないことです。ただし、このデフォルトはオペレーティング・システムによるロール管理使用時のネットワーク接続の説明に従って変更できます。
注意:
この項で説明されている機能は、一部のオペレーティング・システムでしか使用できません。これらの機能が使用できるかどうかを確認するには、使用しているオペレーティング・システム固有のOracle Databaseマニュアルを参照してください。
OS_ROLES
初期化パラメータを使用して、オペレーティング・システムがロールをどのように識別するかを制御できます。
セッションの作成時に、データベースがオペレーティング・システムを使用して各ユーザーのデータベース・ロールを識別するように、初期化パラメータOS_ROLES
をTRUE
に設定します。
インスタンスが現在稼働している場合、そのインスタンスを再起動する必要があります。ユーザーがデータベースとのセッションを作成しようとすると、Oracle Databaseはオペレーティング・システムによって識別されるデータベース・ロールを使用して、そのユーザーのセキュリティ・ドメインを初期化します。
ユーザーのデータベース・ロールを識別するためには、各Oracle Databaseユーザーのオペレーティング・システム・アカウントが、どのデータベース・ロールをユーザーが使用できるようになるかを示すオペレーティング・システム識別子(これらはグループ、権限識別子、または他の類似した名前で呼ばれる場合があります)を持っている必要があります。ロールの指定は、どのロールがユーザーのデフォルト・ロールであるか、どのロールがADMIN
オプションで使用可能かを示すことも可能です。どのオペレーティング・システムを使用している場合も、オペレーティング・システム・レベルでのロールの指定は次の形式になります。
ora_ID_ROLE[[_d][_a][_da]]
次のように値を指定します。
ID
の定義は、オペレーティング・システムが異なると変わります。たとえばVMSでは、ID
はデータベースのインスタンス識別子、VMSではコンピュータ・タイプ、UNIXではシステムID
です。
ID
は、ORACLE_SID
と照合する際に大/小文字が区別されます。ROLE
では、大/小文字は区別されません。
ROLE
は、データベース・ロールの名前です。
d
は、このロールがデータベース・ユーザーのデフォルト・ロールであることを示すオプション文字です。
a
は、このロールがADMIN
オプション付きでユーザーに付与されることを示すオプション文字です。このオプション文字を指定することによって、ユーザーはこのロールを他のロールにのみ付与できるようになります。オペレーティング・システムを使用してロールを管理している場合は、ユーザーにロールを付与できません。
d
またはa
のいずれかを指定する場合は、その文字の直前にアンダースコア(_)を指定してください。
たとえば、オペレーティング・システム・アカウントが、プロファイルで識別される次のロールを持っているとします。
ora_PAYROLL_ROLE1 ora_PAYROLL_ROLE2_a ora_PAYROLL_ROLE3_d ora_PAYROLL_ROLE4_da
対応するユーザーがOracle Databaseのpayroll
インスタンスに接続すると、role3
とrole4
がデフォルト・ロールになり、role2
とrole4
がADMIN
オプション付きで付与されます。
オペレーティング・システムによって管理されているロールを使用する場合は、データベース・ロールがオペレーティング・システムのユーザーに付与されることに注意してください。
オペレーティング・システム・ユーザーが接続できるデータベース・ユーザーは、認可されたデータベース・ロールを使用できます。このため、OS_ROLES = TRUE
を使用している場合は、権限が付与されているオペレーティング・システム・アカウントにデータベース・アカウントを対応付けるために、すべてのOracle DatabaseユーザーをIDENTIFIED EXTERNALLY
として定義することを考慮してください。
OS_ROLES
初期化パラメータをTRUE
に設定すると、ユーザーに対するロールの付与と取消しをオペレーティング・システムで管理できるようになります。
それまでにGRANT
文によってユーザーに付与されたロールは適用されません。ただし、それらのロールはデータ・ディクショナリには残っています。オペレーティング・システム・レベルでのユーザーへのロールの付与のみが適用されます。この場合も、ユーザーは権限をロールとユーザーに付与できます。
注意:
オペレーティング・システムによってADMIN
オプション付きでロールが付与された場合、ユーザーはそのロールを他のロールにのみ付与できます。
OS_ROLES
初期化パラメータをTRUE
を設定すると、オペレーティング・システムによって付与されたロールをSET ROLE
文で動的に有効にできます。
ロールがパスワードやオペレーティング・システムによる認可を必要とするように定義されていた場合でも、この文は適用されます。ただし、ユーザーのオペレーティング・システム・アカウントで識別されないロールは、SET ROLE
文では指定できません。これは、OS_ROLES = FALSE
のときにGRANT
文を使用してロールを付与していた場合でも同じです。(このようなロールを指定しても無視されます。)
OS_ROLES
がTRUE
に設定されている場合、ユーザーは最大148個のロールを使用可能にできます。この数には、ロールに付与されている可能性のある他のロールも含まれることに注意してください。
ロールがオペレーティング・システムによって管理されている場合、デフォルトでユーザーは共有サーバーを通じてデータベースに接続できません。
リモート・ユーザーは保護されていない接続を介して別のオペレーティング・システム・ユーザーになりすますおそれがあるため、デフォルトでこのような制限が適用されています。
このようなセキュリティに対する危険性の心配がない場合は、初期化パラメータREMOTE_OS_ROLES
をTRUE
に設定することで、共有サーバーまたはその他のネットワーク接続でオペレーティング・システムのロール管理を使用できます。この変更は、次回インスタンスを起動して、データベースをマウントするときに有効になります。このパラメータのデフォルト設定はFALSE
です。
付与と取消しは、権限付与およびSET ROLE
文により左右されます。ユーザーに対してデフォルトのロールおよびロールの最大数を設定できます。
内容は次のとおりです。
付与と取消しがいつ有効になるかは、付与または取り消す権限によって異なります。
権限の付与と取消しは次のように有効になります。
任意の対象(ユーザー、ロールおよびPUBLIC
)に対するシステム権限とオブジェクト権限の付与および取消しは、即時に有効になります。
任意の対象(ユーザー、他のロール、PUBLIC
)に対するロールの付与および取消しが有効になるのは、その付与および取消しの実行後、ロールを再度使用可能にするために現行のユーザー・セッションでSET ROLE
文を発行したとき、あるいはその付与または取消しを実行した後に新しくユーザー・セッションを作成したときです。
現在使用可能なロールは、SESSION_ROLES
データ・ディクショナリ・ビューを問い合せることによって確認できます。
ユーザーまたはアプリケーションは、ユーザー・セッション中にSET ROLE
文を何度でも使用して、そのセッションで使用可能になっているロールを変更できます。
ユーザーには、SET ROLE
文で指定したロールが、事前に付与されている必要があります。
次の例では、すでに付与されているロールclerk
を使用可能にして、パスワードを指定しています。
SET ROLE clerk IDENTIFIED BY password;
「パスワードの最低要件」のガイドラインに従って、password
を安全なパスワードに置き換えます。
次の例は、SET ROLE
を使用してすべてのロールを使用禁止にする方法を示しています。
SET ROLE NONE;
ユーザーがログインすると、Oracle Databaseではそのユーザーに明示的に付与されている権限と、そのユーザーのデフォルト・ロールに含まれる権限が、すべて使用可能になります。
GRANT
文で直接付与されているか、CREATE ROLE
権限があるユーザーによってロールが作成されていることを確認します。DEFAULT ROLE
句を指定してALTER USER
文を使用して、ユーザーのデフォルト・ロールを指定します。たとえば、ユーザーjane
に対してデフォルト・ロールのpayclerk
とpettycash
を設定する方法は、次のとおりです。
ALTER USER jane DEFAULT ROLE payclerk, pettycash;
ALTER USER
文のDEFAULT ROLE
句の制限事項は、『Oracle Database SQL言語リファレンス』を参照してください。
CREATE USER
文ではユーザーのデフォルト・ロールを設定できません。ユーザーを最初に作成すると、デフォルトのユーザー・ロール設定はALL
であり、ユーザーにその後に付与されるすべてのロールがデフォルト・ロールになります。デフォルトのユーザー・ロールを制限するには、ALTER USER
文を使用します。
注意:
(グローバル・ロールやアプリケーション・ロール以外の)ロールを作成すると、このロールが自分に暗黙的に付与され、自分のデフォルト・ロールのセットが新しいロールを含むように更新されます。ユーザー・セッションで有効にできるロールは148個のみであることに注意してください。DBA
ロールのような集計ロールがユーザーに付与されると、そのロールに付与されるロールはユーザーが持っているロール数に含まれます。たとえば、あるロールには20個のロールが付与されており、そのロールをユーザーに付与すると、そのユーザーは21個の追加ロールを持っていることになります。したがって、新しいロールをユーザーに付与するときは、ALTER USER
文のDEFAULT ROLE
句を使用してそのユーザーのデフォルト・ロールとして指定されるロールが多すぎないよう確認してください。
ロールはいくつでもユーザーに付与できますが、任意の時点でログイン・ユーザーに対して有効にできるロール数は最大148個です。
したがって、ユーザー・セッションでこのユーザーはすべての権限を使用できるわけではありません。ベスト・プラクティスとして、ユーザーに付与するロールの数を必要最小限のロールに制限します。
ユーザーへのロール付与に関する追加のガイドラインは、ロールの保護に関するガイドラインを参照してください。
Oracle Databaseには、各種の権限とロール付与に関する情報を確認できる、一連のデータ・ディクショナリ・ビューがあります。
内容は次のとおりです。
Oracle Databaseには、権限およびロール付与に関する情報を表示するデータ・ディクショナリ・ビューが用意されています。
表4-6 に、権限とロールの付与に関する情報を入手するために問合せ可能なデータ・ディクショナリ・ビューをリストします。
表4-6 権限およびロール情報を表示するデータ・ディクショナリ・ビュー
ここでは、これらのビューの使用例をいくつか示します。各例では、次の文がすでに発行されていることを前提としています。
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 READ, 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 READ, DELETE ON emp TO jward;
GRANT INSERT (ename, job) ON emp TO swilliams, jward;
関連項目:
これらのデータ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
DBA_SYS_PRIVS
データ・ディクショナリ・ビューは、ロールとユーザーに対して付与されているすべてのシステム権限を返します。
次に例を示します。
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リファレンス』を参照してくださいDBA_ROLE_PRIVS
問合せは、ユーザーと他のロールに対して付与されているロールをすべて返します。
次に例を示します。
SELECT * FROM DBA_ROLE_PRIVS; GRANTEE GRANTED_ROLE ADM ------------------ ------------------------------------ --- SWILLIAMS SECURITY_ADMIN NO
関連項目:
DBA_ROLE_PRIVS
ビューの詳細は、『Oracle Databaseリファレンス』を参照してくださいDBA_TAB_PRIVS
およびDBA_COL_PRIVS
データ・ディクショナリ・ビューには、ユーザーに付与されているオブジェクト権限が表示されます。
DBA_TAB_PRIVS
データ・ディクショナリ・ビューは、指定のユーザーに対して付与されているオブジェクト権限をすべて(列固有の権限を除く)返します。
次に例を示します。
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リファレンス』を参照してくださいSESSION_ROLES
およびSESSION_PRIVS
データ・ディクショナリ・ビューには、データベース・セッションの現在の権限ドメインが表示されます。
SESSION_ROLES
ビューでは、発行者が現在使用できるロールがすべて表示されます。
次に例を示します。
SELECT * FROM SESSION_ROLES;
ユーザーswilliams
に対してsecurity_admin
ロールが使用可能になっている場合に、この問合せを実行すると、Oracle Databaseから次の情報が戻されます。
ROLE ------------------------------ SECURITY_ADMIN
次の問合せを実行すると、発行者のセキュリティ・ドメインで現在使用可能なシステム権限がすべて表示されます。これには、明示的に付与されている権限と使用可能なロールから付与された権限の両方が含まれています。
SELECT * FROM SESSION_PRIVS;
ユーザーswilliams
に対してsecurity_admin
ロールが使用可能になっている場合に、この問合せを実行すると、Oracle Databaseから次の結果が戻されます。
PRIVILEGE ---------------------------------------- AUDIT SYSTEM CREATE SESSION CREATE USER BECOME USER ALTER USER DROP USER CREATE ROLE DROP ANY ROLE GRANT ANY ROLE AUDIT ANY CREATE PROFILE ALTER PROFILE DROP PROFILE
ユーザーswilliams
に対してsecurity_admin
ロールが使用禁止になっている場合、最初の問合せでは何も表示されず、2番目の問合せではCREATE SESSION
権限の付与に関する行が1行のみ表示されます。
関連項目:
SESSION_ROLES
ビューの詳細は、『Oracle Databaseリファレンス』を参照してくださいDBA_ROLES
データ・ディクショナリ・ビューでは、データベースのすべてのロールと各ロールに対して使用されている認証が表示されます。
次に例を示します。
SELECT * FROM DBA_ROLES; ROLE PASSWORD ---------------- -------- CONNECT NO RESOURCE NO DBA NO SECURITY_ADMIN YES
関連項目:
DBA_ROLES
ビューの詳細は、『Oracle Databaseリファレンス』を参照してくださいROLE_ROLE_PRIVS
、ROLE_SYS_PRIVS
およびROLE_TAB_PRIVS
の各データ・ディクショナリ・ビューには、ロールの権限ドメインに関する情報が表示されます。
次に例を示します。
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リファレンス』を参照してください