JP2011507414A

JP2011507414A - データの安全を保護するためのシステムおよび方法

Info

Publication number: JP2011507414A
Application number: JP2010538282A
Authority: JP
Inventors: ローレンスエドワードヌスバーム; スティーブントンプソン
Original assignee: コクーンデータホールディングスリミテッド
Priority date: 2007-12-21
Filing date: 2008-12-22
Publication date: 2011-03-03
Also published as: US8806207B2; AU2008341026C1; EP2232763A4; AU2008341026A1; AU2011201188A1; WO2009079708A1; NZ586279A; AU2008341026B2; KR20100133953A; CN101953111A; CA2709944C; CA2709944A1; EP2232763A1; US20110040964A1

Abstract

【課題】電子ファイルに含まれるデータを安全にユーザーが管理できるようにすること
【解決手段】本発明は、最初のユーザーにより少なくとも一人の受信側ユーザーに配信されるデータの安全を保護するための方法であって、鍵で前記データを暗号化するための、前記最初のユーザーからのリクエストに応答するステップと、前記鍵のロケーションをデータベースに記録するステップとを備え、前記データベースは、前記少なくとも一人の受信側ユーザーからの認可のためのリクエストを受信すると、前記認可時に前記鍵を前記少なくとも一人の受信側ユーザーに提供する、前記データの安全を保護するための方法を提供するものである。
【選択図】図１

Description

本発明は、データの安全を保護するためのシステムおよび方法に関し、より詳細には、電子フォーマットで送られるデータオブジェクトの安全を保護するためのシステムおよび方法に関するが、かかるシステムおよび方法だけに限定されるものではない。

オンライン環境では、電子データを、あるポイントから別のポイントに配信することが多い。特にデータが秘密であり、保護が必要であるような状況において、不正な利用またはアクセスからデータの安全を保護しなければならない場合、ユーザーは、安全でないネットワークを通してデータを送る前に、データを暗号化するためのシステムを利用できる。

データを暗号化するためのシステムおよび方法は知られている。かかるシステムは、ユーザーがデータオブジェクトを選択し、次にクライアントの操作によってパスワードまたは他のタイプのキー（例えばＰＩＮ（パーソナル識別番号）、生体マーカーなど）でデータオブジェクトを暗号化し、暗号化されたデータファイルを作成できるようにする。ユーザーがファイルの暗号を解読するための正しい情報を有していなければ、ユーザーはデータファイルのコンテントを見ることはできないので、このデータファイルを、許容されていない不正なユーザーから「保護」できる。データファイルの暗号を解読しなければならないとき、パスワードを有する正式なユーザーはクライアントを使用することによりデータファイルの暗号を解読できる。

暗号化されたデータファイルをユーザーが配信する意図が全くないかほとんどない場合、かかる仕組みは有効である。かかる状況において、データオブジェクトを一旦暗号化すると、安全でないネットワークを通してデータオブジェクトが配信され得る。しかしながら、ユーザーはオブジェクトの暗号を解読するために、認可されている人物のためのパスワードを配信する方法も見つけなければならない。このパスワードは、効率性のために、自らを暗号化することなく安全でないネットワークを通して配信される。パスワードが横取りされたり、不正な当事者に渡る可能性があるので、このことはデータオブジェクトの安全が脅かされる可能性を高めてしまう。

別の問題は、暗号化されたデータファイル自身の内部に暗号化キーが記憶されるので、標準的な暗号化によって提供される保護レベルが最小となるということである。すなわちファイルが一旦受信されると、ハッカーはデータファイルを暗号化するための必要なデータのすべてを取得してしまう。更に、ユーザーが技術的に熟練していない場合、破るのが容易なパスワードを選ぶと、「力づくの」方法を使用することによってデータオブジェクトの暗号を容易に解読できてしまうことを意味する。

パスワード及びデータオブジェクトが一旦配信されると、ファイルを操作できる権利が受信側ユーザーに完全に移ってしまうので、データオブジェクトを暗号化するための、より安全で機密性の高いパスワードを使用した場合でも、ユーザーはまだデータオブジェクトを利用する態様を管理できない。例えばユーザーがデータオブジェクトを暗号化し、この暗号化されたデータオブジェクトをインターネットを介して別のロケーションへ送った場合、受信側ユーザーはオブジェクトの機密性を検討することなく、データオブジェクトを更に配信できる。例えば、第三者が、暗号化されたデータファイルと共にパスワードを自由に配信するか、または双方の暗号状態を共に除き、複数の未知のユーザーがこのデータオブジェクトにアクセスできるようになってしまう。

これら限界により電子ファイルに含まれるデータを安全にユーザーが管理することが極めて困難なものとなっている。

本発明の第１の様相によれば、最初のユーザーにより少なくとも一人の受信側ユーザーに配信されるデータの安全を保護するための方法であって、鍵で前記データを暗号化するための、前記最初のユーザーからのリクエストに応答するステップと、前記鍵のロケーションをデータベースに記録するステップとを備え、前記データベースは、前記少なくとも一人の受信側ユーザーからの認可のためのリクエストを受信すると、前記認可時に前記鍵を前記少なくとも一人の受信側ユーザーに提供する、前記データの安全を保護するための方法が提供される。

一実施形態では、前記少なくとも一人の受信側ユーザーの前記データとの相互対話を制限するようになっているデータベース受信ルールの別のステップが提供される。

一実施形態では、前記認可するステップは、前記少なくとも一人の受信側ユーザーの識別プロフィルと所定の基準とを比較するステップを更に備え、前記所定の基準が前記識別プロフィルに一致する場合に、前記少なくとも一人の受信側ユーザーを認可する。

