JP2011154622A

JP2011154622A - アクセス制御システム及びアクセス制御方法

Info

Publication number: JP2011154622A
Application number: JP2010016813A
Authority: JP
Inventors: Makoto Kubota; 真久保田
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2010-01-28
Filing date: 2010-01-28
Publication date: 2011-08-11
Anticipated expiration: 2030-01-28
Also published as: US8359633B2; JP5333263B2; US20110185398A1

Abstract

【課題】仮想デスクトップから業務アプリケーションを利用する際、仮想デスクトップに対するアクセス元端末情報に応じたアクセス制御を可能とすること。
【解決手段】ゲートウェイと、該端末が該ゲートウェイを介して通信するＶＤを提供する提供部と、該ＶＤがアクセスするアプリケーションが動作するサーバと通信する中継装置と、該端末に関する端末情報を該中継装置に送る管理部とを有し、管理部は、端末情報と、ユーザ情報と、ＶＤ識別情報とを組として記憶する記憶部を有し、端末情報とユーザ情報とをゲートウェイから受けて記憶部に記憶させ、ユーザ情報とＶＤ識別情報とを提供部から受けて記憶部に記憶させ、ＶＤ識別情報を中継装置から受けると、該ＶＤ識別情報をキーに記憶部から端末情報を検索して中継装置に送り、中継装置はＶＤから受けたメッセージをサーバに転送するか否かを端末情報から判断する。
【選択図】図４

Description

本発明は、仮想デスクトップ環境を提供する技術に関する。

企業の従業員は、事務所、出張先、自宅など様々な場所で作業をすることが多い。このような場合、各地に個別に従業員のデスクトップ環境を用意することは、企業・従業員にとって大きな手間である。また、従業員の移動によりデスクトップが変わることで作業の継続性が途切れることが問題となる。このような問題を解決するサービスとして、近年、ＤａａＳ（Desktop as a Service）と呼ばれるサービスが脚光を浴びている。

ＤａａＳは、ユーザのデスクトップ環境をセンタに構築して、センタからネットワーク経由でユーザ端末上にデスクトップ画面を提供するサービスである。図１に、ＤａａＳの概念図を示す。ＤａａＳサービスの提供者は、ＤａａＳサービスプロバイダ（以下、単にプロバイダと言う。）であり、ＤａａＳサービスの利用者は、例えば、企業及び企業内の従業員である。図２に、ＤａａＳサービスを提供するシステムの概要構成を示す。

プロバイダは、自身のセンタ（以下、ＤａａＳセンタと言う。）内に仮想デスクトップ環境（以下、ＶＤ：Virtual Desktopと言う。）及びサービス利用企業毎に論理的に分離したネットワーク環境（以下、ＤａａＳセンタ内企業ＮＷ）を用意する。ＶＤの実体は、Ｗｉｎｄｏｗｓ（登録商標）などのＯＳ（Operating System）と、当該ＯＳを配備する仮想マシン（以下、ＶＭ：Virtual Machineと言う。）であり、ユーザからＶＤの利用要求を受けた際に、物理サーバ（以下、ＶＤ実現サーバ）上に起動される。

プロバイダと契約した企業の従業員（以下、ユーザと言う。）は、以下のようにしてＤａａＳサービスを利用する。
（１）手許端末から、ＤａａＳセンタ内企業ＮＷに接続する。ユーザは、ＤａａＳセンタ入口のＶＰＮＧＷ（Virtual Private Network GateWay）に対して接続要求を行い、認証後に端末−ＶＰＮＧＷ間でＶＰＮトンネルを構築して、所属企業のＤａａＳセンタ内企業ＮＷにログインする。以降、ＤａａＳセンタ内企業ＮＷへのアクセスは、このＶＰＮトンネル経由で行われる。
（２）ＤａａＳ利用のための認証画面を提供するサーバ（以下、ＶＤポータルと言う。）にアクセスする。そして、ＶＤポータルはユーザの認証を行い、その後、当該ユーザ用のＶＤ（ＶＭ及びＯＳ）を起動し、そのＶＤのＩＰアドレスをユーザ端末に通知する。
（３）ユーザ端末は、通知されたＩＰアドレスのＶＤにＲＤＰ（Remote Desktop Protocol）で接続する。ＲＤＰは、手許端末におけるキーボード、マウスなどの操作情報をＶＤに通知すると共に、ＶＤ上の画面を手許端末に提供することが可能なプロトコルである。
（４）上記（１）乃至（３）の手順でユーザ端末がＶＤに接続すると、以降、ユーザは、物理的には社内外の様々な端末で作業しているにも関わらず、同じデスクトップ環境を使っての作業が可能となる。その際、各ＶＤはＤａａＳセンタ内企業ＮＷ上に接続されているため、ＶＤにアクセスしたユーザは、ＶＤ上のクライアントアプリケーションを利用することができ、社外ＮＷを経由せずに社内の業務アプリケーション（以下、単に業務アプリと言う。）を利用することができる。

企業は、ＶＤから業務アプリへのアクセスをシステムとして可能とする一方で、機密情報の漏洩防止の観点から、ＶＤへのアクセス元とアクセス先の業務アプリに応じてアクセス可否の制御（以下、アクセス制御と言う。）をできるようにしたい。例えば、経理アプリケーションなど機密性の高いアプリケーションについては、社内ＰＣからのアクセスは許容するが社外端末からのアクセスは禁止するなどのアクセス制御が求められる。なお、ここで言うアクセス元とは、ＶＤにアクセスしている端末の場所、種別、端末を利用中のユーザのことである。

しかし、ＶＤ上のＷｅｂからアクセス要求を受けた各企業の業務アプリには、アクセス元がＶＤであるかの如く見えてしまい、ＶＤへのアクセス元がどこであるのかは不明となる。従って、プロバイダ側で、アクセス元及び宛先ＵＲＬ（アクセス先の業務アプリ）に応じたアクセス制御ができることが望ましい。

