JP6692178B2 - 通信システム - Google Patents

Description

本発明は、通信システム、通信装置、および通信システムの通信制御方法に係る。

近年のＭ２Ｍ（Machine TO Machine）通信の増加に伴い、クラウド網に対して負荷の上昇を抑えることや、セキュリティの確保が重要となっている。

特開２００６−６０５９９号公報

クラウド負荷上昇の抑止については、Ｍ２Ｍ端末台数の増加と、Ｍ２Ｍサービスメニューの多様化がクラウドに対する負荷上昇の要因と考えられる。解決手段として、サーバの増設が容易に考えられる手段だが、最大負荷を想定した増設は適切な投資ではなく、他の対策が望まれる。

また、セキュリティの確保については、想定外の種類の通信（プロトコル・アプリケーション）の流入、想定外の量の通信（ＤｏＳ攻撃等）、通信内容の漏えいがＭ２Ｍにおけるセキュリティ保護の対象となると思われる。一方、人間の行う通信のような、標的型攻撃などはＭ２Ｍではあまり重要視されない。従って通信内容・量を可視化し、適切でないと判断した通信を抑止する必要がある。

クラウド負荷上昇の抑止や、セキュリティ確保の一手法としては、通信装置に所定条件により転送またはフィルタを行う機能を設けることが考えられる。

例えば特許文献１では、ファイアウォール装置が、発信元アドレスごとのトラヒック量が一定のしきい値を越えた場合に、攻撃があるものと検知して、指定されたフローに対しフィルタリングまたはレートリミットの設定を行う方式が開示されている（例えば特許文献１の００２３項）。

しかしながら、Ｍ２Ｍ端末等を用いた通信では、その台数の増加と、サービスメニューの多様化により、様々な特性のトラフィックが流れている。よって、単純に閾値との比較でフィルタリング等の処理を行うと、必要な通信を阻害したり、対応すべき通信を見逃したりするおそれがある。

そこで本発明の課題は、Ｍ２Ｍ通信等にも柔軟に対応できる、セキュリティを確保す手法、あるいは、トラヒック負荷に応じた振り分けを実現する手法を提供することにある。

上記課題を解決する本発明の一側面は、複数のユーザ端末と、複数のユーザ端末と接続されるエッジノードと、エッジノードに接続されるネットワークと、ネットワークに接続される複数のサービスサーバとを備える通信システムである。このシステムにおいて、エッジノードは、入力されるパケットの特性を時系列的に蓄積するトラヒックパターンデータと、パケットを処理するためのルールを格納するルールデータと、を格納する。さらに、エッジノードは、ルールデータに基づいてパケットの処理を行う機能部と、機能部による処理の後に、入力されるパケットを、所定の宛先に向けて出力する方路振分機能部と、を備える。また、通信システムは、トラヒックパターンデータの内容に基づいて、ルールデータを更新するルール作成部を備える。

本発明の他の一側面は、複数のユーザ端末と、複数のユーザ端末と接続されるエッジノードと、エッジノードに接続されるネットワークと、ネットワークに接続される複数のサービスサーバとを備える通信システムにおける、エッジノードを構成する通信装置である。この装置は、入力されるパケットの特性を時系列的に蓄積するトラヒックパターンデータと、パケットを処理するためのルールを格納するルールデータと、を格納する記憶装置を備える。また、トラヒックパターンデータの内容に基づいて、ルールデータを更新するルール作成部と、ルールデータに基づいてパケットの処理を行う機能部と、機能部による処理の後に、入力されるパケットを、所定の宛先に向けて出力する方路振分機能部と、を備える。

本発明のさらなる他の一側面は、複数のユーザ端末と、複数のユーザ端末と接続されるエッジノードと、エッジノードに接続されるネットワークと、ネットワークに接続される複数のサービスサーバとを備える通信システムの通信制御方法である。この方法では、エッジノードに入力されるパケットの特性を時系列的に蓄積して、トラヒックパターンデータを生成する第１のステップ、トラヒックパターンデータの統計的処理に基づいて、エッジノードに入力されるパケットの処理内容を定めるルールデータを生成あるいは更新する第２のステップ、ルールデータに基づいて、エッジノードに入力されるパケットの処理内容を決定する第３のステップ、処理内容に基づいて、エッジノードにおいてパケットを廃棄し、あるいは、エッジノードから所望の送信先に送信する第４のステップ、を備える。

ルールデータとは、例えば特定のパケットを廃棄するフィルタルールデータや、特定のパケットを転送するリダイレクトルールデータである。機能部による処理は、例えば、フィルタルールデータに基づくパケットの廃棄や、リダイレクトルールデータに基づく、パケットの転送である。

Ｍ２Ｍ通信等にも対応できる、セキュリティを確保する手法、あるいは、トラヒック負荷に応じた振り分けを実現する手法を提供できる。

実施例のネットワーク構成例を示すブロック図 エッジノード構成例（上り）のブロック図 エッジノード構成例（下り）のブロック図 管理サーバ構成例のブロック図 エッジサーバ構成例のブロック図 正常時のパケットの流れの例を示すチャート図 異常時のパケットの流れの例を示すチャート図 クラウドサーバ過負荷時のパケットの流れの例１を示すチャート図 クラウドサーバ過負荷時のパケットの流れの例２を示すチャート図 トラヒックパターンデータの一例を示す表図 フィルタルールデータの一例を示す表図 リダイレクトルールデータの一例を示す表図 トラヒックパターン学習の例１を示す概念図 トラヒックパターン学習の例２を示す概念図 管理サーバで集計されたトラヒック量の例を示すグラフ図 エッジノードのトラヒック学習機能部の動作フローの一例を示すフロー図 エッジノードのルール作成部によるフィルタルールデータの作成処理例１を示すフロー図である エッジノードのルール作成部によるフィルタルールデータの作成処理例２を示すフロー図 エッジノードのルール作成部によるリダイレクトルールの作成処理例を示すフロー図

実施の形態について、図面を用いて詳細に説明する。ただし、本発明は以下に示す実施の形態の記載内容に限定して解釈されるものではない。本発明の思想ないし趣旨から逸脱しない範囲で、その具体的構成を変更し得ることは当業者であれば容易に理解される。

以下に説明する発明の構成において、同一部分又は同様な機能を有する部分には同一の符号を異なる図面間で共通して用い、重複する説明は省略することがある。基本的に等価な構成が複数存在する場合には、同一の符号にハイフンと異なる符号を付して、各個体を識別することがある。また、個体を識別する必要がない場合には、ハイフン以降を省略することがある。

本明細書等における「第１」、「第２」、「第３」などの表記は、構成要素を識別するために付するものであり、必ずしも、数または順序を限定するものではない。また、構成要素の識別のための番号は文脈毎に用いられ、一つの文脈で用いた番号が、他の文脈で必ずしも同一の構成を示すとは限らない。また、ある番号で識別された構成要素が、他の番号で識別された構成要素の機能を兼ねることを妨げるものではない。

