JP3944214B2 - デバイス管理システム、装置および方法 - Google Patents

Description

本発明は、コンピュータネットワークにおけるデバイス管理技術に関する。

ＳＮＭＰ（Simple Network Management Protocol）は、ＬＡＮ（Local Area Network）をはじめとするネットワークを管理するためのプロトコルである。ＳＮＭＰは、現在、ＴＣＰ／ＩＰをベースとしたネットワークに限らず、ＴＣＰ／ＩＰ以外のプロトコルをベースとしたネットワークのネットワーク管理プロトコルとしても幅広く使用されている。

通常、このネットワーク管理においては、ネットワークデバイスを管理するＰＣ（Personal Computer）から、管理対象のネットワークデバイスがもつＭＩＢ（Mnagement Information Base）に、ＳＮＭＰを使用してアクセスすることにより管理が行われる。ここで、ネットワークデバイスを管理するＰＣをマネージャと呼び、管理されるネットワークデバイスをエージェントと呼ぶ。ＭＩＢは、木構造のデータ構造をしており、すべてのノード（オブジェクト）に対してオブジェクトＩＤという一意に識別可能な識別子が割り付けられている。このＭＩＢの構造は、ＳＭＩ (Structure for Management Information) と呼ばれ、ＲＦＣ１１５５「Structure and Identification of Management Information for TCP/IP-based Internets」（非特許文献１）で規定されている。また、ＳＮＭＰについては、ＲＦＣ１１５７「A Simple Network Management Protocol」（非特許文献２）で規定されている。

ＳＮＭＰのバージョンの１つであるＳＮＭＰｖ１では、マネージャとエージェント間の情報交換に、GetRequest、GetNextRequest、SetRequest、GetResponse、Trapの５つのメッセージが使用される。GetRequestメッセージは、マネージャからエージェントへ送信され、オブジェクトＩＤで指定したオブジェクトの値を取得するのに用いられる。GetNextRequestメッセージは、マネージャからエージェントへ送信され、オブジェクトＩＤの順序に従い、オブジェクトＩＤで指定したオブジェクトの次のオブジェクトの値を取得するのに用いられる。SetRequestメッセージは、マネージャからエージェントへ送信され、オブジェクトＩＤで指定されたノードの値を設定するのに用いられる。GetResponseメッセージは、エージェントからマネージャへ送信され、マネージャからの要求（GetRequest、GetNextRequest或いはSetRequest）に対するエージェントからの応答を返すのに用いられる。Trapメッセージは、エージェントからマネージャへ送信され、異常や事象の発生をエージェントからマネージャに能動的に通知するのに用いられる。

ＳＮＭＰメッセージは、バージョン番号、コミュニティ名、ＰＤＵ（Protocol Data Unit）により構成され、そのコーディング方法はＡＳＮ．１（Abstract Syntax Notation 1）のＢＥＲ（Basic Encoding Rule）に従っている。ＳＮＭＰを実装するマネージャおよびエージェントは、各ＳＮＭＰメッセージに対応する、GetRequest-PDU、GetNextRequest-PDU、SetRequest-PDU、GetResponse-PDU、Trap-PDUの５つのＰＤＵをサポートすることが必須となっている。

図３に、Trap-PDUを除く上記各ＰＤＵのデータフォーマットを示す。図３において３０１はＳＮＭＰメッセージである。３０２はＳＮＭＰのバージョン情報が格納される領域であり、例えば、ＳＮＭＰｖ１の場合は値“0”が設定される。３０３はＳＮＭＰの管理対象となるエージェントとそれを管理するマネージャをグループ化したコミュニティの名前（コミュニティ名）を設定する領域である。エージェントは、マネージャから受信したＳＮＭＰメッセージに設定されているコミュニティ名と自分が属するコミュニティ名と比較し、一致する場合のみ当該ＳＮＭＰメッセージを受け付ける。３０４はＰＤＵが格納される領域であり、そのＰＤＵの構造の詳細は３０５に示されている。

なお、ＳＮＭＰメッセージでは、図示しないＰＤＵのヘッダ部にそのメッセージの種別（GetRequest、GetNextRequest、SetRequest）に関する情報が格納される。

３０６はリクエストＩＤが格納される領域であり、マネージャがGetRequest、GetNextRequest、SetRequestの要求を出す際に、個々の要求と、それに対応する応答を識別するために使用する。エージェントでは、マネージャからの要求を受けると、GetResponseを出力する際に、マネージャからの要求に設定されていたリクエストＩＤと同じ値を領域３０６に設定する。これにより、マネージャでは、受信した応答がどの要求に対するものかを判断することが可能になる。３０７はエラーステータスが格納される領域である。エラーステータスとはマネージャが要求したＳＮＭＰメッセージの中にエラーがあったとき、エージェントからマネージャへ送信するGetResponseメッセージでエラーの内容を通知するときに使用するものである。マネージャが送信する要求時のＰＤＵでは常にエラーなし（noError）が領域３０７に設定される。３０８は、要求されたＳＮＭＰメッセージ上で何番目のオブジェクトにエラーのあったのかを示すエラーインデックスが格納される領域である。

３０９はオブジェクト名（３１０、３１２）とその値（３１１、３１３）の対の配列（variable-bindings）が格納される領域である。ＳＮＭＰメッセージでは、図に示すように複数のオブジェクト（オブジェクト名とその値の対）に対する要求を１つのメッセージに格納することができる。なお、要求時のＰＤＵでは値３１１，３１３は一般にＮＵＬＬを示すデータが格納される。

