日本語PDF
  1. 管理者ガイド
  2. Oracle Database Vault環境でのDBA操作

12 Oracle Database Vault環境でのDBA操作

データベース管理者は、Oracle Data Pumpなどの製品とのDatabase Vaultの使用など、Oracle Database Vault環境で操作を実行できます。

12.1 Oracle Database VaultでのDDL操作の実行

Oracle Database Vaultでのデータ定義言語(DDL)操作は、スキーマの所有権やパッチ・アップグレードなどの状況による影響を受ける場合があります。

親トピック: Oracle Database Vault 環境でのDBA操作

12.1.1 Oracle Database VaultでのDDL操作の実行に関する制限

Oracle Database Vault構成によっては、DDL操作が制限されてOracle Database Vault環境でDDL認可が必要になる場合があります。

具体的には、次のいずれかの特性を持つスキーマでDDL操作を実行するには、DDL認可が必要です。

  • スキーマが、有効なレルムによって保護されるオブジェクトの所有者である。
  • スキーマが、有効なレルムに直接またはロールを介して認可される。
  • スキーマにオブジェクト権限が直接、または有効なレルムによって保護されているオブジェクトのロールを介して付与される。
  • スキーマにOracle Database Vaultのロールが直接またはロールを介して付与される。

DV_PATCH_ADMINロールを付与されたオブジェクト所有者およびユーザーは、DDL認可要件から除外されます。DBMS_MACADM.AUTHORIZE_DDLプロシージャを使用して、特定のスキーマに対してDDL操作を実行するユーザーを認可できます。ただし、DDL認可では、権限受領者がレルムで保護されたオブジェクトまたはスキーマに対してDDL操作を実行できるわけではありません。このような操作を有効化するには、レルムに対してユーザーを認可する必要があります。この認可を与えられているユーザーについて情報を確認するには、DBA_DV_DDL_AUTHデータ・ディクショナリ・ビューに問い合せます。

Oracle Database VaultがOracle Database 21cより古い以前のリリースからアップグレードされた場合、デフォルトのDDL認可(%, %)が存在する可能性があり、これにより、ユーザーは明示的なDDL認可なしで任意のスキーマに対してDDL操作を実行できます。セキュリティを強化するために、Oracleでは、DBMS_MACADM.UNAUTHORIZE_DDL('%', '%')を実行してデフォルトのDDL認可を削除し、DDL操作を実行する必要があるユーザーにのみ必要なDDL認可を付与することをお薦めします。

関連トピック

親トピック: Oracle Database VaultでのDDL操作の実行

12.1.2 DDL操作におけるDV_PATCH_ADMINロールの影響

DV_PATCH_ADMINロールを付与されたオブジェクト所有者およびユーザーは、DDL認可要件から除外されます。

DBMS_MACADM.AUTHORIZE_DDLプロシージャを使用して、特定のスキーマに対してDDL操作を実行するユーザーを認可できます。ただし、DDL認可では、権限受領者がレルムで保護されたオブジェクトまたはスキーマに対してDDL操作を実行することはできません。このような操作を許可するには、レルムに対してユーザーを認可する必要があります。この認可を与えられているユーザーについて情報を確認するには、DBA_DV_DDL_AUTHデータ・ディクショナリ・ビューに問い合せます。

関連トピック

親トピック: Oracle Database VaultでのDDL操作の実行

12.2 Oracle Database VaultのOracle Enterprise Managerとの使用

Oracle Database Vault管理者は、他のデータベースへのポリシーの伝播など、Oracle Enterprise Manager Cloud Controlでタスクを実行できます。

親トピック: Oracle Database Vault 環境でのDBA操作

12.2.1 「他のデータベースへのOracle Database Vault構成の伝播」

Database Vault構成(レルム構成など)を、Database Vaultで保護された他のデータベースに伝播できます。

  1. DV_OWNERまたはDV_ADMINロールおよびSELECT ANY DICTIONARY権限を付与されているユーザーとして、Cloud ControlからOracle Database Vault Administratorにログインします。ログイン方法については、「Oracle Enterprise Cloud ControlからのOracle Database Vaultへのログイン」を参照してください。

  2. 「Database Vault」ホームページの「Database Vaultポリシー伝播」で、「Database Vaultポリシー伝播」を選択します。

    「ポリシー伝播」サブページの「使用可能なポリシー」領域に、現在のデータベースのために作成されたOracle Database Vault構成(つまり、レルム、コマンド・ルール、ルール・セットおよびセキュア・アプリケーション・ロールのために作成された構成)のサマリーが表示されます。Oracle Database release 12c (12.2)で導入されたOracle Database Vaultポリシーは表示されません。ここから、これらの構成を他のデータベースに伝播できます。

  3. 「使用可能なポリシー」で、他のデータベースに伝播する各構成を選択します。


    policy_propagation122.pngの説明が続きます
    図policy_propagation122.pngの説明

  4. 「宛先データベース」で「追加」ボタンをクリックします。

  5. 「検索と選択: Database Vaultに対応した宛先データベース」で宛先データベースを検索し、構成の伝播先となる各データベースを選択します。「選択」ボタンをクリックします。

  6. 「宛先データベース」で次の処理を行います。

    1. 「宛先データベースに資格証明を適用」で、伝播する構成を含むDatabase Vaultデータベースの管理者のユーザー名とパスワードを入力します。

      この機能により、Database Vault管理者のユーザー名とパスワードが、選択したすべての宛先データベースに適用されます。

    2. 構成の伝播先となる各データベースを選択します。

    3. 各データベースのDatabase Vault管理者のユーザー名とパスワードを入力します。

    4. 「適用」ボタンをクリックします。

  7. 「伝播オプション」ページで、次のオプションのオン/オフを選択します。

    シードされたレルム、コマンド・ルール、ルール・セットなどに加えられた変更は、宛先データベースに伝播されません。カスタム作成されたデータのみが伝播されます。

    • 失敗時にリストアします。: 伝播操作でエラーが発生した場合に、伝播がロールバックされます。つまり、宛先データベースの元のポリシーがリストアされます。このオプションを選択しない場合、宛先データベースでポリシーの伝播が続けられ、エラーは無視されます。

    • ユーザー定義ポリシーが存在する場合は、伝播をスキップします。: 宛先データベースにユーザー定義構成がすでにある場合、伝播操作は試行されません。このオプションを選択しない場合、ユーザー定義ポリシーが宛先データベースにあるかどうかに関係なく、既存の構成はすべてクリアされ、ソース・データベースからの構成が宛先データベースに適用されます。

    • Database VaultメトリックのEnterprise Managerメトリックしきい値を伝播します。: ソース・データベースにOracle Database Vaultメトリックしきい値が設定されている場合、これらのしきい値も宛先データベースに伝播されます。このオプションを選択しない場合、構成のみが伝播され、Oracle Database Vaultしきい値は伝播されません。

  8. 「OK」ボタンをクリックします。

  9. 「確認」ウィンドウで「OK」をクリックします。

    成功または失敗を示すメッセージが表示されます。伝播が成功した場合、構成は宛先データベースでただちにアクティブになります。

親トピック: Oracle Database VaultのOracle Enterprise Managerとの使用

12.2.2 Oracle Database Vaultポリシーに対するEnterprise Manager Cloud Controlアラート

Oracle Database Vaultアラートを表示するには、DV_OWNER、DV_ADMINまたはDV_SECANALYSTロールが付与されている必要があります。

アラートは次のとおりです。

  • Database Vaultレルム違反未遂。このアラートにより、Oracle Database Vaultセキュリティ分析者(DV_SECANALYSTロール)はDatabase Vaultデータベースでの違反試行を監視できます。アラートの影響を受けるレルムを選択し、エラー・コードを使用して様々な試行タイプに基づいてレルムをフィルタリングできます。このメトリックは、メトリックおよびポリシーの設定ページで有効化できます。デフォルトでは、レルム違反未遂は24時間ごとに収集されます。

  • Database Vaultコマンド・ルール違反未遂。このアラートの機能は、対象がコマンド・ルール違反であることを除き、Database Vaultレルム違反未遂と同じです。

  • Database Vaultレルム構成の問題。このメトリックは、レルムの構成を追跡し、構成が正しくない場合にアラートを生成します。このメトリックは、Oracle Database Vaultのインストール時に有効化され、デフォルトで1時間ごとにデータを収集します。

  • Database Vaultコマンド・ルール構成の問題。このアラートの機能は、対象がコマンド・ルールに対する構成変更であることを除き、Database Vaultレルム構成の問題と同じです。

  • Database Vaultポリシー変更。このメトリックでは、Database Vaultポリシー(レルムやコマンド・ルールに対するポリシー)に変更があると、アラートが生成されます。詳細なポリシー変更レポートが提供されます。

親トピック: Oracle Database VaultのOracle Enterprise Managerとの使用

12.2.3 Enterprise Manager Cloud ControlにおけるOracle Database Vault固有レポート

Database Vaultホーム・ページから、違反に関する情報を確認できます。

これらの違反は、次のとおりです。

  • レルムおよびコマンド・ルール違反未遂トップ5

  • データベース・ユーザーおよびクライアント・ホストによる違反未遂トップ5

  • 違反未遂の詳細分析の時系列グラフィック・レポート

Database Vaultレポートの完全なアクセス権を持つには、DV_OWNER、DV_ADMINまたはDV_SECANALYSTロールが付与されたユーザーとしてDatabase Vault Administratorにログインする必要があります。

関連トピック

親トピック: Oracle Database VaultのOracle Enterprise Managerとの使用

12.3 Oracle Database VaultでのOracle Data Pumpの使用

データベース管理者は、Oracle Data PumpユーザーにDatabase Vault環境で作業する認可を付与します。

親トピック: Oracle Database Vault 環境でのDBA操作

12.3.1 Oracle Database VaultでのOracle Data Pumpの使用について

Database Vault環境でOracle Data Pumpを使用しているデータベース管理者には、データのエクスポートおよびインポートのためのDatabase Vault固有の認可が必要です。