一実施形態では、前記識別プロフィルは、前記少なくとも一人の受信側ユーザーの特性の特徴を定める少なくとも１つの基準を含む。

一実施形態では、前記最初のユーザーは、中央ソースから鍵をリクエストするようになっているクライアントアプリケーションと相互対話する。

一実施形態では、前記少なくとも一人のユーザーは、前記データの暗号を解読する認可を前記中央ソースからリクエストするようになっている少なくとも１つのレシーバーアプリケーションと相互対話する。

一実施形態では、前記中央ソースのいずれか１個または前記クライアントアプリケーションにより前記鍵を発生する。

一実施形態では、前記中央ソースは、認可されていない不正なユーザーから前記サーバーを保護するようになっているゲートキーパーサービスを含む。

一実施形態では、前記中央ソースは、前記受信側ユーザーにより、前記データにアクティビティをログするようになっているロギングサービスを更に含む。

一実施形態では、前記データは、暗号化されたデータストリングとしてファイルラッパー内に含まれる。

一実施形態では、前記ファイルラッパーは、前記レシーバーアプリケーションによって処理されるようになっている安全なドキュメントである。

一実施形態では、前記データが、このデータをエンクローズするようになっている安全なエンベロープ内にあるときに、前記少なくとも一人の受信側ユーザーの前記データとの相互対話が、前記最初のユーザーが定めたルールによって制限されるよう、前記データオブジェクトには前記データをエンクローズするようになっている安全なエンベロープが設けられている。

本発明の第２の様相によれば、最初のユーザーにより少なくとも一人の受信側ユーザーに配信されるデータの安全を保護するためのシステムであって、鍵で前記データを暗号化するための、前記最初のユーザーからのリクエストに応答するモジュールと、前記鍵のロケーションをデータベースに記録するようになっているルーチンとを備え、前記データベースは、前記少なくとも一人の受信側ユーザーからの認可のためのリクエストを受信すると、前記認可時に前記鍵を前記少なくとも一人の受信側ユーザーに提供する、前記データの安全を保護するためのシステムが提供される。

第２の様相の一実施形態では、前記データベースは、前記少なくとも一人の受信側ユーザーの前記データとの相互対話を制限するルールを受信するようになっている。

本発明の第３の様相によれば、本発明の第１の様相にかかわる方法を実施するよう、コンピュータシステムを制御するための少なくとも１つの命令を含むコンピュータプログラムが提供される。

次に添付図面を参照し、単なる例により、本発明の実施形態について説明する。

本発明の一実施形態に係わるシステムのブロック図である。図１の実施形態に係わるシステムの一様相の作動のフローチャートである。図１の実施形態に係わるシステムの第２の様相の作動のフローチャートである。図１の実施形態に係わるサーバーコンポーネントを示すブロック図である。本システムの一実施形態に係わるファイルラッパーの一例である。本システムの一実施形態に係わる安全なデータオブジェクトの一例を示す。本システムの一実施形態に係わる安全なデータオブジェクトの別の例を示す。

次に、図１を参照する。ここで、本発明の一実施形態は、データの安全を保護するためのシステムを提供するようになっており、このシステムは、データをある鍵で暗号化するよう、最初のユーザーからのリクエストに応答するようになっている中央ソース１００と、認可のためのリクエストを受信するようになっている認可サービスとを備え、受信側ユーザーが認可されると、受信側ユーザーはデータの暗号を解読するための鍵へ向けられる。

この実施形態では、本発明のこの実施形態に係わるシステム、方法および関連するソフトウェアおよび／またはハードウェアアプリケーションを、デバイス、例えば図１に示されるデバイスの一例で実行できる。図１には、中央ソースの略図が示されており、中央ソースはこの実施形態では、本発明の一実施形態と共に使用するのに適したサーバー１００となっている。サーバー１００はアプリケーションおよび／またはシステムサービス、例えば本発明の一実施形態に係わる、データの安全を保護するためのシステムおよび方法を実行するのに使用できる。

図１を参照すると、このサーバー１００は、適当なコンピュータの命令を受信し、記憶し、実行するのに必要な適当なコンポーネントを含むことができる。これらコンポーネントとして、プロセッサ１０２、リードオンリーメモリ（ＲＯＭ）１０４、ランダムアクセスメモリ（ＲＡＭ）１０６、ディスクドライブ１０８のような入出力デバイス、入力デバイス１１０（例えばイーサネット（登録商標）ポート、ＵＳＢポートなど）、ディスプレイ１１２、例えば液晶ディスプレイ、発光ディスプレイまたは他の任意の適当なディスプレイ、および通信リンク１１４を挙げることができる。このサーバーは、ＲＯＭ１０４、ＲＡＭ１０６またはディスクドライブ１０８にインストールできる命令を含み、この命令はプロセッサ１０２によって実行できる。これらには複数の通信リンク１１４を設けることもでき、これら通信リンクは、１つ以上の計算デバイス、例えばサーバー、パソコン、ターミナル、無線またはハンドヘルドの計算デバイスに種々の態様で接続できる。電話回線または他のタイプの通信リンクを通して、これら複数の通信リンクのうちの少なくとも１つを外部計算ネットワークに接続してもよい。

特定の実施形態では、このデバイスは、ディスクドライブ１０８のような記憶デバイスを含むことができ、この記憶デバイスとして、ソリッドステートドライブ、ハードディスクドライブ、光ドライブまたは磁気テープドライブを挙げることができる。サーバー１００は、単一のディスクドライブを使用してもよいし、または多数のディスクドライブを使用してもよい。サーバー１００は、このサーバー１００のディスクドライブ上またはＲＯＭ内に常駐する適当なオペレーティングシステム１１６も使用できる。

