プロキシと SWG とは ── 実機を触ったことがない人のための Web アクセスの中継と制御

午後のセキュリティ分野で、社内から Web へ出る通信の話が出ると必ずプロキシサーバが登場し、近年はその置き換え先としてセキュア Web ゲートウェイ(SWG)が出ます。 一言で言えば「社内の PC を直接インターネットに出さず、代理の 1 台を通して検査・記録する」仕組みですが、設問では 「HTTPS をどう中継するか、中身を見るには何が要るか、クラウドに移すと何が変わるか」まで問われます。1 台のプロキシを置いた会社を例に、順に説明します。

1. プロキシが解いている問題

内部セグメント DMZ インターネット Web サーバ PC PC L3SW プロキシ10.0.1.80:8080 FW ① ② × PC から直接インターネットへは FW が拒否 ① PC → プロキシ(宛先はプロキシ、8080) ② プロキシ → Web サーバ(送信元はプロキシ) FW のルールは「内部 → インターネット」を全部拒否し、「プロキシ → インターネット 80/443」だけ許可
図1 フォワードプロキシの基本配置。以下の説明はすべてこの図で進める

PC がそれぞれ勝手にインターネットへ出る構成では、「誰がどこへアクセスしたか」が分からず、危険なサイトも止められません。 そこで社内のすべての Web 通信を DMZ のプロキシサーバに集め、FW では「PC から直接インターネットへ」を拒否します。プロキシを置く目的は次の 4 つで、設問で「目的を 2 つ答えよ」と来たらここから選びます。

目的内容出た年度
URL フィルタリング登録した FQDN や IP アドレス宛ての通信をブロック(業務外サイト、マルウェア配布サイト、C&C サーバ)R7 午後Ⅰ問3 設問1(2)
アクセスログ誰が・いつ・どこへ。インシデント時に複数機器のログを時系列で突き合わせるために、syslog サーバで集約し時刻同期(NTP)しておくR7 午後Ⅰ問3 設問1(1)(2)
利用者認証プロキシ認証で利用者 ID を確認し、ログに残す。認証サーバ(LDAP/AD)と連携R7 午後Ⅰ問3、H30 午後Ⅰ問1 設問1(2)、H28 午後Ⅰ問2 設問4
送信元 IP の集約外から見た送信元がプロキシのグローバル IP 1 つになる。SaaS 側で「この IP からだけ許可」ができるR5 午後Ⅱ問1、R7 午後Ⅰ問3 設問3(4)
フォワードとリバース 社内 PC の代理として外へ出るのがフォワードプロキシ(この章の話)。外の利用者の代理として社内の Web サーバの前に立つのがリバースプロキシで、SSL-VPN や負荷分散装置、WAF がこの形です(平成30年 午後Ⅰ問1 設問1(1) の空欄「フォワード」「リバース」)。 向きが逆なだけで、「間に入って TCP を終端し、代わりに接続する」仕組みは同じです。

2. フォワードプロキシの動作ステップ

ブラウザに「プロキシを使え」と教える

プロキシは透過的ではなく、ブラウザが宛先をプロキシに向けて送ることで成り立ちます。教え方は 3 つあります。

WPAD の危険 PAC の場所を「名前解決で見つける」ということは、偽の wpad ホストを立てた攻撃者が PC を自分のプロキシに向けられるということです(令和6年 午後Ⅰ問3 設問3(2)「不正なプロキシサーバに中継される」)。 PAC ファイルには社内ネットワークの範囲(例: 172.16.0.0〜172.31.255.255 は DIRECT)が書かれるので、読めば内部構成も分かります。
PAC ファイルの骨格
function FindProxyForURL(url, host) {
  if (isInNet(host, "172.16.0.0", "255.240.0.0")) return "DIRECT";   // 社内宛てはプロキシを使わない
  if (dnsDomainIs(host, ".saas.example.com"))     return "DIRECT";   // SaaS 宛ても直接(ローカルブレイクアウト)
  return "PROXY proxy.a-sha.jp:8080";                                 // それ以外はプロキシ経由
}
一部の PC(対応しないアプリ・OS)では PAC が効かない=「対応する PC やサーバでしか利用できない」(R5 午後Ⅱ問1)

