JP5952466B2 - 業務情報防護装置および業務情報防護方法、並びにプログラム - Google Patents

Description

本発明は、業務情報防護装置および業務情報防護方法、並びにプログラムに関し、特に、業務情報システムの情報セキュリティを向上させることができるようにした業務情報防護装置および業務情報防護方法、並びにプログラムに関する。

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

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

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

このような社会背景に鑑みて、特許文献１には、ＩＤとパスワードによるユーザ認証に加えて、管理者によるアクセス承認を条件とするアクセスルールに関する技術が提案されている。

特開２００４−２１３４７５号公報

特許文献１に記載のアクセスルールは、業務情報システムへの不正アクセスを防止する上で有効な手法であるが、管理者は作業申請に即座に対応する必要があるため負担が大きい。すなわち、情報漏洩を防止しやすいアクセスルールの確立はもちろん重要であるが、ヒューマンエラーの発生を抑制するためにユーザの負担にも配慮する必要がある課題があった。

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

本発明の目的は、業務情報システムにおける情報セキュリティを向上させることができるようにした業務情報防護装置を提供することである。

本発明の一側面は、システムの所定の処理を実行可能な正規ユーザが登録された正規ユーザ情報を保持する正規ユーザ情報保持手段と、アクセス予定者の指定と共に前記所定の処理の実行を申請するための申請情報を受信する申請受信手段と、申請された前記所定の処理とそのアクセス予定者を対応づけた予定情報を保持する予定保持手段と、前記所定の処理の実行に際して、アクセス者を特定するユーザ識別情報を端末から受信する実行要求受信手段と、前記正規ユーザ情報を参照して、前記アクセス者が正規ユーザとして登録されているか否かを判定するユーザ認証手段と、前記予定情報を参照して、前記アクセス者をアクセス予定者とする所定の処理が申請済か否かを判定する申請状態判定手段と、前記ユーザ認証手段の判定と前記申請状態判定手段の判定が共に肯定判定となることを条件として、前記端末から前記システムへの所定の処理のためのアクセスを許可するアクセス制御手段と、前記端末から前記システムへのアクセス履歴をログ情報として記録するログ記録手段と、前記ログ情報に示されるアクセスと前記予定情報で申請された所定の処理のためのアクセスを対比して、前記ログ情報に示されるアクセスの中の、前記予定情報で申請された所定の処理のためのアクセスに合致しないアクセスを、不正アクセスとして検出する検証手段とを備えることを特徴とする。

所定の処理申請の承認者に対して、申請された処理内容を通知する申請通知手段と、前記承認者からの承認入力を受け付ける承認取得手段と更に備え、前記予定保持手段は、更に、前記予定情報として、申請された所定の処理とその承認状態を対応づけて保持し、前記申請状態判定手段は、更に、申請された所定の処理が承認済であるか否かを判定することができる。

前記申請状態判定手段は、更に、所定の処理の実行日時が申請された期間内か否かを判定することができる。

所定の処理の実行条件が定義された実行条件情報を保持する実行条件保持手段と、申請された処理内容が前記実行条件情報と整合することを条件として、申請された所定の処理を前記予定情報に登録する申請登録判定手段とを更に備えることができる。

前記正規ユーザ情報保持手段は、更に、通常のユーザ権限とは異なる特別権限を取得可能なユーザを示す昇格ユーザ情報を保持し、前記申請状態判定手段は、申請された所定の処理に対する実行条件として特別権限が指定されているときには、更に、アクセス者が特別権限を取得可能なユーザであるか否かを判定することができる。

本発明によれば、業務情報システムにおける情報セキュリティを向上させることができるようにした業務情報防護装置を提供することができる。

本実施形態に係る業務情報システムの構成例を示すブロック図である。 業務情報防護装置の機能構成例を示すブロック図である。 実行条件保持部における実行条件情報のデータ構造の例を示す図である。 ログ保持部で保持されるアクセスログの記録内容の例を示す図である。 ログイン画面の表示例を示す図である。 アクセス申請画面の表示例を示す図である。 アクセス承認画面の表示例を示す図である。 アクセス申請・承認レベル設定画面の表示例を示す図である。 アクセスログ検索画面の表示例を示す図である。 検索結果画面の表示例を示す図である。 アクセスチェック処理について説明するフローチャートである。

［業務情報システムの構成］
図１は、本実施形態に係る業務情報システムの構成例を示すブロック図である。同図に示す業務情報システムは、業務情報防護装置１０と作業用端末２０がネットワーク３０を介して接続されているとともに、クライアント環境４０が、業務情報防護装置１０を介してネットワーク３０に接続されている。また業務情報防護装置１０には、ログ管理装置１５も接続されている。

図１に示す業務情報システムにおいて、クライアント環境４０は、ある企業Ａの業務環境を示す。クライアント環境４０の各種業務システムは、稼働後も、適宜メンテナンス作業を受ける。このメンテナンス作業は、クライアント環境４０内で行われることもあるが、多くは作業用端末２０からのリモートアクセスにより実行される。このリモートのメンテナンス作業を行うユーザのことを、以下、単に「作業者」とよぶ。作業者は、通常、企業Ａとメンテナンス作業契約を交わした管理会社のＳＥ（Systems Engineer）であることが多い。作業者は、作業用端末２０を操作して、ネットワーク３０および業務情報防護装置１０を介して、クライアント環境４０の各種業務情報システムにリモートログインする。作業用端末２０と業務情報防護装置１０の間の通信経路は、ＶＰＮ（Virtual Private Network）などによりセキュアな通信経路であることが望ましい。

以下において、ネットワーク３０は、インターネットやローカルエリアネットワーク（ＬＡＮ）等の公用回線を介したリモートアクセスを前提として説明するが、業務情報防護装置１０やクライアント環境４０、作業用端末２０は、互いに専用回線にて接続されてもよい。

また、本明細書においては、各種の業務情報システムの運用により組織業務を実行する側の企業であって、外部の作業用端末２０からメンテナンス作業というサービスを受けるクライアントという意味で「クライアント企業」や「クライアント環境４０」という用語を使用するものとする。

