JP2009506405A - データアーカイブシステム - Google Patents

Abstract

暗号化されたファイルストレージソリューション（ｆｉｌｅ ｓｔｏｒａｇｅ ｓｏｌｕｔｉｏｎ）は、処理ノードのクラスタ、外部データストレージ、及びアプリケーションサーバーにインストールされたソフトウェアエージェント（「ファイルシステムウォッチャ（Ｆｉｌｅ Ｓｙｓｔｅｍ Ｗａｔｃｈｅｒ）」）で構成されている。１つのノードから最大数百ノードまでのクラスタサイズに対応できる。１つ又は複数のクラスタにさまざまなサービスを提供するリモート「キーサーバー（Ｋｅｙ Ｓｅｒｖｅｒｓ）」も存在する。以上は好ましい実施形態を説明しているが、いくつかの事例では一部の機能をより少ない数のハードウェアデバイスに「縮小（ｃｏｌｌａｐｓｅ）」し、一般的にコストとセキュリティ及びフォールトトレランスとのバランスをとるのが望ましい場合もある。
【選択図】 図３

Description

関連出願の相互参照

本出願は、２００５年８月９日に出願され、参照により本明細書に援用されている米国仮出願第６０／７０６，４２５号の優先権を主張するものである。

発明の分野

本発明は、一般にファイルの保存及び管理に関する。より具体的には、安全なファイルシステムにファイルを保存することによって、ファイルの正確な登録日、コンテンツ認証、及び不変性（ｉｍｍｕｔａｂｉｌｉｔｙ）を提供する方法に関する。又、ファイルの暗号化を実施できることによって、セキュリティが保証され、暗号ベースのファイルの削除が可能になる。

発明の背景

多くの企業や政府機関はデータを収集しており、データを保存し、保持する方法を指定する規制によって管理されている。さまざまなタイプのデータは、さまざまなタイプの規制に準拠している。データは、多くの場合に操作から保護されており、監査証跡（ａｕｄｉｔ ｔｒａｉｌ）を作成せずにデータに変更を加えることが困難又は不可能であるようにする必要がある。

多くの会計報告に関する規制では、特定のタイプのデータは規制機関による試験に備えて一定期間にわたって保守しなければならないとしている。それ以外のデータ（たとえば顧客の会計データや医療の記録）は、不注意による放出から保護される必要があり、指定された期間のみ保守される必要がある。このことは、１つのデータセットを第１の期間にわたって保守する必要があり、別のデータセットをそれより短い期間を超えて保存できない機関にとって難題となる可能性がある。

ほとんどの企業環境において、データは集中ファイルシステム（ｃｅｎｔｒａｌｉｚｅｄ ｆｉｌｅ ｓｙｓｔｅｍ）に保存される。アクセス権などの安全対策（Ｓａｆｅｇｕａｒｄｓ）を実装することによって、サーバー上のさまざまなタイプのデータへの差別的又は段階的なアクセスを実現できる。データのセキュリティを保証するために、通常、中央ファイルリポジトリ（ｃｅｎｔｒａｌ ｆｉｌｅ ｒｅｐｏｓｉｔｏｒｙ）はバックアップされ、破局的なデータ喪失が発生した場合の回復機能が提供されている。データをバックアップする場合に、通常はすべてのデータがテープなどの唯一のバックアップメディアエレメント（ｂａｃｋｕｐ ｍｅｄｉａ ｅｌｅｍｅｎｔ）に保存されることになる。したがって、こうしたバックアップでは２つの相容れない保存期間にわたって保存する必要がある。一部のデータは保存する必要があり、その他のデータは保存してはならない。

さらに、公判（ｃｏｕｒｔ ｐｒｏｃｅｅｄｉｎｇｓ）又は監査が進行中の場合は、要求された削除に対応するバックアップの廃棄は禁止されている。この結果、特定の事例に関連付けられた文書を無期限に保持（ｒｅｔｅｎｔｉｏｎ）することが必要になる。すべてのストレージデバイス及び個々のバックアップメディアを検索して関心のあるデータを検出するのはきわめて困難であり、当然のことながら、命令された期間にわたってこうしたメディアを保管する必要がある。完全に準拠できなかった場合は、最も極端な制裁措置として、一部の事例では刑事告発に発展する可能性もある。一方、指定された任意のバックアップメディアには裁判所の命令には関係のない膨大な数の事例に関連する情報が保存されており、その無期限の保管によって、前述の無関係なデータは廃棄しないことが賢明であり、法的に必要な場合はそうした結果になる。

関心のある情報の内容を検索できるようにするには、通常はバックアップテープを「リストア（ｒｅｓｔｏｒｅ）」（すなわち、ハードディスクにコピーバック）する必要があるという事実によって、問題はさらに悪化する。この作業は労働集約的（ｌａｂｏｒ−ｉｎｔｅｎｓｉｖｅ）で時間がかかるだけでなく、一般的にはリストア操作を実行するハードウェアセットの複製が必要である。データを作成したシステムは全面的に日常業務の実行に利用されている可能性が高いためである。多くの場合に文書作成の期限は約４８時間であり、一般的な企業ですべてのバックアップテープをロードし、検索するには通常は不十分である。

従来のデータセンターパラダイム（ｄａｔａ ｃｅｎｔｅｒ ｐａｒａｄｉｇｍ）は、サーバー、外部のプライマリストレージ（通常はストレージエリアネットワーク（ＳＡＮ：Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）によって接続される）、及びバックアップテープドライブ（通常は「ライブラリ」の形をとり、いくつかのテープドライブと数十、数百のテープメディアカセットを備えるロボティックアセンブリ（ｒｏｂｏｔｉｃ ａｓｓｅｍｂｌｙ）で構成されている。これは、さまざまな理由により、多くの規制に準拠するには適していない。

ストレージネットワークのシステム管理者には十分なアクセス権があるので、管理者はビジネスレコード（ｂｕｓｉｎｅｓｓ ｒｅｃｏｒｄ）の追加、削除、又は変更をひそかに実行し、法的機関による検査（ｆｏｒｅｎｓｉｃ ｅｘａｍｉｎａｔｉｏｎ）でこうした操作が判明しないようにすることができる。大企業では、多くの担当者に管理者権限が付与されている可能性が高いので、改ざん（ｔａｍｐｅｒｉｎｇ）が行われたことが判明しても、責任者を特定すること（又は、実際に全くの計画的な行為であり、不慮の事故でもソフトウェアの機能不全でもないと断定すること）はできない。さらに、前述の理由により、１つのバックアップメディアから指定のレコードを「外科的に（ｓｕｒｇｉｃａｌｌｙ）」削除する方法はないので、文書の保持期間を厳密に守ることを強制するのは実際的ではない。

従来のデータセンターでは、プライマリストレージデバイス上のデータもバックアップメディア上のデータも暗号化しないので、ハッカー又はバックアップメディアを保管設備（ｓｔｏｒａｇｅ ｆａｃｉｌｉｔｙ）に輸送中の紛失や物理的な盗難に対してぜい弱になる。

こうした従来のデータセンターの欠点に対処する試みがなされてきた。一般的に使用されている１つのアプローチは、いわゆる「ＷＯＲＭ」（Ｗｒｉｔｅ Ｏｎｃｅ Ｒｅａｄ Ｍａｎｙ）メディアにビジネスレコードを保存することである。ただし、ＷＯＲＭメディアは通常のコンピュータメディアより安全であると認識されている。しかし、ＷＯＲＭのアプローチにはいくつかの重大な弱点がある。第１に、ＷＯＲＭメディアは低速で信頼性が低い傾向がある。第２に、文書を指定された保持期間にわたって保持するためには、期限（ｅｘｐｉｒｙ ｄａｔｅｓ）が近い文書を１つの指定されたＷＯＲＭメディア上にまとめ、適切な期日に１つの単位として廃棄できるようにする必要がある（たとえば、シュレッダー処理又は消却による）。後でバックアップするためにデータをセグメントに分割するのは、実際のアーカイブでは困難である。残念ながら、裁判所の命令又は規制の命令がＷＯＲＭメディア（何ギガバイトものサイズで数百万のファイルが保存されている）上の唯一のファイルに適用されることが判明した場合は、それ以外のファイルを廃棄するのが望ましいか又は必要な場合でも、このＷＯＲＭメディア全体を保管する必要がある。さらに、認識されているＷＯＲＭメディアの改ざん耐性（ｔａｍｐｅｒ ｒｅｓｉｓｔａｎｃｅ）はほとんど錯覚である。ＷＯＲＭメディアの内容を犯罪者のコンピュータにコピーし、こうしたコピーに任意の変更を加え、この不正な（ａｄｕｌｔｅｒａｔｅｄ）データを新しいＷＯＲＭメディアにリライトし、さらにこの新しいメディアを古いメディアとすり替える作業は技術的に簡単なためである。最後に、ＷＯＲＭメディアは通常はオフラインで（たとえばクローゼットの箱の中に）保管されているため、データの完全性と安定性を自動的に監査する方法はない。裁判所又は規制当局にデータを提示する場合は、そのときに初めて読み出し不可能なことや不備があることに気付く場合もある。

こうしたＷＯＲＭメディアの制限に対処するために、新しいタイプのストレージ機器（ｓｔｏｒａｇｅ ｅｑｕｉｐｍｅｎｔ）が開発され、特に固定のコンテンツデータ（ｆｉｘｅｄ ｃｏｎｔｅｎｔ ｄａｔａ）のニーズに合わせて設計された。続いて改ざん防止技術を追加したいくつかの改良型（ｖａｒｉａｎｔｓ）が開発され、こうしたタイプは一般的に「準拠ストレージ（ｃｏｍｐｌｉａｎｔ ｓｔｏｒａｇｅ）」デバイスと呼ばれている。

一般的な「準拠ストレージ」デバイスは、ＥＭＣ Ｃｏｒｐｏｒａｔｉｏｎ製のＣｅｎｔｅｒａ（商標）である。このデバイスは、データの不注意による変更や計画的な改ざんが発生してないことを保証するなど、従来のストレージデバイスのいくつかの制限には対処しているが、すべての問題に対処しているわけではない。データはユニット内にあるときには暗号化されておらず、データをテープや光学メディア（ｏｐｔｉｃａｌ ｍｅｄｉａ）にバックアップできるので安全ではない。さらに、こうしたアーキテクチャにはデータの読み出しと書き込みのための業界標準のアクセスメカニズムを含まない独自のＣｅｎｔｅｒａ ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を組み込む必要がある。最後に、中立的なサードパーティーが管理対象のレコードとこうしたレコードが作成された日付と時刻の完全性を証明できるメカニズムを提供しない。

先行技術による「準拠ストレージ」デバイスのもう１つの制限は、モバイルコンピューティングデバイス（たとえばノートブックコンピュータ（ｌａｐｔｏｐ ｃｏｍｐｕｔｅｒｓ））やリモートオフィス（ｒｅｍｏｔｅ ｂｒａｎｃｈ ｏｆｆｉｃｅｓ）から自動的に資産（ａｓｓｅｔｓ）を収集できる機能を備えていないことである。こうしたデバイスのさらなる制限は、光ディスク（ｏｐｔｉｃａｌ ｐｌａｔｔｅｒｓ）やテープのようなオフラインメディア上のファイルを削除するメカニズムを提供しないことである。

したがって、期限を過ぎた情報を削除する機能を備えているが、安全な監査証跡を残さずにシステムのデータやコンテンツを変更する機会を提供しないファイルストレージソリューションを提供するのが望ましい。

発明の概要

本発明の目的は、従来の暗号化ファイルストレージソリューションの少なくとも１つの欠点を排除又は軽減することである。

本発明の第１の態様では、受信されたファイルを保存する方法が提供される。本方法は、ファイルに関連付けられたメタデータのセットと固有のファイル識別子をアセンブル（ａｓｓｅｍｂｌ）するステップと、ファイルを資産として保存するステップと、ファイルに関連付けられたメタデータを保存された資産に関連付けるデータレコードを作成するステップとを備えている。

