FortiGateのファイアウォールポリシーは、設定する順番が通信の可否やパフォーマンスに直結する重要な要素です。ポリシーの評価順序を理解せずに設定すると、意図しない通信遮断やパフォーマンス低下が発生します。この記事では、ポリシー評価の仕組みから実務で役立つ最適化のコツまでを詳しく解説します。
新規FortiGateを導入した案件で、ポリシーを追加していったところ、突然特定のサーバへの通信ができなくなったことがありました。調査すると、広範囲なdenyポリシーを上位に配置してしまい、後で追加したallowポリシーが評価されていなかったのです。
ポリシーの順番を入れ替えただけで即座に解決しましたが、この経験からポリシー順序の重要性を痛感しました。運用中のファイアウォールでは、定期的なポリシー見直しが不可欠です。
FortiGateのファイアウォールポリシーは、上から順に評価され、最初にマッチしたルールが適用されるという明確なルールがあります。これは「First Match」方式と呼ばれ、一度マッチしたら以降のポリシーは評価されません。
例えば、ポリシーID 1でallowされたトラフィックは、たとえポリシーID 10でdenyルールがあっても既に許可済みとして通過します。逆に、ポリシーID 5でdenyされた通信は、ポリシーID 15にallowルールがあっても遮断されます。
送信元IP、宛先IP、ポート番号などの情報を持つパケットがFortiGateに到着します。
ポリシーリストの最上位（最小ID）から順番に、パケットの情報と照合していきます。
条件に合致した最初のポリシーのアクション（Allow/Deny）が適用され、以降の評価は行われません。
すべてのポリシーに合致しない場合、デフォルトでdeny（暗黙的拒否）として処理されます。
ポリシーの並び順は、セキュリティとパフォーマンスの両面に大きな影響を及ぼします。適切に配置すれば効率的な通信処理が可能ですが、誤った順序では意図しない結果を招きます。
図1: ポリシー配置による影響度
FortiGateは受信したパケットごとにポリシーテーブルを上から順に検索します。頻繁に使用されるルールが下位にあると、毎回多数のポリシー評価を行う必要があり、CPU負荷とレイテンシが増加します。
特に、1秒間に数万パケットを処理する環境では、ポリシー評価のコストが積み重なり、全体のスループットに影響します。トラフィック量の多いルールを上位に配置することで、評価回数を最小化できます。
ポリシー評価回数の比較例
| トラフィック量 | 最適配置時 | 非最適配置時 |
|---|---|---|
| ポリシー10本中 | 平均2〜3回評価 | 平均7〜8回評価 |
| CPU負荷 | 10〜15% | 25〜35% |
| レイテンシ | 0.5ms未満 | 1.5〜2.0ms |
実務では、ポリシーの追加や変更を繰り返すうちに、意図しない順序になってしまうケースが多発します。特に複数の管理者が関わる環境では注意が必要です。
セキュリティを意識するあまり、「特定のネットワーク全体を拒否」するポリシーを上位に配置してしまい、その後に追加した個別許可ルールが機能しなくなるケースです。
# 問題のある配置例
Policy ID 5: Deny 10.0.0.0/8 → any (広範囲拒否)
Policy ID 10: Allow 10.1.1.100 → WebServer (個別許可) ← 評価されない！
Policy ID 15: Allow 10.2.2.0/24 → DBServer (個別許可) ← 評価されない！この場合、10.1.1.100からWebServerへの通信は、Policy ID 5で先にdenyされるため、Policy ID 10は永久に評価されません。
広範囲なdenyルールは必ず具体的なallowルールより下位に配置してください。「より具体的なルールを上位に」が鉄則です。
テスト時やトラブルシューティング時に一時的に作成した「すべて許可」のポリシーを削除し忘れ、上位に残してしまうケースです。これがあると、以降のすべてのポリシーが無効化されます。
# 危険な配置例
Policy ID 3: Allow any → any (すべて許可) ← セキュリティホール！
Policy ID 8: Deny 10.10.10.0/24 → Internet (拒否したいルール) ← 評価されない
Policy ID 12: Allow Internal → WebServer with IPS (詳細制御) ← 評価されない効率的で安全なポリシー配置を実現するための実践的なルールを紹介します。これらは大規模環境でも有効な手法です。
図2: ポリシー最適化の効果
推奨されるポリシー配置順序
| 優先度 | ポリシータイプ | 具体例 |
|---|---|---|
| 1位 | 特定IPの明示的拒否 | 攻撃元IPのブロック、禁止ホスト |
| 2位 | 高頻度・具体的な許可 | 業務サーバへのアクセス、VPN通信 |
| 3位 | 低頻度・具体的な許可 | 管理用アクセス、バックアップ通信 |
| 4位 | 範囲指定の許可 | セグメント間通信、部門別ルール |
| 5位 | 広範囲の拒否 | 内部→外部拒否、ネットワーク全体拒否 |
この順序を守ることで、セキュリティを担保しながら最適なパフォーマンスを実現できます。重要なのは、具体的なルールほど上位に配置し、抽象的なルールは下位に配置するという原則です。
FortiGateでは、GUI（Web画面）とCLI（コマンドライン）の両方でポリシー順序を変更できます。それぞれの方法を実例とともに紹介します。
Web管理画面からの変更は直感的で、変更結果をすぐに視覚的に確認できます。
Policy & Objects → Firewall Policy に移動します。
移動したいポリシーの行を右クリックし「Move」を選択します。
「Before」または「After」で基準となるポリシーIDを選択し、OKをクリックします。
CLIでは、より精密な制御と複数ポリシーの一括移動が可能です。スクリプト化にも適しています。
# ポリシーID 15を、ポリシーID 3の前に移動
config firewall policy
move 15 before 3
end
# ポリシーID 20を、ポリシーID 10の後に移動
config firewall policy
move 20 after 10
end
# 現在のポリシー順序を確認
show firewall policy | grep "edit"CLIでの変更後は、必ず順序が正しく変更されたことを確認してください。GUIで視覚的に確認するのが確実です。
本番環境でポリシー順序を変更する際は、必ずメンテナンスウィンドウを設定し、変更前のconfigをバックアップしてください。順序変更により意図しない通信遮断が発生する可能性があります。
最適化の効果を測定するため、各ポリシーのヒット数（マッチ回数）を定期的に確認することが重要です。
# すべてのポリシーのヒット数を表示
diagnose firewall iprope list 100000
# 特定ポリシーの詳細統計
get firewall policy statistics
# セッション数の確認
diagnose sys session statヒット数が多いポリシーを上位に移動することで、全体の処理効率が向上します。月次で統計を取り、ポリシー配置を見直すことをお勧めします。
FortiGateのファイアウォールポリシーは上から順に評価され、最初にマッチしたルールが適用される仕組みです。この特性を理解し、適切な順序で配置することがセキュリティとパフォーマンスの両立に不可欠です。
- 具体的なルールを上位に、抽象的なルールを下位に配置する
- 高頻度のトラフィックに対応するポリシーは上位に移動する
- 広範囲denyポリシーは個別allowポリシーより必ず下位に配置
- 定期的にヒット数統計を確認し、ポリシー順序を最適化する
- 本番環境での変更は必ずバックアップとメンテナンスウィンドウを確保する
