社内から公開サービスまでの配置

社内端末から公開Webサービスへ接続するとき、『プロキシを通った』という記録だけで、その通信内容まで検査されたと言えるでしょうか。この記事では、架空の社員端末がhttps://portal.example/invoices/41を開く一連の通信を追い、PACによる経路選択、CONNECT、TLS、公開側リバースプロキシの順に整理します。

科目B（午後）で答えるべき中心は、各機器の位置とTLS終端、機器が観測できる範囲、許可・拒否の根拠、ログから言えることの限界です。後半ではTLSインスペクション、PAC改ざん、CONNECTの濫用、転送ヘッダ偽装を同じ構成で検討します。ドメイン、IPアドレス、時刻、ログはすべて教材用の架空例です。

1. まず通信の登場人物と目的を分ける

社員端末192.0.2.10のブラウザは、社外サイトportal.exampleへアクセスします。社内の送信側プロキシはproxy.corp.example:8080、公開サイトの入口にあるリバースプロキシはportal.example:443、背後のアプリは10.0.2.20:8443とします。公開側と社内側は別の管理主体です。

用語	意味とこの例での役割
フォワードプロキシ（以下、送信側プロキシ）	クライアント側が選んで利用する中継点。proxy.corp.exampleは社員端末の代わりに社外へ接続し、認証・宛先制御・ログ記録を行う。単に『プロキシ』というときはこの意味が多いが、試験では配置を確かめる。
リバースプロキシ	サービス提供側の入口としてクライアントからの接続を受け、背後のアプリへ転送する中継点。portal.exampleの公開TLSを終端し、要求を10.0.2.20:8443へ送る。クライアントは通常、背後のアプリの私設IPを直接指定しない。
PAC（Proxy Auto-Configuration）	ブラウザなどのクライアントが各URLについて利用先プロキシ又はDIRECT（直接接続）を選ぶ設定スクリプト。選択は接続前に端末側で行われる。PACそのものは強制的な通信遮断装置ではない。
CONNECTメソッド	HTTPプロキシへ宛先ホスト:ポートへのトンネル確立を要求するメソッド。HTTPSの典型例では200などの2xx応答後、ブラウザと宛先のTLSデータを中継する。2xxはトンネル開始を表し、TLS認証やWebアプリ処理の成功を意味しない。
TLSインスペクション	送信側プロキシがクライアント側TLSを終端してHTTPを検査し、公開サイトへ別のTLS接続を張り直す方式。クライアントには組織の検査用CAが発行した代替サーバ証明書を提示する。対象通信だけに適用される設定もある。
TLS終端	TLSを復号する接続の終点。この例で通常トンネルなら公開側リバースプロキシ、検査ありなら社内プロキシと公開側リバースプロキシの二か所に別々のTLSセッションがある。単にパケットを転送する装置は、その接続のHTTP本文を復号できない。

送信側プロキシは『社員がどこへ出るか』を、リバースプロキシは『外から来た要求をどのアプリへ渡すか』を扱います。どちらも製品によって認証、キャッシュ、WAFなどを備え得ますが、名称だけで機能の有無を決めず、構成と設定を確認します。

社内から公開サービスまでの配置

1. PACの指定先へ接続
2. CONNECT後の転送又は検査後の別接続
3. 別のTLS接続で転送

社員側と公開サービス側で管理境界が異なる。バックエンドのIPは私設アドレス。

通常トンネル時、ブラウザのTLSは送信側プロキシの中継を経て公開入口まで続きます。公開入口からバックエンドへは別のTLS接続を使う設定とします。

2. PACはどの経路を選ぶか

PACのFindProxyForURL(url, host)はURLとホスト名を受け、利用するプロキシの列又はDIRECTを返します。次の例では社内ドメインを直接接続し、それ以外をproxy.corp.example:8080へ送ります。portal.exampleは社外なのでプロキシを選びます。

javascript

function FindProxyForURL(url, host) {
  if (host === "corp.example" ||
      dnsDomainIs(host, ".corp.example")) {
    return "DIRECT";
  }
  return "PROXY proxy.corp.example:8080";
}