ここで、ＶＰＮＧＷにおいてアクセス制御を行う従来技術について説明する。ＶＰＮＧＷは、端末からＶＰＮ接続要求を受ける際に、アクセス元情報を把握することができる。そのため、端末がＶＤを経由せずに業務アプリにアクセスする場合、ＶＰＮＧＷがアクセス元及びＵＲＬに応じたアクセス制御を行うことは可能である。しかし、ＤａａＳサービス利用時にＶＰＮＧＷ上を通過する情報は、端末−ＶＤ間のＲＤＰメッセージである。そして、ＲＤＰは暗号化されているため、図３で示すように、ＶＰＮＧＷはメッセージを取得することが可能であっても、宛先ＵＲＬを読み取ることができず、宛先業務アプリ毎のアクセス制御はできない。

さらに、ＶＤ−業務アプリ間の中継装置（以下、中継装置と言う。）においてアクセス制御を行う従来技術の他形態について説明する。ＤａａＳサービス利用時に中継装置上を通過する情報は、ＶＤから業務アプリ宛のメッセージであり、宛先ＵＲＬからアクセス先の業務アプリを読み取ることは可能である。しかし、図３で示すように、メッセージの送信元はＶＤのＩＰアドレスやＰｏｒｔであるため、中継装置はメッセージに基づいてＶＤへのアクセス元を知ることはできず、アクセス元に応じたアクセス制御を行うことはできない。

特開２００９−２５９０４６号公報

上記のように、従来、ＶＤから業務アプリへアクセスする際、ＶＤへのアクセス元情報及び宛先業務アプリに応じたアクセス制御ができないという問題点があった。

そこで、本発明では、仮想デスクトップから業務アプリケーションを利用する際、仮想デスクトップに対するアクセス元端末情報に応じたアクセス制御を可能とするアクセス制御システム及びアクセス制御方法を提供することを目的とする。

はじめに、上記課題の発生要因を説明する。第１にＶＤ上のＯＳはデスクトップ向けの既存ＯＳであり、業務アプリに対して物理的な端末の如く振る舞うことから、ＶＤ発メッセージの送信元アドレスはＶＤとなってしまう。第２に、そのためＶＤ−業務アプリ間の中継装置には、アクセス元端末が分からない。

次に、上記課題の解決に向けた着眼点を説明する。ＶＰＮＧＷは、「ユーザＩＤ、アクセス元端末情報」の対応情報を管理しているため、中継装置は、ＶＤ発メッセージからユーザＩＤ（以下、ｕＩＤと言う。）が分かれば、当該ｕＩＤをキーとしてＶＰＮＧＷの情報を参照することで、宛先ＵＲＬだけでなくアクセス元も知ることができる。

一方、サービスの特性上、ＶＤは１ユーザに占有されるため、ＶＤのＩＰアドレスはユーザごとに一意である。すなわち、通常、プロキシサーバなどの踏み台となるサーバは複数ユーザから共用されるため、サーバのＩＰアドレスは複数ユーザで共用されるが、ＶＤはＤａａＳ固有の特徴により、１ユーザに占有される。従って、中継装置は、各ＶＤのＩＰアドレスとｕＩＤの関係が分かれば、アクセス元を判別することができる。

また、ＤａａＳの動作メカニズム上、ＶＤポータルは、ＶＤのＩＰアドレスを端末に通知するため、「ｕＩＤ、ＶＤのＩＰアドレス」の対応情報を管理している。

従って、ＶＰＮＧＷ及びＶＤポータルが管理する情報に基づき、ＶＤのＩＰアドレスとアクセス元情報との紐付けが可能となり、中継装置はＶＤ発メッセージの送信元ＩＰ（以下、ＳｒｃＩＰと言う。）からアクセス元情報を識別することができる。

開示の技術によれば、仮想デスクトップから業務アプリケーションを利用する際、仮想デスクトップに対するアクセス元端末情報に応じたアクセス制御を可能とすることができる。

ＤａａＳサービスの概念図である。従来のＤａａＳサービスのシステム構成図である。従来技術の問題点を指摘する図である。本実施の形態に係る仮想デスクトップ環境提供システムの動作原理図である。第１の実施形態における仮想デスクトップ環境提供システムの構成を示す図である。第１の実施形態における仮想デスクトップ環境提供システムの動作シーケンス図である。第１の実施形態におけるＶＰＮＧＷの動作フローチャートである。第１の実施形態におけるユーザ情報管理サーバの動作フローチャートである。第１の実施形態におけるＶＤポータルの動作フローチャートである。第１の実施形態における中継装置の動作フローチャートである。第１の実施形態におけるＶＤ発業務アプリケーション宛メッセージの一例を示す図である。第１の実施形態における認証データベースの一例を示す図である。第１の実施形態におけるユーザ−トンネル対応テーブルの一例を示す図である。第１の実施形態におけるアクセス元情報管理テーブルの一例を示す図である。第１の実施形態におけるＭｓｇフック条テーブルの一例を示す図である。第１の実施形態におけるコネクションテーブルの一例を示す図である。第１の実施形態における認可ポリシテーブルの一例を示す図である。第１の実施形態におけるＶＤ発判断条件テーブルの一例を示す図である。第１の実施形態におけるｕＩＤ−ＶＤ＿ＩＰ対応テーブルの一例を示す図である。第１の実施形態における仮想デスクトップ環境提供システムの変形例を示す図である。第１の実施形態における仮想デスクトップ環境提供システムの第２の変形例を示す図である。第２の実施形態における仮想デスクトップ環境提供システムの構成を示す図である。第２の実施形態における仮想デスクトップ環境提供システムの動作シーケンス図である。

図面を参照しながら、本発明を実施するための最良の形態について説明する。
（本実施の形態に係る仮想デスクトップ環境提供システムの動作原理）
図４を用いて、本実施の形態に係る仮想デスクトップ環境提供システム１００の動作原理について説明する。

