JP2008117316A - 業務情報防護装置 - Google Patents

Abstract

【課題】業務情報システムの情報セキュリティを高め、かつ、そのアクセスルールを管理しやすい仕組みを提供する。
【解決手段】業務情報システムと、その業務情報システムのメンテナンス作業を行う作業用端末のそれぞれと接続される業務情報防護装置に関する。業務情報防護装置は、メンテナンス作業の申請を受け付け、申請されたメンテナンス作業とその作業予定者を対応づけた作業予定情報を保持する。そして、業務情報システムのメンテナンス作業の実行に際しては、作業者を示すユーザ識別情報を作業用端末から受信し、作業者がそもそも正規ユーザとして登録されているか否か、メンテナンス作業が申請済か否かを判定し、この２段階の判定が共に肯定判定となることを条件として、作業用端末から業務情報システムへのメンテナンス作業用アクセスを許可する。
【選択図】図４

Description

この発明は、組織業務を管理するための業務情報システムに関連し、特に、業務情報システムの情報セキュリティを向上させるための技術、に関する。

企業や公共施設などの運用を支える業務情報システム、いわゆるエンタープライズシステム（Enterprise System）は、今や、大小さまざまな組織の基盤となっている。業務情報システムは、ノード端末やデータベースから得られるデータを集計、蓄積、解析、加工した上でより付加価値の高い情報を出力することにより、複雑化する組織マネジメントを支えている。

このような業務情報システムは、稼働後も、動作監視、障害対応、機能拡張や機能変更などのさまざまなメンテナンス作業を必要とする。通常、業務情報システムを導入するクライアント企業は、外部の管理会社にこのメンテナンス作業を委託する。管理会社のＳＥ（System Engineer）は、業務情報システムにリモートログインしてメンテナンス作業を行うことが多い。
特開２００４−２１３４７５号公報

ところで、近年、アメリカで成立したＳＯＸ（Sarbanes‐Oxley）法は、企業経営者や会計監査人に対して公開情報の正当性を保証するように強く求めている。これに倣って、日本でも日本版ＳＯＸ法が導入される予定であり、日本版ＳＯＸ法に対応できる態勢の確立が急務となっている。

このような社会背景に鑑みて、本発明者は、管理会社による業務情報システムへのリモートアクセスに着目し、業務情報システムへのアクセス規制を強化する必要があると認識した。特許文献１は、ＩＤとパスワードによるユーザ認証に加えて、管理者によるアクセス承認を条件とするアクセスルールについて開示する。このようなアクセスルールは、業務情報システムへの不正アクセスを防止する上で有効な手法であるが、管理者は作業申請に即座に対応する必要があるため負担が大きい。本発明者は、情報漏洩を防止しやすいアクセスルールの確立はもちろん重要であるが、ヒューマンエラーの発生を抑制するためにユーザの負担にも配慮する必要があると考えた。

また、企業に導入される業務情報システムが単一システムであるとは限らない。たとえば、ある企業には、財務システムと顧客システムが別々に導入されているかもしれないし、あるいは、それらが更に上位のシステムに統合されているかもしれない。このような複数の業務システムが稼働する企業においても、各業務情報システムの情報セキュリティを高め、かつ、それらのアクセスルールを管理しやすい仕組みが必要である。

本発明は、本発明者の上記課題認識に基づいて完成された発明であり、その主たる目的は、業務情報システムにおける情報セキュリティを向上させるための技術、を提供することにある。

本発明のある態様は、組織業務を管理するための業務情報システムと、その業務情報システムのメンテナンス作業を行う作業用端末のそれぞれと接続される業務情報防護装置である。
この装置は、メンテナンス作業の申請を受け付け、申請されたメンテナンス作業とその作業予定者を対応づけた作業予定情報を保持する。そして、業務情報システムのメンテナンス作業の実行に際しては、作業者を示すユーザ識別情報を作業用端末から受信し、作業者がそもそも正規ユーザとして登録されているか否か、メンテナンス作業が申請済か否かを判定し、この２段階の判定が共に肯定判定となることを条件として、作業用端末から業務情報システムへのメンテナンス作業用アクセスを許可する。

なお、以上の構成要素の任意の組合せ、本発明を方法、システム、記録媒体、コンピュータプログラムにより表現したものもまた、本発明の態様として有効である。

本発明によれば、業務情報システムにおける情報セキュリティを向上させることができる。

図１は、業務情報防護装置１００と各種業務情報システムとの関係を示すハードウェア構成図である。
同図に示すクライアント環境３００は、ある企業Ａの業務環境を示す。クライアント環境３００は、財務情報システム３１０、顧客情報システム３１２、在庫管理システム３１４という３種類の業務情報システムと、１以上の承認用端末３２０を含む。財務情報システム３１０は、企業Ａの財務情報を管理するシステムである。顧客情報システム３１２は、企業Ａの顧客情報を管理するシステムである。在庫管理システム３１４は、企業Ａの商品の在庫状態を管理するシステムである。承認用端末３２０は、ウェブブラウザを搭載した一般的なＰＣ（Personal Computer）端末である。承認用端末３２０は、必ずしもクライアント環境３００に属する必要はなく、ノートＰＣなどの携帯端末であってもよい。

各業務情報システムは、業務情報防護装置１００を介してインターネット３３０と接続される。クライアント環境３００の各種業務システムは、稼働後も、適宜メンテナンス作業を受ける。このメンテナンス作業は、クライアント環境３００内で行われることもあるが、多くは作業用端末２００からのリモートアクセスにより実行される。このリモートのメンテナンス作業を行うユーザのことを、以下、単に「作業者」とよぶ。作業者は、通常、企業Ａとメンテナンス作業契約を交わした管理会社のＳＥであることが多い。作業者は、作業用端末２００を操作して、インターネット３３０、業務情報防護装置１００を介して、クライアント環境３００の各種業務情報システムにリモートログインする。作業用端末２００と業務情報防護装置１００の間の通信経路は、ＶＰＮ（Virtual Private Network）などによりセキュアな通信経路であることが望ましい。
以下においては、インターネットのような公用回線を介したリモートアクセスを前提として説明するが、業務情報防護装置１００やクライアント環境３００、作業用端末２００は、互いに専用回線にて接続されてもよい。
また、本明細書においては、各種の業務情報システムの運用により組織業務を実行する側の企業であって、外部の作業用端末２００からメンテナンス作業というサービスを受けるクライアントという意味で「クライアント企業」や「クライアント環境３００」という用語を使用するものとする。