業務情報防護装置１０は、作業用端末２０からクライアント環境４０へのリモートログイン要求を一元的に受け付ける装置であって、ネットワークセキュリティ境界に設置される。業務公報防護装置１０は、TELNET（Telecommunication network）、SSH（Secure SHell）、FTP（File Transfer Protocol）、HTTP（HyperText Transfer Protocol）、HTTPS（Hypertext Transfer Protocol Security）、Windows（登録商標）RDP（Remote Desktop
Protocol）、CIFS（Common Internet File System）などの通信プロトコルのアクセス制御、およびログ取得による監査を行う（その詳細は後述する）。

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

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

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

中継装置１１は、作業用端末２０よりネットワーク３０を介してアクセスされると、当該作業用端末２０のＩＰアドレスやホスト名などを確認し、接続許可対象外であった場合には、直ちに切断し、接続を許可しない。一方、接続許可対象であった場合には、中継装置１１は、作業用端末２０にユーザＩＤとパスワードを要求し、その要求に応じて送信されてきたユーザＩＤとパスワードを、ユーザ認証装置１２、申請管理装置１３、およびアクセス権管理装置１４に供給し、確認を依頼する。

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

申請管理装置１３は、中継装置１１からユーザＩＤとパスワードを受け取って「申請判定」を実行する。作業者は、業務情報システムへのリモートログインに先立って、どのような作業をいつ実行する予定であるかをあらかじめ申請しなければならない。申請管理装置１３は、このような作業予定を一元的に管理しており、作業者からのリモートログイン要求を受け付けると、その作業者がなんらかのメンテナンス作業を事前に申請しているか否かを確認する。業務情報システムへのアクセスが許可される条件は、ユーザ認証に成功し、かつ、作業申請済みであることである。

アクセス権管理装置１４は、中継装置１１に代わって「アクセス権認証」を実行する。つまり、アクセス権管理装置１４は、中継装置１１からユーザＩＤとパスワード、およびアクセス先を示す情報（ＩＰアドレスやホスト名など）を受け取って、当該ユーザがアクセス先へ接続を許可されているか（アクセス権があるか）否かの認証を実行し、その結果を中継装置１１に返す。

中継装置１１、ユーザ認証装置１２、申請管理装置１３、およびアクセス権管理装置１４は、それぞれ正系と副系の２台のサーバからなり、フェールオーバー機能を有している。すなわち、何らかの理由で正系のサーバに障害が発生した場合、副系のサーバに正系のサーバのＩＰアドレスが付加されるように構成されている。具体的には、正系のサーバと副系のサーバには、それぞれ実ＩＰとバーチャルＩＰを所有しており、副系のサーバが正系のサーバを監視し、異常を検知したときに、正系のバーチャルＩＰを取得する。作業者は、バーチャルＩＰに対してアクセスするようになされており、異常発生時には、正系から副系のサーバへのアクセスに自動的に切り替わる。これにより、作業者は、正系のサーバに障害が発生したことを意識することなく、副系のサーバを利用してサービスを継続することができる。

本実施の形態の業務情報防護装置１０の主たるメリットとして、以下の５つを挙げることができる。
１．ユーザ認証に加えて申請判定を行うため、業務情報システムの情報セキュリティが強化される。
２．既に運用されている業務情報システムへの導入が容易である。
３．申請判定に関連するユーザの負荷が軽減される。
４．複数種類の業務情報システムを単一の業務情報防護装置１０によって一元管理できる。
５．申請内容とアクセスログを紐付けるため、アクセスチェックが容易である。

ログ管理装置１５は、中継装置１１で行われるアクセスの内容を取得し、管理する。例えば、アクセス日時やＩＰアドレスといった「サマリーログ」や送受信されたデータの「全文ログ」が取得され、管理される。

ログ管理装置１５は、申請管理装置１３で管理される作業申請内容とログ管理装置１５で管理されるアクセスログを紐付けて管理しており、アクセスチェックを容易に行うことができる。アクセスチェックとは、アクセスログを捜査し、申請された通りのアクセスを行っているか否かのログ監査を行うことである。

作業用端末２０は、作業者によって、クライアント環境４０へリモートログインするためのユーザＩＤとパスワードが入力されると、そのユーザＩＤとパスワードをリモートログイン要求として、ネットワーク３０を介して業務情報防護装置１０に送信する。

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

図２は、業務情報防護装置１０およびログ管理装置１５の機能構成例を示すブロック図である。

図２に示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを示している。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現することができる。

Ａ：中継装置１１
中継装置１１のログインインタフェース処理部１１１は、作業用端末２０からのリモートログイン要求を受け付ける。このリモートログイン要求には、ユーザＩＤとパスワードが含まれる。中継装置１１は、受け付けたユーザＩＤとパスワードを、ユーザ認証装置１２によるユーザ認証処理、申請管理装置１３による申請判定処理、アクセス権管理装置１４によるアクセス権認証処理のために転送する。またログインインタフェース処理部１１１は、作業用端末２０からアクセス先を示す情報（ＩＰアドレスやホスト名など）を取得したとき、取得した情報をアクセス権管理装置１４によるアクセス権認証処理のために転送する。そしてログインインタフェース処理部１１１は、ユーザ認証装置１２、申請管理装置１３、およびアクセス権管理装置１４から、それぞれの判定結果を受け取る。以下、ユーザＩＤやパスワードのように、ユーザを識別するためのデータのことを「ユーザ識別情報」とよぶ。変形例として、ユーザ識別情報は、指紋や虹彩などの生体情報であってもよい。

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

Ｂ：ユーザ認証装置１２
ユーザ認証装置１２は、ユーザ認証部１２１と正規ユーザ情報保持部１２２を含む。ユーザ認証部１２１は、中継装置１１のログインインタフェース処理部１１１がリモートログイン要求を受け付けたとき、ログインインタフェース処理部１１１からそのユーザＩＤとパスワードを取得する。そして、その送信元のユーザが正規のユーザとして正規ユーザ情報保持部１２２に登録されているかを判定することによりユーザ認証を行う。正規ユーザ情報保持部１２２は、ユーザＩＤとパスワードを対応づけた正規ユーザ情報を保持する。この正規ユーザ情報に登録されているユーザのことを「正規ユーザ」とよぶ。ユーザ認証部１２１は、作業者だけでなく承認者についてもユーザ認証を実行するが、詳細は後述する。なお、ユーザ情報保持部１２２は、ユーザ認証装置１２の内部に実装されているが、これに限らず、たとえば、ＬＤＡＰ（Lightweight Directory Access Protocol）サーバなどの外部装置であってもよい。

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

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

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

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