図面等において示す各構成の位置、大きさ、形状、範囲などは、発明の理解を容易にするため、実際の位置、大きさ、形状、範囲などを表していない場合がある。このため、本発明は、必ずしも、図面等に開示された位置、大きさ、形状、範囲などに限定されない。

＜０．本実施例の概要＞
以下で説明する実施例では、クラウドとエンドユーザを繋ぐネットワークのユーザ側エッジ部分にエッジノードを配備する。ネットワークは、通常ネットワークキャリアが提供している。エッジノードでは、ＤＰＩ（Deep Packet Inspection）を用いたプロトコルやアプリケーションの識別を行う。エッジノードでは、ＤＰＩによる識別結果と、プロトコルやアプリケーション別の通信可否情報（フィルタ情報）に基づき、対象外の通信をブロックする。

また、エッジノードでは、トラヒックパターンに基づいて検知した特定の特徴を持つトラヒックを、動的に通信可否情報に登録してブロックする。このため、エッジノードは、現状の通信可否情報で許可された通信のトラヒックパターンを学習する。

ここでトラヒックパターンとは、トラヒックの特性の時間的変化をいう。トラヒックの特性とは、例えば単位時間あたりのパケット数、データ量、Ｃプレーン（コネクション）数、Ｕプレーン（データ）量、などのパラメータ、および、これらのパラメータを用いて計算される２次的なパラメータである。２次的なパラメータとしては、例えば、Ｃプレーン数とＵプレーン量の相関などがある。エッジノードはこのような、トラヒックパターンを学習する。学習とは、過去のトラヒックパターンを記憶することをいう。

以上の学習処理は、エッジノード毎に行ってもよいし、エッジノードからクラウド側のサーバ等にトラヒック特性を通知して、集計してもよい。サーバで集計することにより、エッジノード単独では検知できない異常を検知することができる。

また、エッジノードでは、ＤＰＩ結果、およびトラヒック学習パターンに基づき、通信の宛先、プロトコル、およびアプリケーションの少なくとも一つに応じて、パケットにタグを付与する。ここでタグには通信元デバイス情報、タグ付けしたエッジノードの情報が含まれる。

エッジノードは、タグに応じて送信先クラウドサーバを振り分ける。アプリケーションによってはクラウドサーバではなく、エッジサーバに振り分けてもよい。後に詳細に説明するように、エッジサーバ１０４は、クラウドサーバ１０６に代わって処理を代行できるサーバである。これによって、クラウドサーバの負荷低減と、処理のリアルタイム性を保証することができる。なお振り分けのルールは、エッジノード外のサーバから指定することも可能である。

＜１．ネットワーク全体構成＞
図１は、実施例となるネットワーク構成例である。図１において、クラウドサーバ（サービスサーバ）１０１は、通信キャリアネットワーク１０２を介して、１または複数の地域ネットワーク１０２−１〜１０２−３に接続されている。

クラウドサーバ１０１は、各種のサービスＡ〜Ｃを提供する１または複数のサービスサーバ１０６−１〜１０６−３と、管理サーバ１０７を含んでいる。地域ネットワーク１０３−１〜１０３−３は、クラウドサーバ１０１との間でデータの送信及び受信の少なくとも一つを行う、ユーザやクライアント１０８−Ｃ、各種装置１０８−Ｍ、センサやデバイス１０８−Ｄ等を含む。便宜的に、地域ネットワーク１０３−１〜１０３−３のこれらの主体を、ユーザ（端末）１０８と総称することにする。地域ネットワーク１０３には、ユーザ１０８からのデータを中継する装置として、例えばＭ２ＭＧＷ（Machine to Machine Gateway）１０９を含んでもよい。本明細書では便宜的に、ユーザ１０８からクラウドサーバ１０１の方向の通信を上り、逆方向を下りと呼称することにする。

通信キャリアネットワーク１０２と地域ネットワーク１０３の間には、データを中継するエッジノード１０５−１〜１０５−３が配置されている。また、エッジノード１０５−１〜１０５−３は、エッジサーバ１０４と交信が可能である。

＜２．エッジノード＞
＜２−１．エッジノード構成例＞
図２Ａおよび図２Ｂはエッジノード１０５の構成例である。エッジノード１０５は、公知の基本的な通信機能とともに以下の構成を備える。すなわち、ＤＰＩ機能部２０１、フィルタ機能部２０２、ルーティング機能部２０３、トラヒック学習機能部２０４、方路振分機能部２０５、クラウド通信機能部２０６、ルール作成機能部２０７を備える。また、エッジノード１０５は、フィルタルールデータ２０８、リダイレクトルールデータ２０９、および、トラヒックパターンデータ２１０を記憶する。

なお、本実施例では、各装置（サーバやノード）は、通常の通信装置の機能の他、情報処理装置の基本構成である、処理装置（プロセッサ）、記憶装置（メモリ）、入力装置（入力インタフェース）、出力装置（出力インタフェース）の構成を備えるものとし、上記各種の機能は、記憶装置に格納されたプログラムが処理装置によって実行されることで、定められた処理を他のハードウェアと協働して実現することとする。処理装置などが実行するプログラム、その機能、あるいはその機能を実現する手段を、「機能」、「機能部」、「手段」、「部」、「ユニット」、「モジュール」等と呼ぶ場合がある。

また、記憶装置は、例えば磁気ディスク装置や各種半導体記憶装置を用いるものとし、本明細書で「データ」と称する情報を格納する。以後の説明では「〜テーブル」、「〜リスト」、「〜ＤＢ（Ｄａｔａｂａｓｅ）」、「データ」、「〜キュー」、「情報」等の表現にて本実施例の構成を説明することがあるが、これらは等価な情報である限り、テーブル、リスト、ＤＢ、キュー、等のデータ構造以外で表現されていてもよい。

また、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ（ＩＤｅｎｔｉｆｉｃａｔｉｏｎ）」という表現を用いるが、これらについては互いに置換が可能である。

また、プログラムは処理装置によって実行されることで定められた処理をメモリ及び通信ポート（通信制御デバイス）を用いながら行うため、処理装置を主語として説明することもできる。また、プログラムを主語として開示された処理はサーバ等の装置、情報処理装置が行う処理としてもよい。また、プログラムの一部または全ては専用ハードウェアによって実現されてもよい。

また、各種プログラムは、プログラム配布サーバや、計算機が読み取り可能な記憶メディアによって情報処理装置にインストールされてもよい。この場合、プログラム配布サーバは、プロセッサと記憶資源を含み、記憶資源はさらに配布プログラムと配布対象であるプログラムを記憶する。そして、配布プログラムをプロセッサが実行することで、プログラム配布サーバのプロセッサは、配布対象のプログラムを他の計算機に配布する。

