JP4934860B2 - 情報システム構成要素解析から算出したトラストスコアに基づいて複数のネットワークエンドポイント間のアクセスを制御する方法 - Google Patents

Description

発明の分野

本発明はコンピュータモジュールの検証に関し、より詳しくは、コンピュータにネットワークリソースにアクセスする許可を与える前にそのコンピュータのインテグリティ(integrity)を判定することに関する。

発明の背景

かつてはコンピュータネットワークは珍しいものであったが、今ではコンピュータネットワークはありふれたものとなっている。大抵の会社では、互いにネットワーク接続されたコンピュータを用いている。大会社では、何百台の、場合によっては何千台の互いにネットワーク接続されているコンピュータを用いていることがある。また、コンピュータネットワークは、家庭にも浸透しつつある。家族全員が自分のコンピュータを持ちたがるので、リソース（例えば、インターネットへの接続）を共有するためにそれらのコンピュータをネットワーク接続することが必要となる。ルーターのようなコンピュータのネットワーク接続をサポートする機器を製造する会社は、簡単にインストールして使用することができる機器を作ることで、この流れに対処している。ユーザーは、しばしば、もう少し複雑な作業をしなければならないことがある。例えば、コンピュータをルーターに接続したり、ルーターの電源を入れたりする作業が必要となるが、コンピュータはユーザーがそれらの作業にとまどう必要がないくらい信頼性の高いものとなっている。

しかし、ネットワーク設定を同一の単純な手順にしたことで、コンピュータの脆弱性は増した。ウィルス、ワーム、トロイの木馬やロジックボムは、かつてないほどのペースで作成されている。そして、このようなネットワークがインターネットに接続されるのに合わせ、このような危機の拡散は、インターネットによって、より簡単に、頻繁に起こるようになっている。

ユーザーにとって、ウィルスやその類のものに感染することは、少なくとも悩ましいことである。ユーザーは、よくても、彼の個人的なネットワーク内のどのコンピュータがウィルスに感染しているか識別し、その感染しているコンピュータを検疫するのに必要な時間をかける必要がある。最悪の場合、ウィルスに感染すると、ハードディスクドライブを消去し、ソフトウェアを一から復元することが必要となるかもしれない。そのために、このユーザーは、その感染したコンピュータに保存していたデータをすべて失うことになるかもしれない。

個人ユーザーにとって、彼らのコンピュータに保存されているデータ（例えば、家族写真や個人的な文書）は、代わりがきかないものであり、かけがえのないものであるかもしれない。それでも生活は続けられるだろう。しかし、仕事においては、このようなデータの消失は致命的な影響を及ぼすであろう。適切なアーカイブポリシー（policy）を実行したとしても、コンピュータシステムとビジネスネットワークを修復するのに要する時間は、その間に得られなかった収入分とコンピュータとネットワークを実際に修復するのに掛かる費用両方を合わせて、1000ドル以上に相当するであろう。さらに、コンピュータとネットワークを修復していて業務ができなかった間に、信用を失ってしまう可能性もある。

従って、これらの問題に対処するため、潜在的に不適切な状態にあるコンピュータがネットワークリソースに対してアクセスする許可を与えられる前に、それらのコンピュータを識別する手段は依然として要望されている。

本発明は、有効なモジュールシグネチャのデータベースを構築し、モジュールを検証し（validate）、さらにコンピュータを検証する方法および装置を含んでいる。コンピュータを検証するために、装置は、このコンピュータ内の複数のモジュールに対して生成されたシグネチャを受け取る。これらのシグネチャは、インテグリティログへとまとめられる（assemble）。この装置は、これらのシグネチャをデータベース内のシグネチャと比較することで、各シグネチャが正しいことを確認しようと試みる。これらのシグネチャが有効または無効にされた後、この装置は、このコンピュータから受け取ったどのシグネチャが有効にされたかに基づいてトラストスコアを生成する。

本発明の前述した特徴、目的、利点およびそれら以外の特徴、目的、利点は、添付図面と関連して記載された以下の詳細な説明から明らかとなるであろう。

好ましい実施例の詳細な説明

図１は、コンピュータの検証を実行するためのインテグリティバリデータ（integrity validator）を有するシステムを示している。図１では、コンピュータシステム105は外部ネットワーク110に接続されている。コンピュータシステム105は、コンピュータ115と、モニター120と、キーボード125と、マウス130と、を含むものとして示されている。しかし、当業者ならば、コンピュータシステム105にその他の構成要素（例えば、プリンタのようなその他の入力装置や出力装置）を持たせてもよいとわかるであろう。また、図１には、コンピュータシステム105の従来の内部構成要素の一部（例えば、中央処理ユニットや、メモリなど）が示されていない。さらに、コンピュータシステム105は、ノートパソコンや、専用端末装置（dedicated terminal）や、携帯情報端末（PDA）などのその他のマシンで代用することができる。

外部ネットワーク110は、その名前が示すように、その機構（組織）の外部のネットワークである。それに対し、内部ネットワーク135は、その機構の内部のネットワークである。インテグリティバリデータ140は、外部ネットワーク110と内部ネットワーク135の間に置かれ、機構の外部にあるコンピュータで、リソース145のような機構の内部にあるリソースにアクセスすることをリクエストしているコンピュータを検証する。リソース145は、どのような種類のリソース（例えば、数個例を挙げると、ネットワークドライブや、ディレクトリや、ファイルや、ウェブページなど）でもよい。このような検証をサポートするために、コンピュータシステム105は、インテグリティログジェネレータ150を備えている。このインテグリティログジェネレータ150は、そのコンピュータシステムに対するインテグリティログをまとめる。その後、インテグリティバリデータ140は、このインテグリティログを用いてコンピュータシステム105を検証する。