作業者は、作業を開始する前に、作業用端末２０を介して申請管理装置１３に作業申請情報を送信する。作業申請情報とは、作業目的、作業日時、件名、アクセス対象となるシステム名などの入力データの集合であるが、このほかにも、申請者のメールアドレス、申請日時や申請者のＩＰアドレスなど、入力されたデータ以外の付帯情報が含まれてもよい。なお、作業申請情報は、作業用端末２０から送信されるが、これに限らず、たとえば、作業用端末２０とは異なる申請用端末（図示せず）から送信されるようにしてもよい。

作業申請部１３１Ａは、作業用端末２０から作業申請情報を受信する。

登録判定部１３１Ｂは、作業申請部１３１Ａで受信された作業申請情報が、実行条件保持部１３５に登録されている実行条件情報（図３を参照して後述する）と適合しているかを判定する。登録判定部１３１Ｂは、作業申請情報が実行条件情報と適合していないと判定した場合、申請を却下し、その旨を作業用端末２０の作業者に通知する。登録判定部１３１Ｂは、作業申請情報が実行条件情報と適合していると判定した場合、作業予定保持部１３６の作業予定情報に、申請された作業を登録する。こうして作業予定情報に登録された作業申請のことを「有効な作業申請」とよぶ。作業予定情報の内容は、作業申請情報の内容と実質的に同等であってもよい。すなわち、受信された作業申請情報のうち、有効な作業申請としての要件を満たす作業申請情報だけが「作業予定情報」として作業予定保持部１３６に正式登録されることになる。

登録判定部１３１Ｂは、有効な作業申請がなされると、作業を一意に識別するための申請ナンバー（作業ＩＤ）を付与する。作業予定情報では、申請ナンバー、作業予定日時、作業内容、作業者名、承認状態等が対応づけられる。

有効な作業申請さえ行えば作業開始可能なタイプのメンテナンス作業だけでなく、承認がなされなければ作業開始できないタイプのメンテナンス作業もある。実行条件情報の一部として、このような定義がなされていてもよい。

なお、作業予定保持部１３６に登録されている作業予定情報のうち、作業予定日時を経過した作業については、過去に出された申請履歴の状態になり、却下された申請については、申請状態が「却下」として記録された状態になる。

申請通知部１３１Ｃは、有効な作業申請が作業予定保持部１３６に登録されると、その申請された作業内容が承認を必要とするものであるか否かを、実行条件保持部１３５に登録されている実行条件情報を参照して判定する。申請通知部１３１Ｃは、メンテナンス作業が申請された場合、その申請ナンバーを承認者に通知する。本実施の形態における申請通知部１３１Ｃは、申請ナンバーを示す電子メールを承認用端末４４に送信する。承認者は、通知を受けると、承認用端末４４の図示せぬ入力部を操作し、申請ナンバーに基づいて業務情報防護装置１０の申請管理装置１３にアクセスし、承認可否を入力する。

作業承認部１３１Ｄは、承認可否を承認用端末４４から受け付ける。作業承認部１３１Ｄは、承認がなされると、作業予定保持部１３６に登録されている作業予定情報における承認状態を「未承認」から「承認」に変更する。却下の場合には、作業承認部１３１Ｄは、作業者に申請却下の旨を通知すると共に、作業予定保持部１３６に登録されている作業予定情報の申請状態を「却下」として記録する。

申請状態判定部１３２は、申請判定を実行する。作業者からリモートログイン要求が受け付けられたとき、ログインインタフェース処理部１１１から取得したユーザ識別情報と作業予定保持部１３６に登録されている作業予定情報を参照して、作業申請済か否かを判定する。また、申請状態判定部１３２は、リモートログイン要求の受信日時が、申請された作業時間内にあるか否かについても判定する。

たとえば、「１０：００〜１１：００」という作業予定時間を指定して申請されているときには、１０：００以前や１１：００以後にリモートログイン要求をしてきても申請判定の結果は「否定」となり、リモートログインは許可されない。

アクセスインタフェース処理部１３３は、ユーザ認証と申請判定が共に肯定判定となると、作業用端末２０からクライアント環境４０へアクセスするための通信経路を許可する。もちろん、承認が必要なメンテナンス作業が申請されているときには、承認済みでなければアクセス許可されない。

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

作業予定保持部１３６は、申請状態管理部１３１の登録判定部１３１Ｂにより正式登録された、有効な作業申請としての要件を満たす作業予定情報を保持する。

昇格処理部１３８は、所定の時間毎に、作業予定保持部１３６から作業予定情報を読み出し、昇格させるべきユーザが存在するか、降格させるべきユーザが存在するかを判定する。

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

図３は、実行条件保持部１３５における実行条件情報のデータ構造の例を示す図である。

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

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

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

なお、登録判定部１３１Ｂは、同一作業者が同一日時に別々の作業を申請した場合には、そのような申請を自動的に却下する。そのため、作業者は、日時Ｔを対象として障害対応作業と稼働監視作業の両方を申請するということはできない。

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

Ｄ：アクセス権管理装置１４
アクセス権管理装置１４は、アクセス権認証部１４１とアクセス権情報保持部１４２を含む。アクセス権認証部１４１は、中継装置１１のログインインタフェース処理部１１１がリモートログイン要求を受け付けたとき、ログインインタフェース処理部１１１からユーザＩＤとパスワード、およびアクセス先を示す情報（ＩＰアドレスやホスト名など）を取得し、その送信元のユーザがアクセス先に接続を許可されているか（アクセス権があるか）否かを、アクセス権情報保持部１４２に登録されているアクセス申請状況をもとに判定する。アクセス権情報保持部１４２は、ユーザＩＤおよびアクセス先を示す情報に対応づけたアクセス申請状況を保持する。

Ｅ：ログ管理装置１５
ログ管理部１５１は、作業用端末２０からクライアント環境４０へのアクセスログを管理する。ログ管理部１５１は、ログ記録部１５１Ａと作業検証部１５１Ｂを含む。ログ記録部１５１Ａは、リモートログイン要求の実行、作業用端末２０と業務情報システムの間で送受されるコマンドやデータ、その実行日時をアクセスログとして記録する。記録時、ログ記録部１５１Ａは、申請状態管理部１３１の登録判定部１３１Ｂで付与された申請ナンバーと、その申請ナンバーに対応する作業申請内容のアクセスログを結びつける。またログ記録部１５１Ａは、認証失敗や未申請、アクセス権無し等の拒否履歴のログも記録する。

