4 ユーザー権限の管理

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

権限管理について

ユーザー権限は、次のように制御できます。

個々の権限の付与および取消し。UPDATE SQL文を実行する権限など、個々の権限を個々のユーザーまたはユーザーのグループに付与できます。
ロールの作成と権限の割当て。ロールは、ユーザーまたは他のロールに一括で付与する関連権限の名前付きグループです。
セキュア・アプリケーション・ロールの作成。セキュア・アプリケーション・ロールを使用すると、データベース・ロールを有効にできるタイミングを制御する条件を定義できます。たとえば、セキュア・アプリケーション・ロールを使用すると、ユーザー・セッションでデータベース・ロールを有効にするのを許可する前に、そのセッションに関連するIPアドレスをチェックできます。

権限付与のガイドライン

権限は、表の更新や削除などの特定のアクションを実行する権利であるため、データベース・ユーザーに必要以上の権限は付与しないでください。権限の管理の概要は、『Oracle Database 2日でデータベース管理者』の「ユーザー権限とロールについて」を参照してください。『Oracle Database 2日でデータベース管理者』では、権限を付与する方法の例も示されています。

つまり、最小権限の原則とは、ユーザーに、効率的かつ簡潔に作業を行うために実際に必要な権限のみを与えることです。最小権限の原則を実践するために、次の制限を可能なかぎり行ってください。

データベース・ユーザーに付与するSYSTEM権限とOBJECT権限の数。
データベースにSYS権限で接続するユーザーの数。

たとえば、通常、CREATE ANY TABLE権限はデータベース管理者権限を持っていないユーザーには付与されません。

PUBLICユーザー・グループの権限処理のガイドライン

データベース・サーバーのユーザー・グループPUBLICから、不要な権限とロールを削除する必要があります。PUBLICはOracle Databaseですべてのユーザーに付与されるデフォルト・ロールとして機能します。どのデータベース・ユーザーも、PUBLICに付与される権限を使用できます。これらの権限には、様々なPL/SQLパッケージでのEXECUTEが含まれ、最小権限のユーザーにより、直接アクセスを許可されていない関数がアクセスおよび実行される可能性があります。

ユーザーへのロール付与のガイドライン

ロールは、ユーザーまたは他のロールに一括して付与する関連権限の名前付きグループです。ロールの管理の基礎については、『Oracle Database 2日でデータベース管理者』の「ロールの管理」を参照してください。『Oracle Database 2日でデータベース管理者』の「例: ロールの作成」も参照してください。

ロールを使用することで、迅速かつ容易にユーザーに権限を付与できます。Oracle Databaseで定義されているロールを使用することもできますが、必要な権限のみを含む独自のロールを作成すると、より継続的な制御が可能になります。Oracle Databaseで定義済のCONNECTロールの権限は変更または削除される可能性があります。このロールには現在、CREATE SESSION権限しかありません。以前は他に8個の権限がありました。

定義したロールに含まれる権限が、特定の職務に必要な権限のみであることを確認します。アプリケーション・ユーザーに既存のロールに含まれるすべての権限が必要ない場合は、適切な権限のみを付与できる別のロールを適用するか、権限をさらに制限するロールを作成して割り当てます。

たとえば、ユーザーSCOTTはよく知られているデフォルトのユーザー・アカウントで、侵入されやすい可能性があるため、このユーザーの権限を厳密に制限する必要があります。CREATE DBLINK権限ではあるデータベースから別のデータベースへのアクセスが許可されるため、SCOTTに対するこの権限を削除します。次にユーザーに付与されたロール全体を削除します。これは、ロールによって付与される権限は、個別に削除できないためです。必要な権限のみを含む独自のロールを再作成し、新しいロールをユーザーに付与します。同様に、セキュリティを高めるために、CREATE DBLINK権限を必要としないすべてのユーザーからこの権限を削除します。

セキュア・アプリケーション・ロールによるアプリケーション・アクセスの制御

