JP2023107599A - インシデント管理装置、及びインシデント管理方法 - Google Patents

Abstract

【課題】発生したリソースの障害の復旧に必要な適切なアクセス権限の設定を行うインシデント管理装置及びインシデント管理方法を提供する。【解決手段】インシデント管理システムにおいて、インシデント管理サーバ３００は、複数のリソース１１５を記憶しており、各リソース１１５へのアクセスが可能なユーザの情報を含む情報であるアクセス権限管理情報１１９に基づき各リソース１１５へのアクセスを管理しているサーバ装置から、複数のリソース１１５のいずれかに発生した障害の情報を受信する障害情報受信部３２１と、障害の情報を受信した場合に、サーバ装置における障害が発生したリソースにアクセスするユーザ及び当該ユーザのアクセス権限を特定するアクセス権限情報特定部３２２と、特定したユーザ及びアクセス権限の情報をアクセス権限管理情報１１９に設定するアクセス権限管理情報設定部３２３と、を備える。【選択図】図１

Description

本発明は、インシデント管理装置、及びインシデント管理方法に関する。

インターネット上でコンピュータ資源を貸し出すクラウドサービスが様々な事業者から提供されている。顧客の要望や顧客が保有するデータの保存場所等にあわせて、任意のクラウドシステム又はオンプレミス環境における、アプリケーションのデプロイ及びその運用を可能とすることが求められている。

Kubernetes等のアプリケーション実行環境においては、アプリケーションのリソースに発生した障害への対応状況はインシデントとして、インシデント管理システムで管理されることが一般的である。この場合、発生した障害からの回復作業を担当するユーザ（障害対応ユーザ）に対して、アプリケーションの安全性確保のため、当該リソースへの適切なアクセス権限の管理を行うことは必須である。

例えば、特許文献１には、障害監視システムにおいて、監視サーバが、監視対象システムから稼動情報を取得し、障害発生と判定した場合、障害発生を通知し、障害発生通知を受信した動的権限管理サーバが、障害発生サーバについて登録された作業担当者を特定し、認証管理サーバに対して、特定されたユーザＩＤの有効化を指示し、障害復旧通知を受信した動的権限管理サーバが、認証管理サーバに対して、障害発生サーバについて一時的に有効化したユーザＩＤの無効化を指示する技術が開示されている。また、非特許文献１、２には、業務管理サービスが開示されている。

特開２０１１－２１０１９０号公報

"Redmine"，[online]，［令和３年（２０２１年）１１月２６日検索］，インターネット（URL: https://www.redmine.org/） "ServiceNow"，[online]，［令和３年（２０２１年）１１月２６日検索］，インターネット（https://www.servicenow.com/）

特許文献１、非特許文献１、及び非特許文献２の管理システムないし管理サービスにおいて開示されている技術では、リソースへのアクセス権限の設定をする場合、現在のアプリケーションのリソースのアクセス権限の内容と、最新の障害対応ユーザの情報とを一致させる必要がある。しかしながら、両者の情報の不一致が頻繁に発生する場合、両者の監視が常時必要となるため、アクセス権限の管理コストが増大する。

本発明は、このような現状に鑑みてなされたものであり、その目的は、発生したリソースの障害の復旧に必要な適切なアクセス権限の設定が可能なインシデント管理装置、及びインシデント管理方法を提供することを目的とする。

上記課題を解決するための本発明の一つは、プロセッサ及びメモリを有し、複数のリソ
ースを記憶しており、各前記リソースへのアクセスが可能なユーザの情報を含む情報であるアクセス権限管理情報に基づき前記各リソースへのアクセスを管理しているサーバ装置から、前記複数のリソースのいずれかに発生した障害の情報を受信する障害情報受信部と、前記障害の情報を受信した場合に、前記サーバ装置における前記障害が発生したリソースにアクセスするユーザ及び当該ユーザのアクセス権限を特定するアクセス権限情報特定部と、前記特定したユーザ及びアクセス権限の情報を前記アクセス権限管理情報に設定するアクセス権限管理情報設定部とを備える、インシデント管理装置とする。

また、上記課題を解決するための本発明の一つは、情報処理装置が、複数のリソースを記憶しており、各前記リソースへのアクセスが可能なユーザの情報を含む情報であるアクセス権限管理情報に基づき前記各リソースへのアクセスを管理しているサーバ装置から、前記複数のリソースのいずれかに発生した障害の情報を受信する障害情報受信処理と、前記障害の情報を受信した場合に、前記サーバ装置における前記障害が発生したリソースにアクセスするユーザ及び当該ユーザのアクセス権限を特定するアクセス権限情報特定処理と、前記特定したユーザ及びアクセス権限の情報を前記アクセス権限管理情報に設定するアクセス権限管理情報設定処理とを実行する、インシデント管理方法とする。

本発明によれば、発生したリソースの障害の復旧に必要な情報を適時に設定することができる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

本実施形態に係るインシデント管理システム１の構成及びインシデント管理システムが行う処理の概要を説明する図である。 ユーザテーブルの一例を示す図である。 ロールテーブルの一例を示す図である。 アプリケーション実行基盤テーブルの一例を示す図である。 ログテーブルの一例を示す図である。 インシデントテーブルの一例を示す図である。 リソース管理者テーブルの一例を示す図である。 各情報処理装置が備えるハードウエア構成の一例を示す図である。 インシデント情報追加処理の一例を説明するフローチャートである。 アクセス権限管理情報取得処理の一例を説明するフローチャートである。 インシデント情報更新処理の一例を説明するフローチャートである。 アクセス権限管理情報更新処理の一例を説明するフローチャートである。 インシデント管理画面の一例を示す図である。

以下、図面を参照しつつ、本発明の一実施形態を説明する。
図１は、本実施形態に係るインシデント管理システム１の構成及びインシデント管理システム１が行う処理の概要を説明する図である。

＜構成＞
インシデント管理システム１は、アプリケーション実行サーバ１００、アプリケーション監視サーバ２００、インシデント管理サーバ３００、管理者端末５０１、及びユーザ端末５０２を含んで構成される。これらの間は、例えば、インターネット、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、又は専用線等の有線又は無線の通信ネ
ットワークにより通信可能に接続される。

アプリケーション実行サーバ１００は、後述するアプリケーション実行基盤１１０により、各種のアプリケーションを実行する情報処理装置である。

