リバース プロキシとは

リバース プロキシとフォワード プロキシの違い

この2つのプロキシ サーバーは混同されやすいため、ここで違いを説明します。

リバース プロキシはWebサーバーの前面に配置され、クライアントがサーバーと直接通信しないように機能します。一方、フォワード プロキシ(CASBの別のモード)はクライアント エンドポイントの前面に配置され、外部からのリクエストを傍受してサーバーがクライアントと直接通信しないようにします。この2種類のサーバーは同じ機能を持っているようにみえますが、フォワード プロキシは通常、トラフィックを転送するために、エンドポイントにインストールされたソフトウェア エージェントを利用するのに対し、リバース プロキシは利用しないという違いがあります。

リバース プロキシ サーバーとは

「リバース プロキシ サーバー」は、リバース プロキシの正式な名称です(フォワード プロキシと「フォワード プロキシ サーバー」についても同様)。「サーバー」を省略した呼び方が一般的になりつつありますが、これは物理的な「箱」のようなハードウェアを連想させるためです。実際のテクノロジーは、アプリケーションやクラウド サービスの形態をとる場合がほとんどです。

リバース プロキシの仕組み

トラフィック フローの中に配置されるリバース プロキシは、組織の認証サービス(シングル サインオンなど)と統合されます。サービスとアプリがリバース プロキシとやりとりするようにIT部門が構成すれば、プロキシはエージェントなしにインラインで動作します。これにより、管理対象のクラウド アプリなどに向かうトラフィックが自動的にリバース プロキシにリダイレクトされ、シンプルなユーザー エクスペリエンスが提供されます。

このプロセスをもう少し詳しく見てみましょう。

リバース プロキシは、機密データ(PCIデータ、PIIなど)が存在するサーバーの仲介人または代理人として機能することで、これらのデータを保護します。クライアントからのリクエストは最初にリバース プロキシに送信され、適切なファイアウォール内の指定されたポートを経てコンテンツ サーバーへと転送され、ユーザーに戻ります。クライアントとサーバーが直接通信することはありませんが、クライアント側は直接通信したかのようなレスポンスを受信します。基本的な手順は、次のとおりです。

1. クライアントがリクエストを送信し、リバース プロキシが受け取る
2. リバース プロキシが受信したリクエストをファイアウォールに転送する(リバース プロキシは、サーバーと通信せずにキャッシュ内のファイルに対するリクエストに直接応答するように構成できます。詳細は、ユース ケースを参照してください)
3. ファイアウォールがリクエストをブロックするか、サーバーに転送する
4. サーバーがファイアウォール経由でプロキシにレスポンスを送信する
5. リバース プロキシがクライアントにレスポンスを送信する

リバース プロキシはまた、ハッカーが保護された内部リソースにリダイレクトしたり、他の脆弱性を悪用したりする可能性のある情報について、サーバーのレスポンスを検査することもできます。

オープン ソース ソフトウェアとリバース プロキシ

リバース プロキシは、開発者がソース コードにアクセスし、変更、配布できるように、オープン ソース ソフトウェア(OSS)上に構築されている場合があります。多くのオープン ソース リバース プロキシには柔軟でカスタマイズ可能な機能が備わっており、ユーザーは要件に応じてプロキシを調整できます。

例えば、NginxやApache、HAProxyはすべてリバース プロキシであり、OSSの機能を通じて、負荷分散、キャッシュ、SSLオフロード、HTTPリクエスト ルーティングを提供します。OSSでは、コードが多くの人の目に触れるため、脆弱性の特定や修正の実行が可能となり、セキュリティの目的でも最適といえます。

リバース プロキシのユース ケース

CASB展開モードとしてのリバース プロキシは、セキュアWebゲートウェイ(SWG)、ゼロトラスト ネットワーク アクセス(ZTNA)、およびその他のクラウド型セキュリティ サービスと並んで、セキュリティ サービス エッジ(SSE)モデルの中核を担います。

SSE以外にも、リバース プロキシの一般的なユース ケースとして次の4点が挙げられます。

管理対象外デバイスの保護

従業員の多くは、個人デバイスも含め、複数のデバイスを業務に使用しています。また、サプライヤーやパートナー、顧客も管理されていない私用のデバイスから組織のアプリケーションにアクセスする場合があります。こうした状況は、セキュリティ上のリスクを生み出しかねません。

VPNなどのエージェントをインストールすることで組織が所有するデバイスを管理できますが、管理対象外のエンドポイントに関してはこの限りではありません。サード パーティーのエンドポイントにエージェントをインストールさせることは不可能でしょうし、大半の従業員も個人所有のデバイスにエージェントを取り入れることは望んでいません。そこで、リバース プロキシを利用することで、エージェントを使うことなく、クラウド アプリケーションやリソースにアクセスする管理対象外のデバイスをデータ漏洩やマルウェアから保護できます。

データ保護

リバース プロキシは情報漏洩防止ポリシーを施行して、認可されたクラウド アプリにおける機密情報の偶発的または意図的なアップロードおよびダウンロードを防止します。インラインで動作し、暗号化されたトラフィックを検査するため(特にクラウドベースのリバース プロキシの場合)、アップロードまたはダウンロードされたデータが確実にポリシーに準拠するようにできます。

脅威対策

クラウド サービスでファイルが感染すると、接続されているアプリおよびデバイス、特に管理対象外のデバイスにも拡散する可能性があります。リバース プロキシは、クラウド リソースにおける感染ファイルのアップロードやダウンロードをエージェントなしで防止し、マルウェアやランサムウェアに対する高度な脅威対策を提供します。

また、リバース プロキシの性質上、サーバーとそのIPアドレスはクライアントから不可視化されるため、分散型サービス拒否(DDoS攻撃)などの脅威からWebリソースを保護できます。

