ヘッダーをスキップ
Oracle® Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス
11g リリース2 (11.2)
B72090-02
  目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

A セキュリティ・オプション

この付録では、マルチマスター・レプリケーションおよびマテリアライズド・ビュー・レプリケーション環境のセキュリティ・オプションについて説明します。

この付録では、次の項目を説明します。

マルチマスター・レプリケーションのセキュリティ設定

ほとんどの場合、マルチマスター・レプリケーションのセキュリティを構成するには、Oracle Enterprise ManagerのAdvanced Replicationインタフェースの構成ウィザードを使用するのが最も簡単です。ただし、レプリケーション・マネージメントAPIを使用してこれらの設定を行うことが必要な場合もあります。

レプリケーション環境を構成するには、データベース管理者がDBA権限で接続して、必要な権限をレプリケーション管理者に付与する必要があります。

最初に、各マスター・サイトで、レプリケーション環境を構成およびメンテナンスする権限と、レプリケートされた変更を伝播および適用する権限を持つユーザー・アカウントを設定します。また、各マスター・サイトでユーザー用のリンクを定義する必要があります。

レプリケーション環境のユーザーのカテゴリとして、レプリケート・オブジェクトにアクセスするエンド・ユーザーに加え、次の3つの特別なカテゴリがあります。

  • レプリケーション環境の構成およびメンテナンスを行う、レプリケーション管理者

  • 遅延トランザクションを伝播する、プロパゲータ

  • これらのトランザクションを適用する、リモート・サイトの受信者

通常は、1人のユーザーが管理者、プロパゲータおよび受信者の役割を果たします。ただし、機能ごとに別々のユーザーを設定することも可能です。1人のグローバル・レプリケーション管理者のみを設定できれば、レプリケーション・グループが複数のスキーマにまたがっていない場合は、異なるスキーマごとに別々のレプリケーション管理者を設定できます。ただし、各データベースに登録できるプロパゲータは1人です。

表A-1に、これらの特別なアカウントに割り当てる必要がある権限を示します。これらのユーザーに必要な権限のほとんどは、レプリケーション・マネージメントAPIへのコールを通じて付与されます。また、特定の権限(データベースへの接続およびデータベース・オブジェクトの管理に必要な権限など)は、直接付与する必要があります。

トラステッド・セキュリティとアントラステッド・セキュリティの比較

ユーザーのカテゴリの他に、セキュリティ・モデルとしてトラステッドとアントラステッドのどちらを実装するかを決定する必要があります。トラステッド・セキュリティ・モデルでは、受信者がすべてのローカル・マスター・グループにアクセスできます。受信者は、リモート・サイトのプロパゲータにかわってローカル・マスター・サイトでデータベース・アクティビティを実行するので、プロパゲータにも、受信者のサイトのすべてのマスター・グループへのアクセス権限があります。1人の受信者をすべての受信トランザクションに使用することに注意してください。

たとえば、図A-1のようなシナリオを考えてみます。マスター・サイトBには、マスター・グループAおよびCのみしかなくても、トラステッド・セキュリティ・モデルが使用されたため、プロパゲータはマスター・サイトのマスター・グループA、B、CおよびDに対するアクセス権限があります。これはデータベース管理の柔軟性を大いに高めますが、リモート・データベース管理のモビリティにより、リモート・サイトの悪意のあるユーザーがマスター・サイトのデータを表示したり破損させたりすることが増えます。

使用するセキュリティ・モデルに関係なく、Oracleでは、オブジェクトがレプリケーション環境に追加されるとき、またはレプリケーション環境から削除されるときに、オブジェクトに適切な権限が自動的に付与されます。

図A-1 トラステッド・セキュリティ: マルチマスター・レプリケーション

図A-1の説明が続きます。
「図A-1 トラステッド・セキュリティ: マルチマスター・レプリケーション」の説明

アントラステッド・セキュリティでは、特定のマスター・グループの使用に必要な権限のみが受信者に割り当てられます。したがって、プロパゲータは、受信者側のローカルなマスター・グループのうち、特定のグループのみにアクセスできます。図A-2にアントラステッド・セキュリティ・モデルを示します。マスター・サイトBには、マスター・グループAとCのみが含まれるため、マスター・サイトAの受信者はマスター・グループAとCに対する権限のみが付与されています。このため、プロパゲータからマスター・サイトAへのアクセスは制限されます。 

