CASBとは何かクラウド管理をわかりやすく整理

• CASBとは、Cloud Access Security Broker の略で、企業ユーザーとクラウドサービスの間でセキュリティポリシーを適用する仕組みです。
• 情報システム担当者にとっての主な価値は、SaaS利用の可視化、シャドーITの把握、データ保護、脅威検知、利用制御をクラウド横断で整理できることです。
• CASBは単独製品として導入する場合もあれば、SSE、SASE、EDR、ID基盤、DLP、SIEMなどの一部機能として提供される場合もあります。
• 導入判断では、「何を止めたいか」より先に、「どのクラウド利用を見える化し、どのリスクに優先順位を付けるか」を決めることが重要です。
• この記事は、NIST、Microsoft、Cloud Security Alliance などの一次情報を確認し、情報システム担当者が導入前に整理すべき観点に絞ってまとめています。

はじめに

「CASBとは何か」を調べる情報システム担当者の多くは、単なる用語の意味ではなく、自社のクラウド管理に必要なのか、既存のプロキシやID基盤と何が違うのか、どこから始めればよいのかを知りたいはずです。特に Microsoft 365、Google Workspace、Box、Salesforce、Slack、GitHub、生成AI系SaaSなどが部門ごとに増えると、従来の境界型ネットワークだけでは利用実態を追い切れません。

クラウドは便利ですが、利用部門が直接契約しやすく、端末も社給PC、私物端末、モバイル、外部委託先などに広がります。結果として、管理者が知らないSaaS、退職者が共有したままのファイル、外部共有リンク、個人アカウントへのアップロード、過剰権限のOAuthアプリなどが残りやすくなります。CASBは、このような「クラウド利用の見えにくさ」を減らし、方針に沿って監視・制御するための考え方と製品領域です。

ただし、CASBを入れればクラウドリスクが自動的に消えるわけではありません。CASBは、ID管理、端末管理、DLP、ログ監視、インシデント対応、利用ルールと組み合わせて初めて意味を持ちます。本記事では、CASBとは何かをわかりやすく整理しつつ、情報システム担当者が導入前に確認すべき実務上の判断軸を示します。

CASBとは何か

CASBは、クラウドサービスを使う企業ユーザーとクラウドサービス提供者の間で、利用状況を見える化し、セキュリティポリシーを適用する仕組みです。MicrosoftはCASBを次のように説明しています。

security policy enforcement point positioned between enterprise users and cloud service providers.

"セキュリティポリシーの適用ポイントは、企業ユーザーとクラウドサービスプロバイダーの間に配置される。"

出典: Microsoft, What is a cloud access security broker (CASB)?

この一文のポイントは、「監視ツール」だけではなく「ポリシーを適用する場所」だという点です。CASBはログを集めるだけでなく、危険なSaaSを検出する、機密情報を含むファイル共有を制限する、未管理端末からのダウンロードを止める、不審な操作を検知してアラートを出す、といった制御に関わります。

NISTの用語集にも cloud access security broker はCASBとして掲載され、関連出典として NIST SP 800-215 が示されています。Source: NIST CSRC Glossary。
NIST SP 800-145では、クラウドコンピューティングを、ネットワーク、サーバー、ストレージ、アプリケーション、サービスなどの共有リソースへオンデマンドにアクセスできるモデルとして説明しています。Source: NIST SP 800-145。

CASBは、このクラウド利用が増えた結果、企業側の統制をどこで効かせるかという課題から生まれた領域だと理解すると自然です。

情報システム担当者向けに言い換えるなら、CASBは「クラウド版の見える化・制御レイヤー」です。ファイアウォールが社内外の通信を見ていたように、CASBはSaaSやクラウドアプリの利用、ファイル、ユーザー行動、端末状態、外部共有などを見て、会社のルールに沿って対応します。ただし、通信経路に必ず入る製品だけを指すわけではなく、API連携でSaaS上の設定やファイル状態を確認するタイプもあります。

なぜクラウド管理でCASBが必要になるのか

CASBが必要になる背景は、クラウド利用の「速さ」と「分散」です。NIST SP 800-145が示すクラウドの特徴には、オンデマンドのセルフサービス、広範なネットワークアクセス、リソースプール、迅速な拡張、計測可能なサービスが含まれます。これらはビジネスには利点ですが、管理者から見ると、利用開始が速く、利用場所が広く、設定変更も頻繁で、従来の台帳管理だけでは追いつきにくいという意味でもあります。

たとえば、営業部門が名刺管理SaaSを契約し、開発部門がリポジトリ管理サービスを使い、マーケティング部門が生成AIや分析SaaSにデータを入れる状況を考えます。各サービスが便利でも、情報システム部門が利用実態、管理者、外部共有、退職者アカウント、API連携、ログ保存期間を把握していなければ、監査や事故対応で困ります。

CASBが担う典型的な課題は次の4つです。

