Microsoft Defender XDR のSIEM連携に関する公式ページ「Integrate your SIEM tools with Microsoft Defender XDR」は、Microsoft Defender の検知情報を既存のSIEMに取り込む方法を確認するための重要なドキュメントです。結論からいうと、今回確認すべきポイントは「すぐに全環境で設定を変えること」ではなく、REST APIでインシデントを取り込むのか、Streaming APIでイベントデータを流すのかを整理し、利用中のSIEMコネクタ・Entraアプリ・API移行期限を点検することです。公式ページは2026年6月24日に更新されており、対象は Microsoft Defender for Endpoint と Microsoft Defender XDR です。(Microsoft Learn)
Microsoft Defender XDR とSplunk、ArcSight、Elastic、IBM QRadarなどを連携している管理者は、この記事を読みながら「自社がどの連携方式を使っているか」「旧APIに依存していないか」「Event HubsやAzure Storageの設定が適切か」を確認してください。特に、Microsoft Graph security API側では旧APIの廃止期限が別途示されているため、SIEM連携の棚卸しは早めに行う価値があります。(Microsoft Learn)
Microsoft Defender XDR のSIEM連携で押さえるべき更新ポイント
Microsoft Defender XDR のSIEM連携は、大きく2つの取り込みモデルで考えると分かりやすくなります。1つ目は、Microsoft Defender XDR のインシデントと、それに含まれるアラートをREST APIから取得する方式です。2つ目は、Advanced Hunting由来のイベントデータをAzure Event HubsまたはAzure Storage Accountへストリーミングし、SIEM側で取り込む方式です。(Microsoft Learn)
| 確認項目 | 内容 | 管理者が取るべき対応 |
|---|---|---|
| 対象範囲 | Microsoft Defender for Endpoint、Microsoft Defender XDR | Defenderポータルだけで完結している環境では影響は限定的。SIEM連携がある環境は要確認 |
| 取り込み方式 | REST APIによるインシデント取得、またはStreaming APIによるイベント転送 | SIEM側の入力元がAPIなのかEvent Hubs／Storageなのかを棚卸しする |
| 認証方式 | Microsoft Entraアプリを使ったOAuth 2.0認証 | アプリ登録、権限、シークレット期限、管理者同意を確認する |
| 対応SIEM | Splunk、Micro Focus ArcSight、Elastic、IBM QRadarなど | 利用中のコネクタが現行の推奨方式か確認する |
| 移行期限 | このSIEM連携ページ自体では一律の強制移行期限は示されていない | ただし関連するMicrosoft Graph security APIの旧API廃止期限は別途確認する |
この更新は「SIEM連携の入口」を整理する意味合いが強く、単独で全テナントに設定変更を強制する内容ではありません。一方で、すでにSIEM、SOAR、チケット管理、独自ダッシュボード、Power BIレポートなどからDefenderのAPIを呼び出している場合は、旧エンドポイントや旧アラートAPIへの依存がないかを確認する必要があります。(Microsoft Learn)
REST API連携とStreaming API連携の違い
Microsoft Defender XDR のSIEM連携で最初に判断すべきなのは、「インシデント管理をしたいのか」「イベントデータを大量に分析したいのか」です。ここを混同すると、SIEM側に不要な大量データを流したり、逆にSOCが必要とするインシデント文脈を取り逃がしたりします。
| 連携方式 | 主な用途 | 向いているケース | 注意点 |
|---|---|---|---|
| インシデントREST API | インシデント、アラート、証跡、重大度、担当者、ステータスなどを取得 | SOCのケース管理、SIEM上でのインシデント集約、チケット連携 | API権限、スロットリング、ページング、ステータス同期を設計する必要がある |
| Streaming API + Event Hubs | Advanced Huntingテーブル由来のイベントをEvent Hubsへ転送 | SplunkやQRadarなどへの大量イベント転送、相関分析、長期保存 | Event Hubsの容量、対象テーブル、重複取り込み、転送遅延を見積もる必要がある |
| Streaming API + Azure Storage | イベントをストレージに保存 | 長期保管、後段処理、監査・調査用データレイク | ストレージアカウントの権限、信頼されたMicrosoftサービスの許可、ライフサイクル管理が重要 |
インシデントREST APIは「アラートを束ねた調査単位」を扱うため、SOCの一次対応やチケット化に向いています。List incidents APIでは、指定した保持ポリシーの範囲内でインシデント一覧を取得でき、各インシデントには関連アラートや関連エンティティが含まれます。APIはlastUpdateTime、createdTime、status、assignedToなどでフィルタリングでき、1ページあたり最大100件、リクエスト上限は1分あたり50回または1時間あたり1,500回とされています。(Microsoft Learn)
一方、Streaming APIは「検知後のインシデント」だけでなく、メール、デバイス、ID、クラウドアプリなどのイベントをSIEMへ流し込む設計です。Microsoft Defender XDRは、Advanced HuntingイベントをEvent HubsまたはAzure Storage Accountへストリーミングできます。(Microsoft Learn)
対応SIEMごとの確認ポイント
公式情報では、インシデントREST API連携とストリーミング連携で対応するSIEMが分けて整理されています。Splunk、ArcSight、Elastic、IBM QRadarを使っている場合は、自社のコネクタがどちらの方式に該当するかを確認してください。(Microsoft Learn)
Splunkを利用している場合
Splunkでは、インシデント取得とイベントストリーミングで利用するアドオンが異なります。インシデントREST API側では、Splunk Add-on for Microsoft SecurityがMicrosoft Defender XDR、Microsoft Defender for Endpoint、Microsoft Defender for Identity、Microsoft Entra ID Protection、Microsoft Defender for Cloud Appsのアラートを含むインシデント取り込みをサポートします。(Microsoft Learn)
注意したいのは、Microsoft Defender XDRインシデントやMicrosoft Defender for Endpointアラートの更新、関連ダッシュボードのサポートがMicrosoft 365 App for Splunk側に移っている点です。Splunkで「取り込みはできているが、更新やダッシュボードの挙動が想定と違う」という場合は、Microsoft Security Add-onだけでなくMicrosoft 365 App for Splunkの利用状況も確認してください。(Microsoft Learn)
イベントストリーミング側では、Splunk Add-on for Microsoft Cloud Servicesを使ってAzure Event Hubsからイベントを取り込む構成が示されています。つまりSplunk環境では、インシデント用途と生イベント用途を分けて設計するのが現実的です。(Microsoft Learn)
Micro Focus ArcSightを利用している場合
ArcSightでは、Microsoft Defender XDR向けのSmartConnectorがインシデントを取り込み、CEFにマッピングします。公式情報では、以前のMicrosoft Defender for Endpoint向けFlexConnectorはリタイア済みであり、SmartConnectorが置き換え先として説明されています。(Microsoft Learn)
ArcSight環境で古いFlexConnectorを使い続けている場合、まず確認すべきなのは「現在の取り込み元がMicrosoft Defender XDRのSmartConnectorになっているか」です。古いコネクタが残っていると、インシデント単位の相関、フィールドマッピング、将来のサポート面でリスクが残ります。
Elasticを利用している場合
Elasticは、Microsoft Defender XDRおよびDefender for Endpointのインシデント・アラートをElastic Securityへ取り込み、他のクラウド、ネットワーク、エンドポイントデータと相関して調査や対応に使う構成が説明されています。ストリーミングAPI連携についてもElastic側の統合情報が案内されています。(Microsoft Learn)
Elasticを使う場合は、Defender XDRのインシデントだけを取り込むのか、Advanced Hunting由来のイベントも取り込むのかを分けて考えることが重要です。両方を取り込む場合は、アラートの二重検知、フィールド名の揺れ、タイムスタンプの扱いを事前に検証しましょう。
IBM QRadarを利用している場合
IBM QRadarについては、Microsoft Defender XDR Device Support Module（DSM）がStreaming APIを呼び出し、Event HubsまたはAzure Storage Account経由でMicrosoft Defender製品のストリーミングイベントデータを取り込む構成が示されています。(Microsoft Learn)
QRadarで確認すべきなのは、DSMが取得しているイベントタイプと、Microsoft Defender XDR側で実際にストリーミング対象として選択しているAdvanced Huntingテーブルが一致しているかです。SIEM側だけを見ても、Defender側でイベントタイプが選ばれていなければデータは流れません。
設定変更で確認すべきポイント
Microsoft Defender XDRのSIEM連携で設定ミスが起きやすいのは、APIそのものよりも周辺設定です。特に、Microsoft Entraアプリ、権限、Event Hubs、Storage、シークレット管理、スロットリングをまとめて確認する必要があります。
Microsoft EntraアプリとOAuth 2.0認証
Microsoft Defender XDR APIを利用するには、一般的にMicrosoft Entraアプリを作成し、そのアプリでアクセストークンを取得し、トークンを使ってDefender APIへアクセスします。APIアクセスにはOAuth 2.0認証が必要です。バックグラウンドサービスやデーモンのようにサインイン中のユーザーなしで動くSIEMコネクタでは、アプリケーションコンテキストの利用が推奨されています。(Microsoft Learn)
実務では、次の4点を必ず確認してください。
- Microsoft Entraのアプリ登録が現在も存在しているか
- 必要なAPIアクセス許可が付与され、管理者同意が済んでいるか
- クライアントシークレットまたは証明書の期限が切れていないか
- 退職者や旧運用担当者の個人アカウントに依存していないか
Microsoftの手順では、アプリ登録後に必要な権限を選択し、権限を追加するたびに管理者同意を付与する流れが示されています。また、シークレット値は作成後に再取得できないため、生成時に安全な場所へ保存する必要があります。(Microsoft Learn)
REST APIでインシデントを取得する場合
インシデントREST APIを使う場合、Incident.Read.AllやIncident.ReadWrite.Allなど、シナリオに応じた権限が必要です。ユーザーコンテキストで取得する場合は、そのユーザーがポータル上でインシデントを表示できる権限を持っている必要があり、レスポンスもユーザーが参照可能な範囲に制限されます。(Microsoft Learn)
管理者が見るべき実務ポイントは次の通りです。
| 確認項目 | 失敗しやすい例 | 対応策 |
|---|---|---|
| 権限 | 読み取りだけ必要なのに読み書き権限を付与している | 最小権限でIncident.Read.Allから検討する |
| ページング | 100件を超えるインシデントを取り逃がす | $topと$skipを前提に実装を確認する |
| 差分取得 | 毎回全件取得してスロットリングに近づく | lastUpdateTimeを使った差分取得を検討する |
| ステータス同期 | Defender側とSIEM側で解決状態がずれる | どちらを正とするか運用ルールを決める |
| レート制限 | 短時間に大量実行して429が返る | ポーリング間隔と再試行制御を見直す |
API制限として、Microsoft Defender XDR APIsにはスロットリングしきい値があり、Incidents APIは1分あたり最大50回または1時間あたり最大1,500回、スロットリング時はHTTP 429が返されます。(Microsoft Learn)
Event Hubsへストリーミングする場合
Event Hubsへイベントを転送する場合は、Azureサブスクリプション側でMicrosoft.Insightsリソースプロバイダーを登録し、Microsoft Entraアプリ登録、シークレット、Event Hubs namespace、Resource ID、ロール割り当てを準備します。Event Hubs namespaceでは、スループットユニットやAuto-Inflateを負荷に応じて選ぶ必要があります。(Microsoft Learn)
Event Hubs構成では、すべてのイベントタイプを1つのEvent Hubへ集約する方法と、イベントタイプごとに別々のEvent Hubへ出力する方法があります。Event Hub Clusterではないnamespaceを使う場合、Azureの制限により、1つのエクスポート設定で選べるイベントタイプは最大10個と説明されています。(Microsoft Learn)
Defenderポータル側では、Streaming API設定で「Forward events to Azure Event Hub」を選び、Event Hub名、Event Hub namespaceのResource ID、対象イベントタイプを設定します。単一Event Hubに出すのか、イベントテーブルごとに分けるのかを決めてから設定しましょう。(Microsoft Learn)
Azure Storageへストリーミングする場合
Azure Storageへイベントを保存する場合は、Storage Accountを作成し、Microsoft.Insightsリソースプロバイダーを登録します。Storage Accountでは、Streaming API設定を行うアカウントにContributorロールを割り当てる必要があります。(Microsoft Learn)
特に見落としやすいのが、Storage Account側の「Allow trusted Microsoft services to access this storage account」を有効にする必要がある点です。この設定が無効のままだと、Microsoft Defender for Endpointからストレージへのデータストリーミングが許可されない可能性があります。(Microsoft Learn)
Storage連携では、イベントタイプごとにblob containerが作成され、各行には受信時刻、テナントID、Advanced Huntingテーブル名に基づくカテゴリ、イベント本体のJSONが含まれます。後段でLog Analytics、Data Lake、SIEM、独自分析基盤に渡す場合は、このJSON構造を前提にスキーママッピングを設計してください。(Microsoft Learn)
Streaming APIで選ぶイベントタイプの考え方
Streaming APIでは、すべてのAdvanced Huntingテーブルが同じように使えるわけではありません。公式の対応表では、Commercial、GCC、GCC High、DoDごとにサポート状況が整理されており、ストリーミングデータとして利用できるのはMicrosoft Defender XDRで一般提供されている列またはフィールドに限られます。(Microsoft Learn)
代表的なGAテーブルには、AlertEvidence、AlertInfo、CloudAppEvents、DeviceEvents、DeviceFileEvents、DeviceInfo、DeviceLogonEvents、DeviceNetworkEvents、DeviceProcessEvents、EmailEvents、EmailAttachmentInfo、EmailUrlInfo、IdentityLogonEvents、UrlClickEventsなどがあります。一方で、BehaviorEntitiesやBehaviorInfoは表上では利用不可とされています。(Microsoft Learn)
グローバル企業や政府系クラウドを使う組織では、「Commercialでは動いたがGCC Highでは期待したテーブルが流れない」といった差分が起こり得ます。リージョンやクラウド種別をまたぐ運用では、イベントタイプの対応状況をテナント単位で確認してください。
移行期限で注意すべき関連API
今回の「Integrate your SIEM tools with Microsoft Defender XDR」ページ自体には、全利用者に対する一律の移行期限は明記されていません。ただし、SIEM連携や独自連携でMicrosoft Graph security APIや旧Defender APIを使っている場合は、関連APIの廃止期限を必ず確認する必要があります。
Microsoft Graph security APIの公式情報では、Legacy alerts APIは非推奨で、2026年8月31日に廃止予定とされています。該当する場合は、新しいalerts and incidents APIへの移行を検討する必要があります。(Microsoft Learn)
また、Advanced Huntingの旧APIエンドポイントであるhttps://api.security.microsoft.com/api/advancedhunting/runおよびhttps://api.security.microsoft.com/api/advancedqueries/runは、Microsoft Graphのadvanced hunting APIに置き換えられており、旧APIは2027年2月1日にデータを返さなくなると説明されています。(Microsoft Learn)
| 対象 | 期限 | 管理者が確認すべきこと |
|---|---|---|
| Legacy alerts API | 2026年8月31日 | SIEM、SOAR、独自アプリが旧alertリソースを使っていないか確認する |
| 旧Advanced Hunting API | 2027年2月1日 | advancedhunting/runやadvancedqueries/runを呼ぶ処理をMicrosoft Graph側へ移行する |
| SIEMコネクタ | 製品・バージョンにより異なる | Splunk、Elastic、QRadar、ArcSight側の最新サポート情報と照合する |
| Entraアプリのシークレット | 自社設定に依存 | 期限切れ前のローテーション計画を作る |
実務では、GitHub、Azure DevOps、PowerShellスクリプト、Logic Apps、Power Automate、SIEMの入力設定、Power BIレポート内を検索し、旧エンドポイント文字列が残っていないか確認すると効率的です。特に、過去に「一時対応」として作ったカスタムコネクタや分析レポートは、正式な資産台帳に載っていないことがあります。
管理者向けチェックリスト
SIEM連携の更新確認では、機能説明を読むだけでなく、実際の運用資産を洗い出すことが重要です。次の順番で確認すると、抜け漏れを減らせます。
連携方式の棚卸し
まず、Defender XDRからSIEMへ流しているデータの入口を確認します。
| 確認項目 | 具体的に見る場所 |
|---|---|
| 利用中のSIEM | Splunk、ArcSight、Elastic、QRadar、Microsoft Sentinel、独自基盤など |
| 取り込み方式 | REST API、Microsoft Graph security API、Event Hubs、Azure Storage、コネクタ製品 |
| 対象データ | インシデント、アラート、Advanced Huntingイベント、メールイベント、デバイスイベント、IDイベント |
| 認証方式 | Microsoft Entraアプリ、ユーザー委任、アプリケーション権限、シークレット、証明書 |
| 運用責任者 | SOC、セキュリティ管理者、Azure管理者、SIEM運用チーム、外部MSSP |
ここで重要なのは、「SIEMにデータが入っているから問題ない」と判断しないことです。データが入っていても、旧API経由、過剰権限、期限切れ間近のシークレット、重複取り込み、フィールド欠落が隠れている場合があります。
権限とシークレットの確認
Microsoft Defender XDR API連携では、Entraアプリの権限とシークレット管理が障害の原因になりがちです。公式手順でも、本番アプリにシークレットをハードコードしないこと、Azure Key Vaultなどで保護することが案内されています。(Microsoft Learn)
確認すべき項目は次の通りです。
- クライアントシークレットの有効期限
- 証明書を使っている場合の証明書期限
- APIアクセス許可の種類と最小権限
- 管理者同意の有無
- アプリ所有者が複数名いるか
- 条件付きアクセスやテナント制限の影響
- ローテーション時のSIEM側設定変更手順
特にMSSPやグローバルSOCが複数テナントを管理している場合、アプリが単一テナント用なのか、マルチテナント用なのかを分けて管理してください。パートナーコンテキストでは、顧客テナントごとの管理者同意が必要になります。(Microsoft Learn)
Event HubsとStorageの容量確認
Streaming APIを使う場合、SIEM障害の原因はDefender側ではなく、Event HubsやStorage側の容量・権限・ネットワーク設定にあることも多いです。Event Hubsでは、想定負荷に応じて価格レベル、スループットユニット、Auto-Inflate、パーティション数を検討します。(Microsoft Learn)
Microsoft Defender XDRのEvent Hubs向け手順では、過去7日間のテーブルボリュームから平均events/secや推定MB/secを見積もるAdvanced Huntingクエリの考え方が示されています。SIEMへの転送対象テーブルを増やす前に、ピーク時間帯のデータ量を測っておくと、取り込み遅延やスロットリングを防ぎやすくなります。(Microsoft Learn)
データが流れないときの切り分け
「SIEMにDefenderのイベントが入らない」場合、いきなりコネクタを再インストールするのではなく、次の順番で切り分けると原因を特定しやすくなります。
| 症状 | よくある原因 | 確認方法 |
|---|---|---|
| インシデントが取得できない | API権限不足、管理者同意なし、シークレット期限切れ | EntraアプリのAPIアクセス許可とサインインログを確認 |
| Event Hubsにメッセージが来ない | Defender側でイベントタイプ未選択、権限不足、Resource ID誤り | Streaming API設定とEvent Hubsメトリックを確認 |
| Storageにblobが作成されない | 信頼されたMicrosoftサービスの許可が無効、Contributor不足 | Storage Accountのネットワーク設定とIAMを確認 |
| 一部テーブルだけ欠落 | Streaming APIで未対応、またはGAでない列を期待している | 対応イベントタイプ表を確認 |
| SIEM上で重複する | REST APIとStreaming APIの両方で同じ検知を取り込んでいる | インシデント系とイベント系の取り込みルールを分離 |
| 急に429が増えた | ポーリング頻度が高い、差分取得できていない | API呼び出し間隔と再試行制御を見直す |
Event Hubs連携では、Defender側でエクスポート対象データがあるかをAdvanced Huntingで確認し、その後Azure側のEvent HubメトリックでIncoming Messagesを確認する流れが案内されています。エクスポートされたメッセージがEvent Hubsに表示されるまで最大1時間かかる場合がある点も、運用監視に入れておくべきです。(Microsoft Learn)
グローバル運用で注意すべきポイント
グローバル企業では、Microsoft Defender XDRのSIEM連携を本社SOCだけで設計すると、地域ごとの法規制、データ保管場所、クラウド種別、権限分離に対応しづらくなります。特に、Event HubsやStorage Accountのリージョン選択、テナントごとのEntraアプリ、政府系クラウドでのイベントタイプ対応状況は、初期設計で確認してください。Streaming APIの対応表はCommercial、GCC、GCC High、DoDを分けて示しています。(Microsoft Learn)
実務では、次のような設計方針にすると運用しやすくなります。
- グローバル共通の命名規則でEntraアプリ、Event Hubs、Storage Accountを作る
- テナントごとにAPI権限とシークレット期限を一覧化する
- SIEM側では「インシデント」と「生イベント」を別インデックスまたは別データセットで管理する
- 重大度、ステータス、担当者、分類などのフィールドマッピングをSOCで標準化する
- ローカルSOCが見るデータ範囲と、グローバルSOCが見るデータ範囲を分ける
- API廃止期限、コネクタのサポート期限、シークレット期限を同じ運用カレンダーで管理する
独自性を出すなら、SIEM連携を「ログ転送」として扱うのではなく、検知後の判断材料をどこまでSIEMに持たせるかで設計するとよいです。Microsoft Defender XDR側で相関済みのインシデントをSIEMに渡すのか、SIEM側で生イベントから独自相関するのかによって、必要なデータ量、コスト、運用手順は大きく変わります。
まず管理者が取るべき行動
今回の更新を受けて、Microsoft Defender XDRを運用する管理者は、最初にSIEM連携の棚卸しを行ってください。特に確認すべきなのは、利用中のSIEMコネクタ、取り込み方式、APIエンドポイント、Entraアプリ、権限、シークレット期限、Event Hubs／Storageの設定、対象イベントタイプです。
次に、旧APIの利用有無を確認します。Legacy alerts APIを使っている場合は2026年8月31日、旧Advanced Hunting APIを使っている場合は2027年2月1日が重要な期限です。該当する処理がある場合は、Microsoft Graph security APIまたは新しいalerts and incidents APIへの移行計画を立てる必要があります。(Microsoft Learn)
最後に、SIEM上で実際に取得できている件数と、Defenderポータル上のインシデント数・イベント数を比較してください。設定画面上は成功していても、権限不足、対象テーブルの選択漏れ、スロットリング、シークレット期限、Event Hubs容量不足でデータが欠落することがあります。Microsoft Defender XDRのSIEM連携は、一度設定して終わりではなく、API仕様、コネクタ、権限、データ量を継続的に点検する運用項目です。
コメント