ファイアウォールポリシーについて

ファイアウォールポリシーとは、ネットワークやシステム間の通信について、「どこから」「どこへ」「どの通信を」「どの条件で」「許可または拒否するか」を定義したルールの集合である。

単なる通信遮断機能ではなく、業務要件・セキュリティ方針・運用ルールを具体的な通信制御に落とし込んだ設計情報という位置づけになる。

ファイアウォールポリシーを構成する主な要素

一般的なポリシーは、次の要素の組み合わせで定義される。

• 送信元（Source）
  IPアドレス、ネットワーク範囲、ゾーン、場合によってはユーザーやデバイス
• 宛先（Destination）
  サーバー、サービス、IPアドレス、FQDN など
• サービス／プロトコル
  TCP/UDP、ポート番号、アプリケーション識別（製品による）
• アクション
  許可（Allow）または拒否（Deny）
• ログ設定
  通信を記録するかどうか、記録粒度

これらを組み合わせることで、ネットワーク内外の通信ルールを明示的に管理する。

ファイアウォールポリシー設計の基本原則

デフォルトデナイ（Default Deny）

設計の基本は、「原則としてすべての通信を拒否し、業務上必要なもののみを許可する」という考え方である。

• 事前に許可されていない通信は通らない
• ルールの意図が明確になり、監査やレビューが容易
• 想定外の通信や攻撃の影響範囲を最小化できる

この原則が守られていないポリシーは、セキュリティ事故の温床になりやすい。

最小権限の原則（Least Privilege）

許可する通信は、送信元・宛先・ポート・プロトコルを可能な限り限定する。

例

• 社内ネットワークからWebサーバーのHTTPS（443）のみ許可
• 管理端末から管理サーバーのSSHのみ許可

「広く許可して後で制限する」ではなく、「必要最小限から始める」ことが重要である。

ファイアウォールの方式とポリシーの考え方

パケットフィルタリング（L3/L4中心）

• IPアドレス、ポート番号、プロトコルなどを基準に通信を制御
• 高速でシンプル
• 通信内容の詳細解析は行わない（または限定的）

※実際には、製品によって異常なフラグや簡易検査を行う場合もあるため、「一切中身を見ない」と断定するのは不正確である。

ステートフルインスペクション

• 通信の状態（セッション）を管理
• 正常に確立した通信に対する戻り通信を許可
• 現在のファイアウォールでは主流の方式

なお、UDPなど状態が曖昧な通信では、タイムアウトや疑似状態管理によって制御される点に注意が必要である。

アプリケーションレベル制御（L7）

• アプリケーション層のプロトコルを理解した上で制御
• URL、HTTPメソッド、ヘッダ、アプリ識別などを条件にできる

ここで重要なのは、L7ファイアウォールとWAF（Web Application Firewall）は目的が異なるという点である。

• L7ファイアウォール：通信制御やアクセス制限が主目的
• WAF：SQLインジェクションやXSSなど、Webアプリ攻撃防御に特化

近年は機能が統合されがちだが、概念としては区別して理解する必要がある。

ファイアウォールポリシーの評価順序についての注意点

多くのファイアウォールでは、ルールは上から順に評価され、最初に一致したものが適用される。

ただし、これは以下の理由により製品依存・構成依存である。

• 優先度や重み付けが内部的に行われる製品
• オブジェクトグループやポリシーセットによる抽象化
• アプリ識別やユーザー連携が絡む評価エンジン
• クラウド環境特有の評価モデル

したがって、「必ず上から順」と断定せず、対象製品の仕様を前提に設計・検証することが必須である。

NATとファイアウォールポリシーの関係

実運用では、NAT（SNAT / DNAT）とポリシーの関係を無視できない。

• ポリシーは「変換前アドレス」で評価されるのか
• それとも「変換後アドレス」で評価されるのか

この違いを誤ると、

• ルールが意図通りにマッチしない
• 不要に広い許可を入れてしまう

といった事故につながる。

NAT処理のタイミングとポリシーマッチングの関係は必ず確認する必要がある。

よくある危険なポリシーと正しい扱い方

ANY-ANY-ALLOW について

送信元：ANY
宛先　：ANY
サービス：ANY
許可

恒久的に存在するこのようなルールは、極めて高リスクな状態である。

ただし、トラブル対応や移行期間中に一時的に設定されるケースが存在すること自体は否定できない。

その場合でも、

• 明確な目的
• 有効期限
• ログ取得
• 後日の削除計画

を必ずセットで管理しなければならない。

ログと運用の重要性

ファイアウォールポリシーは「作って終わり」ではない。

• 拒否ログ：攻撃や誤設定の兆候検知
• 許可ログ：特に管理系通信では必須
• 定期的な棚卸し：未使用ルール・暫定ルールの削除
• 変更管理：申請・レビュー・検証・ロールバック

これらが揃って初めて、ポリシーは管理されたセキュリティ設定になる。

クラウド環境における補足

クラウドでは、ファイアウォール機能が複数の層に分かれている。

• ステートフルな制御（例：セキュリティグループ）
• ステートレスな制御（例：ネットワークACL）

これらはオンプレミスのファイアウォールと同じ感覚で扱うと誤解が生じやすいため、どの層で、どの責務を持たせるかを明確にする必要がある。

また近年は、IPベース制御に加えてID（誰が）・役割（何として）・アプリ（何を）を組み合わせた多層防御が主流になっている。

まとめ

• ファイアウォールポリシーは通信制御ルールの集合である
• 原則はデフォルトデナイと最小権限
• 評価順序、NAT、ログは製品・環境依存であり断定は避ける
• ANY許可は恒久化しない
• 設計と同じくらい運用・棚卸しが重要

以上、ファイアウォールポリシーについてでした。

最後までお読みいただき、ありがとうございました。