ファイアウォールルールは設計から生成する – 定数、検証、変更管理

ファイアウォールのルールセットは、設計そのものではありません。設計を特定の製品や OS が解釈できる形式へ変換した結果です。

ところが実際の運用では、装置に投入されている設定が唯一の正本となり、行番号やアドレスを直接編集する作業が繰り返されがちです。この状態では、ルールが存在する理由、保護対象、許可した通信の責任者、例外の有効期限といった設計情報が失われます。

ルール数が少ないうちは、設定を読めば意図を推測できるかもしれません。しかし、複数拠点、冗長構成、クラウド、IPv4／IPv6、内部セグメンテーションまで対象が広がると、人間が製品固有の設定を直接編集する運用には限界があります。

必要なのは、設計情報を正本として管理し、そこから各実施点のルールを生成する構造です。

この記事は「ポート番号から考えないファイアウォール設計」シリーズの第 7 回です。ここでは、第 1〜6 回で整理した破棄条件を、設計ポリシー、論理ルール、装置設定、検証、変更管理へ落とし込む方法を扱います。

設計、論理ルール、装置設定を分離する

ファイアウォールポリシーは、少なくとも次の三つの層に分けて管理します。

設計ポリシーでは、「インターネットから公開 DNS への DNS 問い合わせを許可する」「管理ネットワーク以外から管理インターフェースへ接続させない」といった意図を記述します。

論理ルールでは、その意図を通信条件へ落とし込みます。ここでは、製品固有のインターフェース名やコマンド構文には依存させません。

装置設定は、論理ルールを実際の機器へ適用するための生成物です。生成物を直接編集すると、次回の生成時に変更が失われるだけでなく、正本との不一致が発生します。したがって、原則として装置設定ではなく、上位の論理ルールを変更します。

IP アドレスやポート番号をルールへ直接埋め込まない

ルール内に IP アドレスやポート番号を直接記述すると、構成変更の影響範囲を把握しにくくなります。

たとえば、複数のルールに 192.0.2.10 が書かれている場合、そのアドレスが公開 Web サービスなのか、監視装置なのか、NAT 変換後の仮想アドレスなのかは、数値だけでは判断できません。アドレス変更時には、すべての出現箇所を調査する必要があります。

これを避けるため、設計上の意味を持つ名前と、現在の実値を分離します。

address_objects:
  public_web_vip:
    ipv4:
      - 192.0.2.10/32
    ipv6:
      - 2001:db8:1200::10/128
    owner: web-platform
    purpose: public-web-entrypoint

service_objects:
  https:
    protocol: tcp
    destination_ports:
      - 443

network_objects:
  management_networks:
    ipv4:
      - 198.51.100.0/25
    ipv6:
      - 2001:db8:2000:100::/64

ルール側では、実際のアドレスではなく public_web_vip や management_networks を参照します。

この構造では、アドレス変更とポリシー変更を区別できます。公開 Web サービスのアドレスを変更しても、「インターネットから公開 Web サービスへの HTTPS を許可する」という設計意図は変わりません。

ただし、名前を付ければよいわけではありません。group1、network-a、temporary2のような名前では、数値を直接書く場合と同様に意味が失われます。オブジェクト名は、配置ではなく役割を表す必要があります。

論理ルールには理由と責任者を含める

一般的なファイアウォール設定には、送信元、宛先、プロトコル、ポート、処理が記述されます。しかし変更管理に必要な情報は、それだけではありません。

少なくとも、次の項目を論理ルールとして管理します。

論理ルールは、たとえば次のように表現できます。

policies:
  - id: FW-PUBLIC-HTTPS-001
    source: internet
    destination: public_web_vip
    service: https
    connection_state:
      - new
      - established
    action: allow
    owner: web-platform
    reason: public-web-service
    expires_at: null
    logging:
      accept: sampled
      deny: not_applicable

重要なのは YAML を使うことではありません。JSON、データベース、専用のポリシー管理システムでも構いません。必要なのは、装置固有の構文とは別に、機械的に検証できる論理モデルを持つことです。

ルールの順序は生成側で決める

多くのファイアウォールでは、ルールの評価順序が結果を左右します。例外ルールを一般ルールより前に置く必要がある製品もあれば、複数の評価段階や暗黙ルールを持つ製品もあります。NAT とフィルタリングの評価順序も実装によって異なります。

この違いを設計ポリシーへ持ち込むと、設計が製品の内部動作に依存します。そのため、論理モデルでは通信条件と優先関係を記述し、実際の行番号やチェイン構成は生成処理で決定します。

生成処理は、少なくとも次の差異を吸収します。