図A-2 アントラステッド・セキュリティ: マルチマスター・レプリケーション

図A-2の説明が続きます。
「図A-2 アントラステッド・セキュリティ: マルチマスター・レプリケーション」の説明

一般にマスター・サイトは信頼できるとみなされるので、トラステッド・セキュリティ・モデルが使用されます。ただし、リモート・マスター・サイトが信頼できない場合は、アントラステッド・モデルを使用して、受信者に割り当てる権限を制限できます。サイトが信頼できないとみなされるのは、たとえばコンサルティング会社が複数の顧客の仕事を担当する場合などです。表A-1の受信者の項目に示す適切なAPIコールを使用して、ユーザーごとに適切な権限を割り当てます。

表A-1 必要なユーザー・アカウント

ユーザー 権限

グローバル・レプリケーション管理者

DBMS_REPCAT_ADMIN.GRANT_ADMIN_ANY_SCHEMA

スキーマレベルのレプリケーション管理者

DBMS_REPCAT_ADMIN.GRANT_ADMIN_SCHEMA

プロパゲータ

DBMS_DEFER_SYS.REGISTER_PROPAGATOR

受信者

詳細は、「REGISTER_USER_REPGROUPプロシージャ」を参照してください。

トラステッド:

DBMS_REPCAT_ADMIN.REGISTER_USER_REPGROUP
privilege => 'receiver'
list_of_gnames => NULL,
...

アントラステッド:

DBMS_REPCAT_ADMIN.REGISTER_USER_REPGROUP
privilege => 'receiver'
list_of_gnames => 'mastergroupname',
...

これらのアカウントを作成し、適切な権限を割り当てた後、各サイト間でユーザー名とパスワードを含む次のプライベート・データベース・リンクを作成します。

  • ローカルのレプリケーション管理者からリモートのレプリケーション管理者へのリンク

  • ローカルのプロパゲータからリモートの受信者へのリンク

1つのユーザー・アカウントがレプリケーション管理者、プロパゲータおよび受信者として機能するように指定した場合は、N(N-1)個のリンクを作成する必要があります。Nはレプリケーション環境内のマスター・サイトの数です。

これらのリンクを作成した後、各ロケーションでDBMS_DEFER_SYS.SCHEDULE_PUSHおよびDBMS_DEFER_SYS.SCHEDULE_PURGEをコールして、遅延トランザクション・キューを各リモート・ロケーションに伝播する頻度、およびこのキューをパージする頻度を定義する必要があります。DBMS_DEFER_SYS.SCHEDULE_PUSHは、各サイトで、1つのリモート・ロケーションに対し1回ずつ、複数回コールする必要があります。

hq.example.comとsales.example.com間のマルチマスター・レプリケーションを設定するためのスクリプトの例を次に示します。

/*--- Create global replication administrator at HQ ---*/
CONNECT system@hq.example.com
ACCEPT password PROMPT 'Enter password for user: ' HIDE
CREATE USER repadmin IDENTIFIED BY &password;
EXECUTE DBMS_REPCAT_ADMIN.GRANT_ADMIN_ANY_SCHEMA(username => 'repadmin');

/*--- Create global replication administrator at Sales ---*/
CONNECT system@sales.example.com
CREATE USER repadmin IDENTIFIED BY &password;
EXECUTE DBMS_REPCAT_ADMIN.GRANT_ADMIN_ANY_SCHEMA(username => 'repadmin');

/*--- Create single user to act as both propagator and receiver at HQ ---*/
CONNECT system@hq.example.com
CREATE USER prop_rec IDENTIFIED BY &password;
/*--- Grant privileges necessary to act as propagator ---*/
EXECUTE DBMS_DEFER_SYS.REGISTER_PROPAGATOR(username => 'prop_rec');
/*--- Grant privileges necessary to act as receiver ---*/
BEGIN
  DBMS_REPCAT_ADMIN.REGISTER_USER_REPGROUP(
        username => 'prop_rec',
        privilege_type => 'receiver',
        list_of_gnames => NULL);
END;
/

