(57)【要約】【課題】リモートにて脆弱性検査を実施する場合、アクセス制御のため、許可されているサービス以外の検査を実施できない。【解決手段】管理端末１００は検査ホスト７００に検査要求情報１０１を送信し、検査可否情報７０１を得る。その経路上のルータ４００は当該通信の内容をデータベース４０１に保持し、当該データベース４０１の情報に基づいて検査ホスト７００から検査対象の公開ホスト２００、３００のアクセス制御を自動設定し、リモート検査を実施する。これにより、アクセス制御によらない脆弱性検査をリモートにて実施可能となり、より詳細なセキュリティ検査が低コストで実施可能となる。【選択図】  図１
2004356787.tif 000002
【特許請求の範囲】
【請求項１】
外部ネットワークと内部ネットワークを互いに接続するゲートウェイ機器と、
検査対象のホストにセキュリティ上の脆弱性検査を実施する機能を備えた、外部ネットワークに接続した検査用ホストと、
脆弱性を検査する対象となる、内部ネットワークに接続した公開ホストと、
当該ゲートウェイ機器にて外部ネットワークから公開ホストへのアクセス制御が設定されているネットワークシステムにおいて、
内部ネットワークから検査用ホストに対して、公開ホストへの脆弱性検査を実施するための検査要求情報を伝達する手段と、
当該検査要求情報に基づいて脆弱性検査の可否を判定し、公開ホストへの脆弱性検査を実施するための検査可否情報を返信する手段と、
当該検査要求情報および検査可否情報をゲートウェイ機器が保持する手段を備え、
当該検査要求情報および検査可否情報に基づいて、ゲートウェイ機器が自身のアクセス制御設定を自動で変更する手段を備えることを特徴とするセキュリティ検査システム。
【請求項２】
請求項１記載のセキュリティ検査システムにおいて、
検査要求情報または検査可否情報に検査対象の公開ホストと検査実施元の検査ホストのアドレス情報、および検査開始時刻と検査終了時刻を含み、
ゲートウェイ機器が当該検査開始時刻から検査終了時刻の間のみ自身のアクセス制御設定を検査用に変更する手段と、
検査終了時刻後にアクセス制御設定を検査開始時刻前のものに変更する手段を備えることを特徴とするセキュリティ検査システム。
【請求項３】
請求項１記載のセキュリティ検査システムにおいて、
複数の公開ホストへの脆弱性検査スケジュール情報を管理する手段と、
当該スケジュール情報に基づいて、異なる新たな公開ホストに関する検査要求情報または検査可否情報に含まれる検査開始時刻および検査終了時刻を変更する手段と、
ゲートウェイ機器が当該変更された検査開始時刻から検査終了時刻に応じて自身のアクセス制御設定を変更する手段を備えることを特徴とするセキュリティ検査システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ネットワーク上のホストに関するセキュリティの脆弱性を検査するシステムに係り、特にリモートホストの脆弱性検査におけるアクセス制御設定方法に関する。
【０００２】
【従来の技術】
インターネットなどのネットワーク上に配置されたホスト（ｈｔｔｐ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）サーバなど）に対するハッキング、クラッキング攻撃の被害が多数報告されている。攻撃者はホストの脆弱性（ソフトウェアのバグなど）をつくことで対象ホストへの不正な侵入を試みる。これが成功した場合、当該ホスト上のデータ漏えい、改ざん、当該ホストを踏み台としたさらなる二次攻撃などの被害が発生する。具体的には顧客情報の漏えい、Ｗｅｂページの改ざん、ＤＤｏＳ攻撃（Ｄｉｓｔｒｉｂｕｔｅｄ  Ｄｅｎａｉａｌ  ｏｆ  Ｓｅｒｖｉｃｅ  ａｔｔａｃｋｓ）などの踏み台ホストからの二次攻撃、などがあげられる。
【０００３】
そこでシステム管理者は、攻撃者に自ホストの脆弱性をつかれ、ホストへの侵入を許すことのないよう対策を行う必要がある。その一つとして、ホストに対する脆弱性検査があげられる。脆弱性検査とは、対象のホストに対して擬似的な攻撃やバナーチェックなどを行い、対象ホスト上で動作しているサービス（アプリケーション）に脆弱性があるかどうかをチェックする手法である。例えばあるｈｔｔｐサーバに対して、ｈｔｔｐサービスを待ち受けしているポート８０番へのアクセスを行い、ｈｔｔｐサービスを動作させているアプリケーションのバージョン情報を入手する。そしてそのバージョンが持つ脆弱性をチェックすることで、検査対象のホストに関する脆弱性検査を行う、などである。この脆弱性検査を定期的に行うことで、システム管理者は検査対象のホストに関する脆弱性を知ることができ、アプリケーションのバージョンアップなどの適切な処置を効率よく施すことができる。
【０００４】
この方法に関する従来技術として、特許文献１に記載の技術がある。本従来技術では、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）などの内部ネットワークとインターネットなどの外部ネットワークを接続するルータＡと、内部ネットワークに配置した、外部ネットワークにサービスを公開している検査対象のホストＢとホストＣ、ルータＡやホストＢなどを管理するための管理端末Ｄ、外部ネットワークに配置した、ホストＢおよびホストＣに関するセキュリティ上の脆弱性を検査するための検査ホストＥを設ける。管理端末Ｄは検査ホストＥに、ホストＢおよびホストＣに対する脆弱性検査要求を送信し、当該検査要求を受信した検査ホストＥは、検査結果閲覧用の識別番号を管理端末Ｃに送信する。その後検査ホストＥはネットワークを介して検査対象のホストＢおよびホストＣの検査を実施する。検査結果の情報は検査ホストＥに格納され、管理端末Ｄはネットワークを介して先の識別番号を用いて検査結果を閲覧する。
【０００５】
【特許文献１】
特開２００２−３２３３８号公報
【０００６】
【発明が解決しようとする課題】
先に述べた従来技術においては、詳細な脆弱性検査を実施することが困難であるという課題がある。一般的に脆弱性検査とは、本従来技術にて実現可能なリモートで行う検査（以下リモート検査）と、検査ホストを検査対象ホストが配置されているデータセンタなどに物理的に持ち込み、両者の通信の間のアクセス制御設定を全てのサービスについて許可した上で、全てのサービスについての検査を実施するオンサイト検査の２つがある。
【０００７】
リモート検査ではルータＡなどにて設定されたアクセス制御にて許可しているサービス（例えばインターネットからホストＢへのアクセスはｈｔｔｐに限り、ホストＣへのアクセスはｄｎｓ（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｅｒｖｉｃｅｓ）、ｓｍｔｐ（Ｓｉｍｐｌｅ  Ｍａｉｌ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）に限る、など）についての脆弱性検査を実施することが可能である。しかしながら万が一、ホストＢがｈｔｔｐの脆弱性などをつかれてホストを乗っ取られた場合、ホストＢからホストＣへの二次被害に関する脆弱性検査を実施することができない。これは踏み台攻撃と呼ばれるもので、乗っ取りが成功したホストを踏み台とした上で、その他のホストに対しての攻撃を行うという手法である。
【０００８】
攻撃者から見ると、攻撃元のホスト情報（ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）アドレス情報など）を踏み台ホストにて隠すことができる、踏み台ホストのリソースを利用可能である、など利点があり、昨今、より一般的な攻撃手法となりつつある。ここでホストＣをリモート検査した場合、ルータＡにて許可しているｄｎｓ、ｓｍｔｐに関する脆弱性のみを検出することができる。
【０００９】
しかしながらホストＣ上にてその他のサービスが起動している場合（例えばｔｅｌｎｅｔ、ｆｔｐ（Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）など）、リモート検査ではそれらのサービスについての脆弱性を調査することができない。ルータＡのアクセス制御設定により、検査ホストＥからの接続が遮断されているためである。よってホストＢからホストＣへのアクセス制御設定によっては、リモート検査で検出できなかったサービスについての脆弱性をついた二次攻撃を行うことが可能である。このように本従来技術にて実現可能なリモート検査のみでは、より詳細な検査を実施することができず、特に踏み台を経由した二次攻撃についてのリスクを検査することはできない。
【００１０】
オンサイト検査では、検査ホストから検査対象のホストへ全てのサービスについて接続が可能となるよう、検査ホストを物理的に配置させる手段をとる。例えば検査ホストを検査対象ホストと同一サブネット上に配置し、アクセス制御設定を全て解除する、などの手法をとる。この手法では、検査対象のホスト上で動作している全てのサービスについての脆弱性を検査可能であるため、上記リモート検査より詳細な検査を実施でき、踏み台を経由した二次攻撃についてのリスクを調査することが可能となる。しかしながら検査ホストを物理的に移動する必要があり、この場合、輸送コストや人的コスト、ソフトウェアライセンス（検査ホストによってはホストに設定するＩＰアドレス単位でのライセンス形態であるケースが存在する）などの問題があり、現実には様々な制約条件が発生する。
【００１１】
そこで、システム構成をリモート検査と同様にした上で、通信経路上にあるルータＡなどのアクセス制御を一時的に変更することで、リモートからオンサイトと同様の詳細な検査を行う手法も存在する。これはルータＡなどのアクセス制御を、検査ホストと検査対象ホスト間の接続を全てのプロトコルについて許可するよう手動で設定する手法である。しかしながら本手法においては、アクセス制御設定を手動で変更する必要があり、工数の増加やオペレーションミスなどの課題がある。
【００１２】
【課題を解決するための手段】
本発明は、検査対象ホストの途中経路上のルータやＦｉｒｅｗａｌｌなどのゲートウェイ機器のアクセス制御設定によらない、より詳細なセキュリティ検査を実現する技術を提供する。同検査をリモートで実現することで、アクセス制御設定における工数削減、オペレーションミスの回避を実現し、これにより迅速かつ詳細なセキュリティ検査を低コストで実現することが可能となる。
【００１３】
より具体的には、本発明では、脆弱性検査を実施する検査ホストを配置した外部ネットワークと、検査対象となる公開ホストを配置した内部ネットワークを互いに接続し、かつアクセス制御設定を実装したゲートウェイ機器を設ける。そして内部ネットワークから検査用ホストに対して、公開ホストへの脆弱性検査を実施するための検査要求情報を伝達する手段と、当該検査要求情報に基づいて脆弱性検査の可否を判定し、公開ホストへの脆弱性検査を実施するための検査可否情報を返信する手段を設ける。さらに当該検査要求情報および検査可否情報をゲートウェイ機器が保持する手段を備え、当該検査要求情報および検査可否情報に基づいて、ゲートウェイ機器が自身のアクセス制御設定を自動で変更する手段を備える。
【００１４】
また検査要求情報または検査可否情報に検査対象の公開ホストと検査実施元の検査ホストのアドレス情報、および検査開始時刻と検査終了時刻を含み、ゲートウェイ機器が当該検査開始時刻から検査終了時刻の間のみ自身のアクセス制御設定を検査用に変更する手段と、検査終了時刻後にアクセス制御設定を検査開始時刻前のものに変更する手段を備える。
【００１５】
これにより、検査対象ホストの途中経路上のゲートウェイ機器のアクセス制御によらない脆弱性検査を実施可能となり、より詳細なセキュリティ検査を実施可能となる。かつ同検査をリモートで実施可能であり、アクセス制御設定における工数削減、オペレーションミスの回避も可能となる。これにより迅速かつ詳細なセキュリティ検査を低コストで実現することができる。
【００１６】
【発明の実施の形態】
以下、本発明の実施の形態について、図面を用いて詳細に説明する。
【００１７】
図１は本発明の一実施例におけるシステム構成図である。
【００１８】
本実施例では、ＬＡＮなどのネットワークである内部ネットワーク５００と、インターネットなどの外部ネットワーク６００、そして内部ネットワーク５００と外部ネットワーク６００を接続するゲートウェイ機器であるルータ４００にて構成される。内部ネットワーク５００には、外部ネットワーク６００にｈｔｔｐなどのサービスを提供している公開ホスト２００、公開ホスト３００が配置され、当該公開ホスト２００、３００とルータ４００を管理するための端末である管理端末１００を配置する。なおルータ４００は後述するアクセス制御設定を変更するためのデータベース４０１を備える。
【００１９】
外部ネットワーク６００には脆弱性検査を実施する機能を備える検査ホスト７００を配置する。まず管理端末１００は検査サーバ７００に、公開サーバ２００、３００を所定の時刻にて検査するよう依頼するための情報である検査要求情報１０１を送信する。検査サーバ７００は当該検査要求情報１０１の情報に基づいて検査実施の可否を後述するスケジュールデータベース７０２の情報に基づいて判断し、検査可否情報７０１を端末１００に返信する。このとき検査要求情報１０１および検査可否情報７０１の情報は、途中経路であるルータ４００内のデータベース４０１にて保持される。その後ルータ４００が検査サーバ７００と公開サーバ２００，３００間のアクセス制御を検査用に自動で変更し、脆弱性検査を実施する。検査終了後、ルータ４００は自身のアクセス制御設定を元に戻し、検査サーバ７００は検査結果を記述した検査結果ファイル７０２を生成する。管理端末１００は検査可否情報７０１に含まれるＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）情報を参照することで、検査結果ファイル７０２を参照可能となり、脆弱性検査の手順が終了する。
【００２０】
以下、上記脆弱性検査の手順を詳細に説明する。図２は脆弱性検査の手順を示すフロー図である。
【００２１】
ステップ１００１では、管理端末１００が検査ホスト７００に対し、検査要求情報１０１を送信する。検査要求情報とは、所定のホストに対して所定の時刻にて脆弱性検査を実施するよう依頼するためのデータである。検査要求情報による検査依頼は例えば、検査ホスト７００にｈｔｔｐサービスが起動しているものとして、管理端末１００が図３に示すＷｅｂページである検査要求情報入力画面７１０にアクセスすることで実現可能である。
【００２２】
管理端末１００では検査要求情報入力画面７１０において、入力フィールド７１１にて検査対象となる公開ホストのアドレス情報（例えばＩＰアドレス情報）を入力する。ここでは検査対象となる公開ホスト２００のＩＰアドレスを「ａ．ｂ．ｃ．ｄ」、公開ホスト３００のＩＰアドレスを「ａ．ｂ．ｃ．ｅ」として、入力フィールド７１１に入力する。そして入力フィールド７１２では脆弱性検査の開始希望時刻を、入力フィールド７１３では脆弱性検査の終了希望時刻を入力する。ここでは開始時刻を「０２／１２／１２／１０：００」、終了時刻を「０２／１２／１２／１７：００」とする。この開始時刻、終了時刻は後に述べる検査可否の判定、およびアクセス制御設定の自動変更にて利用される。そして送信ボタン７１４を押すことで上記情報を検査ホスト７００に送信する。
【００２３】
これらの方法によって検査ホスト７００は、検査対象ホストのアドレス情報、検査開始時刻、検査終了時刻を含む検査要求情報１０１を得ることができる。なお検査要求情報１０１のデータ構造を図４に示す。図４に示すように検査要求情報１０１は、検査対象ホストのアドレス情報「ｔａｒｇｅｔ」、検査開始情報「ｓｔａｒｔ」、検査終了情報「ｅｎｄ」にて構成されるレコードを含む。
【００２４】
検査要求情報１０１のやり取りはルータ４００を経由して行われる。このときルータ４００は当該検査要求情報１０１のデータを内部データベースであるデータベース４０１に保持しておく（ステップ１００２）。このデータベース４０１は自身のアクセス制御設定を変更する機能を実現するための情報を格納する役割を持ち、当該機能については後述する。
【００２５】
ステップ１００３では、検査要求情報１０１を受信した検査ホスト７００が、当該検査要求情報１０１の内容に基づいて、脆弱性検査を実施することが可能かどうかの判定を行う。検査ホスト７００は検査要求情報１０１の内容を解析し、検査開始時刻と検査終了時刻を得る。そしてこの時刻情報に基づいて検査可否の判定を実施する。
【００２６】
検査可否の処理については後述し、ここでは検査要求情報１０１に含まれる検査開始、終了時刻にて検査が可能であると判定したとする。すると検査ホスト７００はステップ１００３２にて、検査を行うべきスケジュール情報を格納したスケジュールデータベース７０２に検査要求情報１０１の内容を格納する。スケジュールデータベース７０２は検査ホスト７００が保持し、図５にデータ構造を示す。
【００２７】
図５に示すようにスケジュールデータベース７０２は、検査対象となるホストのアドレス情報「ｔａｒｇｅｔ」、検査開始時刻「ｓｔａｒｔ」、検査終了時刻「ｅｎｄ」にて構成されるレコードを含む。例えば１行目のレコードでは、検査開始時刻「０２／１２／１２／１０：００」から検査終了時刻「０２／１２／１２／１７：００」まで検査対象ホスト「ａ．ｂ．ｃ．ｄ」の検査をスケジューリングしており、３、４行目のレコードでは別サイトのホストの検査をスケジューリングしていることを示している。
【００２８】
ステップ１００４では、検査ホスト７００が検査可否情報７０１を端末１００に返信する。図６に検査可否情報７０１を示す。図６に示すように検査可否情報７０１は、検査を実施する検査ホスト７００のアドレス情報（ＩＰアドレス）「ｓｏｕｒｃｅ」、検査結果閲覧用のＵＲＬ情報「ｕｒｌ」にて構成されるレコードを含む。端末１００は当該検査可否情報７０１を受信することで、先に送信した検査要求情報１０１にて指定した内容での検査が実施されることを知ることができる。
【００２９】
検査可否情報７０１のやり取りはルータ４００を経由して行われる。このときルータ４００はステップ１００２と同様に、当該検査可否情報７０１のデータを内部データベースであるデータベース４０１に保持しておく（ステップ１００５）。なお図７にデータベース４０１のデータ構造を示す。図７に示すように、データベース４０１には、検査要求情報１０１から得た検査対象ホストのアドレス情報「ｔａｒｇｅｔ」、検査開始時刻「ｓｔａｒｔ」、検査終了時刻「ｅｎｄ」、検査可否情報７０１から得た検査元ホストのアドレス情報「ｓｏｕｒｃｅ」にて構成されるレコードを含む。
【００３０】
ステップ１００６では、ルータ４００がデータベース４０１に含まれる検査開始時刻「ｓｔａｒｔ」を参照し、現在時刻との比較処理を行う。ルータ４００は現在時刻が当該検査開始時刻になるまで待ち続け、指定された時刻になるとステップ１００７へと進む。
【００３１】
例えばステップ１００５までの処理が「０２／１２／１２／０７：００」に行われたとすると、ルータ４００は検査開始時刻である「０２／１２／１２／１０：００」まで処理を待ち続け、検査開始時刻になると、ステップ１００７に示す処理を実行する。なおルータ４００と検査ホスト７００の時刻同期はＮＴＰ（Ｎｅｔｗｏｒｋ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）などを用いて実現可能である。
【００３２】
ステップ１００７では、ルータ４００が自身のアクセス制御設定を変更する処理を行う。図８にルータ４００にて設定されている現状のアクセス制御設定ルール４０２を示す。図８に示すようにアクセス制御設定ルール４０２は、外部ネットワーク６００から公開ホスト２００，３００への接続をｈｔｔｐ、ｄｎｓ、ｓｍｔｐのみ許可しているとする（例えば１行目のルールでは、全てのホストから（ｓｏｕｒｃｅ＝ａｎｙ）公開ホスト２００への接続を（ｄｅｓｔｉｎａｔｉｏｎ＝ａ．ｂ．ｃ．ｄ）、ｈｔｔｐ，ｄｎｓ，ｓｍｔｐ（ｐｒｏｔｏｃｏｌ＝ｈｔｔｐ，ｄｎｓ，ｓｍｔｐ）について許可（ａｃｔｉｏｎ＝ｐｅｒｍｉｔ）する、と読む。なお明示的に記入されていない通信については全て遮断する設定となる）。このルールをデータベース４０１に含まれる情報に基づいて、必要なアクセス制御設定に変更する処理を行う。
【００３３】
図９に変更したアクセス制御設定ルール４０３を示す。図９に示すように、外部ネットワーク６００から公開ホスト２００，３００への接続に関してはアクセス制御設定ルール４０２と同様である（１、２行目のルール）。これに加えアクセス制御設定ルール４０３では、データベース４０１に含まれる検査対象ホストのアドレス情報と検査元ホストのアドレス情報に基づいて、検査ホスト７００「ｓｏｕｒｃｅ＝ｗ．ｘ．ｙ．ｚ」から公開ホスト２００，３００「ｔａｒｇｅｔ＝ａ．ｂ．ｃ．ｄ，ａ．ｂ．ｃ．ｅ」への接続を全てのサービスについて許可するルールを加える（３、４行目のルール）。
【００３４】
具体的にはデータベース４０１に含まれる「ｓｏｕｒｃｅ」から「ｔａｒｇｅｔ」への接続については全てのサービスについて許可するルールを加える。これにより検査ホスト７００は全てのサービスについての脆弱性検査を公開ホスト２００，３００について実施することが可能となる（ステップ１００８）。
【００３５】
ステップ１００９では、ルータ４００がデータベース４０１に含まれる検査終了時刻「ｅｎｄ」を参照し、現在時刻との比較処理を行う。ルータ４００は現在時刻が当該検査終了時刻になるまで待ち続け、指定された時刻になるとステップ１０１０へと進む。
【００３６】
ステップ１０１０では、ルータ４００が自身のアクセス制御設定を変更する処理を行う。具体的には図９に示すアクセス制御設定ルール４０３を、図８に示すアクセス制御設定ルール４０２に戻す処理を行う。これにより検査終了時にはアクセス制御設定が元に戻ることとなる。
【００３７】
ステップ１０１１では、検査ホスト７００が公開ホスト２００，３００の検査結果を記述した検査結果ファイル７０３を生成する。検査結果ファイル７０３はステップ１００４にて返信した検査可否情報７０１に含まれるＵＲＬ情報にて管理端末１００から閲覧可能とする。この場合、検査結果ファイル７０３はＷｅｂにて閲覧可能とし、管理端末１００は検査可否情報７０１を受信することで得たＵＲＬ情報（ｈｔｔｐ：／／ｂａｒ／ｚｚ．ｈｔｍ）にて当該検査結果ファイル７０３を参照可能となる。
【００３８】
以上をもって本実施例における脆弱性検査の手順が終了する。これにより、検査対象ホストの途中経路上のルータやＦｉｒｅｗａｌｌなどのゲートウェイ機器のアクセス制御にて許可しているサービス以外の脆弱性検査を実施可能となり、より詳細なセキュリティ検査を実施可能となる。かつ同検査をリモートで実施可能であり、アクセス制御設定における工数削減、オペレーションミスの回避も可能となる。これにより迅速かつ詳細なセキュリティ検査を低コストで実現できる。
【００３９】
ステップ１００３において、検査ホスト７００が検査要求情報１０１に基づいて検査可否を判定するが、以下、この検査可否判定の処理について詳しく説明する。
【００４０】
検査ホスト７００は、その脆弱性検査の機能（製品の仕様などによる）や処理性能により、同一時刻に複数のホストへの検査ができないものがある。そこでスケジュールデータベース７０２を参照し、所定の時刻にて検査が可能であるかどうかを判定する機能が必要となる。例えば検査ホスト７００は、ある同一時刻内の検査対象ホストを１つしか設定できず、かつ１つのホストについて必要な検査時間は５時間であるとする。このとき検査要求情報１０１では、０２／１２／１２／１０：００から１７：００の間で２つのホストを検査するよう要求している。
【００４１】
ここで公開ホスト２００の検査を０２／１２／１２／１０：００から行うと、検査終了時刻が０２／１２／１２／１５：００となる。その間の新たな検査はできないため、公開ホスト３００への検査は０２／１２／１２／１５：００から０２／１２／１２／２０：００までへと、再度検査開始、終了時刻をスケジューリングしなければならない。そこで検査ホスト７００は、受信した検査要求情報１０１を図１０に示す検査要求情報１０１１に書き換え（ステップ１００３１）、ステップ１００３２にて検査要求情報１０１１をスケジュールデータベース７０２に格納する（図１１にスケジュールデータベース７０２を示す）。
【００４２】
その後、図１２に示す新たな検査開始、終了時刻を加えた検査可否情報７０１１を管理端末１００に返信する（ステップ１００４）。ステップ１００５ではルータ４００が検査可否情報７０１１に基づいてデータベース４０１を図１３のように書き換え、その後のステップで、新たに再スケジューリングされた時刻情報に基づいた検査を実現することが可能となる。
【００４３】
【発明の効果】
本発明により、アクセス制御にて許可されているサービス以外の脆弱性検査が実施可能となり、より詳細なセキュリティ検査を実施可能となる。かつ同検査をリモートで実施可能であり、アクセス制御設定における工数削減、オペレーションミスの回避も可能となる。これにより迅速かつ詳細なセキュリティ検査を低コストで実現できる。
【図面の簡単な説明】
【図１】実施例のシステム構成図である。
【図２】実施例の脆弱性検査の手順を示すフロー図である。
【図３】実施例の検査要求を送信するための画面である。
【図４】実施例の検査要求情報１０１のデータ構造である。
【図５】実施例のスケジュールデータベース７０２のデータ構造である。
【図６】実施例の検査可否情報７０１のデータ構造である。
【図７】実施例のルータ４００内データベース４０１のデータ構造である。
【図８】実施例のルータ４００のアクセス制御ルール４０２を示す。
【図９】実施例のルータ４００のアクセス制御ルール４０３を示す。
【図１０】実施例の検査要求情報１０１１のデータ構造である。
【図１１】実施例のスケジュールデータベース７０２のデータ構造である。
【図１２】実施例の検査可否情報７０１１のデータ構造である。
【図１３】実施例のルータ４００内データベース４０１のデータ構造である。
【符号の説明】
１００…管理端末、１０１…検査要求情報、２００…公開ホスト、３００…公開ホスト、４００…ルータ、４０１…データベース、４０２…アクセス制御ルール、４０３…アクセス制御ルール、５００…内部ネットワーク、６００…外部ネットワーク、７００…検査ホスト、７０１…検査可否情報、７０２…スケジュールデータベース、７０３…検査結果ファイル、７１０…検査要求情報入力画面、７１１…入力フィールド、７１２…入力フィールド、７１３…入力フィールド、７１４…送信ボタン、１０１１…検査要求情報、７０１１…検査可否情報。
【図１】
2004356787.tif 000003
【図２】
2004356787.tif 000004
【図３】
2004356787.tif 000005
【図４】
2004356787.tif 000006
【図５】
2004356787.tif 000007
【図６】
2004356787.tif 000008
【図７】
2004356787.tif 000009
【図８】
2004356787.tif 000010
【図９】
2004356787.tif 000011
【図１０】
2004356787.tif 000012
【図１１】
2004356787.tif 000013
【図１２】
2004356787.tif 000014
【図１３】
2004356787.tif 000015