ファイアウォールポリシー設計とは何か

たとえば、顧客から次の要望を受けたとします。

この要望だけでは、まだファイアウォールの設定を作ることはできません。

少なくとも次の情報を確認する必要があります。

• どの利用者・端末から通信するのか
• 送信元ネットワークはどこか
• 宛先サーバーはどれか
• HTTPなのかHTTPSなのか
• TCP/443だけでよいのか
• DNSなど関連する別通信が必要か
• どちら側から通信を開始するのか
• ログを記録する必要があるか
• 恒久的な通信か、一時的な通信か

通信要件からファイアウォールポリシーへ変換する

ネットワーク要件定義では、顧客の要望をそのまま設計にするのではなく、 具体的な条件へ変換してから設計しました。

ファイアウォールでも同じ考え方を使います。

例：運用担当者が管理サーバーへSSH接続する

ファイアウォールポリシーを構成する基本5要素

1．Source：送信元

誰から通信を許可するのかを指定します。

• 192.168.10.0/24
• 管理端末ネットワーク
• 営業部VLAN
• VPN利用者
• 特定の監視サーバー

送信元を広くしすぎず、実際に通信が必要な範囲へ限定します。

2．Destination：宛先

通信先を指定します。

• Webサーバー
• DNSサーバー
• Active Directoryサーバー
• 監視対象機器
• インターネット
• クラウド上のシステム

3．Service：プロトコル・ポート

4．Action：通信をどう処理するか

代表的な処理には次があります。

• Allow
• Permit
• Accept
• Deny
• Drop
• Reject

製品によって表現や動作の細部は異なるため、 実際の機器仕様を確認して設計します。

5．Log：ログ取得

通信ログは障害調査だけでなく、セキュリティインシデントや監査にも利用します。

• 許可された通信を記録する
• 拒否された通信を記録する
• 管理アクセスを記録する
• インターネットとの通信を記録する
• SIEMやログサーバーへ転送する

ファイアウォール設計の基本は「必要な通信だけを許可する」

ファイアウォール設計では、 業務に必要な通信だけを許可する ことが基本です。

広すぎるポリシー

Source      : 192.168.0.0/16
Destination : Any
Service     : Any
Action      : Allow

このルールでは、非常に広い範囲の通信が許可されます。

実際に必要なのが、

192.168.10.0/24
        ↓
10.10.20.50
TCP/443

だけであれば、その範囲まで限定します。

改善したポリシー

Source      : 192.168.10.0/24
Destination : 10.10.20.50
Service     : TCP/443
Action      : Allow

「Any」を簡単に使わない

実務で起こりやすい問題の1つが、 通信仕様が分からないためAnyで許可する ことです。

Source      : User-LAN
Destination : Server-LAN
Service     : Any
Action      : Allow

本当に必要なのがHTTPSだけであっても、この設定では他の通信まで到達できる可能性があります。

• SSH
• RDP
• SMB
• データベース通信
• 管理用サービス
• その他のアプリケーション通信

暗黙の拒否を前提に必要な通信を許可する

ファイアウォールでは、必要な通信を明示的に許可し、 それ以外を許可しないという考え方で設計します。

Rule 1  User → Web Server   HTTPS      Allow
Rule 2  User → DNS Server   DNS        Allow
Rule 3  Admin → Servers     SSH        Allow
Rule 4  Monitor → Devices   SNMP       Allow
------------------------------------------------
最後    その他                         Deny

この形であれば、設計時に想定していない通信が 無条件に通過することを防ぎやすくなります。

ステートフルファイアウォールと戻り通信

ステートフルファイアウォールは、 通信のセッション状態を管理します。

PCからWebサーバーへの通信を開始した場合、 そのセッションに対応する戻り通信については、 ファイアウォールが状態情報を使って判断します。

そのため、一般的なステートフルファイアウォールでは、 単純に「行きのルールを作ったから、同じ逆方向ルールも必要」 と考えるわけではありません。

ルールの順序・重複・包含関係を確認する

ファイアウォールによっては、上から順番にポリシーを評価し、 最初に一致したルールを適用します。

たとえば次のルールを考えます。

Rule 1
Source      : 192.168.0.0/16
Destination : Any
Service     : Any
Action      : Allow

Rule 2
Source      : 192.168.10.0/24
Destination : 10.10.20.10
Service     : TCP/443
Action      : Deny

Rule 1に先に一致する評価方式であれば、 Rule 2へ到達せず、意図した拒否が機能しない可能性があります。

レビューするポイント

• 上位ルールに包含されていないか
• 同じ条件のルールが重複していないか
• 広すぎるAllowルールが上位にないか
• 実際には評価されないルールがないか
• 一時ルールが恒久ルールより上位に残っていないか

設定を作る前に通信要件表を作る

ファイアウォール設定を直接考え始めるのではなく、 最初に通信要件表を作ると整理しやすくなります。

この流れを作っておけば、 「このFWルールはなぜ必要なのか？」 と聞かれたときに、業務要件までさかのぼって説明できます。

ファイアウォールポリシーには「理由」を残す

ファイアウォールは運用年数が長くなるほどルールが増えていきます。

IPアドレスとポート番号だけを記録していると、 数年後にそのルールの目的が分からなくなることがあります。

