CASBとは？主な機能・仕組みと導入が必要な企業をわかりやすく解説

CASBとは、企業のクラウドサービス利用を可視化し、機密情報の共有やアクセスなどをルールに沿って監視・制御するセキュリティの仕組みです。

Microsoft 365やGoogle Workspaceなどの利用が広がると、「誰が、どのサービスに、どのデータを保存・共有しているか」を把握しにくくなります。CASBは、こうしたクラウド管理の抜け漏れに対応する選択肢です。

ただし、すべての企業に新しいCASB製品が必要とは限りません。既存のセキュリティ機能で対応できる場合もあり、まずは自社で見えていないリスクと、現在の対策で不足している部分を確認することが重要です。

この記事では、CASBの意味や機能、プロキシ・ID基盤との違い、自社に導入が必要かを判断するポイントまで解説します。

CASBとは？クラウド利用の「見える化」と「制御」を担う仕組み

CASBは「Cloud Access Security Broker」の略称で、日本語ではクラウドアクセスセキュリティブローカーと呼ばれます。

企業ユーザーによるクラウドサービスの利用に対し、セキュリティポリシーを適用する役割を担います。Microsoftも、CASBをクラウドのリソースやアプリケーションへのアクセスポリシーを適用し、可視性やデータ制御などを提供するセキュリティソリューションとして説明しています。 microsoft.com

情シス担当者の視点では、次のような疑問に答えるための仕組みと考えるとわかりやすいでしょう。

• 社内でどのクラウドサービスが使われているか

• 機密ファイルが社外に共有されていないか

• 私物端末から重要データをダウンロードできる状態になっていないか

• アカウントが侵害され、不審な操作が行われていないか

  
  CASBは、利用状況を記録するだけでなく、必要に応じて共有や操作を制限する点が特徴です。

なお、必ずしもすべての通信を中継するわけではありません。クラウドサービスのAPIと連携し、保存済みのファイルや共有状態を確認する方式もあります。対応範囲は製品や対象サービスによって異なります。

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

クラウドサービスは、現場部門が短期間で導入でき、社外からも利用できます。業務効率を高める一方、従来のネットワーク管理やアカウント台帳だけでは利用実態を把握しきれない場面が増えます。

特に注意したいのが、次の3つの管理課題です。

1. 未承認のクラウドサービスが増える
   営業部門が顧客管理サービスを契約したり、開発部門がファイル転送サービスを利用したりすると、情シスが把握していないサービスに業務データが保存されることがあります。

こうした未承認のIT利用は「シャドーIT」と呼ばれます。

問題は、未承認であることだけではありません。保存されている情報、管理者、退職時の処理、ログの有無がわからず、事故対応が難しくなることもリスクです。

CASBの可視化機能は、対応するログなどをもとに、クラウドサービスの利用状況を把握する助けになります。

2. 承認済みSaaSでも共有や権限に抜け漏れが生じる
   会社で承認したサービスであっても、安全な状態が続くとは限りません。

• 契約書の共有リンクが公開されたままになっている

• 委託先との共同作業が終わってもアクセス権が残っている

• 必要以上の権限を持つ外部連携アプリが承認されている

• 機密ファイルが個人アカウントへ転送されている

  
  「承認済みサービスだから安全」と「安全に利用できている」は別の問題です。

CASBは、対応するサービスの共有状態や操作を確認し、ポリシー違反の検知・是正を支援します。

3. 社外・私物端末からの利用を管理しにくい
   リモートワークや外部委託が広がると、社給PC以外からクラウドにアクセスする機会も増えます。

正規のアカウントでログインできても、その端末にデータを保存してよいとは限りません。

CASBは、ID基盤や端末管理などと組み合わせることで、「閲覧は許可するが、未管理端末へのダウンロードは制限する」といった制御を支援できます。

CASBの主な機能

CASBの代表的な機能は、可視化、データ保護、脅威対策、コンプライアンス支援です。ただし、利用できる機能や制御の細かさは製品によって異なります。

DLPは「Data Loss Prevention」の略で、機密情報の漏えいを防ぐための仕組みです。

なお、SaaSの設定不備や権限を継続的に評価する機能は、SSPM（SaaS Security Posture Management）として提供される場合もあります。CASBにすべての設定監査機能が含まれるとは限らないため、製品ごとの確認が必要です。

比較する際は、機能数よりも「自社で解決したい課題に対応できるか」を優先しましょう。

CASBの代表的な連携・制御方式には、API型とプロキシ型があります。加えて、ログを分析してクラウド利用を可視化する機能も重要です。

API型は、対応するクラウドサービスと連携し、すでに保存されているファイルや共有状態などを確認します。

通信経路に入らずに確認できる点が利点です。一方、すべての操作をその場で止められるわけではありません。APIの提供範囲、権限、検査頻度を確認する必要があります。

プロキシ型は、対象となるクラウドへの通信を中継し、アクセスやデータの送受信を検査します。

方式には、端末側の通信経路などを設定するフォワードプロキシと、認証連携などを利用して対象サービスへのアクセスを中継するリバースプロキシがあります。

製品・構成によっては、未管理端末からのダウンロード制限などに対応できます。ただし、ブラウザと専用アプリで対応が異なる場合があるため、実際の業務環境で検証しましょう。

プロキシやファイアウォールなどのログを分析し、どのクラウドサービスが使われているかを調べます。

