日本語PDF
  1. 管理者ガイド
  2. Oracle Database Vaultセキュリティ・ガイドライン

D Oracle Database Vaultセキュリティ・ガイドライン

すべてのOracle Database製品と同様に、Oracle Database Vaultインストールを適切に保護するためにセキュリティ・ガイドラインに従う必要があります。

D.1 職務分離のガイドライン

Oracle Database Vaultは、職務分離のガイドラインを容易に実現できるように設計されています。

親トピック: Oracle Database Vaultセキュリティ・ガイドライン

D.1.1 Oracle Database Vaultによる職務分離の処理

職務分離は、各ユーザーの権限をそのユーザーが担当するタスクのみに制限し、それ以外のタスクの権限は付与しません。

多くの権限を1人のユーザーに付与するのではなく、特定の権限カテゴリを特定のユーザーに割り当てます。簡単に言えば、組織で求められる各タスクのアカウンタビリティが職務分離によって構築されます。

職務分離は、過去10年で非常に重要視されるようになりました。多くの組織にとって、職務分離は今後も展開し続ける新しい概念です。データベースの統合、法令順守およびアウトソーシングは、職務分離を推し進める要因の一部にすぎません。Oracle Database Vaultの職務分離では、セキュリティ関連の管理を日常的なDBA操作と分離することによって、セキュリティが強化されます。Database Vaultの職務分離は、現在および将来のビジネス要件に容易に対処できるようにカスタマイズが可能です。特に小規模組織では、限られたリソースでセキュリティ・プロファイルを向上させるために、柔軟性が必要となります。

親トピック: 職務分離のガイドライン

D.1.2 Oracle 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アカウント所有者が自分のパスワードを忘れた場合や企業を退職した場合に備えて、バックアップ・ユーザー・アカウントを保持し続ける必要があります。DV_OWNERロールを付与されているすべてのユーザー・アカウントへのアクセスを失わないことも重要です。DV_OWNERロールを持つアカウントへのアクセスを失った場合(パスワードの紛失やスタッフの離職など)、DV_OWNERロールをリカバリする方法はありません。DV_OWNERロールへのアクセスを失った場合、Database Vaultの制御を変更したり、Database Vaultを無効にすることはできません。この問題に対処するには、データベースがDatabase Vault所有者アカウントを所有している最後の既知のポイントまでデータベースをリカバリします。

    オプションで、アカウント管理とセキュリティ管理の職責を統合することもできます。

  • データベース管理。データベース管理とは、データベース・システムの管理のことで、ビジネス・データへのアクセスのことではありません。次のような操作があります。

    • バックアップ操作では、事前定義されたツールを使用してバックアップを実行するための事前定義時刻が必要です。

    • チューニングおよび監視操作では、継続したパフォーマンス監視および分析が必要です。

    • パッチ適用操作では、パッチが適用されている間のみの一時アクセスが必要です。

    職務分離との関連においてデータベース管理アカウントを確認することをお薦めします。様々なデータベース管理者が、様々な権限およびロールを必要とする様々な職務を担当できます。同様に、経験豊かなデータベース管理者ほど、より多くのロールおよび権限がある可能性があります。ユーザーにデフォルトのDBAロールを付与するかわりに、組織での特定の地位および勤続年数にあわせてデータベース管理ロールを調整することを検討してください。名前付きアカウントのみを日常的な活動のために使用することが重要です。SYSなどのアカウント、およびSYSDBA管理権限を使用するアカウントは、特権アカウント管理(PAM)システムで管理され、使用時にチェック(および監査)される必要があります。バックアップOracle Database Vault所有者およびアカウント管理アカウントをPAMシステムで管理する必要もあります。オペレーティング・システム内では、rootおよびoracleアカウントは、強力な権限があるため、チェックアウト・システムによってのみ使用できるようにする必要があります。

データベース・アカウント管理とデータベース・セキュリティ管理のための個別アカウントと、バックアップ操作のためのその他の名前付きアカウントが必要です。監査者は、各職責のための個別のデータベース・アカウントをチェックし、各アカウントのアクションを追跡できます。特定タスクに割り当てられているユーザーの数は、あまり重要ではありません。Oracle Database Vault監査イベントは保護されており、Database Vaultレポートにはすべての違反未遂が表示されます。