インテグリティログは、コンピュータシステム105における各種のモジュールに対応するシグネチャのセットである。ある実施例では、これらのシグネチャは、各種のモジュールのハッシュであり、MD5や、SHA-1や、SHA-256などのハッシュ関数155を用いて生成することができる。ある実施例では、インテグリティログジェネレータ150は、システムの起動シークエンスの早い段階で（好ましくは、他の何らかのドライバがロードされる前に）ロードされるデバイスドライバであってもよい。その後、インテグリティログジェネレータ150は、システムの起動シークエンスの間にアクセスまたはロードされる各モジュールを識別し、これらのモジュールに対するシグネチャを生成することができる。別の実施例では、インテグリティログジェネレータ150は、すべての可能性のあるモジュールに関してシステムの全体スキャンを実行することができる実行ファイル（executable）であってもよい。当業者ならば、インテグリティログジェネレータ150が動作することができるその他のやり方もわかるであろう。

ある実施例では、インテグリティログジェネレータ150は、デバイスドライバや実行可能モジュールなどの実際にロードされたモジュールに対してのみシグネチャを生成する。別の実施例では、インテグリティログジェネレータ150は、上記のようなモジュールおよびすべてのサポートモジュール（たとえば、動的リンクライブラリ（DLL））に対してシグネチャを生成する。当業者ならば、インテグリティログジェネレータ150がそれに対してシグネチャを生成することができる他のモジュールと、インテグリティログジェネレータ150が動作することができるその他のやり方がわかるであろう。

以上の説明から、インテグリティログジェネレータ150は、ソフトウェアモジュール上でしか動作できないことは明らかであろう。通常、ソフトウェアモジュールは、それらに対してインテグリティログジェネレータ150がシグネチャを生成する多数のモジュールからなるが、当業者ならば、インテグリティログジェネレータ150は、ハードウェアモジュールに対しても同様にシグネチャを生成することができることがわかるであろう。例えば、インテグリティログジェネレータ150は、コンピュータシステムの基本入出力システム（BIOS）内で用いられているファームウェアやハードウェアモジュールに対してもシグネチャを生成することができる。これらのファームウェアやハードウェアモジュールは、例えば、フラッシュメモリや、読み取り専用メモリ（ROM）や、プログラマブル読み取り専用メモリ（PROM）や、消去可能なプログラマブル読み取り専用メモリ（EPROM）や、電気的に消去可能なプログラマブル読み取り専用メモリ（EEPROM）や、強誘電ランダムアクセスメモリ（FRAM）や、磁気抵抗ランダムアクセスメモリ（MRAM）などに格納されていてもよい。

ひとたびシグネチャが生成されると、インテグリティログジェネレータ150は、それらのシグネチャをインテグリティログへとまとめる。このインテグリティログは、シグネチャが生成されたモジュールに対する識別子を含んでもよい。

識別子は、以下の要素を含んでもよい。
モジュールの絶対パスとそのファイル名
モジュールの製造会社
モジュールを内蔵する製品または構成要素。言い換えれば、この識別子は、モジュールが接続されている製品または構成要素を識別できる。
同一モジュールで異なるバージョンのものを区別できるようにするための、モジュールを内蔵するモジュールまたは製品または構成要素のバージョンまたはパスレベル。
当業者ならば、異なるタイプの識別子も使用可能であることがわかるであろう。

ある実施例では、インテグリティバリデータ140は、内部ネットワーク135に直接接続されていないコンピュータシステムを検証するためだけに用いられる。また、ある実施例では、内部ネットワーク135に接続されているコンピュータシステムは、安全かつ有効であるとわかっているという暗黙の仮定がある。これは、必ずしも無理な仮定（unreasonable assumption）というわけではない。というのも、ある機構の内部のコンピュータシステムは、通常その機構によって管理されるからである。こうして、ウィルス等（ウィルスやその類似物）に感染する可能性は、その機構の管理外のコンピュータシステムと比べて低くなる。この仮定を設けることで、機構内部のコンピュータシステムを検証する必要はなくなるため、その機構の内部（管理下）にあるコンピュータシステムはリクエストされたリソースによりすばやくアクセスすることができる。

それにもかかわらず、もうひとつの実施例では、内部ネットワーク135に直接接続されている（従って、外部ネットワーク110を介してリソースをリクエストしてはいない）コンピュータシステムでさえ、リソースにアクセスをリクエストする際に検証を受ける。リクエストされたリソースへのアクセスが遅くなる可能性があるものの、このように検証を行えば、その機構の内部のコンピュータシステム上からでさえ悪意あるエージェントを検出することができるという点においてセキュリティは強固なものとなる。

図１に示されている実施例では、インテグリティバリデータ140は、内部ネットワーク135に直接接続されているものとして図示されている。この実施例は、機構の内部のコンピュータシステムが、一般人には利用できないモジュールを含んでいる場合（例えば、モジュールが開発中の製品であったり、（例えば、政府により）機密扱いされていたりする場合）、うまく機能する。この実施例は、市販のモジュールしか使用していない機構でも機能するが、この実施例はこの機構がインテグリティバリデータ140をそのシステムの一部として含んでいることを必要とするであろう。別の実施例は、この機構が市販のモジュールのみを使用している場合にも利用でき、その場合、インテグリティバリデータ140は、その機構専用のインテグリティバリデータでなく、公的にアクセス可能なインテグリティバリデータであってもよい。このようなインテグリティバリデータは、インテグリティバリデータ160として外部ネットワーク110に接続されることとなる。インテグリティバリデータ160は、インテグリティログが外部ネットワーク110を介してインテグリティバリデータ160に送られることを除いてインテグリティバリデータ140と同様に動作する。