作業検証部１５１Ｂは、ログ保持部１５２で保持されているアクセスログの内容と、そのアクセスログに紐付けられた申請ナンバーに対応する、作業予定保持部１３６に登録されている作業予定情報とを比較して、不正アクセスがなされていないかをチェックする。

たとえば、「稼働監視」を目的とした作業申請がなされているときに、ファイルの書き換え処理の実行がなされたときには、作業検証部１５１Ｂは、ログ保持部１５２で保持されているアクセスログを参照して、このような不正アクセスを検出する。作業検証部１５１Ｂは、承認用端末４４に対して、不正アクセス、あるいは、不正アクセスの疑いのあるアクセスがあった旨を通知する。あるいは、不正アクセスが検出された時点で、アクセスインタフェース処理部１３３はリモートアクセスを強制的に禁止してもよい。

ログ保持部１５２は、申請状態管理部１３１の登録判定部１３１Ｂで付与された申請ナンバーと、その申請ナンバーに対応する作業申請内容のアクセスログを紐付けて保持する。ログ保持部１５２で保持するアクセスログの記録内容については、図４を参照して後述する。

図４は、ログ保持部１５２で保持されるアクセスログの記録内容の例を示す図である。

ログ保持部１５２は、サマリーログ記録領域１５２Ａと全文ログ記録領域１５２Ｂを含み、サマリーログと全文ログの２種類のログを保持している。サマリーログは、アクセスの開始、終了時刻、利用端末、アクセス先サーバのＩＰアドレスやホスト名、利用ＩＤ、接続時間などを含む。全文ログは、実際にコマンドなどを実行・操作した内容を含む。

図４の例の場合、サマリーログ記録領域１５２Ａと全文ログ記録領域１５２Ｂには、それぞれプロトコル毎に主な記録内容が保持されている。たとえば、「ＴＥＬＮＥＴ」のプロトコルの場合、サマリーログ記録領域１５２Ａには、アクセス開始日時、ポート、接続元ＩＰアドレス、ユーザＩＤ、接続先ＩＰアドレス、接続時間が記録され、全文ログ記録領域１５２Ｂには、受信データが記録される。

以上示したアクセスログの記録内容が、申請ナンバーに紐付けてログ保持部１５２で保持される。なお、WindowsRDPで取得されるアクセスログは動画形式で記録される。

図５は、ログイン画面の表示例を示す図である。

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

図６は、アクセス申請画面の表示例を示す図である。

図６に示すアクセス申請画面６０は、作業者が作業申請のために、作業用端末２０から申請管理装置１３にアクセスするときに作業用端末２０に表示される。すなわち、申請状態管理部１３１の作業申請部１３１Ａは、作業用端末２０からアクセスされると、作業用端末２０にアクセス申請画面６０をウェブページとして表示させる。

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

システム名領域６４は、業務情報システムの名前を示し、作業種別領域６５は、作業種別を示す。内容入力領域６６は、作業内容などを自由記述するための領域である。添付ファイル領域６７は、利用する手順書等の電子ファイルを添付するための領域である。アクセス予定日時領域６８は、作業予定日時を示す。作業者は、申請画面６０に示される各項目にデータを入力した後、申請ボタン６９をクリックする。すると、作業用端末２０は、入力されたデータを作業申請情報として申請管理装置１３に送信する。

アクセス申請時に、申請者名、件名、システム分類、システム名、作業種別、内容、およびアクセス予定日時の他、実際に利用する手順書等が記載された電子ファイルを添付することにより、作業申請情報とともに付随する電子ファイルを一元管理することが可能となる。

図７は、アクセス承認画面の表示例を示す図である。

図７に示すアクセス承認画面７０は、承認が必要な作業申請がなされた場合、承認用端末４４に表示される。すなわち、申請状態管理部１３１の登録判定部１３１Ｂは、承認が必要な作業申請がなされたとき、申請ナンバーを承認用端末４４に通知する。承認者が、申請ナンバーを指定して申請管理装置１３にアクセスすると、作業承認部１３１Ｄは承認用端末４４にアクセス承認画面７０をウェブページとして表示させる。

申請情報領域７１は、アクセス申請画面６０に入力された申請内容を示す。承認者名領域７２は、承認者名を入力するための領域である。承認依頼者名領域７３は、承認を依頼したユーザ名を入力するための領域である。たとえば、承認権限のあるユーザＢが、ユーザＣに承認を依頼したときには、ユーザＣはユーザＢに代理して承認判断を行う。これは、ユーザＢの休暇中など、特殊な状況に対応するための措置である。

通信欄７４は、作業申請者に対するメッセージを記述する欄であり、申請却下の理由を記述したり、申請承認するときには作業内容に条件や注文をつけるための記述がなされてもよい。承認ボタン７５は承認用、却下ボタン７６は却下用のボタンである。承認ボタン７５から却下ボタン７６のいずれかがクリックされると、入力内容と承認可否を示すデータが申請管理装置１３に送信される。作業承認部１３１Ｄは、このデータを作業用端末２０に、たとえば、電子メールにより送信する。

「リリース作業」のように、特別権限が必要なメンテナンス作業が申請された場合は、承認可否や実行条件情報に基づいて昇格ユーザ情報の更新が行われる。たとえば、営業日の「６：００〜１６：００」中の時間帯を作業予定時間として、リリース作業が申請されたとする。承認がなされると、申請された日時に限り、申請者は昇格する。たとえば、営業日である「２００６年９月２８日」の「１０：００〜１１：００」を作業予定日時として、ユーザＡがリリース作業を申請したとする。この作業が承認されると、作業予定日時として示される期間だけ、ユーザＡは昇格可能ユーザとなる。すなわち、昇格処理部１３８は、２００６年９月２８日の１０：００に至ると、ユーザＡを昇格させ、正規ユーザ情報保持部１２２の昇格ユーザ情報に登録する。また、９月２８日の１１：００に至ったり、リリース作業が終了したときには、ユーザＡを降格させ、昇格ユーザ情報からユーザＡを抹消する。このように、本実施の形態においては、特別権限は時間制限付きの権限となる。

