JP2005250760A - アラート通知装置 - Google Patents

Abstract

【課題】 監視対象のシステムにトラブルが発生したときに、各管理者の管理権限に基づいてアラートの通知順序を決定し、アラートの通知を行った管理者が対処を行えない場合に、決定した通知順に次の管理者へアラートを通知する。
【解決手段】 公開サーバ１００（アラート通知システム）に、アプリケーションにアラートを通知すべき事象が発生したことを検出する検出手段と、前記検出手段がアプリケーションにアラートを通知すべき事象が発生したことを検出したときに該アプリケーションの管理者のうち所定の管理権限を有する管理者へアラートを通知するとともに、アラートを通知してから所定の時間内に該アプリケーションのいずれの管理者も発生した前記事象への対処を開始しない場合に直前にアラートを通知した管理者より広範囲な管理権限を有する管理者へアラートを通知することを繰り返す対応判断手段と、を備える。
【選択図】 図１

Description

本発明は、アラート通知装置に関する。

従来、システムに障害や不正アクセスが発生した際に、電子メールなどを用いてその場にいないシステム管理者（以下、単に「管理者」という）へアラートを通知することが行われている。しかし、このようなシステムでは、予めシステム内に定義された管理者宛にシステムの障害の検出や不正アクセスの検出についての内容を単に通知するものである。
一方、特許文献１には、以下の技術が開示されている。すなわち、情報を検索する装置において、検索者の利用者情報などを情報の検索の都度履歴情報に記録していき、履歴情報記録部の容量が限界に近づいた場合に、別の記録媒体への履歴情報の保存を促す。このとき、まず、最上位の管理者へメール等で警告通知を発し、その管理者が何らの対応も行わない場合に、その下位の管理者に警告通知を発し、対応が行われるまでさらにその下位の管理者へ警告を通知するという動作を繰り返す。
また、特許文献２には、ＬＡＮ（Local Area Network）における電子メールシステム上で障害が発生した場合、メールサーバの障害状況を複数管理者のうち最適な者に通知するために、サーバとネットワークの故障箇所に影響されないか、あるいは、メールの未読が多いか少ないか、メールソフトを使用中であるか、もしくは、予め設定した優先度の高低などから、優先度判定手段が総合的に判断し、最も迅速に対応が可能と判断される管理者に通知を行う技術が開示されている。
特許第２９８３８０１号明細書 特開平８−２３７２９６号公報

上述するように、従来の障害検知システムや侵入検知システムなどにおいて、監視対象のシステムに不正アクセスや障害、あるいは、その兆候が発生した場合に電子メールなどで管理者にアラートを通知することは可能であった。しかし、アラートの通知の際に必要となるシステムの管理体制に関する情報は、システムのＯＳ（オペレーションシステム）やアプリケーションの施行するアクセス件とは独立に管理されるため、以下のような問題が発生する。
（１）管理者とその管理に必要な権限の対応関係が明確ではないため、複数の管理者による管理を行う場合、初期対応の役割を分割できない。
（２）管理者への通知は事前想定内容に基づき固定的に行うため、複数の管理者による管理を行う場合、予期せぬ障害及び不正アクセスの発生に対しては、適切な対応者の特定が困難となる。
しかし、特許文献１及び特許文献２に開示の技術では、監視対象のシステムに複数の管理者が存在する場合、それぞれの管理者の管理権限（管理対象または管理範囲）に基づいて管理者を順位付け、アラートを通知することは行っていない。

本発明は、このような事情を考慮してなされたもので、その目的は、監視対象のシステムにトラブルが発生したときに、各管理者の管理権限に基づいてトラブルが発生したサービスについてのアラートの通知順序を決定し、管理者が対処を行えない場合に次の通知順に管理者へアラートを通知することができるアラート通知装置を提供することにある。

この発明は、上記の課題を解決すべくなされたもので、請求項１に記載の発明は、アプリケーションにアラートを通知すべき事象が発生したことを検出する検出手段と、前記検出手段がアプリケーションにアラートを通知すべき事象が発生したことを検出したときに該アプリケーションの管理者のうち所定の管理権限を有する管理者へアラートを通知するとともに、アラートを通知してから所定の時間内に該アプリケーションのいずれの管理者も発生した前記事象への対処を開始しない場合に直前にアラートを通知した管理者より広範囲な管理権限を有する管理者へアラートを通知することを繰り返す対応判断手段と、を備えることを特徴とするアラート通知装置である。

請求項２に記載の発明は、請求項１に記載のアラート通知装置であって、前記対応判断手段は、アラートを通知してから所定の時間内に通知先の管理者から該アラートへ対応する旨の意思表示の通知を受信しない場合に、該管理者より広範囲な管理権限を持つ管理者へアラートを通知する、ことを特徴とする。

請求項３に記載の発明は、請求項１または請求項２に記載のアラート通知装置であって、前記アプリケーションにアラートを通知すべき事象が発生してから所定時間内に該アプリケーションのいずれの管理者も発生した前記事象への対処を開始しないときに、該アプリケーションの提供を制限するアプリケーション提供制限手段をさらに備える、ことを特徴とする。

請求項４に記載の発明は、請求項１から請求項３のいずれかの項に記載のアラート通知装置であって、アプリケーションの提供に用いられるリソースに対する各管理者の管理権限を基に、アプリケーションに関するアラート通知順序を決定する送信先判断手段をさらに備え、前記対応判断手段は、前記送信先判断手段が決定したアラート通知順序に従いアラートを通知すべき管理者を選択する、ことを特徴とする。

請求項５に記載の発明は、請求項１から請求項４のいずれかの項に記載のアラート通知装置であって、前記検出手段は、各アプリケーションの提供に用いられるリソースへのアクセスに関するログを記憶するログ記憶手段と、各アプリケーションの提供に用いられるリソースへのアクセスがあったときに前記ログ記憶手段にログを書き込むログ書込手段と、前記ログ記憶手段内のログを基に前記アプリケーションにアラートを通知すべき前記事象の発生あるいは管理者による前記事象への対処の開始を検出するログ監視手段とからなる、ことを特徴とする。