一方、管理対象となるネットワーク上の各種の資源 (プリンタ、複合機、スキャナなど) を効率的に発見し、利用するための方法として、ディレクトリサービスと呼ばれるものが提供されている。ディレクトリサービスとは、言わばネットワークに関する電話帳であり、様々な情報を格納するためのものである。ディレクトリシステムの具体例としては、例えばＲＦＣ１７７７に規定されているＬＤＡＰ（Lightweight Directory Access Protocol）やＮｏｖｅｌｌ社のＮＤＳ (NetWare Directory Service) がある。また、ディレクトリサービスが利用できない環境の場合は、ＳＮＭＰブロードキャストなどを利用してネットワークデバイスを探索することも可能である。

一般的なネットワークデバイス管理システムでは、ＳＮＭＰ／ＭＩＢやディレクトリサービスを用いて、ネットワークに接続されているネットワークデバイスを検索したり、ネットワークデバイスの状態やネットワークデバイスに設定されている各種情報を表示したり変更したりすることができる。また、最近では、サーバＰＣ上で一元管理されたネットワークデバイス管理情報に対して、複数のクライアントＰＣからＷｅｂブラウザ経由でアクセスし、ネットワークに接続されているネットワークデバイスの一覧を表示したり、ネットワークデバイスの状態やネットワークデバイスに設定されている各種情報を表示および／または変更できるＷｅｂアプリケーションの開発が盛んになっている。
特開２００３−３１６６７２号公報 Request for Comments 1155 (Structure and Identification of Management Information for TCP/IP-based Internets)、http://www.ietf.org/rfc/rfc1155.txt Request for Comments 1157 ( A Simple Network Management Protocol (SNMP) )、http://www.ietf.org/rfc/rfc1157.txt

しかし近年になって、上記従来例に示したようなＳＮＭＰ／ＭＩＢにより実現されるネットワークデバイスおよびネットワークデバイス管理システムにおいて、ＳＮＭＰの実装（セキュリティ）に関する脆弱性が指摘されている。

このＳＮＭＰの脆弱性への対策の１つとして、デフォルトのコミュニティ名（以下、デフォルトコミュニティ名という）である“public”や“private”という値を使わずに、他の独自のコミュニティ名（以下、カスタムコミュニティ名という）を使うことが推奨されている。また、特許文献１には、コミュニティ名を動的に生成してセキュリティを向上することが提案されている。

一方、ＳＮＭＰの脆弱性が指摘される以前のネットワークデバイスでは、デフォルトのコミュニティ名でしかアクセスできないような実装になっているものがある。すなわちコミュニティ名を変更可能なものとそうでないものとが混在する場合がある。しかしながら、一般的なネットワークデバイス管理システムでは、管理対象のネットワークデバイスがコミュニティ名の変更が可能かどうかを判断することができなかった。

本発明は上記の課題に鑑みてなされたものであり、デフォルトのコミュニティ名に応答するネットワークデバイスからコミュニティ名を変更可能なデバイスを自動的に検出可能とすることを目的とする。

上記の目的を達成するための本発明の一態様によるデバイス管理装置は以下の構成を備える。すなわち、
ネットワークに接続されたデバイスを所定の管理プロトコルで管理するデバイス管理装置であって、
前記所定の管理プロトコルを用いて、デフォルトのコミュニティ名による第１リクエストに応答するデバイスと、変更されたコミュニティ名による第２リクエストに応答するデバイスを探索する探索手段と、
前記第１リクエストに応答したデバイスのうち、前記第２リクエストに応答したデバイスと同一タイプの製品と判定されたデバイスをコミュニティ名の変更が可能なデバイスとして抽出する抽出手段とを備える。

また、上記の目的を達成するための本発明の他の態様によるデバイス管理システムは以下の構成を備える。すなわち、
ネットワークに接続された複数のデバイスと、該複数のデバイスを所定の管理プロトコルで管理する管理装置とを備えたデバイス管理システムであって、
前記所定の管理プロトコルを用いて、前記複数のデバイスから、デフォルトのコミュニティ名による第１リクエストに応答するデバイスと、変更されたコミュニティ名による第２リクエストに応答するデバイスを探索する探索手段と、
前記第１リクエストに応答したデバイスのうち、前記第２リクエストに応答したデバイスと同一タイプの製品と判定されたデバイスをコミュニティ名の変更が可能なデバイスとして抽出する抽出手段とを備える。

更に、上記の目的を達成するための本発明の他の態様によるデバイス管理方法は、
ネットワークに接続されたデバイスを所定の管理プロトコルで管理するデバイス管理方法であって、
前記所定の管理プロトコルを用いて、デフォルトのコミュニティ名による第１リクエストに応答するデバイスと、変更されたコミュニティ名による第２リクエストに応答するデバイスを探索する探索工程と、
前記第１リクエストに応答したデバイスのうち、前記第２リクエストに応答したデバイスと同一タイプの製品と判定されたデバイスをコミュニティ名の変更が可能なデバイスとして抽出する抽出工程とを備える。

本発明によれば、デフォルトのコミュニティ名に応答するネットワークデバイスからコミュニティ名を変更可能なデバイスを自動的に検出することができる。

以下、添付の図面を用いて本発明の好適な実施形態について説明する。

図１は、本実施形態のネットワークデバイス管理システムが動作可能なネットワークの構成例を示す図である。

図１において、管理対象のネットワークデバイス、ネットワーク管理用のサーバＰＣ、ネットワーク管理用のクライアントＰＣは、すべてＬＡＮ１００に接続されている。１０１ａ〜１０１ｅはカラープリンタ、１０２ａ〜１０２ｅはモノクロプリンタ、１０３ａ〜１０３ｅは複合機 (コピー機能、ファクス機能、プリンタ機能をあわせもつデバイス)、１０４ａ〜１０４ｅはスキャナであり、それぞれネットワークインタフェースカードなどを装着することにより、ネットワークデバイスとしてＬＡＮ１００に接続されている。なお、これらのネットワークデバイスは、本実施形態のネットワークデバイス管理システムで管理可能なネットワークデバイスであり、ディレクトリサービスなどの方法で探索でき、ＳＮＭＰ／ＭＩＢにより情報の取得や設定が可能なものである。

