ドメイン間およびドメイン内トランザクションのセキュアな通信の構成

ドメイン間およびドメイン内トランザクションのセキュアな通信とは

トランザクション通信では、参加サーバーが同じドメイン内にある場合、ドメイン内通信です。サーバーが同じドメイン内ではないトランザクションに参加している場合、それはドメイン間通信です。

分散トランザクションを管理するトランザクション・マネージャの場合、トランザクション・マネージャは、トランザクションを準備して、コミットまたはロールバックするためにすべての参加サーバーやリソースと通信できるようにしておく必要があります。通信チャネルの構成は、トランザクション・ルートが次のどちらであるかによって異なります。

ドメイン内 - トランザクション通信は、同じドメイン内のトランザクションに参加するサーバー間で行われます。グローバル・トランザクションのすべての参加サーバーにローカル・ドメイン・セキュリティを使用するか、セキュリティの相互運用モード使用して、互換性のある通信チャネルを適切に構成する必要があります。
ドメイン間 - トランザクション通信は、同じドメイン内ではないトランザクションに参加するサーバー間で行われます。グローバル・トランザクションのすべての参加ドメインにクロス・ドメイン・セキュリティを使用するか、セキュリティの相互運用モード使用して、互換性のある通信チャネルを適切に構成する必要があります。

通信チャネルは、悪質なサード・パーティがトランザクションの結果に影響を与える中間者攻撃を使用できず、1つ以上のドメイン間で管理制御を取得できないようにセキュアにしておく必要があります。

親トピック: ドメイン間およびドメイン内トランザクションのセキュアな通信の構成

トランザクション通信の要件

トランザクション環境に通信チャネルを構成する場合の特定の要件があります。

ドメイン名およびすべての参加リソースの名前は一意でなければなりません。したがって、サーバーまたはドメインを、別のドメイン内や同じドメイン内のオブジェクトと同じ名前にすることはできません。
設定はドメイン・レベルで行われるため、プロセスで使用されるすべてのドメインについて、クロス・ドメイン・セキュリティの対称性を維持します。
中間者攻撃からトランザクションを保護するには、一方向SSLを構成して通信のセキュリティを強化します。
次の2つの属性が両方とも次のように設定されているデータ・ソースは、グローバル・トランザクションには1つしか参加させることができません。この制約は、データ・ソースがどのドメインに構成されているかに関係なく適用されます。
- 「ロギング・ラスト・リソース」または「2フェーズ・コミットのエミュレート」を選択しています。
- データ・ソースで、非XAドライバを使用してデータベース接続を作成しています。
ノート:

グローバル・トランザクションに複数のLLRまたはJTSリソースを参加させる場合は、命名の競合が原因となってグローバル・トランザクションが失敗します。

ドメイン・トランザクションに使用する通信を決定する方法

親トピック: ドメイン間およびドメイン内トランザクションのセキュアな通信の構成

ドメイン・トランザクションに使用する通信を決定する方法

表7-1を参考に、クロス・ドメイン・セキュリティ、ローカル・ドメイン・セキュリティまたはセキュリティの相互運用モードの使用を決定します:

表7-1 チャネル構成の選択

チャネル構成	サーバー接続	長所	短所
クロス・ドメイン・セキュリティ	ドメイン内	特定のユーザーがドメイン・ペア間の通信を確立するように構成されます。 SSLを使用する場合、中間者攻撃を防止します。	構成がより複雑になります。トランザクション・フローの変更(参加者、参加者ロール(コーディネータとリソースまたはサブコーディネータ)の変更、ドメインの追加や削除、トランザクション・ルートの変更など)には、構成の変更が必要です。
ローカル・ドメイン・セキュリティ	ドメイン間	特定のユーザーが、同じドメイン内のサーバー間で通信を確立するよう構成されます。	構成がより複雑になります
セキュリティの相互運用モード	ドメイン内ドメイン間	構成が非常に簡単です。セキュリティの相互運用モードの構成時にトランザクション・フローを理解する必要はありません。 `default`モードで管理チャネルを使用すると、中間者攻撃の防止になります。管理チャネルが構成され、セキュリティの相互運用性モードが`default`に設定されている場合、メッセージはカーネルIDを使用して転送されます。管理チャネルが構成されていない場合、`default`相互運用性モードは、`performance`相互運用性モードと同じように動作し、メッセージは匿名ユーザーを使用して転送されます。	グローバル・トランザクションへの参加サーバーがあるすべてのドメインで、同じドメイン信頼が使用されます。これは、ドメイン・ペア間のみで信頼が確立されるクロス・ドメイン・セキュリティの場合より安全性が低くなります。 `performance`に設定されている場合、ドメイン間のドメイン信頼の設定は必須ではありません。一部の構成では、中間者攻撃の可能性がわずかにあります。

親トピック: トランザクション通信の要件

セキュアなチャネル通信の構成

サーバー間でのセキュアな通信チャネルを構成する方法を学習します。