HTTP を中継する(プロキシが TCP を 2 本持つ)

ブラウザは Web サーバではなくプロキシに TCP 接続し、「GET http://www.example.jp/index.html」のようにURL 全体を送ります。プロキシは URL のホスト名を自分で名前解決して Web サーバに接続し、応答を受け取ってブラウザへ返します。 つまり図1 の ① と ② は別々の TCP コネクションで、Web サーバから見た送信元はプロキシです。

名前解決は誰がするか プロキシ経由のとき、PC は Web サーバの名前を引きません(プロキシのアドレスさえ分かればよい)。引くのはプロキシです。 だから「PC が内部 DNS に外部の名前を問い合わせる通信」は FW で拒否でき、マルウェアが DNS を使って外へ出る経路も絞れます。逆にプロキシ例外(DIRECT)にした宛先は PC 自身が名前解決する必要があり、FW と DNS の許可が要ります(令和4年 午後Ⅰ問3 設問1)。

利用者を認証する

プロキシは最初の要求に 407 Proxy Authentication Required を返し、ブラウザは利用者 ID とパスワードを付けて再送します。方式は Basic(平文に近い)とダイジェスト認証(パスワードのハッシュを送る。令和4年 午後Ⅰ問1 の空欄)、AD 連携の NTLM/Kerberos があります。 認証に通った利用者 ID がログに残るので、「誰が」が IP アドレスではなく人で分かります。

IP アドレスから人を割り出す 認証していないプロキシのログには送信元 IP しかありません。DHCP 環境では IP が入れ替わるので、L3SW(DHCP サーバ)のリースログと突き合わせて初めて端末が特定できます(令和7年 午後Ⅰ問3 設問1(3))。 この「複数のログを時刻で結ぶ」ために syslog 集約と NTP が前提になります。

3. HTTPS の中継と TLS 復号

今の Web はほぼ HTTPS です。暗号化された通信を「URL ごと読んで中継する」ことはできないので、HTTPS だけは別の方法で中継します。

ブラウザ プロキシ Web サーバ ① CONNECT www.example.jp:443(平文) ② TCP 接続(宛先ポート 443) ③ HTTP/1.1 200 Connection established ④ TLS ハンドシェイク〜暗号化された HTTP が、そのまま通り抜ける プロキシは中身を読めない。分かるのは「接続先ホスト名とポート番号」だけ ① の行にだけ接続先が平文で書かれるので、プロキシの URL フィルタとログは ① で判定する 443 以外への CONNECT を拒否しておくと、プロキシを使った任意ポートへのトンネルを防げる
図2 CONNECT メソッド。プロキシは TCP のトンネルになり、中身には触らない

ブラウザはまず「CONNECT www.example.jp:443」という要求をプロキシへ平文で送ります。プロキシは Web サーバの 443 番へ TCP 接続し、「200 Connection established」を返します。以後プロキシは両方の TCP をつなぐだけのトンネルになり、TLS ハンドシェイクも暗号化データもそのまま通り抜けます。 CONNECT は平成30年 午後Ⅰ問1、令和4年 午後Ⅰ問1、平成28年 午後Ⅰ問2 と繰り返し空欄になっています。

中身を見たいなら TLS を復号する

PCブラウザ プロキシ/SWG自前の CA を持つ Web サーバexample.jp TLS セッション ATLS セッション B サーバ証明書は プロキシの CA が署名した example.jp の証明書(偽造に近い) 本物の example.jp の サーバ証明書で検証 前提: PC の信頼ストアに「プロキシの CA のルート証明書」を配布しておく 配っていない PC では証明書エラーになる(=復号できない) プロキシが両側と別々に TLS を張り、間で平文を検査する
図3 TLS 復号。プロキシが利用者の前で「example.jp のふり」をするので、PC がそれを信頼する下地が要る