アプリケーション監視サーバ２００は、アプリケーション実行基盤１１０の各アプリケーションの動作及び障害の発生を監視する情報処理装置である。

インシデント管理サーバ３００は、アプリケーション監視サーバ２００が検知したアプリケーションの障害（以下、インシデントという）に対する対応を支援する情報処理装置である。

管理者端末５０１は、インシデント管理システム１を管理する管理者が使用する情報処理装置である。本実施形態では、管理者は、アプリケーションを記憶している後述のリソース１１５ごとに存在しているものとする（以下、各管理者をリソース管理者という）。リソース管理者は、そのリソースに関する全てのアクセス権限を有しているものとする。なお、管理者端末５０１は、リソース管理者ごとに複数設けられてもよい。

ユーザ端末５０２は、アプリケーション実行基盤１１０で発生した障害からの復旧業務を担当する各ユーザ（以下、担当ユーザという）が使用する情報処理装置である。各担当ユーザは、ユーザ端末５０２を使用してアプリケーション実行サーバ１００にアクセスすることで、障害に対する対応及び復旧等を実施する。ユーザ端末５０２は、担当ユーザごとに複数設けられてもよい。

次に、アプリケーション実行サーバ１００は、１又は複数のアプリケーション実行基盤１１０を記憶している。アプリケーション実行基盤１１０は、例えば、Kubernetesである。アプリケーション実行基盤１１０は、リソース領域１１４に格納されているアプリケーションのリソースの稼働、リソースの管理、リソース管理者及び担当ユーザの管理、並びにリソースへのアクセス権限の管理等を行うプログラムである。

具体的には、アプリケーション実行基盤１１０は、アプリケーション実行基盤１１０にアクセスする担当ユーザの認証を行うユーザ認証プログラム１１１と、担当ユーザ及びリソース管理者（以下、担当ユーザ及びリソース管理者を「ユーザ」と総称する）のアカウント情報の作成、更新、及び削除等を実行するユーザ管理プログラム１１２と、リソース領域１１４へのアクセス権限を管理するリソースアクセス権限管理プログラム１１３と、リソース領域１１４と、リソース領域１１４の構成を管理するリソース管理プログラム１１６とを備える。

リソース領域１１４は、１又は複数の記憶領域（以下、ネームスペースともいう）からなる。各ネームスペース（リソース領域１１４ａ、ｂ、・・・）は、アプリケーションを記憶し実行するための単位であるリソース１１５を１つ以上有する。すなわち、リソース１１５は、例えばコンテナ、サービス、仮想マシン等の記憶領域の単位である。

リソースアクセス権限管理プログラム１１３は、リソース領域１１４の各リソース１１５にアクセス可能な担当ユーザの情報であるアクセス権限管理情報１１９を管理している。リソース１１５の各プログラムは、各ユーザがアクセスしてきた場合、アクセス権限管理情報１１９に基づき実行の可不可を判定し、実行可と判定した場合に、そのプログラムを実行する。

アクセス権限管理情報１１９は、本実施形態では、各ユーザのユーザＩＤ、そのユーザがアクセス可能なリソース、及び、そのリソースに対するアクセス権限の具体的内容（書き込み、参照等）の情報を含むものとするが、これらの情報以外の情報が含まれていても
よい。

リソース管理プログラム１１６は、担当ユーザ（ユーザ端末５０２）又はリソース管理者（管理者端末５０１）からの、リソース１１５に対する所定の操作命令を受信し、当該リソース１１５に対し各種の処理を実行させる。

次に、アプリケーション実行サーバ１００は、以下に説明するユーザテーブル及びロールテーブルを記憶し、各ユーザのリソースへのアクセス権限を管理している。ユーザテーブル及びロールテーブルは、例えば、ユーザ認証プログラム１１１の実行に際して参照される。

（ユーザテーブル）
図２は、ユーザテーブル１１７の一例を示す図である。ユーザテーブル１１７は複数のレコードを有し、各レコードは、各ユーザのＩＤが設定されるユーザＩＤ１１７１、そのユーザのパスワードをハッシュ化した文字列の情報が設定されるパスワードハッシュ文字列１１７２、及び、そのユーザに割り当てられた、リソース１１５へのアクセス権限（ロール）の情報が設定されるロールＩＤ１１７３の各データ項目を有する。ロールの具体的内容は、以下のロールテーブル１１８で定義されている。

（ロールテーブル）
図３は、ロールテーブル１１８の一例を示す図である。ロールテーブル１１８は複数のレコードを有し、各レコードは、ロールのＩＤが設定されるロールＩＤ１１８１、そのロールが対象とするリソースの情報が設定されるリソース１１８２、及び、そのリソースへのアクセス権限の具体的内容の情報が設定されるアクセス権限１１８３の各データ項目を有する。

同図の例では、「ロールＡ１」及び「ロールＡ２」は、「ネームスペースＡ」に含まれる全リソースがアクセス権限の設定の対象である。また、「ロールＡ１」は、各リソースに対して全てのアクセス権限を有する（「*」）。「ロールＡ２」は、リソースを参照す
る権限のみを有する（「get, list, watch」）。

次に、図１に示すように、アプリケーション監視サーバ２００は、アプリケーション監視プログラム２１０を備える。アプリケーション監視プログラム２１０は、アプリケーション実行基盤１１０で稼働しているアプリケーションのリソース状態を監視する。

インシデント管理サーバ３００は、インシデント管理プログラム３１０を備える。インシデント管理プログラム３１０は、インシデントに関する情報の作成、更新、及び削除等を実行する。インシデント管理プログラム３１０は、アプリケーション実行基盤１１０にアクセスするユーザの情報の作成を実行する。また、インシデント管理プログラム３１０は、リソースアクセス権限管理プログラム１１３を呼び出し、アクセス権限管理情報１１９を設定又は更新する。

具体的には、インシデント管理プログラム３１０は、障害情報受信部３２１、アクセス権限情報特定部３２２、アクセス権限管理情報設定部３２３、及び画面表示部３２４を有する。

障害情報受信部３２１は、アクセス権限管理情報１１９に基づき各リソース１１５へのアクセスを管理しているアプリケーション実行基盤１１０から、リソース１１５のいずれかに発生した障害の情報（障害情報）を受信する。

アクセス権限情報特定部３２２は、アプリケーション実行基盤１１０において障害が発生したリソース１１５にアクセスするユーザ（障害対応ユーザ）及び当該障害対応ユーザのアクセス権限を特定する。