一時ルールには期限を設定する

試験や障害調査のため、一時的に通信を許可することがあります。

その場合は、少なくとも次を管理します。

• 利用目的
• 開始日時
• 終了日時
• 申請者
• 承認者
• 削除予定日
• 削除確認

期間限定の通信は、可能であれば有効期限を持たせ、 終了後に削除確認まで実施します。

オブジェクト設計と命名規則も重要

ファイアウォールでは、IPアドレスやサービスを オブジェクトとして登録してポリシーから参照することがあります。

分かりにくい名前

ADDR01
ADDR02
SERVER01
NET01

名前だけでは何を表しているのか判断しにくくなります。

意味が分かる名前

NET_USER_TOKYO
NET_ADMIN
SRV_DNS01
SRV_WEB_PROD01
SVC_HTTPS

命名規則を統一すると、次のメリットがあります。

• レビューしやすい
• 設定ミスを減らしやすい
• 変更時の影響を確認しやすい
• 引き継ぎしやすい
• 用途不明のオブジェクトを減らせる

設計例：社内PCから業務Webサーバーへ接続する

要件

• 一般利用者は業務Webサーバーを利用する
• 接続はHTTPSのみ
• SSHやRDPなどの管理通信は不要

ポリシー設計

User VLANからServer VLAN全体へのAny通信を許可する必要はありません。

管理通信は一般利用者通信から分離する

サーバーやネットワーク機器を管理する通信は、 一般利用者の通信とは分離して設計することが重要です。

Source      : NET_ADMIN
Destination : NETWORK_DEVICES
Service     : SSH, HTTPS
Action      : Allow
Log         : Enable

一般利用者端末からネットワーク機器の管理インターフェースへ 到達できる必要はありません。

ログ設計もファイアウォールポリシー設計の一部

ファイアウォールは通信を許可・拒否するだけでなく、 通信記録を残す重要な装置でもあります。

設計時に考えること

• 許可通信を記録するか
• 拒否通信を記録するか
• 管理通信を記録するか
• セッション開始・終了のどちらを記録するか
• ログをどこへ転送するか
• 保存期間をどうするか
• 誰が確認するか
• アラート対象とする通信は何か

ログ全体の考え方については、 「20. ログ設計」 もあわせて確認してください。

ポリシー追加の標準フローを決める

ファイアウォールは構築後も、新しいシステムや業務追加によって ポリシー変更が継続的に発生します。

1. 通信要求を受け付ける 誰が何の目的で通信を必要としているのか確認します。
2. 通信要件を確認する 送信元、宛先、サービス、方向、利用期間を整理します。
3. 既存ポリシーを確認する 既存ルールで通信可能か、重複がないか確認します。
4. セキュリティレビューを行う 許可範囲が広すぎないか、リスクを確認します。
5. ポリシーを設計する FW設計書へ具体的な条件を記載します。
6. 承認を取得する 変更管理のルールに従って承認を取得します。
7. 設定変更する 手順書に基づいて機器へ設定を投入します。
8. 通信試験を行う 許可通信と拒否通信の両方を確認します。
9. ログを確認する 意図したポリシーへヒットしていることを確認します。
10. 設計書を更新する 最終的な設定状態と設計書を一致させます。

定期的に不要なファイアウォールルールを見直す

長期間運用されたファイアウォールには、 不要になったポリシーが残りやすくなります。

• 廃止済みサーバー向けルール
• 終了したプロジェクト用ルール
• 一時検証用ルール
• 旧IPアドレス向けルール
• 長期間利用されていないルール
• 他のルールに包含されているルール
• 誰も用途を説明できないルール

「使っていないように見えるから削除する」のではなく、 業務担当者やログなどを確認し、影響を評価してから変更します。

ファイアウォールポリシー設計でよくある失敗

ファイアウォール試験では許可と拒否の両方を確認する

ファイアウォールの試験では、 「必要な通信が通ること」だけでは不十分です。

正常系

User VLAN
    ↓ HTTPS
Web Server

期待結果：通信成功

異常系

User VLAN
    ↓ SSH
Web Server

期待結果：通信失敗

顧客・上司へファイアウォール設計をどう説明するか

技術に詳しくない顧客へ、

Source      : User-VLAN
Destination : Web-Server
Service     : TCP/443
Action      : Allow

とだけ説明しても、設計の意味は伝わりにくいでしょう。

顧客向けの説明例

技術設定をそのまま読み上げるのではなく、 業務・リスク・運用上の意味 に変換して説明します。

ファイアウォールポリシー設計レビューのチェックポイント

• その通信は本当に必要か
• 業務用途が明確か
• 送信元をさらに限定できないか
• 宛先をさらに限定できないか
• ServiceがAnyになっていないか
• 必要以上の双方向通信になっていないか
• 通信開始方向が明確か
• 既存ルールと重複していないか
• 上位ルールに包含されていないか
• ログ取得の要否が決まっているか
• 一時ルールには期限があるか
• 申請元・変更番号が記録されているか
• 正常系試験があるか
• 拒否試験があるか
• 運用開始後の棚卸し方法が決まっているか

ファイアウォール設計で使われる英語表現

実務で使える英文

自分の言葉で説明する課題