業務情報防護装置１００は、作業用端末２００から各業務情報システムへのリモートログイン要求を一元的に受け付ける。そして、以下の２段階の判定が共に肯定判定となったことを条件として、リモートログインを許可する。
１．作業者があらかじめ登録されているユーザであるか（以下、「ユーザ認証」とよぶ）
２．作業者がメンテナンス作業を実行することを事前に（正しく）申請済みであるか（以下、「申請判定」とよぶ）

業務情報防護装置１００は、中継装置１１０、ユーザ認証装置１２０および申請管理装置１４０を含む。業務情報防護装置１００は、中継装置１１０、ユーザ認証装置１２０および申請管理装置１４０の各機能を一体として備える単一の装置であってもよいが、本実施例においては、以下の理由から、これら３つの装置の集合体であるとして説明する。

一般的には、作業者は自端末からターミナルサーバにリモートログインし、このターミナルサーバによってユーザ認証されることを条件として、業務情報システムへのアクセスが許可されるというシステム構成となることが多い。本実施例においては、このような従来システムに加えて、ユーザ認証装置１２０と申請管理装置１４０を導入することによって、申請判定による情報セキュリティの向上を図っている。すなわち、同図に示す中継装置１１０は、既存のターミナルサーバであってもよい。本実施例における中継装置１１０は、ＷＩＮＤＯＷＳ（登録商標）を搭載した一般的なＰＣ端末であるとして説明する。

ユーザ認証装置１２０は、中継装置１１０に代わって「ユーザ認証」を実行する。まず、作業用端末２００のユーザは、従来と同じように中継装置１１０にリモートログインする。このときユーザＩＤとパスワードが中継装置１１０に送信される。ユーザ認証装置１２０は、このユーザＩＤとパスワードを受け取ってユーザ認証を実行し、その結果を中継装置１１０に返す。詳しくは図９に関連して後述する。

申請管理装置１４０は、ユーザＩＤとパスワードを受け取って「申請判定」を実行する。作業者は、業務情報システムへのリモートログインに先立って、どのような作業をいつ実行する予定であるかをあらかじめ申請しなければならない。申請管理装置１４０は、このような作業予定を一元的に管理しており、作業者からのリモートログイン要求を受け付けると、その作業者がなんらかのメンテナンス作業を事前に申請しているか確認する。ユーザ認証に成功し、かつ、作業申請済みであることが、業務情報システムへのアクセスが許可される条件である。
本実施例の業務情報防護装置１００の主たるメリットとして、以下の４つを挙げることができる。
１．ユーザ認証に加えて申請判定を行うため、業務情報システムの情報セキュリティが強化される。
２．既に運用されている業務情報システムへの導入が容易である。
３．申請判定に関連するユーザの負荷が軽減される。
４．複数種類の業務情報システムを単一の業務情報防護装置１００によって一元管理できる。
以上について、特に、上記３．や上記４．を中心として、業務情報防護装置１００の機能および作用について説明する。

図２は、業務情報防護装置１００の機能ブロック図である。
ここに示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。ここでは、各部の機能を中心として説明し、それらの連携、データ構造、作用については、図３以降に関連して詳述する。

本実施例における業務情報防護装置１００は、互いに通信回線で接続された中継装置１１０、ユーザ認証装置１２０および申請管理装置１４０を含む。
Ａ：中継装置１１０
中継装置１１０のログインインタフェース処理部１１２は、作業用端末２００からのリモートログイン要求を受け付ける。このリモートログイン要求には、ユーザＩＤとパスワードが含まれる。従来、中継装置１１０は、このユーザＩＤとパスワードに基づいて自らユーザ認証を行っていたが、本実施例においては、このユーザＩＤとパスワードは、ユーザ認証装置１２０によるユーザ認証処理や申請管理装置１４０による申請判定処理のために転送され、中継装置１１０は、それぞれの判定結果を受け取る。以下、ユーザＩＤやパスワードのように、ユーザを識別するためのデータのことを「ユーザ識別情報」とよぶ。変形例として、ユーザ識別情報は、指紋や虹彩などの生体情報であってもよい。

中継装置１１０は、単一の装置でなくてもよい。たとえば、財務情報システム３１０用の中継装置１１０と、顧客情報システム３１２用の中継装置１１０は別々であってもよい。あるいは、作業者は、複数の中継装置１１０のうち任意の中継装置１１０を介して目的とする業務情報システムにアクセスしてもよい。中継装置１１０を複数設けることは、負荷分散や可用性の面からも好ましい。

Ｂ：ユーザ認証装置１２０
ユーザ認証装置１２０は、ユーザ認証部１２２と正規ユーザ情報保持部１２４を含む。正規ユーザ情報保持部１２４は、ユーザＩＤとパスワードを対応づけた正規ユーザ情報を保持する。この正規ユーザ情報に登録されているユーザのことを「正規ユーザ」とよぶ。ユーザ認証部１２２は、ログインインタフェース処理部１１２がリモートログイン要求を受け付けたとき、ログインインタフェース処理部１１２からそのユーザＩＤとパスワードを取得する。そして、その送信元のユーザが正規ユーザとして登録されているかを判定することによりユーザ認証を行う。ユーザ認証部１２２は、作業者だけでなく承認者についてもユーザ認証を実行するが、詳細は後述する。

業務情報システムに対するメンテナンス作業の中には、リリース作業のように業務情報システムに対する影響が特に大きい作業もある。このようなタイプのメンテナンス作業を実行するためには、通常のユーザ権限によるアクセスではなく、アドミニストレータ並のユーザ権限によりアクセスを行う必要がある。しかし、業務情報システムの情報セキュリティ向上という面から見ると、このような特別なユーザ権限（以下、単に「特別権限」とよぶ）を安易に付与することは好ましくない。詳しい仕組みは後述するが、業務情報防護装置１００は、この特別権限を取得できる状態にあるユーザ（以下、「昇格可能ユーザ」とよぶ）を厳密に管理することができる。正規ユーザ情報保持部１２４は、正規ユーザ情報に加えて、昇格可能ユーザを示す昇格ユーザ情報も保持している。昇格ユーザ情報に登録され、昇格可能ユーザとなることを「昇格」、昇格ユーザ情報から抹消され、昇格可能ユーザでなくなることを「降格」とよぶ。

本実施例におけるユーザ認証装置１２０は単一の装置であり、ユーザ識別情報を一元的に管理する。複数の業務情報システムと複数の関係者をつなぐユーザ認証を単一のユーザ認証装置１２０にて実行することにより、ユーザ認証ポリシー（policy）を管理しやすい構成となっている。