本発明によれば、個々の管理者に対して、当該管理者が管理しているアプリケーションに直接関連しない不正アクセスや障害対応などのトラブルについての不要なアラートを通知せずに済む。そのため、状況確認に係るコストが削減される。また、個々の管理者は、自分に届いた通知であれば、必ず自分の管理しているアプリケーションに関したトラブルであると認識できるので、対応をスムーズに取ることが可能となる。
また、管理者が自身の管理するアプリケーションに対してトラブルへの対応を行うことができない場合であっても、その上位の管理者に通知が転送されるため、トラブルへの対応を迅速に取ることが可能となる。
また、システムの管理権限に基づいてアラートの通知先となる管理者の構造化を行っていくため、事前に管理体系などを設定しておく必要がなくなる。
また、トラブルへの対応が遅れた場合にはアプリケーションの縮退や停止などの制限を行うことにより、システムの安全性が向上する。

以下、図面を参照して本発明の一実施の形態を説明する。
図１は、本発明の一実施の形態によるアラート通知システムの全体構成を示す図である。同図において、アラート通知システムは、アラート通知装置としての公開サーバ１００と、公開サーバ１００の管理者Ａ、Ｂ、Ｃ、…（以下、総称して「管理者」という）の管理用端末２００とを、私設網や公衆網などからなるネットワークＮを介して接続して構成される。

公開サーバ１００は、アプリケーションとして、Ｈｔｔｐ（Hypertext Transfer Protocol）やｆｔｐ（File Transfer Protocol）などの公開サービスを外部のユーザへ提供したり、ユーザ毎の使用領域を管理するためのユーザ領域サービスやプロキシなどの内部サービスを内部のユーザへ提供する。また、公開サーバ１００は、管理者の管理用端末２００へアラートを通知するためのアラート送受信機能と、ネットワークＮを介してアクセスされる管理用端末２００からリモートによる操作を受けるためのリモート操作インターフェースと、自身が備えるコンソールなどからローカルな操作を受けるためのローカル操作インターフェースとを備える。
一方、管理用端末２００は、例えば、公開サーバ１００からのアラートの通知を受けるためのアラート送受信機能と、公開サーバ１００へネットワークＮを介してアクセスし、リモートの操作を行うためのサーバ操作機能とを備える。
このような構成により、公開サーバ１００から管理者の管理用端末２００への障害や不正アクセスなどのトラブルに対するアラートの通知、管理用端末２００から公開サーバ１００へのアラートに対して対処を行う旨の管理者の意志表示の通知（以下、単に「意思表示」と記載）、公開サーバ１００へローカルに、あるいは、管理用端末２００からリモートによるアラートへの対応のための管理者の操作を実現する。

さらに、公開サーバ１００は、以下のようなアラートの通知のエスカレーション機能（以下、単に「エスカレーション」ともいう）を有する。すなわち、公開サーバ１００は、自身が提供するアプリケーションが用いるリソースに対する不正アクセスや障害などのトラブルを検知すると、予め設定された管理範囲に対応する管理者のみにアラートを通知する。そして、通知後一定時間内に通知を行った管理者から意思表示を受けない場合、あるいは、意思表示を受けたが、アラートへの対応が開始されたことを検出しない場合には、さらに広範囲な管理権限を有する管理者を上位の管理者として認識し、その上位の管理者へアラートを通知する。そして、最初にアラートの通知を行ってから一定時間内にどの管理者からもアラートへの対応が開始されない場合、公開サーバ１００は、トラブルがあったアプリケーションサービスの制限を行い、被害の拡大を防ぐ。

図２は、同実施の形態による公開サーバ１００の内部構成を示すブロック図である。
公開サーバ１００は、公開サービス提供部１１０、内部サービス提供部１２０、カーネル１３０、ログ記憶部１４０、ログ監視部１５０、状態・送信判断部１６０、通信部１７０、リモート操作インターフェース部１８０、及び、ローカル操作インターフェース部１９０からなる。

公開サービス提供部１１０は、ネットワークＮを介して接続される図示しないコンピュータ端末からアクセスしている外部ユーザへ各種公開サービスを提供する機能を有する。
内部サービス提供部１２０は、ネットワークＮを介して接続される図示しないコンピュータ端末や管理用端末２００、公開サーバ１００自身が備えるコンソールなどからアクセスしている内部ユーザや管理者等へ、内部のシステムリソースを利用した各種内部サービスを提供する機能を有する。
カーネル１３０は、ＯＳ（オペレーションシステム）の基本的な機能を実現し、内部リソースの管理やアクセス可否判定などを行い、ログ記憶部１４０へログを書き込む機能を有する。ログには、例えば、ユーザや管理者からのログイン履歴やリソースへのアクセス履歴、公開サービスや内部サービス、リソースへのアクセスが正当であるか不正であるか、などの情報が含まれる。
ログ記憶部１４０は、カーネル１３０により書き込まれたログを記憶する。
ログ監視部１５０は、ログ記憶部１４０内のログを監視し、公開サービスや内部サービスに不正アクセスや障害などアラートを通知すべきトラブルが発生したことや、管理者がアラートへの対応を開始したことを認識する機能を有する。なお、管理者がアラートへの対応を開始したことの認識は、公開サービスや内部サービスを提供するためのリソースへ管理者がアクセスしたことを認識することにより行われる。

通信部１７０は、管理者の管理用端末２００へアラートの通知を行う機能と管理者の管理用端末２００からの意思表示を受信する機能を有する。これは、例えば、ＳＭＴＰ（Simple Mail Transfer Protocol）を用いて電子メールなどにより行う。
リモート操作インターフェース部１８０は、ネットワークＮを介して接続される管理用端末２００からｔｅｌｎｅｔやｓｓｈ（Secure Shell）などによる管理者のリモートの操作を受け、実行する機能を有する。
ローカル操作インターフェース部１９０は、公開サーバ１００が備える図示しないコンソールなどから管理者の操作を受け、実行する機能を有する。

