ファイアウォールはしばしばチェックボックスとして扱われます。1つをデプロイし、いくつかのルールを書いて、先に進む。しかし応用ファイアウォール設計はそれ自体が学問分野です—ネットワークセグメンテーションが実際に攻撃者を封じ込めるのか、それとも単に偽りのセキュリティ感覚を与えるだけなのかを決定する分野です。このセクションでは、設計の優れたファイアウォールデプロイメントと、場当たり的なルール集合を分ける実用的な意思決定を説明します。
ルールではなくゾーンから始める
単一のACLを書く前に、信頼ゾーンを定義します。典型的なエンタープライズレイアウトは、インターネット向きDMZホスト、内部ユーザーネットワーク、サーバー/データ層、および管理/OOBネットワークを分離します。各ゾーンは異なる信頼レベルを表すべきであり、ゾーン間のトラフィックは例外であるべきで、デフォルトではありません。
どのトラフィックが正当に何と通信する必要があるかをマッピングします。このトラフィックフローのインベントリは退屈ですが、すべての基盤となります。これをスキップすると、サブネット間の「任意のトラフィックを許可」ルールが過度に許容的になり、セグメンテーションの目的そのものが台無しになります。
デフォルト拒否は譲歩できない
すべてのインターフェース、すべてのゾーンペアは、暗黙的または明示的な拒否で終了する必要があります。ルールは閉鎖的なポスチャへの追加的な例外であるべきで、開放的なポスチャからの減除的な例外ではありません。これは当たり前に聞こえますが、監査では日常的にファイアウォールが見つかります。そこには、急いでデプロイされたことで残された許容的なキャッチオールルール、または削除されたことのない「一時的な」トラブルシューティング変更があります。
デフォルト拒否が何かを壊すとき、それは実際に価値のあるシグナルです—文書化されていない依存関係を見つけたことを意味し、それは暗黙的に許可されるのではなく、明示的にモデル化される必要があります。
ルール順序と特異性
ほとんどのファイアウォールエンジンはルールを上から下に評価し、最初のマッチで停止します。これにより、順序付けは事後考えではなく、設計上の決定になります。具体的なルール（単一ホスト、単一ポート）は通常、広いルール（サブネット範囲、ポート範囲）に先行する必要があります。一般的な失敗モードは、広い許可ルールをリストの早い段階に配置することです。これにより、その下のより制限的なルールが暗黙的に影が落とされます—これらのルールはペーパー上に存在しますが、実際には発火しません。
影が落とされたルールと冗長なルールを定期的に監査します。ルールヒットカウントを視覚化するツールはここで非常に価値があります—意味のある期間にわたってゼロヒットのルールは、無駄であるか、より悪いことに、予期しなかったパスを通じてトラフィックが流れていることの証拠です。
ステートフルインスペクションとその限界
モダンファイアウォールは接続状態を追跡し、これにより開始方向のみのルールを書き、エンジンに戻りトラフィックを許可することを信頼できます。これはステートレスパケットフィルタリングよりも大幅な簡略化ですが、アプリケーション層認識の代替ではありません。TCP/443アウトバウンドを許可するステートフルファイアウォールは、そのトラフィックが正当なHTTPSであるか、同じポート上にトンネリングされたC2チャネルであるかについて知識がなく、また気に留めません。可能な場合は、ファイアウォール実装とアプリケーション層可視性を組み合わせます—プロキシ、ポリシーが許可する場合のTLS検査、またはNGFWアプリケーション識別—ポート番号を意図のプロキシとして依存するのではなく。
エグレスフィルタリングは同等の注意に値する
組織はインバウンドルールに執着し、アウトバウンドを無視します。これはインシデント対応の観点から逆向きです。攻撃者が足がかりを得ると、エグレスコントロールはデータを流出させたり、インフラストラクチャにコールバックできるかどうかを決定するものです。ゾーンごとに明示的なエグレスポリシーを定義します—サーバーが無制限のアウトバウンドインターネットアクセスを必要とすることはめったにありませんし、ワークステーションが任意の外部IPとの接続を任意のポートで開始する必要があることはめったにありません。制限的なエグレスはすべてを停止しませんが、搾取後の活動のコストを上げ、異常なトラフィックがフラグされる可能性を高めます。
変更管理とドリフト
ファイアウォールルールセットは時間とともに不用品を蓄積します。数年前に終了したプロジェクトのために追加されたルール、一時的な例外が恒久的になったルール、誰も目的を覚えていないルール。ファイアウォール設定をコードとして扱います—バージョン管理され、ピアレビューされ、すべてのルールについて文書化された業務上の正当性に結び付けられます。定期的なレビューをスケジュールして、古い項目を削除します。千個の文書化されていないルールを持つファイアウォールは、より小さく理解されたルールセットよりも実際のセキュリティを提供します。なぜなら、誰もそれが実際に何を許可するかについて推論できないからです。
ロギングと相関
トラフィックを暗黙的にブロックするファイアウォールは、半分しか役に立たない。拒否および関心のあるトラフィックが許可されていることが、十分なコンテキスト（ゾーン、ルールID、送信元/送信先、プロトコル）とともにSIEMまたはログパイプラインにログされ、送信されていることを確認します。インシデント中、ファイアウォールログは、横展開または流出の試みのタイムラインを確立するための最速の方法であることが多いです—ただし、保持と忠実度が事前に設定されている場合のみです。
まとめ
応用ファイアウォール設計は、正しいベンダーを選択したり、最新のNGFW機能セットを選択することについてではありません—規律のあるゾーンモデリング、デフォルト拒否実装、注意深いルール衛生、およびエグレスをイングレスと同じ真摯さで扱うことについてです。基本を正しく実行すれば、高度な機能はアーキテクチャの代替ではなく、力の乗数になります。
ネットワークセグメンテーション、ログ相関、ブルーチーム基礎の詳細については、Korra StudioのDEFENSE_GRIDライブラリの関連セクションを参照してください。
