−−−実施例1−−−
以下、図面を適宜参照しつつ、実施例について説明する。図1は第1実施例に係るファイル管理システムの構成図である。ファイル管理システム1000は、ポリシー設定サーバ10、状態管理サーバ20、ログ管理サーバ30、インターネットサーバ41、1台以上のセンサ50、1台以上のプリンタ60、1台以上のクライアント70、文書管理サーバ80、ID管理システム90、資産管理システム100、が有線あるいは無線でネットワーク40に接続された構成をとる。
利用者1は例えば自身のユーザIDが耐タンパ領域に格納されたICカード76を用いて組織への入退室を行う。なお、組織とは建屋あるいは執務室などの居室を分ける部分にセンサが設置されており、最も外側に配置されたセンサの内側を指す。利用者1はさらに、クライアント70あるいは可搬媒体77あるいはノートPC78を使って種々の作業を行う。利用者1は一意に特定可能なユーザ情報を耐タンパ領域に格納した携帯電話79を持っており、組織内外に携帯電話79を持ち歩く。また、クライアント70では、カードリーダ795を接続し、ICカード76を読み込ませてクライアント70と通信することにより、ICカードに記録されたIDを読み込むこともできる。管理者2はポリシー設定サーバ10を使って種々の作業を行う。承認者3は文書管理サーバ80を使って種々の作業を行う。
センサ50は組織の建屋や執務室を分ける入口などに設置してあり、例えば支店のように、同じ組織で物理的な建屋が離れている場合にも、センサ50が設置してあれば、利用者1がICカード76をかざすことにより、センサがICカードのIDを読み取り、認証を行って入退室が可能である。
インターネットサーバ41とは、ネットワーク40内あるいはインターネットでやりとりされる電子メール43の送受信を中継し、送受信した電子メールを保存する電子メールサーバあるいは、インターネット42とのWeb通信を中継するProxyサーバなどである。
さらにクライアント70は、CD−R/DVD−RやUSBフラッシュメモリ、ポータブルHDD、マルチメディアコンテンツを格納するSDカードなどの可搬媒体77が接続可能であり、クライアント70は可搬媒体77とファイル交換をすることができる。
ここで、クライアント70は利用者1ごとに割り当てられていることを原則とする。なお、クライアント70が2人以上の利用者に割り当てられていてもよく、その場合にはクライアント70が利用者を識別および認証することにより、どの利用者がクライアント70を利用したのかを区別できるようにすればよい。さらに、クライアント70で複数人が共通のアカウントを用いてクライアントを使用する場合、ID管理システム90でアカウント管理を行うことにより、誰がどのアカウントと紐付いているかを把握しておく。
さらに図1を使って、ポリシー設定サーバ10、状態管理サーバ20、ログ管理サーバ30、センサ50、クライアント70、文書管理サーバ80、ノートPC78におけるソフトウェア構成を説明する。
ポリシー設定サーバ10では、ファイルに適用するポリシーを格納したポリシーリスト13を設定するポリシー設定プログラム11と、ポリシー設定プログラム11で設定したポリシーリスト13をクライアント70に配信するポリシー配信プログラム12を備える。さらに、ポリシー設定プログラム11およびポリシー配信プログラム12では、作業したログを端末ログ14に格納する。ポリシー設定プログラム11は、管理者2が直接ポリシー設定サーバ10にアクセスするか、管理者用の端末からネットワーク40を介してアクセスしてもよい。
状態管理サーバ20では、ラベル管理リスト23と状態管理リスト24、復号鍵リスト25、端末ログ26を備えており、ログ管理サーバ30のログ解析プログラム31から受信したセンサログと、ID管理システム90のユーザの属性情報を格納するユーザリスト91をつき合わせ、ユーザリスト91に登録したユーザの所在を状態管理リスト24に書き込む状態管理プログラム21が動作する。さらに状態管理プログラム21は、クライアント間をファイルが移動する場合に、ファイルの格納先情報を管理するラベル管理リスト23の更新も行う。また、状態管理サーバは、利用者1が持ち歩く携帯電話79の認証を行う認証プログラム22と、認証が成功した携帯電話に配信する復号鍵リスト25を備える。これにより、利用者が組織外にいる場合でも、本実施例で説明するファイルの制御を行うことが可能となる。
ログ管理サーバ30では、クライアント70、文書管理サーバ80、ポリシー設定サーバ10でそれぞれ取得した端末ログと、センサ50で取得したセンサログ52を収集し、収集した端末ログを解析してログを整形して収集ログ32に格納し、収集ログのうちセンサから取得したセンサログを状態管理サーバ20に送信するログ解析プログラム31が動作する。
クライアント70では、利用者1の操作を詳細に監視し、操作発生時には、対象となるファイルのラベル情報を格納したラベル管理テーブル74と、ポリシー設定サーバ10から受信したポリシーリスト73を参照し、ポリシーに従って操作を許可あるいは防止し、制御した結果をログとして端末ログ75に格納する監視・制御プログラム72が動作する。
文書管理サーバ80では、ファイルにラベルを割り当てるラベル割当プログラム81と、クライアント70に備えた監視・制御プログラム72と同じ機能を備える監視・制御プログラム82が動作する。ラベル割当プログラム81は、クライアント70で利用者1が申請したファイルのラベル情報を受け付け、承認者による承認あるいは変更要求を受け付け、ラベル管理リスト84を更新する。ラベル割当プログラム81で割り当てたファイルとラベルとの対応関係情報は、ラベル管理リスト84に格納する。文書管理サーバ80のラベル割当プログラム81および監視・制御プログラム82で実行した操作のログは端末ログ85に格納される。なお、文書管理サーバ80に格納したファイルは、組織内で審査済みのファイルとし、上書き禁止として取り扱いを行う。
なお、本特許で述べるファイルとは、システムファイルなどではなく、組織内で生成あるいは外部から入手した、組織内で価値のある情報資産全てを対象とする。
図2は、ファイル管理システム1000におけるクライアント70のハードウェア構成を示すブロック図である。クライアント70は、端末ログ75ならびにポリシーリスト73、ラベル管理テーブル74を保存する外部記憶媒体702、監視・制御プログラム72を実行するCPU701、メモリ703、入出力画面を表示する表示部704、入出力を制御する操作部705、可搬媒体77に格納されたデータなどを読み書きするための可搬媒体接続部706、RAM707、有線あるいは無線でネットワーク40と通信を行う通信部708、これらの各装置等を相互接続するバス709から構成される。
また、文書管理サーバ80、ポリシー設定サーバ10、状態管理サーバ20、ログ管理サーバ30も、図2に示したクライアント70のブロック図と同様のハードウェア構成をとる。ただし、文書管理サーバ80、ポリシー設定サーバ10、状態管理サーバ20、ログ管理サーバ30に可搬媒体接続部706は必ずしもなくてよい。
各装置では、CPUが外部記憶媒体702に格納されたプログラムを実行することにより、以下に説明する処理、機能が実現される。ただし、各実施形態の説明では、便宜上、各プログラムを実行主体としている。
また、各プログラムは、あらかじめ、上記各装置の外部記憶媒体702やメモリ703に格納されていても良いし、必要なときに、可搬媒体接続部706や通信部708と、各装置が利用可能な媒体と、を介して、他の装置から導入されてもよい。媒体とは、たとえば、着脱可能な可搬媒体77、または通信媒体(すなわちネットワーク40またはネットワーク40を伝搬する搬送波やディジタル信号)を指す。
図3にポリシーリスト13のデータ構造の一例を示す。ポリシーリスト13は、クライアント70、文書管理サーバ80、可搬媒体77、ノートPC78のいずれかに格納しているファイルに対して操作が発生した場合に操作を実行する条件を記録したものであり、ポリシー設定サーバ10上およびクライアント70上の記憶装置に格納したものである。
ポリシーリスト13は0個以上のエントリから構成される表データであり、情報のカテゴリとレベルの組合せについて設定したラベル281、情報のカテゴリ282、情報の機密性の度合いを示すレベル283、制御対象とする操作284、284の操作を実行するための条件を示すアクセス主体285、ID管理システム90のユーザリスト91に登録されていないユーザあるいはインターネット42を介してアクセス可能なWebサイトなどにおいてファイルを共有可能な共有先286、からなる。
以下、ポリシーリスト13の構成について詳細に説明する。
まず、ラベル281は、列282に示すカテゴリと、列283に示すレベルとの組合せで設定する。なお、ラベル名は列281に示すようにアルファベットでもよいし、ラベルが一意に特定できる名称であればその他の名称でもよい。
ラベルをカテゴリとレベルの組合せで設定するのは、現在情報の種類は多様化しており、レベルやカテゴリによって共有範囲などの取り扱い規則が異なるためである。例えば、情報の共有範囲を大きく以下の4つに分類した場合、それぞれの取り扱い規則は異なるため、それぞれの共有範囲を越えないようなコントロールが必要である。
(1)一般に公開可能なもの
組織内で審査済みのものや、外部から入手した公開情報など。
(2)組織内だけで共有したいもの
ドラフト版や分類不能なものも含めて、大多数の情報が該当する。
(3)組織内でもさらに共有範囲を制限したいもの
機密レベルや種類に応じて分類可能。
(4)特定の組織(組織外)と共有したいもの
取引先や委託先ごとに分類可能。
さらに、各クライアント70に格納しているファイルは、作成途中のドラフト版のものや、完成した文書なども混在する。これらのファイルについて、それぞれ異なる共有範囲を越えないようにするためには、ファイルを取り扱う人だけではなく、ファイルを格納する場所や利用場所を操作ごとに制限すべきである。ポリシーリスト13は、共有範囲の異なる単位をカテゴリとレベルからラベルとして設定し、さらに、ラベルごとに操作に対するアクセス主体および共有先を指定した上で、ラベルをファイルに割り当てることで、情報の種類にあわせたきめ細かいポリシーを適用することができる。
なお、ラベル281は、ラベルが未設定のファイルに割り当てるポリシーとして、ラベルなし2811というラベルを設定し、操作に対する条件の設定を行う。本実施例では、ファイルに対して利用者1がラベルを割り当てると、例えばクライアント70の監視・制御プログラム72がラベルに紐付くポリシーを適用するが、クライアントが格納するファイル全てについてラベルを割り当てるのは手間がかかる。さらに、ラベル付けされないファイルについて制御対象から外れ、漏洩してしまう可能性も考えられる。そこで、ラベルが割り当てられていないファイルについては、少なくとも社外秘として扱い、組織外に情報が持ち出されるような操作は制御すべきと考え、ラベルなしのポリシーも設定し、適用することとする。
次にカテゴリ282は、組織の情報の種類に基づいて設定する値であり、例えば「人事情報」「財務情報」「技術情報」などの情報の種類を定義してもよいし、「取引先A」などのように顧客情報としてもよい。これらの値は、管理者2がポリシー設定プログラム11を用いて追加あるいは修正可能である。
レベル283は、情報の価値に基づいて設定する値であり、例えば「極秘」「秘」「公開」「未設定」を定義する。これらの定義は、ラベルの割り当てを行う利用者1およびラベルの承認を行う承認者3が設定しやすいような分類とする。
操作284は、従来のアクセス制御技術でアクセス権を指定した操作である「閲覧」「編集」に加えて、情報の共有範囲を越えて漏洩につながる可能性の高い操作まで定義したものであり、例えば「閲覧」「編集(ファイルの削除、ファイル名の変更なども含む)」「コピー(電子、紙、スキャンなど)」「印刷」「ネットワーク送信(以下、NW送信とする)(メール、Webアップロードなど)」「持ち出し」などを定義する。
アクセス主体285は、 操作284を実行可能な条件を定義したものであり、具体的にはアクセス主体条件一覧301を元に設定する。アクセス主体285は、少なくとも0個以上の論理式から構成されるデータであり、アクセス主体条件一覧301から選択した条件を一意に識別可能な式を定義する。なお、論理式は、該操作を実行可能な条件、または許可しない条件を書く。さらに、論理式は記号「^」でAND演算子を示し、記号「|」でOR演算子を示す。AND演算子で接続された条件式が情報の取り扱い条件を示す。
アクセス主体285の定義方法についてはアクセス主体条件一覧301のデータ構造を説明した後述べる。
アクセス主体条件一覧301は、少なくとも1個以上のエントリから構成される表データであり、条件として設定する候補となるカテゴリ番号302、カテゴリ番号302について組織が選択し得る属性情報を示すカテゴリの概要303、カテゴリ303で組織が選択し得るデータ(304〜308)、からなる。
カテゴリ303は、例えば「雇用区分」「役職」「組織名」など利用者の属性情報や、ファイルを取り扱う利用者の場所、ファイルを格納する媒体の種類、組織外で利用するための条件、などを定義する。
カテゴリごとに設定するデータ(列304〜列308)は、例えばアクセス主体条件一覧301のC1に記載した「雇用区分」では、「パート」「契約」「社員」など、組織で選択し得る属性情報を定義する。なお、より細かく定義したいカテゴリや属性情報があれば管理者2が追加してもよい。これらのデータに関して、利用者や資産の管理は、別途ユーザリスト91および資産リスト101を用いて行う。ユーザリスト91は、ID管理システム90で管理され、例えば「氏名」「雇用区分」「役職」などの属性情報を、利用者を一意に特定可能なユーザID単位で管理するものである。また、資産リスト101は、資産管理システム100で管理され、例えば「資産ID」や記憶媒体の種類を示す「種類」、「所有部署」、「媒体識別ID」などを資産単位で管理するものである。これらユーザリスト91および資産リスト101は、利用者および資産の追加に伴う登録、あるいは利用者の移動や退職、資産の所有部署の変更や滅却に伴う項目の削除について、ID管理システム90および資産管理システム100の一般的な機能を用いて行われることとする。
さて、ポリシーリスト13におけるアクセス主体285の定義方法について説明する。「閲覧」操作を実行する条件2861では、「C1=3^C2>3^C3=3^C4>2」を記述している。これらの式で左辺に記述する項目は、アクセス主体条件一覧301のカテゴリ番号302を示し、右辺に記述する項目は列304〜列308に示したデータの番号を示す。この例では、「C1が示す雇用区分が3(すなわち社員)」、かつ「C2が示す役職が3より大きい役職(すなわち課長以上)」、かつ「C3が示す組織名が3(すなわち研究部門)」、かつ「C4が示す場所が2より大きい(すなわち執務室、サーバ室、実験室のいずれか)」という条件を全て満たす場合、閲覧操作を実行可能であることを示す。このように、情報のカテゴリとレベルの組合せで定義するラベルについて、共有範囲を越える可能性のある操作ごとにアクセス主体を設定しておくことにより、きめ細かい条件設定を行うことが可能となる。
なお、アクセス主体285について、どのような条件でも操作を許可しないカテゴリについては何も記述しなければよい。例えば、「持ち出し」操作を実行する条件2864には何も記述していない。これは、どのような条件であってもファイルの持ち出しは許可しないことを意味する。
さらに、制限が不要なカテゴリについても式に含めなければよい。例えば、「編集」操作を実行する条件2862に「C5>3」を記述する。この場合は、C5の条件を示す格納媒体の条件を満たせば、その他のカテゴリのデータが何であれ操作を許可することを意味する。
一方、どのような条件でも操作を許可する場合には「*」を記述する。例えば、「NW送信」操作を実行する条件2863は「*」と記述してあるため、どのような条件であってもNW送信を実行できることを意味する。
ポリシーリスト13における共有先286では、組織外における情報の共有先を指定する。主に操作284のNW送信において、取引先の担当者などが決まっている場合や、ファイルをアップロードするWebサイトのURLがわかっている場合、予め担当者のメールアドレスやURLを登録しておくことによって、登録した担当者やURLには組織外であってもファイルを共有可能として設定できる。また、これらの情報を登録しておくことにより、メールアドレスの入力間違いによる誤送信や、送信するファイルを間違えて送信してしまうことを防止することが可能となる。共有先(列286)として登録していない場合についても、承認者3に共有先情報と目的などを申請し、承認を得ることでこれらの操作を実行することが可能である。
以上述べた構造のポリシーリスト13を備えることにより、従来技術のようなユーザの閲覧および編集だけを監視・制御するのではなく、漏洩につながる可能性の高い幅広い操作に対する実施条件を設定することができる。
さらに、本ポリシーはポリシー設定サーバ10に格納したポリシーリスト13で一元管理し、管理者2がポリシー設定プログラム11を用いて予め設定する。管理者2は定期的な見直しの都度、あるいは利用者からの申請に応じてポリシーを変更してもよい。本実施形態では、ファイル300に対してラベル281を割り当てているため、一度ラベルをファイルに割り当てた後に、ラベルを定義するカテゴリやレベル、および各操作に対するアクセス主体の変更を行っても、既に割り当てたファイルには影響しない。また、ポリシーリスト13はポリシー配信プログラム12によってクライアント70にも配信され、クライアント70の監視・制御プログラム72で参照されるため、ファイルのコピーなどによりクライアントが変わった場合でも、ラベルがわかれば同じポリシーを適用することができる。より具体的なポリシーの設定例と実現可能な制御については図4で述べる。
図4に、図3で説明したポリシーの具体的な例を示し、情報の種類ごとにきめ細かい制御ができることを示す。図4では、4種類のラベルを定義した例として、ラベル「A」の定義を4001、ラベル「B」の定義を4002、ラベル「C」の定義を4003、ラベル「なし」の定義を4004に示す。
ラベルA4001は、レベルが極秘の人事情報に割り当てたラベルであり、組織内でもさらに共有範囲を制限したいものである。このような情報は、社外に持ち出す用途はなく、組織内でも公開期限になるまで共有を制限すべきである。そのため、ラベルA4001が割り当てられたファイルの制御として、持ち出しは許可せずに、閲覧操作からNW送信までの操作を、課長以上の社員が執務室のデスクトップPCでのみ実行できる条件を設定する。これにより、例えば、課長以上の社員がラベルA4001のファイルをデスクトップPCから可搬媒体へコピーしようとしても、コピー操作ができる装置としてデスクトップPCを設定しているため、条件を満たすことができず、実行できない。また、NW送信についても、共有範囲が課長以上のため、課長が誤って部下にファイルを転送するような操作も防止することができる。万が一、部下がファイルを入手したとしても、閲覧条件が一致しないため、見られることはない。
ラベルB4002は、公開可能なカタログ情報に割り当てたラベルである。用途としては、社内での閲覧から社外の特定顧客への説明など持ち出す行為まで想定される。そのため、ラベルB4002が割り当てられたファイルの制御として、閲覧およびNW送信は「*(条件なしで可能)」とし、それ以外の操作の条件を設定する。例えば、既に公開されているため、上書きを禁止するために、「編集」操作を許可しないなどがある。一方、持ち出し操作は社員がRFID貼り付け紙以外の媒体を利用すれば、共有先を選ばずに組織外に持ち出すことができる。
ラベルC4003は、レベルが秘の取引先Aに割り当てたラベルである。本情報は、組織内でも取引先Aと関係のあるユーザのみ、また、組織外では取引先Aの利用者のみと情報を共有すべきである。そのため、ラベルC4003が割り当てられたファイルの制御として、社内では、研究または営業部門の契約社員以上の利用者が、執務室以上の場所で閲覧や編集操作を行うように定義する。また、NW送信の共有先として、取引先Aの担当者のメールアドレスを登録し、持ち出し先として、取引先Aの東京オフィスを登録する。これにより、利用者が取引先Aに作成したファイルをメールなどで送信あるいは持ち出す場合は、登録したアドレスまたは宛先以外には承認がないと実行できない。また、承認を得ずに持ち出した場合、あるいは利用先として登録してある取引先Aの東京オフィス以外においても操作できない。なお、ファイルの持ち出し処理の詳細については図13から図15で説明する。
ラベル未設定4004は、ラベルが割り当てられていないファイルに割り当てるラベルである。ラベルが未設定のファイルは、本来極秘で扱うべき情報から、公開する情報までが混在するため、社外秘と同じ共有範囲にすることや、最も狭い範囲となるよう共有範囲を設定し、制御すべきである。そのため、例えば、印刷やNW送信、持ち出しの操作は禁止し、閲覧や編集、コピーを利用者自身のクライアントでのみ(「ID」部分)行わせる。なお、誰かと共同でファイルを作成する場合や情報共有する場合など、利用者自身以外とファイルを共有する必要がある場合には、「未設定」以外の該当するラベルを割り当てればよい。
なお、ラベル未設定のポリシーは組織における業務などに応じて変更してもよく、例えばIDシステムと連携して、ファイルの利用者の職制情報や所属が同じである利用者間、あるいは利用者の役職以上のユーザとの間では閲覧、編集、印刷、NW送信を許可するポリシーとすることも考えられる。
また、ラベル割り当ての手間を削減する方法の一つの例として、予めテンプレートが決まっているファイルについては、ラベルを割り当てたテンプレートを文書管理サーバ80に格納し、利用者がダウンロードして利用する。
以上説明したように、ポリシーリスト13を定義することにより、情報の種類によって操作を行う利用者の属性や場所、情報を格納する媒体を制限することができる。以下に、漏洩につながる可能性の高い操作と、操作を防止するためのポリシーの一例を示す。
(1)情報の持ち出し制御
例えば、ラベルAのように高い機密性が要求されるファイルへのコピー操作に対して、コピー先をデスクトップPCに限定することにより、価値が高い情報を漏洩につながる可搬媒体に書き出す行為を禁止することができる。また、ラベルB4002の公開可能なファイルに対しては、可搬媒体へのコピーや持ち出しも可能とし、ラベルCでは持ち出しにあたり、持ち出しの承認が必要とすることにより、情報の種類に応じて持ち出しの制御ができる。
(2)持ち出したファイルのアクセス制御
例えば、ラベルA4001の閲覧操作に対して、場所における条件を社内のみとすることにより、ノートPCを社外で利用する場合など、不適切な場所での閲覧を防止できる。なお、これは人の所在を特定することが必要であるため、上記センサ50での入退室情報と連携して制御を行う。具体的な処理については、図14で説明する。
(3)印刷の制御
例えば、ラベルA4001のように印刷する場所を制限するポリシーやラベルB4002のように誰でも印刷可能とするポリシーを設定できる。情報の価値に応じて印刷を制限することにより、機密性の高い情報について閲覧はできても印刷はできないように制御することが可能となる。
(4)ネットワーク送信の制御
例えば、ラベルA4001の機密性の高い情報については、ネットワーク送信を社内に限定することにより、組織外への不正な送信や宛先間違い、送信するファイルの間違いを防止することが可能である。
さらに、ラベルC4003のように社外の取引先と共有するファイルについては、共有先として取引相手や委託先企業のメールアドレスやWebアップロード先のURLを事前に指定してあるため、指定している相手には申請をすることにより、承認者の承認を待たずに操作を行うことができる。また、相手先へ不正に電子メールを送信することや、誤送信の防止、正規の宛先に情報を正しく送信することが可能となる。
(5)社外から社内の機密情報へのアクセス制御
例えば、ラベルA4001の閲覧操作では、閲覧可能な場所を社内にすることを条件として設定する。利用者が退室して社外に出る際にICカードをセンサに近づけてIDを読み取らせることにより、利用者の所在が社外として状態管理リスト24に記録されるため、リモートアクセス機能を利用してラベルA4001のファイルにアクセスしようとしてもアクセスできない。これにより、社外でのノートPC利用が認められている社員が社外でノートPCを操作する場合でも、機密性が高い情報の閲覧は防止できるため、第三者にファイルを見られてしまうことによる漏洩を防ぐことができる。
なお、入退室管理とクライアントへのログインとを連携させ、ICカードをかざして入室し、入室した記録がないとクライアントにログインできないようにすることも可能である。また、退室した記録がないと社外ネットワークからリモートアクセスできないようにすることも可能である。これにより、退室時にICカードをかざさずに、社内にいると成りすましてリモートアクセスする行為を防止することができる。なお、上記説明した制御は一例であり、その他の制御も可能である。
図5にポリシーリスト13の設定画面の一例を示す。
ポリシー設定サーバ10に格納するポリシーリスト13は、管理者2がポリシー設定サーバ10の操作部705を介してポリシー設定プログラム11に直接アクセスする、あるいは、別な端末からネットワーク40を介してポリシー設定プログラム11にアクセスすることで設定する。管理者2がポリシー設定プログラム11にアクセスすると、表示部704が図5に示したポリシー設定画面501を表示する。
ポリシー設定画面501では、新規ポリシーの設定、あるいは登録済みポリシーの設定確認や修正を行う。ポリシー設定画面501は、登録済みポリシーのラベル一覧を表す登録済みラベル一覧510と、新規ポリシーを設定する新規追加ボタン511から構成される。
登録済みラベル一覧テーブル510は0個以上のエントリから構成される表データであり、登録済みポリシーのラベル名5011、ファイルのカテゴリ5012、機密性の度合いを表すレベル5013、ラベル5011に設定済みのポリシーを表示する設定表示ボタン5014、ラベル5011に設定済みのポリシーを修正する画面を表示する修正ボタン5015、ラベル5011に設定済みのポリシーを再利用して新規ポリシーを追加するために設定済みポリシーを複写したポリシー設定画面を表示する再利用ボタン5016、ラベル5011が割り当てられているファイルの登録数5017、からなる。
管理者2が実行したいボタンを押下すると、以下のようにそれぞれ画面が表示される。例えば、設定済みポリシーを参照する場合は列5014のボタンを押下し、設定済みポリシーを修正する場合は列5015のボタンを押下し、設定済みポリシーを複写して新規ラベルを登録する場合は列5016のボタンを押下し、新規ポリシーを追加する場合は新規追加ボタン511を押下する。
管理者2から上記ボタンのいずれかが押下されると、ポリシー設定プログラム11はポリシー設定画面502を表示する。
ポリシー設定画面502は、新規登録するラベル名にカテゴリとレベルを割り当てるラベル設定フォーム520、共有先のURLやメールアドレスを入力する入力フォーム5214、共有先のURLやメールアドレスをID管理システムなどから特定する参照ボタン5215、新規追加するラベルについて、操作ごとに実行する権限を設定する操作権限設定画面522、設定したデータをポリシーリスト13に登録するための登録ボタン523から構成される。なお、ボタン5014が押下された場合には、操作権限設定画面522に設定済みのポリシーを表示し、ボタン5015が押下された場合には、操作権限設定画面522に設定済みのポリシーを表示し、さらに表示した権限を変更することができる。さらに、ボタン5016が押下された場合には、操作権限設定画面522に設定済みのポリシーを表示し、新規追加するようラベル520を修正することができる。
ラベル設定フォーム520では、ラベル名5211を入力し、カテゴリ5212とレベル5213から管理者2が設定したい値をプルダウンから選択する。また、設定したいカテゴリがない場合には、管理者2が新規入力フォーム521に適切なカテゴリ名を入力してもよい。
社外共有先入力フォーム5214では、社外でファイルを共有する相手が予めわかっている場合に、URLあるいはメールアドレスなど相手を一意に識別できる情報を入力する。
操作権限設定画面522は、操作ごとに異なるタブ5221で権限設定画面を切り替えることができるため、管理者2はタブ5221を押下して操作を切り替え、全ての操作の権限を設定する。操作権限設定画面522は、操作権限を設定する表5223と、設定したデータのうち表示している表についてのみ入力を全て無効として初期表示に戻すリセットボタン5222、からなる。
操作権限設定表5223は、図3で説明した情報漏洩につながる可能性の高い操作全てについて権限を設定する表であり、新規追加ボタン511を押下した場合など何も入力されていない場合は背景が白く(5224)表示される。管理者2が操作権限を設定する場合は、操作権限設定表5223のうち、条件に該当させない項目を押下すると、押下した項目の背景を例えば黒に反転する(5225)。このように、操作権限設定表5223で押下した項目の色を変えることにより、操作権限を設定することができる。
管理者が全ての権限を設定して登録ボタン523を押下すると、ポリシー設定プログラム11は、操作権限設定画面522を閉じ、操作権限設定表5223に入力されたデータから図3のアクセス主体285に示した論理式を生成し、入力されたデータ全てをポリシーリスト13に登録する。そして、ポリシーリスト13へのデータ登録が終了すると、登録済みラベル一覧テーブル510の最後の行を新規追加し、設定したラベル情報を表示する。
以上説明したように管理者2がポリシーリスト13を生成し、ポリシー配信プログラム12が更新したポリシーリスト13をクライアント70に配信することにより、クライアント70のポリシーリスト73が更新される。ポリシーリスト13のクライアント70への配信については、図6を用いて説明する。
図6にポリシー配信処理の流れを示す。
クライアント70の監視・制御プログラム72は、プログラムを起動した後(ステップ601)、ポリシー設定サーバ10のポリシー配信プログラム12にアクセスし、クライアント70のユーザIDを送信し、ポリシーテーブルの取得を申請する(ステップ602)。
ポリシー配信プログラム12は、ポリシーテーブル取得申請を受信後、ID管理システム90のユーザリスト91を参照し(ステップ603)、ユーザリスト91に受信したユーザIDが登録されているかを判断する(ステップ604)。ユーザIDが登録されていればポリシーリスト13をクライアント70に配信し(ステップ607)、登録されていない場合はクライアント70の監視・制御プログラム72にエラーを返し(ステップ605)、ポリシー設定サーバ10の表示部704にエラーとユーザIDを表示する(ステップ606)。
クライアント70の監視・制御プログラム72は、ポリシー配信プログラム12からポリシーリスト91を受信すると、クライアント70のポリシーリスト73を更新する(ステップ608)。
本動作フローにより、クライアント70が起動するたびにポリシーリスト73は最新の状態に更新される。なお、クライアント70に監視・制御プログラム72を新規インストールした場合には、少なくともラベル「なし」のファイルに対するポリシーを格納したポリシーリストが同時にインストールされる。これにより、監視・制御プログラム72をインストールした直後にファイルにラベルを割り当てていない場合でも、ラベルに基づいた制御を実行することができる。また、クライアント70がネットワーク接続しない場合、またはポリシー設定サーバ10と通信できない場合、またはカードリーダ795でICカードとクライアントを通信して組織内にいることが確認できない場合には、ラベル「なし」のポリシーを全てのファイルに適用する。
図7にラベル割り当て処理の流れを示す。
ファイルへのラベル割り当て処理は、ファイルの利用者1がファイルの共有範囲を利用者以外に設定したい場合に実施する。なお、ファイルの作成者が利用者1でない場合でも、ファイルをクライアント70に格納した場合には、利用者1がラベルを割り当てるまではラベル「なし」のポリシーが適用される。
まず、クライアント70の利用者1がファイルを新規作成あるいはクライアント外からNW送信やインターネット40を通じて入手して保存したファイルについて、自発的にラベルを割り当てる場合、利用者が文書管理サーバ80のラベル割当プログラム81にアクセスし、ログインする。このとき、クライアントの監視・制御プログラム72は、クライアントのユーザIDを送信する。また、ラベルが未設定のファイルを操作しようとして制御された場合、監視・制御プログラム72が文書管理サーバにアクセスし、ユーザIDを送信する(7001)。
すると、文書管理サーバ80のラベル割当プログラム81はサーバ認証を行い(7002)、ポリシー設定サーバ10のポリシーリスト13を参照して(7003)、ユーザIDがアクセス主体の条件を満たすラベルを特定し(7004)、クライアントの画面上にラベル割当画面を表示させる(7005)。
利用者1は、表示されたラベル割当画面でファイルのラベルを割り当て(7006)、さらにラベルを割り当てるファイルを指定し(7007)、ラベル割当プログラム81に送信する(7008)。なお、ラベル割当画面の詳細については、図8で説明する。監視・制御プログラム72は、ラベル管理テーブル74を更新し、申請したファイルの状態を承認待ちとする(7009)。
ラベル割当プログラム81は、クライアント70から受信したユーザIDおよびラベル情報とポリシーリスト13を照合し、承認が必要かを判断し(7010)、承認が必要なラベルの場合は承認者に申請内容を送信する。なお、承認を必要としないラベルは設定してもよいし、しなくてもよい。このとき、ラベル割当プログラム81は、ラベル管理リスト84を参照し、ラベル管理リスト84に登録されたラベル割り当て済みファイルの一覧から、利用者が選択したラベルと同じラベルを割当てられているファイル、あるいは同じカテゴリを割り当てられているファイルなどを少なくとも1以上抽出して送信する(7011)。なお、抽出する条件として、利用者と同じ部署のユーザが所有するファイルのラベルとしてもよい。
承認者3は、申請されたファイルとラベルが適切であるか確認し、必要であればラベルの変更を要求する(7012)。このときの編集画面の詳細については、図8で説明する。
承認者3がラベルを確認あるいは変更要求を実行した後、ラベル割当プログラム81では、ラベルを割り当てたファイルが完成文書である場合には(7013)文書管理サーバ10にファイルを格納し(7014)、ラベル管理リスト84を更新する(7015)。なお、完成文書でない場合には、ファイルは格納せずにラベル管理リスト84を更新する(7015)。
次に、ラベル割当プログラム81は、申請内容に共有先の指定もあるかを確認し(7016)、共有先の指定が必要な場合にはポリシーリスト13を参照し、共有先を追加するようポリシー設定プログラム11に共有先情報を送信する(7017)。また、共有先情報の指定が必要でない場合には操作を行わない。
ラベル割当プログラム81が登録を完了し、登録完了通知を監視・制御プログラム72に送信すると(7018)、クライアント70の監視・制御プログラム72はラベル管理テーブル74を更新し、申請したファイルの状態を承認済みとする(7019)。これにより、ファイルにはラベルが割り当てられ、以降ファイルにはラベルに設定されたポリシーが適用される。
なお、ファイルに対するラベルの割り当ては、本実施例で説明したテーブルを用いてラベルを管理する方式だけではなく、ファイルのヘッダ領域やコンテンツにラベルを埋め込む方法や、DRM技術を用いてラベルとファイル本体をカプセル化してもよい。
図8にラベルの割り当て申請画面の一例を示す。
ファイルへのラベル割り当ては、図7で説明したように、ファイルを格納しているクライアント70の利用者1がまずラベルを割り当てし、割り当てたラベルが適切であるかを承認者3が確認して承認するとファイルにラベルが割り当てられ、ラベルに基づく制御を行う。
ラベル割当申請画面801は、ラベルを新規で割り当てるか、あるいは一度割り当てたラベルを変更するかを選択するボタン8011と、ラベル割り当てを申請する利用者のユーザID8012と、ラベルを割り当てるファイルパス8013と、ラベルを割り当てるファイルを参照して選択するボタン8014と、文書管理サーバに登録するかどうかを選択し、登録する場合には登録先のフォルダを指定する登録先フォルダ8015と、登録先フォルダ8015を文書管理サーバから参照して選択するボタン8016と、ラベルの選択方法を選択するための履歴利用タブ8017またはプルダウン選択タブ8018と、履歴利用タブを選択した場合の選択肢を表示したラベル選択表8019と、入力内容を申請する申請ボタン8020、からなる。なお、履歴利用タブ8017の選択肢として表示するラベルは、利用者1が操作を実行する条件を満たすラベルである。
利用者1は、例えば8010に示したように該当するラベルを選択することで、割り当てるラベルを選択することができる。
また、利用者1がプルダウンによるラベルの選択を希望し、プルダウン選択タブ8018を押下すると、ラベル割当申請画面802が表示される。
ラベル割当申請画面802では、基本的な構成はラベル割当申請画面801と同じであり、ラベル選択表8019の部分をプルダウンで選択するプルダウン選択表8021を表示する。プルダウン選択表8021は、カテゴリ8022を選択するプルダウンと、レベル8023を選択するプルダウンが表示されるため、利用者1は該当するカテゴリとレベルを選択し、選択が終わったら決定ボタン8014を押下することで、割り当てたラベルを申請することができる。
図9にラベル割り当ての承認画面の一例を示し、承認者3のラベル承認方法を説明する。
承認者3が文書管理サーバ80のラベル割当プログラム81にアクセスすると、ラベル承認画面901が表示される。ラベル承認画面901は、申請者のユーザID9011と、利用者1がラベルを割り当てたファイルパス9012と、文書管理サーバ80に登録する場合には登録先フォルダ9013と、利用者1が割り当てたラベル9014と、ファイルを表示する表示ボタン9015と、ラベルを変更する場合に選択するラベルの候補リスト9016と、類似するファイルのラベル一覧9018と、承認ボタン9019、からなる。
承認者3は、ラベル承認画面901を見てファイルとラベルが適しているかを判断する。もし、ファイルの中身を確認する場合は、表示ボタン9015を押下すると、文書管理サーバ10にアップロードされたファイルが開くため、承認者3はファイルの中身を見てラベルを承認することもできる。承認者3は、申請されたファイルについて、ラベルの変更が必要ないと判断した場合は、承認ボタン9019を押下し、ラベルの変更が必要と判断した場合は、別なラベルを選択し(9017)、承認ボタン9019を押下する。これにより、もし利用者1が適切でないラベルをファイルに割り当てていた場合でも、承認者3が変更することにより、適切なラベル割り当てがなされる。
なお、ラベル承認画面901には、類似するファイルのラベル一覧を表示しているため、承認者3は利用者1が設定したラベルが適切かどうかを判断するための目安とすることができる。
図10にラベル管理リスト23および状態管理リスト24のデータ構造の一例を示す。
ラベル管理リスト23は、ラベルが割り当てられたファイルに関するデータを格納している。ラベル管理リスト23は、少なくとも0個以上のエントリからなるデータであり、一意に情報の格納場所を識別可能なファイルパス1011、ファイルを格納する媒体識別ID1012、ファイルに割り当てたラベル1013、ラベルを最後に割り当てた最終ラベル割当者ID1014、ラベルの登録日時1015、ラベルの承認状態1016、その他状態1017、からなる。
その他状態1017で管理するデータは、例えば「ラベル承認中」「持ち出し申請中」「持ち出し中」などのファイルの状態を表示する。ラベル管理リスト23により、どのクライアントにどのラベルをもつ情報が格納されているか、また、ラベルが割り当てられている情報の承認状態などを迅速に把握することができる。また、クライアント70は同じ形式を持つラベル管理テーブル74を備えており、文書管理サーバ80は同じ形式を持つラベル管理リスト84を備えている。ラベル管理テーブル74およびラベル管理リスト84では、クライアント70あるいは文書管理サーバ80に格納しているファイルについて同じ形式で状態を管理している。
次に、状態管理リスト24について説明する。
状態管理リスト24はセンサ50を利用者が通過したログを元に、ID管理システム90のユーザリスト91に登録した利用者の所在を管理するものである。
状態管理リスト24は少なくとも0個以上のエントリからなるデータであり、ユーザID1031、利用者の現在地を示す所在1032、からなる。
例えば、ユーザID1031が001の利用者は執務室にいることを示す。これは、組織外から組織内の建屋、建屋から執務室に利用者が通過する際にICカードをセンサ50に近づけてIDを読み取らせることにより、入室したデータが状態管理リスト24に反映されていることを意味する。状態管理リスト24は、利用者1がICカードをセンサ50を近づけてIDを読み取らせるなど正当な方法で通過した場合に更新されるため、例えば状態管理リスト24で建屋内にいることをクライアント70のログイン条件にしておくことにより、なりすましや共連れにより入室してクライアント70を操作し、ファイルにアクセスしようとしても、状態管理リスト24に入室した記録がない場合には、ログインすらできないよう制御することができる。
なお、利用者の所在を確認する手段として、センサ50だけではなく、利用者が操作するクライアント70が接続するIPアドレスなどを取得することによって、社内のどこに利用者がいるかを判断してもよい。
図11に利用者の所在を特定する処理の流れを示す。
利用者1がセンサ50にICカード76あるいはID情報を格納した携帯電話79をかざしてセンサが設置してあるエリアに入退室すると(1101)、センサ50のセンサログ取得プログラム51で取得したセンサログをログ管理サーバ30のログ解析プログラム31に送信する(1102)。ログ解析プログラム31は、センサログを受信すると(1103)、ユーザリスト91を参照し(1104)、入退室した利用者のユーザIDを特定する(1105)。さらに、ログ解析プログラム31は、特定したユーザIDとセンサの識別情報を状態管理サーバ20の状態管理プログラム21に送信する(1106)。状態管理プログラム21は、ユーザIDとセンサの識別情報を受信すると(1107)、状態管理リスト24を参照し(1108)、受信したユーザIDの所在情報を更新する(1109)。
以上、図11で説明したように、組織内に設置されたセンサ50を利用者が通過した情報を状態管理サーバ20の状態管理リスト24で管理することにより、利用者の所在の変化を把握することができる。
図12でクライアント70、文書管理サーバ80、ノートPC78で動作する監視・制御プログラム72の動作フローについて説明する。
監視・制御プログラム72が起動すると(ステップ1201)、クライアント70における利用者の操作を監視する(ステップ1202)。利用者がファイルに対して操作を行うと(ステップ1203)、発生した操作の状態を識別する(ステップ1204)。このとき監視・制御プログラム72は、発生した操作と、Webアップロードなどネットワーク送信の操作である場合には宛先であるメールアドレスあるいはURLなどの社外共有先情報、クライアントのユーザID、ファイルパス、なども識別する。
次に、クライアント70に格納したラベル管理テーブル74を参照し(ステップ1205)、操作対象であるファイルのファイルパスをキーとしてファイルに割り当てたラベルを特定する(ステップ1206)。
ラベルが「なし」以外に設定されている場合には(ステップ1207)、状態管理サーバ20にアクセスして状態管理リスト24を参照し(ステップ1209)、ユーザIDをキーとして利用者の所在を特定する(ステップ1210)。
ステップ1207においてラベルが未設定の場合、またはステップ1209で状態管理サーバ20にアクセスできなかった場合は、ラベル未設定用のポリシーを参照する(ステップ1208)。なお、ステップ1209で状態管理リスト24にアクセスできない場合もラベル未設定として扱うのは、状態管理サーバ20とアクセスできない場合はクライアントがオフラインの場合と考えられ、オフラインの場合は利用者の所在が特定できないためである。また、クライアントがオフラインの場合は、ポリシー設定サーバ10に格納しているポリシーリスト13とクライアント70に格納しているポリシーテーブル73とが異なってしまう可能性があるため、適用すべき制御が異なってしまうことを防ぐためである。
次に、ステップ1208でラベルが「なし」のポリシーを参照した場合、ステップ1204で識別した状態がラベル「なし」のポリシーと一致するかを判定し(ステップ1214)、一致する場合には操作を実施し(ステップ1215)、一致しない場合には操作を防止する(ステップ1216)。ステップ1216で操作を防止した場合には、利用者にアラートを表示し(ステップ1217)、さらにラベル割当操作を行うか利用者に入力させる画面を表示し、ラベル割り当て操作を利用者が行うと入力を受け付けた場合には(ステップ1218)、ラベル割当画面を表示する(ステップ1219)。ラベルの割り当てを行わない場合、あるいはラベル割当画面を表示した(ステップ1219)後は、ログを取得する(ステップ1220)。
一方、ステップ1210において利用者の所在を特定した場合は、操作がNW送信あるいはクライアント以外の記憶媒体へのファイルのコピー、印刷などいずれかのクライアント以外の格納先への操作であるかを判定し、出力操作である場合には(1211)、資産リスト101を参照してファイル格納先の資産情報を取得し(ステップ1212)、ポリシーリスト73のラベルに設定しているポリシーを参照する(ステップ1213)。また、ステップ1211で操作が出力操作でない場には、ステップ1213を実行する。
ステップ1213でポリシーを参照し、ステップ1204で識別した状態がポリシーの条件と一致するかを判定した結果、一致する場合には(ステップ1221)、操作を実施する(ステップ1222)。さらに、例えばコピーや名前変更、あるいは削除などのように操作を実行することによりファイルパスが変更になる操作であれば(ステップ1223)、ラベル管理テーブル74を更新し(ステップ1224)、ログを取得する(ステップ1220)。ファイルパスが変更にならない場合はステップ1220を実行する。
ステップ1221でポリシーの条件を満たさなかった操作の場合は、操作を防止し(ステップ1225)、アラートを利用者に表示し(ステップ1226)、ログを取得する(ステップ1220)。なお、ステップ1220では、少なくとも操作の発生時刻と、ユーザIDと、操作の実行有無と、ファイルのラベルをログとして記録する。
ステップ1220の後、プログラム終了命令がされない限り(ステップ1227)、ステップ1202に戻って監視を行い、プログラム終了命令がなされた場合は、プログラムを終了する(ステップ1228)。
本実施例では、状態管理サーバ20で管理している状態管理リスト24を参照し、利用者の操作環境も取得して制御することにより、単なる人物からファイルへのアクセス権の制御だけではなく、ファイルを利用する利用者の環境によってもファイルの操作を制御することが可能となる。
なお、図12ではクライアント70における監視・制御プログラム72の説明をしたが、文書管理サーバ80の監視・制御プログラム82では、ラベル管理リスト84とポリシー設定サーバ10のポリシーリスト13を参照し、ノートPC78では、クライアント70からコピーしたラベル管理テーブル7813とポリシーリスト7814を参照する。
図13にファイルの持ち出し操作に係る処理の流れを示す。
利用者1が状態管理サーバ20の状態管理プログラム21にアクセスすると(1301)、申請画面が表示される(1302)。利用者1が表示された申請画面に従い申請情報を入力し(1303)、申請情報および持ち出すファイルを状態管理サーバ20に送信すると(1304)、状態管理プログラム21はラベル管理リスト23と持ち出すファイルのファイルパスとを照合してファイルのラベルを特定し、特定したラベルのポリシーを参照して持ち出し可能かを識別し(1305)、持ち出し操作の条件を満たしていない場合には条件を不適切のエラーメッセージを表示する(1306)。持ち出し操作の条件を満たしている場合には、申請情報を承認者3に送信する(1307)。承認者3は表示された承認画面で持ち出し申請情報を確認し、申請情報の持ち出し許可あるいは不許可を判断し(1308)、状態管理プログラム21に送信する(1309)。
状態管理プログラム21は承認結果を受け付け(1310)、不許可の場合は申請不許可のメッセージを通知し(1311)、許可の場合はラベル管理リスト23の状態を持ち出し承認済に更新し(1312)、少なくとも利用先の所在情報と格納媒体の識別IDを復号条件として含めた暗号鍵を生成し(1313)、ファイルを暗号化する(1314)。
状態管理プログラム21が利用者に持ち出し許可通知を送信すると(1315)、利用者1は状態管理サーバ20にアクセスし(1316)、暗号化したファイルをダウンロードし(1317)、持ち出すノートPC78にファイルを格納する(1318)。このとき、クライアント70の監視・制御プログラム71はファイルのダウンロードを検知し、ラベル管理テーブル74に承認結果を反映する(1323)。
利用者1は、その後組織内から組織外に出る場合、ICカード76あるいは利用者のID情報を格納した携帯電話79をセンサ50に近づけて近距離無線通信を行わせ、IDを読み取らせる(1319)。すると、センサ50のログ取得プログラム51でユーザ情報を取得し(1320)、状態管理プログラム21に取得した情報を送信する(1321)。状態管理プログラム21では、受信したユーザ情報を元にラベル管理リスト23の状態を持ち出し中に更新する(1322)。
この処理により、組織外に持ち出したファイルは暗号化して持ち出されるため、あらかじめ申請し承認された利用先以外の場所で利用者1がアクセスしても復号化されず、不適切な利用場所での操作を防止することができる。
なお、USBメモリなどのCPUを持たない可搬媒体に格納する情報のレベルが高い場合も、強制的にファイル暗号化を行う。暗号化の方法については、例えば「情報漏洩リスク提言のための内部統制と情報資産管理(著:甲斐他、日立評論 2007年9月号、pp.51、3.3節)」に開示しているように、持ち出すファイルを自己復号型で暗号化し、規定PCの識別情報(MACアドレスなど)を暗号ファイルに格納することにより、自宅PCや不審なPCでの閲覧・編集を防止することができる。
図14に組織外におけるファイル操作に係る処理の流れを示す。
利用者1は、携帯電話79に格納された認証プログラム791を用いて状態管理サーバ20の認証プログラム22にアクセスし、ログイン情報792を送信する(1401)。
状態管理サーバ20の認証プログラム22はログイン情報792が正規のものかどうかを判断し(1402)、認証に成功した場合は認証プログラム791に携帯電話79の所在情報送信を要求し(1403)、認証に失敗した場合はエラーメッセージを送信する(1408)。
認証プログラム22が利用者2の所在情報としてGPS情報を送信すると(1404)、状態管理プログラム21は状態管理リスト24を参照し(1405)、利用者の所在が承認済みの場所かどうかを照合する(1406)。
状態管理プログラム21は、所在が承認済みでない場合はエラーメッセージを送信し(1407)、承認済みであった場合は復号鍵リスト25を参照して現在の所在地で利用可能なファイルの復号鍵を特定し、送信する(1408)。
認証プログラム22は復号鍵を受信し(1409)、通信プログラム793を起動する(1410)。通信プログラム793はノートPC78の認証プログラム782にログイン情報を送信し(1411)、認証が成功した場合には(1412)、通信プログラム793に復号鍵を要求し(1413)、通信プログラム793からBluetoothなどを用いて復号鍵を送信する(1414)。ノートPC78の通信プログラム783では、復号鍵を受信すると、ノートPC78に格納し(1415)、利用者1がファイルにアクセスした場合には(1416)、承認されたファイルのみ、復号鍵により復号化し(1417)、閲覧などの操作を実行できるようになる。
なお、ノートPC78の通信プログラム783は、携帯電話79の認証プログラム791と一定時間ごとに通信し、通信できなくなった場合はノートPC78の監視・制御プログラム791が操作を防止する。これにより、ノートPC78を開いたまま承認済みの場所から移動した場合に操作を継続させないことができる。
図15にファイル持ち出し後の組織内での処理の流れを示す。
利用者1がノートPC78を組織外から組織内に持ち帰り(1501)、センサ50に例えばICカード76を近づけIDを読み取らせると(1502)、センサ50のセンサログ取得プログラム51は、ICカード76に格納されたユーザ情報を取得し(1503)、状態管理サーバ20の状態管理プログラム21にデータを送信する(1504)。
状態管理プログラム21はラベル管理リスト23を参照し(1505)、持ち出し中のファイルのうち、持ち出し期限の切れたファイルがあるか特定し(1506)、持ち出し期限の切れたファイルがある場合には利用者1のクライアント70にファイル削除のメッセージを表示させる(1507)。利用者1がノートPC78から持ち出し期限の切れたファイルを削除すると(1508)、クライアント70の監視・制御プログラム72は、削除したファイルを格納した記憶媒体の識別IDを状態管理プログラム21に送信し(1509)、状態管理プログラム21は、ラベル管理リスト23の状態欄に設定した「持ち出し中」データを削除する(1510)。これにより、ノートPC78に格納したファイルを残留させたままにすることを防止することができるため、持ち出しの都度、持ち出しに関係のあるファイルのみを持ち出すことができる。
図16に持ち出し操作に係る申請および承認画面の一例を示す。
持ち出し申請画面の一例を160に示す。持ち出し申請画面160は、ファイルを組織外に持ち出す利用者1が入力を行う画面であり、図13におけるステップ1303で表示する。
持ち出し申請画面160には、少なくとも申請者情報1601と、持ち出すファイル名1602と、持ち出すファイルをクライアント70から参照して選択するボタン1603と、ファイルを格納する媒体の識別ID1604と、格納する媒体を参照して選択するボタン1605と、利用先1606と、利用先の所在の位置情報を選択するボタン1607と、持ち出し期限1608と、持ち出し目的1609と、申請ボタン161と、申請中止ボタン162と、を表示する。
利用者1が持ち出し申請画面160に入力し、申請ボタン161を押下すると、承認者3に持ち出し操作の承認申請と、持ち出すファイル名を選択するボタン1603で選択したファイルが送信される。
次に、持ち出し承認画面の一例を163に示す。持ち出し承認画面163は、利用者1の申請を承認する承認者3が承認を行う画面であり、図13におけるステップ1308で表示する。
持ち出し承認画面163には、少なくとも持ち出し申請画面160で利用者1が入力した情報として、申請者情報1601と、持ち出すファイル名1602と、ファイルを格納する媒体の識別ID1604と、持ち出し期限1608と、持ち出し目的1609、に加えて、持ち出すファイルを表示するボタン1611と、持ち出すファイルのラベル情報1612と、利用先情報の位置情報設定状況1613と、承認を許可するボタン164と、承認を差し戻しするボタン165と、を表示する。なお、持ち出すファイルのラベル情報1612は、持ち出し承認プログラム83が、利用者1が入力したファイル名1602を受け付けた後、ラベル管理リスト84を参照してラベルを特定し、表示する。
以上述べた第1実施例により、情報の活用を阻害することなく、情報漏洩につながる操作を未然に防止することが可能になる。
−−−実施例2−−−
第2実施例では、ファイルのラベル情報をファイルに埋め込む方法を示す。
図17に第2実施例におけるラベル割り当て処理の流れを示す。第2実施例におけるラベル割当処理の大まかな流れは、図7に示した第1実施例におけるラベル割当処理と同じだが、第2実施例ではファイルの拡張領域を利用し、拡張領域に少なくともラベル名と、ラベル設定あるいは承認者情報と、を埋め込む。具体的には、ステップ7014で完成文書の識別を行う前に、ラベル埋め込み処理を行う(1701)。
図18に第2実施例における監視・制御プログラムの動作フローチャートを示す。第2実施例における監視・制御プログラムの動作フローチャートの大まかな流れは、図12に示した監視・制御プログラムの動作フローチャートと同じだが、第2実施例では、ラベル管理テーブル74の参照によるラベル情報の特定処理ではなく、ラベル読み込み処理を行う。また、ラベルをファイルの拡張領域に埋め込むため、ファイルパス変更操作を実行しない。そのため、ステップ1204で状態識別した後は、ラベル読み込み処理を行い(1801)、ラベルの設定状況を確認する(1207)。また、ステップ1222でラベルが設定されているファイルについて操作を実施した後は、ログ取得処理を行う(1220)。
以上述べた第2実施例により、第1実施例と同じシステム構成で情報の活用を阻害することなく、情報漏洩につながる操作を未然に防止することが可能になる。
−−−実施例3−−−
・システム構成について:
第3実施例では、組織外にファイルを持出す場合の承認処理における情報の識別方法を示す。図19に第3実施例のシステム構成図を示す。第3実施例におけるシステム構成では、送受信したメールのログを取得したメールログ1921を備えるメールサーバ192と、承認管理サーバ193を新たに設ける。また、クライアント70は申請管理プログラム1911を備え、ノートPC78は申請管理プログラム7801を備える。
前記申請管理プログラム1911と申請管理プログラム7801は、同じ動作を行うものとし、この申請管理プログラムを対象機器にインストールすることにより、承認済みの属性を持つファイルを記憶手段中より特定し、既存のファイル検索プログラム等における表示用インターフェイスにおいて前記承認済みファイルを前記ファイル検索プログラムの既存機能等により強調表示(例:該当ファイルの表示をハイライト化、太字化するなど)することができる。なお、本実施例における承認フローについては図27および図28を用いて後に詳述する。
また、前記申請管理プログラム1911は、コンテキストメニューに「持出し申請」を有している。例えば、利用者1がクライアント70あるいはノートPC78を介してファイルを選択し、前記申請管理プログラム1911が提供するコンテキストメニューから「持出し申請」を選択したとする。この場合、前記申請管理プログラム1911は、前記承認管理サーバ193の承認管理プログラム(承認管理手段)1931と通信して接続し、持出し申請画面を立ち上げるための認証画面を表示する。なお、第1実施例ではファイル持ち出しの承認処理を状態管理サーバで実施しているが、本実施例3におけるシステム構成に示すように、承認管理機能を備えた情報処理装置=承認管理サーバ193を新たに設け、ラベル割当て処理について役割分担してもよい。
前記承認管理サーバ193は、ファイルの持出しを申請する利用者1および持出しの承認判断をする承認者3のクライアント70やノートPC78などに表示する画面の生成や申請案件のステータスやファイルの管理を行う承認管理プログラム1931(承認管理手段)と、申請されたファイルの識別処理を行うファイル識別プログラム1932(ファイル識別手段)と、組織外の取引先情報を登録した取引先リスト1941およびファイル識別に用いる照合用DB1943(オブジェクト登録データベース)とを管理するDB管理プログラム1934(DB管理手段)と、持出しが承認されたファイルを持出し用のファイル形式に変換するファイル変換プログラム1935と、承認ステータスを格納する承認管理DB1942、ファイルの組織外持ち出しに係る組織のルールを登録した持ち出しルールDB1944、を備える。
なお、既に図2にて示したとおり、前記クライアント70のハードウェア構成は、端末ログ75ならびにポリシーリスト73、ラベル管理テーブル74を保存する外部記憶媒体702(記憶手段)、申請管理プログラム1911および監視・制御プログラム72を実行するCPU701、メモリ703、入出力画面を表示する表示部704(出力手段)、入出力を制御する操作部705(入力手段)、可搬媒体77に格納されたデータなどを読み書きするための可搬媒体接続部706、RAM707、有線あるいは無線でネットワーク40と通信を行う通信部708、これらの各装置等を相互接続するバス709から構成される。また、前記ノートPC78や、本実施例3で新たに登場した承認管理サーバ193も、上記クライアント70と同様のハードウェア構成をとる。
各装置では、CPUが外部記憶媒体に格納されたプログラムを実行することにより、以下に説明する処理、機能が実現される。ただし、各実施形態の説明では、便宜上、各プログラムを実行主体としている。また、各プログラムは、あらかじめ、上記各装置の外部記憶媒体やメモリに格納されていても良いし、必要なときに、可搬媒体接続部や通信部と、各装置が利用可能な媒体と、を介して、他の装置から導入されてもよい。媒体とは、たとえば、着脱可能な可搬媒体、または通信媒体(すなわちネットワーク40またはネットワーク40を伝搬する搬送波やディジタル信号)を指す。
こうした本実施例3における前記承認管理サーバ193は、ラベルの申請受付時ないしファイルの持出し申請受付時において、該当ファイルの構造ないし該当ファイルにおけるオブジェクトの配置を特定し、前記申請ファイルについて特定した事項に関して一致ないし類似する他ファイルを、前記照合用DB1943(オブジェクト登録データベース)の属性情報に基づき特定し、前記ファイルと他ファイルとの差分を取得して、前記取得した差分において前記照合用DB1943(オブジェクト登録データベース)に登録された利用制限のあるオブジェクトの有無を検出し、前記他ファイルの承認結果を前記承認管理DB1942で特定し、前記利用制限のあるオブジェクト有無の情報と前記他ファイルの承認結果の情報とを、承認判断を行う承認者における要確認項目として前記クライアント70やノートPC78などの他端末ないし表示部(出力手段)に出力する、プログラム1932(ファイル識別手段)を備える。
なお、前記ファイル識別プログラム1932は、申請を受け付けたファイルとファイル持ち出し先が同じである過去の申請ファイルか、持ち出し却下ないし許可と判定された過去の申請ファイルを前記承認管理DB1942で検索し、この検索で得た過去の申請ファイル中より、前記他ファイルの特定を実行するとしてもよい。
また、前記ファイル識別プログラム1932は、前記特定した他ファイルの承認結果が持ち出し却下であった場合、その却下理由を前記承認管理DB1942より抽出し、前記要確認項目の情報に含めて前記クライアント70やノートPC78ないし表示部に出力するとしてもよい。
また、前記承認管理サーバ193は、前記記憶手段において、ファイル持出し時におけるファイル形式や持出し方法などの組み合わせにおいて持ち出し許可あるいは不許可のルールを格納する持出しルールDB1944を記憶しているとすれば好適である。この場合、前記ファイル識別プログラム1932は、前記申請ファイルにて指定されているファイル持ち出し方法の情報を、前記持出しルールDB1944に照合し、該当申請ファイルが指定するファイル持ち出し方法が許可された方法であるか判定し、当該判定結果を前記要確認項目の情報に含めて前記クライアント70やノートPC78ないし表示部に出力する。
また前記前記承認管理サーバ193は、前記利用制限のあるオブジェクト有無の情報と前記他ファイルの承認結果の情報とを含む前記要確認項目のデータに基づいて、前記利用制限のあるオブジェクトが含まれる数の順で前記申請ファイル中のページの順位付けをし、前記各ページについて生成したプレビュー画面データを前記順位付けに従って配置した画面データを作成してクライアント70やノートPC78など他端末ないし表示部に出力する、承認管理プログラム1931(承認管理手段)を備える。
なお、前記承認管理プログラム1931は、前記プレビュー画面において、該当ページに含まれている前記利用制限のあるオブジェクトについて強調表示設定を行ってクライアント70やノートPC78や表示部に出力する。
また、前記承認管理サーバ193は、前記ラベルの申請ないしファイルの持出し申請に対する承認結果を他端末(クライアント70やノートPC78など)ないし操作部(入力手段)から得て、前記照合用データベース1943(オブジェクト登録データベース)における該当オブジェクトに関する取り扱い情報を更新するDB管理プログラム(DB管理手段)を備える。なお、前記DB管理手段は、承認結果を受信したときに前記オブジェクト登録データベースを更新するとすれば好適である。
また、前記ファイル識別プログラム1932は、前記申請を受け付けたファイルについて、ページ構成と該当ページにおけるテキストの位置とオブジェクトの位置とを特定し、ここで前記ファイルについて特定した事項に関して類似する他ファイルを、前記照合用DB1943(オブジェクト登録データベース)の属性情報に基づき特定し、前記ファイルと他ファイルとの差分を取得して、前記取得した差分において前記照合用DB1943(オブジェクト登録データベース)に登録されたオブジェクトの有無を検出し表示部(出力手段)ないし他端末(クライアント70やノートPC78など)に出力するとしてもよい。
・データベース構造等について:
図20に取引先リスト1941のデータ構造を示す。取引先リスト1941は、ファイル管理システム1000を導入した組織と業務上取引がある当該組織以外の取引先相手の情報を登録したリストであり、前記DB管理プログラム1934がメールサーバ192に格納されたメールログ1921などから作成する。この取引先リスト1941は、登録番号2001、メールアドレス2002、取引先名2003、最後にメールを受信した日時である最終受信日時2004、持ち出し申請が承認された回数を示す承認回数2005、取引先相手に認識されているユーザIDから成る。本取引先リストを参照することにより、ファイルの持出しが申請されている持出先がこれまで組織として付き合いのある相手か、あるいは新たに付き合いを始める相手かを判断することができる。
なお、上記取引先リスト1941は以下の手順で作成される。前記承認管理プログラム1931が定期的にメールサーバ192に格納しているメールログ1921にアクセスする。そして前記承認管理プログラム1931は、組織のユーザの受信ログを解析し、送信元情報が組織外の相手のメールアドレスを特定する。
次に、前記承認管理プログラム1931は、前記特定した組織外の相手からのメールアドレスに対応する受信元メールアドレスから、組織内のユーザのメールアドレスを特定し、たとえばID管理システム90のユーザリスト91に登録されたメールアドレスと照合してユーザIDを特定する。
そして、前記取引先リストに取引先が登録されている場合、前記承認管理プログラム1931は、前記取引先リスト1941の該当レコードにて最終受信日時を更新する(前記特定したユーザIDが該当取引先に関し未登録のユーザIDであった場合、ユーザID2006の欄も更新する)。一方、前記取引先リスト1941に取引先が登録されていない場合、前記承認管理プログラム1931は新規レコードを追加し、取得した情報(取引先の社名やメールアドレス等)を登録する。
図21に前記承認管理DB1942のデータ構造を示す。承認管理DB1942は、ユーザIDごとに作成した承認案件に関するメタデータと、申請されたファイルのコンテンツに関するメタデータからなる。承認案件に関するメタデータは、ユーザID2100、承認案件ごとに作成する承認案件テーブル2101、ユーザがメールを受信した相手を日時の新しい順に格納したメール受信テーブル2102、とからなる。
なお、承認案件テーブル2101は、承認操作完了時に承認管理プログラム1931が更新し、メール受信テーブル2102は、図24で述べる取引先リスト1941の更新時にDB管理プログラム1934が更新する。前記承認案件テーブル2101は、申請されると割り振られる申請ID2111、取引先の登録番号2112、持出し方法2113、ファイル形式2114、持出し理由2115、承認者コメント2116、承認に係るステータス2117、承認日時2118、申請されたファイルのID2119、とからなる。
メール受信テーブル2102は、ユーザ2100の受信したメールのうち、組織外の相手が送信者であるメールの上位件数を登録したものであり、メールアドレス2121、受信日時2122、からなる。本件数は管理者がカスタマイズすることもできる。
また、申請されたファイルのコンテンツに関するメタデータ2103は、申請されたファイルのID2123およびファイルそのもの2124と、ファイル識別プログラム1932で分析した分析データに照合用DB1943で検出したオブジェクトを付与したデータ2125と、ファイル比較用のデータ2126を格納する。ファイル比較用のデータとしては、ファイル間の類似度を比較可能なものとしてハッシュ値などを格納する。
また、図24に照合用DB1943(オブジェクト登録DB)のデータ構造を示す。前記照合用DB1943は、汎用DB2104と相手先別DB2105からなる。汎用DB2104は、持出し申請やラベル登録などに関する処理に統一的に利用可能なDB(=ファイルおよびラベルを問わないオブジェクトを登録したデータベース)であり、例えば「社外秘」など無条件で持ち出しが禁止される取り扱い情報(或いはその逆に、インターネット上の公開情報など無条件に持ち出しOKの取り扱い情報)が対応付けされた、人名、組織名などの単語、テンプレートなどを示すデータ、図やロゴなど、ファイルに含まれるオブジェクトを登録したものである。また、相手先別DB2105は持出先ごとに生成し、持出し申請に関する処理に用いるDB(=ファイルを持出した履歴のある相手先ごとにオブジェクトを登録したデータベース)であり、前記汎用DB2104と同じ形式でオブジェクト情報が登録される。前記照合用DB1943は、更に、ラベルごとにファイルのオブジェクトを登録したラベル別データベース2106を備えるとしてもよい。これら各DBには、利用禁止オブジェクト2127と、利用可能オブジェクト2128がそれぞれ登録されており、承認案件について検出された件数2129と共に登録されている。
前記照合用DB1943において、前記人名、組織名などの単語、テンプレートなどを示すデータ、図やロゴなどに関するデータが、オブジェクトの属性情報となる。また、これらオブジェクトの属性に対応付けされる「持ち出し禁止」、「持ち出しOK」などの情報が取り扱い情報となる。
また、図25に持ち出しルールDB1944のデータ構造を示す。前記持ち出しルールDB1944は、ファイル持出し時におけるファイル形式や持出し方法などの組み合わせにおいて許可あるいは不許可のルールが記載されているデータベースである。これは管理者や承認者が事前にDB管理プログラム1934を通じて更新するものであり、組織全体や部署などの小規模な単位での設定も可能である。例えば、(1)取引先リスト1941に登録されていない持出し先への持ち出しについてはファイルの詳細確認が必要、(2)ファイル形式がDRM以外の場合は理由の記載が必須、といったルール2129が定義される。
・画面表示例について:
図24に利用者1がファイルを組織外に持出し申請をする際の申請画面220の例を示す。本申請画面は、申請者である利用者1が承認管理サーバ193にクライアント70やノートPC78などでアクセスすると、承認管理サーバ193の承認管理プログラム1931が前記クライアント70やノートPC78などに返信して表示させるものである。なお、前記クライアント70の申請管理プログラム1911が、そのコンテキストメニューにて利用者1から指示を受けて承認管理サーバ193に接続した場合、当該申請管理プログラム1911は選択されているファイルのファイルパスを承認管理サーバ193に送信する。また、前記承認管理プログラム1931では、利用者1にユーザ認証を行わせ、認証が成立した場合には前記ユーザ認証時における認証情報からユーザIDを特定し、前記申請画面220に表示させる。
前記申請画面220では利用者による以下の情報の入力を(クライアント70やノートPC78などを介し)受け付ける。申請者名2211、持出し日2212、持出すファイル名2213、持出し先のメールアドレス2214、持出し理由2215、持出し方法2216、持出し時のファイル形式2217、さらにたとえばファイル形式が事前に定義した持ち出し方法以外(本実施例では、DRM(Digital Rights Management)形式を例示)の場合には、持出し理由を入力させることもできる。このとき、持出すファイル2213について、利用者1は、先ほど述べたようにクライアント70の申請管理プログラム1911を利用して入力する以外に、参照ボタン2220を押下し、ダイアログからファイルを指定することによって入力させてもよい。なお、一度に複数のファイルを持出す場合、前記利用者1は「追加」ボタン2221を押下することで、ファイルを追加登録することができる。
また、持出し先2214については、利用者が「履歴から入力」ボタン2223を押下した際に、承認管理サーバ193が、持出し先候補リスト221をクライアント70やノートPC78などに出力し、このリスト中から選択させるとしてもよい。一方、前記持出し先候補リスト221に登録されていない、すなわち新規の持出し先の場合はメールアドレスの入力を受け付けるとしてもよい。なお、前記持出し先候補リスト221は、例えば前記承認管理サーバ193が、前記取引先リスト1941の格納情報からデータ(メールアドレス2002、取引先名2003など)を抽出し、メールアドレス222と取引先名223からなるデータベースを構成したものとなる。
またこの持ち出し先候補リスト221は、これまでの持出し履歴のある取引先2241、持出し申請頻度の高い取引先順2242、メール受信順2243、そして登録された名前順2244、などの条件で前記取引先リスト1941から抽出したデータがリスト化されており、前記承認管理サーバ193は、該当タブの押下を受けて持ち出し先候補の表示切り替えを行うとすればより好適である。なお、利用者1が前記持出し先候補リスト221から持ち出し先の選択を行って持出し先入力を実行した場合、承認管理サーバ193は、入力フォーム2214の横に、取引先リスト1941にて既登録の取引先名(図中では“A社AAA”)も表示させる。これにより、メールアドレスが類似した取引先を間違えて入力していないかを確認することができる。
また、前記申請画面220において、持出し方法2216については、例えばDRM、暗号化、平文などを選択可能としている。一方、例えば、組織に応じて前記持出し方法2216のデフォルト値(例えば“DRM”)を予め指定しておくこともできる(例:承認管理サーバ193がクライアント70やノートPC78などの指定を受けて当該申請画面220のデータにデフォルト値を設定しておく)。また、承認管理サーバ193は、デフォルト設定されている持出し方法から他の方法に変更する指定を受けた場合、例えば、理由2218の記入がなされないと申請ボタン2231が押下されても処理を遷移させないといった判定を実行し、利用者に理由2218を記入させるとしてもよい。上記申請に係る全ての項目を入力し、利用者が申請ボタン2231を押下することで、当該申請画面220での入力データはクライアント70やノートPC78などから承認管理サーバ193に送信され、申請処理は終了する。承認管理サーバ193では前記申請画面220での入力データを承認管理DB1942に格納することとなる。
図25に承認者3が承認判断をする際の承認画面を示す。承認判断を行うための承認画面は、申請されている情報一覧を示す承認待ち一覧画面230および案件1件ずつの詳細画面233からなり、承認者のクライアント70やノートPC78などからの指示や前記申請画面220での申請ボタンの押下に応じ、承認管理サーバ193が生成してクライアント70やノートPC78などに出力する。承認者3は、まず承認待ち一覧画面230で対象となるファイルの承認判断を実施し、詳細な確認が必要なファイルについては、詳細画面233を見て承認判断を行う。以下、画面の詳細について述べる。
前記承認待ち一覧画面230は、チェックボックス2410と、申請者名2411、持出し日2412、持出し先2413、要確認項目2414、プレビュー2415、承認判断ボタン2416、を表示する画面であり、承認管理サーバ193が記憶手段において予め該当画面のひな形データを有している。前記承認画面230に示す項目のうち、持出先2413については、利用者が入力した持出先に対し、承認管理サーバ193が取引先リスト1941を照合し、この取引先リスト1941に登録済みの持出し先かどうかを特定し、登録済みの場合は登録した顧客名を表示し、登録されていない場合は「未登録」と表示する。また、申請者名2411や持ち出し日2412のデータは、前記承認管理サーバ193が前記申請画面220を通じて受け付けたデータを設定している。
承認者はメールアドレスだけでは持ち出し先について把握することができないため、承認管理サーバ193は、前記取引先リスト1941において該当メールアドレスに対応する相手先情報の登録有無と登録名を、前記承認待ち一覧230の持ち出し先2413の情報として示す。これにより承認者は、取引先の誤入力や不正な取引先の入力を容易に判断することができる。
また、前記承認待ち一覧画面230における要確認項目2414では、申請情報を承認判断するにあたり持出しリスクの高い可能性がある項目を示す(後述する図29のフローにて承認管理サーバ193が実行する処理で特定される)。例えば、図中の案件2431では個人情報が検出されており、個人情報を持出そうとしている可能性が高いことを示している。
さらに、前記承認管理サーバ193は、前記プレビュー2415において、申請されたファイルの表紙2417と、ファイルの中で最も確認すべき情報が記載されたページ2418、とを表示する(後述する図28のフローにて承認管理サーバ193が実行する処理で特定される)。ファイルの表紙をプレビュー表示させるのは、表紙にはあて先や作成者名、タイトルなどファイルの要約情報を表す情報が記載されていることが多いためである。 また、もっとも確認すべき情報が記載されたページ2418のプレビューを表示することにより、承認者が情報の中身を迅速に把握することができる。さらにプレビューを示すことで、承認者がファイルを開かなくても情報を識別することができるという利点もある。たとえばファイルが添付されただけの承認画面の場合、承認者はファイルを開き、記載されているすべてのページを見ないと何に関する情報かすら把握できず、効率的かつ正確に内容を把握することは困難である。これに対し、本プレビュー2415のように、表紙と最も確認すべきページを優先的に表示することによって、承認者におけるファイルを開く手間が削減される。更に、前記承認者が前記画面230における詳細ボタン2432を押下すると、承認管理サーバ193は前記詳細ボタン2432の押下に対応する申請案件に関して記憶手段から情報を抽出し、詳細画面233のデータを生成し返信する。この詳細画面233によれば、例えば前記承認待ち一覧画面230では承認判断しきれなかったファイルの詳細について承認者が確認を行うことができる。
なお、承認者が前記画面230にてチェックボックス2431をチェックし、「チェックした申請をすべて承認」232ボタンを押下することにより、承認管理サーバ193は、詳細画面233の表示を行わずに承認判断の結果を受け付けることができる。なお、「チェックした申請をすべて承認」232ボタンは、「チェックした申請をすべて却下」するボタンとしてもよい。ただし、要確認項目2414に記載される数が所定数より多い申請案件については、前記チェックボックス2431にチェックが入っても、前記詳細画面233の出力を実行しないかぎり承認できないよう、承認管理サーバ193が制御するとしてもよい。
また、前記詳細画面233の構成について述べる。詳細画面233は、前記承認待ち一覧230の情報では承認者が承認判断をしきれない場合に申請内容の詳細を把握させることを目的としたものである。この詳細画面233は承認管理サーバ193がクライアント70やノートPC78などに出力するものであり、申請日2451、申請者名2452、ファイル2453、持出し日2454、持出先2455、持出し理由2456、持出し方法2457、要確認項目2458、さらにファイルのプレビュー2461、不適切表現指定ボタン2463、却下理由2464、差し戻し・却下理由などのコメント記述欄2465の各データを含む画面データである。
前記要確認項目2458には、リスクの高いオブジェクトの種類だけではなく、過去承認/却下されたファイルのうち最も類似しているファイルが表示される(後述する図28のフローにて承認管理サーバ193が実行する処理で特定し設定する)。また、最も類似したファイルが却下されたファイルであった場合、その却下案件の却下理由(例:承認管理DB1942が却下理由の欄を備え、却下案件についてその却下理由のデータを保持している。承認管理サーバ193はこの承認管理DB1942から却下理由のデータを抽出して前記詳細画面233に設定)まで示すことにより、承認者が承認判断をする参考とすることができる。例えば、図に示した例では、該当申請案件が、過去に却下したファイルに最も類似しており、その却下理由は「個人情報のため」としている。承認者は、類似した案件のファイル持ち出し先と本申請のファイル持ち出し先、また類似した案件との差分を確認することによって、両者に大きな違いがないのであれば類似案件同様却下、ファイル持ち出し先や表現の違いにより承認、などの判断を行うことができる。
また、前記承認管理サーバ193は、前記プレビュー2461にて、前記承認待ち一覧画面230で表示したプレビュー画面を該当ファイルにおけるページごとに表示する。さらに、個人情報や企業名などファイルに含まれる情報漏えいリスクの高いオブジェクトをハイライト2462で表示する。これにより、承認者はプレビュー画面2461のどこを注意して確認すればよいかがわかる。なお、承認者が「確認必要順」ボタン2459を押下すると、承認管理サーバ193は、確認する優先度の高い順(例:上方漏洩リスクの高いオブジェクトが含まれる数が多い順など)にプレビュー画面の並び替えを行う。また、前記承認者が「ページ順」ボタン2460を押下すると、承認管理サーバ193は、前記プレビュー画面をページ順に表示する。また、承認者が「ファイルを開く」ボタン2466を押下することにより、前記承認管理サーバ193は、申請案件のファイルを記憶手段から読み出してクライアント70やノートPC78などに出力し、承認者におけるファイル内容の確認に供する。
一方、前記承認者は、承認/却下/差戻のいずれかの判断を選択し、「承認」2471、「却下」2472、「差戻」2473、のいずれかのボタンを押下することによって承認判断を終了する。なお、前記承認判断が「却下」あるいは「差し戻し」の場合、前記承認管理サーバ193は、クライアント70やノートPC78などを介した承認者による理由入力を、コメント2465の欄にて受け付ける。こうした理由入力を受け付けた承認管理サーバ193は、前記理由のデータを利用者のクライアント70やノートPC78などに送信することで、承認者が「差し戻し」や「却下」の判断を行った理由を利用者に通知することができる。
また、承認者が不適切表現指定ボタン2463を押下して(例えば、範囲指定用のカーソルなどを承認管理サーバ193がクライアント70やノートPC78などに出力する)、プレビュー画面2461上のオブジェクトの範囲を指定した場合、承認管理サーバ193はこの範囲指定を受け付けて、前記承認者が不適切な表現と感じたオブジェクトの情報を取得することができる。承認管理サーバ193は、前記範囲指定の情報を利用者のクライアント70やノートPC78などに送信することで、前記承認者が漏洩リスクが高いと判断した表現がどの部分であったか利用者に教えることができる。
さらに、却下理由2464では、却下理由として表現に不適切なものがあったのか、あるいは漏洩リスク上、内容上に不適切なものがあったのかを承認者に選択させることができる。例えば、申請された内容が組織内だけで共有すべき機密情報であった場合、承認者は「内容上不適切」にチェックをする。承認管理サーバ193は前記承認者のクライアント70やノートPC78などから前記却下理由2464でのチェック内容を受け付けて、表現の有無に関わらず内容上漏洩リスクが高いと判断し、申請を却下したことを利用者に通知する(としてもよい)。なお、前記承認者が実施するコメントの記入や指摘は「承認結果」であり、前記照合用DB1943の更新に用いられる(次回以降の申請時に反映される)。
なお、以上述べた各画面の表示項目については、承認者自身で表示する項目をカスタマイズすることも可能である。また、前記承認待ち一覧画面230は承認者が携帯電話を用いて承認操作を行なってもよい。また、ファイルを詳細に確認する必要がある場合には、事前に登録しておいた代理人に承認を依頼することもできる。
・処理フローの例:
まず図26にて、利用者によるファイルの持出し申請の流れについて説明する。利用者の持出し申請の受付処理に係るインタフェースは承認管理サーバ193の前記承認管理プログラム1931が、利用者のクライアント70やノートPC78などに提示する(以下、クライアント70)。
まず、ファイルを組織外に持ち出す利用者がクライアント70により承認管理サーバ193にアクセスし、ログイン処理を指示したとする。すると前記クライアント70はこの指示を受けて前記承認管理サーバ193に対するログイン処理を実行する(2501)。
一方、前記承認管理サーバ193の承認管理プログラム1931は、図24で例示した申請画面220のデータをクライアント70に返信する(2502)。なお、図24で述べたように、利用者がクライアント70の申請管理プログラム1911を利用し、クライアント70がコンテキストメニューから承認管理プログラム1931にアクセスした場合、前記承認管理プログラム1931が利用者のIDと選択されているファイルパスを入力した状態の申請画面のデータを返す。
次に、利用者が前記申請画面220の入力項目のうち「履歴から入力」ボタン2223を押下したとする。前記クライアント70はこの押下事象を受け付けて(2503:Y)、前記承認管理サーバ193に通知を行う。この時、の承認管理プログラム1931は、ログインしているユーザ=前記利用者のユーザIDをキーとし、前記取引先リスト1941および前記承認管理DB1942のメール受信テーブル2102を参照し、持出先候補リストを生成する(2504)。そしてこの持出先候補リストのデータを含む持出先候補画面(図24参照)のデータを生成してクライアント70に送る(2505)。
前記利用者が前記申請画面220の入力項目を全て入力し、申請ボタン2231を押下すると(2506)、クライアント70は前記申請画面220での入力データを承認管理サーバ193に送信する(2507)。他方、前記承認管理サーバ193の承認管理プログラム1931は前記入力データを受信する。そして、前記入力データを前記持出しルールDB1944に照合し、申請内容に不備(例:「社外秘」など無条件で持ち出しが禁止される内容が最初から含まれている等)がないか特定する(2508)。
また、前記承認管理プログラム1931は、前記ステップ2508に続き、前記利用者の申請内容の確認画面を前記クライアント70に送信する(2509)。なお、前記ステップ2508で申請に不備があることが特定された場合、前記承認管理プログラム1931は、前記ステップ2509で送信する確認画面において不備がある項目を例えば強調表示する。この場合、前記クライアント70は前記確認画面のデータを承認管理サーバ193から受信して表示し、該当箇所に関する修正を利用者から受け付ける(2510:Y、2511)。この場合、フローは前記ステップ2506に戻る。一方、前記ステップ2508で申請に不備が無いと判定された場合(2510:N)、前記クライアント70は利用者から申請ボタンの押下を受け付ける(2512)。
これにより、申請内容および申請するファイルがクライアント70から承認管理サーバ193に対し送信される(2513)。前記承認管理サーバ193の承認管理プログラム1931は、前記クライアント70から送信されてくるデータを受信して承認管理DB1942に格納し、該当ファイルに関する組織外持ち出し申請を受け付けることになる(2514)。
続いて図27に基づき、ファイルの持出し申請に対する承認処理の流れについて説明する。この場合、図26のフローに関し述べたように、前記クライアント70は、利用者による申請画面220での申請ボタン押下を受け付けて(2701)申請内容および申請するファイルを承認管理サーバ193に送信する(2702)。前記承認管理サーバ193の承認管理プログラム1931はこれを受信する。
次に、前記承認管理プログラム1931は、申請された持出先について取引先リスト1941を参照し、相手先登録情報を取得する(2703)。そして、相手先用の照合用DB1943の有無を特定する(2704)。なお、新規申請の場合には相手先別の照合用DB1943は存在しないため、前記汎用DB2104のみを用いてファイルの識別を行うこととする。
次に、前記承認管理プログラム1931は、前記申請内容(と前記承認管理DB1942の“ステータス”)から保留案件(図26の前記ステップ2510で“不備あり”となって再申請に回された案件)かを特定し(2705)、該当件が保留案件の場合(2705:Y)、保留された前回のファイルをファイル識別プログラム1932に送信する(2706)。そして、申請されたファイルもファイル識別プログラム1932に送信する(2707)。
一方、前記ファイル識別プログラム1932においてファイル識別処理が行われると(2708)、その識別結果が承認管理プログラム1931に送信される(2709)。なお、ファイル識別プログラム1932の詳細な動作フローについては図28で述べる。
前記承認管理プログラム1931がファイル識別プログラム1932から識別結果を受け取ると、前記持出しルールDB1944を参照し、要確認項目を抽出する(2710)。前記持出しルールDB1944には、持出し時におけるファイル形式や持出し方法などの組み合わせにおいて許可あるいは不許可のルールが記載されている。これは管理者や承認者が事前にDB管理プログラム1934を通じて更新するものであり、組織全体や部署などの小規模な単位での設定も可能である。例えば、(1)取引先リスト1941に登録されていない持出しについてはファイルの詳細確認が必要、(2)ファイル形式がDRM以外の場合は理由の記載が必須、といったルールが定義される。
要確認項目を抽出した前記承認管理プログラム1931は、承認者3のクライアント70等に承認依頼を通知する(2711)。前記承認者のクライアント70は、承認者の指示を受けて承認管理プログラム1931を利用し、承認管理プログラム1931と通信し、前記承認依頼に対応する申請案件の内容を読み出して表示させる(2712、2713)。前記承認者が前記クライアント70にて閲覧する承認待ち一覧画面230については図25で説明したとおりである。
前記承認者が承認/却下/保留のいずれかの判断を前記クライアント70で入力すると、該当クライアント70はこの判断結果を前記承認管理プログラム1931に送信する(2714)。この時、前記承認管理プログラム1931は前記判断結果を受信し、その内容が却下あるいは保留であるか判定する。前記内容が「却下」あるいは「保留」である場合(2715:N)、前記承認管理プログラム1931は、前記利用者のクライアント70に申請が不許可となった通知を送信する(2716)。なお、この通知はメールなどを利用して利用者に通知してもよいし、前記承認管理プログラム1931に前記利用者のクライアント70がアクセスすると承認ステータスを表示させるようにしてもよい。
他方、前記承認者の判断が「承認」であった場合(2715:Y)、前記承認管理プログラム1931はファイル変換プログラム1935に対して該当ファイルを送信し、承認されたファイル形式に変換させる(2717)。さらに、承認管理プログラム1931は前記DB管理プログラム1934に承認結果を送信して照合用DB1943における該当オブジェクトの取り扱い情報を最新の判断結果に更新させる(2718)。なお、前記ファイル変換プログラム1935ではファイル形式を変換すると共に、承認されたファイルであることを識別可能な属性情報を埋め込む。これにより、クライアント70に当該ファイルがダウンロードされた場合に、申請管理プログラム1911が当該ファイルを識別し色づけして表示するため、クライアント70に格納されたファイルのうち、どれが承認されたファイルなのかを一目で把握することができる。
前記ファイル変換プログラム1935でのファイル変換が完了すると、前記承認管理プログラム1931は承認管理DB1942(における“ステータス”など)を更新し(2719)、承認結果を利用者のクライアント70に通知する(2720)。前記利用者のクライアント70が承認管理サーバ193にアクセスして(2721)、持出し用の形式に変換されたファイルをダウンロードすると(2722)、利用者は持出しが可能となる。その後の持出しにおけるコントロールの詳細な処理については、実施例1に示したとおりである。
続いて、図28に基づきファイル識別プログラム1932の処理フローについて説明する。ファイル識別プログラム1932は、承認管理プログラム1931より、申請対象のファイルを取得し(2811)、申請ファイルの構造を分析する(2812)。この申請ファイルの構造分析では、ファイルにおけるヘッダフッタ情報やテンプレート情報(例:ファイル作成に利用している書式ひな形等)、テキスト情報などをページ単位で取得しメモリ等に格納しておく。さらに、前記申請対象のファイルと類似した他ファイルを特定するために、申請対象のファイルのハッシュ値を取得する。また、ファイル形式などにより構造を分析できなかったファイルについては、前記ステップ2812において、前記ファイル識別プログラム1932は承認管理プログラム1931にエラーを返し、処理を終了する。
次に、前記ファイル識別プログラム1932は、申請が一度承認者に保留された案件である場合(2813:Y)、保留された案件のファイルを記憶手段中から取得し(2814)、保留案件ファイルと今回の申請ファイルとの差分を特定する(2815)。
また、新規申請の場合は(2813:N)、前記ファイル識別プログラム1932は、同じ持出先に対して持出し申請を行った履歴ファイルや過去却下されたファイルなどを承認管理DB1942から抽出し、ここで抽出したもののうちから前記申請対象のファイルと最も類似するファイルを特定する(2816)。類似の判断基準としては、前記構造分析(ステップ2812)で得ておいた、ファイルにおけるページ単位のヘッダフッタ情報やテンプレート情報(例:ファイル作成に利用している書式ひな形等)、テキスト情報などであり、前記ファイル識別プログラム1932は、これらについて一致するもの(であり、同じ持出先に対して持出し申請を行ったものや過去却下されたものなど)を前記承認管理DB1942で検索する。こうした類似した他ファイルの特定を行ったファイル識別プログラム1932は、前記特定した他ファイルと前記申請対象ファイルとの差分を特定する(2817)。この差分特定により、例えば、前記他ファイルにおいても、同じ単語や文章が同じページ位置などに入力されているといった部分を特定しておくことで、過去において既に承認判断がなされたオブジェクト(=他ファイルにおいて前記申請対象のファイルのオブジェクトと一致するオブジェクト)、に関しては新たな承認判断を省くことが出来る。なお、類似度が高いファイルがなかった場合には、差分取得処理を行わずに次の処理を実行する(2822)。
次に、前記ファイル識別プログラム1932は、分析した申請対象のファイルのうち、1ページのデータを選択し(2818)、照合用DB1943を参照して前記ステップ2817で特定した差分部分における利用禁止オブジェクト(例:“極秘”などのテキスト)の有無と、利用禁止オブジェクトが含まれていた場合にはページ内の位置(例:該当ページの○○行目○○番目)を特定し、前記特定した検出位置をハイライトなどで強調表示する(2819)。なお、前記照合用DB1943は、セキュリティ用語や人名、企業名、相手先個別のDBなど複数に分類しておき、DBごとに照合を行った結果を識別できるように保持しておくとよい。
前記ファイル識別プログラム1932は、前記申請対象のファイルにおける全ページについて前記ステップ2819の処理を行うと(2820:Y)、前記検出した利用禁止オブジェクトの数をページ単位で比較し、利用禁止オブジェクトを含む数の多い順にページをリストアップする。これによって確認必要順を決定し(2821)、承認管理プログラム1931に結果(図25の詳細画面233における、プレビュー2461での確認必要順2459が押下された場合の表示形態)を送信して終了する。
以上、ファイル識別プログラム1932では、既に承認(ないし却下)された他ファイルと申請対象のファイルとの差分を特定することにより、これまで持出し許可されたファイルにはない特徴を絞り込みし、さらに利用禁止オブジェクトの有無を検出することで承認者が確認すべきポイントを絞り込みすることができる。さらに、ページ単位でオブジェクトの検出数を比較し、検出数に基づいて確認優先順をつけることにより、承認者が確認すべきページを効率よく提示することができる。さらに、利用禁止オブジェクトの種類ごとに検出位置を特定することにより、ページのどの部分がどのカテゴリでリスクがあるのかを一目でわかるようにすることができる。
次に、図29に基づき前記DB管理プログラム1934の処理フローについて説明する。前記DB管理プログラム1934は、承認判断が完了したときに承認結果にもとづいて照合用DB1943の更新を行うプログラムである。この場合、前記承認管理プログラム1931で承認者による承認結果を受信したのち(図27の2718)、DB管理プログラムは承認結果とファイル識別プログラム1932で分析した分析データとを取得する(241)。前記承認結果は、持出先の登録情報と承認/却下/保留のうちいずれかの承認結果を含む。また、前記分析データは、申請対象のファイルの構造データやテキスト情報などに加えて、照合用DB1943での利用禁止オブジェクトなどに該当するとして検出されたオブジェクトとその検出件数を含む。
次に、前記DB管理プログラム1934は、前記承認結果から取得した持出先登録情報(例えば、持ち出し先の会社名やそのメールアドレス)より、持出先用の照合用DB1943が存在するか特定する(242)。持出先用の照合用DB1943が存在しない場合(242:N)、前記DB管理プログラム1934は新たに照合用DB1943を作成する(243)。
続いて前記DB管理プログラム1934は、前記承認管理プログラム1931から取得した分析データについて、検出されたオブジェクトを検出数順に並び替えてリスト化する(244)。また前記DB管理プログラム1934は、前記承認結果が「承認」だった場合(245:Y)、検出されたオブジェクトを利用可能オブジェクトとして持出先用の照合用DB1943に登録する(246)。
他方、前記承認結果が「却下」だった場合(245:N、247)、検出されたオブジェクトを利用不可オブジェクトとして持出先用の照合用DB1943に登録する(248)。このとき登録するデータは、却下理由が「内容上不適切」であった場合とし、前記詳細画面233(図25)において承認者が「不適切」と選択したオブジェクトがある場合は選択した部分のみ登録を行う。これは、句読点や漢字のミスなど表現上の不適切な部分については照合用DB1943へのオブジェクトの登録が不要であるためである。
続いて、前記DB管理プログラム1934は、前記ステップ246、248らにおいて、検出された全てのオブジェクトを照合用DB1943に登録すると、現在承認管理サーバ193に登録されている持出先別の照合用DB1943を比較し(249)、あらかじめ設定しておいた閾値以上の割合で各照合用DB1943に登録されたオブジェクトがあった場合には(250:Y)、汎用DB2104に登録する(251)。これにより、契約などにより相手先と共有しても問題ないオブジェクト等は相手先別の照合用DB1943で管理しておき、一方、統一的に管理されるべきオブジェクト(ファイル等を跨って共通に取り扱われるべきオブジェクト)については汎用DB2104で管理することができる。そのため、ファイルの持出先に合わせて、検出すべきオブジェクトを設定し、それを洗練させていくことができる。
以上述べた第3実施例により、第1実施例および第2実施例に加えて、承認時に承認者が持出し申請されたファイルを持出してよいか判断しやすくなり、さらに、判断ミスを少なくすることが可能となる。
以上、3つの実施例について説明したが、上記実施例に限定されるものではなく、その要旨を逸脱しない範囲において種々の変形が可能であるし、各実施例を組み合わせても良い。