日本語PDF

4 レルムの構成

データベース・オブジェクトを保護するために、これらのオブジェクトの周辺にレルムを作成し、このデータへのユーザー・アクセスを制御するための認可を設定します。

• レルムの概要
  レルムを使用すると、特定のオブジェクト・タイプなど、データベース・オブジェクトを保護できます。
• デフォルト・レルム
  Oracle Database Vaultには、Database VaultおよびSYS関連のスキーマ、システム権限とオブジェクト権限、ロールおよび監査関連オブジェクトを保護するためのデフォルト・レルムが用意されています。
• レルムの作成
  レルムの保護を有効にするには、レルムを作成して、レルム・セキュア・オブジェクト、ロールおよび認可を含めるようにレルムを構成します。
• レルム・セキュア・オブジェクトについて
  レルム・セキュア・オブジェクトにより、レルムによって保護されるテリトリ(一連のスキーマおよびデータベースのオブジェクト、およびロール)が定義されます。
• レルム認可について
  レルム認可では、レルムで保護されているオブジェクトの管理またはアクセスを実行する一連のデータベース・アカウントおよびロールを決定します。
• マルチテナント環境におけるレルム認可
  マルチテナント環境では、共通レルム認可のルールおよび動作は、他の共通オブジェクトの認可と同様です。
• レルムの有効化ステータスの変更
  Enterprise Manager Cloud Controlから、レルムを無効または有効にすることや、シミュレーション・モードを使用するようレルムを設定することができます。
• レルムの削除
  Enterprise Manager Cloud Controlを使用して、レルムを削除できます。
• レルムの動作
  適切な権限を持つデータベース・アカウントにより、レルム内のオブジェクトに影響するSQL文が発行されると、特定のアクティビティ・セットが発生します。
• レルムでの認可の動作
  ユーザーに正しい権限がない場合、レルム認可により、そのユーザーによるアクティビティの実行が阻止されます。
• レルムで保護されたオブジェクトへのアクセス
  レルムでオブジェクトを保護できますが、このレルムで保護されているオブジェクトに含まれるオブジェクトへのアクセスは可能です。
• レルムの動作の例
  レルムにより、同じ権限のある2人のユーザーに、オブジェクトに対する別々のアクセス・レベルが必要な場合に保護を提供できます。
• その他のOracle Database Vaultコンポーネントへのレルムの影響
  レルムはファクタ、アイデンティティおよびルール・セットには影響しませんが、コマンド・ルールには影響します。
• レルム設計のガイドライン
  Oracleでは、一連のレルム設計のガイドラインを提供しています。
• レルムのパフォーマンスへの影響
  レルムは、DDLおよびDML操作などの様々な状況で、データベース・パフォーマンスに影響します。
• レルム関連のレポートおよびデータ・ディクショナリ・ビュー
  Oracle Database Vaultには、レルムの分析に役立つ、レポートとデータ・ディクショナリ・ビューが用意されています。

4.1 レルムの概要

レルムを使用すると、特定のオブジェクト・タイプなど、データベース・オブジェクトを保護できます。

• レルムについて
  レルムは、特定のアプリケーションのために保護する必要のあるデータベース・スキーマ、データベース・オブジェクトおよびデータベース・ロールのグループです。
• 必須レルムによるレルム内のオブジェクトへのユーザー・アクセスの制限
  デフォルトでは、オブジェクト権限を所有または保持するユーザーには、明示的なレルム認可を受けずにレルム保護オブジェクトへのアクセスが許可されます。
• マルチテナント環境におけるレルム
  マルチテナント環境では、アプリケーション・ルート内の共通オブジェクトを保護するためにレルムを作成できます。
• レルムで保護できるオブジェクト・タイプ
  特定のオブジェクト・タイプのスキーマ内のすべてのオブジェクトの周りにレルムを作成できます。

4.1.1 レルムについて

レルムは、特定のアプリケーションのために保護する必要のあるデータベース・スキーマ、データベース・オブジェクトおよびデータベース・ロールのグループです。

レルムは、データベース・オブジェクトの保護ゾーンとみなすことができます。スキーマは、表、ビューおよびパッケージなどのデータベース・オブジェクトの論理的な集合で、ロールは権限の集合です。スキーマおよびロールを機能グループに分類することにより、システム権限を使用するユーザーがこれらのグループに対して行える操作を制御し、データベース管理者またはシステム権限を持つその他の強力なユーザーによる不正なデータ・アクセスを防ぐことができます。Oracle Database Vaultは、既存のOracleデータベースの任意アクセス制御モデルを置き換えません。レルムおよびコマンド・ルールの両方で、このモデルの上位の層として機能します。

Oracle Database Vaultには、通常と必須という2つのタイプのレルムがあります。どちらのタイプのレルムでも、スキーマ全体、個々のデータベース・ロール、またはスキーマ内の重要なオブジェクト(表や索引)を選択的に保護できます。通常レルムの場合、オブジェクト権限を付与されているオブジェクトの所有者またはユーザーはレルム認可なしで問合せやDML操作を実行できますが、DDL操作の実行にはレルム認可が必要です。必須レルムの場合、レルム内のオブジェクトにさらに厳格な保護が適用されます。必須レルムの場合、オブジェクト権限とシステム権限の両方へのアクセスがブロックされ、オブジェクト権限を持つユーザーが、レルム認可なしで問合せ、DMLまたはDDL操作を実行することは許可されません。つまり、オブジェクトが必須レルムで保護されている場合、オブジェクト所有者であっても、適切なレルム認可を受けないとそのオブジェクトにアクセスできません。

Oracle Flashback Technologyを使用するデータベースの場合、標準レルムと必須レルムのどちらも、フラッシュバック表に対する動作が強制的に同じになります。ユーザーにレルムに対する権限がある場合、ユーザーは、レルムで保護された表に対してFLASHBACK TABLE SQL文を実行できます。

情報ライフサイクル管理(ILM)を使用するデータベースの場合、Database Vault管理者は、DBMS_MACADM.AUTHORIZE_MAINTENANCE_USERおよびDBMS_MACADM.UNAUTHORIZE_MAINTENANCE_USERプロシージャを使用して、レルムで保護されたオブジェクトに誰がILM操作を実行可能かを制御できます。