上述したように、ある実施例では、インテグリティバリデータ140は、その機構内部からのリソースに対するネットワークアクセスを検証する動作をする。インテグリティバリデータ140が、あるコンピュータシステム上のありえるすべてのモジュールに対するシグネチャを格納することは可能だが、別の実施例では、インテグリティバリデータ140は、その機構に関するモジュールに対するシグネチャのみを格納する。標準的なモジュール（またはインテグリティバリデータ140に正当であると認められていない別のモジュール）に対して、インテグリティバリデータ140は、検証のため、（外部ネットワーク110を介して）それらのシグネチャをインテグリティバリデータ160へ送る。このやり方では、インテグリティバリデータ160が、これらのモジュールの検証を担当することができるので、インテグリティバリデータ140は、新しいモジュールが導入されてもアップデートを行う必要がなくなる。

コンピュータシステム105が内部ネットワーク135に直接接属されていない場合、リソース145が暗号化された形式と暗号化されていない形式のどちらでリクエストされたとしてもインテグリティバリデータ140は動作することができる。同様に、この場合、リソース145が暗号化されたチャンネルと暗号化されていないチャンネルのどちらを用いてリクエストされたとしても、インテグリティバリデータ140は動作することができる。例えば、リソース145は、パスワードで保護されたウェブページであってもよい。または、リソース145は、リソースに対するアクセスを保護するために用いられる仮想プライベートネットワーク（VPN）を介してリクエストされてもよい。当業者ならば、リソース145に対するアクセスを管理する別のやり方もわかるであろう。

図２は、コンピュータの検証を実行するのに使用される図１のインテグリティバリデータ140のさらなる特徴を示している。図２には、インテグリティバリデータ140がかなり詳しく示されているが、当業者ならばここで示されている細部構造はどのようなインテグリティバリデータ（例えば、インテグリティバリデータ160）にも適用できるということがわかるだろう。また、当業者ならば、図２は、インテグリティバリデータ140内のデータフローを表しているわけではないということがわかるだろう。

インテグリティバリデータ140は、データベース205を有している。データベース205は、図３にかなり詳しく示されている。図３は、テーブル305として表されるデータベース205を示しているが、当業者ならば、データベース205がとることができる別の形式もわかるであろう。テーブル305は、多数のエントリー（入力）を有している。ただし、ここではそのうちのエントリー310、315、320が示されている。各エントリーは、モジュールおよびそれに対応するシグネチャを含んでいる。例えば、エントリー320は、Windows XPオペレーティングシステムの仮想メモリマネージャーDLLに対するシグネチャを示している（このエントリー320に対して示されているシグネチャは、実際のシグネチャではなく、シグネチャを表す乱数である）。エントリー310、315、320は、Microsoft CorporationのWindowsオペレーティングシステムの複数のバージョンに合わせて利用されるモジュールを表している（describe）が、当業者ならば、本発明の実施例は、他のオペレーティングシステムにも同様に適用できるということがわかるであろう。このようなオペレーティングシステムの例としては、例えば、Linuxオペレーティングシステムの複数のバージョンがある（MicrosoftおよびWindowsは、アメリカおよびその他の国のMicrosoft Corporationの登録商標であり、Linuxは、Linus Torvaldsの登録商標である）。

上述したように、テーブル305のエントリーは、各種モジュールに対する識別子を有している。テーブル305にモジュール識別子を含ませることで、モジュールの検証のために与えられたシグネチャを、当該モジュールに期待されるシグネチャと比較することができ、それによって、そのモジュールが適切に検証されているかどうかを確かめることができる。テーブル305は、モジュール識別子をひとつ（そのモジュールのパスとファイル名）しか保有していないように示されているが、当業者ならば、テーブル305は、その他のモジュール識別子を用いたり、なんらかのモジュール識別子の組み合わせを用いたりすることができるということがわかるであろう。

別の実施例では、テーブル305は、モジュール識別子を持たない有効とされたシグネチャしか保有しない。この場合、モジュールの検証のために与えられたシグネチャは、一致が見つかるまで、データベース205内のすべてのシグネチャと比較される。データベース205内のどこかで一致が見つかった場合、そのモジュールは、有効である（validated）とみなされる。そうでなければ、そのモジュールは、有効であるとはみなされない。シグネチャを算定するために選ばれた関数（すなわち、ハッシュ関数）の衝突する（collision）可能性が低い場合、有効にされていないモジュールのシグネチャがデータベース内のシグネチャと一致するリスクは、おそらく取るに足らないものである。しかし、モジュール識別子をデータベース205に持たせれば、このリスクは効率的になくすことができる。

少し戻って図２では、インテグリティバリデータ140は、その他の構成要素を備えている。レシーバ210は、インテグリティバリデータ140に送られる情報を受信するために設けられている。例えば、レシーバ210は、検証するべきコンピュータシステムからのインテグリティログや、新たに有効であるとされたモジュールに対応してデータベース205に加えられるシグネチャや、データベース205内にある既存のモジュールに対応する古いシグネチャを交換するための交換シグネチャを受け取ることができる。トランスミッタ215は、インテグリティバリデータ140からの情報を送信するために設けられている。例えば、トランスミッタ215は、トラストスコアをコンピュータシステムに送ったり、（インテグリティバリデータ140が、シグネチャに対応するモジュールを検証することができない場合）これらのシグネチャを別のインテグリティバリデータへ送ったりすることができる。

