WebLogic Server クラスタ ユーザーズ ガイド
|
 |
 |
|
以下の節では、WebLogic Server クラスタの各種のアーキテクチャについて説明します。
ここでは、「アーキテクチャ」という用語は、アプリケーションの層が 1 つまたは複数のクラスタにデプロイされる仕組みを指します。
Web アプリケーションは、複数の「層」に分けられます。「層」は、アプリケーションで提供される論理的なサービスに対応します。すべての Web アプリケーションが似通っているわけではないので、アプリケーションによっては、以下で説明する層のすべてを利用しない場合があります。また、層はアプリケーションのサービスの論理的な区分を示すものであり、必ずしもハードウェアまたはソフトウェアのコンポーネント間の物理的な区分を示すものではありません。1 つの WebLogic Server インスタンスを実行している 1 台のマシンが、以下で説明するすべての層を提供する場合もあります。
Web 層では、Web アプリケーションのクライアントに対して静的なコンテンツ (単純な HTML ページなど) が提供されます。Web 層は、通常、外部クライアントが Web アプリケーションにアクセスした場合の最初のポイントになります。単純な Web アプリケーションでは、WebLogic Express、Apache、Netscape Enterprise Server、または Microsoft Internet Information Server を実行している 1 つまたは複数のマシンで構成される Web 層が存在する場合もあります。
プレゼンテーション層では、Web アプリケーションのクライアントに対して動的なコンテンツ (サーブレットや JavaServer Pages (JSP) など) が提供されます。Web アプリケーションのプレゼンテーション層は、サーブレットや JSP のホストになる WebLogic Server インスタンスのクラスタで構成されます。クラスタでアプリケーションの静的な HTML ページも提供される場合は、クラスタには Web 層とプレゼンテーション層の両方が含まれます。
Web アプリケーションのすべての層を単一の WebLogic Server クラスタにデプロイするようなクラスタ アーキテクチャを組み合わせ層アーキテクチャと呼びます。
非武装地帯 (DMZ) とは、外部の、信頼性のないソースから使用できるハードウェアおよびサービスの論理的な集合のことです。ほとんどの Web アプリケーションでは、Web サーバのバンクは DMZ にあります。DMZ では、ブラウザ ベースのクライアントからの静的な HTML コンテンツへのアクセスが許可されています。
DMZ には、ハードウェアおよびソフトウェアに対する外部からの攻撃に備えてセキュリティが用意されている場合もあります。ただし、DMZ は信頼性のないソースから使用できるので、その安全性は内部システムよりは劣ります。たとえば、内部システムは、外部からのアクセスをすべて拒否するファイアウォールによって保護できます。DMZ は、アクセス先の個々のマシン、アプリケーション、またはポート番号を隠すファイアウォールによって保護できますが、信頼性のないクライアントからそれらのサービスにアクセスすることは可能です。
ロード バランサという用語は、このマニュアルでは、クライアントの接続リクエストを 1 つまたは複数の別々の IP アドレスに分散させる技術を指します。たとえば、単純な Web アプリケーションでは、DNS ラウンドロビン アルゴリズムがロード バランサとして使用される場合があります。大規模なアプリケーションでは、通常、Alteon WebSystems などから発売されているハードウェアベースのロード バランシング ソリューションが使用されます。このようなソリューションには、ファイアウォールのようなセキュリティ機能も用意されています。
ロード バランサには、クライアント接続をクラスタ内の特定のサーバに関連付ける機能があります。この機能は、クライアント セッション情報のインメモリ レプリケーションを使用する場合に必要です。一部のロード バランシング製品では、インメモリ レプリケーションで使用されるプライマリ サーバおよびセカンダリ サーバを追跡する WebLogic Server クッキーを上書きしないように、クッキーの永続性メカニズムをコンフィグレーションする必要があります。詳細については、「外部ロード バランサによる HTTP セッションのロード バランシング」を参照してください。
プロキシ プラグインとは、WebLogic Server クラスタによって提供される、クラスタ化されたサーブレットにアクセスする Apache、Netscape Enterprise Server、または Microsoft Internet Information Server などの HTTP サーバに対する WebLogic Server の拡張機能のことです。プロキシ プラグインには、WebLogic Server クラスタ内のサーブレットおよび JSP へのアクセスに対するロード バランシング ロジックが含まれます。また、クライアントのセッション ステートのホストになっている主要な WebLogic Server に障害が発生した場合の、セッション ステートのレプリカへのアクセスに対するロジックも含まれます。
推奨基本アーキテクチャは、Web アプリケーションのすべての層が同じ WebLogic Server クラスタにデプロイされる組み合わせ層アーキテクチャです。このアーキテクチャを次の図に示します。
1 つのクラスタが静的な HTTP ページ、サーブレット、および EJB のホストになるので、WebLogic Server コンソールを使用して、Web アプリケーション全体をコンフィグレーションしたり、オブジェクトをデプロイまたはアンデプロイしたりできます。クラスタ化されたサーブレットからの恩恵を受けるために、Web サーバのバンクを別々に保持したり、WebLogic Server プロキシ プラグインをコンフィグレーションしたりする必要はありません。
WebLogic Server クラスタの前で直接ロード バランシング ハードウェアを使用することで、HTML コンテンツとサーブレット コンテンツ両方へのアクセスに対して高度なロード バランシング ポリシーを使用できます。たとえば、現在のサーバの負荷を検出し、クライアントのリクエストを適切に送信するよう、ロード バランサをコンフィグレーションできます。
注意 : インメモリ セッション レプリケーションでサードパーティ製のロード バランサを使用する場合は、プライマリ セッション ステートのホストとなる WebLogic Server インスタンス (接続先サーバ) へのクライアント接続を、ロード バランサが保持するようにしなければなりません。ロード バランサの詳細については、「外部ロード バランサによる HTTP セッションのロード バランシング」を参照してください。
推奨基本アーキテクチャなどの組み合わせ層アーキテクチャは多くの Web アプリケーションのニーズに適していますが、クラスタのロード バランシングおよびフェイルオーバ機能を活用できる度合いは多少限定されます。ロード バランシングおよびフェイルオーバは、Web アプリケーションの各層間のインタフェースでのみ導入できます。そのため、すべての層を単一のクラスタにデプロイするときは、クライアントとクラスタの間でのロード バランシングしか行うことができません。
ロード バランシングとフェイルオーバの大部分は、クライアントとクラスタ自身の間で発生するので、組み合わせ層アーキテクチャでも、ほとんどの Web アプリケーションのニーズを満たすことができます。
しかし、組み合わせ層クラスタには、クラスタ化された EJB へのメソッド呼び出しに対してロード バランシングを実行する機会がありません。クラスタ化されたオブジェクトは、クラスタ内のすべての WebLogic Server インスタンスにデプロイされるので、各オブジェクト インスタンスは各サーバでローカルに使用できます。WebLogic Server では、常にローカルのオブジェクト インスタンスを選択することにより、クラスタ化された EJB に対するメソッド呼び出しが最適化されます。リクエストをリモート オブジェクトに分散させないので、ネットワークのオーバーヘッドが増加しません。
この連結方式は、ほとんどの場合で、異なるサーバへの各メソッド リクエストに対してロード バランシングを行うよりも効率的です。ただし、各サーバの負荷が不均衡な場合は、ローカルでメソッドを処理するよりも、リモート オブジェクトにメソッド呼び出しを送信する方が結果的に効率的になる場合もあります。
クラスタ化された EJB へのメソッド呼び出しに対してロード バランシングを行うには、次の節で説明するように、Web アプリケーションのプレゼンテーション層とオブジェクト層を物理的に異なるクラスタ上に分割する必要があります。
組み合わせ層アーキテクチャと多層アーキテクチャのどちらかに決定する際には、プレゼンテーション層によるオブジェクト層の呼び出しの頻度を考慮してください。プレゼンテーション オブジェクトが通常オブジェクト層を呼び出す場合、組み合わせ層アーキテクチャは、多層アーキテクチャよりも高いパフォーマンスを示す可能性があります。
この節では、推奨多層アーキテクチャについて説明します。このアーキテクチャでは、アプリケーションの各層が複数の異なったクラスタにデプロイされます。
推奨多層アーキテクチャでは、2 つの異なる WebLogic Server クラスタを使用します。1 つは静的な HTTP コンテンツを提供するクラスタであり、もう 1 つはクラスタ化された EJB を提供するクラスタです。多層クラスタは、以下のような Web アプリケーションにお勧めします。
注意 : 多層アーキテクチャを考慮する場合は、プレゼンテーション層からオブジェクト層への呼び出しの頻度を考慮してください。プレゼンテーション オブジェクトが通常オブジェクト層を呼び出す場合、組み合わせ層アーキテクチャは、多層アーキテクチャよりも高いパフォーマンスを示す可能性があります。
推奨多層アーキテクチャでは、アプリケーションの各層が 2 つの異なった物理レイヤ (ハードウェアとソフトウェア) 上に配置されます。
Web/プレゼンテーション レイヤは、静的な HTTP ページ、サーブレット、および JSP の専用ホストになっている WebLogic Server インスタンスのクラスタで構成されます。このサーブレット クラスタは、クラスタ化されたオブジェクトのホストにはなりません。その代わりに、プレゼンテーション層クラスタ内のサーブレットは、オブジェクト レイヤにある異なる WebLogic Server クラスタ内のクラスタ化されたオブジェクトのクライアントとして機能します。
オブジェクト レイヤは、Web アプリケーションで必要なクラスタ化されたオブジェクト (EJB オブジェクトおよび RMI オブジェクト) 専用のホストになる WebLogic Server インスタンスのクラスタで構成されます。専用クラスタにオブジェクト層のホストを配置することで、クラスタ化されたオブジェクトへのアクセスに対するデフォルトの連結の最適化 (「連結されたオブジェクトの最適化」を参照) が失われます。ただし、次の節で説明するように、特定のクラスタ化されたオブジェクトへの各メソッド呼び出しに対するロード バランシングは可能になります。
サーブレットと EJB のホストを異なるクラスタに配置することで、サーブレットの EJB へのメソッド呼び出しで、複数のサーバにわたるロード バランシングが可能になります。このプロセスについては、「多層アーキテクチャでのクラスタ化オブジェクトのロード バランシング」で詳しく説明しています。
プレゼンテーション層とオブジェクト層を別々のクラスタに分割することで、Web アプリケーションの負荷分散に関するオプションが増加します。たとえば、アプリケーションが EJB コンテンツよりも頻繁に HTTP およびサーブレット コンテンツにアクセスする場合は、プレゼンテーション層のクラスタで数多くの WebLogic Server インスタンスを使用し、EJB のホストになるサーバを少数にしてアクセスを集中させることができます。
追加の WebLogic Server インスタンスを利用することで、多層アーキテクチャの障害ポイントは基本クラスタ アーキテクチャよりも少なくなります。たとえば、EJB のホストになっている WebLogic Server に障害が発生しても、Web アプリケーションの HTTP やサーブレットのホストとなる機能には影響しません。
プレゼンテーション層とオブジェクト層を別々のクラスタに分割することで、DMZ にサーブレット/JSP クラスタだけを配置するファイアウォール ポリシーを使用できます。信頼性のないクライアントからの直接アクセスを拒否することで、クラスタ化されたオブジェクトのホストになっているサーバの保護を強化できます。詳細については、「クラスタ アーキテクチャのセキュリティ オプション」を参照してください。
「連結されたオブジェクトの最適化」で説明しているように、クラスタ化されたオブジェクトに対する WebLogic Server の連結の最適化は、クラスタ化されたオブジェクト (EJB または RMI クラス) のホストが、オブジェクトを呼び出すレプリカ対応スタブと同じサーバ インスタンスに配置されることに基づいています。
オブジェクト層を分離させることの最終的な効果は、クライアント (HTTP クライアント、Java クライアント、またはサーブレット) が、クラスタ化されたオブジェクトのホストになっている同じサーバ上のレプリカ対応スタブを取得しないことにあります。このため、WebLogic Server では、連結の最適化を使用できず (「連結されたオブジェクトの最適化」を参照)、クラスタ化されたオブジェクトに対するサーブレット呼び出しでは、レプリカ対応スタブに含まれるロジックに従って自動的にロード バランシングが実行されます。次の図に、多層アーキテクチャ内のクラスタ化された EJB インスタンスにアクセスするクライアントを示します。
図 7-3 多層アーキテクチャでのオブジェクトのロード バランシング
クライアント接続の経路をトレースすると、異なるハードウェアとソフトウェアにオブジェクト層を分離させる意味が理解できます。
サーブレットは、クラスタ化されたオブジェクトのホストになる、WebLogic Server クラスタにある EJB をルックアップします。サーブレットは、Bean のレプリカ対応スタブを取得します。スタブには、Bean のホストになるすべてのサーバのアドレスと、Bean のレプリカへのアクセスに対するロード バランシング ロジックが示されています。
注意 : EJB のレプリカ対応スタブおよび EJB ホームのロード アルゴリズムは、EJB デプロイメント記述子の各要素を使用して指定します。『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「weblogic-ejb-jar.xml デプロイメント記述子のリファレンス」を参照してください。
この例では、同じ WebLogic Server クラスタがサーブレットと EJB の両方のホストになっている場合 (「推奨基本アーキテクチャ」を参照)、WebLogic Server では EJB のリクエストに対するロード バランシングは実行されません。その代わり、サーブレットは常に、ローカル サーバがホストになっている EJB レプリカでメソッドを呼び出します。ローカルの EJB インスタンスを使用した方が、別のサーバにある EJB に対してリモート メソッド呼び出しを行うよりも効率的です。しかし、多層アーキテクチャでは、EJB メソッド呼び出しのロード バランシングを必要とするアプリケーションに対してリモート EJB アクセスが可能です。
多層アーキテクチャではクラスタ化されたオブジェクトへの呼び出しに対するロード バランシングが提供されるので、システムでは通常、組み合わせ層アーキテクチャよりも多い IP ソケットが利用されます。特に、ソケット使用のピーク時は、サーブレットおよび JPS のホストになるクラスタ内の各 WebLogic Server では以下のソケットが最大限に使用される可能性があります。
たとえば、図 7-2 では、サーブレット/JSP クラスタ内の各サーバは最大で 5 つのソケットをオープンする可能性があります。この最大数は、プライマリおよびセカンダリの各セッション ステートが均等にサーブレット クラスタ全体に分散していて、サーブレット クラスタ内の各サーバがオブジェクト クラスタ内の各サーバのリモート オブジェクトに同時にアクセスしたという、最悪のケースを表しています。ほとんどの場合、実際に使用されるソケット数は最大数より小さくなります。
多層アーキテクチャで pure-Java ソケット実装を使用する場合は、ソケットの最大使用に対応できるだけのソケット リーダー スレッドをコンフィグレーションしていることを確認してください。詳細については、「Java ソケット実装用にリーダー スレッドをコンフィグレーションする」を参照してください。
多層アーキテクチャではハードウェア ロード バランサを使用するため、インメモリ セッション ステート レプリケーションを使用する場合は、クライアントの接続先サーバに対するセッション維持型の接続を保持するように、ロード バランサをコンフィグレーションしなければなりません。手順については、「EJB と RMI のロード バランシング方式をコンフィグレーションする」を参照してください。
この節では、多層クラスタ アーキテクチャでの制限の概要を示します。
推奨多層アーキテクチャでは、連結方式を使用してオブジェクト呼び出しを最適化できないので、Web アプリケーションでは、クラスタ化されたオブジェクトに対するすべてのメソッド呼び出しでネットワークのオーバーヘッドが発生します。ただし、このオーバーヘッドは、Web アプリケーションで「多層アーキテクチャの利点」で説明した利点のいずれかが必要な場合には許容できる場合もあります。
たとえば、Web クライアントがサーブレットおよび JSP を頻繁に使用するものの、クラスタ化されたオブジェクトへのアクセスは比較的少ない場合、多層アーキテクチャではサーブレットおよびオブジェクトの負荷を適切に集中させることができます。各サーバの処理能力を最大限に利用しながら、10 個の WebLogic Server インスタンスを含むサーブレット クラスタと 3 個の WebLogic Server インスタンスを含むオブジェクト クラスタをコンフィグレーションできます。
多層アーキテクチャのサーブレット クラスタとオブジェクト クラスタの間にファイアウォールを配置する場合は、オブジェクト クラスタ内のすべてのサーバを IP アドレスではなく、外部に公開されている DNS 名にバインドさせる必要があります。サーバを IP アドレスにバインドさせると、アドレス変換に関する問題が発生し、サーブレット クラスタが各サーバ インスタンスにアクセスできなくなる場合があります。
WebLogic Server インスタンスの内部 DNS 名と外部 DNS 名が同じでない場合、サーバ インスタンスの ExternalDNSName 属性を使用して、サーバの外部 DNS 名を定義します。ファイアウォールの外で、ExternalDNSName はサーバの外部 IP アドレスに変換されます。
クライアントが t3 およびデフォルト チャネルを使用して WebLogic Server にアクセスする場合を除き、ファイアウォールがネットワーク アドレス変換を実行するコンフィグレーションでは、ExternalDNSName を使用する必要があります。たとえば、ファイアウォールがネットワーク アドレス変換を実行し、クライアントがプロキシ プラグインを介して HTTP で WebLogic Server にアクセスするコンフィグレーションでは、ExternalDNSName が必須です。
既存の Web サーバと連携して動作するよう、WebLogic Server クラスタをコンフィグレーションすることができます。そのようなアーキテクチャでは Web サーバのバンクは Web アプリケーションの静的な HTTP コンテンツを提供し、WebLogic プロキシ プラグインまたは HttpClusterServlet を使用してクラスタにサーブレット リクエストおよび JSP リクエストを送信します。
以下の節では、2 種類の代替プロキシ アーキテクチャについて説明します。
次の図に示すような 2 層プロキシ アーキテクチャは、静的な HTTP サーバのホストが Web サーバのバンクに配置されるという点以外は、「推奨基本アーキテクチャ」とほぼ同じです。
2 層プロキシ アーキテクチャには、ハードウェアとソフトウェアの物理レイヤが 2 つあります。
プロキシ アーキテクチャでは、アプリケーションの Web 層を提供するタスクに特化したハードウェアとソフトウェアのレイヤが利用されます。この物理的な Web レイヤは、以下のアプリケーションの組み合わせのいずれか 1 つのホストになる、1 つまたは複数の同じようにコンフィグレーションされたマシンで構成されます。
HttpClusterServlet 選択する Web サーバ ソフトウェアに関係なく、Web サーバの物理層では静的な Web ページのみが提供されるようにする必要があります。動的なコンテンツ (サーブレットや JSP) は、プロキシ プラグインまたは HttpClusterServlet を経由して、プレゼンテーション層のサーブレットや JSP のホストになる WebLogic Server クラスタにプロキシされます。
推奨 2 層プロキシ アーキテクチャでは、プレゼンテーション層およびオブジェクト層のホストは WebLogic Server インスタンスのクラスタに配置されます。このクラスタは、単一のマシンまたは複数の異なるマシンにデプロイできます。
サーブレット/オブジェクト レイヤは、組み合わせ層クラスタ (「推奨基本アーキテクチャ」を参照) とは、アプリケーションのクライアントに静的な HTTP コンテンツを提供しないという点で異なります。
また、Web サーバのバンクを、プレゼンテーション層およびオブジェクト層のホストになる 1 対の WebLogic Server クラスタに対するフロント エンドとして使用することもできます。このアーキテクチャを次の図に示します。
このアーキテクチャには、「推奨多層アーキテクチャ」と同じ利点 (および同じ制限) があります。異なる点は、WebLogic プロキシ プラグインを利用する Web サーバの異なるバンクに Web 層が配置されることだけです。
スタンドアロン Web サーバとプロキシ プラグインの使用には、以下のような利点があります。
静的な HTTP コンテンツをクライアントに提供する Web アプリケーション アーキテクチャがすでに存在する場合は、1 つまたは複数の WebLogic Server クラスタを持つ既存の Web サーバを簡単に統合して、動的な HTTP およびクラスタ化されたオブジェクトを提供できます。
プロキシ アーキテクチャ内の Web サーバは、サードパーティ ユーティリティを使用してコンフィグレーションする必要があり、WebLogic Server 管理ドメインには表示されません。また、クラスタ化されたサーブレットへのアクセスおよびフェイルオーバの恩恵を受けるためには、Web サーバに WebLogic プロキシ プラグインをインストールおよびコンフィグレーションする必要があります。
WebLogic Server クラスタでロード バランサを直接使用すると、サーブレット リクエストのプロキシに関する利点がもたらされます。まず、ロード バランサを持つ WebLogic Server を使用することにより、クライアントの設定における追加管理が不要になります。HTTP サーバのレイヤを別に設定し保持する必要もなく、1 つまたは複数のプロキシ プラグインをインストールおよびコンフィグレーションする必要もありません。また、Web プロキシ レイヤの削除により、クラスタへのアクセスに必要なネットワーク接続数も削減されます。
ロード バランシング ハードウェアを使用することで、システムの能力に適合したロード バランシング アルゴリズムをより柔軟に定義できるようになります。使用するロード バランシング ハードウェアでサポートされている、任意のロード バランシング方式 (ロードベースのポリシーなど) を使用できます。プロキシ プラグインまたは HttpClusterServlet を使用する場合、クラスタ化されたサーブレットへのリクエストについては、単純なラウンドロビン アルゴリズムに制限されます。
ただし、インメモリ セッション ステート レプリケーションを使用している場合、サードパーティ製のロード バランサを使用するには、さらにコンフィグレーションを行う必要があります。この場合は、クライアントがプライマリ セッション ステート情報にアクセスできるようにするため、クライアントと接続先のサーバ間でセッション維持型の接続を保持するように、ロード バランサをコンフィグレーションしなければなりません。プロキシは自動的にセッション維持型の接続を保持するため、プロキシ プラグインを使用する場合は特別なコンフィグレーションは不要です。
推奨コンフィグレーションにあるハードウェアとソフトウェアの物理レイヤの間の境界には、Web アプリケーションの非武装地帯 (DMZ) を定義できるポイントがあります。ただし、すべての境界で物理的なファイアウォールがサポートされているわけではありません。特定の境界で典型的なファイアウォール ポリシーのサブセットがサポートされているだけです。
以下の節では、DMZ を定義して、さまざまなレベルのアプリケーション セキュリティを作成する方法について説明します。
基本ファイアウォール コンフィグレーションでは、信頼性のないクライアントと Web サーバ レイヤの間に 1 つのファイアウォールを使用します。このファイアウォール コンフィグレーションは、推奨基本アーキテクチャまたは推奨多層アーキテクチャで使用できます。
図 7-6 ファイアウォールを使用する基本プロキシ アーキテクチャ
上記のコンフィグレーションでは、1 つのファイアウォールで任意のポリシー (アプリケーションレベルの制限、NAT、IP マスカレード) の組み合わせを使用して、3 つの HTTP サーバへのアクセスをフィルタ処理しています。ファイアウォールの最も重要な役割は、システム内のその他のサーバへのアクセスを拒否することです。つまり、信頼性のないクライアントからは、サーブレット レイヤ、オブジェクト レイヤ、およびデータベースにはアクセスできないようにする必要があります。
物理的なファイアウォールは、DMZ 内の Web サーバの前にも後ろにも配置できます。Web サーバの前にファイアウォールを配置すると、Web サーバへのアクセスを許可し、その他のシステムへのアクセスを拒否するだけで済むので、ファイアウォール ポリシーを簡素化できます。
プロキシ レイヤとクラスタの間にファイアウォールを配置する場合は、以下のコンフィグレーションのガイドラインに従ってください。
ExternalDNSName 属性を使用して、その外部 DNS 名を定義します。ファイアウォールの外で、ExternalDNSName はサーバ インスタンスの外部 IP アドレスに変換されます。 注意 : クラスタ化されたサーバで、https と http のトラフィックを 1 組のカスタム チャネルで分離する場合は、『WebLogic Server 環境のコンフィグレーション』の「チャネル、プロキシ サーバ、およびファイアウォール」を参照してください。
Web サーバ レイヤへのアクセス以外のすべてのアクセスを拒否することによって、基本ファイアウォール コンフィグレーションでは、3 つの Web サーバのみが含まれる小規模な DMZ が作成されます。ただし、DMZ をどんなに慎重に定義しても、悪意のあるクライアントがプレゼンテーション層とオブジェクト層のホストになっているサーバにアクセスする可能性があることは考慮に入れておいてください。
たとえば、ハッカーが Web サーバのホストになっているマシンの 1 つにアクセスしたと仮定します。アクセスのレベルによっては、動的なコンテンツを求めて Web サーバがアクセスする、プロキシされたサーバに関する情報を、ハッカーが入手できる場合もあります。
DMZ をより慎重に定義する場合には、追加のファイアウォールを配置できます (「共有データベースに対するセキュリティの追加」を参照)。
推奨クラスタ アーキテクチャでロード バランシング ハードウェアを使用する場合は、基本ファイアウォールとの関連を考慮してハードウェアのデプロイ方法を決定する必要があります。数多くのハードウェア ソリューションでは、ロード バランシング サービスに加えてセキュリティ機能も提供されていますが、ほとんどのサイトでは Web アプリケーションの防御の最前線としてファイアウォールが使用されています。通常、ファイアウォールでは、Web トラフィックを制限するための、最もよくテストされた一般的なセキュリティ ソリューションが提供されます。ファイアウォールは、次の図に示すようにロード バランシング ハードウェアの前で使用する必要があります。
図 7-7 ファイアウォールとロード バランサを使用する基本プロキシ アーキテクチャ
上記の設定では、Web 層を含む DMZ 内にロード バランサが配置されています。このコンフィグレーションでファイアウォールを使用すると、ファイアウォールはロード バランサへのアクセスを制限するだけで済むので、セキュリティ ポリシーの管理を簡素化できます。また、この設定では、以下で説明するような、Web アプリケーションにアクセスする内部クライアントをサポートするサイトの管理を簡素化することもできます。
Web アプリケーションへの直接アクセスを必要とする内部クライアント (独自の Java アプリケーションを実行するリモート マシンなど) をサポートする場合は、プレゼンテーション層への制限されたアクセスを許可できるよう、基本ファイアウォール コンフィグレーションを拡張できます。アプリケーションへのアクセスを拡張する方法は、リモート クライアントを信頼性のある接続として扱うか、または信頼性のない接続として扱うかによって変わります。
仮想プライベート ネットワーク (VPN) を使用して、リモート クライアントをサポートする場合は、クライアントを信頼性のある接続として扱うことができ、クライアントはファイアウォールの向こう側のプレゼンテーション層に直接接続できます。このコンフィグレーションは、次のようになります。
図 7-8 VPN ユーザのファイアウォール経由のアクセスは制限される
VPN を使用しない場合は、Web アプリケーションへのすべての接続を (独自のクライアント アプリケーションを使用するリモート サイトからの接続であっても) 信頼性のない接続として扱う必要があります。この場合は、次の図に示すように、プレゼンテーション層のホストになっている WebLogic Server インスタンスへのアプリケーションレベルの接続を許可するよう、ファイアウォール ポリシーを変更できます。
図 7-9 アプリケーション コンポーネントのファイアウォール経由のアクセスは制限される
Web アプリケーションの内部データと外部から入手できるデータの両方をサポートする 1 つのデータベースを使用する場合は、データベースにアクセスするオブジェクト レイヤの間に強固な境界を配置することを検討する必要があります。この場合、ファイアウォールを追加することによって、「プロキシ アーキテクチャの基本ファイアウォール」で説明されている DMZ 境界を簡単に強化できます。
次のコンフィグレーションには、Web アプリケーションと内部 (信頼性のある) クライアントによって共有されているデータベース サーバの前に追加のファイアウォールが配置されています。このコンフィグレーションでは、最初のファイアウォールが万一破られた場合や、ハッカーが最終的にオブジェクト層のホストになっているサーバにアクセスした場合のための追加のセキュリティが提供されています。プロダクション環境では、この環境はあり得ません。サイトでは、ハッカーがオブジェクト レイヤにあるマシンにアクセスするよりもずっと前に、悪意のある侵入を検出し、くい止める機能が必要になります。
図 7-10 ファイアウォールが 2 つあるアーキテクチャの DMZ
上記のコンフィグレーションでは、オブジェクト層とデータベースの間の境界は追加のファイアウォールによって強固になっています。ファイアウォールは、オブジェクト層のホストになっている WebLogic Server からの JDBC 接続以外のすべての接続を拒否する厳密なアプリケーションレベルのポリシーを保持します。
|
|
|