セキュア・アプリケーション・ロールは、認可されたPL/SQLパッケージによってのみ有効にできるロールです。PL/SQLパッケージ自体は、アプリケーションへのアクセスを制御するために必要なセキュリティ・ポリシーを反映します。

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

セキュア・アプリケーション・ロールについて

セキュア・アプリケーション・ロールは、認可されたPL/SQLパッケージによってのみ有効にできるロールです。このパッケージは、アプリケーションへのアクセスを制御する1つ以上のセキュリティ・ポリシーを定義します。ロールおよびパッケージは通常、作成者（通常はセキュリティ管理者）のスキーマに作成されます。セキュリティ管理者は、データベースのセキュリティを維持する責任があるデータベース管理者です。

セキュア・アプリケーション・ロールを使用する利点は、ロール自体に付与された権限に加えて、アプリケーション・アクセスにセキュリティの追加レイヤーを作成できることです。セキュア・アプリケーション・ロールを使用すると、パスワードがアプリケーション・ソース・コードに埋め込まれたり表に格納されないため、セキュリティが強化されます。このため、データベースが行う決定はセキュリティ・ポリシーの実装に基づいて行われます。これらの定義はアプリケーションではなくデータベースにまとめて格納されるため、各アプリケーションのポリシーを変更するのではなく、このポリシーを一度に変更します。ポリシーはロールにバインドされているため、データベースに接続しているユーザー数に関係なく、結果は常に同じになります。

セキュア・アプリケーション・ロールには次のコンポーネントがあります。

セキュア・アプリケーション・ロール自体。このロールを作成するには、CREATE ROLE文をIDENTIFIED USING句とともに使用してPL/SQLパッケージに関連付けます。次に、一般的にロールに付与する権限をこのロールに付与します。

このロールをユーザーに直接付与しないでください。この作業はPL/SQLパッケージが行います。ただし、サイトのポリシーがユーザーにロールを付与するものである場合は、ユーザー・アカウントの変更でデフォルトのロールを使用しないかぎり、セキュア・アプリケーション・ロールをユーザーに付与することも可能です。次はその例です。
```
ALTER USER psmith DEFAULT ROLE NONE;
```
セキュア・アプリケーション・ロールに関連付けるPL/SQLパッケージ、プロシージャまたはファンクション。 PL/SQLパッケージは、データベースへのログインを試行する人物にロールを付与またはロールを拒否する条件を設定します。PL/SQLパッケージ、プロシージャまたはファンクションは、定義者の権限ではなく実行者の権限を使用して作成する必要があります。実行者の権限では、パッケージがアクセスするすべてのオブジェクトに対するEXECUTE権限がユーザーに与えられます。実行者の権限のプロシージャは現行ユーザー（プロシージャを実行したユーザー）の権限で実行されます。このようなプロシージャは、特定のスキーマにバインドされません。様々なユーザーがこのようなプロシージャを実行でき、集中化されたアプリケーション・ロジックを使用することで複数のユーザーが自身のデータを管理できます。実行者の権限のパッケージを作成するには、プロシージャ・コードの宣言部でAUTHID CURRENT_USER句を使用します。

ユーザーのロールを有効（または無効）にするために、PL/SQLパッケージにはDBMS_SESSION.SET_ROLEコールも含まれている必要があります。

PL/SQLパッケージを作成してから、適切なユーザーにパッケージに対するEXECUTE権限を付与する必要があります。
ユーザーがログオンしたときにPL/SQLパッケージを実行する方法。 PL/SQLパッケージを実行するには、ユーザーがロールによって付与される権限を使用する前に、アプリケーションから直接PL/SQLパッケージをコールする必要があります。ユーザーがログオンしたときにPL/SQLパッケージを自動的に実行するログオン・トリガーは使用できません。

ユーザーがアプリケーションにログインすると、必要に応じて、パッケージ内のポリシーによるチェックが行われます。チェックを通過したユーザーにはロールが付与され、アプリケーションへのアクセスが許可されます。ユーザーがチェックを通過できない場合、アプリケーションへのアクセスは拒否されます。

