All
SaaS管理
デバイス管理
セキュリティ対策
脅威・インシデント
IT基盤・インフラ
情シス業務・組織形成
AI / テクノロジー
プロダクト
イベントレポート
その他
ガバナンス

新着記事

もっと見る

>

>

パーソナルファイアウォールとは?FWの必要性と設定手順

パーソナルファイアウォールとは?FWの必要性と設定手順

パーソナルファイアウォールとは?FWの必要性と設定手順

パーソナルファイアウォールとは?FWの必要性と設定手順

公開日

最終更新日

テレワークやクラウド利用が定着し、業務端末は社内ネットワークの外から直接通信するようになりました。この環境では、拠点の入口に置くネットワーク用ファイアウォールだけでは、持ち出したPCやBYOD端末を一貫して保護できません。本記事では、IT分野におけるFWやF/Wの意味から、Microsoft Defender Firewallの設定、Intuneによる一括適用、EDR・SASE・ZTNAとの役割分担まで解説します。

パーソナルファイアウォールの基本的な役割や必要性、EPPやEDRなど他のセキュリティ対策との役割分担、全端末での具体的な設定手順を解説するインフォグラフィック。

パーソナルファイアウォール(FW)とは

パーソナルファイアウォールとは、ネットワークの境界ではなくPCやスマートフォンなどの端末内に設置し、個別の通信を制御・監視するセキュリティ機能です。

本記事のポイント

  • ITセキュリティ分野のFWは、Firewallを略したファイアウォールを意味します。

  • パーソナルFWは、端末へ届く受信通信と端末から出る送信通信をルールに基づいて制御します。

  • OS標準FWは受信防御に利用できますが、既定で許可される送信通信の設計と監査が別途必要です。

  • 企業では、パーソナルFW、EPP、EDR、ZTNAを組み合わせて侵入前後の対策を分担します。

IT用語としてのFWとF/Wの意味

FWは「Firewall」の略で、日本語では防火壁を意味します。ITセキュリティでは、通信を検査して許可または遮断する仕組みを指し、F/Wやファイアウォールとも表記されます。「F Wとは何か」「FWは何の略か」という疑問に対する答えは、セキュリティの文脈ではファイアウォールです。

ただし、文脈によって意味は変わります。メール件名の「Fw:」は転送を表すForward、サッカーのFWはForward、システム開発ではFramework、機器仕様ではFirmwareの略として使われる場合があります。本記事が扱うFWは、通信を防御するファイアウォールです。

通信を許可・遮断する基本機能

パーソナルFWは、送信元・送信先のIPアドレス、TCPやUDPなどのプロトコル、ポート番号、実行プログラム、ネットワークの種類を照合します。たとえば、社外のパブリックネットワークではファイル共有用のTCP 445番への受信を拒否し、社内の管理セグメントからだけ保守通信を許可する、といった制御が可能です。

現在のホスト型ファイアウォールは、通信状態を追跡するステートフルインスペクションも利用します。端末が開始した正規の接続に対する応答は通し、外部から突然届いた未要求の接続は遮断するため、単純にポート番号だけを見ていた初期のパケットフィルタリングより精度が上がっています。

受信通信と送信通信の役割

インバウンドは端末へ入る受信通信です。外部からのポートスキャン、共有サービスへの接続、脆弱なリモート管理機能への到達を抑えます。Windowsの一般的な既定構成では、受信は許可規則に一致しない通信を遮断する設計です。

アウトバウンドは端末から外へ出る送信通信です。未知のプログラムによる指令サーバーへの接続、未許可のクラウドストレージ、シャドーITへの通信を制御する際に使います。ただし、すべての送信を一律に拒否すると、OS更新、証明書検証、Web会議、業務SaaSまで停止します。送信制御は、宛先、アプリケーション、利用者、時間帯を段階的に絞る設計が必要です。

パーソナルFWで防げる範囲と限界

パーソナルFWが直接防げるのは、規則に反するネットワーク通信です。不要な待受ポートへの接続、許可していないアプリケーションの外部通信、端末間の横展開に使われる通信を遮断できます。社外へ持ち出したPCにも同じ規則を残せる点が、拠点型FWとの違いです。

一方、正規ブラウザーによるフィッシングサイトへの接続、許可済みHTTPS通信の中身、盗まれた認証情報による正規ログイン、端末内だけで完結するファイルレス攻撃は、FW単体では判別できません。HTTPSの443番ポートを許可していても、その通信が安全とは限らないため、Webフィルタリング、EPP、EDR、認証制御を別の防御層として組み込みます。

