Microsoft Defender for Cloud Appsの「Get started」で最初にやるべきことは、ライセンス・管理者権限・Microsoft Entra IDアプリの前提条件を確認し、Microsoft Defenderポータルからアプリ接続、DLP、ポリシー、Cloud Discoveryを順に有効化することです。
特に2026年6月2日に更新された関連公式情報では、アプリコネクタのAPI制限、複数インスタンス対応、Filesページ非推奨後の運用、コネクタの無効化・再有効化時の注意点が整理されています。既存CASBから移行する管理者や、Defender for Endpoint、Microsoft 365、Google Workspace、Box、Salesforceなどを接続する運用担当者は、初期設定だけでなく「接続後に何が見えるか」「どのポリシーが効くか」「既存環境と競合しないか」まで確認しておく必要があります。(Microsoft Learn)
Microsoft Defender for Cloud AppsのGet startedで確認すべき全体像
Microsoft Defender for Cloud Appsは、クラウドアプリの利用状況を可視化し、企業データを保護し、必要に応じてアクセスや共有を制御するためのMicrosoft Defender系セキュリティサービスです。公式のGet startedは、Microsoft Defenderポータル上でDefender for Cloud Appsを使い始めるためのクイックスタートとして公開されています。(Microsoft Learn)
実務上は、次の順番で進めると迷いにくくなります。
| 確認項目 | 主な作業 | 失敗しやすいポイント |
|---|---|---|
| 前提条件 | ライセンス、管理者権限、必要なMicrosoft Entra IDアプリを確認 | 権限不足で設定画面が見えない、必要なサービスプリンシパルを無効化してしまう |
| アプリ接続 | Microsoft 365、Google Workspace、Box、SalesforceなどをApp Connectorで接続 | API制限や初回スキャン時間を考慮せず、すぐ全データが見えると誤解する |
| DLP・ファイル監視 | ファイル監視、Microsoft Purview Information Protection連携、File policyを設定 | Filesページ非推奨後も旧画面前提の手順で運用してしまう |
| ポリシー | Activity、File、Session、Access、Cloud Discoveryなどを作成 | 最初から自動隔離や権限削除を本番適用して業務影響を出す |
| Cloud Discovery | Defender for Endpoint、ログコレクター、SWG、APIでクラウド利用を検出 | ネットワーク部門との調整不足でログが継続投入されない |
| 組織設定 | 管理ドメイン、IP範囲、メール通知、リスクスコアを設定 | 内部ユーザーと外部ユーザーの判定がずれ、アラート精度が落ちる |
重要なのは、「接続して終わり」ではなく、接続後に取得されるデータをポリシーへ落とし込み、検出・通知・制御まで運用設計することです。
2026年6月2日更新情報で押さえる実務上の変更点
注意点として、Microsoft Learnで確認できるGet started本体の更新日は2025年7月24日です。一方、Get startedのStep 1に紐づく「Connect apps to get visibility and control」の公式ページは2026年6月2日に更新されています。したがって、今回の確認対象は「Get started全体の導入手順」と「2026年6月2日に更新されたアプリ接続まわりの詳細情報」を合わせて読むのが正確です。(GitHub)
2026年6月2日更新の関連情報で、管理者が特に見るべきポイントは次の通りです。
| ポイント | 内容 | 管理者への影響 |
|---|---|---|
| App ConnectorはAPIベース | 接続先クラウドアプリのAPIを使い、アカウント、アクティビティ、ファイル、権限などを取得する | 接続先アプリのAPI制限、権限、監査ログ保持期間を事前確認する必要がある |
| 一部ポリシーは反映に時間がかかる | テナント全体のファイルスキャンなど、大量APIを使う処理は数時間から数日かかる場合がある | 初回導入直後に「検出されない」と判断せず、スキャン完了まで観察する |
| Filesページは非推奨 | 2024年9月1日からDefender for Cloud AppsのFilesページは非推奨 | ファイル確認や制御はFile policies中心の運用へ寄せる |
| 複数インスタンス対応 | 同じアプリを複数インスタンス接続できる。ただしAPI接続アプリが対象 | Salesforceを部門別に複数接続するような構成では有効。一方、Microsoft 365とAzureは対象外 |
| コネクタ無効化時の注意 | 無効化するとそのコネクタインスタンスからのデータ消費が止まる | 再有効化に備えて接続情報を残し、変更前に運用チームへ通知する |
| ネットワーク要件 | 一部アプリではログ収集やポータルアクセスのためにIPアドレスやURLの許可が必要 | ファイアウォール、プロキシ、SWG管理者との事前調整が必要 |
アプリコネクタはHTTPSで通信し、接続先サービスごとのAPI制限やスロットリングを考慮して動作します。特に大規模テナントでは、初回スキャンの完了やファイルポリシーの反映に時間がかかるため、導入直後の評価期間を短くしすぎないことが重要です。(Microsoft Learn)
影響範囲：すぐ確認すべき管理者・開発者・運用チーム
今回のGet started関連情報は、Defender for Cloud Appsをこれから導入する企業だけでなく、すでにMicrosoft Defenderポータルへ移行済みの組織にも影響します。
Microsoft 365や主要SaaSを接続している管理者
Microsoft 365、Google Workspace、Box、Dropbox、Salesforce、Slack、ServiceNow、GitHubなどを接続している場合、App Connectorごとに取得できるデータや実行できるガバナンスアクションが異なります。たとえば、ユーザー一覧、監査証跡、アプリ権限、ファイルスキャン、データガバナンス、SSPMなどは、すべてのアプリで同じように使えるわけではありません。(Microsoft Learn)
導入時は「接続できるか」だけでなく、次の観点で棚卸ししてください。
- そのアプリで取得できるアクティビティログは何か
- ファイルスキャンやDLPに対応しているか
- 外部共有の削除、ユーザー停止、権限取り消しなどのガバナンスアクションが可能か
- API制限により、全件スキャンにどの程度時間がかかるか
- 本番テナント以外に検証用インスタンスがあるか
特にSalesforceやServiceNowのように部門や用途ごとにインスタンスが分かれている環境では、複数インスタンス対応を使うことで、アプリ単位ではなく事業単位・部門単位でポリシーを分けやすくなります。ただし、この複数インスタンス対応はAPI接続アプリが対象であり、Cloud Discovered appsやProxy connected apps、Microsoft 365、Azureには適用されません。(Microsoft Learn)
Defender for Endpointを使っている端末管理者
Cloud Discoveryを広く展開する場合、Defender for Endpointとの統合は重要です。Microsoftの公式情報では、Defender for Endpointとの統合により、エンドポイントのログを使ってShadow ITの検出やデバイス単位の調査を進められると説明されています。対象にはWindows 10、Windows 11のほか、条件を満たすmacOSデバイスも含まれます。(Microsoft Learn)
設定場所は、Microsoft Defenderポータルの Settings > Endpoints > General > Advanced features です。ここでMicrosoft Defender for Cloud Apps連携をオンにすると、最大で約2時間後にDefender for Cloud Apps側へデータが表示される場合があります。すぐに見えないからといって再設定を繰り返すのではなく、反映待ちの時間を運用手順に入れておくべきです。(Microsoft Learn)
API連携や自動化を行う開発者
開発者やSecOps担当者がDefender for Cloud Apps APIを使う場合は、従来型のAPIトークン運用だけを前提にせず、Microsoft Entraアプリケーションを使ったOAuth 2.0認証を前提に設計するのが安全です。公式情報では、Defender for Cloud Apps APIにアクセスするにはMicrosoft Entraアプリを作成し、アクセストークンを取得してAPIへアクセスする流れが示されています。(Microsoft Learn)
バックグラウンドサービスやバッチ処理では、ユーザーのサインインを前提にしないApplication contextが推奨されています。必要な権限は、Read Alerts、Upload Discovery Report、Investigation.Read、Discovery.manage、Settings.manageなど、呼び出すAPIに応じて最小限に絞るべきです。(Microsoft Learn)
実務では、次の3点を必ず確認してください。
- アプリ登録時に必要なAPI権限だけを付与しているか
- 権限追加後に管理者同意を実施しているか
- クライアントシークレットをソースコードやCIログに残していないか
初期設定で確認すべき前提条件
Defender for Cloud Appsの初期設定では、最低限、Microsoft Entra IDまたはMicrosoft 365のSecurity Administrator権限が必要です。また、Defender for Cloud Appsは複数のMicrosoft Entra IDアプリケーションに依存して動作するため、関連するファーストパーティアプリを無効化しないことが明記されています。(Microsoft Learn)
確認すべき代表的なアプリケーションは次の通りです。
| Microsoft Entra IDアプリ | 役割の考え方 |
|---|---|
| Microsoft Defender for Cloud Apps – APIs | APIコネクタや外部連携の基盤 |
| Microsoft Defender for Cloud Apps – Customer Experience | ポータル体験やサービス機能の一部 |
| Microsoft Defender for Cloud Apps – Information Protection | 情報保護機能との連携 |
| Microsoft Defender for Cloud Apps – MIP Server | Microsoft Purview Information Protection関連 |
| Microsoft Defender for Cloud Apps – Data Loss Prevention – SPO | SharePoint OnlineなどのDLP関連 |
セキュリティ強化のつもりで不要そうなエンタープライズアプリを一括無効化している環境では、この確認が特に重要です。該当アプリを止めると、アプリ接続、情報保護、DLP、ファイル監視などに影響する可能性があります。
管理者が取るべき展開手順
Defender for Cloud Appsは、次の順番で展開すると手戻りを減らせます。
ライセンスとアクセス権を確認する
まず、保護対象ユーザーにDefender for Cloud Appsのライセンスがあるかを確認します。Microsoft 365 E5試用版の一部として試用できる場合もありますが、実際にどのユーザー・どのサービスを保護対象にするかは、契約内容に依存します。公式のGet startedでは、Microsoft DefenderポータルのCloud AppsからDefender for Cloud Appsにアクセスする流れが示されています。(Microsoft Learn)
権限は、Global Administratorを常用しないことが基本です。基本設定の公式情報でも、十分な範囲で最小権限を使い、Security AdministratorまたはCloud App Administratorを優先し、Global Administratorが必要な場合はPrivileged Identity Managementによる一時的な昇格を検討する考え方が示されています。(Microsoft Learn)
組織情報と管理ドメインを設定する
次に、Settings > Cloud Apps > System > Organization details で組織名、環境名、管理ドメインを設定します。管理ドメインは、内部ユーザーと外部ユーザーの判定、ファイル共有の判定、レポート、アラートに影響します。公式情報でも、管理ドメインの追加は内部・外部ユーザーやファイル共有の判定に使われる重要なステップとされています。(Microsoft Learn)
ここを後回しにすると、外部共有の検出やDLPポリシーの精度が落ちます。たとえば、グループ会社や子会社のドメインを内部扱いにするのか、外部扱いにするのかを決めずにポリシーを作ると、アラートが多すぎる、または本来検出すべき共有を見落とす原因になります。
App Connectorを接続する
アプリ接続は、Defender for Cloud Apps運用の入口です。Microsoft Defenderポータルで Settings > Cloud Apps > Connected apps > App Connectors に進み、接続するアプリを選択します。接続後は、アクティビティ、ファイル、アカウント、権限などを調査できるようになります。(Microsoft Learn)
ただし、初回接続時はすぐにすべてのデータが揃うとは限りません。アプリコネクタはユーザー一覧、アクティビティ、ファイルなどを段階的・定期的にスキャンします。テナント規模、ユーザー数、ファイル数により完了までの時間が変わります。(Microsoft Learn)
導入直後は、次のような観察期間を設けるとよいでしょう。
| 期間 | 確認内容 |
|---|---|
| 接続直後 | コネクタ状態がConnectedになっているか、認証エラーがないか |
| 数時間後 | アクティビティログ、ユーザー、アカウント情報が増えているか |
| 数日後 | ファイルスキャン、DLP、ポリシー一致件数が想定どおりか |
| 1〜2週間後 | 誤検知、アラート量、業務影響をレビューする |
DLPとFile policyを設計する
DLPを有効化する場合は、まずファイル監視を有効化し、必要に応じてMicrosoft Purview Information Protectionとの連携を確認します。公式Get startedでは、Microsoft 365ファイルの監視を有効にするには、Application AdministratorやCloud Application Administratorなど、関連するEntra管理者権限が必要とされています。(Microsoft Learn)
File policyでは、公開共有ファイル、外部共有された機密ファイル、特定拡張子のファイル、個人情報を含むファイル、未分類ファイルのアップロードなどを検出できます。公式情報では、File policyはクラウドプロバイダーのAPIを使って継続的なコンプライアンススキャン、eDiscovery、DLPなどを実行でき、20以上のメタデータフィルターや100種類以上の一般的なファイル形式のコンテンツ検査に対応すると説明されています。(Microsoft Learn)
本番展開では、最初から自動削除や権限剥奪を有効にするのは避けたほうが安全です。まずは「検出のみ」「メール通知のみ」で数日から数週間運用し、誤検知が少ない条件へ絞り込んでからガバナンスアクションを追加します。
ポリシーはリスクカテゴリごとに作成する
Defender for Cloud Appsのポリシーには、Activity policy、Anomaly detection policy、OAuth app policy、Malware detection policy、File policy、Access policy、Session policy、App discovery policyなどがあります。公式情報では、ポリシーはクラウド上の危険な行動、違反、不審なデータやアクティビティを検出し、必要に応じて修復ワークフローへつなげるものと説明されています。(Microsoft Learn)
実務では、以下のように目的別に分けると運用しやすくなります。
| 目的 | 使うポリシー例 | 具体例 |
|---|---|---|
| シャドーIT検出 | App discovery policy | 新しい生成AIサービスや未承認ストレージの利用を通知 |
| 情報漏えい対策 | File policy、Session policy | 外部共有された機密ファイルを検出、未分類ファイルのアップロードをブロック |
| 不審操作の検出 | Activity policy、Anomaly detection policy | 大量ダウンロード、通常と異なる国からの管理操作を通知 |
| OAuthリスク対策 | OAuth app policy | 高権限OAuthアプリや過剰権限アプリを確認 |
| リアルタイム制御 | Access policy、Session policy | 管理対象外端末からのダウンロード制御、外部ユーザーの読み取り専用化 |
ポリシー作成時は、テンプレートをそのまま本番適用するのではなく、自社のIP範囲、管理ドメイン、部門、例外ユーザー、対象アプリを反映して調整します。フィルター条件が広すぎるとアラート疲れを起こし、狭すぎると重要なリスクを見落とします。
Cloud Discoveryを継続運用にする
Cloud Discoveryは、組織内で使われているクラウドアプリやShadow ITを把握するための機能です。公式情報では、Defender for Cloud Appsのクラウドアプリカタログに対してトラフィックログを分析し、31,000以上のクラウドアプリを90以上のリスク要因で評価するとされています。(Microsoft Learn)
レポートには、手動アップロードによるSnapshot reportと、継続的にログを取り込むContinuous reportがあります。継続運用では、Defender for Endpoint連携、ログコレクター、Secure Web Gateway連携、Cloud Discovery APIなどを使えます。(Microsoft Learn)
特に注意すべきなのは、Cloud Discoveryはセキュリティ部門だけでは完結しない点です。Firewall、Proxy、SWG、Defender for Endpoint、ネットワークチーム、端末管理チームが関わります。ログ形式、送信経路、許可リスト、プロキシ除外、ネットワーク負荷を事前に確認しておきましょう。
移行時の注意点：既存CASBと並行運用してから切り替える
既存のCASB製品を使っている場合、いきなりDefender for Cloud Appsへ全面移行するのはおすすめできません。公式Get startedでも、機密情報保護やCloud Discoveryは、現在利用中のCASBと並行して使い始め、段階的にポリシーを移行する考え方が示されています。APIコネクタはアウトオブバンド接続のため、既存CASBと競合しにくいとされています。(Microsoft Learn)
移行の現実的な進め方は次の通りです。
| フェーズ | 作業 | 判断基準 |
|---|---|---|
| 評価 | Microsoft 365や主要SaaSを接続し、可視化できる範囲を確認 | 既存CASBと検出件数・対象アプリに大きな差がないか |
| 並行運用 | DLP、外部共有、Shadow IT検出を通知のみで運用 | 誤検知率、アラート量、SOC対応工数が許容範囲か |
| 部分移行 | 特定部門・特定アプリからガバナンスアクションを有効化 | 業務影響が発生してもロールバックできるか |
| 本格移行 | 既存CASBの重複ポリシーを整理し、Defender側を標準運用にする | 監査証跡、レポート、インシデント対応手順が整備済みか |
移行時に見落としやすいのは、ポリシー名や条件式ではなく、例外設定と通知先です。旧CASBで「役員」「監査部門」「開発環境」「外部委託先」などを例外扱いしていた場合、同じ考え方をDefender for Cloud Appsのユーザーグループ、IPタグ、管理ドメイン、ポリシーフィルターに落とし込む必要があります。
展開前に確認したいネットワークと権限のチェックリスト
Defender for Cloud Appsの導入では、セキュリティ設定だけでなくネットワーク要件も重要です。公式のネットワーク要件では、MicrosoftCloudAppSecurityやAzureFrontDoor.MicrosoftSecurityのサービス タグ、ポータルアクセス、アクセス制御、セッション制御に必要なURLやIP範囲が整理されています。最新のIP範囲はAzureサービス タグで確認することが推奨されています。(Microsoft Learn)
展開前に、次の項目を確認してください。
| チェック項目 | 確認内容 |
|---|---|
| ポータルアクセス | 管理者端末からMicrosoft DefenderポータルとCloud Apps設定画面へアクセスできるか |
| ファイアウォール | 必要なアウトバウンド443通信、URL、サービス タグを許可しているか |
| セッション制御 | Conditional Access App Controlを使う場合、プロキシやブラウザ制御の影響を検証したか |
| App Connector | 接続先SaaS側で必要な管理者権限、API利用、監査ログ設定が有効か |
| Defender for Endpoint | 対象デバイスがオンボード済みか、Advanced featuresでCloud Apps連携をオンにしたか |
| 管理ドメイン | 自社、子会社、関連会社、委託先を内部扱いにするか外部扱いにするか決めたか |
| 通知先 | SOC、情報システム、各SaaS管理者、法務・監査部門への通知ルートを決めたか |
| ロールバック | 自動ガバナンスアクションを止める手順、ポリシー無効化手順を用意したか |
よくある失敗と回避策
接続したのにデータが見えない
初回接続後、ユーザー、アクティビティ、ファイルの取得には時間がかかる場合があります。大規模テナントやファイル数が多い環境では、数時間から数日単位で見るべきです。接続状態、API権限、対象アプリの監査ログ設定、ネットワーク許可を順に確認しましょう。
ポリシーの誤検知が多すぎる
最初から全ユーザー・全アプリ・全ファイルに広い条件をかけると、アラートが大量に発生します。まずは重要部門、機密ラベル付きファイル、外部共有、管理者操作、未承認アプリなど、リスクが高い対象から始めるのが現実的です。
自動アクションで業務影響が出る
ファイルの外部共有削除、ユーザー停止、トークン取り消し、隔離などは強力ですが、誤適用時の影響も大きくなります。本番では、検出のみ、通知のみ、少数ユーザーでのテスト、自動アクション有効化の順に段階展開してください。
旧ポータル前提の運用手順が残っている
Defender for Cloud AppsはMicrosoft Defenderポータルへ統合が進んでいます。公式リリースノートでは、クラシックポータルからMicrosoft Defenderポータルへの自動リダイレクトが案内され、2024年6月16日以降はクラシックポータル利用者がMicrosoft Defenderポータルへ自動的にリダイレクトされるとされています。(Microsoft Learn)
運用手順書や社内Wikiに古い画面名、旧URL、Filesページ前提の手順が残っていないか確認しましょう。
管理者が今日やるべき確認作業
Microsoft Defender for Cloud AppsのGet startedは、単なる初期設定手順ではなく、クラウドアプリの可視化、DLP、ポリシー制御、Cloud Discovery、既存CASBからの移行を始めるための実務チェックリストとして使えます。
まずは次の順番で確認してください。
- Microsoft DefenderポータルでCloud Appsにアクセスできるか確認する
- Security AdministratorまたはCloud App Administratorなど、必要最小限の管理者権限を割り当てる
- 必要なMicrosoft Entra IDアプリが無効化されていないか確認する
- 主要SaaSをApp Connectorで接続し、取得できるデータとAPI制限を確認する
- 管理ドメイン、IP範囲、メール通知、リスクスコアを設定する
- File policyとCloud Discoveryを通知のみで開始し、誤検知を調整する
- 既存CASBや既存DLPと並行運用し、段階的にポリシーを移行する
- API連携を行う場合は、Microsoft EntraアプリとOAuth 2.0認証を前提に権限を最小化する
特に重要なのは、2026年6月2日に更新されたアプリ接続まわりの公式情報を、単なる「接続手順」としてではなく、API制限、複数インスタンス、Filesページ非推奨後のFile policy運用、コネクタ停止時の影響まで含めて読むことです。最初の1週間は検出精度を確認し、2週間目以降に自動アクションを限定的に有効化する進め方にすると、業務影響を抑えながらMicrosoft Defender for Cloud Appsの効果を高めやすくなります。
コメント