たとえば、経理部で使用される既存のすべてのデータベース・スキーマを保護するレルムを作成できます。レルムに対して認可されていないユーザーは、保護された経理データにシステム権限を使用してアクセスすることを許可されません。スキーマ全体が保護される場合は、表、索引、プロシージャおよびその他のオブジェクトなど、スキーマ内のすべてのオブジェクトが保護されます。

Oracle Database Vaultに作成するレルム上でレポートを実行できます。開発フェーズやテスト・フェーズの間、また、本番フェーズの間でも、シミュレーション・モードを使用して、アクセスをブロックするかわりにレルム違反のみを記録できます。これにより、Database Vaultレルムを使用してアプリケーションを迅速にテストできます。

Oracle Enterprise Manager Cloud ControlでOracle Database Vault Administratorページを使用することで、レルムを構成できます。別の方法としては、Oracle Database Vaultで提供されるPL/SQLインタフェースおよびパッケージを使用することで、レルムを構成できます。

4.1.2 必須レルムによるレルム内のオブジェクトへのユーザー・アクセスの制限

デフォルトでは、オブジェクト権限を所有または保持するユーザーには、明示的なレルム認可を受けずにレルム保護オブジェクトへのアクセスが許可されます。

レルムを必須レルムになるように構成することで、これらのユーザーがアクセスできないようにオプションでレルムを構成できます。必須レルムは、システム権限に基づくアクセスとオブジェクト権限に基づくアクセスの両方をブロックします。つまり、オブジェクト所有者は、レルムへのアクセスが認可されない場合、アクセスできません。ユーザーは、ユーザーまたはロールがレルムにアクセスする認可を受けている場合のみ、必須レルムのセキュア・オブジェクトにアクセスできます。

必須レルムには、その他に次の特徴があります。

• ロールが必須レルムで保護される場合、レルム所有者を除き、保護されたロールに対する権限の付与や取消しを行うことはできません。

• 以前のリリースで作成した通常のレルムを更新して必須レルムにすることができます。こうすると、所有者のアクセスをブロックし、オブジェクト権限ユーザーがレルム保護オブジェクトにアクセスしないようにできます。

• SYS所有オブジェクトは、データ・ディクショナリ保護によってすでに保護されており、Oracle Database Vaultによって個別に保護されてはいません。

必須レルムには、次の利点があります。

• 必須レルムは、オブジェクト所有者およびオブジェクト権限ユーザーをブロックできます。以前のリリースでは、複雑なコマンド・ルールを定義しないとこれらのユーザーをブロックできませんでした。

• 必須レルムを使用すると、アクセス制御を構成する柔軟性が高くなります。たとえば、ユーザーが特定の条件(日中の特定の時間範囲内など)でオブジェクトにアクセスできるようにするとします。レルムはオブジェクト権限をブロックしないため、オブジェクト権限をそのユーザーに付与できません。システム権限のみをユーザーに付与し、ルールを使用してこのユーザーをレルムに対して認可するか、コマンド上でコマンド・ルールを直接作成できます。これらのソリューションは、計算上コストの面でかなり高額になったり、システム権限などの権限をユーザーに過度に付与する必要があるため望ましい方法ではありません。必須レルムの場合、特定の条件に関するルールとともにオブジェクト権限をユーザーに付与し、このユーザーをレルム所有者または参加者として認可するだけで済みます。そのため、必須レルムを使用する場合、ユーザーに過度の権限が付与されず、Oracle Database Vaultポリシーの柔軟性が増します。

• 必須レルムにより、パッチのアップグレード時に保護レイヤーが追加されます。パッチのアップグレード時に、データベース管理者は、オブジェクトにパッチを実行するためにレルム保護オブジェクトへの直接アクセス権が必要になります。社会保障番号などの機密データが含まれる表がある場合、パッチのアップグレード時に必須レルムを使用して、管理者がこれらの表にアクセスしないようにすることができます。パッチ適用が完了し、データベース管理者がオブジェクトにアクセスする必要がなくなったら、必須レルムの保護を無効化し、通常のアプリケーション・レルム保護を再び有効化して、アプリケーション保護を通常の状態に戻すことができます。

• 必須レルムを使用してランタイムで表を保護できます。ランタイムで、アプリケーション・データを多くの表に格納できます。データの整合性や正確性が維持されるように、ランタイム・スキーマなどの単一ユーザーがこれらの表にアクセスする方法が適しています。アプリケーション・データが多くの異なるスキーマに分散する場合、スキーマ所有者とオブジェクト権限を持つユーザーは、データベースに直接ログインするとデータを変更できます。ユーザーがランタイム・スキーマのプロシージャを実行せずにこれらの表を更新できないように、必須レルムを使用して表を保護し、認可されたユーザーのプロシージャのみがアクセスするようにできます。通常のレルムはオブジェクト所有者とオブジェクト権限ユーザーをブロックしないため、必須レルムを使用してこれらをブロックできます。このように、認可されたユーザーのみがランタイムでこれらの表にアクセスできます。

• 構成済のロールに対する変更を禁止することで、セキュリティ設定を固定できます。

同じオブジェクトに必須レルムが複数ある場合、保護されたオブジェクトにアクセスするには、すべての必須レルムに対してユーザーまたはロールを認可する必要があります。

4.1.3 マルチテナント環境におけるレルム

マルチテナント環境では、アプリケーション・ルート内の共通オブジェクトを保護するためにレルムを作成できます。

個々のプラガブル・データベース(PDB)内でこれらのオブジェクトの周りに多数のオブジェクトおよびレルムを作成するのでなく、アプリケーション・ルートでレルムを作成する利点は、それらをアプリケーション・ルートという1つの場所で作成できるということです。このような方法で、それらを一元的に管理できます。

CDBルートでは、共通レルムは作成できません。

Database Vaultの共通レルムは、通常レルムか必須レルムのどちらかにできます。このレルムは、PDB内のローカル・オブジェクトではなく、アプリケーション・ルート内のオブジェクトのみを保護します。CDBルート、アプリケーション・ルート、および影響を受けるPDBはすべて、Database Vaultに対応している必要があります。

共通レルムを構成するには、一般に、DV_OWNERまたはDV_ADMINロールが付与されている必要があります。共通レルムの共通認可を付与するには、アプリケーション・ルートにいる必要があります。アプリケーション・ルートに関連付けられているPDBにレルムを伝播するには、アプリケーション・ルートを同期させる必要があります。たとえば、saas_sales_appというアプリケーションを同期させるには、次のようにします。

ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app SYNC;

