JP2006260176A - 機密文書管理方法及び機密文書管理システム - Google Patents

Abstract

【課題】 情報漏洩のリスクを最小化する機密文書管理システムを実現する。
【解決手段】 ユーザと機密文書との間に両者を媒介するプロキシ（代理）ファイルを介在させる。ユーザは機密文書にダイレクトにアクセスすることができず、その機密文書を代理するプロキシファイルを経由してのみ機密文書にアクセスする。ユーザがプロキシファイルを経由して機密文書を開くタイミングで、クライアント側システムが、その文書に対応した特定のアプリケーションを起動する。ユーザが見るものは使い慣れた特定のアプリケーションだけであり、ユーザにとってクライアント側システムは完全に透過的に動作する。クライアント側システムは、ユーザの操作権限に応じた操作制限をアプリケーションのインタフェイス上に明示し、その実行を制限する。
【選択図】 図１

Description

本発明は、ユーザと機密文書との間に両者を媒介するプロキシ（代理）ファイルを介在させた機密文書管理方法及び機密文書管理システムに関するものである。

機密文書の保護とは、全てのファイルではなく、「機密」としてマーキングされた特定のファイル群の外部流出を如何にして防止するかという一点に集約されることになる。この課題に答えるためには、現在の主流である分散型ネットワーク環境は極めて不利な状況にある。というのは、例えば、機密文書を格納しているファイルサーバを如何に堅固なセキュリティで鎧わせたとしても、その機密文書は簡単にクライアントシステムへとコピーできるからである。その瞬間に、情報漏洩のリスクは劇的に高まることになる。

従って、機密文書を保護するためには、それがファイルとして自由にコピーされてはならない、あるいは、自由にコピーされたとしても一定の権限がなければ解読できない仕掛けになっていなければならない。前者の制約条件を満足するものが「サーバ集中型システム」であり、後者の制約条件を満足するものが「暗号化ファイルシステム」である。

前者の典型例として、例えば、MetaFrame（商標）のようなサーバ集中型ネットワーク環境を提供する製品を挙げることができるが、その欠点として次の二点を指摘することができる。

第一に、この種の製品は、機密文書だけでなくサーバ上に存在する全てのファイルを集中的に管理する。これは、機密文書の保護という観点から見れば、明らかに過剰条件であり過剰機能である。要するに、機密文書にフォーカスしている訳ではなく、ＯＳレベルでのファイル全てが対象になってしまう。

第二に、これがより致命的な欠点になるが、この種のシステムがケアするのはあくまでファイルであり、それにアクセスするアプリケーションではない。つまり、ファイルレベルでは一定の（あるいは過剰なまでの）保護機能が作動したとしても、ユーザのアクセス権限と文書ごとの機密性に応じた操作の制限という機能を提供するわけではない。

この第二の欠点は、「暗号化ファイルシステム」のような種類の製品群にも妥当する。この種の製品群の目的は、あくまでもファイルレベルでの保護にあり、そのファイルにアクセスするアプリケーションのケアは守備範囲に含まれていない。本来の守備範囲に含まれていないからこそ、付加的な機能として含まれている場合には、専用のビューワを用意したりなどして、ユーザにとっての操作性を阻害し、新規学習の負荷を与えてしまうことになる。

つまり、「サーバ集中型システム」であれ「暗号化ファイルシステム」であれ、この種の製品群は、本質的に機密文書とセットであるべきアプリケーションと連携していないのである。ここに致命的な欠点がある。

以上のように、機密文書の保護という観点から見れば、それとセットになっているアプリケーションとの連携は必須である。典型例として、「印刷」という機能を取り上げてみる。一般に、ある機密文書を印刷するためには、それを作成したアプリケーションで印刷しなければならない。この自明の事実から即座に了解できることは、本来、印刷機能を制限するレイヤはアプリケーションであってそれ以外ではないという点である。

まず第一に、印刷が制限されているユーザは、自分が操作しているアプリケーション上で印刷が制限されているということを視認し認識できなければならない。つまり、ユーザがわかるようにアプリケーションレベルで印刷機能が削除されていなければならない。逆に言えば、アプリケーションレベルで印刷機能が削除されてさえいれば、ＯＳなど、より低レベルで印刷機能を制限する必要はないのである。

このユーザインタフェイス上の要件は、単にＯＳレベルで（例えば、デバイスドライバのレベルで）印刷機能を制限するような汎用的な技術的メカニズムでは実現できない。これではレイヤが低すぎるのである。従って、以上の分析から、機密文書を保護するためのシステムは、最小限、以下の要件を備えていなければならないことが析出された。

(1) 機密文書の自由なコピーを許してはならない。あるいは、自由にコピーしても権限がないユーザには解読できないようにしなければならない。ただし、これは機密文書に対してのみであって、全てのファイルに対してである必要はない。

(2) 機密文書を参照・編集するアプリケーションは、ユーザのアクセス権限と文書ごとの機密性に応じた操作の制限に応じて、アプリケーションレベルで操作が制限されなければならない。同時に、操作が制限されていることが、アプリケーションレベルでユーザに認識（視認）されなければならない。

以上の要件を満たしているシステムとしてMicrosoft（登録商標） のWindows（登録商標） RMS(RightManagement System：登録商標) を挙げることができる。
Windows RMS は、独自のサーバシステムの導入とそれに対応したアプリケーション側のカスタマイズによって、アプリケーションレベルでのファイル暗号化を実現している。同時に、暗号化されたファイルの中にユーザのアクセス権限情報も内蔵することで、アプリケーションレベルでの操作制限も実現している。つまり、Windows RMS の環境下では、機密文書をコピーしてもアクセス権限を持たないユーザには解読不能であり、また、自分にどのような操作権限があるのかをアプリケーションレベルで認識することができる。

しかしながら、機密文書の管理という観点から見たとき、Windows RMSはアプリケーションレベルでの管理機能を提供しているわけではない。ここでの管理機能とは、少なくとも以下の三つにカテゴライズすることができる。
(a) 早期に異常を発見する検知機能
(b) 管理者に対するリアルタイム／定期的なメッセージ通知機能
(c) 改竄不可能なアクセスログ機能

機密文書は、単に保護されるだけでなく、同時に、このような管理も行われなければならない。この種の管理機能が提供されることで、組織の情報保護責任者／担当者の管理負荷も軽減できるのであり、更に、このような機能が実現されていることをユーザに周知することによって情報漏洩に対する抑止力ともなるのである。

従って、前節の二つの要件に加えて、機密文書を保護し管理するためのシステムは次の要件を備えていなければならない。
(3) 組織の情報セキュリティ管理体制と接続できる一元的な機密文書管理機能が提供されなければならない。
結局のところ、Windows RMS とは、あくまで分散型ネットワーク環境を前提とした上でセキュリティ強化を図るところに、その目的があり、逆に言えば、分散型ネットワークというフレームワークから一歩も外に出ないまま設計された機密文書保護システムであり、前記(3) のような要望を満たすものではない。

ところで、これまでに分析してきた要件を満足する従来技術の１つとして、「業務システム」が考えられる。「業務システム」には、それこそ組織の形態と必要に応じて実に多種多様なシステム構造が見られるが、その典型は中央にＤＢサーバを置いたクライアントサーバシステムである。このようなシステム構造を備えた業務システムでは、しばしば、データはＤＢ上にあるだけであり、クライアント側に置かれることはなく、少なくともファイルレベルでは、ユーザは自由にコピーすることはできない。

更に、クライアント側の操作はユーザ権限に応じて制限されているし、様々な管理機能もサーバ側で実装されている。つまり、このような種類の業務システムとは、実は業務データ／フローに限定して集中型ネットワーク環境を擬似的に構築しているシステムであると言うことができる。

しかし、このような業務システムの問題は、果たして組織内の機密文書の全てを網羅する業務システムを構築することができるのかといった点にある。そのコストだけを考えても、現実的に無理であることは言うまでもないだろう。しかも、問題はそれだけではない。もちろん業務システムは万能ではない。そもそも万能な情報システムなど存在しない。従って、業務システムの現実の運用の場面では、しばしば報告書や管理資料の作成のために業務サーバからデータを抽出し、そのデータを汎用的な文書アプリケーション（例えばWord やExcel：いずれも登録商標）に取り込んで編集処理が行われる。汎用的なアプリケーションの柔軟で多様な機能が、ここで発揮される訳である。

