1. 管理者ガイド
  2. レルムおよびコマンド・ルール・アクティビティのログ記録のためのシミュレーション・モードの使用

10 レルムおよびコマンド・ルール・アクティビティのログ記録のためのシミュレーション・モードの使用

シミュレーション・モードでは、新規および変更された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 シミュレーション・モードの使用例

シミュレーション・モードは、新しいレルムおよびコマンド・ルールの開発構成をテストするために役立ちます。

使用例を次に示します。

  • アプリケーション認証

    アプリケーションを認証している場合、アプリケーション・テスト環境で、次のようにシミュレーション・モードを使用できます。

    1. アプリケーションのすべてのスキーマを、シミュレーション・モードが有効になっている必須レルムに配置します。

    2. フル・リグレッション・テストを実行します。

    3. DBA_DV_SIMULATION_LOGデータ・ディクショナリ・ビューを問い合せてこれらのスキーマにアクセスできるユーザーを確認することで、シミュレーション・モード・ログを分析します。

    4. レルムを新しい認可で更新し、レルムを有効にします(つまり、シミュレーション・モードは使用しない)。

    5. リグレッション・テストを再実行します。

  • 新しいコマンド・ルールの導入

    Oracle Database Vaultが有効になっている本番データベースでシミュレーション・モードを使用できます。

    1. 新しいコマンド・ルールを、必要な数週間の間、シミュレーション・モードで本番に配置します。

    2. DBA_DV_SIMULATION_LOGを問い合せて、コマンド・ルールが正しく動作しているかどうかを判断することで、シミュレーション・モード・ログを分析します。

    3. 必要に応じて、コマンド・ルールに変更を加えます。

    4. コマンド・ルールを有効にします。

  • シミュレーション・モードでの本番データベースへの新しいレルムの配置。

    この方法は、ルール・セット内の信頼できるパスのルールを設定し、レルムの認可ユーザーを見つけるために必要な、システム・コンテキスト情報を確認するために役立ちます。

    1. レルムを必須モードで作成し、保護されたオブジェクトを追加します。

    2. 認可ユーザーは追加しないでください。

    3. 使用される通常のIPアドレスからアプリケーションおよび開発操作を実行します。

    4. 両方の認可ユーザーのシミュレーション・ログ・ファイル、および信頼できるパスの作成に使用できるシステム・コンテキスト情報を確認します。

    5. 信頼できるパスを作成してから、認可ユーザーを追加します。

    6. シミュレーション・ログをクリアし、アプリケーションおよび開発操作タスクを再度実行します。

    7. 一定期間の経過後、シミュレーション・ログを確認します。すべての制御が正しく更新された場合、シミュレーション・ログは空になっています。シミュレーション・モードでのログ・エントリには、レルムおよびルール・セットに加える必要がある追加変更が示されます。または、ログ・エントリに、悪意ある使用が示される場合があります。

親トピック: レルムおよびコマンド・ルール・アクティビティのログ記録のためのシミュレーション・モードの使用

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 チュートリアル: シミュレーション・モードの使用によるレルムに対する違反の追跡

このチュートリアルでは、シミュレーション・モードを使用するレルムを作成してから、レルムに対する違反をテストする方法を示します。

親トピック: レルムおよびコマンド・ルール・アクティビティのログ記録のためのシミュレーション・モードの使用

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つのユーザーを作成する必要があります

各ユーザーは、Database Vaultポリシー所有者であるpsmith、HR.EMPLOYEES表での違反をコミットするtjones_dba、給与がtjones_dbaの違反を受けるsmavrisとなります。
  1. DV_ACCTMGRロールを付与されているユーザーとして、データベース・インスタンスにログインします。

    たとえば: 

    sqlplus accts_admin_ace
Enter password: password

    マルチテナント環境で、適切なプラガブル・データベース(PDB)にログインする必要があります。たとえば:

    CONNECT accts_admin_ace@hrpdb
Enter password: password

    使用可能なPDBを見つけるには、show pdbsコマンドを実行します。現在のPDBを確認するには、show con_nameコマンドを実行します。

  2. 次のユーザーを作成し、CREATE SESSION権限を付与します。 
    GRANT CREATE SESSION TO psmith IDENTIFIED BY password;
GRANT CREATE SESSION TO tjones_dba IDENTIFIED BY password;
GRANT CREATE SESSION TO smavris IDENTIFIED BY password;

    『Oracle Databaseセキュリティ・ガイド』のガイドラインに従って、安全なパスワードでパスワードを置き換えてください。

  3. DV_OWNERロールを付与されたユーザーとして接続します。
    たとえば:
    CONNECT sec_admin_owen -- Or, sec_admin_owen@hrpdb
Enter password: password
  4. ユーザーpsmithにDV_POLICY_OWNERロールを付与します。これにより、psmithは、Database Vaultポリシーを管理できるようになります。
    GRANT DV_POLICY_OWNER TO psmith;
  5. SYSDBA管理権限を持つユーザーSYSとして接続します。 
    CONNECT SYS AS SYSDBA -- Or, CONNECT SYS@hrpdb AS SYSDBA
