データベース管理者は、Oracle Data Pumpなどの製品と連携したDatabase Vaultの使用など、Oracle Database Vault環境で操作を実行できます。
内容は次のとおりです。
Oracle Database Vaultの管理者は、Oracle Enterprise Manager Cloud Controlで、他のデータベースへのポリシー伝播などのタスクを実行することができます。
内容は次のとおりです。
Database VaultポリシーをDatabase Vaultで保護される他のデータベースに伝播できます。
DV_OWNER
またはDV_ADMIN
ロールを付与されているユーザーとして、Cloud ControlからOracle Database Vault Administratorにログインします。
ログイン方法については、「Oracle Database Vaultへのログイン」で説明します。
「Database Vault」ホーム・ページの「ポリシー伝播」で、「Database Vaultポリシー伝播」を選択します。
「ポリシー伝播」サブページの「使用可能なポリシー」領域に、現在のデータベースに作成されたOracle Database Vaultポリシーのサマリーが表示されます。ここから、ポリシーを他のデータベースに伝播できます。
「使用可能なポリシー」で、他のデータベースに伝播する各ポリシーを選択します。
デフォルトでは、すべてのポリシーが選択されています。
「宛先データベース」で「追加」ボタンをクリックします。
「検索と選択: Database Vaultに対応した宛先データベース」で宛先データベースを検索し、ポリシーの伝播先データベースを選択します。「選択」ボタンをクリックします。
「宛先データベース」で次の処理を行います。
「宛先データベースに資格証明を適用」で、伝播するポリシーを含むDatabase Vaultデータベースの管理者のユーザー名とパスワードを入力します。
この機能により、Database Vault管理者のユーザー名とパスワードが、選択したすべての宛先データベースに適用されます。
ポリシーの伝播先データベースを選択します。
各データベースのDatabase Vault管理者のユーザー名とパスワードを入力します。
「Apply」ボタンをクリックします。
「伝播オプション」ページで、次のオプションのオン/オフを選択します。
シードされたレルム、コマンド・ルール、ルール・セットなどに加えられた変更は、宛先データベースに伝播されません。カスタム作成されたデータのみが伝播されます。
失敗時にリストアします。: ポリシーの伝播でエラーが発生した場合に、伝播がロールバックされます。つまり、宛先データベースの元のポリシーがリストアされます。このオプションを選択しない場合、宛先データベースでポリシーの伝播が続けられ、エラーは無視されます。
ユーザー定義ポリシーが存在する場合は、伝播をスキップします。: 宛先データベースにユーザー定義ポリシーがすでにある場合、ポリシーの伝播は試行されません。このオプションを選択しない場合、ユーザー定義ポリシーが宛先データベースにあるかどうかに関係なく、既存のポリシーはすべてクリアされ、ソース・データベースのポリシーが宛先データベースに適用されます。
Database VaultメトリックのEnterprise Managerメトリックしきい値を伝播します。: ソース・データベースにOracle Database Vaultメトリックしきい値が設定されている場合、これらのしきい値も宛先データベースに伝播されます。このオプションを選択しない場合、ポリシーのみが伝播され、Oracle Database Vaultしきい値は伝播されません。
「OK」ボタンをクリックします。
「確認」ウィンドウで「OK」をクリックします。
成功または失敗を示すメッセージが表示されます。伝播が成功した場合、ポリシーは宛先データベースでただちにアクティブになります。
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ポリシー(レルムやコマンド・ルールに対するポリシー)に変更があると、アラートが生成されます。詳細なポリシー変更レポートが提供されます。
Database Vaultホーム・ページから、違反に関する情報を見つけることができます。
これらの違反は、次のとおりです。
レルムおよびコマンド・ルール違反未遂トップ5
データベース・ユーザーおよびクライアント・ホストによる違反未遂トップ5
違反未遂の詳細分析の時系列グラフィック・レポート
Database Vaultレポートの完全なアクセス権を持つには、DV_OWNER
、DV_ADMIN
またはDV_SECANALYST
ロールが付与されたユーザーとしてDatabase Vault Administratorにログインする必要があります。
DBSNMP
ユーザー・アカウントのパスワードを変更するには、あらかじめ、このアカウントからDV_MONITOR
ロールを取り消しておく必要があります。
Oracle Database Vault環境では、DBSNMP
ユーザー・アカウントにはDV_MONITOR
ロールが付与されます。(DBSNMP
ユーザーが自分自身のパスワードを変更する場合は、DV_MONITOR
ロールを取り消さずにすぐに変更できます。)
DV_OWNER
ロールを付与されているアカウントを使用して、データベース・インスタンスにログインします。 DBSNMP
ユーザー・アカウントからDV_MONITOR
ロールを取り消します。DV_ACCTMGR
ロールを付与されているユーザーとして接続し、DBSNMP
ユーザー・アカウントのパスワードを変更します。DV_OWNER
ユーザーとして接続し、DV_MONITOR
ロールをDBSNMP
ユーザー・アカウントに再び付与します。データベース管理者は、Oracle Data PumpユーザーにDatabase Vault環境で作業する認可を付与します。
内容は次のとおりです。
Database Vault環境でOracle Data Pumpを使用するデータベース管理者がデータのエクスポートやインポートを行うには、Database Vault固有の権限が必要です。
これらの管理者は、標準的なOracle Data Pump権限の他に、これらの権限を持っていなければなりません。これらのユーザーがOracle Data Pumpのトランスポータブル表領域操作を実行する場合、特殊な認可が必要です。Oracle Database Vault環境でデータ・ポンプを使用するためにユーザーの認可を確認するには、DVSYS.DBA_DV_DATAPUMP_AUTH
データ・ディクショナリ・ビューを問い合せます。
関連項目:
Oracle Data Pumpの詳細は、『Oracle Databaseユーティリティ』を参照してください。
トランスポータブル表領域の詳細は、『Oracle Database管理者ガイド』を参照してください。
Database Vault環境でOracle Data Pumpのエクスポートおよびインポート操作を行う管理者に対しては、様々なタイプの権限を付与することができます。
内容は次のとおりです。
Oracle Data Pumpの権限を持つユーザーは、Database Vault環境で通常のOracle Data Pump操作を行うことができます。
フルレベルのData Pump権限を付与すると、これらのユーザーは、トランスポータブル・エクスポート/インポート操作も行えるようになります。
関連項目:
トランスポータブル・エクスポートとトランスポータブル・インポートの操作のみをユーザーが実行できるようにしたい場合は、「ユーザーへのData Pumpのトランスポータブル・エクスポート操作およびトランスポータブル・インポート操作の認可」を参照してくださいOracle Database Vaultでは、Database Vault環境でのOracle Data Pumpの通常操作に必要な認可にいくつかのレベルがあります。
表11-1に、これらのレベルを示します。
表11-1 Oracle Data Pumpの通常操作に対する権限のレベル
シナリオ | 必要な権限 |
---|---|
データベース管理者は、データを別のスキーマにインポートします。 |
このユーザーには、 |
データベース管理者は、Database Vault保護なしのスキーマでデータをエクスポートまたはインポートします。 |
このユーザーには、標準のOracle Data Pump権限を付与する必要があります。 |
データベース管理者は、保護スキーマでデータをエクスポートまたはインポートします。 |
ユーザーがデータをインポートする場合は、このユーザーに |
データベース管理者は、データベース全体の内容をエクスポートまたはインポートします。 |
|
脚注1
デフォルトではBECOME USER
権限はIMP_FULL_DATABASE
ロールに含まれますが、Oracle Database Vault環境ではこの権限は取り消されます。
データベース管理者に、Oracle Database Vault環境で通常操作にData Pumpを使用する権限を付与できます。
Oracle Data Pumpのトランスポータブル操作を行う必要のあるユーザーには、異なるレベルの権限を付与することができます。
内容は次のとおりです。
ユーザーには、異なるレベルのトランスポータブル操作権限を付与することができます。
トランスポータブル・エクスポートとトランスポータブル・インポートの操作を実行する権限のみをユーザーに付与する場合は、タスクに基づいて、ユーザーに適切な権限を付与する必要があります。
関連項目:
Databese Vault環境で通常操作を行うユーザーにOracle Data Pumpの権限が必要な場合は、「ユーザーへのData Pumpの通常エクスポート操作および通常インポート操作の認可」も参照してください。Oracle Database Vaultの場合、Database Vault環境でトランスポータブル・エクスポートとトランスポータブル・インポートの操作を実行するユーザーに必要な権限には、いくつかのレベルがあります。
表11-2に、これらのレベルを示します。
表11-2 Oracle Data Pumpのトランスポータブル操作に対する権限のレベル
シナリオ | 必要な権限 |
---|---|
データベース管理者は、Database Vault保護なしの表領域または表のトランスポータブル・エクスポートを実行します。 |
このユーザーには、標準のOracle Data Pump権限を付与する必要があります。 |
データベース管理者は、Database Vault保護ありの表領域のトランスポータブル・エクスポートを実行します(たとえば、その表領域に存在する表オブジェクトのレルムやコマンドルール)。 |
完全データベース・レベルのOracle Data Pump権限を付与されたユーザーも、( |
データベース管理者は、Database Vault保護ありの表領域内で表のトランスポータブル・エクスポートを実行します(たとえば、エクスポートする表を含む表領域に存在する表オブジェクトのレルムやコマンド・ルール)。 |
完全データベース・レベルのOracle Data Pump権限を付与されたユーザーも、( |
データベース管理者は、データベース全体の内容のトランスポータブル・エクスポートを実行します。 |
|
データベース管理者は、ネットワーク・リンクを使用して、Database Vault保護なしの表領域または表のトランスポータブル・インポートを実行します。 |
データベース管理者と接続ユーザー両方の |
データベース管理者は、ネットワーク・リンクを使用して、Database Vault保護ありの表領域のトランスポータブル・インポートを実行します(たとえば、その表領域に存在する表オブジェクトのレルムやコマンド・ルール)。 |
Database Vault固有の完全データベース・レベルのOracle Data Pump権限を付与されたユーザーも、( |
データベース管理者は、ネットワーク・リンクを使用して、Database Vault保護ありのトランスポータブル表領域内で表をインポートします(たとえば、エクスポートする表を含む表領域に存在する表オブジェクトのレルムやコマンド・ルール)。 |
Database Vault固有の完全データベース・レベルのOracle Data Pump権限を付与されたユーザーも、( |
データベース管理者は、ネットワーク・リンクを使用してデータベース全体の内容のトランスポータブル・インポートを実行します。 |
|
ユーザーがDatabase Vault環境でOracle Data Pumpのトランスポータブル・エクスポートおよびインポートを実行することを認可できます。
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 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 Database Vault環境ではRecovery Manager(RMAN)を使用できます。
Oracle Database VaultでRMANを使用する場合の機能は、標準のOracle Database環境での機能と同じです。
関連項目:
『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』
『Oracle Database Recovery Managerリファレンス』
Oracle Database Vault環境でOracle Streamsを使用する場合、適切な権限が必要です。
必要な権限は、次のとおりです。
Oracle Streams取得プロセスを構成するには、DV_STREAMS_ADMIN
ロールが付与されている必要があります。
レルムで保護された表に変更を適用するには、そのレルムへのアクセスが認可されている必要があります。次に例を示します。
EXEC DBMS_MACADM.ADD_AUTH_TO_REALM('realm_name','username');
関連項目:
DV_STREAMS_ADMIN
ロールの詳細は、「DV_STREAMS_ADMIN Oracle Streams構成ロール」を参照してください
DBMS_MACADM.ADD_AUTH_TO_REALM
プロシージャの詳細は、「ADD_AUTH_TO_REALMプロシージャ」を参照してください
Oracle Database Vault環境でOracle Streamsを使用する場合、適切な権限が必要です。
これらの権限は次のとおりです。
XStreamを構成するには、DV_XSTREAM_ADMIN
ロールが付与されている必要があります。
レルムで保護された表に変更を適用するには、そのレルムへのアクセスが認可されている必要があります。次に例を示します。
EXEC DBMS_MACADM.ADD_AUTH_TO_REALM('realm_name','username');
関連項目:
DV_XSTREAM_ADMIN
ロールの詳細は、「DV_XSTREAM_ADMIN XStream管理ロール」を参照してください
DBMS_MACADM.ADD_AUTH_TO_REALM
プロシージャの詳細は、「ADD_AUTH_TO_REALMプロシージャ」を参照してください
Oracle Database Vault環境でOracle GoldenGateを使用する場合、適切な権限が必要です。
これらの権限は次のとおりです。
Oracle GoldenGateを構成するには、DV_GOLDENGATE_ADMIN
ロールが付与されている必要があります。
Oracle GoldenGateのTRANLOGOPTIONS DBLOGREADER
メソッドを使用してREDOログにアクセスするには、DV_GOLDENGATE_REDO_ACCESS
ロールが付与されている必要があります。
レプリケートされた側でユーザーを作成する場合は、DV_ACCTMGR
ロールがあらかじめ付与されていないければなりません。
レルムで保護された表に変更を適用するには、そのレルムへのアクセスが認可されている必要があります。次に例を示します。
EXEC DBMS_MACADM.ADD_AUTH_TO_REALM('realm_name','username');
関連項目:
DV_GOLDENGATE_ADMIN
ロールの詳細は、「DV_GOLDENGATE_ADMIN GoldenGate管理ロール」を参照してください
DV_GOLDENGATE_REDO_ACCESS
ロールの詳細は、「DV_GOLDENGATE_REDO_ACCESS GoldenGate REDOログ・ロール」を参照してください
DBMS_MACADM.ADD_AUTH_TO_REALM
プロシージャの詳細は、「ADD_AUTH_TO_REALMプロシージャ」を参照してください
Oracle Database Vault環境でデータ・マスキングを行うには、適切な権限がなければなりません。
内容は次のとおりです。
関連項目:
データ・マスキングの詳細は、『Oracle Database Testingガイド』を参照してください。
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デフォルト・コンポーネント保護レルムに追加するとデータ・ディクショナリ・レルム認可を付与できます。
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; /
マスクする表またはスキーマへのアクセス権をユーザーに付与するには、適切なレルムに対してユーザーを認可する必要があります。
データ・マスクする表または表のスキーマがレルム内にある場合、データ・マスキングを行うユーザーを参加者または所有者としてレルム認可に追加する必要があります。表またはスキーマに、他のレルムで保護された表内にある依存オブジェクトがある場合、それらのレルムに対する参加者または所有者認可もユーザーに付与する必要があります。
データ・マスクするオブジェクトを保護するレルムに対して、データ・マスキング・ユーザーを認可するには、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環境でデータ・マスキングを使用するには、表、パッケージ、およびトリガの管理権限が必要です。
データ・マスキングを行うには、ユーザーは、マスキング・オブジェクトに対するCREATE TABLE
、SELECT TABLE
、ALTER TABLE
およびDROP TABLE
権限を持っている必要があります。作成する依存オブジェクトがある場合は、CREATE PACKAGE
、CREATE TRIGGER
などの適切な権限を持っている必要があります。
データ・マスキングの権限を粒度レベルで制御するためのコマンド・ルールを作成できます。これを行うには、データ・マスクする必要のあるオブジェクトへのユーザー・アクセスを禁止または許可するコマンド・ルールを作成します。たとえば、ユーザーがデータ・マスキングを行うユーザーのリスト内にあるかどうかをチェックするAllow Data Maskingと呼ばれるコマンド・ルールを作成できます。ログインするユーザーがこれらのユーザーのいずれかの場合、コマンド・ルールはtrueと評価され、ユーザーは、保護されたオブジェクトに対してデータ・マスクを作成することが許可されます。
データ・マスキング権限を制御するコマンド・ルールを作成するには、次の手順を実行します。
リリース12c以降のスタンドアロンのOracle DatabaseはPDBに変換可能で、さらにそのPDBをCDBにプラグインすることができます。