セキュリティの範囲は広く、接続に関するネットワーク・セキュリティ、オペレーティング・システム・リソースまたはJava仮想マシン(JVM)定義クラスやユーザー定義クラスのアクセス制御および実行制御などがあります。また、外部ソースからインポートされたJavaアーカイブ(JAR)ファイルのバイトコードの検証も含まれます。次の各項では、Oracle DatabaseのJavaアプリケーションに使用できる様々なセキュリティ・サポートについて説明します。
ネットワーク・セキュリティには、認証およびデータの機密保護という2つの主要な側面があります。認証およびデータの機密保護のタイプは、データベースにOracle Netを介して接続するか、またはJava Database Connectivity(JDBC)を介して接続するかによって決定します。次の表で、Oracle NetおよびJDBC接続のセキュリティについて説明します。
関連項目:
|
データベースに接続した後も、データベースに格納されたリソースにアクセスするには、適切なJava2セキュリティのパーミッションとデータベース権限が必要になります。次のようなリソースがあります。
表やPL/SQLパッケージなどのデータベース・リソース
ファイルやソケットなどのオペレーティング・システム・リソース
Oracle JVMクラス
ユーザーによってロードされたクラス
これらのリソースは次の方式で保護されます。
注意:
|
この項の内容は、次のとおりです。
各ユーザーまたはスキーマには、ソケット、ファイルおよびシステム・プロパティなどのオペレーティング・システム・リソースにアクセスするための適切なパーミッションを割り当てる必要があります。
Java2セキュリティは、Javaアプリケーションに柔軟で構成可能なセキュリティを提供します。Java2セキュリティでは、ロードされた各オブジェクトについてスキーマまたはロールに付与するパーミッションを正確に定義できます。Oracle8i リリース8.1.5では、次の保護ロールを使用できます。
注意: このリリースでは下位互換性を維持するために前述の2つのロールが残されています。しかし、これらは使用せずに、各パーミッションを明示的に指定することをお薦めします。 |
Oracle JVMセキュリティはJava2セキュリティに基づいているため、クラスに対するパーミッションはクラス単位で割り当てます。これらのパーミッションは、データベース管理ツールを使用して割り当てられます。各パーミッションは、Permission
オブジェクトにカプセル化され、Permission
表に格納されます。Permission
には、String
値を取る、target
属性とaction
属性が含まれます。
Java2セキュリティはデータベースを対象に作成されていません。Java2セキュリティ・モデルをデータベース内で適用すると、いくつかの相違が明らかになります。たとえば、Java2セキュリティでは、すべてのアプレットは暗黙的に信頼がおけないと定義され、CLASSPATH
内のクラスはすべて信頼できると定義されます。Oracle Databaseでは、すべてのクラスがセキュアなデータベースにロードされます。このため、信頼できるクラスとして処理されません。
次の表で、Sun社のJava2セキュリティとOracle Databaseのセキュリティ実装の違いを説明します。
Java2セキュリティと同様に、Oracle Databaseはセキュリティ・クラスをサポートしています。通常は、ツールを使用するか、またはセキュリティ・ポリシー・ファイルを編集して、コード・ベースにパーミッションを設定します。Oracle Databaseでは、データベースのポリシー表を変更するDBMS_JAVA
プロシージャを使用して、パーミッションを動的に設定します。
ポリシー表を表示するために、USER_JAVA_POLICY
とDBA_JAVA_POLICY
の2つのビューが用意されています。いずれのビューにも、付与されているパーミッションと制限パーミッションに関する情報が含まれています。DBA_JAVA_POLICY
ビューにはポリシー表内のすべての行が表示されます。USER_JAVA_POLICY
ビューには現行ユーザーに関連するパーミッションのみが表示されます。次に、各ビューに表示される行について説明します。
パーミッションを設定するには、次の2つの方法があります。
注意: 完全なセキュリティ設定を確保するには、ファイングレイン定義を実装してください。一般的な定義の方が実装は簡単ですが、必要なレベルのセキュリティ設定を得られない場合があります。 |
ファイングレイン定義を使用して、特定のユーザーまたはロールに対してパーミッションを個別に付与できます。アクセスするためのパーミッションを付与しないと、そのスキーマでのアクセスは拒否されます。ポリシー表に個別にパーミッションを設定するには、次の情報を指定する必要があります。
パーミッションは、SQLまたはJavaのいずれかを使用して付与できます。いずれの場合もパーミッション表内の行を識別する行キー識別子が戻されます。DBMS_JAVA
のJavaバージョンでは、各メソッドによって、行キー識別子が戻りパラメータまたはパラメータ・リストのOUT
変数として戻されます。PL/SQLのDBMS_JAVA
パッケージでは、行キーはkey OUT
パラメータを定義するプロシージャでのみ戻されます。このキーを使用して、特定のパーミッションを使用可能または使用禁止にします。
権限付与を実行した後、該当のパーミッション用に行がすでに存在している場合、更新は発生しませんが、その行のキーが戻されます。行が使用禁止になっている場合は、権限付与を実行すると既存の行が使用可能になります。
DBMS_JAVA
パッケージを使用してパーミッションを付与するには、次のように記述します。
procedure grant_permission ( grantee varchar2, permission_type varchar2, permission_name varchar2, permission_action varchar2 ) procedure grant_permission ( grantee varchar2, permission_type varchar2, permission_name varchar2, permission_action varchar2, key OUT number)
Javaを使用してパーミッションを付与するには、次のように記述します。
long oracle.aurora.rdbms.security.PolicyTableManager.grant ( java.lang.String grantee, java.lang.String permission_type, java.lang.String permission_name, java.lang.String permission_action); void oracle.aurora.rdbms.security.PolicyTableManager.grant ( java.lang.String grantee, java.lang.String permission_type, java.lang.String permission_name, java.lang.String permission_action, long[] key);
DBMS_JAVA
パッケージを使用してパーミッションを制限するには、次のように記述します。
procedure restrict_permission ( grantee varchar2, permission_type varchar2, permission_name varchar2, permission_action varchar2) procedure restrict_permission ( grantee varchar2, permission_type varchar2, permission_name varchar2, permission_action varchar2, key OUT number)
Javaを使用してパーミッションを制限するには、次のように記述します。
long oracle.aurora.rdbms.security.PolicyTableManager.restrict ( java.lang.String grantee, java.lang.String permission_type, java.lang.String permission_name, java.lang.String permission_action); void oracle.aurora.rdbms.security.PolicyTableManager.restrict ( java.lang.String grantee, java.lang.String permission_type, java.lang.String permission_name, java.lang.String permission_action, long[] key);
例10-1に、grant_permission()
メソッドを使用してパーミッションを付与する方法を示します。例10-2に、restrict()
メソッドを使用してパーミッションを制限する方法を示します。
ポリシー表を変更するための適切なパーミッションがあることを前提とすると、DBMS_JAVA
パッケージ内にあるgrant_permission()
メソッドを使用してPolicyTable
を変更し、指定ファイルへのユーザー・アクセスを許可できます。この例のユーザーLarry
は、PolicyTable
を変更するパーミッションを持っています。SQLパッケージ内で、Larry
は、次のように、ユーザーDave
に対してファイルの読取り/書込みのパーミッションを付与できます。
connect larry
Enter password: password
REM Grant DAVE permission to read and write the Test1 file.
call dbms_java.grant_permission('DAVE', 'java.io.FilePermission', '/test/Test1', 'read,write');
REM commit the changes to PolicyTable
commit;
一般的な規則に対する制限または例外を指定するには、restrict()
メソッドを使用できます。一般的な規則とは、ほとんどの場合、パーミッションがtrueの状態(付与されている)の規則を指します。ただし、この規則には例外がある場合があります。この例外に対して、制限パーミッションを指定します。
ディレクトリ全体に対して読取りまたは書込みを禁止する一般的な規則を定義してある場合は、restrict()
メソッドを使用してこの規則の一部を制限するように定義できます。たとえば、/tmp
ディレクトリに格納されている自分のパスワード・ファイルを除いて、このディレクトリ内のすべてのファイルへのアクセスを許可するには、/tmp
ディレクトリ内のすべてのファイルに対する読取り/書込みのパーミッションを付与した後、パスワード・ファイルに対する読取り/書込みアクセスを制限します。
制限に対する例外を指定する場合は、明示的な権限付与パーミッションを作成して制限パーミッションをオーバーライドする必要があります。前述の例では、ファイルの所有者がパスワードファイルを変更できるようにするには、1人のユーザーに対して、アクセスを許可するためのさらに明示的なパーミッションを付与することによって、制限をオーバーライドできます。Oracle JVMセキュリティではすべての規則を考慮して、パスワード・ファイルへのアクセス権を持つユーザーを判断します。次の図にこれを示します。
明示的な規則は次のとおりです。
制限パーミッションに暗黙的な要求が含まれている場合に、付与パーミッションを有効にするには、その制限パーミッションにも暗黙的な付与が含まれている必要があります。
次に、この例を実装するコードを示します。
connect larry
Enter password: password
REM Grant permission to all users (PUBLIC) to be able to read and write
REM all files in /tmp.
call dbms_java.grant_permission('PUBLIC', 'java.io.FilePermission', '/tmp/*', 'read,write');
REM Limit permission to all users (PUBLIC) from reading or writing the
REM password file in /tmp.
call dbms_java.restrict_permission('PUBLIC', 'java.io.FilePermission', '/tmp/password', 'read,write');
REM By providing a more specific rule that overrides the limitation,
REM Larry can read and write /tmp/password.
call dbms_java.grant_permission('LARRY', 'java.io.FilePermission', '/tmp/password', 'read,write');
commit;
このコードでは、次の処理が実行されます。
すべてのユーザーに、/tmp
内のすべてのファイルに対する読取り/書込みのパーミッションを付与します。
すべてのユーザーについて、/tmp
内のpassword
ファイルに対する読取り/書込みを制限します。
Larry
にpassword
ファイルに対する読取り/書込みの明示的なパーミッションを付与します。
ポリシー表を更新するための管理パーミッションの取得
すべてのパーミッションはPolicyTable
内の行です。ポリシー表はデータベース内の表であるため、変更には適切なパーミッションが必要です。特に、PolicyTablePermission
オブジェクトは表を変更するために必要です。Oracle JVMを初期化した後、PolicyTablePermission
を付与されたJAVA_ADMIN
ロールのみがPolicyTable
を変更できます。データベース管理者(DBA)にはただちにJAVA_ADMIN
ロールが割り当てられます。したがって、DBAグループに割り当てられているユーザーは、JAVA_ADMIN
の全パーミッションを自動的に取得できます。
この表にパーミッションを行として追加する必要がある場合は、JAVA_ADMIN
によって、PolicyTablePermission
を使用してスキーマに更新権限が付与されている必要があります。このパーミッションは、スキーマが表に行を追加できるように定義します。各PolicyTablePermission
は、特定のパーミッション・タイプに対応しています。たとえば、あるファイルへのアクセスを制御するパーミッションを追加するには、FilePermission
に対するパーミッションを付与または制限できるPolicyTablePermission
が必要です。一度これを実行すると、FilePermission
に対する管理パーミッションを持つことができます。
管理者は、他のパーミッションと同様の方法でPolicyTablePermission
を付与または制限できますが、構文は複雑になります。使いやすくするため、grant_policy_permission()
またはgrantPolicyPermission()
メソッドを使用して、管理パーミッションを付与できます。
DBMS_JAVA
を使用してポリシー表の管理パーミッションを付与するには、次のように記述します。
procedure grant_policy_permission ( grantee varchar2, permission_schema varchar2, permission_type varchar2, permission_name varchar2 ) procedure grant_policy_permission ( grantee varchar2, permission_schema varchar2, permission_type varchar2, permission_name varchar2, key OUT number )
Javaを使用してポリシー表の管理パーミッションを付与するには、次のように記述します。
long oracle.aurora.rdbms.security.PolicyTableManager.grantPolicyPermission (java.lang.String grantee, java.lang.String permission_schema, java.lang.String permission_type, java.lang.String permission_name); void oracle.aurora.rdbms.security.PolicyTableManager.grantPolicyPermission (java.lang.String grantee, java.lang.String permission_schema, java.lang.String permission_type, java.lang.String permission_name, long[] key);
注意: ポリシー表のPolicyTablePermission 行の名前には、# で区切られたパーミッション・タイプとパーミッション名の両方が含まれています。たとえば、ファイルを読み取るための管理権限をユーザーに付与する場合は、この行の名前にjava.io.FilePermission#read を含めます。Permission クラスとパーミッション名は# で区切ります。 |
例10-3に、PolicyTable
の変更方法を示します。
例10-3 PolicyTableパーミッションの付与
この例では、JAVA_ADMIN
ロールが割り当てられているSYS
が、Larry
に、FilePermission
についてPolicyTable
を更新するパーミッションを付与します。このパーミッションが付与されると、Larry
は他のユーザーにファイルの読取り、書込みおよび削除のパーミッションを付与できます。
REM Connect as SYS, which is assigned JAVA_ADMIN role, to give Larry permission
REM to modify the PolicyTable
connect SYS as SYSDBA
Enter password: password
REM SYS grants Larry the right to administer permissions for
REM FilePermission
call dbms_java.grant_policy_permission('LARRY', 'SYS', 'java.io.FilePermission', '*');
独自のパーミッション・タイプを作成する手順は、次のとおりです。
java.security.Permission
クラスを拡張して、独自のパーミッションを作成します。ユーザーが定義するパーミッションはすべて、Permission
を拡張したものである必要があります。次の例では、MyPermission
を作成します。これは、BasicPermission
(Permission
を拡張するパーミッション)を拡張するパーミッションです。
package test.larry; import java.security.Permission; import java.security.BasicPermission; public class MyPermission extends BasicPermission { public MyPermission(String name) { super(name); } public boolean implies(Permission p) { boolean result = super.implies(p); return result; } }
指定したユーザーへの管理とアクションのパーミッションの付与
パーミッションを作成すると、作成者がそのパーミッションの所有者になります。所有者には、暗黙的に管理パーミッションが付与されます。つまり、所有者はこのパーミッションの管理者になり、grant_policy_permission()
を実行できます。管理パーミッションを付与されたユーザーは、ユーザー定義のパーミッションについてポリシー表を更新できます。
たとえば、LARRY
がMyPermission
というパーミッションを作成した場合は、本人のみが自分または他のユーザーのためにgrant_policy_permission()
をコールできます。このメソッドは、MyPermission
に対する権限を付与できるユーザーについて、PolicyTable
を更新します。次のコードでその方法を示します。
REM Since Larry is the user that owns MyPermission, Larry connects to
REW the database to assign permissions for MyPermission.
connect larry
Enter password: password
REM As the owner of MyPermission, Larry grants himself the right to
REM administer permissions for test.larry.MyPermission within the JVM
REM security PolicyTable. Only the owner of the user-defined permission
REM can grant administrative rights.
call dbms_java.grant_policy_permission ('LARRY', 'LARRY', 'test.larry.MyPermission', '*');
REM commit the changes to PolicyTable
commit;
管理権限を付与された後は、作成したパーミッションに対してアクションのパーミッションを付与できます。たとえば、次のSQL文は、LARRY
にMyPermission
内のすべてのアクションを実行するパーミッションを付与し、DAVE
には「act.
」で始まるアクションのみを実行するパーミッションを付与します。
REM Since Larry is the user that creates MyPermission, Larry connects to
REW the database to assign permissions for MyPermission.
connect larry
Enter password: password
REM Once able to modify PolicyTable for MyPermission, Larry grants himself
REM full permission for MyPermission. Notice that the Permission is prefixed
REM with its owner schema.
call dbms_java.grant_permission( 'LARRY', 'LARRY:test.larry.MyPermission', '*', null);
REM Larry grants Dave permission to do any actions that start with 'act.*'.
call dbms_java.grant_permission
('DAVE', 'LARRY:test.larry.MyPermission', 'act.*', null);
REM commit the changes to PolicyTable
commit;
パーミッションを使用したセキュリティ・チェックの実装
MyPermission
に対してパーミッションを作成、ロードおよび割り当てた後は、パーミッションをチェックするためにSecurityManager
のコールを実装する必要があります。次の例には、sensitive()
、act()
、print()
およびhello()
の4つのメソッドがあります。前述の手順のSQLを使用してパーミッションが付与されているため、この例のクラスでは次のユーザーがメソッドを実行できます。
LARRY
はすべてのメソッドを実行できます。
DAVE
には、act()
メソッドのみを実行するパーミッションが付与されています。
print()
メソッドとhello()
メソッドはすべてのユーザーが実行できます。print()
メソッドはパーミッションをチェックしません。そのため、すべてのユーザーがこれを実行できます。hello()
メソッドはAccessController.doPrivileged()
を実行します。つまり、このメソッドはLARRY
に割り当てられたパーミッションを使用して実行します。これは定義者権限と呼ばれます。
package test.larry; import java.security.AccessController; import java.security.Permission; import java.security.PrivilegedAction; import java.sql.Connection; import java.sql.SQLException; /** * MyActions is a class with a variety of public methods that * have some security risks associated with them. We will rely * on the Java security mechanisms to ensure that they are * performed only by code that is authorized to do so. */ public class Larry { private static String secret = "Larry's secret"; MyPermission sensitivePermission = new MyPermission("sensitive"); /** * This is a security sensitive operation. That is it can * compromise our security if it is executed by a "bad guy". * Only larry has permission to execute sensitive. */ public void sensitive() { checkPermission(sensitivePermission); print(); } /** * Will display a message from Larry. You must be * careful about who is allowed to do this * because messages from Larry may have extra impact. * Both larry and dave have permission to execute act. */ public void act(String message) { MyPermission p = new MyPermission("act." + message); checkPermission(p); System.out.println("Larry says: " + message); } /** * display secret key * No permission check is made; anyone can execute print. */ private void print() { System.out.println(secret); } /** * Display "Hello" * This method invokes doPrivileged, which makes the method run * under definer's rights. So, this method runs under Larry's * rights, so anyone can execute hello. Only Larry can execute hello */ public void hello() { AccessController.doPrivileged(new PrivilegedAction() { public Object run() { act("hello"); return null; } }); } /** * If a security manager is installed ask it to check permission * otherwise use the AccessController directly */ void checkPermission(Permission permission) { SecurityManager sm = System.getSecurityManager(); sm.checkPermission(permission); } }
パーミッションを定義する行を作成した場合は、その行が適用されないように使用禁止にできます。ただし、行アクションを再度実行する場合には、その行を使用可能にできます。不要になった行は表から削除できます。行を削除するには、最初にその行を使用禁止にする必要があります。行を使用禁止にしないと、削除できません。
行を使用禁止にするには、次のいずれかのメソッドを使用できます。
revoke_permission()
このメソッドには、grant()
メソッドおよびrestrict()
メソッドと同じパラメータを指定します。これは、指定されたパラメータと一致するすべての行をポリシー表全体で検索します。
disable_permission()
このメソッドは、ポリシー表の1行のみを使用禁止にします。そのためには、パラメータとしてこのメソッドにポリシー表のキーを指定します。このキーは、パーミッションを使用可能にしたり、削除する場合にも必要になります。パーミッションのキー番号を取り出すには、次のいずれかを実行します。
DBMS_JAVA
を使用してパーミッションを使用禁止にするには、次のように記述します。
procedure revoke_permission (grantee varchar2, permission_type varchar2, permission_name varchar2, permission_action varchar2) procedure disable_permission (key number)
Javaを使用してパーミッションを使用禁止にするには、次のように記述します。
void oracle.aurora.rdbms.security.PolicyTableManager.revoke (java.lang.String grantee, java.lang.String permission_type, java.lang.String permission_name, java.lang.String permission_action_type); void oracle.aurora.rdbms.security.PolicyTableManager.disable (long key);
DBMS_JAVA
を使用してパーミッションを使用可能にするには、次のように記述します。
procedure enable_permission (key number)
Javaを使用してパーミッションを使用可能にするには、次のように記述します。
void oracle.aurora.rdbms.security.PolicyTableManager.enable (long key);
DBMS_JAVA
を使用してパーミッションを削除するには、次のように記述します。
procedure delete_permission (key number)
Javaを使用してパーミッションを削除するには、次のように記述します。
void oracle.aurora.rdbms.security.PolicyTableManager.delete (long key);
パーミッション・タイプ
パーミッションを付与または制限する場合は、パーミッション・タイプを指定する必要があります。アクセス制御に使用できるパーミッション・タイプは次のとおりです。
表10-1は、インストールされているパーミッション・タイプの一覧です。
注意: SYS には、Oracle Databaseに付属するライブラリをロードするためのパーミッションが付与されています。ただし、データベースにCライブラリをロードすることはセキュアでないため、Oracle JVMでは他のユーザーによるライブラリのロードはサポートされていません。このため、loadLibrary.* に対してRuntimePermission を付与することは許可されません。 |
oracle.aurora.rdbms.security.PolicyTablePermission
このパーミッションは、ポリシー表を更新できるユーザーを制御します。特定のパーミッション・タイプについてポリシー表を更新する権限を付与されたユーザーは、一部のリソースへのアクセスを制御できます。
Oracle JVMを初期化した後、JAVA_ADMIN
ロールのみがPolicyTablePermission
を使用してポリシー表の管理権限を付与できます。この権限を付与されると、そのユーザーは、自分の付与パーミッションおよび制限パーミッションを使用してポリシー表を更新できます。
ポリシー表の更新権限を付与する場合は、DBMS_JAVA
パッケージのgrant_policy_permission()
メソッドを使用できます。表を更新したら、DBA_JAVA_POLICY
またはUSER_JAVA_POLICY
ビューのいずれかを表示して、パーミッションを付与したユーザーを参照できます。
oracle.aurora.security.JServerPermission
このパーミッションを使用して、Oracle JVMリソースへのアクセス権を付与および制限します。JServerPermission
は、BasicPermission
を拡張するパーミッションです。次の表は、JServerPermission
によってアクセス権を付与するパーミッション名を示します。
表10-2 JServerPermissionの説明
Grantee(権限受領者) | パーミッション・タイプ | パーミッション名 | パーミッションの付与または制限 | アクション |
---|---|---|---|---|
|
|
|
付与 |
NULL |
|
|
|
付与 |
NULL |
|
|
|
付与 |
NULL |
|
|
|
付与 |
NULL |
|
|
|
付与 |
NULL |
|
|
|
付与 |
NULL |
|
|
|
制限 |
NULL |
|
|
|
制限 |
NULL |
|
|
|
制限 |
NULL |
|
|
|
付与 |
NULL |
|
|
|
付与 |
NULL |
|
|
付与 |
||
|
|
取消し |
初期のパーミッションの付与
Oracle JVMを最初に初期化すると、特定のパーミッションを付与された複数のロールが移入されます。次の表は、それらのロールとその初期のパーミッションを示します。
JAVA_ADMIN
ロールには、すべてのパーミッションについてポリシー表を変更するためのアクセス権が付与されます。SYS
を含むすべてのDBAにはJAVA_ADMIN
が付与されます。表10-1にリストされているパーミッションについては、ポリシー表を更新する完全な管理権限が付与されます。SYS
には、JAVA_ADMIN
のパーミッションの他に、JDKの標準的な機能およびOracle JVMの詳細をサポートするために必要な追加のパーミッションも付与されます。
表10-3は、SYS
に付与される追加のパーミッションの一部です。
パーミッション・タイプ | パーミッション名 | アクション |
---|---|---|
|
NULL |
|
|
NULL |
|
|
NULL |
|
|
NULL |
|
|
書込み |
|
|
NULL |
|
|
NULL |
|
|
NULL |
|
|
NULL |
|
|
NULL |
表10-4は、最初にすべてのユーザーに付与または制限されるパーミッションの一覧です。
パーミッション・タイプ | パーミッション名 | パーミッションの付与または制限 | アクション |
---|---|---|---|
|
|
制限 |
NULL |
|
|
付与 |
読取り |
|
付与 |
書込み |
|
|
付与 |
書込み |
|
|
|
付与 |
NULL |
|
付与 |
NULL |
|
|
付与 |
NULL |
|
|
付与 |
NULL |
|
|
付与 |
NULL |
|
|
付与 |
NULL |
|
|
付与 |
NULL |
|
|
付与 |
NULL |
|
|
制限 |
NULL |
|
|
|
付与 |
NULL |
表10-5は、最初にJAVAUSERPRIV
ロールに付与されるパーミッションの一覧です。
パーミッション・タイプ | パーミッション名 | アクション |
---|---|---|
|
接続、解決 |
|
|
読取り |
|
|
|
NULL |
表10-6は、最初にJAVASYSPRIV
ロールに付与されるパーミッションの一覧です。
パーミッション・タイプ | パーミッション名 | アクション |
---|---|---|
|
適用できるアクションなし |
|
|
読取り、書込み、実行、削除 |
|
|
アクセプト、接続、リスニング、解決 |
|
|
|
NULL |
|
NULL |
|
|
NULL |
|
|
NULL |
|
|
NULL |
|
|
NULL |
|
|
NULL |
|
|
NULL |
|
|
NULL |
表10-7は、最初にJAVADEBUGPRIV
ロールに付与されるパーミッションの一覧です。
Oracle8i Databaseリリース8.1.5では、JAVASYSPRIV
、JAVAUSERPRIV
またはJAVADEBUGPRIV
ロールをスキーマに付与することによって、Oracle JVMセキュリティが制御されていました。Oracle Database 11gでは、これらのロールはパーミッション・グループとして存在しています。ユーザー独自のパーミッションの組合せを設定および定義できます。パーミッションを定義した後は、任意のユーザーまたはロールに任意のパーミッションの組合せを付与できます。付与されたユーザーには、そのロールに設定されている内容と同じパーミッションが付与されます。さらに、追加のパーミッションが必要な場合は、指定したユーザーまたはロールのいずれかに個別にパーミッションを追加できます。ポリシー表に定義されたパーミッションには累積の効果があります。
次の例では、LarryとDaveに次のパーミッションが付与されます。
LarryにはJAVASYSPRIV
パーミッションが付与されます。
Daveには、JAVADEBUGPRIV
パーミッション、およびシステム上の全ファイルへの読取りと書込みのパーミッションが付与されます。
REM Granting Larry the same permissions as those existing within JAVASYSPRIV grant javasyspriv to larry; REM Granting Dave the ability to debug grant javadebugpriv to dave; commit; REM I also want Dave to be able to read and write all files on the system call dbms_java.grant_permission('DAVE', 'SYS:java.io.FilePermission', '<<ALL FILES>>', 'read,write', null);
デバッグ・ロールJAVADEBUGPRIV
は、デバッガを実行するパーミッションを付与するために作成されました。このロールに割り当てられるパーミッションの一覧は、表10-7を参照してください。デバッグ・エージェントをコールするパーミッションを取得するには、次のように、コール元にJAVADEBUGPRIV
またはデバッグJServerPermission
が付与されている必要があります。
REM Granting Dave the ability to debug grant javadebugpriv to dave; REM Larry grants himself permission to start the debug agent. call dbms_java.grant_permission( 'LARRY', 'oracle.aurora.security.JServerPermission', 'Debug', null);
デバッガはサーバー上のコードとデータの両方に広範囲にアクセスできますが、デバッガの使用は開発環境に限定する必要があります。
クラスをロードするには、次のパーミッションが必要です。
JServerPermission("LoadClassInPackage." + class_name)
class_name
には、ロードするクラスの完全修飾名を指定します。
このパーミッションには、システム・パッケージへのロードやシステム・クラスの置換は含まれません。システム・クラスをロードするパーミッションが付与されている場合でも、Oracle Databaseではロードを実行できません。システム・クラスとは、Oracle DatabaseでCREATE JAVA SYSTEM
文を使用してインストールされるクラスです。システム・クラスを置換しようとすると、次のエラーがスローされます。
ORA-01031 "Insufficient privileges"
次に、データベースのインストール後、各ユーザーが実行できる処理について説明します。
SYS
はシステム・クラス以外の全クラスをロードできます。
すべてのユーザーは、java.*
、oracle.aurora.*
およびoracle.jdbc.*
以外のパターンで始まるクラスを自分のスキーマにロードできます。このようなクラスを別のスキーマにロードする場合は、JServerPermission(LoadClassInPackage.
class
)
のパーミッションを付与する必要があります。
次の例は、oracle.aurora.tools.*
パッケージにクラスをロードするパーミッションをSCOTT
に付与する方法を示します。
dbms_java.grant_permission('SCOTT','SYS:oracle.aurora.security.JServerPermission','LoadClassInPackage.oracle.aurora.tools.*',null);
注意: この項はDBAおよびセキュリティ管理者を対象としており、Oracle Databaseで実行されているJavaアプリケーションでJava SE機能のRuntime.exec をセキュアに使用するためのガイドラインを示します。 |
java.lang.Runtime.exec
メソッドはJava SEライブラリにあり、リリース9以降のJava仮想マシン(Java VM)でサポートされており、新しいオペレーティング・システム(OS)プロセスにまたがって、指定されたコマンドおよび引数を新しいプロセスで実行します。SecurityManager
が存在する場合(Java VMがデータベースで実行されている場合は常に存在します)、新しいOSプロセスが開始される前に、関連するパス名に対するファイル実行許可のセキュリティ・チェックが実行されます。DBAまたはセキュリティ管理者は、適切なファイル読取り許可、書込み許可および実行許可を、サーバー側のOSコマンドの実行を認可されているデータベース・ユーザーに選択的に付与する役割を持ちます。さらに、次の各項で説明するように、dbms_java.set_runtime_exec_credentials
プロシージャを使用して、生成されたコマンドのOSユーザー・アイデンティティを制御することを強くお薦めします。
設計上、Runtime.exec
およびjava.lang.ProcessBuilder
クラスとjava.lang.Process
クラスの関連機能は、新しく作成されたプロセスと関連付けられたユーザーのアイデンティティを制御しません。Java VMのデフォルト動作を含むほとんどのJava実装では、分岐プロセスは親プロセスのアイデンティティ(Oracle DatabaseのOracle OSユーザー)を使用して実行されます。セキュリティ上の理由で、Runtime.exec
機能により分岐されたプロセスは、弱い権限を付与されたOSアイデンティティを使用して実行することをお薦めします。dbms_java.set_runtime_exec_credentials
プロシージャは、指定されたデータベース・ユーザー/スキーマを特定のOSアカウントにバインドするメカニズムを提供します。DBAは、できるかぎり小さい権限を持つOSアカウントにRuntime.exec
コールを発行して、データベース・ユーザーをバインドする必要があります。次のコールは、データベース・ユーザー/スキーマDBUSER
をOSのosuser
アカウントに関連付けます。
dbms_java.set_runtime_exec_credentials('DBUSER', 'osuser', 'ospass');
この結果、DBUSER
により発行されたRuntime.exec
コマンドを実行するために生成されるOSプロセスは、osuser
のアイデンティティを使用して実行されます。set_runtime_exec_credentials
プロシージャを使用するには、SYS
ユーザーである必要があります。