ここでいう特別権限とは、いわゆるルート（root）権限やアドミニストレータ（administrator）権限であってもよい。すなわち、昇格可能ユーザとは、自己のユーザＩＤにてログインをした後、たとえば、UNIX（登録商標）のいわゆる「suコマンド」などによりルート権限を取得可能なユーザであってもよい。

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

昇格処理部１３８は、作業申請にかかわらず、所定条件が成立したときに、所定ユーザを昇格させるとしてもよい。たとえば、ユーザＢが災害対応のスペシャリストである場合、昇格処理部１３８は地震の発生を検出すると、ユーザＢを、所定時間を限度として昇格させてもよい。また、このような非常時には、作業申請手続きを省略するというアクセスルールであってもよい。すなわち、業務情報防護装置１０が備える震度計が所定値以上の揺れを計測したことを、ユーザＤの昇格条件としてもよい。

他の例として、業務情報システムにおいてコンピュータウィルスが検知されたことを、所定ユーザの昇格条件としてもよい。あるいは、特別権限を有するユーザＣが作業申請の範囲を超えたアクセスをしたときには、ユーザＣを降格させるとしてもよい。すなわち、業務情報防護装置１０やクライアント環境４０において所定の事象が発生したことを昇格・降格条件として、昇格や降格処理を実行してもよい。管理責任者は、昇格処理部１３８に対して昇格・降格条件を外部から設定することもできる。このため、上記のような緊急時においても、適切なユーザを時間制限付きで速やかに昇格させることができる。

図８は、アクセス申請・承認レベル設定画面の表示例を示す図である。

図８に示すアクセス申請・承認レベル設定画面８０は、管理者が、作業申請情報のアクセス承認レベルを予め設定する場合に、承認用端末４４に表示される。管理者は、アクセス申請・承認レベル設定画面８０上で事前の申請や承認を必要とするか否かを、サーバ設定でポート毎に設定することができる。

プロトコル・ポート番号領域８１は、プロトコル毎のポート番号を示す。サービス起動領域８２は、アクセスされたときにユーザインタフェースなどの提供サービスを自動起動するか否かを設定するための領域である。全文ログ取得領域８３は、作業内容の全文ログを取得するか否かを設定するための領域である。アクセス承認レベル領域８４は、事前の申請や承認を必要とするか否かの承認レベルを設定する領域である。

アクセス申請・承認レベル設定画面８０では、プロトコル・ポート番号毎に承認レベルを設定することができるだけでなく、サマリーログの保存期間、全文ログの保存期間、アクセス申請・画面操作ログ保存期間、およびサーバ状態も設定することができる。これにより、ログ保持部１５２で保持されている膨大な量のアクセスログのうち、不要になったアクセスログをこまめに削除することができる。

図８の例の場合、ＴＥＬＮＥＴの通信プロトコルの２３番のポートは、事前申請と承認を必要とするように設定されている。一方、ＴＥＬＮＥＴの通信プロトコルの２２３番のポートは、アクセスに際し申請も承認も不要な状態に設定されている。このように、通常利用するポートには、「事前申請と承認」を設定したり、緊急時に承認者が不在な場合を想定し、「事前申請」のみを設定したりすることもできる。

図９は、アクセスログ検索画面の表示例を示す図である。

図９に示すアクセスログ検索画面９０は、承認者が、アクセスチェック（ログ監査）を行う場合に、承認用端末４４に表示される。承認者は、許可したアクセスの内容が、事前に申請された作業内容通りに行われているか否かを確認するために、アクセスログ検索画面９０上で、検索したいアクセスログの検索条件を設定する。検索ボタン９１は、設定された検索条件でアクセスログの検索を実行するためのボタンである。検索ボタン９１がクリックされると、検索条件を示すデータがログ管理装置１５に送信される。ログ管理装置１５のログ管理部１５１（の作業検証部１５１Ｂ）は、検索条件を示すデータに基づいて、ログ保持部１５２に登録されているアクセスログを抽出するとともに、申請管理装置１３の作業予定保持部１３６に登録されている作業予定情報を抽出する。

図１０は、検索結果画面の表示例を示す図である。

図１０に示す検索結果画面１００は、アクセスログ検索画面９０の検索ボタン９１がクリックされた場合に、承認用端末４４に表示される。すなわち、承認者によってアクセスログ検索画面９０で設定された検索条件を満たすアクセスログが申請管理装置１３とログ管理装置１５で検索され、その検索結果（アクセスログと作業予定情報）が承認用端末４４に送信され、サマリーとして検索結果画面１００上に一覧表示される。

ファイルアイコン１０１は、具体的な作業内容をダウンロードするためのボタンである。ファイルアイコン１０１がクリックされると、具体的な実行コマンドの内容が、テキストファイルとして取得されて表示される。またファイルコマンド１０２は、申請内容をダウンロードするためのボタンである。ファイルアイコン１０２がクリックされると、具体的な申請内容が取得されて表示される。すなわち承認者は、アクセスログと申請内容を容易に見比べることができるので、ログ監査を効率よく行うことができる。

なお、申請内容に応じて不要だと思われる禁止コマンドなどをキーワードとして予め登録しておくと、そのキーワードが含まれるレコード行数とレコードを抽出することができる。たとえば、アクセス申請時、アクセス分類に「一般ＩＤ作業」を申請した場合、一般ＩＤによるアクセスであれば、特権ＩＤを取得するようなコマンドが不要であるだけでなく、ユーザを追加するコマンドは本来発行されないことがわかっている。そこで、「一般ＩＤ作業」に対して禁止されている、あるいは不要である、「SU-」（特権ＩＤを取得するためのコマンド）、および「useradd」（ユーザを追加するコマンド）をキーワードとして事前に登録しておく。これにより、申請内容に応じて不要だと思われる禁止コマンドなどを含むアクセスログを抽出し、承認者に提供できるので、不正使用を効率よく見つけ出すことができる。

またメール通知の機能を利用すれば、キーワードに合致する操作が行われた場合、管理者へ電子メールを通知することができる。このように、アクセスチェックを行うだけでログ監査を効率良く行うことができる。