ＶＰＮＧＷ１２０は、ＮＷユーザ認証部１４０、ＶＰＮ終端部１５０、ユーザ情報通知部１３０を有する。ＮＷユーザ認証部１４０は、端末１１０からのＶＰＮ接続要求の受信時に、ｕＩＤ及びパスワードでユーザを認証する。ＶＰＮ終端部１５０は、認証がＯＫであった場合に、端末１１０との間でＶＰＮを構築又は終端する。ユーザ情報通知部１３０は、認証ＤＢを参照して当該ユーザが所属する企業用のＤａａＳセンタ内企業ＮＷのＮＷ識別子（以下、テナント識別子と言う。）を特定する。その後、認証対象ユーザのｕＩＤ及びアクセス元端末に関する情報を、前記テナント識別子とセットで、後述のユーザ情報管理サーバ３５０に通知する。

ＶＤポータル１７０は、ＶＤユーザ認証部１８０、ＶＤ起動制御部１９０を有する。ＶＤユーザ認証部１８０は、端末１１０からのＶＤ利用要求の受信時に、ｕＩＤ及びパスワードでユーザを認証し、認証がＯＫの場合、端末１１０に対する応答としてＶＤのＩＰ情報を含める。ＶＤ起動制御部１９０は、ＶＤユーザ認証がＯＫの場合、認証ＤＢ３９０を参照して当該ｕＩＤ用のＶＭのインスタンスＩＤ（以下、ＶＭ＿ＩＤと言う。）を特定する。その後、当該ＶＭ＿ＩＤで識別されるＶＭ部２５０及びＶＭ部２５０上のＯＳ部２３０に対応するＶＤ２１５の起動を、後述のＶＤ実現サーバ２００に対して指示する。

更に、起動済ＶＤ２１５からのＩＰ情報および前記ＶＭ＿ＩＤの受信時に、認証ＤＢを参照してＶＭ＿ＩＤに対応するｕＩＤを特定し、受信したＶＤのＩＰ情報とｕＩＤとをセットにして、ｕＩＤ−ＶＤ＿ＩＰ対応テーブルへのキャッシュ及びユーザ情報管理サーバ３５０への通知を行う。然る後に、ユーザ認証に対し、ＶＤ２１５のＩＰ情報を通知する。

一方、ＶＤ起動制御部１９０は、コネクションブローカ１６０から特定ＩＰのＶＤ２１５の起動停止要求を受けた場合、前記キャッシュからＩＰに対応するｕＩＤを取得し、さらに認証ＤＢ３９０を参照して当該ｕＩＤ用のＶＭ＿ＩＤを特定する。その後、当該ＶＭ＿ＩＤで識別されるＶＭ部２５０の停止を、後述のＶＤ実現サーバ２００に対して指示する。更に、当該ｕＩＤに関するＶＤ２１５のＩＰ情報の解放を、ユーザ情報管理サーバ３５０に要求する。

ＶＤ実現サーバ２００は、物理サーバ部２６０、ＶＭ制御部２１０、ＶＤ２１５、ＩＰ通知Ａｇｅｎｔ部２４０を有する。物理サーバ部２６０は、仮想マシンが動作する物理サーバである。ＶＭ制御部２１０は、物理サーバ部２６０上のＶＭの起動及び停止を制御する。ＶＤ２１５は、ＶＭ部２５０、ＯＳ部２３０及びブラウザなどのクライアントアプリケーション部２２０を含む仮想デスクトップ（Virtual Desktop）である。ＩＰ通知Ａｇｅｎｔ部２４０は、自ＶＤ２１５のＩＰアドレスを、自身のＶＭ＿ＩＤとペアでＶＤポータル１７０に通知する。

なお、本実施の形態において、ＶＤポータル１７０及びＶＤ実現サーバ２００を含む部分は提供部の一例である。

コネクションブローカ１６０は、端末−ＶＤ間のコネクションを監視する既存装置及び手段である。コネクションブローカ１６０は、ＶＤポータル発メッセージの中身を参照して、端末−ＶＤ間で生成されるＲＤＰコネクションの宛先ＩＰ情報を取得した後にそのコネクションを監視する。そして、コネクションブローカ１６０は、一定時間流量が無ければコネクション切断と認識し、前記宛先ＩＰで識別されるＶＤ２１５の停止を、ＶＤポータル１７０に対して要求する。

ユーザ情報管理サーバ３５０は、アクセス元情報管理部３７０を有する。アクセス元情報管理部３７０は、ＶＰＮＧＷ１２０及びＶＤポータル１７０からの通知に基づき、アクセス元情報管理テーブル３６０に、ＶＤ２１５を利用するユーザに関するｕＩＤ、アクセス元端末情報、テナント識別子、及び当該ユーザが使用中のＶＤ２１５のＩＰ情報の記録及び記録の削除を行う。

なお、本実施の形態において、ユーザ情報管理サーバ３５０は、管理部の一例である。

中継装置２７０は、ＶＤ発判断部２９０、ＩＰ−アクセス元情報変換部２８０、ＵＲＬ抽出部３００、認可判定部３２０を有する。ＶＤ発判断部２９０は、受信メッセージのテナント識別子および送信元ＩＰにより、受信メッセージが、ＶＤ２１５から送信されたメッセージであるか否かを判断する。ＩＰ−アクセス元情報変換部２８０は、ＶＤ２１５から送信されたメッセージである場合に、ユーザ情報管理サーバ３５０に問い合わせ、テナント識別子および送信元ＩＰに対応するアクセス元情報を取得する。ＵＲＬ抽出部３００は、メッセージ中の宛先ＵＲＬを抽出する。認可判定部３２０は、アクセス元情報、宛先ＵＲＬなどを使ってメッセージの転送可否を判断する。