4.1.4 レルムで保護できるオブジェクト・タイプ

特定のオブジェクト・タイプのスキーマ内のすべてのオブジェクトの周りにレルムを作成できます。

これらのオブジェクト・タイプは、次のとおりです。

オブジェクト・タイプC-J	オブジェクト・タイプL-P	オブジェクト・タイプR-V
CLUSTER	LIBRARY	ROLE
DIMENSION	MATERIALIZED VIEW	SEQUENCE
FUNCTION	MATERIALIZED VIEW LOG	SYNONYM
INDEX	OPERATOR	TABLE
INDEX PARTITION	PACKAGE	TRIGGER
INDEXTYPE	PROCEDURE	TYPE
JOB	PROGRAM	VIEW

4.2 デフォルトのレルム

Oracle Database Vaultには、Database VaultおよびSYS関連のスキーマ、システム権限とオブジェクト権限、ロールおよび監査関連オブジェクトを保護するためのデフォルト・レルムが用意されています。

デフォルトのレルムで保護されているタスクをユーザーが実行できるように、ユーザーをレルムに追加できます。

• Oracle Database Vaultレルム
  Oracle Database Vaultレルムは、Oracle Database VaultのDVSYS、DVFおよびLBACSYSの各スキーマの構成およびロール情報を保護します。
• Database Vaultアカウント管理レルム
  Database Vaultアカウント管理レルムは、データベース・アカウントとデータベース・プロファイルを管理および作成する管理者のレルムを定義します。
• Oracle Enterprise Managerレルム
  Oracle Database Vaultには、Oracle Enterprise Managerモニタリング・アカウント専用のレルムが用意されています。
• Oracleデフォルト・スキーマ保護レルム
  Oracleデフォルト・スキーマ保護レルムは、Oracle TextなどOracleの機能で使用されるロールおよびスキーマを保護します。
• Oracleシステム権限およびロール管理レルム
  Oracleシステム権限およびロール管理レルムは、Oracleデータベース内にあるすべてのOracle提供ロールを保護します。
• Oracleデフォルト・コンポーネント保護レルム
  Oracleデフォルト・コンポーネント保護レルムは、SYSTEMスキーマとOUTLNスキーマを保護します。

4.2.1 Oracle Database Vaultレルム

Oracle Database Vaultレルムは、Oracle Database VaultのDVSYS、DVFおよびLBACSYSの各スキーマの構成およびロール情報を保護します。

DVSYS、DVFおよびLBACSYSの3つのすべてのスキーマの所有者は、このレルムの所有者です。

このレルムで保護されているオブジェクトを検索するには、次の問合せを実行します。

SELECT OWNER, OBJECT_NAME, OBJECT_TYPE 
FROM DBA_DV_REALM_OBJECT
WHERE REALM_NAME = 'Oracle Database Vault Realm'
ORDER BY OWNER, OBJECT_NAME;

レルム認可ユーザー、その(参加者または所有者としての)ロール、およびOracle Database Vaultルール・セットが認可ユーザーに適用されているかどうかを検索するには、次の問合せを実行します。

SELECT GRANTEE, AUTH_OPTIONS, AUTH_RULE_SET_NAME 
FROM DBA_DV_REALM_AUTH
WHERE REALM_NAME = 'Oracle Database Vault Realm'
ORDER BY GRANTEE;

4.2.2 Database Vaultアカウント管理レルム

Database Vaultアカウント管理レルムは、データベース・アカウントとデータベース・プロファイルを管理および作成する管理者のレルムを定義します。

このレルムの所有者は、ユーザーに対してCREATE SESSION権限の付与と取消しを行うことができます。

このレルムが保護するオブジェクトを検索するには、次の問合せを実行します。

SELECT OWNER, OBJECT_NAME, OBJECT_TYPE 
FROM DBA_DV_REALM_OBJECT
WHERE REALM_NAME = 'Database Vault Account Management'
ORDER BY OWNER, OBJECT_NAME;

レルム認可ユーザー、その参加者としてのロールまたは所有者としてのロールを検索する際に、Oracle Database Vaultルール・セットが認可ユーザーに適用されている場合は、次の問合せを実行します。

SELECT GRANTEE, AUTH_OPTIONS, AUTH_RULE_SET_NAME 
FROM DBA_DV_REALM_AUTH
WHERE REALM_NAME = 'Database Vault Account Management'
ORDER BY GRANTEE;

4.2.3 Oracle Enterprise Managerレルム

Oracle Database Vaultには、Oracle Enterprise Managerモニタリング・アカウント専用のレルムが用意されています。

Oracle Enterprise Managerレルムは、監視と管理に使用されるOracle Enterprise Managerアカウント(DBSNMPユーザーおよび OEM_MONITORロール)を保護します。

このレルムが保護するオブジェクトを検索するには、次の問合せを実行します。

SELECT OWNER, OBJECT_NAME, OBJECT_TYPE 
FROM DBA_DV_REALM_OBJECT
WHERE REALM_NAME = 'Oracle Enterprise Manager'
ORDER BY OWNER, OBJECT_NAME;

レルム認可ユーザー、その参加者としてのロールまたは所有者としてのロールを検索する際に、Oracle Database Vaultルール・セットが認可ユーザーに適用されている場合は、次の問合せを実行します。

SELECT GRANTEE, AUTH_OPTIONS, AUTH_RULE_SET_NAME 
FROM DBA_DV_REALM_AUTH
WHERE REALM_NAME = 'Oracle Enterprise Manager'
ORDER BY GRANTEE;

4.2.4 Oracleデフォルト・スキーマ保護レルム

Oracleデフォルト・スキーマ保護レルムは、Oracleの機能(Oracle Textなど)で使用されるロールやスキーマを保護します。

このグループ分けには、Oracle Spatialスキーマ(MDSYS、MDDATA)がOracle Text(CTXSYS)で拡張して使用されるメリットと、Oracle OLAPがコアOracle Databaseカーネル機能ではなくアプリケーションになるメリットがあります。

Oracleデフォルト・スキーマ保護レルムでは、いくつかのロールとスキーマが保護されます。