アクセス権限管理情報設定部３２３は、アクセス権限情報特定部３２２が特定した障害対応ユーザ及びアクセス権限の情報をアクセス権限管理情報１１９に設定する。

画面表示部３２４は、インシデント、及びアクセス権限管理情報１１９等の各種の情報を画面に表示する。

さらに、インシデント管理サーバ３００は、次述するアプリケーション実行基盤テーブル、ログテーブル、インシデントテーブル、及びリソース管理者テーブルの各データベースを記憶している。

（アプリケーション実行基盤テーブル）
図４は、アプリケーション実行基盤テーブル３１１の一例を示す図である。アプリケーション実行基盤テーブル３１１は１又は複数のレコードを有する。各レコードは、インシデント管理プログラム３１０がアクセスする各アプリケーション実行基盤１１０のＩＤが設定されるアプリケーション実行基盤ＩＤ３１１１、そのアプリケーション実行基盤１１０のアクセス権限管理情報１１９の管理を行うプログラム（例えば、ＡＰＩ：Application Programming Interfaceとして提供されるリソースアクセス権限管理プログラム１１３
）のエンドポイントの情報（例えば、ＵＲＬ）が設定されるＡＰＩエンドポイント３１１２、及び、ユーザ情報自動削除３１１３の各データ項目を有する。

ユーザ情報自動削除３１１３には、障害対応ユーザによるリソース１１５の復旧が完了した場合に、アプリケーション実行基盤１１０のアクセス権限管理情報１１９におけるその障害対応ユーザの情報を削除するか否かを示す情報が設定される。本実施形態では、ユーザ情報自動削除３１１３が”ｔｒｕｅ”である場合、障害対応ユーザの情報は削除され、”ｆａｌｓｅ”である場合、障害対応ユーザの情報は削除されない。

（ログテーブル）
図５は、ログテーブル３１２の一例を示す図である。ログテーブル３１２は１又は複数のレコードを有する。各レコードは、アプリケーション監視プログラム２１０から送信された、インシデント（障害）の内容を記録したログ情報のＩＤが設定されるログＩＤ３１２１、及び、アプリケーション監視プログラム２１０から送信されたログ情報の内容（ログファイルのテキスト情報等）が格納されるログ内容３１２２の各データ項目を有する。

ログ情報には、例えば、障害が発生したリソース、障害の種類、リソースの種類、又はそのリソースに関連する他のリソースの情報が含まれる。

（インシデントテーブル）
図６は、インシデントテーブル３１３の一例を示す図である。インシデントテーブル３１３は、後述するインシデント管理画面３１５によりリソース管理者がデータ入力を行って作成することができる。

インシデントテーブル３１３は１又は複数のレコードを有する。各レコードは、インシデントのＩＤが設定されるインシデントＩＤ３１３１、そのインシデントの情報を記録したログ情報のＩＤが設定されるログＩＤ３１３２、そのインシデントが発生したアプリケーション実行基盤１１０のＩＤが設定されるアプリケーション実行基盤ＩＤ３１３３、そのインシデントが発生したリソースのＩＤが設定されるリソースＩＤ３１３４、そのイン
シデントの復旧作業を担当する障害対応ユーザによる現在の対応状況に関する情報（以下、状態情報という）が設定される状態３１３５、その障害対応ユーザのユーザＩＤが設定されるユーザＩＤ３１３６、及び、そのインシデントに係るリソースに対して設定するアクセス権限の内容を示す情報（以下、アクセス権限情報という）が設定されるリソースアクセス権限設定情報３１３７の各データ項目を有する。なお、同図には示していないが、各レコードには日時の情報が設定されている。

状態３１３５には、レコードの作成時（インシデントの検出時）に「新規」が自動的に設定される。その後、そのインシデントに対応する障害対応ユーザが決定された場合（又は変更された場合）には、リソース管理者（管理者端末５０１）が、状態３１３５に「対応中」を設定する。さらにその後、その障害対応ユーザによる対応が完了した場合には、リソース管理者（管理者端末５０１）が、状態３１３５に「完了」を設定する。なお、状態３１３５への「対応中」又は「完了」の設定は、インシデント管理プログラム３１０が障害対応ユーザの決定又は障害の対応完了を検知して自動的に行ってもよい。

ユーザＩＤ３１３６には、レコードの作成時（インシデントの検出時）には情報が設定されないが、その後、障害対応ユーザが決定された場合（又は変更された場合）には、リソース管理者（管理者端末５０１）が、状態３１３５にその障害対応ユーザのＩＤを設定する。なお、インシデント管理プログラム３１０は、障害対応ユーザの決定又は変更を検知して障害対応ユーザのＩＤを自動的に設定してもよい。

リソースアクセス権限設定情報３１３７には、例えば、障害対応ユーザのユーザＩＤ、インシデントが発生したリソースのリソースＩＤ、及び、そのリソースに対するアクセス権限の情報（get, list, watch等）が格納される。

（リソース管理者テーブル）
図７は、リソース管理者テーブル３１４の一例を示す図である。リソース管理者テーブル３１４は複数のレコードを有し、各レコードは、リソース管理者のユーザＩＤが設定されるユーザＩＤ３１４１、そのリソース管理者が担当するアプリケーション実行基盤１１０のＩＤが設定されるアプリケーション実行基盤ＩＤ３１４２、及び、そのリソース管理者が担当するリソースのＩＤが設定されるリソースＩＤ３１４３の各データ項目を有する。

＜処理の概要＞
次に、インシデント管理システム１が行う処理の概要について説明する。図１に示したように、まず、アプリケーション監視サーバ２００のアプリケーション監視プログラム２１０は、アプリケーション実行サーバ１００が検知した、リソース１１５（アプリケーション）で発生した障害に関する情報（以下、障害情報という）を、アプリケーション実行サーバ１００から受信する（Ｆ１０１）。

アプリケーション監視サーバ２００は、受信した障害情報に基づき、その障害をインシデントとして通知するインシデント通知をインシデント管理サーバ３００に送信し、インシデント管理サーバ３００のインシデント管理プログラム３１０は、このインシデント通知を受信する（Ｆ１０２）。

