(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023115996
(43)【公開日】2023-08-22
(54)【発明の名称】通信監視装置、通信監視プログラム及び通信監視方法
(51)【国際特許分類】
H04L 43/0876 20220101AFI20230815BHJP
H04L 43/12 20220101ALI20230815BHJP
【ＦＩ】
H04L43/0876
H04L43/12
【審査請求】未請求
【請求項の数】9
【出願形態】ＯＬ
(21)【出願番号】P 2022018487
(22)【出願日】2022-02-09
(71)【出願人】
【識別番号】000000295
【氏名又は名称】沖電気工業株式会社
(74)【代理人】
【識別番号】100180275
【弁理士】
【氏名又は名称】吉田 倫太郎
(74)【代理人】
【識別番号】100161861
【弁理士】
【氏名又は名称】若林 裕介
(72)【発明者】
【氏名】土江 康太
(72)【発明者】
【氏名】八百 健嗣
(57)【要約】 （修正有）
【課題】通信レートが急増した場合でも負荷を軽減しつつ、安定的に動作し続けることが可能な通信監視装置、通信監視プログラム及び通信監視方法を提供する。
【解決手段】通信監視装置１０は、監視対象ネットワークを流れる通信のトラフィックデータに基づくフロー情報を保持するキャプチャ部１０１と、フロー情報に基づいて監視対象ネットワーク内の通信について、それぞれ異なる観点で分析を行うトラフィック分析機能を複数備える分析部１０４と、キャプチャ部の負荷状態を判定する負荷状態判定処理を行い、負荷状態判定処理による判定結果に応じて、分析部を構成するトラフィック分析機能を制御するリソース制御部１０３と、を有する。
【選択図】図１
【解決手段】通信監視装置１０は、監視対象ネットワークを流れる通信のトラフィックデータに基づくフロー情報を保持するキャプチャ部１０１と、フロー情報に基づいて監視対象ネットワーク内の通信について、それぞれ異なる観点で分析を行うトラフィック分析機能を複数備える分析部１０４と、キャプチャ部の負荷状態を判定する負荷状態判定処理を行い、負荷状態判定処理による判定結果に応じて、分析部を構成するトラフィック分析機能を制御するリソース制御部１０３と、を有する。
【選択図】図１
【特許請求の範囲】
【請求項1】
監視対象ネットワークを流れる通信のトラフィックデータに基づくフロー情報を保持するキャプチャ手段と、
前記フロー情報に基づいて前記監視対象ネットワーク内の通信について、それぞれ異なる観点で分析を行う通信分析部を複数備える分析手段と、
前記キャプチャ手段の負荷状態を判定する負荷状態判定処理を行い、前記負荷状態判定処理による判定結果に応じて、前記分析手段を構成する前記通信分析部を制御するリソース制御手段と
を有することを特徴とする通信監視装置。
前記フロー情報に基づいて前記監視対象ネットワーク内の通信について、それぞれ異なる観点で分析を行う通信分析部を複数備える分析手段と、
前記キャプチャ手段の負荷状態を判定する負荷状態判定処理を行い、前記負荷状態判定処理による判定結果に応じて、前記分析手段を構成する前記通信分析部を制御するリソース制御手段と
を有することを特徴とする通信監視装置。
【請求項2】
前記リソース制御手段は、前記キャプチャ手段が高負荷状態であると判定している間、優先度の低い前記通信分析部を選択して機能を停止又は制限するように制御し、前記キャプチャ手段が低負荷状態であると判定している間、機能を停止又は制限されている前記通信分析部のうち高い優先度の前記通信分析部を選択して機能の起動又は制限の緩和をするように制御することを特徴とする請求項１に記載の通信監視装置。
【請求項3】
前記リソース制御手段は、前記通信分析部の機能的属性に基づく優先度を設定していることを特徴とする請求項２に記載の通信監視装置。
【請求項4】
前記リソース制御手段は、前記通信分析部の処理内容がリアルタイム処理不要なものである場合に優先度をより低く設定することを特徴とする請求項３に記載の通信監視装置。
【請求項5】
前記リソース制御手段は、前記通信分析部の処理内容がセキュリティに関するものである場合に優先度をより高く設定することを特徴とする請求項４に記載の通信監視装置。
【請求項6】
前記リソース制御手段は、当該通信監視装置の計算資源の使用状況を考慮して、前記分析手段を構成する前記通信分析部に対する制御内容を決定することを特徴とする請求項１～５の何れかに記載の通信監視装置。
【請求項7】
前記通信分析部が機能を停止又は制限されている間に発生したフロー情報を記録する記憶手段をさらに備え、
前記分析手段は、前記通信分析部が機能を停止又は制限されている状態から復帰した後、前記記憶手段が記憶したフロー情報の供給を受けて前記分析手段が分析処理できなかったフロー情報の分析処理を補完する補完用通信分析部をさらに備える
ことを特徴とする請求項１～６のいずれかに記載の通信監視装置。
前記分析手段は、前記通信分析部が機能を停止又は制限されている状態から復帰した後、前記記憶手段が記憶したフロー情報の供給を受けて前記分析手段が分析処理できなかったフロー情報の分析処理を補完する補完用通信分析部をさらに備える
ことを特徴とする請求項１～６のいずれかに記載の通信監視装置。
【請求項8】
コンピュータを、
監視対象ネットワークを流れる通信のトラフィックデータに基づくフロー情報を保持するキャプチャ手段と、
前記フロー情報に基づいて前記監視対象ネットワーク内の通信について、それぞれ異なる観点で分析を行う通信分析部を複数備える分析手段と、
前記キャプチャ手段の負荷状態を判定する負荷状態判定処理を行い、前記負荷状態判定処理による判定結果に応じて、前記分析手段を構成する前記通信分析部を制御するリソース制御手段と
して機能させることを特徴とする通信監視プログラム。
監視対象ネットワークを流れる通信のトラフィックデータに基づくフロー情報を保持するキャプチャ手段と、
前記フロー情報に基づいて前記監視対象ネットワーク内の通信について、それぞれ異なる観点で分析を行う通信分析部を複数備える分析手段と、
前記キャプチャ手段の負荷状態を判定する負荷状態判定処理を行い、前記負荷状態判定処理による判定結果に応じて、前記分析手段を構成する前記通信分析部を制御するリソース制御手段と
して機能させることを特徴とする通信監視プログラム。
【請求項9】
通信監視装置が行う通信監視方法において、
キャプチャ手段、分析手段、及びリソース制御手段を有し、
前記キャプチャ手段は、監視対象ネットワークを流れる通信のトラフィックデータに基づくフロー情報を保持し、
前記分析手段は、前記フロー情報に基づいて前記監視対象ネットワーク内の通信について、それぞれ異なる観点で分析を行う通信分析部を複数備え、
前記リソース制御手段は、前記キャプチャ手段の負荷状態を判定する負荷状態判定処理を行い、前記負荷状態判定処理による判定結果に応じて、前記分析手段を構成する前記通信分析部を制御する
ことを特徴とする通信監視方法。
キャプチャ手段、分析手段、及びリソース制御手段を有し、
前記キャプチャ手段は、監視対象ネットワークを流れる通信のトラフィックデータに基づくフロー情報を保持し、
前記分析手段は、前記フロー情報に基づいて前記監視対象ネットワーク内の通信について、それぞれ異なる観点で分析を行う通信分析部を複数備え、
前記リソース制御手段は、前記キャプチャ手段の負荷状態を判定する負荷状態判定処理を行い、前記負荷状態判定処理による判定結果に応じて、前記分析手段を構成する前記通信分析部を制御する
ことを特徴とする通信監視方法。
【発明の詳細な説明】
【技術分野】
【0001】
この発明は、通信監視装置、通信監視プログラム及び通信監視方法に関し、例えば、ネットワーク内に接続する機器を把握、管理するシステムに適用し得る。
【背景技術】
【0002】
現在、ＩｏＴ機器は、オフィスや工場など組織の様々な環境で活用されている。企業等の組織では、組織内のネットワークに管理外の機器が接続されていないか、マルウェア感染等により不正な通信を発生させていないか等、ネットワークに接続される機器の管理を行う。また、従来、コアネットワークのインターネットとの接続口（コアスイッチ等）を流れる通信トラフィックをミラーリングしキャプチャし分析することで、接続されている機器をリストアップするとともに機器が不正な通信を行っていないかを監視（場合によっては通信遮断まで）する通信監視装置が存在する。
【0003】
しかしながらＩｏＴ機器は、普段はインターネット接続せず、末端の生産現場やオフィス内等の閉じたネットワーク環境（エッジネットワークと呼ぶ）で使われる場合も多く、コアネットワークだけの監視だけではネットワーク全体を網羅できない場合がある。そのため、ＩｏＴ機器が設置されるエッジネットワークにも監視ポイントを設置しそこを流れるトラフィックをキャプチャし分析する通信監視装置が必要となっている。エッジネットワークに設置する通信監視装置は、監視ポイントが多いほど数が必要になるため、安価に導入できることが望まれる。したがって、エッジネットワーク向けの通信監視装置が持てる計算資源は限られたものにならざるを得ない。
【0004】
通常、エッジネットワークでは、接続される機器の台数はコアネットワークで観測される機器数に比べると少なく、監視ポイントを通過する通信トラフィックの流量（通信レート）も少ないため、安価な計算機でも十分機能を果たせる場合が多いが、一方で外部からのＩｏＴ機器を狙ったサイバー攻撃やマルウェア感染した内部ＩｏＴ機器の不正通信（内部機器への脆弱性スキャン等）が発生すると、一時的に通信レートが急増する場合があり、通信監視装置がその役割を完全に果たせない状態に陥る場合がある。例えば、通信トラフィックのキャプチャロスが発生し分析データに欠損が生じたり、過負荷状態にある分析プロセスがＯＳによりＫｉｌｌ（停止）されたりする。このような状況が発生することにより、キャプチャ部１０１やセキュリティ機能等の管理上重要な機能に支障が発生したり、止まってしまったりすると、セキュリティ・インシデントの検知ができず、検知後の通信遮断等の対処が遅れ被害が拡大してしまう恐れがある。そのため、通信レート急増時にも重要な機能の動作を継続するための方法が望まれている。
【0005】
従来、通信監視装置において、通信レートが急増した場合に負荷を軽減することが可能な技術としては、特許文献１、２の記載技術が存在する。
【0006】
特許文献１に記載されたシステムでは、監視しているネットワークの品質（通信品質と接続品質）状況を把握するために、拠点単位にパケットキャプチャ装置を設置し定期的に上位のサーバに品質情報を通知する。また、特許文献１に記載されたシステムでは、キャプチャ装置は通信のセッション毎にスループット（通信レート）を管理しており、高負荷のセッションは一時的に品質情報の測定を停止して次の周期で測定を再開する。さらに、特許文献１に記載されたシステムでは、高負荷のセッションは測定対象から除外することにより、処理負荷を抑えキャプチャ装置の低価格化が実現できる。
【0007】
また、特許文献２に記載のシステムでは、ＷｅｂサーバへのＳｌｏｗＤｏＳ攻撃への対処を前提とし、Ｗｅｂサーバに張られるセッション数と監視ポイントを流れるトラフィック流量を測定し、これらの情報をもとにＷｅｂサーバの資源異常を検知し、検知したことを契機としてトラフィックキャプチャを開始しトラフィックを分析する。特許文献２に記載のシステムは、上記のように、通常はトラフィックキャプチャを停止させ、予め定めた条件を契機としてトラフィックキャプチャを動作させることにより、常時キャプチャする場合に比べて負荷を低減できる。
【先行技術文献】
【特許文献】
【0008】
【特許文献1】特開２０１４－１７１０７６号公報
【特許文献2】特開２０１６－１４８９３９号公報
【発明の概要】
【発明が解決しようとする課題】
【0009】
しかしながら、特許文献１に記載のシステムでは、スループットの高いセッションの通信品質測定を停止してしまうため、セキュリティ監視の場合、スループットの高いセッションは攻撃の挙動である可能性が高く、通信レートが急増した場合に負荷を軽減しつつ、安定的に動作し続けるという課題に十分に対応することはできない。
【0010】
また、特許文献２に記載のシステムでは、特定の攻撃の検知を前提とした技術であるため、トラフィックキャプチャの起動契機をトラフィックデータとは別の要素から得ることができるが、より汎用的に幅広い異常の検知や、セキュリティ機能以外にも定常時の通信量や通信先情報等の可視化を行うためには、常時トラフィックキャプチャを稼働して分析する必要がある。
【0011】
以上のような問題に鑑みて、通信レートが急増した場合でも負荷を軽減しつつ、安定的に動作し続けることが可能な通信監視装置、通信監視プログラム及び通信監視方法が望まれている。
【課題を解決するための手段】
【0012】
第１の本発明は、監視対象ネットワークを流れる通信のトラフィックデータに基づくフロー情報を保持するキャプチャ手段と、前記フロー情報に基づいて前記監視対象ネットワーク内の通信について、それぞれ異なる観点で分析を行う通信分析部を複数備える分析手段と、前記キャプチャ手段の負荷状態を判定する負荷状態判定処理を行い、前記負荷状態判定処理による判定結果に応じて、前記分析手段を構成する前記通信分析部を制御するリソース制御手段とを有することを特徴とする。
【0013】
第２の本発明の通信監視プログラムは、コンピュータを、監視対象ネットワークを流れる通信のトラフィックデータに基づくフロー情報を保持するキャプチャ手段と、前記フロー情報に基づいて前記監視対象ネットワーク内の通信について、それぞれ異なる観点で分析を行う通信分析部を複数備える分析手段と、前記キャプチャ手段の負荷状態を判定する負荷状態判定処理を行い、前記負荷状態判定処理による判定結果に応じて、前記分析手段を構成する前記通信分析部を制御するリソース制御手段として機能させることを特徴とする。
【0014】
第３の本発明は、通信監視装置が行う通信監視方法において、キャプチャ手段、分析手段、及びリソース制御手段を有し、前記キャプチャ手段は、監視対象ネットワークを流れる通信のトラフィックデータに基づくフロー情報を保持し、
前記分析手段は、前記フロー情報に基づいて前記監視対象ネットワーク内の通信について、それぞれ異なる観点で分析を行う通信分析部を複数備え、前記リソース制御手段は、前記キャプチャ手段の負荷状態を判定する負荷状態判定処理を行い、前記負荷状態判定処理による判定結果に応じて、前記分析手段を構成する前記通信分析部を制御することを特徴とする。
前記分析手段は、前記フロー情報に基づいて前記監視対象ネットワーク内の通信について、それぞれ異なる観点で分析を行う通信分析部を複数備え、前記リソース制御手段は、前記キャプチャ手段の負荷状態を判定する負荷状態判定処理を行い、前記負荷状態判定処理による判定結果に応じて、前記分析手段を構成する前記通信分析部を制御することを特徴とする。
【発明の効果】
【0015】
本発明によれば、通信レートが急増した場合でも負荷を軽減しつつ、安定的に動作し続けることが可能な通信監視装置、通信監視プログラム及び通信監視方法を提供することができる。
【図面の簡単な説明】
【0016】
【図1】第１の実施形態に係る通信監視装置の機能的構成について示したブロック図である。
【図2】第１、第２の実施形態に関係する装置の接続構成について示したブロック図である。
【図3】第１、第２の実施形態に係る通信監視装置のハードウェア構成（計算資源の構成）について示したブロック図である。
【図4】実施形態に係る通信監視装置におけるリソース制御に係る構成について示したブロック図である。
【図5】第１の実施形態に係る優先順位情報の構成例について示した図である。
【図6】第１の実施形態に係るリソース使用状況情報の構成例について示した図である。
【図7】第１の実施形態に係る通信監視装置の動作について示したフローチャート（その１）である。
【図8】第１の実施形態に係る通信監視装置の動作について示したフローチャート（その２）である。
【図9】第１の実施形態に係る通信監視装置の動作について示したフローチャート（その３）である。
【図10】第２の実施形態に係る通信監視装置の機能的構成について示したブロック図である。
【図11】第２の実施形態に係る通信監視装置を構成する分析部の内部構成の例について示したブロック図である。
【図12】第２の実施形態に係る通信監視装置の動作について示したフローチャート（その１）である。
【図13】第２の実施形態に係る通信監視装置の動作について示したフローチャート（その２）である。
【発明を実施するための形態】
【0017】
（Ａ）第１の実施形態
以下、本発明による通信監視装置、通信監視プログラム及び通信監視方法の第１の実施形態を、図面を参照しながら詳述する。
以下、本発明による通信監視装置、通信監視プログラム及び通信監視方法の第１の実施形態を、図面を参照しながら詳述する。
【0018】
【0019】
ここでは、通信監視装置１０は、監視対象（分析対象）となる監視対象ネットワークＮ１に接続された通信端末３０（３０ー１、３０－２、・・・）から発生するトラフィックを分析する処理を行うものであるものとする。図２の構成例では、監視対象ネットワークＮ１には、ネットワーク機器として、ネットワークスイッチ２０（レイヤ２スイッチ）が配置されているものとする。
【0020】
図２の構成例では、各通信端末３０が、ネットワークスイッチ２０（レイヤ２スイッチ）に接続されており、ネットワークスイッチ２０がインターネットＮ２へと通信可能な経路に接続されている。なお、ネットワークスイッチ２０とインターネットＮ２との間のネットワーク構成については限定されないものである。また、ネットワークスイッチ２０では、接続される通信端末３０の数は限定されないものであり、運用中に増減する場合もあるものとして説明する。
【0021】
各通信端末３０の具体的な機能・構成や通信内容については限定されないものである。通信端末３０としては、例えば、ＩｏＴ機器、クライアントＰＣ、サーバ装置等種々の端末を適用することができる。ここでは、基本的に各通信端末３０は、インターネットＮ２上の通信装置（例えば、通信端末３０からデータ受信するサーバや、通信端末３０へアクセスする端末等）と通信するものとして説明する。
【0022】
図２の例では、通信監視装置１０は、ネットワークスイッチ２０に接続されているものとする。ここでは、ネットワークスイッチ２０において、インターネットＮ２側と接続するＬＡＮポート（イーサネット（登録商標）ポート）で送受信されるパケット（イーサネットフレーム）が、通信監視装置１０が接続するポートにミラーリングされる設定（いわゆるポートミラー接続）となっているものとする。これにより、通信監視装置１０では、ネットワークスイッチ２０の配下の通信端末３０とインターネットＮ２との間を流れるトラフィック（パケット）を収集することができる。この実施形態では、ネットワークスイッチ２０のポートミラー設定により、通信監視装置１０に通信端末３０とインターネットＮ２との間を流れるトラフィックに基づくデータ（以下、単に「トラフィックデータ」とも呼ぶ）を供給する構成となっているが、通信監視装置１０にトラフィックデータを供給する具体的な構成については限定されないものである。言い換えると、この実施形態では、ネットワークスイッチ２０が、監視対象ネットワークＮ１上の監視ポイント（分析ポイント）に配置されており、この監視ポイントから通信監視装置１０がトラフィックデータの供給を受けて分析処理を行うことになる。
【0023】
通信監視装置１０は、トラフィックデータに基づいて、各通信端末３０に関する分析を行う装置である。
【0024】
次に、通信監視装置１０のハードウェア構成の例について説明する。
【0025】
通信監視装置１０は、全てハードウェア（例えば、専用チップ等）により構成するようにしてもよいし一部又は全部についてソフトウェア（プログラム）として構成するようにしてもよい。通信監視装置１０は、例えば、プロセッサ及びメモリを有するコンピュータにプログラム（実施形態の通信監視プログラムを含む）をインストールすることにより構成するようにしてもよい。
【0026】
図３は、通信監視装置１０のハードウェア構成の例について示したブロック図である。
【0027】
図３では、通信監視装置１０を、ソフトウェア（コンピュータ）を用いて構成する際のハードウェア構成の例について示している。
【0028】
図３に示す通信監視装置１０は、ハードウェア的な構成要素として、プログラム（実施形態の通信監視プログラムを含む）がインストールされたコンピュータ４００を有している。また、コンピュータ４００は、通信監視プログラム専用のコンピュータとしてもよいし、他の機能のプログラムと共用される構成としてもよい。
【0029】
図３に示すコンピュータ４００は、ＣＰＵ４０１、一次記憶部４０２、及び二次記憶部４０３を有している。一次記憶部４０２は、ＣＰＵ４０１の作業用メモリ（ワークメモリ）として機能する記憶手段であり、例えば、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等の高速動作するメモリを適用することができる。二次記憶部４０３は、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）やプログラムデータ（実施形態に係る通信監視プログラムのデータを含む）等の種々のデータを記録する記憶手段であり、例えば、ＦＬＡＳＨメモリやＨＤＤやＳＳＤ等の不揮発性メモリを適用することができる。この実施形態のコンピュータ４００では、ＣＰＵ４０１が起動する際、二次記憶部４０３に記録されたＯＳやプログラム（実施形態に係る通信監視プログラムを含む）を読み込み、一次記憶部４０２上に展開して実行する。
【0030】
以上のように、通信監視装置１０を構成するコンピュータ４００では、主な計算資源（コンピュータリソース）として、ＣＰＵ４０１及び一次記憶部４０２（いわゆるメモリ）を有している。
【0031】
【0032】
図１は、通信監視装置１０の機能的構成について示したブロック図である。
【0033】
図４は、通信監視装置１０におけるリソース制御に係る構成について示したブロック図である。
【0034】
図１に示すように、通信監視装置１０は、キャプチャ部１０１、データベース処理部１０２、リソース制御部１０３、分析部１０４、及び表示部１０５を有している。
【0035】
通信監視装置１０は、例えば、コンピュータ４００上にプログラム（実施形態に係る通信監視プログラムを含む）をインストールすることにより実現することができる。
【0036】
キャプチャ部１０１は、ミラーリングにより供給されたトラフィックデータについて、フロー単位（例えば、送信元ＩＰアドレス、送信元ポート番号、宛先ＩＰアドレス、及び宛先ポート番号の組合せにより分類される単位）に分類して各フローのフロー情報（フローデータ）としてまとめる処理を行う。ここで、フロー情報とは、例えば、フロー毎の通信バイト数やパケット到着間隔等のトラフィック分析に必要とされる通信情報であるものとする。キャプチャ部１０１は、フロー毎のフロー情報を定期又は不定期の間隔でデータベース処理部１０２に供給して蓄積させる。キャプチャ部１０１は、生成したフロー情報をデータベース処理部１０２に供給する。
【0037】
また、キャプチャ部１０１は、一定間隔又は自身の負荷状況に応じた間隔で、通信監視装置１０に係る負荷状況を示す情報（以下、「負荷情報」と呼ぶ）を、データベース処理部１０２を介してリソース制御部１０３に通知する。負荷情報には、例えば、当該通信監視装置１０の通信レート（トラフィックデータの受信状況（例えば、パケット受信間隔やパケットのデータ量等）に基づく通信レート）、処理待ちデータ数（例えば、受信したが処理が追い付かず未解析状態のデータ数）、管理フロー数（例えば、トラフィックデータから観測されるアクティブなフロー（例えば、直近の所定時間内にトラフィックの発生しているフロー）の数）等を含むようにしてもよい。
【0038】
データベース処理部１０２は、供給されるデータを蓄積管理すると共に、他の要素の要求に応じて配信する処理を行う。データベース処理部１０２の具体的な構成については限定されないものであり、種々の構成を適用することができる。この実施形態では、データベース処理部１０２は、処理効率を重視して、Ｐｕｂｌｉｓｈ－Ｓｕｂｓｃｒｉｂｅ型（以下、「Ｐｕｂ－Ｓｕｂ型」と呼ぶものとする）の通知モデル（メッセージモデル）を搭載したデータベースを適用するものとして説明する。なお、データベース処理部１０２の構成は、Ｐｕｂ－Ｓｕｂ型に限定されず種々の構成（例えば、リレーショナルデータベース等）を適用することができる。
【0039】
Ｐｕｂ／Ｓｕｂ型のデータベース（メッセージ通知モデル）では、データ（メッセージ）を作成してＰｕｂｌｉｓｈ（送信；通知）する送信側のクライアントを「Ｐｕｂｌｉｓｈｅｒ」（発行者；送信者）と呼び、データのＳｕｂｓｃｒｉｂｅ（Ｐｕｂｌｉｓｈされるデータの購読申込み；受信）を受ける受信側のクライアントを「Ｓｕｂｓｃｒｉｂｅｒ」（購読者；受信者）と呼ぶ。また、Ｐｕｂ／Ｓｕｂ型のデータベースでは、Ｐｕｂｌｉｓｈされるデータは、「チャネル」と呼ばれる論理的な通信路を通して、Ｓｕｂｓｃｒｉｂｅｒ側に通知される。データベース処理部１０２に適用可能なＰｕｂ－Ｓｕｂ型のデータベースとしては、例えば、Ｒｅｄｉｓ等のプラットフォームを適用することができる。
【0040】
分析部１０４は、データベース処理部１０２におけるフロー情報のチャネルからフロー情報の供給を受けると、複数の異なる観点でのトラフィック分析処理を行う。そして、分析部１０４は、トラフィック分析機能の出力結果を表示部１０５に供給する。
【0041】
リソース制御部１０３はキャプチャ部１０１からＰｕｂｌｉｓｈされた負荷情報等をもとに、キャプチャ部１０１の負荷状態を判断し、その負荷状態に応じて、分析部１０４のトラフィック分析機能郡によるリソース使用を制御する。また、この実施形態では、リソース制御部１０３は通信監視装置１０全体の計算資源（すなわち、コンピュータ４００の計算資源）の使用状況（例えば、ＣＰＵ使用率やメモリ使用率）も考慮して、キャプチャ部１０１の負荷状態や、分析部１０４のトラフィック分析機能郡に対する制御内容を決定するようにしてもよい。
【0042】
表示部１０５は、トラフィック分析機能の出力結果をユーザに表示する表示手段を有する。表示部１０５による表示手段の構成や表示内容の詳細については限定されないものである。表示部１０５は、例えば、通信端末３０ごとに過去一定期間の通信量や通信先情報、セキュリティ検知情報をＷｅｂページとして表示するようにしてもよい。
【0043】
次に、分析部１０４を構成するトラフィック分析機能の詳細について説明する。
【0044】
なお、以下では、この複数のトラフィック分析機能の集合体をトラフィック分析機能郡と呼ぶものとする。
【0045】
分析部１０４は、各トラフィック分析機能についてそれぞれ別個のプログラム（コンピュータ上のプログラム）として起動／管理するものとする。なお、この実施形態では、通信監視装置１０を構成する各要素は、上記の通り１つの計算資源（コンピュータ４００の計算資源）のプールを共有しており、分析部１０４の内部についても同様に上記の計算資源の一部を、さらに複数のトラフィック分析機能に対応するプログラムで分け合っている構成であるものとする。分析部１０４において、各トラフィック分析機能に対応するプログラムを管理／起動する環境については限定されないものであるが、例えば、１つのトラフィック分析機能に対応するプログラム（以下、「分析プログラム」と呼ぶ）に、１つのコンテナ（例えば、Ｄｏｃｋｅｒ等のプラットフォームで管理されるコンテナ）を割当てて分析プログラムを実行するようにしてもよい。分析部１０４では、各分析プログラムの識別子（プログラム名、プロセス名、プログラムファイル名等）と、各分析プログラムが確保（使用）している計算資源（ＣＰＵ使用率及びメモリ使用率）の認識及び制御が可能な構成であるものとして説明する。
【0046】
そして、ここでは、トラフィック分析機能郡を構成するトラフィック分析機能は、セキュリティ性の面（セキュリティ面の属性）から、直接セキュリティに関連する機能（以下、「セキュリティ機能」と呼ぶ）、又は直接セキュリティと関連しない機能（以下、「非セキュリティ機能」と呼ぶ）のいずれか属性に分類が可能であるものとする。また、ここでは、トラフィック分析機能郡を構成する機能は、リアルタイム性の面（リアルタイム性の面の属性）から、リアルタイムでの処理が必須となる機能（以下、「リアルタイム必須機能」と呼ぶ）、又はリアルタイムでの処理が不要な（必須でない）機能（以下、「リアルタイム不要機能」と呼ぶ）のいずれかに分類されるものとして説明する。さらに、ここでは、トラフィック分析機能郡を構成するトラフィック分析機能のうち、セキュリティ機能の属性となる機能の集合体を「セキュリティ機能群」と呼び、非セキュリティ機能の属性となる機能の集合体を「非セキュリティ機能群」と呼ぶものとする。
【0047】
そして、ここでは、トラフィック分析機能郡を構成する非セキュリティ機能群には、各通信端末３０の通信量を集計する機能（以下、「通信量集計機能」と呼ぶ）の分析プログラムＰＡ１０１や、通信端末３０ごとにどことどのような通信を行っているかを集計する機能（以下、「通信先情報集計機能」と呼ぶ）の分析プログラムＰＡ１０２等が含まれるものとする。また、ここでは、トラフィック分析機能郡を構成するセキュリティ機能群には、通信端末３０ごとの普段（定常時）の通信パターンと異なる不正通信パターンを検知する機能（以下、「異常検知機能」と呼ぶ）の分析プログラムＰＡ２０１や、各通信端末３０がソフトウェアのバージョンが古いこと等の理由で既知の脆弱性を保有しているかを検査する機能（以下、「脆弱性検査機能」と呼ぶ）の分析プログラムＰＡ２０２等が含まれるものとする。
【0048】
また、ここでは、各分析プログラムには、各属性を示す付加情報（以下、「タグ情報」と呼ぶ）を付加するようにしてもよい。タグ情報は、例えば、分析プログラムのプログラム名（プロセス名；実行ファイル名）の一部に含めるようにしてもよい。この実施形態の例では、セキュリティ機能に対応するタグ情報（符号）を「セ」、非セキュリティ機能に対応するタグ情報（符号）を「非セ」、リアルタイム不要機能に対応するタグ情報（符号）を「リ不」と表すものとする。なお、ここでは、リアルタイム必須機能については明示的にタグ情報を設けずに、リアルタイム不要機能に対応するタグ情報（リ不）が付いていない分析プログラムはリアルタイム必須機能であることを示すものとする。なお、リアルタイム必須機能の分析プログラムについては明示的に「リ」等のタグ情報を付加するようにしてもよい。また、各属性に対応するタグ情報については上記の形式に限定されず種々の文字を適用するようにしてもよい。例えば、「セ」を「Ｓ」、「非セ」を「ＮＳ」、「リ不」を「ＮＲ」等に置き換えるようにしてもよい。
【0049】
ここでは、タグ情報は、プログラム名（プロセス名）の先頭部分に「＿」（アンダーバー）で区切って付加（配置）されるものとして説明する。例えば、先頭が「セ＿・・・」というプログラム名（プロセス名）の機能は、セキュリティ機能で且つリアルタイム必須機能であることを示している。また、例えば、先頭が「セ＿リ不＿・・・」というプログラム名（プロセス名）の機能はセキュリティ機能で且つリアルタイム不要機能であることを示している。さらに、例えば、先頭が「非セ＿・・・」というプログラム名（プロセス名）の機能は非セキュリティ機能群で且つリアルタイム必須機能であることを示している。そこで、ここでは、異常検知機能のプログラム名（プロセス名）を「セ_異常検知機能」、脆弱性検査機能のプログラム名（プロセス名）を「セ_リ不_脆弱性検査機能」、通信量表示機能のプログラム名（プロセス名）を「非セ_通信量表示機能」、通信先情報表示機能のプログラム名（プロセス名）を「非セ_通信先情報表示機能」とそれぞれ表すものとする。
【0050】
次に、リソース制御部１０３がリソース制御処理を行う際に参考とする情報について説明する。
【0051】
上記の通り、リソース制御部１０３は、負荷情報等に基づいて、分析部１０４のトラフィック分析機能郡によるリソース使用を制御する。リソース制御部１０３は、リソース制御の内容（各分析プログラムに対する制御内容）を決定するにあたって、分析プログラム（トラフィック分析機能）の属性に応じた優先順位を示す情報である優先順位情報１０３ａと、分析部１０４で実行される各分析プログラムによるリソース使用状況を示すリソース使用状況情報１０３ｂを参照する。
【0052】
図５は、優先順位情報１０３ａの構成例について示した図である。
【0053】
図５では、優先順位情報１０３ａの内容をテーブル形式（表形式）で示している。
【0054】
図５では、分析プログラム（トラフィック分析機能）の属性に応じた優先度を「高、中、低」の三段階で示している。図５では、セキュリティ機能で且つリアルタイム必須機能の分析プログラム（タグ情報が「セ＿」となる分析プログラム）について「高」（１番目）の優先度を定義している。また、図５では、非セキュリティ機能で且つリアルタイム必須機能の分析プログラム（タグ情報が「非セ＿」となる分析プログラム）について「中」（２番目）の優先度を定義している。さらに、図５では、リアルタイム不要機能の分析プログラム（タグ情報が「セ＿リ不＿」または「非セ＿リ不＿」となる分析プログラム）について「低」（３番目）の優先度を定義している。なお、優先順位情報１０３ａにおける優先度の段階数や各段階に対応する属性（タグ情報）の組合せについては図５の例に限定されず種々の構成を適用することができる。
【0055】
図６は、リソース使用状況情報１０３ｂの構成例について示した図である。
【0056】
図６では、リソース使用状況情報１０３ｂの内容をテーブル形式（表形式）で示している。
【0057】
図６では、プログラム名（分析プログラムのプログラム名）ごとにリソース利用量の情報を表示している。図５の例では、リソース使用量の情報としてＣＰＵ利用率（単位は［％］）とメモリ使用量（単位は［％］）を表示している。
【0058】
リソース制御部１０３は、定期又は不定期の間隔で分析部１０４における各分析プログラムのリソース使用量を取得してリソース使用状況情報１０３ｂを更新する。
【0059】
リソース制御部１０３が分析プログラムごとのリソース使用状況の情報を取得する方法については限定されないものであるが、例えば、通信監視装置１０がＬＩＮＵＸ（登録商標）ベース（ＯＳ）で動作する環境であれば、ｔｏｐコマンド等のリソース使用量を取得するコマンドの実行結果から、分析プログラムごと（分析プログラムのプロセスごと）のＣＰＵ利用率やメモリ使用量の情報を取得して、リソース使用状況情報１０３ｂを更新することができる。リソース制御部１０３がリソース使用状況情報１０３ｂを更新するタイミングについては限定されないものである。例えば、リソース制御部１０３は、低負荷状態から高負荷状態を判定したタイミングで、リソース使用状況情報１０３ｂを更新するようにしてもよい。また、リソース制御部１０３は、低負荷状態時にも定期的（例えば１０秒間隔）に、リソース使用量の情報を取得しておいて、高負荷状態判定時に直近数回分の取得結果の平均値をリソース使用状況情報１０３ｂに入力するようにしてもよい。
【0060】
次に、トラフィック分析機能郡に対するリソース制御の具体的内容の例について説明する。
【0061】
リソース制御部１０３が、通信監視装置１０の負荷状態を判定する方法については限定されないものである。ここでは、リソース制御部１０３は、負荷情報等に基づいて通信監視装置１０の負荷状態の判定を行うものとする。上記の通り、負荷情報には、通信レート、処理待ち数、及び管理フロー数の情報が含まれる。例えば、リソース制御部１０３は、通信レート、処理待ち数、管理フロー数それぞれに対し予め閾値を設定しておき、いずれかの指標が閾値を超過したか否かに応じて負荷状態を判定するようにしてもよい。また、例えば、リソース制御部１０３は、いずれかの指標が閾値を超過した場合に高負荷状態と判定し、いずれの指標も閾値を超過しない場合低負荷状態と判定するようにしてもよい。
【0062】
この実施形態の例では、リソース制御部１０３は、キャプチャ部１０１の負荷状態が低負荷状態または高負荷状態にあるかを判断し、高負荷状態にあると判断した場合、分析部１０４のトラフィック分析機能郡によるリソース使用を制限（低減）するように制御し、高負荷状態から低負荷状態に遷移した場合には高負荷状態のときに行った制限を緩和する制御を行うものとする。例えば、リソース制御部１０３は、キャプチャ部１０１の負荷状態が高負荷状態であると判断した場合、分析プログラム（トラフィック分析機能）ごとに属性に基づく優先度を認識し、分析部１０４に対して、優先度が低い分析プログラムに対して機能制限停止を指示する。そして、リソース制御部１０３は、キャプチャ部１０１の負荷状態が高負荷状態から低負荷状態に遷移したと判断した場合、分析部１０４に対して、機能制限／停止した分析プログラムに対する制限の緩和又は起動を指示する。
【0063】
また、リソース制御部１０３は、通信監視装置１０（全体）の計算資源の使用状況を考慮して高負荷状態や、各分析プログラムに対する制御内容を決定するようにしてもよい。計算資源の使用状況とは、例えば、当該通信監視装置１０を構成するコンピュータ４００のＯＳから取得できる全体のＣＰＵ使用率やメモリ使用率等が挙げられる。例えば、リソース制御部１０３は、ＣＰＵ使用率（ＣＰＵ４０１の使用率）が１００％に達している場合や、メモリ使用率（一次記憶部４０２の使用率）が所定以上となっている場合や、メモリのスワップ（一次記憶部４０２と二次記憶部４０３との間のスワップ）が発生している場合等に、通信監視装置１０全体の計算資源が逼迫（過負荷状態）であると判断するようにしてもよい。リソース制御部１０３は、例えば、ＬｉｎｕｘＯＳにおけるコマンド（例えばＦｒｅｅコマンド等）を用いて、使用済のスワップ領域のデータ量やメモリ使用率（例えば、ｕｓｅｄメモリとｆｒｅｅメモリからメモリ使用率）を把握することができる。リソース制御部１０３は、例えば、使用済のスワップ領域が所定以上（例えば、０ｋｂｙｔｅｓより大きい）である場合に、当該通信監視装置１０の計算資源が逼迫（過負荷状態）していると判断してもよい。
【0064】
この実施形態では、リソース制御部１０３は、データベース処理部１０２に対して、分析部１０４のリソース使用を制御するための情報（以下、「リソース制御情報」と呼ぶ）をＰｕｂｌｉｓｈするものとする。そして、分析部１０４の各分析プログラムは、リソース制御情報のチャネルの情報をＳｕｂｓｃｒｉｂｅして、当該リソース制御情報の宛先が自身であった場合、当該リソース制御情報に従って自身（分析プログラム）を制御する。
【0065】
リソース制御情報には、制御対象の分析プログラムの識別子（例えば、プログラム名）と、当該分析プログラムに対して要求するリソース制御内容を示す情報（以下、「制御要求情報」と呼ぶ）を含むようにしてもよい。この実施形態には、分析プログラムのリソース制御内容（制御要求情報）には、少なくとも分析プログラムの停止要求、機能制限要求、起動要求、機能緩和要求のいずれかの指示を含むようにしてもよい。
【0066】
上記の通り、リソース制御部１０３は、各分析プログラムの属性に基づく優先度を考慮してリソース制御の内容を決定する。
【0067】
例えば、リアルタイム不要機能（例えば、脆弱性検査機能の分析プログラム）については、フロー情報を処理する間隔を長くするように機能制限すること等で当該機能による計算資源の占有率を下げることができる。また、リアルタイム必須機能（例えば、通信量表示機能）については、受信したフロー情報をランダムに破棄して処理しないようにする（処理対象のフロー情報を間引きする）ように機能制限することで処理負荷を下げることができる。
【0068】
この実施形態の例では、リソース制御部１０３が制御要求情報に制限要求／緩和要求を設定する場合には、当該制限要求／緩和要求にその制限の量（大きさ）を示す情報（以下、「制限量」と呼ぶものとする）が付加されるものとする。制限量は、例えば、０より大きく１以下の値としてもよい。分析部１０４では、分析プログラムごとの制限量のカウンタ（以下、「制限量カウンタ」と呼ぶ）が設定されており、ある分析プログラムについて、制限要求があった場合は当該分析プログラムの制限量カウンタの値を加算（付加された制限量分加算）し、緩和要求があった場合は当該分析プログラムの制限量カウンタの値を減算（付加された制限量分減算）する。ここで、制限量カウンタの値の初期値は０で上限値は１であるものとする。すなわち、制限量カウンタの値が０の場合は全く制限なく動作することを表し、制限量カウンタの値が１の場合は停止を意味する。
【0069】
そして、分析部１０４は、リアルタイム不要機能の分析プログラムについては、制限量カウンタの値に応じて、実行間隔の長さを決定（例えば、制限量カウンタの値が大きいほど実行間隔を長くする）するようにしてもよい。また、分析部１０４は、リアルタイム必須機能については、制限量カウンタの値に応じて、処理するフロー情報を破棄する確率（以下、「フロー情報破棄率」と呼ぶ）を調整する（例えば、制限量カウンタの値が大きいほどフロー情報破棄率を高くする）ようにしてもよい。また、分析部１０４は、制限量カウンタの値が上限値（ここでは１）に達した分析プログラムについては動作を停止するようにしてもよい。
【0070】
例えば、リソース制御部１０３は、キャプチャ部１０１が高負荷状態と判断した場合、優先順位情報１０３ａに従い、優先度の低い分析プログラム（トラフィック分析機能）から順に選択するようにしてもよい。例えば、高負荷状態でリソース使用状況情報１０３ｂの内容が図６のような内容であった場合、リソース制御部１０３は、最も優先度の低い分析プログラムとして、優先度「低」である「セ_リ不_脆弱性検査機能」を制御対象として選択し、「セ_リ不_脆弱性検査機能」について機能制限／停止の要求を行う。
【0071】
例えば、リソース制御部１０３は、付加情報に基づいてキャプチャ部１０１が高負荷状態と判断し、且つ、通信監視装置１０全体の計算資源が逼迫していると判断した場合、制御対象として選択した分析プログラムに対して最初から停止要求を行うようにしてもよい。また、例えば、リソース制御部１０３は、付加情報に基づいてキャプチャ部１０１が高負荷状態と判断し、且つ、通信監視装置１０全体の計算資源が逼迫していないと判断した場合、制御対象として選択した分析プログラムに対して制限要求を行うようにしてもよい。リソース制御部１０３において、一度の制限要求に設定する制限量の値は限定されないものであるが、ここでは、固定値として０．２を設定するものとする。
【0072】
なお、リソース制御部１０３は、例えば、ある分析プログラムに機能制限／停止要求を送信後、通信監視装置１０の計算資源（ＣＰＵ利用率とメモリ使用率）を継続確認し、機能制限／停止をかける前より負荷が大きくなったときに、再度当該分析プログラムを選択して機能制限／停止を行うようにしてもよい。
【0073】
次に、リソース制御部１０３が制御対象として「セ_リ不_脆弱性検査機能」を選択した後の処理の例について説明する。
【0074】
ここでは、まず、リソース制御部１０３が制御対象として「セ_リ不_脆弱性検査機能」を選択し、「セ_リ不_脆弱性検査機能」に対する機能制限／停止の要求が設定されたリソース制御情報を生成して、データベース処理部１０２にＰｕｂｌｉｓｈしたものとする。なお、リソース制御情報に停止要求が設定されている場合には制限量については付加されていなくてもよい。また、リソース制御情報において、停止要求に替えて、停止要求に相当する制限量（ここでは１）を設定するようにしてもよい。
【0075】
リソース制御部１０３は、「セ_リ不_脆弱性検査機能」に対するリソース制御情報（機能制限／停止の要求）を送信後も高負荷状態が継続する場合（より負荷が大きくなった場合も含む）、さらなる負荷低減を図るために、新たに制限対象の分析プログラムを選択して、リソース制御情報（機能制限／停止の要求）を送信する処理を繰り返す。このとき、リソース制御部１０３は、最も優先度の低い分析プログラム（最も優先度の低い分析プログラムが複数ある場合は、その中で最も負荷の高い分析プログラム）を選択して、機能制限／停止の要求のリソース制御情報を生成する。このとき、リソース制御部１０３は、最も優先度の低い分析プログラムが停止状態の場合（制限値カウンタの値が上限値になっている場合を含む）は、その次に優先度の低い分析プログラムを選択して機能制限／停止の要求を行う。例えば、リソース使用状況情報１０３ｂが図６のような内容だった場合、「セ_リ不_脆弱性検査機能」の次に優先度が低い分析プログラムは、「非セ_通信量表示機能」又は「非セ_通信先情報表示機能」となるが、「非セ_通信先情報表示機能」の方が負荷が高いため、「非セ_通信先情報表示機能」が選択されることになる。
【0076】
また、リソース制御部１０３は、高負荷状態が解消して低負荷状態に遷移したと判断すると、機能制限／停止されている分析プログラムの中から最も優先度の高い分析プログラムを選択（該当する優先度の分析プログラムが複数ある場合は、任意の方法によりいずれかの分析プログラムを選択）して、起動要求又は緩和要求のリソース制御情報を生成してＰｕｂｌｉｓｈする。つまり、このとき、リソース制御部１０３は、機能制限／停止の逆手順の処理を行うことになる。そして、リソース制御部１０３は、その後、機能制限／停止されている分析プログラムが存在する状態で、低負荷状態を継続して検知する場合、同様に機能制限／停止されている分析プログラムの中から最も優先度の高い分析プログラムを選択して、起動要求又は緩和要求のリソース制御情報を生成してＰｕｂｌｉｓｈする処理を繰り返す。
【0077】
以上のように、第１の実施形態の通信監視装置１０では、エッジネットワークの接続ポイント（例えば、ネットワークスイッチ２０のポート）をミラーリングすることによって、接続ポイントを流れる通信トラフィックをキャプチャし、キャプチャした通信トラフィックデータから、接続されている機器情報（ＩＰアドレス、ＭＡＣアドレス等）や機器の通信量・通信先情報を可視化する非セキュリティ機能と、不正通信検知や脆弱性検知等の機器の異常を検知するセキュリティ機能を有し、通信レートの急増等による処理負荷増で計算資源が枯渇しそうになったことを検知すると、管理上優先度の低い機能（例えば非セキュリティ機能）を一時的に制限、または停止させることにより計算資源を確保する。
【0078】
【0079】
まず、図７のフローチャートを用いて通信監視装置１０が行うトラフィックデータ分析処理の流れについて説明する。
【0080】
キャプチャ部１０１が、ミラーリングしているネットワークスイッチ２０からトラフィックデータを受信すると（Ｓ１０１）、トラフィックデータからフローを抽出し、抽出したフロー情報（例えば、フロー毎の通信バイト数やパケット到着間隔等のトラフィック分析に必要とされる通信情報）を作成する（Ｓ１０２）キャプチャ部１０１は、当該フローが初めて登場した場合、当該フローをフロー情報とともに管理フローに追加する。キャプチャ部１０１は、受信したフローが管理フローに含まれる場合、管理フロー内のフロー情報を更新する。
【0081】
そして、キャプチャ部１０１は、予め決められたタイミングでフロー情報をデータベース処理部１０２にＰｕｂｌｉｓｈする。キャプチャ部１０１が、フロー情報をＰｕｂｌｉｓｈするタイミングは限定しないが、例えば当該フローの受信パケット数が１０の倍数のときに通知したり、前回Ｐｕｂｌｉｓｈしてから１分経過で通知したりする方法を適用するようにしてもよい。
【0082】
データベース処理部１０２は、フロー情報のＰｕｂｌｉｓｈを受信すると、フロー情報のチャネルをＳｕｂｓｃｒｉｂｅしている分析部１０４の各分析プログラム（トラフィック分析機能）にフロー情報を通知する。そして、分析部１０４では、各分析プログラム（トラフィック分析機能）がフロー情報を受信すると、各々の分析の観点でトラフィック分析を実行する（Ｓ１０３）。この時、いずれかの分析プログラムで機能制限状態にある場合、当該分析プログラムは、制限の大きさ（制限値カウンタの値）に応じた確率で当該フロー情報を処理するか否かを判断し、処理しないと判断された場合、当該フロー情報を破棄する。
【0083】
分析部１０４は各分析プログラムの処理が完了すると、分析結果を表示部１０５に通知する。
表示部１０５は、分析部１０４から受信した受信結果を蓄積し、図示しない端末（例えば、オペレータ等のユーザが使用する端末）から要求があると分析結果を出力（表示）する。
表示部１０５は、分析部１０４から受信した受信結果を蓄積し、図示しない端末（例えば、オペレータ等のユーザが使用する端末）から要求があると分析結果を出力（表示）する。
【0084】
【0085】
まず、キャプチャ部１０１は、定期的又は不定期の間隔で負荷情報として、監視対象ネットワークＮ１との通信レート、処理待ちデータ数、管理フロー数を定期的に集計し、データベース処理部１０２にＰｕｂｌｉｓｈする。キャプチャ部１０１が負荷情報を通知する通知間隔は、前回集計時の負荷の大きさによって動的に変更され、負荷情報の各指標値が大きくなると通知間隔を短くし、負荷情報の各指標値が小さくなると通知間隔を長くするようにしてもよい。データベース処理部１０２は、キャプチャ部１０１から負荷情報のＰｕｂｌｉｓｈを受けると、当該チャネルをＳｕｂｓｃｒｉｂｅしているリソース制御部１０３に負荷情報を通知する（Ｓ２０１）。
【0086】
リソース制御部１０３は負荷情報を受信すると、キャプチャ部１０１が高負荷状態にあるかを判定する（Ｓ２０２、Ｓ２０３）。このとき、リソース制御部１０３は、負荷情報のいずれかの指標値が予め定められた閾値を超過する場合、高負荷状態と判定し、そうでない場合は、低負荷状態と判定する。通信監視装置１０は、ステップＳ２０２、Ｓ２０３で、高負荷状態と判定された場合後述するステップＳ２０４から動作し、低負荷状態と判定された場合上述のステップＳ２０１に戻って動作する。
【0087】
上述のステップＳ２０２、Ｓ２０３で高負荷状態と判定された場合、リソース制御部１０３は、優先順位情報１０３ａとリソース使用状況情報１０３ｂからリソース制御対象（機能制限／停止の対象）の分析プログラム（トラフィック分析機能）を選択する（Ｓ２０４）。
【0088】
ここで、仮に優先順位情報１０３ａが図５で表される場合、優先順位が「低」であるリアルタイム処理が不要な分析プログラムからリソース制御対象になることになる。また、ここで、リソース使用状況情報１０３ｂの内容が図６で表される場合、リアルタイム処理が不要な機能は、「セ_リ不_脆弱性検査機能」のみであるため、当該分析プログラムが機能制限／停止の対象に選択される。
【0089】
次に、リソース制御部１０３は、リソース制御対象（機能制限／停止の対象）とした分析プログラムに対し、機能制限するか停止するかを判断する（Ｓ２０５）。
【0090】
例えば、リソース制御部１０３は、コンピュータ４００のＣＰＵ使用率とメモリ使用状況（計算資源情報と呼ぶ）を確認し、ＣＰＵ使用率が１００％に達している（例えば、マルチコアＣＰＵの場合１台当たりのＣＰＵ使用率が１００％に達している）か、メモリ（一次記憶部４０２）の管理においてスワップが発生している場合、通信監視装置１０（コンピュータ４００）の計算資源が逼迫している（過負荷状態）にあると判断し、リソース制御対象の分析プログラムについて停止の判断をし、そうでない場合は機能制限の判断をする。
【0091】
リソース制御部１０３は、機能制限／停止の判断結果に従い、データベース処理部１０２に対象の分析プログラム（トラフィック分析機能）に対する機能制限／停止を設定したリソース制御情報を、データベース処理部１０２にＰｕｂｌｉｓｈする。
【0092】
データベース処理部１０２は、機能制限／停止要求のＰｕｂｌｉｓｈを受信すると、当該チャネルをＳｕｂｓｃｒｉｂｅしている、分析部１０４の各トラフィック分析機能に通知する。
【0093】
分析部１０４の各分析プログラム（トラフィック分析機能）は、受信したリソース制御情報（機能制限／停止要求）が自身に対するものかを確認し、自身に対するものであった場合、当該リソース制御情報に従って機能制限または停止を実行する（Ｓ２０６）。リソース制御対象の分析プログラムは、リソース制御情報に設定された内容が機能制限の場合は、機能制限に負荷された制限値を制限値カウンタに加算して更新し、更新後の制限値カウンタの値に応じて受信するフロー情報を破棄する確率、またはフローを処理する間隔を設定する。また、リソース制御対象の分析プログラムは、リソース制御情報に設定された内容が停止の場合、フロー情報のチャネルについてＳｕｂｓｃｒｉｂｅを停止する。
【0094】
次に、リソース制御部１０３は、通信監視装置１０（コンピュータ４００）の計算資源の使用状況を確認し（Ｓ２０７）、ステップＳ２０６の機能制限／停止時の後、通信監視装置１０（コンピュータ４００）の計算資源の使用状況が悪化（使用量が増加）しているか否かを確認する（Ｓ２０８）。
【0095】
通信監視装置１０は、ステップＳ２０６の機能制限／停止時の後、通信監視装置１０（コンピュータ４００）の計算資源の使用状況が悪化している場合は上述のステップＳ２０４から動作（再度、分析プログラムを選択して機能制限／停止処理を実行）し、そうでない場合（コンピュータ４００のリソース使用状況が改善している場合）には後述するステップＳ２０９から動作する。
【0096】
上述のステップＳ２０８で、コンピュータ４００の計算資源の使用状況が改善していると判断された場合、リソース制御部１０３は、キャプチャ部１０１からの次の負荷情報を待って受信し（Ｓ２０９）、当該付加情報に基づいてキャプチャ部１０１が高負荷状態であるか否かを判断する（Ｓ２１０）。通信監視装置１０は、ステップＳ２１０で高負荷状態を継続していると判断した場合上述のステップＳ２０７（コンピュータ４００のリソース使用状況を確認する処理）に戻って動作し、そうでない場合（低負荷状態と判断した場合）後述する図９のステップＳ３０１の処理に移行する。
【0097】
上述のステップＳ２１０で、低負荷状態と判断された場合（キャプチャ部１０１が高負荷状態から低負荷状態に移行した場合）、リソース制御部１０３は、機能制限／停止している分析プログラム（分析プログラム）の中から機能緩和／起動する対象の分析プログラムを選択する（Ｓ３０１）。このとき、リソース制御部１０３は、機能制限／停止をした順番とは逆順（つまり機能制限／停止されている分析プログラムで優先度が高い順）で機能緩和／起動する分析プログラムを選択する。
【0098】
次に、リソース制御部１０３は、選択した分析プログラムに対して機能緩和するか起動するかを判断し、当該分析プログラムについて判断結果に従ったリソース制御情報を生成してＰｕｂｌｉｓｈする。このとき、リソース制御部１０３は、選択した分析プログラムが機能制限中であった場合は当該分析プログラムについて機能緩和を行うと判断し、選択した分析プログラムが停止していた場合は当該分析プログラムについて機能起動すると判断するようにしてもよい。ここで、リソース制御部１０３は、当該分析プログラムに対して複数回機能制限を実行していた場合、一回分の機能制限の大きさ（つまり０．２の固定値）の機能緩和（制限値カウンタの減算）を判断するようにしてもよい。そして、データベース処理部１０２は、リソース制御情報（機能緩和／起動要求）のＰｕｂｌｉｓｈを受信すると、各分析プログラム（当該チャネルの各Ｓｕｂｓｃｒｉｂｅｒ）に通知する。各分析プログラムは、リソース制御情報を受信すると、自身が対象であるか否か（例えば、当該リソース制御情報に設定された識別子（プログラム名）であるか否か）を確認して、自身に対するものであった場合、当該リソース制御情報（機能緩和／起動要求）に従い機能緩和／起動を実行する（Ｓ３０２）。このとき、当該分析プログラムにおいて、機能緩和が実行される場合、緩和される制限値の分制限値カウンタの値を減算する更新を行い、更新後の制限値カウンタの値に応じてフロー情報を破棄する確率、またはフローを処理する間隔を再設定する。このとき、当該分析プログラムは、起動する場合、フロー情報を通知するチャネルのＳｕｂｓｃｒｉｂｅを再開し、フロー情報が自身に流れるように制御（分析処理の再開制御）する。
【0099】
ステップＳ３０２でリソース制御情報をＰｕｂｌｉｓｈした後、リソース制御部１０３は、キャプチャ部１０１からの負荷情報の通知を待って受信する（Ｓ３０３）。
【0100】
次に、リソース制御部１０３は、キャプチャ部１０１から受信した負荷情報に基づいて、高負荷状態であるか否かを判定する（Ｓ３０４、Ｓ３０５）。
【0101】
通信監視装置１０は、ステップＳ３０５で高負荷状態と判定された場合、上述のステップＳ２０４（機能制限／停止する分析プログラムの選択処理）に戻って動作し、そうでない場合は後述するステップＳ３０６の処理に移行する。
【0102】
上述のステップＳ３０５で低負荷状態と判定された場合、リソース制御部１０３は、未だ機能制限／停止している分析プログラムの有無を確認し（Ｓ３０６）、機能制限／停止している分析プログラムがある場合は、上述のステップＳ３０１の処理（機能緩和／起動する分析プログラムの選択処理）に戻って動作し、機能制限／停止している分析プログラムが無い場合は、上述のステップＳ２０１に戻って動作する。
【0103】
（Ａ－３）第１の実施形態の効果
第１の実施形態によれば、以下のような効果を奏することができる。
第１の実施形態によれば、以下のような効果を奏することができる。
【0104】
第１の実施形態の通信監視装置１０では、キャプチャ部１０１が負荷情報をリソース制御部に通知し、リソース制御部１０３は複数あるトラフィック分析機能の特性をもとにした優先順位情報１０３ａと分析プログラムのリソース使用状況を用い、優先順位が低くリソースを多く使用する分析プログラムに対し機能の機能制限／停止をさせる。第１の実施形態の通信監視装置１０では、計算資源を確保し、キャプチャ部１０１やセキュリティ機能といった管理上重要な機能が動作し続けるようにリソース管理することができる。また、これにより、第１の実施形態の通信監視装置１０では、キャプチャ部１０１の負荷情報で高負荷状態かを判断することで、高負荷状況下でのキャプチャロスを防ぎ、通信監視装置に完全に負荷がかかる前にその前兆を検知することで重要な機能がＯＳによってＫｉｌｌされたり、リアルタイム分析処理に遅延が生じたりすることを回避することができる。さらに、これにより、通信監視装置１０では、リソース制御の方法として、停止だけでなく、機能制限を設けることによって、高負荷状態でも分析プログラムを動作させつつ、計算資源のひっ迫を防ぐことができる。
【0105】
以上のように第１の実施形態の通信監視装置１０は、ＩｏＴ機器等が接続されるエッジネットワークを流れる通信トラフィックを収集・分析し、ＩｏＴ機器の通信情報（通信量や通信先等）の可視化やサイバー攻撃等の異常を検知することができる。特に、通信監視装置１０では、計算資源が限られた安価な計算機を計算資源（コンピュータ４００）に用いる場合に、外部ネットワークからの攻撃やスキャン等により分析装置に負荷がかかる状況下でも重要な機能の動作を継続させることができる。
【0106】
（Ｂ）第２の実施形態
以下、本発明による通信監視装置、通信監視プログラム及び通信監視方法の第２の実施形態を、図面を参照しながら詳述する。
以下、本発明による通信監視装置、通信監視プログラム及び通信監視方法の第２の実施形態を、図面を参照しながら詳述する。
【0107】
（Ｂ－１）第２の実施形態の構成
第２の実施形態において関係する各装置の接続関係についても図２を用いて示すことができる。以下では、第２の実施形態について第１の実施形態との差異を説明する。
第２の実施形態において関係する各装置の接続関係についても図２を用いて示すことができる。以下では、第２の実施形態について第１の実施形態との差異を説明する。
【0108】
図１０は、第２の実施形態に係る通信監視装置１０Ａの機能的構成について示したブロック図であり、上述の図１と同一部分又は対応部分については同一符号又は対応符号を付している。通信監視装置１０Ａのハードウェア構成についても上述の図３を用いて示すことができる。なお、図２、図３における括弧内の符号は第２の実施形態でのみ用いられる符号である。なお、第１の実施形態に係る通信監視装置１０Ａのハードウェア構成についても第１の実施形態と同様に図３を用いて示すことができる。
【0109】
第２の実施形態の通信監視装置１０Ａでは、表示部１０５が除外され記憶部１０６が追加されている点で第１の実施形態と異なっている。また、第２の実施形態の通信監視装置１０Ａでは、リソース制御部１０３及び分析部１０４が、リソース制御部１０３Ａ及び分析部１０４Ａに置き換わっている点で第１の実施形態と異なっている。
【0110】
第２の実施形態の通信監視装置１０Ａでは、キャプチャ部１０１が高負荷状態にあるときに機能制限／停止していた分析プログラムに対し、キャプチャ部１０１が低負荷状態移行後に未処理のフロー情報の分析をさせ、分析の補完をする。
【0111】
分析部１０４Ａでは、各分析プログラム（トラフィック分析機能）を補完する機能（以下、「補完用トラフィック分析機能」と呼ぶ）に対応するプログラム（以下、「補完用分析プログラム」と呼ぶ）も動作している点で第１の実施形態と異なっている。以下では、補完用トラフィック分析機能の集合体を「補完用トラフィック分析機能群」と呼ぶものとする。
【0112】
まず、分析部１０４Ａについて第１の実施形態との差異を説明する。
【0113】
図１１は、分析部１０４Ａにおけるトラフィック分析機能群（分析プログラム群）と補完用トラフィック分析機能群（補間用分析プログラム群）の構成例について示した図であり、上述の図４と同一部分又は対応部分には同一符号又は対応符号を付している。
【0114】
図１１に示すように、補完用トラフィック分析機能群には、トラフィック分析機能群と同様に、非セキュリティ機能群と非セキュリティ機能群が含まれている。また、図１１に示すように、補完用トラフィック分析機能群には、非セキュリティ機能群に、通信先情報集計機能の補完用分析プログラムＰＣ１０１と通信量集計機能の補完用分析プログラムＰＣ１０２が含まれている。さらに、図１１に示すように、セキュリティ機能群に、異常検知機能の補完用分析プログラムＰＣ２０１と脆弱性検知機能の補完用分析プログラムＰＣ２０２が含まれている。補完用分析プログラムは、分析プログラムと同様に、Ｄｏｃｋｅｒコンテナとして起動するようにしてもよい。なお、図１１では、説明の都合上、全ての分析プログラムに対応する補完用分析プログラムを図示しているが、それぞれの補完用分析プログラムは、対応する分析プログラムで補完処理を必要とするときのみ起動させることが望ましい。
【0115】
分析プログラム（トラフィック分析機能）がリアルタイムにデータベース処理部１０２から受信するフロー情報を処理するのに対し、補完用分析プログラム（補完用トラフィック分析機能）は、機能制限／停止中に分析できなかったフロー情報を処理する役割を担う。各分析プログラムは、自身が機能制限中は破棄したフロー情報と当該フローの生成時刻を記録し、停止中はその期間（停止時刻と再起動時刻）を記録しておく（以下では、これらの情報を「未処理フロー情報リスト」と呼ぶ）。
【0116】
分析部１０４Ａは、リソース制御部１０３Ａから、補完用分析プログラムの起動要求（以下、「補完分析開始要求」と呼ぶ）のＰｕｂｌｉｓｈがあると、当該補完分析開始要求をＳｕｂｓｃｒｉｂｅして、当該補完分析開始要求に対応する補完用分析プログラム（補完用トラフィック分析機能）を起動する。分析部１０４Ａは、補完用分析プログラムを起動する際に、当該補完用分析プログラム（補間用トラフィック分析機能）に対応する分析プログラム（トラフィック分析機能）の未処理フロー情報リストを供給する。
【0117】
補完用分析プログラムは、後述する「対象指定型フロー情報」がＰｕｂｌｉｓｈされるチャネルをＳｕｂｓｃｒｉｂｅし、対象指定型フロー情報を受信すると、未処理フロー情報リストに含まれるフロー情報のみを対象として分析を実行する。
【0118】
分析部１０４Ａ（補完用トラフィック分析プログラム）は、後述するリソース制御部１０３ＡがＰｕｂｌｉｓｈする補完分析停止要求をＳｕｂｓｃｒｉｂｅする。分析部１０４Ａ（補完用トラフィック分析プログラム）は、当該要求を受信すると、対象指定型フロー情報が通知されるチャネルのＳｕｂｓｃｒｉｂｅを終了し、未処理フロー情報リストのうち、処理済みのフロー情報を削除する。そして、分析部１０４Ａは、当該補完用分析プログラムを停止（例えば、対応するＤｏｃｋｅｒコンテナを停止）する。
【0119】
次に、リソース制御部１０３Ａについて第１の実施形態との差異を説明する。
【0120】
リソース制御部１０３Ａは、キャプチャ部１０１が高負荷状態から低負荷状態へ移行後、高負荷状態で機能制限／停止状態にあったトラフィック分析機能の補完分析を制御する処理を行う点で第１の実施形態と異なっている。
【0121】
リソース制御部１０３Ａは、キャプチャ部１０１が高負荷状態になった時、高負荷状態になったことを示す情報（以下、「高負荷開始情報」と呼ぶ）をデータベース処理部１０２にＰｕｂｌｉｓｈする。また、リソース制御部１０３Ａは、キャプチャ部１０１が高負荷状態から低負荷状態に変わり、機能制限／停止していた分析プログラムの機能緩和／起動が完了すると、低負荷状態に移行したことを示す情報（以下、「高負荷終了情報」と呼ぶ）をデータベース処理部１０２にＰｕｂｌｉｓｈする。さらに、リソース制御部１０３Ａは、機能制限／停止を要求した各分析プログラムの機能制限／停止をしていた期間を記録する。さらにまた、リソース制御部１０３Ａは、キャプチャ部１０１が低負荷状態の時、機能制限／停止をしていた分析プログラムの中で優先度の高い順（つまり優先順位情報１０３ａの中で優先度が高くリソース使用状況で負荷が小さい順）に機能制限／停止していた期間の補完分析を実行する。そのために、リソース制御部１０３Ａは、実行対象となった分析プログラムの補完分析開始要求をデータベース処理部１０２にＰｕｂｌｉｓｈする。
【0122】
リソース制御部１０３Ａは、通信監視装置１０Ａ全体の計算資源（コンピュータ４００の計算資源）の使用状況を監視し、通信監視装置１０Ａ全体の計算資源使用状況に所定以上の余裕がある限り、優先度が高いものから順に分析プログラムの補完分析を実行する。また、リソース制御部１０３Ａは、通信監視装置１０Ａ全体の計算資源使用状況に余裕が所定以下となった場合は、分析プログラムをそれ以上実行することを止める。リソース制御部１０３Ａは、分析プログラムの補完分析が完了し、通信監視装置の計算資源使用状況に余裕ができると、再度停止中の分析プログラムを立ち上げていく。
【0123】
リソース制御部１０３Ａは、分析プログラムの補完分析実行中にキャプチャ部１０１の負荷情報が高負荷状態に移行すると、実行中の補完分析プログラムを停止させるために、補完分析停止要求をデータベース処理部１０２にＰｕｂｌｉｓｈする。
【0124】
次に、記憶部１０６の構成について説明する。
【0125】
記憶部１０６は、キャプチャ部１０１が高負荷状態の時のフロー情報を記憶し、低負荷状態の時記憶していたフロー情報をデータベース処理部１０２にＰｕｂｌｉｓｈする。
【0126】
記憶部１０６は、リソース制御部１０３Ａが高負荷開始情報をＰｕｂｌｉｓｈするチャネルをＳｕｂｓｃｒｉｂｅし、高負荷開始情報を受信すると、キャプチャ部１０１がフロー情報をＰｕｂｌｉｓｈするチャネルのＳｕｂｓｃｒｉｂｅを開始し、受信するフロー情報と当該フロー情報の生成時刻を記憶する。また、記憶部１０６は、リソース制御部１０３Ａが高負荷終了情報をＰｕｂｌｉｓｈするチャネルをＳｕｂｓｃｒｉｂｅし、高負荷終了情報を受信すると、フロー情報を受信するチャネルのＳｕｂｓｃｒｉｂｅを停止する。さらに、記憶部１０６は、リソース制御部１０３Ａが補完分析開始要求をＰｕｂｌｉｓｈするチャネルをＳｕｂｓｃｒｉｂｅし、補完分析開始要求を受信すると、補完分析開始要求のメッセージから対象の分析プログラムと機能制限／停止期間を取得し、当該分析プログラムを対象に、当該機能制限／停止期間のフロー情報を対象指定型フロー情報としてフロー情報の生成時刻順にデータベース処理部１０２にＰｕｂｌｉｓｈしていく。さらにまた、記憶部１０６は、リソース制御部１０３Ａが補完分析停止要求をＰｕｂｌｉｓｈするチャネルをＳｕｂｓｃｒｉｂｅし、当該停止要求を受信すると、対象指定型フロー情報のＰｕｂｌｉｓｈを停止する。
【0127】
以上のように、第２の実施形態の通信監視装置１０Ａでは、分析プログラムが機能制限／停止している間のフロー情報を記憶部１０６に記憶させ、当該分析プログラムが機能制限／停止から復帰した後、記憶部１０６が記憶したフロー情報を補完用分析プログラムに供給して分析プログラムが機能制限／停止中に処理できなかったフロー情報の分析処理を補完（代行）させる構成となっている。
【0128】
（Ｂ－２）第２の実施形態の動作
次に、以上のような構成を有する第２の実施形態の通信監視装置１０Ａの動作（実施形態に係る通信監視方法）を説明する。
次に、以上のような構成を有する第２の実施形態の通信監視装置１０Ａの動作（実施形態に係る通信監視方法）を説明する。
【0129】
以下では、第２の実施形態の通信監視装置１０Ａの動作のうち、第１の実施形態との差異を中心に説明する。
【0130】
図１２、図１３は、通信監視装置１０Ａにおける、キャプチャ部１０１の高負荷遷移に伴うフロー情報蓄積処理と、キャプチャ部１０１の低負荷遷移に伴うトラフィック分析の補完処理について示したフローチャートである。第２の実施形態の通信監視装置１０Ａは、第１の実施形態の動作に加えて図１２、図１３のフローチャートの処理を行う。
【0131】
まず、ここでは、キャプチャ部１０１が負荷情報をデータベース処理部１０２にＰｕｂｌｉｓｈしたものとする（Ｓ４０１）。
【0132】
そして、リソース制御部１０３Ａは、当該負荷情報を受信すると、リソース制御部１０３Ａはキャプチャ部１０１が高負荷状態であるか否かを判定し（Ｓ４０２）、高負荷状態であると判定した場合のみ後述のステップＳ４０３に移行し、そうでない場合はステップＳ４０１に戻って動作する。
【0133】
ステップＳ４０２で、キャプチャ部１０１が高負荷状態と判定された場合、リソース制御部１０３Ａは、高負荷開始情報をデータベース処理部１０２にＰｕｂｌｉｓｈする。当該高負荷開始情報は、記憶部１０６によりＳｕｂｓｃｒｉｂｅされる（Ｓ４０３）。
【0134】
記憶部１０６は高負荷開始情報の通知を受けると、その後のフロー情報の蓄積（フロー情報のチャネルのＳｕｂｓｃｒｉｂｅ）を開始する（Ｓ４０４）。その後、記憶部１０６は、キャプチャ部１０１がフロー情報をＰｕｂｌｉｓｈするチャネルをＳｕｂｓｃｒｉｂｅし、フロー情報を受信すると、当該フロー情報の生成時刻とともにフロー情報を保存（記録）する。
【0135】
次に、リソース制御部１０３Ａは、高負荷状態が継続する限り、キャプチャ部１０１からの負荷情報を継続受信し（Ｓ４０５、Ｓ４０６）、その間記憶部１０６はフロー情報を蓄積していく。
【0136】
その後、キャプチャ部１０１が高負荷状態から低負荷状態となると、リソース制御部１０３Ａは、図１３のステップＳ５０１の処理に移行する。
【0137】
キャプチャ部１０１が高負荷状態から低負荷状態に移行したことを判定すると、リソース制御部１０３Ａは、高負荷終了情報をデータベース処理部１０２にＰｕｂｌｉｓｈする。当該高負荷終了情報は記憶部１０６にＳｕｂｓｃｒｉｂｅされる（Ｓ５０１）。
【0138】
記憶部１０６は、高負荷終了情報を受信すると、フロー情報の蓄積を終了する。そのために、記憶部１０６は、フロー情報がＰｕｂｌｉｓｈされるチャネルのＳｕｂｓｃｒｉｂｅを停止する（Ｓ５０２）。
【0139】
リソース制御部１０３Ａは、高負荷終了情報の送信後、通信監視装置１０Ａ（コンピュータ４００）の計算資源の使用状況を確認するとともに、キャプチャ部１０１からの負荷情報を取得する（Ｓ５０３、Ｓ５０４）。
【0140】
次に、リソース制御部１０３Ａは、キャプチャ部１０１が低負荷状態にあるか否かを判定し（Ｓ５０５）、低負荷状態にあると判定した場合は後述するステップＳ５０７に移行し、高負荷状態にあると判定した場合は、ステップＳ５０６に移行する。
【0141】
ステップＳ５０５で低負荷状態でない（高負荷状態である）と判定された場合、リソース制御部１０３Ａは、起動中の補完用分析プログラムを停止（起動している補完用分析プログラムがなければ何もしない）し（Ｓ５０６）、上述のステップＳ４０３に戻って動作する。このとき、リソース制御部１０３Ａは、起動中の補完用分析プログラムの停止を要求する補完分析停止要求をデータベース処理部１０２にＰｕｂｌｉｓｈする。データベース処理部１０２により、当該補完分析停止要求は、記憶部１０６と分析部１０４Ａと分析部１０４Ａの各補完用分析プログラムに通知される。これにより、記憶部１０６は、当該停止要求を受信すると、対象指定型フロー情報のＰｕｂｌｉｓｈを停止する。また、分析部１０４Ａの各補完用分析プログラムは、当該停止要求を受信すると、未処理フロー情報リストを更新（つまり処理が完了したフロー情報を当該リストから削除する）し、機能を停止する。その後、分析部１０４Ａは当該補完用分析プログラムを停止（例えば、対応するＤｏｃｋｅｒコンテナを停止）する。
【0142】
上述のステップＳ５０５でキャプチャ部１０１が低負荷状態にあると判定された場合、リソース制御部１０３Ａは、通信監視装置１０Ａの計算資源に所定以上の余裕があるか否か（計算資源の使用量が所定以下であるか否か）を判定し（Ｓ５０７）、計算資源に所定以上の余裕があると判断した場合は後述するステップＳ５０９から動作し、そうでない場合には後述するステップＳ５０８から動作する。通信監視装置１０Ａの計算資源に所定以上の余裕があるか否か（計算資源の負荷が所定以下であるか否か）については、例えば、ＣＰＵ使用率及びメモリ使用率が所定以下（例えば、ＣＰＵ使用率及びメモリ使用率がいずれも７０％以下）であるか否かに基づいて判定するようにしてもよい。
【0143】
上述のステップＳ５０７で、通信監視装置１０Ａの計算資源に所定以上の余裕がないと判定された場合、リソース制御部１０３Ａは、起動している補完分析プログラムがあるか否かを確認し（Ｓ５０８）、起動している補完分析プログラムがある場合は後述するステップＳ５１０に移行し、そうでない場合は上述のステップＳ５０３に戻って動作する。
【0144】
上述のステップＳ５０７で、通信監視装置１０Ａの計算資源に所定以上の余裕があると判定された場合、リソース制御部１０３Ａは、キャプチャ部１０１が高負荷状態時に機能制限／停止していた分析プログラムのうち、最も優先度の高い分析プログラムを選択する。リソース制御部１０３Ａは、選択した分析プログラムを対象とした補完分析開始要求をデータベース処理部１０２にＰｕｂｌｉｓｈし、分析部１０４Ａに補完用分析プログラムを起動させる（Ｓ５０９）。この時、当該補完分析開始要求には、対象の分析プログラムと当該分析プログラムの機能制限／停止期間が含まれる。リソース制御部１０３ＡからＰｕｂｌｉｓｈされた補完分析開始要求は、補完分析開始要求のチャネルをＳｕｂｓｃｒｉｂｅする分析部１０４Ａと記憶部１０６に対し通知される。分析部１０４Ａは、補完分析開始要求を受信すると、当該補完分析開始要求に記載の分析プログラムに対応する補完用分析プログラムを起動（例えば、当該補完分析プログラムのＤｏｃｋｅｒコンテナを起動）する。この時、分析部１０４Ａは、当該分析プログラムの未処理フロー情報リストを当該補完用分析プログラムに渡し、当該補完用分析プログラムはこれを読み込む。記憶部１０６は、補完分析開始要求を受信すると、当該補完分析開始要求に記載の機能制限／停止期間のフロー情報を取得し、フロー情報の生成時刻順（時系列順）に、当該要求に記載の分析プログラムを対象とした指定型フロー情報をデータベース処理部１０２にＰｕｂｌｉｓｈする。記憶部１０６からＰｕｂｌｉｓｈされた指定型フロー情報は、指定型フロー情報のチャネルをＳｕｂｓｃｒｉｂｅする対象の補完用分析プログラムに通知される。そして、補完用分析プログラムは、指定型フロー情報を受信すると、未処理フロー情報リストに記載のフロー情報であった場合、当該フロー情報をトラフィック分析する。また、補完用分析プログラムは、指定型フロー情報のフロー情報が未処理フロー情報リストに未記載の情報であった場合、当該フロー情報を破棄する。
【0145】
次に、分析部１０４Ａは、補完用分析プログラムが未処理フロー情報リストに記載のフロー情報を全て処理（分析完了）したか否か確認し（Ｓ５１０）、分析終了を確認した場合は後述するステップＳ５１１から動作し、そうでない場合は上述のステップＳ５０３に戻って動作する。
【0146】
当該補完用分析プログラムによる分析完了を確認すると、分析部１０４Ａは、当該補完用分析プログラムを停止（例えば、対応するＤｏｃｋｅｒコンテナを停止）する（Ｓ５１１）。
【0147】
次に、リソース制御部１０３Ａは、補完分析対象の分析プログラムが残っているか否かを確認し（Ｓ５１２）、残っている場合には上述のステップＳ５０３から動作し、そうでない場合は一連の補完処理を終了する。
【0148】
（Ｂ－３）第２の実施形態の効果
第２の実施形態によれば、以下のような効果を奏することができる。
第２の実施形態によれば、以下のような効果を奏することができる。
【0149】
第２の実施形態の通信監視装置１０Ａは、キャプチャ部１０１が高負荷状態期間のフロー情報を保存する記憶部１０６を設け、キャプチャ部１０１が高負荷状態時に機能制限／停止していた分析プログラムに対し、未処理のトラフィック分析をキャプチャ部１０１が低負荷状態移行後に実行する。これにより、第２の実施形態の通信監視装置１０Ａでは、機能制限／停止期間のトラフィック分析処理を補完でき、リソース制御による分析漏れを無くすことができる。また、これにより、第２の実施形態の通信監視装置１０Ａでは、リソース制御部１０３Ａでキャプチャ部１０１の負荷情報や通信監視装置の計算資源使用状況をもとに補完分析を実行するかを都度判断することにより、キャプチャ部１０１や分析プログラムの処理に影響を与えることなく、補完分析を実現することができる。
【0150】
（Ｃ）他の実施形態
本発明は、上記の各実施形態に限定されるものではなく、以下に例示するような変形実施形態も挙げることができる。
本発明は、上記の各実施形態に限定されるものではなく、以下に例示するような変形実施形態も挙げることができる。
【0151】
（Ｃ－１）第１および第２の実施形態におけるリソース制御部１０３、１０３Ａは、１度の制御処理（機能制限／停止、緩和／起動、補完分析開始／停止）の際に、単一の分析プログラムを指定していたが、これに限定されるものではない。例えば、リソース制御部１０３、１０３Ａが優先順位情報１０３ａのタグ情報（例えば、「リアルタイム処理が不要な機能」を示す「リ不」や「非セキュリティ機能」を示す「非セ」）や優先度（例えば、「高」、「中」、「低」）を指定し、各分析プログラムは自身が指定されたタグ情報や優先度に該当する場合に制御処理するなどである。このようにすることで、分析プログラムを一括で制御できるため、より早期の計算資源確保や、機能回復を実現することができる。
【0152】
（Ｃ－２）第１の実施形態では、キャプチャ部１０１の負荷情報（通信レート、処理待ちデータ数、管理フロー数）を用い、負荷情報の各指標が閾値を超えたどうかで高負荷状態の判定をし、高負荷状態になったことを契機として分析プログラムを機能制限／停止していたが、これに限定されるものではない。例えば、リソース制御部１０３がキャプチャ部１０１の過去の負荷情報とその時の通信監視装置１０（コンピュータ４００）の計算資源（ＣＰＵ使用率及びメモリ使用率）の関係を機械学習器等で学習し、通信監視装置１０の計算資源がひっ迫した状態に陥る前のキャプチャ部１０１の負荷情報の傾向を予測することで、より早期に通信監視装置の計算資源を確保することができる。
【0153】
（Ｃ－３）第１の実施形態では、リソース制御部１０３による分析プログラムの機能制限要求の際、制限の大きさを固定値としていたが、これに限定されるものではない。例えば、通信監視装置１０（コンピュータ４００）の計算資源使用状況をもとに、使用状況に余裕がある場合は、制限の大きさに小さい値を設定し、使用状況がひっ迫しつつある場合は、制限の大きさに大きい値を設定する方法が考えられる。このように、通信監視装置１０の計算資源使用状況に応じて動的に制限の大きさを変更することで、機能制限による分析漏れの抑制と、計算資源がひっ迫状態での重要な分析プログラムの分析漏れの抑制が両立できる。
【0154】
（Ｃ－４）第２の実施形態では、分析プログラムの補完分析実行時の記憶部１０６からフロー情報を通知する間隔について言及しなかったが、種々の方法が考えられる。例えば、フロー情報の生成時刻を相対時刻として用いて、元々のフロー情報と同一の間隔で通知する方法が考えられる。これにより、元々のフロー情報の通知間隔に則ることで、分析プログラムは設計上想定される範囲内で（自身のスループットに耐え得る間隔で）フロー情報を受信できるため、分析プログラムが処理負荷過多になることを回避できる。また、リソース制御部１０３が通信監視装置の計算資源状況をもとに、データベース処理部１０２を通して、フロー情報の通知間隔を動的に変更する方法が考えられる。例えば計算資源に十分余裕がある場合は、短い通知間隔を記憶部１０６に通知し、計算資源が増加傾向にある場合は、長い通知間隔を記憶部１０６に通知するなどである。通知間隔を動的に変更することにより、計算資源に余裕があるうちに集中的に補完分析できるため、補完分析プログラムを起動する時間を短縮する効果が期待できる。
【0155】
（Ｃ－５）上記の各実施形態の通信監視装置１０、１０Ａでは、分析部１０４の分析プログラムについて機能制限／停止を行うことによりキャプチャ部１０１のキャプチャロス等を抑制しているが、分析プログラムの機能制限／停止だけでは高負荷状態を脱しない場合、キャプチャ部１０１自体の機能を制限（例えば、キャプチャするパケットを所定の確率で破棄する処理等により制限）するようにしてもよい。
【符号の説明】
【0156】
１０…通信監視装置、１０Ａ…通信監視装置、２０…ネットワークスイッチ、３０…通信端末、１０１…キャプチャ部、１０２…データベース処理部、１０３…リソース制御部、１０３ａ…優先順位情報、１０３ｂ…リソース使用状況情報、１０４…分析部、１０５…表示部、１０６…記憶部、４００…コンピュータ、４０１…ＣＰＵ、４０２…一次記憶部、４０３…二次記憶部。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】