なおここでは、アクセスログと申請内容を見比べることができるように、検索結果を表示するようにしたが、ログ管理部１５１の作業検証部１５１Ｂが、検索条件を示すデータに基づいて、申請管理装置１３の作業予定保持部１３６に登録されている作業予定情報と、ログ保持部１５２に登録されているアクセスログとを対比して、前記ログ情報に示されるアクセスの中の、前記作業予定情報で申請されたメンテナンス作業用アクセスに合致しないアクセスを、不正アクセスとして検出することもできる。

［作業申請処理について］
ここで、作業用端末２０の作業者が行う作業申請処理について説明する。作業者は、まず、作業用端末２０に表示される図５に示すログイン画面５０上でユーザＩＤとパスワードを入力する。作業用端末２０は、入力されたユーザ識別情報と共に、中継装置１１を経由することなく、直接、申請管理装置１３にアクセスする。申請管理装置１３は、ユーザ識別情報をユーザ認証装置１２に転送する。ユーザ認証装置１２のユーザ認証部１２１は、正規ユーザ情報保持部１２２の正規ユーザ情報を参照してユーザ認証を行い、認証に失敗した場合、以降の処理は実行されない。

認証に成功した場合、ユーザ認証装置１２は、認証成功の旨を申請管理装置１３に通知する。申請管理装置１３の作業申請部１３１Ａは、申請画面用データを作業用端末２０に送信する。作業用端末２０は、図６に示すアクセス申請画面６０を表示させる。ユーザは、アクセス申請画面６０にデータを入力し、入力されたデータが作業申請情報として申請管理装置１３に送信される。

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

以上の処理により、作業申請情報のうち、有効な作業申請としての要件を満たす作業申請情報だけが「作業予定情報」として作業予定保持部１３６に正式に登録される。

［作業承認処理について］
次に、作業申請処理によって申請された作業内容の承認処理について説明する。承認用端末４４は、申請が出された旨の電子メールを受け取ったあと、申請管理装置１３にアクセスする。承認者は任意のタイミングにて、図５に示したログイン画面５０上でユーザＩＤとパスワードを入力する。また、承認者は、ユーザＩＤとパスワードの入力時、申請ナンバーも指定する。承認用端末４４は、入力された承認者のユーザＩＤとパスワードをユーザ認証装置１２に送信する。ユーザ認証装置１２のユーザ認証部１２１は、承認用端末４４からユーザＩＤとパスワードを取得し、正規ユーザ情報保持部１２２に登録されている正規ユーザ情報を参照して、承認者のユーザ認証を行う。ユーザ認証に失敗した場合、以降の処理は実行されない。

認証に成功した場合、申請管理装置１３の作業承認部１３１Ｄは、承認用端末４４から取得した申請ナンバーに基づいて、作業予定保持部１３６に登録されている作業申請情報を検索する。申請管理装置１３の作業承認部１３１Ｄは、検索した作業申請情報に基づいて、アクセス承認画面７０のためのＨＴＭＬ（HyperText Markup Language）データを承認用端末４４に送信する。承認用端末４４は、申請ナンバーで指定された作業に関するアクセス承認画面７０（図７）を表示させる。承認者は、アクセス承認画面７０を確認し、承認ボタン７５または却下ボタン７６をクリックすると、入力されたデータが申請管理装置１３に送信される。申請管理装置１３の作業承認部１３１Ｄは、承認可否に応じて作業予定保持部１３６の作業予定情報を更新する。作業承認部１３１Ｄは、作業用端末２０に承認可否を通知する。

以上の処理により、有効に申請された作業について承認がなされる。なお、承認者が、申請管理装置１３にアクセスすると、申請管理装置１３は承認待ちの作業申請を一覧表示させ、承認者はその中から承認対象となる作業申請を選択するというユーザインタフェースであってもよい。また、複数の作業申請を一括して承認または却下を行うことも可能である。

［リモートログイン処理について］
次に、業務情報システムへのリモートログイン処理について説明する。作業者は、作業用端末２０から、まず、中継装置１１にアクセスする。中継装置１１は、アクセスされた作業用端末２０のＩＰアドレスを確認し、接続を許可するか否かを判断し、許可しない場合には接続を切断する。一方、作業用端末２０からの接続を許可する場合には、中継装置１１は、作業用端末２０に対し、プロトコルに適した形でユーザ識別情報（ユーザＩＤおよびパスワード）を要求する。作業用端末２０は、ログイン画面５０（図５）を表示させ、作業者からユーザＩＤとパスワードの入力を受け付ける。作業用端末２０は、入力されたユーザＩＤとパスワードを中継装置１１に送信する。

中継装置１１は、作業用端末２０から受信したユーザＩＤとパスワードをユーザ認証装置１２、申請管理装置１３、およびアクセス権管理装置１４に供給する。ユーザ認証装置１２のユーザ認証部１２１は、中継装置１１からユーザＩＤとパスワードを取得し、正規ユーザ情報保持部１２２に登録されている正規ユーザ情報を参照して、作業者のユーザ認証を行う。ユーザ認証に失敗した場合、以降の処理は実行されない。

認証に成功した場合、中継装置１１は、作業用端末２０にアクセス先の入力を要求する。作業用端末２０は、作業者からアクセス先の入力を受け付け、アクセス先を示す情報（ＩＰアドレスやホスト名など）を中継装置１１に送信する。中継装置１１は、作業用端末２０から受信したアクセス先を示す情報をアクセス権管理装置１４に供給する。アクセス権管理装置１４のアクセス権認証部１４１は、アクセス先を示す情報に基づいて、アクセス権情報保持部１４２に登録されているアクセス申請状況を参照し、アクセス先への当該ユーザのアクセス権を確認する。アクセス権認証部１４１は、不適切なアクセスと判断した場合には、アクセス先への当該ユーザのアクセスを拒否する。一方、適切なアクセスと判断した場合には、アクセス先への当該ユーザのアクセスを許可する。そして全ての判定が肯定となった場合、作業者は、メンテナンス作業の対象となる業務情報システムにアクセス可能となる。

以上の処理により、業務情報システムへリモートログインした場合に、不正なアクセスと判断されると、ログインに失敗し、アクセスを禁止することができる。

