| Oracle Database Vault管理者ガイド 11gリリース1（11.1） E05797-05 |
|
 戻る |
 次へ |
この項の内容は次のとおりです。
職務分離とは、各ユーザーの権限をそのユーザーが担当するタスクのみに制限し、それ以外のタスクの権限は付与しないことを意味します。多くの権限を1人のユーザーに付与するのではなく、特定の権限カテゴリを特定のユーザーに割り当てます。簡単に言えば、組織で求められる各タスクのアカウンタビリティが職務分離によって構築されます。
職務分離は、過去10年間で非常に重要視されるようになりました。多くの企業にとって、職務分離は今後も展開を続ける新しい概念です。データベースの統合や法令遵守、そしてアウトソーシングは職務分離を推し進める要因の一部にすぎません。Oracle Database Vaultの職務分離では、セキュリティ関連の管理を日常的なDBA業務と分離することによって、セキュリティが強化されます。Database Vaultの職務分離は、現在および将来のビジネス要件に迅速に対処できるようにカスタマイズが可能です。特に小規模な企業では、限られたリソースでセキュリティ・プロファイルを向上させるために柔軟性が必要となります。
Oracle Database Vaultでは次の主な職責が定義されます。
アカウント管理。アカウント管理ではユーザー・アカウントの作成、変更および削除を行います。DV_ACCTMGRロールがこれらの権限を提供します。
セキュリティ管理。セキュリティ管理では基本的なセキュリティ・タスクを行います。たとえばレルムやコマンド・ルールの作成、データベース・ユーザーのアクセスに対するセキュリティ・ポリシーの設定、実行が許可されたジョブに対するデータベース・ユーザーの認可などがあります。セキュリティ管理者はセキュリティ監査レポートも実行します。DV_OWNERロールとDV_ADMINロールがこれらの権限を提供します。（Oracle Database Vaultロールによる職務分離の規定の詳細は、「Oracle Database Vaultロール」を参照してください。）
アカウント管理とセキュリティ管理の職責を任意に統合することもできます。
リソース管理。リソース管理はビジネス・データへのアクセスではなく、データベース・システムの管理を表します。次のような操作が含まれます。
バックアップ操作では、事前定義されたツールを使用してバックアップを実行するための事前定義時刻が必要です。
チューニングおよび監視操作では、継続中のパフォーマンス監視および分析が必要です。
パッチ適用操作では、パッチが適用されている時間内のみの一時アクセスが必要です。
リソース管理では、これらの各タスクについて名前付きアカウントとバックアップ・アカウントを作成する必要があります。これらのアカウントをデータ・ディクショナリ・レルムの所有者として追加します。これらのアカウントをデータベースのプライマリ・リソース・マネージャとして使用します。
データベース・アカウント管理とデータベース・セキュリティ管理それぞれのための個別アカウントと、バックアップ操作のためのその他の名前付きアカウントが必要です。監査者は各職責のための個別のデータベース・アカウントをチェックし、各アカウントのアクションを追跡することもできます。重要性が比較的低いのは、特定のタスクに割り当てられているユーザーの数です。Oracle Database Vault監査イベントは保護されており、Database Vaultレポートにはすべての違反未遂が表示されます。
職務分離を適切に行うためには、各環境における基本的な管理タスクを実行するユーザーと、その管理タスクの内容を理解する必要があります。新規のデータベース・アカウント・プロビジョニングとアプリケーション・パッチ適用の両方の管理を1名のデータベース管理者が担当する場合でも、これらの各タスクの文書化と計画は非常に重要です。各種のタスクに個別の管理アカウントを使用することで、アカウンタビリティが向上し、関連するリスクが抑制されます。中規模から大規模の企業では、データベース管理者は通常、一般的な管理タスクを実行しますが、アプリケーションで管理されるビジネス・データにアクセスする必要はありません。職務分離マトリクスを作成すると、Database Vaultのデプロイを計画する際に役立ちます。必要に応じて、追加的なタスクと関連付けられたユーザーをこのリストに含むことができます。この情報は、企業の全般的なエンタープライズ・セキュリティ・ドキュメントの一環となります。
表D-1は職務分離マトリクスの例を示しています。
表D-1 職務分離マトリクスの例
| ユーザー、プロセスまたはアプリケーション | アカウントの作成 | データベース管理 | セキュリティ管理者 | ||||
|---|---|---|---|---|---|---|---|
| SYSDBA | バックアップ | チューニング | パッチ適用 | 監視 | |||
... |
|||||||
|
|
X |
||||||
|
|
X |
||||||
|
|
X |
||||||
|
|
X |
||||||
|
|
X |
X |
|||||
|
|
EBSパッチ適用 |
||||||
|
|
X |
X |
|||||
一部のケースでは、システム管理タスクで、特定のツールおよびプログラムからデータへの一時アクセスが必要になります。これが発生した場合は、Oracle Database Vaultのルールおよびルール・セットに対するこの一時アクセスまたは緊急時アクセスのプロビジョニングを構築します。
各管理ユーザーの職責。
ユーザーが必要とするアクセスの種類。たとえば、アプリケーション所有者はデータ・アクセスを、開発者は開発インスタンスに対するアクセスのみを必要とします。
ビジネス・データにアクセスせずにシステムを管理するユーザー（例: バックアップ、パッチ適用、チューニングおよび監視の操作を実行するユーザー）。
各タスク・カテゴリの職務（例: バックアップ対象のファイル、パッチ適用が必要なアプリケーション、監視の正確な対象）。これらの各タスクに対する代替ユーザー・アカウントも含まれます。
保護が必要なデータベースとアプリケーション。この中にはOracleアプリケーション、パートナー・アプリケーションおよびカスタム・アプリケーションも含まれます。
ビジネス・データへのアクセスの認可が必要なユーザー。次のユーザーが含まれます。
中間層プロセスを利用するアプリケーション所有者
アプリケーション・インタフェースを利用するビジネス・ユーザー
セキュリティの侵害の対処方法など、緊急時のWhat-Ifシナリオ。
本番環境におけるレポート作成。次の内容が含まれます。
レポートの実行者
実行が必要なレポート
各レポートが実行される頻度
各レポートのコピーの受取りを必要とするユーザー
職務分離マトリクス以外に、次のマトリクスの作成があります。
Oracle Database Vault固有マトリクス。Database Vaultロールを付与されているユーザーの名前とタスクが含まれます。
アプリケーション保護マトリクス。保護対象のアプリケーションと設定した保護のタイプが含まれます。
表D-2はPeopleSoftアプリケーションについて作成された保護の例を示しています。これらのセキュリティ・ポリシーを作成するためのスクリプトは、次のURLからダウンロードできます。
http://www.oracle.com/technology/software/products/database_vault/index.html
この項の内容は次のとおりです。
一般的なデータベース管理の目的でSYSTEMアカウントを使用する場合は、データベース管理者のための名前付きデータベース管理アカウントを作成します。これによって、データベース内の管理アクションに対するアカウンタビリティが向上します。
SYSTEMスキーマ内にアプリケーション表がある場合は、これらのアプリケーションを引き続き正常に動作させるため、SYSTEMアカウントをこれらの表に対するレルム認可に追加します。これらのアプリケーションのセキュリティを向上または微調整するため、SYSTEMアカウントに制限を加えることもできます。たとえば、Database Vaultルール・セットを作成して、SYSTEMユーザーのアクセスを特定のIPアドレスに制限できます。
接続時にSYSDBA権限の使用が不可欠なユーザーや、SYSDBAアクセスを現在も必要とするアプリケーション（Oracle Recovery Manager（RMAN）や必須のパッチ適用プロセスなど）のみに、この権限を制限します。その他すべてのケースでは、日常的なデータベース管理を実行するための名前付きデータベース・アカウントを作成します。
Oracle Database Vaultでは、高度な権限を持つオペレーティング・システム・ユーザーはデータベース・ファイルに直接アクセスできます。この種の保護では透過的データ暗号化を使用することで、個々の表の列や表領域全体を非表示にできます。（『Oracle Database Advanced Security管理者ガイド』を参照してください。）慎重に確認して、オペレーティング・システムへの直接アクセスを制限してください。
オペレーティング・システムにアクセスするにはアカウントをパーソナライズしておくことが必要です。これらのパーソナライズされたアカウントはLinuxまたはUNIX環境で、必要な場合にはsudoを使用してoracleソフトウェア所有者にログインします。sudoでは、パーソナライズされた各ユーザーが実行できる特定のコマンドを制御できます。これらのユーザーについては、makeコマンドまたはrelinkコマンドの使用を必ず禁止してください。ただし、管理ユーザーがパッチをインストール、またはその他の緊急的な操作を実行する場合は、一定の時間だけmakeコマンドおよびrelinkコマンドを有効にできます。
Oracle Database Vaultは、データベース内の権限を与えられた多くのユーザーおよびロールからのアプリケーション・データへのアクセスを制限します。ただし、場合によっては、Oracle Database Vaultsは特定のロールおよび権限を信頼します。
表D-3に、信頼できるロールおよび権限を示します。これらのロールおよび権限は、Oracle Database Vaultのインストール時に作成されます。
表D-3 信頼できるOracle Database Vaultロールおよび権限
| ロールまたは権限 | ステータス | 説明 |
|---|---|---|
|
|
オープン |
インストール時に作成され、新規データベース・アカウントの作成に使用されるロール。 |
|
|
オープン |
インストール時に作成され、レルム、ファクタおよびコマンド・ルールの管理に使用されるロール。このユーザーは、自身をレルム認可に追加できません。また、 |
|
|
有効 |
Oracle Databaseのインストール時に作成される権限。一部のOracle機能に必要です。 |
|
|
有効 |
Oracle Databaseのインストール時に作成される権限。データベースの起動および停止。デフォルトでは |
いくつかのアカウントおよびロールは、デフォルトのOracle Databaseインストール環境で非常に強力な権限を持ちます。これらのアカウントおよびロールは、信頼できる人物に制限する必要があります。
ルート・ユーザー・アクセス権を持つユーザーは、次のアクティビティを含め、システムを完全に制御できます。
暗号化されていないファイルの読取り
ファイルの移動および削除
システムでのプログラムの起動または停止
Oracle Databaseインストール環境を所有するユーザーを含む任意のユーザーとしてのログイン
Oracle Database Vaultでは、オペレーティング・システム・ルート・アクセスに対して保護されません。ルート・ユーザー権限は、必ず適切な職責を持つ適切な人物にのみ付与してください。
システムにOracleソフトウェア所有者としてのアクセス権を持つユーザーは、次のアクティビティを含め、Oracleソフトウェアを制御できます。
特定のシステムでのOracle Database Vaultの無効化
暗号化されていないデータベース・ファイルの読取り
データベース・ファイルの移動および削除
システムでのOracleプログラムの起動または停止
Oracle Database Vaultでは、Oracleソフトウェア所有者のオペレーティング・システム・アクセスから保護されません。Oracleソフトウェア所有者アクセス権は、必ず適切な職責を持つ適切な人物にのみ付与してください。
Oracle Database Vaultでは、 SYSDBAアクセス権を持つユーザーから完全には保護されません。Oracle Databaseの一部のコンポーネントでは、SYSDBAアクセスが必要です。これらのコンポーネントは次のとおりです。
Oracle Data GuardおよびData Guard Brokerのコマンドライン・ユーティリティ
Oracle Recovery Managerのコマンドライン・ユーティリティ
Oracle Real Application Clusters
Oracle自動ストレージ管理のコマンドライン・ユーティリティ
インストールでSYSDBAアクセスが必要な場合は、この権限を必要とするユーザーを、UNIXシステムではOSDBAグループおよびWindowsシステムではORA_DBAグループに追加することをお薦めします。SYSDBAアクションは、デフォルトで監査されることを忘れないでください。OSDBAグループの詳細はOracle Databaseのインストレーション・ガイドを、ORA_DBAの詳細はOracle Databaseのプラットフォーム・ガイドを参照してください。
Oracle Database Vaultを本番環境で実行する際は次のガイドラインに従ってください。
アプリケーションの全テストを実行して、作成したDatabase Vaultポリシーが予測どおりに機能しているか確認します。
アプリケーションのパフォーマンスを監視し、必要に応じてルール式を調整します。
適切な製品サポートおよびセキュリティ・グループに職責を次のように割り当てます。
データベース・セキュリティ管理者にセキュリティ職責を割り当てます。
データベース・アカウント管理者にアカウント管理を割り当てます。
データベース管理者にリソース管理タスクを割り当てます。
Database Vault APIスクリプトをセキュア・サーバーにバックアップします。
次の構成およびセキュリティのガイドラインに従ってください。
UTL_FILEパッケージは、SYSによって所有され、PUBLICに付与されます。ただし、ユーザーがオペレーティング・システム・ディレクトリ内のファイルを操作するためには、そのディレクトリ・オブジェクトへのアクセス権が必要です。UTL_FILEパッケージはセキュアな状態で構成できます。詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
DBMS_FILE_TRANSFERパッケージは、SYSによって所有され、EXECUTE_CATALOG_ROLEに付与されます。このパッケージに対するEXECUTEアクセス権を持つユーザーは、同じファイル・システムの1つの場所から別の場所にファイルを移動できます。リモート・システム上のデータベースを含め、データベース・インスタンス間でファイルを移動することもできます。
DBMS_FILE_TRANSFERパッケージを保護するには、次の処理を行います。
DBMS_FILE_TRANSFERパッケージのEXECUTE権限を取り消し、この権限を必要とする信頼できるユーザーに対してのみEXECUTE権限を付与します。
コマンド・ルールを作成して、CREATE DATABASE LINKおよびCREATE DIRECTORY SQL文を制御します。Oracle Database Vault Administratorを使用したコマンド・ルールの作成の詳細は、「コマンド・ルールの作成および編集」を参照してください。
または、例D-1および例D-2に示すように、Oracle Database VaultのMACADMパッケージを使用して、リモート・データベースへの接続の確立に使用されるCREATE DATABASE LINK文へのアクセスを制限および有効化することもできます。このメソッドを使用するには、Oracle Database Vault所有者アカウントを使用してSQL*Plusにログインします。
例D-1 CREATE DATABASE LINKへのアクセスを拒否するコマンド・ルールの作成
BEGIN DBMS_MACADM.CREATE_COMMAND_RULE ( command => 'CREATE DATABASE LINK', rule_set_name => 'Disabled', object_owner => '%', object_name => '%', enabled => dbms_macutl.g_yes); END; / COMMIT;
ユーザーがこのコマンドを使用する必要がある場合、Oracle Database Vault所有者は、Oracle Database Vault Administratorから再び有効にするか、SQL*Plusで次のコマンドを発行できます。
例D-2 CREATE DATABASE LINKへのアクセスを有効にするコマンド・ルールの作成
BEGIN DBMS_MACADM.UPDATE_COMMAND_RULE ( command => 'CREATE DATABASE LINK', rule_set_name => 'Enabled', object_owner => '%', object_name => '%', enabled => dbms_macutl.g_yes); END; / COMMIT;
同様に、例D-3に、CREATE DIRECTORYへのアクセスを無効および有効にするコマンド・ルールを示します。
例D-3 CREATE DIRECTORYへのアクセスを無効および有効にするコマンド・ルール
-- Disable access to CREATE DIRECTORY BEGIN DBMS_MACADM.CREATE_COMMAND_RULE ( command => 'CREATE DIRECTORY', rule_set_name => 'Disabled', object_owner => '%', object_name => '%', enabled => dbms_macutl.g_yes); END; / COMMIT; -- Enable access to CREATE DIRECTORY BEGIN dbms_macadm.update_command_rule ( command => 'CREATE DIRECTORY', rule_set_name => 'Enabled', object_owner => '%', object_name => '%', enabled => dbms_macutl.g_yes); END; / COMMIT;
このリリースのOracle Database Vaultでは、リサイクルビン機能が有効化されています。ALTER SYSTEMコマンド・ルールはこの機能の有効化または無効化を阻止します。リサイクルビンを無効にするには、SQL*Plusにログインし、ALTER SYSTEMコマンド・ルールを無効にしてからリサイクルビンを無効にします。
リサイクルビン機能が有効な場合、レルムで保護されたオブジェクトが削除されると、リサイクルビンに移動します。リサイクルビンに移動すると、そのオブジェクトはレルムで保護されなくなります。SQL*Plusでは、リサイクルビンの内容は次のようにチェックできます。
SELECT * FROM RECYCLEBIN; SELECT * FROM USER_RECYCLEBIN;
リサイクルビンの内容をパージするには、PURGE SQL文を使用します。
PURGE RECYCLEBIN; PURGE USER_RECYCLEBIN;
ALTER SYSTEMコマンド・ルールを無効にしてリサイクルビンも無効にするには、次のようにします。
DVOWNERアカウントとして、ALTER SYSTEMコマンド・ルールを無効にします。
BEGIN DVSYS.DBMS_MACADM.UPDATE_COMMAND_RULE( command => 'ALTER SYSTEM', rule_set_name => 'Allow System Parameters', object_owner => '%', object_name => '%', enabled => 'N'); END; /
SYSDBA権限を使用してSYSとして接続し、RECYCLE BINを無効にします。
CONNECT SYS/AS SYSDBA
Enter password: password
Connected
ALTER SYSTEM SET RECYCLEBIN=OFF SCOPE=SPFILE;
DVOWNERとして接続して、ALTER SYSTEMコマンド・ルールを再び有効にします。
BEGIN DVSYS.DBMS_MACADM.UPDATE_COMMAND_RULE( command => 'ALTER SYSTEM', rule_set_name => 'Allow System Parameters', object_owner => '%', object_name => '%', enabled => 'Y'); END; /
このリリースのOracle Database Vaultでは、CREATE JOB権限は、DBAおよびSCHEDULER_ADMINロールから取り消されています。使用しているアプリケーションにこの変更による影響がないことを確認してください。
CREATE EXTERNAL JOB権限は、Oracle Database 10gリリース2（10.2）で導入されました。この権限は、データベースの外部のオペレーティング・システムで稼働するジョブを実行するデータベース・ユーザーに必要です。デフォルトでは、この権限は、CREATE JOB権限を付与されたすべてのユーザーに付与されます。セキュリティを高めるために、この権限を必要としないユーザーからこの権限を取り消し、必要とするユーザーにのみ付与してください。
このリリースのOracle Database Vaultでは、ロールEXECUTE_CATALOG_ROLEには、次のLogMinerパッケージに対するEXECUTE権限がデフォルトでは付与されません。
DBMS_LOGMNR
DBMS_LOGMNR_D
DBMS_LOGMNR_LOGREP_DICT
DBMS_LOGMNR_SESSION
使用しているアプリケーションにこの変更による影響がないことを確認してください。
トレースおよびデバッグ・コマンドは、Oracleデータベース・メモリー情報を表示する可能性があることに注意してください。Oracle Database Vaultは、これらのコマンドに対する保護を行いません。Oracleデータベース・メモリー情報を保護するために、ALTER SYSTEM権限およびALTER SESSION権限へのアクセスを厳密に制御することをお薦めします。これらの権限は、SYSDBAとして接続しているときにユーザーSYSによって、またDBAロールを付与されている任意のユーザーによって付与できます。
また、ALTER SYSTEM文の既存のコマンド・ルールにツールを追加することをお薦めします。Oracle Database Vault Administratorを使用してルールを作成し、そのルールをルール・セットに追加できます。
例D-4は、このようなルールの作成方法を示しています。このルールにより、ALTER SYSTEM権限を持つユーザーは、コマンドALTER SYSTEM DUMPを発行できなくなります。このコマンド・ルールを作成する場合は、Oracle Database Vault所有者としてSQL*Plusにログインします。
例D-4 既存のALTER SYSTEMコマンド・ルールへのルールの追加
CONNECT dbvacctmgr
Enter password: password
BEGIN
DBMS_MACADM.CREATE_RULE('NO_SYSTEM_DUMP',
'(INSTR(UPPER(DVSYS.DV_SQL_TEXT),''DUMP'') = 0)');
END;
/
EXEC DBMS_MACADM.ADD_RULE_TO_RULE_SET
('Allow System Parameters','NO_SYSTEM_DUMP');
EXEC DVSYS.DBMS_MACADM.UPDATE_COMMAND_RULE
('ALTER SYSTEM', 'Allow System Parameters', '%', '%', 'Y');
COMMIT;
または、Oracle Database Vault Administratorを使用してルールを作成し、そのルールをルール・セットに追加できます。詳細は、「ルール・セットに追加するルールの作成」を参照してください。
定義者権限のストアド・プロシージャは、ストアド・プロシージャの所有者の権限に依存して、ストアド・プロシージャ内で参照されているオブジェクトにアクセスします。起動者権限でのストアド・プロシージャは、ストアド・プロシージャの実行者の権限に依存して、ストアド・プロシージャ内で参照されているオブジェクトにアクセスします。Javaストアド・プロシージャのデフォルトは、起動者権限です。
Oracle Database Vaultセキュリティは、Oracle Database内で行われたコールを傍受することで動作します。
定義者権限でのJavaストアド・プロシージャでは、ストアド・プロシージャの実行はブロックされず、レルム保護は実施されません。ただし、Javaストアド・プロシージャによってアクセスされる基礎となるオブジェクトは、Oracle Database Vaultコマンド・ルールで保護できます。
起動者権限でのJavaストアド・プロシージャでは、ストアド・プロシージャの実行はブロックされません。ただし、Javaストアド・プロシージャによってアクセスされる基礎となるオブジェクトは、Oracle Database Vaultレルムとコマンド・ルールの両方により保護されます。
デフォルトでは、EXECUTE ANY PROCEDURE権限は、DBA、EXPORT_FULL_DATABASEおよびIMPORT_FULL_DATABASEロールに付与されます。Javaストアド・プロシージャを必要としないユーザーおよびロールからEXECUTE ANY PROCEDUREを取り消した上で、選択的に読取り権限を割り当てることにより、Javaストアド・プロシージャへのアクセスを制限できます。また、ユーザーからEXECUTE ANY PROCEDUREを取り消すと、SYSが所有するパッケージへのアクセスを制限することでデータベースの保護を高めることができます。
Oracle Database Vaultを使用する場合は、Javaストアド・プロシージャを分析してセキュリティを最大化することをお薦めします。この処理は、次の手順に従って行うことができます。
例D-5の問合せを実行することにより、定義者権限で作成されたJavaストアド・プロシージャを識別します。この問合せは、データベースに接続するJavaストアド・プロシージャのみ返し、結果をファイルjava_dr.lstにスプールします。
例D-5 定義者権限でのJavaストアド・プロシージャを識別するための問合せ
COLUMN plsql_owner FORMAT a8
COLUMN plsql FORMAT a30
COLUMN java_owner FORMAT a8
COLUMN java FORMAT a30
SPOOL java_dr
select distinct plu.name plsql_owner, plo.name plsql,
ju.name java_owner, jo.name java
from obj$ plo, user$ plu, user$ ju, obj$ jo, procedurejava$ j
where jo.name=j.classname and ju.user#=jo.owner# and ju.name=j.ownername
and jo.type#=29 and bitand(jo.flags, 8)=0
and plo.owner#=plu.user#
and j.obj#=plo.obj# and bitand(plo.flags, 8)=0
and ju.name not in ('SYS', 'ORDSYS')
and jo.obj# in
(select d_obj# from dependency$ connect by d_obj#=prior p_obj#
start with p_obj#=(select obj# from obj$ where name='java/sql/Connection'
and owner#=0));
SPOOL off
手順1で問い合せたJavaストアド・プロシージャを分析し、それらのいずれかがレルムで保護されたオブジェクトにアクセスするかどうかを判断します。「DBA_DV_REALM_OBJECTビュー」で説明されているDBA_DV_REALM_OBJECTビューを使用して、現行のデータベース・インスタンスでレルム・セキュア・オブジェクトのリストを検索できます。
レルムで保護されたオブジェクトにアクセスするJavaストアド・プロシージャに対して、Javaストアド・プロシージャをラップするPL/SQLパッケージを作成します。PL/SQLの最適化により、PL/SQLパッケージ・ラッパーは、パッケージ・ヘッダーに定義されているダミー変数を必要とします。ダミー変数を追加すると、Oracle Database Vaultは、Javaストアド・プロシージャの実行を傍受およびブロックできます。このメソッドはJavaストアド・プロシージャの実行を保護しますが、埋め込まれている他のJavaストアド・プロシージャへのコールに対する保護は提供しないことに注意してください。
例D-6に、Javaクラスemp_countをラップするために作成されるPL/SQLパッケージmypackageを示します。
例D-6 PL/SQLラッパーの作成
CREATE OR REPLACE PACKAGE SCOTT.MYPACKAGE AS tmp varchar2(200) := 'TEST'; -- dummy variable FUNCTION empcount RETURN VARCHAR2; END; / CREATE OR REPLACE PACKAGE BODY SCOTT.MYPACKAGE AS FUNCTION empcount RETURN VARCHAR2 AS LANGUAGE JAVA NAME 'emp_count.count() return java.lang.String'; END; /
次に、起動者権限で作成されたJavaストアド・プロシージャを識別する準備ができます。これは、例D-7の問合せを実行することで行います。この問合せは、データベースに接続するJavaストアド・プロシージャのみ返し、結果をファイルjava_dr.lstにスプールします。
例D-7 起動者権限を持つJavaストアド・プロシージャの識別
COLUMN plsql_owner FORMAT a8
COLUMN plsql FORMAT a30
COLUMN java_owner FORMAT a8
COLUMN java FORMAT a30
spool java_ir
select distinct plu.name plsql_owner, plo.name plsql,
ju.name java_owner, jo.name java
from obj$ plo, user$ plu, user$ ju, obj$ jo, procedurejava$ j
where jo.name=j.classname and ju.user#=jo.owner# and ju.name=j.ownername
and jo.type#=29 and bitand(jo.flags, 8)=8
and plo.owner#=plu.user#
and j.obj#=plo.obj# and bitand(plo.flags, 8)=0
and ju.name not in ('SYS', 'ORDSYS')
and jo.obj# in
(select d_obj# from dependency$ connect by d_obj#=prior p_obj#
start with p_obj#=(select obj# from obj$ where name='java/sql/Connection'
and owner#=0));
spool off
Oracle Database Vaultレルムおよびコマンド・ルールは、起動者権限のストアド・プロシージャに対して実施されます。ただし、Javaストアド・プロシージャの実行をブロックするのにも役立ちます。この処理は、「手順3: レルムで保護されたオブジェクトにアクセスするプロシージャをラップするパッケージの作成」に従って実行できます。
Oracle Database VaultがJavaストアド・プロシージャを保護していることを検証します。例D-8に、Oracle Database Vaultセキュリティのテスト方法を示します。SQL*Plusなどのツールにログインします。次に、レルムで保護されたオブジェクト・ディレクトリへのアクセスを試行し、Javaストアド・プロシージャを実行してレルムで保護されたオブジェクトにアクセスします。
例D-8 Oracle Database VaultによるJavaストアド・プロシージャの保護のテスト
SQL> CONNECT u1
Enter password: password
SQL> SELECT * FROM SESSION_PRIVS;
PRIVILEGE
----------------------------------------
CREATE SESSION
SELECT ANY TABLE
CREATE PROCEDURE
EXECUTE ANY PROCEDURE
Protecting access on direct SQL access
SQL> SELECT COUNT(*) FROM SCOTT.EMP;
ERROR at line 1:
ORA-01031: insufficient privileges
--Now show protecting access through Java
SQL> SELECT SCOTT.MYPACKAGE.EMPCOUNT FROM DUAL;
ERROR at line 1:
ORA-01031: insufficient privileges
ORA-06512: at "SCOTT.MYPACKAGE", line 2
新しいJavaストアド・プロシージャを作成する場合は、Javaクラスが起動者権限で実行し、それらをPL/SQLパッケージ仕様で定義するようにします。パッケージ・ヘッダーにダミーのPL/SQL変数を含めることが重要です。ダミー変数を追加すると、Oracle Database Vaultは、Javaストアド・プロシージャの実行を傍受およびブロックできます。
定義者権限での外部Cコールアウトでは、コールアウトの実行はブロックされず、レルム保護は実施されません。ただし、外部Cコールアウトによってアクセスされる基礎となるオブジェクトは、Oracle Database Vaultコマンド・ルールにより保護されます。外部Cコールアウトのデフォルトは、起動者権限です。
起動者権限での外部Cコールアウトでは、外部Cコールアウトの実行はブロックされません。ただし、外部Cコールアウトによってアクセスされる基礎となるオブジェクトは、Oracle Database Vaultレルムとコマンド・ルールの両方により保護されます。
Oracle Database Vaultセキュリティは、Oracle Database内で行われたコールを傍受することで動作します。
デフォルトでは、EXECUTE ANY PROCEDURE権限は、DBA、EXPORT_FULL_DATABASEおよびIMPORT_FULL_DATABASEロールに付与されます。外部Cコールアウトを必要としないユーザーおよびロールからEXECUTE ANY PROCEDUREを取り消すことにより、外部Cコールアウトへのアクセスを制限できます。また、ユーザーからEXECUTE ANY PROCEDUREを取り消すと、SYSが所有するパッケージへのアクセスを制限することでデータベースの保護を高めることができます。
Oracle Database Vaultを使用する場合は、外部Cコールアウトを分析してセキュリティを最大化することをお薦めします。この処理は、次の手順に従って行うことができます。
例D-9の問合せを実行することにより、定義者権限で作成された外部Cコールアウトを識別します。この問合せは、結果をファイルexternal_wrap.lstにスプールします。
例D-9 PL/SQLパッケージによりラップされる外部Cコールアウトの識別
spool external_wrap
select u.name OWNER, o.name object, o.type#, o.flags from
sys.obj$ o, sys.user$ u
where o.owner# = u.user# and
u.name not in ('MDSYS', 'ORDSYS', 'SYS') and o.obj# in (
select d_obj# from dependency$ connect by d_obj#=prior p_obj#
start with p_obj# in (select obj# from library$ where property = 0))
order by owner, object;
spool off
外部Cコールアウトを分析し、それらのいずれかがレルムで保護されたオブジェクトにアクセスするかどうかを判断します。「DBA_DV_REALM_OBJECTビュー」で説明されているDBA_DV_REALM_OBJECTビューを使用して、現行のデータベース・インスタンスでレルム・セキュア・オブジェクトのリストを検索できます。
レルムで保護されたオブジェクトにアクセスする外部Cコールアウトに対して、外部CコールアウトをラップするPL/SQLパッケージを作成します。PL/SQLの最適化により、PL/SQLパッケージ・ラッパーは、パッケージ・ヘッダーに定義されているダミー変数を必要とします。ダミー変数を追加すると、Oracle Database Vaultは、外部Cコールアウトの実行を傍受およびブロックできます。このメソッドは外部Cコールアウトの実行を保護しますが、埋め込まれている他の外部Cコールアウトへのコールに対する保護は提供しないことに注意してください。
例D-10 PL/SQLラッパーの作成
create or replace package scott.mytestpkg1 as
tmp integer; /* create a dummy plsql variable */
function test return binary_integer;
end;
/
create or replace package body scott.mytestpkg1 as
function test return binary_integer as language C library
c_utils name "test" with context parameters(context,
return indicator short,
return int);
end;
/
例D-11の問合せを実行することにより、起動者権限で作成された外部Cコールアウトを識別します。この問合せは、結果をファイルexternal_standalone.lstにスプールします。
例D-11 PL/SQLパッケージによりラップされる外部Cコールアウトの識別
spool external_standalone
select u.name OWNER, o.name object, o.type#, o.flags from
sys.obj$ o, sys.user$ u
where o.owner# = u.user# and
u.name not in ('MDSYS', 'ORDSYS', 'SYS') and
o.type# in (7,8) and o.obj# in (
select d_obj# from dependency$ connect by d_obj#=prior p_obj#
start with p_obj# in (select obj# from library$ where property = 0))
order by owner, object;
spool off
Oracle Database Vaultレルムおよびコマンド・ルールは、外部Cコールアウトに対して実施されます。ただし、外部Cコールアウトの実行をブロックするのにも役立ちます。この処理は、「手順3: レルムで保護されたオブジェクトにアクセスするCコールアウトをラップするパッケージの作成」に従って実行できます。
Oracle Database Vaultによる外部Cコールアウトの保護を検証します。例D-12に、SQL*Plusなどのツールにログインし、外部Cコールアウトの実行を試行することで、Oracle Database Vaultセキュリティをテストする方法を示します。
例D-12 外部CコールアウトのOracle Databaseセキュリティのテスト
SQL> CONNECT u1
Enter password: password
SQL> SELECT * FROM SESSION_PRIVS;
PRIVILEGE
----------------------------------------
CREATE SESSION
SELECT ANY TABLE
CREATE PROCEDURE
EXECUTE ANY PROCEDURE
SQL> SELECT COUNT(*) FROM SCOTT.EMP;
ERROR at line 1:
ORA-01031: insufficient privileges
SQL> SELECT TEST FROM DUAL;
TEST
-------------------------------------------------------------------------------
14
SQL> SELECT SCOTT.MYPACKAGE1.TEST FROM DUAL;
ERROR at line 1:
ORA-01031: insufficient privileges
ORA-06512: at "SCOTT.MYPACKAGE1", line 2