関連項目:

親トピック: 職務分離のガイドライン

D.1.3 Oracle Database Vaultの職務分離マトリクス

職務分離を適用するには、環境で基本的な管理タスクを実行するユーザーおよびその管理タスクの内容を理解する必要があります。

1人のデータベース管理者が新しいデータベース・アカウントのプロビジョニングとアプリケーションのパッチ適用の両方の管理を担当する場合でも、これらの各タスクについて文書化および計画することが重要となります。これらのタイプのタスクに別々の管理アカウントを使用すると、アカウンタビリティが向上し、悪質なユーザーによって単一のアカウントが侵害された場合に関連するリスクが軽減されます。中規模から大規模の組織では、データベース管理者は通常、一般的な管理タスクを実行する必要はありますが、アプリケーションで管理されるビジネス・データにアクセスする必要はありません。職務分離マトリクスを作成すると、Database Vaultデプロイメントを計画する際に役立ちます。必要に応じて、追加タスクおよび関連するユーザーをリストに含めることができます。この情報は、組織の全体的なエンタープライズ・セキュリティ・ドキュメントの一部となります。

表D-1は、職務分離マトリクスの例を示しています。

表D-1 職務分離マトリクスの例

ユーザー、プロセスまたはアプリケーション アカウント作成 データベース管理 セキュリティ管理者
SYSDBA バックアップ チューニング パッチ適用 監視

JSMITH

あり

不可

不可

不可

不可

不可

不可

SHARDY

不可

不可

不可

不可

不可

不可

あり

PKESTNER

不可

不可

あり

不可

不可

不可

不可

RTYLER

不可

不可

不可

不可

あり

不可

不可

SANDERSON

不可

不可

不可

あり

不可

あり

不可

SYSTEM

不可

不可

不可

不可

可(EBSのパッチ適用の場合)

不可

不可

RMAN

不可

あり

あり

不可

不可

不可

不可

システム管理タスクで、特定のツールおよびプログラムからデータへの一時的なアクセスが必要なこともあります。この場合、Oracle Database Vaultルールおよびルール・セットに、この一時アクセスまたは緊急アクセスに対するプロビジョニングを構築します。

親トピック: 職務分離のガイドライン

D.1.4 データベース・ユーザーのタスクの識別および文書化

組織で必要となる次のタスク範囲を文書化する必要があります。

これらの範囲は次のとおりです。

  • 各管理ユーザーの職責。

  • ユーザーが必要とするアクセス権の種類。たとえば、アプリケーション所有者はデータ・アクセス、開発者は開発インスタンスに対するアクセスのみを必要とします。

  • ビジネス・データにアクセスせずにシステムを管理する必要のあるユーザー(バックアップ、パッチ適用、チューニングおよび監視操作を実行するユーザーなど)。

  • 各タスク・カテゴリの職務(バックアップの必要なファイル、パッチ適用の必要なアプリケーション、監視の正確な対象など)。これらの各タスクの代替ユーザー・アカウントも含まれます。

  • 保護が必要なデータベースとアプリケーション。これには、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コマンド・ルール

    無効なルール・セット

    無効なルール・セット

    無効なルール・セット

    無効なルール・セット

親トピック: 職務分離のガイドライン

D.2 Oracle Database管理アカウントの管理

Oracleでは、SYSTEMなどの管理アカウント、またはSYSDBA管理権限を持つユーザーのセキュリティを管理するためのガイドラインを提供しています。

親トピック: Oracle Database Vaultセキュリティ・ガイドライン

D.2.1 一般的な管理目的のためのSYSTEMユーザー・アカウント

理想的には、SYSTEMアカウントは、使用中にチェックアウトおよび監査されるバックアップとしてのみ使用可能になる必要があります。

共有アカウントではなく、名前付きアカウントのみが、通常のデータベース管理タスクのために使用される必要があります。これにより、データベース内の管理アクションに対するアカウンタビリティが向上します。

