1. Database Vault管理者ガイド
  2. レルムの構成

4 レルムの構成

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

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

4.1 レルムの概要

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

親トピック: レルムの構成

4.1.1 レルムについて

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

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

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

たとえば、経理部のアプリケーションで使用されるデータベース・スキーマを保護するレルムを作成できます。レルムにより、すべてのユーザーがシステム権限(SELECT ANY TABLEなど)を使用して、レルムで保護されたスキーマ・オブジェクトにアクセスすることを禁止できます。スキーマ全体がレルムで保護されている場合、すべての既存のオブジェクトと新しいオブジェクトが保護されます。これには、表、索引、プロシージャ、ビュー、パッケージなどが含まれます。通常レルムで保護されているオブジェクトに対する権限が直接付与されているユーザーは、引き続きそれらの権限付与を使用できます。たとえば、HR.EMPLOYEESに対するSELECTが付与されている場合は、通常レルムで保護されているオブジェクトに対してSELECTコマンドを実行できます。ただし、そのオブジェクトが必須レルムによって保護されている場合は、レルム認可リストのメンバーでないかぎり、SELECTコマンドの実行は許可されません。必須レルムでは、付与されるユーザーが必須レルム内で認可された参加者である必要があります。

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

  • Oracle Database Vaultに作成するレルム上でレポートを実行できます。レルムは有効または無効にしたり、レルムの違反が記録されるがアクションはブロックされないシミュレーション・モードにできます。これにより、Database Vaultレルムを使用してアプリケーションを迅速にテストできます。

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

親トピック: レルムの概要

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

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

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

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

  • 通常レルムと同様に、ロールが必須レルムによって保護されている場合は、レルム所有者を除き、保護されたロールに対して権限の付与や取消しはできません。

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

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

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

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

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

親トピック: レルムの構成

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
FROM DBA_DV_REALM_OBJECT
WHERE REALM_NAME = 'Oracle Default Schema Protection Realm'
AND OBJECT_TYPE = 'ROLE';

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

    SELECT OWNER
FROM DBA_DV_REALM_OBJECT
WHERE REALM_NAME = 'Oracle Default Schema Protection Realm'
AND OBJECT_TYPE = '%';

  • デフォルトで保護されるロール: CTXAPP、OLAP_DBA、EJBCLIENT、OLAP_USER

  • デフォルトで保護されるスキーマ: CTXSYS、EXFSYS、MDDATA、MDSYS

  • 保護をお薦めするスキーマ: 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.2.7 Oracle Label Securityレルム

Oracle Label Securityレルムは、Oracle Label Securityのスキーマおよびロールを保護します。

デフォルトでは、LBACSYSおよびDVSYSユーザーはレルムの所有者であり、LBAC_DBAロールは参加者としてレルムに認可されます。LBACSYSは、このレルムのスキーマです。

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

SELECT OWNER, OBJECT_NAME, OBJECT_TYPE 
FROM DBA_DV_REALM_OBJECT
WHERE REALM_NAME = 'Oracle Label Security'
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 Label Security'
ORDER BY GRANTEE;

親トピック: デフォルトのレルム

4.2.8 Oracle GoldenGate保護レルム

Oracle GoldenGate保護レルムは、Oracleデータベース内のGoldenGate関連オブジェクトを保護します。

デフォルトでは、GGSHAREDCAPユーザーはレルムの所有者です。

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

SELECT OWNER, OBJECT_NAME, OBJECT_TYPE 
FROM DBA_DV_REALM_OBJECT
WHERE REALM_NAME = 'Oracle GoldenGate 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 GoldenGate Protection Realm'
ORDER BY GRANTEE;

親トピック: デフォルトのレルム

4.2.9 Oracle Auditレルム

Oracle Auditレルムは、SYSスキーマのAUDSYSスキーマおよび監査関連オブジェクトを保護します。

監査関連オブジェクトには、SYS所有の表(SYS.AUD$など)、ビュー(AUDSYS.UNIFIED_AUDIT_TRAILなど)およびパッケージ(DBMS_AUDIT_MGMTなど)が含まれます。Oracle Database Vaultでは、これらのオブジェクトの変更、削除または置換の試行は許可されず、試行ごとに監査レコードが生成されます。デフォルトでは、AUDDYSスキーマのみがOracle Auditレルムに認可されており、パッチ適用中にDV_PATCH_ADMINロールを付与されたSYSユーザーが、保護されたオブジェクトを変更できます。

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