• このレルムが保護するオブジェクトを検索するには、次の問合せを実行します。

  SELECT OWNER, OBJECT_NAME, OBJECT_TYPE 
  FROM DBA_DV_REALM_OBJECT
  WHERE REALM_NAME = 'Oracle Default Schema Protection Realm'
  ORDER BY OWNER, OBJECT_NAME;

• レルム認可ユーザー、その参加者としてのロールまたは所有者としてのロールを検索する際に、Oracle Database Vaultルール・セットが認可ユーザーに適用されている場合は、次の問合せを実行します。

  SELECT GRANTEE, AUTH_OPTIONS, AUTH_RULE_SET_NAME 
  FROM DBA_DV_REALM_AUTH
  WHERE REALM_NAME = 'Oracle Default Schema Protection Realm'
  ORDER BY GRANTEE;

• デフォルトで保護されるスキーマ: 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

SYS、CTXSYSおよびEXFSYSユーザーは、Oracleデフォルト・スキーマ保護レルムのデフォルトの所有者です。これらのユーザーは、このレルムで保護されるロールを他のユーザーに付与して、そのスキーマに対する権限も他のユーザーに付与できます。

4.2.5 Oracleシステム権限およびロール管理レルム

Oracleシステム権限およびロール管理レルムは、Oracleデータベース内にあるすべてのOracle提供ロールを保護します。

このレルムには、システム権限を付与する必要があるユーザーの認可も含まれます。

ユーザーSYSは、このレルムの唯一のデフォルトの所有者です。システム権限の管理を担当するどのユーザーも、このレルムの所有者として認可される必要があります。これらのユーザーは、このレルムで保護されるロールを他のユーザーに付与できます。

Oracleシステム権限およびロール管理レルムで保護されるロールの例としては、DBA、IMP_FULL_DATABASE、SELECT_CATALOG_ROLEおよびSCHEDULER_ADMINがあります。

このレルムが保護するオブジェクトを検索するには、次の問合せを実行します。

SELECT OWNER, OBJECT_NAME, OBJECT_TYPE 
FROM DBA_DV_REALM_OBJECT
WHERE REALM_NAME = 'Oracle System Privilege and Role Management Realm'
ORDER BY OWNER, OBJECT_NAME;

レルム認可ユーザー、その参加者としてのロールまたは所有者としてのロールを検索する際に、Oracle Database Vaultルール・セットが認可ユーザーに適用されている場合は、次の問合せを実行します。

SELECT GRANTEE, AUTH_OPTIONS, AUTH_RULE_SET_NAME 
FROM DBA_DV_REALM_AUTH
WHERE REALM_NAME = 'Oracle System Privilege and Role Management Realm'
ORDER BY GRANTEE;

4.2.6 Oracleデフォルト・コンポーネント保護レルム

Oracleデフォルト・コンポーネント保護レルムは、SYSTEMスキーマとOUTLNスキーマを保護します。

このレルムの認可されたユーザーは、ユーザーSYSとSYSTEMです。

このレルムが保護するオブジェクトを検索するには、次の問合せを実行します。

SELECT OWNER, OBJECT_NAME, OBJECT_TYPE 
FROM DBA_DV_REALM_OBJECT
WHERE REALM_NAME = 'Oracle Default Component Protection Realm'
ORDER BY OWNER, OBJECT_NAME;

レルム認可ユーザー、その参加者としてのロールまたは所有者としてのロールを検索する際に、Oracle Database Vaultルール・セットが認可ユーザーに適用されている場合は、次の問合せを実行します。

SELECT GRANTEE, AUTH_OPTIONS, AUTH_RULE_SET_NAME 
FROM DBA_DV_REALM_AUTH
WHERE REALM_NAME = 'Oracle Default Component Protection Realm'
ORDER BY GRANTEE;

4.3 レルムの作成

レルムの保護を有効にするには、レルムを作成して、レルム・セキュア・オブジェクト、ロールおよび認可を含めるようにレルムを構成します。

1. DV_OWNERまたはDV_ADMINロールおよびSELECT ANY DICTIONARY権限を付与されているユーザーとして、Cloud ControlからOracle Database Vault Administratorにログインします。ログイン方法については、「Oracle Enterprise Cloud ControlからのOracle Database Vaultへのログイン」を参照してください。
2. 「管理」ページの「Database Vaultコンポーネント」で、「レルム」をクリックします。
3. 「レルム」ページで、「作成」をクリックして「レルムの作成」ページを表示します。
   
   
   図create_realm122.pngの説明
   
4. 「レルムの作成」ページで、次の設定を入力します。

   • 名前: レルムの名前を入力します。大/小文字の両方を使用して90文字以内で指定できます。この属性は必須です。

     保護されているアプリケーションの名前をレルム名として使用することをお薦めします(人事アプリケーションにはhr_appなど)。

   • 説明: レルムの簡単な説明を入力します。説明は大/小文字混在で最大で1024文字まで入力できます。この属性はオプションです。

     説明には、指定されたアプリケーション保護のビジネス目標や、レルムによる保護の重要性を示すその他のすべてのセキュリティ・ポリシーを含めることができます。また、レルムに対して認可されているユーザーとその目的、および緊急時の認可についても説明できます。

   • 必須レルム: レルムを必須レルムとして作成するには、このチェック・ボックスを選択します。必須レルムの詳細は、「必須レルムによるレルム内のオブジェクトへのユーザー・アクセスの制限」を参照してください。

   • ステータス: 「有効」、「無効」または「シミュレーション」のいずれかを選択します。この属性は必須です。

   • 監査オプション: 次のいずれかを選択します。

     • 監査無効: 監査レコードは作成されません。

     • 成功時に監査: 認可されたアクティビティの監査レコードが作成されます。

     • 失敗時に監査: 認可されていないユーザーがレルムによって保護されているオブジェクトの変更を試行するというようなレルム違反が発生した場合に、監査レコードが作成されます。

     • 成功時または失敗時に監査: アクティビティが認可されている場合でも認可されていない場合でも、レルム内で発生したすべてのアクティビティに関する監査レコードが作成されます。

     非統合監査環境では、Oracle Database Vaultは、監査証跡をDVSYS.AUDIT_TRAIL$表に書き込みます。詳細は、「Oracle Database Vaultの監査」を参照してください。統合監査が有効な場合、この設定では監査レコードは取得されません。かわりに、『Oracle Databaseセキュリティ・ガイド』の説明に従い、この情報を取得する監査ポリシーを作成する必要があります。Oracle Databaseでは、デフォルト・ポリシーORA_DV_AUDPOLも用意されています。これは、Oracle Database VaultのDVSYSおよびDVFスキーマ・オブジェクトと、Oracle Label SecurityのLBACSYSスキーマ・オブジェクトに対して実行されるすべてのアクションを監査します。

