Microsoft Sentinel データコネクタの2026年4月更新でまず押さえるべき答えは、「コネクタを有効化するだけ」では不十分になりつつあるという点です。2026年4月22日に更新された Microsoft Learn の「Connect data sources to Microsoft Sentinel by using data connectors」では、Content Hubからのソリューション導入、Defender portalでの設定、データ保持と階層化、UEBAの有効化、接続後の確認までを一連の運用として扱っています。特に security admins、identity teams、compliance teams は、ログを入れる場所だけでなく、「どのデータをリアルタイム分析に使うか」「どのデータを長期保管するか」「誰がコネクタを保守するか」まで整理しておく必要があります。(Microsoft Learn)
2026年4月22日版でまず確認すべきポイント
今回の公式ドキュメントは、Microsoft Sentinel にデータソースを接続する基本手順を説明する記事ですが、実務上は次の5点が重要です。
| 確認ポイント | 実務での意味 |
|---|---|
| Defender portal前提の運用 | Azure portalだけで手順を覚えるのではなく、Defender portalでのメニュー構成に慣れる必要がある |
| Content Hubからのソリューション導入 | コネクタが見つからない場合、Data connectors画面ではなくContent Hubの導入状態を確認する |
| データ保持と階層化 | Analytics tierとData lake tierを使い分け、コストと検知要件を両立する |
| UEBA連携 | サポート対象コネクタでは、ユーザーやエンティティの異常検知をコネクタ設定から有効化できる |
| サポート担当の確認 | Microsoft製、パートナー製、コミュニティ製で問い合わせ先や保守責任が異なる |
ポイントは、Microsoft Sentinel のデータコネクタ設定が「ログを流し込む作業」から「検知・調査・保管・責任分界を設計する作業」に変わっていることです。
Microsoft Sentinelの最新動向: データ接続はDefender portal中心へ
Microsoft Sentinel は、Defender portalでの統合セキュリティ運用に軸足を移しています。公式ドキュメントでは、2027年3月31日以降、Microsoft Sentinel は Azure portal でサポートされなくなり、Microsoft Defender portalでのみ利用できると案内されています。すでにAzure portal中心で運用している組織は、手順書、教育資料、運用フローをDefender portal基準に更新する必要があります。(Microsoft Learn)
Defender portalでは、Microsoft Sentinelのデータコネクタは次の場所から開きます。
Microsoft Sentinel > Configuration > Data connectorsAzure portalでは、従来どおりMicrosoft Sentinelの「Configuration」配下からData connectorsを開きます。ただし、今後の移行を考えると、新規の手順書や社内ナレッジはDefender portalの表記を主にしたほうが安全です。
Azure portal利用中のチームが今すぐ見直すべきもの
既存環境でAzure portalを使っている場合、以下を棚卸ししてください。
| 見直すもの | 確認内容 |
|---|---|
| 運用手順書 | Data connectors、Content Hub、Advanced hunting、Tablesの画面遷移がDefender portal基準になっているか |
| 権限設計 | SOC担当、ID管理担当、監査担当がDefender portalで必要な画面にアクセスできるか |
| 教育資料 | 新任者向けの画面キャプチャがAzure portalのまま残っていないか |
| 自動化・問い合わせ導線 | コネクタ障害時に、どの画面で状態とサポート先を確認するか明記されているか |
特にグローバル拠点で運用している組織では、地域ごとにAzure portal手順とDefender portal手順が混在しやすくなります。移行期は「どのポータルで操作する手順なのか」を明記しないと、障害対応時に確認が遅れます。
データコネクタの基本手順は「Content Hub導入」から始まる
Microsoft Sentinelにデータソースを接続するには、対象コネクタをインストールして設定する必要があります。公式手順では、前提としてMicrosoft Sentinelワークスペースへの読み取り・書き込み権限が必要で、さらに対象データコネクタを含むソリューションをContent Hubからインストールしておく必要があります。(Microsoft Learn)
実務では、次の流れで確認すると迷いにくくなります。
| 手順 | 作業内容 | つまずきやすい点 |
|---|---|---|
| 事前確認 | ワークスペースへの読み取り・書き込み権限を確認する | 閲覧権限だけでは設定変更できない |
| Content Hub確認 | 対象コネクタを含むソリューションをインストールする | Data connectors画面で検索しても出てこない場合がある |
| コネクタ選択 | Data connectorsで対象コネクタを検索する | 名称が製品名、サービス名、ログ種別で異なる場合がある |
| Connector pageを開く | Open connector pageから設定画面へ進む | 一覧画面だけでは詳細な前提条件を確認できない |
| 前提条件確認 | コネクタ固有の権限、API、エージェント、ネットワーク要件を確認する | ID権限や外部サービス側の設定不足で接続に失敗しやすい |
| 設定適用 | Configurationsの手順に従って接続する | コネクタごとに必要な設定が異なる |
| 受信確認 | Data receivedグラフ、接続状態、KQLクエリで確認する | 有効化直後にデータが出ないことを障害と誤認しやすい |
Content Hubは、Microsoft Sentinelの組み込みコンテンツを探し、ソリューションやスタンドアロンコンテンツを管理する中心的な場所です。ソリューションには、データコネクタだけでなく、分析ルール、ワークブック、プレイブックなど関連コンテンツが含まれる場合があります。(Microsoft Learn)
「コネクタが見つからない」ときの確認順
Data connectorsで目的のコネクタが見つからない場合、いきなり権限や障害を疑う前に、次の順番で確認してください。
| 確認順 | 見る場所 | 判断基準 |
|---|---|---|
| 1 | Content Hub | 対象ソリューションが未インストールではないか |
| 2 | Data connectors | コネクタ名、製品名、サービス名で検索しているか |
| 3 | コネクタ参照ページ | 対象コネクタが公式の一覧に含まれているか |
| 4 | サポート種別 | Microsoft-supported、Partner-supported、Community-supportedのどれか |
| 5 | カスタム接続 | 既存コネクタがない場合、API、Azure Function、Logic App、Logstash、Azure Monitor Agentで代替できるか |
Microsoft Sentinelにはソリューションとして提供されるコネクタ、コミュニティコネクタ、カスタムコネクタがあります。既存のソリューションで接続できない場合は、Codeless Connector Framework、Log Ingestion API、Azure Function、Logic App、Azure Monitor Agent、Logstashなどを使ったカスタム接続も選択肢になります。(Microsoft Learn)
データ保持と階層化は、コネクタ設定時点で考える
2026年4月版で特に実務影響が大きいのが、データ保持と階層化です。Microsoft Sentinel data lakeにオンボードしている場合、データコネクタごとにAnalytics tierとData lake tierの保持設定を考える必要があります。公式ドキュメントでは、データコネクタを有効化すると、既定ではデータがAnalytics tierへ送られ、Data lake tierにもミラーリングされると説明されています。(Microsoft Learn)
Analytics tierは、アラート、ハンティング、ワークブック、Microsoft Sentinelのリアルタイム分析機能に使う領域です。一方、Data lake tierは、長期保管やフォレンジック、履歴分析に向いた低コストの保管領域です。Microsoft Sentinel data lakeでは、セキュリティデータを最大12年まで保持・分析できるとされています。(Microsoft Learn)
Analytics tierとData lake tierの使い分け
| 判断軸 | Analytics tierが向いているデータ | Data lake tierが向いているデータ |
|---|---|---|
| 主な用途 | リアルタイム検知、アラート、ハンティング、ワークブック | 長期保管、監査、履歴調査、低頻度分析 |
| 例 | サインインログ、特権操作ログ、EDRアラート、重要サーバーのイベント | DNSログ、プロキシログ、大量のネットワークログ、長期監査ログ |
| 調査スピード | 高速な対話型調査が必要 | 必要時にKQL jobやNotebookで分析できればよい |
| コスト管理 | 重要データに絞って保持期間を設計する | 大量データを長期保存する場合に有効 |
| 注意点 | 保持期間を延ばすとコストに影響する | リアルタイム分析やアラート用途には向かない |
注意すべきなのは、Data lake tierだけに切り替えると、以後のAnalytics tierへの取り込みが止まる点です。公式手順でも、Data lake tierを選択するとAnalytics tierへの追加取り込みが停止すると説明されています。つまり、コスト削減のために安易にData lake onlyへ変更すると、分析ルールやハンティングで使うはずだったログが見えなくなる可能性があります。(Microsoft Learn)
保持設定のおすすめ判断基準
セキュリティ管理者とコンプライアンス担当は、ログごとに次のように分類すると設計しやすくなります。
| ログの種類 | 推奨方針 | 理由 |
|---|---|---|
| 検知に直結するログ | Analytics tierで保持 | アラート、ハンティング、インシデント調査に使う |
| ID・認証系ログ | Analytics tierを基本に、必要に応じてData lakeへ長期保持 | アカウント侵害調査や内部不正調査で過去データが必要になりやすい |
| 大量のネットワークログ | 重要な期間だけAnalytics tier、長期分はData lake tier | コストが膨らみやすいため |
| 監査証跡 | Data lake tierで長期保持を検討 | リアルタイム検知より保存義務や後追い調査が主目的 |
| 低価値・重複ログ | 取り込み自体を見直す | Sentinelに入れても調査価値が低いデータはコスト要因になる |
保持期間は「長ければ安全」ではありません。検知に必要な期間、監査で必要な期間、調査時に参照する期間を分けて考えることが重要です。
UEBAはIDチームと一緒に設計する
User and Entity Behavior Analytics、つまりUEBAは、接続されたデータソースのログやアラートを分析し、ユーザー、ホスト、IPアドレス、アプリケーションなどのエンティティの通常行動を基準化して、異常な行動を検出する機能です。公式ドキュメントでは、サポート対象のデータコネクタからDefender portal上でUEBAを有効化できる手順が示されています。(Microsoft Learn)
UEBAはSOCだけで完結する機能ではありません。特にidentity teamsと連携し、どのIDデータを同期するか、どのサインインログを対象にするか、オンプレミスActive DirectoryやMicrosoft Entra IDとの関係を整理する必要があります。
UEBAを有効化すべき典型シーン
| シーン | UEBAを検討すべき理由 |
|---|---|
| 特権IDの利用監視 | 普段と違う場所、時間、端末からの操作を見つけやすくなる |
| 内部不正の兆候把握 | 大量アクセス、異常なリソース操作、通常業務と異なる行動の調査に使える |
| 侵害アカウントの早期検知 | サインイン、端末、IP、クラウド操作の文脈を組み合わせて確認できる |
| グローバル拠点のID監視 | 地域や勤務時間の違いを踏まえた行動分析に役立つ |
| コンプライアンス調査 | ユーザー行動の履歴確認や説明責任の補強に使える |
UEBAの有効化自体に特別なライセンスは不要とされていますが、UEBAによって新しいテーブルにデータが生成・保存されるため、追加のデータ保存コストが発生する可能性があります。導入時は「有効化するかどうか」だけでなく、「どのテーブルが増えるか」「保持期間をどうするか」まで確認してください。(Microsoft Learn)
接続後の確認はAdvanced huntingとData lake explorerも見る
データコネクタを有効化した後は、関連するテーブルスキーマにデータがストリーミングされます。Defender portalではAdvanced hunting、Azure portalではLogsでクエリを実行できます。また、Data lakeのデータはData lake explorerやKQL queriesから確認できます。(Microsoft Learn)
接続確認では、画面上のConnected表示だけに頼らないことが重要です。実際にKQLで対象テーブルを開き、直近のデータが入っているか、想定したログ種別が欠けていないかを確認します。
接続確認で使う基本的な見方
// 例: Azure Activityログの取り込み確認
AzureActivity
| take 10// 例: 直近24時間の件数確認
AzureActivity
| where TimeGenerated > ago(24h)
| summarize Count=count() by bin(TimeGenerated, 1h)
| order by TimeGenerated desc本番環境では、コネクタごとに「確認用KQL」を手順書に入れておくと、障害時の切り分けが速くなります。たとえば、Microsoft Entra IDサインインログ、Azure Activity、Defender XDR、Syslog、CEFなど、主要コネクタごとに確認クエリを用意しておくと便利です。
データがすぐ出ない場合の判断
公式ドキュメントでは、データコネクタ設定後、取り込みに時間がかかる場合があり、Data lakeへの取り込みには90〜120分かかると説明されています。したがって、設定直後にData lake側で見えないからといって、すぐに障害と判断しないほうがよいでしょう。(Microsoft Learn)
| 状況 | まず確認すること |
|---|---|
| Data connectors画面ではConnectedだがKQLで出ない | テーブル名、時間範囲、ワークスペースを確認する |
| Analytics tierでは見えるがData lakeで見えない | Data lake側の反映待ち時間を考慮する |
| 一部のログ種別だけ出ない | コネクタ設定で対象テーブルやイベント種別を選択し忘れていないか確認する |
| 突然データが止まった | 外部サービス側のAPI権限、証明書、シークレット期限、エージェント状態を確認する |
| 以前の検知ルールが動かない | テーブルをData lake tier onlyに変更していないか確認する |
コネクタのサポート責任を事前に確認する
Microsoft Sentinelのデータコネクタは、Microsoftだけでなく、パートナーやコミュニティによって提供されるものがあります。公式ドキュメントでは、コネクタページの「Supported by」フィールドからサポート連絡先を確認できるとされています。(Microsoft Learn)
これは運用上かなり重要です。障害時に「Microsoftサポートへ問い合わせるべきか」「ベンダーへ問い合わせるべきか」「GitHubのコミュニティIssueを確認すべきか」が分からないと、復旧までの時間が延びます。
| サポート種別 | 実務上の対応 |
|---|---|
| Microsoft-supported | Microsoftサポートの対象。重大障害時の連絡経路を社内手順に明記する |
| Partner-supported | 製品ベンダーやMSSPなど、指定されたサポート先へ問い合わせる |
| Community-supported | 保守保証が限定的な場合がある。重要システムでは採用前にリスク評価する |
特にcompliance teamsが関係するログでは、サポート種別を軽視しないでください。監査に必要なログが取得できなくなった場合、復旧責任や説明責任が曖昧になると、技術問題がガバナンス問題に発展します。
役割別に見る今回の更新ポイント
Security adminsがやるべきこと
Security adminsは、データコネクタの有効化だけでなく、検知ルール、ハンティング、インシデント調査で使うログがAnalytics tierに残っているかを確認してください。Data lake tierへの移行や保持期間変更は、コスト最適化には有効ですが、誤るとリアルタイム検知に影響します。
特に以下を確認します。
| 確認項目 | 具体的な作業 |
|---|---|
| 重要ログの分類 | 検知用、調査用、監査用にログを分類する |
| テーブル保持 | Analytics retentionとTotal retentionを確認する |
| ルール影響 | 既存のanalytics rulesやhunting queriesが参照するテーブルを確認する |
| 接続監視 | コネクタごとの受信停止を検知する運用を作る |
Identity teamsがやるべきこと
Identity teamsは、UEBAとMicrosoft Entra ID関連ログの扱いを重点的に確認してください。ユーザー行動分析は、SOCだけでは正しく設計できません。通常の勤務形態、特権IDの利用ルール、ゲストユーザーの扱い、国・地域ごとのアクセス事情を反映する必要があります。
| 確認項目 | 具体的な作業 |
|---|---|
| IDログの対象 | Sign-in logs、Audit logs、サービスプリンシパル、マネージドID関連ログを確認する |
| UEBA対象 | どのテーブルをUEBAに使うか整理する |
| 特権ID | 管理者アカウントの利用監視ルールと照合する |
| 誤検知対応 | 出張、時差勤務、委託先アクセスなどを踏まえた運用ルールを作る |
Compliance teamsがやるべきこと
Compliance teamsは、Data lake tierの長期保持をどう使うかを確認してください。すべてのログを高コストな分析領域に置く必要はありませんが、監査や規制対応で必要なログは、保持期間、検索方法、アクセス権限を明確にする必要があります。
| 確認項目 | 具体的な作業 |
|---|---|
| 保持要件 | 法令、契約、社内規程に基づく必要期間を整理する |
| 保存場所 | Analytics tierとData lake tierのどちらに置くか決める |
| アクセス制御 | 誰が長期保管データを検索できるか決める |
| 証跡管理 | コネクタ変更、保持期間変更の承認履歴を残す |
よくある失敗と回避策
Data connectors画面だけを見て「コネクタがない」と判断する
コネクタはContent Hubのソリューションに含まれる場合があります。Data connectorsで見つからないときは、まずContent Hubで対象ソリューションが導入済みか確認してください。
Data lake onlyにして検知ルールを止めてしまう
Data lake tierは長期保管に有効ですが、リアルタイム分析向けではありません。アラート、Advanced hunting、analytics rules、custom detection rulesに必要なログはAnalytics tierに残す必要があります。公式のテーブル設定ドキュメントでも、AnalyticsからData lakeへ変更すると、アラートやAdvanced huntingなどAnalyticsデータに依存する機能が停止する可能性があると説明されています。(Microsoft Learn)
UEBAをSOCだけで有効化する
UEBAはIDの文脈が重要です。通常行動を正しく理解しないまま有効化すると、誤検知や見落としが増えます。Identity teamsと連携し、対象データ、特権ID、例外ルールを設計してから有効化してください。
接続後の確認を画面表示だけで終える
Connected表示は重要ですが、最終確認はKQLで行うべきです。対象テーブルに想定したデータが入り、時間範囲、ログ種別、件数が期待どおりか確認してください。
サポート種別を確認せず本番採用する
コミュニティコネクタやパートナーコネクタを本番の重要ログに使う場合、保守体制を事前に確認してください。障害時の連絡先、SLA、変更通知の有無を明確にしてから採用するのが安全です。
実務で使える更新対応チェックリスト
Microsoft Sentinelのデータコネクタ運用を見直す場合、まず次のチェックリストを使ってください。
| チェック | 確認内容 |
|---|---|
| ポータル移行 | Defender portalで同じ作業ができるか確認した |
| 権限 | Sentinelワークスペースへの読み取り・書き込み権限を確認した |
| Content Hub | 必要なソリューションがインストール済みである |
| コネクタ設定 | PrerequisitesとConfigurationsをコネクタごとに確認した |
| 保持設計 | Analytics tierとData lake tierの使い分けを決めた |
| コスト影響 | 保持期間延長やUEBAによる追加データを確認した |
| UEBA | 対象コネクタとテーブルをIDチームと確認した |
| 検証KQL | 接続確認用のKQLを手順書に入れた |
| サポート | Supported byフィールドで問い合わせ先を確認した |
| 変更管理 | 保持期間やtier変更の承認フローを決めた |
まず着手すべきアクション
2026年4月22日版の「Connect data sources to Microsoft Sentinel by using data connectors」を読むうえで、最も重要なのは、データコネクタを単独の設定作業として扱わないことです。Content Hubで導入し、Data connectorsで接続し、保持と階層化を設計し、必要に応じてUEBAを有効化し、Advanced huntingやData lake explorerで確認する。この流れを標準手順にしてください。
すでにMicrosoft Sentinelを運用している場合は、まず既存コネクタを一覧化し、各コネクタについて「目的」「対象テーブル」「Analytics tier保持期間」「Data lake保持期間」「UEBA利用有無」「サポート種別」を1枚の管理表にまとめるのが効果的です。これにより、セキュリティ運用、ID管理、コンプライアンスの各チームが同じ前提でログ戦略を判断できます。
コメント