Microsoft Defenderの公式ドキュメント更新「updates2」を確認するときに最初に押さえるべき結論は、今回の更新をMicrosoft Defender本体の機能変更として扱わないことです。2026年4月30日に更新された対象は、MicrosoftDocsのdefender-docsリポジトリ内にあるMicrosoft Sentinel向けのLogstashとDCRベースAPIに関するドキュメントです。コミット差分自体は1ファイル、7行追加・7行削除の小規模な変更で、主にコードブロックの表記調整に見えます。(GitHub)
ただし、セキュリティ管理者やコンプライアンス担当者にとっては「小さなドキュメント更新だから無視してよい」とは限りません。対象ページは、LogstashからLog AnalyticsまたはMicrosoft Sentinelへログを取り込む構成、Data Collection Rules、標準テーブル・カスタムテーブル、認証方式、ネットワーク要件に関わるためです。この記事では、Microsoft Defender documentation update: updates2を見たときに、仕様確認・運用影響・移行準備の観点で何を確認すべきかを実務向けに整理します。
Microsoft Defenderの公式ドキュメント更新「updates2」で何が変わったか
今回の「updates2」は、GitHub上のMicrosoftDocs/defender-docsリポジトリにあるコミットメッセージです。コミット対象はsentinel/connect-logstash-data-connection-rules.mdで、変更規模は1ファイル、7 additions、7 deletionsです。差分を見る限り、Logstash設定例のコードブロックで使われていた言語指定の調整が中心で、設定値そのものが置き換わったわけではありません。(GitHub)
重要なのは、対象ファイルがMicrosoft Defenderそのものの検出エンジン、EDRポリシー、Defender for Endpointのオンボーディング手順ではなく、Microsoft SentinelにLogstash経由でログを送る手順を扱っている点です。Microsoft Learn上の該当ページも「Stream logs to Microsoft Sentinel with Logstash and DCR-based API」として公開され、最終更新日は2026年4月30日になっています。(Microsoft Learn)
| 確認項目 | 内容 |
|---|---|
| 更新名 | updates2 |
| 対象リポジトリ | MicrosoftDocs/defender-docs |
| 対象ファイル | sentinel/connect-logstash-data-connection-rules.md |
| 主な対象サービス | Microsoft Sentinel、Log Analytics、Logstash、DCR |
| 変更規模 | 1ファイル、7行追加・7行削除 |
| 実務上の見方 | 製品仕様変更ではなく、まずはドキュメント整備として扱う |
| 確認すべき読者 | security admins、compliance teams、enterprise IT readers |
このため、社内向けの変更管理では「Microsoft Defenderの重大な仕様変更」としてアラートを上げるよりも、「Microsoft Sentinelのログ取り込み手順に関する公式ドキュメント更新」として分類するのが現実的です。
今回の更新を“製品アップデート”と混同しないことが重要
公式ドキュメント更新を追っていると、コミットメッセージだけを見て「Defenderの仕様が変わったのではないか」と判断してしまうことがあります。しかし、MicrosoftDocs系の更新では、製品機能の変更、文章修正、コードサンプルの整形、リンク更新、メタデータ更新が同じようにコミットとして表示されます。
今回の差分は、Logstash設定例のコードブロック周辺で発生しています。GitHubの差分では、複数箇所で“`rubyのようなコードフェンス指定が変更されており、本文の設定項目や認証方式そのものが新しく追加された差分ではありません。(GitHub)
そのため、まず次のように切り分けると判断ミスを防げます。
| 判断軸 | 今回の見方 |
|---|---|
| 製品機能の追加か | 差分だけを見る限り、機能追加とは判断しにくい |
| 設定パラメータの変更か | コード例の中身ではなく、表記調整が中心に見える |
| 既存環境への即時影響か | 直ちに設定変更が必要とは言い切れない |
| 監査・変更管理で記録すべきか | Sentinelのログ取り込み手順を運用している組織では記録対象にする価値がある |
| 移行準備に関係するか | Logstash、DCR、Managed Identity、ネットワーク要件を使う環境では確認すべき |
特にグローバル企業では、SOC、クラウド基盤チーム、コンプライアンスチームが別々にMicrosoftの公式更新を監視していることがあります。誰かが「Defender docs updated」とだけ共有すると、Endpoint担当者とSentinel担当者の認識がずれる可能性があります。共有時は「Defender docs repo内のSentinel Logstash/DCR article update」と具体的に書くのが安全です。
対象ドキュメントはMicrosoft SentinelのLogstash/DCRログ取り込み手順
該当ページは、Logstash出力プラグインを使って外部データソースのログをLog AnalyticsまたはMicrosoft Sentinelへ送る構成を説明しています。Microsoft Learnの本文では、Data Collection Rulesを使ったログ取り込みはパブリックプレビューであり、Logstash出力プラグインがDCRによるパイプライン変換や高度な構成をサポートすると説明されています。(Microsoft Learn)
実務上は、次のような環境で関係します。
- オンプレミスのsyslogサーバーやネットワーク機器のログをMicrosoft Sentinelへ集約している
- Logstashを中継基盤として使い、ログを加工してから取り込んでいる
- カスタムログテーブルまたは標準テーブルへログを流している
- DCRでスキーマや変換処理を管理している
- サービスプリンシパルからManaged Identityへの移行を検討している
- Azure Firewall、NSG、プロキシ、閉域構成で送信制御をしている
Microsoft Defenderという名前だけで見るとEndpoint保護の話に見えますが、今回のドキュメントはSIEM運用に近い内容です。Defender製品群からのアラートやログをSentinelで相関分析している組織では関係しますが、Defender for Endpoint単体の設定変更とは切り分けて確認しましょう。
運用担当者が確認すべきポイント
今回のupdates2で実際の設定変更が必要かどうかは、既存環境が該当ドキュメントの構成に依存しているかで決まります。特に見るべきなのは、コードブロックの差分そのものよりも、現行ページに記載されている前提条件、認証方式、ネットワーク要件、制限事項です。
Logstashとプラグインの対応バージョンを確認する
Microsoft Learnの該当ページでは、Microsoft Sentinel提供のLogstash出力プラグインが扱われており、現在のプラグインとしてmicrosoft-sentinel-log-analytics-logstash-output-plugin v2.1.0が示されています。また、対応するLogstashバージョンも列挙されています。(Microsoft Learn)
ここで確認すべきことは、「ドキュメントにあるバージョンと自社環境が一致しているか」だけではありません。次の観点も合わせて確認します。
| 確認対象 | 確認方法 | 判断基準 |
|---|---|---|
| Logstash本体 | logstash --versionなどで確認 | 公式ページの対応範囲に入っているか |
| Sentinel出力プラグイン | logstash-plugin list --verboseなどで確認 | 古いプラグイン名や非推奨構成を使っていないか |
| Logstash 8系のECS設定 | パイプライン設定を確認 | ECS有効化によるフィールド名のズレがないか |
| オフライン環境 | オフラインプラグインパックの運用を確認 | インターネット接続なしで更新手順を再現できるか |
失敗しやすいのは、検証環境だけ新しいプラグインを使い、本番環境は古いプラグインのままになっているケースです。Sentinel側でデータが見えていても、将来の変更やトラブル時に公式サポート対象外の構成が混ざっていると原因切り分けが難しくなります。
DCRのstreamDeclarationsとoutputStreamを確認する
このドキュメントの中心は、Data Collection Rulesを使ったログ取り込みです。標準テーブルへ取り込む場合、outputStreamには標準テーブル名を指定し、カスタムテーブルとは異なり_CLサフィックスを付けないこと、プレフィックスはCustom-ではなくMicrosoft-を使うことが説明されています。(Microsoft Learn)
たとえばSyslogテーブルに取り込む場合、ドキュメント例ではoutputStreamにMicrosoft-Syslogを使います。ここを誤ると、ログが意図しないカスタムテーブルに入る、変換が合わず欠落する、クエリや分析ルールが期待通り動かないといった問題につながります。
特にコンプライアンスチームが注意すべき点は、ログの到達有無だけではなく、監査に必要なフィールドが正しいテーブル・正しい型・正しい時刻で保持されているかです。
確認例は次のとおりです。
Syslog
| where TimeGenerated > ago(1h)
| summarize count() by Computer, Facility, SeverityLevel
| order by count_ descカスタムテーブルの場合は、テーブル名や列名を自社環境に合わせて確認します。
YourCustomTable_CL
| where TimeGenerated > ago(1h)
| take 50DCRの変換では、取り込み時点でフィールドを落としたり、型変換したりできます。便利な一方で、誤ったprojectや型変換により、あとから必要な証跡を復元できないことがあります。監査要件があるログは、変換前のサンプル、DCR定義、取り込み後のテーブルをセットで保管しておくと変更レビューがしやすくなります。
認証方式はサービスプリンシパルかManaged Identityかを確認する
該当ページでは、Logstash構成で使う認証方式として、サービスプリンシパルとManaged Identityの2種類が説明されています。Managed Identityを有効にすると、クライアントシークレットなしで認証でき、AKS Workload Identity、Azure Arc、IMDSの順に実行環境に応じて認証メカニズムが検出されるとされています。(Microsoft Learn)
実務では、次のように判断するとよいでしょう。
| 認証方式 | 向いている環境 | 注意点 |
|---|---|---|
| サービスプリンシパル | 既存構成を大きく変えずに使いたい環境 | client_app_secretの保管、期限切れ、ローテーション管理が必要 |
| システム割り当てManaged Identity | Azure VMやVMSS上のLogstash | リソース移設時にIDが変わる可能性を考慮する |
| ユーザー割り当てManaged Identity | 複数VMや標準化された運用 | managed_identity_object_idの指定ミスに注意 |
| Azure Arc経由のManaged Identity | ハイブリッド・オンプレミス | Logstash実行ユーザーの権限やArcエージェント状態を確認する |
| AKS Workload Identity | Kubernetes上のLogstash | 必要な環境変数とフェデレーショントークンの設定を確認する |
セキュリティの観点では、サービスプリンシパルを使う場合、client_app_secretをLogstash設定ファイルに平文で置かないことが重要です。Microsoft Learnでも、機密値を構成ファイルに直接記載せず、Logstash KeyStoreの利用が案内されています。(Microsoft Learn)
ネットワーク要件とプロキシ設定を確認する
Microsoft SentinelのLogstash出力プラグインは、Azure MonitorとMicrosoft Entra IDへ通信します。ドキュメントでは、仮想ネットワークサービス タグとしてAzureMonitorとAzureActiveDirectoryが必要であり、サービス タグを使えない場合のファイアウォール要件も示されています。(Microsoft Learn)
閉域構成やプロキシ環境では、次の項目を確認してください。
| 確認項目 | 実務での確認ポイント |
|---|---|
| Microsoft Entra IDへの通信 | 認証エンドポイントへ443/TCPで到達できるか |
| Data Collection Endpointへの通信 | <DCE名>.<リージョン>.ingest.monitor.azure.com形式の宛先へ到達できるか |
| TLS/HTTPS検査 | 認証・取り込み通信でHTTPS検査をバイパスすべき経路を把握しているか |
| プロキシ設定 | proxy、proxy_aad、proxy_endpointの使い分けが正しいか |
| 国・リージョン別クラウド | Azure Commercial、Azure Government、21Vianet環境でエンドポイントが異なることを考慮しているか |
ありがちな失敗は、Azure Monitor側の取り込みエンドポイントだけ許可し、Microsoft Entra ID側の認証通信を忘れることです。この場合、ログ送信以前にトークン取得で失敗します。逆に、認証は通るが取り込み先DCEに到達できない場合は、Logstash側の出力プラグインログやDCRメトリックを見ないと原因が見えにくくなります。
コンプライアンスチームが見るべき影響範囲
コンプライアンス担当者にとって、今回のupdates2で大切なのは「差分の小ささ」よりも「該当ドキュメントが監査証跡の取り込み手順に関係しているか」です。LogstashとDCRは、ログの整形、フィルタリング、テーブル選択に影響します。つまり、設定によっては監査対象ログが欠落したり、保持先が変わったり、クエリで検出できなくなる可能性があります。
次のような組織では、ドキュメント更新を変更管理の参考情報として記録しておく価値があります。
- Microsoft SentinelをSIEM基盤として使っている
- ファイアウォール、ID基盤、業務システムのログをLogstash経由で取り込んでいる
- DCRのKQL変換でログ項目を加工・削除している
- SOCの分析ルールや監査レポートが特定テーブルに依存している
- ISO、SOC 2、PCI DSS、社内統制などでログ完全性の説明が必要になる
コンプライアンス観点での確認表は次のとおりです。
| 観点 | 確認すべきこと | 放置した場合のリスク |
|---|---|---|
| ログ完全性 | 取り込み前後で必要フィールドが残っているか | 監査時に証跡不足になる |
| テーブル設計 | 標準テーブルとカスタムテーブルの使い分けが正しいか | 分析ルールやレポートが対象外になる |
| 時刻項目 | TimeGeneratedやイベント時刻が正しく設定されているか | インシデント時系列がずれる |
| 認証情報 | シークレットを平文保存していないか | 資格情報漏えいのリスクが高まる |
| 変更履歴 | DCR、Logstash設定、プラグイン更新履歴を残しているか | 変更原因の追跡ができない |
監査対応では「Microsoft公式ドキュメントが更新された」だけでは説明になりません。自社環境で何を確認し、変更不要と判断したのか、またはどの設定を変更したのかを記録することが重要です。
移行準備として確認したいポイント
Microsoft Sentinelへのログ取り込みを今後見直す予定がある場合、updates2をきっかけにLogstash/DCR構成を棚卸しすると効果的です。特に、古い取り込み方式からDCRベースのAPIへ移行する場合や、サービスプリンシパルからManaged Identityへ移行する場合は、単なる設定変更ではなく運用設計の見直しになります。
カスタムテーブルと標準テーブルの使い分けを決める
標準テーブルに取り込むメリットは、Microsoft Sentinelの既存分析ルール、ワークブック、調査フローと連携しやすいことです。一方、カスタムテーブルは独自ログのスキーマに合わせやすく、不要な列を減らして運用しやすい場合があります。
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| 標準テーブル | SyslogやCommonSecurityLogなど既存の分析ルールと連携したい | 標準テーブルのスキーマに合わせる変換が必要 |
| カスタムテーブル | SaaSや独自アプリのログを柔軟に扱いたい | _CL付きテーブル名や独自クエリ設計が必要 |
| 併用 | 一部は標準化し、一部は詳細分析用に保持したい | コスト、重複、保持期間の管理が複雑になる |
判断基準は「取り込めるか」ではなく、「検知・調査・監査で使いやすいか」です。たとえばファイアウォールのログをカスタムテーブルに入れた結果、既存のSentinel分析ルールが参照しないのであれば、検知運用上は不利になる場合があります。
サンプルファイルを使ってDCRを検証する
該当ドキュメントでは、Logstashからサンプルファイルを生成し、それを使ってDCRを作成・検証する流れが説明されています。サンプルファイルは、カスタムログやSyslogテーブルへの取り込み時にスキーマを確認するための重要な材料です。(Microsoft Learn)
実務では、サンプルを1種類だけで済ませないことが大切です。正常ログ、エラーログ、長いメッセージ、マルチバイト文字、欠損フィールドを含むログなど、実際の運用で出るパターンを複数用意します。
検証時の手順は次のように整理できます。
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 1 | Logstash入力を準備する | 実データに近いログ形式を使う |
| 2 | サンプルファイルを生成する | ls_timestampなど自動追加フィールドを確認する |
| 3 | DCRのstreamDeclarationsを作る | 列名と型が一致しているか確認する |
| 4 | transformKqlを設定する | 必要フィールドを落としていないか確認する |
| 5 | テスト送信する | SentinelまたはLog Analyticsで受信を確認する |
| 6 | 分析ルール・ワークブックで確認する | 取り込んだログが運用画面で使えるか確認する |
この段階で「ログは入っているが、分析に使える形ではない」という問題を見つけることが重要です。ログ取り込みプロジェクトでは、疎通確認で完了扱いにしてしまい、あとからSOC担当者がクエリを書き直すケースがよくあります。
Managed Identity移行は権限設計から始める
サービスプリンシパルからManaged Identityへ移行する場合、設定ファイルの値を変えるだけでは不十分です。DCRに対する権限、Log Analyticsワークスペース、実行基盤、Azure ArcやAKSの構成を合わせて確認する必要があります。
特にユーザー割り当てManaged Identityを使う場合、複数のIDが存在するVMではmanaged_identity_object_idの指定ミスに注意してください。IDが正しくても、DCRへの権限付与が不足していればログは送信できません。
移行前に、次の3点をチェックします。
- 対象IdentityにDCRへログを書き込むための適切な権限があるか
- Logstashが動く実行環境でManaged Identityを取得できるか
- 障害時にどのログで認証失敗と送信失敗を切り分けるか
「シークレットレス化」はセキュリティ上の利点がありますが、移行直後はトラブルシュートの観点が変わります。シークレット期限切れの心配が減る一方で、ID割り当て、ロール、メタデータサービス、Arcエージェントの状態確認が重要になります。
変更確認の実務フロー
Microsoft DefenderやMicrosoft Sentinel関連の公式ドキュメント更新を見つけたときは、次の流れで確認すると、過剰対応と見落としの両方を防げます。
| ステップ | やること | 今回のupdates2での例 |
|---|---|---|
| 1 | コミット対象を確認する | sentinel/connect-logstash-data-connection-rules.mdが対象 |
| 2 | 差分の種類を分類する | コードブロック表記の調整が中心に見える |
| 3 | 関連サービスを特定する | Microsoft Sentinel、Log Analytics、Logstash、DCR |
| 4 | 自社利用有無を確認する | Logstash経由のログ取り込みを使っているか |
| 5 | 運用影響を判断する | 直ちに設定変更が必要か、確認記録だけでよいか |
| 6 | 必要なら検証する | DCR、認証、ネットワーク、クエリで確認する |
| 7 | 変更管理に残す | 影響なしの判断も記録する |
今回のような小規模差分では、全環境に緊急対応をかける必要は通常ありません。ただし、Sentinelのログ取り込み基盤を運用している場合は、ドキュメントの現在形に合わせて設定台帳や運用手順書を見直す価値があります。
よくある誤解と失敗しやすいポイント
Defenderの検出ロジックが変わったと早合点する
今回のupdates2は、MicrosoftDocs/defender-docsリポジトリ上の更新ですが、対象はMicrosoft SentinelのLogstash/DCR手順です。Defender for Endpointの検出ルール、AVエンジン、EDR設定が変更されたと断定しないようにしましょう。
社内通知では、次のように書くと誤解が減ります。
MicrosoftDocs/defender-docsリポジトリでupdates2コミットを確認。
対象はMicrosoft SentinelのLogstash/DCRベースログ取り込み手順。
現時点ではDefender for Endpoint本体の設定変更ではなく、Sentinelログ取り込み手順のドキュメント更新として確認。コード例をそのまま本番に貼り付ける
公式ドキュメントのサンプルは、理解を助けるための例です。本番環境では、ワークスペース、DCR、DCE、ストリーム名、テーブル、プロキシ、認証方式を自社環境に合わせる必要があります。
特にcreate_sample_file => trueは、サンプルファイル作成時の設定です。本番送信時には、ドキュメント上でもcreate_sample_fileをfalseに変更する流れが示されています。(Microsoft Learn)
DCRの変換で必要なフィールドを落とす
DCRのtransformKqlは便利ですが、不要に見えるフィールドを削除した結果、インシデント調査や監査で困ることがあります。たとえば元の送信元IP、デバイス識別子、ログソース名、重大度、イベント時刻などは、あとから必要になりやすい項目です。
削除する前に、SOC、インフラ、コンプライアンスの3者で「保持すべきフィールド」を確認しましょう。
低頻度ログで取り込み失敗と誤認する
ドキュメントの既知の問題では、イベントレートが低い環境ではplugin_flush_intervalを60以上に増やすこと、DCRメトリックで取り込みペイロードを監視できることが案内されています。(Microsoft Learn)
低頻度の監査ログや検証用ログでは、「送ったのにすぐ見えない」だけで障害と判断しがちです。Logstashの出力ログ、DCRメトリック、Sentinel側のクエリ範囲を合わせて確認してください。
すぐに使える確認チェックリスト
今回のMicrosoft Defender documentation update: updates2を見たあと、実務で使えるチェックリストは次のとおりです。
| チェック | 対象 | 確認内容 |
|---|---|---|
| 対象ファイル | ドキュメント | SentinelのLogstash/DCR記事が対象であることを確認したか |
| 影響範囲 | 自社環境 | Logstash経由のSentinel取り込みを使っているか |
| バージョン | Logstash・プラグイン | 公式ページの対応範囲と大きくずれていないか |
| DCR | スキーマ・変換 | streamDeclarations、dataFlows、outputStreamが正しいか |
| テーブル | Log Analytics | 標準テーブルとカスタムテーブルの使い分けが妥当か |
| 認証 | SPN・Managed Identity | シークレット管理またはManaged Identity権限が適切か |
| ネットワーク | Firewall・Proxy | Entra IDとDCEへの443/TCP通信が通るか |
| 監視 | Logstash・DCR | 出力プラグインログとDCRメトリックを確認できるか |
| 監査 | 記録 | 影響なし、または変更内容を変更管理に残したか |
このチェックリストで「Logstashを使っていない」「Sentinelに該当構成がない」と確認できれば、今回は大きな対応をしなくてもよい可能性が高いです。一方で、該当構成を使っている場合は、設定変更の有無にかかわらず、ドキュメント更新日と確認結果を記録しておくと後日の説明が楽になります。
次に取るべき行動
今回のupdates2は、差分だけを見ると大規模な仕様変更ではなく、Microsoft SentinelのLogstash/DCRベースログ取り込みドキュメントの表記調整として扱うのが妥当です。ただし、対象ページはログ取り込み、DCR、認証、ネットワーク、監査証跡に関わるため、Sentinelを中核にしたセキュリティ運用では軽視すべきではありません。
まず、自社でLogstashからMicrosoft SentinelまたはLog Analyticsへログを送っているかを確認してください。使っていない場合は、今回の更新を情報共有レベルで記録すれば十分です。使っている場合は、Logstashバージョン、プラグイン、DCR、outputStream、認証方式、ネットワーク要件、監視方法を棚卸ししましょう。
ドキュメント更新を追う目的は、更新そのものに反応することではありません。公式情報の変化をきっかけに、自社のセキュリティログ基盤が「正しく取り込めているか」「調査に使える形になっているか」「監査に説明できるか」を確認することです。
コメント