5. 「次へ」をクリックして、「レルム・セキュア・オブジェクト」ページを表示します。

   このページの設定の概念的な詳細は、「レルム・セキュア・オブジェクトについて」を参照してください。

6. 「追加」ボタンをクリックして、「セキュア・オブジェクトの追加」ダイアログ・ボックスで次の情報を入力します。

   • オブジェクト所有者: リストから、データベース・スキーマ所有者の名前を選択します。レルムで保護するオブジェクトがロールの場合、%文字を入力できます。この属性は必須です。

   • オブジェクト・タイプ: リストから、TABLE、INDEXまたはROLEなどのデータベース・オブジェクトのタイプを選択します。この属性は必須です。

     任意のタイプのオブジェクトを必要なだけレルムに追加できます。

     デフォルトで、「オブジェクト・タイプ」ボックスには%ワイルドカード文字が入力されており、指定されたオブジェクト所有者にすべてのオブジェクト・タイプを含めることができます。ただし、データベースに特定のスキーマ所有者がいないロールは含まれず、明示的に指定する必要があります。

   • オブジェクト名: レルムで保護する必要があるデータベースのオブジェクトの名前を入力するか、%を入力して、指定したオブジェクト所有者のすべてのオブジェクト(ロール以外)を指定します。%を入力する場合は、%が「オブジェクト・タイプ」設定に対しても使用されていると、それにスキーマ内のすべてのオブジェクトを含めることができます。ただし、「オブジェクト・タイプ」が「表」に設定されている場合、「オブジェクト名」に対する%の使用は、スキーマ内のすべての表を表します。この属性は必須です。

     デフォルトで、「オブジェクト名」フィールドには%ワイルドカード文字が入力されており、オブジェクト・タイプおよびオブジェクト所有者に指定されているスキーマ全体を含めることができます。%ワイルドカード文字は、現在存在するオブジェクトだけでなく、まだ存在していないオブジェクトにも適用されることに注意してください。

     %を「オブジェクト名」フィールドに入力する場合は、%を「オブジェクト・タイプ」フィールドにも入力していると、それにスキーマ内のすべてのオブジェクトが含まれます。ただし、「オブジェクト・タイプ」を「表」などの特定のオブジェクト・タイプに設定した場合、「オブジェクト・タイプ」を%に設定すると、スキーマ内のそのタイプ(この場合は表)のすべてのオブジェクトを表します。

7. 「次へ」をクリックして、「レルム認可」ページを表示します。

   このページの設定の概念的な詳細は、「レルム認可について」を参照してください。

8. 「追加」ボタンをクリックして、「認可の追加」ダイアログ・ボックスで次の情報を入力します。

   • レルム認可の権限受領者: リストから、レルム認可を付与するデータベース・アカウントまたはロールを選択します。

     このリストには、システム権限のあるアカウントのみでなく、システム内のすべてのアカウントおよびロールが表示されます。

   • レルム認可タイプ: 次のいずれかの設定を選択します。この属性は必須です。

     • 参加者: これらの権限が標準のOracle Database権限付与プロセスを使用して付与されている場合、このアカウントまたはロールは、レルムで保護されているオブジェクトに対するアクセス、操作および作成を行うためのシステム権限を使用できます。1つのレルムには複数の参加者を設定できます。

     • 所有者: このアカウントまたはロールには、レルムの参加者と同じ権限に加えて、レルム・セキュア・データベース・ロールを付与または取り消す認可があります。レルム所有者は、他のユーザーに対して、レルム保護オブジェクトの権限の付与または取消しを行うことができます。1つのレルムに複数の所有者を設定できます。

   • レルム認可ルール・セット: サイトに作成された使用可能なルール・セットから選択します。選択できるのは1つのルール・セットのみですが、ルール・セットには複数のルールがあります。

     ルールを定義することによるレルム認可の制御の詳細は、「ルール・セットに追加するルールの作成」を参照してください。

     ルール・セットに関連付けられている監査およびカスタム・イベント処理は、レルム認可処理の一部として発生します。

9. 「次へ」をクリックして確認ページを表示します。
10. 「確認」ページで、作成した設定を確認します。

    たとえば:

    
    
    図realm_creation122.pngの説明
    
11. 「終了」をクリックして、レルムの作成を完了します。

4.4 レルム・セキュア・オブジェクトについて

レルム・セキュア・オブジェクトにより、レルムによって保護されるテリトリ(一連のスキーマおよびデータベースのオブジェクト、およびロール)が定義されます。

次のような保護方法があります。

• 複数のデータベース・アカウントまたはスキーマのオブジェクトを同じレルムに追加できます。

• 1つのオブジェクトは複数のレルムに属することができます。

  オブジェクトが複数のレルムに属する場合、Oracle Database Vaultは、適切な認可があるかどうかレルムを確認します。SELECT、DDLおよびDML文の場合、ユーザーがいずれかのレルムの参加者であり、コマンド・ルールで許可されれば、そのユーザーが入力するコマンドは許可されます。複数のレルムにおけるデータベース・ロールによるGRANTおよびREVOKE操作の場合、GRANTまたはREVOKE操作を実行するユーザーはレルムの所有者である必要があります。スキーマ所有者は、複数の通常レルムに保護されたオブジェクトに対してDML操作を行うことができます。

  いずれかのレルムが必須レルムの場合、オブジェクトにアクセスするユーザーは、レルム所有者か必須レルムの参加者である必要があります。認可チェック・プロセスでは、必須レルムではないレルムは無視されます。オブジェクトを保護する必須レルムが複数ある場合、オブジェクトにアクセスするユーザーは、すべての必須レルムで認可される必要があります。

• SYS所有オブジェクトは、データ・ディクショナリ保護によってすでに保護されており、Oracle Database Vaultによって個別に保護されてはいません。