状態・送信判断部１６０は、状態判断部１６１、対応判断部１６２、タイムカウンター部１６３、送信先判断部１６４、送信先記憶部１６５、及び、サービス縮退・停止実行部１６６からなる。
状態判断部１６１は、ログ監視部１５０による公開サービスや内部サービスにおける障害や不正アクセスの発生の認識、管理者によるアラートへの対応の開始の認識、あるいは、通信部１７０から受信した意思表示に基づき、アラートへの対処状態を判断する。アラートへの対処状態とは、例えば、アラートを通知済みであるか否か、アラートの通知後に意思表示を受信したか否か、管理者による対応待ちであるか否か、などである。

対応判断部１６２は、状態判断部１６１の判断した対処状態に基づき、通知のエスカレーションを行うか否か、あるいは、サービスの停止や縮退を行うか否かなどを判断する。
タイムカウンター部１６３は、アラートを通知してから通知先の管理者より意思表示を受信するまでのタイムアウト時間ｔ１（以下「時間ｔ１」）、意思表示を受信してからアラートへ対応する権限のある管理者により対応が開始されるまでのタイムアウト時間ｔ２（以下、「時間ｔ２」）、及び、最初のアラートを通知してからアラートに対して対応する権限のある管理者により対応が開始されるまでの対応時間Ｔを計測する。

送信先判断部１６４は、送信先記憶部１６５を参照してアラートを通知すべき管理者を選択する。
送信先記憶部１６５は、アプリケーション（ＡＰ−）管理者対応リストを記憶する。ＡＰ−管理者対応リストは、各公開サービスや内部サービス毎にエスカレーションルールに従った管理者へのアラートの通知順序を記憶する。
サービス縮退・停止実行部１６６は、対応判断部１６２の指示により、サービスの停止や縮退などのサービスの制限を行う。サービスの縮退の例としては、ｆｔｐであればanonymousログインの停止する、プロキシであれば存在キャッシュのみを提供する、などである。

次に、アラート通知システムの動作について説明する。
図３は、アラートの通知のエスカレーション機能におけるアラートの通知順序を決定するための管理者構造の生成手順を示すフロー図である。
まず、公開サーバ１００の送信先判断部１６４は、公開サーバ１００が提供する各サービスのリソースにアクセス可能な役割（ロール）を解析する（ステップＳ１２）。例えば、公開サーバ１００の公開サービス提供部１１０において、「ｆｔｐサービス」及び「Ｈｔｔｐサービス」が提供され、内部サービス提供部１２０において、「ユーザ領域サービス」が提供されているとする。このとき、「ｆｔｐサービス」のリソースへアクセスが許可されるのは、「ｆｔｐ管理ロール」、「公開サービス管理ロール」、及び、「全体管理ロール」であり、「Ｈｔｔｐサービス」のリソースへアクセスが許可されるのは、「Ｈｔｔｐ管理ロール」、「公開サービス管理ロール」、及び、「全体管理ロール」である。また、「ユーザ領域サービス」のリソースへアクセスが許可されるのは、「ユーザ領域管理ロール」、及び、「全体管理ロール」である。

次に、送信先判断部１６４は、ステップＳ１２において解析したロールについて、各サービスを管理する権限の構造化を行う（ステップＳ１４）。構造化の例を以下に示す。
送信先判断部１６４は、自身が提供している「ｆｔｐサービス」、「Ｈｔｔｐサービス」、及び、「ユーザ領域サービス」のリソースにアクセス可能な各ロールについて、そのアクセス可能な範囲を考慮して階層化する。そこで、各サービスのリソースへのアクセス許可がなされているロールのうち、最も多くの種類のサービスのリソースへのアクセス許可がなされているロールを階層の最上位のロールと決定する。具体的には、公開サーバ１００が提供している「ｆｔｐサービス」、「Ｈｔｔｐサービス」、及び、「ユーザ領域サービス」の全てのサービスのリソースにアクセス可能な「全体管理ロール」を最上位の階層のロールとする。

次に、この最上位の階層のロールを含むサービスにおいて、当該サービスのリソースへのアクセスが許可されているロールのうち、最上位の階層のロールを除き最も多くの種類のサービスのリソースへのアクセスが許可されているロールを最上位より一つ下位の階層のロールとする。具体的には、「全体管理ロール」を含むサービスは、「ｆｔｐサービス」、「Ｈｔｔｐサービス」、及び、「ユーザ領域サービス」であり、「全体管理ロール」以外で最も多くの種類のサービスのリソースへのアクセス許可がなされているロールは、「ｆｔｐサービス」及び「Ｈｔｔｐサービス」に対応する「公開サービス管理ロール」である。従って、「公開サービス管理ロール」が「全体管理ロール」の一つ下位の階層のロールとなる。

続いて、最上位の階層のロールを含み、既に決定された最上位より一つ下位の階層のロールを含まないサービスを選択する。そして、この選択したサービスのリソースへのアクセスが許可されているロールのうち、すでに階層が決定しているロールを除き最も多くの種類のサービスのリソースへのアクセスが許可されているロールを他の最上位より一つ下位の階層のロールとする。そして、これを繰り返して、全ての最上位より一つ下位の階層のロールが決定する。すなわち、「全体管理ロール」を含み、「公開サービス管理ロール」を含まないサービスとして、「ユーザ領域サービス」が選択される。選択されたサービスは１つであるので、この「ユーザ領域サービス」の中で「全体管理ロール」以外のロール「ユーザ領域管理ロール」が「全体管理ロール」の他の最上位より一つ下位の階層のロールとなる。
更に、最上位より一つ下位の階層の各ロールについて、同様の処理により更に一つ下位の階層のロールを決定する。