一部の実施形態では、最初のユーザーはクライアントアプリケーション１３０を実行するのに、コンピュータ１２０を利用する。一例におけるこのコンピュータは、ウィンドウズ（登録商標）、ＭＡＣＯＳ（登録商標）またはライナックスオペレーティングシステムのようなオペレーティングシステムを有するインテル／ＡＭＤチップセットを使用するパソコンとしてもよいし、または当業者であれば理解できるように、このコンピュータを計算機能を奏するようになっているＰＡＬＭ（登録商標）またはＩＰＡＱ（登録商標）デバイスのようなモバイルデバイスとしてもよい。

この実施形態では、クライアントアプリケーションは、コンピュータ１２０の記憶デバイスに常駐するようになっているコンピュータ言語で実現されるソフトウェアプログラムとなっている。ＲＯＭ、プログラマブルアレイ、光ドライブ、スマートカード、メモリユニット、不揮発性メモリモジュールに記憶された計算命令を含むが、これらに限定されないクライアントアプリケーション１３０の別の実施例も可能である。一例におけるクライアントアプリケーション１３０は、ユーザーが入力または出力を指示するようになっているインターフェースを有するか、または他の例では、例えばこれらに限定されないがオープンオフィス（登録商標）またはマイクロソフトオフィス（登録商標）のような現在存在するソフトウェアまたはオペレーティングシステムアプリケーションにクライアントアプリケーション１３０が埋め込まれ、これらソフトウェアに対する別の機能が追加されている。

クライアントアプリケーション１３０は、サーバー１００と通信するようになっている通信ポートを有する。ユーザーがアプリケーション１３０を開始すると、アプリケーション１３０は、安全な接続、例えばＳＳＬまたはＳＳＨ接続を介してサーバー１００にコンタクトする。一例では、このアプリケーションは、そのユニークな識別コードまたはＩＰアドレス、もしくはユーザーを識別するためにおよびそのユーザーがオペレートしているコンピュータ１２０を識別するための必要な情報をサーバー１００に送る。これによってサーバー１００は、クライアントアプリケーション１３０とサーバー１００との間の通信セッションを持続できるようになる前に、この通信セッションの認可を許容することにより、データの安全を保護するためのシステムのセキュリティをサーバー１００が管理できるようになる。

一部の実施形態では、図２を参照して説明するように、最初のユーザーは暗号化を必要とするデータを選択するのにクライアントアプリケーション１３０を利用する（２０２）。このデータはファイル１０１、アドレス、ポインタまたはオブジェクトの形態で存在し得る。インターフェースを使用することにより、最初のユーザーは必要なデータをドラッグし、ドロップし、または他の方法で参照したり選択したりすることができる。一旦ファイルが選択されると、クライアントアプリケーション１３０はデータの安全を保護するのに必要なセキュリティプロセスを開始できる。

本明細書に記載の実施形態では、（ファイル、オブジェクト、アドレス、ポインタまたはそれらの任意の組み合わせのいずれかとして存在する）データのすべてを統合し、単一の安全なデータオブジェクト１４０として参照できるように、データをシールし（２０４）、データオブジェクトを作成することにより、セキュリティプロセスがスタートする。安全なデータオブジェクト１４０が一旦作成されると、次に、ユーザーによって安全なデータオブジェクト１４０が記述され、ここでユーザーはオブジェクトを記述するためのパーミションまたはルールも指定できる（２０６）。これらパーミションまたはルールは、データオブジェクト１４０と相互対話または操作できる態様を制御するようになっている。一例では、パーミションは、安全なデータオブジェクト１４０内のデータファイルをリードオンリーまたはプリントオンリーにすることを要求できる。別の例では、これらパーミションまたはルールは、特定タイプのコンピュータソフトウェアを使用する特定のＩＰアドレス内の、どのレベルのユーザーが、これらファイルにアクセスできるかを定めることができる。

最初のユーザーによってそれらパーミションが設定されると、クライアントアプリケーション１３０は安全なデータオブジェクト１４０を受信し、これと相互対話することが認可された受信側ユーザーのリストを提供するアクセス制御リストを第１ユーザーが定めるための機能を提供する（２０８）。このアクセス制御リストは、一例では、受信側ユーザーを認証するのに必要な認証スキームも定めることができる。例えばこの認証スキームは、受信側ユーザーが所定の識別コードを有するコンピュータからオペレート中であること、またはユーザーが特定のローカルネットワークからオペレート中であること、またはある種の生体認証スキャンにより認められていることを要求できる。当業者であれば、受信側ユーザーを認証するための別の変形例も理解することができよう。

この実施形態では、アクセス制御リストの設定時に、クライアントアプリケーション１３０は暗号化プロセスをスタートする（２１０）。一例では、この暗号化プロセスは、ＡＥＳ（高度暗号化規格）、または米国連邦情報処理規格（ＦＩＰＳ）（例えばhttp://www.nist.gov.aes'を参照）、もしくは当業者が理解できるようなその他の暗号化方法を使用する。この暗号化プロセス（２１０）を開始するには、クライアントアプリケーション１３０は自ら暗号化のための鍵を発生するか、もしくはその他の例ではサーバー１００から鍵を検索する。暗号化プロセス中、この鍵はデータオブジェクト１４０によって暗号化されることはなく、よって暗号化された安全データ１４０のオブジェクトは、この鍵を含まない。これによって、強力なレベルの保護を行うことができる。その理由は、安全なデータオブジェクト１４０の暗号を解読したいハッカーは、安全データオブジェクト１４０内に鍵が存在しないので、安全なデータオブジェクト１４０の暗号を解読するのに、力づく方法のような方法を利用できないからである。この暗号化装置は、安全なデータオブジェクト１４０に基づき、別個の、かつ独立したソースから抽出された鍵を有するユーザーしか安全なデータオブジェクト１４０の暗号を解読できないようにする。

