(57)【要約】【課題】中継装置を介してのアクセスに対して、開示可能なリソースを適切に制御することができ、セキュリティを向上することのできる技術を提供する。【解決手段】管理サーバ１７００において、ＣＰＵ１７０４が、リソースに対する利用要求を受信する通知処理モジュール５０００と、利用要求を受信した際に、ユーザ端末１８００によってリソース（サーバ１２００、１３００、１４００等）を利用する場面に関わる状況情報を取得する状況情報収集モジュール５００１と、状況情報に基づいて、リソース中の利用許可可能なリソースを決定するポリシー照合モジュール５００２と、利用許可可能なリソースへのブレードＰＣ１６００を介してのアクセスが可能となるようにスイッチ１５００によるフィルタリングを制御するフィルタリング制御モジュール５００３とを実行するように構成する。【選択図】図２
2008160803.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して接続される、ユーザ端末と、中継装置と、管理サーバとを備え
るアクセス制御システムにおいて、
前記管理サーバは、
前記ユーザ端末の位置に関する位置情報、及び前記ユーザ端末のユーザに関するユーザ情報と、前記中継装置が前記ユーザ端末にアクセスする場合に、該ユーザ端末からアクセスを許可する前記中継装置の備える記憶装置の範囲を関連付けた情報であるフィルタリングポリシーを有する記憶装置と、
前記ユーザ端末から前記中継装置へのアクセス要求を受信する通知処理部と、前記アクセス要求を受信した後、前記アクセス要求から前記ユーザ端末の識別子、及び前記位置情報と前記アクセス要求の対象である中継装置から前記ユーザ情報を取得する状況情報収集部と、前記取得したユーザ端末の識別子、位置情報、及びユーザ情報と、前記フィルタリングポリシーを照合するポリシー照合部と、前記照合の結果定まる範囲に対してのみ前記ユーザ端末が前記中継装置にアクセスできるように前記中継装置の有するファイアウォールを制御するフィルタリング制御部とを有するアクセス制御部と
を備えることを特徴とするアクセス制御システム。
【請求項２】
請求項1記載のアクセス制御システムにおいて、
前記管理サーバは、さらに、
前記中継装置の記憶装置の状態を監視する資産管理部と、
前記資産管理部から、前記中継装置の記憶装置が追加、変更、又は削除された場合にされる通知を受信し、前記追加、変更、又は削除に応じて前記フィルタリングポリシーを更新するメンテナンス部を有することを特徴とするアクセス制御部。
【請求項３】
請求項2記載のアクセス制御システムにおいて、
前記位置情報は、前記ユーザのプレゼンス情報を含み、
前記ユーザ情報は、前記ユーザ端末のユーザに関するスケジュール情報、出張目的、出張先、及びアクセス目的を含むことを特徴とするアクセス制御システム。
【請求項４】
請求項3記載のアクセス制御システムにおいて、
前記プレゼンス情報は、さらに、前記ユーザがユーザ端末を利用する拠点に関する情報を含み、
前記ユーザ端末は、前記ユーザがユーザ端末を利用する場合、該利用する拠点の入退室管理を行う入退室管理サーバから、前記拠点に関する情報を取得することを特徴とするアクセス制御システム。
【請求項５】
請求項3記載のアクセス制御システムにおいて、
前記プレゼンス情報は、さらに、前記ユーザがユーザ端末を利用する拠点に関する情報を含み、
前記ユーザ端末は、自身が有するGPSから、該ユーザ端末の利用する拠点に関する情報を取得することを特徴とするアクセス制御システム。
【請求項６】
請求項4記載のアクセス制御システムにおいて、
前記ユーザ情報は、さらに、前記ユーザ端末のユーザにおける職制、及び業務に関する情報を含むことを特徴とするアクセス制御システム。
【請求項７】
請求項6記載のアクセス制御システムにおいて、
前記フィルタリング制御部は、
前記通知処理部が前記ユーザ端末から前記中継装置へのアクセス要求を複数受信したとき、該アクセス要求の送信元のユーザ端末の識別子が同じで、ユーザ端末から得られる前記拠点に関する情報が異なる場合、前記受信した複数のアクセス要求の送信元である前記ユーザ端末から、前記中継装置に対するアクセスを禁止することを特徴とするアクセス制御システム。
【請求項８】
請求項7記載のアクセス制御システムにおいて、
前記中継装置は複数であり、
前記管理サーバは、さらに、
中継装置から他の中継装置へのアクセスの可否を示す多段アクセス管理ファイルを記憶装置に有し、
前記ユーザ端末が、該ユーザ端末がアクセスする中継装置を介して、他の中継装置にアクセスするとき、前記管理サーバに前記他の中継装置に対するアクセス要求を送信し、前記管理サーバが前記多段アクセス管理ファイルを参照してアクセスを許可した場合に、前記他の中継装置にアクセスが可能となることを特徴とするアクセス制御システム。
【請求項９】
請求項8記載のアクセス制御システムであって、
さらに、スイッチを備え、
前記フィルタリング制御部は、前記中継装置のファイアウォールの代わりに、前記スイッチを、前記照合の結果定まる範囲に対してのみ前記ユーザ端末が前記中継装置にアクセスできるように制御することを特徴とするアクセス制御システム。
【請求項１０】
請求項9記載のアクセス制御システムにおいて、
前記中継装置はブレードPCであることを特徴とするアクセス制御システム。
【請求項１１】
ユーザ端末と、管理サーバと、前記ユーザ端末がアクセスする中継装置と、前記中継装置を介して前記ユーザ端末がアクセスする処理サーバと、前記ユーザ端末と制御するスイッチとを、ネットワークを介して接続して備えるアクセス制御システムにおいて、
前記管理サーバは、
前記ユーザ端末の位置に関する位置情報、及び前記ユーザ端末のユーザに関するユーザ情報と、前記ユーザ端末が前記中継装置にアクセスする場合に、前記中継装置を介して前記ユーザ端末がアクセスできる前記処理サーバを関連付けた情報であるフィルタリングポリシーを有する記憶装置と、
前記ユーザ端末から前記中継装置へアクセス要求を受信する通知処理部と、前記アクセス要求を受信した後、前記アクセス要求から前記ユーザ端末の識別子、及び前記位置情報と前記アクセス要求の対象である中継装置から前記ユーザ情報を取得する状況情報収集部と、前記取得したユーザ端末の識別子、位置情報、及びユーザ情報と、前記フィルタリングポリシーを照合するポリシー照合部と、前記照合の結果定まる処理サーバに対してのみ前記ユーザ端末が前記中継装置を介してアクセスできるように前記スイッチを制御するフィルタリング制御部とを有するアクセス制御部と、
を備えることを特徴とするアクセス制御システム。
【請求項１２】
請求項11記載のアクセス制御システムにおいて、
前記管理サーバは、さらに、
前記中継装置の記憶装置の状態を監視する資産管理部と、
前記資産管理部から、前記中継装置の記憶装置が追加、変更、又は削除された場合にされる通知を受信し、前記追加、変更、又は削除に応じて前記フィルタリングポリシーを更新するメンテナンス部を有することを特徴とするアクセス制御部。
【請求項１３】
請求項12記載のアクセス制御システムにおいて、
前記位置情報は、前記ユーザのプレゼンス情報を含み、
前記ユーザ情報は、前記ユーザ端末のユーザに関するスケジュール情報、出張目的、出張先、及びアクセス目的を含むことを特徴とするアクセス制御システム。
【請求項１４】
請求項13記載のアクセス制御システムにおいて、
前記プレゼンス情報は、さらに、前記ユーザがユーザ端末を利用する拠点に関する情報を含み、
前記ユーザ端末は、前記ユーザがユーザ端末を利用する場合、該利用する拠点の入退室管理を行う入退室管理サーバから、前記拠点に関する情報を取得することを特徴とするアクセス制御システム。
【請求項１５】
請求項13記載のアクセス制御システムにおいて、
前記プレゼンス情報は、さらに、前記ユーザがユーザ端末を利用する拠点に関する情報を含み、
前記ユーザ端末は、自身が有するGPSから、該ユーザ端末の利用する拠点に関する情報を取得することを特徴とするアクセス制御システム。
【請求項１６】
請求項14記載のアクセス制御システムにおいて、
前記ユーザ情報は、さらに、前記ユーザ端末のユーザにおける職制、及び業務に関する情報を含むことを特徴とするアクセス制御システム。
【請求項１７】
請求項16記載のアクセス制御システムにおいて、
前記フィルタリング制御部は、
前記通知処理部が前記ユーザ端末から前記中継装置へのアクセス要求を複数受信したとき、該アクセス要求の送信元のユーザ端末の識別子が同じで、ユーザ端末から得られる前記拠点に関する情報が異なる場合、前記受信した複数のアクセス要求の送信元である前記ユーザ端末から、前記中継装置に対するアクセスを禁止することを特徴とするアクセス制御システム。
【請求項１８】
請求項17記載のアクセス制御システムにおいて、
前記中継装置は複数であり、
前記管理サーバは、さらに、
中継装置から他の中継装置へのアクセスの可否を示す多段アクセス管理ファイルを記憶装置に有し、
前記ユーザ端末が、該ユーザ端末がアクセスする中継装置を介して、他の中継装置にアクセスするとき、前記管理サーバに前記他の中継装置に対するアクセス要求を送信し、前記管理サーバが前記多段アクセス管理ファイルを参照してアクセスを許可した場合に、前記他の中継装置にアクセスが可能となることを特徴とするアクセス制御システム。
【請求項１９】
請求項18記載のアクセス制御システムであって、
さらに、スイッチを備え、
前記フィルタリング制御部は、前記中継装置のファイアウォールの代わりに、前記スイッチを、前記照合の結果定まる範囲に対してのみ前記ユーザ端末が前記中継装置にアクセスできるように制御することを特徴とするアクセス制御システム。
【請求項２０】
請求項19記載のアクセス制御システムにおいて、
前記中継装置はブレードPCであることを特徴とするアクセス制御システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば、インターネットプロトコル（Internet Protocol：IP）を使用して、ユーザが操作するユーザ端末から、ネットワーク及び中継装置を介してリソースにアクセスする、いわゆるリモートアクセスを行う環境下におけるアクセス制御技術に関する
。
【背景技術】
【０００２】
従来、リモートアクセスを実現する形態の一例として、ユーザが直接操作する端末をリモートアクセスするための必要最低限の機能しか持たないシンクライアント端末とし、リモートアクセス先となるサーバ側に、必要なアプリケーションやデータを置くようにしたシンクライアントシステムが知られている。このシンクライアントシステムでは、アプリケーションやデータを各ユーザの端末に持たせていた従来のシステムと異なり、管理者が個々のユーザの端末のアプリケーションやデータ等を管理する必要がなく、サーバ側で一括管理ができるため、コスト削減のメリットがある。
【０００３】
近年、情報漏えい問題が深刻化してきており、単にコスト削減の面だけでなく、ユーザの手元に機密情報を置かないで済むというセキュリティ上のメリットから、シンクライアントシステムの普及が拡大しつつある。
【０００４】
ところで、ネットワークにおけるセキュリティを図るために、ネットワーク上のリソースへのアクセスを制御することが行われている。例えば、フィルタリング機能を有するファイアウォールが、アクセスしてきた装置のＩＰアドレスをパケットの送信元ＩＰアドレスから取得してアクセス可能なリソース開示範囲を制御することが行われている。
【０００５】
また、別の技術として、特許文献１には、ＩＰアドレスが動的に割り当てられる計算機からのアクセスにおいても、アクセス制御を行うことができる技術が開示されている。
【０００６】
【特許文献１】特開平１０−２８１４４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
例えば、パケットの送信元ＩＰアドレスによりリソース開示範囲を制御することを、リモートアクセス環境下において実施することを想定すると、ユーザが直接操作を行っているユーザ端末から送信されるパケットは、中継装置を経由してファイアウォールに導かれることとなり、ファイアウォールには、中継装置のＩＰアドレスが送信元となっているパケットが導かれることになる。すなわち、同じ中継装置を介してアクセスをする場合には
、ファイアウォールには、常に同じ中継装置のＩＰアドレスが到達することとなり、ユーザがいずれの場所からユーザ端末により中継装置を介してリソースへのアクセスを試みたとしても、常に同じリソースが開示されることとなる。
【０００８】
このことは、例えば、ユーザが社内からリソースへのアクセスを行う場合でも、出張先等の社外からリソースへのアクセスを行う場合でも、同じ範囲のリソースにアクセスすることができることを意味しており、情報漏えいの可能性が高まり、セキュリティの面から好ましくない。
【０００９】
また、特許文献１の技術においても、ユーザ認証情報に基づくアクセス制御をしており
、ユーザが同じである場合には、同じリソースの開示範囲となり、上記同様に情報漏えいの可能性が高まり、セキュリティの面から好ましくない。
【００１０】
本発明は、上記課題に鑑みなされたものであり、中継装置を介してのアクセスに対して
、開示可能なリソースの範囲を適切に制御することができ、セキュリティを向上することのできる技術を提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記目的達成のため、本発明は、例えば、ユーザのいる位置に関する情報や、スケジュールの情報、リソースへアクセスする目的に関する情報等といった、ユーザ端末によってリソースを利用する場面に関わる状況情報に応じて、ユーザが必要とするリソースの範囲や、管理者がユーザに開示しても良いと考えるリソースの範囲が異なることに着目してなされたものである。
本発明の一態様に係るアクセス制御システムは、一以上のリソースと、ユーザが操作するユーザ端末から前記リソースへのアクセスを中継するための中継装置と、前記リソースと前記中継装置との間に設けられ、前記リソースへの前記中継装置側からのアクセスにおけるフィルタリングを行うフィルタリング装置とを備えるアクセス制御システムであって、前記アクセス制御システムは、前記フィルタリング装置のフィルタリングを制御する制御サーバを更に備え、前記制御サーバは、前記ユーザ端末による前記リソースに対する利用要求を受信する受信部と、前記利用要求を受信した際に、前記ユーザ端末によって前記リソースを利用する場面に関わる状況情報を取得する取得部と、前記状況情報に基づいて、前記リソース中の利用許可可能なリソースを決定する決定部と、前記利用許可可能なリソースへの前記中継装置を介してのアクセスが可能となるように前記フィルタリング装置によるフィルタリングを制御する制御部とを有することを特徴とする。
【発明の効果】
【００１２】
本発明によると、中継装置を介してのアクセスに対して、開示可能なリソースの範囲を適切に制御することができ、セキュリティを向上することができる。
【発明を実施するための最良の形態】
【００１３】
本発明の実施形態について、図面を参照して説明する。なお、以下に説明する実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組合せの全てが発明の解決手段に必須であるとは限らない。
【実施例１】
【００１４】
図１は、本実施例に係るアクセス制御システムを含むネットワークシステムの一例であるシンクライアントシステムの構成図である。
【００１５】
シンクライアントシステム１０００は、リソースとして、ｎ個のサーバ１２００、１３００、１４００を備えている。ｎ個のサーバ１２００等は、フィルタリング装置の一例としてのスイッチ１５００を介して、中継端末の一例としてのブレードＰＣ１６００、１６１０、１６２０・・・に接続されている。ブレードＰＣ１６００、１６１０、１６２０等は、ネットワークの一例としてのインターネット１１０１に接続されている。なお、本実施形態では、ネットワークは、遠隔地からの接続を意識して便宜的にインターネット１１０１としているが、ネットワークとしては、例えば、イントラネットであってもよく、管理センタ内のネットワークであってもよく、その他の任意のネットワークであってもよい。
【００１６】
スイッチ１５００と、複数のブレードＰＣ１６００、１６１０、１６２０等は、図示しないネットワークを介して制御サーバの一例としての管理サーバ１７００に接続されている。管理サーバ１７００は、さらに、図示しないネットワークによってインターネット１１０１と接続されている。本実施形態では、サーバ１２００、１３００、１４００等と、スイッチ１５００と、ブレードＰＣ１６００、１６１０、１６２０・・と、管理サーバ１７００とが管理センタ内に設けられている。一方、インターネット１１０１には、例えば、出張先にあるユーザ端末１８００が接続されている。このような構成により、ユーザがユーザ端末１８００を操作することにより、ユーザ端末１８００がブレードＰＣ１６００等を介してサーバ１２００等にアクセスすることができるようになっている。
【００１７】
サーバ１２００、１３００、・・・１４００のｎ個のサーバは、同様な構成をしているので、ここでは、サーバ１２００についての構成を説明することとする。なお、各サーバ１２００、１３００、・・・１４００が、それぞれのハードディスクドライブ（ＨＤＤ）、及びメモリ上に保持するデータについては、異なっていてもよく、また、同じであってもよい。サーバ１２００は、バスインターフェース（バスＩＦ）１２０２によって連結されたメモリ１２０３、ＣＰＵ（Central Processing Unit）１２０１、ＨＤＤ１２０６を有する。メモリ１２０３上には、ユーザが利用しているアプリケーション１２０４を起動・保持することができるとともに、ユーザが作業に利用しているデータ（ユーザ作業データ）１２０５を保持することができるようになっている。また、サーバ１２００は、ＩＰネットワーク回線に接続可能なポート１２０７を有する。本実施形態では、ポート１２０７は、ＩＰネットワーク回線１１０３を介してスイッチ１５００に接続されている。本実施形態では、サーバ１３００、・・・１４００もＩＰネットワーク回線１１０４及び１１０５を介してスイッチ１５００に接続されている。
【００１８】
スイッチ１５００は、バスＩＦ１５０６によって連結されたＣＰＵ１５０２、メモリ１５０３、スイッチング部１５０５、ポート１５０１、１５０４、および管理サーバ１７００からのアクセス制御の通信を受け入れるための図示しない管理用のポート等を有する。スイッチング部１５０５は、自身が主体となって、管理サーバ１７００からの後述するフィルタリング要求に応じて、ポート１５０１とポート１５０４との間の通信におけるフィルタリング処理を実行する。なお、本実施形態においては、スイッチング部１５０５は、スイッチ１５００の起動直後においては、全てのユーザ端末からリソースを利用できないように設定されている。すなわち、リソース側の全てのポートが遮断状態に設定されている。この設定は、例えば、スイッチ１５００が自身により設定するようにしてもよく、或いは、管理サーバ１７００が設定するようにしてもよい。設定ポート１５０４等は、ＩＰネットワーク回線１１０６等を介して複数のブレードＰＣ１６００、１６１０、１６２０等に接続される。
【００１９】
ブレードＰＣ１６００、１６１０、１６２０は、同様な構成をしているので、ここでは、ブレードＰＣ１６００について説明することとする。ブレードＰＣ１６００は、バスＩＦ１６０５によって連結された、メモリ１６０２、ＣＰＵ１６０３、ＨＤＤ１６０４、ポート１６０１、及びポート１６０６を有する。ポート１６０６は、ＩＰネットワーク回線１１０７を介してインターネット１１０１に接続されている。なお、ポート１６０１とポート１６０６は、それぞれスイッチ１５００、又はユーザ端末１８００と通信可能であれば、物理的には１つの装置により構成されていてもよく、また、２つの装置により構成されていてもよい。
【００２０】
メモリ１６０２又はＨＤＤ１６０４は、リソースを利用する場面に関わる状況情報を記憶する。リソースを利用する場面に関わる状況情報としては、例えば、出張先等のユーザがいる場所等のプレゼンス情報や、ユーザに関するスケジュール情報や、リソースを使用する目的等がある。これら状況情報は、例えば、ユーザ端末１８００をブレードＰＣ１６００に接続することにより、ユーザが設定することができるようになっている。このため、後述するアクセス制御において、より柔軟な制御を行うことができる。ブレードＰＣ１６００のＣＰＵ１６０３は、所定のプログラムを実行することにより、管理サーバ１７００からの要求に応じて、メモリ１６０２あるいはＨＤＤ１６０４に記憶されているリソースを利用する場面に関わる状況情報を管理サーバ１７００に応答する処理を実行する。また、ブレードＰＣ１６００のＣＰＵ１６０３は、ポート１６０６を介してユーザ端末１８００からの要求を受信し、ポート１６０１を介してスイッチ１５００側に送信するとともに、ポート１６０１を介してスイッチ１５００側からのデータを受信し、ポート１６０６を介してユーザ端末１８００へ送信する中継処理を実行する。なお、本実施形態では、ブレードＰＣ１６００によって中継されるデータのパケットにおける送信元ＩＰアドレスには、ブレードＰＣ１６００のＩＰアドレスが付与される。
【００２１】
管理サーバ１７００は、バスＩＦ１７０６によって連結された、メモリ１７０１、ＣＰＵ１７０４、フィルタリングポリシー記憶部の一例としてのＨＤＤ１７０５を有する。更に、管理サーバ１７００は、スイッチ１５００に対してアクセス制御の通信を行うための図示しない管理用ポートを有しており、この管理用ポートが接続される図示しないＩＰネットワーク回線によって、スイッチ１５００の管理用ポート、ブレードＰＣ１６００等と接続されている。また、管理サーバ１７００は、インターネット１１０１に直接又は間接的に接続されており、インターネット１１０１を介して、ユーザ端末１８００との間での通信が可能となっている。
【００２２】
ＨＤＤ１７０５は、後述する機能を実現するためのアクセス制御機能プログラム１７０２と、フィルタリングポリシー１７０３とを格納している。アクセス制御機能プログラム１７０２は、ＨＤＤ１７０５からメモリ１７０１上に呼び出されて、ＣＰＵ１７０４により実行される。また、フィルタリングポリシー１７０３は、メモリ１７０１上に呼び出されて、ＣＰＵ１７０４により参照や編集される。なお、以下で示すプログラムは、アクセス制御機能プログラム１７０２と同様、ＨＤＤからメモリ上に呼び出されて、ＣＰＵによって実行されるという処理が行われる。
【００２３】
なお、ここでいうリソースとは、ユーザ端末、中継装置、管理サーバなどを指し、より具体的には、中継装置としてのクライアントブレード、中継装置としての仮想サーバ環境における仮想マシン、中継装置としてのデスクトップＰＣ、中継装置としてのサーバブレード、リモートサイトのユーザ環境から中継装置を介して間接的にアクセス可能な、あるいはリモートサイトのユーザ環境から直接的にアクセス可能なサーバ、ストレージ装置やテープ装置などの記憶装置、ストレージセントリックシステムとして中継装置とストレージ装置を一体として見た場合の作業環境、ネットワークブートシステムとしての、ユーザ端末と介在するネットワークと中継装置を一体として見た場合の作業環境などを含む。
【００２４】
次に、管理サーバ１７００の構成及び動作をより詳細に説明する。
【００２５】
図２は、本実施例に係る管理サーバの構成及び動作を説明する図である。
【００２６】
アクセス制御機能プログラム（以下、アクセス制御機能ＰＧ）１７０２は、受信部を構成するための通知処理モジュール５０００、取得部を構成するための状況情報収集モジュール５００１、決定部を構成するためのポリシー照合モジュール５００２と、制御部を構成するためのフィルタリング制御モジュール５００３を有する。これらプログラム及びモジュールをＣＰＵ１７０４が実行することにより、各部が構成される。
【００２７】
通知処理モジュール５０００は、ユーザ端末１８００との間の各種通知のやりとりを制御するモジュールである。ユーザ端末１８００との間の各種通知としては、利用要求通知１９０２、準備結果通知１９０４、終了要求通知１９０３、及び終了結果通知１９０５がある。
【００２８】
図３は、本実施例に係る各種通知のデータ構造を示す図である。
【００２９】
利用要求通知１９０２は、ユーザがユーザ端末１８００を利用してリソースの利用開始を要求する際に送信される通知であり、少なくとも、通知種別カラム、通知先カラム、及び状況情報カラムを有する。通知種別カラムには、リソースの利用要求を表す識別子「CONNECT」が設定される。通知先カラムには、管理サーバ１７００のＩＰアドレスが設定される。状況情報カラムには、要求元であるユーザ端末１８００のＩＰアドレスが設定される。このＩＰアドレスによると、ユーザ端末１８００が実際に存在する具体的な場所を把握することができる場合がある。例えば、ユーザ端末１８００のＩＰアドレスが、在る特定のネットワークにおけるＩＰアドレスであれば、そのネットワークに接続されていることが把握でき、当該ネットワークの場所にユーザ端末１８００が存在することが把握できる。
【００３０】
準備結果通知１９０４は、管理サーバ１７００がユーザ端末１８００に送信する通知であり、少なくとも、通知種別カラム、通知先カラム、準備結果カラム、及びリソース開示範囲カラムを有する。通知種別カラムには、準備結果を示す「RESULT_CONNECT」が設定される。通知先カラムには、要求元であるユーザ端末１８００のＩＰアドレスが設定される。準備結果カラムには、ユーザ端末１８００に対して、適切なリソース開示を行うためのアクセス制御が成功したか否かを示す結果が設定される。例えば、準備が成功した場合には、準備成功を表す識別子「SUCCESS」が設定され、準備が失敗した場合には、準備失敗を表す識別子「FAILURE」が設定される。リソース開示範囲カラムには、ユーザ端末１８００からアクセス可能なサーバのＩＰアドレスリストが設定される。ＩＰアドレスリストが設定されるのは、準備結果が「SUCCESS」の時だけであり、準備結果が「FAILURE」の時には、リソース開示範囲カラムには何も設定されない。
【００３１】
終了要求通知１９０３は、ユーザがユーザ端末１８００を利用したリソースの利用を終了する際に送信される通知であり、少なくとも、通知種別カラム、及び通知先カラムを有する。通知種別カラムには、終了要求を示す「DISCONNECT」が設定される。通知先カラムには、管理サーバ１７００のＩＰアドレスが設定される。
【００３２】
終了結果通知１９０５は、管理サーバ１７００がユーザ端末１８００に送信する通知であり、少なくとも、通知種別カラム、通知先カラム、及び終了結果カラムを有する。通知種別カラムには、終了結果を示す「RESULT_DISCONNECT」が設定される。通知先カラムには、要求元であるユーザ端末１８００のＩＰアドレスが設定される。終了結果カラムには、アクセス可能にしたリソース開示範囲の設定を初期化できたか否かを表す結果を設定する。終了結果カラムには、リソース開示範囲の初期化が成功した場合には、成功を表す識別子「SUCCESS」が設定され、リソース開示範囲の初期化に失敗した場合には、失敗を表す識別子「FAILURE」が設定される。
【００３３】
図２に戻り、ＣＰＵ１７０４が実行する通知処理モジュール５０００によって、ユーザ端末１８００からの利用要求通知１９０２を受信すると、ＣＰＵ１７０４は、状況情報収集モジュール５００１によって、通知処理モジュール５０００及びブレードＰＣ１６００から状況情報を取得する。
【００３４】
ＣＰＵ１７０４が状況情報収集モジュール５００１を実行することによって、通知処理モジュール５０００から収集する状況情報は、利用要求通知１９０２に含まれている状況情報であり、具体的には、要求元であるユーザ端末１８００のＩＰアドレスである。また
、ＣＰＵ１７０４が状況情報収集モジュール５００１によってブレードＰＣ１６００から取得する状況情報は、ユーザのスケジュール情報、ユーザの出張目的、ユーザの出張先、ユーザのアクセス目的等である。
【００３５】
また、ＣＰＵ１７０４は、ポリシー照合モジュール５００２を実行することにより、状況情報収集モジュール５００１により収集した状況情報と、フィルタリングポリシー１７０３（図４参照）とを照合し、状況情報に対応するポリシー、すなわち、リソースの開示範囲を決定する。さらに、ＣＰＵ１７０４は、フィルタリング制御モジュール５００３を実行することにより、決定したリソースの開示範囲に従って、フィルタリング処理のためのアクセス制御リストを生成し、アクセス制御リストを含むフィルタリング要求１９００をスイッチ１５００に送信することにより、フィルタリングを制御する。アクセス制御リストには、例えば、ユーザ端末１８００の中継を行うように決定したブレードＰＣ１６００のＩＰアドレスと、ユーザ端末１８００へ開示可能なネットワーク、サーバ名、又はファイル名とが対応付けられた情報が含まれている。ここで、ユーザ端末１８００の中継を行うようにするブレードＰＣの決定方法としては、例えば、予め複数のブレードＰＣの使用状況を管理しておき、利用要求通知１９０２を受信した場合に、未使用のブレードＰＣを検出して、決定するようにすればよい。中継を行うブレードＰＣを決定した場合には、ユーザ端末１８００に決定したブレードＰＣのＩＰアドレスを通知する。この通知は、例えば、ユーザ端末１８００に返信する準備結果通知１９０４に含めるようにすればよい。これにより、ユーザ端末１８００は、該当するＩＰアドレスのブレードＰＣを把握し、アクセスすることができる。
【００３６】
図４は、本実施例に係るフィルタリングポリシーのデータ構造を示す図である。
【００３７】
フィルタリングポリシー１７０３は、共通設定部分１７０３ａと、個別設定部分１７０３ｂとを有する。共通情報部分１７０３ａは、少なくとも、基準状況情報種別カラム、フラグカラム、及び基準状況情報種別の組合せ論理式カラムを有する。個別設定部分１７０３ｂは、少なくとも、状況情報種別カラム、状況情報カラム、及びリソース開示範囲カラムを有する。
【００３８】
フィルタリングポリシー１７０３は、管理者あるいはユーザ、あるいはその両方によって編集・設定されるものであり、上記編集・設定は、必ず管理サーバ１７００のアクセス制御機能ＰＧを介してなされるものとする。このとき、上記管理サーバ１７００のアクセス制御機能ＰＧは、管理サーバ１７００の内部に予め管理者の有するユーザ識別子のリストを持っており、編集・設定の要求があれば、このユーザ識別子を判定することにより、管理者のユーザ識別子であれば、全ユーザのアクセスに関するセキュリティポリシーに対する編集・設定権限を与え、一般ユーザのユーザ識別子であれば、自分のアクセスに関するセキュリティポリシーに対する編集・設定権限のみ与えるような仕組みを有しているものとする。また、上記管理サーバ１７００のアクセス制御機能ＰＧは、内部にユーザと管理者の編集・設定に関する優先順位を有しており、この優先順位に基いて、ユーザと管理者の両方が同時にセキュリティポリシーの編集・設定を行おうとした際に、どちらの作業を優先させるかを決定し、排他制御を行う。
【００３９】
基準状況情報種別カラムには、アクセス制御に利用可能な状況情報の種別が設定される
。状況情報の種別としては、ユーザ端末の位置情報の種別を示すLOCATION、ユーザのスケジュール情報の種別を示すSCHEDULE、ユーザの出張目的の種別を示すTRIP_OBJECT、ユーザの出張先の種別を示すTRIP_BASE、アクセス目的の種別を示すACCESS_OBJECT等がある。
【００４０】
フラグカラムには、対応する基準状況情報種別、すなわち、図中では同一行の基準状況情報種別をアクセス制御に有効にするか、無効にするかのフラグの情報が設定される。本実施形態では、対応する基準状況情報種別をアクセス制御で有効にする場合には、ONが設定され、対応する基準状況情報種別をアクセス制御で無効にする場合には、OFFが設定される。なお、本実施形態では、複数個の基準状況情報種別を同時に有効にすることができるようになっている。
【００４１】
基準状況情報種別の組合せ論理式カラムには、フラグによって有効にされた基準状況情報種別の条件の組合せを規定する論理式が設定される。論理式としては、複数の基準状況種別を、AND（論理積）、OR（論理和）、NOT（論理否定）、ExOR（排他的論理和）等の論理演算子を利用した式が指定できる。同図においては、ユーザ端末の位置情報とユーザのスケジュール情報との２つの条件を同時に満たすポリシーに従ってアクセス制御を行うことを示す、「LOCATION  AND  SCHEDULE」が指定されている。この指定がされていれば、状況情報種別が「LOCATION」であるリソース開示範囲と、状況情報種別が「SCHEDULE」であるリソース開示範囲との論理和をとった開示範囲が、状況情報種別が「LOCATION」である状況情報と、状況情報種別が「SCHEDULE」である状況情報とを満たす場合にユーザ端末１８００に開示される開示範囲となる。同図では、例えば、特定のＩＰアドレスa.b.c.1に対してサーバリソースSV-1をリソース開示範囲とし、特定の時間帯08:30から12:00の間に公開するというポリシーとなる。
【００４２】
個別設定部分１７０３ｂは、少なくとも、状況情報種別カラム、状況情報カラム、及びリソース開示範囲カラムを有する。状況情報種別カラムには、ポリシーとして用いる状況情報の種別が設定される。状況情報カラムには、対応する状況情報種別に属する所定の状況情報が設定される。設定できる状況情報としては、例えば、ＩＰアドレス、ネットワーク、時間帯、出張目的、拠点、アクセス目的等を設定することができる。リソース開示範囲カラムには、対応する状況情報を満たす際に、開示可能なリソースの範囲（リソース開示範囲）が設定される。リソース開示範囲の単位としては、例えば、サーバ単位であってもよく、ネットワーク単位であってもよく、ファイル単位であってもよい。
【００４３】
例えば、特定のＩＰアドレス（a.b.c.1）からの接続に対して、特定の装置（SV-1）を開示するポリシーを設定する場合には、状況情報種別カラムに「LOCATION」を設定し、状況情報カラムに「a.b.c.1」を設定し、リソース開示範囲カラムには、「SV-1」を設定すればよい。また、特定のＩＰアドレス（a.b.c.2）からの接続に対して、何も開示しないポリシーを設定する場合には、状況情報種別カラムに「LOCATION」を設定し、状況情報カラムに「a.b.c.2」を設定し、リソース開示範囲カラムには、「NON」を設定すればよい。
また、特定のネットワーク（a.b.c.255）からの接続に対して、複数の装置（SV-1、SV-2
）を開示するポリシーを設定する場合には、状況情報種別カラムに「LOCATION」を設定し、状況情報カラムに「a.b.c.255」を設定し、リソース開示範囲カラムには、「SV-1、SV-2」を設定すればよい。なお、「a.b.c.255」は、a.b.c.0〜a.b.c.255までのＩＰアドレスを含むネットワークを意味している。また、特定のＩＰアドレス（a.b.c.3）からの接続に対して、複数のファイル（\\x.y.z.1\files\file.txt、・・・）を開示するポリシーを設定する場合には、状況情報種別カラムに「LOCATION」を設定し、状況情報カラムに「a. b.c.3」を設定し、リソース開示範囲カラムには、「\\x.y.z.1\files\file.txt、・・・」を設定すればよい。
【００４４】
また、ユーザのスケジュール情報を基準としたポリシーを設定する場合、例えば、特定の時間帯（08:30から12:00の間）の接続に対して、全てのリソースを開示するポリシーを設定する場合には、状況情報種別カラムに「SCHEDULE」を設定し、状況情報カラムに「from:08:30、to:12:00」を設定し、リソース開示範囲カラムには、「ALL」を設定すればよい。また、ユーザの出張目的を基準としたポリシーを設定する場合、例えば、特定の出張目的（OBJ1：顧客レビュー）で出先に居るユーザからの接続に対して、複数の装置（SV
-1、 SV-2）を開示するポリシーを設定する場合には、状況情報種別カラムに「TRIP_OBJECT」を設定し、状況情報カラムに「OBJ:顧客レビュー」を設定し、リソース開示範囲カラムには、「SV-1、SV-2」を設定すればよい。また、ユーザのアクセス目的を基準としたポリシーを設定する場合、例えば、特定のアクセス目的（AOBJ1：カタログの取得）で接続してきたユーザに対して、複数の装置（SV-1、SV-2）を開示するポリシーを設定する場合には、状況情報種別カラムに「ACCESS_OBJECT」を設定し、状況情報カラムに「AOBJ:カタログの取得」を設定し、リソース開示範囲カラムには、「SV-1、SV-2」を設定すればよい。
【００４５】
次に、第１実施形態に係るネットワークシステムの動作を説明する。
【００４６】
図５は、本実施例に係るネットワークシステムの動作を示すシーケンス図である。なお、同図は、出張先に居るユーザが管理センタのリソースを利用する場合の動作を示している。
【００４７】
出張先に居るユーザがユーザ端末１８００を用いて管理センタのリソースを利用する際には、ユーザがユーザ端末１８００の図示しない入力装置を利用して、ユーザ端末１８００に管理センタのリソースの利用を開始する指示を行うと、ユーザ端末１８００が管理サーバ１７００に対して、利用要求通知１９０２を発行する（ステップＳ１）。利用要求通知１９０２を受けた管理サーバ１７００は、利用要求通知１９０２及びブレードＰＣ１６００から、ユーザの状況情報を収集する（ステップＳ２）。次に、管理サーバ１７００は、予め設定しているフィルタリングポリシー１７０３を参照して、収集した状況情報に対応するリソースの開示範囲を決定する（ステップＳ３）。
【００４８】
例えば、フィルタリングポリシー１７０３として、「出張先Ａのネットワークからの接続である場合には、SV-1、SV-2、すなわちサーバ１２００、１３００を開示範囲とする」との設定がされている場合には、利用要求通知１９０２に含まれているユーザ端末の位置を示すＩＰアドレスが出張先Ａのネットワーク内のＩＰアドレスであれば、SV-1、SV-2が開示範囲として決定される。
【００４９】
上記フィルタリングポリシーの決定について、図５の処理Ｓ３にて、処理概要を述べたが、具体的なフィルタリングポリシーの決定手順について、図２３のフローチャートに基き、実現手段の一例を以下に示す。
【００５０】
管理サーバ１７００は、ユーザ端末１８００からの利用要求通知１９０２の受信を契機として、フィルタリングポリシーの決定フローを開始する（２３１０１）。利用要求通知１９０２を受信するまでは、待機状態を維持する。利用要求通知１９０２を受信した時点で、管理サーバ１７００は、実際の状況情報を、利用要求通知１９０２のパケットに含まれるデータから抽出し、これを仮に変数Ｘとして保持するものとする（２３１０２）。次に、フィルタリングポリシー１７０３を読み込み、これに含まれる基準状況情報種別のフラグを参照し、有効になっているフラグにつき、これを抽出し、仮に集合Ａとして保持する（２３１０３）。次に、フィルタリングポリシー１７０３に基準状況情報種別の組合せ論理式（以下、単に論理式と表記する）の構成要素が、集合Ａの部分集合であるか否かを検証する（２３１０４）。すなわち、論理式自体の正常性確認を行う。一見すると、上記のようなフラグを用いて、この論理式の正常性確認を行わずとも、状況情報種別毎の情報開示範囲の定義がなされた行ついて正常性確認を行えばよいようにも見えるが、そうではない。ユーザ数が増加したり、運用ポリシーが複雑高度化するにつれ、フィルタリングポリシーが増すが、これに応じて、全ての定義行について正常性確認を行っていたのでは、処理効率が低下し、強いてはユーザに対する品質低下を招くことになる。また、管理者としても、現在有効になっている状況情報種別を一見して把握することが困難となったり、また、有効にしたい状況情報種別のみしか定義として記述できなくなるような不便さがある。そこで、本発明では、フィルタリングポリシー全体を一括的に管理できるよう、上記フラグと上記論理式を用いて管理することによって、処理効率の向上を図り、複数のフィルタリングポリシーを記述しておき、状況に応じて迅速に切り替えを行う、などの使い方も可能とするものである。上記の判定を行った結果、論理式の構成要素が、集合Ａの部分集合であることが確認できた場合、この論理式は正常であると判断し、この論理式をＮ個の変数Ｂ（ｎ）に展開する（２３１０５）。また、上記の判定を行った結果、論理式の構成情報が、集合Ａの部分集合であることが確認できなかった場合、あるいは、明らかにこの部分集合以外の構成要素が含まれていた場合、この論理式には矛盾があると判断してエラー処理を行う（２３２０３）と共に、次の利用要求通知の受信待機状態に戻る（２３１０１）。エラー処理としては、本利用要求通知に対する情報の開示を拒否する（２３２０１）と共に、管理者あるいはユーザに対して、フィルタリングポリシーに論理矛盾を発見した旨、管理者あるいはユーザに対して、ポップアップメッセージやメールなど、可読形式のメッセージとして通知する。これにより、逸早くフィルタリングポリシーの修正を促すことができる（２３２０２）。このようなエラーが発生しなかった場合、条件付きループ処理２３１０６に進み、論理式を構成するＮ個の要素に対して、変数ｎは初期値ｎ＝０から開始し、１ループ毎にｎを１つ加算することにより、ｎ＜Ｎの条件を満たすまで、以下の処理を繰り返す。繰り返しの処理としては、Ｎ番目の変数が指す、状況情報種別を仮にＢ（ｎ）とすれば、まず、ループ毎にＢ（ｎ）の抽出を行う（２３１０７）。次に、フィルタリングポリシー１７０３の各定義行を探索し、状況情報種別カラム＝Ｂ（ｎ）であるか否か、すなわち、上記論理式の一部をなす状況情報種別と適合するかを調べ（２３１０８）、適合しない場合は、本利用要求通知に対する情報の開示を拒否する（２３２０１）と共にエラー処理を行い、次の利用要求通知の受信待機状態に戻る（２３１０１）。適合する場合は、この状況情報種別カラムが指し示す状況情報カラムの値が、変数Ｘに格納された実際の状況情報の値と適合するか否かを調べ（２３１０９）、適合しない場合は、本利用要求通知に対する情報の開示を拒否する（２３２０１）と共にエラー処理を行い、次の利用要求通知の受信待機状態に戻る（２３１０１）。適合する場合は、リソース開示範囲カラムの抽出を行い、これを仮にＮ個の変数Ｃ（ｎ）に代入する（２３１１０）。上記のようなループ処理を論理式を成すＮ個の構成要素全てに対して実施するまで繰り返す。その結果、得られた変数Ｃ（ｎ）の値につき、論理式Ｂ（Ｎ）の正規表現で示されたリソース開示範囲の組合せ定義に従い、リソース開示範囲Ｃ（ｎ）を再構成し、これを本利用要求通知１９０２に対する最終的なフィルタリングポリシー１７０３として決定する。
【００５１】
次に、管理サーバ１７００は、決定された開示範囲を示す特定のリソースをユーザ端末１８００にアクセス可能にするためのフィルタリング要求１９００をスイッチ１５００に送信することにより、スイッチ１５００に対してフィルタリング制御を実行する一方、スイッチ１５００は、フィルタリング要求に従ったフィルタリングを実行できるように設定を試み、設定に成功した場合には、管理サーバ１７００に成功した旨を通知する(ステップＳ４)。これによって、例えば、スイッチ１５００は、出張先Ａのユーザ端末１８００の中継を行うブレードＰＣ１６００を送信元とする通信データを受信した場合には、開示範囲として設定されたサーバ１２００、１３００への通信データであれば、該当するサーバへ当該通信データを送信する一方、それ以外のリソースへの通信データであれば、当該通信データを破棄する処理を実行できるようになる。
【００５２】
フィルタリング制御の結果、制御が成功した場合には、管理サーバ１７００は、ユーザ端末１８００に対して、成功した旨の準備結果通知１９０４を送信する（ステップＳ５）
。ここで、本実施形態では、準備結果通知１９０４には、ユーザ端末１８００がアクセス可能なサーバのリスト、及び、接続すべきブレードＰＣのＩＰアドレスが含まれている。
【００５３】
準備結果通知１９０４を受けたユーザ端末１８００がサーバ等のリソースに対してアクセスする場合においては、指定されているブレードＰＣ１６００を介して、当該リソースへアクセスするための通信データがスイッチ１５００に送信される。スイッチ１５００は、準備結果通知１９０４のリストに含まれているサーバに対するユーザのアクセスであれば、アクセスするための通信データをリソースに送信するように設定されているので、ユーザ端末１８００は、リストに含まれているリソースへアクセスを行うことができる。例えば、出張先Ａからのアクセスであれば、SV-1、SV-2に対してアクセスできる（ステップＳ６、Ｓ７）。
【００５４】
一方、準備結果通知１９０４のリストに含まれていないリソースへのアクセスであれば
、スイッチ１５００は、アクセスするための通信データを破棄するように設定されているので、ユーザ端末１８００は、リストに含まれていないリソースへアクセスを行うことができない。例えば、出張先Ａからのアクセスであれば、SV-3に対してアクセスすることができない（ステップＳ８）。このように、アクセスできるリソースの範囲を制御できるので、不用意な情報漏えいを抑止することができる。
【００５５】
その後、ユーザがユーザ端末１８００による作業を終えた場合には、ユーザ端末１８００が管理サーバ１７００に対して、終了要求通知１９０３を送信する（ステップＳ９）。
これを受けた管理サーバ１７００は、リソースの開示範囲を初期状態、すなわち、アクセス可能にしたリソースへのアクセスを遮断するようにするためのフィルタリング要求をスイッチ１５００に送信することにより、スイッチ１５００に対してフィルタリング制御を実行する一方、スイッチ１５００は、フィルタリング要求に従ったフィルタリングを実行できるように自己の設定を試み、設定に成功した場合には、管理サーバ１７００に成功した旨を通知する(ステップＳ１０)。これによって、例えば、スイッチ１５００は、ブレードＰＣ１６００を送信元とする通信データを受信した場合には、すべての通信データを破棄する処理を実行できるようになる。これによって、情報漏えいを抑止することができる。フィルタリング制御の結果、制御が成功した場合には、管理サーバ１７００は、ユーザ端末１８００に対して、終了結果通知１９０５を送信する（ステップＳ１１）。
【００５６】
例えば、ユーザ端末１８００がブレードＰＣ１６００を介して、リソースへアクセスするための通信データをスイッチ１５００に送信した場合には、スイッチ１５００は、ブレードＰＣ１６００からのリソースへアクセスするための通信データをすべて破棄する。これによって、SV-3だけでなく、作業中にはアクセスすることのできたSV-1、SV-2に対してのアクセスもできなくなる（ステップＳ１２、Ｓ１３、Ｓ１４）。このように、作業終了後の情報漏えいを適切に防止することができる。
【００５７】
以上、本実施例によれば、ユーザは意識することなく、作業場所の環境や目的、時間帯などの状況に応じた適切な開示範囲のリソースにアクセスすることができる。また、万が一、システムへのログイン権限を不正ユーザに盗まれた場合でも、情報の流出を最小限に抑えることができる。
【実施例２】
【００５８】
次に、第２の実施例に係るネットワークシステムについて説明する。
【００５９】
図６は、本実施例に係るネットワークシステムの概略構成及び動作を説明する図である。ここで、第２実施形態においては、第１実施形態と異なる部分について説明することとする。
【００６０】
第２の実施例は、第１の実施例に係るネットワークシステムにおいてユーザの状況情報を一括して管理する状況情報管理サーバ６０００を新たに備え、更に、個々のユーザ端末１８００や、ブレードＰＣ１６００から状況情報を収集するのではなく、状況情報管理サーバ６０００から状況情報を収集するようにしたものである。
【００６１】
状況情報管理サーバ６０００は、ユーザのスケジュール情報、ユーザの出張目的、ユーザの出張先、ユーザのアクセス目的など、ユーザ端末の位置情報以外の状況情報を格納し
、管理している。また、管理サーバ１７００のアクセス制御機能ＰＧ１７０２は、ユーザ端末１８００から利用要求通知１９０２を受信した際に、状態情報管理サーバ６０００から状況情報を収集し、当該収集情報を用いて、フィルタリングポリシー１７０３との照合を行い、フィルタリング要求１９００をスイッチ１５００に送信することによって、アクセス制御を行う処理を実行するためのプログラムとなっている。これによって、ＣＰＵ１７０４がアクセス制御機能ＰＧ１７０２を実行することにより、上記各処理を実行することができる。
【００６２】
以上、第２の実施例によれば、ユーザの状況情報を状況情報管理サーバで容易且つ適切に管理することができる。
【実施例３】
【００６３】
次に、第３の実施例に係るネットワークシステムについて説明する。
【００６４】
図７は、本実施例に係るネットワークシステムの概略構成及び動作を説明する図である。ここで、本実施例は、第１の実施例と異なる部分について説明することとする。
【００６５】
本実施例に係るネットワークシステムは、第１の実施例に係るネットワークシステムにおいて、新たに状況情報管理サーバ６０００を有している。状況情報管理サーバ６０００は、ユーザのスケジュール情報、ユーザの出張目的、ユーザの出張先、ユーザのアクセス目的など、ユーザ端末の位置情報以外の状況情報を格納し、管理している。また、第３実施形態に係る管理サーバ１７００のアクセス制御機能ＰＧ１７０２は、ユーザ端末１８００から利用要求通知１９０２を受信した際に、利用要求通知１９０２、ブレードＰＣ１６００等、及び状況情報管理サーバ６０００から状況情報を収集し、これら状況情報を総括して、フィルタリングポリシー１７０３との照合を行い、フィルタリング要求１９００をスイッチ１５００に送信することによって、アクセス制御を行う処理を実行するためのプログラムとなっている。これによって、ＣＰＵ１７０４がアクセス制御機能ＰＧ１７０２を実行することにより、上記各処理を実行することができる。
【００６６】
以上、第３の実施例によれば、状況情報を種々の場所で設定することができる。
【実施例４】
【００６７】
次に、第４の実施例に係るネットワークシステムについて説明する。ここで、本実施例は、他のいずれの実施例をベースにしても実現することができる。
【００６８】
状況情報管理サーバ６０００は、アクセス制御機能ＰＧ１７０２を実行する装置からアクセスすることができれば、その装置の物理的な配置には制限がなく、また、装置の数についても制限がない。アクセス元が多岐に渡れば、設定内容の競合(矛盾)が発生する可能性が高くなる。また、問題の検出として、設定内容自体が、複雑な組合せを有しているためにその競合の発見が遅れる可能性があり、また、問題の影響として、その競合の発見が遅れると、リモートサイトのユーザは完全にビジネス継続性を失ってしまうというクリティカルな障害に繋がる可能性がある。ポリシー設定の矛盾を目視チェックなどにより事前回避することは非常に困難であり、システム規模を大きくした場合や、設定の方法によっては、同じ状況情報に対して、異なるリソース開示範囲とするポリシーの設定がされてしまい、アクセス制御に対して、論理的に矛盾したポリシーが適用される状況が発生することが考えられる。
【００６９】
そこで、本実施例に係るアクセス制御機能ＰＧ１７０２は、複数の状況情報についてフィルタリングポリシー１７０３と照合する際に、適用すべきリソース開示範囲に論理的な矛盾があるか否かを監査し、論理的な矛盾がない場合には、スイッチ１５００に対して、フィルタリング要求１９００を送信することにより、アクセス制御を行う一方、論理的な矛盾がある場合には、スイッチ１５００に対するフィルタリング要求１９００を送信せずに、アクセス制御は行わないという処理を実行するためのプログラムとなっている。
【００７０】
なお、ここでいう論理的な矛盾とは、フィルタリングポリシー内部でのポリシー不整合と、フィルタリングポリシーと外部情報との不整合があり、より具体的には、内部にユーザ識別子、アクセス元ＩＰアドレス、（カラムを列挙）の組合せで競合している場合、外部に、実際の機器の資産情報(リソースとして最大提供可能な範囲や性能情報など)や稼動状態(稼動中/未稼働/メンテナンス中/破棄予定など)、あるいはそれは表す管理情報と、その他のメタ状況情報と、２つうちいずれかにおいてポリシーに示したリソースの情報と実際のリソースの状態の間に不整合がある場合、ポリシーとメタ状況情報の間でユーザの行動パターンに不整合がある場合をそれぞれ論理的な矛盾と呼び、検出対象とする。
【００７１】
ここで、上記フィルタリングポリシー１７０３は、管理サーバ１７００の内部、あるいは、中継装置の一例である各ブレードＰＣ１６００の内部、のいずれかに格納されているものとし、本フィルタリングポリシー１７０３が本実施例における監査の対象である。また、管理サーバ１７００は、上記フィルタリングポリシー１７０３の格納場所につき、アクセス制御機能１７０２と同じ場所に格納された環境設定ファイルなどにより、予め環境変数として設定されることにより、これを認知する。これは運用形態によって、フィルタリングポリシー１７０３の格納場所や個数が変動するためである。管理サーバ１７００と連携する形態で運用する場合は、管理サーバ１７００内部に上記環境設定ファイルを有しており、なおかつ上記環境設定ファイルの中で、フィルタリングポリシー１７０３の格納場所として管理サーバ１７００内のディレクトリを指示する記述となっている。一方、管理サーバ１７００と連携しない形態、すなわちエージェントを用いて運用する場合は、中継装置の一例としての各ブレードＰＣ内部に上記環境設定ファイルを有しており、なおかつ上記環境設定ファイルの中で、フィルタリングポリシー１７０３の格納場所として、自ブレードＰＣ１６００内のディレクトリを指示する記述となっているか、あるいは、フィルタリングポリシー１７０３を、複数ユーザ分まとめて、管理サーバ１７００上やその他のサーバ上などにおいて、１つのファイルで管理されている場合はそのファイルのディレクトリを指示する記述となっていてもよい。
【００７２】
また、管理サーバ１７００と連携しない形態、すなわちエージェントを用いて運用する場合において、中継装置の一例であるブレードＰＣ１６００のユーザに対する割り当てが、固定割当であり、常に同じユーザが同じブレードＰＣ１６００を利用するような形態であれば特に意識しなくとも不都合は発生しないが、ブレードＰＣ１６００がユーザに対して動的に割り当てられるような形態、すなわち、常に異なるユーザが１つのブレードＰＣ１６００を使い分けるような形態である場合、セキュリティポリシー１７０３が各ブレードＰＣ１６００上に設置してあると、ユーザが切り換わっても、フィルタリングポリシーが追従していないため、同じユーザが同じ条件で接続していても異なるアクセス制御が適用されてしまう可能性がある。このような使い方をする場合、フィルタリングポリシー１７０３を各ブレードＰＣ１６００上に保持するのではなく、前述のように、複数ユーザ分のフィルタリングポリシーを管理サーバ１７００やその他のサーバ上などに設置おくことにより、動的割り当ての影響を受けなくするか、あるいは、接続元ユーザ端末１８００のＩＰアドレスではなく、ユーザ識別子を判別してアクセス制御を行うようにする。これにより、ユーザ端末１８００とブレードＰＣ１６００の対応関係が変化しても、不適切なフィルタリングポリシー１７０３が割り当てられるのを避けることができる。
また、アクセス制御機能ＰＧ１７０２は、管理者あるいはユーザに対して、メールやポップアップメッセージなどによって、アクセス制御に失敗した旨の通知を行う処理も実行するためのプログラムとなっている。これによって、ＣＰＵ１７０４がアクセス制御機能ＰＧ１７０２を実行することにより、上記各処理を実行することができる。
【００７３】
また、管理サーバ１７００がこの監査を実行するタイミングについて、手動の場合と自動の場合で、次の２つのパターンがある。
【００７４】
手動で監査を開始する場合、ユーザあるいは管理者が、管理サーバ１７００を専用の管理インタフェースにより操作することによって、手動で監査を開始する場合、リモートサイトからユーザの監査要求を受けた場合、あるいはユーザ乃至管理者が管理サーバ１７００の有する専用の管理インタフェースを用いて直接的に監査要求を出した任意のタイミングのいずれかにおいて、監査を開始する。
【００７５】
自動で監査を開始する場合、管理サーバ１７００が内部にタイマー機能を有しており、定期的に監査を実行するか、あるいは、定期的にフィルタリングポリシー１７０３のファイル更新の有無を監視していて、更新があった場合にのみ監査を開始するものである。
【００７６】
なお、手動の監査と、自動の監査は独立しており、自動の監査のためのタイマーが動いている間においても、随時、ユーザ乃至管理者からの監査要求を受け付けるものとする。
【００７７】
また、監査結果に対するアクションとして、アクションが起こるタイミングと、その内容につき、次に示す。
【００７８】
監査の方法が手動であるか、自動であるかに関わらず、監査結果が得られた時点で、その監査結果にフィルタリングポリシー１７０３の論理矛盾が認められた場合は、管理サーバ１７００は、即時的にアクセス制御を行い、スイッチ１５００のポート、又はファイアウォール８３００のポートを閉塞させることによって、ユーザアクセスを遮断する。監査結果が得られた時点で、その監査結果にフィルタリングポリシー１７０３の論理矛盾が認められなかった場合は、本監査に伴うアクセス制御は行わない。但し、監査処理以外のアクセス制御、すなわち通常の接続要求や終了要求に伴うアクセス制御は本処理とは関係なく適用されるものとする。これにより、ユーザからの要求と、管理者による監査の両方のオペレーションによるアクセス制御が競合する可能性が考えられるが、もし競合した場合は、セキュリティ性の維持を優先し、監査結果に対するアクセス制御の処理を優先するものとする。
【００７９】
上記に示した一連の監査に伴うアクセス制御の処理は、既にユーザアクセスができる所までシーケンスが進んでしまっている場合においても、例外なく適用される手順であり、既にスイッチ１５００のポート乃至ファイアウォール８３００のポートが閉塞済みであれば、引き続き閉塞状態を保ち、また、上記ポートが開放された状態にあれば、巻き戻し処理として、上記ポートを閉塞させる。
【００８０】
ＣＰＵ１７０４がアクセス制御機能ＰＧ１７０２を実行して上記処理を行うことにより
、ユーザあるいは管理者のケアレスミスによって設定されたフィルタリングポリシーによって引き起こされるおそれのあるセキュリティレベルの低下や、システムの動作不良などを事前に検出することができ、解消することができるようになる。
【００８１】
以上、本発明を複数の実施形態に基づいて説明したが、本発明は上述した実施形態に限られず、他の様々な態様に適用可能である。
【００８２】
例えば、上記実施例では、管理サーバ１７００をスイッチ１５００、ブレードＰＣ１６００とは異なるハードウエアにより実現していたが、本発明はこれに限られず、スイッチ１５００、ブレードＰＣ１６００等、ユーザ端末１８００と通信可能なハードウエアであれば、いずれのハードウエアによって実現してもよい。
【００８３】
また、上記実施形態では、管理サーバ１７００が動的にユーザ端末１８００を中継するブレードＰＣを決定し、ユーザ端末１８００に通知し、ユーザ端末１８００が通知されたブレードＰＣを使用するようにしていたが、本発明はこれに限られず、例えば、管理サーバ１７００が予めユーザ端末１８００に使用させる特定のブレードＰＣを把握しておき、ユーザ端末１８００に、当該特定のブレードＰＣを通知するようにしてもよく。また、ユーザ端末１８００が予め使用するブレードＰＣを把握しておき、そのブレードＰＣを使用するようにしてもよい。
【００８４】
また、上記実施例では、ユーザ端末１８００は、ブレードＰＣを介さずに管理サーバ１７００と通信するようにしていたが、本発明はこれに限られず、ブレードＰＣを経由して管理サーバ１７００との通信を行うようにしてもよい。
【００８５】
ここまでは、管理サーバ１７００が存在することが前提となるシステムの実施例であったが、顧客環境によっては、管理サーバなしで同じようなセキュリティ性を確保したいといったリクワイアメントも想定できる。このため、サーバレスでの実現方式について、第５の実施例にて説明する。
【実施例５】
【００８６】
以下、第５の実施例について、図８乃至図９を用いて説明する。
【００８７】
図８は、本実施例におけるシステムの全体構成を示す図である。図1に比べて、物理構成としては、管理サーバ１７００とスイッチ１５００が縮退された構成となっている。
アクセス先リソースとしてのｎ個のサーバ１２００、１３００、１４００など、ｎ個のサーバ、および、ブレードＰＣ１６００は、直接イントラネット８１００に接続されている。また、ブレードＰＣ１６００は、複数台設置されているものとする。
【００８８】
また、リソース開示範囲制御エージェント８２００（以下、エージェント８２００）が、ブレードＰＣ１６００のハードディスク１６０４上に保存されており、メモリ１６０２上で実行されている。このエージェント８２００が、管理サーバ１７００の代用となり、フィルタリングポリシー１７０３の読み込みや、状況情報８４００の読み込み、アクセス制御など、リソース開示範囲の制御に関する機能の主体となっている。
【００８９】
尚、ブレードＰＣ１６００の設置台数は、１台以上であり、複数台存在してよいため、このエージェント８２００も、ブレードＰＣ１６００の台数に応じて、複数個存在してよい。エージェント８２００が複数個する場合も、１個の場合と同様、リソース開示範囲の制御は、他ユーザの処理とは独立して実行される。
【００９０】
フィルタリング処理は、スイッチ１５００の代わりに、ブレードＰＣ１６００のメモリ１６０２上で実行されているファイアウォール８３００が担っている。但し、管理サーバを縮退したい要件の本質は、できるだけ管理対象となる機器を減らしたいことにあり、このため、各ユーザのブレードＰＣ１６００とポートとの対応関係を意識して管理しなければならないスイッチ１５００も縮退しているものである。従って、特にファイアウォール８３００との連携に制限するものではない。エージェント８２００と連携できる機能あるいは装置であれば、第１の実施例と同様に、スイッチ１５００との連携で実現しても構わないし、それ以外の方法によってアクセス制御を行っても構わない。
【００９１】
図9は、本実施例における処理概要を表すシーケンス図である。
【００９２】
ユーザは、本システムに接続する際、ユーザ端末から、ブレードＰＣ１６００上にあるエージェント８２００に対して、利用要求通知9000を送信する。これを受取ったエージェント８２００は、ユーザ要求に含まれる状況情報８４００、およびブレードＰＣ１６００上にある状況情報８４００を併せて（９００１）、リソース開示範囲を制御するためのポリシーを決定する（９００２）。判定結果が正しければ、ファイアウォールに対して、フィルタリング制御を行い、特定のリソースに対するユーザアクセスを許可するような設定を行う（９００３）。次に、フィルタリングの設定が完了したタイミングで、エージェント８２００は、ユーザ端末１８００に対して、準備完了通知９００４を送信することによって、ユーザアクセスを促す。これを受けたユーザ端末１８００は、目的となるアクセス先リソースに対してアクセスしようと試みるが、予めファイアウォール８３００にてアクセス許可が設定されたアクセス先リソース以外にアクセスすることは出来ず（９００５〜９００７）、出先からのアクセスであっても、適切なセキュリレベルが確保される。
【００９３】
ユーザは、リモートサイトからの作業を終えた時点で、終了要求通知９００８をエージェント８２００に対して送信する。これを受けたエージェント８２００は、ファイアウォール８３００に対して、現在アクセスしているリソースへのアクセスを閉塞させるような制御を行い、その制御が完了次第、ユーザ端末１８００に対して、終了成功通知９０１０を送信する。その後、ユーザは正式に作業を終えているため、再度、エージェント８２００に利用要求通知を送信して、正式に接続シーケンスを再開するまでの間は、全てのサーバリソースに対してアクセス出来なくなる（９０１１〜９０１３）。
【００９４】
図１０は、本実施例におけるブレードＰＣ１６００の論理的な内部構造を示す図であり、主にリソース開示範囲制御エージェント８２００にフォーカスした図である。ブレードＰＣ１６００は、リソース開示エージェント８２００、ファイアウォール８３００、および２つのポート１０２０１、１０２０２を有しており、ユーザ端末１８００は、ポート１０２０１とポート１０２０２を介して、アクセス先リソースであるn個のサーバ１２００、１３００、１４００に接続されている。ここで、ポート１０２０１とポート１０２０２のアクセス制御を行うのが、ファイアウォール８３００であり、このファイアウォール８３００にアクセス制御の指令を出すのが、リソース開示範囲制御エージェント８２００である。リソース開示範囲制御エージェント８２００は、シーケンス管理モジュール１０３０１、通知処理モジュール１０３０２、状況情報収集モジュール１０３０３、ポリシー照合モジュール１０３０４、フィルタ設定用GUIモジュール１０３０５、フィルタリングモジュール１０３０６から構成される。
【００９５】
シーケンス管理モジュール１０３０１は、エージェント８２００内の各機能モジュールの挙動を統括的に監視・制御しているモジュールである。
【００９６】
図１１は、図１０の各機能モジュールの挙動を示す図である。
【００９７】
ユーザは、接続時に、ユーザ端末１８００からエージェント８２００に対して、利用要求通知１０１０１を送信する。これを受けたエージェント８２００では、通知処理モジュール１０３０２で受信する。同モジュールでは、通知の解析を行い、本通知がユーザからの利用開始要求を示す通知であることを判定した上で、シーケンス管理モジュールに対して、利用要求１０１０２を出す。通知の解析は、第１の実施例と同様、通知パケットのデータ構造を調べることにより、図３の利用要求通知１９０２に示すような、通知種別としてCONNECT（利用要求）を有するか否かで判定する。利用要求１０１０２を受けたシーケンス管理モジュール１０３０１は、アクセス制御の条件となる状況情報８４００の収集を状況情報収集モジュール１０３０３に要求し、同モジュールは、ユーザ端末１８００から送信された利用要求通知１０１０１の中に含まれる状況情報８４００を主たる情報源とし、これに補足的な状況情報として、出張申請の内容やスケジュールなどを登録した情報として、自ブレードからアクセスできる場所に設置された状況情報８４００も併せて取得し（１０１１０）、その内容をシーケンス管理モジュール１０３０１に応答する（１０１０３）。
【００９８】
なお、本実施例では最もシンプルな例として、補足的な状況情報８４００が自ブレードのローカルディスク上に保存された場合を示すが、これに限らず、自ブレードからアクセスできる位置にあれば、アクセス先リソースであるn個のサーバ１２００、１３００、１４００のうち、ある特定のサーバ上に格納してあってもよいし、また補足的な状況情報を格納する目的で設置されたある特定の他のブレード上にあってもよく、特に場所は限定しない。次に、シーケンス管理モジュール１０３０１は、アクセス制御の要となるフィルタリングポリシー１７０３の検索要求を、状況情報収集要求１０１０３によって得られた状況情報８４００と共に送信する（１０１０４）。これを受けたポリシー照合モジュール１０３０４は、自ブレードからアクセスできる場所に設置されたフィルタリングポリシー１７０３内を上記状況情報８４００に基づいて検索し、その検索結果をシーケンス管理モジュール１０３０１に応答する（１０１０４）。
【００９９】
また、本実施例では最もシンプルな例として、フィルタリングポリシー１７０３が自ブレードのローカルディスク上に保存された場合を示すが、これに限らず、自ブレードからアクセスできる位置にあれば、アクセス先リソースであるn個のサーバ１２００、１３００、１４００のうち、ある特定のサーバ上に格納してあってもよいし、また補足的な状況情報を格納する目的で設置されたある特定の他のブレード上にあってもよく、特に場所は限定しない。次にシーケンス管理モジュール１０３０１は、ポリシー検索要求１０１０４にて取得したポリシーに従って、フィルタリングモジュール１０３０６に対してフィルタリング処理の適用要求を送信する（１０１０７）。本要求は、ファイアウォール８３００の実装形態にもよるが、通常はACL（Access Control List）と呼ばれる定義ファイルを設定・編集することによりなされるものである。フィルタリングモジュール１０３０６は、ファイアウォール８３００に対して、このACLによるフィルタ適用を行う（１０１０８）。フィルタリングモジュール１０３０６は、フィルタ適用の結果をファイアウォール８３００から応答として受信し、これをシーケンス管理モジュール１０３０１に対して応答する（１０１０７）。ACL要求の成功応答１０１０７の受信を契機として、シーケンス管理モジュール１０３０１は、ユーザアクセスのための準備が整ったと判断し、ユーザ端末１８００に対して、準備完了通知１０１０１を送信する。通知のデータ構造は、図３の準備完了通知１９０４に示すような、通知種別としてRESULT_CONNECT（準備結果）を有するパケットとして送信する。
【０１００】
ユーザ端末１８００が準備完了通知１０１０１を受信したことを契機として、ユーザ端末１８００は、アクセス先リソースであるn個のサーバ１２００、１３００、１４００に対するアクセスを開始する。ここで、前述のファイアウォールによるアクセス制限が掛かるため、今のアクセス条件（状況情報８４００）にて、予め設定されたフィルタリングポリシー１７０３に適合する範囲でしかアクセスすることができない。これにより、出先のアクセス環境に対して、必要な情報は提供しながらも、必要以上に情報が開示されてしまうことによるセキュリティの低下を回避することができる。
【０１０１】
次にユーザは、リモートサイトからの作業を終えて、終了時に、ユーザ端末１８００からエージェント８２００に対して、終了要求通知１０１０１を送信する。これを受けたエージェント８２００では、通知処理モジュール１０３０２で受信する。同モジュールでは、通知の解析を行い、本通知がユーザからの終了要求を示す通知であることを判定した上で、シーケンス管理モジュールに対して、終了要求１０１０２を出す。通知の解析は、第１の実施例と同様、通知パケットのデータ構造を調べることにより、図３の利用要求通知１９０３に示すような、通知種別としてDISCONNECT（終了要求）を有するか否かで判定する。また、終了時にシーケンス管理モジュール１０３０１は、第１の実施例と同様、特にフィルタリングポリシーを参照することなく、全てのn個のサーバ１２００、１３００、１４００に対するアクセスが不可となるようなACL要求１０１０７をフィルタリングモジュール１０３０６に対して送信し、これを受けたフィルタリングモジュール１０３０６は、ファイアウォール８３００に対して、ACLを適用する。ファイアウォール８３００がアクセス制御を行うことにより、本ユーザに対する全てのアクセス経路が閉塞され、未使用時におけるシステムのセキュリティが確保される（１０１０８）。最後に、フィルタリングモジュール１０３０６は、アクセス経路の閉塞成功を受けて、これを終了成功通知１０１０１として、ユーザ端末１８００に送信する。通知のデータ構造は、図３の終了成功通知１９０５に示すような、通知種別としてRESULT_DISCONNECT（準備結果）を有するパケットとして送信する。
【０１０２】
前述のように、第５の実施例では、第１〜第４の実施例においてリソースの開示範囲に関する制御を行う管理サーバ１７００の機能を、個々のブレードＰＣ１６００上で動作するエージェント８２００に持たせることにより、比較的小規模なシステムの場合、わざわざ管理サーバ１７００を設置しなくても運用を開始することができる効果がある。更に、障害の影響範囲の抑制効果がある。具体的には、リソースの開示範囲の制御は、個々のブレードＰＣ１６００上で独立して成されるため、上記制御において発生した障害が、そのまま他ユーザへの影響として現れることがなく、個々のブレードＰＣ１６００内、すなわち該当ユーザだけの影響として閉じられる。また、制御対象となるのは、リソースの開示範囲だけであり、リソースそのものに対して制御（加工や権限の変更）などを行うものではなく、この点においても、他ユーザのアクセス状態に対して影響を与えるシステム構成になっていない。
【実施例６】
【０１０３】
以下、第６の実施例について、図１２乃至図１７を用いて説明する。
【０１０４】
図１２は、本実施例におけるシステムの全体構成を示す図である。本実施例では、第１の実施例におけるＩＰアドレスを基にした状況情報の判定ではなく、オフィスを一意に識別するための識別子（以下、オフィスＩＤと呼ぶ）を基にした状況情報の判定を行うことを特徴とする実施例を挙げる。すなわち、第１の実施例が、ユーザ単位での状況情報の判定およびフィルタリングポリシーの設定を行っているのに対し、本実施例では、オフィス単位での状況情報の判定およびフィルタリングポリシーの設定を行う場合の例である。オフィス毎にセキュリティレベルが同じであるような運用を行う場合、この方法はより効率的であり、また、ユーザに関する属性情報（所属や職制など）が変化しても、作業を行うオフィスが同じであるならば毎回フィルタリングポリシーを変更する必要がないなど、実運用における使い方の幅を広げる機能である。
【０１０５】
本システムにおいて、管理センタ１１００は、オフィスＡ（１２１００）とオフィスＢ（１２２０１）が、インターネット１１０１を介して、管理センタ１１００に接続されており、ユーザA（１２１０１）は、オフィスＡ（１２１００）およびオフィスＢ（１２２０１）のどちらにも入室し、作業できる権限があるとする。また、ユーザA（１２１０１）は通常、オフィスＡ（１２１００）で作業しており、出張先のオフィスＢ（１２２０１）で一時的な作業を行うものとする。また、出張先で利用するオフィスＢ（１２２０１）は、通常利用するオフィスＡ（１２１００）よりもセキュリティ対策のレベルが低いものとし、オフィスＢ（１２２０１）での作業向けに開示できるリソースの範囲は、オフィスＡ（１２１００）で開示できる範囲よりも狭く限定されるべきものとする。
【０１０６】
このような２つのオフィスがインターネット１１０１を介して接続される管理センタ１１００においては、リソースの開示範囲の制御を行う管理サーバ１７００が設置されており、本管理サーバ１７００は、内部にアクセス制御の主体となるアクセス制御機能１９００を有し、アクセス制御機能１９００は、フィルタリングポリシー１２３０１を用いてポリシーの照合を行いながら、スイッチ１５００に対してフィルタリングの適用を行うことにより、アクセス先リソース１２００、１３００、１４００の開示範囲を制御するものである。
【０１０７】
本実施例では、ユーザＡ（１２１０１）が、異なるオフィスであるオフィスＡ（１２１００）とオフィスＢ（１２２０１）との間で出張を行い、作業を行う際、両作業場所において、同じユーザ端末Ａ（１２１０２）を用いて、同じブレードＰＣ１６００を経由し、アクセス先リソースにアクセスする際、適切な開示範囲での開示が行われることを示す。
【０１０８】
図１２のシステム構成図は、図１３の動作概要を示すシーケンス図に従って、動作する。通常利用環境であるオフィスＡ（１２１００）において、ユーザＡ（１２１０１）は、入退室カード１０１０３を用いて、リーダ１０１０４にかざすことにより、認証１２１０５を行い、リーダ１０１０４により読み込まれた入退室カード１０１０３の情報は、入退室管理サーバ１２１０７に対して引き渡される（１２１０８）。この情報の引渡しは、リーダ１０１０４が主体となって入退室管理サーバ１２１０７に対して能動的に送信されてもよいし、また、入退室管理サーバが主体となって、リーダ１０１０４は定期的に入退室管理サーバ１２１０７から本情報を受動的に取得されてもよい。
【０１０９】
入退室管理サーバ１２１０７は、自身が管理するデータベース１２１０６を有しており、そのデータベースは、図１４に示す構造１４１０１を持っている。当オフィス内で全ユーザに共通な情報として、オフィスＩＤカラムを持っており、例としてオフィスＡのオフィスＩＤを示すOFFICE-01が設定されているものとする。また、各ユーザ毎の設定情報として、ユーザ識別子カラム、アクセス可否カラム、ステータスカラムの３つを有しており、それぞれ、ユーザ識別子カラムには、ユーザを一意に識別するための識別子を設定するものであり、例として、ここではユーザＡ、ユーザＢ、ユーザＣを、それぞれUSER-A、USER-B、USER-Cとして設定してあるものとする。また、ステータスカラムには、各ユーザに対する入退室状態を表す識別子が設定される。オフィスＩＤカラム、ユーザ識別子カラム、アクセス可否カラムに関しては、予め管理者によって設定される。但し、既に登録済みのユーザに対して、何らかの理由で一時的に入退室を制限したい要求がある場合は、ユーザ識別子の削除・再登録を行うまでもなく、アクセス可否情報を「可」から「否」に変更し、制限を解く際に元に戻せばよい。また、ステータスカラムは管理者の手動登録によるものではなく、各ユーザの入退室に同期して、入退室管理サーバ１２１０７によって自動的に更新が行われるものである。
【０１１０】
入退室カード１０１０３の情報を受けた入退室管理サーバ１２１０７は、データベース１２１０６内を検索することによって、ユーザＡ（１２１０１）の入退室権限をチェックし、ユーザＡ（１２１０１）に対して入退室権限があると見なされた場合は、そのユーザに対するステータスを「退室」から「入室」に更新し（１３１０１）、ドアのロックを解除する（１３１０２）。ユーザＡ（１２１０１）は、入室を完了した後、オフィスＡ（１２１００）内で、ユーザ端末Ａ（１２１０２）の物理スイッチ、あるいはユーザ端末の画面上にある接続ボタンを押すなどして、ユーザ端末１２１０２に対して接続要求１３１０３を指示する。
【０１１１】
接続要求１３１０３を受けたユーザ端末１２１０２は、入退室管理サーバ１２１０７に対して、オフィスを一意に特定するために、予め管理者によって入退室管理サーバ１２１０７に対して割り当てられたオフィスＩＤ（以下、単にオフィスＩＤと表記）の提供を要求する（１３１０４）。入退室管理サーバ１２１０７は、自身に割り当てられたオフィスＩＤである「OFFICE-01」という識別子を含む応答をユーザ端末１２１０２に対して応答する（１３１０５）。続いて、ユーザ端末１２１０２は、上記オフィスＩＤ「OFFICE-01」を含む利用要求通知１３１０６を、管理センタ内１１００内に設置してある管理サーバ１７００に対して送信する。
【０１１２】
管理センタ１１００内に設置された管理サーバ１７００が管理するフィルタリングポリシー１２３０１は、図１５に示すデータ構造１５１０１を持っている。データ構造そのものは、図４に示すデータ構造１７０３と本質的には変わらないが、本実施例では、作業場所がどのオフィスであるか、という情報を元にリモートサイトにおけるアクセス制御を行うことが本質であるため、状況情報種別として、特にオフィスＩＤに着目した設定例を例示したものとなっている。
【０１１３】
以下、テーブルの各カラムについて、説明する。
【０１１４】
複数個設定された状況情報種別のうち、どれを有効な情報として利用するかを表す基準状況情報種別カラムでは、ユーザの出張先を示す「TRIP_BASE」という状況情報種別だけON（有効）にし、他は無効にした場合を例示している。状況情報種別「TRIP_BASE」は、ユーザの出張先を示す情報であれば、特にオフィスＩＤである必要はなく、各出張先の名称であってもよいし、近隣オフィスをひとくくりにした地域名称であってもよい。また、基準状況情報種別の組合せ論理式カラムには、「TRIP_BASE」のみ設定されているものとする。また、各ユーザ毎の設定情報として、状況情報種別カラム、状況情報カラム、リソース開示範囲カラムがある。状況情報種別カラムは、全て「TRIP_BASE」で共通であり、それぞれ、特定のオフィスＩＤ（OFFICE-01）に対して、複数の装置（SV-1、SV-2、SV-3）を開示するポリシー、特定のオフィスＩＤ（OFFICE-02）に対して、特定の装置（SV-1）を開示するポリシー、特定のオフィスＩＤ（OFFICE-03）に対して、何も開示しない（NON）ポリシー、複数のオフィスＩＤ（OFFICE-04、OFFICE-05）を含む地域単位で、特定の装置（SV-4）を開示するポリシー、特定のオフィスＩＤ（OFFICE-06）に対して、複数のファイル（\\x.y.z.1\files\file1.txt、・・・）を開示するポリシー、特定のオフィスＩＤ（ＯＦＦＩＣＥ−MAIN）に対して、全てのリソースを開示するポリシー、が設定されているものとする。どの場合も、リソース開示範囲の粒度が変わるだけで、制御の本質は同じであるため、ここでは、具体的な制御の説明として、最初の２つのポリシーである、特定のオフィスＩＤ（OFFICE-01）に対して、複数の装置（SV-1、SV-2、SV-3）を開示するポリシー、特定のオフィスＩＤ（OFFICE-02）に対して、特定の装置（SV-1）を開示するポリシーについてのみ具体的に説明する。
管理サーバ１７００は、前述のフィルタリングポリシー１２３０１を検索し（１３１０７）、ユーザＡ（１２１０１）に対するリソースの開示範囲を、サーバ１２００、１３００、１４００の３台として、スイッチ１５００に対してフィルタリングの適用を実施し（１３１０８）、ポートの開放を行う。このフィルタリングの適用が成功した場合、管理サーバ１７００は、ユーザ端末１２１０２に対して、サーバ１２００、１３００、１４００に対するアクセス準備が整ったことを示す準備完了通知１３１０９を送信する。これを受信したユーザ端末Ａ（１２１０２）は、ブレードＰＣ１６００に対して接続を確立する（１３１１０）。接続が確立した時点で、ユーザ端末Ａ（１２１０２）の画面上には、リモート画面が表示される（１３１１１）ため、これを契機として、ユーザＡ（１２１０１）は、ブレードＰＣ１６００経由で、サーバ１２００、１３００、１４００、のそれぞれのリソースに対してアクセスしながら、作業を実施することができる（１３１１２）。
【０１１５】
ユーザＡ（１２１０１）が作業を終えた時点で、リモート画面の切断（１３１１３）を行うことを契機として、ユーザ端末Ａ（１２１０２）は、管理サーバ１７００に対して、終了要求通知１３１１４を送信し、これを受けた管理サーバ１７００は、スイッチ１５００に対して、このブレードＰＣ１６００が接続されるポートにおける全てのトラフィックに対するアクセスを遮断するようにフィルタリング制御を適用し（１３１１５）、その結果を終了成功通知１３１１６として、ユーザ端末Ａ（１２１０２）に対して送信する。この時点で、ユーザ端末Ａ（１２１０２）上では、リモート画面が切断され、完全にセンタ内のリソースにアクセスできなくなる（１３１１７）ため、ユーザＡ（１２１０１）は、これを契機として、ユーザ端末Ａ（１２１０２）での作業を完全に終え、退室しようとする。退室時に、ユーザＡ（１２１０１）は、リーダ１２１０４に入退室カード１２１０３をかざして認証を行い（１３１１８）、その際、入室時と同様に、入退室カード１２１０３の情報が入退室管理サーバ１２１０７に対して送信され（１３１１９）、入室時と同様に、データベース１２１０６を検索することにより、入退室の権限あるユーザであると見なされれば、データベース１２１０６上の本ユーザＡ（１２１０１）のステータスを「入室」から「退室」に更新し（１３１２０）、入退室管理サーバは、退室のためにドアのロックを解除し（１３１２１）、ユーザＡ（１２１０１）は退室を完了する。
【０１１６】
ここまでが、オフィスＡ（１２１００）におけるユーザＡ（１２１０１）のリモートアクセスの手順である。
【０１１７】
次に、この同じユーザＡ（１２１０１）が、同じユーザ端末Ａ（１２１０２）を用いて、別の拠点である、オフィスＢ（１２２０１）に出向き、同じ入退室カード１２１０３を用いて入室し、その場所から同様にリモート接続を試みた場合を説明する。
【０１１８】
ここで、オフィスＢ（１２２０１）内に設置されたリーダ１２２０２、入退室管理サーバ１２２０５、データベース１２２０４、はそれぞれオフィスＡ（１２１００）に設置されたリーダ１２１０４、入退室管理サーバ１２１０７、データベース１２１０６と物理的には異なるものであるが、動作やデータ構造などは同じである。このため、入退室カード１２１０３を用いた認証処理１２２０３は、認証処理１０２０５と同様であり、リーダ１２２０２と入退室管理サーバ１２２０５との通信１２２０６も、リーダ１２１０４と入退室管理サーバ１２１０７との通信１２１０８と同様である。また、各オフィス毎に、入退室の制限は独立して設けられることが考えられるため、データベース１２２０４内の登録情報は、各オフィス毎に異なっていてもよいし、同じであってもよいが、本実施例では、ユーザＡ（１２１０１）に対する個別の設定としては、ユーザＡ（１２１０１）は、オフィスＡ（１２１００）と同様、オフィスＢ（１２２０１）に対しても、入退室の権限を有しているものとする。ここで、データベース１２２０４のデータ構造を図１６に示す。ユーザ識別子カラム、アクセス可否カラム、ステータスカラムについては、図１４のデータベース１４１０１と同様に有しており、ステータスカラムは、その時のユーザ入退室状態によって変化するため、必ずしも図１４のデータベース１４１０４と同じとは限らない。
【０１１９】
但し、データベース１２２０４内の、オフィスＢ（１２２０１）について全ユーザに共通な設定情報であるオフィスＩＤは、オフィスＡ（１２１００）のデータベース１２１０６と異なり、ここでは、「OFFICE-02」という識別子が設定されているものとする。
【０１２０】
ここで図１７は、オフィスＢ（１２２０１）におけるユーザアクセスのシーケンスを示す図である。処理１２２０３、１２２０６、および１７１０１〜１７１０４、１７１１３〜１７１２１は、図１３と同様である。
【０１２１】
図１７において、ユーザ端末Ａ（１２１０２）からのオフィスＩＤの要求１７１０４に対する応答として、入退室管理サーバ１２２０５は、オフィスＩＤ（OFFICE-02）を応答する（１７１０５）。利用要求通知１７１０６では、このオフィスＢ（１２２０１）のオフィスＩＤ（OFFICE-02）を含む通知を送信するため、管理サーバ１７００では、図１５のフィルタリングポリシーで対応する行を検索し、サーバSV-1（１２００）の開示のみ許可できると判断し（１７１０７）、スイッチ１５００に対して、サーバSV-1（１２００）のみ開示するような制御を行う（１７１０８）。その結果、準備完了通知１７１０９、接続１７１１０、リモート画面の表示１７１１１がなされ、最終的にユーザＡ（１２１０１）は、サーバSV-1（１２００）のみアクセスでき、それ以外のサーバであるサーバSV-2、SV-3（１３００、１４００）にはアクセスできない（１７１１２）。
【０１２２】
以上のようにして、オフィス毎に異なるセキュリティポリシーが存在していたとしても、ユーザはそれを意識することなく、尚且つセキュリティレベルも保たれた状態で、適切なアクセス先リソースの開示範囲を制御・提供することができる。
【０１２３】
なお、本実施例では、管理サーバ１７００が存在することを前提とした例示となっているが、本発明の本質から、第５の実施例と組み合わせて実現することができ、すなわち、管理機能は、必ずしも管理サーバ１７００上に実現される必要がなく、エージェントとして各ユーザの中継装置（ここではブレードＰＣ）上に実現されてもよい。その場合、フィルタリングポリシーの設定・変更に関して、必ずしも管理者のみが変更可能である必要はなく、ユーザによる設定・変更が可能であったり、あるいはユーザと管理者、共に設定・変更が可能であったりしてもよいものとする。
【０１２４】
また、本実施例では、入室時および退室時、共にリーダ１２１０４、１２２０２に入退室カードをかざす方式を述べたが、実運用ではこれに限る必要はない。入室時はログを取ることが目的ではなく入室制限をすることが主たる目的であり、カードをかざした方がよい。逆に、退室時は退室制限をすることが目的ではなく、ログを取ることが主たる目的なので、ユーザの手間を考慮すれば、退室時は非接触型が適している。このように入室時と退室時で、リーダの使い方を分けてもよい。入退室カードの他では、例えば指紋情報や静脈情報、虹彩情報などを用いた生体認証がある。
【実施例７】
【０１２５】
以下、第７の実施例として、中継装置の実現方式に関して述べる。本発明では、中継装置に求められる機能は、単にリモートサイトからの接続要求を受け付け、接続を確立し、その延長線上に、複数のアクセス先リソースへのアクセスを提供できるものであれば、特にその実現形態を問うものではない。従って、本中継装置は、物理的な装置として提供されてもよいし、また仮想的な装置として提供されてもよい。仮想的な装置である場合、具体的には、仮想サーバと呼ばれるプラットフォーム上で複数の仮想マシンが動作する実現方式であってもよいし、またサーバベースト型で、複数のユーザ空間に対して、共通リソースとしての業務アプリケーション環境が提供される形態であってもよい。また、物理的な装置である場合、必ずしも、本実施例で紹介しているようなラックマウントタイプのブレードＰＣである必要はなく、一般的なデスクトップタイプのＰＣであってもよい。また、本中継装置に対して、外部ハードディスクとしてストレージ装置などが接続されており、ユーザ環境が拡張された一般にストレージセントリックシステムと呼ばれる形態であってもよい。また、別の形態として、本発明において、接続元であるユーザ端末Ａ（１２１０２）が、自身の内部にハードディスクを持っておらず（今後、このような形態のユーザ端末をディスクレスPCと呼ぶものとする）、インターネット１１０１などのネットワークを介して、管理センタ１１００などのリモートサイトにあるブレードＰＣ１６００などの中継装置内にあるハードディスク、あるいは同様に管理センタ１１００などのリモートサイトにあるストレージ装置内にあるディスク、などからオペレーティングシステムをロードし、起動するような形態の一般にネットワークブートシステムと呼ばれるシステムであってもよい。
【０１２６】
ここで、ユーザは、リモートサイトから、直接的にはアクセス先リソースであるサーバ郡などに対して接続できず、一旦ブレードＰＣなどの中継装置を経由しなければならない構成であってもよいし、また、中継装置を経由しなくても直接アクセス先リソースにアクセスできる構成であってもよい。但し、中継装置を経由せずに直接アクセス先リソースにアクセスできる構成の場合、中継装置内にあるエージェントによってユーザアクセスを監視・管理できないため、本エージェントをアクセス先リソース内に保持し、管理サーバ１７００と通信することによって、ユーザアクセスの経路を提供する。尚、複数のユーザアクセスに対しては、アクセス先リソース内に複数のエージェントを設置してもよいし、１つのエージェントによって、複数ユーザからの要求を受け付けてもよく、いずれにしても、本発明の基本的な処理シーケンスには影響を与えない。
【実施例８】
【０１２７】
以下、第８の実施例として、他の効果を示す事例を示す。上記に説明した実施例に係る発明の本質は、出先にあるユーザ端末、あるいはユーザが置かれたシチュエーションを加味し、リモートサイトにある管理センタ内の情報を、そのシチュエーションに適した範囲で、ユーザに開示することにあるが、この仕組みにより、更に実運用においては、多段アクセスに対するセキュリティ面において、二次的な効果を得る。図１８に、本実施例における基本構成を示す。なお、多段とは、ユーザから見てアクセス先リソースの最終的なターゲットとなるサーバとユーザ間の直列的な多段を意味するものではなく、中継装置の１つとしてのブレードＰＣとユーザ間で、ブレードＰＣ間を乗り継ぐような並列的なアクセスをすることを指す。
【０１２８】
図１８は、図１２のシステム構成をより一般化したものであり、複数のユーザを収容するために、ブレードＰＣ１（１６００）、ブレードＰＣ２（１８２０２）、ブレードＰＣ（１８２０３）、の３つのブレードＰＣが設置されていることを想定する。各ブレードPCは、１台につき、１ユーザの使用が割り当てられているものとする。
【０１２９】
図１８において、正規ユーザA（１２１０１）は、ユーザ端末A(１２１０２)を操作しておらず、本システムには接続していない状態であるとする。図１８では、ユーザA（１２１０１）は、オフィスA(１２１００)内に居るが、本システムにアクセスしていなければ特にユーザA(１２１０１)の居場所は限定しない。
【０１３０】
このとき、ユーザB（１２１０２）が、本システムに対して接続を試みる場合を考える。ユーザＢ（１２１０２）は、正規ユーザであっても、不正ユーザであってもよい。すなわち、明示的に、管理センタ１１００の管理サーバ１７００が管理するフィルタリングポリシー１７０３内に登録された正規ユーザが、管理サーバ１７００に問い合わせて正式に自ブレードＰＣに接続し、その後は多段に異なるブレードＰＣ間を乗り継いで接続することにより、不正な情報開示範囲でのアクセス権限の取得を行う場合であってもよいし、そもそも管理サーバ１７００が管理するフィルタリングポリシー１７０３に登録されていない（未知の）不正ユーザが状況情報そのものを偽って任意のブレードに接続し、そこを拠点として、多段に踏み台を利用することによって、不正な情報開示範囲でのアクセス権限を取得する場合の両方に対して有効な機能である。本実施例では、上記のような様々なケースのうち、正規ユーザが自分のアクセスできる範囲を超えて、許されないリソースに対してもアクセスを行おうとする不正アクセスについて着目するものとする。
【０１３１】
そもそもフィルタリングポリシー１７０３の定義は、ブレードＰＣ１６００、１８２０１、１８２０２に対して付与されるものではなく、状況情報に対して付与される定義である。アクセス元のユーザ端末がこの条件に加算されることがあっても、中継装置であるブレードＰＣが含まれることはない。このため、予めブレードＰＣに対して、直接的に、情報の開示範囲が割り当たることはないが、ユーザが利用するブレードＰＣが固定的に割り当たっている場合、すなわち、正規ユーザＡ（１２１００）が通常利用する中継装置は、ブレードＰＣ３（１８２０２）である、などと固定的に決められている場合については、各ユーザに対する情報開示の範囲が決定された時点で、間接的に、そのブレードＰＣに対して情報開示の範囲が固定的に割り当てられることに相当するようなアクセス制御が行われることになる。
【０１３２】
本実施例での前提条件として、各ブレードＰＣに割り当てられたリソース開示の範囲は異なっており、それぞれ、ブレードＰＣ１（１６００）はサーバSV-1（１２００）のみ開示、ブレードＰＣ２（１８２０１）はサーバSV-1（１２００）とSV-2（１３００）を開示、ブレードＰＣ３（１８２０２）はサーバSV-1、SV-2、SV-3の全サーバ（１２００、１３００、１４００）を開示できるようになっている。また、ユーザＡ（１２１０１）に対しては、ブレードＰＣ３（１８２０２）が割り当てられており、ユーザＢ（１８１０１）に対しては、ブレードＰＣ１（１６００）が割り当てられているものとする。
【０１３３】
ここで、ユーザＢ（１８１０１）は、最初に管理サーバ１７００に対して、利用要求通知１８１０４を送信し、予め自分に与えられた権限である、ブレードＰＣ１への接続を確立すると共に、サーバSV-1（１２００）へのアクセス権限も同時に得る。但し、この状態では、他のサーバに対してアクセスできない。
【０１３４】
このため、ユーザＢ（１８１０１）は、他ユーザ用に設置されたブレードＰＣを乗り継ぎ、よりアクセス範囲を拡大しようとするような不正アクセスを行う。図１８では、ユーザＢ（１８０１０２）は、一旦、ユーザ端末Ｂ（１８１０１）から、インターネット１１０１を介して、ブレードＰＣ１（１６００）に接続し、更に、ブレードＰＣ１（１６００）からブレードＰＣ２（１８２０１）、ブレードＰＣ２（１８２０１）からブレードＰＣ（１８２０２）へのと次々に接続を繰り返し、最終的に全てのサーバに対するアクセス権限を持っており、普段はユーザＡ（１２１０１）によって利用されているはずのブレードＰＣから、スイッチ１５００を介して、許された範囲を超えたサーバに対してアクセスしようとするが、本発明では、ユーザアクセスの際、規定のシーケンスがあり、このシーケンス通りに接続手順を踏まないことには、スイッチのアクセス制御は開放されず、管理センタ内のサーバにアクセスすることはできないという点、および、直前の接続元情報ではなく、出先にある真の接続情報を用いてアクセス制御を施す点、の２点において、上記不正アクセスを行うことができない。
【実施例９】
【０１３５】
次に、第９の実施例として、状況情報の拡充について述べる。第１乃至第８までの実施例においては、状況情報として、真に出先のユーザが置かれた状況に関する状況情報をベースとしたアクセス制御の手法を主に説明している。しかしながら、上記状況情報は、各ユーザのおかれたシチュエーションによって千差万別であるため、統一したポリシーの設定を行うことが難しく、ユーザ数が増大すると、管理者の運用コストが高くなる傾向にある。この問題を解決するために、同じ方向性を持った複数のユーザに対して、一括してフィルタリングポリシーを適用する場合について、本実施例で示す。
【０１３６】
第１乃至第８までの実施例においても、ＩＰアドレスの範囲や、ネットワーク単位や、拠点単位、アクセス目的によってフィルタリングポリシーを定義することにより、単にユーザ毎に個別のＩＰアドレスを定義していく作業に比べてコスト削減を図ることができるが、この作業では、予めシステム全体のネットワーク構成を把握しておく必要があったり、各ユーザのアクセス目的や動的に変化する作業拠点の情報を逐次意識する必要がある。
【０１３７】
本実施例では、ユーザ自身に常に付属してまわる属性情報で、作業拠点やアクセス元のＩＰアドレス、アクセス目的などが変化しても、変化しない情報をベースとしたアクセス制御の手法を述べる。
【０１３８】
状況情報の中には、第１の実施例において、図４に示すように、直接的に位置情報に関わる情報以外にも、スケジュール情報や、出張目的、リソースへのアクセス目的などが挙げられる。このような、直接的な状況情報に付随する二次的な状況情報のことを、ここではメタ状況情報と呼ぶことにする。
【０１３９】
上述のメタ状況情報は、ユーザ単位に設定していくことも可能であるが、同じ業務でああったり、同じ部署やプロジェクトであったりする場合、あるいは同じレベルの職制を持っていたりする場合、同じようなフィルタリングポリシーが設定される傾向が強い。これを利用して、実運用の効率化を図るために、職制情報、および業務種別をベースとしたアクセス制御も同様に行えるものとする。本実施例の実現のためには、次の２つの条件が整っている必要がある。１つは、フィルタリングポリシーの中に、上記２つの情報、すなわち、職制情報と業務種別が入っていること、もう１つは、ユーザ端末が、管理サーバに対して、利用要求通知を送信する際、上記職制情報や業務種別の情報を含めたパケットを送信するか、あるいは、第１の実施例と同様に、ユーザ識別子だけを送信し、これを受けた管理センタ内の管理サーバ側で、ユーザ識別子とメタ状況情報との対応関係（テーブル）を持っており、管理サーバがこのテーブルを検索することによって、アクセス制御を行うこと、この２点が必要である。
【０１４０】
本実施例の効果として、ユーザが作業を行うシチュエーションが変化しても、ある一定期間の間は頻繁に変わらない情報として、前述のメタ状況情報を使っているため、一度登録してしまえば頻繁な情報の更新による管理者やユーザのコストが削減できる上、メタ状況情報としての職制情報や業務種別などの情報は、一般的に既存の管理サーバが管理していることが多く、このような管理サーバと連携することにより、メンテナンスのコストは全く意識する必要がなくなるという効果がある。また、セキュリティポリシーを変更する際は、メタ状況情報のみ変更すれば、これに関連する全てのユーザのアクセス制御を一括変更することが可能である。
【０１４１】
また、本実施例で紹介したメタ状況情報の利用は、アクセス制御における位置情報を絞り込むための状況情報と組み合わせて利用することも可能であり、実現方法としては、フィルタリングポリシーのファイルに、状況情報の条件とメタ状況情報の条件、および、それらの使い方を指示する論理式を、第１の実施例と同様に追加していけばよい。これにより、組織単位でのアクセス制御に加えて、各ユーザのアクセス制御を個別に設定するような、入れ子形式のフィルタリングポリシーを定義することができる。
【実施例１０】
【０１４２】
次に、第１０の実施例を示す。
【０１４３】
既に第８の実施例で、ユーザの多段アクセスについて言及しているが、第８の実施例では、特に正規ユーザ、あるいは不正ユーザによる、不正アクセスに着目したケースの説明であり、通常運用における正規アクセスでの多段アクセスではない。
【０１４４】
本実施例では、通常運用において、踏み台的な使い方ではなく、正規のアクセス経路として、多段に中継装置を乗り継ぐことにより、目的のアクセス先リソースに対してアクセスする使い方を想定しており、このケースにおいても、出先のユーザ端末に対して、適切な範囲での情報開示が保たれることを示すものである。
【０１４５】
第８の実施例との違いは、第８の実施例が、他ユーザの中継装置を乗り継いでいるのに対し、本実施例では、他ユーザの中継装置ではなく、予めユーザに対して割り当てられた複数の中継装置を乗り継ぐ使い方をすることである。
【０１４６】
図１９に、本実施例の基本的なシステム構成を示す。
【０１４７】
管理センタ１１００とオフィスＡ（１２１００）が、インターネット１１０１によって接続されており、管理センタ１１００内には、スイッチ１５００を介して、仮想サーバ１（１９３０１）およびブレードＰＣ１（１６００）が接続されている。ここで、仮想サーバとは、専用のプラットフォーム上で複数の仮想マシンを動作させ、ユーザ個別の環境を提供するためのサーバであってもよいし、またサーバベースト型で、ユーザ個別の環境を設置し、それぞれのユーザ個別の環境に対して、共通リソースとしての業務アプリケーション環境を提供するためのサーバであってもよい。この仮想サーバ１（１９３０１）上では、ユーザ個別の環境の１つである仮想環境１（１９３０２）が動作しており、ユーザは、この仮想環境１（１９３０２）を、ブレードＰＣ１（１６００）やユーザ端末Ａ（１２１０２）や、ブレードＰＣ１（１６００）のような、通常の物理ＰＣでの作業環境と同様に使うことができる。
【０１４８】
次にアクセス手順について説明する。本実施例において、管理サーバ１７００が管理するセキュリティポリシーには、ユーザ１（１２１０１）が、オフィスＡ（１２１００）からアクセスできるリソースは、図１９にある３つのサーバリソース１２００、１３００、１４００のうち、サーバ１２００と１３００、の２つだけに限定して設定されているものとする（１９４０１）。最初にユーザＡ（１２１０１）は、ユーザ端末Ａ（１２１０２）を用いて、管理サーバ１７００に対し、利用要求通知を送信することにより、準備完了通知を応答として受信する（１９２０１）。この時点で、ユーザＡ（１２１０１）は、ユーザ端末Ａ（１２１０２）から、ブレードＰＣ１（１６００）に対してアクセスでき、尚且つ、ブレードＰＣ１（１６００）から、サーバ１２００、１３００に対するアクセス権限も同時に得ることができる。しかしながら、ユーザＡ（１２１０１）は、本システム上に中継装置を複数台所有し、それぞれの中継装置を用途毎に分けて環境構築し、利用している場合が想定される。このような例の１つとして、本システムにおいて、ブレードＰＣ１（１６００）上を通常の作業環境として使い、仮想環境１（１９３０２）を実験環境として使い、仮想環境１（１９３０２）上で、サーバ１２００、１３００上にあるマニュアルを参照しながら、実験を行い、その実験結果を、ブレードＰＣ１（１６００）上で集計・分析を行う、などといった作業を行う場合、作業環境であるブレードＰＣ１（１６００）からサーバ１２００、１３００のデータが参照できるだけでなく、仮想環境１（１９３０２）からもサーバ１２００、１３００のデータが参照できた方が、作業効率の高い仕事をすることができる。
【０１４９】
そこで、ユーザＡ（１２１０１）は、接続先であるブレードＰＣ１（１６００）から、管理サーバ１７００に対して、多段アクセス要求通知１９２０２を送信する。多段アクセス要求通知１９２０２、１９２０３のデータ構造は、図２０に示すデータ構造２０１０１のようになっており、通知種別カラムには、多段アクセス要求を示す識別子として、「CASCADE」が設定され、この通知の送信先として、管理サーバ１７００が設定され、接続のペアを示す情報として、現在居る中継装置のＩＰアドレスと、次に接続したい中継装置のＩＰアドレスの情報を設定したパケットを送信する。これを受けた管理サーバ１７００は、図２１に示すような、多段アクセス管理ファイル１９５０１を参照し、要求元である中継装置と、要求先である次の中継装置のペアが、予め許可されたペアとしてこの多段アクセス管理ファイル１９５０１に定義されているか否かを検索し、既に定義済みであれば、スイッチ１５００に対して、そのアクセスを実現するためのアクセス制御を適用（１９００）し、要求元である現在の中継装置に対して、多段アクセス許可通知を送信する。また、上記ペアが多段アクセス管理ファイル１９５０１に定義されていなければ許可されない不正な要求として、これを却下する。
【０１５０】
現在の中継装置に送信する応答パケットのデータ構造は、図２０の２０１０２に示すような構造を持っており、通知種別として、多段アクセス要求通知に対する応答であることを示す識別子「RESULT_CASCADE」が設定され、通知先には、要求通知にて現中継装置として設定されたいたＩＰアドレスの情報を設定し、準備結果カラムには、上記中継接続の要求に対する承認・却下を示す「YES／NO」が設定され、最後に次中継装置情報カラムには、承認あるいは却下する対象となる接続先中継装置のＩＰアドレスが設定される。
【０１５１】
本実施例では、多段アクセス要求通知により、明示的に次にどの中継装置を経由したいか、現在の中継装置にて把握できているシチュエーションについて例示したが、実際の運用においてはこれに限ることなく、現在の中継装置から、一度管理サーバ１７００に対して、次にどの中継装置を経由したいかの情報を除いて、単に多段アクセスしたい旨を示す多段アクセス要求通知を送信し、これを受けた管理サーバ１７００は、多段アクセス管理ファイル１９５０１を参照することにより、その通知を送信してきたユーザあるいは中継装置が多段アクセス可能な中継装置の一覧をリストアップし、これを応答として現在の中継装置に送信し、現在の中継装置はこの中継装置の一覧の中から、次の作業に適した中継装置を選択して、再度管理サーバ１７００に対して多段アクセス利用の確定要求を送信し、管理サーバ１７００は、この確定要求に含まれる中継装置が前段の処理で応答として送信した中継装置のリストに含まれる場合は、正規の多段アクセスであると判断して、上記次の中継装置に対するアクセスを許可するためのアクセス制御をスイッチ１５００に対して適用する（１９００）方法であってもよい。尚、後述の方法では、中継装置の段数が多い場合や、用途が複雑な場合、あるいは中継可能なアクセス経路が限定されている場合などに対して、有効な使い方と考えられる。
【０１５２】
また、本実施例では、図２０において、多段アクセス要求通知のデータ構造１９５０１内で、現在の中継装置のアドレスを要求元の情報として設定する例を挙げたが、これに限らず、図２１のデータ構造２０１０１に示すような、ユーザ識別子をキーとして、１人のユーザに対して複数の経路番号が割り当てられ、それぞれの経路番号に対して、多段アクセス可能な中継装置の接続の順序を含めた定義が設定されるようなデータ構造のパケットであってもよい。例として、データ構造１９５０１では、ユーザＡに対して、予め２つの多段アクセスの経路が割り当てられており、それぞれ、ブレードＰＣ１ （１６００）から仮想環境１（１９３０２）に対する多段アクセス、ブレードＰＣ１（１６００）から仮想環境２）に対する多段アクセスが許可されていることを示している
２種類の多段アクセス管理ファイルの持ち方、１９５０１と２０１０１において、１９５０１は、中継経路がさほど複雑ではない場合や、また、１つの中継装置を複数ユーザで共有する場合などに有効であり、２０１０１は、中継経路が複雑な場合や、また、１つの中継装置を利用できるユーザが限定されている場合、また、単に直前の中継装置との接続関係だけでなく、第１の中継装置から最後の中継装置までのアクセス経路を総合的に、アクセスの順序も含めて管理したい場合などに有効である。
【０１５３】
また、本実施例では、多段アクセスによる乗り継ぎの終点でリソースにアクセスすることに限定せず、途中の中継装置からも随時アクセス可能できるものであることを説明したが、全ての中継装置に対して個別にフィルタリングポリシーを用意する必要があるわけではない。アクセス元のシチュエーション（状況情報）が同じであれば、途中の中継装置を何段であろうと、どのマシンを経由していようと、開示範囲は同じであるべきであり、管理サーバは、そのユーザが使うよう登録された中継装置からのリクエストであれば、常に同じフィルタリグポリシーを参照・適用するものとする。
【０１５４】
これにより、管理サーバ１７００は、ユーザＡ（１２１０１）の現在の状況情報に対しては、仮想環境１（１９３０２）に対して接続してもよいという判断を下し、結果として、ユーザＡ（１２１０１）は、ブレードＰＣ１６００から、次の接続先である仮想環境１９３０２に対する接続を確立する。
【０１５５】
この時点で、ユーザＡ（１２１０１）は、ブレードＰＣ１（１６００）を介し、直接的にサーバ１２００、１３００に対してアクセスすることもできるし、ブレードＰＣ１６００を介し、仮想環境１（１９３０２）上で、作業を行うこともできるし、仮想環境１（１９３０２）からサーバ１２００、１３００、１４００に対してアクセスすることもできるし、また、図１９には例示していないが、更に次なる多段アクセスのための中継装置を経由して作業を行うことも可能であり、最終的なアクセス先であるサーバ１２００、１３００、１４００と、真のアクセス元であるユーザ端末Ａ（１２１０２）との間に介在する中継装置の個数に制限はなく、何個介在していてもよいし、全く介在せずに直接的にサーバ１２００、１３００、１４００に対して接続する形態のシステムであってもよい。仮想環境１（１９３０２）から更に次なるアクセスのための中継装置を経由する場合は、ブレードＰＣ１（１６００）から仮想環境１（１９３０２）に対して多段アクセスを行った際と同様に、管理サーバ１７００に対して、多段アクセス要求２を送信し、これに対する許可として、多段アクセス許可通知２を受信することにより、段階的に次段の中継装置を経由していくことができる（１９２０３）。
【０１５６】
次に、ユーザＡ（１２１０１）は、ブレードＰＣ１（１６００）および、仮想環境１（１９３０２）を介して、最終的な接続先であるサーバ１２００、１３００、１４００に対して接続するために、管理サーバ１７００に対して、２回目の多段アクセス要求２を送信し、管理サーバ１７００は、多段アクセス管理ファイル１９５０１乃至２０１０１内にその要求が許可される接続先として設定されていることを確認できた場合は、これに対する応答として、多段アクセス許可通知を受信する（１９２０３）。この時点で、ユーザＡ（１２１０１）は、ブレードＰＣ１（１６００）と、仮想環境１（１９３０２）と、スイッチ１５００とを介して、サーバ１２００、１３００、１４００に対するアクセス権限を得ることができる。
【０１５７】
なお、複数の中継装置を経由して、アクセス先リソースに接続する場合であっても、真のアクセス元の状況情報が変わらない以上は、開示すべき情報の範囲、あるいは開示してはならない情報の範囲は、原則として同じであるものとする。
【０１５８】
但し、本実施例の応用的な使い方として、一段目の中継装置上にはオフィス環境を設置し、二段目の中継装置上には実験環境を設置し、これらを共存させながら業務を遂行するような場合、オフィス環境と実験環境で、アクセスできる情報の範囲を変えたい要求が考えられる。この場合、フィルタリングポリシーのテーブル内に、中継装置の種類あるいは利用目的などを定義できるカラムを設け、管理サーバ１７００は、この項目を参照することより、真のアクセス元の状況情報が同じである接続に対しても、どの中継装置から目的のアクセス先リソースに接続を試みているかに応じて、開示できる情報の範囲を動的に制御するような仕組みがあってもよい。
【０１５９】
本実施例では第２の中継装置として、仮想環境を想定したが、その逆の構成、すなわち、第１の中継装置が仮想環境であり、第２の中継装置がブレードＰＣであるようなシステム構成も想定出来る。この場合、単に介在する装置の種類と順序が変化するだけで、本特許の本質的な制御方式に影響するものではなく、同じ機能で対処可能である。また、第１の中継装置をオフィス作業用途として仮想環境を割り当て、第２の中継装置を実験用途としてブレードＰＣを割り当てる場合、そのシステム特性としては、様々な実験を行う場合、その結果として予期せぬ事態を招く危険性があり、その影響が当ユーザに対する影響に留まり、他ユーザに影響させないという特性を持っている。しかしながら、他ユーザへの影響を抑制できる反面、実験マシンのスペックに融通が利かないため、ヴァリエーションの高い実験を行うには、上記２つのシステム構成が混在するような使い方、すなわち、図２２に示すようなハイブリッドタイプのシステム構成も想定可能であり、前述のように、本システムにおいても本実施例と同じ処理フローで対応できる。
【実施例１１】
【０１６０】
次に、第１１の実施例として、メンテナンス機能について述べる。
【０１６１】
既に、第４の実施例おいて、複数の状況情報に対するフィルタリングポリシー１７０３に論理的な矛盾があるか否かを監査するような機能について述べている。
【０１６２】
但し、第４の実施例で監査している論理的な矛盾の対象は、フィルタリングポリシーの記述内容そのものであり、実運用においては、この監査に加えて、更に、論理的なフィルタリングポリシーと、そのフィルタリングポリシーが指示している物理的な実際のリソースとの間に矛盾がないかを監査する機能が必要となる。
【０１６３】
運用管理者あるいはユーザによるメンテナンス作業という観点に基づき、本システムは、次に示すような、３つの機能を有しているものとする。本機能は、管理サーバ１７００の有するアクセス制御機能１７０２が担うことを想定するが、フィルタリングポリシー１７０３と、物理リソースであるサーバ１２００、１３００、１４００とにアクセス可能な場所であれば、特に設置場所に対して制限するものではない。
【０１６４】
第１のメンテナンス機能として、アクセス先リソースが追加された場合、すなわちサーバやフォルダ、ファイルやネットワークなどが追加された場合、この変化を管理者あるいはユーザに対して通知し、フィルタリングポリシー１７０３に対して、今後新たな条件を追加可能であることを教える機能を有する。この通知を受けて、管理者あるいはユーザは、フィルタリングポリシーの追加が必要であるか否かを判断する契機を得、必要であればフィルタリングポリシーを追加することにより、遊休リソースの発生を最小限に抑制することができる。
【０１６５】
第２のメンテナンス機能として、アクセス先リソースが変更された場合、すなわちサーバやフォルダ、ファイルやネットワークなどのマイグレーションが行われた場合、例えば、サーバの格納情報は同じだが、新しいサーバに乗り換えてIPアドレスやサーバ名が変わった場合など、フィルタリングポリシー１７０３における該当行のIPアドレスやサーバ名を自動修正する機能を有する。
【０１６６】
第３のメンテナンス機能として、アクセス先リソースが削除された場合、すなわちサーバやフォルダ、ファイルやネットワークなどが削除された場合、この変化をフィルタリングポリシー１７０３に対して、フィードバックを掛ける機能を有する。フィードバックの掛け方としては、フィルタリングポリシー１７０３内を検索し、該当する行を発見した時点で、該当する行自体を削除するか、該当する行は残しておいてアクセス不可に変更するか、あるいは単にコメント行として制御のための情報ではなくするか、のいずれであってもよい。
【０１６７】
ここまでの説明で、本システムに対するアクセス先リソースの追加・変更・削除に関する機能およびアクションを述べた。次に、本アクションが発動するためのトリガーとして必要なエージェント機能について述べる。
【０１６８】
本実施例における第１乃至第３のメンテナンス機能の実現のために、ソフトウェアエージェントによるアクセス先リソースの資産管理と状態監視を行うものとする。管理者あるいはユーザは、本システムに対して、アクセス先リソースとしての機器を新規に導入する際、必ず上記ソフトウェアエージェント（以降、資産管理エージェントと呼ぶ）をインストールするような運用を行う。
【０１６９】
資産管理エージェントは、次に示す５つの機能を有している。
【０１７０】
１つ目の機能として資産管理エージェントは、マシンを初期導入するため、資産管理エージェントのインストールを行った際に、インストール先マシンの固有情報として、マシン識別情報（資産管理ＩＤ、ＩＰアドレス、サブネットマスク、ＭＡＣアドレス、ホスト名など）と、マシンスペック情報（ＣＰＵタイプ、ＣＰＵ処理速度、ディスク容量、メモリ容量、ネットワーク帯域など）と、更に管理情報（インストール年月日、インストール者あるいは機器管理者など）を含む、マシン追加通知を、管理サーバ１７００に対して送信する。上記通知に含まれる情報のうち、資産管理ＩＤとは、資産管理エージェントが独自に管理する情報であり、管理者あるいはユーザが資産管理エージェントをインストールする際に、資産管理エージェントのインストーラおよび管理サーバ１７００が連携して自動採番する本システム内で一意の識別子である。資産管理エージェントは、この一意性を確保するため、本システム内に設置された管理サーバ１７００に対して、資産管理ＩＤの発行を申請する。ここで、管理サーバ１７００は、システム内に設置された資産管理エージェントに対して発行し現在使用中である資産ＩＤのリストをファイルやデータベースなどに記録しておくことで管理しておく。上記資産管理ＩＤの発行申請を受けた管理サーバ１７００は、内部で管理する資産管理ＩＤを検索し、既存の資産管理ＩＤとの重複がないように、新たな資産管理ＩＤを生成して、上記資産管理エージェントに対して、この新たな資産管理ＩＤを発行する。
【０１７１】
２つ目の機能として資産管理エージェントは、資産管理エージェントのインストール後に、フォルダ、ファイル、ネットワークインタフェースなどが追加された場合、追加されたフォルダ名、ファイル名、ネットワークインタフェース名（および番号）を含むマシン内リソース追加通知を、管理サーバ１７００に対して送信する。管理サーバ１７００は、上記マシン内リソース追加通知を受けた時点で、該当するリソースの定義を、フィルタリングポリシー１７０３に追加することができる旨、管理者あるいはユーザに対して、ポップアップメッセージやメールなど、可読形式のメッセージとして通知する。
【０１７２】
また、サーバ内の格納情報（論理リソース）は変わらないが、これを搭載するサーバ（物理リソース）が変化する場合、例えば、システムの増改築に伴うサーバのマイグレーションなど、においては、資産管理エージェントに設定済みの資産管理ＩＤの付け替えを行うことにより、新しい物理リソースが追加されたが、特にフィルタリングポリシーの修正が必要ではないことを管理サーバ１７００に対して通知する。具体的には、サーバ１２００からサーバ１３００に対してデータを移動する際、サーバ１２００および１３００の両方に対して資産管理エージェントをインストールしておき、サーバ１２００上のデータをサーバ１３００に移動させた後で、サーバ１２００上の資産管理エージェントから、マイグレーションの申請を、管理サーバ１７００に対して行う。ここで、管理サーバ１７００は、本システム内に設置された資産管理エージェントに設定された資産管理ＩＤに対して、参照・変更・削除などの権限を有するものとする。本マイグレーション申請のパケットには、マイグレーション元となるサーバのＩＰアドレスと資産管理ＩＤ、およびマイグレーション先のＩＰアドレスと資産管理ＩＤが含まれており、この申請を受取った管理サーバ１７００は、マイグレーション元となるサーバ１２００の資産管理エージェントに設定された資産管理ＩＤ（以下、旧資産管理ＩＤと呼ぶ）を、新規の資産管理ＩＤに更新した上で、即時的に、マイグレーション先のサーバ１３００の資産管理ＩＤを、旧資産管理ＩＤに更新する。これにより、ユーザから見れば、物理的なサーバのマイグレーションが行われたことは特に意識する必要がなく、従来通りに接続でき、ビジネス継続性を維持できると共に、管理者から見れば、フィルタリングポリシーを特に変更することなく、資産管理情報だけ更新することが可能となる。
【０１７３】
３つ目の機能として資産管理エージェントは、資産管理エージェントのインストール後に、フォルダ、ファイル、ネットワークインタフェースなどが変更（編集）された場合、編集されたフォルダ名、ファイル名、ネットワークインタフェース名（および番号）を含むマシン内リソース変更通知を、管理サーバ１７００に対して送信する。管理サーバ１７００は、上記マシン内リソース変更通知を受けた時点で、該当するリソースの定義を、フィルタリングポリシー１７０３に反映し、これを反映した事を管理者あるいはユーザに対して、ポップアップメッセージやメールなど、可読形式のメッセージとして通知する。尚、上記のようなリソースの変更により、リソースの名称は変わっているが、その実体は変わっていない場合、あるいは、リソースの名称は同じでも、その実体が変わっている場合、リソースの名称もその実際も共に変わっている場合、編集されたがデータは元に戻っている場合、など様々な結果を想定することができる。いずれにしても、リソースの変更により、それ自体が持つセキュリティレベルが、当初セキュリティポリシー１７０３を設定していた時点とは変わる可能性がある。運用の都合上、上記のようにリソースに変更が掛けられた際、単にフィルタリングポリシーの定義にこれを反映するだけでなく、セキュリティレベルが変わった可能性を加味して、管理者あるいはユーザに対して、再度ポリシーの策定を促すような通知を、ポップアップメッセージやメールなど、可読形式のメッセージとして通知する。
【０１７４】
４つ目の機能として資産管理エージェントは、資産管理エージェントのインストール後に、フォルダ、ファイル、ネットワークインタフェースなどが削除された場合、削除されたフォルダ名、ファイル名、ネットワークインタフェース名（および番号）を含むマシン内リソース削除通知を、管理サーバ１７００に対して送信する。管理サーバ１７００は、上記マシン内リソース削除通知を受けた時点で、該当するリソースの定義を、フィルタリングポリシー１７０３から除外し、これを除外した事を管理者あるいはユーザに対して、ポップアップメッセージやメールなど、可読形式のメッセージとして通知する。
【０１７５】
５つ目の機能として資産管理エージェントは、マシンを本システムから除外するため、資産管理エージェントのアンインストールを行った際に、アンインストールマシンの固有情報として、マシン識別情報（資産管理ＩＤ、ＩＰアドレス、サブネットマスク、ＭＡＣアドレス、ホスト名、など）と、管理情報（アンインストール年月日、アンインストール者あるいは機器管理者、など）を含む、マシン削除通知を、管理サーバ１７００に対して送信する。管理サーバ１７００は、資産管理ＩＤの整合性を確保するため、上記マシン削除通知を受取った時点で、該当する資産管理ＩＤを、前述の資産ＩＤのリストから削除する。これにより、ユーザがアクセス可能とされているサーバに対してアクセスを試みたが、アクセス先のサーバは既に廃止済みでアクセスできない、などという障害を事前に避けることができる。更に管理サーバ１７００は、通知を受けたリソースに対して、フィルタリングポリシー１７０３内を検索し、該当する行を発見した時点で、該当する行自体を削除するか、該当する行は残しておいてアクセス不可に変更するか、あるいは単にコメント行として、制御のための情報ではないものとするか、予め管理者あるいはユーザによって策定された、これらいずれかの手段により、リソースの削除をフィルタリングポリシー１７０３にフィードバックする。
【実施例１２】
【０１７６】
次に、第１２の実施例として、モバイル対応として応用するための使い方について例示する。
【０１７７】
第１の実施例では、本発明の基本的なシステム構成として、自社内インフラだけで独立して運用できる実施形態を述べた。しかしながら、ユーザのアクセス形態は多岐に渡り、必ずしも自社内インフラだけで対応できるとは限らない状況にあるといえる。例えば、本発明の主眼は、出先のシチュエーションに応じて、ユーザに開示する情報の範囲を動的に制御する点にあるが、第１の実施例では、このシチュエーションの判断が、ユーザからの利用要求通知１９０２を受けたことが契機となっている。しかしながら、最初に利用要求通知１９０２を送信し、これ対する適切な情報の開示範囲が決定されて後、ユーザが場所を移動しないとは限らない。このため、一度決定した情報開示の範囲では、次の移動場所において、既に適切な開示範囲ではなくなっている可能性が考えられる。
【０１７８】
このため、ユーザが任意のタイミングで、移動しながらでも、常に適切な情報の開示範囲を制御し、ユーザに対するリソースへのアクセス経路を確保するために、本実施例において、本システムは、次に示す２つの機能を持つものとする。
【０１７９】
１つ目は、現在位置のリアルタイムな検出であり、２つ目は、検出した位置情報に基く、自動再接続である。
【０１８０】
現在位置のリアルタイムな検出方法としては、アクセス制御を行うのに必要な粒度での位置（座標）情報が取得できる方法であれば特に手段を限定するものではないが、一例として、ユーザ端末１８００自らがＧＰＳ（Global Positioning System：全地球測位システム、以下、ＧＰＳと呼ぶ）機能を搭載していて、定期的に管理サーバ１７００に対して、その位置情報を送信するようにしてもよいし、また、ユーザ端末１８００において、位置情報の検出結果が、情報開示範囲の定義として予め設定された範囲である閾値を超えて移動された場合にのみ、管理サーバ１７００に対してその結果を送信するようにしてもよい。また、ユーザ端末１８００自身がＧＰＳ機能を内蔵していなくとも、ユーザ端末１８００と管理サーバ１７００との間に介在するインターネット１１０１の経路を提供している電気通信事業者（一般にキャリアと呼ばれている）と提携し、アクセスポイントの情報を提供してもらうことにより、間接的に位置情報を知る方法であってもよい。尚、最後の方法は、アクセスポイントの位置が物理的に特定できるために実現できる方法である。
【０１８１】
次に、検出した位置情報に基く自動再接続の方法としては、上記検出された位置情報の変化（移動）を契機として、再度、利用要求通知１９０２を、管理サーバ１７００に対して送信することにより、図５に示す接続シーケンスを再実行する。尚、最初の接続シーケンスと、２回目以降に移動によって発生した接続シーケンスとの間には、位置情報と含む状況情報の違い以外は変わりがないため、特に管理者やユーザの判断が新たに発生する必要はなく、第１の実施例と同様に接続を開始することができる。また、バックグラウンドで再接続処理が実行されるため、ユーザから見れば、特に切断と再接続が行われたことを意識することなく、ビジネス継続性やユーザビリティを損なうことがない。
【０１８２】
また、上記再接続処理に関して、移動あるいは障害による切断なのか、ユーザの作業が終了したことによる切断なのかを判別する機能が必要であり、この機能がない場合、例えば、障害なく作業できている状態で、単にユーザが移動しただけであるのに、作業終了と誤って認識され、自動再接続が行われなかったり、逆に正常に作業を終了しているにも関わらず、本人が離席中に勝手に接続が回復されているような問題が発生する可能性がある。このため、本実施例においては、移動や障害による切断と、明示的な作業の終了に違いについて、図５に示す終了要求通知Ｓ９の受信の有無によって判断するものとする。管理サーバ１７００が、ユーザ端末１８００から、終了要求通知Ｓ９を受信していないにも関わらず、セッションが切断されてしまった場合、管理サーバ１７００はこれをユーザの移動あるいは障害による一時的な切断と判断し、上記自動再接続を実施する。逆に、管理サーバ１７００が、ユーザ端末１８００から、終了要求通知Ｓ９を受信済みの状態で、セッションが切断された場合、管理サーバ１７００はこれをユーザによる明示的な作業終了の意思があるものと判断し、本人不在中のセキュリティ確保のためにも、自動再接続の処理は実施しないようにする。
【実施例１３】
【０１８３】
次に、第１３の実施例として、本システムへのリモートアクセスの手段について、拡張を行う場合の管理サーバ１７００の機能拡張について述べる。
【０１８４】
これまでの実施例において、ユーザ端末から本システム内のアクセス先リソースに対するリモートアクセスの手段は、ＲＤＰ（Remote Desktop Protocol）に代表されるような画面転送のプロトコルを用いた手段を例示していたが、アクセス時のシチュエーションに応じて情報開示の範囲を動的に制御するという本発明の趣旨を鑑みれば、リモートアクセスの手段を、特に画面転送によるものに限定する必要はない。ユーザは、例えば、アクセス先リソース内の共有フォルダのファイルに対して、直接的に出先のユーザ端末からアクセスして、出先のユーザ端末上の本ファイルの内容を展開するような使い方もできるし、出先のユーザ端末から、アクセス先リソースのあるサーバに対して、直接的にＴＥＬＮＥＴ（ＲＦＣ８５４にて定義された標準的なＩＰネットワークにおけるリモート端末との通信プロトコル）などのプロトコルによって接続をするような使い方もできる。
【０１８５】
上記のような使い方をする場合、管理サーバ１７００は、次の２点につき、機能拡張を行う必要がある。
【０１８６】
１つ目は、管理サーバ１７００は、自身が管理するテーブルとして、フィルタリングポリシー１７０３内に、リモートアクセスサービスの種類、あるいはプロトコル名称などを定義するカラム（以下、フィルタリング対象サービスカラムと呼ぶ）を設けること。
【０１８７】
２つ目は、上記フィルタリングポリシー１７０３を読み込み、尚且つこの情報を用いてスイッチ１５００に対してアクセス制御の要求を行うフィルタリング制御モジュール５００３が、上記フィルタリング対象サービスカラムて定義してある情報を読み込み、この情報を用いて、フィルタリング対象サービスカラムのプロトコル名称(種別)に対して、ポート開閉定義を施すようなＡＣＬを生成すること。
【０１８８】
管理者あるいはユーザは、上記のような使い方を行う際、上記フィルタリング対象サービスカラムに対して、アクセス制御の対象となるプロトコルを、例えば、画面転送を実現するＲＤＰプロトコルから、ＴＥＬＮＥＴプロトコルに変更するだけでよく、上記の機能拡張以外に、本機能の実現においてシステム拡張を行う必要はなく、第１の実施例において紹介した機能をそのまま転用することができる。
【実施例１４】
【０１８９】
次に、第１４の実施例として、状況情報の拡充について述べる。本実施例においては、第９の実施例で述べたような、メタ状況情報とは異なり、直接的に正に今確立されているユーザアクセスに関わる状況情報そのものについて拡充を図るものである。
【０１９０】
これまでの実施例のおいて、接続元の状況情報として、要約すれば、「誰が」「どこから」アクセスしてきているのか、という情報をリアルタイムに取得することができた。スケジュール情報などのメタ状況情報を加えると、これに「いつから」「いつまで」「なんの目的で」などの情報がこれに修飾されることになる。これに対して、状況情報そのものの精度を上げることにより、更なるセキュリティ強化を図るのが本実施例の意図であり、上記のようにして取得できる状況情報に関して、「どのマシンを用いて」「どのアクセス先リソースに対して」アクセスするのか、という状況情報を拡張するものである。
【０１９１】
ユーザあるいは管理者が、明らかにユーザのアクセス先リソースの範囲を予め分かっている場合は、明示的にどのリソースに対してアクセスする必要があるのかを、ユーザ側からの告知により知り得るか、あるいは、セキュリティやメンテナンスなどの目的により、管理者がアクセス範囲を制限する際に、管理者からの設定により知り得るか、のいずれかの方法により知り得たアクセス範囲の情報を元にして、予め許可されているアクセス範囲の中にあって、尚且つその全てを公開せず、その接続に関わる必要最低限の開示範囲に制限して開示するものである。これにより、アクセス許可はあるが、今すぐにはアクセスしないにも関わらず、公開されるようなリソースが発生せず、ユーザは安心して出先においても作業を行う事ができる。
【０１９２】
図２４に、本実施例の基本的なシステム構成を示す。
【０１９３】
管理センタ１１００内には、セキュリティベルの異なる複数のサーバ、サーバSV-1（１２００）、サーバSV-2（１３００）、サーバSV-3（１４００）、が設置されており、それぞれのセキュリティレベルを仮に、高、中、低、とする。このセキュリティレベルとアクセス先リソースの対応関係は、管理サーバ１７００が管理するフィルタリングポリシー１７０３の情報の一部として管理されていてもよいし、別の設定ファイルとして管理サーバ１７００内にあってもよい。このセキュリティレベルの指定は、上記設定ファイル内において、次の２つの方式のいずれかによってなされる。１つ目は、個々のＩＰアドレスにより、アクセス先リソースとなるサーバを１台ずつ指定していく方法であり、２つ目は、ＩＰアドレスの範囲を指定することにより、複数のサーバをまとめて指定する方法である。本セキュリティレベルは、サーバ自身に対して割り当てられるセキュリティレベルであってもよいし、ユーザがアクセスできるデータに対して割り当てられるセキュリティレベルであってもよい。また、アクセス元となるオフィスＡ（１２１００）内には、ユーザＡ（１２１０１）が居り、目的に応じて、複数のマシン、マシンＡ（２４１０１）、マシンＢ（２４１０２）、マシンＣ（２４１０３）を使い分けながら、アクセス先リソースへのアクセスを試みているものとする。このとき、作業端末となるマシンは、様々なバリエーションが想定される。マシンＡ（２４１０１）は、本体にハードディスク装置を内蔵しておらず、リモートサイトに設置されたハードディスク装置に対して接続して利用することによって、作業履歴となるアプリケーションデータやログファイルなどを手元の端末に残さないタイプのセキュリティレベルの高いマシンである。また、マシンＢ（２４１０２）は、個人毎に配布され、本体にハードディスク装置を内蔵している普通のタイプのＰＣであり、セキュリティレベルも普通のマシンである。また、マシンＣ（２４１０３）は、出先のオフィスにおいて、共用として使われるマシンであり、複数の不特定ユーザが利用するという意味において、本実施例では、セキュリティレベルの低いマシンとして扱う。
【０１９４】
ユーザＡ（１２１０１）は、本システムに接続する際、第１の実施例と同様のシーケンスにて、接続を試みる。但し、第１の実施例における利用要求通知１９０２は、図３に示す、通知種別と通知先、そしてただ１つの状況情報のみを有するようなデータ構造であるが、本実施例では、これを図２５に示すような利用要求通知２５１０１、すなわち通知種別と通知先、そして複数の状況情報を有するようなデータ構造に拡張する。具体的には、上記複数の状況情報は、接続元マシンのＩＰアドレス、アクセス元マシン種別、アクセス先リソースの範囲、そして、アプリケーションセキュリティのカラムから構成される。これらのカラムは、最低１つあればよく、必ずしも全てのカラムが揃っている必要はない。運用のシーンに併せて、管理者は必要なカラムを増減して設定することができる。
【０１９５】
以下、それぞれのカラムについて説明する。接続元マシンのＩＰアドレスカラムには、第１の実施例と同様、マシンＡ（２４１０１）、マシンＢ（２４１０２）、マシンＣ（２４１０３）のうち、いずれかただ１つのマシンについて、現在利用中のマシンのＩＰアドレスの値が入る。アクセス元マシン種別カラムには、マシンＡ（２４１０１）なら、ディスクレスＰＣを表す識別子「PC_TYPE_A」が入り、マシンＢ（２４１０２）なら、ディスク付きＰＣを表す識別子「PC_TYPE_B」が入り、マシンＣ（２４１０３）なら、共用PCを表す識別子「PC_TYPE_C」が入る。アクセス先リソースの範囲カラムには、次の２つの方式のいずれかによって、現在ユーザがアクセスを希望するリソースの範囲を指定する。１つ目の方式として、接続元マシンの指定と同様に、IPアドレスを複数指定することにより、限られた複数のリソースについて開示を求める方法がある。また、２つ目の方式として、セキュリティレベルを指定することにより、これに該当するリソースに限られた複数のリソースについて一括して開示を求める方法がある。また、アプリケーションセキュリティカラムは、セキュリティソフトの導入状況や、ウィルスチェック結果、不正ソフトのインストール状況など、アプリケーションレベルでのセキュリティ対策の実施状況を総合的に判断してレベル付けした結果が入る。尚、この判断は、ユーザＡ（１２１０１）が利用するユーザ側のマシン、マシンＡ（２４１０１）、マシンＢ（２４１０２）、マシンＣ（２４１０３）の個々について、それぞれ上記セキュリティ対策の実施状況を判定し、これを管理サーバ１７００に対して通知するようなソフトウェアエージェントを有し、管理サーバはこれを受動的に受取るような仕組みであってもよいし、また、ユーザ側のマシンにはソフトウェアエージェントが入っていない代わりに、利用要求通知２５１０１を受取ったことを契機として、管理サーバ１７００から、能動的にユーザ側のマシンに対してセキュリティレベルの監査をリモートで実施するような仕組みであってもよい。また、個々のセキュリティレベルの監査の基準は、上記ソフトウェアエージェントが設定ファイルとして有していてもよいし、あるいは、管理サーバ１７００がフィルタリングポリシー１７０３の一部として有していてもよい。
【０１９６】
また、アクセス元マシン種別、アクセス先リソースの範囲、アプリケーションセキュリティ、の各セキュリティティレベルにつき、最終的にアクセス先リソースの開示を行う際は、これらのうち、最も低いセキュリティレベルを規準として、情報を開示するものとする。例えば、アクセス元マシン種別が、「PC_TYPE_A」であって、「PC_TYPE_A」が最もセキュリティレベルが高いと設定されており、アクセス先リソースの範囲が「HIGH」であるが、アプリケーションセキュリティが「LOW」である場合、使用しているマシンと開示要求は最もセキュリティレベルの高いものであるが、アプリケーションセキュリティの対策が不十分であると判断して、実際に開示する情報は、セキュリティレベル低「LOW」の情報までとする。
【０１９７】
尚、本実施例で拡張が必要となる通知は、上述の利用要求通知２５１０１のみであり、準備結果通知１９０４、終了要求通知１９０３、及び終了結果通知１９０５に関しては、第１の実施例と同じデータ構造を用いるものとする。
【０１９８】
本実施例において、ユーザＡ（１２１０１）は、オフィスＡ（１２１００）から接続する際、どのマシンを用いても、常にＩＰアドレス：iii.jjj.kkk.lllを用いてアクセスするものとする。また、フィルタリングポリシー１７０３には、ＩＰアドレス：iii.jjj.kkk.lllからのアクセスに対しては、管理センタ１７００にあるサーバSV-1（１２００）、SV-2（１３００）、SV-3（１３００）の全てのサーバが、開示されるようなフィルタリングポリシー１７０３初期設定が、管理者あるいはユーザによって、なされているものとする。
【０１９９】
また、接続元マシンのセキュリティレベルのみ指定した場合のアクションの例として、指定されたセキュリティレベル以下のリソースに対してのみアクセスできるようなフィルタリングポリシー１７０３の設定が考えられる。本実施例では、セキュリティレベル高のマシンは、サーバ高、中、低の全てに対してアクセスでき、セキュリティレベル中のマシンは、サーバ中と低の２つだけにアクセスでき、また、セキュリティレベル低のマシンは、サーバ低のみにアクセスできるものとする。
【０２００】
このとき、ユーザＡ（１２１０１）が、セキュリティレベルの最も高いマシンである、マシンＡ（２４１０１）を用い、セキュリティレベルの最も低いサーバであるサーバSV-3（１４００）に対してのみ接続したいケースを想定する。
【０２０１】
以下に、基本的な処理シーケンスを説明する。
【０２０２】
ユーザＡ（１２１０１）がマシンＡ（２４１０１）から、アクセス元マシンのＩＰアドレスとして、マシンＡ（２４１０１）のＩＰアドレス、アクセス元マシン種別として「PC_TYPE_A」、アクセス先リソースの範囲として「LOW」、アプリケーションセキュリティとして、「HIGH」が設定された利用要求通知２５１０１を送信し、これに対する準備結果通知１９０４を受取った時点で、ユーザＡ（１２１０１）は、マシンＡ（２４１０１）から、フィルタリングポリシー１７０３には、全てのサーバにアクセスできるような設定がなされてあるにも関わらず、現在利用することを告知された最もセキュリティレベルの低いサーバSV-3（１４００）にのみアクセスできるようになる。
【０２０３】
次に、ユーザＡ（１２１０１）がマシンＢ（２４１０２）から、アクセス元マシンのＩＰアドレスとして、マシンＢ（２４１０２）のＩＰアドレス、アクセス元マシン種別として「PC_TYPE_B」、アクセス先リソースの範囲としてサーバSV-2（１３００）のＩＰアドレス、アプリケーションセキュリティとして、「MIDDLE」が設定された利用要求通知２５１０１を送信し、これに対する準備結果通知１９０４を受取った時点で、ユーザＡ（１２１０１）は、管理者に依頼するなどしてフィルタリングポリシーを変更してもらうことなく、マシンＢ（２４１０２）のセキュリティレベルに応じたリソースの開示範囲であるサーバSV-2（１３００）とSV-3（１４００）のうち、現在利用することを告知されたサーバSV-2（１３００）にのみアクセスすることができる。
【０２０４】
次に、ユーザＡ（１２１０１）がマシンＣ（２４１０３）から、アクセス元マシンのＩＰアドレスとして、マシンＣ（２４１０３）のＩＰアドレス、アクセス元マシン種別として「PC_TYPE_C」、アクセス先リソースの範囲として「MIDDLE」、アプリケーションセキュリティとして、「MIDDLE」が設定された利用要求通知２５１０１を送信し、これに対する準備結果通知１９０４を受取った時点で、ユーザＡ（１２１０１）は、フィルタリングポリシーを変更することなく、マシンＣ（２４１０３）から要求のあったリソースの開示範囲であるサーバSV-2（１３００）とSV-3（１４００）のうち、サーバSV-3のみに対してアクセスすることができる。ユーザから明示的にアクセス範囲を告知することによって、必要最低限の範囲に絞り込んで情報を開示することができる反面、ユーザの告知が間違っている場合、必要以上に情報が開示されてしまう危険性があるため、この例のように、複数のセキュリティレベルの項目を総合的に判断することによって、ユーザの告知が間違っている場合においても、適切な開示範囲にて情報を開示するものである。
【０２０５】
以上のように、アクセス元とアクセス先の組合せで、幾つかのパタンを挙げてきたが、本実施例は、アクセス権限と使い方の組合せを考慮し、ネットワーク、アクセス先マシンの物理（サーバ単位でのセキュリティの運用ポリシー）・論理（データそのもののセキュリティ性）、アクセス元マシンの物理（マシン種別）・論理（アプリケーション）、などについて、多面的に状況情報を判断することによって、必要最低限での開示を実現するものである。これは、出先で、顧客などと共に、同じ端末の画面を囲んで、デモや資料作成などを行っている際などに情報漏えい対策として有効な機能である。
【実施例１５】
【０２０６】
次に、第１５の実施例として、マルチユーザ対応について説明する。これまでの実施例において、中継装置となるブレードＰＣは、１台につき１ユーザが占有することを前提として説明してきた。しかしながら、運用の一形態として、設備投資削減などの目的から、複数のユーザでブレードＰＣをシェアするような使い方も想定できる。このようなケースにおいても、ユーザ毎に独立した最適な情報開示が行うことができる仕組みについて以下に説明する。
【０２０７】
複数のユーザでブレードＰＣをシェアするような使い方には、大別すると、次の２つのパターンが考えられる。１つ目のパターンとして、同時に複数のユーザはアクセスしないが、入れ替わり立ち代り、異なるユーザからの接続を受け付けるような使い方（以下、時分割アクセスと呼ぶものとする）が考えられる。また、２つ目のパターンとして、常に複数のユーザからのアクセスを受け付けるような使い方（以下、多重アクセスと呼ぶものとする）が考えられる。以下、それぞれのパターンについて、本発明に必要となる拡張機能について述べる。
【０２０８】
上記時分割アクセスにおいて、ブレードＰＣに対して、一度にアクセスするユーザ数は１人だけなので、ユーザアクセスの経路を識別するためには、アクセス中のブレードＰＣとアクセス先リソースの対応関係だけ把握していれば、識別することができる。このため、特に拡張機能は必要ない。
【０２０９】
上記多重アクセスにおいて、ブレードＰＣに対して、一度にアクセスユーザ数が複数人であるため、単にアクセス中のブレードＰＣとアクセス先リソースの対応関係だけ把握していても、ユーザアクセスの経路を識別することができない。このようなケースにおいては、マシン単位ではなく、セッション単位での経路の識別が必要となる。本ケースでは、管理サーバ１７００は使わず、リソース開示範囲制御エージェント８２００を使って制御を行う。リソース開示範囲エージェント８２００が有するフィルタリングモジュール１０３０６は、ユーザとユーザセッションとマシンとポートの対応関係を把握している。具体的には、各ブレードに接続してきたユーザアクセスのセッション情報を検出し、各セッションがそれぞれどの論理ポートあるいは物理ポートを用いて、アクセス先リソースとの通信を行っているかを把握している。これにより、同じブレードＰＣに対して、複数のユーザから利用要求通知が送信された場合、フィルタリングモジュール１０３０６は、ファイアウォール８３００に対して、ポート単位で各ユーザに対するアクセス制御を行うことにより、同じブレードＰＣにアクセスしていても、あるユーザアクセスのセッションに対しては、サーバSV-1（１２００）しか開示しないが、別にユーザアクセスのセッションに対してはサーバSV-1（１２００）、SV-2（１３００）、SV-3（１４００）を開示する、というようなことができる。
【実施例１６】
【０２１０】
次に、第１６の実施例として、第６の実施例で示した使い方を更に拡張する例を示す。第６の実施例では、位置判定手法の拡充として、各拠点で入退室管理サーバ１２１０７や１２２０５などが管理するオフィスＩＤにより、ユーザがどの拠点から接続してきているのかという情報に基き、情報の開示範囲を制御する機能を例示した。本実施例では、第６の実施例により、上記オフィスＩＤの管理がなされたシステムであることを前提として、同じユーザからの接続が異なるオフィスから試みられた場合の対処について説明する。
【０２１１】
本来、ユーザ識別子は、ユーザを一意に識別するための識別子であり、複数あってはならない情報であるべきであるが、何らかの原因により、攻撃者からユーザ識別子を複製され、ユーザ識別子が複数存在する状況に陥った場合、不正アクセスが発生する可能性がある。具体的には、ユーザ識別子は、例えば電子証明書などのデータの中に組み込まれる可能性が高いと考えられる。このため、正規ユーザの電子証明書がファイルとして、何らかの原因により漏えいしてしまう可能性が考えられ、このような場合、攻撃者が上記証明書の複製を所有する事態が想定できる。この場合、正規ユーザと攻撃者が同じ証明書（同じユーザ識別子）を用いて利用要求通知１７０２を送信してくるため、そのままでは管理者は正規ユーザと攻撃者の区別をすることができない。このような、本来1つしか存在し得ないユーザ識別子によって、複数が同時に接続されている疑わしい状況に対して、フィルタリング制御モジュール５００３によって、次の２つの対処のうちいずれを行ってもよい。
【０２１２】
１つ目は、疑わしい両接続を共に切断すると共に、管理者に対して、不正アクセスがあった旨を伝える通知を送信する。
【０２１３】
２つ目は、そのままでは疑わしい両接続に対して、メタ状況情報との突合せを行うことにより、正規ユーザと攻撃者の識別を行い、両接続共を破棄するのではなく、正規ユーザの接続だけ残して、攻撃者の接続だけを破棄する仕組みである。具体的には、出張申請やスケジュール情報と照合して一致を確認することにより、同じユーザ識別子であっても、本来の接続元として正しいオフィスＩＤはどちらの利用要求通知１７０２に含まれているのかを判別し、正しいオフィスＩＤが含まれている正規ユーザの接続だけを残す方法である。
【図面の簡単な説明】
【０２１４】
【図１】本発明の一実施形態に係るネットワークシステムの構成図
【図２】本発明の第１実施形態に係るネットワークシステムの動作を示すシーケンス図
【図３】本発明の第１実施形態に係る各種通知のデータ構造を示す図
【図４】本発明の第１実施形態に係るフィルタリングポリシーのデータ構造を示す図
【図５】本発明の第１実施形態に係る管理サーバの構成及び動作を説明する図
【図６】本発明の第２実施形態に係るネットワークシステムの概略構成及び動作を説明する図
【図７】本発明の第３実施形態に係るネットワークシステムの概略構成及び動作を説明する図
【図８】本発明の第５実施形態に係るネットワークシステムの概略構成及び動作を説明する図
【図９】本発明の第５実施形態に係るネットワークシステムの動作を示すシーケンス図。
【図１０】本発明の第５実施形態に係るリソース開示範囲制御エージェントの概略構成及び動作を説明する図
【図１１】本発明の第５実施形態に係るリソース開示範囲制御エージェントの動作を示すシーケンス図
【図１２】本発明の第６実施形態に係るネットワークシステムの概略構成及び動作を説明する図
【図１３】本発明の第６実施形態に係るネットワークシステムの動作を示すシーケンス図
【図１４】本発明の第６実施形態に係る入退室管理サーバにおけるデータベースのデータ構造を示す図
【図１５】本発明の第６実施形態に係るフィルタリングポリシーのデータ構造を示す図
【図１６】本発明の第６実施形態に係る入退室管理サーバにおけるデータベースのデータ構造の別形態を示す図
【図１７】本発明の第６実施形態に係るユーザアクセスの動作を示すシーケンス図
【図１８】本発明の第８実施形態に係るネットワークシステムの概略構成及び動作を説明する図
【図１９】本発明の第１０実施形態に係るネットワークシステムの概略構成及び動作を説明する図
【図２０】本発明の第１０実施形態に係る多段アクセス時の要求および応答パケットのデータ構造を示す図
【図２１】本発明の第１０実施形態に係る多段アクセス管理ファイルのデータ構造を示す図
【図２２】本発明の第１０実施形態に係るネットワークシステムの別形態としての概略構成及び動作を説明する図
【図２３】本発明の第１実施形態に係るフィルタリングポリシーの決定手順を示すフローチャート図
【図２４】本発明の第１４実施形態に係るネットワークシステムの概略構成及び動作を説明する図
【図２５】本発明の第１４実施形態に係る利用要求通知のデータ構造を示す図
【符号の説明】
【０２１５】
１０００  シンクライアントシステム、１１００  アクセス制御システム、１１０１  インターネット、１１０３、１１０４、１１０５、１１０６、１１０７、１１０８  ＩＰネットワーク回線、１２００、１３００、１４００  サーバ、１２０１  ＣＰＵ、１２０２
バスＩＦ、１２０３  メモリ、１２０４  アプリケーション、１２０５  ユーザ作業データ、１２０６  ＨＤＤ、１２０７  ポート、１５００  スイッチ、１５０１、１５０４
ポート、１５０２  ＣＰＵ、１５０３  メモリ、１５０５  スイッチング部、１５０６
バスＩＦ、１６００、１６１０、１６２０  ブレードＰＣ、１６０１、１６０６  ポート、１６０２  メモリ、１６０３  ＣＰＵ、１６０４  ＨＤＤ、１６０５  バスＩＦ、１７００  管理サーバ、１７０１  メモリ、１７０２  アクセス制御機能プログラム、１７０３  フィルタリングポリシー、１７０４  ＣＰＵ、１７０５  ＨＤＤ、１７０６  バスＩＦ、１８００  ユーザ端末、１８０１  ポート、１８０２  メモリ、１８０３
ＣＰＵ、１８０４  ＨＤＤ、１８０５  バスＩＦ、５０００  通知処理モジュール、５００１  状況情報収集モジュール、５００２  ポリシー照合モジュール、５００３  フィルタリング制御モジュール、６０００  状況情報管理サーバ。
【図１】
2008160803.tif 000003
【図２】
2008160803.tif 000004
【図３】
2008160803.tif 000005
【図４】
2008160803.tif 000006
【図５】
2008160803.tif 000007
【図６】
2008160803.tif 000008
【図７】
2008160803.tif 000009
【図８】
2008160803.tif 000010
【図９】
2008160803.tif 000011
【図１０】
2008160803.tif 000012
【図１１】
2008160803.tif 000013
【図１２】
2008160803.tif 000014
【図１３】
2008160803.tif 000015
【図１４】
2008160803.tif 000016
【図１５】
2008160803.tif 000017
【図１６】
2008160803.tif 000018
【図１７】
2008160803.tif 000019
【図１８】
2008160803.tif 000020
【図１９】
2008160803.tif 000021
【図２０】
2008160803.tif 000022
【図２１】
2008160803.tif 000023
【図２２】
2008160803.tif 000024
【図２３】
2008160803.tif 000025
【図２４】
2008160803.tif 000026
【図２５】
2008160803.tif 000027