［昇格・降格判定処理について］
次に、昇格処理部１３８が実行するユーザの昇格・降格処理について説明する。申請管理装置１３の昇格処理部１３８は、作業予定保持部１３６から作業予定情報を読み出し、昇格させるべきユーザが存在するか判定する。たとえば、営業日である「２００６年９月２８日」の「１０：００〜１１：００」を作業予定日時として、ユーザＡがリリース作業を申請し、承認されたとする。この場合、２００６年９月２８日の１０：００に至ると、昇格処理部１３８はユーザＡを昇格させる。昇格処理部１３８は、昇格可能ユーザのユーザ識別情報をユーザ認証装置１２に送信し、正規ユーザ情報保持部１２２の昇格ユーザ情報にユーザＡを登録する。

また昇格処理部１３８は、作業予定情報から降格させるべきユーザが存在するか判定する。上述の例の場合、２００６年９月２８日の１1：００に至ると、ユーザＡを降格させる。昇格処理部１３８は、降格すべきユーザのユーザ識別情報をユーザ認証装置１２に送信し、正規ユーザ情報保持部１２２の昇格ユーザ情報からユーザＡを抹消する。

申請管理装置１３は、所定時間毎（たとえば１分毎）に、上述の処理を繰り返し実行することにより、昇格ユーザ情報は定期的に更新される。

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

なお、上述した作業申請処理、作業承認処理、業務情報システムへのログイン処理、昇格・降格判定処理の詳細については、特開２００８−１１７３６１号公報等に記載されている通り公知の技術である。

［アクセスチェック処理について］
次に、図１１のフローチャートを参照して、アクセスチェック処理について説明する。承認者は、許可したアクセスの内容が、事前に申請された作業内容通りに行われているか否かを確認するために、承認用端末４４の入力部（図示せず）を用いて、アクセスチェック（ログ監査）の実行を指示する。

ステップＳ１において、承認用端末４４は、承認者からの指示に基づいて、図９に示したアクセスログ検索画面９０を表示する。承認者は、アクセスログ検索画面９０上で、検索したいアクセスログの検索条件を設定する。ステップＳ２において、承認用端末４４は、承認者により設定されたアクセスログの検索条件の入力を受け付ける。そして、検索ボタン９１がクリックされると、ステップＳ３において、承認用端末４４は、入力を受け付けたアクセスログの検索条件データをログ管理装置１５に送信する。

ステップＳ４において、ログ管理装置１５の作業検証部１５１Ｂは、承認用端末４４から検索条件データを受信すると、申請管理装置１３の作業予定保持部１３６から、検索条件データに含まれる申請ナンバーに対応する作業予定情報を読み出し、ログ保持部１５２から申請ナンバーに紐付けされているアクセスログを読み出し、両者を突き合わせ、不正アクセスがなされていないかをチェックする。たとえば、上述したように、「稼働監視」を目的とした作業申請がなされているときに、ファイルの書き換え処理の実行がなされたときには、不正アクセスとなる。ステップＳ５において、作業検証部１５１Ｂは、ログ保持部１５２から検索条件に合致するアクセスログを読み出し、アクセスチェック結果として承認用端末４４に通知する。

ステップＳ６において、承認用端末４４は、ログ管理装置１５から受信したアクセスチェック結果に基づいて、図１０に示した検索結果画面１００を表示させる。なお、申請内容に応じて不要だと思われる禁止コマンドをキーワードとして予め登録してある場合、キーワードに合致するアクセスログが検索された場合には、検索されたキーワードに合致するレコード行数とレコードを、管理者へメール通知することができる。

［発明の実施の形態における効果］
以上のように、本実施の形態では、ユーザ認証に加えて申請判定を行うため、不正アクセスを防止しやすい構成となっている。ユーザ認証だけの場合、ユーザ識別情報の漏洩は、業務情報システムからの情報漏洩に直結しやすい。しかし、業務情報防護装置１０は、更に作業申請手続きを要求するため、ユーザ識別情報の漏洩が不正アクセスに直結しにくい。なぜならば、不正なユーザが、仮にユーザ識別情報を不正に手に入れたとしても、虚偽の作業申請を行ってまで業務情報システムにアクセスするには心理抑制がかかりやすいためである。

また、正当な管理会社のＳＥに対してもクライアント環境４０へのアクセスを規制する仕組みが実現されている。上述したように、作業の申請や承認がログとして記録されるため、事後的なアクセスチェックが容易となる。このため、クライアント企業としても、自システムについてのコンプライアンス（compliance）を証明しやすいというメリットがある。このような特徴により、業務情報防護装置１０は、ＳＯＸ方が求める「内部統制の強化」に資することができる。

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

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

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

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

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

また、業務情報防護装置１０は、複数の業務情報システムに対するアクセスを一元管理できる。そのため、複数の業務情報システムに対して統一的なアクセスポリシーを適用しやすくなっている。更に、既に運用されている業務情報システムに対して、業務情報防護装置１０を追加するだけで実現できるというメリットもある。

以上においては、「メンテナンス作業」を例に挙げ説明したが、本発明は、これに限らず、たとえば、社員が外出先からアクセスする場合にも適用することが可能である。

上述した一連の処理は、ハードウエアにより実行することもできるし、ソフトウエアにより実行することもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、専用のハードウエアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、プログラム記録媒体からインストールされる。

この発明は、上記実施の形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化したり、上記実施の形態に開示されている複数の構成要素を適宜組み合わせたりすることにより種々の発明を形成できる。例えば、実施の形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施の形態に亘る構成要素を適宜組み合わせても良い。

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

Claims (8)

