Microsoft Sentinel カスタム コネクタの作成リソースに関する2026年5月14日更新の公式情報は、「既存のMicrosoft Defender環境に新しい設定変更が自動適用される」という告知ではありません。結論から言うと、管理者や開発者が確認すべきポイントは、データソースごとに Codeless Connector Framework、Azure Monitor Agent、Logstash、Logic Apps、Logs Ingestion API、Azure Functions のどれを使うべきかを見直し、DCR、DCE、認証、スキーマ、ASIMパーサー、Defenderポータル移行への影響を点検することです。公式ページは2026年5月14日に更新され、Microsoft Sentinelに既存コネクタがない場合にカスタムデータコネクタを作成するための方法を比較しています。(Microsoft Learn)
Microsoft Defenderの運用担当者にとって重要なのは、Microsoft SentinelがDefenderポータルで一般提供され、SIEMとXDRの統合運用に組み込まれている点です。一方で、カスタムコネクタの実装そのものは、引き続きMicrosoft Sentinel、Log Analyticsワークスペース、Azure Monitor、DCRを中心に設計します。つまり「Defenderの画面が変わる」ことと「ログの取り込み方式をどう設計するか」は分けて考える必要があります。(Microsoft Learn)
Microsoft Defenderで何が変わるのか
今回の「Resources for creating Microsoft Sentinel custom connectors」は、Microsoft DefenderやMicrosoft Sentinelの検知機能が一律で変更されるリリースではなく、カスタムコネクタ作成時に選べる実装方法を整理した公式リソースです。Microsoft SentinelにはAzureサービスや外部ソリューション向けの組み込みコネクタがありますが、既存の方法で接続できないデータソースについては、自社でデータソースコネクタを作成する選択肢があります。(Microsoft Learn)
押さえるべき変更点は、次の3つです。
| 確認ポイント | 管理者・開発者への意味 |
|---|---|
| カスタムコネクタ作成方法の比較が明確化 | データソースの種類、ログ量、開発スキル、運用コストに応じて方式を選ぶ必要がある |
| DCRやDCEを使う設計の重要度が上がる | Logs Ingestion API、CCF、Logstash DCRベース構成では、DCR設計が取り込み品質に直結する |
| Defenderポータル移行との整合性が必要 | コネクタの場所や運用画面はDefenderポータル側で確認する機会が増える |
注意したいのは、この公式ページ自体には「特定の既存カスタムコネクタを直ちに廃止する」「すべての環境で強制移行が必要」といった内容は示されていないことです。実務では、既存の取り込みが止まるかどうかを慌てて確認するより、現在のカスタム取り込み方式が今後も保守しやすい構成かを棚卸しするのが現実的です。(Microsoft Learn)
対象になる管理者・開発者
この情報を確認すべきなのは、Microsoft Defenderを使うすべてのユーザーではありません。主な対象は、Microsoft SentinelをDefenderポータルまたはAzure portalで運用し、標準コネクタだけでは収集できないログを取り込んでいる組織です。
| 対象者 | 確認すべき内容 |
|---|---|
| SOC管理者 | 既存のデータコネクタ、分析ルール、プレイブック、インシデント運用に影響がないか |
| Sentinel管理者 | Log Analyticsワークスペース、DCR、DCE、カスタムテーブル、ASIMパーサーの状態 |
| 開発者・ISV | SaaSや独自システムからSentinelへログを送る方式の選定 |
| インフラ管理者 | Logstash、Azure Functions、Azure Monitor Agent、ネットワーク経路、プロキシ、Private Link |
| セキュリティアーキテクト | Defenderポータル移行、SIEM/XDR統合、長期的な運用設計 |
逆に、Defender for EndpointやDefender for Office 365の標準アラートだけを見ている利用者は、今回の内容による直接的な設定変更は少ないと考えられます。ただし、Microsoft SentinelをDefenderポータルに統合している環境では、調査画面やデータコネクタの確認場所が変わるため、運用手順書は更新しておくべきです。(Microsoft Learn)
カスタムコネクタ作成方法の選び方
Microsoft Learnでは、Microsoft Sentinel カスタム コネクタ作成方法として、Codeless Connector Framework、Azure Monitor Agent、Logstash、Logic Apps、Logs Ingestion API、Azure Functionsが比較されています。選び方を誤ると、取り込みコストの増加、運用負荷の増大、検知ルールで使いにくいスキーマになるといった問題が起きます。(Microsoft Learn)
| 方式 | 向いているケース | 注意点 |
|---|---|---|
| Codeless Connector Framework | SaaS APIから定期的にログを取得したい。高度なコード実装を避けたい | 対象APIの認証方式、ページング、レスポンス構造が対応しているか事前確認が必要 |
| Azure Monitor Agent | オンプレミスやIaaS上のテキストログ、ファイルベースのログを収集したい | 対象ファイル、文字コード、追記方式、DCR設計が重要 |
| Logstash | 既にLogstash基盤がある。多様な入力プラグインやフィルターを活用したい | VMまたはクラスタ運用が必要。DCRベースプラグインはプレビュー扱いのため本番適用は慎重に判断 |
| Logic Apps | 低頻度・低容量のクラウドAPI、手動テスト、補助的なエンリッチメント | 大量ログではコストが上がりやすい |
| Logs Ingestion API | 独自アプリやISV製品から柔軟にログを送信したい | DCR、アプリ登録、権限、JSONスキーマ、TLS、エンドポイント設計が必要 |
| Azure Functions | 高容量のクラウドログ、独自処理、複雑な変換や再試行制御が必要 | 開発・監視・例外処理・認証管理が必要 |
実務で迷った場合は、「ログ量」と「開発自由度」で切り分けると判断しやすくなります。少量のSaaS API取得ならCCFまたはLogic Apps、大量ログや独自変換が必要ならAzure FunctionsまたはLogs Ingestion API、既存のログ集約基盤がLogstashならDCRベースのLogstash構成を検討します。
Codeless Connector Frameworkを選ぶ場合
Codeless Connector Frameworkは、コード量を抑えてSaaS向けコネクタを作成したい場合に有力です。公式ドキュメントでは、CCFで作成したコネクタはSaaS型で、サービスインストールが不要であり、ヘルス監視とMicrosoft Sentinelのサポートを含むと説明されています。新しいCCFでは、複数の認証・ページング方式への対応、標準DCRのサポート、UI定義と接続構成の分離などが改善点として挙げられています。(Microsoft Learn)
導入前に確認すべきなのは、対象SaaS APIがCCFで扱える形かどうかです。特に、証明書署名トークン、独自のページング、複雑な再試行条件、非標準のレスポンス構造がある場合は、CCFだけで無理に実装せず、Azure FunctionsやLogs Ingestion APIも候補に入れます。
Azure Monitor Agentを選ぶ場合
オンプレミスサーバーやIaaS上のアプリケーションがテキストファイルへログを書き出す場合は、Azure Monitor Agentを使ったCustom Text Logsの収集が適しています。DCRでCustom Text Logsデータソースを構成し、Log Analyticsワークスペースのカスタムテーブルへ送信します。(Microsoft Learn)
失敗しやすいのは、ファイル収集の基本条件を軽視するケースです。Microsoft Learnでは、収集対象ファイルはエージェントマシンのローカルドライブ上にあり、ASCIIまたはUTF-8で、既存レコードを上書きせず末尾追記される必要があると説明されています。また、多すぎるディレクトリ監視やログファイルのリネームは、パフォーマンス低下や重複取り込みの原因になります。(Microsoft Learn)
Logstashを選ぶ場合
Logstashは、既にElastic系のログ処理に慣れている組織や、多様な入力プラグインを活用したい環境に向いています。Microsoft SentinelのLogstash出力プラグインでは、DCRベースAPIを使って外部データソースのログをカスタムテーブルまたは標準テーブルへ転送できます。DCRによる列名・型の制御、取り込み時変換、フィルタリングやエンリッチメントにも対応しています。(Microsoft Learn)
ただし、DCRベースのLogstash出力プラグインはパブリックプレビューであり、SLAなしとされています。本番ワークロードで使う場合は、可用性、再送、監視、サポート方針を確認し、段階的に展開する必要があります。(Microsoft Learn)
また、古いLogstash出力プラグインはHTTP Data Collection APIを使うレガシー方式として扱われ、関連ページには非推奨の表示があります。既存環境で古いプラグインを使っている場合は、DCRベースの新しい構成へ移行できるかを評価してください。(Microsoft Learn)
Logic Appsを選ぶ場合
Logic Appsは、少量のクラウドデータソースや、手動実行、スケジュール実行、Webhookによる取り込みに向いています。Microsoft Learnでは、Logic Appsはサーバーレスのカスタムコネクタ作成に使える一方、大量データではコストが高くなる可能性があるため、低容量データソースまたはデータアップロードのエンリッチメント用途に推奨されています。(Microsoft Learn)
例えば、1時間に数百件程度のAPIログを取得して整形する程度ならLogic Appsで十分な場合があります。一方、数分ごとに大量のイベントを取り込み続ける設計では、アクション実行回数、再試行、失敗時のキューイング、コストが膨らみやすくなります。この場合はAzure FunctionsやLogs Ingestion APIを検討します。
Logs Ingestion APIを選ぶ場合
独自アプリケーション、社内システム、ISV製品から直接Sentinelへログを送る場合は、Azure MonitorのLogs Ingestion APIが中心になります。このAPIはREST APIまたはクライアントライブラリでLog Analyticsワークスペースへデータを送信でき、対応するAzureテーブルやカスタムテーブルへ取り込めます。(Microsoft Learn)
設計時に特に重要なのは、DCRです。Logs Ingestion APIでは、データの送信先テーブル、ワークスペース、入力データ構造、変換処理をDCRで定義します。アプリ登録にはDCRへのアクセス権が必要で、DCRに対してMonitoring Metrics Publisherロールを割り当てる必要があります。(Microsoft Learn)
また、2026年3月1日からLogs Ingestion APIではTLS 1.2以上の接続が強制されます。古いランタイム、古いOS、古いプロキシ、組み込み機器からログ送信している場合は、TLS設定を必ず確認してください。(Microsoft Learn)
Azure Functionsを選ぶ場合
Azure Functionsは、高容量のクラウドログや、複雑なAPI呼び出し、独自の正規化、リトライ制御、複数テーブルへの振り分けが必要な場合に適しています。Microsoft Learnでは、Azure FunctionsをRESTful APIやPowerShellなどの言語と組み合わせて、サーバーレスのカスタムコネクタを作成できる方法として紹介しています。(Microsoft Learn)
実装時は、関数コードだけでなく、マネージドIDまたはサービスプリンシパル、シークレット管理、タイムアウト、失敗時の再試行、アプリケーションログ、取り込み遅延の監視まで含めて設計します。PoCでは動いても、本番ではAPI制限や一時的な障害でログ欠損が起こることがあります。キューやストレージを組み合わせ、再処理できる構成にしておくと安全です。
管理者が確認すべき設定
Microsoft Defender側の運用画面だけで判断せず、Log AnalyticsとAzure Monitor側の設定も含めて確認します。特にDCR、DCE、テーブル、権限、認証は、ログ取り込みの成否を左右します。
| 確認項目 | 見るべきポイント |
|---|---|
| データソース | 標準コネクタで対応可能か。カスタム実装が本当に必要か |
| 取り込み方式 | CCF、AMA、Logstash、Logic Apps、Logs Ingestion API、Azure Functionsのどれか |
| Log Analyticsテーブル | 標準テーブルかカスタムテーブルか。カスタムテーブル名、列名、型は適切か |
| DCR | 入力ストリーム、変換KQL、出力テーブル、ワークスペースが一致しているか |
| DCE | Private Link利用時や古いDCR利用時に必要な構成になっているか |
| 認証 | アプリ登録、シークレット、マネージドID、DCRへの権限付与が正しいか |
| ネットワーク | プロキシ、ファイアウォール、Private Link、送信先エンドポイントを許可しているか |
| セキュリティ | シークレットを平文設定ファイルに置いていないか |
| 監視 | 失敗、遅延、重複、欠損を検出できるか |
| ASIM | 検知ルールやハンティングで使える形に正規化しているか |
Logs Ingestion APIでは、DCRログ取り込みエンドポイントまたはDCEを使います。Private Linkを使う場合や、DCRにログ取り込みエンドポイントが含まれない場合はDCEが必要です。古いDCRからDCRエンドポイントへ移したい場合、既存DCRへエンドポイントを追加するのではなく、新しいDCRを作成して置き換える必要があります。(Microsoft Learn)
Defenderポータル移行で注意すべきこと
Microsoft SentinelはMicrosoft Defenderポータルで一般提供されており、Microsoft Defender XDRやE5ライセンスを持たない顧客でもDefenderポータルで利用できます。さらに、2027年3月31日以降、Microsoft SentinelはAzure portalでサポートされなくなり、Defenderポータルでのみ利用可能になると案内されています。(Microsoft Learn)
ただし、Defenderポータルへの統合によって、既存のMicrosoft Sentinelデータ収集やテレメトリの基本アーキテクチャが変わるわけではありません。公式の移行情報では、Microsoft Sentinelで構成された既存コネクタは中断なく動作し、Log Analyticsの観点では基盤となる取り込みパイプラインやデータスキーマに変更はないと説明されています。(Microsoft Learn)
実務上の注意点は、画面の場所です。Defenderポータルでは、データコネクタは「Microsoft Sentinel > Configuration > Data connectors」に移ります。分析、ウォッチリスト、自動化、設定などもDefenderポータル上の配置に合わせて運用手順書を更新する必要があります。(Microsoft Learn)
移行・展開時に失敗しやすいポイント
カスタムコネクタの移行では、ログが送信できることだけを成功条件にしないことが重要です。Sentinelで使いやすいデータになっているか、Defenderポータルで調査しやすいか、分析ルールやハンティングで活用できるかまで確認します。
| よくある問題 | 原因 | 対策 |
|---|---|---|
| テーブルにデータが入らない | DCRのstream名、出力先、権限、エンドポイントの不一致 | DCRのJSON、DCR Immutable ID、Monitoring Metrics Publisherロールを確認 |
| データは入るが検知に使えない | 独自スキーマのまま正規化していない | ASIMパーサーを作成し、既存の検知コンテンツで使いやすくする |
| ログが重複する | 複数DCR、ファイルリネーム、複数パイプラインから同じログを送信 | 送信経路を棚卸しし、重複条件をKQLで確認 |
| Logic Appsのコストが増える | 大量イベントをアクション単位で処理している | Functions、Logs Ingestion API、Logstashへの移行を検討 |
| タイムスタンプがずれる | TimeGeneratedやログ内時刻の変換が不適切 | 取り込み時変換と時刻形式を明示し、UTC基準で検証 |
| 本番だけ失敗する | プロキシ、Private Link、TLS、API制限をPoCで確認していない | 本番同等ネットワークで段階テストを実施 |
| シークレット漏えいリスクがある | 設定ファイルにクライアントシークレットを平文保存 | マネージドID、Key Vault、Logstash KeyStoreなどを使う |
Microsoft Learnでは、カスタムコネクタで収集したデータを活用するにはASIMパーサーを開発し、Sentinelの組み込みコンテンツがカスタムデータを使えるようにすることが推奨されています。LogstashやAzure Functionsを使う場合は、コネクタ側で一部の解析を実装することで、クエリ時の解析負荷を減らせます。(Microsoft Learn)
展開前の実務チェックリスト
新規作成や移行を始める前に、次の順序で確認すると手戻りを減らせます。
| 手順 | 実施内容 |
|---|---|
| 現状把握 | 標準コネクタ、カスタムコネクタ、Logstash、Logic Apps、Functions、手動スクリプトを棚卸しする |
| 方式選定 | ログ量、API仕様、運用スキル、コスト、可用性で方式を選ぶ |
| スキーマ設計 | 標準テーブルへ寄せるか、カスタムテーブルを作るかを決める |
| DCR設計 | streamDeclarations、transformKql、outputStream、workspaceResourceIdを確認 |
| 認証設計 | マネージドIDを使えるか。使えない場合はシークレット管理を設計 |
| ネットワーク確認 | DCRエンドポイント、DCE、Private Link、プロキシ、TLS 1.2以上を確認 |
| 検証 | ステージング環境で取り込み、重複、遅延、欠損、コストを確認 |
| Sentinel活用 | ASIMパーサー、分析ルール、Workbook、ハンティングクエリで使えるか確認 |
| 運用監視 | 取り込み失敗、関数エラー、Logic Apps実行失敗、Logstash再送を監視 |
| 手順書更新 | Defenderポータル上のメニュー位置、運用担当、障害時対応を反映 |
検証時は、単に「1件入った」で終わらせず、以下のような観点でKQLを使って確認します。
YourCustomTable_CL
| where TimeGenerated > ago(1h)
| summarize Count = count() by bin(TimeGenerated, 15m)YourCustomTable_CL
| where TimeGenerated > ago(24h)
| summarize Count = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)重複が疑われる場合は、ログID、送信元ホスト、イベント時刻など、自社ログで一意性を判断できる列を使って確認します。
YourCustomTable_CL
| where TimeGenerated > ago(24h)
| summarize Count = count() by EventId, SourceHost, EventTime
| where Count > 1既存環境では何から始めるべきか
既にMicrosoft Sentinelを使っている場合、最初に行うべきことは「すぐに作り替える」ことではなく、現在のデータ取り込み経路を一覧化することです。特に、HTTP Data Collector APIを使う古いスクリプト、古いLogstashプラグイン、平文シークレットを持つ構成、Logic Appsで大量ログを処理している構成は、優先的に見直します。
次に、Defenderポータル移行の観点で、データコネクタ、分析ルール、自動化ルール、プレイブック、Workbook、ハンティングクエリの担当者と確認手順を更新します。Microsoft Sentinelのバックエンド取り込みが変わらないとしても、運用者が探す画面や調査フローが変わると、障害時の初動が遅れるためです。(Microsoft Learn)
新規にMicrosoft Sentinel カスタム コネクタを作る場合は、標準コネクタの有無を確認したうえで、ログ量が少ないSaaS連携ならCCFまたはLogic Apps、ファイルログならAzure Monitor Agent、既存ログ基盤があるならLogstash、独自性や拡張性が必要ならLogs Ingestion APIまたはAzure Functionsを選びます。最後にASIMパーサーまで用意し、Microsoft Defender上のインシデント調査やハンティングで使えるデータに整えることが、実用的なゴールです。
コメント