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

リバースプロキシは、1つまたは複数のオリジンサーバーの前に配置されます。クライアントはパブリックプロキシエンドポイントに接続し、そこでリクエストが終端または転送され、アップストリームアプリケーションが選択され、オリジンサーバーを直接公開することなくレスポンスが返されます。

一般的な役割としては、TLS終端、ロードバランシング、キャッシング、圧縮、認証、Webアプリケーションファイアウォールの適用、レート制限、リクエストの正規化、段階的な展開などが挙げられます。リバースプロキシはWebサイトのアーキテクチャの一部であるため、クライアント側で特別なプロキシ設定を行う必要は通常ありません。

• 明示的なHTTPプロキシ: ブラウザまたはアプリケーションには、ホスト名とポート番号が設定されています。
• SOCKS プロキシ: クライアントとバージョンによっては、ウェブトラフィック以外にも様々なトラフィックを伝送できる汎用トランスポートプロキシ。
• 透過プロキシ: ネットワークインフラストラクチャは、クライアントによる手動設定なしにトラフィックをリダイレクトするため、情報開示とTLS処理には注意が必要です。
• 居住用プロキシ: 発信アドレスは消費者向けインターネットサービスプロバイダ（ISP）に関連付けられており、合法的な発信元であるかどうかを評価する必要がある。
• データセンタープロキシ: アドレスはホスティングインフラストラクチャから生成され、通常は速度とコストが優先されます。
• 静的プロキシまたはスティッキープロキシ： セッション中、出口の一つが安定して維持される。
• ローテーションプロキシ： ゲートウェイは、要求または間隔に応じて出口を変更します。

当サイトの無料プロキシサーバー一覧では、匿名公開エンドポイントが認証情報や機密データの取り扱いに適さない理由を解説しています。

• レイヤー7 HTTPリバースプロキシ: ホスト名、パス、ヘッダー、Cookie、またはアプリケーションルールを使用したルーティング。
• レイヤー4ロードバランサー： HTTPの完全な意味を理解せずに、TCPまたはUDP接続を分散します。
• APIゲートウェイ: 認証、クォータ、変換、ルーティング、および開発者向けポリシーを追加します。
• コンテンツ配信ネットワーク： 分散されたエッジロケーションからキャッシュされたコンテンツを提供し、オリジンを保護します。
• Webアプリケーションファイアウォールゲートウェイ： アプリケーションのリクエストを検査し、定義された攻撃パターンをブロックします。
• Ingressコントローラー： 外部トラフィックをKubernetesなどのコンテナプラットフォームにルーティングします。
• サービスメッシュゲートウェイ: サービス間またはサービス内へのIDおよびトラフィックポリシーを適用します。

• 原産地保護： パブリッククライアントは、アプリケーションサーバーに直接接続するのではなく、エッジに接続します。
• 負荷分散: ヘルスチェックとルーティングにより、リクエストは健全な上流システムに分散されます。
• TLS管理： 証明書と暗号化ポリシーは一元管理できる。
• パフォーマンス： キャッシング、圧縮、接続の再利用、エッジ配信によって、オリジン側の作業が削減されます。
• セキュリティポリシー: レート制限、認証、リクエストサイズ、WAFルールを一貫して適用できます。
• 展開制御: 加重ルーティングは、カナリアリリース、ブルー/グリーンデプロイメント、およびフェイルオーバーをサポートします。

リバースプロキシは依然として重要な依存関係です。冗長なインスタンス、テスト済みのヘルスチェック、保護された管理アクセス、および監視可能なアップストリーム障害を活用してください。

• 流出管理： 管理者は、管理対象デバイスからの通信先とプロトコルを制限できます。
• 可視性： 中央ログは、マルウェア、データ損失、ポリシー違反の調査に役立ちます。
• アドレス制御: 承認されたワークロードは、許可リストに登録されている既知の送信アドレスを使用できます。
• コンテンツ フィルタリング: 組織は、悪意のある、または不適切な宛先をブロックすることができます。
• キャッシング： 繰り返し提供される公共資源は、規定や方針が許す限り、地域内で提供される場合がある。
• 地域別品質保証: 承認されたチームは、目的地の位置依存的な動作を再現できる。

問題が制御対象のクライアント（従業員の送信、ラボのトラフィック、自動化ジョブ、アプリケーション固有のルーティング、または安定した許可リスト登録済み送信アドレスが必要な場合など）から発生する場合は、フォワードプロキシを使用してください。これは、複数のクライアントが1つのポリシーと監査証跡を共有する必要がある場合に特に有効です。

単に「匿名性を確保するため」にプロキシを追加しないでください。正確な経路、データの機密性、ID要件、想定される宛先、ログ記録、データ保持期間、および障害発生時の動作を明確に定義してください。広範なデバイストラフィックや統合的な脅威対策が必要な場合は、VPNまたはセキュアWebゲートウェイの方が適している場合があります。

単一の制御されたエントリポイントが必要な公開サービスまたは内部サービスを運用する場合は、リバースプロキシを使用してください。証明書の管理、ホスト名とパスのマッピング、リクエスト制限の適用、負荷分散、および変化するアップストリームトポロジーの隠蔽を行うのに最適な場所です。

本番環境のインフラストラクチャとして設計する：冗長性を導入し、証明書を自動化し、管理プレーンを制限し、実際のクライアントアドレスを安全に保持し、タイムアウトを定義し、プロキシとオリジンの両方のレイテンシを監視する。

フォワードプロキシの制限事項

• 集中型システムの障害が発生すると、多くのクライアントの外部アクセスが遮断される可能性があります。
• TLS検査は、証明書、プライバシー、法律、および鍵管理に関する義務を導入する。
• アプリケーションはシステム設定を無視したり、サポートされていないプロトコルを使用したりする場合があります。
• ログは、ユーザーの活動に関する機密性の高い記録となる可能性がある。
• ルーティングの不備や出口の過負荷は、遅延と障害発生率を増加させる。

リバースプロキシの限界

• 設定ミスがあると、エッジの背後にあるすべてのアプリケーションが危険にさらされる可能性があります。
• タイムアウトやバッファリングが不適切だと、アップロード、ストリーミング、または長時間かかるリクエストが失敗する可能性があります。
• 冗長性がない場合、リバースプロキシは単一障害点となる。
• 偽造されたクライアントIPヘッダーを信頼すると、ログやセキュリティ上の判断が損なわれる可能性があります。
• プライベートな応答やパーソナライズされた応答をキャッシュすると、ユーザー間でデータが漏洩する可能性があります。

はい。企業クライアントは、送信リクエストをフォワードプロキシ経由で送信し、宛先側はリバースプロキシまたはCDN経由で受信することができます。各仲介者は、それぞれ異なる所有者とポリシー境界に基づいてサービスを提供します。

例えば、従業員のブラウザが会社の送信プロキシに対して認証を行います。そのプロキシは、公開アプリケーションのエッジゲートウェイに接続します。リバースプロキシはTLSを終端し、WAFルールを適用して、リクエストを正常なオリジンにルーティングします。トラブルシューティングには、機密情報を公開することなく、相関ID、同期されたクロック、および両側のログが必要です。