2026年5月21日時点でMicrosoft Defender for Endpointの「Turn on network protection」を確認するなら、最初に押さえるべき結論は明確です。Windowsクライアントは監査モードで影響を確認してからブロックモードへ移行し、Windows Serverは先にAllowNetworkProtectionOnWinServerを有効化しないと、配布したポリシーが適用されたように見えても実際には無視される可能性があります。 Microsoft Defenderのネットワーク保護は、危険なドメインやIP、フィッシング、悪意あるコンテンツへのアクセスをアプリ単位ではなくOSレベルで抑止する機能です。Microsoft公式情報では、Group Policy、PowerShell、MDM、Microsoft Configuration Manager、Microsoft Defenderポータル、Intuneから有効化できます。(Microsoft Learn)
Microsoft Defenderのネットワーク保護で確認すべき影響範囲
Microsoft Defenderのネットワーク保護は、Microsoft Edgeだけを守る機能ではありません。Microsoft Defender SmartScreenの保護範囲を拡張し、低評価のドメインやホスト名に接続しようとするアウトバウンドHTTP/HTTPS通信をブロックできます。また、Microsoft Edge以外のブラウザや非ブラウザアプリにもWeb保護の考え方を広げられる点が重要です。(Microsoft Learn)
ただし、すべての通信を単純に同じ条件で見られるわけではありません。WindowsではMicrosoft Edgeは主にSmartScreen側で処理され、Microsoft Edge以外のブラウザやアプリではネットワーク保護が検査と制御に関わります。さらに、Web Content FilteringやカスタムインジケーターによるURL/IPブロックを実際に強制するには、ネットワーク保護をblockモードにする必要があります。(Microsoft Learn)
影響を受けやすい対象は次のとおりです。
| 対象 | 影響の例 | 展開前に見るべきポイント |
|---|---|---|
| 一般ユーザー端末 | 悪意あるサイト、フィッシングサイト、危険なダウンロード元へのアクセスがブロックされる | 業務WebサイトやSaaSが誤検知されないか |
| 開発者PC | CLI、PowerShell、ビルドツール、パッケージ取得処理の通信が検査対象になる | 社内リポジトリ、外部パッケージ配布元、CI/CD接続先 |
| サーバー | ドメインコントローラー、DNS、Exchange、SQL Serverなどで通信性能に影響する可能性 | UDP処理、プロキシ、業務通信のベースライン |
| 非Microsoft Edgeブラウザ | ChromeやFirefoxなどでHTTPS通信の検査条件に制約がある | QUICやEncrypted Client Helloの扱い |
| Configuration Manager管理端末 | ポリシー削除後もExploit Guard設定が残る場合がある | 移行時の設定残り、競合、解除手順 |
特に開発部門では、「ブラウザで見ていない通信」も止まる可能性を前提に検証してください。たとえば、PowerShellスクリプトが外部APIへ接続する処理、npmやNuGetなどの依存関係取得、社内プロキシ経由の検証環境アクセスは、監査モードでログを確認してから本番展開するのが安全です。
公式情報で特に押さえるべき変更点・強調点
今回の公式情報で管理者が最も注意すべきなのは、Windows Serverでの扱いです。Windows Serverではネットワーク保護がオプトイン機能として扱われ、Defender、Intune、SCCMなどからポリシーを配布しても、OS側でAllowNetworkProtectionOnWinServerを明示的に許可していない場合、Defenderエージェントがネットワーク保護の構成を無視すると説明されています。(Microsoft Learn)
もう一つの重要点は、Intuneのセキュリティベースラインを安易に使わないことです。Microsoft公式情報では、セキュリティベースラインはネットワーク保護以外の多数の推奨設定も同時に適用するため、ネットワーク保護だけを有効化したい場合はAntivirus policyまたはDevice configuration profileを使うべきだとされています。既存の端末管理設計がある組織では、ベースラインの一括適用によって不要な設定変更やポリシー競合が起きる可能性があります。(Microsoft Learn)
また、MDMで細かく制御する場合は、EnableNetworkProtectionだけでなく、Defender CSP側のサーバー許可、非同期検査、UDP検査、TLS/HTTP/SSH解析などの設定も確認が必要です。Defender CSPの公式ページは2026年5月8日更新表示となっており、ネットワーク保護関連の構成項目を確認できます。(Microsoft Learn)
有効化モードの違い：最初はAudit、最終的にはBlockを目指す
ネットワーク保護には、主に無効、監査、ブロックの3つの状態があります。いきなり全社でブロックモードにすると、業務アプリや開発ツールの通信に予期しない影響が出る可能性があります。まず監査モードでイベントを収集し、必要な許可設定を整えてから段階的にブロックするのが現実的です。
| モード | 何が起きるか | 使う場面 |
|---|---|---|
| Disabled | 危険なドメインへの接続をネットワーク保護ではブロックしない | 未導入、切り戻し、一時的な障害調査 |
| Audit mode | ブロックされるはずの通信を許可し、イベントログに記録する | 展開前検証、業務影響調査、例外候補の洗い出し |
| Block mode | 危険と判定された通信をブロックする | 本番適用、Web Content Filtering、カスタムインジケーター強制 |
PowerShellで監査モードにする場合は、管理者権限のPowerShellで次を実行します。
Set-MpPreference -EnableNetworkProtection AuditMode本番でブロックする場合は次のコマンドです。
Set-MpPreference -EnableNetworkProtection Enabled無効化する場合は次のようにします。
Set-MpPreference -EnableNetworkProtection DisabledMicrosoftの評価手順でも、監査モードを有効化して、どのIPアドレスやドメインがブロック対象になるかを確認する流れが示されています。イベントビューアーでは、設定変更が5007、監査が1125、ブロックが1126として記録されます。(Microsoft Learn)
管理方法別の設定ポイント
ネットワーク保護は複数の管理方法で有効化できます。重要なのは、「どの方法でもよい」ではなく、組織の端末管理方式に合わせて単一の管理経路を決めることです。同じ設定をIntune、Group Policy、Configuration Manager、PowerShellで重複管理すると、競合や切り戻し漏れの原因になります。
| 管理方法 | 向いている環境 | 設定の要点 | 注意点 |
|---|---|---|---|
| Microsoft DefenderポータルのEndpoint security policy | Defender for Endpoint中心で管理している環境 | Windows向けMicrosoft Defender AntivirusテンプレートでEnable network protectionを設定 | 手順にはMicrosoft Entra IDのSecurity Administratorロールが必要 |
| Microsoft Intune | Intuneで端末管理している組織 | Antivirus policyまたはDevice configuration profileで設定 | ベースラインだけを目的に使うと他の推奨設定も入る |
| Group Policy | ドメイン参加PC、オンプレAD中心の環境 | Prevent users and apps from accessing dangerous websitesを有効化し、オプションでBlockを選ぶ | ポリシーをEnabledにするだけでは不十分。Blockの選択が必要 |
| PowerShell | 検証端末、少数展開、サーバー個別対応 | Set-MpPreferenceでAudit/Enabled/Disabledを切り替える | サーバーでは追加設定が必要 |
| MDM/CSP | 独自MDM、細かい構成管理 | EnableNetworkProtection CSPで0/1/2を指定 | 値の意味と対象OSを確認する |
| Microsoft Configuration Manager | ConfigMgrでEndpoint Protectionを管理している環境 | Exploit Guard PolicyのNetwork ProtectionでBlock/Audit/Disabledを選ぶ | 配布解除後も設定が残る場合がある |
Group Policyでは、Computer configuration > Administrative templates > Windows components > Microsoft Defender Antivirus > Microsoft Defender Exploit Guard > Network protectionに進み、Prevent users and apps from accessing dangerous websitesを開きます。完全に有効化するにはポリシーをEnabledにしたうえで、オプションのドロップダウンからBlockを選択する必要があります。(Microsoft Learn)
Windows Serverでは追加設定を忘れない
Windows Serverでネットワーク保護を展開する場合、クライアントPCと同じ設定だけでは不十分です。公式情報では、Windows Server 2019以降は次の追加コマンドが示されています。(Microsoft Learn)
Set-MpPreference -AllowNetworkProtectionOnWinServer $trueWindows Server 2016およびWindows Server 2012 R2でMicrosoft Defender for Endpointの統合エージェントを使う場合は、次の設定も必要です。
Set-MpPreference -AllowNetworkProtectionDownLevel $true
Set-MpPreference -AllowNetworkProtectionOnWinServer $trueサーバー展開で見落としやすいのが、UDPトラフィックの処理です。公式情報では、ドメインコントローラー、Windows DNSサーバー、Windows File Server、Microsoft SQL Server、Microsoft Exchange Serverなど、大量のUDPトラフィックを生成するサーバーロールでは、Allow Datagram Processing On Win Serverを無効のままにすることが強く推奨されています。有効化すると、ネットワーク性能や信頼性に影響する可能性があります。(Microsoft Learn)
サーバー展開では、次の順序で進めると失敗しにくくなります。
| 手順 | 実施内容 | 判断基準 |
|---|---|---|
| 事前調査 | サーバーロール、通信量、プロキシ、DNS、既存Defender設定を確認 | DC、DNS、Exchange、SQLは個別検証対象にする |
| 監査モード | 代表サーバーだけにAudit modeを適用 | Event ID 1125やAdvanced Huntingで業務通信を確認 |
| 例外対応 | 必要に応じて許可インジケーターや構成見直し | 安易にプロセス全体除外にしない |
| 段階展開 | 低リスクサーバーからBlock modeへ移行 | 性能、認証、名前解決、メール配送を監視 |
| 本番拡大 | サーバー群ごとに段階適用 | 変更前後のメトリックを比較 |
MDMとCSPで確認すべき値
MDMでネットワーク保護を有効化する場合、Policy CSPのEnableNetworkProtectionを使います。公式情報では、パスは次のように示されています。(Microsoft Learn)
./Device/Vendor/MSFT/Policy/Config/Defender/EnableNetworkProtection指定値は次のとおりです。
| 値 | 意味 |
| – | —————— |
| 0 | Disabled |
| 1 | Enabled、block mode |
| 2 | Enabled、audit mode |
Windows Server向けの許可やパフォーマンス関連設定は、Defender CSP側も確認します。たとえば、AllowNetworkProtectionOnWinServerはWindows Serverでネットワーク保護をblockまたはauditに設定できるかを制御し、falseの場合はEnableNetworkProtectionの値が無視されると説明されています。(Microsoft Learn)
./Device/Vendor/MSFT/Defender/Configuration/AllowNetworkProtectionOnWinServer
./Device/Vendor/MSFT/Defender/Configuration/AllowNetworkProtectionDownLevel
./Device/Vendor/MSFT/Defender/Configuration/DisableDatagramProcessing
./Device/Vendor/MSFT/Defender/Configuration/AllowSwitchToAsyncInspectionさらに、TLS、HTTP、SSH、DNS over TCPなどの解析を無効化する設定もあります。ただし、これらは単に「トラブルが起きたから全部無効化する」ものではありません。通信性能や互換性の問題を切り分ける目的で、影響範囲を確認しながら段階的に使うべき設定です。(Microsoft Learn)
Intune展開で失敗しやすいポイント
IntuneでMicrosoft Defenderのネットワーク保護を展開する場合、もっとも避けたいのは「セキュリティベースラインを使えば早い」という判断です。すでに別のポリシーでDefenderやAttack Surface Reductionを管理している環境では、ベースライン適用により意図しない設定が一緒に入ることがあります。ネットワーク保護だけを有効化したいなら、Endpoint securityのAntivirus policy、またはDevice configuration profileで対象設定を絞るほうが安全です。(Microsoft Learn)
Microsoft Defender for Endpoint Security Settings Managementを使う場合も、ポリシー競合に注意が必要です。Microsoftの公式情報では、同じ設定を管理する複数ポリシーを同一デバイスへ展開することを避けるよう案内されています。また、デバイスは通常90分ごとにIntuneへチェックインし、Defenderポータルから手動同期できる場合もあります。(Microsoft Learn)
展開前に確認したいチェック項目は次のとおりです。
| 確認項目 | なぜ重要か |
|---|---|
| 同じ端末にGPOとIntuneが同時適用されていないか | 有効・無効・監査の競合が起きる |
| セキュリティベースラインで他設定も変わらないか | ネットワーク保護以外の影響が出る |
| 対象グループにサーバーや開発者端末が混ざっていないか | 業務通信への影響が大きい端末を誤って一括適用しやすい |
| Block modeを必要とする機能か | Web Content Filteringやカスタムインジケーターはblock modeが必要 |
| 監査ログを見る担当者が決まっているか | Audit modeのまま放置されるのを防ぐ |
Configuration Managerから移行する場合の注意点
Microsoft Configuration ManagerでExploit Guard Policyを展開している環境では、Network ProtectionタブでBlock、Audit、Disabledを選んで配布できます。問題は、あとから配布を外したときです。公式情報では、Configuration Managerで展開したExploit Guardポリシーは、配布を削除してもクライアント上に設定が残る場合があると説明されています。(Microsoft Learn)
そのため、Configuration ManagerからIntuneやDefender Security Settings Managementへ移行するときは、次の流れにしてください。
- 既存のExploit Guard PolicyでNetwork Protectionが設定されている端末を棚卸しする
- Configuration Manager、GPO、Intune、PowerShellのどれが最終的な管理元か決める
- 重複するポリシーを外す前に、現状の
EnableNetworkProtection値を記録する - 移行先ポリシーをAudit modeで先に配布する
- 設定解除後もレジストリや
Get-MpPreferenceで残留設定を確認する
「旧ポリシーを削除したから無効になったはず」と判断しないことが重要です。移行作業では、ポリシーの削除ではなく、端末上の実効設定まで確認してください。
有効化後の確認方法
ネットワーク保護が有効かどうかは、レジストリで確認できます。公式情報では、次の場所にあるEnableNetworkProtectionを確認する手順が示されています。(Microsoft Learn)
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender\Policy Manager存在しない場合は、次の場所も確認します。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Windows Defender Exploit Guard\Network Protection値の意味は次のとおりです。
| 値 | 状態 |
| – | ———- |
| 0 | Off |
| 1 | On |
| 2 | Audit mode |
PowerShellで確認する場合は、次のようにGet-MpPreferenceを使うと運用しやすくなります。
Get-MpPreference | Select-Object EnableNetworkProtectionMicrosoft DefenderポータルのAdvanced Huntingを使える環境では、次のようなクエリで監査・ブロックイベントを確認できます。公式情報では、ネットワーク保護の監査イベントはExploitGuardNetworkProtectionAudited、ブロックはExploitGuardNetworkProtectionBlockedとして示されています。(Microsoft Learn)
DeviceEvents
| where ActionType in ('ExploitGuardNetworkProtectionAudited','ExploitGuardNetworkProtectionBlocked')
| project Timestamp, DeviceName, ActionType, RemoteUrl, InitiatingProcessFileName
| sort by Timestamp desc検証用サイトを使う場合は、Microsoftが評価手順で示しているテストサイトを使えます。実際の悪性サイトではなく、動作確認用に作成されたサイトです。(Microsoft Learn)
https://smartscreentestratings2.net開発者・情シスが見落としやすい通信とブラウザ設定
ネットワーク保護を有効化すると、開発者やSREが使うツールにも影響する場合があります。特に、外部のパッケージレジストリ、CI/CD、APIモック、クラウド管理CLI、PowerShellスクリプトの通信は、ブラウザでアクセスしていないため見落とされがちです。
また、非Microsoft EdgeブラウザではHTTPS接続のFQDN判定にTLSハンドシェイクの情報が関係します。公式情報では、非Microsoft EdgeブラウザでFQDNをブロックするには、QUICとEncrypted Client Helloを無効化する必要があると説明されています。ネットワーク保護が有効なのにChromeやFirefoxで期待どおりブロックされない場合は、QUIC、HTTP/3、ECHの設定を確認してください。(Microsoft Learn)
開発者端末では、次の観点で例外要否を判断します。
| 確認対象 | 具体例 | 判断基準 |
|---|---|---|
| パッケージ取得先 | npm、NuGet、PyPI、Maven、GitHub関連通信 | 公式レジストリか、社内ミラー経由か |
| CI/CD | GitHub Actions、Azure DevOps、Jenkins連携 | ビルド失敗がネットワーク保護イベントと一致するか |
| 社内開発環境 | 検証API、ステージング、社内証明書サイト | ドメイン評価が不明扱いになっていないか |
| 管理スクリプト | PowerShell、curl、独自CLI | 実行プロセス名とRemoteUrlをログで確認する |
| プロキシ | PAC、固定プロキシ、SSLインスペクション | Defenderがクラウドサービスへ到達できるか |
例外を作る場合は、広すぎるプロセス除外よりも、可能な限りURL、ドメイン、IPの許可インジケーターで範囲を絞るほうが安全です。誤検知や未検知が疑われる場合、Microsoft公式情報ではカスタム許可インジケーター、IP除外、プロセス除外、サポートログ提出などの選択肢が示されています。(Microsoft Learn)
トラブル時の切り分け手順
ネットワーク保護の展開後に「安全なサイトがブロックされる」「危険なサイトがブロックされない」「サーバー通信が遅くなった」といった問題が起きた場合は、いきなり無効化するのではなく、原因を分けて確認します。
まず、前提条件を確認してください。Microsoft公式のトラブルシューティングでは、Microsoft Defender Antivirusが主たるウイルス対策として動作していること、リアルタイム保護、Behavior Monitoring、Cloud-delivered protection、クラウド保護への接続性が有効であることが確認項目として挙げられています。(Microsoft Learn)
次に、Audit modeへ切り替えて、問題の通信がブロック対象として記録されるかを確認します。
Set-MpPreference -EnableNetworkProtection AuditModeサーバー性能問題では、ドメインコントローラーやExchangeサーバーへの接続が遅くなるケースが想定されています。公式情報では、問題切り分けのためにDatagram Processing、Performance Telemetry、FTP/SSH/RDP/HTTP/SMTP/DNS/TLS解析などを順番に確認する流れが示されています。すべてを一括で無効化すると、どの機能が原因だったか分からなくなるため、1項目ずつ検証してください。(Microsoft Learn)
プロキシ環境では、ネットワーク保護がOSのプロキシ設定を認識できず、クラウドサービスへ到達できない場合があります。その場合は、Set-MpPreference -ProxyServerまたはSet-MpPreference -ProxyPacUrlでDefender側にプロキシを認識させる方法が案内されています。(Microsoft Learn)
展開前に管理者が作るべき実行チェックリスト
全社展開前には、次のチェックリストを使うと抜け漏れを減らせます。
| チェック | 実施内容 |
|---|---|
| 対象端末の分類 | Windowsクライアント、Windows Server、VDI、開発者端末、管理端末を分ける |
| 管理経路の決定 | Intune、GPO、Configuration Manager、Defender Security Settings Managementのどれで管理するか決める |
| 既存設定の棚卸し | GPO、Intune、ConfigMgr、ローカルPowerShell設定の重複を確認する |
| 監査モードの期間設定 | 監査ログを見る期間と担当者を決める |
| 例外ルールの方針 | 許可インジケーターを優先し、プロセス除外は最小限にする |
| サーバー追加設定 | AllowNetworkProtectionOnWinServerとDownLevel設定を確認する |
| ブラウザ設定 | QUIC、HTTP/3、Encrypted Client Helloの影響を確認する |
| ロールバック手順 | Disabledへの切り替え、影響端末の特定、設定残りの確認方法を決める |
| 本番判定 | Event ID 1125/1126、Advanced Hunting、ヘルプデスク問い合わせを確認する |
実務では、「監査モードを入れた」だけでは不十分です。監査モードで収集したイベントを、端末種別、プロセス名、通信先、業務影響の有無で分類し、ブロックモードへ移る判断材料にする必要があります。
まとめ：ネットワーク保護は段階展開とサーバー設定が成功の鍵
Microsoft Defender for Endpointのネットワーク保護は、危険なドメインやIPへの接続をOSレベルで抑止できる重要な防御機能です。一方で、非Microsoft Edgeブラウザ、開発ツール、PowerShell、サーバー通信、プロキシ環境にも影響するため、単純に「有効化すれば終わり」ではありません。
管理者が次に取るべき行動は、まず現在の管理経路を整理し、WindowsクライアントとWindows Serverを分けてAudit modeを展開することです。その後、イベントログとAdvanced Huntingで影響を確認し、必要な許可設定を整えてからBlock modeへ移行してください。Windows ServerではAllowNetworkProtectionOnWinServerを忘れず、ドメインコントローラーやDNS、Exchange、SQL Serverなど高トラフィックのサーバーロールではUDP処理と性能影響を必ず確認しましょう。
コメント