10 レルムおよびコマンド・ルール・アクティビティのログ記録のためのシミュレーション・モードの使用
シミュレーション・モードでは、新規および変更されたOracle Database Vaultの制御を迅速にテストするために、SQLの実行を防止するかわりにシミュレーション・ログに違反を書き込みます。
- シミュレーション・モードについて
シミュレーション・モードを使用すると、Oracle Database Vaultのレルムおよびコマンド・ルールによってSQL実行をブロックするかわりに、シミュレーション・ログに違反を記録できます。 - シミュレーション・モードの使用例
シミュレーション・モードは、新しいレルムおよびコマンド・ルールの開発構成をテストするために役立ちます。 - シミュレーション・モードでのレルムのログ記録
通常のレルムおよび必須レルムの両方をシミュレーション・モードに設定できます。 - チュートリアル: シミュレーション・モードの使用によるレルムに対する違反の追跡
このチュートリアルでは、シミュレーション・モードを使用するレルムを作成してから、レルムに対する違反をテストする方法を示します。
10.1 シミュレーション・モードについて
シミュレーション・モードでは、Oracle Database Vaultのレルムおよびコマンド・ルールによってSQL実行をブロックするかわりに、シミュレーション・ログに違反を記録できます。
シミュレーション・モードでは、簡単に分析できるよう、1つの場所で取得されたエラーが格納されます。シミュレーション・モードを使用するには、レルムまたはコマンド・ルールの作成または更新時に、レルムまたはコマンド・ルールを有効または無効にするのではなく、それをシミュレーション・モードに設定します。レルムまたはコマンド・ルールはまだ有効になっていますが、違反はブロックされず、かわりにシミュレーション・ログ・ファイルに記録されるため、本番環境に対して有効にする前に、潜在的なエラーを見つけるためにテストできます。シミュレーション・モードを有効にすると、レポートに複数のレルムまたはコマンド・ルールに対する違反が含められることがあります。ユーザーのSQL文のソースをより正確に識別できる詳細なレポートが必要な場合は、PL/SQLコール・スタックを含めるようにシミュレーション・モードを構成します。このコール・スタックは、Database Vault監査レコードのより優れたトラブルシューティングのために、プロシージャおよびファンクションのコールを再帰的にキャプチャします。コール・スタック情報は、DVSYS.DBA_DV_SIMULATION_LOG
データ・ディクショナリ・ビューのPL_SQL_STACK
列に格納されます。
たとえば、次のレルム作成文では、シミュレーション・モードが有効になり、PL/SQLコース・スタックが生成されます。
BEGIN DBMS_MACADM.CREATE_REALM( realm_name => 'HR Apps', description => 'Realm to protect the HR realm', enabled => DBMS_MACUTL.G_SIMULATION, audit_options => DBMS_MACUTL.G_REALM_AUDIT_FAIL, realm_type => 1, realm_scope => DBMS_MACUTL.G_SCOPE_LOCAL, pl_sql_stack => TRUE); END; /
この時点では、レルムまたはコマンド・ルールに違反するSQL文はまだ実行可能ですが、これらのアクティビティはDBA_DV_SIMULATION_LOG
データ・ディクショナリ・ビューに記録されます。たとえば、次の問合せは、HR Appsレルムおよびシミュレーション・モードに設定されているその他すべてのレルムまたはコマンド・ルールに対する違反を検出します。
SELECT USERNAME, COMMAND, SQLTEXT, VIOLATION_TYPE FROM DBA_DV_SIMULATION_LOG, TABLE(DBA_DV_SIMULATION_LOG.REALM_NAME) RN WHERE RN.COLUMN_VALUE = "HR APPS"; USERNAME COMMAND SQLTEXT VIOLATION_TYPE -------- ---------- ------------------------------- -------------- DGRANT SELECT SELECT SALARY FROM HR.EMPLOYEES; Realm Violation
レルムまたはコマンド・ルールのテストの完了後、DV_ADMIN
またはDV_OWNER
ロールを付与されているユーザーは、このビューDVSYS.SIMULATION_LOG$
の基礎となる表の内容を削除することで、.DBA_DV_SIMULATION_LOG
データ・ディクショナリ・ビューをクリアできます。
たとえば:
DELETE FROM DVSYS.SIMULATION_LOG$;
または
DELETE FROM DVSYS.SIMULATION_LOG$ WHERE COMMAND = 'SELECT';
10.2 シミュレーション・モードの使用例
シミュレーション・モードは、新しいレルムおよびコマンド・ルールの開発構成をテストするために役立ちます。
使用例を次に示します。
-
アプリケーション認証
アプリケーションを認証している場合、アプリケーション・テスト環境で、次のようにシミュレーション・モードを使用できます。
-
アプリケーションのすべてのスキーマを、シミュレーション・モードが有効になっている必須レルムに配置します。
-
フル・リグレッション・テストを実行します。
-
DBA_DV_SIMULATION_LOG
データ・ディクショナリ・ビューを問い合せてこれらのスキーマにアクセスできるユーザーを確認することで、シミュレーション・モード・ログを分析します。 -
レルムを新しい認可で更新し、レルムを有効にします(つまり、シミュレーション・モードは使用しない)。
-
リグレッション・テストを再実行します。
-
-
新しいコマンド・ルールの導入
Oracle Database Vaultが有効になっている本番データベースでシミュレーション・モードを使用できます。
-
新しいコマンド・ルールを、必要な数週間の間、シミュレーション・モードで本番に配置します。
-
DBA_DV_SIMULATION_LOG
を問い合せて、コマンド・ルールが正しく動作しているかどうかを判断することで、シミュレーション・モード・ログを分析します。 -
必要に応じて、コマンド・ルールに変更を加えます。
-
コマンド・ルールを有効にします。
-
-
シミュレーション・モードでの本番データベースへの新しいレルムの配置。
この方法は、ルール・セット内の信頼できるパスのルールを設定し、レルムの認可ユーザーを見つけるために必要な、システム・コンテキスト情報を確認するために役立ちます。
-
レルムを必須モードで作成し、保護されたオブジェクトを追加します。
-
認可ユーザーは追加しないでください。
-
使用される通常のIPアドレスからアプリケーションおよび開発操作を実行します。
-
両方の認可ユーザーのシミュレーション・ログ・ファイル、および信頼できるパスの作成に使用できるシステム・コンテキスト情報を確認します。
-
信頼できるパスを作成してから、認可ユーザーを追加します。
-
シミュレーション・ログをクリアし、アプリケーションおよび開発操作タスクを再度実行します。
-
一定期間の経過後、シミュレーション・ログを確認します。すべての制御が正しく更新された場合、シミュレーション・ログは空になっています。シミュレーション・モードでのログ・エントリには、レルムおよびルール・セットに加える必要がある追加変更が示されます。または、ログ・エントリに、悪意ある使用が示される場合があります。
-
10.3 シミュレーション・モードでのレルムのログ記録
通常のレルムおよび必須レルムの両方をシミュレーション・モードに設定できます。
- シミュレーション・モードでレルムのログを記録する場合の考慮事項
シミュレーション・モードでレルムを使用する場合、考慮する必要があるいくつかのユースケースがあります。 - ユースケース: すべての新規レルムがシミュレーション・モード
このユースケースでは、すべてのレルムが必須または通常のいずれかで、ユーザーが作成するレルムはすべてシミュレーション・モードになります。 - ユースケース: 既存レルムへの新規レルムの導入
このユースケースでは、既存のレルムを持つデータベースに新規レルムを追加します。 - ユースケース: レルムへの新規オブジェクトの追加のテスト
このユースケースでは、既存のレルムに新規オブジェクトを追加してから、現在のレルム保護を削除せずにシミュレーション・モードを使用してこれをテストします。 - ユースケース: レルムからのオブジェクトの削除のテスト
このユースケースでは、既存レルムからのオブジェクトの削除をテストします。 - ユースケース: 認可されたユーザーのレルムへの追加のテスト
このユースケースでは、ユーザーを追加することでセキュリティ制御を緩和します。単に認可されたユーザーを追加する場合は、何もシミュレートする必要はありません。 - ユースケース: 認可されたユーザーのレルムからの削除のテスト
このユースケースでは、認可されたユーザーを削除し、シミュレーション・モードを使用してそのユーザーがまだレルムにアクセスする必要があるかどうかを確認します。 - ユースケース: レルムを使用した新規ファクタのテスト
このユースケースでは、ファクタに対する変更をテストします。 - ユースケース: 既存のコマンド・ルールへの変更のテスト
このユースケースでは、既存のコマンド・ルールに対する変更を、元のコマンド・ルールを有効にしたままテストします。
10.3.1 シミュレーション・モードでレルムのログを記録する場合の考慮事項
シミュレーション・モードでレルムを使用する場合、考慮する必要があるいくつかのユースケースがあります。
-
すべての新規Database Vault制御によるアプリケーションのテスト: すべてのレルムがシミュレーション・モード
-
既存の使用中のDatabase Vault制御に対するレルムの追加: レルムのサブセットのみがシミュレーション・モード
-
有効化されている既存レルムに新規オブジェクトを追加し、既存の制御を無効にしないでシミュレーション・モードを使用して差異をテスト
-
有効化されている既存レルムから1つ以上の既存オブジェクトを削除し、既存の制御を無効にしないでシミュレーション・モードを使用して差異をテスト
-
有効化されている既存レルムに新しい認可ユーザーを追加し、既存の制御を無効にしないでシミュレーション・モードを使用して差異をテスト
-
有効化されている既存レルムから1つ以上の既存の認可ユーザーを削除し、既存の制御を無効にしないでシミュレーション・モードを使用して差異をテスト
-
有効化されている既存レルムでファクタを追加するか変更し、既存の制御を無効にしないでシミュレーション・モードを使用して差異をテスト
-
元のコマンド・ルールを有効にしたまま、コマンド・ルールへの変更を本番でテスト
ユーザーがSQL文を実行し、それが失敗した場合、失敗の原因は有効化されているレルム、シミュレーションされているレルムまたはそれらの両方のいずれかです。必須レルム、通常のレルムまたはその両方が存在する可能性があります。これらの条件によって、シミュレーション・ログに記録されるデータが決まります。
次の各項で説明するユースケースを作成し、通常と必須の両方のタイプのレルムがオブジェクトを保護している場合、通常のレルムは必須レルムによって完全に無力化されます。必須レルムと通常のレルムが同じオブジェクトを保護しているすべてのケースで、シミュレーション・ログに関して通常のレルムを無視できます。必須レルムの失敗のみがシミュレーション・ログに記録されます。通常のレルムの失敗がシミュレーション・ログに記録されるのは、オブジェクトのすべてのレルムが通常のレルムである場合のみとなります。さらに、通常のレルムがシミュレーション・ログに書き込まれるには、次のことに該当する必要があります。
-
シミュレーション・モードの通常のレルムがすべて失敗している。かつ
-
有効化されている通常のレルムもすべて失敗している
有効化されたまたはシミュレーションの通常のレルムが1つ以上成功している場合は、シミュレーションの通常のレルムはいずれもログに記録されません。
親トピック: シミュレーション・モードでのレルムのログ記録
10.3.2 ユースケース: すべての新規レルムがシミュレーション・モード
このユースケースでは、すべてのレルムが必須または通常のいずれかで、ユーザーが作成するレルムはすべてシミュレーション・モードです。
次に例を示します。
-
必須レルムのみで、すべてがシミュレーション・モード
-
ユーザーは、すべての必須レルムでSQL文の実行を認可されます。シミュレーション・ログ表には何も記録されません。
-
ユーザーは、1つ以上の必須レルム・チェックに失敗します。すべてのレルム・チェックの失敗が、シミュレーション・ログに記録されます。ユーザーのSQL文が成功した必須レルム・チェックはログに記録されません。
この例では、3つの必須レルムがあります。ユーザーのSQL文は1つのレルムで成功し、他の2つでは失敗します。シミュレーション・ログには、失敗した2つのレルム・チェックのみが記録されます。
-
-
通常のレルムのみで、すべてがシミュレーション・モード
-
ユーザーは、少なくとも1つの通常のレルムでSQL文の実行を認可されます。ユーザーはデータへのアクセス権があるため、シミュレーション・ログには何も記録されません。
-
ユーザーは、すべての通常のレルムでSQL文の実行を認可されません。シミュレーション・ログには、レルム認可の失敗がすべて記録されます。これにより、ユーザーは、どのレルムでユーザーが認可される必要があるかを選択できます。SQLが機能するには、1つの通常のレルムで認可されることのみが必要となり、SQLを認可するために通常のレルムすべてを更新する必要はありません。
-
-
必須および通常のレルムが混在し、すべてがシミュレーション・モード
-
この場合、ユーザーが拒否されたときに主要レルムを取得します。必須および通常のレルムが混在している場合、必須レルムが主要レルムとなります。ユーザーがアクセス権を取得するには、すべての必須レルムが認可チェックに合格する必要があります。実際は、必須レルムがオブジェクトを保護している場合、通常のレルムは必要ないとみなすことができます。そのため、必須レルムと通常のレルムの両方が同じオブジェクトを保護している場合は、必須レルムのみが、SQL文がブロックされるか実行を許可されるかを制御します。ユーザーが通常のレルムに対して認可されているかどうかは関係ありません。この例では、最初のシナリオである、シミュレーション・モードの必須レルムのルールに従います。
-
ユーザーは、すべての必須レルムでSQL文の実行を認可されます。シミュレーション・ログ表には何も記録されません。ユーザーは1つ以上の通常のレルムで成功する場合も失敗する場合もありますが、通常のレルムの失敗に関しては何も記録されません。
-
ユーザーは、1つ以上の必須レルム・チェックに失敗します。すべてのレルム・チェックの失敗が、シミュレーション・ログに記録されます。ユーザーのSQL文が成功した必須レルム・チェックはログに記録されません。
たとえば、必須レルムが3つあるとします。ユーザーのSQL文は1つのレルムで成功し、他の2つでは失敗します。シミュレーション・ログには、失敗した2つのレルム・チェックのみが記録されます。
シミュレーション・ログに記録する必要があるのは必須レルムのみであるため、通常のレルムを記録する必要はありません。
-
親トピック: シミュレーション・モードでのレルムのログ記録
10.3.3 ユースケース: 既存レルムへの新規レルムの導入
このユースケースでは、既存のレルムを持つデータベースに新規レルムを追加します。
既存のレルムは有効化され、動作しています。新規レルムはシミュレーション・モードになっています。このユースケースは、シミュレーション・モードのレルムと有効化されているレルムの両方が同じオブジェクトを保護している場合にのみ適用されます。
例:
-
シミュレーション・モードの新しい必須レルムと有効化されている既存の必須レルムがあります。このユースケースでは、オブジェクトに対する追加の必須レルムを示します。これにより、既存のオブジェクトのセキュリティが強化されます。
-
有効化されている必須レルムとシミュレーション・モードの必須レルムがすべて、ユーザーのSQL文で成功: この場合、SQLは正常に実行され、何も記録されません
-
有効化されている必須レルム(1つ以上)が失敗し、シミュレーション・モードの必須レルムはすべて成功: SQLがブロックされ、シミュレーション・ログには何も書き込まれません
-
有効化されている必須レルム(1つ以上)が失敗し、シミュレーション・モードの必須レルムの1つ以上が失敗: SQLがブロックされ、失敗したシミュレーション・モードの必須レルムがすべてシミュレーション・ログに書き込まれます
-
有効化されている必須レルムはすべて成功し、シミュレーション・モードの必須レルムの1つ以上が失敗: SQLはブロックされず、失敗したシミュレーション・モードの必須レルムがすべてシミュレーション・ログに書き込まれます
-
-
シミュレーション・モードの新しい通常のレルムと、有効化されている既存の通常のレルムがある場合: 通常のレルムがセキュリティ・オブジェクトに追加され、ユーザーが機密データにアクセスするための新しい方法が提供されます
-
有効化されている通常のレルム(1つ以上)とシミュレーション・モードの通常のレルム(1つ以上)が成功: ユーザーのSQLは正常に実行され、シミュレーション・ログには何も書き込まれません
-
有効化されている通常のレルム(1つ以上)が成功し、シミュレーション・モードの通常のレルムはすべて失敗: ユーザーのSQLは正常に実行され、シミュレーション・ログには何も書き込まれません
-
有効化されている通常のレルムがすべて失敗し、シミュレーション・モードの通常のレルムがすべて失敗: ユーザーのSQLがブロックされ、シミュレーション・モードの通常のレルムがすべてシミュレーション・ログに書き込まれます。必要に応じて、どの通常のレルムを認可するかをユーザーが評価する必要があります。現在の実装では、SQLがブロックされ、シミュレーション・モードの通常のレルムはシミュレーション・ログに追加されません。これは、有効化されている通常のレルムによって、いずれにしろSQLはブロックされるためです。このユースケースでは、ユーザーがSQLを認可するための新しいレルムを追加している可能性があるため、これを変更する必要があります。新しいSQLが、動作したと考えられるものの、シミュレーション・モードの通常のレルムすべてによってブロックされる場合(シミュレーション・モードの通常のレルムのいずれかが、SQLの動作を許可するように設定されている場合)、何が発生したかを確認する方法はありません。これは、この状況での監査ログへの入力と同様です。
-
有効化されている通常のレルムがすべて失敗し、シミュレーション・モードの通常のレルム(1つ以上)が成功: ユーザーのSQLがブロックされ、シミュレーション・ログには書き込まれません。
-
-
新しい通常のレルムと、有効化されている既存の必須レルムがある場合: この状況では何も行う必要はありません。有効化されている必須レルムが引き続きオブジェクトを制御し、シミュレーション・モードの新しい通常のレルムは、有効化されているかどうかに関係なく、影響を及ぼしません。この場合、シミュレーション・ログは生成されません。
-
シミュレーション・モードの新しい必須レルムと、有効化されている既存の通常のレルムがある場合: 現時点では有効化されている通常のレルムがオブジェクトを制御していますが、シミュレーション・モードの新しい必須レルムが有効化されると、それらの必須レルムがオブジェクトを完全に制御するようになり、有効化されている古い通常のレルムによる制御は失われます。そのため、シミュレーション・ログはすべての必須レルムについて作成されます。これは、新しい必須レルムと有効化されている既存の必須レルムがあるシナリオと同じです。
-
シミュレーション・モードの新しい通常のレルムと、有効化されている既存の必須レルムおよび通常のレルムがある場合: 有効化されている必須レルムが、システム内に既存の有効化されている通常のレルムに、シミュレーション・モードの新しい通常のレルムを追加するかどうかを決定するレルムになります。これは、すべてがシミュレーション・モードの必須レルムと通常のレルムが混在しているシナリオと同じです。シミュレーション・ログには何も書き込まれません。
-
シミュレーション・モードの新しい必須レルムと、有効化されている必須レルムおよび通常のレルムがある場合: 有効化されている通常のレルムは無視できます。これは、新しい必須レルムと有効化されている既存の必須レルムがあるシナリオと同じです。
-
シミュレーション・モードの新しい必須レルムおよび通常のレルムと、有効化されている既存の必須レルムおよび通常のレルムが混在している場合: 有効化されている必須レルムと通常のレルムはすべて無視できます。この場合は、単に、既存オブジェクトに必須レルムが追加されます。これは、新しい必須レルムと有効化されている既存の必須レルムがあるシナリオと同じです。
親トピック: シミュレーション・モードでのレルムのログ記録
10.3.4 ユースケース: レルムへの新規オブジェクトの追加のテスト
このユースケースでは、既存のレルムに新規オブジェクトを追加してから、現在のレルム保護を削除せずにシミュレーション・モードを使用してこれをテストします。
同じ認可されたユーザーおよびルール・セットを使用して、新規オブジェクトに対しシミュレーション・モードの重複レルムを作成することをお薦めします。こうすることで、新規オブジェクトのテスト中に、既存のレルムが既存オブジェクトへの保護を提供し続けることができます。
親トピック: シミュレーション・モードでのレルムのログ記録
10.3.5 ユースケース: レルムからのオブジェクトの削除のテスト
このユースケースでは、既存のレルムからのオブジェクトの削除をテストします。
既存オブジェクトに対するセキュリティ制御を削除するため、シミュレーション・モードを使用する必要はありません。単に、オブジェクトをレルムから削除してください。
親トピック: シミュレーション・モードでのレルムのログ記録
10.3.6 ユースケース: 認可されたユーザーのレルムへの追加のテスト
このユースケースでは、ユーザーを追加することでセキュリティ制御を緩和します。単に認可されたユーザーを追加する場合は、何もシミュレートする必要はありません。
レルム内のデータにアクセスする新機能を追加しようとしているが、レルムに対して認可する新規データベース・ユーザーが不明な場合は、単に、新機能をテストとして実行してください(認可されていない場合は、機能がブロックされます)。Database Vault監査ログをレビューして、レルム・データにアクセスしようとしたユーザー名を確認し、新規データベース・ユーザーを認可して追加します。
親トピック: シミュレーション・モードでのレルムのログ記録
10.3.7 ユースケース: 認可されたユーザーのレルムからの削除のテスト
このユースケースでは、認可されたユーザーを削除し、シミュレーション・モードを使用してそのユーザーがまだレルムにアクセスする必要があるかどうかを確認します。
認可されたユーザーが認可されたアクティビティのためにレルムにアクセスしているかどうかを確認する必要があるため、このユーザーを削除してよいか不明な場合があります。
データが通常のレルムによってのみ保護されている場合は、認可されているユーザーのみが異なるレルムのクローンを作成できます。元のレルムから削除対象のユーザーを削除し、このユーザーをレルムのクローンに追加します。次に、audit on success
を取得するようにレルムのクローンの監査設定を変更します。こうすることで、削除したユーザーが一定期間にわたりレルムにアクセスしていた場合、監査レコードにそのユーザーが表示されます。この場合、監査ポリシーも使用できます。必須レルムによって保護されているデータの場合、最適な方法は監査ポリシーを作成することです。
親トピック: シミュレーション・モードでのレルムのログ記録
10.3.8 ユースケース: レルムを使用した新規ファクタのテスト
このユースケースでは、ファクタに対する変更をテストします。
ファクタが変更されるシナリオには、次の2つがあります。
-
アプリケーションまたはインフラストラクチャに対する変更によって、ファクタが強制的に変更される場合
この場合、元のファクタを保持する必要はありません。ただし、新規ファクタのテスト中、オブジェクトおよび認可されたユーザーを有効化されたままにしておくことができる必要があります。有効化されたレルムを使用して、認可されたユーザーからファクタを削除できます。同時に、認可されたユーザーなしで、保護されている同じオブジェクトの必須レルムをシミュレーション・モードで作成します。通常のレルムが認可されていないユーザーからオブジェクトを保護し、シミュレーション・レルムがすべてのアクセスをファクタ情報とともに取得します。ユーザーごとに、シミュレーション・ログを調べてシミュレーション・モードの必須レルムに追加できる新規ファクタを見つけ、元の通常のレルムに移行する前にそのファクタがクリーンであることを確認できます。
-
アプリケーションおよびインフラストラクチャの変更は行われないが、新規ファクタの追加やファクタの削除などの変更は行われる場合
ファクタを追加したら、元のレルムから、新規ファクタが追加された2つ目のシミュレーション・レルムのクローンを作成する必要があります。シミュレーション・ログでファクタの使用に問題がないことが示されている場合は、元のレルムに新規ファクタを安全に導入できます。
ファクタを削除するとセキュリティ・プロファイルが低下するため、単に、ルール・セットからファクタを削除できます。テストを実行する必要はありません。
親トピック: シミュレーション・モードでのレルムのログ記録
10.3.9 ユースケース: 既存のコマンド・ルールへの変更のテスト
このユースケースでは、既存のコマンド・ルールに対する変更を、元のコマンド・ルールを有効にしたままテストします。
コマンド・ルールには更新が必要な場合があり、本番で変更を有効にする前にテストすることが理想的です。既存のコマンド・ルールに追加する新規コマンド・ルールの場合は、作成時にその新規コマンド・ルールをシミュレーション・モードに設定します。その他の既存のコマンド・ルールはすでに有効化され、保護を提供しています。
既存のコマンド・ルールを変更する必要がある場合、既存の保護を保持したまま新しい変更をテストする方法はありません。元のコマンド・ルールの実行内容を取得する監査ポリシーを作成し、それに対するアラートを設定することをお薦めします。監査はコマンド・ルールとは異なり、SQLの実行を阻止しませんが、少なくともアクションに関するアラートを受け取ることはできます。続けて、更新された新しいコマンド・ルールをシミュレーション・モードに設定してテストできます。
親トピック: シミュレーション・モードでのレルムのログ記録
10.4 チュートリアル: シミュレーション・モードの使用によるレルムに対する違反の追跡
このチュートリアルでは、シミュレーション・モードを使用するレルムを作成してから、レルムに対する違反をテストする方法を示します。
- このチュートリアルについて
このチュートリアルでは、HR.EMPLOYEES
表に対するレルムを作成し、それに対する違反をテストします。 - ステップ1: このチュートリアル用のユーザーの作成
このチュートリアル用に3つのユーザーを作成する必要があります。 - ステップ2: レルムおよびOracle Database Vaultポリシーの作成
次に、HR.EMPLOYEES
表の周囲にレルムを作成し、このレルムをOracle Database Vaultポリシーに追加します。 - ステップ3: レルムおよびポリシーのテスト
ユーザーtjones_dba
がレルムに対して違反をコミットし、レルムおよびポリシーをテストします。 - ステップ4: DBA_DV_SIMULATION_LOGビューでの違反の問合せ
これで、ユーザーtjones_dba
が犯した違反のシミュレーション・モード・ログを確認できるようになります。 - ステップ5: レルムの有効化および再テスト
違反を取得したので、ユーザーpsmith
は、HR.EMPLOYEES_pol
ポリシーを更新できます。 - ステップ6: このチュートリアルのコンポーネントの削除
コンポーネントが不要になった場合、このチュートリアルで作成したコンポーネントを削除できます。
10.4.1 このチュートリアルについて
このチュートリアルでは、HR.EMPLOYEES
表に対するレルムを作成し、それに対する違反をテストします。
HR.EMPLOYEES
表には、従業員の給与などの機密データが含まれています。レルムをテストするために、管理者tjones_dba
は、別の従業員smavris
の給与を参照して変更します。Database Vault管理者sec_admin_owen
は、シミュレーション・モードを使用して、HR.EMPLOYEES
表に対する違反を追跡します。これを達成するために、ユーザーsec_admin_owen
は、委任された管理者であるユーザーpsmith
が所有することになる、Database Vaultポリシーを作成します。ユーザーpsmith
は、その後、DV_OWNER
ロールやDV_ADMIN
ロールを必要とせずに、制限された変更をポリシーに加えることができるようになります。
10.4.2 ステップ1: このチュートリアル用のユーザーの作成
このチュートリアル用に3つのユーザーを作成する必要があります
psmith
、HR.EMPLOYEES
表での違反をコミットするtjones_dba
、給与がtjones_dba
の違反を受けるsmavris
となります。
10.4.3 ステップ2: レルムおよびOracle Database Vaultポリシーの作成
次に、HR.EMPLOYEES
表周りのレルムを作成し、このレルムをOracle Database Vaultポリシーに追加します。
10.4.4 ステップ3: レルムおよびポリシーのテスト
ユーザーtjones_dba
がレルムに対して違反をコミットし、レルムおよびポリシーをテストします。
tjones_dba
の違反は、DBA_DV_SIMULATION_LOG
データ・ディクショナリ・ビューに記録されています。
10.4.5 ステップ4: DBA_DV_SIMULATION_LOGビューでの違反の問合せ
これで、ユーザーtjones_dba
が犯した違反のシミュレーション・モード・ログを確認できるようになります。
tjones_dba
が2つの違反をコミットしたことが示されます。まず、別の従業員の給与を参照し、それのみでなく、半分に減らしました。違反タイプはレルム違反です。自分の給与の参照は正当であるため、smavris
による問合せは取得されませんでした。
10.4.6 ステップ5: レルムの有効化および再テスト
違反を取得したので、ユーザーpsmith
は、HR.EMPLOYEES_pol
ポリシーを更新できます。
HR.EMPLOYEES_realm
レルムを有効化できるようにするためです。その後、もう一度違反をテストできます。