送信先判断部１６４は、上述する処理を繰り返すことにより、サービスを管理する権限の構造化を行う。
具体的には、図３に示すように、サービスを管理する権限の全体構造は、「全体管理ロール」を最上位のロールとして、その配下に「公開サービス管理ロール」及び「ユーザ領域管理ロール」が存在し、さらに、「公開サービス管理ロール」の配下に「ｆｔｐ管理ロール」及び「Ｈｔｔｐ管理ロール」が存在するツリー構造となる。このツリー構造においては、ルートに近いロールがより広範囲な権限を持つ。

送信先判断部１６４は、各サービスの権限を構造化すると、続いて、内部に設定されている各管理者のリソースの管理権限から役割設定を読み（後述する図６参照）、この階層構造を構成する各ロールへマッピングする（ステップＳ１６）。
このように管理者構造を生成することにより、各サービスに対するアラートの通知のエスカレーションは、サービスを管理する権限の最も狭い下位のロールの管理者から、より権限の広い上位のロールの管理者への順に行われる。例えば、Ｈｔｔｐサービス障害時のアラートの通知のエスカレーションは、Ｈｔｔｐ管理ロールの管理者、公開サービス管理ロールの管理者、全体管理ロールの管理者の順となる。また、ユーザ領域障害時のアラートの通知のエスカレーションは、ユーザ領域管理ロールに属する管理者、全体管理ロールに属する管理者の順となる。

また、１つのロールに複数の管理者が存在する場合には、以下のようなルールにより、通知のエスカレーションの順番を決定する。
（１）持っているロールが少ない管理者を選任管理者と見なす。これは、選任管理者がそのサービスに対してより熟知していると考えられるため、順位を高くするものである。
（２）各管理者が持っている最上位のロールの階層がより下である管理者を下位管理者と見なす。これは、部分的な権限を持つ管理者が、その部分の責任を負っていると考えられることによるものである。
なお、権限が少ない管理者から、より大きい権限の管理者へとエスカレーションする以外のルールの設定や対応は行わなくとも、通知が必要な責任者などを手動で通知先として設定してもよい。

図４は、各管理者のサービスの管理権限の例を、図５は、図４に示す各管理者のサービスの管理権限を基に決定される各サービスの障害や不正アクセス発生時のアラートの通知順位を示す。
図４においては、管理者ＡはＨｔｔｐの管理権限を持つため「Ｈｔｔｐ管理ロール」に属し、管理者Ｂはｆｔｐの管理権限を持つため「ｆｔｐ管理ロール」に属し、管理者Ｃは公開サービスの管理権限を持つため「公開サービス管理ロール」に属し、管理者Ｄはユーザ領域の管理権限を持つため「ユーザ領域管理ロール」に属する。また、管理者Ｅは、Ｈｔｔｐ、ｆｔｐ、公開サービス及びユーザ領域の管理権限を持つため、「Ｈｔｔｐ管理ロール」、「ｆｔｐ管理ロール」、「公開サービス管理ロール」及び「ユーザ領域管理ロール」に属する。なお、管理者Ａ、Ｂ、Ｃ、Ｄ、Ｅはそれぞれ、公開サーバ１００内において、User A，User B，User C，User D，User Eとして識別されるものとする。

この場合、図３に示すように、「Ｈｔｔｐサービス」の障害時は、アラートの通知のエスカレーションルールにより、「Ｈｔｔｐ管理ロール」に属する管理者がアラートの一次（最初の）通知者（対応者）となる。ここで、「Ｈｔｔｐ管理ロール」に属する管理者は、管理者Ａ及び管理者Ｅである。しかし、持っているロールが少ない管理者を選任管理者と見なすルール、あるいは、それぞれの管理者が持っている最上位のロールの階層がより下である管理者を下位管理者と見なすルールに従い、管理者Ａがアラートの一次通知者となる。

また、「Ｈｔｔｐサービス」の次の通知先となる二次通知者（対応者）は、「Ｈｔｔｐ管理ロール」より権限の大きい「公開サービス管理ロール」に属する管理者となる。「公開サービス管理ロール」の管理者は、管理者Ｃ及び管理者Ｅであるが、持っているロールが少ない管理者を選任管理者と見なすルールに従い、管理者Ｃが二次通知者（対応者）、管理者Ｅが三次通知者（対応者）となる（図５参照）。同様に、図５に示すように、ｆｔｐサービスにおける一次通知者は管理者Ｂ、二次通知者は管理者Ｃ、三次通知者は管理者Ｅとなる。また、ユーザ領域サービスにおける一次通知者は管理者Ｄ、二次通知者は管理者Ｅとなる。また、複数のサービスに同時にトラブルが発生した場合、これらのサービスに共通の最も下位の管理者が最初の管理者となる。例えば、「Ｈｔｔｐサービス」及び「ｆｔｐサービス」両方にトラブルが発生した場合、両サービスに共通の最も下位の管理者、すなわち、「公開サービス管理ロール」に属する管理者Ｃが最初の管理者となる。

図６は、公開サーバ１００内における管理者の管理権限の設定例を示す。同図において、管理者Ａのロールは管理者Ａ（User A）の行に対応する「http_admin_r」により設定されることが示されている。そして、この「http_admin_r」で設定される権限は、「http_admin_t」で規定され、Ｈｔｔｐサービス（ｈｔｔｐ）の提供に関わるリソースの設定を変更するための権限が割り当てられていることが示されている。例えば、管理者Ｃ（User C）や管理者Ｅ（User E）に、Ｈｔｔｐサービスの変更の権限を与えることで、Ｈｔｔｐ管理ロールを担うことになる。

