Windows 11を特定用途のEdge PCとして運用していると、

このPC、本当にこんなに通信する必要があるのか？

と思うことがあります。

Windows 11には標準状態でも、

Network Discovery
Remote Assistance
Wi-Fi Direct
Wireless Display
Media Streaming
mDNS
UPnP / SSDP
Teams
Xbox
Hyper-V
Connected Devices Platform

など、一般的なPCとして便利に使うための機能やFirewall Ruleが多数存在します。

しかし、

接続機器
↓
Edge PC
↓
Cloud

という用途に限定された端末では、そのすべてが必要とは限りません。

今回は、Windows 11 Proを搭載したEdge PCで、

業務上必要な通信は残し、使用しないWindows標準機能の通信を減らす

という方針でWindows Defender Firewallを整理した事例をまとめます。

結論：Firewall Ruleは「PCの役割」から逆算する

今回のEdge PCで必要だった主な通信は、次の2つです。

接続機器
↓
TCP 57545
↓
Edge PC

そして、

Edge PC
↓
TCP 443
↓
Cloud

整理すると次のようになります。

通信	Direction	Port	用途
接続機器 → Edge PC	Inbound	TCP 57545	データ受信
Edge PC → Cloud	Outbound	TCP 443	Cloud通信

つまり、考え方としては、

必要な業務通信
↓
維持する

使用しないWindows機能
↓
Firewall Ruleを整理する

です。

重要なのは、

「不要そうなRuleを全部止める」ことではありません。

そのPCで何を動かすのかを先に決め、その役割からFirewallを逆算します。

Windows 11のFirewall Ruleを確認する

Windows Defender Firewallの詳細設定は、次の場所から確認できます。

Control Panel
↓
System and Security
↓
Windows Defender Firewall
↓
Advanced settings

ここには、

Inbound Rules
Outbound Rules

があります。

実際に確認すると、Windows 11にはかなり多くのRuleが存在します。

例えば、

Network Discovery
Remote Assistance
Wireless Display
Wi-Fi Direct
Windows Media Player
AllJoyn
Cast to Device
Connected Devices Platform
mDNS
Hyper-V
Xbox
Microsoft Teams

などです。

一般ユーザー向けPCでは便利でも、専用Edge PCでは使用しない機能があります。

そこで、

「このEdge PCで本当に使う機能か？」

を基準に一つずつ確認しました。

InboundとOutboundで設定方法を変えた

今回の構成では、InboundとOutboundで処理方法を分けました。

Inbound

不要な受信Ruleは、

Enabled
↓
Disabled

としました。

つまり、

使用しないInbound Ruleを無効化する

という方針です。

Firewall管理画面で対象Ruleを右クリックし、

Disable Rule

を選択します。

Outbound

Outbound側は、

RuleをEnabled
↓
Block the connection

としました。

つまり、

対象Ruleを有効にしたうえで、その通信を明示的にBlockする

という方法です。

整理すると、

Direction	今回の設定
Inbound	不要なRuleをDisabled
Outbound	RuleをEnabledにしてBlock

という違いがあります。

Inboundで無効化した主なWindows機能

すべてのRule名を列挙すると非常に長くなるため、機能単位で整理します。

1. Network Discovery

例えば、

Network Discovery (LLMNR-UDP-In)
Network Discovery (NB-Datagram-In)
Network Discovery (NB-Name-In)
Network Discovery (SSDP-In)
Network Discovery (UPnP-In)
Network Discovery (WSD-In)
Network Discovery (WSD Events-In)

などです。

これらは主に、

PCやDeviceの探索
ネットワーク上のDevice発見
UPnP
SSDP
WSD
名前解決

などに関係します。

今回のEdge PCではLAN上の一般的なDevice Discoveryを必要としていないため、使用しないRuleを無効化しました。

2. Wi-Fi Direct / Wireless Display

例えば、

Wi-Fi Direct Network Discovery
Wi-Fi Direct Scan Service Use
Wi-Fi Direct Spooler Use
Wireless Display
Wireless Display Infrastructure Back Channel
WFD ASP Coordination Protocol
WFD Driver-only

などです。

今回のEdge PCでは、

無線ディスプレイ
Wi-Fi Direct
無線でのDevice探索

を使用しないため対象としました。

3. Cast to Device

WindowsにはCast to Device関連のRuleもあります。

例えば、

