JP5961708B2 - 集中型の操作管理 - Google Patents

Description

コンピュータシステムに格納されコンピュータシステム上で実行されているプログラムの識別及び信頼性は、ユーザにとって基本的なセキュリティ課題である。基本的に、ユーザは対話操作を行うプログラムが宣伝されている通りに機能することを望んでいる。ユーザが特定のプログラムを信頼しているのに、そのプログラムが予期しない動作をすると、ユーザは問題に遭遇する可能性がある。幾つかの状況において、プログラムが故意に改ざんされている場合もあれば、又はウイルス若しくは他のセキュリティ問題が存在する場合もある。プログラムが、単にユーザが当初予期したものと異なる動作をする場合も往々にしてある。この原因は、そのプログラムが信頼済みソースに由来するものでないか、或る時点で改ざんされて他のコンポーネントとの互換性を失ったか、又は他の何らかの理由で無効になったためである。

それ故、この問題への対処を試みるため、近年のコンピュータ上で多くのセキュリティプログラムが実行されている。これらのアプリケーションの各々は、コンピュータの一連のセキュリティニーズに対処するものであり、ウイルス対策アプリケーション、ファイアウォール、マルウェア検出プログラム、署名チェックメカニズムなどを含む。これらのプログラムのなかには、オペレーティングシステムの一部として提供されるものもあれば、インターネットブラウザに統合されているものもあり、他方、サードパーティベンダーから購入されるか又はダウンロードされるものさえある。

しかしながら、これらのプログラムは、ＩＤの認証を確立する上で一貫性のあるメカニズムではない。システム内で実行されている何らかの操作によって、信頼できないソースに由来するデータオブジェクトが導入されてしまい、コンピュータに危害を与える可能性があるにもかかわらず、オペレーティングシステム内で実行されている全ての操作の包括的なチェックを必ずしも当てにできるとは限らない。これらのプロセスは、オペレーティングシステム内で最適に機能できず、システム全体の速度を減速させてしまうこともしばしばである。これらのセキュリティプログラムが寄せ集めの性質を持つため、一連の統一されたセキュリティインターフェースプログラミングを導入することはソフトウェア開発者にとって困難又は不可能にもなっている。更に悪いことに、これらの雑多な取り合わせのセキュリティ評価プログラムのなかには、厳密に信頼され得るものとしての認定を受けていないソースから来た可能性のあるものもある。

ＩＤ認証を確立するためには、一貫性あるメカニズムが必要とされる。特に必要とされるのは、一貫性あるパフォーマンス、オペレーティングシステム内で為されている操作の包括的検査、及び均質なソフトウェア開発サポートを提供する目的にオペレーティングシステムと完全に統合されたセキュリティ評価メカニズムである。

本発明の幾つかの実施形態では、デバイス向けの新規なセキュリティフレームワークが提供されている。幾つかの実施形態において、このフレームワークは、デバイスのオペレーティングシステムの一部である。幾つかの実施形態のフレームワークには、デバイス上で実行されているアプリケーションに対して実行する必要のある様々な操作に関するセキュリティポリシーの評価を行うセキュリティ評価モジュールが具備されている。そのような操作の例としては、アプリケーションのインストール及び実行、並びにアプリケーションでコンテンツファイルを開く（例えば、文書を開く）ことが挙げられる。

幾つかの実施形態において、アプリケーションに対する様々な操作の要求を受け取る操作開始モジュールが、デバイスに具備されている。そのような要求を受け取ると即座に、操作開始モジュールは、セキュリティ評価モジュールに対し、セキュリティポリシーのデータストレージに格納されているセキュリティポリシールールに基づいて、要求された操作の実行可能性をチェックするように指示する。幾つかの実施形態においては、ダウンロードされたプログラムの妥当性のチェック、プログラムのソース又は発行者の検証などに、セキュリティポリシールールが使用される。要求された操作がセキュリティポリシールールによって許可された場合、セキュリティ評価モジュールは、操作が承認されたことを操作開始モジュールに通知する。操作開始モジュールは、該当する操作ハンドラ（例えば、インストーラ、実行モジュール、又はファイルを開くモジュール）に対し、要求された操作を遂行するように指示する。

幾つかの実施形態において、セキュリティポリシーは、ルールデータベース内に格納されている様々なルール又は命令の形で具体化される。ルールデータベース内のルールは、データオブジェクト（例えば、プログラムコード、又は開く対象の文書）がコンピュータのセキュリティポリシーに適合するために何が必要かを指定する。幾つかの実施形態において、幾つかの実施形態において、ルールデータベースは、ルールデータベースに対するクエリの実行を効率化するための、様々なテーブルを具備する。そのようなテーブルの例として、権限テーブル及びキャッシュテーブルの２つが挙げられる。

幾つかの実施形態においては、セキュリティポリシーの下でデータオブジェクトのセキュリティを評価する際に、ルールデータベース内の権限テーブルのエントリを、その優先度によって示された順序で調べる必要がある。これらの実施形態においては、データオブジェクトに対して如何なるセキュリティ評価を行う際にも、優先度の低いルールが適用可能になるのは、優先度の高いルールが適用できない場合だけに限られる。優先度の高いルールと優先度の低いルールが重複する場合は、優先度の高いルールの方が優先度の低いルールよりも優先される。故に、優先度の高いルールに対して何らかの変更を行った場合、優先度の低いルールの適用範囲が変わる可能性がある。

幾つかの実施形態において、操作開始モジュールはアプリケーションに要求された各々の操作に対してセキュリティ評価を実行する。他の実施形態において、操作開始モジュールがセキュリティ評価を実行する対象の操作は、アプリケーションに要求される操作のうちの一部だけである。例えば、幾つかの実施形態においては、新規に受け取ったアプリケーションのインストール、又はアプリケーションが新規に受け取ったファイルを初めて開くことに対してのみ、評価が実行される。このアプローチを容易にするため、幾つかの実施形態のデバイスは、新規に受け取ったアプリケーション及び新規に受け取ったファイルにタグを関連付ける。このタグの関連付けが為されるのは、そのようなファイルが初めてデバイス上にローディングされたとき又は初めて開かれたとき（例えば、ネットワーク経由で又はデバイスの周辺インターフェースを介して初めてダウンロードされたとき）である。

幾つかの実施形態のセキュリティ評価モジュールは、データファイルが含まれているデータ構造（「アーカイブ」など）の妥当性を検証することによって、１つ以上のデータファイルの妥当性を承認又は不承認する。そのような幾つかの実施形態においては、アーカイブにＩＤ署名が保持されており、このＩＤ署名を使用することによって、データファイルを安全に認証できると共に、それらのアーカイブ内に含まれるデータファイルのソースを識別できる。より具体的には、これらの実施形態のオペレーティングシステムにおいては、それらの文書又はデータファイルを含むアーカイブ構造内に埋め込まれた署名に基づいて文書又はデータファイルを承認又は不承認するルールが、ルールデータベース内に含まれている。承認済みアーカイブ内の文書は、自動的に承認される。

以上の概要は、本発明の幾つかの実施形態を簡潔に紹介するためのものである。本明細書に開示された全ての発明内容の紹介又は概要を意味しない。以下の詳細な説明、及び詳細な説明で引用される図面は、更に、要約で述べた実施形態並びに他の実施形態について述べる。したがって、本明細書で述べる全ての実施形態を理解するために、要約、詳細な説明及び図面の十分な検討が必要とされる。更に、特許請求された内容は、要約、詳細な説明及び図面における実例となる詳細によって限定されず、特許請求された内容は、主題の趣旨から逸脱しない他の特定の形態で実施することができるので、添付の特許請求の範囲によって定義される。

本発明の新規の特徴は、添付の特許請求の範囲で説明される。しかしながら、説明のため、本発明の幾つかの実施形態は、以下の図に示される。
実行するように要求された様々な操作のセキュリティを評価するコンピューティングデバイスのオペレーティングシステムを示す図である。 オペレーティングシステムが要求された操作の処理及び承認に用いるプロセスを概念的に示す図である。 オペレーティングシステムのセキュリティポリシーに基づいて要求された操作のセキュリティ評価を遂行するためのプロセスの例を概念的に示す図である。 セキュリティ評価モジュール及びルールデータベースを使用してセキュリティ評価を遂行する際のオペレーティングシステム内のデータフローを示す図である。 セキュリティ評価モジュール及びルールデータベースを使用してセキュリティ評価を遂行する際のオペレーティングシステム内のデータフローを示す図である。 セキュリティ評価モジュール及びルールデータベースを使用してセキュリティ評価を遂行する際のオペレーティングシステム内のデータフローを示す図である。 オペレーティングシステムのセキュリティポリシーを判定するためのルール又は命令を格納する権限テーブルを概念的に示す図である。 追加のフィールドを含む権限テーブルを概念的に示す図である。 各レコード又はエントリ内に１つのルールフィールドのみを含む権限テーブルを概念的に示す図である。 複数のエントリを使用して単一のセキュリティポリシーを表す権限テーブルを示す図である。 セキュリティポリシーの例を表す一連のベン図である。 別のセキュリティポリシーの例を表す一連のベン図である。 権限テーブルを使用してセキュリティ評価を実行するためのプロセスを概念的に示す図である。 権限テーブルとキャッシュテーブルとを含むルールデータベースを示す図である。 操作開始モジュールからの要求に基づいてセキュリティ評価のために権限テーブル及びキャッシュテーブルの両方を使用するセキュリティ評価モジュールを示す図である。 データオブジェクト用キャッシュテーブルエントリをセキュリティ評価モジュールが生成し格納することを示す図である。 権限テーブルとキャッシュテーブルの両方をセキュリティ評価の実行に使用するプロセスを概念的に示す図である。 ユーザによるルールデータベースの変更後にルールテーブルを保守管理するプロセスを概念的に示す図である。 セキュリティ評価を実行するため自身の識別子を挿入するオペレーティングシステムを有するコンピュータを概念的に示す図である。 セキュリティ評価操作の一環としてタグをチェックするオペレーティングシステムを示す図である。 データオブジェクト内のタグを識別する操作開始モジュールを使用してセキュリティ評価を実行したときの、オペレーティングシステム内のデータフローを示す図である。 データオブジェクト内のタグを識別する操作開始モジュールを使用してセキュリティ評価を実行したときの、オペレーティングシステム内のデータフローを示す図である。 タグビットを処理するためのルールを含むルールデータベースを有するオペレーティングシステムを示す図である。 署名を含むデータアーカイブを受け取って格納するコンピュータを示す図である。 データアーカイブ内の署名に基づいてデータファイル又は文書のセキュリティ評価を行うためのルールをルールデータベース内に含むオペレーティングシステムを示す図である。 文書を開く操作のセキュリティ評価を実行するプロセスを概念的に示す図である。 本発明の幾つかの実施形態が実行される電子システムを概念的に示す図である。

下掲の明細書本文には、説明のため多数の詳細を記載するが、これらの具体的な詳細を用いることなしに本発明を実施できることは、当業者に理解されるであろう。他の例では、本発明の記述を余計な詳細で不明瞭にしないように、周知の構造及び装置がブロック図の形で示される。

Ｉ．セキュリティ評価を備えるオペレーティングシステム
図１は、実行が要求された様々な操作のセキュリティを評価するコンピューティングデバイスのオペレーティングシステム１００を示す。要求された操作は、アプリケーションの実行、アプリケーションのインストール、文書を開くことなどであり得る。要求された操作のセキュリティは、オペレーティングシステムによって提供されるセキュリティフレームワークの一部であるセキュリティ評価モジュールによって評価される。このセキュリティ評価に基づいて、要求された操作を終了するか、又はその処理の続行を許可する。

図１に示すように、オペレーティングシステム１００は、セキュリティ評価モジュール１１０と、ルールデータベース１２０と、操作開始モジュール１３０と、操作要求モジュール１４０と、インストールモジュール１７０と、実行モジュール１７２と、コンテンツを開くモジュール１７４と、を含む。図１にはまた、オペレーティングシステム１００がセキュリティポリシーを評価する対象のアプリケーション１５０及びデータファイル１６０も示してある。セキュリティ評価モジュール１１０及びルールデータベース１２０は、アプリケーションプログラミングインターフェース（ＡＰＩ）１９０を提供するセキュリティフレームワーク１８０の一部である。

オペレーティングシステム１００は、コンピュータハードウェアリソースを管理すると共に様々なソフトウェアアプリケーションプログラムに対して共通サービスを提供する、一連のプログラムである。オペレーティングシステム１００は、アプリケーションプログラムとコンピュータハードウェアとの間の橋渡し役として入力、出力、及びメモリ割り当てなどの機能を遂行する。幾つかの実施形態において、プログラムのアプリケーションコードはハードウェアを介して実行され、オペレーティングシステムから受け取った割り込み、又はオペレーティングシステムに対して行われた呼び出しを介してオペレーティングシステムと相互作用する。

アプリケーション１５０は、オペレーティングシステム上で稼動して機能を遂行する実行可能データオブジェクトである。アプリケーション１５０の例としては、ワードプロセッサ、ウェブブラウザ、ゲーム、メディア編集用アプリケーションなどが挙げられる。幾つかの実施形態において、アプリケーション１５０は、オペレーティングシステム１００が実行されているコンピュータ上に１つ以上の実行可能プログラムをインストールするインストールプログラムである。

幾つかの実施形態において、アプリケーション１５０は、アプリケーションのユーザがアプリケーションの信頼性を判定できるように、ＩＤ署名を１つ以上埋め込む。アプリケーション１５０に埋め込まれた署名は、アプリケーションのソース、即ち発行元のセキュアなＩＤである。データオブジェクトの署名者にしか解らない秘密のプライベートキーを使用してデータオブジェクトのコンテンツに基づいて署名が生成されると、データオブジェクト（例えば、アプリケーション）が「署名」される。したがって、そのような署名によって、データオブジェクトの署名者又はソースを識別することも、データオブジェクトの完全性を保護することもできる。データオブジェクトの署名を認証するために、即ち、実際に署名がそうであると言われている（proported）ソース／署名者によってデータオブジェクトから生成されことを検証するために、データオブジェクト（即ち、オペレーティングシステム）の受領者では公開鍵を使用して、データオブジェクトのコンテンツと共に署名を認証する。公開鍵はそうであると言われているソース／署名者に由来するものであることは公知であり、さらに公開鍵が本当にそうであると言われているソース／署名者によって発行されていることは、（例えば、信頼済み認証局に問い合わせるか、又は受領者自身のデータベースをチェックすることによって）受領者が独立に検証できる。

幾つかの実施形態において、データオブジェクトの署名は、データオブジェクトに関連付けられている公開鍵証明書から抽出される。公開鍵証明書（別称：デジタル証明書又はＩＤ証明書）は、デジタル署名を使用して、人又は組織の名前、そのアドレスなどのようなＩＤ情報に公開鍵をバインドする電子文書である。証明書は、公開鍵が或る個人に帰属することを検証する目的に使用できる。証明書上の署名は、ＩＤ情報及び公開鍵が共に帰属することを証明書の署名者が認証したものである。アプリケーションデータオブジェクトのコンテンツ、及び証明書内の情報の両方に基づいて生成又は署名される署名は、認証されたときに、アプリケーションデータオブジェクトのコンテンツに改ざんがなく証明書内の情報が真正であることを証明する。証明書には、署名及びソース識別子（例えば、ベンダーＩＤ及び公開鍵）に加えて、署名の認証方法（例えば、署名の生成に用いられるアルゴリズムのＩＤ）に関する情報も含まれる。

図１の例では、オペレーティングシステム１００によって署名認証の操作が実行されている。幾つかの実施形態において、オペレーティングシステム１００は、アプリケーション１５０の署名の認証に失敗した場合、アプリケーション１５０の実行又はインストールを禁止する。幾つかの実施形態において、オペレーティングシステム１００は、認証されたアプリケーションに対してさえも、セキュリティポリシーのセットに従ってアプリケーションの発行元が信頼できるものとして判定されなければ、そのアプリケーションの操作が続行されるのを禁止する。

データファイル１６０は、オペレーティングシステム内で実行できる１つ以上のアプリケーションに関連付けられたデータオブジェクトである。データファイル１６０の例としては、テキストファイル、ワードプロセッサ文書、スプレッドシート、メディアファイルなどが挙げられる。データファイル１６０は、データファイルを読み込み又は開くことができるアプリケーションによって、読み込まれ又は開かれる。幾つかの実施形態において、データファイル１６０には、署名又は証明書が含まれていない文書が含まれる。また、署名又は証明書にデータファイルを関連付けることができるように、データファイルをアーカイブ構造内に配置してもよい。幾つかの実施形態のセキュリティ評価モジュールが、データアーカイブ内のデータファイルを扱う仕組みを、下掲の図２５及び２６に示す。

インストールモジュール１７０は、アプリケーション１５０などのアプリケーションのインストールを監督する、オペレーティングシステム１００内部のモジュールである。幾つかの実施形態において、インストールモジュール１７０は、操作開始モジュール１３０から「続行」コマンドが送られてくるのを待ってから、オペレーティングシステムを介してアプリケーション１５０のインストール処理を続行する。これらの実施形態の幾つかにおいて、セキュリティポリシーのセットに従ってアプリケーションの署名、及び一連の要件に対する適合性を検証する目的で、インストールモジュールはアプリケーションデータオブジェクト１５０をセキュリティ評価モジュール１１０に渡す。インストールモジュール１７０は、アプリケーション１５０の認証及びそのソースの検証が為されたことを示す情報を操作開始モジュール１３０から受け取った場合に限り、アプリケーション１５０のインストールを続行する。

実行モジュール１７２は、アプリケーション１５０などの、オペレーティングシステム１００内で実行されるアプリケーションを起動する、オペレーティングシステム１００内部のモジュールである。実行モジュール１７２はインストールモジュール１７０と同様に、幾つかの実施形態において、操作開始モジュール１３０からの「続行」コマンドを待ってから、オペレーティングシステム１００を介してアプリケーション１５０を起動する。これらの実施形態の幾つかにおいて、実行モジュールは、セキュリティポリシーのセットに従ってアプリケーションの署名を検証し一連の要件を満たすために、アプリケーションデータオブジェクト１５０をセキュリティ評価モジュール１１０に渡す。アプリケーション１５０の認証及びそのソースの検証が為された後に、操作開始モジュール１３０から起動コマンドを受け取った場合に限り、実行モジュール１７２がアプリケーション１５０の実行を続行する。

