ファイアウォール/セキュリティグループのルール設計 — 許可の粒度をどこで切るか

ファイアウォールのルールは「必要になったら追加する」という運用を続けると、気づけば誰も全体を把握できない肥大したリストになる。設計判断の核心は「何を許可するか」だけでなく、「どこで線を引き、それ以外を捨てるか」にある。本記事では、デフォルトポリシーの選択から粒度の決め方、コード管理の境界まで、構築担当者が直面する設計の分岐点を整理する。

ルールを都度足して穴だらけになる構造

追加だけが繰り返されるルールセットの末路

構築プロジェクトが動き始めた直後は、ルールの数は少ない。しかし運用フェーズに入ると「新しいサービスが疎通しない」「テスト環境だけ一時的に開けたい」という要求が積み重なり、担当者はその都度ルールを追加していく。削除されることなく積み上がったルールは、プロジェクト開始から1年が経つ頃には数十件を超え、どのルールがどの要件に対応するのか追えない状態になる。現場では「触ると何かが壊れそうで手が出せない」という話をよく聞く。これはルールに追加理由が紐づいていないことが原因で、追加時のコンテキストが失われると削除判断が不可能になる。

環境数の増加がルール管理を指数的に複雑にする

開発・ステージング・本番の3環境を持つ構成であれば、ルールの変更を3か所に適用しなければならない。環境ごとに手作業で更新していると、1か月後には環境間でルール内容が食い違うことが起こる。10台規模のサーバー群であれば個別管理も何とかなるが、50台・100台と規模が拡大するにつれて、手作業での同期は破綻する。ある構築案件では、本番にだけ特定ポートへのアクセスが残っており、ステージングでは閉じていたために検証を通過した設定が長期間放置されていたケースが報告されている。環境数と台数の積がそのまま管理コストの目安になる。

ルール肥大化がレビューを機能不全にする

セキュリティレビューの文脈でファイアウォールルールを確認するとき、200件を超えるリストを目視でチェックすることは現実的ではない。命名規則がなく説明欄も空白のルールが並ぶ状態では、レビュアーは「問題がなさそう」という印象判断しかできなくなる。本来のレビューとは「このルールは今も必要か」「より狭い範囲で代替できないか」を問うものだが、肥大化したリストの前ではその問いかけ自体が成立しない。設計フェーズで「ルールをどこで止めるか」を決めておかないと、レビュープロセスも形骸化していく。

許可で始めるか拒否で始めるかの設計判断

デフォルト許可とデフォルト拒否が生む構造的な差

ファイアウォールのデフォルトポリシーには「デフォルト許可（通過させてから例外で遮断）」と「デフォルト拒否（遮断してから例外で開放）」の二つがある。前者はルールを少なくできる反面、「遮断し忘れ」が攻撃面になる。後者は必要なものしか通らないため安全度は高いが、許可漏れによって通信が止まるリスクと隣り合わせになる。本番環境に近いほどデフォルト拒否を選ぶべき理由は明確で、「何が通っているか」を設計者が把握しきれているという前提を維持するためだ。デフォルト許可のまま進むと、その前提は設計の初期段階から崩れている。

インバウンドとアウトバウンドの非対称な扱い

インバウンドについては多くの担当者が慎重に設計するが、アウトバウンドは「制限しなくてもいいだろう」という判断で開放したままにされることが多い。しかしアウトバウンドの無制限開放は、C2通信やデータ外送の経路になり得る。より厳密に設計するなら、アウトバウンドもデフォルト拒否とし、外部APIやNTPサーバーなど必要な宛先だけを許可する形が理想だ。現実的な落とし穴は「どこに通信が発生するか分からない」という状況で、アプリケーションが必要とする通信先を実装前に洗い出す工程を設計フェーズに組み込んでおく必要がある。

ステートフルとステートレスが混在する設計での整合

AWSのセキュリティグループはステートフルであり、インバウンドで許可したセッションの戻りパケットはアウトバウンドルールなしで通過する。一方、ネットワークACLはステートレスであり、戻りパケットのために別途アウトバウンドルールを定義しなければならない。この二つを同一VPC内で組み合わせるとき、片方だけを意識して設計すると通信が通らない状態になる。設計段階でステートフル層とステートレス層の責務を分離し、「どちらで何を制御するか」を明示的に決めておくことが判断の起点になる。

ポート単位・送信元単位・タグ単位でどこまで絞るか

ポート範囲指定が生む意図しない開口部