暗号化プロセス（２１０）が終了すると、クライアントアプリケーション１３０は完全に暗号化された安全なデータオブジェクト１４０を戻す（２１２）。一例では、ＸＭＬまたは別の適当なコンピュータ言語で実現できる暗号化されたデータファイルをファイルラッパー５００に添付することにより、安全なデータオブジェクト１４０を作成する。一例では、図５に示されるようなファイルラッパー５００は、ユーザーによって、レシーバーアプリケーションまたはクライアントアプリケーションのいずれかによりオブジェクトがオープンにされたとき、安全なデータオブジェクト１４０に関連する情報がアプリケーションに通知され、本明細書で説明したような安全保護プロセスをアシストするように、安全なデータオブジェクト１４０を記述するためのメタデータ５０２を提供する。この安全なデータオブジェクトは、コンピュータ１２０上のメモリ内または記憶デバイス上に常駐するファイルとして記憶される。最初のユーザーは、配信チャンネル１３５を介し、ｅメール、ＦＴＰ、ＳＳＨ、記憶装置、ＣＤ、ＵＳＢデバイス、不揮発性メモリの形態またはその他の電子的フォームで、オブジェクトを配信するオプションを有することができる。

一実施形態では、レシーバーアプリケーション１３２は、安全なデータオブジェクト１４０の暗号を解読するようになっている受信側ユーザーのコンピュータ１２２に常駐する。受信側ユーザーが安全なデータオブジェクト１４０を所有すると、受信側ユーザーはレシーバーアプリケーション１３２をスタートさせ、このレシーバーアプリケーション１３２は、一例ではｅメールソフトウェアに統合でき、よってｅメールにより安全なデータオブジェクト１４０が受信されたときに自動的にスタートする。図３を参照すると、レシーバーアプリケーションはサーバー１００と通信し、サーバー１００との安全な接続を確立する（３０２）。サーバー１００は、認可プロセス（３０４）をスタートし、よって一例では、レシーバーアプリケーション１３２は受信側ユーザーを識別するように、識別コードをサーバーへ送る。

別の例では、認証すべき十分な詳細事項を入力することが受信側ユーザーに求められる。認証される方法は、安全なオブジェクト１４０が作成されたときに最初のユーザーが既に定めた方法であり、この方法は、上記のように生体認証スキャン、パスワード、質問、当業者が理解できるような他の形態の認証を必要としてもよい。

受信側ユーザーの認証に成功したとき（３０４）、レシーバーアプリケーション１３２は、受信側ユーザーに対し、最初のユーザーが許容した特定の権利に対するパーミションおよびアクセスパーミションに関してサーバー１００に問い合わせをする（３０６）。これら権利が一旦受け入れられると、受信側ユーザーは最初のユーザーが定めたパーミションおよびルールでしか相互対話できないように拘束される。受信側ユーザーが安全なデータオブジェクト１４０内のデータファイルのコンテントを見ることしか許容されないような一部の例では、レシーバーアプリケーション１３２によりブラウザが開始される。このブラウザは、ファイルだけをディスプレイするようになっており、受信側ユーザーがファイルを編集するための試みは拒否する。

この実施形態では、レシーバーアプリケーション１３２は、暗号解読プロセス（３０８）をスタートし、このプロセスは、安全なデータオブジェクトを暗号化するのに使用された鍵である、サーバー１００からの暗号解読鍵に対する指示を最初にリクエストする。サーバー１００は、サーバー内に鍵を記憶してもよく、この場合、レシーバーアプリケーション１３２に鍵が送信される。しかしながら一部の例では、別のロケーションにある別個のサーバー内に鍵を記憶してもよく、従ってサーバー１００は、別個のサーバーから鍵を検索するための指示をレシーバーアプリケーション１３２に送るだけである。更に別の例では、別個の記憶メディア、例えばスマートカードまたはＵＳＢ鍵、またはＣＤＲＯＭ内に記憶してもよく、この場合、サーバー１００は鍵を収納している適当な記憶メディアをユーザーが探すことを指示する指示をレシーバーアプリケーションに送る。

レシーバーアプリケーション１３２は、鍵の所有に成功すると（３０８）、安全なデータオブジェクトの暗号を解読（３１０）し、第１ユーザーが定めたパーミションおよびルールによって既に決められた制約を受けた状態でデータを受信側ユーザーに送る。受信側ユーザーがデータに対して行う各操作または相互対話が記録され、記憶およびレビューのためにサーバー１００へログが戻される（３１４）。

図４を参照すると、一部の実施形態では、サーバー１００は次のような多数のサーバーコンポーネントを含むが、これらに限定されるわけではない。
・ゲートキーパーサービス４１０
・認証サービス４１２
・アドミニストレーションサービス４１４
・アイデンティティサービス４１６
・データベースサービス４１８
・バックアップサービス４１９

これらサービスの各々を個々のサーバーに設けてもよいし、または図４に示されるような例では、これらサーバーコンポーネントの各々に機能を提供するよう、サーバー１００内のコンピュータ言語、機械コードまたはＲＯＭで実行されるコンピュータソフトウェアとして存在してもよい。これらサービスの各々は別のサービスと通信し、本発明の一実施形態に従ってデータの安全を保護するためのシステムおよび方法を提供するようなサーバー１００となるように組み合わせられる。