インシデント管理プログラム３１０は、受信したインシデント通知に基づき、障害の復旧を要求する情報（以下、インシデント情報という）を作成する。インシデント管理プログラム３１０は、作成したインシデント情報を管理者端末５０１に送信する（Ｆ１０３）。その後、管理者端末５０１のリソース管理者は、管理者端末５０１が受信したインデント情報に基づき、適切な障害対応ユーザを特定する業務を行う。管理者端末５０１は、リ
ソース管理者が特定した障害対応ユーザの情報をインシデント管理サーバ３００に送信する（Ｆ１０４）。なお、管理者端末５０１は、障害対応ユーザの特定を検知してその障害対応ユーザの情報をインシデント管理サーバ３００に自動的に送信してもよい。

また、インシデント管理プログラム３１０は、アプリケーション実行基盤１１０に、特定された障害対応ユーザ及びそのアクセス権限に関する情報を含む要求情報（以下、設定要求という）を送信する（Ｆ１０５）。アプリケーション実行基盤１１０のユーザ管理プログラム１１２及びリソースアクセス権限管理プログラム１１３は、受信した設定要求に基づき、障害対応ユーザ、リソース、及びアクセス権限等の情報を、アクセス権限管理情報１１９に設定する。

さらに、インシデント管理プログラム３１０は、特定された障害対応ユーザが管理するユーザ端末５０２に、障害の復旧等の対応を依頼する旨の情報（以下、復旧依頼情報という）を送信する（Ｆ１０６）。

当該ユーザ端末５０２は、復旧依頼情報を受信するとその内容を画面に表示し、これにより障害対応ユーザは、障害の復旧作業の必要性を認知する。そして、この障害対応ユーザの操作によりユーザ端末５０２は、ユーザ認証プログラム１１１の認証を通じてアプリケーション実行基盤１１０にログインする。ユーザ端末５０２は、インシデントが発生したリソース１１５（このリソース１１５に対するアクセス権限は、前記のＦ１０５によりアクセス権限管理情報１１９に設定されている）に対する操作命令を、リソース管理プログラム１１６に送信する（Ｆ１０７）。リソース管理プログラム１１６は、受信した操作命令に従って、上記リソース１１５に対する操作を実施する。これにより、障害発生リソースにおける障害が解消し、復旧作業は完了する。

ここで、図８は、アプリケーション実行サーバ１００、アプリケーション監視サーバ２００、インシデント管理サーバ３００、管理者端末５０１、及びユーザ端末５０２の各情報処理装置が備えるハードウエア構成の一例を示す図である。各情報処理装置は、CPU(Central Processing Unit)、DSP(Digital Signal Processor)、GPU(Graphics Processing Unit)、FPGA(Field-Programmable Gate Array)等の処理装置９１（プロセッサ）と、ROM(Read Only Memory)、RAM(Random Access Memory)等の主記憶装置９２（メモリ）と、HDD(Hard Disk Drive)、SSD(Solid State Drive)などの補助記憶装置９３と、１以上の通信規
格（例えば、ＩＥＥＥ８０２．３）に対応する通信インタフェースである通信装置９４とを備える。また、各情報処理装置は、マウスやキーボード等で構成される入力装置９５、又は、液晶ディスプレイまたは有機EL（Electro-Luminescence）ディスプレイ等で構成される出力装置９６を備えていてもよい。

各情報処理装置の各機能は、処理装置９１が、主記憶装置９２又は補助記憶装置９３に格納されているプログラムを読み出して実行することにより実現される。またこのプログラムは、例えば、記録媒体に記録して配布することができる。なお、各情報処理装置は、処理装置９１及び主記憶装置９２の組み合わせの代わりに、書き換え可能な論理回路であるＦＰＧＡ（Field Programmable Gate Array）や特定用途向け集積回路であるＡＳＩＣ
（Application Specific Integrated Circuit）により実現されてもよい。また各情報処
理装置は、処理装置９１及び主記憶装置９２の組み合わせの代わりに、異なる構成の組み合わせ、たとえばＣＰＵ、ＲＯＭ、ＲＡＭ、及びＦＰＧＡの組み合わせにより実現されてもよい。
次に、インシデント管理サーバ３００が行う処理の詳細について説明する。

＜インシデント情報追加処理＞
図９は、インシデント情報追加処理の一例を説明するフローチャートである。インシデ
ント情報追加処理は、アプリケーション監視サーバ２００からのインシデント通知を受信して（Ｆ１０２）その情報をインシデントテーブル３１３に登録する処理である。インシデント情報追加処理は、例えば、インシデント管理サーバ３００の起動後繰り返し実行される。

インシデント管理サーバ３００のインシデント管理プログラム３１０は、アプリケーション監視サーバ２００からの、障害情報を含むインシデント通知の受信を待機している。なお、障害情報は、例えば、障害が発生したアプリケーション実行基盤１１０のアプリケーション実行基盤ＩＤ、リソースＩＤ、及び障害のログを含む。

インシデント通知を受信すると（Ｓ１０１）、インシデント管理プログラム３１０は、受信したインシデント通知の内容を、ログテーブル３１２に登録する（Ｓ１０２）。例えば、インシデント管理プログラム３１０は、ログテーブル３１２の、新規のログＩＤを設定した新たなレコードに、インシデント通知におけるログの内容を登録する。

また、インシデント管理プログラム３１０は、受信したインシデント通知の内容を、インシデントテーブル３１３に登録する（Ｓ１０３）。例えば、インシデント管理プログラム３１０は、インシデントテーブル３１３の、新規のインシデントＩＤを設定した新たなレコードに、ログＩＤと、インシデント通知におけるアプリケーション実行基盤ＩＤと、リソースＩＤとを設定する。また、インシデント管理プログラム３１０は、そのレコードの状態３１３５に「新規」を設定する。

インシデント管理プログラム３１０は、リソース管理者テーブル３１４を参照することで、インシデント通知が示す障害（以下、発生インシデントという）に係るリソース（以下、障害発生リソースという）のリソース管理者のユーザＩＤを特定する。インシデント管理プログラム３１０は、特定したリソース管理者に係る管理者端末５０１に、インシデントに関する情報を送信する（Ｓ１０４）。

例えば、インシデント管理プログラム３１０は、リソース管理者テーブル３１４を参照し、アプリケーション実行基盤ＩＤ３１４２及びリソースＩＤ３１４３に、インシデント通知におけるアプリケーション実行基盤ＩＤ及びリソースＩＤに対応する情報が設定されているレコードを特定し、そのレコードのユーザＩＤ３１４１の内容を取得する。インシデント管理プログラム３１０は、取得したユーザＩＤ３１４１に係るリソース管理者のメールアドレスに、Ｓ１０３で設定した情報（インシデントＩＤ、ログＩＤ、アプリケーション実行基盤ＩＤ、リソースＩＤ、及び状態情報）を送信する。以上でインシデント情報追加処理は終了する。

