業務情報防護装置
【課題】業務情報システムの情報セキュリティを高める。
【解決手段】業務情報防護装置１００は、業務情報システム３００のサーバ装置３２０に対するクライアント端末２００からのリモートアクセスを制御する。リモートアクセスの実行対象となるサーバ装置３２０とリモートアクセスを実行予定のユーザとを示すアクセス申請情報を受信し、サーバ装置３２０ごとのリモートアクセス予定を管理する。リモートアクセス予定に応じて、各ユーザの属するユーザグループを適宜変更する。クライアント端末からのいずれかのサーバ装置３２０へのリモートアクセス要求がなされるとき、サーバ装置３２０へのアクセス権限のあるユーザグループに所属している正規ユーザであることを条件として、サーバ装置３２０へのリモートアクセスを許可する。
【解決手段】業務情報防護装置１００は、業務情報システム３００のサーバ装置３２０に対するクライアント端末２００からのリモートアクセスを制御する。リモートアクセスの実行対象となるサーバ装置３２０とリモートアクセスを実行予定のユーザとを示すアクセス申請情報を受信し、サーバ装置３２０ごとのリモートアクセス予定を管理する。リモートアクセス予定に応じて、各ユーザの属するユーザグループを適宜変更する。クライアント端末からのいずれかのサーバ装置３２０へのリモートアクセス要求がなされるとき、サーバ装置３２０へのアクセス権限のあるユーザグループに所属している正規ユーザであることを条件として、サーバ装置３２０へのリモートアクセスを許可する。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、組織業務を管理するための業務情報システムに関連し、特に、業務情報システムの情報セキュリティを向上させるための技術、に関する。
【背景技術】
【０００２】
企業や公共施設などの運用を支える業務情報システム、いわゆるエンタープライズシステム（Enterprise System）は、今や、大小さまざまな組織の基盤となっている。業務情報システムは、クライアント端末やデータベースから得られるデータを集計、蓄積、解析、加工した上でより付加価値の高い情報を出力することにより、複雑化する組織マネジメントを支えている。
【０００３】
業務情報システムが取り扱う情報（以下、「組織情報」とよぶ）は、以下の３種類に大別できる。
１．外部公開情報：組織内のみならず組織外にも公開可能な組織情報。たとえば、ＩＲ（Investor Relations）情報やプレスリリース情報が該当する。
２．内部公開情報：組織内において公開されるが、組織外には非公開となる組織情報。たとえば、社内掲示板の情報が該当する。
３．限定公開情報：特殊な内部公開情報であり、一部の組織構成員にのみ公開される情報。たとえば、取引先リスク評価情報は、通常、経理部や所定職位以上の社員のみがアクセスできる限定公開情報である。
【０００４】
一般的な業務情報システムは、パスワードなどのユーザ認証により、限定公開情報へのアクセスを制限することが多い。たとえば、経理部用の限定公開情報を格納する経理情報データベースに対して、経理部共通の「部署パスワード」を設定する。このような運用によれば、部署パスワードを知っている社員、いいかえれば、経理部に所属する社員だけが経理情報データベースの限定公開情報にアクセスできる。
【特許文献１】特開２００４−２１３４７５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかし、上記運用の場合、ある経理部員が別の部署に配属変更となると、部署パスワードが経理部以外に漏洩する可能性が高くなる。この経理部員が正社員でなく契約社員であれば、部署パスワードが組織外に漏洩する可能性も高くなる。部署パスワードを頻繁に変更すればこのような問題にある程度は対処できるが、他の経理部員にとって負担となる。
【０００６】
更に、経理部以外に所属する社員が経理情報データベースにアクセスしたい場合もある。この社員のアクセス範囲・アクセス時間等をコントロールできれば、経理情報データベースへの一時的・限定的なアクセスを許可してもよいかもしれない。しかし、この社員に部署パスワード自体を教えてしまうと、やはり部署パスワードが関係者以外に漏洩するかもしれない。
【０００７】
近年、アメリカで成立したＳＯＸ（Sarbanes‐Oxley）法は、企業経営者や会計監査人に対して公開情報の正当性を保証するように強く求めている。これに倣って、日本でも日本版ＳＯＸ法が導入される予定であり、日本版ＳＯＸ法に対応できる態勢の確立が急務となっている。
【０００８】
このような社会背景に鑑みて、本発明者は、業務情報システムへのアクセス、特に、限定公開情報に対する組織構成員からのアクセスに着目し、組織内部における業務情報システムへのアクセス規制を強化する必要があると認識した。特許文献１は、ＩＤとパスワードによるユーザ認証に加えて、管理者によるアクセス承認を条件とするアクセスルールを開示する。このようなアクセスルールは、業務情報システムへの不正アクセスを防止する上で有効な手法であるが、管理者は作業申請に即座に対応する必要があるため負担が大きい。本発明者は、限定公開情報に対する組織内からのアクセスをコントロールする上で、限定公開情報の流出抑制はもちろん重要であるが、限定公開情報へのアクセスにともなうユーザ負荷を抑制することもまた重要であると考える。
【０００９】
本発明は、本発明者の上記課題認識に基づいて完成された発明であり、その主たる目的は、業務情報システムにおける情報セキュリティを向上させるための技術、を提供することにある。
【課題を解決するための手段】
【００１０】
本発明の別の態様も、複数のサーバ装置の連携により組織業務を管理するための業務情報システムにおいて、クライアント端末からサーバ装置へのリモートアクセスを制御するための業務情報防護装置に関する。
この装置は、リモートアクセスの実行対象となるサーバ装置とリモートアクセスを実行予定のユーザとを示すアクセス申請情報を受信し、サーバ装置ごとのリモートアクセス予定を管理する。リモートアクセス予定に応じて、各ユーザの属するユーザグループを適宜変更する。クライアント端末からのいずれかのサーバ装置へのリモートアクセス要求がなされるとき、サーバ装置へのアクセス権限のあるユーザグループに所属している正規ユーザであることを条件として、サーバ装置へのリモートアクセスを許可する（後述する「ユーザ認証主導型」に対応する）。業務情報防護装置はサーバ装置に対してリモートアクセス要求元ユーザのユーザグループを通知し、サーバ装置は自装置についてあらかじめ設定されているユーザグループに当該ユーザが所属していることを条件としてユーザからのリモートアクセス要求を受け付けてもよい。
【００１１】
なお、以上の構成要素の任意の組合せ、本発明を方法、システム、記録媒体、コンピュータプログラムにより表現したものもまた、本発明の態様として有効である。
【発明の効果】
【００１２】
本発明によれば、業務情報システムにおける情報セキュリティを向上させることができる。
【発明を実施するための最良の形態】
【００１３】
本実施例においては、「ユーザ認証主導型」および「申請判定主導型」という２つの方式について説明する。ユーザ認証主導型を基本として説明するが、申請判定主導型についても適宜補足説明を加えつつ説明する。ユーザ認証主導型ではアクセスを申請しなくても限定公開情報にアクセスできる可能性があるが、申請判定主導型においてはアクセス申請が必須条件となる。ユーザ認証主導型または申請判定主導型のいずれかを採用するとしてもよいし、アクセス対象となるサーバ装置やフォルダごとにいずれかを採用してもよい。
【００１４】
図１は、業務情報防護装置１００と業務情報システム３００との関係を示すハードウェア構成図である。
業務情報システム３００は、企業Ａの組織業務を管理するシステムである。業務情報システム３００は、人事システム３１０と経理システム３１２という２種類のシステムを統合する。業務情報システム３００は、このほかにも、在庫管理、製品開発などさまざまなシステムを含んでもよい。
人事システム３１０は、人事情報データベースとしてのサーバ装置３２０ａとサーバ装置３２０ｂを含む。サーバ装置３２０ａのデータは、フォルダ（ディレクトリ）３２４ａ、３２４ｂ、３２４ｃにより階層化されている。サーバ装置３２０ｂのデータは、フォルダ３２４ｄ、３２４ｅ、３２４ｆ、３２４ｇにより階層化されている。サーバ装置３２０ａのフォルダ３２４ｃは、サーバ装置３２０ｂのフォルダ３２４ｄにマップ（map）されている。
経理システム３１２は、経理情報データベースとしてのサーバ装置３２０ｃとサーバ装置３２０ｄを含む。サーバ装置３２０ｃとサーバ装置３２０ｄのデータもフォルダ３２４により階層化されている。また、業務情報システム３００は、社内掲示板用ウェブサーバとしてのサーバ装置３２０ｅを含む。
【００１５】
業務情報システム３００と業務情報防護装置１００、クライアント端末２００ａ、２００ｂ、２００ｃといった複数のクライアント端末２００は、イントラネット（intranet）等の企業内ネットワークを介して互いに接続される。クライアント端末２００は、ウェブブラウザを搭載した一般的なＰＣ（Personal Computer）端末である。社員（以下、「正規ユーザ」ともよぶ）は、クライアント端末２００から業務情報システム３００にリモートアクセスする。業務情報システム３００や業務情報防護装置１００には、１以上の承認用端末３２２も接続される。承認用端末３２２も、ウェブブラウザを搭載した一般的なＰＣ端末である。承認用端末３２２の役割については後述する。
【００１６】
正規ユーザは、複数の「ユーザグループ」に分類される。「ユーザグループ」とは、たとえば、人事部や経理部のような所属、正社員や契約社員のような契約形態、課長や部長、取締役のような職位などの観点からユーザの分類したものである。たとえば、ある正規ユーザαは、「人事部」、「契約社員」、「事務職」というユーザグループに属し、別の正規ユーザβは、「営業部」、「正社員」、「部長」というユーザグループに属するかもしれない。
【００１７】
人事システム３１０や経理システム３１２において、各サーバ装置３２０が保持するデータは限定公開情報である。サーバ装置３２０ａの限定公開情報にアクセスできるのは「人事部」に所属する正規ユーザだけであるかもしれない。また、サーバ装置３２０ｂのフォルダ３２４ｅに保持される限定公開情報にアクセスできるのは、「部長以上」であって「人事部」に所属する正規ユーザだけであるかもしれない。各システム、各サーバ装置３２０、各フォルダ３２４には、限定公開情報にアクセスできるユーザグループ（以下、「権限グループ」とよぶ）があらかじめ設定されている。さきほどの例であれば、フォルダ３２４ｅの限定公開情報についての権限グループは、「部長以上」かつ「人事部」となる。
【００１８】
一方、サーバ装置３２０ｅが保持するデータは内部公開情報である。したがって、企業Ａの社員であれば、すなわち正規ユーザでさえあればサーバ装置３２０ｅの内部公開情報へアクセスできる。サーバ装置３２０ｅの一部のフォルダ３２４は、完全公開情報も保持する。この場合、正規ユーザでないユーザであってもサーバ装置３２０ｅの完全公開情報にアクセスできる。
業務情報防護装置１００は、内部公開情報や限定公開情報に対するクライアント端末２００からのリモートアクセス可否を判定するための装置である。以下においては、限定公開情報へのリモートアクセスを中心として説明する。
【００１９】
業務情報防護装置１００は、ユーザ認証装置１２０と申請管理装置１４０を含む。業務情報防護装置１００は、ユーザ認証装置１２０と申請管理装置１４０の機能を一体として備える単一の装置であってもよいが、本実施例においては、これら２つの装置の集合体であるとして説明する。
【００２０】
ユーザは、内部公開情報や限定公開情報にアクセスする上で、まず、クライアント端末２００にログインする。このとき、クライアント端末２００には、ユーザＩＤとパスワードが入力される。以下、ユーザＩＤやパスワードのように、ユーザを識別するためのデータのことを「ユーザ識別情報」とよぶ。クライアント端末２００は、ユーザ識別情報をユーザ認証装置１２０に渡す。クライアント端末２００は、申請管理装置１４０やサーバ装置３２０を経由してユーザ認証装置１２０にユーザ識別情報を渡してもよいし、ユーザ認証装置１２０に直接転送してもよい。
ユーザ認証装置１２０は、クライアント端末２００に代わって、ログイン要求元のユーザが正規ユーザであるか判定する（以下、「ユーザ認証」とよぶ）。
【００２１】
限定公開情報の権限グループに所属しているユーザでなければ、限定公開情報にアクセスすることはできない。人事システム３１０のサーバ装置３２０ａは、「人事部」のユーザであればアクセス可能である。あるユーザがサーバ装置３２０ａをアクセス先として指定するとき、このユーザが人事部に所属していれば、サーバ装置３２０ａへのアクセスは許可される。一方、ユーザが人事部に所属していないときでも、このユーザがサーバ装置３２０ａに対するリモートアクセスを事前に（正しく）申請済みであればアクセスを許可される。申請管理装置１４０が申請済みか否かを判定する（以下、「申請判定」とよぶ）。ただし、申請判定主導型の場合、たとえユーザが人事部に所属していても、事前の申請が必須となる。
以下においては、限定公開情報Ａについての権限グループに属する正規ユーザのことを限定公開情報Ａの「権限ユーザ」とよぶ。また、限定公開情報Ａに対する権限ユーザ以外の正規ユーザのことを「非権限ユーザ」とよぶ。
ユーザは、クライアント端末２００から、業務情報システム３００の任意のサーバ装置３２０、ひいては、任意のフォルダ３２４にアクセスする。
【００２２】
クライアント端末２００とサーバ装置３２０との接続が確立したあと、ログインユーザは、アクセス対象となるフォルダ３２４を変更できる。このとき、クライアント端末２００から該当サーバ装置３２０に「フォルダ変更要求」が送信される。変更先のフォルダ３２４が保持する情報が限定公開情報であれば、サーバ装置３２０は、ログインユーザがその限定公開情報についての権限ユーザであるかを判定する。権限ユーザであれば、フォルダ変更要求を許可する。本来、非権限ユーザであっても、申請管理装置１４０に事前に正しく申請していれば、フォルダ変更要求が許可される。ただし、申請判定主導型の場合、権限ユーザであっても、事前の申請が必須となる。
【００２３】
以上をまとめると、
１．内部公開情報に対しては、ユーザ認証によりアクセス権を判定する。
２．限定公開情報に対しては、
２−１．ユーザ認証主導型の場合、権限ユーザであれば、申請判定の判定結果に関わらずアクセス可能である。通常は、申請判定自体を実行しない。一方、本来的に非権限ユーザであっても、事前の申請により暫定的に権限ユーザとなって限定公開情報にアクセスすることができる。
２−２．申請判定主導型の場合、権限ユーザであろうとも、事前の申請がなされていなければアクセスは不可能である。
【００２４】
内部公開情報や限定公開情報は、サーバ装置３２０やフォルダ３２４を単位として管理できる。限定公開情報を保持するサーバ装置３２０やフォルダ３２４は、権限グループについての情報を保持する。サーバ装置３２０ａは、人事システム３１０についての権限グループ情報、サーバ装置３２０ａについての権限グループ情報を保持する。また、サーバ装置３２０ａのフォルダ３２４ｂは、フォルダ３２４ｂの権限グループ情報を保持する。同様にして、サーバ装置３２０ｂはサーバ装置３２０ｂの権限グループ情報を保持する。
【００２５】
なお、所定の限定公開情報については権限グループを設定しなくてもよい。たとえば、サーバ装置３２０ｂのフォルダ３２４ｇの限定公開情報Ｂには権限グループが設定されていない。正規ユーザがどのようなユーザグループに所属していようとも、この限定公開情報Ｂにアクセスするために必ずアクセス申請しなければならない。すなわち、限定公開情報Ｂについては、すべての正規ユーザは非権限ユーザとなる。特に機密性の高い限定公開情報については、このような設定方法も有効である。これは事実上、申請判定主導型によるセキュリティ管理と同様の効果を発揮することになる。
ユーザ認証主導型によるリモートアクセスの手続きの流れについては図９に関連して詳述する。また、申請判定主導型によるリモートアクセスの手続きの流れについては図１０に関連して詳述する。
【００２６】
図２は、業務情報防護装置１００の機能ブロック図である。
ここに示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。ここでは、各部の機能を中心として説明し、それらの連携、データ構造、作用については、図３以降に関連して詳述する。
【００２７】
本実施例における業務情報防護装置１００は、互いに通信回線で接続されたユーザ認証装置１２０と申請管理装置１４０を含む。
【００２８】
ユーザは、業務情報システム３００へアクセスする前に、まず、クライアント端末２００にログインする。このとき、クライアント端末２００にはユーザＩＤとパスワードが入力される。本実施例においては、このユーザＩＤとパスワードは、ユーザ認証装置１２０によるユーザ認証や申請管理装置１４０による申請判定のために転送される。
【００２９】
Ａ：ユーザ認証装置１２０
ユーザ認証装置１２０は、ユーザ認証部１２２と正規ユーザ情報保持部１２４を含む。正規ユーザ情報保持部１２４は、ユーザＩＤとパスワード、ユーザグループを対応づけた正規ユーザ情報を保持する。この正規ユーザ情報に登録されているユーザが「正規ユーザ」となる。ユーザがクライアント端末２００にログインするとき、クライアント端末２００はユーザ認証部１２２にユーザ識別情報を送信する。ユーザ認証部１２２は、このユーザ識別情報と正規ユーザ情報を比較することによりユーザ認証を行う。ユーザ認証部１２２は、クライアント端末２００のユーザだけでなく承認用端末３２２のユーザについてもユーザ認証を実行する。
【００３０】
本実施例におけるユーザ認証装置１２０は単一の装置であり、正規ユーザ情報を一元的に管理する。複数のシステムについてのユーザ認証を単一のユーザ認証装置１２０にて実行することにより、ユーザ認証ポリシー（policy）を一元的に管理できる。
【００３１】
Ｂ：申請管理装置１４０
申請管理装置１４０は、申請状態管理部１４２、申請状態判定部１４４、アクセスインタフェース処理部１４６、ユーザグループ変更部１８２、実行条件保持部１５０およびアクセス予定保持部１５２を含む。
【００３２】
実行条件保持部１５０は、非権限ユーザについてのアクセスルールを示す実行条件情報を保持する。リモートアクセスの目的は複数の種別（以下、単に「アクセス種別」とよぶ）に分類される。アクセス種別として、データを閲覧するだけの「データ参照」、新たなデータを登録するための「データ追加」、既存のデータを書き換えるための「データ変更」、ソフトウェアインストールなどの「リリース作業」などが挙げられる。ユーザ認証主導型の場合、権限ユーザは事前のアクセス申請をしなくても限定公開情報にアクセスできるが、非権限ユーザはアクセス日時、アクセス種別等を明示した「アクセス申請情報」を業務情報防護装置１００に送信することにより、アクセス予定を事前に申請しておかなければならない。後述の登録判定部１６２は、実行条件情報を参照して、このアクセス申請情報の適否をチェックする。
【００３３】
たとえば、サーバ装置３２０ａの権限グループが「人事部」であるとき、情報技術部のユーザがこのサーバ装置３２０ａに新しいソフトウェアをインストールしたいとする。このユーザは、サーバ装置３２０ａについては非権限ユーザである。ここで、サーバ装置３２０ａの管理責任者は、サーバ装置３２０ａへの「リリース作業」が２月１日にのみ実行可能である旨を実行条件情報に登録したとする。
【００３４】
非権限ユーザが１月３０日を予定日としてサーバ装置３２０ａへの「リリース作業」を申請しても、アクセスルールに適合しないためこの申請は自動的に却下される。このように、サーバ装置３２０ａの管理責任者は、サーバ装置３２０ａに対する非権限ユーザのアクセスルールを実行条件情報としてあらかじめ登録しておくことができる。
更に、承認権限のある特別なユーザ（以下、単に「承認者」とよぶ）によって申請が承認されなければならない旨を実行条件情報に登録することもできる。実行条件情報のデータ構造については、次の図３に関連して更に詳述する。
【００３５】
申請状態管理部１４２は、アクセス申請に関する処理を全般的に担当する。申請状態管理部１４２は、アクセス申請部１５６、アクセス承認部１５８、申請通知部１６０および登録判定部１６２を含む。
【００３６】
アクセス申請部１５６は、アクセス申請情報を受信する。アクセス申請情報は、後の図４に示す申請画面２２０において入力されるデータの集合である。後の図４では、入力データとして、アクセスの目的、日時、件名、アクセス対象となるサーバ名などが示されるが、このほかにも、申請者のメールアドレスなどさまざまな情報が含まれてもよい。更に、申請日時や申請者のＩＰアドレスなど、入力されたデータ以外の付帯情報が含まれてもよい。登録判定部１６２は、アクセス申請情報が実行条件情報と適合するか判定する。先ほどの例でいえば、２月１日以外を対象としてサーバ装置３２０ａに対するリリース作業が申請された場合、登録判定部１６２はこの申請を却下し、その旨を非権限ユーザに通知する。申請内容が実行条件情報と適合していれば、登録判定部１６２はアクセス予定保持部１５２のアクセス予定情報に、申請を登録する。アクセス予定情報に登録されたアクセス申請のことを「有効なアクセス申請」とよぶ。アクセス予定情報の内容は、アクセス申請情報の内容と実質的に同等であってよい。すなわち、受信されたアクセス申請情報のうち、有効なアクセス申請としての要件を満たすアクセス申請情報だけがアクセス予定情報として正式登録される。登録判定部１６２は、有効なアクセス申請がなされると、リモートアクセス予定を一意に識別するためのアクセスＩＤを付与する。アクセス予定情報では、アクセスＩＤ、アクセス予定日時、アクセス内容、ユーザ名、承認状態等が対応づけられる。
【００３７】
申請通知部１６０は、アクセス申請情報が登録されると、その申請内容が承認を必要とするものであるか否かを実行条件情報を参照して判定する。申請通知部１６０は、承認が必要なアクセス申請情報について、そのアクセスＩＤを承認者に通知する。本実施例における申請通知部１６０は、アクセスＩＤを示す電子メールを承認用端末３２２に送信する。承認者は、アクセスＩＤに基づいて申請管理装置１４０にアクセスし、承認可否を入力する。アクセス承認部１５８は、承認可否を承認用端末３２２から受信する。このときのユーザインタフェースに関しては図５に関連して後述する。
【００３８】
アクセス承認部１５８は、承認がなされると、アクセス予定情報における承認状態を「未承認」から「承認」に変更する。却下の場合には、アクセス承認部１５８はユーザに申請却下の旨を通知すると共に、アクセス予定情報から該当申請を抹消する。また、登録判定部１６２は、アクセス予定情報のうち、アクセス予定日時を経過した申請や、すでに完了した申請を適宜抹消する。
【００３９】
申請状態判定部１４４は申請判定を実行する。ここで、ユーザ認証主導型と申請判定主導型について簡単に説明しておく。
【００４０】
１：ユーザ認証主導型
リモートログインに際し、クライアント端末２００はユーザ識別情報をサーバ装置３２０に送信する。サーバ装置３２０はユーザ識別情報をユーザ認証装置１２０に送信し、ユーザ認証装置１２０はユーザ認証を実行する。ここで、ログイン要求元のユーザが正規ユーザであれば、ユーザの所属するユーザグループをサーバ装置３２０に通知する。サーバ装置３２０についての権限ユーザであれば、サーバ装置３２０はアクセスを許可し、クライアント端末２００との通信経路を確立する。
【００４１】
申請管理装置１４０のユーザグループ変更部１８２は、アクセス予定情報に基づいて、適宜、ユーザ認証装置１２０の正規ユーザ情報を更新する。たとえば、情報技術部のユーザＡが、「２月１日から２月２日」を対象として、人事システム３１０へのアクセス予定を有効に申請している状況を想定する。本来、ユーザＡは、人事システム３１０のサーバ装置３２０ａに関する権限ユーザではないが、申請された「２月１日から２月２日」に限って一時的にアクセス権限を付与される。
ユーザグループ変更部１８２は、２月１日に至るとユーザＡのユーザグループとして一時的に「人事部」と登録する。そして、２月２日が終わるとき、ユーザＡのユーザグループから「人事部」を抹消する。いわば、ユーザＡは申請期間に限って暫定的に人事部に所属することになる。
【００４２】
このようにして申請管理装置１４０は、適宜、正規ユーザ情報保持部１２４を更新することになる。このため、リモートアクセス実行時において、ユーザ認証装置１２０は、ユーザ識別情報に基づいて、事実上、ユーザ認証と申請判定をまとめて実行できることになる。リモートログインに限らず、フォルダ変更要求についても同様のアルゴリズムにてユーザ認証主導型によるアクセス制御が可能である。
【００４３】
２：申請判定主導型
この申請判定主導型においては、有効なアクセス申請がなされていなければ業務情報システム３００へのアクセスを許可しない。このため、特に情報セキュリティを重視する場合に好ましい処理モデルである。
リモートログインに際し、クライアント端末２００はユーザ識別情報をサーバ装置３２０に送信する。サーバ装置３２０はユーザ識別情報を申請管理装置１４０に送信する。ここで、申請管理装置１４０はユーザ識別情報に含まれるユーザＩＤを取得し、当該ユーザが有効にアクセス申請済みであるか判定する。有効なアクセス申請がなされていなければ、ユーザ認証を実行することなくアクセスは拒否される。
【００４４】
有効にアクセス申請済みであれば、申請管理装置１４０はユーザ識別情報をユーザ認証装置１２０に転送する。ユーザ認証装置１２０はここでユーザＩＤとパスワードをチェックしてユーザ認証を実行する。ログイン要求元のユーザが正規ユーザであれば、ユーザ認証装置１２０はアクセス許可通知をサーバ装置３２０に通知する。サーバ装置３２０は、アクセス許可通知を受信したことを条件として、クライアント端末２００との通信経路を確立する。
【００４５】
すなわち、申請管理装置１４０は、アクセス予定情報に基づいて、有効にアクセス申請していないユーザのアクセスをユーザ認証の前段階にて排除する。リモートログインに限らず、フォルダ変更要求についても同様のアルゴリズムにて申請判定主導型によるアクセス制御が可能である。詳細については図１０に関連して後述する。
【００４６】
１．ユーザ認証主導型の場合、申請状態判定部１４４は、ユーザ識別情報とアクセス予定情報を定期的に参照して、アクセス申請済か否か、必要であれば、更に承認済みか否かを判定する。
２．申請判定主導型の場合においては、申請状態判定部１４４は、リモートアクセス要求日時が、申請されたアクセス予定時間内にあるかについても判定する。たとえば、ある非権限ユーザαが「２月１日」というアクセス予定日時を指定してサーバ装置３２０ａへのアクセス申請をしている場合、１月３１日以前や２月２日以後にサーバ装置３２０ａにリモートアクセス要求をしても申請判定の結果は「否定」となり、リモートアクセスは許可されない。一方、非権限ユーザＡが「２月１日」というアクセス予定日時においてサーバ装置３２０ａにリモートアクセス要求してきたときには、申請判定の結果は「肯定」となり、アクセスインタフェース処理部１４６はアクセスを許可する。
もちろん、承認が必要なアクセスが申請されているときには、承認済みでなければアクセス許可されない。アクセスインタフェース処理部１４６は、サーバ装置３２０やフォルダ３２４へのアクセス可否判定を統括的に制御する。
【００４７】
本実施例における申請管理装置１４０は単一の装置であり、申請判定を一元的に実行する。複数システムに関する申請判定を単一の申請管理装置１４０にて実行することにより、実行条件情報やアクセス予定情報を一元的に管理できる。
【００４８】
図３は、実行条件保持部１５０における実行条件情報のデータ構造図である。
実行条件情報は、各サーバ装置３２０やフォルダ３２４の管理責任者により定められたアクセスルールを示す。ルールＩＤ欄１６４は、アクセスルールを一意に識別するためのＩＤ（以下、「ルールＩＤ」とよぶ）を示す。アクセスルールが登録されると、ルールＩＤが割り当てられる。対象領域欄１６６は、アクセスルールの適用対象となるサーバ装置３２０やフォルダ３２４を示す。日時欄１６８は、アクセスルールの適用日時を示す。アクセス種別欄１７０は、アクセスルールが適用されるアクセス種別を示す。承認要否欄１７２は、該当アクセスの実行をするために承認が必要か否かを示す。たとえば、ルールＩＤ「１」のアクセスルールは、「サーバＩＤ：０６」のサーバ装置３２０（以下、「サーバ装置３２０（０６）」と表記する）における「フォルダＩＤ：２４」のフォルダ３２４（以下、「フォルダ３２４（２４）」と表記する）に保持される限定公開情報に関し、「６：００〜１６：００」の時間帯について適用される。
【００４９】
すなわち、サーバ装置３２０（０６）のフォルダ３２４（２４）に非権限ユーザがアクセスする場合、「６：００〜１６：００」という時間帯に限って、「データ参照」か「データ追加」というアクセス種別にて事前申請をしていればアクセスが許可される。承認は不要であり、正しく申請さえしていればよい。しかし、「データ変更」を目的として申請をしても却下されることになる。また、この時間帯以外のアクセスは許可されない。
【００５０】
一方、サーバ装置３２０（０８）に非権限ユーザがアクセスする場合、「６：００〜１６：００」という時間帯に限って、「データ変更」か「リリース作業」というアクセス種別にて事前申請をし、かつ、承認を得られればアクセスが許可される。
【００５１】
図４は、申請画面２２０を示す画面図である。
ユーザがアクセス申請のために申請管理装置１４０にアクセスすると、アクセス申請部１５６はクライアント端末２００に同図に示す申請画面２２０を表示させる。申請画面２２０は、クライアント端末２００にウェブページとして表示される画面である。
【００５２】
申請者名領域２２２には、申請者名を入力する。申請者は、自分以外が作業をするときには、実際に作業を実行する予定のユーザ名を入力する。件名領域２２４には、申請する作業の件名を入力する。システム分類領域２２６からは、対象システムのタイプが選択される。ここでは、経理システム３１２が選択されている。サーバ指定領域２２７はアクセス対象となるサーバ装置３２０のサーバＩＤ、フォルダ指定領域２２８はアクセス対象となるフォルダ３２４のフォルダＩＤを示す。サーバ指定領域２２７やフォルダ指定領域２２８においては複数のサーバ装置３２０や複数のフォルダ３２４を指定してもよい。
【００５３】
アクセス種別領域２３０はアクセス種別を示す。内容入力領域２３２は、作業内容などを自由記述するための領域である。アクセス予定日時領域２３４は、アクセス予定日時を示す。申請者は、申請画面２２０に示される各項目にデータを入力した後、申請ボタン２３６をクリックする。すると、入力されたデータがアクセス申請情報として申請管理装置１４０に送信される。
【００５４】
図５は、承認画面２６０を示す画面図である。
承認が必要なアクセス申請がなされた場合、申請通知部１６０はアクセスＩＤを承認用端末３２２に通知する。承認者が、アクセスＩＤを指定して申請管理装置１４０にアクセスすると、アクセス承認部１５８は承認用端末３２２に同図に示す承認画面２６０を表示させる。承認画面２６０も、承認用端末３２２にウェブページとして表示される。
【００５５】
申請情報領域２６２は、申請画面２２０に入力された申請内容を示す。承認者名領域２６４は、承認者名を入力する領域である。承認依頼者名領域２６６は、承認を依頼したユーザ名を入力するための領域である。たとえば、承認権限のあるユーザＢが、ユーザＣに承認を依頼したときには、ユーザＣはユーザＢに代理して承認判断を行う。これは、ユーザＢの休暇中など、特殊な状況に対応するための措置である。通信欄２６８は、申請者に対するメッセージを記述する欄である。申請却下の理由を記述したり、申請承認するときには作業内容に条件や注文をつけるための記述がなされてもよい。承認ボタン２７０は承認用、却下ボタン２７２は却下用のボタンである。承認ボタン２７０から却下ボタン２７２のいずれかがクリックされると、入力内容と承認可否を示すデータが申請管理装置１４０に送信される。アクセス承認部１５８は、このデータをクライアント端末２００に、たとえば、電子メールにより送信する。
【００５６】
図６は、リモートログインに成功した後、クライアント端末２００から人事システム３１０にアクセスするときのアクセス画面２９４を示す。
クライアント端末２００から人事システム３１０への接続が確立すると、人事システム３１０のフォルダ構造を示すアクセス画面２９４がクライアント端末２００に表示される。同図に示すように、サーバ装置３２０ａとサーバ装置３２０ｂの各フォルダ３２４が階層化されて画面表示される。ユーザは、アクセス先となるフォルダ３２４を選択する。このとき、クライアント端末２００から該当サーバ装置３２０にフォルダ変更要求が送信される。ユーザ認証主導型の場合、該当サーバ装置３２０は、ユーザが変更先のフォルダ３２４についての権限ユーザであるかを判定する。
【００５７】
図７は、アクセス申請処理の過程を示すシーケンス図である。
アクセス申請時においては、クライアント端末２００のユーザは、ユーザ識別情報を送信して、直接、申請管理装置１４０にアクセスする（Ｓ１０）。申請管理装置１４０は、ユーザ識別情報をユーザ認証装置１２０に転送する（Ｓ１２）。ユーザ認証装置１２０のユーザ認証部１２２は、ユーザ認証を実行する（Ｓ１４）。ユーザ認証に失敗すれば、以降の処理は実行されない。ここでは、ユーザ認証が成功したものとして説明を続ける。
【００５８】
ユーザ認証装置１２０は、ユーザ認証の結果、すなわち、認証成功の旨を申請管理装置１４０に通知する（Ｓ１６）。申請管理装置１４０のアクセス申請部１５６は、申請画面２２０のためのＨＴＭＬ（Hyper Text Markup Language）データを送信し（Ｓ１８）、クライアント端末２００は、申請画面２２０を表示させる（Ｓ２０）。ユーザは、申請画面２２０にデータを入力し、申請ボタン２３６をクリックすると（Ｓ２２）、入力されたデータがアクセス申請情報として申請管理装置１４０に送信される（Ｓ２４）。
【００５９】
申請管理装置１４０の登録判定部１６２は、申請内容と実行条件情報を比較し、登録可否を判定する（Ｓ２６）。有効なアクセス申請でなければ、登録判定部１６２は申請を却下した上で、クライアント端末２００に却下通知し、以降の処理は実行されない。ここでは、有効なアクセス申請であったとして説明を続ける。
登録判定部１６２は、申請をアクセス予定保持部１５２のアクセス予定情報に登録する（Ｓ２８）。このときアクセスＩＤが付与される。承認が必要であれば、申請通知部１６０は承認を求める旨の電子メールを承認用端末３２２に送信する（Ｓ３０）。
【００６０】
図８は、アクセス承認処理の過程を示すシーケンス図である。
承認用端末３２２が図７のＳ３０において電子メールを受け取ったあと、承認者は任意のタイミングにて、自己のユーザ識別情報と共に申請管理装置１４０にアクセスする（Ｓ３２）。承認者はアクセスＩＤも指定する。
【００６１】
申請管理装置１４０は、承認者のユーザ識別情報をユーザ認証装置１２０に転送する（Ｓ３４）。ユーザ認証装置１２０のユーザ認証部１２２は、正規ユーザ情報を参照してユーザ認証を行う（Ｓ３６）。このユーザ認証では、正規ユーザであるだけでなく、「承認権限者」として登録されているかも判定される。ユーザ認証に失敗すれば、以降の処理は実行されない。ここでは、ユーザ認証が成功したものとして説明を続ける。
【００６２】
ユーザ認証装置１２０は、ユーザ認証の結果を示すデータ、ここでは認証成功の旨を示すデータを申請管理装置１４０に通知する（Ｓ３８）。申請管理装置１４０のアクセス承認部１５８は、承認画面２６０のためのＨＴＭＬデータを送信し（Ｓ４０）、承認用端末３２２は、承認画面２６０を表示させる（Ｓ４２）。ユーザは、承認画面２６０にデータを入力し、承認ボタン２７０または却下ボタン２７２をクリックすると（Ｓ４４）、入力されたデータが申請管理装置１４０に送信される（Ｓ４６）。
【００６３】
申請管理装置１４０のアクセス承認部１５８は、承認可否に応じてアクセス予定保持部１５２のアクセス予定情報を更新する（Ｓ４８）。アクセス承認部１５８は、クライアント端末２００に承認可否を通知する（Ｓ５０）。
以上の処理により、有効に申請されたアクセスについて承認がなされる。なお、承認者が、申請管理装置１４０にアクセスすると、申請管理装置１４０は承認待ちのアクセス申請を一覧表示させ、承認者はその中から承認対象となるアクセス申請を選択するというユーザインタフェースであってもよい。
【００６４】
図９は、ユーザ認証主導型において、クライアント端末２００からサーバ装置３２０へのリモートアクセス実行過程を示すシーケンス図である。
ユーザが人事システム３１０へアクセスする場合について説明する。このとき、クライアント端末２００から、人事システム３１０の入口であるサーバ装置３２０ａに対して、リモートアクセス要求が送信される（Ｓ１００）。このとき、ユーザ識別情報もサーバ装置３２０ａに送信される。サーバ装置３２０ａは、このユーザの権限グループをユーザ認証装置１２０に問い合わせる（Ｓ１０２）。申請管理装置１４０はユーザ認証装置１２０の正規ユーザ情報保持部１２４をアクセス予定情報に基づいて定期的に更新している。ユーザ認証装置１２０は、権限グループの判定の前に、まず、ユーザ識別情報に基づいて、ユーザ認証を実行する（Ｓ１０４）。ユーザ認証に失敗すると、人事システム３１０のアクセスは許可されないが、ここでは成功したものとして説明を続ける。次に、ユーザ認証装置１２０は、ログインユーザの権限グループを正規ユーザ情報保持部１２４を参照して特定し（Ｓ１０６）、サーバ装置３２０に通知する（Ｓ１０８）。ここでいう権限グループは、アクセス元のユーザの本来の権限グループかもしれないし、申請により暫定的に所属している権限グループかもしれない。サーバ装置３２０ａは、この権限グループを参照して、ユーザがサーバ装置３２０ａにアクセス可能な権限ユーザであれば（Ｓ１１０のＹ）、アクセス画面２９４の画面データをクライアント端末２００に送信する（Ｓ１１２）。権限ユーザでなければ（Ｓ１１０のＮ）、アクセスは許可されない。
【００６５】
アクセス画面２９４において、ユーザがアクセス対象となるフォルダ３２４を変更するときも同様である。たとえば、アクセス対象となるフォルダ３２４をサーバ装置３２０ａのフォルダ３２４ａからサーバ装置３２０ｂのフォルダ３２４ｆに変更するとする。ユーザがアクセス画面２９４において、アクセス先フォルダを変更すると、クライアント端末２００はサーバ装置３２０ｂにフォルダ変更要求を送信する。サーバ装置３２０は、このユーザがフォルダ３２４ｆについての権限ユーザであるかを判定する。権限ユーザであれば、クライアント端末２００からフォルダ３２４ｆへのアクセスを許可する。
【００６６】
図１０は、申請判定主導型において、クライアント端末２００からサーバ装置３２０へのリモートアクセス実行過程を示すシーケンス図である。
ここでも、ユーザが人事システム３１０へアクセスする場合について説明する。クライアント端末２００から、人事システム３１０の入口であるサーバ装置３２０ａに対して、リモートアクセス要求が送信される（Ｓ１２０）。ユーザ識別情報もサーバ装置３２０ａに送信される。サーバ装置３２０ａは、このユーザが事前に有効な申請をしているかを申請管理装置１４０に問い合わせる（Ｓ１２２）。申請済みでなければ（Ｓ１２４のＮ）、申請管理装置１４０はアクセス拒否通知をサーバ装置３２０に送信し（Ｓ１２６）、アクセスは失敗する。当該時間帯について有効に申請済みであれば（Ｓ１２４のＹ）、申請管理装置１４０はユーザ認証装置１２０に対してユーザ認証を依頼する（Ｓ１２４）。ユーザ認証装置１２０は、ユーザ識別情報に基づいて、ユーザ認証を実行する（Ｓ１２６）。すなわち、ユーザＩＤとパスワードがマッチしているかを判定する。ユーザ認証装置１２０は、ユーザ認証の結果をサーバ装置３２０に送信する（Ｓ１２８）。ユーザ認証に成功していれば、サーバ装置３２０は、アクセス画面２９４の画面データをクライアント端末２００に送信する（Ｓ１３０）。
なお、変形例として、申請済みでなければ（Ｓ１２４のＮ）、申請管理装置１４０はサーバ装置３２０にアクセス拒否通知を明示的に送信せず、ユーザ認証装置１２０へのユーザ認証も依頼しないとしてもよい。すなわち、申請済みでなければ、申請管理装置１４０において一連のプロセスが中断されることになる。サーバ装置３２０は、申請管理装置１４０への問い合わせ後（Ｓ１２２）、所定時間が経過しても、ユーザ認証装置１２０からユーザ認証の結果が返ってこなければ、リモートアクセスを拒否されたものとして判定してもよい。
【００６７】
図１１は、ユーザグループ変更処理の過程を示すシーケンス図である。
ユーザ認証主導型と申請判定主導型のいずれの場合であっても、業務情報防護装置１００は、各正規ユーザのユーザグループを定期的に変更することができる。たとえば、２００７年を契約期間として人事部に派遣される契約社員の場合、人事システム３１０の限定公開情報にアクセスできるのは２００７年だけである。また、２００７年３月３１日までは経理部に所属し、４月１日からは人事部へ配属になることが決まっている社員の場合、４月１日からユーザグループが変更となる。このように、正規ユーザのユーザグループ変更が組織のスケジュールとして確定していることも多い。ユーザグループ変更部１８２は、このような正規ユーザのユーザグループを変更するための条件として「グループ変更条件」を保持している。
申請管理装置１４０のユーザグループ変更部１８２は、同図に示すＳ８０、Ｓ８２、Ｓ８４の処理を定期的に繰り返す。このループ処理の開始タイミングは、所定時間、たとえば、毎日午前６時００分のように設定される。
【００６８】
ループ処理の開始タイミングに至ると、申請管理装置１４０のユーザグループ変更部１８２は、グループ変更条件を読み出し（Ｓ８０）、ユーザグループを変更させるべき正規ユーザが存在するか判定する（Ｓ８２）。ユーザグループ変更部１８２は、ユーザグループを変更すべきユーザが存在すれば（Ｓ８２のＹ）、その正規ユーザのユーザ識別情報と変更後のユーザグループをユーザ認証装置１２０に通知する（Ｓ８４）。ユーザ認証装置１２０は、正規ユーザ情報を更新する（Ｓ８６）。このようなループ処理により、正規ユーザ情報は定期的に更新される。
【００６９】
以上、本実施例に示した業務情報防護装置１００によれば、限定公開情報に対するアクセス権をユーザ認証と申請判定により判定するため、不正アクセスを防止しやすい構成となっている。権限ユーザは、クライアント端末２００にログインするだけで限定公開情報にアクセスできる。このため、部署パスワードの設定にともなう煩わしさが回避される。一方、非権限ユーザであっても、アクセス予定を事前に申請することにより限定公開情報にアクセスできる。申請判定主導型の場合、アクセス予定を事前に申請しなければ限定にアクセスできないため、よりセキュリティが強固となる。
更に、実行条件情報の設定や承認可否判定により、非権限ユーザの限定公開情報へのアクセス権を一時的・限定的に制御しやすくなっている。システムやサーバ装置３２０単位だけでなく、フォルダ３２４単位でアクセス権をコントロールできるため、限定公開情報の重要度に応じて、セキュリティを精緻かつ簡易に制御できる。グループ変更条件によりユーザグループを自動的に管理することにより、組織変更時においてもユーザに負担をかけることなく情報セキュリティを保つことができる。
このような特徴により、業務情報防護装置１００は、ＳＯＸ法が求める「内部統制の強化」に資する。
【００７０】
通常、リモートアクセス作業は、あらかじめ実行スケジュールが確定していることが多い。本実施例の業務情報防護装置１００によれば、事前のアクセス申請と任意のタイミングでの承認という運用により、ユーザおよび承認者に過度の心理的負担をかけないかたちで業務情報システム３００のセキュリティ管理を実現できる。
【００７１】
なお、業務情報システム３００の各サーバ装置３２０は、自装置に対するクライアント端末２００からのアクセス内容を業務情報防護装置１００に通知してもよい。そして、業務情報防護装置１００は、実際のアクセス内容を示すアクセスログとして記録してもよい。このような態様によれば、業務情報防護装置１００は、申請されたアクセス内容と、実際のアクセス内容に齟齬が発生していないかをチェックできる。このため、アクセス許可されたあとも、事後的に不正アクセスが発生していないかをチェックできる。
【００７２】
また、業務情報防護装置１００は、複数のシステムに対するアクセスを一元管理できる。そのため、複数のシステムに対して統一的なアクセスポリシーを適用しやすくなっている。更に、既に運用されている業務情報システム３００に対して、業務情報防護装置１００を追加するだけで実現できるというメリットもある。
【００７３】
以上、本発明を実施例をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００７４】
請求項に記載のアクセス申請受信部の機能は、本実施例においては主としてアクセス申請部１５６により実現される。請求項に記載のユーザ条件設定部とユーザグループ変更部の機能は、本実施例においては主としてユーザグループ変更部１８２により実現される。
このほかにも、請求項に記載の各構成要件が果たすべき機能は、本実施例において示された各機能ブロックの単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。
【図面の簡単な説明】
【００７５】
【図１】業務情報防護装置と業務情報システムとの関係を示すハードウェア構成図である。
【図２】業務情報防護装置の機能ブロック図である。
【図３】実行条件保持部における実行条件情報のデータ構造図である。
【図４】申請画面を示す画面図である。
【図５】承認画面を示す画面図である。
【図６】リモートログインに成功した後、クライアント端末から人事システムにアクセスするときのアクセス画面を示す図である。
【図７】アクセス申請処理の過程を示すシーケンス図である。
【図８】アクセス承認処理の過程を示すシーケンス図である。
【図９】ユーザ認証主導型において、クライアント端末からサーバ装置へのリモートアクセス実行過程を示すシーケンス図である。
【図１０】申請判定主導型において、クライアント端末からサーバ装置へのリモートアクセス実行過程を示すシーケンス図である。
【図１１】ユーザグループ変更処理の過程を示すシーケンス図である。
【符号の説明】
【００７６】
１００ 業務情報防護装置、 １２０ ユーザ認証装置、 １２２ ユーザ認証部、 １２４ 正規ユーザ情報保持部、 １４０ 申請管理装置、 １４２ 申請状態管理部、 １４４ 申請状態判定部、 １４６ アクセスインタフェース処理部、 １５０ 実行条件保持部、 １５２ アクセス予定保持部、 １５６ アクセス申請部、 １５８ アクセス承認部、 １６０ 申請通知部、 １６２ 登録判定部、 １８２ ユーザグループ変更部、 ２００ クライアント端末、 ３００ 業務情報システム、 ３１０ 人事システム、 ３１２ 経理システム、 ３２０ サーバ装置、 ３２２ 承認用端末、 ３２４ フォルダ。
【技術分野】
【０００１】
この発明は、組織業務を管理するための業務情報システムに関連し、特に、業務情報システムの情報セキュリティを向上させるための技術、に関する。
【背景技術】
【０００２】
企業や公共施設などの運用を支える業務情報システム、いわゆるエンタープライズシステム（Enterprise System）は、今や、大小さまざまな組織の基盤となっている。業務情報システムは、クライアント端末やデータベースから得られるデータを集計、蓄積、解析、加工した上でより付加価値の高い情報を出力することにより、複雑化する組織マネジメントを支えている。
【０００３】
業務情報システムが取り扱う情報（以下、「組織情報」とよぶ）は、以下の３種類に大別できる。
１．外部公開情報：組織内のみならず組織外にも公開可能な組織情報。たとえば、ＩＲ（Investor Relations）情報やプレスリリース情報が該当する。
２．内部公開情報：組織内において公開されるが、組織外には非公開となる組織情報。たとえば、社内掲示板の情報が該当する。
３．限定公開情報：特殊な内部公開情報であり、一部の組織構成員にのみ公開される情報。たとえば、取引先リスク評価情報は、通常、経理部や所定職位以上の社員のみがアクセスできる限定公開情報である。
【０００４】
一般的な業務情報システムは、パスワードなどのユーザ認証により、限定公開情報へのアクセスを制限することが多い。たとえば、経理部用の限定公開情報を格納する経理情報データベースに対して、経理部共通の「部署パスワード」を設定する。このような運用によれば、部署パスワードを知っている社員、いいかえれば、経理部に所属する社員だけが経理情報データベースの限定公開情報にアクセスできる。
【特許文献１】特開２００４−２１３４７５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかし、上記運用の場合、ある経理部員が別の部署に配属変更となると、部署パスワードが経理部以外に漏洩する可能性が高くなる。この経理部員が正社員でなく契約社員であれば、部署パスワードが組織外に漏洩する可能性も高くなる。部署パスワードを頻繁に変更すればこのような問題にある程度は対処できるが、他の経理部員にとって負担となる。
【０００６】
更に、経理部以外に所属する社員が経理情報データベースにアクセスしたい場合もある。この社員のアクセス範囲・アクセス時間等をコントロールできれば、経理情報データベースへの一時的・限定的なアクセスを許可してもよいかもしれない。しかし、この社員に部署パスワード自体を教えてしまうと、やはり部署パスワードが関係者以外に漏洩するかもしれない。
【０００７】
近年、アメリカで成立したＳＯＸ（Sarbanes‐Oxley）法は、企業経営者や会計監査人に対して公開情報の正当性を保証するように強く求めている。これに倣って、日本でも日本版ＳＯＸ法が導入される予定であり、日本版ＳＯＸ法に対応できる態勢の確立が急務となっている。
【０００８】
このような社会背景に鑑みて、本発明者は、業務情報システムへのアクセス、特に、限定公開情報に対する組織構成員からのアクセスに着目し、組織内部における業務情報システムへのアクセス規制を強化する必要があると認識した。特許文献１は、ＩＤとパスワードによるユーザ認証に加えて、管理者によるアクセス承認を条件とするアクセスルールを開示する。このようなアクセスルールは、業務情報システムへの不正アクセスを防止する上で有効な手法であるが、管理者は作業申請に即座に対応する必要があるため負担が大きい。本発明者は、限定公開情報に対する組織内からのアクセスをコントロールする上で、限定公開情報の流出抑制はもちろん重要であるが、限定公開情報へのアクセスにともなうユーザ負荷を抑制することもまた重要であると考える。
【０００９】
本発明は、本発明者の上記課題認識に基づいて完成された発明であり、その主たる目的は、業務情報システムにおける情報セキュリティを向上させるための技術、を提供することにある。
【課題を解決するための手段】
【００１０】
本発明の別の態様も、複数のサーバ装置の連携により組織業務を管理するための業務情報システムにおいて、クライアント端末からサーバ装置へのリモートアクセスを制御するための業務情報防護装置に関する。
この装置は、リモートアクセスの実行対象となるサーバ装置とリモートアクセスを実行予定のユーザとを示すアクセス申請情報を受信し、サーバ装置ごとのリモートアクセス予定を管理する。リモートアクセス予定に応じて、各ユーザの属するユーザグループを適宜変更する。クライアント端末からのいずれかのサーバ装置へのリモートアクセス要求がなされるとき、サーバ装置へのアクセス権限のあるユーザグループに所属している正規ユーザであることを条件として、サーバ装置へのリモートアクセスを許可する（後述する「ユーザ認証主導型」に対応する）。業務情報防護装置はサーバ装置に対してリモートアクセス要求元ユーザのユーザグループを通知し、サーバ装置は自装置についてあらかじめ設定されているユーザグループに当該ユーザが所属していることを条件としてユーザからのリモートアクセス要求を受け付けてもよい。
【００１１】
なお、以上の構成要素の任意の組合せ、本発明を方法、システム、記録媒体、コンピュータプログラムにより表現したものもまた、本発明の態様として有効である。
【発明の効果】
【００１２】
本発明によれば、業務情報システムにおける情報セキュリティを向上させることができる。
【発明を実施するための最良の形態】
【００１３】
本実施例においては、「ユーザ認証主導型」および「申請判定主導型」という２つの方式について説明する。ユーザ認証主導型を基本として説明するが、申請判定主導型についても適宜補足説明を加えつつ説明する。ユーザ認証主導型ではアクセスを申請しなくても限定公開情報にアクセスできる可能性があるが、申請判定主導型においてはアクセス申請が必須条件となる。ユーザ認証主導型または申請判定主導型のいずれかを採用するとしてもよいし、アクセス対象となるサーバ装置やフォルダごとにいずれかを採用してもよい。
【００１４】
図１は、業務情報防護装置１００と業務情報システム３００との関係を示すハードウェア構成図である。
業務情報システム３００は、企業Ａの組織業務を管理するシステムである。業務情報システム３００は、人事システム３１０と経理システム３１２という２種類のシステムを統合する。業務情報システム３００は、このほかにも、在庫管理、製品開発などさまざまなシステムを含んでもよい。
人事システム３１０は、人事情報データベースとしてのサーバ装置３２０ａとサーバ装置３２０ｂを含む。サーバ装置３２０ａのデータは、フォルダ（ディレクトリ）３２４ａ、３２４ｂ、３２４ｃにより階層化されている。サーバ装置３２０ｂのデータは、フォルダ３２４ｄ、３２４ｅ、３２４ｆ、３２４ｇにより階層化されている。サーバ装置３２０ａのフォルダ３２４ｃは、サーバ装置３２０ｂのフォルダ３２４ｄにマップ（map）されている。
経理システム３１２は、経理情報データベースとしてのサーバ装置３２０ｃとサーバ装置３２０ｄを含む。サーバ装置３２０ｃとサーバ装置３２０ｄのデータもフォルダ３２４により階層化されている。また、業務情報システム３００は、社内掲示板用ウェブサーバとしてのサーバ装置３２０ｅを含む。
【００１５】
業務情報システム３００と業務情報防護装置１００、クライアント端末２００ａ、２００ｂ、２００ｃといった複数のクライアント端末２００は、イントラネット（intranet）等の企業内ネットワークを介して互いに接続される。クライアント端末２００は、ウェブブラウザを搭載した一般的なＰＣ（Personal Computer）端末である。社員（以下、「正規ユーザ」ともよぶ）は、クライアント端末２００から業務情報システム３００にリモートアクセスする。業務情報システム３００や業務情報防護装置１００には、１以上の承認用端末３２２も接続される。承認用端末３２２も、ウェブブラウザを搭載した一般的なＰＣ端末である。承認用端末３２２の役割については後述する。
【００１６】
正規ユーザは、複数の「ユーザグループ」に分類される。「ユーザグループ」とは、たとえば、人事部や経理部のような所属、正社員や契約社員のような契約形態、課長や部長、取締役のような職位などの観点からユーザの分類したものである。たとえば、ある正規ユーザαは、「人事部」、「契約社員」、「事務職」というユーザグループに属し、別の正規ユーザβは、「営業部」、「正社員」、「部長」というユーザグループに属するかもしれない。
【００１７】
人事システム３１０や経理システム３１２において、各サーバ装置３２０が保持するデータは限定公開情報である。サーバ装置３２０ａの限定公開情報にアクセスできるのは「人事部」に所属する正規ユーザだけであるかもしれない。また、サーバ装置３２０ｂのフォルダ３２４ｅに保持される限定公開情報にアクセスできるのは、「部長以上」であって「人事部」に所属する正規ユーザだけであるかもしれない。各システム、各サーバ装置３２０、各フォルダ３２４には、限定公開情報にアクセスできるユーザグループ（以下、「権限グループ」とよぶ）があらかじめ設定されている。さきほどの例であれば、フォルダ３２４ｅの限定公開情報についての権限グループは、「部長以上」かつ「人事部」となる。
【００１８】
一方、サーバ装置３２０ｅが保持するデータは内部公開情報である。したがって、企業Ａの社員であれば、すなわち正規ユーザでさえあればサーバ装置３２０ｅの内部公開情報へアクセスできる。サーバ装置３２０ｅの一部のフォルダ３２４は、完全公開情報も保持する。この場合、正規ユーザでないユーザであってもサーバ装置３２０ｅの完全公開情報にアクセスできる。
業務情報防護装置１００は、内部公開情報や限定公開情報に対するクライアント端末２００からのリモートアクセス可否を判定するための装置である。以下においては、限定公開情報へのリモートアクセスを中心として説明する。
【００１９】
業務情報防護装置１００は、ユーザ認証装置１２０と申請管理装置１４０を含む。業務情報防護装置１００は、ユーザ認証装置１２０と申請管理装置１４０の機能を一体として備える単一の装置であってもよいが、本実施例においては、これら２つの装置の集合体であるとして説明する。
【００２０】
ユーザは、内部公開情報や限定公開情報にアクセスする上で、まず、クライアント端末２００にログインする。このとき、クライアント端末２００には、ユーザＩＤとパスワードが入力される。以下、ユーザＩＤやパスワードのように、ユーザを識別するためのデータのことを「ユーザ識別情報」とよぶ。クライアント端末２００は、ユーザ識別情報をユーザ認証装置１２０に渡す。クライアント端末２００は、申請管理装置１４０やサーバ装置３２０を経由してユーザ認証装置１２０にユーザ識別情報を渡してもよいし、ユーザ認証装置１２０に直接転送してもよい。
ユーザ認証装置１２０は、クライアント端末２００に代わって、ログイン要求元のユーザが正規ユーザであるか判定する（以下、「ユーザ認証」とよぶ）。
【００２１】
限定公開情報の権限グループに所属しているユーザでなければ、限定公開情報にアクセスすることはできない。人事システム３１０のサーバ装置３２０ａは、「人事部」のユーザであればアクセス可能である。あるユーザがサーバ装置３２０ａをアクセス先として指定するとき、このユーザが人事部に所属していれば、サーバ装置３２０ａへのアクセスは許可される。一方、ユーザが人事部に所属していないときでも、このユーザがサーバ装置３２０ａに対するリモートアクセスを事前に（正しく）申請済みであればアクセスを許可される。申請管理装置１４０が申請済みか否かを判定する（以下、「申請判定」とよぶ）。ただし、申請判定主導型の場合、たとえユーザが人事部に所属していても、事前の申請が必須となる。
以下においては、限定公開情報Ａについての権限グループに属する正規ユーザのことを限定公開情報Ａの「権限ユーザ」とよぶ。また、限定公開情報Ａに対する権限ユーザ以外の正規ユーザのことを「非権限ユーザ」とよぶ。
ユーザは、クライアント端末２００から、業務情報システム３００の任意のサーバ装置３２０、ひいては、任意のフォルダ３２４にアクセスする。
【００２２】
クライアント端末２００とサーバ装置３２０との接続が確立したあと、ログインユーザは、アクセス対象となるフォルダ３２４を変更できる。このとき、クライアント端末２００から該当サーバ装置３２０に「フォルダ変更要求」が送信される。変更先のフォルダ３２４が保持する情報が限定公開情報であれば、サーバ装置３２０は、ログインユーザがその限定公開情報についての権限ユーザであるかを判定する。権限ユーザであれば、フォルダ変更要求を許可する。本来、非権限ユーザであっても、申請管理装置１４０に事前に正しく申請していれば、フォルダ変更要求が許可される。ただし、申請判定主導型の場合、権限ユーザであっても、事前の申請が必須となる。
【００２３】
以上をまとめると、
１．内部公開情報に対しては、ユーザ認証によりアクセス権を判定する。
２．限定公開情報に対しては、
２−１．ユーザ認証主導型の場合、権限ユーザであれば、申請判定の判定結果に関わらずアクセス可能である。通常は、申請判定自体を実行しない。一方、本来的に非権限ユーザであっても、事前の申請により暫定的に権限ユーザとなって限定公開情報にアクセスすることができる。
２−２．申請判定主導型の場合、権限ユーザであろうとも、事前の申請がなされていなければアクセスは不可能である。
【００２４】
内部公開情報や限定公開情報は、サーバ装置３２０やフォルダ３２４を単位として管理できる。限定公開情報を保持するサーバ装置３２０やフォルダ３２４は、権限グループについての情報を保持する。サーバ装置３２０ａは、人事システム３１０についての権限グループ情報、サーバ装置３２０ａについての権限グループ情報を保持する。また、サーバ装置３２０ａのフォルダ３２４ｂは、フォルダ３２４ｂの権限グループ情報を保持する。同様にして、サーバ装置３２０ｂはサーバ装置３２０ｂの権限グループ情報を保持する。
【００２５】
なお、所定の限定公開情報については権限グループを設定しなくてもよい。たとえば、サーバ装置３２０ｂのフォルダ３２４ｇの限定公開情報Ｂには権限グループが設定されていない。正規ユーザがどのようなユーザグループに所属していようとも、この限定公開情報Ｂにアクセスするために必ずアクセス申請しなければならない。すなわち、限定公開情報Ｂについては、すべての正規ユーザは非権限ユーザとなる。特に機密性の高い限定公開情報については、このような設定方法も有効である。これは事実上、申請判定主導型によるセキュリティ管理と同様の効果を発揮することになる。
ユーザ認証主導型によるリモートアクセスの手続きの流れについては図９に関連して詳述する。また、申請判定主導型によるリモートアクセスの手続きの流れについては図１０に関連して詳述する。
【００２６】
図２は、業務情報防護装置１００の機能ブロック図である。
ここに示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。ここでは、各部の機能を中心として説明し、それらの連携、データ構造、作用については、図３以降に関連して詳述する。
【００２７】
本実施例における業務情報防護装置１００は、互いに通信回線で接続されたユーザ認証装置１２０と申請管理装置１４０を含む。
【００２８】
ユーザは、業務情報システム３００へアクセスする前に、まず、クライアント端末２００にログインする。このとき、クライアント端末２００にはユーザＩＤとパスワードが入力される。本実施例においては、このユーザＩＤとパスワードは、ユーザ認証装置１２０によるユーザ認証や申請管理装置１４０による申請判定のために転送される。
【００２９】
Ａ：ユーザ認証装置１２０
ユーザ認証装置１２０は、ユーザ認証部１２２と正規ユーザ情報保持部１２４を含む。正規ユーザ情報保持部１２４は、ユーザＩＤとパスワード、ユーザグループを対応づけた正規ユーザ情報を保持する。この正規ユーザ情報に登録されているユーザが「正規ユーザ」となる。ユーザがクライアント端末２００にログインするとき、クライアント端末２００はユーザ認証部１２２にユーザ識別情報を送信する。ユーザ認証部１２２は、このユーザ識別情報と正規ユーザ情報を比較することによりユーザ認証を行う。ユーザ認証部１２２は、クライアント端末２００のユーザだけでなく承認用端末３２２のユーザについてもユーザ認証を実行する。
【００３０】
本実施例におけるユーザ認証装置１２０は単一の装置であり、正規ユーザ情報を一元的に管理する。複数のシステムについてのユーザ認証を単一のユーザ認証装置１２０にて実行することにより、ユーザ認証ポリシー（policy）を一元的に管理できる。
【００３１】
Ｂ：申請管理装置１４０
申請管理装置１４０は、申請状態管理部１４２、申請状態判定部１４４、アクセスインタフェース処理部１４６、ユーザグループ変更部１８２、実行条件保持部１５０およびアクセス予定保持部１５２を含む。
【００３２】
実行条件保持部１５０は、非権限ユーザについてのアクセスルールを示す実行条件情報を保持する。リモートアクセスの目的は複数の種別（以下、単に「アクセス種別」とよぶ）に分類される。アクセス種別として、データを閲覧するだけの「データ参照」、新たなデータを登録するための「データ追加」、既存のデータを書き換えるための「データ変更」、ソフトウェアインストールなどの「リリース作業」などが挙げられる。ユーザ認証主導型の場合、権限ユーザは事前のアクセス申請をしなくても限定公開情報にアクセスできるが、非権限ユーザはアクセス日時、アクセス種別等を明示した「アクセス申請情報」を業務情報防護装置１００に送信することにより、アクセス予定を事前に申請しておかなければならない。後述の登録判定部１６２は、実行条件情報を参照して、このアクセス申請情報の適否をチェックする。
【００３３】
たとえば、サーバ装置３２０ａの権限グループが「人事部」であるとき、情報技術部のユーザがこのサーバ装置３２０ａに新しいソフトウェアをインストールしたいとする。このユーザは、サーバ装置３２０ａについては非権限ユーザである。ここで、サーバ装置３２０ａの管理責任者は、サーバ装置３２０ａへの「リリース作業」が２月１日にのみ実行可能である旨を実行条件情報に登録したとする。
【００３４】
非権限ユーザが１月３０日を予定日としてサーバ装置３２０ａへの「リリース作業」を申請しても、アクセスルールに適合しないためこの申請は自動的に却下される。このように、サーバ装置３２０ａの管理責任者は、サーバ装置３２０ａに対する非権限ユーザのアクセスルールを実行条件情報としてあらかじめ登録しておくことができる。
更に、承認権限のある特別なユーザ（以下、単に「承認者」とよぶ）によって申請が承認されなければならない旨を実行条件情報に登録することもできる。実行条件情報のデータ構造については、次の図３に関連して更に詳述する。
【００３５】
申請状態管理部１４２は、アクセス申請に関する処理を全般的に担当する。申請状態管理部１４２は、アクセス申請部１５６、アクセス承認部１５８、申請通知部１６０および登録判定部１６２を含む。
【００３６】
アクセス申請部１５６は、アクセス申請情報を受信する。アクセス申請情報は、後の図４に示す申請画面２２０において入力されるデータの集合である。後の図４では、入力データとして、アクセスの目的、日時、件名、アクセス対象となるサーバ名などが示されるが、このほかにも、申請者のメールアドレスなどさまざまな情報が含まれてもよい。更に、申請日時や申請者のＩＰアドレスなど、入力されたデータ以外の付帯情報が含まれてもよい。登録判定部１６２は、アクセス申請情報が実行条件情報と適合するか判定する。先ほどの例でいえば、２月１日以外を対象としてサーバ装置３２０ａに対するリリース作業が申請された場合、登録判定部１６２はこの申請を却下し、その旨を非権限ユーザに通知する。申請内容が実行条件情報と適合していれば、登録判定部１６２はアクセス予定保持部１５２のアクセス予定情報に、申請を登録する。アクセス予定情報に登録されたアクセス申請のことを「有効なアクセス申請」とよぶ。アクセス予定情報の内容は、アクセス申請情報の内容と実質的に同等であってよい。すなわち、受信されたアクセス申請情報のうち、有効なアクセス申請としての要件を満たすアクセス申請情報だけがアクセス予定情報として正式登録される。登録判定部１６２は、有効なアクセス申請がなされると、リモートアクセス予定を一意に識別するためのアクセスＩＤを付与する。アクセス予定情報では、アクセスＩＤ、アクセス予定日時、アクセス内容、ユーザ名、承認状態等が対応づけられる。
【００３７】
申請通知部１６０は、アクセス申請情報が登録されると、その申請内容が承認を必要とするものであるか否かを実行条件情報を参照して判定する。申請通知部１６０は、承認が必要なアクセス申請情報について、そのアクセスＩＤを承認者に通知する。本実施例における申請通知部１６０は、アクセスＩＤを示す電子メールを承認用端末３２２に送信する。承認者は、アクセスＩＤに基づいて申請管理装置１４０にアクセスし、承認可否を入力する。アクセス承認部１５８は、承認可否を承認用端末３２２から受信する。このときのユーザインタフェースに関しては図５に関連して後述する。
【００３８】
アクセス承認部１５８は、承認がなされると、アクセス予定情報における承認状態を「未承認」から「承認」に変更する。却下の場合には、アクセス承認部１５８はユーザに申請却下の旨を通知すると共に、アクセス予定情報から該当申請を抹消する。また、登録判定部１６２は、アクセス予定情報のうち、アクセス予定日時を経過した申請や、すでに完了した申請を適宜抹消する。
【００３９】
申請状態判定部１４４は申請判定を実行する。ここで、ユーザ認証主導型と申請判定主導型について簡単に説明しておく。
【００４０】
１：ユーザ認証主導型
リモートログインに際し、クライアント端末２００はユーザ識別情報をサーバ装置３２０に送信する。サーバ装置３２０はユーザ識別情報をユーザ認証装置１２０に送信し、ユーザ認証装置１２０はユーザ認証を実行する。ここで、ログイン要求元のユーザが正規ユーザであれば、ユーザの所属するユーザグループをサーバ装置３２０に通知する。サーバ装置３２０についての権限ユーザであれば、サーバ装置３２０はアクセスを許可し、クライアント端末２００との通信経路を確立する。
【００４１】
申請管理装置１４０のユーザグループ変更部１８２は、アクセス予定情報に基づいて、適宜、ユーザ認証装置１２０の正規ユーザ情報を更新する。たとえば、情報技術部のユーザＡが、「２月１日から２月２日」を対象として、人事システム３１０へのアクセス予定を有効に申請している状況を想定する。本来、ユーザＡは、人事システム３１０のサーバ装置３２０ａに関する権限ユーザではないが、申請された「２月１日から２月２日」に限って一時的にアクセス権限を付与される。
ユーザグループ変更部１８２は、２月１日に至るとユーザＡのユーザグループとして一時的に「人事部」と登録する。そして、２月２日が終わるとき、ユーザＡのユーザグループから「人事部」を抹消する。いわば、ユーザＡは申請期間に限って暫定的に人事部に所属することになる。
【００４２】
このようにして申請管理装置１４０は、適宜、正規ユーザ情報保持部１２４を更新することになる。このため、リモートアクセス実行時において、ユーザ認証装置１２０は、ユーザ識別情報に基づいて、事実上、ユーザ認証と申請判定をまとめて実行できることになる。リモートログインに限らず、フォルダ変更要求についても同様のアルゴリズムにてユーザ認証主導型によるアクセス制御が可能である。
【００４３】
２：申請判定主導型
この申請判定主導型においては、有効なアクセス申請がなされていなければ業務情報システム３００へのアクセスを許可しない。このため、特に情報セキュリティを重視する場合に好ましい処理モデルである。
リモートログインに際し、クライアント端末２００はユーザ識別情報をサーバ装置３２０に送信する。サーバ装置３２０はユーザ識別情報を申請管理装置１４０に送信する。ここで、申請管理装置１４０はユーザ識別情報に含まれるユーザＩＤを取得し、当該ユーザが有効にアクセス申請済みであるか判定する。有効なアクセス申請がなされていなければ、ユーザ認証を実行することなくアクセスは拒否される。
【００４４】
有効にアクセス申請済みであれば、申請管理装置１４０はユーザ識別情報をユーザ認証装置１２０に転送する。ユーザ認証装置１２０はここでユーザＩＤとパスワードをチェックしてユーザ認証を実行する。ログイン要求元のユーザが正規ユーザであれば、ユーザ認証装置１２０はアクセス許可通知をサーバ装置３２０に通知する。サーバ装置３２０は、アクセス許可通知を受信したことを条件として、クライアント端末２００との通信経路を確立する。
【００４５】
すなわち、申請管理装置１４０は、アクセス予定情報に基づいて、有効にアクセス申請していないユーザのアクセスをユーザ認証の前段階にて排除する。リモートログインに限らず、フォルダ変更要求についても同様のアルゴリズムにて申請判定主導型によるアクセス制御が可能である。詳細については図１０に関連して後述する。
【００４６】
１．ユーザ認証主導型の場合、申請状態判定部１４４は、ユーザ識別情報とアクセス予定情報を定期的に参照して、アクセス申請済か否か、必要であれば、更に承認済みか否かを判定する。
２．申請判定主導型の場合においては、申請状態判定部１４４は、リモートアクセス要求日時が、申請されたアクセス予定時間内にあるかについても判定する。たとえば、ある非権限ユーザαが「２月１日」というアクセス予定日時を指定してサーバ装置３２０ａへのアクセス申請をしている場合、１月３１日以前や２月２日以後にサーバ装置３２０ａにリモートアクセス要求をしても申請判定の結果は「否定」となり、リモートアクセスは許可されない。一方、非権限ユーザＡが「２月１日」というアクセス予定日時においてサーバ装置３２０ａにリモートアクセス要求してきたときには、申請判定の結果は「肯定」となり、アクセスインタフェース処理部１４６はアクセスを許可する。
もちろん、承認が必要なアクセスが申請されているときには、承認済みでなければアクセス許可されない。アクセスインタフェース処理部１４６は、サーバ装置３２０やフォルダ３２４へのアクセス可否判定を統括的に制御する。
【００４７】
本実施例における申請管理装置１４０は単一の装置であり、申請判定を一元的に実行する。複数システムに関する申請判定を単一の申請管理装置１４０にて実行することにより、実行条件情報やアクセス予定情報を一元的に管理できる。
【００４８】
図３は、実行条件保持部１５０における実行条件情報のデータ構造図である。
実行条件情報は、各サーバ装置３２０やフォルダ３２４の管理責任者により定められたアクセスルールを示す。ルールＩＤ欄１６４は、アクセスルールを一意に識別するためのＩＤ（以下、「ルールＩＤ」とよぶ）を示す。アクセスルールが登録されると、ルールＩＤが割り当てられる。対象領域欄１６６は、アクセスルールの適用対象となるサーバ装置３２０やフォルダ３２４を示す。日時欄１６８は、アクセスルールの適用日時を示す。アクセス種別欄１７０は、アクセスルールが適用されるアクセス種別を示す。承認要否欄１７２は、該当アクセスの実行をするために承認が必要か否かを示す。たとえば、ルールＩＤ「１」のアクセスルールは、「サーバＩＤ：０６」のサーバ装置３２０（以下、「サーバ装置３２０（０６）」と表記する）における「フォルダＩＤ：２４」のフォルダ３２４（以下、「フォルダ３２４（２４）」と表記する）に保持される限定公開情報に関し、「６：００〜１６：００」の時間帯について適用される。
【００４９】
すなわち、サーバ装置３２０（０６）のフォルダ３２４（２４）に非権限ユーザがアクセスする場合、「６：００〜１６：００」という時間帯に限って、「データ参照」か「データ追加」というアクセス種別にて事前申請をしていればアクセスが許可される。承認は不要であり、正しく申請さえしていればよい。しかし、「データ変更」を目的として申請をしても却下されることになる。また、この時間帯以外のアクセスは許可されない。
【００５０】
一方、サーバ装置３２０（０８）に非権限ユーザがアクセスする場合、「６：００〜１６：００」という時間帯に限って、「データ変更」か「リリース作業」というアクセス種別にて事前申請をし、かつ、承認を得られればアクセスが許可される。
【００５１】
図４は、申請画面２２０を示す画面図である。
ユーザがアクセス申請のために申請管理装置１４０にアクセスすると、アクセス申請部１５６はクライアント端末２００に同図に示す申請画面２２０を表示させる。申請画面２２０は、クライアント端末２００にウェブページとして表示される画面である。
【００５２】
申請者名領域２２２には、申請者名を入力する。申請者は、自分以外が作業をするときには、実際に作業を実行する予定のユーザ名を入力する。件名領域２２４には、申請する作業の件名を入力する。システム分類領域２２６からは、対象システムのタイプが選択される。ここでは、経理システム３１２が選択されている。サーバ指定領域２２７はアクセス対象となるサーバ装置３２０のサーバＩＤ、フォルダ指定領域２２８はアクセス対象となるフォルダ３２４のフォルダＩＤを示す。サーバ指定領域２２７やフォルダ指定領域２２８においては複数のサーバ装置３２０や複数のフォルダ３２４を指定してもよい。
【００５３】
アクセス種別領域２３０はアクセス種別を示す。内容入力領域２３２は、作業内容などを自由記述するための領域である。アクセス予定日時領域２３４は、アクセス予定日時を示す。申請者は、申請画面２２０に示される各項目にデータを入力した後、申請ボタン２３６をクリックする。すると、入力されたデータがアクセス申請情報として申請管理装置１４０に送信される。
【００５４】
図５は、承認画面２６０を示す画面図である。
承認が必要なアクセス申請がなされた場合、申請通知部１６０はアクセスＩＤを承認用端末３２２に通知する。承認者が、アクセスＩＤを指定して申請管理装置１４０にアクセスすると、アクセス承認部１５８は承認用端末３２２に同図に示す承認画面２６０を表示させる。承認画面２６０も、承認用端末３２２にウェブページとして表示される。
【００５５】
申請情報領域２６２は、申請画面２２０に入力された申請内容を示す。承認者名領域２６４は、承認者名を入力する領域である。承認依頼者名領域２６６は、承認を依頼したユーザ名を入力するための領域である。たとえば、承認権限のあるユーザＢが、ユーザＣに承認を依頼したときには、ユーザＣはユーザＢに代理して承認判断を行う。これは、ユーザＢの休暇中など、特殊な状況に対応するための措置である。通信欄２６８は、申請者に対するメッセージを記述する欄である。申請却下の理由を記述したり、申請承認するときには作業内容に条件や注文をつけるための記述がなされてもよい。承認ボタン２７０は承認用、却下ボタン２７２は却下用のボタンである。承認ボタン２７０から却下ボタン２７２のいずれかがクリックされると、入力内容と承認可否を示すデータが申請管理装置１４０に送信される。アクセス承認部１５８は、このデータをクライアント端末２００に、たとえば、電子メールにより送信する。
【００５６】
図６は、リモートログインに成功した後、クライアント端末２００から人事システム３１０にアクセスするときのアクセス画面２９４を示す。
クライアント端末２００から人事システム３１０への接続が確立すると、人事システム３１０のフォルダ構造を示すアクセス画面２９４がクライアント端末２００に表示される。同図に示すように、サーバ装置３２０ａとサーバ装置３２０ｂの各フォルダ３２４が階層化されて画面表示される。ユーザは、アクセス先となるフォルダ３２４を選択する。このとき、クライアント端末２００から該当サーバ装置３２０にフォルダ変更要求が送信される。ユーザ認証主導型の場合、該当サーバ装置３２０は、ユーザが変更先のフォルダ３２４についての権限ユーザであるかを判定する。
【００５７】
図７は、アクセス申請処理の過程を示すシーケンス図である。
アクセス申請時においては、クライアント端末２００のユーザは、ユーザ識別情報を送信して、直接、申請管理装置１４０にアクセスする（Ｓ１０）。申請管理装置１４０は、ユーザ識別情報をユーザ認証装置１２０に転送する（Ｓ１２）。ユーザ認証装置１２０のユーザ認証部１２２は、ユーザ認証を実行する（Ｓ１４）。ユーザ認証に失敗すれば、以降の処理は実行されない。ここでは、ユーザ認証が成功したものとして説明を続ける。
【００５８】
ユーザ認証装置１２０は、ユーザ認証の結果、すなわち、認証成功の旨を申請管理装置１４０に通知する（Ｓ１６）。申請管理装置１４０のアクセス申請部１５６は、申請画面２２０のためのＨＴＭＬ（Hyper Text Markup Language）データを送信し（Ｓ１８）、クライアント端末２００は、申請画面２２０を表示させる（Ｓ２０）。ユーザは、申請画面２２０にデータを入力し、申請ボタン２３６をクリックすると（Ｓ２２）、入力されたデータがアクセス申請情報として申請管理装置１４０に送信される（Ｓ２４）。
【００５９】
申請管理装置１４０の登録判定部１６２は、申請内容と実行条件情報を比較し、登録可否を判定する（Ｓ２６）。有効なアクセス申請でなければ、登録判定部１６２は申請を却下した上で、クライアント端末２００に却下通知し、以降の処理は実行されない。ここでは、有効なアクセス申請であったとして説明を続ける。
登録判定部１６２は、申請をアクセス予定保持部１５２のアクセス予定情報に登録する（Ｓ２８）。このときアクセスＩＤが付与される。承認が必要であれば、申請通知部１６０は承認を求める旨の電子メールを承認用端末３２２に送信する（Ｓ３０）。
【００６０】
図８は、アクセス承認処理の過程を示すシーケンス図である。
承認用端末３２２が図７のＳ３０において電子メールを受け取ったあと、承認者は任意のタイミングにて、自己のユーザ識別情報と共に申請管理装置１４０にアクセスする（Ｓ３２）。承認者はアクセスＩＤも指定する。
【００６１】
申請管理装置１４０は、承認者のユーザ識別情報をユーザ認証装置１２０に転送する（Ｓ３４）。ユーザ認証装置１２０のユーザ認証部１２２は、正規ユーザ情報を参照してユーザ認証を行う（Ｓ３６）。このユーザ認証では、正規ユーザであるだけでなく、「承認権限者」として登録されているかも判定される。ユーザ認証に失敗すれば、以降の処理は実行されない。ここでは、ユーザ認証が成功したものとして説明を続ける。
【００６２】
ユーザ認証装置１２０は、ユーザ認証の結果を示すデータ、ここでは認証成功の旨を示すデータを申請管理装置１４０に通知する（Ｓ３８）。申請管理装置１４０のアクセス承認部１５８は、承認画面２６０のためのＨＴＭＬデータを送信し（Ｓ４０）、承認用端末３２２は、承認画面２６０を表示させる（Ｓ４２）。ユーザは、承認画面２６０にデータを入力し、承認ボタン２７０または却下ボタン２７２をクリックすると（Ｓ４４）、入力されたデータが申請管理装置１４０に送信される（Ｓ４６）。
【００６３】
申請管理装置１４０のアクセス承認部１５８は、承認可否に応じてアクセス予定保持部１５２のアクセス予定情報を更新する（Ｓ４８）。アクセス承認部１５８は、クライアント端末２００に承認可否を通知する（Ｓ５０）。
以上の処理により、有効に申請されたアクセスについて承認がなされる。なお、承認者が、申請管理装置１４０にアクセスすると、申請管理装置１４０は承認待ちのアクセス申請を一覧表示させ、承認者はその中から承認対象となるアクセス申請を選択するというユーザインタフェースであってもよい。
【００６４】
図９は、ユーザ認証主導型において、クライアント端末２００からサーバ装置３２０へのリモートアクセス実行過程を示すシーケンス図である。
ユーザが人事システム３１０へアクセスする場合について説明する。このとき、クライアント端末２００から、人事システム３１０の入口であるサーバ装置３２０ａに対して、リモートアクセス要求が送信される（Ｓ１００）。このとき、ユーザ識別情報もサーバ装置３２０ａに送信される。サーバ装置３２０ａは、このユーザの権限グループをユーザ認証装置１２０に問い合わせる（Ｓ１０２）。申請管理装置１４０はユーザ認証装置１２０の正規ユーザ情報保持部１２４をアクセス予定情報に基づいて定期的に更新している。ユーザ認証装置１２０は、権限グループの判定の前に、まず、ユーザ識別情報に基づいて、ユーザ認証を実行する（Ｓ１０４）。ユーザ認証に失敗すると、人事システム３１０のアクセスは許可されないが、ここでは成功したものとして説明を続ける。次に、ユーザ認証装置１２０は、ログインユーザの権限グループを正規ユーザ情報保持部１２４を参照して特定し（Ｓ１０６）、サーバ装置３２０に通知する（Ｓ１０８）。ここでいう権限グループは、アクセス元のユーザの本来の権限グループかもしれないし、申請により暫定的に所属している権限グループかもしれない。サーバ装置３２０ａは、この権限グループを参照して、ユーザがサーバ装置３２０ａにアクセス可能な権限ユーザであれば（Ｓ１１０のＹ）、アクセス画面２９４の画面データをクライアント端末２００に送信する（Ｓ１１２）。権限ユーザでなければ（Ｓ１１０のＮ）、アクセスは許可されない。
【００６５】
アクセス画面２９４において、ユーザがアクセス対象となるフォルダ３２４を変更するときも同様である。たとえば、アクセス対象となるフォルダ３２４をサーバ装置３２０ａのフォルダ３２４ａからサーバ装置３２０ｂのフォルダ３２４ｆに変更するとする。ユーザがアクセス画面２９４において、アクセス先フォルダを変更すると、クライアント端末２００はサーバ装置３２０ｂにフォルダ変更要求を送信する。サーバ装置３２０は、このユーザがフォルダ３２４ｆについての権限ユーザであるかを判定する。権限ユーザであれば、クライアント端末２００からフォルダ３２４ｆへのアクセスを許可する。
【００６６】
図１０は、申請判定主導型において、クライアント端末２００からサーバ装置３２０へのリモートアクセス実行過程を示すシーケンス図である。
ここでも、ユーザが人事システム３１０へアクセスする場合について説明する。クライアント端末２００から、人事システム３１０の入口であるサーバ装置３２０ａに対して、リモートアクセス要求が送信される（Ｓ１２０）。ユーザ識別情報もサーバ装置３２０ａに送信される。サーバ装置３２０ａは、このユーザが事前に有効な申請をしているかを申請管理装置１４０に問い合わせる（Ｓ１２２）。申請済みでなければ（Ｓ１２４のＮ）、申請管理装置１４０はアクセス拒否通知をサーバ装置３２０に送信し（Ｓ１２６）、アクセスは失敗する。当該時間帯について有効に申請済みであれば（Ｓ１２４のＹ）、申請管理装置１４０はユーザ認証装置１２０に対してユーザ認証を依頼する（Ｓ１２４）。ユーザ認証装置１２０は、ユーザ識別情報に基づいて、ユーザ認証を実行する（Ｓ１２６）。すなわち、ユーザＩＤとパスワードがマッチしているかを判定する。ユーザ認証装置１２０は、ユーザ認証の結果をサーバ装置３２０に送信する（Ｓ１２８）。ユーザ認証に成功していれば、サーバ装置３２０は、アクセス画面２９４の画面データをクライアント端末２００に送信する（Ｓ１３０）。
なお、変形例として、申請済みでなければ（Ｓ１２４のＮ）、申請管理装置１４０はサーバ装置３２０にアクセス拒否通知を明示的に送信せず、ユーザ認証装置１２０へのユーザ認証も依頼しないとしてもよい。すなわち、申請済みでなければ、申請管理装置１４０において一連のプロセスが中断されることになる。サーバ装置３２０は、申請管理装置１４０への問い合わせ後（Ｓ１２２）、所定時間が経過しても、ユーザ認証装置１２０からユーザ認証の結果が返ってこなければ、リモートアクセスを拒否されたものとして判定してもよい。
【００６７】
図１１は、ユーザグループ変更処理の過程を示すシーケンス図である。
ユーザ認証主導型と申請判定主導型のいずれの場合であっても、業務情報防護装置１００は、各正規ユーザのユーザグループを定期的に変更することができる。たとえば、２００７年を契約期間として人事部に派遣される契約社員の場合、人事システム３１０の限定公開情報にアクセスできるのは２００７年だけである。また、２００７年３月３１日までは経理部に所属し、４月１日からは人事部へ配属になることが決まっている社員の場合、４月１日からユーザグループが変更となる。このように、正規ユーザのユーザグループ変更が組織のスケジュールとして確定していることも多い。ユーザグループ変更部１８２は、このような正規ユーザのユーザグループを変更するための条件として「グループ変更条件」を保持している。
申請管理装置１４０のユーザグループ変更部１８２は、同図に示すＳ８０、Ｓ８２、Ｓ８４の処理を定期的に繰り返す。このループ処理の開始タイミングは、所定時間、たとえば、毎日午前６時００分のように設定される。
【００６８】
ループ処理の開始タイミングに至ると、申請管理装置１４０のユーザグループ変更部１８２は、グループ変更条件を読み出し（Ｓ８０）、ユーザグループを変更させるべき正規ユーザが存在するか判定する（Ｓ８２）。ユーザグループ変更部１８２は、ユーザグループを変更すべきユーザが存在すれば（Ｓ８２のＹ）、その正規ユーザのユーザ識別情報と変更後のユーザグループをユーザ認証装置１２０に通知する（Ｓ８４）。ユーザ認証装置１２０は、正規ユーザ情報を更新する（Ｓ８６）。このようなループ処理により、正規ユーザ情報は定期的に更新される。
【００６９】
以上、本実施例に示した業務情報防護装置１００によれば、限定公開情報に対するアクセス権をユーザ認証と申請判定により判定するため、不正アクセスを防止しやすい構成となっている。権限ユーザは、クライアント端末２００にログインするだけで限定公開情報にアクセスできる。このため、部署パスワードの設定にともなう煩わしさが回避される。一方、非権限ユーザであっても、アクセス予定を事前に申請することにより限定公開情報にアクセスできる。申請判定主導型の場合、アクセス予定を事前に申請しなければ限定にアクセスできないため、よりセキュリティが強固となる。
更に、実行条件情報の設定や承認可否判定により、非権限ユーザの限定公開情報へのアクセス権を一時的・限定的に制御しやすくなっている。システムやサーバ装置３２０単位だけでなく、フォルダ３２４単位でアクセス権をコントロールできるため、限定公開情報の重要度に応じて、セキュリティを精緻かつ簡易に制御できる。グループ変更条件によりユーザグループを自動的に管理することにより、組織変更時においてもユーザに負担をかけることなく情報セキュリティを保つことができる。
このような特徴により、業務情報防護装置１００は、ＳＯＸ法が求める「内部統制の強化」に資する。
【００７０】
通常、リモートアクセス作業は、あらかじめ実行スケジュールが確定していることが多い。本実施例の業務情報防護装置１００によれば、事前のアクセス申請と任意のタイミングでの承認という運用により、ユーザおよび承認者に過度の心理的負担をかけないかたちで業務情報システム３００のセキュリティ管理を実現できる。
【００７１】
なお、業務情報システム３００の各サーバ装置３２０は、自装置に対するクライアント端末２００からのアクセス内容を業務情報防護装置１００に通知してもよい。そして、業務情報防護装置１００は、実際のアクセス内容を示すアクセスログとして記録してもよい。このような態様によれば、業務情報防護装置１００は、申請されたアクセス内容と、実際のアクセス内容に齟齬が発生していないかをチェックできる。このため、アクセス許可されたあとも、事後的に不正アクセスが発生していないかをチェックできる。
【００７２】
また、業務情報防護装置１００は、複数のシステムに対するアクセスを一元管理できる。そのため、複数のシステムに対して統一的なアクセスポリシーを適用しやすくなっている。更に、既に運用されている業務情報システム３００に対して、業務情報防護装置１００を追加するだけで実現できるというメリットもある。
【００７３】
以上、本発明を実施例をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００７４】
請求項に記載のアクセス申請受信部の機能は、本実施例においては主としてアクセス申請部１５６により実現される。請求項に記載のユーザ条件設定部とユーザグループ変更部の機能は、本実施例においては主としてユーザグループ変更部１８２により実現される。
このほかにも、請求項に記載の各構成要件が果たすべき機能は、本実施例において示された各機能ブロックの単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。
【図面の簡単な説明】
【００７５】
【図１】業務情報防護装置と業務情報システムとの関係を示すハードウェア構成図である。
【図２】業務情報防護装置の機能ブロック図である。
【図３】実行条件保持部における実行条件情報のデータ構造図である。
【図４】申請画面を示す画面図である。
【図５】承認画面を示す画面図である。
【図６】リモートログインに成功した後、クライアント端末から人事システムにアクセスするときのアクセス画面を示す図である。
【図７】アクセス申請処理の過程を示すシーケンス図である。
【図８】アクセス承認処理の過程を示すシーケンス図である。
【図９】ユーザ認証主導型において、クライアント端末からサーバ装置へのリモートアクセス実行過程を示すシーケンス図である。
【図１０】申請判定主導型において、クライアント端末からサーバ装置へのリモートアクセス実行過程を示すシーケンス図である。
【図１１】ユーザグループ変更処理の過程を示すシーケンス図である。
【符号の説明】
【００７６】
１００ 業務情報防護装置、 １２０ ユーザ認証装置、 １２２ ユーザ認証部、 １２４ 正規ユーザ情報保持部、 １４０ 申請管理装置、 １４２ 申請状態管理部、 １４４ 申請状態判定部、 １４６ アクセスインタフェース処理部、 １５０ 実行条件保持部、 １５２ アクセス予定保持部、 １５６ アクセス申請部、 １５８ アクセス承認部、 １６０ 申請通知部、 １６２ 登録判定部、 １８２ ユーザグループ変更部、 ２００ クライアント端末、 ３００ 業務情報システム、 ３１０ 人事システム、 ３１２ 経理システム、 ３２０ サーバ装置、 ３２２ 承認用端末、 ３２４ フォルダ。
【特許請求の範囲】
【請求項１】
複数のサーバ装置の連携により組織業務を管理するための業務情報システムにおいて、クライアント端末からサーバ装置へのリモートアクセスを制御するための装置であって、
リモートアクセスを実行可能な正規ユーザと複数のユーザグループのいずれかとの対応を示す正規ユーザ情報を保持する正規ユーザ情報保持部と、
クライアント端末から、リモートアクセスの実行対象となるサーバ装置とリモートアクセスを実行予定のユーザとを示すアクセス申請情報を受信するアクセス申請受信部と、
受信されたアクセス申請情報に基づいて、サーバ装置ごとのリモートアクセス予定を示すアクセス予定情報を保持するアクセス予定保持部と、
前記アクセス予定情報を参照して、リモートアクセスの実行対象となるサーバ装置についてあらかじめ設定されている所定のユーザグループにリモートアクセスを実行予定のユーザを一時的に登録するユーザグループ変更部と、
クライアント端末からのいずれかのサーバ装置に対するリモートアクセスに際して、ユーザを特定するためのユーザ識別情報とリモートアクセス対象となるサーバ装置を特定するサーバ識別情報を取得するアクセス要求取得部と、
前記ユーザ識別情報と前記正規ユーザ情報を参照して、リモートアクセスを要求するユーザが、正規ユーザとして登録されているかを判定するユーザ認証部と、
リモートアクセスを要求するユーザがサーバ装置について設定されているユーザグループに所属しているかをサーバ装置側において判定するために、前記ユーザ識別情報と前記正規ユーザ情報を参照して、リモートアクセスを要求するユーザが属しているユーザグループをサーバ装置に通知するユーザグループ通知部と、
を備えることを特徴とする業務情報防護装置。
【請求項２】
正規ユーザの属するユーザグループを変更するための条件を示すグループ変更条件の設定入力を受け付けるユーザ条件設定部と、
前記グループ変更条件が成立するときに、その対象となる正規ユーザの所属するユーザグループを変更するユーザグループ変更部と、
を備えることを特徴とする請求項１に記載の業務情報防護装置。
【請求項１】
複数のサーバ装置の連携により組織業務を管理するための業務情報システムにおいて、クライアント端末からサーバ装置へのリモートアクセスを制御するための装置であって、
リモートアクセスを実行可能な正規ユーザと複数のユーザグループのいずれかとの対応を示す正規ユーザ情報を保持する正規ユーザ情報保持部と、
クライアント端末から、リモートアクセスの実行対象となるサーバ装置とリモートアクセスを実行予定のユーザとを示すアクセス申請情報を受信するアクセス申請受信部と、
受信されたアクセス申請情報に基づいて、サーバ装置ごとのリモートアクセス予定を示すアクセス予定情報を保持するアクセス予定保持部と、
前記アクセス予定情報を参照して、リモートアクセスの実行対象となるサーバ装置についてあらかじめ設定されている所定のユーザグループにリモートアクセスを実行予定のユーザを一時的に登録するユーザグループ変更部と、
クライアント端末からのいずれかのサーバ装置に対するリモートアクセスに際して、ユーザを特定するためのユーザ識別情報とリモートアクセス対象となるサーバ装置を特定するサーバ識別情報を取得するアクセス要求取得部と、
前記ユーザ識別情報と前記正規ユーザ情報を参照して、リモートアクセスを要求するユーザが、正規ユーザとして登録されているかを判定するユーザ認証部と、
リモートアクセスを要求するユーザがサーバ装置について設定されているユーザグループに所属しているかをサーバ装置側において判定するために、前記ユーザ識別情報と前記正規ユーザ情報を参照して、リモートアクセスを要求するユーザが属しているユーザグループをサーバ装置に通知するユーザグループ通知部と、
を備えることを特徴とする業務情報防護装置。
【請求項２】
正規ユーザの属するユーザグループを変更するための条件を示すグループ変更条件の設定入力を受け付けるユーザ条件設定部と、
前記グループ変更条件が成立するときに、その対象となる正規ユーザの所属するユーザグループを変更するユーザグループ変更部と、
を備えることを特徴とする請求項１に記載の業務情報防護装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２００８−２２６０５８（Ｐ２００８−２２６０５８Ａ）
【公開日】平成２０年９月２５日（２００８．９．２５）
【国際特許分類】
【出願番号】特願２００７−６５８２６（Ｐ２００７−６５８２６）
【出願日】平成１９年３月１４日（２００７．３．１４）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
【公開日】平成２０年９月２５日（２００８．９．２５）
【国際特許分類】
【出願日】平成１９年３月１４日（２００７．３．１４）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
[ Back to top ]