チュートリアル: セキュア・アプリケーション・ロールの作成

このチュートリアルでは、2人のユーザーMatthew WeissとWinston TaylorがOE.ORDERS表から情報を取得する場合を説明します。この表へのアクセス権は、EMPLOYEE_ROLEセキュア・アプリケーション・ロールで定義されています。MatthewはWinstonのマネージャで、OE.ORDERS表内の情報にアクセスできます。Winstonは情報にアクセスできません。

このチュートリアルでは、次の手順を実行します。

手順1: セキュリティ管理者アカウントを作成する

セキュリティを強化するためには、システム管理者に職務を割り当てる際に、責務分離の概念を取り入れる必要があります。このマニュアルのチュートリアルでは、sec_adminというセキュリティ管理者アカウントを作成し、使用します。

sec_adminセキュリティ管理者アカウントを作成するには、次のようにします。

Database Controlを起動します。

Database Controlを起動する手順については、『Oracle Database 2日でデータベース管理者』を参照してください。
管理者のユーザー名（SYSTEMなど）とパスワードを入力し、「ログイン」をクリックします。

データベースのホームページが表示されます。
「サーバー」をクリックして、「サーバー」サブページを表示します。
「セキュリティ」で、「ユーザー」を選択します。

「ユーザー」ページが表示されます。
「作成」をクリックします。

「ユーザーの作成」ページが表示されます。
次の情報を入力します。
- 名前: sec_admin
- プロファイル: デフォルト
- 認証: パスワード
- 「パスワードの入力」および「パスワードの確認」: 「パスワードの作成要件」に示されている要件を満たすパスワードを入力します。
- デフォルト表領域: SYSTEM
- 一時表領域: TEMP
- ステータス: ロック解除
「システム権限」をクリックして、「システム権限」サブページを表示します。
「リストを編集」をクリックします。

「システム権限の変更」ページが表示されます。
「使用可能なシステム権限」リストから次の権限を選択し、「移動」をクリックして「選択したシステム権限」リストに移動します（複数の権限は[Ctrl]キーを押しながら選択します）。
- CREATE PROCEDURE
- CREATE ROLE
- CREATE SESSION
- SELECT ANY DICTIONARY
「OK」をクリックします。
「管理者オプション」では、ボックスを選択しないでください。
「OK」をクリックします。

手順2: このチュートリアルで使用するユーザー・アカウントを作成する

MatthewとWinstonは、どちらもHR.EMPLOYEESスキーマの従業員のサンプルです。従業員のマネージャIDや電子メール・アドレスなどの情報を含む列があります。以降でセキュア・アプリケーション・ロールをテストするため、これら2人の従業員のユーザー・アカウントを作成する必要があります。

ユーザー・アカウントを作成するには、次のようにします。

Database Controlで「データベース・インスタンス」リンクを選択して、データベースのホームページを表示します。

Database Controlにログインしていない場合、Database Controlの起動方法の詳細は『Oracle Database 2日でデータベース管理者』を参照してください。「ログイン」ページで、管理者のユーザー名（SYSTEMなど）およびパスワードを入力し、「ログイン」をクリックします。
「サーバー」をクリックして、「サーバー」サブページを表示します。
「セキュリティ」で、「ユーザー」を選択します。

「ユーザー」ページが表示されます。
「作成」をクリックします。

「ユーザーの作成」ページが表示されます。
次の情報を入力します。
- 名前: mweiss（Matthew Weissのユーザー・アカウントを作成するため）
- プロファイル: デフォルト
- 認証: パスワード
- 「パスワードの入力」および「パスワードの確認」: 「パスワードの作成要件」に示されている要件を満たすパスワードを入力します。
- デフォルト表領域: USERS
- 一時表領域: TEMP
- ステータス: ロック解除
「システム権限」をクリックして、「システム権限」サブページを表示します。
「リストを編集」をクリックします。