このように、公開サーバ１００内にサービスの管理に必要な権限の割り当てを各ユーザ毎に設定しておくことにより、結果として送信先判断部１６４は、図４に示すような各管理者のサービスの管理権限を認識し、さらに、このサービス管理権限を基に図５に示すような各サービスのアラートの通知順位（管理者の管理組織）を決定する。すなわち、最上位管理者が管理者Ｅ（最上位管理者Ｅ）であり、その配下にユーザ領域サービスの管理者Ｄと上位管理者Ｃとが存在し、さらに、上位管理者Ｃの配下にＨｔｔｐサービスの管理者Ａ及びｆｔｐサービスの管理者Ｂが存在する組織となる。
そして、図５に示すような管理組織を示す情報は、ＡＰ−管理者対応リストとして公開サーバ１００内の送信先記憶部１６５内に記憶される。なお、ＡＰ−管理者対応リストは、送信先判断部１６４が予め生成して設定しておくことでもよく、アラートの通知の必要性が生じる毎に生成してもよい。また、管理者がＡＰ−管理者対応リストを作成して送信先記憶部１６５に登録することでもよい。また、管理権限とは無関係であり、対応を要求せずにアラートの通知のみを行う送信先のユーザのリストを管理者が作成し、さらに送信先記憶部１６５に登録してもよい。

図７〜図９は、アラートの通知のエスカレーションにおける動作概要を説明するための図である。
図７において、公開サーバ１００の公開サービス提供部１１０が提供するＨｔｔｐサービスに、不正アクセスがあったとする（ステップＳ２２）。このとき、カーネル１３０は、Ｈｔｔｐサービスからリソースの読出しなどのシステムコールを受ける（ステップＳ２４）。カーネル１３０は、Ｈｔｔｐサービスへのアクセスが不正であったことのアクセス判定結果をログ記憶部１４０に書き込む。ログ監視部１５０は、ログ記憶部１４０内にログとして記録されたアクセス判定結果により不正アクセスを検出すると、状態・送信判断部１６０に通知する（ステップＳ２６）。

状態・送信判断部１６０の状態判断部１６１がＨｔｔｐサービスへの不正アクセスについてまだどの管理者にもアラートを送信していないことを判断すると、送信先判断部１６４は、送信先記憶部１６５内のＡＰ−管理者対応リストを参照し、最初にＨｔｔｐサービスのアラートの通知を行う管理者を選択する。そして、送信先判断部１６４からの指示を受けた通信部１７０は、一次管理者である管理者Ａの管理用端末２００宛にＨｔｔｐサービスのアラートを電子メールなどにより通知する（ステップＳ３０）。このとき、送信先記憶部１６５内にアラートの通知のみを行う送信先のユーザのリストが登録されている場合には、このリストで示されるユーザにもアラートを通知する。

次に、図８において、公開サーバ１００は、アラートを通知した管理者Ａの管理用端末２００から、アラートへの対応を行う旨の意思表示を電子メールなどにより受信する（ステップＳ３２）。そして、管理者Ａが管理用端末２００からリモート操作により、あるいは、コンソールからのローカル操作により公開サーバ１００へログインし、Ｈｔｔｐサービスの状況を確認する（ステップＳ３４）。このとき、管理者ＡがＨｔｔｐサービスにアクセスすることにより、カーネル１３０は、公開サービス提供部１１０が提供するＨｔｔｐサービスのリソースから読出しなどのシステムコールを受ける（ステップＳ３６）。カーネル１３０は、管理者Ａ（User A）のログインや、Ｈｔｔｐサービスへのアクセス、操作に関するログをログ記憶部１４０に書き込む。ログ監視部１５０は、ログ記憶部１４０に記録されたログを読み出して、管理者Ａがログインし、状況確認が行われたことを認識する（ステップＳ３８）。

一方、図９は、図７のステップＳ３０におけるアラートの通知後に、公開サーバ１００が管理者から意思表示を受信せず、また、管理者による状況確認も行われなかった場合を示す。
公開サーバ１００の状態判断部１６１は、管理者Ａへのアラートの通知後、意思表示を所定の時間内に受信しなかったことを認識し、また、ログ監視部１５０は、ログ記憶部１４０内にカーネル１３０が記録したログに、どのＨｔｔｐサービスの管理者（対応者）からも状況確認が行われていないことを認識する（ステップＳ４２）。すると、送信先判断部１６４は、送信先記憶部１６５内のＡＰ−管理者対応リストを参照し、次にＨｔｔｐサービスのアラート通知を行う二次管理者を選択する。そして、送信先判断部１６４の指示により、通信部１７０は、二次管理者である上位管理者Ｃの管理用端末２００宛にＨｔｔｐサービスのアラートを通知する（ステップＳ４４）。

公開サーバ１００は、上位管理者Ｃから意思表示を所定の時間内に受信せず、どのＨｔｔｐサービスの管理者からも状況確認が行われていないことを認識すると、同様の手順によりさらに三次管理者である最上位管理者Ｅの管理用端末２００へアラートを通知する。そして、公開サーバ１００は、最上位管理者Ｅからも意思表示を所定の時間内に受信せず、どのＨｔｔｐサービスの管理者からも状況確認が行われていないことを認識した場合、Ｈｔｔｐサービスの停止や縮退など被害の拡大を防ぐ緊急の措置を行う（ステップＳ４６）。

図１０は、公開サーバ１００の動作を示すフロー図である。
まず、公開サーバ１００が提供する公開サービス提供部１１０あるいは内部サービス提供部１２０の提供する任意のサービスに障害や不正アクセスなどのトラブルが発生すると、ログ監視部１５０は、カーネル１３０がログ記憶部１４０に書き込んだログによりこれを検出する（ステップＳ５０）。
すると、公開サーバ１００は、エスカレーションにおけるスタートの管理者を見つけアラートの通知を行う（ステップＳ５２）。すなわち、状態・送信判断部１６０の状態判断部１６１が、どの管理者へもアラートを通知していないことを認識すると、対応判断部１６２は、一次管理者へアラートを通知しなければならないことを判断する。送信先判断部１６４は、送信先記憶部１６５内のＡＰ−管理者対応リストを参照して、トラブルがあったサービスに対する一次管理者を決定する。対応判断部１６２は、通信部１７０に指示することにより、この一次管理者へアラートの通知を行う。さらに、タイムカウンター部１６３は、対応期限Ｔ及び時間ｔ１の計測を開始する。

