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

4 レルムの構成

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

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

レルムの概要

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

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

レルムについて

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

レルムは、データベース・オブジェクトの保護ゾーンとみなすことができます。スキーマは、表、ビューおよびパッケージなどのデータベース・オブジェクトの論理的な集合で、ロールは権限の集合です。スキーマおよびロールを機能グループに分類することにより、システム権限を使用するユーザーがこれらのグループに対して行える操作を制御し、データベース管理者またはシステム権限を持つその他の強力なユーザーによる不正なデータ・アクセスを防ぐことができます。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操作を実行可能かを制御できます。

スキーマ、スキーマ内の特定のタイプのすべてのオブジェクト、またはスキーマ内の個々のオブジェクトをレルムに登録できます。レルムを作成すると、レルムで保護する一連のスキーマ・オブジェクトまたはロール(セキュア・オブジェクト)を登録し、セキュア・オブジェクトにアクセスする一連のユーザーやロールを認可できます。通常レルムで保護されるオブジェクトは、直接オブジェクト権限を持つユーザーからのDMLアクセスを許可します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

関連トピック

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

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

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

個々のプラガブル・データベース(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;

関連トピック

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

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

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

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

オブジェクト・タイプ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

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

デフォルトのレルム

Oracle Database Vaultには、通常のレルムであり、必須レルムではないデフォルト・レルムが用意されています。

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

Oracle Database Vaultレルム

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

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

このレルムは次のオブジェクトを保護します。

  • 保護されるスキーマ全体: DVSYS、DVF、LABACSYS

  • 保護されるロール:

    スキーマDV_A-DV_S スキーマDV_P-L スキーマDV_G-DV_X

    DV_ADMIN

    DV_MONITOR

    DV_GOLDENGATE_ADMIN

    DV_AUDIT_CLEANUP

    DV_PATCH_ADMIN

    DV_GOLDENGATE_REDO_ACCESS

    DV_DATAPUMP_NETWORK_LINK

    DV_PUBLIC

    DV_XSTREAM_ADMIN

    DV_OWNER

    DV_STREAMS_ADMIN

    -

    DV_SECANALYST

    LBAC_DBA

    -

  • 保護されるPL/SQLパッケージ: SYS.DBMS_RLS

関連トピック

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

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

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

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

関連トピック

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

Oracle Enterprise Managerレルム

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

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

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

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

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

このグループ分けには、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システム権限およびロール管理レルムは、Oracle Database内のデータのエクスポートとインポートに使用される機密ロールをすべて保護します。

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

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

  • デフォルトで保護されるロール:

    ロールA-E ロールG-J ロールJ-S

    AQ_ADMINISTRATOR_ROLE

    GATHER_SYSTEM_STATISTICS

    JAVAUSERPRIV

    AQ_USER_ROLE

    GLOBAL_AQ_USER_ROLE

    LOGSTDBY_ADMINISTRATOR

    DBA

    HS_ADMIN_ROLE

    OPTIMIZER_PROCESSING_RATE

    DBA_OLS_STATUS

    IMP_FULL_DATABASE

    RECOVERY_CATALOG_OWNER

    DELETE_CATALOG_ROLE

    JAVA_ADMIN

    RESOURCE

    DV_REALM_OWNER

    JAVADEBUGPRIV

    SCHEDULER_ADMIN

    DV_REALM_RESOURCE

    JAVA_DEPLOY

    SELECT_CATALOG_ROLE

    EXECUTE_CATALOG_ROLE

    JAVAIDPRIV

    -

    EXP_FULL_DATABASE

    JAVASYSPRIV

    -

  • 保護をお薦めするロール: DBFS_ROLE、HS_ADMIN_EXECUTE_ROLE、HS_ADMIN_SELECT_ROLE

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

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

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

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

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

レルムの作成

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

  1. DV_OWNERまたはDV_ADMINロールを付与されているユーザーとして、PDBまたはアプリケーション・ルートに接続します。
    次に例を示します。 
    CONNECT c##sec_admin_owen@pdb_name
Enter password: password

    使用可能なPDBを確認するには、DBA_PDBSデータ・ディクショナリ・ビューのPDB_NAME列を問い合せます。現在のコンテナを確認するには、show con_nameコマンドを実行します。

  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    => 1,
  realm_scope   => DBMS_MACUTL.G_SCOPE_LOCAL,
  pl_sql_stack  => TRUE);