「システム権限の変更」ページが表示されます。
「使用可能なシステム権限」リストからCREATE SESSION権限を選択し、「移動」をクリックして「選択したシステム権限」リストに移動します。
「OK」をクリックします。

CREATE SESSIONがユーザーmweissのシステム権限としてリストされた状態で「ユーザーの作成」ページが表示されます。
CREATE SESSIONの「管理者オプション」が選択されていないことを確認し、「OK」をクリックします。

「ユーザー」ページが表示されます。
ユーザー・リストから「MWEISS」を選択し、次に「アクション」リストから「類似作成」を選択します。次に「実行」をクリックします。
「ユーザーの作成」ページで、次の情報を入力してWinstonのユーザー・アカウントを作成します。このアカウントはMatthewのユーザー・アカウントとほぼ同じになります。
- 名前: wtaylor
- 「パスワードの入力」および「パスワードの確認」: 「パスワードの作成要件」に示されている要件を満たすパスワードを入力します。
「OK」をクリックします。

wtaylorにCREATE SESSION権限を付与する必要はありません。これは、この処理が「類似作成」アクションによって実行されているためです。
Database Controlを終了します。

これで、Matthew WeissとWinston Taylorの両方にユーザー・アカウントが作成され、同じ権限が与えられました。

手順3: セキュア・アプリケーション・ロールを作成する

これで、employee_roleセキュア・アプリケーション・ロールを作成する準備ができました。これを実行するには、セキュリティ管理者sec_adminとしてログインする必要があります。「手順1: セキュリティ管理者アカウントを作成する」に、sec_adminアカウントの作成方法の説明があります。

セキュア・アプリケーション・ロールを作成するには、次のようにします。

SQL*Plusを起動し、セキュリティ管理者sec_adminとしてログオンします。
```
SQLPLUS sec_admin
Enter password: password
```
SQL*Plusが起動し、デフォルトのデータベースに接続してから、プロンプトが表示されます。
```
SQL> 
```
SQL*Plusの起動の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
次のセキュア・アプリケーション・ロールを作成します。
```
CREATE ROLE employee_role IDENTIFIED USING sec_roles;
```
IDENTIFIED USING句では、関連付けられているPL/SQLパッケージ（この場合はsec_roles）内でのみ有効（または無効）にするロールを設定します。この段階では、sec_roles PL/SQLパッケージが存在している必要はありません。
ユーザーOEとして接続します。
```
CONNECT oe
Enter password: password
```
OEがロックされているというエラー・メッセージが表示された場合は、OEアカウントのロックを解除し、次の文を入力してパスワードをリセットします。セキュリティを考慮して、以前のリリースのOracle Databaseで使用していたパスワードと同じパスワードは再使用しないでください。「パスワードの作成要件」に示されているパスワードのガイドラインに従って、任意のセキュアなパスワードを入力します。
```
CONNECT sys/as sysdba
Enter password: sys_password
PASSWORD OE
Changing password for OE
New password: password
Retype new password: password
Password changed.

CONNECT oe
Enter password: password
```
次の文を入力して、OE.ORDERS表に対するSELECT権限をEMPLOYEE_ROLEロールに付与します。
```
GRANT SELECT ON OE.ORDERS TO employee_role;
```
ユーザーに直接ロールは付与しないでください。ユーザーがセキュリティ・ポリシーの条件を満たしている場合、ロールの付与はPL/SQLパッケージにより行われます。ユーザーに直接ロールを付与する必要がある場合は、ユーザーのロールを無効にする必要があります。これは、パッケージのセキュリティ・ポリシーがチェックを開始する前に、ロールが無効になっている必要があるためです。たとえば、ユーザーwsmith（wsmithにロールが最初に付与されると仮定）のロールを無効にするには、次の文を入力します。
```
ALTER USER wsmith DEFAULT ROLE NONE;
```

手順4: 参照表を作成する