このタイプのユーザーは、Oracle Data Pumpの標準の権限に加えて、Database Vault権限を持っている必要があります。これらのユーザーがOracle Data Pumpのトランスポータブル表領域操作を実行する場合、特殊な認可が必要です。DBA_DV_DATAPUMP_AUTHデータ・ディクショナリ・ビューを問い合せることで、Oracle Database Vault環境でのData Pumpの使用に関するユーザーの認可を確認できます。この認可は、個々のユーザーまたはデータベース・ロールに付与できます。

関連項目:

親トピック: Oracle Database VaultでのOracle Data Pumpの使用

12.3.2 ユーザーまたはロールへのData Pumpの通常エクスポート操作および通常インポート操作の認可

Database Vault環境でOracle Data Pumpエクスポート操作およびインポート操作を実行する管理者に、様々なタイプの認可を使用できます。

親トピック: Oracle Database VaultでのOracle Data Pumpの使用

12.3.2.1 Oracle Data Pumpの通常操作のユーザーまたはロールへの認可について

Oracle Data Pump認可を持つユーザーは、Database Vaul環境で通常のOracle Data Pump操作を実行できます。

次のタイプのOracle Data Pump認可を実行できます。

  • 保護されたスキーマおよびオブジェクトをインポートできるようにユーザーまたはロールを認可します
  • ユーザーまたはロールに対して、インポート操作中に行われるアクティビティ(ユーザーの作成、Oracle Database Vaultで保護されたロールおよびシステム権限の付与、特定のOracle Databaseロールの付与、Oracle Databaseシステム権限の付与)の実行を認可します

ノート:

完全レベルData Pump認可では、トランスポータブル・エクスポートおよびインポート操作も実行できます。
12.3.2.2 Oracle Data Pumpの通常操作に対するDatabase Vault権限のレベル

Oracle Database Vaultでは、Database Vault環境でのOracle Data Pumpの通常操作に必要な認可にいくつかのレベルがあります。

表12-1に、これらのレベルを示します。

表12-1 Oracle Data Pumpの通常操作のための認可のレベル

シナリオ 必要な認可

データベース管理者は、データを別のスキーマにインポートします。

このユーザー(またはロール)には、BECOME USERシステム権限とIMP_FULL_DATABASEロールを付与する必要があります。脚注1ユーザーに付与されている権限を確認するには、USER_SYS_PRIVSデータ・ディクショナリ・ビューを問い合せます。

データベース管理者は、Database Vault保護なしのスキーマでデータをエクスポートまたはインポートします。

このユーザー(またはロール)には、標準のOracle Data Pump権限のみを付与する必要があります。これは、EXP_FULL_DATABASEロールとIMP_FULL_DATABASEロールです。ユーザーがデータをインポートする場合は、このユーザーにBECOME USERシステム権限を付与します。

データベース管理者は、保護スキーマでデータをエクスポートまたはインポートします。

EXP_FULL_DATABASEロールとIMP_FULL_DATABASEロールの他に、DBMS_MACADM.AUTHORIZE_DATAPUMP_USERプロシージャを使用してDatabase Vault固有の権限もこのユーザー(またはロール)に付与する必要があります。この認可は、EXPDPとIMPDPの両方のユーティリティに適用されます。後から、DBMS_MACADM.UNAUTHORIZE_DATAPUMP_USERプロシージャを使用してこの権限を取り消すことができます。

ユーザーがデータをインポートする場合は、このユーザーにBECOME USERシステム権限も付与します。

データベース管理者は、データベース全体の内容をエクスポートまたはインポートします。

EXP_FULL_DATABASEロールとIMP_FULL_DATABASEロール、およびDBMS_MACADM.AUTHORIZE_DATAPUMP_USERプロシージャで付与される権限の他に、このユーザー(またはロール)にはDV_OWNERロールも付与する必要があります。ユーザーがデータをインポートする場合は、このユーザーにBECOME USERシステム権限を付与します。

脚注1

デフォルトではBECOME USER権限はIMP_FULL_DATABASEロールに含まれますが、Oracle Database Vault環境ではこの権限は取り消されます。

12.3.2.3 Database VaultにおけるOracle Data Pumpの通常操作をユーザーまたはロールに認可

データベース管理者またはロールに、Oracle Database Vault環境で通常操作にData Pumpを使用することを認可できます。

  1. DV_OWNERまたはDV_ADMINロールを付与されているユーザーとして、データベース・インスタンスにログインします。
  2. 認可を付与するユーザーまたはロールに、Oracle Data Pumpの使用に必要なEXP_FULL_DATABASEおよびIMP_FULL_DATABASEロールが付与されていることを確認します。
    SELECT GRANTEE, GRANTED_ROLE FROM DBA_ROLE_PRIVS WHERE GRANTED_ROLE LIKE '%FULL%';
  3. 保護されたスキーマおよびオブジェクトをインポートするために、このユーザーまたはロールにOracle Database Vaultの認可を付与します。

    たとえば、Data PumpユーザーDP_MGRに、データベース表EMPLOYEESのオブジェクトをエクスポートおよびインポートする権限を付与するには、次のように入力します。 

    EXEC DBMS_MACADM.AUTHORIZE_DATAPUMP_USER('DP_MGR', 'HR', 'EMPLOYEES');

    DP_MGRのアクティビティを特定のスキーマに制限するには、次のプロシージャを入力します。 

    EXEC DBMS_MACADM.AUTHORIZE_DATAPUMP_USER('DP_MGR', 'HR');

    DP_MGR_ROLEロールを付与されているユーザーに、データベース全体のオブジェクトのエクスポートおよびインポートを認可するには、次のように入力します。 

    EXEC DBMS_MACADM.AUTHORIZE_DATAPUMP_USER('DP_MGR_ROLE');

    DBMS_MACADM.AUTHORIZE_DATAPUMP_USERプロシージャの実行後、DBA_DV_DATAPUMP_AUTHデータ・ディクショナリ・ビューに問い合せてユーザーまたはロールの認可を確認できます。

    ユーザーまたはロールに完全な認可を付与した(schema、object、typeおよびactionパラメータに%を使用した)場合は、次のステップを省略できます。ただし、認可が特定のスキーマのみの場合(たとえば、schemaがHRに設定され、残りのパラメータが引き続き%に設定されている場合)は、次のステップを実行する必要があります。

  4. 必要に応じて、インポート操作中に次のアクティビティを実行するようにユーザーまたはロールに認可を付与します。
    1. インポート中にユーザーを作成します。例:
      EXEC DBMS_MACADM.AUTH_DATAPUMP_CREATE_USER('DP_MGR');
    2. インポート中にOracle Database Vaultで保護されたロールおよびシステム権限を付与します。例:
      EXEC DBMS_MACADM.AUTH_DATAPUMP_GRANT('DP_MGR');
    3. インポート中に特定のロールを付与します。例:
      EXEC DBMS_MACADM.AUTH_DATAPUMP_GRANT_ROLE('DP_MGR', 'DBA');
    4. インポート中にシステム権限を付与します。例:
      EXEC DBMS_MACADM.AUTH_DATAPUMP_GRANT_SYSPRIV('DP_MGR');
  5. ユーザーまたはロールがデータベース全体をエクスポートする必要がある場合は、DV_OWNERロールを付与します。
    たとえば、ロールの場合は次のように入力します。
    GRANT DV_OWNER TO DP_MGR_ROLE;
12.3.2.4 ユーザーまたはロールからのOracle Data Pump認可の取消し

通常操作のためにOracle Data Pumpを使用するデータベース管理者またはロールの認可を取り消すことができます。

  1. ユーザーまたはロールにDV_OWNERロールが付与されている場合は、オプションでDV_OWNERロールを取り消します。
    REVOKE DV_OWNER FROM DP_MGR;
  2. DBA_DV_DATAPUMP_AUTHデータ・ディクショナリ・ビューに問い合せて、Oracle Data Pumpの認可が付与されているユーザーまたはロールを確認します。
    SELECT GRANTEE, SCHEMA, OBJECT FROM DBA_DV_DATAPUMP_AUTH;
  3. 前のステップで収集した情報を使用して、DBMS_MACADM.UNAUTHORIZE_DATAPUMP_USERコマンドを作成します。

    たとえば: 

    EXEC DBMS_MACADM.UNAUTHORIZE_DATAPUMP_USER('DP_MGR', 'HR', 'EMPLOYEES');

    この権限取消しが、元の権限付与アクションを補完するものであることを確認します。すなわち、最初にDP_MGRにデータベース全体に対する権限を付与した場合、次のコマンドは機能しません。 

    EXEC DBMS_MACADM.UNAUTHORIZE_DATAPUMP_USER('DP_MGR', 'HR');
EXEC DBMS_MACADM.UNAUTHORIZE_DATAPUMP_USER('DP_MGR', 'HR', 'EMPLOYEES');
  4. インポート操作中にユーザーの作成またはその他のアクティビティを実行する認可をユーザーまたはロールに付与した場合は、これらを取り消します。
    たとえば: 
    EXEC DBMS_MACADM.UNAUTH_DATAPUMP_CREATE_USER('DP_MGR');
EXEC DBMS_MACADM.UNAUTH_DATAPUMP_GRANT('DP_MGR');
EXEC DBMS_MACADM.UNAUTH_DATAPUMP_GRANT_ROLE('DP_MGR', 'DBA');
EXEC DBMS_MACADM.UNAUTH_DATAPUMP_GRANT_SYSPRIV('DP_MGR');

    ユーザーの認可を確認するには、DBA_DV_DATAPUMP_AUTHデータ・ディクショナリ・ビューを問い合せます。

12.3.3 ユーザーまたはロールへのData Pumpのトランスポータブル・エクスポート操作およびトランスポータブル・インポート操作の認可

Oracle Data Pumpのトランスポータブル操作を実行する必要があるユーザーには、直接またはロールを通じて、様々な認可レベルを付与できます。

親トピック: Oracle Database VaultでのOracle Data Pumpの使用

12.3.3.1 Oracle Data Pumpのトランスポータブル操作のユーザーへの認可について

様々なレベルのトランスポータブル操作の認可をユーザーに(直接またはロールを通じて)付与できます。

トランスポータブル・エクスポートとトランスポータブル・インポートの操作を実行する認可のみをユーザーに付与する場合は、タスクに基づいて、ユーザーまたはロールに適切な認可を付与する必要があります。