以下では、仮想デスクトップ環境提供システム１００における処理の流れを説明する。ＶＤ２１５の利用を望むユーザは、まず手元の端末１１０から、ＶＰＮＧＷ１２０にＶＰＮ接続要求を行う。ＶＰＮＧＷ１２０は、ＮＷユーザ認証部１４０による認証結果がＯＫであれば、ユーザ情報通知部１３０を使ってユーザ情報管理サーバ３５０へのアクセス元情報の通知を行う。ユーザ情報管理サーバ３５０は、通知されたｕＩＤ、アクセス元端末情報、テナント識別子を、アクセス元情報管理テーブル３６０に記録する。ＶＰＮＧＷ１２０は、上記の後に端末１１０に認証完了の応答を返し、端末はＶＰＮＧＷ１２０のＶＰＮ終端部１５０との間にトンネルを構築し、当該トンネルを使ってメッセージの送受信を行う。

その後、上記端末１１０からＶＤ利用要求を受けたＶＤポータル１７０は、ＶＤユーザ認証部１８０による認証結果がＯＫであれば、ＶＤ起動制御部１９０を使って当該ユーザ用のＶＤ２１５を起動する。起動したＶＤ２１５上のＯＳに組み込まれたＩＰ通知Ａｇｅｎｔ部２４０は、当該ＶＤのＩＰ情報とＶＭ＿ＩＤのペアをＶＤポータル１７０に通知する。ＶＤポータル１７０のＶＤ起動制御部１９０は、通知されたＶＭ＿ＩＤをｕＩＤに変換した後、通知されたＩＰ情報及びｕＩＤのペアを、ユーザ情報管理サーバ３５０に対して通知する。ユーザ情報管理サーバ３５０は、アクセス元情報管理テーブル３６０中の通知されたｕＩＤに関するエントリに、通知されたＩＰ情報を記録する。

ＶＤポータル１７０のＶＤユーザ認証部１８０が、端末１１０にＶＤ２１５のＩＰ情報を通知し、端末１１０が通知されたＩＰ情報のＶＤ２１５への接続を完了した後、ＶＤ２１５上のクライアントアプリケーションが社内宛メッセージを送信する。その後、ＶＤ２１５と業務アプリ３４０の間に位置する中継装置２７０は、ＶＤ発判断部２９０で受信メッセージがＶＤ発と判断し、ＩＰ−アクセス元情報変換部２８０を使ってアクセス元情報を取得する。そして、認可判定部３２０が、ＵＲＬ抽出部３００で抽出した宛先ＵＲＬ情報及び前記アクセス元情報を使って認可判定を行うことで、アクセス元情報及び宛先業務アプリケーションに応じたアクセス制御が可能となる。

なお、上記説明では認可判定を中継装置２７０で行うこととしたが、認可判定の実現形態は外部サーバで行う形態であっても良い。つまり、認可ポリシ３１０および認可判定部３２０を外部サーバ上で保持し、当該外部サーバが認可可否を判断し、中継装置２７０は判断結果に応じた中継及び廃棄の制御のみを行う形態であっても良い。

上記のように、ＶＤ２１５から業務アプリ３４０への利用要求に際し、ＶＤ２１５にアクセスしている端末１１０の場所、種別及びユーザに応じたアクセス制御を可能とすることで、機密データの漏洩リスクが軽減される。さらには、仮想デスクトップサービスを使うユーザによる、業務アプリ及び業務データへの不用意なアクセスを防止することができる。

（第１の実施形態）
図５乃至図２０を用いて、第１の実施形態における仮想デスクトップ環境提供システム１００について説明する。はじめに、第１の実施形態で想定するシステム構成、アドレッシング、事前設定について説明する。

図５で、システム構成を示す。サーバの内部構成は図４の場合と同様である。図５中のＤＨＣＰ（Dynamic Host Configuration Protocol）サーバ４００は、各ＶＤ２１５が自身のＩＰアドレスを決める為の既存手段である。認証サーバ３８０は、認証情報を一括して管理するサーバである。

次に、企業Ａ向けのアドレッシングについて説明する。ＤａａＳセンタ内企業ＮＷは「ＶＬＡＮ＃Ａ」、ＶＤポータル１７０のＩＰアドレスは「ｖｄｐ−ａ」（企業Ａの社内で使用できるプライベートアドレス）、ＶＤ２１５のＩＰアドレスは「ｖｄ＃ａ１〜ａｎ」（企業Ａの社内で使用できるプライベートアドレス）とする。そして、ユーザａ１向けのアドレッシングは、ＶＤ２１５のＩＰアドレスが「ｖｄ＃ａ１」、ＶＭ部２５０のインスタンスＩＤが「ＩＤ＃ａ１」とする。

次に、企業Ａ向けのＤａａＳセンタ内の事前設定及び環境構築について説明する。図１２に、各ユーザの認証情報を設定する認証ＤＢの一例を示す。図１５には、コネクションブローカ１６０の設定を示し、認証応答メッセージを判断するための条件として、Ｍｓｇフック条件テーブルに、送信元ＩＰアドレスとして「ｖｄｐ−ａ」を設定する。ＤＨＣＰサーバ４００の設定については、ＶＬＡＮ＃ＡのＶＤ２１５に割り当て可能なＩＰアドレスとして、ＤＨＣＰサーバ４００内に「ｖｄ＃ａ１〜ａｎ」を設定する。図１８で示すように、中継装置２７０の設定としては、ＶＤ発メッセージかその他ノード発メッセージかを判断するための条件として、ＶＤ発判断条件テーブルに、ＶＬＡＮとして「＃Ａ」を、送信元ＩＰアドレスとして「ｖｄ＃ａ１〜ａｎ」を設定する。

次に、図６を用いて、第１の実施形態における仮想デスクトップ環境提供システム１００の処理を説明する。当該説明は、Ａ）ユーザがＶＤ２１５を起動するまでの流れ、Ｂ）ユーザがＶＤ２１５上でＷｅｂを使って業務アプリにアクセスする際の認可判定の流れ、Ｃ）ユーザがＶＤ２１５を終了するまでの流れの３フェーズに分けて行う。なお、図６で示すシーケンス中の主なサーバのフロー詳細は、図７乃至１０のフローチャートに示す。