本明細書に記載の実施形態では、クライアントアプリケーションまたはレシーバーアプリケーションがサーバー１００と通信するとき、ゲートキーパーサービス４１０がサーバー１００によるアプリケーション（１３０、１３２）の間のセッションを開始する。一旦開始すると、ゲートキーパーサービス４１０はユーザーを認証するための認証サービス４１２に接続することをアプリケーションに指示する。

ゲートキーパーサービス４１０を通して初期のすべての接続を指示することにより、サーバーでのセキュリティが更に高まる。その理由は、ゲートキーパーサービス４１０は、サーバーコンポーネント４００のセキュリティを脅かし得る悪意および／またはブラックリストに乗ったウェブ接続をフィルタで除去するようになっているからである。当業者であれば、着信トラヒックを分析し得る、ハードウェアおよび／またはソフトウェアのファイアウォールサービスを含むがこれらに限定されないゲートキーパーサービス４１０を実行できる多くの変形例が存在することが理解できよう。

ユーザーコンピュータ１２０、１２２とサーバー１００との間の接続がゲートキーパーサービス４１０の条件を満たした場合、次に認証サービス４１２はユーザーをチェックし、認可しようとする。これを行うには、まずユーザープロフィル、ユーザー認証手段、パスワードなどを含むがこれらに限定されない識別基準のリストを記憶するアイデンティティサービス４１６からの記録を検索するためのサービスを必要とする。このデータが検索された後に、最初のユーザーであるか、または受信側ユーザーとなっているユーザーを認証し、サーバー１００へのサービスを続けなければならない。一部の例では、ユーザーがサーバーコンポーネント４００へのアクセスを続けることができるよう、クライアントセッションを認証し、認可するために、ユーザーがパスワード鍵、プロフィルの詳細を入力することを認証サービス４１２が要求してもよいし、またはこの認証サービスでクライアントのＩＤ、ＩＰアドレス、コンピュータ識別コード、生体認証または識別サービス４１６内のデータとクロスレファレンスできる他の手段を検出してもよい。

この認証サービスの完了に一旦成功すると、サーバー１００は次に、本明細書に記載したデータの安全を保護するためのシステムおよび方法を提供するように、クライアント１３０またはレシーバーアプリケーション１３２のためのリクエストを処理することを続行できる。安全なデータオブジェクト１４０を作成する際の最初のユーザーは、受信側ユーザーが安全なデータオブジェクトと相互対話し、このオブジェクトを操作できる態様を制限するためのパーミションまたはルールを含むことを選択している場合、アドミニストレーションサービス４１４は、入力し、記憶し、実行すべきこれらパーミションおよびルールに対する機能を提供する。

この実施形態では、アドミニストレーションサービス４１４は、受信側ユーザーによるデータオブジェクトのその後の利用を制限する少なくとも１つのパーミションをクライアントアプリケーション１３２が入力し、記憶することを許容する。アドミニストレーションサービスは、最初のユーザーが作成した安全なデータオブジェクトを参照する、クライアントアプリケーション１３０へブロードキャストされるインターフェースを有する。このインターフェースの一例では、最初のユーザーは安全なデータオブジェクト１４０を記述するためのパーミションのリストから選択することができる。これらルールは次のものを含むが、これらだけに限定されるものではない。
・データオブジェクトの読み出し、書き込み、プリントパーミション
・データオブジェクトのコピーパーミション
・データオブジェクトの共用
・データオブジェクトの再配信
・データオブジェクトにアクセスするために認められる特定の時間
・データオブジェクトにアクセスすることが認められる人または人のグループ
・誰が、もし存在する場合どんな状況でデータオブジェクトのバックアップが許容されるか
・データオブジェクトにアクセスすることが許容されているコンピュータのネットワークロケーションまたは地理的ロケーション

最初のユーザーによって一旦ルールが確定すると、このユーザーはインターフェースを介してルールをセーブすることを選択できる。ユーザーは安全なデータオブジェクト１４０を参照し、ルールおよびパーミションをデータベースに記録するよう、データベースサービス４１８をトリガーする受け入れボタンまたはスイッチを選択できる。当業者であれば理解できるように、このデータベースはリレーショナルデータベースマネージメントシステム（ＲＤＢＭＳ）、例えばオラクル（登録商標）またはマイクロソフトアクセス（登録商標）、オブジェクト指向データベースシステム、フラットファイルまたは他のファイル構造を含むが、これらに限定されない。データベースにルールおよびパーミションが一旦書き込まれと、受信側ユーザーが参照した安全なデータオブジェクトにアクセスするときにこれらルールおよびパーミションを検索できる。

図２および３に概略が示されたプロセスを参照し、システムの作動について説明する。まず最初のユーザーが暗号化し、配信しなければならないデータを準備し、選択する。このデータは、例えばドキュメント、スプレッドシート、ｅメール、テキスト、グラフィックス、マルチメディア、または他の形態のコンピュータデータを含む１つ以上のデータファイル内に存在し得る。このデータの選択時に、最初のユーザーは、クライアントアプリケーション１３０をオープンにする。このクライアントアプリケーションは、一例では、この最初のユーザーのコンピュータ（２０２）で作動するソフトウェアアプリケーションとして存在する。このアプリケーションが一旦開始されると、クライアントモジュールは接続の完全性を証明するのにゲートキーパーサービスが一連のチェックを実行するようになっているサーバー１００にコンタクトする（２０３）。ゲートキーパー４１０が接続を許容した場合、安全なオブジェクトの許可された作成者としてユーザーを識別できるよう、ユーザーを認証するために認証サービス４１２が実行される。認証サービスの条件の一致（例えばパスワード、鍵または生体認証スキャンの入力）により、ユーザーが正式に認可されると、クライアントアプリケーションはサーバー１００との接続を維持し続け、安全なデータオブジェクトを形成するために、暗号化を必要とするデータファイルをユーザーが追加できるようにする。一部の例では、ユーザーは１つ以上のファイルをクライアントアプリケーション１３２のインターフェース内にドラッグし、ファイルを組み合わせて単一のデータオブジェクトを形成するよう、データオブジェクトをクローズすることを選択できる（２０２）。