employee_roleロールを付与するユーザーを決定するプロシージャを作成します。このプロシージャは、マネージャID 100のSteven Kingに報告を行うマネージャにのみemployee_roleを付与します。この情報はHR.EMPLOYEES表にあります。ただし、この表には給与情報などの機密データが含まれており、また、使用した場合すべてのユーザーがアクセスする必要があるため、このプロシージャでは使用できません。実際にはほとんどの場合に、参照表として既存のアプリケーション表を使用します。このチュートリアルでは、従業員の名前、従業員ID、マネージャIDのみを含む独自の参照表を作成します。

HR.HR_VERIFYルックアップ・テーブルを作成するには、次のようにします。

SQL*Plusで、ユーザーHRとして接続します。
```
CONNECT hr
Enter password: password
```
HRがロックされているというエラー・メッセージが表示された場合は、そのアカウントのロックを解除し、次の文を入力してパスワードをリセットします。セキュリティを考慮して、以前のリリースのOracle Databaseで使用していたパスワードと同じパスワードは再使用しないでください。「パスワードの作成要件」に示されているパスワードのガイドラインに従って、任意のセキュアなパスワードを入力します。
```
CONNECT sys/as sysdba
Enter password: password
ALTER USER HR ACCOUNT UNLOCK IDENTIFIED BY password;
CONNECT hr
Enter password: password
```

次のCREATE TABLE SQL文を入力して参照表を作成します。

CREATE table hr_verify AS 
SELECT employee_id, first_name, last_name, email, manager_id 
FROM employees;
/

次のSQL文を入力して、この表に対するEXECUTE権限をMWEISSとWTAYLORに付与します。

GRANT SELECT ON hr.hr_verify TO mweiss;
GRANT SELECT ON hr.hr_verify TO wtaylor;
GRANT SELECT ON hr.hr_verify TO sec_admin;

手順5: PL/SQLプロシージャを作成してセキュア・アプリケーション・ロールを設定する

次に、セキュア・アプリケーション・ロールのプロシージャを作成します。多くの場合、プロシージャを格納するパッケージを作成しますが、このチュートリアルは、1つのセキュア・アプリケーション・ロールのみをテスト（プロシージャで定義）するシンプルなチュートリアルであるため、プロシージャのみを作成します。複数のプロシージャを作成してロールをテストする場合は、パッケージ内にプロシージャを作成します。

PL/SQLパッケージは、SQL文でアクセスできる関連プロシージャおよびタイプのセットに対する単純で明確なインタフェースを定義します。またパッケージは、コードを再利用可能にし、メンテナンスを簡単にします。セキュア・アプリケーション・ロールに関するここでの利点は、セキュリティ・ポリシーのグループを作成できることです。このポリシー・グループは一緒に使用され、アプリケーションを保護するように設計された堅牢なセキュリティ計画を表します。セキュリティ・ポリシーに違反したユーザー（または潜在的な侵入者）に対して、エラーを記録するための監査チェックをパッケージに追加できます。

セキュア・アプリケーション・ロールのプロシージャを作成するには、次のようにします。

SQL*Plusでユーザーsec_adminとして接続します。
```
CONNECT sec_admin
Enter password: password
```

次のCREATE PROCEDURE文を入力してセキュア・アプリケーション・ロールのプロシージャを作成します。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

CREATE OR REPLACE procedure sec_roles AUTHID CURRENT_USER
AS
v_user varchar2(50);
v_manager_id number :=1;
BEGIN
v_user := lower((sys_context ('userenv','session_user')));
SELECT manager_id
INTO v_manager_id FROM hr.hr_verify WHERE lower(email)=v_user;
IF v_manager_id = 100
THEN
EXECUTE IMMEDIATE 'SET ROLE employee_role';
ELSE NULL;
END IF;
EXCEPTION
WHEN NO_DATA_FOUND THEN v_manager_id:=0;
DBMS_OUTPUT.PUT_LINE(v_manager_id);
END;
/

この例では、次のとおりです。

1行目: CREATE PROCEDURE文に、実行者の権限を使用してプロシージャを作成するAUTHID CURRENT_USER句を追加します。AUTHID CURRENT_USER句は、現在のユーザーの権限を使用し、実行者の権限を使用してパッケージを作成します。