Ａ）ユーザがＶＤを起動し、ユーザ情報管理サーバにアクセス元情報が記録されるまでの流れ

１）ＶＰＮ接続要求について説明する。ユーザは、端末１１０（ここでは携帯電話）からＶＰＮＧＷ１２０に対し、ＶＰＮ接続要求を行う。

２）ＶＰＮ接続応答について説明する。ＶＰＮＧＷ１２０のＮＷユーザ認証部１４０は、認証結果を端末に返す。

３）ＶＰＮ構築について説明する。認証ＯＫである場合、端末１１０はＶＰＮＧＷ１２０のＶＰＮ終端部１５０との間に、ｓｅｓｓｉｏｎ−ＩＤで識別されるＶＰＮトンネルを構築し、図１３で示すユーザ−トンネル対応テーブルにｕＩＤとｓｅｓｓｉｏｎ−ＩＤの対応を記録する。以降、ＶＰＮＧＷ１２０は、端末１１０から上記ＶＰＮトンネルをＤａａＳセンタ内企業ＮＷ（ＶＬＡＮ＃Ａ）とマッピングする。即ち、上記ＶＰＮトンネルからパケットを受信した場合、ＶＬＡＮタグ＃Ａを付けてＤａａＳセンタ側に送信する。

４）アクセス元情報通知について説明する。ＶＰＮＧＷ１２０は、ユーザ情報通知部１３０を使い、認証時に得られたアクセス元情報（アクセス元端末情報（回線＝携帯、端末種別＝ｉ−ｐｈｏｎｅ）、アクセス元ユーザ情報（ｕＩＤ＝ｕｓｅｒ００１））及びＤａａＳセンタ内企業ＮＷで使うＶＬＡＮタグ情報をユーザ情報管理サーバ３５０に通知する。次に、ユーザ情報管理サーバ３５０は、通知された上記情報を図１４で示すアクセス元情報管理テーブル３６０に記録する。

５）ＶＤ利用要求について説明する。ユーザは、構築したＶＰＮトンネルを使って、ＶＤポータル画面に対しＨＴＴＰ（HyperText Transfer Protocol）でアクセスし、ｖｄｐ−ａ宛に、ＶＤの利用要求を行う。

６）ＶＤ起動指示について説明する。ＶＤポータル１７０のＶＤユーザ認証部１８０は、ユーザ認証する時に認証ＤＢ３９０を参照し、認証を行うとともに、当該ユーザ（ｕＩＤ＃ｕｓｅｒ００１）向けＶＭ部２５０のインスタンスＩＤ＃ａ１を取得する。次に、ＶＤポータル１７０のＶＤ起動制御部１９０は、ＶＤ実現サーバ２００に対し、インスタンスＩＤ＃ａ１で識別されるＶＭ部２５０の起動を指示する。そして、ＶＤ実現サーバ２００上のＶＭ制御部２１０は、インスタンスＩＤ＃ａ１で識別されるＶＭイメージをＨＤＤから読み出してＶＭ部２５０及びＶＭ部２５０上のＯＳ部２３０を起動する。

７）ＩＰアドレスの取得について説明する。ＯＳ部２３０は、ＤＨＣＰサーバ４００から自身のＩＰアドレスを取得して、自身のＩＰアドレスとする。

８）自ＩＰアドレスの通知について説明する。上記ＯＳ部２３０上のＩＰ通知Ａｇｅｎｔ部２２０は、取得したＩＰアドレスを、ＶＭ部２５０のインスタンスＩＤ＃ａ１と共に、ＶＤポータル１７０に通知する。

９）ＶＤ＿ＩＰの通知について説明する。ＶＤポータル１７０のＶＤ起動制御部１９０は、認証ＤＢ３９０を参照し、通知されたインスタンスＩＤ＃ａ１に対応するユーザＩＤとしてｕｓｅｒ００１を得る。次に、ＶＤポータル１７０のＶＤ起動制御部１９０は、後でＶＤ２１５を停止する時のために、ユーザＩＤと通知されたＶＤ２１５のＩＰアドレスとの対応について、図１９で示すｕＩＤ−ＶＤ＿ＩＰ対応テーブルにキャッシュとして記録する。なお、停止時における上記キャッシュの使い方は、後述の１７）、１８）で説明する。そして、ＶＤポータル１７０のＶＤ起動制御部１９０は、「ユーザＩＤ＝ｕｓｅｒ００１、ＶＤ＿ＩＰ＝ｖｄ＃ａ１」という情報をユーザ情報管理サーバ３５０に通知する。さらに、ユーザ情報管理サーバ３５０のアクセス元情報管理部３７０は、上記４）でアクセス元情報管理テーブル３６０に記録したｕｓｅｒ００１の情報に対し、ＶＤ２１５のＩＰアドレスをバインドして記録する。

１０）ＶＰＮ利用応答について説明する。ＶＤポータル２１５のＶＤユーザ認証部１８０は、端末１１０に対し、ＶＤ＿ＩＰとしてｖｄ＃ａ１を通知する。次に、ＶＤポータル１７０と端末１１０との間に位置するコネクションブローカ１６０は、送信元ＩＰアドレスがｖｄｐ−ａなので、監視対象パケットと認識してパケットをフックし、メッセージの中身を参照する。そして、参照した結果、ｖｄ＃ａ１宛にＲＤＰコネクションが開始されることを検知して、図１６で示すコネクションテーブルに、監視対象として「送信元ＩＰアドレス＝端末ＩＰアドレス、宛先ＩＰアドレス＝ｖｄ＃ａ１」を登録する。さらに、コネクションブローカ１６０は、フックしたパケットをそのまま端末１１０宛に転送する。