/*--- Create single user to act as both propagator and receiver at Sales ---*/
CONNECT system@sales.example.com
CREATE USER prop_rec IDENTIFIED BY &password;
/*--- Grant privileges necessary to act as propagator ---*/execute
EXECUTE DBMS_DEFER_SYS.REGISTER_PROPAGATOR(username => 'prop_rec');
/*--- Grant privileges necessary to act as receiver ---*/
BEGIN
  DBMS_REPCAT_ADMIN.REGISTER_USER_REPGROUP(
        username => 'prop_rec',
        privilege_type => 'receiver',
        list_of_gnames => NULL);
END;
/

/*--- Create public link from HQ to Sales with necessary USING clause ---*/
CONNECT system@hq.example.com
CREATE PUBLIC DATABASE LINK sales.example.com USING 'sales.example.com';

/*--- Create private repadmin to repadmin link ---*/
CONNECT repadmin@hq.example.com
CREATE DATABASE LINK sales.example.com CONNECT TO repadmin 
 IDENTIFIED BY &password;

/*--- Schedule replication from HQ to Sales ---*/
BEGIN
  DBMS_DEFER_SYS.SCHEDULE_PUSH(
     destination => 'sales.example.com',
     interval => 'sysdate + 1/24',
     next_date => sysdate,
     stop_on_error => FALSE,
     parallelism => 1);
END;
/

/*--- Schedule purge of def tran queue at HQ ---*/
BEGIN
  DBMS_DEFER_SYS.SCHEDULE_PURGE(
     next_date => sysdate,
     interval => 'sysdate + 1',
     delay_seconds => 0,
     rollback_segment => '');
END;
/

/*--- Create link from propagator to receiver for scheduled push ---*/
CONNECT prop_rec/prop_rec@hq.example.com
CREATE DATABASE LINK sales.example.com CONNECT TO prop_rec 
 IDENTIFIED BY &password;

/*--- Create public link from Sales to HQ with necessary USING clause ---*/
CONNECT system@sales.example.com
CREATE PUBLIC DATABASE LINK hq.example.com USING 'hq.example.com';

/*--- Create private repadmin to repadmin link ---*/
CONNECT repadmin@sales.example.com
CREATE DATABASE LINK hq.example.com CONNECT TO repadmin IDENTIFIED BY &password;

/*--- Schedule replication from Sales to HQ ---*/
BEGIN
  DBMS_DEFER_SYS.SCHEDULE_PUSH(
     destination => 'hq.example.com',
     interval => 'sysdate + 1/24',
     next_date => sysdate,
     stop_on_error => FALSE,
     parallelism => 1);
END;
/

/*--- Schedule purge of def tran queue at Sales ---*/
BEGIN
  DBMS_DEFER_SYS.SCHEDULE_PURGE(
     next_date => sysdate,
     interval => 'sysdate + 1',
     delay_seconds => 0,
     rollback_segment =>'');
END;
/

/*--- Create link from propagator to receiver for scheduled push ---*/
CONNECT prop_rec/prop_rec@sales.example.com
CREATE DATABASE LINK hq.example.com connect TO prop_rec IDENTIFIED BY &password;

マテリアライズド・ビュー・レプリケーションのセキュリティ設定

ほとんどの場合、マテリアライズド・ビュー・レプリケーションのセキュリティを構成するには、Oracle Enterprise ManagerのAdvanced Replicationインタフェースの構成ウィザードを使用するのが最も簡単です。ただし、一部の特別な状況では、レプリケーション・マネージメントAPIを使用してこれらの設定を行う必要がある場合があります。レプリケーション環境を構成するには、データベース管理者がDBA権限で接続して、必要な権限をレプリケーション管理者に付与する必要があります。

最初に、各マテリアライズド・ビュー・サイトで、レプリケーション環境を構成およびメンテナンスする権限と、レプリケートされた変更を伝播する権限を持つユーザー・アカウントを設定します。また、これらのユーザー用に、対応付けられたマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトへのリンクを定義する必要があります。対応付けられたマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトで追加のユーザーを作成するか、ユーザーへ追加の権限を割り当てることが必要な場合もあります。

マテリアライズド・ビュー・サイトのユーザーのカテゴリとして、レプリケート・オブジェクトにアクセスするエンド・ユーザーに加え、次の3つの特別なカテゴリがあります。

  • レプリケーション環境の構成およびメンテナンスを行う、レプリケーション管理者

  • 遅延トランザクションを伝播する、プロパゲータ

  • 対応付けられたマスター表またはマスター・マテリアライズド・ビューからマテリアライズド・ビューへ変更をプルダウンする、リフレッシャ。

