Microsoft Sentinel data connectorsの2026年4月更新で最初に押さえるべき点は、「新しいコネクタを探す」よりも先に、既存の取り込み経路・保持設計・ポータル移行を棚卸しする必要があることです。特に、従来のHTTP Data Collector APIを使うデータソースは2026年9月14日以降のサポート終了に備え、Logs Ingestion APIまたはCodeless Connector Frameworkへの移行計画を立てる必要があります。Microsoft公式の英語版「Microsoft Sentinel data connectors」は2026年4月22日に更新されており、データ取り込み、Data Lake、Defenderポータル移行、サポート種別を運用目線で見直すきっかけになります。(Microsoft Learn)
この記事では、security admins、identity teams、compliance teamsが何を確認し、どの順番で対応すべきかを実務向けに整理します。
Microsoft Sentinelの最新動向: Microsoft Sentinel data connectorsで何が変わったか
Microsoft Sentinel data connectorsは、Microsoft Sentinelにログやセキュリティデータを取り込むための入口です。Microsoft公式ドキュメントでは、Microsoft Defender XDR、Office 365、Microsoft Entra ID、Microsoft Defender for Identity、Microsoft Defender for Cloud AppsなどのMicrosoftサービスとの連携に加え、Syslog、Common Event Format、REST APIを使ったMicrosoft以外の製品との接続も説明されています。(Microsoft Learn)
今回の更新を「新しいコネクタの追加一覧」として読むと、本質を見落とします。実務上のポイントは、次の4つです。
| 確認ポイント | 影響を受けやすい担当者 | すぐ確認すべきこと |
|---|---|---|
| HTTP Data Collector APIのサポート終了 | security admins、SOC運用担当 | Azure Functionsベースの独自連携や古いカスタムログ取り込みが残っていないか |
| Defenderポータルへの移行 | security admins、運用設計担当 | Sentinelの運用手順、権限、画面キャプチャ、教育資料を更新できるか |
| Microsoft Sentinel Data Lakeの保持・削除設計 | compliance teams、データ管理担当 | GDPR、保持期間、Purge、Purview設定との関係を誤解していないか |
| Content Hubとソリューション単位の管理 | security admins、identity teams | 必要なコネクタが単体ではなくソリューションとして導入・更新されているか |
特に重要なのは、データコネクタが単なる「接続設定」ではなく、検知ルール、ハンティングクエリ、ワークブック、プレイブック、コンプライアンス要件に直結することです。取り込み方式を変えると、テーブル名、スキーマ、KQL、アラート条件、保持期間まで見直しが必要になる場合があります。
更新ポイントの最重要項目はHTTP Data Collector APIからの移行
Microsoft公式ドキュメントでは、2026年9月14日以降、従来のHTTP Data Collector APIはサポートされなくなると説明されています。HTTP Data Collector APIを使うデータソース、カスタム統合、コネクタは、取り込み中断を避けるためにLogs Ingestion APIまたはCodeless Connector Frameworkへの移行を計画する必要があります。(Microsoft Learn)
ここで注意したいのは、「APIのエンドポイントを差し替えれば終わり」ではない点です。Microsoftの移行ガイドでは、Logs Ingestion APIはData Collection Rule、Data Collection Endpoint、RBAC、変換処理などを使う構成であり、従来のHTTP Data Collector APIよりもスキーマ管理や変換の考え方が明確になります。(Microsoft Learn)
既存環境で確認すべき対象
次のような構成がある場合は、移行対象になる可能性が高いです。
| 既存構成 | 確認すべき理由 | 推奨される見直し |
|---|---|---|
| Azure Functionsで外部APIを定期取得し、Log Analyticsに送信している | 古いData Collector APIを使っている可能性がある | Logs Ingestion APIまたはCCFで再設計する |
| 独自のPowerShellやPythonスクリプトでカスタムログを送っている | 認証方式や送信先APIが古い可能性がある | DCR、DCE、マネージドID、Entraアプリ認証を確認する |
| サードパーティ製品の古いSentinel連携テンプレートを使っている | コネクタのサポート元がMicrosoft以外の場合がある | コネクタページのSupported byを確認する |
| カスタムテーブルに分析ルールやブックを多数紐づけている | 移行後にテーブル名や列名が変わると検知が止まる | KQL、Workbook、Playbook、Parserを棚卸しする |
Microsoftの移行情報では、Sentinelコネクタが従来のHTTP Data Collector APIからCCFへ移行する流れがあり、移行時に新しい、または更新されたテーブル名やスキーマが発生する可能性があると説明されています。古いAzure Functionsベースのコネクタと新しいCCFコネクタが一時的に併存する場合もあるため、重複取り込みや検知漏れに注意が必要です。(Microsoft Learn)
移行時に見落としやすい作業
移行で失敗しやすいのは、取り込み処理だけを更新し、周辺コンテンツを放置するケースです。
たとえば、旧コネクタではCustomProduct_CLというテーブルにログが入っていたのに、新しいCCFベースのコネクタでは別のテーブル名や列構成になる場合があります。このとき、分析ルールが旧テーブルを参照したままだと、ログは入っているのにアラートが発火しない状態になります。
移行前後では、少なくとも次を確認してください。
- 取り込み先テーブル名
- TimeGeneratedの値が期待どおりか
- 主要な列名と型
- 既存KQLの参照先
- 分析ルールのスケジュールと閾値
- Workbookのグラフ表示
- Playbookで参照しているフィールド
- ParserやASIMマッピングの有無
- 旧コネクタとの二重取り込み
- データ保持期間とコスト
検証用のKQLは、まず複雑なハンティングクエリではなく、件数と時間帯を確認する単純なものから始めるのが安全です。
<対象テーブル名>
| summarize Count = count() by bin(TimeGenerated, 1h)
| order by TimeGenerated descCEF機器のようにCommonSecurityLogへ取り込む構成では、送信元ベンダーや製品名の偏りも確認します。
CommonSecurityLog
| summarize Count = count() by DeviceVendor, DeviceProduct
| order by Count descMicrosoft Entra IDのサインインログを扱う場合は、identity teamsと一緒に、認証イベントが期待どおり流れているかを確認します。
SigninLogs
| summarize Count = count() by ResultType, bin(TimeGenerated, 1h)
| order by TimeGenerated descDefenderポータル前提の運用へ切り替える
Microsoft公式ドキュメントでは、2027年3月31日以降、Microsoft SentinelはAzure portalでサポートされず、Microsoft Defenderポータルでのみ利用可能になると説明されています。Azure portalでSentinelを運用している場合は、Defenderポータルへの移行計画を立てる必要があります。(Microsoft Learn)
これは画面の場所が変わるだけではありません。セキュリティ運用の手順書、権限設計、問い合わせ対応、教育資料、監査証跡の確認方法に影響します。
データコネクタ運用で変わる確認ポイント
Microsoft Sentinelでデータコネクタを有効化するには、対象ソリューションをContent Hubから導入し、データコネクタ画面でコネクタを開き、前提条件を確認して設定する流れになります。Microsoft公式の接続手順では、Defenderポータルでは「Microsoft Sentinel > Configurations > Data connectors」から操作する流れが示されています。(Microsoft Learn)
Azure portal中心の運用を続けている組織では、次を早めに更新してください。
| 更新対象 | 具体的な見直し内容 |
|---|---|
| 運用手順書 | Azure portalの画面遷移をDefenderポータルの画面遷移に置き換える |
| 権限設計 | Sentinel操作、Content Hub、Log Analytics、Defenderポータルの権限を整理する |
| 障害対応フロー | データが入らない場合に、どの画面で状態を見るかを明確にする |
| 監査・内部統制資料 | 誰がコネクタを有効化、変更、削除できるかを説明できるようにする |
| 教育資料 | SOCアナリストやヘルプデスクが古い画面を参照しないようにする |
security adminsは、移行期限の直前に画面変更をまとめて対応するのではなく、今のうちにDefenderポータルで日常運用を試すべきです。特にグローバルSOCでは、地域ごとに操作手順が分かれるとインシデント対応の初動が遅れます。
Microsoft Sentinel Data Lakeの保持と削除をコンプライアンス視点で見直す
2026年4月更新で見逃せないのが、Microsoft Sentinel Data Lakeに関するデータ管理上の注意点です。公式ドキュメントでは、分析層でPurge機能を使ってGDPR関連の権利を行使できても、それはData Lake層には影響しないと説明されています。また、Sentinel Data Lakeでは特定レコードを個別にPurgeできず、ソースや分析層で削除されたデータでも、定義された保持期間に従ってData Lakeに保持されるとされています。(Microsoft Learn)
さらに、Purview設定の変更はSentinel Data Lakeに格納されたデータへ影響しないこと、Data Lakeのストレージ場所はテナント管理者が選択し、ソースサービスの主な保存場所と異なる可能性があることも明記されています。(Microsoft Learn)
compliance teamsが確認すべき論点
| 論点 | 確認すべき質問 | 失敗しやすい誤解 |
|---|---|---|
| GDPRと削除要求 | 分析層とData Lake層の削除・保持の扱いを分けて説明できるか | 「Purgeすれば全層から消える」と考える |
| 保持期間 | どのログを何年保持する必要があるか | すべてのログを長期保持してコストとリスクが増える |
| Purviewとの関係 | Purview設定変更がSentinel Data Lakeに影響しない前提で設計しているか | Purview側の設定でSentinel Data Lakeも自動制御されると考える |
| 保存場所 | テナント管理者が選んだData Lakeの保存場所を把握しているか | ソースサービスと同じ地域に保存されると決めつける |
| 国・地域要件 | US Governmentクラウドなどで機能差を確認しているか | Commercialクラウドの情報をそのまま適用する |
データ保持は、後から「長すぎた」「短すぎた」と気づいても修正が難しい領域です。特に個人情報、認証ログ、管理者操作ログ、端末ログ、メール関連ログをSentinel Data Lakeへ送る場合は、security adminsだけで決めず、compliance teamsと法務・監査担当を交えて保持方針を決めるべきです。
Microsoftの接続手順では、Data Lakeを利用している場合、データコネクタ単位で保持と階層化を構成でき、Data Lake層では最大12年保存できると説明されています。また、既定では分析層へ送信され、Data Lake層にもミラーされるため、必要に応じて分析層とData Lake層の保持設定を分ける設計が重要です。(Microsoft Learn)
Content Hubとソリューション単位でコネクタを管理する
Microsoft Sentinel data connectorsは、単体の接続設定としてだけでなく、Microsoft Sentinelソリューションの一部として提供される場合があります。公式ドキュメントでは、ソリューションにはデータコネクタ、ワークブック、分析ルール、プレイブックなどのセキュリティコンテンツが含まれ、データコネクタを追加するにはContent Hubから関連ソリューションをインストールすると説明されています。(Microsoft Learn)
この設計を理解していないと、「データコネクタ画面で検索しても見つからない」という問題が起きます。実際には、コネクタが存在しないのではなく、関連ソリューションがContent Hubに未導入、または未更新の可能性があります。
実務での確認手順
| 手順 | 操作 | 確認ポイント |
|---|---|---|
| 1 | Content Hubで対象製品名やサービス名を検索する | ソリューションがインストール済みか |
| 2 | ソリューションの内容を確認する | データコネクタ、分析ルール、Workbook、Playbookが含まれるか |
| 3 | Data connectors画面でコネクタを開く | 前提条件、権限、接続状態を確認する |
| 4 | 取り込み先テーブルを確認する | 想定したテーブルにログが入っているか |
| 5 | 関連する分析ルールを有効化する | 取り込んだログが検知に使われているか |
| 6 | サポート種別を確認する | Microsoft、パートナー、コミュニティのどれが保守するか |
identity teamsがMicrosoft Entra IDやDefender XDR関連のデータを扱う場合も、単にログを取り込むだけでなく、インシデント、アラート、ユーザー行動分析、条件付きアクセス調査とのつながりを意識する必要があります。ログは入っているが検知や調査に使われていない状態は、コストだけが発生する典型的な失敗パターンです。
接続方式別に見るMicrosoft Sentinel data connectorsの使い分け
Microsoft Sentinel data connectorsには、サービス間連携、エージェントベース連携、カスタム連携など複数の方式があります。公式ドキュメントでは、MicrosoftサービスやAWS向けのサービス間連携、Azure Monitor Agentを使ったSyslog/CEF連携、REST APIやCCF、Logs Ingestion APIを使ったカスタムコネクタ作成が説明されています。(Microsoft Learn)
| 接続方式 | 向いているデータソース | 主な確認ポイント |
|---|---|---|
| サービス間連携 | Microsoft Defender XDR、Microsoft Entra ID、Microsoft 365、AWSなど | 権限、テナント、対象サービス、取り込み範囲 |
| Syslog/CEF via AMA | ファイアウォール、プロキシ、VPN、IDS/IPSなど | AMA、Linuxログフォワーダー、UDP/TCP、CommonSecurityLog |
| Custom logs via AMA | サーバー上のアプリケーションログ | ファイルパス、形式、カスタムテーブル、保持期間 |
| Logs Ingestion API | 独自アプリ、外部SaaS、スクリプト連携 | DCR、DCE、Entra認証、スキーマ、変換 |
| Codeless Connector Framework | API提供のあるセキュリティ製品との標準化連携 | Content Hub、DCR/DCE、コネクタ保守元、テーブル変更 |
| Logstash | 既存のログパイプラインがある環境 | フィルター、転送遅延、重複取り込み、運用担当範囲 |
選定基準は「接続できるか」ではなく、「継続運用できるか」です。たとえば、短期的にはAzure FunctionsでAPIを叩いてカスタムテーブルへ入れる方法が早く見えても、長期的にはCCFやLogs Ingestion APIを使ったDCRベースの設計のほうが、スキーマ管理、変換、権限、サポートの面で扱いやすい場合があります。
サポート種別を確認し、障害時の責任分界点を明確にする
Microsoft Sentinelのデータコネクタは、Microsoftだけでなく、パートナーやコミュニティによって作成されるものもあります。公式ドキュメントでは、各データコネクタにはMicrosoft-supported、Partner-supported、Community-supportedのようなサポート種別があり、パートナーサポートの場合は指定されたサポート連絡先へ問い合わせると説明されています。(Microsoft Learn)
これは、障害対応で非常に重要です。ログが入らない場合、原因はMicrosoft Sentinel側とは限りません。外部製品のAPI制限、認証トークン期限、ベンダー側の仕様変更、コネクタ実装の不具合、ネットワーク経路、ログフォワーダーの停止など、責任分界点が複数に分かれます。
運用台帳に残すべき情報
| 項目 | 記録例 |
|---|---|
| コネクタ名 | Microsoft Defender XDR、Syslog via AMA、特定SaaSコネクタなど |
| サポート種別 | Microsoft-supported、Partner-supported、Community-supported |
| サポート連絡先 | Microsoftサポート、ISV、MSSP、GitHub issueなど |
| データソース所有者 | IDチーム、ネットワークチーム、クラウド基盤チームなど |
| 認証方式 | マネージドID、Entraアプリ、APIキー、証明書など |
| 取り込み先テーブル | SigninLogs、CommonSecurityLog、カスタムテーブルなど |
| 関連コンテンツ | 分析ルール、Workbook、Playbook、Parser |
| 最終検証日 | 接続テストやKQL確認を実施した日付 |
グローバル組織では、タイムゾーンや地域別の運用窓口も記録しておくと、夜間や休日のインシデント対応で迷いません。
対象チーム別のアクション
security adminsがやるべきこと
security adminsは、まずデータコネクタの棚卸しを行い、古いAPIや古いポータル前提の運用を洗い出します。
優先順位は次の順番が現実的です。
| 優先度 | 対応内容 | 理由 |
|---|---|---|
| 高 | HTTP Data Collector API利用有無を確認 | 2026年9月14日以降のサポート終了に直結する |
| 高 | Defenderポータルでの操作手順を整備 | 2027年3月31日以降のAzure portal非サポートに備える |
| 中 | Content Hubのソリューション更新状況を確認 | コネクタや関連ルールが古い可能性がある |
| 中 | サポート種別と問い合わせ先を台帳化 | 障害時の切り分けを速くする |
| 中 | 旧コネクタと新コネクタの重複取り込みを確認 | コスト増と検知ノイズを防ぐ |
identity teamsがやるべきこと
identity teamsは、Microsoft Entra ID、Defender for Identity、Microsoft Defender XDRなど、ID関連データの取り込み範囲を確認します。
特に確認すべきなのは、サインインログ、リスクイベント、ID保護、条件付きアクセス、特権アカウント操作に関するログです。ID関連のログは、ゼロトラスト、内部不正検知、アカウント侵害調査に直結します。取り込み設定を変更した後は、SigninLogsや関連テーブルで件数だけでなく、失敗ログ、成功ログ、リスク判定、管理者操作が期待どおり見えるか確認してください。
また、UEBAを使う組織では、対応コネクタからUEBAを有効化できるかも確認対象です。Microsoft公式手順では、Defenderポータルのデータコネクタ画面から、UEBA対応コネクタのAdvanced optionsで対象テーブルを有効化する流れが説明されています。(Microsoft Learn)
compliance teamsがやるべきこと
compliance teamsは、ログの保持期間、削除要求、保存場所、監査要件を確認します。
特にMicrosoft Sentinel Data Lakeを使う場合、分析層のPurgeとData Lake層の保持は同じではありません。個人データを含む可能性のあるログを長期保持する場合は、保持目的、保持期間、アクセス権限、監査ログ、国・地域要件を明確にしてください。
実務では、次のような分類表を作ると判断しやすくなります。
| データ種別 | 例 | 推奨される確認 |
|---|---|---|
| IDログ | サインイン、MFA、条件付きアクセス | 個人情報、保持期間、調査用途 |
| 端末ログ | Defender for Endpoint、EDRイベント | 長期調査の必要性、データ量 |
| ネットワークログ | Firewall、Proxy、VPN | 高容量ログの保持コスト、個人識別性 |
| メール・コラボレーションログ | Defender for Office 365、Microsoft 365関連 | メッセージ追跡、内部監査、法的要件 |
| クラウド操作ログ | Azure、AWS、管理者操作 | 特権操作監査、証跡保持 |
既存環境の棚卸し手順
Microsoft Sentinel data connectorsの更新を受けて、まずは次の順番で棚卸しを行うと効率的です。
| 手順 | 作業 | 完了条件 |
|---|---|---|
| 1 | Data connectors画面でインストール済み、使用中のコネクタを一覧化する | コネクタ名、状態、サポート種別が分かる |
| 2 | Content Hubで関連ソリューションを確認する | 未導入、未更新のソリューションが分かる |
| 3 | 取り込み方式を分類する | サービス間連携、AMA、CEF、Logs Ingestion API、CCF、旧APIが分かる |
| 4 | HTTP Data Collector APIの利用を調査する | 移行対象の有無が分かる |
| 5 | 取り込み先テーブルとKQL依存関係を確認する | 分析ルール、Workbook、Playbookの影響範囲が分かる |
| 6 | Data Lake保持設定を確認する | 分析層とData Lake層の保持期間が分かる |
| 7 | Defenderポータルで運用手順を再確認する | 旧Azure portal前提の手順が残っていない |
| 8 | 移行テストを行う | 新旧取り込みの差分、重複、検知漏れが確認済み |
棚卸しでは、単に「接続済み」と表示されているかを見るだけでは不十分です。接続済みでも、必要なデータ型が無効、ログ量が極端に少ない、KQLが古い、分析ルールが無効、保持期間が誤っているケースがあります。
失敗しやすいポイントと回避策
ログは入っているのに検知されない
原因として多いのは、テーブル名や列名の変更です。特に旧コネクタからCCFベースの新コネクタへ移行する場合、既存の分析ルールやWorkbookが旧スキーマを参照していると検知が止まります。
回避策は、移行前に依存するKQLを検索し、対象テーブル名と列名を一覧化することです。移行後は、件数確認だけでなく、実際の分析ルールが動くかを検証してください。
旧コネクタと新コネクタで二重取り込みになる
移行期間中に古いAzure Functionsベースの連携と新しいコネクタを同時に動かすと、同じイベントが二重に取り込まれる場合があります。これはコスト増、アラート重複、インシデント件数の水増しにつながります。
回避策は、並行稼働期間を明確にし、同一イベントの重複判定をKQLで確認することです。
Data Lakeの削除仕様を誤解する
分析層でPurgeできるからData Lake層でも同じように削除できる、と考えるのは危険です。公式ドキュメントでは、Sentinel Data Lakeから特定レコードをPurgeできないことが説明されています。(Microsoft Learn)
回避策は、Data Lakeへ送る前に、保持期間、データ分類、個人情報の扱い、アクセス権限を決めることです。
サポート元を確認していない
障害が発生してから、コネクタがMicrosoft-supportedではなくPartner-supportedやCommunity-supportedだったと分かると、対応が遅れます。
回避策は、運用台帳にサポート種別と問い合わせ先を明記することです。特にMSSPやグローバルSOCでは、誰が一次切り分けを行い、誰がベンダーに問い合わせるかを事前に決めておく必要があります。
Azure portal前提の教育資料が残る
2027年3月31日以降のAzure portal非サポートを考えると、古い画面を前提にした手順書や研修資料はリスクになります。(Microsoft Learn)
回避策は、Defenderポータルでの操作を標準手順にし、Azure portalの手順は段階的に廃止することです。
まず次にやるべきこと
Microsoft Sentinel data connectorsの2026年4月更新で、管理者がすぐに取るべき行動は明確です。
まず、現在有効なデータコネクタを一覧化し、HTTP Data Collector APIを使う古い連携がないか確認してください。次に、Content Hubで関連ソリューションの導入・更新状況を確認し、Defenderポータルでの操作手順に切り替えます。Data Lakeを使っている、または今後使う予定がある場合は、分析層とData Lake層の保持・削除・保存場所をcompliance teamsと一緒に確認してください。
この更新は、単なるドキュメント更新ではなく、Sentinel運用を「接続できているか」から「継続的に検知・調査・監査できるか」へ見直すタイミングです。特に2026年9月14日のHTTP Data Collector APIサポート終了、2027年3月31日のAzure portal非サポートは、後回しにすると運用リスクになります。今日の時点で、コネクタ台帳、移行対象、保持設計、Defenderポータル運用の4点を確認することから始めましょう。
コメント