(57)【特許請求の範囲】
【請求項１】
ネットワーク（１００）内の少なくとも１つのゲートウェイ（１２０、１５０）を解析する方法であって、当該少なくとも１つのゲートウェイ（１２０、１５０）が、複数のルールを含むパケットフィルタ処理構成ファイル（１２５、１５５）を有し、当該ネットワークが、複数のアドレスを有するような、ネットワーク内のゲートウェイを解析する方法において、当該方法が、
（ａ）  当該ネットワークを該パケットフィルタ処理構成ファイル（１２５、１５５）に基づいてモデル化するゲートウェイゾーン・グラフを生成するステップであって、当該ゲートウェイゾーン・グラフが、当該少なくとも１つのゲートウェイ（１２０、１５０）に対応する少なくとも１つのゲートウェイノード（３１２、３１５）と、少なくとも２つのゾーンノード（３１１、３１３、３１４、３１６）とを有し、当該少なくとも１つのゲートウェイが、パケットフィルタ処理マシンであり、当該ゾーンノードが各々が、当該少なくとも１つのゲートウェイによって形成された当該アドレスの区分された収集群に対応するような、生成するステップ；と、
（ｂ）  １つ以上の与えられたサービスが少なくとも１つのソースアドレスと少なくとも１つの宛先アドレスとの間で許されるかどうかを問い合わせる質問を受け取るステップ；と、
（ｃ）  当該少なくとも１つのソースアドレスと当該少なくとも１つの宛先アドレスとの間で遭遇する当該ゲートウェイゾーン・グラフ内の各ゲートウェイノードに連関する各ルールと対照して当該質問を評価するステップ；と、からなることを特徴とする、ネットワーク内のゲートウェイ解析方法。
【請求項２】
該ルールが、ルールベースのオブジェクトとして表示されることを特徴とする請求項１の方法。
【請求項３】
該ゲートウェイゾーン・グラフが、ネットワークトポロジーファイル（２１０）から導出されることを特徴とする請求項１の方法。
【請求項４】
該質問が、該サービス、ソースアドレス、又は宛先アドレスの少なくとも１つに対するワイルドカードを含むことを特徴とする請求項１の方法。
【請求項５】
該方法が更に、
（ｄ１）  該１つ以上の与えられたサービスのうち、少なくとも１つのソースアドレスと少なくとも１つの宛先アドレスとの間で許されるサービス部分を定めるステップ；からなることを特徴とする請求項１の方法。
【請求項６】
該方法が更に、
（ｄ２）  該パケットフィルタ処理構成ファイルを、該評価するステップの間に処理される論理ルールのテーブルに変形するステップ；からなることを特徴とする請求項１の方法。
【請求項７】
該質問が、ソースホストグループ、宛先ホストグループ、及びサービスホストグループからなることを特徴とする請求項１の方法。
【請求項８】
該質問が、該ネットワーク内にパケットが挿入されるべき位置であってソースアドレスとは異なる位置、を指定することを特徴とする請求項１の方法。
【請求項９】
複数のゲートウェイデバイス（１２０、１５０）を有するネットワーク（１００）をモデル化する、ネットワークモデル化方法であって、
（ａａ）  当該ネットワーク内の当該ゲートウェイデバイスであってパケットフィルタ処理ルールベースを有する各ゲートウェイデバイス、及び当該ゲートウェイデバイスによって定義される当該ネットワーク内の各ゾーン（１１０、１３０、１４０、１６０）を特定するステップ；と、
（ｂｂ）  該パケットフィルタ処理ルールベースに基づいて当該ネットワークをモデル化するゲートウェイゾーン・グラフを生成するステップであって、当該ゲートウェイゾーン・グラフが、当該ゲートウェイデバイス（１２０、１５０）の各々に対応するゲートウェイノード（３１２、３１５）と当該ゾーンの各々に対応するゾーンノード（３１１、３１３、３１４、３１６）とを有するような、生成するステップ；とからなることを特徴とする、ネットワークモデル化方法。
【請求項１０】
該方法が更に、
（ｃｃ）  該パケットフィルタ処理ルールベースを、論理ルールのテーブルに変形するステップ；からなることを特徴とする請求項９の方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、概略的にはファイアウォールに関し、詳しくはファイアウォールのセキュリティ・ポリシー（手段）を解析するための方法及び装置に関する。
【０００２】
【従来の技術】
ネットワーク・ファイアウォールはインターネットに接続されたネットワークのための重要な保護手段を提供する。ファイアウォールは、箱から取り出して直ぐに起動できるような単純なアプリケーションソフトウエアではない。ファイアウォールは、与えられた会社又は実体（エンティティ）の特定のニーズのための重要なセキュリティ・ポリシーを実現するように構成し管理する必要がある。
【０００３】
ファイアウォールのセキュリティに影響を与える最も重要な因子はファイアウォール構成であるといわれてきた。ファイアウォールは感銘を与えるような技術的進歩であり続けてはいるが、ファイアウォールの構成及び管理における進歩は今まで、もしあるにしてもあまりなかった。
【０００４】
ファイアウォールは、パケットをフィルタ処理して、イントラネットのような私有コーポレート（法人）ネットワークをインターネットのような公衆ネットワークから隔離する、ネットワーク・ゲートウェイである。今日のファイアウォールの大部分はルールベース又はファイアウォール構成ファイルによって構成される。
【０００５】
小さな会社のＬＡＮ（構内通信網）のような単一、同質のイントラネットを守るファイアウォールの場合には、単一のルールベースがファイアウォールに対して、入って来る（到来）セッション（パケット）のどれの通過を許すべきか、そしてどれを阻止すべきかを指示する。同様にルールベースが、出て行く（外行）セッション（パケット）のどれの通過を許すべきかを指示する。ファイアウォールの業務管理担当者（アドミニストレータ）はこの低レベルのルールベースを用いて高レベルのコーポレート・セキュリティ・ポリシーを実現する必要がある。
【０００６】
ファイアウォールの構成インタフェースは一般に、セキュリティ業務管理担当者が種々のホストグループ（ＩＰアドレスの範囲（レンジ））及びサービスグループ（プロトコルと、エンドポイントを形成するホストにおける対応するポート番号とのグループ）を定義することを可能にする。単一のルールには一般に、ソース（発信源）、宛先、サービスグループ及び適切なアクションが含まれる。ソース及び宛先はホストグループであり、アクションは概して、対応するセッションのパケットを通過させるか又は脱落させるかのいずれかの動作の表示である。
【０００７】
多くのファイアウォールにおいてはルールベースは、「順序」に対して感度がある（順序に基づいて動作する）。言い替えれば、ファイアウォールは、ルールベース中の第１のルールが新しいセッションに適用されるかどうかを点検する。もし第１のルールが適用される場合、パケットは第１のルールによって指定されるアクションに基づいて通過又は脱落させられる。もし第１のルールが適用されない場合、ファイアウォールは、ルールベース中の第２のルールが適用されるかどうかを点検する。以下、適用されるルールが見出されるまで同様に点検が行われる。
【０００８】
この方式は、ルールベース内の冗長ルールが原因で誤った構成に至ることがしばしばあり、望むセキュリティ・ポリシーは、ルールの一部についてその順序を変更した後でなければ実現されない。
【０００９】
ファイアウォールを業務管理するときの問題は、複数のファイアウォールを用いるより大きな会社の場合には更に悪くなる。ファイアウォールが多数あると、１つの会社のイントラネットが多数のゾーンに分割され、セキュリティ・ポリシーは一般に、異なるゾーンを相互に接続する多数のゲートウェイ上に位置する多数のルールベースによって実現される。
【００１０】
したがって、セキュリティ・ホールを生じさせることのないように、種々のルールベース間の相互動作（インタープレー）を注意深く点検する必要がある。イントラネットがより複雑になるにしたがって、ルールベースの設計及び管理の複雑性が増大する。
【００１１】
今日、中ぐらいの大きさのコーポレート・イントラネットでも多数のファイアウォール及びルータを有し、これらのファイアウォール及びルータは全て、全体的（大域的）なコーポレート・セキュリティ・ポリシーの種々の態様を実施させるのに用いられる。これらのデバイスを一致して作動するように構成することは困難であり、もしデバイスが異なる納入業者（ベンダ）によって製造されている場合には特にそうである。例えば新しいセキュリティ業務管理担当者が業務を引き継ぐ場合に現存の構成をテスト又は逆解析（リバースエンジニアリング）することさえも難しい。
【００１２】
ファイアウォール構成ファイルは低レベルの形式で書かれ、その可読性は、アッセンブリコードに匹敵し、大域的なセキュリティ・ポリシーが、関与する全てのファイアウォールにわたって拡張される。
【００１３】
現在、ファイアウォール業務管理担当者は、コーポレート環境内の種々のクラスのマシン又はサービスに適用可能なセキュリティ許可を定める簡単な方法を持ちあわせていない。したがって、業務管理担当者が１つ以上の与えられたサービスが１つ以上の与えられたマシン間で許されるかどうか、のようなコーポレート・セキュリティ・ポリシーに関するルーチン質問に答えることは、不可能ではないにしても困難である。
【００１４】
コーポレート・セキュリティ・ポリシーの評価がなぜ困難であり得るのかについては、いくつかの理由がある。第１に、パケットはソースと宛先との間に、それぞれいくつかのフィルタ処理デバイスを通る多数の通信路（パス）を有する。質問に答えるには、業務管理担当者は、これらの全てについてルールを点検することが必要になる。
【００１５】
加えて、一般的なベンダ構成ツールは一度に１つのデバイスしか扱わず、そのため大域的にみて挙動が一貫しないことになる。もし異なるベンダによって製造されたパケットフィルタ処理デバイスが関与する場合、状況は直ぐに悪化する。
【００１６】
更に、単一のパケット処理デバイスの単一のインタフェースにおいてポリシーを理解することでさえも問題がある。前に述べたように、ファイアウォール構成言語は、わかりにくく、非常に低レベルであり、ルールの順序に有感であり、そしてベンダに特有な性質を有する度合いが高い。
【００１７】
現在、バルネラビリティ（外部からの攻撃に対する弱さ）テストツールは、市販で入手可能なものがいくつかある。その一例（商品名サタン：記述が文献（例えば、M. Freiss, Protecting Networks with SATAN, O'Reilly & Associates, Inc. (1998) ）にある）は、広範に展開されたプロトコル及びオペレーティング・システムにおける既知の欠陥を利用する。これらの欠陥の或るものは適切なファイアウォール・ポリシーによって阻止できる。このようにして、「サタン」ツールを用いてファイアウォール・ポリシーをテストすることができる。
【００１８】
加えて、別のこの種のツール（商品名ネット・ソナー２．０：シスコ・システム社（Cisco Systems Inc. of San Jose, CA）から市販で入手可能）は、コーポレート・イントラネットに接続してネットワークを検査することにより、展開された、ルーティング（定められたルートによる信号配送）・ポリシー及びファイアウォール・ポリシーをテストする。
【００１９】
現在入手可能なバルネラビリティ・テストツールはアクティブ（能動性）である。言い替えれば、これらのツールはネットワーク上でパケットを送信し受信する。このため、これらのツールはいくつかの制約を受ける。もしこれらの制約が克服されれば、これらのバルネラビリティ・テストツールの利用性及び効率は大幅に増大することになる。
【００２０】
例えば、もしイントラネットが大きくて、何千台ものマシンを有する場合、現在のバルネラビリティ・テストツールは、処理が遅い（各１個のＩＰアドレスを可能な各ポートに対してテストする場合）か又は標本統計的（ランダムテストを行う場合）である。すなわち、間違いなくこれらのツールは、インターネット上の可能な各ＩＰをテストすることはできない。
【００２１】
加えて、現在のバルネラビリティ・テストツールは、ファイアウォール構成上の誤りを１種類しか、すなわち「無許可のパケットの通過を許してしまうという誤り」しか捉えることができない。その結果、これらのツールは、第２の種類の誤り、すなわち「許可されたパケットを、意図せずに（うっかり）阻止するという誤り」を捉えない。この第２の種類の誤りは一般に、「ポリシーを展開して、不満が出るのを待つ」戦略によって検出される。これは、ネットワークユーザにとって破壊的であり、重要な業務通信処理が切断されることになる。
【００２２】
アクティブテストは常に、「事後」である。しかし、新しいポリシーが展開された後に問題を検出する手法は、（ａ）危険であり（問題が検出されて安全なポリシーが展開されるまでネットワークが無防備であるため）、（ｂ）コストが掛かり（大きなネットワークにおいてセキュリティ・ポリシーを展開するのは時間が掛かり誤りを生じやすい手法であるため）、そして（ｃ）ユーザにとって破壊的である。
【００２３】
更に、アクティブ・ツールはネットワークトポロジー（接続形態）内のその物理的位置からしかテストできない。アクティブ・ツールがホストの上で動くそのホストに関与しないネットワーク内のパスに特有の問題は、検出されないままになる。
【００２４】
【発明が解決しようとする課題】
したがって、業務管理担当者が大域的ファイアウォール・ポリシーを発見してテストすることのできるファイアウォール解析ツールに対する必要性がある。更に、ネットワークトポロジーを最小の記述しか用いずに、ベンダ特有で低レベルの種々の構成ファイルを直接解析するファイアウォール解析ツールに対する必要性がある。又更に、適切な要約レベルで行われる質疑応答セッションを通してユーザと対話するファイアウォール解析ツールに対する必要性がある。
【００２５】
【課題を解決するための手段】
概略的には、本発明により、ネットワーク環境においてパケットフィルタ処理機能を行う１つ以上のファイアウォール、又は例えばルータのような他のネットワーク・ゲートウェイの動作を解析するための方法及び装置が開示される。個々特定のネットワーク環境に対するセキュリティ・ポリシーは一般に、各ファイアウォールに対する「パケットをフィルタ処理するための構成ファイル」（パケットフィルタ処理構成ファイル）（すなわち、ルールベース）を定義することによって実現される。
【００２６】
パケットフィルタ処理構成ファイルが、或る到来パケット又は外行パケットを通過又は脱落させるように、与えられたファイアウォールに指示する。ユーザの質問を与えられると、ここに開示された本発明による装置、すなわち、ファイアウォール（すなわち、ゲートウェイ）解析ツールが、ネットワーク環境のトポロジーを考慮の上、種々のファイアウォールの挙動をシミュレートして、当初の質問に指定されたサービス又はマシンのどの部分がソースから宛先に到達することになるかを定める。
【００２７】
開示されたファイアウォール解析ツールが、関連するパケットフィルタ処理構成ファイルを収集して読み取りを行い、「対象として暗黙に示された」（黙示の）セキュリティ・ポリシーを内部的表示の形で形成する。加えて、ファイアウォール解析ツールは、グラフデータ構造を利用してネットワークトポロジーを表現する。ゲートウェイゾーン・グラフは、縁部（エッジ）で相互接続されたいくつものノードからなる。各ノードは、ゲートウェイ（ファイアウォール又はルータ）若しくはゲートウェイによって形成されたゾーンに対応する。
【００２８】
概して、本発明においては、与えられたパケットがどの物理的パスに沿っても、もしそれがルート規定（取り決め）によれば許されない場合であっても、移動できるものと仮定する。ゲートウェイゾーン・グラフは、パケットフィルタ処理ルールベースを有する各デバイスに対して、そしてこれらデバイスによって定義される各ゾーンに対して、ノードを有する。ファイアウォール解析ツールは、ネットワーク内の各ルータ及び切換器（スイッチ）について知っている必要がなく、又用いられるルート規定に無関係である。
【００２９】
ネットワーク内でどこへパケットが移動するかを、そしてこれらのパス沿いにどのゲートウェイに遭遇するか、すなわちどのゲートウェイを経由するかをファイアウォール解析ツールが定めることが、ゲートウェイゾーン・グラフにより可能になる。このようにしてソースと宛先との間の各パス沿いに遭遇するゲートウェイゾーン・グラフ内の各ゲートウェイノードについて、ファイアウォール解析ツールが質問オブジェクトを各ルールベースと対照して評価することができる。
【００３０】
本発明の更に別の態様によれば、ファイアウォール解析ツールは、「１つ以上の与えられたサービスが１つ以上の与えられたマシンの間で許されるかどうか」のような単純な質問を受け取って評価するためのグラフィカル・ユーザ・インタフェースを提供する。
【００３１】
本発明においては、与えられたサービスが複数のサービスからなるサービス群（a set of services） である場合、ユーザは質問を統合することが許される（ワイルドカード「可能な全てのサービス」まで）。そして、与えられたマシンは、任意の群数のＩＰアドレス群である（ワイルドカード「可能な全てのアドレス」まで）。
【００３２】
本発明の更に別の態様によれば、ファイアウォール解析ツールはソースのＩＰアドレスを変更することによって模擬の侵入攻撃（アタック）をシミュレートすることができる。ファイアウォール解析ツールは、ネットワーク内でパケットを注入すべき位置として、ソースホストグループの真の位置ではないネットワーク内の位置を、ユーザが指定することを許す。ファイアウォール解析ツールは又、ネットワークアドレス変換（ＮＡＴ）を行うファイアウォールルールを考慮に入れることもできる。
【００３３】
【発明の実施の形態】
図１は、本発明に基づくネットワーク環境の例を示す。図１に示すように、ネットワーク環境１００が、２つのファイアウォール（すなわち、ゲートウェイ）、詳しくは内部ファイアウォール１２０及び外部ファイアウォール１５０、を有する。外部ファイアウォール１２０は、会社の、インターネット１１０のような外部ネットワークとの接続を保護する。外部ファイアウォール１２０の後にはサーバゾーン１３０がある。サーバゾーン１３０は、しばしば「非武装地帯」（ＤＭＺ）にたとえられ、会社の外部可視（外部に見える）サーバを有する。
【００３４】
本実施例においては、サーバゾーン１３０内の外部可視サーバは、電子メール（ｓｍｔｐ）、ハイパーテキストトランスファ・プロトコル（ｈｔｔｐ）ファイルトランスファ（ｗｅｂ）及びファイルトランスファ・プロトコル（ｆｔｐ）ファイルトランスファサービスを含むマルチ・サーバ１３８と、ドメインネームシステム（ｄｎｓ）サーバ１３４とを有する。
【００３５】
サーバゾーン１３０の後には、イントラネットのような、会社の私有又は内部ネットワークを保護する内部ファイアウォール１５０がある。内部ファイアウォール１５０は３つのインタフェースを有する。第１のインタフェースはサーバゾーン１３０に対するものである。第２のインタフェースは内部ファイアウォール１５０をコーポレートネットワークゾーン１６０に接続し、第３のインタフェースはファイアウォール１５０をファイアウォール業務管理ゾーン１４０に接続する。
【００３６】
ファイアウォール業務管理ホストの安全保持はネットワークの保全にとって重要であり、他のコーポレートホストから分離する必要がある。コーポレートネットワークゾーン内には概して、別格の１つのホスト（制御ホストと称する）（図示しない）があり、構成のホストは、サーバゾーン１３０内のサーバに対する業務管理を行う。本実施例においては、各ファイアウォール１２０、１５０はそれに付随するパケットフィルタ処理構成ファイル１２５、１５５を有する（これらについては下に述べる）。
【００３７】
概して、パケットフィルタ処理構成ファイル１２５、１５５は、ファイアウォールに特有のルールベースである。多数のファイアウォールを有するマルチ・ファイアウォール環境（図１）においては、種々のファイアウォールが会社のイントラネットを多数のゾーン、例えば、サーバゾーン（非武装地帯）１３０、ファイアウォール業務管理ゾーン１４０、及びコーポレートネットワークゾーン１６０、に分割する。
【００３８】
この場合、セキュリティ・ポリシーは一般に、種々のゲートウェイに位置する多数のルールベースによって実現される。したがって、これらのルールベース間の相互動作によって、どのセッションの通過が許されるかが定められる。
【００３９】
図１に例示のコーポレートネットワーク環境では、信頼されている内部コーポレートユーザには無制限のアクセスあ提供される一方、外部ユーザは、明白に公衆利用可能とされるコンテンツにのみアクセスが許されるというセキュリティ・ポリシーが用いられる。具体的には、このセキュリティ・ポリシーでは内部コーポレートホストはインターネット上の全ての資源へのアクセスが許される。しかし、外部のホストは、サーバゾーン１３０内のサーバのみにアクセスできる。
【００４０】
詳しくは、コーポレートユーザへの電子メールサービスは、マルチ・サーバ１３８を介してのみ許され、ドメインネームシステム・サービスは、インターネットにはドメインネーム・サーバによってのみ提供される。加えて、符号１３４及び１３８のサーバについての更新は、サーバゾーン１３０内のサーバに対して業務管理を行うウェブ業務管理ホスト（制御ホスト）（図示しない）によってのみ行われる。他のコーポレートユーザは、非武装地帯（サーバゾーン）のサーバ１３４、１３８に関してインターネットホストと同じ特権を有する。
【００４１】
最後に、ファイアウォール１２０、１５０のインタフェースは、ファイアウォール業務管理ゾーン１４０のファイアウォール業務管理ホストからのみアクセスが可能である。
【００４２】
図１に示すように、本発明ではファイアウォール解析ツール２００が提供され、このファイアウォール解析ツールは、下で更に述べるように、関連するパケットフィルタ処理構成ファイル１２５、１５５を収集して読み取りを行い、黙示のセキュリティ・ポリシーを内部的表示の形で形成する。ファイアウォール解析ツール２００は、「１つ以上の与えられたサービスが１つ以上の与えられたマシンの間で許されるかどうか」のような単純な質問を受け取って評価するためのグラフィカル・ユーザ・インタフェースを提供する。
【００４３】
与えられたサービスが複数のサービスからなるサービス群である場合、ユーザは質問を統合することができる（ワイルドカード「可能な全てのサービス」まで）。そして、与えられたマシンは、任意の群数のＩＰアドレス群である（ワイルドカード「可能な全てのアドレス」まで）。
【００４４】
質問を与えられて、ファイアウォール解析ツール２００が、ネットワーク環境１００のトポロジーを考慮の上、種々のファイアウォールの挙動をシミュレートして、当初の質問に指定されたサービス又はマシンのどの部分がソースから宛先に到達することになるかを計算する。
【００４５】
すなわち、ファイアウォール解析ツール２００は、サービスの或る１つのサブセット（構成部分）のみが許されるかどうか、又はこれら許されたサービスが、指定されたソース及び宛先ホストグループのサブセットの間でのみ許されるかどうかを定める。
【００４６】
本発明の更に別の態様によれば、ファイアウォール解析ツール２００はソースのＩＰアドレスを変更することによって模擬の侵入攻撃をシミュレートすることができる。ファイアウォール解析ツールは、ネットワーク内でパケットを注入すべき位置として、ソースホストグループの真の位置ではないネットワーク内の位置を、ユーザが指定することを許す。ファイアウォール解析ツール２００は又、ネットワークアドレス変換（ＮＡＴ）を行うファイアウォールルールを考慮に入れることもできる。
【００４７】
[ファイアウォールの用語及びモデル化概念]
一般に、ファイアウォール構成ツールは、セキュリティ業務管理担当者が種々のホストグループ（ＩＰアドレスをあつめたもの（収集群））及びサービスグループ（プロトコルと、エンドポイントを形成するホストにおける対応するポート番号とのグループ）を定義することを可能にする。単一のルールには一般に、ソース、宛先、サービスグループ及び適切なアクションが含まれる。ソース及び宛先はホストグループであり、アクションは概して、対応するセッションのパケットを通過させるか又は脱落させるかのいずれかの動作の表示である。
【００４８】
加えて、このアクションによって、ログ記録の書き方又はネットワークアドレス変換（ＮＡＴ）の動作を指定される。
【００４９】
前に述べたように、ルールベースは、「順序」に対して感度がある。概略的には、ファイアウォールは、ルールベース中の第１のルールが新しいセッションに適用されるかどうかを点検する。もし第１のルールが適用される場合、パケットは第１のルールによって指定されるアクションに基づいて通過又は脱落させられる。もし第１のルールが適用されない場合、ファイアウォールは、ルールベース中の第２のルールが適用されるかどうかを点検し、以下も同様である。
【００５０】
本説明において、ゲートウェイは、パケットフィルタ処理マシンであり、ファイアウォール又はルータのいずれかである。普通、ゲートウェイは、多数の連関先（ホーム）を有する。その理由は、ゲートウェイが少なくとも２つのインターネット接続を有するからである。一般に、ゲートウェイは、多数のネットワーク接続を有する。各接続は、インタフェースを介して行われ、このインタフェースはそれ自体の独自のＩＰアドレスを有する。各インタフェースは、それに付随するパケットフィルタ処理構成ファイル１２５、１５５を有する。
【００５１】
ゲートウェイは、図１に示すように、ＩＰアドレススペースを、共通の要素を持たないゾーンに分割する。厳密には、ゾーンｚは、ゾーン内の２つのアドレスの間で送られたパケットがフィルタ処理ゲートウェイを通らないようなＩＰアドレスの最大数集合（セット）である。大抵のゾーンは会社のサブネットワークに対応し、通常１つの大きなインターネット１１０のゾーンが、その会社によって用いられていないＩＰアドレススペースの部分に対応する。
【００５２】
「サービス」とは、ｔｃｐ又はｕｄｐのようなプロトコルベースと、ソース及び宛先の両側におけるポート番号との組み合わせである。例えば、サービステルネット（ｔｅｌｎｅｔ）は、宛先ポート２３とソースポート（どれでも）でｔｃｐとして定義される。サービスグループは単に、サービスの集合（サービス群）である。
【００５３】
[ファイアウォール解析ツール]
図２に示すように、ファイアウォール解析ツール２００は、ユーザによって書かれたトポロジー定義ファイル２１０（簡単には、トポロジーファイル）に述べるように（下の「トポロジーファイル」の項で更に説明する）、ネットワークトポロジーの、事例を挙げて裏付けされたモデルを必要とする。図２に示すように、トポロジー定義ファイル２１０は、モデル定義言語（ＭＤＬ）の一部（サブセット）を用いて記述される（下の「モデル定義言語」の項で説明する）。
【００５４】
図２に示すように、ファイアウォール解析ツール２００の質問エンジン２４０が、図３に関連して下に述べるグラフデータ構造と、図４に関連して下に述べる質問アルゴリズム４００との組み合わせを用いる。図２に示すように、質問エンジン２４０は、ソース及び宛先（両方共ホストグループ）並びにサービスグループからなる、ユーザ２２０からの質問を入力として取る。
【００５５】
本発明の一態様によればファイアウォール解析ツール２００は、ネットワーク内の各ルータ及び切換器について知っている必要がなく、又用いられるルート規定に無関係である。概して、本発明においては、与えられたパケットがどの物理的パスに沿っても、もしそれがルート規定によれば許されない場合であっても、移動できるものと仮定する。本発明では、パケットフィルタ処理ルールベースをインストールしたデバイス及びこれらのデバイスが定義するゾーンを考慮する。
【００５６】
このレベルの細分性においてはトポロジーは全く安定している。したがって、トポロジーファイル２１０は、ファイアウォール１２０、１５０がネットワーク１００内で追加され又は置換された場合にのみ修正すればよい。
【００５７】
トポロジー定義ファイル２１０の一部として、ユーザ２２０は、ネットワーク環境１００内のゲートウェイ１２０、１５０のインタフェースの全てに対するルールベースを有するパケットフィルタ処理構成ファイル１２５、１５５（以下包括的に、ファイアウォール構成ファイル２３０と称する）の名称を指定する。
【００５８】
トポロジー定義ファイル２１０を読み取った後、ファイル解析ツール２００は、サポートされている変更ファイアウォールの各々に対する個別の「フロントエンド」モニタを用いてこれらのファイアウォール構成ファイルの各々を解析して、各デバイスに対する内部ルールベースデータ構造を設定する。尚、再度注記するが、これらのファイアウォール構成ファイル２３０は、ベンダ特有であり、対象のデバイスを構成するのに用いられるツールによって形成される。
【００５９】
ユーザが、質問の３部構成（サービス、ソース、宛先）の各項目を、例えば、構成ファイルにおいて定義されたホストグループ又はサービスグループ全ての選択を提示するドロップダウン（プルダウン）メニューから選択することによって質問を形成する。
【００６０】
[トポロジーのモデル化]
ネットワークトポロジーは、ゲートウェイを介して接続されるゾーン１３０、１４０、１６０にネットワーク環境１００を分割することによってモデル化される。各インタフェ−スはそれ自体のＩＰアドレスを有する（そして或る目的に対するホストと考えられる）か又は、もしファイアウォール１２０、１５０がブリッジとして作動する場合には不可視と宣言される（この宣言は例えばキーワード「ＩＮＶＩＳ」を用いて行われる）。
【００６１】
ゾーン１３０、１４０、１６０に対してそのゾーンから出る又はそのゾーンへ入るパケットは、その対応するインタフェース上でゲートウェイ（ファイアウォール）１２０、１５０によってフィルタ処理することができる。同じゾーン１３０、１４０、１６０内で送られ、受け取られたパケットは、ゲートウェイ１２０、１５０によってフィルタ処理することはできない。その理由は、単にパケットがゲートウェイ１２０、１５０を通過しないからである。
【００６２】
したがって、ファイアウォール解析ツール２００の見通しから、同じゾーン内の２つのホストの間に、全てのフィルタ処理がインタフェースによって行われるパスが存在する。ゾーンはホストグループから構成される。ホストグループは一般に、より小さいホストグループ又は単一のホストの階層に更に再分割される。
【００６３】
[トポロジーファイル]
本項では、ネットワーク環境１００を記述するのに用いられる、モデル定義言語（ＭＤＬ）で書かれたトポロジーの完全な作表表示を示す。トポロジーファイルによって、ゲートウェイゾーン・グラフ３００を構築するための入力メカニズム（機構）が与えられる。これについては下で更に述べる。第１に、ホストグループが定義される。
【００６４】
0004658340.tif 000002
【００６５】
尚、ＩＰアドレスレンジは異なる種々の仕方で指定できる。スラッシュ表記法は、何個の最上位ビットが固定であるかを表示することによってレンジを定義（指定）する。
【００６６】
次に、インタフェースが次のよう定義される。
【００６７】
0004658340.tif 000003
【００６８】
「NO_GEN」の属性を有するインタフェースは、フィルタ処理を行わない。「INVIS」 の属性を有するインタフェースは、ブリッジとして働くファイアウォールに属するのでＩＰアドレスを持たない。
【００６９】
最後に、ゲートウェイ及びゾーンが定義される。
【００７０】
0004658340.tif 000004
【００７１】
[名前付け]
本発明によって用いられるモデルにおいてオブジェクト（ホスト、ホストグループ、サービスグループ）は概して、名前を有する。このことで、ユーザとの対話の際、高レベルの要約が得られる。意味のある名前は生のＩＰアドレス及びポート番号よりもより多くの表現性がある。ファイアウォール解析ツール２００は、可能な範囲まで、これらの名前をベンダ特有の構成ファイルから得る。
【００７２】
しかし、各デバイス及びインタフェースが個々独立的に構成されているとの仮定から、名前の衝突（コンフリクト）が存在する。例えば、業務管理担当者が或る１つのゲートウェイのポート８０上のｔｃｐを表すのに「http」の名前を定義し、他方、別のゲートウェイ上で業務管理担当者がポート８０、８０００、及び８０８０上のｔｃｐを意味するのに同じ名前を用いる。
【００７３】
このレベルの名前付けをサポートするために、ファイル解析ツール２００は、インタフェースごとに個別の記号テーブル情況（コンテキスト）を維持する。もし同じ名前が異なる情況で異なる意味を持って現れた場合、ファイアウォール解析ツール２００はオプションとして、そのドロップダウンメニューに変形版の名前の全てを、インタフェース名を接頭語として付けて示すことができる。そうでない場合、もし変形版の名前が全て同じ場合、名前は１回だけ、接頭語なしに現れることになる。
【００７４】
[ルールベース]
コーポレートのネットワーク環境１００内にある黙示のセキュリティ・ポリシーは、ベンダ特有のパケットフィルタ処理構成ファイル１２５、１５５から導出される。ファイル解析ツール２００が、インタフェースに連関するこれらのパケットフィルタ処理構成ファイル１２５、１５５の各々を、次に示すレコード構造を含む論理ルールテーブルに変換する（説明の便宜上簡単化してある）。
【００７５】
0004658340.tif 000005
【００７６】
実際のセマンティクス（意味論）は異なるベンダ間では差異がある。本実施例においては、次の例示セマンティクスが利用される。パケットがフィルタ処理されると、リスト内のルールがその順序の順に点検され、合致が生じるまで点検が継続される。ソース、宛先、及びサービスグループ（service_grp） フィールドが、パケット内の対応するフィールドと対比される。
【００７７】
「方向」が、このインタフェースが位置するゲートウェイ１２０、１５０に入るパケット（ＩＮ）に適用されるのか又はゲートウェイ１２０、１５０を離れる（出る）パケット（ＯＵＴ）に適用されるのかを指定する（すなわち、ルールはゲートウェイ中心である）。ワイルドカードの方向（ＢＯＴＨ）は、ルールが両方向に適用されることを表す。もし合致が生じると、対応するアクション（脱落又は通過）が行われる。
【００７８】
内部ルールベーステーブルは又、ネットワークアドレス変換（ＮＡＴ）を行うルールをサポートする。したがってルール構造はいくつか追加フィールドを有する。
【００７９】
[質問]
ファイル解析ツール２００における中心オブジェクトは、質問である。質問はソースホストグループ、宛先ホストグループ、及びサービスグループからなる３部構成である。このような質問のセマンティクスは、ソースホストグループ内のどのＩＰアドレスがサービスグループから宛先ホストグループ内のどのＩＰアドレスにサービスを送ることができるのかということである。質問は次に示すデータ構造によって記述される。
【００８０】
0004658340.tif 000006
【００８１】
尚、再度注記するが、ホストグループ及びサービスグループはワイルドカードである。すなわち、質問の３部構成の要素のどれでも、「どれでも」を意味する"*" 印のワイルドカードであり得る。したがって、「どのマシンが会社のウェブサーバを使うことができるか」の質問は、形態（*, web_servers, http_services） を有する３部構成の質問によって表すことができる。但し、ホストグループ（web_servers） 及びサービスグループ（http_services） が定義されたと仮定する。
【００８２】
一般に、質問によって記述されるパケットの全てが宛先に到達できるわけではない。種々ののルールベースの動作を経る際に或るパケットは脱落する。したがって、ファイル解析ツール２００は、このような質問に、細かくした「サブ質問」のリスト、すなわち、各要素が、本来の質問３部構成内の対応する要素の一部分（サブセット）であるような３部構成質問のリスト、で回答することになる。
【００８３】
この回答のセマンティクスは、各サブセット３部構成について、対応するソースホストグループがサービスを宛先ホストグループに実際に送ることができることである。
【００８４】
[ゲートウェイゾーン・グラフ]
ファイル解析ツール２００は、ネットワークトポロジーを表すのにグラフデータ構造を利用する。図３は、図１のネットワーク環境に対するゲートウェイゾーン・グラフ３００を例示する。ゲートウェイゾーン・グラフ３００は、エッジ３２１〜３２５によって相互接続されたいくつかのノード３１１〜３１６からなる。グラフ理論原理に基づくゲートウェイゾーン・グラフ３００の生成の詳細説明については、文献（例えば、T. H. Cormen et al., Introduction to Algorithms, 463-630 (MIT Press, 1989)）を参照されたい。
【００８５】
図３に示す例示のゲートウェイゾーン・グラフ３００は次の標準表記法を利用する。三角形記号"△"はネットワーク環境１００内のゲートウェイ１２０、１５０を表し、矩形記号"□"はネットワーク環境１００内のゾーン１１０、１３０、１４０、１６０を表す。もし２つのノード３１１〜３１６の間に物理的接続がある場合には、これら２つのノードの間にはエッジ３２１〜３２５がある。
【００８６】
概して、ゲートウェイゾーン・グラフ３００は、与えられたパケットがネットワーク環境１００内のどこを移動することになるか、そしてこれらのパス沿いにどのゲートウェイにパケットが遭遇するか、をファイル解析ツール２００が定めるのを可能にする。
【００８７】
この目的のため、内部モデルは次の補助グラフを有する。本説明においては、ゲートウェイゾーン・グラフ３００は、その頂点がゲートウェイＧの集合（セット）とゾーンＺの集合とからなる２連グラフＨ＝((Ｇ∪Ｚ),Ｉ) として定義される。インタフェースＩの集合はエッジを形成する。すなわち、もしｇがその隣接ゾーンがｚであるインタフェースｉを有する場合そしてその場合にのみ、Ｈは、ゲートウェイｇ∈Ｇをゾーンｚ∈Ｚに接続するエッジｉ＝(ｇ,ｚ) を有する。
【００８８】
ゲートウェイゾーン・グラフ３００の頂点は、次に示す構造を用いて実現される。
【００８９】
0004658340.tif 000007
【００９０】
各ゲートウェイ及びゾーンに対してノードが１つある。種類（type）フィールドは、ゲートウェイ又はゾーンが与えられたノードによって表されるかどうかを示す。「hg」フィールドはノードに含まれるＩＰレンジを示す。ゾーンノードに対して、「hg」はゾーンのホストグループからこのゾーンに隣接するインタフェースのＩＰアドレスを差し引いたものである。ゲートウェイノードに対して、「hg」はゲートウェイに取り付けられたインタフェースのＩＰアドレスの集合である。ノード構造内の「q」 フィールドは、下で述べるように、質問の処理に用いられる。
【００９１】
[質問エンジンアルゴリズム]
ファイル解析ツール２００の質問エンジンは、図３に関して上に述べたグラフデータ構造と、図４に関して下で述べる質問アルゴリズム４００に含まれるルールベースシミュレータとの組み合わせを用いる。図２に示すように、質問エンジン２４０は、ソース及び宛先（両方共ホストグループ）並びにサービスグループからなる、ユーザ２２０からの質問を入力として取る。質問エンジンはそれから、質問によって記述されたパケット全ての挙動を、パケットがネットワーク内を移動する間にシミュレートする。
【００９２】
図４は、図２のファイル解析ツール２００によって行われる例示の質問エンジンアルゴリズム４００を説明する流れ図である。図４に示すように、ステップ４１０の間にユーザ質問が受け取られ、ステップ４２０の間に、この質問が先ず、ソースホストグループを含むゲートウェイゾーン・グラフ内のノードに添付される。
【００９３】
ワイルドカード"*" が用いられたときにもしソースホストグループが例えば単一のゾーンに含まれていない場合、ソースホストグループはステップ４２０の間に、各々が１つのゾーンに含まれる互いに素のホストグループに分解される。
【００９４】
それからステップ４３０の間に、各ソースホストグループを求めて個別のグラフ探索（サーチ）が行われる。概してグラフサーチは、グラフサーチで遭遇するゲートウェイゾーン・グラフ３００内の各ゲートウェイノードについて、上記の各ルールベースオブジェクトと対照して質問オブジェクトを評価する。
【００９５】
それからステップ４４０の間に、質問エンジンアルゴリズムが、現ノードに接続する全てのエッジにわたって質問を伝搬させようと試みる。質問エンジンアルゴリズムは、グラフ全体をサーチし終わるまで、この仕方で質問の伝搬を継続する。プログラム制御がステップ４６０の間に終了する前に、ステップ４５０の間に質問を満足させる全ての３部構成項目が特定される。
【００９６】
質問エンジンアルゴリズムの基本ステップは、ファイアウォール・インタフェースを意味するゲートウェイゾーン・グラフ３００内のエッジに質問を伝搬させることである。これは、質問によって記述されるパケットについてのインタフェースに添付されているルールベースの効果をモデル化するものである。一般に、質問のいくつかの部分のみしか、与えられたエッジを通過できない。その理由は、パケットのうちインタフェースによって脱落するものがあるからである。
【００９７】
したがって、１つのエッジを通過後、質問は、通過を許されるであろうパケットのみを表す、より細かい質問の集合に分解する必要がある。例えば、本来の質問は（corporate_net, internet, *）だったが、ルールベースは、外行のｈｔｔｐ及びｓｍｔｐサービスしか許さない。したがって、このエッジの他方側に到達する質問集合は今や（corporate_net, internet, tcp）、（corporate_net, internet, smtp） である。
【００９８】
尚、質問が、或るノードでは１回よりも多く到来し、他方、別のノードでは全く到来しない、その理由は、質問エンジンアルゴリズム４００が、質問がネットワーク環境１００を通して取り得る、考えられる全てのパスにわたって逆探知し、質問の或る部分が脱落せずに残っている限りこの探知を続けるからである。
【００９９】
もし質問がノードｖ（ゾーン又はゲートウェイ）にいくつかの異なるパスを経由して到達した場合、ノードｖに添付される新しい質問は、これら考えられるパスの各々を介してノードｖに到達した結果状態としての質問を合体させたものである。１つの変化例では、もし既に他のパスでは通過を許されなかった新しいパケットが通過を許されないであろうことが明確な場合には、複数のパスにわたる調査を行わないようにサーチを最適化することができる。
【０１００】
質問処理の最終段階は、ステップ４５０の間に結果を収集することである。これは単に、宛先ホストグループを含むノードをよく見て正しい宛先に到達した質問を取り出すことである。
【０１０１】
最悪の事例（ケース）では、質問エンジンアルゴリズム４００の複雑性がゲートウェイゾーン・グラフ３００のサイズにおいて指数関数的である。しかし、この最悪のケースは非常に密なグラフでしか生じない。一般的なゲートウェイゾーン・グラフ３００は混み方が非常に希薄である。その理由は、ファイアウォール１２０、１５０が普通、ネットワーク内の戦略的要衝に配置され、又最も一般的なケースのゲートウェイゾーン・グラフのトポロジーが樹木であるためである。
【０１０２】
樹木トポロジーでは、アルゴリズムは本質的に「深さ第一」サーチである。すなわち、グラフのサイズにおいて線形である。更に、ファイアウォールによって隔てられたゾーンのみがモデル化されるので、ゲートウェイゾーン・グラフは極めて小さくなりやすい。
【０１０３】
[模擬]
基本アルゴリズムを少し拡張することにより、模擬の侵入攻撃のテストが可能になる。質問を定義するソース、宛先、及びサービスのパラメータに加えて、パケットがそこから発起する「真のソース」を指定するオプションとしての第４のパラメータが追加される。この第４のパラメータが定義されると、本来のソースホストグループはパケット内にある贋のソースアドレスと理解される。
【０１０４】
すると質問は、上記の仕方で処理することが可能であるが、但し、変更点として、アルゴリズムは処理を贋ソースアドレスを含むノードから開始するのではなく真のソースを含むノードから開始する。
【０１０５】
[例]
「コーポレートゾーンと非武装地帯（サーバゾーン）との間で何のサービスが許されるか？」という質問を考える。結果は図５に示すとおりで、ファイアウォール構成がこの点で正しく行われたことを反映する。サービスはコーポレートゾーンの全てのホストに利用可能であるが、制御ホストのみがサーバへのｔｃｐ接続を開くことができる。
【０１０６】
加えて、注記したいのは、ホスト及びサービスグループの名前のみが表示され、より詳細な部分（実際のＩＰアドレス及びポート番号のような）は、エントリを拡大することによって（オプションとしてマウスクリックを介して）利用可能である。
【０１０７】
別の例で、「インターネット１１０は内部ネットワーク（ゾーン）１３０、１４０、１５０にどれだけ多くのアクセスを有するか？」という質問を考える。その結果を図６に示す。結果表示の最初の５行は、インターネット１１０上のどのホストもサーバゾーン１３０上のサーバへのアクセスに何らかの制約を受けることを示す。更に、ファイアウォール解析ツール２００の観点からはインターネット１１０のゾーンのどのホストもインターネット１１０のゾーンの他のどのホストとも会話することができ、このことが表示の第３行を説明している。
【０１０８】
しかし、最後の行はセキュリティ・ポリシー実現に際しての弱点を表示している。この行は、インターネット１１０上のどのホストも外部ゲートウェイの内部インタフェースとのサービスを潜在的に開設できることを表している。トポロジーファイルを調査すると次の問題が明らかになる。すなわち、「外部インタフェース（I_internet_dmz）は、いかなるフィルタ処理も行わなず、一旦パケットがゲートウェイを通って入ると、パケットがフィルタ処理なしに他方のインタフェースと会話できる」という問題である。
【０１０９】
このバルネラビリティを解決する、より細心の手法は、ルールベースを内部インタフェースでなく外部インタフェースに添付することである。
【０１１０】
別の例で、侵入攻撃の模擬行為の調査の仕方を説明する。最も敏感なホストは多分、ファイアウォール業務管理ゾーン１４０である。したがって、インターネットホストは、たとえそれが模擬行為の場合であっても、ファイアウォール業務管理ゾーン１４０に到達できるようであってはならない。この禁止を行うために、実際のソースがインターネット１１０のゾーンであるように設定され、与えられるソース（模擬アドレス）は任意である。その結果を図７に示す。
【０１１１】
結果が示す「漏れ」は実は、前の質問において見られる同じ問題の結果である。インターネットホストは、インタフェース（I_dmz_in）のソースアドレスを有するメッセージを生成できる。外部インタフェースではフィルタ処理は行われず、一旦内部に入ると、パケットは（I_dmz_in）というインタフェースそれ自体から発起されたかのように考えられ、ルールのうちの１つに合致することからこのパケットは通過させられてしまう。
【０１１２】
本発明の質問／回答メカニズムを更に拡張した場合には、質問についての追加情報が与えられる。例えば、質問の結果が「どのインタフェースにおけるどのルールが、或る特定のパケットの通過又は脱落をもたらしたか」を示すことが可能である。このような情報を図で表して、パケットがソースから宛先又はでの間に取るパスを示すことができる。
【０１１３】
本発明の質問／回答メカニズムの別の拡張によれば、ファイアウォール解析ツール２００を強化して、例えばゾーンを「内部」又は「外部」と定義することによってトポロジーに無関係な質問を可能化できる。もしファイアウォール解析ツール２００がファイルから質問を読み込むことができれば、ユーザは専門家によって生成された質問を用いて、ネットワークを或る基本的な非保安性（保安のよくない状態）に関してテストすることが可能になる。
【０１１４】
専門家の質問は、周知の保安のよくないポート又はサービスを対象にしていて、これらのポートの外部ゾーンからのアクセス可能性を点検できる。新しいバルネラビリティが知られるにつれて、ＣＥＲＴ（米国のコンピュータ緊急状態対応組織）のような組織が、更新された質問ファイルをダウンロード用にそれら組織のウェブサイト上で利用可能にすることができる。
【０１１５】
[モデル定義言語]
米国特許出願（Application Serial Number 09/240,934, filed January 29, 1999）（本発明の被譲渡人に譲渡）に述べられているように、セキュリティ・ポリシーを事例を挙げて裏付けするために、そしてそのポリシーをトポロジー上にマッピングするために、モデル定義言語（ＭＤＬ）が用いられる。解析システムがモデル定義言語プログラムを一例のエンティティ関係モデルに変換する。モデルは、対応するデータ構造によって表される。
【０１１６】
<<セキュリティ・ポリシー記述のためのモデル定義言語>>
サービスが次に示す形式のステートメントによって定義される。
0004658340.tif 000008
【０１１７】
例えば、次に示すコード・フラグメント（断片）が、広く用いられているsmtp、ssh、ping、httpsの諸サービス、及びtcp に基づく全てのパケットを表示するサービスを定義する。
【０１１８】
0004658340.tif 000009
【０１１９】
これらのサービスは、次に示す形式のステートメントによってサービスグループ（ServiceGrp）の形にグループ化される。
<service-grp-name> =｛<service-name1>,<service-name2> ...｝
【０１２０】
次に示すコード・フラグメントが２つのサービスグループ（admin-to-gtwy） 及び（gtwy-to-admin） を定義する。
0004658340.tif 000010
【０１２１】
次に示す形式のステートメントによって役割（role） が定義され、そこでは矢印（arrow） が明瞭な仕方で方向属性を定義し、role-grp-name がピアを指し、srv-grp-nameがservice-group を指す。
0004658340.tif 000011
【０１２２】
次に示すコード・フラグメントが、上に述べたmail_server、及びinternal_mail_server という役割を定義する。
【０１２３】
0004658340.tif 000012
【０１２４】
役割が、次に示すステートメントによって、開いた（デフォルトで）役割グループ（role group）３２５の形にグループ化される。
<role-grp-name> =｛<role-name1>,<role-name2> ...｝
役割が、次に示すステートメントによって、閉じた役割グループの形にグループ化される。
<role-grp-name> = << <role-name1>,<role-name2> ...>>
【０１２５】
次に示すコード・フラグメントが、役割グループ（role-group）及びゲートウェイ（gateway） を定義し、単方向ゲートウェイの役割を１つの役割グループ内にバンドルする。
0004658340.tif 000013
【０１２６】
<<トポロジー記述及びポリシーマッピングのためのモデル定義言語>>
ホスト及びホストグループが次に示すステートメントによって定義される。
<host-name> = [ <IP-Addr>]:<role-grp-name>
<host-grp-name> = [ <IP-Range>]:<role-grp-name>
【０１２７】
次に示すコード・フラグメントが、ダーティ・ホスト（firty host）（多分、イントラネットの外部に位置する）及びダスティ・ホスト（dusty host）を定義し、これらのホストに外部メールサーバ及び内部メールサーバの役割をそれぞれ割り当てる。
0004658340.tif 000014
【０１２８】
ゲートウェイが次に示すステートメントによって定義される。
<gateway-name> =｛<host-name1>,<host-name2> ...｝
【０１２９】
次に示すコード・フラグメントが、payroll_gw_interface1/2 をホストとして定義し、それらのＩＰアドレスを指定し、それからゲートウェイpayroll_gwを、その２つのインタフェースとしてpayroll_gw_interface 1/2を有するものとして定義する。コード・フラグメントは又、役割グループ、ゲートウェイをインタフェースに割り当てる。
【０１３０】
0004658340.tif 000015
【０１３１】
ゾーンは、次に示すステートメントによって定義される。
<zone-name> :｛<gtwy-interface-name1>,<gtwy-interface-name2> ...｝
【０１３２】
次に示すコード・フラグメントが、payroll_zone及びcorp_zone （イントラネットmanhattan_officeの数部分）をホストグループとして定義し、それらのＩＰレンジを指定し、それからpayroll_zoneを、payroll_gw_interface1 によってpayroll_gwに接続されるものとして指定することによって又payroll_gw_interface2 をcorp_zone に接続されるものとして指定することによって、ネットワークトポロジーの数部分を定義する。
【０１３３】
0004658340.tif 000016
【０１３４】
以上の説明は、本発明の一実施例に関するもので、この技術分野の当業者であれば、本発明の種々の変形例を考え得るが、それらはいずれも本発明の技術的範囲に包含される。
尚、特許請求の範囲に記載した参照番号は発明の容易な理解のためで、その技術的範囲を制限するよう解釈されるべきではない。
【０１３５】
【発明の効果】
以上述べたごとく、本発明によれば、ネットワークのファイアウォール（ゲートウェイ）のセキュリティ・ポリシーの解析に用いられる、利用性及び効率の大幅に増大した解析ツールが得られる。
じれにより、大域的ファイアウォール・ポリシーを発見して解析することができる。ネットワークトポロジーを最小の記述のみ用いるだけで、ベンダ特有で低レベルの種々の構成ファイルを直接解析することができる。更に、適切な要約レベルで行われる質疑応答セッションを通してユーザと対話する処理が可能である。このようにファイアウォールの解析処理効率が改善される。
【図面の簡単な説明】
【図１】本発明に基づくネットワーク環境の例を示す説明図である。
【図２】図１のファイアウォール解析ツールの構成要素を示す説明図である。
【図３】図１のネットワーク環境のゲートウェイゾーン・グラフを示す説明図である。
【図４】図２のファイアウォール解析ツールによって行われる質問エンジン・アルゴリズムの例を記述する流れ図である。
【図５】ユーザの質問を受け取って結果を提供するために図２のファイアウォール解析ツールが用いる例示のグラフィカル・ユーザ・インタフェースの画面である。
【図６】ユーザの質問を受け取って結果を提供するために図２のファイアウォール解析ツールが用いる例示のグラフィカル・ユーザ・インタフェースの画面である。
【図７】ユーザの質問を受け取って結果を提供するために図２のファイアウォール解析ツールが用いる例示のグラフィカル・ユーザ・インタフェースの画面である。
【符号の説明】
１００  ネットワーク環境
１１０  インターネット
１２０  外部ファイアウォール
１２５  パケットフィルタ処理構成ファイル
１３０  サーバゾーン
１３４  ドメインネーム・サーバ（ｄｎｓ）
１３８  マルチ・サーバ
１４０  ファイアウォール業務管理ゾーン
１５０  内部ファイアウォール
１５５  パケットフィルタ処理構成ファイル
１６０  コーポレートネットワークゾーン
２００  ファイアウォール解析ツール
２１０  ネットワークトポロジー定義ファイル
２２０  ユーザ
２３０  ファイアウォール構成ファイル
２４０  質問エンジン
２５０  グラフアルゴリズム
３００  ゲートウェイゾーン・グラフ
３１１、３１２、３１３、３１４、３１５、３１６  ノード
３２１、３２２、３２３、３２４、３２５  エッジ
４００  質問アルゴリズム
【図１】
0004658340.tif 000017
【図２】
0004658340.tif 000018
【図３】
0004658340.tif 000019
【図４】
0004658340.tif 000020
【図５】
0004658340.tif 000021
【図６】
0004658340.tif 000022
【図７】
0004658340.tif 000023