バリデータ220は、インテグリティバリデータ140で受信したシグネチャを検証するために設けられている。バリデータ220は、一つ以上のシグネチャを受け取り、どのシグネチャが有効とされているかを判定し、どのシグネチャが有効とされていてどのシグネチャが有効とされていないかを表したものを送り返す。バリデータ220は、比較器と同じくらい簡単に、受け取ったシグネチャをデータベース205内のシグネチャと比較し、その比較したシグネチャがデータベース205内のシグネチャと一致したかどうかを示すことができる。バリデータ220は、必要であれば、シグネチャを検証するためのより複雑な技術を実行することもできる。

トラストスコアジェネレータ225は、コンピュータシステムに対してトラストスコアを生成するために設けられている。トラストスコアは、コンピュータシステムが信頼にたるものかどうかを示すものである。トラストスコアは、様々な異なったやり方で生成することができる。ある実施例では、トラストスコアは、あるコンピュータシステム上の全モジュール（有効とされたものもそうでないものも含む）の数に対するコンピュータシステム上の有効とされたモジュールの数の割合である。別の実施例では、トラストスコアは、０から１０００の間の数をとることができる。この場合、０は、全く信頼できないコンピュータシステムを表し、１０００は、完全に信頼できるコンピュータシステムを表す。また別の実施例では、有効とされた重要なモジュールを多く含むコンピュータシステムが、有効とされた重要なモジュールをほとんど持たないコンピュータシステムよりも高く評価されるように（たとえ後者のコンピュータシステムの有効とされたモジュールの総数が前者のコンピュータシステムより多かったとしても高く評価されるように）、重要なモジュールは、他のモジュールより大きな重み付けがなされる。「重要（critical）」の定義は、ある機構（組織）にとって重要とされるモジュールと同じ程度に絶対的に必要なモジュールを意味するものではない。したがって、ある機構は、そのオペレーティングシステムに関連するファイルを「重要」であるとするかもしれないし、別の機構は、その内部でカスタム開発されたモジュールを（それがどんな目的で開発されたものであっても）「重要」であるとするかもしれない。

トラストスコアジェネレータ225がトラストスコアを算出するやり方は他にもある。別の実施例では、トラストスコアジェネレータは、インテグリティログ内における有効とされた各種モジュールの位置を計算に入れることができる。例えば、あらかじめインテグリティログにリストされているモジュールは、後からインテグリティログに加えられたモジュールより重要視される。別の実施例では、トラストスコアジェネレータ225は、トラストスコアを算出する際にモジュール識別子を計算に入れることができる。ある製造会社により製造されたモジュールを、別の製造会社により製造されたモジュールよりも重要視することができる。例えば、アプリケーションと連動して動作するモジュールの場合には、特定のアプリケーション製造会社に製造されたモジュールを、当該アプリケーションと関係のない製造会社に製造されたモジュールよりも重要視することができる。

また別の実施例では、モジュールのバージョンやパッチのレベルが、トラストスコアを算出する際の因子（ファクター）となることがある。例えば、モジュールに複数のバージョンがあると仮定すると、より新しいバージョンを古いバージョンよりも重要視することができる。有効とされているモジュールが期限切れである場合、そのトラストスコアは、同一のモジュールでより新しいバージョンのものを有する以外は同一のコンピュータシステムのトラストスコアよりも低くなる。

インテグリティバリデータ140は、ポリシー230を持つこともできる。ポリシー230は、コンピュータシステムが、どのような条件下でどのようにして図１のリソース145のようなリソースにアクセスすることを許可されるのかを示すことができる。ある実施例では、ポリシー230は、スレッショルドスコア235を持つ。リソースに対するアクセスを許可されるためには、コンピュータシステムは、少なくともスレッショルドスコア235以上のトラストスコアを持つ必要がある。そのコンピュータシステムに対するトラストスコアがスレッショルド235以下であった場合、そのコンピュータシステムはそのリソースに対するアクセスを拒否される。

別の実施例では、ポリシー230は、複数のスレッショルドスコアを持つことができる。例えば、図２では、ポリシー230は、ニつのスレッショルドスコア235と240を持つものとして示されている。このコンピュータシステムに対するトラストスコアがスレッショルドスコア235以上である場合、このコンピュータシステムはそのリソースに対する完全なアクセス（full access）が許可される。このコンピュータシステムに対するトラストスコアがスレッショルドスコア235未満でスレッショルドスコア240以上である場合、このコンピュータシステムはそのリソースに対する部分的なアクセス（partial access）が許可される。このコンピュータシステムに対するトラストスコアがスレッショルドスコア240未満である場合、このコンピュータシステムは、そのリソースに対するアクセスを拒否される（この場合、このコンピュータシステムは、ヘルプリソースにリダイレクトし、なぜこのコンピュータシステムのトラストスコアがこんなに低いのかを究明することができる）。

