こんにちは！ゼロトラストや最先端のネットワークセキュリティの世界へようこそ。
日々、企業のネットワークを守るために奮闘されているインフラエンジニアの皆さん、そしてこれからネットワークの世界に飛び込もうとしている初学者の皆さん、お疲れ様です。
今回は、最近のクラウドサービス（SaaS）の裏側でこっそり使われている、ちょっと厄介で最高に面白い「WebSocket（ウエブソケット）」という技術と、それを監視する「CASB（キャスブ）」の切っても切れない関係についてお話ししていきます。
「WebSocket？なんだか難しそうな名前だな…」と思ったそこのあなた、安心してください！
難しいパケットの構造や、呪文のような英語のヘッダー名はいったん脇に置いて、身近な例えから一歩ずつ優しく紐解いていきましょう。それでは、さっそく扉を開けてみましょう！
—
1. そもそもWebSocketってなに？ 郵便配達に例えてみよう
私たちが普段見ているWebサイトは、基本的に「質問をしたら、答えが返ってくる」という往復書簡のような仕組みで動いています。これを「HTTP通信」と呼びます。
あなたが「このページを見せて」と手紙（リクエスト）を出し、サーバーが「はい、どうぞ」と返事（レスポンス）をしたら、そこで一度郵便配達のやり取りは終わりです。
しかし、チャットアプリやリアルタイムで更新されるダッシュボード、SaaSの画面などを思い出してください。相手からの返事を待たずに、向こうから次々と情報が飛び込んできますよね。
ここで登場するのが WebSocket です。
WebSocketは、一度サーバーとクライアントの間で「握手（ハンドシェイク）」を交わすと、「よし、これからは専用のパイプラインを繋ぎっぱなしにして、いつでも双方向でキャッチボールをしよう！」という状態を作る技術です。
イメージとしては、普通の郵便配達ではなく、「一度繋いだら切り札なしでずっと喋り続けられる専用の直通電話」のようなものですね。
この「繋がりっぱなし」という特徴が、パフォーマンスを爆発的に上げる一方で、ネットワークセキュリティの守護神たちを大いに悩ませることになるのです。
—
2. CASB（キャスブ）ってどんなお巡りさん？
ここで、今回のもう一つの主役である CASB（Cloud Access Security Broker） についておさらいしておきましょう。
CASBは、社員が会社の外から（あるいは社内から）様々なSaaSを利用する際、「変なデータをアップロードしていないか？」「怪しいマルウェアをダウンロードしていないか？」を監視・制御する、いわば「クラウド専用の凄腕お巡りさん」です。
通常、CASBは流れてくるHTTPのパケットを一枚一枚めくり、「おっと、このファイルには機密情報（マイナンバーやクレジットカード番号など）が書かれているぞ！ストップ！」とDLP（情報漏洩対策）の目を光らせています。
しかし、ここで一つの大きな壁にぶ2つ当たります。
それが、「WebSocketの永続的コネクション」という壁です。
—
3. WebSocket通信がCASBのリアルタイムインスペクションをすり抜ける理由
先ほど、WebSocketは「一度繋いだら切りっぱなしの直通電話」だと言いました。
通常のHTTP通信であれば、データが流れるたびに封筒の宛先や中身をCASBというお巡りさんが一枚一枚チェックできます。しかし、WebSocketのパイプラインの内部を流れるデータは、いわば「暗号化された密室の中で交わされる高速な会話」のようなものです。
しかも、その中を流れるデータは、人間が読むようなきれいなテキスト形式ではなく、細切れにされたバイナリデータ（0と1の羅列）であることも少なくありません。
CASBが直面する3つの限界
1. 終わりのないストリームの罠:
通常のファイルアップロードなら「ファイルの最初から最後まで」をスキャンして判定できますが、WebSocketはいつ始まり、いつ終わるかわからないダラダラとしたデータの流れです。どこで区切ってスキャンすればいいのか、お巡りさんも判断に迷ってしまいます。
2. パフォーマンスのボトルネック:
もしCASBが、WebSocketのパイプラインを流れるすべてのパケットを無理やり引き剥がして、一文字ずつ厳密にスキャンしようとしたらどうなるでしょう？ そう、ネットワーク全体がものすごく重くなり、ユーザーから「画面がフリーズした！」と悲鳴が上がってしまいます。
3. カプセル化された独自フォーマット:
SaaSベンダーは、自分たちのアプリを高速に動かすために、WebSocketの中に独自のルールでデータを詰め込んで送受信します。お巡りさん（CASB）からすると、「何語で喋っているのか分からない外国の暗号」のように見えてしまうのです。
—
4. 現場でどう立ち向かう？ 実用的な対策とアプローチ
「じゃあ、WebSocketが使われているSaaSでは、情報漏洩もマルウェアもノーチェックになっちゃうの？」
いいえ、そんなことはありません！私たちインフラエンジニアやセキュリティ担当者は、次のような現実的な対策を組み合わせてこの壁を乗り越えています。
対策アプローチの例
- セッションの終端（SSL/TLSインスペクション）の徹底:
まずは通信の暗号化（HTTPS/WSS）をネットワーク機器（プロキシやセキュアWebゲートウェイ）で一度終端し、中身を可視化する基本を徹底します。
- CASBの「API連携（Out-of-Band）」の併用:
リアルタイム（リアルタイムインスペクション）でパケットを監視するのが難しいなら、SaaSの公式APIとCASBを裏で結びつけ、「クラウド上に保存されたデータや、やり取りされた履歴を定期的に巡回してスキャンする」というアプローチをとります。これならリアルタイム性は少し落ちますが、確実なDLPが可能です。
- アプリケーション層でのポリシー制御:
特定の危険なSaaSや、業務に関係のないWebSocket通信そのものをファイアウォールやSWG（Secure Web Gateway）でスパッと遮断することも、立派なゼロトラスト戦略の一つです。
ここで、実務でよく使われるプロキシやCASB連携のイメージとして、設定ファイルやポリシーの考え方を少し覗いてみましょう。
# 仮想的なCASB / SWGのセキュリティポリシー設定例
# WebSocket通信を含むSaaSトラフィックに対する制御イメージ
security_policy:
name: "websocket-saas-inspection-policy"
target_protocols:
- "http"
- "https"
- "wss" # WebSocketセキュア通信をターゲットに含める
actions:
- rule_id: 101
description: "許可された社内認定SaaSのWebSocketはAPI連携による事後スキャンを適用"
app_category: "Approved_Collaboration_Tools"
inspection_type: "api_based_oob" # Out-of-Band（帯域外）スキャン
action: "allow"
- rule_id: 102
description: "未承認のシャドーIT（WebSocket利用アプリ）は通信をブロック"
app_category: "Shadow_IT"
inspection_type: "realtime_proxy"
action: "block" # リアルタイムインスペクションの限界を補うため、通信自体を遮断このように、すべての通信をリアルタイムで監視しようとするのではなく、「リアルタイムで止められるもの」と「APIで後から監視するもの（あるいはそもそも使わせないもの）」を賢く使い分けるのが、現代のセキュリティ運用の鉄則なのです。
—
5. おわりに：技術の進化と共に歩むセキュリティ
今回は、WebSocketを使ったSaaS通信と、CASBのリアルタイムインスペクションの限界、そしてその対策についてお話ししました。
新しい技術（WebSocketのような高速なリアルタイム通信）が登場すると、それを守るセキュリティの仕組み（CASBのリアルタイムDLP）との間で、どうしてもイタチごっこやジレンマが生まれます。しかし、その裏にある仕組み（「直通電話」と「お巡りさん」の関係）を少し噛み砕いて理解するだけで、目の前のトラブルシューティングや設計の引き出しがグッと広がったはずです。
完璧な防御壁なんて存在しない「ゼロトラスト」の世界だからこそ、技術の特性を正しく知り、複数の手段を組み合わせる知恵が求められます。
これからも一緒に、一歩ずつ楽しくインフラとセキュリティの技術を深めていきましょう！
それでは、また次回の技術コラムでお会いしましょう！
コメント