アクセス制御システム及びアクセス制御方法
【課題】仮想デスクトップから業務アプリケーションを利用する際、仮想デスクトップに対するアクセス元端末情報に応じたアクセス制御を可能とすること。
【解決手段】ゲートウェイと、該端末が該ゲートウェイを介して通信するＶＤを提供する提供部と、該ＶＤがアクセスするアプリケーションが動作するサーバと通信する中継装置と、該端末に関する端末情報を該中継装置に送る管理部とを有し、管理部は、端末情報と、ユーザ情報と、ＶＤ識別情報とを組として記憶する記憶部を有し、端末情報とユーザ情報とをゲートウェイから受けて記憶部に記憶させ、ユーザ情報とＶＤ識別情報とを提供部から受けて記憶部に記憶させ、ＶＤ識別情報を中継装置から受けると、該ＶＤ識別情報をキーに記憶部から端末情報を検索して中継装置に送り、中継装置はＶＤから受けたメッセージをサーバに転送するか否かを端末情報から判断する。
【解決手段】ゲートウェイと、該端末が該ゲートウェイを介して通信するＶＤを提供する提供部と、該ＶＤがアクセスするアプリケーションが動作するサーバと通信する中継装置と、該端末に関する端末情報を該中継装置に送る管理部とを有し、管理部は、端末情報と、ユーザ情報と、ＶＤ識別情報とを組として記憶する記憶部を有し、端末情報とユーザ情報とをゲートウェイから受けて記憶部に記憶させ、ユーザ情報とＶＤ識別情報とを提供部から受けて記憶部に記憶させ、ＶＤ識別情報を中継装置から受けると、該ＶＤ識別情報をキーに記憶部から端末情報を検索して中継装置に送り、中継装置はＶＤから受けたメッセージをサーバに転送するか否かを端末情報から判断する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、仮想デスクトップ環境を提供する技術に関する。
【背景技術】
【０００２】
企業の従業員は、事務所、出張先、自宅など様々な場所で作業をすることが多い。このような場合、各地に個別に従業員のデスクトップ環境を用意することは、企業・従業員にとって大きな手間である。また、従業員の移動によりデスクトップが変わることで作業の継続性が途切れることが問題となる。このような問題を解決するサービスとして、近年、ＤａａＳ（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）サーバ、４１０ ＶＤ発判断条件テーブル
【技術分野】
【０００１】
本発明は、仮想デスクトップ環境を提供する技術に関する。
【背景技術】
【０００２】
企業の従業員は、事務所、出張先、自宅など様々な場所で作業をすることが多い。このような場合、各地に個別に従業員のデスクトップ環境を用意することは、企業・従業員にとって大きな手間である。また、従業員の移動によりデスクトップが変わることで作業の継続性が途切れることが問題となる。このような問題を解決するサービスとして、近年、ＤａａＳ（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）サーバ、４１０ ＶＤ発判断条件テーブル
【特許請求の範囲】
【請求項１】
端末と通信するゲートウェイと、該端末が該ゲートウェイを介して通信する仮想デスクトップを提供する提供部と、該仮想デスクトップがアクセスするアプリケーションが動作するサーバと通信する中継装置と、該端末に関する端末情報を該中継装置に送る管理部と、を有するアクセス制御システムにおいて、
前記管理部は、
端末に関する端末情報と、該端末から仮想デスクトップを介してアプリケーションを使用するユーザに関するユーザ情報と、該仮想デスクトップを識別する仮想デスクトップ識別情報とを組として記憶する記憶部を有し、
前記端末情報と前記ユーザ情報とを、前記ゲートウェイから受けて前記記憶部に記憶させ、前記ユーザ情報と前記仮想デスクトップ識別情報とを、前記提供部から受けて前記記憶部に記憶させ、前記仮想デスクトップ識別情報を前記中継装置から受けると、該仮想デスクトップ識別情報をキーに前記記憶部から前記端末情報を検索して、検索された前記端末情報を前記中継装置に送り、
前記中継装置は、前記仮想デスクトップから受けたメッセージを前記サーバに転送するか否かを、前記管理部から受けた前記端末情報から判断する、
アクセス制御システム。
【請求項２】
前記中継装置は、
端末から仮想デスクトップを介してアプリケーションを使用するユーザに関するユーザ情報と、端末に関する端末情報と、該仮想デスクトップから受けたメッセージを前記サーバに転送して良いかを規定する可否情報とを組として記憶する第２記憶部を有し、
前記メッセージを前記サーバに転送するか否かを、前記管理部から受けた前記端末情報と、前記第２記憶部から読み出した前記端末情報及び前記可否情報とを比較して判断する、
請求項1記載のアクセス制御システム。
【請求項３】
前記管理部は、前記仮想デスクトップ識別情報を前記中継装置から受けると、該仮想デスクトップ識別情報をキーに前記記憶部から前記端末情報及び前記ユーザ情報を検索して、検索された前記端末情報及び前記ユーザ情報を前記中継装置に送り、
前記中継装置は、記メッセージを前記サーバに転送するか否かを、前記管理部から受けた前記端末情報及び前記ユーザ情報から判断する、
請求項１又は２記載のアクセス制御システム
【請求項４】
前記中継装置は、
前記メッセージに含まれる、前記ユーザに対応するネットワークを識別するテナント識別子と前記仮想デスクトップ識別情報とに基づいて、当該メッセージが前記仮想デスクトップより送信されたメッセージであるか否かを判断し、当該メッセージが前記仮想デスクトップより送信されたメッセージであると判断した場合に、当該メッセージを前記サーバに転送するか否かを判断する、
請求項１乃至３いずれか一項記載のアクセス制御システム。
【請求項５】
前記端末は、前記ゲートウェイを介さずに前記提供部と通信し、
前記管理部は、
前記端末情報と前記ユーザ情報と前記仮想デスクトップ識別情報とを、前記提供部から受けて前記記憶部に記憶させ、前記仮想デスクトップ識別情報を前記中継装置から受けると、該仮想デスクトップ識別情報をキーに前記記憶部から前記端末情報を検索して、検索された前記端末情報を前記中継装置に送る、
請求項１乃至４いずれか一項記載のアクセス制御システム。
【請求項６】
端末と通信するゲートウェイと、該端末が該ゲートウェイを介して通信する仮想デスクトップを提供する提供部と、該仮想デスクトップがアクセスするアプリケーションが動作するサーバと通信する中継装置と、該端末に関する端末情報を該中継装置に送る管理部と、を有するアクセス制御システムにおいて、
前記管理部は、
端末に関する端末情報と、該端末から仮想デスクトップを介してアプリケーションを使用するユーザに関するユーザ情報と、該仮想デスクトップを識別する仮想デスクトップ識別情報とを組として記憶部に記憶させる手順と、
前記端末情報と前記ユーザ情報とを、前記ゲートウェイから受けて前記記憶部に記憶させ、前記ユーザ情報と前記仮想デスクトップ識別情報とを、前記提供部から受けて前記記憶部に記憶させ、前記仮想デスクトップ識別情報を前記中継装置から受けると、該仮想デスクトップ識別情報をキーに前記記憶部から前記端末情報を検索して、検索された前記端末情報を前記中継装置に送る手順とを実行し、
前記中継装置は、前記仮想デスクトップから受けたメッセージを前記サーバに転送するか否かを、前記管理部から受けた前記端末情報から判断する、
アクセス制御方法。
【請求項１】
端末と通信するゲートウェイと、該端末が該ゲートウェイを介して通信する仮想デスクトップを提供する提供部と、該仮想デスクトップがアクセスするアプリケーションが動作するサーバと通信する中継装置と、該端末に関する端末情報を該中継装置に送る管理部と、を有するアクセス制御システムにおいて、
前記管理部は、
端末に関する端末情報と、該端末から仮想デスクトップを介してアプリケーションを使用するユーザに関するユーザ情報と、該仮想デスクトップを識別する仮想デスクトップ識別情報とを組として記憶する記憶部を有し、
前記端末情報と前記ユーザ情報とを、前記ゲートウェイから受けて前記記憶部に記憶させ、前記ユーザ情報と前記仮想デスクトップ識別情報とを、前記提供部から受けて前記記憶部に記憶させ、前記仮想デスクトップ識別情報を前記中継装置から受けると、該仮想デスクトップ識別情報をキーに前記記憶部から前記端末情報を検索して、検索された前記端末情報を前記中継装置に送り、
前記中継装置は、前記仮想デスクトップから受けたメッセージを前記サーバに転送するか否かを、前記管理部から受けた前記端末情報から判断する、
アクセス制御システム。
【請求項２】
前記中継装置は、
端末から仮想デスクトップを介してアプリケーションを使用するユーザに関するユーザ情報と、端末に関する端末情報と、該仮想デスクトップから受けたメッセージを前記サーバに転送して良いかを規定する可否情報とを組として記憶する第２記憶部を有し、
前記メッセージを前記サーバに転送するか否かを、前記管理部から受けた前記端末情報と、前記第２記憶部から読み出した前記端末情報及び前記可否情報とを比較して判断する、
請求項1記載のアクセス制御システム。
【請求項３】
前記管理部は、前記仮想デスクトップ識別情報を前記中継装置から受けると、該仮想デスクトップ識別情報をキーに前記記憶部から前記端末情報及び前記ユーザ情報を検索して、検索された前記端末情報及び前記ユーザ情報を前記中継装置に送り、
前記中継装置は、記メッセージを前記サーバに転送するか否かを、前記管理部から受けた前記端末情報及び前記ユーザ情報から判断する、
請求項１又は２記載のアクセス制御システム
【請求項４】
前記中継装置は、
前記メッセージに含まれる、前記ユーザに対応するネットワークを識別するテナント識別子と前記仮想デスクトップ識別情報とに基づいて、当該メッセージが前記仮想デスクトップより送信されたメッセージであるか否かを判断し、当該メッセージが前記仮想デスクトップより送信されたメッセージであると判断した場合に、当該メッセージを前記サーバに転送するか否かを判断する、
請求項１乃至３いずれか一項記載のアクセス制御システム。
【請求項５】
前記端末は、前記ゲートウェイを介さずに前記提供部と通信し、
前記管理部は、
前記端末情報と前記ユーザ情報と前記仮想デスクトップ識別情報とを、前記提供部から受けて前記記憶部に記憶させ、前記仮想デスクトップ識別情報を前記中継装置から受けると、該仮想デスクトップ識別情報をキーに前記記憶部から前記端末情報を検索して、検索された前記端末情報を前記中継装置に送る、
請求項１乃至４いずれか一項記載のアクセス制御システム。
【請求項６】
端末と通信するゲートウェイと、該端末が該ゲートウェイを介して通信する仮想デスクトップを提供する提供部と、該仮想デスクトップがアクセスするアプリケーションが動作するサーバと通信する中継装置と、該端末に関する端末情報を該中継装置に送る管理部と、を有するアクセス制御システムにおいて、
前記管理部は、
端末に関する端末情報と、該端末から仮想デスクトップを介してアプリケーションを使用するユーザに関するユーザ情報と、該仮想デスクトップを識別する仮想デスクトップ識別情報とを組として記憶部に記憶させる手順と、
前記端末情報と前記ユーザ情報とを、前記ゲートウェイから受けて前記記憶部に記憶させ、前記ユーザ情報と前記仮想デスクトップ識別情報とを、前記提供部から受けて前記記憶部に記憶させ、前記仮想デスクトップ識別情報を前記中継装置から受けると、該仮想デスクトップ識別情報をキーに前記記憶部から前記端末情報を検索して、検索された前記端末情報を前記中継装置に送る手順とを実行し、
前記中継装置は、前記仮想デスクトップから受けたメッセージを前記サーバに転送するか否かを、前記管理部から受けた前記端末情報から判断する、
アクセス制御方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【公開番号】特開２０１１−１５４６２２（Ｐ２０１１−１５４６２２Ａ）
【公開日】平成２３年８月１１日（２０１１．８．１１）
【国際特許分類】
【出願番号】特願２０１０−１６８１３（Ｐ２０１０−１６８１３）
【出願日】平成２２年１月２８日（２０１０．１．２８）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２３年８月１１日（２０１１．８．１１）
【国際特許分類】
【出願日】平成２２年１月２８日（２０１０．１．２８）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]