Ｃ：申請管理装置１４０
申請管理装置１４０は、申請状態管理部１４２、申請状態判定部１４４、アクセスインタフェース処理部１４６、ログ管理部１４８、昇格処理部１８２、実行条件保持部１５０、作業予定保持部１５２、ログ保持部１５４を含む。

実行条件保持部１５０は、メンテナンス作業についてのアクセスルールを実行条件情報として保持する。メンテナンス作業は、障害対応、調査、稼働監視、リリース作業・・・のようにその目的はさまざまである。メンテナンス作業は、このように複数の種別（以下、単に「作業種別」とよぶ）に分類される。たとえば、業務情報システムへのモジュール追加といったリリース作業は、営業時間外にのみ許可したい場合がある。このような場合、業務情報システムの管理責任者は、リリース作業は営業時間外にのみ実行可能となるように実行条件を設定する。実行条件保持部１５０のデータ構造については、次の図３に関連して更に詳述する。

作業者は、業務情報システムにアクセスするためには、メンテナンス作業の実行をあらかじめ申請しなければならない。申請状態管理部１４２は、この作業の申請に関する処理を担当する。申請状態管理部１４２は、作業申請部１５６、作業承認部１５８、申請通知部１６０および登録判定部１６２を含む。

作業者は、作業を開始する前に、作業用端末２００から申請管理装置１４０に作業申請情報を送信する。作業申請情報とは、後の図４に示す申請画面２２０において入力されるデータの集合である。後の図４では、入力データとして、作業目的、作業日時、件名、アクセス対象となるシステム名などが示されるが、このほかにも、申請者のメールアドレスなどさまざまな情報が含まれてもよい。更に、申請日時や申請者のＩＰアドレスなど、入力されたデータ以外の付帯情報が含まれてもよい。作業申請部１５６は、作業用端末２００から作業申請情報を受信する。登録判定部１６２は、受信された作業申請情報が実行条件情報と適合しているかを判定する。先ほどの例でいえば、営業時間中を対象としてリリース作業が申請された場合、登録判定部１６２は申請を却下し、その旨を作業者に通知する。申請内容が実行条件情報と適合していれば、登録判定部１６２は作業予定保持部１５２の作業予定情報に、申請された作業を登録する。こうして作業予定情報に登録された作業申請のことを「有効な作業申請」とよぶ。作業予定情報の内容は、作業申請情報の内容と実質的に同等であってもよい。すなわち、受信された作業申請情報のうち、有効な作業申請としての要件を満たす作業申請情報だけが「作業予定情報」として作業予定保持部１５２に正式登録されることになる。登録判定部１６２は、有効な作業申請がなされると、作業を一意に識別するための作業ＩＤを付与する。作業予定情報では、作業ＩＤ、作業予定日時、作業内容、作業者名、承認状態等が対応づけられる。

有効な作業申請さえ行えば作業開始可能なタイプのメンテナンス作業だけでなく、承認がなされなければ作業開始できないタイプのメンテナンス作業もある。実行条件情報の一部として、このような定義がなされてもよい。申請通知部１６０は、有効な作業申請が登録されると、その申請された作業内容が承認を必要とするものであるか否かを実行条件情報を参照して判定する。申請通知部１６０は、承認が必要なメンテナンス作業が有効に申請されたときには、その作業ＩＤを承認者に通知する。本実施例における申請通知部１６０は、作業ＩＤを示す電子メールを承認用端末３２０に送信する。承認者は、通知を受けると、作業ＩＤに基づいて申請管理装置１４０にアクセスし、承認可否を入力する。作業承認部１５８は、この承認可否を承認用端末３２０から受け付ける。

作業承認部１５８は、承認がなされると、作業予定情報における承認状態を「未承認」から「承認」に変更する。却下の場合には、作業承認部１５８は作業者に申請却下の旨を通知すると共に、作業予定情報から該当作業を抹消する。また、登録判定部１６２は、作業予定情報に登録されている作業のうち、作業予定日時を経過した作業や、すでに完了した作業を適宜、作業予定情報から抹消する。

申請状態判定部１４４は、申請判定を実行する。作業者からリモートログイン要求が受け付けられたとき、ログインインタフェース処理部１１２から取得したユーザ識別情報と作業予定情報を参照して、作業申請済か否かを判定する。また、リモートログイン要求の受信日時が、申請された作業時間内にあるかについても判定する。たとえば、「１０：００〜１１：００」という作業予定時間を指定して申請されているときには、１０：００以前や１１：００以後にリモートログイン要求をしてきても申請判定の結果は「否定」となり、リモートログインは許可されない。ユーザ認証と申請判定が共に肯定判定となると、アクセスインタフェース処理部１４６は、作業用端末２００からクライアント環境３００へアクセスするための通信経路を開放する。
もちろん、承認が必要なメンテナンス作業が申請されているときには、承認済みでなければアクセス許可されない。

ログ管理部１４８は、作業用端末２００からクライアント環境３００へのアクセスログを管理する。ログ管理部１４８は、ログ記録部１７８と作業検証部１８０を含む。
ログ記録部１７８は、リモートログイン要求の実行、作業用端末２００と業務情報システムの間で送受されるコマンドやデータ、その実行日時をアクセスログとして記録する。ログ保持部１５４は、このアクセスログを保持する。作業検証部１８０は、アクセスログの内容と、申請されていた作業内容とを比較して、不正アクセスがなされていないかをチェックする。たとえば、「稼働監視」を目的とした作業申請がなされているときに、ファイルの書き換え処理の実行がなされたときには、作業検証部１８０はアクセスログを参照して、このような不正アクセスを検出する。作業検証部１８０は、承認用端末３２０に対して、不正アクセス、あるいは、不正アクセスの疑いのあるアクセスがあった旨を通知する。あるいは、不正アクセスが検出された時点で、アクセスインタフェース処理部１４６はリモートアクセスを強制的に遮断してもよい。
昇格処理部１８２は、各ユーザの昇格・降格判定を行うが、詳しくは図１０に関連して後述する。

本実施例における申請管理装置１４０は単一の装置であり、申請判定を一元的に実行する。複数の業務情報システムに関する申請判定を単一の申請管理装置１４０にて実行することにより、実行条件や作業予定情報を管理しやすい構成となっている。