PACの値・関数	意味と判断上の注意
url	アクセス先URL。https://のパスやクエリをPACへ渡さないブラウザ実装がある。この例はホスト名で分岐し、/invoices/41などのHTTPSパスをPACで判定する前提を置かない。
host	URLの接続先ホスト名。ここではportal.example又はcorp.exampleなど。呼び出し側から渡された値であり、接続先が安全であるとの認証結果ではない。
dnsDomainIs(host, ".corp.example")	サブドメインかどうかを文字列上で判定するPAC関数。この条件だけでは裸のcorp.exampleは一致しないため、例では別にhost === "corp.example"を確認する。
PROXY proxy.corp.example:8080	送信側の通常HTTPプロキシを指定する。ここでのPROXYはクライアントとプロキシ間の接続自体がTLSで保護されることを意味しない。宛先サイトへのHTTPSはCONNECT後に別途成立する。
DIRECT	プロキシを経由せず宛先へ接続する指示。社内向けに許したDIRECTが外部にも広がると、プロキシの認証・ログ・宛先制御を迂回し得る。
PROXY ...; DIRECT	左から試す代替経路の指定。プロキシ障害時に直接接続へ移る構成では、可用性は上がるが外部通信が検査を迂回し得る。実装や失敗の条件はブラウザごとに確認する。
PAC取得失敗・適用外アプリ	PACの取得・解析失敗時の動作や適用対象はクライアント実装と設定による。ブラウザだけのPACでは、別アプリの外部通信や端末の設定変更を強制的に抑えられない。

PACの配布先と更新権限は重要です。改ざんされると、外部サイトをDIRECTにしたり、攻撃者のプロキシを返したりできます。ただし攻撃者プロキシを通っただけで、正しく検証されたHTTPS本文を復号できるわけではありません。端末が攻撃者のCAを信頼している、利用者が証明書警告を無視するなど別条件が必要です。

PACをHTTPS等の保護された経路で配布し、配布元・更新権限・変更履歴を管理する。
外部向けDIRECTを禁止したい場合は、出口のFWでも端末から社外への直接接続を拒否し、プロキシの送信元だけを許可する。
PAC配布失敗やプロキシ障害時の実際の挙動を対象ブラウザ・アプリで検証する。企業の方針が遮断なら、正常時と障害時の両方で外部へ直通できないことを確認する。

3. CONNECTでトンネルを作り、公開側までTLSを張る

以下はHTTP/1.1で送信側プロキシへ接続する例です。ブラウザはPACの結果に従ってproxy.corp.example:8080へ接続し、公開サイトのホスト名とポートをauthority-formで送ります。送信側プロキシは社員の利用権限と宛先を確認してから接続を許可します。

text

CONNECT portal.example:443 HTTP/1.1
Host: portal.example:443

HTTP/1.1 200 Connection Established

[この後、トンネル内でブラウザとportal.exampleのTLS通信]

CONNECTの要求行に/invoices/41は入りません。200はプロキシがトンネルモードへ移る合図です。この直後のTLSハンドシェイクでブラウザがportal.exampleのサーバ証明書を検証し、成立後に暗号化されたGET要求を送ります。証明書の検証に失敗すれば、CONNECTが200でもWebページは正常表示されません。

検査なしのHTTPSトンネル

PACの選択後。TLSはブラウザと公開側リバースプロキシ間で成立する。

図のブラウザと公開側入口の矢印は、送信側プロキシがTCPバイト列を中継する論理上の通信です。プロキシに通常のトンネル機能しかなければ、その機器はCONNECT宛先、接続時刻、通信量などを観測できますが、TLS内のGETパス、Cookie、本文は読めません。

3-1. HTTPリクエストの3形式を混同しない

通信場面	HTTP/1.1の要求行と読み方
平文HTTPを送信側プロキシへ	GET http://portal.example/help HTTP/1.1 はabsolute-form。プロキシが完全なURLを受けて転送先を決める。平文HTTPなら経路上にHTTP内容が見える。
HTTPSのトンネルを要求	CONNECT portal.example:443 HTTP/1.1 はauthority-form。宛先のホストとポートだけをプロキシへ要求し、リソースのパスは要求行にない。
TLS後の公開側入口・バックエンド	GET /invoices/41 HTTP/1.1 はorigin-form。クライアントと公開側入口のTLS内にあるため、単なるCONNECT中継プロキシのHTTPログには現れない。

