すべてを境界ファイアウォールで防がない – 破棄条件を配置する場所

ファイアウォール設計では、何を破棄するかだけでなく、どこで破棄するかを決める必要があります。同じパケットを破棄する場合でも、アクセススイッチ、境界ルーター、境界ファイアウォール、ホスト、アプリケーションでは、利用できる判断材料と保護できる資源が異なります。

従来の境界防御では、組織内外の境界に高機能なファイアウォールを配置し、そこへ制御を集中させる構成が一般的でした。しかし現在では、クラウド、コンテナ、リモートアクセス、SaaS、拠点間接続などにより、通信経路を単一の境界へ集約できるとは限りません。東西通信や同一セグメント内の通信は、境界ファイアウォールを通過しないこともあります。

これは境界ファイアウォールが不要になったという意味ではありません。境界ファイアウォールに判断できることと、判断できないことを区別し、破棄条件ごとに適切な実施点を選ぶ必要があるということです。

この記事は「ポート番号から考えないファイアウォール設計」シリーズの第 6 回です。ここでは、破棄条件を決めるだけでなく、その条件をどの装置、レイヤー、実施点で判定するかを扱います。

破棄する場所は、判断材料と保護対象から決める

一般に、送信元に近い場所ほど大量の通信を早い段階で排除できます。その一方で、送信元に近い場所では、通信の目的やアプリケーション上の意味を判断する材料が不足します。

宛先に近づくほど、ユーザー ID、ワークロード、HTTP メソッド、API、認証状態などの情報を利用できるようになります。しかし、その段階まで通信を運ぶために、回線、ルーター、ファイアウォール、ロードバランサー、OS などの資源はすでに消費されています。

したがって、破棄位置を決める際の原則は次のように表現できます。

十分な判断材料を持つ、できるだけ上流の地点で破棄します。

ここで重要なのは、単純に「送信元に近いほどよい」としないことです。判断材料が不足した地点で厳しい制御を行えば、正当な通信まで破棄する可能性があります。反対に、十分な情報が得られるまで検査を遅らせれば、その手前にある資源を保護できません。

配置	利用できる判断材料	保護しやすい資源	主な制約
送信元ホスト、アクセスネットワーク	ポート、MAC アドレス、割り当て IP アドレス、端末属性	組織内ネットワーク、上流回線	アプリケーション上の目的までは分からない
L3 ゲートウェイ、境界ルーター	プレフィックス、経路、インターフェース、VRF	回線、ルーター、下流装置	ユーザーや処理内容を識別しにくい
境界ファイアウォール	ゾーン、接続状態、NAT、L3/L4 情報	公開ネットワーク、DMZ、内部ネットワーク	暗号化された通信の意味を十分に判断できない場合がある
内部セグメンテーション	ワークロード、所属ネットワーク、通信方向	業務システム間、管理ネットワーク	経路変更や構成変更への追従が必要
ロードバランサー、WAF、API ゲートウェイ	TLS、HTTP、URI、ヘッダー、API 単位の情報	Web/API 処理資源	回線や上流装置の枯渇には間に合わない
アプリケーション	ユーザー、権限、業務データ、処理コスト	業務機能、データ	ネットワーク資源の保護には向かない

送信元の正当性は、送信元に近い場所ほど詳しく検証できる

送信元アドレスの検証は、破棄位置によって判断精度が変わる典型例です。

インターネット境界では、プライベートアドレス、自組織のアドレス、予約済みプレフィックスなど、外部から到着するはずのない送信元を破棄できます。しかし境界ルーターが確認できるのは、主としてプレフィックスや経路の整合性です。その IP アドレスが、組織内のどの端末へ割り当てられたものかまでは通常判断できません。

これに対して、端末を直接収容するアクセスネットワークでは、次のような対応関係を把握できる場合があります。

• 物理ポートまたは無線接続
• MAC アドレス
• DHCP によって割り当てられた IP アドレス
• VLAN、VRF、テナント
• 認証された端末またはユーザー

この地点では、「組織内のプレフィックスに含まれる」という粗い条件ではなく、「この接続点から使用してよいアドレスである」という細かい条件で検証できます。

SAVI は、IP アドレスと接続点を表すバインディングアンカーを対応付け、送信元アドレスの詐称をアクセスネットワークで抑止する考え方です。BCP 38 による入口フィルタリングを、アクセスネットワーク側のより細かい粒度で補完する位置づけになります。

uRPF などの経路に基づく検証も有効ですが、経路の存在は端末への割り当てを証明するものではありません。どの粒度の正当性を確認するのかによって、配置すべき検証点は変わります。

境界ファイアウォールが担当すべきこと

境界ファイアウォールは、信頼領域の異なるネットワーク間において、通信方向、接続状態、公開サービス、NAT などを制御する地点として引き続き重要です。特に、インターネットから内部ネットワークへの新規接続を原則として拒否し、公開対象だけを明示的に許可する設計は、境界で実施するのが合理的です。

