Microsoft Sentinelのデータコネクタ選定でまず押さえるべき答えは、「使いたい製品名で検索して接続する」だけでは不十分ということです。2026年4月22日に更新されたMicrosoft公式の「Find your Microsoft Sentinel data connector」は、対応コネクタの一覧であると同時に、誰がサポートするか、DCRに対応するか、データレイクだけに取り込めるか、AMAで通信要件を満たせるかを確認するための実務チェックリストとして読むべきページです。公式ページは、サポートされる標準データコネクタと各コネクタのデプロイ手順へのリンクを一覧化しており、英語版は2026年4月22日に最終更新されています。(Microsoft Learn)
特にsecurity admins、identity teams、compliance teamsが見るべきポイントは明確です。セキュリティ管理者は「接続できるか」より「継続運用できるか」を確認し、ID管理チームはMicrosoft Entra IDやUPN、サインインログなどの影響範囲を見ます。コンプライアンス担当は、データの保存先、保持期間、サポート責任、コミュニティコネクタのドキュメント責任を確認する必要があります。
Microsoft Sentinelの最新動向: Find your Microsoft Sentinel data connectorで何が変わったか
今回の更新で注目したいのは、Microsoft Sentinelのデータコネクタが単なる「接続一覧」ではなく、Microsoft Defenderポータル、DCR、Microsoft Sentinel data lake、AMA、非推奨コネクタの移行判断と強く結びついている点です。
Microsoft公式ページでは、Microsoft Sentinelデータコネクタはプレビュー扱いであること、また2027年3月31日以降はAzure portalでMicrosoft Sentinelがサポートされず、Microsoft Defenderポータルのみで利用されることが明記されています。既存環境でAzure portalを中心に運用している場合、コネクタ選定と同時にDefenderポータルへの移行計画も進めるべきです。(Microsoft Learn)
| 確認ポイント | 現場での意味 | 最初に確認すること |
|---|---|---|
| Defenderポータルへの移行 | コネクタ管理、権限、運用画面が将来的にDefenderポータル中心になる | 既存ワークスペースがDefenderポータルに接続済みか |
| Solutions / Community / Customの区別 | サポート責任と導入手順が変わる | コネクタがContent hubのソリューション由来か、Marketplace由来か |
| AMAの通信要件 | Syslog、CEF、Windows系ログの取り込みでネットワーク設定が詰まりやすい | エージェント導入先からHTTPS 443送信が可能か |
| DCR support | 取り込み時変換、フィルター、コスト最適化に関係する | 対象テーブルがWorkspace transform DCRに対応するか |
| Lake-only ingestion | 長期保管・調査用データを分析層に入れず保持できる | アラート検知に使うデータか、保管・調査目的のデータか |
| Deprecated / Legacy | 既存コネクタの放置が障害・重複課金・移行遅れにつながる | 非推奨コネクタを使っていないか |
ここで重要なのは、「新しいコネクタが増えたか」だけを見るのではなく、運用設計の判断材料が一覧の中に埋め込まれていると捉えることです。
データコネクタはSolutions、Community、Customの3種類で考える
Microsoft Sentinelのデータコネクタは、大きく「Solutions」「Community connectors」「Custom connectors」の3つに分けて考えると整理しやすくなります。Microsoft公式ページでは、多くのデータコネクタが分析ルール、ブック、プレイブックなどを含むMicrosoft Sentinel solutionの一部として展開されること、コミュニティ提供のコネクタはAzure Marketplaceで見つかること、未対応のデータソースはカスタムコネクタとして作成できることが説明されています。(Microsoft Learn)
| 種類 | 向いているケース | 注意点 |
|---|---|---|
| Solutions | Microsoft SentinelのContent hubから、検知ルールやブックも含めて導入したい場合 | コネクタ単体ではなく、関連コンテンツも含めて評価する |
| Community connectors | 特定ベンダーやコミュニティが提供する連携を使いたい場合 | ドキュメントや保守の責任が作成元にあるため、サポート窓口を確認する |
| Custom connectors | 自社システム、独自SaaS、未対応ログを取り込みたい場合 | API、認証、DCR、テーブル設計、運用監視を自社で設計する必要がある |
security adminsがまず行うべきことは、対象データソースをこの3分類に振り分けることです。たとえば、AWS、Microsoft Entra ID、Microsoft 365、Defender製品のような主要データソースは標準コネクタやソリューションから探します。一方、自社開発アプリケーションの監査ログや業界特化SaaSのイベントは、Marketplaceのコミュニティコネクタやカスタムコネクタの候補になります。
compliance teamsは、コミュニティコネクタを使う場合に特に注意が必要です。Microsoft公式ページでは、コミュニティデータコネクタのドキュメントはコネクタ作成元の責任とされています。つまり、監査証跡、サポートSLA、仕様変更時の通知、個人データの扱いをMicrosoft公式ドキュメントだけで担保できるとは限りません。(Microsoft Learn)
AMAベースのデータコネクタはポート443送信を最初に確認する
今回の更新ポイントとして実務上もっとも見落としやすいのが、Azure Monitor Agent、つまりAMAベースのデータコネクタの通信要件です。公式ページでは、AMAベースのデータコネクタにはエージェントがインストールされたシステムからのインターネット接続が必要であり、エージェント導入先とMicrosoft Sentinel間の接続を許可するためにポート443の送信を有効にする必要があると説明されています。(Microsoft Learn)
SyslogやCommon Event Format、いわゆるCEFのログ収集では、Microsoft SentinelのContent hubからセキュリティアプライアンスやデバイス向けのソリューションをインストールし、対応するSyslog via AMAまたはCEF via AMAのデータコネクタを構成したうえで、最終的にセキュリティデバイス側の転送設定を行います。(Microsoft Learn)
AMA構成前のチェックリスト
| チェック項目 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| 送信通信 | エージェント導入先からHTTPS 443で外部通信できるか | ファイアウォールやプロキシでブロックされる |
| 名前解決 | Microsoftのエンドポイントを解決できるか | 閉域網やDNS制限で名前解決に失敗する |
| プロキシ | LinuxフォワーダーやWindowsサーバーがプロキシ経由で通信するか | OS側とエージェント側のプロキシ設定がずれる |
| ログ転送経路 | デバイス → Syslog/CEFフォワーダー → AMA → Sentinelの順に流れるか | デバイス側は送っているが、フォワーダーで止まる |
| 重複収集 | 旧エージェントや別経路で同じログを送っていないか | 同一イベントの二重取り込みでコストが増える |
| テーブル確認 | Syslog、CommonSecurityLog、SecurityEventなど期待するテーブルに入るか | コネクタの接続状態だけ見て、実データ確認を忘れる |
実務では、コネクタ画面が「接続済み」に見えても、ログが期待するテーブルに入っていないことがあります。接続後は必ずKQLで最新データを確認してください。たとえばSyslogなら、まずは次のようなクエリで到着状況を見ます。
Syslog
| summarize Count = count() by Computer, bin(TimeGenerated, 1h)
| order by TimeGenerated descCEFの場合は、CommonSecurityLogを確認します。
CommonSecurityLog
| summarize Count = count() by DeviceVendor, DeviceProduct, bin(TimeGenerated, 1h)
| order by TimeGenerated descここでデータが出ない場合は、Microsoft Sentinel側より先に、デバイスの転送先、フォワーダーの受信、AMAの状態、ネットワークの443送信を順に切り分けると早く解決できます。
DCR supportはコスト削減とデータ品質の判断材料になる
Find your Microsoft Sentinel data connectorの一覧で重要なのが「DCR support」です。DCRはData Collection Ruleの略で、Microsoft SentinelではAMAベースのコネクタやLogs ingestion APIのワークフローで使われます。Microsoft公式ドキュメントでは、DCRを使った取り込み時変換により、不要データのフィルター、データの正規化、機密情報のマスク、列追加によるエンリッチメントなどが可能と説明されています。(Microsoft Learn)
DCR supportを確認する意味は、単に「対応しているか」ではありません。次のような運用判断に直結します。
| 判断したいこと | DCR対応がある場合の考え方 | DCR対応がない場合の考え方 |
|---|---|---|
| ノイズを減らしたい | 取り込み前に不要行・不要列を減らせる可能性がある | 取り込み後のKQLや分析ルール側で対応する |
| 個人情報を扱う | 取り込み時に一部項目をマスクできる可能性がある | 保管後のアクセス制御やクエリ制限を重視する |
| クエリ性能を上げたい | 事前にパース済み列を作り、検索しやすくする | クエリ時に毎回parseやextendが必要になる |
| コストを抑えたい | 取り込み対象を絞る設計がしやすい | 保持期間、データレイク、分析ルールの範囲で調整する |
たとえばプロキシログをすべて分析層に取り込むと、データ量が急増します。セキュリティ調査に必要なステータスコード、送信元、宛先、ユーザー、カテゴリだけを活用する設計にできるなら、DCRや取り込み時変換の対応可否は大きな判断材料になります。
ただし、DCR対応は万能ではありません。ログの削りすぎは、インシデント調査時に「なぜこの通信が発生したか」を追えなくする原因になります。コスト削減を目的にフィールドを削る場合は、SOC、ID管理、コンプライアンス担当で「削ってよい列」「必ず残す列」を事前に合意しておくべきです。
Lake-only ingestionは「検知」と「長期保管」を分けるために使う
Microsoft Sentinel data lakeを使う環境では、コネクタ選定時に「Lake-only ingestion」も確認すべきです。Microsoft公式ドキュメントでは、Microsoft Sentinel data lakeにオンボードすると、既存のMicrosoft Sentinelデータコネクタは分析層とデータレイク層の両方にデータを送る構成にでき、必要に応じてデータレイク層のみに取り込むこともできます。データレイク層のみに取り込む設定にすると、分析層への取り込みは停止し、既存の分析層データは保持設定に従って保持されます。(Microsoft Learn)
Microsoft Sentinel data lakeは、長期保存、KQL、Jupyter notebooks、スケールしたセキュリティ分析を目的としたデータ基盤として位置付けられており、Microsoft 365、Microsoft Entra ID、EDR、ファイアウォール、ネットワークログ、IDアクセスログ、DNS、プロキシ、メールテレメトリなど、既存のSentinelデータコネクタと連携できます。(Microsoft Learn)
| 取り込み先 | 向いているデータ | 具体例 |
|---|---|---|
| Analytics tier | アラート、インシデント、即時検知に使うデータ | 高リスクサインイン、EDRアラート、重要サーバーのセキュリティイベント |
| Analytics + Data lake | 検知にも長期調査にも使うデータ | IDログ、クラウド監査ログ、重要SaaSの監査イベント |
| Lake-only ingestion | 長期保管、フォレンジック、傾向分析が主目的のデータ | 大量のプロキシログ、DNSログ、低優先度の操作ログ |
compliance teamsにとってLake-only ingestionは魅力的ですが、注意点もあります。分析層に入れないデータは、通常のアラートやインシデント検知に使えない可能性があります。つまり「保管できている」と「検知できている」は同じではありません。ログごとに、次のように判断すると失敗を防げます。
| 質問 | Analytics tierに入れるべき可能性 |
|---|---|
| そのログをリアルタイム検知に使うか | 高い |
| そのログがインシデントの初動判断に必要か | 高い |
| 監査時に後から検索できればよいか | 低い |
| データ量が大きく、検知ルールではほとんど使わないか | 低い |
| 法規制や社内規程で長期保持が必要か | Lake-onlyまたは長期保持を検討 |
A365 ObservabilityなどAI時代のログもコネクタ選定に入ってくる
今回のコネクタ一覧で目を引く例の一つが、A365 Observabilityです。公式ページでは、A365、AI Foundry、CopilotのAIエージェントテレメトリをMicrosoft Sentinel data lakeに取り込み、ハンティング、グラフ、MCPワークフローでエージェントの動作、ツール利用、実行内容を調査するためのコネクタとして説明されています。(Microsoft Learn)
これは、Microsoft Sentinelのコネクタ選定が従来の「サーバーログ」「ファイアウォールログ」「IDログ」だけではなく、AIエージェントの利用状況や実行履歴にも広がっていることを示しています。グローバル企業では、AI利用の監査、データ持ち出し、権限昇格、プロンプト経由の情報露出などを調査するために、AI関連テレメトリをどこまでSentinelに取り込むかを早めに検討すべきです。
ただし、AI関連ログは組織の機密情報や個人情報に触れる可能性があります。compliance teamsは、取り込み前に次の3点を確認してください。
| 確認項目 | 実務での見方 |
|---|---|
| データ分類 | プロンプト、応答、ツール実行ログに機密情報が含まれるか |
| アクセス制御 | SOC、監査、法務、IT管理者のどこまで閲覧できるか |
| 保存期間 | 調査に必要な期間と、社内規程・地域規制の保存制限が矛盾しないか |
Identity teamsはUPN、サインインログ、権限をセットで見る
identity teamsがMicrosoft Sentinel data connectorを見るときは、単にMicrosoft Entra IDのログを取り込むかどうかだけでなく、取り込んだIDデータが自動化、分析ルール、インシデント対応にどう使われるかを確認する必要があります。
Microsoft Sentinelの2026年4月の最新情報では、分析ルールアラートでAccount Nameに完全なUPNをマップした場合、Account NameがUPNプレフィックスに統一され、UserPrincipalName、UPNSuffixなどのUPN関連フィールドが追加される変更が案内されています。これにより、フルUPNを前提にした自動化ルールやLogic Appsの条件は見直しが必要になる可能性があります。(Microsoft Learn)
たとえば、従来の自動化で次のような条件を使っている場合は注意が必要です。
AccountName equals [email protected]今後は、次のようにUPNプレフィックスとサフィックスを分けて扱う設計にした方が安全です。
AccountName starts with user
UPNSuffix equals example.comID関連コネクタの見直しでは、次の観点を合わせて確認してください。
| 項目 | 確認する理由 |
|---|---|
| Sign-in Logs | 不審なサインイン、国・地域、条件付きアクセスの判断に使う |
| User Risk Events | IDリスクをインシデント優先度に反映する |
| UPNの扱い | 自動化ルール、通知、チケット起票で誤判定を防ぐ |
| ゲストユーザー | B2Bや外部IDの監査漏れを防ぐ |
| 管理者ロール | 特権IDの操作ログとアラートを優先する |
IDログは、SOCだけでなく監査・内部統制にも使われます。取り込み設計の段階で、ID管理チームとSOCが別々に判断すると、後から「必要な列がない」「保持期間が短い」「自動化が誤作動する」といった問題が起きやすくなります。
Community connectorsは導入前にサポート責任を確認する
Community connectorsは、標準コネクタで対応しきれない製品や地域固有のサービスをMicrosoft Sentinelに接続するうえで便利です。一方で、公式ページではコミュニティデータコネクタのドキュメント責任は作成元にあるとされています。つまり、Microsoft純正コネクタと同じ運用保証を期待して導入すると、障害時の切り分けで困る可能性があります。(Microsoft Learn)
Microsoft SentinelのデータコネクタにはMicrosoft-supported、Partner-supported、Community-supportedなどのサポート種別があり、Microsoft以外が作成したコネクタでは、問題発生時に指定されたサポート連絡先やGitHubコミュニティで対応する形になります。(Microsoft Learn)
Community connectors導入前の確認表
| 確認項目 | 質問例 |
|---|---|
| サポート窓口 | 障害時に誰へ連絡するのか |
| 更新頻度 | API変更や認証方式変更に追随しているか |
| 認証方式 | APIキー、OAuth、証明書、マネージドIDのどれを使うか |
| 権限範囲 | 最小権限でログ取得できるか |
| データ保存 | どのテーブルに、どの項目が保存されるか |
| 地域要件 | EU、米国、日本などのデータ所在地要件に抵触しないか |
| 監査証跡 | コネクタ自体の設定変更や失敗ログを追えるか |
グローバル環境では、同じSaaSでもリージョンごとにAPIエンドポイントやデータ保持ポリシーが異なることがあります。Community connectorsを使う場合は、本番導入前に少なくとも1つのテストワークスペースで、取り込み項目、テーブル名、認証更新、障害時のログを確認してください。
Deprecated connectorsとLegacy connectorsは移行リストを作る
Find your Microsoft Sentinel data connectorには、Deprecated Sentinel data connectorsのセクションもあります。公式ページでは、非推奨およびレガシーデータコネクタが一覧化され、非推奨コネクタはサポートされないと説明されています。(Microsoft Learn)
既存環境で特に注意したいのは、旧エージェント、旧API、古いAzure Functionsベースのコネクタです。たとえば、GitHub Enterprise Audit Logの非推奨コネクタでは、deprecated HTTP Data Collector APIを置き換えるCCFデータコネクタへの移行が案内されています。また、Infobloxのレガシーエージェントでは、AMAコネクタの利用が推奨され、MMAとAMAを同じマシンで使うとログ重複や追加コストにつながる可能性があると説明されています。(Microsoft Learn)
既存環境の棚卸し手順
| 手順 | やること | 成果物 |
|---|---|---|
| 現在のコネクタを一覧化 | SentinelのData connectors、Content hub、IaC定義を確認する | 利用中コネクタ一覧 |
| Deprecatedを照合 | 公式ページのDeprecatedセクションと突き合わせる | 移行対象リスト |
| 取り込みテーブルを確認 | 実際にデータが入っているテーブルをKQLで確認する | 継続利用データの範囲 |
| 代替方式を決める | AMA、CCF、Logs ingestion API、標準コネクタを比較する | 移行方針 |
| 重複期間を設計 | 新旧コネクタの並行稼働期間を短く管理する | 重複課金防止策 |
| 検知ルールを修正 | テーブル名やスキーマ変更に合わせてKQLを更新する | 影響を受ける分析ルール一覧 |
棚卸しでは、コネクタ画面だけでなくKQLで実データを確認してください。次のクエリは、最近データが入っているテーブルをざっくり確認する際の起点になります。
search *
| where TimeGenerated > ago(24h)
| summarize Count = count() by $table
| order by Count desc本番環境ではこのクエリが重くなる可能性があります。対象テーブルが分かっている場合は、SecurityEvent、CommonSecurityLog、SigninLogsなど、個別テーブルに絞って確認する方が安全です。
導入判断は「接続可否」ではなく「運用できるか」で決める
Microsoft Sentinelのデータコネクタ選定で失敗しやすいのは、「公式一覧にあるから導入する」「Marketplaceにあるから使う」という判断です。実務では、次の5つを満たすコネクタを優先してください。
| 判断基準 | 確認内容 |
|---|---|
| 検知価値 | そのログがアラート、ハンティング、インシデント調査に使われるか |
| 運用責任 | 障害時に誰が一次対応し、誰へエスカレーションするか |
| コスト | 取り込み量、保持期間、分析層とデータレイク層の使い分けが明確か |
| セキュリティ | 認証情報、API権限、Managed Identity、シークレット管理が安全か |
| コンプライアンス | 保存地域、保持期間、個人情報、監査ログの扱いが説明できるか |
たとえば、セキュリティアプライアンスのログをCEF via AMAで取り込む場合、接続設定だけでなく、アプライアンス側のログカテゴリ、フォワーダーの冗長化、AMAの通信要件、CommonSecurityLogのスキーマ、DCR対応、分析ルールの有無まで確認します。これを行わずに「ログが入った」だけで完了にすると、インシデント時に必要なフィールドが欠落していることがあります。
まずやるべきアクション
今回のMicrosoft Sentinel: Find your Microsoft Sentinel data connectorの更新ポイントを踏まえると、次に取るべき行動はシンプルです。
まず、利用中または導入予定のデータソースを一覧化し、各コネクタについて「Solutions / Community / Custom」「DCR support」「Lake-only ingestion」「AMA要件」「Deprecated該当有無」「サポート元」を記録します。次に、Azure portal中心の運用が残っている場合は、2027年3月31日以降のDefenderポータル前提で、権限、運用手順、コネクタ画面の場所を見直します。最後に、identity teamsとcompliance teamsを巻き込み、IDログの自動化影響、データ保持、地域要件、コミュニティコネクタのサポート責任を確認します。
Microsoft Sentinelのデータコネクタは、単なるログ取り込みの入口ではありません。検知精度、調査スピード、監査対応、コスト管理を左右する基盤です。2026年4月更新の公式リファレンスは、コネクタを探すページとしてではなく、Sentinel運用を見直すための棚卸し表として活用すると効果的です。
コメント