1. システムの所定の処理を実行可能な正規ユーザが登録された正規ユーザ情報を保持する正規ユーザ情報保持手段と、
   アクセス予定者の指定と共に前記所定の処理の実行を申請するための申請情報を受信する申請受信手段と、
   申請された前記所定の処理とそのアクセス予定者を対応づけた予定情報を保持する予定保持手段と、
   前記所定の処理の実行に際して、アクセス者を特定するユーザ識別情報を端末から受信する実行要求受信手段と、
   前記正規ユーザ情報を参照して、前記アクセス者が正規ユーザとして登録されているか否かを判定するユーザ認証手段と、
   前記予定情報を参照して、前記アクセス者をアクセス予定者とする所定の処理が申請済か否かを判定する申請状態判定手段と、
   前記ユーザ認証手段の判定と前記申請状態判定手段の判定が共に肯定判定となることを条件として、前記端末から前記システムへの所定の処理のためのアクセスを許可するアクセス制御手段と、
   前記端末から前記システムへのアクセス履歴である複数の記録内容を含むサマリーログ及び複数の記録内容を含む全文ログをログ情報として記録するログ記録手段と、
   承認用端末に、前記ログ情報に含まれる記録内容を検索条件として入力できる検索画面を表示させる表示手段と、
   前記承認用端末における検索条件に基づいて前記ログ記録手段に記録されているログ情報及び前記予定保持手段に保持されている予定情報を抽出し、前記ログ情報に示されるアクセスの中の、前記予定情報で申請された所定の処理のためのアクセスに合致しないアクセスを、不正アクセスとして検出する検証手段と
   を備え、
   前記表示手段は、前記承認用端末に、前記検証手段が検出した不正アクセスを表示させることを特徴とする業務情報防護装置。
2. 所定の処理申請の承認者に対して、申請された処理内容を通知する申請通知手段と、
   前記承認者からの承認入力を受け付ける承認取得手段と
   を更に備え、
   前記予定保持手段は、更に、前記予定情報として、申請された所定の処理とその承認状態を対応づけて保持し、
   前記申請状態判定手段は、更に、申請された所定の処理が承認済であるか否かを判定する
   ことを特徴とする請求項１に記載の業務情報防護装置。
3. 前記申請状態判定手段は、更に、所定の処理の実行日時が申請された期間内か否かを判定する
   ことを特徴とする請求項１または２に記載の業務情報防護装置。
4. 所定の処理の実行条件が定義された実行条件情報を保持する実行条件保持手段と、
   申請された処理内容が前記実行条件情報と整合することを条件として、申請された所定の処理を前記予定情報に登録する申請登録判定手段と
   を更に備えることを特徴とする請求項１から３のいずれかに記載の業務情報防護装置。
5. 前記正規ユーザ情報保持手段は、更に、通常のユーザ権限とは異なる特別権限を取得可能なユーザを示す昇格ユーザ情報を保持し、
   前記申請状態判定手段は、申請された所定の処理に対する実行条件として特別権限が指定されているときには、更に、アクセス者が特別権限を取得可能なユーザであるか否かを判定する
   ことを特徴とする請求項４に記載の業務情報防護装置。
6. 特別権限の取得可能条件を示す昇格条件の設定入力を受け付ける昇格条件設定手段と、
   前記昇格条件が成立するときに、昇格条件の対象となるユーザを前記昇格ユーザ情報に登録する昇格登録手段と
   を更に備えることを特徴とする請求項５に記載の業務情報防護装置。
7. システムの所定の処理を実行可能な正規ユーザが登録された正規ユーザ情報を保持する正規ユーザ情報保持ステップと、
   アクセス予定者の指定と共に前記所定の処理の実行を申請するための申請情報を受信する申請受信ステップと、
   申請された前記所定の処理とそのアクセス予定者を対応づけた予定情報を保持する予定保持ステップと、
   前記所定の処理の実行に際して、アクセス者を特定するユーザ識別情報を端末から受信する実行要求受信ステップと、
   前記正規ユーザ情報を参照して、前記アクセス者が正規ユーザとして登録されているか否かを判定するユーザ認証ステップと、
   前記予定情報を参照して、前記アクセス者をアクセス予定者とする所定の処理が申請済か否かを判定する申請状態判定ステップと、
   前記ユーザ認証ステップでの判定と前記申請状態判定ステップでの判定が共に肯定判定となることを条件として、前記端末から前記システムへの所定の処理のためのアクセスを許可するアクセス制御ステップと、
   前記端末から前記システムへのアクセス履歴である複数の記録内容を含むサマリーログ及び複数の記録内容を含む全文ログをログ情報として記録するログ記録ステップと、
   承認用端末に、前記ログ情報に含まれる記録内容を検索条件として入力できる検索画面を表示させる表示ステップと、
   前記承認用端末における検索条件に基づいて前記ログ記録手段に記録されているログ情報及び前記予定保持手段に保持されている予定情報を抽出し、前記ログ情報に示されるアクセスの中の、前記予定情報で申請された所定の処理のためのアクセスに合致しないアクセスを、不正アクセスとして検出する検証ステップとを含み、
   前記表示ステップは、前記承認用端末に、前記検証手段が検出した不正アクセスを表示させることを特徴とする業務情報防護方法。
8. システムの所定の処理を実行可能な正規ユーザが登録された正規ユーザ情報を保持する正規ユーザ情報保持ステップと、
   アクセス予定者の指定と共に前記所定の処理の実行を申請するための申請情報を受信する申請受信ステップと、
   申請された前記所定の処理とそのアクセス予定者を対応づけた予定情報を保持する予定保持ステップと、
   前記所定の処理の実行に際して、アクセス者を特定するユーザ識別情報を端末から受信する実行要求受信ステップと、
   前記正規ユーザ情報を参照して、前記アクセス者が正規ユーザとして登録されているか否かを判定するユーザ認証ステップと、
   前記予定情報を参照して、前記アクセス者をアクセス予定者とする所定の処理が申請済か否かを判定する申請状態判定ステップと、
   前記ユーザ認証ステップでの判定と前記申請状態判定ステップでの判定が共に肯定判定となることを条件として、前記端末から前記システムへの所定の処理のためのアクセスを許可するアクセス制御ステップと、
   前記端末から前記システムへのアクセス履歴である複数の記録内容を含むサマリーログ及び複数の記録内容を含む全文ログをログ情報として記録するログ記録ステップと、
   承認用端末に、前記ログ情報に含まれる記録内容を検索条件として入力できる検索画面を表示させる表示ステップと、
   前記承認用端末における検索条件に基づいて前記ログ記録手段に記録されているログ情報及び前記予定保持手段に保持されている予定情報を抽出し、前記ログ情報に示されるアクセスの中の、前記予定情報で申請された所定の処理のためのアクセスに合致しないアクセスを、不正アクセスとして検出する検証ステップとを含み、
   前記表示ステップは、前記承認用端末に、前記検証手段が検出した不正アクセスを表示させることを含む処理をコンピュータに実行させることを特徴とするプログラム。
   

Images