コンテンツを開くモジュール１７４は、データファイル１６０が開かれるのを監督する、オペレーティングシステム１００内部のモジュールである。幾つかの実施形態において、コンテンツを開くことは、データファイル１６０内のコンテンツに適したアプリケーションを識別してから、そのコンテンツをアプリケーションに渡す操作を伴う。前述したように、データファイルのコンテンツは、署名を伴う場合もあれば又は伴わない場合もあり、認証を必要とする場合もあれば又は必要としない場合もある。文書の認証が必要とされる場合は、セキュリティポリシーのセットに従って文書の署名を検証し一連の要件を満たす目的で、文書がセキュリティ評価モジュール１１０に渡される。コンテンツを開くモジュール１７４は、データファイル１６０の認証及びそのソースの検証が為された後に、操作開始モジュール１３０から起動コマンドを受け取った場合に限り、文書、即ちデータファイル１６０を開くことに進む。

幾つかの実施形態において、データファイル１６０を開くことは、アプリケーションの実行に関連付けられている。これらの実施形態の幾つかにおいて、コンテンツを開くモジュール１７４は最初に、データファイル１６０を開くためのアプリケーションを識別する。コンテンツを開くモジュール１７４によって識別されたアプリケーションがオペレーティングシステム内で既に実行されている場合、コンテンツを開くモジュールは、実行対象となる実行モジュール１７２にデータファイルを渡す。識別されたアプリケーションが現時点で実行されていない場合、コンテンツを開くモジュール１７４は、実行モジュール１７２にアプリケーションの実行を開始させる。アプリケーションの認証及びそのソースの検証が為されたことがオペレーティングシステム１００によって判定された後ではじめて、識別されたアプリケーションの実行が為される。

操作要求モジュール１４０は、オペレーティングシステム１００による特定の操作の実行を要求するモジュールである。そのような操作には、アプリケーションのインストール、アプリケーションの実行、文書を開くことなどが含まれ得る。幾つかの実施形態において、操作要求モジュール１４０は、（例えば、文書又はアプリケーションのグラフィカルアイコンを選択することによって）文書を開くための又は特定のアプリケーションを実行するためのユーザコマンドを受け取るユーザインターフェース（ＧＵＩなど）である。操作要求モジュール１４０はまた、オペレーティングシステム内で実行されていて、操作開始モジュール１３０に対して操作の実行を要求する別のプログラムである場合もある。幾つかの実施形態において、操作要求モジュール１４０はまた、オペレーティングシステム１００のセキュリティポリシーによって操作の実行が許可されない場合（例えば、アプリケーション１５０の署名が認証に失敗したか、又はアプリケーション１５０のソースが信頼されていない場合）、操作開始モジュール１３０からの通知を受け取る。

操作開始モジュール１３０は、特定の操作が為されるのを許可するか又は禁止することによって、オペレーティングシステムのセキュリティポリシーを施行するモジュールである。操作開始モジュール１３０は、操作要求モジュール１４０から特定の操作に対する要求を受け取る。操作開始モジュール１３０は、要求に基づいて、必要なデータオブジェクト（例えば、アプリケーション１５０又はデータファイル１６０）を取得する。その後、操作開始モジュール１３０は、セキュリティ評価モジュール１１０に対し、オペレーティングシステム１００のセキュリティポリシーの下で要求された操作を評価するように要求する。操作開始モジュールはまた、要求したセキュリティ評価操作の一環として、受け取ったデータオブジェクトをセキュリティ評価モジュールに渡す。

セキュリティ評価モジュール１１０は、或る操作がオペレーティングシステムのセキュリティポリシーに適合したものであるかどうかを判定するモジュールである。セキュリティ評価モジュール１１０は、操作開始モジュール１３０から、特定の操作に関するセキュリティポリシーの評価を要求するクエリを受け取る。セキュリティ評価モジュール１１０は、操作に関連付けられているデータオブジェクトを調べることによって、操作がセキュリティポリシーに適合したものであるかどうかを判定する。例えば、アプリケーション１５０をインストールする操作に基づく要求は、セキュリティ評価モジュールが調べる幾つかのデータオブジェクト（例えば、アプリケーション１５０用インストールパッケージのインストールファイル、及びインストールプログラム自体）を含み得る。別の例において、データファイル１６０をアプリケーション１５０で開く要求には、セキュリティ評価モジュール１１０によって検査されるアプリケーション１５０の実行可能プログラム及びデータファイル１６０の両方に対するデータオブジェクトが含まれ得る。幾つかの実施形態において、アプリケーション１５０及びデータファイル１６０は、セキュリティ評価の対象と言われるものである。続いて、セキュリティ評価モジュール１１０は、操作開始モジュール１３０から受け取るクエリに応答する。例えば、特定の操作がセキュリティポリシーの要件を満たしている場合、セキュリティ評価モジュールは操作開始モジュール１３０に対し、セキュリティポリシーの要件を満たしていることを通知する。他方、特定の操作がセキュリティポリシーの要件を満たしていない場合、セキュリティ評価モジュールは、操作開始モジュールに対し、特定の操作がセキュリティポリシーの要件を満たしていない旨の応答をする。

幾つかの実施形態において、セキュリティ評価モジュール１１０及びルールデータベース１２０は、オペレーティングシステム１００のセキュリティ評価を遂行するセキュリティフレームワーク１８０の一部として実装される。オペレーティングシステムの他のコンポーネントは、セキュリティフレームワーク１８０によって提供されるセキュリティＡＰＩ１９０を使用して操作のセキュリティ評価を遂行できる。図１の例において、操作開始モジュール１３０は、ＡＰＩ１９０を介してセキュリティ評価モジュール１１０と通信するオペレーティングシステム１００のコンポーネントである。

一旦操作開始モジュール１３０がクエリに対する応答をセキュリティ評価モジュール１１０から受け取ると、操作開始モジュール１３０は、特定の操作の続行を許可するか又は許可しないようにする（例えば、禁止する）ことによって、セキュリティポリシーを施行する。操作の続行が許可された場合、操作開始モジュール１３０は、操作要求モジュール１４０によって要求された操作の実行をインストールモジュール１７０、実行モジュール１７２、又はコンテンツを開くモジュール１７４に開始させる。操作が許可されない場合、操作開始モジュール１３０はその旨を操作要求モジュール１４０に通知する。通知を受けた操作要求モジュール１４０は、今度はユーザに通知を行って、要求された操作を終了する。下の図２は、操作開始モジュール１３０によって実行されるプロセスの例を記述したものである。

データオブジェクト内に埋め込まれた署名は、その受領者によって認証されたときに、データオブジェクトが特定のソースに由来するものであることを検証する。幾つかの実施形態において、セキュリティ評価モジュール１１０は、データオブジェクト内の署名を認証し、データオブジェクトのソースを確認する。セキュリティ評価モジュールによって認証され得る署名を生成できない（例えば、欠陥があるか又は不完全な）データオブジェクトは、信頼できないソースに由来する可能性が高い。そのような状態において、セキュリティ評価モジュール１１０は、オペレーティングシステムのセキュリティポリシーの下で、データオブジェクトが実行されることのないよう又は開かれないように、操作開始モジュール１３０に対し通知する。（幾つかの実施形態においては、認証ができなかった署名付きの文書又はプログラムは、続行を許可されることはない。）その逆に、セキュリティ評価モジュール１１０がデータオブジェクトの署名を認証できる場合、セキュリティ評価モジュールは、セキュリティポリシーの下で他の要件も満たされる（例えば、データオブジェクトのソースが信頼できる場合など）とすれば、操作開始モジュールに対し、要求された操作を続行しても問題のない旨を通知し得る。

幾つかの実施形態によって実装されるセキュリティポリシーは、種々のデータオブジェクトを異なった様式で調べる。一部の種類のデータオブジェクトに関しては、オペレーティングシステムのセキュリティポリシーが、署名の認証のほかにも、満たされる必要のある更なる要件を有し得る。例えば、セキュリティポリシーが、一連の証明書に基づいて署名を認証することを義務付けている場合もあれば、又は（コード署名の認証が成功したとしても）データオブジェクトのソースが特定のベンダーであることを必須としている場合もある。幾つかの実施形態においては、セキュリティポリシーにユーザが変更を加えることができる。例えば、信頼済みコンピュータ管理者は、セキュリティ評価モジュールが任意の署名の検証又は認証を行うことなしに特定のデータオブジェクトを受け入れるようにオペレーティングシステムのセキュリティポリシーを変更することもできる。幾つかの実施形態において、セキュリティ評価モジュール１１０は、操作開始モジュール１３０によって提示される任意のデータオブジェクトに対して任意のセキュリティポリシーを実装するように、恣意的にプログラミングされ得る。

幾つかの実施形態において、データオブジェクトの評価に用いられるセキュリティポリシーは、データオブジェクトがセキュリティポリシーに適合しているかどうか判定するためにセキュリティ評価モジュール１１０が実行する命令のセットとして実装される。図１のオペレーティングシステムの例において、セキュリティポリシーを実装する命令セットはルールデータベース１２０内に格納されている。セキュリティ評価モジュール１１０は、ルールデータベース１２０から命令セットを取得し、取り出された命令を用いて、（ｉ）データオブジェクトの分析し（例えば、データオブジェクトのソースが受け入れ可能なものかどうか判定するために）、及び（ｉｉ）分析に基づいて操作開始モジュール１３０に対し応答を発行する。ルールデータベース内に格納された１つ以上のルールからなる各セットは、時として「コード要件」と呼ばれる。この呼称は、データオブジェクト（例えば、アプリケーション１５０などの実行可能プログラムコード、又はデータファイル１６０）がオペレーティングシステムのセキュリティポリシーに適合する上で何が必要かをこのルールセットが指定していることに由来する。下の図３は、セキュリティ評価モジュール１１０によって実行されるプロセスの例を記述したものである。コード要件については、後ほど図９及び１３を参照しながら、更に詳述する。

ルールデータベース１２０は、オペレーティングシステム１００のセキュリティポリシーを実装するための命令のセットが格納されるデータベースである。セキュリティ評価モジュール１１０は、ルールデータベース１２０から命令のセットを取得し、それによって、操作開始モジュール１３０によって為されたセキュリティのクエリに応答する。ルールデータベースについては、後ほど図７〜図１７を参照しながら、更に詳述する。

図２は、幾つかの実施形態のオペレーティングシステムが要求された操作の処理及び承認に用いるプロセス２００を概念的に示したものである。具体的には、プロセスは要求された操作に関するセキュリティ評価を要求し、承認された操作を開始する。幾つかの実施形態において、プロセス２００は、オペレーティングシステム１００内のモジュール（例えば、図１の操作開始モジュール１３０）によって実行される。

（２１０において）（例えば、操作要求モジュール１４０から）操作要求を取得したときに、プロセス２００は開始される。幾つかの実施形態において、この要求は、文書を開くための又はアプリケーションを実行するためのユーザコマンドである。また、現在実行しているアプリケーション、又はオペレーティングシステム内で特定の操作を実行するためのシステムプロセスによって、要求が促されることもある。

次いで、（２２０において）このプロセスによって要求がセキュリティ評価モジュールに渡される。図１の例においては、セキュリティ評価モジュールがセキュリティポリシーの下で要求のセキュリティを評価する際に必要とするデータオブジェクト（例えば、アプリケーション１５０又はデータファイル１６０）もまた、要求に含まれる。例えば、文書を開くためにユーザコマンドによって開始された操作要求では、場合によっては、文書を開くにはアプリケーションの呼び出しが必要になることから、複数のデータオブジェクトをセキュリティ評価モジュールに渡す必要のある場合があり、それ故、セキュリティ評価モジュールに渡された要求には、文書及びアプリケーションの両方のファイルハンドルが含まれることになる。

次いで、プロセスは（２３０において）セキュリティ評価モジュール（例えば、１１０）からの応答を受け取り、（２４０において）要求された操作を承認するかどうかを判定する。幾つかの実施形態において、セキュリティ評価モジュールからの応答は（例えば、操作開始モジュール１３０への通知によって）要求がオペレーティングシステムのセキュリティポリシーを通過したかどうかを示すものである。幾つかの実施形態において、要求がセキュリティ評価を通過した（例えば、認証済み署名を有し、かつ許容され得るソースに由来する）ことが応答により示された場合、プロセス２００は、要求された操作を続行させる。幾つかの実施形態において、応答による指示がそれ以外の場合（例えば、セキュリティ評価モジュールが署名を認証できない場合、又はデータオブジェクトが許容され得るソースに由来するものでない場合）、プロセス２００は要求された操作を終了するか又は保留にする。

要求が承認されると、（２５０において）プロセス２００は、要求を受け取って承認済み操作の実行ができる操作ハンドラに要求を渡す。図１に示すように、幾つかの操作ハンドラは、要求を受け取って操作を実行できる。インストールモジュール１７０、実行モジュール１７２及びコンテンツを開くモジュール１７４などがこれに含まれる。操作ハンドラに要求が渡された後に、プロセス２００が終了する。

他方、プロセス２００は要求を不承認する場合、（２６０において）操作要求モジュール（例えば、図１の１４０）に既定のメッセージを返し、続いて、ユーザ（不図示）に対し通知を行う。更にまた、要求が承認されない場合、プロセス２００は、その要求を操作ハンドラに渡さない。故に、要求が承認されない場合、操作ハンドラ（例えば１７０、１７２及び１７４）はいずれも、要求された操作を実行しない。操作要求モジュールに既定のメッセージが返された後、プロセス２００が終了する。

幾つかの実施形態では、プロセス２００のバリエーションが実行される。例えば、プロセス２００の具体的な操作は、図と共に記載される厳密な順序で実行されるとは限らない。具体的な操作は、１つの連続した一連の操作で実行されなくてもよく、様々な具体的な操作が、異なる実施形態で実行されてもよい。

図３は、オペレーティングシステムのセキュリティポリシーに基づいて要求された操作のセキュリティ評価を遂行するためのプロセス３００の例を概念的に示したものである。具体的には、プロセス３００はルールデータベースを使用して、要求された操作に関するセキュリティ評価をプロセスが実行することを可能にするルールに対して要求をマッチさせる。幾つかの実施形態において、プロセス３００はオペレーティングシステム内のモジュール、例えば、図１のセキュリティ評価モジュール１１０によって実行される。

（３１０において）操作開始モジュールから要求が受け取られると、プロセス３００が開始される。要求された特定の操作に関するセキュリティ評価が必要とされることが、要求により示される。

次に、（３２０において）プロセスはルールデータベースに対しクエリを実行し、マッチするものを見つける。プロセス３００は、要求とマッチするか又は要求に適用可能なルールのエントリがルールデータベース内にあるかどうかを調べる。要求とマッチしないルールは、要求のセキュリティ評価には使用できない。例えば、特定の名前の付いたアプリケーションをチェック対象とするルールは、別の名前のアプリケーションのチェックには使用できない。以下に更に説明するように、ルールデータベース内の複数のエントリが同時に要求とマッチする場合もあるが、その際、適用されるルールは最高優先度のルールだけに限られる。

続いて、（３３０において）マッチするルール又は適用可能なルールがルールデータベース内に見つかったかどうかが、プロセスによって判定される。プロセス３００が少なくとも１つのマッチするルールを見つけた場合、プロセスは３４０に進む。それ以外の場合、プロセスは３６０に進む。

３６０において、プロセスは、要求に対して適用可能なルール又は命令が存在しないことを示す既定の応答を、操作開始モジュールに返す。幾つかの実施形態において、既定のセキュリティポリシーでは、マッチするルールがルールデータベース内に無い操作に対しては要求が承認されない。幾つかの実施形態において、既定のセキュリティポリシーでは、ルールデータベースによって特に禁止されていない要求が許可される。幾つかの実施形態において、既定ポリシーでは、オペレーティングシステムがユーザに通知を行う必要がある。既定の応答が返された後、プロセス３００が終了する。

３４０において、プロセスは要求に関するセキュリティ評価を行う。幾つかの実施形態において、プロセスは、マッチするルール又は適用可能な命令セットを要求に関連付けられているデータオブジェクト（例えば、アプリケーション１５０及び／又はデータファイル１６０）に適用することによって、セキュリティ評価を行う。幾つかの実施形態では、マッチするルールセットが、セキュリティ評価モジュールにおいて実行可能プログラムとして実行される。幾つかの実施形態において、マッチするルールセットは、セキュリティ評価モジュールにデータオブジェクトのソース、データオブジェクトのＩＤ、及びデータオブジェクトの種類などの変数に基づいてセキュリティ評価を行わせる。

一旦セキュリティ評価が行われると、（３５０において）プロセスは、要求された操作の続行を許可すべきかどうかを判定するためにセキュリティ評価を操作開始モジュールに返す。セキュリティ評価を操作開始モジュールに返した後、プロセス３００が終了する。

幾つかの実施形態は、プロセス３００のバリエーションを実行する。例えば、プロセス３００の特定の操作が、図と共に記載される厳密な順序で実行されるとは限らない。具体的な操作は、１つの連続した一連の操作で実行されなくてもよく、様々な具体的な操作が、異なる実施形態で実行されてもよい。

図４〜６は、セキュリティ評価モジュール及びルールデータベースを使用してセキュリティ評価を実行するときのオペレーティングシステム１００内部のデータフローを示したものである。図１におけるように、図４〜６のオペレーティングシステム１００は、セキュリティ評価モジュール１１０と、ルールデータベース１２０と、操作開始モジュール１３０と、操作要求モジュール１４０と、インストールモジュール１７０と、実行モジュール１７２と、コンテンツを開くモジュール１７４と、を含んで構成される。

図４は、要求された操作がアプリケーションのインストールを目的としたものである場合のオペレーティングシステム１００内部のデータフローを示す。操作要求モジュール１４０が操作開始モジュール１３０に対しアプリケーションＸをインストールするよう要求すると（操作‘１’）、操作要求モジュール１４０において操作データフローが開始する。この要求は、幾つかの実施形態において、アプリケーションＸをインストールするためのユーザコマンドに基づくものである。ユーザコマンドは、ユーザインターフェースを介して受け取られ得る。