第１の態様の実施形態において、ファイルを資産として保存するステップには、ファイルを暗号化することによって資産を作成するステップが含まれており、このステップには対称暗号化キー（ｓｙｍｍｅｔｒｉｃａｌ ｅｎｃｒｙｐｔｉｏｎ ｋｅｙ）を取得するステップと、このキーをファイルに一対一に関連付けるステップと、こうした資産を保存するステップとを含めてもよい。他の実施形態では、本方法にはデータレコードとして暗号化するステップの前に、ファイルにタイムスタンプを関連付けるステップがさらに含まれる。固有のファイル識別子には、ファイルコンテンツの暗号学的ハッシュの連結（ｃｏｎｃａｔｅｎａｔｉｏｎ ｏｆ ｃｒｙｐｔｏｇｒａｐｈｉｃ ｈａｓｈｅｓ）を含めることができ、ＭＤ−５、ＳＨＡ−１、ＳＨＡ−２２４、ＳＨＡ−２５６、ＳＨＡ−３８４、及びＳＨＡ−５１２から選択されたハッシュとしてこうした暗号学的ハッシュが含まれる。固有のファイル識別子にはさらにファイルサイズも含めることができ、メタデータにはファイルに関連付けられたシリアル番号と必要に応じて暗号化キーを含めることができる。データレコードを作成するステップには、指定された期間内に保存された資産のシリアル番号付きのリストを含むストレージマニフェスト（ｓｔｏｒａｇｅ ｍａｎｉｆｅｓｔ）にエントリを追加するステップが含まれる。本方法には、ストレージマニフェストを閉じるステップと、ストレージマニフェストを資産として保存するステップとをさらに含めることができ、このステップにはストレージマニフェストに関連付けられたメタデータのセットをアセンブルするステップと、ストレージマニフェストを暗号化して資産を作成するステップと、資産を保存するステップと、マニフェストに関連付けられたメタデータを保存された資産に関連付ける新しいストレージマニフェストへのエントリを作成するステップとが含まれる。

本発明の第２の態様では、監査可能な（ａｕｄｉｔａｂｌｅ）データストレージシステムにデータを保存する方法が提供される。本方法は、監査可能なデータストレージシステムに保存するために受信したファイルに関連付けられたデータをマニフェストに記録するステップと、マニフェストを閉じるステップと、マニフェストを監査可能なデータストレージシステムにファイルとして保存するステップと、監査可能なデータストレージシステムに保存するために受信したファイルに関連付けられた新しいマニフェストを作成するステップとを備えており、新しいマニフェストは前のマニフェストをエントリとして備えている。

本発明の第２の態様の実施形態において、記録するステップには、保存するために受信したファイルのそれぞれに関連付けられた固有のファイル識別子、ファイルサイズ、シリアル番号、暗号化キーの識別情報、及び保持情報を保存するステップとを含めることができる。固有のファイル識別子は、該当するファイルの少なくとも２つの暗号学的ハッシュに従って決定でき、該当するファイルの少なくとも２つの暗号学的ハッシュの連結でもよい。マニフェストを閉じるステップは、マニフェストが作成されてから事前に指定された期間が経過した後に実行できる。新しいマニフェストを作成するステップには、前のマニフェストに関連付けられた固有のファイル識別子を新しいマニフェストの最初のエントリとして記録するステップを含めることができ、この固有のファイル識別子には閉じたマニフェストのコンテンツの暗号学的ハッシュの連結が含まれている。マニフェストを閉じるステップには、保存されたマニフェストのコピーを信頼できるサードパーティーに転送するステップを含めることができる。

本発明の第３の態様では、ファイルを監査可能なファイルシステムに保存するデータアーカイブシステム（ｄａｔａ ａｒｃｈｉｖｉｎｇ ｓｙｓｔｅｍ）が提供される。データアーカイブシステムは、ストレージアレイ（ｓｔｏｒａｇｅ ａｒｒａｙ）、ストレージマネージャ（ｓｔｏｒａｇｅ ｍａｎａｇｅｒ）、及びマニフェストエンジン（ｍａｎｉｆｅｓｔ ｅｎｇｉｎｅ）を備えている。ストレージアレイは、資産を保存する。ストレージマネージャは、データアーカイブシステムによって受信されたファイルを資産としてストレージアレイに保存する。マニフェストエンジンは、ストレージマネージャによって資産として保存されたファイルに関連付けられたデータを受信し、受信したデータをマニフェストに保存することによって、ストレージアレイに保存された資産の監査可能なログを作成する。

本発明の第３の態様の実施形態において、ストレージアレイは独立したドライブの冗長なアレイであり、ストレージマネージャには受信したファイルの少なくとも１つを保存する前に暗号化する暗号化エンジンが含まれる。受信したデータには、ストレージマネージャがファイルを暗号化するときに使用する暗号化キーの識別情報を含めることができ、暗号化エンジンには外部のキーサーバーから取得された暗号化キーのキャッシュを保存するキーマネージャを含めることができる。マニフェストエンジンには、既存のマニフェストをマニフェストが作成されてからあらかじめ指定された時間が経過した後に閉じ、閉じたマニフェストを資産として保存するファイルとしてストレージマネージャに提供し、既存のマニフェストを閉じるときに新しいマニフェストを作成し、さらに閉じたマニフェストを資産として保存するときに閉じたマニフェストを信頼できるサードパーティーに提供するマニフェスト管理ユニット（ｍａｎｉｆｅｓｔ ｍａｎａｇｅｍｅｎｔ ｕｎｉｔ）を含めることができる。ストレージマネージャによって保存されたファイルに関連付けられた受信データには、資産に関連付けられた固有のファイル識別子、ファイルサイズ、シリアル番号、保持ポリシー、及び暗号化キーの識別情報の少なくとも１つを含めることができる。データアーカイブシステムには、さらにストレージアレイに保存され、削除するようにマーク付けされた資産をリストアップする廃棄（ｄｉｓｐｏｓｉｔｉｏｎ）マニフェストを作成し、廃棄マニフェスト内の資産をアクセス不能にするための認可（ａｕｔｈｏｒｉｚａｔｉｏｎ）を受けたときにこうした資産をアクセス不能にする廃棄エージェントをさらに含めることもできる。廃棄エージェントには、保存された資産のそれぞれに関連付けられた保持ポリシー（ｒｅｔｅｎｔｉｏｎ ｐｏｌｉｃｉｅｓ）に従って廃棄マニフェストを作成する保持ポリシーエージェントを含めることもできる。廃棄エージェントには、さらに認可を受けたときにアクセス不能にする廃棄マニフェストにリストアップされた資産に関連付けられた暗号化キーを削除する暗号化キー削除手段を含めることもできる。

本発明のその他の態様及び機能については、以下に示す本発明の特定の実施形態の説明と添付の図面を関連付けながら参照することによって、当業者には理解されるであろう。

ここで、単に例として添付の図面に関連付けながら本発明の実施態様について説明する。

詳細な説明

本発明は、一般にファイルをデジタル資産として長期間にわたってアーカイブする方法及びシステムを提供する。

以下で説明するシステムのエレメントは、本発明を逸脱することなくモジュール方式で実装することができる。したがって、本発明の意図された範囲を必ずしも逸脱することなく、本システムに対して機能の追加及び削除が可能である。

本発明のシステムは、ファイルを作成するユーザー、ファイルを配置するディレクトリ、及び当業者には明らかであろうその他の基準を含む任意の数の基準に基づくストレージプロファイルを保持する機能を提供する。

本発明は、データのセキュリティを保証するために、ファイルごとに固有のキーに基づくデータ暗号化を利用している。本発明のデータアーカイブシステムにファイルが挿入されると、このファイルは暗号化され、資産として保存される。固有のファイル識別子（ｕＦＩＤ：ｕｎｉｑｕｅ ｆｉｌｅ ｉｄｅｎｔｉｆｉｅｒ）は、資産のコンテンツから計算され、データベース内で保守される。ｕＦＩＤは、ファイルのコンテンツに従って指定されたファイルごとに一意であるように決定されるのが好ましい。さらにシリアル番号も資産に割り当てられる。メタデータには、作成日、及びファイルの保持期間を決定するために使用できるその他の情報を含めることができる。本発明の１つの実施形態では、資産に関連付けられたｕＦＩＤ、シリアル番号、及びその他の情報は、「マニフェスト」と呼ばれるリスト形式のファイルに保存される。

マニフェストにリストアップされた資産にシリアル番号が付いているため、後日の監査によってデータレコードが完全であることが保証される。マニフェスト自体を、資産に変換されるファイルとしてファイルシステム内に保存できる。したがって、各マニフェストには前のマニフェストがリストアップされる。マニフェスト内のシリアル番号付きのエントリを削除すると、欠番が出ることから明らかになるであろう。一方、各マニフェストが後続のマニフェストに組み込まれることによって、後続のすべてのエントリに番号を付け直す作業は困難になる。ｕＦＩＤに資産に関する情報（たとえばファイルコンテンツの暗号学的ハッシュ及びファイルサイズ）を含めると、マニフェストの改ざんはさらに困難になる。これが実装された場合は、マニフェストの改ざんは時間がかかるだけでなく計算も複雑になる。

ファイルごとに異なる暗号化キーを使用することにより、暗号化キーを保存するデータベースエントリを除去することによって、データアーカイブシステムからファイルを個別に削除できる。十分に安全な暗号化の方法を使用する限り、暗号化された資産のデータを回復するのは実質的に不可能であろう。このようにして、暗号化された資産をテープやオプティカル（ｏｐｔｉｃａｌ）などのオフラインメディアに安全にバックアップすることができる。資産の削除は実質的に資産の復号化に必要なキーの削除によって実現できるため、期限の異なる資産が存在しても問題は発生しない。この技術は、暗号化キースクラブと呼ばれている。

本発明のシステムの実装について、実例を示すために以下で詳細に説明するが、以下の説明は範囲を限定するものと理解されてはならない。複数のコンピュータシステムを使用する場合について説明されているが、これは冗長なエレメントを使用することによって予期しない障害を回避できる現在の好ましい実施形態にすぎない。本発明のシステムは、意図された保護の範囲を逸脱することなく、単一システムにも実装できる。さらに、個別の機能として示されたマスターキーサーバーなどのエレメントを、本発明のデータアーカイブシステムに統合することもできる。こうしたエレメントは、以下の説明及び図面ではさらに高レベルのデータセキュリティを提供し、オペレータの改ざんに対してさらなる安全対策を実現するために、個別のエンティティとして示されている。

本発明の１つの実施態様において、本発明のデータアーカイブシステムは相互に接続された複数のコンピュータシステム又は「ノード」を使用して実装されている。複数のコンピュータシステムを利用することにより、冗長性と機能分散が実現され、単一障害点が回避される。相互に接続されたコンピュータシステムのそれぞれには、さまざまなソフトウェアモジュールがインストールされている。データは、ＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙｓ ｏｆ Ｉｎｄｅｐｅｎｄｅｎｔ Ｄｒｉｖｅｓ）アレイのように一定レベルの冗長性を提供するファイルストレージシステムに保存するのが好ましい。

現在の好ましい実施形態では、２つのフロントエンドノードは２つのバックエンドノードに接続されているので、フロントエンドノードとバックエンドノードの間で作業負荷の分散が可能になり、アクティブな冗長性が提供される。バックエンドノードは、そのデータストレージ要件に適合するＲＡＩＤアレイを利用するのが好ましい。

データアーカイブシステムに接続するクライアントコンピュータ上では、Ｆｉｌｅ Ｓｙｓｔｅｍ Ｗａｔｃｈｅｒ（ＦＳＷ）モジュールが実行され、データアーカイブシステムに保存する必要のあるデータを監視する。本データアーカイブシステムに保存するための要件に適合するファイルが保存されると、ＦＳＷは本データアーカイブシステムに接続してファイルを転送する。

本データアーカイブシステムにはキーサーバーが接続されており、キーサーバーは冗長なキーサーバーによってバックアップされるのが好ましい。キーサーバーは、地理的に離れた場所に配置することによって、キーサーバー改ざんの可能性を排除することができる。キーサーバーは、信頼できるサードパーティー（ＴＴＰ：ｔｒｕｓｔｅｄ ｔｈｉｒｄ ｐａｒｔｙ）によってホストされるのが有利であろう。最高のパフォーマンスを実現するために、暗号化と復号化を必要とするデータアーカイブシステムの一部又はすべてのノードにハードウェアベースの暗号処理アクセラレータチップ又はカードをインストールしてもよい。