テレワークとゼロトラストで高まるFWの必要性

端末が社内外を移動する環境では、接続場所に左右されないホスト単位の通信制御が必要です。

国内市場と不正アクセスの数値

JNSA(特定非営利活動法人日本ネットワークセキュリティ協会)は、正式名称「2024年国内情報セキュリティ市場調査報告書」(2025年公開)で、2025年度の国内情報セキュリティ市場を1兆9,458億円と予測しています。同報告書によると、エンドポイント保護管理製品の2023年度市場規模(推定実績値)は2,698億円(前年度比10.4%増)であり、端末単位の防御と集中管理へ投資が移っていることが読み取れます。調査の対象範囲・集計条件は JNSA「2024年国内情報セキュリティ市場調査」公開ページ(https://www.jnsa.org/result/surv_mrk/2024/)で確認できます。

警察庁は2023年の不正アクセス行為の認知件数を6,312件と集計し、前年から186.9%増加したと公表しました。2023年時点の統計であり、2026年の現在と単純比較はできませんが、認証情報の悪用やインターネット公開機器への攻撃を前提に端末側でも通信を制限する根拠になります。年次資料は警察庁のサイバーセキュリティ関連統計で公開されています。

データ侵害コストの最新状況

IBMは「Cost of a Data Breach Report 2025」で、データ侵害1件当たりの世界平均コストを444万米ドルと報告しています。2024年版の488万米ドルからは低下したものの、端末1台を起点とする認証情報窃取や横展開が、調査、復旧、通知、事業停止を含む経営損失につながる構造は変わりません。調査対象と算定方法はIBMの2025年データ侵害コスト調査で確認できます。

なお、トレンドマイクロは「セキュリティ成熟度と被害の実態調査 2024」で、被害経験組織の過去3年間の累計被害額を平均約1億7,100万円と報告しています。最新予算の算定にはIBMの2025年版などと併用しつつ、調査母集団や集計定義が自社環境と一致するかを確認します。

グローバルIPとポート公開の評価

モバイル回線を使っただけで、PCが必ずインターネットから直接到達可能になるわけではありません。通信事業者のキャリアグレードNAT、家庭用ルーターのNAT、IPv6ファイアウォールによって外部からの新規接続が遮断される構成も一般的です。一方、固定グローバルIP、IPv6の受信許可、UPnP、ルーターのポート転送を使っている場合は、RDPのTCP 3389番やSMBのTCP 445番が外部へ露出する可能性があります。

UPnPやポート転送など業務上不要なルーター設定は、外部から到達不能であるかどうかにかかわらず原則として削除・停止します。外部スキャン結果とルーター設定の両方で到達不能を確認したうえで不要設定も除去できていれば、端末規則の統一を並行して進めます。到達可能な場合は、ルーター側の転送規則を削除し、端末FWで受信元を管理セグメントまたはVPNに限定します。外部公開が業務要件なら、直接ポートを開けず、ZTNAや認証付きゲートウェイを経由させます。

最新の攻撃傾向を補足する資料として、LAC WATCHの脅威分析も参照できます。ただし、個別記事の観測対象と自社環境が一致するとは限らないため、自社のFWログ、EDRアラート、外部公開資産の棚卸し結果を優先します。

セキュア・バイ・デフォルトと端末境界

セキュア・バイ・デフォルトとは、利用者が追加設定をしなくても安全側の初期値で動作する設計です。パーソナルFWでは、全プロファイルでFWを有効にする、未要求の受信を既定で拒否する、一般利用者による無効化を防ぐ、許可規則の適用範囲を限定する構成が該当します。

ゼロトラストでは、社内ネットワークに接続しているという理由だけで端末を信頼しません。利用者ID、端末の準拠状態、アプリケーション、接続先を都度評価します。端末側FWはこのうちネットワーク通信を担い、PC単位の小さな境界、いわゆるマイクロペリメーターを作ります。

2026年のAI活用と運用上の判断

主要なセキュリティベンダーは、機械学習による不審な通信の分類や、EDRが検知した端末の自動隔離をエンドポイント製品へ組み込んでいます。定義ファイルにないプログラムでも、通常と異なるプロセスが外部の指令サーバーへ周期的に接続する挙動を検出し、FWやネットワーク制御へ遮断指示を渡す構成です。製品更新の確認にはMicrosoft Security Blogの製品・脅威情報も利用できます。

ただし、「AI搭載」という表記だけでは遮断範囲を判断できません。検知根拠、誤検知時の解除方法、監査ログ、端末隔離の対象通信を検証できるなら限定部署で試験し、確認できなければ既存FWルールとEDRアラートの連携から始めます。

Precedence Researchの日本エンドポイントセキュリティ市場予測は中長期の参考資料ですが、民間調査会社による予測です。年度予算では、国内の分類と実績値を追跡できるJNSA資料を基準にし、海外予測は成長方向を補う用途に限定します。

OS標準FWと法人向け製品の選び方

端末数が少なく設定監査を手作業で回せる組織はOS標準FWを利用でき、端末数や拠点数が増えた組織は集中管理機能を追加します。

Microsoft Defender Firewallの位置付け

Windows 10とWindows 11にはMicrosoft Defender Firewallが組み込まれています。管理画面や旧来のコントロールパネルでは「Windows Defender ファイアウォール」と表示される場合がありますが、本記事ではMicrosoftの現行文書に合わせてMicrosoft Defender Firewallと表記します。

このファイアウォールは、ドメイン、プライベート、パブリックのネットワークプロファイルごとに規則を設定できます。一般的な初期構成は未許可の受信を遮断し、送信を許可する設計です。受信防御には利用できますが、マルウェア感染後のC2通信や未許可SaaSへの送信を初期状態のまま網羅的に止めるものではありません。Microsoftは、機能と既定動作をWindows Firewallの公式ドキュメントで説明しています。

FW・EDR・統合製品の比較

Microsoft Defender Firewall、Microsoft Defender for Endpoint、サードパーティ製エンドポイント保護は同じ製品分類ではありません。機能を混同しないよう、以下の比較軸で整理します。

比較項目

Microsoft Defender Firewall

Microsoft Defender for Endpoint

サードパーティ製統合エンドポイント保護

主な役割

Windows端末の受信・送信通信制御

端末挙動の検知、調査、隔離、脆弱性管理

製品によりFW、EPP、EDR、Web制御を統合

基本費用

対応するWindowsライセンスに含まれる

対象の法人向けライセンスが必要

有償。料金と最小契約数は要問い合わせの場合が多い

受信制御

プロファイル、ポート、アプリ単位で設定

Firewallの設定・状態を管理基盤と連携可能

製品独自エージェントまたはOS機能を利用

送信制御

規則を作成可能だが、一般的な既定値は許可

EDR検知と端末隔離を連動可能

アプリ、URL、カテゴリ、脅威情報との連携範囲は製品ごとに異なる

一元管理

GPO、PowerShell、MDMなどを利用

クラウド管理画面と監査機能を利用

ベンダーの管理コンソールを利用

適する環境

Windows中心で基本的な通信規則を統一する環境

侵入後の調査や端末隔離まで扱う環境

Windows、macOS、モバイルを横断管理する環境

注意点

送信規則とログ監査を別途設計する

FWそのものの代替ではない

OS標準FWとの共存方式を製品単位で検証する

サードパーティ製品がWindows セキュリティへ登録された場合でも、Microsoft Defender Firewallが必ず自動停止するとは限りません。製品独自のフィルタードライバーを使う方式、OS標準FWを管理する方式、機能を併用する方式があります。検証端末で有効なサービス、適用規則、再起動後の状態を取得できれば本番展開へ進み、取得できなければベンダーの共存手順を確定するまで展開を止めます。

端末規模別の管理方法

50台、300台という区分は公的な規格ではなく、情シスの監査工数を見積もるための実務上の目安です。1台当たり月10分かけて有効状態、例外、ログを点検すると、50台で月約8.3時間、300台で月50時間になります。担当者が月8時間程度を確保できるかどうかで、手作業と集中管理の境目を判断できます。

  • 50名未満:Windows中心で構成がそろっているなら、Microsoft Defender Firewallを有効化し、GPOまたは端末管理ツールで基本規則を配布します。月次監査を8時間以内に完了できる間は専用製品を追加しない判断も成立します。

  • 50〜300名:手作業の例外管理では更新漏れが増えるため、Intune、GPO、統合エンドポイント製品のいずれかで規則と有効状態を収集します。専任担当者がいない場合は、ログ監視をSOCサービスへ切り出します。

  • 300名超:月50時間規模の個別点検は継続しにくいため、MDM、EDR、SIEMを連携させます。例外申請、承認、期限切れ削除までをワークフロー化し、未準拠端末はZTNA側で業務アプリへの接続を制限します。

Windows以外を含む環境の選定基準

macOSにはアプリケーションファイアウォールやパケットフィルタリング機能がありますが、Windowsの受信規則と同じ設定項目ではありません。Linuxもnftablesやiptablesなど構成が異なります。複数OSを含む場合は、画面表示を統一することより、受信拒否、送信制御、設定改変防止、ログ取得という管理要件をそろえます。

監査ログを同じ管理基盤へ送れるならOS標準機能の併用が可能です。OSごとにログ形式や保持期間が分断されるなら、クロスプラットフォーム対応のエンドポイント管理製品を採用します。

組織の規模と要件に応じたファイアウォール運用方式の選定フロー

▲ 組織の規模と要件に応じたファイアウォール運用方式の選定フロー

安全な設定手順とMDMによる一括適用

安全なFW設定は、現状取得、限定テスト、段階配布、ログ監視、例外棚卸しの順で進めます。

変更前の現状取得

最初に、全端末のFW有効状態、適用プロファイル、受信・送信規則、無効化されている規則を収集します。設定変更から始めると、既存の業務通信がどの例外に依存していたか分からず、障害時に戻せません。

Windowsでは、管理画面に加えてPowerShellや管理ツールから構成を出力し、変更前ファイルとして保管します。業務アプリの実行ファイル、接続先FQDN、ポート、利用プロファイル、担当部署も記録します。根拠を特定できない許可規則は即削除せず、利用ログを一定期間取得してから停止します。

Windows端末の安全な規則作成

個別端末で業務通信を許可する場合も、FW全体をオフにせず対象を最小化します。Windowsの画面構成は更新により変わる場合がありますが、設定の判断順序は同じです。

  1. 「Windows セキュリティ」から「ファイアウォールとネットワーク保護」を開き、ドメイン、プライベート、パブリックの有効状態を記録します。

  2. 「詳細設定」で受信規則または送信規則を選び、既存規則で代替できない場合だけ新しい規則を作成します。

  3. ポート全体の許可より、実行ファイルのパスでプログラムを指定した規則を優先します。Microsoft Defender Firewallの標準的な規則では実行ファイルパスを条件とするため、プログラムの署名そのものを直接の許可条件として扱えるわけではありません。ポート指定が必要なら、プロトコルとポート番号を固定します。なお、FQDNベースの宛先制御はWindows Defender Firewallの標準規則では対応していないため、Defender for EndpointのネットワークフィルタリングやSWG側で制御します。

  4. 受信元IP、接続先IP、利用者、インターフェース、ネットワークプロファイルを業務範囲へ限定します。公衆Wi-Fiでも動作させる必要がなければ、パブリックプロファイルを対象外にします。

  5. 規則名にシステム名、申請番号、所有部署、失効日を含めます。例として「会計SaaS更新通信_申請1234_経理_2026-09失効」のように記録します。

  6. 検証端末で接続成功と不要通信の遮断を確認し、問題があれば保存した構成へ戻します。成功した場合だけ対象部署へ段階配布します。

「任意のプログラム」「任意のIPアドレス」「すべてのプロファイル」を同時に許可すると、想定外のプログラムが同じポートを利用できます。接続できないという理由だけで広い規則を作らず、通信ログから実際の実行ファイルと接続先を特定します。

Intuneによるサイレント一括適用

Microsoft Intuneを利用している組織では、エンドポイントセキュリティのファイアウォールポリシーから設定を配布できます。利用できる設定項目や対象OSはテナント、OSバージョン、ライセンスで変わるため、管理画面とMicrosoft Intuneのファイアウォールポリシー公式手順を照合します。

  1. 設計:ドメイン、プライベート、パブリックの全プロファイルでFWを有効にし、一般利用者による変更を制限する基準ポリシーを作ります。

  2. 検証:情シス端末5〜10台のテストグループへ配布し、Web会議、VPN、印刷、ファイル共有、OS更新を確認します。

  3. 限定展開:1部署または全体の5〜10%へ広げ、ヘルプデスクの問い合わせ件数とブロックログを3〜5営業日観測します。

  4. 全社展開:業務影響が許容範囲なら段階的に対象を増やします。重大障害が出た場合はポリシー全体を削除せず、問題の規則だけを停止します。

  5. 監査:適用失敗端末、長期間未接続の端末、利用者が変更した端末を一覧化し、未準拠端末を隔離グループへ移します。

テスト端末でポリシー適用結果とロールバックを取得できれば限定展開へ進みます。結果を取得できない場合は、全社配布ではなくGPOまたは別の端末管理経路との競合調査を先に行います。

オンプレミスADとGPOによる配布

オンプレミスのActive Directoryを中心に運用している企業は、グループポリシーでMicrosoft Defender Firewallの規則を配布できます。コンピューター単位のポリシーとして管理し、利用者によるローカル規則の追加を許可するかどうかも決めます。

GPOとMDMを同じ端末へ適用すると、競合した設定の優先順位を把握しにくくなります。どちらか一方を正本とし、もう一方は移行期間の設定に限定します。適用元を端末台帳へ記録できるなら段階移行を進め、記録できないなら二重管理を解消してから送信規則を厳格化します。

ログ収集とSIEM連携

FWログには、遮断された通信の送信元・送信先、ポート、時刻などが記録されます。単体端末にログを残すだけでは、同じ宛先への接続が複数端末で発生した際に全体像を把握できません。300台の端末が1日100件ずつ遮断を記録すれば、1日3万件になるため、人手での全件確認は成立しません。

SIEMやSOCへログを集約し、同一外部IPへの集中通信、短時間の連続ポートスキャン、通常利用しない国・地域への接続、業務時間外の反復通信を優先して通知します。通知ごとに重大度、担当者、初動時間を定義し、EDRのプロセス情報と突合できる構成にします。

モバイル端末とBYODの通信制御

iOSやAndroidでは、PC向けホストFWと同じ権限で全アプリのパケットを自由に遮断できるとは限りません。OSのサンドボックス、ローカルVPN、ネットワーク拡張、DNSフィルタリング、MDMの管理対象設定を組み合わせます。

会社所有端末は、MDMで業務アプリ、VPN、DNS保護、証明書を配布し、未管理アプリへのデータ受け渡しを制限します。BYODは端末全体を会社管理にせず、業務領域と個人領域を分離します。端末準拠状態を取得できれば業務アプリへの接続を許可し、取得できなければブラウザー経由の限定機能または仮想デスクトップへ切り替えます。

生成AIとシャドーITへの送信制御

パーソナルFWの送信規則だけで、Web版生成AIへの文章貼り付けや正規クラウドストレージへのアップロード内容までは判別できません。多くのサービスがHTTPSの443番ポートを使うため、ポート単位で遮断すると通常のWeb業務にも影響します。

未許可SaaSへの接続を制御する場合は、DNSフィルタリング、セキュアWebゲートウェイ、CASB、ブラウザー制御、DLPを併用します。許可する生成AIサービス、入力できる情報区分、ログ保持期間を定義し、FWでは未知の実行ファイルや直接IP接続など周辺通信を抑えます。

設定・運用チェックリスト

  • ドメイン、プライベート、パブリックの全プロファイルでFWが有効になっている

  • TCP 3389番と445番がインターネットへ直接公開されていない

  • 許可規則に所有部署、申請番号、失効日が記録されている

  • 一般利用者がFWを無効化できない

  • 送信通信の既定値と例外方針を文書化している

  • 変更前構成とロールバック手順を保存している

  • ブロックログを集中管理し、重大度別の通知条件を設定している

  • 退職者端末、休眠端末、長期未接続端末を監査対象に含めている

  • macOS、Linux、iOS、AndroidについてOS別の管理範囲を定義している

  • 例外規則を少なくとも四半期ごとに棚卸ししている

パーソナルファイアウォールを安全に適用・運用する5段階の手順

▲ パーソナルファイアウォールを安全に適用・運用する5段階の手順

ネットワークFW・EDR・SASEとの違い

パーソナルFWは端末の通信制御を担う機能であり、境界防御、侵入後検知、認証制御を担う製品とは役割が異なります。

防御対象と機能の比較

各技術は競合関係ではなく、攻撃経路の異なる段階を担当します。防御対象を次の表で切り分けると、機能の重複購入や対策漏れを防げます。

技術

主な保護対象

主な役割

単体では防ぎにくい攻撃

ネットワークFW

拠点とインターネットの境界

IP、ポート、アプリケーションに基づく通過制御

拠点FWを通らないテレワーク端末の通信

パーソナルFW

個々のPC・サーバー

端末単位の受信・送信制御

端末内で完結する攻撃、許可済みHTTPSの悪用

IDS・IPS

ネットワーク上の通信

攻撃パターンの検知と遮断

暗号化され内容を解析できない通信

WAF

Webアプリケーション

SQLインジェクションやXSSなどの防御

従業員端末へのマルウェア侵入

EPP

端末上のファイルとプロセス

既知・未知マルウェアの実行防止

正規ツールを悪用した侵入後の操作

EDR

端末上の挙動と履歴

検知、調査、封じ込め、端末隔離

認証前のアクセス判断やWebアプリの脆弱性

SASE・ZTNA

利用者から業務アプリまでのアクセス

ID、端末状態、接続先に基づく動的制御

端末内の不正プロセスを詳細に解析する処理

DNS・Web保護

ドメイン名とWebアクセス

不正サイト、フィッシング、カテゴリ別の遮断

IPアドレスへの直接通信や端末内の攻撃

事前防御と侵入後検知の組み合わせ

パーソナルFWは、許可されていない通信を実行前または接続時に止める事前防御です。EDRは、PowerShellの不審な実行、認証情報へのアクセス、プロセス注入など、端末内で起きた挙動を記録して調査する侵入後対策です。

たとえば、マルウェアがHTTPSで外部へ接続した場合、443番を許可するFWだけでは遮断できないことがあります。EDRが不審な親子プロセスを検知して端末隔離を指示し、パーソナルFWまたはネットワーク制御が業務に必要な管理通信以外を止める構成なら、検知から封じ込めまでを短縮できます。

ZTNAによるアクセス判断

ZTNAは「社内からの接続だから許可する」という判断をやめ、利用者、端末、アプリケーションごとに接続を許可します。FWが有効、EDRが稼働、OS更新が一定基準内という端末条件を満たす場合だけ、会計や人事などの業務アプリへ接続させる設計です。

端末が未準拠になった場合は、すべての通信を止めるのではなく、更新サーバー、ヘルプデスク、EDR管理基盤だけへ接続できる修復用ネットワークへ移します。この分離により、利用者は復旧作業を継続でき、未準拠端末から機密システムへの接続は防げます。

多層防御の構成例

  1. 接続前:ZTNAが利用者ID、多要素認証、端末準拠状態を検査します。

  2. 通信時:パーソナルFWとネットワークFWが、端末・拠点ごとの受信と送信を制御します。

  3. コンテンツ利用時:DNS保護、Webゲートウェイ、WAFが不正サイトやWeb攻撃を検査します。

  4. 端末実行時:EPPがマルウェアの実行を防ぎ、EDRがプロセス挙動を記録します。

  5. インシデント時:EDRが端末を隔離し、SIEMとSOCがFWログや認証ログを突合します。

この構成では、どれか1製品がすべての攻撃を防ぐという前提を置きません。FWで遮断できなかった通信をEDRが検知し、盗まれた認証情報による接続をZTNAが制限する形で、制御を重ねます。

攻撃経路における各セキュリティ製品(ネットワークFW・パーソナルFW・EPP/EDR)の役割分担

▲ 攻撃経路における各セキュリティ製品(ネットワークFW・パーソナルFW・EPP/EDR)の役割分担

国内企業のエンドポイント保護事例

国内事例では、パーソナルFWを単独導入するより、ゼロトラストや統合管理の一部として端末ポリシーをそろえる施策が中心です。

JFEグループのゼロトラスト移行

  • 業種・規模:鉄鋼・エンジニアリングなどを展開する企業グループ、約5万人規模の利用を想定した公開事例です。

  • 導入時期:2020年代前半から段階的に移行しており、個別端末への完了年月は公開資料の範囲で異なります。

  • 課題:ハイブリッドワークにより、社内ネットワークの境界だけでは社外端末へ同じセキュリティポリシーを適用できませんでした。

  • 施策:利用者と端末を接続の都度検証するゼロトラストへ移行し、社外へ持ち出す端末にもホスト側の通信制御とアクセス制御を組み込みました。

  • 成果:接続場所に依存せず、端末状態と利用者IDを基準に業務システムへのアクセスを制御できる運用へ移行しました。

JFEホールディングスは、サイバーセキュリティをグループ全体の経営課題として扱い、対策状況を統合報告書で公開しています。組織規模や施策の更新状況は JFEグループ統合報告書(https://www.jfe-holdings.co.jp/investor/library/group-report/) で追跡できます。同報告書で確認できるのはゼロトラスト移行の方針・進捗であり、パーソナルFW単体の遮断件数や効果測定の数値は記載範囲外です。報告書の記載年度と自社の検討時期を照合し、最新年度版を参照します。

三菱UFJ eスマート証券のアクセス制御

  • 業種・規模:金融商品取引業、従業員が複数の業務システムやクラウドサービスを利用する環境です。

  • 導入時期:ベンダーの公開導入事例掲載時点で運用しており、全端末への個別展開日は非開示です。

  • 課題:金融機関としての通信制御を維持しながら、利用者ごとにクラウドサービスへのアクセスを柔軟に変える必要がありました。

  • 施策:端末側の通信状態と認証・アクセス制御を連携し、許可されていないアプリケーションや接続先を制限しました。

  • 成果:利用者、端末、接続先を組み合わせたポリシーへ移行し、社内外で異なっていたアクセス管理を集約しました。

この事例から導ける判断は、金融業だから特定製品を選ぶということではありません。FWログ、利用者ID、端末準拠状態を同じインシデント単位で追跡できるなら統合運用へ進み、追跡できなければ通信規則と認証ポリシーの識別子をそろえる作業を先行します。

SonicWall公開事例の運用コスト削減

  • 業種・規模:国内大手生命保険・損害保険会社、全国17拠点です。企業名はベンダー公開情報で非開示です。

  • 導入時期:公開事例掲載時点で運用済みですが、個別の導入年月は非開示です。

  • 課題:拠点ごとに異なるゲートウェイと端末設定を個別管理しており、監視と変更作業が分散していました。

  • 施策:エンドポイントと拠点側ゲートウェイのポリシー、監視、ログを統合管理しました。

  • 成果:SonicWallの公開事例では、機器の全拠点一括導入による購入コストの削減効果が報告されています。ただし、公開資料の記載範囲は機器・ライセンス調達コストの削減であり、運用工数の削減率については数値の裏付けを確認できていません。

自社での効果測定では、削減対象(機器購入費・運用工数・出張費など)を明確に定義し、導入前後を同じ範囲・定義で測ります。削減対象を混在させると、実際に改善した領域と改善していない領域の判断ができなくなります。

事例から読み取る導入条件

3事例に共通するのは、FW製品の設置だけで完了していない点です。端末台帳、認証、ポリシー配布、ログ、例外申請を一つの運用単位として扱っています。導入前の基準値を記録しなければ、遮断件数が増えても攻撃増加なのか設定改善なのか判断できません。

導入効果を測る指標には、FW有効率、ポリシー適用成功率、期限切れ例外数、重大アラートの初動時間、端末隔離までの時間、月間運用工数を使います。少なくとも導入前1カ月と導入後3カ月を同じ定義で比較します。

導入時の注意点と失敗パターン

パーソナルFWの失敗は、機能不足よりも送信規則の未設計、広すぎる例外、ログ放置、管理経路の競合によって発生します。

代表的な誤解と対策

誤解・失敗

発生する問題

対策と判断基準

OS標準FWを有効にすれば初期設定のままで十分

受信は遮断できても、既定で許可される送信通信を使ったC2接続やデータ送信が残る

重要端末から送信ログを取得し、未許可アプリの通信が見つかればアプリ単位の送信規則を追加する

パーソナルFWがあればEPPやEDRは不要

許可済みHTTPS、ファイルレス攻撃、端末内の不正操作を見逃す

FWを通信制御、EPPを実行防止、EDRを挙動検知として分担する

通信障害の切り分けでFW全体を無効化する

作業後の戻し忘れにより、すべての受信面が開く

検証端末だけで対象規則を一時停止し、終了時刻を決めて自動復元する

ポートを全ネットワークへ許可する

公衆Wi-Fiでも同じ待受サービスへ接続できる

アプリ、受信元、プロファイルを限定し、パブリックでは拒否する

サードパーティ製導入時にOSサービスを手動停止する

製品の共存方式と異なる状態になり、更新や監視に影響する

検証端末でベンダー手順に従い、有効サービスと適用規則を記録してから配布する

ブロックログを保存するだけで分析しない

ポートスキャン、横展開、複数端末の同一宛先通信を見逃す

SIEMへ集約し、重大条件に一致した通信だけを通知する

例外規則に期限を設定しない

廃止済みアプリや退職者向けの許可が残る

失効日と所有部署を必須項目とし、四半期ごとに自動抽出する

アウトバウンドを一括拒否する失敗

送信通信が弱いという理由で、全端末のアウトバウンドを一度に既定拒否へ変えると、OS更新、DNS、時刻同期、証明書失効確認、Web会議、クラウド認証などが停止します。障害の影響範囲が広く、情シスが原因を切り分けられない状態になります。

最初は監視モードまたは重要部署の検証端末で送信先を収集します。業務通信をアプリケーションとFQDNへ整理した後、未知の実行ファイル、直接IP接続、不要な管理プロトコルから段階的に遮断します。業務通信の95%以上を規則へ分類できれば限定部署で既定拒否を試験し、分類できなければ既定許可を維持したまま高リスク通信だけを拒否します。

過剰なホワイトリストによる業務障害

アプリケーションの更新で実行ファイルのパス、署名、CDNの接続先、利用ポートが変わると、厳密なホワイトリストが突然業務を止める場合があります。特にWeb会議やクラウド型業務アプリは接続先が複数あり、単一IPアドレスへの固定が適さない場合があります。

ベンダーが公開する接続要件を規則台帳へ記録し、変更通知を受け取れる担当者を決めます。FQDN規則や署名済みアプリの指定が利用できるなら固定IPより優先し、利用できなければセキュアWebゲートウェイ側で宛先を制御します。

ネットワークプロファイルの誤判定

自宅や公衆Wi-Fiをプライベートネットワークとして登録すると、社内向けに許可していた共有、検出、管理通信が社外でも有効になる場合があります。逆に、社内ネットワークをパブリックと判定すると、プリンターや資産管理ツールが通信できません。

社内ネットワークはドメイン認証や管理済みネットワーク識別子で判定し、利用者が任意に変更できない構成にします。プロファイル誤判定をログで検出できれば自動修復し、検出できなければパブリック側を安全側の既定値として運用します。

例外申請フローの欠如

現場が情シスへ口頭やチャットだけで通信許可を依頼すると、目的、所有者、期限が規則に残りません。障害対応のために作った一時規則が恒久化し、数年後に攻撃経路として残ることがあります。

例外申請には、業務目的、対象端末、実行ファイル、接続先、ポート、プロファイル、利用開始日、失効日、代替手段を記録します。緊急許可は24時間など短い期限で自動失効させ、継続利用する場合だけ通常申請へ切り替えます。

よくある質問

パーソナルファイアウォールに関する検索や導入判断で生じやすい疑問へ簡潔に回答します。

Q:FWとは何の略で、ITではどのような意味ですか?

A:FWはFirewallの略で、ITセキュリティでは通信を規則に基づいて許可・遮断するファイアウォールを意味します。F/Wと表記される場合も同じ意味です。

Q:パーソナルファイアウォールと一般的なFWの違いは何ですか?

A:一般的なネットワークFWは拠点とインターネットの境界を守り、パーソナルファイアウォールは個々のPCやサーバー上で通信を制御します。社外へ持ち出す端末には、拠点FWとは別に端末側の制御が必要です。

Q:Windows標準のファイアウォールだけで十分ですか?

A:少数のWindows端末で基本的な受信防御を行う場合は、Microsoft Defender Firewallを利用できます。送信通信の制御、全社的な状態監視、侵入後の調査が必要なら、GPOやIntuneによる集中管理とEDRを追加します。

Q:ファイアウォールを無効にするとどうなりますか?

A:許可規則に一致しない受信通信も端末へ到達し、共有サービスや待受ポートの攻撃面が広がります。障害の切り分けでも全体を無効化せず、検証端末で対象規則だけを一時停止します。

Q:iPhoneやAndroidにもパーソナルFWは必要ですか?

A:モバイルOSでは、PC向けFWと同じ方式ではなく、ローカルVPN、DNSフィルタリング、MDM、OSのネットワーク機能を使って通信を制御します。会社所有端末はMDMで統一し、BYODは業務領域と個人領域を分離します。

まとめ

パーソナルファイアウォールは、端末ごとに受信・送信通信を制御し、社外へ持ち出したPCにも同じ防御方針を適用する機能です。ただし、許可済みHTTPS、フィッシング、認証情報の悪用、ファイルレス攻撃を単独で防ぐことはできません。EPP、EDR、DNS保護、ZTNAと役割を分ける構成が必要です。

最初の一歩として、明日までに全端末のFW有効率、TCP 3389番・445番の外部公開、期限のない例外規則を一覧化します。50台を超えて月次確認が8時間以上になるならGPOまたはMDMへ移し、300台を超えるならSIEMとEDRを連携させます。設定変更は検証端末から始め、変更前構成とロールバック手順を必ず残します。

本記事の内容に誤り等がございましたら、こちらからご連絡ください。

監修

Admina Team

情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。