続いて、操作開始モジュール１３０は、セキュリティ評価モジュール１１０に対し、オペレーティングシステムのセキュリティポリシーの下でアプリケーションＸのインストールに対するセキュリティを評価するよう要求を行う（操作‘２’）。幾つかの実施形態において、セキュリティ評価モジュール１１０に対するこの要求は、アプリケーションＸをインストールする上で必要なデータオブジェクト（インストールファイル及びパッケージなど）へのハンドルを含む。

セキュリティ評価モジュール１１０は要求を受け取ると即座に、ルールデータベース１２０に対しクエリを実行し（操作‘３’）、セキュリティポリシーの下でインストール要求とマッチするルール又は命令を探す。ルールデータベースは、そのデータベース内でクエリとマッチするルール又は命令をセキュリティ評価モジュール１１０に提供する（操作‘４’）。セキュリティ評価モジュール１１０とルールデータベース１２０との間のこのクエリプロセスは、マッチするルールがルールデータベース内に見つかるまで、又はルールデータベース内に適用可能なルールが存在しないことが判定されるまで続行される。

一旦マッチするルールが見つかると、セキュリティ評価モジュール１１０は、アプリケーションＸのインストールに関連するデータオブジェクトにマッチするルールを適用することによって、セキュリティ評価を実行する。幾つかの実施形態において、ルールは、データオブジェクトの処理、及びデータオブジェクトがオペレーティングシステムのセキュリティポリシーに適合しているどうかの判定を行うためのプログラム命令という形をとる。幾つかの実施形態において、データオブジェクトを処理することは、データオブジェクトの内部でアプリケーションＸのインストールに関連する署名を検証することを含む。幾つかの実施形態において、セキュリティポリシーに対する適合性は、署名の認証が成功したかどうか、及び署名が信頼済みソースに由来するものかどうかに基づいて判定される。続いて、セキュリティ評価が操作開始モジュール１３０に返される（操作‘５’）。図４に示す例において、セキュリティ評価モジュールは、アプリケーションＸをインストールしても問題のないことを示している。アプリケーションＸのインストールに関連するデータオブジェクトが、ルールデータベース内に格納されているセキュリティポリシーに適合していることが判明したため、これがセキュリティ評価である。

アプリケーションＸをインストールしても問題がないというセキュリティ評価を受け取った後、操作開始モジュール１３０は、インストールモジュール１７０に対し、インストーラを起動してコンピュータにアプリケーションＸをインストールするように指示する。実行モジュール１７２及びコンテンツを開くモジュール１７４の周囲の点線は、それらの２つのモジュールがこの操作に関与していないことを示す。

図５は、インストール操作のデータフローを図示するのではなく、要求された操作がアプリケーションの実行（例えば、起動又は呼び出し）を目的としている場合のオペレーティングシステム１００内部のデータフローを示していることを除けば、図５は図４とほぼ同じである。操作要求モジュール１４０が操作開始モジュール１３０に対し、アプリケーションＸを実行するよう要求すると（操作‘１’）、操作要求モジュール１４０において操作データフローが開始する。この要求は、幾つかの実施形態において、アプリケーションＸを実行するためのユーザコマンドである。ユーザコマンドは、ユーザインターフェースを介して受け取られ得る。

続いて、操作開始モジュール１３０は、セキュリティ評価モジュールに対し、オペレーティングシステムのセキュリティポリシーの下でアプリケーションＸの実行に関するセキュリティを評価するよう要求を行う（操作‘２’）。幾つかの実施形態において、この要求は、アプリケーションＸの実行可能マシンコードなどの、アプリケーションＸの実行に必要なデータオブジェクトへのハンドルを含む。

セキュリティ評価モジュール１１０は、要求を受け取ると即座に、ルールデータベース１２０に対してクエリを実行し（操作‘３’）、セキュリティポリシーの下でアプリケーションを実行するための要求とマッチするルール又は命令を探す。ルールデータベースは、そのデータベース内のクエリの条件を満たすルール又は命令をセキュリティ評価モジュール１１０に提供する（操作‘４’）。セキュリティ評価モジュール１１０とルールデータベース１２０との間のこのクエリプロセスは、マッチするルールがルールデータベース内に見つかるまで、又はルールデータベース内に適用可能なルールが存在しないと判定されるまで続行される。

一旦マッチするルールが見つかると、セキュリティ評価モジュール１１０は、アプリケーションＸを実行することに関連するデータオブジェクトにマッチするルールを適用することによって、セキュリティ評価を実行する。幾つかの実施形態において、ルールは、データオブジェクトの処理、及びデータオブジェクトがオペレーティングシステムのセキュリティポリシーに適合しているどうかの判定を行うためのプログラム命令という形をとる。幾つかの実施形態において、データオブジェクトを処理することは、データオブジェクトの内部でアプリケーションＸを実行することに関連する署名を検証することを含む。幾つかの実施形態において、セキュリティポリシーに対する適合性は、署名の認証が成功したかどうか、及び署名が信頼済みソースに由来するものかどうかに基づいて判定される。続いて、セキュリティ評価が操作開始モジュール１３０に返される（操作‘５’）。図５に示す例において、セキュリティ評価モジュールは、アプリケーションＸを実行しても問題のないことを示している。アプリケーションＸを実行することに関連するデータオブジェクトが、ルールデータベース内に格納されているセキュリティポリシーに適合していることが判明したため、これがセキュリティ評価である。

アプリケーションＸを実行しても問題がないというセキュリティ評価を受け取った後、操作開始モジュール１３０は、実行モジュール１７２に対し、アプリケーションＸを起動するように指示する。インストールモジュール１７０及びコンテンツを開くモジュール１７４の周囲の点線は、それらの２つのモジュールがこの操作に関与していないことを示す。

図６のデータフローが、文書を開く要求に基づいていることを除けば、図６は先行する２つの図とほぼ同じである。操作要求モジュール１４０が操作開始モジュール１３０に対し、文書データファイルＸを開くことを要求すると（操作‘１’）、操作要求モジュール１４０においてデータフローが開始する。この要求は、幾つかの実施形態において、データファイルＸを開くためのユーザコマンドである。ユーザコマンドは、ユーザインターフェースを介して受け取られ得る。

続いて、操作開始モジュール１３０は、セキュリティ評価モジュールに対し、オペレーティングシステムのセキュリティポリシーの下でデータファイルＸを開くことに対するセキュリティを評価するよう要求を行う（操作‘２’）。幾つかの実施形態において、この要求はデータファイルＸへのハンドルを含む。データファイルＸがアプリケーションＹで開くべき文書である場合、幾つかの実施形態において、この要求はアプリケーションＹの実行可能バイナリファイルへのハンドルも含む。この実例においては、文書Ｘ及びアプリケーションＹの両方が、文書Ｘを開く上で必要なデータオブジェクトであると見なされる。したがって、これらのデータオブジェクトの両方に対してセキュリティ評価が実行される。一方、幾つかの実施形態において、データファイルＸを開く際に必要なアプリケーションは、既に実行されている（故に、図５の例におけるように、セキュリティ評価を既に通過している）。それ故、要求の一部としてセキュリティ評価モジュールに渡されるのは、データファイルＸ用のハンドルだけである。

セキュリティ評価モジュール１１０は要求を受け取ると即座に、ルールデータベース１２０に対しクエリを実行し（操作‘３’）、セキュリティポリシーの下で文書を開く要求とマッチするルール又は命令を探す。ルールデータベースは、そのデータベース内のルール又は命令をセキュリティ評価モジュール１１０に提供する（操作‘４’）。セキュリティ評価モジュール１１０とルールデータベース１２０との間のこのクエリプロセスは、マッチするルールがルールデータベース内に見つかるまで、又はルールデータベース内に適用可能なルールが存在しないと判定されるまで続行される。

一旦マッチするルールが見つかると、セキュリティ評価モジュール１１０は、データファイルＸを開くことに関連するデータオブジェクト（例えば、アプリケーションＹ）にマッチするルールを適用することによって、セキュリティ評価を実行する。幾つかの実施形態において、ルールは、データオブジェクトの処理、及びデータオブジェクトがオペレーティングシステムのセキュリティポリシーに適合しているどうかの判定を行うためのプログラム命令という形をとる。幾つかの実施形態において、データオブジェクトを処理することは、データオブジェクトの内部でデータファイルＸを開くことに関連する署名を検証することを含む。幾つかの実施形態においては、署名の認証が成功したかどうか、及び署名が信頼済みソースに由来するものかどうかに基づいて判定が為される。続いて、セキュリティ評価が操作開始モジュール１３０に返される（操作‘５’）。図６に示す例において、セキュリティ評価モジュールは、データファイルＸを開いても問題のないことを示している。データファイルＸを開くことに関連するデータオブジェクト（例えば、データファイルＸ自体、及びアプリケーションＹ）が、ルールデータベース内に格納されているセキュリティポリシーに適合していることが判明したため、これがセキュリティ評価である。

データファイルＸを開いても問題がないというセキュリティ評価を受け取った後、操作開始モジュール１３０は、コンテンツを開くモジュール１７４に対し、アプリケーションＸを起動するように指示する。実行モジュール１７２及びインストールモジュール１７０の周囲の点線は、それらの２つのモジュールがこの操作に関与していないことを示す。幾つかの実施形態において、文書を開くためにコンピュータ内で現在実行されていないアプリケーションを実行する必要がある場合、操作開始モジュールはまた実行モジュール１７２の起動も行う。

ＩＩ．ルールデータベース
上記の例において、要求された操作に関連付けられているデータオブジェクトは、オペレーティングシステムのセキュリティポリシーに従って評価される。これらのセキュリティポリシーは、ルールデータベース内に格納された様々なルール又は命令で具体化される。それ故、「オペレーティングシステムのセキュリティポリシー」は、オペレーティングシステム内で為される操作を制御するプログラミング可能なルールのセットであるが、オペレーティングシステム自体のプログラムの一部ではない。第ＩＩ−Ｃ節で説明するように、これらの「オペレーティングシステムのセキュリティポリシー」は、コンピュータシステムのユーザ又はベンダーが変更を施すことができる。

幾つかの実施形態において、ルールデータベースは、ルールデータベースに対するクエリの実行を効率化するための様々なテーブルを具備する。そのような２つのテーブル（即ち、権限テーブル及びキャッシュテーブル）については後述する。

Ａ．権限テーブル
幾つかの実施形態において、ルールデータベースは権限テーブルを具備する。そのような幾つかの実施形態においては、セキュリティ評価モジュールがオペレーティングシステム内で特定の操作の実行を許可するかどうかを判定するために取り出すルールが、権限テーブルに含まれる。権限テーブル内のルールには、データオブジェクト（例えば、プログラムコード、又は開く対象の文書）がコンピュータのセキュリティポリシーに適合するために何が必要かが指定される。それ故、これらのルールのうちの１つ以上のセットはそれぞれ、幾つかの実施形態において「コード要件」と呼ばれる。

コード要件には、主体の署名に使用される証明書に対して任意の条件（証明書の中のベンダーＩＤ及び／又は公開鍵が特定の信頼済みソースに帰属することを必要とするなど）を表明できる。また、コード要件には、これらのプログラムの不可欠な部分である構成辞書のエントリなどの、他のものが必要とされる場合もある。例えば、コード要件に「アドレス帳の使用を許可するエンタイトルメントが必要」の旨を記述してもよい（エンタイトルメントとは、プログラム内の内包物として何らかのものによって指定された構成辞書の１つである）。これは、その署名とは全く無関係である。

オペレーティングシステムのセキュリティポリシーを判定するためのルール又は命令を格納する権限テーブル７００を、図７に概念的に示す。権限テーブル７００にはエントリ又はレコードのセットが含まれており、各エントリ又はレコードには、コード要件を指定する１つ以上のルール又は命令のセットが格納されている。特定のセキュリティポリシーは、権限テーブル内の１つ以上のエントリで表すことができる。

図示するように、記憶装置７１０には権限テーブル７００が格納されており、この権限テーブル７００にはレコード７２１、７２２及び７２３をはじめとする幾つかのエントリ又はレコードが含まれている。レコードは、ポリシー７３１、７３２及び７３３をはじめとする幾つかのセキュリティポリシーを表す。各レコード又はエントリはまた、フィールドのセット７４１〜７４４も含んで構成されている。フィールド７４１〜７４３は「ルール１」〜「ルールｎ」とラベル付けされている。フィールド７４４は「アクション」とラベル付けされている。

レコードの各フィールドは、オペレーティングシステムのセキュリティ評価モジュールに対し、論理演算又は算術演算のセットを実行して論理演算又は算術演算のセットに従って決定を下すように指示する、ルール又は命令のセットである。例えば、レコード７２１のフィールド７４１内の‘Ｘ’はセキュリティ評価がアプリケーションに関するものかどうかを確認する演算セットであってよく、レコード７２１のフィールド７４２内の‘Ｙ’は証明書の失効日を確認する演算セットであってもよく、レコード７２２のフィールド７４２の‘Ｚ’はアプリケーションが信頼済みベンダー又はソースに由来するものであるかどうかを検証するルールであってもよく、他方、フィールド７４１内の‘Ｗ’は開かれる対象のファイルがインターネットからダウンロードされたファイルであるかどうかをチェックするルールであってもよい。必ずしもエントリの全てのフィールドが入力されている必要はない。例えば、エントリ７２３には、１つのルールフィールド（７４１）だけが入力されている。レコード７２３用のそのフィールド内の命令は、開くように要求された文書をインターネットからダウンロードするかどうかのチェックであり得る。

或るレコードの別々のフィールド内の命令のセットはそれぞれ共同で１つの判定を行う。この１つの判定を用いることによって、「アクション」フィールド７４４に記述されているアクションを行うべきかどうかを決定する。例えば、レコード７２２のアクションフィールド７４４内に「承認」と記載されているため、評価対象のデータオブジェクトが、Ｘ．５０９規格の下で検証された証明書を有し、かつ信頼済みベンダーに由来するアプリケーションであるときには、特定のアプリケーションを起動する要求がセキュリティ評価モジュールによって承認される。他方、エントリ７２３が「非承認」であるため、特定のコンテンツアイテムがインターネットからダウンロードされているときには、セキュリティ評価モジュールは、その特定のコンテンツアイテムを開く要求を不承認する。

セキュリティポリシーは、そのような命令又は要件の集まりで構成される。図７の例において、セキュリティポリシーＡ７３１はレコード７２１内のルール又は命令で構成され、セキュリティポリシーＢ７３２はレコード７２２内のルール又は命令で構成され、セキュリティポリシーＣ７３３はレコード７２３内のルール又は命令で構成される。幾つかの実施形態において、セキュリティポリシーは、権限テーブル内の２つ以上のレコードにまたがるルールの集まりである。そのような権限テーブルについては、後ほど図１０を参照しながら更に説明する。

幾つかの実施形態において、ルールによっては、マッチング用のものもあれば検証用のものもある。マッチング用のルールは、特定のエントリがセキュリティ評価の要求に適用できるかどうかを判定するものである。検証用のルールは、要求がルールテーブルの特定のエントリ又はレコードによって具体化されるセキュリティポリシーに適合しているかどうかを判定するものである。例えば、特定のベンダーからのデータオブジェクトの種類を却下するルールは検証用のルールであり、それに対して、ルールの適用範囲をゲームアプリケーションだけに制限するルールはマッチング用のルールである。

幾つかの実施形態は、ルールフィールド及びアクション用のフィールドに加えて、その他のフィールドも含む。図８は、権限テーブル８００を概念的に示したものである。権限テーブル８００は、図７に図示されているルールフィールド及びアクションフィールドだけでなく追加のフィールドも含んでいることを除けば、権限テーブル７００とほぼ同じである。権限テーブル８００はまた幾つかのエントリ（８２１〜８２３）を有し、各エントリは幾つかのフィールド（８４０〜８４４）を有する。これらのフィールドには、ルールフィールド（８４１〜８４３）及びアクションフィールド（８４４）が包含される。一方、権限テーブル７００とは異なり、権限テーブル８００における各エントリはまた優先度フィールド８４０も具備する。

幾つかの実施形態の優先度フィールド８４０は、要求とマッチするルールを探すために、権限テーブル内のどのエントリを最初に調べるかを決定するものである。優先度フィールド内で、より高い優先度値のエントリを調べてから、より低い優先度値のエントリを調べる。図８に示すように、優先度フィールド８４０において、レコード８２２は優先度値が１．７５であり、一方、レコード８２３は優先度値１．２５である。したがって、レコード８２２がレコード８２３より前に検索され、一方、レコード８２１（優先度値２．７０を有する）がレコード８２２及び８２３の両方より前に検索される。エントリの優先度は、他の方法で（例えば、整数を使用するか、リンクリストにおいて最高優先度のエントリから最低優先度のエントリまでを配列するか、又はエントリの優先度を基準にソートすることによって）表記してもよい。

与えられたいずれかのセキュリティ評価要求について、権限テーブル内の複数のエントリが要求とマッチすることがあり得る。一方、幾つかの実施形態において、マッチするエントリが見つかると、セキュリティ評価モジュールは権限テーブルの検索を中断する。例えば、マッチするものを複数有し得る検索において、セキュリティ評価モジュールは、最初のマッチするエントリ（即ち、最高優先度のマッチするエントリ）のみを使用する。したがって、優先度フィールドを使用すれば、マッチするエントリが複数存在する可能性が低くなり、マッチするエントリが１つだけセキュリティ評価に用いられることが保証される。

図７及び８の例において、権限テーブル内のエントリは、各々論理演算又は算術演算のセットを実行するための命令セットを格納する幾つかのルールフィールドを含む、幾つかのフィールドを備える。一方、一部の実施形態は、全てのルールフィールドの命令のセットを単一のルールとして表し、権限テーブル内に単一のルールフィールドのみを有する。権限テーブルのレコード内の単一のルールフィールドは、特定のセキュリティポリシーの下でセキュリティ評価を行うために必要とされる全ての命令を含む。

図９は、各レコード又はエントリ内に１つのルールフィールドのみを含む、他の幾つかの実施形態の権限テーブル９００を概念的に図示している。権限テーブル９００は、権限テーブル８００と同様に、優先度フィールド９４１、アクションフィールド９４３、及び幾つかのエントリ（９２１〜９２３）を含む。一方、幾つかのルールフィールドを備える権限テーブル８００とは異なり、権限テーブル９００は１つだけルールフィールド９４２を備える。

