|
| |
| Sun Java System Web Proxy Server 4.0.1 管理ガイド | |
第 14 章
逆プロキシの使用この章では、Proxy Server を逆プロキシとして使用する方法について説明します。逆プロキシとは、特定のプロキシサーバーを代理で使用する方法の名前です。逆プロキシは、ファイアウォールの外側で使用され、外部のクライアントに対してはセキュリティー保護されたコンテンツサーバーに見せかけます。これは会社のサーバーのデータが外部から直接、監視されずにアクセスされることを防ぎます。また、レプリケーション用に使用することもできます。つまり、アクセス回数の多いサーバーの前に複数のプロキシを接続して、負荷を分散することができます。この章では、Proxy Server をファイアウォールの内側または外側で交互に使用できるようにする方法について説明します。
この章には、次の内容が記述されています。
逆プロキシのしくみ逆プロキシには 2 つのモデルがあります。1 つ目のモデルでは Proxy Server によるセキュリティー機能を利用してトランザクションを処理し、2 つ目のモデルでは、キャッシング機能を利用してアクセス回数の多いサーバーの負荷を分散します。どちらのモデルも、厳密にファイアウォール上で動作するわけではないという意味で、従来のプロキシの使用法とは異なっています。
サーバーの代理としてのプロキシ
クレジットカード番号のデータベースなど、セキュリティー保護する必要のある機密情報を保持するコンテンツサーバーがある場合、このコンテンツサーバーの代理として、プロキシをファイアウォールの外側に設定することができます。外部のクライアントがコンテンツサーバーにアクセスしようとすると、代わりに Proxy Server に送られます。実際のコンテンツは、ファイアウォールの内側でセキュリティー保護されたコンテンツサーバー内にあります。Proxy Server はファイアウォールの外側にあり、クライアントからはコンテンツサーバーに見えます。
クライアントがサイトに対して要求を送ると、その要求は Proxy Server に送られます。次に、Proxy Server は、クライアントの要求を、ファイアウォール内の特定の経路を経由させてコンテンツサーバーに送信します。コンテンツサーバーも、この経路を経由させて結果をプロキシに返します。プロキシは、実際のコンテンツサーバーのように見せかけて、取得した情報をクライアントに送信します (図 14-1 を参照)。コンテンツサーバーがエラーメッセージを返してきた場合、Proxy Server は、このメッセージをクライアントに送信する前に、メッセージを遮断して、ヘッダーに表示された URL を変更することができます。これによって、外部クライアントにより内部のコンテンツサーバーに対するリダイレクト URL が入手されることを防ぐことができます。
このように、プロキシはセキュリティー保護されたデータベースを悪意のある攻撃から守るためのバリアとして機能します。万が一悪意のある攻撃が成功してしまった場合でも、侵入者は 1 つのトランザクションに関連する情報にしかアクセスできないように制限される可能性が高くなり、データベース全体にアクセスすることはありません。ファイアウォールの経路には Proxy Server しかアクセスできないため、承認されていないユーザーは実際のコンテンツサーバーにアクセスすることはできません。
図 14-1 実際のコンテンツサーバーのように見える逆プロキシ
ファイアウォールルーターを設定することによって、特定のポート上の特定のサーバー (この場合は割り当てられたポート上のプロキシ) が、ほかのコンピュータのアクセスを許可することなく、ファイアウォールを通過してアクセスできるようになります。
セキュリティー保護された逆プロキシ
セキュリティー保護された逆プロキシが実行されるのは、Proxy Server とほかのマシンの間の 1 つ以上の接続で Secure Sockets Layer (SSL) プロトコルが使用され、データが暗号化されている場合です。
セキュリティー保護された逆プロキシには多くの使用法があります。
セキュリティー保護された逆プロキシを使用すると、データの暗号化に伴うオーバーヘッドによって、セキュリティー保護された各接続の速度が低下します。しかし、SSL の提供するキャッシングメカニズムによって、接続している両者は以前に更新済みのセキュリティーパラメータを再利用することができ、以降の接続のオーバーヘッドを大幅に減らすことができます。
セキュリティー保護された逆プロキシは、次の 3 つの方法で設定できます。
セキュリティー保護されたクライアントからプロキシへ: このシナリオは、プロキシとコンテンツサーバー間でやりとりされる情報が、承認されていないユーザーからアクセスされる可能性がほとんど、またはまったくない場合に効果的です (図 14-2 を参照)。
図 14-2 セキュリティー保護されたクライアントからプロキシへの接続
セキュリティー保護されたプロキシからコンテンツサーバーへ: このシナリオは、ファイアウォールの内側にクライアントがあり、コンテンツサーバーがファイアウォールの外側にある場合に効果的です。このシナリオでは、Proxy Server はサイト間のセキュリティー保護されたチャネルとして機能します (図 14-3 を参照)。
図 14-3 セキュリティー保護されたプロキシからコンテンツサーバーへの接続
- セキュリティー保護されたクライアントからプロキシへ、およびセキュリティー保護されたプロキシからコンテンツサーバーへ: このシナリオは、サーバー、プロキシ、およびクライアント間でやりとりされる情報をセキュリティー保護する必要がある場合に効果的です。このシナリオでは、Proxy Server はサイト間のセキュリティー保護されたチャネルのように機能し、クライアント認証についてもセキュリティー保護します (図 14-4 を参照)。
図 14-4 セキュリティー保護されたクライアントからプロキシへの接続と、セキュリティー保護されたプロキシからコンテンツサーバーへの接続
これらの設定の各設定方法については、「逆プロキシの設定」を参照してください。
プロキシは SSL のほかにもクライアント認証を使用することができます。このためには、プロキシに対して要求を作成するコンピュータが、識別情報を検証するための証明書 (または ID の形式) を提示する必要があります。
負荷分散のためのプロキシ
組織内で複数のプロキシサーバーを使用して、Web サーバー間のネットワーク負荷を分散することができます。このモデルでは、Proxy Server のキャッシュ機能を利用して、ロードバランスのためのサーバープールを作成します。この場合、Proxy Server はファイアウォールのどちら側に配置してもかまいません。1 日に大量の要求を受信する Web サーバーがある場合、プロキシサーバーを使用することで、この Web サーバーの負荷を減らし、ネットワークアクセスの効率を上げることができます。
Proxy Server は、実際のサーバーに対するクライアント要求の橋渡し役として機能します。Proxy Server は、要求されたドキュメントをキャッシュします。複数のプロキシサーバーが存在する場合、DNS は IP アドレスを「ラウンドロビン」方式で選択して、要求をランダムにルーティングすることができます。クライアントは毎回同じ URL を使用しますが、要求は毎回異なるプロキシを経由して送信されることがあります。
アクセス回数の多い 1 台のコンテンツサーバーへの要求を、複数のプロキシを使用して処理する方法には、サーバーが 1 台の場合と比べて、より大きな負荷を、より効率的に処理できるようになるという利点があります。最初の起動時に、プロキシがコンテンツサーバーからドキュメントをはじめて取得した後は、コンテンツサーバーへの要求数が大幅に減少する可能性があります。
コンテンツサーバーに送る必要があるのは、CGI 要求とときどき発生する新規の要求だけです。それ以外の要求は、プロキシで処理できます。次に例を示します。サーバーへの要求の 90% は CGI 以外の要求 (つまり、キャッシュ可能な要求) で、1 日あたりのコンテンツサーバーへのヒット数は 200 万回であるとします。この状況で、3 つのプロキシに接続し、各逆プロキシが 1 日あたり 200 万回のアクセスを処理すれば、1 日あたり約 600 万回のヒット数を処理することもできるようになります。コンテンツサーバーに到達する要求は 10% なので、各プロキシからの 1 日あたりのヒット数は合計 20 万回、つまり全体で 60 万回程度となり、こちらの方がはるかに効率的です。ヒット数が約 200 万回から 600 万回に増加しても、コンテンツサーバー上の負荷はそれに伴って 200 万回から 60 万回に減少します。ただし、実際の結果はユーザーの状況によって異なります。
図 14-5 ロードバランスのために使用するプロキシ
逆プロキシの設定逆プロキシを設定するには、通常マッピングと逆マッピングという 2 つのマッピングが必要です。
- 通常マッピングは、要求をコンテンツサーバーにリダイレクトします。クライアントが Proxy Server にドキュメントを要求した場合、Proxy Server は通常マッピングによって、実際のドキュメントの取得先を知る必要があります。
- 逆マッピングでは、Proxy Server がコンテンツサーバーからのリダイレクトにトラップをかけます。プロキシはリダイレクトを遮断し、リダイレクトされた URL を変更して Proxy Server にマップします。たとえば、クライアントが要求するドキュメントがほかの場所に移動されていたり、見つからなかったりした場合、コンテンツサーバーは、要求された URL でドキュメントが見つからないことを説明するメッセージをクライアントに返します。コンテンツサーバーは、返されたメッセージに、移動されたファイルの取得に使用する URL を示した HTTP ヘッダーを追加します。内部のコンテンツサーバーのプライバシーを守るために、プロキシは、逆マッピングを使用して URL をリダイレクトすることができます。
ここでは、http://http.site.com/ という Web サーバーがあり、このサーバーの逆プロキシサーバーを設定する場合を考えてみます。この場合の逆プロキシは http://proxy.site.com/ とします。
通常マッピングと逆マッピングは、次のようにして作成します。
- サーバーマネージャーにアクセスし、「URLs」タブをクリックします。
- 「Create Mapping」リンクをクリックします。「Create Mapping」ページが表示されます。
- 表示されるページに、1 つ目のマッピングに関する情報を入力します。その例を次に示します。
「Regular mapping」:
「Source prefix」: http://proxy.site.com
「Source destination」: http://http.site.com/
- 「了解」をクリックします。前のページに戻り、2 つ目のマッピングを作成します。
「Reverse mapping」:
「Source prefix」: http://http.site.com/
「Source destination」: http://proxy.site.com/
- 変更を行うには、「了解」をクリックします。
「了解」ボタンをクリックすると、プロキシサーバーは 1 つ以上のマッピングを追加します。マッピングを表示するには、「View/Edit Mappings」というリンクをクリックします。追加されたマッピングは、次のような形式で表示されます。
「from」: /
「to」: http://http.site.com/
これらの追加の自動マッピングは、逆プロキシを通常のサーバーとして接続してくるユーザーを対象としています。最初のマッピングは、逆プロキシを通常のプロキシとして接続してくるユーザーを対象としています。設定方法によりますが、通常、必要とされるのは 2 つ目のマッピングのみですが、両方を設定してもプロキシに問題が発生することはありません。
配信元サーバー上で CGI アプリケーションがまだ実行されているので、Proxy Server が単独で CGI アプリケーションを実行することはありません。ただし、CGI スクリプトによって結果をキャッシュするように指示されている (Last-modified または Expires ヘッダーによってゼロ以外の time-to-live を示唆することにより) 場合、プロキシは結果をキャッシュします。
セキュリティー保護された逆プロキシの設定
セキュリティー保護された逆プロキシを設定する前に、デジタル署名、認証局 (Certificate Authority、ACA)、および認証についてよく理解しておく必要があります。
セキュリティー保護された逆プロキシの設定は、セキュリティー保護されていない逆プロキシの設定とほぼ同じです。唯一異なる点は、暗号化するファイルのプロトコルとして HTTPS を指定する必要があるということだけです。
次に、ユーザーが選択する設定シナリオに応じた、セキュリティー保護された逆プロキシの設定方法について説明します。マッピングの設定方法を説明するために、ここでは、http.site.com という Web サーバーがあり、proxy.site.com というセキュリティー保護された逆プロキシを設定する場合を考えてみます。手順を実際に実行する場合は、下記の例で使用されている名前を、実際の Web サーバー名とプロキシ名に置き換えてください。
セキュリティー保護されたクライアントからプロキシへ
- サーバーマネージャーにアクセスし、「URLs」タブをクリックします。
- 「Create Mapping」リンクをクリックします。「Create Mapping」ページが表示されます。
- 表示されたページで、次の方法に従って通常マッピングと逆マッピングを設定します。
「Regular mapping」:
「Source prefix」: https://proxy.mysite.com
「Source destination」: http://http.mysite.com/
「Reverse mapping」:
「Source prefix」: http://http.mysite.com/
「Source destination」: https://proxy.mysite.com/
- 変更を保存して適用します。
作成したマッピングを表示するには、「View/Edit Mappings.」というリンクをクリックします。
セキュリティー保護されたプロキシからコンテンツサーバーへ
- サーバーマネージャーにアクセスし、「URLs」タブをクリックします。
- 「Create Mapping」リンクをクリックします。「Create Mapping」ページが表示されます。
- 表示されたページで、次の方法に従って通常マッピングと逆マッピングを設定します。
「Regular mapping」:
「Source prefix」: http://proxy.mysite.com
「Source destination」: https://http.mysite.com/
「Reverse mapping」:
「Source prefix」: https://http.mysite.com/
「Source destination」: http://proxy.mysite.com/
- 変更を保存して適用します。作成したマッピングを表示するには、「View/Edit Mappings」というリンクをクリックします。
セキュリティー保護されたクライアントからプロキシへ、およびセキュリティー保護されたプロキシからコンテンツサーバーへ
- サーバーマネージャーにアクセスし、「URLs」タブをクリックします。
- 「Create Mapping」リンクをクリックします。「Create Mapping」ページが表示されます。
- 表示されたページで、次の方法に従って通常マッピングと逆マッピングを設定します。
「Regular mapping」:
「Source prefix」: https://proxy.mysite.com
「Source destination」: https://http.mysite.com/
「Reverse mapping」:
「Source prefix」: https://http.mysite.com/
「Source destination」: https://proxy.mysite.com/
逆プロキシでの仮想マルチホスティング
仮想マルチホスティングは、配信元サーバー (ここでは逆プロキシサーバー) が、複数の DNS エイリアスに対して、それぞれのアドレスに別々のサーバーがインストールされているかのように応答できるようにする機能です。例として、次のような DNS ホスト名が挙げられます。
それぞれのホスト名は、同じ IP アドレス (逆プロキシの IP アドレス) にマッピングされます。次に、アクセスに使用された DNS 名に基づいて、逆プロキシに異なる動作をさせることができます。
仮想マルチホスティングを使用すると、複数の異なるドメインも 1 台の逆プロキシサーバーでホストできるようになります。その例を次に示します。
複数のローカルホスト名と複数のドメインの組み合わせを、すべて 1 台のプロキシサーバーに保持できることに注意してください。
この節では、次の内容について説明します。
仮想マルチホスティング機能の詳細
仮想マルチホスティング機能は、DNS ホスト名およびドメイン名 (またはエイリアス) を指定して、ターゲット URL のプレフィックスに、そのホスト名に送信された要求が送られる場所を指定することによって機能します。例として、次の 2 つのマッピングが可能になります。
マッピングでは、ルート対ルートで行う必要がないので、ターゲット URL 内に URL パスのプレフィックスを追加することもできます。
仮想ドメインのマッピングにも同じことが当てはまります。たとえば、次のようなマッピングを使用できます。
システムは、HTTP の「Host:」ヘッダーを見にいき、そのヘッダーに基づいて、一致する仮想マルチホスティングのマッピングが選択されます。一致するマルチホスティングのマッピングがない場合、サーバーは、続けて設定ファイルに表示される順にほかのマッピングを見にいきます。一致するものが見つからなければ、マッピングは実行されません。一致するものがない場合、通常、「Proxy denies fulfilling the request」という応答がプロキシから返されます。
仮想マルチホスティングを設定するには
- サーバーマネージャーにアクセスし、「URLs」タブをクリックします。
- 「Configure Virtual Multihosting」リンクをクリックします。「Configure Virtual Multihosting」ページが表示されます。
- 「Source Hostname (alias)」フィールドで、このマッピングを適用するローカルホスト名 (または DNS エイリアス) を入力します。
- 「Source Domain Name」フィールドで、このマッピングを適用するローカルドメイン名を入力します。通常、複数の異なる DNS ドメインをマルチホストする場合を除き、これはユーザー自身のネットワークのドメイン名になります。
- 「Destination URL Prefix」フィールドに、ホスト名とドメイン名が上の指定と一致する場合に要求が送信されるターゲット URL のプレフィックスを入力します。
- テンプレートを使用している場合は、「Use This Template」ドロップダウンリストからテンプレート名を選択します。テンプレートを適用しない場合は「NONE」のままにします。
- 「了解」をクリックします。
- 「Restart Required」をクリックします。「Apply Changes」ページが表示されます。
- 「Restart Proxy Server」ボタンをクリックして、変更を適用します。
作成するそれぞれの仮想マルチホスティングのマッピングについて、上記の手順を繰り返します。
仮想マルチホスティングのマッピングはすべて、「Configure Virtual Multihosting」ページの下部に表示されます。「Source Hostname (alias)」と「Source Domain Name」フィールドは、プロキシのポート番号とともに 1 つの正規表現にマージされ、「Host:」ヘッダーとのマッチングに使用されることに注意してください。
たとえば、ホスト名が「www」、ドメインが「example.com」、ポート番号が「8080」の場合、次のような正規表現が表示されます。
これは、ユーザーが入力するか、クライアントが送信する、次のようなすべての組み合わせと必ず一致します。ポート番号は、80 以外の場合でも、クライアントソフトウェアによって省略されることがあります。サーバーにとって、待機していたポート番号は明白であるためです。
仮想マルチホスティングでの重要な注意事項
逆プロキシのマッピングを設定する前には、クライアント自動設定機能を無効にする必要があります。クライアント自動設定機能は転送プロキシを対象としており、逆プロキシは対象とされていないため、無効にしても問題は発生しません。
仮想マルチホスティング機能により、自動逆マッピングが設定されます。そのため、「Virtual Multihosting」ページを使用して入力したマッピングに対して、逆マッピングを作成しないでください。
仮想マッピングは、obj.conf 内で virt-map 関数を使用して指定します。
仮想マッピングは、obj.conf 設定ファイル内で指定された順にマッチングされます。仮想マッピングを行う前に、通常マッピング、逆マッピング、正規表現によるマッピング、またはクライアント自動設定によるマッピングが存在する場合、これらが最初に適用されます。同様に、仮想マッピング内に一致するものが存在しない場合、obj.conf 内の仮想マッピングセクションの次にあるマッピングに進んで変換が行われます。
Proxy Server のポート番号が変更された場合、間違ったポート番号を設定していることになるので、仮想マルチホスティングのマッピングを再作成する必要があります。