１１）ＶＤ接続について説明する。端末１１０は、通知に従い、ｖｄ＃ａ１宛にＲＤＰで接続する。次に、コネクションブローカ１６０は、ｖｄ＃ａ１宛パケットの単位時間あたりの流量をコネクションテーブルに記録し、一定時間流量が無ければ切断と判断する。ここでは、パケットが流れたので接続中と判断し、受信パケットをそのまま転送する。そして、以降ＶＤ２１５は、端末１１０との間で、キーボード操作や画面情報をＲＤＰでやり取りする。

Ｂ）ユーザがＶＤ２１５上でＷｅｂを使って業務アプリ３４０にアクセスする際の認可判定の流れ

１２）業務アプリ利用要求について説明する。ユーザが、ＶＤ２１５上で社内の業務アプリにアクセスするためにＷｅｂを操作し、ＵＲＬとして「ｕｒｌ−Ａ１」を入力した場合を想定する。すると、ＶＤ２１５は、ＶＬＡＮタグ＝＃Ａ、送信元ＩＰ＝ｖｄ＃ａ１のメッセージを業務アプリ３４０宛に送信する。図１１にメッセージフォーマットを示す。

１３）ＩＰ−アクセス元情報変換について説明する。中継装置２７０のＶＤ発判断部２９０は、受信メッセージがＶＤ発か否かについてＶＤ発判断条件テーブル４１０を参照して判断する。その結果、「ＶＬＡＮ＃Ａ、送信元ＩＰ＝ｖｄ＃ａ１〜ｎ」の条件に合致するので、ＶＤ発と認識する。次に、中継装置２７０のＩＰ−アクセス元情報変換部２８０は、ユーザ情報管理サーバ３５０に対して「ＶＬＡＮタグ＝＃Ａ、送信元ＩＰアドレス＝ｖｄ＃ａ１」の情報を渡し、応答としてアクセス元情報（回線＝携帯、端末種別＝ｉ−ｐｈｏｎｅ、ユーザＩＤ＝ｕｓｅｒ００１）を取得する。次に、中継装置２７０のＵＲＬ抽出部３００は、受信メッセージのＨＴＴＰヘッダ中のＧＥＴフィールドから宛先ＵＲＬを抽出する。そして、中継装置２７０の認可判定部３２０は、図１７で示す認可ポリシテーブル３１０を参照し、認可判定を行う。参照キーは、アクセス元情報、受信メッセージ中の宛先ＵＲＬである。

１４）業務アプリ利用要求転送について説明する。中継装置２７０は、認可判定結果に従い、メッセージを中継または廃棄する。認可結果がＯＫであれば中継し、ＮＧであれば廃棄やＮＧ応答を行う。

Ｃ）ユーザがＶＤを終了するまでの流れ

１５）ＶＤ終了要求について説明する。ユーザは、ＶＤ２１５の使用を終了したい場合、ＶＤ２１５上ＯＳ部２３０の操作で停止要求をするか、又はＶＤ２１５から提供されている画面を閉じることでＶＤ２１５の停止要求をする。

１６）ＶＤ停止要求について説明する。コネクションブローカ１６０は、「送信元ＩＰアドレス＝端末ＩＰアドレス、宛先ＩＰアドレス＝ｖｄ＃ａ１」のコネクションの流量が一定時間ゼロであることを検知する。そして、コネクションブローカ１６０は、このコネクションの切断を検知し、ＶＤポータル１７０に対し、ｖｄ＃ａ１のＶＤ２１５の停止を要求する。

１７）ＶＤ停止指示について説明する。ＶＤポータル１７０のＶＤ起動制御部１９０は、ｕＩＤ−ＶＤ＿ＩＰ対応テーブルを参照して、ＶＤ２１５のＩＰ情報（ｖｄ＃ａ１）に対応するｕＩＤを取得する。更に、ＶＤポータル１７０のＶＤ起動制御部１９０は認証ＤＢ３９０を参照して、このユーザＩＤに対応するＶＭ部２５０のインスタンスＩＤ情報（＃ａ１）を取得する。その後、ＶＤ起動制御部１９０はＶＤ実現サーバ２００に対し、インスタンスＩＤ＃ａ１のＶＭ部２５０の停止指示を行う。そして、ＶＤ実現サーバ２００上のＶＭ制御部２１０は、インスタンスＩＤ＃ａ１で識別されるＶＭ部２５０を停止する。

１８）ＶＤ解放通知について説明する。ＶＤポータル１７０のＶＤ起動制御部１９０は、ユーザ情報管理サーバ３５０に対し、ユーザＩＤをパラメタとしてＶＤ２１５の解放を要求する。そして、ユーザ情報管理サーバ３５０のアクセス元情報管理部３７０は、ｕＩＤ＃ａのＶＤ＿ＩＰ情報（ｖｄ＃ａ１）を削除する。

１９）ＶＰＮ終了要求について説明する。ユーザは、ＶＰＮの使用を終了したい場合、端末１１０上でＶＰＮの終了要求をする。次に、ＶＰＮＧＷ１２０のＶＰＮ終端部１５０は、要求を受けたｓｅｓｓｉｏｎ−ＩＤのＶＰＮトンネルを終了する。更に、ＶＰＮ終端部１５０は、ｓｅｓｓｉｏｎ−ＩＤに対応するｕＩＤ（ｕｓｅｒ００１）をユーザ−トンネル対応テーブルから取得する。

２０）アクセス元情報の削除要求について説明する。ＶＰＮＧＷ１２０のユーザ情報通知部１３０は、ユーザ情報管理サーバ３５０に対し「ｕｓｅｒ００１」の情報の削除要求をする。すると、ユーザ情報管理サーバ３５０のアクセス元情報管理部３７０は、「ｕｓｅｒ００１」に関する情報を削除する。