ポリシー230は以上の説明では、一つのリソースと二つ以下のスレッショルドスコアを有する例について記載されているが、当業者ならばポリシー230は、他のやり方で定義されてもよいことがわかるであろう。例えば、ポリシー230は、同一のネットワーク上の異なるリソースに対して異なるポリシーを記述することができる。すなわち、リソースに対するアクセス許可は、コンピュータシステムのトラストスコアと一つ以上のスレッショルドスコアの二者間でのスコア比較以外のやり方で判定される。また、ポリシー230が特定の機構のリソースにアクセスすることに対するポリシーであるのに対して、インテグリティバリデータ140が実際は複数の機構により使用されている（例えば、インテグリティバリデータ140がインテグリティバリデータ160のように外部ネットワークに接続されている）場合、インテグリティバリデータ140は、複数の機構（組織）に対するポリシーを格納することができる。

図２では、インテグリティバリデータ140は、トラストスコアとポリシー230を生成するのに用いられる両方の機能を有しているものとして示されているが、当業者ならばインテグリティバリデータ140は、これらの機能を兼ねそろえている必要はないとわかるであろう。例えば、インテグリティバリデータ140は、トラストスコアの生成だけを担い、（この生成されたトラストスコアに基づいた）ポリシー管理は他の場所で行うことができる。

図４は、図１のインテグリティバリデータが図２のデータベースを構築するのに用いる手順のフローチャートを示している。図４では、ステップ405で、モジュールが識別される。図４は、コンピュータシステムを検証するために用いられるデータベースを構築することに関する。モジュール識別はおそらく手作業で行われる。例えば、モジュール製造者は、シグネチャの生成およびデータベースに対するシグネチャの追加のためにモジュールを提示することができる。しかし、当業者ならば、モジュール識別は自動化できるとわかるであろう。ステップ410で、識別されたモジュールに対してシグネチャが生成される。ステップ415で、シグネチャはデータベースへ追加される。最後に、ステップ420で、モジュールに対する識別子をデータベースに加え、先ほどのシグネチャと関連付け、後のモジュール検証に利用することができる。矢印425で示されているように、ステップ425は、オプションであり省くことができる。

図５A−５Bは、図１のインテグリティバリデータが個々のモジュールシグネチャを検証するのに用いる手順のフローチャートを示している。図５Aでは、ステップ505で、インテグリティバリデータがモジュールに対するシグネチャ（および場合によってはそれに加えてモジュールに対する識別子）を受け取る。ステップ510で、このシグネチャはデータベースと比較される。モジュール識別子が与えられた場合、これを用いてデータベースの検索領域を減らすことができる。ステップ515で、インテグリティバリデータは、データベース内でこのシグネチャが見つかったかどうか判定する。見つかった場合、ステップ520で、このシグネチャは有効とされる（validate）。

インテグリティバリデータがデータベース内でこのシグネチャを見つけることができなかった場合、インテグリティバリデータは、ステップ525で、このシグネチャを検証することができる別のデータベース（またはインテグリティバリデータ）があるかどうか判定する。適当なデータベース（またはインテグリティバリデータ）が見つからなかった場合、ステップ530で、このシグネチャは無効であるとして拒絶され、処理が終了する。適当なデータベース（またはインテグリティバリデータ）が見つかった場合（そうでなければ）、ステップ535でインテグリティバリデータは、その別のデータベース（またはインテグリティバリデータ）にこのシグネチャを送る。ステップ540で、インテグリティバリデータは、シグネチャがその別のデータベースで見つかったかどうか判定する。見つかった場合、処理はステップ520へ戻り、このシグネチャは有効とされる。見つからなかった場合、処理はステップ525へ戻り、そこで、このシグネチャを送ることができるまた別のデータベース（またはインテグリティバリデータ）があるかどうか判定する。

図６は、図１に示されているコンピュータのようなコンピュータが、図１に示されているインテグリティバリデータを用いてインテグリティログをまとめ、コンピュータを検証するのに用いる手順のフローチャートを示している。ステップ605では、インテグリティログジェネレータはコンピュータシステム上のモジュールを識別する。ステップ610では、インテグリティログジェネレータは、これらのモジュールに対してシグネチャを生成する。別のやり方としては、インテグリティログジェネレータは、ステップ615で、これらのシグネチャをインテグリティログへとまとめてもよい。矢印620で示されているように、ステップ615は、省略可能である。すなわちこれらのシグネチャを、インテグリティログへとまとめる必要はない。最後に、ステップ625で、インテグリティログジェネレータは、検証のためにこれらのシグネチャ（および場合によってはそれに加えてモジュール識別子）をインテグリティバリデータへ送る。

図７Ａ−７Ｂは、図１に示されているインテグリティバリデータがコンピュータを検証するために用いる手順のフローチャートを示している。図７Ａでは、ステップ705で、インテグリティバリデータは、検証のためにシグネチャ（および場合によってはそれに加えてモジュール識別子）を受け取る。ステップ710では、インテグリティバリデータは検証のためにシグネチャを選択する。選択されるシグネチャは、シークエンス内の次のシグネチャであってよい。または、選択されるシグネチャは、別の基準で選択されてもよい。インテグリティバリデータは、ステップ715で、図５Ａ−５Ｂと関連して前述したようにシグネチャを検証しようと試みる。