12.3.3.2 Data Pumpのトランスポータブル操作に対するDatabase Vault権限のレベル

Oracle Database Vaultでは、Database Vault環境でトランスポータブル・エクスポートとトランスポータブル・インポートの操作を実行する必要があるユーザーに必要な認可にいくつかのレベルがあります。

表12-2に、これらのレベルを示します。

表12-2 Oracle Data Pumpのトランスポータブル操作に対する権限のレベル

シナリオ 必要な認可

データベース管理者は、Database Vault保護なしの表領域または表のトランスポータブル・エクスポートを実行します。

このユーザー(またはロール)には、標準のOracle Data Pump権限のみを付与する必要があります。これは、EXP_FULL_DATABASEロールとIMP_FULL_DATABASEロールです。

データベース管理者は、Database Vault保護ありの表領域のトランスポータブル・エクスポートを実行します(たとえば、その表領域に存在する表オブジェクトのレルムやコマンドルール)。

EXP_FULL_DATABASEロールとIMP_FULL_DATABASEロールの他に、DBMS_MACADM.AUTHORIZE_TTS_USERプロシージャを使用してDatabase Vault固有のトランスポータブル表領域の認可もこのユーザー(またはロール)に付与する必要があります。後から、DBMS_MACADM.UNAUTHORIZE_TTS_USERプロシージャを使用してこの権限を取り消すことができます。

完全データベース・レベルのOracle Data Pump権限を付与されたユーザーも、(DBMS_MACADM.AUTHORIZE_DATAPUMP_USERプロシージャを介して)、これらの操作を実行できます。

データベース管理者は、Database Vault保護ありの表領域内で表のトランスポータブル・エクスポートを実行します(たとえば、エクスポートする表を含む表領域に存在する表オブジェクトのレルムやコマンド・ルール)。

EXP_FULL_DATABASEロールとIMP_FULL_DATABASEロールの他に、DBMS_MACADM.AUTHORIZE_TTS_USERプロシージャを使用して、エクスポートされる表を含む表領域に対するDatabase Vault固有のトランスポータブル表領域の認可もこのユーザー(またはロール)に付与する必要があります。

完全データベース・レベルのOracle Data Pump権限を付与されたユーザーも、(DBMS_MACADM.AUTHORIZE_DATAPUMP_USERプロシージャで)、これらの操作を実行できます。

データベース管理者は、データベース全体の内容のトランスポータブル・エクスポートを実行します。

DV_OWNER、EXP_FULL_DATABASE、IMP_FULL_DATABASEの各ロールの他に、DBMS_MACADM.AUTHORIZE_DATAPUMP_USERプロシージャを使用してDatabase Vault固有の完全データベース・レベルのOracle Data Pumpの認可もこのユーザー(またはロール)に付与する必要があります。このユーザーに対してDBMS_MACADM.AUTHORIZE_TTS_USERプロシージャを実行する必要はありません。

データベース管理者は、ネットワーク・リンクを使用して、Database Vault保護なしの表領域または表のトランスポータブル・インポートを実行します。

データベース管理者と接続ユーザー両方のEXP_FULL_DATABASEロールとIMP_FULL_DATABASEロールの他に、ネットワーク・リンクで指定されている接続ユーザー(またはロール)にDV_DATAPUMP_NETWORK_LINKロールも付与する必要があります。

データベース管理者は、ネットワーク・リンクを使用して、Database Vault保護ありの表領域のトランスポータブル・インポートを実行します(たとえば、その表領域に存在する表オブジェクトのレルムやコマンド・ルール)。

EXP_FULL_DATABASEロールとIMP_FULL_DATABASEロールの他に、DBMS_MACADM.AUTHORIZE_TTS_USERプロシージャを使用して、ネットワーク・リンクで指定されている接続ユーザー(またはロール)に、その表領域のDatabase Vault固有トランスポータブル表領域の認可も付与する必要があります。接続ユーザーに、DV_DATAPUMP_NETWORK_LINKロールも付与する必要があります。

Database Vault固有の完全データベース・レベルのOracle Data Pumpの認可を付与されたユーザーも、(DBMS_MACADM.AUTHORIZE_DATAPUMP_USERプロシージャを介して)、これらの操作を実行できます。

データベース管理者は、ネットワーク・リンクを使用して、Database Vault保護ありのトランスポータブル表領域内で表をインポートします(たとえば、エクスポートする表を含む表領域に存在する表オブジェクトのレルムやコマンド・ルール)。

EXP_FULL_DATABASEロールとIMP_FULL_DATABASEロールの他に、DBMS_MACADM.AUTHORIZE_TTS_USERプロシージャを使用して、エクスポートされる表を含む表領域に対するDatabase Vault固有のトランスポータブル表領域の認可も接続ユーザー(またはロール)に付与する必要があります。ネットワーク・リンクで指定されている接続ユーザー(またはロール)に、DV_DATAPUMP_NETWORK_LINKロールも付与する必要があります。

Database Vault固有の完全データベース・レベルのOracle Data Pump権限を付与されたユーザーも、(DBMS_MACADM.AUTHORIZE_DATAPUMP_USERプロシージャを介して)、この操作を実行できます。

データベース管理者は、ネットワーク・リンクを使用してデータベース全体の内容のトランスポータブル・インポートを実行します。

DV_OWNERロールの他に、DBMS_MACADM.AUTHORIZE_DATAPUMP_USERプロシージャを使用してDatabase Vault固有の完全データベース・レベルのOracle Data Pumpの認可も、接続ユーザー(またはロール)に付与する必要があります。このユーザーに対してDBMS_MACADM.AUTHORIZE_TTS_USERプロシージャを実行する必要はありません。ネットワーク・リンクで指定されている接続ユーザー(またはロール)に、DV_DATAPUMP_NETWORK_LINKロールも付与する必要があります。

12.3.3.3 Database VaultにおけるData Pumpのトランスポータブル操作をユーザーまたはロールに認可

ユーザーまたはロールがDatabase Vault環境でOracle Data Pumpのトランスポータブル・エクスポートおよびインポート操作を実行することを認可できます。

  1. DV_OWNERまたはDV_ADMINロールを付与されているユーザーとして、データベース・インスタンスにログインします。
  2. 認可を付与するユーザーまたはロールに、Oracle Data Pumpの使用に必要なEXP_FULL_DATABASEおよびIMP_FULL_DATABASEロールが付与されていることを確認します。
    SELECT GRANTEE, GRANTED_ROLE FROM DBA_ROLE_PRIVS 
 WHERE GRANTED_ROLE LIKE '%FULL%';
  3. トランスポータブル・エクスポートを実行する、またはネットワーク・リンクを使用してデータベースの内容全体のトランスポータブル・インポートを実行する場合は、DBMS_MACADM.AUTHORIZE_DATAPUMP_USERプロシージャを使用して、完全データベース・レベルのOracle Data Pump認可をユーザーまたはロールに付与します。それ以外の場合、このステップは無視してください。

    たとえば:

    EXEC DBMS_MACADM.AUTHORIZE_DATAPUMP_USER('DP_MGR');
  4. Database Vault固有のトランスポータブル表領域認可のみが必要な場合は、このユーザーまたはロールにその認可を付与します。

    たとえば: 

    EXEC DBMS_MACADM.AUTHORIZE_TTS_USER('DP_MGR', 'HR_TS');
  5. トランスポータブル・インポート操作を実行するユーザーが、ネットワーク・リンクを使用して操作を実行する場合は、このユーザーまたはロールにDV_DATAPUMP_NETWORK_LINKロールを付与します。

    たとえば:

    GRANT DV_DATAPUMP_NETWORK_LINK TO DP_MGR;
  6. トランスポータブル・エクスポートを実行するユーザー、またはネットワーク・リンクを使用してデータベース全体のトランスポータブル・インポートを実行する場合は、このユーザーまたはロールにDV_OWNERロールを付与します。
    GRANT DV_OWNER TO DP_MGR;
12.3.3.4 トランスポータブル表領域認可のユーザーまたはロールからの取消し

Data Pumpを使用するデータベース管理者の権限を取り消すことができます。

  1. ユーザーまたはロールにDV_OWNERロールが付与されている場合は、オプションでこのロールを取り消します。
    REVOKE DV_OWNER FROM DP_MGR;
  2. DBA_DV_TTS_AUTHデータ・ディクショナリ・ビューに問い合せて、Oracle Data Pumpの認可が付与されているユーザーまたはロールを確認します。
    SELECT GRANTEE, TSNAME FROM DBA_DV_TTS_AUTH;
  3. 前のステップで収集した情報を使用して、DBMS_MACADM.UNAUTHORIZE_TTS_USER文を作成します。

    たとえば: 

    EXEC DBMS_MACADM.UNUTHORIZE_TTS_USER('DP_MGR', 'HR_TS');
  4. トランスポータブル・エクスポートを実行した、またはネットワーク・リンクを使用してデータベースの内容全体のトランスポータブル・インポートを実行した場合は、完全データベース・レベルのOracle Data Pump認可をユーザーまたはロールから取り消します。

    たとえば:

    EXEC DBMS_MACADM.UNAUTHORIZE_DATAPUMP_USER('DP_MGR');
  5. すでにトランスポータブル・インポート操作を実行したユーザーが、ネットワーク・リンクを使用して操作を実行した場合は、このユーザーまたはロールからDV_DATAPUMP_NETWORK_LINKロールを取り消します。

    たとえば:

    REVOKE DV_DATAPUMP_NETWORK_LINK FROM DP_MGR;

12.3.4 Database Vault環境でのデータのエクスポートまたはインポートのガイドライン

Oracle Data Pumpデータベース管理者に適切な認可を付与すると、必要なエクスポートまたはインポート操作を実行できるようになります。

