(57)【要約】シグネチャルールローディング方法および対応するネットワークデバイスを開示している。該方法の一例では、まず、ネットワークデバイスはクラウドサーバーによって送信されたシグネチャルールライブラリを受信し、前記シグネチャルールライブラリが少なくとも一つのシグネチャルールを含み、各シグネチャルールが対応するデバイスタイプ構成情報に関連している。各シグネチャルールに対し、該ネットワークデバイスは該シグネチャルールに関連するデバイスタイプ構成情報が前記ネットワークデバイスのローカルデバイスタイプ構成情報にマッチするかどうかを判断する。上記判断結果がＹＥＳである場合、前記ネットワークデバイスは前記シグネチャルールをロードする。【選択図】図１
2019510410.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークデバイスは、クラウドサーバーによって送信されたシグネチャルールライブラリを受信し、前記シグネチャルールライブラリが少なくとも一つのシグネチャルールを含み、各シグネチャルールが対応するデバイスタイプ構成情報に関連していることと、
各シグネチャルールに対し、前記ネットワークデバイスは、該シグネチャルールに関連するデバイスタイプ構成情報が前記ネットワークデバイスのローカルデバイスタイプ構成情報にマッチするかどうかを判断することと、
関連するデバイスタイプ構成情報が前記ネットワークデバイスのローカルデバイスタイプ構成情報にマッチするシグネチャルールに対し、前記ネットワークデバイスは、該シグネチャルールをロードすることと、
を含むシグネチャルールローディング方法。
【請求項２】
前記クラウドサーバーによって送信された前記シグネチャルールライブラリを受信することは、
前記ネットワークデバイスは、ソフトウェア定義ネットワークＳＤＮコントローラによって前記クラウドサーバーから送信された前記シグネチャルールライブラリを受信すること、
を含む請求項１に記載のシグネチャルールローディング方法。
【請求項３】
前記クラウドサーバーから前記シグネチャルールライブラリを送信するように、前記ネットワークデバイスは、前記クラウドサーバーにシグネチャルールアップグレードの要求を送信すること、
をさらに含む請求項１に記載のシグネチャルールローディング方法。
【請求項４】
前記デバイスタイプ構成情報がタイプ−長さ−値とのＴＬＶフォーマットで記録される
請求項１に記載のシグネチャルールローディング方法。
【請求項５】
前記の該シグネチャルールをロードすることは、
前記ネットワークデバイスは、該シグネチャルールのバーション番号が前記ネットワークデバイスにロードされたシグネチャルールのバーション番号より高いかどうかを判断することと、
上記判断結果がＹＥＳである場合は、前記ネットワークデバイスは該シグネチャルールをロードすることと、
を含む請求項１に記載のシグネチャルールローディング方法。
【請求項６】
関連するデバイスタイプ構成情報が前記ネットワークデバイスのローカルデバイスタイプ構成情報にマッチしないシグネチャルールに対し、前記ネットワークデバイスは該シグネチャルールを破棄すること、
をさらに含む請求項１に記載のシグネチャルールローディング方法。
【請求項７】
プロセッサーを含むネットワークデバイスであって、
機器可読記憶媒体に格納されるシグネチャルールローディングの制御ロジックに対応する機械実行可能なコマンドを呼び出すことによって、前記プロセッサーに、
クラウドサーバーによって送信されたシグネチャルールライブラリを受信し、前記シグネチャルールライブラリが少なくとも一つのシグネチャルールを含み、各シグネチャルールが対応するデバイスタイプ構成情報に関連していることと、
各シグネチャルールに対し、該シグネチャルールに関連するデバイスタイプ構成情報が前記ネットワークデバイスのローカルデバイスタイプ構成情報にマッチするかどうかを判断することと、
関連するデバイスタイプ構成情報が前記ネットワークデバイスのローカルデバイスタイプ構成情報にマッチするシグネチャルールに対し、該シグネチャルールを前記ネットワークデバイスにロードすることと、
を実行させるネットワークデバイス。
【請求項８】
前記クラウドサーバーによって送信された前記シグネチャルールライブラリを受信する時に、前記デバイス実行可能なコマンドは、前記プロセッサーに、
ソフトウェア定義ネットワークＳＤＮコントローラによって前記クラウドサーバーから送信された前記シグネチャルールライブラリを受信すること、
をさらに実行させる請求項７に記載のネットワークデバイス。
【請求項９】
前記デバイス実行可能なコマンドは、前記プロセッサーに、
前記クラウドサーバーから前記シグネチャルールライブラリを送信するように、前記クラウドサーバーにシグネチャルールアップグレード要求を送信すること、
をさらに実行させる請求項７に記載のネットワークデバイス。
【請求項１０】
前記シグネチャルールに対応するデバイスタイプ構成情報がタイプ−長さ−値とのＴＬＶフォーマットで記録される、
請求項７に記載のネットワークデバイス。
【請求項１１】
該シグネチャルールを前記ネットワークデバイスにロードする時に、前記デバイス実行可能なコマンドは、前記プロセッサーに、
該シグネチャルールのバーション番号が前記ネットワークデバイスにロードされたシグネチャルールのバーション番号より高いかどうかを判断することと、
上記判断結果がＹＥＳである場合、該シグネチャルールを前記ネットワークデバイスにロードすることと、
をさらに実行させる請求項７に記載のネットワークデバイス。
【請求項１２】
前記デバイス実行可能なコマンドは、前記プロセッサーに、
関連するデバイスタイプ構成情報が前記ネットワークデバイスのローカルデバイスタイプ構成情報にマッチしないシグネチャルールに対し、前記ネットワークデバイスは該シグネチャルールを破棄すること、
をさらに実行させる請求項７に記載のネットワークデバイス。
【発明の詳細な説明】
【関連出願の相互参照】
【０００１】
本願は、２０１６年３月２日に出願した出願番号が２０１６１０１１６５４９．６である中国特許出願に基づいて優先権を主張する。その全記載をここに援用する。
【背景技術】
【０００２】
セキュリティ攻防技術の発展に伴い、ハッカーの攻撃手段が増えている。より多くの攻撃から防御できるために、デバイスに搭載されるシグネチャライブラリの規模も拡大している。そのうち、シグネチャライブラリに複数のシグネチャルールが含まれている。シグネチャルール発行システムに、すべてのシグネチャルールを含む一つの最大規模のシグネチャライブラリと各種のシグネチャサブライブラリとがある。デバイスのタイプ（例えば、ルーター、スイッチおよび無線アクセスコントローラ（ＡＣ））およびモデル（例えば、ハイエンド、ミドルレンジおよびローエンドの構成など）に応じて最大規模のシグネチャライブラリをテーラーすることにより、前記シグネチャサブライブラリを得ることができる。このようにして、前記シグネチャサブライブラリはデバイスに対応するシグネチャルールを含んでおり、クラウドサーバーに格納されることができる。
【０００３】
仮想化シナリオでは、シグネチャルール発行システムは、ソフトウェア定義型ネットワーク（Ｓｏｆｔｗａｒｅ  Ｄｅｆｉｎｅ  Ｎｅｔｗｏｒｋ、ＳＤＮ）コントローラによってシグネチャサブライブラリを発行することで、シグネチャルールの発行を実現することができる。例えば、シグネチャルールの発行を行う時に、ＳＤＮコントローラは最初にその管理範囲内のすべての仮想デバイスのタイプおよびモデルを検知してから、同じタイプのデバイスに対して、検知された該タイプの仮想デバイスの最もローエンドのモデルの構成仕様に従って、管理範囲内のすべての該タイプの仮想デバイスにシグネチャサブライブラリを発行する。
【図面の簡単な説明】
【０００４】
【図１】図１は本開示の一例で提供されるシグネチャルールローディング方法のフローチャートである。
【図２】図２は本開示のもう一例で提供されるシグネチャルールローディング方法のフローチャートである。
【図３】図３は本開示のもう一例で提供されるシグネチャルールローディング方法のフローチャートである。
【図４】図４は本開示のもう一例で提供されるシグネチャルールローディング方法のフローチャートである。
【図５】図５は本開示の一例で提供されるネットワークデバイスのハードウェア構造の模式図である。
【図６】図６は本開示の一例で提供されるシグネチャルールローディング制御ロジックに基づく機能モジュールのブロック図。
【図７】図７は本開示のもう一例で提供されるシグネチャルールローディング制御ロジックに基づく機能モジュールのブロック図。
【図８】図８は本開示のもう一例で提供されるシグネチャルールローディング制御ロジックに基づく機能モジュールのブロック図。
【図９】図９は本開示のもう一例で提供されるシグネチャルールローディング制御ロジックに基づく機能モジュールのブロック図。
【発明を実施するための形態】
【０００５】
以下、本開示における図面を参照し、本開示の例に係る技術案を明確かつ完全に説明する。ここにて説明する例は本願の全ての例ではなく、単に一部の例であることは明らかである。本開示における例に基づいて、当業者による創造的な働きがない場合に得られた他のすべての例は、本開示の特許請求の範囲にある。
【０００６】
本開示はシグネチャルールローディング方法を提供する。当該方法により、ネットワークデバイスが自身のニーズに応じてシグネチャルールを自動的に選別してロードすることができ、該ネットワークデバイスにロードされたシグネチャルールの全てがローカルデバイスタイプ構成情報にマッチすることを保証できる。従って、該ネットワークデバイスはそのリソースを効率的に使用することができ、そしてその機能を十分に発揮することができる。
【０００７】
以下では、まず、本開示の一例で提供されるシグネチャルールローディング方法について説明する。
【０００８】
リアルのシナリオでは、該シグネチャルールローディング方法はネットワークデバイスに対してシグネチャルールを発行する。例えば、該ネットワークデバイスは自身の構成ニーズに応じて、対応するシグネチャルールを選別してロードする。そのうち、該ネットワークデバイスは、スイッチや、ルーターまたは無線ＡＣなどとすることができる。
【０００９】
仮想化シナリオでは、該シグネチャルールローディング方法は、ネットワークデバイスにおいて実現される仮想デバイスに適用することができる。例えば、該仮想デバイスは仮想ルーター、仮想ファイアウォールなどとすることができる。
【００１０】
また、該シグネチャルールローディング方法はクライアントによって実行してもよく、プラグインによって実行してもよい。
【００１１】
該シグネチャルールローディング方法では、クラウドサーバに格納されたシグネチャルールライブラリに含まれるシグネチャルールのそれぞれに、関連するデバイスタイプ構成情報をマークしている。そのうち、該デバイスタイプ構成情報は、デバイスタイプとモデル（例えば、ハイエンドルーター、ローエンド無線ＡＣ、およびミドルレンジスイッチなど）とすることができる。他の例では、該デバイスタイプ構成情報はデバイスにより保護される対象の構成情報（以下、被保護対象構成情報という）とすることもできる。該対象はＰＣ、サーバーなどとすることができる。該被保護対象構成情報は、例えば、該被保護対象のオペレーティングシステムのタイプ（例えばＷｉｎｄｏｗｓ、Ｌｉｎｕｘ、およびＭａｃ  ＯＳなど）とすることができる。このようにして、ネットワークデバイスは、そのデバイスタイプ構成情報に応じて、クラウドサーバーから送信されたシグネチャルールライブラリから自身に対応するシグネチャルールを自動的に選別する。上記方法は、異なるデバイスタイプ構成のネットワークデバイスに対していろいろなシグネチャサブライブラリをテーラーしてクラウドサーバーに格納し、そしてシグネチャサブライブラリを発行する方式でシグネチャルールを発行するような技術案に比べて、クラウドサーバーの記憶スペースを効率的に節約することができ、クラウドサーバーのスペース管理の複雑さも低減することができる。
【００１２】
図１に示すように、該シグネチャルールローディング方法は以下のステップＳ１０１ーＳ１０３を含むことができる。
【００１３】
ステップＳ１０１において、ネットワークデバイスはクラウドサーバーによって送信されたシグネチャルールライブラリを受信する。そのうち、該シグネチャルールライブラリは少なくとも一つのシグネチャルールを含んでおり、且つ各シグネチャルールは、対応するデバイスタイプ構成情報に関連する。
【００１４】
該ネットワークデバイスは、該クラウドサーバによって送信されたシグネチャルールライブラリを受信する前に、シグネチャルールのアップグレード処理を要求するようにクラウドサーバにアップグレード要求情報を自発的に送信してもよい。或いは、仮想化シナリオでは、ネットワークデバイスがシグネチャルールのロード設定を適時に行うことができるように、またはネットワークデバイス自身にロードされているシグネチャルールをアップグレードして改善することができるように、該クラウドサーバーは、仮想デバイスである該ネットワークデバイスにシグネチャルールライブラリを自発的に発行することができる。
【００１５】
そして、タイプおよび構成の異なる様々なネットワークデバイスはシグネチャルールに対するロード設定能力が異なることがあることに鑑みて、この例において、クラウドサーバーによって送信されるシグネチャルールライブラリは少なくとも一つのシグネチャルールを含んでおり、該少なくとも一つのシグネチャルールのそれぞれは、対応するデバイスタイプ構成情報に関連する。このようにして、該シグネチャルールライブラリを受信したネットワークデバイスは、前記デバイスタイプ構成情報に応じてシグネチャルールを自動的に選別してロードすることができる。
【００１６】
ステップＳ１０２において、シグネチャルールのそれぞれに対し、該ネットワークデバイスは該シグネチャルールに関連するデバイスタイプ構成情報が該ネットワークデバイスのローカルデバイスタイプ構成情報にマッチするかどうかを判断する。その結果がＹＥＳである場合、ステップＳ１０３に進み、そうでない場合、該シグネチャルールを破棄する。
【００１７】
該ネットワークデバイスは、クラウドサーバーによって送信されたシグネチャルールライブラリを受信することにより、該シグネチャルールライブラリに含まれるシグネチャルールのそれぞれに対し、該シグネチャルールに関連するデバイスタイプ構成情報を解析するとともに、該シグネチャルールに関連するデバイスタイプ構成情報が該ネットワークデバイスのローカルデバイスタイプ構成情報にマッチするかどうかを判断する。該シグネチャルールに関連するデバイスタイプ構成情報が該ネットワークデバイスのローカルデバイスタイプ構成情報にマッチすると判断した場合、該ネットワークデバイスは、該シグネチャルールに対するロード処理を継続する。そのうち、シグネチャルールに関連するデバイスタイプ構成情報を解析するには、当業者に一般的に知られている任意の技術を採用することができるので、ここで省略する。
【００１８】
仮想化シナリオでは、仮想デバイスも、シグネチャルールのそれぞれに対し、該シグネチャルールに関連するデバイスタイプ構成情報がローカルデバイスタイプ構成情報にマッチするかどうかを判断する。そして、該シグネチャルールに関連するデバイスタイプ構成情報が該仮想デバイスのローカルデバイスタイプ構成情報にマッチすると判断した場合、該仮想デバイスは、該シグネチャルールに対するロード処理を継続する。
【００１９】
ステップＳ１０３において、該ネットワークデバイスは、関連するデバイスタイプ構成情報がローカルデバイスタイプ構成情報にマッチするシグネチャルールをロードする。
【００２０】
該ネットワークデバイスはローカルデバイスタイプ構成情報にマッチするシグネチャルールを確定した後、該シグネチャルールに対するロード操作を実行する。そして、該ネットワークデバイスは、該シグネチャルールに対するロードが完了した後、該シグネチャルールに対応する機能を発揮する。そのうち、シグネチャルールに対してロードするには、当業者に一般的に知られている任意の技術を採用することができるので、ここで省略する。また、クラウドサーバーにとって、もちろん該シグネチャルールが既に発行され有効になった。
【００２１】
一例では、シグネチャルール発行システムにおいて、クラウドサーバーによって実行される動作は、該シグネチャルールライブラリを発行することであるが、ネットワークデバイスによって実行される動作は、該シグネチャルールライブラリにあるマッチするシグネチャルールを選別してロードすることである。
【００２２】
この例を適用する時に、まず、ネットワークデバイスはクラウドサーバーによって送信されたシグネチャルールライブラリを受信する。該シグネチャルールライブラリは、少なくとも一つのシグネチャルールを含んでおり、且つ各シグネチャルールは、対応するデバイスタイプ構成情報に関連する。その後、該ネットワークデバイスは、シグネチャルールのそれぞれに対して該シグネチャルールに関連するデバイスタイプ構成情報が該ネットワークデバイスのローカルデバイスタイプ構成情報にマッチするかどうかを判断する。その結果がYESである場合は、該シグネチャルールをロードする。クラウドサーバーから発行されたのが、既にテーラーされ、一部のシグネチャルールを含むシグネチャサブライブラリであると異なり、この例では、クラウドサーバーによって格納及び送信されるのがいずれも全てのシグネチャルールを含む最大規模のシグネチャルールライブラリであるため、クラウドサーバーの記憶スペースを効率的に節約することができる。また、該シグネチャルールライブラリに含まれる各シグネチャルールが対応するデバイスタイプ構成情報に関連することによって、ネットワークデバイスは自身のニーズに応じて（例えば、デバイスタイプ構成情報）該シグネチャルールライブラリにおけるシグネチャルールを自動的に選別してロードすることができるので、ネットワークデバイスにロードされたシグネチャルールの全てが該ネットワークデバイスのローカルデバイスタイプ構成情報にマッチすることが保証でき、ネットワークデバイスのリソースを効率的に利用してネットワークデバイスの機能を十分に発揮することができる。
【００２３】
一例では、仮想化シナリオにおいて、クラウドサーバーは、その管理範囲内の仮想デバイスにシグネチャルールライブラリを自発的に発行することにより、該仮想デバイスがシグネチャルールライブラリに含まれるシグネチャサーバーをロードする。例えば、該仮想化シナリオにおいて、クラウドサーバによって送信されたシグネチャルールライブラリを受信する（Ｓ１０１）ことは、ＳＤＮコントローラによってクラウドサーバから送信されたシグネチャルールライブラリを受信することを含むことができる。
【００２４】
この例では、該ＳＤＮコントローラは、発行されるシグネチャルールライブラリに含まれるシグネチャルールと、仮想デバイスとの対応関係を知らなくても良い。該仮想デバイスは、該シグネチャルールライブラリに含まれるシグネチャルールのそれぞれに関連するデバイスタイプ構成情報に応じて、必要なシグネチャルールを自動的に選別してロードすることができる。この例で提供されるシグネチャルールローディング方法を適用することにより、ＳＤＮコントローラは仮想デバイスのタイプとモデルを判断しなくてもよいので、ＳＤＮコントローラの負荷を低減することができ、そして仮想デバイスのシグネチャルールをロードする効率を向上することができる。もちろん、クラウドサーバーがＳＤＮコントローラによってシグネチャルールライブラリを定期的に、または不定期に送信できる。例えば、クラウドサーバーは、ローカルに格納されるシグネチャルールが変化したことを検出すると、その管理範囲内の仮想デバイスにシグネチャルールライブラリを自発的に発行する。
【００２５】
また、ネットワークデバイスはクラウドサーバーにシグネチャルールを自発的に要求する。例えば、図２に示すように、クラウドサーバーによって送信された前記シグネチャルールライブラリを受信する（Ｓ１０１）前に、この例で提供されるシグネチャルールローディング方法は、ステップＳ２０１を含んでもよい。即ち、ステップＳ２０１において、該ネットワークデバイスは、クラウドサーバーにシグネチャルールライブラリについてのアップグレードの要求を送信する。
【００２６】
例えば、ネットワークデバイスは、自身のリソースが十分でありながら、ロードされたシグネチャルールが該ネットワークデバイスの担う機能を満たすことができない場合、クラウドサーバーにシグネチャルールを自発的に要求し、対応するシグネチャルールを取得してロードすることにより、シグネチャルールに対するアップグレードを実現する。または、ネットワークデバイスは、まだシグネチャルールをロードしたことがないが、シグネチャルールをロードする必要がある場合、クラウドサーバーにシグネチャルールを要求し、対応するシグネチャルールを取得してロードしてもよい。
【００２７】
さらに、ステップＳ１０１〜Ｓ１０３とステップＳ２０１とを組み合わせて、ネットワークデバイスがクラウドサーバーにシグネチャルールを自発的に要求した後に、クラウドサーバーは、該ネットワークデバイスにシグネチャルールを発行することができる。このようにして、該ネットワークデバイスは、該シグネチャルールライブラリを受信した後、該シグネチャルールライブラリにおけるシグネチャルールのそれぞれに関連するデバイスタイプ構成情報に応じて、自身のニーズに合ったシグネチャルールを自動的に選別してロードできる。
【００２８】
このようにして、ユーザが色々な種類のシグネチャサブライブラリからネットワークデバイスのニーズを満たすシグネチャサブライブラリを選別する必要がなくなるので、該クラウドサーバーにおけるシグネチャサブライブラリのタイプが知らないことでロードするシグネチャサブライブラリを誤って選択することを有効に回避することができる。例えば、ローエンド構成のネットワークデバイスがユーザの誤った選択によってハイエンド構成に対応するシグネチャサブライブラリをロードしたことにより、該ローエンド構成のネットワークデバイスがあまりにも多くのシグネチャルールをロードしてしまい、リソースを使い果たすことがある。または、ハイエンド構成のネットワークデバイスがユーザの誤った選択によってローエンド構成に対応するシグネチャサブライブラリをロードしたことにより、該ハイエンド構成のネットワークデバイスの機能の発揮が制限されることがある。また、この例においてシグネチャルールに対する選別は完全に自動であり、ユーザの関与が不要であるので、ユーザの時間と労力を節約することができる。
【００２９】
さらに、シグネチャルールのそれぞれに関連するデバイスタイプ構成情報は、タイプ−長さ−値（Ｔｙｐｅ−ｌｅｎｇｔｈ−ｖａｌｕｅ、TLV）のフォーマットで記録することができる。該ＴＬＶは該シグネチャルールに追加されてもよい。例えば、シグネチャルールライブラリに格納されるシグネチャルールのそれぞれの具体的な内容は、ＴＬＶフォーマットでシグネチャルールのそれぞれを記録する。そのうち、ＴＬＶはＴｙｐｅタイプ・Ｌｅｎｇｔｈ長さ・Ｖａｌｕｅ値で表す可変フォーマットである。ＴｙｐｅとＬｅｎｇｔｈの長さは固定可能であり、たとえば２または４バイト（ｂｙｔｅ）でもよい。Ｖａｌｕｅの長さはＬｅｎｇｔｈで指定できる。シグネチャルールライブラリに含まれる内容の一致性を保証するために、シグネチャルールのそれぞれに関連するデバイスタイプ構成情報はＴＬＶフォーマットで記録してもよい。このようにして、ネットワークデバイスにおいて該ＴＬＶフォーマットで記録されるデバイスタイプ構成情報に対する解析処理を追加すればよい。
【００３０】
一例では、Ｔｙｐｅフィールドは、該Ｔｙｐｅフィールドが所在しているＴＬＶを識別するためものであり、デバイスタイプ構成情報を示している。たとえば、該Ｔｙｐｅフィールドは、具体的に「ｄｅｖｉｃｅ」として設定され、該デバイスタイプ構成情報の具体的な内容はＶａｌｕｅフィールドに記録されてよい。
【００３１】
例えば、デバイスタイプ構成情報がデバイスタイプとモデルである場合、Ｖａｌｕｅの具体的な値は表１に示したものを参照してもよい。
【００３２】
【表１】
2019510410.tif 000003
【００３３】
一例として、シグネチャルールライブラリにシグネチャルール１００００１を含んでおり、シグネチャルール１００００１に関連するデバイスタイプ構成情報の値が「ａｄ」であるとすると、該シグネチャルール１００００１をハイエンド構成のセキュリティデバイスとハイエンド構成のルーターに発行しても良いことを意味する。このようにして、あるハイエンド構成のセキュリティデバイスは、関連するデバイスタイプ構成情報が「ａｄ」であるシグネチャルール１００００１を受信したら、該デバイスタイプ構成情報「ａｄ」にハイエンド構成セキュリティデバイスに対応する「ａ」が含まれているため、該ハイエンド配置のセキュリティデバイスは、該シグネチャルール１００００１に関連するデバイスタイプ構成情報が該ハイエンド構成のセキュリティデバイスのローカルデバイスタイプ構成情報にマッチすると判断でき、該ハイエンド構成のセキュリティデバイスが該シグネチャルール１００００１をロードする。
【００３４】
同様に、ハイエンド構成のルーターも、シグネチャルール１００００１に関連するデバイスタイプ構成情報「ａｄ」に基づいて、該デバイスタイプ構成情報がローカルデバイスタイプ構成情報である「ｄ」にマッチすると判断したと、シグネチャルール１００００１をロードし続ける。
【００３５】
一方、ハイエンド構成のセキュリティデバイスとハイエンド構成のルーター以外の他のデバイスは、シグネチャルール１００００１を受信したら該シグネチャルール１００００１を破棄するので、該シグネチャルール１００００１をロードすることはない。
【００３６】
別の例として、デバイスタイプ構成情報はデバイスの保護対象の構成情報である場合、Ｖａｌｕｅの具体的な値については、表２に示したものを参照してもよい。
【表２】
2019510410.tif 000004
【００３７】
一例として、シグネチャルールライブラリにシグネチャルール１００００２を含んでおり、デバイスの保護対象の構成情報の値が「ＡＢ」であるとすると、該シグネチャルール１００００２を保護対象のシステムタイプがＷｉｎｄｏｗｓまたはＬｉｎｕｘであるデバイスに発行しても良いことを意味する。このようにして、保護対象のシステムタイプがＷｉｎｄｏｗｓまたＬｉｎｕｘであるデバイスは、関連する保護対象構成情報が「ＡＢ」であるシグネチャルール１００００２を受信したら、該保護対象のシステムタイプ「ＡＢ」にＷｉｎｄｏｗｓに対応する「Ａ」およびＬｉｎｕｘに対応する「Ｂ」が含まれているため、保護対象のシステムタイプがＷｉｎｄｏｗｓまたはＬｉｎｕｘであるデバイスは、該シグネチャルール１００００２に関連する保護対象構成情報が該デバイスのローカル保護対象構成情報にマッチすると判断でき、該デバイスが該シグネチャルール１００００２をロードする。
【００３８】
一方、保護対象のシステムがＷｉｎｄｏｗｓまたはＬｉｎｕｘ以外の他のデバイスは、シグネチャルール１００００２を受信したら該シグネチャルール１００００２を破棄するので、該シグネチャルール１００００２をロードすることはない。
【００３９】
もちろん、デバイスタイプ構成情報に対応するＶａｌｕｅの値の設定は、他の文字識別子を利用してもよく、クラウドサーバーによって発行されるシグネチャルールライブラリに含まれるシグネチャルールのそれぞれに関連するデバイスタイプ構成情報が、シグネチャルールをロードする必要があるネットワークデバイスのローカルデバイスタイプ構成情報の文字識別子にマッチできると確保すればよい。
【００４０】
もちろん、クラウドサーバーに格納されるシグネチャルールライブラリにおけるシグネチャルールは一般的にアップグレードと改善を継続しているものである。したがって、シグネチャルールに対する管理を容易にするために、該シグネチャルールのそれぞれにバーション番号を持たせることにより、ネットワークデバイスは該シグネチャルールのバーション番号に基づいてシグネチャルールのアップグレードを行うかどうかを確定することができる。例えば、図３に示すように、該シグネチャルールをロードする（Ｓ１０３）前に、この例で提供されるシグネチャルールローディング方法はステップＳ３０１をさらに含んでもよい。即ち、該ネットワークデバイスは、ロードしようとする該シグネチャルールのバーション番号が該ネットワークデバイスにロードされたシグネチャルールのバーション番号より高いかどうかを判断する。そして、判断結果がＹＥＳである場合は、該ネットワークデバイスはステップＳ１０３に進む。
【００４１】
ネットワークデバイスは、ロードされる該シグネチャルールに関連するデバイスタイプ構成情報が該ネットワークデバイスのローカルデバイスタイプ構成情報にマッチすると確定した後、ロードされる該シグネチャルールのバーション番号がネットワークデバイスにロードされたシグネチャルールのバーション番号より高いかどうかをさらに判断する。そして、ロードされる該シグネチャルールのバーション番号がネットワークデバイスにロードされたシグネチャルールのバーション番号より高いと判断した場合、該ネットワークデバイスはシグネチャルールをアップグレードする必要があると確定できるので、シグネチャルールに対するロード処理を継続する。
【００４２】
クラウドサーバーによって発行されるのは、該クラウドサーバーに格納されているすべてのシグネチャルールを含んでいる最大規模のシグネチャルールライブラリであり、ネットワークデバイスは、発行される該シグネチャルールライブラリの全部を受信する。そして、ネットワークデバイスがシグネチャルールのそれぞれに関連するデバイスタイプ構成情報に応じて、ローカルデバイスタイプ構成情報にマッチするシグネチャルールを自動的に選別してロードするとともに、ローカルデバイスタイプ構成情報にマッチしないシグネチャルールを破棄する。例えば、図４に示すように、この例で提供されるシグネチャルールローディング方法はステップＳ４０１をさらに含んでもよい。即ち、該シグネチャルールに関連するデバイスタイプ構成情報が該ネットワークデバイスのローカルデバイスタイプ構成情報にマッチしない場合、該ネットワークデバイスは該シグネチャルールを破棄する。そのうち、シグネチャルールを破棄することについて、当業者に周知の任意の技術を採用することができるので、ここで省略する。
【００４３】
上記の方法の例に対応して、本開示はネットワークデバイスも提供する。図５に示すように、該ネットワークデバイスはプロセッサー５１と機器可読記憶媒体５２とを含む。そのうち、プロセッサー５１と機器可読記憶媒体５２とは内部バス５３を介して互いに接続する。他の可能な実施方式において、前記ネットワークデバイスは、他のデバイスまたはモジュールと通信できるように、外部インターフェース５４を含むこともできる。
【００４４】
異なる例において、機器可読記憶媒体５２はＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ、ランダムアクセスメモリ）、揮発性メモリ、不揮発性メモリ、フラッシュメモリ、ストレージドライブ（ハードディスクドライブなど）、ソリッドステートドライブ、任意タイプのメモリディスク（例えば光ディスク、ＤＶＤなど）、または類似する記憶媒体およびそれらの組み合わせでよい。
【００４５】
さらに、機器可読記憶媒体５２に、プロセッサー５１によって実行されるシグネチャルールローディングの制御ロジック６０に対応する機器可読命令を格納する。図６に示すように、機能によって分割すると、前記制御ロジック６０は、受信モジュール６０１と、構成情報判断モジュール６０２と、ローディングモジュール６０３とを含むことができる。
【００４６】
そのうち、前記受信モジュール６０１は、クラウドサーバーによって送信されたシグネチャルールライブラリを受信するように構成している。前記シグネチャルールライブラリは少なくとも一つのシグネチャルールを含み、各シグネチャルールは対応するデバイスタイプ構成情報に関連する。一例では、前記各シグネチャルールに関連するデバイスタイプ構成情報はＴＬＶフォーマットで記録することができる。
【００４７】
前記構成情報判断モジュール６０２は、各シグネチャルールに対し、該シグネチャルールに関連するデバイスタイプ構成情報がネットワークデバイスのローカルデバイスタイプ構成情報にマッチするかどうかを判断するように構成している。判断結果がＹＥＳである場合は、前記ローディングモジュール６０３をトリガする。
【００４８】
前記ローディングモジュール６０３は前記シグネチャルールを前記ネットワークデバイスにロードするように構成している。
【００４９】
この例を適用する時に、まず、該ネットワークデバイスはクラウドサーバーによって送信されたシグネチャルールライブラリを受信する。該シグネチャルールライブラリは少なくとも一つのシグネチャルールを含んでおり、各シグネチャルールは対応するデバイスタイプ構成情報に関連する。そして、該ネットワークデバイスは、各シグネチャルールに対し、該シグネチャルールに関連するデバイスタイプ構成情報がネットワークデバイスのローカルデバイスタイプ構成情報にマッチするかどうかを判断する。その結果がＹＥＳである場合は、該ネットワークデバイスに該シグネチャルールをロードする。クラウドサーバーから発行されたのが、既にテーラーされ、一部のシグネチャルールを含むシグネチャサブライブラリであると異なり、この例では、クラウドサーバーによって格納及び送信されるのがいずれも全てのシグネチャルールを含む最大規模のシグネチャルールライブラリであるため、クラウドサーバーの記憶スペースを効率的に節約することができる。また、該シグネチャルールライブラリに含まれる各シグネチャルールは対応するデバイスタイプ構成情報に関連することによって、該ネットワークデバイスは自身のニーズに応じて（例えば、デバイスタイプ構成情報）該シグネチャルールライブラリにおけるシグネチャルールを自動的に選別してロードするできるので、ネットワークデバイスにロードされたシグネチャルールの全てが該ネットワークデバイスのデバイスタイプ構成情報にマッチすることを保証でき、ネットワークデバイスのリソースを効率的に利用してネットワークデバイスの機能を十分に発揮することができる。
【００５０】
一例において、前記受信モジュール６０１は、具体的に、ＳＤＮコントローラによってクラウドサーバーから送信されたシグネチャルールライブラリを受信するように構成する。
【００５１】
別の例によれば、図７に示すように、該シグネチャルールローディングの制御ロジックは、アップグレード要求送信モジュール７０１をさらに含むことができる。前記アップグレード要求送信モジュール７０１は前記クラウドサーバーにシグネチャルールライブラリに対するアップグレード要求を送信するように構成する。
【００５２】
別の例によれば、図８に示すように、該シグネチャルールローディングの制御ロジックはバーション番号判断モジュール８０１をさらに含むことができる。前記バーション番号判断モジュール８０１は、該シグネチャルールのバーション番号が前記ネットワークデバイスにロードされたシグネチャルールのバーション番号より高いかどうかを判断するように構成する。判断結果がＹＥＳである場合は、前記ローディングモジュール６０３をトリガする。
【００５３】
別の例によれば、図９に示すように、該シグネチャルールローディングの制御ロジックは破棄モジュール９０１をさらに含むことができる。前記破棄モジュール９０１は、前記構成情報判断モジュール６０２が該シグネチャルールに関連するデバイスタイプ構成情報とネットワークデバイスのローカルデバイスタイプ構成情報にマッチしないと判断した場合、前記シグネチャルールを破棄するように構成する。
【００５４】
以下、ソフトウェアで実現することを例として、ネットワークデバイスは該制御ロジック６０をどのように実行するかについてさらに説明する。この例では、本開示の制御ロジック６０が機器可読記憶媒体５２に記憶される機械実行可能なコマンドとして理解すべきである。本開示のネットワークデバイスのプロセッサー５１は機器可読記憶媒体５２に格納される制御ロジック６０に対応する機械実行可能なコマンドを呼び出して実行する際に、プロセッサー５１に、
クラウドサーバーによって送信されたシグネチャルールライブラリを受信し、前記シグネチャルールライブラリは少なくとも一つのシグネチャルールを含み、各シグネチャルールは対応するデバイスタイプ構成情報に関連しており、前記シグネチャルールに関連するデバイスタイプ構成情報はタイプ−長さ−値というＴＬＶフォーマットで記録されることと、
各シグネチャルールに対し、該シグネチャルールに関連するデバイスタイプ構成情報が前記ネットワークデバイスのローカルデバイスタイプ構成情報にマッチするかどうかを判断することと、
関連するデバイスタイプ構成情報がローカルデバイスタイプ構成情報にマッチするシグネチャルールに対し、該シグネチャルールを前記ネットワークデバイスにロードすることと、
を実行させる。
【００５５】
一例では、前記クラウドサーバーによって送信された前記シグネチャルールライブラリを受信する時に、前記デバイス実行可能なコマンドは前記プロセッサー５１に、ソフトウェア定義ネットワークＳＤＮコントローラによって前記クラウドサーバーから送信された前記シグネチャルールライブラリを受信することを実行させる。
【００５６】
一例では、前記デバイス実行可能なコマンドは、前記プロセッサー５１に、前記クラウドサーバーが前記シグネチャルールライブラリを送信するように前記クラウドサーバーにシグネチャルールアップグレード要求を送信することを実行させる。
【００５７】
一例では、関連するデバイスタイプ構成情報がローカルデバイスタイプ構成情報にマッチするシグネチャルールに対し、該シグネチャルールを前記ネットワークデバイスにロードする時に、前記デバイス実行可能なコマンドは、前記プロセッサー５１に、該シグネチャルールのバーション番号が前記ネットワークデバイスにロードされたシグネチャルールのバーション番号より高いかどうかを判断し、上記判断結果がＹＥＳである場合は、該シグネチャルールを前記ネットワークデバイスにロードすることを実行させる。
【００５８】
一例では、前記デバイス実行可能なコマンドは、前記プロセッサー５１に、関連するデバイスタイプ構成情報が前記ネットワークデバイスのローカルデバイスタイプ構成情報にマッチしないシグネチャルールに対し、該シグネチャルールを破棄することを実行させる。
【００５９】
デバイスの例は基本的に方法の例に対応しているので、関連する部分が方法の例の部分の説明を参照すればよい。上記のデバイスの例は例示的なものだけであり、別々の部材として記載されたユニットは物理的に分離してもしていなくてもよい。ユニットとして示されたモジュールは物理的なユニットでよいし、物理的なユニットでなくても良い。つまり、一箇所に設置されてもよく、または複数のネットワークユニットに分配されることもできる。この例の技術案の目的を実現するために、実際のニーズに応じてモジュールの一部または全部を選択することができる。当業者は創造的な働きがなくても、理解して実施することができる。
【００６０】
なお、この明細書では、第１および第２などのような関係用語は、一つの実体や操作を他の実体や操作と区別するためのものに過ぎないので、これらの実体や操作の間にそのような実際の関係や順序が存在することを必ずしも要求または示唆するわけではない。用語「含む」、「備える」またはその任意の他の変形は、非排他的な包含を含むことを意図しており、これによって、一連の要素を含むプロセス、方法、物品またはデバイスがこれらの要素を含むだけでなく、明示的に挙げられていないほかの要素や、このようなプロセス、方法、物品またはデバイスに固有される要素も含む。これ以上に制限がない場合、「…を含む」および「…を備える」という用語によって限定される要素は、前記要素を含むプロセス、方法、物品またはデバイスに他の同じ要素が存在することを排除するものではない。
【００６１】
当業者は、上記方法の例の全てまたは一部のステップは、機器可読記憶媒体に格納されているプログラムにより相関するハードウェアに対して指示することによって実現できることが理解することができる。ここでの記憶媒体とは、例えばＲＯＭ／ＲＡＭ、ディスク、光ディスクなどである。
【００６２】
以上の記載は本開示の好ましい例だけであり、本開示の請求範囲を限定するものではない。本願の要旨及び原則の内になされる何らの補正、同等な取り替え、改良などは本開示の保護範囲に含まれている。
【図１】
2019510410.tif 000005
【図２】
2019510410.tif 000006
【図３】
2019510410.tif 000007
【図４】
2019510410.tif 000008
【図５】
2019510410.tif 000009
【図６】
2019510410.tif 000010
【図７】
2019510410.tif 000011
【図８】
2019510410.tif 000012
【図９】
2019510410.tif 000013
【国際調査報告】
2019510410.tif 000014
2019510410.tif 000015
2019510410.tif 000016
2019510410.tif 000017