親トピック: ドメイン間およびドメイン内トランザクションのセキュアな通信の構成

ローカル・ドメイン・セキュリティ

ローカル・ドメイン・セキュリティでは、資格証明マッパーを使用することで、グローバル・トランザクションの同じドメイン内にあるサーバー間に、互換性のある通信チャネルを構成することを可能にしています。ドメイン内のサーバー間ですべてのJTA通信を実行するユーザーを指定できます。

ローカル・ドメイン・セキュリティが有効な場合、JTAでは、指定されたユーザーの資格証明を資格証明マッパーから取得し、それらを使用してサブジェクトを認証してから、リクエストされた操作が実行されます。ユーザーは、CrossDomainConnectorユーザー・グループに属し、資格証明マッパーのエントリとして存在するローカル・ユーザーであることが必要です。

Oracle WebLogic Remote Consoleオンライン・ヘルプのJTAのローカル・ドメイン・セキュリティの有効化に関する項を参照してください。

親トピック: セキュアなチャネル通信の構成

クロス・ドメイン・セキュリティ

クロス・ドメイン・セキュリティでは、資格証明マッパーを使用することで、グローバル・トランザクションにおけるリモート・サーバー間に、互換性のある通信チャネルを構成できます。トランザクションに参加するすべてのドメイン・ペアについて、資格証明マッパーを1つずつ構成します。各ドメイン・ペアには、CrossDomainConnectorセキュリティ・ロールに属する、異なる資格証明一式があります。

この場合、複雑な構成が必要になりますが、クロス・ドメイン・セキュリティを使用すると、各ドメイン間の信頼を調整できます。WebLogic Serverドメイン間のクロス・ドメイン・セキュリティに関する項で説明されているように、JMS、JTA、MDB、WANレプリケーションなどのサブシステムでは、クロス・ドメイン・セキュリティが実装されています。(EJBコンテナには、クロス・ドメイン・セキュリティのソリューションは実装されていません。)

次のトピックを参照してください。

『Oracle WebLogic Serverセキュリティの管理』のWebLogic Serverドメイン間のクロス・ドメイン・セキュリティの有効化に関する項
『Oracle WebLogic Serverセキュリティの管理』のクロス・ドメイン・セキュリティ用の資格証明マッピングの構成に関する項

クロス・ドメイン・セキュリティを構成する際の重要な考慮事項
クロス・ドメイン・セキュリティは推移的ではない
トランザクションに参加する複数のサーバーでは、相互にクロスドメインの資格証明マッピングが設定されます。
トランザクションへの参加に基づいて除外リストにドメインを追加する
除外リストは、クロス・ドメイン・セキュリティが構成されているドメインのサーバーが、クロス・ドメイン・セキュリティがサポートされていないか、有効になっていない別のドメインのサーバーとともに、トランザクションに参加するためのメカニズムになります。

親トピック: セキュアなチャネル通信の構成

クロス・ドメイン・セキュリティを構成する際の重要な考慮事項

クロス・ドメイン・セキュリティを構成する際には、以下のガイドラインを考慮に入れてください。

クロス・ドメイン・セキュリティでは、ドメイン信頼は必須ではありません。
トランザクションに参加するすべてのドメイン・ペアについて、資格証明マッパーを正しく構成する必要があります - CrossDomainConnectorセキュリティ・ロールに属する資格証明のセットを設定しなければなりません。資格証明マッピングが正しくないと、参加ドメイン間のトランザクションは失敗します。『Oracle WebLogic Serverセキュリティの管理』のクロス・ドメイン・セキュリティ用の資格証明マッピングの構成に関する項を参照してください。
クロス・ドメイン・セキュリティをサポートしない(またはクロス・ドメイン・セキュリティが無効になっている)WebLogicドメインと相互運用するには、それらのドメインを、クロス・ドメイン・セキュリティが有効になっているすべての参加WebLogic Serverドメインの「除外するドメイン名」リストに追加する必要があります。「除外するドメイン名」およびCrossDomainSecurityEnabledフラグの構成が、すべての参加ドメインで統一されていない場合、トランザクションのブランチは失敗します。
「クロス・ドメイン・セキュリティの有効化」フラグが有効になっていて、トランザクションにリモートおよびローカルの参加サーバーがある場合は、リモート・サーバーとのRMI通信にクロス・ドメイン・セキュリティが使用されます。
「クロス・ドメイン・セキュリティの有効化」フラグの有効/無効の設定を切り替えると、しばらくの間トランザクションや他のリモート呼出しが失敗することがあります。トランザクションにおいてコミット・リクエストが失敗した場合は、構成の変更が完了した後にコミットが再試行されます。トランザクションのRMI呼出しが失敗した場合は、トランザクションがタイムアウトしてロールバックされます。ロールバックは、AbandonTimeoutSecondsが経過するまで再試行されます。

親トピック: クロス・ドメイン・セキュリティ

クロス・ドメイン・セキュリティは推移的ではない

トランザクションに参加する複数のサーバーでは、相互にクロス・ドメインの資格証明マッピングを設定します。