この地点で問題が発生する。たとえ業務システムが堅固なシステムであったとしても、そこから機密データを抽出したならば、その瞬間、そのデータを取り込んだ文書は、機密データを含んでいるにもかかわらず業務システムの管理外に置かれることになる。
しかも、新たに作成された機密文書は、たいていの場合、ユーザのローカルシステムに保存されたままになる。あるいは、複数のユーザがアクセスできるようなファイルサーバに保存される可能性すらある。ここで、情報漏洩のリスクは一気に高まる。

しかも、より本質的な問題は、そもそも業務システムを経由しなくても、日常的な業務の一貫として、ユーザはしばしば汎用的な文書アプリケーションを用いて経営情報や人事情報、顧客情報などの機密とされるべき文書を作成しているという誰もが周知の事実である。とは言うものの、クライアント側に「データ抽出」を提供しているシステムが非常に多いのが実情である。データ加工やデータ交換といった目的のために必要な機能ではあるが、これがどのような問題を引き起こすのか、容易に想像がつくであろう。たとえファイルサーバが堅牢なセキュリティを備えていても、分散型ネットワークである限り、原則的にコピーは可能である。

こうして、現実には、堅固な業務システムがあろうがなかろうが、組織内の分散型ネットワーク環境の中で機密文書が散乱してしまうことになる。ここで、たとえ機密文書が散乱したとしても、それぞれの文書には強固なアクセス制限を施している限り大丈夫であるとの反論は無効である。問題は、正当なアクセス権限をもったユーザから情報漏洩する可能性をどのように最小化すればよいのか、つまり「内部の敵」にどのように対処するのかというものである。ユーザが汎用的な文書アプリケーションを使い続ける限り、以上の問題は不可避なものである。

以上のように種々の従来技術について述べてきたが、「内部の敵」から機密文書を保護し適切に管理するためのシステムに対して求められる前記の基本的な要件(1) から(3) を満足できるシステムは、集中型ネットワークを擬似的に構築する業務システムがもっとも近いものであるが、既に述べたように、この業務システムにおいても、組織内の全ての機密文書を網羅できるような業務システムを構築することは現実的に極めて困難であり、更に、より一層本質的な問題は、ユーザが汎用的な文書アプリケーションを使い続ける限り、必ずその「網の目」から漏れる機密文書が発生してしまう可能性は避けられないという欠点がある。

なお、アクセス権限に応じて、アプリケーションの機能制限を行う技術としては、たとえば、次の特許文献に記載のものがあるが、これらも単にユーザの権限に応じてアプリケーションの機能制限を行うだけであり、内部の敵から機密文書を保護することはできないものであった。
特許2897807号公報 特開2002-312292号公報 特開2000-137682号公報

本発明は、前記のような従来技術の問題点を解決するために提案されたものであって、その目的は、汎用的な文書アプリケーションのレイヤで動作し（だからこそアプリケーションとも連携できる）、かつ、その基本的なアーキテクチャは現在の分散型ネットワーク上で仮想的に集中型ネットワークを構築することのできる機密文書管理システムを提供することにある。より具体的には、次のような機能を有する機密文書管理システムを提供することにある（図１参照）。

(a) ユーザと機密文書との間に両者を媒介するプロキシ（代理）ファイルを介在させ、このプロキシファイルの存在によって、ユーザは機密文書にダイレクトにアクセスすることができず、あくまでも、その機密文書を代理するプロキシファイルを経由してのみ機密文書にアクセスすることができる。

(b) ユーザがプロキシファイルを経由して機密文書を開くタイミングで、クライアント側システムが、その文書に対応した特定のアプリケーションを起動する。つまり、ユーザが見るものは使い慣れた文書アプリケーションだけであり、従って、ユーザにとってクライアント側システムは、完全に透過的に動作する。

(c) クライアント側システムは、文書アプリケーションを、その公開ＡＰＩなどを通じて制御することで、ユーザの操作権限に応じた操作制限をアプリケーションのインタフェイス上に明示し、その実行を制限することができる。

前記のような目的を達成するために、本発明は、暗号化された機密文書を格納した機密文書サーバと、この機密文書サーバに対してネットワークを介して接続されたクライアントシステムとを備え、このクライアントシステムに設けられたアプリケーションによって前記機密文書の編集を行う機密文書管理方法において、前記機密文書を復号化して生成されたプロキシファイルを前記機密文書サーバとクライアントシステムとの間に介在させ、前記機密文書に対するユーザのアクセス権に従って前記プロキシファイルを介して対応する機密文書の編集を行わせことで前記機密文書の存在をユーザから隠蔽すると共に、このプロキシファイルを介して前記機密文書を編集するアプリケーションに対して、前記機密文書に対するユーザのアクセス権に対応した機能制限と前記機密文書の編集に対する各ユーザに共通の機能制限とを行うことを特徴とする。

本発明の実施形態の１つは、ユーザの機密文書の編集要求を取得した機密文書サーバが、編集要求に関する改竄不能なアクセスログの作成、異常アクセスの検出及び秘密文書管理者に対する通知の少なくとも１つを実行することを特徴とする

本発明の実施形態の１つは、前記アプリケーションに対する機能制限を、アプリケーションレベルでユーザに認識させることを特徴とする。

本発明の実施形態の１つは、機密文書を復号化してプロキシファイルを生成をクライアントシステム上で行うことにより機密文書をクライアントシステム側でディスクファイル化し、このディスクファイル化に当たって、パスワードロックなどの暗号化機能を有するアプリケーションに対してアプリケーション外部から暗号化を実行させると共に、
(1) 機密文書をディスクファイル化する際には、それを格納するディレクトリを大量に、かつ深いところで、動的に生成する。
(2) アプリケーション上では機密文書のファイル名だけを表示し、ディレクトリの位置は表示せず、また参照もできないようにしておく。
(3) アプリケーションとしてファイルの「オープン履歴」を有するものを使用し、その「オープン履歴」から、機密文書の履歴だけを削除する。
(4) 文書アプリケーション上で表示するファイル名はプロキシファイルのファイル名であり、ディスクファイル化された機密文書のファイル名とは異なるようにしておく。ディスクファイル化された機密文書のファイル名は、そのたびごとに動的に生成し予測困難なものにしておく。
という(1) から(4) の処理の少なくとも１つを実行させることを特徴とする。

本発明の実施形態の１つは、暗号化された機密文書を格納した機密文書サーバと、この機密文書サーバに対してネットワークを介して接続されたクライアントシステムとを備え、前記機密文書サーバは、暗号化された機密文書の格納部と、機密文書に関する情報及びユーザに関する情報を格納した情報格納部と、機密文書にアクセスするユーザの認証を行う認証処理部と、クライアントシステム側との間で情報の授受を行うメッセージ送信部とを備えた機密文書管理システムにおいて、前記クライアントシステムは、機密文書を復号化して生成されたプロキシファイルの格納部と、ユーザの認証情報と機密文書サーバに関する情報を格納した情報格納部と、プロキシファイルを介して機密文書を編集するためのアプリケーションと、このアプリケーションに関して前記機密文書に対するユーザのアクセス権に対応した機能制限と前記機密文書の編集に対する各ユーザに共通の機能制限とを行うアプリケーション制御部と、アプリケーションによるプロキシファイルを介した機密文書の編集及びシステムによる機密文書への直接的な制御を実行する機密文書管理部と、機密文書サーバとクライアントシステム間でメッセージの授受を行うメッセージ送受信部とを備えていることを特徴とすることを特徴とする。

本発明の実施形態の１つは、前記機密文書サーバがネットワークに対して複数接続され、これら複数の機密文書サーバの少なくとも１つが他の機密文書サーバに対するユーザのリクエストについて、その認証処理を行う認証処理部を有していることを特徴とする。

本発明の実施形態の１つは、前記機密文書サーバが、同一の機密文書に対する複数のリクエスト要求を検出し、これをクライアントシステム側のユーザに通知する排他処理部を有していることを特徴とする。

本発明の実施形態の１つは、前記機密文書サーバが、編集要求に関する改竄不能なアクセスログを作成するロギング部、異常アクセスの検知部または秘密文書管理者に対するメッセージの送受信部の少なくとも１つを有することを特徴とする。

本発明の実施形態の１つは、プロキシファイルを経由してリクエストされた機密文書をサーバからクライアントシステムに向けて転送する直前、またはユーザが編集作業を完了して文書ファイルがサーバへ転送された直後の少なくとも一方のタイミングで機密文書単位でファイル保護処理を実行するファイル保護処理部を有することを特徴とする。

前記認証処理部は、アクセスしたユーザの認証が妥当な場合に、
(a) リクエストされた機密文書
(b) その機密文書の文書タイプなどの管理情報
(c) そのユーザの当該機密ファイルに対するアクセス権限情報
をクライアントシステムに送信することを特徴とする。

