CASB（Cloud Access Security Broker）は、クラウドサービスの利用状況の把握やデータ保護などを担うセキュリティの仕組みです。Microsoftは、未把握のクラウド利用の発見、利用状況の可視化、脅威対策、情報保護などをCASBの基本機能として挙げています。MicrosoftのCASB機能説明
導入を検討するときは、「何が使われているかを知りたい」のか、「特定の操作を止めたい」のかを先に分けることを勧めます。サービス名の一覧を得ることと、機密ファイルのダウンロードを防ぐことでは、確認する連携や試験が異なるためです。
本記事ではMicrosoft Defender for Cloud Appsの公式仕様を具体例に、導入要件の整理方法を示します。製品例の機能を、すべてのCASB製品に共通する仕様として扱わないでください。判断表と導入手順は、公開仕様を踏まえた編集上の提案です。
CASBで見えることと、止められること
利用の可視化：まずクラウドサービスの利用を把握する
Defender for Cloud Appsは、ネットワークトラフィックの評価とアプリのカタログを使って、利用されているアプリを識別します。Cloud discoveryの画面では、アプリの種類、リスク、利用者や送信元IPアドレスなどを確認できます。機能概要、Cloud discoveryの確認項目
ここでの検討課題は、社内で承認されていない利用、いわゆるシャドーITを含め、どの利用を調査対象にするかです。本稿では、発見したサービスについて「利用部門」「業務目的」「扱うデータ」「代替手段」を記録する方法を提案します。リスクの評価だけで利用禁止を決めず、業務上の用途も確認するためです。
API連携：接続したサービスの情報を調べる
Defender for Cloud Appsのアプリコネクターは、クラウドサービス提供者のAPIを使って可視化と制御を行います。取得や処理は接続先APIの制約を受け、一部のポリシー処理には数時間から数日かかる場合があると説明されています。APIコネクターの仕様
そのため、API連携の検証では「必要な情報が取れるか」に加えて「いつ取得・処理されるか」を確認しましょう。APIで検知した後に対処する要件と、利用者の操作中に止める要件を、同じ試験で合格にしないことが大切です。
セッション制御：対象のアクセスや操作に制限をかける
同製品のConditional Access app controlは、IDプロバイダーと連携してブラウザーのセッションを可視化・制御します。公式例には、管理されていない端末からのアクセス制限や、機密ファイルのダウンロード禁止があります。セッション制御の仕様と例
ただし、ブラウザーで制御できたことだけで、専用アプリや同期クライアントも含めて確認済みとはしないでください。同資料は、保護の迂回を防ぐためにネイティブクライアントのアクセスをブロックし、ブラウザーベースのセッションだけを許可する設定を案内しています。どの経路を許可するかも検証項目に含めましょう。
導入目的を決める判断表
次の表は製品の対応表ではなく、要件を整理するための提案です。候補製品の仕様確認と、自社環境での試験に使ってください。
| 解決したい課題 | 検討する機能・連携 | 検証で確認すること |
|---|---|---|
| 未把握のクラウド利用を調べたい | 利用状況の収集・発見 | 対象の端末・接続経路から試したサービスを識別できるか |
| 承認済みSaaS内の活動やファイルを調べたい | 対象SaaSのAPIコネクター | 必要な情報、取得権限、取得から検知までの時間 |
| 管理外端末へのダウンロードを止めたい | ID連携とセッション制御 | 指定条件の端末・利用者・ファイルで操作を止められるか |
| 未承認サービスの利用を禁止したい | 遮断を実行する製品・連携先 | 発見や分類だけでなく、実際の接続が禁止されるか |
「CASBを入れる」という要件だけでは、試験の合格条件を決めにくくなります。例えば「営業部の承認済みSaaSについて、管理外端末からの機密ファイルのダウンロードを制限する」のように、部門・サービス・端末条件・操作を具体化しましょう。
CASB導入を進める4つの手順
1. 対象サービスと接続経路を一覧にする
最初に、守りたいサービスとデータを列挙します。利用者、管理端末と管理外端末、社内と社外、ブラウザーと専用アプリを組み合わせ、今回の試験対象を決めます。
例えばブラウザーだけを試す場合は、専用アプリを「未確認」と記録します。観測や試験の対象にしていない利用を、問題なしと判断しないための整理です。
2. 既存機能と追加が必要な要件を照合する
採用中のSaaS、ID管理、端末管理、通信制御の各担当者に、実現したい条件を渡しましょう。既存契約で利用できる機能と、追加製品や連携が必要な部分を確認します。
比較時は、製品名だけでなく、対象プラン、対応するSaaS、必要権限、ログの保持条件、運用担当を記録することを勧めます。費用や契約条件はここでは断定せず、自社の契約に照らして確認してください。
3. 限定した対象で可視化と制御を試す
はじめに対象部門や検証用アカウントを限定して、必要な情報が得られるかを確認します。その後、制限する操作と許可する操作を対にして試します。以下は試験項目の例です。
- 指定した管理外端末では、対象ファイルのダウンロードが止まる。
- 許可対象の端末では、必要な業務操作を続けられる。
- 専用アプリなど別の接続経路でも、決めた許可・禁止条件を満たす。
- API連携では、試験操作から情報取得・検知までの時間を記録できる。
- 意図しない制限が起きた際に、担当者が設定を戻せる。
遮断できることと、必要な業務を続けられることの両方を合格条件にするのが、本稿の提案です。
4. 検知後の対応と例外の管理を決める
アラートの受け手、業務部門への確認方法、制限を解除する担当者を決めます。例外には理由・承認者・期限・再確認日を付ける運用を勧めます。
導入判断の資料には「確認できた範囲」「未確認の経路」「検知までの時間」「止められなかった操作」を残してください。これらを基に、対象範囲を広げるか、連携や運用を見直すかを判断できます。
CASBの検討では、可視化・API連携・セッション制御ごとに、達成したい条件を一つずつ試すことが出発点になります。自社の利用経路と業務条件を添えた検証表を作り、導入担当と運用担当が同じ合格条件を共有しましょう。