固定コンテンツ分散型データ記憶システムにおけるデータ機密保持方法
好ましくは対称的なノードから成るアーカイブ記憶クラスタは機密共有によってキー管理を行なうデータ機密保護スキームを含む。１つの実施態様では、保護スキームをインストールに行う。インストール時に暗号化キーが生成し、分断され、それぞれの断片がアーカイブ・ノードに書き込まれる。盗まれたり、悪用されたりすることがないように、キーがドライブに書き込まれることはない。機密が割り振りされるスキームであるから、クラスタがドライブを実装する前にｎ個のノードのうちのｔ個が存在しなければならない。即ち、クラスタが起動する前に、キーを復元するためのプロセスが実行される。このプロセスは、充分なｔ値に達するまでできる限り多数のノードと接触する。充分なｔ値に達したら、プロセスはキーを復元し、局所的にドライブを実装する。双方向通信の場合、ｔ個のノードすべてにおいてこの実装がほぼ同時に行なわれる。ドライブが実装されると、クラスタは通常通りに作動を続けることができる。
【発明の詳細な説明】
【関連出願の相互参照】
【０００１】
本願は２００７年５月７日付け米国特許出願第６０／９１６，４７８号に基づく。
【０００２】
本願は２００５年７月２７日付け米国特許出願第１１／１９０，４０２号「固定コンテンツ分散型データ記憶のためのメタデータ管理」および２００６年１２月１３日付け米国特許出願第１１／６３８，２５２号「独立ノードの冗長アレイのポリシーに基づく管理」に関連の出願である。
【発明の背景】
【０００３】
【技術分野】
【０００４】
本発明は分散型コンピュータ・ネットワークにおける可用性、信頼性および耐久性に優れたデータ記憶技術に係わる。
【関連技術の説明】
【０００５】
従来のテープおよび光学的媒体による記憶方法に代わる、またはこれを補完する方法として、可用性、信頼性および耐久性に優れた「固定コンテンツ」のアーカイブ記憶システムに対する需要が高まっている。「固定コンテンツ」とは典型的には参照などのため、変化することなく記憶されるべきディジタル情報を指す。このようなディジタル情報の例として、ｅ-メール、書類、診断画像、チェック画像、音声記録、フィルム、ビデオなどが挙げられる。従来の独立ノード冗長アレイ（ＲＡＩＮ）記憶アプローチはこのような固定コンテンツ情報資産を記憶する大規模なオンライン・アーカイブを構成するための選択アーキテクチャーとして出現した。ノードが必要に応じてクラスタに結合および離脱できるようにすることによってＲＡＩＮアーキテクチャーは記憶クラスタを１つまたは２つ以上のノードの故障から隔離する。複数のノードにデータを複製することによってＲＡＩＮ-タイプのアーカイブはノートの故障または撤去を自動的に補償することができる。典型的には、ＲＡＩＮシステムは閉システム内において共通の部品で構成されたハードウェア装置として広く配布される。
【０００６】
図１は拡張可能なこの種の、ディスクに基づくアーカイブ記憶管理システムを示す。ノードは異なるハードウェア、即ち「異種」ハードウェアから構成することができる。ノードは典型的には１つまたは２つ以上の記憶ディスク、例えば、実際の物理的記憶ディスクや、記憶領域ネットワーク（ＳＡＮ）に含まれるような仮想記憶ディスクへのアクセス有する。それぞれのノードにおけるアーカイブ・クラスタ・アプリケーション（および場合によってはアプリケーションが実行される基本オペレーティング・システム（基本ソフト））は同じでもよいし、実質的に同じでもよい。それぞれのノードにおける（オペレーティング・システムを含むこともできる）ソフトウェアは対称であるが、ハードウェアは異種であってもよい。このシステムを利用することによって、図１に示すように、企業は書類、ｅ-メール、衛星画像、診断画像、チェック画像、音声記録、ビデオなど多様な固定コンテンツ情報の恒久的な記憶ファイルを作成することができる。言うまでもなく、これらの情報タイプは例に過ぎない。高レベルの信頼性は独立サーバー、またはいわゆる記憶ノードにおいてデータを複製することによって達成される。それぞれのノードはピアと対称であることが好ましい。即ち、好ましい態様では所与のノードがすべての機能を発揮できるから、どれか１つのノードが故障してもアーカイブの可用性には殆ど影響しない。
【０００７】
共有の米国特許第７，１５５，４６６号に記載されているように、ＲＡＩＮ方式のアーカイブ・システムにおいて、ディジタル資産を捕捉し、保存し、管理し、検索する分散型
ソフトウェア・アプリケーションをそれぞれのノードに組み込むことは公知である。図２はそのようなシステムの１例を示す。個々のアーカイブの物理的境界をクラスタと呼称する。典型的には、クラスタは単一デバイスではなく、デバイスの集合体である。典型的なデバイスはコンピュータまたはＬｉｎｕｘのようなソフトを運用するマシーンである。商品ハードウェアをホストとするＬｉｎｕｘ系方式システムのクラスタは数個の記憶ノード・サーバーから数千テラバイトのデータを記憶する厖大な数のノードにまで拡張可能なアーカイブを提供する。このアーキテクチャーでは、組織の増大するアーカイブ需要に記憶容量が対応することができる。
【発明の概要】
【０００８】
本発明は拡張可能なアーカイブ記憶管理システムにおけるデータの機密保持機能を向上させる技術を提供する。１つの実施態様においては、アーカイブに記憶されるコンテンツ（および、必要ならメタデータも）をユーザーには見えないように暗号化することによってこの目的を達成する。こうすることによって、コンテンツ（および/またはメタデータ）が盗まれたアーカイブ媒体（例えば、ディスク）から再生されたり、アーカイブへのアクセスを許された第三者（例えば、技術者、またはその他のサービス要員）によって不正に取得されたりすることが防止される。
【０００９】
図示例では、機密保持スキームとして、「機密共有」プロトコルに基づく分散型キー管理を採用する。機密共有の基本的なアイデアは、機密（即ち、キー）をｎ個の部分に分断し、これらｎ個の断片のうちのｔ個を利用することによってキーを復元できる、というものである。好ましくは、機密保持スキームをインストール時に行なう。具体的には、この時点において暗号化キーが生成し、分断され、それぞれの断片がアーカイブ・ノードに書き込まれる。断片が割当てられた後、キーをプリントしてもよいが、多くの場合、クラスタのディスクに記憶させることはない。このようにすれば、盗難などのおそれがあるドライブにキーが書き込まれることがない。この実施態様では、こうしてキーが生成し、一連の割当分に分割され、それぞれの割当分が個々のノードへ送信される。上述したように、機密が割り振りされるスキームであるから、クラスタがドライブを実装する前にｎ個のノードのうちのｔ個が存在しなければならない。即ち、クラスタが起動する前に、キーを復元するためのプロセスが行なわれる。このプロセスでは、充分なｔ値に達するまでできる限り多数のノードと接触する。充分なｔ値に達したら、プロセスはキーを復元し、局所的にドライブを実装する。双方向通信の場合、ｔ個のノードすべてにおいてこの実装がほぼ同時に行なわれる。ドライブが実装されると、クラスタは通常通りに作動を続けることができる。
【００１０】
以上、本発明の特徴を述べたが、飽くまでも説明のための概要であり、以下に説明するように実施態様を変えることによって、上記以外の有益な成果を挙げることができる。
【００１１】
本発明の詳細と利点を添付の図面を参照しながら以下に説明する。
【図面の簡単な説明】
【００１２】
【図１】図１は本発明を実施することができる固定コンテンツ記憶アーカイブの簡略化したブロックダイヤグラムである。
【図２】図２はそれぞれが対称であり、本発明のアーカイブ・クラスタ・アプリケーションを備えた独立ノードの冗長アレイを示す簡略図である。
【図３】図３は所与のノードにおいて実行されるアーカイブ・クラスタ・アプリケーションの種々の構成コンポーネントの高レベルの図解である。
【図４】図４は本発明のキー生成プログラムのアウトプットを示す。
【図５】図５は本発明のシステムによる暗号化の表示形式を示す。
【図６】図６は実施例を構成するプログラムを示す。
【図示実施例の詳細な説明】
【００１３】
本発明の方法を実施する図２に示す好ましい実施例は大別して下記のコンポーネントから成る：ノード２０２、１対のネットワーク・スイッチ２０４、配電ユニット（ＰＤＵ）２０６、および無停電電源（ＵＰＳ）２０８。ノード２０２は典型的には１つまたは２つ以上の商品サーバーから成り、ＣＰＵ（適当なランダム・アクセス・メモリ（ＲＡＭ）、例えば、Ｉｎｔｅｌ×８６）、１つまたは２つ以上のハード・ドライブ（例えば、標準的なＩＤＥ/ＳＡＴＡ、ＳＣＳＩなど）、および２つまたは３つ以上のネットワーク・インターフェース・カード（ＮＩＣ）を含む。典型的なノードは２．４ＧＨｚチップ、５１２ＭＢＲＡＭ、および６個の２００ＧＢハード・ドライブを実装された２Ｕラックである。但し、これに限定されることはない。ネットワーク・スイッチ２０４は典型的にはノード間のピア対ピア通信を可能にする内部スイッチ２０５と、それぞれのノードへのエクストラ-クラスタ・アクセスを可能にする外部スイッチ２０７から成る。それぞれのスイッチはクラスタに含まれるすべてのノードに対応するのに充分な数のポートを必要とする。この目的にはＥｔｈｅｒｎｅｔまたはＧｉｇＥスイッチを使用することができる。すべてのノードおよびスイッチへの給電にはＰＤＵ２００を使用し、すべてのノードおよびスイッチを保護するためにＵＰＳ２０８を使用する。限定するものではないが、典型的には、クラスタをネットワーク、例えば、公衆通信回線、企業インターネット、またはその他の広域ネットワークまたはローカル・エリア・ネットワークに接続可能である。図示実施例の場合、クラスタは企業環境内に実装される。クラスタには、サイトの企業ドメイン・ネーム・システム（ＤＮＳ）ネーム・サーバーを介してナビゲートすることによって到達することができる。例えば、クラスタのドメインが既存のドメインの新しいサブドメインである場合がある。代表的な実施態様においては、企業ＤＮＳサーバーはサブドメインをクラスタ自体内のネーム・サーバーに任せる。エンド・ユーザーは公知のインターフェースまたはアクセス・ツールを使用してクラスタにアクセスする。例えば、クラスタへのアクセスはＩＰ系プロトコル（ＨＴＴＰ、ＦＴＰ、ＮＦＳ、ＡＦＳ、ＳＭＢ、Ｗｅｂサービス、など）に従って、またはＡＰＩを介して、またはその他の公知の、またはその後開発されたアクセス方法、アクセス・サービス、アクセス・プログラムまたはツールを介して行なうことができる。
【００１４】
クライエント・アプリケーションは例えば標準的なＵＮＩＸファイル・プロトコル、ＨＴＴＰＡＰＩのような１種または２種以上の外部ゲートウェイを介してクラスタにアクセスする。アーカイブは好ましくは任意に標準的なＵＮＩＸファイル・プロトコルに従って動作させることができる仮想ファイル・システムを介して露出させることが好ましい。例えば、ＮＦＳ、ＦＴＰ、ＳＭＢ/ＣＩＦＳなどが挙げられる。
【００１５】
１つの実施態様として、アーカイブ・クラスタ・アプリケーションは（例えば、Ｅｔｈｅｒｎｅｔを介して）クラスタとしてネットワーク化される複数の独立ノード（Ｈ-ＲＡＩＮ）において進行する。所与のノードのハードウェアは異機種であってもよい。但し、最大限の信頼性を達成するためには、好ましくはそれぞれのノードが、図３に示すように幾つかのランタイム・コンポーネントから成る（同じか、または殆ど同じ）分散アプリケーションのインスタンス３００を実行する。即ち、ハードウェアは異機種であってもよいが、（少なくとも本発明に関する限り）ノードにおけるソフトウェア・スタックは同じである。これらのソフトウェア・コンポーネントはゲートウエイ・プロトコル層３０２、アクセス層３０４、ファイル・トランザクションおよび管理層３０６、およびコア・コンポーネント層３０８を含む。「層」は説明の便宜上の呼称であり、当業者には明らかなように、他の呼称で機能を特徴付けることも可能である。層（またはこれに含まれるコンポーネント）の１つまたは２つ以上を一体化してもしなくてもよい。コンポーネントによってはそれぞれの層に配分してもよいものがある。
【００１６】
ゲートウェイ・プロトコル層３０２におけるゲートウェイ・プロトコルは既存のアプリケーションを不可視化する。具体的には、ゲートウェイはＮＦＳ３１０およびＳＭＢ/ＣＩＦＳ３１２のようなネイティブ・ファイル・サービスと共にＷｅｂサービスＡＰＩを提供することによってカスタム・アプリケーションを構成する。ＨＴＴＰサポート３１４も含まれる。アクセス層３０４はアーカイブへのアクセスを可能にする。具体的には、本発明では、固定コンテンツ・ファイル・システム（ＦＣＦＳ）３１６はネイティブ・ファイル・システムをエミュレートしてアーカイブ・オブジェクトへのフル・アクセスを可能にする。ＦＣＦＳはアプリケーションを、あたかも普通のオブジェクトであるかのようにアーカイブ・コンテンツへ直接アクセスさせる。好ましくは、メタデータをファイルとして表示しながら、アーカイブ・コンテンツを原型に戻す。ＦＣＦＳ３１６はディレクトリ、認証およびルーチン・ファイル-レベル呼出しの型通りのビューを提供するから、管理者は手馴れた方法で固定コンテンツ・データを提供することができる。ファイル・アクセス呼出しをユーザー-スペース・デーモンが傍受してこれを、呼出しアプリケーションに適切なビユーを動的に生成させる（層３０８における）該当のコア・コンポーネントに転送することが好ましい。ＦＣＦＳ呼出しをアーカイブ・ポリシーによって規制することにより自主的なアーカイブ管理を容易にすることが好ましい。即ち、１例として、管理者またはアプリケーションは保持期間（所与のポリシー）が未だ有効なアーカイブ・オブジェクトを消去できない。
【００１７】
アクセス層３０４は好ましくはＷｅｂユーザー・インターフェース（ＵＩ）３１８およびＳＮＭＰゲートウェイ３２０をも含む。Ｗｅｂユーザー・インターフェース３１８はファイル・トランザクション/管理層３０６における管理エンジン３２２への対話式アクセスを可能にする管理者コンソールとして構成されていることが好ましい。管理コンソール３１８はアーカイブ・オブジェクトおよび個別ノードを含むアーカイブの動的なビューを提供する、パスワードで保護されたＷｅｂ系ＧＵＩであることが好ましい。ＳＮＭＰゲートウェイ３２０は記憶管理アプリケーションが管理エンジン３２２にアクセスしてクラスタの活動を確実にモニターし、制御することを容易にする。管理エンジンはシステムおよびポリシー事象を含むクラスタの活動をモニターする。ファイル・トランザクション/管理層３０６はリクエスト・マネジャー・プロセス３２４をも含む。リクエスト・マネジャー３２４は（アクセス層３０４を介して）外界からのすべてのリクエストを、さらにはコア・コンポーネント層３０８に含まれるポリシー・マネジャー３２６からの内部リクエストをも調整する。
【００１８】
コア・コンポーネントはポリシー・マネジャー３２６のほかに、メタデータ・マネジャー３２８と、記憶マネジャー３３０の１つまたは２つ以上のインスタンスをも含む。メタデータ・マネジャー３２８はそれぞれのノードにインストールされていることが好ましい。クラスタに含まれるこれらメタデータ・マネジャーが全体で分散データベースとして作用し、すべてのアーカイブ・オブジェクトを管理する。所与のノードにおいて、メタデータ・マネジャー３２８はアーカイブ・オブジェクトのサブセットを管理し、好ましくそれぞれのオブジェクトが外部ファイル（「ＥＦ」、記憶のためアーカイブに入力されるデータ）と、内部ファイル群（それぞれが「ＩＦ」）との間で、アーカイブ・データの物理的位置をマップする。同じメタデータ・マネジャー３２８が他のノードから複写されるアーカイブ。オブジェクト群をも管理する。即ち、すべての外部ファイルの現状を、幾つかのノードにおける複数のメタデータ・マネジャーが常時把握することができる。ノードに故障が発生しても、残りの正常なノードにおけるメタデータ・マネジャーが、それまで故障ノードに管理されていたデータへのアクセス継続を可能にする。このイオペレーションをさらに詳細に後述する。記憶マネジャー３３０は分散アプリケーションにおけるすべての他のコンポーネントがファイル・システム層を利用できるようにする。好ましくは、ノードのローカル・ファイル・システムにデータ・オブジェクトを記憶する。所与のノードにおけるそれぞれのドライブはそれ自体の記憶・マネジャーを有することが好ましい。記憶
・マネジャー３３０はシステム情報、データのインテグリティ・チェックをも提供し、ローカル・ディレクトリ構造を検討することもできる。
【００１９】
図３に示すように、クラスタは通信ミドルウェア層３３２およびＤＮＳマネジャー３３４を介して内部および外部通信を管理する。インフラストラクチャー３３２はアーカイブ・コンポーネント間の通信を可能にする有効且つ信頼できるメッセージ系ミドルウェア層である。図示実施例では、この層がマルチキャスト通信および２点間通信を可能にする。ＤＮＳマネジャー３３４はすべてのノードを企業サーバーに接続する分散ネーム・サービスを行なう。好ましくは、ＤＮＳマネジャーは（単独で、またはＤＮＳサービスと協働して）すべてのノードを横切るリクエストを負荷平衡させることによってクラスタの処理能力と利用可能性を最大にする。
【００２０】
図示実施例では、ＡｒＣアプリケーション・インスタンスが例えばＲｅｄＨａｔＬｉｎｕｘ９．０、ＦｅｄｏｒａＣｏｒｅ６などのようなベース・オペレーティング・システムにおいてで実行される。通信ミドルウェアは公知の分散型通信メカニズムである。その他のコンポーネントとして、固定コンテンツ・ファイル・システム（ＦＣＦＳ）３１６のために使用できるＦＵＳＥ（ＵＳＥｒｓｐａｃｅにおけるＦｉｌｅｓｙｓｔｅｍを含むことができる。ＮＦＳゲートウェイ３１０は標準的なｎｓｆｄＬｉｎｕｘＫｅｒｎｅｌＮＦＳドライバーによって構成することができる。それぞれのノードにおけるデータベースは、例えば、オブジェクト-関連のデータベース管理システム（ＯＲＤＢＭＳ）であるＰｏｓｔｇｒｅＳＱＬ（ここではＰｏｓｔｇｒｅｓとも呼称する）によって構成することができる。ノードはＪａｖａＨＴＴＰサーバー/サーブレット・コンテナーであるＪｅｔｔｙのようなＷｅｂサーバーを含むことができる。以上に述べたメカニズムはいずれも説明の便宜上挙げた例に過ぎないことはいうまでもない。
【００２１】
所与のノードにおける記憶マネジャー３３０は物理的記憶デバイスの管理を担当する。好ましくは、それぞれの記憶・マネジャー・インスタンスが配置アルゴリズムに従ってすべてのファイルが配置される単一ルート・ディレクトリーとして機能する。複数の記憶・マネジャー・インスタンスが１つのノードにおいて作用しながら、それぞれがシステムにおける異なる物理的ディスクを表わす。記憶・マネジャーは使用されているドライブおよびインターフェース技術をシステムの残り部分から除去する。記憶・マネジャー・インスタンスがフィライルの書き込みを要求されると、表示すべきフルパスおよびフルネームを生成させる。代表的な実施態様では、記憶・マネジャーに保存されるべきそれぞれのオブジェクトが保存されるべき生のデータとして受信され、次いで、記憶・マネジャーが保存するファイルに自体のメタデータを加えることによって種々の情報を追跡できるようにする。例えば、このメタデータは下記のエレメントを含む：ＥＦ長さ（外部ファイルの長さ（単位はバイト））、ＩＦＳｅｇｍｅｎｔのサイズ（このＩｎｔｅｒｎａｌＦｉｌｅファイル部分のサイズ）、ＥＦ保護表示（保護モード）、ＩＦ保護機能（この内部ファイルの表示）、ＥＦ生成タイムスタンプ（外部ファイル・タイムスタンプ）、シグネチャ（シグネチャのタイプを含む、書き込み（ＰＵＴ）時における内部ファイルのシグネチャ）およびＥＦファイルネーム（外部ファイルのファイルネーム）。内部ファイル・データと共にこの補足的メタデータ保存することによって、保護レベルが強化される。具体的には、スカベンジングによって、内部ファイルに保存されているメタデータからデータベース中に外部ファイル記録を生成させることができる。他のポリシー内部ファイルに対して内部ファイル・ハッシュの正当性を確認することによって内部ファイルが損なわれていないことを確認することができる。
【００２２】
内部ファイルはアーカイブ・オブジェクトにおけるオリジナル「オリジナル・ファイル」の一部を表わすデータの「チャンク（塊）」である場合があり、これら「チャンク」を別々のノードに配置することにより、分散化および保護ブロックを達成することができる
。外部ファイルをこのように小さいユニットに分断することは必要条件ではなく、内部ファイルが外部ファイルの完全なコピーであってもよい。典型的には、それぞれの外部ファイル項目についてメタデータ・マネジャーに１つの外部ファイル項目が存在し、それぞれの外部ファイル項目ごとに複数の内部ファイル項目が存在する場合もある。典型的には、内部ファイルのレイアウトはシステムに応じて異なる。所与の実施態様においては、ディスクにおけるこのデータの実際の物理的フォーマットが一連の可変長記録の形で保存される。
【００２３】
リクエスト・マネジャー３２４はシステム内の他のコンポーネントと相互作用することによってアーカイブ・アクションを行なうのに必要な一連のオペレーションを実行する。リクエスト・マネジャーは種類の異なる多くの同時アクションを援護し、失敗したトランザクションをロールバックすることができ、実行に長時間を要するトランザクションを援護する。リクエスト・マネジャーはまた、アーカイブにおける読出し/書き込みが正しく扱われ、すべてのリクエストが常時既知の状態にあることを保証する。さらにまた、複数ノードに亘る複数の読出し/書き込みオペレーションを調整して所与のクライエント・リクエストに対応する。また、リクエスト・マネジャーはメタデータ・マネジャー項目をキャッシュに格納し、セッションおよびデータ・ブロックのためのバッファリングを可能にする。
【００２４】
クラスタの第１の任務はディスクに無限数のファイルを保存することにある。所与のノードは到達できない、または何らかの理由で使用できないという意味で「信頼できない」と見做されることがある。このような場合によっては信頼性に欠けるノードが互に協働して信頼できる、且つ高度の可用性を有する記憶を生成する。一般に、保存しなければならない２種類の情報がある：ファイル自体とファイルに関するメタデータである。
【００２５】
データの保護
本発明では、データ機密保持スキームがアーカイブにおける個々のノードに書き込まれるコンテンツおよびメタデータを暗号化する。この技術は好ましくは「機密共有」によるキー管理を行なう。１つの実施態様においては、保護スキームをインストール時に行う。インストールの時点において暗号化キーが生成し、分断され、それぞれの断片がそれぞれのアーカイブ・ノードに書き込まれる。盗まれたり悪用されたりしないようにするため、キーをドライブに書き込まない。機密が割り振りされるスキームであるから、クラスタがドライブを実装する前にｎ個のノードのうちのｔ個が存在しなければならない。キーを復元するめのプロセスが行なわれる。このプロセスでは、充分なｔ値に達するまでできる限り多数のノードと接触する。充分なｔ値に達したら、プロセスはキーを復元し、局所的にドライブを実装する。双方向通信の場合、ｔ個のノードすべてにおいてこの実装がほぼ同時に行なわれる。ドライブが実装されると、クラスタは通常通りに作動を続けることができる。
【００２６】
１つの実施態様では、暗号化キーを分断し、アーカイブにおける設定可能な個数のノードに分散する。キーの割り振りとドライブの数との比率が１：１とは限らないが、所与のドライブがそれぞれのドライブと連携するキー断片を有することが好ましい。個々のドライブにおいて、キー断片はドライブに書き込まれるコンテンツおよびメタデータのすべてを暗号化する。ドライブに対するサーチ・インデックスも暗号化されることが好ましい。この方法によってデータの機密性が保護され、アーカイブ自体の外部から（例えば、第三者アプリケーションを利用して）コンテンツを暗号化する必要性が省かれる。こうして暗号がユーザーには見えなくなる。
【００２７】
インストールの段階で、ユーザーがキーを書き留め、これを安全な場所（好ましくはアーカイブ外の場所）に記憶することが好ましい。キーはアーカイブ中のディスクからデー
タを回収するのに使用できるが、アーカイブ・ディスクに保存しないことが好ましい。即ち、キーをディスクには書き込まず、（最初のインストールの際にだけ）表示することが好ましい。ユーザー・インターフェースを介して、またはインターフェースの使用中、キーを使用できないことが好ましい。キーはシステム内のロックされたメモリ（即ち、交換不能なメモリ）に記憶され、上述したように、必要な個数（例えば、ｎ/２＋１個）のドライバーを有するシステムによって初めて復元できる。キーを復元できなければ、クラスタは起動できず、データにアクセスすることができない。暗号化システムにおけるスワップ領域をも暗号化することによってデータ露出を回避することが好ましい。
【００２８】
本発明はハードウェア（即ち、ディスク）の盗難、および/または部外者のアーカイブへのアクセスを防止する。例えば、クラスタへの物理的アクセスを画策し、ハード・ドライブ（またはノード全体）を取り外し、持ち去る泥棒からデータを保護しようとするものである。要は、盗難されてもそのハードディスクが泥棒にとって役立たないものにすることである。
【００２９】
起動に際しては、ディスクを実装する前にきーが必要になる。手動、または自動的にパスフレーズ（またはこれに類するもの）を入力するのではなく、本発明では、機密共有プロトコルを実施することが好ましい。機密共有は公知の暗号プロトコルであり、機密をｎ個の断片に分断し、そのうちのｔ個を利用してキーを復元するというものである。好ましくは、キー断片１つ毎にそれぞれのドライブをインストールする。泥棒（または権限のない人物または団体が有用なデータにアクセスできるためには、ｔ個のドライブを盗むか（さもなければｔ個のドライブに対するアクセス権を超越しなければならない。当然のことながらｔ個のドライブの存在なしにはアーカイブも役に立たないから、便宜性とセキュリティとの兼ね合いこそがアーカイブ・ユーザーにとって重要な課題である。クラスタが起動する前にキーを復元するためのプロセスが実行されるが、このシーケンスは不要である。このプロセスはできる限り多数のノードと接触する。充分なｔ値に達したら、プロセスはキーを復元し、局所的にドライブを実装する。双方向通信（例えば、一連のバックエンド・リンクを介してのマルチキャストまたは放送）を使用する場合、ドライブの実装はｔ個のノードすべてにおいてほぼ同時に行なわれる。ドライブが実装されたら、クラスタは通常の態様で起動する。
【００３０】
所与のディスクにおいて、既存デバイスの頂部に暗号化されたブロック・デバイス・ドライバーを重ねることが好ましい。ディスク・パーティションの頂部にドライバーを重ねることによって、データが書き込まれるのに伴ってパーティションが暗号化される。同様に、データもキーがなければ読み出すことはできない。
【００３１】
本発明の方法をさらに詳細に以下に説明する。
【００３２】
機密共有に関する詳細は参考のため本願明細書中に引用した幾つかの公知刊行物に記載されている。例えば、Shamir, "How to share a secret," Communications of the ACM, volume 22, pp. 612-613, ACM, 1979 および Blakley, "Safeguarding cryptographic keys," in Proceedings of AFIPS 1979, volume 48, pp. 313-317, June 1979.
【００３３】
キーはキー生成（keygen)プログラムを使用して生成させる。キー生成プログラム６０２は設定ファイルを読むことによって適正なキー長さ（例えば、２５６ビット・キーなら３２バイト）を決定する。キーはランダム・データである。キー生成プログラム６０２は分断されたキーを繋ぎ合わせるのに必要な最小限のノード個数を定義する閾値を含む幾つかのコマンド・ライン引数を求める。閾値が設定されていない場合、初期値を割振りされるキー断片数（即ち、ノードの個数）に設定することが好ましい。閾値に続いて、キー生成プログラムはキー断片を割り振られるノードの１つまたは２つ以上のＩＰアドレスを取
上げる。キーを割り振りした後、キー生成プログラムはエスクロウ用として生成したキーをプリントアウトおよび/または表示する（但し、保存しない）。このオペレーションを図４に示す。既に述べたように、キーもキーに関するデータも、盗難に遭ったり、悪用されたりする恐れのあるディスクには保存しない。１組のコマンド・ライン引数を以下に例示する：
キー生成−閾値２{10.1.1.10, 10.1,1,11, 10.1.1.1, 10.1.1.13}
この実施例では、キーが４分割され、４個の特定ノードに伝送される。実際にはキー分割数はもっと多い場合が考えられる。キー共有プロトコルによれば、この実施例の場合、クラスタがドライブを実装できるために存在しなければならないノードの個数は２個である。実際には、閾値がもっと高い値に設定されることになる。
【００３４】
キー生成プログラムによって送信されるキー・データはノード毎に、キー書き込みを管理する第２プログラムによって受信される。キー書き込みプログラム６０４と呼称されるこのプログラムは所与の設定ファイル（例えば、ノードにおける/ｃｒｙｐｔ‐ｓｈａｒｅ）にキー・データを書き込む。キー書き込みプログラムはインストールによって起動させられ、書き込みが終わると、プログラムが退出することが好ましい。キー書き込みプログラム６０４は状態（即ち、インストール以外の状態）では作動せず、クラスタ再キー書き込み事故に対するエキストラ・バリヤーをして機能する。事実上、キー書き込みプログラムは実質的にはファイル・コピー・プログラムである。暗号化スキームを容易にする他のプログラムと同様にキー書き込みプログラム６０４はメモリ交換を行なうことができない。暗号断片がドロップオフするとキー書き込みプログラムは退出する。
【００３５】
起動時に、キー・サービスと呼称されるデーモン・プロセスがスタートする。キー・サービス・プロセス６０６はマルチキャストを介して通信することにより、クラスタにおける他のキー・サービス・プロセスにメッセージを送信する。キー・サービス・プロセス６０６は/ｃｒｙｐｔ‐ｓｈａｒｅ設定ファイルを読み、キー生成プログラムと同様に閾値を取上げる。キー生成プログラムは設定ファイルに閾値を保存してもしなくてもよい。
【００３６】
個々のディスクにおいて、初期化スクリプトがディスク実装に関与する。本発明のスキームでは、補足の初期化スクリプトを設け、この補足スクリプトに高い優先権を与える（即ち、先行して作用するようにする)。このスクリプトはキー設定プログラム６０８に保存すればよい。如何なる暗号文（例えば、ＡＥＳ（Ｒｉｊｎｄａｅｌとも呼称される）、Ａｎｕｂｉｓ、Ａｒｃ４、Ｂｌｏｗｆｉｓｈ、Ｃａｓｔ５、Ｃａｓｔ６、ＤＥＳ、ＴｒｉｐｌｅＤＥＳ、Ｋｈａｚａｄ、Ｓｅｒｐｅｎｔ、ＴＥＡ/ＸＴＥＡ/ＸＥＴＡ、Ｔｗｏｆｉｓｈなど)を暗号文として使用するかを特定するのにも使用することができる。暗号文またはキー長さに関係なく、暗号化モードは暗号ブロック連鎖方式であることが好ましい。但し、これは必須条件ではない。正常な使用時には、キー設定プログラムは下のデバイスと新規のデバイス名を検討する。キー設定プログラムはキー・サービス・プロセスと接触してキーをリクエストする。もしキー・サービス・プロセスがすでにキーを復元している場合には、キー・サービス・プロセスはこれを返送する。キー・サービス・プロセスが未だキーを持っていなければ、キーサービス・プロセスは他のノードにマルチキャスト・メッセージを送信してそれぞれのノードに割り振られているキー断片を求め、完全なキーに復元する。キーを入手すると、キー設定プログラムが、例えば、クリプト・ターゲットを利用してデバイス・マッパー項目を作成する。新規デバイス名がブロック・デバイスとなり、ディスク実装スクリプトがこれを利用してドライブを実装する。この時点から、この新規デバイスをブロック・デバイスとして利用することができる。
【００３７】
一般に、暗号化がなされてもユーザーまたはソフトウェアに視認できるような変化はない。図５に示すように、アーカイブが暗号化されていることが暗号のタイプとともに表示されることが好ましい。ブロック・デバイスを直接実装するのではなく、実装されたドラ
イブがデバイス・マッパーを通過することが好ましいが、このことは視認できないのが普通である。典型的には、デバイス・マッパーを通過しなければ暗号化されたドライブは使用できない。
【００３８】
キー・データが交換領域で途切れることがないように、キーを扱うすべてのプログラムが交換機能を停止することが好ましい。プログラムがルートとして作動する必要はない。
【００３９】
少なくとも幾つかのノードが存在することが好ましい。機密共有アルゴリズムでは、正しく復元するのに少なくとも２つの共有ノードが必要であり、さらには、暗号化された単一のノードは、ドライブが盗まれた場合、盗んだ側がキーを発見するのに充分なキー生成情報を得易いからである。非常事態、例えば、閾値を下回るほどの異常がクラスタに発生した場合に備えて、キーを第三者預託すべきである。当然のことながら、データは第三者預託されるキーと同程度にしか安全ではないから、キーそのもの安全な記憶が要求される。必要なら、キー破壊ルーチンまたは機能をシステムに組み込むことができる。例えば、システムに制御スイッチまたは制御オペレーションを組み込み、これが作動するとキーを構成している割り振り部分（またはその幾つか）を破壊するようにすることができる。キーを構成する割り振り部分がバックアップから取り戻されるまでアーカイブはシャットダウンの状態となる。
【００４０】
例えば、暗号化された交換領域を含み、上記プログラムを暗号化するなど、種々の実施態様が考えられる。
【００４１】
また、キーが外部に漏れた場合に、アーカイブ全体（またはその一部）をあらためて暗号化しなくも済む対策を講ずるべきである。この問題に対応するため、システムは事実上セッション・キーである暗号化されたキー・アークテクチャを採用することができる。具体的には、上記の技術によって種々の割り振りキー断片を組み合わせて唯一のマスターキーを生成する。この実施態様では種々の割り振り断片をまとめてセッション・キーを生成し、このセッション・キーを使用して本物のキーを解読する。解読したら、この本物のキーを使用してディスクを実装する。本物のキーはアーカイブ外部からは決して見えない。もしセッション・キーが盗難に遭ったら、このキーを廃棄し、別のセッション・キーを生成する。このアプローチの利点として、システムにはユーザー毎に１個ずつのセッション・キーを設けることができ、このキーをユーザーが任意に変更できる。
【００４２】
本発明はディジタル情報資産を捕捉し、保存し、管理し、検索するように構成されたアーカイブ管理システムの実現を容易にする。構成は多様な必要条件を考慮している：無制限の記憶、高度の信頼性、自主的管理、法規制の順守、ハードウェアの独立性、および既存アプリケーションとの融合。（例えば）Ｌｉｎｕｘを運用する商品ハードウェアのクラスタは堅牢なプラットホームと、実質的に無制限のアーカイブを可能にする。システムは、例えば、数個の記憶ノード・サーバーから数千テラバイトのデータを保存できる厖大な数のノードにまで拡張可能である。ユニークなアーキテクチャーは保存容量を組織の増大するアーカイブ需要にあわせて増大させることを可能にする。
【００４３】
本発明の幾つかの実施態様において行なわれるオペレーションの特定のシーケンスを説明したが、これらのシーケンスは飽くまでも説明の便宜上取上げたに過ぎず、実施態様によっては、異なるシーケンスでオペレーションを実行したり、いくつかのオペレーションを組み合わせたり、オーバーラップさせる、なども可能である。実施態様によっては特定の構成要件、構造または特性を有するが、必ずしもすべての実施態様がこれら特定の構成要件、構造または特性を含むとは限らない。
【００４４】
本発明を方法またはプロセスに関して説明したが、本発明はこれらのプロセスを実行す
る装置にも係わる。この装置は所要の目的に合わせて構成するか、または記憶されているコンピュータ・プログラムによって設定される汎用コンピュータで構成されるか、または設定される。このようなコンピュータ・プログラムはコンピュータ可読記憶媒体、例えば、光学的ディスク、ＣＤ‐ＲＯＭ，磁気-光学ディスク、読出し専用メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、磁気または光学カード、または電子的命令の記憶に好適な媒体などに記憶することができ、いずれもコンピュータ・システムのバスに接続している。
【００４５】
システムの所与のコンポーネントを別々に説明したが、当業者には明らかなように、機能の幾つかを所与の命令、プログラム・シーケンス、コード部分などにおいて組み合わせたり、振り分けることもできる。
【００４６】
上述のように、リクエスト・マネジャー・コンポーネントは保護マネジャーを利用することによって入ってくる書き込みに応じてアーカイブに記憶するとともに、ポリシー違反が検出されるとポリシーに適合させる。リクエスト・マネジャーがこの好ましいが、アプリケーションの他のコンポーネントを利用して保護マネジャーの機能を援護または提供することもできる。
【００４７】
本発明を以上に説明したが、その範囲を後記の請求項によって定義する。
【関連出願の相互参照】
【０００１】
本願は２００７年５月７日付け米国特許出願第６０／９１６，４７８号に基づく。
【０００２】
本願は２００５年７月２７日付け米国特許出願第１１／１９０，４０２号「固定コンテンツ分散型データ記憶のためのメタデータ管理」および２００６年１２月１３日付け米国特許出願第１１／６３８，２５２号「独立ノードの冗長アレイのポリシーに基づく管理」に関連の出願である。
【発明の背景】
【０００３】
【技術分野】
【０００４】
本発明は分散型コンピュータ・ネットワークにおける可用性、信頼性および耐久性に優れたデータ記憶技術に係わる。
【関連技術の説明】
【０００５】
従来のテープおよび光学的媒体による記憶方法に代わる、またはこれを補完する方法として、可用性、信頼性および耐久性に優れた「固定コンテンツ」のアーカイブ記憶システムに対する需要が高まっている。「固定コンテンツ」とは典型的には参照などのため、変化することなく記憶されるべきディジタル情報を指す。このようなディジタル情報の例として、ｅ-メール、書類、診断画像、チェック画像、音声記録、フィルム、ビデオなどが挙げられる。従来の独立ノード冗長アレイ（ＲＡＩＮ）記憶アプローチはこのような固定コンテンツ情報資産を記憶する大規模なオンライン・アーカイブを構成するための選択アーキテクチャーとして出現した。ノードが必要に応じてクラスタに結合および離脱できるようにすることによってＲＡＩＮアーキテクチャーは記憶クラスタを１つまたは２つ以上のノードの故障から隔離する。複数のノードにデータを複製することによってＲＡＩＮ-タイプのアーカイブはノートの故障または撤去を自動的に補償することができる。典型的には、ＲＡＩＮシステムは閉システム内において共通の部品で構成されたハードウェア装置として広く配布される。
【０００６】
図１は拡張可能なこの種の、ディスクに基づくアーカイブ記憶管理システムを示す。ノードは異なるハードウェア、即ち「異種」ハードウェアから構成することができる。ノードは典型的には１つまたは２つ以上の記憶ディスク、例えば、実際の物理的記憶ディスクや、記憶領域ネットワーク（ＳＡＮ）に含まれるような仮想記憶ディスクへのアクセス有する。それぞれのノードにおけるアーカイブ・クラスタ・アプリケーション（および場合によってはアプリケーションが実行される基本オペレーティング・システム（基本ソフト））は同じでもよいし、実質的に同じでもよい。それぞれのノードにおける（オペレーティング・システムを含むこともできる）ソフトウェアは対称であるが、ハードウェアは異種であってもよい。このシステムを利用することによって、図１に示すように、企業は書類、ｅ-メール、衛星画像、診断画像、チェック画像、音声記録、ビデオなど多様な固定コンテンツ情報の恒久的な記憶ファイルを作成することができる。言うまでもなく、これらの情報タイプは例に過ぎない。高レベルの信頼性は独立サーバー、またはいわゆる記憶ノードにおいてデータを複製することによって達成される。それぞれのノードはピアと対称であることが好ましい。即ち、好ましい態様では所与のノードがすべての機能を発揮できるから、どれか１つのノードが故障してもアーカイブの可用性には殆ど影響しない。
【０００７】
共有の米国特許第７，１５５，４６６号に記載されているように、ＲＡＩＮ方式のアーカイブ・システムにおいて、ディジタル資産を捕捉し、保存し、管理し、検索する分散型
ソフトウェア・アプリケーションをそれぞれのノードに組み込むことは公知である。図２はそのようなシステムの１例を示す。個々のアーカイブの物理的境界をクラスタと呼称する。典型的には、クラスタは単一デバイスではなく、デバイスの集合体である。典型的なデバイスはコンピュータまたはＬｉｎｕｘのようなソフトを運用するマシーンである。商品ハードウェアをホストとするＬｉｎｕｘ系方式システムのクラスタは数個の記憶ノード・サーバーから数千テラバイトのデータを記憶する厖大な数のノードにまで拡張可能なアーカイブを提供する。このアーキテクチャーでは、組織の増大するアーカイブ需要に記憶容量が対応することができる。
【発明の概要】
【０００８】
本発明は拡張可能なアーカイブ記憶管理システムにおけるデータの機密保持機能を向上させる技術を提供する。１つの実施態様においては、アーカイブに記憶されるコンテンツ（および、必要ならメタデータも）をユーザーには見えないように暗号化することによってこの目的を達成する。こうすることによって、コンテンツ（および/またはメタデータ）が盗まれたアーカイブ媒体（例えば、ディスク）から再生されたり、アーカイブへのアクセスを許された第三者（例えば、技術者、またはその他のサービス要員）によって不正に取得されたりすることが防止される。
【０００９】
図示例では、機密保持スキームとして、「機密共有」プロトコルに基づく分散型キー管理を採用する。機密共有の基本的なアイデアは、機密（即ち、キー）をｎ個の部分に分断し、これらｎ個の断片のうちのｔ個を利用することによってキーを復元できる、というものである。好ましくは、機密保持スキームをインストール時に行なう。具体的には、この時点において暗号化キーが生成し、分断され、それぞれの断片がアーカイブ・ノードに書き込まれる。断片が割当てられた後、キーをプリントしてもよいが、多くの場合、クラスタのディスクに記憶させることはない。このようにすれば、盗難などのおそれがあるドライブにキーが書き込まれることがない。この実施態様では、こうしてキーが生成し、一連の割当分に分割され、それぞれの割当分が個々のノードへ送信される。上述したように、機密が割り振りされるスキームであるから、クラスタがドライブを実装する前にｎ個のノードのうちのｔ個が存在しなければならない。即ち、クラスタが起動する前に、キーを復元するためのプロセスが行なわれる。このプロセスでは、充分なｔ値に達するまでできる限り多数のノードと接触する。充分なｔ値に達したら、プロセスはキーを復元し、局所的にドライブを実装する。双方向通信の場合、ｔ個のノードすべてにおいてこの実装がほぼ同時に行なわれる。ドライブが実装されると、クラスタは通常通りに作動を続けることができる。
【００１０】
以上、本発明の特徴を述べたが、飽くまでも説明のための概要であり、以下に説明するように実施態様を変えることによって、上記以外の有益な成果を挙げることができる。
【００１１】
本発明の詳細と利点を添付の図面を参照しながら以下に説明する。
【図面の簡単な説明】
【００１２】
【図１】図１は本発明を実施することができる固定コンテンツ記憶アーカイブの簡略化したブロックダイヤグラムである。
【図２】図２はそれぞれが対称であり、本発明のアーカイブ・クラスタ・アプリケーションを備えた独立ノードの冗長アレイを示す簡略図である。
【図３】図３は所与のノードにおいて実行されるアーカイブ・クラスタ・アプリケーションの種々の構成コンポーネントの高レベルの図解である。
【図４】図４は本発明のキー生成プログラムのアウトプットを示す。
【図５】図５は本発明のシステムによる暗号化の表示形式を示す。
【図６】図６は実施例を構成するプログラムを示す。
【図示実施例の詳細な説明】
【００１３】
本発明の方法を実施する図２に示す好ましい実施例は大別して下記のコンポーネントから成る：ノード２０２、１対のネットワーク・スイッチ２０４、配電ユニット（ＰＤＵ）２０６、および無停電電源（ＵＰＳ）２０８。ノード２０２は典型的には１つまたは２つ以上の商品サーバーから成り、ＣＰＵ（適当なランダム・アクセス・メモリ（ＲＡＭ）、例えば、Ｉｎｔｅｌ×８６）、１つまたは２つ以上のハード・ドライブ（例えば、標準的なＩＤＥ/ＳＡＴＡ、ＳＣＳＩなど）、および２つまたは３つ以上のネットワーク・インターフェース・カード（ＮＩＣ）を含む。典型的なノードは２．４ＧＨｚチップ、５１２ＭＢＲＡＭ、および６個の２００ＧＢハード・ドライブを実装された２Ｕラックである。但し、これに限定されることはない。ネットワーク・スイッチ２０４は典型的にはノード間のピア対ピア通信を可能にする内部スイッチ２０５と、それぞれのノードへのエクストラ-クラスタ・アクセスを可能にする外部スイッチ２０７から成る。それぞれのスイッチはクラスタに含まれるすべてのノードに対応するのに充分な数のポートを必要とする。この目的にはＥｔｈｅｒｎｅｔまたはＧｉｇＥスイッチを使用することができる。すべてのノードおよびスイッチへの給電にはＰＤＵ２００を使用し、すべてのノードおよびスイッチを保護するためにＵＰＳ２０８を使用する。限定するものではないが、典型的には、クラスタをネットワーク、例えば、公衆通信回線、企業インターネット、またはその他の広域ネットワークまたはローカル・エリア・ネットワークに接続可能である。図示実施例の場合、クラスタは企業環境内に実装される。クラスタには、サイトの企業ドメイン・ネーム・システム（ＤＮＳ）ネーム・サーバーを介してナビゲートすることによって到達することができる。例えば、クラスタのドメインが既存のドメインの新しいサブドメインである場合がある。代表的な実施態様においては、企業ＤＮＳサーバーはサブドメインをクラスタ自体内のネーム・サーバーに任せる。エンド・ユーザーは公知のインターフェースまたはアクセス・ツールを使用してクラスタにアクセスする。例えば、クラスタへのアクセスはＩＰ系プロトコル（ＨＴＴＰ、ＦＴＰ、ＮＦＳ、ＡＦＳ、ＳＭＢ、Ｗｅｂサービス、など）に従って、またはＡＰＩを介して、またはその他の公知の、またはその後開発されたアクセス方法、アクセス・サービス、アクセス・プログラムまたはツールを介して行なうことができる。
【００１４】
クライエント・アプリケーションは例えば標準的なＵＮＩＸファイル・プロトコル、ＨＴＴＰＡＰＩのような１種または２種以上の外部ゲートウェイを介してクラスタにアクセスする。アーカイブは好ましくは任意に標準的なＵＮＩＸファイル・プロトコルに従って動作させることができる仮想ファイル・システムを介して露出させることが好ましい。例えば、ＮＦＳ、ＦＴＰ、ＳＭＢ/ＣＩＦＳなどが挙げられる。
【００１５】
１つの実施態様として、アーカイブ・クラスタ・アプリケーションは（例えば、Ｅｔｈｅｒｎｅｔを介して）クラスタとしてネットワーク化される複数の独立ノード（Ｈ-ＲＡＩＮ）において進行する。所与のノードのハードウェアは異機種であってもよい。但し、最大限の信頼性を達成するためには、好ましくはそれぞれのノードが、図３に示すように幾つかのランタイム・コンポーネントから成る（同じか、または殆ど同じ）分散アプリケーションのインスタンス３００を実行する。即ち、ハードウェアは異機種であってもよいが、（少なくとも本発明に関する限り）ノードにおけるソフトウェア・スタックは同じである。これらのソフトウェア・コンポーネントはゲートウエイ・プロトコル層３０２、アクセス層３０４、ファイル・トランザクションおよび管理層３０６、およびコア・コンポーネント層３０８を含む。「層」は説明の便宜上の呼称であり、当業者には明らかなように、他の呼称で機能を特徴付けることも可能である。層（またはこれに含まれるコンポーネント）の１つまたは２つ以上を一体化してもしなくてもよい。コンポーネントによってはそれぞれの層に配分してもよいものがある。
【００１６】
ゲートウェイ・プロトコル層３０２におけるゲートウェイ・プロトコルは既存のアプリケーションを不可視化する。具体的には、ゲートウェイはＮＦＳ３１０およびＳＭＢ/ＣＩＦＳ３１２のようなネイティブ・ファイル・サービスと共にＷｅｂサービスＡＰＩを提供することによってカスタム・アプリケーションを構成する。ＨＴＴＰサポート３１４も含まれる。アクセス層３０４はアーカイブへのアクセスを可能にする。具体的には、本発明では、固定コンテンツ・ファイル・システム（ＦＣＦＳ）３１６はネイティブ・ファイル・システムをエミュレートしてアーカイブ・オブジェクトへのフル・アクセスを可能にする。ＦＣＦＳはアプリケーションを、あたかも普通のオブジェクトであるかのようにアーカイブ・コンテンツへ直接アクセスさせる。好ましくは、メタデータをファイルとして表示しながら、アーカイブ・コンテンツを原型に戻す。ＦＣＦＳ３１６はディレクトリ、認証およびルーチン・ファイル-レベル呼出しの型通りのビューを提供するから、管理者は手馴れた方法で固定コンテンツ・データを提供することができる。ファイル・アクセス呼出しをユーザー-スペース・デーモンが傍受してこれを、呼出しアプリケーションに適切なビユーを動的に生成させる（層３０８における）該当のコア・コンポーネントに転送することが好ましい。ＦＣＦＳ呼出しをアーカイブ・ポリシーによって規制することにより自主的なアーカイブ管理を容易にすることが好ましい。即ち、１例として、管理者またはアプリケーションは保持期間（所与のポリシー）が未だ有効なアーカイブ・オブジェクトを消去できない。
【００１７】
アクセス層３０４は好ましくはＷｅｂユーザー・インターフェース（ＵＩ）３１８およびＳＮＭＰゲートウェイ３２０をも含む。Ｗｅｂユーザー・インターフェース３１８はファイル・トランザクション/管理層３０６における管理エンジン３２２への対話式アクセスを可能にする管理者コンソールとして構成されていることが好ましい。管理コンソール３１８はアーカイブ・オブジェクトおよび個別ノードを含むアーカイブの動的なビューを提供する、パスワードで保護されたＷｅｂ系ＧＵＩであることが好ましい。ＳＮＭＰゲートウェイ３２０は記憶管理アプリケーションが管理エンジン３２２にアクセスしてクラスタの活動を確実にモニターし、制御することを容易にする。管理エンジンはシステムおよびポリシー事象を含むクラスタの活動をモニターする。ファイル・トランザクション/管理層３０６はリクエスト・マネジャー・プロセス３２４をも含む。リクエスト・マネジャー３２４は（アクセス層３０４を介して）外界からのすべてのリクエストを、さらにはコア・コンポーネント層３０８に含まれるポリシー・マネジャー３２６からの内部リクエストをも調整する。
【００１８】
コア・コンポーネントはポリシー・マネジャー３２６のほかに、メタデータ・マネジャー３２８と、記憶マネジャー３３０の１つまたは２つ以上のインスタンスをも含む。メタデータ・マネジャー３２８はそれぞれのノードにインストールされていることが好ましい。クラスタに含まれるこれらメタデータ・マネジャーが全体で分散データベースとして作用し、すべてのアーカイブ・オブジェクトを管理する。所与のノードにおいて、メタデータ・マネジャー３２８はアーカイブ・オブジェクトのサブセットを管理し、好ましくそれぞれのオブジェクトが外部ファイル（「ＥＦ」、記憶のためアーカイブに入力されるデータ）と、内部ファイル群（それぞれが「ＩＦ」）との間で、アーカイブ・データの物理的位置をマップする。同じメタデータ・マネジャー３２８が他のノードから複写されるアーカイブ。オブジェクト群をも管理する。即ち、すべての外部ファイルの現状を、幾つかのノードにおける複数のメタデータ・マネジャーが常時把握することができる。ノードに故障が発生しても、残りの正常なノードにおけるメタデータ・マネジャーが、それまで故障ノードに管理されていたデータへのアクセス継続を可能にする。このイオペレーションをさらに詳細に後述する。記憶マネジャー３３０は分散アプリケーションにおけるすべての他のコンポーネントがファイル・システム層を利用できるようにする。好ましくは、ノードのローカル・ファイル・システムにデータ・オブジェクトを記憶する。所与のノードにおけるそれぞれのドライブはそれ自体の記憶・マネジャーを有することが好ましい。記憶
・マネジャー３３０はシステム情報、データのインテグリティ・チェックをも提供し、ローカル・ディレクトリ構造を検討することもできる。
【００１９】
図３に示すように、クラスタは通信ミドルウェア層３３２およびＤＮＳマネジャー３３４を介して内部および外部通信を管理する。インフラストラクチャー３３２はアーカイブ・コンポーネント間の通信を可能にする有効且つ信頼できるメッセージ系ミドルウェア層である。図示実施例では、この層がマルチキャスト通信および２点間通信を可能にする。ＤＮＳマネジャー３３４はすべてのノードを企業サーバーに接続する分散ネーム・サービスを行なう。好ましくは、ＤＮＳマネジャーは（単独で、またはＤＮＳサービスと協働して）すべてのノードを横切るリクエストを負荷平衡させることによってクラスタの処理能力と利用可能性を最大にする。
【００２０】
図示実施例では、ＡｒＣアプリケーション・インスタンスが例えばＲｅｄＨａｔＬｉｎｕｘ９．０、ＦｅｄｏｒａＣｏｒｅ６などのようなベース・オペレーティング・システムにおいてで実行される。通信ミドルウェアは公知の分散型通信メカニズムである。その他のコンポーネントとして、固定コンテンツ・ファイル・システム（ＦＣＦＳ）３１６のために使用できるＦＵＳＥ（ＵＳＥｒｓｐａｃｅにおけるＦｉｌｅｓｙｓｔｅｍを含むことができる。ＮＦＳゲートウェイ３１０は標準的なｎｓｆｄＬｉｎｕｘＫｅｒｎｅｌＮＦＳドライバーによって構成することができる。それぞれのノードにおけるデータベースは、例えば、オブジェクト-関連のデータベース管理システム（ＯＲＤＢＭＳ）であるＰｏｓｔｇｒｅＳＱＬ（ここではＰｏｓｔｇｒｅｓとも呼称する）によって構成することができる。ノードはＪａｖａＨＴＴＰサーバー/サーブレット・コンテナーであるＪｅｔｔｙのようなＷｅｂサーバーを含むことができる。以上に述べたメカニズムはいずれも説明の便宜上挙げた例に過ぎないことはいうまでもない。
【００２１】
所与のノードにおける記憶マネジャー３３０は物理的記憶デバイスの管理を担当する。好ましくは、それぞれの記憶・マネジャー・インスタンスが配置アルゴリズムに従ってすべてのファイルが配置される単一ルート・ディレクトリーとして機能する。複数の記憶・マネジャー・インスタンスが１つのノードにおいて作用しながら、それぞれがシステムにおける異なる物理的ディスクを表わす。記憶・マネジャーは使用されているドライブおよびインターフェース技術をシステムの残り部分から除去する。記憶・マネジャー・インスタンスがフィライルの書き込みを要求されると、表示すべきフルパスおよびフルネームを生成させる。代表的な実施態様では、記憶・マネジャーに保存されるべきそれぞれのオブジェクトが保存されるべき生のデータとして受信され、次いで、記憶・マネジャーが保存するファイルに自体のメタデータを加えることによって種々の情報を追跡できるようにする。例えば、このメタデータは下記のエレメントを含む：ＥＦ長さ（外部ファイルの長さ（単位はバイト））、ＩＦＳｅｇｍｅｎｔのサイズ（このＩｎｔｅｒｎａｌＦｉｌｅファイル部分のサイズ）、ＥＦ保護表示（保護モード）、ＩＦ保護機能（この内部ファイルの表示）、ＥＦ生成タイムスタンプ（外部ファイル・タイムスタンプ）、シグネチャ（シグネチャのタイプを含む、書き込み（ＰＵＴ）時における内部ファイルのシグネチャ）およびＥＦファイルネーム（外部ファイルのファイルネーム）。内部ファイル・データと共にこの補足的メタデータ保存することによって、保護レベルが強化される。具体的には、スカベンジングによって、内部ファイルに保存されているメタデータからデータベース中に外部ファイル記録を生成させることができる。他のポリシー内部ファイルに対して内部ファイル・ハッシュの正当性を確認することによって内部ファイルが損なわれていないことを確認することができる。
【００２２】
内部ファイルはアーカイブ・オブジェクトにおけるオリジナル「オリジナル・ファイル」の一部を表わすデータの「チャンク（塊）」である場合があり、これら「チャンク」を別々のノードに配置することにより、分散化および保護ブロックを達成することができる
。外部ファイルをこのように小さいユニットに分断することは必要条件ではなく、内部ファイルが外部ファイルの完全なコピーであってもよい。典型的には、それぞれの外部ファイル項目についてメタデータ・マネジャーに１つの外部ファイル項目が存在し、それぞれの外部ファイル項目ごとに複数の内部ファイル項目が存在する場合もある。典型的には、内部ファイルのレイアウトはシステムに応じて異なる。所与の実施態様においては、ディスクにおけるこのデータの実際の物理的フォーマットが一連の可変長記録の形で保存される。
【００２３】
リクエスト・マネジャー３２４はシステム内の他のコンポーネントと相互作用することによってアーカイブ・アクションを行なうのに必要な一連のオペレーションを実行する。リクエスト・マネジャーは種類の異なる多くの同時アクションを援護し、失敗したトランザクションをロールバックすることができ、実行に長時間を要するトランザクションを援護する。リクエスト・マネジャーはまた、アーカイブにおける読出し/書き込みが正しく扱われ、すべてのリクエストが常時既知の状態にあることを保証する。さらにまた、複数ノードに亘る複数の読出し/書き込みオペレーションを調整して所与のクライエント・リクエストに対応する。また、リクエスト・マネジャーはメタデータ・マネジャー項目をキャッシュに格納し、セッションおよびデータ・ブロックのためのバッファリングを可能にする。
【００２４】
クラスタの第１の任務はディスクに無限数のファイルを保存することにある。所与のノードは到達できない、または何らかの理由で使用できないという意味で「信頼できない」と見做されることがある。このような場合によっては信頼性に欠けるノードが互に協働して信頼できる、且つ高度の可用性を有する記憶を生成する。一般に、保存しなければならない２種類の情報がある：ファイル自体とファイルに関するメタデータである。
【００２５】
データの保護
本発明では、データ機密保持スキームがアーカイブにおける個々のノードに書き込まれるコンテンツおよびメタデータを暗号化する。この技術は好ましくは「機密共有」によるキー管理を行なう。１つの実施態様においては、保護スキームをインストール時に行う。インストールの時点において暗号化キーが生成し、分断され、それぞれの断片がそれぞれのアーカイブ・ノードに書き込まれる。盗まれたり悪用されたりしないようにするため、キーをドライブに書き込まない。機密が割り振りされるスキームであるから、クラスタがドライブを実装する前にｎ個のノードのうちのｔ個が存在しなければならない。キーを復元するめのプロセスが行なわれる。このプロセスでは、充分なｔ値に達するまでできる限り多数のノードと接触する。充分なｔ値に達したら、プロセスはキーを復元し、局所的にドライブを実装する。双方向通信の場合、ｔ個のノードすべてにおいてこの実装がほぼ同時に行なわれる。ドライブが実装されると、クラスタは通常通りに作動を続けることができる。
【００２６】
１つの実施態様では、暗号化キーを分断し、アーカイブにおける設定可能な個数のノードに分散する。キーの割り振りとドライブの数との比率が１：１とは限らないが、所与のドライブがそれぞれのドライブと連携するキー断片を有することが好ましい。個々のドライブにおいて、キー断片はドライブに書き込まれるコンテンツおよびメタデータのすべてを暗号化する。ドライブに対するサーチ・インデックスも暗号化されることが好ましい。この方法によってデータの機密性が保護され、アーカイブ自体の外部から（例えば、第三者アプリケーションを利用して）コンテンツを暗号化する必要性が省かれる。こうして暗号がユーザーには見えなくなる。
【００２７】
インストールの段階で、ユーザーがキーを書き留め、これを安全な場所（好ましくはアーカイブ外の場所）に記憶することが好ましい。キーはアーカイブ中のディスクからデー
タを回収するのに使用できるが、アーカイブ・ディスクに保存しないことが好ましい。即ち、キーをディスクには書き込まず、（最初のインストールの際にだけ）表示することが好ましい。ユーザー・インターフェースを介して、またはインターフェースの使用中、キーを使用できないことが好ましい。キーはシステム内のロックされたメモリ（即ち、交換不能なメモリ）に記憶され、上述したように、必要な個数（例えば、ｎ/２＋１個）のドライバーを有するシステムによって初めて復元できる。キーを復元できなければ、クラスタは起動できず、データにアクセスすることができない。暗号化システムにおけるスワップ領域をも暗号化することによってデータ露出を回避することが好ましい。
【００２８】
本発明はハードウェア（即ち、ディスク）の盗難、および/または部外者のアーカイブへのアクセスを防止する。例えば、クラスタへの物理的アクセスを画策し、ハード・ドライブ（またはノード全体）を取り外し、持ち去る泥棒からデータを保護しようとするものである。要は、盗難されてもそのハードディスクが泥棒にとって役立たないものにすることである。
【００２９】
起動に際しては、ディスクを実装する前にきーが必要になる。手動、または自動的にパスフレーズ（またはこれに類するもの）を入力するのではなく、本発明では、機密共有プロトコルを実施することが好ましい。機密共有は公知の暗号プロトコルであり、機密をｎ個の断片に分断し、そのうちのｔ個を利用してキーを復元するというものである。好ましくは、キー断片１つ毎にそれぞれのドライブをインストールする。泥棒（または権限のない人物または団体が有用なデータにアクセスできるためには、ｔ個のドライブを盗むか（さもなければｔ個のドライブに対するアクセス権を超越しなければならない。当然のことながらｔ個のドライブの存在なしにはアーカイブも役に立たないから、便宜性とセキュリティとの兼ね合いこそがアーカイブ・ユーザーにとって重要な課題である。クラスタが起動する前にキーを復元するためのプロセスが実行されるが、このシーケンスは不要である。このプロセスはできる限り多数のノードと接触する。充分なｔ値に達したら、プロセスはキーを復元し、局所的にドライブを実装する。双方向通信（例えば、一連のバックエンド・リンクを介してのマルチキャストまたは放送）を使用する場合、ドライブの実装はｔ個のノードすべてにおいてほぼ同時に行なわれる。ドライブが実装されたら、クラスタは通常の態様で起動する。
【００３０】
所与のディスクにおいて、既存デバイスの頂部に暗号化されたブロック・デバイス・ドライバーを重ねることが好ましい。ディスク・パーティションの頂部にドライバーを重ねることによって、データが書き込まれるのに伴ってパーティションが暗号化される。同様に、データもキーがなければ読み出すことはできない。
【００３１】
本発明の方法をさらに詳細に以下に説明する。
【００３２】
機密共有に関する詳細は参考のため本願明細書中に引用した幾つかの公知刊行物に記載されている。例えば、Shamir, "How to share a secret," Communications of the ACM, volume 22, pp. 612-613, ACM, 1979 および Blakley, "Safeguarding cryptographic keys," in Proceedings of AFIPS 1979, volume 48, pp. 313-317, June 1979.
【００３３】
キーはキー生成（keygen)プログラムを使用して生成させる。キー生成プログラム６０２は設定ファイルを読むことによって適正なキー長さ（例えば、２５６ビット・キーなら３２バイト）を決定する。キーはランダム・データである。キー生成プログラム６０２は分断されたキーを繋ぎ合わせるのに必要な最小限のノード個数を定義する閾値を含む幾つかのコマンド・ライン引数を求める。閾値が設定されていない場合、初期値を割振りされるキー断片数（即ち、ノードの個数）に設定することが好ましい。閾値に続いて、キー生成プログラムはキー断片を割り振られるノードの１つまたは２つ以上のＩＰアドレスを取
上げる。キーを割り振りした後、キー生成プログラムはエスクロウ用として生成したキーをプリントアウトおよび/または表示する（但し、保存しない）。このオペレーションを図４に示す。既に述べたように、キーもキーに関するデータも、盗難に遭ったり、悪用されたりする恐れのあるディスクには保存しない。１組のコマンド・ライン引数を以下に例示する：
キー生成−閾値２{10.1.1.10, 10.1,1,11, 10.1.1.1, 10.1.1.13}
この実施例では、キーが４分割され、４個の特定ノードに伝送される。実際にはキー分割数はもっと多い場合が考えられる。キー共有プロトコルによれば、この実施例の場合、クラスタがドライブを実装できるために存在しなければならないノードの個数は２個である。実際には、閾値がもっと高い値に設定されることになる。
【００３４】
キー生成プログラムによって送信されるキー・データはノード毎に、キー書き込みを管理する第２プログラムによって受信される。キー書き込みプログラム６０４と呼称されるこのプログラムは所与の設定ファイル（例えば、ノードにおける/ｃｒｙｐｔ‐ｓｈａｒｅ）にキー・データを書き込む。キー書き込みプログラムはインストールによって起動させられ、書き込みが終わると、プログラムが退出することが好ましい。キー書き込みプログラム６０４は状態（即ち、インストール以外の状態）では作動せず、クラスタ再キー書き込み事故に対するエキストラ・バリヤーをして機能する。事実上、キー書き込みプログラムは実質的にはファイル・コピー・プログラムである。暗号化スキームを容易にする他のプログラムと同様にキー書き込みプログラム６０４はメモリ交換を行なうことができない。暗号断片がドロップオフするとキー書き込みプログラムは退出する。
【００３５】
起動時に、キー・サービスと呼称されるデーモン・プロセスがスタートする。キー・サービス・プロセス６０６はマルチキャストを介して通信することにより、クラスタにおける他のキー・サービス・プロセスにメッセージを送信する。キー・サービス・プロセス６０６は/ｃｒｙｐｔ‐ｓｈａｒｅ設定ファイルを読み、キー生成プログラムと同様に閾値を取上げる。キー生成プログラムは設定ファイルに閾値を保存してもしなくてもよい。
【００３６】
個々のディスクにおいて、初期化スクリプトがディスク実装に関与する。本発明のスキームでは、補足の初期化スクリプトを設け、この補足スクリプトに高い優先権を与える（即ち、先行して作用するようにする)。このスクリプトはキー設定プログラム６０８に保存すればよい。如何なる暗号文（例えば、ＡＥＳ（Ｒｉｊｎｄａｅｌとも呼称される）、Ａｎｕｂｉｓ、Ａｒｃ４、Ｂｌｏｗｆｉｓｈ、Ｃａｓｔ５、Ｃａｓｔ６、ＤＥＳ、ＴｒｉｐｌｅＤＥＳ、Ｋｈａｚａｄ、Ｓｅｒｐｅｎｔ、ＴＥＡ/ＸＴＥＡ/ＸＥＴＡ、Ｔｗｏｆｉｓｈなど)を暗号文として使用するかを特定するのにも使用することができる。暗号文またはキー長さに関係なく、暗号化モードは暗号ブロック連鎖方式であることが好ましい。但し、これは必須条件ではない。正常な使用時には、キー設定プログラムは下のデバイスと新規のデバイス名を検討する。キー設定プログラムはキー・サービス・プロセスと接触してキーをリクエストする。もしキー・サービス・プロセスがすでにキーを復元している場合には、キー・サービス・プロセスはこれを返送する。キー・サービス・プロセスが未だキーを持っていなければ、キーサービス・プロセスは他のノードにマルチキャスト・メッセージを送信してそれぞれのノードに割り振られているキー断片を求め、完全なキーに復元する。キーを入手すると、キー設定プログラムが、例えば、クリプト・ターゲットを利用してデバイス・マッパー項目を作成する。新規デバイス名がブロック・デバイスとなり、ディスク実装スクリプトがこれを利用してドライブを実装する。この時点から、この新規デバイスをブロック・デバイスとして利用することができる。
【００３７】
一般に、暗号化がなされてもユーザーまたはソフトウェアに視認できるような変化はない。図５に示すように、アーカイブが暗号化されていることが暗号のタイプとともに表示されることが好ましい。ブロック・デバイスを直接実装するのではなく、実装されたドラ
イブがデバイス・マッパーを通過することが好ましいが、このことは視認できないのが普通である。典型的には、デバイス・マッパーを通過しなければ暗号化されたドライブは使用できない。
【００３８】
キー・データが交換領域で途切れることがないように、キーを扱うすべてのプログラムが交換機能を停止することが好ましい。プログラムがルートとして作動する必要はない。
【００３９】
少なくとも幾つかのノードが存在することが好ましい。機密共有アルゴリズムでは、正しく復元するのに少なくとも２つの共有ノードが必要であり、さらには、暗号化された単一のノードは、ドライブが盗まれた場合、盗んだ側がキーを発見するのに充分なキー生成情報を得易いからである。非常事態、例えば、閾値を下回るほどの異常がクラスタに発生した場合に備えて、キーを第三者預託すべきである。当然のことながら、データは第三者預託されるキーと同程度にしか安全ではないから、キーそのもの安全な記憶が要求される。必要なら、キー破壊ルーチンまたは機能をシステムに組み込むことができる。例えば、システムに制御スイッチまたは制御オペレーションを組み込み、これが作動するとキーを構成している割り振り部分（またはその幾つか）を破壊するようにすることができる。キーを構成する割り振り部分がバックアップから取り戻されるまでアーカイブはシャットダウンの状態となる。
【００４０】
例えば、暗号化された交換領域を含み、上記プログラムを暗号化するなど、種々の実施態様が考えられる。
【００４１】
また、キーが外部に漏れた場合に、アーカイブ全体（またはその一部）をあらためて暗号化しなくも済む対策を講ずるべきである。この問題に対応するため、システムは事実上セッション・キーである暗号化されたキー・アークテクチャを採用することができる。具体的には、上記の技術によって種々の割り振りキー断片を組み合わせて唯一のマスターキーを生成する。この実施態様では種々の割り振り断片をまとめてセッション・キーを生成し、このセッション・キーを使用して本物のキーを解読する。解読したら、この本物のキーを使用してディスクを実装する。本物のキーはアーカイブ外部からは決して見えない。もしセッション・キーが盗難に遭ったら、このキーを廃棄し、別のセッション・キーを生成する。このアプローチの利点として、システムにはユーザー毎に１個ずつのセッション・キーを設けることができ、このキーをユーザーが任意に変更できる。
【００４２】
本発明はディジタル情報資産を捕捉し、保存し、管理し、検索するように構成されたアーカイブ管理システムの実現を容易にする。構成は多様な必要条件を考慮している：無制限の記憶、高度の信頼性、自主的管理、法規制の順守、ハードウェアの独立性、および既存アプリケーションとの融合。（例えば）Ｌｉｎｕｘを運用する商品ハードウェアのクラスタは堅牢なプラットホームと、実質的に無制限のアーカイブを可能にする。システムは、例えば、数個の記憶ノード・サーバーから数千テラバイトのデータを保存できる厖大な数のノードにまで拡張可能である。ユニークなアーキテクチャーは保存容量を組織の増大するアーカイブ需要にあわせて増大させることを可能にする。
【００４３】
本発明の幾つかの実施態様において行なわれるオペレーションの特定のシーケンスを説明したが、これらのシーケンスは飽くまでも説明の便宜上取上げたに過ぎず、実施態様によっては、異なるシーケンスでオペレーションを実行したり、いくつかのオペレーションを組み合わせたり、オーバーラップさせる、なども可能である。実施態様によっては特定の構成要件、構造または特性を有するが、必ずしもすべての実施態様がこれら特定の構成要件、構造または特性を含むとは限らない。
【００４４】
本発明を方法またはプロセスに関して説明したが、本発明はこれらのプロセスを実行す
る装置にも係わる。この装置は所要の目的に合わせて構成するか、または記憶されているコンピュータ・プログラムによって設定される汎用コンピュータで構成されるか、または設定される。このようなコンピュータ・プログラムはコンピュータ可読記憶媒体、例えば、光学的ディスク、ＣＤ‐ＲＯＭ，磁気-光学ディスク、読出し専用メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、磁気または光学カード、または電子的命令の記憶に好適な媒体などに記憶することができ、いずれもコンピュータ・システムのバスに接続している。
【００４５】
システムの所与のコンポーネントを別々に説明したが、当業者には明らかなように、機能の幾つかを所与の命令、プログラム・シーケンス、コード部分などにおいて組み合わせたり、振り分けることもできる。
【００４６】
上述のように、リクエスト・マネジャー・コンポーネントは保護マネジャーを利用することによって入ってくる書き込みに応じてアーカイブに記憶するとともに、ポリシー違反が検出されるとポリシーに適合させる。リクエスト・マネジャーがこの好ましいが、アプリケーションの他のコンポーネントを利用して保護マネジャーの機能を援護または提供することもできる。
【００４７】
本発明を以上に説明したが、その範囲を後記の請求項によって定義する。
【特許請求の範囲】
【請求項１】
ネットワーク化された独立ノードの冗長アレイから成り、それぞれのノードがオブジェクト系の記憶を行なわせるアプリケーションのインスタンスを実行するクラスタにおけるデータ機密保持方法であって、
ノードに亘ってキー断片の形で機密を共有させ；
クラスタのインストール時に、もし設定された個数のノードがそれぞれに割り振られたキー断片を提供できれば、キーを断片から復元するステップから成るデータ機密保持方法。
【請求項２】
キーの復元に協働するそれぞれのノードに少なくとも１つのドライブを実装するステップをも含む請求項１に記載の方法。
【請求項３】
クラスタの起動を完了するステップをも含む請求項２に記載の方法。
【請求項４】
所与のノードにおいて、割り振られたキー断片を使用することによって前記所与のノードに書き込まれるデータを暗号化するステップをも含む請求項１に記載の方法。
【請求項５】
キーを所与の暗号と連携させる請求項１に記載の方法。
【請求項６】
機密共有ステップに先立ってキーを生成するステップをも含む請求項１に記載の方法。
【請求項７】
キーをディスクに保存しない請求項１に記載の方法。
【請求項８】
キーを交換不能なメモリに記憶する請求項１に記載の方法。
【請求項９】
ノードの個数が少なくとも2個である請求項１に記載の方法。
【請求項１０】
キーがセッション・キーである請求項１に記載の方法。
【請求項１１】
クラスタに保存されているデータへのアクセスを防止する必要が生じたらキーを破壊するステップをも含む請求項１に記載の方法。
【請求項１】
ネットワーク化された独立ノードの冗長アレイから成り、それぞれのノードがオブジェクト系の記憶を行なわせるアプリケーションのインスタンスを実行するクラスタにおけるデータ機密保持方法であって、
ノードに亘ってキー断片の形で機密を共有させ；
クラスタのインストール時に、もし設定された個数のノードがそれぞれに割り振られたキー断片を提供できれば、キーを断片から復元するステップから成るデータ機密保持方法。
【請求項２】
キーの復元に協働するそれぞれのノードに少なくとも１つのドライブを実装するステップをも含む請求項１に記載の方法。
【請求項３】
クラスタの起動を完了するステップをも含む請求項２に記載の方法。
【請求項４】
所与のノードにおいて、割り振られたキー断片を使用することによって前記所与のノードに書き込まれるデータを暗号化するステップをも含む請求項１に記載の方法。
【請求項５】
キーを所与の暗号と連携させる請求項１に記載の方法。
【請求項６】
機密共有ステップに先立ってキーを生成するステップをも含む請求項１に記載の方法。
【請求項７】
キーをディスクに保存しない請求項１に記載の方法。
【請求項８】
キーを交換不能なメモリに記憶する請求項１に記載の方法。
【請求項９】
ノードの個数が少なくとも2個である請求項１に記載の方法。
【請求項１０】
キーがセッション・キーである請求項１に記載の方法。
【請求項１１】
クラスタに保存されているデータへのアクセスを防止する必要が生じたらキーを破壊するステップをも含む請求項１に記載の方法。
【図２】
【図１】
【図３】
【図４】
【図５】
【図６】
【図１】
【図３】
【図４】
【図５】
【図６】
【公表番号】特表２０１０−５３０５６２（Ｐ２０１０−５３０５６２Ａ）
【公表日】平成２２年９月９日（２０１０．９．９）
【国際特許分類】
【出願番号】特願２０１０−５０７６２４（Ｐ２０１０−５０７６２４）
【出願日】平成２０年５月７日（２００８．５．７）
【国際出願番号】ＰＣＴ／ＵＳ２００８／０６２９２３
【国際公開番号】ＷＯ２００８／１３７９３９
【国際公開日】平成２０年１１月１３日（２００８．１１．１３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
２．ＥＴＨＥＲＮＥＴ
３．ＵＮＩＸ
【出願人】（５０８２４８１４０）アーカイヴァス インコーポレイテッド (3)
【Ｆターム（参考）】
【公表日】平成２２年９月９日（２０１０．９．９）
【国際特許分類】
【出願日】平成２０年５月７日（２００８．５．７）
【国際出願番号】ＰＣＴ／ＵＳ２００８／０６２９２３
【国際公開番号】ＷＯ２００８／１３７９３９
【国際公開日】平成２０年１１月１３日（２００８．１１．１３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
２．ＥＴＨＥＲＮＥＴ
３．ＵＮＩＸ
【出願人】（５０８２４８１４０）アーカイヴァス インコーポレイテッド (3)
【Ｆターム（参考）】
[ Back to top ]