以上の動作により、仮想デスクトップにアクセスしている端末の場所や種別に応じたアクセス制御が可能となる。なお、第１の実施形態では、ユーザの手元の端末として携帯電話を想定したが、インターネット上のＰＣ、ＳｍａｒｔＰｈｏｎｅ、拠点内のＰＣの場合も同様である。

また、第１の実施形態では、中継装置２７０が認可判定を行うケースを示したが、認可判定は外部サーバで行っても良い。たとえば上記１３）のＵＲＬ抽出部３００の処理は、次のような構成及び動作であっても良い。構成については、認可判定を行うサーバとして、認可ポリシテーブル３１０を保持する認可サーバを別途設ける。動作については、中継装置２７０が、上記認可サーバに対し認可判定依頼メッセージを送信し、その際メッセージには参照キー（アクセス元情報、受信メッセージ中の宛先ＵＲＬ）が指定される。そして、認可サーバは、認可ポリシテーブル３１０を参照し認可判定を行い、認可サーバは中継装置２７０に対し、認可判定を応答する。

また、第１の実施形態では、認可判定のキーとして使用するアクセス元情報を「回線、端末種別、ユーザＩＤ」と想定したが、その他のパラメタを含んでも良い。例えば、端末ＩＰアドレス、アクセス時間などを含んでも良い。また、第１の実施形態では、アクセス元情報管理テーブル３６０を管理するサーバについて、ユーザ情報管理サーバ３５０として単独で設けたが、当該テーブルを既存サーバが内包しても良い。例えば、図２０で示すように、コネクションブローカ１６０がアクセス元情報管理テーブル３６０を内包しても良い。または図２１で示すように、中継装置２７０がアクセス元情報管理テーブル３６０を内包しても良い。

（第２の実施形態）
図２２及び図２３を用いて、第２の実施形態における仮想デスクトップ環境提供システム１００について説明する。ここでは、拠点発のＶＤアクセスが、ＶＰＮＧＷを経由しない場合について説明する。

図２２に、第２の実施形態における仮想デスクトップ環境提供システム１００のシステム構成を示す。各サーバの内部構成は図４と同様である。なお、図２２において、各サーバが保持するテーブル及びＤＢは第１の実施形態と同じであるため、ここでは略記する。

以下、図２３で示すシーケンスに沿って、仮想デスクトップ環境提供システム１００の処理について説明する。説明は第１の実施形態と同様に３フェーズに分けて行う。なお、シーケンス中の番号は第１の実施形態と対応し、第２の実施形態では、第１の実施形態と動作が全く同じものについては説明を省略する。

Ａ）ユーザがＶＤを起動し、ユーザ情報管理にアクセス元情報が記録されるまでの流れ

１）乃至４）については、第２の実施形態では処理を行わない。

５）ＶＤ利用要求について説明する。ユーザは、キャリアが事前に構築した企業Ａ向けの社内ＮＷ経由でＶＤポータル画面に対しＨＴＴＰでアクセスし、ｖｄｐ−ａ宛にＶＤ２１５の利用要求を行う。

６）乃至８）については、第１の実施形態と同じであるため説明を省略する。

９）ＶＤ＿ＩＰの通知について説明する。ＶＤポータル１７０のＶＤ起動制御部１９０は、認証ＤＢ３９０を参照し、通知されたインスタンスＩＤ＃ａ１に対応するユーザＩＤとしてｕｓｅｒ００１を取得する。次に、ＶＤポータル１７０のＶＤ起動制御部１９０は、後フェーズでＶＤ２１５を停止する時のために、ユーザＩＤと通知されたＶＤ２１５のＩＰアドレスとの対応について、ｕＩＤ−ＶＤ＿ＩＰ対応テーブルにキャッシュとして記録する。ＶＤポータル１７０のＶＤ起動制御部１９０は、「ユーザＩＤ＝ｕｓｅｒ００１、ＶＤ＿ＩＰ＝ｖｄ＃ａ１、回線＝社内の拠点、端末種別＝ＰＣ」の情報をユーザ情報管理サーバ３５０に通知する。なお、社内の拠点であることは、送信元端末１１０のＩＰアドレスが拠点内の端末に割り振ったＩＰアドレスであることから判断する。また、第１の実施形態と異なり、ＶＤ起動制御部１９０は端末種別情報も通知する。

そして、ユーザ情報管理サーバ３５０のアクセス元情報管理部３７０は、「ｕｓｅｒ００１」のアクセス元情報がアクセス元情報管理テーブル３６０に未登録なので、当該ユーザは社内拠点からＶＤポータル１７０にアクセスしていると判断し、アクセス元情報管理テーブル３６０に「アクセス元端末情報（回線＝拠点、端末種別＝ＰＣ）、アクセス元ユーザ情報（ユーザＩＤ＝ｕｓｅｒ００１）、テナント識別子（ＶＬＡＮ＃Ａ）」のエントリを新規に登録する。

１０）乃至１７）については、第１の実施形態と同じであるため説明を省略する。

１８）ＶＤ解放通知について説明する。ＶＤポータル１７０のＶＤ起動制御部１９０は、ユーザ情報管理サーバ３５０に対し、ユーザＩＤをパラメタとしてＶＤ２１５の解放を要求する。次に、ユーザ情報管理サーバ３５０のアクセス元情報管理部３７０は、ｕＩＤ＃ａのＶＤ＿ＩＰ情報（ｖｄ＃ａ１）を削除する。このとき、アクセス元情報管理テーブル３６０において、回線＝拠点と記録されているので、端末−ＶＤ間にＶＰＮＧＷ１２０は無いと判断し、ユーザＩＤ＃ａの全情報をアクセス元情報管理テーブル３６０から削除する。

１９）及び２０）については第２の実施形態では処理を行わない。

上記のように、第２の実施形態における仮想デスクトップ環境提供システム１００は、拠点発のアクセスがＶＰＮＧＷを介さない場合であっても、仮想デスクトップにアクセスしている端末の場所や種別に応じたアクセス制御を可能とする。