パッケージを機能させるには、実行者の権限を使用する必要があります。実行者の権限は、パッケージがアクセスするすべてのオブジェクトに対するEXECUTE権限をユーザーに与えます。

実行者の権限のプロシージャ内で有効化されるロールは、プロシージャの終了後も有効なままになります。ただし、ユーザーがセッションを終了すると、ユーザーはセキュア・アプリケーション・ロールに関連付けられた権限を持たなくなります。この場合、残りのセッションのロールを有効にする専用のプロシージャを使用できます。

ユーザーは、定義者権限のプロシージャ内のセキュリティ・ドメインを変更できないため、セキュア・アプリケーション・ロールは実行者権限のプロシージャ内でのみ有効になります。

実行者の権限を使用したプロシージャの作成の重要性については、「セキュア・アプリケーション・ロールについて」を参照してください。
3行目: ユーザーのセッション情報を格納するv_user変数を宣言します。
4行目: v_userユーザーのマネージャIDを格納するv_manager_id変数を宣言します。
6行目: ユーザー・ログオンのユーザー・セッション情報（この場合は、MatthewまたはWinston）を取得します。ユーザー・セッション情報を取得するには、SQLファンクションSYS_CONTEXTをネームスペース属性USERENV（'userenv'、session_attribute）とともに使用して、この情報をv_user変数に書き込みます。

このファンクションから返される情報は、ユーザーが認証された方法、クライアントのIPアドレスおよびユーザーがプロキシを介して接続したかどうかを示します。SYS_CONTEXTの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
7～8行目: 現行ユーザーのマネージャIDを取得します。SELECT文によって、マネージャIDがv_manager_id変数にコピーされ、HR.HR_VERIFY表で現行ユーザーのマネージャIDがチェックされます。
9から13行目: IF条件により、ユーザーにsec_rolesロールを付与すべきかどうかテストされます。この例の場合は、MatthewのマネージャであるSteven King（従業員番号は100）に報告を行うかどうかが条件となります。Matthewのように、Kingに報告を行う場合、ユーザーにはセキュア・アプリケーション・ロールが付与されます。報告を行わない場合は、ロールは付与されません。

結果として、Matthew WeissはSteven Kingの直属の部下であるためセキュア・アプリケーション・ロールを付与されますが、WinstonはSteven Kingの直属の部下ではないためロールは付与されません。
10～12行目: IF条件内では、THEN条件によってSET ROLE文がすぐに実行され、ロールが付与されます。これが実行されない場合は、ELSE条件により、権限付与が拒否されます。
14から15行目: データが検出されない場合は、EXCEPTION文を使用してv_manager_idを0に設定します。
16行目: マネージャIDをバッファにコピーしてすぐに使用できるようにします。

手順6: MatthewとWinstonのプロシージャにEXECUTE権限を付与する

この段階で、MatthewとWinstonはOE.ORDERS表にアクセスを試行できますが、アクセスはできません。次の手順で、MatthewとWinstonにsec_rolesプロシージャのEXECUTE権限を付与します。sec_rolesプロシージャは実行できますが、OE.ORDERS表から選択したときに、アクセスが許可または拒否されます。

sec_rolesプロシージャのEXECUTE権限を付与するには、次のようにします。

SQL*Plusで、ユーザーsec_adminとして次のGRANT SQL文を入力します。

GRANT EXECUTE ON sec_admin.sec_roles TO mweiss;
GRANT EXECUTE ON sec_admin.sec_roles TO wtaylor;

手順7: EMPLOYEE_ROLEセキュア・アプリケーション・ロールをテストする

MatthewとWinstonとしてログオンし、OE.ORDERS表にアクセスを試行して、employee_roleセキュア・アプリケーション・ロールをテストします。MatthewとWinstonがログオンすると、OE.ORDERS表でSELECT文を発行する前に、employee_roleプロシージャが実行されてロールの検証が行われます。