図３は、実行条件保持部１５０における実行条件情報のデータ構造図である。
実行条件情報は、各業務情報システムの管理責任者により定められたアクセスルールである。ルールＩＤ欄１６４は、アクセスルールを一意に識別するためのＩＤ（以下、「ルールＩＤ」とよぶ）を示す。アクセスルールが登録されるときに、ルールＩＤが割り当てられる。年月日欄１６６は、アクセスルールの適用日を示す。時間欄１６８は、アクセスルールの適用時間を示す。たとえば、ルールＩＤ「１」のアクセスルールが適用されるのは、企業Ａの営業日であって「６：００〜１６：００」の時間帯である。作業種別欄１７０は、アクセスルールが適用されるメンテナンス作業の作業種別を示す。承認要否欄１７２は、該当作業の実行をするために承認が必要か否かを示す。

たとえば、ルールＩＤ「１」のアクセスルールが適用されるのは、営業日の「６：００〜１６：００」における作業種別「０１」の「障害対応」を目的としたメンテナンス作業と、作業種別「０２」の「調査」を目的としたメンテナンス作業であり、これらについては承認不要である。すなわち、営業日の「６：００〜１６：００」中を作業予定日時として障害対応を目的としたメンテナンス作業を行う場合には、作業者はあらかじめその旨を示す作業申請行うだけでよく、承認は不要である。一方、営業日の「６：００〜１６：００」において、「稼働監視」や「リリース作業」を目的とするメンテナンス作業を実行する場合には、作業申請だけでなく承認がなされていなければアクセスできない。

たとえば、作業者Ａが、営業日の「６：００〜１６：００」中の日時Ｔにリモートアクセス要求をしてきたとする。このとき、同図に示す実行条件情報に基づく申請判定の結果は以下の通りである。
１．日時Ｔを作業予定時間として含むような作業の申請がなされていない場合
否定判定となる。
２．日時Ｔを作業予定時間として含む障害対応作業を申請していた場合
肯定判定となる。
３．日時Ｔを作業予定時間として含む稼働監視作業を申請していた場合
申請状態判定部１４４は、作業予定保持部１５２を参照し、申請された稼働監視作業が承認済みであれば肯定判定する。未承認や却下の場合には、否定判定となる。
なお、登録判定部１６２は、同一作業者が同一日時に別々の作業を申請した場合には、そのような申請を自動的に却下する。そのため、日時Ｔを対象として障害対応作業と稼働監視作業の両方を申請するということはできない。

実行条件保持部１５０は、業務情報システムごとに別々の実行条件情報を保持してもよいが、本実施例においては、財務情報システム３１０、顧客情報システム３１２、在庫管理システム３１４に対して共通のアクセスルールを定義した統合的な実行条件情報であるとする。また、本実施例においては、作業種別「０４」の「リリース作業」を実行するには特別権限が必要であるが、それ以外の作業には特別権限は不要であるとして説明する。

図４は、申請画面２２０を示す画面図である。
作業者が作業申請のために申請管理装置１４０にアクセスすると、作業申請部１５６は作業用端末２００に同図に示す申請画面２２０を表示させる。申請画面２２０は、作業用端末２００にウェブページとして表示される画面であるとする。

申請者名領域２２２には、作業を申請するユーザ名を入力する。申請者は、自分以外が作業をするときには、実際に作業を実行する予定のユーザ名を入力する。件名領域２２４には、申請する作業の件名を入力する。システム分類領域２２６からは、対象とする業務情報システムのタイプが選択される。ここでは、財務情報システム３１０が選択されている。アクセスインタフェース処理部１４６は、申請日時において、選択された業務情報システム以外への当該ユーザのアクセスを禁止するように制御してもよい。

システム名領域２２８は、業務情報システムの名前を示し、作業種別領域２３０は、作業種別を示す。内容入力領域２３２は、作業内容などを自由記述するための領域である。アクセス予定日時領域２３４は、作業予定日時を示す。作業者は、申請画面２２０に示される各項目にデータを入力した後、申請ボタン２３６をクリックする。すると、入力されたデータが作業申請情報として申請管理装置１４０に送信される。

図５は、承認画面２６０を示す画面図である。
承認が必要な作業申請がなされた場合、登録判定部１６２は作業ＩＤを承認用端末３２０に通知する。承認者が、作業ＩＤを指定して申請管理装置１４０にアクセスすると、作業承認部１５８は承認用端末３２０に同図に示す承認画面２６０を表示させる。承認画面２６０も、承認用端末３２０にウェブページとして表示される。

申請情報領域２６２は、申請画面２２０に入力された申請内容を示す。承認者名領域２６４は、承認者名を入力するための領域である。承認依頼者名領域２６６は、承認を依頼したユーザ名を入力するための領域である。たとえば、承認権限のあるユーザＢが、ユーザＣに承認を依頼したときには、ユーザＣはユーザＢに代理して承認判断を行う。これは、ユーザＢの休暇中など、特殊な状況に対応するための措置である。通信欄２６８は、作業申請者に対するメッセージを記述する欄である。申請却下の理由を記述したり、申請承認するときには作業内容に条件や注文をつけるための記述がなされてもよい。承認ボタン２７０は承認用、却下ボタン２７２は却下用のボタンである。承認ボタン２７０から却下ボタン２７２のいずれかがクリックされると、入力内容と承認可否を示すデータが申請管理装置１４０に送信される。作業承認部１５８は、このデータを作業用端末２００に、たとえば、電子メールにより送信する。

「リリース作業」のように、特別権限が必要なメンテナンス作業が申請された場合は、承認可否や実行条件情報に基づいて昇格ユーザ情報の更新が行われる。たとえば、営業日の「６：００〜１６：００」中の時間帯を作業予定時間として、リリース作業が申請されたとする。承認がなされると、申請された日時に限り、申請者は昇格する。たとえば、営業日である「２００６年９月２８日」の「１０：００〜１１：００」を作業予定日時として、ユーザＡがリリース作業を申請したとする。この作業が承認されると、作業予定日時として示される期間だけ、ユーザＡは昇格可能ユーザとなる。すなわち、昇格処理部１８２は、２００６年９月２８日の１０：００に至ると、ユーザＡを昇格させ、正規ユーザ情報保持部１２４の昇格ユーザ情報に登録する。また、９月２８日の１１：００に至ったり、リリース作業が終了したときには、ユーザＡを降格させ、昇格ユーザ情報からユーザＡを抹消する。このように、本実施例においては、特別権限は時間制限付きの権限となる。
ここでいう特別権限とは、いわゆるルート（root）権限やアドミニストレータ（administrator）権限であってもよい。すなわち、昇格可能ユーザとは、自己のユーザＩＤにてログインをした後、たとえば、UNIX（登録商標）のいわゆる「suコマンド」などによりルート権限を取得可能なユーザであってもよい。

