リモートアクセス制御装置
【課題】業務情報システムへのアクセス規制を強化とアクセス内容の検証容易性を高める。
【解決手段】ユーザの操作に基づく制御命令の送信により管理対象装置のシステム操作を行う作業用端末と管理対象装置のそれぞれと接続されるリモートアクセス制御装置に関する。この装置は、システム操作により実行されるシステム作業の実行予定者の指定を含む作業申請情報を受信し、開発側承認者と運用側承認者に作業申請情報を送信する。システム作業の実行予定者の指定を含む作業実行要求を受信すると、作業実行要求に指定された実行予定者を対象とするメンテナンス作業が開発側承認者と運用側承認者のそれぞれにより承認済であることを条件として、作業用端末から送信される制御命令を管理対象装置に転送する。
【解決手段】ユーザの操作に基づく制御命令の送信により管理対象装置のシステム操作を行う作業用端末と管理対象装置のそれぞれと接続されるリモートアクセス制御装置に関する。この装置は、システム操作により実行されるシステム作業の実行予定者の指定を含む作業申請情報を受信し、開発側承認者と運用側承認者に作業申請情報を送信する。システム作業の実行予定者の指定を含む作業実行要求を受信すると、作業実行要求に指定された実行予定者を対象とするメンテナンス作業が開発側承認者と運用側承認者のそれぞれにより承認済であることを条件として、作業用端末から送信される制御命令を管理対象装置に転送する。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、通信ネットワークに接続される機器のシステム操作に関連し、特に、業務情報システムのメンテナンス作業に関する。
【背景技術】
【０００２】
企業や公共施設などの運用を支える業務情報システム、いわゆるエンタープライズシステム（Enterprise System）は、今や、大小さまざまな組織の基盤となっている。業務情報システムは、ノード端末やデータベースから得られるデータを集計、蓄積、解析、加工した上でより付加価値の高い情報を出力することにより、複雑化する組織マネジメントを支えている。
【０００３】
このような業務情報システムは、稼働後も、動作監視、障害対応、機能拡張や機能変更などのさまざまなメンテナンス作業を必要とする。通常、業務情報システムを導入するクライアント企業は、外部の管理会社や内部の別組織にこのメンテナンス作業を委託する。管理会社のＳＥ（System
Engineer）は、業務情報システムにリモートログインしてメンテナンス作業を行うことが多い。
【特許文献１】特開２００４−２１３４７５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ところで、近年、アメリカで成立したＳＯＸ（Sarbanes‐Oxley）法は、企業経営者や会計監査人に対して公開情報の正当性を保証するように強く求めている。これに倣って、日本でも日本版ＳＯＸ法が導入される予定であり、日本版ＳＯＸ法に対応できる態勢の確立が急務となっている。
【０００５】
このような社会背景に鑑みて、本発明者は、管理会社による業務情報システムへのリモートアクセスに着目し、業務情報システムへのアクセス規制の強化とアクセス内容の検証、特に、既定のルールや承認に基づいたアクセスが行われているかの検証が必要であると認識した。更に、その検証結果を利用することによりメンテナンス作業をいっそう効率化することができると想到した。
【０００６】
本発明は、本発明者の上記課題認識に基づいて完成された発明であり、その主たる目的は、通信ネットワークに接続される機器を遠隔地からシステム操作するときの情報セキュリティや作業内容の検証性を向上させるための技術、を提供することにある。
【課題を解決するための手段】
【０００７】
本発明のさらに別の態様もまた、ユーザの操作に基づく制御命令の送信により管理対象装置のシステム操作を行う作業用端末と管理対象装置のそれぞれと接続されるリモートアクセス制御装置である。
この装置は、システム操作により実行されるシステム作業の実行予定者の指定を含む作業申請情報を受信し、開発側承認者と運用側承認者に作業申請情報を送信する。
システム作業の実行予定者の指定を含む作業実行要求を受信すると、作業実行要求に指定された実行予定者を対象とするメンテナンス作業が開発側承認者と運用側承認者のそれぞれにより承認済であることを条件として、作業用端末から送信される制御命令を管理対象装置に転送する。
【０００８】
なお、ここでいうシステム操作とは、管理対象装置の障害対応、障害調査、定期検査等の保守・点検など、いわゆるメンテナンス作業としてのシステム作業を遠隔地から実行するための操作であってもよい。
【０００９】
本発明のさらに別の態様も、ユーザの操作に基づく制御命令の送信により管理対象装置のシステム操作を行う作業用端末と管理対象装置のそれぞれと接続されるリモートアクセス制御装置である。
この装置は、システム操作により実行されるシステム作業の実行予定者の指定を含む作業申請情報を受信し、申請されたシステム作業をその承認状態と共に作業予定情報に登録する。
システム作業の実行予定者の指定を含む作業実行要求を受信すると、指定された実行予定者を対象とするシステム作業が承認済であることを条件として、作業用端末から送信される制御命令を管理対象装置に転送する。ただし、あらかじめスケジュール化されているシステム作業については、承認済か否かに関わらず、作業用端末から送信される制御命令を管理対象装置に転送する。
【００１０】
なお、以上の構成要素の任意の組合せ、本発明を方法、システム、記録媒体、コンピュータプログラムにより表現したものもまた、本発明の態様として有効である。
【発明の効果】
【００１１】
本発明によれば、業務情報システムにおける情報セキュリティと作業内容の検証性を向上させることができる。
【発明を実施するための最良の形態】
【００１２】
図１は、リモートアクセス制御装置１００と各種業務情報システムとの関係を示すハードウェア構成図である。
同図に示す運用環境３００は、ある企業Ａの業務環境を示す。運用環境３００に属する人や装置等を以下においては「運用側」とよぶことにする。また、メンテナンス実行環境２００とは、ある企業Ｂの業務環境を示す。メンテナンス実行環境２００に属する人や装置等を以下においては「開発側」とよぶことにする。企業Ａにおいてはさまざまな業務情報システムが運用されており、それらのメンテナンス作業が企業Ｂに委託されている。すなわち、メンテナンス作業に関しては、企業Ａがクライアント側、企業Ｂがサービス側となる。以下においては、企業Ａのことを「委託側企業」、企業Ｂのことを「受託側企業」ともよぶ。証券会社や銀行、官公庁、交通機関などさまざまな企業が委託側企業となり得る。一方、受託側企業となるのは、いわゆるシステム・インテグレータ（System
Integrator）である。
【００１３】
企業Ａの運用環境３００は、財務情報システム３１０、顧客情報システム３１２、在庫管理システム３１４という３種類の業務情報システムと、１以上の運用側承認端末３２０を含む。財務情報システム３１０は、企業Ａの財務情報を管理するシステムである。顧客情報システム３１２は、企業Ａの顧客情報を管理するシステムである。在庫管理システム３１４は、企業Ａの商品の在庫状態を管理するシステムである。運用側承認端末３２０は、ウェブブラウザを搭載した一般的なＰＣ（Personal
Computer）端末である。運用側承認端末３２０は、必ずしも運用環境３００に属する必要はなく、ノートＰＣなどの携帯端末であってもよい。
【００１４】
メンテナンス実行環境２００は、作業用端末２０２ａ、２０２ｂ、２０２ｃ等の複数の作業用端末２０２と、１以上の開発側承認端末２０４を含む。作業用端末２０２や開発側承認端末２０４もウェブブラウザを搭載した一般的なＰＣ端末である。開発側承認端末２０４も、ノートＰＣなどの携帯端末であってもよい。
各業務情報システムは、リモートアクセス制御装置１００を介してインターネット３３０と接続される。また、作業用端末２０２や開発側承認端末２０４はインターネット３３０を介してリモートアクセス制御装置１００と接続される。
【００１５】
運用環境３００の各種業務システムは、稼働後も、適宜メンテナンス作業を受ける。このメンテナンス作業の中にはバックアップ用テープの交換作業のように、運用環境３００内で行われる作業もあるが、ほとんどは作業用端末２０２からのリモートアクセスにより実行される。このリモートのメンテナンス作業を行うユーザのことを、以下、単に「作業者」とよぶ。作業者は、通常、企業ＢのＳＥであることが多い。作業者はいずれかの作業用端末２０２を操作し、リモートアクセス制御装置１００にリモートログインする。そして、リモートアクセス制御装置１００が提供するユーザインタフェースを介して、目的の業務情報システムにアクセスする。いいかえれば、リモートアクセス制御装置１００は、各種業務情報システムへのアクセスを一元的に管理する。
なお、情報セキュリティ強化の面から、作業用端末２０２とリモートアクセス制御装置１００の間の通信経路は、ＶＰＮ（Virtual Private Network）などによりセキュアな通信経路であることが望ましい。
【００１６】
リモートアクセス制御装置１００は、作業用端末２０２からのリモートログイン要求を受け付ける。そして、以下の３段階の判定が共に肯定判定となったことを条件として、リモートログインを許可する。
１．作業者があらかじめ登録されているユーザであるか（以下、「ユーザ認証」とよぶ）
２．作業者がメンテナンス作業を実行することを事前に申請済みであるか（以下、「申請判定」とよぶ）
３．作業者が申請したメンテナンス作業が、開発側承認端末２０４を使用する承認者（以下、「開発側承認者」とよぶ）と運用側承認端末３２０を使用する承認者（以下、「運用側承認者」とよぶ）の両方により承認済であるか（以下、「承認判定」とよぶ）
以上のプロセスには例外もあるが、そのような例外も含めて詳細は後述する。まず、作業者によるメンテナンス作業の申請と承認に関して説明する。
【００１７】
図２は、作業の申請と承認についての処理過程を示すシーケンス図である。
作業者は、メンテナンス作業を実行する前に、作業予定日時や作業内容等を申請しなければならない。作業用端末２０２のユーザ、すなわち、作業者は、まず、リモートアクセス制御装置１００に作業申請のためのアクセスを行う（Ｓ１０）。リモートアクセス制御装置１００は、申請画面２５０用のＨＴＭＬ（Hyper
Text Markup Language）データを送信する（Ｓ１２）。申請画面２５０のユーザインタフェースに関しては図３に関連して後述する。
【００１８】
作業用端末２０２には申請画面２５０が表示される（Ｓ１４）。ユーザは、申請画面２５０に申請内容を示すデータを入力すると（Ｓ１６）、入力されたデータが作業申請情報としてリモートアクセス制御装置１００に送信される（Ｓ１８）。リモートアクセス制御装置１００は、この作業申請情報を、作業予定として作業予定情報に登録する（Ｓ２０）。作業予定情報のデータ構造については、図８に関連して後述する。リモートアクセス制御装置１００は、開発側承認端末２０４と運用側承認端末３２０のそれぞれに、電子メールを送信し、新たな作業申請がなされた旨を通知する（Ｓ２２、Ｓ２４）。
【００１９】
開発側承認端末２０４の開発側承認者は、承認可否を判断するためにリモートアクセス制御装置１００にアクセスする（Ｓ２６）。リモートアクセス制御装置１００は、開発側承認画面２７０のＨＴＭＬデータを送信する（Ｓ２８）。開発側承認画面２７０のユーザインタフェースに関しては図４に関連して後述する。開発側承認端末２０４には開発側承認画面２７０が表示される（Ｓ３０）。ユーザ、すなわち、開発側承認者が開発側承認画面２７０に承認可否を入力すると（Ｓ３２）、承認可否を示す開発側承認情報がリモートアクセス制御装置１００に送信される（Ｓ３４）。リモートアクセス制御装置１００は、この承認可否に応じて、申請された作業の承認状態を更新する（Ｓ３６）。
【００２０】
一方、運用側承認端末３２０の運用側承認者も、承認判断のためにリモートアクセス制御装置１００にアクセスする（Ｓ３８）。リモートアクセス制御装置１００は、運用側承認画面３４０のＨＴＭＬデータを送信し、運用側承認画面３４０を表示させる（Ｓ４０、Ｓ４２）。運用側承認画面３４０のユーザインタフェースに関しては図５に関連して後述する。ユーザ、すなわち、運用側承認者が運用側承認画面３４０に承認可否を入力すると（Ｓ４４）、承認可否を示す運用側承認情報がリモートアクセス制御装置１００に送信される（Ｓ４６）。リモートアクセス制御装置１００は、この承認可否に応じて、申請された作業の承認状態を更新する（Ｓ４８）。
こうして、作業の申請と、開発側承認者による承認（以下、単に「開発側承認」とよぶ）、運用側承認者による承認（以下、単に「運用側承認」とよぶ）がなされる。開発側承認者は受託側企業における責任者であり、運用側承認者は委託側企業における責任者である。したがって、開発側承認は受託側企業の立場から判断され、運用側承認は委託側企業の立場から判断されることになる。
【００２１】
より正確には、Ｓ１０、Ｓ２６、Ｓ３８においては、作業者、開発側承認者、運用側承認者のユーザＩＤとパスワードも送信される。リモートアクセス制御装置１００は、受信したユーザＩＤとパスワードが登録済みのものであるかユーザ認証を行い、このユーザ認証が成功しなければ申請画面２５０等のＨＴＭＬデータを送信しない仕組みとなっている。以下、ユーザＩＤやパスワードのようにユーザを一意に識別するための情報のことを「ユーザ識別情報」とよぶことにする。
【００２２】
なお、Ｓ２２やＳ２４のように能動的に作業申請を通知するのではなく、各承認者がリモートアクセス制御装置１００にアクセスしたときに承認待ちの作業申請を一覧表示させてもよい。承認者は、この一覧表の中から承認判断対象となる作業申請を選択し、開発側承認画面２７０や運用側承認画面３４０を表示させてもよい。
【００２３】
また、Ｓ１８において作業申請がなされたとき、リモートアクセス制御装置１００は、開発側承認端末２０４と運用側承認端末３２０の両方ではなく、いずれか一方、たとえば、開発側承認端末２０４にだけ通知してもよい。そして、開発側承認がなされたことを条件として、運用側承認端末３２０に通知してもよい。この場合、運用側承認者は、開発側承認がなされた作業申請についてだけ判断すればよいので、承認判断にともなう負荷が軽減されるという効果がある。
【００２４】
パスワードなどによるユーザ認証だけでアクセスを許す業務情報システムの場合、パスワードの漏洩はそのまま業務情報システムの危機に直結する。特許文献１はＩＤとパスワードによるユーザ認証に加えて、管理者によるアクセス承認を条件とするアクセスルールについて開示する。このようなアクセスルールは、業務情報システムへの不正アクセスを防止する上で有効な手法であるが、開発側承認者の立場からの判断しかなされていない。
【００２５】
しかし、開発側承認者が承認しても、運用側からみると作業予定日時が都合の悪い時間帯かもしれない。たとえば、処理負荷が高くなると予測される時間帯にメンテナンス作業まで実行されると、業務情報システム全体としての処理効率が大きく低下してしまう。本実施例におけるリモートアクセス制御装置１００によれば、運用側承認者にも承認権を付与することにより、このような状況にも適切に対処できる。すなわち、受託側と委託側という異なる立場からの多角的な承認判断が可能となっている。
次に、Ｓ１４の申請画面２５０、Ｓ３０の開発側承認画面２７０、Ｓ４２の運用側承認画面３４０について説明したあと、作業者がメンテナンス作業を実行するときの処理過程を説明する。
【００２６】
図３は、作業用端末２０２に表示される申請画面２５０を示す。
作業申請のためにリモートアクセス制御装置１００にアクセスすると、作業用端末２０２には同図に示す申請画面２５０が表示される。申請画面２５０は、作業用端末２０２にウェブページとして表示される。
【００２７】
作業者名欄２５２には、作業者名を選択形式にて入力する。たとえば、作業用端末２０２のユーザ「相野伸行」がリモートアクセス制御装置１００にログインしたときには、作業者名欄２５２には「相野伸行」が表示される。ユーザは、作業者名欄２５２にて別の作業者を指定することもできる。すなわち、「相野伸行」は、自分で作業を行うための申請のみならず、別の作業者のために代理として作業申請をすることもできる。
【００２８】
件名領域２５４には、作業申請の件名を入力する。システム名領域２５６には作業対象となる業務情報システムを指定し、ターゲット名領域２５８には作業の対象となるノード、すなわち、管理対象装置を指定する。同図においては、財務情報システム３１０（ＩＤ：０４）に含まれる複数の装置のうち、ウェブサーバ（ＩＤ：１４）が管理対象装置となっている。作業種別領域２６０は作業種別（作業ＩＤ）を示す。メンテナンス作業は、障害対応、調査、稼働監視、テスト、リリース作業・・・のようにその目的はさまざまである。メンテナンス作業は、このように複数の種別（以下、単に「作業種別」とよぶ）に分類される。ここでは、作業ＩＤ：０４のリリース作業、すなわち、ウェブサーバに搭載されるソフトウェアの更新作業が指定されている。開発側連絡領域２６２には開発側承認者への連絡事項、運用側連絡領域２６４には運用側承認者への連絡事項が自由記述形式にて入力される。作業日時領域２６６は作業予定日時を示す。
作業者は、申請画面２５０に示される各項目にデータを入力した後、申請ボタン２６８をクリックする。入力されたデータは作業申請情報としてリモートアクセス制御装置１００に送信される。リモートアクセス制御装置１００は、申請された作業に「申請ＩＤ」が付与し、作業予定情報に登録する。
【００２９】
図４は、開発側承認端末２０４に表示される開発側承認画面２７０を示す。
開発側承認端末２０４から承認判断のためにリモートアクセス制御装置１００にアクセスすると、開発側承認端末２０４には同図に示す開発側承認画面２７０が表示される。開発側承認画面２７０は、開発側承認端末２０４にウェブページとして表示される。
【００３０】
申請情報領域２７４には申請画面２５０において入力された申請内容の一部、いいかえれば、作業申請情報の一部が示されている。連絡事項領域２８４の表示内容は、申請画面２５０の開発側連絡領域２６２にて入力された内容に対応する。一方、申請画面２５０の運用側連絡領域２６４に入力された内容は申請情報領域２７４に表示されない。このように、作業申請情報のうち、開発側承認者の立場からみて判断に必要な情報だけが抽出されて表示される。このようなやり方によれば、作業申請情報の内容が複雑化したときにも、開発側承認者が申請内容を確認するときの手間を軽減できる。
【００３１】
また、関連情報領域２７２には、作業申請情報の一部として指定されていた「財務情報システム（０４）」の関連情報が表示されている。リモートアクセス制御装置１００は、このような様々な関連情報を保持している。ここでは、「財務情報システム（０４）」とは、「村野株式会社」という委託側企業で運用されるシステムであり、この会社は受託側企業からみて１９９８年から取引関係にあるという情報が関連づけられている。このように、リモートアクセス制御装置１００は、作業申請情報に含まれる情報についての関連情報のうち、開発側承認者の承認判断に資する関連情報を選択的に提供する。同図の場合、リモートアクセス制御装置１００は、作業対象の業務情報システムについて、「企業名」と「取引開始年」という関連情報を開発側承認者に提供するという設定がなされていることになる。
【００３２】
承認者名領域２７６には、開発側承認者の承認者名を入力する。通信欄２７８は、作業者に対する通信事項を入力する。承認ボタン２８０は承認用、却下ボタン２８２は却下用のボタンである。承認ボタン２８０か却下ボタン２８２のいずれかがクリックされると、承認者名領域２７６、通信欄２７８の記述内容と承認可否を示す開発側承認情報がリモートアクセス制御装置１００に送信される（図２のＳ３４）。通信欄２７８の内容は電子メールにて作業用端末２０２に送信されてもよい。
【００３３】
図５は、運用側承認端末３２０に表示される運用側承認画面３４０を示す。
運用側承認端末３２０から承認判断のためにリモートアクセス制御装置１００にアクセスすると、運用側承認端末３２０には同図に示す運用側承認画面３４０が表示される。運用側承認画面３４０は、運用側承認端末３２０にウェブページとして表示される。
【００３４】
申請情報領域３４４には、申請画面２５０において入力された申請内容の一部、いいかえれば、作業申請情報の一部が示される。連絡事項領域３４６の表示内容は、申請画面２５０の運用側連絡領域２６４に入力された内容に対応する。一方、申請画面２５０の開発側連絡領域２６２に入力された内容は、申請情報領域２７４には表示されない。また、申請情報領域３４４においては、実際にメンテナンス作業を行う作業者の名前も表示されない。委託側企業にとっては、いつ、どんな作業がなされるかという情報は重要であるが、誰が作業をするかはそれほど重要な情報ではないと考えられるからである。
【００３５】
関連情報領域３４２には、作業申請情報の一部として指定されていた「ウェブサーバ（１４）」の関連情報が表示されている。ここでは、「ウェブサーバ（１４）」には、「最大接続可能数」、「搭載しているＣＰＵ」、「所定期間における当該装置のＣＰＵの平均使用率」、「搭載しているメモリの大きさ」といった情報が関連づけられている。同図に示す例では、運用側承認者のために「ウェブサーバ（１４）」の関連情報が運用側承認画面３４０にて提供されている。
【００３６】
承認者名領域３４８は、運用側承認者の承認者名を入力するための領域である。通信欄３５０には、作業者に対する通信事項を記入する。承認ボタン３５２は承認用、却下ボタン３５４は却下用のボタンである。承認ボタン３５２か却下ボタン３５４のいずれかがクリックされると、承認者名領域３４８と通信欄３５０の内容と承認可否を示す運用側承認情報がリモートアクセス制御装置１００に送信される（図２のＳ４６）。通信欄３５０の内容は電子メールにて作業用端末２０２に送信されてもよい。
次に、実際にメンテナンス作業を開始するときの処理について説明する。
【００３７】
図６は、業務情報システムへのリモートログイン処理の過程を示すシーケンス図の一例である。
作業者が作業用端末２０２を操作して、リモートアクセス制御装置１００にアクセスすると、リモートアクセス制御装置１００はログイン画面を作業用端末２０２に表示させる。作業者は、ユーザ識別情報とアクセス先となる業務情報システムなどを指定して、作業実行要求をリモートアクセス制御装置１００に送信する（Ｓ５０）。リモートアクセス制御装置１００は、まず受信したユーザ識別情報を参照してユーザ認証を行う（Ｓ５２）。ユーザ認証に失敗すると（Ｓ５２のＮ）、アクセスは拒否され（Ｓ６２）、拒否の旨が作業用端末２０２に通知される（Ｓ６４）。ユーザ認証に成功すると（Ｓ５２のＹ）、次に、アクセス元のユーザが、現在日時を作業予定日時としてなんらかのメンテナンス作業を申請済みであるかについての判定、すなわち申請判定が実行される（Ｓ５４）。申請済みでなければ（Ｓ５４のＮ）、アクセスは拒否される（Ｓ６２）。
【００３８】
申請済であれば（Ｓ５４のＹ）、その作業申請が運用側承認済みか判定される（Ｓ５６）。運用側承認がなされていなければ（Ｓ５６のＮ）、アクセス拒否となる（Ｓ６２）。運用側承認済であれば（Ｓ５６のＹ）、開発側承認済みか判定される（Ｓ５８）。開発側承認がなされていなければ（Ｓ５８のＮ）、アクセス拒否となる（Ｓ６２）。開発側承認済でなければ（Ｓ５８のＹ）、アクセスは許可され（Ｓ６０）、その旨が作業用端末２０２に通知される（Ｓ６４）。
【００３９】
以上の処理過程を経て、作業者はリモートアクセス制御装置１００へリモートログインする。以後は、リモートアクセス制御装置１００が作業用端末２０２にユーザインタフェース画面を提供する。作業者は、このユーザインタフェース画面を介して業務情報システム、ひいては、管理対象装置にアクセスする。このアクセス用のプロトコルは、HttpやTelnet、Ftpなどの既知の通信プロトコルであればよい。たとえば、リモートアクセス制御装置１００は、ＧＵＩ（Graphical
User Interface）にて管理対象装置のメンテナンス作業を行うための専用ウェブページを作業用端末２０２に表示させてもよい。あるいは、専用ＣＵＩ（Character-based
User Interface）画面にて管理対象装置にコマンドを送信してもよい。
このように作業用端末２０２のユーザインタフェース画面に対する操作により、リモートアクセス制御装置１００が操作される。たとえば、ウェブページ上のボタンやエディットボックスに対する入力がなされると、作業用端末２０２はその入力内容に応じた操作データをリモートアクセス制御装置１００に転送する。リモートアクセス制御装置１００は、この操作データに対応する各種処理を行う。すなわち、作業用端末２０２からリモートアクセス制御装置１００に送信される操作データが、リモートアクセス制御装置１００を操作するための制御命令となる。
【００４０】
ＧＵＩであれＣＵＩであれ、作業用端末２０２からリモートアクセス制御装置１００を経由して管理対象装置に各種コマンドを送信することによりメンテナンス作業が実行される。リモートアクセス制御装置１００は、このコマンドや管理対象装置からの応答をログ情報として記録する。また、リモートアクセス制御装置１００は、作業者による実際の画面操作を動画として記録してもよい。
リモートアクセス制御装置１００はログ情報を事後的に検証する機能を備えるが、ログ情報とその検証方法については、図９や図１０に関連して後述する。
【００４１】
なお、先述したように、開発側承認を前提として運用側承認がなされるという設計であれば、リモートログイン処理においてＳ５８の開発側承認の判定処理は不要となる。
【００４２】
図７は、リモートアクセス制御装置１００の機能ブロック図である。
ここに示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。
【００４３】
リモートアクセス制御装置１００は、ユーザインタフェース処理部１１０、データ処理部１５０およびデータ保持部１８０を含む。
【００４４】
ユーザインタフェース処理部１１０は、たとえば、作業用端末２０２や開発側承認端末２０４、運用側承認端末３２０に画面用データを送信し、これらの端末から各種データを受信する。また、各種業務情報システムに作業者からのコマンドを転送したり、各業務情報システムからのデータを受信して、作業用端末２０２に転送する。このようにユーザインタフェース処理部１１０は、業務情報システムにアクセスするためのユーザインタフェース全般を担当する。
データ処理部１５０は、ユーザインタフェース処理部１１０から取得されたデータを元にして各種のデータ処理を実行する。データ処理部１５０は、ユーザインタフェース処理部１１０とデータ保持部１８０の間のインタフェースの役割も果たす。
データ保持部１８０は、各種データを保持するための記憶領域である。
【００４５】
ユーザインタフェース処理部１１０：
ユーザインタフェース処理部１１０は、申請通信部１２０、作業通信部１３６および通知部１４０を含む。
申請通信部１２０は、開発側承認端末２０４や運用側承認端末３２０に対して、作業の申請・承認に関する通信を担当する。申請通信部１２０は、作業申請受信部１２２、承認受信部１２４および申請送信部１３０を含む。作業申請受信部１２２は、作業用端末２０２から作業申請情報を受信する（図２のＳ１８）。申請送信部１３０のうち、開発側申請送信部１３２は作業申請情報を開発側承認端末２０４に送信し（図２のＳ２８）、運用側申請送信部１３４は作業申請情報を運用側承認端末３２０に送信する（図２のＳ４０）。承認受信部１２４のうち、開発側承認受信部１２６は開発側承認情報を受信し（図２のＳ３４）、運用側承認受信部１２８は運用側承認情報を受信する（図２のＳ４６）。
作業通信部１３６は、作業用端末２０２からの作業実行要求を受信する。また、メンテナンス作業用のコマンドを受信し、管理対象装置に転送する。
通知部１４０は、リモートアクセス制御装置１００の処理結果に関する各種情報を作業用端末２０２等に通知する。通知部１４０のうちスキップ通知部１４２は後述する「スキップ承認」が実行された旨を開発側承認端末２０４に電子メール通知する。通知部１４０のうち検証通知部１４４は、ログ情報の解析結果を通知する。ログ情報の解析についても後述する。
【００４６】
データ保持部１８０：
データ保持部１８０は、作業予定保持部１８２、ログ保持部１８４、傾向保持部１８６、契約保持部１８８、スケジュール保持部１９０、関連情報保持部１９２およびユーザ情報保持部１９４を含む。
作業予定保持部１８２は、申請されたメンテナンス作業の実行予定を作業予定情報として保持する。作業予定情報のデータ構造については次の図８に関連して詳述する。ログ保持部１８４は、メンテナンス作業の実行に際して、作業用端末２０２から送信されるコマンドや、業務情報システムからの応答をログ情報として保持する。本実施例においては、ログ情報は作業者ごとに記録される。ログ情報については図９に関連して詳述する。
【００４７】
傾向保持部１８６は、メンテナンス作業の統計的な傾向を示す傾向情報を保持する。この傾向情報は、ログ情報を集計することにより生成される。傾向情報とは、たとえば、過去６ヶ月間において、月曜日の「１２：００〜１８：００」において、財務情報システム３１０のウェブサーバＡに対し、「メンテナンス作業がなされている時間の割合」、「送信コマンド総数」、「メンテナンス作業が実行される確率」など、さまざまな観点から集計される統計情報である。傾向情報については図１０（ａ）や図１０（ｂ）に関連しても後述する。
【００４８】
一般的には、委託側企業と受託側企業の間でＳＬＡ（Service Level Agreement）とよばれるメンテナンス契約が交わされる。ＳＬＡは、いわば、メンテナンス作業の品質保証契約である。
たとえば、あるウェブサーバのソフトウェアを更新するとき、すなわち、「リリース作業」を実行するときには、複数のウェブサーバ間で負荷分散を実行するロードバランサから、作業対象となるウェブサーバを外してから、ウェブサーバのサービスを停止させるという順番で作業がなされなければならない。また、あるウェブサーバについて３０分以上の稼働監視作業を毎週金曜日に実行しなければならないという契約内容も考えられる。契約保持部１８８はこのようなメンテナンス作業の質的・量的な実行条件を示すＳＬＡを実行条件情報として保持する。
また、内部統制の観点から、システム操作についての役割分担や業務フローが社内規定によって定められる場合もある。このような観点から、契約保持部１８８が保持する実行条件情報には、ＳＬＡに限らず社内規定に基づく実行条件が定められてもよい。
【００４９】
メンテナンス作業の中には、あらかじめ決められたスケジュールにて実行される定型的な作業もある。スケジュール保持部１９０は、メンテナンス作業の実行スケジュールとしてスケジュール情報を保持する。関連情報保持部１９２は、作業申請情報に含まれ得る各種データについて、関連情報を対応づけて保持する。関連情報については図４や図５に関連して説明した通りである。ユーザ情報保持部１９４は、ユーザＩＤとパスワードを対応づけた正規ユーザ情報を保持する。この正規ユーザ情報に登録されているユーザだけがユーザ認証をパスすることになる。
【００５０】
データ処理部１５０：
データ処理部１５０は、作業予定登録部１５２、作業記録部１５４、アクセス制御部１６０、承認判定部１６２、ユーザ認証部１７６および作業検証部１６４を含む。
作業予定登録部１５２は、申請されたメンテナンス作業を作業予定保持部１８２に登録する。作業申請がなされると、申請を一意に識別するための申請ＩＤが付与される。作業予定情報では、申請ＩＤ、作業予定日時、作業内容、作業者名、承認状態等が対応づけられる。したがって、開発側承認情報や運用側承認情報が受信されると、作業予定情報は更新される。作業記録部１５４は、メンテナンス作業の作業内容を記録する。作業記録部１５４のうちのログ記録部１５６はログ情報を記録し、傾向記録部１５８はログ情報を集計して傾向情報を生成し、傾向保持部１８６に記録する。
【００５１】
アクセス制御部１６０は、業務情報システムと作業用端末２０２の間のデータ送受の中継または遮断を行う。承認判定部１６２は、申請判定および承認判定を実行する。ユーザ認証部１７６は、正規ユーザ情報を参照してユーザ認証を実行する。アクセス制御部１６０は、ユーザ認証、申請判定、承認判定（開発側承認判定と運用側承認判定）を経て、アクセスの可否を設定する（図６のＳ６０やＳ６２を参照）。すなわち、メンテナンス実行環境２００から管理対象装置への通信経路の開閉を設定する。
【００５２】
作業検証部１６４は、ログ情報によりメンテナンス作業を事後的に検証する機能ブロックである。作業検証部１６４は、不正なアクセス、または、不正の疑いがあるアクセス等について異常を検出するための異常判定部１６６と、メンテナンス作業の実行結果に基づいて受託側企業の業務状態を検査するための状態判定部１７４を含む。状態判定部１７４の具体的な機能については後述する。
異常判定部１６６は、メンテナンス作業が作業申請された内容と適合しているかを判定する申請検証部１６８、メンテナンス作業が過去のアクセス傾向と適合しているかを判定する傾向判定部１７０、メンテナンス作業がＳＬＡに適合しているかを判定する契約検証部１７２を含む。これらの各機能についても詳細は後述する。
【００５３】
図８は、作業予定保持部１８２における作業予定情報のデータ構造図である。
申請ＩＤ欄２１０は、申請ＩＤを示す。作業予定登録部１５２は、作業申請情報が受信されると、一意の申請ＩＤを付与して作業予定情報に登録する。作業者ＩＤ欄２１２は、作業予定者のユーザＩＤを示す。申請日欄２１４は作業申請がなされた日付を示し、作業日時欄２１６は作業予定日時を示す。
【００５４】
開発側承認欄２１８は開発側承認についての状態を示し、承認状態欄２２０は承認済を「○」、未承認を「−」、却下を「×」として承認状態を、承認日時欄２２２は承認日時を示す。運用側承認欄２２４は運用側承認についての状態を示し、承認状態欄２２６は、承認済、未承認、却下のいずれかの承認状態を、承認日時欄２２８は承認日時を示す。
作業種別欄２３０は、作業種別を示す。システムＩＤ欄２３２は作業対象となる業務情報システムのＩＤを示し、ノードＩＤ欄２３４は管理対象装置、すなわち、メンテナンス作業の対象となるノードのＩＤを示す。
【００５５】
同図においては、「申請ＩＤ：１」においては、「作業種別：０１」という障害対応作業が申請されており、開発側承認者にも運用側承認者にも承認されている。「申請ＩＤ：２」のリリース作業は、運用側承認者により却下されている。「申請ＩＤ：３」の調査作業は、開発側承認者には承認されているが運用側承認者には未承認である。一方、「申請ＩＤ：４」のテスト作業は、運用側は承認済であるが開発側は未承認である。したがって、通常であれば、「申請ＩＤ：４」のテスト作業は、このままでは実行不可能であるが、所定の状況においては、開発側承認を待たずにメンテナンス作業を実行することができる。このように開発側承認を経ることなく運用側承認だけでメンテナンス作業を許可することを「スキップ承認」とよぶ。
【００５６】
運用側承認者としては、受託側企業から業務情報システムの運用現場に派遣されるＳＥか、あるいは、委託側企業のアドミニストレータなどが想定される。業務情報システムは、通常、年中無休２４時間体制で運用されるため、複数の運用側承認者が交代制で運用に対応している。したがって、運用側承認者は、作業申請を素早く検討しやすい立場にある。
これに対して、開発側承認者は、受託側企業における作業者の上司が想定される。したがって、開発側承認は、開発側承認者の勤務時間でなければ得られない可能性がある。
【００５７】
しかし、メンテナンス作業の中には、障害対応のように即時的な対応が求められる作業もある。このような場合にスキップ承認が有効である。スキップ承認がなされたときには、スキップ通知部１４２は開発側承認端末２０４に対してスキップ承認がなされた旨を電子メール等により事後的に通知する。本実施例においては、作業申請がなされたときに、その旨を開発側承認端末２０４と運用側承認端末３２０に通知するとして説明したが（図２のＳ２２やＳ２４）、先述したように承認者がリモートアクセス制御装置１００にアクセスしたときに承認待ちの作業を閲覧するという受動的な処理方法であってもよい。このような受動的な処理方法を採用する場合には、スキップ承認の通知は、開発側承認者の注意を喚起する上で特に有効である。
また、所定時間内に開発側承認者が承認を行わない場合には、開発側承認端末２０４にアラーム通知を行い、承認を義務付けてもよい。
【００５８】
スキップ承認が可能となる条件としては、
１．所定の作業種別についての申請であること、たとえば、障害対応のように緊急性の高いメンテナンス作業であること、
２．作業申請日時から作業の開始予定日時までの時間が所定時間以下であること、たとえば、緊急性の高いメンテナンス作業であること
３．作業申請時にスキップ承認を作業者が明示的に申請していること
４．あらかじめ指定された作業者による申請であること、たとえば、経験豊富で信頼できる作業者の申請であること
などについてのいずれか、または、それらの組み合わせが考えられる。
そのほかにも、開発側承認者に電話などによりあらかじめ承認を得ている旨を証明できる場合には、スキップ承認可能としてもよい。
【００５９】
なお、作業予定登録部１５２は、作業予定情報に登録されている作業のうち、作業予定日時を経過したメンテナンス作業や、すでに完了したメンテナンス作業を適宜、作業予定情報から抹消する。
【００６０】
図９は、ログ保持部１８４におけるログ情報のデータ構造図である。
本実施例においては、ログ情報は作業者ごとに別々のファイルとして作成される。アクセス日時欄２４０は、作業用端末２０２から業務情報システムに向けて送信されたコマンドをリモートアクセス制御装置１００が受信した日時を示す。コマンド欄２４２は送信されたコマンド名、ターゲット欄２４４はコマンドの送信先、メッセージ欄２４６は管理対象装置から出力されるメッセージを示す。このほかにも、コマンドのパラメータやアクセス先の業務情報システム名などが記録されてもよい。
なお、ログ記録部１５６は作業用端末２０２に表示された画面をビデオ情報として取得し、時刻情報や操作指示情報と対応付けて、ログ保持部１８４に記録することもできる。たとえば、リモートアクセス制御装置１００が作業用端末２０２のユーザインタフェース画面そのものを提供するモデルであれば、リモートアクセス制御装置１００は作業者のマウスの移動やクリックといった操作を動画として記録することができる。ただし、本明細書においては、このような動画記録機能については特に詳述しない。
【００６１】
同図に示すログ情報は、図８に示した「申請ＩＤ：２」のリリース作業に対応している。まず、作業者は２００６年１０月１４日の２：３５に、コマンドＡによりリモートアクセス制御装置１００にリモートログインしている。コマンドＡはログインコマンドである。２：３８には、「ノードＩＤ：１」のロードバランサにコマンドＢを送信し、「ノードＩＤ：４」の管理対象装置であるウェブサーバを管理対象から外している。コマンドＢは、ロードバランサの管理対象を変更するためのコマンドである。２：４０にロードバランサは、管理対象装置のリストからの除去を完了している。
以降においては、ウェブサーバの停止、モジュールの更新、再起動、複数種類のテスト実行、動作確認を経て、ウェブサーバは再びロードバランサに登録されている。以上のアクセスのあと、３：４５に作業者はコマンドＨにより、リモートアクセス制御装置１００からログアウトしている。
また、同日３：５０に作業者は再びリモートアクセス制御装置１００にログインしている。
【００６２】
どのようなコマンドがどのような順序で実行されているかにより、メンテナンス作業の作業種別をログ情報から判定できる。ＳＬＡに関連して説明したように、メンテナンス作業には作業種別に応じて特有の作業手順が設定されるからである。
あるいは、メンテナンス作業ごとに特有のコマンドを検出することにより、作業種別を特定することもできる。たとえば、モジュール更新のためのコマンドＤは、リリース作業に特有のコマンドである。したがって、ログインからログアウトまでの間に、コマンドＤが記録されているときには、リリース作業の実行があったことを事後的に推定できる。
【００６３】
このようなログ情報により、以下に示す３種類の観点から不正なアクセス、または、不正を疑われるアクセスが発生していないかが検証される。
１．作業申請に基づく検証（以下、「申請検証」とよぶ）
申請検証部１６８は、ログ情報に基づき、申請された作業内容と実際の作業内容が適合しているかを検証する。たとえば、申請されていた作業が調査作業であったのに、作業者がモジュール更新用コマンドを送信していれば、申請検証部１６８は異常検出する。あるいは、申請されていたメンテナンス作業について想定されるコマンド実行順序と、実際に実行されたメンテナンス作業におけるコマンドの順序が整合していなければ異常検出してもよい。作業予定日時においてリモートログインが発生していないときにや、作業の終了予定時刻を過ぎてもログアウトしていないときも異常検出となる。
【００６４】
２．ＳＬＡに基づく検証（以下、「契約検証」とよぶ）
従来、業務情報システムのメンテナンス作業において、ＳＬＡにおける実行条件が遵守されているかを確認することは困難であった。契約検証部１７２は、ログ情報に基づき、ＳＬＡに示された実行条件と実際の作業内容が適合しているかを検証する。たとえば、リリース作業については、ロードバランサから管理対象装置を外した上で作業にとりかかるように処理手順が定められているかもしれない。また、証券会社の業務情報システムであれば、ソフトウェアの更新が終わった後には、所定銘柄を対象とした買い注文、売り注文、約定確認についての動作確認が義務づけられるかもしれない。実行された作業におけるコマンドにおいてこのような手順が守られていなければ、契約検証部１７２は異常検出する。また、１ヶ月につき、所定のテスト作業を１０回以上実行しなければならないという契約内容であれば、契約検証部１７２は１ヶ月あたり実行されたテスト作業の回数が１０回未満であるときに異常検出する。
【００６５】
３．アクセス傾向に基づく検証（以下、「傾向検証」とよぶ）
業務情報システムに対するメンテナンス作業は、通常、営業時間外になされることが多く、アクセスの発生しやすい時間帯と発生しにくい時間帯がある。傾向記録部１５８は、このようなアクセス傾向を傾向情報として記録する。傾向判定部１７０は、傾向情報とログ情報を比較して、一般的なアクセス傾向とは異なるアクセスを異常検出する。傾向検証については、次の図９を参照しながら更に説明する。
【００６６】
いずれにしても、検証通知部１４４は、異常検出の内容を開発側承認端末２０４や運用側承認端末３２０に通知する。アクセス制御部１６０は、異常検出がなされた時点で、業務情報システムへの通信経路を強制的に遮断してもよい。
なお、作業者ごとではなく、複数の作業者についてのログ情報を１つのファイルにまとめて記録してもよい。また、管理対象装置ごとにログ情報を記録するとしてもよい。ログ情報の取り方についてはさまざまなバリエーションが考えられる。
【００６７】
図１０（ａ）は、傾向情報に基づいてアクセス量をグラフ化した図である。
本実施例においては、傾向情報は、曜日単位で集計され、更に、１日は、０：００〜６：００、６：００〜１２：００、１２：００〜１８：００、１８：００〜２４：００の４つの時間帯に区切られている。同図は、過去６ヶ月間において、ある管理対象装置Ｃに対して送信されたコマンド数の平均値を示す。同図によると、金曜日の１８：００〜２４：００という時間帯にもっとも多くのコマンドが送信されているが、月曜日の０：００〜１２：００という時間帯においてはコマンドは全く送信されていない。管理対象装置Ｃに対するアクセスは、水曜日の午前中と金曜日の夜から土曜日の朝に集中する傾向がある。
同図において、Ｔ２はアクセス量の上限検証値、Ｔ１は下限検証値を示す。
【００６８】
図１０（ｂ）は、ログ情報に基づいてアクセス量をグラフ化した図である。
同図では、過去１週間分のログ情報について、管理対象装置Ｃに送信されたコマンド数を示す。傾向情報にあわせて、傾向判定部１７０は、ログ情報を曜日ごとに分類し、更に１日を４つの時間帯に分割してアクセス量を集計している。
同図において、Ｖ２はアクセス量の上限検証値、Ｖ１は下限検証値を示す。
傾向判定部は、Ｔ１、Ｔ２、Ｖ１、Ｖ２に基づいて、以下の方法により傾向検証処理を行う。
【００６９】
傾向判定部１７０は、
１．傾向情報においてアクセス量がＴ２以上、かつ、ログ情報においてアクセス量がＶ１以下
２．傾向情報においてアクセス量がＴ１以下、かつ、ログ情報においてアクセス量がＶ２以上
となる時間帯が存在するかを検出する。上記１．は、通常はアクセス量が多い時間帯なのに、今週はメンテナンス作業が行われていない可能性がある時間帯を検出するための条件であり、上記２．は、通常はアクセス量が少ない時間帯に不正なアクセスが発生している可能性がある時間帯を検出するための条件である。
図１０（ａ）および図１０（ｂ）によると、上記１．の条件にあてはまるのは金曜日１８：００〜０：００、上記２．の条件にあてはまるのは水曜日１８：００〜０：００である。したがって、このような時間帯が存在すると、異常検出となる。
【００７０】
なお、すべてのコマンドではなく、特定種類のコマンド、たとえば、リモートログインコマンドだけを対象として傾向検証処理を実行してもよい。また、コマンドの量ではなく、特定種類のメンテナンス作業の実行回数に関して傾向検証してもよい。あるいは、特定の作業者や特定の業務情報システムに限った傾向検証であってもよい。ログインからログアウトまでの時間を作業時間として、各時間帯において作業時間が占める割合に基づき傾向検証を行ってもよい。また、曜日ごとではなく、日付ごとや月ごと、営業日と非営業日のような任意の時間帯区分にてアクセス傾向を集計してもよい。このように、メンテナンス作業が実行された時間帯におけるアクセス内容とその時間帯におけるアクセス傾向との適否については、さまざまな評価条件に基づいて判定できる。
【００７１】
図１１は、業務情報システムへのリモートログイン処理の過程を示すシーケンス図の別例である。
図６に示したように、作業用端末２０２からのアクセスは、ユーザ認証、申請判定および承認判定（開発側承認と運用側承認）という判定過程を経た上で許可される。しかし、先述したスキップ承認がなされてもよいし、定型的なメンテナンス作業については承認不要としてもよい。スケジュール保持部１９０のスケジュール情報には、このような定型的なメンテナンス作業が登録されている。スケジュール情報は、作業予定情報のデータ構造のうち、申請日欄２１４、開発側承認欄２１８、運用側承認欄２２４についての情報を含まないデータ構造となっている。
【００７２】
同図においてＳ５０〜Ｓ６４にて示す処理の内容は、図６において同一の符号を付した処理の内容と同等であるので、図６に示した処理との差異を中心として説明する。まず、ユーザ認証に成功すると（Ｓ５２）、アクセス制御部１６０は現在時刻においてその作業者を指定したメンテナンス作業がスケジュール情報に登録されているかを判定する（Ｓ７０）。もし、現在時刻を作業予定時刻とするメンテナンス作業がスケジュール情報に登録されていれば（Ｓ７０のＹ）、処理はＳ６０にスキップされ、アクセス許可設定となる。すなわち、定型的なメンテナンス作業については、作業者は作業申請をしなくても管理対象装置にアクセスすることができる。もちろん、スケジュール情報に指定されている管理対象装置とは異なる管理対象装置へのアクセスは許可されない。
変形例として、スケジュール保持部１９０に定型的なシステム操作作業がスケジュール情報として登録されている場合には、スケジュール情報に登録されている作業開始時刻の所定時間前になると、リモートアクセス制御装置１００の申請自動生成部（図示せず）が作業申請情報を自動的に生成してもよい。このような方法によっても、作業者が定型的な作業についての作業申請をしなくても管理対象装置にアクセス可能とすることができる。
【００７３】
また、作業申請済み（Ｓ５４のＹ）、かつ、運用側承認済（Ｓ５６のＹ）であって開発側承認が得られていなくても（Ｓ５８のＮ）、スキップ承認が可能なメンテナンス作業であれば（Ｓ７２のＹ）、スキップ通知部１４２がスキップ承認がなされて旨を開発側承認端末２０４に通知した上で（Ｓ７４）、アクセス許可設定となる（Ｓ６０）。なお、同図には示さなかったが、Ｓ５８において、開発側承認者が作業申請を既に却下している場合にはスキップ承認は実行され得ず、アクセス拒否設定となる（Ｓ６２）。
【００７４】
本実施例におけるリモートアクセス制御装置１００は、ログ情報に基づいて業務情報システムへのアクセスの正当性を検証するだけでなく、更に、受託側企業におけるメンテナンス作業の効率化のためにログ情報を解析する機能も備える。このようなログ情報の解析は、状態判定部１７４により実行される。状態判定部１７４によるログ情報の解析は、以下に示す観点から実行される。
【００７５】
１．同一の時間帯において複数の作業者により同一種別のメンテナンス作業が発生していないか
たとえば、木曜日の１８：００〜２０：００の時間帯において、作業者Ｄが管理対象装置Ｅ、作業者Ｆが管理対象装置Ｇ、作業者Ｈが管理対象装置Ｉに対するメンテナンス作業を実行しているとする。そして、これらのメンテナンス作業がいずれもテスト作業であったとする。このような状況においては、たとえば、作業者Ｄが３つの管理対象装置に対するテスト作業をまとめて行った方が作業効率が高くなると考えられる。
【００７６】
状態判定部１７４は、ログ情報、あるいは、ログ情報から生成される傾向情報を参照して、複数の作業者間で同じ作業が重複している時間帯があるか判定する。これは、複数の作業者についてのログ情報を比較することにより検出できる。所定数、たとえば、２以上の作業者についてのログ情報を参照し、同じ作業種別のメンテナンス作業が同一時間帯に発生していれば、検証通知部１４４はこのような時間帯や関連する作業者名、管理対象装置名、作業種別等を開発側承認端末２０４等に通知する。
受託側企業では、このような通知に基づいて、作業者間における役割分担を変更することにより、業務効率を向上させることができる。
【００７７】
２．メンテナンス作業の実行に要する時間が長くなりすぎていないか
通常、メンテナンス作業は処理手順が決まっているため、作業時間をある程度見積もることができる。状態判定部１７４は、ログ情報を参照して、作業時間が所定の上限時間を超えているメンテナンス作業を検出する。検証通知部１４４は、このようなメンテナンス作業の実行日時、作業者名、あるいは、ログ情報から抽出した作業内容等を開発側承認端末２０４に通知する。作業時間は、たとえば、ログインコマンドが入力されてからログアウトコマンドが入力されるまでの時間として計測されてもよい。
受託側企業では、このような通知に基づいて、どのような状況やどのような作業者についてのメンテナンス作業が非効率になっているかを判断できる。上限時間は、メンテナンス作業の種類に応じて設けられてもよいし、作業者ごとに設けられてもよい。たとえば、経験豊富な作業者であれば上限時間を短めに設定し、経験の浅い作業者については長めに上限時間を設定すれば、「その作業者のスキルを考慮するとしても、作業時間がかかりすぎているメンテナンス作業」を特定することができる。
【００７８】
３．同一種別のメンテナンス作業について、作業者による作業時間のばらつきがどの程度か
状態判定部１７４は、ログ情報や、ログ情報から生成される傾向情報に基づいて、所定作業、たとえば、テスト作業に要する作業時間が、作業者間でどの程度ばらついているかを指標化する。単純に、テスト作業についての作業者ごとの平均所要時間をリストにしてもよいし、作業者の経験年数や職位に応じて平均所要時間を分類してもよい。たとえば、職位が低いわりには平均所要時間の短い作業者を、昇進候補としてリストアップしてもよい。検証通知部１４４は、検証結果を開発側承認端末２０４に通知する。
受託側企業では、同じ作業を要するのに作業者によってどの程度の作業時間を要しているかにより、作業者ごとの時間単価を判断することもできる。また、テスト作業に要する作業時間が短い作業者、すなわち、テスト作業に慣れている作業者に優先的にテスト作業を担当させれば、受託側企業全体としての業務効率を向上させることができる。
【００７９】
４．作業を行う時間帯が偏っている作業者がいないか
状態判定部１７４は、ログ情報や、ログ情報から生成される傾向情報に基づいて、作業者ごとの作業時間帯を検出する。たとえば、作業者Ｊは、火曜日の午前中に作業が集中する傾向にあるとする。状態判定部１７４は、上限検証値Ｔ１やＶ１、下限検証値Ｔ２やＶ１に基づいて、特に負荷の高い時間帯や特に負荷の低い時間帯を特定する。検証通知部１４４は、作業者ごとにの作業時間帯に関する情報を開発側承認端末２０４に通知する。
受託側企業では、このような通知に基づいて、作業者Ｊの火曜日午前の作業の一部を別の時間帯にシフトさせることで、作業者Ｊの負荷を平準化させることができる。このようなデータは、運用スケジュールやＳＬＡの内容を見直す上でも客観的で有効な資料となるため、多忙なＳＥの労働環境改善にも資する。
【００８０】
更に、状態判定部１７４は、作業者Ｊが忙しい火曜日の午前中において、作業者Ｋによる作業があまり発生していないことを検出したとする。この場合には、作業者Ｊの火曜日午前の作業の一部を作業者Ｋに移管することにより、作業者間における負荷分散を行うことができる。
【００８１】
５．特定のメンテナンス作業に業務が偏っている作業者がいないか
通常、テスト作業だけを行っていれば、作業者はテスト作業に習熟することになる。しかし、その一方で、スキルが特定作業に偏ってしまう可能性がある。状態判定部１７４は、ログ情報や、ログ情報から生成される傾向情報に基づいて、作業内容が偏っている作業者を検出する。たとえば、作業者ごとの傾向情報を参照して、所定期間において実行されたメンテナンス作業のうち、テスト作業の割合が７０％以上となっている作業者Ｋを検出したとする。検証通知部１４４は、作業内容が偏っている作業者名とその作業種別を開発側承認端末２０４に通知する。
受託側企業では、このような通知に基づいて、作業者Ｋの職務の見直すことにより、作業者Ｋのスキルが多様化するように配慮できる。すなわち、客観的なデータに基づいた合理的なジョブローテーションを実現しやすくなる。上記例の場合、作業者Ｋの実行しているテスト作業の一部を、テスト作業をあまり経験していない作業者Ｌに移管してもよい。
【００８２】
このように、状態判定部１７４は、ログ情報を解析することにより受託側企業の業務効率向上に資するさまざまなデータを生成できる。以上のデータを組み合わせて利用することもできる。たとえば、作業内容がテスト作業に偏っていて、かつ、テスト作業に要する時間がとても短いとき、その作業者はテスト作業に十分習熟しているといえる。このようなときには、テスト作業の一部を別の作業者に移管してもよい。受託側企業全体としての業務負荷が大きい時期には、テスト作業をテスト作業に習熟した作業者に集中的に割り当てることにより目下の業務効率を向上させ、全体としての業務負荷が小さい時期には、テスト作業をテスト作業に習熟していない作業者にも積極的に割り当てることにより、将来的な業務効率の向上が実現されるように作業を割り当ててもよい。
このように、状態判定部１７４によるログ情報の解析結果に応じて、直接的な業務効率向上と将来的な業務効率向上という２つの目的を状況に応じてバランスさせることもできる。
【００８３】
以上、リモートアクセス制御装置１００を実施例に基づいて説明した。
リモートアクセス制御装置１００は、原則として、開発側と運用側のダブルチェックをアクセス許可条件としているため、業務情報システムへの不正アクセスを防止しやすい構成となっている。事前の作業申請と任意のタイミングでの承認という運用により、作業者および承認者に過度の心理的負担をかけないかたちで業務情報システムのセキュリティ管理を実現できる。
また、申請された作業内容やそれに関連する情報のうち、開発側承認者と運用側承認者のそれぞれの判断に資する情報が選択的に提供されるため、各承認者の承認判断にともなう負荷をいっそう軽減できる。
【００８４】
更に、状況に応じて、開発側承認者についての承認をスキップできるため、緊急性の高いメンテナンス作業にも対応しやすい。スキップ承認がなされた旨は、開発側承認者に通知されるので、開発側承認者は事後的に作業内容をチェックすることができる。また、スケジュール化されている定型的なメンテナンス作業については作業申請不要とすれば、作業者の手続き負担を軽減できる。
【００８５】
リモートアクセス制御装置１００は、アクセス履歴をログ情報として記録し、更に、ログ情報から長期的なアクセス傾向を傾向情報として指標化することができる。申請された作業内容、傾向情報、ＳＬＡに示される作業条件等に鑑みて、メンテナンス作業が正常に行われているかを検証できる。特に、従来においては、ＳＬＡが交わされても、ＳＬＡが遵守されていることを検証するのは困難であった。リモートアクセス制御装置１００の契約検証部１７２は、実際に行われた作業内容をＳＬＡと比較検証できるため、委託側企業は自己の業務情報システムに対して適切なメンテナンスがなされていることを外部的に証明しやすくなる。また、ＳＬＡが遵守されていることを証明しやすい仕組みは、受託側企業は質の高いサービスが提供できることをアピールしやすくなるという効果がある。
【００８６】
更に、リモートアクセス制御装置１００は、ログ情報を積極的に活用することにより受託側企業における業務効率改善にも貢献することができる。既述のように作業者の負荷やスキルなどを多角的に検討することにより、大量の作業員が多くの業務情報システムを管理する現場においても、受託側企業全体としての業務効率を最大化するための対策を立てやすくなる。
【００８７】
更に付け加えるならば、リモートアクセス制御装置１００は、複数の業務情報システムに対するアクセスを一元管理できる。そのため、複数の業務情報システムに対して統一的なアクセスポリシを適用しやすくなっている。本実施例においては、メンテナンス作業について、委託側企業Ａと受託側企業Ｂのように１対１の関係を中心として説明するが、受託側企業Ｂは、複数の委託側企業のメンテナンス作業を請け負う場合についても同様である。たとえば、企業Ｂが、企業Ａだけでなく企業Ｍの業務情報システムのメンテナンス作業も請け負っているとする。この場合、企業Ｂの作業者は、企業Ａ用のリモートアクセス制御装置１００と企業Ｍ用のリモートアクセス制御装置１００のうち、アクセス先の企業に対応したリモートアクセス制御装置１００を介して、目的とする業務情報システムにアクセスすることになる。また、企業Ａ用のリモートアクセス制御装置１００と企業Ｍ用のリモートアクセス制御装置１００のそれぞれのログ情報を集計することにより、企業Ｂについてのログ情報の検証が可能となる。
【００８８】
本実施例においては、業務情報システムにおけるサーバやデータベース等を管理対象装置として説明したが、業務情報システムに限らずルータのような一般的な通信機器のリモートメンテナンスにも応用可能である。
【００８９】
以上、本発明を実施例をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００９０】
請求項に記載の承認入力部の機能は、本実施例においては主として承認受信部１２４により実現される。請求項に記載の作業要求受信部の機能は、本実施例においては主として作業通信部１３６により実現される。請求項に記載の第１の閾値および第２の閾値は、本実施例においては、Ｔ１、Ｖ２として表現されており、請求項に記載の第３の閾値および第４の閾値は、本実施例においては、Ｔ２、Ｖ１として表現されている。
このほかにも、請求項に記載の各構成要件が果たすべき機能は、本実施例において示された各機能ブロックの単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。
【図面の簡単な説明】
【００９１】
【図１】リモートアクセス制御装置と各種業務情報システムとの関係を示すハードウェア構成図である。
【図２】作業の申請と承認についての処理過程を示すシーケンス図である。
【図３】作業用端末に表示される申請画面を示す図である。
【図４】開発側承認端末に表示される開発側承認画面を示す図である。
【図５】運用側承認端末に表示される運用側承認画面を示す図である。
【図６】業務情報システムへのリモートログイン処理の過程を示すシーケンス図の一例である。
【図７】リモートアクセス制御装置の機能ブロック図である。
【図８】作業予定保持部における作業予定情報のデータ構造図である。
【図９】ログ保持部におけるログ情報のデータ構造図である。
【図１０】（ａ）傾向情報に基づいてアクセス量をグラフ化した図である。（ｂ）ログ情報に基づいてアクセス量をグラフ化した図である。
【図１１】業務情報システムへのリモートログイン処理の過程を示すシーケンス図の別例である。
【符号の説明】
【００９２】
１００ リモートアクセス制御装置、 １１０ ユーザインタフェース処理部、 １２０ 申請通信部、 １２２ 作業申請受信部、 １２４ 承認受信部、 １２６ 開発側承認受信部、 １２８ 運用側承認受信部、 １３０ 申請送信部、 １３２ 開発側申請送信部、 １３４ 運用側申請送信部、 １３６ 作業通信部、 １４０ 通知部、 １４２ スキップ通知部、 １４４ 検証通知部、 １５０ データ処理部、 １５２ 作業予定登録部、 １５４ 作業記録部、 １５６ ログ記録部、 １５８ 傾向記録部、 １６０ アクセス制御部、 １６２ 承認判定部、 １６４ 作業検証部、 １６６ 異常判定部、 １６８ 申請検証部、 １７０ 傾向判定部、 １７２ 契約検証部、 １７４ 状態判定部、 １７６ ユーザ認証部、 １８０ データ保持部、 １８２ 作業予定保持部、 １８４ ログ保持部、 １８６ 傾向保持部、 １８８ 契約保持部、 １９０ スケジュール保持部、 １９２ 関連情報保持部、 １９４ ユーザ情報保持部、 ２００ メンテナンス実行環境、 ２０２ 作業用端末、 ２０４ 開発側承認端末、 ２５０ 申請画面、 ２７０ 開発側承認画面、 ３００ 運用環境、 ３２０ 運用側承認端末、 ３４０ 運用側承認画面。
【技術分野】
【０００１】
この発明は、通信ネットワークに接続される機器のシステム操作に関連し、特に、業務情報システムのメンテナンス作業に関する。
【背景技術】
【０００２】
企業や公共施設などの運用を支える業務情報システム、いわゆるエンタープライズシステム（Enterprise System）は、今や、大小さまざまな組織の基盤となっている。業務情報システムは、ノード端末やデータベースから得られるデータを集計、蓄積、解析、加工した上でより付加価値の高い情報を出力することにより、複雑化する組織マネジメントを支えている。
【０００３】
このような業務情報システムは、稼働後も、動作監視、障害対応、機能拡張や機能変更などのさまざまなメンテナンス作業を必要とする。通常、業務情報システムを導入するクライアント企業は、外部の管理会社や内部の別組織にこのメンテナンス作業を委託する。管理会社のＳＥ（System
Engineer）は、業務情報システムにリモートログインしてメンテナンス作業を行うことが多い。
【特許文献１】特開２００４−２１３４７５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ところで、近年、アメリカで成立したＳＯＸ（Sarbanes‐Oxley）法は、企業経営者や会計監査人に対して公開情報の正当性を保証するように強く求めている。これに倣って、日本でも日本版ＳＯＸ法が導入される予定であり、日本版ＳＯＸ法に対応できる態勢の確立が急務となっている。
【０００５】
このような社会背景に鑑みて、本発明者は、管理会社による業務情報システムへのリモートアクセスに着目し、業務情報システムへのアクセス規制の強化とアクセス内容の検証、特に、既定のルールや承認に基づいたアクセスが行われているかの検証が必要であると認識した。更に、その検証結果を利用することによりメンテナンス作業をいっそう効率化することができると想到した。
【０００６】
本発明は、本発明者の上記課題認識に基づいて完成された発明であり、その主たる目的は、通信ネットワークに接続される機器を遠隔地からシステム操作するときの情報セキュリティや作業内容の検証性を向上させるための技術、を提供することにある。
【課題を解決するための手段】
【０００７】
本発明のさらに別の態様もまた、ユーザの操作に基づく制御命令の送信により管理対象装置のシステム操作を行う作業用端末と管理対象装置のそれぞれと接続されるリモートアクセス制御装置である。
この装置は、システム操作により実行されるシステム作業の実行予定者の指定を含む作業申請情報を受信し、開発側承認者と運用側承認者に作業申請情報を送信する。
システム作業の実行予定者の指定を含む作業実行要求を受信すると、作業実行要求に指定された実行予定者を対象とするメンテナンス作業が開発側承認者と運用側承認者のそれぞれにより承認済であることを条件として、作業用端末から送信される制御命令を管理対象装置に転送する。
【０００８】
なお、ここでいうシステム操作とは、管理対象装置の障害対応、障害調査、定期検査等の保守・点検など、いわゆるメンテナンス作業としてのシステム作業を遠隔地から実行するための操作であってもよい。
【０００９】
本発明のさらに別の態様も、ユーザの操作に基づく制御命令の送信により管理対象装置のシステム操作を行う作業用端末と管理対象装置のそれぞれと接続されるリモートアクセス制御装置である。
この装置は、システム操作により実行されるシステム作業の実行予定者の指定を含む作業申請情報を受信し、申請されたシステム作業をその承認状態と共に作業予定情報に登録する。
システム作業の実行予定者の指定を含む作業実行要求を受信すると、指定された実行予定者を対象とするシステム作業が承認済であることを条件として、作業用端末から送信される制御命令を管理対象装置に転送する。ただし、あらかじめスケジュール化されているシステム作業については、承認済か否かに関わらず、作業用端末から送信される制御命令を管理対象装置に転送する。
【００１０】
なお、以上の構成要素の任意の組合せ、本発明を方法、システム、記録媒体、コンピュータプログラムにより表現したものもまた、本発明の態様として有効である。
【発明の効果】
【００１１】
本発明によれば、業務情報システムにおける情報セキュリティと作業内容の検証性を向上させることができる。
【発明を実施するための最良の形態】
【００１２】
図１は、リモートアクセス制御装置１００と各種業務情報システムとの関係を示すハードウェア構成図である。
同図に示す運用環境３００は、ある企業Ａの業務環境を示す。運用環境３００に属する人や装置等を以下においては「運用側」とよぶことにする。また、メンテナンス実行環境２００とは、ある企業Ｂの業務環境を示す。メンテナンス実行環境２００に属する人や装置等を以下においては「開発側」とよぶことにする。企業Ａにおいてはさまざまな業務情報システムが運用されており、それらのメンテナンス作業が企業Ｂに委託されている。すなわち、メンテナンス作業に関しては、企業Ａがクライアント側、企業Ｂがサービス側となる。以下においては、企業Ａのことを「委託側企業」、企業Ｂのことを「受託側企業」ともよぶ。証券会社や銀行、官公庁、交通機関などさまざまな企業が委託側企業となり得る。一方、受託側企業となるのは、いわゆるシステム・インテグレータ（System
Integrator）である。
【００１３】
企業Ａの運用環境３００は、財務情報システム３１０、顧客情報システム３１２、在庫管理システム３１４という３種類の業務情報システムと、１以上の運用側承認端末３２０を含む。財務情報システム３１０は、企業Ａの財務情報を管理するシステムである。顧客情報システム３１２は、企業Ａの顧客情報を管理するシステムである。在庫管理システム３１４は、企業Ａの商品の在庫状態を管理するシステムである。運用側承認端末３２０は、ウェブブラウザを搭載した一般的なＰＣ（Personal
Computer）端末である。運用側承認端末３２０は、必ずしも運用環境３００に属する必要はなく、ノートＰＣなどの携帯端末であってもよい。
【００１４】
メンテナンス実行環境２００は、作業用端末２０２ａ、２０２ｂ、２０２ｃ等の複数の作業用端末２０２と、１以上の開発側承認端末２０４を含む。作業用端末２０２や開発側承認端末２０４もウェブブラウザを搭載した一般的なＰＣ端末である。開発側承認端末２０４も、ノートＰＣなどの携帯端末であってもよい。
各業務情報システムは、リモートアクセス制御装置１００を介してインターネット３３０と接続される。また、作業用端末２０２や開発側承認端末２０４はインターネット３３０を介してリモートアクセス制御装置１００と接続される。
【００１５】
運用環境３００の各種業務システムは、稼働後も、適宜メンテナンス作業を受ける。このメンテナンス作業の中にはバックアップ用テープの交換作業のように、運用環境３００内で行われる作業もあるが、ほとんどは作業用端末２０２からのリモートアクセスにより実行される。このリモートのメンテナンス作業を行うユーザのことを、以下、単に「作業者」とよぶ。作業者は、通常、企業ＢのＳＥであることが多い。作業者はいずれかの作業用端末２０２を操作し、リモートアクセス制御装置１００にリモートログインする。そして、リモートアクセス制御装置１００が提供するユーザインタフェースを介して、目的の業務情報システムにアクセスする。いいかえれば、リモートアクセス制御装置１００は、各種業務情報システムへのアクセスを一元的に管理する。
なお、情報セキュリティ強化の面から、作業用端末２０２とリモートアクセス制御装置１００の間の通信経路は、ＶＰＮ（Virtual Private Network）などによりセキュアな通信経路であることが望ましい。
【００１６】
リモートアクセス制御装置１００は、作業用端末２０２からのリモートログイン要求を受け付ける。そして、以下の３段階の判定が共に肯定判定となったことを条件として、リモートログインを許可する。
１．作業者があらかじめ登録されているユーザであるか（以下、「ユーザ認証」とよぶ）
２．作業者がメンテナンス作業を実行することを事前に申請済みであるか（以下、「申請判定」とよぶ）
３．作業者が申請したメンテナンス作業が、開発側承認端末２０４を使用する承認者（以下、「開発側承認者」とよぶ）と運用側承認端末３２０を使用する承認者（以下、「運用側承認者」とよぶ）の両方により承認済であるか（以下、「承認判定」とよぶ）
以上のプロセスには例外もあるが、そのような例外も含めて詳細は後述する。まず、作業者によるメンテナンス作業の申請と承認に関して説明する。
【００１７】
図２は、作業の申請と承認についての処理過程を示すシーケンス図である。
作業者は、メンテナンス作業を実行する前に、作業予定日時や作業内容等を申請しなければならない。作業用端末２０２のユーザ、すなわち、作業者は、まず、リモートアクセス制御装置１００に作業申請のためのアクセスを行う（Ｓ１０）。リモートアクセス制御装置１００は、申請画面２５０用のＨＴＭＬ（Hyper
Text Markup Language）データを送信する（Ｓ１２）。申請画面２５０のユーザインタフェースに関しては図３に関連して後述する。
【００１８】
作業用端末２０２には申請画面２５０が表示される（Ｓ１４）。ユーザは、申請画面２５０に申請内容を示すデータを入力すると（Ｓ１６）、入力されたデータが作業申請情報としてリモートアクセス制御装置１００に送信される（Ｓ１８）。リモートアクセス制御装置１００は、この作業申請情報を、作業予定として作業予定情報に登録する（Ｓ２０）。作業予定情報のデータ構造については、図８に関連して後述する。リモートアクセス制御装置１００は、開発側承認端末２０４と運用側承認端末３２０のそれぞれに、電子メールを送信し、新たな作業申請がなされた旨を通知する（Ｓ２２、Ｓ２４）。
【００１９】
開発側承認端末２０４の開発側承認者は、承認可否を判断するためにリモートアクセス制御装置１００にアクセスする（Ｓ２６）。リモートアクセス制御装置１００は、開発側承認画面２７０のＨＴＭＬデータを送信する（Ｓ２８）。開発側承認画面２７０のユーザインタフェースに関しては図４に関連して後述する。開発側承認端末２０４には開発側承認画面２７０が表示される（Ｓ３０）。ユーザ、すなわち、開発側承認者が開発側承認画面２７０に承認可否を入力すると（Ｓ３２）、承認可否を示す開発側承認情報がリモートアクセス制御装置１００に送信される（Ｓ３４）。リモートアクセス制御装置１００は、この承認可否に応じて、申請された作業の承認状態を更新する（Ｓ３６）。
【００２０】
一方、運用側承認端末３２０の運用側承認者も、承認判断のためにリモートアクセス制御装置１００にアクセスする（Ｓ３８）。リモートアクセス制御装置１００は、運用側承認画面３４０のＨＴＭＬデータを送信し、運用側承認画面３４０を表示させる（Ｓ４０、Ｓ４２）。運用側承認画面３４０のユーザインタフェースに関しては図５に関連して後述する。ユーザ、すなわち、運用側承認者が運用側承認画面３４０に承認可否を入力すると（Ｓ４４）、承認可否を示す運用側承認情報がリモートアクセス制御装置１００に送信される（Ｓ４６）。リモートアクセス制御装置１００は、この承認可否に応じて、申請された作業の承認状態を更新する（Ｓ４８）。
こうして、作業の申請と、開発側承認者による承認（以下、単に「開発側承認」とよぶ）、運用側承認者による承認（以下、単に「運用側承認」とよぶ）がなされる。開発側承認者は受託側企業における責任者であり、運用側承認者は委託側企業における責任者である。したがって、開発側承認は受託側企業の立場から判断され、運用側承認は委託側企業の立場から判断されることになる。
【００２１】
より正確には、Ｓ１０、Ｓ２６、Ｓ３８においては、作業者、開発側承認者、運用側承認者のユーザＩＤとパスワードも送信される。リモートアクセス制御装置１００は、受信したユーザＩＤとパスワードが登録済みのものであるかユーザ認証を行い、このユーザ認証が成功しなければ申請画面２５０等のＨＴＭＬデータを送信しない仕組みとなっている。以下、ユーザＩＤやパスワードのようにユーザを一意に識別するための情報のことを「ユーザ識別情報」とよぶことにする。
【００２２】
なお、Ｓ２２やＳ２４のように能動的に作業申請を通知するのではなく、各承認者がリモートアクセス制御装置１００にアクセスしたときに承認待ちの作業申請を一覧表示させてもよい。承認者は、この一覧表の中から承認判断対象となる作業申請を選択し、開発側承認画面２７０や運用側承認画面３４０を表示させてもよい。
【００２３】
また、Ｓ１８において作業申請がなされたとき、リモートアクセス制御装置１００は、開発側承認端末２０４と運用側承認端末３２０の両方ではなく、いずれか一方、たとえば、開発側承認端末２０４にだけ通知してもよい。そして、開発側承認がなされたことを条件として、運用側承認端末３２０に通知してもよい。この場合、運用側承認者は、開発側承認がなされた作業申請についてだけ判断すればよいので、承認判断にともなう負荷が軽減されるという効果がある。
【００２４】
パスワードなどによるユーザ認証だけでアクセスを許す業務情報システムの場合、パスワードの漏洩はそのまま業務情報システムの危機に直結する。特許文献１はＩＤとパスワードによるユーザ認証に加えて、管理者によるアクセス承認を条件とするアクセスルールについて開示する。このようなアクセスルールは、業務情報システムへの不正アクセスを防止する上で有効な手法であるが、開発側承認者の立場からの判断しかなされていない。
【００２５】
しかし、開発側承認者が承認しても、運用側からみると作業予定日時が都合の悪い時間帯かもしれない。たとえば、処理負荷が高くなると予測される時間帯にメンテナンス作業まで実行されると、業務情報システム全体としての処理効率が大きく低下してしまう。本実施例におけるリモートアクセス制御装置１００によれば、運用側承認者にも承認権を付与することにより、このような状況にも適切に対処できる。すなわち、受託側と委託側という異なる立場からの多角的な承認判断が可能となっている。
次に、Ｓ１４の申請画面２５０、Ｓ３０の開発側承認画面２７０、Ｓ４２の運用側承認画面３４０について説明したあと、作業者がメンテナンス作業を実行するときの処理過程を説明する。
【００２６】
図３は、作業用端末２０２に表示される申請画面２５０を示す。
作業申請のためにリモートアクセス制御装置１００にアクセスすると、作業用端末２０２には同図に示す申請画面２５０が表示される。申請画面２５０は、作業用端末２０２にウェブページとして表示される。
【００２７】
作業者名欄２５２には、作業者名を選択形式にて入力する。たとえば、作業用端末２０２のユーザ「相野伸行」がリモートアクセス制御装置１００にログインしたときには、作業者名欄２５２には「相野伸行」が表示される。ユーザは、作業者名欄２５２にて別の作業者を指定することもできる。すなわち、「相野伸行」は、自分で作業を行うための申請のみならず、別の作業者のために代理として作業申請をすることもできる。
【００２８】
件名領域２５４には、作業申請の件名を入力する。システム名領域２５６には作業対象となる業務情報システムを指定し、ターゲット名領域２５８には作業の対象となるノード、すなわち、管理対象装置を指定する。同図においては、財務情報システム３１０（ＩＤ：０４）に含まれる複数の装置のうち、ウェブサーバ（ＩＤ：１４）が管理対象装置となっている。作業種別領域２６０は作業種別（作業ＩＤ）を示す。メンテナンス作業は、障害対応、調査、稼働監視、テスト、リリース作業・・・のようにその目的はさまざまである。メンテナンス作業は、このように複数の種別（以下、単に「作業種別」とよぶ）に分類される。ここでは、作業ＩＤ：０４のリリース作業、すなわち、ウェブサーバに搭載されるソフトウェアの更新作業が指定されている。開発側連絡領域２６２には開発側承認者への連絡事項、運用側連絡領域２６４には運用側承認者への連絡事項が自由記述形式にて入力される。作業日時領域２６６は作業予定日時を示す。
作業者は、申請画面２５０に示される各項目にデータを入力した後、申請ボタン２６８をクリックする。入力されたデータは作業申請情報としてリモートアクセス制御装置１００に送信される。リモートアクセス制御装置１００は、申請された作業に「申請ＩＤ」が付与し、作業予定情報に登録する。
【００２９】
図４は、開発側承認端末２０４に表示される開発側承認画面２７０を示す。
開発側承認端末２０４から承認判断のためにリモートアクセス制御装置１００にアクセスすると、開発側承認端末２０４には同図に示す開発側承認画面２７０が表示される。開発側承認画面２７０は、開発側承認端末２０４にウェブページとして表示される。
【００３０】
申請情報領域２７４には申請画面２５０において入力された申請内容の一部、いいかえれば、作業申請情報の一部が示されている。連絡事項領域２８４の表示内容は、申請画面２５０の開発側連絡領域２６２にて入力された内容に対応する。一方、申請画面２５０の運用側連絡領域２６４に入力された内容は申請情報領域２７４に表示されない。このように、作業申請情報のうち、開発側承認者の立場からみて判断に必要な情報だけが抽出されて表示される。このようなやり方によれば、作業申請情報の内容が複雑化したときにも、開発側承認者が申請内容を確認するときの手間を軽減できる。
【００３１】
また、関連情報領域２７２には、作業申請情報の一部として指定されていた「財務情報システム（０４）」の関連情報が表示されている。リモートアクセス制御装置１００は、このような様々な関連情報を保持している。ここでは、「財務情報システム（０４）」とは、「村野株式会社」という委託側企業で運用されるシステムであり、この会社は受託側企業からみて１９９８年から取引関係にあるという情報が関連づけられている。このように、リモートアクセス制御装置１００は、作業申請情報に含まれる情報についての関連情報のうち、開発側承認者の承認判断に資する関連情報を選択的に提供する。同図の場合、リモートアクセス制御装置１００は、作業対象の業務情報システムについて、「企業名」と「取引開始年」という関連情報を開発側承認者に提供するという設定がなされていることになる。
【００３２】
承認者名領域２７６には、開発側承認者の承認者名を入力する。通信欄２７８は、作業者に対する通信事項を入力する。承認ボタン２８０は承認用、却下ボタン２８２は却下用のボタンである。承認ボタン２８０か却下ボタン２８２のいずれかがクリックされると、承認者名領域２７６、通信欄２７８の記述内容と承認可否を示す開発側承認情報がリモートアクセス制御装置１００に送信される（図２のＳ３４）。通信欄２７８の内容は電子メールにて作業用端末２０２に送信されてもよい。
【００３３】
図５は、運用側承認端末３２０に表示される運用側承認画面３４０を示す。
運用側承認端末３２０から承認判断のためにリモートアクセス制御装置１００にアクセスすると、運用側承認端末３２０には同図に示す運用側承認画面３４０が表示される。運用側承認画面３４０は、運用側承認端末３２０にウェブページとして表示される。
【００３４】
申請情報領域３４４には、申請画面２５０において入力された申請内容の一部、いいかえれば、作業申請情報の一部が示される。連絡事項領域３４６の表示内容は、申請画面２５０の運用側連絡領域２６４に入力された内容に対応する。一方、申請画面２５０の開発側連絡領域２６２に入力された内容は、申請情報領域２７４には表示されない。また、申請情報領域３４４においては、実際にメンテナンス作業を行う作業者の名前も表示されない。委託側企業にとっては、いつ、どんな作業がなされるかという情報は重要であるが、誰が作業をするかはそれほど重要な情報ではないと考えられるからである。
【００３５】
関連情報領域３４２には、作業申請情報の一部として指定されていた「ウェブサーバ（１４）」の関連情報が表示されている。ここでは、「ウェブサーバ（１４）」には、「最大接続可能数」、「搭載しているＣＰＵ」、「所定期間における当該装置のＣＰＵの平均使用率」、「搭載しているメモリの大きさ」といった情報が関連づけられている。同図に示す例では、運用側承認者のために「ウェブサーバ（１４）」の関連情報が運用側承認画面３４０にて提供されている。
【００３６】
承認者名領域３４８は、運用側承認者の承認者名を入力するための領域である。通信欄３５０には、作業者に対する通信事項を記入する。承認ボタン３５２は承認用、却下ボタン３５４は却下用のボタンである。承認ボタン３５２か却下ボタン３５４のいずれかがクリックされると、承認者名領域３４８と通信欄３５０の内容と承認可否を示す運用側承認情報がリモートアクセス制御装置１００に送信される（図２のＳ４６）。通信欄３５０の内容は電子メールにて作業用端末２０２に送信されてもよい。
次に、実際にメンテナンス作業を開始するときの処理について説明する。
【００３７】
図６は、業務情報システムへのリモートログイン処理の過程を示すシーケンス図の一例である。
作業者が作業用端末２０２を操作して、リモートアクセス制御装置１００にアクセスすると、リモートアクセス制御装置１００はログイン画面を作業用端末２０２に表示させる。作業者は、ユーザ識別情報とアクセス先となる業務情報システムなどを指定して、作業実行要求をリモートアクセス制御装置１００に送信する（Ｓ５０）。リモートアクセス制御装置１００は、まず受信したユーザ識別情報を参照してユーザ認証を行う（Ｓ５２）。ユーザ認証に失敗すると（Ｓ５２のＮ）、アクセスは拒否され（Ｓ６２）、拒否の旨が作業用端末２０２に通知される（Ｓ６４）。ユーザ認証に成功すると（Ｓ５２のＹ）、次に、アクセス元のユーザが、現在日時を作業予定日時としてなんらかのメンテナンス作業を申請済みであるかについての判定、すなわち申請判定が実行される（Ｓ５４）。申請済みでなければ（Ｓ５４のＮ）、アクセスは拒否される（Ｓ６２）。
【００３８】
申請済であれば（Ｓ５４のＹ）、その作業申請が運用側承認済みか判定される（Ｓ５６）。運用側承認がなされていなければ（Ｓ５６のＮ）、アクセス拒否となる（Ｓ６２）。運用側承認済であれば（Ｓ５６のＹ）、開発側承認済みか判定される（Ｓ５８）。開発側承認がなされていなければ（Ｓ５８のＮ）、アクセス拒否となる（Ｓ６２）。開発側承認済でなければ（Ｓ５８のＹ）、アクセスは許可され（Ｓ６０）、その旨が作業用端末２０２に通知される（Ｓ６４）。
【００３９】
以上の処理過程を経て、作業者はリモートアクセス制御装置１００へリモートログインする。以後は、リモートアクセス制御装置１００が作業用端末２０２にユーザインタフェース画面を提供する。作業者は、このユーザインタフェース画面を介して業務情報システム、ひいては、管理対象装置にアクセスする。このアクセス用のプロトコルは、HttpやTelnet、Ftpなどの既知の通信プロトコルであればよい。たとえば、リモートアクセス制御装置１００は、ＧＵＩ（Graphical
User Interface）にて管理対象装置のメンテナンス作業を行うための専用ウェブページを作業用端末２０２に表示させてもよい。あるいは、専用ＣＵＩ（Character-based
User Interface）画面にて管理対象装置にコマンドを送信してもよい。
このように作業用端末２０２のユーザインタフェース画面に対する操作により、リモートアクセス制御装置１００が操作される。たとえば、ウェブページ上のボタンやエディットボックスに対する入力がなされると、作業用端末２０２はその入力内容に応じた操作データをリモートアクセス制御装置１００に転送する。リモートアクセス制御装置１００は、この操作データに対応する各種処理を行う。すなわち、作業用端末２０２からリモートアクセス制御装置１００に送信される操作データが、リモートアクセス制御装置１００を操作するための制御命令となる。
【００４０】
ＧＵＩであれＣＵＩであれ、作業用端末２０２からリモートアクセス制御装置１００を経由して管理対象装置に各種コマンドを送信することによりメンテナンス作業が実行される。リモートアクセス制御装置１００は、このコマンドや管理対象装置からの応答をログ情報として記録する。また、リモートアクセス制御装置１００は、作業者による実際の画面操作を動画として記録してもよい。
リモートアクセス制御装置１００はログ情報を事後的に検証する機能を備えるが、ログ情報とその検証方法については、図９や図１０に関連して後述する。
【００４１】
なお、先述したように、開発側承認を前提として運用側承認がなされるという設計であれば、リモートログイン処理においてＳ５８の開発側承認の判定処理は不要となる。
【００４２】
図７は、リモートアクセス制御装置１００の機能ブロック図である。
ここに示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。
【００４３】
リモートアクセス制御装置１００は、ユーザインタフェース処理部１１０、データ処理部１５０およびデータ保持部１８０を含む。
【００４４】
ユーザインタフェース処理部１１０は、たとえば、作業用端末２０２や開発側承認端末２０４、運用側承認端末３２０に画面用データを送信し、これらの端末から各種データを受信する。また、各種業務情報システムに作業者からのコマンドを転送したり、各業務情報システムからのデータを受信して、作業用端末２０２に転送する。このようにユーザインタフェース処理部１１０は、業務情報システムにアクセスするためのユーザインタフェース全般を担当する。
データ処理部１５０は、ユーザインタフェース処理部１１０から取得されたデータを元にして各種のデータ処理を実行する。データ処理部１５０は、ユーザインタフェース処理部１１０とデータ保持部１８０の間のインタフェースの役割も果たす。
データ保持部１８０は、各種データを保持するための記憶領域である。
【００４５】
ユーザインタフェース処理部１１０：
ユーザインタフェース処理部１１０は、申請通信部１２０、作業通信部１３６および通知部１４０を含む。
申請通信部１２０は、開発側承認端末２０４や運用側承認端末３２０に対して、作業の申請・承認に関する通信を担当する。申請通信部１２０は、作業申請受信部１２２、承認受信部１２４および申請送信部１３０を含む。作業申請受信部１２２は、作業用端末２０２から作業申請情報を受信する（図２のＳ１８）。申請送信部１３０のうち、開発側申請送信部１３２は作業申請情報を開発側承認端末２０４に送信し（図２のＳ２８）、運用側申請送信部１３４は作業申請情報を運用側承認端末３２０に送信する（図２のＳ４０）。承認受信部１２４のうち、開発側承認受信部１２６は開発側承認情報を受信し（図２のＳ３４）、運用側承認受信部１２８は運用側承認情報を受信する（図２のＳ４６）。
作業通信部１３６は、作業用端末２０２からの作業実行要求を受信する。また、メンテナンス作業用のコマンドを受信し、管理対象装置に転送する。
通知部１４０は、リモートアクセス制御装置１００の処理結果に関する各種情報を作業用端末２０２等に通知する。通知部１４０のうちスキップ通知部１４２は後述する「スキップ承認」が実行された旨を開発側承認端末２０４に電子メール通知する。通知部１４０のうち検証通知部１４４は、ログ情報の解析結果を通知する。ログ情報の解析についても後述する。
【００４６】
データ保持部１８０：
データ保持部１８０は、作業予定保持部１８２、ログ保持部１８４、傾向保持部１８６、契約保持部１８８、スケジュール保持部１９０、関連情報保持部１９２およびユーザ情報保持部１９４を含む。
作業予定保持部１８２は、申請されたメンテナンス作業の実行予定を作業予定情報として保持する。作業予定情報のデータ構造については次の図８に関連して詳述する。ログ保持部１８４は、メンテナンス作業の実行に際して、作業用端末２０２から送信されるコマンドや、業務情報システムからの応答をログ情報として保持する。本実施例においては、ログ情報は作業者ごとに記録される。ログ情報については図９に関連して詳述する。
【００４７】
傾向保持部１８６は、メンテナンス作業の統計的な傾向を示す傾向情報を保持する。この傾向情報は、ログ情報を集計することにより生成される。傾向情報とは、たとえば、過去６ヶ月間において、月曜日の「１２：００〜１８：００」において、財務情報システム３１０のウェブサーバＡに対し、「メンテナンス作業がなされている時間の割合」、「送信コマンド総数」、「メンテナンス作業が実行される確率」など、さまざまな観点から集計される統計情報である。傾向情報については図１０（ａ）や図１０（ｂ）に関連しても後述する。
【００４８】
一般的には、委託側企業と受託側企業の間でＳＬＡ（Service Level Agreement）とよばれるメンテナンス契約が交わされる。ＳＬＡは、いわば、メンテナンス作業の品質保証契約である。
たとえば、あるウェブサーバのソフトウェアを更新するとき、すなわち、「リリース作業」を実行するときには、複数のウェブサーバ間で負荷分散を実行するロードバランサから、作業対象となるウェブサーバを外してから、ウェブサーバのサービスを停止させるという順番で作業がなされなければならない。また、あるウェブサーバについて３０分以上の稼働監視作業を毎週金曜日に実行しなければならないという契約内容も考えられる。契約保持部１８８はこのようなメンテナンス作業の質的・量的な実行条件を示すＳＬＡを実行条件情報として保持する。
また、内部統制の観点から、システム操作についての役割分担や業務フローが社内規定によって定められる場合もある。このような観点から、契約保持部１８８が保持する実行条件情報には、ＳＬＡに限らず社内規定に基づく実行条件が定められてもよい。
【００４９】
メンテナンス作業の中には、あらかじめ決められたスケジュールにて実行される定型的な作業もある。スケジュール保持部１９０は、メンテナンス作業の実行スケジュールとしてスケジュール情報を保持する。関連情報保持部１９２は、作業申請情報に含まれ得る各種データについて、関連情報を対応づけて保持する。関連情報については図４や図５に関連して説明した通りである。ユーザ情報保持部１９４は、ユーザＩＤとパスワードを対応づけた正規ユーザ情報を保持する。この正規ユーザ情報に登録されているユーザだけがユーザ認証をパスすることになる。
【００５０】
データ処理部１５０：
データ処理部１５０は、作業予定登録部１５２、作業記録部１５４、アクセス制御部１６０、承認判定部１６２、ユーザ認証部１７６および作業検証部１６４を含む。
作業予定登録部１５２は、申請されたメンテナンス作業を作業予定保持部１８２に登録する。作業申請がなされると、申請を一意に識別するための申請ＩＤが付与される。作業予定情報では、申請ＩＤ、作業予定日時、作業内容、作業者名、承認状態等が対応づけられる。したがって、開発側承認情報や運用側承認情報が受信されると、作業予定情報は更新される。作業記録部１５４は、メンテナンス作業の作業内容を記録する。作業記録部１５４のうちのログ記録部１５６はログ情報を記録し、傾向記録部１５８はログ情報を集計して傾向情報を生成し、傾向保持部１８６に記録する。
【００５１】
アクセス制御部１６０は、業務情報システムと作業用端末２０２の間のデータ送受の中継または遮断を行う。承認判定部１６２は、申請判定および承認判定を実行する。ユーザ認証部１７６は、正規ユーザ情報を参照してユーザ認証を実行する。アクセス制御部１６０は、ユーザ認証、申請判定、承認判定（開発側承認判定と運用側承認判定）を経て、アクセスの可否を設定する（図６のＳ６０やＳ６２を参照）。すなわち、メンテナンス実行環境２００から管理対象装置への通信経路の開閉を設定する。
【００５２】
作業検証部１６４は、ログ情報によりメンテナンス作業を事後的に検証する機能ブロックである。作業検証部１６４は、不正なアクセス、または、不正の疑いがあるアクセス等について異常を検出するための異常判定部１６６と、メンテナンス作業の実行結果に基づいて受託側企業の業務状態を検査するための状態判定部１７４を含む。状態判定部１７４の具体的な機能については後述する。
異常判定部１６６は、メンテナンス作業が作業申請された内容と適合しているかを判定する申請検証部１６８、メンテナンス作業が過去のアクセス傾向と適合しているかを判定する傾向判定部１７０、メンテナンス作業がＳＬＡに適合しているかを判定する契約検証部１７２を含む。これらの各機能についても詳細は後述する。
【００５３】
図８は、作業予定保持部１８２における作業予定情報のデータ構造図である。
申請ＩＤ欄２１０は、申請ＩＤを示す。作業予定登録部１５２は、作業申請情報が受信されると、一意の申請ＩＤを付与して作業予定情報に登録する。作業者ＩＤ欄２１２は、作業予定者のユーザＩＤを示す。申請日欄２１４は作業申請がなされた日付を示し、作業日時欄２１６は作業予定日時を示す。
【００５４】
開発側承認欄２１８は開発側承認についての状態を示し、承認状態欄２２０は承認済を「○」、未承認を「−」、却下を「×」として承認状態を、承認日時欄２２２は承認日時を示す。運用側承認欄２２４は運用側承認についての状態を示し、承認状態欄２２６は、承認済、未承認、却下のいずれかの承認状態を、承認日時欄２２８は承認日時を示す。
作業種別欄２３０は、作業種別を示す。システムＩＤ欄２３２は作業対象となる業務情報システムのＩＤを示し、ノードＩＤ欄２３４は管理対象装置、すなわち、メンテナンス作業の対象となるノードのＩＤを示す。
【００５５】
同図においては、「申請ＩＤ：１」においては、「作業種別：０１」という障害対応作業が申請されており、開発側承認者にも運用側承認者にも承認されている。「申請ＩＤ：２」のリリース作業は、運用側承認者により却下されている。「申請ＩＤ：３」の調査作業は、開発側承認者には承認されているが運用側承認者には未承認である。一方、「申請ＩＤ：４」のテスト作業は、運用側は承認済であるが開発側は未承認である。したがって、通常であれば、「申請ＩＤ：４」のテスト作業は、このままでは実行不可能であるが、所定の状況においては、開発側承認を待たずにメンテナンス作業を実行することができる。このように開発側承認を経ることなく運用側承認だけでメンテナンス作業を許可することを「スキップ承認」とよぶ。
【００５６】
運用側承認者としては、受託側企業から業務情報システムの運用現場に派遣されるＳＥか、あるいは、委託側企業のアドミニストレータなどが想定される。業務情報システムは、通常、年中無休２４時間体制で運用されるため、複数の運用側承認者が交代制で運用に対応している。したがって、運用側承認者は、作業申請を素早く検討しやすい立場にある。
これに対して、開発側承認者は、受託側企業における作業者の上司が想定される。したがって、開発側承認は、開発側承認者の勤務時間でなければ得られない可能性がある。
【００５７】
しかし、メンテナンス作業の中には、障害対応のように即時的な対応が求められる作業もある。このような場合にスキップ承認が有効である。スキップ承認がなされたときには、スキップ通知部１４２は開発側承認端末２０４に対してスキップ承認がなされた旨を電子メール等により事後的に通知する。本実施例においては、作業申請がなされたときに、その旨を開発側承認端末２０４と運用側承認端末３２０に通知するとして説明したが（図２のＳ２２やＳ２４）、先述したように承認者がリモートアクセス制御装置１００にアクセスしたときに承認待ちの作業を閲覧するという受動的な処理方法であってもよい。このような受動的な処理方法を採用する場合には、スキップ承認の通知は、開発側承認者の注意を喚起する上で特に有効である。
また、所定時間内に開発側承認者が承認を行わない場合には、開発側承認端末２０４にアラーム通知を行い、承認を義務付けてもよい。
【００５８】
スキップ承認が可能となる条件としては、
１．所定の作業種別についての申請であること、たとえば、障害対応のように緊急性の高いメンテナンス作業であること、
２．作業申請日時から作業の開始予定日時までの時間が所定時間以下であること、たとえば、緊急性の高いメンテナンス作業であること
３．作業申請時にスキップ承認を作業者が明示的に申請していること
４．あらかじめ指定された作業者による申請であること、たとえば、経験豊富で信頼できる作業者の申請であること
などについてのいずれか、または、それらの組み合わせが考えられる。
そのほかにも、開発側承認者に電話などによりあらかじめ承認を得ている旨を証明できる場合には、スキップ承認可能としてもよい。
【００５９】
なお、作業予定登録部１５２は、作業予定情報に登録されている作業のうち、作業予定日時を経過したメンテナンス作業や、すでに完了したメンテナンス作業を適宜、作業予定情報から抹消する。
【００６０】
図９は、ログ保持部１８４におけるログ情報のデータ構造図である。
本実施例においては、ログ情報は作業者ごとに別々のファイルとして作成される。アクセス日時欄２４０は、作業用端末２０２から業務情報システムに向けて送信されたコマンドをリモートアクセス制御装置１００が受信した日時を示す。コマンド欄２４２は送信されたコマンド名、ターゲット欄２４４はコマンドの送信先、メッセージ欄２４６は管理対象装置から出力されるメッセージを示す。このほかにも、コマンドのパラメータやアクセス先の業務情報システム名などが記録されてもよい。
なお、ログ記録部１５６は作業用端末２０２に表示された画面をビデオ情報として取得し、時刻情報や操作指示情報と対応付けて、ログ保持部１８４に記録することもできる。たとえば、リモートアクセス制御装置１００が作業用端末２０２のユーザインタフェース画面そのものを提供するモデルであれば、リモートアクセス制御装置１００は作業者のマウスの移動やクリックといった操作を動画として記録することができる。ただし、本明細書においては、このような動画記録機能については特に詳述しない。
【００６１】
同図に示すログ情報は、図８に示した「申請ＩＤ：２」のリリース作業に対応している。まず、作業者は２００６年１０月１４日の２：３５に、コマンドＡによりリモートアクセス制御装置１００にリモートログインしている。コマンドＡはログインコマンドである。２：３８には、「ノードＩＤ：１」のロードバランサにコマンドＢを送信し、「ノードＩＤ：４」の管理対象装置であるウェブサーバを管理対象から外している。コマンドＢは、ロードバランサの管理対象を変更するためのコマンドである。２：４０にロードバランサは、管理対象装置のリストからの除去を完了している。
以降においては、ウェブサーバの停止、モジュールの更新、再起動、複数種類のテスト実行、動作確認を経て、ウェブサーバは再びロードバランサに登録されている。以上のアクセスのあと、３：４５に作業者はコマンドＨにより、リモートアクセス制御装置１００からログアウトしている。
また、同日３：５０に作業者は再びリモートアクセス制御装置１００にログインしている。
【００６２】
どのようなコマンドがどのような順序で実行されているかにより、メンテナンス作業の作業種別をログ情報から判定できる。ＳＬＡに関連して説明したように、メンテナンス作業には作業種別に応じて特有の作業手順が設定されるからである。
あるいは、メンテナンス作業ごとに特有のコマンドを検出することにより、作業種別を特定することもできる。たとえば、モジュール更新のためのコマンドＤは、リリース作業に特有のコマンドである。したがって、ログインからログアウトまでの間に、コマンドＤが記録されているときには、リリース作業の実行があったことを事後的に推定できる。
【００６３】
このようなログ情報により、以下に示す３種類の観点から不正なアクセス、または、不正を疑われるアクセスが発生していないかが検証される。
１．作業申請に基づく検証（以下、「申請検証」とよぶ）
申請検証部１６８は、ログ情報に基づき、申請された作業内容と実際の作業内容が適合しているかを検証する。たとえば、申請されていた作業が調査作業であったのに、作業者がモジュール更新用コマンドを送信していれば、申請検証部１６８は異常検出する。あるいは、申請されていたメンテナンス作業について想定されるコマンド実行順序と、実際に実行されたメンテナンス作業におけるコマンドの順序が整合していなければ異常検出してもよい。作業予定日時においてリモートログインが発生していないときにや、作業の終了予定時刻を過ぎてもログアウトしていないときも異常検出となる。
【００６４】
２．ＳＬＡに基づく検証（以下、「契約検証」とよぶ）
従来、業務情報システムのメンテナンス作業において、ＳＬＡにおける実行条件が遵守されているかを確認することは困難であった。契約検証部１７２は、ログ情報に基づき、ＳＬＡに示された実行条件と実際の作業内容が適合しているかを検証する。たとえば、リリース作業については、ロードバランサから管理対象装置を外した上で作業にとりかかるように処理手順が定められているかもしれない。また、証券会社の業務情報システムであれば、ソフトウェアの更新が終わった後には、所定銘柄を対象とした買い注文、売り注文、約定確認についての動作確認が義務づけられるかもしれない。実行された作業におけるコマンドにおいてこのような手順が守られていなければ、契約検証部１７２は異常検出する。また、１ヶ月につき、所定のテスト作業を１０回以上実行しなければならないという契約内容であれば、契約検証部１７２は１ヶ月あたり実行されたテスト作業の回数が１０回未満であるときに異常検出する。
【００６５】
３．アクセス傾向に基づく検証（以下、「傾向検証」とよぶ）
業務情報システムに対するメンテナンス作業は、通常、営業時間外になされることが多く、アクセスの発生しやすい時間帯と発生しにくい時間帯がある。傾向記録部１５８は、このようなアクセス傾向を傾向情報として記録する。傾向判定部１７０は、傾向情報とログ情報を比較して、一般的なアクセス傾向とは異なるアクセスを異常検出する。傾向検証については、次の図９を参照しながら更に説明する。
【００６６】
いずれにしても、検証通知部１４４は、異常検出の内容を開発側承認端末２０４や運用側承認端末３２０に通知する。アクセス制御部１６０は、異常検出がなされた時点で、業務情報システムへの通信経路を強制的に遮断してもよい。
なお、作業者ごとではなく、複数の作業者についてのログ情報を１つのファイルにまとめて記録してもよい。また、管理対象装置ごとにログ情報を記録するとしてもよい。ログ情報の取り方についてはさまざまなバリエーションが考えられる。
【００６７】
図１０（ａ）は、傾向情報に基づいてアクセス量をグラフ化した図である。
本実施例においては、傾向情報は、曜日単位で集計され、更に、１日は、０：００〜６：００、６：００〜１２：００、１２：００〜１８：００、１８：００〜２４：００の４つの時間帯に区切られている。同図は、過去６ヶ月間において、ある管理対象装置Ｃに対して送信されたコマンド数の平均値を示す。同図によると、金曜日の１８：００〜２４：００という時間帯にもっとも多くのコマンドが送信されているが、月曜日の０：００〜１２：００という時間帯においてはコマンドは全く送信されていない。管理対象装置Ｃに対するアクセスは、水曜日の午前中と金曜日の夜から土曜日の朝に集中する傾向がある。
同図において、Ｔ２はアクセス量の上限検証値、Ｔ１は下限検証値を示す。
【００６８】
図１０（ｂ）は、ログ情報に基づいてアクセス量をグラフ化した図である。
同図では、過去１週間分のログ情報について、管理対象装置Ｃに送信されたコマンド数を示す。傾向情報にあわせて、傾向判定部１７０は、ログ情報を曜日ごとに分類し、更に１日を４つの時間帯に分割してアクセス量を集計している。
同図において、Ｖ２はアクセス量の上限検証値、Ｖ１は下限検証値を示す。
傾向判定部は、Ｔ１、Ｔ２、Ｖ１、Ｖ２に基づいて、以下の方法により傾向検証処理を行う。
【００６９】
傾向判定部１７０は、
１．傾向情報においてアクセス量がＴ２以上、かつ、ログ情報においてアクセス量がＶ１以下
２．傾向情報においてアクセス量がＴ１以下、かつ、ログ情報においてアクセス量がＶ２以上
となる時間帯が存在するかを検出する。上記１．は、通常はアクセス量が多い時間帯なのに、今週はメンテナンス作業が行われていない可能性がある時間帯を検出するための条件であり、上記２．は、通常はアクセス量が少ない時間帯に不正なアクセスが発生している可能性がある時間帯を検出するための条件である。
図１０（ａ）および図１０（ｂ）によると、上記１．の条件にあてはまるのは金曜日１８：００〜０：００、上記２．の条件にあてはまるのは水曜日１８：００〜０：００である。したがって、このような時間帯が存在すると、異常検出となる。
【００７０】
なお、すべてのコマンドではなく、特定種類のコマンド、たとえば、リモートログインコマンドだけを対象として傾向検証処理を実行してもよい。また、コマンドの量ではなく、特定種類のメンテナンス作業の実行回数に関して傾向検証してもよい。あるいは、特定の作業者や特定の業務情報システムに限った傾向検証であってもよい。ログインからログアウトまでの時間を作業時間として、各時間帯において作業時間が占める割合に基づき傾向検証を行ってもよい。また、曜日ごとではなく、日付ごとや月ごと、営業日と非営業日のような任意の時間帯区分にてアクセス傾向を集計してもよい。このように、メンテナンス作業が実行された時間帯におけるアクセス内容とその時間帯におけるアクセス傾向との適否については、さまざまな評価条件に基づいて判定できる。
【００７１】
図１１は、業務情報システムへのリモートログイン処理の過程を示すシーケンス図の別例である。
図６に示したように、作業用端末２０２からのアクセスは、ユーザ認証、申請判定および承認判定（開発側承認と運用側承認）という判定過程を経た上で許可される。しかし、先述したスキップ承認がなされてもよいし、定型的なメンテナンス作業については承認不要としてもよい。スケジュール保持部１９０のスケジュール情報には、このような定型的なメンテナンス作業が登録されている。スケジュール情報は、作業予定情報のデータ構造のうち、申請日欄２１４、開発側承認欄２１８、運用側承認欄２２４についての情報を含まないデータ構造となっている。
【００７２】
同図においてＳ５０〜Ｓ６４にて示す処理の内容は、図６において同一の符号を付した処理の内容と同等であるので、図６に示した処理との差異を中心として説明する。まず、ユーザ認証に成功すると（Ｓ５２）、アクセス制御部１６０は現在時刻においてその作業者を指定したメンテナンス作業がスケジュール情報に登録されているかを判定する（Ｓ７０）。もし、現在時刻を作業予定時刻とするメンテナンス作業がスケジュール情報に登録されていれば（Ｓ７０のＹ）、処理はＳ６０にスキップされ、アクセス許可設定となる。すなわち、定型的なメンテナンス作業については、作業者は作業申請をしなくても管理対象装置にアクセスすることができる。もちろん、スケジュール情報に指定されている管理対象装置とは異なる管理対象装置へのアクセスは許可されない。
変形例として、スケジュール保持部１９０に定型的なシステム操作作業がスケジュール情報として登録されている場合には、スケジュール情報に登録されている作業開始時刻の所定時間前になると、リモートアクセス制御装置１００の申請自動生成部（図示せず）が作業申請情報を自動的に生成してもよい。このような方法によっても、作業者が定型的な作業についての作業申請をしなくても管理対象装置にアクセス可能とすることができる。
【００７３】
また、作業申請済み（Ｓ５４のＹ）、かつ、運用側承認済（Ｓ５６のＹ）であって開発側承認が得られていなくても（Ｓ５８のＮ）、スキップ承認が可能なメンテナンス作業であれば（Ｓ７２のＹ）、スキップ通知部１４２がスキップ承認がなされて旨を開発側承認端末２０４に通知した上で（Ｓ７４）、アクセス許可設定となる（Ｓ６０）。なお、同図には示さなかったが、Ｓ５８において、開発側承認者が作業申請を既に却下している場合にはスキップ承認は実行され得ず、アクセス拒否設定となる（Ｓ６２）。
【００７４】
本実施例におけるリモートアクセス制御装置１００は、ログ情報に基づいて業務情報システムへのアクセスの正当性を検証するだけでなく、更に、受託側企業におけるメンテナンス作業の効率化のためにログ情報を解析する機能も備える。このようなログ情報の解析は、状態判定部１７４により実行される。状態判定部１７４によるログ情報の解析は、以下に示す観点から実行される。
【００７５】
１．同一の時間帯において複数の作業者により同一種別のメンテナンス作業が発生していないか
たとえば、木曜日の１８：００〜２０：００の時間帯において、作業者Ｄが管理対象装置Ｅ、作業者Ｆが管理対象装置Ｇ、作業者Ｈが管理対象装置Ｉに対するメンテナンス作業を実行しているとする。そして、これらのメンテナンス作業がいずれもテスト作業であったとする。このような状況においては、たとえば、作業者Ｄが３つの管理対象装置に対するテスト作業をまとめて行った方が作業効率が高くなると考えられる。
【００７６】
状態判定部１７４は、ログ情報、あるいは、ログ情報から生成される傾向情報を参照して、複数の作業者間で同じ作業が重複している時間帯があるか判定する。これは、複数の作業者についてのログ情報を比較することにより検出できる。所定数、たとえば、２以上の作業者についてのログ情報を参照し、同じ作業種別のメンテナンス作業が同一時間帯に発生していれば、検証通知部１４４はこのような時間帯や関連する作業者名、管理対象装置名、作業種別等を開発側承認端末２０４等に通知する。
受託側企業では、このような通知に基づいて、作業者間における役割分担を変更することにより、業務効率を向上させることができる。
【００７７】
２．メンテナンス作業の実行に要する時間が長くなりすぎていないか
通常、メンテナンス作業は処理手順が決まっているため、作業時間をある程度見積もることができる。状態判定部１７４は、ログ情報を参照して、作業時間が所定の上限時間を超えているメンテナンス作業を検出する。検証通知部１４４は、このようなメンテナンス作業の実行日時、作業者名、あるいは、ログ情報から抽出した作業内容等を開発側承認端末２０４に通知する。作業時間は、たとえば、ログインコマンドが入力されてからログアウトコマンドが入力されるまでの時間として計測されてもよい。
受託側企業では、このような通知に基づいて、どのような状況やどのような作業者についてのメンテナンス作業が非効率になっているかを判断できる。上限時間は、メンテナンス作業の種類に応じて設けられてもよいし、作業者ごとに設けられてもよい。たとえば、経験豊富な作業者であれば上限時間を短めに設定し、経験の浅い作業者については長めに上限時間を設定すれば、「その作業者のスキルを考慮するとしても、作業時間がかかりすぎているメンテナンス作業」を特定することができる。
【００７８】
３．同一種別のメンテナンス作業について、作業者による作業時間のばらつきがどの程度か
状態判定部１７４は、ログ情報や、ログ情報から生成される傾向情報に基づいて、所定作業、たとえば、テスト作業に要する作業時間が、作業者間でどの程度ばらついているかを指標化する。単純に、テスト作業についての作業者ごとの平均所要時間をリストにしてもよいし、作業者の経験年数や職位に応じて平均所要時間を分類してもよい。たとえば、職位が低いわりには平均所要時間の短い作業者を、昇進候補としてリストアップしてもよい。検証通知部１４４は、検証結果を開発側承認端末２０４に通知する。
受託側企業では、同じ作業を要するのに作業者によってどの程度の作業時間を要しているかにより、作業者ごとの時間単価を判断することもできる。また、テスト作業に要する作業時間が短い作業者、すなわち、テスト作業に慣れている作業者に優先的にテスト作業を担当させれば、受託側企業全体としての業務効率を向上させることができる。
【００７９】
４．作業を行う時間帯が偏っている作業者がいないか
状態判定部１７４は、ログ情報や、ログ情報から生成される傾向情報に基づいて、作業者ごとの作業時間帯を検出する。たとえば、作業者Ｊは、火曜日の午前中に作業が集中する傾向にあるとする。状態判定部１７４は、上限検証値Ｔ１やＶ１、下限検証値Ｔ２やＶ１に基づいて、特に負荷の高い時間帯や特に負荷の低い時間帯を特定する。検証通知部１４４は、作業者ごとにの作業時間帯に関する情報を開発側承認端末２０４に通知する。
受託側企業では、このような通知に基づいて、作業者Ｊの火曜日午前の作業の一部を別の時間帯にシフトさせることで、作業者Ｊの負荷を平準化させることができる。このようなデータは、運用スケジュールやＳＬＡの内容を見直す上でも客観的で有効な資料となるため、多忙なＳＥの労働環境改善にも資する。
【００８０】
更に、状態判定部１７４は、作業者Ｊが忙しい火曜日の午前中において、作業者Ｋによる作業があまり発生していないことを検出したとする。この場合には、作業者Ｊの火曜日午前の作業の一部を作業者Ｋに移管することにより、作業者間における負荷分散を行うことができる。
【００８１】
５．特定のメンテナンス作業に業務が偏っている作業者がいないか
通常、テスト作業だけを行っていれば、作業者はテスト作業に習熟することになる。しかし、その一方で、スキルが特定作業に偏ってしまう可能性がある。状態判定部１７４は、ログ情報や、ログ情報から生成される傾向情報に基づいて、作業内容が偏っている作業者を検出する。たとえば、作業者ごとの傾向情報を参照して、所定期間において実行されたメンテナンス作業のうち、テスト作業の割合が７０％以上となっている作業者Ｋを検出したとする。検証通知部１４４は、作業内容が偏っている作業者名とその作業種別を開発側承認端末２０４に通知する。
受託側企業では、このような通知に基づいて、作業者Ｋの職務の見直すことにより、作業者Ｋのスキルが多様化するように配慮できる。すなわち、客観的なデータに基づいた合理的なジョブローテーションを実現しやすくなる。上記例の場合、作業者Ｋの実行しているテスト作業の一部を、テスト作業をあまり経験していない作業者Ｌに移管してもよい。
【００８２】
このように、状態判定部１７４は、ログ情報を解析することにより受託側企業の業務効率向上に資するさまざまなデータを生成できる。以上のデータを組み合わせて利用することもできる。たとえば、作業内容がテスト作業に偏っていて、かつ、テスト作業に要する時間がとても短いとき、その作業者はテスト作業に十分習熟しているといえる。このようなときには、テスト作業の一部を別の作業者に移管してもよい。受託側企業全体としての業務負荷が大きい時期には、テスト作業をテスト作業に習熟した作業者に集中的に割り当てることにより目下の業務効率を向上させ、全体としての業務負荷が小さい時期には、テスト作業をテスト作業に習熟していない作業者にも積極的に割り当てることにより、将来的な業務効率の向上が実現されるように作業を割り当ててもよい。
このように、状態判定部１７４によるログ情報の解析結果に応じて、直接的な業務効率向上と将来的な業務効率向上という２つの目的を状況に応じてバランスさせることもできる。
【００８３】
以上、リモートアクセス制御装置１００を実施例に基づいて説明した。
リモートアクセス制御装置１００は、原則として、開発側と運用側のダブルチェックをアクセス許可条件としているため、業務情報システムへの不正アクセスを防止しやすい構成となっている。事前の作業申請と任意のタイミングでの承認という運用により、作業者および承認者に過度の心理的負担をかけないかたちで業務情報システムのセキュリティ管理を実現できる。
また、申請された作業内容やそれに関連する情報のうち、開発側承認者と運用側承認者のそれぞれの判断に資する情報が選択的に提供されるため、各承認者の承認判断にともなう負荷をいっそう軽減できる。
【００８４】
更に、状況に応じて、開発側承認者についての承認をスキップできるため、緊急性の高いメンテナンス作業にも対応しやすい。スキップ承認がなされた旨は、開発側承認者に通知されるので、開発側承認者は事後的に作業内容をチェックすることができる。また、スケジュール化されている定型的なメンテナンス作業については作業申請不要とすれば、作業者の手続き負担を軽減できる。
【００８５】
リモートアクセス制御装置１００は、アクセス履歴をログ情報として記録し、更に、ログ情報から長期的なアクセス傾向を傾向情報として指標化することができる。申請された作業内容、傾向情報、ＳＬＡに示される作業条件等に鑑みて、メンテナンス作業が正常に行われているかを検証できる。特に、従来においては、ＳＬＡが交わされても、ＳＬＡが遵守されていることを検証するのは困難であった。リモートアクセス制御装置１００の契約検証部１７２は、実際に行われた作業内容をＳＬＡと比較検証できるため、委託側企業は自己の業務情報システムに対して適切なメンテナンスがなされていることを外部的に証明しやすくなる。また、ＳＬＡが遵守されていることを証明しやすい仕組みは、受託側企業は質の高いサービスが提供できることをアピールしやすくなるという効果がある。
【００８６】
更に、リモートアクセス制御装置１００は、ログ情報を積極的に活用することにより受託側企業における業務効率改善にも貢献することができる。既述のように作業者の負荷やスキルなどを多角的に検討することにより、大量の作業員が多くの業務情報システムを管理する現場においても、受託側企業全体としての業務効率を最大化するための対策を立てやすくなる。
【００８７】
更に付け加えるならば、リモートアクセス制御装置１００は、複数の業務情報システムに対するアクセスを一元管理できる。そのため、複数の業務情報システムに対して統一的なアクセスポリシを適用しやすくなっている。本実施例においては、メンテナンス作業について、委託側企業Ａと受託側企業Ｂのように１対１の関係を中心として説明するが、受託側企業Ｂは、複数の委託側企業のメンテナンス作業を請け負う場合についても同様である。たとえば、企業Ｂが、企業Ａだけでなく企業Ｍの業務情報システムのメンテナンス作業も請け負っているとする。この場合、企業Ｂの作業者は、企業Ａ用のリモートアクセス制御装置１００と企業Ｍ用のリモートアクセス制御装置１００のうち、アクセス先の企業に対応したリモートアクセス制御装置１００を介して、目的とする業務情報システムにアクセスすることになる。また、企業Ａ用のリモートアクセス制御装置１００と企業Ｍ用のリモートアクセス制御装置１００のそれぞれのログ情報を集計することにより、企業Ｂについてのログ情報の検証が可能となる。
【００８８】
本実施例においては、業務情報システムにおけるサーバやデータベース等を管理対象装置として説明したが、業務情報システムに限らずルータのような一般的な通信機器のリモートメンテナンスにも応用可能である。
【００８９】
以上、本発明を実施例をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００９０】
請求項に記載の承認入力部の機能は、本実施例においては主として承認受信部１２４により実現される。請求項に記載の作業要求受信部の機能は、本実施例においては主として作業通信部１３６により実現される。請求項に記載の第１の閾値および第２の閾値は、本実施例においては、Ｔ１、Ｖ２として表現されており、請求項に記載の第３の閾値および第４の閾値は、本実施例においては、Ｔ２、Ｖ１として表現されている。
このほかにも、請求項に記載の各構成要件が果たすべき機能は、本実施例において示された各機能ブロックの単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。
【図面の簡単な説明】
【００９１】
【図１】リモートアクセス制御装置と各種業務情報システムとの関係を示すハードウェア構成図である。
【図２】作業の申請と承認についての処理過程を示すシーケンス図である。
【図３】作業用端末に表示される申請画面を示す図である。
【図４】開発側承認端末に表示される開発側承認画面を示す図である。
【図５】運用側承認端末に表示される運用側承認画面を示す図である。
【図６】業務情報システムへのリモートログイン処理の過程を示すシーケンス図の一例である。
【図７】リモートアクセス制御装置の機能ブロック図である。
【図８】作業予定保持部における作業予定情報のデータ構造図である。
【図９】ログ保持部におけるログ情報のデータ構造図である。
【図１０】（ａ）傾向情報に基づいてアクセス量をグラフ化した図である。（ｂ）ログ情報に基づいてアクセス量をグラフ化した図である。
【図１１】業務情報システムへのリモートログイン処理の過程を示すシーケンス図の別例である。
【符号の説明】
【００９２】
１００ リモートアクセス制御装置、 １１０ ユーザインタフェース処理部、 １２０ 申請通信部、 １２２ 作業申請受信部、 １２４ 承認受信部、 １２６ 開発側承認受信部、 １２８ 運用側承認受信部、 １３０ 申請送信部、 １３２ 開発側申請送信部、 １３４ 運用側申請送信部、 １３６ 作業通信部、 １４０ 通知部、 １４２ スキップ通知部、 １４４ 検証通知部、 １５０ データ処理部、 １５２ 作業予定登録部、 １５４ 作業記録部、 １５６ ログ記録部、 １５８ 傾向記録部、 １６０ アクセス制御部、 １６２ 承認判定部、 １６４ 作業検証部、 １６６ 異常判定部、 １６８ 申請検証部、 １７０ 傾向判定部、 １７２ 契約検証部、 １７４ 状態判定部、 １７６ ユーザ認証部、 １８０ データ保持部、 １８２ 作業予定保持部、 １８４ ログ保持部、 １８６ 傾向保持部、 １８８ 契約保持部、 １９０ スケジュール保持部、 １９２ 関連情報保持部、 １９４ ユーザ情報保持部、 ２００ メンテナンス実行環境、 ２０２ 作業用端末、 ２０４ 開発側承認端末、 ２５０ 申請画面、 ２７０ 開発側承認画面、 ３００ 運用環境、 ３２０ 運用側承認端末、 ３４０ 運用側承認画面。
【特許請求の範囲】
【請求項１】
ユーザの操作に基づく制御命令の送信により管理対象装置のシステム操作を行う作業用端末と前記管理対象装置のそれぞれと接続され、
前記作業用端末から、システム操作により実行されるシステム作業の実行予定者の指定を含む作業申請情報を受信する作業申請受信部と、
開発側責任者としてシステム作業の実行可否を判断する開発側承認者の開発側承認端末に対し、前記作業申請情報を送信する開発側申請部と、
前記開発側承認端末から、前記作業申請情報に対する承認可否を示す開発側承認情報を受信する開発側承認受信部と、
運用側責任者としてシステム作業の実行可否を判断する運用側承認者の運用側承認端末に対し、前記作業申請情報を送信する運用側申請部と、
前記運用側承認端末から、前記作業申請情報に対する承認可否を示す運用側承認情報を受信する運用側承認受信部と、
前記作業用端末から、システム作業の実行予定者の指定を含む作業実行要求を受信する作業要求受信部と、
前記作業実行要求に指定された実行予定者を対象とするシステム作業が前記開発側承認者と前記運用側承認者のそれぞれにより承認済であるか否かを判定する承認判定部と、
前記開発側承認者と前記運用側承認者の双方により承認済であることをアクセス許可条件として、前記作業用端末から送信される制御命令を前記管理対象装置に転送するアクセス制御部と、
を備えることを特徴とするリモートアクセス制御装置。
【請求項２】
前記アクセス制御部は、前記開発側承認者による承認をスキップ可能な設定にてシステム作業の申請がなされたときには、前記開発側承認者による承認の有無に関わらず前記作業用端末から送信される制御命令を前記管理対象装置に転送することを特徴とする請求項１に記載のリモートアクセス制御装置。
【請求項３】
前記開発側承認者による承認をスキップして前記管理対象装置へのアクセスが許可されたとき、前記開発側承認端末に対してスキップがなされた旨を通知する事後通知部、
を更に備えることを特徴とする請求項１または２に記載のリモートアクセス制御装置。
【請求項４】
前記開発側申請部は、前記作業申請情報の中から前記開発側承認者の判断に資する一部分の情報を抽出して前記開発側承認端末に送信し、
前記運用側申請部は、前記運用側承認者の判断に資する情報として、前記作業申請情報の中から前記一部分とは異なる部分の情報を抽出して前記運用側承認端末に送信することを特徴とする請求項１から３のいずれかに記載のリモートアクセス制御装置。
【請求項５】
前記作業申請情報に含まれる情報に対する関連情報を保持する関連情報保持部、を更に備え、
前記開発側申請部は、前記作業申請情報の関連情報うち前記開発側承認者の判断に資する関連情報を選択して前記開発側承認端末に送信し、
前記運用側申請部は、前記開発側承認者の判断に資する情報として、前記作業申請情報の関連情報のうち前記選択された関連情報とは異なる関連情報を選択して前記運用側承認端末に送信することを特徴とする請求項１から４のいずれかに記載のリモートアクセス制御装置。
【請求項６】
ユーザの操作に基づく制御命令の送信により管理対象装置のシステム操作を行う作業用端末と前記管理対象装置のそれぞれと接続され、
前記作業用端末から、システム操作により実行されるシステム作業の実行予定者の指定を含む作業申請情報を受信する作業申請受信部と、
申請されたシステム作業に対する承認可否の入力を受け付ける承認入力部と、
申請されたシステム作業をその承認状態と共に作業予定情報に登録する作業予定登録部と、
前記作業用端末から、システム作業の実行予定者の指定を含む作業実行要求を受信する作業要求受信部と、
前記作業予定情報を参照して、前記作業実行要求に指定された実行予定者を対象とするシステム作業が承認済か否かを判定する承認判定部と、
承認済であることをアクセス許可条件として、前記作業用端末から送信される制御命令を前記管理対象装置に転送するアクセス制御部と、
前記管理対象装置に対する作業の実行スケジュールがあらかじめ定められたスケジュール情報を保持するスケジュール保持部と、を備え、
前記アクセス制御部は、前記スケジュール情報にあらかじめ登録されているシステム作業については、承認済か否かに関わらず、前記作業用端末から送信される制御命令を前記管理対象装置に転送することを特徴とするリモートアクセス制御装置。
【請求項１】
ユーザの操作に基づく制御命令の送信により管理対象装置のシステム操作を行う作業用端末と前記管理対象装置のそれぞれと接続され、
前記作業用端末から、システム操作により実行されるシステム作業の実行予定者の指定を含む作業申請情報を受信する作業申請受信部と、
開発側責任者としてシステム作業の実行可否を判断する開発側承認者の開発側承認端末に対し、前記作業申請情報を送信する開発側申請部と、
前記開発側承認端末から、前記作業申請情報に対する承認可否を示す開発側承認情報を受信する開発側承認受信部と、
運用側責任者としてシステム作業の実行可否を判断する運用側承認者の運用側承認端末に対し、前記作業申請情報を送信する運用側申請部と、
前記運用側承認端末から、前記作業申請情報に対する承認可否を示す運用側承認情報を受信する運用側承認受信部と、
前記作業用端末から、システム作業の実行予定者の指定を含む作業実行要求を受信する作業要求受信部と、
前記作業実行要求に指定された実行予定者を対象とするシステム作業が前記開発側承認者と前記運用側承認者のそれぞれにより承認済であるか否かを判定する承認判定部と、
前記開発側承認者と前記運用側承認者の双方により承認済であることをアクセス許可条件として、前記作業用端末から送信される制御命令を前記管理対象装置に転送するアクセス制御部と、
を備えることを特徴とするリモートアクセス制御装置。
【請求項２】
前記アクセス制御部は、前記開発側承認者による承認をスキップ可能な設定にてシステム作業の申請がなされたときには、前記開発側承認者による承認の有無に関わらず前記作業用端末から送信される制御命令を前記管理対象装置に転送することを特徴とする請求項１に記載のリモートアクセス制御装置。
【請求項３】
前記開発側承認者による承認をスキップして前記管理対象装置へのアクセスが許可されたとき、前記開発側承認端末に対してスキップがなされた旨を通知する事後通知部、
を更に備えることを特徴とする請求項１または２に記載のリモートアクセス制御装置。
【請求項４】
前記開発側申請部は、前記作業申請情報の中から前記開発側承認者の判断に資する一部分の情報を抽出して前記開発側承認端末に送信し、
前記運用側申請部は、前記運用側承認者の判断に資する情報として、前記作業申請情報の中から前記一部分とは異なる部分の情報を抽出して前記運用側承認端末に送信することを特徴とする請求項１から３のいずれかに記載のリモートアクセス制御装置。
【請求項５】
前記作業申請情報に含まれる情報に対する関連情報を保持する関連情報保持部、を更に備え、
前記開発側申請部は、前記作業申請情報の関連情報うち前記開発側承認者の判断に資する関連情報を選択して前記開発側承認端末に送信し、
前記運用側申請部は、前記開発側承認者の判断に資する情報として、前記作業申請情報の関連情報のうち前記選択された関連情報とは異なる関連情報を選択して前記運用側承認端末に送信することを特徴とする請求項１から４のいずれかに記載のリモートアクセス制御装置。
【請求項６】
ユーザの操作に基づく制御命令の送信により管理対象装置のシステム操作を行う作業用端末と前記管理対象装置のそれぞれと接続され、
前記作業用端末から、システム操作により実行されるシステム作業の実行予定者の指定を含む作業申請情報を受信する作業申請受信部と、
申請されたシステム作業に対する承認可否の入力を受け付ける承認入力部と、
申請されたシステム作業をその承認状態と共に作業予定情報に登録する作業予定登録部と、
前記作業用端末から、システム作業の実行予定者の指定を含む作業実行要求を受信する作業要求受信部と、
前記作業予定情報を参照して、前記作業実行要求に指定された実行予定者を対象とするシステム作業が承認済か否かを判定する承認判定部と、
承認済であることをアクセス許可条件として、前記作業用端末から送信される制御命令を前記管理対象装置に転送するアクセス制御部と、
前記管理対象装置に対する作業の実行スケジュールがあらかじめ定められたスケジュール情報を保持するスケジュール保持部と、を備え、
前記アクセス制御部は、前記スケジュール情報にあらかじめ登録されているシステム作業については、承認済か否かに関わらず、前記作業用端末から送信される制御命令を前記管理対象装置に転送することを特徴とするリモートアクセス制御装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２００８−１１７００９（Ｐ２００８−１１７００９Ａ）
【公開日】平成２０年５月２２日（２００８．５．２２）
【国際特許分類】
【出願番号】特願２００６−２９７０２６（Ｐ２００６−２９７０２６）
【出願日】平成１８年１０月３１日（２００６．１０．３１）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
【公開日】平成２０年５月２２日（２００８．５．２２）
【国際特許分類】
【出願日】平成１８年１０月３１日（２００６．１０．３１）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
[ Back to top ]