ステップ720（図７Ｂ）では、インテグリティバリデータは、このシグネチャが有効とされているかどうか判定する。このシグネチャが有効とされている場合、ステップ725で、インテグリティバリデータは、データベースで見つかった（are found）シグネチャのセットにこのシグネチャを加える。シグネチャが有効とされていない場合、ステップ730で、データベース内で見つからなかったシグネチャのセットにこのシグネチャを加える。どちらの場合も、ステップ735で、インテグリティバリデータは、検証の済んでいない（まだ検証すべき）シグネチャが残っているかどうかを確認する。検証の済んでいないシグネチャが残っている場合、処理は、図７Ａのステップ710に戻る。検証の済んでいないシグネチャが残っていない場合、ステップ740で、インテグリティバリデータはトラストスコアを生成する。図２と関連して前述したように、このトラストスコアは、そのトラストスコアを生成する際に、特定の（certain）シグネチャをそれら以外のシグネチャよりも大きく重み付けることができる。

上述したように、ステップ715は、コンピュータシステムに対するシグネチャを検証するやり方について図５Ａ−５Ｂと関連している。上述したように、図５Ａ−５Ｂは、単一のシグネチャの処理と、最初のインテグリティバリデータがシグネチャを検証することができない場合にそのシグネチャを別のインテグリティバリデータに送ることを説明している。このアプローチは、インテグリティログ内にあるシグネチャのような複数のシグネチャの個々のシグネチャに対してはうまく機能するが、別の実施例では、最初のインテグリティバリデータを用いてできる限り多くのシグネチャを処理し、有効とされなかったシグネチャを第二のインテグリティバリデータにグループとして送る。

図８は、図１のコンピュータのようなコンピュータにネットワークリソースにアクセスすることを許可もしくは拒否するのに図１のインテグリティバリデータが用いる手順のフローチャートを示している。図８では、図７Ａ−７Ｂと関連して前述したように、ステップ805で、インテグリティバリデータは、コンピュータシステムに対してトラストスコアを生成する。ステップ810で、インテグリティバリデータは望ましいリソースに対するポリシーにアクセスする。ステップ815で、インテグリティバリデータは、トラストスコアとこのポリシーを比較する。最後に、ステップ820で、インテグリティバリデータは、このポリシーを用いて、このコンピュータシステムに対して、このリソースに対するアクセスの適切なレベルを決定する。

以下に、本発明の一定の態様を実施する適切なマシンの簡単な一般的な説明をする。通常、マシンは、例えばプロセッサ、メモリ（例えば、ランダムアクセスメモリ(RAM)やリードオンリーメモリ(ROM)や他の状態保存媒体）、記憶装置、映像インターフェースおよび出力／入力インターフェースポートなどが取付けられるシステムバスを含む。マシンは少なくとも一部分において、キーボード、マウスなどの従来の入力デバイスからの入力および別のマシンから受けた指示、バーチャルリアリティ(VR)環境、生体フィードバックまたは他の入力信号との情報交換によって制御することが可能である。本件明細書で使用されているマシン（machine）という語は、単一のマシンまたは、一緒に作動するマシンやデバイスと結合するコミュニケーションシステムを広く包含することを意図する。典型的なマシンは、自動車、列車、タクシーなどの個人的または公共の交通機関といった移動手段と同様に、パーソナルコンピュータ、ワークステーション、サーバ、ポータブルコンピュータ、携帯端末、電話、タブレットなどのコンピュータデバイスを含む。

また、マシンは、プログラマブルまたは非プログラマブル論理デバイスやアレイのような内蔵コントローラやASIC（Application Specific Integrated Circuits）や内蔵コンピュータやスマートカードなどを含んでもよい。また、マシンは、ネットワーク・インターフェース、モデムまたは他のコミュニケーションのカップリングを介して、一つまたは複数のリモートマシンへの一つまたは複数の接続を利用してもよい。さらに、マシンは、イントラネット、インターネット、ローカル・エリア・ネットワーク、広域ネットワークなどのような物理的、および/または論理的なネットワークを通して相互接続され得る。当業者であれば、ネットワークコミュニケーションが、無線周波数(RF)、衛星、電子レンジ、電気電子技術学会(IEEE)、545.11、ブルートゥース、光学の、赤外線のケーブル、レーザなどを含む様々な有線および/または無線の短距離または長距離キャリアとプロトコルを利用できることがわかるであろう。

本発明は、機能、手順、データ構造、アプリケーションプログラムなどを含む関連データを参照するか、あるいはそれらとの関連で説明することができる。これらの関連データは、マシンによりアクセスされたとき、当該マシンにタスクを実行させるか、あるいは抽象データ型か低レベルのハードウェアコンテキストを定義することになる。関連データは、例えば、RAM、ROMなどの揮発性および/または非揮発性メモリ、またはハードドライブ、フロッピーディスク、光記憶装置、テープ、フラッシュメモリ、メモリスティック、デジタルビデオディスク、生物学的記憶装置などを含む他の記憶装置とそれらの関連記憶媒体に格納することができる。関連データは物理的および/または論理的なネットワークを含む伝送環境で、パケット、シリアルデータ、並列データ、伝播された信号などの形で送信され、圧縮または暗号化された形式で使用できる。また、関連データは、分散環境で使用され、マシンのアクセスのために、局所的及び/または遠隔的に格納され得る。

図示された実施例に基づいて本発明の原理を記載しかつ説明したが、図示された実施例が係る原理から逸脱することなくその構成と詳細において変更してもよく、かつどのような望ましいやり方で組み合わせてもよいことを理解されたい。そして、以上の説明は特定の実施例に焦点を合わせたが、他の構成も考えることができる。特に、「本発明のある実施例に係る」という表現、または同様の表現がここで使用されるが、これらの語句は一般に参考実施例となり得ることを意味し、本発明を特定の実施例の構成に限定することは意図していない。ここに使用されるように、これらの語句は、他の実施例と組み合わせることができる同一または異なる実施例を表してもよい。