前述のように、「フロントエンド」と「バックエンド」ノードの間で作業負荷を分散でき、フロントエンドとバックエンドの両方で冗長性が提供される。一般に、フロントエンドノードはユーザーと対話し、バックエンドノードはユーザーから隔離されている。こうした設計により、ユーザーに影響を及ぼすことなくバックエンドノードを変更する操作が可能になる。ユーザーコンピュータにインストールされているＦＳＷを使用すると、フロントエンドノードはＦＳＷとデータアーカイブシステムとの間のインターフェースとして動作する。これで、バックエンドノードは暗号化、ストレージ、マニフェスト、及びメタデータデータベースマネジメントを管理できる。本データアーカイブシステム内のノード間通信は、従来のコンピュータネットワーキング技術（たとえば、Ｅｔｈｅｒｎｅｔ、トークンリング、及び他の同様のネットワーキング技術）を使用して実行できる。バックエンドノードからデータストレージデバイスへの接続は、同様に標準的なストレージ接続技術（たとえばファイバチャネル）を使用して作成できる。

ＦＳＷは、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ、Ｌｉｎｕｘ、Ａｐｐｌｅ’ＯＳ Ｘ、Ｓｕｎ’ｓ Ｓｏｌａｒｉｓ、及び他の一般的なプラットフォーム（ＢＳＤ Ｕｎｉｘなど）を含むさまざまなコンピューティングプラットフォームに実装できる。接続されたコンピュータからＦＳＷインスタンスの接続を受信すると、フロントエンドノードはＦＳＷクライアントの認証、タイムスタンプサービス、管理サービス、設定サービス、及びサービスマネージャアプリケーションを含む多くのサービスを提供できる。資産として保存するために受信したファイルは、フロントエンドノードによって提供されたタイムスタンプに関連付けられ、ファイルを作成するコンピュータのクロックに頼る必要がないようにするのが好ましい。こうしたタイムスタンプを作成するステップには、ファイルに関連付けられたＸＭＬファイル記述子にタイムスタンプを関連付けるステップを含めてもよい。タイムスタンプは、タイムスタンプサービスによって暗号学的に署名され、タイムスタンプの認証を提供することもできる。タイムスタンプは一般的なサービスであり、こうしたサービスの実装については当業者には十分に理解されるであろう。本データアーカイブシステムに接続するユーザーは、管理パネルへのアクセスを要求し、認可されたユーザーは設定を確認できるようにしてもよい。フロントエンドノードは、こうした設定の変更を行うためのインターフェースを提供できる（Ｗｅｂベースの設定ツールの提供によるもの、又はユーザーノード上のスタンドアロンアプリケーションから渡されたメッセージを受理する機能によるものなど）。グローバル設定を提供し、信頼できるクライアント、サーバー、及びユーザーのリストを管理者が保守でき、確認できるようにしてもよい。さらに、サービスマネージャを実装し、ノード間又はモジュール間のトランザクションを監視することもできる。要求されたトランザクションがタイムアウトの時間内に完了しない場合に、サービスマネージャはトランザクション要求を再発行できる。

バックエンドノードを実装し、バックエンドノードによって提供されるサービスに、顧客情報サービス（Ｃｕｓｔｏｍｅｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｉｃｅ）、ストレージサービス、キーマネージャサービス、マニフェストサービス、廃棄サービス、監査サービス、オブジェクトファイルサービス（ＯＦＳ：Ｏｂｊｅｃｔ Ｆｉｌｅ Ｓｅｒｖｉｃｅ）、及びサービスマネージャを含めることができる。顧客情報サービスを使用して、資産が保存されたときにこれを追跡するためのデータベースを管理できる。これにより、資産にシリアル番号を付け、このシリアル番号付きの資産に関連付けられたメタデータをキャッシングし、保存する唯一のエンティティが提供される。ストレージサービスは、物理ストレージデバイスへのインターフェースを提供する。このサービスによって、システムのストレージ以外の部分がストレージデバイスと対話するための定義済みのインターフェースが提供され、ストレージ以外の部分には透過なストレージデバイスの設計変更が可能になる。ストレージサービスは、接続されたＲＡＩＤサブシステムのペアに保存されたデータの冗長ストレージの管理を操作することもできる。キーマネージャサービスは、個々の資産の暗号化に使用するキーの操作と割り当てを行う。キーマネージャサービスは、キーが外部のエンティティで生成される場合に、ローカルにキャッシングされたセットが十分に少なくなったときの新しいキーの要求を担当するのが一般的である。マニフェストサービスは、ストレージに配置された資産のマニフェストをアセンブルする。１つの実施形態では、固定の間隔で、又は事前に指定された数の資産が保存された後に、或いはその両方の組合せに基づいて、マニフェストが作成される。マニフェストは、通常は、ＸＭＬ形式のメッセージなどのファイルであり、シリアル番号付きの資産を追跡する。マニフェストが完成すると、タイムスタンプサービスを使用してデジタル署名することによって、マニフェストが改ざんされず、マニフェストを資産として保存できることを保証できる。マニフェストを資産として保存することにより、マニフェストは次のマニフェストに記録される最初のエントリになる。一連のマニフェストを調べると、各マニフェスト（最初のマニフェストを除く）の最初のエントリは前のマニフェストと前のマニフェストに関連付けられたｕＦＩＤである。マニフェストは容易には改ざんできない。改ざんするとｕＦＩＤが変更され、次のマニフェストに記録されるためである。このように、マニフェストを変更するには後続のすべてのマニフェストを変更する必要がある。したがって、安全なタイムスタンプ作成プロセスを使用することにより、証跡を残さずにマニフェストを変更するのは困難であろう。さらに、マニフェストをキーサーバーに提供することによって、保存されたマニフェストを既知の適正なコピーと比較することができる。このように、何者かが資産を変更しようとすると、資産がマニフェストに記録されており、証跡を作成せずにマニフェストを変更することはできないという事実によって、変更は明らかになる。資産が削除されると、資産にシリアル番号が付いていることによって削除が判明する。一連のシリアル番号に欠番が出るためである。このようにして、マニフェストに関連付けられたｕＦＩＤや他のファイル関連情報などの情報は、キャリーフォワード方式（ｃａｒｒｙ ｆｏｒｗａｒｄ ｍａｎｎｅｒ）で保存される。こうしたキャリーフォワード方式（ロシアンドール（Ｒｕｓｓｉａｎ−ｄｏｌｌ）ストレージの方法とも呼ばれる）では、１つのマニフェストが後続のマニフェストのエントリとして組み込まれる。資産のｕＦＩＤを再計算し、再計算されたｕＦＩＤとマニフェストに保存されたｕＦＩＤを検証してから、マニフェストのｕＦＩＤを検査することによってその妥当性（ｖａｌｉｄｉｔｙ）を検査する監査のプロセスは、容易に実装することができる。最新のマニフェストから開始し、前のマニフェストのｕＦＩＤを調べて、対応するマニフェストのｕＦＩＤを計算することによって、マニフェストを検査できる。さらに、こうした検査を再帰的に繰り返すことによって、マニフェストチェインが改ざんされていないことを保証できる。

廃棄サービスは、ストレージに保存された資産の期限を検査するのに使用される。資産に関連付けられたメタデータ内で設定された期限に基づいて削除される資産のリストを作成でき、このリストを使用して暗号化キースクラブプロセスを実行できる。削除するファイルのリストをキーマネージャに提供でき（場合によってはオペレータが承認した後に）、資産に関連付けられた暗号化キーを削除できる。実際のストレージから資産を削除することもできる。バックアップから資産を入手できる場合も、キーマネージャ及びキーサーバーから暗号化キーを削除することによって、資産を回復できないことが保証される。監査サービスは保存された資産をスキャンし、これを関連のメタデータ内の情報と比較することによってファイルが改ざんされないことを保証できる。メタデータには、資産の暗号学的ハッシュなどの情報を保存でき、資産が変更されたかどうかを判断する簡単な検査が可能になる。保存されたマニフェストにファイルの不正な変更がないかを検査することもできる。ＯＦＳサービスは、使用されていない一時ファイルの消去、不要なトランザクション監視ログの削除、及び資産のオンラインキャッシュの管理などのハウスキーピング作業を実行するために使用できる。サービスマネージャは、フロントエンドノードと同様に、バックエンドノードの内部と外部ノードの両方のサービス間の対話を追跡し、タイムアウト時間が経過しても実現されていないトランザクションが再発行されることを保証する。

バックエンドシステムに関連して説明したように、暗号化キーはＴＴＰによってホストできる外部のキーサーバーで生成できる。このことによって、キーをまとめて生成でき、キーマネージャによって要求できるキーページとして準備できる。こうしたキーは、対称暗号化キーとして１度だけ使用できるように設計されているが、非対称キーペア（ａｓｙｍｍｅｔｒｉｃａｌ ｋｅｙ ｐａｉｒｓ）として生成することもできる。データアーカイブシステムで複数のキーサーバーによる冗長性を利用できるように、少なくとも２台のキーサーバーが互いに地理的に遠く離れて存在するのが好ましいであろう。キーサーバーは、正確で改ざんに強い日付と時刻の値を提供するＳｔｒａｔｕｍ １タイムサーバーデバイスのようなタイムサーバーデバイス（ｔｉｍｅ ｓｅｒｖｅｒ ｄｅｖｉｃｅ）に接続してもよい。こうした値は、受信したマニフェストのタイムスタンプをさらに確認するものとしてマニフェストとともに保存することができる。暗号化キーをリモート生成することの利点は、キーがファイルの暗号化に使用される前に遠隔地で安全に複製されるという保証が得られることである。

現在の好ましい実施形態では、サービスのそれぞれが他のサービスへの抽出された（ａｂｓｔｒａｃｔｅｄ）メッセージパッシング（ｍｅｓｓａｇｅ−ｐａｓｓｉｎｇ）インターフェースを使用して設計されている。これには、指定されたサービスのインスタンスのリストを保有する機能が含まれる。同じサービスの複数のインスタンスを実行することにより、サービスの特定のインスタンスが使用できなくなっても操作を続行できる。さらに、任意の数のサービスインスタンスを実装することによって、本発明のストレージシステムを提供するクラスタシステムのサービス対象となる数のノードのパフォーマンスを調整できるようになる。１つの操作モードでは、サービスのラウンドロビン方式の（ｒｏｕｎｄ−ｒｏｂｉｎ）選択を使用して適切な負荷分散が実現されるようにしている。インターフェースが抽出されることにより、同一のサーバーハードウェア上でも、ＬＡＮ上で接続されたクラスタサーバー間でも、或いは数千マイルも離れてＷＡＮ又はインターネットを経由して接続されたノード間でさえも、サービスは相互に通信することができる。任意の数のノードにサービスを展開できることにより、ノードの数及びノードあたりのサービスの数を変更でき、コスト／パフォーマンスを容易に両立できる。

本発明の１つの実施形態の動作では、キーサーバーは初期化のプロセスでＣＤ−ＲＯＭから月次のマスターキーを読み出し、復号化してそのキーデータベースの整合性を検査する。。このデータベースは、一般にサーバーに直接接続されたローカルディスクドライブ上にある。キーサーバーは、リモートサイトに配置されるのが理想的であり、通常は少なくとも２台のサーバーが中立的立場の信頼できるサードパーティーによってホストされている。

顧客サイト（ｃｕｓｔｏｍｅｒ ｓｉｔｅ）では、キーマネージャが起動すると、キーマネージャもＣＤ−ＲＯＭからマスターキーをロードしてさまざまな整合性検査を実行し、さらにキーサーバーに要求を送信し、そのコードページ（Ｃｏｄｅ Ｐａｇｅｓ）を更新する必要があるかどうかを確認する。コードページは暗号化されたコンテナであり（そのキーはマスターキーによってさら暗号化されたテーブルに保存される）、個別のレコードを大量に保持している。各レコードは、キー、シリアル番号、及びその他のハウスキーピング情報を備えている。コードページのサイズの大小は任意であるが、１つの実施形態では５，０００個の個別のキーレコードを保持している。期限切れのキーがある場合に、キーサーバーは期限切れのキーが削除された更新済みのコードページをキーマネージャに送信する。キーマネージャは、キーサーバーが提供した改訂版のコードページで古いコードページを上書きする。

