JP2010277494A - システムおよび端末装置 - Google Patents

Abstract

【課題】
データの外部漏洩の可能性をより低減することを課題とする。
【解決手段】
クライアントと、クライアントとネットワークを介して接続され、クライアントのデータを管理するデータサーバと、クライアントとネットワークを介して接続され、クライアントに対してアプリケーション機能を提供するアプリケーションサーバと、を備えるシステムにおいて、アプリケーションサーバは、クライアントへアプリケーション機能としてのアプリケーションプログラムを送信し、クライアントは、データサーバから秘匿化処理が施されたデータを受信し、アプリケーションプログラムに対して秘匿化処理が施されたデータを参照させる。
【選択図】図１

Description

本発明は、システムおよび端末装置に関し、特に、端末装置のデータをＷｅｂアプリケーションに直接参照させない技術に関する。

これまでクライアント装置上で実行するデスクトップアプリケーションとして実装されてきた企業向け業務システムの多くがＷｅｂ上のサービスであるＷｅｂアプリケーションとして提供され始めている。

特許文献１は、個人情報や企業の機密情報を外部に出さずに内部で管理するために、Ｗｅｂアプリケーションの機能のうち、データを管理する機能を利用者組織内のネットワークに配備することで（データ分離モデル）、データを利用者組織内に置いたまま外部のＷｅｂアプリケーションを利用する技術を開示している。

特開２００９−０１５８１６号公報

しかしながら、特許文献１記載の技術では、悪意あるＷｅｂアプリケーションの場合、利用者組織内に配備したデータがＷｅｂアプリケーションの提供元やその他のサーバに送信される可能性を排除できない可能性があった。

上記課題を解決するため、本発明は、クライアントと、クライアントとネットワークを介して接続され、クライアントのデータを管理するデータサーバと、クライアントとネットワークを介して接続され、クライアントに対してアプリケーション機能を提供するアプリケーションサーバと、を備えるシステムにおいて、アプリケーションサーバは、クライアントへアプリケーション機能としてのアプリケーションプログラムを送信し、クライアントは、データサーバから秘匿化処理が施されたデータを受信し、または、データサーバから受信したデータに秘匿化処理を施し、アプリケーションプログラムに対して秘匿化処理が施されたデータを参照させる。

本発明によれば、セキュリティをより向上させることが可能になる。

本発明の実施形態機能構成およびネットワーク構成を示す図。 コンピュータ装置の構成を示す図。 初期ページの一例を示す図。 データプロバイダからデータを取得し画面表示する処理のスクリプト例を示す図。 利用者の入力データから新規レコードをデータプロバイダに保存する処理のスクリプト例を示す図。 アプリスクリプトがデータプロバイダからデータを取得する処理フローを示す図。 アプリスクリプトがデータプロバイダにデータを保存する処理フローを示す図。 ＤＯＭハンドラがＤＯＭノードの属性値を設定する処理フローを示す図。 ＤＯＭハンドラがＤＯＭノードの属性値を取得する処理フローを示す図。 符番処理および符番復号処理のフローを示す図。 符番表の一例を示す図。 フィルタプロキシを導入する場合の本発明の実施形態の機能構成およびネットワーク構成を示す図。

まず、本発明の概要について説明する。

本発明の実施形態では、アプリケーションプロバイダから提供されたアプリスクリプトが、利用者組織内にあるデータプロバイダのデータを直接参照できないようにすることで、アプリスクリプトがＷｅｂアプリケーション提供者等にデータプロバイダが保持する保護すべきデータの送信を不可能にする。

ここで、アプリスクリプトとは、利用者組織外のＷｅｂアプリケーション提供サーバから提供され、利用者組織内に配備されたデータ提供サーバを介して利用者組織内のデータにアクセスしながらアプリケーション機能を提供するスクリプトプログラムを指し、一般的にはスクリプト言語ＪａｖａＳｃｒｉｐｔ（登録商標）で記述される。また、データプロバイダとは、利用者組織内に配備したＷｅｂアプリケーションで利用するデータを管理するためのサーバ装置である。

アプリスクリプトがデータプロバイダのデータを直接参照できないようにするため、本発明の実施形態では、データプロバイダが保持するデータをアプリスクリプトが直接参照しないように暗号化処理や符番処理を施す。暗号化処理とは、対象となる値そのものから暗号鍵等を用いて何らかの演算処理を行い元の値を第３者に見られないようにすることを指す。また、符番処理とは、対象となる値そのものとは無関係の他と重複のない識別子を対象となる値に対し付与し、その値と付与した識別子の組をひとつのレコードとする符番表を用意しておくことで、識別子だけを見ても元の値は算出されず、後から識別子を指定することで元の値を取り出すことができるようにする処理を指す。暗号化処理の場合は暗号鍵が、符番処理の場合は符番表がアプリスクリプトに対して秘匿されていれば、元の値はアプリスクリプトからの参照が不可能となる。

しかしながら、アプリスクリプトがデータプロバイダのデータを参照できないままでは当該Ｗｅｂアプリケーション利用者にデータプロバイダのデータを表示することもできない。そこで、アプリスクリプトにはデータを参照させず、かつ、データプロバイダのデータを表示可能とする仕組みをＷｅｂブラウザ（のアプリスクリプトを実行する環境）に導入する。

秘匿すべきデータは暗号化処理もしくは符番処理によりアプリスクリプトに対して参照できなくし、表示時やデータプロバイダへのデータ保存時は元の値に戻して処理する。アプリスクリプトが表示したものを再取得する場合も暗号化処理もしくは符番処理を行いアプリスクリプトには参照できないようにする。

以下、暗号化処理や符番処理を秘匿化または秘匿化処理と呼び、秘匿化したデータを参照できる状態にすることをいずれも復号または復号処理と呼ぶこととする。