Enter password: password
  6. DBAロールをユーザーtjones_dbaに付与します。
    GRANT DBA TO tjones_dba;
  7. HRスキーマ所有者として接続します。
    CONNECT HR -- Or, HR@hrpdb
Enter password: password
  8. HR.EMPLOYEES表に対するSELECT権限をユーザーsmavrisに付与します。
    GRANT SELECT ON HR.EMPLOYEES TO smavris;
この段階で、ユーザーはすべて、適切な権限を作成および付与されています。

親トピック: チュートリアル: シミュレーション・モードの使用によるレルムに対する違反の追跡

10.4.3 ステップ2: レルムおよびOracle Database Vaultポリシーの作成

次に、HR.EMPLOYEES表周りのレルムを作成し、このレルムをOracle Database Vaultポリシーに追加します。

  1. DV_OWNERロールを付与されたユーザーとして接続します。

    たとえば:

    CONNECT sec_admin_owen -- Or, sec_admin_owen@hrpdb
Enter password: password
  2. 次のように、HR.EMPLOYEES表周りのレルムを作成します。

    これらのプロシージャは、HR.EMPLOYEES_realmレルムを作成し、HR.EMPLOYEES表をこのレルムに追加し、HRを所有者として認証し、ユーザーpsmithを参加者として認証して、レルムをシミュレーション・モードに設定します。 

    BEGIN
 DBMS_MACADM.CREATE_REALM(
  realm_name    => 'HR.EMPLOYEES_realm', 
  description   => 'Realm to protect HR.EMPLOYEES', 
  enabled       => DBMS_MACUTL.G_SIMULATION, 
  audit_options => DBMS_MACUTL.G_REALM_AUDIT_FAIL,
  realm_type    => 0);
END; 
/

BEGIN
 DBMS_MACADM.ADD_OBJECT_TO_REALM(
  realm_name   => 'HR.EMPLOYEES_realm', 
  object_owner => 'HR', 
  object_name  => 'EMPLOYEES', 
  object_type  => 'TABLE'); 
END;
/
  3. HR.EMPLOYEES_pol Database Vaultポリシーを作成し、シミュレーション・モードになるよう設定します。

    これらのプロシージャは、HR.EMPLOYEES_polポリシーを作成し、たった今作成したレルムをポリシーに追加してから、ユーザーpsmithをポリシーの所有者として追加します。 

    BEGIN
 DBMS_MACADM.CREATE_POLICY(
  policy_name  => 'HR.EMPLOYEES_pol',
  description  => 'Policy to protect HR.EMPLOYEES',
  policy_state => DBMS_MACADM.G_SIMULATION);
END;
/

BEGIN
 DBMS_MACADM.ADD_REALM_TO_POLICY(
  policy_name  => 'HR.EMPLOYEES_pol',
  realm_name   => 'HR.EMPLOYEES_realm');
END;
/

BEGIN
 DBMS_MACADM.ADD_OWNER_TO_POLICY(
  policy_name  => 'HR.EMPLOYEES_pol',
  owner_name   => 'PSMITH');
END;
/
この時点では、レルムおよびポリシーはテストを受ける準備ができています。

親トピック: チュートリアル: シミュレーション・モードの使用によるレルムに対する違反の追跡

10.4.4 ステップ3: レルムおよびポリシーのテスト

ユーザーtjones_dbaがレルムに対して違反をコミットし、レルムおよびポリシーをテストします。

  1. ユーザーtjones_dbaとして接続します。
    CONNECT tjones_dba -- Or, tjones_dba@hrpdb
Enter password: password
  2. HR.EMPLOYEES表にsmavrisの給与を問い合せます。
    SELECT SALARY FROM HR.EMPLOYEES WHERE EMAIL = 'SMAVRIS';

    次のような出力が表示されます。

        SALARY
----------
      6500
  3. smavrisの給与を半分に減らします。
    UPDATE HR.EMPLOYEES
SET SALARY = SALARY / 2
WHERE EMAIL = 'SMAVRIS';

1 row updated.
  4. ユーザーsmavrisとして接続します。
    CONNECT smavris -- Or, smavris@hrpdb
  5. smavrisの給与を問い合せます。
    SELECT SALARY FROM HR.EMPLOYEES WHERE EMAIL = 'SMAVRIS';

    次のような出力が表示されます。

        SALARY
----------
      3250
この時点では、tjones_dbaの違反は、DBA_DV_SIMULATION_LOGデータ・ディクショナリ・ビューに記録されています。

親トピック: チュートリアル: シミュレーション・モードの使用によるレルムに対する違反の追跡

10.4.5 ステップ4: DBA_DV_SIMULATION_LOGビューでの違反の問合せ

これで、ユーザーtjones_dbaが犯した違反のシミュレーション・モード・ログを確認できるようになります。

  1. DV_OWNERロールを付与されたユーザーとして接続します。
    たとえば:
    CONNECT sec_admin_owen -- Or, leo_dvowner@hrpdb
