会社のPCから個人のクラウドストレージに資料を上げたら、どうやって止めるのか。生成AIに顧客情報を貼り付けたら、誰が気付けるのか。業務で毎日クラウドサービス(SaaS)を使うようになり、こうした心配はファイアウォールの設定だけでは片付かなくなりました。
この記事では、その役割を受け持つCASB(キャスビー、Cloud Access Security Broker)を、企業でよくある5つの場面から入って説明します。そのうえで、CASBがクラウドアプリをどう評価しているのか、通信のどこに入り込んで制御しているのかを、構成図とシーケンス図で順番に見ていきます。
- CASBとは何か、URLフィルタやファイアウォールと何が違うのか
- 企業でよくある5つの場面で、CASBが何をするのか
- クラウドアプリを評価する仕組み(リスクスコア)
- CASBが間に入る4つの方式と、シーケンスで見る動き
- 導入でつまずきやすい点
この記事は、Microsoft、Zscaler、Netskope、Palo Alto Networks などが公開しているドキュメントを参考にしながら、CASBに共通する考え方を一般化してまとめたものです。特定の製品の機能や動作を説明するものではなく、記事の内容がそのまま各製品に当てはまることを保証するものでもありません。
使える機能や動作、必要なライセンスは、製品やバージョン、契約によって異なります。導入や設計の際は、必ず各メーカーや販売代理店に確認してください。
CASBを一言でいうと
CASBは、社員とクラウドサービスの間に立って、会社のセキュリティルールを当てはめる仕組みです。調査会社のGartnerが2012年に定義した言葉で、クラウドの利用者と提供者の間に置く「セキュリティポリシーを実施するポイント」と説明されています。
空港の保安検査場にたとえるとイメージしやすくなります。行き先(どのサービスか)だけでなく、誰が、どの端末から、何を持って、何をしに行くのかを見て、通してよいかを決めます。行き先が同じサービスでも、持ち物や目的によって通したり止めたりできるのがCASBです。
URLフィルタやファイアウォールでは何が足りないのか
URLフィルタは、Webサイトを「ギャンブル」「ショッピング」「オンラインストレージ」のようなカテゴリに分け、業務に関係のないカテゴリを禁止する使い方が一般的です。判断の単位はサイトで、問いは「そのサイトに行ってよいか」です。ファイアウォールも、主に「どこへ通信するか」で許可と拒否を決めます。
CASBの問いは、そこから一歩奥に入ります。オンラインストレージのように業務で使うサービスは、URLフィルタでは「許可」にするしかありません。許可したサービスの中で、誰が、どのテナント(契約)に、何をしているのかを見える化し、操作ごとに許可・禁止を決めるのがCASBです。同じドメインの上に、自社のテナントも、取引先のテナントも、社員が個人で作ったアカウントも載っているので、サイト単位の判断ではこの区別ができません。
| 知りたいこと | URLフィルタ・ファイアウォール | CASB |
|---|---|---|
| 判断の単位 | サイトやカテゴリ(ギャンブル、ショッピングなど) | クラウドアプリと、その中の操作 |
| どのサービスか | ドメインやURLのカテゴリで判断できる | 数万種類のSaaSを識別し、安全性の評価も付けて判断する |
| 会社の契約か、個人か | ドメインが同じなので見分けにくい | ログイン時の情報などから、テナントを見分ける |
| 何をしたか | アクセスしたことは分かるが、閲覧・アップロード・共有の区別は苦手 | 閲覧、アップロード、ダウンロード、共有などの操作ごとに制御する |
| データの中身 | 見ていない | DLP(情報漏えい対策)で、機密情報が含まれるかを検査する |
| 社外からの利用 | 会社のネットワークを通らない通信は見えない | 個人のPCからの利用や、SaaSに保存済みのデータも対象にできる |
どちらが優れているという話ではなく、守る階層が違います。最近はURLフィルタとCASBをひとつのクラウドサービスとしてまとめて提供することも多く、両方を組み合わせて使うのが普通です。
CASBが通信の中身(操作の種類やファイル)を見るには、HTTPSの通信をいったん復号する必要があります。そのため、端末にはCASBが発行する証明書を信頼させておきます。証明書の仕組みは 【初心者】公開鍵暗号、認証局、デジタル署名をイメージで解説 で説明しています。
プロキシ経由のHTTPSがどのように流れ、復号するとTLSがどう変わるのかは、【図解】CONNECTメソッドとは?プロキシ経由のHTTPS通信の流れを初心者向けに解説 で説明しています。
CASBの歩み
2012年に定義された当初のCASBは、社員が会社に無断で使っているクラウド(シャドーIT)を見つけることが主な役割でした。その後、データの持ち出しを止めたり、SaaSに保存されたファイルを調べたりと、機能が広がっていきます。
今はCASBを単体の製品として買うより、Webアクセスを守るSWG(Secure Web Gateway)、社内システムへのアクセスを守るZTNA(Zero Trust Network Access)と一緒に、クラウドのサービスとして提供されることが多くなっています。この組み合わせはSSE(Security Service Edge)と呼ばれ、ネットワーク側の機能まで含めたものがSASE(Secure Access Service Edge)です。
5つの場面でCASBをイメージする
CASBが何をするのかは、具体的な場面で見るのがいちばん早いです。ここでは、企業でよく話題になる5つの場面を取り上げます。CASBが入り込む場所(会社のPC、個人のPC、SaaSに保存されたデータ)ごとに並べると、図4のようになります。
それぞれの場面の最後に「使う仕組み」をまとめています。そこで「SEQ 1」のように番号を書いたものは、記事の後半「シーケンスで見るCASBの動き」で、通信の流れを詳しく説明しています。
生成AIへの機密情報の貼り付けを止める
開発者がエラーの原因を調べるためにソースコードを、営業が表の整形を頼むために顧客リストを、生成AIのチャットに貼り付けてしまう。今、多くの企業がいちばん気にしている場面です。
- 会社のPCには専用のエージェントなどが入っていて、通信は常にCASBを通ります。
- 生成AIへ送るプロンプトや添付ファイルを、CASBがDLPで検査します。クレジットカード番号のような決まった形の番号、社外秘を示すキーワード、事前に登録した顧客データとの一致などを探します。
- 機密情報が見つかれば、その送信だけを止め、止めた理由を画面に表示します。
- 違反の記録を管理者に送ります。
生成AIそのものを禁止するのではなく、「会社が契約したワークスペースでの利用は許可し、個人アカウントへのログインは止める」という分け方もできます。
フォワードプロキシ+DLP。通信の詳しい流れは、後半の SEQ 1(フォワードプロキシで送信の中身を検査する) で説明します。会社と個人のアカウントを分ける仕組みは SEQ 2 です。
個人のPCからは「見るだけ」にする
在宅勤務の社員や業務委託先が、自分のPCから会社のSaaS(Microsoft 365 など)を使いたい。ブラウザで見たり編集したりはさせたいけれど、ファイルが個人のPCに残るのは困る、という場面です。
- サインインのときに、IdP(ID基盤)が端末を調べます。会社が管理していない端末だと分かると、通信をCASB経由に切り替えます。
- ブラウザでの閲覧や編集は、そのまま使えます。
- ダウンロードは止めるか、暗号化などの保護をかけたうえで許可します。印刷やコピー&ペーストも制御の対象になります。
この方式で制御できるのはブラウザでの利用です。デスクトップアプリからの接続は対象外になるため、IdPの側で「管理外の端末からはブラウザ以外を許可しない」といった設定を組み合わせます。
リバースプロキシ+IdPの条件付きアクセス。通信の詳しい流れは、後半の SEQ 3(リバースプロキシで個人のPCのダウンロードを止める) で説明します。
退職予定者の大量持ち出しに気付き、止める
転職が決まった営業担当が、深夜に顧客管理システムから大量のデータを書き出し、個人のクラウドストレージにアップロードしようとする。内部不正としてよく挙げられる場面です。
- 行動分析(UEBA:User and Entity Behavior Analytics)が、普段と比べてダウンロードの量が急に増えたことを「いつもと違う動き」として検知し、そのユーザーの危険度を引き上げます。
- 個人のストレージへのアップロードは、通信の途中で止めます。CASBは同じストレージサービスでも会社の契約と個人の契約を見分けられるので、「個人側へのアップロードだけ禁止」にできます。
- セキュリティ監視の担当者(SOC)にアラートを送ります。
ここでは「気付く」と「止める」が別の仕組みで動いている点がポイントです。行動分析は普段の行動を覚える学習期間が必要で、SaaSから集めたログを使う検知には時間差もあります。その場で止めるのは、通信の途中にいるフォワードプロキシの役目です。
行動分析(UEBA)+フォワードプロキシ。会社と個人の契約を見分ける仕組みは、後半の SEQ 2(テナント制限で会社と個人のアカウントを分ける) で説明します。
未承認サービスを止めて、会社のツールへ案内する
大きな設計データを取引先に送るため、会社が認めていない無料のファイル転送サービスを使おうとする。シャドーITの典型的な場面です。
- CASBが持つアプリの評価(カタログ)で、そのサービスが「未承認」や「高リスク」に分類されていると判断します。
- アップロードを止め、代わりに使うべき会社のツール(会社契約のストレージの外部共有機能など)を画面で案内します。
- 業務上の理由を入力すれば続けられるようにし、その理由を記録しておく使い方もあります。
行き止まりのブロック画面だけを出すと、社員は別の抜け道を探しがちです。理由を説明して正しいツールへ誘導する「ユーザーコーチング」を組み合わせると、現場の反発を抑えながらシャドーITを減らせます。
アプリの評価(リスクスコア)+フォワードプロキシ+ユーザーコーチング。アプリの評価は、この後の「クラウドアプリをどう評価しているのか」で説明します。通信の流れは SEQ 1 と同じで、判断の材料がDLPの結果ではなくアプリの評価になります。
公開リンクの放置を見つけて直す
クラウドストレージで共有リンクを作るとき、誤って「リンクを知っている全員」にしてしまう。リンクが外に出れば、社外の誰でも資料を開ける状態です。
- CASBがSaaSとAPIで連携し、保存されているファイルの共有設定と中身を調べます。
- 「公開リンクで共有されている」かつ「機密情報を含む」ファイルを見つけます。
- 公開リンクを削除する、社内限定に変える、隔離するといった修正を、APIを使って自動で行います。
- ファイルの所有者に、設定を直したことを知らせます。
この場面では、通信の途中にCASBはいません。社員がSaaSを社外から直接操作していても調べられる一方、共有した瞬間に止めることはできず、見つけて直すまでに時間差があります。
API連携。通信の詳しい流れは、後半の SEQ 4(API連携で公開リンクを直す) で説明します。
CASBの4つの機能(4つの柱)
5つの場面で出てきた機能を整理すると、CASBの説明でよく使われる「4つの柱」になります。GartnerがCASBの機能をこの4つで示したとして、各社の解説で紹介されています。
| 柱 | 何をするか | 上の場面 |
|---|---|---|
| 可視化(Visibility) | 社員がどのクラウドを、どれくらい使っているかを洗い出す。シャドーITを見つける | CASE 4 |
| データ保護(Data Security) | DLPで機密情報の送信や共有を止める。公開リンクを直す | CASE 1、2、5 |
| 脅威対策(Threat Protection) | いつもと違う操作やアカウントの乗っ取りを検知する。マルウェアを含むファイルを見つける | CASE 3 |
| コンプライアンス(Compliance) | 規制や社内ルールに合った使い方になっているかを確かめ、記録を残す | CASE 4、5 |
最近は、SaaSの設定ミス(多要素認証が必須になっていない、外部共有の既定値が広すぎる、など)を点検するSSPM(SaaS Security Posture Management)も、CASBと一緒に提供されることが増えています。
クラウドアプリをどう評価しているのか
CASBは、世の中の数万種類のSaaSを調べたカタログを持っています。社員の通信やログに出てきたサービスをこのカタログと照らし合わせることで、「何が使われていて、それは安心して使えるのか、リスクがあるのか」が分かります。
どんな項目で評価しているのか
評価の項目は、だいたい次の4つのグループに分けられます。項目ごとの評価に重みを付けてまとめ、そのアプリがどのくらい安心して使えるかをリスクスコアという数字で表します。
| グループ | 主な項目の例 |
|---|---|
| 一般 | 運営会社、設立年、利用の多さ、データセンターの場所(データの保管場所) |
| セキュリティ | 多要素認証(MFA)への対応、通信と保存データの暗号化、管理者やユーザーの監査ログ、過去の情報漏えい、既知の脆弱性 |
| コンプライアンス | ISO/IEC 27001、SOC 2、PCI DSS などの認証・基準への準拠 |
| 法務・プライバシー | 利用規約の内容、データの保持期間、利用者のプライバシー保護 |
スコアをポリシーにつなげる
スコアはあくまで判断材料です。最終的には、管理者がアプリに「許可」「監視(条件付きで許可)」「禁止」といったタグを付け、それをポリシーの条件に使います。たとえば「禁止タグのストレージにはアップロードさせず、会社のストレージを案内する」「リスクの高い生成AIでは、プロンプトを記録する」といった書き方です。
なお、カタログに載っていないサービスは、そのままでは識別できません。社内向けに作ったサービスなどは、管理者が独自のアプリとして登録しておきます。
CASBはどこに入り込むのか(4つの方式)
CASBが社員とクラウドの間に入る方法は、大きく4つあります。どれか1つで全部を守ることはできないので、守りたい場所に合わせて組み合わせます。図11は、4つの方式をひとつの会社の中に並べた全体像です。
フォワードプロキシとリバースプロキシの違いが分からない場合は、先に 【図解】フォワードプロキシとリバースプロキシの違いとは?企業の構成例で初心者向けに解説 を読むと、この先が分かりやすくなります。
CASBそのものはクラウドのサービスとして動いていて、利用者はそこへ通信を送るか、IdPに振り向けられて入ります。管理者は管理画面でポリシーを設定し、検知した内容はアラートやログとして管理者や監視担当に届きます。ここからは、4つの方式を1つずつ見ていきます。
① フォワードプロキシ:会社のPCの通信をすべて通す
会社のPCから出るWeb通信を、すべてCASB経由にします。在宅やモバイルのPCには通信を転送するエージェントを入れ、本社や拠点はルータからGRE/IPsecのトンネルでまとめてCASBへ送ります。ブラウザのプロキシ設定(PACファイル)で向ける方法もあります。PACファイルを自動で配る仕組みは 【図解】WPADとは?DHCP・DNSでプロキシ設定を自動で配る仕組みを初心者向けに解説 で説明しています。
CASBはTLSを復号してアプリと操作を識別し、DLPで中身を調べ、ポリシーで判断してからSaaSへ中継します。承認済みかどうかに関係なく、どのサービスへの通信でもその場で止められるのが強みです。一方で、エージェントや証明書を入れられない、会社が管理していない端末は対象にできません。
② リバースプロキシ:サインインのときに経由させる
個人のPCのように、エージェントを入れられない端末に使います。利用者がSaaSにサインインすると、IdPが端末の状態を調べ、管理外の端末であればCASBのURLへリダイレクトします。以降の通信はCASBが中継し、画面の中のリンクもCASB経由のURLに書き換えます。
利用者から見ると、ブラウザのアドレス欄にSaaSのURLの後ろにCASBのドメインが付いた形で表示されるのが目印です。対象はIdPと連携させた承認済みのSaaSで、ブラウザからの利用に限られます。
③ API連携:SaaSの中を後から調べる
SaaSが提供する管理用のAPIを使って、保存されているファイル、共有設定、操作ログを調べます。最初に管理者がSaaSの管理者アカウントでCASBからのAPI接続を許可しておくと、あとはCASBが変更の通知や定期的なスキャンでSaaSの中を確認します。
通信の途中にいないので、社外の取引先が使った場合でも、過去に保存されたデータでも調べられます。ただし、その場で止めることはできず、検知や修正までに数時間かかることもあります。
④ ログ分析:ファイアウォールやプロキシのログを読む
社内のファイアウォールやプロキシの通信ログを、ログコレクター(ログを集める社内のサーバ)を経由してCASBに送り、どのクラウドが、誰に、どれくらい使われているかを洗い出します。結果は、利用中のクラウドの一覧とリスクの評価を並べたレポートとして管理者に届きます。
導入の手始めとして、シャドーITの実態をつかむのに向いています。ログを読むだけなので、これ単体では通信を止めません。
4つの方式の比較
| 方式 | その場で止める | 得意なこと | 苦手なこと |
|---|---|---|---|
| ① フォワードプロキシ | できる | 会社のPCからの、承認済み・未承認を問わないSaaS利用 | 管理外の端末。復号できない通信 |
| ② リバースプロキシ | できる | 個人のPCや協力会社のPCからの、承認済みSaaSの利用 | デスクトップアプリ。未承認のSaaS。SaaS側の画面の変更で動かなくなることがある |
| ③ API連携 | できない(後から修正) | 保存済みのデータ、共有設定、社外からの直接利用 | アップロードや共有の瞬間を止めること。APIを持たないSaaS |
| ④ ログ分析 | できない(見える化) | 組織全体のシャドーITの洗い出し | 通信を止めること。操作の中身 |
個人のPC向けには、リバースプロキシの代わりに、ブラウザ自体でダウンロードやコピーを制御する方法も増えています。画面だけを端末に送る「ブラウザ分離」や、会社が配る「エンタープライズブラウザ」などです。目的は同じで、管理外の端末にデータを残さないことです。
シーケンスで見るCASBの動き
前半の5つの場面で「使う仕組み」に「SEQ 1」などと書いたものを、ここでシーケンス図にして詳しく追いかけます。誰と誰がやり取りし、CASBがどこで判断しているのかに注目してください。
| シーケンス | 内容 | 対応する場面 |
|---|---|---|
| SEQ 1 | フォワードプロキシで、送信の中身を検査する | CASE 1(CASE 4も同じ流れ) |
| SEQ 2 | テナント制限で、会社と個人のアカウントを分ける | CASE 1、CASE 3 |
| SEQ 3 | リバースプロキシで、個人のPCのダウンロードを止める | CASE 2 |
| SEQ 4 | API連携で、公開リンクを直す | CASE 5 |
フォワードプロキシで、送信の中身を検査する
CASE 1(生成AIへの機密情報の貼り付け)の詳しい流れです。会社のPCの通信は、最初からCASBを通るようになっています。
CASBはTLSを復号してプロンプトを取り出し、DLPで調べます。機密情報があれば送信はそこで止まり、生成AIのサービスには届きません。問題がなければ、社員は普段どおり使えます。CASE 4の未承認サービスも同じ流れで、判断の材料がアプリの評価に変わるだけです。
テナント制限で、会社と個人のアカウントを分ける
CASE 1とCASE 3で出てきた「会社の契約と個人の契約を見分ける」仕組みです。ドメインが同じでも分けられるのは、ログインのときに仕掛けがあるからです。
CASBは、ログイン画面への通信に「このテナントだけ許可する」という情報をHTTPヘッダーとして付け足します。SaaSの側がそのヘッダーを見て、自社以外のテナントへのログインを断ります。たとえば Microsoft 365 では、Restrict-Access-To-Tenants などのヘッダーが決められています。CASBとSaaSが協力して実現する仕組みなので、SaaSの側が対応していることが前提です。
リバースプロキシで、個人のPCのダウンロードを止める
CASE 2(個人のPCからは見るだけ)の詳しい流れです。IdPとCASBが連携して、管理外の端末からの通信だけをCASB経由に切り替えます。
ポイントは、リダイレクトでCASBのURLに入ったあと、CASBが画面の中のリンクも書き換えていることです。これにより、画面の中でクリックした先も、CASBを通り続けます。IdPでのリダイレクトにはSAMLなどのシングルサインオンの仕組みが使われます。SAMLの流れは 【SAML】シングルサインオン(SSO)の動作概要 を参照してください。
API連携で、公開リンクを直す
CASE 5(公開リンクの放置)の詳しい流れです。CASBは通信の途中ではなく、SaaSの外から調べています。
SaaSからの変更通知を受けて調べるほか、定期的な全体スキャンで過去のファイルも確認します。見つけたら、管理者が設定した内容に沿って、APIで共有設定を変えたり、ファイルを隔離したりします。
導入でつまずきやすいポイント
| ポイント | 起きること | 対策の例 |
|---|---|---|
| TLSの復号 | 端末が証明書を信頼していないと警告が出る。証明書を固定しているアプリや相互TLSの通信は復号できない | 証明書をMDMなどで配る。復号できない通信は除外し、API連携で補う |
| プライバシー | 通信の中身を見ることへの社内の抵抗 | 社内規程と周知をそろえる。金融や医療など私的なサイトは復号から外す |
| いきなりブロック | 業務が止まり、別の抜け道が使われる | ログ分析で現状をつかみ、警告(コーチング)から始めて、ブロックへ進める |
| APIの時間差 | アップロードや共有の瞬間は止められない | 止めたい操作はフォワードプロキシやリバースプロキシで制御する |
| デスクトップアプリ | リバースプロキシはブラウザしか制御できない | 管理外の端末からは、IdPでブラウザ以外の接続を許可しない |
まとめ
CASBは、URLフィルタのように「そのサイトに入ってよいか」を決めるのではなく、許可したクラウドの中で「誰が・どの端末で・どのテナントに・何を・どんなデータを」を見て制御する仕組みです。会社のPC、個人のPC、SaaSに保存されたデータで入り方が違うので、守りたい場所に合わせて方式を組み合わせます。
| 守りたい場所 | 方式 | できること(場面) |
|---|---|---|
| 会社のPC | フォワードプロキシ | 生成AIへの機密情報の送信を止める(CASE 1)、個人ストレージへの持ち出しを止める(CASE 3)、未承認サービスから会社のツールへ案内する(CASE 4) |
| 個人のPC・協力会社のPC | リバースプロキシ(ブラウザ分離など) | 見るだけ許可し、ダウンロードを止める(CASE 2) |
| SaaSに保存されたデータ | API連携 | 公開リンクを見つけて直す(CASE 5)、いつもと違う操作に気付く(CASE 3) |
| 組織全体 | ログ分析 | シャドーITを洗い出す(導入の手始め) |
設計を考えるときは、「この場面はどの方式で守るのか」「その方式で守れない部分はどこか」を表にしてみると、必要な機能が見えてきます。製品ごとに使える機能や制御できる範囲は異なるため、具体的な製品の選定や設計は、メーカーや販売代理店に確認しながら進めてください。
コメント