アプリスクリプトによる画面入出力処理はＷｅｂブラウザが表示対象のＷｅｂページ内に含まれるスクリプトに対して提供する、ＤＯＭ ＡＰＩと呼ばれるＡＰＩを通して行われる。ＤＯＭ ＡＰＩはウェブページの見栄えを表現するＨＴＭＬをプログラム等からアクセスするための標準ＡＰＩである。ツリー構造で表現され、ＨＴＭＬ内の各要素を参照するだけでなく、追加、修正、削除操作を可能とする。多くのＷｅｂブラウザがＨＴＭＬ内に記述されたＪａｖａＳｃｒｉｐｔを実行するためのエンジンを有しており、ＪａｖａＳｃｒｉｐｔに対しＤＯＭ ＡＰＩを通して表示中のＨＴＭＬに対し参照、追加、修正、削除処理の実行を可能としている。

そこで、秘匿化した結果アプリスクリプトから直接参照できなくなったデータを表示処理可能とするため、ＤＯＭ ＡＰＩの処理を修正し、秘匿化データが設定される場合には復号処理を行ってから表示設定処理を行うことで利用者に対象データの値を見えるようにする。

ただし、リンク、画像、インラインフレーム、スクリプト要素を示すＤＯＭノード（具体的にはＡタグＩＭＧタグ、ＩＦＲＡＭＥタグ、ＳＣＲＩＰＴタグ）の場合、そのデータ取得先（ＩＭＧタグでは画像の取得先、ＩＦＲＡＭＥタグではＨＴＭＬの取得先、ＳＣＲＩＰＴタグではＪａｖａＳｃｒｉｐｔの取得先）のＵＲＬのパラメタとして秘匿対象のデータが設定されてしまうと、指定されたＵＲＬが示すサーバに当該データが送信されることとなる（パラメタとしてＵＲＬで示す先のサーバにデータが送信されてしまうため）。そのため、そのようなＤＯＭノード属性に対する設定処理の場合、上記のような復号処理は行わないようにし、データ漏洩を防ぐ。この点は本発明の実施形態におけるアプリケーションに対する制限事項である。つまり、本発明の実施形態では、Ｗｅｂアプリケーションでは秘匿対象のデータを使って画像、フレームページ、スクリプトのＵＲＬを構成し取得することがないように処理が行われる。

データプロバイダへデータを送信する場合には、秘匿化データが渡された場合には復号処理をしたのちに送信する。ただし、データプロバイダでの暗号化処理により秘匿化している場合は暗号化したままの形式でデータを送信し、復号はデータプロバイダで行っても良い。符番処理の場合も、符番対応表をデータプロバイダでも参照できる形式にしてあれば復号はデータプロバイダで行っても良い。

アプリプロバイダへデータを送信する場合には、送信対象として秘匿化データが渡された場合でも復号処理を行わず、そのまま文字列化処理を行ったものを送信すればよい。このような処理手順によりデータプロバイダ以外の送信先に対しては秘匿すべきデータを利用者外部に送信せずにすむ。

なお、Ｗｅｂアプリケーションにおいて、入力データをデータプロバイダのデータとして保存したい場合がある。そのため、入力データについても外部漏洩対策が必要となる。この場合には、データプロバイダのデータの場合と同様に、利用者からの入力データに対し、アプリスクリプトによる取得処理時には秘匿化処理を行うことで、アプリスクリプトに対して秘匿化する。

また、Ｗｅｂアプリケーションの機能として、データプロバイダからのデータやアプリケーション利用者からの入力データに対し合計計算や文字列連結等の演算処理が必要になる場合がある。このような演算処理結果を表示したり、データとして保存したりすることは、Ｗｅｂアプリケーションの基本機能となることが多く想定される。秘匿化されたままだとこれが不可能となり、アプリケーションとしては非常に制限されたものになってしまう。

通常は表示対象の文字列をＤＯＭノードの属性として設定すれば表示されるが、秘匿化した上で表示処理を可能とするため、表示対象として表示に必要な演算処理を行うための処理オブジェクト（関数）を設定すれば、その結果を表示可能にする処理方式をとることで対処する。ＤＯＭノードに対する属性設定処理による表示処理時、表示対象として関数が渡された場合、秘匿データを参照可能にした状態で当該関数を実行し、その結果を秘匿データと同様に表示可能・参照不可能な状態（秘匿化した状態）で表示する。関数実行の直後に再び秘匿データを通常どおり参照不可能な状態にすることで、アプリケーションスクリプトに対し秘匿すべきデータを秘匿した状態を保つことができる。

また、その関数内では秘匿データが参照可能な状態になってしまうため、関数の処理内に秘匿データを画面表示する処理がある場合、そのまま表示処理させることが可能となってしまい、あとから表示済みデータをアプリスクリプトから取得処理した場合に参照可能となってしまう。そのため、表示処理のために秘匿データを参照可能としている処理中は、その他の表示処理を禁止する。

以上の処理により、安全に秘匿データに対して演算処理や変換処理を表示可能とし、かつ漏洩を防止することができる。

以下、添付の図面を参照しながら、本発明にかかる実施の形態について説明する。

まず、図１により、本実施の形態に係るネットワークシステムの全体構成について説明する。

本実施の形態に係るネットワークシステムには、ネットワークに接続された複数の情報処理装置１０、２０、３０が含まれている。即ち、
（１）本システムで提供するＷｅｂアプリケーションの利用者が利用するＷｅｂブラウザがインストールされた１台以上の情報処理装置（以下、Ｗｅｂブラウザ）１０、
（２）本システムで提供するＷｅｂアプリケーションの機能のうち、秘匿対象の情報を管理する機能を提供し、利用者組織にて管理される情報処理装置（以下データプロバイダ）２０、
（３）本システムで提供するＷｅｂアプリケーションの機能のうち、（２）がもつ秘匿対象の情報の管理機能以外の機能（秘匿対象ではない情報の管理機能とページ生成処理機能）を提供し、利用者組織以外の第三者にて管理される。情報処理装置（以下、アプリケーションプロバイダ）３０が含まれている。