＜アクセス権限管理情報取得処理＞
図１０は、アクセス権限管理情報取得処理の一例を説明するフローチャートである。アクセス権限管理情報取得処理は、アプリケーション実行基盤１１０のアクセス権限管理情報１１９から障害発生リソースに関する情報を取得し、インシデントテーブル３１３に対して障害発生リソースへのアクセス権限の登録を行う処理である。アクセス権限管理情報取得処理は、例えば、インシデント情報追加処理の完了を契機として開始される。なお、アクセス権限管理情報取得処理は複数回繰り返し実行されてもよい。

インシデント管理プログラム３１０は、アプリケーション実行基盤１１０のアクセス権限管理情報１１９から、障害発生リソースにおける障害及びアクセス権限の情報（以下、障害発生リソース情報という）を取得する。具体的には、インシデント管理プログラム３１０は、リソースアクセス権限管理プログラム１１３を呼び出すことで、アクセス権限管理情報１１９から、障害発生リソースに関する部分（例えば、障害発生リソースを担当す
るとして登録されているユーザ又はリソース管理者のユーザＩＤ及びそのアクセス権限）を取得する（Ｓ２０１）。

インシデント管理プログラム３１０は、Ｓ２０１で取得した障害発生リソース情報に、障害発生リソースのリソース管理者以外のユーザのアクセス権の情報が含まれているか否かを確認する（Ｓ２０２）。

障害発生リソースのリソース管理者以外のユーザのアクセス権の情報が含まれている場合は（Ｓ２０２：Ｙｅｓ）、インシデント管理プログラム３１０は、Ｓ２０３の処理を実行し、障害発生リソースのリソース管理者以外のユーザのアクセス権の情報が含まれていない場合は（Ｓ２０２：Ｎｏ）、インシデント管理プログラム３１０は、Ｓ２０４の処理を実行する。

Ｓ２０３においてインシデント管理プログラム３１０は、インシデントテーブル３１３に、アクセス権限の情報を追加する。例えば、インシデント管理プログラム３１０は、インシデントテーブル３１３の、障害発生リソースに係るレコードのリソースアクセス権限設定情報３１３７に、Ｓ２０２で特定したリソース管理者以外のユーザに関する障害発生リソース情報（例えば、各ユーザのユーザＩＤ、障害発生リソースのリソースＩＤ、及びアクセス権限の情報）を追加する。以上でアクセス権限管理情報取得処理は終了する（Ｓ２０９）。

一方、Ｓ２０４においてインシデント管理プログラム３１０は、インシデントテーブル３１３から、障害発生リソースに係るインシデントと同種の過去のインシデントを検索する。例えば、インシデント管理プログラム３１０は、インシデントテーブル３１３のアプリケーション実行基盤ＩＤ３１３３の内容及びリソースＩＤ３１３４の内容が障害発生リソースのアプリケーション実行基盤ＩＤ及びリソースＩＤとそれぞれ同じであり、インシデントテーブル３１３のインシデントＩＤ３１３１の内容又はログＩＤ３１３２が示すログ情報の内容が同じ又は類似するレコードを検索する（なお、類似性の判断は、例えば文字列又は単語の類似性を判断する周知の技術等で行えばよい）。

障害発生リソースに係るインシデントと同種の過去のインシデントがある場合には（Ｓ２０４：Ｙｅｓ）、インシデント管理プログラム３１０は、Ｓ２０５の処理を実行し、障害発生リソースに係るインシデントと同種の過去のインシデントがない場合には（Ｓ２０４：Ｎｏ）、インシデント管理プログラム３１０は、Ｓ２０６の処理を実行する。

Ｓ２０５においてインシデント管理プログラム３１０は、Ｓ２０４で検索したインシデントのうち最新のインシデントを特定し、そのインシデントのアクセス権限情報を取得する。そして、インシデント管理プログラム３１０は、その情報をインシデントテーブル３１３に追加する（Ｓ２０３）。以上でアクセス権限管理情報取得処理は終了する（Ｓ２０９）。

例えば、インシデント管理プログラム３１０は、Ｓ２０４で検索したインシデントテーブル３１３のレコードのうち最新のレコードを特定し、特定したレコードのリソースアクセス権限設定情報３１３７の内容を取得する（Ｓ２０５）。インシデント管理プログラム３１０は、インシデントテーブル３１３の、障害発生リソースに係るレコードのリソースアクセス権限設定情報３１３７に、上記取得したリソースアクセス権限設定情報３１３７の内容を設定する（Ｓ２０３）。

一方、Ｓ２０６においてインシデント管理プログラム３１０は、障害発生リソースに関連するリソース（以下、関連リソースという）を検出し、障害発生リソース及び関連リソ
ースからなるリソース群の構成の特徴を特定する。

具体的には、インシデント管理プログラム３１０は、リソース間の参照及び被参照の関係、各リソースの環境情報に基づき、リソース構成の特徴を特定する。例えば、まず、インシデント管理プログラム３１０は、（１）障害発生リソースのコンテナ（例えば、Pod
）のイメージ名、（２）そのコンテナにアクセスするための環境情報（例えば、Secret、ConfigMap）の名称、及び（３）環境情報を参照するリソース（関連リソース）のコンテ
ナの全てのイメージ名を特定する。そして、インシデント管理プログラム３１０は、リソース構成の特徴として、例えば、環境情報及び関連リソースの数、種類、名称、及びデータ内容の類似性等を特定する（なお、類似性の判断は、例えば文字列又は単語の類似性を判断する周知の技術等で行えばよい）。

なお、リソース構成の特徴（関連リソース及び環境情報）の特定の方法は上記の方法に限定されない。例えば、インシデント管理プログラム３１０は、リソース及び環境情報の構成の特徴を定義したデータを予め作成しておいてもよい。また、インシデント管理プログラム３１０は、インシデントテーブル３１３の各レコードのログＩＤ３１３２からログ情報を取得し、取得したログ情報を解析してもよい。また、インシデント管理プログラム３１０は、アプリケーション実行サーバ１００が備える所定の管理プログラムを呼び出すことで特徴を特定してもよい。

