通信制御システム
【課題】簡易且つ安価な構成で、蓄積されている電子データを他の媒体に取り出す際に取り出した本人しか利用できないような制御や、取り出された電子データの管理者による強制的に廃棄を可能とする。
【解決手段】電子データ管理サーバが、ポリシサーバ５から得たユーザのポリシーに基づいて配信の可否を判断し、配信するに際しては電子データを暗号化し、ユーザの電子証明書の有効性を検証する証明書有効性検証サーバ７が、ユーザ端末１のユーザアプリケーション２から送られたユーザの電子証明書を受信し、当該電子証明書の有効性を検証した結果、当該電子証明書が失効している場合には、上記ユーザアプリケーション２に対して上記電子データの廃棄を促すことを特徴とする通信制御システムである。
【解決手段】電子データ管理サーバが、ポリシサーバ５から得たユーザのポリシーに基づいて配信の可否を判断し、配信するに際しては電子データを暗号化し、ユーザの電子証明書の有効性を検証する証明書有効性検証サーバ７が、ユーザ端末１のユーザアプリケーション２から送られたユーザの電子証明書を受信し、当該電子証明書の有効性を検証した結果、当該電子証明書が失効している場合には、上記ユーザアプリケーション２に対して上記電子データの廃棄を促すことを特徴とする通信制御システムである。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子データ等を保持しているデータベースやファイルサーバ等へのアクセスをアクセス者のポリシー等に基づいて制御し、電子データを暗号化した後に配信する通信制御システムに関する。
【背景技術】
【０００２】
従来、ネットワーク上で電子データ等の配布を行う場合に、当該電子データを暗号化して送ることが一般になされているが、当該電子データが重要なドキュメント等である場合には、当該電子データを取得した後においても利用制限をかけることが望まれる。
【０００３】
このような点に鑑みて、特許文献１では、サーバが組織構成や利用者ＩＤ及び文書に設定された利用規則に基いて、その利用者に対する利用規則を決定し、そして、利用者の公開鍵で暗号化して送り、クライアント装置が上記利用規約に基づいて文書を復号化して利用者に提示する技術が開示されている。
【特許文献１】特開２００４−３００５６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記特許文献１では、サーバ側で組織構成や利用者ＩＤ、利用規約の情報を管理しなければならない。さらに、[発明が解決しようとする課題]に記載されている、“本日辞表を提出した社員がいて、辞表提出後に自分のハードディスク内のコンテンツする利用できない、つまり社外へ情報の持ち出しができなくなるという仕組みをサーバ側に保存している利用規則の変更で実現する”と述べているが、コンテンツを利用する際には、この利用規則をチケットサーバに毎回取得する必要がある。また、この利用規則はコンテンツ毎に用意する必要がある。そのため、この利用規則の管理には、非常に大きな負荷がかかるし、例にあるように社員が退職した場合、その社員に関連した利用規則を全て変更しなければならない。すなわち、蓄積されている電子データを他の媒体に取り出す際に、取り出した本人しか利用できないような制御、取り出された電子データの管理者による強制的な廃棄については非常に管理負荷の大きい仕組みを採用していると言える。
【０００５】
さらに、上記文献１では、[解決手段]にあるように、文書ファイルを文書サーバに登録する際に利用規則をチケットサーバに登録するとあることから、既存のファイルサーバやDBに蓄積された電子データの利用について全く言及されていない。
【０００６】
本発明の目的とするところは、簡易且つ安価な構成で、既存のファイルサーバやDBに蓄積されている電子データを他の媒体に取り出す際に取り出した本人しか利用できないような制御や、取り出された電子データの管理者による強制的な廃棄を可能とすることにある。特に、ユーザが保持する電子データを一括廃棄する、電子データ毎に廃棄するといったことが可能な点に特徴がある。さらに、この電子データ毎に廃棄するというのは、複数のユーザが保持している際にも、一括廃棄可能となる。
【課題を解決するための手段】
【０００７】
上記目的を達成するために、本発明の第１の態様では、ユーザアプリケーションを実装したユーザ端末と通信自在な通信制御システムにおいて、ユーザ毎のポリシーを管理するポリシーサーバと、電子データを蓄積したファイルサーバと、上記ユーザ端末から電子データ取得リクエストを受けると、上記ポリシーサーバにポリシー取得リクエストを行い、当該ポリシーサーバから得たポリシーに基づいて電子データをユーザ端末に配信してよいか否かを判断し、配信してよいと判断した場合にはファイルサーバより電子データを取得し当該電子データを暗号化した後にユーザ端末に送信するように制御する管理サーバと、を具備することを特徴とする通信制御システムが提供される。
【０００８】
第２の態様では、この第１の態様において、ユーザの電子証明書の有効性を検証する証明書有効性検証サーバを更に有し、当該証明書有効性検証サーバが、上記ユーザ端末から送られたユーザの電子証明書を受信し、当該電子証明書の有効性を検証した結果、当該電子証明書が失効している場合には、上記ユーザアプリケーションに対して上記電子データの廃棄を促すことを更に特徴としてもよい。
【０００９】
この第２の態様において、上記廃棄とは、上記暗号化された電子データの復号化を禁止することをいうこととしてもよい。
【００１０】
この第２の態様において、上記ユーザの電子証明書の有効性については、管理者により失効させることが可能であるようにしてもよい。
【００１１】
この第２の態様において、ユーザに配布された電子データのIDとその電子データの暗号化に利用された鍵の電子証明書を管理する鍵、電子データ管理サーバを有することとしてもよい。
【００１２】
また、上記第１の態様において、上記管理サーバにおいて、電子データ単位やユーザ単位で電子データを廃棄することを受け付けるインタフェースを保持することを更なる特徴としてもよい。
【発明の効果】
【００１３】
本発明によれば、簡易且つ安価な構成で、蓄積されている電子データを他の媒体に取り出す際に取り出した本人しか利用できないような制御や、取り出された電子データの管理者による強制的な廃棄を可能とする通信制御システムを提供することができる。
【発明を実施するための最良の形態】
【００１４】
以下、図面を参照して、本発明の実施の形態について説明する。
【００１５】
先ず、本発明の第１の実施の形態について説明する。
【００１６】
図１は、本発明の第１の実施の形態に係る通信制御システムの構成を示す図である。
【００１７】
この図１に示されるように、この通信制御システムは、ユーザアプリケーション２が実装されたユーザ端末１とインターネット等のネットワーク８を介して相互に通信自在な電子データ管理サーバ３、証明書発行・管理サーバ６、証明書有効性検証サーバ７により構成されている。電子データ管理サーバ３は、データベース（以下、ＤＢと称する）／ファイルサーバ４、ポリシーサーバ５とも通信自在となっている。
【００１８】
このような構成において、ユーザアプリケーション２は、ユーザ端末１にインストールされＯＳ上で実行される。電子データ管理サーバ３は、ユーザアプリケーション２からのリクエストに基づいてＤＢ／ファイルサーバ４やポリシーサーバ５と情報のやり取りや電子データの暗号化を行う。ポリシーサーバ５は、ネットワーク上のユーザ端末１のＱｏＳやセキュリティ制御機能を一元管理するものであり、ここでは電子データを送信すべきか否かを決定するためのポリシーを管理している。ＤＢ／ファイルサーバ４は、電子データを蓄積している。証明書発行・管理サーバ６は、暗号化の鍵や電子証明書を発行する。そして、証明書有効性検証サーバ７は、電子証明書の有効性を検証する。
【００１９】
以下、図２のフローチャートを参照して、本発明の第１の実施の形態に係る通信制御システムによる一連の動作を詳細に説明する。
【００２０】
ユーザ端末１のユーザアプリケーション２が電子データ管理サーバ３に電子データ取得リクエストを行うと（ステップＳ１）、電子データ管理サーバ３はポリシーサーバ５にポリシー取得リクエストを行う（ステップＳ２）。このポリシー取得リクエストにはユーザＩＤが含まれている。ポリシーサーバ５は、このポリシー取得リクエストを受けると、ユーザＩＤに対応するポリシーを電子データ管理サーバ３に返信する（ステップＳ３）。
【００２１】
電子データ管理サーバ３は、このポリシーを受信すると、当該ポリシーに基づいて電子データをユーザアプリケーション２に与えてよいか否かを判断し、与えてよいと判断した場合にはＤＢ／ファイルサーバ４にファイル取得リクエストを行う（ステップＳ４）。
【００２２】
そして、ＤＢ／ファイルサーバ４は、このリクエストを受けると、該当する電子データであるファイルを電子データ管理サーバ３に送信する（ステップＳ５）。
【００２３】
続いて、電子データ管理サーバ３は、このファイルを暗号化し（ステップＳ６）、暗号化された電子データをユーザアプリケーション２に送信する（ステップＳ７）。そして、ユーザアプリケーション２は、暗号化された電子データを復号化し（ステップＳ８）、こうして電子データの利用を開始する（ステップＳ９）。
【００２４】
以上説明したように、本発明の第１の実施の形態によれば、ユーザＩＤに対応するポリシーに基づいてファイル取得の可否を判断し、電子データを暗号化してユーザアプリケーション２側に送信することができるので、セキュリティを確保することができる。
【００２５】
次に本発明の第２の実施の形態について説明する。
【００２６】
これは、暗号化方式として「公開鍵暗号化方式」を採用したものである。
【００２７】
基本的な構成は図１と同様であるので、ここでは図１と同一構成については同一符号をもって適宜参照することとし、重複した説明は省略する。
【００２８】
以下、図３のフローチャートを参照して、本発明の第２の実施の形態に係る通信制御システムによる一連の動作を詳細に説明する。
【００２９】
ユーザ端末１のユーザアプリケーション２が電子データ管理サーバ３に電子データ取得リクエストを行うと（ステップＳ１１）、電子データ管理サーバ３はポリシーサーバ５にポリシー取得リクエストを行う（ステップＳ１２）。この電子データ取得リクエストにはユーザＩＤが少なくとも含まれている。ポリシーサーバ５は、ポリシー取得リクエストを受けると、ユーザＩＤに対応するポリシーを返信する（ステップＳ１３）。電子データ管理サーバ３は、このポリシーを受信すると、当該ポリシーに基づいて電子データをユーザアプリケーション２に与えてよいか否かを判断し、与えてよいと判断した場合にはＤＢ／ファイルサーバ４にファイル取得リクエストを行う（ステップＳ１４）。ＤＢ／ファイルサーバ４は、このリクエストを受けると、該当するファイルを送信する（ステップＳ１５）。
【００３０】
電子データ管理サーバ３は、電子証明書発行・管理サーバ６に公開鍵、秘密鍵、電子証明書の作成リクエストを行う（ステップＳ１６）。証明書発行・管理サーバ６は、このリクエストを受けると、公開鍵、秘密鍵、電子証明書を作成し、電子データ管理サーバ３に送信する（ステップＳ１７）。尚、電子証明書、鍵ペア（公開鍵・秘密鍵）の作成はユーザ毎であってもファイル毎であってもよいことは勿論である。
【００３１】
電子データ管理サーバ３は、この作成した公開鍵で電子データを暗号化し、ユーザの公開鍵で秘密鍵を暗号化し（ステップＳ１８）、作成された公開鍵の電子証明書、暗号化された電子データ、及び暗号化された秘密鍵をユーザアプリケーション２に送信する（ステップＳ１９）。ユーザアプリケーション２は、これらを取得すると作成された公開鍵の電子証明書、ユーザの電子証明書の有効性の検証を証明書有効性検証サーバ７に問い合わせる（ステップＳ２０）。証明書有効性検証サーバ７は、検証結果をユーザアプリケーション２側に送信する（ステップＳ２１）。検証の結果、ユーザの電子証明書が失効していない場合には、ユーザアプリケーション２は、公開鍵で暗号化された秘密鍵の復号化を行い（ステップＳ２２）、復号化された秘密鍵で電子データの復号化を行い（ステップＳ２３）、電子データの利用を開始する（ステップＳ２４）。
【００３２】
以上説明したように、本発明の第２の実施の形態によれば、証明書発行・管理サーバ６により作成された公開鍵で電子データを暗号化し、ユーザの公開鍵で暗号化された秘密鍵を併せて送信するようにしているのでセキュリティが確保される。電子データ利用後は、作成された公開鍵で暗号化された電子データのみ保存され、同じ電子データを再度利用する際は、ステップ20より開始するのは勿論である。また、ユーザの電子証明書が失効している場合にはアプリケーション２が暗号化された電子データを復号化しないことから、例えば退職されたユーザが退職後に電子データを閲覧しようとしても、当該ユーザの電子証明書を失効しておけば閲覧不可とすることができる。
【００３３】
次に本発明の第３の実施の形態について説明する。
【００３４】
これは、暗号化方式として「共通鍵暗号化方式」を採用したものである。
【００３５】
基本的な構成は図１と同様であるので、ここでは図１と同一構成については同一符号をもって適宜参照することとし、重複した説明は省略する。
【００３６】
以下、図４のフローチャートを参照して、本発明の第３の実施の形態に係る通信制御システムによる一連の動作を詳細に説明する。
【００３７】
ユーザ端末１のユーザアプリケーション２が電子データ管理サーバ３に電子データ取得リクエストを行うと（ステップＳ３１）、電子データ管理サーバ３はポリシーサーバ５にポリシー取得リクエストを行う（ステップＳ３２）。電子データ取得リクエストにはユーザＩＤが含まれている。ポリシーサーバ５は、このポリシー取得リクエストを受けると、ユーザＩＤに対応するポリシーを返信する（ステップＳ３３）。電子データ管理サーバ３は、このポリシーを受信すると、当該ポリシーに基づいて電子データをユーザアプリケーション２に与えてよいか否かを判断し、与えてよいと判断した場合にはＤＢ／ファイルサーバ４にファイル取得リクエストを行う（ステップＳ３４）。
【００３８】
ＤＢ／ファイルサーバ４は、このリクエストを受けると、該当するファイルを送信する（ステップＳ３５）。電子データ管理サーバ３は、共通鍵を作成し（ステップＳ３６）、当該共通鍵により電子データを暗号化し（ステップＳ３７）、ユーザの公開鍵により共通鍵を暗号化し（ステップＳ３８）、暗号化された共通鍵、及び暗号化された電子データをユーザアプリケーション２に送信する（ステップＳ３９）。
【００３９】
そして、ユーザアプリケーション２は、ユーザ電子証明書の有効性の検証を証明書有効性検証サーバ７に問い合わせる（ステップＳ４０）。証明書有効性検証サーバ７は、検証結果をユーザアプリケーション２側に送信する（ステップＳ４１）。検証の結果、ユーザの電子証明書が有効である場合には、ユーザアプリケーション２は暗号化された共通鍵の復号化を行い（ステップＳ４２）、復号化された共通鍵で電子データの復号化を行い（ステップＳ４３）、電子データの利用が開始される（ステップＳ４４）。
【００４０】
以上説明したように、本発明の第３の実施の形態によれば、ユーザの公開鍵で暗号化された電子データを復号化するユーザの秘密鍵をもっているのはユーザだけであるのでセキュリティが更に高められることになる。また、ユーザの電子証明書が失効している場合にはアプリケーション２が暗号化された電子データを復号化しないことから、例えば退職されたユーザが退職後に電子データを閲覧しようとしても、当該ユーザの電子証明書を失効しておけば閲覧不可とすることができる。
【００４１】
次に本発明の第４の実施の形態について説明する。
【００４２】
これは、暗号化方式として公開鍵暗号化方式を採用したものである。
【００４３】
基本的な構成は図５に示される通りである。図１の構成と比較すると、鍵・電子データ管理サーバ９が新たに追加している点のみが相違する。その他の構成は、図１と同様であるので、ここでは図１と同一構成については同一符号をもって適宜参照することとし、重複した説明は省略する。鍵・電子データ管理サーバ９とは、作成された電子証明書と電子データの登録を行うためのものであり、これらを一元管理するものである。
【００４４】
以下、図６のフローチャートを参照して、本発明の第４の実施の形態に係る通信制御システムによる一連の動作を詳細に説明する。
【００４５】
ユーザ端末１のユーザアプリケーション２が電子データ管理サーバ３に電子データ取得リクエストを行うと（ステップＳ５１）、電子データ管理サーバ３はポリシーサーバ５にポリシー取得リクエストを行う（ステップＳ５２）。ポリシーサーバ５は、このポリシー取得リクエストを受けると、ポリシーを返信する（ステップＳ５３）。電子データ管理サーバ３は、このポリシーを受信すると、当該ポリシーに基づいて電子データをユーザアプリケーション２に与えてよいか否かを判断し、与えてよいと判断した場合にはＤＢ／ファイルサーバ４にファイル取得リクエストを行う（ステップＳ５４）。ＤＢ／ファイルサーバ４は、このリクエストを受けると、該当するファイルを送信する（ステップＳ５５）。
【００４６】
電子データ管理サーバ３は、証明書発行・管理サーバ６に公開鍵、秘密鍵、電子証明書の作成リクエストを行う（ステップＳ５６）。証明書発行・管理サーバ６は、このリクエストを受けると、公開鍵、秘密鍵、電子証明書を作成し、電子データ管理サーバ３に送信する（ステップＳ５７）。尚、電子証明書、鍵ペア（公開鍵・秘密鍵）の作成はユーザ毎であってもファイル毎であってもよい。電子データ管理サーバ３は、この作成した公開鍵で電子データを暗号化し、ユーザの公開鍵で秘密鍵を暗号化し（ステップＳ５８）、作成された電子証明書と電子データを鍵・電子データ管理サーバ９に登録する（ステップＳ５９）。
【００４７】
鍵・電子データ管理サーバ９は、登録が完了すると、その旨を電子データ管理サーバ３に返信する（ステップＳ６０）。
【００４８】
続いて、電子データ管理サーバ３は、作成された公開鍵の電子証明書、暗号化された電子データ、及び暗号化された秘密鍵をユーザアプリケーション２に送信する（ステップＳ６１）。ユーザアプリケーション２は、これらを取得すると作成された電子証明書、およびユーザ電子証明書の有効性の検証を証明書有効性検証サーバ７に問い合わせる（ステップＳ６２）。証明書有効性検証サーバ７は、検証結果をユーザアプリケーション２側に送信する（ステップＳ６３）。検証の結果、ユーザの電子証明書が失効していない場合には、ユーザアプリケーション２は暗号化された秘密鍵の復号化を行い（ステップＳ６４）、復号化された秘密鍵で電子データの復号化を行い（ステップＳ６５）、こうして電子データの利用が開始される（ステップＳ６６）。
【００４９】
以上説明したように、本発明の第４の実施の形態によれば、暗号化された電子データを復号化する秘密鍵をもっているのはユーザだけであるのでセキュリティが更に高められることになる。また、ユーザの電子証明書が失効している場合にはアプリケーション２が暗号化された電子データを復号化しないことから、例えば退職されたユーザが退職後に電子データを閲覧しようとしても、当該ユーザの電子証明書を失効しておけば閲覧不可とすることができる。さらに、作成さえた電子証明書と電子データＩＤを鍵・電子データ管理サーバ９にて登録を受け付け、一元管理することができる。
【００５０】
次に本発明の第５の実施の形態について説明する。
【００５１】
基本的な構成は図５と同様であるので、ここでは図５と同一構成については同一符号をもって適宜参照することとし、重複した説明は省略する。
【００５２】
以下、図７のフローチャートを参照して、本発明の第５の実施の形態に係る通信制御システムによる一連の動作を詳細に説明する。
管理者より電子データ管理サーバ３に対して電子データ廃棄リクエストがなされると（ステップＳ７１）、電子データ管理サーバ３は当該電子データＩＤをキーにした該当電子証明書取得リクエストを鍵・電子データ管理サーバ９に対して行う（ステップＳ７２）。
【００５３】
鍵・電子データ管理サーバ９は、ＩＤに該当する電子証明書を電子データ管理サーバ３に送信する（ステップＳ７３）。続いて、電子データ管理サーバ３は、電子証明書の失効リクエストを証明書発行・管理サーバ６に対して行う（ステップＳ７４）。
【００５４】
証明書発行・管理サーバ６は、このリクエストを受けると、証明書有効性検証サーバ７に対して失効通知を行うと共に（ステップＳ７５）、結果を電子データ管理サーバ３に通知する（ステップＳ７６）。一方、ユーザアプリケーション２より電子証明書の有効性検証の問い合わせが証明書有効性検証サーバ７に対してなされると（ステップＳ７７）、証明書有効性検証サーバ７より検証結果がユーザアプリケーション２まで送られる（ステップＳ７８）。ユーザアプリケーション２は、この電子データが廃棄された旨を通知し（ステップＳ１０９）、暗号化された電子データを廃棄することになる（ステップＳ１１０）。
【００５５】
以上説明したように、本発明の第５の実施の形態によれば、管理者より、廃棄したい電子データが、例えユーザのハードディスクといった外部記憶媒体に格納されていたとしても、電子データを暗号化している公開鍵の電子証明書を取得し、その電子証明書を失効することで、管理者側から、電子データを強制的に廃棄することが可能となる。ユーザ単位で行いたい場合は、ユーザの電子証明書を失効すれば、ユーザ単位で電子データを廃棄することができる。この電子データの廃棄については、例えばユーザアプリケーション２が実装されているユーザ端末１の不図示のハードや媒体に記憶されているデータの削除、ノイズの混入等により実現される。
【００５６】
また、強制的な廃棄に替えて暗号化された情報を復号化できないようにしたり、復号化された電子データを保存不可としたりすることもできる。
【００５７】
以上、本発明の実施の形態について説明したが、本発明はこれに限定されず、その趣旨を逸脱しない範囲で種々の改良・変更が可能であることは勿論である。例えば、暗号化方式は、上記したものには限定されないことは勿論である。
【図面の簡単な説明】
【００５８】
【図１】本発明の第１〜３の実施の形態に係る通信制御システムの構成を示す図である。
【図２】本発明の第１の実施の形態に係る通信制御システムによる一連の動作を詳細に説明するフローチャートである。
【図３】本発明の第２の実施の形態に係る通信制御システムによる一連の動作を詳細に説明するフローチャートである。
【図４】本発明の第３の実施の形態に係る通信制御システムによる一連の動作を詳細に説明するフローチャートである。
【図５】本発明の第４，５の実施の形態に係る通信制御システムの構成を示す図である。
【図６】本発明の第４の実施の形態に係る通信制御システムによる一連の動作を詳細に説明するフローチャートである。
【図７】本発明の第５の実施の形態に係る通信制御システムによる一連の動作を詳細に説明するフローチャートである。
【符号の説明】
【００５９】
１・・・ユーザ端末、２・・・ユーザアプリケーション、３・・・電子データ管理サーバ、４・・・ＤＢ／ファイルサーバ、５・・・ポリシーサーバ、６・・・証明書発行・管理サーバ、７・・・証明書有効性検証サーバ、８・・・ネットワーク。
【技術分野】
【０００１】
本発明は、電子データ等を保持しているデータベースやファイルサーバ等へのアクセスをアクセス者のポリシー等に基づいて制御し、電子データを暗号化した後に配信する通信制御システムに関する。
【背景技術】
【０００２】
従来、ネットワーク上で電子データ等の配布を行う場合に、当該電子データを暗号化して送ることが一般になされているが、当該電子データが重要なドキュメント等である場合には、当該電子データを取得した後においても利用制限をかけることが望まれる。
【０００３】
このような点に鑑みて、特許文献１では、サーバが組織構成や利用者ＩＤ及び文書に設定された利用規則に基いて、その利用者に対する利用規則を決定し、そして、利用者の公開鍵で暗号化して送り、クライアント装置が上記利用規約に基づいて文書を復号化して利用者に提示する技術が開示されている。
【特許文献１】特開２００４−３００５６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記特許文献１では、サーバ側で組織構成や利用者ＩＤ、利用規約の情報を管理しなければならない。さらに、[発明が解決しようとする課題]に記載されている、“本日辞表を提出した社員がいて、辞表提出後に自分のハードディスク内のコンテンツする利用できない、つまり社外へ情報の持ち出しができなくなるという仕組みをサーバ側に保存している利用規則の変更で実現する”と述べているが、コンテンツを利用する際には、この利用規則をチケットサーバに毎回取得する必要がある。また、この利用規則はコンテンツ毎に用意する必要がある。そのため、この利用規則の管理には、非常に大きな負荷がかかるし、例にあるように社員が退職した場合、その社員に関連した利用規則を全て変更しなければならない。すなわち、蓄積されている電子データを他の媒体に取り出す際に、取り出した本人しか利用できないような制御、取り出された電子データの管理者による強制的な廃棄については非常に管理負荷の大きい仕組みを採用していると言える。
【０００５】
さらに、上記文献１では、[解決手段]にあるように、文書ファイルを文書サーバに登録する際に利用規則をチケットサーバに登録するとあることから、既存のファイルサーバやDBに蓄積された電子データの利用について全く言及されていない。
【０００６】
本発明の目的とするところは、簡易且つ安価な構成で、既存のファイルサーバやDBに蓄積されている電子データを他の媒体に取り出す際に取り出した本人しか利用できないような制御や、取り出された電子データの管理者による強制的な廃棄を可能とすることにある。特に、ユーザが保持する電子データを一括廃棄する、電子データ毎に廃棄するといったことが可能な点に特徴がある。さらに、この電子データ毎に廃棄するというのは、複数のユーザが保持している際にも、一括廃棄可能となる。
【課題を解決するための手段】
【０００７】
上記目的を達成するために、本発明の第１の態様では、ユーザアプリケーションを実装したユーザ端末と通信自在な通信制御システムにおいて、ユーザ毎のポリシーを管理するポリシーサーバと、電子データを蓄積したファイルサーバと、上記ユーザ端末から電子データ取得リクエストを受けると、上記ポリシーサーバにポリシー取得リクエストを行い、当該ポリシーサーバから得たポリシーに基づいて電子データをユーザ端末に配信してよいか否かを判断し、配信してよいと判断した場合にはファイルサーバより電子データを取得し当該電子データを暗号化した後にユーザ端末に送信するように制御する管理サーバと、を具備することを特徴とする通信制御システムが提供される。
【０００８】
第２の態様では、この第１の態様において、ユーザの電子証明書の有効性を検証する証明書有効性検証サーバを更に有し、当該証明書有効性検証サーバが、上記ユーザ端末から送られたユーザの電子証明書を受信し、当該電子証明書の有効性を検証した結果、当該電子証明書が失効している場合には、上記ユーザアプリケーションに対して上記電子データの廃棄を促すことを更に特徴としてもよい。
【０００９】
この第２の態様において、上記廃棄とは、上記暗号化された電子データの復号化を禁止することをいうこととしてもよい。
【００１０】
この第２の態様において、上記ユーザの電子証明書の有効性については、管理者により失効させることが可能であるようにしてもよい。
【００１１】
この第２の態様において、ユーザに配布された電子データのIDとその電子データの暗号化に利用された鍵の電子証明書を管理する鍵、電子データ管理サーバを有することとしてもよい。
【００１２】
また、上記第１の態様において、上記管理サーバにおいて、電子データ単位やユーザ単位で電子データを廃棄することを受け付けるインタフェースを保持することを更なる特徴としてもよい。
【発明の効果】
【００１３】
本発明によれば、簡易且つ安価な構成で、蓄積されている電子データを他の媒体に取り出す際に取り出した本人しか利用できないような制御や、取り出された電子データの管理者による強制的な廃棄を可能とする通信制御システムを提供することができる。
【発明を実施するための最良の形態】
【００１４】
以下、図面を参照して、本発明の実施の形態について説明する。
【００１５】
先ず、本発明の第１の実施の形態について説明する。
【００１６】
図１は、本発明の第１の実施の形態に係る通信制御システムの構成を示す図である。
【００１７】
この図１に示されるように、この通信制御システムは、ユーザアプリケーション２が実装されたユーザ端末１とインターネット等のネットワーク８を介して相互に通信自在な電子データ管理サーバ３、証明書発行・管理サーバ６、証明書有効性検証サーバ７により構成されている。電子データ管理サーバ３は、データベース（以下、ＤＢと称する）／ファイルサーバ４、ポリシーサーバ５とも通信自在となっている。
【００１８】
このような構成において、ユーザアプリケーション２は、ユーザ端末１にインストールされＯＳ上で実行される。電子データ管理サーバ３は、ユーザアプリケーション２からのリクエストに基づいてＤＢ／ファイルサーバ４やポリシーサーバ５と情報のやり取りや電子データの暗号化を行う。ポリシーサーバ５は、ネットワーク上のユーザ端末１のＱｏＳやセキュリティ制御機能を一元管理するものであり、ここでは電子データを送信すべきか否かを決定するためのポリシーを管理している。ＤＢ／ファイルサーバ４は、電子データを蓄積している。証明書発行・管理サーバ６は、暗号化の鍵や電子証明書を発行する。そして、証明書有効性検証サーバ７は、電子証明書の有効性を検証する。
【００１９】
以下、図２のフローチャートを参照して、本発明の第１の実施の形態に係る通信制御システムによる一連の動作を詳細に説明する。
【００２０】
ユーザ端末１のユーザアプリケーション２が電子データ管理サーバ３に電子データ取得リクエストを行うと（ステップＳ１）、電子データ管理サーバ３はポリシーサーバ５にポリシー取得リクエストを行う（ステップＳ２）。このポリシー取得リクエストにはユーザＩＤが含まれている。ポリシーサーバ５は、このポリシー取得リクエストを受けると、ユーザＩＤに対応するポリシーを電子データ管理サーバ３に返信する（ステップＳ３）。
【００２１】
電子データ管理サーバ３は、このポリシーを受信すると、当該ポリシーに基づいて電子データをユーザアプリケーション２に与えてよいか否かを判断し、与えてよいと判断した場合にはＤＢ／ファイルサーバ４にファイル取得リクエストを行う（ステップＳ４）。
【００２２】
そして、ＤＢ／ファイルサーバ４は、このリクエストを受けると、該当する電子データであるファイルを電子データ管理サーバ３に送信する（ステップＳ５）。
【００２３】
続いて、電子データ管理サーバ３は、このファイルを暗号化し（ステップＳ６）、暗号化された電子データをユーザアプリケーション２に送信する（ステップＳ７）。そして、ユーザアプリケーション２は、暗号化された電子データを復号化し（ステップＳ８）、こうして電子データの利用を開始する（ステップＳ９）。
【００２４】
以上説明したように、本発明の第１の実施の形態によれば、ユーザＩＤに対応するポリシーに基づいてファイル取得の可否を判断し、電子データを暗号化してユーザアプリケーション２側に送信することができるので、セキュリティを確保することができる。
【００２５】
次に本発明の第２の実施の形態について説明する。
【００２６】
これは、暗号化方式として「公開鍵暗号化方式」を採用したものである。
【００２７】
基本的な構成は図１と同様であるので、ここでは図１と同一構成については同一符号をもって適宜参照することとし、重複した説明は省略する。
【００２８】
以下、図３のフローチャートを参照して、本発明の第２の実施の形態に係る通信制御システムによる一連の動作を詳細に説明する。
【００２９】
ユーザ端末１のユーザアプリケーション２が電子データ管理サーバ３に電子データ取得リクエストを行うと（ステップＳ１１）、電子データ管理サーバ３はポリシーサーバ５にポリシー取得リクエストを行う（ステップＳ１２）。この電子データ取得リクエストにはユーザＩＤが少なくとも含まれている。ポリシーサーバ５は、ポリシー取得リクエストを受けると、ユーザＩＤに対応するポリシーを返信する（ステップＳ１３）。電子データ管理サーバ３は、このポリシーを受信すると、当該ポリシーに基づいて電子データをユーザアプリケーション２に与えてよいか否かを判断し、与えてよいと判断した場合にはＤＢ／ファイルサーバ４にファイル取得リクエストを行う（ステップＳ１４）。ＤＢ／ファイルサーバ４は、このリクエストを受けると、該当するファイルを送信する（ステップＳ１５）。
【００３０】
電子データ管理サーバ３は、電子証明書発行・管理サーバ６に公開鍵、秘密鍵、電子証明書の作成リクエストを行う（ステップＳ１６）。証明書発行・管理サーバ６は、このリクエストを受けると、公開鍵、秘密鍵、電子証明書を作成し、電子データ管理サーバ３に送信する（ステップＳ１７）。尚、電子証明書、鍵ペア（公開鍵・秘密鍵）の作成はユーザ毎であってもファイル毎であってもよいことは勿論である。
【００３１】
電子データ管理サーバ３は、この作成した公開鍵で電子データを暗号化し、ユーザの公開鍵で秘密鍵を暗号化し（ステップＳ１８）、作成された公開鍵の電子証明書、暗号化された電子データ、及び暗号化された秘密鍵をユーザアプリケーション２に送信する（ステップＳ１９）。ユーザアプリケーション２は、これらを取得すると作成された公開鍵の電子証明書、ユーザの電子証明書の有効性の検証を証明書有効性検証サーバ７に問い合わせる（ステップＳ２０）。証明書有効性検証サーバ７は、検証結果をユーザアプリケーション２側に送信する（ステップＳ２１）。検証の結果、ユーザの電子証明書が失効していない場合には、ユーザアプリケーション２は、公開鍵で暗号化された秘密鍵の復号化を行い（ステップＳ２２）、復号化された秘密鍵で電子データの復号化を行い（ステップＳ２３）、電子データの利用を開始する（ステップＳ２４）。
【００３２】
以上説明したように、本発明の第２の実施の形態によれば、証明書発行・管理サーバ６により作成された公開鍵で電子データを暗号化し、ユーザの公開鍵で暗号化された秘密鍵を併せて送信するようにしているのでセキュリティが確保される。電子データ利用後は、作成された公開鍵で暗号化された電子データのみ保存され、同じ電子データを再度利用する際は、ステップ20より開始するのは勿論である。また、ユーザの電子証明書が失効している場合にはアプリケーション２が暗号化された電子データを復号化しないことから、例えば退職されたユーザが退職後に電子データを閲覧しようとしても、当該ユーザの電子証明書を失効しておけば閲覧不可とすることができる。
【００３３】
次に本発明の第３の実施の形態について説明する。
【００３４】
これは、暗号化方式として「共通鍵暗号化方式」を採用したものである。
【００３５】
基本的な構成は図１と同様であるので、ここでは図１と同一構成については同一符号をもって適宜参照することとし、重複した説明は省略する。
【００３６】
以下、図４のフローチャートを参照して、本発明の第３の実施の形態に係る通信制御システムによる一連の動作を詳細に説明する。
【００３７】
ユーザ端末１のユーザアプリケーション２が電子データ管理サーバ３に電子データ取得リクエストを行うと（ステップＳ３１）、電子データ管理サーバ３はポリシーサーバ５にポリシー取得リクエストを行う（ステップＳ３２）。電子データ取得リクエストにはユーザＩＤが含まれている。ポリシーサーバ５は、このポリシー取得リクエストを受けると、ユーザＩＤに対応するポリシーを返信する（ステップＳ３３）。電子データ管理サーバ３は、このポリシーを受信すると、当該ポリシーに基づいて電子データをユーザアプリケーション２に与えてよいか否かを判断し、与えてよいと判断した場合にはＤＢ／ファイルサーバ４にファイル取得リクエストを行う（ステップＳ３４）。
【００３８】
ＤＢ／ファイルサーバ４は、このリクエストを受けると、該当するファイルを送信する（ステップＳ３５）。電子データ管理サーバ３は、共通鍵を作成し（ステップＳ３６）、当該共通鍵により電子データを暗号化し（ステップＳ３７）、ユーザの公開鍵により共通鍵を暗号化し（ステップＳ３８）、暗号化された共通鍵、及び暗号化された電子データをユーザアプリケーション２に送信する（ステップＳ３９）。
【００３９】
そして、ユーザアプリケーション２は、ユーザ電子証明書の有効性の検証を証明書有効性検証サーバ７に問い合わせる（ステップＳ４０）。証明書有効性検証サーバ７は、検証結果をユーザアプリケーション２側に送信する（ステップＳ４１）。検証の結果、ユーザの電子証明書が有効である場合には、ユーザアプリケーション２は暗号化された共通鍵の復号化を行い（ステップＳ４２）、復号化された共通鍵で電子データの復号化を行い（ステップＳ４３）、電子データの利用が開始される（ステップＳ４４）。
【００４０】
以上説明したように、本発明の第３の実施の形態によれば、ユーザの公開鍵で暗号化された電子データを復号化するユーザの秘密鍵をもっているのはユーザだけであるのでセキュリティが更に高められることになる。また、ユーザの電子証明書が失効している場合にはアプリケーション２が暗号化された電子データを復号化しないことから、例えば退職されたユーザが退職後に電子データを閲覧しようとしても、当該ユーザの電子証明書を失効しておけば閲覧不可とすることができる。
【００４１】
次に本発明の第４の実施の形態について説明する。
【００４２】
これは、暗号化方式として公開鍵暗号化方式を採用したものである。
【００４３】
基本的な構成は図５に示される通りである。図１の構成と比較すると、鍵・電子データ管理サーバ９が新たに追加している点のみが相違する。その他の構成は、図１と同様であるので、ここでは図１と同一構成については同一符号をもって適宜参照することとし、重複した説明は省略する。鍵・電子データ管理サーバ９とは、作成された電子証明書と電子データの登録を行うためのものであり、これらを一元管理するものである。
【００４４】
以下、図６のフローチャートを参照して、本発明の第４の実施の形態に係る通信制御システムによる一連の動作を詳細に説明する。
【００４５】
ユーザ端末１のユーザアプリケーション２が電子データ管理サーバ３に電子データ取得リクエストを行うと（ステップＳ５１）、電子データ管理サーバ３はポリシーサーバ５にポリシー取得リクエストを行う（ステップＳ５２）。ポリシーサーバ５は、このポリシー取得リクエストを受けると、ポリシーを返信する（ステップＳ５３）。電子データ管理サーバ３は、このポリシーを受信すると、当該ポリシーに基づいて電子データをユーザアプリケーション２に与えてよいか否かを判断し、与えてよいと判断した場合にはＤＢ／ファイルサーバ４にファイル取得リクエストを行う（ステップＳ５４）。ＤＢ／ファイルサーバ４は、このリクエストを受けると、該当するファイルを送信する（ステップＳ５５）。
【００４６】
電子データ管理サーバ３は、証明書発行・管理サーバ６に公開鍵、秘密鍵、電子証明書の作成リクエストを行う（ステップＳ５６）。証明書発行・管理サーバ６は、このリクエストを受けると、公開鍵、秘密鍵、電子証明書を作成し、電子データ管理サーバ３に送信する（ステップＳ５７）。尚、電子証明書、鍵ペア（公開鍵・秘密鍵）の作成はユーザ毎であってもファイル毎であってもよい。電子データ管理サーバ３は、この作成した公開鍵で電子データを暗号化し、ユーザの公開鍵で秘密鍵を暗号化し（ステップＳ５８）、作成された電子証明書と電子データを鍵・電子データ管理サーバ９に登録する（ステップＳ５９）。
【００４７】
鍵・電子データ管理サーバ９は、登録が完了すると、その旨を電子データ管理サーバ３に返信する（ステップＳ６０）。
【００４８】
続いて、電子データ管理サーバ３は、作成された公開鍵の電子証明書、暗号化された電子データ、及び暗号化された秘密鍵をユーザアプリケーション２に送信する（ステップＳ６１）。ユーザアプリケーション２は、これらを取得すると作成された電子証明書、およびユーザ電子証明書の有効性の検証を証明書有効性検証サーバ７に問い合わせる（ステップＳ６２）。証明書有効性検証サーバ７は、検証結果をユーザアプリケーション２側に送信する（ステップＳ６３）。検証の結果、ユーザの電子証明書が失効していない場合には、ユーザアプリケーション２は暗号化された秘密鍵の復号化を行い（ステップＳ６４）、復号化された秘密鍵で電子データの復号化を行い（ステップＳ６５）、こうして電子データの利用が開始される（ステップＳ６６）。
【００４９】
以上説明したように、本発明の第４の実施の形態によれば、暗号化された電子データを復号化する秘密鍵をもっているのはユーザだけであるのでセキュリティが更に高められることになる。また、ユーザの電子証明書が失効している場合にはアプリケーション２が暗号化された電子データを復号化しないことから、例えば退職されたユーザが退職後に電子データを閲覧しようとしても、当該ユーザの電子証明書を失効しておけば閲覧不可とすることができる。さらに、作成さえた電子証明書と電子データＩＤを鍵・電子データ管理サーバ９にて登録を受け付け、一元管理することができる。
【００５０】
次に本発明の第５の実施の形態について説明する。
【００５１】
基本的な構成は図５と同様であるので、ここでは図５と同一構成については同一符号をもって適宜参照することとし、重複した説明は省略する。
【００５２】
以下、図７のフローチャートを参照して、本発明の第５の実施の形態に係る通信制御システムによる一連の動作を詳細に説明する。
管理者より電子データ管理サーバ３に対して電子データ廃棄リクエストがなされると（ステップＳ７１）、電子データ管理サーバ３は当該電子データＩＤをキーにした該当電子証明書取得リクエストを鍵・電子データ管理サーバ９に対して行う（ステップＳ７２）。
【００５３】
鍵・電子データ管理サーバ９は、ＩＤに該当する電子証明書を電子データ管理サーバ３に送信する（ステップＳ７３）。続いて、電子データ管理サーバ３は、電子証明書の失効リクエストを証明書発行・管理サーバ６に対して行う（ステップＳ７４）。
【００５４】
証明書発行・管理サーバ６は、このリクエストを受けると、証明書有効性検証サーバ７に対して失効通知を行うと共に（ステップＳ７５）、結果を電子データ管理サーバ３に通知する（ステップＳ７６）。一方、ユーザアプリケーション２より電子証明書の有効性検証の問い合わせが証明書有効性検証サーバ７に対してなされると（ステップＳ７７）、証明書有効性検証サーバ７より検証結果がユーザアプリケーション２まで送られる（ステップＳ７８）。ユーザアプリケーション２は、この電子データが廃棄された旨を通知し（ステップＳ１０９）、暗号化された電子データを廃棄することになる（ステップＳ１１０）。
【００５５】
以上説明したように、本発明の第５の実施の形態によれば、管理者より、廃棄したい電子データが、例えユーザのハードディスクといった外部記憶媒体に格納されていたとしても、電子データを暗号化している公開鍵の電子証明書を取得し、その電子証明書を失効することで、管理者側から、電子データを強制的に廃棄することが可能となる。ユーザ単位で行いたい場合は、ユーザの電子証明書を失効すれば、ユーザ単位で電子データを廃棄することができる。この電子データの廃棄については、例えばユーザアプリケーション２が実装されているユーザ端末１の不図示のハードや媒体に記憶されているデータの削除、ノイズの混入等により実現される。
【００５６】
また、強制的な廃棄に替えて暗号化された情報を復号化できないようにしたり、復号化された電子データを保存不可としたりすることもできる。
【００５７】
以上、本発明の実施の形態について説明したが、本発明はこれに限定されず、その趣旨を逸脱しない範囲で種々の改良・変更が可能であることは勿論である。例えば、暗号化方式は、上記したものには限定されないことは勿論である。
【図面の簡単な説明】
【００５８】
【図１】本発明の第１〜３の実施の形態に係る通信制御システムの構成を示す図である。
【図２】本発明の第１の実施の形態に係る通信制御システムによる一連の動作を詳細に説明するフローチャートである。
【図３】本発明の第２の実施の形態に係る通信制御システムによる一連の動作を詳細に説明するフローチャートである。
【図４】本発明の第３の実施の形態に係る通信制御システムによる一連の動作を詳細に説明するフローチャートである。
【図５】本発明の第４，５の実施の形態に係る通信制御システムの構成を示す図である。
【図６】本発明の第４の実施の形態に係る通信制御システムによる一連の動作を詳細に説明するフローチャートである。
【図７】本発明の第５の実施の形態に係る通信制御システムによる一連の動作を詳細に説明するフローチャートである。
【符号の説明】
【００５９】
１・・・ユーザ端末、２・・・ユーザアプリケーション、３・・・電子データ管理サーバ、４・・・ＤＢ／ファイルサーバ、５・・・ポリシーサーバ、６・・・証明書発行・管理サーバ、７・・・証明書有効性検証サーバ、８・・・ネットワーク。
【特許請求の範囲】
【請求項１】
ユーザアプリケーションを実装したユーザ端末と通信自在な通信制御システムにおいて、
ユーザ毎のポリシーを管理するポリシーサーバと、
電子データを蓄積したファイルサーバと、
上記ユーザ端末から電子データ取得リクエストを受けると、上記ポリシーサーバにポリシー取得リクエストを行い、当該ポリシーサーバから得たポリシーに基づいて電子データをユーザ端末に配信してよいか否かを判断し、配信してよいと判断した場合にはファイルサーバより電子データを取得し、当該電子データを暗号化した後にユーザ端末に送信するように制御する管理サーバと、
を具備することを特徴とする通信制御システム。
【請求項２】
ユーザの電子証明書の有効性を検証する証明書有効性検証サーバを更に有し、当該証明書有効性検証サーバが、上記ユーザ端末から送られたユーザの電子証明書を受信し、当該電子証明書の有効性を検証した結果、当該電子証明書が失効している場合には、上記ユーザアプリケーションに対して上記電子データの廃棄を促すことを更に特徴とする請求項１に記載の通信制御システム。
【請求項３】
上記廃棄とは、上記暗号化された電子データの復号化を禁止することをいう請求項２に記載の通信制御システム。
【請求項４】
上記ユーザの電子証明書の有効性については、管理者により失効させることが可能である請求項２に記載の通信制御システム。
【請求項５】
ユーザに配布された電子データのIDとその電子データの暗号化に利用された鍵の電子証明書を管理する鍵、電子データ管理サーバを有することを特徴とする請求項２に記載の通信制御システム。
【請求項６】
上記請求項１記載の管理サーバにおいて、電子データ単位やユーザ単位で電子データを廃棄することを受け付けるインタフェースを保持することを更なる特徴として持つ、請求項１記載の通信制御システム。
【請求項１】
ユーザアプリケーションを実装したユーザ端末と通信自在な通信制御システムにおいて、
ユーザ毎のポリシーを管理するポリシーサーバと、
電子データを蓄積したファイルサーバと、
上記ユーザ端末から電子データ取得リクエストを受けると、上記ポリシーサーバにポリシー取得リクエストを行い、当該ポリシーサーバから得たポリシーに基づいて電子データをユーザ端末に配信してよいか否かを判断し、配信してよいと判断した場合にはファイルサーバより電子データを取得し、当該電子データを暗号化した後にユーザ端末に送信するように制御する管理サーバと、
を具備することを特徴とする通信制御システム。
【請求項２】
ユーザの電子証明書の有効性を検証する証明書有効性検証サーバを更に有し、当該証明書有効性検証サーバが、上記ユーザ端末から送られたユーザの電子証明書を受信し、当該電子証明書の有効性を検証した結果、当該電子証明書が失効している場合には、上記ユーザアプリケーションに対して上記電子データの廃棄を促すことを更に特徴とする請求項１に記載の通信制御システム。
【請求項３】
上記廃棄とは、上記暗号化された電子データの復号化を禁止することをいう請求項２に記載の通信制御システム。
【請求項４】
上記ユーザの電子証明書の有効性については、管理者により失効させることが可能である請求項２に記載の通信制御システム。
【請求項５】
ユーザに配布された電子データのIDとその電子データの暗号化に利用された鍵の電子証明書を管理する鍵、電子データ管理サーバを有することを特徴とする請求項２に記載の通信制御システム。
【請求項６】
上記請求項１記載の管理サーバにおいて、電子データ単位やユーザ単位で電子データを廃棄することを受け付けるインタフェースを保持することを更なる特徴として持つ、請求項１記載の通信制御システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２００６−３３６２４（Ｐ２００６−３３６２４Ａ）
【公開日】平成１８年２月２日（２００６．２．２）
【国際特許分類】
【出願番号】特願２００４−２１２１１８（Ｐ２００４−２１２１１８）
【出願日】平成１６年７月２０日（２００４．７．２０）
【出願人】（５０２３０６６６０）日本テレコム株式会社 (63)
【Ｆターム（参考）】
【公開日】平成１８年２月２日（２００６．２．２）
【国際特許分類】
【出願日】平成１６年７月２０日（２００４．７．２０）
【出願人】（５０２３０６６６０）日本テレコム株式会社 (63)
【Ｆターム（参考）】
[ Back to top ]