以前、会社のパソコンをセットアップするとき、必ずと言っていいほど行っていた作業がありました。Internet Explorerの「インターネット オプション」を開き、プロキシサーバーのアドレスとポート番号を入力することです。
社内システムには直接アクセスし、インターネットへ接続するときにはプロキシを経由する。接続先によって経路を切り替えるために、PACファイル(proxy.pac)を設定したことがある方もいるのではないでしょうか。
ところが最近は、こうした設定を意識する機会がずいぶん減りました。仕事ではMicrosoft 365をはじめとするクラウドサービスを利用し、自宅や外出先からインターネットへ接続するのも当たり前になっています。
そういえば、あのプロキシサーバーは今、どうなっているのでしょうか。
今回は、従来のプロキシを振り返りながら、SWG(Secure Web Gateway)とはどのような仕組みか、プロキシと何が違うのかを解説します。
01 プロキシサーバーの役割:社内ネットワークの「出口」で通信を管理
企業でインターネットの利用が広がり始めた頃、業務に関係のないサイトの閲覧や、危険なWebサイトへのアクセスをどう防ぐかが課題になりました。そこで使われたのがプロキシサーバーです。
プロキシ(Proxy)は「代理」を意味します。その名のとおり、PCに代わってインターネット上のサーバーへアクセスし、取得した情報をPCへ返す仕組みです。企業ではこの中継機能を利用して、Webアクセスを一か所で管理していました。
例えば、社員がWebサイトを開こうとすると、通信はいったん社内のプロキシサーバーへ送られます。そこでアクセス先を確認し、会社のルールに従って通信を許可・遮断します。アクセスログを保存すれば、問題が発生した際に通信履歴を調べることもできます。また、Webコンテンツをキャッシュして通信量を削減する役割もありました。
こうした方式が合理的だったのは、仕事をする場所と会社が管理するネットワークがほぼ一致していたからです。社員はオフィスに出社し、社内LANに接続されたPCで仕事をする。インターネットへ出る通信も、決められた経路を通ることが一般的でした。
つまり、ネットワークの出口を管理することで、社員のWebアクセスの多くを管理できたのです。

02 クラウド時代、社内プロキシだけでは管理しきれない理由
Microsoft 365でメールを確認し、Teamsで会議を開き、SharePointに保存された資料を編集する。こうした業務では、インターネット上のクラウドサービスへ頻繁にアクセスしています。
しかも、社員が必ずしもオフィスにいるとは限りません。自宅のWi-Fiから会社のPCを利用することもあれば、出張先でインターネットへ接続することもあります。
すべての通信をいったん社内に戻し、社内プロキシを通すこともできますが、クラウドの利用が増えるほど、通信の遠回りや社内設備への負荷が問題になります。
そこで広がったのが、クラウドへの通信を社内経由にせず直接インターネットへ出す「ローカルブレイクアウト」です。リモートアクセスVPNでは、特定の通信だけをVPNに通さない「スプリットトンネル」として構成されることもあります。
通信経路は短くなりますが、新たな疑問が生まれます。会社のプロキシを通らない通信には、以前と同じアクセス制限が適用されるのでしょうか。