これはHTTP/1.1の表記例です。HTTP/2のCONNECTはストリームと擬似ヘッダで表現するため、HTTP/1.1の要求行をそのまま見つける前提で解析しません。メソッドが同じでも、キャプチャ対象のHTTPバージョンを確認します。

3-2. 407・403・502・200の段階を読み分ける

観測	言えることと追加確認
407 Proxy Authentication Required	プロキシがクライアント認証を要求。ブラウザのプロキシ認証設定・資格情報・プロキシ側の認証記録を調べる。この応答だけで公開サイトの障害とは言えない。
403などプロキシによる拒否	設定した宛先ACL、利用者ポリシー、ブロック理由を確認する。403という数値だけではプロキシが返したか、トンネル内の公開サイトが返したか分からないため発生点を特定する。
502・504など中継側のエラー	名前解決、宛先TCP接続、上流TLS、上流応答のどの段階で失敗したかをログと時刻で調べる。同じコードでも送信側・公開側のどちらが生成したかで対処が異なる。
CONNECTへの2xx応答	トンネルモードが始まったことを示す。続くTLS証明書検証、HTTP応答、アプリ認証、画面描画の成功は別々に確認する。

4. TLSインスペクションではどこで復号するか

組織が対象宛先のTLSインスペクションを有効にした場合、送信側プロキシはブラウザとのTLSを終端し、portal.exampleへ自分で別のTLS接続を張ります。ブラウザに提示するportal.example名の証明書は、公開サイトの実物ではなく、組織の検査用CAによって発行された代替証明書です。

検査ありの二つのTLS接続

ブラウザと検査プロキシ、検査プロキシと公開側入口が別々にサーバ証明書を検証する。

図では検査処理の自己矢印を省略しています。プロキシはブラウザから受けたHTTPを復号して検査・記録した後、公開側入口へ別のTLS接続で送ります。ブラウザ側の検証対象は組織CAが発行した代替証明書、プロキシ側の検証対象は公開サイトの実際の証明書です。片方の成功はもう片方の成功を証明しません。

検証する側	必要な信頼と失敗時の意味
ブラウザ→検査プロキシ	端末の信頼ストアに、組織の検査用CAを安全に配布する。代替証明書の名前がportal.exampleに合うことも要る。組織CAが未登録なら証明書エラーになる。公開サイトのCAを端末が信頼するだけでは足りない。
検査プロキシ→公開側入口	プロキシ自身が公開サイト証明書のチェーン、名前、有効期間などを検証する。ここを無効にすると、プロキシが偽サイトへTLS接続しても端末には組織CAの『正常な』代替証明書を提示し得る。
公開側入口→内部アプリ	この例では別TLS接続で10.0.2.20:8443へ接続する。入口は内部アプリの証明書と宛先を検証する。外側のHTTPSだけでは内部区間が保護されると決まらない。
証明書ピンニング・クライアント証明書	アプリが接続先の公開鍵や発行者を固定する場合、代替証明書を拒否し得る。クライアント証明書を使う方式も構成により透過的検査が困難。例外は対象・理由・承認者を限定し、検査なしトンネルの宛先制御を残す。

組織CAの発行鍵は、多数の宛先名の代替証明書を作れる高権限の鍵です。専用CAを用いて発行鍵の保護、利用監査、端末への信頼配布、鍵更新、失効・撤去手順を管理します。検査対象には個人情報や機微情報を含む通信もあるため、対象範囲、ログの保持・閲覧権限、例外を事前に定めます。

4-1. どの装置が何を見られるか