マルウェア検査や詳細な URL フィルタをするには平文が必要なので、プロキシ(または SWG)が意図的な中間者になります。 ブラウザとの間はプロキシが即席で発行した example.jp の証明書で TLS を張り、Web サーバとの間は本物の証明書で別の TLS を張ります。その証明書に署名しているのはプロキシ自身の CA なので、PC が普通にアクセスすると証明書エラーになります。

だから「ルート証明書の配布」が答えになる PC にプロキシ(SWG)の CA のルート証明書をあらかじめインストールしておけば、プロキシが発行した証明書を正当なものとして受け入れます。 平成30年 午後Ⅰ問1 設問2(2)「プロキシサーバのルート証明書」、令和7年 午後Ⅰ問3 設問2(1)「SWG サービスのルート証明書」が同じ答えです。 配布は AD のグループポリシーや MDM で行い、配っていない私物端末や IoT 機器では復号できません。
復号できない・してはいけない通信 (a) アプリが証明書ピンニング(特定の証明書しか受け付けない)をしていると接続自体が失敗する。(b) オンラインバンキングや医療など機密性の高い宛先は復号対象から除外するのが通例。 (c) クライアント証明書で相互認証する通信は、プロキシが代わりに証明書を出せないので復号不可。設問で「復号の対象外にすべき通信」と来たらこの 3 つです。

4. FW・IDS/IPS・WAF・UTM との役割分担

セキュリティ機器は「どの層の何を見るか」で役割が分かれます。設問で「どの機器で防げるか」を問われたら、この表で判断します。

機器見るものできることできないこと
FW(ステートフル)IP アドレス・ポート・TCP の状態通信の許可/拒否。戻りパケットの自動許可。NAPT許可したポートの中身(HTTP の内容)は見ない
プロキシHTTP の URL・ヘッダ・(復号すれば)本文URL フィルタ、認証、ログ、キャッシュ、マルウェア検査HTTP 以外のプロトコル。復号しない HTTPS の中身
IDS / IPSパケットの中身をシグネチャ(既知の攻撃パターン)やアノマリ(通常と違う振る舞い)で照合IDS は検知して通知、IPS はインラインで遮断。脆弱性へのパッチ適用までの間の仮想パッチ暗号化された通信。未知の攻撃(シグネチャがない)
WAFHTTP リクエストの内容(SQL インジェクション、XSS など Web アプリへの攻撃)公開 Web サーバの前に置いて攻撃を遮断。クラウド型は DNS で経由させるWeb 以外。アプリの設計ミスそのもの
UTM上記を 1 台に統合中小拠点向け。FW+プロキシ+IPS+アンチウイルス性能。復号と検査を全部やると遅い
IDS の置き方 IDS はインラインではなく、スイッチのミラーポートからコピーをもらってプロミスキャスモード(自分宛てでないフレームも受け取る)で監視します(平成27年 午後Ⅰ問3 の空欄「アノマリ」「ミラー」「プロミスキャス」)。 検知したら FW の ACL を動的に変えて送信元を遮断する連携もありますが、送信元 IP は偽装されうるので正規の通信まで止める危険があります(同 設問2(3))。IPS は通信を通す「バイパス機能」を持ち、誤検知や故障時に業務を止めないようにします(同 設問3(2))。
C&C サーバとの通信を止める、という設問 マルウェアに感染した PC は、攻撃者の C&C サーバ(指令サーバ)へ HTTPS で定期的に接続します。これは「社内から外への普通の HTTPS」に見えるので FW では止まりません。 止められるのは、プロキシ/SWG の URL フィルタ(既知の C&C の FQDN・IP をブロック)と、プロキシを経由しない通信を FW で全部拒否することの組合せです(令和7年 午後Ⅰ問3 設問2(2)、平成29年 午後Ⅰ問2 設問4、令和元年 午後Ⅱ問2 設問6)。 令和元年 午後Ⅱ問2 設問6(5) は「プロキシ経由を強制すると、マルウェアが C&C の IP アドレスを取得できず宛先を設定できない」という理屈を問いました。