初期の棚卸しに向いていますが、取得できる情報には限界があります。たとえば、DNSログだけでは、サービス内で誰がどのファイルを共有したかまでは通常わかりません。

「サービスの利用を把握できること」と「内部の操作まで確認できること」は分けて評価しましょう。

CASBは、既存のセキュリティ対策をすべて置き換えるものではありません。それぞれの役割を分けて考えることが重要です。

ゼロトラストは、ネットワークの内側にいることなどを理由に暗黙の信頼を置かず、リソースへのアクセスを評価する考え方です。NIST SP 800-207でも、ネットワーク上の位置だけでなく、ユーザーや資産、リソースを中心とした防御が示されています。 csrc.nist.gov

CASBは、その考え方をクラウド利用の可視化やデータ保護の面から支える仕組みの一つです。CASBを導入しただけで、ゼロトラストが完成するわけではありません。

CASBを検討するときは、製品比較より先に、自社の管理状況を確認しましょう。

以下の項目で「わからない」「確認できていない」があれば、可視化や管理方法を見直すきっかけになります。

• 部門が契約・利用している主要SaaSを把握している

• 機密情報が保存されているサービスと管理者がわかる

• 外部共有リンクや委託先の権限を定期的に確認している

• 退職・異動時にアカウントと共有権限を見直している

• 私物端末からの閲覧・ダウンロードにルールがある

• 生成AIサービスへの業務データ入力を管理している

• 不審な操作を確認できるログと対応担当者がいる

• 既存製品で対応できる範囲と、対応できない範囲がわかる

未確認項目があるからといって、直ちにCASBの購入が必要になるわけではありません。

まずは、設定変更や既存機能で改善できることを整理します。そのうえで、可視化や制御が不足する領域についてCASBを検討するのが合理的です。

生成AIサービスについても、サービスの検出、入力内容の検査、操作の制御は別の機能です。利用するサービスやブラウザ、専用アプリへの対応を個別に確認してください。

CASB導入を進める4つのステップ

最初からすべてのクラウドサービスを対象にすると、設定と運用の負荷が大きくなります。

まずは、利用者が多いサービスや、個人情報・契約書・設計資料などを扱うサービスから着手しましょう。

「機密情報」という抽象的な表現ではなく、具体的なデータの種類まで決めると、検知ルールを設計しやすくなります。

現在のSaaS契約やセキュリティ製品に、必要な機能が含まれている場合もあります。

以下を確認し、不足する部分を整理してください。

• SaaS標準の監査・共有管理機能

• IdPの認証・アクセス制御

• 端末管理の対象範囲

• SWGやDLPの対応機能

• ログの保存期間と確認方法

  ステップ3：監視から始め、段階的に制御する

  
  最初から一律にブロックすると、正当な業務まで止めるおそれがあります。

「監視のみ」「通知」「高リスク操作の制限」の順に進め、誤検知や業務影響を確認しましょう。

外部共有が必要な業務では、例外申請の承認者と有効期限も決めておくことが重要です。

アラートが届いても、確認する人が決まっていなければ改善につながりません。

• 誰が一次確認するか

• どの条件で共有を停止するか

• 利用部門へどう連絡するか

• どの情報を事故対応用に保存するか

  
  導入効果は、検知件数だけでなく、是正にかかった時間や未対応の高リスク事象、誤検知による業務影響なども含めて評価しましょう。

CASBに関するよくある質問

なくなるとは限りません。検出範囲は取得できるログや連携方式に左右されます。

また、現場が未承認サービスを使う理由を解消しなければ、別のサービスへ移る可能性もあります。承認済みサービスの整備や、利用申請のしやすさも重要です。

既存製品で必要な管理・制御ができていれば、追加導入が不要な場合もあります。

ただし、Web通信を確認できても、SaaSに保存済みのファイルや共有状態までは確認できないことがあります。製品名ではなく、実際の対応範囲で判断しましょう。

一律には管理できません。API連携の可否や、対応する操作、対象アプリなどによって管理範囲が変わります。

特にAPI型は、対象サービスとの連携が前提です。導入前に、管理したいサービスと操作が対応範囲に含まれるかを確認してください。

製品、利用人数、契約プラン、必要な機能、導入支援や運用支援の範囲などで変わります。

ライセンス費用だけでなく、初期設定、検証、アラート確認、ルールの見直しにかかる工数も含めて比較することが重要です。

まとめ｜CASBの検討は、クラウド管理の現状把握から

CASBは、企業のクラウド利用を可視化し、データ共有やアクセスなどをルールに沿って監視・制御する仕組みです。

導入を検討する際は、次の3点から整理しましょう。

1. どのサービスで、何を把握できていないか

2. 既存の機能で、どこまで対応できるか

3. 不足する対策を、誰が運用するか

   
   重要なのは、CASBを購入することではなく、クラウド上のリスクを把握し、必要な対策を継続できる状態にすることです。

「外部共有の状態がわからない」「既存の対策で十分か判断できない」「CASBが必要なのか、まず整理したい」――このような課題はありませんか。

製品選定の前に現状を確認することで、設定の見直しで対応すべきことと、追加対策を検討すべきことを分けやすくなります。

InfiniCore株式会社のセキュリティ診断について、まずはご相談ください。
診断の対象範囲や進め方をご確認のうえ、自社の課題に合うかをご検討いただけます。