１０５ａ〜１０５ｅはネットワーク接続可能なＰＣ (Personal Computer) である。これらのＰＣにおいては、本実施形態のネットワークデバイス管理ソフトウェアが稼動可能である。また、ＰＣ１０５ａ〜１０５ｅにおいて、本発明に従ったネットワークデバイス管理システムをＷｅｂベースのアプリケーションとして実施してもよく、その場合は次のような形態となる。すなわち、いずれか１つのＰＣ（サーバＰＣ）上でネットワークデバイス管理ソフトウェアを稼動し、他のＰＣ（クライアントＰＣ）からはＷｅｂブラウザ経由で上記サーバＰＣ上で稼動しているネットワーク管理ソフトウェアにアクセスすることによりネットワークデバイス管理システムを利用することが可能になる。このとき、サーバＰＣ上のＷｅｂブラウザから、同じサーバＰＣ上で稼動しているネットワークデバイス管理システムにアクセスするようにしてもよい。

また、図１において、カラープリンタ１０１ａ、ｂ、モノクロプリンタ１０２ａ、複合機１０３ａ、ｂ、およびスキャナ１０４ａ、ｂはコミュニティ名“my_community_a”に属するネットワークデバイスであり、カラープリンタ１０１ｃ、ｄ、モノクロプリンタ１０２ｂ、ｃ、複合機１０３ｃ、ｄ、およびスキャナ１０４ｃはコミュニティ名“my_community_b”に属するネットワークデバイスであり、カラープリンタ１０１ｅ、モノクロプリンタ１０２ｄ、ｅ、複合機１０３ｅ、およびスキャナ１０４ｄ、ｅはコミュニティ名“my_community_c”に属するネットワークデバイスである。これらのネットワークデバイスは、上記のようなカスタムコミュニティ名に応答するようにコミュニティ名の設定が行われている必要がある。しかしながら、コミュニティ名の変更が実施されていないネットワークデバイスや、コミュニティ名の変更ができないネットワークデバイスが接続されている場合もある。そのようなネットワークデバイスの場合には、カスタムコミュニティ名によるアクセスはできず、デフォルトコミュニティ名（“public”や“private”など）でアクセスする必要がある。

図２Ａは、本実施形態のネットワークデバイス管理ソフトウェアが稼動可能なＰＣ（１０５ａ〜ｅ）の構成例を示すブロック図である。