例えば、オフィスではアクセスを禁止しているWebサイトに、自宅からなら接続できてしまうとしたらどうでしょう。社員が誤ってフィッシングサイトを開いた場合、その通信を会社は把握できるのでしょうか。
PCのセキュリティソフトなど別の保護はあるものの、社内プロキシに設定したアクセス制限はかかりません。
このように、クラウド利用や働く場所の変化に合わせ、特定の社内ネットワークに依存しないWebアクセス管理が求められるようになりました。その選択肢の一つがSWGです。
03 SWGの仕組み:社外からの通信にもポリシーを適用
SWG(Secure Web Gateway)は、Webアクセスに対するセキュリティ機能を提供する仕組みです。危険なWebサイトへのアクセス遮断やマルウェアの検査、アクセスログの記録などを行います。
機能だけを見ると、従来の企業向けプロキシと似ています。実際、多くのSWGはWeb通信を中継するプロキシとして動作しており、まったく別の仕組みに置き換わったわけではありません。
従来のプロキシとの大きな違いは、クラウド型のSWGを利用することで、社内ネットワークを経由しないWeb通信にも、企業のセキュリティポリシーを適用できることです。
PCからの通信をクラウド上のSWGへ送る
クラウド型SWGの具体例として、Ciscoの「Cisco Umbrella」があります。Cisco Umbrellaは、DNSレベルでのアクセス制御や、プロキシによるWeb通信の検査などを提供しています。
DNSによる制御は、Webサイトに接続する前の名前解決の段階で、危険なドメインへのアクセスをブロックする仕組みです。サイトの内容を読み込む前に止められるのが特徴です。
一方、プロキシを利用する方式では、Web通信をクラウド上のセキュリティ基盤へ転送し、URLやファイルなどを検査できます。Cisco UmbrellaのSWGはHTTP/HTTPS通信を中継し、ポリシーで設定すればHTTPS通信を復号して検査することもできます(参考資料2)。DNSによる制御よりも詳しく通信を確認できます。
社外でこれらの機能を使う代表的な方法が、PCへのエージェント導入です。エージェントが通信をクラウド上のSWGへ送るため、自宅や外出先でも企業のルールを適用できます。
なお、SWGへの接続方法は端末エージェントだけではありません。Cisco Umbrellaでも、PACファイルや拠点からのIPsecトンネルなど、複数の接続方法が用意されています(参考資料3)。

