(57)【要約】      （修正有）【課題】ソフトウェア開発および配送プロセスの複数のレベルの間でセキュリティ許可の割り当てを分配する態様で、セキュリティ許可を定義する方法を提供する。【解決手段】開発者は、特定のアプリケーションに対する許可を、メタデータとして定義して、アプリケーションと関連して保存される許可メタデータ・ファイル内に許可を保存する。署名者は、アプリケーション及び許可ファイルを検査して、ファイル内の適切な許可レベルが適正に設定されているとき、アプリケーションを有効にするか、又はアプリケーションに署名する。署名者が、アプリケーションおよび許可ファイル内の許可を有効にした、又は署名したとき、アプリケーションは、許可ファイルの下での最大の許可が付与された状態で、利用者に配布され、又は提供される。利用者は、アプリケーションにポリシー・ファイルを付加することにより、開発者から付与された許可の範囲をさらに制限できる。【選択図】図１
2007265404.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェア・アプリケーションに対応するメタデータ・セキュリティ・パラメータを設定するステップと、
前記アプリケーションおよび前記メタデータ・セキュリティ・パラメータを検証するときに、前記アプリケーションおよび前記メタデータ・セキュリティ・パラメータに安全に署名するステップと、
前記ソフトウェア・アプリケーションの配布者が、前記アプリケーションおよび前記メタデータ・セキュリティ・パラメータの署名者に対して有する信用レベルに対応する配布セキュリティ・パラメータを設定するステップと、
前記メタデータ・セキュリティ・パラメータおよび前記配布セキュリティ・パラメータで表されるセキュリティ・レベルのうち低い方と関連するセキュリティ・レベルで前記アプリケーションを配布するステップとを含む、ソフトウェア・アプリケーションのセキュリティ・パラメータを設定する方法。
【請求項２】
署名者セキュリティ・パラメータを設定するステップをさらに含み、配布の前記セキュリティ・レベルが、前記メタデータ・セキュリティ・パラメータ、前記署名者セキュリティ・パラメータ、および前記配布セキュリティ・パラメータで表されるセキュリティ・レベルのうち大きい方である、請求項１に記載の方法。
【請求項３】
前記メタデータ・セキュリティ・パラメータおよび前記配布セキュリティ・パラメータが、コンピュータ・コードに対するセキュリティ・レベルに対応する、請求項１に記載の方法。
【請求項４】
命令により要求される前記セキュリティ・レベルが、前記配布されるセキュリティ・レベルを超えないことを確保するために、前記ソフトウェア・アプリケーションの命令のランタイム検査を実行するステップをさらに含む、請求項１に記載の方法。
【請求項５】
前記ランタイム検査が、Ｊａｖａ（登録商標）ランタイム・エンジンにより実行される、請求項４に記載の方法。
【請求項６】
前記メタデータ・セキュリティ・パラメータおよび前記配布セキュリティ・パラメータが、Ｊａｖａ（登録商標）セキュリティ・ポリシーに適合している、請求項１に記載の方法。
【請求項７】
前記メタデータ・セキュリティ・パラメータが、前記ソフトウェア・アプリケーションの開発者により定義される、請求項１に記載の方法。
【請求項８】
ソフトウェア・アプリケーションに対応するメタデータ・セキュリティ・パラメータと、
前記ソフトウェア・アプリケーションおよび前記メタデータ・セキュリティ・パラメータを検証する、前記ソフトウェア・アプリケーションに対応する証明書および署名と、
前記ソフトウェア・アプリケーションの配布者が、前記証明書および前記署名を作成した署名者に対して有する信用レベルに対応する配布セキュリティ・パラメータと、
前記メタデータ・セキュリティ・パラメータおよび前記配布セキュリティ・パラメータで表されるセキュリティ・レベルのうち低い方と関連するセキュリティ・レベルで前記アプリケーションを配布するロジックとを含む、ソフトウェア・アプリケーションのセキュリティ・パラメータを設定するシステム。
【請求項９】
前記署名者により定義された署名者セキュリティ・パラメータをさらに含み、配布する前記ロジックが、前記メタデータ・セキュリティ・パラメータおよび前記配布セキュリティ・パラメータで表されるセキュリティ・レベルのうち低い方に、配布の前記セキュリティ・レベルを設定する、請求項８に記載のシステム。
【請求項１０】
前記メタデータ・セキュリティ・パラメータおよび前記配布セキュリティ・パラメータが、コンピュータ・コードに対するセキュリティ・レベルに対応する、請求項８に記載のシステム。
【請求項１１】
命令により要求される前記セキュリティ・レベルが、前記配布されるセキュリティ・レベルを超えないことを確保するために、前記ソフトウェア・アプリケーションの実行中の命令について実行されるランタイム検査をさらに含む、請求項８に記載のシステム。
【請求項１２】
前記ランタイム検査が、Ｊａｖａ（登録商標）ランタイム環境により実行される、請求項１１に記載のシステム。
【請求項１３】
前記メタデータ・セキュリティ・パラメータおよび前記配布セキュリティ・パラメータが、Ｊａｖａ（登録商標）セキュリティ・ポリシーに適合している、請求項８に記載のシステム。
【請求項１４】
前記メタデータ・セキュリティ・パラメータが、前記ソフトウェア・アプリケーションの開発者により定義される、請求項８に記載のシステム。
【請求項１５】
ソフトウェア・アプリケーションに対応するメタデータ・セキュリティ・パラメータと、
前記アプリケーションおよび前記メタデータ・セキュリティ・パラメータを検証するときに、前記アプリケーションおよび前記メタデータ・セキュリティ・パラメータに安全に署名するロジックと、
前記ソフトウェア・アプリケーションの配布者が、前記アプリケーションおよび前記メタデータ・セキュリティ・パラメータの署名者に対して有する信用レベルに対応する配布セキュリティ・パラメータと、
前記メタデータ・セキュリティ・パラメータおよび前記配布セキュリティ・パラメータで表されるセキュリティ・レベルのうち低い方と関連するセキュリティ・レベルで前記アプリケーションを配布するロジックとを含む、アプリケーション開発者により設定されるセキュリティ許可を有する安全なアプリケーションの分配サービス用プログラム。
【請求項１６】
署名者セキュリティ・パラメータをさらに含み、前記アプリケーションを配布する前記ロジックが、前記メタデータ・セキュリティ・パラメータおよび前記配布セキュリティ・パラメータで表されるセキュリティ・レベルのうち低い方のセキュリティ・レベルに、配布のセキュリティ・レベルを適用する、請求項１５に記載のプログラム。
【請求項１７】
前記メタデータ・セキュリティ・パラメータおよび前記配布セキュリティ・パラメータが、コンピュータ・コードに対するセキュリティ・レベルに対応する、請求項１５に記載のプログラム。
【請求項１８】
命令により要求される前記セキュリティ・レベルが、前記配布されるセキュリティ・レベルを超えないことを確保するために、前記ソフトウェア・アプリケーションの命令のランタイム検査を実行するロジックをさらに含む、請求項１５に記載のプログラム。
【請求項１９】
前記ランタイム検査が、Ｊａｖａ（登録商標）ランタイム環境により実行される、請求項１８に記載のプログラム。
【請求項２０】
前記メタデータ・セキュリティ・パラメータが、前記ソフトウェア・アプリケーションの開発者により定義される、請求項１５に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的に、コンピュータ・セキュリティに関し、さらに具体的に述べると、コンピュータ利用技術におけるセキュリティ許可を定義する方法、システム及びプログラムに関する。
【背景技術】
【０００２】
「ウェブ」と呼ばれることもあるインターネットの出現とともに、企業および消費者は、以前は利用できなかったソフトウェア・アプリケーションの開発および配送のための複数のチャンネルを有する。企業体の複数のレベルに渡るアプリケーションの分配は、組織間の信用の問題をもたらす。例えば、企業内でアプリケーションを実装する配布者は、アプリケーションの健全性を検証する署名者を信じなければならず、この署名者もまた、アプリケーションのコードを作る開発者を信じなければならない。ニューヨーク州アーモンクのインターナショナル・ビジネス・マシーンズ社（ＩＢＭ）のような企業は、ソフトウェア・アプリケーションの配布、統合、実行、および管理を容易にするセキュリティ手続きを開発した。
【０００３】
現在、コンピュータ・セキュリティ問題に対する一般的なアプローチの１つは、ランタイム環境におけるアプリケーションの健全性を確保するために、Ｊａｖａ（登録商標）２セキュリティ・モデルを配布することである。Ｊａｖａ（登録商標）２セキュリティの１つの問題は、正確なセキュリティ許可を定義するプロセスが厄介であることである。
【０００４】
ワシントン州レドモンドのマイクロソフト社により発表されたウィンドウズ（登録商標）では、アプリケーション許可は、ゾーンまたはグループに基づいている。異なったセキュリティ・ゾーンが定義されるとともに、特定ゾーン内の主要な決定は、アプリケーションのセキュリティ許可設定に基づいて、特定のアプリケーションを実行するべきかどうかということである。アプリケーションの実行を許可する決定が行われると、通常、稼動するアプリケーションは、ゾーンに対応するすべての許可を取得する。さらに、許可があまりにも細かく分割されているため、セキュリティ・ゾーンはＪａｖａ（登録商標）環境では有用ではない。換言すれば、この細かく分割された、イエスかノーかのアプローチは、アプリケーションを配布するシステム管理者または他の利用者が、詳細なセキュリティ設定情報を使用できることを要求するとともに、利用者が、特定のゾーン内の異なるアプリケーションに対して、異なるレベルのセキュリティを設定することを防止する。
【０００５】
Ｊａｖａ（登録商標）２セキュリティは、セキュリティ・ポリシーを実施するために、許可検査を使用する。Ｊ２ＥＥランタイム環境デフォルトＪａｖａ（登録商標）２セキュリティ・ポリシーは、ランタイム健全性を確保するために、Ｊ２ＥＥアプリケーションに、非常に限定された許可の組を付与する。アプリケーションを配布する利用者は、アプリケーションに対する許可レベルを設定しなければならない。上述したように、このアプローチは、アプリケーションを配布する利用者が、アプリケーションがどのように使用されるべきか、および誰によって使用されるべきかについての詳細な情報を有することを要求する。
【０００６】
アプリケーションを開発して、署名して、配布する責任がある人々の間にセキュリティ・ポリシーの設定を分配するシステムが求められている。各レベルにおいて、作業者は、セキュリティ要求上の異なった見解を有し、分散型アプローチは、各レベルの作業者が彼らの特定のセキュリティ上の問題に対処することを可能にするであろう。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
ソフトウェア開発および配送プロセスの複数のレベル間でセキュリティ許可の割り当てを分配する態様で、コンピュータ利用技術におけるセキュリティ許可を定義する方法を提供する。レベルは、開発者、アプリケーション署名者、およびアプリケーションを配布する作業者を含むが、これらに限らない。許可ファイルを作成することにより、開発者は特定のアプリケーションに適用可能な最大の許可を指定できる。その後署名者は、システムに関する署名者の知識に応じて、アプリケーションの許可をさらに制限できる。最後に、アプリケーションを配布する利用者は、様々な利用者に割り当てられた特定の許可についてのコントロールをアサートすることができる。
【課題を解決するための手段】
【０００８】
開発者は、特定のアプリケーションに対する許可を、アプリケーション内のメタデータとして定義して、アプリケーションと関連して保存される許可メタデータ・ファイル内に許可を保存する。署名者は、アプリケーションおよび許可ファイルを検査して、ファイル内の適切な許可レベルが適正に設定されたことが満たされているとき、アプリケーションを有効にするか、またはアプリケーションに「署名する」。署名者が、アプリケーションおよび許可ファイル内の許可を有効にしたか、または署名したとき、アプリケーションは、許可ファイルの下での最大の許可が付与された状態で、コンピューティング・システム上にアプリケーションをインストールする利用者に配布され、または提供される。配布されたアプリケーションは、メタデータにおいて指定された許可を付与されるが、利用者が署名者と関連づけて、かつポリシー・ファイルにおいて定義した許可に制限される。換言すれば、アプリケーションが実行されるとき、ランタイム検査は、アプリケーションが、アプリケーションを配布する人が署名者に付与した最大の信用に基づいて、署名者により保証されるような許可ファイルと、アプリケーションを配布する作業者により定義されるようなポリシー・ファイルの両方により許可される動作を実行できるだけであることを確保する。
【発明の効果】
【０００９】
開示された技術の１つの利点は、署名者が責任を制限できることである。例えば、署名者が、特定のバンドルがあまり信頼できないと判断するとき、署名者は、狭いセキュリティ範囲の中だけで、バンドルに署名できる。署名者はまた、異なった信用レベルに対して同じ証明書を使用できるため、コンピュータ管理を簡素化できる。さらに、システム管理者または他の利用者は、実行処理に対して必要とされる許可について判断するために、配布の前に許可ファイルを検査することができる。また、クレームされた内容は、システム管理者が特定の署名者が受け取るアプリケーションの最大セキュリティ範囲を制限することを可能とする。
【００１０】
この要約は、クレームされた内容を包括的に説明するものではなく、むしろ、クレームされた内容と関連する機能のうちの、いくつかの簡潔な概説を提供するものである。本発明の他のシステム、方法、機能、特徴、および利点は、後述の図面および詳細な説明を検討すれば、当業者に明らかであり、または明らかになるであろう。
【発明を実施するための最良の形態】
【００１１】
特にウィンドウズ（登録商標）・オペレーティング・システム（ＯＳ）およびＪａｖａ（登録商標）開発環境に関連して説明されるが、クレームされた内容は、フレキシブルなアプリケーション・セキュリティが好ましい任意の情報技術（ＩＴ）システムにおいて実行されうる。コンピューティング技術の当業者は、開示された実施形態が、後述されるコンピューティング環境に加えて、様々なコンピューティング環境と関連性を有することを認識するであろう。さらに、開示された発明の方法は、ソフトウェア、ハードウェア、またはソフトウェアおよびハードウェアの組み合わせで実行されうる。ハードウェア部分は、専用ロジックを用いて実行され、ソフトウェア部分は、メモリに保存されて、マイクロプロセッサ、パーソナル・コンピュータ（ＰＣ）、またはメインフレームのような好適な命令実行システムにより実行されうる。
【００１２】
本明細書の文脈では、「メモリ」または「記録媒体」は、命令実行システム、装置、またはデバイスにより使用する、または命令実行システム、装置、またはデバイスと共に使用する、プログラムおよびデータ、もしくは、プログラムまたはデータを、含む、保存する、通信する、伝搬する、または搬送する任意の手段でありうる。メモリおよび記録媒体は、電子的、磁気的、光学的、電磁気的、赤外線式、または半導体のシステム、装置、もしくはデバイスでありうるが、これらに限らない。また、メモリおよび記録媒体は、例えば、携帯用コンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、消去可能プログラム可能読取り専用メモリ（ＥＰＲＯＭ、またはフラッシュ・メモリ）、および携帯用コンパクト・ディスク読取り専用メモリ、または、プログラムおよびデータ、もしくは、プログラムまたはデータを保存できる他の好適な媒体を含むが、これらに限らない。
【００１３】
クレームされた主題に基づく一実施形態は、ソフトウェア・アプリケーション・セキュリティを実行するプログラムされた方法に関する。本明細書で使用される「プログラムされた方法」という用語は、現在、実行される１つ以上のプロセス・ステップ、あるいは、将来の時点で実行されることが可能な１つ以上のプロセス・ステップを意味すると定義される。プログラムされた方法という用語は、３つの選択的形態を予想する。第１に、プログラムされた方法は、現在、実行されるプロセス・ステップを含む。第２に、プログラムされた方法は、コンピュータにより実行されるとき１つ以上のプロセス・ステップを実行する、コンピュータ命令を具現化するコンピュータ読み込み可能媒体を含む。最後に、プログラムされた方法は、１つ以上のプロセス・ステップを実行するために、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組み合わせでプログラムされたコンピュータ・システムを含む。「プログラムされた方法」という用語は、同時に２つ以上の選択的形態を有するものと解釈されるべきではなく、むしろ、選択的形態の最も本当の意味で解釈されるべきであり、所与の任意の時点において、複数の選択的形態のうち、１つだけが存在することを理解すべきである。
【００１４】
ここで図面を参照すると、図１は、クレームされた内容を組み込んだ例示的コンピューティング・システム・アーキテクチャ１００のブロック図である。クライアント・システム１０２は、共に、コンピューティング・システム１００およびクライアント・システム１０２とのヒューマン・インタラクションを容易にするモニタ１０６、キーボード１０８、およびマウス１１０に結合された中央処理装置（ＣＰＵ）１０４を含む。また、クライアント・システム１０２内に含まれ、かつＣＰＵ１０４に取り付けられているのは、データ記憶構成要素１１２であり、このデータ記憶構成要素１１２は、ＣＰＵ１０４、すなわち内部デバイスに組み込まれてもよく、またはこれに限定されないが、例えば、ユニバーサル・シリアル・バス（ＵＳＢ）ポート（図示しない）のような様々な一般的に利用可能な接続デバイスを用いて、外部からＣＰＵ１０４に取り付けられてもよい。クレームされた内容を組み込んだ例示的コンピュータ・ソフトウェア・アプリケーション１１４を保存するデータ記憶１１２が示されている。アプリケーション１１４は、数個の構成要素、すなわち、コード１１６、許可メタデータ・ファイル１１８、証明書１２０、および署名１２２を含む。また、ポリシー・ファイル１２４がデータ記憶１１２上に保存されている。アプリケーション１１４と関連して示されているが、ポリシー・ファイル１２４は、アプリケーション１１４とは別々に配布されるとともに、アプリケーション１１４に固有のものではない。換言すれば、通常、ポリシー・ファイル１２４は、特定のアプリケーションに対するポリシーではなく、コンピュータ・システムに対するポリシーを定義する。典型的なコンピューティング・システムは、２つ以上のアプリケーションを含むであろうが、便宜上、１つだけを示していることに注目すべきである。構成要素１１８、１２０、１２２、および１２４は、発明の背景において上述したセキュリティ問題に対処する分散型のフレキシブルなセキュリティ・ポリシーを提供するセキュリティ・システムの構成要素を示す。構成要素１１８、１２０、１２２、および１２４は、図２〜図５と共にさらに詳細に後述される。
【００１５】
クライアント・システム１０２およびＣＰＵ１０４は、インターネット１２６に接続され、また、このインターネット１２６は、サーバ・コンピュータ１２８に接続される。この例では、ＣＰＵ１０４およびサーバ１２８は、インターネット１２６を介して結合されて通信を行うが、また、ＣＰＵ１０４およびサーバ１２８は、これに限定されないが、例えば、ローカル・エリア・ネットワーク（ＬＡＮ）（図示しない）のような任意の個数の通信媒体を介して結合されうる。さらに、多数の可能なコンピューティング・システム構成があり、コンピューティング・システム１００は、その１つの簡単な例に過ぎないことに注目すべきである。
【００１６】
図２は、クレームされた内容を使用する、ソリューション、またはアプリケーション開発システム１３０のブロック図である。図１のクライアント・システム１０２、コード１１６、サーバ、または「ステージング・サーバ」１２８が、この図に含まれている。図１と同様に、アプリケーション１１４は、コード１１６、許可メタデータ１１８、証明書１２０、および署名１２２を含む。この図は、開発システム１３０によるアプリケーション１１４の作成を示す。
【００１７】
開発者が、特定のソフト市場にカスタム・ビジネス・ソリューションを提供するこの例において、プロセスは、アプリケーション開発１３２、アプリケーション認証または署名１３４、アプリケーション・ステージング１３６、およびアプリケーション配布１３８の４つの例示的段階に分けて示される。
【００１８】
アプリケーション開発１３２の間に、開発者は、コード１１６を作成して、コード１１６と関連する許可メタデータ・ファイル１１８を定義する。コード１１６は、例示的ファイル、すなわち、ファイル＿１  １４０、およびファイル＿２  １４２を含む。便宜上、ファイル＿１  １４０、およびファイル＿２  １４２は、開発プロセス１３０のうち、１段階の間だけ、コード１１６内に示されているが、ファイル１４０および１４２は、段階１３４、１３６、および１３８を通じても同様にコード１１６の一部であることを理解すべきである。
【００１９】
例示的許可メタデータ・ファイル１１８は、図３と共にさらに詳細に後述される。許可メタデータ・ファイル１１８を使用するプロセスは、図４および図５と共に詳細に後述される。コード１１６の開発は、カスタム・コンピュータ・コードの記述、ならびにサード・パーティのコードおよびソフトウェア製品の組み込みを含みうるが、これらに限らない。換言すれば、コード１１６は、市販の製品であったり、専門技術者により作成されたり、またはサード・パーティ業者により開発された任意の個数の個別構成要素を含みうる。ファイル＿１  １４０、およびファイル＿２  １４２は、２つのこのような構成要素である。ファイル１４０および１４２は、あくまで説明のために使用されたに過ぎず、典型的なアプリケーション１１４および対応するコード１１６は、多数のファイルおよび構成要素を含むであろうことに注目すべきである。便宜上、ファイル＿１  １４０、およびファイル＿２  １４２だけが示されている。
【００２０】
アプリケーション署名１３４の間に、システム管理者のような信頼のある当事者が、コード１１６、および許可メタデータ・ファイル１１８を検査して、セキュリティ要件が満たされているとき、証明書１２０、および対応する署名１２２を付加することにより、コード１１６およびファイル１１８を認証する。認証の前に、付加的なファイル（図示しない）が、コード１１６、および許可メタデータ・ファイル１１８に含まれうる。認証されると、コード１１６、許可メタデータ・ファイル１１８、証明書１２０、および署名１２２は、アプリケーション・パッケージ１４４の一部分となり、証明書１２０および署名１２２を無効にすることなく、変更することができない。換言すれば、コード１１６、もしくはファイル１４０または１４２のような任意の構成要素部分が変更されるとき、新しい証明書１２０および署名１２２を挿入することにより、コード１１６および許可メタデータ・ファイル１１８を再認証しなければならない。したがって、アプリケーション・パッケージ１４４の証明書１２０および署名１２２は、システム管理者または他の認定ユーザが、アプリケーション・パッケージ１４４がセキュリティのために調べられたことを認識して、アプリケーション・パッケージ１４４を配布することを可能とする。
【００２１】
証明書１２０は、システム管理者、他の認定ユーザ、または「署名者」を確認する手段である。証明書１２０は、証明書チェーンを有する署名者に対応する公開鍵を含む。証明書１２０は、署名者のアイデンティティの証拠として、異なったアプリケーションで提示されうる。署名された各アプリケーションは、アプリケーション１１４のようなアプリケーションのコンテンツに基づく、異なった署名１２２、およびアプリケーションに署名するために使用された証明書１２０を有する。実際に、わずかであってもバージョンのコンテンツが異なるため、アプリケーションの異なったバージョンは、異なった署名を有する。したがって、署名１２２は２つの機能を実行し、すなわち、署名１２２は、証明書１２０が署名１２２を作成するために使用されたことを確認するために使用されうるとともに、また、アプリケーション１１４のコンテンツ、および証明書１２０が関連する他の任意のアプリケーションのコンテンツを検証するために使用されうる。セキュリティのためにアプリケーションを検査して、認証して、かつ署名するプロセスは、コンピューティング技術および暗号技術の当業者には、よく知られているはずである。
【００２２】
アプリケーション・ステージング１３６は、最終的なクライアントまたは顧客にアプリケーション・パッケージ１４４を分配するいくつかの方法を示す。このような分配手段の例としては、例えば、クライアント・システム１０２などの顧客システム上にインストールするために、郵送、または別の方法で顧客に配送されるコンパクト・ディスク（ＣＤ）１４６、およびクライアント・システム１０２がアプリケーション・パッケージ１４４のような製品またはソリューションをダウンロードできるステージング・サーバ１２８などがあるが、これらに限らない。コンピューティング技術の当業者は、ＣＤ１４６およびステージング・サーバ１２８の他に、多数の可能な配送選択肢があることを認識するはずである。
【００２３】
アプリケーション配布１３８の間に、クライアント・システム１０２に対する責任を有するシステム管理者または他の作業者が、データ記憶１１２上にアプリケーション・パッケージ１４４をロードする。配布されると、アプリケーション１１４は、多く見てもせいぜい許可メタデータ・ファイル１１８内に指定される許可を付与される。システム管理者、またはアプリケーション１１４を配布する他の利用者は、コード１１６および許可メタデータ・ファイル１１８を検査した後に、管理者が有しうる任意のセキュリティ上の問題に対処するためにポリシー・ファイル１２４を付加する。アプリケーション１１４が実行されるとき、ランタイム検査は、アプリケーション１１４が、署名者により保証されるような許可メタデータ・ファイル１１８と、アプリケーション１１４を配布する作業者により定義されるようなポリシー・ファイル１２４の両方により許可される動作を実行できるだけであることを確保する。このように、段階１３２、１３４、および１３８の作業者は皆、彼らの個々の必要性および関心に基づいて、アプリケーション１１４に付与される最大の許可を管理する。特に、システム管理者は、アプリケーション配布段階１３８の間、アプリケーション署名段階１３４の間に証明書１２０および署名１２２を作成した署名者に管理者が付与した最大の信用に基づいて、アプリケーション１１４を制限できる。例えば、管理者が、特に開発者または署名者を信頼しないとき、それでもなお、アプリケーションは、非常に限られた許可を付与されて、かつ実行することができる。
【００２４】
図３は、図１および図２と共に最初に上述された、クレームされた内容の一実施形態で使用されうる例示的許可メタデータ・ファイル１１８を示す。許可メタデータ・ファイル１１８は、「ファイル」エントリ１５０、「特性」エントリ１５２、および「システム」エントリ１５４を含む。ファイル・エントリ１５０は、コード１１６（図１および図２）と関係がある様々なファイルと関連するアクセス許可を定義し、この例では、両方とも図２と共に上述された、ファイル＿１  １４０、およびファイル＿２  １４２を含む。特性エントリ１５２は、コンピューティング・システムおよびアプリケーション１１４と関連しうる様々な特性に対するアクセス権を定義する。システム・エントリ１５４は、特に、アプリケーション１１４がインストールされるシステムにアクセスするために使用されうる様々なリモート・コンピューティング・デバイスに対するアクセス・パラメータを定義する。下記の例では、アプリケーション１１４は、クライアント・システム１０２上にインストールされて、サーバ１２８からのリモート・アクセスを可能とする。
【００２５】
ファイル・エントリ１５０は、例示的ファイル＿Ａ（図示しない）を参照する第１行「ｊａｖａ．ｉｏ．ＦｉｌｅＰｅｒｍｉｓｓｉｏｎ  “ＦＩＬＥ＿Ａ”  ‘ｒｅａｄ，ｗｒｉｔｅ’」、および例示的データ・ファイル＿Ｂ（図示しない）を参照する第２行「ｊａｖａ．ｉｏ．ＦｉｌｅＰｅｒｍｉｓｓｉｏｎ  “ＦＩＬＥ＿Ｂ”  “ｒｅａｄ，ｅｘｅｃｕｔｅ”」の２つの例示的な行を含む。ファイル・エントリ１５０内の行のシンタックスは、第１のエントリ、例えば、「ｊａｖｅ．ｉｏ．ＦｉｌｅＰｅｒｍｉｓｓｉｏｎｓ」は、許可の種類を指定し、第２のエントリ、例えば、「ＦＩＬＥ＿Ａ」は、許可が適用される組織名であり、第３のエントリ、例えば、「ｒｅａｄ，ｗｒｉｔｅ」は、対応するファイルについて許された許可された動作を指定する。例えば、第１の行で、「ｊａｖａ．ｉｏ．ＦｉｌｅＰｅｒｍｉｓｓｉｏｎ」というフレーズは、エントリがｊａｖａ入出力（Ｉ／Ｏ）許可を参照することを指定する。「ＦＩＬＥ＿Ａ」という用語は、対応するデータ・ファイルを指定する。「ｒｅａｄ，ｗｒｉｔｅ」というフレーズは、ファイル＿Ａが、利用者またはアプリケーションにより、読み出されかつ書き込まれうることを示す。簡単に述べると、ファイル＿Ａは、利用者およびアプリケーションが読み出しかつ書き込むことができる普通のファイルとしてリストにされる。
【００２６】
特性エントリ１５２は、１つの例示的な行「ｊａｖａ．ｉｏ．ＰｒｏｐｅｒｔｙＰｅｒｍｉｓｓｉｏｎ  “ｓｏｍｅ．ｐｒｏｐｅｒｔｙ．ｎａｍｅ”  “ｒｅａｄ”」を含む。ファイル・エントリ１５０と同様に、第１のフレーズ、例えば、「ｊａｖａ．ｉｏ．ＰｒｏｐｅｒｔｙＰｅｒｍｉｓｓｉｏｎ」は、許可の種類を指定し、第２のエントリ、例えば、「ｓｏｍｅ．ｐｒｏｐｅｒｔｙ．ｎａｍｅ」は、許可が適用される組織名であり、第３のエントリ、例えば、「ｒｅａｄ」は、対応する特性について許された許可された動作を指定する。換言すれば、行「ｊａｖａ．ｉｏ．ＰｒｏｐｅｒｔｙＰｅｒｍｉｓｓｉｏｎ  “ｓｏｍｅ．ｐｒｏｐｅｒｔｙ．ｎａｍｅ”  “ｒｅａｄ”」は、エントリが特性に対するｊａｖａ入出力（Ｉ／Ｏ）許可を参照することを指定する。「ｓｏｍｅ．ｐｒｏｐｅｒｔｙ．ｎａｍｅ」という用語は、定義された特性を指定する。「ｒｅａｄ」というフレーズは、対応する特性が、利用者またはアプリケーションにより、読み出されうることを示す。
【００２７】
システム・エントリ１５４は、１つの例示的な行「ｊａｖａ．ｎｅｔ．ＳｏｃｋｅｔＰｅｒｍｉｓｓｉｏｎ  “ｗｗｗ．ｉｂｍ．ｃｏｍ：８０”  “ｃｏｎｎｅｃｔ，ａｃｃｅｐｔ”」を含む。システム・エントリ１５４内の行のシンタックスは、ファイル・エントリ１５０および特性エントリ１５２のシンタックスと類似している。例えば、システム・エントリ１５４におけるこの例の行の１つは、この例では、“ｗｗｗ．ｉｂｍ．ｃｏｍ”の、ホスト・ポート８０が、接続と連結してかつ受容することが許可されることを示す。
【００２８】
ファイル１１８は、クレームされた内容を実行するために使用されうる許可メタデータ・ファイルの一例に過ぎないことを理解すべきである。コンピューティング技術の当業者は、本明細書に説明されたシステムに組み込まれうるエントリには、多数のフォーマットおよび種類があることを理解すべきである。エントリ１５０、１５２、および１５４のエントリのフォーマットおよび意味は、あくまで例として使用されているに過ぎない。さらに、シンタックスおよび意味は、コンピューティング技術の当業者には、よく知られているはずである。
【００２９】
図４は、クレームされた内容と関連するアプリケーション開発および配布（Ｄ＆Ｄ）プロセス２００のフローチャートである。開示された技術に基づき、プロセス２００と関連する動作が、アプリケーション開発および配布プロセス１３０（図２）の数人の作業者の間に分配される。例えば、アプリケーションは、送信前に開発者により署名され、または送信後に開発者以外のだれかにより署名されうる。関連しているとき、特定の動作に対して通常責任のある当事者について、説明されるであろう。
【００３０】
プロセス２００は、「アプリケーション・パッケージ（ＡＰ）の開発および配布  （Ｄ＆Ｄ）を開始」ブロック２０２で始まり、コントロールは、直ちに「アプリケーションをコード化」ブロック２０４に進む。ブロック２０４の間に、アプリケーション開発者は、コード１１６（図１および図２）を特定用途用に、書き込みおよびアセンブルし、もしくは、書き込みまたはアセンブルする。上述したように、コード１１６の開発は、カスタム・コンピュータ・コードの記述、ならびにサード・パーティのコードおよびソフトウェア製品の組み込みを含みうるが、これらに限らない。換言すれば、コード１１６は、市販の製品であったり、専門技術者により作成されたり、またはサード・パーティ業者により開発された任意の個数の個別構成要素を含みうる。ファイル＿１  １４０（図２）、およびファイル＿２  １４２（図２）は、２つのこのような構成要素である。
【００３１】
ブロック２０４の間にコードが製作された後、「許可を定義」ブロック２０６の間に、アプリケーション開発者は、ファイル１１８（図１〜図３）のような許可メタデータ・ファイルを製作する。「パッケージを送信」ブロック２０８の間に、開発者は、コード１１６およびファイル１１８をアプリケーション・パッケージとして、パッケージのソースを検証する署名者に配送する。ブロック２０８は、アプリケーション開発１３２（図２）から、アプリケーション署名１３４（図２）への移行に対応する。
【００３２】
「パッケージを認証」ブロック２１０の間に、ファイル内の、図３と共に上述したもののような適切な許可レベルが、適正に設定されたことが満たされているとき、署名者は、コード１１６および許可メタデータ・ファイル１１８を検査して、それらを有効にするか、またはそれらに「署名する」。アプリケーションの署名は、アプリケーション・パッケージ１４４（図２）を製作するために、証明書１２０および署名１２２を、コード１１６および許可メタデータ・ファイル１１８に組み込むことにより実行される。
【００３３】
ブロック２１０の間に署名者がアプリケーションおよび許可ファイルを有効にしたか、または署名したとき、「パッケージを配送」ブロック２１２の間に、アプリケーションがエンド・ユーザに配送される。ブロック２１２は、アプリケーション署名１３４から、アプリケーション・ステージング１３６（図２）を介して、アプリケーション配布１３８（図２）への移行に対応する。「ポリシーを定義」ブロック２１４の間に、システム管理者、またはコンピューティング・システム１０２（図１および図２）に対して責任を有する利用者は、許可メタデータ・ファイル１１８を検査して、定義された許可が適切であるか否かを判断する。システム管理者が、変更が必要であると判断するとき、ポリシー・ファイル１２４（図１および図２）が修正される。「パッケージをインストール」ブロック２１６の間に、アプリケーション・パッケージ１４４が、最終的なアプリケーション１１４（図１および図２）を作成するために、コンピューティング・システム１０２上にインストールされる。
【００３４】
最後に、プロセス２００は、プロセス２００が完了する「ＡＰのＤ＆Ｄを終了」ブロック２１９に進む。この例では、単一プロセス２００として示されたが、ブロック２０４、２０６、２０８、および２１０を開発プロセス２２０の一部として、ならびにブロック２１２、２１４、および２１６を配布プロセス２３０の一部として特徴付けることができる。換言すれば、プロセス２２０およびプロセス２３０は、異なるコンピューティング・システム上の異なる組織により実行されうる別個のプロセスであり、単に、便宜上、単一プロセス２００の一部として示されているに過ぎない。開発および配布プロセス２００の間に、ブロック２０４、２０６、２０８、２１０、２１２、２１４、および２１６の各々は、複数回、挿入されうることを理解すべきである。例えば、ブロック２１０の間に、署名者は、許可メタデータ・ファイル１１８が不十分であるか、または制限し過ぎているかを判断して、変更を行うために、コード１１６および許可メタデータ・ファイル１１８を開発者に戻すことができる。
【００３５】
図５は、アプリケーション１１４を実行するランタイム・プロセス２５０のフローチャートである。この例では、プロセス２５０は、データ記憶１１２（図１）上に保存されて、ＣＰＵ１０４（図１）上で実行処理する。一実施形態および下記の例では、プロセス２５０は、カリフォルニア州サンタ・クララのサン・マイクロシステムズ社（Ｓｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ、  Ｉｎｃｏｒｐｏｒａｔｅｄ）により発表されたＪａｖａ（登録商標）ランタイム環境（ＪＲＥ）（図示しない）に組み込まれる。
【００３６】
プロセス２５０は、「アプリケーション（Ａｐｐ．）の実行処理を開始」ブロック２５２で始まり、コントロールは、直ちに「アプリケーションをロード」ブロック２５４に進む。ブロック２５４の間に、プロセス２５０は、アプリケーション１１４（図１および図２）をＣＰＵ１０４にロードする。「命令を取り出す」ブロック２５６の間に、プロセス２５０は、アプリケーション１１４内の実行されていない第１の命令を取得する。プロセス２５０がブロック２５６に入るたびに、取り出された命令は、後述の説明において「現在」の命令と呼ばれる。
【００３７】
「許可を検査」ブロック２５８の間に、プロセス２５０は、ブロック２５６の間に取り出された命令に関連する情報を探して、アプリケーション１１４と関連する許可メタデータ・ファイル１１８をスキャンする。例えば、現在の命令が、データ記憶１１２の特定のディレクトリへの書き込みを要求するとき、プロセス２５０は、特定のディレクトリ、およびアプリケーション１１４を開始した利用者との関係を探して、ファイル・エントリ１５０（図３）をスキャンする。「許可（Ｐｅｒｍ．）を許すか？」ブロック２６０の間に、プロセス２５０は、許可ファイル１１８が、現在の命令の実行を許可するか、または禁じるかについて判断する。ファイル１１８が実行を許可するとき、プロセス２５０は、現在の命令に関連する情報を探してポリシー・ファイル１２４をスキャンする「ポリシーを検査」ブロック２６２に進む。
【００３８】
「ポリシーを許すか？」ブロック２６４の間に、プロセス２５０は、ポリシー・ファイル１２４が、現在の命令の実行を許可するか、または禁じるかについて判断する。ファイル１２４が実行を許可するとき、プロセス２５０は、ＪＲＥが命令を実行する「命令を実行」ブロック２６６に進む。
【００３９】
許可を許すか？ブロック２６０の間、またはポリシーを許すか？ブロック２６４の間に、現在の命令の実行はファイル１１８またはファイル１２４に違反するとプロセス２５０が判断するとき、それぞれ、プロセス２５０は、「エクセプションをスロー（Ｔｈｒｏｗ  Ｅｘｃｅｐｔｉｏｎ）」ブロック２６８に進む。ブロック２６８の間に、ＪＲＥは、実行拒否から回復するために適切な処置を取る。エクセプションをどのように取り扱うかに応じて、これは、アプリケーション１１４の実行およびアプリケーション１１４の終了、もしくは、アプリケーション１１４の実行またはアプリケーション１１４の終了を開始した人への通知を含みうる。この例では、ブロック２６８の間にスローされたエクセプションを取り扱った後に、ＪＲＥは適切な処置を取り、単に、次の命令を取り出して、処理を続ける。スローされたエクセプションのプログラミングおよび使用は、プログラミング技術の当業者には、よく知られているはずである。
【００４０】
ブロック２６６の間の現在の命令の実行処理、またはこの例では、ブロック２６８の間のエクセプションのスローに続いて、プロセス２５０は、「さらに命令があるか？」ブロック２７０に進み、このブロック２７０の間に、プロセス２５０は、アプリケーション１１４内に付加的な実行されていない命令があるか否かを判断する。プロセス２５０が、アプリケーション１１４内に付加的な実行されていない命令があると判断するとき、プロセス２５０は、ブロック２５６に戻り、次の命令を取り出して、上述したように処理が続く。プロセス２５０が、実行されていない命令はないと判断したとき、コントロールは、プロセス２５０およびアプリケーション１１４が完了する「アプリケーションの実行処理を終了」ブロック２７９に進む。
【００４１】
本発明は、その特定の実施形態に関して図示されかつ説明されたが、形式および詳細における上記のおよび他の変更が、同じか、または異なる順序で実行される、付加的な、より少ない、または変更された要素、または付加的な、より少ない、または変更されたブロックを含むとともに、これらに限定されずに、本発明の要旨および範囲を逸脱することなく、本発明に行われうることを当業者は理解するであろう。
【図面の簡単な説明】
【００４２】
下記の添付図面とともに、開示された実施形態についての下記の詳細な説明を検討すれば、本発明をより良く理解できる。
【図１】クレームされた内容を組み込んだ例示的コンピューティング・システムのブロック図である。
【図２】分配要素を含む、クレームされた内容を使用する例示的アプリケーション開発アーキテクチャのブロック図である。
【図３】クレームされた内容の一実施形態で使用されうる例示的許可ファイルを示す。
【図４】クレームされた内容と関連するアプリケーション開発および配布プロセスのフローチャートである。
【図５】クレームされた内容に基づいて開発されたアプリケーションを実行するランタイム・プロセスのフローチャートである。
【図１】
2007265404.tif 000003
【図２】
2007265404.tif 000004
【図３】
2007265404.tif 000005
【図４】
2007265404.tif 000006
【図５】
2007265404.tif 000007