抜け穴はないか？ファイアウォールのルール管理におけるベストプラクティス
ネットワークの複雑化に伴い、ファイアウォールのルールにもかなりの調整が必要になっている。ルールを適切に管理するための手段と技術を紹介する。
会社のファイアウォールのルールを変更したせいで、ネットワークの防御に抜け穴ができてしまったのではないかと怪しんでいるネットワーク管理者は、どれくらいいるだろうか。
現代のネットワークは複雑になり、周辺環境やアプリケーション、ユーザーの全体像を常に把握しておくことが難しくなった。IT担当者が変わったり新しいアプリケーションが加わったり、ユーザーが入れ替わったり職務の変更があったりといった変更に伴って、ファイアウォールのルールにかなりの調整が必要になることもあり、パーミッションにも混乱が生じやすい。本稿ではファイアウォールのルール変更を適切に行うための手段と技術を紹介する。
まず初めに、わたしが考えるファイアウォールのルール管理に対する最善のアプローチは、以下の3点が鍵となる。
- ルールの基本は常にシンプルに
- すべてのルールを文書に残す
- 変更管理ポリシーの導入
ルールの基本は常にシンプルに
ファイアウォールのマニュアルは難解になりがちだが、覚えておくべき要点は、フィルタが例えば「ポート80をブロックする」といった特定の値についての動作を定めるものであるのに対し、ルールは「もしポートが80ならば拒否する」といった条件文を適用するものであるということだ。ファイアウォールをどう設定するかは、その組織のセキュリティポリシーで確立されたビジネスルールに直接起因するものでなければならない。ファイアウォール設定のアプローチがこの指針に沿うことを目標にすれば、ルールとフィルタはおのずと決まってくる。
フィルタとルールを組み合わせる最善の方法は、まず基本的な「拒否」フィルタを作成し、その後、特定のケースを処理するためのフィルタやルールを作成することだ。例えば「全ポートをブロックし、ポート80を許可する」といった具合になる。このファイアウォールのルール管理のアプローチでは、必ずしもルールの重複を避けられるとは限らないが、「許可」のルールの優先度を常に「拒否」フィルタよりも低く設定しておけば、ルールセット全体としてのセキュリティは高まる。
文書化と変更管理ポリシー
また、全ルールについてコメントと詳しい記録を残しておけば、いざ変更を加える段になったときにそれぞれの意図が理解しやすくなる。変更管理プロセスにのっとった変更のみを行うことも大切だ。変更管理プロセスは公式かつ統制の取れたアプローチで、変更した設定が確実にテストされ、意図しない結果（例えばセキュアでない設定になるなど）が発生した場合にやり直しができることを保証するものだ。さらに、ルールやポリシーのグループには意味のある名称を付け、作成した日付と管理者のイニシャルをファイル名に含めるようにする。
1つのファイアウォール技術だけを当てにするのは不安だという管理者もいる。実際、1つで何もかも極めてうまくやってくれるファイアウォールなど存在しない。多くの場合、ネットワークの複数の侵入経路に対応し、それぞれ違った多様なビジネスアプリケーションを守ってくれるファイアウォールが複数必要になる。ただしネットワーク上にファイアウォールが増えるほど、ネットワーク全体の統制と一貫性を保つのは難しくなる。
このような場合に最善の戦略は、ネットワークトラフィックの流れの中で、それぞれにはっきりした目的と立場を持たせることだ。例えばデータベースの守り専用のファイアウォールなら、ルールとフィルタはデータベースに出入りするトラフィックの制御だけを念頭に置けばよく、ネットワーク上のほかの端末のセキュリティを気に掛ける必要はない。これでルールセットがよりシンプルになり、管理しやすくなる。
ファイアウォールのルール管理を自動化できる製品
幸いなことに、今ではファイアウォール管理を自動化し、組織全体で一貫性と統制を保ったファイアウォールの設定維持を容易にする技術がある。例えばCisco Systemsのファイアウォールのみを使ったネットワークなら、「CiscoWorks Management Center for PIX」を使って複数のPIXファイアウォールの設定管理ができる。McAfeeの「Firewall Enterprise Control Center」では、中央インタフェースを提供してMcAfee Firewallアプライアンスを一元管理しやすくしている。
Juniper Networksのファイアウォール管理ツール「Network and Security Manager」（NSM）でわたしが気に入っているのは、ローカルの管理者が削除したり無効にしたりできないJuniper製の全ファイアウォールに「開始」「終了」のルールを作成できる機能だ。各社製品の混在環境で一貫したルールを導入するなら、ベンダー中立のアプリケーション「Firewall Builder」によるファイアウォールのルール設定・管理を試してもいい。同製品のGUIで作成した同じポリシーを基に、サポート対象のどんなファイアウォールプラットフォーム用にでも設定ファイルを作成できる（Firewall BuilderはGNU General Public License：GPLと商用ライセンスの両方を通じて提供されている）。
Algosecの「Firewall Analyzer」は、ファイアウォールのルール管理に対して違うアプローチを取っている。同製品は複数のファイアウォールベンダーと装置にクエリをかけ、そもそも変更が必要なのかどうかをチェックする。ルールやポリシーが既に存在しているかもしれないからだ。さらに、提案した変更にまつわる業務上、セキュリティ上の影響についても評価してくれる。RedSeal Systemsの「Security Risk Manager」も同様に、ファイアウォールとルータの設定を、業界およびセキュリティ上のべストプラクティスに照らし合わせて分析し、変更を提案してくれる。
どの製品を使う場合でも、ファイアウォールのポリシーを絶え間なく変更していると、パフォーマンスに影響が出るということは覚えておきたい。調整にはコストが掛かり、計画したりネットワークのほかの部分と統制を取ったりする時間もかかる。最後に、定期的にファイアウォールのルールを監査して、自分が「その都度導入した」設定が、「想定通りの」設定からそれていないかどうかチェックすることをお勧めする。サービスやシステムがネットワークから削除されると、孤立したり、使われていないルールが発生することもあれば、別のシステム変更にルールが追い付かなくなることもあるのだ。
本稿筆者のマイケル・コッブ氏は、データセキュリティおよび解析に関するトレーニングやサポートを提供するITコンサルティング会社、Cobweb Applicationsの創業者兼マネージングディレクター。CISSP-ISSAP（公認情報システムセキュリティプロフェッショナル―情報システムセキュリティアーキテクチャプロフェッショナル）の資格を持つ。共著書として『IIS Security』があり、主要なIT出版物に多くの技術記事を寄稿している。
この記事を読んだ人にお薦めのホワイトペーパー
この記事を読んだ人にお薦めの関連記事
ITmediaはアイティメディア株式会社の登録商標です。