CASB(キャスビー・Cloud Access Security Broker)とは、従業員のクラウド利用を可視化し、 管理外のクラウドサービス（シャドーIT）による情報漏えいリスクを抑えるための仕組みです。 ただしCASBは、導入すれば自動的にシャドーIT対策が完成する製品ではありません。 通信経路の設計や既存プロキシ・ファイアウォールとの共存、ポリシー設計など、 実運用に入るまでに検討すべきことが多くあります。 機能も多岐にわたるため、導入したものの十分に活用しきれていないこともあります。 ここでは、こうした実務上のポイントと、近年のCASBを取り巻く変化を整理します。
シャドーITとは、管理部門の把握なく社内で使われているクラウドサービスやアプリのことです。 従業員によって悪意なく導入されるケースがほとんどですが、把握されないまま利用が広がることで、 情報漏えいや管理不備の温床になりえます。 近年は生成AIサービスを含め、業務部門や従業員が自らSaaSを使い始める場面が増えています。 管理部門が把握しないまま機密情報が入力・共有されれば、 情報漏えいやコンプライアンス上の問題につながりかねません。 CASBは、こうした管理外のクラウド利用を可視化し、必要に応じて制御するために使われます。
無料プランのファイル共有ツールに、社外秘の資料がアップロードされている
例：会社が契約・管理していないファイル転送サービスへの、機密資料のアップロード
退職済み従業員のSaaSアカウントが、解約されずに残り続けている
例：退職した職員による情報漏洩や、パスワードの危殆化による情報流出
個人のクレジットカードで契約したSaaSに、業務データが保存されている
例：個人利用のサービスは管理部門の目が届きにくく、情報漏洩につながりやすい
CASBは2010年代前半、SaaSの普及とシャドーIT対策を背景に登場しました。その後、専業ベンダーの登場や業界再編を経て、現在はCASB単体ではなくSSE/SASEの一機能として提供されるケースが増えています。生成AIの普及も、クラウド利用管理のあり方を大きく変えています。
CASB機能が単体製品としてではなく、SWG・ZTNAなどと合わせたSSE/SASEプラットフォームの 一部として提供されるのが主流になっています。 CASBは通信をどこで可視化・制御するかが重要なため、SWGやZTNAと切り離して考えにくくなっています。 そのため現在は、CASB単体の機能比較だけでなく、 SSE/SASE全体としてのネットワーク設計まで含めて製品を選ぶ必要があります。
ChatGPTをはじめとする生成AIサービスの業務利用が急速に広がり、「入力した情報が どう扱われるか」という新しい種類のシャドーITリスクが生まれています。 生成AIでは、入力した情報がサービス側で保存・処理されるため、 機密情報を意図せず外部サービスへ送信してしまうリスクがあります。 入力データの学習利用や保持条件はサービス・契約プランによって異なるため、 企業側で利用ルールを設けることが重要です。 既存のCASB製品も、AI利用状況の可視化・制御に対応を進めている段階です。
「社内は安全、社外は危険」という境界防御の前提が崩れる中、CASBは ゼロトラストアーキテクチャにおける「クラウド利用の可視化・制御」を担う 要素の一つとして再定義されつつあります。
カタログスペックには書かれない、導入・運用フェーズで実際につまずきやすいポイントです。
通信内容を検査するには一度復号する必要があり、証明書の配布やアプリ側の警告対応が必須になります。 対象を絞らないと、非対応アプリでは通信エラーとなります。
プロキシ型・SASE型では通信がCASBを経由するため、 接続先から見た送信元IPが、利用者本来の回線ではなくCASB側のものになる場合があります。 IP制限をかけている取引先や官公庁システムへのアクセスができなくなることがあります。 対策として、固定IPの利用や、対象通信をプロキシから除外するバイパス設計が必要になる場合があります。
すでに稼働しているプロキシやファイアウォールとの経路の整理・切り分けが必要になります。 全面切替か併用かの判断は、ネットワーク構成によって難易度が大きく変わります。 ローカルブレイクアウトやSD-WANをすでに採用している環境では、 通信経路をどこでCASBへ渡すかも重要な設計ポイントになります。
CASBは未許可SaaSの利用を検知できますが、「なぜ使っているか」「業務上必要か」の判断は 結局、現場へのヒアリングという人力の工程が残ります。
DLP・脅威防御・UEBAなど機能ごとにモジュール課金される製品が多く、 「必要な機能だけ」を積み上げた結果の総額が見積り時点まで見えにくい傾向があります。 また、昨今の円安・インフレによって実装後の契約更新時に大幅な値上げされるケースも多く、 数年単位での長期契約がおすすめです。
CASB製品の多くは、リスク評価の基準が欧米（英語圏）を前提に設計されています。 そのため日本語のみで運営されているサイトやサービスに対しては、 実際のリスクレベルを見誤って判定されることが少なくありません。 したがってある程度は管理者の目で確認する必要が出てきます。
Gartnerが提唱する整理に基づく、クラウド利用管理の基本機能です。
「誰が・どの端末から・どのSaaSを」使っているかを通信ログから自動で棚卸しし、 サービスごとのリスク評価と合わせて一覧化します。 ヒアリングでは追いきれないシャドーITを網羅的に発見でき、 対策の優先順位付けや経営層への報告の裏付けにもなります。
DLP（情報漏えい対策）ポリシーで、機密情報のアップロードや 社外への過剰な共有を検知・ブロックします。 人の注意力に頼らず「うっかり」による漏えいを仕組みで防げるのが利点で、 共有リンクの棚卸しやデータの暗号化にも活用できます。
普段と異なる場所・時間からのログインや大量ダウンロードといった 「振る舞い」を検知し、アカウント乗っ取りやマルウェアの拡散を早期に発見・防御します。 侵害への気づきが早まることで、被害範囲の特定と封じ込めまでの時間を短縮できます。
各SaaSの認証取得状況（ISO 27001 など）や自社ポリシーへの適合を評価し、 違反時の操作ログを監査証跡として残せます。 監査のたびに証跡を人手で集める工数を減らし、 個人情報保護法や業界ガイドラインへの説明責任を果たしやすくなります。
CASBがクラウド通信のどこに介在するかで、大きく3方式に分かれます。
利用者の端末からの通信を一度プロキシに通し、その場でSaaS利用を検査・制御する方式。 エージェントやPAC配布が必要ですが、未許可SaaSのリアルタイム遮断ができます。 現在のSSE製品では広く採用されている方式です。
SaaS側の入口に割り込み、認証と組み合わせて通信を制御する方式。端末側の設定が不要で、 社外端末や私物端末(BYOD)からのアクセス制御に向いています。 対象SaaSや認証方式によって対応可否が異なるため、 すべてのクラウドサービスを同じように制御できるわけではありません。
SaaSが提供するAPIを通じて、保存済みのデータや設定・共有状況を後追いで監査する方式。 通信経路を変更せずに導入しやすい一方、通信中のリアルタイム遮断には向きません。 まずSaaS内部の設定や保存データを可視化・監査したい場合に適しています。
CASBを入れればシャドーITは無くなる
検知・可視化はできますが、利用の是非を判断し是正するのは組織側の運用です。
大手ベンダーならどれも同じ
提供方式や得意領域、国内サポート体制など、実務上の違いは製品ごとにあります。
導入すればすぐ効果が出る
既存ネットワークとの整理、ポリシー設計、運用体制の整備まで含めて初めて機能します。
利用しているSaaSやWebサイトのURL、メールアドレスを入力すると、 公開情報をもとに信頼性を簡易診断できます。
本サイト内の図中に記載されているサービス名・ロゴは各社の商標です。 CASBが仲介する対象の例示であり、各社との提携・代理店契約・認定関係を示すものではありません。 掲載内容は一般に公開されている情報に基づく概要であり、最新の仕様は各社にご確認ください。
casb.jp All rights reserved.