スマートフォンのペアレンタルコントロールを思い浮かべると分かりやすいかもしれません。自宅のWi-Fiでも外出先のモバイル通信でも同じ利用制限がかかるように、SWGも利用者の場所を問わず企業のルールを適用します。もちろん、内部の技術や保護対象は異なります。
URLだけでなく、利用者や端末の情報も判断材料になる
従来のプロキシでは、アクセス先のURLや接続元のIPアドレスをもとに通信を制御することが一般的でした。
現在のSWGでは、これらに加えて、利用者のIDや所属グループ、端末の状態、アクセス先のリスクなどを判断材料にできる製品があります。
例えば、Cisco Umbrellaでは、SAMLなどによるID連携を行うことで、ユーザーやグループごとにきめ細かなWebアクセスポリシーを適用できます(参考資料4)。さらに、端末管理やID基盤の条件付きアクセスと組み合わせれば、会社が管理するPCからのアクセスは許可し、管理対象外の端末からのアクセスは制限するといった使い方も考えられます。また、製品によってはファイルのアップロードやダウンロードに制御を加えることも可能です。
ただし、利用できる機能や検査範囲は製品・契約内容・設定によって異なります。特に暗号化通信の検査では、プライバシーや業務アプリケーションへの影響にも配慮が必要です。
従来のプロキシとクラウド型SWGの比較
両者の違いを整理すると、次のとおりです。
| 比較項目 | 従来の社内プロキシ | クラウド型SWG |
|---|---|---|
| 制御する場所 | 社内ネットワークの出口(自社設置の機器) | インターネット上のクラウド基盤 |
| 対象となる通信 | 社内ネットワークを経由する通信 | 社内・社外を問わず、SWGへ転送された通信 |
| 主な接続方法 | ブラウザのプロキシ設定、PACファイル | 端末エージェント、PACファイル、拠点からのトンネル接続など |
| 主な判断材料 | アクセス先のURL、接続元のIPアドレス | URLやカテゴリに加え、利用者のID・所属グループ、アクセス先のリスクなど |
| 基盤の運用 | 自社で機器・ソフトウェアを保守 | 基盤はサービス事業者が運用し、自社はポリシーを管理 |
04 自社のWebアクセス管理で確認すべき3つのポイント
では、自社のWebアクセスは実際にどう管理されているでしょうか。次の3つのポイントから確認してみましょう。
社外からのWebアクセスにも同じルールが適用されているか
会社のPCを自宅に持ち帰ったとき、オフィスと同じアクセス制限が適用されているでしょうか。社内プロキシだけで管理している場合、社外からの通信は別の経路を通っている可能性があります。
特にVPNを経由せずにインターネットへ接続する環境では、社内と社外でセキュリティ対策に違いがないか確認しておきましょう。
どの通信を制御できているか
Webブラウザだけでなく、PCにインストールされたアプリケーションもインターネットへ接続しています。SWGの導入状況によっては、これらの通信すべてが検査対象になるとは限りません。
どの通信を管理し、何を例外とするかを把握しておきましょう。クラウドサービスの利用が増えたことで、以前の設定と実際の通信経路が合わなくなっている可能性もあります。
何を基準にアクセスを制御しているか
アクセス先のURLやIPアドレスだけで制御しているのか、利用者や端末の状態も判断に利用できるのか。必要な機能は、自社の働き方や利用するサービスによって異なります。
また、アクセスログの取得範囲や、不審な通信が検知された場合の対応体制も確認しておきたいところです。ログを取得するだけでなく、問題が起きたときに調査や対処に使える状態になっていることが重要です。
今月のTODO:自社のWebアクセスを確認する
- 社内と社外でPCのインターネット接続経路がどう異なるか確認する
- Webアクセス制御を担っている機器・サービスを把握する
- ブラウザ以外の通信も含め、制御対象と例外を確認する
- 利用者や端末に応じたアクセス制御が必要か検討する
- アクセスログの取得範囲と、異常を検知した際の対応体制を確認する
すでにSWGを導入している企業でも、利用するクラウドサービスや働き方が変化している場合には、現在の設定が実態に合っているかを見直すことが大切です。
05 まとめ:会社の出口から、利用者ごとのWebアクセス管理へ
社内ネットワークの出口で通信をまとめて管理するプロキシは、当時の企業IT環境に適した方法でした。しかし、クラウドの普及と働く場所の多様化により、ネットワークの境界だけでWebアクセスを管理することは難しくなり、場所を問わずポリシーを適用できるクラウド型SWGが使われるようになっています。
プロキシがなくなったわけではありません。現在のSWGにも、通信を中継・検査するプロキシの技術が活用されています。変わったのは、通信を制御する場所と、アクセスの可否を判断するための情報です。
こうした変化は、ネットワーク上の位置だけを根拠に信頼せず、アクセスの条件を確認する「ゼロトラストセキュリティ」の考え方にもつながっています(参考資料1)。
ドコモソリューションズのゼロトラスト型セキュリティサービスでは、Cisco Umbrellaによるインターネットアクセスセキュリティ(SWG)、Microsoft Defender for Endpointによる端末セキュリティ(EDR)、当社SOCによるログ監視を含む導入・運用支援を基本サービスとして提供しています。オプションとして、Microsoft Entra Private Accessによる社内システムへのアクセス(ZTNA)や、Microsoft Intuneによる端末管理もご用意しています。クラウド利用や働く場所の変化に合わせてWebアクセスの管理を見直したい場合は、現在のネットワーク構成や運用体制も含めてご相談ください。
参考資料
- NIST「SP 800-207 Zero Trust Architecture」
https://csrc.nist.gov/pubs/sp/800/207/final - Cisco Umbrella「Configure the Secure Web Gateway」
https://docs.umbrella.com/umbrella-user-guide/docs/configure-the-secure-web-gateway - Cisco Umbrella「Identity and SIG Deployment」
https://docs.umbrella.com/umbrella-user-guide/docs/identity-and-sig-deployment - Cisco Umbrella「Configure SAML Integrations」
https://docs.umbrella.com/umbrella-user-guide/docs/configure-saml-integrations
商標について
※Microsoft、Microsoft 365、Microsoft Teams、SharePoint、Internet Explorer、Microsoft Defender for Endpoint、Microsoft Entra Private Access、Microsoft Intuneは、米国Microsoft Corporationの米国およびその他の国における商標または登録商標です。
※Cisco、Cisco Umbrellaは、米国およびその他の国におけるCisco Systems, Inc.またはその関連会社の商標または登録商標です。
※Wi-Fiは、Wi-Fi Allianceの登録商標です。