申請・承認プロセスとは別に、特別権限を付与するか否かを別のアクセスポリシーにて管理してもよい。たとえば、リリース作業が作業者Ｂにより申請され、承認者Ｃに作業承認され、更に、別の承認者Ｄが作業者Ｂへの特別権限付与を許可したことを条件として、作業者Ｂの作業を許可してもよい。このように、「特別権限」という重要な権限の管理者を作業承認者と分離することにより、業務情報防護装置１００の情報セキュリティをいっそう強化することができる。

昇格処理部１８２は、作業申請にかかわらず、所定条件が成立したときに、所定ユーザを昇格させるとしてもよい。たとえば、ユーザＢが災害対応のスペシャリストである場合、昇格処理部１８２は地震の発生を検出すると、ユーザＢを所定時間を限度として昇格させてもよい。また、このような非常時には、作業申請手続きを省略するというアクセスルールであってもよい。すなわち、業務情報防護装置１００が備える震度計が所定値以上の揺れを計測したことをユーザＤの昇格条件としてもよい。他の例として、業務情報システムにおいてコンピュータウィルスが検知されたことを、所定ユーザの昇格条件としてもよい。あるいは、特別権限を有するユーザＣが作業申請の範囲を超えたアクセスをしたときには、ユーザＣを降格させるとしてもよい。すなわち、業務情報防護装置１００やクライアント環境３００において所定の事象が発生したことを昇格・降格条件として、昇格や降格処理を実行してもよい。管理責任者は、昇格処理部１８２に対して昇格・降格条件を外部から設定することもできる。このため、上記のような緊急時においても、適切なユーザを時間制限付きで速やかに昇格させることができる。

図６（ａ）は、作業用端末２００から中継装置１１０にリモートログイン要求するときに、作業用端末２００に表示されるログイン画面２８０を示す。
中継装置１１０は、リモートログイン要求を受け付けると、ログインウィンドウ２８２を作業用端末２００に表示させる。すなわち、中継装置１１０のログインインタフェース処理部１１２が、作業用端末２００のユーザインタフェース画面を提供することになる。作業用端末２００のユーザは、ユーザＩＤやパスワードを入力する。ユーザからみたユーザインタフェースは従来のターミナルサーバが提供するものと同じであるが、入力されたユーザ識別情報はユーザ認証装置１２０や申請管理装置１４０によってそれぞれユーザ認証、申請判定に供される。

ユーザ認証に成功し、申請判定が肯定判定となると、中継装置１１０は次に示す初期画面２９０を作業用端末２００に表示する。あるいは、中継装置１１０ではなく申請管理装置１４０が初期画面２９０を提供するとしてもよい。

図６（ｂ）は、作業用端末２００からのリモートログインが許可されたときに、作業用端末２００に表示される初期画面２９０を示す。
システムアイコン２９２は、財務情報システム３１０や顧客情報システム３１２などの各業務情報システムと対応づけられている。いずれかのアイコンがクリックされると、その業務情報システムにアクセスするためのユーザインタフェース画面が、たとえば、ウェブページとして表示される。このほかにも、TelnetやFtpなどに基づくコマンドラインＵＩが提供されてもよい。これらの業務情報システムアクセス用ＵＩは、申請管理装置１４０のアクセスインタフェース処理部１４６により作業用端末２００に提供される。

たとえば、ユーザが財務情報システム３１０に対応するシステムアイコン２９２を選択して、財務情報システム３１０へのインタフェースを開こうとするときには、アクセスインタフェース処理部１４６は、作業予定情報を参照して、ユーザが財務情報システム３１０を対象とした作業申請をしているかを判定する。申請済み、あるいは、申請済みかつ承認済みでなければ、当該アクセスは禁止される。
リモートログイン時においては、作業者が業務情報防護装置１００に対して、作業申請済みであるか否かに基づいて申請判定がなされる。リモートログインが成功して実際に業務情報システムを指定してアクセスを開始するときには、アクセスインタフェース処理部１４６が、指定された業務情報システムに対する作業申請済みか否かに基づいてアクセス可否を判定する。

図７は、作業申請処理の過程を示すシーケンス図である。
作業用端末２００のユーザは、まず、ユーザＩＤとパスワードを含むユーザ識別情報と共に、中継装置１１０を経由することなく、直接、申請管理装置１４０にアクセスする（Ｓ１０）。たとえば、ユーザは、申請管理装置１４０のリモートログイン画面にてユーザ識別情報を入力してもよい。図６（ａ）に示したように、作業用端末２００のユーザが業務情報防護装置１００にアクセスすると、業務情報防護装置１００はログイン画面２８０として示した画面を作業用端末２００に表示される。このとき、ログイン画面２８０のログインウィンドウ２８２にユーザＩＤやパスワードを入力すると、業務情報防護装置１００はこれらのユーザ識別情報をインターネット３３０を経由で取得することになる。申請管理装置１４０は、ユーザ識別情報をユーザ認証装置１２０に転送する（Ｓ１２）。ユーザ認証装置１２０のユーザ認証部１２２は、正規ユーザ情報を参照してユーザ認証を行う（Ｓ１４）。ユーザ認証に失敗すれば、以降の処理は実行されない。ここでは、ユーザ認証が成功したものとして説明を続ける。

ユーザ認証装置１２０は、ユーザ認証の結果、すなわち、認証成功の旨を申請管理装置１４０に通知する（Ｓ１６）。申請管理装置１４０の作業申請部１５６は、申請画面２２０のためのＨＴＭＬ（Hyper Text Markup Language）データを送信し（Ｓ１８）、作業用端末２００は、申請画面２２０を表示させる（Ｓ２０）。ユーザは、申請画面２２０にデータを入力し、申請ボタン２３６をクリックすると（Ｓ２２）、入力されたデータが作業申請情報として申請管理装置１４０に送信される（Ｓ２４）。

申請管理装置１４０の登録判定部１６２は、申請された作業内容と実行条件情報を比較し、登録可否を判定する（Ｓ２６）。有効な作業申請でなければ、登録判定部１６２は申請を却下した上で、作業用端末２００に却下通知し、以降の処理は実行されない。ここでは、有効な申請であったとして説明を続ける。
登録判定部１６２は、申請されたメンテナンス作業を作業予定保持部１５２の作業予定情報に登録する（Ｓ２８）。このとき作業ＩＤが設定される。承認が必要な作業であれば、申請通知部１６０は承認を求める旨の電子メールを承認用端末３２０に送信する（Ｓ３０）。