5. クラウド型 SWG への移行

テレワークと SaaS が増えると、自宅の PC は本社のプロキシを通りませんし、本社のプロキシに全拠点の SaaS 通信を集めると詰まります。 そこでプロキシの機能をクラウドのサービスとして使うのが SWG(Secure Web Gateway)です。令和7年 午後Ⅰ問3 がまるごとこの移行の問題でした。

本社 PC FW 旧プロキシは撤去 自宅(テレワーク) PC エージェント SWG サービス URL フィルタ・TLS 復号 マルウェア検査・ログ 出口 IP=SWG-GIP SaaS 一般の Web トンネル orプロキシ設定 社内でも自宅でも、Web へ出る通信は必ず SWG を通る(同じポリシー・同じログ) SaaS 側の「許可する送信元 IP」は、本社のグローバル IP から SWG-GIP へ変更が必要 FW の許可ルールは「内部 → SWG サービス TCP/443」に変わる 赤線=SWG への接続。拠点は IPsec/GRE トンネル、端末はエージェントか PAC で向ける
図4 SWG へ移行した後の通信。社内からも自宅からも SWG を通る

SWG へ通信を向ける 3 つの方法

方法仕組み向く対象
エージェント方式PC に SWG 事業者のソフトを入れ、Web 通信を SWG へ転送(TLS/IPsec のトンネル)。端末がどこにいても同じテレワーク PC、モバイル
トンネル方式拠点のルータ/FW と SWG の間に IPsec や GRE のトンネルを張り、拠点の全 Web 通信を流すエージェントを入れられない機器(複合機、IoT、サーバ)のある拠点
プロキシ設定(PAC)方式PAC で宛先プロキシを SWG の FQDN にする。SWG が従来のプロキシと同じ CONNECT を受ける既存のプロキシ設定をそのまま置き換えるとき

移行で変わる 3 点(ここが設問になる)

周辺の用語を位置づける SWG は「Web 向けの出口の検査」。CASB は「どの SaaS に何をアップロードしたか」を可視化・制御する層で、SWG に同居することが多い。 ZTNA は「社内アプリへのアクセスを VPN の代わりに、利用者・端末ごとの認証で許可する」仕組み。これらに SD-WAN を足してクラウドで一括提供する枠組みが SASE です。 午後では個別の仕組みより「どの通信が、どこを通って、どこで検査されるか」を図で追えることが問われます。

6. 用語集(午後で出る順)

