Microsoft Defender for Cloud Apps と Microsoft Sentinel integration で最初に確認すべきことは、従来の SIEM エージェントを前提にした運用を続けていないかです。公式ドキュメントでは、Microsoft Defender for Cloud Apps の SIEM エージェントは 2025 年 11 月から非推奨となり、2025 年 6 月 19 日以降は新しい SIEM エージェントを構成できません。一方で、Microsoft Sentinel エージェント統合はプレビューとしてサポートされ、引き続き追加可能とされています。(Microsoft Learn)
つまり、管理者が取るべき対応は「Sentinel との接続を有効にする」だけではありません。既存の CEF／Syslog 連携、KQL クエリ、分析ルール、Power BI レポート、インシデント運用まで含めて、どのデータをどの経路で取り込むかを見直す必要があります。この記事では、Microsoft Defender for Cloud Apps と Microsoft Sentinel 統合の変更点、影響範囲、確認すべき設定、移行時の注意点を実務目線で整理します。
Microsoft Defenderのセキュリティ更新で管理者がまず確認すべきポイント
Microsoft Defender for Cloud Apps と Microsoft Sentinel の統合は、クラウドアプリのアラートや検出データを Microsoft Sentinel に集約し、SOC の監視・調査・自動化に活用するための機能です。公式情報では、Sentinel 統合により、通常のセキュリティワークフローを維持しながら、クラウドアプリの保護、手順の自動化、クラウドとオンプレミスイベントの相関分析を行えると説明されています。(Microsoft Learn)
今回の重要点は、単なる画面変更ではなく、Defender for Cloud Apps のログ連携方式が、従来型の SIEM エージェント中心から、Microsoft Sentinel／Microsoft Defender XDR／API を組み合わせた運用へ移行していることです。
特に次の3点は、すぐに棚卸ししてください。
| 確認項目 | 管理者が見るべきポイント |
|---|---|
| 既存の SIEM エージェント | CEF／Syslog で外部 SIEM に送っている運用が残っていないか |
| Microsoft Sentinel 統合 | アラートと検出ログがどのテーブルに入っているか |
| 将来の移行先 | Microsoft Defender XDR コネクタ、Streaming API、Graph Security API への移行が必要か |
Microsoft が推奨している移行先には、アラートとアクティビティ向けの Microsoft Defender XDR Streaming API、Microsoft Entra ID Protection のログオンイベント向けの IdentityLogonEvents、Microsoft Graph Security Alerts API、Microsoft Defender XDR incidents API があります。(Microsoft Learn)
何が変わったのか：従来のSIEMエージェント前提からの見直しが必要
従来の Defender for Cloud Apps SIEM エージェントは、管理者がサーバー上で JAR ファイルを実行し、Defender for Cloud Apps から取得したアラートやアクティビティを Syslog／CEF 形式で SIEM に送る構成でした。Generic SIEM 連携では、エージェントが Defender for Cloud Apps REST API からデータを取得し、HTTPS 443 番ポートで通信した後、ローカル SIEM に Syslog メッセージを送信する構成です。(Microsoft Learn)
この方式を使っている組織では、次のような影響が出やすくなります。
| 対象 | 影響 | 確認すべき対応 |
|---|---|---|
| ArcSight や汎用 CEF に連携している環境 | 既存エージェント依存の運用が非推奨対象になる | 連携方式、パーサー、保存先を棚卸しする |
| CEF フィールドを前提にした検知ルール | API 移行後にフィールド名や構造が変わる可能性がある | KQL、SIEM ルール、正規化処理を見直す |
| Sentinel で Cloud Discovery を見ている環境 | McasShadowItReporting の取り込み有無が重要 | 検出ログが実際に届いているか確認する |
| SOC 運用チーム | アラート重複、インシデント重複、欠落に気づきにくい | 取り込み経路を1枚の構成図にまとめる |
| 開発者・自動化担当 | API、プレイブック、Power BI レポートの修正が必要になる | 既存のクエリ・コネクタ・資格情報を確認する |
特に失敗しやすいのは、「Sentinel に何かしらログが入っているから問題ない」と判断してしまうケースです。SecurityAlert にアラートが入っていても、Cloud Discovery の検出ログが McasShadowItReporting に入っていない場合、シャドウ IT の可視化やアプリ利用状況の分析が不足します。
Microsoft Sentinel統合で取り込まれるデータ
Defender for Cloud Apps と Microsoft Sentinel の統合後、Sentinel 側では主に次のテーブルを確認します。公式ドキュメントでは、検出ログは McasShadowItReporting、アラートは SecurityAlert に格納されると説明されています。(Microsoft Learn)
| データ種別 | Sentinel 側のテーブル | 主な用途 |
|---|---|---|
| アラート | SecurityAlert | Defender for Cloud Apps の検知結果を SOC で確認する |
| 検出ログ | McasShadowItReporting | シャドウ IT、クラウドアプリ利用、アップロード量・ダウンロード量などを分析する |
McasShadowItReporting では、アプリ名、アプリカテゴリ、ユーザー名、IP アドレス、アップロード量、ダウンロード量、総イベント数、アプリのリスクスコアなどを確認できます。たとえば、利用量が多い未承認クラウドストレージを洗い出したい場合は、次のような KQL が実務で使いやすいでしょう。
McasShadowItReporting
| where TimeGenerated > ago(7d)
| summarize
Events = sum(TotalEvents),
UploadedBytes = sum(UploadedBytes),
DownloadedBytes = sum(DownloadedBytes)
by AppName, AppCategory
| top 20 by Events複数の Defender 製品や外部コネクタを SecurityAlert に集約している場合は、いきなり製品名で決め打ちしないほうが安全です。まず実データの ProductName や ProviderName を確認し、その環境に合ったフィルターを作ります。
SecurityAlert
| where TimeGenerated > ago(7d)
| summarize AlertCount = count() by ProductName, ProviderName
| order by AlertCount descこの確認を省くと、分析ルールを作ったつもりでも対象アラートを拾えていない、または別製品のアラートまで拾ってしまうことがあります。
設定前に確認すべき前提条件
Microsoft Sentinel と統合するには、有効な Microsoft Sentinel ライセンスが必要です。また、テナントで少なくともセキュリティ管理者以上の権限が必要とされています。(Microsoft Learn)
実務では、公式の前提条件に加えて次の点も確認しておくと、展開後の手戻りを減らせます。
| 確認項目 | 理由 |
|---|---|
| Microsoft Sentinel ワークスペースの所有者・管理者 | データコネクタ、分析ルール、保持期間、コスト設定に関わるため |
| Defender for Cloud Apps の管理権限 | Cloud Apps 設定画面で SIEM エージェント統合を操作するため |
| 既存の SIEM 連携一覧 | 旧エージェント、XDR コネクタ、個別コネクタの重複を避けるため |
| 保存期間とコスト | Log Analytics に入るデータ量が増える可能性があるため |
| SOC の検知ルール | テーブル名やフィールド名が変わると検知漏れにつながるため |
| Power BI 利用有無 | Shadow IT Discovery ダッシュボードや独自レポートの接続確認が必要なため |
特に、Microsoft Sentinel を Azure portal で運用している組織は、ポータル移行も同時に見ておくべきです。Microsoft Sentinel は Microsoft Defender portal で一般提供されており、2027 年 3 月 31 日以降は Azure portal でサポートされず、Defender portal のみで利用可能になります。(Microsoft Learn)
Microsoft Defender for Cloud AppsとSentinelを統合する手順
公式手順では、Defender ポータル側で SIEM エージェントから Sentinel 統合を追加し、その後 Microsoft Sentinel 側で構成を完了します。具体的には、Microsoft Defender ポータルで Settings、Cloud Apps の順に進み、System 配下の SIEM agents から Add SIEM agent、Sentinel を選択します。(Microsoft Learn)
実務向けに整理すると、手順は次の流れです。
| 手順 | 作業 | 注意点 |
|---|---|---|
| 事前確認 | ライセンス、権限、既存連携を確認 | 旧 SIEM エージェントが残っていないか確認する |
| Defender 側設定 | Settings → Cloud Apps → SIEM agents → Sentinel を選択 | 既に統合済みの場合、Sentinel 追加オプションは表示されないことがある |
| データ種別選択 | アラート、検出ログを選ぶ | アラートは Sentinel 有効化時に自動でオン。検出ログはスライダーとフィルターを確認 |
| Sentinel 側設定 | データコネクタの構成を完了 | ワークスペースを間違えない |
| 取り込み確認 | SecurityAlert と McasShadowItReporting を KQL で確認 | 新しい検出ログは通常 15 分以内に表示されるが、環境により遅れることがある |
| 運用確認 | 分析ルール、ブック、プレイブック、通知を確認 | アラート重複や欠落をチェックする |
検出ログは通常、Defender for Cloud Apps で構成してから 15 分以内に Microsoft Sentinel に表示されます。ただし、システム環境によっては時間がかかるため、設定直後に空だからといってすぐ失敗と判断しないことが重要です。(Microsoft Learn)
Microsoft Defender XDRコネクタとの関係を整理する
混乱しやすいのが、Defender for Cloud Apps の Sentinel 統合と、Microsoft Defender XDR コネクタの違いです。
Microsoft Defender XDR コネクタは、Microsoft Defender XDR のインシデント、アラート、高度なハンティングイベントを Microsoft Sentinel にストリーミングし、両ポータル間でインシデントを同期します。Microsoft Sentinel を Defender portal にオンボードしている場合、このコネクタは自動的に有効化されるため、Azure portal での手動構成は不要とされています。(Microsoft Learn)
使い分けの目安は次のとおりです。
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| Defender for Cloud Apps の Sentinel 統合 | Cloud Discovery の検出ログを Sentinel で扱いたい | 商用顧客向けの直接統合。プレビュー扱いである点を確認する |
| Microsoft Defender XDR コネクタ | Defender 製品横断のインシデント、アラート、高度なハンティングイベントを統合したい | 既存の個別コネクタや分析ルールとの重複・スキーマ差分を確認する |
| Defender XDR Streaming API | 外部 SIEM やデータ基盤に継続的にイベントを流したい | API、Event Hubs、Azure Storage などの設計が必要 |
| Graph Security Alerts API | アラートデータをアプリケーションや自動化処理で利用したい | 既存 CEF フィールドとの1対1対応を期待しない |
Defender XDR コネクタでは、Defender for Cloud Apps に関係する高度なハンティングテーブルとして CloudAppEvents を利用できます。これは、Defender for Cloud Apps がカバーする各種クラウドアプリやサービスのアクティビティ情報を扱うテーブルです。(Microsoft Learn)
一方、従来の SIEM エージェントから API へ移行する場合、CEF フィールドと新しい API スキーマが完全に一致するとは限りません。公式の移行情報でも、レガシ CEF スキーマとの完全な 1 対 1 のマッピングがない可能性が示されています。(Microsoft Learn)
開発者・検知エンジニアが注意すべきスキーマ変更
移行で最も影響を受けるのは、KQL、SIEM パーサー、ダッシュボード、アラート自動化を作っている担当者です。
たとえば、レガシ SIEM の CEF では suser がユーザー、destinationServiceName が発生元アプリ、externalId がイベント ID やアラート ID として扱われていました。API 移行後は、Defender XDR Streaming API や Graph Security Alerts API 側の AccountObjectId、AccountDisplayName、CloudAppEvents > Application、ReportId、AlertId などに読み替える必要があります。(Microsoft Learn)
移行時は、次のような進め方が安全です。
| 作業 | 具体例 |
|---|---|
| フィールド利用状況を棚卸し | SIEM ルール、KQL、Power BI、Logic Apps で参照しているフィールドを一覧化する |
| 変換レイヤーを作る | 旧フィールド名と新フィールド名を直接ルールに埋め込まず、関数やビューで吸収する |
| テスト用クエリを残す | 旧経路と新経路で件数、重大度、対象ユーザー、アプリ名を比較する |
| 期間を区切って並行運用する | いきなり切り替えず、少なくとも主要アラートの一致を確認する |
| 誤検知・欠落を記録する | 移行後に発生した差分をナレッジ化し、検知ルールに反映する |
スキーマ移行では「同じ意味に見えるフィールド」が危険です。名前が似ていても、発生時刻、作成時刻、更新時刻、解決時刻などの意味が異なる場合があります。時系列分析や SLA 管理に使うフィールドは、特に慎重に確認してください。
政府機関向けクラウドや複数ポータル運用での注意点
Defender for Cloud Apps と Microsoft Sentinel の直接統合は、商用顧客のみが利用可能とされています。GCC、GCC High、DoD の顧客については、Defender for Cloud Apps のデータは Microsoft Defender XDR で利用できるため、Microsoft Defender XDR コネクタ経由で Sentinel に取り込む構成が推奨されています。(Microsoft Learn)
また、Microsoft Sentinel のポータル移行も無視できません。Defender portal では、インシデント、アラート、調査を統合画面で扱えるほか、Advanced hunting で複数データセットを横断してクエリできます。Microsoft の公式情報では、Defender portal 上の Sentinel で、統合インシデント、エンティティページ、Advanced hunting などを使えると説明されています。(Microsoft Learn)
現場で確認すべきなのは、機能名ではなく「運用手順が変わる場所」です。たとえば、Azure portal で Logs を開いていた担当者は、Defender portal では Investigation & response 配下の Advanced hunting を使う場面が出てきます。データコネクタは Defender portal 側では Microsoft Sentinel、Configuration、Data connectors の導線になります。(Microsoft Learn)
既存環境で確認すべきチェックリスト
まずは次の順番で確認すると、影響範囲を短時間で把握できます。
| 優先度 | チェック項目 | 判断基準 |
|---|---|---|
| 高 | 旧 Defender for Cloud Apps SIEM エージェントの有無 | SIEM agents に Generic SIEM や ArcSight 向け構成が残っていないか |
| 高 | Sentinel 統合のデータ到着 | SecurityAlert と McasShadowItReporting に直近データがあるか |
| 高 | アラート重複 | XDR コネクタ、個別 Defender コネクタ、旧 SIEM 連携で同じ検知を二重処理していないか |
| 中 | KQL・分析ルール | テーブル名、フィールド名、時間条件が現在の取り込み経路に合っているか |
| 中 | Power BI レポート | ワークスペース ID、認証、更新スケジュールが正しいか |
| 中 | コストと保持期間 | Cloud Discovery ログの取り込み量が想定内か |
| 低 | ドキュメント整備 | SOC、ID 管理、クラウド管理、開発担当が同じ構成図を見ているか |
特に McasShadowItReporting は、シャドウ IT の可視化に直結します。データが入っていない場合、検出ログを送る設定が無効になっている、フィルター条件で除外されている、ワークスペースを間違えている、反映待ちである、といった原因を順に確認しましょう。
Power BIやレポート運用での注意点
Microsoft Sentinel に保存された Defender for Cloud Apps データは、Power BI でも利用できます。公式ドキュメントでは、Sentinel から Defender for Cloud Apps データのクエリをインポートし、Defender for Cloud Apps Shadow IT Discovery アプリを接続して、組み込みの Shadow IT Discovery ダッシュボードを利用する手順が紹介されています。(Microsoft Learn)
ただし、Shadow IT Discovery アプリは Microsoft AppSource に公開されていないため、インストール権限について Power BI 管理者に確認が必要になる場合があります。(Microsoft Learn)
レポート運用では、次の3点を確認してください。
| 確認項目 | 失敗しやすいポイント |
|---|---|
| ワークスペース ID | Sentinel の Log Analytics ワークスペース ID と Power BI の接続先を取り違える |
| 認証方式 | 個人アカウントで接続し、退職・異動時に更新が止まる |
| 更新スケジュール | データは入っているが、Power BI 側の更新が止まっていて古い状態に見える |
セキュリティ運用レポートは、見た目よりも「いつのデータか」が重要です。ダッシュボードには最終更新時刻を表示し、週次レビューでは Sentinel 側の KQL 結果と Power BI の数値を突き合わせる運用にしておくと、誤った判断を避けられます。
展開・移行で失敗しないための実務ポイント
Microsoft Defender for Cloud Apps と Microsoft Sentinel integration の展開では、技術設定よりも「運用の切り替え設計」が成否を分けます。
まず、既存の SIEM エージェントをすぐ削除するのではなく、どの検知ルール、ダッシュボード、通知、インシデント対応がそのデータに依存しているかを確認します。そのうえで、Sentinel 統合、Defender XDR コネクタ、API のどれで代替するのかを決めます。
次に、移行後の検知品質を確認します。件数だけでなく、重大度、対象ユーザー、対象アプリ、IP アドレス、発生時刻の粒度まで比較してください。特にアクティビティログは、アラートよりも件数が多く、保存期間やコストにも影響します。
最後に、SOC の手順書を更新します。ポータルの場所、KQL の実行場所、アラート調査の入口、Power BI レポートの更新方法が変わると、障害時やインシデント時に対応が遅れます。構成変更と同じタイミングで、一次対応者向けの手順書も必ず更新しましょう。
まず取るべき次のアクション
Microsoft Defender for Cloud Apps と Microsoft Sentinel の統合では、旧 SIEM エージェントの非推奨、Sentinel へのログ取り込み、Defender XDR との連携、API 移行、ポータル移行が同時に関係します。最初にやるべきことは、新機能を試すことではなく、現在どの経路でどのデータを取り込んでいるかを可視化することです。
管理者は、SIEM agents の既存構成、Sentinel の SecurityAlert と McasShadowItReporting、Defender XDR コネクタの状態、KQL・Power BI・プレイブックの依存関係を確認してください。開発者や検知エンジニアは、CEF 前提のフィールド参照を棚卸しし、API や Defender XDR 側のスキーマに合わせた移行計画を作る必要があります。
早めに構成を整理しておけば、旧エージェント非推奨の影響を抑えつつ、Microsoft Sentinel と Microsoft Defender XDR を使った統合セキュリティ運用へ移行しやすくなります。
コメント