作業を開始する前に、次のガイドラインに従う必要があります。

  • データベースのデータファイルの完全バックアップを作成します。これにより、新しくインポートしたデータが気に入らなかった場合、容易にデータベースを元の状態に戻すことができます。このガイドラインは、侵入者が自分のポリシーを使用するようにOracle Data Pumpエクスポート・データを変更した場合に特に有用です。

  • 複数のスキーマまたは表をエクスポートおよびインポートする方法を決定します。DBMS_MACADM.AUTHORIZE_DATAPUMP_USERプロシージャでは複数のスキーマまたは表は指定できませんが、次のいずれかの方法でこの作業を行うことできます。

    • それぞれのスキーマまたは表に対してDBMS_MACADM.AUTHORIZE_DATAPUMP_USERプロシージャを実行し、次にEXPDPユーティリティとIMPDPユーティリティのSCHEMASパラメータまたはTABLESパラメータのオブジェクトのリストを指定します。

    • 全データベースのエクスポートまたはインポート操作を実行します。この場合、次のガイドランを参照してください。

  • データベース全体のエクスポートまたはインポート操作を実行する場合は、EXPDPまたはIMPDP FULLオプションをYに設定します。この設定によりDVSYSスキーマが取得されるため、認可したユーザーまたはロールにDV_OWNERロールが付与されていることを確認してください。

次のことに注意してください。

  • Oracle Database Vaultが有効になっている場合、ダイレクト・パス・オプション(direct=y)でレガシーのEXPユーティリティとIMPユーティリティは使用できません。

  • 直接の付与またはロールを介した付与のいずれかによって、DBMS_MACADM.AUTHORIZE_DATAPUMP_USERプロシージャを通じてDatabase Vault固有のOracle Data Pump認可を付与されている、またはDBMS_MACADM.AUTHORIZE_TTS_USERプロシージャを通じてトランスポータブル表領域の認可を付与されているユーザーは、データベース・オブジェクトのエクスポートとインポートを実行できますが、通常はアクセスがないスキーマ表に対するSELECT問合せなど、他のアクティビティは実行できません。同様に、指定されたデータベース・オブジェクト外部のオブジェクトに対してData Pump操作を実行することもできません。

  • データベース全体をエクスポートまたはインポートするユーザーにDV_OWNERロールを付与する必要があります。これは、データベース全体のエクスポートには、Oracle Database Vaultポリシーを格納するDVSYSスキーマへのアクセスが必要になるためです。ただし、DVSYSスキーマ自体をエクスポートすることはできません。Data Pumpは、保護定義のみをエクスポートします。インポート・プロセスを開始する前に、ターゲット・データベースにはDVSYSスキーマが必要であり、Database Vaultが有効になっている必要があります。)逆に、インポートされたポリシーをターゲット・データベースに適用するData Pumpインポート操作では、内部的にDBMS_MACADM PL/SQLパッケージが使用され、ここでData PumpユーザーにDV_OWNERロールが必要になります。

関連項目:

Oracle Data Pumpの詳細は、『Oracle Databaseユーティリティ』を参照してください。

親トピック: Oracle Database VaultでのOracle Data Pumpの使用

12.4 Oracle Database VaultでのOracle Schedulerの使用

データベース・ジョブのスケジュールを担当するユーザーは、Oracle Database Vault固有の認可を有している必要があります。

親トピック: Oracle Database Vault 環境でのDBA操作

12.4.1 Oracle Database VaultでのOracle Schedulerの使用について

付与する必要がある認可レベルは、タスクを実行する管理者のスキーマによって異なります。

次のシナリオが想定されます。

  • 管理者が、独自のスキーマでジョブをスケジュールする場合。スキーマがレルムで保護されている場合を除き、データベース・ジョブをスケジュールする権限が付与されている管理者は、Oracle Database Vault固有の権限がなくても作業を続行できます。スキーマがレルムで保護されている場合は、このユーザーがレルムへのアクセスを許可されていることを確認してください。

  • 管理者は別のスキーマでジョブを実行するが、このジョブでOracle Database Vaultのレルムまたはコマンド・ルールで保護されたオブジェクトにアクセスしない場合。この場合、このユーザーには、ジョブに関連するシステム権限のみが必要で、Oracle Database Vault権限は必要ありません。

  • 管理者がデータベースまたはリモート・データベースの任意のスキーマを含む、他のユーザーのスキーマでジョブを実行する場合。このジョブがOracle Database Vaultレルムまたはコマンド・ルールで保護されているオブジェクトにアクセスする場合、DBMS_MACADM.AUTHORIZE_SCHEDULER_USERプロシージャを使用して、このユーザーにDatabase Vault固有の権限を付与する必要があります。この権限は、バックグラウンド・ジョブおよびフォアグラウンド・ジョブの両方に適用されます。フォアグラウンド・ジョブの場合、権限はジョブを作成または変更した最後のユーザーに適用されます。また、スキーマ所有者(ジョブが作成された保護スキーマ)がレルムに対して認可されていることを確認してください。

    後から、DBMS_MACADM.UNAUTHORIZE_SCHEDULER_USERプロシージャを使用してこの権限を取り消すことができます。スキーマがレルムで保護されていない場合、ユーザーにDBMS_MACADM.AUTHORIZE_SCHEDULER_USERプロシージャを実行する必要はありません。

レルムによって保護されているOracle Schedulerジョブを有効または無効にするには、自身がそのレルムに対して認可されているか(DBMS_MACADM.ADD_AUTH_TO_REALMを使用)、またはジョブ所有者スキーマに対するOracle Scheduler認可(DBMS_MACADM.AUTHORIZE_SCHEDULER_USERを使用)が必要です。

関連トピック

親トピック: Oracle Database VaultでのOracle Schedulerの使用

12.4.2 ジョブ・スケジュール管理者へのDatabase Vaultの認可の付与

Database Vault環境で、ユーザーにデータベース・ジョブをスケジュールする権限を付与できます。

  1. DV_OWNERまたはDV_ADMINロールを付与されているユーザーとして、データベース・インスタンスにログインします。

    これらのどちらかのロールを付与されているユーザーのみ、必要な権限を付与できます。

  2. 権限を付与するユーザーに、データベース・ジョブをスケジュールするシステム権限が付与されていることを確認してください。

    この権限には、CREATE JOB、CREATE ANY JOB、CREATE EXTERNAL JOB、EXECUTE ANY PROGRAM、EXECUTE ANY CLASS、MANAGE SCHEDULERが含まれます。DBAおよびSCHEDULER_ADMINロールがこれらの権限を提供しますが、Oracle Database Vaultが有効な場合、権限はこれらのロールから取り消されます。

    たとえば: 

    SELECT GRANTEE, PRIVILEGE FROM DBA_SYS_PRIVS 
 WHERE PRIVILEGE IN ('CREATE JOB', 'CREATE ANY JOB');
  3. このユーザーにOracle Database Vaultに対する権限を付与します。

    たとえば、ユーザーjob_mgrにデータベースの任意のスキーマのジョブをスケジュールする権限を付与するには、次のようになります。 

    EXEC DBMS_MACADM.AUTHORIZE_SCHEDULER_USER('JOB_MGR');

    オプションで、job_mgrのアクティビティを特定のスキーマに制限することもできます。 

    EXEC DBMS_MACADM.AUTHORIZE_SCHEDULER_USER('JOB_MGR', 'HR');
  4. 次のようにDBA_DV_JOB_AUTHデータ・ディクショナリ・ビューを問い合せることで、ユーザーに権限が付与されていることを確認してください。
    SELECT GRANTEE,SCHEMA FROM DBA_DV_JOB_AUTH WHERE GRANTEE = 'user_name';

関連トピック

親トピック: Oracle Database VaultでのOracle Schedulerの使用

12.4.3 ジョブ・スケジュール管理者からの権限の取消し

ユーザーからデータベース・ジョブをスケジュールする権限を取り消すことができます。

  1. DBA_DV_JOB_AUTHデータ・ディクショナリ・ビューを問い合せて、ユーザーの認可を確認します。
    SELECT GRANTEE, SCHEMA FROM DBA_DV_JOB_AUTH WHERE GRANTEE='username';
  2. 前のステップで収集した情報を使用して、DBMS_MACADM.UNAUTHORIZE_SCHEDULER_USERコマンドを作成します。

    たとえば: 

    EXEC DBMS_MACADM.UNAUTHORIZE_SCHEDULER_USER('JOB_MGR');

    この権限取消しが、元の権限付与アクションを補完するものであることを確認します。すなわち、最初にjob_mgrにデータベース全体に対する権限を付与した場合、次のコマンドは機能しません。 

    EXEC DBMS_MACADM.UNAUTHORIZE_SCHEDULER_USER('JOB_MGR', 'HR');

関連トピック

親トピック: Oracle Database VaultでのOracle Schedulerの使用

12.5 Oracle Database Vaultでの情報ライフサイクル管理の使用

Oracle Database Vault対応データベースで情報ライフサイクル管理操作を実行するユーザーは、これらの操作を実行するために認可を受けている必要があります。

親トピック: Oracle Database Vault 環境でのDBA操作

12.5.1 Oracle Database Vaultでの情報ライフサイクル管理の使用について

Oracle Database Vaultのレルムおよびコマンド・ルールで保護されたオブジェクトに対して情報ライフサイクル管理(ILM)操作を実行する役割を担うユーザーに認可を付与できます。

ユーザーがDatabase Vault対応データベースでのILM操作のために次のSQL文を実行できるようにするには、まずユーザーに認可を与える必要があります。

  • ALTER TABLE

    • ILM

    • FLASHBACK ARCHIVE

    • NO FLASHBACK ARCHIVE

  • ALTER TABLESPACE

    • FLASHBACK MODE

親トピック: Oracle Database Vaultでの情報ライフサイクル管理の使用

12.5.2 ユーザーへのDatabase VaultでのILM操作の認可

ユーザーにOracle Database Vault環境での情報ライフサイクル管理(ILM)操作の実行を認可できます。

  1. DV_OWNERまたはDV_ADMINロールを付与されているユーザーとして、データベース・インスタンスにログインします。
    これらのどちらかのロールを付与されているユーザーのみ、必要な権限を付与できます。
  2. DBMS_MACADM.AUTHORIZE_MAINTENANCE_USERを使用してユーザーに認可を与えます。
    たとえば、HR.EMPLOYEES表でILM操作を実行するための認可をユーザーに与えるには、次のようにします。
    EXEC DBMS_MACADM.AUTHORIZE_MAINTENANCE_USER ('PSMITH', 'HR', 'EMPLOYEES', 'TABLE', 'ILM');

    ユーザーpsmithにデータベース全体のILM認可を与える必要がある場合は、次のようなプロシージャを入力します。 

    EXEC DBMS_MACADM.AUTHORIZE_MAINTENANCE_USER ('PSMITH', '%', '%', '%', '%');
  3. DBA_DV_MAINTENANCE_AUTHデータ・ディクショナリ・ビューを問い合せることで、ユーザーが認可されていることを確認してください。

