すべてのOracle Database製品と同様に、Oracle Database Vaultインストールを適切に保護するためにセキュリティ・ガイドラインに従う必要があります。
内容は次のとおりです。
Oracle Database Vaultは、職務分離のガイドラインを容易に実現できるように設計されています。
内容は次のとおりです。
職務分離とは、各ユーザーの権限をそのユーザーが担当するタスクのみに制限し、それ以外のタスクの権限は付与しないことです。
多くの権限を1人のユーザーに付与するのではなく、特定の権限カテゴリを特定のユーザーに割り当てます。簡単に言えば、組織で求められる各タスクのアカウンタビリティが職務分離によって構築されます。
職務分離は、過去10年で非常に重要視されるようになりました。多くの組織にとって、職務分離は今後も展開し続ける新しい概念です。データベースの統合、法令順守およびアウトソーシングは、職務分離を推し進める要因の一部にすぎません。Oracle Database Vaultの職務分離では、セキュリティ関連の管理を日常的なDBA操作と分離することによって、セキュリティが強化されます。Database Vaultの職務分離は、現在および将来のビジネス要件に容易に対処できるようにカスタマイズが可能です。特に小規模組織では、限られたリソースでセキュリティ・プロファイルを向上させるために、柔軟性が必要となります。
Oracle Database Vaultでは、いくつかの主な職責が定義されます。
これらの職責は次のとおりです。
アカウント管理。アカウント管理では、ユーザー・アカウントの作成、変更、および削除を行います。DV_ACCTMGR
ロールがこれらの権限を提供します。日常使用するプライマリDV_ACCTMGR
ユーザーと、バックアップDV_ACCTMGR
ユーザーは、Oracle Database Vaultの登録プロセス時に作成されます。安全対策として、プライマリDV_ACCTMGR
アカウント所有者が自分のパスワードを忘れた場合や企業を退職した場合に備えて、バックアップ・アカウントを保持し続けます。
セキュリティ管理。セキュリティ管理では、基本的なセキュリティ・タスクを行います。たとえば、レルムやコマンド・ルールの作成、データベース・ユーザーのアクセスに対するセキュリティ・ポリシーの設定、実行が許可されたジョブに対するデータベース・ユーザーの認可などがあります。セキュリティ管理者は、セキュリティ監査レポートの実行も行います。DV_OWNER
およびDV_ADMIN
ロールにこれらの権限が含まれています。日常使用するプライマリDV_OWNER
ユーザーと、バックアップDV_OWNER
ユーザーは、Oracle Database Vaultの登録プロセス時に作成されます。安全対策として、プライマリDV_OWNER
アカウント所有者が自分のパスワードを忘れた場合や企業を退職した場合に備えて、バックアップ・ユーザー・アカウントを保持し続ける必要があります。
オプションで、アカウント管理とセキュリティ管理の職責を統合することもできます。
データベース管理。データベース管理とは、データベース・システムの管理のことで、ビジネス・データへのアクセスのことではありません。次のような操作があります。
バックアップ操作では、事前定義されたツールを使用してバックアップを実行するための事前定義時刻が必要です。
チューニングおよび監視操作では、継続したパフォーマンス監視および分析が必要です。
パッチ適用操作では、パッチが適用されている間のみの一時アクセスが必要です。
職務分離との関連においてデータベース管理アカウントを確認することをお薦めします。様々なデータベース管理者が、様々な権限およびロールを必要とする様々な職務を担当できます。同様に、経験豊かなデータベース管理者ほど、より多くのロールおよび権限がある可能性があります。ユーザーにデフォルトのDBA
ロールを付与するかわりに、組織での特定の地位および勤続年数にあわせてデータベース管理ロールを調整することを検討してください。名前付きアカウントのみを日常的な活動のために使用することが重要です。SYS
などのアカウント、およびSYSDBA
管理権限を使用するアカウントは、特権アカウント管理(PAM)システムで管理され、使用時にチェック(および監査)される必要があります。バックアップOracle Database Vault所有者およびアカウント管理アカウントをPAMシステムで管理する必要もあります。オペレーティング・システム内では、root
およびoracle
アカウントは、強力な権限があるため、チェックアウト・システムによってのみ使用できるようにする必要があります。
データベース・アカウント管理とデータベース・セキュリティ管理のための個別アカウントと、バックアップ操作のためのその他の名前付きアカウントが必要です。監査者は、各職責のための個別のデータベース・アカウントをチェックし、各アカウントのアクションを追跡できます。特定タスクに割り当てられているユーザーの数は、あまり重要ではありません。Oracle Database Vault監査イベントは保護されており、Database Vaultレポートにはすべての違反未遂が表示されます。
関連項目:
Oracle Database Vaultロールがどのように職務分離を提供するかの詳細は、Oracle Database Vaultロールを参照してください
デフォルトのOracle Database Vaultアカウントをすべて示すリストは、登録中に作成されるOracle Database Vaultアカウントを参照してください
バックアップ・アカウントの重要性の詳細は、バックアップOracle Database Vaultアカウントを参照してください
職務分離を適用するには、環境で基本的な管理タスクを実行するユーザーと、その管理タスクの内容を、事前に理解しておく必要があります。
1人のデータベース管理者が新しいデータベース・アカウントのプロビジョニングとアプリケーションのパッチ適用の両方の管理を担当する場合でも、これらの各タスクについて文書化および計画することが重要となります。これらのタイプのタスクに別々の管理アカウントを使用すると、アカウンタビリティが向上し、悪質なユーザーによって単一のアカウントが侵害された場合に関連するリスクが軽減されます。中規模から大規模の組織では、データベース管理者は通常、一般的な管理タスクを実行する必要はありますが、アプリケーションで管理されるビジネス・データにアクセスする必要はありません。職務分離マトリクスを作成すると、Database Vaultデプロイメントを計画する際に役立ちます。必要に応じて、追加タスクおよび関連するユーザーをリストに含めることができます。この情報は、組織の全体的なエンタープライズ・セキュリティ・ドキュメントの一部となります。
表D-1は、職務分離マトリクスの例を示しています。
表D-1 職務分離マトリクスの例
ユーザー、プロセスまたはアプリケーション | アカウントの作成 | データベース管理 | セキュリティ管理 | ||||
---|---|---|---|---|---|---|---|
SYSDBA | バックアップ | チューニング | パッチ適用 | 監視 | |||
|
あり |
なし |
なし |
なし |
なし |
なし |
なし |
|
なし |
なし |
なし |
なし |
なし |
なし |
あり |
|
なし |
なし |
あり |
なし |
なし |
なし |
なし |
|
なし |
なし |
なし |
なし |
あり |
なし |
なし |
|
なし |
なし |
なし |
あり |
なし |
あり |
なし |
|
なし |
なし |
なし |
なし |
可(EBSのパッチ適用の場合) |
なし |
なし |
|
なし |
あり |
あり |
なし |
なし |
なし |
なし |
システム管理タスクで、特定のツールおよびプログラムからデータへの一時的なアクセスが必要なこともあります。この場合、Oracle Database Vaultルールおよびルール・セットに、この一時アクセスまたは緊急アクセスに対するプロビジョニングを構築します。
組織で必要となる次のタスク範囲を文書化する必要があります。
これらの範囲は次のとおりです。
各管理ユーザーの職責。
ユーザーが必要とするアクセス権の種類。たとえば、アプリケーション所有者はデータ・アクセス、開発者は開発インスタンスに対するアクセスのみを必要とします。
ビジネス・データにアクセスせずにシステムを管理する必要のあるユーザー(バックアップ、パッチ適用、チューニングおよび監視操作を実行するユーザーなど)。
各タスク・カテゴリの職務(バックアップの必要なファイル、パッチ適用の必要なアプリケーション、監視の正確な対象など)。これらの各タスクの代替ユーザー・アカウントも含まれます。
保護が必要なデータベースとアプリケーション。これには、Oracle Applications、パートナ・アプリケーションおよびカスタム・アプリケーションが含まれます。
ビジネス・データベースへのアクセスを認可する必要のあるユーザー。次のユーザーが含まれます。
中間層プロセスを利用するアプリケーション所有者
アプリケーション・インタフェースを利用するビジネス・ユーザー
セキュリティ侵害の対処方法など、緊急時のWhat-Ifシナリオ。
本番環境でのレポート作成。次の内容が含まれます。
レポートの実行者
実行が必要なレポート
各レポートの実行頻度
各レポートのコピーの受取りを必要とするユーザー
職務分離マトリクス以外に、次のマトリクスの作成があります。
Oracle Database Vault固有マトリクス。Database Vaultロールを付与されているユーザーの名前およびタスクを含めることができます。
アプリケーション保護マトリクス。保護対象アプリケーションおよび設定した保護タイプを含めることができます。
表D-2は、OracleがPeopleSoftアプリケーション向けに作成した保護の例を示しています。SYSADM
、PSFTDBA
、SYSTEM
およびDBA
はすべて、適切なルール・セットに対して認可されています。
表D-2 アプリケーション保護マトリクスの例
保護タイプ | SYSADM | PSFTDBA | SYSTEM | DBA |
---|---|---|---|---|
PeopleSoftレルム |
所有者 |
所有者 |
アクセス不可 |
アクセス不可 |
SELECTコマンド・ルール |
制限なし |
制限PSFTDBルール・セット |
アクセス不可 |
アクセス不可 |
CONNECTコマンド・ルール |
PeopleSoftAccessルール・セット |
制限なし |
制限なし |
制限なし |
DROP TABLESPACEコマンド・ルール |
無効なルール・セット |
無効なルール・セット |
無効なルール・セット |
無効なルール・セット |
Oracleでは、SYSTEM
などの管理者アカウントのセキュリティ管理用、あるいはSYSDBA
管理者権限を有するユーザー用のガイドラインを提供しています。
内容は次のとおりです。
理想的には、SYSTEM
アカウントは、使用中にチェックアウトおよび監査されるバックアップとしてのみ使用可能になる必要があります。
共有アカウントではなく、名前付きアカウントのみが、通常のデータベース管理タスクのために使用される必要があります。これにより、データベース内の管理アクションに対するアカウンタビリティが向上します。
SYSTEM
スキーマ内にアプリケーション表がある場合は、これらの表に関してレルム権限にSYSTEM
アカウントを追加する必要があります。
これにより、これらのアプリケーションが引き続き正常に機能できるようになります。
これらのアプリケーションのセキュリティを向上または微調整するため、SYSTEM
アカウントに制限を加えることもできます。たとえば、SYSTEM
ユーザーのアクセスを特定のIPアドレスに制限するDatabase Vaultルール・セットを作成できます。
SYSDBA
管理権限を使用するのは、この権限を使って接続することがどうしても必要なユーザーや、アプリケーションがSYSDBA
アクセスを必要とする場合だけに限定してください。
たとえば、必須パッチ適用プロセスにはSYSDBA
アクセスが必要です。
他のすべてのケースでは、日常的なデータベース管理を実行するための名前付きデータベース・アカウントを作成します。また、OSDBA
ユーザー・グループのメンバーにはSYSDBA
管理権限が付与されます。オペレーティング・システムのroot
およびoracle
アカウントの他に、データベースSYS
アカウント、およびSYSDBA
権限があるアカウントは、特権アカウント管理(PAM)システムで管理され、要求時のみチェックアウトされる必要があります。
関連項目:
SYSDBAアクセスの管理セキュリティ向上のために、ルートおよびオペレーティング・システムの次へのアクセスを注意深く監視する必要があります: Oracle Database Vault。
Oracle Database Vaultは、多くの権限を持つデータベース・ユーザーが機密データにアクセスすることを防ぎます。また、Oracle Database自体を使用している場合は、「透過的データ暗号化」を使用することで、最大の権限を持つオペレーティング・システム・ユーザーが機密データにアクセスできないようにできます。透過的データ暗号化では、表領域および表の列を暗号化できます。これにより、オペレーティング・システム・ユーザーが、オペレーティング・システムのデータベース・ファイルを参照することや、機密データを見つけることができなくなります。(透過的データ暗号化の詳細は、『Oracle Database Advanced Securityガイド』を参照してください。)オペレーティング・システムへの直接アクセスを常に注意深く確認し、制限することをお薦めします。
オペレーティング・システムにアクセスするには、アカウントをパーソナライズしておく必要があります。これらのパーソナライズされたアカウントは、LinuxまたはUNIX環境で、必要に応じてsudo
を使用してoracle
ソフトウェア所有者にログインします。sudo
では、パーソナライズされた各ユーザーが実行できる特定のコマンドを制御できます。これらのユーザーについては、make
、relink
、gdb
、またはデータベースで問題が発生する可能性があるその他のコマンドの使用を禁止してください。ただし、管理ユーザーがパッチをインストール、またはその他の緊急操作を実行する必要がある場合は、一定の時間のみmake
およびrelink
コマンドを有効にし、この時間中のアクションを監査できます。
Oracle Database Vaultは、データベース内の権限を与えられた多くのユーザーおよびロールからのアプリケーション・データへのアクセスを制限します。
ただし、場合によっては、Oracle Database Vaultsは特定のロールおよび権限を信頼します。
表D-3に、信頼できるロールおよび権限を示します。これらのロールおよび権限は、Oracle Database Vaultのインストール時に作成されます。
表D-3 信頼できるOracle Database Vaultロールおよび権限
ロールまたは権限 | ステータス | 説明 |
---|---|---|
|
オープン |
登録時に作成され、新規データベース・アカウントの作成に使用されるロール。安全対策として、
|
|
オープン |
登録時に作成され、レルム、ファクタおよびコマンド・ルールの管理に使用されるロール。このユーザーは、自分自身をレルム認可に追加できます。安全対策として、
|
|
有効 |
Oracle Databaseのインストール時に作成される権限。一部のOracle機能に必要です。 |
|
有効 |
Oracle Databaseのインストール時に作成される権限。データベースの起動および停止。デフォルトでは |
関連項目:
DV_OWNER
およびDV_ACCTMGR
のバックアップ・アカウントの重要性の詳細は、「バックアップOracle Database Vaultアカウント」を参照してください
SYSDBA
の管理のガイドラインは、「SYSDBAアクセスの管理」を参照してください
SYSOPER
の管理のガイドラインは、「SYSOPERアクセスの管理」を参照してください
強力な権限を伴うアカウントやロールは、信頼できる人物だけに制限する必要があります。
内容は次のとおりです。
ルート・ユーザー・アクセス権を持つユーザーは、システムを完全に制御できます。
これらのユーザーが実行できるアクティビティには、次のものがあります。
暗号化されていないファイルの読取り
ファイルの移動および削除
システムでのプログラムの起動または停止
Oracle Databaseインストール環境を所有するユーザーを含む任意のユーザーとしてのログイン
Oracle Database Vaultでは、オペレーティング・システム・ルート・アクセスに対して保護されません。root
およびoracle
アカウントを特権アカウント管理(PAM)システムで管理します。これらのアカウントは、特定のタスクに必要な場合のみチェックアウトします。強い権限があるオペレーティング・システム・アカウントが使用されている場合は、キーストローク取得およびビデオ取得まで、監査レベルを高くします。
システムにOracleソフトウェア所有者としてのアクセス権を持つユーザーは、Oracleソフトウェアを制御できます。
これらのユーザーが実行できるアクティビティには、次のものがあります。
暗号化されていないデータベース・ファイルの読取り
データベース・ファイルの移動および削除
システムでのOracleプログラムの起動または停止
Oracle Database Vaultでは、Oracleソフトウェア所有者のオペレーティング・システム・アクセスから保護されません。Oracleソフトウェア所有者アカウントを特権アカウント管理(PAM)システムで管理します。このアカウントは、特定のタスクに必要な場合のみチェックアウトします。強い権限があるオペレーティング・システム・アカウントが使用されている場合は、キーストローク取得およびビデオ取得まで、監査レベルを高くします。
通常のデータベース・メンテナンス・タスクではSYS
アカウントおよびSYSDBA
権限を使用しないようにする必要があります。
かわりに、必要なシステム権限、またはSYSBACKUP
、SYSDG
、SYSKM
などの特定の管理権限がある名前付きアカウントを使用します。ただし、パッチの実行、データベースのアップグレードまたは問題のトラブルシューティング(たとえば、停止したデータベースへの接続)のためにSYSDBA
権限が必要な場合があります。
SYSDBA
権限のあるユーザーは、直接的または間接的(たとえば、診断、データベース・アップグレードおよびパッチ適用による)に機密アプリケーション・データにアクセスできるため、SYSDBA
権限およびアカウントの使用は厳密に制限する必要があります。強力な権限のあるアカウントのリストには、SYS
、およびデータベース内のSYSDBA
権限のあるユーザー・アカウント、およびオペレーティング・システム内のrootおよびoracleアカウントが含まれます。データベースおよびオペレーティング・システム内の強力な権限のあるアカウントへのアクセスは、例外ベースである必要があり、ユーザーが、これらのアカウントおよび権限へのアクセスをロック解除するプロセスを経る必要があります。これらのアカウントを特権アカウント管理(PAM)システムで管理することをお薦めします。これらのアカウントは、特定のタスクに必要な場合のみチェックアウトします。強い権限があるオペレーティング・システム・アカウント(root
およびoracle
)およびデータベース・アカウント(SYS
アカウントおよびSYSDBA
管理権限)が使用されている場合は、キーストローク取得およびビデオ取得まで、監査レベルを高くします。これらの強い権限のあるアカウントがデータベースにアクセスするときには、SYS
アカウントを監査してそれらのアクティビティを監視します。
Oracle Database Vaultを本番環境で実行する際は、特定のガイドラインに従う必要があります。
これらのガイドラインは、次のとおりです。
アプリケーションの全テストを実行して、作成したDatabase Vaultポリシーが予測どおりに機能していることを確認します。
アプリケーションのパフォーマンスを監視し、必要に応じてルール式を調整します。
適切な製品サポートおよびセキュリティ・グループに職責を次のように割り当てます。
データベース・セキュリティ管理者にセキュリティ職責を割り当てます。
データベース・アカウント・マネージャにアカウント管理を割り当てます。
データベース管理者にリソース管理タスクを割り当てます。
Database Vault APIスクリプトをセキュア・サーバーにバックアップします。
PL/SQLパッケージ、権限およびリサイクルビンのセキュリティの考慮事項を認識する必要があります。
内容は次のとおりです。
注意:
パッチおよび新規アプリケーションをインストールすると、この項で取り消した権限のうち、Oracleが推奨する一部の権限が再付与されることがあります。パッチおよび新規アプリケーションをインストールした後で、これらの権限を確認し、取り消されたままになっていることを確認してください。
パッケージに対するEXECUTE
権限を取り消した場合は、所有者にパッケージに対するEXECUTE
が付与されていることを確認し、パッケージの依存関係を確認し、取消し後に無効なパッケージを再コンパイルしてください。
パッケージにアクセスできるユーザーを確認するには、名前付きデータベース管理者としてデータベース・インスタンスにログインして、次の問い合せを発行します。
SELECT * FROM DBA_TAB_PRIVS WHERE TABLE_NAME = package_name;
package_name
は、検索するパッケージの名前です。
パッケージに依存するユーザー、パッケージ、プロシージャおよびファンクションを検索するには、次の問合せを発行します。
SELECT OWNER, NAME, TYPE FROM ALL_DEPENDENCIES
WHERE REFERENCED_NAME = package_name;
この2つの問合せは、動的SQLで行われたパッケージへの参照を識別しません。
UTL_FILE
およびDBMS_FILE_TRANSFER
PL/SQLパッケージへのアクセスを慎重に制限する必要があります。
内容は次のとおりです。
UTL_FILE
パッケージはSYS
によって所有され、PUBLIC
に付与されます。ただし、ユーザーがオペレーティング・システム・ディレクトリ内のファイルを操作するためには、そのディレクトリ・オブジェクトへのアクセス権が必要です。
UTL_FILE
パッケージをセキュアに構成できます。詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
DBMS_FILE_TRANSFER
パッケージは、SYS
によって所有され、EXECUTE_CATALOG_ROLE
に付与されます。このパッケージに対するEXECUTE
アクセス権を持つユーザーは、同じファイルシステムの1つの場所から別の場所にファイルを移動できます。リモート・システム上のデータベースを含め、データベース・インスタンス間でファイルを移動することもできます。
DBMS_FILE_TRANSFER
PL/SQLパッケージへのアクセスを様々な方法で保護できます。
次の方法のいずれかを使用して、DBMS_FILE_TRANSFER
PL/SQLパッケージを保護します。
DBMS_FILE_TRANSFER
パッケージのEXECUTE
権限を取り消し、この権限を必要とする信頼できるユーザーに対してのみEXECUTE
権限を付与します。
コマンド・ルールを作成して、CREATE DATABASE LINK
およびCREATE DIRECTORY
SQL文を制御します。Oracle Database Vault Administratorを使用したコマンド・ルール作成の詳細は、"「コマンド・ルールの作成または編集」"を参照してください。
Oracle Database Vaultコマンド・ルールを作成して、CREATE DATABASE LINK
およびCREATE DIRECTORY
文へのアクセスを制限および有効化します。これらの文は、リモート・データベースへの接続を確立するために使用します。
関連項目:
CREATE DATABASE LINK
文の使用を保護するために作成できるコマンド・ルールの例は、次の項を参照してください。
DBMS_MACADM.CREATE_COMMAND_RULE
では、コマンド・ルールを作成して、CREATE DATABASE LINK
SQL文へのアクセスを拒否できます。
例D-1に、CREATE DATABASE LINK
権限へのアクセスを拒否するコマンド・ルールの作成方法を示します。
例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;
DBMS_MACADM.UPDATE_COMMAND_RULE
プロシージャは、既存のコマンド・ルールを変更するために使用できます。
例D-2に、CREATE DATABASE LINK
権限へのアクセスを有効にするコマンド・ルールの作成方法を示します。
有効なユーザーがCREATE DATABASE LINK
文を使用する必要がある場合、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
コマンド・ルールがリサイクルビン機能の有効化を妨げます。
しかし、リサイクルビンを有効にした場合は、そのリサイクルビンを無効にするのを妨げることはできません。リサイクルビン機能が有効な場合、レルムで保護されたオブジェクトが削除されると、リサイクル・ビンに移動されます。そこでは、オブジェクトはレルムによって保護されなくなります。DVSYS
スキーマのオブジェクトは例外です。DVSYS
を保護スキーマとして保持し続けるために、このスキーマのオブジェクトを削除できません。他のレルムのセキュリティを強化するために、リサイクルビンを無効にする必要があります。
SELECT
文を使用すると、リサイクルビンの内容をチェックできます。
SQL*Plusで、次のようにSELECT
を使用して、リサイクルビンの内容をチェックします。
SELECT * FROM RECYCLEBIN; SELECT * FROM USER_RECYCLEBIN;
PURGE
SQL文を使用すると、リサイクルビンの内容をパージできます。
次のPURGE
コマンドを実行して、リサイクルビンの内容をパージします。
PURGE RECYCLEBIN; PURGE USER_RECYCLEBIN;
CREATE ANY JOB
権限はDBA
ロールおよびSCHEDULER_ADMIN
ロールから取り消されています。
使用しているアプリケーションにこの変更による影響がないことを確認してください。
CREATE EXTERNAL JOB
権限は、Oracle Database 10gリリース2 (10.2)で導入されました。
この権限は、データベースの外部のオペレーティング・システムで稼働するジョブを実行するデータベース・ユーザーに必要です。デフォルトでは、CREATE EXTERNAL JOB
権限は、CREATE JOB
権限が付与されたすべてのユーザーに付与されます。セキュリティを高めるために、この権限を必要としないユーザーからこの権限を取り消し、必要とするユーザーにのみ付与してください。
ロールEXECUTE_CATALOG_ROLE
には、いくつかのLogMinerパッケージに対するEXECUTE
権限がデフォルトでは付与されません。
これらのパッケージは次のとおりです。
DBMS_LOGMNR
DBMS_LOGMNR_D
DBMS_LOGMNR_LOGREP_DICT
DBMS_LOGMNR_SESSION
使用しているアプリケーションにこの変更による影響がないことを確認してください。
強力なALTER SYSTEM
およびALTER SESSION
システム権限を保護する方法を認識する必要があります。
内容は次のとおりです。
トレースおよびデバッグ・コマンドは、Oracleデータベース・メモリー情報を表示する可能性があることに注意してください。
Oracle Database Vaultは、これらのコマンドに対する保護を行いません。Oracleデータベース・メモリー情報を保護するために、ALTER SYSTEM
権限およびALTER SESSION
権限へのアクセスを厳密に制御することをお薦めします。これらの権限は、SYSDBA
として接続しているときにユーザーSYS
によって、またDBA
ロールを付与されている任意のユーザーによって付与できます。
また、ALTER SYSTEM
文の既存のコマンド・ルールにツールを追加することをお薦めします。Oracle Database Vault Administratorを使用してルールを作成し、そのルールをルール・セットに追加できます。ALTER SESSION
権限は、信頼できるユーザーにのみ付与してください。(たとえば、ALTER SESSION
文はトレースを有効にできます。)
ALTER SYSTEM
権限のあるユーザーにALTER SYSTEM
文を発行できないようにするルールを作成できます。
例D-4に、ALTER SYSTEM
権限を持つユーザーがコマンドALTER SYSTEM DUMP
を発行できなくなるルールの作成方法を示します。このコマンド・ルールを作成するときに、Oracle Database Vault所有者アカウントとしてデータベース・インスタンスにログインします。
または、Oracle Database Vault Administratorを使用してルールを作成し、そのルールをルール・セットに追加できます。詳細は、「ルール・セットに追加するルールの作成」を参照してください。
例D-4 既存のALTER SYSTEMコマンド・ルールへのルールの追加
CONNECT bea_dvacctmgr
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 Fine Grained Control of System Parameters','NO_SYSTEM_DUMP');
COMMIT;