4.5 レルム認可について

レルム認可では、レルムで保護されているオブジェクトの管理またはアクセスを実行する一連のデータベース・アカウントおよびロールを決定します。

次の状況でシステム権限を使用できるように、レルム認可をアカウントまたはロールに付加できます。

• レルム・セキュア・オブジェクトの作成またはレルム・セキュア・オブジェクトへのアクセスが必要な場合

• レルム・セキュア・ロールを付与または取り消す必要がある場合

レルム所有者またはレルム参加者としてレルム認可を付与されたユーザーは、システム権限を使用してレルム内のセキュア・オブジェクトにアクセスできます。

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

• レルム所有者は、自分のレルムに他のユーザーを所有者または参加者として追加できません。DV_OWNERまたはDV_ADMINロールのあるユーザーのみ、所有者または参加者としてユーザーをレルムに追加できます。

• DV_OWNERロールを付与されているユーザーは、自分自身をレルム認可に追加できます。

• レルム所有者(ただし、レルム参加者ではない)は、レルム・セキュア・ロールの付与または取消し、あるいはレルム・セキュア・オブジェクトに対するオブジェクト権限の付与または取消しを誰に対しても行うことができます。

• ユーザーはレルム所有者またはレルム参加者のいずれかとして付与されますが、両方を付与されることはありません。また一方で、既存のレルム認可の認可タイプを更新できます。

「レルムの編集: HR Realm」ページを使用して、レルム認可を管理します。レルム認可を作成、編集および削除できます。

4.6 マルチテナント環境におけるレルム認可

マルチテナント環境では、共通レルム認可のルールおよび動作は、他の共通オブジェクトの認可と同様です。

共通レルムのローカル認可

共通レルムのローカル認可とは、ユーザーがアクセスしているPDBのためにこのユーザーが保持している認可のことを指します。

共通レルムのローカル認可のルールは、次のとおりです。

• DV_OWNERまたはDV_ADMINロールを共通で付与されているユーザーは、共通ユーザー、共通ロール、ローカル・ユーザーおよびローカル・ロールにローカル認可を付与できます。共通DV_OWNERまたはDV_ADMINユーザーは、PDB内の共通レルムからローカル認可を削除することもできます。

• ローカルDatabase Vault管理者は、PDB内のローカルで認可できます(つまり、ローカル認可をローカル・ユーザーと共通ユーザーの両方に付与する)。また、共通Database Vault管理者は、各PDBで認可を付与できます。共通レルム認可は、アプリケーション・ルートで共通Database Vault管理者のみが付与できます。

• 共通Database Vault管理者は、ローカル認可を、PDB内から共通レルムに追加することも、それから削除することもできます。

• 共通ユーザーに共通レルムのローカル認可しかない場合、このユーザーは、このローカル認可以外のPDB内の共通レルムにはアクセスできません。

• 共通ユーザーまたは共通ロールは、共通レルムへのローカル認可と共通認可の両方を同時に保持できます。共通レルムから共通ユーザーのローカル認可を削除しても、共通ユーザーの共通認可には影響しません。共通レルムから共通ユーザーの共通認可を削除しても、共通ユーザーのローカル認可には影響しません。

共通レルムの共通認可

共通レルムの共通認可とは、Database Vaultに対応しているすべてのコンテナで認可が有効になっていると同時に、共通ユーザーまたは共通ロールがアプリケーション・ルートで保持している認可のことを指します。

共通レルムのローカル認可のルールは、次のとおりです。

• DV_OWNERまたはDV_ADMINロールを共通で付与されているユーザーは、アプリケーション・ルート内の共通ユーザーまたはロールに共通レルム認可を付与できます。この共通Database Vault管理者は、アプリケーション・ルート内にいながら、共通認可の削除を実行できます。

• この共通認可は、CDB内の、Database Vaultに対応しているコンテナに適用されます。

• 共通ユーザーにアプリケーション・ルート内の共通レルムに対する権限がある場合、このユーザーは、アプリケーション・ルート内およびアプリケーションPDB内の共通レルムによって保護されているオブジェクトにアクセスできます。

• 共通レルムに関連付けられているルール・セットは、共通ルール・セットである必要があります。共通認可に関連付けられている共通ルール・セットに追加されるルールに、ローカル・オブジェクトを含めることはできません。

アプリケーション・ルート内と個々のPDB内でのレルムの認可の動作

コンテナでのDatabase Vault強制の間に、共通レルムは、それがPDBでローカルで使用される場合の同じレルムと同じ強制動作を実行します。

4.7 レルムの有効化ステータスの変更

Enterprise Manager Cloud Controlから、レルムを無効または有効にすることや、シミュレーション・モードを使用するようレルムを設定することができます。

レルムがポリシーによって管理されており、ポリシー・ステータスが部分になっている場合は、レルムの有効化ステータスを変更できます。ポリシーが有効、無効またはシミュレーション・モードに設定されている場合、レルムの有効化ステータスは変更できません。

1. Oracle Database Vaultの「管理」ページで、「レルム」を選択します。
2. 「レルム」ページで無効または有効にするレルムを選択し、「編集」を選択します。
3. 「レルムの編集」ページの「一般」セクションの「ステータス」の下で、「無効」、「有効」または「シミュレーション」のいずれかを選択します。
4. 「完了」、「終了」の順にクリックします。

4.8 レルムの削除

Enterprise Manager Cloud Controlを使用して、レルムを削除できます。

1. レルムに関連するOracle Database Vaultデータ・ディクショナリ・ビューに問い合せて、削除するレルムへの様々な参照を特定します。
2. レルムがポリシーの一部である場合は、ポリシーからレルムを削除します。
   1. Oracle Database Vaultの「管理」ページで、「ポリシー」を選択します。
   2. レルムを含むポリシーを選択してから、「編集」をクリックします。
   3. 「レルム」領域を展開します。
   4. レルムを選択してから、「削除」をクリックします。
   5. 「次へ」、「終了」、の順にクリックします。
3. 「管理」ページの「Database Vaultコンポーネント」で、「レルム」を選択します。
4. 「レルム」ページで削除するレルムを選択し、「削除」を選択します。
5. 「確認」ウィンドウで、「はい」をクリックします。

   Oracle Database Vaultは、レルムの構成(レルム認可を含む)を削除します。レルム認可に使用されるルール・セットは削除しません。