関連トピック

親トピック: Oracle Database Vaultでの情報ライフサイクル管理の使用

12.5.3 ユーザーからの情報ライフサイクル管理認可の取消し

Oracle Database Vault環境で情報ライフサイクル管理(ILM)操作を実行できないよう、ユーザーから認可を取り消すことができます。

  1. DV_OWNERまたはDV_ADMINロールを付与されているユーザーとして、データベース・インスタンスにログインします。
    これらのどちらかのロールを付与されているユーザーのみ、必要な権限を付与できます。
  2. DBA_DV_MAINTENANCE_AUTHデータ・ディクショナリ・ビューを問い合せて、ILMユーザーに与えられた認可の種類を確認します。
  3. DBMS_MACADM.UNAUTHORIZE_MAINTENANCE_USERを使用してユーザーから認可を取り消します。
    たとえば:
    EXEC DBMS_MACADM.UNAUTHORIZE_MAINTENANCE_USER ('PSMITH', 'HR', '%', 'TABLE', 'ILM');

関連トピック

親トピック: Oracle Database Vaultでの情報ライフサイクル管理の使用

12.6 Oracle Database VaultにおけるOracle Database Replayの使用

データベース管理者は、Oracle Database ReplayユーザーにDatabase Vault環境で作業する認可を付与できます。

親トピック: Oracle Database Vault 環境でのDBA操作

12.6.1 Oracle Database VaultでのDatabase Replayの使用について

Oracle Database Replayでワークロード取得操作およびワークロード・リプレイ操作の両方を実行するDatabase Vault認可をユーザーに付与できます。

親トピック: Oracle Database VaultにおけるOracle Database Replayの使用

12.6.2 ユーザーへのDatabase Replay操作の認可

ワークロード取得操作およびワークロード・リプレイ操作の両方をOracle Database Replayユーザーに認可できます。

親トピック: Oracle Database VaultにおけるOracle Database Replayの使用

12.6.2.1 ユーザーへのワークロード取得操作の認可

Oracle Database Vault環境でOracle Database Replayのワークロード取得操作を実行する認可をユーザーに付与できます。

  1. DV_OWNERまたはDV_ADMINロールを付与されているユーザーとして、データベース・インスタンスにログインします。
    これらのロールのいずれかを付与されているユーザーのみが、この認可を付与できます。
  2. DBMS_MACADM.AUTHORIZE_DBCAPTUREプロシージャを使用して、ユーザーを認可します。
    たとえば:
    EXEC DBMS_MACADM.AUTHORIZE_DBCAPTURE ('PFITCH');
  3. DBA_DV_DBCAPTURE_AUTHデータ・ディクショナリ・ビューを問い合せて、ユーザーが認可されていることを確認します。
12.6.2.2 ユーザーへのワークロード・リプレイ操作の認可

Oracle Database Vault環境でOracle Database Replayのワークロード・リプレイ操作を実行する認可をユーザーに付与できます。

  1. DV_OWNERまたはDV_ADMINロールを付与されているユーザーとして、データベース・インスタンスにログインします。
    これらのロールのいずれかを付与されているユーザーのみが、この認可を付与できます。
  2. DBMS_MACADM.AUTHORIZE_DBREPLAYプロシージャを使用して、ユーザーを認可します。
    たとえば:
    EXEC DBMS_MACADM.AUTHORIZE_DBREPLAY ('PFITCH');
  3. DBA_DV_DBREPLAY_AUTHデータ・ディクショナリ・ビューを問い合せて、ユーザーが認可されていることを確認します。

12.6.3 ユーザーからのDatabase Replay認可の取消し

Oracle Database Replayのワークロード取得操作およびワークロード・リプレイ操作の両方に対する認可を取り消すことができます。

  • ワークロード取得権限の取消し
    ユーザーから認可を取り消して、Oracle Database Vault環境でOracle Database Replayのワークロード取得操作を実行できないようにすることができます。
  • ワークロード・リプレイ権限の取消し
    ユーザーから認可を取り消して、Oracle Database Vault環境でOracle Database Replayのワークロード・リプレイ操作を実行できないようにすることができます。

親トピック: Oracle Database VaultにおけるOracle Database Replayの使用

12.6.3.1 ワークロード取得権限の取消し

ユーザーから認可を取り消して、Oracle Database Vault環境でOracle Database Replayのワークロード取得操作を実行できないようにすることができます。

  1. DV_OWNERまたはDV_ADMINロールを付与されているユーザーとして、データベース・インスタンスにログインします。
    これらのロールのいずれかを付与されているユーザーのみが、この認可を付与できます。
  2. DBA_DV_DBCAPTURE_AUTHデータ・ディクショナリ・ビューを問い合せて、ワークロード取得認可を取り消すユーザーを見つけます。
  3. DBMS_MACADM.UNAUTHORIZE_DBCAPTUREプロシージャを使用して、ユーザーから認可を取り消します。
    たとえば:
    EXEC DBMS_MACADM.UNAUTHORIZE_DBCAPTURE ('PFITCH');
12.6.3.2 ワークロード・リプレイ権限の取消し

ユーザーから認可を取り消して、Oracle Database Vault環境でOracle Database Replayのワークロード・リプレイ操作を実行できないようにすることができます。

  1. DV_OWNERまたはDV_ADMINロールを付与されているユーザーとして、データベース・インスタンスにログインします。
    これらのロールのいずれかを付与されているユーザーのみが、この認可を付与できます。
  2. DBA_DV_DBREPLAY_AUTHデータ・ディクショナリ・ビューを問い合せて、ワークロード・リプレイ認可を取り消すユーザーを見つけます。
  3. DBMS_MACADM.UNAUTHORIZE_DBDBREPLAYプロシージャを使用して、ユーザーから認可を取り消します。
    たとえば:
    EXEC DBMS_MACADM.UNAUTHORIZE_DBREPLAY ('PFITCH');

12.7 Oracle Database Vaultでのプリプロセッサ・プログラムの実行

外部表からプリプロセッサ・プログラムを実行するユーザーには、Oracle Database Vault固有の認可が必要です。

親トピック: Oracle Database Vault 環境でのDBA操作

12.7.1 Oracle Database Vaultでのプリプロセッサ・プログラムの実行について

ユーザーが外部表からプリプロセッサ・プログラムを実行するDatabase Vaultの認可を付与したり、取り消すことができます。

親トピック: Oracle Database Vaultでのプリプロセッサ・プログラムの実行

12.7.2 ユーザーへのプリプロセッサ・プログラム実行の認可

DBMS_MACADM.AUTHORIZE_PREPROCESSORプロシージャは、外部表からプリプロセッサ・プログラムを実行する認可をユーザーに付与します。

  1. DV_OWNERまたはDV_ADMINロールを付与されているユーザーとして、データベース・インスタンスにログインします。
    これらのロールのいずれかを付与されているユーザーのみが、この認可を付与できます。
  2. DBMS_MACADM.AUTHORIZE_PREPROCESSORプロシージャを使用して、ユーザーを認可します。
    たとえば:
    EXEC DBMS_MACADM.AUTHORIZE_PREPROCESSOR ('PFITCH');
  3. DBA_DV_PREPROCESSOR_AUTHデータ・ディクショナリ・ビューを問い合せて、ユーザーが認可されていることを確認します。

親トピック: Oracle Database Vaultでのプリプロセッサ・プログラムの実行

12.7.3 ユーザーからのプリプロセッサ実行認可の取消し

DBMS_MACADM.UNAUTHORIZE_PREPROCESSORプロシージャは、ユーザーから認可を取り消して、Oracle Database Vault環境でユーザーが外部表からプリプロセッサ・プログラムを実行できないようにします。

  1. DV_OWNERまたはDV_ADMINロールを付与されているユーザーとして、データベース・インスタンスにログインします。
    これらのロールのいずれかを付与されているユーザーのみが、この認可を付与できます。
  2. DBMS_MACADM.UNAUTHORIZE_PREPROCESSORプロシージャを使用して、ユーザーから認可を取り消します。
    たとえば:
    EXEC DBMS_MACADM.UNAUTHORIZE_PREPROCESSOR ('PFITCH');
  3. DBA_DV_PREPROCESSOR_AUTHデータ・ディクショナリ・ビューを問い合せて、ユーザーが認可されていないことを確認します。

親トピック: Oracle Database Vaultでのプリプロセッサ・プログラムの実行

12.8 Database Vault操作の制御を使用したローカルPDBデータへのマルチテナント共通ユーザー・アクセスの制限

インフラストラクチャ・データベース管理者などのCDBルート共通ユーザーでPDBアクセスを制御できます。

親トピック: Oracle Database Vault 環境でのDBA操作

12.8.1 Database Vault操作の制御の使用について

共通ユーザーが自律型で通常のクラウドまたはオンプレミス環境でプラガブル・データベース(PDB)のローカル・データにアクセスすることを自動的に制限できます。

これは、CDB共通ユーザーに適用されるOracle Database Vault操作の制御を使用して実現できます。

Database Vault操作の制御は、データベース管理者がCDBルートに高い権限を持つユーザーとしてログインする必要があるが、PDB顧客データにアクセスできない場合に便利です。データベース操作の制御では、PDBデータベース管理者はブロックされません。これらのユーザーをブロックするには、PDBでOracle Database Vaultを有効にし、レルム制御などのDatabase Vault機能を使用してこれらのユーザーをブロックします。

操作の制御では、共通ユーザーがPDBローカル・データ(ローカルPDBユーザーが所有するデータ)にアクセスできない設計になっています。しかし、操作の制御を使用する場合は、アプリケーション・ルート、アプリケーションPDBおよび通常のPDBにある共通ユーザーのオブジェクトのデータに共通ユーザーが引き続きアクセスして、共通の操作を実行する必要があると考えられます。