各レコード又はエントリに対しルールフィールド９４２を含むコード要件は、要求に対しセキュリティ評価を実行する上で必要なマッチング用及び検証用の両方の命令を含む全ての命令を含む。幾つかの実施形態において、上述したように、コード要件は、１つ以上の連結されたルールのセットであり得る。そのような幾つかの実施形態においては、データオブジェクトのソースを検証するために、そのコード要件が要求されたデータオブジェクトに適用される。例えば、エントリ９２１用ルールフィールド９４２を含むコード要件における命令セットは、（１）セキュリティ評価の要求がアプリケーションに対するものかどうか、（２）アプリケーションが信頼済みベンダー又はソースに由来するかどうか、及び（３）証明書内のソースを識別する情報（例えば、ベンダーＩＤ、公開鍵など）が実際に信頼済みベンダー又はソースに帰属するかどうかをそれぞれ判定できる。３つの判定のそれぞれがその対応するルールの条件を満たす場合に限り、アクションフィールド９４３内のアクションが適用される。他方、３つの判定のうちの１つ以上がその対応するルールの条件を満たさない場合、レコードのアクションフィールドは適用されない。故に、アクションフィールドによって規定されたアクションは、レコード用の単一ルールに基づくもの（例えば、要求されたアクションの承認又は不承認）であり、セキュリティ評価モジュールに伝達される。

権限テーブルは、図７〜図１０に示すものとは異なるフォーマットを有し得る。例えば、権限テーブルエントリは、幾つかの実施形態において、無効フィールドに或る値が含まれている場合にエントリをスキップすることができ、セキュリティ評価モジュールが検索中にエントリを考慮しない「無効化」と呼ばれるフィールドを含み得る。

上記で図７を参照しながら説明したように、オペレーティングシステムのセキュリティポリシーは、ルールデータベース内のルール及び命令で表される。幾つかの実施形態において、権限テーブル内の各エントリは、１つの特定のセキュリティポリシー（例えば、特定のベンダーからの有効な署名を有するアプリケーションのみを許可すること）を表すのに十分である。幾つかの実施形態において、セキュリティポリシーは、権限テーブル内の２つ以上のエントリで表すことができる。

図１０は、複数のエントリを使用して単一のセキュリティポリシーを表す権限テーブル１０００を示したものである。図１０については、図１１及び図１２を参照しながら説明する。権限テーブル１０００は、権限テーブル９００と同様に、幾つかのエントリ（１０２１〜１０２７）を有し、各エントリは３つのフィールド（優先度フィールド１０４１、ルールフィールド１０４２、及びアクションフィールド１０４３）を有する。一方、図１０にはまた、権限テーブルの３つのエントリ（エントリ１０２１、１０２４及び１０２６）で実装されるセキュリティポリシー１０３１の例（「セキュリティポリシー１」）も示してある。セキュリティポリシーの３つのエントリはそれぞれ優先度が異なり（Ｐ１、Ｐ５及びＰ８）、マッチング優先度が最高のエントリ１つだけが、セキュリティ評価に用いられる。この例において、Ｐ１は優先度が最も高く、Ｐ５は優先度がＰ１よりも低く、かつＰ８は優先度が最も低い。

図１１は、図１０のセキュリティポリシー１０３１の例を表す一連のベン図を示している。この線図は、３つの権限テーブルエントリ（Ｐ１、Ｐ５及びＰ８）間の論理的な関係を示している。この線図にはまた、優先度を用いたセキュリティポリシー１０３１の例の構造が、図示されている。

図１１には、セキュリティポリシー１０３１、２次元のベン図１１２０、及び３次元線図１１３０も含まれている。セキュリティポリシー１０３１には、優先度Ｐ１用のレコード（又は命令セット）、優先度Ｐ５用のレコード、及び優先度Ｐ８用のレコードが含まれている。優先度Ｐ１のレコード（即ち、１０２１）内のルールは「有効な証明書を有する全てのＸ社製ワードプロセッシングアプリ」を許可する。優先度Ｐ５のレコード（即ち、１０２４）内のルールは「一切のＸ社製アプリを許可しない」。優先度Ｐ８のレコード（即ち、１０２６）内のルールは、全てのアプリケーションを開くことを許可する。幾つかの実施形態において、証明書はその署名が認証された場合、「有効」と見なされる。

２Ｄベン図１１２０は、３つの楕円形１１２１〜１１２３を含む。３Ｄ線図１１３０は、同じ３つの楕円形を３次元の様式で示したものである。楕円形１１２１は優先度Ｐ１のルールを表し、楕円形１１２２は優先度Ｐ５のルールを表し、楕円形１１２３は優先度Ｐ８のルールを表す。

このようにして、２Ｄベン図１１２０は、３つの権限テーブルエントリ同士の間の論理的な関係を示している。ベン図１１２０の内部において、楕円形１１２３は楕円形１１２２及び１１２１を包含し、楕円形１１２２は楕円形１１２１を包含する。これは、３つのレコード内のルール同士の間の論理的な関係に対応している。Ｐ１ルール「有効な証明書を有する全てのＸ社製ワードプロセッシングアプリ」の適用範囲はＰ５ルール「Ｘ社製アプリ」の適用範囲のサブセットであり、Ｐ５ルールの適用範囲はＰ８ルール「全てのアプリ」の適用範囲のサブセットである。

３Ｄ線図は、セキュリティ評価を行う際にセキュリティポリシー１０３１内のどのルールを適用すべきかを、権限テーブル内の優先度フィールドを使用することによって決定する仕組みを示したものである。図示するように、楕円形１１２１は最上位にあり、セキュリティポリシー１０３１における最高優先度のルール（Ｐ１）に対応している。楕円形１１２２は２番目に上位にあり、セキュリティポリシー１０３１において優先度が２番目に高いルール（Ｐ５）に対応している。楕円形１１２３は最下位にあり、セキュリティポリシー１０３１における最低優先度のルール（Ｐ８）に対応している。より高い優先度の楕円形とより低い優先度の楕円形が交差すると、より高い優先度の楕円形がより低い優先度の楕円形に影を投げかけるのと同じように、より高い優先度のルールとより低い優先度のルールが交差する場合は、より高い優先度のルールがより低い優先度のルールに優先する。より高い優先度のルールの適用範囲が有効になって、より低い優先度のルールの適用範囲に穴を開けている。

このようにして、セキュリティ評価を遂行する際、権限テーブル１０００内の複数のエントリを使用して、論理的な矛盾なしにセキュリティポリシー１０３１を作成できる。権限テーブル内の様々なエントリを同じ要求に適用する際にどのルールを使用すべきかという問題は、優先度フィールドを使用して解決される。

図１２は、別のセキュリティポリシー１２３１の例を表す一連のベン図を示したものである。この線図は、３つの権限テーブルエントリ（Ｐ１、Ｐ５及びＰ８）間の論理的な関係を示している。この線図にはまた、優先度を用いたセキュリティポリシー１２３１の例の構造を、図示してある。セキュリティポリシー１２３１における権限テーブルエントリは、セキュリティポリシー１０３１における権限テーブルエントリとは異なり、必ずしも相互にサブセットになるとは限らない。

図１２は、セキュリティポリシー１２３１、２次元ベン図１２２０及び３次元線図１２３０を含む。セキュリティポリシー１２３１は、優先度Ｐ１用レコード（即ち、命令のセット）、優先度Ｐ５用レコード、及び優先度Ｐ８用レコードを含む。優先度Ｐ１のレコード内のルールは「有効な証明書を有する全てのワードプロセッシングアプリ」を許可する。優先度Ｐ５のレコード内のルールは「一切のＸ社製品を許可しない」。優先度Ｐ８のレコード内のルールは、有効な証明書を有する全てのアプリケーションを開くことを許可する。

ベン図１２２０は、３つの楕円形１２２１〜１２２３を含む。３Ｄ線図１２３０は、３つの同じ楕円形を３次元の様式で示したものである。楕円形１２２１は優先度Ｐ１のルールを表し、楕円形１２２２は優先度Ｐ５のルールを表し、楕円形１２２３は優先度Ｐ８のルールを表す。

このようにして、２Ｄベン図は３つの権限テーブルエントリ同士の間の論理的な関係を示している。ベン図１２２０内において、楕円形１２２３は楕円形１２２１を包含している一方、楕円形１２２２は楕円形１２２１及び１２２３の両方に重なっている。これは、３つのレコード内のルール同士の間の論理的な関係に対応している。具体的には、Ｐ１ルール「有効な証明書を有する全てのワードプロセッシングアプリ」の適用範囲は、Ｐ８ルール「有効な証明書を有する全てのアプリ」の適用範囲のサブセットである。Ｐ５ルール「一切のＸ社製品を許可しない」の適用範囲は、Ｐ１及びＰ８レコードのサブセットにもスーパーセットにもならずにＰ１及びＰ８レコードの両方に交差する。

３Ｄ線図１２３０は、セキュリティ評価を行う際にセキュリティポリシー１２３１内のどのルールを適用すべきかを、権限テーブル内の優先度フィールドを使用することによって決定する仕組みを示したものである。図示するように、楕円形１２２１は最上位にあり、セキュリティポリシー１２３１における最高優先度のルール（Ｐ１）に対応している。楕円形１２２２は２番目に上位にあり、セキュリティポリシー１２３１において優先度が２番目に高いルール（Ｐ５）に対応している。楕円形１２２３は最下位にあり、セキュリティポリシー１２３１において最低優先度のルール（Ｐ８）に対応している。より高い優先度の楕円形とより低い優先度の楕円形が交差すると、より高い優先度の楕円形がより低い優先度の楕円形に影を投げかけるのと同じように、より高い優先度のルールとより低い優先度のルールが交差するときは、より高い優先度のルールがより低い優先度のルールに優先する。

このようにして、セキュリティ評価を遂行する際に、権限テーブル内の複数のエントリを使用して、論理的な矛盾なしにセキュリティポリシー１２３１を作成できる。権限テーブル内の様々なエントリを同じ要求に適用する際にどのルールを使用すべきかという問題は、優先度フィールドを使用することによって解決される。例えば、有効な証明書を有するＸ社製のワードプロセッサに対する要求をすると、当該ワードプロセッサが承認される結果になる。これは、「有効な証明書を有する全てのワードプロセッシングアプリ」のルールの方が、「一切のＸ社製品を許可しない」よりも優先度が高いからである。別の例として、「一切のＸ社製品を許可しない」のルールの方が「有効な証明書を有する全てのアプリ」よりも優先度が高いため、有効な証明書を有するＸ社製ウェブブラウザアプリケーションに対する要求をしても承認されない。

一部の実施形態に関し、権限テーブルを使用してセキュリティ評価を実行するためのプロセス１３００を、図１３に概念的に示す。このプロセスは、セキュリティ評価要求を受け取り、権限テーブルのエントリ（又はレコード）を要求とマッチングさせる。次いで、プロセスは、権限テーブル内に格納されているコード要件に要求データオブジェクトが適合しているかどうかを検証することによってセキュリティ評価を遂行する。

（１３１０において）セキュリティ評価を行うクエリ又は要求を受け取ると、プロセス１３００が開始する。この要求は、権限テーブル内に格納されているコード要件が適用されるデータオブジェクト（例えば、アプリケーションプログラムコード、インストールパッケージ、又は開く対象の文書）を伴う。

次いで、（１３２０において）プロセスはデータオブジェクトからコード署名を抽出する。幾つかの実施形態において、署名は、データオブジェクトのソースによって発行された公開鍵証明書から抽出される。続いて、（１３２５において）プロセスは、抽出された署名が認証されるかどうか判定する。幾つかの実施形態において、セキュリティ評価モジュールの中の別個のモジュールが、コード署名認証（例えば、コード署名検証モジュール）を実行する。一旦コード署名が抽出されると、プロセスはコード署名検証モジュールを使用して、コード署名が認証に成功したかどうかをチェックする。署名が認証に成功した場合、プロセスは１３３０に進む。署名が認証に失敗した場合、プロセス１３００は終了する。

次に、（１３３０において）プロセスは権限テーブル内の最高優先度エントリを見つける。幾つかの実施形態において、プロセス１３００は、権限テーブル内の各エントリの優先順位フィールドを比較することによって、どのエントリが最高優先度のものであるかを判定する。続いて、（１３４０において）プロセスはエントリが見つかったかどうかを判定する。幾つかの実施形態において、この判定は、どのエントリが既に調べ終えているかを記録することによって為される。権限テーブル内の全てのエントリを既に調べ終えた後、これ以上はエントリが見つからない。最高優先度のエントリが見つかった場合、プロセスは１３５０に進む。権限テーブル内に検査対象のエントリがこれ以上存在しない場合、プロセス１３００は終了する。

１３５０において、プロセスは見つかった権限テーブルエントリからコード要件を取り出す。（１３６０において）プロセスは、取り出されたコード要件を使用して、データオブジェクトのソースを検証する。そのような検証には、ベンダーＩＤ、及び署名の生成に用いられる証明書の失効日の検証が含まれ得る。また、取り出されたコード要件は、データオブジェクトの他の必須の属性、即ち、データオブジェクトのタイプ、データオブジェクトの名前、又はデータオブジェクトに関連付けられている他の任意の属性などの属性の検証にも使用される。それ故、例えば、データオブジェクトからの署名をプロセスが認証できるとしても、コード要件が満たされなければ（例えば、データオブジェクトのタイプが適切でない場合、又は信頼できると見なされるソースに由来しない場合には）、依然としてデータオブジェクトがプロセスによって却下され得る。

その場合、（１３７０において）プロセスはコード要件がクエリにマッチしているか、即ちクエリに適用可能であるかを判定する。要求に適用できないコード要件に基づいてセキュリティ評価を行うことはできない。時として、プロセスがコード要件を使用して要求のデータオブジェクトを処理するまではコード要件の適用範囲を判定できないこともあるため、幾つかの実施形態では、プロセスのこの時点まではコード要件の適用範囲がチェックされない。幾つかの実施形態において、十分な情報が利用可能になると直ぐ、コード要件の適用範囲が、プロセスによってチェックされる。コード要件がクエリにマッチする（即ち、適用可能である）場合、プロセスは１３９０に進む。それ以外の場合、プロセスは１３８０に進む。

１３８０において、プロセスは権限テーブルを検索して、優先度が次に高いエントリを探す。幾つかの実施形態は、前に検査されたエントリのうち優先度が高いものをマーキングする。そうすれば、単にマーキングされていない最高優先度のエントリが、優先度が次に高いエントリである。次に、（１３４０において）プロセスはエントリが見つかるかどうかを判定する。その場合、プロセスは１３５０に戻る。それ以外の場合、プロセス１３００が終了する。

１３９０において、プロセスはコード要件を使用して、操作開始モジュールが始めるべきアクションを判定する。幾つかの実施形態において、このアクションは、データオブジェクトがコード要件を満たしているかどうかに応じて、マッチしたエントリのアクション（即ち、承認又は不承認）フィールドで指定される。要求に応答した後、プロセス１３００が終了する。

Ｂ．キャッシュテーブル
権限テーブル内のエントリを使用してセキュリティ評価を行うことは、幾つかの実施形態において、多くの計算を含み得る。証明書に埋め込まれた情報を検証するルールは、幾つかの実施形態において計算量の多い操作を含み得る。更にまた、要求にマッチするエントリの検索を完了するために、権限テーブル内の多くのエントリをまたがってトラバースする必要があり得る。例えば、要求にマッチするエントリが存在しないことを確認するために、権限テーブルを完全にトラバースする必要があり得る。幾つかの実施形態は、セキュリティ評価操作の実行対象を未評価のデータオブジェクトのみに限定することによって、セキュリティ評価時間を節約する。つまり、アプリケーションプログラムが初めて起動されたときにのみ、又はデータファイルが初めて開かれたときにのみ、権限テーブルに対してクエリが実行される。

セキュリティ評価操作を更に加速するため、幾つかの実施形態のルールデータベースは、権限テーブルのほかにキャッシュテーブルを組み込む。幾つかの実施形態において、キャッシュテーブルには、そのデータオブジェクトに一意なハッシュ値でインデックス付けされたアドレスロケーションに、データオブジェクトに必要なアクションが格納される。例えば、アプリケーションプログラム又はデータファイルに関して一意のコードディレクトリのハッシュ値を計算できる。故に、アプリケーションの実行（若しくはインストール）、又はアーカイブを開くことのセキュリティ評価に対する要求（下記第ＩＶ節で図２４及び図２５を参照しながら更に詳細に説明する）は、アプリケーション実行可能ファイル、インストールファイル又はアーカイブのハッシュ値の計算のみを必要とする。続いて、ハッシュのインデックス値が指し示すキャッシュテーブルのアドレスロケーションから、アクション（例えば、承認又は不承認）が取り出される。

権限テーブルに対するクエリとは異なり、キャッシュテーブルに対するクエリでは、ルールに従って複数のエントリをトラバースする必要もないし時間の掛かる計算も行う必要もない。故に、キャッシュテーブル内に対応するエントリを有するデータオブジェクトに関する操作の評価に対する要求は、大幅に加速できる。幾つかの実施形態において、セキュリティ評価の要求は、先にキャッシュテーブル内のマッチするエントリを見つけようと試みてから、権限テーブルを検索する。キャッシュテーブル内のエントリがそれぞれ１つのデータオブジェクト（例えば、アプリケーション実行可能ファイル又は文書）に対応することから、キャッシュテーブルはオブジェクトテーブルとも呼ばれる。ユーザは、最近相互作用したデータオブジェクト（よって、キャッシュテーブル内にエントリを有する）と相互作用する傾向があるため、キャッシュテーブルを使用すれば、セキュリティ評価の時間が著しく短縮される。

一部の実施形態に関し、権限テーブル１４１０及びキャッシュテーブル１４６０を含むルールデータベース１４００を、図１４に示す。この図にはまた、キャッシュテーブルのエントリの例、及びキャッシュテーブルエントリと権限テーブルエントリ間の関係も示してある。幾つかの実施形態において、権限テーブル及びキャッシュテーブルは、別々の物理的ストレージ内に格納される一方、他の実施形態においては、権限テーブル及びキャッシュテーブルが単一の物理的ストレージ内に格納される。

