逆プロキシのしくみ

逆プロキシには 2 つの方法を使用できます。一方の方法では Proxy Server のセキュリティー機能を利用してトランザクションを処理します。他方の方法ではキャッシング機能を利用してアクセス回数の多いサーバーの負荷を分散します。どちらの方法も、厳密にファイアウォール上で動作しないため、従来のプロキシの使用法とは異なっています。

サーバーの代理としてのプロキシ

クレジットカード番号のデータベースなど、セキュリティー保護する必要のある機密情報を保持するコンテンツサーバーがある場合、このコンテンツサーバーの代理として、プロキシをファイアウォールの外側に設定することができます。外部のクライアントがコンテンツサーバーにアクセスしようとすると、代わりに 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 セキュリティー保護されたクライアントからプロキシへの接続

• セキュリティー保護されたプロキシからコンテンツサーバーへ: このシナリオは、ファイアウォールの内側にクライアントがあり、コンテンツサーバーがファイアウォールの外側にある場合に効果的です。このシナリオでは、次の図に示すように、Proxy Server はサイト間のセキュリティー保護されたチャネルとして機能します。

図 14–3 セキュリティー保護されたプロキシからコンテンツサーバーへの接続

• セキュリティー保護されたクライアントからプロキシへ、およびセキュリティー保護されたプロキシからコンテンツサーバーへ: このシナリオは、サーバー、プロキシ、およびクライアント間でやりとりされる情報をセキュリティー保護する必要がある場合に効果的です。このシナリオでは、次の図に示すように、Proxy Server はサイト間のセキュリティー保護されたチャネルのように機能し、クライアント認証についてもセキュリティー保護します。

図 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 負荷分散のためのプロキシ