さらに、本発明並びにその実施形態は、前記各機密文書管理方法における各処理や機密文書管理システムにおける各部分が有する機能を、コンピュータ上で実現させるためのプログラムやそのプログラムを記録したコンピュータ読取可能な記録媒体としても実現可能である。

前記のような構成を有する本発明によれば、次のような効果が期待できる。
(1) 現在浸透している分散型ネットワークを前提することができるために、現在のPC が提供するコストパフォーマンスや豊富で柔軟な機能など、そのメリットを殺さずに済む。
(2) 汎用的な文書アプリケーションを利用するために、既に導入されている業務システムと棲み分け、容易に共存することができる。
(3) 汎用的な文書アプリケーションのレイヤで動作するために、ユーザのアクセス権限に応じた操作制限を、アプリケーションのユーザインタフェイス上で明示することができる。

以下、本発明の一実施形態を図面に従って具体的に説明する。まず、本実施形態を実現するためには、実稼働環境において以下の要素が必要となる。
(a) ファイル拡張子と連携してアプリケーションを起動するファイラー（例えばWindows でのエクスプローラ）
(b) アプリケーションの機能を公開ＡＰＩとして登録できるＯＳ（例えばWindows でのCOM インタフェイス）
(c) 上記の公開ＡＰＩを利用したアプリケーション（例えばWindows でのExcel やWord）

なお、現時点では上記の要素を備えた稼働環境はWindows であり、そこで動作するExcel やWord であるが、これは、あくまでも現時点でのことに過ぎない。ごく近い将来Unix （登録商標）系のＯＳなどでも実現できる可能性があり、従って、本発明は特定のＯＳや特定のアプリケーションに依存したものではない。しかしながら、本実施形態では、説明の具体性と現時点での実現可能性を考慮した上でWindows やExcel といった具体的な要素を利用する。

また、本実施形態を実現するには、次のような段階が必要となる。
(a) 機密文書を代理するプロキシファイルの導入（プロキシファイルと、それが代理する機密文書とをバインドする。）
(b) プロキシファイルとアプリケーションの連携（プロキシファイルへのアクセスをトリガとして起動されるべきアプリケーションを定義する。）
(c) プロキシファイルと連携したアプリケーションの機能制限の可否（起動されたアプリケーションの機能をユーザのアクセス権限に応じて制御する。）

前記(a) (b) については問題はなく、如何なるタイプの機密文書であろうとも実現できる。しかし、(c) の特に、ユーザから透過的にアプリケーションの機能制御を行うためには、クライアントシステム側が外部からそのアプリケーションの機能に介入できなければならないが、本実施形態のようにWindows やExcel といった具体的な要素を利用した場合には、保護／管理対象となっているタイプの機密文書に対応したアプリケーションが自分の機能をＯＳなどに公開ＡＰＩとして登録していなければならない。

この種のアプリケーションの典型例がWindows 上で動作するWord やExcel であるが、同じようにWindows 上で動作するアプリケーションでも、自分の各機能をいわば「パーツ」としてＯＳに登録／公開していないものが存在する。この種のアプリケーションに対しては、本実施形態では「プロキシファイルと連携したアプリケーションの機能制限」を提供することはできない。

（１）システム要素の定義
本明細書における各用語の定義は次の通りである。
(a) 機密文書：保護されるべき文書ファイル
(b) 機密文書サーバ：機密文書を格納したファイルサーバ
(c) サーバシステム：機密文書サーバ上で動作し機密文書を一元的に保護／管理するサーバプログラム
(d) プロキシファイル：機密文書を代理するファイル
(e) クライアントシステム：プロキシファイルにアクセスしてサーバシステムと通信し、クライアント側の文書アプリケーションと連携して動作するプログラム

（２）プロキシファイル
ユーザは、機密文書にダイレクトにアクセスすることはできず、このプロキシファイルを経由してのみ機密文書にアクセスすることができる。ということは、一方では、ユーザに対して機密文書を隠蔽し、そのヴェイルの向こう側に存在する実体としての機密文書を様々に抽象化することが可能になるし、他方では、ユーザが、このプロキシファイルにアクセスするタイミングで機密文書に対する様々な保護メカニズムを作動させることが可能になる。

プロキシファイルには、それが代理する機密文書を一意に特定する識別子（「機密文書識別子」）と、その機密文書が格納されているサーバを一意に特定する識別子（「サーバ識別子」）が暗号化されて格納されている。プロキシファイルのファイル名自体は何でも構わない。ユーザがわかりやすいような名前をつければよいし、それどころか、ユーザごとに異なった名前をつけても構わない。そもそもプロキシファイルと、それが代理する機密ファイルとの関係は「多対一」であり、プロキシファイルは、その内容が変更されない限り、コピーすることは自由であり、ファイル名もそれぞれが異なった名前をつけても全く構わない。クライアントシステムは、プロキシファイルにアクセスする際、あくまでもその中身だけを必要としているのであり、それ以外は本質的な要素ではない。

ちなみに、「機密文書を一意に特定する識別子」は、それを格納する機密文書サーバ上で生成される。従って、この識別子の一意性は一つの機密文書サーバに対してのみ保証される。

（３）機密文書
機密文書にアクセスするためにはプロキシファイルを経由してのみ可能という「間接アクセス方式」が取られるために、保護されるべき機密文書は、ユーザからはシステムの構造上、隠蔽されることになる。つまり、ユーザは機密文書をファイルレベルでコピーしたり外部に持ち去ることができない。また、仮に何らかのトラブルで機密文書が外部に流出したとしても、機密文書自体は既に機密文書サーバ上で暗号化された状態なので内容が明らかになることもあり得ない。

プロキシファイルの本質は、それが代理する機密文書を一意に特定する識別子に他ならないが、この識別子と機密文書との関係は単純なもの（例えば、単純な「一対一」対応）である必要はない。機密文書管理システムの観点から言えば、ある一つの機密文書とは、一方では、一連の変更履歴が集積した時系列的な複数バージョンの集合体であり、他方では、必要に応じてユーザごとに異なる可能性がある複数バージョンの集合体である。

この二つの軸から見た、それぞれの物理的なファイルレベルでの機密文書を「機密文書スライス」と名付ければ、本システムでの機密文書とは機密文書スライスの集合体として抽象的かつ論理的に定義することができる。従って、あるユーザがある機密文書を、プロキシファイルを経由してリクエストしたとき、具体的にはどの機密文書スライスをそのユーザに対して提供すべきかを多様な目的に応じて、サーバシステム側で統一的かつ一元的に定義することができる。

（４）実施形態の構成
本実施形態の機密文書管理システムは、図２の機能ブロック図に示すように、機密文書格納部１０、情報格納部１１、認証処理部１２、ファイル保護処理部１３、ロギング部１４、メッセージ送受信部１５、異常検知部１６及び排他制御部１７を備えた機密文書サーバ１と、プロキシファイル格納部２０、情報格納部２１、アプリケーション２２、アプリケーション制御部２３、機密文書管理部２４及びメッセージ送受信部２５を備えたクライアントシステム２と、プロキシファイル格納部３０を備えた適当なファイルサーバ３とから構成される。なお、ファイルサーバ３は、本発明に不可欠のものではなく、各クライアントシステム２において、プロキシファイルを格納するように構成しても良い。

なお、プロキシファイルは、ユーザが自由にアクセスできるファイルサーバでも、あるいは、ユーザのクライアントシステム上でも、生成可能である。これは、ユーザの初期設定項目の一つとしておくことで、自由に設定することができる。通常は、既に使用されているファイルサーバ上に生成するのが使いやすいが、場合によっては（例えば経理データ文書など）、一般ユーザには、その存在や文書ファイル名すら知られたくような機密文書の場合には、ユーザが一般にアクセス可能なファイルサーバ上ではなく、自分のローカルシステムや、特定のメンバーしかアクセスできないシステム上にプロキシファイルを生成する（設定する）ことが好ましい。

（４−１）機密文書格納部１０
機密文書格納部１０は、ユーザがクライアントシステム２上で作成した所定のファイル、あるいはプロキシファイルを介して編集した他の機密文書を新たな機密文書として指定した場合に、これを機密文書サーバ１内に格納、保存する部分である。一度、この機密文書格納部１０に格納されたファイルはクライアントシステム２側からは直接アクセスすることはできず、その機密文書と対応関係にあるプロキシファイルを介してのみアクセスされることになる。

