権限制御システム、権限制御方法及び権限制御プログラム
【課題】監視対象のシステムの稼動状況に応じて的確な権限制御を行なうための権限制御システム、権限制御方法及び権限制御プログラムを提供する。
【解決手段】監視サーバ２０の制御部２１は、監視対象システム１０から稼動情報を取得し、障害発生かどうかについて判定する。監視対象システム１０において障害発生と判定した場合、監視サーバ２０の制御部２１は、障害発生を通知する。障害発生通知を受信した動的権限管理サーバ５０の制御部５１は、障害発生サーバについて登録された作業担当者を特定する。そして、制御部５１は、認証管理サーバ３０に対して、特定されたユーザＩＤの有効化を指示する。その後、障害復旧通知を受信した動的権限管理サーバ５０の制御部５１は、認証管理サーバ３０に対して、障害発生サーバについて一時的に有効化したユーザＩＤの無効化を指示する。
【解決手段】監視サーバ２０の制御部２１は、監視対象システム１０から稼動情報を取得し、障害発生かどうかについて判定する。監視対象システム１０において障害発生と判定した場合、監視サーバ２０の制御部２１は、障害発生を通知する。障害発生通知を受信した動的権限管理サーバ５０の制御部５１は、障害発生サーバについて登録された作業担当者を特定する。そして、制御部５１は、認証管理サーバ３０に対して、特定されたユーザＩＤの有効化を指示する。その後、障害復旧通知を受信した動的権限管理サーバ５０の制御部５１は、認証管理サーバ３０に対して、障害発生サーバについて一時的に有効化したユーザＩＤの無効化を指示する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、監視対象のシステムの稼動状況に応じて的確な権限制御を行なうための権限制御システム、権限制御方法及び権限制御プログラムに関する。
【背景技術】
【０００２】
セキュリティ管理の観点からは、コンピュータの利用者（担当者）の役割に応じた最小限の特権を与えるとともに、強いアクセス権限（特権）を有するＩＤは必要な場合のみ使用を許可することが望ましい。
【０００３】
他方、システム統合基盤のように多数のサーバを管理する環境では、ユーザ管理を効率的に行なうため、ディレクトリサービスなどの認証システムが使われることがある。この認証システムには、担当者の役割に応じて静的な権限を有するユーザＩＤが設定されており、担当者はそのユーザＩＤを利用して、複数のサーバに対する作業を行なうことができる。
【０００４】
この場合、認証システム上のユーザＩＤは静的な状態で設定されているため、システムの稼動状況によっては、担当者に対して不必要に強いアクセス権限を許可してしまう可能性や、不必要なサーバへのアクセスを許可してしまう可能性がある。
【０００５】
例えば、システムに障害が発生した場合には復旧作業を行なう担当者に付与されるユーザＩＤには、システムに障害が発生した場合に備え、複数のサーバに対して設定変更を行なうことができる権限が予め付与されている。このため、システムの誤操作、不正行為、情報漏えい、データの改竄等が生じる可能性がある。
【０００６】
そこで、このような特権を有するユーザＩＤの使用は、運用上、申請・承認を経なければ許可しないこととする場合も多い。この場合、作業前に、作業担当者による作業内容の申請、運用管理担当者による作業内容の承認、オペレータによるユーザＩＤのパスワード変更等、事前作業が必要になる。従って、最小権限の原則に厳格に従うと、障害発生時に迅速な対応ができない可能性がある。
【０００７】
また、このような運用を行なった場合においても、貸与したユーザＩＤにより申請以外の作業が行われることをリアルタイムで完全に抑止することは困難である。従って、作業時のログと申請内容との突き合わせ等により、事後的に点検する必要があった。
【０００８】
そこで、静的に決定された権限による判定のみならず、その状況に応じた判定を行なうために、他システムとの連携を図る技術が検討されている（例えば、特許文献１を参照。）。この文献に記載された技術では、セキュアサーバ（アクセス権限判定装置）が、アクセスする主体が持つ属性をＤＢサーバに保持し、アクセスする主体の行動に応じて動的に変化する状態を監視する。そして、アプリケーション実行装置からアクセス権限判定要求を受信したときに指定されるアクセス権限判定条件を解釈し、属性および状態を参照してアクセスする主体が守るべき対象にアクセスする権限があるか否かを判定する。この判定結果を要求のあったアプリケーション実行装置に出力する。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００８−１３９９４０号公報（第１頁、図１３）
【発明の概要】
【発明が解決しようとする課題】
【００１０】
特許文献１に記載されているように、アクセスする主体の行動に応じて動的に権限を変更する場合においても、既存のシステムをできる限り有効活用することができれば、システム構築を効率的に行なうことができるので有意義である。
【００１１】
また、一つのユーザＩＤに対して、複数のサーバに対して同一の権限が設定されていることがある。このような場合には、本番の運用中の環境において、「管理者」権限を有する担当者が緊急作業の際、誤って作業対象でないシステムについて操作してしまう可能性がある。
【００１２】
更に、障害対応のように緊急作業が必要な場合には、その障害の影響を考慮して権限を付与する必要がある。
更に、障害対応時の操作ログは、どのような手順で対応したのかが分かる重要な情報であり、通常時の操作ログよりも詳細に記録することが望ましい。
【００１３】
本発明は、上記問題点を解決するためになされたものであり、監視対象のシステムの稼動状況に応じて的確な権限制御を行なうための権限制御システム、権限制御方法及び権限制御プログラムを提供することにある。
【課題を解決するための手段】
【００１４】
上記問題点を解決するために、請求項１に記載の発明は、監視対象装置の稼動状態を監視する監視システムと、監視対象装置について各担当者に付与可能なアクセス権限を管理する認証管理システムとに接続された制御手段を備えた権限制御システムであって、前記制御手段が、前記監視システムから、監視対象装置における障害状況に関する情報を取得した場合、前記認証管理システムに接続し、前記障害を検知した監視対象装置についてのアクセス権限を付与可能な担当者を特定する手段と、前記認証管理システムに対して、前記障害を検知した監視対象装置について、前記特定した担当者のアクセス権限を付与する指示を行なう権限付与手段と、前記監視システムから、前記障害を検知した監視対象装置の正常稼動に関する情報を取得した場合には、前記認証管理システムに対して、前記障害を検知した監視対象装置について付与したアクセス権限を取り消す指示を行なう権限取消手段とを備えたことを要旨とする。
【００１５】
請求項２に記載の発明は、請求項１に記載の権限制御システムにおいて、前記権限取消手段は、前記障害を検知した監視対象装置について付与したアクセス権限に関連付けられたすべての監視対象装置の正常稼動に関する情報を取得した場合に、前記認証管理システムに対して、前記監視対象装置について付与したアクセス権限を取り消す指示を行なうことを要旨とする。
【００１６】
請求項３に記載の発明は、請求項１又は２に記載の権限制御システムにおいて、監視対象装置に対して、この装置に関連する関連装置情報が登録された監視対象情報記憶手段を更に備え、前記権限付与手段は、前記監視対象情報記憶手段を用いて、障害を検知した監視対象装置の関連装置を特定し、前記認証管理システムにおいて、障害を検知した監視対象装置及び前記関連装置についてのアクセス権限を付与可能な担当者を特定し、前記認証管理システムに対して、前記特定した担当者のアクセス権限を付与する指示を行なうことを要旨とする。
【００１７】
請求項４に記載の発明は、請求項１〜３のいずれか一つに記載の権限制御システムにおいて、障害状況に対応させて権限レベルが登録された権限レベル情報記憶手段を更に備え、前記権限付与手段は、前記権限レベル情報記憶手段を用いて、検知した障害状況に応じ
た権限レベルを特定し、前記認証管理システムにおいて、この権限レベルのアクセス権限を付与する指示を行なうことを要旨とする。
【００１８】
請求項５に記載の発明は、監視対象装置の稼動状態を監視する監視システムと、監視対象装置について各担当者に付与可能なアクセス権限を管理する認証管理システムとに接続された制御手段を備えた権限制御システムを用いて権限制御を行なう方法であって、前記制御手段が、前記監視システムから、監視対象装置における障害状況を取得した場合、前記認証管理システムに接続し、前記障害を検知した監視対象装置についてのアクセス権限を付与可能な担当者を特定する段階と、前記認証管理システムに対して、前記障害を検知した監視対象装置について、前記特定した担当者のアクセス権限を付与する指示を行なう権限付与段階と、前記監視システムから、前記障害を検知した監視対象装置の正常稼動に関する情報を取得した場合には、前記認証管理システムに対して、前記障害を検知した監視対象装置について付与したアクセス権限を取り消す指示を行なう権限取消段階とを備えたことを要旨とする。
【００１９】
請求項６に記載の発明は、監視対象装置の稼動状態を監視する監視システムと、監視対象装置について各担当者に付与可能なアクセス権限を管理する認証管理システムとに接続された制御手段を備えた権限制御システムを用いて権限制御を行なうためのプログラムであって、前記制御手段を、前記監視システムから、監視対象装置における障害状況を取得した場合、前記認証管理システムに接続し、前記障害を検知した監視対象装置についてのアクセス権限を付与可能な担当者を特定する手段、前記認証管理システムに対して、前記障害を検知した監視対象装置について、前記特定した担当者のアクセス権限を付与する指示を行なう権限付与手段、前記監視システムから、前記障害を検知した監視対象装置の正常稼動に関する情報を取得した場合には、前記認証管理システムに対して、前記障害を検知した監視対象装置について付与したアクセス権限を取り消す指示を行なう権限取消手段として機能させることを要旨とする。
【００２０】
（作用）
請求項１、５又は６に記載の発明によれば、制御手段が、監視システムから、監視対象装置における障害状況を取得した場合、認証管理システムに接続し、障害を検知した監視対象装置についてのアクセス権限を付与可能な担当者を特定する。そして、認証管理システムに対して、障害を検知した監視対象装置について、特定した担当者のアクセス権限を付与する指示を行なう。また、監視システムから、障害を検知した監視対象装置の正常稼動に関する情報を取得した場合には、認証管理システムに対して、障害を検知した監視対象装置について付与したアクセス権限を取り消す指示を行なう。これにより、監視対象システムの稼動状況に応じた、きめ細かいアクセス制御を実現し、セキュリティの向上を実現することができる。また、システムの稼動状況に応じてアクセス権限の付与や取り消しが行なわれるので、障害等の緊急時に迅速な対応が可能になる。更に、開発担当者による申請以外の作業や、不正行為を防止することができる。
【００２１】
請求項２に記載の発明によれば、権限取消手段は、障害を検知した監視対象装置について付与したアクセス権限に関連付けられたすべての監視対象装置の正常稼動に関する情報を取得した場合に、認証管理システムに対して、障害を検知した監視対象装置について付与したアクセス権限を取り消す指示を行なう。これにより、複数の障害が連続的に発生し、一つの担当者識別子に対して、複数の監視対象装置のアクセス権限が設定されている環境下において、障害中の監視対象装置が存在しなくなるまで、同じ担当者識別子を利用して復旧作業を継続することができる。
【００２２】
請求項３に記載の発明によれば、権限付与手段は、監視対象情報記憶手段を用いて、障害を検知した監視対象装置の関連装置を特定する。そして、認証管理システムにおいて、
障害を検知した監視対象装置及び前記関連装置についてのアクセス権限を付与可能な担当者を特定し、前記認証管理システムに対して、前記特定した担当者のアクセス権限を付与する指示を行なう。これにより、一つの監視対象装置における障害によって影響を受ける他の監視対象装置の復旧作業を併せて行なうことができる。
【００２３】
請求項４に記載の発明によれば、権限付与手段は、権限レベル情報記憶手段を用いて、検知した障害状況に応じた権限レベルを特定する。そして、認証管理システムにおいて、この権限レベルのアクセス権限を付与する指示を行なう。これにより、アクセス権限のレベルを細分化した場合にも、的確なアクセス権限を付与することができる。
【発明の効果】
【００２４】
本発明によれば、監視対象のシステムの稼動状況に応じて的確な権限制御を行なうための権限制御システム、権限制御方法及び権限制御プログラムを提供することができる。
【図面の簡単な説明】
【００２５】
【図１】本発明の実施形態の権限管理システムの説明図。
【図２】本発明の実施形態の権限管理システムの機能ブロックの説明図。
【図３】本実施形態の処理において用いるデータの説明図であって、（ａ）は認証管理サーバが保持する権限管理テーブルに記録されたデータ、（ｂ）は動的権限管理サーバが保持する障害管理テーブルに記録されたデータの説明図。
【図４】本実施形態の処理手順の説明図であって、（ａ）は障害発生時処理、（ｂ）は障害復旧時処理の説明図。
【図５】本実施形態の処理において用いるデータの説明図であって、（ａ）は障害発生時の権限管理テーブルに記録されたデータ、（ｂ）は障害復旧時の権限管理テーブルに記録されたデータの説明図。
【図６】第２の実施形態の処理手順の説明図であって、（ａ）は障害発生時処理、（ｂ）は障害復旧時処理の説明図。
【図７】他の実施形態の処理手順の説明図であって、（ａ）は第３の実施形態、（ｂ）は第４の実施形態の処理手順の説明図。
【図８】第５の実施形態の処理手順の説明図であって、（ａ）は障害発生時処理、（ｂ）は障害復旧時処理の説明図。
【図９】第６の実施形態の障害発生時処理の説明図。
【図１０】他の実施形態におけるログイン処理の説明図。
【図１１】認証管理サーバが保持する権限管理テーブルに記録されたデータの説明図。
【発明を実施するための形態】
【００２６】
＜第１の実施形態＞
以下、本発明を具体化した権限管理システムの一実施形態を図１〜図５に従って説明する。本実施形態では、各種サービスを提供するためのシステム（監視対象装置）の稼動状態を監視し、この稼動状態に応じて、作業担当者のユーザＩＤのアカウント状態を変更することによりアクセス権限の権限制御を行なう。ここでは、図１に示すように、監視対象システム１０、監視サーバ２０、認証管理サーバ３０、クライアント端末４０、動的権限管理サーバ５０を用いる。そして、各種サービスを提供するためのシステムである監視対象システム１０において障害が発生した場合には、動的権限管理サーバ５０が、認証管理サーバ３０における監視対象システム１０のアクセス権限を動的に変更する。
【００２７】
監視対象システム１０は、サービスを提供するためのコンピュータシステムであり、各サービス提供システムに共通的な情報処理を実行したり、システム基盤の運用上必要となる処理を実行したりする共用システムＺや、各サービス提供に必要な処理を個別に実行す
るサービス提供システム（Ａ，Ｂ，Ｃ）が含まれる。
【００２８】
更に、本実施形態では、各監視対象システム１０は、複数のサーバ１１により構築されている。例えば、共用システムＺはサーバ（ｚ１〜ｚ３）から構成されている。同様に、サービス提供システム（Ａ）はサーバ（ａ１〜ａ３）、サービス提供システム（Ｂ）はサーバ（ｂ１〜ｂ３）、サービス提供システム（Ｃ）はサーバ（ｃ１〜ｃ３）から構成されている。
【００２９】
そして、監視対象システム１０において障害が発生した場合には、稼動情報として、発生したエラーに関する情報を蓄積しておく。このエラーに関する情報には、障害が発生したサーバ１１の識別子（サーバＩＤ）や障害内容を含める。
【００３０】
監視サーバ２０は、ネットワークを介して、各監視対象システム１０の稼動状況を監視する既存のコンピュータシステム（監視システム）である。この監視サーバ２０は、制御部２１、担当者管理データベース２２、障害履歴データベース２３を備えている。制御部２１は、制御手段（ＣＰＵ、ＲＡＭ、ＲＯＭ等）を備え、後述する処理（障害監視段階、障害通知段階、障害復旧段階等の各処理等）を行なう。そのための監視プログラムを実行することにより、制御部２１は、図２に示すように、障害監視手段２１１、障害発生通知手段２１２、障害復旧通知手段２１３として機能する。
【００３１】
障害監視手段２１１は、監視対象システム１０の稼働状況を監視し、障害発生を検知する処理を実行する。本実施形態では、障害監視手段２１１が、監視対象システム１０を構成する各サーバ１１に、順次、アクセスし、各サーバ１１の稼働情報を取得する。なお、障害発生の検知方法はこれに限定されるものではない。例えば、障害発生時に、監視対象システム１０が、障害監視手段２１１に対して障害発生を通知するような構成を利用してもよい。
【００３２】
障害発生通知手段２１２は、障害の発生を検知した場合、各システムの運用管理担当者や動的権限管理サーバ５０に障害発生を通知する処理を実行する。
障害復旧通知手段２１３は、障害が解消し、システムが回復した場合に、動的権限管理サーバ５０に障害復旧を通知する処理を実行する。
【００３３】
担当者管理データベース２２には、監視対象システム１０に障害が発生した場合に、障害が発生した監視対象システム１０の復旧作業を指示する運用管理担当者に対して通知を送信するための連絡先テーブルが記録されている。この連絡先テーブルは、各監視対象システム１０の運用管理担当者が決定された際に予め登録される。この連絡先テーブルには、監視対象の各サーバ１１のサーバＩＤに関連付けられて、運用管理担当者の連絡先が記録されている。
【００３４】
障害履歴データベース２３には、監視対象システム１０において発生した障害の障害履歴レコードが記録される。この障害履歴レコードは、障害が発生した場合に生成されて登録される。障害履歴レコードには、障害が発生したサーバ１１の識別子（サーバＩＤ）、障害内容、障害発生日時、障害復旧日時を含める。
【００３５】
認証管理サーバ３０は、作業担当者等が監視対象システム１０にアクセスする場合に、権限を認証するための既存のコンピュータシステム（認証管理システム）である。この認証管理サーバ３０は、制御部３１、権限管理データベース３２を備えている。制御部３１は、制御手段（ＣＰＵ、ＲＡＭ、ＲＯＭ等）を備える。この制御部３１は、監視対象システム１０を構成するサーバ１１に対するログイン要求を取得し、ログイン要求に含まれるユーザＩＤ及びパスワードを取得する。そして、制御部３１は、取得したユーザＩＤ及び
パスワードと、権限管理データベース３２に登録されたユーザＩＤ及びパスワードとを照合することにより、アクセス者の認証を行なう。そして、アクセス者の認証ができた場合には、権限管理データベース３２により特定されるアクセス権限情報に基づき、各監視対象システム１０を構成する各サーバ１１へのアクセスを許可する。
【００３６】
権限管理データベース３２はアクセス権限情報記憶手段として機能する。この権限管理データベース３２には、図３（ａ）に示すように、アクセス者を認証し、アクセス権限を特定するための権限管理テーブル３２０が記録されている。この権限管理テーブル３２０は、各担当者の役割に応じて決定されたアクセス権限が登録された場合に記録される。権限管理テーブル３２０は、担当者毎に、グループＩＤ、ユーザＩＤ、パスワード、アクセス許可ホスト、アカウント状態に関する権限管理レコードが記録されている。
【００３７】
グループＩＤデータ領域には、このユーザＩＤが属するグループを特定するための識別子に関するデータが記録されている。本実施形態では、各ユーザＩＤが属するグループによりアクセス権限を特定することができる。ここでは、「管理者」、「運用参照」、「運用オペ」のグループが設定されている。「管理者」は、特権ＩＤと同様に強い権限が付与されたグループであり、各サーバ１１の設定変更を行なうことができる権限が付与される。本実施形態では、サーバ１１において発生した障害の復旧作業を行なう場合には、この「管理者」権限が必要になる。「運用参照」は、システムの稼動状態を確認するために最小限の権限が付与されたグループである。「運用オペ」は、システム運用のために、手順書等に基づき一定の範囲内のオペレーション作業を行なうために最小限の権限が付与されたグループである。
【００３８】
ユーザＩＤ、パスワードの各データ領域には、それぞれ各担当者を特定するための識別子、本人を認証するためのパスワードに関するデータが記録されている。
アクセス許可ホストデータ領域には、このユーザＩＤによりアクセス可能なサーバ１１を特定するための識別子（サーバＩＤ）に関するデータが記録されている。本実施形態では、一つのユーザＩＤに対して、複数のアクセス許可ホストを設定することができる。この場合には、アクセス許可ホストデータ領域に、この担当者が担当するすべてのサーバＩＤを登録する。
【００３９】
アカウント状態データ領域には、この権限の有効性を判定するためのフラグに関するデータが記録される。本実施形態では、「有効」フラグ又は「無効」フラグのいずれかが記録される。このアカウント状態において「有効」フラグが記録されている場合のみ、アクセス権限が付与されていることになり、制御部３１は、ユーザＩＤを用いてのアクセスを許容する。本実施形態においては、「運用参照」や「運用オペ」のグループに属するユーザＩＤについては、常時、有効フラグが記録されている。一方、「管理者」のグループに属するユーザＩＤについては、平常時は「無効」フラグが記録されており、動的権限管理サーバ５０からの指示に基づき「有効」フラグに変更される。更に、付与されたアクセス権限は、動的権限管理サーバ５０からの指示に基づいて「無効」フラグに変更されることにより、アクセス権限が取り消される。
【００４０】
クライアント端末４０は、各監視対象システム１０の担当者が利用するコンピュータ端末である。本実施形態においては、各担当者は、このクライアント端末４０を用いて、各監視対象システム１０にログインして、アクセス権限により許容された範囲での操作を行なうことができる。このクライアント端末４０は、制御部、キーボードやポインティングデバイスからなる入力部、ディスプレイ等からなる表示部等を備えている。
【００４１】
動的権限管理サーバ５０は、各監視対象システム１０の稼動状況に応じて、作業担当者のユーザＩＤのアカウント状態を変更するコンピュータシステムである。この動的権限管
理サーバ５０は、制御部５１、障害管理データベース５２を備えている。制御部５１は、制御手段（ＣＰＵ、ＲＡＭ、ＲＯＭ等）を備え、後述する処理（担当者特定段階、権限付与段階、権限取消段階等の各処理等）を行なう。そのための権限管理プログラムを実行することにより、制御部５１は、図２に示すように、担当者特定手段５１１、権限設定手段５１２として機能する。
【００４２】
担当者特定手段５１１は、障害が発生したサーバ１１について復旧作業を行なう作業担当者を特定する処理を実行する。
権限設定手段５１２は、権限付与手段及び権限取消手段として機能し、認証管理サーバ３０において設定されているユーザＩＤのアカウント状態の変更を指示する処理を実行する。このために、権限設定手段５１２には、認証管理サーバ３０に登録されたユーザＩＤのアカウント状態を変更する権限が設定されている。更に、権限設定手段５１２は、復旧作業のためにアカウント状態を変更した作業担当者のユーザＩＤを仮記憶する変更情報記憶手段を備えている。この変更情報記憶手段には、本来設定されているアカウント状態から変更（本実施形態では「無効」から「有効」に変更）を加えたユーザＩＤ及び、障害対応を行なう対象サーバＩＤを含めた障害対応レコードが記録される。
【００４３】
障害管理データベース５２は監視対象情報記憶手段として機能する。この障害管理データベース５２には、監視対象システム１０の各サーバ１１において発生する可能性がある障害を登録した障害管理テーブル５２０が記録されている。この障害管理テーブル５２０は、各管理システムにおいて発生する可能性がある障害を予め登録する。障害管理テーブル５２０は、対象システム、対象サーバ、障害内容、グループＩＤに関するデータを含んで構成されている。
【００４４】
対象システム、対象サーバの各データ領域には、監視対象のシステムやサーバを特定するための識別子（システムＩＤやサーバＩＤ）に関するデータが記録される。
障害内容データ領域には、各サーバにおいて発生する可能性がある障害の内容に関するデータが記録されている。
グループＩＤデータ領域には、発生した障害の復旧作業を行なうために必要な権限を有するグループを特定するための識別子に関するデータが記録されている。
【００４５】
次に、この権限管理システムにおける動作を、図４を用いて説明する。ここでは、図４（ａ）に示す障害発生時処理、図４（ｂ）に示す障害復旧時処理の順番に説明する。
【００４６】
（障害発生時処理）
まず、図４（ａ）を用いて障害発生時処理を説明する。
ここでは、監視サーバ２０の制御部２１は、稼動情報の取得処理を実行する（ステップＳ１−１）。具体的には、制御部２１の障害監視手段２１１は、ネットワークを介して、監視対象システム１０を構成する各サーバ１１に、順次、アクセスし、各サーバ１１の稼働情報を取得する。
【００４７】
次に、監視サーバ２０の制御部２１は、障害発生かどうかについての判定処理を実行する（ステップＳ１−２）。具体的には、制御部２１の障害監視手段２１１は、各サーバ１１から取得した稼動情報において、エラーメッセージが含まれているかどうかにより、障害発生を判定する。
【００４８】
稼動情報にエラーメッセージが含まれておらず、障害発生を検知しない場合（ステップＳ１−２において「ＮＯ」の場合）、稼動情報の取得処理（ステップＳ１−１）を継続する。
【００４９】
一方、稼動情報にエラーメッセージが含まれており、障害発生と判定した場合（ステップＳ１−２において「ＹＥＳ」の場合）、監視サーバ２０の制御部２１は、障害発生通知処理を実行する（ステップＳ１−３）。具体的には、制御部２１の障害監視手段２１１は、障害が発生したサーバ１１の識別子（サーバＩＤ）、障害内容、障害発生日時を記録した障害履歴レコードを生成し、障害履歴データベース２３に登録する。更に、制御部５１の障害発生通知手段２１２は、動的権限管理サーバ５０に対して障害発生通知を送信する。この障害発生通知には、障害が発生した監視対象システム１０、サーバ１１及び障害内容に関する情報を含める。本実施形態においては、サーバａ１において「ｘｘｘプロセス停止」の障害が発生した場合を想定する。この場合には、サーバａ１についての復旧作業が必要になる。
【００５０】
更に、障害発生通知手段２１２は、担当者管理データベース２２を用いて、運用管理担当者の中から、障害が発生したサーバ１１の復旧作業を指示する運用管理担当者を特定する。そして、障害発生通知手段２１２は、この運用管理担当者の連絡先に対して、障害発生通知を送信する。障害発生通知を受信した運用管理担当者は、作業担当者に対して復旧作業を指示する。
【００５１】
障害発生通知を受信した動的権限管理サーバ５０の制御部５１は、障害発生サーバについて登録されたユーザＩＤの特定処理を実行する（ステップＳ１−４）。具体的には、制御部５１の担当者特定手段５１１は、認証管理サーバ３０にアクセスする。そして、権限管理データベース３２において、障害が発生した監視対象システム１０について、障害の復旧に必要なグループＩＤに属し、アクセス許可ホストデータ領域に障害が発生したサーバＩＤが登録されたユーザＩＤを検索する。本実施形態では、図３（ａ）において、グループＩＤ「管理者」に属し、アクセス許可ホストとしてサーバａ１が登録されたユーザＩＤとして「ｄｅｖ０１」、「ｄｅｖ０２」、「ｄｅｖ０４」を特定する。
【００５２】
次に、動的権限管理サーバ５０の制御部５１は、ユーザＩＤの有効化処理を実行する（ステップＳ１−５）。具体的には、制御部５１の権限設定手段５１２は、認証管理サーバ３０に対して、ステップＳ１−４において特定したユーザＩＤのアカウント状態の有効化を指示する。本実施形態では、図５（ａ）に示すように、各ユーザＩＤ「ｄｅｖ０１」、「ｄｅｖ０２」、「ｄｅｖ０４」のアカウント状態を「有効」にするための指示を認証管理サーバ３０に送信する。この指示を受信した認証管理サーバ３０は、各ユーザＩＤについてのアカウント状態データ領域に「有効」フラグを記録する。これにより、担当者「ａａａ」、「ｂｂｂ」、「ｄｄｄ」は、サーバａ１に、「管理者」の権限でアクセス可能になる。更に、権限設定手段５１２は、この障害に対応して有効化した作業担当者のユーザＩＤ、対象サーバＩＤを設定した障害対応レコードを変更情報記憶手段に仮記憶する。
【００５３】
（障害復旧時処理）
次に、図４（ｂ）を用いて障害復旧時処理を説明する。
ここでは、監視サーバ２０の制御部２１は、障害復旧情報の取得処理を実行する（ステップＳ２−１）。具体的には、制御部２１の障害監視手段２１１は、各サーバ１１の稼働情報を取得する。作業担当者による復旧作業により、サーバ１１が復旧した場合には、障害監視手段２１１は、障害発生サーバの正常稼働情報を取得する。そして、障害発生サーバを含む監視対象システム１０の復旧を確認した作業担当者は、監視サーバ２０において障害復旧情報を入力する。障害復旧情報を取得した制御部２１の障害監視手段２１１は、障害履歴データベース２３において、障害が復旧した監視対象システム１０のサーバ１１の識別子（サーバＩＤ）が記録された障害履歴レコードに障害復旧日時を記録する。
【００５４】
次に、監視サーバ２０の制御部２１は、障害復旧通知処理を実行する（ステップＳ２−２）。具体的には、制御部２１の障害復旧通知手段２１３は、動的権限管理サーバ５０に
対して障害復旧通知を送信する。この障害復旧通知には、障害が回復した監視対象システム１０、サーバ１１及び障害内容に関する情報を含める。本実施形態では、障害が発生していたサーバａ１が含まれるシステム（Ａ）が復旧した場合を想定する。
【００５５】
障害復旧通知を受信した動的権限管理サーバ５０の制御部５１は、障害発生サーバにおいて一時的に有効化したユーザＩＤの特定処理を実行する（ステップＳ２−３）。具体的には、制御部５１の担当者特定手段５１１は、障害発生時に有効化したユーザＩＤを変更情報記憶手段から取得する。本実施形態では、ユーザＩＤ「ｄｅｖ０１」、「ｄｅｖ０２」、「ｄｅｖ０４」を変更情報記憶手段から取得する。
【００５６】
次に、動的権限管理サーバ５０の制御部５１は、ユーザＩＤの無効化処理を実行する（ステップＳ２−４）。具体的には、制御部５１の権限設定手段５１２は、認証管理サーバ３０に対して、特定したユーザＩＤのアカウント状態の無効化を指示する。ここでは、権限管理テーブル３２０において、ユーザＩＤに関連付けられているすべてのサーバ１１の障害が復旧している場合のみ、アカウント状態を「無効」にするための指示を認証管理サーバ３０に送信する。この指示を受信した認証管理サーバ３０は、各ユーザＩＤについてのアカウント状態データ領域に「無効」フラグを記録する。一方、権限管理テーブル３２０において、障害が継続している他のサーバ１１に関連付けられているユーザＩＤについては、アカウント状態を「無効」にするための指示を送信しない。この結果、認証管理サーバ３０において、アカウント状態データ領域の「有効」フラグが維持される。本実施形態では、他の監視対象システム１０については障害が発生しておらず、図５（ｂ）に示すように、ユーザＩＤ「ｄｅｖ０１」、「ｄｅｖ０２」、「ｄｅｖ０４」のアカウント状態が「無効」になる。更に、権限設定手段５１２は、変更情報記憶手段に仮記憶されたユーザＩＤ、対象サーバＩＤを含む障害対応レコードを削除する。
【００５７】
以上、本実施形態によれば、以下に示す効果を得ることができる。
（１）上記実施形態では、障害発生と判定した場合（ステップＳ１−２において「ＹＥＳ」の場合）、監視サーバ２０の制御部２１は、障害発生通知処理を実行する（ステップＳ１−３）。障害発生通知を受信した動的権限管理サーバ５０の制御部５１は、障害発生サーバについて登録された担当者の特定処理（ステップＳ１−４）、この担当者のユーザＩＤの有効化処理（ステップＳ１−５）を実行する。これにより、障害が発生した場合、グループＩＤ「管理者」に属し、障害が発生したサーバ１１にアクセスが許可されたユーザＩＤのみが有効化される。従って、障害対応が必要な場合には、平常時には無効化されているユーザＩＤを用いて、効率的に復旧作業を行なうことができる。この場合、制御部５１の権限設定手段５１２は、認証管理サーバ３０に対して、特定した作業担当者において、グループＩＤ「管理者」に属するユーザＩＤのアカウント状態の有効化を指示する。従って、既存の認証管理サーバ３０による認証管理方法や設定情報を用いて、アクセス管理を行なうことができる。
【００５８】
（２）上記実施形態では、監視サーバ２０の制御部２１は、障害復旧情報を取得した場合（ステップＳ２−１）、障害復旧通知処理（ステップＳ２−２）を実行する。障害復旧通知を受信した動的権限管理サーバ５０の制御部５１は、障害発生サーバにおいて一時的に有効化したユーザＩＤの特定処理（ステップＳ２−３）、このユーザＩＤの無効化処理（ステップＳ２−４）を実行する。これにより、平常時等のように高いアクセス権限が必要でない場合には無効化しておくことにより、不必要に高い権限でのアクセスを抑制できる。従って、誤操作を抑制し、セキュリティを向上させることができる。
【００５９】
＜第２の実施形態＞
次に、本発明を具体化した第２の実施形態を図６に従って説明する。第１の実施形態においては、障害が発生したサーバ１１についてアクセスが許可され、グループＩＤ「管理
者」に属するすべての作業担当者のユーザＩＤを有効化した。第２の実施形態は、第１の実施形態の障害発生時処理において、一つのユーザＩＤに対して、複数のサーバ１１や監視対象システム１０のアクセス権限が設定されている環境において、障害が発生したサーバやシステムについてのアクセス権限のみを有効化する構成であり、同様の部分については詳細な説明を省略する。
【００６０】
この実施形態においては、変更情報記憶手段に、認証管理サーバ３０の権限管理データベース３２において変更を加える前の内容を記録する。具体的には、本来のアカウント状態を変更したユーザＩＤについて、本来の権限管理レコードの内容（グループＩＤ、ユーザＩＤ、アクセス許可ホスト、アカウント状態）を記録する。
【００６１】
以下、図６（ａ）に示す障害発生時処理、図６（ｂ）に示す障害復旧時処理の順番に説明する。
（障害発生時処理）
まず、図６（ａ）を用いて障害発生時処理を説明する。
【００６２】
ここでは、監視サーバ２０の制御部２１は、ステップＳ１−１と同様に、稼動情報の取得処理を実行する（ステップＳ３−１）。
次に、監視サーバ２０の制御部２１は、ステップＳ１−２と同様に、障害発生かどうかについての判定処理を実行する（ステップＳ３−２）。障害発生を検知しない場合（ステップＳ３−２において「ＮＯ」の場合）、稼動情報の取得処理（ステップＳ３−１）を継続する。
【００６３】
一方、障害発生と判定した場合（ステップＳ３−２において「ＹＥＳ」の場合）、監視サーバ２０の制御部２１は、ステップＳ１−３と同様に、障害発生通知処理を実行する（ステップＳ３−３）。
【００６４】
障害発生通知を受信した動的権限管理サーバ５０の制御部５１は、ステップＳ１−４と同様に、障害発生サーバについて登録されたＩＤであって、グループＩＤ「管理者」に属するユーザＩＤの特定処理を実行する（ステップＳ３−４）。具体的には、権限設定手段５１２は、権限管理データベース３２において、グループＩＤ「管理者」に属するとともに、アクセス許可ホストに障害発生サーバを含み、アカウント状態として「無効」が登録されたユーザＩＤを検索する。また、権限設定手段５１２は、変更情報記憶手段において、アクセス許可ホストに障害発生サーバを含み、グループＩＤ「管理者」に属するユーザＩＤを検索する。
【００６５】
次に、動的権限管理サーバ５０の制御部５１は、ユーザＩＤの有効化処理を実行する（ステップＳ３−５）。具体的には、制御部５１の権限設定手段５１２は、認証管理サーバ３０に対して、ステップＳ３−４において特定したユーザＩＤのアカウント状態の有効化を指示する。更に、権限設定手段５１２は、この障害に対応して有効化した作業担当者の権限管理レコードを変更情報記憶手段に仮記憶する。
【００６６】
一方、変更情報記憶手段において、グループＩＤ「管理者」に属するユーザＩＤが記録されている場合には、権限設定手段５１２は、障害が発生したサーバやシステムに対するグループＩＤ「管理者」への追加登録申請を行なう。ここでは、認証管理サーバ３０に対して、サーバＩＤをアクセス許可ホストとして記録するための追加登録申請を送信する。例えば、サーバ「ａ１」において障害が発生した場合、復旧作業を行なう作業担当者のユーザＩＤ「ｄｅｖ０１」を特定する。ここで、権限管理データベース３２において、ユーザＩＤ「ｄｅｖ０１」のアクセス許可ホストとして「ｂ１」のみが記録されている場合は、権限設定手段５１２は、「ａ１」についての追加登録申請を送信する。
【００６７】
次に、動的権限管理サーバ５０の制御部５１は、障害が発生していないサーバについてのアクセス権限の無効化処理を実行する（ステップＳ３−６）。具体的には、制御部５１の権限設定手段５１２は、認証管理サーバ３０において、アカウント状態を有効化したユーザＩＤの権限管理レコードに、障害が発生していないサーバ１１がアクセス許可ホストとして記録されているかどうかを確認する。ここで、ユーザＩＤに対して、障害が発生していないシステムやサーバがアクセス許可ホストとして記録されている場合には、権限設定手段５１２は、認証管理サーバ３０に対して、障害が発生していないシステムやサーバについての権限抹消申請を送信する。例えば、サーバ「ａ１」において障害が発生した場合、復旧作業を行なう作業担当者のユーザＩＤ「ｄｅｖ０１」を特定する。ここで、ユーザＩＤ「ｄｅｖ０１」のアクセス許可ホストとして「ａ１，ａ２，ａ３，ｂ１，ｂ２，ｂ３，ｚ１，ｚ２，ｚ３」が記録されている場合は、権限設定手段５１２は、「ａ２，ａ３，ｂ１，ｂ２，ｂ３，ｚ１，ｚ２，ｚ３」についての権限抹消申請を送信する。
【００６８】
（障害復旧時処理）
次に、図６（ｂ）を用いて障害復旧時処理を説明する。
ここでは、監視サーバ２０の制御部２１は、ステップＳ２−１と同様に、障害復旧情報の取得処理を実行する（ステップＳ４−１）。
【００６９】
次に、監視サーバ２０の制御部２１は、ステップＳ２−２と同様に、障害復旧通知処理を実行する（ステップＳ４−２）。
障害復旧通知を受信した動的権限管理サーバ５０の制御部５１は、ステップＳ２−３と同様に、障害発生サーバにおいて一時的に有効化したユーザＩＤの特定処理を実行する（ステップＳ４−３）。
【００７０】
次に、動的権限管理サーバ５０の制御部５１は、ユーザＩＤの無効化処理を実行する（ステップＳ４−４）。具体的には、制御部５１の権限設定手段５１２は、認証管理サーバ３０に対して、特定したユーザＩＤに関連付けられたアクセス許可ホストとして記録されているサーバＩＤを取得する。そして、権限設定手段５１２は、障害復旧情報に含まれていないサーバ１１が残っているかどうかを確認する。他に復旧していないシステムやサーバが残っているユーザＩＤについては、権限設定手段５１２は、認証管理サーバ３０に対して、復旧したシステムのサーバ１１についての権限抹消申請を送信する。一方、すべてのシステムやサーバが復旧したユーザＩＤについては、変更情報記憶手段に保持していた権限管理レコードの内容に基づいて、認証管理サーバ３０に対して、アカウント状態を「無効」にした状態での登録申請を送信する。
【００７１】
以上、本実施形態によれば、以下に示す効果を得ることができる。
（３）上記実施形態では、動的権限管理サーバ５０の制御部５１は、障害が発生していないサーバについてのアクセス権限の無効化処理を実行する（ステップＳ３−６）。ここでは、権限設定手段５１２は、認証管理サーバ３０に対して、障害が発生していないシステムやサーバについての権限抹消申請を送信することにより、一旦、権限管理データベース３２から削除する。これにより、ユーザＩＤを、障害発生により復旧作業が必要なサーバのみにアクセスが許可された状態に設定することができる。従って、必要以上のシステムやサーバへのアクセスを抑制することにより、よりセキュリティを向上させることができる。
【００７２】
＜第３の実施形態＞
次に、本発明を具体化した第３の実施形態を図７（ａ）に従って説明する。第１の実施形態においては、障害が発生した監視対象システム１０について、グループＩＤ「管理者」に属するすべての作業担当者のユーザＩＤを有効化した。第３の実施形態は、第１の実
施形態の障害発生時処理において、有効化するユーザＩＤを作業担当者の勤怠状況に基づいて特定する構成であり、同様の部分については詳細な説明を省略する。本実施形態においては、作業担当者毎に勤怠状況を管理する勤怠管理システムを設ける。この勤怠管理システムにおいては、ユーザＩＤに対して、勤怠状況（出勤状況や出勤予定）が登録されている。
【００７３】
（障害発生時処理）
図７（ａ）を用いて障害発生時処理を説明する。
ここでは、監視サーバ２０の制御部２１は、ステップＳ１−１と同様に、稼動情報の取得処理を実行する（ステップＳ５−１）。
【００７４】
次に、監視サーバ２０の制御部２１は、ステップＳ１−２と同様に、障害発生かどうかについての判定処理を実行する（ステップＳ５−２）。障害発生を検知しない場合（ステップＳ５−２において「ＮＯ」の場合）、稼動情報の取得処理（ステップＳ５−１）を継続する。
【００７５】
一方、障害発生と判定した場合（ステップＳ５−２において「ＹＥＳ」の場合）、監視サーバ２０の制御部２１は、ステップＳ１−３と同様に、障害発生通知処理を実行する（ステップＳ５−３）。
【００７６】
障害発生通知を受信した動的権限管理サーバ５０の制御部５１は、ステップＳ１−４と同様に、障害発生サーバについて登録されたＩＤであって、グループＩＤ「管理者」に属するユーザＩＤの特定処理を実行する（ステップＳ５−４）。
【００７７】
次に、動的権限管理サーバ５０の制御部５１は、作業担当者の勤怠状況の確認処理を実行する（ステップＳ５−５）。具体的には、制御部５１の担当者特定手段５１１は、勤怠管理システムにアクセスし、特定したユーザＩＤに関連付けられた勤怠状況を取得する。そして、担当者特定手段５１１は、出勤している作業担当者、又は基準時間内に出勤予定の作業担当者のユーザＩＤを抽出する。
【００７８】
次に、動的権限管理サーバ５０の制御部５１は、ユーザＩＤの有効化処理を実行する（ステップＳ５−６）。具体的には、制御部５１の権限設定手段５１２は、認証管理サーバ３０に対して、勤怠管理システムを用いて抽出した作業担当者のユーザＩＤについてアカウント状態の有効化を指示する。更に、権限設定手段５１２は、この障害に対応して有効化した作業担当者のユーザＩＤ、対象サーバＩＤを設定した障害対応レコードを変更情報記憶手段に仮記憶する。
【００７９】
以上、本実施形態によれば、以下に示す効果を得ることができる。
（４）上記実施形態では、動的権限管理サーバ５０の制御部５１は、特定した担当者の勤怠状況の確認処理を実行する（ステップＳ５−５）。そして、動的権限管理サーバ５０の制御部５１は、ユーザＩＤの有効化処理を実行する（ステップＳ５−６）。これにより、社内にいない場合や、出勤予定がない場合等により障害に対応できない作業担当者のユーザＩＤを「無効」のまま維持することができる。従って、不必要なアクセス権限の設定を抑制し、セキュリティを向上させることができる。
【００８０】
＜第４の実施形態＞
次に、本発明を具体化した第４の実施形態を図７（ｂ）に従って説明する。第１の実施形態においては、障害が発生した監視対象システム１０を構成するサーバ１１について、グループＩＤ「管理者」に属する作業担当者のユーザＩＤを有効化した。第４の実施形態は、第１の実施形態の障害発生時処理において、有効化するユーザＩＤを復旧作業に必要
な権限レベルを考慮して特定する構成であり、同様の部分については詳細な説明を省略する。本実施形態においては、認証管理サーバ３０において、「管理者」のアクセス権限を細分化するとともに、これに対応させて異なる権限レベルのグループＩＤが設定されている場合を想定する。また、動的権限管理サーバ５０の制御部５１には、障害状況に対応させて、細分化された「管理者」のアクセス権限の中で、復旧作業に必要な権限レベルを登録した権限レベルテーブル（権限レベル情報記憶手段）を保持させておく。そして、障害状況に応じて、復旧作業に必要な最低限の権限レベル以上のアクセス権限が設定されたグループＩＤを有するユーザＩＤのみについてアカウント状態を有効化する。
【００８１】
（障害発生時処理）
図７（ｂ）を用いて障害発生時処理を説明する。
ここでは、監視サーバ２０の制御部２１は、ステップＳ１−１と同様に、稼動情報の取得処理を実行する（ステップＳ６−１）。
【００８２】
次に、監視サーバ２０の制御部２１は、ステップＳ１−２と同様に、障害発生かどうかについての判定処理を実行する（ステップＳ６−２）。障害発生を検知しない場合（ステップＳ６−２において「ＮＯ」の場合）、稼動情報の取得処理（ステップＳ６−１）を継続する。
【００８３】
一方、障害発生と判定した場合（ステップＳ６−２において「ＹＥＳ」の場合）、監視サーバ２０の制御部２１は、ステップＳ１−３と同様に、障害発生通知処理を実行する（ステップＳ６−３）。
【００８４】
障害発生通知を受信した動的権限管理サーバ５０の制御部５１は、復旧作業に必要なアクセス権限の特定処理を実行する（ステップＳ６−４）。具体的には、制御部５１の担当者特定手段５１１は、権限レベルテーブルから、障害発生通知に含まれる障害状況に対応した権限レベルを特定する。ここでは、復旧作業において必要最低限の権限レベルが特定される。
【００８５】
次に、動的権限管理サーバ５０の制御部５１は、障害発生サーバについて登録されたユーザＩＤの特定処理を実行する（ステップＳ６−５）。具体的には、ステップＳ１−４と同様に、制御部５１の担当者特定手段５１１は、認証管理サーバ３０にアクセスする。そして、担当者特定手段５１１は、権限管理テーブル３２０において、ステップＳ６−４で特定した権限レベル以上のアクセス権限に対応するグループＩＤに属し、アクセス許可ホストに障害が発生したサーバＩＤに関連付けられたユーザＩＤを検索する。
【００８６】
次に、動的権限管理サーバ５０の制御部５１は、ユーザＩＤの有効化処理を実行する（ステップＳ６−６）。具体的には、制御部５１の権限設定手段５１２は、認証管理サーバ３０に対して、権限レベルテーブルを用いて抽出したグループＩＤに属するユーザＩＤについてアカウント状態の有効化を指示する。更に、権限設定手段５１２は、この障害に対応して有効化した作業担当者のユーザＩＤ、対象サーバＩＤを設定した障害対応レコードを変更情報記憶手段に仮記憶する。
【００８７】
以上、本実施形態によれば、以下に示す効果を得ることができる。
（５）上記実施形態では、動的権限管理サーバ５０の制御部５１は、復旧作業に必要なアクセス権限の特定処理を実行する（ステップＳ６−５）。これにより、アクセス権限を細分化して登録している環境では、障害状況に応じて最低限必要な作業担当者のユーザＩＤを有効化することができる。
【００８８】
＜第５の実施形態＞
次に、本発明を具体化した第５の実施形態を図８に従って説明する。第１の実施形態においては、障害が発生した監視対象システム１０について、グループＩＤ「管理者」に属する作業担当者のユーザＩＤを有効化した。第５の実施形態は、第１の実施形態の障害発生時処理、障害復旧時処理において、障害の影響を受ける他のサーバ１１を考慮してユーザＩＤを有効化する構成であり、同様の部分については詳細な説明を省略する。本実施形態においては、障害が発生した監視対象システム１０だけではなく、この障害の影響を受ける他の監視対象システム１０についても作業担当者のユーザＩＤを有効化する。この場合には、監視対象情報記憶手段として、障害管理テーブル５２０に影響先情報を記録しておく。この影響先情報には、所定のサーバ１１において障害が発生した場合、この障害の影響が及ぶ他のサーバ１１（関連装置）を特定するための識別子（サーバＩＤ）が記録されている。本実施形態においては、一つの障害により複数のサーバに影響を与える場合には、影響を受けるすべてのサーバ１１の識別子が記録される。
【００８９】
以下、図８（ａ）に示す障害発生時処理、図８（ｂ）に示す障害復旧時処理の順番に説明する。
（障害発生時処理）
まず、図８（ａ）を用いて障害発生時処理を説明する。
【００９０】
ここでは、監視サーバ２０の制御部２１は、ステップＳ１−１と同様に、稼動情報の取得処理を実行する（ステップＳ７−１）。
次に、監視サーバ２０の制御部２１は、ステップＳ１−２と同様に、障害発生かどうかについての判定処理を実行する（ステップＳ７−２）。障害発生を検知しない場合（ステップＳ７−２において「ＮＯ」の場合）、稼動情報の取得処理（ステップＳ７−１）を継続する。
【００９１】
一方、障害発生と判定した場合（ステップＳ７−２において「ＹＥＳ」の場合）、監視サーバ２０の制御部２１は、ステップＳ１−３と同様に、障害発生通知処理を実行する（ステップＳ７−３）。
【００９２】
障害発生通知を受信した動的権限管理サーバ５０の制御部５１は、障害発生サーバの関連サーバの特定処理を実行する（ステップＳ７−４）。具体的には、制御部５１の担当者特定手段５１１は、障害管理データベース５２に記録された障害管理テーブル５２０から、障害発生サーバの障害状況に応じて、影響を受けるすべてのサーバ１１を特定する。これにより、障害発生サーバだけではなく、関連サーバも特定することができる。
【００９３】
次に、動的権限管理サーバ５０の制御部５１は、障害発生サーバ、関連サーバについて登録されたユーザＩＤの特定処理を実行する（ステップＳ７−５）。具体的には、制御部５１の担当者特定手段５１１は、認証管理サーバ３０にアクセスし、権限管理データベース３２において、障害発生サーバ及び影響先として特定した関連サーバについてグループＩＤ「管理者」に属するユーザＩＤを検索する。
【００９４】
次に、動的権限管理サーバ５０の制御部５１は、障害発生サーバ、関連サーバについて登録された担当者のユーザＩＤの有効化処理を実行する（ステップＳ７−６）。具体的には、制御部５１の権限設定手段５１２は、認証管理サーバ３０に対して、抽出した作業担当者において、グループＩＤ「管理者」に属するユーザＩＤについて、アカウント状態の有効化を指示する。更に、権限設定手段５１２は、この障害に対応して有効化した作業担当者のユーザＩＤ、対象サーバＩＤを設定した障害対応レコードを変更情報記憶手段に仮記憶する。
【００９５】
（障害復旧時処理）
次に、図８（ｂ）を用いて障害復旧時処理を説明する。
監視サーバ２０の制御部２１は、ステップＳ２−１と同様に、障害復旧情報の取得処理を実行する（ステップＳ８−１）。
【００９６】
次に、監視サーバ２０の制御部２１は、ステップＳ２−２と同様に、障害復旧通知処理を実行する（ステップＳ８−２）。
障害復旧通知を受信した動的権限管理サーバ５０の制御部５１は、障害発生サーバ、関連サーバにおいて一時的に許可したユーザＩＤの特定処理を実行する（ステップＳ８−３）。具体的には、制御部５１の担当者特定手段５１１は、障害発生時に有効化したユーザＩＤを変更情報記憶手段から取得する。
【００９７】
次に、動的権限管理サーバ５０の制御部５１は、ユーザＩＤの無効化処理を実行する（ステップＳ８−４）。具体的には、制御部５１の権限設定手段５１２は、権限管理データベース３２において、特定したユーザＩＤのアカウント状態の無効化を指示する。ここでは、権限管理テーブル３２０において、特定のユーザＩＤのすべての対象システムの障害が復旧している場合にアカウント状態データ領域に「無効」フラグを記録する。一方、権限管理テーブル３２０において、障害が継続している他のサーバ１１に対するアクセス権限のグループＩＤ「管理者」に属するユーザＩＤについては、アカウント状態データ領域の「有効」フラグを維持する。
【００９８】
以上、本実施形態によれば、以下に示す効果を得ることができる。
（６）上記実施形態では、動的権限管理サーバ５０の制御部５１は、障害発生サーバの関連サーバの特定処理（ステップＳ７−４）、障害発生サーバ、関連サーバについて登録されたユーザＩＤの特定処理（ステップＳ７−５）、ユーザＩＤの有効化処理（ステップＳ７−６）を実行する。これにより、一つのサーバ１１において発生した障害の影響を考慮して、的確な作業担当者にアクセス権限を設定することができる。
【００９９】
＜第６の実施形態＞
次に、本発明を具体化した第６の実施形態を図９に従って説明する。第１の実施形態においては、障害が発生した監視対象システム１０について、グループＩＤ「管理者」に属する作業担当者のユーザＩＤを有効化した。第６の実施形態は、第１の実施形態の障害発生時処理において、アクセス権限を付与するために、一時的な新たなＩＤを設定する構成であり、同様の部分については詳細な説明を省略する。本実施形態においては、障害が発生した監視対象システム１０について、一時的に有効化した仮ユーザＩＤを設定する。このために、動的権限管理サーバ５０の制御部５１に認証支援手段を設ける。この認証支援手段には、仮ユーザＩＤテーブルを保持させる。この仮ユーザＩＤテーブルには、使用可能な仮ユーザＩＤ、仮パスワードが記録されている。そして、障害発生時には、仮ユーザＩＤテーブルにおいて、作業担当者に対して仮ユーザＩＤを設定するとともに、この仮ユーザＩＤに対して、本来のユーザＩＤを関連付けて記録する。
【０１００】
更に、作業担当者の操作ログを蓄積するログ管理システムを設ける。このログ管理システムは、仮ユーザＩＤによるログインを検知した場合、この作業担当者の操作入力内容を取得し、操作日時に関連付けて蓄積する。
【０１０１】
（障害発生時処理）
まず、図９を用いて障害発生時処理を説明する。
ここでは、監視サーバ２０の制御部２１は、ステップＳ１−１と同様に、稼動情報の取得処理を実行する（ステップＳ９−１）。
【０１０２】
次に、監視サーバ２０の制御部２１は、ステップＳ１−２と同様に、障害発生かどうか
についての判定処理を実行する（ステップＳ９−２）。障害発生を検知しない場合（ステップＳ９−２において「ＮＯ」の場合）、稼動情報の取得処理（ステップＳ９−１）を継続する。
【０１０３】
一方、障害発生と判定した場合（ステップＳ９−２において「ＹＥＳ」の場合）、監視サーバ２０の制御部２１は、ステップＳ１−３と同様に、障害発生通知処理を実行する（ステップＳ９−３）。
【０１０４】
障害発生通知を受信した動的権限管理サーバ５０の制御部５１は、ステップＳ１−４と同様に、障害発生サーバについて登録された担当者の特定処理を実行する（ステップＳ９−４）。
【０１０５】
次に、動的権限管理サーバ５０の制御部５１は、障害発生サーバについて登録された担当者に対してアクセス権限を付与するための仮ユーザＩＤの設定処理を実行する（ステップＳ９−５）。具体的には、制御部５１の担当者特定手段５１１は、仮ユーザＩＤテーブルから、使用可能な仮ユーザＩＤを取得する。ここでは、仮ユーザＩＤテーブルにおいて、本来のユーザＩＤが関連付けられていない仮ユーザＩＤを取得する。この場合、担当者特定手段５１１は、特定した作業担当者の人数分の仮ユーザＩＤを取得する。そして、担当者特定手段５１１は、仮ユーザＩＤテーブルにおいて、仮ユーザＩＤに関連付けて、本来のユーザＩＤを記録する。更に、担当者特定手段５１１は、認証管理サーバ３０に対して、仮ユーザＩＤの登録申請を送信する。この登録申請においては、グループＩＤ「管理者」において仮ユーザＩＤ、仮パスワード、障害発生サーバのサーバＩＤを含める。登録申請を受信した認証管理サーバ３０は、権限管理データベース３２に仮ユーザＩＤを登録する。これにより、仮ユーザＩＤにおいて、障害発生サーバに対する「管理者」のアクセス権限が付与される。
【０１０６】
次に、動的権限管理サーバ５０の制御部５１は、仮ユーザＩＤの通知処理を実行する（ステップＳ９−６）。具体的には、制御部５１の担当者特定手段５１１は、障害が発生した監視対象システム１０の運用管理担当者に対して、新たに設定した仮ユーザＩＤ及び仮パスワードを通知する。この場合、運用管理担当者は、動的権限管理サーバ５０から取得した仮ユーザＩＤ及び仮パスワードを、作業担当者に対して通知して、復旧作業の実行を指示する。
【０１０７】
（ログイン処理）
作業担当者は、通知された仮ユーザＩＤ及び仮パスワードを用いて、各サーバ１１にアクセスして復旧作業を行なう。この場合、ログ管理システムは、仮ユーザＩＤにおける操作ログの記録処理を実行する。具体的には、ログ管理システムは、クライアント端末４０において、仮ユーザＩＤを用いてログインした作業担当者の操作入力内容を取得し、操作日時に関連付けて蓄積する。
【０１０８】
（障害復旧時処理）
障害復旧時処理においては、監視サーバ２０の制御部２１において、ステップＳ２−１〜Ｓ２−２と同様に、障害復旧情報の取得処理、障害復旧通知処理を実行する。
【０１０９】
そして、障害復旧通知を受信した動的権限管理サーバ５０の制御部５１は、ステップＳ２−３と同様に、障害発生サーバにおいて一時的に許可した仮ユーザＩＤの特定処理を実行する。
【０１１０】
そして、ステップＳ２−４と同様に、仮ユーザＩＤの無効化処理を実行する。この場合、動的権限管理サーバ５０の制御部５１は、認証管理サーバ３０に対して、仮ユーザＩＤ
の抹消申請を送信する。更に、制御部５１は、仮ユーザＩＤテーブルにおいて、仮ユーザＩＤに関連付けて記録されたユーザＩＤを削除する。
【０１１１】
以上、本実施形態によれば、以下に示す効果を得ることができる。
（７）上記実施形態では、動的権限管理サーバ５０の制御部５１は、障害発生サーバについて登録された担当者に対してアクセス権限を付与するための仮ユーザＩＤの設定処理を実行する（ステップＳ９−５）。そして、ログ管理システムは、仮ユーザＩＤにおける操作ログの記録処理を実行する。これにより、通常のユーザＩＤの設定情報を変更することなく、障害対応に必要な権限をもつユーザＩＤの作成をすることができる。また、一時的に付与された仮ユーザＩＤにおける操作内容を記録することができる。そして、この作業担当者が復旧作業時に行なった操作情報を蓄積し、障害対応について情報共有を行なうことができる。
【０１１２】
なお、上記実施形態は、以下の態様に変更してもよい。
・ 上記第５の実施形態では、障害管理テーブル５２０において、影響先情報を予め登録しておく。この影響先情報は、復旧作業を行なう作業担当者の操作ログに基づいて、更新するようにしてもよい。この場合には、復旧作業を行なった作業担当者がアクセスしたシステムやサーバの情報を蓄積し、障害内容に関連付けて、これらのシステムやサーバ情報を影響先として登録する。これにより、復旧作業実績に基づいて、必要な影響先を設定することができる。
【０１１３】
・ 上記第６の実施形態では、動的権限管理サーバ５０の制御部５１は、仮ユーザＩＤの通知処理を実行する（ステップＳ９−６）。これに代えて、作業担当者自身のユーザＩＤを用いてログインできるようにしてもよい。この場合にも、障害発生通知を受信した動的権限管理サーバ５０の制御部５１は、ステップＳ１−４と同様に、障害発生サーバについて登録された担当者の特定処理を実行する（ステップＳ９−４）。次に、動的権限管理サーバ５０の制御部５１は、障害発生サーバについて登録された担当者に対してアクセス権限を付与するための仮ユーザＩＤの設定処理を実行する（ステップＳ９−５）。そして、動的権限管理サーバ５０の制御部５１は、仮ユーザＩＤの通知処理（ステップＳ９−６）に代えて、仮パスワードの通知処理を実行する。
【０１１４】
次に、図１０を用いてログイン処理を説明する。
運用管理担当者より仮パスワードの通知を受けた作業担当者が、各サーバ１１にアクセスする場合には、自分のユーザＩＤ及び通知された仮パスワードを用いる。
【０１１５】
そして、動的権限管理サーバ５０の制御部５１は、ログイン要求の取得処理を実行する（ステップＳ１０−１）。具体的には、制御部５１の認証支援手段は、サーバ１１から、ユーザＩＤ及び仮パスワードを含めたログイン要求を取得する。
【０１１６】
次に、動的権限管理サーバ５０の制御部５１は、仮ユーザＩＤの登録があるかどうかについての判定処理を実行する（ステップＳ１０−２）。具体的には、制御部５１の認証支援手段は、仮ユーザＩＤテーブルにおいて、ログイン要求に含まれるユーザＩＤを検索する。
【０１１７】
仮ユーザＩＤテーブルにユーザＩＤが登録されており、仮ユーザＩＤが設定されている場合（ステップＳ１０−２において「ＹＥＳ」の場合）、動的権限管理サーバ５０の制御部５１は、仮ユーザＩＤによる認証要求処理を実行する（ステップＳ１０−３）。具体的には、制御部５１の認証支援手段は、ログイン要求に含まれるユーザＩＤを、仮ユーザＩＤテーブルに記録されている仮ユーザＩＤに読み替える。そして、認証支援手段は、仮ユーザＩＤ及び仮パスワードを含めたログイン要求を認証管理サーバ３０に転送する。この
場合には、認証管理サーバ３０の制御部３１は、読み替えられたユーザＩＤ及び仮パスワードによりログイン認証を行なう。ログイン認証を完了した場合、認証管理サーバ３０は、仮ユーザＩＤの権限により、サーバ１１へのアクセスを許可する。この場合も、ログ管理システムは、仮ユーザＩＤにおける操作ログの記録処理を実行する。
【０１１８】
一方、仮ユーザＩＤテーブルにユーザＩＤが登録されておらず、仮ユーザＩＤが設定されていない場合（ステップＳ１０−２において「ＮＯ」の場合）、動的権限管理サーバ５０の制御部５１は、通常の認証要求処理を実行する（ステップＳ１０−４）。具体的には、制御部５１の認証支援手段は、サーバ１１から取得したユーザＩＤ及びパスワードを含めたログイン要求を認証管理サーバ３０に転送する。この場合、認証管理サーバ３０の制御部３１は、転送されたユーザＩＤ及びパスワードによりログイン認証を行なう。ここでも、ログイン認証を完了した場合、認証管理サーバ３０は、ユーザＩＤの権限により、サーバ１１へのアクセスを許可する。なお、「無効化」されているユーザＩＤの場合には、アクセスは許可されないことになる。
【０１１９】
・ 上記各実施形態において、複数の実施形態を組み合わせて、本発明の権限制御システムを構成するようにしてもよい。
また、上記各実施形態において、監視サーバ２０、認証管理サーバ３０、動的権限管理サーバ５０等を用いて、アクセス権限を管理したが、このアクセス権限を管理するためのハードウェア構成は、上述の構成に限定されるものではない。例えば、認証管理サーバ３０と動的権限管理サーバ５０を、同一のコンピュータシステム内の機能として動作させてもよい。
【０１２０】
・ 上記各実施形態では、障害が発生したサーバ１１毎に、グループＩＤ「管理者」に属するユーザＩＤを有効化する。有効化の範囲はサーバ１１に限定されるものではない。例えば、障害が発生した監視対象システム１０毎に、アクセス権限を有効化するようにしてもよい。
【０１２１】
・ 上記各実施形態では、障害発生通知を受信した動的権限管理サーバ５０の制御部５１は、障害発生サーバについて登録された担当者の特定処理を実行する（ステップＳ１−４）。具体的には、制御部５１の担当者特定手段５１１は、認証管理サーバ３０にアクセスし、権限管理データベース３２において、障害が発生した監視対象システム１０についてグループＩＤ「管理者」に属するユーザＩＤを検索する。この場合、ユーザＩＤを検索するデータベースは、認証管理サーバ３０内の権限管理データベース３２に限定されるものではない。例えば、権限管理データベース３２と同じデータベースを動的権限管理サーバ５０内に設けておき、このデータベースを用いて、ユーザＩＤを検索するようにしてもよい。
【０１２２】
・ 上記各実施形態では、障害復旧時処理により、ユーザＩＤのアカウント状態を無効化して復元する。ユーザＩＤのアカウント状態の復元は、システムの復旧時に限定されるものではない。例えば、システムやサーバが復旧してから基準時間経過後に、ユーザＩＤのアカウント状態を無効化するようにしてもよい。障害復旧後に、再度、サーバやシステムにログインして稼動状態を確認する場合もある。この場合にも所定期間においては、ユーザＩＤを利用してアクセスすることができる。
【０１２３】
・ 上記各実施形態では、障害発生時にユーザＩＤを有効化するとともに、障害復旧時に無効化する場合を説明した。ユーザＩＤの有効化や無効化は、障害時に限定されるものではない。例えば、システム開発の状況に応じて、ユーザＩＤを有効化や無効化するようにしてもよい。具体的には、システム管理サーバから、「開発中」、「本番運用中」等のフェーズ情報を取得する。そして、「開発中」フェーズにおいては、グループＩＤ「開発
担当者」に属するユーザＩＤを有効化するとともに、グループＩＤ「運用担当者」に属するユーザＩＤを無効化する。一方、「本番運用中」フェーズにおいては、グループＩＤ「開発担当者」に属するユーザＩＤを無効化するとともに、グループＩＤ「運用担当者」に属するユーザＩＤを有効化する。
【０１２４】
・ 上記各実施形態では、監視対象システム１０を構成するサーバ１１についてのアクセス権限を動的に制御したが、制御対象はこれらに限定されるものではない。例えば、ネットワーク機器やストレージ装置についてのアクセス権限を制御するようにしてもよい。
【０１２５】
・ 上記各実施形態では、権限管理データベース３２に記録されている権限管理テーブル３２０により、有効化するユーザＩＤを特定する。この権限管理テーブル３２０は、担当者毎に、グループＩＤ、ユーザＩＤ、パスワード、アクセス許可ホスト、アカウント状態に関する権限管理レコードが記録されている。アクセス権限を特定するためのデータ構造は、これに限定されるものではない。例えば、図１１に示すように、グループ管理テーブル３２５、ユーザＩＤ管理テーブル３２６を用いることも可能である。このグループ管理テーブル３２５には、グループＩＤに対して、このグループに属するユーザＩＤが登録されている。また、ユーザＩＤ管理テーブル３２６には、ユーザＩＤに対して、アクセス許可ホスト情報が登録されている。そして、「管理者」権限が付与されたグループに属するユーザＩＤを検索することで、アカウント状態を変更するユーザＩＤを特定することができる。
【符号の説明】
【０１２６】
１０…監視対象システム、２０…監視サーバ、２１…制御部、２１１…障害監視手段、２１２…障害発生通知手段、２１３…障害復旧通知手段、２２…担当者管理データベース、２３…障害履歴データベース、３０…認証管理サーバ、３１…制御部、３２…権限管理データベース、４０…クライアント端末、５０…動的権限管理サーバ、５１…制御部、５１１…担当者特定手段、５１２…権限設定手段、５２…障害管理データベース。
【技術分野】
【０００１】
本発明は、監視対象のシステムの稼動状況に応じて的確な権限制御を行なうための権限制御システム、権限制御方法及び権限制御プログラムに関する。
【背景技術】
【０００２】
セキュリティ管理の観点からは、コンピュータの利用者（担当者）の役割に応じた最小限の特権を与えるとともに、強いアクセス権限（特権）を有するＩＤは必要な場合のみ使用を許可することが望ましい。
【０００３】
他方、システム統合基盤のように多数のサーバを管理する環境では、ユーザ管理を効率的に行なうため、ディレクトリサービスなどの認証システムが使われることがある。この認証システムには、担当者の役割に応じて静的な権限を有するユーザＩＤが設定されており、担当者はそのユーザＩＤを利用して、複数のサーバに対する作業を行なうことができる。
【０００４】
この場合、認証システム上のユーザＩＤは静的な状態で設定されているため、システムの稼動状況によっては、担当者に対して不必要に強いアクセス権限を許可してしまう可能性や、不必要なサーバへのアクセスを許可してしまう可能性がある。
【０００５】
例えば、システムに障害が発生した場合には復旧作業を行なう担当者に付与されるユーザＩＤには、システムに障害が発生した場合に備え、複数のサーバに対して設定変更を行なうことができる権限が予め付与されている。このため、システムの誤操作、不正行為、情報漏えい、データの改竄等が生じる可能性がある。
【０００６】
そこで、このような特権を有するユーザＩＤの使用は、運用上、申請・承認を経なければ許可しないこととする場合も多い。この場合、作業前に、作業担当者による作業内容の申請、運用管理担当者による作業内容の承認、オペレータによるユーザＩＤのパスワード変更等、事前作業が必要になる。従って、最小権限の原則に厳格に従うと、障害発生時に迅速な対応ができない可能性がある。
【０００７】
また、このような運用を行なった場合においても、貸与したユーザＩＤにより申請以外の作業が行われることをリアルタイムで完全に抑止することは困難である。従って、作業時のログと申請内容との突き合わせ等により、事後的に点検する必要があった。
【０００８】
そこで、静的に決定された権限による判定のみならず、その状況に応じた判定を行なうために、他システムとの連携を図る技術が検討されている（例えば、特許文献１を参照。）。この文献に記載された技術では、セキュアサーバ（アクセス権限判定装置）が、アクセスする主体が持つ属性をＤＢサーバに保持し、アクセスする主体の行動に応じて動的に変化する状態を監視する。そして、アプリケーション実行装置からアクセス権限判定要求を受信したときに指定されるアクセス権限判定条件を解釈し、属性および状態を参照してアクセスする主体が守るべき対象にアクセスする権限があるか否かを判定する。この判定結果を要求のあったアプリケーション実行装置に出力する。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００８−１３９９４０号公報（第１頁、図１３）
【発明の概要】
【発明が解決しようとする課題】
【００１０】
特許文献１に記載されているように、アクセスする主体の行動に応じて動的に権限を変更する場合においても、既存のシステムをできる限り有効活用することができれば、システム構築を効率的に行なうことができるので有意義である。
【００１１】
また、一つのユーザＩＤに対して、複数のサーバに対して同一の権限が設定されていることがある。このような場合には、本番の運用中の環境において、「管理者」権限を有する担当者が緊急作業の際、誤って作業対象でないシステムについて操作してしまう可能性がある。
【００１２】
更に、障害対応のように緊急作業が必要な場合には、その障害の影響を考慮して権限を付与する必要がある。
更に、障害対応時の操作ログは、どのような手順で対応したのかが分かる重要な情報であり、通常時の操作ログよりも詳細に記録することが望ましい。
【００１３】
本発明は、上記問題点を解決するためになされたものであり、監視対象のシステムの稼動状況に応じて的確な権限制御を行なうための権限制御システム、権限制御方法及び権限制御プログラムを提供することにある。
【課題を解決するための手段】
【００１４】
上記問題点を解決するために、請求項１に記載の発明は、監視対象装置の稼動状態を監視する監視システムと、監視対象装置について各担当者に付与可能なアクセス権限を管理する認証管理システムとに接続された制御手段を備えた権限制御システムであって、前記制御手段が、前記監視システムから、監視対象装置における障害状況に関する情報を取得した場合、前記認証管理システムに接続し、前記障害を検知した監視対象装置についてのアクセス権限を付与可能な担当者を特定する手段と、前記認証管理システムに対して、前記障害を検知した監視対象装置について、前記特定した担当者のアクセス権限を付与する指示を行なう権限付与手段と、前記監視システムから、前記障害を検知した監視対象装置の正常稼動に関する情報を取得した場合には、前記認証管理システムに対して、前記障害を検知した監視対象装置について付与したアクセス権限を取り消す指示を行なう権限取消手段とを備えたことを要旨とする。
【００１５】
請求項２に記載の発明は、請求項１に記載の権限制御システムにおいて、前記権限取消手段は、前記障害を検知した監視対象装置について付与したアクセス権限に関連付けられたすべての監視対象装置の正常稼動に関する情報を取得した場合に、前記認証管理システムに対して、前記監視対象装置について付与したアクセス権限を取り消す指示を行なうことを要旨とする。
【００１６】
請求項３に記載の発明は、請求項１又は２に記載の権限制御システムにおいて、監視対象装置に対して、この装置に関連する関連装置情報が登録された監視対象情報記憶手段を更に備え、前記権限付与手段は、前記監視対象情報記憶手段を用いて、障害を検知した監視対象装置の関連装置を特定し、前記認証管理システムにおいて、障害を検知した監視対象装置及び前記関連装置についてのアクセス権限を付与可能な担当者を特定し、前記認証管理システムに対して、前記特定した担当者のアクセス権限を付与する指示を行なうことを要旨とする。
【００１７】
請求項４に記載の発明は、請求項１〜３のいずれか一つに記載の権限制御システムにおいて、障害状況に対応させて権限レベルが登録された権限レベル情報記憶手段を更に備え、前記権限付与手段は、前記権限レベル情報記憶手段を用いて、検知した障害状況に応じ
た権限レベルを特定し、前記認証管理システムにおいて、この権限レベルのアクセス権限を付与する指示を行なうことを要旨とする。
【００１８】
請求項５に記載の発明は、監視対象装置の稼動状態を監視する監視システムと、監視対象装置について各担当者に付与可能なアクセス権限を管理する認証管理システムとに接続された制御手段を備えた権限制御システムを用いて権限制御を行なう方法であって、前記制御手段が、前記監視システムから、監視対象装置における障害状況を取得した場合、前記認証管理システムに接続し、前記障害を検知した監視対象装置についてのアクセス権限を付与可能な担当者を特定する段階と、前記認証管理システムに対して、前記障害を検知した監視対象装置について、前記特定した担当者のアクセス権限を付与する指示を行なう権限付与段階と、前記監視システムから、前記障害を検知した監視対象装置の正常稼動に関する情報を取得した場合には、前記認証管理システムに対して、前記障害を検知した監視対象装置について付与したアクセス権限を取り消す指示を行なう権限取消段階とを備えたことを要旨とする。
【００１９】
請求項６に記載の発明は、監視対象装置の稼動状態を監視する監視システムと、監視対象装置について各担当者に付与可能なアクセス権限を管理する認証管理システムとに接続された制御手段を備えた権限制御システムを用いて権限制御を行なうためのプログラムであって、前記制御手段を、前記監視システムから、監視対象装置における障害状況を取得した場合、前記認証管理システムに接続し、前記障害を検知した監視対象装置についてのアクセス権限を付与可能な担当者を特定する手段、前記認証管理システムに対して、前記障害を検知した監視対象装置について、前記特定した担当者のアクセス権限を付与する指示を行なう権限付与手段、前記監視システムから、前記障害を検知した監視対象装置の正常稼動に関する情報を取得した場合には、前記認証管理システムに対して、前記障害を検知した監視対象装置について付与したアクセス権限を取り消す指示を行なう権限取消手段として機能させることを要旨とする。
【００２０】
（作用）
請求項１、５又は６に記載の発明によれば、制御手段が、監視システムから、監視対象装置における障害状況を取得した場合、認証管理システムに接続し、障害を検知した監視対象装置についてのアクセス権限を付与可能な担当者を特定する。そして、認証管理システムに対して、障害を検知した監視対象装置について、特定した担当者のアクセス権限を付与する指示を行なう。また、監視システムから、障害を検知した監視対象装置の正常稼動に関する情報を取得した場合には、認証管理システムに対して、障害を検知した監視対象装置について付与したアクセス権限を取り消す指示を行なう。これにより、監視対象システムの稼動状況に応じた、きめ細かいアクセス制御を実現し、セキュリティの向上を実現することができる。また、システムの稼動状況に応じてアクセス権限の付与や取り消しが行なわれるので、障害等の緊急時に迅速な対応が可能になる。更に、開発担当者による申請以外の作業や、不正行為を防止することができる。
【００２１】
請求項２に記載の発明によれば、権限取消手段は、障害を検知した監視対象装置について付与したアクセス権限に関連付けられたすべての監視対象装置の正常稼動に関する情報を取得した場合に、認証管理システムに対して、障害を検知した監視対象装置について付与したアクセス権限を取り消す指示を行なう。これにより、複数の障害が連続的に発生し、一つの担当者識別子に対して、複数の監視対象装置のアクセス権限が設定されている環境下において、障害中の監視対象装置が存在しなくなるまで、同じ担当者識別子を利用して復旧作業を継続することができる。
【００２２】
請求項３に記載の発明によれば、権限付与手段は、監視対象情報記憶手段を用いて、障害を検知した監視対象装置の関連装置を特定する。そして、認証管理システムにおいて、
障害を検知した監視対象装置及び前記関連装置についてのアクセス権限を付与可能な担当者を特定し、前記認証管理システムに対して、前記特定した担当者のアクセス権限を付与する指示を行なう。これにより、一つの監視対象装置における障害によって影響を受ける他の監視対象装置の復旧作業を併せて行なうことができる。
【００２３】
請求項４に記載の発明によれば、権限付与手段は、権限レベル情報記憶手段を用いて、検知した障害状況に応じた権限レベルを特定する。そして、認証管理システムにおいて、この権限レベルのアクセス権限を付与する指示を行なう。これにより、アクセス権限のレベルを細分化した場合にも、的確なアクセス権限を付与することができる。
【発明の効果】
【００２４】
本発明によれば、監視対象のシステムの稼動状況に応じて的確な権限制御を行なうための権限制御システム、権限制御方法及び権限制御プログラムを提供することができる。
【図面の簡単な説明】
【００２５】
【図１】本発明の実施形態の権限管理システムの説明図。
【図２】本発明の実施形態の権限管理システムの機能ブロックの説明図。
【図３】本実施形態の処理において用いるデータの説明図であって、（ａ）は認証管理サーバが保持する権限管理テーブルに記録されたデータ、（ｂ）は動的権限管理サーバが保持する障害管理テーブルに記録されたデータの説明図。
【図４】本実施形態の処理手順の説明図であって、（ａ）は障害発生時処理、（ｂ）は障害復旧時処理の説明図。
【図５】本実施形態の処理において用いるデータの説明図であって、（ａ）は障害発生時の権限管理テーブルに記録されたデータ、（ｂ）は障害復旧時の権限管理テーブルに記録されたデータの説明図。
【図６】第２の実施形態の処理手順の説明図であって、（ａ）は障害発生時処理、（ｂ）は障害復旧時処理の説明図。
【図７】他の実施形態の処理手順の説明図であって、（ａ）は第３の実施形態、（ｂ）は第４の実施形態の処理手順の説明図。
【図８】第５の実施形態の処理手順の説明図であって、（ａ）は障害発生時処理、（ｂ）は障害復旧時処理の説明図。
【図９】第６の実施形態の障害発生時処理の説明図。
【図１０】他の実施形態におけるログイン処理の説明図。
【図１１】認証管理サーバが保持する権限管理テーブルに記録されたデータの説明図。
【発明を実施するための形態】
【００２６】
＜第１の実施形態＞
以下、本発明を具体化した権限管理システムの一実施形態を図１〜図５に従って説明する。本実施形態では、各種サービスを提供するためのシステム（監視対象装置）の稼動状態を監視し、この稼動状態に応じて、作業担当者のユーザＩＤのアカウント状態を変更することによりアクセス権限の権限制御を行なう。ここでは、図１に示すように、監視対象システム１０、監視サーバ２０、認証管理サーバ３０、クライアント端末４０、動的権限管理サーバ５０を用いる。そして、各種サービスを提供するためのシステムである監視対象システム１０において障害が発生した場合には、動的権限管理サーバ５０が、認証管理サーバ３０における監視対象システム１０のアクセス権限を動的に変更する。
【００２７】
監視対象システム１０は、サービスを提供するためのコンピュータシステムであり、各サービス提供システムに共通的な情報処理を実行したり、システム基盤の運用上必要となる処理を実行したりする共用システムＺや、各サービス提供に必要な処理を個別に実行す
るサービス提供システム（Ａ，Ｂ，Ｃ）が含まれる。
【００２８】
更に、本実施形態では、各監視対象システム１０は、複数のサーバ１１により構築されている。例えば、共用システムＺはサーバ（ｚ１〜ｚ３）から構成されている。同様に、サービス提供システム（Ａ）はサーバ（ａ１〜ａ３）、サービス提供システム（Ｂ）はサーバ（ｂ１〜ｂ３）、サービス提供システム（Ｃ）はサーバ（ｃ１〜ｃ３）から構成されている。
【００２９】
そして、監視対象システム１０において障害が発生した場合には、稼動情報として、発生したエラーに関する情報を蓄積しておく。このエラーに関する情報には、障害が発生したサーバ１１の識別子（サーバＩＤ）や障害内容を含める。
【００３０】
監視サーバ２０は、ネットワークを介して、各監視対象システム１０の稼動状況を監視する既存のコンピュータシステム（監視システム）である。この監視サーバ２０は、制御部２１、担当者管理データベース２２、障害履歴データベース２３を備えている。制御部２１は、制御手段（ＣＰＵ、ＲＡＭ、ＲＯＭ等）を備え、後述する処理（障害監視段階、障害通知段階、障害復旧段階等の各処理等）を行なう。そのための監視プログラムを実行することにより、制御部２１は、図２に示すように、障害監視手段２１１、障害発生通知手段２１２、障害復旧通知手段２１３として機能する。
【００３１】
障害監視手段２１１は、監視対象システム１０の稼働状況を監視し、障害発生を検知する処理を実行する。本実施形態では、障害監視手段２１１が、監視対象システム１０を構成する各サーバ１１に、順次、アクセスし、各サーバ１１の稼働情報を取得する。なお、障害発生の検知方法はこれに限定されるものではない。例えば、障害発生時に、監視対象システム１０が、障害監視手段２１１に対して障害発生を通知するような構成を利用してもよい。
【００３２】
障害発生通知手段２１２は、障害の発生を検知した場合、各システムの運用管理担当者や動的権限管理サーバ５０に障害発生を通知する処理を実行する。
障害復旧通知手段２１３は、障害が解消し、システムが回復した場合に、動的権限管理サーバ５０に障害復旧を通知する処理を実行する。
【００３３】
担当者管理データベース２２には、監視対象システム１０に障害が発生した場合に、障害が発生した監視対象システム１０の復旧作業を指示する運用管理担当者に対して通知を送信するための連絡先テーブルが記録されている。この連絡先テーブルは、各監視対象システム１０の運用管理担当者が決定された際に予め登録される。この連絡先テーブルには、監視対象の各サーバ１１のサーバＩＤに関連付けられて、運用管理担当者の連絡先が記録されている。
【００３４】
障害履歴データベース２３には、監視対象システム１０において発生した障害の障害履歴レコードが記録される。この障害履歴レコードは、障害が発生した場合に生成されて登録される。障害履歴レコードには、障害が発生したサーバ１１の識別子（サーバＩＤ）、障害内容、障害発生日時、障害復旧日時を含める。
【００３５】
認証管理サーバ３０は、作業担当者等が監視対象システム１０にアクセスする場合に、権限を認証するための既存のコンピュータシステム（認証管理システム）である。この認証管理サーバ３０は、制御部３１、権限管理データベース３２を備えている。制御部３１は、制御手段（ＣＰＵ、ＲＡＭ、ＲＯＭ等）を備える。この制御部３１は、監視対象システム１０を構成するサーバ１１に対するログイン要求を取得し、ログイン要求に含まれるユーザＩＤ及びパスワードを取得する。そして、制御部３１は、取得したユーザＩＤ及び
パスワードと、権限管理データベース３２に登録されたユーザＩＤ及びパスワードとを照合することにより、アクセス者の認証を行なう。そして、アクセス者の認証ができた場合には、権限管理データベース３２により特定されるアクセス権限情報に基づき、各監視対象システム１０を構成する各サーバ１１へのアクセスを許可する。
【００３６】
権限管理データベース３２はアクセス権限情報記憶手段として機能する。この権限管理データベース３２には、図３（ａ）に示すように、アクセス者を認証し、アクセス権限を特定するための権限管理テーブル３２０が記録されている。この権限管理テーブル３２０は、各担当者の役割に応じて決定されたアクセス権限が登録された場合に記録される。権限管理テーブル３２０は、担当者毎に、グループＩＤ、ユーザＩＤ、パスワード、アクセス許可ホスト、アカウント状態に関する権限管理レコードが記録されている。
【００３７】
グループＩＤデータ領域には、このユーザＩＤが属するグループを特定するための識別子に関するデータが記録されている。本実施形態では、各ユーザＩＤが属するグループによりアクセス権限を特定することができる。ここでは、「管理者」、「運用参照」、「運用オペ」のグループが設定されている。「管理者」は、特権ＩＤと同様に強い権限が付与されたグループであり、各サーバ１１の設定変更を行なうことができる権限が付与される。本実施形態では、サーバ１１において発生した障害の復旧作業を行なう場合には、この「管理者」権限が必要になる。「運用参照」は、システムの稼動状態を確認するために最小限の権限が付与されたグループである。「運用オペ」は、システム運用のために、手順書等に基づき一定の範囲内のオペレーション作業を行なうために最小限の権限が付与されたグループである。
【００３８】
ユーザＩＤ、パスワードの各データ領域には、それぞれ各担当者を特定するための識別子、本人を認証するためのパスワードに関するデータが記録されている。
アクセス許可ホストデータ領域には、このユーザＩＤによりアクセス可能なサーバ１１を特定するための識別子（サーバＩＤ）に関するデータが記録されている。本実施形態では、一つのユーザＩＤに対して、複数のアクセス許可ホストを設定することができる。この場合には、アクセス許可ホストデータ領域に、この担当者が担当するすべてのサーバＩＤを登録する。
【００３９】
アカウント状態データ領域には、この権限の有効性を判定するためのフラグに関するデータが記録される。本実施形態では、「有効」フラグ又は「無効」フラグのいずれかが記録される。このアカウント状態において「有効」フラグが記録されている場合のみ、アクセス権限が付与されていることになり、制御部３１は、ユーザＩＤを用いてのアクセスを許容する。本実施形態においては、「運用参照」や「運用オペ」のグループに属するユーザＩＤについては、常時、有効フラグが記録されている。一方、「管理者」のグループに属するユーザＩＤについては、平常時は「無効」フラグが記録されており、動的権限管理サーバ５０からの指示に基づき「有効」フラグに変更される。更に、付与されたアクセス権限は、動的権限管理サーバ５０からの指示に基づいて「無効」フラグに変更されることにより、アクセス権限が取り消される。
【００４０】
クライアント端末４０は、各監視対象システム１０の担当者が利用するコンピュータ端末である。本実施形態においては、各担当者は、このクライアント端末４０を用いて、各監視対象システム１０にログインして、アクセス権限により許容された範囲での操作を行なうことができる。このクライアント端末４０は、制御部、キーボードやポインティングデバイスからなる入力部、ディスプレイ等からなる表示部等を備えている。
【００４１】
動的権限管理サーバ５０は、各監視対象システム１０の稼動状況に応じて、作業担当者のユーザＩＤのアカウント状態を変更するコンピュータシステムである。この動的権限管
理サーバ５０は、制御部５１、障害管理データベース５２を備えている。制御部５１は、制御手段（ＣＰＵ、ＲＡＭ、ＲＯＭ等）を備え、後述する処理（担当者特定段階、権限付与段階、権限取消段階等の各処理等）を行なう。そのための権限管理プログラムを実行することにより、制御部５１は、図２に示すように、担当者特定手段５１１、権限設定手段５１２として機能する。
【００４２】
担当者特定手段５１１は、障害が発生したサーバ１１について復旧作業を行なう作業担当者を特定する処理を実行する。
権限設定手段５１２は、権限付与手段及び権限取消手段として機能し、認証管理サーバ３０において設定されているユーザＩＤのアカウント状態の変更を指示する処理を実行する。このために、権限設定手段５１２には、認証管理サーバ３０に登録されたユーザＩＤのアカウント状態を変更する権限が設定されている。更に、権限設定手段５１２は、復旧作業のためにアカウント状態を変更した作業担当者のユーザＩＤを仮記憶する変更情報記憶手段を備えている。この変更情報記憶手段には、本来設定されているアカウント状態から変更（本実施形態では「無効」から「有効」に変更）を加えたユーザＩＤ及び、障害対応を行なう対象サーバＩＤを含めた障害対応レコードが記録される。
【００４３】
障害管理データベース５２は監視対象情報記憶手段として機能する。この障害管理データベース５２には、監視対象システム１０の各サーバ１１において発生する可能性がある障害を登録した障害管理テーブル５２０が記録されている。この障害管理テーブル５２０は、各管理システムにおいて発生する可能性がある障害を予め登録する。障害管理テーブル５２０は、対象システム、対象サーバ、障害内容、グループＩＤに関するデータを含んで構成されている。
【００４４】
対象システム、対象サーバの各データ領域には、監視対象のシステムやサーバを特定するための識別子（システムＩＤやサーバＩＤ）に関するデータが記録される。
障害内容データ領域には、各サーバにおいて発生する可能性がある障害の内容に関するデータが記録されている。
グループＩＤデータ領域には、発生した障害の復旧作業を行なうために必要な権限を有するグループを特定するための識別子に関するデータが記録されている。
【００４５】
次に、この権限管理システムにおける動作を、図４を用いて説明する。ここでは、図４（ａ）に示す障害発生時処理、図４（ｂ）に示す障害復旧時処理の順番に説明する。
【００４６】
（障害発生時処理）
まず、図４（ａ）を用いて障害発生時処理を説明する。
ここでは、監視サーバ２０の制御部２１は、稼動情報の取得処理を実行する（ステップＳ１−１）。具体的には、制御部２１の障害監視手段２１１は、ネットワークを介して、監視対象システム１０を構成する各サーバ１１に、順次、アクセスし、各サーバ１１の稼働情報を取得する。
【００４７】
次に、監視サーバ２０の制御部２１は、障害発生かどうかについての判定処理を実行する（ステップＳ１−２）。具体的には、制御部２１の障害監視手段２１１は、各サーバ１１から取得した稼動情報において、エラーメッセージが含まれているかどうかにより、障害発生を判定する。
【００４８】
稼動情報にエラーメッセージが含まれておらず、障害発生を検知しない場合（ステップＳ１−２において「ＮＯ」の場合）、稼動情報の取得処理（ステップＳ１−１）を継続する。
【００４９】
一方、稼動情報にエラーメッセージが含まれており、障害発生と判定した場合（ステップＳ１−２において「ＹＥＳ」の場合）、監視サーバ２０の制御部２１は、障害発生通知処理を実行する（ステップＳ１−３）。具体的には、制御部２１の障害監視手段２１１は、障害が発生したサーバ１１の識別子（サーバＩＤ）、障害内容、障害発生日時を記録した障害履歴レコードを生成し、障害履歴データベース２３に登録する。更に、制御部５１の障害発生通知手段２１２は、動的権限管理サーバ５０に対して障害発生通知を送信する。この障害発生通知には、障害が発生した監視対象システム１０、サーバ１１及び障害内容に関する情報を含める。本実施形態においては、サーバａ１において「ｘｘｘプロセス停止」の障害が発生した場合を想定する。この場合には、サーバａ１についての復旧作業が必要になる。
【００５０】
更に、障害発生通知手段２１２は、担当者管理データベース２２を用いて、運用管理担当者の中から、障害が発生したサーバ１１の復旧作業を指示する運用管理担当者を特定する。そして、障害発生通知手段２１２は、この運用管理担当者の連絡先に対して、障害発生通知を送信する。障害発生通知を受信した運用管理担当者は、作業担当者に対して復旧作業を指示する。
【００５１】
障害発生通知を受信した動的権限管理サーバ５０の制御部５１は、障害発生サーバについて登録されたユーザＩＤの特定処理を実行する（ステップＳ１−４）。具体的には、制御部５１の担当者特定手段５１１は、認証管理サーバ３０にアクセスする。そして、権限管理データベース３２において、障害が発生した監視対象システム１０について、障害の復旧に必要なグループＩＤに属し、アクセス許可ホストデータ領域に障害が発生したサーバＩＤが登録されたユーザＩＤを検索する。本実施形態では、図３（ａ）において、グループＩＤ「管理者」に属し、アクセス許可ホストとしてサーバａ１が登録されたユーザＩＤとして「ｄｅｖ０１」、「ｄｅｖ０２」、「ｄｅｖ０４」を特定する。
【００５２】
次に、動的権限管理サーバ５０の制御部５１は、ユーザＩＤの有効化処理を実行する（ステップＳ１−５）。具体的には、制御部５１の権限設定手段５１２は、認証管理サーバ３０に対して、ステップＳ１−４において特定したユーザＩＤのアカウント状態の有効化を指示する。本実施形態では、図５（ａ）に示すように、各ユーザＩＤ「ｄｅｖ０１」、「ｄｅｖ０２」、「ｄｅｖ０４」のアカウント状態を「有効」にするための指示を認証管理サーバ３０に送信する。この指示を受信した認証管理サーバ３０は、各ユーザＩＤについてのアカウント状態データ領域に「有効」フラグを記録する。これにより、担当者「ａａａ」、「ｂｂｂ」、「ｄｄｄ」は、サーバａ１に、「管理者」の権限でアクセス可能になる。更に、権限設定手段５１２は、この障害に対応して有効化した作業担当者のユーザＩＤ、対象サーバＩＤを設定した障害対応レコードを変更情報記憶手段に仮記憶する。
【００５３】
（障害復旧時処理）
次に、図４（ｂ）を用いて障害復旧時処理を説明する。
ここでは、監視サーバ２０の制御部２１は、障害復旧情報の取得処理を実行する（ステップＳ２−１）。具体的には、制御部２１の障害監視手段２１１は、各サーバ１１の稼働情報を取得する。作業担当者による復旧作業により、サーバ１１が復旧した場合には、障害監視手段２１１は、障害発生サーバの正常稼働情報を取得する。そして、障害発生サーバを含む監視対象システム１０の復旧を確認した作業担当者は、監視サーバ２０において障害復旧情報を入力する。障害復旧情報を取得した制御部２１の障害監視手段２１１は、障害履歴データベース２３において、障害が復旧した監視対象システム１０のサーバ１１の識別子（サーバＩＤ）が記録された障害履歴レコードに障害復旧日時を記録する。
【００５４】
次に、監視サーバ２０の制御部２１は、障害復旧通知処理を実行する（ステップＳ２−２）。具体的には、制御部２１の障害復旧通知手段２１３は、動的権限管理サーバ５０に
対して障害復旧通知を送信する。この障害復旧通知には、障害が回復した監視対象システム１０、サーバ１１及び障害内容に関する情報を含める。本実施形態では、障害が発生していたサーバａ１が含まれるシステム（Ａ）が復旧した場合を想定する。
【００５５】
障害復旧通知を受信した動的権限管理サーバ５０の制御部５１は、障害発生サーバにおいて一時的に有効化したユーザＩＤの特定処理を実行する（ステップＳ２−３）。具体的には、制御部５１の担当者特定手段５１１は、障害発生時に有効化したユーザＩＤを変更情報記憶手段から取得する。本実施形態では、ユーザＩＤ「ｄｅｖ０１」、「ｄｅｖ０２」、「ｄｅｖ０４」を変更情報記憶手段から取得する。
【００５６】
次に、動的権限管理サーバ５０の制御部５１は、ユーザＩＤの無効化処理を実行する（ステップＳ２−４）。具体的には、制御部５１の権限設定手段５１２は、認証管理サーバ３０に対して、特定したユーザＩＤのアカウント状態の無効化を指示する。ここでは、権限管理テーブル３２０において、ユーザＩＤに関連付けられているすべてのサーバ１１の障害が復旧している場合のみ、アカウント状態を「無効」にするための指示を認証管理サーバ３０に送信する。この指示を受信した認証管理サーバ３０は、各ユーザＩＤについてのアカウント状態データ領域に「無効」フラグを記録する。一方、権限管理テーブル３２０において、障害が継続している他のサーバ１１に関連付けられているユーザＩＤについては、アカウント状態を「無効」にするための指示を送信しない。この結果、認証管理サーバ３０において、アカウント状態データ領域の「有効」フラグが維持される。本実施形態では、他の監視対象システム１０については障害が発生しておらず、図５（ｂ）に示すように、ユーザＩＤ「ｄｅｖ０１」、「ｄｅｖ０２」、「ｄｅｖ０４」のアカウント状態が「無効」になる。更に、権限設定手段５１２は、変更情報記憶手段に仮記憶されたユーザＩＤ、対象サーバＩＤを含む障害対応レコードを削除する。
【００５７】
以上、本実施形態によれば、以下に示す効果を得ることができる。
（１）上記実施形態では、障害発生と判定した場合（ステップＳ１−２において「ＹＥＳ」の場合）、監視サーバ２０の制御部２１は、障害発生通知処理を実行する（ステップＳ１−３）。障害発生通知を受信した動的権限管理サーバ５０の制御部５１は、障害発生サーバについて登録された担当者の特定処理（ステップＳ１−４）、この担当者のユーザＩＤの有効化処理（ステップＳ１−５）を実行する。これにより、障害が発生した場合、グループＩＤ「管理者」に属し、障害が発生したサーバ１１にアクセスが許可されたユーザＩＤのみが有効化される。従って、障害対応が必要な場合には、平常時には無効化されているユーザＩＤを用いて、効率的に復旧作業を行なうことができる。この場合、制御部５１の権限設定手段５１２は、認証管理サーバ３０に対して、特定した作業担当者において、グループＩＤ「管理者」に属するユーザＩＤのアカウント状態の有効化を指示する。従って、既存の認証管理サーバ３０による認証管理方法や設定情報を用いて、アクセス管理を行なうことができる。
【００５８】
（２）上記実施形態では、監視サーバ２０の制御部２１は、障害復旧情報を取得した場合（ステップＳ２−１）、障害復旧通知処理（ステップＳ２−２）を実行する。障害復旧通知を受信した動的権限管理サーバ５０の制御部５１は、障害発生サーバにおいて一時的に有効化したユーザＩＤの特定処理（ステップＳ２−３）、このユーザＩＤの無効化処理（ステップＳ２−４）を実行する。これにより、平常時等のように高いアクセス権限が必要でない場合には無効化しておくことにより、不必要に高い権限でのアクセスを抑制できる。従って、誤操作を抑制し、セキュリティを向上させることができる。
【００５９】
＜第２の実施形態＞
次に、本発明を具体化した第２の実施形態を図６に従って説明する。第１の実施形態においては、障害が発生したサーバ１１についてアクセスが許可され、グループＩＤ「管理
者」に属するすべての作業担当者のユーザＩＤを有効化した。第２の実施形態は、第１の実施形態の障害発生時処理において、一つのユーザＩＤに対して、複数のサーバ１１や監視対象システム１０のアクセス権限が設定されている環境において、障害が発生したサーバやシステムについてのアクセス権限のみを有効化する構成であり、同様の部分については詳細な説明を省略する。
【００６０】
この実施形態においては、変更情報記憶手段に、認証管理サーバ３０の権限管理データベース３２において変更を加える前の内容を記録する。具体的には、本来のアカウント状態を変更したユーザＩＤについて、本来の権限管理レコードの内容（グループＩＤ、ユーザＩＤ、アクセス許可ホスト、アカウント状態）を記録する。
【００６１】
以下、図６（ａ）に示す障害発生時処理、図６（ｂ）に示す障害復旧時処理の順番に説明する。
（障害発生時処理）
まず、図６（ａ）を用いて障害発生時処理を説明する。
【００６２】
ここでは、監視サーバ２０の制御部２１は、ステップＳ１−１と同様に、稼動情報の取得処理を実行する（ステップＳ３−１）。
次に、監視サーバ２０の制御部２１は、ステップＳ１−２と同様に、障害発生かどうかについての判定処理を実行する（ステップＳ３−２）。障害発生を検知しない場合（ステップＳ３−２において「ＮＯ」の場合）、稼動情報の取得処理（ステップＳ３−１）を継続する。
【００６３】
一方、障害発生と判定した場合（ステップＳ３−２において「ＹＥＳ」の場合）、監視サーバ２０の制御部２１は、ステップＳ１−３と同様に、障害発生通知処理を実行する（ステップＳ３−３）。
【００６４】
障害発生通知を受信した動的権限管理サーバ５０の制御部５１は、ステップＳ１−４と同様に、障害発生サーバについて登録されたＩＤであって、グループＩＤ「管理者」に属するユーザＩＤの特定処理を実行する（ステップＳ３−４）。具体的には、権限設定手段５１２は、権限管理データベース３２において、グループＩＤ「管理者」に属するとともに、アクセス許可ホストに障害発生サーバを含み、アカウント状態として「無効」が登録されたユーザＩＤを検索する。また、権限設定手段５１２は、変更情報記憶手段において、アクセス許可ホストに障害発生サーバを含み、グループＩＤ「管理者」に属するユーザＩＤを検索する。
【００６５】
次に、動的権限管理サーバ５０の制御部５１は、ユーザＩＤの有効化処理を実行する（ステップＳ３−５）。具体的には、制御部５１の権限設定手段５１２は、認証管理サーバ３０に対して、ステップＳ３−４において特定したユーザＩＤのアカウント状態の有効化を指示する。更に、権限設定手段５１２は、この障害に対応して有効化した作業担当者の権限管理レコードを変更情報記憶手段に仮記憶する。
【００６６】
一方、変更情報記憶手段において、グループＩＤ「管理者」に属するユーザＩＤが記録されている場合には、権限設定手段５１２は、障害が発生したサーバやシステムに対するグループＩＤ「管理者」への追加登録申請を行なう。ここでは、認証管理サーバ３０に対して、サーバＩＤをアクセス許可ホストとして記録するための追加登録申請を送信する。例えば、サーバ「ａ１」において障害が発生した場合、復旧作業を行なう作業担当者のユーザＩＤ「ｄｅｖ０１」を特定する。ここで、権限管理データベース３２において、ユーザＩＤ「ｄｅｖ０１」のアクセス許可ホストとして「ｂ１」のみが記録されている場合は、権限設定手段５１２は、「ａ１」についての追加登録申請を送信する。
【００６７】
次に、動的権限管理サーバ５０の制御部５１は、障害が発生していないサーバについてのアクセス権限の無効化処理を実行する（ステップＳ３−６）。具体的には、制御部５１の権限設定手段５１２は、認証管理サーバ３０において、アカウント状態を有効化したユーザＩＤの権限管理レコードに、障害が発生していないサーバ１１がアクセス許可ホストとして記録されているかどうかを確認する。ここで、ユーザＩＤに対して、障害が発生していないシステムやサーバがアクセス許可ホストとして記録されている場合には、権限設定手段５１２は、認証管理サーバ３０に対して、障害が発生していないシステムやサーバについての権限抹消申請を送信する。例えば、サーバ「ａ１」において障害が発生した場合、復旧作業を行なう作業担当者のユーザＩＤ「ｄｅｖ０１」を特定する。ここで、ユーザＩＤ「ｄｅｖ０１」のアクセス許可ホストとして「ａ１，ａ２，ａ３，ｂ１，ｂ２，ｂ３，ｚ１，ｚ２，ｚ３」が記録されている場合は、権限設定手段５１２は、「ａ２，ａ３，ｂ１，ｂ２，ｂ３，ｚ１，ｚ２，ｚ３」についての権限抹消申請を送信する。
【００６８】
（障害復旧時処理）
次に、図６（ｂ）を用いて障害復旧時処理を説明する。
ここでは、監視サーバ２０の制御部２１は、ステップＳ２−１と同様に、障害復旧情報の取得処理を実行する（ステップＳ４−１）。
【００６９】
次に、監視サーバ２０の制御部２１は、ステップＳ２−２と同様に、障害復旧通知処理を実行する（ステップＳ４−２）。
障害復旧通知を受信した動的権限管理サーバ５０の制御部５１は、ステップＳ２−３と同様に、障害発生サーバにおいて一時的に有効化したユーザＩＤの特定処理を実行する（ステップＳ４−３）。
【００７０】
次に、動的権限管理サーバ５０の制御部５１は、ユーザＩＤの無効化処理を実行する（ステップＳ４−４）。具体的には、制御部５１の権限設定手段５１２は、認証管理サーバ３０に対して、特定したユーザＩＤに関連付けられたアクセス許可ホストとして記録されているサーバＩＤを取得する。そして、権限設定手段５１２は、障害復旧情報に含まれていないサーバ１１が残っているかどうかを確認する。他に復旧していないシステムやサーバが残っているユーザＩＤについては、権限設定手段５１２は、認証管理サーバ３０に対して、復旧したシステムのサーバ１１についての権限抹消申請を送信する。一方、すべてのシステムやサーバが復旧したユーザＩＤについては、変更情報記憶手段に保持していた権限管理レコードの内容に基づいて、認証管理サーバ３０に対して、アカウント状態を「無効」にした状態での登録申請を送信する。
【００７１】
以上、本実施形態によれば、以下に示す効果を得ることができる。
（３）上記実施形態では、動的権限管理サーバ５０の制御部５１は、障害が発生していないサーバについてのアクセス権限の無効化処理を実行する（ステップＳ３−６）。ここでは、権限設定手段５１２は、認証管理サーバ３０に対して、障害が発生していないシステムやサーバについての権限抹消申請を送信することにより、一旦、権限管理データベース３２から削除する。これにより、ユーザＩＤを、障害発生により復旧作業が必要なサーバのみにアクセスが許可された状態に設定することができる。従って、必要以上のシステムやサーバへのアクセスを抑制することにより、よりセキュリティを向上させることができる。
【００７２】
＜第３の実施形態＞
次に、本発明を具体化した第３の実施形態を図７（ａ）に従って説明する。第１の実施形態においては、障害が発生した監視対象システム１０について、グループＩＤ「管理者」に属するすべての作業担当者のユーザＩＤを有効化した。第３の実施形態は、第１の実
施形態の障害発生時処理において、有効化するユーザＩＤを作業担当者の勤怠状況に基づいて特定する構成であり、同様の部分については詳細な説明を省略する。本実施形態においては、作業担当者毎に勤怠状況を管理する勤怠管理システムを設ける。この勤怠管理システムにおいては、ユーザＩＤに対して、勤怠状況（出勤状況や出勤予定）が登録されている。
【００７３】
（障害発生時処理）
図７（ａ）を用いて障害発生時処理を説明する。
ここでは、監視サーバ２０の制御部２１は、ステップＳ１−１と同様に、稼動情報の取得処理を実行する（ステップＳ５−１）。
【００７４】
次に、監視サーバ２０の制御部２１は、ステップＳ１−２と同様に、障害発生かどうかについての判定処理を実行する（ステップＳ５−２）。障害発生を検知しない場合（ステップＳ５−２において「ＮＯ」の場合）、稼動情報の取得処理（ステップＳ５−１）を継続する。
【００７５】
一方、障害発生と判定した場合（ステップＳ５−２において「ＹＥＳ」の場合）、監視サーバ２０の制御部２１は、ステップＳ１−３と同様に、障害発生通知処理を実行する（ステップＳ５−３）。
【００７６】
障害発生通知を受信した動的権限管理サーバ５０の制御部５１は、ステップＳ１−４と同様に、障害発生サーバについて登録されたＩＤであって、グループＩＤ「管理者」に属するユーザＩＤの特定処理を実行する（ステップＳ５−４）。
【００７７】
次に、動的権限管理サーバ５０の制御部５１は、作業担当者の勤怠状況の確認処理を実行する（ステップＳ５−５）。具体的には、制御部５１の担当者特定手段５１１は、勤怠管理システムにアクセスし、特定したユーザＩＤに関連付けられた勤怠状況を取得する。そして、担当者特定手段５１１は、出勤している作業担当者、又は基準時間内に出勤予定の作業担当者のユーザＩＤを抽出する。
【００７８】
次に、動的権限管理サーバ５０の制御部５１は、ユーザＩＤの有効化処理を実行する（ステップＳ５−６）。具体的には、制御部５１の権限設定手段５１２は、認証管理サーバ３０に対して、勤怠管理システムを用いて抽出した作業担当者のユーザＩＤについてアカウント状態の有効化を指示する。更に、権限設定手段５１２は、この障害に対応して有効化した作業担当者のユーザＩＤ、対象サーバＩＤを設定した障害対応レコードを変更情報記憶手段に仮記憶する。
【００７９】
以上、本実施形態によれば、以下に示す効果を得ることができる。
（４）上記実施形態では、動的権限管理サーバ５０の制御部５１は、特定した担当者の勤怠状況の確認処理を実行する（ステップＳ５−５）。そして、動的権限管理サーバ５０の制御部５１は、ユーザＩＤの有効化処理を実行する（ステップＳ５−６）。これにより、社内にいない場合や、出勤予定がない場合等により障害に対応できない作業担当者のユーザＩＤを「無効」のまま維持することができる。従って、不必要なアクセス権限の設定を抑制し、セキュリティを向上させることができる。
【００８０】
＜第４の実施形態＞
次に、本発明を具体化した第４の実施形態を図７（ｂ）に従って説明する。第１の実施形態においては、障害が発生した監視対象システム１０を構成するサーバ１１について、グループＩＤ「管理者」に属する作業担当者のユーザＩＤを有効化した。第４の実施形態は、第１の実施形態の障害発生時処理において、有効化するユーザＩＤを復旧作業に必要
な権限レベルを考慮して特定する構成であり、同様の部分については詳細な説明を省略する。本実施形態においては、認証管理サーバ３０において、「管理者」のアクセス権限を細分化するとともに、これに対応させて異なる権限レベルのグループＩＤが設定されている場合を想定する。また、動的権限管理サーバ５０の制御部５１には、障害状況に対応させて、細分化された「管理者」のアクセス権限の中で、復旧作業に必要な権限レベルを登録した権限レベルテーブル（権限レベル情報記憶手段）を保持させておく。そして、障害状況に応じて、復旧作業に必要な最低限の権限レベル以上のアクセス権限が設定されたグループＩＤを有するユーザＩＤのみについてアカウント状態を有効化する。
【００８１】
（障害発生時処理）
図７（ｂ）を用いて障害発生時処理を説明する。
ここでは、監視サーバ２０の制御部２１は、ステップＳ１−１と同様に、稼動情報の取得処理を実行する（ステップＳ６−１）。
【００８２】
次に、監視サーバ２０の制御部２１は、ステップＳ１−２と同様に、障害発生かどうかについての判定処理を実行する（ステップＳ６−２）。障害発生を検知しない場合（ステップＳ６−２において「ＮＯ」の場合）、稼動情報の取得処理（ステップＳ６−１）を継続する。
【００８３】
一方、障害発生と判定した場合（ステップＳ６−２において「ＹＥＳ」の場合）、監視サーバ２０の制御部２１は、ステップＳ１−３と同様に、障害発生通知処理を実行する（ステップＳ６−３）。
【００８４】
障害発生通知を受信した動的権限管理サーバ５０の制御部５１は、復旧作業に必要なアクセス権限の特定処理を実行する（ステップＳ６−４）。具体的には、制御部５１の担当者特定手段５１１は、権限レベルテーブルから、障害発生通知に含まれる障害状況に対応した権限レベルを特定する。ここでは、復旧作業において必要最低限の権限レベルが特定される。
【００８５】
次に、動的権限管理サーバ５０の制御部５１は、障害発生サーバについて登録されたユーザＩＤの特定処理を実行する（ステップＳ６−５）。具体的には、ステップＳ１−４と同様に、制御部５１の担当者特定手段５１１は、認証管理サーバ３０にアクセスする。そして、担当者特定手段５１１は、権限管理テーブル３２０において、ステップＳ６−４で特定した権限レベル以上のアクセス権限に対応するグループＩＤに属し、アクセス許可ホストに障害が発生したサーバＩＤに関連付けられたユーザＩＤを検索する。
【００８６】
次に、動的権限管理サーバ５０の制御部５１は、ユーザＩＤの有効化処理を実行する（ステップＳ６−６）。具体的には、制御部５１の権限設定手段５１２は、認証管理サーバ３０に対して、権限レベルテーブルを用いて抽出したグループＩＤに属するユーザＩＤについてアカウント状態の有効化を指示する。更に、権限設定手段５１２は、この障害に対応して有効化した作業担当者のユーザＩＤ、対象サーバＩＤを設定した障害対応レコードを変更情報記憶手段に仮記憶する。
【００８７】
以上、本実施形態によれば、以下に示す効果を得ることができる。
（５）上記実施形態では、動的権限管理サーバ５０の制御部５１は、復旧作業に必要なアクセス権限の特定処理を実行する（ステップＳ６−５）。これにより、アクセス権限を細分化して登録している環境では、障害状況に応じて最低限必要な作業担当者のユーザＩＤを有効化することができる。
【００８８】
＜第５の実施形態＞
次に、本発明を具体化した第５の実施形態を図８に従って説明する。第１の実施形態においては、障害が発生した監視対象システム１０について、グループＩＤ「管理者」に属する作業担当者のユーザＩＤを有効化した。第５の実施形態は、第１の実施形態の障害発生時処理、障害復旧時処理において、障害の影響を受ける他のサーバ１１を考慮してユーザＩＤを有効化する構成であり、同様の部分については詳細な説明を省略する。本実施形態においては、障害が発生した監視対象システム１０だけではなく、この障害の影響を受ける他の監視対象システム１０についても作業担当者のユーザＩＤを有効化する。この場合には、監視対象情報記憶手段として、障害管理テーブル５２０に影響先情報を記録しておく。この影響先情報には、所定のサーバ１１において障害が発生した場合、この障害の影響が及ぶ他のサーバ１１（関連装置）を特定するための識別子（サーバＩＤ）が記録されている。本実施形態においては、一つの障害により複数のサーバに影響を与える場合には、影響を受けるすべてのサーバ１１の識別子が記録される。
【００８９】
以下、図８（ａ）に示す障害発生時処理、図８（ｂ）に示す障害復旧時処理の順番に説明する。
（障害発生時処理）
まず、図８（ａ）を用いて障害発生時処理を説明する。
【００９０】
ここでは、監視サーバ２０の制御部２１は、ステップＳ１−１と同様に、稼動情報の取得処理を実行する（ステップＳ７−１）。
次に、監視サーバ２０の制御部２１は、ステップＳ１−２と同様に、障害発生かどうかについての判定処理を実行する（ステップＳ７−２）。障害発生を検知しない場合（ステップＳ７−２において「ＮＯ」の場合）、稼動情報の取得処理（ステップＳ７−１）を継続する。
【００９１】
一方、障害発生と判定した場合（ステップＳ７−２において「ＹＥＳ」の場合）、監視サーバ２０の制御部２１は、ステップＳ１−３と同様に、障害発生通知処理を実行する（ステップＳ７−３）。
【００９２】
障害発生通知を受信した動的権限管理サーバ５０の制御部５１は、障害発生サーバの関連サーバの特定処理を実行する（ステップＳ７−４）。具体的には、制御部５１の担当者特定手段５１１は、障害管理データベース５２に記録された障害管理テーブル５２０から、障害発生サーバの障害状況に応じて、影響を受けるすべてのサーバ１１を特定する。これにより、障害発生サーバだけではなく、関連サーバも特定することができる。
【００９３】
次に、動的権限管理サーバ５０の制御部５１は、障害発生サーバ、関連サーバについて登録されたユーザＩＤの特定処理を実行する（ステップＳ７−５）。具体的には、制御部５１の担当者特定手段５１１は、認証管理サーバ３０にアクセスし、権限管理データベース３２において、障害発生サーバ及び影響先として特定した関連サーバについてグループＩＤ「管理者」に属するユーザＩＤを検索する。
【００９４】
次に、動的権限管理サーバ５０の制御部５１は、障害発生サーバ、関連サーバについて登録された担当者のユーザＩＤの有効化処理を実行する（ステップＳ７−６）。具体的には、制御部５１の権限設定手段５１２は、認証管理サーバ３０に対して、抽出した作業担当者において、グループＩＤ「管理者」に属するユーザＩＤについて、アカウント状態の有効化を指示する。更に、権限設定手段５１２は、この障害に対応して有効化した作業担当者のユーザＩＤ、対象サーバＩＤを設定した障害対応レコードを変更情報記憶手段に仮記憶する。
【００９５】
（障害復旧時処理）
次に、図８（ｂ）を用いて障害復旧時処理を説明する。
監視サーバ２０の制御部２１は、ステップＳ２−１と同様に、障害復旧情報の取得処理を実行する（ステップＳ８−１）。
【００９６】
次に、監視サーバ２０の制御部２１は、ステップＳ２−２と同様に、障害復旧通知処理を実行する（ステップＳ８−２）。
障害復旧通知を受信した動的権限管理サーバ５０の制御部５１は、障害発生サーバ、関連サーバにおいて一時的に許可したユーザＩＤの特定処理を実行する（ステップＳ８−３）。具体的には、制御部５１の担当者特定手段５１１は、障害発生時に有効化したユーザＩＤを変更情報記憶手段から取得する。
【００９７】
次に、動的権限管理サーバ５０の制御部５１は、ユーザＩＤの無効化処理を実行する（ステップＳ８−４）。具体的には、制御部５１の権限設定手段５１２は、権限管理データベース３２において、特定したユーザＩＤのアカウント状態の無効化を指示する。ここでは、権限管理テーブル３２０において、特定のユーザＩＤのすべての対象システムの障害が復旧している場合にアカウント状態データ領域に「無効」フラグを記録する。一方、権限管理テーブル３２０において、障害が継続している他のサーバ１１に対するアクセス権限のグループＩＤ「管理者」に属するユーザＩＤについては、アカウント状態データ領域の「有効」フラグを維持する。
【００９８】
以上、本実施形態によれば、以下に示す効果を得ることができる。
（６）上記実施形態では、動的権限管理サーバ５０の制御部５１は、障害発生サーバの関連サーバの特定処理（ステップＳ７−４）、障害発生サーバ、関連サーバについて登録されたユーザＩＤの特定処理（ステップＳ７−５）、ユーザＩＤの有効化処理（ステップＳ７−６）を実行する。これにより、一つのサーバ１１において発生した障害の影響を考慮して、的確な作業担当者にアクセス権限を設定することができる。
【００９９】
＜第６の実施形態＞
次に、本発明を具体化した第６の実施形態を図９に従って説明する。第１の実施形態においては、障害が発生した監視対象システム１０について、グループＩＤ「管理者」に属する作業担当者のユーザＩＤを有効化した。第６の実施形態は、第１の実施形態の障害発生時処理において、アクセス権限を付与するために、一時的な新たなＩＤを設定する構成であり、同様の部分については詳細な説明を省略する。本実施形態においては、障害が発生した監視対象システム１０について、一時的に有効化した仮ユーザＩＤを設定する。このために、動的権限管理サーバ５０の制御部５１に認証支援手段を設ける。この認証支援手段には、仮ユーザＩＤテーブルを保持させる。この仮ユーザＩＤテーブルには、使用可能な仮ユーザＩＤ、仮パスワードが記録されている。そして、障害発生時には、仮ユーザＩＤテーブルにおいて、作業担当者に対して仮ユーザＩＤを設定するとともに、この仮ユーザＩＤに対して、本来のユーザＩＤを関連付けて記録する。
【０１００】
更に、作業担当者の操作ログを蓄積するログ管理システムを設ける。このログ管理システムは、仮ユーザＩＤによるログインを検知した場合、この作業担当者の操作入力内容を取得し、操作日時に関連付けて蓄積する。
【０１０１】
（障害発生時処理）
まず、図９を用いて障害発生時処理を説明する。
ここでは、監視サーバ２０の制御部２１は、ステップＳ１−１と同様に、稼動情報の取得処理を実行する（ステップＳ９−１）。
【０１０２】
次に、監視サーバ２０の制御部２１は、ステップＳ１−２と同様に、障害発生かどうか
についての判定処理を実行する（ステップＳ９−２）。障害発生を検知しない場合（ステップＳ９−２において「ＮＯ」の場合）、稼動情報の取得処理（ステップＳ９−１）を継続する。
【０１０３】
一方、障害発生と判定した場合（ステップＳ９−２において「ＹＥＳ」の場合）、監視サーバ２０の制御部２１は、ステップＳ１−３と同様に、障害発生通知処理を実行する（ステップＳ９−３）。
【０１０４】
障害発生通知を受信した動的権限管理サーバ５０の制御部５１は、ステップＳ１−４と同様に、障害発生サーバについて登録された担当者の特定処理を実行する（ステップＳ９−４）。
【０１０５】
次に、動的権限管理サーバ５０の制御部５１は、障害発生サーバについて登録された担当者に対してアクセス権限を付与するための仮ユーザＩＤの設定処理を実行する（ステップＳ９−５）。具体的には、制御部５１の担当者特定手段５１１は、仮ユーザＩＤテーブルから、使用可能な仮ユーザＩＤを取得する。ここでは、仮ユーザＩＤテーブルにおいて、本来のユーザＩＤが関連付けられていない仮ユーザＩＤを取得する。この場合、担当者特定手段５１１は、特定した作業担当者の人数分の仮ユーザＩＤを取得する。そして、担当者特定手段５１１は、仮ユーザＩＤテーブルにおいて、仮ユーザＩＤに関連付けて、本来のユーザＩＤを記録する。更に、担当者特定手段５１１は、認証管理サーバ３０に対して、仮ユーザＩＤの登録申請を送信する。この登録申請においては、グループＩＤ「管理者」において仮ユーザＩＤ、仮パスワード、障害発生サーバのサーバＩＤを含める。登録申請を受信した認証管理サーバ３０は、権限管理データベース３２に仮ユーザＩＤを登録する。これにより、仮ユーザＩＤにおいて、障害発生サーバに対する「管理者」のアクセス権限が付与される。
【０１０６】
次に、動的権限管理サーバ５０の制御部５１は、仮ユーザＩＤの通知処理を実行する（ステップＳ９−６）。具体的には、制御部５１の担当者特定手段５１１は、障害が発生した監視対象システム１０の運用管理担当者に対して、新たに設定した仮ユーザＩＤ及び仮パスワードを通知する。この場合、運用管理担当者は、動的権限管理サーバ５０から取得した仮ユーザＩＤ及び仮パスワードを、作業担当者に対して通知して、復旧作業の実行を指示する。
【０１０７】
（ログイン処理）
作業担当者は、通知された仮ユーザＩＤ及び仮パスワードを用いて、各サーバ１１にアクセスして復旧作業を行なう。この場合、ログ管理システムは、仮ユーザＩＤにおける操作ログの記録処理を実行する。具体的には、ログ管理システムは、クライアント端末４０において、仮ユーザＩＤを用いてログインした作業担当者の操作入力内容を取得し、操作日時に関連付けて蓄積する。
【０１０８】
（障害復旧時処理）
障害復旧時処理においては、監視サーバ２０の制御部２１において、ステップＳ２−１〜Ｓ２−２と同様に、障害復旧情報の取得処理、障害復旧通知処理を実行する。
【０１０９】
そして、障害復旧通知を受信した動的権限管理サーバ５０の制御部５１は、ステップＳ２−３と同様に、障害発生サーバにおいて一時的に許可した仮ユーザＩＤの特定処理を実行する。
【０１１０】
そして、ステップＳ２−４と同様に、仮ユーザＩＤの無効化処理を実行する。この場合、動的権限管理サーバ５０の制御部５１は、認証管理サーバ３０に対して、仮ユーザＩＤ
の抹消申請を送信する。更に、制御部５１は、仮ユーザＩＤテーブルにおいて、仮ユーザＩＤに関連付けて記録されたユーザＩＤを削除する。
【０１１１】
以上、本実施形態によれば、以下に示す効果を得ることができる。
（７）上記実施形態では、動的権限管理サーバ５０の制御部５１は、障害発生サーバについて登録された担当者に対してアクセス権限を付与するための仮ユーザＩＤの設定処理を実行する（ステップＳ９−５）。そして、ログ管理システムは、仮ユーザＩＤにおける操作ログの記録処理を実行する。これにより、通常のユーザＩＤの設定情報を変更することなく、障害対応に必要な権限をもつユーザＩＤの作成をすることができる。また、一時的に付与された仮ユーザＩＤにおける操作内容を記録することができる。そして、この作業担当者が復旧作業時に行なった操作情報を蓄積し、障害対応について情報共有を行なうことができる。
【０１１２】
なお、上記実施形態は、以下の態様に変更してもよい。
・ 上記第５の実施形態では、障害管理テーブル５２０において、影響先情報を予め登録しておく。この影響先情報は、復旧作業を行なう作業担当者の操作ログに基づいて、更新するようにしてもよい。この場合には、復旧作業を行なった作業担当者がアクセスしたシステムやサーバの情報を蓄積し、障害内容に関連付けて、これらのシステムやサーバ情報を影響先として登録する。これにより、復旧作業実績に基づいて、必要な影響先を設定することができる。
【０１１３】
・ 上記第６の実施形態では、動的権限管理サーバ５０の制御部５１は、仮ユーザＩＤの通知処理を実行する（ステップＳ９−６）。これに代えて、作業担当者自身のユーザＩＤを用いてログインできるようにしてもよい。この場合にも、障害発生通知を受信した動的権限管理サーバ５０の制御部５１は、ステップＳ１−４と同様に、障害発生サーバについて登録された担当者の特定処理を実行する（ステップＳ９−４）。次に、動的権限管理サーバ５０の制御部５１は、障害発生サーバについて登録された担当者に対してアクセス権限を付与するための仮ユーザＩＤの設定処理を実行する（ステップＳ９−５）。そして、動的権限管理サーバ５０の制御部５１は、仮ユーザＩＤの通知処理（ステップＳ９−６）に代えて、仮パスワードの通知処理を実行する。
【０１１４】
次に、図１０を用いてログイン処理を説明する。
運用管理担当者より仮パスワードの通知を受けた作業担当者が、各サーバ１１にアクセスする場合には、自分のユーザＩＤ及び通知された仮パスワードを用いる。
【０１１５】
そして、動的権限管理サーバ５０の制御部５１は、ログイン要求の取得処理を実行する（ステップＳ１０−１）。具体的には、制御部５１の認証支援手段は、サーバ１１から、ユーザＩＤ及び仮パスワードを含めたログイン要求を取得する。
【０１１６】
次に、動的権限管理サーバ５０の制御部５１は、仮ユーザＩＤの登録があるかどうかについての判定処理を実行する（ステップＳ１０−２）。具体的には、制御部５１の認証支援手段は、仮ユーザＩＤテーブルにおいて、ログイン要求に含まれるユーザＩＤを検索する。
【０１１７】
仮ユーザＩＤテーブルにユーザＩＤが登録されており、仮ユーザＩＤが設定されている場合（ステップＳ１０−２において「ＹＥＳ」の場合）、動的権限管理サーバ５０の制御部５１は、仮ユーザＩＤによる認証要求処理を実行する（ステップＳ１０−３）。具体的には、制御部５１の認証支援手段は、ログイン要求に含まれるユーザＩＤを、仮ユーザＩＤテーブルに記録されている仮ユーザＩＤに読み替える。そして、認証支援手段は、仮ユーザＩＤ及び仮パスワードを含めたログイン要求を認証管理サーバ３０に転送する。この
場合には、認証管理サーバ３０の制御部３１は、読み替えられたユーザＩＤ及び仮パスワードによりログイン認証を行なう。ログイン認証を完了した場合、認証管理サーバ３０は、仮ユーザＩＤの権限により、サーバ１１へのアクセスを許可する。この場合も、ログ管理システムは、仮ユーザＩＤにおける操作ログの記録処理を実行する。
【０１１８】
一方、仮ユーザＩＤテーブルにユーザＩＤが登録されておらず、仮ユーザＩＤが設定されていない場合（ステップＳ１０−２において「ＮＯ」の場合）、動的権限管理サーバ５０の制御部５１は、通常の認証要求処理を実行する（ステップＳ１０−４）。具体的には、制御部５１の認証支援手段は、サーバ１１から取得したユーザＩＤ及びパスワードを含めたログイン要求を認証管理サーバ３０に転送する。この場合、認証管理サーバ３０の制御部３１は、転送されたユーザＩＤ及びパスワードによりログイン認証を行なう。ここでも、ログイン認証を完了した場合、認証管理サーバ３０は、ユーザＩＤの権限により、サーバ１１へのアクセスを許可する。なお、「無効化」されているユーザＩＤの場合には、アクセスは許可されないことになる。
【０１１９】
・ 上記各実施形態において、複数の実施形態を組み合わせて、本発明の権限制御システムを構成するようにしてもよい。
また、上記各実施形態において、監視サーバ２０、認証管理サーバ３０、動的権限管理サーバ５０等を用いて、アクセス権限を管理したが、このアクセス権限を管理するためのハードウェア構成は、上述の構成に限定されるものではない。例えば、認証管理サーバ３０と動的権限管理サーバ５０を、同一のコンピュータシステム内の機能として動作させてもよい。
【０１２０】
・ 上記各実施形態では、障害が発生したサーバ１１毎に、グループＩＤ「管理者」に属するユーザＩＤを有効化する。有効化の範囲はサーバ１１に限定されるものではない。例えば、障害が発生した監視対象システム１０毎に、アクセス権限を有効化するようにしてもよい。
【０１２１】
・ 上記各実施形態では、障害発生通知を受信した動的権限管理サーバ５０の制御部５１は、障害発生サーバについて登録された担当者の特定処理を実行する（ステップＳ１−４）。具体的には、制御部５１の担当者特定手段５１１は、認証管理サーバ３０にアクセスし、権限管理データベース３２において、障害が発生した監視対象システム１０についてグループＩＤ「管理者」に属するユーザＩＤを検索する。この場合、ユーザＩＤを検索するデータベースは、認証管理サーバ３０内の権限管理データベース３２に限定されるものではない。例えば、権限管理データベース３２と同じデータベースを動的権限管理サーバ５０内に設けておき、このデータベースを用いて、ユーザＩＤを検索するようにしてもよい。
【０１２２】
・ 上記各実施形態では、障害復旧時処理により、ユーザＩＤのアカウント状態を無効化して復元する。ユーザＩＤのアカウント状態の復元は、システムの復旧時に限定されるものではない。例えば、システムやサーバが復旧してから基準時間経過後に、ユーザＩＤのアカウント状態を無効化するようにしてもよい。障害復旧後に、再度、サーバやシステムにログインして稼動状態を確認する場合もある。この場合にも所定期間においては、ユーザＩＤを利用してアクセスすることができる。
【０１２３】
・ 上記各実施形態では、障害発生時にユーザＩＤを有効化するとともに、障害復旧時に無効化する場合を説明した。ユーザＩＤの有効化や無効化は、障害時に限定されるものではない。例えば、システム開発の状況に応じて、ユーザＩＤを有効化や無効化するようにしてもよい。具体的には、システム管理サーバから、「開発中」、「本番運用中」等のフェーズ情報を取得する。そして、「開発中」フェーズにおいては、グループＩＤ「開発
担当者」に属するユーザＩＤを有効化するとともに、グループＩＤ「運用担当者」に属するユーザＩＤを無効化する。一方、「本番運用中」フェーズにおいては、グループＩＤ「開発担当者」に属するユーザＩＤを無効化するとともに、グループＩＤ「運用担当者」に属するユーザＩＤを有効化する。
【０１２４】
・ 上記各実施形態では、監視対象システム１０を構成するサーバ１１についてのアクセス権限を動的に制御したが、制御対象はこれらに限定されるものではない。例えば、ネットワーク機器やストレージ装置についてのアクセス権限を制御するようにしてもよい。
【０１２５】
・ 上記各実施形態では、権限管理データベース３２に記録されている権限管理テーブル３２０により、有効化するユーザＩＤを特定する。この権限管理テーブル３２０は、担当者毎に、グループＩＤ、ユーザＩＤ、パスワード、アクセス許可ホスト、アカウント状態に関する権限管理レコードが記録されている。アクセス権限を特定するためのデータ構造は、これに限定されるものではない。例えば、図１１に示すように、グループ管理テーブル３２５、ユーザＩＤ管理テーブル３２６を用いることも可能である。このグループ管理テーブル３２５には、グループＩＤに対して、このグループに属するユーザＩＤが登録されている。また、ユーザＩＤ管理テーブル３２６には、ユーザＩＤに対して、アクセス許可ホスト情報が登録されている。そして、「管理者」権限が付与されたグループに属するユーザＩＤを検索することで、アカウント状態を変更するユーザＩＤを特定することができる。
【符号の説明】
【０１２６】
１０…監視対象システム、２０…監視サーバ、２１…制御部、２１１…障害監視手段、２１２…障害発生通知手段、２１３…障害復旧通知手段、２２…担当者管理データベース、２３…障害履歴データベース、３０…認証管理サーバ、３１…制御部、３２…権限管理データベース、４０…クライアント端末、５０…動的権限管理サーバ、５１…制御部、５１１…担当者特定手段、５１２…権限設定手段、５２…障害管理データベース。
【特許請求の範囲】
【請求項１】
監視対象装置の稼動状態を監視する監視システムと、監視対象装置について各担当者に付与可能なアクセス権限を管理する認証管理システムとに接続された制御手段を備えた権限制御システムであって、
前記制御手段が、
前記監視システムから、監視対象装置における障害状況に関する情報を取得した場合、前記認証管理システムに接続し、前記障害を検知した監視対象装置についてのアクセス権限を付与可能な担当者を特定する手段と、
前記認証管理システムに対して、前記障害を検知した監視対象装置について、前記特定した担当者のアクセス権限を付与する指示を行なう権限付与手段と、
前記監視システムから、前記障害を検知した監視対象装置の正常稼動に関する情報を取得した場合には、前記認証管理システムに対して、前記障害を検知した監視対象装置について付与したアクセス権限を取り消す指示を行なう権限取消手段と
を備えたことを特徴とする権限制御システム。
【請求項２】
前記権限取消手段は、前記障害を検知した監視対象装置について付与したアクセス権限に関連付けられたすべての監視対象装置の正常稼動に関する情報を取得した場合に、前記認証管理システムに対して、前記監視対象装置について付与したアクセス権限を取り消す指示を行なうことを特徴とする請求項１に記載の権限制御システム。
【請求項３】
監視対象装置に対して、この装置に関連する関連装置情報が登録された監視対象情報記憶手段を更に備え、
前記権限付与手段は、前記監視対象情報記憶手段を用いて、障害を検知した監視対象装置の関連装置を特定し、
前記認証管理システムにおいて、障害を検知した監視対象装置及び前記関連装置についてのアクセス権限を付与可能な担当者を特定し、
前記認証管理システムに対して、前記特定した担当者のアクセス権限を付与する指示を行なうことを特徴とする請求項１又は２に記載の権限制御システム。
【請求項４】
障害状況に対応させて権限レベルが登録された権限レベル情報記憶手段を更に備え、
前記権限付与手段は、
前記権限レベル情報記憶手段を用いて、検知した障害状況に応じた権限レベルを特定し、
前記認証管理システムにおいて、この権限レベルのアクセス権限を付与する指示を行なうことを特徴とする請求項１〜３のいずれか一つに記載の権限制御システム。
【請求項５】
監視対象装置の稼動状態を監視する監視システムと、監視対象装置について各担当者に付与可能なアクセス権限を管理する認証管理システムとに接続された制御手段を備えた権限制御システムを用いて権限制御を行なう方法であって、
前記制御手段が、
前記監視システムから、監視対象装置における障害状況に関する情報を取得した場合、前記認証管理システムに接続し、前記障害を検知した監視対象装置についてのアクセス権限を付与可能な担当者を特定する段階と、
前記認証管理システムに対して、前記障害を検知した監視対象装置について、前記特定した担当者のアクセス権限を付与する指示を行なう権限付与段階と、
前記監視システムから、前記障害を検知した監視対象装置の正常稼動に関する情報を取得した場合には、前記認証管理システムに対して、前記障害を検知した監視対象装置について付与したアクセス権限を取り消す指示を行なう権限取消段階と
を備えたことを特徴とする権限制御方法。
【請求項６】
監視対象装置の稼動状態を監視する監視システムと、監視対象装置について各担当者に付与可能なアクセス権限を管理する認証管理システムとに接続された制御手段を備えた権限制御システムを用いて権限制御を行なうためのプログラムであって、
前記制御手段を、
前記監視システムから、監視対象装置における障害状況に関する情報を取得した場合、前記認証管理システムに接続し、前記障害を検知した監視対象装置についてのアクセス権限を付与可能な担当者を特定する手段、
前記認証管理システムに対して、前記障害を検知した監視対象装置について、前記特定した担当者のアクセス権限を付与する指示を行なう権限付与手段、
前記監視システムから、前記障害を検知した監視対象装置の正常稼動に関する情報を取得した場合には、前記認証管理システムに対して、前記障害を検知した監視対象装置について付与したアクセス権限を取り消す指示を行なう権限取消手段
として機能させることを特徴とする権限制御プログラム。
【請求項１】
監視対象装置の稼動状態を監視する監視システムと、監視対象装置について各担当者に付与可能なアクセス権限を管理する認証管理システムとに接続された制御手段を備えた権限制御システムであって、
前記制御手段が、
前記監視システムから、監視対象装置における障害状況に関する情報を取得した場合、前記認証管理システムに接続し、前記障害を検知した監視対象装置についてのアクセス権限を付与可能な担当者を特定する手段と、
前記認証管理システムに対して、前記障害を検知した監視対象装置について、前記特定した担当者のアクセス権限を付与する指示を行なう権限付与手段と、
前記監視システムから、前記障害を検知した監視対象装置の正常稼動に関する情報を取得した場合には、前記認証管理システムに対して、前記障害を検知した監視対象装置について付与したアクセス権限を取り消す指示を行なう権限取消手段と
を備えたことを特徴とする権限制御システム。
【請求項２】
前記権限取消手段は、前記障害を検知した監視対象装置について付与したアクセス権限に関連付けられたすべての監視対象装置の正常稼動に関する情報を取得した場合に、前記認証管理システムに対して、前記監視対象装置について付与したアクセス権限を取り消す指示を行なうことを特徴とする請求項１に記載の権限制御システム。
【請求項３】
監視対象装置に対して、この装置に関連する関連装置情報が登録された監視対象情報記憶手段を更に備え、
前記権限付与手段は、前記監視対象情報記憶手段を用いて、障害を検知した監視対象装置の関連装置を特定し、
前記認証管理システムにおいて、障害を検知した監視対象装置及び前記関連装置についてのアクセス権限を付与可能な担当者を特定し、
前記認証管理システムに対して、前記特定した担当者のアクセス権限を付与する指示を行なうことを特徴とする請求項１又は２に記載の権限制御システム。
【請求項４】
障害状況に対応させて権限レベルが登録された権限レベル情報記憶手段を更に備え、
前記権限付与手段は、
前記権限レベル情報記憶手段を用いて、検知した障害状況に応じた権限レベルを特定し、
前記認証管理システムにおいて、この権限レベルのアクセス権限を付与する指示を行なうことを特徴とする請求項１〜３のいずれか一つに記載の権限制御システム。
【請求項５】
監視対象装置の稼動状態を監視する監視システムと、監視対象装置について各担当者に付与可能なアクセス権限を管理する認証管理システムとに接続された制御手段を備えた権限制御システムを用いて権限制御を行なう方法であって、
前記制御手段が、
前記監視システムから、監視対象装置における障害状況に関する情報を取得した場合、前記認証管理システムに接続し、前記障害を検知した監視対象装置についてのアクセス権限を付与可能な担当者を特定する段階と、
前記認証管理システムに対して、前記障害を検知した監視対象装置について、前記特定した担当者のアクセス権限を付与する指示を行なう権限付与段階と、
前記監視システムから、前記障害を検知した監視対象装置の正常稼動に関する情報を取得した場合には、前記認証管理システムに対して、前記障害を検知した監視対象装置について付与したアクセス権限を取り消す指示を行なう権限取消段階と
を備えたことを特徴とする権限制御方法。
【請求項６】
監視対象装置の稼動状態を監視する監視システムと、監視対象装置について各担当者に付与可能なアクセス権限を管理する認証管理システムとに接続された制御手段を備えた権限制御システムを用いて権限制御を行なうためのプログラムであって、
前記制御手段を、
前記監視システムから、監視対象装置における障害状況に関する情報を取得した場合、前記認証管理システムに接続し、前記障害を検知した監視対象装置についてのアクセス権限を付与可能な担当者を特定する手段、
前記認証管理システムに対して、前記障害を検知した監視対象装置について、前記特定した担当者のアクセス権限を付与する指示を行なう権限付与手段、
前記監視システムから、前記障害を検知した監視対象装置の正常稼動に関する情報を取得した場合には、前記認証管理システムに対して、前記障害を検知した監視対象装置について付与したアクセス権限を取り消す指示を行なう権限取消手段
として機能させることを特徴とする権限制御プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２０１１−２１０１９０（Ｐ２０１１−２１０１９０Ａ）
【公開日】平成２３年１０月２０日（２０１１．１０．２０）
【国際特許分類】
【出願番号】特願２０１０−７９７２９（Ｐ２０１０−７９７２９）
【出願日】平成２２年３月３０日（２０１０．３．３０）
【出願人】（５９２１３１９０６）みずほ情報総研株式会社 (187)
【Ｆターム（参考）】
【公開日】平成２３年１０月２０日（２０１１．１０．２０）
【国際特許分類】
【出願日】平成２２年３月３０日（２０１０．３．３０）
【出願人】（５９２１３１９０６）みずほ情報総研株式会社 (187)
【Ｆターム（参考）】
[ Back to top ]