図８は、作業承認処理の過程を示すシーケンス図である。
承認用端末３２０が図７のＳ３０において電子メールを受け取ったあと、承認者は任意のタイミングにて、ユーザＩＤとパスワードを含むユーザ識別情報と共に申請管理装置１４０にアクセスする（Ｓ３２）。たとえば、申請管理装置１４０のリモートログイン画面にて入力してもよい。また、承認者はここで作業ＩＤも指定する。図６（ａ）と同様に、承認用端末３２０のユーザが業務情報防護装置１００にアクセスしたときにも、業務情報防護装置１００はログイン画面２８０として示した画面を承認用端末３２０に表示される。このとき、ログイン画面２８０のログインウィンドウ２８２にユーザＩＤやパスワードを入力すると、業務情報防護装置１００はこれらのユーザ識別情報をインターネット３３０を経由で取得することになる。

申請管理装置１４０は、承認者のユーザ識別情報をユーザ認証装置１２０に転送する（Ｓ３４）。ユーザ認証装置１２０のユーザ認証部１２２は、正規ユーザ情報を参照してユーザ認証を行う（Ｓ３６）。ユーザ認証に失敗すれば、以降の処理は実行されない。ここでは、ユーザ認証が成功したものとして説明を続ける。なお、作業者用の正規ユーザ情報と承認者用の正規ユーザ情報は、別々に管理されてもよい。

ユーザ認証装置１２０は、ユーザ認証の結果を示すデータ、ここでは認証成功の旨を示すデータを申請管理装置１４０に通知する（Ｓ３８）。申請管理装置１４０の作業承認部１５８は、承認画面２６０のためのＨＴＭＬデータを送信し（Ｓ４０）、承認用端末３２０は、作業ＩＤにて指定された作業に関する承認画面２６０を表示させる（Ｓ４２）。ユーザは、承認画面２６０にデータを入力し、承認ボタン２７０または却下ボタン２７２をクリックすると（Ｓ４４）、入力されたデータが申請管理装置１４０に送信される（Ｓ４６）。

申請管理装置１４０の作業承認部１５８は、承認可否に応じて作業予定保持部１５２の作業予定情報を更新する（Ｓ４８）。作業承認部１５８は、作業用端末２００に承認可否を通知する（Ｓ５０）。
以上の処理により、有効に申請された作業について承認がなされる。なお、承認者が、申請管理装置１４０にアクセスすると、申請管理装置１４０は承認待ちの作業申請を一覧表示させ、承認者はその中から承認対象となる作業申請を選択するというユーザインタフェースであってもよい。

図９は、業務情報システムへのリモートログイン処理の過程を示すシーケンス図である。
作業者は、作業用端末２００から、まず、中継装置１１０にアクセスする。このとき中継装置１１０は、図６（ａ）に示したログイン画面２８０を作業用端末２００に表示させる。作業者が、ユーザ識別情報をログインウィンドウ２８２に入力すると、作業用端末２００は、ユーザ識別情報を中継装置１１０に送信する（Ｓ６０）。ユーザ認証装置１２０は、中継装置１１０がユーザ識別情報を受信したときに、ユーザ認証装置１２０にユーザ識別情報を転送させる（Ｓ６２）。ユーザ認証装置１２０は、更に、このユーザ識別情報を申請管理装置１４０に転送する（Ｓ６４）。

申請管理装置１４０の申請状態判定部１４４は、ユーザ識別情報と作業予定情報を参照して、現在日時において作業者がなんらかのメンテナンス作業を申請済みであるか判定する（Ｓ６６）。申請済みでなければ（Ｓ６６のＮ）、申請管理装置１４０は中継装置１１０やユーザ認証装置１２０にデータ返送しないため、中継装置１１０のログイン処理はタイムアウトし、リモートログインは失敗する。申請済みであれば（Ｓ６６のＹ）、申請状態判定部１４４は申請判定成功を示すデータをユーザ認証装置１２０に返す（Ｓ６８）。なお、申請された作業に承認が必要であれば、Ｓ６６においては承認済みか否かも考慮の対象となる。また、申請された作業に特別権限が必要であれば、Ｓ６６においては昇格可能ユーザか否かも考慮の対象となる。

ユーザ認証部１２２は、結果通知を受信するとユーザ認証を実行する（Ｓ７０）。ユーザ認証部１２２は、認証の成否を中継装置１１０に通知する（Ｓ７２）。ユーザ認証に失敗している場合（Ｓ７４のＮ）、中継装置１１０のログインインタフェース処理部１１２はログイン失敗処理を行う。ユーザ認証に成功すると（Ｓ７４のＹ）、中継装置１１０は図６（ｂ）に示す初期画面２９０を作業用端末２００に表示させる（Ｓ７６、Ｓ７８）。

このあと、作業者は、初期画面２９０のシステムアイコン２９２を選択して、メンテナンス作業の対象となる業務情報システムにアクセスする。以後は、申請管理装置１４０のアクセスインタフェース処理部１４６は、業務情報システムへのアクセス用画面を作業用端末２００に提供する。また、アクセスインタフェース処理部１４６は、業務情報システムと作業用端末２００の間のデータ送受の中継または遮断を行う。たとえば、１０：００〜１１：００が作業予定時間として申請されているときには、１１：００を超えた時点でアクセスを遮断する。すなわち、アクセスインタフェース処理部１４６は、業務情報システムに対する外部からのアクセスをすべて管理下におくことができる。

図１０は、昇格・降格判定処理の過程を示すシーケンス図である。
申請管理装置１４０は、プロセス開始後、同図に示すＳ８０、Ｓ８２、Ｓ８８の処理を繰り返す。このループ処理の開始タイミングは、所定時間、たとえば、１分間ごととなる。