Cast to Device functionality (qWave-TCP-In)
Cast to Device functionality (qWave-UDP-In)
Cast to Device SSDP Discovery
Cast to Device streaming server
Cast to Device UPnP Events

などです。

これらは、

Media Device探索
Streaming
UPnP

などに関連します。

専用Edge PCでは使用しないため無効化しました。

4. Remote Assistance

例えば、

Remote Assistance (DCOM-In)
Remote Assistance (PNRP-In)
Remote Assistance (RA Server TCP-In)
Remote Assistance (SSDP TCP-In)
Remote Assistance (SSDP UDP-In)
Remote Assistance (TCP-In)

などがあります。

さらに、

Remote Desktop - Shadow (TCP-In)

なども確認しました。

Remote Assistanceを利用しない端末であれば、不要なRemote接続経路を残しておく必要はありません。

ただし、実際にRemote Desktopなどを運用している場合は止めてはいけません。

5. Hyper-V

Hyper-Vを使用しない端末では、

Hyper-V - WMI
Hyper-V MIG
Hyper-V REMOTE_DESKTOP
Hyper-V RPC
Hyper-V RPC-EPMAP
Hyper-V Management Clients

なども確認対象になります。

今回の端末ではHyper-Vを使用していなかったため整理しました。

6. mDNS / Connected Devices

例えば、

mDNS
Connected Devices Platform
Connected Devices Platform - Wi-Fi Direct Transport
Microsoft Edge mDNS

などです。

一般ユーザー向けPCでは便利ですが、

通信先が決まっている
用途が固定されている
Device Discoveryを使用しない

という端末では、必須とは限りません。

Application向けFirewall Ruleも確認する

Windows標準ApplicationにもInbound Ruleがあります。

例えば、

Microsoft Teams
App Installer
Desktop App Web Viewer
Feedback Hub
Game Bar
Microsoft Store
Microsoft To Do
Windows Camera
Windows Media Player

などです。

Edge PCが、

業務Applicationを起動する
↓
接続機器からDataを受信する
↓
Cloudへ送信する

ことだけを目的としているのであれば、Consumer向けApplicationを使用しない場合があります。

そのため、

Applicationを使っていないから終わり

ではなく、

そのApplication用のFirewall Ruleが残っていないか

も確認しました。

Outboundでは不要な通信をBlockする

Outbound側でも、同じように機能ごとに確認しました。

例えば、

LLMNR
NetBIOS
SSDP
UPnP
WSD
Wi-Fi Direct
Wireless Display
Remote Assistance
Windows Media Player
Media Streaming

などです。

さらにConsumer Applicationでは、

Teams
Microsoft Store
Microsoft To Do
Microsoft Photos
Microsoft Clipchamp
Feedback Hub
Game Bar
Get Help
Windows Camera
Widgets Platform Runtime
Windows Web Experience Pack

なども確認対象にしました。

使用しないと判断したOutbound Ruleについては、

Properties
↓
Enabled
↓
Block the connection

としています。

IPv6関連Ruleは特に注意する

今回の設定では、

DHCPv6
IPv6
ICMPv6
Neighbor Discovery
Router Advertisement
Router Solicitation
Multicast Listener
Teredo
IPHTTPS

などのIPv6関連Ruleも確認しました。

ただし、ここは特に注意が必要です。

IPv6関連Ruleは無効化した方がよい、という意味ではありません。

IPv6を利用している環境で安易に変更すると、

通信できない
名前解決に影響する
Network機能に影響する

といった問題が発生する可能性があります。

今回の環境では、

自分のシステムで使用しているか
↓
確認
↓
不要なものだけ変更

という判断をしています。

設定一覧だけをコピーして適用するのは避けた方がよいです。

Device Management関連をBlockするときも注意

Outboundには、

Windows Device Management Certificate Installer
Windows Device Management Device Enroller
Windows Device Management Enrollment Service
Windows Device Management Sync Client

などのRuleもあります。

これらは、

Intune
MDM
組織のDevice Management

を利用している場合に必要になる可能性があります。

したがって、

Rule名だけを見て不要と判断しない

ことが重要です。

Firewall Ruleを大量に変更するなら一覧管理する

Firewall Ruleを数個変更する程度ならGUIだけでも管理できます。

しかし数十個以上変更すると、

何を変更したのか
なぜ変更したのか
元の設定は何だったのか

が分からなくなります。