親トピック: Oracle Database管理アカウントの管理

D.2.2 アプリケーション表のSYSTEMスキーマ

SYSTEMスキーマ内にアプリケーション表がある場合は、SYSTEMアカウントをこれらの表に対するレルム認可に追加します。

これにより、これらのアプリケーションは引続き正常に動作します。

これらのアプリケーションのセキュリティを向上または微調整するため、SYSTEMアカウントに制限を加えることもできます。たとえば、SYSTEMユーザーのアクセスを特定のIPアドレスに制限するDatabase Vaultルール・セットを作成できます。

親トピック: Oracle Database管理アカウントの管理

D.2.3 SYSDBA管理権限の制限

SYSDBA管理権限は、接続時にこの権限の使用がどうしても必要なユーザーや、引き続きSYSDBAアクセスを必要とするアプリケーションに制限してください。

たとえば、必須のパッチ適用プロセスには、SYSDBAアクセスが必要です。

他のすべてのケースでは、日常的なデータベース管理を実行するための名前付きデータベース・アカウントを作成します。また、OSDBAユーザー・グループのメンバーにはSYSDBA管理権限が付与されます。オペレーティング・システムのrootおよびoracleアカウントの他に、データベースSYSアカウント、およびSYSDBA権限があるアカウントは、特権アカウント管理(PAM)システムで管理され、要求時のみチェックアウトされる必要があります。

関連トピック

親トピック: Oracle Database管理アカウントの管理

D.2.4 Oracle Database Vaultへのルートおよびオペレーティング・システムのアクセス

セキュリティ向上のために、ルートおよびオペレーティング・システムの次へのアクセスを注意深く監視する必要があります: Oracle Database Vault。

Oracle Database Vaultは、多くの権限を持つデータベース・ユーザーが機密データにアクセスすることを防ぎます。また、Oracle Database自体を使用している場合は、「透過的データ暗号化」を使用することで、最大の権限を持つオペレーティング・システム・ユーザーが機密データにアクセスできないようにできます。透過的データ暗号化では、表領域および表の列を暗号化できます。これにより、オペレーティング・システム・ユーザーが、オペレーティング・システムのデータベース・ファイルを参照することや、機密データを見つけることができなくなります。オペレーティング・システムへの直接アクセスを常に注意深く確認し、制限することをお薦めします。

オペレーティング・システムにアクセスするには、アカウントをパーソナライズしておく必要があります。これらのパーソナライズされたアカウントは、LinuxまたはUNIX環境で、必要に応じてsudoを使用してoracleソフトウェア所有者にログインします。sudoでは、パーソナライズされた各ユーザーが実行できる特定のコマンドを制御できます。これらのユーザーについては、make、relink、gdb、またはデータベースで問題が発生する可能性があるその他のコマンドの使用を禁止してください。ただし、管理ユーザーがパッチをインストール、またはその他の緊急操作を実行する必要がある場合は、一定の時間のみmakeおよびrelinkコマンドを有効にし、この時間中のアクションを監査できます。

関連項目:

透過的データ暗号化の詳細は、『Oracle Database Advanced Securityガイド』を参照してください。

親トピック: Oracle Database管理アカウントの管理

D.3 Oracle Database Vaultによって信頼されるアカウントおよびロール

Oracle Database Vaultは、データベース内の権限を与えられた多くのユーザーおよびロールからのアプリケーション・データへのアクセスを制限します。

ただし、場合によっては、Oracle Database Vaultsは特定のロールおよび権限を信頼します。

表D-3に、信頼できるロールおよび権限を示します。これらのロールおよび権限は、Oracle Database Vaultのインストール時に作成されます。

表D-3 信頼できるOracle Database Vaultロールおよび権限

ロールまたは権限 ステータス 説明

DV_ACCTMGRロール

オープン

登録時に作成され、新規データベース・アカウントの作成に使用されるロール。安全対策として、DV_ACCTMGRロールがあるバックアップ・ユーザーを保持し、特権アカウント管理(PAM)システムを使用してこのアカウントを管理します。