ループ処理の開始タイミングに至ると、申請管理装置１４０の昇格処理部１８２は、作業予定保持部１５２から作業予定情報を読み出し（Ｓ８０）、昇格させるべきユーザが存在するか判定する（Ｓ８２）。営業日である「２００６年９月２８日」の「１０：００〜１１：００」を作業予定日時として、ユーザＡがリリース作業を申請し、承認されたとする。この場合、２００６年９月２８日の１０：００に至ると、昇格処理部１８２はユーザＡを昇格させる。昇格処理部１８２は、昇格可能ユーザのユーザ識別情報をユーザ認証装置１２０に送信し（Ｓ８４）、正規ユーザ情報保持部１２４の昇格ユーザ情報にユーザＡを登録する（Ｓ８６）。昇格可能ユーザが存在しなければ（Ｓ８２のＮ）、昇格ユーザ登録はなされない。次に、昇格処理部１８２は、降格させるべきユーザが存在するか判定する（Ｓ８８）。さきほどの設例の場合、２００６年９月２８日の１1：００に至ると、ユーザＡを降格させる。昇格処理部１８２は、降格すべきユーザのユーザ識別情報をユーザ認証装置１２０に送信し（Ｓ９０）、正規ユーザ情報保持部１２４の昇格ユーザ情報からユーザＡを抹消する（Ｓ９２）。降格すべきユーザが存在しなければ（Ｓ８８のＮ）、昇格ユーザ情報からの抹消は行われない。

このようなループ処理により、昇格ユーザ情報は定期的に更新される。時間制限付きの特別権限により、業務情報システムの情報セキュリティをいっそう向上させることができる。ユーザは、リモートログインした後に、自ら特別権限を明示的に要求してもよいが、どのような条件で昇格を許すかは、昇格処理部１８２が所定の昇格条件に基づいて判定してもよい。

以上、本実施例に示した業務情報防護装置１００によれば、ユーザ認証に加えて申請判定を行うため、不正アクセスを防止しやすい構成となっている。ユーザ認証だけの場合、ユーザ識別情報の漏洩は、業務情報システムからの情報漏洩に直結しやすい。しかし、業務情報防護装置１００は更に作業申請手続きを要求するため、ユーザ識別情報の漏洩が不正アクセスに直結しにくい。なぜならば、仮にユーザ識別情報を不正に手に入れたとしても、虚偽の作業申請を行ってまで業務情報システムにアクセスするには心理抑制がかかりやすいためである。
また、正当な管理会社のＳＥに対してもクライアント環境３００へのアクセスを規制する仕組みが実現されている。また、作業の申請や承認がログとして記録されるため、事後的なアクセスチェックが容易となる。このため、クライアント企業としても、自システムについてのコンプライアンス（compliance）を証明しやすいというメリットがある。このような特徴により、業務情報防護装置１００は、ＳＯＸ方が求める「内部統制の強化」に資することができる。

申請された作業内容が実行条件情報に適合しないときには、登録判定部１６２は、不審な申請がなされた旨を承認用端末３２０に通知したり、当該ユーザ識別情報を一時的に無効化してもよい。登録判定部１６２のこのような作業申請チェックにより、不正な作業申請を自動的に却下できる。更に、申請だけでなく承認が必要なメンテナンス作業を定義することもできるため、情報セキュリティをいっそう向上させることができる。

また、特別権限が必要なメンテナンス作業を実行するときにも、特別権限に時間制限を設け、業務情報防護装置１００はどのユーザにどのようなタイミングで特別権限を与えるかを一元管理できる。

通常、メンテナンス作業は、あらかじめ実行スケジュールが確定していることが多い。本実施例の業務情報防護装置１００によれば、事前の作業申請と任意のタイミングでの承認という運用により、作業者および承認者に過度の心理的負担をかけないかたちで業務情報システムのセキュリティ管理を実現できる。

業務情報防護装置１００は、アクセスログを記録することもできる。また、ログ管理部１４８は、作業申請された内容と、実際の作業の内容に齟齬が発生していないかをチェックできる。このため、アクセス許可されたあとも、事後的に不正アクセスが発生していないかをチェックできる。

このように、業務情報防護装置１００は、
１．ユーザ認証
２．実行条件と申請された作業内容の適合性の判定
３．リモートログイン要求時における申請判定
４．リモートログイン要求日時と申請された作業予定日時の比較
５．特別権限に関する判定
６．アクセスログに基づく不正アクセス検出
という複数の観点から業務情報システムを防御している。

また、業務情報防護装置１００は、複数の業務情報システムに対するアクセスを一元管理できる。そのため、複数の業務情報システムに対して統一的なアクセスポリシーを適用しやすくなっている。更に、既に運用されている業務情報システムに対して、業務情報防護装置１００を追加するだけで実現できるというメリットもある。
なお、本実施例においては、作業用端末２００からインターネット３３０等の通信ネットワークを介して業務情報防護装置１００にリモートアクセスを行う前提にて説明したが、このような前提は本発明の技術的範囲を制約するものではない。業務情報防護装置１００に直接的に接続されるキーボードやマウス、ディスプレイなどの入出力デバイスを介して業務情報システムにアクセスする運用形態においても、本実施例に示したようなユーザ認証と申請判定による２重判定や、その他の技術的特徴を適用可能であることは当業者には理解されるところである。

以上、本発明を実施例をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

請求項に記載の実行要求受信部の機能は、本実施例においては主としてログインインタフェース処理部１１２により実現される。また、請求項に記載のアクセス制御部の機能は、本実施例においては主としてアクセスインタフェース処理部１４６により実現される。請求項に記載の昇格条件設定部と昇格登録部の機能は、本実施例においては主として昇格処理部１８２により実現される。
このほかにも、請求項に記載の各構成要件が果たすべき機能は、本実施例において示された各機能ブロックの単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。

以上の実施の形態および変形例から把握される発明のいろいろな態様をすでに特許請求の範囲に記載したものも含む形にて以下に例示する。

Ａ１．組織業務を管理するための業務情報システムと業務情報システムのメンテナンス作業を行う作業用端末のそれぞれと接続され、
メンテナンス作業を実行可能な正規ユーザが登録された正規ユーザ情報を保持する正規ユーザ情報保持部と、
当該装置が管理対象とする複数種類の業務情報システムのうちのいずれかの指定と作業予定者の指定と共にメンテナンス作業の実行を申請するための作業申請情報を受信する作業申請受信部と、
前記複数種類の業務情報システムのそれぞれについて、申請されたメンテナンス作業とその作業予定者を対応づけた作業予定情報を保持する作業予定保持部と、
メンテナンス作業の実行に際して、作業対象となる業務情報システムの指定と共に作業者を特定するユーザ識別情報を前記作業用端末から受信する実行要求受信部と、
前記正規ユーザ情報を参照して、前記作業者が正規ユーザとして登録されているか否かを判定するユーザ認証部と、
前記指定された業務情報システムについての作業予定情報を参照して、前記作業者を作業予定者とするメンテナンス作業が申請済であるか否かを判定する申請状態判定部と、
前記ユーザ認証部の判定と前記申請状態判定部の判定が共に肯定判定となることを条件として、前記作業用端末から前記指定された業務情報システムへのメンテナンス作業用アクセスを許可するアクセス制御部と、
を備えることを特徴とする業務情報防護装置。