キーは直ちにかつ大量に必要になるので、キーマネージャは多くのコードページを要求し、さらにコードページをローカルにキャッシングすることができる。内蔵のハードドライブを使用してコードページを保存してもよい。キャッシングされたキーの数がしきい値を下回ると、キーマネージャは別のコードページセットをキーサーバーから要求する。これは、ユーザーデータを暗号化するプロセスから切り離された非対称のプロセスでもよい。指定された任意の時間に、使用に備えている何万個もの個別のキーレコードがキーマネージャ内に存在できる。

Ｆｉｌｅ Ｓｙｓｔｅｍ Ｗａｔｃｈｅｒ（ＦＳＷ）クライアントは、ユーザーのコンピュータを監視し、一連の設定可能な基準を満たす新しいファイルを探す。ファイルが基準を満たす場合は、ファイルをデータアーカイブシステムに送信し、長期間にわたって保存する必要があることを表すものとして処理される。こうした基準は、単にファイルが指定されたディレクトリに配置されていること、ファイルが特定のファイルタイプの拡張子をもつこと、或いは管理者が要求するその他の基準でよい。

ＦＳＷは、このようなファイルを検出すると、それをフロントエンドノード上のＷｅｂサーバーに送信する。Ｗｅｂサービスは、ＦＳＷから送信された情報を含むＸＭＬフラグメント（ｆｒａｇｍｅｎｔ）を顧客情報サーバー（Ｃｕｓｔｏｍｅｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｅｒ）に送信する。次に、顧客情報サーバーはＸＭＬタイムスタンプサービスからタイムスタンプを要求し、タイムスタンプサービスはデジタル署名の時刻と日付を提供する。さらに、この情報はＷｅｂサービスによって他のメタデータと統合され、ストレージマネージャに送信される。ストレージマネージャは、ファイルを保存するＣＡＳアドレスとしてファイルに関連付けられた固有のファイル識別子（ｕＦＩＤ）を使用する。先行技術のデータ管理ユーティリティは、暗号学的ハッシュを使用して固有のファイル識別子を作成しようとしたのに対して、本発明はハッシュの衝突を軽減するメカニズムを提供する。ファイルがハッシュ化されると、ファイルは多対１のマッピングによって処理される。ハッシュの出力は、一般的にはファイルより短いので、あらゆるファイルサイズに関して一意とは見なされない。しかし、多くの場合にハッシュ（たとえばＭＤ５又はＳＨＡ−ｌハッシュ）はファイルサイズと併せて完全に固有の識別子を提供する。本発明において、固有のファイル識別子は既知のハッシュの結合によって作成されるのが好ましい。こうしたハッシュの結合によって、ハッシュの衝突の可能性は軽減される。ハッシュの衝突は、ファイルサイズの同じ２つの異なるファイルが同じハッシュ値にマップされた場合に発生する。十分に大きなファイルセットではＭＤ５又はＳＨＡ−１の衝突が発生する可能性があるが、ハッシュ値の結合によって衝突の可能性は指数関数的に減少する。各アルゴリズムでは異なる方法でハッシュを作成するため、ＭＤ５とＳＨＡ−１の両方についてファイルペアのハッシュの衝突が発生する確率は非常に低い。ハッシュの結合は、ハッシュ値の連結と同程度にシンプルでよい。こうした連結は、さらにファイルサイズを組み込むことによって一意性を向上できる。

ストレージマネージャは、さらに各ファイルのグローバルに固有のシリアル番号を発行するのが好ましい。こうしたシリアル番号は、顧客番号（ベンダーによって発行される）、インストール番号（たとえば、０００１は顧客が最初に購入したクラスタ、０００２は顧客が最初に購入したクラスタ、以下同様）、ユーザー定義の部門番号（ＦＳＷ設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ））、及びストレージマネージャが発行した連続するシリアル番号によって構成できる。システム管理者の要求に応じて、こうした情報の代わりにこれ以外の情報をシリアル番号にエンコードすることもできる。

ファイルコンテンツとファイルサイズのハッシュＭＤ５とＳＨＡ−１の連結で構成されるｕＦＩＤを作成することにより、ハッシュの衝突の確率は統計的に意味のない確率に軽減される。同一の方法によって両方のハッシュアルゴリズムが危険にされされる確率はきわめて低いので、１つのハッシュアルゴリズムで暗号を解読されることに関連付けられる問題も大幅に縮小される。資産に割り当てられた連続するシリアル番号と各資産のｕＦＩＤを関連付けることによって、証跡が作成され、マニフェストを調べて個々のシリアル番号が説明されることを確認し、マニフェスト内のファイルがそのｕＦＩＤに適合することを保証することによって、有効な監査プロセスを実現できる。マニフェスト内のエントリが削除されると、それは連番に欠番があることによって明らかになり、マニフェストのコピーに含まれるすべてのエントリに体系的に番号を付け直し、各ファイルを再び適切に暗号化して新しい資産を取得するのはきわめて困難である。証跡を作成せずにこの作業を行うのは不可能であろう。これは、マニフェストがそのｕＦＩＤ（マニフェストデータのハッシュが含まれる）とともに次のマニフェストで資産としてリストアップされるという事実によってさらに複雑になる。前述のように、マニフェストを変更し、しかもハッシュ値を維持できる確率は統計的に意味がないほど小さい。又、個々の資産へのアクセスを追跡する安全なアクセスログを実装し、各資産にだれがアクセスしたか、資産にいつアクセスしたかを示すことによって、特定のレベルのセキュリティを提供することもできる。これは、その他のセキュリティ機能と併用し、十分に堅牢な（ｒｏｂｕｓｔ）証跡を提供することによって簡単な監査のプロセスを実現できる。２人のユーザーが同じファイルをストレージシステムに保存しようとする場合に、システムは２つのシリアル番号を（２つの保存要求に応答して）割り当てるが、資産はそのｕＦＩＤによってインデックス付けできるので、ファイルの唯一のインスタンスが保存される必要があることを当業者は理解するであろう。ｕＦＩＤを保存のインデックスとして使用することにより、特定のファイルが重複して保存されるのを防止できるコンテンツアドレッサブルストレージ（ＣＡＳ：ｃｏｎｔｅｎｔ ａｄｄｒｅｓｓａｂｌｅ ｓｔｏｒａｇｅ）の形を実現できる。

ＦＳＷがファイルをデータアーカイブシステム（ＤＡＳ：Ｄａｔａ Ａｒｃｈｉｖｉｎｇ Ｓｙｓｔｅｍ）に挿入できると判断した場合は、ファイルをそのままの状態にしてコピーをＤＡＳに送信し、ＤＡＳ内のコピーをポイントするショートカットでファイルを置き換え、さらにファイルをディレクトリから削除するという３つの操作を実行できる。ユーザーは、次にＤＡＳを使用してファイルにアクセスする必要がある。ファイルに要求された保持時間は、ＦＳＷによって中継できる。ユーザーは、システムの再設定を要求せずに制御や変更を実行できる。これに代わるシステムでは、ＦＳＷは保持時間に関する情報をデータアーカイブシステムに転送することによって、システムは転送されたデータに基づいて集中的な意思決定を実現できる。保持時間は、特定のディレクトリについて設定された暗黙的な規則によって決定してもよい。「最終更新日（ｌａｓｔ ｍｏｄｉｆｉｅｄ ｄａｔｅ）」によって指定してもよい。さらに、顧客プロファイルに関連してもよい。「最終更新日」を使用するのは、アプリケーションソフトウェアで動作中に保持期限を設定するには便利な方法である。顧客プロファイルに基づく保持期間の場合は、ファイル名の先頭にアプリケーションで定義された「レコードロケータ（ｒｅｃｏｒｄ ｌｏｃａｔｏｒ）」（たとえば顧客番号）を付加してもよい。ファイルの削除は、顧客から廃棄マネージャに送信されたリスト内に所定のレコード番号が指定された後に、プログラム可能な年数が経過してから実行できる。このモードは、顧客アカウントが閉じてから特定の年数だけレコードを保存する必要があるという規制に準拠するために有効である。このようにして、ＦＳＷはデータアーカイブシステムに保持情報（たとえばＸＭＬフラグメント）を提供できる。

ここで、ＷｅｂサービスはＦＳＷから情報を受信する（多くの場合にｕＦＩＤを含む）。こうした情報はＣＩＳに送信され、次にＣＩＳはファイルにシリアル番号を割り当てる。ｕＦＩＤを識別子として使用してファイルを保存することにより、コンテンツアドレッサブルストレージが実現されるが、シリアル番号に基づく検索も可能になるので、複数のユーザーが同じファイルを保存する場合にファイルの複数のインスタンスを認識する必要はない。ＣＩＳは、ファイルを保存する前に暗号化又は圧縮する必要があるかどうかを指定する保持ポリシーを確認できる。ＣＩＳは、ここでファイルと関連の情報を送信し、タイムスタンプが記録される。タイムスタンプサービスは、ＸＭＬフラグメントに署名し、それを適切なＸＭＬドキュメントに変換することができる。ここで、このドキュメントはストレージマネージャに提供される。ストレージマネージャは、次に使用可能な未使用の暗号化キーを必要に応じてキーマネージャから取得し、このキー使用してこのファイルを暗号化及び圧縮する。ファイルを暗号化するときに、ストレージマネージャは使用する暗号化キーのシリアル番号とファイルのｕＦＩＤで構成されるレコードをキーマネージャに送信し、次にキーマネージャは顧客情報サービスに通知してレコードを保存できる。この情報は、少なくとも２つのデータベースに保存されるのが好ましい。冗長なコピーがリモートキーサーバーに送信され、キーサーバーはキーを使用済みとしてマークすることができる。したがって、キーサーバーは指定されたｕＦＩＤに関連付けられた暗号化キーのレコードを保持することもできる。

レコードは、暗号化されたファイル、そのｕＦＩＤ、そのシリアル番号、作成の時刻と日付、要求された保持ポリシー、及び顧客が指定する設定可能なメタデータを含めて構成される。これで、レコードは「資産」となる。ファイルは暗号化されたファイルシステムに移行されたときに資産になることを当業者は理解するであろう。出願者は、本明細書の全体を通じてファイルと資産とを適切に区別しようとしている。

ストレージマネージャは、コードページの独自のキャッシュを保持できる。ストレージマネージャは、より多くの暗号化キーを必要とする場合に、キーマネージャからコードページを要求する。次に使用可能なキーとそのシリアル番号がコードページのキャッシュから取得され、これを使用してファイルが暗号化されると、この時点でファイルは保存の対象となる資産に変わる。これで、こうした資産を保存できる。冗長なシステムでは、資産を少なくとも２つのバックエンドデバイス（通常は外部ＲＡＩＤアレイ又は光学的ジュークボックス（ｏｐｔｉｃａｌ ｊｕｋｅｂｏｘｅｓ））に保存できる。ｕＦＩＤ、タイムスタンプ、シリアル番号、メタデータ、その暗号化に使用されたキーのシリアル番号、及びその他のハウスキーピング情報を含む資産のマニフェストエントリが作成される。このマニフェストエントリはマニフェストサーバーによってマニフェスト内に保存され、マニフェストは資産として構築されて本発明のストレージソリューションに送信される。固定の間隔で（たとえば５分ごとに）、この期間に生成されたマニフェストエントリを保持するマニフェストがキーマネージャに送信され、ここでキーマネージャはこのマニフェストをリモートサイトに配置されたキーサーバーに「登録（ｒｅｇｉｓｔｅｒｓ）」する。さらに、このマニフェストはストレージマネージャに提供され、資産として保存されることにより、次のマニフェストの最初のエントリになる。

１つの実施形態では、マニフェストは直前の５分間にファイルストレージシステムで受信された各ファイル、又は１つのマニフェストファイルでリストアップできる最大のファイル数が受信された場合はその各ファイルに関する前述のメタデータ項目をリストアップするＸＭＬファイルである。１つのマニフェストが終了すると、別の新しいマニフェストが開始される。マニフェストが閉じると、マニフェストはその他のユーザーファイルと全く同様にしてデバイスに保存され（前述のセキュリティ／整合性の機能を提供する）、さらにリモートデバイスであるキーサーバーに送信される。