操作の制御が有効で、Oracle DatabaseインストールでALLOW_COMMON_OPERATIONパラメータを使用できない場合は、PDB、アプリケーション・ルートまたはアプリケーションPDBのローカル・データへの共通ユーザーのアクセスがブロックされます。ただし、CDB$ROOT以外のコンテナ(アプリケーション・ルート、アプリケーションPDBおよび通常のPDB)で次のシナリオが実行された場合、CDBで共通に作成されていないDatabase Vaultレルムおよびコマンド・ルールがデフォルトのDatabase Vaultレルムおよびコマンド・ルールでない場合は無視されます。

  • CDB共通ユーザーが所有するオブジェクトにCDB共通ユーザーがアクセスする。
  • PDB、アプリケーション・ルートまたはアプリケーションPDBにCDB共通ユーザーが接続する。
  • ALTER SYSTEM文またはALTER SESSION文をCDB共通ユーザーが実行する。

最近のOracle Databaseのパッチには、共通ユーザーがPDBの共通ユーザー・オブジェクトにアクセスして共通コマンドを実行できるかどうかを制御するALLOW_COMMON_OPERATIONパラメータが含まれています。ALLOW_COMMON_OPERATIONにより、共通ユーザーのオブジェクトおよび共通の操作コマンドへのアクセス機能が操作の制御から分離され、共通の操作に対してローカルDatabase Vaultの制御を強制するかどうかをユーザーがより柔軟に制御できるようになります。

ALLOW_COMMON_OPERATIONパラメータは、Oracle Databaseリリース19Cに対するパッチとして追加されました。DV_MONITORロールまたはDV_SECANALYSTロールがある場合は、次の問合せを実行して、インストール内にあるかどうかを確認できます。 

SELECT * FROM DVSYS.DBA_DV_COMMON_OPERATION_STATUS;

ALLOW_COMMON_OPERATIONパラメータが存在しない場合は、「ORA-00942: 表またはビューが存在しません。」のエラーになります。ALLOW_COMMON_OPERATIONが存在し、FALSEに設定されている場合は、すべてのDatabase Vaultの制御が操作の制御で尊重されます(無視されません)。そのような場合、PDB Database Vaultの制御で、共通ユーザーのオブジェクトへのアクセスがブロックされ、共通操作もブロックされることがあります。

共通ユーザーまたはアプリケーションがPDBのローカル・データにアクセスする必要があるタスクを実行する必要がある場合、共通ユーザーおよびパッケージに対するDatabase Vault操作の制御の例外リストを作成できます。例外リストに指定する共通ユーザーのタイプの例として、Oracle Textで使用するCTXSYSアプリケーション・アカウントがあります。例外リストでパッケージを指定すると、例外リスト内のユーザーに完全なアクセス権を提供するかわりに、より細かい制御を適用できます。

Database Vault操作の制御を使用する一般的なプロセスは、次のとおりです。

  1. Database Vault操作の制御を有効にして、本番環境に対してこれを有効にしたままにします。
  2. この段階では、Database Vault操作の制御は、PDBでDatabase Vaultが有効になっているかどうかに関係なく、環境内のすべてのPDBに適用されます。
  3. 特定のユーザーとパッケージがPDBのローカル・スキーマにアクセスできるようにするには、これらを例外リストに追加します。ユーザーまたはパッケージにアクセス権が不要になった場合、例外リストから削除できます。たとえば、データベースでOracle Textを使用している場合、CTXSYS管理ユーザー・アカウントおよびパッケージを例外リストに追加できます。

親トピック: Database Vault操作の制御を使用したローカルPDBデータへのマルチテナント共通ユーザー・アクセスの制限

12.8.2 例外リストへの共通ユーザーおよびパッケージの追加の動作

共通ユーザーまたはパッケージを例外リストに追加する前に、特別な要件を満たす必要があります。

パッケージがユーザー・アカウント内の唯一のオブジェクトであり、PDBローカル・データにアクセスする必要がある場合、例外リストにユーザー・パッケージを追加できます。これにより、例外リストに含まれる内容を詳細に制御できます。例外リストに追加する共通ユーザーおよびパッケージの種類は、PDBの機能に必要な種類です。たとえば、Oracle Spatialを使用している場合、例外リストにMDSYSアカウントを追加する必要があります。MDSYSでは、Oracle Spatialの機能用の顧客PDBデータにアクセスする必要があります。

操作の制御の例外リストのPL/SQLプロシージャは、共通ユーザーがPL/SQLプロシージャを実行するためのシステム権限または直接オブジェクト権限を持っている場合は、すべての共通ユーザーが実行できます。(定義者権限プロシージャのみ例外リストに追加でき、実行者権限では追加できません。)

操作の制御の例外リスト(ユーザー、%例外)上のユーザーのみが、PL/SQLプロシージャを変更する権限を持っている場合にのみ、例外リスト上のPL/SQLプロシージャを変更できます。たとえば、プロシージャが操作の制御の例外リストにあるがUser Xが例外リストにない場合、User Xは自身のUser X PL/SQLプロシージャを変更できません。User Yが例外リスト(Y, %)に存在し、User YがUser Xプロシージャを変更する権限を持っている場合、User YはUser Xのプロシージャを変更できます。

共通ユーザーおよびパッケージをDatabase Vault操作の制御の例外リストに追加するには、DBMS_MACADM.ADD_APP_EXCEPTION PL/SQLプロシージャを使用します。既存の例外を確認するには、DBA_DV_APP_EXCEPTIONデータ・ディクショナリ・ビューを問い合せます。

親トピック: Database Vault操作の制御を使用したローカルPDBデータへのマルチテナント共通ユーザー・アクセスの制限

12.8.3 Database Vault操作の制御の有効化

Database Vault操作の制御を有効にするには、DBMS_MACADM.ENABLE_APP_PROTECTION PL/SQLプロシージャを使用します。

マルチテナント本番サーバーに対してDatabase Vault操作の制御を使用する場合、Database Vault操作の制御をフル・タイムで有効にしたままにすることをお薦めします。

ほとんどの場合、特定のPDBだけでなく、CDB全体に対してデータベース操作の制御を有効にします。特定のPDBに対して無効にする必要がある場合(トラブルシューティングの目的など)、PDBでDBMS_MACADM.DISABLE_APP_PROTECTIONプロシージャを実行できます。PDBのトラブルシューティングが終了したら、このトピックの例に示すように、Database Vault操作の制御を再有効化します。
Database Vault操作の制御を有効にする前に、CDBルートでDatabase Vaultを有効にして構成する必要があります。ただし、Database VaultはPDBで有効にする必要はありません。
  1. DV_OWNERロールを付与されている共通ユーザーとしてCDBルートにログインします。
    たとえば:
    sqlplus c##sec_admin_owen_root
Enter password: password
  2. DBMS_MACADM.ENABLE_APP_PROTECTIONプロシージャを実行します。
    • CDB環境内のすべてのPDBに対してDatabase Vault操作を制御するには、次のようにします。 
      EXEC DBMS_MACADM.ENABLE_APP_PROTECTION;
    • 特定のPDBの操作の制御は、トラブルシューティングの理由で無効になっている可能性があります。特定のPBB (HRPDBなど)に対するDatabase Vault操作の制御を再度有効にするには、次のようにします。
      EXEC DBMS_MACADM.ENABLE_APP_PROTECTION ('HRPDB');
この段階で、1つまたはすべてのPDBがDatabase Vault操作の制御に対して有効になります。SYSDBA管理権限を持つユーザーSYSとして接続してからSELECT * FROM DBA_DV_STATUS;問合せを実行すると、確認できます。特定の信頼できる共通ユーザーまたはパッケージがこれらのPDBのローカル・スキーマにアクセスして特定の操作を実行する必要がある場合、DBMS_MACADM.ADD_APP_EXCEPTIONプロシージャを使用して、ユーザーまたはパッケージをDatabase Vault操作の制御の例外リストに追加できます。

関連トピック

親トピック: Database Vault操作の制御を使用したローカルPDBデータへのマルチテナント共通ユーザー・アクセスの制限

12.8.4 例外リストへの共通ユーザーおよびパッケージの追加

PDBローカル・データにアクセスする必要がある共通ユーザーおよびアプリケーションを例外リストに追加できます。

  1. DV_OWNERロールを付与されている共通ユーザーとしてCDBルートにログインします。
    たとえば:
    sqlplus c##sec_admin_owen_root
Enter password: password
  2. 共通ユーザーに指定するパッケージが次の要件を満たしていることを確認します。
    • パッケージは共通ユーザーが所有している必要があります。
    • ユーザーが作成したパッケージは、定義者権限プロシージャを使用して作成する必要があります。

    ユーザーが作成したパッケージの詳細は、DBA_OBJECTSデータ・ディクショナリ・ビューを問い合せると確認できます。

  3. DBMS_MACADM.ADD_APP_EXCEPTIONプロシージャを実行します。
    たとえば:
    DBMS_MACADM.ADD_APP_EXCEPTION ('MDSYS', 'PATCH_APP');

親トピック: Database Vault操作の制御を使用したローカルPDBデータへのマルチテナント共通ユーザー・アクセスの制限

12.8.5 例外リストからの共通ユーザーおよびパッケージの削除

PDBローカル・データにアクセスする必要がなくなったユーザーおよびアプリケーションを例外リストから削除できます。

共通ユーザーおよびパッケージをDatabase Vault操作の制御の例外リストから削除するには、DBMS_MACADM.DELETE_APP_PROTECTION PL/SQLプロシージャを使用できます。既存の例外を確認するには、DBA_DV_APP_EXCEPTIONデータ・ディクショナリ・ビューを問い合せます。
  1. DV_OWNERロールを付与されている共通ユーザーとしてCDBルートにログインします。
    たとえば:
    sqlplus c##sec_admin_owen_root
Enter password: password
  2. DBMS_MACADM.DELETE_APP_EXCEPTIONプロシージャを実行します。
    たとえば:
    DBMS_MACADM.DELETE_APP_EXCEPTION ('MDSYS', 'PATCH_APP');