これら情報処理装置１０，２０，３０はそれぞれの機能を実現するためのプログラムの実行に必要な通常のハードウェア構成（ＣＰＵ，一時記憶装置、プログラムがインストールされた二次記憶装置等）を有している（図２）。以下の各図面で説明するフローチャートは、特に言及しない限り、記憶装置に記憶されたプログラムがＣＰＵで実行されるものとする。

図２は情報処理装置１０，２０，３０のハードウェア構成を示したものである。情報処理装置２−１は二次記憶装置２−１０２に実行すべきプログラムや、そのプログラムの実行に用いるデータを記録しておき、プログラムの実行時にはプログラムやデータを二次記憶装置２−１０３から一時記憶装置２−１０２に読み込み、ＣＰＵ２−１０１が一時記憶装置２−１０２にあるプログラムやデータを読み込みながらプログラムを実行する。プログラムの実行時には外部装置との入出力処理を入力インタフェース２−１０４、出力インタフェース２−１０５、通信インタフェース２−１０６を通じて、それぞれ入力装置２−２、出力装置２−３、通信装置２−４に対して行う。

なお、図１において、Ｗｅｂブラウザ１０の構成要素のうち、符番表１５、ＨＴＭＬ１８、アプリスクリプト３２は上記プログラムの実行に用いるデータであり、それ以外の構成要素は上記プログラムに相当する。同様に、データプロバイダ２０の構成要素のうち、秘匿対象データ２０５は上記プログラムの実行に用いるデータであり、それ以外の構成要素は上記プログラムに相当し、アプリケーションプロバイダ３０の構成要素のアプリスクリプトは上記プログラムの実行に用いるデータであり、Ｗｅｂサーバ３１は上記プログラムに相当する。それぞれ、各情報処理装置（１０，２０，３０）の二次記憶装置２−１０３に保存され、ＣＰＵ２−１０１が一時記憶装置２−１０２に読み込みながら実行する。

なお、図１ではＷｅｂブラウザ１０はユーザの数だけ存在しうるが、ここでは説明のためひとつだけ示している。

以下、実施例１の構成要素の機能および処理手順について説明する。データプロバイダ２０はネットワークを介してＷｅｂブラウザ１０からの処理要求を受け付け、処理要求に応じたＷｅｂページを返信するＷｅｂサーバ２０１と、本システムによるＷｅｂアプリケーションを実行するための初期ページを生成する初期ページ生成機能２０２と、本システムによるＷｅｂアプリケーションで扱うデータを操作する処理を行うためのユーザインタフェース機能を提供するデータＡＰＩ（Application Programming Interface）機能２０４と、本システムによるＷｅｂアプリケーションで扱うコンテンツデータ２０５と、秘匿対象データ２０５とから構成される。秘匿対象データ２０５は一時記憶装置もしくは二次記憶装置に記憶されており、初期ページ生成機能２０２とデータＡＰＩ機能２０４はプログラムであり、通常、上述の二時記憶装置に記憶され一時記憶装置に読み込まれた後、ＣＰＵで実行される。

データプロバイダ２０はＷｅｂブラウザ１０からの処理要求に応じて、初期ページを生成する機能と、秘匿対象データのデータ操作機能をＷｅｂブラウザ１０に提供する。

初期ページ生成機能は初期ページ生成機能２０２によって行う。初期ページはＷｅｂブラウザが読み込むものであり、本発明によるＷｅｂアプリケーションを実行する際に最初に読み込むべきページであり、アプリケーションプロバイダ３０からアプリスクリプト３２を読み込むことと、データプロバイダ２０のデータ操作機能を利用するのに必要な設定が記述されたものである。

データ操作機能はデータＡＰＩ機能２０４により実行され、Ｗｅｂブラウザ１０からのデータ操作要求をＷｅｂサーバ２０１により受信すると、データ操作要求に応じたデータ操作を、秘匿対象データ２０５に対して実行し、その結果を要求もとのＷｅｂブラウザ１０に返信する処理を行うものである。 一方、アプリケーションプロバイダ３０は、ネットワークを介してＷｅｂブラウザ１０からの処理要求を受け付け、処理要求に応じたアプリスクリプトを返信するＷｅｂサーバ３１と、本システムによるＷｅｂアプリケーションの機能のうちユーザインタフェースの機能を提供するプログラムであるアプリスクリプト３２とから構成される。このアプリスクリプト３２等のプログラムは、通常、プロバイダ３０を構成する情報処理装置の二次記憶装置に記憶されている。

アプリケーションプロバイダはＷｅｂブラウザ１０からの要求に応じてアプリスクリプトを提供する機能を提供する。Ｗｅｂブラウザ１０からのアプリスクリプト取得要求をＷｅｂサーバ３１が受信すると、アプリスクリプト取得要求に応じたアプリスクリプト３２を要求元のＷｅｂブラウザ１０に返送する処理を行うものである。

実施例１のシステムはＷｅｂブラウザ１０とデータプロバイダ２０およびアプリケーションプロバイダ３０との間でネットワークを介して通信を行いながら、データの操作処理（データの作成、編集、参照、削除）に関してはデータプロバイダ２０のデータＡＰＩ機能２０４を利用し、ユーザインタフェース機能についてはアプリケーションプロバイダ３０の提供する機能を利用するアプリケーション実行環境をユーザに提供する。