用語意味午後でのポイント
フォワードプロキシ社内 PC の代理で外へ出る。URL フィルタ・ログ・認証・キャッシュ目的を 2 つ答えさせる定番
リバースプロキシ外の利用者の代理で社内サーバの前に立つSSL-VPN・LB・WAF の形。向きの区別
透過型プロキシPC に設定せず、経路上で HTTP を横取りして中継設定不要だが HTTPS の扱いが難しい
PACプロキシ自動設定ファイル。宛先ごとに PROXY/DIRECT を返す JavaScript社内宛て・SaaS 宛てを DIRECT にする。対応しない機器がある
WPADDHCP または DNS(wpad ホスト名)で PAC の URL を自動検出偽 wpad による不正プロキシへの誘導
CONNECTHTTPS 中継用のメソッド。接続先ホスト:ポートを平文で指定し、以後は TCP トンネル443 以外を拒否。プロキシに分かるのは FQDN とポートだけ
プロキシ認証407 で利用者 ID を要求。Basic/ダイジェスト/AD 連携ログを人に結び付ける
TLS 復号(SSL インスペクション)プロキシが中間者として両側に別々の TLS を張るPC にプロキシ CA のルート証明書を配布。ピンニングや機密宛ては除外
ルート証明書信頼の起点となる CA の自己署名証明書配布していない端末では証明書エラー
URL フィルタFQDN・URL・カテゴリで許可/拒否C&C サーバやマルウェア配布サイトの遮断
C&C サーバマルウェアに指令を出す攻撃者のサーバ感染 PC からの外向き HTTPS を止める=プロキシ強制+フィルタ
syslog / NTPログの集約と時刻同期複数機器のログを時系列で突き合わせる前提
IDS / IPS検知のみ/インラインで遮断。シグネチャ型・アノマリ型ミラーポート、プロミスキャス、仮想パッチ、バイパス
WAFWeb アプリ層の攻撃を遮断。クラウド型は DNS で経由XFF ヘッダで元の送信元 IP をサーバへ伝える
UTMFW・プロキシ・IPS・AV の統合機拠点の出口。性能に注意
SWGクラウド型のプロキシ。URL フィルタ・TLS 復号・マルウェア検査・ログエージェント/トンネル/PAC で向ける。出口 IP が変わる
SWG-GIP(出口 IP)SWG がインターネットへ出るときの送信元 IPSaaS の送信元制限をこれに変更
CASB / ZTNA / SASESaaS 利用の可視化/VPN 代替のアプリ単位アクセス/これらの統合位置づけだけ分かればよい
ローカルブレイクアウト特定 SaaS 宛てだけプロキシ・SWG を通さず直接出す速いがログ・フィルタの対象外。詳細は VPN ページ

7. 午後での問われ方と答え方の型

設問の型答え方出た年度
プロキシを導入している目的を N つ登録 FQDN/IP 宛ての通信のブロック、アクセス履歴の確認、利用者認証R7 午後Ⅰ問3
ログの時刻を合わせる理由複数機器のログを時系列で突き合わせて確認するためR7 午後Ⅰ問3
IP アドレスから端末を特定するのに必要なログDHCP サーバ(L3SW)のリースログR7 午後Ⅰ問3
空欄「HTTPS の中継に使うメソッド」CONNECTH30 午後Ⅰ問1、R4 午後Ⅰ問1、H28 午後Ⅰ問2
CONNECT の悪用対策HTTPS(443)以外のポートへの CONNECT を拒否するH30 午後Ⅰ問1
HTTPS でプロキシが確認できる情報接続先ホスト名と接続先ポート番号H28 午後Ⅰ問2
TLS 復号のために PC に入れるものプロキシ(SWG)のルート証明書H30 午後Ⅰ問1、R7 午後Ⅰ問3
URL フィルタで止める通信の相手C&C サーバR7 午後Ⅰ問3、H29 午後Ⅰ問2
PAC のメリット・制限宛先ごとにプロキシ/直接を切り替えられる。対応する PC・アプリでしか使えないR5 午後Ⅱ問1、R6 午後Ⅰ問3
WPAD の取得手段・リスクDHCP、DNS、HTTP で URL を取得。不正なプロキシに中継されるR6 午後Ⅰ問3
プロキシ例外にした宛先で必要になる設定PC 側の DNS・デフォルトゲートウェイ、FW で PC からの直接通信を許可R4 午後Ⅰ問3
SWG 移行後の FW ルール送信元 内部セグメント、宛先 SWG サービス、TCP/443 を許可R7 午後Ⅰ問3
SWG 移行で SaaS 側に必要な変更許可する送信元 IP を SWG の出口 IP に変更R7 午後Ⅰ問3、R5 午後Ⅱ問1
SWG を経由することの欠点経由による遅延。出口 IP が共用だと送信元制限に使えないR4 午後Ⅰ問2
SaaS 宛てを直接出す利点FW・回線・経由機器の負荷軽減、RTT 短縮R7 午後Ⅰ問3
IDS の接続方法・用語ミラーポート、プロミスキャスモード、アノマリ検知H27 午後Ⅰ問3、R4 午後Ⅰ問1
書き方の型 「何のため」は動詞で終える(「ログのため」ではなく「Web サイトへのアクセス履歴を確認するため」)。 通信を答えるときは送信元・宛先・プロトコル/ポートの 3 点セットで書く(「内部セグメント → SWG サービス、TCP/443」)。 証明書を問われたら「誰の・何の証明書か」まで書く(「ルート証明書」だけでは不足、「SWG サービスのルート証明書」)。