（４−２）サーバの情報格納部１１
機密文書を一元的に管理する機密文書サーバ１には情報格納部１１が設けられ、この情報格納部１１には、次のように格納している機密文書の情報に加えて、ユーザ認証するためのユーザ情報や自分自身のサーバ情報などが含まれる。

(a) 機密文書情報：プロキシファイルの中に含まれる機密文書を一意に特定する識別子、機密文書サーバ上での位置、作成者、最新の参照者、最新の更新者、削除者などの情報。
(b) ユーザ情報：クライアントからのリクエストを処理する際のユーザ認証やライセンス管理のためにユーザ情報の管理を一元的に行う。

(c) サーバ情報：自分自身のサーバ情報だけでなく、他に追加されたサーバの情報も含む。すなわち、本発明の機密文書管理システムでは、負荷分散などのために複数の機密文書サーバを稼働させることができる。ただし、ユーザ認証は最初に導入された機密文書サーバが「プライマリサーバ」として一元的に行う。従って、各サーバはに自分がプライマリサーバであるか否か（認証処理部１２を有するか否か）という情報が必要となる。これを「認証サーバの一元化」と呼ぶ。

（４−３）認証処理部１２
クライアントシステム２がプロキシファイル３を経由して機密文書サーバ１と接続する際には以下の二つの情報を送信する。
(a) そのユーザの認証情報
(b) プロキシファイルに格納されている機密文書の識別子
機密文書サーバ１における認証処理部１２は、これによって、誰が、どの機密文書をリクエストしているのかを機密文書サーバ１に認識させることができる。

ちなみに、上記の情報を送信する際、どの機密文書サーバに送信すればよいのかは、クライアントシステム２がアクセスしたプロキシファイル３に格納されている機密文書サーバ識別子によって確定する。このとき、機密文書のリクエスト情報を送信された機密文書サーバ１が認証処理部１２を有するプライマリサーバでなかった場合には、クライアントシステムから受け取ったユーザ認証情報をプライマリサーバへと転送し、チェックしてもらう。

プライマリサーバによるチェックの結果が妥当であれば、この機密文書サーバはクライアントシステムにリクエストされた機密文書を転送する。妥当でなければ、クライアントシステムに認証エラーの応答を返す。妥当な場合、クライアントシステムは機密文書サーバから次の情報を返される。

(a) リクエストされた機密文書
(b) その機密文書の文書タイプなどの管理情報
(c) そのユーザの当該機密ファイルに対するアクセス権限情報

クライアントシステム２にとって、自分がリクエストした機密文書が必要なことは言うまでもないが、これに加えて、この機密文書について、そのユーザに対してはどのような操作権限を許可するのか（ないしは許可しないのか）を認識し、制御するために、上記のアクセス権限情報が必要になる。

本実施形態では、クライアント数の増大や機密文書サーバの負荷分散のために複数の機密文書サーバを同時に稼働させることができる。しかし、その際にユーザ情報も複数のサーバに分散させることはシステム全体の構造を一気に複雑化することになる。この点を考慮して、このシステムでは、最初に導入した機密文書サーバを「プライマリサーバ」として複数サーバの稼働環境でもユーザ認証を一元化する。

（４−４）ファイルの保護処理部１３
このファイルの保護処理部１３は、ファイル単位での保護処理という観点から、プロキシファイルを経由してリクエストされた機密文書をサーバからクライアントシステムに向けて転送する直前（プリプロセス）、更に、ユーザが編集作業を完了して文書ファイルがサーバへ転送された直後（ポストプロセス）、この二つのタイミングで機密文書単位に必要な処理を定義する。間接アクセス方式だからこそ実現可能なこの機能を、それぞれ「プリプロセッサ機能」と「ポストプロセッサ機能」と呼ぶ。

この機能が必要とされる典型的な事例はファイル単位でのウィルスチェックだろう。Word やExcel の文書ファイルにも「マクロ・ウィルス」が汚染してしまう可能性があることは周知の事実であり、そのための監視メカニズムを機密文書サーバ上で一元的に、しかも機密文書にアクセスされるたびごとに実行できることは、機密文書サーバ上の機密文書全体の安全性を高めるためにも極めて重要な要件の一つと言えよう。

（４−５）ロギング部１４
このロギング部１４は、プロキシファイルを経由して機密文書がリクエストされたタイミングで、誰が、いつ、どの機密文書をリクエストしたかといったアクセス情報を記録する。このアクセスログ情報は電子署名を施すことによって改竄を防止し、必要に応じて監査証跡として用いることができる。

（４−６）メッセージ送受信部１５
メッセージ通知部は、前記ロギング部による記録と同じタイミングで、必要に応じて条件を設定することで、管理者宛にリアルタイムに「ユーザが機密文書にアクセスした」というメッセージを電子メールで通知する。

この条件の事例としては、一例として、以下のようなものがある。
(a) ある特定の機密文書にアクセスした場合
(b) ある特定のユーザ（あるいはグループ）からリクエストがあった場合
(c) ある特定の時期（例えば休日）にアクセスした場合
(d) 以上の複合

（４−７）異常検知部１６
機密文書にアクセスするのが業務上の人間による行為である限り、そのアクセス分布には自ずと自然な統計パターンが見出される。例えば、ある同じ機密文書に一人の人間が一日に１００回以上もアクセスすることは想定しにくいし、１分間に１０回以上アクセスすることも想定しにくい。おそらく、この場合は何か不正なプログラムが知らないうちに動作していると判断するべきであろう。このような「異常なアクセス分布」を別途定義することにより、異常検知部１６は、このパターンにマッチした場合には異常を検知したとして、前記メッセージ送受信部１５を介して、管理者宛にリアルタイムに通知する。

更に、このような「静的な異常検知ルール」の定義だけでなく、実際の運用状況の中でアクセスデータを蓄積し、統計的に管理・分析し、それに基づいて異常を検知するルールを動的に生成することもできる。

（４−８）排他制御部１７
一般に、機密文書は、同時に複数のユーザからアクセスされる可能性がある。このような場合、通常のシステムでは、機密文書に関する排他制御は、可能であったとしてもファイルレベルでのもの以上ではない。つまり、単純に「そのファイルに対してはアクセス不可」というメッセージがＯＳからのエラー情報を通じて表示されるだけであり、後からアクセスしようとしたユーザには、これ以上の情報は与えられない。

ところが、プロキシファイルが介在すると、ユーザは機密文書にダイレクトにアクセスすることはできずプロキシファイルを経由してのみアクセス可能なので、サーバシステム側で木目の細かい排他制御を実現し、豊富な情報をクライアントシステム側で表示することができる。このシステムが、本質的には「機密文書管理システム」である所以である。

例えば、本実施形態の排他制御部１７は、あるユーザＡがある機密文書Ｘに対して既に「書き込み」モードでアクセスしていたとき、他のユーザＢがプロキシファイルを経由して、この同じ機密文書にアクセスしようとすると、このタイミングで（最低限）次のような情報を提示した上でアクセスを禁止することができる。

(a) 当該機密文書Ｘに誰がどのようなモードでアクセスしているか（この場合は、Ａが「書き込み」モードでアクセスしている、という情報を提示）
(b) そのユーザＡは、いつから、この機密文書にアクセスしているか
仮に、このユーザＡが、既に５時間もの間、この機密文書にアクセスしているとの情報が提示されたならば、Ａは不注意にも機密文書を開きっ放しで離席している可能性があることになる。このように、機密文書ごとのリアルタイムなアクセス情報はセキュリティ的な観点から見ても非常に重要な手がかりを提供する。

また、本実施形態の排他制御部１７は、更に、このタイミングで「ユーザ間メッセージ通知」処理も実行する。例えば、あるユーザＡがプロキシファイルを経由してある機密文書Ｘにアクセスし、そのときに既に他のユーザＢが当該機密文書Ｘを開いていたならば、そのタイミングで自動的にＡからＢへ「Ｘに対してアクセスを希望」との通知メールを送信する。

（４−９）プロキシファイル格納部２０
クライアントシステム２には、機密文書サーバ１に格納されている機密文書に対応したプロキシファイルを格納するためのプロキシファイル格納部２０が設けられている。このプロキシファイル格納部２０は、ユーザがそのクライアントシステム２を介して機密文書にアクセスした場合に、その機密文書に対応して生成され、プロキシファイル格納部２０内に保存される。