Ｗｅｂブラウザ１０はデータプロバイダ２０やアプリケーションプロバイダ３０との通信処理を行うための通信処理部１７と、利用者により操作された入力装置による入力や、画面表示処理を行うための画面入出力部１６と、アプリケーションプロバイダ３０より提供されるアプリスクリプト３２を実行処理するためのスクリプトエンジン１１と、Ｗｅｂサーバ２０１により提供され、アプリスクリプト３２により操作されるＨＴＭＬ１８を処理するためのＤＯＭハンドラ１２と、データプロバイダ２０のデータＡＰＩ機能を介して秘匿対象データ２０５にアクセスするためのデータアクセサ１３と、データアクセサ１３により取得したデータを管理するための秘匿データ管理部１４と、秘匿データ管理部が管理する秘匿データ情報を記録する符番表１５とから構成される。スクリプトエンジンはアプリケーションプロバイダ３０から提供されるアプリスクリプト３２の内容を読み取りながら動作し、ＤＯＭハンドラ１２は画面表示対象のＨＴＭＬ１８を読み取りながら動作する。スクリプトエンジン１１等のＷｅｂブラウザ内の構成要素であるプログラムは通常、Ｗｅｂブラウザ１０を構成する情報処理装置の二時記憶装置に記憶され一時記憶装置に読み込まれた後、ＣＰＵで実行される。

以下、実施例１のシステムの処理手順を具体的に説明する。

ここでは単純な顧客管理アプリケーションを例に説明する。例示する顧客管理アプリケーションはデータプロバイダ２０の秘匿対象データ２０５として記録される顧客管理情報の一覧を表示する機能と、新規に顧客管理情報を作成し秘匿対象データ２０５内に保存する機能とを有するものとする。

図３に顧客管理アプリケーションを実行するための（データプロバイダ２０の初期ページ生成機能２０２によって生成される）初期ページの一例を示す（ただし、説明のため左端に行番号を付与してある）。２行目から１０行目までに、顧客管理情報の一覧を表示するためのｔａｂｌｅ要素が記述されており、１１行目から１９行目までに新規顧客管理情報を作成するための入力欄のためのｆｏｒｍ要素が記述されており、２０行目にアプリスクリプトを読み込むためのｓｃｒｉｐｔ要素が記述されている。

顧客管理情報の一覧を表示するためのｔａｂｌｅ要素は図３の状態では中身の情報がない状態であるが、アプリスクリプトの動作によりデータプロバイダ２０から顧客情報の一覧が取得され、その内部に取得した顧客情報が挿入される。
例示する顧客管理アプリケーションを実現するアプリスクリプト３２のうちデータプロバイダ２０にアクセスして顧客情報を取得しその一覧を表示する処理のためのスクリプトの一例を図４に、利用者により入力された情報に基づき新規に顧客管理情報を作成し秘匿対象データ２０５内に保存する処理のためのスクリプトの一例を図５にそれぞれ示す（ただしそれぞれ説明のため左端に行番号を付与してある）。

以下、図４のスクリプトの処理手順にそって、データプロバイダからデータを受信する処理フローと、受信したデータを画面表示する処理フローを説明する。
まずデータプロバイダからデータを受信する処理を図６のフローに従って説明する。

図４のスクリプト例では4行目の「Ｃｕｓｔｏｍｅｒ．ｆｉｎｄ＿ａｌｌ();」の部分がデータアクセサにより顧客情報の一覧をデータプロバイダからデータを受信する処理の命令に相当し、図６のステップ６−１０１に相当する。
アプリスクリプトが４行目のような命令によりデータアクセサにデータ取得呼び出しを行うと、データアクセサはアプリスクリプトからの命令に応じてデータプロバイダ２０に対しデータ取得要求を送信する（ステップ６−２０１）。4行目の例では、データ取得要求は顧客情報の一覧を取得することを表したものであり、例えばＳＱＬ文により「ＳＥＬＥＣＴ ＊ ＦＲＯＭ ＣＵＳＴＯＭＥＲＳ」のように表される（秘匿対象データ２０５が一般的なＲＤＢにより構成され、顧客情報を表すテーブルの名前がＣＵＳＴＯＭＥＲＳの場合）。

データプロバイダ２０はデータ取得要求を受信すると（ステップ６−３０１）データＡＰＩ機能２０４によりこれを処理し、秘匿対象データ２０５より顧客情報一覧を取得し（ステップ６−３０２）、要求元のデータアクセサ１３に返信する（ステップ６−３０３）。

データアクセサ１３はデータプロバイダ２０よりデータ取得要求の結果を受信すると（ステップ６−２０２）、結果の値すべてに対し符番処理を行う（ステップ６−２０３）。符番処理についてはこの後説明するが、アプリスクリプト３２に対して得られた値を直接参照させないために値の代わりに対応する符番をアプリスクリプト３２に取得結果として渡すために行う。

そして、符番処理によって得られた値を呼び出しもとのアプリスクリプト３２に返す（ステップ６−２０４、６−１０２）。

ステップ６−２０３で行われる符番処理について、図１０（ａ）に示す処理フローを用いて説明する。ただし、この後の本実施例の説明において、符番処理はステップ６−２０３以外の箇所でも利用する。

符番処理はＷｅｂブラウザ１０の秘匿データ管理部１４によって行われる。

秘匿データ管理部１４は、データプロバイダ２０が保持する秘匿対象データのように、アプリスクリプト３２に対し直接参照させないデータを、符番処理対象として与えられると、はじめに新規に符番を生成する（ステップ１０ａ−１）。符番は符番表１５のどのレコードの符番情報とも重複しない値のものであればどのような値でもよく、例えば１ずつ増加する正数値でよい。

図１１は符番表の一例を示しており、符番として１ずつ増加する正数値を用いている（１１−ｃ１）。

次に生成した符番と、与えられた符番対象データをもつレコードを作成し符番表１５に記録する（ステップ１０ａ−２）。そして、生成した符番を符番処理要求元に返す（ステップ１０ａ−３）（ステップ６−２０３の例ではデータアクセサ１３に返す）。

