クラウド型とオンプレミス型のセキュアWebゲートウェイの比較
- クラウド型とオンプレミス型のセキュアWebゲートウェイの主な違いは、トラフィックの復号と検査が行われる場所にあります。
- クラウド型SWGは、リモートユーザーやSaaSに適しています。一方、オンプレミス型SWGは、規制対象のトラフィック、内部トラフィック、およびOTトラフィックに適しています。
- 機能一覧がますます似通ってきている中で、レイテンシー、主権、回復力、そして大量導入時のコストの方がより重要である。
- ハイブリッド型のsecure web gateway は、単一のポリシーに基づき、各ユーザーとサイトを最適なポイントで検査します。
- 両方のモデルを共有ポリシーエンジンなしで実行すると、オフィスユーザーとリモートユーザーの間で設定のずれが生じます。
オンプレミスのsecure web gateway は、自社のデータセンターや支社で稼働し、Webトラフィックをローカルで検査する、物理または仮想のプロキシアプライアンスです。一方、クラウド型のsecure web gateway は、ベンダーのPoP（接続拠点）から同様の機能を提供します。現在、多くの組織が両方を必要としており、そのため、ハイブリッドSWGは規制対象企業にとって一般的なアーキテクチャとなっています。
この記事は、「ハイブリッドクラウドのセキュリティ」ガイドの一部です。
secure web gateway の機能
secure web gateway は、ユーザーとインターネットの間に配置され、どこで稼働していても、脅威をブロックし、利用規定を遵守させ、データ損失を防止します。
通常、以下の機能を提供しています：
- URLおよびカテゴリによるフィルタリング
- TLSの復号と検査
- マルウェアスキャン、サンドボックス、および危険なサイトに対するremote browser isolation
- Data loss prevention アップロードおよびフォーム送信について
- クラウドアプリケーションの可視化と制御
- 調査およびコンプライアンスのためのログ記録
NISTSP 800-215では、従来の境界防御が消滅する中、現代の企業ネットワークにおいてZTNAやCASB、その他の制御手段と組み合わせて導入されるポイント型セキュリティソリューションの一つとして、SWGが挙げられている。
クラウド型とオンプレミス型SWG：並列比較
クラウド型とオンプレミス型のSWGの主な違いは、検査が行われる場所と、その実行責任の所在にあります。
| 因子 | クラウドSWG | オンプレミス型SWG |
|---|---|---|
| 点検場所 | ベンダーの拠点 | お客様のデータセンターおよび支店 |
| こんな方に最適 | リモートおよびモバイルユーザー、SaaSへの直接トラフィック | オフィス、工場、データセンターの利用者；内部トラフィック |
| レイテンシ | 最寄りの接続拠点までの距離によって異なります | オンサイトユーザー向けのホップ追加を最小限に抑える |
| 復号化されたデータが存在する場所 | ベンダーのインフラストラクチャ | お客様のインフラストラクチャ |
| ログの保存場所 | ベンダー指定または設定可能なリージョン | どこに保管しても |
| 外部接続への依存 | 必須 | サポート対象のローカル検査では不要ですが、クラウド上で提供されるサービスを利用するにはインターネット接続が必要です |
| キャパシティプランニング | 販売業者の責任 | あなたの責任 |
| 運用上の取り組み | ハードウェアへの負担を軽減。ポリシーや例外設定は引き続きお客様自身で管理可能です | ハードウェアのライフサイクル、パッチ適用、およびスケーリングは、お客様ご自身で管理いただけます |
| コストモデル | ユーザーごと、または利用量ごと。ユーザー数に応じてスケールします。 | ハードウェアとライセンスは、スループットに応じて拡張可能 |
| エアギャップネットワーク | 不向き | 明示的にサポートされており、かつすべての依存関係が解決されている場合に限る |
点検場所
検査場所によって、復号されたコンテンツを誰が扱うかが決まります。
多くのトラフィッククラスにおいて、適切な制御機能と認証を取得したクラウド型SWGであれば、要件を満たすことができます。規制対象のペイロードについては、ローカルでの検査を行うことで外部処理を削減できる場合がありますが、検査場所を決定する前に、転送されるサービス、ロギング、証拠、アクセス、および適用される要件を評価してください。
TLS検査に伴うリスク管理に関するNSAのガイダンスでは、TLS検査は企業ネットワーク内で1回のみ実施し、同じトラフィックをそれぞれ復号化するプロキシの連鎖を避けることが推奨されています。ハイブリッド構成では、特定のフローについて、ローカルゲートウェイかクラウドゲートウェイのいずれか一方によって復号化され、両方で復号化されないようにする必要があります。「ローカルとクラウドのTLS検査：導入時のトレードオフ」を参照してください。
レイテンシーとユーザー体験
遅延は、実際のルーティング、接続拠点までの距離、ゲートウェイの処理能力、および検査負荷によって異なります。
リモートユーザーの場合、クラウド型SWGを導入することで、本社へのVPNバックホールを排除し、ユーザー体験を向上させることができます。オンプレミスユーザーの場合、ローカルでのインスペクションを行うことでクラウド経由の経路を回避できますが、宛先やネットワーク設計によっては、クラウドでのインスペクションが依然として適している場合もあります。以下の項目について、その違いを測定してください：
- 音声、動画、取引プラットフォームなどのリアルタイムアプリケーション
- 大容量ファイルの転送とソフトウェアの更新
- ベンダーの最寄りの拠点から遠く離れた拠点
- 厳格なタイミング要件が求められるOTおよび産業用システム
ポリシー制御
どちらのモデルもきめ細かなポリシーを適用しますが、真の問題は、クラウドとオンプレミスのゲートウェイが1つのポリシーを共有しているかどうかという点です。
レガシーのアプライアンス群と別のクラウドサービスを並行して運用している組織では、多くの場合、2つのルールセット、2つの例外設定、そして2つのDLP設定を維持しています。時間が経つにつれて、オフィスにいるユーザーと自宅で作業している同じユーザーとの扱いに違いが生じますが、監査やインシデントが発生するまで、誰もそれに気づかないままになります。
ポリシー管理が統合されたハイブリッドSWGにより、チームはルールを一度定義するだけで、すべてのゲートウェイに適用することができます。たとえば、「Skyhigh SWG for Hybrid」は、オンプレミスとクラウドの各適用ポイントにわたる統合ポリシー管理をサポートしており、ポリシーはクラウドコンソールで一度作成するだけで済みます。
運用上の取り組み
クラウド型SWGはハードウェア関連の作業を軽減しますが、どちらのモデルにおいても、ポリシー、例外設定、証明書の管理は引き続きチームが担当する必要があります。
クラウド型SWGを導入すれば、ハードウェアの調達、容量計画、アプライアンスへのパッチ適用といった作業が不要になります。ただし、ポリシーの設計、例外処理、証明書管理、インシデントの優先順位付けといった作業は不要にはなりません。これらは、どちらのモデルにおいても、引き続き貴チームの業務となります。
オンプレミスのSWGには、ハードウェアの更新、OSのアップグレード、トラフィックの増加に伴うスケーリングといったライフサイクル管理が必要です。 仮想化およびコンテナ化されたアプライアンスは、こうした負担の一部を軽減します。ベンダーのプラットフォーム変更は、予期せぬ運用コストの発生につながる可能性があります。たとえば、Symantec Edge SWG（旧Blue Coat ProxySG）をご利用のお客様は、SGOS 7.3のサポート終了や、SGOS 7.4におけるJavaベースの管理コンソールの廃止に直面しています。詳細については、「Blue Coat 」および「ProxySGのサポート終了：移行計画」をご覧ください。
レジリエンス
オンプレミスのSWGは、外部接続が切断されても検査を継続しますが、クラウド型SWGはベンダーやそのSWGへのネットワーク経路に依存します。
クラウド型SWGは、ベンダーへの接続性とベンダーの可用性に依存しています。多くの組織では、リモートユーザーに関してはこれを容認しています。しかし、工場、病院、トレーディングフロア、あるいは政府施設などにおいては、障害発生時にWeb検査機能が失われたり、オープン状態になったりすることは許容できない場合があります。 オンプレミス型ゲートウェイは、外部接続が切断された場合でも、ローカルでWebトラフィックの検査を継続します。データ保護やremote browser isolation など、ベンダーのクラウドに依存するサービスは、接続経路が復旧するまで利用できません。「ハイブリッドSSEの耐障害性：フェイルオーバーと復旧」を参照してください。
移行要件
モデル間やベンダー間のSWG移行には、いずれも以下の6つのステップが含まれます：
- 現在のポリシー、例外、認証領域、およびICAPやDLPなどの統合機能について把握する。
- どのユーザーとサイトを、どの適用ポイントに移行させるかを決定します。
- トラフィック制御を再設定する：明示的なプロキシまたはPACファイル、エージェント、トンネル、あるいはブラウザ制御。
- TLS検査認証局を再発行し、配布する。
- 本番移行前に、パイロットグループと並行して運用を行う。
- 検証済みのロールバック計画を策定した上で、段階的に移行を行う。
「Secure Web Gateway への移行：カットオーバーおよびロールバックのチェックリスト」を参照してください。
どのモデルがあなたに適しているでしょうか？
機能一覧ではなく、ユーザー、アプリケーション、および規制対象データの所在に基づいて選択してください。
ユーザーのほとんどがリモートで、アプリケーションのほとんどがSaaSであり、かつ規制や契約により復号化されたトラフィックのローカル処理が義務付けられていない場合は、主にクラウドを選択してください。
特定のトラフィックに対してローカルでの処理や継続性が求められる場合は、主にオンプレミス環境を選択してください。エアギャップ環境、機密環境、またはOT環境については、製品による明示的なサポートに加え、管理、認証、更新、ライセンス、および検査に関するすべての依存関係を検証してください。
オフィス勤務者とリモート勤務者が混在している場合、規制対象データと一般的なトラフィックが混在している場合、あるいは既存のオンプレミス型ゲートウェイ環境を、クラウドへの強制的な移行を伴わずに近代化したい場合には、ハイブリッドを選択してください。これは、規制業界の大企業のほとんどに当てはまります。
ハイブリッドsecure web gateway
ハイブリッド型SWGは、オンプレミスのアプライアンスとクラウド上のPoPを、単一のポリシーエンジン、単一のコンソール、および単一のログセットの下で統合します。
オフィス内のトラフィックはローカルで検査され、リモートトラフィックはクラウド上で検査され、ポリシーで必要とされる場合は、どこであってもトラフィックが規制されます。
Skyhigh Hybrid SSE Mesh は、このモデルを Web ゲートウェイの枠を超えて拡張し、ローカル ZTNA、セキュアブラウザ制御、およびクラウド型 CASB、DSPM、DLP、RBI を同一のポリシー下で統合します。
出典
- NIST.SP 800-215: 安全な企業ネットワーク環境の構築ガイド（2022年11月）。https://csrc.nist.gov/pubs/sp/800/215/final
- NSA. 「トランスポート層セキュリティ（TLS）検査に伴うリスクの管理」（2019年11月）。https://media.defense.gov/2019/Nov/18/2002212783/-1/-1/0/MANAGING%20RISK%20FROM%20TLS%20INSPECTION_20191106.PDF
- Skyhigh Security. ハイブリッド向けSecure Web Gateway 。https://www.skyhighsecurity.com/products/secure-web-gateway-for-hybrid.html
- Skyhigh Security. 「Skyhigh Security 、2026年ガートナー『Critical Capabilities forSecurity Service Edge』の『Advanced SSE Use Case』部門で第1位にランクイン」（2026年8月5日）。https://www.globenewswire.com/news-release/2026/08/05/3339504/0/en/skyhigh-security-ranked-1-in-advanced-sse-use-case-in-2026-gartner-critical-capabilities-for-security-service-edge.html
- Broadcom。Edge SWG（ProxySG）およびAdvanced Secure Gatewayのサポート終了および製品ライフサイクルについて（KB 151102）。https://knowledge.broadcom.com/external/article/151102/end-of-life-and-product-lifecycle-for-pr.html