こんにちは！ネットワークセキュリティの世界へようこそ。凄腕のネットワークセキュリティスペシャリストとして、日夜国内外のサイバー脅威と戦っている私ですが、今回は「SASE（Secure Access Service Edge）」と「CASB（Cloud Access Security Broker）」、その中でも特に熱い注目を集めている「インライン方式のトラフィックインターセプション」について、徹底的に分かりやすく解説していきます。
「インライン方式？ リバースプロキシ？ 何だか難しそう……」と思ったそこのあなた、安心してください！今回は小難しいパケットの構造や暗号の数式は一旦脇に置いて、私たちの身近にある「郵便配達の仕組み」に例えながら、一歩ずつ優しく紐解いていきましょう。
さあ、コーヒー片手に、安全なクラウド時代のセキュリティの旅に出発です！
—
1. そもそもCASB（キャスブ）って何をするもの？
私たちが普段何気なく使っているMicrosoft 365、Google Workspace、Slack、あるいは個人のDropboxなどなど……。今や仕事のデータは会社の中にあるパソコンの中だけでなく、雲の上の「クラウド」に広がっていますよね。
ここでセキュリティ担当者が頭を悩ませるのが、こんな疑問です。
- 「社員が会社のデータを勝手に個人のクラウドに保存していないか？」
- 「海外の怪しいWi-Fiから、マルウェアに感染した端末で社給クラウドにログインしていないか？」
- 「クレジットカード番号や機密情報がチャットに書き込まれていないか？」
こうした「クラウドサービスの利用状況を可視化し、コントロールし、守る」ためのセキュリティの門番が、CASB（Cloud Access Security Broker）というわけです。
そして、そのCASBがユーザーとクラウドの間にどうやって入り込む（インターセプトする）かという方式の一つが、今回主役となる「インライン方式」なのです。
—
2. 身近な例えで理解する「インライン方式」の正体
「インライン（Inline）」という言葉は、直訳すると「直列」「途中の経路上」という意味になります。
これがどれくらいリアルな挙動なのか、「郵便配達」に例えてみましょう。
従来の「野放し」な通信（ダイレクト）
あなたが友人（クラウド）に手紙（データ）を出したいとき、これまではポストに直接投函していました。中身に何が書かれていようと、郵便局員がその場で検閲することはありませんよね。とてもスピーディーですが、もし手紙に「家の合鍵」が書いてあって、それが間違った宛先に届いたら……大惨事です。
インライン方式のCASB（セキュリティチェックポイント付きの国際郵便局）
インライン方式を導入すると、あなたがクラウドへ送る手紙（HTTPリクエスト）は、必ず途中にいる「厳格なセキュリティチェック官（CASB）」の机の上を通過するよう強制されます。
チェック官は、手紙の封をあけて（※正確にはSSL/TLS復号を行います）、
1. 「おっと、この宛先のクラウドサービスは、うちの会社では禁止されているブラックリストのものだよ！」（アクセス制御）
2. 「ちょっと待って、この手紙の本文に『顧客のクレジットカード番号』が書かれているぞ！」（DLP：データ損失防止）
3. 「端末のセキュリティ状態がボロボロじゃないか。このままでは通せない！」（コンテキストベースの制御）
といったチェックを、一瞬のうちに行います。問題がなければそのままクラウドへ送り、問題があればその場で「ストップ！」をかける。これがインライン方式のリアルな姿です。
—
3. インライン方式の2つのアプローチ：「リバースプロキシ」と「フォワードプロキシ」
CASBが通信の途中に割り込む（インターセプトする）方法には、大きく分けて「リバースプロキシ（Reverse Proxy）」と「フォワードプロキシ（Forward Proxy）」の2つが存在します。
それぞれの特徴を、現場のエンジニア目線で分かりやすく見ていきましょう。
① リバースプロキシ方式（社外からクラウドへの入り口をガード）
- どんな仕組み？
ユーザーがMicrosoft 365などにアクセスする際、DNS（名前解決）の向き先をCASBのサーバーに書き換えておきます。ユーザーは「クラウドにアクセスしているつもりが、実は手前のCASBに話しかけている」状態になります。
- 得意なこと・利用シーン
主に「マネージド（会社が管理している）なクラウドサービスへのアクセス制御」や、社員が個人の端末（BYOD）から会社のメールを見に行くようなシナリオで絶大な威力を発揮します。
- 弱点
世の中に無数にあるすべてのクラウドサービスに対してリバースプロキシの門番を立てることはできないため、カバー範囲が特定の主要アプリに絞られがちです。
② フォワードプロキシ方式（社内・エッジからのすべての出口をガード）
- どんな仕組み？
ユーザーのPCやスマートフォンのブラウザ（あるいはSASEのクライアントソフト）にあらかじめ「すべての通信はまずこのCASBプロキシを経由しなさい」と設定しておきます。ユーザーがどこに行くにしても、通信は必ずCASBを通ります。
- 得意なこと・利用シーン
社員が会社のPCから業務に関係ない怪しいクラウドストレージにアクセスしたり、シャドーIT（会社に無断で使われているクラウド）を使おうとしたりするのを「一網打尽」にするのに向いています。
- 弱点
社外に持ち出したノートPCの場合、専用のVPNやSASEエージェント（ZscalerやCloudflare WARPなど）が常時動いていないと、フォワードプロキシ経由の通信経路を作れないという課題があります。
—
4. 実務で役立つ設定・イメージの覗き見
「理屈はわかったけれど、実際の現場ではどんな設定をするの？」という声にお応えして、ここではイメージしやすいように、一般的なSASE/CASB環境におけるルーティングやプロキシ設定の雰囲気を感じ取ってみましょう。
例えば、クラウドプロキシ（フォワードプロキシ型CASB）を利用する際の、クライアント端末（Pacファイルや設定スクリプト）のイメージは以下のようになります。
// 【サンプル】ブラウザにプロキシ経路を指示する PACファイル（Proxy Auto-Configuration）の例
function FindProxyForURL(url, host) {
// 社内ネットワークや特定の安全なドメイン以外への通信は、すべてCASBのプロキシへ流す
if (shExpMatch(host, "*.microsoftonline.com") ||
shExpMatch(host, "*.salesforce.com") ||
shExpMatch(host, "*.dropbox.com")) {
// CASB（セキュアWebゲートウェイ）のプロキシサーバーへ転送
return "PROXY casb-gateway.enterprise-security.local:10443";
}
// 上記以外の一般的なWeb閲覧はダイレクト、または通常の社内プロキシへ
return "DIRECT";
}> エンジニアの現場メモ：
> 最近のモダンなSASE環境では、ブラウザのPACファイルに頼るだけでなく、端末に常駐する軽量なエージェント（クライアントソフト）が、OSのネットワーク層（レイヤー3/4）でパケットをキャプチャし、自動的にCASBのクラウド基盤へトンネリングする方式が主流になっています。ユーザーはプロキシの存在すら意識する必要がありません。
—
5. インライン方式における「最大の壁」と現実的な対策
ここまで聞くと「インライン方式のCASBを導入すれば、セキュリティは完璧だ！」と思えるかもしれませんが、現場のインフラエンジニアとして避けて通れない「リアルな壁」が存在します。それが「SSL/TLSの可視化（復号化）」です。
現代のインターネット通信は、ほとんどがHTTPS（暗号化）されています。暗号化されているということは、CASBの門番から見ても「中は真っ黒なダンボール箱」にしか見えず、中にクレジットカード番号やマルウェアが入っていても中身が見えません。
これを解決するために、インライン方式のCASBでは「SSLインスペクション（復号・再暗号化）」という処理を行います。
[ユーザー端末]
↓ (HTTPS通信：暗号化)
[CASBプロキシ] ← ここで一旦「パカッ」と中身を開けてDLP検査やマルウェアスキャンを実施！
↓ (新しい証明書で再度暗号化して転送)
[クラウドサービス]ここで問題になるのが、
- 「プライバシー侵害の懸念」（個人のプライベートな通信や銀行口座のパスワードまで見えてしまわないか？）
- 「証明書エラーの壁」（会社のオレオレ証明書を端末に信頼させないと、ブラウザが「警告：安全ではありません」と叫び出す）
といった実務上の調整です。そのため、CASBを導入する際は、人事部門や法務部門、そしてエンドユーザーを巻き込んで「どのトラフィックを検査し、どのトラフィック（例えば個人の医療系サイトやネットバンキングなど）はプライバシー配慮のために検査から除外（SSLバイパス）するか」というポリシーのチューニングが極めて重要になってきます。
—
6. まとめ：一歩ずつ、確実なゼロトラストの土台へ
今回は、インライン方式のCASBトラフィックインターセプションについて、郵便配達の例えや現場のリアルな課題を交えながら解説してきました。最後に、今日の重要なポイントを振り返ってみましょう。
- CASBのインライン方式は、ユーザーとクラウドの通信経路上に立ちふさがり、リアルタイムでアクセス制御やデータ流出防止（DLP）を行う強力な門番である。
- 方式には、特定のアプリの入り口をガードする「リバースプロキシ」と、すべての出口を網羅的に見張る「フォワードプロキシ（SASE連携）」がある。
- 暗号化通信を検査するためには、SSLインスペクション（復号）の仕組みと、プライバシー配慮のポリシー設計が不可欠である。
「すべてを信用せず、常に検証する」というゼロトラストの思想において、通信の途中にしっかりとセキュリティの目を光らせるインライン方式のCASBは、これからの企業ネットワークの心臓部となります。
難しい用語に圧倒されそうになったときは、いつでも「手紙の検閲と郵便局」の仕組みを思い出してください。一歩ずつ着実に知識を重ねていけば、あなたも立派なセキュリティ・アーキテクトです。
それでは、また次回の技術解説でお会いしましょう！安全なネットワークライフを！
コメント