DV_OWNERロールがあるユーザーは、このユーザーを変更できません。

DV_ACCTMGRロールがあるすべてのアカウントを失った場合(パスワードの紛失や組織からのユーザーの退職などが原因)、回復できません。必ずバックアップDV_ACCTMGRアカウントをこの目的のために作成するようにしてください。

DV_OWNERロール

オープン

登録時に作成され、レルム、ファクタおよびコマンド・ルールの管理に使用されるロール。このユーザーは、自分自身をレルム認可に追加できます。安全対策として、DV_OWNERロールがあるバックアップ・ユーザーを保持し、特権アカウント管理(PAM)システムを使用してこのアカウントを管理します。

DV_OWNERロールがあるユーザーは、このユーザーを変更できません。

DV_OWNERロールがあるすべてのアカウントを失った場合(パスワードの紛失や組織からのユーザーの退職などが原因)、回復できません。必ずバックアップDV_OWNERアカウントをこの目的のために作成するようにしてください。

SYSDBA権限

有効

Oracle Databaseのインストール時に作成される権限。一部のOracle機能に必要です。

SYSOPER権限

有効

Oracle Databaseのインストール時に作成される権限。データベースの起動および停止。デフォルトではSYSにのみ付与されます。

関連トピック

親トピック: Oracle Database Vaultセキュリティ・ガイドライン

D.4 信頼できる人物に制限する必要のあるアカウントおよびロール

強力なアカウントおよびロールは、信頼できる人物に制限する必要があります。

親トピック: Oracle Database Vaultセキュリティ・ガイドライン

D.4.1 オペレーティング・システムへのルート・アクセス権を持つユーザーの管理

ルート・ユーザー・アクセス権を持つユーザーは、システムを完全に制御できます。

これらのユーザーが実行できるアクティビティには、次のものがあります。

  • 暗号化されていないファイルの読取り

  • ファイルの移動および削除

  • システムでのプログラムの起動または停止

  • Oracle Databaseインストール環境を所有するユーザーを含む任意のユーザーとしてのログイン

Oracle Database Vaultでは、オペレーティング・システム・ルート・アクセスに対して保護されません。rootおよびoracleアカウントを特権アカウント管理(PAM)システムで管理します。これらのアカウントは、特定のタスクに必要な場合のみチェックアウトします。強い権限があるオペレーティング・システム・アカウントが使用されている場合は、キーストローク取得およびビデオ取得まで、監査レベルを高くします。

親トピック: 信頼できる人物に制限する必要のあるアカウントおよびロール

D.4.2 Oracleソフトウェア所有者の管理

システムにOracleソフトウェア所有者としてのアクセス権を持つユーザーは、Oracleソフトウェアを制御できます。

これらのユーザーが実行できるアクティビティには、次のものがあります。

  • 暗号化されていないデータベース・ファイルの読取り

  • データベース・ファイルの移動および削除

  • システムでのOracleプログラムの起動または停止

Oracle Database Vaultでは、Oracleソフトウェア所有者のオペレーティング・システム・アクセスから保護されません。Oracleソフトウェア所有者アカウントを特権アカウント管理(PAM)システムで管理します。このアカウントは、特定のタスクに必要な場合のみチェックアウトします。強い権限があるオペレーティング・システム・アカウントが使用されている場合は、キーストローク取得およびビデオ取得まで、監査レベルを高くします。

親トピック: 信頼できる人物に制限する必要のあるアカウントおよびロール

D.4.3 SYSDBAアクセスの管理

通常のデータベース・メンテナンス・タスクではSYSアカウントおよびSYSDBA権限を使用しないようにする必要があります。

かわりに、必要なシステム権限、またはSYSBACKUP、SYSDG、SYSKMなどの特定の管理権限がある名前付きアカウントを使用します。ただし、パッチの実行、データベースのアップグレードまたは問題のトラブルシューティング(たとえば、停止したデータベースへの接続)のためにSYSDBA権限が必要な場合があります。