END; 
/

    詳細は、次のとおりです。

    • realm_nameは、大文字小文字の両方を使用して128文字以内で指定できます。保護されているアプリケーションの名前をレルム名として使用することをお薦めします(人事アプリケーションにはhr_appなど)。このパラメータは必須です。DBA_DV_REALMデータ・ディクショナリ・ビューには、既存のレルムがリストされます。
    • descriptionは、大/小文字混在で1024文字まで指定できます。説明には、指定されたアプリケーション保護のビジネス目標や、レルムによる保護の重要性を示すその他のすべてのセキュリティ・ポリシーを含めることができます。また、レルムに対して認可されているユーザーとその目的、および緊急時の認可についても説明できます。
    • enabledレルムの確認を制御します。有効な設定は、レルムのチェックを有効にする場合(デフォルト)のDBMS_MACUTL.G_YES 'y'、シミュレーション・ログでの違反の取得も含めてすべてのレルムのチェックを無効にする場合のDBMS_MACUTL.G_NOまたは'n'、またはSQL文の実行を有効にしてシミュレーション・ログで違反を取得する場合の DBMS_MACUTL.G_SIMULATIONまたは's'です。
    • audit_optionsは、従来の監査にのみ適用されます。統合監査環境には適用されません。Oracle Databaseリリース20c以降では、従来の監査は非推奨になりました。audit_optionsではなく、統合監査ポリシーを作成するようにお薦めします。

      有効なaudit_optionsの設定は、DBMS_MACUTL.G_REALM_AUDIT_OFF、DBMS_MACUTL.G_REALM_AUDIT_FAIL、DBMS_MACUTL.G_REALM_AUDIT_SUCCESS、およびDBMS_MACUTL.G_REALM_AUDIT_FAIL + DBMS_MACUTL.G_REALM_AUDIT_SUCCESSです。

    • realm_typeでは、レルムが必須(1)または必須でない(0)のどちらかを定義します。必須に設定すると、レルム所有者またはレルム参加者のみがレルム内のオブジェクトにアクセスできます。レルム所有者や参加者ではないオブジェクト所有者およびオブジェクト権限ユーザーはアクセスできません。
    • realm_scopeでは、レルムがPDB (DBMS_MACUTL.G_SCOPE_LOCAL)とアプリケーション・ルート(DBMS_MACUTL.G_SCOPE_COMMON)のどちらに作成されるかを定義します。アプリケーション・ルートで共通レルムを作成し、関連付けられたPDBにそれを表示できるようにする場合は、アプリケーションを同期させる必要があります。次に例を示します。
      ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app SYNC;
    • pl_sql_stackは、シミュレーション・モードに使用します。有効(TRUE)な場合は、失敗した操作のPL/SQLスタックを記録するかどうかを指定します。無効にするには、FALSEを入力します。デフォルトは、FALSEです。

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

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

    詳細は、次のとおりです。

    • realm_nameは、大文字小文字の両方を使用して128文字以内で指定できます。
    • object_ownerは、レルムに追加するオブジェクトの所有者です。レルムで保護するオブジェクトがロールの場合、%文字を入力できます。
    • object_nameは、レルムで保護するオブジェクトの名前です。また、%を入力することで、指定したオブジェクト所有者のすべてのオブジェクト(ロールを除く)を指定します。%を入力する場合、%がobject_typeパラメータに対しても使用されていると、それにスキーマ内のすべてのオブジェクトを含めることができます。ただし、object_typeがTABLEに設定されている場合、object_nameに対する%の使用は、スキーマ内のすべての表を表します。%ワイルドカード文字は、現在存在するオブジェクトだけでなく、まだ存在していないオブジェクトにも適用されることに注意してください。
    • object_typeは、オブジェクトのタイプです(TABLE、INDEX、ROLEなど)。すべてのタイプに対応するレルムを作成する場合は、%またはDBMS_MACUTL.G_ALL_OBJECTを入力します。任意のタイプのオブジェクトを必要なだけレルムに追加できます。
  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;