また、計算機は入出力デバイスを有してもよい。入出力デバイスの例としてはディスプレイとキーボードとポインタデバイスが考えられるが、これ以外のデバイスであってもよい。また、入出力デバイスの代替としてシリアルインタフェースやイーサーネットインタフェースを入出力デバイスとし、当該インタフェースにディスプレイ又はキーボード又はポインタデバイスを有する表示用計算機を接続し、表示用情報を表示用計算機に送信したり、入力用情報を表示用計算機から受信することで、表示用計算機で表示を行ったり、入力を受け付けることで入出力デバイスでの入力及び表示を代替してもよい。

以上の構成は、単体のコンピュータで構成してもよいし、あるいは、入力装置、出力装置、処理装置、記憶装置の任意の部分が、ネットワークで接続された他のコンピュータで構成されてもよい。

本実施例中、ソフトウエアで構成した機能と同等の機能は、ＦＰＧＡ（Field Programmable Gate Array）、ＡＳＩＣ（Application Specific Integrated Circuit）などのハードウエアでも実現できる。そのような態様も本願発明の範囲に含まれる。

＜２−２．上り方向エッジノード動作例＞
図２Ａおよび図２Ｂを参照して、エッジノード１０５の動作を説明する。本明細書の図面では、太い矢印はトラフィック（パケット）の経路を、細い矢印は装置内の制御のためのデータ、コマンド等を示す。

図２Ａは上り方向の処理である。上り方向の通信において、エッジノード１０５はユーザ１０８からのパケット２１１Ｕを受信すると、ＤＰＩ機能部２０１にてアプリケーション種別を特定する。アプリケーション種別は、パケット２１１Ｕ本体と合わせてこの後に続くフィルタ機能部２０２に送られる。

フィルタ機能部２０２は、フィルタルールデータ２０８を適用して、パケットの送信元ＩＰアドレスやＤＰＩ機能部２０１から送られてきたアプリケーション種別をフィルタルールデータと照合し、これに合致すればパケットを廃棄する。パケットを廃棄した場合には、これ以降の処理は行わない。フィルタルールデータ２０８には、パケットの送信元ＩＰアドレスやアプリケーション種別の他、他の種類のパラメータを格納してもよい。また、フィルタリングは、複数のパラメータの一つまたは複数の組合せに基づいて行ってもよい。

パケット２１１が廃棄されなかった場合には、パケット２１１Ｕをルーティング機能部２０３へ送る。ルーティング機能部２０３はリダイレクトルールデータ２０９を参照してパケットの宛先を選択する。その後パケット２１１Ｕをトラヒック学習機能部２０５に送る。

トラヒック学習機能部２０５は受信したパケット２１１Ｕの受信時刻、パケットサイズ、送信元ＩＰアドレス、宛先ＩＰアドレス、アプリケーション種別といった情報を用いてトラヒックパターンデータ２１０を更新する。トラヒックパターンの更新方法、および、フィルタルールデータ２０８、リダイレクトルールデータ２０９の更新方法は後述する。

パケットは方路振り分け機能部２０５に送られる。方路振り分け機能部２０５ではパケット２１１Ｕを宛先に応じて振り分ける。振り分けられたパケット２１１Ｕは、上り方向の宛先であるクラウド１０１中のクラウドサーバ１０６や、エッジサーバ１０４に送出される。

＜２−３．下り方向エッジノード動作例＞
図２Ｂは下り方向の処理である。下り方向の通信において、エッジノード１０５は、クラウドサーバ１０６やエッジサーバ１０４からのパケット２１１Ｄを受信すると、ＤＰＩ機能部２０１にてアプリケーション種別を特定する。アプリケーション種別は、パケット２１１本体と合わせてこの後に続くフィルタ機能部２０２に送られる。

フィルタ機能部２０２はフィルタルールデータ２０８を参照して、パケットの送信元ＩＰアドレスやＤＰＩ機能部２０１から送られてきたアプリケーション種別を、フィルタルールデータに照合する。フィルタ機能部２０２の動作の詳細は、図２Ａで説明したものと同じである。

ルーティング機能部２０３はリダイレクトルールデータを参照してパケット２１１Ｄの宛先を選択する。なお下り方向の通信はユーザ１０８へ送信されるデータなので、リダイレクトルールの対象外であるため参照する必要はない。しかし、上りと下りで処理を共通化する利点があるため、本実施例では下りでもリダイレクトルールデータを参照することにしている。上りと下りを識別して、下り方向の通信の場合は、ルーティング機能部２０３をスキップすることも可能である。その後パケット２１１Ｄをトラヒック学習機能部２０４に送る。

トラヒック学習機能部２０４はトラヒックパターンデータ２１０を更新する。動作の詳細は、図２Ａで説明したものと同じである。その後、パケットは方路振り分け機能部２０５に送られる。方路振り分け機能部２０５ではパケットを宛先（地域ネットワーク１０３中のユーザ１０８）に送り出す。

＜２−４．管理サーバによるエッジノードのリダイレクト制御例＞
図２Ａ、図２Ｂを参照して、管理サーバによるエッジノードのリダイレクト制御例を説明する。

クラウド通信部２０６はトラヒックパターンデータ２１０を周期的に管理サーバ１０７へ送信する。管理サーバ１０７は各エッジノード１０５から送られてきたトラヒックパターンデータ２１０を集計し、クラウドサーバ１０６毎にかかる負荷を計算する。計算の結果負荷が閾値を超えた場合、負荷の元となったエッジノードに対して転送停止指示を送信する。または、転送停止要求後に負荷が閾値を下回った場合は、転送許可指示を当該エッジノードに送信する。

転送停止指示を受け取ったエッジノード１０５のクラウド通信部２０６はこれをルール作成部２０７に送る。ルール作成部２０７はリダイレクトルールデータ２０９にて、転送停止対象のクラウドサーバに対するリダイレクト指示を「有」に設定する。リダイレクトルールデータ２０９の詳細は後述する。

転送許可指示を受け取ったエッジノード１０５のクラウド通信部２０６はこれをルール作成部２０７に送る。ルール作成部２０７はリダイレクトルールデータ２０９にて、転送許可対象のクラウドサーバに対するリダイレクト指示を「無」に設定する。

またルール作成部２０７は定期的にトラヒックパターンデータ２１０を参照し、特定のアプリケーションや特定のＩＰアドレスからの通信についてトラヒックの異常が認められる場合、これらのアプリケーションやＩＰアドレスからの通信をブロックするために、フィルタルールデータ２０８に対象となるアプリケーションやＩＰアドレスを記載する。

さらにルール作成部２０７は、トラヒックパターンデータ２１０にて特定の宛先に対する通信量が一定の閾値を超えた場合、自律的にリダイレクトルールデータ２０９の、該当する宛先ＩＰアドレスのリダイレクト指示を「有」に設定するように構成することもできる。