（４−１０）クライアントシステムの情報格納部２１
クライアントシステムは機密文書サーバ上で動作しているサーバシステムと通信する。従って、初期インストール時には、その情報格納部２１に対して、最低限、以下の情報を設定する必要がある。
(a) ユーザの認証情報
(b) 機密文書サーバ（プライマリサーバ）のＩＰアドレスとポート番号
クライアントシステム側で必要な情報は基本的にはこれだけである。以上の情報に基づいて、初期インストール時に機密文書サーバ（プライマリサーバ）に接続し、自らのユーザアカウント情報を登録することになる。

（４−１１）アプリケーション２２
前記のように本実施形態においては、アプリケーションの機能を公開ＡＰＩとして登録できるＯＳ（例えばWindows でのCOM インタフェイス）と、この公開ＡＰＩを利用したアプリケーション（例えばWindows でのExcel やWord）を使用する。ユーザから透過的にアプリケーションの機能制御を行うためには、クライアントシステム側が外部からそのアプリケーションの機能に介入できなければならないという理由による。

（４−１２）アプリケーション制御部２３
アプリケーション制御部２３は、ユーザがプロキシファイルにアクセスしたタイミングでクライアントシステムが起動し、一連の準備処理を経た後に、機密文書に対応した特定のアプリケーションを、クライアントシステムの内部から起動させるものである。そのため、クライアントシステムがアプリケーションとシームレス（つまりユーザからは完全に透過的）に連携動作する。

例えば、Windows 上でのnotorious なアプリケーションであるWord やExcel は自らの機能の一部をCOM インタフェイスを通じて他のシステム（典型的にはVisual Basic Automation）にも公開している。本実施形態のアプリケーション制御部は、この公開ＡＰＩを通じて、クライアントシステムは汎用的な文書アプリケーションの代表格でもあるWord やExcel を外部から制御する（図１２を参照）。

同時に、アプリケーション制御部２３は、ユーザから透過的に機密文書に対応した特定のアプリケーションを起動させるだけでなく、それに加えて、そのユーザのアクセス権限に応じてアプリケーションの操作を制限する（図１３を参照）。しかも、単に機能的に制限するだけでなく、ユーザインタフェイスにも同様に外部から変更を加えることで、ユーザが自分にどのような操作が許可されていないのかも認識（視認）させる。

つまり、このアプリケーション制御部２３により、ユーザにとっては、プロキシファイルにアクセスするだけで自動的に必要な使い慣れたアプリケーションが起動するのみならず、自分の操作権限に応じて機能が制限された（それがユーザインタフェイス上でも認識できる）特殊なバージョンのアプリケーションが起動することになる。その結果、完全に透過的なアプリケーションとの連携がここに実現される。

このアプリケーション制御部２３は、プロキシファイルを経由して機密文書にアクセスしない場合には、クライアントシステム上において、該当するアプリケーションを標準的なアプリケーションとして起動し、通常の標準的な処理を実行させる。

（４−１３）機密文書管理部２４
クライアントシステムに設けられた機密文書編集部２４は、次のような機能を有している。このうち、機密文書の編集及び閲覧（印刷）については、機密文書と関連づけられた種々のアプリケーション２２によりプロキシファイルを経由して行う。一方、他の機能については、クライアントシステム２に用意された専用のプログラムにより実現される。ただし、以下の機能は、その操作が許可されたユーザだけが実行できる。

(1) 機密文書の編集：プロキシファイルを経由して所定のアプリケーションにより機密文書を編集する。この際、システムはユーザに対して完全に透過的に動作するので意識することはない。
(2) 機密文書の閲覧：プロキシファイルを経由して所定のアプリケーションにより機密文書を参照する。参照の場合、文書内容を編集することは許されない。編集の場合と同様に、この際にも、システムはユーザに対して完全に透過的に動作するので意識することはない。

(3) 機密文書の複写・移動：クライアントシステムの提供する機能によって、指定した機密文書を複写・移動する。
(4) 機密文書の削除：クライアントシステムの提供する機能によって、指定した機密文書を削除する。ただし、この場合の削除とは「論理削除」であって、機密文書の実体が物理的に削除されるわけではない。
(5) 機密文書の復旧：クライアントシステムの提供する機能によって、指定した機密文書を復旧する。

(6) 機密文書のインポート：ユーザが作成した文書を機密文書としてシステムにインポート（登録）する。この際、同時に、この機密文書を代理するプロキシファイルが生成される。
(7) 機密文書のエクスポート：機密文書をシステムからエキスポートする。この際、この機密文書はシステムの保護／管理外へと出ることになる。

（４−１４）メッセージ送受信部２５
クライアントシステム２のメッセージ送受信部は、機密文書サーバ１やプロキシファイルを格納した文書サーバ３との間で、機密文書の編集等に必要な情報や排他制御に関する情報などを交換するものである。

（５）本実施形態の作用
次に本実施形態の作用を、その各処理ごとにフローチャートに従って説明する。
図３〜図５は、本実施形態における機密文書に対する編集処理を示すものであって、図３はクライアントシステム２と機密文書サーバ１間の情報のやり取りを説明する模式図、図４は機密文書のリクエストと受領を行うクライアントシステム２側の処理フロー図、図５は機密文書リクエストの受信と機密文書の更新を行う機密文書サーバ側の処理フロー図である。

（５−１）処理の開始：クライアントシステム側の処理…図４
クライアントシステム２において、ユーザが所定のファイラー（Windows 環境ではエクスプローラ）上から、クライアントシステム２あるいは文書サーバ４上にあるあるプロキシファイルをダブルクリックするなどの操作を行うことにより選択する（ステップ４１）。

すると、既にクライアントシステム２にインストールされている機密文書管理部２４が起動し、選択されたプロキシファイルをオープンして、その内容を読み込む（ステップ４２）。すなわち、プロキシファイルには、このファイルが代理する機密文書を一意に特定する識別子と、その機密文書が格納されている機密文書サーバを一意に特定するサーバ識別子が格納されている。この後者、サーバ識別子によって、クライアントシステムは自分がどのサーバに接続すればよいのかを判断することができる。これは、機密文書サーバの処理負荷の分散やライセンス数の問題から、複数の機密文書サーバを稼働させざるを得ない場合があるからである。

オープンされたプロキシファイルからその内容を読み込んだクライアントシステム２は、機密文書サーバ１に対して、機密文書のリクエストとして、以下の情報を送信する（ステップ４３）。
(1) プロキシファイルが代理する機密文書の識別子
(2) ユーザの認証情報
（５−２）機密文書リクエストの受信：機密文書サーバ側の処理…図５
クライアントシステム２からリクエストを受信した（ステップ５１）機密文書サーバ１は、まず認証情報をチェックした上で、リクエストされた機密文書についてのユーザのアクセス権限を確定する。すなわち、クライアントシステム２からリクエストを受信したタイミングで、機密文書サーバ１は、以下の処理を行う。

(1) 機密文書サーバが管理している改竄不能ログに、このリクエストを記録する（ステップ５２）。
(2) このリクエストがきたことを（必要に応じて）管理者に通知する（ステップ５３）。
(3) 蓄積された統計情報と設定された条件に基づいて、例えば、「余りにも短時間でリクエストが繰り返されている」などの理由からこのリクエストが異常であると判定されたら（ステップ５４のＹＥＳ）、リクエストを拒否し（ステップ５５）、管理者に通知する（ステップ５６）。

クライアントシステム２からのリクエストが異常でない場合には（ステップ５４のＮＯ）、そのリクエストに含まれている認証情報の検証を行う（ステップ５７）。認証が妥当でない場合には、そのリクエストを拒否するメッセージをクライアントシステム２に送信する（ステップ５８）。一方、認証が妥当であったら（ステップ５７のＹＥＳ）、機密文書サーバ１は、後述する排他制御処理を行った後（ステップ５９）、クライアントシステム２に対して以下の情報を暗号化して転送する（ステップ５１１〜５１３）。
(1) リクエストされた機密文書
(2) その機密文書に関する管理情報：例えば、この機密文書のファイルタイプ（対応するアプリケーション）やその他
(3) 当該ユーザのこの機密文書に対するアクセス権限情報

前記ステップ５９における排他制御処理は、クライアントシステム４からリクエストされた機密文書が既に他のユーザにオープンされているかをチェックし、すでにオープンされていた場合には排他処理の対象であるとして（ステップ５９のＹＥＳ）、機密文書サーバ１は、少なくとも以下の情報をクライアントシステム４に対して返す（ステップ５１０）。
(1) 当該機密文書には、誰がどのようなモードでアクセスしているか
(2) そのユーザは、いつから、この機密文書にアクセスしているか

また、機密文書サーバ１は機密文書をクライアントシステム２に転送する際、処理が定義されていたら、この機密文書に対して一定の処理を施すことも可能である（例えば「ウィルスチェック」など）。これを「プリプロセッサ機能」と呼ぶ（ステップ５１２）。

