| Oracle® Databaseセキュリティ・ガイド 12c リリース1 (12.1) B71285-10 |
|
 前 |
 次 |
権限とロールの認可を使用すると、ユーザーが毎日のタスクを実行するために保持する権限を制御します。
内容は次のとおりです。
関連項目:
権限の使用を分析するポリシーの作成方法の詳細は、『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初期化パラメータを設定する場合は、initSID.oraファイルで変更します。あるいは、サーバー・パラメータ・ファイル(SPFILE)を使用してデータベースを起動した場合は、SYSDBA管理権限を持つユーザーSYSとしてSQL*PlusにログインしてからALTER SYSTEM文を入力することもできます。
例4-1では、SQL*PlusのALTER SYSTEM文を発行して、O7_DICTIONARY_ACCESSIBILTY初期化パラメータをFALSEに設定する方法を示しています。
例4-1 O7_DICTIONARY_ACCESSIBILITYのFALSEへの設定
ALTER SYSTEM SET O7_DICTIONARY_ACCESSIBILITY=FALSE SCOPE=SPFILE;
O7_DICTIONARY_ACCESSIBILITYをFALSEに設定すると、任意のスキーマ内のオブジェクトへのアクセスを可能にするシステム権限(たとえば、CREATE ANY PROCEDUREのようなANY権限を持つユーザー)ではSYSスキーマ内のオブジェクトへのアクセスが許可されません。これは、SYSスキーマ内のオブジェクト(データ・ディクショナリ・オブジェクト)へのアクセスがSYSDBA管理権限を使用して接続するユーザーに制限されていることを意味します。SYSユーザーはSYSDBA権限とSYSOPER権限のどちらかでログインする必要があることに注意してください。それ以外の場合、 ORA-28009「SYSでの接続はSYSDBAまたはSYSOPERで行う必要があります」エラーが発生します。O7_DICTIONARY_ACCESSIBILITYをTRUEに設定すると、データベースにユーザーSYSとしてログインできるようになり、SYSDBA権限やSYSOPER権限を指定する必要もありません。
他のスキーマのオブジェクトへのアクセスを提供するシステム権限で、他のユーザーがSYSスキーマ内のオブジェクトにアクセスすることはできません。たとえば、SELECT ANY TABLE権限を持つユーザーは、他のスキーマのビューや表にはアクセスできますが、ディクショナリ・オブジェクト(動的パフォーマンス・ビューの実表、通常のビュー、パッケージおよびシノニム)は選択できません。ただし、これらのユーザーは、明示的なオブジェクト権限を付与することで、SYSスキーマ内のオブジェクトにアクセスできるようになります。
関連項目:
O7_DICTIONARY_ACCESSIBILITY初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください明示的なオブジェクト権限のあるユーザーまたは管理権限で接続しているユーザー(SYSDBA)は、SYSスキーマ内のオブジェクトにアクセスできます。
表4-1に、SYSスキーマ内のオブジェクトへのアクセスが必要なユーザーに対して付与できるロールをリストします。
表4-1 SYSスキーマ・オブジェクトにアクセスできるロール
| ロール | 説明 |
|---|---|
|
このロールを付与されたユーザーには、データ・ディクショナリ・ビューに対する |
|
このロールを付与されたユーザーには、データ・ディクショナリ内にあるパッケージとプロシージャに対する |
|
このロールを付与されたユーザーは、システム監査表 注意: 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文を使用するか、initSID.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リファレンス』を参照してください