＜３．管理サーバ構成例＞
図３は、管理サーバ１０７の構成例である。管理サーバ１０７の統計情報収集部３０１は、各地のエッジノード１０５のクラウド通信部２０６から送信される、トラヒックパターンデータ２１０、あるいは、トラヒックパターンデータを生成するための情報を周期的に収集する。収集の周期は任意であるが、例えば１分周期とする。周期が短ければ制御の精度が向上するが、収集のためのオーバヘッドが増大する。

クラウドトラヒック学習機能部３０２はこのトラヒックパターンデータ２１０を集計し、クラウドトラヒック学習機能部３０２でトラヒックパターンを学習する。学習の仕方はエッジノード１０５のトラヒック学習機能部２０４と同様である。

エッジノード１０５、管理サーバ１０７におけるトラヒックパターン学習は後に詳述する。学習した結果は、トラヒックパターンデータ２１０、３０４として蓄積される。これによりクラウド１０１もしくはクラウドサーバ１０６にかかる負荷の傾向を把握できる。

特定のクラウド１０１もしくはクラウドサーバ１０６にかかる負荷が一定の閾値を超えた場合、転送可否指示部３０５により、地域毎のトラヒック傾向を見て、パケット量が多いエッジノード１０５（複数あってもよい）に対して、当該送信先に対する送信停止（あるいは別サーバへの転送）の指示を出すことができる。逆に負荷が閾値を下回った場合、対象となっていたエッジノード１０５に対して送信許可（あるいは別サーバへの転送解除）の指示を出す。

また、管理サーバ１０７は、クラウド管理者からの指示を、ユーザインターフェース３０３を介して受け付け、指示内容に基づき、全てのもしくは選択したエッジノード１０５に対して転送禁止あるいは許可の指示を出すこともできる。

なお、上述したように、エッジノード１０５から管理サーバ１０７に送信されるデータは、トラヒックパターンデータ２１０そのものでなく、トラヒック学習機能部２０４で作成されるトラヒックの状況を示すデータでもよい。

＜４．エッジサーバ構成例＞
図４は、エッジサーバ１０４の構成である。エッジサーバ１０４は、クラウドサーバ１０６の負荷が高いとき、リアルタイム性の高い処理の場合にエッジノード１０５から転送されてきたユーザ１０８（ＰＣ/タブレット、Ｍ２Ｍデバイスなど）からのパケットを、クラウドサーバ１０６に代わって処理するサーバである。通常のサーバが有する構成以外の特徴に限って以下で説明する。

受信したパケットは振り分け部４０１にてサービスに応じて適切なサービス処理部４０２（図中のサービスＡ，Ｂ，Ｃ，，，）に転送され、そこで処理される。なお、複数のサービス処理部４０２は、例えばサーバ仮想化の技術を用いて、同一物理サーバ上に実現することができる。

エッジサーバ１０４は、クラウドインタフェース４０３により、定期的にクラウドサーバ１０６とデータをやりとりし、データの同期をとる。これは、ユーザがクラウドサーバ１０６と通信しても、エッジサーバ１０４と通信しても、同じ結果を得られるようにするためである。

＜５．正常時パケットフロー例＞
図５は、正常時のパケットの流れを示すチャート図である。ここで、正常時とはパケットのフィルタリングがされず、負荷の大きなクラウドサーバ１０６もない状態である。

ユーザ１０８から送信されるパケット２１１Ｕは、Ｍ２ＭＧＷ１０９を介して、地域ネットワーク１０３のエッジノード１０５に送られる。エッジノード１０５では、図２Ａで説明した処理を行い、トラヒック学習機能部２０４は、トラヒックパターン学習Ｓ５０１を実行する。

また、クラウドサーバ１０６から送信されるパケット２１１Ｄは、地域ネットワーク１０３のエッジノード１０５に送られる。エッジノード１０５では、図２Ｂで説明した処理を行い、トラヒック学習機能部２０４は、トラヒックパターン学習Ｓ５０１を実行する。

エッジノード１０５を経由したパケット２１１Ｄは、Ｍ２ＭＧＷ１０９を介して、地域ネットワーク１０３のユーザ１０８に転送される。

トラヒックパターン学習Ｓ５０１の内容は、後に説明する。また、図４で説明したように、エッジサーバ１０４とクラウドサーバ１０６は同期処理Ｓ５０２を行う。

＜６．異常時パケットフロー例＞
図６は、異常パケット検出時のパケットの流れを示すチャート図である。ここで異常時とは例えば、悪意あるユーザやサーバによるアクセスがあり、フィルタリングがされるべき場合である。

悪意のあるユーザ１０８Ｖから送信される攻撃パケット２１１ＵＶは、Ｍ２ＭＧＷ１０９を介して、地域ネットワーク１０３のエッジノード１０５に送られる。図２Ａで説明したように、エッジノード１０５では、フィルタルールデータ２０８と攻撃パケット２１１ＵＶを照合して、フィルタルールデータ２０８と一致した場合には、攻撃パケット２１１ＵＶを破棄する。

また、フィルタルールデータ２０８と攻撃パケット２１１ＵＶが一致しない場合であっても、攻撃パケット２１１ＵＶのトラヒックパターンが、トラヒックパターンデータ２１０と比較して異常値を示す場合には、攻撃パケット２１１ＵＶをフィルタするように、ルール作成部２０７がフィルタルールデータ２０８を変更する（Ｓ６０１）。その結果、変更されたフィルタルールデータ２０８と一致する攻撃パケット２１１Ｖは、廃棄される（Ｓ６０２）。異常の検知方法については、後に図１２〜図１４で説明する。

悪意あるサーバ１０６ＤＶからの攻撃パケット２１１ＤＶも同様に、フィルタルールデータ２０８を変更し（Ｓ６０３）、一致した攻撃パケット２１１ＤＶは廃棄される（Ｓ６０４）。

以上の処理は、各エッジノード１０５が自律的にフィルタルールデータ２０８を変更する例である。ただし、これに加えて、あるいはこれに代えて、管理サーバ１０７からの指示でフィルタルールデータ２０８を変更してもよい。すなわち、管理サーバ１０７もトラヒックパターンデータ３０４を備えているため、各地のエッジノード１０５からの情報に基づく統計情報が、トラヒックパターンデータ３０４に基づいて異常値を示す場合には、関連するエッジノード１０５のフィルタルールデータ２０８に対して変更の指示を出す。

管理サーバ１０７は、システム全体のトラヒックパターンを把握しているので、エッジノード１０５単独で検知できない異常を検知できる可能性がある。ただし、
エッジノード１０５からの情報を収集するまでにタイムラグがあるため、反応は遅くなる。

＜７．高負荷時サーバ切替え処理例１＞
図７はクラウドサーバ１０６の負荷が高い時の、上りパケット２１１Ｕの流れを示すチャート図である。ユーザ１０８からの上りパケット２１１Ｕは、Ｍ２ＭＧＷ１０９を経由してエッジノード１０５で処理される。