通常は、これらの機能を1人のユーザーが実行します。ただし、これらの機能をそれぞれ別のユーザーが実行する場合もあります。たとえば、マテリアライズド・ビューは、マテリアライズド・ビュー・サイトの管理者が作成して、他のエンド・ユーザーがリフレッシュします。

表A-2に、マテリアライズド・ビュー・サイトの作成とメンテナンスに必要な権限を示します。

表A-2 マテリアライズド・ビュー・サイトに必要なユーザー・アカウント

ユーザー 権限

マテリアライズド・ビュー・サイト・レプリケーション管理者

DBMS_REPCAT_ADMIN.GRANT_ADMIN_ANY_SCHEMA

プロパゲータ

DBMS_DEFER_SYS.REGISTER_PROPAGATOR

リフレッシャ

CREATE ANY MATERIALIZED VIEW ALTER ANY MATERIALIZED VIEW

マテリアライズド・ビュー・サイトに適切なユーザーを作成するのみでなく、関連付けられているマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトにも追加のユーザーを作成する必要があります。表A-3に、マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトのユーザーが新しいマテリアライズド・ビュー・サイトをサポートするために必要な権限を示します。

トラステッド・セキュリティとアントラステッド・セキュリティの比較

マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトのユーザーのカテゴリの他に、セキュリティ・モデルとしてトラステッドとアントラステッドのどちらを実装するのかを決定する必要があります。トラステッド・セキュリティ・モデルでは、受信者およびプロキシ・マテリアライズド・ビュー管理者がすべてのローカル・レプリケーション・グループにアクセスできます。受信者およびプロキシ・マテリアライズド・ビュー管理者は、プロパゲータおよびマテリアライズド・ビュー管理者のかわりにローカル・マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトのデータベース・アクティビティをリモート・マテリアライズド・ビュー・サイトで実行します。このため、リモート・マテリアライズド・ビュー・サイトのプロパゲータおよびマテリアライズド・ビュー管理者もまた、マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトのすべてのレプリケーション・グループにアクセスできます。1人の受信者をすべての受信トランザクションに使用することに注意してください。

たとえば、図A-3のようなシナリオを考えてみます。マテリアライズド・ビュー・サイトにはマテリアライズド・ビュー・グループAおよびC(マスター・サイトのマスター・グループAおよびCの基づく)のみしかなくても、トラステッド・セキュリティ・モデルが使用されたため、プロパゲータおよびマテリアライズド・ビューの管理者はマスター・サイトのマスター・グループA、B、CおよびDに対するアクセス権限があります。これはデータベース管理の柔軟性を大いに高めますが、DBAはこれらのリモート・サイトのいずれにおいても管理機能を実行でき、これらの変更をマスター・サイトに伝播させることができるため、リモート・サイトの悪意のあるユーザーがマスター・サイトのデータを表示したり破損させたりすることが増えます。

使用するセキュリティ・モデルに関係なく、Oracleでは、オブジェクトがレプリケーション環境に追加されるとき、またはレプリケーション環境から削除されるときに、オブジェクトに適切な権限が自動的に付与されます。

図A-3 トラステッド・セキュリティ: マテリアライズド・ビュー・レプリケーション

図A-3の説明が続きます。
「図A-3 トラステッド・セキュリティ: マテリアライズド・ビュー・レプリケーション」の説明

アントラステッド・セキュリティでは、特定のレプリケーション・グループの使用に必要な権限のみがプロキシ・マテリアライズド・ビュー管理者と受信者に付与されます。したがって、プロパゲータとマテリアライズド・ビュー管理者は、マスター・サイトのこれらの特定のレプリケーション・グループのみにアクセスできます。図A-4に、マテリアライズド・ビュー・レプリケーションのアントラステッド・セキュリティ・モデルを示します。マテリアライズド・ビュー・サイトにはマテリアライズド・ビュー・グループAとCが含まれるので、マスター・グループAとCのみへのアクセスが必要です。アントラステッド・セキュリティを使用すると、マテリアライズド・ビュー・サイトのプロパゲータまたはマテリアライズド・ビュー管理者は、マスター・サイトのマスター・グループBとDにアクセスできません。