「アプリケーションが使うポートは大体この範囲だから」という理由で8000〜9000のような範囲指定を行うと、使っていないポートまで開放した状態になる。ポート8080だけ必要なら8080を単体で指定するべきだ。範囲指定は「今後の拡張に備えて」という意図で行われることが多いが、拡張が発生したときに改めてルールを追加する運用の方が、攻撃面の管理という観点では正しい。1000ポートを範囲指定で開けておくことと必要なポートだけを個別に開けることの間に通信上の差はないが、攻撃面は大きく異なる。

送信元IP固定とセキュリティグループ参照の使い分け

送信元をIPアドレスで指定する方法は直感的だが、オートスケーリングやコンテナのような動的インフラでは送信元IPが変動するため、IP固定の管理は現実的でなくなる。AWSのセキュリティグループでは、送信元として別のセキュリティグループを参照する設計が可能で、「このグループに属するリソースからのアクセスを許可する」という意図をルールとして表現できる。これによりIPアドレスの変動に依存せず、論理的な単位で制御できる。オンプレミスからクラウドへの移行期など、IPが固定できる範囲とできない範囲が混在する環境では、この使い分けを設計段階で明確にしておく必要がある。

タグベース制御が適切な場面とその限界

タグを使った制御は、クラウド上でリソースを動的に分類する際に有効だが、タグ自体の管理が甘いと制御が意図通りに機能しない。「role=web」というタグが付いたリソースだけを通すポリシーは、タグが正確に付与されているという前提に立つ。タグの付け忘れや誤付与が発生すると、通信できないか意図しないリソースに通信が届くかのどちらかになる。タグベース制御を設計に組み込む場合は、タグの命名規則・付与ルール・監査の仕組みをセットで設計しなければ、制御の信頼性が担保されない。

ホストfirewall・セキュリティグループ・ネットワークACLの守備範囲

三つの制御レイヤーは守備範囲が異なり、重複して使うことで多層防御になる。どれか一つで済まそうとすると、カバーできない領域が生まれる。下表はそれぞれの特性を整理したものだ。

比較項目	ホストファイアウォール（iptables / nftables）	セキュリティグループ（AWS / GCP）	ネットワークACL（AWS VPC サブネット）
適用レイヤー	OS内部（ホスト単位）	ハイパーバイザー（インスタンス単位）	サブネット境界
ステートフル／ステートレス	ステートフル（conntrack使用時）	ステートフル	ステートレス
戻りパケットの扱い	conntrackで自動許可	自動で許可（アウトバウンドルール不要）	別途アウトバウンドルールが必要
ルール評価順	チェーン内の定義順	全ルールを評価し許可が優先	番号の小さいルールを優先評価
主な用途	OSレベルの細粒度制御・ホスト間フィルタリング	クラウドリソース間の通信制御	サブネット単位の粗粒度フィルタリング
変更の即時反映	即時（既存セッションに影響する場合あり）	即時（既存セッションにも反映）	即時（ステートレスのため影響範囲が広い）

ホストファイアウォールはクラウドのセキュリティグループが存在する場合でも、「クラウド側の設定ミスがあってもOS層で止められる」という多層防御の観点から有効だ。セキュリティグループはリソース単位の柔軟な制御に向いており、ネットワークACLはサブネット全体に一括で適用したい粗粒度の制限に使う。三者は代替関係ではなく補完関係にある点を設計段階で整理しておくことが重要だ。

ルールをコードで宣言し重複を抑える境界

IaCでルールを管理する設計粒度の決め方

TerraformやCloudFormationでセキュリティグループを管理する場合、「インフラ全体を1ファイルに書く」か「機能単位でモジュール化する」かの選択が設計の分岐点になる。巨大な1ファイルはgit diffでどこが変わったか追いにくくなり、変更レビューの質が落ちる。機能単位のモジュール化は、同じルールセットを複数環境で再利用するときに力を発揮する。ただし、モジュールの粒度が細かすぎると参照関係が複雑になり、かえって可読性が下がる。「1モジュールが何の責務を持つか」を先に定義し、それに合わせてルールをグループ化する順序が重要だ。

重複ルールが生まれる境界を設計で抑える

複数のチームが独立してセキュリティグループを管理していると、同じ送信元・同じポートへの許可が別々のリソースで定義されることがある。重複したルールは即座に悪影響を及ぼすわけではないが、「本当は削除すべきルールが残っている」状態と見分けがつかなくなる。Terraformのstate管理で他チームの変更が上書きされる問題も生じやすい。対策として、「アプリケーションチームが管理するルール」と「プラットフォームチームが管理するルール」を明確に分け、それぞれの管理ファイルとstateを分離しておくことが有効だ。

ドリフト検知とルール一致の保証