エッジノード１０５はユーザ１０８からの上りパケット２１１Ｕのトラヒックを学習する一方、ＤＰＩによりクラウドサーバ１０６毎の通信量を監視し、特定のクラウドサーバ１０６への負荷が高い場合、宛先をクラウドサーバ１０６からエッジサーバ１０４に切り替える（Ｓ７０１）。負荷が高いサーバの検出方法は、後に図１２〜図１４で説明する。

切り換えた結果、上りパケット２１１Ｕはクラウドサーバ１０６からエッジサーバ１０４にリダイレクトされる。

クラウドサーバ１０６とエッジサーバ１０４は定期的に、あるいは、クラウドサーバ１０６の負荷が低いときなどを契機にデータの同期を実施する（Ｓ７０２）。

＜８．高負荷時サーバ切替え処理例２＞
図８はクラウドサーバ１０６の負荷が高い時の、上りパケット２１１Ｕの流れを示すチャート図である。図７の例では、クラウドサーバ１０６の負荷は、エッジノード１０５が検出し、自律的に切替えた。しかし、単一のエッジノード１０５では特定のクラウドサーバ１０６に負荷が集中しているように見えなくても、他のエッジノード１０５が送出するパケットを考慮すると、特定のクラウドサーバに負荷が集中している場合がある。

図８の例では、エッジノード１０５−１、１０５−２其々では、クラウドサーバ１０６向けのパケット量は多くない。しかし、クラウドサーバ１０６には、エッジノード１０５−１、１０５−２の両方から上りパケット２１１Ｕが集中するため、負荷が大きくなっている。

図８の例では、管理サーバ１０７は、配下の各エッジノード１０５からトラヒック統計情報の報告（Ｓ８０１）を受け、統計情報を集計し、負荷が大きくなっているクラウドサーバ１０６を検出すると、当該クラウドサーバ１０６にパケット２１１Ｕを送出しているエッジノードに対して、送出先の切り替え指示を行い、宛先をクラウドサーバ１０６からエッジサーバ１０４に切り替える（Ｓ８０２）。

統計情報の集計手法としては、例えば宛先となるクラウドサーバ１０６毎に、転送量を合算すればよい。

＜９．トラヒックパターンデータ例と異常判定例＞
図９は、エッジノード１０５が格納する、トラヒックパターンデータ２１０の一例を示す図である。本実施例では、トラヒックパターンデータ２１０は上り通信と下り通信とで２つ設ける。ただし両者に形態上の違いはないため、同じ図で説明する。

なお、管理サーバ１０７が格納する、トラヒックパターンデータ３０４も同様に構成できる。トラヒックパターンデータ３０４は、各エッジノード１０５のトラヒックパターンデータ２１０を集計したものである。ただし、前述のようにトラヒックパターンデータ２１０より時間的に遅れて更新される。トラヒックパターンデータ３０４では、送信元ＩＰアドレス９０１の代わりに、送信元エッジノード１０５のＩＰアドレスを用いて、エッジノード単位の統計をとることもできる。

トラヒックパターンデータ２１０は、送信元ＩＰアドレス（検索キー＃１）９０１、宛先ＩＰアドレス（検索キー＃２）９０２、アプリケーション名称（検索キー＃３）９０３と、時間帯毎のＣプレーンのカウンタ９０４と、Ｕプレーンのカウンタ９０５が記憶されている。Ｃプレーンは、送受信機間でコネクションの設定、解放等に関する制御情報を扱うプロトコルである。Ｕプレーンは、送受信機間でユーザ情報を送受するために使用するプロトコルである。

これらのカウンタはトラヒック学習機能部２０４がパケット２１１を受信するたびに計上する。ここで時間帯とは、例えば周期的に実行する場合には、その周期によって定められる。例えば、図９では１０分間隔である。メモリ量を節約したい場合には、ある程度の時間が経過すると、時間帯毎のカウンタは古い時間帯から順に上書きされるように構成してもよい。

またトラヒックパターンデータ２１０は、全ＩＰアドレス、および、アプリケーションの合計カウンタ９０６を時間帯毎に計算し、記録してある。また、任意のまとまった時間帯で時間帯毎の合計カウンタの平均値９０７と分散値９０８を計算し、記録してある。この平均値と分散値を基準として時間帯毎のマハラノビス距離９０９を計算し、記録する。マハラノビス距離は統計量の一つとして、過去データから外れたデータを異常値として検出するために用いることができる。統計量とは、過去のデータに所望の関数を適用して得た、データの特徴を要約した数値をいう。例えば、平均値、分散、偏差値、マハラノビス距離のようなものである。統計量を求める処理のことを統計的処理という。このように、過去のデータを統計的に処理することにより、異常判定を行うことができる。

ルール作成部２０７はトラヒックパターンデータ２１０をモニタして、マハラノビス距離９０９があらかじめ定めた一定値を超えた場合に、検索キー＃１（送信元ＩＰアドレス）や、検索キー＃２(宛先ＩＰアドレス)、検索キー＃３（アプリケーション名称）毎に、Ｃプレーン、Ｕプレーンのカウンタをチェックし、通信量の過多など判定する。判定は、カウンタの値を、例えば「閾値」、「所定期間のカウンタの値の平均値」、あるいは、「所定期間前のカウンタの値」等との比較により行うことができる。ただし、これに限るものではなく、他の方法を用いてもよい。その結果、異常と判定された通信量と関連する送信ＩＰアドレス、受信アドレス、あるいはアプリケーションを検出することができる。異常と判定されたＩＰアドレスあるいはアプリケーションは、フィルタルールデータ２０８あるいはリダイレクトルールデータ２０９に登録される。

上記のマハラノビス距離は、異常検知の一手法であるが他の異常検知手法を用いてもよい。例えば、単純に時間帯毎のＵプレーン合計値の一つ前の時間帯との差分を見て、その値があらかじめ定めた一定量を超えた場合に検索キー＃１(送信元ＩＰアドレス)、検索キー＃２(宛先ＩＰアドレス)、検索キー＃３（アプリケーション名称）毎に、Ｕプレーンのカウンタをチェックし、通信量の過多を判定して、どのＩＰアドレスあるいはアプリケーションが異常なのかを検出し、フィルタルールデータ２０８の作成に用いることもできる。

＜２−４．管理サーバによるエッジノードのリダイレクト制御例＞で説明したように、ルール作成部２０７は、管理サーバ１０７からの転送停止指示または転送許可指示に従って、リダイレクトルール２０９の設定内容を変更することができる。またルール作成部２０７は、管理サーバ１０７の指示によらず、エッジノード１０５のトラヒックパターンデータ２１０を参照して、クラウドサーバ１０６のＩＰアドレスを検索キー＃２(宛先ＩＰアドレス)にて検索し、クラウドサーバ毎にＣプレーン、Ｕプレーンの時間帯における合計値を計算し、あらかじめ定めた一定値を超えた場合にリダイレクトルールデータ２０９の設定内容を変更することもできる。