権限テーブル１４１０は、フォーマット及びコンテンツが図９の権限テーブル９００と同様で、レコードエントリ１４２１〜１４２３、優先度フィールド１４４０、ルールフィールド１４４１、及びアクションフィールド１４４２を含む。

キャッシュテーブル１４６０は、３つのエントリ１４７１〜１４７３を有している。キャッシュテーブルのエントリは、権限テーブルのエントリとは異なり、ルールフィールドを有しない。一方、キャッシュテーブルは、ハッシュＩＤフィールド１４９１、有効期限フィールド１４９２、アクションフィールド１４９３及び参照フィールド１４９４などの他のフィールドを有する。

キャッシュテーブル１４６０のエントリ１４７１は、権限テーブル１４１０のエントリ１４２１とマッチするデータオブジェクト（データオブジェクトＡ）に基づく。キャッシュテーブル１４６０のエントリ１４７２は、権限テーブル１４１０のエントリ１４２２とマッチするデータオブジェクト（データオブジェクトＢ）に基づく。幾つかの実施形態においては、データオブジェクトＡ及びＢに基づいてセキュリティ評価要求が行われたときに、これらのキャッシュテーブルエントリが作成される。エントリ１４７３は、権限テーブル１４１０内のいずれのエントリにもマッチしないデータオブジェクト（データオブジェクトＣ）に基づく。権限テーブル１４１０が、データオブジェクトＣに関するセキュリティ評価要求のためのマッチするルールをもたらすことに失敗すると、キャッシュテーブル１４６０内にネガティブエントリ１４７３が作成される。結果として、そのようなネガティブエントリがキャッシュテーブル内に存在していることにより、長時間にわたる権限テーブル１４１０の網羅的な検索が起きないようになる。

キャッシュテーブルのネガティブエントリ１４７３は、権限テーブル１４１０内にマッチするエントリが無いオブジェクトから生成されるため、権限テーブルから一切のフィールドを継承しない。幾つかの実施形態において、ネガティブエントリには、これがネガティブエントリであること、及び権限テーブル１４１０内にそのデータオブジェクト用のマッチするエントリが存在しないことを示す表示が含まれる。そのような幾つかの実施形態において、権限テーブルには、通常は処理されないが、キャッシュテーブル内のネガティブエントリが参照するためのアンカーとしての役目を果たす「仮想」エントリが含まれる。つまり、一切のルールが適用されないことが判定された結果として作成されるキャッシュレコード（即ち、ネガティブエントリ）は、権限テーブル内に格納されている仮想的な「権限なし」ルール（即ち、仮想エントリ）を参照する。これは主としてデータ構造の整合性を確実にするために為されるもので、これらの実施形態の目に見える挙動には影響しない。

キャッシュテーブルエントリ内のアクションフィールド１４９３には、実際にデータオブジェクトに対して行われたアクションが記録される。このアクションは、権限テーブル１４１０内に格納されたマッチするルールの適用に基づき、データオブジェクトを承認又は不承認する。例えば、キャッシュテーブルのエントリ１４７２のアクションフィールドはオブジェクトＢを「承認しない」ことを示す。これは、（権限テーブルエントリ１４２２内に格納された）オブジェクトＢのマッチするルールがオブジェクトＢをそのコード要件を満たしていないものとして評価したためオブジェクトＢが承認されなかったことを示す。この場合、オブジェクトＢに基づく次の要求でキャッシュテーブル内のこのエントリを取り出すことも承認されない。つまり、各キャッシュテーブルエントリのアクションフィールド１４９３には、そのエントリのデータオブジェクトのセキュリティ評価が格納される。

有効期限フィールド１４９２は、キャッシュエントリがいつ失効したかを示す。幾つかの実施形態において、データオブジェクト用のキャッシュテーブルエントリの有効期限は、そのデータオブジェクトのコンテンツによって決定される。幾つかの実施形態は、データオブジェクトの証明書の有効期限をキャッシュエントリの有効期限として使用する。署名が一連の証明書から導出されるデータオブジェクトに関しては、最も早く失効する証明書の有効期限が、これらの幾つかの実施形態で使用される。幾つかの実施形態において、有効期限は、権限テーブル内のルールによって決定され、キャッシュテーブルのエントリが作成されたときに、キャッシュテーブル内に挿入される。幾つかの実施形態において、オペレーティングシステムは、データオブジェクト証明書以外の情報に基づいて有効期限を独自に指定する。幾つかの実施形態においてそのような情報は、ベンダー提供の既定値、要求された操作の種類、又はオペレーティングシステムに利用可能な他の何らかの情報であり得る。

幾つかの実施形態において、セキュリティ評価モジュールは、キャッシュテーブルエントリを適用する前に、そのエントリの有効期限フィールドをチェックする。有効期限を基準に失効したキャッシュテーブルエントリは、セキュリティ評価モジュールにより無視される（そしてキャッシュミスとして扱われる）。これにより、セキュリティ評価モジュールが、キャッシュテーブル１４６０内で現在用いられていないエントリに基づいて、誤ったセキュリティ評価を行わずに済むようになる。幾つかの実施形態において、失効済みキャッシュテーブルエントリは、アクセスされたときにパージされる。幾つかの実施形態は、キャッシュテーブルに失効済みエントリがないかどうかを定期的にチェックして、失効済みエントリがあるときはテーブルから除去するパージメカニズムを備える。

ハッシュＩＤフィールド１４９１には、ハッシュ値が格納される。幾つかの実施形態において、キャッシュテーブルエントリのハッシュＩＤフィールドには、キャッシュテーブルエントリのデータオブジェクトのハッシュに関連付けられた値が格納される。他の幾つかの実施形態は、このフィールドをキャッシュテーブル内に含まない。

幾つかの実施形態において、参照フィールド１４９４には、権限テーブル内のエントリへのリンクが格納される。具体的には、各キャッシュテーブルエントリの参照フィールド１４９４には、キャッシュテーブルエントリの生成に使用される、権限テーブル内のエントリへのリンクが格納される（即ち、その権限テーブルエントリのルールは、キャッシュテーブルエントリに関連付けられたデータオブジェクトのセキュリティ評価の遂行に使用される）。例えば、キャッシュテーブルエントリ１４７１の参照フィールドには、キャッシュテーブルエントリ１４７１が権限テーブルエントリ１４２１から生成されることが示され、キャッシュテーブルエントリ１４７２の参照フィールドには、キャッシュテーブルエントリ１４７２が権限テーブルエントリ１４２２から生成されることが示される。

幾つかの実施形態は、キャッシュテーブル内の参照フィールドを使用して、権限テーブルが変更されたために無効になったエントリのキャッシュテーブルをパージする。幾つかの実施形態において、キャッシュテーブルにはまた、権限テーブルから継承される優先度フィールドも含まれる（不図示）。幾つかの実施形態は、キャッシュテーブル内の優先度フィールドを使用して、権限テーブルが変更されたために無効になったエントリのキャッシュテーブルをパージする。キャッシュテーブルエントリのパージについては、下記の第ＩＩ−Ｃ節で、図１８を参照しながら更に説明する。

幾つかの実施形態において、キャッシュテーブル１４６０には、他のフィールドも含まれる。これらのキャッシュテーブルフィールドの幾つかのコンテンツは、キャッシュテーブルエントリの作成に使用される権限テーブルエントリから継承される。幾つかの実施形態において、キャッシュテーブル内のエントリ同士は必ずしも隣接するとは限らない。それらエントリのアドレスは、そのエントリの生成に用いられるデータオブジェクトのハッシュ値で決定されるからである。幾つかの実施形態において、データオブジェクトのハッシュ値は、データオブジェクトに対してハッシュ操作を実行することによって生成される。幾つかの実施形態において、ハッシュ操作は、他の任意のデータオブジェクトから一意にデータオブジェクトを識別するハッシュ値を生成する。幾つかの実施形態において、ハッシュ操作は、増分ハッシュ操作を含む。増分ハッシュ操作の説明は、本明細書において参照により援用されている、例えば、米国特許第７，１０３，７７９号に見出すことができる。

幾つかの実施形態において、ハッシュ操作は、コードディレクトリのハッシュ操作を含む。幾つかの実施形態において、コードディレクトリのハッシュは、キャッシュテーブル内の全ての一意のエントリを参照する一意の値である。故に、その対応するコード要件を有する各データオブジェクトは、一意のコードディレクトリハッシュにより、キャッシュテーブル内で一意に識別される。コードディレクトリのハッシュ及びその機能の説明は、本明細書において参照により援用される、米国特許出願公開第２００８／０１６８５５３号に見出すことができる。

図１４の例において、オブジェクトＡのエントリ（１４７１）はオブジェクトＡのハッシュ値でインデックス付けされている場所に格納され、オブジェクトＢのエントリ（１４７２）はオブジェクトＢのハッシュ値でインデックス付けされている場所に格納され、オブジェクトＣのエントリ（１４７３）はオブジェクトＣのハッシュ値でインデックス付けされている場所に格納される。

一部の実施形態に関し、操作開始モジュールからの要求に基づいてセキュリティ評価の目的に権限テーブル及びキャッシュテーブルの両方を使用するセキュリティ評価モジュール１５００を、図１５に示す。図示するように、セキュリティ評価モジュール１５００は、操作開始モジュール１５０５からの要求を受け取り、権限テーブル１５１０及びキャッシュテーブル１５１５の両方に対してクエリを実行する。セキュリティ評価モジュール１５００は、権限テーブルに対してクエリを実行するクエリマネージャ１５２０と、キャッシュテーブルに対してクエリを実行するクエリマネージャ１５２５と、を具備する。セキュリティ評価モジュール１５００はまた、プロセッサ１５３０と、キャッシュテーブルレコードジェネレータ１５４０と、を具備する。権限テーブル１５１０に対してクエリを実行するクエリマネージャ１５２０はまた、ルールエンジン１５５０と、レコード選択モジュール１５６０と、署名検証モジュール１５７０とを含む。

操作開始モジュール１５０５は、セキュリティ評価要求を行い、セキュリティ評価の結果が、セキュリティ評価モジュールのプロセッサ１５３０から来るのを待つ。プロセッサ１５３０は、操作開始モジュール１５０５からのセキュリティ評価要求を受け取る。プロセッサは、この受け取ったセキュリティ評価要求に基づいて、セキュリティ評価要求を承認するかどうかを判定するために、クエリマネージャ１５２０（権限テーブル用）及び１５２５（キャッシュテーブル用）の両方と通信する。また、プロセッサは、キャッシュテーブル１５１５内にキャッシュミスがあるときには、キャッシュテーブルレコードジェネレータ１５４０を使用して、新規のキャッシュエントリを生成する。また、キャッシュテーブルレコードジェネレータは、要求の対象であるデータオブジェクト（即ち、プログラムコード又は文書）をハッシュすることによって、キャッシュテーブル１５１５の物理メモリへのアドレスを生成する際にも使用される。

キャッシュテーブルに対してクエリを実行するためのクエリマネージャ１５２５は、プロセッサ１５３０と、キャッシュテーブル１５１５を格納する物理メモリとの間のインターフェースを提供する。権限テーブルに対してクエリを実行するためのクエリマネージャ１５２０は、プロセッサ１５３０と、権限テーブル１５１０を格納する物理メモリとの間のインターフェースを提供する。また、クエリマネージャ１５２０は、レコード選択モジュール１５６０を使用して、権限テーブル１５１０からエントリを選択して取り出す。続いて、取り出されたエントリは、ルールエンジン１５５０に中継され、解析され実行される。幾つかの実施形態において、クエリマネージャ１５２０は署名検証モジュール１５７０を使用して、データオブジェクトのコード署名を検証する。そのような幾つかの実施形態において、何らかの原因でコード署名が正しく認証できない場合、セキュリティ評価モジュール１５００は、操作開始モジュール１５０５に不承認メッセージを返す。幾つかの実施形態において、ルールエンジン１５５０、レコード選択モジュール１５６０及び署名検証モジュール１５７０の機能が、クエリマネージャ１５２０でなくプロセッサ１５３０によって実行される。

署名検証モジュール１５７０は、データオブジェクトのコード署名を認証する。幾つかの実施形態において、署名検証モジュールは、データオブジェクト自体のコンテンツだけでなく公開鍵証明書の情報も使用して署名を認証する。署名検証モジュールは、証明書により識別された署名認証アルゴリズムに従って署名認証操作を実行する。署名認証プロセスを完了すると直ぐ、署名検証モジュールは、データオブジェクトの署名の認証が成功したかどうかをセキュリティ評価モジュール１５００に通知する。

図１６は、セキュリティ評価モジュール１６００によるデータオブジェクト用キャッシュテーブルエントリの生成及び格納を示している。具体的には、図はデータオブジェクトに基づいてセキュリティ評価モジュールに対して要求が行われたときの、キャッシュテーブルエントリ内の様々なフィールドの生成を示したものである。図１６は、権限テーブル１６０５、キャッシュテーブル１６１０、及びセキュリティ評価モジュール１６００に対しデータオブジェクト１６２５に関する要求を行う操作開始モジュール１６２０を示したものである。キャッシュテーブルは、エントリ１６１１〜１６１３を有する。

セキュリティ評価モジュール１６００は、権限テーブル用クエリマネージャ１６３０と、ハッシュモジュール１６５０と、メモリインターフェース１６６０と、有効期限抽出モジュール１６７０と、を具備する。一部の実施形態に関しては、クエリマネージャ１６３０が、図１５のクエリマネージャ１５２０に類似している。ハッシュモジュール１６５０、及び有効期限抽出モジュール１６７０の機能は、図１５のプロセッサ１５３０に類似のプロセッサによって実行される。セキュリティ評価モジュール１６００はまた、署名検証モジュールなどの他のモジュールを具備するが、図を簡略化する目的で示していない。

操作開始モジュール１６２０は、セキュリティ評価モジュール１６００に対し、データオブジェクト１６２５（‘データオブジェクトＸ’）の使用を必要とする操作に関するセキュリティ評価の要求を行う。データオブジェクト１６２５は、クエリマネージャ１６３０、ハッシュモジュール１６５０、及び有効期限抽出モジュール１６７０を含む、セキュリティ評価モジュール１６００内の幾つかのモジュールに中継される。クエリマネージャ１６３０は、権限テーブル１６０５からデータオブジェクト１６２５とマッチするエントリを見つける。その後、クエリマネージャはマッチするエントリのルールを適用して、データオブジェクト１６２５に適切なアクションを決定する。クエリマネージャによって決定されたこのアクションが、新規のキャッシュテーブルエントリ１６１２用のアクションフィールド１６４２を形成する。

ハッシュモジュール１６５０はデータオブジェクト１６２５を受け取り、受け取ったデータオブジェクトに対してハッシュ操作を実行する。幾つかの実施形態において、ハッシュ操作は、増分ハッシュ操作である。ハッシュモジュール１６５０は、データオブジェクトＸ用に新規に作成されたキャッシュテーブルエントリのキャッシュテーブル内の場所を指定するためインデックス（‘Ｘ用のインデックス’）の役目を果たす一意のコードディレクトリのハッシュ値１６５５を生成する。続いて、メモリインターフェース１６６０は、この値をキャッシュテーブル用の物理アドレスとして使用する。幾つかの実施形態において、この一意に生成されたコードディレクトリのハッシュ値は、データオブジェクトＸ用のエントリ１６１２のハッシュＩＤフィールド内に格納される。

有効期限抽出モジュール１６７０はまたデータオブジェクト１６２５を受け取り、有効期限をデータオブジェクト１６２５から計算するか又は抽出する。幾つかの実施形態において、データオブジェクトの有効期限は、データオブジェクトの署名の作成に用いられる証明書によって指定される。データオブジェクトは、その署名を１つより多くの証明書、又は実に一連の証明書から導出する場合もある。幾つかの実施形態は、これらの証明書の最も早い有効期限を、キャッシュテーブルエントリの失効日として使用する。抽出された有効期限は、有効期限フィールド１６７５になる。幾つかの実施形態において、有効期限抽出モジュール１６７０は、有効期限を判定するための基準として他の情報を使用する。他の幾つかの実施形態において、有効期限フィールド１６７５は権限テーブルから継承され、有効期限抽出モジュール１６７０では計算されない。

アクションフィールド１６４２及び有効期限フィールド１６７５は一体に連結され、データオブジェクトＸ用のハッシュＩＤフィールド及び参照フィールドと供にデータオブジェクトＸ用の新規のキャッシュテーブルエントリ１６１２を形成する。キャッシュテーブル１６１０は、他の２つのオブジェクト用の他の２つのエントリ（データオブジェクトＹ用のエントリ１６１１及びオブジェクトＺ用のエントリ１６１３）を有する。

幾つかの実施形態において、キャッシュテーブルのコンテンツは、同様なオペレーティングシステムを実行している別々のコンピュータによって共有され得る。コンピュータは、別のコンピュータによって生成されるキャッシュテーブル、又はオペレーティングシステムのベンダーによって供給される事前にパッケージングされたキャッシュテーブルをインポートできる。そのような事前入力済みキャッシュテーブルを使用するコンピュータは、それ自身のキャッシュエントリを生成する必要なしに、そのセキュリティ評価操作を直ちに加速できる。

一部の実施形態に関し、権限テーブルとキャッシュテーブルの両方をセキュリティ評価の実行に使用するプロセス１７００を、図１７に概念的に示す。このプロセスはまず、キャッシュテーブル内のマッチするエントリを見つけようと試みる。プロセスがキャッシュテーブル内でそのようなエントリを見つけることができない場合（即ち、キャッシュミス）、代わりに権限テーブルに対してクエリを実行してマッチするエントリを見つける。権限テーブルに対してクエリが実行されると、結果としてキャッシュテーブル内に新規のエントリが生成される。幾つかの実施形態において、このプロセスはオペレーティングシステムのセキュリティ評価モジュールによって実行される。

操作開始モジュールによって（例えば、アプリケーションの実行、アプリケーションのインストール、又は文書を開くなどの）操作が要求されたときに、プロセス１７００が開始される。プロセスは、要求された操作に必要とされるデータオブジェクトと共に、この要求を（１７１０において）受け取る。