次に、符番処理したデータプロバイダからの受信データを画面表示する処理を図８のフローに従って説明する。

画面表示する処理はアプリスクリプト３２からＤＯＭ ＡＰＩを通じてＤＯＭハンドラ１２が処理する。

図４のスクリプト例の５〜１４行目において、符番処理したデータプロバイダ２０から受信した顧客情報一覧データを繰り返し一レコードずつ処理し、各々のレコードについてカラムの値を画面表示中のテーブルのレコードのカラムの値として表示する処理を行っている。１０行目の「ｔｄ．ｔｅｘｔＣｏｎｔｅｎｔ ＝ ｃｕｓｔｏｍｅｒ[ＣＵＳＴＯＭＥＲ＿ＡＴＴＲＳ[ｊ]];」の部分が画面表示のテーブルレコードのカラムの値として、受信したレコードのカラムの値を設定しようとしている部分となり、図８のフローの初期状態に相当する。

本実施例のＤＯＭハンドラ１２は一般的なＷｅｂブラウザが具備するＤＯＭハンドラに修正を加えたものである。一般的なＷｅｂブラウザが具備するＤＯＭハンドラの場合、ステップ８−１のような設定対象値の種類による処理判別をせず、即、設定対象値を指定属性の値として設定する（ステップ８−３０１の動作がこれにあたる）。本実施例のＤＯＭハンドラ１２は、設定対象値として符番や関数が与えられた場合、与えられた対象値に基づいて設定値を生成し、設定処理を行う。

設定対象値が関数の場合（ステップ８−２０１〜８−２０５）の処理説明は後で行う。

設定対象値が符番の場合、まず演算処理中フラグの値がＯＮになっているか否かを調べる（ステップ８−１０１）。演算処理中フラグは設定対象値が関数の場合にその値がＯＮに設定されるものであり、その意味については設定対象値が関数の場合の処理説明において行う。

演算処理中フラグがＯＮの場合はそのまま処理を終了する。

演算処理中フラグがＯＦＦの場合、設定対象値の符番に対し復号処理を行い、符番に対応する元の値（この例ではデータプロバイダの秘匿対象データから取得した顧客情報の値）を取り出す（ステップ８−１０２）。復号処理の詳細についてはこの後説明する。

次に復号処理の結果として得た値を指定された属性の値として設定する（ステップ８−１０３）。この処理は通常のＤＯＭハンドラにおける属性設定処理（ステップ８−３０１に相当）と同じである。

ただし、設定対象のＤＯＭノードがリンク、画像、インラインフレーム、スクリプト要素などを示すＤＯＭノード（具体的にはＡタグＩＭＧタグ、ＩＦＲＡＭＥタグ、ＳＣＲＩＰＴタグ）の場合、そのデータ取得先（ＩＭＧタグでは画像の取得先、ＩＦＲＡＭＥタグではＨＴＭＬの取得先、ＳＣＲＩＰＴタグではスクリプトの取得先）のＵＲＬを示す属性が設定対象である場合は、設定処理は行わない。これらのＤＯＭノード属性に値を設定すると、それに伴い通信処理が発生し、指定データが外部に送信されてしまうが、上記の設定処理の中止処理により、データ漏洩を防止する。

そして、対象ＤＯＭノードに対し、アプリスクリプト３２に対し秘匿すべきデータが設定されたことを記録するため、秘匿値設定フラグを設定する（ステップ８−１０４）。このフラグは後にＤＯＭノード属性値取得処理を行う際に利用される。

ステップ８−１０２に記載の、符番復号処理を図１０（ｂ）のフロー図を用いて説明する。

符番復号処理はＷｅｂブラウザ１０の秘匿データ管理部が、符番表を参照しながら行う。秘匿データ管理部は符番復号処理において、符番を指定されると、符番表を参照し、指定された符番を持つレコードを検出し（ステップ１０ｂ−１）、検出したレコードの値を返す（ステップ１０ｂ−２）。例えば、符番表が図１１の符番表例の状態であったとき、指定された符番が２である場合、レコード１１−ｒ２を検出し、その秘匿対象値カラムの値”京都府”を復号結果として返す。

以上の処理により、アプリスクリプト３２はデータプロバイダ２０が保持する秘匿対象データよりデータを取得し、画面表示処理を行うことができる。ただし、取得したデータは符番処理されており、直接値を参照することはできず、かつ、画面表示処理においては元の値を表示することが可能となっている。

以下、図５のスクリプトの処理手順にそって、利用者により入力された情報を取得する処理フローと、取得した入力情報をデータプロバイダに保存する処理フローを説明する。

まず利用者により入力された情報を取得する処理を図９のフローに従って説明する。

図５のスクリプトの３行目〜９行目で図３の初期ページの１２行目から１９行目に準備済みの入力用ＤＯＭノード（具体的にはＩＮＰＵＴ要素）の値を取得し、保存対象の顧客情報としてまとめる処理が記載されており、７行目の「ｃｕｓｔｏｍｅｒ[ｅｌｅｍｅｎｔ．ｎａｍｅ] ＝ ｅｌｅｍｅｎｔ．ｖａｌｕｅ;」の部分が入力用ＤＯＭノードから値取得処理を示しており、図９のフローの初期状態に相当する。

前記の通り、本実施例のＤＯＭハンドラ１２は一般的なＷｅｂブラウザが具備するＤＯＭハンドラに修正を加えたものである。一般的なＷｅｂブラウザが具備するＤＯＭハンドラの場合、ステップ９−１のような対象ＤＯＭノードに秘匿値が設定済みか否かを判定する処理をせず、即、対象ＤＯＭノードの指定属性の値を返す（ステップ９−２０１の動作がこれにあたる）。本実施例のＤＯＭハンドラ１２は、対象ＤＯＭノードに秘匿値が設定済みである場合、指定属性の値に対し符番処理を行い、対応する符番を返す。