図A-4 アントラステッド・セキュリティ: マテリアライズド・ビュー・レプリケーション

図A-4の説明が続きます。
「図A-4 アントラステッド・セキュリティ: マテリアライズド・ビュー・レプリケーション」の説明

通常、マテリアライズド・ビュー・サイトはセキュリティ違反を受けやすいため、アントラステッド・セキュリティ・モデルが使用されます。マテリアライズド・ビュー・サイトでトラステッド・セキュリティ・モデルの使用を必要とする理由はほとんどなく、マテリアライズド・ビュー・サイトでアントラステッド・セキュリティ・モデルを使用することをお薦めします。

トラステッド・セキュリティ・モデルを使用する理由として1つ考えられるのは、マテリアライズド・ビュー・サイトがあらゆる観点(セキュリティ、常時ネットワーク接続、リソース)からマスター・サイトと判断される場合で、データをサブセット化する必要があるためにマテリアライズド・ビューになっている場合です。マルチマスター構成では、行サブセット化と列サブセット化はサポートされていません。

表A-3のプロキシ・マテリアライズド・ビュー管理者と受信者の項目に示す適切なAPIコールを使用して、各ユーザーに適切な権限を割り当てます。

表A-3 マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトの必須ユーザー・アカウント

ユーザー 権限

プロキシ・マテリアライズド・ビュー・サイト管理者

詳細は、「REGISTER_USER_REPGROUPプロシージャ」を参照してください。

トラステッド:

DBMS_REPCAT_ADMIN.REGISTER_USER_REPGROUP 
privilege => 'proxy_snapadmin'
list_of_gnames => NULL,
...

アントラステッド:

DBMS_REPCAT_ADMIN.REGISTER_USER_REPGROUP 
privilege => 'proxy_snapadmin'
list_of_gnames => 'mastergroupname',
...

受信者

詳細は、「REGISTER_USER_REPGROUPプロシージャ」を参照してください。

Trusted:
DBMS_REPCAT_ADMIN.REGISTER_USER_REPGROUP 
privilege => 'receiver'
list_of_gnames => NULL,
...

アントラステッド:

DBMS_REPCAT_ADMIN.REGISTER_USER_REPGROUP 
privilege => 'receiver'
list_of_gnames => 'mastergroupname',
...

プロキシ・リフレッシャ

トラステッド:

CREATE SESSION およびSELECT ANY TABLEを付与

アントラステッド:

必要なマスター表またはマスター・マテリアライズド・ビューおよびマテリアライズド・ビュー・ログにCREATE SESSION およびSELECTを付与

マテリアライズド・ビュー、および対応付けられたマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトにアカウントを作成した後、次に示すプライベート・データベース・リンクを作成します。このリンクは、ユーザー名およびパスワードを含んだ、マテリアライズド・ビュー・サイトからマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトへのリンクです。

  • マテリアライズド・ビュー・レプリケーション管理者からプロキシ・マテリアライズド・ビュー・レプリケーション管理者へのリンク

  • プロパゲータから受信者へのリンク

  • リフレッシャからプロキシ・リフレッシャへのリンク

  • マテリアライズド・ビュー所有者からマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトへのリフレッシュ用リンク

1つのユーザー・アカウントがマテリアライズド・ビュー管理者、プロパゲータおよびリフレッシャとして機能するように指定した場合は、これらの機能に対し、1つのマテリアライズド・ビュー・サイトごとにリンクを1つ作成する必要があります。マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトからマテリアライズド・ビューへのリンクは必要ありません。

これらのリンクを作成した後、マテリアライズド・ビュー・サイトでDBMS_DEFER_SYS.SCHEDULE_PUSHおよびDBMS_DEFER_SYS.SCHEDULE_PURGEをコールして、遅延トランザクション・キューを対応付けられたマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトに伝播する頻度、およびこのキューをパージする頻度を定義する必要があります。対応付けられたマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトから変更を取り込む頻度をスケジュール設定する場合は、マテリアライズド・ビュー・サイトで、DBMS_REFRESH.REFRESHもコールする必要があります。

  前
前 		 次
次
  目次へ移動
目次		 索引へ移動
索引