次いで、プロセスは（１７２０において）データオブジェクト用のハッシュ値（即ち、一意のコードディレクトリのハッシュ値）を判定する。幾つかの実施形態において、ハッシュ値は増分ハッシュ操作によって計算される。計算されたハッシュ値は、データオブジェクト用のキャッシュテーブル内にエントリを配置するためのインデックスの役目をする。次に、プロセスは（１７３０において）ハッシュ値を使用してキャッシュテーブルエントリを見つけることができるかどうかを判定する。この判定は、幾つかの実施形態において、ハッシュ値で指し示された場所に格納された有効なエントリが存在するかどうかに基づく。これらの実施形態の幾つかにおいて、各キャッシュテーブルエントリは、キャッシュテーブルエントリが有効かどうかを示すビットに関連付けられている。データオブジェクト用のキャッシュエントリが入力されていない場合、又はキャッシュテーブルエントリがパージ済みでかつ新規のキャッシュエントリが未入力の場合、キャッシュテーブルエントリは無効となる。プロセスがデータオブジェクトのハッシュ値を使用して有効なエントリを見つけることができる場合（キャッシュヒット）、プロセスは１７４０に進む。それ以外（キャッシュミス）の場合、プロセスは１７５０に進む。

１７４０において、プロセスは、マッチするキャッシュテーブルエントリのコンテンツに基づいてセキュリティ評価要求に対する応答を判定する。次いで、プロセスは（１７８０において）その応答が要求された操作の承認であるかどうかを判定する。応答によって操作が承認された場合、プロセスは１７９０に進み、ここで操作開始モジュールは要求を図１の実行モジュール１７２、インストールモジュール１７０又はコンテンツを開くモジュール１７４などの操作ハンドラに渡す。応答によって操作が承認されない場合、操作開始モジュールは要求を操作ハンドラに渡さないようにして、操作の続行を中止する。プロセス１７００は、キャッシュテーブルエントリのコンテンツに基づいて操作開始モジュールに応答した後で、終了する。

キャッシュテーブルにおいてキャッシュミスが発生したため、１７５０において、プロセスは権限テーブルに対してクエリを実行する。幾つかの実施形態において、この操作は、図１３のプロセス１３００によって実行される。このプロセス１３００は権限テーブルを検索して、要求にマッチするエントリを探す。

次に、プロセスは（１７５５において）権限テーブル内でマッチするエントリを見つけることができたかどうかを判定する。その場合、プロセスは１７６０に進む。それ以外の場合、プロセスは１７７０に進み、データオブジェクト用のネガティブキャッシュエントリを作成し、その後で終了する。上述したように、データオブジェクト用のネガティブキャッシュエントリによって、セキュリティ評価モジュールは、オペレーティングシステムのセキュリティポリシーが特定の要求に適用可能なルールを有していないことを即座に確認できる。

１７６０において、プロセスは権限テーブル内のマッチするエントリから応答を判定する。プロセスは、次いで（１７６５において）権限テーブル内のこのマッチするエントリに基づいて、キャッシュテーブル内に新規のエントリを作成する。続いて、プロセスは１７８０に進み、要求された操作を承認すべきかそれとも不承認すべきかを判定する。プロセス１７００は、権限テーブルエントリのコンテンツに基づいて操作開始モジュールに応答した後で、終了する。

Ｃ．ユーザによるオーバーライド
幾つかの実施形態において、十分な特権を有するユーザは、権限テーブル内のエントリの追加、削除又は修正によってルールデータベースに変更を加えることを許可される。例えば、管理者特権を有するユーザは、特定のアプリケーションを実行するための署名認証をバイパスできる。ユーザは、より低い優先度のルールよりも優先されるより高い優先度のエントリを権限テーブルに追加し、それにより特定のアプリケーションの実行を許可することによって、このパイパスを行うことができる。

一方、上の図１０に示すように、セキュリティポリシーは多くの場合、優先度を基準に一体にリンクされた幾つかのテーブルエントリを含む。したがって、セキュリティポリシーの下でデータオブジェクトを評価するためには、これらのテーブルエントリを優先度で示された順序で調べる必要がある。データオブジェクトに関して何らかのセキュリティ評価を行う際、より高い優先度のルールが適用できないときに限り、より低い優先度のルールが適用可能になる。故に、より高い優先度のルールに何らかの変更が加えられた場合、より低い優先度のルールの適用範囲が変わる可能性がある。

キャッシュテーブルには、権限テーブルが変更される前のルールの適用範囲を反映するキャッシュエントリが格納されているため、幾つかの実施形態においては、特定の優先度の権限テーブルが変更されると、キャッシュテーブル内のエントリのうち優先度が等しいか又はより低い全てのエントリをパージすることが、引き起こされる。例えば、新規の権限テーブルエントリの優先度値が２．３である場合、キャッシュテーブル内のエントリのうち優先度が２．３に等しいか又はより低い全てのエントリをパージすることが、引き起こされる。幾つかの実施形態において、このパージプロセスは、各キャッシュテーブルエントリ内の参照フィールド（例えば、図１４の１４９４）を使用して、キャッシュテーブルエントリの作成に使用される権限テーブルエントリの優先度を把握する。他の幾つかの実施形態において、各キャッシュテーブルエントリには、この目的のため権限テーブルから継承される優先度フィールドが保持されている。

幾つかの実施形態において、ネガティブキャッシュエントリは、優先度が最も低いと想定される。ネガティブエントリは、権限テーブル内にマッチするエントリが無いデータオブジェクトのキャッシュテーブルエントリであるため、権限テーブルに何らかの変更が加えられた場合、ネガティブエントリのデータオブジェクトに影響が及ぶ可能性がある（即ち、権限が変更された場合、データオブジェクトが権限テーブル内にマッチするエントリを有するようになり、故に、ネガティブエントリが無効になる）。これらの実施形態の幾つかにおいて、権限テーブルに対する何らかの変更が加えられると、常にネガティブキャッシュエントリがパージされる。

一部の実施形態に関し、管理者ユーザがルールデータベースを変更した後にルールテーブルを保守管理するプロセスを、図１８に概念的に示す。このプロセスでは、キャッシュテーブルからより低い優先度のエントリがパージされる。プロセス１８００は、特権のあるユーザ（例えば、管理者）がルールデータベースに変更を加えたときに、開始される。このプロセスは（１８１０において）特権のあるユーザからルール変更を受け取り、（１８２０において）そのルールの変更が権限テーブル内に既に存在するルールに対するものかどうかを判定する。そのルールの変更が権限テーブル内に既に存在するルールに対するものである場合、プロセスは１８４０に進み、権限テーブルエントリを更新する。それ以外の場合、プロセスは１８３０に進み、権限テーブル内に新規のエントリを作成する。

次いで、プロセスは（１８５０において）新規に追加されたか又は更新されたルールよりも優先度の低いエントリがルールデータベース内にあるかどうかを判定する。エントリがある場合、プロセスは１８６０に進む。それ以外の場合、プロセス１８００が終了する。

１８６０において、プロセスはキャッシュテーブル内の全てのより低い優先度のエントリを削除する。幾つかの実施形態において、プロセスは、キャッシュテーブル内にある全てのエントリを調べ、新規に追加されたか又は更新された権限テーブルエントリと優先度が等しいか又はより低い全てのエントリをパージする。全てのより低い優先度のキャッシュテーブルエントリ（任意のネガティブエントリを含む）が削除された後、プロセス１８００が終了する。

ＩＩＩ．ダウンロードされたコンテンツのセキュリティ評価
上記の実施形態の幾つかは、データオブジェクト内に埋め込まれている証明書を使用して、これらのデータオブジェクトに関するセキュリティ評価を行う。ほとんどの場合、これらの方法は、これらのデータオブジェクトのソースによって提供されたＩＤ（例えば、証明書内の署名及びベンダーＩＤ）に依存する。ただし、これらのソース提供のＩＤは、必ずしも常に利用可能であるとは限らない、又は信頼できるものであるとは限らない。それ故、セキュリティ評価を遂行する目的で、これらのソース提供の識別子に依存するのに加えて又はその代わりに、幾つかの実施形態のオペレーティングシステムは独自のＩＤをデータオブジェクト用に提供している。これらの実施形態の幾つかにおいて、オペレーティングシステムは、インターネット、ＵＳＢフラッシュドライブ、又はデバイスの他の任意の周辺インターフェースなどの外部ソースからインポートされるデータオブジェクトにタグを関連付ける。タグには、データオブジェクトが外部ソースに由来するものであることを示す隔離ビットが含まれる。隔離ビットが存在する場合、データオブジェクトに対してシステムがセキュリティ評価を遂行していないことを更に示している。一旦オペレーティングシステムがデータオブジェクトに対しセキュリティ評価を遂行すると、タグが更新され（例えば、隔離ビットを除去することによって）、データオブジェクトがオペレーティングシステムのセキュリティポリシーの下で既に評価されたこと、及びデータオブジェクトがオペレーティングシステムのセキュリティポリシーを通過した（又は通過しなかった）ことを示す。

図１９は、セキュリティ評価を実行するため自身の識別子を使用するオペレーティングシステムを具備するコンピュータ１９００を概念的に示したものである。具体的には、コンピュータ１９００のオペレーティングシステムは、例えば、インターネットからダウンロードされたコンテンツ及び／又はアプリケーションにタグ又は隔離ビットを追加する。コンピュータ１９００は、記憶装置１９１０と、タグモジュール１９２０と、現在コンピュータ１９００上で実行されているアプリケーション１９３０と、ネットワークインターフェース１９４０と、ユーザインターフェース（ＵＩ）モジュール１９５０と、を含む。ＵＩモジュール１９５０は、入力デバイスドライバ１９６０及び表示モジュール１９７０を介してユーザとの通信を制御する。

ネットワークインターフェース１９４０は、ネットワークを介したコンピュータ１９００と外界との間の通信インターフェースを提供する。ネットワークは、コンピュータ１９００がインターネット１９８０経由で通信し、他のコンピュータからアプリケーションファイル１９８１〜１９８２及びコンテンツファイル１９８３〜１９８４などのデータオブジェクトにアクセスできるようにしている。これらのコンテンツファイルは、テキストファイル、ワードプロセッサ文書、スプレッドシート、メディアファイルなどであり得る。アプリケーションファイルはインストール及びプログラムファイルを挙げることができる。そして、これらのアプリケーション及びコンテンツファイルがコンピュータ１９００にダウンロードできる。図に示されていないが、コンピュータ１９００はまた、インターネット以外の外部ソース（外部フラッシュドライブなど）からも、データオブジェクトをダウンロードできる。

アプリケーション１９３０は、現在オペレーティングシステムを介してコンピュータ１９００上で実行されているプログラム又はプロセスのセットである。アプリケーション１９３０は、インターネットブラウザ、ワードプロセッサ、ビデオゲーム、メディア編集アプリケーション、又はコンピュータ１９００上で動作可能な任意のプログラムであり得る。アプリケーション１９３０は、ネットワークインターフェースを介してインターネット上のソースからデータオブジェクト１９８１〜１９８４をダウンロードすることを含む、インターネット経由での通信を必要とする操作を実行できる。一旦ファイルをダウンロードし終えると、アプリケーション１９３０は、ダウンロードされたファイルを記憶装置１９１０内に格納する。幾つかの実施形態においては、ダウンロードされたファイルは格納される前にタグモジュール１９２０を通過しなければならない。

タグモジュール１９２０は、各ダウンロードされたファイルをタグに関連付ける。幾つかの実施形態において、そのようなタグには、ダウンロードされたファイルが外部ソースに由来するものであり、かつオペレーティングシステムのセキュリティポリシーの下で検査されていないことを示す隔離ビットが含まれる。幾つかの実施形態においては、タグモジュールによって、ダウンロードされたファイルにタグが挿入されるか又は追加される。幾つかの実施形態において、タグモジュールは、どのファイルがインターネット又は他の外部ソースに由来するものであるかを記録するタグテーブルを保守管理する。コンピュータ上で実行されている他のプロセス又はモジュールは、タグテーブルにアクセスして、どのファイル又はデータオブジェクトがインターネットなどの外部ソースに由来するものであるとしてタグ付けされているかを確認できる。幾つかの実施形態では、外部ソースからのファイルへのタグ付けは、ファイルがアプリケーション１９３０によってダウンロードされると直ぐに、かつそのファイルが記憶装置１９１０内に格納される前に為される。

記憶装置１９１０には、コンピュータ１９００用の様々なデータオブジェクトが格納される。これらのデータオブジェクトは、インターネット又は他の外部ソースからダウンロードされるコンテンツファイル及びアプリケーションファイルを含み得る。幾つかの実施形態において、これらのダウンロードされたアプリケーション及びコンテンツファイルは、タグモジュール１９２０によって供給されたタグに関連付けられる。

一旦ダウンロード済みファイルが格納されてタグ付けされると、オペレーティングシステムは、データオブジェクトがダウンロードされたかどうかを考慮するセキュリティポリシーに基づいてセキュリティ評価を遂行し得る。図２０は、セキュリティ評価操作の際にタグ又は隔離ビットの存在チェックを必要とするオペレーティングシステム２０００を示したものである。具体的には、オペレーティングシステム２０００は、セキュリティ評価操作が実行される前に、データオブジェクトがタグ付けされているかどうかを識別するためのメカニズムを備える。セキュリティ評価操作は、上の第Ｉ節及び第ＩＩ節に記載されているセキュリティ評価操作と類似している。

図示するように、オペレーティングシステム２０００は操作要求モジュール２００５と、セキュリティ評価モジュール２０２０と、ルールデータベース２０３０と、操作開始モジュール２０１０と、を含む。操作開始モジュールは、プロセッサ２０４０とタグ識別モジュール２０５０とを含む。オペレーティングシステムはまた、インストールモジュール２０６０及びコンテンツを開くモジュール２０７０も含む。

幾つかの実施形態において、オペレーティングシステム２０００は、図１のオペレーティングシステム１００と類似している。具体的には、操作要求モジュール２００５は、操作要求モジュール１４０と同様に、操作開始モジュール１３０に対し操作の実行を要求する。インストールモジュール１７０及びコンテンツを開くモジュール１７４と同様に、インストールモジュール２０６０及びコンテンツを開くモジュール２０７０は、承認された要求を受け取って、承認された操作を実行する操作ハンドラである。

セキュリティ評価モジュール２０２０及びルールデータベース２０３０は、図１に示すセキュリティ評価モジュール１１０及びルールデータベース１２０と同様の操作を実行する。セキュリティ評価モジュール及びルールデータベースの機能についてはまた、上の第ＩＩ節で図７〜１７を参照しながら説明されている。例えば、幾つかの実施形態において、ルールデータベース２０３０は、権限テーブルとキャッシュテーブルの両方を含む。幾つかの実施形態において、セキュリティ評価モジュール２０２０は、ユーザ入力に基づいて、タグ付けされたオブジェクトのセキュリティ評価を遂行する。例えば、セキュリティ評価モジュール２０２０は、タグ付けされたオブジェクトをセキュリティ評価する要求を受け取ると即座に、要求された操作がダウンロード済みオブジェクトを含むことをユーザに通知し、リスクを承知の上で続行するかどうかをユーザに尋ねる。

操作開始モジュール２０１０は、操作開始モジュール１３０と同様に、特定操作の実行を許可するか又は禁止することにより、オペレーティングシステムのセキュリティポリシーを執行する。操作開始モジュール２０１０は操作要求モジュール２００５から特定の操作要求を受け取り、要求された操作をオペレーティングシステム２０００のセキュリティポリシーの下で評価するようにセキュリティ評価モジュール２０２０に要求する。一方、図１の操作開始モジュール１３０とは異なり、操作開始モジュール２０１０は、要求された操作に対するデータオブジェクトが、インターネット又は他の任意の外部ソースに由来するものとしてタグ付けされているかどうかをチェックする。外部ソースに由来するものとしてタグ付けされた（例えば、隔離ビットでタグ付けされた）データオブジェクトが、セキュリティ評価の対象となる。既に評価されたデータオブジェクトに対する反復的なセキュリティ評価を回避するため、幾つかの実施形態は、セキュリティ評価後にタグを更新し、既にデータオブジェクトの評価が済んでいることを示す。幾つかの実施形態では、隔離ビットを除去することによって、これを達成する。幾つかの実施形態において、更新済みタグはまた、データオブジェクトが以前のセキュリティ評価に通過したのか失敗したのかも示す。

図２０の例において、操作開始モジュール２０１０内部のタグ識別モジュール２０５０は、タグをチェックしてプロセッサモジュール２０４０にレポートする。オペレーティングシステム２０００において、セキュリティ評価モジュール２０２０は、タグに基づいてそのセキュリティ評価を行わない。タグを使用して、要求された操作の処理を続行すべきかどうかを決定するのは、操作開始モジュール２０１０内のプロセッサ２０４０である。これらの実施形態の幾つかにおいて、要求された操作に関連付けられているデータオブジェクトが外部ソースに由来するものであり評価されたことのないものとしてタグ付けされている場合にのみ、操作開始モジュール２０１０はセキュリティ評価の処理を続行する。データオブジェクトがそのようにタグ付けされていない場合（例えば、隔離ビットが除去された場合、又はデータオブジェクトが以前に評価を受けたものとして既にタグ付けされている場合）、操作開始モジュール２０１０は、セキュリティ評価を行うようにセキュリティ評価モジュールに要求しない。

図２１〜２２は、データオブジェクト内のタグを識別する操作開始モジュールを使用してセキュリティ評価を実行したときの、オペレーティングシステム２０００内のデータフローを示したものである。図２０におけるように、図２１〜２２のオペレーティングシステム２０００は、セキュリティ評価モジュール２０２０と、ルールデータベース２０３０と、操作開始モジュール２０１０と、操作要求モジュール２００５と、インストールモジュール２０６０と、コンテンツを開くモジュール２０７０と、を含む。

