(57)【要約】      （修正有）【課題】複数の端末から複数のログを収集している状況において、その時々においてインシデントを検出するために必要なログのみ抽出し、収集するログ収集／解析サーバを提供する。【解決手段】ログ収集／解析サーバ１は、サーバ側通信インターフェースと、サーバ側記憶部と、サーバ側制御部とを備える。サーバ側制御部は、障害検出情報に基づきサーバ側記憶部に記憶されたログデータ２０５を確認し、ログから複数の端末２Ｘ〜２Ｚのうち障害が発生したまたは発生しそうな監視対象端末を特定し、監視対象端末へログ送信の優先度を変更する第１の指示を送信し、障害が発生してない複数の端末へログ送信の優先度を変更する第２の指示を送信する。端末側制御部は、第１の指示または第２の指示を受信する場合、ログ送信の優先度を変更する制御を実行する。【選択図】図１
2018010441.tif 000002
【特許請求の範囲】
【請求項１】
複数の端末とネットワークを介して前記複数の端末からログを収集するログ収集サーバを備えるログ収集システムであって、
前記ログ収集サーバは、前記ネットワークと接続するサーバ側通信インターフェースと、前記ログを格納するサーバ側記憶部と、前記ログ収集サーバを制御するサーバ側制御部とを備え、
前記端末は、前記ネットワークと接続する端末側インターフェースと、前記ログを格納する端末側記憶部と、前記端末を制御する端末側制御部とを備え、
前記サーバ側制御部は、
前記サーバ側記憶部に予め記憶された障害検出情報に基づき前記サーバ側記憶部に記憶された前記ログを確認し、
前記ログから前記複数の端末のうち障害が発生したまたは発生しそうな監視対象端末を特定し、
前記サーバ側通信インターフェースを介して、前記監視対象端末へログ送信の優先度を変更する第１の指示を送信し、または、障害が発生してない前記複数の端末へログ送信の優先度を変更する第２の指示を送信し、または、前記第１の指示及び前記第２の指示を送信し、
前記端末側制御部は、
前記第１の指示または前記第２の指示を受信する場合、前記ログ送信の優先度を変更する制御を実行することを特徴とするログ収集システム。
【請求項２】
請求項１に記載のログ収集システムであって、
前記第１の指示または前記第２の指示は、前記障害検出情報の、警戒値を超えたタイミングまたは障害値を超えたタイミングで指示されることを特徴とするログ収集システム。
【請求項３】
請求項２に記載のログ収集システムであって、
前記警戒値を超えた場合、前記第１の指示はログ送信の優先度を上げる指示であり、前記第２の指示は前記ログ送信の優先度を下げる指示であり、
前記障害値を超えた場合、前記第１の指示はログ送信の優先度を下げる指示であり、前記第２の指示は前記ログ送信の優先度を上げる指示であることを特徴とするログ収集システム。
【請求項４】
請求項１に記載のログ収集システムであって、
前記第１の指示または前記第２の指示を送信してから所定時間が経過した場合、前記サーバ側制御部は、前記ログ送信の優先度を元の優先度に戻す指示を送信することを特徴とするログ収集システム。
【請求項５】
請求項１に記載のログ収集システムであって、
前記障害検出情報の障害値を超えた端末に対して、前記サーバ側制御部は、前記ログの送信を停止させる指示を送信することを特徴とするログ収集システム
【請求項６】
請求項１に記載のログ収集システムであって、
前記端末は前記端末側記憶部に前記ログを含む複数種類のログを記憶し、
前記端末側制御部は、発生した障害の種類に基づき前記ログの一部を削除した前記複数種類のログを前記サーバへ送信することを特徴とするログ収集システム。
【請求項７】
請求項１に記載のログ収集システムであって、
前記ログ収集サーバは、画面を出力する出力装置と、前記画面を操作し操作者の入力を受け付ける入力装置をさらに備え、
前記サーバ側制御部は、
前記出力装置に前記複数の端末のログ送信の優先度を表示させ、
前記入力装置より前記操作者によりログ送信の優先度の変更入力を受け付けると、前記ログ送信の優先度を変更する前記端末へログ優先度の変更をさせる変更指示を送信させることを特徴とするログ収集システム。
【請求項８】
複数の端末とネットワークを介して前記複数の端末からログを収集するログ収集サーバであって、
前記ログ収集サーバは、前記ネットワークと接続し、複数の外部端末と通信をする通信インターフェースと、前記ログを格納する記憶部と、当該装置を制御する制御部とを備え、
前記制御部は、
前記記憶部に予め記憶された障害検出情報に基づき前記記憶部に記憶された前記ログを確認し、
前記ログから前記複数の外部端末のうち障害が発生したまたは発生しそうな監視対象端末を特定し、
前記通信インターフェースを介して、前記監視対象端末へログ送信の優先度を変更する第１の指示を送信し、または、障害が発生してない前記複数の外部端末へログ送信の優先度を変更する第２の指示を送信し、または、前記監視対象端末へ前記第１の指示及び前記障害が発生していない前記複数の外部端末へ前記第２の指示を送信することを特徴とするログ収集サーバ。
【請求項９】
請求項８に記載のログ収集サーバであって、
前記制御部は、前記障害検出情報の警戒値を超えたタイミングまたは障害値を超えたタイミングで前記第１の指示または前記第２の指示を指示することを特徴とするログ収集サーバ。
【請求項１０】
請求項９に記載のログ収集サーバであって、
前記警戒値を超えた場合、前記第１の指示はログ送信の優先度を上げる指示であり、前記第２の指示は前記ログ送信の優先度を下げる指示であり、
前記障害値を超えた場合、前記第１の指示はログ送信の優先度を下げる指示であり、前記第２の指示は前記ログ送信の優先度を上げる指示であること、を特徴とするログ収集サーバ。
【請求項１１】
請求項８に記載のログ収集サーバであって、
前記第１の指示または前記第２の指示を送信してから所定時間が経過した場合、前記側制御部は、前記ログ送信の優先度を元の優先度に戻す指示を送信することを特徴とするログ収集サーバ。
【請求項１２】
請求項８に記載のログ収集サーバであって、
前記障害検出情報の障害値を超えた端末に対して、前記制御部は、前記ログの送信を停止させる指示を送信することを特徴とするログ収集サーバ。
【請求項１３】
請求項８に記載のログ収集サーバであって、
画面を出力する出力装置と、
前記画面を操作し操作者の入力を受け付ける入力装置と、をさらに備え、
前記側制御部は、
前記出力装置に前記複数の端末のログ送信の優先度を表示させ、
前記入力装置より前記操作者によりログ送信の優先度の変更入力を受け付けると、前記ログ送信の優先度を変更する前記端末へログ優先度の変更をさせる変更指示を送信させることを特徴とするログ収集サーバ。
【請求項１４】
複数の端末とネットワークを介して前記複数の端末からログを収集するログ収集サーバを制御する制御方法であって、
前記ログ収集サーバは、前記ネットワークと接続し、複数の外部端末と通信をする通信インターフェースと、前記ログを格納する記憶部と、当該装置を制御する制御部とを備え、
前記制御部は、
前記記憶部に予め記憶された障害検出情報に基づき前記記憶部に記憶された前記ログを確認するステップと、
前記ログから前記複数の外部端末のうち障害が発生したまたは発生しそうな監視対象端末を特定するステップと、
前記通信インターフェースを介して、前記監視対象端末へログ送信の優先度を変更する第１の指示を送信するステップ、または、障害が発生してない前記複数の外部端末へログ送信の優先度を変更する第２の指示を送信するステップ、または、前記監視対象端末へ前記第１の指示及び前記障害が発生していない前記複数の外部端末へ前記第２の指示を送信するステップのいずれかを実行することを特徴とするログ収集サーバの制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、端末からのログをサーバで収集するログ収集システム、ログ収集サーバ、ログ収集方法、に関する。
【背景技術】
【０００２】
近年、企業システムにおけるセキュリティ侵害や障害などのインシデントの発生事例は増加傾向にある。そのため、インシデントが発生した際、迅速にシステムを元の状態に復旧させる必要がある。
【０００３】
本技術の背景として、例えば非特許文献１に記載の技術がある。非特許文献１に記載の技術は、不正プログラム感染や改ざんといったセキュリティ侵害インシデントの検知に基づいて、SDNコントローラがネットワークを動的に制御することで、不正な端末やサーバなどを、ネットワークから隔離したり、不正な端末やサーバの通信を遮断したりする技術が開示されている。
【０００４】
ここで、セキュリティ侵害や障害などのインシデントを検知する構成に注目する。例えば非特許文献１に示したインシデントを検知するシステムでは、複数の端末で発生しうるセキュリティ侵害インシデントを管理サーバが一元的に把握する構成が一般的である。この場合、管理サーバが複数の端末から端末内で発生したセキュリティ侵害インシデントに関する情報を収集することが必要となる。
【０００５】
しかし、管理サーバが管理する端末数の増加に伴い、管理サーバ側のCPUなどのリソースの枯渇が懸念される。そのため、管理サーバのリソースの状況に応じて端末からのログ送信処理を制御する技術が存在する。例えば、特許文献１には、ログを送信する端末が、サーバのリソース状況に応じ、ログ送信を待機させる待機時間をログの優先度に基づいて動的に変更可能な技術が開示されている。異常検知アラームなどのログは高い優先度、アプリ起動情報は低い優先度といったように、ログ毎に優先度を設定することが開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１５−２１５７７０号公報
【非特許文献】
【０００７】
【非特許文献１】日本電気株式会社、“ＮＥＣとトレンドマイクロ、SDNを活用し、サイバー攻撃を自動防御するソリューションを共同開発”、ＩＥＴＦ、[平成２６年１１月１８日発表]、［平成２８年６月２９日検索］、インターネット＜http://jpn.nec.com/press/201411/20141118_01.html＞
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかし、インシデント検知においては、特許文献１に示す技術のようにログ毎に優先度を定義できるものではない。従って、全てのログを収集する必要があるが管理サーバ側のリソースに限界があるため、その時々において必要なログのみ抽出し、収集する必要がある。インシデント検知において必要とされるログとは、インシデントが発生する兆候があり、発生確率が高いインシデントを検知するためのログとなる。そのときどきの状況に応じて、インシデント検知に必要なログを判別し、優先的に抽出する必要がある。
【０００９】
以上より、本願発明では、インシデント検知に必要なログを判別し、優先的にログを抽出し、収集するためのログ収集方法、ログ収集サーバ、ログ収集システムについて提供する。
【課題を解決するための手段】
【００１０】
上記課題を解決するための一つの手段として、ログ収集サーバは、ネットワークと接続するサーバ側通信インターフェースと、ログを格納するサーバ側記憶部と、ログ収集サーバを制御するサーバ側制御部とを備え、端末は、ネットワークと接続する端末側インターフェースと、ログを格納する端末側記憶部と、端末を制御する端末制御部とを備え、サーバ側制御部は、サーバ側記憶部に予め記憶された障害検出情報に基づきサーバ側記憶部に記憶されたログを確認し、ログから複数の端末のうち障害が発生したまたは発生しそうな監視対象端末を特定し、サーバ側通信インターフェースを介して、監視対象端末へログ送信の優先度を変更する第１の指示を送信し、または、障害が発生してない複数の端末へログ送信の優先度を変更する第２の指示を送信し、または、第１の指示及び前記第２の指示を送信し、端末側制御部は、第１の指示または第２の指示を受信する場合、ログ送信の優先度を変更する制御を実行するログ収集システムを提供する。
【発明の効果】
【００１１】
本発明によれば、インシデント発生の兆候を検知したインシデントに関連するログの収集を優先的に行い、限られたリソースの中で障害の発生検出の可能性を高めることができる。
【００１２】
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
【図面の簡単な説明】
【００１３】
【図１】ログ収集システムの概要を示す図である。
【図２】ログ収集／解析サーバ１、端末２のハードウェア及びソフトウェアの構成を示した図である。
【図３】インシデント警戒／障害検出テーブル２０３を示す図である。
【図４】ログ送信優先度状態管理テーブル２０４１を示す図である。
【図５】ログ送信優先度調整テーブル２０４２を示す図である。
【図６】ログ送信停止テーブル２０４３を示す図である。
【図７（ａ）】ログ収集／解析サーバ１と端末２の機能の動作の流れを示したシーケンス図となる。
【図７（ｂ）】ログ収集／解析サーバ１と端末２の機能の動作の流れを示したシーケンス図となる。
【図７（ｃ）】ログ収集／解析サーバ１と端末２の機能の動作の流れを示したシーケンス図となる。
【図８】障害の兆候があったインシデントのログを優先的に収集する動作を示すログ収集／解析サーバ１におけるフローチャート図である。
【図９】障害の兆候があったインシデントのログを優先的に収集する動作を示す端末２におけるフローチャート図である。
【図１０】警戒値を超過した後一定時間以上経過し、障害を検出しなかった場合の、処理のリセット動作を示すログ収集／解析サーバ１におけるフローチャート図である。
【図１１】処理のリセット動作を示す端末２におけるフローチャート図である。
【図１２】インシデントを検出した場合の、処理のリセット動作を示すログ収集／解析サーバ１におけるフローチャート図である。
【図１３】インシデントを検出した場合の、一部のログ送信停止の動作を示すログ収集／解析サーバ１におけるフローチャート図である。
【図１４】インシデントを検出した場合の、一部のログ送信停止の動作を示す端末２におけるフローチャート図である。
【図１５】ログ収集の優先度を変更した際の、端末２の送信帯域の変化を示した図である。
【図１６】グラフィカルユーザインターフェース（ＧＵＩ）の例を示した図である。
【発明を実施するための形態】
【００１４】
以下、課題を解決するための一実施例を、説明する。
【００１５】
なお、以下の説明では、「ａｂｃテーブル」の表現にて情報を説明することがあるが、情報は、テーブル以外のデータ構成で表現されていてもよい。データ構成に依存しないことを示すために「ａｂｃテーブル」のうちの少なくとも１つを「ａｂｃ情報」と呼ぶことができる。
【００１６】
また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ（例えばCPU（Central  Processing  Unit））によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）及び／又は通信インターフェースデバイス（例えば通信ポート）等を用いながら行うため、処理の主語がプロセッサとされてもよい。プログラムを主語として説明された処理は、プロセッサあるいはそのプロセッサを有する装置が行う処理としてもよい。また、プロセッサは、処理の一部または全部を行うハードウェア回路を含んでもよい。プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な記憶メディアであってもよい。プログラムソースがプログラム配布サーバの場合、プログラム配布サーバはプロセッサ（例えばCPU）と記憶資源を含み、記憶資源はさらに配布プログラムと配布対象であるプログラムとを記憶している。そして、プログラム配布サーバのプロセッサが配布プログラムを実行することで、プログラム配布サーバのプロセッサは配布対象のプログラムを他の計算機に配布する。
【００１７】
本実施例では、以下の状況を前提とし説明をする。
【００１８】
図１は、一実施例における、ログ収集システムを示す構成図である。以下、用語を定義しながらログ収集システムの説明を行う。
【００１９】
ログ収集／解析サーバ１や、端末２は、ＣＰＵやメモリを内蔵する計算機であり、これらの詳細な説明は図２で行う。端末２は、端末２Ｘ、端末２Ｙ、端末２Ｚ・・・として示すように、１つ以上で複数あっても良い。以下明細書にて端末２として説明をする場合は、各端末（端末２Ｘ、２Ｙ、２Ｚ）を特別区別をしていないものとする。また、ログ収集／解析サーバ１や端末２は、物理マシンのメモリで実行され、物理マシンのハードウェア資源を利用して稼動する仮想的な計算機であっても良い。
【００２０】
本実施例のログ収集システムの概要を説明する。ログ収集システムは、ログ収集／解析サーバ１と複数の端末２から構成されている。ログ収集／解析サーバ１と端末２は図示しないネットワークにて互いに接続されている。ログ収集／解析サーバ１は、各端末２から所定のタイミングで送付されるログデータをサーバ側ログ受信部２０６にて受信し、サーバ側ログデータ２０５としてサーバ側のメモリに記憶する。
【００２１】
端末２は、アプリ等を運用している際に発生したさまざまなログを端末側のメモリに端末側ログデータとして記憶する。なお、端末側ログデータとしては、端末２と通信をする外部装置とのログ（iptable）や、端末２で稼働するＣＰＵの状況（CPU）や通信するネットワークの状況(NW)、アプリの状況（appliXX）等がある。前記したログ以外の種類のログを記憶してもよいことは言うまでもない。
【００２２】
端末ログデータは所定のタイミングで、端末側ログ送信部２１２にあるバッファに一時的に格納され、予め定められたタイミングでログ収集／解析サーバ１へ送信される。
【００２３】
ログ収集／解析サーバ１にて収集されたログは、障害検出部２０１にて、インシデント警戒／障害検出テーブル２０３に基づいて端末２に障害が発生をしているか否かを確認する。端末２の中で障害が発生している場合、ログ収集／解析サーバ１のサーバ側ログ管理部２０２は端末２の端末側ログ管理部２１１に対して、ログ送信の優先度を変更する指示を送信する。端末２の端末側ログ管理部２１１は、受信した指示に従い、ログ送信量制御部２１３にログの送信量を変更させる指示や圧縮部２１４にバッファにあるログの圧縮等を指示する。
【００２４】
以上の構成を備えることで、本実施例のログ収集システムは、障害が発生するまたは発生しそうな端末２に対してログを優先的に収集することができる。本実施例の詳細については以下にて説明をする。
【００２５】
図２（ａ）は、図１にて説明した計算機（ログ収集／解析サーバ１、端末２）のハードウェア及びソフトウェアの構成を示した図である。換言すると、図１はログ収集／解析サーバ１および端末２に共通する構成を説明する図である。
【００２６】
計算機には、メモリ２１、入力装置２２、出力装置２３、ＣＰＵ２４、通信装置２５、および、１つ以上のポートＰ１・・・Ｐｎ（ｎは自然数）を備え、それらが内部バスで接続される。
【００２７】
メモリ２１には、実行中のプログラムやデータが記録される。各装置内のプログラムやデータは、あらかじめメモリ２１に格納しておいてもよいし、同様に内部バスで接続されている図示していない記憶装置に格納しておいてもよい。また、ハードディスクやＳＤメモリーカード、ＣＤ−ＲＯＭ等の外部媒体から入力してもよい。また、プログラムにより実現される機能を、専用のハードウェアにより実現してもよい。
【００２８】
入力装置２２は、例えば、ユーザの指示をマウスやキーボードから入力するための装置である。出力装置２３は、その入力の状態や、メモリ２１上で実行された処理の結果を、管理画面等に出力するための装置である。ＣＰＵ２４はメモリ２１に格納されたプログラムを実行する。通信装置２５は、ポートＰ１・・・Ｐｎを介して、図示しないネットワークで接続された他装置とパケットを送受信するための装置である。
【００２９】
次に、ログ収集／解析サーバ１がメモリ２１で実行する機能について説明する。まず、ログ収集／解析サーバ１が実行する機能について、図２（ｂ）を用いて説明する。障害検出部２０１は、警戒検出管理部２０１１と、障害検出管理部２０１２から構成されており、サーバ側ログデータ２０５を監視し、障害が発生する兆候及び障害の発生を検出する機能を備える。インシデント警戒／障害検出テーブル２０３は、障害検出部２０１が参照するテーブルであり、詳細は図３を用いて後述する。サーバ側ログ管理部２０２は、端末２から収集するログの収集優先度を制御する。ログ管理テーブル群２０４は、ログ送信優先状態管理テーブル２０４１と、ログ送信優先度調整テーブル２０４２と、ログ送信停止テーブル２０４３から成り、それぞれ、サーバ側ログ管理部２０２が、端末２のログ送信優先度を制御するために、参照するテーブルである。サーバ側ログ受信部２０６は、端末２から送信されるログを受信し、サーバ側ログデータ２０５にログを保存する。なお、上記する「ＡＢＣ部」は「ＡＢＣプログラム」と呼ぶこともできる。以下、メモリ２１で実行される機能に関しては同様である。
【００３０】
次に、端末２がメモリ２１で実行する機能について、図２（ｃ）を用いて説明する。
端末側ログ管理部２１１は、サーバ側ログ管理部２０２からの命令を受け、端末２のログの送信優先度を調整する。
【００３１】
端末側ログ送信部２１２は、ログ送信部２１２１と、ログ送信用バッファ２１２２から構成されている。ログ送信部２１２１は、端末側ログデータ２１５に保存されているログを、ログ送信用バッファ領域２１２２に一時的に保存した後、ログ収集／解析サーバ１へ送信する。ログ送信量制御部２１３は、端末２から、ログ収集／解析サーバ１へ送信するログの量を制御する。ログの量の制御の詳細については、図４、図５を用いて後述する。圧縮部２１４は、端末２からログ収集／解析サーバ１へログを送信する際に、特定のログの容量を削減する。なお、ログ容量の圧縮については公知の方法を用いるため、説明は省略する。
【００３２】
端末側ログデータ２１５は、ＯＳやアプリケーションソフトウェアが出力するログに相当する。例えば、Ｌｉｎｕｘ（登録商標）の場合、ＯＳが起動情報やエラー情報などを/var/log/syslogにテキストデータとして書き出す。また、アプリケーションソフトウェアが、起動情報やエラー情報などを書き出す場合もあり、それらは主に計算機のハードディスク上に保存される場合が多い。なお、本実施例ではＬｉｎｕｘ（登録商標）をベースとして説明をする。
【００３３】
図３は、ログ収集／解析サーバ１のインシデント警戒／障害検出テーブル２０３を示す図である。障害検出部２０１は本テーブルを参照して、端末２にインシデントが発生したか否かを判断する。
【００３４】
インシデント種別２０３０１には、インシデントを識別可能な一意の識別子が入る。インシデント名称２０３０２には、上記インシデント種別を感覚的に把握可能なインシデントを表す表現が入る。ログ送信端末２０３０３には、インシデントの発生を特定するために必要となるログを保持する端末の識別子が入る。本実施例を適用するシステムにおいて、一意に決められたＵＵＩＤ（Universally Unique Identifier）のような識別子でも良いし、ＩＰアドレスでも良い。
【００３５】
ログ２０３０４には、インシデントの原因を特定するために必要なログのパスが入る。例えば、Ｌｉｎｕｘ（登録商標）上で利用可能な機能としてiptablesがある。iptablesは、自計算機を通過したパケット毎に、日時、利用インターフェース、宛先ＩＰアドレス、送信元ＩＰアドレスなどの様々な情報を例えば/var/log/iptablesというログに記録する。警戒値２０３０５には、インシデントが発生する兆候をとらえるための条件が入り、障害値２０３０６には、インシデントの発生を認識するための条件が入る。
【００３６】
例えば、同一送信宛先宛の通信の急激な増加というインシデントを検出する場合、/var/log/iptablesのログを解析し、１分間以内に１０００以上の同一宛先ＩＰアドレスのパケットの出現を持って、インシデントと判別する。この場合、障害値には、「１分間以内に１０００以上の同一宛先ＩＰアドレスのパケットの出現」という条件が入る。警戒値は、障害として検出される以前に障害が発生しそうな兆候をとらえるための条件のため、例えば、「１分間以内に７００以上の同一宛先ＩＰアドレスのパケットの出現」という条件が入る。
【００３７】
図４は、ログ送信優先度状態管理テーブル２０４１を示す図である。ログ送信端末２０４１１、ログ２０４１２は、それぞれ、図３にて説明したログ送信端末２０３０３、ログ２０３０４と同じである。送信優先度２０４１３は、端末２からログを送信する際の優先度が入る。例えば、本実施例では、特定ログを優先的に収集する場合、特定ログの優先度を「優」と設定し、それ以外のログの優先度を「低」と設定する。時刻２０４１４には、送信優先度２０４１３を設定した時刻が入る。
【００３８】
図５は、ログ送信優先度調整テーブル２０４２を示す図である。ログ送信端末は、図３、図４で説明した２０３０３、２０４１２と同じである。送信優先度の優に属する帯域２０４２２は、ログ送信優先度状態管理テーブル２０４１にて示した送信優先度２０４１３が「優」の場合の送信帯域上限となる。送信優先度の優に属するポート２０４２３は、上記送信帯域条件を実施するために、必要となる送信ＴＣＰポートとなる。本実施例では、帯域制限を設けることにより、ログ送信の優先度を変更する方式を想定している。
【００３９】
例えば、Ｌｉｎｕｘ（登録商標）にはtraffic controlという機能があり、ＴＣＰポート毎に送信帯域の上限を適用することが可能となる。例えば、端末ＸからＴＣＰポート１０００２で送信した通信に対する上限帯域は、１００ｋｂｐｓとなる。送信優先度の「低」に属する帯域２０４２４は、ログ送信優先度状態管理テーブル２０４１にて示した送信優先度２０４１３が「低」の場合の送信帯域上限となる。送信優先度の「低」に属するポート２０４２５は、上記送信帯域条件を実施するために、必要となる送信ＴＣＰポートとなる。例えば、端末ＸからＴＣＰポート１０００１で送信した通信に対する上限帯域は、１０ｋｂｐｓとなる。このように、ＴＣＰポート毎に、送信帯域上限を変えることによって、ログ送信の優先度を変更する。
【００４０】
図６は、ログ送信停止テーブル２０４３を示す図である。ログ送信端末２０４３１は、ログ２０４３２は、それぞれ、図３、図４、図５で説明したログ送信端末（２０３０３、２０４１１、２０４２１）、ログ（２０３０４、２０４１２）と同じである。停止項目２０４３３は、インシデントの発生を検出し、既にそのインシデントに対して対策を施した場合、それ以上送信する必要のないログ条件を記録する。
【００４１】
例えば、前述のとおり、同一送信宛先宛の通信の急激な増加というインシデントを検出する場合、/var/log/iptablesのログのうち、１分間以内の同一宛先ＩＰアドレス数をカウントし、１分間に１０００パケット以上の同一宛先ＩＰアドレス（１０．１０．１０．１）の出現をもって、インシデントの発生を検出した場合、例えば、１０．１０．１０．１宛ての通信の上限帯域を制限するという対策が有効になる。
【００４２】
こうすることにより、急激に増加した１０．１０．１０．１宛ての通信帯域を削減し、その他のＩＰアドレス宛の通信を保証することができる。このような対策を実施した場合、それ以降の１０．１０．１０．１宛ての/var/log/iptablesのログの情報送信は、必要なくなるため、例えば、/var/log/iptablesのうち、宛先ＩＰアドレスが１０．１０．１０．１のレコードを送信しないということが、ログ送信量削減には有効になる。従って、このように、以降の送信を停止する情報を、停止項目２０４３３に書き込む。
もちろん図３〜図６で説明したテーブルの項目はあくまで一例であり、これ以外の表現があっても良い。また、項目に過不足があっても良い。
【００４３】
図７は、本実施形態における、ログ収集／解析サーバ１と端末２の機能の動作の流れを示したシーケンス図である。図８〜図１４は、本実施形態における、ログ収集／解析サーバ１、端末２それぞれの機能の動作の流れを示したフローチャート図とである。
以降、図７及び図８〜図１４を用いて、本実施形態における機能を説明する。なお図７の点線で囲まれた部分は、図８〜図１４に示すフローチャートにそれぞれ対応するシーケンス図である。
【００４４】
まず、図７（ａ）を用いて、本実施形態における、通常時の動作について説明する。
端末２の端末側ログ送信部２１２は、所定のタイミングで端末側ログデータ２１５からログを取得し、ログ収集／解析サーバ１へ送信している。ログ収集／解析サーバ１の、サーバ側ログ受信部２０６は、端末２から送信されたログを受信し、サーバ側ログデータ２０５に保存する。障害検出部２０１は、インシデント警戒／検出テーブル２０３を参照し、警戒値や障害値の条件を把握した上で、サーバ側ログデータ２０５を監視する。
【００４５】
次に、図７（ａ）と図８、図９を用いて、障害の兆候があったインシデントのログを優先的に収集する動作を説明する。図７（ａ）に示すとおり、ログを優先的に収集する動作は、ログ収集／解析サーバ１の動作を受けて、端末２に動作が移るように処理される。
【００４６】
まず、図８を用いてログ収集／解析サーバ１の動作について説明する。障害検出部２０１にある警戒検出管理部２１１１は、インシデント警戒／障害検出テーブル２０３を参照し、端末から収集したログが記憶されている監視対象のサーバ側ログデータ２０５に警戒値を超過しているログがあるか否かを監視する（ステップ８０１）。次にあるインシデントにおける、ある端末から送信されたあるログにおいて、警戒値超えを検出したか否かを判断する（ステップ８０２）。警戒値を超えたインシデントが検出されない場合（ステップ８０２：Ｎｏ）、監視を継続する。
【００４７】
警戒値を超えたインシデントを検出した場合（ステップ８０２：Ｙｅｓ）、警戒検出管理部２０１１は、サーバ側ログ管理部２０２に警戒値越えがあったことを通知する（ステップ８０３）。通知を受けたサーバ側ログ管理部２０２は、警戒値を超えたインシデントが検出された端末以外の端末（以下、該当端末とする）の該当するログ（以下、該当ログとする）における現在の状態を参照するためログ送信優先度調整テーブル２０４２を参照する（ステップ８０４）。該当端末の該当ログにおける送信優先度が「優」に設定されている場合（ステップ８０５：Ｙｅｓ）、サーバ側ログ管理部２０２が、該当端末における該当ログの 送信優先度を「低」に変更することを決定する（ステップ８０６）。
【００４８】
サーバ側ログ管理部２０２は、ログ送信優先度状態管理テーブル２０４２の該当端末の該当ログにおける送信優先度を「低」に変更し、合わせて変更した日時を書き込む（ステップ８０７）。 サーバ側ログ管理部２０２が、該当端末の該当ログの送信優先度を低下させるように、該当端末に対して命令を送信する（ステップ８０８）。なお、詳細は図９（ｂ）にて後述するが、ステップ８０８では、警戒値を超えたインシデントを検知した端末に対しても該当するログ（上記、該当ログに含む）の送信優先度を変更させる命令が出される。
【００４９】
次に、図９（ａ）、図９（ｂ）を用いて端末２の動作を説明する。本実施例では、ログの送信優先度を上げる方法として次に示す図９（ａ）、図９（ｂ）の２種類を例示する。
端末側ログ管理部２１１は、ログ収集／解析サーバ１から該当ログにおけるログ送信優先度を低下のさせる通知を受け取る（ステップ９０１）。
【００５０】
図９（ａ）は該当端末の該当ログの送信優先度を低下させる方法である。端末側ログ管理部２１１は、該当ログのログ送信量低下を、ログ送信量制御部２１３を用いて指示する（ステップ９０２）。ログ送信量を低下させる具体的な方法は、図５を用いて説明したためここでの説明は省略する。ログ送信量制御部２１３は、該当ログの、ログ送信量低下の設定を実施する（ステップ９０３）。
【００５１】
図９（ｂ）は送信量を低下させるログ以外のログつまり、送信優先度を上げるログを短時間で送信できるように、圧縮させて送信する方法である。警戒値を超えたインシデントが検出された端末の端末側ログ管理部２１１は、送信量を低下させるログ以外のログを圧縮させて送信するように指示する（ステップ９０４）。圧縮部２１４は、上記ログの圧縮を実施する（ステップ９０５）。
【００５２】
以上の流れを、テーブルを用いた具体例に沿って説明する。ステップ８０２のある端末のあるログにおける警戒値超えとは、例えば図３のインシデント警戒／障害検出テーブル２０３に示すインシデントＢ−１（アプリＸＸ通信障害）の端末Ｙにおける/var/log/.../cpuのログの値が、cpu利用率４５％になっていた場合であるとする。従って、図３インシデント警戒／障害検出テーブル２０３に示したようにインシデントＢ−１に関するログ（端末Ｙの/var/log/appliXX、端末Ｙの/var/log/.../cpu、端末Ｚの/var/log/.../nw）の収集を優先すべきとなる。このとき、ステップ８０４に示す該当端末の該当ログとは、警戒値を超えて、優先して収集すべきログ（端末Ｙの/var/log/appliXX、端末Ｙの/var/log/.../cpu、端末Ｚの/var/log/.../nw）以外のログ、つまり、端末Ｘの/var/log/iptables、端末Ｘの/var/log/.../cpuに相当する。警戒値超えを検出したインシデントＢ−１の根拠となるログを優先的に収集するために、以降、それ以外のインシデントＡ−１の根拠となるログの収集に関する優先度を低下させる処理を実施するわけである。同様に、９０４に示す、送信量を低下させるログ以外のログとは、端末Ｙの/var/log/appliXX、端末Ｙの/var/log/.../cpu、端末Ｚの/var/log/.../nwに相当する。
【００５３】
なお、本実施例では、該当ログの優先度を「低」に変えることで、相対的に警戒ログの優先度を上げる方法を説明したが、優先して収集すべきログおよび該当ログの優先度が「優」の場合に、優先して収集すべきログの優先度を「最優」などにして、優先して収集すべきグの優先度を主体的に上げる方法を採用することもできる。また、該当ログを「低」に変え、優先して収集すべきログを「最優」にするように組み合わせることもできる。
【００５４】
以上のようにインシデント発生の兆候を検知したインシデントに関連するログとそうでないログ（該当ログ）を区別し、警戒ログを優先的に収集することで限られたリソースの中で障害の発生検出の可能性を高めることができる。
【００５５】
次に、図７（ｂ）と図１０、図１１を用いて、上記図８、９に示す動作を受けて、警戒値を超過した後一定時間以上経過し、障害を検出しなかった場合の、処理のリセット動作（第１のリセット処理）を説明する。図１１（ａ）は該当端末のログ優先度状態を元の状態に戻す処理を示すフローチャートである。図１１（ｂ）は警戒値を超えたインシデントが検出された端末のログ圧縮処理の解除処理を示すフローチャートである。
【００５６】
図７（ｂ）に示すとおり、リセット動作はログ収集／解析サーバ１の動作から、端末２の動作に移る。
まず、図１０を用いてリセット動作におけるログ収集／解析サーバ１の動作について説明する。サーバ側ログ管理部２０２は、ログ送信優先度状態管理テーブル２０４２に記載の時刻２０４１４を参照する（ステップ１００１）。本実施例では「低」と設定された時刻を参照する。時刻２０４１４に記載されている時刻から一定時間以上経過しているか否かを判断し（ステップ１００２）、一定時間経過している場合（ステップ１００２：Ｙｅｓ）、サーバ側ログ管理部２０２がログ優先度調整テーブル２０４２を参照し、該当端末の該当ログの送信優先度を「優」に決定する（ステップ１００３）。サーバ側ログ管理部２０２が、ログ優先度調整テーブル２０４２の該当端末の該当ログの送信優先度を「優」に変更する（ステップ１００４）。サーバ側ログ管理部２０２が、該当端末の該当ログの送信優先度を、元の状態に戻すように該当端末へ命令を送信する（ステップ１００５）。なお、一定時間経過していない場合(ステップ１００２：Ｎｏ)、一定時間経過するまで処理を繰り返す。
【００５７】
次に、図１１を用いてリセット動作における端末２の動作を説明する。
端末側ログ管理部２１１は、ログ収集／解析サーバ１から、該当ログにおけるログ送信優先度低下の解除通知を受け取る（ステップ１１０１）。
【００５８】
図１１（ａ）では、該当端末の端末側ログ管理部２１１は該当ログのログ送信量低下を解除するよう、ログ送信量制御部２１３を通じて指示する（ステップ１１０２）。指示を受けたログ送信量制御部２１３は、該当ログにおける送信量低下の解除を設定する（ステップ１１０３）。
【００５９】
図１１（ｂ）では、警戒値を超えたインシデントが検出された端末の端末側ログ管理部２１１が、送信量を低下させるログ以外のログを送信する際にかけていた圧縮処理を停止するよう指示する（ステップ１１０４）。指示を受けた圧縮部２１４が、上記ログの圧縮処理解除を設定する（ステップ１１０５）。 
本発明は、警戒値を超過した際、そのインシデント発生の可能性が高くなっていると認識し、そのインシデントに関するログ収集の優先度を上げる処理を実施することを想定している。しかし、一定時間以上経過しても、インシデントが発生しなかったという状況では、当該インシデント発生の可能性が高くないものと見なし、このように、ログ収集に関する優先制御をリセットするものとする。ここでは、警戒値を超過して一定時間経過した際のリセット処理を示したが、例えば、警戒値を超過して、再び、警戒値を下回った場合も、同様のリセット処理を実施しても良いものとする。
【００６０】
次に、図７（ｂ）と図１２、図１１を用いて、障害値を超えたインシデントを検出した場合の、処理のリセット動作（第２のリセット処理）を説明する。図７（ｂ）に示すとおり、ログ収集／解析サーバ１の動作を受けて、端末２の動作に移る。
【００６１】
まず、図１２を用いてログ収集／解析サーバ１の動作について説明する。障害検出管理部２０１２は、インシデント警戒／障害検出テーブル２０３を参照し、障害値超えているインシデントが有るか否かを監視する（ステップ１２０１）。あるインシデントにおける、ある端末から送信されたあるログにおいて、障害値超えを検出すると（ステップ１２０２：Ｙｅｓ）、障害検出管理部２０１２は、サーバ側ログ管理部２０２に障害値を超えたインシデントの検知を通知する（ステップ１２０３）。障害値越えを検出しない場合（ステップ１２０２：Ｎｏ）、処理をループさせる。
【００６２】
検知を通知されたサーバ側ログ管理部２０２は、ログ送信優先度調整テーブル２０４２を参照する（ステップ１２０４）。該当端末の該当ログにおける送信優先度が「低」に設定されている場合（ステップ１２０５：Ｙｅｓ）、サーバ側ログ管理部２０２が、該当端末における該当ログの 送信優先度を「優」に決定する（ステップ１２０６）。サーバ側ログ管理部２０２は、ログ送信優先度状態管理テーブル２０４２の該当端末の該当ログにおける送信優先度を「優」に変更する（ステップ１２０７）。 サーバ側ログ管理部２０２が、該当端末の該当ログの送信優先度を元の状態に戻すように、該当端末に対して命令を送信する（ステップ１２０８）。次に、端末２の処理に移行するが、これは、図１１（ａ）にて説明したとおりであるため、省略する。
【００６３】
次に、図７（ｃ）と図１３、図１４を用いて、障害値越えのインシデントを検出した場合の一部のログ送信停止の動作について説明する。図７（ｃ）に示すとおり、ログ送信停止処理はログ収集／解析サーバ１の動作から、端末２の動作に移る。
【００６４】
まず、図１３を用いてログ収集／解析サーバ１の動作について説明する。障害検出部２０１にある障害検出管理部２０１２は、インシデント警戒／障害検出テーブル２０３を参照し、障害値超えたインシデントの有無を監視する（ステップ１３０１）。あるインシデントにおける、ある端末から送信されたあるログにおいて、障害値超えを検出すると（ステップ１３０２：Ｙｅｓ）、サーバ側ログ管理部２０２が、ログ送信停止テーブル２０４３に、障害値を超えたインシデントを検出した端末に対して該当ログの該当部分のみの送信を停止する情報を書き込む（ステップ１３０３）。サーバ側ログ管理部２０２が、障害値を超えたインシデントを検出した端末に対し、該当するログの該当部分のみの送信を停止する命令を送信する（ステップ１３０４）。
【００６５】
次に、図１４を用いて端末２の動作を説明する。障害値を超えたインシデントを検出した端末の端末側ログ管理部２１１が、ログ収集／解析サーバ１から、該当ログの該当部分の送信停止の通知を受け取る（ステップ１４０１）。障害値を超えたインシデントを検出した端末の端末側ログ管理部２１１が、該当ログの該当部分のログ送信停止を、端末側ログ送信部２１２を通して指示する（ステップ１４０２）。端末側ログ送信制御部２１２が、該当ログの該当部分のそれ以降の送信を停止する（ステップ１４０３）。
【００６６】
これは、図６のログ送信停止テーブル２０４３にて説明したとおり、障害値を超えたインシデントを検出し、そのインシデントに対する対策が完了した後、端末２から、それ以上送信する必要のない情報の送信を停止するための処理となる。具体的には、図６にて説明したとおり、/var/log/iptablesの送信先ＩＰアドレス１０．１０．１０．１のレコードを送信する必要がなくなった場合、この部分のみの送信を停止する。不要なログの送信を停止する事で、無駄なリソースの消費を抑えることができる。
【００６７】
なお、本実施例にて示したフローは、例えば、ログ収集／解析サーバ１側でログ送信量を決定するテーブルを保持し、端末２は、ログ収集／解析サーバ１側の指示を受けてその通りの処理を実施するものとして記載したが、もちろん、一部の情報（例えばログ送信優先度調整テーブル２０４２）を、端末２側で保持し、端末２側で情報を参照して、処理を実行しても良い。
【００６８】
図１５は、本実施例においてログ収集の優先度を変更した際の端末２の送信帯域の変化を示した図である。図５のログ送信優先度調整テーブル２０４２に示したとおり、通常状態、つまり送信優先度が優の上限帯域は、１００Ｋｂｐｓに設定されてある。このときは、端末２からのログ送信帯域の時間的変化を見ると、図１５の（１）通常状態に示すように、１００Ｋｂｐｓを上限に、ログの送信帯域がピークを迎え、短時間でログの送信が完了する。
【００６９】
一方、ステップ９０３にてログ送信量の低下の設定をした場合、図１５の（２）帯域制限（上限：１０ｓＫｂｐｓ）をかけた場合に示すように、１０Ｋｂｐｓを上限に、ログの送信帯域がピークを迎え、（１）と比較して、長い時間でログの送信が完了する。
【００７０】
即ち、帯域制限をかけた場合は、ログの送信に長い時間がかかるものの、帯域制限をかけない場合に比べて帯域全体のリソースの消費は少ないことを示している。 
図１６は、本実施例における、グラフィカルユーザインターフェース（ＧＵＩ）の例を示した図である。インシデント一覧画面には、インシデント警戒／障害検出テーブル２０３に示したようなインシデントの一覧が表示される。また、それぞれのインシデントを検出するための根拠となるログを送信する端末とログ種別が表示され、それぞれのログ種別毎に現在の端末２からの「現在の送信優先度」が表示されている。このボタンを押下すると、より詳細なログの送信状態が表示される。例えば、端末Ｘの/var/log/iptablesは、障害値に「１分間以内に１０００以上の同一宛先ＩＰアドレスのパケットの出現」、警戒値に「１分間以内に７００以上の同一宛先ＩＰアドレスのパケットの出現」という条件が設定され、現在は送信優先度が「低」の状態に設定されおり、その送信上限帯域は、１０Ｋｂｐｓで、端末２からＴＣＰポート１０００１を利用して送信されている、といったような情報が表示される。
【００７１】
また、例えば、「設定の確認」の詳細設定を押下すると、図３〜図６に示した各テーブルの値を修正することが可能となる。ログ送信状況表示画面では、例えば、インシデント一覧画面で選択した端末におけるログの送信帯域の推移が表示される。例えば、カーソルを合わせることで、どのログが、どれくらいの帯域で送信されているかを確認することができる。操作履歴画面では、いつ、本発明における何の処理が実行されたかの履歴を表示する。
【００７２】
上記する構成を備えることで、本実施例のログ収集システムは、インシデント発生の兆候を検知したインシデントに関連するログの収集を優先的に行い、限られたリソースの中で障害の発生検出の可能性を高めることができる。
【００７３】
なお、本発明は上記した実施例に限定されるものではない。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
【符号の説明】
【００７４】
１：ログ収集／解析サーバ、２：端末、２１：メモリ、２２：入力装置、２３：出力装置、２４：ＣＰＵ、２５：通信装置、２０１：障害検出部、２０１１：警戒検出管理部、２０１２：障害検出管理部、２０２：サーバ側ログ管理部、２０２１：サーバ側ログ送信管理部、２０２２：ログ送信命令部、２０３：インシデント警戒／障害検出テーブル、２０４：ログ管理テーブル群、２０４１：ログ優先度状態管理テーブル、２０４２：ログ送信優先度調整テーブル、２０４３：ログ送信停止テーブル、２０５：サーバ側ログデータ、２０６：サーバ側ログ受信部、２１１：端末側ログ管理部、２１２：端末側ログ送信部、２１２１：ログ送信部、２１２２：ログ送信用バッファ領域、２１３：ログ送信量制御部、２１４：圧縮部、２１５：端末側ログデータ、Ｐｎ：ポート
【図１】
2018010441.tif 000003
【図２】
2018010441.tif 000004
【図３】
2018010441.tif 000005
【図４】
2018010441.tif 000006
【図５】
2018010441.tif 000007
【図６】
2018010441.tif 000008
【図７（ａ）】
2018010441.tif 000009
【図７（ｂ）】
2018010441.tif 000010
【図７（ｃ）】
2018010441.tif 000011
【図８】
2018010441.tif 000012
【図９】
2018010441.tif 000013
【図１０】
2018010441.tif 000014
【図１１】
2018010441.tif 000015
【図１２】
2018010441.tif 000016
【図１３】
2018010441.tif 000017
【図１４】
2018010441.tif 000018
【図１５】
2018010441.tif 000019
【図１６】
2018010441.tif 000020