Microsoft Defender環境でMicrosoft Sentinelを使っている管理者にとって、今回のポイントは「Azure Virtual Network flow logsをMicrosoft Sentinelへ連携し、ネットワーク通信の可視化・検知・調査に使いやすくなった」ことです。2026年5月27日にAzure Updatesで公開された「Virtual network flow logs connector with Microsoft Sentinel」の一般提供により、Azure上の通信ログをSOCの調査フローへ組み込みやすくなりました。特に、侵害調査、ポートスキャン検知、RDPブルートフォース検知、異常な外向き通信の確認をSentinel側で進めたい組織は、優先的に確認すべき更新です。(Microsoft Azure)
ただし、これは「Microsoft DefenderのAI/Copilot機能が単体で増えた」という更新ではありません。実務上は、Microsoft Defenderポータルに集約されていくSentinel運用の中で、Azureネットワークのフローデータをより扱いやすくするためのセキュリティ運用基盤の強化と捉えるのが正確です。
Microsoft DefenderとSentinel運用で何が変わるのか
今回一般提供されたのは、Azure Virtual Network flow logsとMicrosoft Sentinelを連携するためのコネクタです。Virtual Network flow logsはAzure Network Watcherの機能で、仮想ネットワークを流れるIPトラフィックの情報を記録できます。Microsoftの説明では、フローデータはAzure Storageへ送信され、可視化ツール、SIEM、IDSなどへエクスポートして利用できます。(Microsoft Learn)
これまでもネットワークログをSentinelで扱うことは可能でしたが、実務では「どのログをどのワークスペースへ入れるか」「Traffic Analyticsをどう有効化するか」「検知ルールをどう作るか」が運用負荷になりがちでした。今回の連携では、Traffic Analyticsで処理・集約されたネットワークフローデータをMicrosoft Sentinelで分析しやすくし、ASIMベースのパーサーによる正規化、相関分析、脅威検出に活用できる点が重要です。(aka.ms)
| 観点 | これまで課題になりやすかった点 | 今回の更新で期待できること |
|---|---|---|
| ネットワーク可視化 | Azureネットワークの通信状況がSOCの調査画面と分断されやすい | Sentinelの調査・検知ワークフローに組み込みやすい |
| 検知 | ポートスキャン、異常通信、ブルートフォースなどを個別に設計する必要がある | ネットワーク系の分析ルールやハンティングに活用しやすい |
| 調査 | IP、ポート、通信方向、通信量を別画面で追う手間がある | インシデント調査時に通信の文脈を参照しやすい |
| 運用 | NSG単位のログ設定や重複収集でコストが膨らみやすい | VNet単位で監視範囲を整理しやすい |
一般提供になったことの意味
Azure Updatesのステータス「Launched」は、実稼働向けに完全リリースされ、Azure顧客が利用できる状態を示します。つまり今回の更新は、検証環境だけで試す段階から、本番のセキュリティ運用に組み込むかを判断する段階に進んだと考えられます。(Microsoft Azure)
管理者が見るべきポイントは、「今すぐ全VNetで有効化するか」ではありません。まずは、守るべき重要システム、外部公開経路、管理用通信、オンプレミス接続、ExpressRouteやVPN Gateway周辺など、調査価値が高い通信から対象を決めることです。
特に次のような環境では、導入効果が出やすくなります。
- Azure上に基幹システムや公開Webシステムを置いている
- Microsoft SentinelをSIEMとして運用している
- Microsoft Defenderポータルでインシデント管理を進めている、または移行予定がある
- NSGフローログを使っているが、監視範囲やコスト整理に課題がある
- SOCやCSIRTがIPアドレス、ポート、通信方向、通信量を調査に使っている
一方で、小規模な検証環境や通信量の少ない環境では、すぐに大きな効果が見えない場合もあります。重要なのは、ログを増やすことではなく「検知・調査に使う通信データを選ぶ」ことです。
Virtual Network flow logsとは何か
Virtual Network flow logsは、Azure仮想ネットワークを流れるIPトラフィックを記録するAzure Network Watcherの機能です。Layer 4の通信を対象に、ネットワークインターフェイス、5タプル情報、通信方向、フロー状態、暗号化状態、スループット情報などを記録します。Microsoft Learnでは、1分間隔でAzureプラットフォームにより収集され、Azureリソースやネットワークトラフィックに影響しないと説明されています。(Microsoft Learn)
実務での使い道は、単なる通信ログの保存にとどまりません。たとえば、次のような場面で役立ちます。
| 活用シーン | 確認したいこと | 具体例 |
|---|---|---|
| 侵害調査 | 侵害端末がどこへ通信していたか | 不審VMから外部IPへの周期的な通信を確認する |
| 通信棚卸し | 想定外の経路がないか | 本来DBへ接続しないサブネットからの通信を見つける |
| 監査・準拠 | 分離されたネットワークが守られているか | 本番・検証環境間の通信有無を確認する |
| コスト・性能分析 | 通信量が急増していないか | 特定ワークロードの帯域増加を把握する |
| ルール改善 | NSGや管理ルールが適切か | 許可・拒否された通信を見て過剰なルールを見直す |
NSGフローログとの違い
既存環境で特に注意したいのが、NSGフローログとの違いです。Virtual Network flow logsとNSGフローログはいずれもIPトラフィックを記録しますが、監視の単位とカバー範囲が異なります。
Virtual Network flow logsは仮想ネットワーク単位で有効化でき、サポートされるワークロードの通信をまとめて記録しやすいのが特徴です。一方、NSGフローログはネットワークセキュリティグループを対象にするため、サブネットやNICに関連付くNSGの構成を意識する必要があります。Microsoftは、同じ基盤ワークロードに対してNSGフローログとVirtual Network flow logsを重ねて有効化すると、重複記録や追加コストにつながるため、Virtual Network flow logsを有効化する前にNSGフローログを無効化することを推奨しています。(Microsoft Learn)
| 比較項目 | NSGフローログ | Virtual Network flow logs |
|---|---|---|
| 主な対象 | ネットワークセキュリティグループ | 仮想ネットワーク、サブネット、ネットワークインターフェイス |
| 設計の考え方 | NSG単位で通信を把握 | VNet単位で通信を把握しやすい |
| 重複リスク | サブネット・NICの構成によって複雑化しやすい | NSGフローログとの併用時に注意が必要 |
| 向いている用途 | NSGルールの確認、既存運用の継続 | 広いネットワーク可視化、Sentinel連携、調査基盤の整理 |
既存のNSGフローログを使っている場合は、「置き換えるか」「一部だけ残すか」「保持期間を変えるか」を設計してから展開してください。両方を何となく有効にすると、ログ量とコストだけが増えて、SOCの分析品質は上がらないという失敗につながります。
Microsoft Sentinelでできる検知・調査
Traffic AnalyticsとMicrosoft Sentinelを連携すると、ネットワークフローデータをセキュリティ運用に組み込みやすくなります。Microsoft Learnでは、Traffic AnalyticsがVirtual Network flow logsを処理・集約し、脅威インテリジェンス、地理情報、トポロジの文脈でデータを拡張すると説明されています。Sentinel側ではASIMベースのパーサーによりデータを正規化し、相関分析、調査、脅威検出に利用できます。(aka.ms)
実際に有効活用しやすい検知例は次の通りです。
| 検知・調査対象 | 見るべき通信の例 | 管理者の対応例 |
|---|---|---|
| RDPブルートフォース | 3389番ポートへの失敗接続が短時間に多発 | 送信元IPの遮断、JITアクセス確認、管理ポート公開の見直し |
| ポートスキャン | 1つの送信元が多数の宛先ポートへ接続 | 外部公開範囲、NSG、Firewallルールを確認 |
| 外部からのポートスイープ | 外部送信元が同一ポートで複数IPへ接続 | 攻撃元のブロック、公開IPの棚卸し |
| SMB通信の異常 | 通常より多い445番通信 | 横展開の疑いを調査、端末隔離を検討 |
| ビーコン通信 | 一定間隔で外部へ繰り返す通信 | C2通信の可能性を確認、Defenderアラートと突合 |
| ポートの誤用 | 普段使わないポートの利用増加 | アプリ変更か不正通信かを確認 |
ここで重要なのは、ログを入れただけでは検知品質は上がらないという点です。初期状態の分析ルールをそのまま使うのではなく、自社の通常通信に合わせてしきい値、除外条件、監視対象サブネットを調整してください。
たとえば、バックアップサーバーや監視基盤は通信量が多く、異常検知に引っかかりやすい場合があります。こうした既知の大量通信を除外せずに運用すると、SOCはノイズ対応に追われます。逆に、管理用サブネットや重要DBサブネットでは、少量の想定外通信でも重大な兆候になるため、厳しめの検知条件を設定する価値があります。
影響範囲：誰が確認すべきか
今回の更新は、Microsoft Defenderを日常的に使うエンドユーザーよりも、Azure、Sentinel、SOC運用に関わる管理者への影響が大きい内容です。
| 役割 | 確認すべきこと |
|---|---|
| セキュリティ管理者 | Sentinelのワークスペース、分析ルール、インシデント運用にネットワークフローをどう組み込むか |
| Azure管理者 | Network Watcher、Virtual Network flow logs、Storage、Log Analytics、Traffic Analyticsの構成 |
| SOCアナリスト | 新しいネットワーク系アラートの調査手順、ノイズ除外、優先度付け |
| ネットワーク担当者 | VNet、サブネット、NSG、VPN、ExpressRoute、Firewallとの関係 |
| 開発・運用チーム | アプリ通信の通常パターン、リリース時の通信変化、誤検知時の連絡経路 |
| コスト管理担当 | ログ収集量、Traffic Analytics処理量、Storage保持期間、Sentinel取り込みコスト |
特に見落としやすいのは、開発チームとの連携です。アプリケーションの通信仕様を知らないままSOCだけで分析ルールを作ると、正規のバッチ処理や外部API連携を不審通信として扱ってしまう可能性があります。導入時は、重要システムごとに「通常の通信先」「使用ポート」「許容される時間帯」「通信量の目安」を整理しておくと、運用開始後の誤検知を減らせます。
管理者が確認すべき設定
Virtual Network flow logs connector with Microsoft Sentinelを活用する前に、次の設定を順番に確認しましょう。
| 確認項目 | チェック内容 | 注意点 |
|---|---|---|
| 対象VNet | どの仮想ネットワークを監視するか | いきなり全VNetに展開せず、重要度で優先順位を付ける |
| Network Watcher | 対象リージョンで利用できるか | リージョンごとの対応状況を確認する |
| Microsoft.Insights | リソースプロバイダーが登録済みか | 未登録だとフローログ設定でつまずく |
| Storage Account | フローログの保存先があるか | 保持期間、暗号化、アクセス制御を確認 |
| Traffic Analytics | フローログに対して有効化するか | 有効化すると分析しやすくなるが、処理コストも確認する |
| Log Analytics Workspace | Sentinelと同じワークスペースか | Traffic Analyticsで使うワークスペースとSentinelの関係を整理 |
| Microsoft Sentinel | ワークスペースで有効化済みか | Microsoft Defenderポータルでの運用も見据える |
| Content Hub | Network Session Essentialsなど必要なコンテンツ | 分析ルール、Workbook、ハンティングクエリを確認 |
| Analytics rules | 有効化する検知ルール | 初期値のまま本番化せず、しきい値と除外条件を調整 |
Microsoft Learnの手順では、Virtual Network flow logsの作成にあたり、Azureアカウント、Microsoft.Insightsプロバイダー、仮想ネットワーク、Azure Storage Accountが前提として示されています。また、Traffic Analyticsを有効にする場合は、Log Analytics Workspaceの選択が必要です。(Microsoft Learn)
展開時のおすすめ手順
本番環境で安全に展開するなら、次の順序が現実的です。
| フェーズ | 作業内容 | 完了条件 |
|---|---|---|
| 現状把握 | NSGフローログ、Traffic Analytics、Sentinelワークスペースの利用状況を棚卸し | どのVNet・NSGで既にログ収集しているか分かる |
| 対象選定 | 重要VNet、外部公開VNet、管理用VNetを優先順位付け | 最初に有効化する範囲が決まる |
| 小規模検証 | 1〜2個のVNetでVirtual Network flow logsを有効化 | ログ量、遅延、検知ノイズを確認できる |
| Sentinel連携 | Traffic AnalyticsとSentinelの連携、Content Hubコンテンツの導入 | アラートやWorkbookでデータを確認できる |
| ルール調整 | 分析ルールのしきい値、除外条件、インシデント分類を調整 | SOCが対応可能なアラート量に収まる |
| 段階展開 | 本番VNetへ順次展開 | コスト・アラート・調査手順を管理しながら拡大 |
| 運用定着 | 定例レビュー、検知ルール改善、ログ保持方針の見直し | 月次でノイズと検知漏れを改善できる |
最初の検証では、ログ量を必ず確認してください。Virtual Network flow logsはVNetレベルで広く通信を拾えるため、ゲートウェイや高トラフィックなワークロードを含む環境では、想定よりログ量が増える場合があります。Microsoft Learnでも、Virtual Network flow logsはネットワークセキュリティ境界を越えてログ範囲を広げるため、より狭い範囲のフローログ設定と比べてログ量が多くなる可能性があると説明されています。(Microsoft Learn)
移行・置き換えで失敗しやすいポイント
NSGフローログを残したまま重複収集する
最も起きやすい失敗は、既存のNSGフローログを残したままVirtual Network flow logsを追加することです。重複記録により、Storageや分析基盤のコストが増え、調査時にも同じ通信が複数の形で見えて混乱します。
移行時は、次の3つを必ず確認してください。
- 既存のNSGフローログがどのNSGで有効になっているか
- Virtual Network flow logsの対象VNetやサブネットと重なっていないか
- Sentinel側のクエリや分析ルールが旧ログ前提になっていないか
いきなりNSGフローログを全停止するのではなく、対象VNetごとに並行検証期間を短く設け、ログ内容・検知結果・コストを比較してから切り替えるのが安全です。
ワークスペース設計を確認せずに有効化する
Traffic AnalyticsとSentinelのワークスペースが分散していると、分析ルールやWorkbookの管理が複雑になります。組織によっては、環境別、部門別、リージョン別にLog Analytics Workspaceを分けていることがあります。
この場合は、次の基準で設計を見直してください。
| 判断基準 | 推奨される考え方 |
|---|---|
| SOCが一元監視したい | Sentinelの中核ワークスペースへ集約する設計を検討 |
| データ主権や部門分離が必要 | ワークスペース分割を維持し、横断クエリや運用手順を整理 |
| コスト管理を重視 | 高トラフィック環境と重要監視環境を分ける |
| 権限分離が必要 | RBAC、テーブルアクセス、運用担当範囲を明確化 |
分析ルールを有効化しただけで満足する
Microsoft SentinelのContent Hubからネットワーク関連の分析ルールを導入できても、それだけで運用が完成するわけではありません。初期ルールは汎用的に作られているため、自社環境の通常通信を学習・調整する期間が必要です。
たとえば、開発環境ではポートスキャンに似た挙動がテストで発生することがあります。社内監視ツールが多数のVMへ定期的に接続する場合もあります。これらを除外しないまま本番SOCへ流すと、重要なアラートがノイズに埋もれます。
導入後2〜4週間は、次の観点でチューニングしてください。
- 誤検知が多い送信元IPやサブネット
- 業務上正当な大量通信
- 深夜・休日に発生する定期処理
- 監視対象から除外すべき検証環境
- 優先度を上げるべき管理系通信や外部公開通信
コスト面で確認すべきこと
Virtual Network flow logsは、収集されるネットワークフローログのGB単位で課金され、無料枠やTraffic Analytics、Storageに関する料金条件があります。Microsoft Learnでは、Virtual Network flow logsはサブスクリプションごとに月5GBの無料枠があり、Traffic Analyticsを有効化した場合はTraffic Analyticsの処理料金が別途適用され、Storageの保存料金も別に発生すると説明されています。(Microsoft Learn)
コストを抑えるには、次のように考えると実務的です。
| コスト要因 | 対策 |
|---|---|
| 高トラフィックVNetのログ量 | 重要度に応じて対象を絞る |
| 重複ログ | NSGフローログとの重複を避ける |
| Storage保持期間 | 監査要件に合わせて必要最小限にする |
| Traffic Analytics処理量 | 最初は限定範囲で有効化し、処理量を確認 |
| Sentinel側の分析・保持 | 長期保持が必要なデータと短期調査用データを分ける |
セキュリティログは「多ければ安全」ではありません。調査に使わないログを長期間保持しても、コストと検索負荷が増えるだけです。重要サブネット、外部公開経路、管理系通信など、検知価値の高い場所から始めるのが現実的です。
Microsoft Defenderポータルへの移行も合わせて確認する
今回の更新を確認する際は、Microsoft Sentinelのポータル移行も無視できません。Microsoft SentinelはMicrosoft Defenderポータルで一般提供されており、Microsoft Defender XDRやE5ライセンスがない顧客でもDefenderポータル上で利用できます。また、2027年3月31日以降、Microsoft SentinelはAzure portalではサポートされず、Microsoft Defenderポータルでのみ利用可能になると案内されています。(Microsoft Learn)
つまり、Virtual Network flow logs connector with Microsoft Sentinelをこれから本番運用に組み込むなら、Azure portalだけを前提に手順書や教育資料を作らない方が安全です。今後のSOC運用は、Microsoft Defenderポータルでのインシデント管理、調査、Sentinelデータ活用を前提に整備しておくべきです。
確認すべき項目は次の通りです。
- DefenderポータルでSentinelワークスペースを参照できるか
- SOCアナリストに必要な権限が付与されているか
- 既存のWorkbook、Analytics rule、Hunting queryが想定どおり使えるか
- インシデントの運用手順がAzure portal前提になっていないか
- 画面遷移、調査フロー、エスカレーション手順を更新したか
特に、運用手順書にAzure portalの画面キャプチャが多い組織は早めに見直してください。機能そのものよりも、現場の操作手順が古いことが移行時の混乱につながります。
開発者・運用担当者が確認すべきこと
開発者にとっても、今回の更新は無関係ではありません。ネットワークフローがSOCに取り込まれると、アプリケーションの通信パターンがセキュリティ監視の対象としてより見えやすくなります。
開発・運用チームは、次の情報をセキュリティチームへ共有しておくと、誤検知を減らせます。
| 共有すべき情報 | 例 |
|---|---|
| 正常な通信先 | 外部API、SaaS、決済サービス、監視サービス |
| 使用ポート | HTTPS以外に使う独自ポート、管理ポート |
| 通信時間帯 | 夜間バッチ、月次処理、バックアップ時間 |
| 通信量の目安 | 通常時とピーク時の差 |
| リリース時の変化 | 新しい外部連携、通信経路変更、データ移行作業 |
| 例外通信 | 一時的な検証、脆弱性診断、負荷試験 |
たとえば、リリース直後に新しい外部APIへの通信が増えた場合、SOC側では「未知の外向き通信」と見えることがあります。事前に変更内容を共有しておけば、アラート発生時の切り分けが速くなります。
導入前チェックリスト
本番展開前に、最低限次の項目を確認してください。
| チェック項目 | 確認結果 |
|---|---|
| 監視対象のVNet、サブネット、重要ワークロードを決めた | 未確認なら最初に棚卸しする |
| 既存のNSGフローログ設定を確認した | 重複収集を避ける |
| Microsoft.Insightsプロバイダーを確認した | 未登録なら登録する |
| Storage Accountの保持期間とアクセス制御を決めた | 長期保持の理由を明確にする |
| Traffic Analyticsを有効化する範囲を決めた | いきなり全体展開しない |
| Sentinelワークスペースとの関係を整理した | 分散ワークスペースは運用設計が必要 |
| Content Hubのネットワーク関連コンテンツを確認した | 必要な分析ルールを選定する |
| SOCの対応手順を作成した | アラートを誰が見るか決める |
| 開発・運用チームから正常通信情報を集めた | 誤検知を減らす |
| コストの初期見積もりと見直し日を設定した | 1か月後に実績確認する |
今回の更新をどう扱うべきか
Virtual network flow logs connector with Microsoft Sentinelの一般提供は、Microsoft Defenderポータルへ統合されていくセキュリティ運用において、Azureネットワークの可視化を強化する重要な更新です。エンドユーザーの画面が大きく変わる種類の更新ではありませんが、SOC、Azure管理者、ネットワーク担当者にとっては、調査の質と速度に影響します。
まず実施すべきことは、全社展開ではなく「現状のログ収集と監視対象の棚卸し」です。次に、重要VNetを1つ選び、Virtual Network flow logs、Traffic Analytics、Microsoft Sentinelの連携を小さく検証します。そのうえで、検知ルール、除外条件、コスト、運用手順を調整し、段階的に対象を広げてください。
今回の更新をうまく使える組織は、単にログを増やす組織ではありません。どの通信を監視すべきか、どのアラートをSOCが対応すべきか、どの情報を開発チームと共有すべきかを決められる組織です。Microsoft DefenderとMicrosoft Sentinelの統合運用を進めるなら、ネットワークフローを「保存するログ」ではなく「調査に使う証拠」として設計することが、最も大きな効果につながります。
コメント