図２Ａにおいて、２００は、ネットワークデバイス管理ソフトウェアが稼動するＰＣであり、図１における１０５ａ〜１０５ｅと同等である。ＰＣ２００は、ＲＯＭ２０２もしくはＨＤ（ハードディスクドライブ）２１１に記憶されているか、ＦＤ（フロッピー(登録商標）ディスクドライブ）２１２、ＣＤ (ＣＤ−ＲＯＭドライブ) ２１３またはＤＶＤ (ＤＶＤ−ＲＯＭドライブ) ２１４より供給されるネットワーク管理ソフトウェアを実行するＣＰＵ２０１を備え、システムバス２０４に接続される各デバイスを総括的に制御する。

２０３はＲＡＭであり、ＣＰＵ２０１のメインメモリ、ワークエリア等として機能する。２０５はＫＢＣ（キーボードコントローラ）で、ＫＢ（キーボード）２０９や不図示のポインティングデバイス等からの入力信号を制御する。２０６はＣＲＴＣ（ＣＲＴコントローラ）で、ＣＲＴ（ＣＲＴディスプレイ）２１０の表示を制御する。２０７はＤＫＣ（ディスクコントローラ）で、ブートプログラム、種々のアプリケーション、編集ファイル、ユーザファイルそしてネットワーク管理ソフトウェア等を記憶するＨＤ２１１、ＦＤ２１２、ＣＤ２１３、ＤＶＤ２１４とのアクセスを制御する。２０８はＮＩＣ（ネットワークインタフェースカード）で、ＬＡＮ１００を介して、他のネットワークデバイスと双方向にデータをやりとりする。なお、後述のすべての説明において、特に断りのない限り、実行の主体はハード上はＣＰＵ２０１であり、ソフトウェア上の制御の主体は、ＨＤ（ハードディスク）２１１にインストールされたネットワークデバイス管理ソフトウェアである。

図２Ｂは、本実施形態のネットワークデバイス管理システムが管理する対象のネットワークデバイス（エージェント）の構成例を示す図である。デバイス２５０は例えばモノクロプリンタ１０２ａ〜１０２ｅを示すものとするが、カラープリンタ１０１ａ〜１０１ｅ、複合機１０３ａ〜１０３ｅ、スキャナ１０４ａ〜１０４ｅにおいてもネットワーク通信に関わる構成は同様である。

図２Ｂにおいて、ＣＰＵ２５１はＲＯＭ２５２に格納されたプログラムに従ってネットワークデバイス２５０の全体の動作を制御する。プリンタエンジン２５４はインターフェース２５３を介してＣＰＵ２５１により制御され、可視画像を記録媒体上に形成する。フラッシュＲＯＭ２５６は電気的にデータの書き換えが可能なＲＯＭであり、ＭＩＢ２６５ａを格納している。ＲＡＭ２５７はＣＰＵ２５１が各種制御を実行するためのワークエリアを提供する。なお、プリンタエンジン２５４のためのビデオメモリとしての機能も含まれる。ＮＢ２５８はネットワークボードであり、ＬＡＮ１００と当該ネットワークデバイス２５０とを接続する。

図４は、本実施形態のネットワークデバイス管理システムにおいて、ネットワーク上に接続されたネットワークデバイスの探索に関連する処理の一例を示すフローチャートである。図４において、「マネージャ」はネットワークデバイス管理システムであり、本実施形態ではＰＣ１０５ａ〜ｅに相当する。また、「エージェント」は管理対象のネットワークデバイスであり、本実施形態では、モノクロプリンタ１０２ａ〜１０２ｅを示すものとするが、カラープリンタ１０１ａ〜１０１ｅ、複合機１０３ａ〜１０３ｅ、スキャナ１０４ａ〜１０４ｅに相当する。

ステップＳ４０１〜Ｓ４０７、ステップＳ４１２〜Ｓ４１８、および、ステップＳ４２３〜Ｓ４２６の処理はマネージャ上で実行される処理である。また、ステップＳ４０８〜Ｓ４１１およびステップＳ４１９〜Ｓ４２２の処理はｉ番目のエージェント上で実行される処理である。ネットワーク上に接続された全てのエージェントの数をＮとすると、ｉが０〜Ｎ−１の間、ステップＳ４０４〜Ｓ４２５の処理が繰り返されることになる。

ステップＳ４０１では、ディレクトリサービスやＳＮＭＰブロードキャストなどを利用してネットワークに接続されたネットワークデバイスを探索し、ステップＳ４０２に進む。ステップＳ４０２では、ステップＳ４０１で探索されたネットワークデバイスを順に参照するためのインデックス変数ｉを“０”に初期化し、ステップＳ４０３に進む。なお、デバイスの探索において、エージェントは所定の順番で登録され、インデックス番号が付されるものとする。

ステップＳ４０３では、インデックス変数ｉの値と、ステップＳ４０１で探索されたネットワークデバイスの数を比較し、インデックス変数ｉの値がネットワークデバイスの数よりも小さかった場合にはステップＳ４０４に進み（ステップＳ４０３：Ｙｅｓ）、それ以外の場合は処理を終了する（ステップＳ４０３：Ｎｏ）。

ステップＳ４０４では、インデックス変数ｉで参照されるネットワークデバイスに対してデフォルトコミュニティ名でGetRequestを送信し、ステップＳ４０５に進む。ステップＳ４０５では、ステップＳ４０４で送信したGetRequestに対する応答を監視するためのタイマを起動し、ステップＳ４０６に進む。ステップＳ４０６では、ステップＳ４０５で起動した応答待ちタイマがタイムアウトしたかどうか検査し、タイムアウトした場合はステップＳ４０７に進む（ステップＳ４０６：Ｙｅｓ）。タイムアウトする前に、ｉ番目のエージェントからGetResponseによる応答を受信した場合は、ステップＳ４０６からステップＳ４１２へ処理を進める。ステップＳ４０７では、ステップＳ４０４において送信したGetRequestのコミュニティ名に対して、ｉ番目のエージェントが応答しなかった旨を記憶（図６で後述するデフォルトコミュニティ名への応答６０５に応答がなかったことを示す「０」を格納）し、ステップＳ４１５に進む。なお、ステップＳ４１４では、デフォルトコミュニティ名に応答したことを示す「１」がデフォルトコミュニティ名への応答６０５に格納される。

尚、図４では応答待ちタイマがタイムアウトするまでにGetResponseを受信できなかった場合は直ちにステップＳ４０７に進むが、ステップＳ４０４によるGetRequestの再送処理を適切な回数繰り返すようにしてもよい。

一方、ｉ番目のエージェントにおいて、ステップＳ４０４で送信されたGetRequestを受信する（ステップＳ４０８）と、ステップＳ４０９〜Ｓ４１１の処理が行われる。ステップＳ４０９では、ｉ番目のエージェントにおいて、ステップＳ４０８で受信したGetRequestを解析し、応答可能なGetRequestであった場合にはステップＳ４１１に進み（ステップＳ４０９：Ｙｅｓ）、応答不可能なGetRequestであった場合にはステップＳ４１０に進む（ステップＳ４１０：Ｎｏ）。ここで、応答可能なGetRequestとは、当該ｉ番目のエージェントが受け付け可能なコミュニティ名で送信されたGetRequestであり、GetRequestによる情報の取得処理そのものに失敗した場合であっても、エラーの内容を示すGetResponseがマネージャに送信されるものである。また、応答不可能なGetRequestとは、当該ｉ番目のエージェントが受け付け不可能なコミュニティ名で送信されたGetRequestであり、このGetRequestについてはエージェントからマネージャにはGetResponseなどのＳＮＭＰメッセージは送信されない。

ステップＳ４１０では、ｉ番目のエージェントにおいて、ステップＳ４０８で受信したGetRequestに関するエラー処理を行い、ステップＳ４０８で受信したGetRequestに関するエージェント内での処理を終了する。ここで実行するエラー処理とは、例えばエージェント内部でカウントしている不正コミュニティ名で送信されたＳＮＭＰメッセージの受信カウンタのカウントアップ処理などが挙げられる。

ステップＳ４１１では、当該ｉ番目のエージェントにおいて、ステップＳ４０８で受信したGetRequestに対する応答としてGetResponseをマネージャに送信し、ステップＳ４０８で受信したGetRequestに関するエージェント内での処理を終了する。

マネージャの処理に戻り、応答待ちタイマのタイムアップまでにｉ番目のエージェントよりGetResponseを受信（ステップＳ４１２）すると、ステップＳ４１３に進む。ステップＳ４１３では、ステップＳ４０５において起動したGetRequestの応答待ちタイマを停止し、ステップＳ４１４に進む。このタイマ停止処理により、ステップＳ４０６において実行されているタイマのタイムアウト監視処理も停止される。ステップＳ４１４では、ステップＳ４０４において送信したGetRequestのコミュニティ名に対して、ｉ番目のエージェントが応答した旨を記憶し、ステップＳ４１５に進む。なお、デフォルトコミュニティ名とカスタムコミュニティ名の両方に応答するようなデバイスもあることを考慮し、本実施形態では、デフォルトコミュニティ名に応答した場合でも、ステップＳ４１５以降の処理を行う。また、ステップＳ４１４においては、デフォルトコミュニティ名を用いたリクエストにより、当該ｉ番目のエージェントから図６のリストに示すような情報（デバイス名６０１、製品名６０２、ネットワークインタフェースボード（ＮＢ）名６０３）を取得してテーブル６００に登録し、ＲＡＭ２０３に記憶する。

尚、ステップＳ４０４で使用するデフォルトコミュニティ名は、例えば、ネットワークデバイス管理システムが予め保持している文字列であり、例えば、“public”や“private”が適用される。また、ステップＳ４０４からステップＳ４１４までのデフォルトコミュニティ名に関する一連の処理は、本実施形態では１つのコミュニティ名についての処理しか記載していないが、複数のコミュニティ名について処理する場合にはＳＮＭＰメッセージに設定するコミュニティ名を変更しながらステップＳ４０４からステップＳ４１４の処理を複数回繰り返すようにしてもよい。例えば、上述のように“public”や“private”の２つのコミュニティ名について応答をチェックする必要があれば、ステップＳ４０４からステップＳ４１４の処理を２回繰り返すことになる。

ステップＳ４１５では、インデックス変数ｉで参照されるネットワークデバイスに対して予め設定されている独自のコミュニティ名（以下、カスタムコミュニティ名と称する）でGetRequestを送信し、ステップＳ４１６に進む。

ステップＳ４１６では、ステップＳ４１５で送信したGetRequestに対する応答を監視するためのタイマを起動し、ステップＳ４１７に進む。ステップＳ４１７では、ステップＳ４１６で起動した応答待ちタイマがタイムアウトしたかどうか検査し、タイムアウトしている場合はステップＳ４１８に進む（ステップＳ４１７：Ｙｅｓ）。尚、応答待ちタイマがタイムアウトした場合に、ステップＳ４１５によるGetRequestの再送処理を適切な回数繰り返すように構成してもよい。

ステップＳ４１８では、前記ステップＳ４１５において送信したGetRequestのコミュニティ名に対して、前記ｉ番目のエージェントが応答しなかった旨を記憶（図６のカスタムコミュニティ名への応答６０６に応答がなかったことを示す「０」を格納）し、ステップＳ４２６に進む。一方、応答待ちタイマのタイムアップ前にｉ番目のエージェントからGetResponseを受信した場合はステップＳ４２３以降の処理が実行される。

また、ｉ番目のエージェントにおいては、マネージャがステップＳ４１５において送信したGetRequestを受信すると（ステップＳ４１９）、処理をステップＳ４２０に進める。ステップＳ４２０では、ｉ番目のエージェントにおいて、ステップＳ４１９で受信したGetRequestを解析し、応答可能なGetRequestであった場合にはステップＳ４２２に進み（ステップＳ４２０：Ｙｅｓ）、応答不可能なGetRequestであった場合にはステップＳ４２１に進む（ステップＳ４２０：Ｎｏ）。ここで、応答可能なGetRequestとは、ｉ番目のエージェントが受け付け可能なコミュニティ名で送信されたGetRequestであり、GetRequestによる情報の取得処理そのものに失敗した場合であっても、エラーの内容を示すGetResponseがマネージャに送信されるものである。また、応答不可能なGetRequestとは、ｉ番目のエージェントが受け付け不可能なコミュニティ名で送信されたGetRequestであり、このGetRequestについてはエージェントからマネージャにはGetResponseなどのＳＮＭＰメッセージは送信されない。

ステップＳ４２１では、前記ｉ番目のエージェントにおいて、前記ステップＳ４１９で受信したGetRequestに関するエラー処理を行い、前記ステップＳ１９で受信したGetRequestに関するエージェント内での処理を終了する。ここで実行するエラー処理とは、例えばエージェント内部でカウントしている不正コミュニティ名で送信されたＳＮＭＰメッセージの受信カウンタのカウントアップ処理などがある。

ステップＳ４２２では、ｉ番目のエージェントにおいて、ステップＳ４１９で受信したGetRequestに対する応答としてGetResponseをマネージャに送信し、ステップＳ４１９で受信したGetRequestに関するエージェント内での処理を終了する。

マネージャは、ステップＳ４２２でｉ番目のエージェントから送信されたGetResponseを受信すると、処理をステップＳ４２４へ進め、ステップＳ４１６において起動したGetRequestの応答待ちタイマを停止する。このタイマ停止処理により、ステップＳ４１７において実行されているタイマのタイムアウト監視処理も停止される。そして、ステップＳ４２５において、ステップＳ４１５において送信したGetRequestのカスタムコミュニティ名に対して、ｉ番目のエージェントが応答した旨を記憶（カスタムコミュニティ名への応答６０５に「１」を格納）し、ステップＳ４２６に進む。なお、ステップＳ４２５においては、カスタムコミュニティ名を用いたリクエストにより、当該ｉ番目のエージェントから図６のリストに示すような情報（デバイス名６０１、製品名６０２、ネットワークインタフェースボード（ＮＢ）名６０３）を取得し、ＲＡＭ２０３に記憶されたテーブル６００に登録する。

尚、ステップＳ４１５で使用するカスタムコミュニティ名は、例えば、図には示さないステップにおいて、ネットワークデバイス管理者が予め設定した文字列であり、例えば、“my_community_a”、“my_community_b”、“my_community_c”などの任意の文字列を使用することができる。また、ステップＳ４１５〜ステップＳ４２５までのネットワークデバイス管理者が指定したコミュニティ名に関する一連の処理は、本実施形態では１つのカスタムコミュニティ名についての処理しか記載していないが、複数のカスタムコミュニティ名について処理する場合にはＳＮＭＰメッセージに設定するコミュニティ名を変更しながらステップＳ４１５からステップＳ４２５の処理を複数回繰り返すことになる。例えば、本実施形態のように、“my_community_a”、“my_community_b”、“my_community_c”の３つのカスタムコミュニティ名について調べる場合は、ステップＳ４１５〜ステップＳ４２５までの処理を３回繰り返すことになる。

ステップＳ４２６では、前記ステップＳ４０１で探索されたネットワークデバイスを参照するためのインデックス変数ｉの値を“１”加算し、ステップＳ４０３に戻る。

尚、図４においてマネージャからエージェントに送信するGetRequestでは、管理対象のエージェントが必ず実装しているＭＩＢオブジェクトの取得要求を行うものとする。本実施形態では、このGetRequestにより後述の図６に示す、デバイス名、製品名、ネットワークインタフェースボード名などのネットワークデバイスの管理に必要な情報を取得するものとする。なお、図６の例では、デバイス名６０１はsysName.0（オブジェクトＩＤは、1.3.6.1.2.1.1.5.0）を、製品名６０２はhrDeviceDescr.1（オブジェクトＩＤは、1.3.6.1.2.1.25.3.2.1.3.1）を、ネットワークインタフェースボード名６０３はifDescr.1（オブジェクトＩＤは、1.3.6.1.2.1.2.2.1.2.1）を、それぞれ取得するものとする。また、ステップＳ４０７、Ｓ４１４、Ｓ４１８、Ｓ４２５において記録するコミュニティ名の応答状況はデフォルトコミュニティへの応答６０５およびカスタムコミュニティ名への応答６０６に反映される。なお、デフォルトコミュニティ名への応答６０５およびカスタムコミュニティ名への応答６０６には、応答がなかった場合は「０」、応答があった場合は「１」が格納される。

また、本実施形態では、上記処理によってデフォルトコミュニティ名が付与されているエージェントにおいて、カスタムコミュニティ名を設定可能であるかどうかを調べる。図５は、本実施形態によるネットワークデバイス管理システムにおいて、デフォルトコミュニティ名に応答するネットワークデバイスを検索し、探索されたネットワークデバイスにおいてコミュニティ名の変更が可能かどうかを検査する処理の一例を示すフローチャートである。

図５において、ステップＳ５０１では、上記図４のフローチャートに示したネットワークデバイスの探索処理（応答するコミュニティ名の検査を含む（単にデバイスを探索するだけならば、ユーザから指定されたコミュニティ名でのみ探索すればよいが、本実施形態ではユーザから指定されたコミュニティ名があった場合でも、デフォルトコミュニティ名での探索が必要になる））を行い、ステップＳ５０２に進む。ステップＳ５０２では、ステップＳ５０１で探索されたネットワークデバイス（エージェント）の情報（例えば、図６に示したような情報）を順に参照するためのインデックス変数ｉを“０”に初期化し、ステップＳ５０３に進む。

ステップＳ５０３では、インデックス変数ｉの値と、ステップＳ５０１において探索されたネットワークデバイスの数を比較し、インデックス変数ｉの値の方が小さい場合にはステップＳ５０４に進み（ステップＳ５０３：Ｙｅｓ）、それ以外の場合は本処理を終了する。尚、後述のステップＳ５０４からステップＳ５１１の処理によりデフォルトコミュニティ名に応答したネットワークデバイスで、かつコミュニティ名の変更が可能なネットワークデバイスが検出された場合は、本処理を終了する際に、図７に示すようなメッセージボックスを表示することで、ネットワークデバイス管理者にコミュニティ名の変更を促すようにしても良い。図７において、７００はコミュニティ名の変更を促すメッセージを表示するウィンドウであり、７０１、７０２は、デフォルトのコミュニティ名に応答し、かつコミュニティ名の変更が可能と判断されたネットワークデバイスの一覧、７０３はウィンドウ７００を閉じるためのボタンである。なお、デフォルトコミュニティ名に応答したネットワークデバイスで、かつコミュニティ名の変更が可能なネットワークデバイスが検出された場合の処理は、上記に限られるものではない。例えば、図７の共有プリンタ０３や１２のコミュニティ名を変更するためのＵＩを自動的に起動したり、コミュニティ名をカスタムコミュニティ名に自動的に変更する等の処理を実行させるようにしてもよい。

ステップＳ５０４からステップＳ５１１までは、インデックス変数ｉにより参照されるネットワークデバイスに関する処理である。ステップＳ５０４では、ｉ番目のネットワークデバイスがデフォルトのコミュニティ名に応答したかどうか判断（例えば、デフォルトコミュニティ名への応答６０５をチェックすることで判断できる）し、デフォルトのコミュニティ名に応答している場合にはステップＳ５０５に進み（ステップＳ５０４：Ｙｅｓ）、それ以外の場合はステップＳ５１２に進む（ステップＳ５０５：Ｎｏ）。例えば、図６に示した例では、共有プリンタ０３、０６〜１０、および、１２がデフォルトのコミュニティ名“public”に応答している。

ステップＳ５０５では、ステップＳ５０４において、デフォルトコミュニティ名に応答すると判断されたｉ番目のネットワークデバイスと同一の製品を検索するためのインデックス変数ｊを“０”に初期化し、ステップＳ５０６に進む。インデックス変数ｊを用いることにより、インデックス変数ｉと同様に、ステップＳ５０１において探索されたネットワークデバイスの情報を参照できるものとする。

ステップＳ５０７〜ステップＳ５０９は、インデックス変数ｉで参照できるネットワークデバイスと、インデックス変数ｊで参照できるネットワークデバイスに関する処理である。ステップＳ５０７〜ステップＳ５０９の処理は、全てのネットワークデバイスについて実行される（ステップＳ５０６、Ｓ５１０）。

ステップＳ５０７ではインデックス変数ｉの値と、インデックス変数ｊの値が等しいかどうか判断し、値が等しくなければステップＳ５０８に進に（ステップＳ５０７：Ｙｅｓ）、値が等しい場合はステップＳ５１１に進む（ステップＳ５０７：Ｎｏ）。インデックス変数ｉの値と、インデックス変数ｊの値が等しい場合、これらの変数で参照できるネットワークデバイスの情報は同一のものを指しているため、同一製品かどうかを判別する必要はないからである。

ステップＳ５０８では、インデックス変数ｉで参照されるネットワークデバイスと、インデックス変数ｊで参照されるネットワークデバイスの情報を比較する。比較の結果、これらのネットワークデバイスが同一製品であると判断された場合はステップＳ５０９に進み（ステップＳ５０８：Ｙｅｓ）、それ以外の場合はステップＳ５１１に進む（ステップＳ５０８：Ｎｏ）。尚、本実施形態では、同一製品かどうかの判断は、図６の製品名６０２とネットワークインタフェースボード名６０３の値が等しいかどうかにより判別するものとする。従って、図６の例では、共有プリンタ０１〜０５、共有プリンタ０６〜１０、共有プリンタ１１〜１５、共有スキャナ０１〜０５が同一製品と判断される。なお、同一製品かどうかの判断を製品名６０２あるいはボード名６０３のどちらか一方のみを用いて行えるシステムであれば、いずれか一方を用いて当該判断を行えばよい。

ステップＳ５０９では、インデックス変数ｊで参照できるネットワークデバイスが、ネットワークデバイス管理者が指定したカスタムコミュニティ名（本実施形態では、“my_community_a”、“my_community_b”、“my_community_c”のいずれか）に応答しているかどうか調べる（例えば、カスタムコミュニティ名への応答６０６をチェックすることで判断できる）。カスタムコミュニティ名に応答していると判定された場合はステップＳ５１０に進み（ステップＳ５０９：Ｙｅｓ）、それ以外の場合はステップＳ５１１に進む（ステップＳ５０９：Ｎｏ）。

例えば、図６に示した例では、共有プリンタ０１、０２、０４、０５、１１、１３〜１５、および共有スキャナ０１〜０５がカスタムコミュニティ名に応答している。本実施形態では、カスタムコミュニティ名に応答しているネットワークデバイスを、コミュニティ名の変更が可能なネットワークデバイスであると判断する。よって、図６の例では、共有プリンタ０１〜０５は、カスタムコミュニティ名に応答しているネットワークデバイス（共有プリンタ０１、０２、０４、０５）があるためコミュニティ名が変更可能なネットワークデバイスと判断することができ、共有プリンタ０６〜０９は、いずれもデフォルトコミュニティ名（“public”）に応答しているため、コミュニティ名の変更ができないネットワークデバイスと判断することができる。

ただし、実際には前記共有プリンタ０６〜０９は、コミュニティ名の変更が可能なネットワークデバイスである可能性もある。本実施形態では、コミュニティ名の変更ができない可能性があるネットワークデバイスについてはデフォルトコミュニティ名の変更を促すことがないようにすることを目的としている。よって、同一製品すべてがコミュニティ名の変更ができるにもかかわらずデフォルトのコミュニティ名のまま運用されている場合については、コミュニティ名の変更ができないネットワークデバイスとして扱っている。

ステップＳ５１１では、インデックス変数ｉで参照できるネットワークデバイスが、デフォルトのコミュニティ名に応答し、かつコミュニティ名の変更が可能なネットワークデバイスであることを記憶し、ステップＳ５１２に進む。この結果は、例えば、図６の管理テーブルの図示しないエントリに記憶される。

ステップＳ５１１では、インデックス変数ｊの値を“１”加算し、ステップＳ５０６に戻る。
ステップＳ５１２では、インデックス変数ｉの値を“１”加算し、ステップＳ５０３に戻る。

以上説明したように、本実施形態のネットワークデバイス管理システムによれば、管理対象ネットワークデバイスの中からデフォルトコミュニティ名に応答するネットワークデバイスが自動的に検出され、更に、これらのネットワークデバイスにおいてコミュニティ名の変更が可能かどうかを自動的に判断される。このため、コミュニティ名の変更が可能でかつデフォルトのコミュニティ名に応答しているネットワークデバイスのみをネットワークデバイス管理者に表示することが可能となる。よって、ネットワークデバイス管理者は、ＳＮＭＰの脆弱性対策の１つであるデフォルトコミュニティ名の変更処理を効率的に行うことが可能になり、ユーザの利便性が向上するという効果がある。

なお、上記実施形態では、同一タイプの製品であるか否かをＳＮＭＰを利用して収集された情報（製品名、ネットワークボード名）に基づいて判定したが、これらの情報は別のプロトコルを介して収集されたものであってもよいし、マニュアルで入力されたものであってもよい。また、管理プロトコルとしては、ＳＮＭＰ以外にも、例えば、ＳＬＰマルチキャストが挙げられる。ＳＬＰマルチキャストにはＳＮＭＰ ｖ１のコミュニティ名に相当するものとしてスコープ名というものがあり、上述した処理を適用できる。

図８は、記憶媒体の一例であるＣＤ−ＲＯＭのメモリマップを示す図である。９９９９はディレクトリ情報を記憶してある領域で、以降のインストールプログラムを記憶してある領域９９９８およびネットワークデバイス管理ソフトウェアを記憶してある領域９９９７の位置を示している。９９９８は、インストールプログラムを記憶してある領域である。９９９７は、ネットワークデバイス管理ソフトウェアを記憶してある領域である。本発明のネットワークデバイス管理ソフトウェアがＰＣ２００にインストールされる際には、まずインストールプログラムを記憶してある領域９９９８に記憶されているインストールプログラムがシステムにロードされ、ＣＰＵ２０１によって実行される。次に、 ＣＰＵ２０１によって実行されるインストールプログラムが、ネットワークデバイス管理ソフトウェアを記憶してある領域９９９７からネットワークデバイス管理ソフトウェアを読み出して、ハードディスク２１１に格納する。

なお、本発明は、複数の機器（例えばホストコンピュータ、インタフェース機器、リーダなど）から構成されるシステムあるいは統合装置に適用しても、ひとつの機器からなる装置に適用してもよい。

また、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、本発明の目的が達成されることは言うまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。プログラムコードを供給するための記憶媒体としては、例えば、フロッピー(登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ，ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。

また、コンピュータが読み出したプログラムコードを実行することによって、前述した実施形態の機能が実現される他、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳなどが実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現され得る。

さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現され得る。

なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体から、そのプログラムをパソコン通信など通信ラインを介して要求者にそのプログラムを配信する場合にも適用できることは言うまでもない。

本実施形態のネットワークデバイス管理システムが動作可能なネットワークの構成例を示す図である。 本実施形態のネットワークデバイス管理システムが稼動可能なＰＣの内部構成を示す図である。 本実施形態のネットワークデバイスの内部構成例を示す図である。 ＳＮＭＰメッセージ（Trapを除く）のフォーマットを示す図である。 本実施形態のネットワークデバイス管理システムにおける、ネットワークデバイスの探索に関連する処理を示すフローチャートである。 本実施形態のネットワークデバイス管理システムにおける、デフォルトのＳＮＭＰコミュニティ名に応答し、かつＳＮＭＰコミュニティ名の変更が可能なネットワークデバイスを検索する処理の一例を示すフローチャートである。 本実施形態のネットワークデバイス管理システムにおいて探索されたネットワークデバイスに関する情報の一例を示す図である。 本実施形態のネットワークデバイス管理システムにおいて、図６に示したネットワークデバイスの探索結果のうち、デフォルトコミュニティ名に応答し、かつコミュニティ名の変更が可能なネットワークデバイスについて、コミュニティ名の変更を促すメッセージの一例を示す図である。 本発明のプログラムが格納された記憶媒体の一例であるＣＤ-ＲＯＭのメモリマップを示す図である。

Claims (13)

1. ネットワークに接続されたデバイスを所定の管理プロトコルで管理するデバイス管理装置であって、
   前記所定の管理プロトコルを用いて、デフォルトのコミュニティ名による第１リクエストに応答するデバイスと、変更されたコミュニティ名による第２リクエストに応答するデバイスを探索する探索手段と、
   前記第１リクエストに応答したデバイスのうち、前記第２リクエストに応答したデバイスと同一タイプの製品と判定されたデバイスをコミュニティ名の変更が可能なデバイスとして抽出する抽出手段とを備えることを特徴とするデバイス管理装置。
2. 前記抽出手段で抽出されたデバイスをコミュニティ名の変更が可能なデバイスとして提示する提示手段を更に備えることを特徴とする請求項１に記載のデバイス管理装置。
3. 前記所定の管理プロトコルはＳＮＭＰであることを特徴とする請求項１に記載のデバイス管理装置。
4. 前記抽出手段は、前記所定の管理プロトコルによって各デバイスから収集した情報に基づいてデバイスの抽出を行うことを特徴とする請求項１に記載のデバイス管理装置。
5. 前記抽出手段は、前記第１または第２リクエストに応答したデバイスから取得される製品名に基づいて、デバイスの抽出を行うことを特徴とする請求項１乃至４のいずれかに記載のデバイス管理装置。
6. ネットワークに接続された複数のデバイスと、該複数のデバイスを所定の管理プロトコルで管理する管理装置とを備えたデバイス管理システムであって、
   前記所定の管理プロトコルを用いて、前記複数のデバイスから、デフォルトのコミュニティ名による第１リクエストに応答するデバイスと、変更されたコミュニティ名による第２リクエストに応答するデバイスを探索する探索手段と、
   前記第１リクエストに応答したデバイスのうち、前記第２リクエストに応答したデバイスと同一タイプの製品と判定されたデバイスをコミュニティ名の変更が可能なデバイスとして抽出する抽出手段とを備えることを特徴とするデバイス管理システム。
7. ネットワークに接続されたデバイスを所定の管理プロトコルで管理するデバイス管理方法であって、
   前記所定の管理プロトコルを用いて、デフォルトのコミュニティ名による第１リクエストに応答するデバイスと、変更されたコミュニティ名による第２リクエストに応答するデバイスを探索する探索工程と、
   前記第１リクエストに応答したデバイスのうち、前記第２リクエストに応答したデバイスと同一タイプの製品と判定されたデバイスをコミュニティ名の変更が可能なデバイスとして抽出する抽出工程とを備えることを特徴とするデバイス管理方法。
8. 前記抽出工程で抽出されたデバイスをコミュニティ名の変更が可能なデバイスとして提示する提示工程を更に備えることを特徴とする請求項７に記載のデバイス管理方法。
9. 前記所定の管理プロトコルはＳＮＭＰであることを特徴とする請求項７に記載のデバイス管理方法。
10. 前記抽出工程は、前記所定の管理プロトコルによって各デバイスから収集した情報に基づいてデバイスの抽出を行うことを特徴とする請求項７に記載のデバイス管理方法。
11. 前記抽出工程は、前記第１または第２リクエストに応答したデバイスから取得される製品名に基づいて、デバイスの抽出を行うことを特徴とする請求項７乃至１０のいずれかに記載のデバイス管理方法。
12. 請求項７乃至１１のいずれかに記載のデバイス管理方法をコンピュータに実行させるための制御プログラム。
13. 請求項７乃至１１のいずれかに記載のデバイス管理方法をコンピュータに実行させるための制御プログラムを格納した記憶媒体。

Images