ＤＯＭハンドラ１２はＤＯＭノード属性値取得処理において、はじめに対象ＤＯＭノードに秘匿値が設定されているか否かを示すフラグがＯＮであるか否かを判定する（ステップ９−２０１）。フラグがＯＦＦである場合、対象ＤＯＭノードの指定属性の値を返す（ステップ９−２０１）。フラグがＯＮである場合、対象ＤＯＭノードの指定属性の値を取り出し、符番処理を行う（ステップ９−１０１）。符番処理は前述と同様、図１０（ａ）のフローに従って行う。そして、符番処理の結果生成された符番をＤＯＭノード属性取得処理の呼び出し元に返す（この例の場合、７行目のｃｕｓｔｏｍｅｒ[ｅｌｅｍｅｎｔ．ｎａｍｅ]の値として設定される）。

次に符番処理した利用者により入力された情報をデータプロバイダに保存する処理を図７のフローに従って説明する。

図５の１０行目の「ｃｕｓｔｏｍｅｒ．ｓａｖｅ();」が、スクリプトの３行目〜９行目によって生成された保存対象情報をデータプロバイダ２０の秘匿対象データに保存する処理を示しており、ステップ７−１０１に相当する。アプリスクリプト３２が１０行目のような命令によりデータアクセサ１３にデータ保存呼び出しを行うと（ステップ７−１０１）、データアクセサ１３はアプリスクリプト３２から渡される保存対象の情報に対し、復号処理を行う（ステップ７−２０１）。復号処理は前述と同様、図１０（ｂ）のフローに従って処理する。ただし、保存対象の情報が符番でない場合は、符号処理をせずそのままの値を保存対象情報として処理する。

符番復号処理により秘匿対象の元の値と置き換えられた保存対象情報を得ると、次にデータプロバイダ２０に対し保存対象情報を含むデータ保存要求を送信する（ステップ７−２０２）。

１０行目の例では、データ保存要求は利用者による入力値に基づく新規顧客情報レコードを保存することを表したものであり、例えばＳＱＬ文により「ＩＮＳＥＲＴ ＩＮＴＯ ＣＵＳＴＯＭＥＲＳ(ｎａｍｅ，ｏｒｄｅｒ，ａｄｄｒｅｓｓ，ｃｏｎｔａｃｔ，ｓａｌｅｓｅｐｅｒｓｏｎ) ＶＡＬＵＥＳ('ｃｏｍｐａｎｙ３'，１０００，'大阪府'，'０１Ｘ−２ＹＹＹ−３ＺＺＺ'，'ｓａｌｅｓｅｐｅｒｓｏｎ３')」のように表現される（一般的なＲＤＢにより構成され、顧客情報を表すテーブルの名前がＣＵＳＴＯＭＥＲＳの場合）。

データプロバイダ２０はデータ保存要求を受信すると（ステップ７−３０１）データＡＰＩ機能２０４によりこれを処理し、秘匿対象データ２０５に受信した新規顧客情報を保存し（ステップ７−３０２）、要求元のデータアクセサに保存結果を返信する（ステップ７−３０３）。

データアクセサ１３はデータプロバイダ２０よりデータ保存要求の結果を受信すると（ステップ７−２０３）、受信した保存結果を呼び出しもとのアプリスクリプト３２に返す（ステップ７−２０４、７−１０２）。

以上の処理手順により、利用者により入力された情報をデータプロバイダ２０に保存することができる。ただし、アプリスクリプト３２に対しては利用者により入力された情報は直接参照できず、データプロバイダ２０以外のサーバ等に送信処理が試みられても元の値とは関係のない符番データが送信されることとなるため、データ漏洩を防止することができる。

以上の手順による実施例により、データプロバイダ２０が保持するデータや、利用者により入力されたデータを符番処理によりアプリスクリプト３２に対し秘匿化しながら、それらのデータを画面表示したり、データプロバイダ２０に保存したりすることを可能な機能をもったデータ分離モデルアプリケーションを構成することができる。

実施例１では、秘匿すべきデータ（データプロバイダ２０から取得したデータと、利用者からの入力データ）をアプリスクリプト３２に直接参照させることなく、画面上に表示したり、データプロバイダ２０に保存することができたが、通常のアプリケーション処理では取得したデータに演算処理を行い、その結果を画面表示したり、データ保存したりすることが必要となる。

しかしながら、上記の処理方式では、アプリスクリプト３２は秘匿データに対しては直接値を参照することが不可能なため、演算処理を行うこともできない。

そこでＤＯＭノード属性やデータアクセサ１３に渡す保存対象データとして、演算処理を表す関数を渡すことにより、演算結果を表示したりデータ保存したりすることを可能とする。

ＤＯＭノード属性に対し関数が渡された場合、当該関数の実行中は符合値を参照する場合は符番に対応する値を参照することができるようにし、関数の実行結果を取得した直後に再び符合はそのまま符番とし、対応する値は取得できないものとする。そして関数の実行結果として取得した演算結果をＤＯＭノード属性の値として設定し、画面に反映させる。

ただし、当該演算処理を表現する関数内でＤＯＭノード属性に秘匿データを設定する処理があると符番に対応する値そのものとして設定されてしまうため、演算処理関数の実行中はＤＯＭノード属性に対して値を設定されても無視して設定されないようにする。
上記の処理手順を、図８のフローにそって説明する。

ＤＯＭノード属性に対して関数が渡された場合、ステップ８−２０１に進み、現行の処理が始まる前にＤＯＭノード属性に対して関数が渡されているか否かを判定するための演算処理実行中フラグがＯＮであるか否かを判定する。演算処理実行中フラグがＯＮの場合は、現行の処理が始まる前にＤＯＭノード属性設定処理で関数が渡され、その関数が実行中であるため、設定処理を中断し終了する。演算処理実行中フラグがＯＦＦの場合、まず、演算処理実行中フラグをＯＮに設定する（ステップ８−２０２）。