観測点	通常トンネルと検査ありで見える範囲
社員端末	ブラウザはアクセスした完全なURL、HTTP応答、実際に提示された証明書を確認できる。PACの選択や証明書例外が端末に記録されるかは製品・設定次第。
送信側プロキシ・検査なし	CONNECT宛先portal.example:443、利用者認証の結果、接続先IP、接続時刻、通信量などを記録できる。HTTPSのGETパス、Cookie、本文、最終HTTPステータスは通常読めない。宛先IPやTLSメタデータの記録範囲は製品次第。
送信側プロキシ・検査あり	その接続を実際に復号した場合、GET /invoices/41、HTTPヘッダ、応答などを検査できる。全HTTPS通信を自動的に検査したと決めず、対象ポリシーと実際の検査ログを確認する。
公開側リバースプロキシ	公開TLSを終端するため、HTTPメソッド、パス、ステータス、送信元接続IPを見られる。接続元は社員端末ではなく、送信側プロキシの外向きIPになり得る。社員個人の識別には別証跡が要る。
内部アプリ	公開側入口が転送したHTTP要求を受ける。TCPの直接の相手は公開側入口。元の接続IPを知るには、信頼した入口が付与した転送ヘッダ又は別の認証情報・相関情報が要る。

『接続先ホスト名が見えた』と『URLのパスが見えた』は違います。トンネルのCONNECTにホスト名があり、TLSの中にパスがあります。検査ありのログにパスが記録されても、公開側のアプリが正しく処理したかは応答と公開側ログまで照合します。

5. リバースプロキシは元の接続元をどう伝えるか

公開側リバースプロキシはportal.exampleの証明書で外部TLSを終端し、要求パスやHostに基づいて内部アプリを選びます。この例では/invoices/41を10.0.2.20:8443へ別TLSで渡します。バックエンドのソケットが見る接続元は公開側入口であり、社員端末のIPではありません。

転送ヘッダForwardedは、たとえばfor（直前のクライアント側のIP）、proto（元のプロトコル）、host（元のHost）などを伝えられます。X-Forwarded-Forも広く使われますが標準化された単一の信頼判定規則はありません。値はただのHTTPヘッダなので、インターネットから届いた値をそのまま『真正な送信元IP』と扱えません。

text

# 公開側入口が受けた要求の例
peer_ip=198.51.100.40
method=GET
host=portal.example
path=/invoices/41
inbound_xff=203.0.113.77

# 信頼できないinbound_xffを破棄して入口が付け直す例
Forwarded: for=198.51.100.40;proto=https;host=portal.example
X-Forwarded-For: 198.51.100.40
X-Request-ID: req-51

198.51.100.40は送信側プロキシの外向きIPとし、203.0.113.77は外部から持ち込まれた偽のX-Forwarded-For値とします。公開側入口が直接観測したpeer_ipは前者です。社員端末192.0.2.10を示す値は、この公開側入口だけでは確定できません。上記のX-Request-IDは説明用に入口が付ける相関IDであり、製品が自動生成する保証はありません。

公開入口で外部から来たForwardedとX-Forwarded-*を破棄又は規則に従い再構築し、バックエンドは信頼済み入口からの接続だけでその値を使う。
バックエンドへの直通をFWで禁止し、入口とバックエンド間のTLS証明書も検証する。直通できると、攻撃者が転送ヘッダを任意に付けられる。
IP制限やレート制限で元IPを使う場合、プロキシの連鎖でどの位置の値を採用するかを固定し、未知の中継点の申告値を信頼しない。複数社員が同じ外向きIPを共有する前提で設計する。

もし公開側入口がinbound_xff=203.0.113.77をそのままバックエンドへ渡し、バックエンドがこの値を管理者許可IPとして扱うと、HTTPヘッダを送れる攻撃者がIP制限をすり抜けるおそれがあります。必要な成立条件は、入口が未検証ヘッダを通すこと、バックエンドがそれを信頼すること、当該IPで認可することの三つです。

6. 架空ログを段階ごとに読み、確定事項を分ける

次のログは正常な一回のアクセスを説明するための架空例です。各行は実製品のログ形式ではなく、観測点を揃えた要約です。時刻はすべてUTC、公開側入口のpeer_ip=198.51.100.40は送信側プロキシの外向きIPです。

text

09:00:00.100 browser
  client=192.0.2.10 target=portal.example:443
  pac=PROXY proxy.corp.example:8080
09:00:00.210 forward-proxy
  user=alice client=192.0.2.10
  connect=portal.example:443 result=200
  egress=198.51.100.40 inspection=off
09:00:00.410 browser
  tls_peer=portal.example cert_validation=ok
09:00:00.530 reverse-proxy
  peer=198.51.100.40 method=GET
  path=/invoices/41 request_id=req-51
  upstream=10.0.2.20:8443 status=200