境界ファイアウォールが担当しやすい条件には、次のようなものがあります。

条件	境界に適している理由
外部から内部への未許可の新規接続	信頼領域をまたぐ通信方向を把握できる
外部から到着する自組織送信元アドレス	トポロジー上成立しないことを判断できる
公開していない宛先・プロトコル・ポート	公開サービスの一覧と照合できる
接続状態と矛盾するパケット	ステートテーブルと照合できる
DMZ から内部への不要な通信	ゾーン間ポリシーとして定義できる
管理系ネットワークへの直接接続	管理境界を集中的に保護できる

一方で、境界ファイアウォールだけでは判断できない条件もあります。たとえば、HTTPS 通信が正当な業務操作なのか、API を呼び出すユーザーに権限があるのか、処理コストの高いリクエストが濫用されているのかは、L3/L4 の状態だけでは判定できません。

また、境界ファイアウォールへ到達した時点で回線が飽和している場合、そこで破棄しても回線資源は保護できません。大規模な DDoS に対しては、ISP、クラウド事業者、スクラビングサービスなど、さらに上流での対処が必要です。RTBH などによって経路制御を利用して攻撃通信を上流で破棄する手法も、この問題に対する実装の一つです。

ルーター自身を守る制御は、転送通信の制御と分ける

境界ルーターでは、通過する通信だけでなく、ルーター自身の制御プレーンへ向かう通信を保護する必要があります。ルーティングプロトコル、管理接続、ICMP、ARP や IPv6 Neighbor Discovery など、装置自身が処理する通信は CPU 資源を消費します。

この制御を下流のファイアウォールだけに任せることはできません。ファイアウォールへ転送されず、ルーター自身で終端される通信だからです。

そのため、ルーターの制御プレーンに対しては、次のような条件を装置自身または直近のネットワークで適用します。

• ルーティングプロトコルの送信元と受信インターフェース
• 管理接続を許可する管理ネットワーク
• 制御通信の種類と通信量
• フラグメントや例外処理を必要とするパケット
• 正常時に必要となる最大レート

は、ルーターの制御プレーンへ到達する正当な通信を識別し、それ以外を破棄またはレート制限する考え方を整理しています。ここでも、制御の目的は単なるポート遮断ではなく、装置自身が処理すべき通信の条件を定義することです。

東西通信は境界ファイアウォールを通らない

同一データセンター内、同一 VPC 内、同一クラスター内の通信は、組織の境界ファイアウォールを経由しない場合があります。侵入後の横展開を制限するには、ワークロード間の通信を実際に観測できる地点で制御しなければなりません。

内部セグメンテーションファイアウォール、分散ファイアウォール、クラウドのセキュリティグループ、ホストファイアウォール、Kubernetes NetworkPolicy などは、この役割を担います。

Kubernetes NetworkPolicy は、Pod 間および Pod と外部の間の L3/L4 通信を制御します。ただし、実際に機能させるには NetworkPolicy を実装するネットワークプラグインが必要です。にもあるとおり、ポリシーを定義しただけで、利用中のネットワーク実装が対応していなければ制御は行われません。

コンテナ環境では IP アドレスが動的に変化するため、固定アドレスだけに依存したルールは構成変更に追従しにくくなります。Namespace、Pod ラベル、サービスアカウントなど、ワークロードを表す属性からポリシーを生成し、実際のパケット処理地点へ配布する設計が必要です。

アプリケーション上の不正は、アプリケーションに近い場所で判断する

同じ TCP/443 への通信でも、処理内容は一様ではありません。

• 静的ファイルの取得
• 認証処理
• 検索 API の実行
• 大規模な集計処理
• 管理 API による設定変更
• ファイルのアップロード

境界ファイアウォールから見れば、これらは同じ宛先、同じプロトコル、同じポートへの接続です。しかし、必要な権限、許容する通信量、サーバー側で消費する資源は大きく異なります。

HTTP の形式や既知の攻撃パターンは WAF で検査できます。API 単位の認証、クォータ、リクエストサイズ、レート制限は API ゲートウェイで実施できます。業務データに対する権限や、処理内容に応じた制限はアプリケーションでなければ判断できません。

ただし、アプリケーションで拒否できるからといって、上流の制御が不要になるわけではありません。アプリケーションがリクエストを受信した時点で、TLS 終端、接続管理、パース、認証、ログ記録などの処理はすでに発生しています。大量通信による回線や接続テーブルの枯渇は、アプリケーション上のレート制限では防げません。

公開 API では、異なる条件を異なる地点で処理する

公開 API を例にすると、破棄条件は次のように分担できます。