インシデント管理プログラム３１０は、インシデントテーブル３１３から、Ｓ２０６で特定したリソース構成の特徴と同じ特徴のリソース構成を有する他のリソース群を検索し、そのリソース群における、障害発生リソースに対応するリソースを検索する（Ｓ２０７）。

例えば、インシデント管理プログラム３１０は、Ｓ２０６で特定した、リソースの参照被参照の関係及び環境情報と同じ関係及び環境情報を有するリソース群を全て検索し、検索した各リソース群における、障害発生リソースに対応するリソースを特定する。そして、インシデント管理プログラム３１０は、特定したリソースの情報が設定されているインシデントテーブル３１３のレコードを全て検索する。なお、インシデント管理プログラム３１０は、同じ参照被参照の関係及び環境情報だけでなく、一定の類似関係にある参照被参照の関係及び環境情報を有するリソース群を検索してもよい。

Ｓ２０７でリソースを検索できなかった場合は（Ｓ２０７：Ｎｏ）、アクセス権限管理情報取得処理は終了する（Ｓ２０９）。

一方、Ｓ２０７でリソースを検索できた場合は（Ｓ２０７：Ｙｅｓ）、インシデント管理プログラム３１０は、Ｓ２０８、Ｓ２０３の処理を実行する。

例えば、インシデント管理プログラム３１０は、Ｓ２０６で検索したレコードのリソースアクセス権限設定情報３１３７の内容を取得する（Ｓ２０８）。インシデント管理プログラム３１０は、インシデントテーブル３１３の、障害発生リソースに係るレコードのリソースアクセス権限設定情報３１３７に、上記取得したリソースアクセス権限設定情報３１３７の内容を設定する（Ｓ２０３）。以上でアクセス権限管理情報取得処理は終了する（Ｓ２０９）。

＜インシデント情報更新処理＞
図１１は、インシデント情報更新処理の一例を説明するフローチャートである。インシデント情報更新処理は、リソース管理者からの入力に基づき、インシデントテーブル３１３のレコード内容を修正又は更新する処理である。インシデント情報更新処理は、例えば
、インシデントテーブル３１３の作成後、繰り返し実行される。

インシデント管理サーバ３００のインシデント管理プログラム３１０は、インシデントＩＤが付帯した、（リソース管理者等により決定された）障害対応ユーザのユーザＩＤ、障害対応ユーザの状態情報（例えば、「対応中」又は「完了」）、又は障害対応ユーザのアクセス権限の情報のいずれかの管理者端末５０１からの受信を待機する（Ｓ３０１）。なお、インシデント管理プログラム３１０は、これらの情報の入力を直接リソース管理者等から受け付けてもよい。

インシデント管理プログラム３１０は、上記情報を受信すると（又は入力されると）（Ｓ３０１）、受信した情報に基づきインシデントテーブル３１３を更新する（Ｓ３０２）。

例えば、インシデント管理プログラム３１０は、Ｓ３０１で受信した情報に付帯するインシデントＩＤに基づき、更新するインシデントテーブル３１３のレコードを特定する。インシデント管理プログラム３１０は、特定したレコードのユーザＩＤ３１３６、状態３１３５、又はリソースアクセス権限設定情報３１３７を、Ｓ３０１で受信した情報で更新する。以上でインシデント情報更新処理は終了する。

＜アクセス権限管理情報更新処理＞
図１２は、アクセス権限管理情報更新処理の一例を説明するフローチャートである。アクセス権限管理情報更新処理は、インシデントテーブル３１３の更新を契機に、アプリケーション実行基盤１１０のアクセス権限管理情報１１９を更新する処理である。

インシデント管理サーバ３００のインシデント管理プログラム３１０は、所定のタイミング（例えば、所定の時間間隔（１０秒ごと）、所定の時刻）で、インシデントテーブル３１３のレコードの更新を監視する（Ｓ４０１）。なお、インシデントテーブル３１３のレコードの更新は、例えば、インシデント情報追加処理、アクセス権限管理情報取得処理、又はインシデント情報更新処理により行われる。

インシデント管理プログラム３１０は、インシデントテーブル３１３の更新を検知すると、その更新内容を特定する。

インシデント管理プログラム３１０は、その更新内容が、障害対応ユーザによる復旧の開始であるか否かを判定する（Ｓ４０２）。例えば、インシデント管理プログラム３１０は、ユーザＩＤ３１３６にユーザの情報（障害対応ユーザの情報）が既に設定又はその後変更されており、かつ状態３１３５が「新規」から「対応中」に変更されたインシデントテーブル３１３のレコードがあるか否かを判定する。

更新内容が、障害対応ユーザによる復旧の開始である場合は（Ｓ４０２：Ｙｅｓ）、インシデント管理プログラム３１０は、Ｓ４０３の処理を実行し、更新内容が、障害対応ユーザによる復旧の開始でない場合は（Ｓ４０２：Ｎｏ）、インシデント管理プログラム３１０は、Ｓ４０６の処理を実行する。

Ｓ４０３において、インシデント管理プログラム３１０は、障害対応ユーザの障害発生リソースへのアクセス権限が設定されているか否かを判定する。例えば、インシデント管理プログラム３１０は、Ｓ４０２で特定したレコードのリソースアクセス権限設定情報３１３７に、Ｓ４０２の処理中に特定された障害対応ユーザのユーザＩＤが含まれているか否かを判定する。

障害対応ユーザのリソースへのアクセス権限が設定されている場合は（Ｓ４０３：Ｙｅｓ）、インシデント管理プログラム３１０はＳ４０４の処理を実行し、障害対応ユーザのリソースへのアクセス権限が設定されていない場合は（Ｓ４０３：Ｎｏ）、アクセス権限管理情報更新処理は終了する（Ｓ４０９）。

Ｓ４０４において、インシデント管理プログラム３１０は、インシデントテーブル３１３のアクセス権限情報を更新する。例えば、インシデント管理プログラム３１０は、Ｓ４０２で特定したレコードのリソースアクセス権限設定情報３１３７に設定されているアクセス権限情報の障害対応ユーザのユーザＩＤの部分を、そのレコードのユーザＩＤ３１３６の内容に設定する。

そして、インシデント管理プログラム３１０は、Ｓ４０４での更新内容の設定を要求する設定要求をアプリケーション実行基盤１１０に送信し（Ｓ４０５）、アクセス権限管理情報更新処理は終了する（Ｓ４０９）。