/

    詳細は、次のとおりです。

    • realm_nameは、大文字小文字の両方を使用して128文字以内で指定できます。
    • granteeは、所有者または参加者として認可するユーザーまたはロール名です。現在のデータベース・インスタンスに既存のユーザーとロールを検索するには、DBA_USERSビューとDBA_ROLESビューを問い合せます。特定のユーザーまたはロールの認可を検索するには、DVA_DV_REALM_AUTHビューを問い合せます。権限管理で使用されている既存のセキュア・アプリケーション・ロールを確認するには、DBA_DV_ROLEビューに問い合せます。
    • rule_set_nameは、実行時にチェックするオプションのルール・セットです。DBA_DV_RULE_SETデータ・ディクショナリ・ビューには、利用可能なルール・セットがリストされます。指定できるのは1つのルール・セットのみですが、このルール・セットには複数のルールがあります。
    • auth_optionsでは、レルムの認可方法を決定します。有効な設定は次のとおりです。
      • 権限が標準のOracle Database権限付与プロセスを使用して付与されている場合、DBMS_MACUTL.G_REALM_AUTH_PARTICIPANTはレルムで保護されているオブジェクトに対するアクセス、操作および作成を行うためのシステム権限または直接権限を付与できます。(デフォルト)
      • DBMS_MACUTL.G_REALM_AUTH_OWNERには、レルムの参加者と同じ認可に加えて、レルム保護オブジェクトに対するレルム・セキュア・ロールおよび権限を付与または取り消す認可があります。

      1つのレルムには複数の参加者または所有者を設定できます。

    • auth_scopeでは、レルムが現在のPDBでローカルに認可されるか(DBMS_MACUTL.G_SCOPE_LOCAL)、アプリケーション・ルートで認可されるか(DBMS_MACUTL.G_SCOPE_COMMON)を定義します。

関連トピック

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

レルムの変更

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

  1. DV_OWNERまたはDV_ADMINロールを付与されているユーザーとして、PDBまたはアプリケーション・ルートに接続します。
    次に例を示します。 
    CONNECT c##sec_admin_owen@pdb_name
Enter password: password

    使用可能なPDBを確認するには、DBA_PDBSデータ・ディクショナリ・ビューのPDB_NAME列を問い合せます。現在のコンテナを確認するには、show con_nameコマンドを実行します。

  2. レルム名を検索して、その定義を確認します。
    次に例を示します。
    SELECT NAME, DESCRIPTION, ENABLED, AUTH_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    => 1);
END;
/

関連トピック

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

レルムの削除

レルムの削除前に、そのレルムへの参照をOracle Database Vaultポリシーから削除する必要があります。

  1. DV_OWNERまたはDV_ADMINロールを付与されているユーザーとして、PDBまたはアプリケーション・ルートに接続します。
    次に例を示します。 
    CONNECT c##sec_admin_owen@pdb_name
Enter password: password

    使用可能なPDBを確認するには、DBA_PDBSデータ・ディクショナリ・ビューのPDB_NAME列を問い合せます。現在のコンテナを確認するには、show con_nameコマンドを実行します。

  2. 削除するレルムの名前を検索します。
    SELECT NAME FROM DBA_DV_REALM 