09:00:00.590 backend
  peer=10.0.2.1 request_id=req-51
  route=/invoices/41 status=200

証跡	確定できること／まだ言えないこと
browserのPAC選択	そのブラウザが当該URLをプロキシ経由に決めたこと。別アプリや別時刻も同じ経路だったとは言えない。端末改ざんの有無は設定履歴も要る。
forward-proxyのCONNECT 200	aliceとして認証された接続がportal.example:443へのトンネルを得たこと。GET /invoices/41やアプリ処理成功はこの行だけで分からない。userの真正性には認証方式とアカウント共有状況も関わる。
browserのTLS検証成功	ブラウザがその接続で提示された証明書を受け入れたこと。inspection=offと突き合わせて公開側証明書を検証したと考えられるが、証明書のチェーン・主体を確かめるには証明書記録が要る。
reverse-proxyのGET・200	公開側入口がGET /invoices/41を受け、req-51に200を返したこと。peerは送信側プロキシの外向きIP。社員端末のIPや、応答本文が利用者に表示されたかまでは確定できない。
backendのreq-51・200	バックエンドが入口から同じ相関IDの要求を受け、200を返したこと。実際の業務上の成功や画面表示、データの内容はアプリログ・監査ログ・ブラウザ側の確認が要る。

req-51は公開側入口とバックエンド間の相関には使えますが、送信側プロキシのログには出ていません。この例で両組織の記録を結ぶには、時刻の同期、接続先、外向きIP、通信量、必要なら公開側のTLS接続識別子や端末側の記録を突き合わせます。同時接続が多いと時刻とIPだけでは一意に決まらず、断定を避けます。

7. 異常時は攻撃条件・防御点・証跡を一緒に読む

異常・攻撃	成立条件、対策、残る確認
PAC改ざんによるDIRECT	攻撃者がPAC配布元又は端末設定を変更でき、外部向けにDIRECTを返す。プロキシログが消えても通信停止とは限らない。PACの変更履歴と端末設定を保全し、出口FWで端末の直通を遮断する。
悪意のあるプロキシへ誘導	PAC改ざんでPROXY evil.example:8080を返す。攻撃者は宛先・時刻・通信量を見たり妨害したりできるが、正しく検証されたHTTPSを直ちに復号はできない。端末の信頼ストアや証明書警告、検査用CAの配布状態も確認する。
CONNECTの無制限許可	認証や宛先・ポート制限が甘く、攻撃者がプロキシに到達できる。port 25などWeb以外へ中継して踏み台にできる。送信元認証、許可宛先・ポート、名前解決後IPの制限、ログ監視を行う。
X-Forwarded-For偽装	公開入口が外部入力の転送ヘッダを通し、バックエンドがその値でIP認可する。入口で破棄・再構築し、バックエンドへの直通を遮断する。入口のpeerとヘッダ両方を保存して差を確認する。
TLS検査の上流検証無効	検査プロキシが公開側証明書の名前・チェーン検証を省き、攻撃者が上流経路を偽装できる。ブラウザ側は組織CAの代替証明書を正常と判定し得る。上流検証を復旧し、対象期間の接続先IPと証明書を調べる。
内部転送区間の保護不足	公開側入口とバックエンドが信頼できない区間を平文で通り、そこに攻撃者がアクセスできる。入口の公開HTTPSだけでは守れない。内部区間TLSと証明書検証、ネットワーク分離を確認する。

PAC改ざんから社外直通まで

1. PACを書き換え：証跡配布元の変更履歴・端末内PAC／防御・対処配布元と更新権限を保護
2. DIRECTを選択：証跡ブラウザの経路選択記録／防御・対処対象URLとPAC結果を検証
3. 社外へ直接接続：証跡 FW・DNS・端末の接続記録／防御・対処出口FWで端末直通を拒否
4. プロキシ記録を回避：証跡同時刻のプロキシ記録欠落／防御・対処端末・出口・プロキシを相関

プロキシ回避の成立にはPAC改ざんに加え、出口で端末直通が許される必要がある。

プロキシにログがないことだけでは直通の証明になりません。端末でPACがDIRECTを返した証跡、出口FWに端末の宛先接続が残ること、当該時刻にプロキシを通っていないことを組み合わせます。出口FWが既に端末直通を拒否していれば、PAC改ざんは通信失敗を起こしても社外直通には至りません。