次に、状態判断部１６１は、対応期限Ｔを過ぎているか否かを判断する（ステップＳ５４）。対応期限Ｔを過ぎていないと判断した場合、時間ｔ１内に通信部１７０が意思表示を受信したか否かを判断する（ステップＳ５６）。そして、時間ｔ１内に意思表示を受信した場合、意思表示を送信した管理者（対応者）の情報を内部に記憶する（ステップＳ５８）。さらに、タイムカウンター部１６３は、時間ｔ２の計測を始める。

続いて、状態判断部１６１は、対応期限Ｔを過ぎているか否かを判断する（ステップＳ６０）。対応期限Ｔを過ぎていないと判断した場合、ログ監視部１５０の監視結果により、時間ｔ２内にトラブルが発生したサービスの管理権限を持つ任意の管理者が、当該サービスのリソースへアクセスしたか否かを判断する（ステップＳ６２）。サービスの管理権限を持ついずれかの管理者からのアクセスが有ったと判断した場合、アラートへの対処に着手したとして、この管理者の情報を内部に記録して終了する（ステップＳ６４）。

なお、ステップＳ６２において、一定時間内にトラブルが発生したサービスの管理権限を持ついずれの管理者も該当リソースへアクセスしなかった場合、タイムカウンター部１６３は、時間ｔ２の計測をリセットする（ステップＳ６６）。そして、対応判断部１６２がエスカレーションを行うことを決定すると、送信先判断部１６４は、送信先記憶部１６５内のＡＰ−管理者対応リストを参照して見つけた次の通知先の管理者へアラートの通知を行う（ステップＳ６８）。さらに、タイムカウンター部１６３は、時間ｔ１の計測をリセットする。その後、公開サーバ１００は、ステップＳ５４からの処理を繰り返す。

また、ステップＳ５６において時間ｔ１内に意思表示を受信しなかった場合、公開サーバ１００は、エスカレーションにより次の管理者へアラートを通知し、時間ｔ１の計測をリセットするステップＳ６８からの処理を実行する。
また、ステップＳ５４またはステップＳ６０において、対応期限Ｔを過ぎたことを認識した場合、サービス縮退・停止実行部１６６は、アラートへの対応が取られなかったものとして、トラブルがあったサービスを縮退あるいは停止する（ステップＳ７０）。

図１１〜図１８は、アラートの通知のエスカレーションにおける動作例を示す。ここでは、一次管理者としての管理者Ａ、二次管理者としての上位管理者Ｃ、三次管理者としての最上位管理者Ｅの順に通知がエスカレーションするものとする。
図１１は、アラートの最初の通知先の管理者が時間ｔ１内に公開サーバ１００へ意思表示を行い、アラートへの対応を行った場合の例を示す。
公開サーバ１００は、サービスに障害が発生すると、一次管理者である管理者Ａの管理用端末２００へアラートを通知し、時間ｔ１及び対応期限Ｔの計測を始める。そして、時間ｔ１内に管理者Ａの管理用端末２００から意志表示を受信すると、時間ｔ２の計測を開始する。管理者Ａは、時間ｔ２内に管理用端末２００、あるいは、公開サーバ１００のコンソールから公開サーバ１００へログインし、障害への対応を行う。公開サーバ１００は、対応の開始待ちが完了したことを認識し、これ以上のアラートの通知やサービスの制限は行わない。

図１２は、アラートの最初の通知先の管理者が時間ｔ１内に意思表示を通知せず、上位管理者が意思表示を行い、アラートへの対応を行った場合の例を示す。
公開サーバ１００は、サービスに障害が発生すると、一次管理者である管理者Ａの管理用端末２００へアラートを通知し、時間ｔ１及び対応期限Ｔの計測を始める。公開サーバ１００が、時間ｔ１内に管理者Ａからの意思表示を受けなかったことを検出すると、二次管理者である上位管理者Ｃの管理用端末２００へアラートを通知し、時間ｔ１の計測をリセットする。そして、時間ｔ１内に上位管理者Ｃの管理用端末２００から意志表示を受信すると、時間ｔ２の計測を開始する。上位管理者Ｃは、時間ｔ２内に公開サーバ１００へログインし、障害への対応を行う。公開サーバ１００は、対応の開始待ちが完了したことを認識し、これ以上のアラートの通知やサービスの制限は行わない。

図１３は、アラートの最初の通知先の管理者及び上位管理者が時間ｔ１内に意思表示を通知せず、最上位管理者が意思表示を行い、アラートへの対応を行った場合の例を示す。
公開サーバ１００は、サービスに障害が発生すると、一次管理者である管理者Ａの管理用端末２００へアラートを通知し、時間ｔ１及び対応期限Ｔの計測を始める。公開サーバ１００が、時間ｔ１内に管理者Ａからの意思表示を受けなかったことを検出すると、二次管理者である上位管理者Ｃの管理用端末２００へアラートを通知し、時間ｔ１の計測をリセットする。さらに、公開サーバ１００が、時間ｔ１内に上位管理者Ｃからの意思表示を受けなかったことを検出すると、三次管理者である最上位管理者Ｅの管理用端末２００へアラートを通知し、時間ｔ１の計測をリセットする。公開サーバ１００は、時間ｔ１内に最上位管理者Ｅの管理用端末２００から意志表示を受信すると、時間ｔ２の計測を開始する。そして、最上位管理者Ｅは、時間ｔ２内に公開サーバ１００へログインし、障害への対応を行う。公開サーバ１００は、対応の開始待ちが完了したことを認識し、サービスの制限は行わない。