ユーザーMWEISSとしてemployee_roleセキュア・アプリケーション・ロールをテストするには、次のようにします。

ユーザーmweissとして接続します。

CONNECT mweiss
Enter password: password

次のSQL文を入力してsec_rolesプロシージャを実行します。
```
EXEC sec_admin.sec_roles;
```
この文により、現行セッションに対してsec_rolesプロシージャが実行されます。
OE.ORDERSで次のSELECT文を実行します。
```
SELECT count(*) FROM oe.orders;
```
MatthewにはOE.ORDERS表へのアクセス権があります。
```
  COUNT(*)
----------
       105
```

次に、Winstonがセキュア・アプリケーションにアクセスしようとします。

ユーザーWTAYLORとしてemployee_roleセキュア・アプリケーション・ロールをテストするには、次のようにします。

SQL*Plusでユーザーwtaylorとして接続します。
```
CONNECT wtaylor
Enter password: password
```
次のSQL文を入力してsec_rolesプロシージャを実行します。
```
EXEC sec_admin.sec_roles;
```
この文により、現行セッションに対してsec_rolesプロシージャが実行されます。
OE.ORDERSで次のSELECT文を実行します。
```
SELECT count(*) FROM oe.orders;
```
WinstonはSteven Kingに直接報告を行わないため、OE.ORDERS表へのアクセス権がありません。SELECT文を実行した場合でも、ORDERS表に含まれる実際の注文数はわかりません。
```
ERROR at line 1:
ORA-00942: 表またはビューが存在しません。
```

手順8: このチュートリアルで使用したコンポーネントを削除する（オプション）

このチュートリアルで作成したコンポーネントを削除します。

コンポーネントを削除するするには、次のようにします。

SQL*Plusで、SYSDBA権限を持つSYSとして接続します。
```
CONNECT SYS/AS SYSDBA
Enter password: password
```
次のDROP文を入力します。
```
DROP USER mweiss;
DROP USER wtaylor;
```
ユーザーsec_adminは削除しないでください。このマニュアルの以降のチュートリアルで、このユーザーが必要になります。
SQL*Plusでユーザーsec_adminとして接続します。
```
CONNECT sec_admin
Enter password: password
```

次のDROP SQL文を入力します。

DROP ROLE employee_role;
DROP PROCEDURE sec_roles;

ユーザーHRとして接続してから、HR_VERIFY表を削除します。
```
CONNECT HR
Enter password: password
DROP TABLE hr_verify;
```
SQL*Plusを終了します。
```
EXIT
```

権限セキュリティに使用される初期化パラメータ

表4-1に、ユーザー権限を保護するために使用する初期化パラメータを示します。

表4-1 権限セキュリティに使用される初期化パラメータ

初期化パラメータ	デフォルト設定	説明
`O7_DICTIONARY_ACCESSIBILITY`	`FALSE`	`SYSTEM`権限に対する制限を制御します。このパラメータの詳細は、「データ・ディクショナリ保護の有効化」を参照してください。
`OS_ROLES`	`FALSE`	Oracleまたはオペレーティング・システムが各ユーザー名のロールを識別および管理するかどうかを決定します。
`MAX_ENABLED_ROLES`	`30`	他のロールに含まれるロールを含め、ユーザーが有効にできるデータベース・ロールの最大数を指定します。
`REMOTE_OS_ROLES`	`FALSE`	オペレーティング・システム・ロールがリモート・クライアントに対して許可されるかどうかを指定します。デフォルト値の`FALSE`を指定すると、Oracleはリモート・クライアントのロールを識別および管理します。
`SQL92_SECURITY`	`FALSE`	`UPDATE`文や`DELETE`文などを実行するためにユーザーに`SELECT`オブジェクト権限が付与されている必要があるかどうかを指定します。

初期化パラメータを変更するには、「初期化パラメータ値の変更」を参照してください。初期化パラメータの詳細は、『Oracle Databaseリファレンス』および『Oracle Database管理者ガイド』を参照してください。