7-1. CONNECTの宛先は名前だけで許可しない

CONNECT portal.example:443の宛先は、リクエストを送ったクライアントが指定する値です。プロキシが宛先名をDNSで引く構成では、名前への許可判定と実際の接続先IPが一致しているかが重要です。宛先名だけを許可し、名前解決後に私設IPや管理用IPへ接続できると、プロキシを内部ネットワークへの踏み台にされ得ます。

制御位置	許可判定で確認する内容
クライアントからプロキシへの入口	利用者又は端末を認証し、使えるプロキシの入口を社内に限定する。407による認証要求と認証失敗をログで区別する。認証があっても、アカウント窃取や設定誤りによる濫用は残る。
CONNECT要求の宛先	ホスト名、ポート、利用者の許可範囲を確認する。port 443だけを許す方法もあるが、443上の非WebサービスまでWebとみなさない。必要な宛先だけを許すほど効果が高い。
プロキシの名前解決後	接続先IPが許可された範囲か確認し、私設・ループバック・リンクローカル・管理用の宛先を禁止する。複数のA・AAAAや名前解決の再実行がある場合、実際に接続するIPで判定する。
プロキシから外への出口	FWでプロキシ自体が到達できる宛先とポートを絞る。アプリ側ACLをすり抜けても出口で止められるよう、禁止対象への接続試験を行う。

『CONNECTを許す』ことは、HTTP要求の中身を安全と認めることではありません。トンネル化後に何が流れるかは通常の中継プロキシには分からず、443番であってもHTTPS以外の通信が通る場合があります。宛先制限はCONNECT時に、内容検査が必要なら別の適切な検査点で行います。

7-2. 検査対象から外れる通信を把握する

TLSインスペクションの方針は、端末で使う全通信に自動的に適用されるわけではありません。PAC適用外アプリ、プロキシを使わない直通通信、明示的な検査除外先、トンネルを許したが復号できなかったアプリを区別します。HTTP/3はUDPを使うため、HTTP/1.1のCONNECTを使う経路だけを見ても全量を把握できません。実際の利用プロトコルと出口制御を確認します。

TLS検査を例外にした宛先では、送信側プロキシは通常トンネルとして接続先と通信量を扱えても、HTTPパスは読めません。ピンニング対応のために例外を広げる際は、対象ホスト、業務理由、期限、承認者、代替となる端末・公開側ログを記録します。例外を作ったことと、宛先制御まで解除することは別です。

検査プロキシは認証情報や個人情報を含むHTTP本文を見られるため、ログにCookieやAuthorizationヘッダを無制限に保存しない設計が必要です。検査可否、記録項目、閲覧権限、保存期間を分けて管理します。調査時には『プロキシが復号可能だった』ことと『当該本文がログに残った』ことも区別します。

8. 設定変更・障害・復旧をどう進めるか

検査開始やプロキシ移行では、PACを変えるだけでは足りません。利用者認証、プロキシ宛先ACL、出口FW、組織CAの端末配布、上流サーバ証明書検証、ログと例外の管理を一緒に設計します。新旧構成が混在する期間の経路を明記し、誰が変更・承認・復旧を判断するか決めます。

PAC改ざん・検査障害時の対処

1. 範囲を特定：対応影響端末とPAC版を確認／確認する証跡端末設定・配布履歴
2. 直通を遮断：対応出口FWとPACを是正／確認する証跡拒否ログ・変更記録
3. 信頼を確認：対応組織CAと上流検証を点検／確認する証跡証明書・検査ポリシー
4. 通信を調査：対応端末・プロキシ・公開側を照合／確認する証跡時刻・宛先・相関ID
5. 再開を判断：対応正常・拒否・障害時を試験／確認する証跡試験結果・承認記録

原因の種類を切り分け、正常な接続と拒否されるべき経路を両方試す。

検査プロキシの証明書エラーでは、まずブラウザに提示された証明書の発行者を確認します。組織CA未配布なら端末側、プロキシが公開サイト証明書を拒否したなら上流側、ピンニングを行うアプリなら設計上の非互換を疑います。証明書検証を一律に無効化して復旧扱いにはしません。