図１４は、アラートの最初の通知先の管理者が意思表示を通知したが、時間ｔ２内に対応せず、上位管理者が意思表示及びアラートへの対応を行った場合の例を示す。
公開サーバ１００は、サービスに障害が発生すると、一次管理者である管理者Ａの管理用端末２００へアラートを通知し、時間ｔ１及び対応期限Ｔの計測を始める。公開サーバ１００は、時間ｔ１内に管理者Ａの管理用端末２００から意志表示を受信すると、時間ｔ２の計測を開始する。そして、時間ｔ２内に管理者Ａが対応を行わなかったことを検出すると、二次管理者である上位管理者Ｃの管理用端末２００へアラートを通知し、時間ｔ１の計測をリセットする。公開サーバ１００は、時間ｔ１内に上位管理者Ｃの管理用端末２００から意思表示を受信すると、時間ｔ２の計測を開始する。上位管理者Ｃは、時間ｔ２内に公開サーバ１００へログインし、障害への対応を行う。公開サーバ１００は、対応の開始待ちが完了したことを認識し、これ以上のアラートの通知やサービスの制限は行わない。

図１５は、アラートの最初の通知先の管理者が意思表示を通知せず、上位管理者が意思表示を通知したが、時間ｔ２内に対応せず、最上位管理者が意思表示及びアラートへの対応を行った場合の例を示す。
公開サーバ１００は、サービスに障害が発生すると、一次管理者である管理者Ａの管理用端末２００へアラートを通知し、時間ｔ１及び対応期限Ｔの計測を始める。公開サーバ１００が、時間ｔ１内に管理者Ａからの意思表示を受けなかったことを検出すると、二次管理者である上位管理者Ｃの管理用端末２００へアラートを通知し、時間ｔ１の計測をリセットする。
公開サーバ１００は、時間ｔ１内に上位管理者Ｃの管理用端末２００から意志表示を受信すると、時間ｔ２の計測を開始する。そして、時間ｔ２内に上位管理者Ｃが対応を行わなかったことを検出すると、三次管理者である最上位管理者Ｅの管理用端末２００へアラートを通知し、時間ｔ１の計測をリセットする。
公開サーバ１００は、時間ｔ１内に最上位管理者Ｅの管理用端末２００から意思表示を受信すると、時間ｔ２の計測を開始する。最上位管理者Ｅは、時間ｔ２内に公開サーバ１００へログインし、障害への対応を行う。公開サーバ１００は、対応の開始待ちが完了したことを認識し、サービスの制限は行わない。

図１６は、アラートの最初の通知先の管理者が意思表示を行ったが、対応を行う前に上位管理者が対応を行った場合の例を示す。
公開サーバ１００は、サービスに障害が発生すると、一次管理者である管理者Ａの管理用端末２００へアラートを通知し、時間ｔ１及び対応期限Ｔの計測を始める。管理者Ａは、管理用端末２００から公開サーバ１００に対して、時間ｔ１内に意志表示を通知する。公開サーバ１００は、管理者Ａからの意思表示を受信すると、時間ｔ２の計測を開始する。
そして、管理者Ａが障害への対応を行う前の時間ｔ２内に、上位管理者Ｃが公開サーバ１００へログインし、障害への対応を行う。すると、公開サーバ１００は、管理者Ａの管理用端末２００へ対応が開始されたことを電子メールなどにより通知する。そして、公開サーバ１００は、対応の開始待ちが完了したことを認識し、これ以上のアラートの通知やサービスの制限は行わない。

図１７は、アラートの最初の通知先の管理者が時間ｔ１内に意思表示を通知せず、上位管理者が意思表示を行ったが、上位管理者が対応する前に管理者が対応を行った場合の例を示す。
公開サーバ１００は、サービスに障害が発生すると、一次管理者である管理者Ａの管理用端末２００へアラートを通知し、時間ｔ１及び対応期限Ｔの計測を始める。しかし、公開サーバ１００が、時間ｔ１内に管理者Ａからの意思表示を受けなかったことを検出すると、二次管理者である上位管理者Ｃの管理用端末２００へアラートを通知し、時間ｔ１の計測をリセットする。上位管理者Ｃは、時間ｔ１内に管理用端末２００から公開サーバ１００に対して意志表示を通知する。
公開サーバ１００は、上位管理者Ｃの管理用端末２００から意思表示を受信すると、時間ｔ２の計測を開始する。このとき、時間ｔ２内に、管理者Ａが公開サーバ１００へログインし、障害への対応を行う。公開サーバ１００は、管理者Ａが障害への対応を開始したことを認識すると、上位管理者Ｃの管理用端末２００へ対応が開始されたことを電子メールなどにより通知する。そして、対応の開始待ちが完了したことを認識し、これ以上のアラートの通知やサービスの制限は行わない。

図１８は、通知のエスカレーションを行っていたが、対応期限Ｔまでにいずれの管理者も対応を行えなかった場合の例を示す。
公開サーバ１００は、サービスに障害が発生すると、一次管理者である管理者Ａの管理用端末２００へアラートを通知し、時間ｔ１及び対応期限Ｔの計測を始める。公開サーバ１００は、時間ｔ１内に管理者Ａの管理用端末２００から意思表示を受信すると、時間ｔ２の計測を開始する。そして、時間ｔ２内に管理者Ａが対応を行わなかったことを検出すると、二次管理者である上位管理者Ｃの管理用端末２００へアラートを通知し、時間ｔ１の計測をリセットする。
公開サーバ１００は、時間ｔ１内に上位管理者Ｃの管理用端末２００から意思表示を受信すると、時間ｔ２の計測を開始する。そして、時間ｔ２内に上位管理者Ｃが対応を行わなかったことを検出すると、三次管理者である最上位管理者Ｅの管理用端末２００へアラートを通知し、時間ｔ１の計測をリセットする。公開サーバ１００は、時間ｔ１内に最上位管理者Ｅの管理用端末２００から意志表示を受信すると、時間ｔ２の計測を開始する。そして、最上位管理者Ｅが、公開サーバ１００へログインする前に対応期限Ｔが経過した場合、公開サーバ１００は、サービスの停止や減縮などの制限を行う。