また、同様にルール作成部２０７は、管理サーバ１０７からの指示に従って、フィルタルールデータ２０８の設定内容を変更することができる。

＜１０．フィルタルールデータ例＞
図１０は、エッジノード１０５が記憶する、フィルタルールデータ２０８の例を示す図である。フィルタルールデータ２０８は、エッジノード１０５のフィルタ機能部２０２で参照される。フィルタルールデータ２０８には、例えばブロックする対象とする通信の送信元ＩＰアドレス１００１、あるいはアプリケーション１００２が記載されている。この他に、ブロックする対象とする通信の送信先ＩＰアドレスや、送信元エッジノードのＩＰアドレス等、他のパラメータを記載してもよい。

＜１１．リダイレクトルールデータ例＞
図１１は、エッジノード１０５が記憶する、リダイレクトルールデータ２０９の例を示す図である。リダイレクトルールデータ２０９は、エッジノード１０５のルーティング機能部２０３で参照される。

図１１に示すようにリダイレクトルールデータ２０９は、クラウドサーバＩＰアドレス１００１毎に、リダイレクト指示の有無１１０２が記載されている。

ルーティング機能部２０３は、パケットを受信するとパケットの宛先ＩＰアドレスをチェックする。そして、リダイレクトルールデータ２０９の該当宛先ＩＰアドレス１１０１のリダイレクト指示１１０２を参照する。

リダイレクト指示１１０２が「無」の場合、上り方向の通信において、パケットはトラヒック学習機能部２０４に転送され、さらに、クラウドサーバ１０６へ転送される。

リダイレクト指示が「有」の場合、上り方向の通信において、パケットはリダイレクトルールデータ２０９のエッジサーバＩＰアドレス１１０３で指定されるエッジサーバ１０４に宛先が変更される。その後、パケットはトラヒック学習機能部２０４に転送され、転送先であるエッジサーバ１０４の、対応するサービス１１０４に転送される。リダイレクト指示１１０２はルール作成部２０７によって有無が設定される。

なお、上記の実施例では、クラウドサーバ１０６が高負荷の場合には、エッジサーバ１０４でサービスを代行させた。他の例としては、負荷の少ないクラウドサーバに代行させることもできる。負荷の少ないクラウドサーバの検出方法は、負荷の大きいクラウドサーバの検出方法と同様である。この方法では、処理のためのリソースを有効に利用できるが、クラウドサーバの負荷状況に応じて、同期処理Ｓ５０１を行う相手の組合せを、動的に変更する必要がある。

＜１２．トラヒックパターン学習の例１＞
図１２は、エッジノード１０５のトラヒック学習機能部２０４が行う、トラヒックパターン学習の例を示す概念図である。トラヒックパターンの学習、フィルタ機能を説明する。ここで「学習」とは、過去のトラヒックの状況を時系列的なデータとして蓄積することをいう。

図１２（ａ）は、トラヒック学習機能部２０４で収集された、各時刻におけるトラフィック量を示すグラフである。ここでは、Ｕプレーンのデータ量をモニタしているものとする。すなわち、図１２（ａ）のグラフは、エッジノード１０５を通過するパケット２１１の量を反映している。

トラヒック学習機能部２０４は、各時刻におけるトラフィック量を基に、パケット２１１の送信元アドレス、送信先アドレス、アプリケーション等に基づいて分類を行うことができる。例えば、図１２（ｂ）は、ある特定の送信元アドレス１から送信されるトラヒック量の時間変化を示し、図１２（ｃ）は、他の特定の送信元アドレス２から送信されるトラヒック量の時間変化を示すとする。このほか、特定の受信元アドレスや、特定のアプリケーションごとのデータに分類することにしてもよい。

トラヒック学習機能部２０４は、このようなトラヒックパターンを、図９で説明したように、例えば平均値やマハラノビス距離のような統計量とともに、トラヒックパターンデータ２１０として記憶装置に記憶する。また、ルール作成部２０１では、トラヒックパターンデータ２１０を分析し、フィルタリングすべきパケットや、リダイレクトすべきパケットに適用するルールを決定する。

どのようなパケットをフィルタリングするかは、トラヒックパターンに通常と異なる兆候が表れているかを検知する。簡単な例としては、時間あたりのトラヒック量の変動幅（例えば直前の値との差分）をモニタし、閾値を超えた場合に「異常」と判断する。例えば、図１２（ｂ）の例では、変動幅超過分１２０１が閾値を超えた許容外変動である場合、そのパケットは異常通信であると判定し、当該パケットの送信元を、フィルタルールデータ２０８の送信元ＩＰアドレス１００１に登録する。あるいは、図９で説明したように平均値やマハラノビス距離を用いたり、標準偏差を計算したりして異常通信を判定してもよい。

また、図１２（ｂ）を、ある特定のクラウドサーバ１へ送信されるトラヒック量の時間変化とし、図１２（ｃ）を、他のクラウドサーバ２へ送信されるトラヒック量の時間変化を示すものとすれば、上記と同様の手法により、クラウドサーバ１への送信パケットが急激に増加していることが分かる。その場合には、当該パケットの送信先を、図１１のリダイレクトルールデータ２０９の、クラウドサーバＩＰアドレス１１０１に登録し、パケットをエッジサーバ１０４にリダイレクトする。

あるいは、当該パケットがクラウドサーバ１の攻撃を意図するトラヒックであると判断し、図１０のフィルタルールデータ２０８の、クラウドサーバ１への送信パケットを廃棄する。

以上のように、トラヒックパターンデータ２１０は、ルール作成部２０１で使用され、フィルタルールデータ２０８やリダイレクトルール２０９に反映することができる。過去のラヒックパターンデータを学習し、これを基準とすることで、実際のトラフィックの状況を反映した異常検出をすることができる。

＜１３．トラヒックパターン学習の例２＞
図１３はトラヒックパターンの他の学習例である。図９に示したデータを用いたトラヒックパターンの学習、フィルタ機能の例を説明する。この例では、トラヒック学習機能部２０４は、Ｃプレーンコネクション数とＵプレーンデータ量の相関をモニタする。通常、Ｃプレーンコネクション数の多さとＵプレーンデータ量の間には相関がある。しかし、ＤｏＳ攻撃などにより大量のデータが送信される状況では，コネクション数に対してデータ量が多くなり、異常と認識される。一方、データ量は少ないがコネクション数が増えている状況は、例えばＳＹＮ Ｆｌｏｏｄのような攻撃が行われていると想定される。

図１３は、縦軸にＣプレーンコネクション数、横軸にＵプレーンデータ量を定義したグラフである。白丸１３０１は相関に基づき正常と判定される通信であり、黒丸１３０２は相関に基づき異常と判定される通信である。正常通信と異常通信の境界は、例えば点線１３０３で示される。

正常通信と異常通信の境界１３０３はオペレータが固定値で設定してもよいし、過去のトラヒックパターンデータ２１０から統計的に設定してもよい。例えば、過去データの分布の９０％が含まれる範囲のように設定することができる。

