(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0017】
[業務情報システムの構成]
図1は、本実施形態に係る業務情報システムの構成例を示すブロック図である。同図に示す業務情報システムは、業務情報防護装置10と作業用端末20がネットワーク30を介して接続されているとともに、クライアント環境40が、業務情報防護装置10を介してネットワーク30に接続されている。また業務情報防護装置10には、ログ管理装置15も接続されている。
【0018】
図1に示す業務情報システムにおいて、クライアント環境40は、ある企業Aの業務環境を示す。クライアント環境40の各種業務システムは、稼働後も、適宜メンテナンス作業を受ける。このメンテナンス作業は、クライアント環境40内で行われることもあるが、多くは作業用端末20からのリモートアクセスにより実行される。このリモートのメンテナンス作業を行うユーザのことを、以下、単に「作業者」とよぶ。作業者は、通常、企業Aとメンテナンス作業契約を交わした管理会社のSE(Systems Engineer)であることが多い。作業者は、作業用端末20を操作して、ネットワーク30および業務情報防護装置10を介して、クライアント環境40の各種業務情報システムにリモートログインする。作業用端末20と業務情報防護装置10の間の通信経路は、VPN(Virtual Private Network)などによりセキュアな通信経路であることが望ましい。
【0019】
以下において、ネットワーク30は、インターネットやローカルエリアネットワーク(LAN)等の公用回線を介したリモートアクセスを前提として説明するが、業務情報防護装置10やクライアント環境40、作業用端末20は、互いに専用回線にて接続されてもよい。
【0020】
また、本明細書においては、各種の業務情報システムの運用により組織業務を実行する側の企業であって、外部の作業用端末20からメンテナンス作業というサービスを受けるクライアントという意味で「クライアント企業」や「クライアント環境40」という用語を使用するものとする。
【0021】
業務情報防護装置10は、作業用端末20からクライアント環境40へのリモートログイン要求を一元的に受け付ける装置であって、ネットワークセキュリティ境界に設置される。業務公報防護装置10は、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)などの通信プロトコルのアクセス制御、およびログ取得による監査を行う(その詳細は後述する)。
【0022】
業務情報防護装置10は、以下の2段階の判定が共に肯定判定となったことを条件として、作業用端末20からのリモートログインを許可する。
1.作業者があらかじめ登録されているユーザであるか(以下、「ユーザ認証」とよぶ)
2.作業者がメンテナンス作業を実行することを事前に(正しく)申請済みであるか(以下、「申請判定」とよぶ)
【0023】
業務情報防護装置10は、中継装置11、ユーザ認証装置12、申請管理装置13、およびアクセス権管理装置14を含む。業務情報防護装置10は、中継装置11、ユーザ認証装置12、申請管理装置13、およびアクセス権管理装置14の各機能を一体として備える単一の装置であってもよいが、本実施の形態においては、以下の理由から、これら3つの装置の集合体であるとして説明する。
【0024】
一般的には、操作者は自端末からターミナルサーバにリモートログインし、このターミナルサーバによってユーザ認証されることを条件として、業務情報システムへのアクセスが許可されるというシステム構成となることが多い。本実施の形態においては、このようなシステム(従来のシステム)に加えて、ユーザ認証装置12、申請管理装置13、およびアクセス権管理装置14を導入することによって、申請判定による情報セキュリティの向上を図っている。すなわち、
図1に示す中継装置11は、既存のターミナルサーバであってもよく、以下、WINDOWS(登録商標)を搭載した一般的なPC(Personal Computer)端末であるとして説明する。
【0025】
中継装置11は、作業用端末20よりネットワーク30を介してアクセスされると、当該作業用端末20のIPアドレスやホスト名などを確認し、接続許可対象外であった場合には、直ちに切断し、接続を許可しない。一方、接続許可対象であった場合には、中継装置11は、作業用端末20にユーザIDとパスワードを要求し、その要求に応じて送信されてきたユーザIDとパスワードを、ユーザ認証装置12、申請管理装置13、およびアクセス権管理装置14に供給し、確認を依頼する。
【0026】
ユーザ認証装置12は、中継装置11に代わって「ユーザ認証」を実行する。まず、作業用端末20のユーザは、従来と同じように中継装置11にリモートログインする。このときユーザIDとパスワードがネットワーク30を介して中継装置11に送信される。ユーザ認証装置12は、中継装置11からユーザIDとパスワードを受け取ってユーザ認証を実行し、その結果を中継装置11に返す。
【0027】
申請管理装置13は、中継装置11からユーザIDとパスワードを受け取って「申請判定」を実行する。作業者は、業務情報システムへのリモートログインに先立って、どのような作業をいつ実行する予定であるかをあらかじめ申請しなければならない。申請管理装置13は、このような作業予定を一元的に管理しており、作業者からのリモートログイン要求を受け付けると、その作業者がなんらかのメンテナンス作業を事前に申請しているか否かを確認する。業務情報システムへのアクセスが許可される条件は、ユーザ認証に成功し、かつ、作業申請済みであることである。
【0028】
アクセス権管理装置14は、中継装置11に代わって「アクセス権認証」を実行する。つまり、アクセス権管理装置14は、中継装置11からユーザIDとパスワード、およびアクセス先を示す情報(IPアドレスやホスト名など)を受け取って、当該ユーザがアクセス先へ接続を許可されているか(アクセス権があるか)否かの認証を実行し、その結果を中継装置11に返す。
【0029】
中継装置11、ユーザ認証装置12、申請管理装置13、およびアクセス権管理装置14は、それぞれ正系と副系の2台のサーバからなり、フェールオーバー機能を有している。すなわち、何らかの理由で正系のサーバに障害が発生した場合、副系のサーバに正系のサーバのIPアドレスが付加されるように構成されている。具体的には、正系のサーバと副系のサーバには、それぞれ実IPとバーチャルIPを所有しており、副系のサーバが正系のサーバを監視し、異常を検知したときに、正系のバーチャルIPを取得する。作業者は、バーチャルIPに対してアクセスするようになされており、異常発生時には、正系から副系のサーバへのアクセスに自動的に切り替わる。これにより、作業者は、正系のサーバに障害が発生したことを意識することなく、副系のサーバを利用してサービスを継続することができる。
【0030】
本実施の形態の業務情報防護装置10の主たるメリットとして、以下の5つを挙げることができる。
1.ユーザ認証に加えて申請判定を行うため、業務情報システムの情報セキュリティが強化される。
2.既に運用されている業務情報システムへの導入が容易である。
3.申請判定に関連するユーザの負荷が軽減される。
4.複数種類の業務情報システムを単一の業務情報防護装置10によって一元管理できる。
5.申請内容とアクセスログを紐付けるため、アクセスチェックが容易である。
【0031】
ログ管理装置15は、中継装置11で行われるアクセスの内容を取得し、管理する。例えば、アクセス日時やIPアドレスといった「サマリーログ」や送受信されたデータの「全文ログ」が取得され、管理される。
【0032】
ログ管理装置15は、申請管理装置13で管理される作業申請内容とログ管理装置15で管理されるアクセスログを紐付けて管理しており、アクセスチェックを容易に行うことができる。アクセスチェックとは、アクセスログを捜査し、申請された通りのアクセスを行っているか否かのログ監査を行うことである。
【0033】
作業用端末20は、作業者によって、クライアント環境40へリモートログインするためのユーザIDとパスワードが入力されると、そのユーザIDとパスワードをリモートログイン要求として、ネットワーク30を介して業務情報防護装置10に送信する。
【0034】
クライアント環境40は、財務情報システム41、顧客情報システム42、在庫管理システム43という3種類の業務情報システムと、1以上の承認用端末44を含む。財務情報システム41は、企業Aの財務情報を管理するシステムである。顧客情報システム42は、企業Aの顧客情報を管理するシステムである。在庫管理システム43は、企業Aの商品の在庫状態を管理するシステムである。承認用端末44は、ウェブブラウザを搭載した一般的なPC端末である。承認用端末44は、必ずしもクライアント環境40に属する必要はなく、ノートPCなどの携帯端末であってもよい。
【0035】
図2は、業務情報防護装置10およびログ管理装置15の機能構成例を示すブロック図である。
【0036】
図2に示す各ブロックは、ハードウェア的には、コンピュータのCPUをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを示している。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現することができる。
【0037】
A:中継装置11
中継装置11のログインインタフェース処理部111は、作業用端末20からのリモートログイン要求を受け付ける。このリモートログイン要求には、ユーザIDとパスワードが含まれる。中継装置11は、受け付けたユーザIDとパスワードを、ユーザ認証装置12によるユーザ認証処理、申請管理装置13による申請判定処理、アクセス権管理装置14によるアクセス権認証処理のために転送する。またログインインタフェース処理部111は、作業用端末20からアクセス先を示す情報(IPアドレスやホスト名など)を取得したとき、取得した情報をアクセス権管理装置14によるアクセス権認証処理のために転送する。そしてログインインタフェース処理部111は、ユーザ認証装置12、申請管理装置13、およびアクセス権管理装置14から、それぞれの判定結果を受け取る。以下、ユーザIDやパスワードのように、ユーザを識別するためのデータのことを「ユーザ識別情報」とよぶ。変形例として、ユーザ識別情報は、指紋や虹彩などの生体情報であってもよい。
【0038】
中継装置11は、単一の装置でなくてもよい。たとえば、財務情報システム41用の中継装置11と、顧客情報システム42用の中継装置11は別々であってもよい。あるいは、作業者は、複数の中継装置11のうち任意の中継装置11を介して目的とする業務情報システムにアクセスしてもよい。中継装置11を複数設けることは、負荷分散や可用性の面からも好ましい。同様に、ユーザ認証装置12、申請管理装置13、およびアクセス権管理装置14も、負荷分散や可用性の面から複数設けるようにしてもよい。
【0039】
B:ユーザ認証装置12
ユーザ認証装置12は、ユーザ認証部121と正規ユーザ情報保持部122を含む。ユーザ認証部121は、中継装置11のログインインタフェース処理部111がリモートログイン要求を受け付けたとき、ログインインタフェース処理部111からそのユーザIDとパスワードを取得する。そして、その送信元のユーザが正規のユーザとして正規ユーザ情報保持部122に登録されているかを判定することによりユーザ認証を行う。正規ユーザ情報保持部122は、ユーザIDとパスワードを対応づけた正規ユーザ情報を保持する。この正規ユーザ情報に登録されているユーザのことを「正規ユーザ」とよぶ。ユーザ認証部121は、作業者だけでなく承認者についてもユーザ認証を実行するが、詳細は後述する。なお、ユーザ情報保持部122は、ユーザ認証装置12の内部に実装されているが、これに限らず、たとえば、LDAP(Lightweight Directory Access Protocol)サーバなどの外部装置であってもよい。
【0040】
業務情報システムに対するメンテナンス作業の中には、リリース作業のように業務情報システムに対する影響が特に大きい作業もある。このようなタイプのメンテナンス作業を実行するためには、通常のユーザ権限によるアクセスではなく、アドミニストレータ並のユーザ権限によりアクセスを行う必要がある。しかし、業務情報システムの情報セキュリティ向上という面から見ると、このような特別なユーザ権限(以下、単に「特別権限」とよぶ)を安易に付与することは好ましくない。詳しい仕組みは後述するが、業務情報防護装置10は、この特別権限を取得できる状態にあるユーザ(以下、「昇格可能ユーザ」とよぶ)を厳密に管理することができる。正規ユーザ情報保持部122は、正規ユーザ情報に加えて、昇格可能ユーザを示す昇格ユーザ情報も保持している。昇格ユーザ情報に登録され、昇格可能ユーザとなることを「昇格」、昇格ユーザ情報から抹消され、昇格可能ユーザでなくなることを「降格」とよぶ。
【0041】
本実施の形態におけるユーザ認証装置12は単一の装置であり、ユーザ識別情報を一元的に管理する。複数の業務情報システムと複数の関係者をつなぐユーザ認証を単一のユーザ認証装置12にて実行することにより、ユーザ認証ポリシー(policy)を管理しやすい構成となっている。
【0042】
C:申請管理装置13
申請管理装置13は、申請状態管理部131、申請状態判定部132、アクセスインタフェース処理部133、実行条件保持部135、作業予定保持部136、および昇格処理部138を含む。
【0043】
作業者は、業務情報システムにアクセスするためには、メンテナンス作業の実行をあらかじめ申請しなければならない。申請状態管理部131は、この作業の申請に関する処理を担当する。申請状態管理部131は、作業申請部131A、登録判定部131B、申請通知部131C、および作業承認部131Dを含む。
【0044】
作業者は、作業を開始する前に、作業用端末20を介して申請管理装置13に作業申請情報を送信する。作業申請情報とは、作業目的、作業日時、件名、アクセス対象となるシステム名などの入力データの集合であるが、このほかにも、申請者のメールアドレス、申請日時や申請者のIPアドレスなど、入力されたデータ以外の付帯情報が含まれてもよい。なお、作業申請情報は、作業用端末20から送信されるが、これに限らず、たとえば、作業用端末20とは異なる申請用端末(図示せず)から送信されるようにしてもよい。
【0045】
作業申請部131Aは、作業用端末20から作業申請情報を受信する。
【0046】
登録判定部131Bは、作業申請部131Aで受信された作業申請情報が、実行条件保持部135に登録されている実行条件情報(
図3を参照して後述する)と適合しているかを判定する。登録判定部131Bは、作業申請情報が実行条件情報と適合していないと判定した場合、申請を却下し、その旨を作業用端末20の作業者に通知する。登録判定部131Bは、作業申請情報が実行条件情報と適合していると判定した場合、作業予定保持部136の作業予定情報に、申請された作業を登録する。こうして作業予定情報に登録された作業申請のことを「有効な作業申請」とよぶ。作業予定情報の内容は、作業申請情報の内容と実質的に同等であってもよい。すなわち、受信された作業申請情報のうち、有効な作業申請としての要件を満たす作業申請情報だけが「作業予定情報」として作業予定保持部136に正式登録されることになる。
【0047】
登録判定部131Bは、有効な作業申請がなされると、作業を一意に識別するための申請ナンバー(作業ID)を付与する。作業予定情報では、申請ナンバー、作業予定日時、作業内容、作業者名、承認状態等が対応づけられる。
【0048】
有効な作業申請さえ行えば作業開始可能なタイプのメンテナンス作業だけでなく、承認がなされなければ作業開始できないタイプのメンテナンス作業もある。実行条件情報の一部として、このような定義がなされていてもよい。
【0049】
なお、作業予定保持部136に登録されている作業予定情報のうち、作業予定日時を経過した作業については、過去に出された申請履歴の状態になり、却下された申請については、申請状態が「却下」として記録された状態になる。
【0050】
申請通知部131Cは、有効な作業申請が作業予定保持部136に登録されると、その申請された作業内容が承認を必要とするものであるか否かを、実行条件保持部135に登録されている実行条件情報を参照して判定する。申請通知部131Cは、メンテナンス作業が申請された場合、その申請ナンバーを承認者に通知する。本実施の形態における申請通知部131Cは、申請ナンバーを示す電子メールを承認用端末44に送信する。承認者は、通知を受けると、承認用端末44の図示せぬ入力部を操作し、申請ナンバーに基づいて業務情報防護装置10の申請管理装置13にアクセスし、承認可否を入力する。
【0051】
作業承認部131Dは、承認可否を承認用端末44から受け付ける。作業承認部131Dは、承認がなされると、作業予定保持部136に登録されている作業予定情報における承認状態を「未承認」から「承認」に変更する。却下の場合には、作業承認部131Dは、作業者に申請却下の旨を通知すると共に、作業予定保持部136に登録されている作業予定情報の申請状態を「却下」として記録する。
【0052】
申請状態判定部132は、申請判定を実行する。作業者からリモートログイン要求が受け付けられたとき、ログインインタフェース処理部111から取得したユーザ識別情報と作業予定保持部136に登録されている作業予定情報を参照して、作業申請済か否かを判定する。また、申請状態判定部132は、リモートログイン要求の受信日時が、申請された作業時間内にあるか否かについても判定する。
【0053】
たとえば、「10:00〜11:00」という作業予定時間を指定して申請されているときには、10:00以前や11:00以後にリモートログイン要求をしてきても申請判定の結果は「否定」となり、リモートログインは許可されない。
【0054】
アクセスインタフェース処理部133は、ユーザ認証と申請判定が共に肯定判定となると、作業用端末20からクライアント環境40へアクセスするための通信経路を許可する。もちろん、承認が必要なメンテナンス作業が申請されているときには、承認済みでなければアクセス許可されない。
【0055】
実行条件保持部135は、メンテナンス作業についてのアクセスルールを実行条件情報として保持する。メンテナンス作業は、障害対応、調査、稼働監視、リリース作業・・・のようにその目的はさまざまである。メンテナンス作業は、このように複数の種別(以下、単に「作業種別」とよぶ)に分類される。たとえば、業務情報システムへのモジュール追加といったリリース作業は、営業時間外にのみ許可したい場合がある。このような場合、業務情報システムの管理責任者は、リリース作業は営業時間外にのみ実行可能となるように実行条件を設定する。実行条件保持部135のデータ構造については、
図3を参照して後述する。
【0056】
作業予定保持部136は、申請状態管理部131の登録判定部131Bにより正式登録された、有効な作業申請としての要件を満たす作業予定情報を保持する。
【0057】
昇格処理部138は、所定の時間毎に、作業予定保持部136から作業予定情報を読み出し、昇格させるべきユーザが存在するか、降格させるべきユーザが存在するかを判定する。
【0058】
本実施の形態における申請管理装置13は単一の装置であり、申請判定を一元的に実行する。複数の業務情報システムに関する申請判定を単一の申請管理装置13にて実行することにより、実行条件や作業予定情報を管理しやすい構成となっている。
【0059】
図3は、実行条件保持部135における実行条件情報のデータ構造の例を示す図である。
【0060】
実行条件情報は、各業務情報システムの管理責任者により定められたアクセスルールである。ルールID欄135Aは、アクセスルールを一意に識別するためのID(以下、「ルールID」とよぶ)を示す。アクセスルールが登録されるときに、ルールIDが割り当てられる。年月日欄135Bは、アクセスルールの適用日を示す。時間欄135Cは、アクセスルールの適用時間を示す。たとえば、ルールID「1」のアクセスルールが適用されるのは、企業Aの営業日であって「6:00〜16:00」の時間帯である。作業種別欄135Dは、アクセスルールが適用されるメンテナンス作業の作業種別を示す。承認要否欄135Eは、該当作業の実行をするために承認が必要か否かを示す。
【0061】
図3の例では、たとえば、ルールID「1」のアクセスルールが適用されるのは、「営業日」の「6:00〜16:00」における作業種別「01」の「障害対応」を目的としたメンテナンス作業と、作業種別「02」の「調査」を目的としたメンテナンス作業であり、これらについては承認不要である。すなわち、営業日の「6:00〜16:00」中を作業予定日時として障害対応を目的としたメンテナンス作業を行う場合には、作業者はあらかじめその旨を示す作業申請行うだけでよく、承認は不要である。またルールID「2」のアクセスルールが適用されるのは、「営業日」の「6:00〜16:00」における作業種別「03」の「稼働監視」を目的としたメンテナンス作業と、作業種別「04」の「リリース作業」を目的としたメンテナンス作業であり、これらについては承認が必要である。すなわち、営業日の「6:00〜16:00」において、「稼働監視」や「リリース作業」を目的とするメンテナンス作業を実行する場合には、作業申請だけでなく承認がなされていなければアクセスできない。
【0062】
たとえば、作業者Aが、営業日の「6:00〜16:00」中の日時Tにリモートアクセス要求をしてきたとする。このとき、
図3の例で示す実行条件情報に基づく申請判定の結果は以下の通りである。
1.日時Tを作業予定時間として含むような作業の申請がなされていない場合、否定判定となる。
2.日時Tを作業予定時間として含む障害対応作業が申請されていた場合、肯定判定となる。
3.日時Tを作業予定時間として含む稼働監視作業が申請されていた場合、申請状態判定部132は、作業予定保持部136を参照し、申請された稼働監視作業が承認済みであれば肯定判定する。未承認や却下の場合には、否定判定となる。
【0063】
なお、登録判定部131Bは、同一作業者が同一日時に別々の作業を申請した場合には、そのような申請を自動的に却下する。そのため、作業者は、日時Tを対象として障害対応作業と稼働監視作業の両方を申請するということはできない。
【0064】
実行条件保持部135は、業務情報システムごとに別々の実行条件情報を保持してもよいが、本実施の形態においては、財務情報システム41、顧客情報システム42、在庫管理システム43に対して共通のアクセスルールを定義した統合的な実行条件情報であるとする。また、本実施の形態においては、作業種別「04」の「リリース作業」を実行するには特別権限が必要であるが、それ以外の作業には特別権限は不要であるとして説明する。
【0065】
D:アクセス権管理装置14
アクセス権管理装置14は、アクセス権認証部141とアクセス権情報保持部142を含む。アクセス権認証部141は、中継装置11のログインインタフェース処理部111がリモートログイン要求を受け付けたとき、ログインインタフェース処理部111からユーザIDとパスワード、およびアクセス先を示す情報(IPアドレスやホスト名など)を取得し、その送信元のユーザがアクセス先に接続を許可されているか(アクセス権があるか)否かを、アクセス権情報保持部142に登録されているアクセス申請状況をもとに判定する。アクセス権情報保持部142は、ユーザIDおよびアクセス先を示す情報に対応づけたアクセス申請状況を保持する。
【0066】
E:ログ管理装置15
ログ管理部151は、作業用端末20からクライアント環境40へのアクセスログを管理する。ログ管理部151は、ログ記録部151Aと作業検証部151Bを含む。ログ記録部151Aは、リモートログイン要求の実行、作業用端末20と業務情報システムの間で送受されるコマンドやデータ、その実行日時をアクセスログとして記録する。記録時、ログ記録部151Aは、申請状態管理部131の登録判定部131Bで付与された申請ナンバーと、その申請ナンバーに対応する作業申請内容のアクセスログを結びつける。またログ記録部151Aは、認証失敗や未申請、アクセス権無し等の拒否履歴のログも記録する。
【0067】
作業検証部151Bは、ログ保持部152で保持されているアクセスログの内容と、そのアクセスログに紐付けられた申請ナンバーに対応する、作業予定保持部136に登録されている作業予定情報とを比較して、不正アクセスがなされていないかをチェックする。
【0068】
たとえば、「稼働監視」を目的とした作業申請がなされているときに、ファイルの書き換え処理の実行がなされたときには、作業検証部151Bは、ログ保持部152で保持されているアクセスログを参照して、このような不正アクセスを検出する。作業検証部151Bは、承認用端末44に対して、不正アクセス、あるいは、不正アクセスの疑いのあるアクセスがあった旨を通知する。あるいは、不正アクセスが検出された時点で、アクセスインタフェース処理部133はリモートアクセスを強制的に禁止してもよい。
【0069】
ログ保持部152は、申請状態管理部131の登録判定部131Bで付与された申請ナンバーと、その申請ナンバーに対応する作業申請内容のアクセスログを紐付けて保持する。ログ保持部152で保持するアクセスログの記録内容については、
図4を参照して後述する。
【0070】
図4は、ログ保持部152で保持されるアクセスログの記録内容の例を示す図である。
【0071】
ログ保持部152は、サマリーログ記録領域152Aと全文ログ記録領域152Bを含み、サマリーログと全文ログの2種類のログを保持している。サマリーログは、アクセスの開始、終了時刻、利用端末、アクセス先サーバのIPアドレスやホスト名、利用ID、接続時間などを含む。全文ログは、実際にコマンドなどを実行・操作した内容を含む。
【0072】
図4の例の場合、サマリーログ記録領域152Aと全文ログ記録領域152Bには、それぞれプロトコル毎に主な記録内容が保持されている。たとえば、「TELNET」のプロトコルの場合、サマリーログ記録領域152Aには、アクセス開始日時、ポート、接続元IPアドレス、ユーザID、接続先IPアドレス、接続時間が記録され、全文ログ記録領域152Bには、受信データが記録される。
【0073】
以上示したアクセスログの記録内容が、申請ナンバーに紐付けてログ保持部152で保持される。なお、WindowsRDPで取得されるアクセスログは動画形式で記録される。
【0074】
図5は、ログイン画面の表示例を示す図である。
【0075】
図5に示すログイン画面50は、作業用端末20から中継装置11にリモートログイン要求するときに、作業用端末20に表示される。中継装置11は、リモートログイン要求を受け付けると、ログインウィンドウ51を作業用端末20のログイン画面50内に表示させる。すなわち、中継装置11のログインインタフェース処理部111が、作業用端末20のユーザインタフェース画面を提供することになる。作業用端末20のユーザは、ログイン画面50内に表示されたログインウィンドウ51上でユーザIDやパスワードを入力する。ユーザからみたユーザインタフェースは従来のターミナルサーバが提供するものと同じであるが、入力されたユーザ識別情報はユーザ認証装置12、申請管理装置13、およびアクセス権管理装置14によってそれぞれユーザ認証、申請判定、アクセス権認証に供給される。
【0076】
図6は、アクセス申請画面の表示例を示す図である。
【0077】
図6に示すアクセス申請画面60は、作業者が作業申請のために、作業用端末20から申請管理装置13にアクセスするときに作業用端末20に表示される。すなわち、申請状態管理部131の作業申請部131Aは、作業用端末20からアクセスされると、作業用端末20にアクセス申請画面60をウェブページとして表示させる。
【0078】
申請者名領域61には、作業を申請するユーザ名を入力する。申請者は、自分以外が作業をするときには、実際に作業を実行する予定のユーザ名を入力する。件名領域62には、申請する作業の件名を入力する。システム分類領域63からは、対象とする業務情報システムのタイプが選択される。ここでは、財務情報システム64が選択されている。アクセスインタフェース処理部133は、申請日時において、選択された業務情報システム以外への当該ユーザのアクセスを禁止するように制御してもよい。
【0079】
システム名領域64は、業務情報システムの名前を示し、作業種別領域65は、作業種別を示す。内容入力領域66は、作業内容などを自由記述するための領域である。添付ファイル領域67は、利用する手順書等の電子ファイルを添付するための領域である。アクセス予定日時領域68は、作業予定日時を示す。作業者は、申請画面60に示される各項目にデータを入力した後、申請ボタン69をクリックする。すると、作業用端末20は、入力されたデータを作業申請情報として申請管理装置13に送信する。
【0080】
アクセス申請時に、申請者名、件名、システム分類、システム名、作業種別、内容、およびアクセス予定日時の他、実際に利用する手順書等が記載された電子ファイルを添付することにより、作業申請情報とともに付随する電子ファイルを一元管理することが可能となる。
【0081】
図7は、アクセス承認画面の表示例を示す図である。
【0082】
図7に示すアクセス承認画面70は、承認が必要な作業申請がなされた場合、承認用端末44に表示される。すなわち、申請状態管理部131の登録判定部131Bは、承認が必要な作業申請がなされたとき、申請ナンバーを承認用端末44に通知する。承認者が、申請ナンバーを指定して申請管理装置13にアクセスすると、作業承認部131Dは承認用端末44にアクセス承認画面70をウェブページとして表示させる。
【0083】
申請情報領域71は、アクセス申請画面60に入力された申請内容を示す。承認者名領域72は、承認者名を入力するための領域である。承認依頼者名領域73は、承認を依頼したユーザ名を入力するための領域である。たとえば、承認権限のあるユーザBが、ユーザCに承認を依頼したときには、ユーザCはユーザBに代理して承認判断を行う。これは、ユーザBの休暇中など、特殊な状況に対応するための措置である。
【0084】
通信欄74は、作業申請者に対するメッセージを記述する欄であり、申請却下の理由を記述したり、申請承認するときには作業内容に条件や注文をつけるための記述がなされてもよい。承認ボタン75は承認用、却下ボタン76は却下用のボタンである。承認ボタン75から却下ボタン76のいずれかがクリックされると、入力内容と承認可否を示すデータが申請管理装置13に送信される。作業承認部131Dは、このデータを作業用端末20に、たとえば、電子メールにより送信する。
【0085】
「リリース作業」のように、特別権限が必要なメンテナンス作業が申請された場合は、承認可否や実行条件情報に基づいて昇格ユーザ情報の更新が行われる。たとえば、営業日の「6:00〜16:00」中の時間帯を作業予定時間として、リリース作業が申請されたとする。承認がなされると、申請された日時に限り、申請者は昇格する。たとえば、営業日である「2006年9月28日」の「10:00〜11:00」を作業予定日時として、ユーザAがリリース作業を申請したとする。この作業が承認されると、作業予定日時として示される期間だけ、ユーザAは昇格可能ユーザとなる。すなわち、昇格処理部138は、2006年9月28日の10:00に至ると、ユーザAを昇格させ、正規ユーザ情報保持部122の昇格ユーザ情報に登録する。また、9月28日の11:00に至ったり、リリース作業が終了したときには、ユーザAを降格させ、昇格ユーザ情報からユーザAを抹消する。このように、本実施の形態においては、特別権限は時間制限付きの権限となる。
【0086】
ここでいう特別権限とは、いわゆるルート(root)権限やアドミニストレータ(administrator)権限であってもよい。すなわち、昇格可能ユーザとは、自己のユーザIDにてログインをした後、たとえば、UNIX(登録商標)のいわゆる「suコマンド」などによりルート権限を取得可能なユーザであってもよい。
【0087】
また、申請・承認プロセスとは別に、特別権限を付与するか否かを別のアクセスポリシーにて管理してもよい。たとえば、リリース作業が作業者Bにより申請され、承認者Cに作業承認され、更に、別の承認者Dが作業者Bへの特別権限付与を許可したことを条件として、作業者Bの作業を許可してもよい。このように、「特別権限」という重要な権限の管理者を作業承認者と分離することにより、業務情報防護装置10の情報セキュリティをいっそう強化することができる。
【0088】
昇格処理部138は、作業申請にかかわらず、所定条件が成立したときに、所定ユーザを昇格させるとしてもよい。たとえば、ユーザBが災害対応のスペシャリストである場合、昇格処理部138は地震の発生を検出すると、ユーザBを、所定時間を限度として昇格させてもよい。また、このような非常時には、作業申請手続きを省略するというアクセスルールであってもよい。すなわち、業務情報防護装置10が備える震度計が所定値以上の揺れを計測したことを、ユーザDの昇格条件としてもよい。
【0089】
他の例として、業務情報システムにおいてコンピュータウィルスが検知されたことを、所定ユーザの昇格条件としてもよい。あるいは、特別権限を有するユーザCが作業申請の範囲を超えたアクセスをしたときには、ユーザCを降格させるとしてもよい。すなわち、業務情報防護装置10やクライアント環境40において所定の事象が発生したことを昇格・降格条件として、昇格や降格処理を実行してもよい。管理責任者は、昇格処理部138に対して昇格・降格条件を外部から設定することもできる。このため、上記のような緊急時においても、適切なユーザを時間制限付きで速やかに昇格させることができる。
【0090】
図8は、アクセス申請・承認レベル設定画面の表示例を示す図である。
【0091】
図8に示すアクセス申請・承認レベル設定画面80は、管理者が、作業申請情報のアクセス承認レベルを予め設定する場合に、承認用端末44に表示される。管理者は、アクセス申請・承認レベル設定画面80上で事前の申請や承認を必要とするか否かを、サーバ設定でポート毎に設定することができる。
【0092】
プロトコル・ポート番号領域81は、プロトコル毎のポート番号を示す。サービス起動領域82は、アクセスされたときにユーザインタフェースなどの提供サービスを自動起動するか否かを設定するための領域である。全文ログ取得領域83は、作業内容の全文ログを取得するか否かを設定するための領域である。アクセス承認レベル領域84は、事前の申請や承認を必要とするか否かの承認レベルを設定する領域である。
【0093】
アクセス申請・承認レベル設定画面80では、プロトコル・ポート番号毎に承認レベルを設定することができるだけでなく、サマリーログの保存期間、全文ログの保存期間、アクセス申請・画面操作ログ保存期間、およびサーバ状態も設定することができる。これにより、ログ保持部152で保持されている膨大な量のアクセスログのうち、不要になったアクセスログをこまめに削除することができる。
【0094】
図8の例の場合、TELNETの通信プロトコルの23番のポートは、事前申請と承認を必要とするように設定されている。一方、TELNETの通信プロトコルの223番のポートは、アクセスに際し申請も承認も不要な状態に設定されている。このように、通常利用するポートには、「事前申請と承認」を設定したり、緊急時に承認者が不在な場合を想定し、「事前申請」のみを設定したりすることもできる。
【0095】
図9は、アクセスログ検索画面の表示例を示す図である。
【0096】
図9に示すアクセスログ検索画面90は、承認者が、アクセスチェック(ログ監査)を行う場合に、承認用端末44に表示される。承認者は、許可したアクセスの内容が、事前に申請された作業内容通りに行われているか否かを確認するために、アクセスログ検索画面90上で、検索したいアクセスログの検索条件を設定する。検索ボタン91は、設定された検索条件でアクセスログの検索を実行するためのボタンである。検索ボタン91がクリックされると、検索条件を示すデータがログ管理装置15に送信される。ログ管理装置15のログ管理部151(の作業検証部151B)は、検索条件を示すデータに基づいて、ログ保持部152に登録されているアクセスログを抽出するとともに、申請管理装置13の作業予定保持部136に登録されている作業予定情報を抽出する。
【0097】
図10は、検索結果画面の表示例を示す図である。
【0098】
図10に示す検索結果画面100は、アクセスログ検索画面90の検索ボタン91がクリックされた場合に、承認用端末44に表示される。すなわち、承認者によってアクセスログ検索画面90で設定された検索条件を満たすアクセスログが申請管理装置13とログ管理装置15で検索され、その検索結果(アクセスログと作業予定情報)が承認用端末44に送信され、サマリーとして検索結果画面100上に一覧表示される。
【0099】
ファイルアイコン101は、具体的な作業内容をダウンロードするためのボタンである。ファイルアイコン101がクリックされると、具体的な実行コマンドの内容が、テキストファイルとして取得されて表示される。またファイルコマンド102は、申請内容をダウンロードするためのボタンである。ファイルアイコン102がクリックされると、具体的な申請内容が取得されて表示される。すなわち承認者は、アクセスログと申請内容を容易に見比べることができるので、ログ監査を効率よく行うことができる。
【0100】
なお、申請内容に応じて不要だと思われる禁止コマンドなどをキーワードとして予め登録しておくと、そのキーワードが含まれるレコード行数とレコードを抽出することができる。たとえば、アクセス申請時、アクセス分類に「一般ID作業」を申請した場合、一般IDによるアクセスであれば、特権IDを取得するようなコマンドが不要であるだけでなく、ユーザを追加するコマンドは本来発行されないことがわかっている。そこで、「一般ID作業」に対して禁止されている、あるいは不要である、「SU-」(特権IDを取得するためのコマンド)、および「useradd」(ユーザを追加するコマンド)をキーワードとして事前に登録しておく。これにより、申請内容に応じて不要だと思われる禁止コマンドなどを含むアクセスログを抽出し、承認者に提供できるので、不正使用を効率よく見つけ出すことができる。
【0101】
またメール通知の機能を利用すれば、キーワードに合致する操作が行われた場合、管理者へ電子メールを通知することができる。このように、アクセスチェックを行うだけでログ監査を効率良く行うことができる。
【0102】
なおここでは、アクセスログと申請内容を見比べることができるように、検索結果を表示するようにしたが、ログ管理部151の作業検証部151Bが、検索条件を示すデータに基づいて、申請管理装置13の作業予定保持部136に登録されている作業予定情報と、ログ保持部152に登録されているアクセスログとを対比して、前記ログ情報に示されるアクセスの中の、前記作業予定情報で申請されたメンテナンス作業用アクセスに合致しないアクセスを、不正アクセスとして検出することもできる。
【0103】
[作業申請処理について]
ここで、作業用端末20の作業者が行う作業申請処理について説明する。作業者は、まず、作業用端末20に表示される
図5に示すログイン画面50上でユーザIDとパスワードを入力する。作業用端末20は、入力されたユーザ識別情報と共に、中継装置11を経由することなく、直接、申請管理装置13にアクセスする。申請管理装置13は、ユーザ識別情報をユーザ認証装置12に転送する。ユーザ認証装置12のユーザ認証部121は、正規ユーザ情報保持部122の正規ユーザ情報を参照してユーザ認証を行い、認証に失敗した場合、以降の処理は実行されない。
【0104】
認証に成功した場合、ユーザ認証装置12は、認証成功の旨を申請管理装置13に通知する。申請管理装置13の作業申請部131Aは、申請画面用データを作業用端末20に送信する。作業用端末20は、
図6に示すアクセス申請画面60を表示させる。ユーザは、アクセス申請画面60にデータを入力し、入力されたデータが作業申請情報として申請管理装置13に送信される。
【0105】
申請管理装置13の登録判定部131Bは、申請された作業内容と実行条件保持部135の実行条件情報を比較し、登録可否を判定する。有効な作業申請でなければ、登録判定部131Bは申請を却下した上で、作業用端末20に却下通知し、以降の処理は実行されない。一方、有効な作業申請であると判定した場合、登録判定部131Bは、申請されたメンテナンス作業を作業予定保持部136の作業予定情報に登録する。承認が必要な作業であれば、申請通知部131Cは承認を求める旨の電子メールを承認用端末44に送信する。
【0106】
以上の処理により、作業申請情報のうち、有効な作業申請としての要件を満たす作業申請情報だけが「作業予定情報」として作業予定保持部136に正式に登録される。
【0107】
[作業承認処理について]
次に、作業申請処理によって申請された作業内容の承認処理について説明する。承認用端末44は、申請が出された旨の電子メールを受け取ったあと、申請管理装置13にアクセスする。承認者は任意のタイミングにて、
図5に示したログイン画面50上でユーザIDとパスワードを入力する。また、承認者は、ユーザIDとパスワードの入力時、申請ナンバーも指定する。承認用端末44は、入力された承認者のユーザIDとパスワードをユーザ認証装置12に送信する。ユーザ認証装置12のユーザ認証部121は、承認用端末44からユーザIDとパスワードを取得し、正規ユーザ情報保持部122に登録されている正規ユーザ情報を参照して、承認者のユーザ認証を行う。ユーザ認証に失敗した場合、以降の処理は実行されない。
【0108】
認証に成功した場合、申請管理装置13の作業承認部131Dは、承認用端末44から取得した申請ナンバーに基づいて、作業予定保持部136に登録されている作業申請情報を検索する。申請管理装置13の作業承認部131Dは、検索した作業申請情報に基づいて、アクセス承認画面70のためのHTML(HyperText Markup Language)データを承認用端末44に送信する。承認用端末44は、申請ナンバーで指定された作業に関するアクセス承認画面70(
図7)を表示させる。承認者は、アクセス承認画面70を確認し、承認ボタン75または却下ボタン76をクリックすると、入力されたデータが申請管理装置13に送信される。申請管理装置13の作業承認部131Dは、承認可否に応じて作業予定保持部136の作業予定情報を更新する。作業承認部131Dは、作業用端末20に承認可否を通知する。
【0109】
以上の処理により、有効に申請された作業について承認がなされる。なお、承認者が、申請管理装置13にアクセスすると、申請管理装置13は承認待ちの作業申請を一覧表示させ、承認者はその中から承認対象となる作業申請を選択するというユーザインタフェースであってもよい。また、複数の作業申請を一括して承認または却下を行うことも可能である。
【0110】
[リモートログイン処理について]
次に、業務情報システムへのリモートログイン処理について説明する。作業者は、作業用端末20から、まず、中継装置11にアクセスする。中継装置11は、アクセスされた作業用端末20のIPアドレスを確認し、接続を許可するか否かを判断し、許可しない場合には接続を切断する。一方、作業用端末20からの接続を許可する場合には、中継装置11は、作業用端末20に対し、プロトコルに適した形でユーザ識別情報(ユーザIDおよびパスワード)を要求する。作業用端末20は、ログイン画面50(
図5)を表示させ、作業者からユーザIDとパスワードの入力を受け付ける。作業用端末20は、入力されたユーザIDとパスワードを中継装置11に送信する。
【0111】
中継装置11は、作業用端末20から受信したユーザIDとパスワードをユーザ認証装置12、申請管理装置13、およびアクセス権管理装置14に供給する。ユーザ認証装置12のユーザ認証部121は、中継装置11からユーザIDとパスワードを取得し、正規ユーザ情報保持部122に登録されている正規ユーザ情報を参照して、作業者のユーザ認証を行う。ユーザ認証に失敗した場合、以降の処理は実行されない。
【0112】
認証に成功した場合、中継装置11は、作業用端末20にアクセス先の入力を要求する。作業用端末20は、作業者からアクセス先の入力を受け付け、アクセス先を示す情報(IPアドレスやホスト名など)を中継装置11に送信する。中継装置11は、作業用端末20から受信したアクセス先を示す情報をアクセス権管理装置14に供給する。アクセス権管理装置14のアクセス権認証部141は、アクセス先を示す情報に基づいて、アクセス権情報保持部142に登録されているアクセス申請状況を参照し、アクセス先への当該ユーザのアクセス権を確認する。アクセス権認証部141は、不適切なアクセスと判断した場合には、アクセス先への当該ユーザのアクセスを拒否する。一方、適切なアクセスと判断した場合には、アクセス先への当該ユーザのアクセスを許可する。そして全ての判定が肯定となった場合、作業者は、メンテナンス作業の対象となる業務情報システムにアクセス可能となる。
【0113】
以上の処理により、業務情報システムへリモートログインした場合に、不正なアクセスと判断されると、ログインに失敗し、アクセスを禁止することができる。
【0114】
[昇格・降格判定処理について]
次に、昇格処理部138が実行するユーザの昇格・降格処理について説明する。申請管理装置13の昇格処理部138は、作業予定保持部136から作業予定情報を読み出し、昇格させるべきユーザが存在するか判定する。たとえば、営業日である「2006年9月28日」の「10:00〜11:00」を作業予定日時として、ユーザAがリリース作業を申請し、承認されたとする。この場合、2006年9月28日の10:00に至ると、昇格処理部138はユーザAを昇格させる。昇格処理部138は、昇格可能ユーザのユーザ識別情報をユーザ認証装置12に送信し、正規ユーザ情報保持部122の昇格ユーザ情報にユーザAを登録する。
【0115】
また昇格処理部138は、作業予定情報から降格させるべきユーザが存在するか判定する。上述の例の場合、2006年9月28日の11:00に至ると、ユーザAを降格させる。昇格処理部138は、降格すべきユーザのユーザ識別情報をユーザ認証装置12に送信し、正規ユーザ情報保持部122の昇格ユーザ情報からユーザAを抹消する。
【0116】
申請管理装置13は、所定時間毎(たとえば1分毎)に、上述の処理を繰り返し実行することにより、昇格ユーザ情報は定期的に更新される。
【0117】
以上の処理のように、時間制限付きの特別権限により、業務情報システムの情報セキュリティをいっそう向上させることができる。ユーザは、リモートログインした後に、自ら特別権限を明示的に要求してもよいが、どのような条件で昇格を許すかは、昇格処理部138が所定の昇格条件に基づいて判定してもよい。
【0118】
なお、上述した作業申請処理、作業承認処理、業務情報システムへのログイン処理、昇格・降格判定処理の詳細については、特開2008−117361号公報等に記載されている通り公知の技術である。
【0119】
[アクセスチェック処理について]
次に、
図11のフローチャートを参照して、アクセスチェック処理について説明する。承認者は、許可したアクセスの内容が、事前に申請された作業内容通りに行われているか否かを確認するために、承認用端末44の入力部(図示せず)を用いて、アクセスチェック(ログ監査)の実行を指示する。
【0120】
ステップS1において、承認用端末44は、承認者からの指示に基づいて、
図9に示したアクセスログ検索画面90を表示する。承認者は、アクセスログ検索画面90上で、検索したいアクセスログの検索条件を設定する。ステップS2において、承認用端末44は、承認者により設定されたアクセスログの検索条件の入力を受け付ける。そして、検索ボタン91がクリックされると、ステップS3において、承認用端末44は、入力を受け付けたアクセスログの検索条件データをログ管理装置15に送信する。
【0121】
ステップS4において、ログ管理装置15の作業検証部151Bは、承認用端末44から検索条件データを受信すると、申請管理装置13の作業予定保持部136から、検索条件データに含まれる申請ナンバーに対応する作業予定情報を読み出し、ログ保持部152から申請ナンバーに紐付けされているアクセスログを読み出し、両者を突き合わせ、不正アクセスがなされていないかをチェックする。たとえば、上述したように、「稼働監視」を目的とした作業申請がなされているときに、ファイルの書き換え処理の実行がなされたときには、不正アクセスとなる。ステップS5において、作業検証部151Bは、ログ保持部152から検索条件に合致するアクセスログを読み出し、アクセスチェック結果として承認用端末44に通知する。
【0122】
ステップS6において、承認用端末44は、ログ管理装置15から受信したアクセスチェック結果に基づいて、
図10に示した検索結果画面100を表示させる。なお、申請内容に応じて不要だと思われる禁止コマンドをキーワードとして予め登録してある場合、キーワードに合致するアクセスログが検索された場合には、検索されたキーワードに合致するレコード行数とレコードを、管理者へメール通知することができる。
【0123】
[発明の実施の形態における効果]
以上のように、本実施の形態では、ユーザ認証に加えて申請判定を行うため、不正アクセスを防止しやすい構成となっている。ユーザ認証だけの場合、ユーザ識別情報の漏洩は、業務情報システムからの情報漏洩に直結しやすい。しかし、業務情報防護装置10は、更に作業申請手続きを要求するため、ユーザ識別情報の漏洩が不正アクセスに直結しにくい。なぜならば、不正なユーザが、仮にユーザ識別情報を不正に手に入れたとしても、虚偽の作業申請を行ってまで業務情報システムにアクセスするには心理抑制がかかりやすいためである。
【0124】
また、正当な管理会社のSEに対してもクライアント環境40へのアクセスを規制する仕組みが実現されている。上述したように、作業の申請や承認がログとして記録されるため、事後的なアクセスチェックが容易となる。このため、クライアント企業としても、自システムについてのコンプライアンス(compliance)を証明しやすいというメリットがある。このような特徴により、業務情報防護装置10は、SOX方が求める「内部統制の強化」に資することができる。
【0125】
申請された作業内容が実行条件情報に適合しないときには、登録判定部131Bは、不審な申請がなされた旨を承認用端末44に通知したり、当該ユーザ識別情報を一時的に無効化してもよい。登録判定部131Bのこのような作業申請チェックにより、不正な作業申請を自動的に却下できる。更に、申請だけでなく承認が必要なメンテナンス作業を定義することもできるため、情報セキュリティをいっそう向上させることができる。
【0126】
特別権限が必要なメンテナンス作業を実行するときにも、特別権限に時間制限を設けることで、業務情報防護装置10は、どのユーザにどのようなタイミングで特別権限を与えるかを一元管理できる。
【0127】
通常、メンテナンス作業は、あらかじめ実行スケジュールが確定していることが多い。本実施の形態によれば、事前の作業申請と任意のタイミングでの承認という運用により、作業者および承認者に過度の心理的負担をかけないかたちで業務情報システムのセキュリティ管理を実現できる。
【0128】
業務情報防護装置10は、アクセスログを記録することもできる。また、ログ管理部151は、作業申請された内容と、実際の作業の内容に齟齬が発生していないかをチェックすることができる。このため、アクセス許可されたあとも、事後的に不正アクセスが発生していないかを容易にチェックできる。
【0129】
このように、業務情報防護装置10は、
1.ユーザ認証
2.実行条件と申請された作業内容の適合性の判定
3.リモートログイン要求時における申請判定
4.リモートログイン要求日時と申請された作業予定日時の比較
5.特別権限に関する判定
6.アクセスログに基づく不正アクセス検出
という複数の観点から業務情報システムを防御している。
【0130】
また、業務情報防護装置10は、複数の業務情報システムに対するアクセスを一元管理できる。そのため、複数の業務情報システムに対して統一的なアクセスポリシーを適用しやすくなっている。更に、既に運用されている業務情報システムに対して、業務情報防護装置10を追加するだけで実現できるというメリットもある。
【0131】
以上においては、「メンテナンス作業」を例に挙げ説明したが、本発明は、これに限らず、たとえば、社員が外出先からアクセスする場合にも適用することが可能である。
【0132】
上述した一連の処理は、ハードウエアにより実行することもできるし、ソフトウエアにより実行することもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、専用のハードウエアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、プログラム記録媒体からインストールされる。
【0133】
この発明は、上記実施の形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化したり、上記実施の形態に開示されている複数の構成要素を適宜組み合わせたりすることにより種々の発明を形成できる。例えば、実施の形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施の形態に亘る構成要素を適宜組み合わせても良い。