上記実施の形態によれば、個々の管理者に対して、当該管理者が管理しているサービスに直接関連しない不正アクセスや障害対応などのトラブルについての不要なアラートを通知せずに済む。そのため、状況確認に係るコストが削減される。また、個々の管理者は、自分に届いた通知であれば、必ず自分の管理しているサービスに関したトラブルであると認識できるので、トラブルへの対応をスムーズに取ることが可能となる。
また、管理者が自身の管理するサービスに対してトラブルへの対応を行うことができない場合であっても、その上位の管理者に通知が転送されるため、トラブルへの対応を迅速に取ることが可能となる。
また、システム管理権限に基づいてアラートの通知先となる管理者の構造化を行っていくため、事前に管理体系などを設定しておく必要がなくなる。
また、トラブルへの対応が遅れた場合にはサービスの縮退を行うことにより、システムの安全性が向上する。

なお、上述の公開サーバ１００（アラート通知装置）は、内部にコンピュータシステムを有している。そして、上述した公開サーバ１００（アラート通知装置）の動作の過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータシステムが読み出して実行することによって、上記処理が行われる。ここでいうコンピュータシステムとは、ＯＳや周辺機器等のハードウェアを含むものである。

また、「コンピュータ読み取り可能な記録媒体」とは、ＲＯＭの他に、磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のシステムやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含むものとする。

また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。
また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。

本発明の一実施の形態によるアラート通知システムの全体構成を示す図である。 同実施の形態による公開サーバの内部構成を示すブロック図である。 同実施の形態による公開サーバにおける管理者構造の生成手順を示す図である。 同実施の形態による各管理者の管理権限の例を示す図である。 同実施の形態によるアラートの通知順位の例を示す図である。 同実施の形態による各管理者の権限の設定例を示す図である。 同実施の形態によるアラートの通知のエスカレーションにおける動作概要を説明するための図である。 同実施の形態によるアラートの通知のエスカレーションにおける動作概要を説明するための図である。 同実施の形態によるアラートの通知のエスカレーションにおける動作概要を説明するための図である。 同実施の形態による公開サーバの動作を示すフロー図である。 同実施の形態によるアラート通知のエスカレーションにおける動作例を示す図である。 同実施の形態によるアラート通知のエスカレーションにおける動作例を示す図である。 同実施の形態によるアラート通知のエスカレーションにおける動作例を示す図である。 同実施の形態によるアラート通知のエスカレーションにおける動作例を示す図である。 同実施の形態によるアラート通知のエスカレーションにおける動作例を示す図である。 同実施の形態によるアラート通知のエスカレーションにおける動作例を示す図である。 同実施の形態によるアラート通知のエスカレーションにおける動作例を示す図である。 同実施の形態によるアラート通知のエスカレーションにおける動作例を示す図である。

符号の説明

１００…公開サーバ
１１０…公開サービス提供部
１２０…内部サービス提供部
１３０…カーネル（ログ書込手段）
１４０…ログ記憶部
１５０…ログ監視部
１６０…状態・送信判断部
１６１…状態判断部
１６２…対応判断部
１６３…タイムカウンター部
１６４…送信先判断部
１６５…送信先記憶部
１６６…サービス縮退・停止実行部（アプリケーション提供制限手段）
１７０…通信部
１８０…リモート操作インターフェース部
１９０…ローカル操作インターフェース部
２００…管理用端末

Claims (5)

1. アプリケーションにアラートを通知すべき事象が発生したことを検出する検出手段と、
   前記検出手段がアプリケーションにアラートを通知すべき事象が発生したことを検出したときに該アプリケーションの管理者のうち所定の管理権限を有する管理者へアラートを通知するとともに、アラートを通知してから所定の時間内に該アプリケーションのいずれの管理者も発生した前記事象への対処を開始しない場合に直前にアラートを通知した管理者より広範囲な管理権限を有する管理者へアラートを通知することを繰り返す対応判断手段と、
   を備えることを特徴とするアラート通知装置。
2. 前記対応判断手段は、アラートを通知してから所定の時間内に通知先の管理者から該アラートへ対応する旨の意思表示の通知を受信しない場合に、該管理者より広範囲な管理権限を持つ管理者へアラートを通知する、
   ことを特徴とする請求項１に記載のアラート通知装置。
3. 前記アプリケーションにアラートを通知すべき事象が発生してから所定時間内に該アプリケーションのいずれの管理者も発生した前記事象への対処を開始しないときに、該アプリケーションの提供を制限するアプリケーション提供制限手段をさらに備える、
   ことを特徴とする請求項１または請求項２に記載のアラート通知装置。
4. アプリケーションの提供に用いられるリソースに対する各管理者の管理権限を基に、アプリケーションに関するアラート通知順序を決定する送信先判断手段をさらに備え、
   前記対応判断手段は、前記送信先判断手段が決定したアラート通知順序に従いアラートを通知すべき管理者を選択する、
   ことを特徴とする請求項１から請求項３のいずれかの項に記載のアラート通知装置。
5. 前記検出手段は、
   各アプリケーションの提供に用いられるリソースへのアクセスに関するログを記憶するログ記憶手段と、
   各アプリケーションの提供に用いられるリソースへのアクセスがあったときに前記ログ記憶手段にログを書き込むログ書込手段と、
   前記ログ記憶手段内のログを基に前記アプリケーションにアラートを通知すべき前記事象の発生あるいは管理者による前記事象への対処の開始を検出するログ監視手段とからなる、
   ことを特徴とする請求項１から請求項４のいずれかの項に記載のアラート通知装置。
   
   

Images