8. ミニ確認問題

クリックで答えが開きます。

Q1 フォワードプロキシを置く目的を 3 つURL フィルタリング(登録した FQDN/IP 宛ての遮断)、アクセスログの記録、利用者認証。加えて送信元 IP の集約とキャッシュ。
Q2 プロキシ経由のとき、Web サーバの名前解決をするのは PC かプロキシかプロキシ。PC はプロキシのアドレスだけ知ればよい。だから PC から外部名の DNS 問合せを FW で拒否できる。
Q3 HTTPS をプロキシが中継する手順を 3 行で① ブラウザが CONNECT ホスト:443 を送る → ② プロキシがサーバの 443 へ TCP 接続し 200 を返す → ③ 以後は TLS を含む全データをそのまま双方向に転送する。
Q4 CONNECT を 443 以外にも許すと何が起きるかプロキシを踏み台に任意のポートへ TCP トンネルを張れるので、SSH や独自プロトコルで外部へ抜ける経路になる。
Q5 TLS 復号を有効にする前に PC へ配るものと、配らないとどうなるかプロキシ(SWG)の CA のルート証明書。配らないと、プロキシが発行した証明書を検証できず証明書エラーで接続できない。
Q6 TLS 復号の対象から外すべき通信を 2 つ証明書ピンニングをしているアプリの通信(接続が失敗する)、オンラインバンキングなど機密性の高い宛先。クライアント証明書で相互認証する通信も不可。
Q7 PAC ファイルで実現できることと、できない機器があるのはなぜか宛先ごとに PROXY/DIRECT を切り替えられる(社内宛て・SaaS 宛てを直接)。PAC を解釈するのはブラウザや OS の機能なので、対応しないアプリ・機器では効かない。
Q8 WPAD の仕組みとリスクDHCP オプションか DNS の wpad ホスト名で PAC の URL を見つけ HTTP で取得する。攻撃者が偽の wpad を立てると、PC を不正なプロキシに中継させられる。
Q9 SWG へ移行したとき、SaaS 側と FW 側で変えることSaaS 側: 許可する送信元 IP を本社のグローバル IP から SWG の出口 IP に変更。FW 側: 内部 → SWG サービス(TCP/443)の許可を追加し、旧プロキシ → インターネットの許可を削除。
Q10 マルウェアの C&C 通信をネットワークで止める組合せFW で PC から直接の外向き通信を拒否してプロキシ/SWG 経由を強制し、プロキシ/SWG の URL フィルタで C&C サーバの FQDN・IP を遮断する。

用語の振り返り

このページの用語集(19 語)から作った確認問題です。「意味 → 用語」は意味の説明(用語そのものは__で伏せてある)を読んで用語を入力し、Enter で答え合わせします。 表記ゆれで × になったときは「合っていた」で直せます。「用語 → 意味」は口で説明してから答えを開いて自己採点します。結果はこのブラウザに保存され、「×だけ」で間違えた語だけを解き直せます。

← 拠点間VPNトップ(目次)へ認証連携 →

作成 2026-10-28。ネットワークスペシャリスト 科目B(午後)対策。出典は平成27〜30年秋・令和元年秋・令和4〜7年春の午後Ⅰ・Ⅱ(IPA 公開問題と解答例)。 関連: 拠点間 VPN とは、認証連携とは、午後 解答用紙 令和7年(問3 が SWG 移行)。