親トピック: Database Vault操作の制御を使用したローカルPDBデータへのマルチテナント共通ユーザー・アクセスの制限

12.8.6 Database Vault操作の制御の無効化

Database Vault操作の制御を無効にするには、DBMS_MACADM.DISABLE_APP_PROTECTION PL/SQLプロシージャを使用します。

ほとんどの場合は、Database Vault操作の制御を有効にしたままにする必要があります。トラブルシューティングでDatabase Vault操作の制御からPDBを削除する必要がある場合は、PDBに対するDatabase Vault操作の制御を一時的に無効にすることをお薦めします(残りのPDBの運用制御を維持します)。トラブルシューティングが完了したら、Database Vault操作の制御を再度有効にする必要があります。
  1. DV_OWNERロールを付与されている共通ユーザーとしてCDBルートにログインします。
    たとえば:
    sqlplus c##sec_admin_owen_root
Enter password: password
  2. DBMS_MACADM.DISABLE_APP_PROTECTIONプロシージャを実行します。
    • CDB環境内のすべてのPDBに対するDatabase Vault操作の制御を無効にするには、次のようにします。 
      EXEC DBMS_MACADM.DISABLE_APP_PROTECTION;
    • 特定のPBB (HRPDBなど)に対するDatabase Vault操作の制御を無効にするには、次のようにします。
      EXEC DBMS_MACADM.DISABLE_APP_PROTECTION ('HRPDB');

親トピック: Database Vault操作の制御を使用したローカルPDBデータへのマルチテナント共通ユーザー・アクセスの制限

12.9 Oracle Recovery ManagerとOracle Database Vault

Oracle Database Vault環境ではRecovery Manager(RMAN)を使用できます。

Oracle Database VaultでRMANを使用する場合の機能は、標準のOracle Database環境での機能とほぼ同じです。ただし、エクスポート操作を試行する場合、RMANのリカバリ表および表パーティション機能は、レルムで保護された表と連携しないことに注意してください。エクスポート操作を実行するには、全表リカバリを実行してから、Database Vault認可ユーザーが実際に保護されている保護表のエクスポートを実行する必要があります。

表をリカバリしようとしたときにRMANの表および表パーティション・リカバリ機能とレルム保護された表が連携しないことに注意してください。その表をリカバリするには、データベース全体のリカバリを実行してから、Database Vault認可ユーザーが、レルムで保護された表をエクスポートし既存のデータベースにインポートする必要があります。

関連トピック

親トピック: Oracle Database Vault 環境でのDBA操作

12.10 Oracle Database VaultでXStreamを使用するための権限

Oracle Database Vault環境でOracle Streamsを使用する場合、適切な権限が必要です。

これらの権限は次のとおりです。

  • XStreamを構成するには、DV_XSTREAM_ADMINロールが付与されている必要があります。

  • レルムで保護された表に変更を適用するには、そのレルムへのアクセスが認可されている必要があります。たとえば:

    EXEC DBMS_MACADM.ADD_AUTH_TO_REALM('realm_name','username');
  • DBMS_XSTREAM_AUTH.GRANT_ADMIN_PRIVILEGEプロシージャを実行する前に、DV_ACCTMGRロールが付与されている必要があります。

関連トピック

親トピック: Oracle Database Vault 環境でのDBA操作

12.11 Oracle Database VaultでOracle GoldenGateを使用するための権限

Oracle Database Vault環境でOracle GoldenGateを使用する場合、適切な権限が必要です。

これらの権限は次のとおりです。

  • Oracle GoldenGateを構成するには、ユーザーにDV_GOLDENGATE_ADMINロールが付与されている必要があります。

  • ユーザーがOracle GoldenGateのTRANLOGOPTIONS DBLOGREADERメソッドを使用してREDOログにアクセスする必要がある場合は、ユーザーにDV_GOLDENGATE_REDO_ACCESSロールが付与されている必要があります。

    たとえば、DV_GOLDENGATE_ADMINロールとDV_GOLDENGATE_REDO_ACCESSロールをgg_adminというユーザーに付与するには、次のようにします。 

    GRANT DV_GOLDENGATE_ADMIN, DV_GOLDENGATE_REDO_ACCESS TO gg_admin;

  • ユーザーにDV_ACCTMGRロールが付与されていないと、レプリケートされた側でこのユーザーがユーザーを作成することはできません。

  • ユーザーは、手続き型レプリケーションを実行する前に、トリガーなしモードで抽出操作を実行する必要があります。

  • レルムで保護された表に変更を適用するには、そのレルムへのアクセスが認可されている必要があります。たとえば:

    EXEC DBMS_MACADM.ADD_AUTH_TO_REALM('realm_name','username');

  • SYSユーザーは、次のように、SYSTEMスキーマでデータ定義言語(DDL)を実行する認可を与えられている必要があります。 

    EXECUTE DVSYS.DBMS_MACADM.AUTHORIZE_DDL('SYS', 'SYSTEM');

  • ユーザーは、Oracleデフォルト・コンポーネント保護レルムへの認可を与えられている必要があります。たとえば、このレルム認可をgg_adminというユーザーに与えるには、次のようにします。 

    BEGIN
 DVSYS.DBMS_MACADM.ADD_AUTH_TO_REALM(
   REALM_NAME    => 'Oracle Default Component Protection Realm',
   GRANTEE       => 'gg_admin',
   AUTH_OPTIONS  => 1);
END;
/

ノート:

Oracle GoldenGateは、SYS、SYSTEMおよびGoldenGate関連スキーマ内のオブジェクトを問い合せ、更新および管理します。いずれかのスキーマがOracle Database Vaultレルムによって保護されている場合、GoldenGate Extract操作は失敗する可能性があります。Oracle Database Vaultでは、ディクショナリ関連オブジェクトがOracleのデフォルト・コンポーネント保護レルムで保護されます。カスタムOracle Database VaultレルムまたはカスタムOracle Database Vaultコマンド・ルールを使用して、SYSやSYSTEMなどのデフォルト・スキーマを保護しないことをお薦めします。

関連トピック

親トピック: Oracle Database Vault 環境でのDBA操作

12.12 Oracle Database Vault環境でのデータ・マスキングの使用

Oracle Database Vault環境でデータ・マスキングを実行するには、正しい認可が必要です。

親トピック: Oracle Database Vault 環境でのDBA操作

12.12.1 Oracle Database Vaultが有効なデータベースでのデータ・マスキングについて

Oracle Database Vaultが有効なデータベースでは、Database Vaultの認可を受けたユーザーのみがDatabase Vaultで保護されたデータベース・オブジェクトのデータをマスクできます。

Database Vault以外の環境では、SELECT_CATALOG_ROLEおよびDBAロールを付与されたユーザーがデータ・マスキングを行えます。ただし、Database Vaultを使用する場合、ユーザーに追加の権限が必要です。この項では、ユーザーがDatabase Vaultで保護されたオブジェクトのデータをマスクできるようにするために使用できる3つの方法について説明します。

ユーザーに適切な権限がない場合、マスキング定義の作成時またはジョブの実行時に次のエラーが発生します。

ORA-47400: Command Rule violation for string on string 

ORA-47401: Realm violation for string on string. 

ORA-47408: Realm violation for the EXECUTE command 

ORA-47409: Command Rule violation for the EXECUTE command 

ORA-01301: insufficient privileges

親トピック: Oracle Database Vault環境でのデータ・マスキングの使用

12.12.2 データ・ディクショナリ・レルム認可へのデータ・マスキング・ユーザーの追加

データ・マスキング・ユーザーをOracleデフォルト・コンポーネント保護レルムに追加するとデータ・ディクショナリ・レルム認可を付与できます。

Oracleデータ・ディクショナリでは、SYSおよびSYSTEMなどのOracle Databaseカタログ・スキーマへのアクセスが制御されます。(これらのスキーマをすべて示すリストについては、「デフォルトのレルム」を参照)。システム権限およびデータベース管理者ロールを付与する機能も制御されます。ユーザーをOracleデフォルト・コンポーネント保護レルムに追加する場合、これらのユーザーに、Oracleデータ・ディクショナリに関連付けられている権限がすでにあれば、これらのユーザーはDatabase Vault環境で同じ権限を持ちます。したがって、ユーザーをこのレルムに追加する場合、このユーザーが信頼できるユーザーであることを確認します。

  • Oracleデフォルト・コンポーネント保護レルムにユーザーを追加するには、DBMS_MACADM.ADD_AUTH_TO_REALMプロシージャを使用します。

たとえば: 

BEGIN
 DBMS_MACADM.ADD_AUTH_TO_REALM(
  realm_name   => 'Oracle Default Component Protection Realm', 
  grantee      => 'DBA_JSMITH', 
  auth_options => DBMS_MACUTL.G_REALM_AUTH_PARTICIPANT);
END;
/

親トピック: Oracle Database Vault環境でのデータ・マスキングの使用

12.12.3 マスクする表またはスキーマへのアクセス権のユーザーへの付与

マスクする表またはスキーマへのアクセス権をユーザーに付与するには、適切なレルムに対してユーザーを認可する必要があります。

データ・マスクする表または表のスキーマがレルム内にある場合、データ・マスキングを行うユーザーを参加者または所有者としてレルム認可に追加する必要があります。表またはスキーマに、他のレルムで保護された表内にある依存オブジェクトがある場合、それらのレルムに対する参加者または所有者認可もユーザーに付与する必要があります。

  • データ・マスクするオブジェクトを保護するレルムに対して、データ・マスキング・ユーザーを認可するには、DBMS_MACADM.ADD_AUTH_TO_REALMプロシージャを使用します。

次の例では、ユーザーDBA_JSMITHに、Business Apps Realmと呼ばれるレルムで保護されたHR.EMPLOYEES表に対する認可を付与する方法を示します。 