各ファイルは保存の対象となる資産に変換されるときに、そのファイルに固有のキーを使用して暗号化され、ファイルごとに暗号化キースクラブ暗号化キースクラブ（暗号ベースのファイルの削除）を実行できるようにするのが好ましい。ファイルが暗号化され、対応する資産がシステムに追加されると、マニフェストに資産のｕＦＩＤが追加され、暗号化キー、暗号化キーの保管場所、暗号化キーに関連付けられたシリアル番号を追跡する。１つの実施形態では、マニフェストは固定の間隔で、又は事前に指定された数の資産が追加された後に、或いはその両方の組合せに基づいて作成される。ファイルマニフェストは、消費されたキーコンテナのリスト、最新のマニフェストより後に追加されたファイルのシリアル番号とｕＦＩＤ（及びファイルがストレージシステムに送信された時刻など、その他のメタデータ）を割り当てられたファイル名、及びその他のハウスキーピング情報を含むデータ構造である。マニフェストは、最終的には別のファイルとしてファイルシステムに保存される。すべてのファイルに対して唯一のキー又は少ない数のキーを使用する先行技術とは異なり、ファイルごとに固有のキーを提供することによって、他の資産に影響を及ぼさずに個々の資産をシステムから効果的に削除できる。

マニフェストが閉じると、マニフェストはリモートキーサーバーに送信され、ここでリモートサーバーはマニフェストにデジタル署名をして中央リポジトリに保存することができる。リモートキーサーバーはＴＴＰによってホストされ、ＴＴＰはさまざまな顧客に同様のサービスを提供できるので、リモートキーサーバーは本データアーカイブシステムと同様のストレージシステムを利用してデータのセキュリティ及び整合性を提供するのが好ましいと言えよう。さらに、キーサーバーは署名されたマニフェストを保存対象の資産としてファイルストレージシステムに送り返すことができる。マニフェストを本データアーカイブシステムのファイルシステムに保存することによって、署名されたマニフェストが次のファイルマニフェストの要素になることが保証される。マニフェストのコピーは、資格のある弁護士又は日付と時刻の属性を提供する別の非デジタルの場所（ｎｏｎ−ｄｉｇｉｔａｌ ｖｅｎｕｅ）に預けることができる。マニフェストは、暗号化キーコンテナの消費に言及する。この情報はリモートキーサーバーによって記録できるので、特定のキーコンテナをだれが使用し、キーコンテナをいつ削除できるか又はいつ削除する必要があるかに関するレコードは、リモートキーサーバーによって保持できる。

マニフェストを非デジタルの場所に預けることについて言及する。ＴＴＰがマニフェストに署名した時刻を提供する以外に、マニフェスト自体を非デジタルエンティティに提供できる。マニフェストの入れ子的な性質（ｎｅｓｔｅｄ ｎａｔｕｒｅ）（ｕＦＩＤとメタデータを伴う各マニフェストが後続のマニフェストに保存される）により、一連の非隣接マニフェストを資格のある弁護士に提供でき、弁護士はマニフェストの受信日に認証を提供できる。資格のある弁護士が２つのマニフェストを受信し、要求されたファイルのメタデータを含むマニフェストが中間（ｉｎｔｅｒｉｍ）のマニフェストに保存されている場合に、中間のマニフェストが２つの認証された日付の間に開いて閉じたことを容易に立証できる。このことを証明するために、２つの日付の間にあるすべてのマニフェストを調べてマニフェスト間のリンクを示すことができる。マニフェストは次のマニフェストに資産として挿入されるため、次のマニフェストの暗号学的ハッシュに直接的な影響がある。これで、前述の「フィードフォワード（ｆｅｅｄ ｆｏｒｗａｒｄ）」特性が作成される（「ロシアンドール（Ｒｕｓｓｉａｎ−ｄｏｌｌ）」ストレージとも考えられる）。こうした属性により、各マニフェストを開いて前のマニフェスト信頼性（ａｕｔｈｅｎｔｉｃｉｔｙ）を確認できる。

以上に開示されたファイルマニフェストの操作方法にはさまざまな利点がある。マニフェストをＴＴＰに提供することにより、ファイル作成の時刻と日付を証明できる。マニフェストを非デジタルオーソリティに提供すると、マニフェストの入れ子的な性質との組合せにより、この非デジタルオーソリティはファイルがストレージシステムに提供された期間を２つの日付に挟まれた形で提供できる。サードパーティーは、シリアル番号と入れ子式のマニフェストの使用に基づいてレコードの完全性を証明することもできる。レコードの完全性を証明するプロセスでは、マニフェストが設計され、保存される方法は証拠となる十分な情報を提供するため、機密情報をサードパーティーに送信する必要はない。サードパーティーのタイムスタンプによる時刻／日付を顧客の時刻／日付と比較することにより、ストレージシステムがその内部クロックを変更して手順を免れようとしていないことを示すことができる。マニフェストは、後続のマニフェストを無効にすることなく変更を検出されずに実行することはできない。後続のマニフェストを「訂正」するには、顧客サイトでは入手できない情報が必要であり、いかなる場合にもキーサーバーに保存されたコピーとは一致しないためである。最新のマニフェストを調べるだけで、マニフェストチェインが改ざんされていないことを確認できる。キーサーバーは資産とその暗号化に使用するキーコンテナとを相互に関連付けるので、緊急の状況でキーサーバーに保存されるキーデータベースを使用して、指定された任意の資産を復号化できる。

マニフェストサーバーがマニフェストコンテナをユーザーのデータ資産と同様にクラスタに保存すると、マニフェストはデジタル署名付きのタイムスタンプ、ｕＦＩＤ、シリアル番号、暗号化キーが割り当てられ、さらにバックエンドストレージに保存される。これは、各マニフェストの１つの要素はそれまでの最新のマニフェストのメタデータであることを意味する。前のマニフェストは、通常、後続のマニフェストに含まれる最初のエントリである。前のマニフェストには、さらにその前のマニフェストのメタデータが含まれる（以下同様）。

ドキュメントは、その保持期間が経過すると、廃棄マネージャによって処理される。廃棄マネージャは、スケジュールされたプロセス（たとえば夜間に実行されるプロセス）として実行でき、キーサーバーを使用してマニフェストの内容を確認し、内部的な一貫性を検査することによって、マニフェストの整合性を検査する。ここで、廃棄マネージャは、削除する必要のあるキーのリストをキーサーバーに報告することによって、ドキュメントを期限切れにできる。続いて、キーマネージャがそのキーページを更新するときに、キーサーバーは受信した期限切れのドキュメントに関連付けられたキーを新しいコードページに提供する。このようにして、キーマネージャは期限切れの資産を復号化する機能を失う。

キーマネージャ上に配置されたコードページのローカルキャッシュは、マスターキーによって超暗号化される（ｓｕｐｅｒ ｅｎｃｉｐｈｅｒｅｄ）のが好ましいので、管理者は手頃なバックアップソフトウェアパッケージを使用してローカルドライブに保存されたコードページを含めてキーマネージャサーバーをバックアップすることもできる。マスターキーは（通常はＣＤ−ＲＯＭで配布される）、毎月変更され、古いコードは廃棄される。管理者がマスターキーを廃棄又は処分しないと、古いコードページがバックアップからリストアできるので、マスターキー（又はマスターキーが保存されたメディア）が廃棄されるまでは、暗号化キースクラブが有効であると見なすことはできない。これで安全対策を提供でき、サイトはマスターキーが削除期間を安全に経過したと考えられる場合にこれを廃棄できるというセーフティネット（ｓａｆｅｔｙ ｎｅｔ）を実現することができる。キーを廃棄するため、ファイルはシステムに残されていても実質的にはアクセス不能である。２５６ビットＡｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ（ＡＥＳ−２５６）のような十分に綿密な暗号化ルーチンを選択することにより、キーが廃棄された場合はデータが回復不能と見なすことができる。

ここで、ＦＳＷの設定、資産の作成、資産のリードバック（ｒｅａｄｉｎｇ ｉｔ ｂａｃｋ）、及び資産の削除の例について説明する。次の例は、本発明の１つの実施形態について詳細に説明するために提供されており、本発明の範囲を限定するものと見なしてはならないことに留意されたい。こうした例は、唯一の実施形態と見なしてはならない。又、本発明の範囲に対する限定と理解してもならない。この例では、キーマネージャがキャッシュ内に十分なコードページを保持することが想定されている。この例は、図１に関連して提供されており、以下にそのステップの概要を示している。

管理者は、Ｗｅｂブラウザを使用してＳｙｓＡｄｍｉｎ設定コンソールにアクセスし、「ＦＳＷ設定（ＦＳＷ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）」のリンクを選択する。コンソールには、ネットワーク内にあるＦＳＷのすべてのインスタンスがリストアップされる。管理者は、このリストから「ＨｕｍａｎＲｅｓｏｕｒｃｅｓＳｅｒｖｅｒ」を選択し、「ＰｅｒｓｏｎｎｅｌＦｉｌｅｓ」というディレクトリを監視し、５年間の保持規則セットを使用し、暗号化をオンにし、ファイルをショートカットで置き換えるように設定する。

ＨｕｍａｎＲｅｓｏｕｒｃｅｓＳｅｒｖｅｒ上のＦＳＷのインスタンスは、定期的にＳｙｓＡｄｍｉｎサービスに問い合わせ、その設定が変更されたかどうかを確認する。ＦＳＷは、更新された設定ファイルを確認し、これをロードする。ＦＳＷは、ＰｅｒｓｏｎｎｅｌＦｉｌｅｓディレクトリが変更されたかどうかの監視を開始する。ＨｕｍａｎＲｅｓｏｕｒｃｅｓＳｅｒｖｅｒのユーザーは、ＨｏｍｅＡｄｄｒｅｓｓｅｓ．ｄｏｃというドキュメントをＰｅｒｓｏｎｎｅｌＦｉｌｅｓディレクトリに保存する。

ＦＳＷは、ディレクトリの内容が変更されたことをオペレーティングシステムから通知される。ＦＳＷは、日付、時刻、及びファイルのサイズを問い合わせる。ＦＳＷは、処理するファイルのキューにファイル情報を配置する。キューがネットワーク通信に効率的なサイズに到達した場合、又はキューの最初のエントリが保存されてから一定の時間が経過した場合に、キューの内容はフロントエンドノードのＦＳＷ設定テーブルに送信される。何らかの理由によって送信が失敗した場合は、キューに配置されたファイルの次のフロントエンドノードへの送信を試みる（以下同様）。フロントエンドノードが使用できない場合は、ＦＳＷは必要に応じて引き続きファイルをキューに配置する。フロントエンドノードが使用可能になると、ファイルが送信される。ＦＳＷは、このようにして信頼性の低い断続的なネットワーク接続を行うモバイルコンピューティングプラットフォームやリモートオフィスをサポートする。しかし、この例ではＨｏｍｅＡｄｄｒｅｓｓｅｓ．ｄｏｃは高速のフロントエンドモジュールと正常に通信するキュー内の唯一のエントリであることを想定する。この結果、ステップ１００でファイルがデータアーカイブシステムに転送される。

フロントエンドノードでファイルが受信されると、タイムスタンプサービスへの要求が発行され、資産にタイムスタンプが関連付けられる。受信したタイムスタンプの時刻は、ＦＳＷによって報告されたタイムスタンプとは異なる場合があることに留意されたい。リモートサーバー及びワークステーションで設定された日付と時刻は特に信頼性が高いとは考えられないので、タイムスタンプサービスによって割り当てられた日付と時刻が廃棄の計算に使用される。後で、リモートキーサーバー上の日付と時刻を使用してこのタイムスタンプを証明するステップについて説明する。

ファイル名、請求された日付と時刻（ユーザーが提供する）、実際の日付と時刻（タイムスタンプサービスが提供したもの）、ファイルサイズ、保持期間に関する規則、顧客が提供するメタデータ（ある場合）からなる資産のレコードが作成される。このレコードは、設定リスト内の最初のストレージマネージャに送信される（すべてのサービスは他の使用可能なサービスのすべてインスタンスのリストを保持しているので、サービスが応答しない場合は、操作を他のいずれかのインスタンスで再試行できる）。このレコードには、このファイルの保持ポリシーに関する情報を含めることもできる。