（５−３）機密文書サーバが複数存在する場合…図６、図７
ところで、機密文書サーバが複数ある場合、前記のクライアントシステム２からの機密文書リクエストの処理は、次のようになる。図６はその場合のクライアントシステムと、複数の機密サーバ間の情報のやり取りを示す模式図、図７は機密文書サーバが複数存在する場合のフロー図である。なお、図７において、リクエストの送信までは、前記図４と同様な処理がなされる。

複数の機密文書サーバがある場合、そのいずれかにクライアントシステム２からの認証情報の転送された場合、ここで処理の分岐が生じる可能性がある。すなわち、クライアントシステムから接続された機密文書サーバ１が「プライマリサーバ」ではなかった場合（ステップ７４のＮＯ）、この機密文書サーバ１は、自分に情報登録されているプライマリサーバ１へとクライアントシステム２から送信されたユーザの認証情報を転送する（ステップ７６）。

プライマリサーバは転送されたユーザの認証情報をチェックして、妥当なものでなければ（ステップ７７のＮＯ）認証エラーを返す（ステップ７８）ので、これを受けた転送元サーバはクライアントシステムからのリクエストを拒否する（ステップ７９）。一方、妥当なものであれば（ステップ７７のＹＥＳ）、転送元機密文書サーバへその旨を返信し（ステップ７１０）、転送元サーバによるリクエスト処理（ステップ１１）が実行される。なお、この転送元サーバによるリクエスト処理は、プライマリサーバによるリクエスト処理と同様のものであり、図５のステップ５９以降に相当する。。

プライマリサーバ１ａからユーザ認証チェックの結果を受け取った機密文書サーバ１ｂは、その結果に応じた応答を、接続してきたクライアントシステム２へと返す（ステップ９）。

（５−４）機密文書の受領：クライアントシステム側の処理…図４
機密文書サーバ１から暗号化された情報を受け取った（ステップ４４）クライアントシステム２は、それを復号化して、機密文書とアクセス権限情報を取得する（ステップ４５）。クライアントシステム２は、復号化された機密文書のファイルタイプに対応したアプリケーション（Excel あるいはWord など）を起動する（ステップ４６）。この処理のタイミングで、復号化された機密文書が一旦、ディスクファイル化されることになる。

ここでアプリケーションが起動される際、クライアントシステムは、そのアプリケーションの公開ＡＰＩを利用して、外部から、このアプリケーション内部で生じる特定のイベント（例えば「印刷」や「名前をつけて保存」などの操作）を制御する（ステップ４７）。Windows の場合「COM インタフェイス」を経由して制御することになる。なお、公開ＡＰＩだけでは処理できない部分に関しては、ダイレクトにWindow Messageをフックして処理することになる。

更に、機密文書サーバから取得したアクセス権限情報に基づいて、どのようなイベントを制御するのかを決める（ステップ４８）。例えば、印刷不可なのか、書き込み不可なのかを決めることになる。このようにして、アプリケーションの機能をユーザのアクセス権限に応じて制限する。典型的には「名前をつけて保存」「印刷」などの操作をすると「あなたには、その権限がありません」などのメッセージが表示される。このようにして、ユーザの権限に応じたアプリケーションが実行されるので、ユーザはこのアプリケーションを利用して文書の編集を行う（ステップ４９）。

編集作業が完了したら、アプリケーションは終了し（ステップ４１０）、制御が機密文書管理システム側に戻るので、クライアントシステム２は、更新された機密文書を暗号化した後（ステップ４１１）、機密文書サーバへとその文書を転送する（ステップ４１２）。

（５−５）機密文書の更新：機密文書サーバ側の処理…図５
機密文書サーバ１側では、クライアントシステムから転送された機密文書を受信し（ステップ５１４）、その内容に従って蓄積されていた機密文書を更新する（ステップ５１５）。なお、更新する際に、処理が定義されていたら、この機密文書に対して一定の処理を施す（例えば「ウィルスチェック」など）。これを「ポストプロセッサ機能」と呼ぶ。

以上、本実施の形態における「機密文書の編集」の処理フローを詳述してきたが、これと同様に日常的に使用されると思われる「機密文書の参照」は、編集不可である点を除いて、「機密文書の編集」の処理フローに準ずるので省略する。

（６）機密文書のインポート
次に、機密文書のインポートについて図８から図１０に従って説明する。これは、ユーザが機密文書化したい文書を機密文書管理システムに新たに登録する作業である。図８はクライアントシステム２と機密文書サーバ１間の情報のやり取りを説明する模式図、図９は機密文書のリクエストと受領を行うクライアントシステム２側の処理フロー図、図１０は機密文書リクエストの受信と機密文書の更新を行う機密文書サーバ側の処理フロー図である。

（６−１）処理の開始：クライアントシステム側の動作…図９
例えば、図１４の画面例に示すように、エクスプローラ上から、機密文書化したい文書を選んで、クライアントシステムのアイコン上にドラッグアンドドロップする（ステップ９１）。クライアントシステムは、ユーザによってドロップされた文書が処理可能な文書タイプであるかどうかを判定し（ステップ９２）、処理可能であれば（ステップ９２のＹＥＳ）、機密文書サーバに対して、機密文書のインポートリクエストを発行する（ステップ９４）。処理可能でなければ（ステップ９４のＮＯ）、ユーザに対してエラーメッセージを表示する（ステップ９３）。

この際、クライアントシステムから機密サーバへと送信される情報は以下のものである。
(1) ユーザ認証情報
(2) 機密文書のタイプ情報
(3) 機密文書のパーミッション情報
(4) 機密文書化したい文書ファイル

なお、前記(3) は、インポート操作を行うユーザが文書に対して設定するパーミッション（アクセス許可）情報である。この際、デフォルトのルールに従うならば、ユーザは特に設定する必要はないし、更に管理者が一律にルールを設定している場合には、この段階でユーザが自由にパーミッションを設定することはできない。

（６−２）機密文書インポートリクエストの受信：サーバシステム側の動作…図１０
クライアントシステムからインポートリクエストを受信した機密文書サーバは、まず、管理処理を行う。

すなわち、クライアントシステム２からリクエストを受信した（ステップ１０１）タイミングで、機密文書サーバ１は以下の処理を行う。
(1) 機密文書サーバ１が管理している改竄不能ログに、このリクエストを記録する（ステップ１０２）。
(2) このリクエストがきたことを（必要に応じて）管理者に通知する（ステップ１０３）。
(3) 蓄積された統計情報と設定された条件に基づいて、例えば、「余りにも短時間でリクエストが繰り返されている」などと、このリクエストが異常であると判定されたら（ステップ１０４のＹＥＳ）、リクエストを拒否し（ステップ１０５）、管理者に通知する（ステップ１０６）。

次に、機密文書サーバ１は、認証情報をチェックする（ステップ１０７）。この際に、複数の機密文書サーバが稼働している場合の処理の分岐は、前述した場合と同様なので省略する。この認証が妥当なものであれば（ステップ１０７のＹＥＳ）次の処理へと移行し、妥当なものでなければ（ステップ１０７のＮＯ）、クライアントシステムに対して認証エラーを返す（ステップ１０８）。

認証が妥当であったら、機密文書サーバはクライアントシステムから受け取った文書を機密文書化するために、まず以下の処理を行う。
(1) 文書の暗号化（ステップ１０９）
(2) 機密文書サーバ上への文書の配置（ステップ１０１０）

次に、生成された機密文書を管理するために、機密文書管理表のレコードを一つ生成する。この際に、このサーバ上で一意の機密文書識別子も生成される（ステップ１０１１）。その後、機密文書サーバは、クライアントシステムから受け取った文書を無事に機密文書化したとの応答を返す（ステップ１０１２）。この際に返される情報は以下のものである。
(1) 機密文書識別子
(2) サーバ識別子

（６−３）プロキシファイルの生成：クライアントシステム側の動作…図９
クライアントシステム２が機密文書サーバ１からの応答を受信すると、その応答に含まれていた二つの情報を用いて、クライアントシステムは指定されたディレクトリにプロキシファイルを生成する（ステップ９６）。なお、プロキシファイルをどこに生成するのかは、クライアントシステムの初期インストール時に設定する。クライアントシステム上でも、ファイルサーバ上でも構わない。どのように運用するのかによって決まる。