BEGIN
 DBMS_MACADM.ADD_AUTH_TO_REALM(
  realm_name   => 'Business Apps Realm', 
  grantee      => 'DBA_JSMITH', 
  auth_options => DBMS_MACUTL.G_REALM_AUTH_PARTICIPANT;
END;
/

親トピック: Oracle Database Vault環境でのデータ・マスキングの使用

12.12.4 データ・マスキングの権限を制御するコマンド・ルールの作成

Oracle Database Vault環境でデータ・マスキングを使用するには、表、パッケージおよびトリガーを管理する権限が必要です。

データ・マスキングを行うには、ユーザーは、マスキング・オブジェクトに対するCREATE TABLE、SELECT TABLE、ALTER TABLEおよびDROP TABLE権限を持っている必要があります。作成する依存オブジェクトがある場合は、CREATE PACKAGE、CREATE TRIGGERなどの適切な権限を持っている必要があります。

データ・マスキングの権限を粒度レベルで制御するためのコマンド・ルールを作成できます。これを行うには、データ・マスクする必要のあるオブジェクトへのユーザー・アクセスを禁止または許可するコマンド・ルールを作成します。たとえば、ユーザーがデータ・マスキングを行うユーザーのリスト内にあるかどうかをチェックするAllow Data Maskingと呼ばれるコマンド・ルールを作成できます。ログインするユーザーがこれらのユーザーのいずれかの場合、コマンド・ルールはtrueと評価され、ユーザーは、保護されたオブジェクトに対してデータ・マスクを作成することが許可されます。

データ・マスキング権限を制御するコマンド・ルールを作成するには:

  1. ルール・セット・ルールを作成します。

    たとえば: 

    BEGIN
 DBMS_MACADM.CREATE_RULE(
  rule_name  => 'Is HDRISCOLL or DBA_JSMITH User', 
  rule_expr  =>'USER IN(''HDRISCOLL'',''DBA_JSMITH'')';
END;
/
  2. ルール・セットを作成し、ルールを追加します。 
    BEGIN
 DBMS_MACADM.CREATE_RULE_SET(
  rule_set_name    => 'Allow Data Masking', 
  description      => 'Allows users HDRISCOLL and DBA_JSMITH access', 
  enabled          => 'Y',
  eval_options     => 1,
  audit_options    => 1,
  fail_options     => 1,
  fail_message     => 'You do not have access to this object.',
  fail_code        => 20461,
  handler_options  => 0, 
  is_static        => TRUE);
END;
/
BEGIN
 DBMS_MACADM.ADD_RULE_TO_RULE_SET(
  rule_set_name => 'Allow Data Masking', 
  rule_name     => 'Is HDRISCOLL or DBA_JSMITH User'),
  rule_order    => 1);
END;
/
  3. コマンド・ルールを作成し、このルールを追加します。 
    BEGIN
 DBMS_MACADM.CREATE_COMMAND_RULE(
  command         => 'CREATE TABLE', 
  rule_set_name   => 'Allow Data Masking', 
  object_owner    => 'HR', 
  object_name     => 'EMPLOYEES', 
  enabled         => DBMS_MACUTL.G_YES);
END; 
/

親トピック: Oracle Database Vault環境でのデータ・マスキングの使用

12.13 スタンドアロンのOracle DatabaseをPDBに変換してCDBにプラグイン

リリース12c以降のスタンドアロンのOracle DatabaseはPDBに変換可能で、さらにそのPDBはCDBにプラグインできます。

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

    たとえば: 

    sqlplus c##sec_admin
Enter password: password
  2. CONTAINER = CURRENTを指定して、ユーザーSYSにDV_PATCH_ADMINロールを付与します。 
    GRANT DV_PATCH_ADMIN TO SYS CONTAINER = CURRENT;
  3. ルートで、SYSOPERシステム権限を持つユーザーSYSとして接続します。

    たとえば:

    CONNECT SYS AS SYSOPER
Enter password: password
  4. データベースを読取り専用モードで再起動します。

    たとえば:

    SHUTDOWN IMMEDIATE
STARTUP MOUNT
ALTER DATABASE OPEN READ ONLY
  5. Database Vault対応のデータベースに、DV_OWNERロールを持つユーザーとして接続します。

    たとえば:

    CONNECT sec_admin@pdb_name
  6. このデータベースで、ユーザーSYSにDV_PATCH_ADMINロールを付与します。
    GRANT DV_PATCH_ADMIN TO SYS;
  7. オプションで、DBMS_PDB.CHECK_PLUG_COMPATIBILITYファンクションを実行して、切断されたPDBがCDBと互換性があるかどうかを確認します。

    このファンクションを実行する場合は、次のパラメータを設定します。

    • pdb_descr_file: PDBの記述を含むXMLファイルへのフルパスを設定します。

    • store_report: PDBにCDBと互換性がない場合にレポートを生成するかどうかを指定します。レポートを生成する場合はTRUEに、レポートを生成しない場合はFALSEに設定します。生成されたレポートは、PDB_PLUG_IN_VIOLATIONS一時表に格納され、PDBにCDBとの互換性がない場合にのみ生成されます。

    たとえば、/disk1/usr/dv_db_pdb.xmlファイルで記述されているPDBに現在のCDBと互換性があるかどうかを判断するには、次のPL/SQLブロックを実行します。 

    SET SERVEROUTPUT ON
DECLARE
  compatible CONSTANT VARCHAR2(3) := 
    CASE DBMS_PDB.CHECK_PLUG_COMPATIBILITY(
           pdb_descr_file => '/disk1/usr/dv_db_pdb.xml',
           store_report   => TRUE)
    WHEN TRUE THEN 'YES'
    ELSE 'NO'
END;
BEGIN
  DBMS_OUTPUT.PUT_LINE(compatible);
END;
/

    出力がYESの場合はPDBに互換性があり、次のステップに進むことができます。

    出力がNOの場合は、PDBに互換性がありません。PDB_PLUG_IN_VIOLATIONS一時表を調べると、互換性がない理由を確認できます。

  8. PDBを記述するXMLファイルを作成します。

    たとえば:

    BEGIN
  DBMS_PDB.DESCRIBE(
    pdb_descr_file => '/disk1/oracle/dv_db.xml');
END;
/
  9. CREATE PLUGGABLE DATABASE文を実行し、USING句でXMLファイルを指定します。要求された場合には、他の句を指定します。

    たとえば: 

    CREATE PLUGGABLE DATABASE pdb_name AS CLONE USING 'dv_db.xml' NOCOPY;
  10. 作成したPDBに、SYSDBA管理権限を持つユーザーSYSとして接続します。 
    CONNECT SYS@pdb_name AS SYSDBA
  11. noncdb_to_pdb.sqlスクリプトを実行します。
    @$ORACLE_HOME/rdbms/admin/noncdb_to_pdb.sql
  12. このPDBを読取り/書込み制限モードでオープンします。
    ALTER PLUGGABLE DATABASE pdb_name OPEN READ WRITE RESTRICTED;
  13. 次のプロシージャを実行してPDBを同期します。
    EXECUTE DBMS_PDB.SYNC_PDB;
  14. DV_OWNERロールを付与されているユーザーとしてルートに接続します。 
    sqlplus c##sec_admin
Enter password: password
  15. CONTAINER = CURRENTを指定して、ユーザーSYSからDV_PATCH_ADMINロールを取り消します。
    REVOKE DV_PATCH_ADMIN FROM SYS CONTAINER = CURRENT;
  16. Database Vault対応のレガシー・データベースに、SYSOPERシステム権限を持つユーザーSYSとして接続します。
    CONNECT SYS@pdb_name AS SYSOPER
  17. このデータベースを再起動します。

    たとえば:

    SHUTDOWN IMMMEDIATE
STARUP
  18. ユーザーSYSからDV_PATCH_ADMINロールを取り消します。
    REVOKE DV_PATCH_ADMIN FROM SYS;

親トピック: Oracle Database Vault 環境でのDBA操作

12.14 Oracle Database Vault環境でのORADEBUGユーティリティの使用

ORADEBUGユーティリティは、主にOracleサポートがOracle Databaseで生じる問題を診断する場合に使用します。

ユーザーがOracle Database Vaultが有効な環境でORADEBUGユーティリティを実行できるかどうかを制御できます。従来型の監査環境では、AUDIT_SYS_OPERATIONS初期化パラメータをTRUEに設定することで、ORADEBUGの使用を監査できます。統合監査環境では、ORADBUGコマンドが強制的に監査されます。この制御は、特権OSユーザー(Oracleサーバー・プロセスと同じOSユーザーIDを持つOSユーザー)には適用されません。このようなユーザーは他の手段(たとえば、デバッガ)を使用してOracleプロセスを完全に制御および調査できるため、この例外が発生します。
  1. DV_OWNERまたはDV_ADMINロールを付与されているユーザーとして、データベース・インスタンスにログインします。
  2. 必要に応じて、ORADEBUGがすでに無効か有効かを確認します。
    SELECT * FROM DBA_DV_ORADEBUG;
  3. 次のいずれかのプロシージャを実行します。

    • ORADEBUGの使用を無効にするには: 

      EXEC DBMS_MACADM.DISABLE_ORADEBUG;

    • ORADEBUGの使用を有効にするには: 

      EXEC DBMS_MACADM.ENABLE_ORADEBUG;

関連トピック

親トピック: Oracle Database Vault 環境でのDBA操作

12.15 Oracle Database Vault環境でのパッチ操作の実行

ユーザーSYSがOracle Database Vault対応データベースでパッチ操作を実行するには、DV_PATCH_ADMINロールが必要です。

DV_PATCH_ADMINが付与されているユーザーもデータを表示できます。
  1. DV_OWNERまたはDV_ADMINロールを付与されているユーザーとして、CDBまたはアプリケーション・ルートに接続します。
  2. SYSユーザーに、一時的にDV_PATCH_ADMINロールを付与します。
    GRANT DV_PATCH_ADMIN TO SYS CONTAINER=ALL;

    単一のPDBにパッチを適用する場合、すべてのコンテナでDV_PATCH_ADMINをSYSに付与する必要はありません。

  3. SYSユーザーがパッチ操作を実行した後、パッチのreadmeファイルの指示に慎重に従って、ユーザーSYSからDV_PATCH_ADMINを取り消します。
    REVOKE DV_PATCH_ADMIN FROM SYS CONTAINER=ALL;

親トピック: Oracle Database Vault 環境でのDBA操作