D Oracle Database Vaultセキュリティ・ガイドライン
すべてのOracle Database製品と同様に、Oracle Database Vaultインストールを適切に保護するためにセキュリティ・ガイドラインに従う必要があります。
- 職務分離のガイドライン
Oracle Database Vaultは、職務分離のガイドラインを容易に実現できるように設計されています。 - Oracle Database管理アカウントの管理
Oracleでは、SYSTEM
などの管理アカウント、またはSYSDBA
管理権限を持つユーザーのセキュリティを管理するためのガイドラインを提供しています。 - Oracle Database Vaultによって信頼されるアカウントおよびロール
Oracle Database Vaultは、データベース内の権限を与えられた多くのユーザーおよびロールからのアプリケーション・データへのアクセスを制限します。 - 信頼できる人物に制限する必要のあるアカウントおよびロール
強力なアカウントおよびロールは、信頼できる人物に制限する必要があります。 - Oracle Database Vaultを本番環境で使用するためのガイドライン
Oracle Database Vaultを本番環境で実行する際は、特定のガイドラインに従う必要があります。 - セキュアな構成のガイドライン
PL/SQLパッケージ、権限およびリサイクルビンのセキュリティの考慮事項を認識する必要があります。
D.1 職務分離のガイドライン
Oracle Database Vaultは、職務分離のガイドラインを容易に実現できるように設計されています。
- Oracle Database Vaultによる職務分離の処理
職務分離とは、各ユーザーの権限をそのユーザーが担当するタスクのみに制限し、それ以外のタスクの権限は付与しないことを意味します。 - Oracle Database Vault環境でのタスクの分離
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レポートにはすべての違反未遂が表示されます。
関連項目:
-
Oracle Database Vaultロールがどのように職務分離を提供するかの詳細は、Oracle Database Vaultロールを参照してください
-
デフォルトのOracle Database Vaultアカウントをすべて示すリストは、登録中に作成されるOracle Database Vaultアカウントを参照してください
-
バックアップ・アカウントの重要性の詳細は、バックアップOracle Database Vaultアカウントを参照してください
親トピック: 職務分離のガイドライン
D.1.3 Oracle Database Vaultの職務分離マトリクス
職務分離を適用するには、環境で基本的な管理タスクを実行するユーザーおよびその管理タスクの内容を理解する必要があります。
1人のデータベース管理者が新しいデータベース・アカウントのプロビジョニングとアプリケーションのパッチ適用の両方の管理を担当する場合でも、これらの各タスクについて文書化および計画することが重要となります。これらのタイプのタスクに別々の管理アカウントを使用すると、アカウンタビリティが向上し、悪質なユーザーによって単一のアカウントが侵害された場合に関連するリスクが軽減されます。中規模から大規模の組織では、データベース管理者は通常、一般的な管理タスクを実行する必要はありますが、アプリケーションで管理されるビジネス・データにアクセスする必要はありません。職務分離マトリクスを作成すると、Database Vaultデプロイメントを計画する際に役立ちます。必要に応じて、追加タスクおよび関連するユーザーをリストに含めることができます。この情報は、組織の全体的なエンタープライズ・セキュリティ・ドキュメントの一部となります。
表D-1は、職務分離マトリクスの例を示しています。
表D-1 職務分離マトリクスの例
ユーザー、プロセスまたはアプリケーション | アカウント作成 | データベース管理 | セキュリティ管理者 | ||||
---|---|---|---|---|---|---|---|
SYSDBA | バックアップ | チューニング | パッチ適用 | 監視 | |||
|
あり |
不可 |
不可 |
不可 |
不可 |
不可 |
不可 |
|
不可 |
不可 |
不可 |
不可 |
不可 |
不可 |
あり |
|
不可 |
不可 |
あり |
不可 |
不可 |
不可 |
不可 |
|
不可 |
不可 |
不可 |
不可 |
あり |
不可 |
不可 |
|
不可 |
不可 |
不可 |
あり |
不可 |
あり |
不可 |
|
不可 |
不可 |
不可 |
不可 |
可(EBSのパッチ適用の場合) |
不可 |
不可 |
|
不可 |
あり |
あり |
不可 |
不可 |
不可 |
不可 |
システム管理タスクで、特定のツールおよびプログラムからデータへの一時的なアクセスが必要なこともあります。この場合、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
管理権限を持つユーザーのセキュリティを管理するためのガイドラインを提供しています。
- 一般的な管理目的のためのSYSTEMユーザー・アカウント
理想的には、SYSTEM
アカウントは、使用中にチェックアウトおよび監査されるバックアップとしてのみ使用可能になる必要があります。 - アプリケーション表のSYSTEMスキーマ
SYSTEM
スキーマ内にアプリケーション表がある場合は、SYSTEM
アカウントをこれらの表に対するレルム認可に追加します。 - SYSDBA管理権限の制限
SYSDBA
管理権限は、接続時にこの権限の使用がどうしても必要なユーザーや、引き続きSYSDBA
アクセスを必要とするアプリケーションに制限してください。 - Oracle Database Vaultへのルートおよびオペレーティング・システムのアクセス
セキュリティ向上のために、ルートおよびオペレーティング・システムの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ロールおよび権限
ロールまたは権限 | ステータス | 説明 |
---|---|---|
|
オープン |
登録時に作成され、新規データベース・アカウントの作成に使用されるロール。安全対策として、
|
|
オープン |
登録時に作成され、レルム、ファクタおよびコマンド・ルールの管理に使用されるロール。このユーザーは、自分自身をレルム認可に追加できます。安全対策として、
|
|
有効 |
Oracle Databaseのインストール時に作成される権限。一部のOracle機能に必要です。 |
|
有効 |
Oracle Databaseのインストール時に作成される権限。データベースの起動および停止。デフォルトでは |
D.4 信頼できる人物に制限する必要のあるアカウントおよびロール
強力なアカウントおよびロールは、信頼できる人物に制限する必要があります。
- オペレーティング・システムへのルート・アクセス権を持つユーザーの管理
ルート・ユーザー・アクセス権を持つユーザーは、システムを完全に制御できます。 - Oracleソフトウェア所有者の管理
システムにOracleソフトウェア所有者としてのアクセス権を持つユーザーは、Oracleソフトウェアを制御できます。 - SYSDBAアクセスの管理
通常のデータベース・メンテナンス・タスクではSYS
アカウントおよびSYSDBA
権限を使用しないようにする必要があります。 - SYSOPERアクセスの管理
デフォルトでは、Oracle Databaseは、SYSOPER
アクセスをOSOPER
グループのオペレーティング・システム・ユーザーおよびユーザーSYS
に限定します。
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スクリプトをセキュア・サーバーにバックアップします。
D.6 セキュアな構成のガイドライン
PL/SQLパッケージ、権限およびリサイクルビンのセキュリティの考慮事項を認識する必要があります。
- 一般的なセキュア構成のガイドライン
一般的なセキュア構成のガイドラインには、パッチおよび取消し操作が含まれます。 - UTL_FILEおよびDBMS_FILE_TRANSFERパッケージのセキュリティの考慮事項
UTL_FILE
およびDBMS_FILE_TRANSFER
PL/SQLパッケージへのアクセスを慎重に制限する必要があります。 - CREATE ANY JOB権限のセキュリティの考慮事項
CREATE ANY JOB
権限はDBA
ロールおよびSCHEDULER_ADMIN
ロールから取り消されています。 - CREATE EXTERNAL JOB権限のセキュリティの考慮事項
CREATE EXTERNAL JOB
権限は、Oracle Database 10gリリース2 (10.2)で導入されました。 - LogMinerパッケージのセキュリティの考慮事項
ロールEXECUTE_CATALOG_ROLE
には、いくつかのLogMinerパッケージに対するEXECUTE
権限がデフォルトでは付与されません。 - ALTER SYSTEMおよびALTER SESSION権限のセキュリティの考慮事項について
強力なALTER SYSTEM
およびALTER SESSION
システム権限を保護する方法を認識する必要があります。
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パッケージへのアクセスを慎重に制限する必要があります。
- UTL_FILEおよびDBMS_FILE_TRANSFERパッケージのセキュリティの考慮事項について
UTL_FILE
パッケージは、SYS
によって所有され、PUBLIC
に付与されます。 - DBMS_FILE_TRANSFERパッケージへのアクセスの保護
DBMS_FILE_TRANSFER
PL/SQLパッケージへのアクセスを様々な方法で保護できます。 - 例: CREATE DATABASE LINKへのアクセスを拒否するコマンド・ルールの作成
DBMS_MACADM.CREATE_COMMAND_RULE
では、コマンド・ルールを作成して、CREATE DATABASE LINK
SQL文へのアクセスを拒否できます。 - 例: CREATE DATABASE LINKへのアクセスを有効にするコマンド・ルールの作成
DBMS_MACADM.UPDATE_COMMAND_RULE
プロシージャは、既存のコマンド・ルールを変更するために使用できます。 - 例: CREATE DIRECTORYへのアクセスを無効および有効にするコマンド・ルール
親トピック: セキュアな構成のガイドライン
D.6.2.1 UTL_FILEおよびDBMS_FILE_TRANSFERパッケージのセキュリティの考慮事項について
UTL_FILE
パッケージはSYS
によって所有され、PUBLIC
に付与されます。
ただし、ユーザーがオペレーティング・システム・ディレクトリ内のファイルを操作するためには、そのディレクトリ・オブジェクトへのアクセス権が必要です。
DBMS_FILE_TRANSFER
パッケージは、SYS
によって所有され、EXECUTE_CATALOG_ROLE
に付与されます。このパッケージに対するEXECUTE
アクセス権を持つユーザーは、同じファイル・システムの1つの場所から別の場所にファイルを移動できます。リモート・システム上のデータベースを含め、データベース・インスタンス間でファイルを移動することもできます。
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
文へのアクセスを制限および有効化します。これらの文は、リモート・データベースへの接続を確立するために使用します。
-
関連項目:
CREATE DATABASE LINK
文の使用を保護するために作成できるコマンド・ルールの例は、次の項を参照してください。
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
権限がデフォルトでは付与されません。
これらのパッケージは次のとおりです。
-
SYS.DBMS_LOGMNR_D
-
SYS.DBMS_LOGMNR_LOGREP_DICT
-
SYS.DBMS_LOGMNR_FILE_TRANSFER
-
SYS.DBMS_LOGMNR
使用しているアプリケーションにこの変更による影響がないことを確認してください。
親トピック: セキュアな構成のガイドライン
D.6.6 ALTER SYSTEMおよびALTER SESSION権限のセキュリティの考慮事項
強力なALTER SYSTEM
およびALTER SESSION
システム権限を保護する方法を認識する必要があります。
- ALTER SYSTEMおよびALTER SESSION権限のセキュリティの考慮事項について
トレースおよびデバッグ・コマンドは、Oracleデータベース・メモリー情報を表示する可能性があることに注意してください。 - 例: 既存のALTER SYSTEMコマンド・ルールへのルールの追加
ALTER SYSTEM
権限のあるユーザーがALTER SYSTEM
文を発行できないようにするルールを作成できます。
親トピック: セキュアな構成のガイドライン
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 bea_dvacctmgr
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;