負荷分散

リバース プロキシは、1台のサーバーを過剰負荷の状態にしかねないクライアントからのリクエストを処理し、バックエンド サーバーの負荷を軽減することで、高可用性を実現するとともに読込時間を短縮します。これは、主に次の2つの方法で行われます。

1. リバース プロキシは配信元サーバーからのコンテンツを一時記憶域にキャッシュし、サーバーとそれ以上やりとりすることなく、そのコンテンツをリクエストしたクライアントに送信する(これはWebアクセラレーションと呼ばれる)。ドメイン ネーム システム(DNS)を使用すると、複数のリバース プロキシ間でリクエストを均等にルーティングできる。
2. 大規模なWebサイトやその他のWebサービスが複数の配信元サーバーを使用している場合、リバース プロキシはサーバーの負荷が均等になるように、リクエストをサーバー間で分散させる。

リバース プロキシを使用するメリット

これらのユース ケースからもわかるように、リバース プロキシを使用するメリットは主に次の3つに分類することができます。

• データ セキュリティと脅威対策：リバース プロキシは、管理対象および管理対象外のエンドポイントとWebサーバー間のトラフィック(暗号化されたトラフィックを含む)を監視し、フィルタリングすることで、Webアプリケーション ファイアウォール(WAF)機能を提供し、SQLインジェクションやクロスサイト スクリプティングなどのサイバー攻撃からWebサーバーを保護します。
• スケーラビリティーとリソース管理：これは2つの側面を持つメリットです。リバース プロキシでは、ユーザーのエンドポイントにエージェントをインストールすることなく、管理対象のリソースに安全にアクセスできるため、オペレーションのスケーラビリティーを確保できます。また、サーバー負荷分散、APIトラフィック管理などの機能を通じて、インフラの拡張もサポートします。
• パフォーマンスと生産性：クラウドベースのリバース プロキシは、リモート ユーザーのトラフィックも含め、トラフィックを分析して、セキュリティ ポリシーを施行します。データ センターにトラフィックをバックホールすることは一切ありません。これはエンド ユーザーのパフォーマンスを最適化するうえで重要な意味を持ちます。また、現在のトラフィックの大部分を占めるTLS/SSLトラフィックを検査できる無制限のスケーラビリティーも備えており、アプライアンスベースのファイアウォールやプロキシのように検査によってパフォーマンスを大幅に低下させることがありません。

リバース プロキシが抱える課題

リバース プロキシは、管理対象外のデバイスやエンタープライズ アプリケーションの保護に関してセキュリティ上の大きなメリットをもたらす一方、次のようなデメリットもあります。

• 管理対象外のリソースを保護できない：SSOと統合していないアプリやリソースへの安全なアクセスが必要となる場合、リバース プロキシでは対応できません。リバース プロキシが監視するのは、すべてのトラフィックではなく、許可されたリソースに向かうトラフィックのみのため、許可されていないリソースを同じ方法で保護するにはフォワード プロキシが必要になります。
• 機能しないリスクが頻繁に発生する：リバース プロキシは通常、アプリケーションの特定のバージョンで動作するようハードコードされています。そのため、アプリケーションが更新され、新しいコードがプロキシに送信されると、機能しなくなる場合があります。更新されたアプリケーションはプロキシが再コード化されるまで使用できなくなるため、ユーザーの不満が生じたり、生産性が低下したりする可能性があります。

課題を解消するクラウドベースのブラウザー分離

リバース プロキシの制限や機能停止のリスクを回避しながら、エンドポイント エージェントなしで管理対象外のデバイスを安全に使用するために、クラウドベースのブラウザー分離を利用する組織が増えています。

ユーザーが管理対象のクラウド アプリケーションにアクセスすると、Zscaler Cloud Browser Isolation (CBI)はセッションを仮想化し、クラウド内の分離された環境でコンテンツをレンダリングして、セッションをピクセル ストリームとしてユーザーに送信します。クラウド アプリのネイティブなエクスペリエンスと同じユーザー エクスペリエンスを確保できますが、CBIによって管理対象外のデバイスによるアプリ内の機密データのダウンロード、コピー、貼り付け、印刷が防止されます。

これらの理由から、CBIは管理対象外のデバイスを介した偶発的な漏洩や悪意のある持ち出し、そしてマルウェアの拡散を防ぎながら、より幅広いユーザーベースの柔軟性と生産性を支えるための理想的な方法と考えることができます。

Zscalerが提供するクラウドベースのブラウザー分離

Zscaler Browser Isolation™は業界最先端のゼロトラストのWeb分離を活用して、Webからのデータ漏洩や脅威に対して優れた防御を提供します。

卓越したユーザー エクスペリエンスを実現

独自のピクセル ストリーミング技術とクラウドへの直接接続を備えたプロキシ アーキテクチャーにより、アプリやWebサイトへの高速接続が可能になります。高性能なストリーミングでブラウザーのピクセル データを受信できるため、生産性を低下させずにセキュリティを確保できます。

あらゆる場所のユーザーを一貫して保護

本社、モバイルまたはリモートの拠点、そして高度に対象を絞った部門や部署にゼロトラストの分離ポリシーを適用して、あらゆるデバイスや場所のユーザーを保護します。

管理の手間を削減

Zscaler Client Connectorまたはエージェント不要のオプションを活用しつつ、ブラウザー分離をネイティブに統合したZscaler Zero Trust Exchange™経由でトラフィックをルーティングし、わずか数秒で展開と管理を行うことができます。

あらゆるWebブラウザーへの対応

主要なWebブラウザーをすべてサポートしているため、ユーザーのニーズに対応できます。分離されたセッションのCookieの永続性により、ユーザーの重要な設定やサインオン情報が維持されます。