ＨｏｍｅＡｄｄｒｅｓｓｅｓ．ｄｏｃのＭＤ５ハッシュ及び同じファイルのＳＨＡ−１ハッシュが計算される。ＳＨＡ−１ハッシュの代わりに、ＳＨＡファミリの他のハッシュ、たとえばＳＨＡ−２ハッシュ（ＳＨＡ−２２４、ＳＨＡ−２５６、ＳＨＡ−３８４、ＳＨＡ−５１２など）を使用してもよい。本発明の範囲を逸脱することなく、その他の暗号学的ハッシュアルゴリズムを使用することもできる。こうした２種類のハッシュはファイルのサイズとともに連結され、ファイルのｕＦＩＤが作成される。統計学的な意味で、同じサイズの２つのファイルに同じｕＦＩＤが提供される確率はきわめて低いので、ハッシュを連結したものはサイズの同じすべてのファイルを通じて一意であると考えられる。ＭＤ−５ハッシュアルゴリズムとＳＨＡファミリ又はアルゴリズムは全く異なるので、ＭＤ−５の衝突が発生した場合に、同じ２つのファイルでＳＨＡの衝突も同時に発生する可能性は低い。同様に、たとえば、ＭＤ−５ハッシュを変更せずにファイルを改ざんする方法を検出した場合に、ファイルサイズとＳＨＡ−１ハッシュが両方とも変更されない可能性はきわめて低い。しかし、２人のユーザーが所有する２つのファイルのコンテンツが同じ場合は、ファイル名と作成日が異なっていても、両方のファイルのｕＦＩＤは同じになる。ｕＦＩＤは、一般に問題のファイルの作成者、作成日、及びファイル名には関連しないためである。ｕＦＩＤが同じなので、ストレージシステムには唯一のコピーが保存され、コンテンツアドレッサブルストレージが提供される。

シリアル番号は保存要求にも割り当てられる。ｕＦＩＤとは対照的に、２つの同等のファイルがＦＳＷから送信される場合は、ファイル名と作成日が同じでも、新しいシリアル番号が発行される。この番号は、個々の保存要求の追跡に使用される。ｕＦＩＤは、顧客情報サービスなどの外部システムによって提供することもできる。このようにして、ステップ１０２でタイムスタンプが取得され、ｕＦＩＤが作成され、さらにシリアル番号が割り当てられる。

ステップ１０４で、ファイルの名前とコンテンツは、次に使用可能な暗号化キーを使用して暗号化される。ステップ１０８で、使用するキーのシリアル番号とファイルのｕＦＩＤは、キーマネージャに転送される。キーマネージャはこの情報を顧客情報サービスに送信し、顧客情報サービスは異なるノード上にある冗長なＳＱＬデータベースのペアにこの情報を保存する。顧客情報サービスは、この情報をさらにリモートキーサーバーに送信する。リモートキーサーバーはこのキーを使用済みとしてマーク付けし、この情報はキーサーバーのローカルＳＱＬデータベースに保存される。データを暗号化するステップはデータのセキュリティを提供し、最終的には個々のファイルごとの暗号化キースクラブを実現するが、暗号化システムを使用しない監査によってファイルストレージシステムの整合性を確認できることを当業者は理解するであろう。本システムのいくつかの実施形態では、ＣＩＳがシリアル番号を割り当てるときに、ファイルをメタデータとして暗号化するかどうかをＣＩＳが指示することもできる。この指示には、使用する暗号化キーを含めることもできる。

次にステップ１０６で、ストレージマネージャは暗号化されたＨｏｍｅＡｄｄｒｅｓｓｅｓ．ｄｏｃファイルのコピーを関連のメタデータとともに少なくとも２つの異なる外部ＲＡＩＤストレージデバイスに資産として保存する。ｕＦＩＤは資産の識別子として使用されるので、これは指定されたファイルコンテンツセットの唯一のインスタンスがＲＡＩＤデバイスに保存されることを意味する。このようにすれば、同じファイルの複数のコピーによって領域が消費されない（たとえば、１つのドキュメントに対して何百個もの同等のコピーが組織内に配布される場合）。こうしたストレージ機能は、一般に「コンテンツアドレッサブルストレージ（ＣＡＳ）」と呼ばれる。資産が安全に保存されると、ＦＳＷに完了メッセージが送信される。一部のステップ（たとえばステップ１０６や１０８）は、図示された順序又は説明された順序で実行する必要はないことを当業者は理解するであろう。この操作の間に、「トランザクションリカバリファイル（ｔｒａｎｓａｃｔｉｏｎ ｒｅｃｏｖｅｒｙ ｆｉｌｅ）」をさまざまなステップで作成でき、更新できる。このリカバリファイルは、保存のプロセスが失敗し、再試行が必要な場合に支援を提供できる。

ステップ１１０で、シリアル番号、期限、ｕＦＩＤ、キーコンテナ番号、日付と時刻、及びファイルサイズがレコードに挿入され、現在開いているマニフェストに追加される。５分ごとにマニフェストが閉じて処理され、新しいマニフェストが開く。

ステップ１１２で、ＦＳＷはＨｕｍａｎＲｅｓｏｕｒｃｅｓＳｅｒｖｅｒからファイルを削除し、Ｗｅｂサービスをポイントするシンボリックリンクでこれを置き換える。シンボリックリンクには、資産のシリアル番号も含まれる。ＦＳＷは、データアーカイブシステムがファイルを受信し、プロセス又はハードウェアに問題が発生した場合に続行するための十分な情報を保持する限り、ファイルが資産として保存される前に、ファイルの資産としての保存が完了したという通知を提供されることがある。このような例では、ＦＳＷが正常な保存の通知を受け取り、保存のプロセスでエラーが発生した場合に、トランザクションリカバリファイルを使用することができる。

フロントエンドノードでファイルが受信されると、トランザクションを追跡して対応する資産が正常に保存されたことを確認できる。ストレージマネージャにファイルと対応するメタデータ（ファイルを圧縮又は暗号化する必要があるかどうかの指示を含む）を提供すると、フロントエンドノードは保存プロセスの部分を完了する。しかし、資産が正常に保存されたという通知をストレージマネージャが提供するまで、フロントエンドノードはトランザクションレコードを未完（ｉｎｃｏｍｐｌｅｔｅ）とマーク付けしたままである。このことにより、フロントエンドノードは各トランザクションの進捗を監視し、必要に応じて保存要求を再発行することができる。

ファイルをリードバックするために、ユーザーはローカルファイル名と同様にしてシンボリックリンクを開くことができる。Ｗｅｂサービスは資産のシリアル番号を顧客情報サービスに送信し、さらに顧客情報サービスはこのシリアル番号を参照することによって、ストレージマネージャに送信するファイルのｕＦＩＤを確認する。ストレージマネージャはファイルを取得してこれをＷｅｂサービスに返し、さらにＷｅｂサービスはそれをＨｕｍａｎＲｅｓｏｕｒｃｅｓＳｅｒｖｅｒに返す。

顧客が要求に応じて資産を削除するメカニズムは提供されない。シンボリックリンクを削除することによって資産は廃棄されず、ユーザーはＲＡＩＤストレージに直接アクセスすることはできない。

しかし本システムは、図２に示すように、保持期間を過ぎた場合にファイルを削除できるように設計されている。ステップ１１４で、廃棄サービスは管理の対象となるすべての資産を毎日スキャンする。ステップ１１６で、ＨｏｍｅＡｄｄｒｅｓｓｅｓ．ｄｏｃが作成されてから５年以上経過している場合は、このファイルが廃棄候補のリストに追加される。管理者は、定期的にこのリストを確認し、資産の廃棄を承認するものとする。廃棄の前のいかなる時点においても、管理者は１つ又は複数の資産を「保留（ｈｏｌｄ）」にし、廃棄を無期限に阻止することができる。保留は、一般に引き続きビジネス価値があるもの、又は裁判所又は規制機関から保持するように命令されているものに設定される。

保留が設定されず、管理者がファイルの廃棄を承認した場合に、ストレージマネージャはファイルが保存されているＲＡＩＤシステム上のすべてのファイルをスクラブする。この操作は、７個の異なるビットパターンでファイルを上書きすることよるものを含めて、任意の数の既知の技術を使用して実行できる。ステップ１１８で、資産の削除はＷＯＲＭの実装では不可能な場合があるのでオプションと考えられる。又、資産に対して暗号化キースクラブが実行されるので、資産の削除は技術的に不要になる。ステップ１２０で、ファイルが一括（ｂａｔｃｈ）で廃棄されると、廃棄マニフェストがリモートキーサーバーに送信され、削除する資産に関連付けられたキーを削除するようにリモートキーサーバーに指示する。リモートキーサーバーは、ファイルの暗号化キーのローカルコピーをすべてスクラブする。ステップ１２２で、ローカルキーマネージャは更新されたコードページをリモートキーサーバーから一定の間隔で要求する。更新されたコードページには、削除されたキーは含まれていないので、実質的に暗号化キースクラブのプロセスは完了する。暗号化キーのすべてのコピーが廃棄されると、ＲＡＩＤストレージ上の暗号化されたリポジトリから作成されたＨｏｍｅＡｄｄｒｅｓｓｅｓ．ｄｏｃのすべてのバックアップコピーは読み出し不可能になる。このようにして、ドキュメントは暗号化されたリポジトリから作成された任意のバックアップから暗号化キースクラブが実行される。

以上に開示したように、本発明のさまざまな実装によって多くの利点が得られる。前述のアーキテクチャは、ＳＥＣ １７ａ、ＨＩＰＡＡ、ＣＦＲ ２１ ｐａｒｔ １１（ＦＤＡ）、Ｓａｒｂａｎｅｓ Ｏｘｌｅｙ、ＰＩＰＥＤＡ ｏｆ Ｃａｎａｄａ、ＵＫ Ｄａｔａ Ｐｒｏｔｅｃｔｉｏｎ Ａｃｔ、及びその他の規制の該当するすべての要件に準拠すると考えられる。資産は、複数のストレージデバイスに保存でき、各デバイスはＲＡＩＤ技術などの冗長性を利用して信頼性を向上することができる。保存されたデータは暗号化されているので、不注意によってデータが公開される危険性は低くなる。これに応じて、バックアップメディア上のデータも暗号化されている。バックアップメディア上にある期限切れの資産は、実質的に回復不可能である。暗号化キーの管理は、完全に自動化できる。暗号化キーは、地理的に離れた複数の冗長な場所に保存できる。資産は、許可なくアクセスできない。又、検出されずに変更、削除、アーカイブシステムへの挿入を行うこともできない。ファイルを作成した日付と時刻の値は、外部的に確認できる。中立的なサードパーティーは、資産の実際の内容について知らなくても、資産の完全性と信頼性を証明できる。ネットワークを経由したすべてのトランザクションを監視でき、必要に応じて成功するまで再試行できる。必要なデータストレージ容量は、ＣＡＳ技術によって削減できる。リモートで接続するシステムや断続的に接続するシステムをサポートできる。

その他の実施形態では、本発明の範囲を逸脱することなく、さまざまな変更を実行できる。以下のリストは、本発明の範囲を逸脱しないと見なす必要のある多くの変更を示している。以下のリストに示す変更は限定と理解してはならない。又、リストに含まれないその他の変更も本発明の範囲を逸脱しないことに留意されたい。

・ その他の相互接続技術を使用できる。たとえば、ノード間及び／又はストレージ間の相互接続にインフィニバンド（Ｉｎｆｉｎｉｂａｎｄ））を使用してもよい。ＲＡＩＤストレージとの通信にファイバチャネルの代わりにｉＳＣＳＩを使用してもよい。

・ その他のパッケージング技術を使用できる。たとえば、多くのディスクドライブベイを備えるサーバーケースを使用して、データストレージをさらにサービスノードに統合してもよい。

・ 本システムは、任意の数のオペレーティングシステム上に実装できる。

・ ＦＳＷは、ユーザーのコンピュータをスキャンし、そのコンピュータ上で各ファイルのｕＦＩＤを作成することもできる。このリストは、管理の対象となる資産のリスト又は保持期間が終了した後に削除されることが想定される資産のリストと比較することによって、「ストレイ（ｓｔｒａｙ）」すなわちドキュメントの無制御状態の（ｕｎｃｏｎｔｒｏｌｌｅｄ）コピーが存在することをユーザー又は管理者に通知する。

