以下、図面を参照して開示の技術の実施形態の一例を詳細に説明する。
〔第1実施形態〕
図1には、本実施形態に係るコンピュータ・システム10が示されている。コンピュータ・システム10は、複数台の端末装置12と、サービス提供装置14と、端末装置12とサービス提供装置14の間に設けられた中継装置16と、を備えている。なお、図1ではサービス提供装置14を1台のみ示しているが、端末装置12と同様にサービス提供装置14も複数台設けられていてもよい。
複数台の端末装置12は、例えばPC(Personal Computer)や携帯端末から成り、企業内の業務遂行のために企業内に設置され、ウェブページ閲覧部22を各々備えている。ウェブページ閲覧部22は、サービス提供装置14へリクエストを送信することで、サービス提供装置14へサービスの提供を要求する。また、ウェブページ閲覧部22は、サービス提供装置14から受信したレスポンスに含まれるウェブページのデータをウェブページとして端末装置12のディスプレイ72(図2参照)に表示させる。また、ウェブページ閲覧部22は、サービス提供装置14から受信したレスポンスにスクリプトが含まれている場合、当該スクリプトを実行する。
サービス提供装置14は、端末装置12に対してウェブ上で所定のサービスを提供する装置である。サービス提供装置14は、例えばサーバ・コンピュータから成り、端末装置12が設置された企業外に設置され、所定のサービスを提供するための処理を行うサービス提供部24を備えている。サービス提供部24は、所定のサービスとして、ウェブ上で提供可能な任意のサービスを適用可能であるが、本実施形態では、端末装置12からサービス提供装置14へのファイルのアップロードが前提となるサービスを提供する。ファイルのアップロードが前提となるサービスとしては、例えばアップロードされたファイルを公開、或いは共有するサービスや、アップロードされたファイルに対して何らかの処理を行って結果を返すサービス等が挙げられる。
中継装置16は、端末装置12と同一の企業内に設置されており、中継サーバ18及びファイル管理サーバ20を備えている。中継サーバ18は、端末装置12とサービス提供装置14との間の情報(リクエスト/レスポンス)の送受を中継するサーバであり、リクエスト受付部26、リクエスト解析部28、ファイル取得部30、リクエスト生成部32、リクエスト転送部34を備えている。また、中継サーバ18は、レスポンス受付部36、レスポンス解析部38、スクリプト付加部40、レスポンス転送部42、利用者情報管理部44及びURL管理部46を備えている。
なお、レスポンス解析部38は開示の技術における解析部の一例であり、スクリプト付加部40は開示の技術における付加部の一例である。また、リクエスト解析部28、ファイル取得部30、リクエスト生成部32及びリクエスト転送部34は、開示の技術におけるファイル送信部の一例である。
リクエスト受付部26は、端末装置12からサービス提供装置14へ送信されたリクエストを受け付ける。リクエスト解析部28は、リクエスト受付部26によって受け付けられたリクエストを解析し、リクエストを送信した端末装置12を操作している利用者の利用者IDを前記リクエストから取得する。また、リクエスト解析部28は、前記リクエストがファイルのアップロードを要求するアップロード・リクエストの場合に、アップロード対象のファイルの属性情報を前記アップロード・リクエストから取得する。利用者情報管理部44は、リクエスト解析部28によって取得された利用者IDを記憶する。
ファイル取得部30は、リクエスト解析部28によってアップロード対象のファイルの属性情報がアップロード・リクエストから取得された場合に、アップロード対象のファイルのデータをファイル管理サーバ20から取得する。リクエスト生成部32は、リクエスト受付部26によって受け付けられたリクエストを整形することで、サービス提供装置14へ送信するリクエストを生成する。またリクエスト生成部32は、ファイル取得部30によってアップロード対象のファイルのデータが取得された場合、取得されたアップロード対象のファイルのデータを付加することで、サービス提供装置14へ送信するアップロード・リクエストを生成する。
リクエスト転送部34は、リクエスト生成部32によって生成されたリクエストをサービス提供装置14へ転送する。URL管理部46は、端末装置12からのリクエストの送信先としてのサービス提供装置14のURL(Uniform Resource Locator)を記憶する。
レスポンス受付部36は、サービス提供装置14から端末装置12へ送信されたレスポンスを受け付ける。レスポンス解析部38は、レスポンス受付部36によって受け付けられたレスポンスを解析し、セッションIDを前記レスポンスから取得する。ところで、セキュイティ面から、イントラ(個人や企業内)のリソースの場所が外部サービスに渡らないよう、ブラウザに制限がかっており(仕様)、通常のHTMLタグでは、ファイル選択において、利用者の誤操作を防ぐことはできない。このため、レスポンス解析部38は、レスポンス受付部36によって受け付けられたレスポンスに<input type="file">タグが含まれているか否かを探索する。利用者情報管理部44は、レスポンス解析部38によって取得されたセッションIDを、リクエスト解析部28によって取得された利用者IDと対応付けて記憶する。
スクリプト付加部40は、レスポンス解析部38により、レスポンスに<input type="file">タグが含まれているとの解析結果が得られた場合に、前記レスポンスに付加するスクリプトを生成し、生成したスクリプトをレスポンスに付加する。レスポンス転送部42は、レスポンス解析部38及びスクリプト付加部40による処理を経たレスポンスを端末装置12へ送信する。
ファイル管理サーバ20は、端末装置12からサービス提供装置14へのアップロードを予定しているファイルを管理するサーバであり、ファイル受付部48、ファイル管理部50及びファイル記憶部52を備えている。なお、ファイル管理部50は開示の技術におけるファイル管理部の一例であり、ファイル記憶部52は開示の技術における記憶部の一例である。
ファイル受付部48は、サービス提供装置14へのアップロードを予定しているファイルを端末装置12から受け付ける。ファイル管理部50は、ファイル受付部48によって受け付けられたファイルが機密性を有しないファイルか否かを判定する。ファイル記憶部52はファイルDB(データベース)54を記憶している。ファイル記憶部52は、ファイル管理部50によって機密性を有しないことが確認されたファイルを、当該ファイルのファイル管理サーバ20への送信を指示した利用者の利用者IDと対応付けてファイルDB54に格納する。
また、ファイル管理部50は、ファイル管理サーバ20へのファイルの送信を指示した個々の利用者毎に、ファイルDB54に格納されたファイル一覧を表すファイル一覧リストを生成し、生成した利用者毎のファイル一覧リストを中継サーバ18へ送信する。中継サーバ18へ送信された利用者毎のファイル一覧リストは、中継サーバ18の利用者情報管理部44に保存される。
端末装置12は、例えば図2に示すPC60で実現することができる。PC60はCPU62、メモリ64、HDD(Hard Disk Drive)やフラッシュメモリ等によって実現される不揮発性の記憶部68、通信I/F(インタフェース)部70を備えている。PC60はディスプレイ72、キーボード74及びマウス76が接続されており、通信I/F部70を介してコンピュータ・ネットワーク(例えば企業内LAN)82に接続されている。記憶部68にはブラウザのプログラム80が記憶されている。CPU62は、ブラウザのプログラム80を実行することで、図1に示すウェブページ閲覧部22として動作する。
サービス提供装置14は、例えば図2に示すアプリケーション・サーバ84で実現することができる。アプリケーション・サーバ84はCPU86、メモリ88、HDD(Hard Disk Drive)やフラッシュメモリ等によって実現される不揮発性の記憶部90、通信I/F部92を備えている。アプリケーション・サーバ84は通信I/F部92を介してコンピュータ・ネットワーク(例えばインターネット)96に接続されている。記憶部90にはサービス提供プログラム94が記憶されている。CPU86は、サービス提供プログラム94を実行することで、図1に示すサービス提供部24として動作する。
中継装置16のうちの中継サーバ18は、例えば図2に示すサーバ・コンピュータ100で実現することができる。サーバ・コンピュータ100はCPU102、メモリ104、HDD(Hard Disk Drive)やフラッシュメモリ等によって実現される不揮発性の記憶部106、通信I/F部108を備えている。サーバ・コンピュータ100は通信I/F部108を介してコンピュータ・ネットワーク82,96に各々接続されている。
記録媒体としての記憶部106には、サーバ・コンピュータ100を中継サーバ18として機能させるための中継プログラム110が記憶されている。CPU102は、中継プログラム110を記憶部106から読み出してメモリ104に展開し、中継プログラム110が有するプロセスを順次実行する。
中継プログラム110は、リクエスト受付プロセス112、リクエスト解析プロセス114、ファイル取得プロセス116、リクエスト生成プロセス118、リクエスト転送プロセス120及びレスポンス受付プロセス122を有する。また中継プログラム110はレスポンス解析プロセス124、スクリプト付加プロセス126、レスポンス転送プロセス128、利用者情報管理プロセス130及びURL管理プロセス132を有する。
CPU102は、リクエスト受付プロセス112を実行することで、図1に示すリクエスト受付部26として動作する。またCPU102は、リクエスト解析プロセス114を実行することで、図1に示すリクエスト解析部28として動作する。またCPU102は、ファイル取得プロセス116を実行することで、図1に示すファイル取得部30として動作する。またCPU102は、リクエスト生成プロセス118を実行することで、図1に示すリクエスト生成部32として動作する。またCPU102は、リクエスト転送プロセス120を実行することで、図1に示すリクエスト転送部34として動作する。
またCPU102は、レスポンス受付プロセス122を実行することで、図1に示すレスポンス受付部36として動作する。またCPU102は、レスポンス解析プロセス124を実行することで、図1に示すレスポンス解析部38として動作する。またCPU102は、スクリプト付加プロセス126を実行することで、図1に示すスクリプト付加部40として動作する。またCPU102は、レスポンス転送プロセス128を実行することで、図1に示すレスポンス転送部42として動作する。またCPU102は、利用者情報管理プロセス130を実行することで、図1に示す利用者情報管理部44として動作する。またCPU102は、URL管理プロセス132を実行することで、図1に示すURL管理部46として動作する。これにより、中継プログラム110を実行したサーバ・コンピュータ100が中継サーバ18として機能することになる。
中継装置16のうちのファイル管理サーバ20は、例えば図2に示すサーバ・コンピュータ134で実現することができる。サーバ・コンピュータ134はCPU136、メモリ138、HDD(Hard Disk Drive)やフラッシュメモリ等によって実現される不揮発性の記憶部140、通信I/F部142を備えている。サーバ・コンピュータ134は通信I/F部142を介してコンピュータ・ネットワーク82に接続されている。
記録媒体としての記憶部140には、サーバ・コンピュータ134をファイル管理サーバ20として機能させるためのファイル管理プログラム144と、ファイルDB54が記憶されている。CPU136は、ファイル管理プログラム144を記憶部140から読み出してメモリ138に展開し、ファイル管理プログラム144が有するプロセスを順次実行する。
ファイル管理プログラム144は、ファイル受付プロセス146及びファイル管理プロセス148を有する。CPU136は、ファイル受付プロセス146を実行することで、図1に示すファイル受付部48として動作する。またCPU136は、ファイル管理プロセス148を実行することで、図1に示すファイル管理部50として動作する。これにより、ファイル管理プログラム144を実行したサーバ・コンピュータ134が、ファイル管理サーバ20として機能することになる。なお、中継プログラム110及びファイル管理プログラム144は開示の技術における中継プログラムの一例である。
次に本第1実施形態の作用を説明する。前述のように、サービス提供装置14のサービス提供部24は、端末装置12からサービス提供装置14へのファイルのアップロードが前提となるサービスを提供している。このため、このサービスを業務で利用する場合、端末装置12を操作する利用者の不注意や判断ミス、操作ミス等により、機密性を有するファイルが企業内から誤って外部のサービス提供サーバへアップロードされる恐れがある。
機密情報の漏洩を抑制する技術として、機密性を有するファイルや当該ファイルが格納されたディレクトリを対象としてアクセス権を設定する技術が知られている。しかし、この技術は、機密性を有するファイルに対するアクセス権を有する利用者が、機密性を有するファイルを誤ってアップロードすることは防止できない。
また、他の技術として、中継サーバ18によるURLフィルタリング処理によって、アクセス可能なサイトを制限する技術がある。しかし、この技術は、利用者からのアクセス要求を許可するか遮断するかをURLに基づいて選択するものであり、アップロード対象のファイルが機密性を有しているか否かに基づいて、アップロード・リクエストを通過又は遮断することはできない。
また、他の技術として、アップロード・リクエストに含まれるアップロード対象のファイルが機密性を有しているか否かを中継サーバ18が判定し、アップロード・リクエストを通過又は遮断する処理を行うことも考えられる。しかし、この場合、中継サーバ18がアップロード・リクエストを受信する度に中継サーバ18に負荷が加わると共に、ファイルのアップロードに要する時間が長時間化するという問題が生ずる。特に、アップロード対象のファイルのサイズが大きい場合や、アップロード・リクエストが頻繁に送信された場合には、中継サーバ18に過大な負荷が加わり、コンピュータ・ネットワーク82内の通信が輻輳状態になる等の不具合が生ずる恐れもある。
このため、本第1実施形態では、アップロードを予定しているファイルが事前にファイル管理サーバ20で受け付けられ、ファイル管理サーバ20は、受け付けたファイルが機密性を有していないか否かを事前に判定する。そして、ファイル管理サーバ20は、機密性を有していないことを確認したファイルのみをファイルDB54に格納する。
また、中継サーバ18は、サービス提供装置14から端末装置12へのレスポンスのHTMLデータに、アップロード対象のファイルを指定する操作が行われることを意味するコード(<input type="file">タグ)が含まれているか否かを監視する。なお、<input type="file">タグはタイプ属性が"file"のフォームタグである。中継サーバ18は、前記レスポンスのHTMLデータに前記コードが含まれていた場合、アップロード対象のファイルの選択肢として、ファイルDB54に格納されたファイルを端末装置12のディスプレイ72に表示させるスクリプトを前記レスポンスに付加する。
このスクリプトは、利用者によってアップロード対象のファイルが選択されてアップロードが指示されると、サービス提供装置14へ送信するアップロード・リクエストに選択されたファイルの属性情報を設定する処理を端末装置12によって行わせる。中継サーバ18は、端末装置12からサービス提供装置14へのアップロード・リクエストを受信すると、当該リクエストに属性情報が設定されたファイルのデータをファイル管理サーバ20から取得し、前記リクエストに付加する。
以下、図3〜図10を参照し、本第1実施形態に係るコンピュータ・システム10において、サービス提供装置14が提供するサービスを利用するための一連の処理・利用者の操作について順に説明する。
本第1実施形態において、サービス提供装置14が提供するサービスは、端末装置12からサービス提供装置14へのファイルのアップロードが前提となるサービスである。このため、サービス提供装置14が提供するサービスを利用する場合、利用者は、サービス利用のための事前準備として、端末装置12を介し、アップロードを予定しているファイルを対応する監視フォルダに格納させる操作を行う(図3のステップ200も参照)。
監視フォルダは、ファイル管理サーバ20の記憶部140に、コンピュータ・システム10を利用する個々の利用者毎に設けられている。ファイル管理サーバ20のファイル受付部48は、何れかの監視フォルダに新たなファイルが格納されたか否かを常時監視している。上記のように、アップロードを予定しているファイルが何れかの監視フォルダに新たに格納されると、ファイル管理サーバ20では、図4に示すファイル管理処理が行われる。
ファイル管理処理のステップ250において、ファイル受付部48は、監視フォルダに新たに格納されたファイルを監視フォルダから取り出すと共に、ファイルが新たに格納された監視フォルダに対応する利用者の利用者IDを取得する。次のステップ252において、ファイル管理部50は、ファイル受付部48によって監視フォルダから取り出されたファイルに対し、予め設定されたキーワードが含まれているか否かを検索する等により、機密性の有無を判定する(図3のステップ202も参照)。なお、機密性の有無はキーワード検索によって判定することに限られるものではなく、例えばファイル名や属性情報を用いて判定する等のように、公知の種々の技術を適用可能である。
次のステップ254において、ファイル管理部50は、ステップ252における判定の結果に基づき、監視フォルダから取り出されたファイルが機密性の無いファイルか否かを判定する(図3のステップ204も参照)。監視フォルダから取り出されたファイルに、例えば"機密"や"confidential"等のキーワードが含まれていた場合には、当該ファイルは機密性有りと判断されてステップ254の判定が否定され、ステップ262へ移行する。この場合、ステップ262において、ファイル管理部50は、監視フォルダにファイルを格納する処理を行った端末装置12に対し、監視フォルダに格納されたファイルは機密性を有するのでファイルDB54には格納できない旨を通知するエラー情報を送信する。
一方、監視フォルダから取り出されたファイルが機密性を有していないと判定された場合、ステップ254の判定が肯定されてステップ256へ移行する。ファイル記憶部52に記憶されているファイルDB54には、コンピュータ・システム10を利用する個々の利用者毎に格納フォルダが設けられている。ステップ256において、ファイル管理部50は、監視フォルダから取り出されたファイルのデータを、ファイルDB54のうち、ファイル受付部48によって取得された利用者IDに対応する格納フォルダ内に格納する(図3のステップ206も参照)。
次のステップ258において、ファイル管理部50は、今回ファイルを新たに格納した格納フォルダに対応する特定の利用者のファイル一覧リストに、今回取り出したファイルの情報を追加する。ファイル一覧リストは、一例として図9(B)に示すように、個々の格納フォルダ毎に、格納フォルダに格納された各ファイルについて「ファイル名」、「チェック日時」、「パス名」(図示無し)の各属性情報が設定されている。そしてステップ260において、ファイル管理部50は、更新したファイル一覧リストを利用者IDと共に中継サーバ18に送信する(図3のステップ208も参照)。ファイル管理サーバ20から中継サーバ18へ送信されたファイル一覧リスト及び利用者IDは、中継サーバ18の利用者情報管理部44によって対応付けて保管される(図3のステップ210も参照)。
上記のようにして、アップロードを予定しているファイルのファイルDB54への格納が完了した後に、利用者は、サービス提供装置14に対してサービスの提供を要求する操作を端末装置12を介して行う(図3のステップ212も参照)。この操作は、例えば端末装置12上でブラウザ(ウェブページ閲覧部22)を起動し、アクセス先としてサービス提供装置14のURL(詳しくは、サービス提供装置14のサイトのうちアップロード画面のURL)を指定することによって為される。これにより、端末装置12からは、サービス提供装置14を宛先として、アップロード画面の配信を要求するリクエストが送信され、このリクエストが中継サーバ18で受信されることで、中継サーバ18では図5に示すスクリプト付加処理が行われる。
スクリプト付加処理のステップ270において、リクエスト受付部26は、端末装置12から受信したサービス提供装置14宛のリクエストを受け付ける。また、リクエスト解析部28はリクエスト受付部26によって受け付けられたリクエストを解析し、当該リクエストに設定されている利用者ID(リクエストを送信した端末装置12を操作している利用者のID)を取得する(図3のステップ214も参照)。利用者情報管理部44は、リクエスト解析部28によって取得された利用者IDを記憶する。また、リクエスト転送部34は、リクエスト受付部26によって受け付けられたリクエストを、サービス提供装置14へそのまま送信する。
サービス提供装置14は、端末装置12から送信されたリクエストを中継サーバ18経由で受信すると、当該リクエストで配信が要求されたアップロード画面のデータを記憶部90から読み出す。そしてサービス提供装置14は、記憶部90から読み出したアップロード画面のデータを、端末装置12宛のレスポンスに整形して送信する(図3のステップ216も参照)。
サービス提供装置14から送信されたリクエストが中継サーバ18で受信されると、スクリプト付加処理のステップ272において、レスポンス受付部36は、サービス提供装置14から受信した端末装置12宛のレスポンスを受け付る。また、レスポンス解析部38はレスポンス受付部36によって受け付けられたレスポンスを解析し、当該レスポンスに設定されているセッションIDを取得する(図3のステップ218も参照)。次のステップ274において、利用者情報管理部44は、レスポンス解析部38によって取得されたセッションIDを、先に記憶した利用者IDと対応付けて記憶する。
また、ステップ276において、レスポンス解析部38は、レスポンス受付部36によって受け付けられたレスポンスに<input type="file">タグが含まれているか否かを探索する。そしてステップ278において、スクリプト付加部40は、レスポンス解析部38による探索によって<input type="file">タグが発見されたか否か判定する(図3のステップ220も参照)。上記の<input type="file">タグは、レスポンスを受信した端末装置12において、端末装置12からサービス提供装置14へのアップロード対象のファイルを指定する操作が行われることを意味している。
ステップ278の判定が否定された場合、レスポンスを受信した端末装置12ではアップロード対象のファイルを指定する操作が行われないと判断できるので、ステップ278からステップ288へ移行する。ステップ288において、レスポンス転送部42は、サービス提供装置14からのレスポンスを端末装置12へそのまま(スクリプトを付加せずに)送信し、スクリプト付加処理を終了する。
一方、ステップ278の判定が肯定された場合は、レスポンスを受信した端末装置12ではアップロード対象のファイルを指定する操作が行われると判断できるので、ステップ278からステップ280へ移行する。ステップ280において、スクリプト付加部40は、レスポンス解析部38によって取得されたセッションIDと対応付けて利用者情報管理部44に記憶されている利用者IDを利用者情報管理部44から取得する。またスクリプト付加部40は、取得した利用者IDと対応付けて利用者情報管理部44に保管されているファイル一覧リストを利用者情報管理部44から読み出す。
次のステップ282において、スクリプト付加部40は、端末装置12でアップロード対象のファイルの選択が行われる際に、ステップ280で読み出したファイル一覧リストを端末装置12のディスプレイ72に表示させるスクリプトを生成する。スクリプト付加部40によって生成されるスクリプトの一例を図6,7に示す。図6,7において、スクリプト付加部40によって生成されるスクリプトは、破線で囲みかつ太字で示した部分である。
図6に示すスクリプトはアップロード画面(親画面)に関するスクリプトである。図9(A),(C)に示すように、アップロード画面150には、アップロード対象のファイルの候補を表示させるための「参照」ボタン152及びアップロードを指示するための「アップロード」ボタン154が設けられている。また、アップロード画面には、アップロード対象のファイルのパス名を表示するための表示欄156も設けられている。スクリプト付加部40によって生成される親画面に関するスクリプトには、「参照」ボタン152が選択された場合に新しいウインドウを開いてファイル一覧リスト画面(子画面)を呼び出すスクリプトが含まれている。また、リクエストの宛先と子画面との間でのデータの渡し方を定義するスクリプト、子画面からファイルのパス名を受け取るスクリプト、及び、「アップロード」ボタン154が選択された場合にリクエストを送信するスクリプトも含まれている。
また、図7に示すスクリプトは子画面に関するスクリプトである。図9(B)に示すように、ファイル一覧リスト画面160は、利用者名を示す文字列162及びファイル一覧リスト164が設けられている。なお、ファイル一覧リスト画面160は開示の技術におけるファイル指定画面の一例である。スクリプト付加部40によって生成される子画面に関するスクリプトには、子画面を生成するスクリプトが含まれている。また、ファイル一覧リスト164に表示された何れかのファイルが選択されると、選択されたファイルのパス名を親画面のスクリプトへ伝えるスクリプトも含まれている。スクリプト付加部40は、子画面を生成するスクリプトを、利用者情報管理部44から読み出したファイル一覧リストに基づいて生成する。
次のステップ284において、スクリプト付加部40は、レスポンス解析部38による探索によって発見された<input type="file">タグを含むスクリプト(例えば以下のスクリプト)を、リクエスト受付部26によって受け付けられたリクエストから削除する。
<input type="file" name="data"/> <br>
そしてスクリプト付加部40は、リクエスト受付部26によって受け付けられたリクエストに対し、削除したスクリプトに代えて、ステップ282で生成したスクリプトを付加する(図3のステップ222も参照)。次のステップ286において、レスポンス転送部42は、スクリプト付加部40によってスクリプトが付加されたレスポンスを端末装置12へ送信し、スクリプト付加処理を終了する。
上記のように中継サーバ18によってスクリプトが付加されたレスポンスを受信した端末装置12では、受信したレスポンスに付加されたスクリプトがウェブページ閲覧部22(ブラウザ)によって解釈・実行されることで、図8に示すファイル選択処理が行われる。
ファイル選択処理のステップ300において、ウェブページ閲覧部22は、図9(A)に示すようなアップロード画面150を端末装置12のディスプレイ72に表示させる(図3のステップ224も参照)。次のステップ302において、ウェブページ閲覧部22は、アップロード画面150内の「参照」ボタン152が選択される迄待機する。「参照」ボタン152が選択されると、ステップ302からステップ304へ移行し、ウェブページ閲覧部22は、ファイル一覧リストを表示する子画面(図9(B)に示すファイル一覧リスト画面160)を表示する(図3のステップ226も参照)。
アップロード画面150内の「参照」ボタン152が選択された場合、一般には、予め任意に設定されたフォルダに格納されたファイルが一覧表示され、表示対象のフォルダの変更(ディレクトリの移動)も可能であるので、任意のファイルが選択可能である。このため、アップロード対象のファイルとして機密性を有するファイルが誤って選択される可能性がある。
これに対して本実施形態では、アップロード画面150内の「参照」ボタン152が選択された場合に、中継サーバ18によって付加されたスクリプトにより、ファイル一覧リスト画面160が表示される。このファイル一覧リスト画面160内のファイル一覧リスト164には、機密性を有していないことがファイル管理サーバ20によって確認されたファイルのみが選択肢として一覧表示される。このため、機密性を有するファイルがアップロード対象のファイルとして誤って選択されることが防止される。
次のステップ306において、ウェブページ閲覧部22は、ファイル一覧リスト164に一覧表示されているファイルのうちの何れかのファイルが選択される迄待機する。この間、利用者は、ファイル一覧リスト164を参照し、一覧表示されているファイルの中からアップロード対象のファイルを選択する操作を行う(図3のステップ228も参照)。アップロード対象として何れかのファイルが選択されると、ステップ306からステップ308へ移行し、ウェブページ閲覧部22は、選択されたファイルのファイル名、パス名及びチェック日時を親画面(のスクリプト)へ受け渡し、子画面の表示を消去する。また、ウェブページ閲覧部22は、例として図9(C)に示すように、親画面へ受け渡されたファイルのパス名を表示欄156内に表示させる。
次のステップ310において、ウェブページ閲覧部22は、アップロード画面150内の「アップロード」ボタン152が選択される迄待機する。「アップロード」ボタン152が選択されると、ステップ310からステップ312へ移行する。そして、ステップ312において、ウェブページ閲覧部22は、アップロード対象として選択されたファイルのファイル名、パス名及びチェック日時を含むアップロード・リクエストをサービス提供装置14へ送信する(図3のステップ230も参照)。なお、このアップロード・リクエストには、アップロード対象のファイルのファイル名、パス名及びチェック日時の各属性情報が含まれているものの、アップロード対象のファイルのデータ自体は含まれていない。
続いて、端末装置12からサービス提供装置14宛のアップロード・リクエスト(アップロード対象のファイルの属性情報を含むリクエスト)を受信した場合に中継サーバ18で実行されるファイルアップロード処理について、図10を参照して説明する。
ファイルアップロード処理のステップ320において、リクエスト受付部26は、端末装置12から受信したサービス提供装置14宛のアップロード・リクエストを受け付ける。また、リクエスト解析部28は、リクエスト受付部26によって受け付けられたアップロード・リクエストを解析する。次のステップ322において、リクエスト解析部28は、リクエスト受付部26によって受け付けられたアップロード・リクエストからセッションID、アップロード対象のファイルのファイル名、パス名及びチェック日時を各々取得する。
ステップ324において、ファイル取得部30は、リクエスト解析部28によって取得されたパス名に基づき、アップロード対象のファイルのデータをファイル管理サーバ20から取得する(図3のステップ232も参照)。次のステップ326において、リクエスト生成部32は、ファイル取得部30によって取得されたアップロード対象のファイルのデータを、リクエスト受付部26によって受け付けられたアップロード・リクエストに付加する。また、リクエスト生成部32は、サービス提供装置14へ送信するためにアップロード・リクエストを整形する。アップロード・リクエストを整形する処理としては、例えばヘッダの情報(例えばコンテンツ・タイプ等)を書き替える処理が挙げられる。
そしてステップ328において、リクエスト転送部34は、リクエスト生成部32によってアップロード対象のファイルのデータが付加されて整形されたアップロード・リクエストをサービス提供装置14へ送信する(図3のステップ234も参照)。このアップロード・リクエストがサービス提供装置14で受信されることで、サービス提供装置14のサービス提供部24により、所定のサービスを提供する処理が行われることになる(図3のステップ236も参照)。
このように、本実施形態では、アップロード対象のファイルの選択に際し、機密性を有していないことがファイル管理サーバ20によって事前に確認されたファイルのみが選択肢として一覧表示される。これにより、機密性を有するファイルがアップロード対象のファイルとして誤って選択されることを防止することができ、機密性を有するファイルがサービス提供装置14へ送信されることを防止できる。
また、本実施形態では、アップロード対象のファイルが機密性を有しているか否かの判定はファイル管理サーバ20によって事前に行われるので、中継サーバ18はアップロード・リクエストを中継する際に前記判定を行う必要が無い。これにより、アップロード・リクエストを中継する際に中継サーバ18に加わる負荷が軽減され、アップロード対象のファイルのサイズが大きい場合や、アップロード・リクエストが頻繁に送信された場合にも、ファイルのアップロードは短時間で完了する。
また、本実施形態では、端末装置12から送信されるアップロード・リクエストにアップロード対象のファイルのデータが含まれていないので、端末装置12と中継サーバ18との間のトラフィックが減少する。一方、中継サーバ18はアップロード・リクエストを受信した場合にアップロード対象のファイルのデータをファイル管理サーバ20から取得するので、中継サーバ18とファイル管理サーバ20との間のトラフィックは増加する。但し、本実施形態において、利用者によってアップロード対象として選択されるファイルは、機密性を有していないことがファイル管理サーバ20によって事前に確認されたファイルであり、選択されたファイルが機密性の点でアップロードできないことは生じない。このため、利用者によってアップロード対象のファイルが選択された後、当該ファイルが機密性を有していないか否か判定する場合と比較して、機密性の点でアップロードできないファイルのデータを送受することが無くなる。従って、コンピュータ・ネットワーク82内における無駄なトラフィックが削減され、コンピュータ・ネットワーク82全体としてのトラフィックを減少させることができる。
更に、サービス提供装置14が提供するサービスの種類によっては、元々のファイルに対してデータ量の増減が生ずる改変(例えばヘッダに何らかの情報を付加する等)を行ったデータをアップロードすると、サービス提供処理の処理結果がエラーとなることがある。これに対して本実施形態では、機密性を有していないことがファイル管理サーバ20によって確認されてファイルDB54にデータが格納されたファイルはファイル一覧リストによって管理される。このため、本実施形態は、機密性を有していないことが確認されたファイルのデータを改変する必要はなく、当該改変を行っていないので、サービス提供処理の処理結果がエラーとなることも防止できる。
また、本実施形態で説明した技術は、端末装置12にブラウザがインストールされていれば実現可能である。このため、端末装置12に専用のアプリケーションをインストールしたり、端末装置12にインストールされているアプリケーション(例えばメーラ等)を改変する必要もなく、容易に実施可能である。
〔第2実施形態〕
次に開示の技術の第2実施形態について説明する。なお、本第2実施形態は第1実施形態と同一の構成であるので、各部分に同一の符号を付して構成の説明を省略し、以下、本第2実施形態の作用について、第1実施形態と異なる部分のみ説明する。
本第2実施形態は、機密性を有していないことがファイル管理サーバ20によって確認されてファイルDB54にデータが格納されたファイルのアップロードに際し、当該ファイルの改竄を確認する点で第1実施形態と相違している。以下、図11〜図14を参照して詳細を説明する。
第2実施形態に係るファイル管理サーバ20は、アップロードを予定しているファイルが何れかの監視フォルダに新たに格納されると、図12に示すファイル管理処理を行う。このファイル管理処理では、監視フォルダから取り出したファイルが機密性を有していないと判定し (ステップ254の判定が肯定)、当該ファイルのデータをファイルDB54の格納フォルダ内に格納(ステップ256)した後に、ステップ264へ移行する。ステップ264において、ファイル管理部50は、監視フォルダから取り出してファイルDB54に格納したファイルのハッシュ値を演算する(図11のステップ238も参照)。
次のステップ266において、ファイル管理部50は、今回ファイルを新たに格納した格納フォルダに対応する特定の利用者のファイル一覧リストに、今回取り出したファイルの情報として、ステップ264で演算したハッシュ値を含む各情報を追加する。これにより、次のステップ260において、ハッシュ値を含むファイル一覧リストが利用者IDと共にファイル管理部50から中継サーバ18に送信される(図11のステップ208も参照)。また、ファイル管理サーバ20から中継サーバ18へ送信されたファイル一覧リスト及び利用者IDは、中継サーバ18の利用者情報管理部44によって対応付けて保管される(図11のステップ210も参照)。
第2実施形態に係る中継サーバ18によって行われるスクリプト付加処理については、第1実施形態で説明した処理(図5)と同じであるが、スクリプト付加部40によって生成されてレスポンスに付加されるスクリプトが若干相違している。すなわち、前述のように本第2実施形態では、ファイル一覧リストに、各ファイルの情報の1つとして各ファイルのハッシュ値が含まれているが、本第2実施形態では、各ファイルのハッシュ値は端末装置への送信対象から除外され、スクリプトに含まれていない。また、本第2実施形態において、スクリプト付加部40は、図13に示すファイル選択処理を端末装置12のウェブページ閲覧部22(ブラウザ)によって行わせるスクリプトを生成する。以下、図13を参照し、端末装置12のウェブページ閲覧部22(ブラウザ)によって行われるファイル選択処理を説明する。
このファイル選択処理は、端末装置12のディスプレイ72にファイル一覧リスト画面160が表示されている状態で、利用者によってアップロード対象のファイルが選択される (図3のステップ228も参照)と、ステップ306からステップ314へ移行する。ステップ314において、ウェブページ閲覧部22は、スクリプトに含まれるパス名に基づき、利用者によって選択されたアップロード対象のファイルのデータをファイル管理サーバから取得する(図11のステップ240も参照)。次のステップ316において、ウェブページ閲覧部22は、ステップ314で取得したアップロード対象のファイルのデータに基づき、アップロード対象のファイルのハッシュ値を演算する(図11のステップ242も参照)。また、ステップ318において、ウェブページ閲覧部22は、アップロード対象のファイルのファイル名、パス名、チェック日時及び演算したハッシュ値を親画面(のスクリプト)へ受け渡し、子画面の表示を消去する。
次のステップ310において、ウェブページ閲覧部22は、第1実施形態と同様に、アップロード画面150内の「アップロード」ボタン152が選択される迄待機する。「アップロード」ボタン152が選択されると、ステップ310からステップ319へ移行する。そして、ステップ319において、ウェブページ閲覧部22は、アップロード対象のファイルのファイル名、パス名、チェック日時及びハッシュ値を含むアップロード・リクエストをサービス提供装置14へ送信する(図11のステップ230も参照)。なお、このアップロード・リクエストには、アップロード対象のファイルのファイル名、パス名、チェック日時及びハッシュ値の各属性情報が含まれているものの、アップロード対象のファイルのデータ自体は含まれていない。
第2実施形態に係る中継サーバ18は、端末装置12からサービス提供装置14宛のアップロード・リクエストを受信した場合に、図14に示すファイルアップロード処理を行う。このファイルアップロード処理のステップ320において、リクエスト受付部26は、端末装置12から受信したサービス提供装置14宛のアップロード・リクエストを受け付ける。また、リクエスト解析部28は、リクエスト受付部26によって受け付けられたアップロード・リクエストを解析する。
次のステップ330において、リクエスト解析部28は、リクエスト受付部26によって受け付けられたアップロード・リクエストからセッションID、アップロード対象のファイルのファイル名、パス名、チェック日時及びハッシュ値を各々取得する。ステップ324において、ファイル取得部30は、リクエスト解析部28によって取得されたセッションIDと対応付けて利用者情報管理部44に記憶されている利用者IDを取得する。続いてファイル取得部30は、取得した利用者IDと対応付けて利用者情報管理部44に記憶されているファイル一覧リストを利用者情報管理部44から読み出す(図11のステップ244も参照)。
次のステップ334において、ファイル取得部30は、リクエスト解析部28によって取得されたハッシュ値が、読み出したファイル一覧リストに設定されている同一ファイルのハッシュ値に一致しているか否か判定する(図11のステップ246も参照)。ハッシュ値が不一致の場合、ファイルDB54に格納された同ファイルのデータは、機密性を有していないことがファイル管理サーバ20によって確認された後で改竄された可能性がある。このため、ステップ334の判定が否定された場合はステップ336へ移行し、中継サーバ18は端末装置12に対してサービス提供装置14へのファイルのアップロードができない旨を通知し、ファイルアップロード処理を終了する。
また、ハッシュ値が一致していた場合はステップ334の判定が肯定されてステップ324へ移行する。以降の処理は第1実施形態と同じであり、アップロード対象のファイルのデータがファイル管理サーバ20から取得され(ステップ324)、当該データがアップロード・リクエストに付加され、アップロード・リクエストが整形される(ステップ326)。そして、アップロード・リクエストがサービス提供装置14へ送信され(ステップ328)、サービス提供装置14のサービス提供部24により、所定のサービスを提供する処理が行われる(図11のステップ236も参照)。
このように、本第2実施形態では、アップロードを予定しているファイルが機密性を有していないことを確認した際に、ハッシュ値を演算して保存しておき、ファイルをアップロードする際に改めてハッシュ値を演算して比較している。これにより、機密性を有しないことが確認されてファイルDB54に格納されたファイルが、当該ファイルのアップロードが行われる迄の間に改竄されて機密情報が付加された等の場合にも、ファイルのアップロードによって機密情報が漏洩することを防止できる。その他の作用効果は第1実施形態と同じであるので、説明を省略する。
なお、上記では機密性を有しないことが確認されたファイルをファイルDB54に利用者単位で格納・管理する態様を説明したが、利用者のグループ単位でファイルを格納・管理するようにしてもよい。
また、上記では端末装置12及び中継装置16が企業内に設置された態様を説明したが、開示の技術はこれに限られるものではなく、端末装置12及び中継装置16は、例えば家庭内に設置されていてもよい。また、上記では中継装置16が中継サーバ18とファイル管理サーバ20に分けられた態様を説明したが、これに限定されるものではなく、中継サーバ18とファイル管理サーバ20の機能を単一の装置(コンピュータ)で実現するようにしてもよい。
また、上記では開示の技術の中継プログラムの一例である中継プログラム110及びファイル管理プログラム144のうち、中継プログラム110が記憶部106に予め記憶され、ファイル管理プログラム144が記憶部140に予め記憶されている態様を説明した。しかし、これに限定されるものではなく、開示の技術の中継プログラムは、CD−ROMやDVD−ROM等の記録媒体に記録されている形態で提供することも可能である。
本明細書に記載された全ての文献、特許出願及び技術規格は、個々の文献、特許出願及び技術規格が参照により取り込まれることが具体的かつ個々に記された場合と同程度に、本明細書中に参照により取り込まれる。