Enter password: password
  2. DBA_DV_SIMULATION_LOGデータ・ディクショナリ・ビューを問い合せます。
    SELECT USERNAME, COMMAND, SQLTEXT, VIOLATION_TYPE 
FROM DBA_DV_SIMULATION_LOG, TABLE(DBA_DV_SIMULATION_LOG.REALM_NAME) RN 
WHERE RN.COLUMN_VALUE = 'HR.EMPLOYEES_realm';

    次のような出力が表示されます。

    USERNAME
--------------------------------------------------------------------------------
COMMAND
--------------------------------------------------------------------------------
SQLTEXT
--------------------------------------------------------------------------------
VIOLATION_TYPE
--------------------------------------------------------------------------------
TJONES_DBA
UPDATE
UPDATE HR.EMPLOYEES SET SALARY = SALARY / 2 WHERE EMAIL = 'SMAVRIS'
Realm Violation

USERNAME
--------------------------------------------------------------------------------
COMMAND
--------------------------------------------------------------------------------
SQLTEXT
--------------------------------------------------------------------------------
VIOLATION_TYPE
--------------------------------------------------------------------------------
TJONES_DBA
SELECT
SELECT SALARY FROM HR.EMPLOYEES WHERE EMAIL = 'SMAVRIS'
Realm Violation
出力に、ユーザーtjones_dbaが2つの違反をコミットしたことが示されます。まず、別の従業員の給与を参照し、それのみでなく、半分に減らしました。違反タイプはレルム違反です。自分の給与の参照は正当であるため、smavrisによる問合せは取得されませんでした。

親トピック: チュートリアル: シミュレーション・モードの使用によるレルムに対する違反の追跡

10.4.6 ステップ5: レルムの有効化および再テスト

違反を取得したので、ユーザーpsmithは、HR.EMPLOYEES_polポリシーを更新できます。

これは、HR.EMPLOYEES_realmレルムを有効化できるようにするためです。その後、もう一度違反をテストできます。
  1. ユーザーpsmithとして接続します。
    CONNECT psmith -- Or, psmith@hrpdb
Enter password: password
  2. ポリシーを有効になるよう更新します。
    BEGIN
 DBMS_MACADM.UPDATE_POLICY_STATE(
  policy_name   => 'HR.EMPLOYEES_pol',
  policy_state  => 1);
END;
/
  3. ユーザーtjones_dbaとして接続します。
    CONNECT tjones_dba --Or, tjones_dba@hrpdb
  4. smavrisの給与をさらに低く減らすことを試みます。
    UPDATE HR.EMPLOYEES
SET SALARY = SALARY / 2
WHERE EMAIL = 'SMAVRIS';

    次のような出力が表示されます。

    ERROR at line 1:
ORA-01031: insufficient privileges
    ポリシー(現在は有効になっている)により、レルムでHR.EMPLOYEES表を保護できます。smavrisの給与は、これ以上減らせません。

親トピック: チュートリアル: シミュレーション・モードの使用によるレルムに対する違反の追跡

10.4.7 ステップ6: このチュートリアルのコンポーネントの削除

コンポーネントが不要になった場合、このチュートリアルで作成したコンポーネントを削除できます。

  1. DV_OWNERロールを付与されたユーザーとして接続します。
    たとえば:
    CONNECT sec_admin_owen -- Or, leo_dvowner@hrpdb
Enter password: password
  2. HR.EMPLOYEES_pol Database Vaultポリシーを削除します。
    EXEC DBMS_MACADM.DROP_POLICY('HR.EMPLOYEES_pol');
    まずポリシーを削除してからでないと、その内容を削除できません。
  3. HR.EMPLOYEES_realmレルムを削除します。
    EXEC DBMS_MACADM.DELETE_REALM('HR.EMPLOYEES_realm');
  4. 累積されたシミュレーション・モード・ログ・データを削除します。

    シミュレーション・モード・ログではユーザーtjones_dbaに関する情報のみが取得されるため、このユーザーに関連する行のみを削除できます。 

    DELETE FROM DVSYS.SIMULATION_LOG$ WHERE USERNAME = 'TJONES_DBA';
  5. ユーザーHRとして接続します。
    CONNECT HR -- Or, CONNECT HR@hrpdb
Enter password: password
  6. smavrisの給与をその違反前の状態に戻します。
    UPDATE HR.EMPLOYEES
SET SALARY = 6500
WHERE EMAIL = 'SMAVRIS';
  7. DV_ACCTMGRロールを付与されているユーザーとして接続します。

    たとえば:

    CONNECT accts_admin_ace -- Or, accts_admin_ace@hrpdb
Enter password: password
  8. ユーザーpsmith、smavrisおよびtjones_dbaを削除します。
    DROP USER psmith;
DROP USER smavris;
DROP USER tjones_dba;

親トピック: チュートリアル: シミュレーション・モードの使用によるレルムに対する違反の追跡