例えば、インシデント管理プログラム３１０は、Ｓ４０４で更新したリソースアクセス権限設定情報３１３７の内容（障害対応ユーザのＩＤ、リソース、及びアクセス権限等の情報）を含む設定要求を、アプリケーション実行基盤１１０に送信する。この場合、インシデント管理プログラム３１０は、当該レコードのアプリケーション実行基盤ＩＤ３１３３の情報及びアプリケーション実行基盤テーブル３１１に基づきエンドポイントを特定し、特定したエンドポイントを呼び出すことで、設定要求を送信する。

そして、アプリケーション実行基盤１１０のリソースアクセス権限管理プログラム１１３は、受信した設定要求におけるリソースアクセス権限設定情報３１３７の内容を、アクセス権限管理情報１１９に設定する。

一方、Ｓ４０６において、インシデント管理プログラム３１０は、インシデントテーブル３１３の更新内容が、障害対応ユーザによる復旧の完了であるか否かを判断する（Ｓ４０２）。例えば、インシデント管理プログラム３１０は、状態３１３５が「対応中」から「完了」に変更されたインシデントテーブル３１３のレコードがあるか否かを判定する。

インシデントテーブル３１３の更新内容が、障害対応ユーザによる復旧の完了である場合（Ｓ４０６：Ｙｅｓ）、インシデント管理プログラム３１０は、Ｓ４０７の処理を実行し、インシデントテーブル３１３の更新内容が、障害対応ユーザによる復旧の完了でない場合（Ｓ４０６：Ｎｏ）、アクセス権限管理情報更新処理は終了する（Ｓ４０９）。

Ｓ４０７において、インシデント管理プログラム３１０は、復旧を行った障害対応ユーザの情報をアプリケーション実行基盤１１０（アクセス権限管理情報１１９）から削除するか否かを判断する。例えば、インシデント管理プログラム３１０は、Ｓ４０６で特定されたレコードのアプリケーション実行基盤ＩＤ３１３３の内容を取得し、アプリケーション実行基盤テーブル３１１においてアプリケーション実行基盤ＩＤ３１３１に上記取得した内容が設定されているレコードのユーザ情報自動削除３１１３が”ｔｒｕｅ”であるかもしくは”ｆａｌｓｅ”であるかを確認する。

復旧を行った障害対応ユーザの情報を削除する場合は（Ｓ４０７：Ｙｅｓ）、インシデント管理プログラム３１０は、Ｓ４０８の処理を実行し、復旧を行った障害対応ユーザの情報を削除しない場合は（Ｓ４０７：Ｎｏ）、アクセス権限管理情報更新処理は終了する（Ｓ４０９）。

Ｓ４０８において、インシデント管理プログラム３１０は、アクセス権限管理情報１１
９における、復旧を行った障害対応ユーザの情報の削除の要求をアプリケーション実行基盤１１０に送信し（Ｓ４０５）、アクセス権限管理情報更新処理は終了する（Ｓ４０９）。

例えば、インシデント管理プログラム３１０は、Ｓ４０６で特定したレコードのユーザＩＤ３１３６に設定されている障害対応ユーザのＩＤの情報を含む削除要求を、アプリケーション実行基盤１１０に送信する。この場合、インシデント管理プログラム３１０は、上記レコードのアプリケーション実行基盤ＩＤ３１３３の情報に基づき、アプリケーション実行基盤テーブル３１１からエンドポイントを特定し、特定したエンドポイントを呼び出すことで、削除要求を送信する。

その後、アプリケーション実行基盤１１０のリソースアクセス権限管理プログラム１１３は、受信した削除要求に対応するアクセス権限管理情報１１９の部分を削除する。

（インシデント管理画面）
図１３は、インシデント管理画面３１５の一例を示す図である。インシデント管理画面３１５は、インシデントＩＤ、アプリケーション実行基盤ＩＤ、障害発生リソースのＩＤ、障害発生リソースのログＩＤの値の各表示欄３１６を備える。また、インシデント管理画面３１５は、状態情報（「新規」、「対応中」、「完了」）のユーザからの設定を受け付ける設定欄３１７を備える。さらに、インシデント管理画面３１５は、ユーザから、担当者及びリソースアクセス権限設定情報の入力を受け付ける入力欄３１８を備える。

以上説明したように、本実施形態のインシデント管理サーバ３００は、アクセス権限管理情報１１９に基づき各リソースへ１１５のアクセスが管理されているアプリケーション実行サーバ１００（アプリケーション実行基盤１１０）から、アプリケーション監視サーバ２００を介してリソース１１５の障害情報を受信し、障害が発生したリソース１１５にアクセスする障害対応ユーザ及び障害対応ユーザのアクセス権限を特定し、特定した障害対応ユーザの情報及びアクセス権限の情報を、アクセス権限管理情報１１９に設定する。

これにより、アプリケーション実行基盤１１０のリソース１１５で発生した障害（インシデント）の復旧を担当する障害対応ユーザ及び復旧作業に必要なアクセス権限の情報を、アプリケーション実行基盤１１０のアクセス権限管理情報１１９に反映することができる。これにより、障害対応ユーザは、障害が発生したアプリケーション実行基盤１１０のリソース１１５にアクセスし、障害を復旧することができる。

例えば、アプリケーション実行基盤１１０のアクセス権限管理情報１１９に登録されている障害対応ユーザが途中で変更された場合であっても、障害を復旧するにあたり、適切な障害対応ユーザの情報及びアクセス権限の情報をアクセス権限管理情報１１９に反映することができる。

以上のように、本実施形態のインシデント管理サーバ３００によれば、発生したリソースの障害の復旧に必要な適切なアクセス権限の設定が可能となる。そして、リソースの障害対応のためのアクセス権限の管理コストを低減することができる。

さらに、本実施形態のインシデント管理サーバ３００は、障害が解消したか否かを判断し、その障害が解消したと判断した場合に、アクセス権限管理情報１１９に設定した障害対応ユーザの情報を削除する。

これにより、障害が解消しリソースの修正が不要となったにも関わらず、障害対応ユーザによりリソース１１５が誤って改変されることを防ぐことができる。

また、本実施形態のインシデント管理サーバ３００は、アプリケーション実行サーバ１００（アプリケーション監視サーバ２００）から受信した障害情報に基づき、アクセス権限の情報を特定する。

これにより、アプリケーション実行サーバ１００（アプリケーション実行基盤１１０）の仕様及び運用に基づいた適切なアクセス権限の情報を特定することができる。