・ ＲＡＩＤに加えてＷＯＲＭテープ又はオプティカルを使用するのは別の可能性であり、こうしたテープ又はオプティカルは比較的アクセス頻度の低いデータ階層ストレージ管理（ＨＳＭ：Ｈｉｅｒａｒｃｈｉｃａｌ Ｓｔｏｒａｇｅ Ｍａｎａｇｅｍｅｎｔ）パラダイムで使用されるか、及び／又は新しい資産が受信されたときにそのそれぞれのコピーを保存するジャーナル（ｊｏｕｒｎａｌ）として使用される。

・ 暗号化は、ディレクトリごとにオフにできるので、多くの事例で暗号化を行わずにこの技術を利用できる。

・ ストレージマネージャノードは、その全体を従来のＲＡＩＤコントローラ、たとえばネットワークアドレッサブルストレージ（ＮＡＳ：ｎｅｔｗｏｒｋ ａｄｄｒｅｓｓａｂｌｅ ｓｔｏｒａｇｅ）のフロントエンドに含めることができる。

・ ＦＳＷ技術は、データをキャプチャする多くのデバイスのいずれにも埋め込まれるようにライセンスできる。たとえば、警察や保険のカメラマンは証拠品の写真を撮影し、ＦＳＷクライアントはこの品目のデジタル署名とタイムスタンプを作成する。次回にカメラをそのクレードルにドッキングすると、ＦＳＷはこの資産をクラスタ内の管理対象とする。このように、写真の信頼性と写真レコード全体の完全性を証明する一連の証拠が存在する。こうした技術を使用できるいくつかのデバイスには、以下のものが含まれる。
・ デジタルカメラ
・ ＰＤＡ（特にカメラを内蔵するもの）
・ ビデオカムコーダ（Ｖｉｄｅｏ Ｃａｍｃｏｒｄｅｒ）
・ ＤＶＤレコーダ
・ オーディオレコーダ（たとえば取り調べ用）
・ 交通取り締まり用カメラ（Ｔｒａｆｆｉｃ ｅｎｆｏｒｃｅｍｅｎｔ ｃａｍｅｒａｓ）
・ ＣＴスキャン（ＣＡＴｓｃａｎ）、Ｘ線などの医療用イメージングカメラ（Ｉｍａｇｉｎｇ ｃａｍｅｒａｓ）
・ コンピュータ化されたラボの設備（たとえば、メディカルラボの機器（ｍｅｄｉｃａｌ ｌａｂ ｇｅａｒ）、飲酒検知（ｂｒｅａｔｈａｌｙｚｅｒｓ）、クロマトグラフィー（ｃｈｒｏｍａｔｏｇｒａｐｈｓ））
・ ビデオ監視レコーダ（Ｖｉｄｅｏ Ｓｕｒｖｅｉｌｌａｎｃｅ ｒｅｃｏｒｄｅｒｓ）
・ 留守番電話（Ｔｅｌｅｐｈｏｎｅ ｒｅｃｏｒｄｉｎｇ ｄｅｖｉｃｅ）
・ 宅配業者（たとえば、Ｆｅｄ−Ｘ、ｍｉｌｉｔａｒｙ ｃｏｕｒｉｅｒｓ）が使用するハンドヘルドコンピュータ

図３は、本発明のシステムを示すブロック図である。システム内のエレメントは、相互に接続されているものとして説明されており、分散型データアーカイブシステムが実装された場合にエレメントを分散する方法は問わない。本発明の範囲を逸脱することなく、さまざまなプロセスの負荷をさまざまな方法で分散できる任意の数のさまざまな実装を提供できることを、当業者は理解するであろう。

クライアントノード１３０は、準拠ストレージのファイルを生成する。クライアントストレージ１３４上にあるこうしたファイルの作成と変更は、ＦＳＷ １３２によって監視される。準拠ストレージのファイルの作成を検出すると、ＦＳＷ １３２はこのファイルをデータアーカイブシステム１４０に送信する。このファイルは、タイムスタンプエンジン１４２に提供され、ここで前述のようにファイルにタイムスタンプが記録され、到着時刻の正確な追跡を保証できる。ここで、タイムスタンプを記録されたファイルはストレージマネージャ１４６に提供され、ストレージマネージャは、ファイルのｕＦＩＤを生成し、ファイルにシリアル番号を割り当て、さらにファイルに関連するその他のメタデータを準備する。次に、ストレージマネージャ１４６はキーマネージャ１５２からキーを要求し、キーマネージャはローカルにキャッシングされたコードページ１５４からキーを取得する。さらに、ファイルが保存用に暗号化されて提供され、資産のストレージ１４８ａ及び１４８ｂに保存される。保存された資産と関連のファイルに関する情報は、マニフェストエンジン１５０に提供され、マニフェストエンジンはマニフェストにレコードを追加し、ＤＡＳ １４０への送信を追跡する。ストレージマネージャ１４６は、ファイルに関する情報と使用するキーの識別情報をＣＩＳ １４４に提供する。ＣＩＳは、システム１４０の外部のエレメントでもよい。マニフェストがいっぱいになると、マニフェストエンジンはタイムスタンプエンジン１４２にマニフェストを提供し、新しいファイルとしてＤＡＳ １４０に保存する。キーマネージャ１５２は、コードページ１５４をキーサーバー１５６から取得し、コードページをローカルにキャッシングできる。

前述のように、廃棄エージェント１５４は資産ストレージ１４８ａ及び１４８ｂ内のファイルを監視し、廃棄する必要があるかどうかを判断する。廃棄エージェントがファイルを廃棄するように指示すると、資産ストレージから資産を削除でき、キーサーバー１５６は廃棄要求を通知される。キーサーバー１５６は、この資産に関連付けられたキーをコードページから削除できる。ここで、更新されたコードページがキーマネージャ１５２に提供され、キャッシングされたページ１５４を置き換える。これで、実質的に暗号化キースクラブは完了する。

ここで、図３に示すシステムの詳しい動作について説明する。

キーの保存は、キーのコピーを複数の場所に保存することによって実行される。地理的に離れた複数の場所に保存するのが好ましい。マスターキーサーバー１５６は、キーマネージャ１５２から離れていてもよく、暗号化キーの生成と長期保存の管理を担当する。マスターキーサーバー１５６は、一般に安全な施設内にあるシステムベンダーによってホストされるが、顧客が実装することもできる。キーマネージャ１５２は、１つのユニットのデータが１００％失われた場合に対応できるように設計され、暗号化された冗長なキーストレージを備えているのが好ましい。ＤＡＳ １４０は、キー値の発行とローリング（ｒｏｌｌｉｎｇ）を管理する１つ又は複数のキーマネージャを備えているのが好ましい。キーマネージャ１５２は、コードページ１５４にキーを保存する。

キーマネージャ１５２は、使用可能なキーの数が最低水準を下回ることを確認する。ここで、キーサーバー１５６から新しいコードページ１５４が要求される。各コードページ１５４には、それぞれ暗号化キーを保持するキーコンテナが含まれる。マスターキーサーバー１５６は、コードページを動的に生成する。各コードページは、３つ以上の冗長なストレージロケーションに保存されるのが好ましい。コードページは、３つのロケーションのすべてにおいて毎晩バックアップされるようにフラグを設定できる。バックアップは、ローリングベースで２週間保持されるのが好ましい。

キーマネージャ１５２は各コードページをダウンロードする。コードページは、キーサーバー１５６によって２５６ビットのキーを使用して暗号化されてから保存される。ここで、コードページキーはローカルＲＳＡキーを使用して暗号化され、ＣｏｄｅＰａｇｅＨｅａｄｅｒファイルに登録される。ＣｏｄｅＰａｇｅＨｅａｄｅｒファイルは、ルートキーファイル（Ｒｏｏｔ Ｋｅｙ ｆｉｌｅ）内で検出されたキーを使用して暗号化される。ルートファイルキーは、キーマネージャ１５２からアクセス可能な取り外し可能媒体又はハードウェアキートークン（ｈａｒｄｗａｒｅ ｋｅｙ ｔｏｋｅｎ）に保存されるのが好ましい。ルートファイルキーは、固定のスケジュールに従って廃棄される。

ここで、キーの消費についてさらに詳しく説明する。ファイルがシステム１４０に挿入されると、ストレージマネージャ１４６はこのファイルを暗号化するときに使用するキーを取得する。キーコンテナは、２つのコンポーネント、すなわちコードページのシリアル番号とコンテナのシリアル番号を使用してシリアル番号付けされる。キーコンテナは、ファイルの第１のインスタンスに関連付けられる。これはファイルのｕＦＩＤに付加される。各ｕＦＩＤは、コンテンツアドレッサブルストレージが実装された場合に、同じファイルのすべての保存要求に関連付けられる。各保存要求には、それ自体がシリアル番号であるｓｉｇｎａｔｕｒｅｌＤが付けられる。各ｓｉｇｎａｔｕｒｅｌＤには、期限を含むライフサイクルが指定される。このようなデータは顧客情報サービス１４４とストレージマネージャ１４６に保存されるので、廃棄エージェント１５４はファイルをいつ廃棄する必要があるのか、及びファイルの取得をいつ許可するのかを決定できる。

前述のように、マニフェストエンジン１５０は「ｎ」分ごとにマニフェストを作成する。一般に、ストレージマニフェストには、ＭａｎｉｆｅｓｔＩＤ、ｓｉｇｎａｔｕｒｅＩＤ（保存要求）、保存要求に関連付けられたファイルのｕＩＤ、ライフサイクルの期限、ストレージのタイムスタンプと暗号化コードページのシリアル番号、及びキーコンテナが含まれる。さらに、マニフェストはタイムスタンプが記録され、ストレージマネージャ１４６に提供されて資産として保存される。マニフェストが資産として保存されると、マニフェストのメタデータが次のマニフェストに追加される。マニフェストのコピーがマスターキーサーバー１５６に送信され、冗長なストレージが実現する。さらに、マニフェストに関する情報は初めに生成されたキーコンテナとコードページに関連付けられる。こうした情報には、キーコンテナの期限、ｕＦＩＤ、ｓｉｇｎａｔｕｒｅｌＤが含まれる。キーコンテナは、期限が切れるまでシステムから削除できないが、期限が切れたコンテナは厳密な意味で廃棄されるまでは引き続きアクティブである。

顧客には、日次ベース又は他の同様のスケジュールで廃棄選択マニフェストレポートが廃棄エージェント１５４から提供される。画面上のレポートを使用して、廃棄できる資産を表示することもできる。これで、顧客は廃棄する資産を承認できる。廃棄エージェント１５４は、事前に指定した時刻に承認済みの廃棄要求を確認するプロセスを実行する。このプロセスには、認証と整合性に関するレベル２のチェックが含まれるのが好ましい。廃棄マニフェストが確認されると、ストレージマネージャ１４６に削除要求を送信することにより、資産がシステムから削除される。最後に、廃棄マニフェストがマスターキーサーバー１５６に送信される。サーバーは、廃棄マニフェストを元のキーコンテナと照合する。これで、「ローリング」プロセス実行中にアクティブなシステムからキーコンテナを削除できる。

毎晩、廃棄マニフェストの「ｎ」分後に、キーマネージャ１５２はコードページを更新する。マスターキーサーバー１５６は、期限が切れて廃棄されたキーコンテナのないコードページを再生成する。世代番号（ｇｅｎｅｒａｔｉｏｎ ｎｕｍｂｅｒ）の異なる新しいコードページが生成される。ここで、新しい世代番号はキーマネージャ１５２にダウンロードされる。初めのコードページは、顧客が暗号化データベースを再生成するまで顧客のシステムで保持できる。これは、通常は月次ベースで実行される。

月に１度、コードページ１５４のセット全体をＤＡＳ １４０からロードし、ロードされた新しいマスターキーを使用して再暗号化することができる。前のマスターキーは廃棄又はロックされる。前のマスターキーが廃棄されると、暗号化キースクラブが完了する。キーマネージャ１５２は新しい世代のコードページをロードでき、システムは前と同様に動作を継続する。キーマネージャ１５２は、キーキャッシュの動作を維持しながらシステムを中断することなくコードページを再生成できる。

本発明の前述の実施形態は、例を示すことのみを目的としている。特定の実施形態に対するさまざまな改変（Ａｌｔｅｒａｔｉｏｎｓ）、変更、及び変形は、添付の請求項のみによって定義される本発明の範囲を逸脱することなく当業者によって実施できる。

