WebSocketの闇を暴け：SASE/CASB環境における「見えない通信」への処方箋
現場のエンジニア諸君、今日もパケットの海を泳いでいるか？
最近、多くの企業がSASE（Secure Access Service Edge）を導入し、境界防御からアイデンティティ中心のゼロトラストへと移行している。中でもCASB（Cloud Access Security Broker）は、SaaS利用を可視化・制御する要として欠かせない存在だ。だが、現場で泥臭いトラブルシューティングを繰り返していると、避けて通れない「死角」がある。それが WebSocket だ。
今日は、HTTPSの皮を被った「永続的コネクション」が、いかにしてCASBのリアルタイムインスペクションをすり抜けてしまうのか、そして我々エンジニアはどう立ち向かうべきかについて、実務的な知見を共有しよう。
—
1. なぜWebSocketはCASBの「目」を盗むのか
通常のHTTP通信は「リクエスト→レスポンス」の短いサイクルで完結する。CASBのインラインプロキシ（通常は透過的なフォワードプロキシとして動作）は、この境界でパケットをバッファリングし、DLP（情報漏洩対策）エンジンでペイロードをスキャンする。
しかし、WebSocket は違う。HTTP Upgrade ヘッダーによってハンドシェイクが完了した瞬間、プロトコルはTCP上のストリームへと変貌する。
GET /chat HTTP/1.1
Host: saas-app.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13一度このトンネルが開通すると、以降の通信はフレーム単位のバイナリデータとしてやり取りされる。多くのCASBは、CPU負荷とレイテンシの観点から、この「長時間続く双方向ストリーム」の全データをメモリ上に保持してリアルタイムスキャンすることができない。結果として、「接続開始時の認証は通したが、その後のデータの中身はノーチェック」という状態が生まれる。これがセキュリティ上の最大の盲点だ。
—
2. 現場で直面する「見えないデータ」の実践的デバッグ
まずは、自分の環境でWebSocketがどう流れているか、簡単なクライアントで可視化してみよう。Pythonの websocket-client ライブラリを使うと、通信の断片を捕まえるのが容易だ。
import websocket
# 接続先SaaSのWebSocketエンドポイント
def on_message(ws, message):
# ここで受信した生データをログに出力する
# CASBがインスペクションできていれば、ここにDLPの警告が入るはずだが...
print(f"Received: {message}")
ws = websocket.WebSocketApp("wss://saas-app.example.com/stream",
on_message=on_message)
ws.run_forever()このコードを実行し、Wiresharkでパケットを追いかけてみるといい。TLS復号化が有効な環境であれば、Payload Data が暗号化されずに（CASBのプロキシを通ったはずなのに）生データとして流れていく様が見えるはずだ。もしCASBが適切に制御していれば、特定のキーワードを含んだメッセージを送った際に 403 Forbidden が返されるか、コネクションが強制切断されるはずだが、現実はそう甘くない。
—
3. 実践的対策：CASBの限界をどう補完するか
CASBのリアルタイムインスペクションが効かない以上、我々は「レイヤーを分けた多層防御」で対抗する必要がある。
A. APIレベルの制御（API-based CASBの活用）
リアルタイム（インライン）の限界を悟ったら、次は「API連携型CASB」の出番だ。SaaS側のAPIを叩き、アップロードされたファイルやメッセージ履歴をスキャンする。これはリアルタイムではないが、少なくとも「事後検知」として強力な武器になる。
B. エンドポイントでの制御
通信の出口で止められないなら、入口で止める。EDR（Endpoint Detection and Response）を駆使し、ブラウザの拡張機能や不審なプロセスによるWebSocket通信を監視する。
C. プロキシの「明示的切断」ポリシー
もし特定のSaaSでDLPが必須なら、ポリシー設定で特定のWebアプリケーションに対する Upgrade ヘッダーを遮断する、あるいは「WebSocketの使用を許可しない（HTTPSのREST APIのみに限定させる）」という運用判断も一つの技術的選択肢だ。
設定例（Nginxや一部の次世代ファイアウォールでの考え方）：
# WebSocketのUpgradeを許可しない設定例
if ($http_upgrade = "websocket") {
return 403; # セキュリティポリシーによりWebSocketを拒否
}—
4. エンジニアへのアドバイス：泥臭い検証の重要性
最後に、ネットワークスペシャリストとして一つだけ伝えたい。「ベンダーのスペックシートを信じすぎるな」。
CASBのカタログには「WebSocket対応」と書かれているかもしれない。だが、それは「ハンドシェイクを通す」という意味なのか、それとも「フレーム内のペイロードまで検査する」という意味なのか。この微妙な差が、インシデント発生時の生死を分ける。
現場でやるべきことは単純だ。
1. 意図的にDLP検知ルールに引っかかるような「ダミーの個人情報」をWebSocket経由で送ってみる。
2. CASBのログコンソールにそのイベントが記録されるか確認する。
3. 記録されないなら、その通信経路は「信頼してはいけない」という前提でインフラを設計し直す。
ゼロトラストとは「何も信頼しないこと」だ。技術の死角を技術で埋めるのではなく、死角がある前提でシステムを設計する。それが、トラブルを乗り越えてきた我々のようなエンジニアの「凄み」なのだ。
パケットは嘘をつかない。自分の目で見て、自分の手で検証し、確実な守りを構築してくれ。健闘を祈る。
コメント