結論から言うと、2026年5月14日時点で確認すべきポイントは「Microsoft Defender本体の検出ロジックが変わったか」ではなく、LogstashとDCRベースAPIを使ってMicrosoft Sentinelへログを送っている環境があるかです。該当の公式情報は、Logstash出力プラグインを使い、外部ログをLog AnalyticsまたはMicrosoft Sentinelのカスタムテーブル／標準テーブルへ取り込む手順を扱っています。Microsoft Learn上の該当ページは、表示上は2026年4月30日最終更新となっています。(Microsoft Learn)
Microsoft DefenderとMicrosoft Sentinelを組み合わせてSOC運用している組織では、今回の内容を「Defenderの緊急パッチ」として扱うより、Sentinelのログ取り込み設計、DCR、認証方式、ネットワーク要件、内部Runbookの見直しポイントとして整理するのが現実的です。特にLogstash、DCR、Logs Ingestion API、Syslog、CommonSecurityLog、カスタムログを使っている管理者は、設定値を見直す価値があります。
Microsoft Defenderの「Stream Logs to Microsoft Sentinel via Logstash and DCR-Based API」とは
「Stream Logs to Microsoft Sentinel via Logstash and DCR-Based API」は、LogstashのMicrosoft Sentinel向け出力プラグインを使い、外部データソースのログをMicrosoft SentinelまたはLog Analyticsへ送るための公式手順です。
ポイントは、従来の単純なログ転送ではなく、DCR（Data Collection Rules）を使って取り込み時のスキーマ、変換、出力先テーブルを制御する点です。公式ドキュメントでは、このプラグインにより、列名と型の制御、取り込み時のフィルターやエンリッチメント、カスタムテーブルまたは一部の標準テーブルへの取り込みが可能と説明されています。(Microsoft Learn)
ただし、この機能は公式ドキュメント上でパブリックプレビューとされています。プレビュー機能は一般提供機能と同じSLAが付かない場合があるため、本番環境へ展開する場合は、検証環境でのテスト、変更承認、ロールバック手順を用意してから進めるべきです。(Microsoft Learn)
今回の変更点は「Defender本体の仕様変更」ではなく、Logstash/DCR手順の確認が中心
GitHub上のMicrosoftDocs/defender-docsリポジトリでは、updates2というコミットでsentinel/connect-logstash-data-connection-rules.mdが更新されています。差分として確認できるのは1ファイル、7行追加、7行削除で、複数のLogstash設定例に付いていたrubyのコードフェンス指定が、通常のコードブロックへ変更された点です。(GitHub)
つまり、少なくともこの差分を見る限り、次のような変更とは読み取れません。
- Microsoft Defender for Endpointの検出エンジン変更
- Defenderポリシーの既定値変更
- Sentinelのインシデント生成ルール変更
- Logstashプラグインの必須パラメーター変更
- DCR、DCE、Logs Ingestion APIのエンドポイント変更
- 既存環境への即時の設定変更要求
実務上は、「Microsoft Defender関連の公式ドキュメント更新」という見出しだけで判断せず、実際に変更されたファイルと差分を見ることが重要です。今回の対象はMicrosoft SentinelのLogstash/DCR連携手順であり、Defender本体の機能変更として社内アラートを出すより、Sentinelログ取り込み運用の確認項目として扱うのが適切です。
| 確認項目 | 今回の見方 | 管理者が取るべき対応 |
|---|---|---|
| 対象ファイル | SentinelのLogstash/DCR連携手順 | Sentinel運用チーム、SOC、基盤チームで確認 |
| 変更の性質 | コードブロック表記の修正が中心 | 内部ドキュメントやRunbookの表記差分を確認 |
| Defender本体への影響 | 差分だけでは直接変更とは判断しにくい | Defenderポリシーを変更しない |
| 既存パイプラインへの影響 | 設定値変更は確認されない | 実データ取り込みが継続しているかだけ確認 |
| 優先度 | Logstash/DCRを使う環境では中程度 | 設定棚卸しと証跡記録を実施 |
影響を受ける環境と優先順位
今回の内容は、すべてのMicrosoft Defender利用者に影響するものではありません。影響を受けやすいのは、Microsoft DefenderとMicrosoft Sentinelを組み合わせ、外部ログの取り込みにLogstashやDCRを使っている組織です。
| 環境 | 影響度 | 確認ポイント |
|---|---|---|
| LogstashからMicrosoft Sentinelへログを送信している | 高 | プラグイン、DCR、DCE、認証、出力先テーブルを確認 |
| SyslogをLogstash経由でSentinelへ送っている | 高 | Microsoft-Syslogなど標準テーブル向けのoutputStreamを確認 |
| カスタムテーブルへログを送っている | 高 | _CLテーブル、スキーマ、transformKqlを確認 |
| Service principalで認証している | 中〜高 | シークレット保管、期限、ローテーションを確認 |
| Managed identityを使っている | 中〜高 | AKS、Azure Arc、Azure VM/VMSSごとの認証方式を確認 |
| Microsoft Defenderのみ利用しSentinel連携がない | 低 | 今回の差分による直接影響は限定的 |
| 内部Wikiや手順書に公式コード例を転載している | 中 | ruby表記の有無、Markdownレンダリング、説明文を確認 |
特に注意したいのは、SOCのRunbookやIaCテンプレート、社内Wikiに公式ドキュメントのコード例をコピーしているケースです。設定内容が変わっていなくても、コードブロックの言語指定が変わると、社内ドキュメントの見た目や自動生成ツールの処理に影響することがあります。
管理者が最初に確認すべき設定
LogstashとDCRベースAPIでSentinelへログを送る構成では、設定項目が複数のレイヤーに分かれます。トラブル時に原因を切り分けにくいため、次の順番で確認すると効率的です。
| レイヤー | 確認するもの | 失敗しやすいポイント |
|---|---|---|
| Logstash | 対応バージョン、入力プラグイン、フィルター、出力プラグイン | Logstash 8利用時のECS設定、プラグイン未更新 |
| 出力プラグイン | microsoft-sentinel-log-analytics-logstash-output-plugin | サードパーティ製プラグインと混同する |
| DCR | streamDeclarations、dataFlows、transformKql、outputStream | 入力スキーマとDCR定義の不一致 |
| テーブル | カスタムテーブルまたは標準テーブル | _CLサフィックス、Custom-／Microsoft-プレフィックスの誤り |
| 認証 | Service principalまたはManaged identity | シークレット期限切れ、権限不足、IDの指定漏れ |
| ネットワーク | AzureMonitor、AzureActiveDirectory、443番 outbound | プロキシ、TLS検査、ファイアウォールで遮断 |
| 検証 | KQL、Logstashログ、DCRメトリック | 「送信したつもり」でテーブル未確認 |
公式ドキュメントでは、Microsoftがサポートするのは当該のMicrosoft Sentinel提供Logstash出力プラグインであり、Microsoft Sentinel向けのサードパーティ製Logstash出力プラグインはサポート対象外とされています。運用環境で別プラグインを使っている場合は、サポート範囲の整理が必要です。(Microsoft Learn)
DCRベースAPIでログを送る基本構成
この構成では、Logstashが外部ログを受け取り、必要に応じてフィルターで整形し、Microsoft Sentinel向け出力プラグインからLogs Ingestion APIへ送信します。Logs Ingestion APIは、DCRを参照して受信データの構造、変換、宛先ワークスペース、宛先テーブルを判断します。(Microsoft Learn)
基本的な流れは次のとおりです。
| 手順 | 作業 | 実務上の注意 |
|---|---|---|
| 1 | Logstashでサンプルデータを生成または受信する | 本番ログに近い形式でサンプルを作る |
| 2 | サンプルファイルを作成する | create_sample_file => trueはサンプル作成用 |
| 3 | カスタムテーブルまたは標準テーブルを決める | 標準テーブルは対応テーブルに限定される |
| 4 | DCRを作成する | streamDeclarationsと実データの列名・型を合わせる |
| 5 | transformKqlを設定する | 必要な列を落としすぎない |
| 6 | 認証方式を設定する | Service principalかManaged identityを選ぶ |
| 7 | Logstashを再起動する | 再起動後にテーブルで着信確認する |
| 8 | KQLで検証する | 件数、時刻、送信元、重大度を確認する |
本番送信に切り替えるときは、サンプルファイル作成用のcreate_sample_file => trueを残さないように注意してください。公式手順でも、実際に取り込む設定へ進む際はcreate_sample_fileをfalseに変更する流れが示されています。(Microsoft Learn)
カスタムテーブルと標準テーブルの使い分け
DCRベースAPIでは、カスタムテーブルにも一部の標準テーブルにもログを送れます。ただし、どちらを選ぶかで、後続の分析、コスト、ルール整備、運用負荷が変わります。
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| カスタムテーブル | 独自形式の製品ログ、業務アプリログ、標準スキーマに合わないログ | 分析ルール、ハンティングクエリ、Workbookを自分で整備する必要がある |
| 標準テーブル | Syslog、CommonSecurityLogなど既存のSentinel運用に乗せたいログ | Logs Ingestion APIで対応している標準テーブルに限られる |
| 既存コネクタ | 対象製品向けの公式コネクタやAMA連携があるログ | Logstashを使うより保守が簡単な場合がある |
Logs Ingestion APIでは、カスタムテーブルは事前に存在している必要があり、カスタムテーブル名には_CLサフィックスが必要です。標準テーブルへ送る場合は、対応しているAzureテーブルに限定されます。(Microsoft Learn)
また、Microsoft Sentinelのベストプラクティスでは、Logstashでログ内容をフィルターするとログがカスタムログとして取り込まれ、無料枠や分析機能、課金、ルール整備に影響する場合があると説明されています。カスタムログは分析ルール、脅威ハンティング、Workbookへ自動的に組み込まれるわけではないため、取り込み後の検出設計まで含めて判断する必要があります。(Microsoft Learn)
Service principalとManaged identityの選び方
Logstash出力プラグインでは、Service principalによるクライアント資格情報認証と、Managed identityによるパスワードレス認証が示されています。(Microsoft Learn)
| 認証方式 | メリット | 注意点 |
|---|---|---|
| Service principal | オンプレミスや任意のサーバーでも使いやすい | client_app_secretの保管、期限管理、漏えい対策が必要 |
| System-assigned managed identity | Azure VMなどでシークレット管理を減らせる | 実行環境がManaged identityに対応している必要がある |
| User-assigned managed identity | 複数リソースで同じIDを使いやすい | 複数IDがあるVMではObject ID指定が必要になる場合がある |
| AKS Workload Identity | Kubernetes環境でシークレットレスにしやすい | 環境変数やOIDC連携の前提を満たす必要がある |
| Azure Arc managed identity | オンプレミスやハイブリッドサーバーで使える | Logstashプロセスの実行ユーザー権限に注意が必要 |
公式ドキュメントでは、Managed identity有効時にAKS Workload Identity、Azure Arc、IMDSの順に適切なIDメカニズムを検出すると説明されています。また、Azure Arcを使う場合、Logstashプロセスはチャレンジトークンを読むためにhimdsグループのメンバーであるユーザーとして実行する必要があります。(Microsoft Learn)
セキュリティ面では、client_app_secretのような機密値をLogstash設定ファイルへ平文で書かないことが重要です。公式ドキュメントでも、Logstash KeyStoreなどを使った機密情報の保管が推奨されています。(Microsoft Learn)
設定例を見るときの注意点
今回のGitHub差分では、Logstash設定例のコードブロックからruby指定が外されています。これは実務的にも自然な修正です。Logstashの設定ファイルはRubyそのものではなく、Logstash pipeline configurationとして扱うべきだからです。(GitHub)
社内ドキュメントに例を書く場合も、次のように通常のコードブロックとして扱うと誤解が少なくなります。
output {
microsoft-sentinel-log-analytics-logstash-output-plugin {
managed_identity => true
data_collection_endpoint => "<DCEまたはDCRのlogsIngestion URI>"
dcr_immutable_id => "<DCR immutableId>"
dcr_stream_name => "<stream name>"
}
}Service principalを使う場合は、設定値をファイルに直書きしない運用が前提です。
output {
microsoft-sentinel-log-analytics-logstash-output-plugin {
client_app_Id => "<application client ID>"
client_app_secret => "<secret value>"
tenant_id => "<tenant ID>"
data_collection_endpoint => "<logsIngestion URI>"
dcr_immutable_id => "<DCR immutableId>"
dcr_stream_name => "<stream name>"
create_sample_file => false
}
}この例をそのまま本番に貼り付けるのではなく、自社のDCR、DCE、テーブル、認証方式、プロキシ要件に合わせて置き換えてください。
DCR設定で失敗しやすいポイント
DCRは便利ですが、入力データ、変換、出力先テーブルを結び付けるため、設定ミスの影響が大きくなります。
| 失敗例 | 原因 | 対策 |
|---|---|---|
| データが入らない | dcr_stream_nameとDCR内のstream名が一致しない | DCRのJSONビューで実際のstream名を確認する |
| 標準テーブルへ入らない | outputStreamのプレフィックスを誤る | 標準テーブルはMicrosoft-、カスタムはCustom-を使う |
| カスタムテーブルが見つからない | _CL付きテーブルを作成していない | 取り込み前にLog Analytics側でテーブルを用意する |
| 変換後に時刻が不正 | TimeGeneratedを適切に作っていない | transformKqlでイベント時刻を明示する |
| DCR作成に失敗する | 列名が@や_で始まる | 入力列名は英字で始まるように変換する |
| 監査で困る | 不要に見える列を削除しすぎた | IP、ホスト名、ログソース、重大度、元イベント時刻は残す |
公式ドキュメントでは、streamDeclarations内の入力ストリーム列名は文字で始まる必要があり、TimeGeneratedのdatetimeフィールドが必須とされています。これらは本番展開前のチェックリストに入れておくべき項目です。(Microsoft Learn)
ネットワークとプロキシの確認ポイント
LogstashサーバーからMicrosoft Sentinelへログを送るには、認証先とログ取り込み先へ到達できる必要があります。公式ドキュメントでは、Azure virtual network service tagsとしてAzureMonitorとAzureActiveDirectoryの両方が必要とされています。サービスタグを使えない環境では、Microsoft Entra IDの認証エンドポイントとData Collection Endpointへの443番アウトバウンド通信が必要です。(Microsoft Learn)
確認すべき観点は次のとおりです。
| 項目 | 確認内容 |
|---|---|
| 通信方向 | LogstashサーバーからAzure側へのOutbound 443 |
| 認証先 | Microsoft Entra IDのログインエンドポイント |
| 取り込み先 | DCEまたはDCRのlogsIngestionエンドポイント |
| プロキシ | proxy、proxy_aad、proxy_endpointの使い分け |
| TLS検査 | 公式要件に沿って例外設計が必要か確認 |
| 高スループット | compress_dataの利用可否を検討 |
| 429対策 | retransmission_delayを増やして再試行頻度を調整 |
大量ログを送る環境では、送信失敗時の再送、圧縮、プロキシ経由の遅延、APIスロットリングを考慮する必要があります。公式ドキュメントでは、compress_dataは高スループットパイプラインで推奨され、HTTP 429のようなスロットリング時にはretransmission_delayを増やすことでリクエスト率を下げられると説明されています。(Microsoft Learn)
展開前に実施したい検証手順
本番環境へ適用する前に、最低限次の検証を行ってください。
| 検証 | 具体的な確認方法 | 合格基準 |
|---|---|---|
| サンプル生成 | create_sample_file => trueでサンプルファイルを作る | 想定列と型が確認できる |
| DCR変換 | サンプルを使ってtransformKqlを確認 | 宛先テーブルのスキーマに合う |
| 認証 | Service principalまたはManaged identityで送信 | トークン取得エラーがない |
| ネットワーク | Logstashサーバーから認証先とDCEへ接続 | 443番通信が成功する |
| 取り込み | SentinelのLogsでKQL確認 | 最新イベントが表示される |
| 運用ログ | Logstashログを確認 | 出力プラグインのエラーがない |
| 監査 | 変更記録を残す | 実施者、日時、設定、結果が残る |
KQLでの確認例は次のようにシンプルで構いません。
CustomTable_CL
| where TimeGenerated > ago(24h)
| summarize Events=count() by bin(TimeGenerated, 1h)
| order by TimeGenerated descSyslogへ送っている場合は、次のように送信元や重大度ごとに確認できます。
Syslog
| where TimeGenerated > ago(24h)
| summarize Events=count() by Computer, SeverityLevel
| order by Events desc検証では「データが入ったか」だけでなく、どのテーブルに、どの時刻で、どの列名で、どの件数が入ったかまで確認してください。ログ取り込みは成功していても、時刻や重大度がずれていると、後続の分析ルールやインシデント調査で問題になります。
2026年以降の移行計画で見落とせない点
今回の更新そのものは小さな文書差分ですが、Sentinelのログ取り込みを運用している組織は、周辺の移行スケジュールも合わせて確認すべきです。
Microsoft Sentinelのデータコネクタに関する公式情報では、2026年9月14日以降、従来のHTTP Data Collector APIはサポートされなくなるため、該当するデータソース、カスタム統合、コネクタはサポートされる代替方式へ移行する必要があると説明されています。(Microsoft Learn)
また、Microsoft Sentinelは2027年3月31日以降、Azure portalではサポートされず、Microsoft Defender portalでのみ利用可能になる予定です。現在Azure portalでSentinelを運用している組織は、Defender portalへの移行計画も並行して進める必要があります。(Microsoft Learn)
さらに、Azure MonitorのLogs Ingestion APIでは、2026年3月1日からTLS 1.2以上の接続が強制されると説明されています。古いプロキシ、レガシーOS、古いJava実行環境を経由するLogstash環境では、TLS要件も確認しておくべきです。(Microsoft Learn)
| 期限・時期 | 内容 | 取るべき対応 |
|---|---|---|
| 2026年3月1日以降 | Logs Ingestion APIでTLS 1.2以上が必要 | 古いTLS設定、プロキシ、証明書検査を確認 |
| 2026年9月14日以降 | HTTP Data Collector APIがサポート外へ | Logs Ingestion APIやCCFなどへ移行計画を作る |
| 2027年3月31日以降 | SentinelはDefender portalのみで利用 | SOC手順、教育、権限、画面キャプチャを更新 |
よくある誤解と回避策
Microsoft Defenderの検出機能が変わったと早合点する
今回のGitHub差分だけを見ると、変更対象はSentinelのLogstash/DCR連携手順です。Defender for Endpointの検出ルール、EDR設定、インシデント生成ロジックが変更されたとは判断できません。社内通知では「Defender本体の仕様変更」ではなく、「Sentinelログ取り込み手順の文書更新」と表現すると誤解を避けられます。
公式サンプルをそのまま本番へ貼り付ける
公式サンプルは理解を助けるための例です。本番環境では、テナントID、アプリケーションID、DCR immutableId、DCE URI、stream名、テーブル名、プロキシ設定、認証方式を自社環境に合わせる必要があります。
特にcreate_sample_file => trueはサンプル作成用です。本番送信時に残すと、期待した送信動作にならない可能性があります。
標準テーブルとカスタムテーブルの違いを軽視する
標準テーブルに入れれば既存の分析ルールやWorkbookに乗りやすくなりますが、対応テーブルに限られます。カスタムテーブルは柔軟ですが、後続の検出、検索、可視化を自分で整備する必要があります。
DCRで必要な列を削りすぎる
取り込み量を減らすために列を削るのは有効ですが、インシデント調査で必要になる列まで落とすと後悔します。最低限、元イベント時刻、送信元ホスト、送信元IP、ログソース、重大度、メッセージ本文、相関IDに相当する項目は残すか、削除理由を記録してください。
Azure portal前提の手順を更新しない
Sentinelの運用はMicrosoft Defender portalへ移行していきます。画面操作手順、スクリーンショット、権限設計、SOC教育資料がAzure portal前提のままだと、将来の移行時に混乱します。
管理者向けチェックリスト
今回の更新を受けて、次のチェックリストを順に確認してください。
| チェック | 確認内容 |
|---|---|
| 利用有無 | LogstashからSentinelへログを送っているか |
| プラグイン | Microsoft Sentinel公式の出力プラグインを使っているか |
| Logstash | 対応バージョンの範囲に入っているか |
| DCR | streamDeclarations、dataFlows、transformKqlが実データと一致しているか |
| テーブル | カスタムテーブルと標準テーブルの使い分けが妥当か |
| 認証 | Service principalのシークレット管理またはManaged identityの設定が適切か |
| 権限 | DCRへのアクセス権限が正しく付与されているか |
| ネットワーク | Entra IDとDCE/DCR endpointへ443番で到達できるか |
| コスト | カスタムログ化による課金・機能影響を把握しているか |
| 検出 | 分析ルール、ハンティング、Workbookが取り込み後のテーブルを参照しているか |
| 移行 | HTTP Data Collector APIやAzure portal前提の手順が残っていないか |
| 証跡 | 更新確認日、対象ファイル、判断、対応内容を記録したか |
今回の更新をどう扱うべきか
今回の「Stream Logs to Microsoft Sentinel via Logstash and DCR-Based API」は、Microsoft Defender本体の緊急変更としてではなく、Microsoft Sentinelのログ取り込み運用を見直すきっかけとして扱うのが適切です。
LogstashとDCRを使っていない環境では、影響は限定的です。一方で、外部ログをLogstash経由でSentinelへ送っている環境では、DCR、テーブル設計、認証方式、ネットワーク、コスト、分析ルールまで一通り確認してください。
次に取るべき行動は明確です。まず、社内のRunbookやIaCリポジトリでmicrosoft-sentinel-log-analytics-logstash-output-plugin、dcr_stream_name、data_collection_endpointを検索します。該当があれば、公式手順との差分、実際の取り込み状況、移行計画を確認します。該当がなければ、「対象構成なし」として記録し、Sentinelの将来移行スケジュールだけ継続的に監視しましょう。
コメント