（７）文書アプリケーションの機能制限
これまでは機密文書管理システムとしての機能に着目してきた。ここで、このシステムと連携して動作する文書アプリケーションが、このシステムと連携するがために制限されなければならない機能に関して明確にする。ただし、ここで明確にされる文書アプリケーションの機能制限は、ユーザのアクセス権限に応じて制限されるような様々な機能（例えば「印刷機能」）についてのものではない。そうではなくて、この機密文書管理システムと連携して動作するがために、ユーザのアクセス権限とは関わりなく共通して制限される機能についてのものである。

（７−１）アプリケーション連携と非連携
アプリケーションの機能制限とは、本発明の機密文書管理システムと連携して動作するアプリケーションは、連携して動作する場合には幾つかの機能が制限されるが、連携して動作しない場合、つまり、ユーザにとって通常の仕方で（単独で）起動されて動作する場合には、いわばフルスペックの標準的な機能を備えた文書アプリケーションとして何ら変わりなく動作する。

この機密文書管理システムと連携して文書アプリケーションが動作するメカニズムは、既に説明してきたように、あくまでもクライアントシステムの内部から起動され、制御される点にある。ここに、外部から文書アプリケーションの機能を制限する可能性が生まれる。従って、この機密文書管理システムと連携し、その場合には機能が制限されるからといって、いわば、その代償として、通常の使用の場合でも常に文書アプリケーションの機能が制限されてしまうことは、ない。

（７−２）「ファイル機能」の制限
最大の問題は「ファイル機能」にある。ファイルを「開く」、「閉じる」、「上書き保存する」、「名前を変えて保存する」等々、この機密文書管理システムのコンセプトから見ると、この一連の機能、文書アプリケーションとしては極めて当然の機能にこそ、このアプリケーションを本実施の形態の機密文書管理システムと共に立ち上げた場合には大きな問題点を有している。

典型例は「名前を変えて保存する」機能である。このシステムが稼働している環境で、この機能を実行するということは、機密文書を単に名前だけを変えてコピーしていることに等しい。このような機能は、気密文書管理システムと共に実行されルアプリケーションにおいては、ユーザのアクセス権限がどのようなものであろうとも禁止されなければならない。

「開く」機能および「閉じる」機能に関しては、本実施の形態のシステムは、必ず特定のプロキシファイルが起点として処理を行うものであるから、本実施形態のシステム下で実行されるアプリケーションは、常に一つの文書だけを処理対象にしているため、不要である。すなわち、文書アプリケーションが起動したときには既に文書は開かれており、わざわざユーザが「開く」ことは必要ないし、その文書を「閉じる」ということは、その文書の処理を「終了」することと等しい。別の文書を処理したい場合には、別のプロキシファイルにアクセスすればよいだけである。

「上書き保存する」機能には問題がない。これは、本実施形態のシステムとアプリケーションとが連携して動作している場合にも機能する。要するに、ユーザのアクセス権限に関わりなく制限されなければならない機能の基準は以下のものになる。
(1) 機密文書のコピーに繋がるような機能
(2) 意味を失ってしまうためユーザに混乱を引き起こしかねないような機能
(3) 常に一つの文書を処理するという原則に抵触するような機能
この基準に従って、汎用的な文書アプリケーションの多様な機能（特にファイル関係の機能）は、この機密文書管理システムと連携する限り、制限されなければならない。

（８）機密文書ディスクファイル化の問題点
本実施形態の機密文書管理システムは、汎用的な文書アプリケーションのレイヤで仮想的に集中型ネットワークを構築するものである。従って、本来であればクライアント側に機密文書をディスクファイル化してはならない。ディスクファイル化した途端に、クライアントユーザによってコピーされる可能性が生じるからである。しかしながら、殆んどの汎用的な文書アプリケーションは、自分が処理する文書ファイルがディスクファイルであることを前提として動作する。従って、この機密文書管理システムでも、クライアント側で機密文書をディスクファイル化せざるを得ない。

ここで、クライアント側ではなく、サーバ側でディスクファイル化する方法も考えられる。この選択肢にはメリットもあればデメリットも考えられるが、本質的には上記の問題に対する解決策にはならない。なぜならば、たとえサーバ側でディスクファイル化したとしても7、その機密文書にアクセスするユーザにはアクセス権限を与えざるを得ず、従って、そのユーザはサーバ上にディスクファイル化されている機密文書をコピーすることが可能になるからである。

なお、機密文書サーバ上に格納されている機密文書は、もちろんディスクファイル化されている。ここで問題にしているのは、この機密文書のことではなく、クライアントシステム側のリクエストに応えて転送され復号化された後に文書アプリケーションによってオープンされる機密文書のことである。機密文書サーバ上に格納されている機密文書は、もちろん、ユーザにはアクセス不能であり、この点はシステムの根本的な仕様である。

クライアント側であれサーバ側であれ、ディスクファイル化された途端に、そのファイルに対するアクセス権限を持つユーザにはコピーが可能になる。しかし、「内部の敵」に対抗すべく構想されたこのシステムが禁止しようとしているのは、まさにこの事態である。汎用的な文書アプリケーションがディスクファイルを前提として動作する限り、機密文書のディスクファイル化は不可避である。

この極めて困難で決定的な問題の解決手段の一つは、システムによる一時的な暗号化である。機密文書のディスクファイル化が不可避であるとすれば、残る方策は、たとえコピーされても権限のないユーザには解読不能なように暗号化あるいはパスワードロックなどを施すしか道は残されていない。しかし、外部のシステムにより単純に暗号化(パスワードロック) してはならない。なぜならば、そこで暗号化された機密文書は文書アプリケーションによって直接的に処理されるファイルなのだから。つまり、外部のシステムが勝手に暗号化（パスワードロック）すると、肝心な文書アプリケーションが処理できないファイルになってしまうのである。