Ａ２．前記正規ユーザ情報保持部は、前記複数種類の業務情報システムのそれぞれについての正規ユーザを単一の正規ユーザ情報にて管理することを特徴とするＡ１に記載の業務情報防護装置。

Ａ３．メンテナンス作業申請の承認者に対して、申請された作業内容を通知する作業申請通知部と、
前記承認者からの承認入力を受け付ける作業承認取得部と、を更に備え、
前記作業予定保持部は、更に、前記作業予定情報として、申請されたメンテナンス作業とその承認状態を対応づけて保持し、
前記申請状態判定部は、更に、申請されたメンテナンス作業が承認済であるか否かを判定することを特徴とするＡ１または２に記載の業務情報防護装置。

Ａ４．前記複数種類の業務情報システムのそれぞれについて、メンテナンス作業の実行条件が定義された実行条件情報を保持する実行条件保持部と、
申請された作業内容が前記実行条件情報と整合することを条件として、申請されたメンテナンス作業を前記作業予定情報に登録する申請登録判定部と、
を備えることを特徴とするＡ１からＡ３のいずれかに記載の業務情報防護装置。

業務情報防護装置と各種業務情報システムとの関係を示すハードウェア構成図である。 業務情報防護装置の機能ブロック図である。 実行条件保持部における実行条件情報のデータ構造図である。 申請画面を示す画面図である。 承認画面を示す画面図である。 （ａ）作業用端末から中継装置にリモートログイン要求するときに、作業用端末に表示されるログイン画面である。（ｂ）作業用端末からのリモートログインが許可されたときに、作業用端末に表示される初期画面である。 作業申請処理の過程を示すシーケンス図である。 作業承認処理の過程を示すシーケンス図である。 業務情報システムへのリモートログイン処理の過程を示すシーケンス図である。 昇格・降格判定処理の過程を示すシーケンス図である。

符号の説明

１００ 業務情報防護装置、 １１０ 中継装置、 １１２ ログインインタフェース処理部、 １２０ ユーザ認証装置、 １２２ ユーザ認証部、 １２４ 正規ユーザ情報保持部、 １４０ 申請管理装置、 １４２ 申請状態管理部、 １４４ 申請状態判定部、 １４６ アクセスインタフェース処理部、 １４８ ログ管理部、 １５０ 実行条件保持部、 １５２ 作業予定保持部、 １５４ ログ保持部、 １５６ 作業申請部、 １５８ 作業承認部、 １６０ 申請通知部、 １６２ 登録判定部、 １７８ ログ記録部、 １８０ 作業検証部、 １８２ 昇格処理部、 ２００ 作業用端末、 ２２０ 申請画面、 ２６０ 承認画面、 ２８０ ログイン画面、 ２９０ 初期画面、 ３００ クライアント環境、 ３１０ 財務情報システム、 ３１２ 顧客情報システム、 ３１４ 在庫管理システム、 ３２０ 承認用端末。

Claims (8)

1. 組織業務を管理するための業務情報システムと前記業務情報システムのメンテナンス作業を行う作業用端末のそれぞれと接続され、
   メンテナンス作業を実行可能な正規ユーザが登録された正規ユーザ情報を保持する正規ユーザ情報保持部と、
   作業予定者の指定と共にメンテナンス作業の実行を申請するための作業申請情報を受信する作業申請受信部と、
   申請されたメンテナンス作業とその作業予定者を対応づけた作業予定情報を保持する作業予定保持部と、
   前記業務情報システムのメンテナンス作業の実行に際して、作業者を特定するユーザ識別情報を前記作業用端末から受信する実行要求受信部と、
   前記正規ユーザ情報を参照して、前記作業者が正規ユーザとして登録されているか否かを判定するユーザ認証部と、
   前記作業予定情報を参照して、前記作業者を作業予定者とするメンテナンス作業が申請済か否かを判定する申請状態判定部と、
   前記ユーザ認証部の判定と前記申請状態判定部の判定が共に肯定判定となることを条件として、前記作業用端末から前記業務情報システムへのメンテナンス作業用アクセスを許可するアクセス制御部と、
   を備えることを特徴とする業務情報防護装置。
2. メンテナンス作業申請の承認者に対して、申請された作業内容を通知する作業申請通知部と、
   前記承認者からの承認入力を受け付ける作業承認取得部と、を更に備え、
   前記作業予定保持部は、更に、前記作業予定情報として、申請されたメンテナンス作業とその承認状態を対応づけて保持し、
   前記申請状態判定部は、更に、申請されたメンテナンス作業が承認済であるか否かを判定することを特徴とする請求項１に記載の業務情報防護装置。
3. 前記申請状態判定部は、更に、メンテナンス作業の実行日時が申請された作業期間内か否かを判定することを特徴とする請求項１または２に記載の業務情報防護装置。
4. メンテナンス作業の実行条件が定義された実行条件情報を保持する実行条件保持部と、
   申請された作業内容が前記実行条件情報と整合することを条件として、申請されたメンテナンス作業を前記作業予定情報に登録する申請登録判定部と、
   を更に備えることを特徴とする請求項１から３のいずれかに記載の業務情報防護装置。
5. 前記正規ユーザ情報保持部は、更に、通常のユーザ権限とは異なる特別権限を取得可能なユーザを示す昇格ユーザ情報を保持し、
   前記申請状態判定部は、申請されたメンテナンス作業に対する実行条件として特別権限が指定されているときには、更に、作業者が特別権限を取得可能なユーザであるか否かを判定することを特徴とする請求項４に記載の業務情報防護装置。
6. 特別権限の取得可能条件を示す昇格条件の設定入力を受け付ける昇格条件設定部と、
   前記昇格条件が成立するときに、昇格条件の対象となるユーザを前記昇格ユーザ情報に登録する昇格登録部と、
   を備えることを特徴とする請求項５に記載の業務情報防護装置。
7. 前記作業用端末から前記業務情報システムへのアクセス履歴をログ情報として記録するログ記録部、を更に備えることを特徴とする請求項１から６のいずれかに記載の業務情報防護装置。
8. 前記ログ情報を参照して、実行された作業内容が申請された作業内容の範囲内にあるか否かを判定する作業検証部、を更に備えることを特徴とする請求項７に記載の業務情報防護装置。

Images