本稿では、2026-04-25に更新情報として取り上げられたMicrosoft Learnの「Configure Firewall Rules With Group Policy」を、Windows運用の現場向けに整理します。結論から言うと、今回のポイントは「新しいファイアウォール機能の追加」というより、Group PolicyでWindows Firewall規則を設計・配布する際に、カスタム規則、スコープ、プロファイル、サービスSID、RPC規則を改めて正しく押さえることです。
特にsecurity admins、identity teams、compliance teamsは、単にポートを開けるのではなく、「誰が」「どの端末に」「どの通信を」「どの根拠で」許可またはブロックするのかをGPO単位で説明できる状態にしておく必要があります。なお、Microsoft Learn上の対象ページでは本稿確認時点で「Last updated on 2026-04-23」と表示されているため、ここでは2026年4月下旬更新として扱います。(Microsoft Learn)
Windowsの最新動向: Configure Firewall Rules With Group Policyで何が変わったか
「Configure Firewall Rules With Group Policy」は、Windows Firewall with Advanced Securityコンソールを使い、Group Policy Object（GPO）からWindows Firewall規則を構成する手順を説明する公式ドキュメントです。対象にはWindows 11、Windows 10、Windows Server 2025、Windows Server 2022、Windows Server 2019、Windows Server 2016が含まれます。(Microsoft Learn)
今回の更新で実務上注目すべき点は、次の3つです。
| 観点 | 読み取るべきポイント | 実務での対応 |
|---|---|---|
| GPOによる集中管理 | ADドメイン参加デバイスでは、GPOを作成または編集してWindows Firewall with Advanced Security配下で規則を管理する | ローカル設定ではなく、OU・端末種別・サーバー役割ごとにGPOを分ける |
| カスタム規則の重視 | ProgramやPortだけで規則を作ると設定画面が限定されるため、柔軟性が必要な場合はCustomを選ぶ | ポート、プログラム、サービス、スコープ、プロファイルを1つの設計単位として確認する |
| RPC・サービス規則の注意 | RPCはEndpoint Mapperと動的ポートの2段構成で考える必要がある | AD、WMI、管理系サービスを扱うidentity teamsは特に影響範囲を確認する |
重要なのは、「GPOで配れば安全」ではないことです。GPOは展開力が強い分、誤った規則を配布すると多くの端末に一斉に影響します。今回の公式ドキュメントは、各ルール種別の作成手順を示していますが、現場ではその前に「どの通信を許可するのが最小権限か」を決める必要があります。
GPOでWindows Firewall規則を構成する基本ルート
Active Directoryドメイン参加デバイスを構成する場合、公式手順ではDomain Administratorsグループのメンバー、またはドメイン内のGPOを変更できる委任権限が必要です。GPOを作成または編集し、Computer Configuration > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security を開きます。単一デバイスで確認する場合は、管理者権限で wf.msc を起動します。(Microsoft Learn)
実務では、次の順番で設計すると失敗しにくくなります。
| 手順 | 確認項目 | 判断基準 |
|---|---|---|
| GPOの対象を決める | 端末、サーバー、管理端末、ドメインコントローラーなど | 役割が違う端末を同じGPOに混ぜない |
| 受信・送信を決める | Inbound Rules / Outbound Rules | 外部から待ち受ける通信か、端末から外へ出る通信かを分ける |
| Rule TypeはCustomを基本にする | Program、Port、Custom | セキュリティ要件がある場合はCustomで詳細条件を指定する |
| スコープを絞る | Local IP、Remote IP | 可能なら管理サブネットや特定サーバーだけに限定する |
| プロファイルを選ぶ | Domain、Private、Public | 業務端末・サーバーではDomain中心。Public適用は慎重に扱う |
| 名前と説明を残す | 規則名、説明、変更理由 | 監査で説明できる命名規則にする |
規則名は、あとから検索しやすい形にします。例えば ALLOW-IN-TCP-135-RPC-MGMT-DC-202604 のように、Action、Direction、Protocol、Port、用途、対象、作成年月を入れると、棚卸しや監査で追いやすくなります。
受信ICMP規則: 監視に必要でも「全部許可」は避ける
ICMP規則は、監視ツールの死活監視やネットワーク疎通確認に使われます。公式手順では、ICMPv4またはICMPv6を選び、IPv4とIPv6の両方を使うネットワークではそれぞれ個別のICMP規則を作成する必要があると説明されています。(Microsoft Learn)
実務では、安易に「すべてのICMP種類」を許可しないことが重要です。監視目的なら、監視サーバーのIPアドレスだけをRemote IPに指定し、対象プロファイルもDomainに限定します。
| 利用シーン | 推奨設定 | 避けたい設定 |
|---|---|---|
| 監視サーバーからのping | 監視サーバーのIPだけ許可 | 任意の送信元からICMPを許可 |
| トラブルシュート | 一時的なGPOまたは限定OUで許可 | 全社端末に永続的に許可 |
| IPv6環境 | ICMPv6規則も個別に作成 | IPv4だけ設定して疎通不良を見落とす |
ICMPはポート番号を持たないため、「TCP/UDPのポート管理」と同じ考え方では整理できません。identity teamsがLDAPやDFS関連の疎通を調べる場合も、ICMPの扱いがトラブルシュートに影響することがあります。MicrosoftのActive Directory関連ドキュメントでも、LDAP要求が長時間保留される場合などにICMP pingが使われるケースが説明されています。(Microsoft Learn)
受信ポート規則: 「ポートを開ける」だけでは不十分
受信ポート規則は、指定したTCPまたはUDPポートで待ち受けるプログラムが、そのポート宛ての通信を受け取れるようにする規則です。公式手順では、受信規則の作成時にCustomを選ぶことで、ウィザード上の詳細設定をすべて扱えると説明されています。(Microsoft Learn)
たとえば業務アプリがTCP 8443で待ち受ける場合、単に「TCP 8443を許可」では不十分です。次のように、複数条件を組み合わせて初めて実務で使える規則になります。
| 条件 | 設定例 | 理由 |
|---|---|---|
| Direction | Inbound | 外部からアプリに接続するため |
| Protocol | TCP | アプリ仕様に合わせる |
| Local port | 8443 | 待ち受け側のポートを指定する |
| Program | %ProgramFiles%\Vendor\App\app.exe | 他のプログラムが同じポートを使うリスクを下げる |
| Remote IP | 管理サブネットまたは接続元サーバー | 任意の端末から接続される状態を避ける |
| Profile | Domain | 社内ドメイン接続時だけ有効にする |
公式ドキュメントでも、ポート規則はプログラムまたはサービス規則と組み合わせることが多く、組み合わせることで「指定ポート」かつ「指定プログラムが動作している場合」に通信を限定できると説明されています。(Microsoft Learn)
送信ポート規則: 既定許可を前提に「ブロックの副作用」を確認する
Windows Firewallは、禁止する規則に一致しない限り、既定で送信ネットワークトラフィックを許可します。公式手順の送信ポート規則は、指定したTCPまたはUDPポート番号に一致する送信通信をブロックする例として説明されています。(Microsoft Learn)
送信規則を作るときは、受信規則よりも影響調査が重要です。たとえば「外部へのTCP 443を一部ブロックする」場合、Webアクセスだけでなく、更新、認証、EDR、クラウドサービス、監視連携に影響する可能性があります。
送信ブロックを入れる前に、少なくとも次の確認を行います。
| 確認項目 | 確認内容 |
|---|---|
| 対象プロセス | どの実行ファイルの通信を止めるのか |
| 宛先 | 任意のインターネット宛てか、特定IP・サブネット宛てか |
| 認証への影響 | Entra ID、AD FS、LDAP、Kerberos、プロキシ認証などに影響しないか |
| 更新への影響 | Windows Update、Defender、業務アプリ更新が止まらないか |
| ログ | ブロック時にイベントやファイアウォールログで確認できるか |
セキュリティ強化のために送信制御を導入する場合は、いきなり全社展開せず、監査モードに近い形で対象通信を洗い出し、パイロットOUで検証してから本番GPOに移すのが安全です。
プログラム・サービス規則: サービスSIDを必ず確認する
プログラムまたはサービス規則は、特定の実行ファイルやサービスに対して受信・送信通信を許可またはブロックするための規則です。公式手順では、プログラムパスの指定に環境変数を使うことで、端末ごとのインストール場所の違いに対応できるとされています。(Microsoft Learn)
特に注意すべきなのが、サービスに規則を適用する場合です。公式ドキュメントでは、Apply to this service またはサービス短縮名での指定を使うには、サービスが RESTRICTED または UNRESTRICTED のSIDタイプで構成されている必要があると説明されています。確認コマンドは次の通りです。(Microsoft Learn)
sc qsidtype <ServiceName>結果が NONE の場合、そのサービスにはこの方法でファイアウォール規則を適用できません。SIDタイプを設定する場合は、次の形式を使います。
sc sidtype <ServiceName> UNRESTRICTEDただし、SIDタイプの変更はサービス起動や依存関係に影響する可能性があります。公式ドキュメントでも、SIDタイプを RESTRICTED に変更するとサービスが起動しない可能性があるため、ファイアウォール規則で使う必要があるサービスに限定し、UNRESTRICTED を使うことが推奨されています。(Microsoft Learn)
RPC規則: identity teamsが最も見落としやすいポイント
RPCをサポートする受信規則では、1つのポートを開けるだけでは不十分です。公式手順では、RPC Endpoint Mapper向けのTCP 135を許可する規則と、動的に割り当てられるRPCポート向けの規則の2つを作成する必要があると説明されています。(Microsoft Learn)
設計イメージは次の通りです。
| 規則 | 目的 | 主な設定 |
|---|---|---|
| RPC Endpoint Mapper | クライアントがRPCサービスの動的ポートを問い合わせる | %systemroot%\system32\svchost.exe、RpcSs、TCP、Local port 135 |
| RPC-enabled network services | 実際のRPC対応サービス通信を許可する | 対象サービス、TCP、RPC Dynamic Ports |
Active Directory、WMI、リモート管理、バックアップ、監視などはRPCの影響を受けやすいため、identity teamsは「TCP 135だけ許可しているから大丈夫」と判断しない方が安全です。MicrosoftのActive Directory関連ドキュメントでも、Windows Server 2008以降の動的クライアントポート範囲として49152〜65535が示され、ADや信頼関係でRPC、LDAP、Kerberos、SMBなど複数の通信が関係することが説明されています。(Microsoft Learn)
ADレプリケーションRPCを特定ポートに制限する方法もありますが、レジストリ変更や追加ポート開放が必要になります。Microsoftは、AD RPC通信を特定ポートに固定する場合でも、Kerberosなど追加の通信が必要になることを明記しています。(Microsoft Learn)
Group Policy処理で起きる「効いていない」問題
ファイアウォールGPOの運用でよくある相談が、「GPOを変更したのに効かない」「一部の端末だけ規則が違う」「IPsec接続が不安定になる」というものです。
Microsoft LearnのWindows Firewall toolsでは、Windows Firewallのポリシー設定はレジストリに保存され、既定ではグループポリシーが90分ごとに0〜30分のランダムオフセット付きでバックグラウンド更新されると説明されています。また、GPO設定の保存場所に書き込みや削除があると、Windows Filtering Platform（WFP）がファイアウォール規則と設定を読み直し、新しいフィルターを適用し、古いフィルターを削除します。(Microsoft Learn)
特に注意したいのは、Configure registry policy processing の「Process even if the Group Policy objects haven’t changed」です。この設定を有効にすると、変更がない場合でもバックグラウンド更新ごとにWFPフィルターが再適用され、複数GPOがある環境では再適用が繰り返される可能性があります。Microsoftは、問題を避けるため、この設定を既定のNot ConfiguredまたはDisabledにすることを推奨しています。(Microsoft Learn)
一時的な確認では、次のコマンドが役立ちます。
gpupdate.exe /forcegpresult /h C:\Temp\gpo-result.htmlgpupdate /force はドメインコントローラーに接続できる状態で実行する必要があります。オフライン端末やVPN接続前の端末では、GPOの適用タイミングが遅れることがあります。
GPOとIntuneを併用する場合の注意点
グローバル企業やハイブリッド環境では、GPOとMicrosoft IntuneのFirewall policyが混在することがあります。この場合、「どちらが正」となる管理面を決めておかないと、同じ端末に異なる規則が入り、調査が難しくなります。
Microsoft Intuneの公式ドキュメントでは、Endpoint securityのFirewall policyを使ってWindowsやmacOSの組み込みファイアウォールを構成できると説明されています。また、Windows Firewall rulesプロファイルではポート、プロトコル、アプリケーション、ネットワークを含む細かい規則を定義でき、各プロファイルは最大150個のカスタム規則をサポートします。(Microsoft Learn)
Intune側では、複数のFirewall rulesプロファイルを同じデバイスに適用できますが、同じ対象に対して異なる設定の規則が存在するとデバイス上で競合します。たとえば、ある規則がTeams.exeをブロックし、別の規則がTeams.exeを許可する場合、両方がクライアントへ送られて競合する可能性があります。(Microsoft Learn)
| 環境 | 推奨する管理方針 |
|---|---|
| オンプレAD中心のサーバー | GPOを主軸にし、OU単位で規則を管理する |
| Intune管理のクライアント | Intune Endpoint security Firewall policyを主軸にする |
| ハイブリッド参加端末 | GPOとIntuneの適用範囲を分離し、同じ設定を二重管理しない |
| 監査対象システム | 変更承認、GPOバックアップ、適用結果、例外期限をセットで残す |
「GPOにもIntuneにも同じ規則を入れておけば安心」という考え方は避けるべきです。管理経路が増えるほど、トラブル時に原因を切り分けにくくなります。
security admins向けチェックリスト
Windows Firewall規則をGPOで配布する前に、security adminsは次の観点でレビューします。
| チェック項目 | 確認すること |
|---|---|
| 最小権限 | Any IP、Any Program、Any Profileになっていないか |
| 方向 | InboundとOutboundを取り違えていないか |
| プロファイル | Domainだけでよい規則がPublicにも適用されていないか |
| スコープ | 管理サブネットや接続元サーバーに限定できないか |
| 期間 | 一時的な例外に終了日があるか |
| 所有者 | 業務部門、システムオーナー、承認者が記録されているか |
| ログ | ブロックや許可の確認方法が決まっているか |
| ロールバック | GPOリンク解除、規則無効化、旧GPO復元の手順があるか |
特に危険なのは、トラブル対応中に作った「一時許可」が恒久化することです。例外規則には、規則名や説明に期限・申請番号・担当者を入れておくと、後日の棚卸しで判断しやすくなります。
identity teams向けチェックリスト
identity teamsは、認証・ディレクトリ・レプリケーション・管理通信への影響を重点的に確認します。
| 対象 | 注意点 |
|---|---|
| Domain Controller | LDAP、Kerberos、DNS、SMB、RPC、ADWSなど複数通信が関係する |
| Trust | ドメイン間・フォレスト間の通信要件を個別に確認する |
| RPC | TCP 135だけでなく、動的RPCポートまたは固定化したポートの扱いを確認する |
| ICMP | LDAPやDFS関連の疎通確認に影響するケースがある |
| 管理ツール | WMI、イベントログ取得、監視、バックアップの通信を検証する |
AD関連通信は「ひとつのアプリのポートを開ける」より複雑です。ファイアウォール変更を行う際は、ドメインコントローラー間、メンバーサーバー、管理端末、監視サーバーの通信経路を分けて確認します。
compliance teams向けチェックリスト
compliance teamsにとって重要なのは、技術的に正しいことだけではありません。監査時に説明できることが必要です。
| 証跡 | 残す内容 |
|---|---|
| 変更申請 | 目的、対象、通信要件、承認者 |
| GPO情報 | GPO名、リンク先OU、セキュリティフィルター、WMIフィルター |
| 規則一覧 | 方向、プロトコル、ポート、プログラム、サービス、スコープ、プロファイル |
| 検証結果 | 適用前後の疎通確認、ログ、影響確認 |
| 例外管理 | 有効期限、更新判断、削除予定 |
| ロールバック | 復旧手順、担当者、想定所要手順 |
おすすめは、GPO名と変更申請番号をそろえることです。たとえば GPO-FW-SRV-RPC-MGMT-CRQ12345 のようにすると、監査ログ、変更管理システム、GPOバックアップをひも付けやすくなります。
よくある失敗と回避策
| 失敗例 | 起きる問題 | 回避策 |
|---|---|---|
| Portだけで許可する | どのプログラムでもそのポートを使える | ProgramまたはService条件を組み合わせる |
| ICMPを全許可する | 不要な疎通確認を広く許す | 監視サーバーや管理サブネットに限定する |
| Publicプロファイルにも適用する | ノートPCや一時ネットワークで想定外に開く | 原則Domainに限定し、必要時だけ追加する |
| RPCをTCP 135だけで判断する | 実通信が動的ポートで失敗する | Endpoint MapperとRPC Dynamic Portsをセットで設計する |
| サービスSIDを確認しない | サービス規則が期待通り適用できない | sc qsidtype で事前確認する |
| GPOとIntuneで同じ規則を管理する | 許可とブロックが競合する | 管理ソースを分け、重複を避ける |
| 変更理由を残さない | 監査や棚卸しで削除判断ができない | 規則名・説明・申請番号・期限を記録する |
まず取るべきアクション
2026年4月更新の「Configure Firewall Rules With Group Policy」を読む際は、手順をそのままなぞるだけでなく、自社のWindows Firewall運用を見直す材料として使うのが効果的です。
最初に行うべきことは、既存GPOの棚卸しです。受信規則、送信規則、ICMP、RPC、サービス規則を分類し、Any IP、Any Program、Public適用、期限切れ例外を洗い出します。次に、GPOとIntuneのどちらで管理するかを端末種別ごとに決めます。最後に、パイロットOUで検証し、gpresult や通信ログで適用結果を確認してから本番OUへ展開します。
Windows FirewallのGPO管理は、単なるネットワーク設定ではなく、エンドポイント防御、ID基盤、監査対応をつなぐ運用設計です。今回の更新をきっかけに、ポート単位の場当たり的な許可から、根拠・範囲・証跡を持ったファイアウォール規則管理へ移行しましょう。
コメント