そのため今回は、

Rule Name
Direction
Current Status
変更後Status
Network Profile
用途

を一覧で管理しました。

例えば、

Rule	Direction	設定
Network Discovery	Inbound	Disabled
Wireless Display	Inbound	Disabled
Remote Assistance	Inbound	Disabled
Network Discovery	Outbound	Block
Wireless Display	Outbound	Block
Media Streaming	Outbound	Block

という形です。

特に量産・展開するEdge PCでは、

変更履歴と元に戻す方法を残しておく

ことが重要です。

Firewall変更後に確認すること

Firewall Ruleを変更できたからといって、作業完了ではありません。

最低限、

接続機器
↓
Edge PC

の通信を確認します。

今回であれば、

TCP 57545

です。

さらに、

Edge PC
↓
Cloud

側の、

TCP 443

も確認します。

ただしPortが開いていることだけでは不十分です。

最終的には、

接続機器
↓
Data送信
↓
Edge Application
↓
Data処理
↓
Cloud送信
↓
Cloud側でData到達を確認

まで実施します。

つまりFirewall変更後の判定基準は、

Ruleを変更できたかではなく、不要な通信を減らしても本来のシステム機能が維持されているか

です。

「全部止める」のではなく「端末の役割」を決める

今回一番重要だったのは、Firewall Ruleの名前を覚えることではありません。

最初に、

このEdge PCは何をするPCなのか？

を定義することでした。

今回必要なのは、

接続機器
↓
Edge PC
↓
Cloud

という通信です。

一方で、

Network Discovery
Media Streaming
Remote Assistance
Wi-Fi Direct
Wireless Display
Game関連
Consumer Application

などは、今回の端末の役割には含まれていません。

そのため、

Edge PCとして必要
↓
維持

Edge PCとして使用しない
↓
通信Ruleを整理

という方針にしました。

専用端末のFirewall設計では、

「何を止めるか」より先に「何を動かすPCなのか」を決める

のがポイントだと思います。

注意：この記事のRule一覧をそのまま適用しない

この記事で紹介した設定は、

Windows 11で一律に無効化・Blockすることを推奨するものではありません。

特に、

IPv6
Network Discovery
Remote Assistance
Device Management
Hyper-V
Wi-Fi Direct
mDNS

などは、環境によって必要になります。

実際に変更する場合は、

PCの用途
必要なApplication
必要なNetwork通信
IPv4 / IPv6構成
Remote管理方法
MDM / Device Managementの有無
元に戻す方法

を確認したうえで実施します。

また、変更後は検証環境で動作確認し、

本来必要な通信が維持されていること

を確認してから展開するのが安全です。

まとめ

今回のWindows 11 Edge PCでは、

接続機器 → Edge PC
TCP 57545

と、

Edge PC → Cloud
TCP 443

という必要通信を維持しながら、使用しないWindows標準機能のFirewall Ruleを整理しました。

考え方はシンプルです。

PCの役割を決める
↓
必要通信を洗い出す
↓
Windows標準Ruleを棚卸しする
↓
不要なInbound Ruleを無効化
↓
不要なOutbound通信をBlock
↓
実際の業務通信をEnd-to-Endで確認

Firewallを強くすること自体が目的ではなく、

必要な機能を維持したまま、不要な通信範囲を減らす

ことが目的です。

特に24時間365日動作するような専用Edge PCでは、一般ユーザー向けWindows PCとは違う視点でFirewall Ruleを確認する価値があります。

次回：病院ネットワークでAMQPが通らなかったので、AMQP over WebSocketへ変更した

Edge PC側のFirewallで必要な通信を許可していても、

Edge PC
↓
施設Network
↓
Cloud

という経路では、施設側のFirewallやNetwork Policyによって通信できない場合があります。

実際の運用では、Cloudへの通信に通常のAMQPを使用した際、

AMQP
↓
施設NetworkでBlock

となる環境がありました。

そこで、

AMQP
↓
AMQP over WebSocket
↓
TCP 443

へ通信方式を変更しました。

次回は、

「病院ネットワークでAMQPが通らない場合に、Azure IoT EdgeをAMQP over WebSocketへ変更した理由」

についてまとめます。

本記事は、実際のEdge PC運用・障害対応経験をもとに、機密情報に配慮して一部を一般化・匿名化しています。特定の組織・施設・製品・システムについて説明するものではありません。