結論として、ここに説明された実施例へ多種多様に置き換えることができることを鑑みると、この詳細な説明および添付図面は例示のみを意図しており、発明の範囲を限定するものとして解するべきではない。したがって、本発明により主張されることはすべて、請求項とその同等物の範囲および精神を逸脱しないようなすべての変更を含むものである。

コンピュータの検証を実行するためのインテグリティバリデータを有するシステムを示している。 コンピュータの検証を実行するのに用いられる図１のインテグリティバリデータをより詳細に示している。 図２のデータベースをより詳細に示している。 図１のインテグリティバリデータが図２のデータベースを構築するのに用いる手順のフローチャートを示している。 図１のインテグリティバリデータが個々のモジュールシグネチャを検証するのに用いる手順のフローチャートを示している。 図１のコンピュータシステムのようなコンピュータシステムが、図１のインテグリティバリデータを用いてインテグリティログをまとめ、コンピュータシステムを検証するために用いる手順のフローチャートを示している。 図１のインテグリティバリデータがコンピュータシステムを検証するために用いる手順のフローチャートを示している。 図１のインテグリティバリデータが、図１のコンピュータシステムのようなコンピュータシステムにネットワークリソースに対するアクセスを許可または拒否するために用いる手順のフローチャートである。

Claims (21)

1. 第一の複数のモジュールに対する第一の複数のシグネチャであって、各シグネチャは前記第一の複数のモジュール中の一モジュールのハッシュである前記第一の複数のシグネチャを格納するために設けられているデータベースと、
   マシン内の第二の複数のモジュールに対応する第二の複数のシグネチャであって、各シグネチャは前記第二の複数のモジュール中の一モジュールのハッシュである前記第二の複数のシグネチャを受け取るためのレシーバと、
   前記第二の複数のシグネチャのうちで受け取った少なくとも一つのシグネチャを前記データベース内の複数のシグネチャのうちの一つまたは複数のシグネチャと比較し、前記第二の複数のモジュールのうち前記データベース内で対応するシグネチャが見つかったモジュールを有効なモジュールとして識別し、前記第二の複数のモジュールのうち前記データベース内で対応するシグネチャが見つからなかったモジュールを有効でないモジュールとして識別する動作をするバリデータと、
   前記マシン内の第二の複数のモジュールの総数に対する前記有効なモジュールの数の割合である、前記マシンに対するトラストスコアを生成するためのトラストスコアジェネレータと、
   を有する装置。
2. 前記装置は、
   前記有効でないモジュールに対応するシグネチャを、第二のデータベースを有する別の装置へ送るトランスミッタ、
   を更に有し、
   前記レシーバは、前記別の装置から前記第二のデータベース内に前記送ったシグネチャが含まれるか否かを受け取る動作をし、
   前記トラストスコアジェネレータは、前記送ったシグネチャのうち前記第二のデータベースに含まれていたシグネチャに対応するモジュールの数を前記有効なモジュールの数に加算して、前記トラストスコアを生成する動作をする、
   ようになっている請求項１に記載の装置。
3. 前記データベースは、前記第一の複数のモジュールに対する第一の複数の識別子を格納するために設けられており、
   前記レシーバは、前記第二の複数のモジュールに対する第二の複数の識別子を受け取る動作をし、
   前記バリデータは、前記マシン内の前記複数のモジュールに対する前記第二の複数の識別子を用いて、前記第二の複数のシグネチャと前記データベース内の前記複数のシグネチャを比較する動作をする、
   ようになっている請求項１に記載の装置。
4. リソースに対するアクセスを制御するためのポリシー、
   を更に有し、
   前記ポリシーが前記リソースに対する完全なアクセスをする資格を得るためのスレッショルドスコアを含んでいる、
   ことを特徴とする請求項１に記載の装置。
5. 前記ポリシーが前記リソースに対する部分的なアクセスをする資格を得るための第二のスレッショルドスコアを更に含んでいる、
   ことを特徴とする請求項４に記載の装置。
6. 前記レシーバは、モジュールのシグネチャを受け取り前記データベースへ加えるように動作をする、
   ことを特徴とする請求項１に記載の装置。
7. ネットワークと、
   前記ネットワークに接続されたリソースと、
   第一の複数のモジュールに対する第一の複数のシグネチャであって、各シグネチャは前記第一の複数のモジュール中の一モジュールのハッシュである前記第一の複数のシグネチャを含むインテグリティログを生成するためのインテグリティログジェネレータを有し、前記ネットワークに接続されたコンピュータと、
   前記ネットワークに接続されている装置と、
   を備え、
   該装置は、
   第二の複数のモジュールに対する第二の複数のシグネチャであって、各シグネチャは前記第二の複数のモジュール中の一モジュールのハッシュである前記第二の複数のシグネチャを格納するために設けられているデータベースと、
   前記コンピュータから前記インテグリティログを受け取るためのレシーバと、
   前記第一の複数のモジュールのうち前記データベース内に対応するシグネチャがあるモジュールの数の、前記コンピュータに含まれる前記第一の複数のモジュールの総数に対する割合である、トラストスコアを生成するためのトラストスコアジェネレータと、
   前記リソースに対するアクセスを制御するためのポリシーと、
   を有し、
   前記ポリシーは、前記リソースに対する完全なアクセスをする資格を得るためのスレッショルドスコアを含んでおり、前記リソースに対する前記コンピュータのアクセスが前記ポリシーにより制御される、
   ことを特徴とするシステム。