4.9 レルムの動作

適切な権限を持つデータベース・アカウントにより、レルム内のオブジェクトに影響するSQL文が発行されると、特定のアクティビティ・セットが発生します。

これらの権限には、DDL、DML、EXECUTE、GRANT、REVOKEまたはSELECT権限が含まれます。

1. ユーザーのオブジェクト権限は適切ですか。

   Oracle Database Vaultは、ユーザーの権限をチェックしてから、ユーザーの続行を許可します。ユーザーに適切な権限がない場合は、ユーザーにその権限を付与します。ユーザーの権限が適切な場合は、ステップ2に進みます。レルム認可では、追加の権限がユーザーに暗黙的に付与されることはありません。

2. SQL文はレルムによって保護されているオブジェクトに影響しますか。

   影響する場合は、ステップ3に進みます。実行しない場合、レルムはSQL文に影響しません。ステップ8に進みます。コマンドによって影響されるオブジェクトがレルムで保護されていない場合、レルムも実行されるSQL文には影響しません。

3. 必須レルムですか、通常のレルムですか。

   当てはまる場合は、ステップ5に進みます。通常レルムの場合は、ステップ4に進みます。

4. データベース・アカウントで、システム権限を使用してSQL文を実行しますか。

   当てはまる場合は、ステップ5に進みます。当てはまらない場合は、ステップ7に進みます。セッションが、対象となるオブジェクトに対して、SELECT、EXECUTEおよびDML文のオブジェクト権限しか持っていない場合、レルム保護は実施されません。レルムは、レルムで保護されているオブジェクトまたはロールに対するシステム権限の使用を保護します。通常レルムによって保護されているオブジェクトに関するオブジェクト権限を持つユーザーでも、DDL操作を行うことはできません。

5. データベース・アカウントは、レルム所有者またはレルム参加者ですか。

   当てはまる場合は、ステップ6に進みます。いずれでもない場合は、レルム違反が発生し、文は失敗します。コマンドがレルムで保護されているロールのGRANTかREVOKEである場合、またはレルムで保護されているオブジェクトに対するオブジェクト権限GRANTかREVOKEである場合、セッションはロールを介して直接的または間接的にレルム所有者として認可されている必要があります。

6. データベース・アカウントに対するレルム認可は、状況に応じてルール・セットに基づきますか。

   影響する場合は、ステップ7に進みます。当てはまらない場合は、ステップ8に進みます。

7. ルール・セットはTRUEに評価されますか。

   影響する場合は、ステップ8に進みます。そうでない場合は、レルム違反が発生し、SQL文は失敗します。

8. コマンド・ルールでコマンドの実行が阻止されますか。

   阻止される場合は、コマンド・ルール違反が発生し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から取り消すことをお薦めします。

4.10 レルムでの認可の動作

ユーザーに正しい権限がない場合、レルム認可により、そのユーザーによるアクティビティの実行が阻止されます。

• レルムの認可について
  レルムは、システム権限によるアクセスからデータを保護します。
• レルム認可の例
  たとえば、システム権限および他の強力な権限を持つユーザーからオブジェクトを保護するレルムを作成できます。

4.10.1 レルムの認可について

レルムは、システム権限によるアクセスからデータを保護します。

レルムは、データ所有者または参加者に追加の権限は付与しません。

レルム認可により、ユーザーのコマンドがコマンド内に指定されているオブジェクトへのアクセスや、そのコマンドの実行を許可または拒否される必要がある場合、論理的に確認する実行時メカニズムが提供されます。

システム権限は、CREATE ANY TABLEおよびDELETE ANY TABLEなどのデータベース権限より優先されます。通常これらの権限はスキーマ全体に適用されるため、オブジェクト権限の必要はありません。DBA_SYS_PRIVS、USER_SYS_PRIVSおよびROLE_SYS_PRIVSなどのデータ・ディクショナリ・ビューには、データベース・アカウントまたはロールのシステム権限が表示されています。データベース認可は、レルムに保護されていないオブジェクトを対象としています。ただし、レルムによって保護されているオブジェクトのシステム権限を正常に使用するには、ユーザーがレルム所有者または参加者として認可されている必要があります。レルム違反によりシステム権限の使用を阻止し、監査することができます。

必須レルムは、オブジェクト権限およびシステム権限に基づく両方のアクセスをブロックします。つまり、オブジェクト所有者は、レルムへのアクセスが認可されない場合、アクセスできません。ユーザーは、ユーザーまたはロールがレルムにアクセスする認可を受けている場合のみ、必須レルムのセキュア・オブジェクトにアクセスできます。

4.10.2 レルム認可の例

システム権限および他の強力な権限を持つユーザーからオブジェクトを保護するレルムを作成できます。

• 例: 認可されていないユーザーによる表作成の試行
  認可されていないユーザーが表を作成しようとすると、ORA-47401エラーが発生します。
• 例: 認可されていないユーザーによるDELETE ANY TABLE権限の使用の試行
  認可されていないユーザー・アクセスに対して、ORA-01031: 権限が不十分ですというエラーが表示されます。
• 例: 認可されたユーザーによるDELETE操作の実行
  認可されたユーザーには、認可されたアクティビティの実行が許可されます。

4.10.2.1 例: 認可されていないユーザーによる表作成の試行

権限のないユーザーが表を作成しようとすると、ORA-47401エラーが発生します。

例4-1に、レルムによってHRスキーマが保護されているレルムに、CREATE ANY TABLEシステム権限を持つ認可されていないユーザーが表の作成を試行すると発生する動作を示します。

例4-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などのシステム権限の不正な使用は失敗します。

4.10.2.2 例: 認可されていないユーザーによるDELETE ANY TABLE権限の使用の試行

認可されていないユーザー・アクセスに対して、ORA-01031: 権限が不十分ですというエラーが表示されます。

例4-2に、認可されていないデータベース・アカウントがDELETE ANY TABLEシステム権限を使用して既存のレコードの削除を試行すると発生する動作を示します。データベース・セッションにより次のエラーが返されます。

例4-2 認可されていないユーザーによるDELETE ANY TABLE権限の使用の試行

DELETE FROM HR.EMPLOYEES WHERE EMPNO = 8002;

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

ERROR at line 1:
ORA-01031: insufficient privileges