• 可視化: どのSaaSが、誰に、どの端末から、どれくらい使われているかを把握する。
• データ保護: 機密情報を含むファイルの外部共有、ダウンロード、アップロードを検知・制御する。
• 脅威対策: 不審なログイン、通常と異なる大量ダウンロード、不正OAuthアプリ、マルウェアを検知する。
• コンプライアンス支援: 利用サービスのリスク、監査証跡、ポリシー違反を整理する。

ここで大事なのは、CASBを「禁止するための道具」とだけ見ないことです。クラウド活用を止めるのではなく、安全に使える範囲を明確にするための管理基盤として扱う方が、現場との摩擦を減らせます。情報システム担当者は、利用部門の業務を理解したうえで、禁止、許可、条件付き許可、監視のみを使い分ける必要があります。

CASBの主な機能を表で整理

CASBの機能は製品によって異なりますが、導入前の整理では「どのリスクに効くのか」で見ると判断しやすくなります。以下の表は、情報システム担当者が比較検討で使いやすい代表的な観点です。

この表で最初に見るべきなのは、機能数ではなく「自社の優先課題」との一致です。たとえば、部門契約SaaSが多い企業ではシャドーIT可視化が先です。機密ファイルの外部共有が課題ならDLPとSaaS設定監査が先です。侵害アカウントの早期検知が課題なら、UEBA、IdP、SIEM連携が重要になります。

CASBの動き方: API型、プロキシ型、ログ分析型

CASBの実装方式は大きく分けると、API型、プロキシ型、ログ分析型があります。実際の製品は複数方式を組み合わせることが多く、方式ごとに得意・不得意があります。

API型は、Microsoft 365、Google Workspace、Box、SalesforceなどのSaaS APIへ接続し、ファイル共有、権限、設定、イベントログを確認します。既にSaaS上に存在するデータや設定を後から検査しやすいのが利点です。一方、リアルタイムに通信を止める用途では、APIの提供範囲や反映タイミングに左右されます。

プロキシ型は、ユーザーとクラウドサービスの通信経路に入り、アクセスや操作をその場で制御します。未管理端末からのダウンロード禁止、特定操作のブロック、アップロード時の検査などに向きます。ただし、経路設計、証明書、対象アプリ、ユーザー体験、モバイル対応、例外処理を丁寧に設計しないと、業務影響が出ます。

ログ分析型は、プロキシ、ファイアウォール、DNS、IdP、EDRなどのログからクラウド利用を見つけます。初期の可視化やシャドーIT把握に向いていますが、検出後の制御は別の仕組みと組み合わせる必要があります。

情報システム担当者は、「全通信をCASBに通すべきか」ではなく、「対象SaaSごとに、どの方式で、どの操作を見て、どこまで止めるか」を決めるべきです。たとえば、Microsoft 365はAPI型で既存ファイルと共有設定を確認し、未承認SaaSはログ分析でリスクを棚卸しし、高リスク操作だけプロキシ型で制御する、という段階的な構成が現実的です。

CASBとSWG、SASE、ゼロトラストの違い

CASBは、SWGやSASE、ゼロトラストと混同されやすい用語です。SWGは主にWebアクセスを保護する仕組みで、悪性サイト、URLフィルタリング、マルウェア検査、Web通信制御などに強みがあります。CASBは、SaaSやクラウドアプリの利用状況、データ、設定、ユーザー操作に焦点を当てます。重なる部分はありますが、同じものではありません。

SASEは、ネットワーク接続とセキュリティ機能をクラウド提供型で統合する考え方です。CASB、SWG、ZTNA、FWaaS、DLPなどがSASEやSSEの一部機能として提供されることがあります。そのため、近年は「CASB製品を単独で買うか」よりも、「自社のSASE/SSE構想の中でCASB機能をどう使うか」という検討になりやすくなっています。

ゼロトラストとの関係も重要です。NIST SP 800-207は、ゼロトラストを静的なネットワーク境界から、ユーザー、資産、リソースを中心にした防御へ移す考え方として説明しています。Source: NIST SP 800-207。
また、認証と認可は企業リソースへのセッション確立前に実施されるべきだとしています。

NIST SP 800-207Aは、マルチクラウド環境でアプリケーションレベルの細かなポリシーを実現するため、場所ではなくIDに焦点を移すこと、APIゲートウェイやサイドカープロキシなどがポリシーを適用する基盤になり得ることを述べています。Source: NIST SP 800-207A。
CASBはゼロトラストそのものではありませんが、SaaS利用の可視化、条件付きアクセス、データ保護、行動監視を通じて、ゼロトラスト運用を支える部品になります。

導入前に決めるべきこと

CASB導入で失敗しやすいのは、製品比較から始めてしまうケースです。先に決めるべきなのは、対象範囲、優先リスク、既存基盤との役割分担です。