異常通信と判定された通信に関連する、送信元、送信先、アプリケーションの少なくとも一つは、フィルタルールデータ２０８に登録され、廃棄対象となる。図１３に示すように、過去のトラヒックパターンデータを統計的に分析することで、適切な異常検出が可能となる。

＜１４．トラヒックパターンとサーバ側キャパシティの関係例＞
以上の図１２と図１３では、エッジノード１０５のトラヒック学習機能部２０４とトラヒックパターンデータ２１０を例に説明したが、管理サーバ１０７のクラウドトラヒック学習機能部３０２とトラヒックパターンデータ３０４でも同様の処理を行うことができる。この場合には、管理サーバ１０７は各エッジノード１０５のフィルタルールデータ２０８やリダイレクトルールデータ２０９を、クラウド通信部２０６を介して変更する。

図１４は、図８のフローＳ８０１により管理サーバ１０７で集計された、エッジノード１０５−１のトラフィック量１４０１と、エッジノード１０５−２のトラヒック量トラフィック量１４０２のトラフィックパターンと、クラウドサーバ１０６のキャパシティ１４０３の関係を示す。

トラフィックパターンのデータに基づいて、図９で説明した平均や分散、マハラノビス距離を利用することで、合計トラフィック量がクラウドサーバ１０６のキャパシティを超える前に、統計情報の傾向から増加の兆候を判定し、オーバ量１４０４をエッジサーバ１０４に転送することができる。

＜１５．エッジノードのトラヒック学習機能部の動作例＞
図１５は、エッジノード１０５のトラヒック学習機能部２０４の動作フローの一例を示す図である。図２Ａおよび図２Ｂも参照しつつ動作を説明する。

処理Ｓ１５０１では、トラヒック学習機能部２０４は、ルーティング機能部２０３またはフィルタ機能部２０２からパケットを受信する。

処理Ｓ１５０２では、トラヒック学習機能部２０４は、受信したパケットの送信元ＩＰアドレス、宛先ＩＰアドレス、アプリケーション名称をチェックする。

処理Ｓ１５０３では、トラヒック学習機能部２０４は、トラヒックパターンデータ２１０を参照し、受信したパケットの送信元ＩＰアドレス、宛先ＩＰアドレス、アプリケーション名称が、既にトラヒックパターンデータ２１０に登録されているか否かを確認する。

処理Ｓ１５０４では、これらが登録されていない場合に、トラヒックパターンデータ２１０に新たな行を追加する。

処理Ｓ１５０５では、登録済みのあるいは新たに登録したトラヒックパターンデータ２１０において、最新の時間帯のＣプレーンカウンタ９０４およびＵプレーンカウンタ９０５の少なくともひとつを計上する。

処理Ｓ１５０６では、トラヒック学習機能部２０４は、カウンタの計上に基づいて、統計上必要な種々のパラメータを計算し、記録する。例えば、合計値９０６、平均値９０７、分散９０８、マハラノビス距離９０９である。

処理Ｓ１５０７では、トラヒック学習機能部２０４での学習処理が終了し、パケットは方路振分機能部２０５に転送される。

以上はトラヒック学習機能部２０４の処理の一例であり、トラヒックパターンデータ２１０もパターンデータの一例である。トラヒック学習機能部２０４は、トラヒックの傾向を把握することにより、定常状態からの変化を検知するものであり、その趣旨から逸脱しなければ、他の処理や他のデータを採用してもよい。

＜１６．エッジノードのルール作成部の動作例１＞
図１６は、エッジノード１０５のルール作成部２０７における、フィルタルールデータ２０８の作成例を示すフロー図である。この例は、図１２で説明したように、Ｕプレーントラヒックを周期的に監視し、過去データ例えば前回の値等との差分をモニタしながら、異常検出をするフローである。この処理は、定期的に行われてもよいし、トラヒックパターンデータ２１０あるいは３０４が更新されたタイミングで行ってもよい。図１６の例では、定期的に行うものとした。

処理Ｓ１６０１では、ルール作成部２０７は、Ｕプレーンのデータ量の、前回処理時との差分を計算する。

処理Ｓ１６０２では、ルール作成部２０７は、計算した差分を閾値と比較する。

処理Ｓ１６０３では、差分の閾値との比較結果で処理を分岐する。

処理Ｓ１６０４では、差分が閾値以内の場合、ルール作成部２０７は次の更新タイミングまで待機する。

処理Ｓ１６０５では、差分が閾値を超える場合、ルール作成部２０７は異常トラヒックの原因となるフローを特定する。例えば、異常トラヒックで閾値以上の割合を占めるフローを原因と特定する。

処理Ｓ１６０６では、ルール作成部２０７はフィルタルールデータ２０８に、異常トラヒックの原因となるフローに関連するＩＰアドレスやアプリケーションを登録する。あるいは、異常トラヒックの原因となるフローはリダイレクトルールデータ２０９に登録し、他のサーバに転送してもよい。他のサーバでは異常トラヒックに対して、対抗措置を講じる等を行うことができる。

＜１７．エッジノードのルール作成部の動作例２＞
図１７は、エッジノード１０５のルール作成部２０７における、フィルタルールデータ２０８の作成例を示すフロー図である。この例は、図１３で説明したように、Ｃプレーン（コネクション接続数）とＵプレーン（転送データ量）のトラヒックの相関を周期的に監視し、異常検出をするフローである。この処理は、定期的に行われてもよいし、トラヒックパターンデータ２１０あるいは３０４が更新されたタイミングで行ってもよい。図１７の例では、定期的に行うものとした。

ＣプレーンとＵプレーンの比率の計算には例えば両者の単位時間あたりの通信量の平均値からのずれをマハラノビス距離で計測するなどが考えられる。

処理Ｓ１７０１では、ルール作成部２０７は、最新のＣプレーンとＵプレーン量の相関を計算する。

処理Ｓ１７０２では、ルール作成部２０７は、計算した相関を過去のトラヒックパターンの相関と比較する。あるいは、基準となるトラヒックパターンの相関（たとえば固定値）と比較する。比較の結果、ずれ量が規定値以上の場合には、ＣプレーンとＵプレーン量の相関比率が異常と判定する。

処理Ｓ１７０３では、相関比率が正常か否かで処理を分岐する。

処理Ｓ１７０４では、比率が正常の場合、ルール作成部２０７は次の更新タイミングまで待機する。

処理Ｓ１７０５では、比率が異常の場合、ルール作成部２０７は異常トラヒックの原因となるフローを特定する。例えば、異常トラヒック中に占める割合の大きなフローを特定する。

処理Ｓ１７０６では、ルール作成部２０７はフィルタルールデータ２０８に、異常トラヒックの原因となるフローに関連するＩＰアドレスやアプリケーションを登録する。その後、処理Ｓ１７０４で待機に入る。