SYSDBA権限のあるユーザーは、直接的または間接的(たとえば、診断、データベース・アップグレードおよびパッチ適用による)に機密アプリケーション・データにアクセスできるため、SYSDBA権限およびアカウントの使用は、厳密に制限する必要があります。強力な権限のあるアカウントのリストには、SYS、およびデータベース内のSYSDBA権限のあるユーザー・アカウント、およびオペレーティング・システム内のrootおよびoracleアカウントが含まれます。データベースおよびオペレーティング・システム内の強力な権限のあるアカウントへのアクセスは、例外ベースである必要があり、ユーザーが、これらのアカウントおよび権限へのアクセスをロック解除するプロセスを経る必要があります。これらのアカウントを特権アカウント管理(PAM)システムで管理することをお薦めします。これらのアカウントは、特定のタスクに必要な場合のみチェックアウトします。強い権限があるオペレーティング・システム・アカウント(rootおよびoracle)およびデータベース・アカウント(SYSアカウントおよびSYSDBA管理権限)が使用されている場合は、キーストローク取得およびビデオ取得まで、監査レベルを高くします。これらの強い権限のあるアカウントがデータベースにアクセスするときには、SYSアカウントを監査してそれらのアクティビティを監視します。SYS (またはSYSDBA管理者権限を持つユーザー)にDV_PATCH_ADMINロールが付与されている場合は、バッチ適用操作の際にENABLE_DV_PATCH_ADMIN_AUDITプロシージャを使用することをお薦めします。

関連トピック

親トピック: 信頼できる人物に制限する必要のあるアカウントおよびロール

D.4.4 SYSOPERアクセスの管理

デフォルトでは、Oracle Databaseは、SYSOPERアクセスをOSOPERグループのオペレーティング・システム・ユーザーおよびユーザーSYSに限定します。

これによって、SYSOPERがOracleデータ・ディクショナリを直接変更することを防ぎます。SYSOPER権限は、データベース内の制限された権限を持ちますが、このロールを持つユーザーは、Oracleデータベースの起動と停止を行うことができます。SYSOPER権限は、信頼できるユーザーにのみ付与してください。

親トピック: 信頼できる人物に制限する必要のあるアカウントおよびロール

D.5 Oracle Database Vaultを本番環境で使用するためのガイドライン

Oracle Database Vaultを本番環境で実行する際は、特定のガイドラインに従う必要があります。

これらのガイドラインは、次のとおりです。

  • アプリケーションの全テストを実行して、作成したDatabase Vaultポリシーが予測どおりに機能していることを確認します。

  • アプリケーションのパフォーマンスを監視し、必要に応じてルール式を調整します。

  • 適切な製品サポートおよびセキュリティ・グループに職責を次のように割り当てます。

    • データベース・セキュリティ管理者にセキュリティ職責を割り当てます。

    • データベース・アカウント・マネージャにアカウント管理を割り当てます。

    • データベース管理者にリソース管理タスクを割り当てます。

  • Database Vault APIスクリプトをセキュア・サーバーにバックアップします。

親トピック: Oracle Database Vaultセキュリティ・ガイドライン

D.6 セキュアな構成のガイドライン

PL/SQLパッケージ、権限およびリサイクルビンのセキュリティの考慮事項を認識する必要があります。

親トピック: Oracle Database Vaultセキュリティ・ガイドライン

D.6.1 一般的なセキュア構成のガイドライン

一般的なセキュア構成のガイドラインには、パッチおよび取消し操作が含まれます。

  • パッチおよび新規アプリケーションをインストールすると、この項で取り消した権限のうち、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で行われたパッケージへの参照を識別しません。

親トピック: セキュアな構成のガイドライン

D.6.2 UTL_FILEおよびDBMS_FILE_TRANSFERパッケージのセキュリティの考慮事項

UTL_FILEおよびDBMS_FILE_TRANSFER PL/SQLパッケージへのアクセスを慎重に制限する必要があります。

親トピック: セキュアな構成のガイドライン

D.6.2.1 UTL_FILEおよびDBMS_FILE_TRANSFERパッケージのセキュリティの考慮事項について