この実施形態では、サーバーのアドミニストレーションサービス４１４に最初のユーザーが向けられ、最初のユーザーに対し、受信側ユーザーによってデータオブジェクト１４０を操作できる態様を記述するための機会が与えられる。一例では、最初のユーザーはインターフェースにアクセスし、この最初のユーザーにはデータオブジェクトを操作する態様を制御するための種々のルールおよびパーミションが提供される。これらオプションの一部の例は既に説明したとおりである。これらルールおよびパーミションは、受信側ユーザーにより、安全なデータオブジェクト１４０にアクセスするのに使用されるレシーバーアプリケーション１３２によって実行される。これらルールおよびパーミションが一旦入力され、選択された場合、ユーザーはサーバー１００のデータベースサービスによりデータベースに書き込むべきルールをトリガーする受け入れスイッチまたはボタンを選択できる。パーミションがデータベースに書き込まれるようになっているこの例では、パーミションはアクセス制御リスト（ＡＣＬ）のフォームで書き込まれ（２０８）、このリストは次にサーバー１００のデータベースサービス４１８により再び記憶される。

データファイルまたはオブジェクトのためのパーミションおよびルールの選択を完了すると、ユーザーはオブジェクトを暗号化できる（２１０）。一例では、クライアントアプリケーション１３０は、次に、安全なデータオブジェクトを形成するよう、データを暗号化するための鍵を作成する。暗号化プロセスは、自らの安全オブジェクトがいかなる方法でも暗号化鍵を明らかにすることがないよう、安全なデータオブジェクト内に鍵が埋め込まれないことを保証するものである。別の例では、クライアントアプリケーション１３０は、サーバー１００から鍵をリクエストし、この鍵はデータの暗号化に適したランダム鍵を発生する。サーバー１００に鍵を記憶するためのオプションがユーザーに与えられるか、またはサーバー以外の場所に鍵を記憶し、かつ認可された正式な受信側ユーザーを鍵に向けることができるよう、鍵が記憶されている場所をサーバー１００に表示するためのオプションがユーザーに与えられる。このような仕組みは、サーバー１００に記憶される鍵の数を少なくし、よって他のサーバーに対する、セキュリティが侵されるリスクの広がりを低減する。このプロセスでは、ハッカーは適当な鍵を探すことに対する更なるハードルを有することになる。その理由は、どの不正なユーザーも鍵のロケーションについて即座に知ることができないからである。

最初のユーザーが選択したデータを一旦クライアントアプリケーションが暗号化した場合、クライアントアプリケーション１３０により安全なデータオブジェクトが形成される。暗号化プロセスの完了時（２１０）、配信チャンネル１３５を通して任意の数の受信側ユーザーに対し、安全にされたデータオブジェクト１４０を配信する準備が完了する。一部の例では、最初のユーザーは、単一または多数の受信者に対し、安全なオブジェクトを簡単にｅメールで送るか、またはコンパクトディスク、ユニバーサルシリアルバス（ＵＳＢ）鍵または他のコンピュータで読み取り可能なメディアで配信できる。ハッカーはデータオブジェクトの暗号を解読するための鍵を発見しなければ、安全なデータオブジェクト１４０を破ることが極端に困難であることを知るので、この仕組みの直接の利点により、ユーザーが安全でないチャンネルを通して安全なオブジェクトを配信することが可能となる。安全なデータオブジェクト１４０内に暗号化鍵が存在しないように、安全なデータオブジェクト１４０が暗号化されているので、よって安全なデータオブジェクト１４０の暗号を解読することは極めて困難となる。

受信側ユーザーによる安全なデータオブジェクトの受信時に、受信側ユーザーは前に述べたように、レシーバーアプリケーション１３２を開始し、安全なデータオブジェクト１４０をレシーバーアプリケーション１３２へロードできる。一部の例では、このことは安全なデータオブジェクト１４０を選択し、レシーバーアプリケーション１３２によって提供されるインターフェース内にこのオブジェクトをドラッグし、ドロップしなければならないようにできる。別の例では、現在存在するソフトウェアパッケージ、例えばマイクロソフトワード（登録商標）、エクセル（登録商標）、パワーポイント（登録商標）、アクセス（登録商標）またはインターネットエクスプローラ（登録商標）または他の同様なパッケージにレシーバーアプリケーションを統合してもよい。安全なデータオブジェクト１４０のロードに成功すると、次にレシーバーアプリケーション１３２が中央サーバー１００に接続されたときに、受信側ユーザーが、この中央サーバーによって認証される。この認証は、物理的なスマートカード、ＵＳＢ鍵、生体認証データ、パスワード、ユーザーのコンピュータ上にあるユニークなＩＤ、ＩＰアドレス、またはこれらの任意の組み合わせを含むこれらのいずれかを準備して、または利用できる他の証明技術によって行うことができる。受信側ユーザーの認可および認証に成功すると、レシーバーアプリケーション１３２は、サーバー１００と通信し、暗号解読鍵にアクセスすることが指示される。この暗号解読鍵はサーバー１００に記憶してもよい。しかしながら、一部の状況では、サーバーは鍵をセーブできる適当な別個のロケーションに対するポインタを記憶するだけでよい。一例では、安全なデータオブジェクトに対し、別個に配信されたその後のスマートカードが暗号解読鍵を記憶してもよい。いずれの場合にせよ、中央サーバー１００が暗号解読鍵を検索するために、受信側ユーザーを適当なロケーションに向ける。これを行うには、受信側ユーザーの一部で別の動作、例えば別個のサーバーにアクセスするか、または鍵を含む物理的メディアを探すこと（例えばスマートカードをコンピュータ１２２に挿入すること）を必要とし得る。暗号解読鍵の取得に一旦成功すると、次にレシーバーアプリケーション１３２は、安全なデータオブジェクト１４０の暗号を解読でき、ユーザーが安全なデータオブジェクト１４０を操作するのを可能にするが、この操作は、最初のユーザーが設定し得たパーミションおよびルールによって制限される。最初のユーザーが安全なデータオブジェクト内に暗号化されたドキュメントを編集できる受信側ユーザーの能力を制限しているような例では、受信側ユーザーは、ドキュメントを変更したり、この変更をセーブすることはできず、受信側ユーザーは、ドキュメントの読み取り、ドキュメントへのアクセス、ドキュメントのプリントしかできないよう制限される。