SELECT OWNER, OBJECT_NAME, OBJECT_TYPE 
FROM DBA_DV_REALM_OBJECT
WHERE REALM_NAME = 'Oracle Audit'
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 Audit'
ORDER BY GRANTEE;

関連トピック

親トピック: デフォルトのレルム

4.3 レルムの作成

レルム保護を有効化する際の最初のステップは、そのレルム自体を作成することです。その後で、レルム・セキュア・オブジェクト、ロール、および認可を追加します。

  1. DV_OWNERまたはDV_ADMINロールを付与されているユーザーとして、PDBまたはアプリケーション・ルートに接続します。
  2. DBMS_MACADM.CREATE_REALMプロシージャを実行して、レルムを作成します。
    たとえば: 
    BEGIN
 DBMS_MACADM.CREATE_REALM(
  realm_name    => 'HR Realm', 
  description   => 'Realm to protect the HR schema', 
  enabled       => DBMS_MACUTL.G_YES, 
  audit_options => DBMS_MACUTL.G_REALM_AUDIT_OFF,
  realm_type    => DBMS_MACADM.MANDATORY_REALM,
  realm_scope   => DBMS_MACUTL.G_SCOPE_LOCAL,
  pl_sql_stack  => TRUE);
END; 
/

    この時点で、レルムは作成されていますが、そのレルムはどのオブジェクトも保護していません。また、そのレルムには一切の権限がありません。

  3. DBMS_MACADM.ADD_OBJECT_TO_REALMプロシージャを実行して、オブジェクト(表やロールなど)をレルムに追加し、保護できるようにします。
    たとえば: 
    BEGIN
 DBMS_MACADM.ADD_OBJECT_TO_REALM(
  realm_name   => 'HR Realm', 
  object_owner => 'HR', 
  object_name  => 'EMPLOYEES', 
  object_type  => 'TABLE'); 
END;
/
  4. DBMS_MACADM.ADD_AUTH_TO_REALMプロシージャを実行して、レルムに対してユーザーを認可します。
    たとえば: 
    BEGIN
 DBMS_MACADM.ADD_AUTH_TO_REALM(
  realm_name    => 'HR Realm', 
  grantee       => 'HR', 
  rule_set_name => 'Enabled',
  auth_options  => DBMS_MACUTL.G_REALM_AUTH_OWNER,
  auth_scope    => DBMS_MACUTL.G_SCOPE_LOCAL);
END;
/

関連トピック

親トピック: レルムの構成

4.4 レルムの変更

DBMS_MACADM.UPDATE_REALMプロシージャを使用すると、レルムの定義を変更できます。

  1. DV_OWNERまたはDV_ADMINロールを付与されているユーザーとして、PDBまたはアプリケーション・ルートに接続します。
  2. レルム名を検索して、その定義を確認します。
    たとえば:
    SELECT NAME, DESCRIPTION, ENABLED, AUDIT_OPTIONS, REALM_TYPE 
FROM DBA_DV_REALM ORDER BY NAME;

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

  3. DBMS_MACADM.UPDATE_REALM文を実行します。
    たとえば: 
    BEGIN
 DBMS_MACADM.UPDATE_REALM(
  realm_name    => 'HR Realm', 
  description   => 'Realm to protect the HR schema', 
  enabled       => DBMS_MACUTL.G_YES, 
  audit_options => DBMS_MACUTL.G_REALM_AUDIT_OFF, 
  realm_type    => DBMS_MACADM.MANDATORY_REALM),
  pl_sql_stack  => TRUE;
END;
/

関連トピック

親トピック: レルムの構成

4.5 レルムの削除

DBMS_MACADM.DELETE_REALMプロシージャを使用して、レルムを削除できます。

レルムを削除すると、そのレルムに対して作成されたすべての関連も削除されます。
  1. DV_OWNERまたはDV_ADMINロールを付与されているユーザーとして、PDBまたはアプリケーション・ルートに接続します。
  2. 削除するレルムの名前を検索します。
    SELECT NAME FROM DBA_DV_REALM 