IaCで管理していても、コンソールから手動でルールを追加した瞬間にコードと実態が乖離する。この乖離を「ドリフト」と呼び、蓄積すると次のapply時に意図しない削除が起きる。CI/CDパイプラインにplan結果の確認ステップを組み込み、差分が出た際にアラートを上げる仕組みが必要だ。本番環境への変更頻度が高い場合はPR単位で自動チェックが走る設計が望ましく、週次の定期チェックでも一定の効果がある。コードと実態の一致は、ルール管理全体の信頼性を支える基盤になる。

絞りすぎて通信が止まる・緩めて攻撃面が広がる境界

過度な制限が引き起こす障害パターン

セキュリティを強化しようとルールを絞り込んだ結果、必要な通信まで遮断して本番障害を起こすケースは珍しくない。典型的なパターンは、アウトバウンドルールの追加直後にDNS解決が止まる、NTPへの通信が遮断されて時刻がずれる、外部ライブラリのダウンロードができなくなりデプロイが失敗するといったものだ。いずれも「どの通信が必要か」のリストアップが不完全なまま制限をかけた結果で、設計段階でアプリケーションの通信要件を洗い出す工程を省いたことに起因する。変更を本番に適用する前にステージング環境で通信テストを実施し、主要なエンドポイントへの疎通を確認する手順を設計に組み込んでおくことが重要だ。

緩いルールが長期間残るアンチパターン

「急ぎで開けた」ルールが数か月後も残り続けるケースは多い。特定の障害対応のために0.0.0.0/0からのアクセスを一時的に許可し、対応が終わった後も削除されずに残るパターンだ。セキュリティグループの変更ログは記録されるが、ルールの削除は積極的に行わなければ起きない。有効期限のない一時ルールは実質的に永続ルールになる。対策として、ルール追加時に「削除予定日」と「追加理由」をタグまたは説明欄に記録する運用ルールを設けると、定期棚卸しの際に判断材料が揃う。月次または四半期ごとに全ルールをレビューするサイクルを設計フェーズで決めておくと、恒常化しやすい。

変更時のリスク評価フレーム

ルールを変更するとき、影響範囲が読めないまま適用すると意図しない障害が起きる。変更前に「どのリソースがこのルールに依存しているか」「変更後に通信が止まる可能性があるフローはどれか」を確認するフレームが必要だ。具体的には、変更対象のセキュリティグループに紐づくリソースのリスト、通信の依存グラフ、ロールバック手順の3点を変更前に準備する。10件以上のルールを一度に追加・削除するような大規模変更は、段階的に適用するかメンテナンスウィンドウを設けることが判断の基準になる。変更をまとめて一括適用するリスクは、変更件数に比例して高まる。

ファイアウォール設計チェックリスト

以下は設計フェーズの終盤または運用移行前に確認する項目を整理したものだ。全項目にチェックが入らない状態で本番移行を迎えると、後からの修正コストが大きくなる。

1. デフォルトポリシーの明示: 本番・ステージング・開発の各環境でデフォルト拒否／許可の方針を明示的に定めているか。
2. アウトバウンドの設計: アウトバウンドルールが「全開放」になっていないか。必要な宛先リストを起点に絞り込んでいるか。
3. ポートの最小化: 範囲指定ではなく単体ポート指定になっているか。範囲指定を使う場合は理由と削除条件が記録されているか。
4. 送信元の論理化: 動的インフラ（オートスケーリング・コンテナ）に対してIPベースではなくグループ参照またはタグベース制御を採用しているか。
5. ルールへのコンテキスト付与: 各ルールに追加理由・追加日・削除予定日が記録されているか（タグまたは説明欄）。
6. IaC管理の徹底: セキュリティグループの全ルールがコードで管理されており、コンソールからの手動追加が禁止または検知される仕組みがあるか。
7. チームの管理境界の分離: 複数チームが管理する場合、stateファイルと管理ファイルが分離されており、責務の重複がないか。
8. ドリフト検知の仕組み: CI/CDまたは定期スキャンでコードと実態の乖離を検出できるか。
9. 通信要件のリストアップ: アプリケーションが必要とする全通信先（インバウンド・アウトバウンド）が設計書またはIaCコメントに記載されているか。
10. 変更時の影響範囲確認手順: ルール変更前に依存リソースのリストとロールバック手順を確認するプロセスが定義されているか。
11. 定期棚卸しの設計: 月次または四半期の棚卸しサイクルが決まっており、担当者が割り当てられているか。
12. 多層防御の確認: ホストファイアウォール・セキュリティグループ・ネットワークACLのどの層をどの目的で使うかが明示されており、冗長性が担保されているか。