CASBとは何か：SaaSの「内側」を可視化・制御するクラウド時代の関所

SWGが「Web通信」を守るのに対し、CASB（Cloud Access Security Broker） はSaaSの“アプリ内部のふるまい”を可視化・制御するためのレイヤです。ユーザーがどのSaaSを使い、どんなデータをどこへ共有し、どの権限を付与しているのか――クラウド前提の働き方では、ここが最大の盲点になります。CASBは、その盲点を埋めるための「信号機」であり「監査カメラ」であり、時に「遮断機」として機能します。

1. CASBの基本機能：発見・可視化・制御・防御・ガバナンス

シャドーITの発見（Discovery）：プロキシ/エージェント/ログ取込で未承認SaaSの利用を棚卸し。リスクスコアやカテゴリ分類で可視化。
アクセス可視化と制御（Visibility & Control）：ユーザー/グループ/端末の属性や場所に応じたポリシー。承認済みSaaSは許可、未承認はブロック/読取専用など。
データ保護（DLP/IRM）：アップロード・共有リンク・外部共有・生成AIへの貼り付けなどを、機密区分やコンテキストで検査。自動マスク/暗号化/ウォーターマーク付与も。
脅威対策（Malware/Account Takeover）：アップロードファイルのサンドボックス解析、OAuthアプリの過剰権限検知、異常なログイン/同時セッション検知。
SSPM（SaaS Security Posture Management）：テナント設定のベンチマーク（公開共有既定値・MFA必須・監査ログ保持など）を継続チェックし是正。

ポイントは「通信の外側だけでなく、SaaSの内側に踏み込む」こと。URL単位の許可・拒否ではなく、“そのSaaSで何をしたか”（例：共有リンクを作った、外部ドメインへ転送した、公開範囲を Anyone にした等）を捉えます。

2. 実装モデル：プロキシ型とAPI型、インラインとアウトオブバンド

CASBは大きく分けて二つの実装があります。

2.1 プロキシ（インライン）型

フォワード/リバース・プロキシ：トラフィックをCASB経由にし、ブラウザ操作をリアルタイムで制御。未管理端末に“閲覧のみ”を強制、アップロード禁止、クリップボード制御など細かい制御が可能。
利点：即時制御・即時ブロックが可能。端末が社外でも効く。
注意：証明書配布やSNI例外、アプリのドメイン追加などの運用設計が要る。レイテンシ設計や復号範囲のプライバシー配慮も必須。

2.2 API（アウトオブバンド）型

事後スキャン：Box/Google Drive/OneDrive/Slack/TeamsなどのAPIでファイル・メッセージ・共有設定を巡回。機密検出→自動隔離、公開リンクの巻き取り、外部共有の強制停止など。
利点：ネットワーク経由でなくても監査可能。モバイルアプリや外部コラボも検知できる。
注意：リアルタイム抑止は弱い。API制限や権限設計、データ保護要件に応じた遅延許容の合意が必要。

実務ではハイブリッドが定石。高リスク操作はインラインで即時制御し、広範な監査・是正はAPIでカバーします。生成AIの投稿制御や“未管理端末の閲覧のみ”はインライン、共有リンクの棚卸しや権限の定期是正はAPI、という棲み分けが分かりやすいです。

3. 具体的なユースケース

未管理端末からのSaaSアクセスを閲覧専用に：ダウンロード禁止、コピー/印刷禁止、画面に透かし、期限付きアクセス。
共有リンクの露出低減：「Anyoneリンク」を自動検出→社内限定へ切替。外部ドメインの共有は取引先ドメインのみ許可。
生成AIへの機密投稿対策：プロンプト内の個人情報・設計図・ソースコードをDLPで検査し、遮断/マスク/承認フロー。
OAuthアプリの過剰権限：「全メールの読み取り」「全Driveアクセス」のような権限を持つサードパーティ連携を棚卸し・強制剥奪。
アカウント乗っ取り検知：異常な地理・短時間の多拠点ログイン・大量DL・外部共有爆増などの挙動相関で検出。

4. 設計と導入のベストプラクティス

資産管理と命名規則：テナント、ドメイン、アカウント、グループ、共有ポリシーを台帳化。SaaS毎に“公開既定値”と“例外フロー”を文書化。
ポリシー階層：全社（最低限DLP/マルウェア）→ 部門（外部共有条件）→ 業務（プロジェクト例外）の3層構造で複雑性を吸収。
トラフィックステアリング：PAC/エージェント/SASE PoP/IdP連携（Conditional Access, SAML, SCIM）を地理と回線で最適化。
プライバシーと法令順守：復号対象・除外対象の明文化。医療/人事データは除外、監査ログは国内保存など。
段階導入：可視化→モニタ→ソフトブロック→ハードブロックの順。影響分析ダッシュボードを用意し、例外は期限付きに。

5. よくある落とし穴と回避策

「SaaSの全部は見えない」問題：一部の機能はAPI未提供。カバレッジ表を作り、SWG・ZTNA・EDR・SSPMと補完設計。
OAuthの権限地獄：取り消してもユーザー再許可で復活。許可ワークフローと禁止スコープ、定期棚卸しを自動化。
遅延アラート疲れ：インラインで即時止めるべき操作（DL/外部共有）はCASB側にルールを寄せ、事後検出は是正自動化まで一体で。
個人アカウント混入：同一SaaSの個人/企業アカウント混在は事故の温床。ドメイン制限・アプリ分離・ブックマーク配布で誤操作を減らす。

6. SWG・ZTNA・DLP・MDM/MTDとの役割分担

SWG：Web通信の入口検査。アプリ単位の到達制御。
CASB：SaaS内の操作制御・データ保護・権限ガバナンス。
ZTNA：社内アプリやSaaSプライベートエンドポイントへのゼロトラスト接続。
DLP：オン/オフラインのデータ流通統制を横断で担う基盤。
MDM/MTD：端末健全性・脅威検知。CASBポリシーに端末コンプライアンスをフィード。

結論として、CASBは「SaaSの内側」を守る中核であり、SASE/SSE全体の要としてデータ中心の設計を実現します。

7. 成功のKPI：動かして測る

未承認SaaS数の推移／承認化率
Anyoneリンク等の“過公開”件数の削減率
高リスクOAuthアプリの駆逐率・再発率
未管理端末の閲覧専用化カバレッジ（ユーザー比）
インシデントMTTD/MTTR（是正自動化による短縮）

「どこまで自動是正できたか」をKPIに含めると、運用負荷の削減が数字で語れるようになります。

8. まとめ：クラウド時代の実務は“データ中心”に

ネットワーク境界の時代は終わり、今はデータが社外・端末外・組織外へと自在に行き来します。CASBは、その動きを「見える化」し「止めるべき時に止め」「後からでも正せる」ための制御塔です。設計の核はシンプルです。どのデータを、誰が、どこで、どう扱ってよいか。この問いにCASBの機能マップを重ね、SWG/ZTNA/DLP/SSPMと役割分担しながら、段階的に完成度を高めていきましょう。