別の実施形態では、安全なデータオブジェクトは、図６に示されるような安全なエンベロープとして存在できる。安全なデータオブジェクトが安全なエンベロープ６００である場合、このエンベロープは安全なエンベロープ６００内に記憶される個々のデータファイル６０２をエンクローズするファイルとして記憶される。このエンベロープは、前に説明したような安全なデータオブジェクトの元で完全に保護される。しかしながら、エンベロープ内のファイルが、一旦安全なエンベロープからユーザーのコンピュータインターフェース（例えばデスクトップもしくは自らのファイルシステム）にドラッグされ、除かれると、現在のシステム６１０によって実行されているような制御および保護が取り消され、受信側ユーザーはファイルのアウトライト６０５を所有していた場合に許容されるように、受信側ユーザーがデータファイルと完全に相互対話し、このデータファイルを操作できるようにする。この例では、最初のユーザーは、受信側ユーザーが安全なエンベロープからデータファイルを除くことができないようにすることを保証するためのパーミションを作成できる。

安全なデータオブジェクトが安全なドキュメント７００として存在する別の実施形態では、図７を参照して説明するようなシステムおよび方法を使ってデータファイル自身が暗号化される。この場合、クライアントアプリケーションだけを通して全体のファイル７０２にアクセスしなければならず、許可されていない場合、このファイルを受信側ユーザーによって配信したり、完全なコピーをすることはできない。

上記実施形態は、いかなる態様においても、暗号化すべきデータと相互対話しないことが好ましい。換言すれば、暗号化すべきデータが「通過」することは決してないし、また中央ソースに記憶されることもない。このような仕組みにより、ハッカーを引き寄せる可能性のあるデータの中心ハブを提供する危険性が除かれる。

一部の実施形態では、このシステムはウェブまたはオンラインインターフェース上のユーザーに対するサービスとして提供される。この実施形態では、既に述べたステップに従ってデータオブジェクトを暗号化したり、暗号を解読したりするためのアプリケーション１３０をダウンロードしたりオペレートするライセンスがユーザーに提供される。このライセンスはアプリケーション１３０の機能を制限できる。一例では、フリーライセンスはアプリケーション１３０をファイルの暗号解読だけに限定するが、料金を支払えば、アプリケーション１３０がファイルを暗号化することを許容するようにライセンスを拡張することもできる。別の例では、ライセンスは暗号化または暗号解読できるファイルのタイプを制限し、よって所定のファイルへのユーザーのアクセスを制限する。この例は、所定のデータオブジェクトを暗号化したり、暗号を解読するための異なるライセンスを各ユーザーに付与できるようになっている会社またはグループ環境で特に有効である。

必要ではないが、図を参照してこれまで説明した実施形態は、アプリケーションプログラミングインターフェース（ＡＰＩ）を介して、またはデベロッパーが使用するための一連のライブラリーとして実現し、別のソフトウェアアプリケーション、例えばターミナルまたはパソコンのオペレーティングシステム、またはポータブル計算デバイスのオペレーティングシステム内に含まれるようにすることもできる。一般に、プログラムモジュールはルーチン、プログラム、オブジェクト、コンポーネントおよび特定の機能の作動を実行し、またはシフトするデータファイルを含むので、ソフトウェアアプリケーションの機能を多数のルーチン、オブジェクトまたはコンポーネントにわたって分散させ、実施形態および本明細書に請求するより広義の発明と同じ機能を達成することができことが理解できよう。かかる変形例および変更例は、当業者が想到できる範囲内にある。

本発明の方法およびシステムが計算システムによって実現されるか、または一部が計算システムによって実現される場合、適当な計算システムアーキテクチャを利用できることも理解できよう。この計算システムは、スタンドアローンコンピュータ、ネットワークコンピュータおよび専用計算デバイスを含む。「計算システム」および「計算デバイス」なる用語を使用する場合、これら用語は上記機能を奏するためのコンピュータハードウェアの任意の適当な構造をカバーするものである。

１００サーバー
１０２プロセッサ
１０４リードオンリーメモリ
１０６ランダムアクセスメモリ
１０８入出力デバイス
１１０入力デバイス
１１２ディスプレイ
１１４ディスプレイおよび通信リンク
１２０コンピュータ
１２２ユーザーのコンピュータ
１３０クライアントアプリケーション
１３２レシーバーアプリケーション
１３５配信チャンネル
１４０データオブジェクト
４１０ゲートキーパーサービス
４１２認証サービス
４１４アドミニストレーションサービス
４１６アイデンティティサービス
４１８データベースサービス
５００ファイルラッパー
５０２メタデータ

Claims

