| Oracle Database Vault管理者ガイド 11gリリース1（11.1） E05797-05 |
|
 戻る |
 次へ |
この章の内容は次のとおりです。
レルムは、指定されたアプリケーションの、保護する必要のあるデータベース・スキーマおよびロールを機能的にグループ化したものです。レルムは、使用するデータベース・オブジェクトの保護ゾーンと考えることができます。スキーマは、表、ビューおよびパッケージなどのデータベース・オブジェクトの論理的な集合で、ロールは権限の集合です。スキーマおよびロールを機能グループに分類することにより、これらのグループに対してシステム権限を使用する権限を制御し、DBAまたはシステム権限を含む多くの権限を持つその他のユーザーによる不正なデータ・アクセスを防ぐことができます。Oracle Database Vaultは、既存のOracleデータベースの任意のアクセス制御モデルをそのまま使用します。レルムおよびコマンド・ルールのどちらの場合も、このモデルの上の層として機能します。
レルムを作成すると、レルムで保護する一連のスキーマ・オブジェクトまたはロール（セキュア・オブジェクト）を登録し、セキュア・オブジェクトにアクセスする一連のユーザーやロールを認可できます。
たとえば、Oracle Database Vaultをインストールすると、レルムを作成して経理部門で使用される既存のデータベース・スキーマをすべて保護できます。レルムに対して認可されていないユーザーは、保護された経理データにシステム権限を使用してアクセスすることを許可されません。
Oracle Database Vaultに作成するレルム上でレポートを実行できます。詳細は、「関連するレポートおよびデータ・ディクショナリ・ビュー」を参照してください。
この章では、Oracle Database Vault Administratorを使用してレルムを構成する方法を説明します。Oracle Database Vaultが提供するPL/SQLインタフェースおよびパッケージを使用してレルムを構成するには、次の章を参照してください。
Oracle Database Vaultには次に示すデフォルトのレルムが用意されています。
Database Vaultアカウント管理: データベース・アカウントおよびデータベース・プロファイルを管理および作成する管理者のレルムを定義します。
Oracleデータ・ディクショナリ: 次のOracle Catalogスキーマのレルムを定義します。
ANONYMOUS |
DBSNMP |
MDSYS |
SYS |
||
BI |
EXFSYS |
MGMT_VIEW |
SYSMAN |
||
CTXSYS |
MDDATA |
OUTLN |
SYSTEM |
このレルムは、システム権限およびデータベース管理者ロールを付与する権限も制御します。
Oracle Database Vault: 構成およびロール情報などのOracle Database Vaultスキーマ（DVSYS、DVFおよびLBACSYS）のレルムを定義します。
Oracle Enterprise Manager: データベース情報にアクセスするためのOracle Enterprise Managerアカウント（SYSMANおよびDBSNMP）のレルムを定義します。
通常、レルムの保護を有効にするには、まずレルムを作成し、レルムを編集してレルム・セキュア・オブジェクト、ロールおよび認可を含めます。「レルム設計のガイドライン」に、レルムの作成に関する注意事項が説明されています。
レルムを作成するには、次のようにします。
Database Vault所有者（DV_OWNER）ロールが付与されているデータベース・アカウントを使用して、Oracle Database Vault Administratorにログインします。
少なくとも、DV_ADMINロールを持っている必要があります。ログイン方法は、「Oracle Database Vault Administratorの起動」で説明されています。
「管理」ページの「Database Vault機能管理」で、「レルム」をクリックします。
「レルム」ページで「作成」をクリックします。
「レルムの作成」ページで、次の設定を入力します。
一般:
名前: レルムの名前を入力します。大/小文字混在で最大で90文字まで入力できます。この属性は必須です。
保護されたアプリケーションの名前をレルム名として使用することをお薦めします（たとえば、人事アプリケーションにhr_appと名付けます）。
説明: レルムの簡単な説明を入力します。説明は大/小文字混在で最大で1024文字まで入力できます。この属性はオプションです。
この説明には、対象となるアプリケーション保護のビジネス目標や、レルムによる保護の重要性を示すその他すべてのセキュリティ・ポリシーを含めることができます。また、レルムに対する権限を持つユーザー名とその目的や、緊急時の認可についても説明できます。
ステータス: 「有効」または「無効」のいずれかを選択し、実行時にレルムを有効または無効にします。レルムはデフォルトでは有効です。この属性は必須です。
監査無効: 監査レコードは作成されません。
失敗時に監査（デフォルト）: 認可されていないユーザーがレルムによって保護されているオブジェクトの変更を試行するというようなレルム違反が発生した場合に、監査レコードが作成されます。
成功時または失敗時に監査: アクティビティが認可されている場合でも認可されていない場合でも、レルム内で発生したすべてのアクティビティに関する監査レコードが作成されます。
「OK」をクリックします。
作成した新しいレルムがリストされたレルムのサマリー・ページが表示されます。
新しいレルムを作成したら、そのレルムにレルムで保護するスキーマやデータベース・オブジェクトを追加し、アクセスするユーザーやロールを認可できます。これを実行するには、新しいレルムを編集し、オブジェクトおよび認可されたユーザーを追加します。
Oracle Database Vaultの「管理」ページで、「レルム」を選択します。
「レルム」ページで編集するレルムを選択します。
「編集」をクリックします。
必要に応じてレルムを編集し、「OK」をクリックします。
|
関連項目:
|
レルム・セキュア・オブジェクトは、レルムが保護する領域を定義します。レルムの領域は、一連のスキーマ、データベース・オブジェクトおよびロールです。次のような保護方法があります。
複数のデータベース・アカウントまたはスキーマのオブジェクトを同じレルムに追加できます。
1つのオブジェクトは複数のレルムに属することができます。
オブジェクトが複数のレルムに属する場合、Oracle Database Vaultはアクセス権があるかどうかレルムをチェックします。SELECT、DDLおよびDML文では、ユーザーがいずれかのレルムの参加者で、コマンド・ルールで許可されれば、そのユーザーが入力するコマンドは許可されます。複数のレルムにおけるデータベース・ロールによるGRANTおよびREVOKE操作の場合、GRANTまたはREVOKE操作を実行するユーザーはレルムの所有者である必要があります。
レルムによって保護されているオブジェクトは「レルムの編集」ページから管理できます。このページでは、レルム・セキュア・オブジェクトを作成、編集および削除できます。
レルム・セキュア・オブジェクトを作成するには、次のようにします。
Oracle Database Vaultの「管理」ページで、「レルム」を選択します。
「レルム」ページで必要なレルムを選択し、「編集」を選択します。
「レルムの編集」ページの「レルム・セキュア・オブジェクト」で、次のいずれかを実行します。
新しいレルム・セキュア・オブジェクトを作成するには、「作成」を選択します。
既存のオブジェクトを変更するには、リストからオブジェクトを選択して「編集」を選択します。
「レルム・セキュア・オブジェクトの作成」ページで、次の設定を入力します。
オブジェクト・タイプ: リストから、TABLE、INDEXまたはROLEなどのデータベース・オブジェクトのオブジェクト・タイプを選択します。この属性は必須です。
デフォルトで、「オブジェクト・タイプ」ボックスには%ワイルドカード文字が入力されており、指定されたオブジェクト所有者にすべてのオブジェクト・タイプを含めることができます。ただし、データベースに特定のスキーマ所有者がいないロールは含まれず、明示的に指定する必要があります。
オブジェクト名: レルムが保護するデータベースのオブジェクト名を入力するか、%を入力して指定したオブジェクト所有者のすべてのオブジェクト（ロールを除く）を指定します。ただし、ワイルドカード文字とテキストを使用して複数のオブジェクト名を指定することはできません。たとえば、EMP_%と入力して、文字EMP_で始まるすべての表を指定することはできません。また、ワイルドカード文字を使用して複数のロールを選択することもできません。ロール名は個々に入力する必要があります。この属性は必須です。
デフォルトで、「オブジェクト名」フィールドには%ワイルドカード文字が入力されており、指定されたオブジェクト・タイプおよびオブジェクト所有者のすべてのオブジェクトを含めることができます。%ワイルドカード文字は、現在存在するオブジェクトだけでなく、まだ存在していないオブジェクトにも適用されることに注意してください。また、%ワイルドカード文字はロールには適用されないことにも注意してください。複数のロールを含める場合は、各ロールを別々に指定する必要があります。
「OK」をクリックします。
たとえば、HRスキーマのEMPLOYEES表を保護するには、「レルム・セキュア・オブジェクトの作成」ページに次の設定を入力します。
オブジェクト所有者: HR
オブジェクト・タイプ: TABLE
オブジェクト名: EMPLOYEES
レルム・セキュア・オブジェクトの編集
レルム・セキュア・オブジェクトを編集するには、次のようにします。
「レルムの編集」ページの「レルム・セキュア・オブジェクト」で、オブジェクトを選択します。
「編集」をクリックします。
「レルム・セキュア・オブジェクトの編集」ページで、必要に応じて属性を編集します。
「OK」をクリックします。
レルム・セキュア・オブジェクトの削除
レルム・セキュア・オブジェクトを削除するには、次のようにします。
「レルムの編集」ページの「レルム・セキュア・オブジェクト」で、オブジェクトを選択します。
「削除」をクリックします。
確認ページが表示されます。
「はい」をクリックします。
これによりオブジェクトがレルムから除外され保護されなくなります。（通常のデータベース保護は適用されています。）ただし、オブジェクトはデータベースからは削除されません。
レルム認可では、レルムで保護されているオブジェクトの管理またはアクセスを実行する一連のデータベース・アカウントおよびロールを決定します。レルム認可は、次の状況におけるシステム権限の使用を認可されたアカウントまたはロールです。
レルム・セキュア・オブジェクトの作成またはレルム・セキュア・オブジェクトへのアクセスが必要な場合
レルム・セキュア・ロールを付与または取り消す必要がある場合
レルム所有者またはレルム参加者としてレルム認可を付与されたユーザーは、システム権限を使用してレルム内のセキュア・オブジェクトにアクセスできます。
次の点に注意してください。
ここで設定する認可は、レルムによって保護されているデータベース・オブジェクトへの通常の直接オブジェクト権限を持つ一般ユーザーには影響しません。
レルム所有者は、自分のレルムに他のユーザーを所有者または参加者として追加できません。DV_OWNERまたはDV_ADMINロールのあるユーザーのみ、所有者または参加者としてユーザーをレルムに追加できます。
レルム参加者ではなくレルム所有者は、任意のユーザーに対してレルム・セキュア・データベース・ロールの付与または取消しを実行できます。
ユーザーはレルム所有者またはレルム参加者のいずれかとして付与されますが、両方を付与されることはありません。ただし、レルム認可の認可オプションは更新できます。
「レルムの編集: HR Realm」ページを使用して、レルム認可を管理します。レルム認可を作成、編集および削除できます。レルム認可の構成情報を追跡する場合は、「「レルム認可構成の問題」レポート」を参照してください。
Oracle Database Vaultの「管理」ページで、「レルム」を選択します。
「レルム」ページで必要なレルムを選択し、「編集」を選択します。
「レルムの編集」ページの「レルム認可」で、次のいずれかを実行します。
新しいレルム認可を作成するには、「作成」を選択します。
既存のレルム認可を変更するには、リストからレルム認可を選択して「編集」を選択します。
「レルムの編集」ページの「レルム認可」で、「作成」をクリックします。
「レルム認可の作成」ページで、次の設定を入力します。
権限受領者: リストから、レルム認可を付与するOracleデータベース・アカウントまたはロールを選択します。この属性は必須です。
このリストには、システム権限のあるアカウントのみでなく、システム内のすべてのアカウントおよびロールが表示されます。
このリストからユーザー自身（つまり、ログインしたユーザー）を選択することや、DV_ADMIN、DV_OWNERまたはDV_SECANALYSTのロールを付与されているアカウントを選択することはできません。
認可タイプ: 次のいずれかを選択します。この属性は必須です。
参加者（デフォルト）: 権限が標準のOracle Database権限付与プロセスを使用して付与されている場合、このアカウントまたはロールは、レルムで保護されているオブジェクトに対するアクセス、操作および作成を行うためのシステム権限または直接権限を付与できます。1つのレルムに複数の参加者を設定できます。
所有者: このアカウントまたはロールには、レルムの参加者と同じ権限と、レルム・セキュア・データベース・ロールを付与または取り消す認可があります。1つのレルムに複数の所有者を設定できます。
認可ルール・セット: に作成された使用可能なルール・セットから選択します。選択できるのは1つのルール・セットのみですが、ルール・セットには複数のルールがあります。
ルールを定義することによるレルム認可の制御の詳細は、「ルール・セットに追加するルールの作成」を参照してください。
ルール・セットに関連付けられている監査およびカスタム・イベント処理は、レルム認可処理の一部として発生します。
「OK」をクリックします。
レルム認可の編集
「レルムの編集」ページの「レルム認可」で、レルム認可を選択します。
「編集」をクリックします。
「レルム認可の編集」ページが表示されます。
必要に応じて属性を編集します。
「OK」をクリックします。
レルム認可の削除
「レルムの編集」ページの「レルム認可」で、レルム認可を選択します。
「削除」をクリックします。
確認ページが表示されます。
「はい」をクリックします。
デフォルトで、レルムの作成時にはレルムは有効になります。たとえば、パッチ更新などのシステム・メンテナンスのためにレルムを無効にし、後から再度有効にできます。
レルムを無効または有効にするには、次のようにします。
Oracle Database Vaultの「管理」ページで、「レルム」を選択します。
「レルム」ページで無効または有効にするレルムを選択し、「編集」を選択します。
「レルムの編集」ページの「一般」セクションにある「ステータス」で、「無効」または「有効」を選択します。
「OK」をクリックします。
レルムを削除する前に、それに関連するOracle Database Vaultビューに問い合せることで、そのレルムへの様々な参照を特定できます。詳細は、「Oracle Database Vaultのデータ・ディクショナリ・ビュー」を参照してください。
Oracle Database Vaultの「管理」ページで、「レルム」を選択します。
「レルム」ページで削除するレルムを選択し、「削除」を選択します。
「確認」ページで「はい」をクリックします。
Oracle Database Vaultにより、レルムの構成（ヘッダー、セキュア・オブジェクトおよび認可）が削除されます。レルム内のルール・セットは削除されません。
適切な権限を持つデータベース・アカウントにより、カスタマ定義レルム内のオブジェクトに影響するSQL文（つまりDDL、DML、EXECUTE、GRANT、REVOKEまたはSELECT）が発行されると、次のアクションが発生します。
データベース・アカウントで、システム権限を使用してSQL文を実行しますか。
実行する場合は、手順2に進みます。当てはまらない場合は、手順6に進みます。セッションが、対象となるオブジェクトに対して、SELECT、EXECUTEおよびDMLのオブジェクト権限しか持っていない場合、レルム保護は実施されません。レルムは、レルムで保護されているオブジェクトまたはロールに対するシステム権限の使用を保護します。
O7_DICTIONARY_ACCESSIBILITY初期化パラメータがTRUEに設定されている場合は、SYS以外のユーザーがSYSスキーマ・オブジェクトにアクセスできることに留意してください。セキュリティ強化のために、O7_DICTIONARY_ACCESSIBILITYがFALSEに設定されていることを確認してください。
SQL文はレルムによって保護されているオブジェクトに影響しますか。
影響する場合は、手順3に進みます。影響しない場合は、レルムもSQL文には影響しないため、手順6に進みます。コマンドによって影響されるオブジェクトがレルムで保護されていない場合、レルムも実行されるSQL文には影響しません。
データベース・アカウントは、レルム所有者またはレルム参加者ですか。
いずれかであり、コマンドがレルムで保護されているロールのGRANTかREVOKEである場合、またはレルムで保護されているオブジェクトに対するGRANTかREVOKEである場合、セッションは直接またはレルム内の保護されているロールを介して間接的にレルム所有者として認可されている必要があります。いずれかである場合は、手順4に進みます。いずれでもない場合は、レルム違反が発生し、文は失敗します。SYSはデフォルトのOracleデータ・ディクショナリ・レルムで唯一のレルム所有者であり、SYSのみがデータベース・アカウントまたはロールにシステム権限を付与できることに注意してください。
データベース・アカウントに対するレルム認可は、状況に応じてルール・セットに基づきますか。当てはまる場合は、手順5に進みます。当てはまらない場合は、手順6に進みます。
ルール・セットの評価はTrueですか。
当てはまる場合は、手順6に進みます。そうでない場合は、レルム違反が発生し、SQL文は失敗します。
コマンド・ルールでコマンドの実行が阻止されますか。阻止される場合は、コマンド・ルール違反が発生しSQL文は失敗します。阻止されない場合は、レルム違反もコマンド・ルール違反も発生しないため、コマンドは成功します。
たとえば、HRアカウントにDROP ANY TABLE権限があり、HRレルムの所有者であるとしても、月ごとのメンテナンスの時間帯でないかぎり、コマンド・ルールでHRによるHRスキーマの任意の表の削除を阻止できます。コマンド・ルールは、直接オブジェクト権限だけでなくANYシステム権限の使用にも適用され、レルム・チェック後に評価されます。
また、セッションはレルム内で認可されるため、アカウントはレルムによって保護されているオブジェクトに対する任意の権限を使用できるというわけではありません。たとえば、アカウントまたはロールにSELECT ANY表権限があり、HRレルムの参加者であるとします。これは、そのアカウントまたはロールが付与されているアカウントによる、HR.EMPLOYEES表への問合せが可能であることを意味します。レルムの参加者であることは、そのアカウントまたはロールでHR.EMPLOYEES表を削除できるということではありません。Oracle Database Vaultは、既存のOracleデータベースの任意のアクセス制御モデルをそのまま使用します。レルムおよびコマンド・ルールのどちらの場合も、このモデルの上の層として機能します。
次の点に注意してください。
表がレルムに追加される前に表に作成されていたビューは、レルムで保護されません。ビューを保護するには、明示的にビューをレルムに追加します。
レルムで保護されたオブジェクトにアクセスする起動者権限でのプロシージャでは、プロシージャの起動者がレルムに対して認可されている必要があります。
SYSが所有するPL/SQLプロシージャの実行は、Oracleデータ・ディクショナリのレルム実施の対象です。（Oracleデータ・ディクショナリ・レルムは、Oracle Database Vaultによって提供されるデフォルトのレルムの1つです。詳細は、「デフォルトのレルム」を参照してください。）ただし、通常Oracleデータベースで必要なように、セッションにはプロシージャのEXECUTE権限が必要です。
Javaストアド・プロシージャはレルムによって保護されませんが、Javaストアド・プロシージャがアクセスするデータ・オブジェクトはレルムで保護できます。本当に認可されているユーザーが保護されているデータを参照できるように、実行者の権限を使用してJavaストアド・プロシージャを作成する必要があります。
レルムは、システム権限を使用したアクセスからデータを保護しますが、レルムが所有者または参加者に追加の権限を付与するわけではありません。レルム認可により、ユーザーのコマンドがコマンド内に指定されているオブジェクトへのアクセスや、そのコマンドの実行を許可されているかどうかを論理的に確認する実行時メカニズムが提供されます。
システム権限は、CREATE ANY TABLEおよびDELETE ANY TABLEなどのデータベース権限より優先されます。通常これらの権限はスキーマ全体に適用されるため、直接権限を付与する必要はありません。dba_sys_privs、user_sys_privsおよびrole_sys_privsなどのデータ・ディクショナリ・ビューには、データベース・アカウントまたはロールのシステム権限が表示されています。データベース認可は、レルムに保護されていないオブジェクトを対象としています。ただし、レルムによって保護されているオブジェクトのシステム権限を正常に使用するには、ユーザーがレルム所有者または参加者として認可されている必要があります。レルム違反によりシステム権限の使用を阻止し、監査することができます。
例4-1に、レルムによってHRスキーマが保護されているレルムに、CREATE ANY TABLEシステム権限を持つ認可されていないユーザーが表の作成を試行すると発生する動作を示します。
次のような出力結果が表示されます。
ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-20401: Realm Violation on table HR.DEMO2 ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 35 ORA-06512: at line 13
この例からわかるように、認可されていないユーザーの試みは失敗します。SELECT ANY TABLE、CREATE ANY TABLE、DELETE ANY TABLE、UPDATE ANY TABLE、INSERT ANY TABLE、CREATE ANY INDEXなどのシステム権限の不正な使用は失敗します。例4-2に、認可されていないデータベース・アカウントがDELETE ANY TABLEシステム権限を使用して既存のレコードの削除を試行すると発生する動作を示します。データベース・セッションにより次のエラーが返されます。
次のような出力結果が表示されます。
ERROR at line 1: ORA-01031: insufficient privileges
レルムはオブジェクトの直接権限には影響しません。たとえば、HR.EMPLOYEES表の削除権限を付与されているユーザーは、レルム認証なしで正常にレコードを削除できます。そのため、レルムには、データベース・アカウントによる通常のビジネス・アプリケーションの使用に最低限の影響力が必要です。
例4-3に、認可されたユーザーがレルム内で許可された標準的なタスクをどのように実行するかを示します。
図4-1は、レルム内のデータがどのように保護されているかを示しています。このシナリオでは、別々のレルムを担当する2人のユーザーに同じシステム権限があります。レルム所有者は、データベース・アカウントまたはデータベース・ロールのいずれかです。OE_ADMINおよびHR_ADMINの2つのロールのそれぞれは、セキュア・オブジェクトとしてレルムで保護され、レルム所有者として構成されます。
さらに、OE_ADMINなどのレルム所有者は、レルムで保護されているデータベース・ロールの付与または取消しを実行できます。レルム所有者は、Oracleデータ・ディクショナリ・レルムのSYSによって作成されたDBAロールなど、他のレルムで保護されているロールを管理できません。レルムで保護されているオブジェクトにアクセスするためにシステム権限の不正な使用を試行することで、監査可能なレルム違反が作成されます。各レルム所有者の権限はそのレルム内に制限されます。たとえば、OE_ADMINには人事レルムへのアクセス権はなく、HR_ADMINには受注レルムへのアクセス権はありません。
レルムにはファクタ、アイデンティティ、またはルール・セットに対する影響力はありません。コマンド・ルールには影響力があるため、SQL文を処理する際にはOracle Database Vaultによってまずレルム認可が評価されます。
「レルムの動作」では、レルム内のオブジェクトに影響を与えるSQL文を処理する際にOracle Database Vaultが実行する手順が説明されています。「コマンド・ルールの動作」では、コマンド・ルールがどのように処理されるかが説明されています。
データベース・アプリケーションを構成するスキーマおよびロールに基づいてレルムを作成します。
最小限かつ特定のロールおよびアプリケーション・オブジェクトの維持に必要なシステム権限でデータベース・ロールを定義し、名前付きアカウントにロールを付与します。これにより、レルムの認可されたメンバーとしてロールを追加できます。レルムで保護されていてアプリケーションに必要なオブジェクトのオブジェクト・レベルの権限の場合、ロールを作成して、最低限かつ特定のオブジェクト・レベルの権限をロールに付与し、名前付きアカウントを付与します。多くの場合、ANYの付くシステム権限がすでに使用中でないかぎり、これらのタイプのロールをレルムで認可する必要はありません。権限はできるだけ少なくするという方針のモデルがデータベース・アプリケーションには理想的です。
データベース・オブジェクトは複数のレルムに属することが可能で、アカウントまたはロールは複数のレルムで認可することが可能です。
データベース・スキーマのサブセットに制限付きのアクセス権（HRスキーマのEMPLOYEES表のみ、またはレルムで保護されたロールなど）を付与するには、最低限必要なオブジェクトと認可で新しいレルムを作成します。
レルム認可として追加する予定で、現在ロールに許可されている権限に注意してください。
SYSまたはSYSTEMなどのアカウントが初めてロールを作成し、Oracle Database Vault管理者がそのロールをレルム認可として追加した場合、ロールのレルム認可は意図せず付与される可能性があり、すぐには気付きません。これはロールを作成するアカウントが作成される際に、ロールが暗黙的に付与されるためです。
管理タスクに対しては、一時的なレルム保護の緩和が必要な場合もあります。レルムを無効にするのではなく、セキュリティ管理者（DV_ADMINまたはDV_OWNER）をログインさせて、レルムの認可されたアカウントに名前付きのアカウントを追加し、認可ルール・セットを有効に設定します。その後、有効なルール・セットで、ルール・セットの監査をすべてオンにします。管理タスクが完了するとレルム認可を削除できます。
新しいユーザーにANY権限を付与する場合は、必要に応じて他のユーザーにANY権限を付与できるよう、データ・ディクショナリ・レルムにデータベース管理ユーザーを追加することをお薦めします。
Oracle Data Pumpの使用時など、レルムで保護されているデータのインポートおよびエクスポートの実行が必要な場合があります。レルム所有者として、次の手順を実行します。可能な場合は、この章で説明されている機能を使用して、インポートおよびエクスポート・アクティビティを監査してください。
データを保護するレルムのレルム参加者のインポートおよびエクスポートを実行するアカウントを作成します。このアカウントをデータ転送の間はレルム参加者のみに設定します。監査を実行する認可を制御するにはルール・セットを使用します。エクスポート操作を実行するユーザーまたはスキーマがレルムで保護されている場合は、このスキーマを保護しているレルムにSYSを追加します。
Oracle Data Pumpのインポートの場合は、データ・ポンプ操作の期間中にインポートを実行するユーザーにBECOME USER権限を付与します。インポートされているスキーマ・アカウントがターゲット・データベースに存在しない場合は、インポートが行われる間、SYSTEMにDV_ACCTMGRロールを付与します。インポートが完了すると、両方のユーザーから付与を取り消すことができます。
レルムで保護されているオブジェクト上でのDDLおよびDML操作には、Oracle Databaseに対してそれほどの影響力はありません。スキーマ全体にレルムを作成し、特定のユーザーを認可して割り当てられたタスクに関連する特定の操作のみを実行することをお薦めします。ファイングレイン制御の場合は、個々の表を対象とするレルムを定義し、ユーザーを認可して表で特定の操作を実行できます。ただし、1つのレルムが複数のレルムを対象とすることになるため、スキーマ全体を対象とするレルムは作成しないよう注意してください。
監査はパフォーマンスに影響します。最高のパフォーマンスを実現するためには、すべての操作を監査するのではなくファイングレイン監査を使用することをお薦めします。
Oracle Enterprise Manager（デフォルトでOracle DatabaseとともにインストールされるOracle Enterprise Manager Database Controlを含む）、StatspackおよびTKPROFなどのツールを実行してシステム・パフォーマンスを確認できます。Oracle Enterprise Managerの詳細は、Oracle Enterprise Managerのドキュメント・セットを参照してください。Database Controlの詳細は、オンライン・ヘルプを参照してください。StatspackおよびTKPROFユーティリティについては、『Oracle Databaseパフォーマンス・チューニング・ガイド』で説明されています。
表4-1に、レルムの分析に便利なOracle Database Vaultレポートを示します。これらのレポートの実行方法の詳細は、第16章「Oracle Database Vaultレポート」を参照してください。
表4-1 レルムに関連するレポート
| レポート | 目的 |
|---|---|
|
|
レルムの保護およびレルム認可操作により生成されたレコードが監査されます。 |
|
|
不完全または無効なルール・セット、またはレルムに影響する権限受領者や所有者が存在しないなどの認可構成情報が表示されます。 |
|
|
ルールが定義されていないか、有効ではなく、それらを使用するレルムに影響を与える可能性があるルール・セットが表示されます。 |
|
|
レルムが影響するオブジェクト権限が表示されます。 |
|
|
レルムの権限受領者および所有者の情報が示されます。 |
|
|
コマンド・ルールが影響するオブジェクトが表示されます。 |
表4-2に、既存のレルムに関する情報を提供するデータ・ディクショナリ・ビューを示します。