レルムはオブジェクトの直接権限には影響しません。たとえば、HR.EMPLOYEES表の削除権限を付与されているユーザーは、レルム認証なしで正常にレコードを削除できます。そのため、レルムには、データベース・アカウントによる通常のビジネス・アプリケーションの使用に最低限の影響力が必要です。

4.10.2.3 例: 認可されたユーザーによるDELETE操作の実行

認可されたユーザーには、認可されたアクティビティの実行が許可されます。

例4-3に、認可されたユーザーがレルム内で許可された標準的なタスクをどのように実行するかを示します。

例4-3 認可されたユーザーによるDELETE操作の実行

DELETE FROM HR.EMPLOYEES WHERE EMPNO = 8002;

1 row deleted.

4.11 レルムで保護されたオブジェクトへのアクセス

レルムでオブジェクトを保護できますが、このオブジェクトに含まれるオブジェクトにはアクセスできます。

たとえば、特定の表にレルムを作成するとします。ただし、この表にユーザーが索引を作成できるようにします。これは、次のシナリオに応じて次のように実行できます。

• ユーザーにCREATE ANY INDEX権限がない場合。表のレルム所有者として、索引を作成する必要のあるユーザーにCREATE INDEX ON table権限を付与します。

• ユーザーにCREATE ANY INDEX権限がある場合。この場合、別のレルムを作成して、すべての索引タイプをセキュア・オブジェクトとし、そのユーザーにレルムの参加者認可を付与します。(レルム参加者以外がレルムで保護された表に索引を作成する場合、CREATE ANY INDEXのみでは不十分なことに注意してください。)

• すべてのデータベース管理者が索引を作成できるようにし、データベース管理者にCREATE ANY INDEX権限がある場合。データ保護レルムで、索引タイプを除いて保護するすべてのオブジェクト・タイプを指定します。これにより、保護された表の索引をすべての管理者が作成できます。

4.12 レルムの動作の例

レルムにより、同じ権限のある2人のユーザーに、オブジェクトに対する別々のアクセス・レベルが必要な場合に保護を提供できます。

図4-1は、レルム内のデータがどのように保護されているかを示しています。

このシナリオでは、別々のレルムを担当する2人のユーザーに同じシステム権限があります。レルム所有者は、データベース・アカウントまたはデータベース・ロールのいずれかです。OE_ADMINおよびHR_ADMINの2つのロールのそれぞれは、セキュア・オブジェクトとしてレルムで保護され、かつレルム所有者として構成されます。

さらに、OE_ADMINなどのレルム所有者は、レルムで保護されているデータベース・ロールの付与または取消しを実行できます。レルム所有者は、他のレルムで保護されるロール(Oracleシステム権限およびロール管理レルムでSYSによって作成されるDBAロールなど)を管理できません。レルムで保護されているオブジェクトにアクセスするためにシステム権限の不正な使用を試行することで、監査可能なレルム違反が生成されます。各レルム所有者の権限はそのレルム内に制限されます。たとえば、OE_ADMINには人事レルムへのアクセス権はなく、HR_ADMINには受注レルムへのアクセス権はありません。

図4-1 レルムおよびレルム所有者に対する認可の動作

「図4-1 レルムおよびレルム所有者に対する認可の動作」の説明

4.13 その他のOracle Database Vaultコンポーネントへのレルムの影響

レルムにはファクタ、アイデンティティ、またはルール・セットに対する影響力はありませんが、コマンド・ルールに対してはあります。

コマンド・ルールでは、SQL文を処理する際にOracle Database Vaultによってまずレルム認可が評価されます。

「レルムの動作」では、レルム内のオブジェクトに影響を与えるSQL文を処理する際にOracle Database Vaultで実行されるステップが説明されています。「コマンド・ルールの動作」では、コマンド・ルールがどのように処理されるかが説明されています。

4.14 レルム設計のガイドライン

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;
  /

• 制限を適用せずにレルムを有効にする、シミュレーション・モードを使用して、レルムの開発フェーズをテストできます。シミュレーション・モードでは違反に関する詳細情報が書き込まれ、適用されたアクティビティを表示できます。DV_OWNERまたはDV_ADMINロールを持つユーザーは、DBA_DV_SIMULATION_LOGデータ・ディクショナリ・ビューを問い合せてシミュレーション・ログを表示できます。

4.15 レルムのパフォーマンスへの影響

レルムは、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チューニング・ガイド』を参照してください

4.16 レルムに関連するレポートおよびデータ・ディクショナリ・ビュー

Oracle Database Vaultには、レルムの分析に役立つ、レポートとデータ・ディクショナリ・ビューが用意されています。

表4-1では、Oracle Database Vaultレポートを示します。これらのレポートの実行方法の詳細は、「Oracle Database Vaultレポート」を参照してください。

表4-1 レルムに関連するレポート

レポート	用途
「レルムの監査」レポート	レルムの保護およびレルム認可操作により生成されたレコードが監査されます。
「レルム認可構成の問題」レポート	不完全または無効なルール・セット、またはレルムに影響する権限受領者や所有者が存在しないなどの認可構成情報が表示されます。
「ルール・セット構成の問題」レポート	ルールが定義されていないか、有効ではなく、それらを使用するレルムに影響を与える可能性があるルール・セットが表示されます。
オブジェクト権限レポート	レルムが影響するオブジェクト権限が表示されます。
権限管理 - サマリー・レポート	レルムの権限受領者および所有者の情報が示されます。
機密オブジェクト・レポート	コマンド・ルールが影響するオブジェクトが表示されます。

表4-2に、既存のレルムに関する情報を提供するデータ・ディクショナリ・ビューを示します。

表4-2 レルムに使用されるデータ・ディクショナリ・ビュー

データ・ディクショナリ・ビュー	説明
DBA_DV_REALMビュー	現行のデータベース・インスタンスで作成されたレルムが表示されます。
DBA_DV_REALM_AUTHビュー	特定のレルムのレルム・オブジェクトにアクセスするための、名前付きデータベース・ユーザー・アカウントまたはデータベース・ロール(GRANTEE)の認可が表示されます。
DBA_DV_REALM_OBJECTビュー	データベース・スキーマ、または特定のデータベース・オブジェクトが含まれている(つまり、レルムによって保護されている)スキーマのサブセットが表示されます。