最初のユーザーにより少なくとも一人の受信側ユーザーに配信されるデータの安全を保護するための方法であって、
鍵で前記データを暗号化するための、前記最初のユーザーからのリクエストに応答するステップと、
前記鍵のロケーションをデータベースに記録するステップとを備え、前記データベースは、前記少なくとも一人の受信側ユーザーからの認可のためのリクエストを受信すると、前記認可時に前記鍵を前記少なくとも一人の受信側ユーザーに提供する、前記データの安全を保護するための方法。
前記少なくとも一人の受信側ユーザーの前記データとの相互対話を制限するようになっているルールを、前記データベースが受信する別のステップを備える、請求項１に記載の方法。
前記認可するステップは、
前記少なくとも一人の受信側ユーザーの識別プロフィルと所定の基準とを比較するステップを更に備え、前記所定の基準が前記識別プロフィルに一致する場合に、前記少なくとも一人の受信側ユーザーを認可する、請求項１または２に記載の方法。
前記識別プロフィルは、前記少なくとも一人の受信側ユーザーの特性の特徴を定める少なくとも１つの基準を含む、請求項３に記載の方法。
前記最初のユーザーは、中央ソースから鍵をリクエストするようになっているクライアントアプリケーションと相互対話する、請求項１〜４のうちのいずれか１項に記載の方法。
前記少なくとも一人のユーザーは、前記データの暗号を解読する認可を前記中央ソースからリクエストするようになっている少なくとも１つのレシーバーアプリケーションと相互対話する、請求項５に記載の方法。
前記中央ソースのいずれか１個または前記クライアントアプリケーションにより前記鍵を発生する、請求項１〜６のうちのいずれか１項に記載の方法。
前記中央ソースは、認可されていない不正なユーザーから前記サーバーを保護するようになっているゲートキーパーサービスを含む、請求項１〜７のうちのいずれか１項に記載の方法。
前記中央ソースは、前記受信側ユーザーにより、前記データにアクティビティをログするようになっているロギングサービスを更に含む、請求項８に記載の方法。
前記データは、暗号化されたデータストリングとしてファイルラッパー内に含まれる、請求項１〜９のうちのいずれか１項に記載の方法。
前記ファイルラッパーは、前記レシーバーアプリケーションによって処理されるようになっている安全なドキュメントである、請求項１０に記載の方法。
前記データが、このデータをエンクローズするようになっている安全なエンベロープ内にあるときに、前記少なくとも一人の受信側ユーザーの前記データとの相互対話が、前記最初のユーザーが定めたルールによって制限されるよう、前記データオブジェクトには前記データをエンクローズするようになっている安全なエンベロープが設けられている、請求項１０または１１に記載の方法。
最初のユーザーにより少なくとも一人の受信側ユーザーに配信されるデータの安全を保護するためのシステムであって、
鍵で前記データを暗号化するための、前記最初のユーザーからのリクエストに応答するモジュールと、
前記鍵のロケーションをデータベースに記録するようになっているルーチンとを備え、前記データベースは、前記少なくとも一人の受信側ユーザーからの認可のためのリクエストを受信すると、前記認可時に前記鍵を前記少なくとも一人の受信側ユーザーに提供する、前記データの安全を保護するためのシステム。
前記データベースは、前記少なくとも一人の受信側ユーザーの前記データとの相互対話を制限するルールを受信するようになっている、請求項１３に記載のシステム。
前記ルーチンは、前記所定の基準が前記識別プロフィルに一致する場合に、前記少なくとも一人の受信側ユーザーを認可するよう、前記少なくとも一人の受信側ユーザーの識別プロフィルと所定の基準とを比較する、請求項１３または１４に記載のシステム。
前記識別プロフィルは、前記少なくとも一人の受信側ユーザーの特性を特徴付ける少なくとも１つの基準を含む、請求項１５に記載のシステム。
前記最初のユーザーは、中央ソースからの鍵をリクエストするようになっているクライアントアプリケーションと相互対話する、請求項１５〜１６のうちのいずれか１項に記載のシステム。
前記少なくとも一人のユーザーは、前記データの暗号を解読する認可を前記中央ソースからリクエストするようになっている少なくとも１つのレシーバーアプリケーションと相互対話する、請求項１７に記載のシステム。
前記中央ソースまたは前記クライアントアプリケーションにより前記鍵を発生する、請求項１５〜１８のうちのいずれか１項に記載のシステム。
前記中央ソースは、認可されていない不正なユーザーから前記サーバーを保護するようになっているゲートキーパーサービスを含む、請求項１５〜１９のうちのいずれか１項に記載のシステム。
前記中央ソースは、前記受信側ユーザーにより、前記データにアクティビティをログするようになっているロギングサービスを更に含む、請求項２０に記載のシステム。
前記データは、暗号化されたデータストリングとしてファイルラッパー内に含まれる、請求項１５〜２１うちのいずれか１項に記載のシステム。
前記ファイルラッパーは、前記レシーバーアプリケーションによって処理されるようになっている安全なドキュメントである、請求項２２に記載のシステム。
前記データが、このデータをエンクローズするようになっている安全なエンベロープ内にあるときに、前記少なくとも一人の受信側ユーザーの前記データとの相互対話が、前記最初のユーザーが定めたルールによって制限されるよう、前記データオブジェクトには前記データをエンクローズするようになっている安全なエンベロープが設けられている、請求項２２または２３に記載のシステム。
請求項１〜１２のうちのいずれか１項に記載の方法を実施するよう、コンピュータシステムを制御するための少なくとも１つの命令を含むコンピュータプログラム。
請求項２５に記載のコンピュータプログラムを提供する、コンピュータで読み取り可能なメディア。