図２１は、オペレーティングシステム２０００内にアプリケーションをインストールする操作のデータフローを示したものである。操作開始モジュール２０１０に対しアプリケーションＸをインストールするように要求が行われると（操作‘１’）、操作要求モジュール２００５において操作が開始する。その後、プロセッサ２０４０はアプリケーションＸがタグ付けされているかどうかを尋ねるコマンドをタグ識別モジュール２０５０に送信する（操作‘２’）。アプリケーションＸが、外部ソースに由来するもの（例えば、隔離ビットを有する）としてタグ付けされている場合、タグ識別モジュール２０５０が確認をプロセッサ２０４０に送信する（操作‘３’）と、プロセッサはセキュリティ評価を遂行するようにセキュリティ評価モジュール２０２０に対し要求する（操作‘４’）。他方、アプリケーションＸがタグ付けされていない場合、又はアプリケーションＸが以前に評価された（又は隔離ビットが除去された）ものとしてタグ付けされている場合、プロセッサ２０４０は幾つかの実施形態において、セキュリティ評価モジュール２０２０に対し、セキュリティ評価を遂行するように要求しない。幾つかの実施形態において、アプリケーションＸが、以前のセキュリティ評価に失敗したものとしてタグ付けされている場合、プロセッサ２０４０はセキュリティ評価モジュール２０２０を関与させることなしに、インストールプロセスを即座に終了し得る。その逆に、アプリケーションＸが、以前のセキュリティ評価に通過したものとしてタグ付けされている場合、プロセッサ２０４０は幾つかの実施形態において、セキュリティ評価モジュール２０２０を関与させることなしに、アプリケーションＸが処理を続行するのを即座に許可し得る。

セキュリティ評価要求が為された場合、セキュリティ評価モジュール２０２０はルールデータベース２０３０に対してクエリを実行する（操作‘５’）。ルールデータベース２０３０はそのデータベース内のルール又は命令をセキュリティ評価モジュール２０２０に供給する（操作‘６’）。セキュリティ評価モジュール２０２０とルールデータベース２０３０との間のこのクエリプロセスは、マッチするルールがルールデータベース内に見つかるまで、又は適用可能なルールがルールデータベース内に存在しないという判定が為されるまで、続行される。

一旦マッチするルールが見つかると、セキュリティ評価モジュール２０２０は、マッチするルールをアプリケーションＸのインストールに関連するデータオブジェクトに適用する。その後、セキュリティ評価を操作開始モジュール２０１０に返す（操作‘７’）。図２１の例において、セキュリティ評価モジュールから操作開始モジュールへの通信内容は、アプリケーションＸのインストールに関連するデータオブジェクトが、ルールデータベース内に格納されているセキュリティポリシーに適合することが判明したため、アプリケーションＸをインストールしても問題のないことを示している。

アプリケーションＸが、セキュリティ評価モジュール２０２０によって遂行されたセキュリティ評価に通過したことを知ると即座に、プロセッサ２０４０は、アプリケーションＸのインストールの処理を続行すべきかどうかを判定する。セキュリティ評価モジュールによって為されるセキュリティ評価に加えて、幾つかの実施形態において、プロセッサ２０４０はアプリケーションＸがタグ付けされているかどうかを考慮する。プロセッサはアプリケーションＸのインストールの処理を続行しても問題のないことを決定した場合、コマンドをインストールモジュール２０６０に送信し、アプリケーションＸのインストールを起動する（操作‘８’）。コンテンツを開くモジュール２０７０の周囲にある点線は、このモジュールがこの操作に関与していないことを示す。

図２２は、オペレーティングシステム２０００において文書を開く操作のデータフロー図を示したものである。操作開始モジュール２０１０に対しデータファイルＸを開くよう要求したとき（操作‘１’）に、操作要求モジュール２００５において、操作が開始する。その後、プロセッサ２０４０は、データファイルＸがタグ付けされているかどうかを尋ねるコマンドをタグ識別モジュール２０５０に送信する（操作‘２’）。データファイルＸが外部ソースに由来する（例えば、隔離ビットを有する）ものとしてタグ付けされている場合、タグ識別モジュール２０５０は確認をプロセッサ２０４０に送信し（操作‘３’）、プロセッサはセキュリティ評価を行うようにセキュリティ評価モジュール２０２０に対し要求する（操作‘４’）。他方、データファイルＸがタグ付けされていない場合、又はデータファイルＸが、以前に評価されたものとしてタグ付けされている場合、幾つかの実施形態において、プロセッサ２０４０はセキュリティ評価モジュール２０２０に対しセキュリティ評価を遂行するよう要求しない。幾つかの実施形態において、データファイルＸが、以前のセキュリティ評価に失敗したものとしてタグ付けされている場合、プロセッサ２０４０は、セキュリティ評価モジュール２０２０を関与させることなしに、ファイルを開くプロセスを直ちに終了できる。その逆に、データファイルＸが、以前のセキュリティ評価に通過したものとしてタグ付けされている場合、幾つかの実施形態において、プロセッサ２０４０は、セキュリティ評価モジュール２０４０を関与させることなしに、データファイルを開くことの続行を直ちに許可できる。

セキュリティ評価要求が行われた場合、セキュリティ評価モジュール２０２０は続いて、ルールデータベース２０３０に対してクエリを実行する（操作‘５’）。ルールデータベース２０３０は、そのデータベース内のルール又は命令をセキュリティ評価モジュール２０２０に供給する（操作‘６’）。マッチするルールがルールデータベース内に見つかるまで、又は適用可能なルールがルールデータベース内に存在しないという判定が為されるまで、セキュリティ評価モジュール２０２０とルールデータベース２０３０との間のこのクエリプロセスが続行される。

一旦マッチするルールが見つかると、セキュリティ評価モジュール２０２０は、マッチするルールを、データファイルＸを開くことに関連するデータオブジェクトに適用する。次いで、セキュリティ評価を操作開始モジュール２０１０に返す（操作‘７’）。図２２の例において、データファイルＸはルールデータベース内に格納されているセキュリティポリシーに適合することが判明しているため、セキュリティ評価モジュールから操作開始モジュールに返された通信は、データファイルＸを開いても問題のないことを示す。

プロセッサ２０４０は、セキュリティ評価モジュール２０２０によって遂行されたセキュリティ評価をデータファイルＸが通過したことを知ると即座に、データファイルＸを開くことを続行すべきかどうかを判定する。セキュリティ評価モジュールによって為されたセキュリティ評価に加えて、幾つかの実施形態においてはまた、プロセッサ２０４０はデータファイルＸがタグ付けされているかどうかを考慮する。プロセッサがデータファイルＸを開くことに進んでも問題がないと判断した場合、プロセッサはコンテンツを開くモジュール２０７０にコマンドを送信して、データファイルＸを開くことを開始する（操作‘８’）。インストールモジュール２０６０の周囲の点線は、この操作にインストールモジュール２０６０が関与していないことを示す。

図２０〜２２は、データオブジェクトがインターネットなどの外部ソースに由来するものであるとしてタグ付けされているかどうかを判定する操作開始モジュール２０１０を具備する、オペレーティングシステム２０００を示している。オペレーティングシステム２０００の操作開始モジュール２０１０はまた、操作を続行すべきかどうかをタグに基づいて判定する。ルールデータベース内に格納されているルールは、タグを考慮しないし処理もしない。一方、他の幾つかの実施形態において、オペレーティングシステムのルールデータベースには、タグを識別し、識別されたタグに基づいてセキュリティ評価を行うルールが含まれる。

一部の実施形態に関し、ダウンロードされたデータオブジェクトに関連付けられたタグを処理するためのルールを含むルールデータベースを具備するオペレーティングシステム２３００を、図２３に示す。そのような幾つかの実施形態において操作開始モジュールは、要求された操作に関連付けられたデータオブジェクトのタグをチェックしない。オペレーティングシステム２０００と同様、オペレーティングシステム２３００は、操作要求モジュール２３０５とセキュリティ評価モジュール２３２０とルールデータベース２３３０と操作開始モジュール２３１０とを含む。オペレーティングシステムはまた、インストールモジュール２３６０と、コンテンツを開くモジュール２３７０とを含む。

操作開始モジュール２３１０は、操作要求モジュール２３０５から操作の要求を受け取り、セキュリティ評価モジュール２３２０に対しセキュリティ評価の要求を行う。一方、操作開始モジュール２０１０とは異なり、操作開始モジュール２３１０は、ダウンロードタグのチェックを行わない。

セキュリティ評価モジュール２３２０は、操作開始モジュール２３１０からセキュリティ評価の要求を受け取り、ルールデータベースに対してクエリを実行し、各セキュリティ評価要求に関連付けられているデータオブジェクトにマッチするルールを探す。

ルールデータベース２３３０には、セキュリティ評価を遂行するためのルールが格納される。また、ルールデータベース２３３０は、ルールデータベース２０３０とは異なり、タグ付けされているかどうか確認する、データオブジェクトを分析するためのルールを含む。データオブジェクトがタグ付けされている場合、幾つかの実施形態は次に、データオブジェクトに対しセキュリティ評価を遂行し、要求された操作を承認／不承認するために、ルールデータベース内のルールを適用することに進む。第ＩＩ節で先に述べたように、幾つかの実施形態において、ルールデータベース２３３０は、権限テーブル及びキャッシュテーブルの両方を含む。例えば、隔離ビットを有するために以前のセキュリティ評価で不承認されたデータオブジェクトは、データオブジェクトを不承認するアクションフィールドを備えるキャッシュエントリを有し得る。

ＩＶ．文書のセキュリティ評価
データオブジェクトのソースを識別するための署名は、部分的にはデータオブジェクトのコンテンツに基づいて導出されるため、データオブジェクトが改ざんされたかどうかを調べる目的に署名を使用できる。これはまた、コンテンツがユーザによってしばしば変更されるデータオブジェクト（例えば、文書）は、自身の署名を有し得ないことも意味する。一方、データファイルは署名を含む証明書を保持できる構造（例えば、アーカイブ）内に配置できる。そのような署名を使用することで、構造内のデータファイルのソースを安全に識別することができる。幾つかの実施形態において、オペレーティングシステムは、アーカイブ構造内に埋め込まれた証明書のＩＤに基づいて文書又はデータファイルを承認又は不承認するルールを、ルールデータベース内に含む。これらの実施形態の幾つかは、承認済みアーカイブ内の文書も同様に承認されるものと見なす。

図２４は、証明書を有するデータアーカイブを受け取って格納するコンピュータ２４００を示したものである。その後、コンピュータ２４００のオペレーティングシステムで（署名付き）証明書を使用することによって、アーカイブ内のコンテンツのソースを安全に識別できる。図示するように、コンピュータ２４００は、記憶装置２４１０と、コンピュータ２４００上で現在実行されているアプリケーション２４３０と、ネットワークインターフェース２４４０と、ユーザインターフェース（ＵＩ）モジュール２４５０と、を含む。ＵＩモジュール２４５０は、入力デバイスドライバ２４６０及び表示モジュール２４７０を介したユーザとの通信を制御する。

ネットワークインターフェース２４４０は、ネットワークを介したコンピュータ２４００と外界との間の通信インターフェースを提供する。ネットワークを利用することによって、コンピュータ２４００はインターネット経由で通信ができ、他のコンピュータからデータアーカイブ２４８１〜２４８４などのデータオブジェクトにアクセスできる。これらのアーカイブのコンテンツは、テキストファイル、ワードプロセッサ文書、スプレッドシート、メディアファイルなどであり得る。これらのアーカイブのコンテンツはまた、実行可能アプリケーション又はアプリケーションインストールファイルであり得る。これらのデータアーカイブの一部又は全部が、それらのソースを識別する署名付き証明書を有する。データアーカイブは、１個のコンテンツ（データアーカイブ２４８１など）又は複数個のコンテンツ又はファイル（データアーカイブ２４８４など）を含み得る。図には示してないが、コンピュータ２４００はまた、外部フラッシュドライブなどの他のデータ通信手段を介して他のコンピュータからデータアーカイブにアクセスすることもできる。

アプリケーション２４３０は、オペレーティングシステムを介してコンピュータ２４００上で現在実行されているプログラム又は一連のプロセスである。アプリケーション２４３０は、インターネットブラウザ、ワードプロセッサ、ビデオゲーム、メディア編集アプリケーション、又はコンピュータ２４００上で動作可能な任意のプログラムであり得る。アプリケーション２４３０は、ネットワークインターフェース２４４０を介してインターネットからデータアーカイブ２４８１〜２４８４をダウンロードすることを含む、インターネットとの通信を必要とする操作を実行できる。

一旦データアーカイブがダウンロードされた後、このダウンロードされたファイルがアプリケーション２４３０によって記憶装置２４１０内に格納される。データアーカイブを記憶装置２４１０に格納する操作は、上で図１９を参照しながら説明したように、タグ付き又は隔離データの格納操作と類似している。記憶装置２４１０にはデータアーカイブが格納される。一旦データアーカイブが格納された後は、署名を認証しデータアーカイブ内に埋め込まれた証明書を調べることによって、オペレーティングシステムはセキュリティ評価を遂行できる。

図２５は、データアーカイブ内の証明書に基づいてデータファイル又は文書のセキュリティ評価を行うためのルールがルールデータベース内に含まれているオペレーティングシステムを示したものである。具体的には、図２５は、オペレーティングシステム２５００内でデータファイルを開くための要求の例を示している。データファイルはデータアーカイブ内に埋め込まれている。

オペレーティングシステム２５００は、操作要求モジュール２５０５と、セキュリティ評価モジュール２５２０と、ルールデータベース２５３０と、操作開始モジュール２５１０と、コンテンツを開くモジュール２５７０と、を含んで構成される。オペレーティングシステム２５００はまた、データアーカイブ２５８０を含む幾つかのデータアーカイブが格納されている記憶装置２５６０にアクセスできる。幾つかの実施形態において、記憶装置２５６０は、図２４の記憶装置２４１０を具含む。記憶装置２４１０には、インターネット又は他の外部ソースからダウンロードされたデータアーカイブが格納される。

幾つかの実施形態において、オペレーティングシステム２５００は、図１のオペレーティングシステム１００に類似している。具体的には、操作要求モジュール２５０５は、操作要求モジュール１４０と同様、操作開始モジュール２５１０に対し操作の実行を要求する。操作開始モジュール２５１０は、操作要求モジュール２５０５から要求を受け取り、セキュリティ評価モジュール２５２０に対しセキュリティ評価を行うように要求する。図２５で示される例において、要求はデータアーカイブ２５８０内に埋め込まれている文書又はデータファイルを開くことに対する要求である。操作開始モジュール２５１０は、データアーカイブ２５８０をセキュリティ評価モジュールに渡すことによって、セキュリティ評価モジュール２５２０に対し要求を行う。操作開始モジュール２５１０は、一旦セキュリティ評価モジュール２５２０からの応答を受け取ると、セキュリティ評価に基づいて、コンテンツを開くモジュール２５７０を起動するか又は要求された操作を終了する。

セキュリティ評価モジュール２５２０及びルールデータベース２５３０は、セキュリティ評価モジュール１１０及びルールデータベース１２０と同様の操作を実行する。上の第ＩＩ節で図７〜１７を参照しながら説明したように、幾つかの実施形態において、ルールデータベースは権限テーブル及びキャッシュテーブルの両方を有する。データファイル又は文書のソースを安全に識別するため、セキュリティ評価モジュール２５２０は、ルールデータベース２５３０内に格納されているルールを適用する前に署名を認証する。

コンテンツを開くモジュール２５７０は、図１のコンテンツを開くモジュール１７４に似ている。コンテンツを開くモジュール２５７０は、一旦操作開始モジュール２５１０から起動コマンドを受け取ると、要求されたデータファイルを開くことに進む。図２５の例において、データアーカイブ２５８０内で開くように要求されたデータファイルは、記憶装置２５６０内に格納される。幾つかの実施形態において、データファイルを開くため、コンテンツを開くモジュール２５７０は、アーカイブ構造からデータファイルを抽出し、その後、（例えば、データファイルを開くために必要とされるアプリケーションにデータファイルを送信することによって）データファイルを開く。

一部の実施形態に関し、文書を開く操作のセキュリティ評価を実行するプロセス２６００を、図２６に概念的に示す。具体的には、プロセス２６００は、データアーカイブに埋め込まれている署名付き証明書に基づいてセキュリティ評価の決定を行う目的でオペレーティングシステムによって実行される。

プロセス２６００は、データファイル（又は文書）を開くための要求を受け取ったときに、開始される。（２６１０において）プロセスは、開くように要求された文書を受け取る。続いて、（２６２０において）プロセスは、文書が安全な種類のものかどうかを判定する。幾つかの実施形態において、コンピュータに危害を与える可能性の低い種類の文書又はファイルは、そのソースに関係なく、開くことを許可される。例えば、テキストファイルは安全であると見なされ、署名又は他のソースの識別を必要としない。文書が安全な種類であると見なされる場合、プロセスは２６７０に進み、文書を操作ハンドラ（図２５のコンテンツを開くモジュール２５７０など）に渡す。文書が安全な種類であると見なされない場合、プロセスは２６３０に進む。幾つかの実施形態において、実行可能な文書は安全であると見なされない。幾つかの実施形態において、或る種類の非実行可能文書は、それらの文書を開いて使用するアプリケーションを介してコンピュータに危害を与える可能性のある悪質なコードを保持し得るため、そのような非実行可能文書に対するソース検証もまた必要になる。

次に、（２６３０において）プロセスは文書がアーカイブ内にあるかどうかを判定する。上述したように、データファイル又は文書によっては、ソースを識別する署名を有さないが、署名を保持するアーカイブ構造内にデータファイルを配置できるものもある。一方、幾つかの実施形態において、或る種の文書は、アーカイブに格納されずに、自身の署名を含み得る（例えば、滅多に変更されない文書は、そのファイルが改ざんされたかどうか検査する署名を保持し得る）。文書がアーカイブ内にない場合、プロセス２６００は２６５０に進む。それ以外の場合、プロセスは２６４０に進み、それ自体で文書のセキュリティ評価を遂行する。

２６４０において、プロセスは文書自身の証明書に基づいて、セキュリティ評価を遂行する。操作は、文書の証明書内に埋め込まれている文書の署名の認証のほか、証明書内の他の情報に基づく追加のセキュリティ評価を含む。幾つかの実施形態において、プロセスはルールデータベースに対してクエリを実行し、文書に対しセキュリティ評価を行う際に使用できるマッチするルールを探す。この操作は、幾つかの実施形態において、文書にコード要件を適用することを含む。コード要件は、文書内に埋め込まれている証明書を調べ、かつソースが信頼できるものかどうかをチェックするための命令を含み得る。プロセスはセキュリティ評価の実行後に、（２６６０において）マッチするルールに基づいて、開く対象の文書を承認するかどうかを判定する。その場合、（２６７０において）プロセスは、操作ハンドラ（図２５のコンテンツを開くモジュール２５７０など）に開くために文書を渡す。それ以外の場合、プロセスは終了する。