ORDER BY NAME;
  3. DBA_DV_REALM_OBJECTデータ・ディクショナリ・ビューを問い合せて、レルムへのオブジェクト参照を確認します。
    たとえば、HR Realmというレルムに関連付けられたレルム・オブジェクトは、次のように検索します。
    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
  4. DBMS_MACADM.DELETE_OBJECT_FROM_REALMプロシージャを実行して、レルムからEMPLOYEESオブジェクトを削除します。
    次に例を示します。
    BEGIN
 DBMS_MACADM.DELETE_OBJECT_FROM_REALM(
  realm_name   => 'HR Realm', 
  object_owner => 'HR', 
  object_name  => 'EMPLOYEES', 
  object_type  => 'TABLE'); 
END;
/
  5. DBA_DV_REALM_AUTHデータ・ディクショナリ・ビューを問い合せて、レルムの認可を見つけます。
    次に例を示します。
    SELECT GRANTEE, AUTH_SCOPE 
FROM DBA_DV_REALM_AUTH 
WHERE REALM_NAME = 'HR Realm'; 

GRANTEE  AUTH_SCOPE
–------  –------------------------
HR       DBMS_MACUTL.G_SCOPE_LOCAL
  6. レルムから認可を削除します。
    たとえば、HR Realmのローカル認可を削除するには、次のように入力します。 
    BEGIN
DBMS_MACADM.DELETE_AUTH_FROM_REALM(
 realm_name  => 'HR Realm',
 grantee     => 'HR',
 auth_scope  => DBMS_MACUTL.G_SCOPE_LOCAL);
END;
/
  7. DBA_DV_POLICY_OBJECTデータ・ディクショナリを問い合せて、レルムに関連付けられているOracle Database Vaultポリシーを調べます。
    次に例を示します。 
    SELECT POLICY_NAME, COMMAND_OBJ_NAME 
FROM DBA_DV_POLICY_OBJECT 
WHERE COMMAND_OBJ_NAME = 'HR Realm';
  8. DBMS_MACADM.DELETE_REALM_FROM_POLICYを実行して、ポリシーからレルムを削除します。
    次に例を示します。 
    BEGIN
 DBMS_MACADM.DELETE_REALM_FROM_POLICY(
  policy_name    => 'HR_DV_Policy',
  realm_name     => 'HR Realm');
END;
/
  9. この時点で、レルムに参照はありません。DBMS_MACADM.DELETE_REALMプロシージャを実行して、レルムを削除します。
    EXEC DBMS_MACADM.DELETE_REALM('HR Realm');

関連トピック

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

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

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

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

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

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

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

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

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

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

レルム認可について

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

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

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

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

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

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

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

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

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

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

関連トピック

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

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

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

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

共通レルムのローカル認可とは、ユーザーがアクセスしている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でローカルで使用される場合の同じレルムと同じ強制動作を実行します。

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

レルムの動作

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

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

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

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

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

    影響する場合は、ステップ4に進みます。通常レルムの場合は、ステップ3に進みます。

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

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

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

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

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

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

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

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

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

    阻止される場合は、コマンド・ルール違反が発生し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エラーが発生します。

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

親トピック: レルム認可の例

例: 認可されていないユーザーによる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表の削除権限を付与されているユーザーは、レルム認証なしで正常にレコードを削除できます。そのため、レルムには、データベース・アカウントによる通常のビジネス・アプリケーションの使用に最低限の影響力が必要です。

親トピック: レルム認可の例

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

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

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

例4-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人のユーザーに、オブジェクトに対する別々のアクセス・レベルが必要な場合に保護を提供できます。

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

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

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

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

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

関連トピック

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

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

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

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

「レルムの動作」では、レルム内のオブジェクトに影響を与える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 Vaultには、レルムの分析に役立つ、レポートとデータ・ディクショナリ・ビューが用意されています。

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

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

レポート 用途

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DBA_DV_REALM

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

DBA_DV_REALM_AUTH

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

DBA_DV_REALM_OBJECT

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

関連トピック

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