PAC改ざん後は、配布元の不正な変更権限を除き、正しいPACを再配布し、古いキャッシュや端末ごとの例外設定を点検します。検査用CAの発行鍵が漏れた疑いがある場合は、単なるPAC修正で終えず、鍵の利用停止・新CAへの切替え・旧信頼の撤去と影響範囲調査を進めます。

正常試験：portal.exampleがPROXYを選び、CONNECT、TLS証明書検証、公開側・内部アプリの応答まで成功する。検査対象なら検査ログにも対象パスが残る。
拒否試験：端末が外部へDIRECTを選んでも出口FWが遮断し、認証なしのCONNECTや禁止ポートが送信側プロキシで拒否される。
障害試験：PAC配布元又はプロキシの停止時に、組織が定めた遮断・代替経路へ進む。証明書エラーの例外操作を利用者へ強いない。
公開側試験：外部から持ち込んだX-Forwarded-ForでバックエンドのIP認可が変わらず、バックエンドへの直通もできない。

9. 科目B（午後）の記述演習

演習1：CONNECT 200の意味

条件：送信側プロキシにCONNECT portal.example:443 result=200があり、社員は画面を開けない。問い：200から確定することと、次に調べることを述べよ。

解答：トンネルの開始は確認できる。ブラウザのTLS証明書検証、TLSハンドシェイク、公開側入口のHTTPログと応答、ブラウザのエラーを調べる。誤答『Webアプリは200を返した』はCONNECTの応答とTLS内のHTTP応答を混同している。

演習2：プロキシにURLパスがない

条件：inspection=offで、プロキシログにはportal.example:443と通信量だけがある。問い：/invoices/41へのアクセスを証明するには何が必要か。

解答：端末のブラウザ記録又は公開側入口のHTTPログで当該パスを確認し、時刻・接続先・送信側の外向きIPなどで相関する。誤答『CONNECTがあればパスも分かる』は、パスがTLS内にあるため成り立たない。

演習3：PACのDIRECTと出口制御

条件：PACが改ざんされ、portal.exampleにDIRECTを返した。出口FWは社員端末から社外への直通を拒否する。問い：起こることと調査対象を述べよ。

解答：ブラウザは直通を試すがFWで拒否され、プロキシを使った接続は成立しない。PACの変更履歴、端末の適用結果、FW拒否ログを調べる。誤答『必ず情報が流出した』は出口で遮断される条件に反する。

演習4：公開側のIP制限

条件：外部利用者がX-Forwarded-For: 203.0.113.77を指定し、203.0.113.77は管理者許可IPである。公開側入口がこのヘッダをそのまま通す。問い：脆弱になる追加条件と対策を述べよ。

解答：バックエンドが未検証の値を真正な元IPとして認可に使うと成立する。公開側入口で外部入力の転送ヘッダを破棄して観測したpeerから再構築し、バックエンドは信頼済み入口からの接続だけを受ける。誤答『ヘッダをHTTPSで送れば真正』は、TLSが送信者によるヘッダ内容の偽装を防がないため誤り。

演習5：TLS検査の証明書エラー

条件：検査導入後、ブラウザには組織CA発行のportal.example証明書が提示されるが、特定端末だけ警告を出す。問い：最初に確認する設定と避けるべき対処を述べよ。

解答：その端末の信頼ストアに正規の組織CAが配布され、名前・有効期間が一致するか確認する。証明書警告を無視させる運用は避ける。誤答『公開サイトのCAを追加すればよい』は、ブラウザが検証する代替証明書の発行者を取り違えている。

演習6：上流証明書検証を無効にした場合

条件：検査プロキシが公開側入口の証明書検証を無効化していた。問い：なぜ危険か、復旧後に何を確認するか。

解答：攻撃者が上流接続を偽装できる位置にいれば、プロキシは偽サイトとのTLSも受け入れ、端末には組織CAの代替証明書を正常提示し得る。検証を有効化し、対象期間の宛先IP・提示証明書・接続記録を調べ、正常サイトと偽証明書の拒否を試す。誤答『端末が組織CAを信頼しているので安全』は、二つのTLS接続を一つとみなしている。