２６５０において、プロセスはアーカイブの証明書に基づいてセキュリティ評価を実行する。この操作は、アーカイブの証明書内に埋め込まれている署名の認証のほか、証明書内の他の情報に基づく追加のセキュリティ評価も含む。幾つかの実施形態において、プロセスはルールデータベースに対してクエリを実行し、アーカイブに対するセキュリティ評価を行う際に使用できるマッチするルールを探す。幾つかの実施形態において、この操作はコード要件をアーカイブに適用することを含む。コード要件は、アーカイブ内の証明書を調べてソースが信頼できるものかどうかをチェックする命令を含み得る。その後、プロセスは（２６６０において）マッチするルールに基づいて、アーカイブ、更にはアーカイブ内にある全ての文書を開くために承認するかどうかを判定する。その場合、プロセスは（２６７０において）文書を操作ハンドラ（図２５のコンテンツを開くモジュール２５７０など）に開くために渡す。それ以外の場合、プロセスは終了する。

Ｖ．電子システム
前述の機能及びアプリケーションの多くは、コンピュータ可読記憶媒体（コンピュータ可読媒体とも呼ばれる）に記録される命令セットとして指定されるソフトウェアプロセスとして実現される。これらの命令が、１つ以上の計算又は処理ユニット（例えば、１つ以上のプロセッサ、プロセッサのコア、又は他の処理ユニット）によって実行されるとき、それらの命令は、処理ユニットに、命令に示されたアクションを実行させる。コンピュータ可読媒体の例には、ＣＤ−ＲＯＭ、フラッシュドライブ、ランダムアクセスメモリ（ＲＡＭ）チップ、ハードディスク、消去可能プログラム可能な読み出し専用メモリ（ＥＰＲＯＭ）、電気的消去可能プログラム可能な読み出し専用メモリ（ＥＥＰＲＯＭ）などがあるが、これらに限定されない。コンピュータ可読媒体は、無線によって又は有線接続により進行する搬送波及び電子信号を含まない。

この明細書では、用語「ソフトウェア」は、プロセッサによって処理するためにメモリに読み込むことができる、読み出し専用メモリ内に存在するファームウェア又は磁気記憶装置に記憶されたアプリケーションを含む。また、幾つかの実施形態において、複数のソフトウェア発明は、別個のソフトウェア発明をそのままにしながら、より大きいプログラムの下位区分として実施されてもよい。幾つかの実施形態において、複数のソフトウェア発明を別個のプログラムとして実行することもできる。最後に、本明細書で述べたソフトウェア発明を一緒に実行する別個のプログラムの如何なる組み合わせも本発明の範囲内である。幾つかの実施形態において、ソフトウェアプログラムは、１つ以上の電子システム上で動作するようにインストールされたとき、ソフトウェアプログラムの動作を実行し行う１つ以上の特定のマシン実装を定義する。

図２７は、本発明の幾つかの実施形態が実現される電子システム２７００を概念的に示す。電子システム２７００は、コンピュータ（例えば、デスクトップコンピュータ、パーソナルコンピュータ、タブレットコンピュータなど）、電話、ＰＤＡ、又は他の種類の電子装置でよい。そのような電子システムは、様々なタイプのコンピュータ可読媒体、及び様々な他のタイプのコンピュータ可読媒体のためのインターフェースを含む。電子システム２７００は、バス２７０５、処理ユニット２７１０、グラフィクス処理ユニット（ＧＰＵ）２７１５、システムメモリ２７２０、ネットワーク２７２５、読み出し専用メモリ２７３０、永久記憶装置２７３５、入力装置２７４０及び出力装置２７４５を含む。

バス２７０５は、電子システム２７００の多数の内部装置を通信可能に接続する全てのシステムバス、ペリフェラルバス及びチップセットバスを集合的に表す。例えば、バス２７０５は、処理ユニット２７１０を、読み出し専用メモリ２７３０、ＧＰＵ２７１５、システムメモリ２７２０、及び永久記憶装置２７３５と通信可能に接続する。

これらの様々なメモリユニットから、処理ユニット２７１０は、本発明のプロセスを実行するために実行すべき命令及び処理すべきデータを検索する。処理ユニットは、異なる実施形態において、シングルプロセッサ又はマルチコアプロセッサでよい。幾つかの命令は、ＧＰＵ２７１５に渡され、ＧＰＵ２７１５によって実行される。ＧＰＵ２７１５は、様々な計算をオフロードしたり、処理ユニット２７１０によって提供された画像処理を補完したりすることができる。幾つかの実施形態において、そのような機能は、ＣｏｒｅＩｍａｇｅのカーネルのシェーディング言語を使用して提供されてもよい。

読み出し専用メモリ（ＲＯＭ）２７３０は、処理ユニット２７１０及び電子システムの他のモジュールによって必要とされる静的データ及び命令を格納する。他方、永久記憶装置２７３５は、読み書きメモリ装置である。この装置は、電子システム２７００がオフででも、命令及びデータを格納する不揮発性メモリユニットである。本発明の幾つかの実施形態は、永久記憶装置２７３５として大容量記憶装置（磁気又は光ディスク、及びその対応するディスクドライブなど）を使用する。

他の実施形態は、永久記憶装置としてリムーバブル記憶装置（フロッピディスク、フラッシュメモリデバイスなど、及びその対応するディスクドライブ）を使用する。永久記憶装置２７３５と同様に、システムメモリ２７２０は、読み書きメモリ装置である。しかしながら、記憶装置２７３５と異なり、システムメモリ２７２０は、ランダムアクセスメモリなどの揮発性読み書きメモリである。システムメモリ２７２０は、実行時間にプロセッサが必要とする命令及びデータのうちの幾つかを格納する。幾つかの実施形態において、本発明のプロセスは、システムメモリ２７２０、永久記憶装置２７３５、及び／又は読み出し専用メモリ２７３０に格納される。例えば、様々なメモリユニットは、幾つかの実施形態によれば、マルチメディアクリップを処理する命令を含む。これらの様々なメモリユニットから、処理ユニット２７１０はいつかの実施形態のプロセスを実行するために実行する命令及び処理するデータを取り出す。

バス２７０５は、また、入力装置２７４０及び出力装置２７４５に接続する。入力装置２７４０によって、ユーザは電子システムに情報を伝達しコマンドを選択することができる。入力装置２７４０には、英数字キーボード及びポインティングデバイス（「カーソル制御デバイス」とも呼ばれる）、カメラ（例えば、ウェブカメラ）、音声コマンドを受け取るマイクロフォン又は類似の装置などが挙げられる。出力装置２７４５は、電子システムによって生成された画像を表示するか、又はデータを他の方法で出力する。出力装置２７４５には、プリンタ、陰極線管（ＣＲＴ）又は液晶ディスプレイ（ＬＣＤ）などのディスプレイ装置、並びにスピーカ又は類似のオーディオ出力装置が挙げられる。幾つかの実施形態には、入力装置と出力装置との両方として機能するタッチスクリーンなどのデバイスを含む。

最後に、図２７に示されたように、バス２７０５も、ネットワークアダプタ（図示せず）を介して電子システム２７００をネットワーク２７２５に結合する。このように、コンピュータは、コンピュータのネットワークの一部（例えば、ローカルエリアネットワーク（「ＬＡＮ」）、広域ネットワーク（「ＷＡＮ」）、イントラネット、又はインターネットなどのネットワークのネットワーク）であり得る。電子システム２７００のいずれか又は全てのコンポーネントが、本発明で使用されてもよい。

幾つかの実施形態は、マイクロプロセッサ、マシン可読又はコンピュータ可読媒体（あるいは、コンピュータ可読記憶媒体、マシン可読媒体又はマシン可読記憶媒体と呼ばれる）にコンピュータプログラム命令を記憶する記憶装置及びメモリなどの電子構成要素を含む。そのようなコンピュータ可読媒体の幾つかの例には、ＲＡＭ、ＲＯＭ、読み出し専用コンパクトディスク（ＣＤ−ＲＯＭ）、追記型コンパクトディスク（ＣＤ−Ｒ）、書き換え可能コンパクトディスク（ＣＤ−ＲＷ）、読み出し専用多目的ディスク（例えば、ＤＶＤ−ＲＯＭ、２層ＤＶＤ−ＲＯＭ）、様々な記録可能／書き換え可能ＤＶＤ（例えば、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷなど）、フラッシュメモリ（例えば、ＳＤカード、ミニＳＤカード、マイクロＳＤカードなど）、磁気及び／又はソリッドステートハードディスク、読み出し専用記録可能Ｂｌｕ−ｒａｙ（登録商標）ディスク、超高密度光ディスク、任意の他の光学又は磁気メディア、及びフロッピディスクが挙げられる。コンピュータ可読媒体は、少なくとも１つの処理ユニットによって実行可能で、様々な操作を実行するための命令セットを含むコンピュータプログラムを格納してもよい。コンピュータプログラム又はコンピュータコードの例には、コンパイラによって作成されるようなマシンコード、及びインタープリタを使用してコンピュータ、電子構成要素又はマイクロプロセッサによって実行される高レベルコードを含むファイルが挙げられる。

上記の考察は、主に、ソフトウェアを実行するマイクロプロセッサ又はマルチコアプロセッサを参照しているが、幾つかの実施形態は、特定用途向け集積回路（ＡＳＩＣ）又はフィールドプログラマブルゲートアレイ（ＦＰＧＡ）などの１つ以上の集積回路によって実行される。幾つかの実施形態において、そのような集積回路は、回路自体に格納された命令を実行する。更に、幾つかの実施形態は、プログラマブルロジックデバイス（ＰＬＤ）、ＲＯＭ、又はＲＡＭデバイスに格納されたソフトウェアを実行する。

本出願のこの明細書及びクレームで使用されるとき、用語「コンピュータ」、「サーバ」、「プロセッサ」及び「メモリ」は全て、電子又は他の技術装置を参照する。これらの用語は、人々又は人々のグループを含まない。規定のため、用語「ディスプレイ又は表示」は、電子システム上の表示を意味する。本出願のこの明細書及びクレームで使用されるとき、用語「コンピュータ可読媒体」、「コンピュータ可読媒体」、及び「マシン可読媒体」は、コンピュータによって読み出し可能な形式で情報を記憶する有形な物理的物体に完全に制限される。これらの用語は、無線信号、有線でダウンロードされた信号、及び他の暫時信号を除外する。

本発明を多数の特定の詳細に関して述べたが、当業者は、本発明を、本発明の趣旨から逸脱しない他の特定の形式で実施できることを理解するであろう。更に、少なくとも幾つかの図（図２、図３、図１３、図１７、図１８及び図２６を含む）は、プロセスを概念的に示す。これらのプロセスの具体的な操作は、図示され記述された厳密な順序で実行されなくてもよい。具体的な操作は、１つの連続した一連の操作で実行されなくてもよく、様々な具体的な操作が、異なる実施形態で実行されてもよい。更に、プロセスは、幾つかのサブプロセスを使用して、又はより大きいマクロプロセスの一部として実施されてもよい。したがって、当業者は、本発明が、以上の実例となる詳細によって制限されず、添付の特許請求の範囲によって定義されることを理解するであろう。

Claims (20)

1. 一連の処理ユニットと、
   オペレーティングシステムを格納する機械可読媒体と、
   を含んで構成される電子デバイスであって、
   前記オペレーティングシステムが
   文書及び前記文書に関連付けられているアプリケーションを開くコマンドを受信するための操作要求モジュールと、
   前記受信されたコマンドに基づいてセキュリティ評価を要求するための操作開始モジュールであって、前記要求が、
   （ｉ）前記アプリケーションについてセキュリティ評価がまだ遂行されていない場合、前記文書と前記アプリケーションに関連付けられている複数の種々の操作とに、
   （ｉｉ）前記文書を開く前記コマンドを受信する前に前記アプリケーションのセキュリティ評価が既に遂行されている場合、前記文書に、
   関連付けられている一連のデジタルオブジェクトを含む、操作開始モジュールと、
   前記一連のデジタルオブジェクトがセキュリティポリシーを遵守しているかどうかを評価するためのセキュリティ評価モジュールと、
   を具備する電子デバイス。
2. 前記アプリケーションについてセキュリティ評価がまだ遂行されていない場合、前記一連のデジタルオブジェクトが、前記文書に関連付けられているデジタルオブジェクトの第１のサブセットと、前記複数の種々の操作に関連付けられているデジタルオブジェクトの第２のサブセットと、を具備する、請求項１に記載の電子デバイス。
3. 前記第１及び第２のサブセットが前記セキュリティポリシーに適合している場合に、前記操作開始モジュールが前記文書を開くこと及び前記アプリケーションを起動することを開始する、請求項２に記載の電子デバイス。
4. 前記セキュリティ評価モジュールが、アプリケーションプログラミングインターフェース（ＡＰＩ）を使用して前記要求されたセキュリティ評価を遂行するセキュリティフレームワークの一部である、請求項１に記載の電子デバイス。
5. 前記複数の操作が、前記オペレーティングシステムを実行しているコンピュータ内に前記アプリケーションをインストールすることを含む、請求項１に記載の電子デバイス。
6. 前記セキュリティ評価モジュールが、特定の操作に関連付けられているデジタルオブジェクトのサブセットに必須とされる一連の特徴を指定するコード要件を検査することによって、前記特定の操作に対するセキュリティポリシーを評価する、請求項１に記載の電子デバイス。
7. 前記オペレーティングシステムが、前記セキュリティポリシーに関連付けられている複数の命令セットを格納するデータベースを更に具備し、前記セキュリティ評価モジュールが、特定の操作とマッチする命令セットを前記データベースから取り出すことによって、前記特定の操作に関連付けられている前記セキュリティポリシーを判定する、請求項１に記載の電子デバイス。
8. 前記データベースが権限テーブルとキャッシュテーブルとを具備し、前記特定の操作とマッチする前記命令セットを前記データベースから取り出すことが、前記権限テーブル内のマッチするエントリを検索する前に前記キャッシュテーブル内のマッチするエントリを検索することを含む、請求項７に記載の電子デバイス。
9. デバイスの少なくとも１つの処理ユニットによって実行されたときに、オペレーティングシステム内でセキュリティ評価を提供するプログラムであって、前記プログラムが、
   前記デバイス上で実行されているアプリケーションに関連付けられた文書を開くコマンドを受信し、
   （ｉ）セキュリティフレームワークがまだ前記アプリケーションのセキュリティ評価を遂行していなかった場合は前記文書及び前記アプリケーションに関して、
   （ｉｉ）前記文書を開く前記コマンドを受信する前に前記セキュリティフレームワークが前記アプリケーションのセキュリティ評価を遂行していた場合は前記文書に関して、
   セキュリティ評価を遂行するように前記セキュリティフレームワークに対し要求し、
   前記セキュリティ評価に基づいて前記文書を開くことを決定する
   ための命令セットを含む、プログラム。
10. 前記セキュリティ評価が、前記文書に関連付けられているデジタルオブジェクトに必須とされる一連の特徴を指定するコード要件に基づくものである、請求項９に記載のプログラム。
11. 前記プログラムが、前記セキュリティ評価を遂行するための複数の命令セットを格納するデータベースを保守管理するための命令セットを更に含み、前記セキュリティフレームワークが、前記文書とマッチする命令セットを前記データベースから取り出すことによって、前記文書に関連付けられているセキュリティポリシーを判定する、請求項９に記載のプログラム。
12. 前記データベースが権限テーブルとキャッシュテーブルとを具備し、前記文書とマッチする前記命令セットを前記データベースから取り出すことが、前記権限テーブル内のマッチするエントリを検索する前に前記キャッシュテーブル内のマッチするエントリを検索することを含む、請求項１１に記載のプログラム。
13. 前記文書の前記セキュリティ評価が、前記文書が信頼済みソースに由来するものかどうかを判定することを含む、請求項９に記載のプログラム。
14. オペレーティングシステムによって実行される操作のセキュリティを評価する方法であって、
    オペレーティングシステムの内部で実行されているアプリケーションで文書を開くコマンドを受信することと、
    セキュリティフレームワークにアクセスするためのアプリケーションプログラミングインターフェース（ＡＰＩ）を使用して前記文書のセキュリティ評価を要求することと、
    前記アプリケーションが以前に評価されていなかった場合に、前記アプリケーションに対する追加のセキュリティ評価を要求することと、
    前記要求されたセキュリティ評価に基づいて特定の操作を実行するかどうかを判定することと、
    を含む、方法。
15. 前記アプリケーションの前記セキュリティ評価に対する前記要求が、前記アプリケーションの前記セキュリティ評価に対する前記要求に先立つものである、請求項１４に記載の方法。
16. 前記特定の操作が、前記オペレーティングシステム内でのアプリケーションの実行に関連付けられている前記文書を開くことを含む、請求項１４に記載の方法。
17. 前記特定の操作を実行するかどうかを判定することが、前記文書が信頼済みソースに由来するものかどうかを判定することを含む、請求項１４に記載の方法。
18. 前記セキュリティ評価が、前記文書に関連付けられているデジタルオブジェクトに必須とされる一連の特徴を指定するコード要件を検査することによって前記文書に関してセキュリティポリシーを評価することを含む、請求項１４に記載の方法。
19. 前記コード要件が、前記セキュリティポリシーに関連付けられている複数の命令セットを格納するデータベース内に格納されており、前記データベースが権限テーブルとキャッシュテーブルとを含み、前記文書とマッチする前記命令セットを前記データベースから取り出すことが、前記権限テーブル内のマッチするエントリを検索する前に前記キャッシュテーブル内のマッチするエントリを検索することを含む、請求項１８に記載の方法。
20. 前記文書とマッチする命令セットをデータベースから取り出すことによって、前記文書に関連付けられているセキュリティポリシーを判定することを更に含む、請求項１４に記載の方法。

Images