次に関数実行中は符番が符番復号処理された値として評価されるよう、符番オブジェクトを変更する。この符番オブジェクトの変更は、例えば符番をＪａｖａＳｃｒｉｐｔのオブジェクトとして表現する場合、式の評価中の値を表現する関数ｖａｌｕｅＯｆの処理を変更し、復号処理した値を返すようにすることで実現できる。

そして、指定された関数を実行して結果を取得し（ステップ８−２０４）、演算処理実行中フラグをＯＦＦに戻す（ステップ８−２０５）。後は、ノード属性設定処理の値として符番値が設定された場合と同様に、結果として得た値を指定された属性値として設定し（ステップ８−１０３）、対象ノードに秘匿値設定フラグを付与して（ステップ８−１０４）処理を終了する。

データプロバイダ２０へのデータ保存処理において関数が渡された場合も、上記と同様に、当該関数の実行中は符合値を参照する場合は符番に対応する値を参照することができるようにし、関数の実行結果を取得した直後に再び符合はそのまま符番とし、対応する値は取得できないものとする。そして関数の実行結果として取得した演算結果を保存対象データとして他のカラムの値とともに設定し、送信する。送信後の保存処理は前述のデータ保存処理と同様である。

上記の処理手順により、秘匿データを対象にした場合でも演算処理を行った結果を画面表示したりデータ保存したりすることが可能となり、アプリケーションに対する制限を抑えることが可能となる。

実施例１において、ＤＯＭノード属性設定処理で秘匿対象データ（符番や関数）が対象値として設定された場合（図８のフローのステップ８−１０３）に、設定処理により通信を伴うようなＤＯＭノード属性が設定対象である場合は設定処理をスキップすることによってデータ漏洩を防止していたが、一般的に普及しているＷｅｂブラウザではこれらのＤＯＭノード属性以外にも、ｗｉｎｄｏｗ．ｏｐｅｎ関数や、ｄｏｃｕｍｅｎｔ．ｌｏｃａｔｉｏｎ属性など、呼び出し処理や設定処理に伴って通信処理が発生する要素がＪａｖａＳｃｒｉｐｔエンジンの機能に与えられている。そのため、これらの機能に対しても秘匿対象データが渡された場合は処理をスキップするように機能変更することで、さらに本発明の実施形態によるアプリケーションにおける、データ漏洩を防止することができる。

実施例１〜３において、データプロバイダ２０から取得したデータや利用者から入力された値をアプリスクリプトに対して直接参照できなくするために符番処理を用いていたが、代わりに暗号処理を利用することもできる。符番処理では符番から秘匿対象の値を復元するために符番表が必要であったが、暗号処理を用いることで符番表が不要となり、Ｗｅｂブラウザ１０が動作するコンピュータ装置における一時記憶装置の記憶領域の使用量を低減することができる。ただし、一般に暗号処理のほうが符番処理よりも計算量がかかるため、記憶領域とＣＰＵ性能を鑑みて、処理方法を選定するべきである。

また、暗号・復号処理はＷｅｂブラウザではなく、データプロバイダ２０内で行ってもよく、データプロバイダ２０内の秘匿対象データとしてはじめから暗号化した値を記録してもよい。後者の場合、表示処理や演算処理など、元の値が必要なときに復号処理を行う。

実施例１〜４において、ＤＯＭハンドラ、データアクセサ、秘匿データ管理部、符番表の機能はＷｅｂブラウザに組み込まれた機能として説明したが、これらの機能をスクリプトにより実装し、初期ページにおいてそのスクリプトをアプリスクリプトよりも前に読み込まれるように設定することで、アプリスクリプトが実行されるときに実施例１〜４の処理手順を実現する方法をとることもできる。

ＤＯＭハンドラについては既存のＤＯＭ ＡＰＩを実施例１に記載の処理手順が動作するよう上書き定義することで対処する。データアクセサは一般的に普及しているＷｅｂブラウザでＪａｖａＳｃｒｉｐｔエンジンに対して提供される画面遷移なしにサーバとの通信処理を可能とするＸＭＬＨｔｔｐＲｅｑｕｅｓｔとよばれるオブジェクトを利用することでデータプロバイダとの通信処理を記述することができ、実施例１に記載の処理手順が動作するよう定義することで対処する。秘匿データ管理部、符番表については一般的にＷｅｂブラウザからその実現を支援する機能はないので、実施例１に記載の処理手順をＪａｖａＳｃｒｉｐｔのプログラムとして実装することで対処する。

以上の処理方式をとることにより、実施例１〜４に記載の機能を具備するＷｅｂブラウザ１０の代わりに、一般的に普及しているＷｅｂブラウザを本発明の実施形態のＷｅｂアプリケーションを利用するクライアント装置として利用することができる。

ただし、ＪａｖａＳｃｒｉｐｔとしてこれらの機能を実現した場合、悪意あるアプリスクリプトにより再度ＤＯＭハンドラ１２やデータアクセサ１３の処理が上書き定義されてしまい、秘匿データが漏洩されてしまう可能性がある。

そのため、本実施例では、図１２のようにＷｅｂブラウザ１０が読み込むアプリスクリプトに対しフィルタ処理を行うフィルタプロキシ４０を配置する構成とし、そのフィルタ処理により上記のような再上書き定義を防止する。
フィルタ処理では、アプリスクリプト３２内の変数や関数など全識別子に対し一定の文字列を付与する処理を行う。こうすることで、たとえＤＯＭノードを表すオブジェクトを変更するようなプログラムが記述されていても識別子が一致しなくなるため、それが機能させないことができる。

以上のように本発明の実施形態によれば、データ分離モデルによるアプリケーションにおいて、悪意あるアプリスクリプトによるデータプロバイダ上データの外部漏洩を防止することができ、利用者はＷｅｂアプリケーションを安心して利用することができるようになる。