実施点	主な破棄・制限条件	保護対象
ISP、DDoS 対策基盤	容量型攻撃、明白な攻撃トラフィック	インターネット回線
境界ルーター	不正な送信元、異常なフラグメント、制御プレーン向け通信	ルーター、下流装置
境界ファイアウォール	未公開宛先、未許可ポート、状態不整合	ネットワーク境界、接続テーブル
ロードバランサー	接続数、TLS 条件、バックエンド状態	バックエンド接続、サーバー群
WAF、API ゲートウェイ	HTTP 形式、API 単位のレート、トークン、要求サイズ	Web/API 処理基盤
アプリケーション	認可、業務条件、データ整合性、処理コスト	業務機能、データ

ここで、すべての地点に同じルールを複製する必要はありません。各地点には、その地点でしか判断できない条件と、その地点までに保護しなければならない資源があります。

多層防御は、同じ ACL を重ねることではない

多層防御を「同じ条件を複数の装置へ設定すること」と解釈すると、変更時の不整合が生じやすくなります。ある装置だけ例外設定が残る、IPv4 だけ更新されて IPv6 が更新されない、障害調査時にどこで破棄されたのか分からない、といった問題につながります。

複数の制御点を使用する場合は、条件ごとに主たる実施点を決めます。

破棄条件	主たる実施点	補完する実施点
端末による送信元アドレス詐称	アクセスネットワーク	L3 ゲートウェイ、境界ルーター
インターネットからの未許可接続	境界ファイアウォール	ホストファイアウォール
内部ワークロード間の不要通信	分散ファイアウォール、NetworkPolicy	ホストファイアウォール
ルーター制御プレーンへの過剰通信	ルーター自身	上流ルーター
HTTP リクエストの異常	WAF、API ゲートウェイ	アプリケーション
業務権限の不足	アプリケーション	API ゲートウェイ
回線容量を超える攻撃	ISP、DDoS 対策基盤	境界ルーター

補完する実施点は、主たる制御が失敗した場合の安全策として機能します。ただし、どの装置が最終的な責任を持つのか、どのログを一次情報とするのかを決めておかなければなりません。

ゼロトラストでもネットワーク制御は残る

ゼロトラストでは、ネットワーク上の位置だけを信頼の根拠とせず、アクセス対象となる資源、主体、端末状態、認証結果などに基づいて判断します。NIST SP 800-207 も、ネットワークセグメントではなく資源を保護対象の中心に置いています。

これは、境界ファイアウォールやネットワーク上の破棄条件を廃止する考え方ではありません。送信元アドレスの詐称、未使用ポートへの接続、状態不整合パケット、ルーター制御プレーンへの攻撃、容量型 DDoS などは、ユーザー認証より前に処理すべき問題です。

ネットワーク制御は、通信として成立しないものや、資源へ到達させる必要のないものを排除します。その上で、ID、端末状態、ワークロード属性、業務権限による判断を、対象資源に近い地点で追加します。

つまり、ゼロトラストによって制御点が消えるのではなく、境界だけに依存していた制御点が、資源の近くへ分散します。

配置設計で確認すべき事項

破棄条件を設計したら、次の順序で実施点を検討します。

1. 正常な通信の条件を定義します。
2. 条件から外れた通信によって、どの資源が影響を受けるかを特定します。
3. その資源が消費される前に存在する制御点を列挙します。
4. 各制御点で利用できる判断材料を確認します。
5. 十分な精度で判断できる、最も上流の地点を主たる実施点とします。
6. 主たる制御を迂回する経路と、障害時の挙動を確認します。
7. 補完する制御点と、ログの責任範囲を決めます。
8. IPv4 と IPv6 の両方について、同じ制御経路が成立するかを確認します。

特に見落としやすいのは迂回経路です。管理ネットワーク、バックアップ回線、クラウド事業者の内部経路、ロードバランサーからの直接接続、同一セグメント内通信などが、想定した制御点を通過しないことがあります。

まとめ

ファイアウォール設計では、すべての破棄条件を境界へ集めるのではなく、条件を判断でき、かつ保護対象となる資源が消費される前の地点へ配置する必要があります。

送信元アドレスの割り当てはアクセスネットワークが詳しく把握できます。経路とプレフィックスの整合性はルーターが判断できます。ゾーン間の通信方向と接続状態は境界ファイアウォールが扱えます。HTTP や API の意味はプロキシやアプリケーションに近い地点でなければ判断できません。回線容量を超える攻撃は、組織の設備へ到達する前に処理する必要があります。

設計として一貫させるべきなのは、制御装置の配置ではなく、正常な通信の条件と破棄する理由です。そのポリシーを、判断材料と保護対象に応じて複数の実施点へ割り当てます。

境界ファイアウォールへ何でも背負わせないことは、防御を弱めることではありません。それぞれの破棄条件を、最も効果的に機能する場所へ配置することです。

参考資料

• RFC 7513 – Source Address Validation Improvement Framework
• RFC 5635 – Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding
• RFC 6192 – Protecting the Router Control Plane
• Kubernetes Documentation – Network Policies
• NIST SP 800-207 – Zero Trust Architecture