リバース プロキシとは

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

この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インジェクションやクロスサイト スクリプティングなどのサイバー攻撃から保護します。
• スケーラビリティーとリソース管理：これは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ブラウザーに対応します。分離されたセッションのCookieが保たれることで、ユーザーの重要な設定、基本設定、サインオン情報が維持されます。