また、本実施形態のインシデント管理サーバ３００は、アプリケーション実行サーバ１００（アプリケーション監視サーバ２００）から過去に受信した障害情報に基づき、発生した障害に対応する障害を特定し、特定した障害の情報に基づき、アクセス権限の情報を特定する。

これにより、アプリケーション実行サーバ１００（アプリケーション実行基盤１１０）の過去の障害履歴に基づき、適切なアクセス権限の情報を特定することができる。

また、本実施形態のインシデント管理サーバ３００は、障害発生リソース及び関連リソースの関係性（リソース構成の特徴）を特定し、特定した関係性と同種の関係性を有するリソース群における、障害発生リソースに対応したリソースを特定し、特定したリソースと、過去に受信した障害情報とに基づき、アクセス権限の情報を特定する。

これにより、過去に障害発生リソースに障害が発生していなかったような場合でも、障害発生リソースと同様のリソース構成を有する他のリソースに基づいて、適切なアクセス権限を特定することができる。

また、本実施形態のインシデント管理サーバ３００は、障害発生リソースにアクセスするユーザの情報の入力をリソース管理者から受け付ける画面を表示することで、障害対応ユーザを特定する。

これにより、リソース管理者の判断に基づき、適宜な障害対応ユーザを設定することができる。

本発明は上記実施形態に限定されるものではなく、その要旨を逸脱しない範囲内で、任意の構成要素を用いて実施可能である。以上説明した実施形態や変形例はあくまで一例であり、発明の特徴が損なわれない限り、本発明はこれらの内容に限定されるものではない。また、上記では種々の実施形態や変形例を説明したが、本発明はこれらの内容に限定されるものではない。本発明の技術的思想の範囲内で考えられるその他の態様も本発明の範囲内に含まれる。

例えば、本実施形態の各装置が備える各機能の一部は他の装置に設けてもよいし、別装置が備える機能を同一の装置に設けてもよい。

１１５ リソース
１１９ アクセス権限管理情報
３００ インシデント管理サーバ
３２１ 障害情報受信部
３２２ アクセス権限情報特定部
３２３ アクセス権限管理情報設定部
３２４ 画面表示部

Claims (12)

1. プロセッサ及びメモリを有し、
   複数のリソースを記憶しており、各前記リソースへのアクセスが可能なユーザの情報を含む情報であるアクセス権限管理情報に基づき前記各リソースへのアクセスを管理しているサーバ装置から、前記複数のリソースのいずれかに発生した障害の情報を受信する障害情報受信部と、
   前記障害の情報を受信した場合に、前記サーバ装置における前記障害が発生したリソースにアクセスするユーザ及び当該ユーザのアクセス権限を特定するアクセス権限情報特定部と、
   前記特定したユーザ及びアクセス権限の情報を前記アクセス権限管理情報に設定するアクセス権限管理情報設定部と
   を備える、インシデント管理装置。
2. 前記アクセス権限管理情報設定部は、前記障害が解消したか否かを判断し、前記障害が解消したと判断した場合に、前記アクセス権限管理情報に設定した前記ユーザの情報を削除する、
   請求項１に記載のインシデント管理装置。
3. 前記アクセス権限情報特定部は、前記サーバ装置から受信した障害の情報に基づき、前記アクセス権限の情報を特定する、
   請求項１に記載のインシデント管理装置。
4. 前記アクセス権限情報特定部は、過去に受信した障害の情報に基づき、前記発生した障害に対応する障害を特定し、特定した障害の情報に基づき、前記アクセス権限の情報を特定する、
   請求項１に記載のインシデント管理装置。
5. 前記アクセス権限管理情報設定部は、前記障害が発生したリソース及び当該リソースに関連づけられている他のリソースの間の関係性を特定し、特定した関係性と同じ関係性を有するリソース群における、前記障害が発生したリソースに対応するリソースを特定し、特定したリソースと、過去に受信した前記障害の情報とに基づき、前記アクセス権限の情報を特定する、
   請求項１に記載のインシデント管理装置。
6. 前記アクセス権限情報特定部は、前記障害が発生したリソースにアクセスするユーザの情報の入力を受け付ける画面を表示することで、前記ユーザの情報を特定する、
   請求項１に記載のインシデント管理装置。
7. 情報処理装置が、
   複数のリソースを記憶しており、各前記リソースへのアクセスが可能なユーザの情報を含む情報であるアクセス権限管理情報に基づき前記各リソースへのアクセスを管理しているサーバ装置から、前記複数のリソースのいずれかに発生した障害の情報を受信する障害情報受信処理と、
   前記障害の情報を受信した場合に、前記サーバ装置における前記障害が発生したリソースにアクセスするユーザ及び当該ユーザのアクセス権限を特定するアクセス権限情報特定処理と、
   前記特定したユーザ及びアクセス権限の情報を前記アクセス権限管理情報に設定するアクセス権限管理情報設定処理と
   を実行する、インシデント管理方法。
8. 前記情報処理装置が、
   前記アクセス権限管理情報設定処理において、前記障害が解消したか否かを判断し、前記障害が解消したと判断した場合に、前記アクセス権限管理情報に設定した前記ユーザの情報を削除する、
   請求項７に記載のインシデント管理方法。
9. 前記情報処理装置が、
   前記アクセス権限情報特定処理において、前記サーバ装置から受信した障害の情報に基づき、前記アクセス権限の情報を特定する、
   請求項７に記載のインシデント管理方法。
10. 前記情報処理装置が、
    前記アクセス権限情報特定処理において、過去に受信した障害の情報に基づき、前記発生した障害に対応する障害を特定し、特定した障害の情報に基づき、前記アクセス権限の情報を特定する、
    請求項７に記載のインシデント管理方法。
11. 前記情報処理装置が、
    前記アクセス権限管理情報設定処理において、前記障害が発生したリソース及び当該リソースに関連づけられている他のリソースの間の関係性を特定し、特定した関係性と同じ関係性を有するリソース群における、前記障害が発生したリソースに対応するリソースを特定し、特定したリソースと、過去に受信した前記障害の情報とに基づき、前記アクセス権限の情報を特定する、
    請求項７に記載のインシデント管理方法。
12. 前記情報処理装置が、
    前記アクセス権限情報特定処理において、前記障害が発生したリソースにアクセスするユーザの情報の入力を受け付ける画面を表示することで、前記ユーザの情報を特定する、
    請求項７に記載のインシデント管理方法。

Images