＜１８．エッジノードのルール作成部によるリダイレクトルール作成処理例（周期処理）＞
図１８は、エッジノードのルール作成部によるリダイレクトルール作成処理例である。＜９．トラヒックパターンデータ例＞で説明したように、エッジノード１０５のルール作成部２０７は、自らリダイレクトルールデータ２０９を生成してもよい。

ここでは、ルール作成部２０７は、一定周期でトラヒックパターンデータ２１０を参照し、ルール作成を行う周期処理とした。すなわち図１８は、リダイレクトルールデータ２０９を周期的に設定しなおすためのフローである。既に述べたように、このほかに管理サーバ１０７からの指示に基づいてリダイレクトルールの設定を変更することもありうる。ただしこれは自明な処理であるため、フローに起こすことはしない。

処理Ｓ１８０１では、ルール作成部２０７は、リダイレクトルール２０９を参照し、クラウドサーバのＩＰアドレス１１０１を検索キー＃１（送信元ＩＰアドレス）としてトラヒックパターンデータ２１０を検索する。

処理Ｓ１８０２では、トラヒックパターンデータ２１０の宛先ＩＰアドレス９０２毎に、Ｃプレーン、Ｕプレーンの合計値を計算する。

処理Ｓ１８０３では、計算した合計値が閾値を超えている宛先アドレスがあるかどうかを判定する。なお、判定においては、固定された閾値との比較の他、過去のＣプレーン、Ｕプレーンの合計値からのずれを判定してもよい。例えば、過去一定期間の合計値の平均値を閾値とする。この方式は、閾値を動的に設定できるので、システムの通常の状態を反映しやすい特長がある。

処理Ｓ１８０４では、合計値が閾値を超えている場合、リダイレクトルール２０９の該当宛先ＩＰアドレスのリダイレクト指示が「無」であるかどうかを判定する。「無」ではない場合には、一定時間経過待ち処理Ｓ１８０８に進む。

処理Ｓ１８０５では、リダイレクト指示が「無」の場合、リダイレクトルールデータ２０９において、該当する宛先アドレスの行のリダイレクト指示を「有」に設定する。

処理Ｓ１８０６では、合計値が閾値を超えていない場合、リダイレクトルールの該当宛先ＩＰアドレスのリダイレクト指示が「有」であるかどうかを判定する。「有」ではない場合には、一定時間経過待ち処理Ｓ１８０８に進む。

処理Ｓ１８０７では、リダイレクトルールデータにおいて該当する宛先アドレスの行のリダイレクト指示を「無」に設定する。

処理Ｓ１８０８では、次の処理時間になるまで待機する。

なお合計値の閾値との比較において、超過をみるための閾値と超過からの回復を見るための閾値とは同じでないほうがより好ましい。閾値が同じ場合、合計値が閾値付近で変動する場合リダイレクト指示が「有」と「無」の間を過度に変遷するためである。回復を見るための閾値は、超過を見る閾値よりも低く設定することが望ましい。

本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることが可能である。また、各実施例の構成の一部について、他の実施例の構成の追加・削除・置換をすることが可能である。

エッジサーバ１０４
エッジノード：１０５
クラウドサーバ：１０６
ユーザ：１０８
Ｍ２ＭＧＷ：１０９

Claims (2)

1. 複数のユーザ端末と、前記複数のユーザ端末と接続されるエッジノードと、前記エッジノードに接続されるネットワークと、前記ネットワークに接続される複数のサービスサーバとを備える通信システムであって、
   前記エッジノードは、
   入力されるパケットの特性を時系列的に蓄積するトラヒックパターンデータと、
   前記パケットを処理するためのルールを格納するルールデータと、
   を格納し、
   前記エッジノードは、
   前記ルールデータに基づいて前記パケットの処理を行う機能部と、
   前記機能部による処理の後に、前記入力されるパケットを、所定の宛先に向けて出力する方路振分機能部と、
   を備え、
   前記通信システムは、
   時間的な分解能を持つ前記トラヒックパターンデータの内容に基づいて、前記ルールデータを更新するルール作成部を備え、
   前記エッジノードは、
   前記トラヒックパターンデータの内容に基づいて、前記ルールデータであるフィルタルールデータを更新する前記ルール作成部と、
   前記フィルタルールデータに基づいて、前記入力されるパケットをフィルタする、前記機能部であるフィルタ機能部を備え、
   前記ルール作成部は、前記トラヒックパターンデータの内容に基づいて、異常なトラヒックを検知し、前記異常なトラヒックに関連する、送信元ＩＰアドレス、宛先ＩＰアドレス、および、アプリケーション名称の少なくとも一つを、前記フィルタルールデータに登録し、
   前記フィルタ機能部は、前記フィルタルールデータに登録された、前記送信元ＩＰアドレス、前記宛先ＩＰアドレス、および、前記アプリケーション名称の少なくとも一つを有するパケットを廃棄し、
   前記ルール作成部は、前記トラヒックパターンデータである、Ｃプレーン数とＵプレーン量の相関が、あらかじめ定めた範囲から逸脱した場合、当該トラヒックを異常として検知する、
   通信システム。
2. 複数のユーザ端末と、前記複数のユーザ端末と接続されるエッジノードと、前記エッジノードに接続されるネットワークと、前記ネットワークに接続される複数のサービスサーバとを備える通信システムであって、
   前記エッジノードは、
   入力されるパケットの特性を時系列的に蓄積するトラヒックパターンデータと、
   前記パケットを処理するためのルールを格納するルールデータと、
   を格納し、
   前記エッジノードは、
   前記ルールデータに基づいて前記パケットの処理を行う機能部と、
   前記機能部による処理の後に、前記入力されるパケットを、所定の宛先に向けて出力する方路振分機能部と、
   を備え、
   前記通信システムは、
   時間的な分解能を持つ前記トラヒックパターンデータの内容に基づいて、前記ルールデータを更新するルール作成部を備え、
   前記エッジノードは、
   前記トラヒックパターンデータの内容に基づいて、前記ルールデータであるフィルタルールデータを更新する前記ルール作成部と、
   前記フィルタルールデータに基づいて、前記入力されるパケットをフィルタする、前記機能部であるフィルタ機能部を備え、
   前記ルール作成部は、前記トラヒックパターンデータの内容に基づいて、異常なトラヒックを検知し、前記異常なトラヒックに関連する、送信元ＩＰアドレス、宛先ＩＰアドレス、および、アプリケーション名称の少なくとも一つを、前記フィルタルールデータに登録し、
   前記フィルタ機能部は、前記フィルタルールデータに登録された、前記送信元ＩＰアドレス、前記宛先ＩＰアドレス、および、前記アプリケーション名称の少なくとも一つを有するパケットを廃棄し、
   前記ルール作成部は、前記トラヒックパターンデータである、Ｃプレーン数とＵプレーン量の相関が、過去の前記トラヒックパターンデータから定めた範囲から逸脱した場合、当該トラヒックを異常として検知する、
   通信システム。

Images