8. 前記システムは、第二の装置を更に含み、
   前記第二の装置は、第三の複数のモジュールに対する第三の複数のシグネチャを格納するために設けられている第二のデータベースを有し、
   前記装置は、前記有効でないモジュールに対応するシグネチャを前記第二の装置に送るためのトランスミッタを有し、
   前記第二の装置は、前記トランスミッタから送られたシグネチャが前記第二のデータベース内にあるか否かを前記レシーバに送る、
   ことを特徴とする請求項７に記載のシステム。
9. 第二のネットワークを更に有し、
   前記装置と前記第二の装置が前記第二のネットワークに接続されている、
   ことを特徴とする請求項８に記載のシステム。
10. 装置がマシンのインテグリティを検証する方法であって、
    当該装置は、レシーバと、バリデータと、データベースと、トラストスコアジェネレータとを有し、
    前記レシーバが、前記マシン内の複数のモジュールに対応する第一の複数のシグネチャであって、各シグネチャは前記マシン内の前記第一の複数のモジュール中の一モジュールのハッシュである前記第一の複数のシグネチャを受け取るステップと、
    前記バリデータが、前記複数のモジュールに対する前記第一の複数のシグネチャを前記データベース内の第二の複数のシグネチャであって、各シグネチャは一モジュールのハッシュである前記第二の複数のシグネチャと比較するステップと、
    前記バリデータが、前記複数のモジュールのうち前記データベース内で対応するシグネチャが見つかったモジュールを有効なモジュールとして識別し、前記複数のモジュールのうち該データベース内で対応するシグネチャが見つからなかったモジュールを有効でないモジュールとして識別するステップと、
    前記トラストスコアジェネレータが、前記マシン内の複数のモジュールの総数に対する前記有効なモジュールの数の割合である、トラストスコアを生成するステップと、
    を含む方法。
11. 当該装置は、第一のスレッショルドスコアを有するポリシーを更に有し、
    前記装置が、前記トラストスコアが前記第一のスレッショルドスコアより大きい場合に、前記マシンのネットワーク上のリソースに対するアクセスを許可するステップ、
    を更に含む請求項１０に記載の方法。
12. 前記マシンのネットワーク上のリソースに対するアクセスを許可するステップが、
    前記装置が、前記ポリシーにアクセスするステップ、
    を更に含んでいる、
    ことを特徴とする請求項１１に記載の方法。
13. 前記ポリシーは、第二のスレッショルドスコアを更に有し、
    前記マシンのネットワーク上のリソースに対するアクセスを許可するステップは、
    前記装置が、前記トラストスコアが前記第二のスレッショルドスコア未満で前記第一のスレッショルドスコアより大きい場合、前記リソースに対する部分的なアクセスを許可するステップ、
    を含む、
    ことを特徴とする請求項１２に記載の方法。
14. 前記装置が、前記トラストスコアが前記第一のスレッショルドスコア未満である場合、前記リソースに対するアクセスを拒否するステップ、
    を更に含む、
    ことを特徴とする請求項１２に記載の方法。
15. 前記トラストスコアを生成するステップは、
    前記トラストスコアジェネレータが、前記トラストスコアを生成する際に、少なくとも第一のモジュールを少なくとも第二のモジュールよりも大きく重み付けるステップ、
    を含む、
    ことを特徴とする請求項１０に記載の方法。
16. 前記第一の複数のシグネチャを受け取るステップは、
    前記レシーバが、前記複数のモジュールに対応する前記第一の複数のシグネチャを含んでいるインテグリティログを受け取るステップ、
    を含む、
    ことを特徴とする請求項１０に記載の方法。
17. 当該装置は、トランスミッタを更に有し、
    前記方法は、さらに、
    前記トランスミッタが、前記有効でないモジュールに対応する前記シグネチャを、第二のデータベースを有する別の装置に送るステップと、
    前記レシーバが、前記別の装置から前記第二のデータベース内に前記送ったシグネチャが含まれるか否かを受け取るステップと、
    を含み、
    前記トラストスコアを生成するステップは、前記トラストスコアジェネレータが、前記送ったシグネチャのうち前記第二のデータベースに含まれていたシグネチャに対応するモジュールの数を前記有効なモジュールの数に加算して、前記トラストスコアを生成するステップを含む、
    ことを特徴とする請求項１０に記載の方法。
18. 前記複数のモジュールに対応する第一の複数のシグネチャを受け取るステップは、前記レシーバが、前記第一の複数のシグネチャおよび前記複数のモジュールに対する複数の識別子を受け取るステップを含み、
    前記複数のモジュールに対する前記第一の複数のシグネチャをデータベース内の第二の複数のシグネチャと比較するステップは、前記バリデータが、前記複数のモジュールに対する前記第一の複数のシグネチャを、前記複数のモジュールに対する前記複数の識別子を用いて、前記データベース内の第二の複数のシグネチャと比較するステップを含む、
    ことを特徴とする請求項１０に記載の方法。
19. 前記トラストスコアを前記マシンに送信するトランスミッタ、
    を更に有する請求項１に記載の装置。
20. 前記トラストスコアを前記コンピュータに送信するトランスミッタ、
    を更に有する請求項７に記載のシステム。
21. 前記装置は、トランスミッタを更に有し、
    該トランスミッタが、前記トラストスコアを前記マシンに送信するステップ、
    を更に含む請求項１０に記載の方法。

Images