ファイアウォールの例外設定とは、既定の通信制御ポリシー(多くは「不要な通信は拒否」)に対して、特定条件の通信を「許可ルール」として明示的に追加することを指します。
重要なのは、例外設定は
- 無秩序に通信を通すためのものではなく
- 業務・システム上必要な通信を、条件付きで限定的に許可するための仕組み
である、という点です。
ファイアウォールの基本動作モデル
多くのファイアウォールは、以下の考え方で設計されています。
- 明示的に許可された通信のみ通す
- 条件に一致しない通信は拒否される
この前提のもとで、「例外」とは本来は拒否される通信のうち、正当な理由があるものだけを許可するルールを意味します。
例外設定で制御する主な要素
例外(許可)ルールは、通常以下の条件を組み合わせて定義します。
通信方向(インバウンド / アウトバウンド)
| 種類 |
内容 |
| インバウンド |
外部 → 内部(例:Web公開、SSH接続) |
| アウトバウンド |
内部 → 外部(例:API通信、更新通信) |
特にインバウンド通信は攻撃対象になりやすいため、厳密な制御が必須です。
IPアドレス(送信元 / 宛先)
原則として
許可するIPはできる限り限定する
という設計が推奨されます。
ポート番号
代表的な例は以下の通りです。
| ポート |
主な用途 |
| 80 |
HTTP |
| 443 |
HTTPS |
| 22 |
SSH |
| 21 |
FTP |
| 3306 |
MySQL |
ポートは「使うものだけ開ける」が基本です。
プロトコル
ポートとプロトコルは必ずセットで考え、不要な組み合わせは許可しません。
アプリケーション / プロセス(主にOSレベルFW)
OS内蔵のファイアウォールでは、
- ポートではなく
- 特定のアプリケーション単位で通信を許可
できる場合があります。
同じポート番号でも、意図しないプログラムの通信を防げる点が特徴です。
代表的な例外設定の実例
Webサーバーを公開する場合
目的
外部からWebアクセスを受け付ける
一般的な設定例
- 方向:インバウンド
- ポート:443(HTTPS)
- プロトコル:TCP
- 送信元IP:必要に応じて制限
※ HTTP(80番ポート)は、
- HTTPSへのリダイレクト
- 証明書取得方式
など明確な必要性がある場合に限って開けるのが実務的です。
SSHでサーバー管理を行う場合
目的
管理者のみがサーバーに接続する
設定例
- インバウンド通信
- 送信元IP:管理者の固定IPのみ
- ポート:22(または変更後のSSHポート)
- プロトコル:TCP
さらに安全性を高める場合は、
- VPN経由のみ許可
- 公開鍵認証必須
といった対策を組み合わせます。
外部APIへ通信する場合(アウトバウンド)
目的
内部システムから外部APIへ接続
設定例
- アウトバウンド通信
- 宛先:API提供元のIPまたは範囲
- ポート:443
- プロトコル:TCP
アウトバウンド通信も無制限に許可しないことが、被害拡大防止の観点で重要です。
クラウド環境における注意点
クラウド環境では、通信制御が複数レイヤーで行われます。
- 仮想ネットワークレベルのファイアウォール
- インスタンス単位の許可ルール
- OS内のファイアウォール
そのため、通信トラブル時は
「どのレイヤーで止められているか」
を切り分ける必要があります。
例外設定で起きやすい問題点
一時的な許可が放置される
ルールの意図が分からない
ログを確認していない
が判断できなくなります。
良い例外設定の基本原則
- 最小権限の原則
必要最小限のIP・ポート・期間だけ許可する
- 既定動作を理解する
ルール評価順序やデフォルト拒否の有無は製品ごとに異なる
- ルールには必ず理由を記載する
「なぜ必要か」が分かる状態にする
- 定期的に棚卸しを行う
使われていない例外は削除する
Web制作・Web運用視点での実務的注意
Web系の業務では、
などがファイアウォールのアウトバウンド制限で失敗するケースが多くあります。
アプリやCMSの不具合に見えても、実際は通信が遮断されているだけということも少なくありません。
まとめ
- 例外設定とは「通信を緩めること」ではなく
必要な通信を条件付きで許可すること
- IP / ポート / プロトコル / 方向を必ず限定する
- インバウンドは特に慎重に扱う
- 製品ごとの仕様(評価順・既定動作)を理解する
- ルールは作って終わりではなく、管理・棚卸しが重要
以上、ファイアウォールの例外設定についてでした。
最後までお読みいただき、ありがとうございました。