Microsoft DefenderポータルでMicrosoft Sentinelを運用している管理者にとって、2026年5月14日更新の「Connect data sources to Microsoft Sentinel by using data connectors」は、単なるデータコネクタ設定手順ではありません。結論から言うと、今後はContent hubで必要なソリューションを導入し、Defenderポータル上のData connectorsで設定・保持期間・UEBA・取り込み状況まで確認する運用が前提になります。特にAzureポータルでMicrosoft Sentinelを使い続けている組織は、2027年3月31日以降のDefenderポータル移行を見据えて、コネクタ、分析ルール、自動化、API連携を棚卸しする必要があります。(Microsoft Learn)
2026年5月14日更新の要点
Microsoft Learnの該当記事は、Microsoft Sentinelにデータソースを接続するには、Microsoft Sentinel Content hubで提供されるデータコネクタをインストールし、設定する必要があると説明しています。対象は「Microsoft DefenderポータルのMicrosoft Sentinel」と「AzureポータルのMicrosoft Sentinel」の両方ですが、重要なのは今後の主軸がDefenderポータルへ移っていく点です。(Microsoft Learn)
今回の更新で管理者が押さえるべきポイントは、次の4つです。
| 確認項目 | 何を意味するか | 管理者が取るべき行動 |
|---|---|---|
| AzureポータルからDefenderポータルへの移行 | Microsoft Sentinelの管理画面がDefenderポータル中心になる | Azureポータル前提の手順書、教育資料、運用フローを見直す |
| Content hubの重要性 | コネクタは単体ではなく、関連ソリューションとして提供される場合がある | 目的のコネクタが見つからない場合、まずContent hubでソリューション導入状況を確認する |
| データ保持と階層化 | Analytics tierとData lake tierをコネクタ単位で意識する必要がある | 検知に使うログ、長期保管するログ、低頻度参照ログを分類する |
| UEBAとAdvanced hunting | 取り込んだデータを行動分析やハンティングに使える | 対応コネクタではUEBA有効化、KQLクエリ、テーブル名を確認する |
「コネクタを有効化したら終わり」ではなく、取り込まれたデータがどのテーブルに入り、どの検知ルールやハンティングで使われ、どの期間保持されるかまで確認するのが実務上のポイントです。
Microsoft Defender管理者に影響する範囲
この更新は、Microsoft Defender for Endpointなど個別のセンサー設定が直接変わる話ではありません。影響の中心は、Microsoft DefenderポータルでMicrosoft Sentinelを使い、SIEMとXDRを統合運用している環境です。
特に影響を受けやすいのは、次の担当者です。
| 対象者 | 影響する作業 | 見直すべきポイント |
|---|---|---|
| セキュリティ管理者 | データコネクタの導入、権限管理、保持期間設定 | Sentinelワークスペースの読み書き権限、Content hubの導入状況 |
| SOCアナリスト | インシデント調査、Advanced hunting、UEBA | AzureポータルとDefenderポータルでの画面差分、KQLの実行場所 |
| 開発者・自動化担当 | API連携、Logic Apps、チケット連携 | Microsoft Graph API、SecurityInsights API、レスポンス項目の差分 |
| MSSP・複数テナント管理者 | 複数ワークスペース、複数テナントの監視 | primary workspace、secondary workspace、テナント単位の接続設計 |
DefenderポータルにMicrosoft Sentinelを接続すると、インシデント管理やAdvanced huntingなどの機能を統合して使えます。Microsoftの説明では、Microsoft SentinelはDefender XDRやE5ライセンスの有無にかかわらずDefenderポータルで一般提供されており、2025年7月1日以降にMicrosoft Sentinelへオンボードする多くの顧客は自動的にDefenderポータルへオンボードされる場合があります。(Microsoft Learn)
Azureポータル利用組織は2027年3月31日を移行期限として扱う
最も重要な変更点は、Microsoft SentinelのAzureポータル対応終了です。Microsoftは、2027年3月31日以降、Microsoft SentinelはAzureポータルでサポートされず、Microsoft Defenderポータルでのみ利用できると案内しています。AzureポータルでMicrosoft Sentinelを使っている顧客はDefenderポータルへリダイレクトされるため、今から移行計画を立てる必要があります。(Microsoft Learn)
移行そのものに追加コストは発生せず、通常どおりMicrosoft Sentinelの使用量に基づいて課金されると説明されています。ただし、コストが変わらないことと、運用変更が不要であることは別です。画面、権限、インシデント相関、自動化、API連携は確認が必要です。(Microsoft Learn)
移行前に確認すべき実務項目
| 項目 | 確認内容 | 放置した場合のリスク |
|---|---|---|
| ワークスペース構成 | primary workspaceとsecondary workspaceの設計 | Defender XDRデータとの相関対象を誤る |
| Azure RBAC | Sentinel Reader、Sentinel Contributorなどの付与範囲 | DefenderポータルでSentinelメニューが表示されない |
| コネクタ一覧 | 既存コネクタ、接続先、取り込みテーブル | 移行後にログが想定どおり見えない |
| 分析ルール | Defender XDRデータとSentinelデータをまたぐ検知 | スキーマ差分でクエリが失敗する |
| 自動化ルール | Incident provider、Description、タイトル条件 | 移行後にLogic Appsやチケット連携が動かない |
| 運用手順書 | Azureポータル前提の画面キャプチャや操作手順 | SOCアナリストの初動対応が遅れる |
Defenderポータルでは、単一のMicrosoft Entraテナントに対して、1つのprimary workspaceと複数のsecondary workspaceを接続できます。既存のAzure RBAC権限はDefenderポータル側にも反映されますが、ロール変更は引き続きAzureポータル側で管理する点に注意が必要です。(Microsoft Learn)
データコネクタ設定の基本手順
データソースをMicrosoft Sentinelへ接続する基本の流れは、次の順番で考えると失敗しにくくなります。
| 手順 | 操作 | 確認ポイント |
|---|---|---|
| 1 | Content hubで対象ソリューションを探す | コネクタ、分析ルール、Workbook、Playbookが含まれるか確認する |
| 2 | 必要なソリューションをインストールする | Microsoft Sentinel Contributorなど、必要な権限があるか確認する |
| 3 | Microsoft Sentinel > Configuration > Data connectorsを開く | 目的のコネクタが表示されない場合は、ソリューション未導入を疑う |
| 4 | コネクタページを開く | Prerequisitesを読み、権限、認証情報、接続要件を満たす |
| 5 | Configurationsの手順に沿って設定する | 外部サービスのAPIキー、エージェント、ポート開放などを確認する |
| 6 | データ保持、UEBA、取り込み状況を確認する | Data receivedグラフ、接続状態、KQLで確認する |
Defenderポータルでは、Microsoft Sentinel > Configuration > Data connectorsからコネクタを選択し、Open connector pageで詳細設定を開きます。目的のコネクタが見つからない場合は、関連ソリューションがContent hubにインストールされているか確認する必要があります。(Microsoft Learn)
Content hubは、Microsoft Sentinelの組み込みコンテンツを探し、管理する中心的な場所です。ソリューションには、データコネクタだけでなく、分析ルール、Workbook、Playbookなどが含まれることがあります。ソリューション内のコンテンツを使うには、該当ソリューション全体をインストールする必要がある点も見落としやすいポイントです。(Microsoft Learn)
コネクタ別の前提条件を必ず確認する
Microsoft Sentinelのデータコネクタは、種類によって前提条件が大きく異なります。たとえば、Azure Monitor Agent、APIキー、外部SaaS側の権限、Azure Functionsの作成権限、ネットワーク機器側の転送設定などが必要になる場合があります。
Microsoftのデータコネクタ一覧では、各コネクタの前提条件、取り込み先テーブル、DCR対応、Lake-only ingestion対応などが示されています。Azure Monitor Agentベースのコネクタでは、エージェントをインストールしたシステムからMicrosoft Sentinelへ接続するため、アウトバウンドのTCP 443番ポートを許可する必要があります。(Microsoft Learn)
よくある失敗例
| 失敗例 | 原因 | 対策 |
|---|---|---|
| コネクタが一覧に出ない | Content hubで関連ソリューションを入れていない | 先にソリューションをインストールする |
| SyslogやCEFが入らない | AMA、DCR、機器側転送設定のどこかが未完了 | エージェント、DCR、送信元機器の3点を切り分ける |
| 外部SaaSログが入らない | APIトークンの権限不足、期限切れ、スコープ不足 | SaaS側の監査ログ権限とトークン有効期限を確認する |
| ログ量が想定より多い | すべてのイベントテーブルを有効化した | 検知に必要なテーブルから段階的に有効化する |
| サポート窓口を誤る | コネクタ提供元がMicrosoft以外 | コネクタページのSupported byを確認する |
Microsoft SentinelのコネクタはMicrosoftだけでなく、他社やコミュニティによって提供されるものもあります。トラブル時は、コネクタページのSupported byに記載されたサポート連絡先を確認するのが基本です。(Microsoft Learn)
データ保持と階層化は「検知」と「保管」を分けて考える
Microsoft Sentinel data lakeにオンボードしている場合、データコネクタごとにデータ保持と階層化を設定できます。Microsoftの説明では、data lakeは現在のMicrosoft Sentinelワークスペースに相当するAnalytics tierと、最大12年の保存に対応するData lake tierで構成されます。(Microsoft Learn)
コネクタを有効化すると、既定ではデータがAnalytics tierに送られ、Data lake tierにもミラーリングされます。管理者は、各階層の保持期間を設定したり、データをData lake tierのみに送る構成を選んだりできます。ただし、Data lake tierのみを選ぶと、Analytics tierへの以後の取り込みは停止されます。(Microsoft Learn)
保持先の判断基準
| ログの種類 | 推奨する考え方 | 理由 |
|---|---|---|
| 検知ルールで即時利用するログ | Analytics tierに保持 | 分析ルール、インシデント調査、SOC運用で使いやすい |
| 監査・証跡として長期保管するログ | Data lake tierを活用 | 長期間の調査やコンプライアンス用途に向く |
| 大量だが普段は見ないログ | Lake-onlyを検討 | コストと検索頻度のバランスを取りやすい |
| インシデント初動に必要なログ | Lake-onlyにしない方が安全 | 検知や即時調査で参照できないと対応が遅れる可能性がある |
Data lakeへの取り込みには時間がかかる場合があり、MicrosoftはData lakeへのデータ取り込みに90〜120分かかると説明しています。設定直後にデータが見えない場合でも、まずはコネクタの接続状態、Data receivedグラフ、対象テーブルへの反映を順に確認してください。(Microsoft Learn)
Microsoft Defender XDR connectorのスキーマ差分に注意する
Microsoft Defender関連のログを扱う場合は、Microsoft Defender XDR connectorの挙動を必ず確認してください。このコネクタは、Microsoft Defender XDRのインシデント、アラート、Advanced huntingイベントをMicrosoft Sentinelへストリーミングし、両ポータル間でインシデントを同期します。DefenderポータルにMicrosoft Sentinelをオンボード済みの場合、Microsoft Defender XDR connectorは自動的に有効化されるため、Azureポータルでの手動設定手順は不要です。(Microsoft Learn)
注意すべきなのは、スタンドアロンコネクタからXDR connectorへ切り替えると、アラートのスキーマやフィールドマッピングが変わる可能性がある点です。Microsoftは、既存のクエリ、分析ルール、Workbookに影響する可能性があるため、移行前に差分確認を推奨しています。(Microsoft Learn)
影響を受けやすい箇所
| 項目 | 影響例 | 確認方法 |
|---|---|---|
| KQLクエリ | フィールド名や値セットが変わる | 既存クエリをAdvanced huntingとLog Analyticsで実行確認する |
| 分析ルール | 条件に使っているフィールドが変わる | 検知結果がゼロになっていないか確認する |
| Workbook | グラフや集計が表示されない | 参照テーブルと列名を確認する |
| 自動化 | インシデントプロバイダーや説明欄に依存 | 条件式、チケット連携、Logic Appsの入力を確認する |
| Defender for Cloud | スコープがサブスクリプション単位からテナント単位に変わる場合がある | primary workspaceへの取り込み方針を確認する |
特にMicrosoft Defender for Cloudでは、Defender XDR統合により、Tenant-based Microsoft Defender for Cloud connectorとSubscription-based Microsoft Defender for Cloud legacy connectorの使い分けが重要になります。相関されたテナント全体のDefender for Cloudインシデントをprimary workspaceへ送る場合は、Tenant-based connectorを使い、legacy connectorを切断する構成が案内されています。(Microsoft Learn)
重複インシデントを防ぐ設定を確認する
Defender XDRとMicrosoft Sentinelを統合すると、インシデントが双方向で同期されます。そのため、同じアラートから重複インシデントが作成されないように、Microsoft Defender XDR統合製品のMicrosoft incident creation rulesを無効化することが推奨されています。対象にはDefender for Endpoint、Defender for Identity、Defender for Office 365、Defender for Cloud Apps、Microsoft Entra ID Protectionなどが含まれます。(Microsoft Learn)
既存環境で確認するなら、まず次のようなKQLでMicrosoft XDR由来のインシデントを見ます。
SecurityIncident
| where ProviderName == "Microsoft XDR"
| summarize Count = count() by bin(TimeGenerated, 1d)
| order by TimeGenerated descMicrosoft Defender XDR connectorを有効化すると、以前接続されていたMicrosoft Defenderコンポーネントの個別コネクタは、画面上は接続済みに見えてもバックグラウンドで自動的に切断され、データは流れなくなると説明されています。この挙動を知らないと、「コネクタは接続済みなのにデータがない」と誤解しやすいため注意してください。(Microsoft Learn)
UEBAは対応コネクタで早めに有効化を検討する
UEBAは、接続済みデータソースのログやアラートを分析し、ユーザー、ホスト、IPアドレス、アプリケーションなどの行動ベースラインを作成します。その上で、侵害の兆候となる異常な振る舞いを検出する機能です。(Microsoft Learn)
Defenderポータルでは、Microsoft Sentinel > Configuration > Data connectorsからUEBA対応コネクタを選び、Advanced optionsのConfigure UEBAで対象テーブルを有効化します。(Microsoft Learn)
ただし、UEBAは有効化すれば即座に万能な検知ができる機能ではありません。実務では、次の順番で進めると安全です。
| 手順 | 内容 |
|---|---|
| 1 | UEBA対応コネクタと対象テーブルを確認する |
| 2 | 既存のID、デバイス、クラウドアプリのログ量を確認する |
| 3 | 重要ユーザー、特権アカウント、管理端末を優先して監視する |
| 4 | 異常検知の結果をSOCでレビューし、誤検知の傾向を把握する |
| 5 | 分析ルール、Watchlist、インシデント対応手順に反映する |
Defenderポータルへ移行すると、IdentityInfoテーブルはAdvanced hunting側でも利用できますが、一部のフィールドがリネームされたり、サポートされなかったりする場合があります。また、IdentityInfoはDefenderネイティブテーブルとなり、Azureポータルで使っていたテーブルレベルRBACが使えなくなる点にも注意が必要です。(Microsoft Learn)
データが入っているかをKQLで確認する
コネクタを有効化した後は、Data receivedグラフだけでなく、KQLで対象テーブルを確認してください。DefenderポータルではAdvanced hunting、AzureポータルではLogs、Data lake内のデータはData lake explorerのKQL queriesから確認します。(Microsoft Learn)
たとえば、Defender for Endpointのデバイスイベントを確認する場合は、次のように日別件数を見ると、取り込みの有無と急な増減を把握しやすくなります。
DeviceEvents
| summarize Count = count() by bin(TimeGenerated, 1d)
| order by TimeGenerated descアラートやインシデントの取り込み確認では、テーブル名、プロバイダー名、時間範囲を意識します。
SecurityIncident
| summarize Count = count() by ProviderName, bin(TimeGenerated, 1d)
| order by TimeGenerated descここで件数がゼロの場合、すぐに障害と判断せず、次の順に確認します。
| 確認順 | 見る場所 | 判断ポイント |
|---|---|---|
| 1 | Data connectors | コネクタ状態がConnectedになっているか |
| 2 | Content hub | 対象ソリューションが導入済みか |
| 3 | Prerequisites | 権限、APIキー、エージェント、ネットワーク要件を満たすか |
| 4 | 対象テーブル | テーブル名を誤っていないか |
| 5 | 保持・階層化設定 | Lake-onlyにしてAnalytics tierへ入っていない可能性がないか |
| 6 | 時間範囲 | Data lake取り込み待ち、遅延、UTC時刻のずれがないか |
開発者はAPIと自動化の差分を確認する
開発者や自動化担当者は、Defenderポータル移行に伴うAPIとインシデント項目の差分に注意が必要です。Microsoftは、統合されたインシデントやアラートを扱う場合、Microsoft Graph REST API v1.0の利用を推奨しています。一方で、分析ルールや自動化ルールなどMicrosoft Sentinelリソースへの操作には、引き続きMicrosoft Sentinel APIが利用されます。(Microsoft Learn)
SecurityInsights APIでMicrosoft Sentinelインシデントを処理している場合は、レスポンス本文の変更により、自動化条件やトリガー条件を更新する必要がある可能性があります。たとえば、Defenderポータルではインシデントプロバイダー名がMicrosoft XDRになり、リンク項目もproviderIncidentUrlなどの扱いを確認する必要があります。(Microsoft Learn)
自動化で確認すべきポイント
| 対象 | 確認内容 | 推奨対応 |
|---|---|---|
| Logic Apps Playbook | インシデント説明、タイトル、プロバイダー名に依存していないか | 分析ルール名、タグ、重大度など安定した条件へ変更する |
| ServiceNowなどのチケット連携 | インシデントURLや説明欄を参照していないか | providerIncidentUrlなど移行後の項目を検証する |
| KQLベースの検知 | XDR connector移行後もフィールドが存在するか | スキーマ差分をテスト環境で確認する |
| API連携 | SecurityInsights APIとMicrosoft Graph APIの使い分け | 統合インシデント・アラートはGraph API中心に設計する |
| 自動化ルール | Incident provider条件、Description条件を使っていないか | 移行後に動作しない条件を洗い出す |
Defenderポータル移行後は、既存インシデント名が相関エンジンによって変更される可能性があるため、Microsoftは自動化ルールの条件にインシデントタイトルを使わず、分析ルール名やタグを使うことを推奨しています。また、SecurityIncidentテーブルのDescriptionフィールドが含まれなくなるため、説明欄を条件にしている自動化は見直しが必要です。(Microsoft Learn)
展開時のおすすめ順序
本番環境でいきなり全コネクタを有効化すると、ログ量、コスト、誤検知、既存自動化への影響を同時に抱えることになります。展開は次の順番で進めると、安全に移行できます。
| フェーズ | 実施内容 | 成功基準 |
|---|---|---|
| 棚卸し | 既存コネクタ、テーブル、分析ルール、Workbook、Playbookを一覧化 | どのログが何に使われているか説明できる |
| 設計 | primary workspace、保持期間、Data lake活用方針を決める | 検知用ログと長期保管ログが分類されている |
| 検証 | 重要コネクタを1つずつ有効化し、KQLで確認 | Data receivedと対象テーブルの件数が一致傾向にある |
| 差分確認 | XDR connector、スキーマ、API、自動化を確認 | 既存クエリとチケット連携が動作する |
| 運用移行 | 手順書、教育資料、SOCフローをDefenderポータル前提に更新 | アナリストがAzureポータルなしで初動対応できる |
| 継続改善 | 誤検知、ログ量、保持期間、UEBA結果を定期レビュー | コストと検知品質のバランスが取れている |
特に、Microsoft Defender XDRのイベントテーブルは種類が多く、DeviceEvents、EmailEvents、IdentityLogonEvents、CloudAppEvents、AlertInfo、AlertEvidenceなど、用途に応じて有効化対象を選ぶ必要があります。必要なテーブルを絞らずに有効化すると、取り込み量と調査対象が急増し、SOCの運用負荷が上がる可能性があります。(Microsoft Learn)
管理者が今すぐ確認すべきチェックリスト
最後に、Microsoft Defender管理者が今日から確認すべき項目を整理します。
| チェック | 確認すること |
|---|---|
| Azureポータル依存 | Microsoft Sentinelの運用がAzureポータル前提になっていないか |
| Defenderポータル接続 | Microsoft SentinelワークスペースがDefenderポータルへ接続済みか |
| 権限 | Sentinel Reader、Sentinel Contributor、Owner、Security administratorの付与範囲 |
| Content hub | 必要なソリューションとコネクタがインストール済みか |
| コネクタ状態 | Connected表示、Data receivedグラフ、対象テーブルのKQL確認 |
| 保持設定 | Analytics tier、Data lake tier、Lake-onlyの使い分け |
| UEBA | 対応コネクタで有効化すべきテーブルがあるか |
| XDR connector | スタンドアロンコネクタとの差分、重複インシデント防止設定 |
| 分析ルール | KQLのフィールド名、ProviderName、テーブル名が移行後も有効か |
| 自動化 | Logic Apps、チケット連携、API、インシデントタイトル依存の条件 |
| サポート | コネクタごとのSupported byを確認しているか |
まず着手すべきなのは、コネクタ一覧、取り込みテーブル、分析ルール、自動化ルールの棚卸しです。その上で、Azureポータル前提の運用をDefenderポータル前提へ移し、重要なデータソースから順に接続、保持、UEBA、検知ルールを確認していくのが現実的です。Microsoft Sentinelのデータコネクタ設定は、ログを入れる作業ではなく、Microsoft Defenderを中心にした統合セキュリティ運用の入口と考えるべきです。
コメント