ゼロトラストの最前線：CASBリバースプロキシの「URL書換え」という魔術と、その裏にある脆弱性の罠
ネットワークエンジニアとして現場を渡り歩いていると、「境界防御は死んだ」という言葉を耳にしない日はありません。しかし、ゼロトラストへ移行する過程で、我々が避けて通れないのが「マネージド外のデバイスからのアクセス制御」です。
そこで登場するのが、SASEやCASBのリバースプロキシ方式。ユーザーが直接SaaSへアクセスするのではなく、一度CASBのプロキシを経由させることで、通信を「握る」技術です。今回は、この仕組みの核となる「URL書換え」の挙動と、そこに潜むセッションハイジャックのリスク、そしてエンジニアが守るべき鉄則について、泥臭い知見を共有しましょう。
—
1. URL書換えの正体：パケットレベルの「翻訳作業」
リバースプロキシ方式のCASBは、ユーザーのブラウザとSaaSの間に立ち、通信内容をリアルタイムで翻訳します。例えば、本来のSaaSのURLが https://app.example.com だとすると、CASBはこれを https://app.example.com.casb-proxy.com のように書き換えます。
この「URL書換え」は、単にHTMLのリンクを置換しているだけではありません。主要な処理は以下の通りです。
1. HTML/CSS/JSのパース: レスポンスに含まれる絶対パスや相対パスをすべてCASBドメイン経由に変換。
2. Cookieのインターセプト: Set-Cookie ヘッダーを傍受し、ドメインをCASB配下のものに強制変更してクライアントへ渡す。
3. WebSocket/APIのリクエスト変換: JSが発行するXHRや fetch の宛先を書き換える。
このプロセスで最も恐ろしいのは、「書き換え漏れ」による情報漏洩と、「悪意のある改ざん」によるセッションハイジャックです。
—
2. セッションハイジャックを防ぐための「防波堤」
CASB経由の通信において、攻撃者は Cookie を盗もうと躍起になります。特に、リバースプロキシが Cookie の Domain 属性を書き換える際に、Secure 属性や HttpOnly 属性を維持・強化できているかは、設計者の腕の見せ所です。
実践：セッション保護のためのヘッダー構成
CASB側の設定で最低限守るべきは、以下のようなStrictなヘッダー付与です。
# CASBがSaaSへ送る際、またはブラウザへ返す際のヘッダー例
Set-Cookie: session_id=abc123xyz; Domain=casb-proxy.com; Secure; HttpOnly; SameSite=Strictもし、SameSite 属性が None になっていたら……クロスサイトリクエストフォージェリ（CSRF）の格好の餌食です。実務では、必ずブラウザの開発者ツールで、Cookie が意図通りに保護されているかを確認してください。
—
3. Web API開発者が知るべき「URL書換え」のデバッグ
APIを開発・運用していると、CASBを通すと「なぜか画像が読み込めない」「APIが403を返す」といったトラブルに遭遇します。これは、Referer ヘッダーや Origin ヘッダーがCASBによって書き換えられ、SaaS側が「不正なリクエストだ」と判断するためです。
Pythonによる検証コード：ヘッダーの確認
CASB配下からのリクエストが、意図したヘッダーで届いているかを確認する小さなスクリプトです。
import requests
# CASBプロキシを通した際、ヘッダーがどう変換されるかを確認
target_url = "https://app.example.com.casb-proxy.com/api/v1/data"
headers = {
"User-Agent": "Mozilla/5.0",
"Referer": "https://app.example.com.casb-proxy.com/"
}
try:
# 実際のリクエスト実行
response = requests.get(target_url, headers=headers)
print(f"Status Code: {response.status_code}")
# サーバーが受け取ったと想定されるヘッダーの挙動を追跡
print(f"Response Headers: {response.headers}")
except Exception as e:
print(f"Connection Error: {e}")curlによる「生」のトラフィック確認
プロキシを通した時の挙動を疑うなら、やはり curl での直接検証が一番です。
# プロキシを指定してURLの挙動をデバッグ
curl -Iv -x https://your-casb-proxy.com:8080 \
-H "Host: app.example.com" \
https://app.example.com/login-Iv: ヘッダーを詳細に表示し、Set-Cookieがどう変換されているかを確認します。-x: プロキシサーバーを指定。CASBの挙動を直接シミュレートします。
—
4. 現場のシニアエンジニアからの一言
最後に、実務でトラブル対応する際に必ず覚えておいてほしいことがあります。
「CASBは完璧な魔法ではない」ということです。
URL書換えは、極めて難易度の高い「力技」です。シングルページアプリケーション（SPA）のようにJSで動的にURLを生成する環境では、CASBのパーサーが追いつかないケースが多々あります。
トラブルシュートの際、まずはブラウザのネットワークタブを開き、以下の3点を確認してください。
1. X-CASB-Proxy-Info のようなカスタムヘッダーが付与されているか（プロキシ通過の証拠）。
2. Cookie のドメインが casb-proxy.com になっているか。
3. Content-Security-Policy (CSP) が、CASBのドメインを許可しているか。
もし、これらが崩れていれば、それはCASBのポリシー設定ミスか、SaaS側の動的なJS生成が原因です。焦らず、パケットの「翻訳前後」を比較してください。
ネットワークの境界は消えましたが、その代わりに「トラフィックをいかに安全に仲介するか」という新しい境界線が生まれています。この仕組みを深く理解することが、モダンなインフラエンジニアとしての生存戦略になるはずです。
現場からは以上です。次の現場でまた会いましょう。
コメント