• アドレスオブジェクトとサービスオブジェクトの構文
• 最初に一致したルールを採用するかどうか
• ステートフル検査の表現
• IPv4 と IPv6 のルール配置
• NAT 前後のどちらのアドレスを評価するか
• インターフェースとゾーンの対応
• 破棄と拒否の実装
• ログ取得方法とレート制限
• 暗黙ルールの有無
• 冗長装置への適用単位

製品を変更する場合も、設計ポリシーと論理ルールを維持できれば、新しい装置向けの生成処理を追加できます。製品固有設定を正本としている場合は、既存設定から設計意図を逆算しなければなりません。

生成できることと、正しいことは別である

構文上有効な設定を生成できても、そのルールが設計として正しいとは限りません。生成前後に、複数の段階で検証する必要があります。

構造の検証

構造検証では、論理モデルを機械的に処理できるかを確認します。

• 必須項目が存在するか
• オブジェクト参照が解決できるか
• IP アドレスやプレフィックスの形式が正しいか
• ポート番号の範囲が正しいか
• ルール ID が重複していないか
• 定義されていないゾーンを参照していないか
• 有効期限の形式が正しいか

ポリシーの検証

ポリシー検証では、構文としては有効でも、設計原則に反するルールを検出します。

anyを含むルールを一律に禁止する必要はありません。インターネット向け通信の送信元や、最終破棄ルールの条件として必要な場合があります。重要なのは、広い条件を例外として検出し、その理由をレビューできることです。

通信結果の検証

最終的には、特定の通信が許可されるか、破棄されるかをテストします。テスト対象は設定行ではなく、設計上の通信要件です。

test_cases:
  - name: internet_to_public_https
    source: internet
    destination: public_web_vip
    protocol: tcp
    destination_port: 443
    expected: allow

  - name: internet_to_public_ssh
    source: internet
    destination: public_web_vip
    protocol: tcp
    destination_port: 22
    expected: deny

  - name: user_network_to_management_ssh
    source: user_networks
    destination: network_devices
    protocol: tcp
    destination_port: 22
    expected: deny

  - name: management_network_to_management_ssh
    source: management_networks
    destination: network_devices
    protocol: tcp
    destination_port: 22
    expected: allow

このテストは、生成処理を変更した場合、ファイアウォール製品を更新した場合、アドレスオブジェクトを変更した場合にも再実行します。通信要件をテストとして保持することで、変更対象とは無関係に見える既存通信への影響も検出できます。

IPv4 と IPv6 は共通の意図から別々に検証する

IPv4 と IPv6 で同じサービスを提供する場合、論理上の許可方針は共通化できます。ただし、生成されるルールを単純に同一にしてよいとは限りません。

IPv6 では、Neighbor Discovery、Path MTU Discovery、Router Advertisement などに ICMPv6 が使用されます。IPv4 のルールを機械的に IPv6 へ置き換えただけでは、必要な制御通信を破棄する可能性があります。反対に、IPv6 の経路や公開アドレスが存在しているにもかかわらず、IPv4 側にしか破棄ルールが生成されていないこともあります。

したがって、共通化するのはサービスの意図であり、検証結果ではありません。

IPv4 側のテストが成功したことは、IPv6 側の安全性を証明しません。論理ポリシーを共有していても、アドレスファミリーごとの生成物と通信結果を独立して確認します。

変更時には二種類の差分を見る

自動生成された設定を適用する場合、レビューすべき差分は一つではありません。

第一の差分は、論理ポリシーの差分です。誰が、どの通信要件を、なぜ変更したのかを確認します。

第二の差分は、生成された装置設定の差分です。生成処理の結果として、実際のルールセットがどのように変化するかを確認します。

論理上はアドレスオブジェクト一つの変更であっても、そのオブジェクトを参照する多数のルールへ影響する場合があります。逆に、生成された設定では多数の行が変更されていても、論理上は一つのサービス追加だけという場合もあります。

両方の差分を確認しなければ、意図と実装のどちらかを見落とします。

適用はトランザクションとして扱う

設定の生成に成功した後も、適用時の失敗を考慮する必要があります。

冗長ファイアウォールの片系だけに設定が反映される、複数拠点の一部で適用に失敗する、オブジェクトは追加されたが参照ルールが追加されない、といった部分適用は、単純な設定ミスより調査が難しくなります。

適用処理では、次の状態を区別します。

1. 生成済み
2. 構文検証済み
3. レビュー済み
4. 適用準備済み
5. 適用中
6. 適用完了
7. 通信検証済み
8. 監視確認済み

可能であれば、装置のコミット機能、候補設定、設定チェックポイントなどを利用します。複数の実施点へ展開する場合は、すべてを無条件に同時変更するのではなく、影響範囲を限定した段階適用も検討します。

