| Oracle® Database Vault管理者ガイド 12cリリース1 (12.1) B71286-08 |
|
 前 |
 次 |
データベース・オブジェクトを保護するために、これらのオブジェクトの周辺にレルムを作成し、ユーザーがこのデータに対して行うアクセスを制御するための権限付与を設定します。
内容は次のとおりです。
レルムを使用すると、特定のオブジェクト・タイプなど、データベース・オブジェクトを保護できます。
内容は次のとおりです。
レルムは、特定のアプリケーションのために保護する必要のあるデータベース・スキーマ、データベース・オブジェクト、およびデータベース・ロールをグループ化したものです。
レルムは、データベース・オブジェクトの保護ゾーンとみなすことができます。スキーマは、表、ビューおよびパッケージなどのデータベース・オブジェクトの論理的な集合で、ロールは権限の集合です。スキーマおよびロールを機能グループに分類することにより、システム権限を使用するユーザーがこれらのグループに対して行える操作を制御し、データベース管理者またはシステム権限を持つその他の強力なユーザーによる不正なデータ・アクセスを防ぐことができます。Oracle Database Vaultは、既存のOracleデータベースの任意アクセス制御モデルを置き換えません。レルムおよびコマンド・ルールの両方で、このモデルの上位の層として機能します。
Oracle Database Vaultには、通常と必須という2つのタイプのレルムがあります。通常のレルムは、データベース・オブジェクト(スキーマなど)全体を保護します。このタイプのレルムは、直接オブジェクト権限が付与されたユーザーを除き、すべてのユーザーを制限します。直接オブジェクト権限を持つユーザーは、通常のレルムでDML操作を行うことができますが、DDL操作を行うことはできません。必須レルムは、レルム内のオブジェクトへのユーザー・アクセスを制限します。必須レルムは、オブジェクト権限およびシステム権限に基づく両方のアクセスをブロックします。つまり、オブジェクト所有者であっても、自身のオブジェクトが必須レルムで保護されている場合、適切なレルム認可を受けないとそのオブジェクトにアクセスできません。
レルムを作成すると、レルムで保護する一連のスキーマ・オブジェクトまたはロール(セキュア・オブジェクト)を登録し、セキュア・オブジェクトにアクセスする一連のユーザーやロールを認可できます。
たとえば、経理部で使用される既存のすべてのデータベース・スキーマを保護するレルムを作成できます。レルムに対して認可されていないユーザーは、保護された経理データにシステム権限を使用してアクセスすることを許可されません。
Oracle Database Vaultに作成するレルム上でレポートを実行できます。詳細は、「レルムに関連するレポートおよびデータ・ディクショナリ・ビュー」を参照してください。
この項では、Oracle Enterprise Manager Cloud Controlで、Oracle Database Vault Administratorページを使用してレルムを構成する方法について説明します。Oracle Database Vaultが提供するPL/SQLインタフェースおよびパッケージを使用してレルムを構成するには、「Oracle Database VaultレルムのAPI」を参照してください。
デフォルトでは、オブジェクト権限を所有または保持するユーザーには、明示的なレルム認可を受けずにレルム保護オブジェクトへのアクセスが許可されます。
レルムを必須レルムになるように構成することで、これらのユーザーがアクセスできないようにオプションでレルムを構成できます。必須レルムは、システム権限に基づくアクセスとオブジェクト権限に基づくアクセスの両方をブロックします。つまり、オブジェクト所有者は、レルムへのアクセスが認可されない場合、アクセスできません。ユーザーは、ユーザーまたはロールがレルムにアクセスする認可を受けている場合のみ、必須レルムのセキュア・オブジェクトにアクセスできます。
必須レルムには、その他に次の特徴があります。
同じオブジェクトに必須レルムが複数ある場合、保護されたオブジェクトにアクセスするには、すべての必須レルムに対してユーザーまたはロールを認可する必要があります。
ロールが必須レルムで保護される場合、レルム所有者を除き、保護されたロールに対する権限の付与や取消しを行うことはできません。
以前のリリースで作成した通常のレルムを更新して必須レルムにすることができます。こうすると、所有者のアクセスをブロックし、オブジェクト権限ユーザーがレルム保護オブジェクトにアクセスしないようにできます。
必須レルムには、次の利点があります。
必須レルムは、オブジェクト所有者およびオブジェクト権限ユーザーをブロックできます。以前のリリースでは、複雑なコマンド・ルールを定義しないとこれらのユーザーをブロックできませんでした。
必須レルムを使用すると、アクセス制御を構成する柔軟性が高くなります。たとえば、ユーザーが特定の条件(日中の特定の時間範囲内など)でオブジェクトにアクセスできるようにするとします。レルムはオブジェクト権限をブロックしないため、オブジェクト権限をそのユーザーに付与できません。システム権限のみをユーザーに付与し、ルールを使用してこのユーザーをレルムに対して認可するか、コマンド上でコマンド・ルールを直接作成できます。これらのソリューションは、計算上コストの面でかなり高額になったり、システム権限などの権限をユーザーに過度に付与する必要があるため望ましい方法ではありません。必須レルムの場合、特定の条件に関するルールとともにオブジェクト権限をユーザーに付与し、このユーザーをレルム所有者または参加者として認可するだけで済みます。そのため、必須レルムを使用する場合、ユーザーに過度の権限が付与されず、Oracle Database Vaultポリシーの柔軟性が増します。
必須レルムにより、パッチのアップグレード時に保護レイヤーが追加されます。パッチのアップグレード時に、データベース管理者は、オブジェクトにパッチを実行するためにレルム保護オブジェクトへの直接アクセス権が必要になります。社会保障番号などの機密データが含まれる表がある場合、パッチのアップグレード時に必須レルムを使用して、管理者がこれらの表にアクセスしないようにすることができます。パッチ適用が完了し、データベース管理者がオブジェクトにアクセスする必要がなくなったら、必須レルムの保護を無効化し、通常のアプリケーション・レルム保護を再び有効化して、アプリケーション保護を通常の状態に戻すことができます。
必須レルムを使用してランタイムで表を保護できます。ランタイムで、アプリケーション・データを多くの表に格納できます。データの整合性や正確性が維持されるように、ランタイム・スキーマなどの単一ユーザーがこれらの表にアクセスする方法が適しています。アプリケーション・データが多くの異なるスキーマに分散する場合、スキーマ所有者とオブジェクト権限を持つユーザーは、データベースに直接ログインするとデータを変更できます。ユーザーがランタイム・スキーマのプロシージャを実行せずにこれらの表を更新できないように、必須レルムを使用して表を保護し、認可されたユーザーのプロシージャのみがアクセスするようにできます。通常のレルムはオブジェクト所有者とオブジェクト権限ユーザーをブロックしないため、必須レルムを使用してこれらをブロックできます。このように、認可されたユーザーのみがランタイムでこれらの表にアクセスできます。
構成済のロールに対する変更を禁止することで、セキュリティ設定を固定できます。
特定のオブジェクト・タイプのスキーマ内のすべてのオブジェクトの周りにレルムを作成できます。
これらのオブジェクト・タイプは、次のとおりです。
| オブジェクト・タイプC-J | オブジェクト・タイプL-P | オブジェクト・タイプR-V |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Oracle Database Vaultにはデフォルトのレルムが用意されています。これは通常のレルムであり、必須レルムではありません。
内容は次のとおりです。
Oracle Database Vaultレルムは、Oracle Database VaultのDVSYS、DVFおよびLBACSYSの各スキーマの構成およびロール情報を保護します。
この3つすべてのスキーマの所有者がこのレルムの所有者になります。これらのスキーマの詳細は、「Oracle Database Vaultのスキーマ」および「登録中に作成されるOracle Database Vaultアカウント」を参照してください。
このレルムは次のオブジェクトを保護します。
保護されるスキーマ全体: DVSYS、DVF、LABACSYS
保護されるロール:
| スキーマDV_A-DV_S | スキーマDV_P-L | スキーマDV_G |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
- |
|
|
- |
保護されるPL/SQLパッケージ: SYS.DBMS_RLS
Database Vaultアカウント管理レルムは、データベース・アカウントとデータベース・プロファイルを管理および作成する管理者のレルムを定義します。
このレルムは、DV_ACCTMGRロールとCONNECTロールを保護します。このレルムの所有者は、ユーザーに対してCREATE SESSION権限の付与と取消しを行うことができます。
DV_ACCTMGRロールの詳細は、「DV_ACCTMGR Database Vaultアカウント・マネージャ・ロール」を参照してください。
Oracle Database Vaultには、Oracle Enterprise Managerアカウント専用のレルムが用意されています。
Oracle Enterprise Managerレルムは、監視と管理に使用されるOracle Enterprise Managerアカウント(DBSNMPユーザーおよび OEM_MONITORロール)を保護します。
Oracleデフォルト・スキーマ保護レルムは、Oracle TextなどのOracle機能で使用されるロールやスキーマを保護します。
このグループ分けには、Oracle Spatialスキーマ(MDSYS、MDDATA)がOracle Text(CTXSYS)で拡張して使用されるメリットと、Oracle OLAPがコアOracle Databaseカーネル機能ではなくアプリケーションになるメリットがあります。
Oracleデフォルト・スキーマ保護レルムで保護されるロールとスキーマ
Oracleデフォルト・スキーマ保護レルムでは、いくつかのロールとスキーマが保護されます。
デフォルトで保護されるロール: CTXAPP、OLAP_DBA、EJBCLIENT、OLAP_USER
デフォルトで保護されるスキーマ: CTXSYS、EXFSYS、MDDATA、MDSYS
保護をお薦めするロール: APEX_ADMINISTRATOR_ROLE、SPATIAL_CSW_ADMIN、WFS_USR_ROLE、CSW_USR_ROLE、SPATIAL_WFS_ADMIN、WM_ADMIN_ROLE
保護をお薦めするスキーマ: APEX_030200、OWBSYS、WMSYS
Oracleデフォルト・スキーマ保護レルムの所有者
SYS、CTXSYSおよびEXFSYSユーザーは、Oracleデフォルト・スキーマ保護レルムのデフォルトの所有者です。これらのユーザーは、このレルムで保護されるロールを他のユーザーに付与して、そのスキーマに対する権限も他のユーザーに付与できます。
Oracleシステム権限およびロール管理レルムは、Oracle Databaseのデータのエクスポートとインポートに使用されるすべての機密ロールを保護します。
このレルムには、システム権限を付与する必要があるユーザーの認可も含まれます。
ユーザーSYSは、このレルムの唯一のデフォルトの所有者です。システム権限の管理を担当するどのユーザーも、このレルムの所有者として認可される必要があります。これらのユーザーは、このレルムで保護されるロールを他のユーザーに付与できます。
デフォルトで保護されるロール:
| ロールA-E | ロールG-J | ロールJ-S |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- |
|
|
- |
保護をお薦めするロール: DBFS_ROLE、HS_ADMIN_EXECUTE_ROLE、HS_ADMIN_SELECT_ROLE
レルムの保護を有効にするには、レルムを作成して、レルム・セキュア・オブジェクト、ロール、および認可を含めるようにレルムを構成します。
「レルム設計のガイドライン」に、レルムの作成に関する注意事項が説明されています。
レルム・セキュア・オブジェクトは、レルムが保護する地域(一連のスキーマおよびデータベースのオブジェクトとロール)を定義します。
次のような保護方法があります。
複数のデータベース・アカウントまたはスキーマのオブジェクトを同じレルムに追加できます。
1つのオブジェクトは複数のレルムに属することができます。
オブジェクトが複数のレルムに属する場合、Oracle Database Vaultは、適切な認可があるかどうかレルムを確認します。SELECT、DDLおよびDML文の場合、ユーザーがいずれかのレルムの参加者であり、コマンド・ルールで許可されれば、そのユーザーが入力するコマンドは許可されます。複数のレルムにおけるデータベース・ロールによるGRANTおよびREVOKE操作の場合、GRANTまたはREVOKE操作を実行するユーザーはレルムの所有者である必要があります。スキーマ所有者は、複数の通常レルムに保護されたオブジェクトに対してDML操作を行うことができます。
いずれかのレルムが必須レルムの場合、オブジェクトにアクセスするユーザーは、レルム所有者か必須レルムの参加者である必要があります。認可チェック・プロセスでは、必須レルムではないレルムは無視されます。オブジェクトを保護する必須レルムが複数ある場合、オブジェクトにアクセスするユーザーは、すべての必須レルムで認可される必要があります。
レルム認可では、レルムで保護されているオブジェクトの管理またはアクセスを実行する一連のデータベース・アカウントおよびロールを決定します。
次の状況でシステム権限を使用できるように、レルム認可をアカウントまたはロールに付加できます。
レルム・セキュア・オブジェクトの作成またはレルム・セキュア・オブジェクトへのアクセスが必要な場合
レルム・セキュア・ロールを付与または取り消す必要がある場合
レルム所有者またはレルム参加者としてレルム認可を付与されたユーザーは、システム権限を使用してレルム内のセキュア・オブジェクトにアクセスできます。
次の点に注意してください。
レルム所有者は、自分のレルムに他のユーザーを所有者または参加者として追加できません。DV_OWNERまたはDV_ADMINロールのあるユーザーのみ、所有者または参加者としてユーザーをレルムに追加できます。
DV_OWNERロールを付与されているユーザーは、自分自身をレルム認可に追加できます。
レルム所有者(ただし、レルム参加者ではない)は、レルム・セキュア・ロールの付与または取消し、あるいはレルム・セキュア・オブジェクトに対するオブジェクト権限の付与または取消しを誰に対しても行うことができます。
ユーザーはレルム所有者またはレルム参加者のいずれかとして付与されますが、両方を付与されることはありません。また一方で、既存のレルム認可の認可タイプを更新できます。
「レルムの編集: HR Realm」ページを使用して、レルム認可を管理します。レルム認可を作成、編集および削除できます。レルム認可の構成情報を追跡する場合は、「レルム認可構成に関する問題のレポート」を参照してください。
Enterprise Manager Cloud Controlからレルムを無効化または有効化できます。
適切な権限を持つデータベース・アカウントが、レルム内のオブジェクトに影響するSQL文を発行すると、特別なアクティビティのセットが発生します。
これらの権限には、DDL、DML、EXECUTE、GRANT、REVOKE、またはSELECT権限が含まれます。
SQL文はレルムによって保護されているオブジェクトに影響しますか。
実行する場合は、手順2に進みます。実行しない場合、レルムはSQL文に影響しません。手順7に進みます。コマンドによって影響されるオブジェクトがレルムで保護されていない場合、レルムも実行されるSQL文には影響しません。
必須レルムですか、通常のレルムですか。
データベース・アカウントで、システム権限を使用してSQL文を実行しますか。
影響する場合は、手順4に進みます。当てはまらない場合は、手順6に進みます。セッションが、対象となるオブジェクトに対して、SELECT、EXECUTEおよびDML文のオブジェクト権限しか持っていない場合、レルム保護は実施されません。レルムは、レルムで保護されているオブジェクトまたはロールに対するシステム権限の使用を保護します。通常レルムによって保護されているオブジェクトに関するオブジェクト権限を持つユーザーでも、DDL操作を行うことはできません。
O7_DICTIONARY_ACCESSIBILITY初期化パラメータがTRUEに設定されている場合は、SYS以外のユーザーがSYSスキーマ・オブジェクトにアクセスできることに留意してください。セキュリティ強化のために、O7_DICTIONARY_ACCESSIBILITYがFALSEに設定されていることを確認してください。
データベース・アカウントは、レルム所有者またはレルム参加者ですか。
当てはまる場合は、手順5に進みます。いずれでもない場合は、レルム違反が発生し、文は失敗します。コマンドがレルムで保護されているロールのGRANTかREVOKEである場合、またはレルムで保護されているオブジェクトに対するオブジェクト権限GRANTかREVOKEである場合、セッションはロールを介して直接的または間接的にレルム所有者として認可されている必要があります。
データベース・アカウントに対するレルム認可は、状況に応じてルール・セットに基づきますか。
ルール・セットはTRUEに評価されますか。
影響する場合は、手順7に進みます。そうでない場合は、レルム違反が発生し、SQL文は失敗します。
コマンド・ルールでコマンドの実行が阻止されますか。
阻止される場合は、コマンド・ルール違反が発生しSQL文は失敗します。阻止されない場合は、レルム違反もコマンド・ルール違反も発生しないため、コマンドは成功します。
たとえば、HRアカウントにDROP ANY TABLE権限があり、HRレルムの所有者であるとしても、月ごとのメンテナンスの時間帯でないかぎり、コマンド・ルールでHRによるHRスキーマの任意の表の削除を阻止できます。コマンド・ルールは、オブジェクト権限だけでなくANYシステム権限の使用にも適用され、レルム・チェック後に評価されます。
また、セッションはレルム内で認可されるため、アカウントはレルムによって保護されているオブジェクトを完全に制御できるわけではありません。レルム認可は、アカウントに追加権限を暗黙的に付与しません。アカウントは、従前どおり、オブジェクトにアクセスするためのシステム権限またはオブジェクト権限を持っている必要があります。たとえば、アカウントまたはロールにSELECT ANY表権限があり、HRレルムの参加者であるとします。これは、そのアカウントまたはロールが付与されているアカウントによる、HR.EMPLOYEES表への問合せが可能であることを意味します。レルムの参加者であることは、そのアカウントまたはロールでHR.EMPLOYEES表をDROPできるということではありません。Oracle Database Vaultは、既存のOracleデータベースの任意アクセス制御モデルを置き換えません。レルムおよびコマンド・ルールの両方で、このモデルの上位の層として機能します。
次の点に注意してください。
デフォルトでは、レルム内の表の保護では、ビューは保護されません。ビューが作成された時期が、表がレルムに追加される前か後かに関係なく、保護する必要のあるビューは、レルムに追加しておく必要があります。
レルムで保護されたオブジェクトにアクセスする起動者権限でのプロシージャでは、プロシージャの起動者がレルムに対して認可されている必要があります。
表のアクセスがPUBLICに付与されている場合、レルム保護では表は保護されないので注意してください。たとえば、SELECT ON table_nameがPUBLICに付与されている場合、table_name(表が必須レルムで保護される場合を除く)がレルムで保護されていても、全ユーザーがこの表にアクセスできます。不要な権限はPUBLICから取り消すことをお薦めします。
レルムは、システム権限によるアクセスからデータを保護します。
レルムは、データ所有者または参加者に追加の権限は付与しません。
レルム認可により、ユーザーのコマンドがコマンド内に指定されているオブジェクトへのアクセスや、そのコマンドの実行を許可または拒否される必要がある場合、論理的に確認する実行時メカニズムが提供されます。
システム権限は、CREATE ANY TABLEおよびDELETE ANY TABLEなどのデータベース権限より優先されます。通常これらの権限はスキーマ全体に適用されるため、オブジェクト権限の必要はありません。DBA_SYS_PRIVS、USER_SYS_PRIVSおよびROLE_SYS_PRIVSなどのデータ・ディクショナリ・ビューには、データベース・アカウントまたはロールのシステム権限が表示されています。データベース認可は、レルムに保護されていないオブジェクトを対象としています。ただし、レルムによって保護されているオブジェクトのシステム権限を正常に使用するには、ユーザーがレルム所有者または参加者として認可されている必要があります。レルム違反によりシステム権限の使用を阻止し、監査することができます。
必須レルムは、オブジェクト権限およびシステム権限に基づく両方のアクセスをブロックします。つまり、オブジェクト所有者は、レルムへのアクセスが認可されない場合、アクセスできません。ユーザーは、ユーザーまたはロールがレルムにアクセスする認可を受けている場合のみ、必須レルムのセキュア・オブジェクトにアクセスできます。
システム権限および他の強力な権限を持つユーザーからオブジェクトを保護するレルムを作成できます。
内容は次のとおりです。
権限のないユーザーが表を作成しようとすると、ORA-47401エラーが発生します。
例5-1に、レルムによってHRスキーマが保護されているレルムに、CREATE ANY TABLEシステム権限を持つ認可されていないユーザーが表の作成を試行すると発生する動作を示します。
例5-1 認可されていないユーザーによる表作成の試行
CREATE TABLE HR.demo2 (col1 NUMBER(1));
次のような出力結果が表示されます。
ORA-47401: Realm violation for CREATE TABLE on HR.DEMO2
この例からわかるように、認可されていないユーザーの試みは失敗します。SELECT ANY TABLE、CREATE ANY TABLE、DELETE ANY TABLE、UPDATE ANY TABLE、INSERT ANY TABLE、CREATE ANY INDEXなどのシステム権限の不正な使用は失敗します。
適切な権限を持たないユーザーがアクセスしようとすると、「ORA-01031: insufficient privileges」というエラーが発生します。
例5-2に、認可されていないデータベース・アカウントがDELETE ANY TABLEシステム権限を使用して既存のレコードの削除を試行すると発生する動作を示します。データベース・セッションにより次のエラーが返されます。
例5-2 認可されていないユーザーによるDELETE ANY TABLE権限の使用の試行
DELETE FROM HR.EMPLOYEES WHERE EMPNO = 8002;
次のような出力結果が表示されます。
ERROR at line 1: ORA-01031: insufficient privileges
レルムはオブジェクトの直接権限には影響しません。たとえば、HR.EMPLOYEES表の削除権限を付与されているユーザーは、レルム認証なしで正常にレコードを削除できます。そのため、レルムには、データベース・アカウントによる通常のビジネス・アプリケーションの使用に最低限の影響力が必要です。
認可ユーザーは、与えられた権限の範囲内でアクティビティを実行することができます。
例5-3に、認可されたユーザーがレルム内で許可された標準的なタスクをどのように実行するかを示します。
例5-3 認可されたユーザーによるDELETE操作の実行
DELETE FROM HR.EMPLOYEES WHERE EMPNO = 8002; 1 row deleted.
レルムによってオブジェクトを保護することができますが、その場合でも、このレルム保護オブジェクトの一部であるオブジェクトにアクセスできるようにすることは可能です。
たとえば、特定の表にレルムを作成するとします。ただし、この表にユーザーが索引を作成できるようにします。これは、次のシナリオに応じて次のように実行できます。
ユーザーにCREATE ANY INDEX権限がない場合。表のレルム所有者として、索引を作成する必要のあるユーザーにCREATE INDEX ON table権限を付与します。
ユーザーにCREATE ANY INDEX権限がある場合。この場合、別のレルムを作成して、すべての索引タイプをセキュア・オブジェクトとし、そのユーザーにレルムの参加者認可を付与します。(レルム参加者以外がレルムで保護された表に索引を作成する場合、CREATE ANY INDEXのみでは不十分なことに注意してください。)
すべてのデータベース管理者が索引を作成できるようにし、データベース管理者にCREATE ANY INDEX権限がある場合。データ保護レルムで、索引タイプを除いて保護するすべてのオブジェクト・タイプを指定します。これにより、保護された表の索引をすべての管理者が作成できます。
レルムは、同じ権限を持つ2人のユーザーがオブジェクトに対して別々のアクセス・レベルを必要とする場合に、保護を提供することができます。
図5-1は、レルム内のデータがどのように保護されているかを示しています。
このシナリオでは、別々のレルムを担当する2人のユーザーに同じシステム権限があります。レルム所有者は、データベース・アカウントまたはデータベース・ロールのいずれかです。OE_ADMINおよびHR_ADMINの2つのロールのそれぞれは、セキュア・オブジェクトとしてレルムで保護され、かつレルム所有者として構成されます。
さらに、OE_ADMINなどのレルム所有者は、レルムで保護されているデータベース・ロールの付与または取消しを実行できます。レルム所有者は、他のレルムで保護されるロール(Oracleシステム権限およびロール管理レルムでSYSによって作成されるDBAロールなど)を管理できません。レルムで保護されているオブジェクトにアクセスするためにシステム権限の不正な使用を試行することで、監査可能なレルム違反が生成されます。各レルム所有者の権限はそのレルム内に制限されます。たとえば、OE_ADMINには人事レルムへのアクセス権はなく、HR_ADMINには受注レルムへのアクセス権はありません。
関連項目:
レルムの作成および使用方法に関するチュートリアルは、「クイック・スタート・チュートリアル: DBAアクセスからのスキーマの保護」を参照してください
レルムは、ファクタ、アイデンティティ、ルール・セットには影響を与えず、コマンド・ルールに影響を与えます。
コマンド・ルールを使用すると、Oracle Database VaultはSQL文の処理時にまずレルム認可を評価します。
「レルムの動作」では、レルム内のオブジェクトに影響を与えるSQL文を処理する際にOracle Database Vaultで実行される手順が説明されています。「コマンド・ルールの動作」では、コマンド・ルールがどのように処理されるかが説明されています。
Oracleでは、一連のレルム設計のガイドラインを提供しています。
データベース・アプリケーションを構成するスキーマおよびロールに基づいてレルムを作成します。
最小限かつ特定のロールおよびアプリケーション・オブジェクトの維持に必要なシステム権限でデータベース・ロールを定義し、名前付きアカウントにロールを付与します。これにより、レルムの認可されたメンバーとしてロールを追加できます。レルムで保護されていてアプリケーションに必要なオブジェクトのオブジェクト・レベルの権限の場合、ロールを作成して、最低限かつ特定のオブジェクト・レベルの権限をロールに付与し、名前付きアカウントを付与します。多くの場合、ANYの付くシステム権限がすでに使用中でないかぎり、これらのタイプのロールをレルムで認可する必要はありません。権限はできるだけ少なくするという方針のモデルがデータベース・アプリケーションには理想的です。
データベース・オブジェクトは複数のレルムに属することが可能で、アカウントまたはロールは複数のレルムで認可することが可能です。
データベース・スキーマのサブセットに制限付きのアクセス権(HRスキーマのEMPLOYEES表のみ、またはレルムで保護されたロールなど)を付与するには、最低限必要なオブジェクトと認可で新しいレルムを作成します。
ロールを権限受領者としてレルムに追加する場合は、ロールを保護するレルムを作成します。これにより、SYSTEMユーザー・アカウントなどGRANT ANY ROLEシステム権限が付与されているユーザーが、自分自身にロールを付与することができなくなります。
SYSユーザー・アカウントをレルム認可に追加する場合は、ロール(DBAロールなど)を介さずに、ユーザーSYSを明示的に追加する必要があります。
レルム認可として追加する予定で、現在ロールに許可されている権限に注意してください。
SYSまたはSYSTEMなどのアカウントが初めてロールを作成し、Oracle Database Vault管理者がそのロールをレルム認可として追加した場合、ロールのレルム認可は意図せず付与される可能性があり、すぐには気付きません。これはロールを作成するアカウントが作成される際に、ロールが暗黙的に付与されるためです。
管理タスクに対しては、一時的なレルム保護の緩和が必要な場合もあります。レルムを無効にするのではなく、セキュリティ管理者(DV_ADMINまたはDV_OWNER)をログインさせて、レルムの認可されたアカウントに名前付きのアカウントを追加し、認可ルール・セットを有効に設定します。その後、有効なルール・セットで、ルール・セットの監査をすべてオンにします。管理タスクが完了するとレルム認可を削除できます。
新しいユーザーにANY権限を付与する場合は、必要に応じて他のユーザーにANY権限を付与できるよう、Oracleシステム権限およびロール管理レルムにデータベース管理ユーザーを追加することをお薦めします。たとえば、名前付きアカウントを使用してANY操作のGRANTを実行すると、これらの操作の監査が可能になり、説明責任を果すための監査証跡が作成されます。
レルムによって保護されていた表、索引またはロールを削除し、同じ名前を使用して再作成した場合、レルムの保護はリストアされません。新しい表、索引またはロールに対してレルムの保護を再作成する必要があります。ただし、指定したスキーマ内の以後の表、索引およびロールすべてに対して自動的に保護を実施できます。たとえば、以後の表すべてに保護を実施するには、次のようにします。
BEGIN
DBMS_MACADM.ADD_OBJECT_TO_REALM('realm_name', 'schema_name', '%', 'TABLE');
END;
/
レルムは、DDLおよびDML操作などの様々な状況で、データベース・パフォーマンスに影響します。
レルムで保護されているオブジェクトに対するDDLおよびDML操作によって、Oracle Databaseはそれほど影響を受けません。スキーマ全体を対象としてレルムを作成し、割り当てられたタスクに関連する特定の操作のみを実行できるよう特定のユーザーを認可することをお薦めします。ファイングレイン制御の場合は、個々の表を対象とするレルムを定義し、表に対する特定の操作を実行できるようユーザーを認可すると同時に、スキーマ全体を対象としたレルムでアプリケーション全体を保護することもできます。ただし、このタイプの構成はパフォーマンスを低下させる可能性がある一方、スキーマ内の一部のオブジェクトにレルム認可を付与できないことに注意してください。
監査はパフォーマンスに影響します。最高のパフォーマンスを実現するためには、すべての操作を監査するのではなくファイングレイン監査を使用することをお薦めします。
システム・パフォーマンスを定期的に確認します。確認するには、Oracle Enterprise Manager(Oracle Databaseと一緒にデフォルトでインストールされるOracle Enterprise Manager Cloud Controlを含む)、自動ワークロード・リポジトリ(AWR)およびTKPROFなどのツールを実行します。
関連項目:
データベース・パフォーマンスの監視方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください
個々のSQL文およびPL/SQL文の実行を監視するには、『Oracle Database SQLチューニング・ガイド』を参照してください
Oracle Database Vaultには、レルムの分析に役立つ、レポートとデータ・ディクショナリ・ビューが用意されています。
表5-1に、Oracle Database Vaultレポートを示します。これらのレポートの実行方法の詳細は、「Oracle Database Vaultレポート」を参照してください。
表5-1 レルムに関連するレポート
| レポート | 目的 |
|---|---|
レルムの保護およびレルム認可操作により生成されたレコードが監査されます。 |
|
不完全または無効なルール・セット、またはレルムに影響する権限受領者や所有者が存在しないなどの認可構成情報が表示されます。 |
|
ルールが定義されていないか、有効ではなく、それらを使用するレルムに影響を与える可能性があるルール・セットが表示されます。 |
|
レルムが影響するオブジェクト権限が表示されます。 |
|
レルムの権限受領者および所有者の情報が示されます。 |
|
コマンド・ルールが影響するオブジェクトが表示されます。 |
表5-2に、既存のレルムに関する情報を提供するデータ・ディクショナリ・ビューを示します。
表5-2 レルムに使用されるデータ・ディクショナリ・ビュー
| データ・ディクショナリ・ビュー | 説明 |
|---|---|
現行のデータベース・インスタンスで作成されたレルムが表示されます。 |
|
特定のレルムのレルム・オブジェクトにアクセスするための、名前付きデータベース・ユーザー・アカウントまたはデータベース・ロール( |
|
データベース・スキーマ、または特定のデータベース・オブジェクトが含まれている(つまり、レルムによって保護されている)スキーマのサブセットが表示されます。 |