資産を保存する方法を示す流れ図である。 資産の暗号化キースクラブ（ｅｎｃｒｙｐｔｉｏｎ ｋｅｙ ｓｃｒｕｂｂｉｎｇ）を行う方法を示す流れ図である。 本発明のデータアーカイブシステムを示すブロック図である。

Claims (53)

1. 受信したファイルを保存する方法であって、
   前記ファイルに関連付けられたメタデータのセットと固有のファイル識別子とをアセンブルするステップと、
   前記ファイルを資産として保存するステップと、
   前記ファイルに関連付けられた前記メタデータを前記保存された資産に関連付けるデータレコードを作成するステップと
   を備える方法。
2. 前記ファイルを資産として保存するステップは、前記ファイルを暗号化することによって資産を作成するステップと、前記資産を保存するステップとを含む請求項１に記載の方法。
3. 前記暗号化するステップの前に、前記ファイルにタイムスタンプを関連付けるステップをさらに含む請求項１に記載の方法。
4. 前記データレコードはさらに前記タイムスタンプを含む請求項３に記載の方法。
5. 前記固有のファイル識別子は前記ファイルの複数の暗号学的ハッシュの連結を含む請求項１に記載の方法。
6. 前記固有のファイル識別子はＭＤ−５暗号学的ハッシュとＳＨＡ−１暗号学的ハッシュとの連結を含む請求項５に記載の方法。
7. 前記複数の暗号学的ハッシュのそれぞれは、ＭＤ−５、ＳＨＡ−１、ＳＨＡ−２２４、ＳＨＡ−２５６、ＳＨＡ−３８４、及びＳＨＡ−５１２を含むリストから選択される請求項５に記載の方法。
8. 前記固有のファイル識別子はファイルサイズを含む請求項５に記載の方法。
9. 前記メタデータはシリアル番号を含む請求項１に記載の方法。
10. 前記暗号化するステップは、固有の暗号化キーを取得するステップと、前記キーを前記ファイルに関連付けるステップとを含む請求項２に記載の方法。
11. 前記暗号化キーは対称暗号化キーである請求項１０に記載の方法。
12. 前記データレコードを作成するステップは暗号化キーのシリアル番号を前記保存された資産に関連付けるステップを含む請求項１０に記載の方法。
13. 前記データレコードを作成するステップはストレージマニフェストにエントリを追加するステップを含む請求項１に記載の方法。
14. 前記ストレージマニフェストは指定された期間内に保存された資産のシリアル番号付きのリストを含む請求項１３に記載の方法。
15. 前記ストレージマニフェストを閉じるステップと、前記ストレージマニフェストを資産として保存するステップとをさらに含む請求項１３に記載の方法。
16. 前記ストレージマニフェストを保存するステップは、
    前記ストレージマニフェストに関連付けられたメタデータのセットをアセンブルするステップと、
    前記ストレージマニフェストを暗号化して資産を作成するステップと、
    前記資産を保存するステップと、
    前記マニフェストに関連付けられた前記メタデータを前記保存された資産に関連付ける新しいストレージマニフェストへのエントリを作成するステップとを含む請求項１５に記載の方法。
17. 監査可能なデータストレージシステムにデータを保存する方法であって、
    監査可能なデータストレージシステムに保存するために受信したファイルに関連付けられたデータをマニフェストに記録するステップと、
    前記マニフェストを閉じるステップと、
    前記マニフェストを前記監査可能なデータストレージシステムにファイルとして保存するステップと、
    前記監査可能なデータストレージシステムに保存するために受信したファイルに関連付けられた新しいマニフェストを作成するステップと
    を備えており、前記新しいマニフェストは前記前のマニフェストをエントリとして含む方法。
18. 前記記録するステップは固有のシリアル番号を前記保存するために受信したファイルのそれぞれに関連付けるステップを含む請求項１７に記載の方法。
19. 前記監査可能なストレージシステムの監査を実行するステップをさらに含む請求項１８に記載の方法。
20. 前記監査を実行するステップは、
    前記マニフェストを調べてシリアル番号の完全なセットが存在することを確認するステップと、
    前記マニフェストに保存されたデータに関連付けられた各ファイルが前記監査可能なストレージシステム内に存在することを確認するステップと
    を含む請求項１９に記載の方法。
21. 前記記録するステップは、前記保存するために受信したファイルのそれぞれに関連付けられた固有のファイル識別子、ファイルサイズ、及びシリアル番号を保存するステップを含む請求項１７に記載の方法。
22. 前記記録するステップは前記ファイルのそれぞれに関連付けられた保持情報を保存するステップをさらに含む請求項２１に記載の方法。
23. 前記固有のファイル識別子は前記関連付けられたファイルの少なくとも２つの暗号学的ハッシュに従って決定される請求項２１に記載の方法。
24. 前記固有のファイル識別子は前記関連付けられたファイルの少なくとも２つの暗号学的ハッシュの連結を含む請求項２３に記載の方法。
25. 前記監査可能なストレージシステムの監査を実行するステップをさらに含む請求項２３に記載の方法。
26. 前記監査を実行するステップは、
    前記マニフェストを調べてシリアル番号の完全なセットが存在することを確認するステップと、
    前記マニフェストに保存されたデータに関連付けられた各ファイルが前記監査可能なストレージシステム内に存在することを確認するステップと、
    前記固有のファイル識別子を再計算し、前記計算された固有のファイル識別子を前記マニフェストに保存された前記固有のファイル識別子と比較することによって、前記システム内に存在する前記マニフェストに保存されたデータに関連付けられた各ファイルが変更されていないことを確認するステップと
    を含む請求項２５に記載の方法。
27. 前記保存するために受信したファイルの少なくとも１つは暗号化され、前記データを記録するステップは、前記少なくとも１つのファイルの暗号化に使用された暗号化キーに関連付けられた暗号化キーコンテナのシリアル番号を記録するステップを含む請求項１７に記載の方法。
28. 前記マニフェストを閉じるステップは、前記マニフェストが作成されてから事前に指定された期間が経過した後に実行される請求項１７に記載の方法。
29. 前記新しいマニフェストを作成するステップは、前記前のマニフェストに関連付けられた固有のファイル識別子を最初のエントリとして前記新しいマニフェストに記録するステップを含み、前記固有のファイル識別子は前記閉じたマニフェストの暗号学的ハッシュの連結を含む請求項１７に記載の方法。
30. 前記マニフェストを閉じるステップは、前記保存されたマニフェストのコピーを外部のサイトに転送するステップを含む請求項１７に記載の方法。
31. 前記外部のサイトは信頼できるサードパーティーによって管理される請求項３０に記載の方法。
32. 監査可能なファイルシステムにファイルを保存するデータアーカイブシステムであって、
    資産を保存するストレージアレイと、
    前記データアーカイブシステムによって受信されたファイルを前記ストレージアレイに資産として保存するストレージマネージャと、
    前記ストレージマネージャによって資産として保存されたファイルに関連付けられたデータを受信し、前記受信したデータをマニフェストに保存することによって前記ストレージアレイに保存された資産の監査可能なログを作成するマニフェストエンジンと
    を含むデータアーカイブシステム。
33. 前記ストレージアレイは独立したドライブの冗長なアレイである請求項３２に記載のデータアーカイブシステム。
34. 前記ストレージマネージャは受信されたファイルの少なくとも１つを保存する前に暗号化する暗号化エンジンを含む請求項３２に記載のデータアーカイブシステム。
35. 前記受信されたデータは前記ストレージマネージャによって前記ファイルの暗号化に使用された前記暗号化キーの識別情報を含む請求項３４に記載のデータアーカイブシステム。
36. 前記暗号化エンジンは暗号化キーのキャッシュを保存するキーマネージャを含む請求項３４に記載のデータアーカイブシステム。
37. 前記キーマネージャは外部のキーサーバーからキャッシングする暗号化キーのセットを要求するキーサーバーインターフェースを含む請求項３６に記載のデータアーカイブシステム。
38. 前記マニフェストエンジンは、既存のマニフェストを前記マニフェストが作成されてからあらかじめ指定された時間が経過したときに閉じ、前記閉じたマニフェストを資産として保存するファイルとして前記ストレージマネージャに提供し、前記既存のマニフェストを閉じるときに新しいマニフェストを作成するマニフェスト管理ユニットを含む請求項３２に記載のデータアーカイブシステム。
39. 前記マニフェスト管理ユニットは閉じたマニフェストを資産として保存するときに前記閉じたマニフェストを外部のサイトに提供する手段を含む請求項３８に記載のデータアーカイブシステム。
40. 前記外部のサイトは前記信頼できるサードパーティーによって管理される請求項３９に記載のデータアーカイブシステム。
41. 前記ストレージマネージャによって保存されたファイルに関連付けられた前記受信データは、前記資産に関連付けられた固有のファイル識別子、ファイルサイズ、シリアル番号、保持ポリシー、及び暗号化キーの識別情報の少なくとも１つを含む請求項３２に記載のデータアーカイブシステム。
42. 前記ストレージアレイに保存され、削除するようにマーク付けされた資産をリストアップする廃棄マニフェストを作成し、前記廃棄マニフェスト内の少なくとも１つの資産をアクセス不能にする廃棄エージェントをさらに含む請求項３２に記載のデータアーカイブシステム。
43. 前記廃棄エージェントは、前記少なくとも１つの資産をアクセス不能にする前に、前記資産をアクセス不能にするための認可を受ける手段を含む請求項４２に記載のデータアーカイブシステム。
44. 前記廃棄エージェントは前記保存された資産のそれぞれに関連付けられた保持ポリシーに従って前記廃棄マニフェストを作成する保持ポリシーエージェントを含む請求項４２に記載のデータアーカイブシステム。
45. 前記廃棄エージェントは、前記資産をアクセス不能にする前記廃棄マニフェストにリストアップされた資産に関連付けられた暗号化キーを削除する暗号化キー削除手段を含む請求項４２に記載のデータアーカイブシステム。
46. 前記監査可能なファイルシステムに保存するファイルをクライアントコンピュータから取得し、前記取得された前記監査可能なファイルシステムに保存するファイルを前記ストレージマネージャに送信するファイルシステムウォッチャをさらに含む請求項３２に記載のデータアーカイブシステム。
47. 前記ファイルシステムウォッチャは、取得されたファイルに関連付けられた前記データを確認し、前記取得されたファイルに関連付けられた前記データを前記マニフェストエンジンに送信するファイル属性エンジン（ｆｉｌｅ ａｔｔｒｉｂｕｔｅ ｅｎｇｉｎｅ）を含む請求項４６に記載のデータアーカイブシステム。
48. 前記ファイル属性エンジンは、前記取得されたファイルの少なくとも２つの暗号学的ハッシュに従って、前記取得されたファイルのそれぞれに関連付けられた固有のファイル識別子を決定する手段を含む請求項４７に記載のデータアーカイブシステム。
49. 前記ストレージマネージャに送信された各ファイルが受信され、前記固有のファイル識別子に従って検証されたことの確認を前記ファイルシステムウォッチャに提供するトランザクション検証エンジンをさらに含む請求項４７に記載のデータアーカイブシステム。
50. 前記ファイル属性エンジンは、前記取得されたファイルの前記ロケーションに従って、前記取得されたファイルのそれぞれに関連付けられる保持ポリシーを決定する保持ポリシー決定手段を含む請求項４７に記載のデータアーカイブシステム。
51. 前記取得されたファイルの前記ロケーションは、前記取得されたファイルを保存する前記コンピュータが配置される部門、前記取得されたファイルが保存されるコンピュータ、前記取得されたファイルが保存されるコンピュータのディレクトリを含むリストから選択される請求項５０に記載のデータアーカイブシステム。
52. 前記取得されたファイルを前記ストレージマネージャに送信した後に、前記ファイルをシンボリックリンクとショートカットのいずれかで置き換えるリンクエンジン（ｌｉｎｋｉｎｇ ｅｎｇｉｎｅ）を含む請求項４６に記載のデータアーカイブシステム。
53. 前記シンボリックリンクは前記取得されたファイルに関連付けられたシリアル番号を含む請求項５２に記載のデータアーカイブシステム。

Images