また、Ｗｅｂアプリケーション提供者側にデータを置く場合であっても、データプロバイダのデータはアプリケーション提供者側やその他組織に漏洩しない。

１０：Ｗｅｂブラウザ、２０：データプロバイダ、３０：アプリケーションプロバイダ、４０：フィルタプロキシ。

Claims (22)

1. クライアントと、前記クライアントとネットワークを介して接続され、前記クライアントのデータを管理するデータサーバと、前記クライアントとネットワークを介して接続され、前記クライアントに対してアプリケーション機能を提供するアプリケーションサーバと、を備えるシステムにおいて、
   前記アプリケーションサーバは、
   前記クライアントへアプリケーション機能としてのアプリケーションプログラムを送信し、
   前記クライアントは、
   前記データサーバから秘匿化処理が施されたデータを受信し、または、前記データサーバから受信したデータに秘匿化処理を施し、
   前記アプリケーションプログラムに対して秘匿化処理が施されたデータを参照させることを特徴とするシステム。
2. 請求項１記載のシステムにおいて、
   前記クライアントは、前記アプリケーションプログラムに対して秘匿化処理が施されていないデータを参照させないことを特徴とするシステム。
3. 請求項１または２記載のシステムにおいて、
   前記クライアントは、前記秘匿化処理が施されたデータの秘匿化を解除してデータを表示することを特徴とするシステム。
4. 請求項１から３の何れか記載のシステムにおいて、
   前記クライアントは、前記アプリケーションプログラムが前記秘匿化処理が施されたデータを参照して処理を実行した後、前記秘匿化処理を解除して前記アプリケーションプログラムにより処理されたデータを表示することを特徴とするシステム。
5. 請求項１から４の何れか記載のシステムにおいて、
   前記クライアントは、利用者からの情報の入力を受け付ける入力部から情報が入力された場合には、前記入力された情報を前記アプリケーションプログラムに参照させないことを特徴とするシステム。
6. 請求項１から５の何れか記載のシステムにおいて、
   前記クライアントは、前記アプリケーションプログラムが前記データサーバから送信されたデータを外部へ送信する送信処理を含む場合には、前記送信処理を中止することを特徴とするシステム。
7. 請求項１から６の何れか記載のシステムにおいて、
   前記クライアントは、利用者からの情報の入力を受け付ける入力部から情報が入力された場合には、前記入力された情報を前記アプリケーションプログラムに参照させないことを特徴とするシステム。
8. 請求項７記載のシステムにおいて、
   前記クライアントは、前記アプリケーションプログラムが前記入力された情報を外部へ送信する送信処理を含む場合には、前記送信処理を中止することを特徴とするシステム。
9. 請求項３記載のシステムにおいて、
   前記クライアントは、前記秘匿化処理を解除するための符番表を備えることを特徴とするシステム。
10. 請求項１から９の何れか記載のシステムにおいて、
    前記秘匿化処理は、暗号化処理または符号処理であることを特徴とするシステム。
11. データを管理するデータサーバおよびアプリケーション機能を提供するアプリケーションサーバとネットワークを介して接続されたクライアントにおいて、
    前記クライアントは、
    前記アプリケーションサーバからアプリケーション機能としてのアプリケーションプログラムを受信し、
    前記データサーバから秘匿化処理が施されたデータを受信し、または、前記データサーバから受信したデータに秘匿化処理を施し、
    前記アプリケーションプログラムに対して秘匿化処理が施されたデータを参照させることを特徴とするクライアント。
12. 請求項１１記載のクライアントにおいて、
    前記アプリケーションプログラムに対して秘匿化処理が施されていないデータを参照させないことを特徴とするクライアント。
13. 請求項１１または１２記載のクライアントにおいて、
    前記秘匿化処理が施されたデータの秘匿化を解除してデータを表示することを特徴とするクライアント。
14. 請求項１１から１３の何れか記載のクライアントにおいて、
    前記アプリケーションプログラムが前記秘匿化処理が施されたデータを参照して処理を実行した後、前記秘匿化処理を解除して前記アプリケーションプログラムにより処理されたデータを表示することを特徴とするクライアント。
15. 請求項１１から１４の何れか記載のクライアントにおいて、
    利用者からの情報の入力を受け付ける入力部から情報が入力された場合には、前記入力された情報を前記アプリケーションプログラムに参照させないことを特徴とするクライアント。
16. 請求項１１から１５の何れか記載のクライアントにおいて、
    前記アプリケーションプログラムが前記データサーバから送信されたデータを外部へ送信する送信処理を含む場合には、前記送信処理を中止することを特徴とするクライアント。
17. 請求項１１から１６の何れか記載のクライアントにおいて、
    利用者からの情報の入力を受け付ける入力部から情報が入力された場合には、前記入力された情報を前記アプリケーションプログラムに参照させないことを特徴とするクライアント。
18. 請求項１７記載のクライアントにおいて、
    前記アプリケーションプログラムが前記入力された情報を外部へ送信する送信処理を含む場合には、前記送信処理を中止することを特徴とするクライアント。
19. 請求項１３記載のクライアントにおいて、
    前記秘匿化処理を解除するための符番表を備えることを特徴とするクライアント。
20. 請求項１１から１９の何れか記載のクライアントにおいて、
    前記秘匿化処理は、暗号化処理または符号処理であることを特徴とするクライアント。
21. 請求項１から１０の何れか記載のシステムにおいて、
    前記クライアントはＷｅｂブラウザであり、前記アプリケーションプログラムはアプリスクリプトであることを特徴とするシステム。
22. 請求項１１から２０の何れか記載のクライアントはＷｅｂブラウザであり、前記アプリケーションプログラムはアプリスクリプトであることを特徴とするクライアント。

Images