まず、対象クラウドを決めます。全SaaSを最初から完全管理しようとすると、設定、例外、通知、運用負荷が大きくなります。最初は、利用者数が多いSaaS、機密情報が入るSaaS、外部共有が多いSaaS、部門契約が増えているSaaSに絞る方が現実的です。

次に、制御の強さを決めます。いきなりブロックを多用すると、業務部門は回避策を探します。初期は「検出して通知する」「高リスク共有だけ隔離する」「未管理端末では閲覧のみ許可する」など、段階的な制御が適しています。特にDLPは誤検知が業務影響に直結するため、検知ルール、例外申請、承認フロー、ログ確認の担当を明確にしてから強制適用すべきです。

さらに、既存ツールとの境界を決めます。IdPは本人確認と条件付きアクセス、MDM/EDRは端末状態、SWGはWebアクセス、SIEMは相関分析、CASBはクラウドアプリとデータの可視化・制御、と役割を分けると設計しやすくなります。Cloud Security AllianceのSecurity Guidance v5は、クラウドセキュリティをIAM、セキュリティ監視、インフラ、データ、アプリケーション、インシデント対応など複数ドメインで扱っています。Source: CSA Security Guidance v5。
CASBだけを過信せず、クラウド管理全体の一部として位置付けることが必要です。

情報システム担当者向けチェックリスト

CASB検討を始める前に、次の順で確認すると、製品比較が現実的になります。

1. 主要SaaSを棚卸しする。契約部門、管理者、利用者数、機密データ有無、外部共有有無を確認する。
2. 未承認SaaSの検出元を決める。プロキシ、DNS、IdP、EDR、経費精算、SSOログなど、利用実態が取れる場所を洗い出す。
3. 守るデータを定義する。個人情報、営業秘密、設計資料、ソースコード、契約書など、DLP対象を業務用語で整理する。
4. 制御レベルを段階化する。監視のみ、通知、隔離、共有停止、ダウンロード禁止、利用禁止を分ける。
5. 例外申請を設計する。業務上必要な外部共有や委託先利用を止めすぎないよう、承認者と期限を決める。
6. アラート運用を決める。誰が一次確認し、どの条件でセキュリティ担当へエスカレーションするかを決める。
7. 経営・監査向けの説明軸を用意する。利用リスク、是正件数、残リスク、改善計画を報告できる形にする。

このチェックリストは、導入プロジェクトの初期要件として使えます。製品の機能表だけを見ると、どれも多機能に見えます。しかし、自社で運用できるログ、制御、承認、レポートまで落とし込むと、本当に必要な機能が絞られます。

よくある誤解

なくなりません。CASBはシャドーITを見つけ、リスクを評価し、制御する助けになりますが、利用部門がなぜそのSaaSを使うのかを解決しなければ、別の回避策が生まれます。承認済みサービスの選択肢、申請の速さ、利用ルールの分かりやすさも同時に改善する必要があります。

代わりにはなりません。ゼロトラストは、暗黙の信頼を置かず、ユーザー、端末、アプリケーション、データ、リスクに基づいてアクセスを判断する考え方です。CASBは、特にクラウドアプリとデータの領域で、その判断材料と制御点を提供する部品です。

必ずしも不要とは言えません。SWGやプロキシはWeb通信の保護に強い一方、SaaS内部のファイル共有、権限、OAuthアプリ、過去に置かれたデータの検査はAPI型CASBの方が向く場合があります。逆に、CASBだけで悪性サイト対策や全Web通信制御を完結させるのも現実的ではありません。

最初は「可視化」から始めるのが安全です。主要SaaSと未承認SaaSを棚卸しし、機密データが入る場所、外部共有が多い場所、退職者や委託先が関わる場所を見つけます。そのうえで、リスクの高い操作から小さく制御します。いきなり全社ブロックを増やすより、業務影響を測りながら段階的に進める方が定着しやすくなります。

まとめ

CASBとは、クラウド利用を見える化し、企業のセキュリティポリシーをSaaSやクラウドアプリに適用するための仕組みです。情報システム担当者にとっては、クラウド管理の抜け漏れを減らし、部門利用、外部共有、機密データ、未管理端末、異常行動を整理するための実務的なレイヤーだと考えると分かりやすいでしょう。

導入時は、製品名や機能数から入るのではなく、自社のクラウド利用実態、守るべきデータ、既存のID・端末・ログ基盤、運用できる制御レベルから逆算することが重要です。CASBは万能ではありませんが、クラウド利用が広がる企業にとって、見えないリスクを見えるリスクに変え、対応可能な運用へ落とすための有効な選択肢です。

この記事では、CASBの定義、クラウド管理で必要になる理由、機能、実装方式、周辺領域との違い、導入前チェックを一次情報ベースで整理しました。実際の導入では、対象SaaS、規制要件、既存契約、ログ保存、個人情報の扱い、労務・監査要件によって最適解が変わります。必要に応じて、セキュリティ担当、法務、監査、利用部門を含めて要件を固めてください。