ドメイン信頼とは異なり、クロス・ドメイン・セキュリティの構成は推移的ではありません。つまり、AがBを信頼し、BがCを信頼していても、それによってAがCを信頼しているということにはなりません。

以下のシナリオについて考察します。

DomainAにはServer1があります(コーディネータ)
DomainBにはServer2があります(サブコーディネータ)
DomainCにはServer3とServer4があります(Server3はサブコーディネータ)
DomainDにはServer5があります(トランザクションには参加しません)

このシナリオでクロス・ドメインの資格証明マッピングを設定するには、次の操作を行います。

DomainAにおいてDomainBのクロス・ドメイン・セキュリティを設定します。
DomainBにおいてDomainAのクロス・ドメイン・セキュリティを設定します。
DomainAにおいてDomainCのクロス・ドメイン・セキュリティを設定します。
DomainCにおいてDomainAのクロス・ドメイン・セキュリティを設定します。
DomainBにおいてDomainCのクロス・ドメイン・セキュリティを設定します。
DomainCにおいてDomainBのクロス・ドメイン・セキュリティを設定します。

DomainDはトランザクションに参加しないため、クロス・ドメインの資格証明マッピングを使用する必要はありません。ただし、「トランザクションへの参加に基づいて除外リストにドメインを追加する」にある、より詳細な説明を参照してください。

これらをわかりやすい形で表したのが、表7-2です。表のセルに「はい」と記されているのは、それに対応するドメインの組合せに対してクロス・ドメイン・セキュリティを構成する必要があることを表したものです。

表7-2 参加ドメインが3つの場合のクロス・ドメイン・セキュリティの設定

—	DomainA	DomainB	DomainC	DomainD
DomainA	NA	はい	はい	いいえ
DomainB	はい	NA	はい	いいえ
DomainC	はい	はい	NA	いいえ
DomainD	いいえ	いいえ	いいえ	NA

その上でクロス・ドメイン・セキュリティの構成にDomainDを追加し、DomainEを追加しないでおいた場合は、クロス・ドメインの資格証明マップは表7-3のようになります。表のセルに「はい」と記されているのは、それに対応するドメインの組合せに対してクロス・ドメイン・セキュリティを構成する必要があることを表したものです。

表7-3 参加ドメインが5つの場合のクロス・ドメイン・セキュリティの設定

—	DomainA	DomainB	DomainC	DomainD	DomainE
DomainA	NA	はい	はい	はい	いいえ
DomainB	はい	NA	はい	はい	いいえ
DomainC	はい	はい	NA	はい	いいえ
DomainD	はい	はい	はい	NA	いいえ
DomainE	いいえ	いいえ	いいえ	いいえ	NA

親トピック: クロス・ドメイン・セキュリティ

トランザクションへの参加に基づいて除外リストにドメインを追加する

除外リストでは、クロス・ドメイン・セキュリティが構成されているドメインのサーバーと、クロス・ドメイン・セキュリティがサポートされていないか、有効になっていない別のドメインのサーバーがトランザクションに参加するためのメカニズムが提供されます。

クロス・ドメイン・セキュリティが構成されていないドメインのサーバーが、クロス・ドメイン・セキュリティが構成されているドメインのサーバーと一緒にトランザクションに参加する場合、クロス・ドメイン・セキュリティが構成されているドメインの除外リストに該当ドメインを追加します。

クロス・ドメイン・セキュリティが構成されているドメインすべての除外リストにドメインを追加する必要はありません。ただし、除外リストへ追加する必要があるケースでは、ドメインとのトランザクションへの参加を明示的に行う必要があります。

ノート:

クロス・ドメイン・セキュリティが有効になっていないすべてのドメインの名前を除外ドメインのリストに追加するほうが便利です。トランザクションに参加しないドメインのみを除外する場合、トランザクションについてのみ除外すれば十分です。『Oracle WebLogic Serverセキュリティの管理』のクロス・ドメイン・セキュリティからのドメインの除外に関する項で説明されているように、クロス・ドメイン・セキュリティが有効になっていないすべてのドメインを除外するほうが、より一般的です。

以下のシナリオについて考察します。

トランザクション#1:
- DomainAにはServer1があります(コーディネータ)
- DomainBにはServer2があります(サブコーディネータ)
- DomainCにはServer3とServer4があります(Server3はサブコーディネータ)
- DomainDにはServer5があります(トランザクションには参加せず、クロス・ドメイン・セキュリティは構成されていません)
トランザクション#2:
- DomainBにはServer6があります(コーディネータ)
- DomainDにはServer5があります(サブコーディネータで、クロス・ドメイン・セキュリティは構成されていません)

この場合、トランザクション#2のためにDomainDをDomainBの除外リストに追加する必要があります。

DomainAおよびDomainCのサーバーとのトランザクションには参加していないため、これら2つのドメインの除外リストにはDomainDを含める必要はありません。

親トピック: クロス・ドメイン・セキュリティ