Microsoft Intune の「Manage firewall settings with endpoint security policies in Microsoft Intune」は、Intune で Windows と macOS の組み込みファイアウォールを管理するための公式ドキュメントです。今回まず押さえるべき結論は、ファイアウォール設定を従来のデバイス構成プロファイルだけで管理するのではなく、Endpoint security > Firewall の専用ポリシーとして整理し、競合・対象OS・レポート確認まで含めて見直すべきという点です。
特に、Windows Firewall、Windows Firewall rules、macOS firewall を Intune で管理している組織は、既存ポリシーの重複、Windows 10 のサポート終了後の扱い、Windows Firewall CSP の適用動作、ルール数の上限、レポートでの検出方法を確認しておく必要があります。GitHub の MicrosoftDocs 履歴では対象ファイルに 2026年7月1日の「Metadata updates」が確認できますが、Microsoft Learn 上の対象ページ自体には「Last updated on 2026-04-15」と表示されています。そのため、本記事では「7月1日に新機能が追加された」と断定せず、現行の公式情報をもとに管理者が実務で確認すべきポイントを整理します。(GitHub)
Microsoft Intune の Firewall policy とは
Microsoft Intune の Firewall policy は、Endpoint security ノードから利用できるファイアウォール専用のセキュリティポリシーです。対象は Windows と macOS で、デバイスに組み込まれているファイアウォール機能を Intune から構成・展開します。Microsoft Learn では、同じファイアウォール設定を Endpoint Protection のデバイス構成プロファイルでも構成できる一方、デバイス構成プロファイルにはファイアウォール以外の設定も含まれるため、ファイアウォールだけを管理したい場合は Endpoint security の Firewall policy のほうが分かりやすいと説明されています。(Microsoft Learn)
実務上の意味は明確です。ファイアウォール設定を「デバイス構成」「セキュリティベースライン」「Endpoint security」「GPO」「Configuration Manager」などに分散させると、どのポリシーが最終的に有効なのか追いにくくなります。特にグローバル企業では、国・拠点・部門ごとに例外ルールが増えやすいため、まずは「ファイアウォールの基準設定はどのポリシーで管理するか」を決めることが重要です。
今回確認すべき主な更新ポイント
| 確認項目 | 管理者が見るべきポイント | 実務上の影響 |
|---|---|---|
| 対象プラットフォーム | Windows、macOS、Defender for Endpoint 経由の Windows Server | 管理対象OSごとにポリシー設計を分ける必要がある |
| Windows プラットフォーム | 旧「Windows 10 and later」ではなく「Windows」プラットフォームが中心 | 古いテンプレートの新規作成はできず、既存プロファイルの扱いに注意 |
| Windows Firewall rules | 1つのプロファイルで最大150個のカスタムルール | 大規模環境では複数プロファイルへの分割設計が必要 |
| Reusable settings groups | Windows Firewall rules で Remote IP ranges や FQDN 定義を再利用可能 | 拠点IP、SaaS宛先、管理ネットワークを共通部品化できる |
| 競合管理 | Windows Firewall profile は同じ設定を別ポリシーで管理すると競合し得る | 設定がデバイスに送信されない、または意図しない状態になる可能性 |
| レポート | Firewall off、MDM Firewall status for Windows で状態確認 | 適用確認だけでなく、ファイアウォール無効端末の検出に使える |
| Windows 10 | 2025年10月14日にサポート終了 | Intune 登録は可能でも、機能保証や運用リスクを別途評価する必要がある |
影響範囲：Windows、macOS、Windows Server を分けて考える
Microsoft Learn の対象ページでは、Firewall profile の前提条件として Windows、Microsoft Defender for Endpoint の Security settings management シナリオを通じた Windows Server 2012 R2 以降、サポート対象の macOS が挙げられています。(Microsoft Learn)
ここで注意したいのは、「Intune で管理できる」と「同じ方式で管理できる」は同じではないという点です。Windows クライアント、macOS、Windows Server では、使えるプロファイル、レポート、適用経路、前提ライセンスや連携機能が異なります。
Windows クライアント
Windows では、主に次のプロファイルを使います。
| プロファイル | 用途 | 使いどころ |
|---|---|---|
| Windows Firewall | Windows Defender Firewall の基本設定を管理 | ドメイン、プライベート、パブリックネットワークごとの基本制御 |
| Windows Firewall rules | ポート、プロトコル、アプリ、ネットワーク単位でルールを定義 | Teams、業務アプリ、管理ツール、拠点IPの許可・ブロック |
| Windows Hyper-V Firewall Rules | Hyper-V コンテナー向けのルール制御 | WSL や仮想化関連ワークロードを含む端末管理 |
Windows Firewall rules は、ポート、プロトコル、アプリケーション、ネットワークなどを指定して通信の許可・ブロックを定義できます。ただし、1つのプロファイルでサポートされるカスタムルールは最大150個です。大規模環境では「全社共通ルール」「部門別ルール」「開発者向けルール」「拠点別ルール」のように分割し、命名規則を統一しておくと運用しやすくなります。(Microsoft Learn)
macOS
macOS では、macOS firewall プロファイルを使って組み込みファイアウォールを有効化し、着信接続の制御、ステルスモード、アプリごとの着信許可・ブロックなどを管理できます。Microsoft Learn の設定リファレンスでは、Enable Firewall を有効にしたうえで、Block all incoming connections、Enable stealth mode、Firewall apps などを構成できると説明されています。(Microsoft Learn)
macOS 管理でよくある失敗は、Windows と同じ感覚でポート単位の細かい制御を前提にしてしまうことです。macOS では、まず「ファイアウォールを有効化するか」「共有サービスをどこまで許すか」「業務アプリの着信をどう扱うか」を整理し、必要以上に厳しい設定でリモートサポートや業務アプリを止めないように検証しましょう。
Windows Server
Windows Server は、Intune にネイティブ登録して管理するというより、Microsoft Defender for Endpoint の Security settings management シナリオを通じて扱うケースがあります。対象ページでは Windows Server 2012 R2 以降が前提条件として示されています。(Microsoft Learn)
サーバーにファイアウォールポリシーを適用する場合は、クライアント端末以上に慎重な検証が必要です。管理ポート、監視エージェント、バックアップ、RDP、WinRM、業務アプリの待ち受けポートを洗い出さずにブロック設定を入れると、リモート管理不能やサービス停止につながります。
Windows 10 サポート終了後の扱いに注意
Microsoft は、Windows 10 version 22H2 などが 2025年10月14日にサポート終了となり、その後はセキュリティ更新プログラムを受け取れないと案内しています。Intune の Firewall policy ドキュメントでも、Windows 10 は Intune で許可されるバージョンではあるものの、機能は保証されず変動する可能性があると注意されています。(Microsoft Learn)
つまり、2026年時点で Windows 10 端末が残っている組織では、「Intune でポリシーが配布できるから問題ない」と判断するのは危険です。管理者は次のように分けて考えるべきです。
| 状況 | 推奨アクション |
|---|---|
| Windows 11 へ移行済み | Firewall policy の標準化と競合整理を優先 |
| Windows 10 が一部残存 | 対象台数、用途、ネットワーク接続範囲を棚卸し |
| Windows 10 が基幹業務で残存 | Extended Security Updates や代替端末計画を含めてリスク評価 |
| Windows 10 と Windows 11 が混在 | 同じルールが同じように適用されるか検証グループで確認 |
特にファイアウォールは「適用できたか」だけでなく、「意図した通信だけが許可されているか」まで確認する必要があります。OS のサポート状態が異なる端末を同じセキュリティグループに入れて一括適用する場合は、レポートと実機確認を組み合わせてください。
旧 Windows 10 and later プラットフォームからの移行観点
Microsoft Learn では、2022年4月5日以降、「Windows 10 and later」プラットフォームは「Windows」プラットフォームに置き換えられたと説明されています。新しい Windows プラットフォームは、Intune または Microsoft Defender for Endpoint と通信するデバイスをサポートし、Windows Server プラットフォームも追加でサポートします。また、古いプロファイルの新規作成はできませんが、既存インスタンスは引き続き利用・編集できます。(Microsoft Learn)
管理者が取るべき対応は、単純な「作り直し」ではありません。まず既存プロファイルを棚卸しし、どのプロファイルが古いテンプレートで作られているか、どのグループに割り当てられているか、同じ設定を新しい Windows プラットフォームのポリシーでも管理していないかを確認します。
移行前に確認するチェックリスト
| チェック項目 | 確認方法 | 判断基準 |
|---|---|---|
| 古いプロファイルの有無 | Endpoint security > Firewall と Devices > Configuration を確認 | 新規作成できない旧形式が残っていないか |
| 重複設定 | Firewall、Endpoint Protection、Security baseline を比較 | 同じ設定を複数ポリシーで構成していないか |
| 割り当て対象 | Microsoft Entra ID グループ、フィルター、除外設定を確認 | 本番端末に意図せず二重適用されていないか |
| 例外ルール | 業務アプリ、管理ツール、VPN、監視製品の通信を確認 | 例外が文書化されているか |
| ロールバック手順 | テストグループでポリシー削除・除外を検証 | 通信障害時に戻せるか |
Windows Firewall CSP の Atomic block 動作を理解する
重要な技術的ポイントが、Windows Firewall CSP の Atomic block に関する動作です。Microsoft Learn では、Windows 11 21H2、Windows 11 22H2、Windows 10 21H2 以降で、Atomic block 内のファイアウォールルールが「all-or-nothing」として適用されると説明されています。これより前の Windows では、ブロック内のルールを1つずつ処理し、途中で問題が起きても既に成功したルールをロールバックしないため、部分適用が発生する可能性があります。(Microsoft Learn)
これは運用上かなり重要です。たとえば、10個のルールをまとめて配布したときに、古いOSでは先頭の数個だけが適用され、後続ルールが失敗する可能性があります。その場合、管理者は「ポリシー全体が失敗した」と認識できず、端末ごとに中途半端な通信制御が残るリスクがあります。
対策として、次の運用を推奨します。
| リスク | 対策 |
|---|---|
| ルールの部分適用 | OS バージョンごとにテストグループを分ける |
| どのルールが失敗したか分かりにくい | ルール名に用途、方向、対象アプリ、変更日を含める |
| 1プロファイルにルールを詰め込みすぎる | 役割別にプロファイルを分割する |
| 失敗時の影響が大きい | 最初は監視対象・IT部門端末へ段階展開する |
ポリシー競合は「設定」と「ルール」で見方が違う
Firewall policy の運用で最も失敗しやすいのが競合です。Microsoft Learn では、Windows Firewall profile は他の Windows Firewall profile やデバイス構成など、同じ設定を異なる値で管理するポリシーと競合する可能性があり、競合した設定はデバイスに送信されないと説明されています。一方、Windows Firewall rules profile は複数適用でき、競合しないルールはマージされます。(Microsoft Learn)
この違いを理解していないと、「複数ポリシーを当てれば足し算される」と誤解しがちです。
競合しやすい例
| 例 | 起きること | 対策 |
|---|---|---|
| ポリシーAで Windows Firewall を有効、ポリシーBで無効 | 同じ設定に異なる値が入り競合 | 基本設定は1つの標準ポリシーに集約 |
| ルールAで Teams.exe を許可、ルールBで Teams.exe をブロック | 両方がクライアントに送信され端末側で競合 | アプリ単位で所有ポリシーを決める |
| Security baseline と Firewall policy の両方で同じ設定を構成 | 設定が意図通り適用されない可能性 | ベースラインは基準、Firewall policy は例外・詳細に分ける |
| GPO と Intune でローカルルールの扱いが違う | ハイブリッド環境で結果が読みにくい | 移行期間を決め、管理元を段階的に一本化 |
実務では、まず「基本設定」と「個別ルール」を分けると整理しやすくなります。基本設定は Windows Firewall profile で一元管理し、アプリ・ポート・拠点IPなどの例外は Windows Firewall rules profile で管理する形です。
Reusable settings groups は大規模環境ほど効果が大きい
Windows Firewall rules profile では、Reusable settings groups を使って Remote IP address ranges や FQDN definitions and auto-resolution を再利用できます。Microsoft Learn では、この機能は public preview として説明されており、Windows Firewall Rules などで利用できるとされています。Reusable settings group を編集すると、そのグループを含む各プロファイルにも変更が反映されます。(Microsoft Learn)
活用例としては、次のようなものがあります。
| 再利用グループ例 | 内容 | メリット |
|---|---|---|
| HQ-Networks | 本社・データセンターのIP範囲 | 拠点追加時の修正箇所を減らせる |
| SOC-Tools | 監視・EDR・ログ収集基盤の宛先 | セキュリティ運用で必要な通信を標準化できる |
| Dev-Allowed-FQDN | 開発部門で使う外部サービス | 開発者端末だけに展開しやすい |
| Blocked-High-Risk-Ranges | 明示的に遮断したい宛先範囲 | 複数ポリシーで同じブロック条件を使える |
ただし、Reusable settings groups は便利な反面、変更の影響範囲が広がります。1つのグループを編集すると、それを参照している複数のポリシーに影響するため、グループ名、説明、所有部門、変更履歴を明確にしておきましょう。
FQDN と受信ルールの制限に注意
対象ドキュメントでは、Inbound FQDN rules はネイティブにはサポートされないと説明されています。ただし、pre-hydration scripts を使って受信用IPエントリを生成する方法には触れられています。(Microsoft Learn)
これは「FQDN で柔軟に受信許可したい」と考えている管理者にとって重要です。クラウドサービスはIPレンジが変わることがあるため、送信方向では FQDN ベースの管理が便利ですが、受信方向まで同じ発想で設計できるとは限りません。業務アプリの受信許可を設計する場合は、次の順で検討すると安全です。
- そもそも端末側で受信を許可する必要があるか確認する
- 必要な場合は、対象アプリ、ポート、プロトコル、ネットワークプロファイルを限定する
- FQDN 前提ではなく、可能な範囲でIP範囲や管理ネットワークに絞る
- 変更頻度が高い宛先は、更新手順と検証方法を文書化する
レポートで見るべきポイント
Firewall policy は、作成して割り当てて終わりではありません。Microsoft Learn では、Endpoint security > Firewall > Summary でファイアウォールがオフになっているデバイス数や、ポリシー名、種類、割り当て有無、最終更新日を確認できると説明されています。また、Endpoint security ノードの「MDM devices running Windows 10 or later with firewall off」や、Reports > Firewall > MDM Firewall status for Windows から状態確認ができます。(Microsoft Learn)
MDM Firewall status for Windows では、Enabled、Disabled、Limited、Temporarily Disabled、Not applicable などの状態でフィルターできます。(Microsoft Learn)
運用で見るべきレポート項目
| レポート項目 | 見るべき理由 | 対応例 |
|---|---|---|
| Firewall status | ファイアウォールが有効か確認 | Disabled 端末を優先調査 |
| Last check-in time | 情報が古くないか確認 | 長期間未チェックイン端末を別管理 |
| Target | Intune 管理か別経路か確認 | 管理方式の混在を整理 |
| Limited | 一部ネットワークやルールが無効な可能性 | 端末側設定とポリシー競合を確認 |
| Not applicable | 対象外OSやレポート非対応の可能性 | 割り当てグループやOS条件を見直す |
大規模環境では、「ファイアウォールがオフの端末ゼロ」を最初のKPIにするより、「業務影響を出さずに標準ポリシーへ収束させる」ことを優先したほうが現実的です。まずはレポートで現状を見える化し、例外端末を分類してから是正しましょう。
よくある設定ミスとトラブルシューティング
対象ページでは、Firewall rules の一般的な問題として、ポート範囲、プロトコル指定、Edge traversal、Interface types に関する注意点が挙げられています。たとえば、RemotePortRanges や LocalPortRanges の範囲は昇順で、0〜65535 の範囲に収める必要があります。また、ポート範囲を指定する場合は TCP の 6 または UDP の 17 など、プロトコルも指定する必要があります。(Microsoft Learn)
| 失敗例 | 原因 | 対策 |
|---|---|---|
5-1 のようなポート範囲を指定 | 範囲が降順 | 1-5 のように昇順で指定 |
70000 のようなポートを指定 | 有効範囲外 | 0〜65535 の範囲に収める |
| ポート範囲だけ指定し、プロトコル未指定 | TCP/UDP が不明 | TCP は 6、UDP は 17 を指定 |
| Edge traversal を有効にしたが送信ルールにしている | 方向の条件不一致 | 受信トラフィック向けルールにする |
| Interface types で All と他の種類を併用 | 指定の組み合わせ不正 | All を使う場合は他の種類を選ばない |
トラブル対応では、Intune 管理センターのポリシーステータスだけでなく、端末側のイベントビューアー、実際の Windows Defender Firewall ルール、アプリ通信ログを併せて確認することが重要です。特に「ルールは配布済みだがアプリが通信できない」場合、ファイアウォール以外にプロキシ、VPN、DNS、ゼロトラスト製品、EDR のネットワーク保護が影響していることもあります。
管理者が今すぐ確認すべき実務チェックリスト
次の順番で確認すると、設定漏れや影響範囲を整理しやすくなります。
| 優先度 | 確認内容 | 具体的な作業 |
|---|---|---|
| 高 | ファイアウォール管理元の棚卸し | Intune、GPO、Configuration Manager、セキュリティベースラインを確認 |
| 高 | Windows 10 端末の残存確認 | OSバージョン別に台数、用途、接続先を抽出 |
| 高 | ポリシー競合の確認 | 同じ設定を複数ポリシーで構成していないか確認 |
| 高 | Firewall off 端末の抽出 | Endpoint security と Reports の Firewall レポートを確認 |
| 中 | 旧プロファイルの確認 | Windows 10 and later で作成された古いプロファイルを特定 |
| 中 | ルール数と分割設計 | 150ルール上限を意識してプロファイルを分類 |
| 中 | 例外ルールの妥当性 | Teams、VPN、管理ツール、業務アプリの通信を検証 |
| 中 | Reusable settings groups の利用可否 | 拠点IPや共通FQDNを再利用グループ化できるか検討 |
| 低 | 命名規則の整備 | ルール名に用途、方向、対象、変更日を含める |
推奨される移行・見直しの進め方
ファイアウォールポリシーの見直しは、いきなり本番端末へ適用せず、段階的に進めるべきです。
現状把握
最初に、現在どの仕組みでファイアウォールを管理しているかを確認します。Intune の Endpoint security、デバイス構成プロファイル、セキュリティベースライン、GPO、Configuration Manager、ローカル設定が混在している場合は、一覧表にまとめます。
標準ポリシーの設計
次に、全社共通の標準ポリシーを決めます。基本方針としては、Domain、Private、Public の各ネットワークでファイアウォールを有効化し、既定の受信はブロック、必要なアプリやポートだけを許可する形が管理しやすいです。ただし、業務アプリやリモート管理ツールに影響するため、例外ルールを必ず洗い出してください。
テストグループへの展開
IT部門、パイロットユーザー、特定拠点など、影響を確認しやすいグループから展開します。Windows 10、Windows 11、macOS、VPN利用端末、社外利用端末など、利用条件が異なるデバイスを含めると、本番展開前に問題を発見しやすくなります。
レポート確認と例外整理
適用後は、Firewall status、ポリシーステータス、イベントログ、アプリ通信を確認します。例外が必要な場合は、個別端末で手作業変更するのではなく、Windows Firewall rules profile や Reusable settings groups に反映し、管理された例外として残します。
本番展開と継続監視
本番展開後も、定期的に Firewall off 端末、Limited 状態、競合、未チェックイン端末を確認します。ファイアウォールは一度設定して終わるものではなく、アプリ追加、SaaS変更、拠点ネットワーク変更、OS移行に合わせて継続的に見直す必要があります。
まとめ：Intune の Firewall policy は「集約」と「検証」が重要
Microsoft Intune の Firewall policy は、Windows と macOS の組み込みファイアウォールを Endpoint security から管理するための重要な機能です。今回の確認ポイントは、新しいボタンや単独の新機能を探すことではなく、ファイアウォール管理を Endpoint security に集約し、古いプロファイル、競合、Windows 10 残存、ルール上限、レポート確認まで含めて運用を整えることです。
管理者はまず、現在のファイアウォール設定がどこで管理されているかを棚卸ししてください。そのうえで、基本設定は Windows Firewall profile、個別の許可・ブロックは Windows Firewall rules、共通IPやFQDNは Reusable settings groups で整理すると、変更に強い構成になります。
特にグローバル環境では、拠点・部門・OSごとの例外が増えやすいため、「誰が見ても分かるポリシー名」「変更履歴」「テストグループ」「レポート監視」をセットで運用することが重要です。次に取るべき行動は、Endpoint security > Firewall と Reports > Firewall を開き、既存ポリシー、競合、Firewall off 端末、Windows 10 残存端末を確認することです。
コメント