ということは、ここでディスクファイル化された機密文書をシステムが暗号化（パスワードロック）する際には、対応する文書アプリケーションがサポートしている暗号化(パスワードロック）でなければならない、つまり、より具体的に言えば、文書アプリケーション自身に暗号化(パスワードロック)させなければならないことになる。これが、決定的な必要条件である。

現実には、Word やExcel などの文書アプリケーションでは、既にパスワードロックやファイル暗号化がサポートされているために、ディスクファイル化されたタイミングで、システムが外部から一時的にパスワードロックをかけることは可能である。この際、外部からパスワードロックをかける場合には、そのパスワードをシステムが自動生成するために（一種の「セッションキー」）、使用しているユーザですら、そのパスワードを知ることはできない。また、知らなくても、この一連の処理はシステムが背後で自動的に行うために、ユーザには全く問題がない。かくして、この機密文書がどこかにコピーされたとしてもユーザ自身を含めて誰にもオープンすることはできない。

以上の対策によって、たとえ機密文書がディスクファイル化されコピーされたとしても、システム以外の誰にも読むことができなくなる。ただし、このパスワードロックやファイル暗号化のセキュリティ強度は、その機能を持つ文書アプリケーションに依存すること（要するに等しいこと）になるので必ずしも十分なものとはいえない。しかし、そもそも機密文書がディスクファイル化されていることをユーザが気がつかなければ、そして、仮に気がついたとしても、ファイルとして見つけることができなければ、より信頼性が向上するのは言うまでもない。

本実施形態の機密文書管理システムでは、編集や参照の際には、ユーザに対して完全に透過的に動作するので、通常、ユーザがディスクファイル化された機密文書を意識することはない。ユーザが、ファイルとして意識するのはプロキシファイルだけであって、それを経由してアクセスされる機密文書ではない。機密文書は、そのタイプに応じて自動的に起動される、文書アプリケーションの中でだけ意識するものに過ぎず、一個のファイルとして意識するものではない。

更に、本実施形態においては、ディスクファイル化された機密文書をユーザの目から隠蔽するために以下の対処を行なおう。
(1) 機密文書をディスクファイル化する際には、それを格納するディレクトリを大量に、かつ深いところで、動的に生成する。
(2) 文書アプリケーション上では機密文書のファイル名だけを表示し、ディレクトリの位置は表示せず、また参照もできないようにしておく。
(3) 殆んどの文書アプリケーションに標準的な機能として搭載されているファイルの「オープン履歴」から、機密文書の履歴だけを削除する。
(4) 文書アプリケーション上で表示するファイル名はプロキシファイルのファイル名であり、ディスクファイル化された機密文書のファイル名とは異なるようにしておく。ディスクファイル化された機密文書のファイル名は、そのたびごとに動的に生成し予測困難なものにしておく。

前記のように、本実施形態の機密文書管理システムと連携して動作する文書アプリケーションには、ファイルの「新規作成」や「開く」、「名前をつけて保存」などのファイル関連の機能が存在しない。従って、ユーザが仮にディスクファイル化された機密文書を探索しようとしても、その手がかりは文書アプリケーション上には存在しない。この点で、探索するのは絶対に不可能とは言わないまでも、相当に困難な状況を産み出すことはできることになる。そもそも、ユーザはディスクファイル化された機密文書のファイル名すら直接的には知ることができないのである。ユーザが知ることができるのは、文書アプリケーション上に表示された（プロキシファイルのファイル名に由来する）ファイル名だけある。つまり、通常の一般ユーザに探索することは非常に困難である。

言うまでもないことであるが、ディスクファイル化された機密文書の隠蔽という観点から見れば、以上の対処は決して完全なものではない。ディスクファイル化された機密文書の探索は、それがディスクファイル化されている限り、原理的には不可能ではない。しかし、通常の一般ユーザには探索することが非常に困難な状態を作り出すことは可能であり、その限りで、ユーザが「内部の敵」へと変貌する可能性を劇的に低減することができる。

仮にユーザがディスクファイル化された機密文書を発見したとしても、そのようなユーザの全てが「内部の敵」へと変貌するとは限らない。もし変貌して、何らかの外部媒体に、その機密文書をコピーしたとしても、既にシステムによってパスワードロックや暗号化が施されているために、そのユーザ自身も含めて誰にも解読することができない。

以上の対処によって、本実施形態によれば、実効的には、ユーザの目からディスクファイル化された機密文書を隠蔽したと言うことができる。従って、結果的には、図１１に示すような特徴を有し、しかも、汎用的な文書アプリケーションのレイヤで仮想的な集中型ネットワーク環境を構築することができる。

本発明に係る機密文書管理システムの概念を示す模式図。 本発明に係る機密文書管理システムの一実施形態の構成を示す機能ブロック図。 本実施形態におけるクライアントシステム２と機密文書サーバ１間の情報のやり取りを説明する模式図。 本実施形態における機密文書のリクエストと受領を行うクライアントシステム２側の処理フロー図 本実施形態における機密文書リクエストの受信と機密文書の更新を行う機密文書サーバ側の処理フロー図。 本発明において機密文書サーバが複数ある場合の情報のやり取りを説明する模式図。 機密文書サーバが複数ある場合における機密文書リクエストの受信処理を示す処理フロー図。 クライアントシステム２と機密文書サーバ１間の情報のやり取りを説明する模式図。 機密文書のリクエストと受領を行うクライアントシステム２側の処理フロー図。 機密文書リクエストの受信と機密文書の更新を行う機密文書サーバ側の処理フロー図。 本発明の機密文書管理システムにおける各部の特徴を示す模式図。 本実施形態におけるアプリケーションのメニュー項目の自動的な削除を示す画面例。 本実施形態におけるアプリケーションの機能の制限を示す画面例。 本実施形態における機密文書のインポート操作時を示す画面例。

符号の説明

１…機密文書サーバ
２…クライアントシステム
３…ファイルサーバ
１０…機密文書格納部
１１…情報格納部
１２…認証処理部
１３…ファイル保護処理部
１４…ロギング部
１５…メッセージ送受信部
１６…異常検知部
１７…排他制御部
２０…プロキシファイル格納部
２１…情報格納部
２２…アプリケーション
２３…アプリケーション制御部
２４…機密文書管理部
２５…メッセージ送受信部
３０…プロキシファイル格納部

Claims (10)

1. 暗号化された機密文書を格納した機密文書サーバと、この機密文書サーバに対してネットワークを介して接続されたクライアントシステムとを備え、このクライアントシステムに設けられたアプリケーションによって前記機密文書の編集を行う機密文書管理方法において、
   前記機密文書を復号化して生成されたプロキシファイルを前記機密文書サーバとクライアントシステムとの間に介在させ、前記機密文書に対するユーザのアクセス権に従って前記プロキシファイルを介して対応する機密文書の編集を行わせことで前記機密文書の存在をユーザから隠蔽すると共に、このプロキシファイルを介して前記機密文書を編集するアプリケーションに対して、前記機密文書に対するユーザのアクセス権に対応した機能制限と前記機密文書の編集に対する各ユーザに共通の機能制限とを行うことを特徴とする機密文書管理方法。
2. ユーザの機密文書の編集要求を取得した機密文書サーバが、編集要求に関する改竄不能なアクセスログの作成、異常アクセスの検出及び秘密文書管理者に対する通知の少なくとも１つを実行することを特徴とする請求項１に記載の機密文書管理方法。
3. 前記アプリケーションに対する機能制限を、アプリケーションレベルでユーザに認識させることを特徴とする請求項１または請求項２に記載の機密文書管理方法。
4. 機密文書を復号化してプロキシファイルを生成をクライアントシステム上で行うことにより機密文書をクライアントシステム側でディスクファイル化し、このディスクファイル化に当たって、パスワードロックなどの暗号化機能を有するアプリケーションに対してアプリケーション外部から暗号化を実行させると共に、
   (1) 機密文書をディスクファイル化する際には、それを格納するディレクトリを大量に、かつ深いところで、動的に生成する。
   (2) アプリケーション上では機密文書のファイル名だけを表示し、ディレクトリの位置は表示せず、また参照もできないようにしておく。
   (3) アプリケーションとしてファイルの「オープン履歴」を有するものを使用し、その「オープン履歴」から、機密文書の履歴だけを削除する。
   (4) 文書アプリケーション上で表示するファイル名はプロキシファイルのファイル名であり、ディスクファイル化された機密文書のファイル名とは異なるようにしておく。ディスクファイル化された機密文書のファイル名は、そのたびごとに動的に生成し予測困難なものにしておく。
   という(1) から(4) の処理の少なくとも１つを実行させることを特徴とする請求項１から請求項３のいずれか１項に記載の機密文書管理方法。
5. 暗号化された機密文書を格納した機密文書サーバと、この機密文書サーバに対してネットワークを介して接続されたクライアントシステムとを備え、
   前記機密文書サーバは、暗号化された機密文書の格納部と、機密文書に関する情報及びユーザに関する情報を格納した情報格納部と、機密文書にアクセスするユーザの認証を行う認証処理部と、クライアントシステム側との間で情報の授受を行うメッセージ送信部とを備えた機密文書管理システムにおいて、
   前記クライアントシステムは、機密文書を復号化して生成されたプロキシファイルの格納部と、ユーザの認証情報と機密文書サーバに関する情報を格納した情報格納部と、プロキシファイルを介して機密文書を編集するためのアプリケーションと、このアプリケーションに関して前記機密文書に対するユーザのアクセス権に対応した機能制限と前記機密文書の編集に対する各ユーザに共通の機能制限とを行うアプリケーション制御部と、アプリケーションによるプロキシファイルを介した機密文書の編集及びシステムによる機密文書への直接的な制御を実行する機密文書管理部と、機密文書サーバとクライアントシステム間でメッセージの授受を行うメッセージ送受信部とを備えていることを特徴とする機密文書管理システム。
6. 前記機密文書サーバがネットワークに対して複数接続され、これら複数の機密文書サーバの少なくとも１つが他の機密文書サーバに対するユーザのリクエストについて、その認証処理を行う認証処理部を有していることを特徴とする請求項５に記載の機密文書管理システム。
7. 前記機密文書サーバが、同一の機密文書に対する複数のリクエスト要求を検出し、これをクライアントシステム側のユーザに通知する排他処理部を有していることを特徴とする請求項５または請求項６に記載の機密文書管理システム。
8. 前記機密文書サーバが、編集要求に関する改竄不能なアクセスログを作成するロギング部、異常アクセスの検知部または秘密文書管理者に対するメッセージの送受信部の少なくとも１つを有することを特徴とする請求項５から請求項７のいずれか１項に記載の機密文書管理システム。
9. プロキシファイルを経由してリクエストされた機密文書をサーバからクライアントシステムに向けて転送する直前、またはユーザが編集作業を完了して文書ファイルがサーバへ転送された直後の少なくとも一方のタイミングで機密文書単位でファイル保護処理を実行するファイル保護処理部を有することを特徴とする請求項５から請求項８のいずれか１項に記載の機密文書管理システム。
10. 前記認証処理部は、アクセスしたユーザの認証が妥当な場合に、
    (a) リクエストされた機密文書
    (b) その機密文書の文書タイプなどの管理情報
    (c) そのユーザの当該機密ファイルに対するアクセス権限情報
    をクライアントシステムに送信することを特徴とする請求項５から請求項９のいずれか１項に記載の機密文書管理システム。