ORDER BY NAME;
  3. オプションで、レルムを削除する前に、レルムの定義を確認します。
    • レルムへのオブジェクト参照を確認するには、DBA_DV_REALM_OBJECTデータ・ディクショナリ・ビューを問い合せます。次に例を示します。
      SELECT OBJECT_OWNER, OBJECT_NAME, OBJECT_TYPE 
FROM DBA_DV_REALM_OBJECT 
WHERE REALM_NAME = 'HR Realm'; 

OBJECT_OWNER  OBJECT_NAME  OBJECT_TYPE
–-----------  –----------  –-----------
HR            EMPLOYEES    TABLE

      レルムからオブジェクトのみを削除する場合は、DBMS_MACADM.DELETE_OBJECT_FROM_REALMプロシージャを実行できます。

    • レルムの認可を検索するには、DBA_DV_REALM_AUTHデータ・ディクショナリ・ビューを問い合せます。次に例を示します。
      SELECT GRANTEE, AUTH_OPTIONS 
FROM DBA_DV_REALM_AUTH 
WHERE REALM_NAME = 'HR Realm'; 

GRANTEE  AUTH_OPTIONS
–------  –------------------------
HR       DBMS_MACUTL.G_SCOPE_LOCAL

      DBMS_MACADM.DELETE_AUTH_FROM_REALMプロシージャを実行して、認可を削除できます。

    • レルムに関連付けられているポリシーを検索するには、DBA_DV_POLICY_OBJECTデータ・ディクショナリ・ビューを問い合せます。次に例を示します。
      SELECT POLICY_NAME, COMMAND_OBJ_NAME 
FROM DBA_DV_POLICY_OBJECT 
WHERE COMMAND_OBJ_NAME = 'HR Realm';

      DBMS_MACADM.DELETE_REALM_FROM_POLICYを実行して、ポリシーからレルムを削除できます。

  4. DBMS_MACADM.DELETE_REALMプロシージャを実行して、レルムを削除します。
    たとえば:
    EXEC DBMS_MACADM.DELETE_REALM('HR Realm');

関連トピック

親トピック: レルムの構成

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

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

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

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

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

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

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

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

親トピック: レルムの構成

4.7 レルム認可について

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

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

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

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

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

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

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

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

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

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

関連トピック

親トピック: レルムの構成

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

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

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

共通レルムのローカル認可とは、ユーザーがアクセスしている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.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 レルム認可の例

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

親トピック: レルムでの認可の動作

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-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などのツールを実行します。

関連トピック

親トピック: レルムの構成

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

Oracle Enterprise ManagerとOracle Database Vaultを一緒に使用すると、レルムの分析に役立つレポートおよびデータ・ディクショナリ・ビューが提供されます。

表4-1では、Oracle Database Vaultレポートを示します。

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

レポート 用途

「レルムの監査」レポート

レルムの保護およびレルム認可操作により生成されたレコードが監査されます。

「レルム認可構成の問題」レポート

不完全または無効なルール・セット、またはレルムに影響する権限受領者や所有者が存在しないなどの認可構成情報が表示されます。

「ルール・セット構成の問題」レポート

ルールが定義されていないか、有効ではなく、それらを使用するレルムに影響を与える可能性があるルール・セットが表示されます。

すべてのオブジェクト権限レポート

レルムが影響するオブジェクト権限をリストします

権限管理サマリー・レポート

レルムの権限受領者および所有者の情報を提供します

機密オブジェクト・レポート

コマンド・ルールが影響するオブジェクトが表示されます。

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

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

データ・ディクショナリ・ビュー 説明

DBA_DV_REALM

現行のデータベース・インスタンスで作成されたレルムが表示されます。

DBA_DV_REALM_AUTH

特定のレルムのレルム・オブジェクトにアクセスするための、名前付きデータベース・ユーザー・アカウントまたはデータベース・ロール(GRANTEE)の認可が表示されます。

DBA_DV_REALM_OBJECT

データベース・スキーマ、または特定のデータベース・オブジェクトが含まれている(つまり、レルムによって保護されている)スキーマのサブセットが表示されます。

関連トピック

親トピック: レルムの構成