以上、本発明の実施の形態について詳述したが、本発明は係る特定の実施の形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲において、種々の変形・変更が可能である。

１００仮想デスクトップ環境提供システム、１１０ユーザ端末、１２０ＶＰＮＧＷ（Virtual Private Network GateWay）、１３０ユーザ情報通知部、１４０ＮＷユーザ認証部、１５０ＶＰＮ終端部、１６０コネクションブローカ、１７０ＶＤ（Virtual Desktop）ポータル、１８０ＶＤユーザ認証部、１９０ＶＤ起動制御部、２００ＶＤ実現サーバ、２１０ＶＭ（Virtual Machine）制御部、２１５仮想デスクトップ（ＶＤ：Virtual Desktop）、２２０クライアントアプリケーション部、２３０ＯＳ部、２４０ＩＰ通知Ａｇｅｎｔ部、２５０ＶＭ部、２６０物理サーバ部、２７０中継装置、２８０ＩＰ−アクセス元情報変換部、２９０ＶＤ発判断部、３００ＵＲＬ（Uniform Resource Locator）抽出部、３１０認可ポリシテーブル、３２０認可判定部、３３０廃棄部、３４０業務アプリケーション、３５０ユーザ情報管理サーバ、３６０アクセス元情報管理テーブル、３７０アクセス元情報管理部、３８０認証サーバ、３９０認証データベース、４００ＤＨＣＰ（Dynamic Host Configuration Protocol）サーバ、４１０ＶＤ発判断条件テーブル

Claims

端末と通信するゲートウェイと、該端末が該ゲートウェイを介して通信する仮想デスクトップを提供する提供部と、該仮想デスクトップがアクセスするアプリケーションが動作するサーバと通信する中継装置と、該端末に関する端末情報を該中継装置に送る管理部と、を有するアクセス制御システムにおいて、
前記管理部は、
端末に関する端末情報と、該端末から仮想デスクトップを介してアプリケーションを使用するユーザに関するユーザ情報と、該仮想デスクトップを識別する仮想デスクトップ識別情報とを組として記憶する記憶部を有し、
前記端末情報と前記ユーザ情報とを、前記ゲートウェイから受けて前記記憶部に記憶させ、前記ユーザ情報と前記仮想デスクトップ識別情報とを、前記提供部から受けて前記記憶部に記憶させ、前記仮想デスクトップ識別情報を前記中継装置から受けると、該仮想デスクトップ識別情報をキーに前記記憶部から前記端末情報を検索して、検索された前記端末情報を前記中継装置に送り、
前記中継装置は、前記仮想デスクトップから受けたメッセージを前記サーバに転送するか否かを、前記管理部から受けた前記端末情報から判断する、
アクセス制御システム。
前記中継装置は、
端末から仮想デスクトップを介してアプリケーションを使用するユーザに関するユーザ情報と、端末に関する端末情報と、該仮想デスクトップから受けたメッセージを前記サーバに転送して良いかを規定する可否情報とを組として記憶する第２記憶部を有し、
前記メッセージを前記サーバに転送するか否かを、前記管理部から受けた前記端末情報と、前記第２記憶部から読み出した前記端末情報及び前記可否情報とを比較して判断する、
請求項1記載のアクセス制御システム。
前記管理部は、前記仮想デスクトップ識別情報を前記中継装置から受けると、該仮想デスクトップ識別情報をキーに前記記憶部から前記端末情報及び前記ユーザ情報を検索して、検索された前記端末情報及び前記ユーザ情報を前記中継装置に送り、
前記中継装置は、記メッセージを前記サーバに転送するか否かを、前記管理部から受けた前記端末情報及び前記ユーザ情報から判断する、
請求項１又は２記載のアクセス制御システム
前記中継装置は、
前記メッセージに含まれる、前記ユーザに対応するネットワークを識別するテナント識別子と前記仮想デスクトップ識別情報とに基づいて、当該メッセージが前記仮想デスクトップより送信されたメッセージであるか否かを判断し、当該メッセージが前記仮想デスクトップより送信されたメッセージであると判断した場合に、当該メッセージを前記サーバに転送するか否かを判断する、
請求項１乃至３いずれか一項記載のアクセス制御システム。
前記端末は、前記ゲートウェイを介さずに前記提供部と通信し、
前記管理部は、
前記端末情報と前記ユーザ情報と前記仮想デスクトップ識別情報とを、前記提供部から受けて前記記憶部に記憶させ、前記仮想デスクトップ識別情報を前記中継装置から受けると、該仮想デスクトップ識別情報をキーに前記記憶部から前記端末情報を検索して、検索された前記端末情報を前記中継装置に送る、
請求項１乃至４いずれか一項記載のアクセス制御システム。
端末と通信するゲートウェイと、該端末が該ゲートウェイを介して通信する仮想デスクトップを提供する提供部と、該仮想デスクトップがアクセスするアプリケーションが動作するサーバと通信する中継装置と、該端末に関する端末情報を該中継装置に送る管理部と、を有するアクセス制御システムにおいて、
前記管理部は、
端末に関する端末情報と、該端末から仮想デスクトップを介してアプリケーションを使用するユーザに関するユーザ情報と、該仮想デスクトップを識別する仮想デスクトップ識別情報とを組として記憶部に記憶させる手順と、
前記端末情報と前記ユーザ情報とを、前記ゲートウェイから受けて前記記憶部に記憶させ、前記ユーザ情報と前記仮想デスクトップ識別情報とを、前記提供部から受けて前記記憶部に記憶させ、前記仮想デスクトップ識別情報を前記中継装置から受けると、該仮想デスクトップ識別情報をキーに前記記憶部から前記端末情報を検索して、検索された前記端末情報を前記中継装置に送る手順とを実行し、
前記中継装置は、前記仮想デスクトップから受けたメッセージを前記サーバに転送するか否かを、前記管理部から受けた前記端末情報から判断する、
アクセス制御方法。