リバースプロキシ
 |
リバースプロキシ（英: reverse proxy）または逆プロキシ、サロゲートサーバは、特定のサーバへのリクエストが必ず通過するように設置されたプロキシサーバである[1][2]。一般的なプロキシとは逆で、不特定多数のクライアントのアクセスに備えて特定のサーバ専用に設けられる。クライアントに取ってはサービスの窓口として機能し、普通はクライアントがリバースプロキシを意識することはない。
Webサーバを運用する企業は、インターネットユーザーのブラウザとWebサーバ間の通信を容易にするためにリバースプロキシを設定することが多い。そうすることの重要な利点は、Webサーバを企業内ネットワーク上のファイアウォールの背後に隠すことができ、リバースプロキシのみをインターネットに直接公開する必要がある点である。リバースプロキシサーバは、人気のあるオープンソースのWebサーバに実装されている。専用のリバースプロキシサーバは、インターネット上の最大規模のウェブサイトの一部で使用されている。
リバースプロキシは、それを経由して中継されるリクエストのIPアドレスを追跡し、暗号化されていないトラフィックを読み取り/変更することができる。しかし、これはサーバを侵害した者も同様の行為が可能であることを意味する。
リバースプロキシは、不特定多数のクライアントに対するアクセス制限や、サーバの負荷分散のために用意される。
用途
[編集]シングルサインオン
[編集]リバースプロキシは、認証を持たないWebサーバにアクセス認証・認可を追加することができる[3][4]。リバースプロキシサーバを前置することで防御が一段階増える。複数台のサーバがある場合にリバースプロキシで認証・認可を行うとシングルサインオンを実現できる。
暗号化/SSL高速化
[編集]SSL による暗号化でセキュアなWebサイトを作るとき、暗号化をWebサーバ自体が行うのではなく、SSL高速化のためのハードウェアを備えたリバースプロキシサーバで行う。この用途で用いる場合、SSLオフローダとも呼ばれる。
負荷分散
[編集]リバースプロキシは複数のサーバに対し負荷分散させることができる。Webサーバ群にリバースプロキシを組み合わせる場合、リバースプロキシが各WebページにあるURLを書き換えることもある（外部に公開されているURLを内部の位置に変換する）。
リバースプロキシはWebサーバ内の画像などの変化しない静的なコンテンツのキャッシュとして作用し、Webサーバの負荷を低減する。Webサイトアクセスの大部分は参照のみであるため、これによってWebサーバの負荷は大幅に低減される。ウェブアクセラレーションとして知られている。
圧縮
[編集]リバースプロキシは静的なコンテンツを圧縮して最適化し、ロード時間を短縮できる。
速度の調整
[編集]Webサーバ上のプログラムがコンテンツを生成している場合、直接クライアントと通信を行うと、クライアント側がダウンロードするのを待たないとプログラムを終了できない。リバースプロキシはWebサーバが生成したコンテンツをまとめてキャッシュし、プログラムはその時点で終了可能となり、クライアントはクライアント側の速度でダウンロードが可能となる。
仮想的なサーバ統合
[編集]複数のサーバがそれぞれ独自のサービスを提供している場合にリバースプロキシを導入して、利用者には1台のサーバとして見せることができる。
HTTPトンネリング
[編集]トンネリングは、プライベートネットワークのデータとプロトコル情報をカプセル化することで、パブリックネットワークを介して送信する。HTTPトンネリングは、上位レベルのプロトコル（HTTP）を使用して下位レベルのプロトコル（TCP）を転送する。HTTPプロトコルは、CONNECTリクエストメソッドを指定し、要求されたリソースとの双方向通信を開始し、トンネルを開く。これにより、HTTPプロキシの背後にあるクライアントは、TLS（HTTPS、ポート443）を使用してウェブサイトにアクセスできる。ただし、すべてのプロキシサーバがこのCONNECTメソッドをサポートしているわけではなく、ポート443のみに制限されている場合もある[5]。
HTTPヘッダの検査
[編集]リバースプロキシはHTTPヘッダを検査することができ、これにより、例えば、インターネットに対して単一のIPアドレスを提示しつつ、HTTPリクエストのURLに基づいて異なる内部サーバにリクエストを中継することが可能となる。
オリジンサーバの隠匿
[編集]リバースプロキシは、オリジンサーバの存在と特性を隠すことができる。これにより、オリジンサーバ/ウェブサイトの実際の場所を特定することがより困難になり、例えば、ウェブサイトのIPアドレスがすぐには明らかにならないため、テイクダウンやウェブサイトへのアクセスブロックなどの法的措置を開始することがより困難になる可能性がある。さらに、リバースプロキシが異なる法的要件を持つ異なる法域に配置されている場合、テイクダウンプロセスがさらに複雑になる場合がある。
リスク
[編集]通過トラフィックが暗号化されており、リバースプロキシがトラフィックをフィルタリング/キャッシュ/圧縮するか、またはその他の方法で修正または改善する必要がある場合、プロキシはまず通信を復号化してから再暗号化する必要がある。これには、プロキシがTLS証明書とその対応する秘密鍵を所有する必要があり、暗号化されていないデータにアクセスできるシステムの数を増やし、攻撃者の標的となる。
攻撃者が組織のリバースプロキシを悪用することに成功した場合、またはインターネットに面したサーバをリバースプロキシサーバに変換することに成功した場合、内部ネットワークおよびシステムへのアクセスが可能になり、外部のデータ漏洩につながる。
リバースプロキシが攻撃をフィルタリングするように構成されていない場合、またはシグネチャデータベースの更新が適切にされていない場合、ゼロデイ攻撃が成立し、攻撃者がリバースプロキシサーバの背後にあるシステムを制御できるようになる可能性がある。
サードパーティーのリバースプロキシを使用することは、機密性、完全性、可用性の全体を、プロキシを運営するサードパーティの手に委ねることを意味する。
リバースプロキシが多くの異なるドメインの前面に立っている場合、その障害（例えば、誤った設定やDDoS攻撃によるもの）は、前面にあるすべてのドメインをダウンさせる可能性がある[6]。
リバースプロキシは、バックエンドサーバにアクセスする他の方法がない場合、単一障害点となる可能性もある。
脚注
[編集]- ^ “Forward and reverse proxies”. The Apache Software Foundation. 2018年8月28日時点のオリジナルよりアーカイブ。2025年10月3日閲覧。
- ^ Reese, Will (September 2008). “Nginx: the high-performance web server and reverse proxy”. Linux Journal (173).
- ^ “Possible to add basic HTTP access authentication via HAProxy?”. serverfault.com. 2018年10月4日時点のオリジナルよりアーカイブ。2016年4月27日閲覧。
- ^ “forward_auth (Caddyfile directive) - Caddy Documentation”. caddyserver.com. 2022年5月22日閲覧。
- ^ “Proxy servers and tunneling” (英語). MDN Web Docs. 2020年11月26日時点のオリジナルよりアーカイブ。2020年12月6日閲覧。
- ^ “Cloudflare outage knocks out major sites and services, including Discord” (英語). finance.yahoo.com. 2020年6月22日時点のオリジナルよりアーカイブ。2020年12月14日閲覧。
関連項目
[編集]- プロキシ
- Squid - リバースプロキシとしても使えるプロキシサーバ
- Apache HTTP Server - リバースプロキシとして使われることもある
- Lighttpd - 負荷分散機能付きのリバースプロキシとして利用可能
- Varnish Cache - オープンソースのリバースプロキシ
- nginx - リバースプロキシ兼Webサーバ
- コンテンツデリバリネットワーク
- ネットワークアドレス変換
外部リンク
[編集]- SwitchFlow Reverse Proxy - Linux 用 C++ リバースプロキシ
- Perlbal - Perlベースのリバースプロキシ/ロードバランサー/Webサーバ
- PortFusion - オープンソースのリバースプロキシ
- Pound - 負荷分散のためのリバースプロキシ
- YXORP - ファイアウォール兼リバースプロキシ。GPL