UTL_FILEパッケージはSYSによって所有され、PUBLICに付与されます。

ただし、ユーザーがオペレーティング・システム・ディレクトリ内のファイルを操作するためには、そのディレクトリ・オブジェクトへのアクセス権が必要です。

DBMS_FILE_TRANSFERパッケージは、SYSによって所有され、EXECUTE_CATALOG_ROLEに付与されます。このパッケージに対するEXECUTEアクセス権を持つユーザーは、同じファイル・システムの1つの場所から別の場所にファイルを移動できます。リモート・システム上のデータベースを含め、データベース・インスタンス間でファイルを移動することもできます。

関連項目:

UTL_FILEパッケージの安全な構成については、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください

親トピック: UTL_FILEおよびDBMS_FILE_TRANSFERパッケージのセキュリティの考慮事項

D.6.2.2 DBMS_FILE_TRANSFERパッケージへのアクセスの保護

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文へのアクセスを制限および有効化します。これらの文は、リモート・データベースへの接続を確立するために使用します。

D.6.2.3 例: 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;
D.6.2.4 例: CREATE DATABASE LINKへのアクセスを有効にするコマンド・ルールの作成

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.6.2.5 例: CREATE DIRECTORYへのアクセスを無効および有効にするコマンド・ルール

例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;

D.6.3 CREATE ANY JOB権限のセキュリティの考慮事項

CREATE ANY JOB権限はDBAロールおよびSCHEDULER_ADMINロールから取り消されています。

使用しているアプリケーションにこの変更による影響がないことを確認してください。

関連トピック

親トピック: セキュアな構成のガイドライン

D.6.4 CREATE EXTERNAL JOB権限のセキュリティの考慮事項

CREATE EXTERNAL JOB権限は、Oracle Database 10gリリース2 (10.2)で導入されました。

この権限は、データベースの外部のオペレーティング・システムで稼働するジョブを実行するデータベース・ユーザーに必要です。デフォルトでは、CREATE EXTERNAL JOB権限は、CREATE JOB権限が付与されたすべてのユーザーに付与されます。セキュリティを高めるために、この権限を必要としないユーザーからこの権限を取り消し、必要とするユーザーにのみ付与してください。

親トピック: セキュアな構成のガイドライン

D.6.5 LogMinerパッケージのセキュリティの考慮事項

ロールEXECUTE_CATALOG_ROLEには、いくつかのLogMinerパッケージに対するEXECUTE権限がデフォルトでは付与されません。

これらのパッケージは次のとおりです。

  • DBMS_LOGMNR

  • DBMS_LOGMNR_D

  • DBMS_LOGMNR_LOGREP_DICT

  • DBMS_LOGMNR_SESSION

使用しているアプリケーションにこの変更による影響がないことを確認してください。

親トピック: セキュアな構成のガイドライン

D.6.6 ALTER SYSTEMおよびALTER SESSION権限のセキュリティの考慮事項

強力なALTER SYSTEMおよびALTER SESSIONシステム権限を保護する方法を認識する必要があります。

親トピック: セキュアな構成のガイドライン

D.6.6.1 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文はトレースを有効にできます。)

D.6.6.2 例: 既存のALTER SYSTEMコマンド・ルールへのルールの追加

ALTER SYSTEM権限のあるユーザーがALTER SYSTEM文を発行できないようにするルールを作成できます。

例D-4では、ALTER SYSTEM権限のあるユーザーがALTER SYSTEM DUMP文を発行できないようにするルールを作成する方法を示します。このコマンド・ルールを作成するときに、Oracle Database Vault所有者アカウントとしてデータベース・インスタンスにログインします。

または、Oracle Database Vault Administratorを使用してルールを作成し、そのルールをルール・セットに追加できます。詳細は、「ルール・セットに追加するルールの作成」を参照してください。

例D-4 既存のALTER SYSTEMコマンド・ルールへのルールの追加

CONNECT accts_admin_ace
Enter password: password

BEGIN
 DBMS_MACADM.CREATE_RULE('NO_SYSTEM_DUMP',
 '(INSTR(UPPER(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;