ロールバックでは、単に以前の設定ファイルを投入できるだけでは不十分です。NAT、セッション同期、ルーティング、DNS、ロードバランサーなどの関連変更と整合する状態へ戻せる必要があります。

緊急変更を自動化の外に放置しない

障害対応やインシデント対応では、正規の生成経路を待たずに装置へ直接ルールを追加しなければならない場合があります。緊急変更そのものを禁止すると、必要な対応が遅れます。

問題は、緊急変更が装置上に残り、正本へ反映されないことです。次回の自動生成で消失する場合もあれば、装置上だけに存在し続ける場合もあります。

そのため、直接変更には次の条件を設けます。

• 変更者と承認者を記録します。
• 対象装置、ルール、目的を記録します。
• 原則として有効期限を設定します。
• 監視対象と解除条件を決めます。
• 対応後に論理ポリシーへ反映するか、装置から削除します。
• 正本と実機の差分を確認します。

緊急変更を例外経路として正式に定義しておけば、自動化と緊急対応を両立できます。

実機との差分を継続的に検出する

正本から設定を生成していても、実機が常に生成結果と一致しているとは限りません。直接変更、適用失敗、装置交換、ソフトウェア更新、クラウド側の変更などによって差分が発生します。

この差分は構成ドリフトとして検出します。

差分を検出した場合、実機側を無条件に上書きするのではなく、原因を確認します。正本への反映漏れであれば正本を更新し、未承認の変更であれば実機を期待状態へ戻します。

また、実機設定だけでなく、実際の通信結果も確認する必要があります。装置の不具合、経路変更、クラスタ状態、別の制御点の影響によって、設定が一致していても期待した通信結果にならない場合があるためです。

ログとルール ID を対応させる

装置上の行番号は、ルールの追加や生成順序の変更によって変化します。行番号だけをログへ記録しても、後からどの設計意図に基づく処理だったのか追跡できません。

生成時には、論理ルールの ID を装置上のルール名、コメント、ログ識別子などへ埋め込みます。これにより、ログから次の情報を逆引きできます。

• ルールの設計理由
• 通信要件の所有者
• 変更履歴
• 有効期限
• 関連するテストケース
• 配置されている他の制御点

ヒット数がゼロのルールは見直し候補になりますが、それだけで不要とは判断できません。災害復旧、フェイルオーバー、証明書更新、保守接続など、平常時には使用されない通信もあります。

削除判断では、観測期間、サービスの運用周期、代替経路、所有者の確認、テスト環境での再現を組み合わせます。

ルールのライフサイクルを管理する

ファイアウォールルールには、作成だけでなく、変更、停止、削除までのライフサイクルがあります。

NIST SP 800-41 Revision 1 でも、ファイアウォールポリシーとルールセットについて、正式な変更管理と定期的なレビューを行う必要性が示されています。

自動生成は、この変更管理を省略するための仕組みではありません。人間が確認すべき対象を、装置固有の大量の設定行から、設計上の意味を持つ差分へ移すための仕組みです。

まとめ

ファイアウォールルールを直接編集する運用では、設定と設計が一体化します。その結果、アドレス変更がポリシー変更として扱われ、製品固有の評価順序が設計へ入り込み、ルールが存在する理由や責任者が失われます。

これを避けるには、正常な通信の条件を設計ポリシーとして記述し、製品に依存しない論理ルールへ変換し、そこから各実施点の設定を生成します。IP アドレス、ポート、ゾーン、サービスは意味を持つオブジェクトとして管理し、生成物には安定したルール ID を引き継ぎます。

さらに、構文検証だけでなく、過剰許可、ルール競合、IPv4／IPv6 の不整合、配置の誤り、実際の通信結果まで検証します。適用後には実機との差分を監視し、緊急変更も最終的には正本へ収束させます。

ファイアウォールの品質は、設定行を正確に書けるかどうかだけでは決まりません。設計意図を失わず、変更の影響を事前に評価し、期待した通信結果が維持されていることを継続的に確認できるかどうかで決まります。

参考資料

• NIST SP 800-41 Revision 1 – Guidelines on Firewalls and Firewall Policy

関連記事

ファイアウォールは構文ではなく、通信制御の抽象化で理解する 送信元 IP だけでは不正と判断できない – 経路とトポロジーから破棄条件を考える ファイアウォール設計はポート番号から始めない – 正常な通信の条件から破棄対象を逆算する ICMP は許可か拒否かでは設計できない – IPv4 / IPv6 制御通信の成立条件 正常なパケットは、どこから攻撃になるのか – 通信量と資源から考えるファイアウォール設計 開いているポートでも通してはいけない – 接続状態とパケット構造の検証 すべてを境界ファイアウォールで防がない – 破棄条件を配置する場所