プライマリ・コンテンツに移動
Java Platform, Standard Editionデプロイメント・ガイド
リリース10
E94981-01
目次へ移動
目次

前

10 デプロイメント・ルール・セット

デプロイメント・ルール・セット機能は、Javaデスクトップ環境を直接管理する企業を対象にしており、JavaアプレットやJava Web Startアプリケーションのセキュリティ・ポリシーがかつてないほど厳しくなっている環境の下で、企業がレガシー・ビジネス・アプリケーションを使い続ける方法を提供します。この機能は、特定のアプリケーションに使用されるJREのバージョンを制御する機能も提供します。

注意:

デプロイメント・ルール・セット機能はオプションであり、制御された環境の組織で内部的にのみ使用されるものとします。ルール・セットを含むJARファイルが配布されたり、公的に入手可能になったりした場合は、そのルール・セットの署名に使用された証明書がブラックリストに登録され、Javaでブロックされます。

この項の内容は次のとおりです。

デプロイメント・ルール・セットの概要

デプロイメント・ルール・セット機能を使用すると、企業は、セキュリティ・プロンプトなしで実行できる既知のアプリケーションのホワイトリストを作成できます。

Javaアプレット、Java Web Startアプリケーション、およびブラウザに埋め込まれたりブラウザから起動されるJavaFXアプリケーションは、まとめてリッチ・インターネット・アプリケーション(RIA)として知られています。ユーザーを保護し、RIAが損なわれる可能性を最小限に抑えるために、RIAの起動時にセキュリティ・チェックが行われ、ユーザーにRIAの実行を許可するよう求めるプロンプトが表示されます。デプロイメント・ルール・セットによって定義されたホワイトリスト上のアプリケーションは、ほとんどのセキュリティ・プロンプトを表示せずに実行できますが、次のプロンプトは抑止されません。

  • HTTPSのセキュリティ警告

  • ユーザーに資格証明を入力して接続するよう要求する認証ダイアログ

  • ショートカットや関連付けの作成といったアクションを実行する署名なしのJava Web Startアプリケーションからのセキュリティ警告

配備用のルールは、XMLファイルに定義され、署名付きJARファイルにパッケージ化されます。それらのルールは、RIAと一致するものが見つかるまで順次にテストされます。ルールに割り当てられているアクションに応じて、そのあとRIAはセキュリティ・プロンプトなしで実行されるか、実行がブロックされるか、または適用可能ないずれかのセキュリティ・プロンプトを表示するデフォルトの処理で実行されます。一致するルールがない場合は、デフォルトの処理が使用されます。それらのルールでは、RIAの実行に使用されるJREのバージョンを指定したり、古いJREの通知を抑止したりすることもできます。

システムにインストールされているアクティブなルール・セットは、Javaコントロール・パネルの「Webの設定」タブから参照できます。

ルール・セットの作成

ルール・セットはXMLファイルで、ruleset.xmlという名前を付ける必要があります。このファイルの作成には、任意のテキスト・エディタを使用できます。

ルールの定義

所属組織内でRIAを実行またはブロックするために必要なルールを定義します。ルール・セットの構文については、「Javaデプロイメント・ルール・セットのDTD」を参照してください。不明な要素または属性がルール・セットに含まれる場合、Javaコンソールに警告が書き込まれます。

次の要素が有効です。

ルール・セットが無効な場合は、その問題について説明するエラーが表示され、すべてのRIAがブロックされます。RIAを実行できるようにするには、ruleset.xmlファイルを修正するか、DeploymentRuleSet.jarファイルをデプロイメント・ディレクトリから削除する必要があります(このディレクトリの場所についてはルール・セットのインストールを参照)。ルール・セットが無効と報告される場合は、表示されたエラーに基づいて、次の問題をチェックします。

  • ファイルが読取り不可です。

  • ファイルの構造が無効です。

  • ルールが適切に定義されていません。

  • runというアクションを持つルールに選択条件が指定されていないため、そのルールがすべてのRIAと一致します。

  • JARファイルが有効な証明書で正しく署名されていません。

DeploymentRuleSet.jarファイルが削除された場合、RIAはデフォルトの配備プロセスによって処理されます。

ルール・セットの例については、「」を参照してください。

<ruleset>

<ruleset>要素は、ポリシー・ファイルの最上位要素です。

有効な子要素は<rule>および<customer>です。

次の表は、有効な属性について説明しています。

表10-1 <ruleset>の属性

属性 説明 必須

version

このファイルの処理に必要なデプロイメント・ルール・セット仕様の最小バージョン。それ以降のバージョンも使用できることを示すには、プラス記号(+)を使用します(例: 1.0+)。JREが指定されたバージョンをサポートしていない場合、すべてのRIAはブロックされます。

はい

<rule>

<rule>要素は、ルールに指定された条件に一致するRIAまたはRIAのセットのために実行されるアクションを定義します。

この要素には、1つの<id>要素、1つの<action>要素およびオプションの<customer>要素が含まれます。ルールは、1つのルールが一致するまで順次に処理されます。一致するものが見つかると、それ以上のルールは処理されません。一致するルールがない場合は、デフォルトの処理が使用され、関連するセキュリティ・プロンプトまたは警告がすべて表示されます。

注意:

RIAに、別の証明書で署名されているか、別の場所にあるアーティファクトが含まれている場合は、ルール・セットにそのRIAのすべてのアーティファクトのルールが必ず含まれるようにしてください。混合コードのケース(異なる権限レベルを持つJARファイル間の呼出しや、JavaScriptコードから特権付きJavaコードへの呼出し)の場合は、混合コード用のルールの設定を参照してください。

有効な親要素は<ruleset>です。有効な子要素は<id>および<action>です。

この要素に属性はありません。

<id>

<id>要素は、ルールが適用されるRIAまたはRIAのセットを識別します。一致と見なされるには、RIAが、存在しているすべての属性および子要素と一致する必要があります。属性または子要素が存在しない場合、ルールはすべてのRIAと一致します。

注意:

ルールのアクションがrunの場合は、少なくとも1つの属性または子要素が存在する必要があります。

有効な親要素は<rule>です。有効な子要素は<certificate><checksum>および<jnlp-checksum>です。署名付きJARファイルには<certificate>要素を使用します。署名なしのJARファイルには、デプロイメント・ルール・セット1.2以上の<checksum>要素を使用します。署名なしのJNLPファイルでセキュアでないプロパティを使用できるようにするには、場所ベースの実行ルールとともにデプロイメント・ルール・セット1.3以上の<jnlp-checksum>要素を使用します。

次の表は、有効な属性について説明しています。

表10-2 <id>の属性

属性 説明 必須

location

RIAのソースのURL。JNLPを使用するRIAの場合、この値はメインJNLPファイルのhref属性、またはアプレット・タグのjnlp_hrefパラメータと一致します。href属性またはjnlp_hrefパラメータが指定されていない場合、locationとともに<jnlp-checksum>要素を使用します。JNLP拡張の場合、この値はmainアーティファクトのresource要素に含まれるextension要素の場所と一致します。JNLPを使用しないRIAの場合、この値はHTMLファイルのURLと一致します。パスは大文字と小文字が区別され、UTF-8エンコーディングが使用されるものとします。

潜在的なman-in-the-middle攻撃を回避するために、HTTPSプロトコルの使用を強くお薦めします。

場所の一致は、次のガイドラインに基づいて行われます。

  • 指定する場合は、それらのプロトコルが完全に一致している必要があります。

  • ホスト名はアスタリスク+ドットおよびホスト名の部分文字列(*.host-name-substring)で始めることができ、そのドットの後に指定されたホスト名の部分文字列で終わるどのホストとも一致します。たとえば、*.example.comhost.example.comおよびhost.test.example.comと一致します。ホスト名はアスタリスクのみにしたり、ホスト名の部分文字列を含まないアスタリスク(*.comなど)にすることはできません。

  • 指定する場合は、それらのポート番号が完全に一致している必要があります。

  • 指定する場合は、それらのパスの先頭が完全に一致している必要があります。location属性にパスが含まれていない場合は、そのホストからのすべてのパスが一致しているものと見なされます。たとえば、host.example.com/sampleshost.example.com/samplesおよびhost.example.com/samples/testと一致しますが、host.example.com/testとは一致しません。しかし、host.example.comhost.example.com/sampleshost.example.com/samples/test、およびhost.example.com/testと一致します。

location属性が存在しないか、その値がnullの場合、場所はすべてのRIAと一致します。

いいえ

title

JNLPファイルのtitle要素に使用される文字列、またはJava Plug-inによって使用される文字列。title属性が存在し、その値がnull以外の場合、その値はRIAのタイトルと完全に一致する必要があります。title属性が存在しないか、その値がnullの場合、タイトルはすべてのRIAと一致します。

ルールのアクションがrunまたはdefaultであり、title属性が存在する場合は、別のid属性または子要素をtitle属性で指定する必要があります。そうしないと、そのルールが無効になります。

いいえ

<certificate>

<certificate>要素は、RIAの署名に使用された証明書を識別します。hash属性が必須です。

有効な親要素は<id>です。この要素に子要素はありません。

次の表は、有効な属性について説明しています。

表10-3 <certificate>の属性

属性 説明 必須

algorithm

hash属性の値の生成に使用されるハッシュ・アルゴリズムを定義する文字列。現時点では、セキュリティ・ハッシュ・アルゴリズムSHA-256のみがサポートされています。その値がnullの場合は、SHA-256が使用されます。

いいえ

hash

コード署名証明書のハッシュ値を表す16進数の文字列。この値は、algorithm属性に指定されたハッシュ・アルゴリズムに基づいています。使用する値の取得方法については、「証明書のハッシュを取得する」を参照してください。

はい

<checksum>

<checksum>要素は、署名なしのJARファイルのチェックサムを識別します。hash属性が必須です。この要素はデプロイメント・ルール・セット1.2以上で使用可能です。

有効な親要素は<id>です。この要素に子要素はありません。

次の表は、有効な属性について説明しています。

表10-4 <checksum>の属性

属性 説明 必須

algorithm

hash属性の値の生成に使用されるハッシュ・アルゴリズムを定義する文字列。現時点では、セキュリティ・ハッシュ・アルゴリズムSHA-256のみがサポートされています。その値がnullの場合は、SHA-256が使用されます。SHA-256以外の非nullの値が使用されている場合、警告が発行されてSHA-256が使用されます。

いいえ

hash

圧縮されていない形式のJARファイル(圧縮レベル0)のチェックサムのハッシュ値を表す16進数の文字列。この値は、algorithm属性に指定されたハッシュ・アルゴリズムに基づいています。

はい

<jnlp-checksum>

<jnlp-checksum>要素は、JNLPファイルのチェックサムを識別します。hash属性が必須です。この要素はデプロイメント・ルール・セット1.3以上で使用可能です。

有効な親要素は<id>です。この要素に子要素はありません。

<id>要素のlocation属性がnullの場合、<jnlp-checksum>要素は無視されます。複数の<jnlp-checksum>要素を指定できます。JNLPファイルのチェックサムがルール内のいずれかの<jnlp-checksum>要素のhash属性と等しい場合、ルールは一致します。次の表は、有効な属性について説明しています。

表10-5 <jnlp-checksum>の属性

属性 説明 必須

hash

チェックサムのハッシュ値を表す16進数の文字列。この値は、algorithm属性に指定されたハッシュ・アルゴリズムに基づいています。

はい

<action>

<action>要素は、ルールと一致するすべてのRIAに対して実行されるアクションを定義します。

有効な親要素は<rule>です。有効な子要素は<message>です。

次の表は、有効な属性について説明しています。

表10-6 <action>の属性

属性 説明 必須

permission

実行されるアクション。有効な値はblockdefaultおよびrunです。

block - RIAは実行されません。メッセージがユーザーに表示されます。カスタム・メッセージを表示するには、<message>要素を含めます。

default - デフォルトの処理を使ってRIAが実行され、適用可能ないずれかのセキュリティ・プロンプトが表示されます。デフォルトの処理でRIAがブロックされるときにカスタム・メッセージを含めるには、バージョン1.2以上のデプロイメント・ルール・セットを使用して<message>要素を含めます。

run - 次の種類のRIAがプロンプトなしの実行を許可されます。

  • 信頼できる認証局からの有効な証明書で署名されているもの

  • 期限切れの証明書で署名されているもの

  • 自己署名付き

  • 署名なし

  • 必要なJARファイル・マニフェスト属性が含まれていないもの

runアクションでカスタム・メッセージを含めるには、バージョン1.2以上のデプロイメント・ルール・セットを使用して<message>要素を含めます。

はい

version

RIAの実行に使用するJREのバージョンを識別する文字列。この属性は、permission属性の値がrunである場合にのみ適用されます。特定のRIAとの互換性を確保するために古いJREが必要な場合に、version属性を使用します。version属性が存在しない場合、RIAは入手可能な最新のJREで実行されます。

有効な値は次のとおりです。

  • プラットフォーム・バージョン(1.7、1.7+、1.8、9など)。プラットフォーム・バージョンは、指定されたプラットフォーム(バージョンの後にプラス記号(+)が続く場合は指定されたプラットフォームまたはそれ以降)のすべてのバージョンの使用を要求します。

  • 実装バージョン(1.7.0_40、1.8.0_20など)。実装バージョンは、特定のバージョンの使用を要求します。

  • SECURESECUREキーワードは、セキュリティ・ベースライン以上のすべてのバージョンの使用を要求します。

  • SECURE-version。ここで、versionは有効なプラットフォーム・バージョンです(SECURE-1.8など)。SECURE-versionキーワードは、指定されたプラットフォーム(プラットフォームの後にプラス記号(+)が続く場合は指定されたプラットフォームまたはそれ以降)のすべてのセキュアなバージョンの使用を要求します。

使用されるJREのバージョンは、次の優先順位によって決まります。

  • JREの現在のバージョンが入手可能で、version属性と、RIAによって要求されたバージョンの両方と一致する場合は、それが使用されます。

  • 入手可能なJREの最新バージョンがversion属性と、RIAによって要求されたバージョンの両方と一致する場合は、それが使用されます。

  • JREの現在のバージョンが入手可能で、version属性と一致する場合は、それが使用されます。

  • 入手可能なJREの最新バージョンがversion属性と一致する場合は、それが使用されます。

それらの基準を満たすバージョンが入手できない場合、そのRIAはブロックされ、メッセージがユーザーに表示されます。カスタム・メッセージを表示するには、message要素を含めます。

いいえ

force

version属性に指定されたJREをRIAの実行に使用する必要があるかどうかを示すブール値。この属性をtrueに設定した場合、ルールで指定されたJREは、RIAにより要求されたJREをオーバーライドします。ルールで指定されたJREを使用できない場合、RIAはブロックされます。デフォルトは、falseです。

たとえば、RIAが1.7ファミリ(1.7*)のJREを要求し、企業で実行されているJRE 8のバージョンのみを保護する必要がある場合、version属性にSECURE-1.8を指定するルールを作成し、force属性をtrueに設定できます。このルールは、1.8ファミリのセキュアなバージョンでのみRIAを実行するよう強制します。

この属性は、デプロイメント・ルール・セットの1.1以降のバージョンで使用できます。

いいえ

<message>

<message>要素は、ユーザーに表示されるカスタム・メッセージを定義します。このメッセージを使用して、RIAがブロックされる理由を説明したり、追加情報をユーザーに提供することができます。

プレーン・テキストのみを使用でき、HTMLタグやその他の特殊フォーマットはサポートされていません。この要素が存在しない場合は、RIAがブロックされたときにデフォルトのメッセージが表示されます。デプロイメント・ルール・セット1.2以上では、実行するように設定されたアクションのあるルールに対してこの要素が存在する場合、追加のダイアログがユーザーに表示されます。複数のロケールをサポートするには、ロケールごとにmessage要素を含めます。

locale属性を指定しない場合は、message要素が指定されていないすべてロケールに対してそのメッセージが使用されます。ユーザーのロケール用のmessage要素が指定されず、ロケールのないmessage要素も存在しない場合は、デフォルトのメッセージが表示されます。

メッセージが表示されるダイアログ・ボックスが画面に収まるようにするには、メッセージを1024文字未満に保ち、指定されたすべてのロケールをテストします。

有効な親要素は<action>です。この要素に子要素はありません。

次の表は、有効な属性について説明しています。

表10-7 <message>要素の属性

属性 説明 必須

locale

メッセージが適用されるロケール。

いいえ

<customer>

<customer>要素に指定された情報は、トレースおよびコンソールが有効な場合はデプロイメント・トレース・ファイルおよびJavaコンソールに書き込まれます。この要素を使用して、デバッグ情報を提供したり、カスタム・データをルールまたはルール・セットと関連付けます。

<customer>要素に、プレーン・テキストまたは有効なXMLとして任意の情報を入力できます。ルールに固有の情報を指定するには、そのルール内に<customer>要素を含めます。ルール・セットに関する情報を指定するには、ルールの外側に要素を含めます。デプロイメント・ルール・セット1.2よりも前では、この要素は無視されます。デプロイメント・ルール・セット1.2以上では、この要素からの情報は、トレース・ファイルおよびJavaコンソールが有効な場合はそれらにコピーされます。

有効な親要素は<ruleset>および<rule>です。この要素に子要素はありません。

この要素に属性はありません。

JavaScriptコード(LiveConnect)からの呼出しのルールの設定

JavaScriptコードからRIAへの呼出しを行う必要がある場合は、次のガイドラインに従ってそれらの呼出しがブロックされないようにします。

  • ルール・セットに、RIAと一致する、runというアクションを持つルールが含まれている場合、そのルール・セットには、JavaScriptコードの場所と一致する、runというアクションを持つルールも含まれている必要があります。

  • ルール・セットに、RIAと一致する、defaultというアクションを持つルールが含まれている場合、またはRIAと一致するルールがないためにデフォルトの処理が使用される場合は、次のいずれかが当てはまる必要があります。

    • ルール・セットに、JavaScriptコードの場所と一致する、runというアクションを持つルールが含まれています。

    • ルール・セットに、JavaScriptコードの場所と一致する、defaultというアクションを持つルールが含まれています。

    • JavaScriptコードの場所と一致するルールがないため、デフォルトの処理が使用されます。

JavaScriptコードが特権付きコードを呼び出していて、混合コードの警告を抑止する必要がある場合は、「混合コードのルールを設定する」を参照してください。

混合コード用のルールの設定

ルール・セットを作成するときは、RIAに関連付けられているすべてのアーティファクトのルールが必ず含まれるようにしてください。異なる権限レベルを持つコード間の呼出し時、またはJavaScriptコードから特権付きJavaコードへの呼出し時に生成される混合コードのセキュリティ警告を抑止するために、追加のルールが必要になることがあります。

混合コードのセキュリティ警告を抑止するには、次のRIAの要件に基づいたルールをルール・セットに含めます。

  • 異なる権限レベルを持つJavaコード間で呼出しを行うには、呼び出されるコードと一致する、runというアクションを持つルールを追加します。

    たとえば、次のルールでは、サンドボックス・コードから、https://host.example.com/appsに置かれた特権付きコードへの呼出しで混合コードのプロンプトが表示されないようにします。

    <rule>
     <id location="https://host.example.com/apps"/>
     <action permission="run"/>
     </rule>
    
  • JavaScriptコードから特権付きJavaコードへの呼出しを行うには、JavaScriptコードの場所と一致する、runというアクションを持つルールを追加します。

    たとえば、次のルールでは、https://host.example.com上のいずれかのページに置かれているJavaScriptコードから特権付きJavaコードへの呼出しで混合コードのプロンプトが表示されないようします。

    <rule>
     <id location="https://host.example.com/"/>
     <action permission="run"/>
     </rule>
    

    ルール・セットに、JavaScriptコードの場所と一致する、runまたはdefaultというアクションを持つルールが1つも含まれていない場合、JavaScriptコードからの呼出しはブロックされます。JavaScriptコードからの呼出しで適用可能ないずれかのセキュリティ・プロンプトが表示されるようにする場合は、JavaScriptコードの場所と一致する、defaultというアクションを持つルールを定義する必要があります。

このセクションに示されている、混合コードのプロンプトを抑止するためのルールが、そのルールと一致するRIAのほかのセキュリティ・プロンプトも抑止することに注意してください。必要な制御を行うために必要とされる順序でルールが定義されていることを確認してください。

証明書のハッシュの取得

証明書のハッシュを使用してRIAと一致させるルールを定義する場合は、正しい16進数の文字列を取得する必要があります。次の手順を実行します。

  1. 次のコマンドを使用して、JARファイルの証明書情報を出力します(その際、myjar.jarを自身のJARファイルの名前に置き換えます)。
    keytool -printcert -jarfile myjar.jar | more
    
  2. その出力の先頭で、Signer#1を見つけます。
  3. Signer#1の下のCertificate fingerprintsセクションで、SHA256から始まる行を見つけます。

    SHA256識別子に続くテキストには、コロンで区切られた32ペアの16進数が含まれています。この文字列はcertificate要素のhash属性に使用します。文字列はコロンありまたはコロンなしで使用できます。

ルール・セットのパッケージ化

ruleset.xmlファイルに定義されているルール・セットを、DeploymentRuleSet.jarという名前の署名付きJARファイルにパッケージ化する必要があります。このJARファイルは、信頼できる認証局からの有効な証明書で署名されている必要があります。

JARファイルの作成と署名については、「Javaチュートリアル」の「Packaging Programs in JAR Files」レッスンを参照してください。

ルール・セットのインストール

ルール・セットは、Javaアプリケーションを実行する必要があるすべてのシステムにインストールする必要があります。

DeploymentRuleSet.jarファイルをユーザーのシステムの次のディレクトリにインストールします。

  • Windowsプラットフォームでは、そのファイルを<Windows-directory>\Sun\Java\Deploymentディレクトリ(c:\Windows\Sun\Java\Deploymentなど)にインストールします。

  • SolarisおよびLinuxプラットフォームでは、そのファイルを/etc/.java/deploymentディレクトリにインストールします。

  • macOSプラットフォームでは、そのファイルを/Library/Application Support/Oracle/Java/Deployment/ディレクトリにインストールします。

アクティブなルール・セットの表示

一度にアクティブにできるデプロイメント・ルール・セットは1つのみです。アクティブなルール・セットはJavaコントロール・パネルから表示できます。

アクティブなルール・セットを表示するには、次の手順を実行します。

  1. Javaコントロール・パネルを起動します。
  2. 「Webの設定」タブに移動します。
  3. 「デプロイメント・ルール・セット」タブに移動します。

    ルール・セットがアクティブな場合、ルール・セットへのリンクが表示されます。アクティブなルール・セットが存在しない場合は、メッセージが表示されます。

  4. 「アクティブなデプロイメント・ルール・セットの表示」リンクをクリックします。

セキュリティに関する考慮事項

デプロイメント・ルール・セット機能を使用すると、ユーザーに潜在的なセキュリティ・リスクを通知せずにRIAを実行できます。次のセキュリティ上の考慮事項を確認して、ルール・セットの使用に伴うリスクを認識し、提示されるすべての推奨事項に従ってください。

  • id要素のlocation属性は、次の情報と比較されます。

    • HTMLファイルの場所(JNLPを使用しないアプレットの場合)

    • JNLPファイルのhref属性の値(JNLPを使用するJava Web Startアプリケーションおよびアプレットの場合)

    • アプレット・タグのjnlp_hrefパラメータの値(JNLPを使用するアプレットおよびJNLPファイルでhref属性を指定しない場合)

    一致した場合は、HTMLファイルまたはJNLPファイル内のすべてのコンテンツが信頼できるものと見なされます。ただし、そのファイルをホストするWebサイトがクロスサイト・スクリプティング攻撃に脆弱である場合は、悪意のあるコンテンツがHTMLファイルやJNLPファイルに注入される可能性があります。

  • JNLPを使用するアプレットの場合、HTMLファイルの場所がチェックされないため、アプレットがどこからでも起動される可能性があります。

  • ルールをRIAと一致させるためにlocation属性を使用しない場合は、RIAの起動に使用されるHTMLファイルまたはJNLPファイルが損なわれる可能性があります。location属性を使用することをお薦めします。

  • サーバー全体を信頼する場合、実行のアクションを含むルールのlocation属性でのパスのみを含めます。サーバー上の他の場所が信頼されない可能性がある場合、実行ルールでパスを使用すると、セキュリティ・リスクが発生することがあり、お薦めしません。

  • location属性にパスが含まれる場合は、可能であれば、複雑なパスやマルチバイト文字の使用を避けてください。パスは大文字と小文字が区別され、UTF-8エンコーディングが使用されるものとします。サポートされていない文字、デコード・エラー、または長すぎるエンコーディングが検出されると、セキュリティ例外が発生します。Webサーバー、ファイル・システム、またはブラウザがそのパスを別々に正規化した場合は、location属性に基づいたルールが予期しない結果を返す可能性があります。

  • 特定のURIのブロッキング・ルールは、堅牢なセキュリティ施行メカニズムになるよう意図されていません。たとえば、ドメイン名を使って作成されたルールは、ユーザーが代わりにIPアドレスを使用すればパイパスできます。識別子が1つもなく、ブロックというアクションを持つ最終ルールをルール・セットに含めることが推奨されます。RIAをセキュリティ・プロンプトなしで実行するか、デフォルトの処理で実行するために必要なルールを定義し、ほかのすべてのRIAを最終ルールで一致させることで、それらの実行をブロックします。

  • すべての場所に対してHTTPSプロトコルを使用することをお薦めします。

  • デプロイメント・ルール・セット内のルールの順序は、きわめて重要な意味を持ちます。ルールは、ファイルの先頭から順次に処理されます。一致するものが見つかると、それ以上のルールは処理されません。最終ルール・セットを確認し、肯定的なケースと否定的なケースの両方に目を向けて、それらのルールが管理する予定のRIAをカバーし、不明なRIAとの一致を許可しないようにします。

  • 複数のJARファイルやJNLP拡張など、RIAのすべてのアーティファクトにルールが必要です。アーティファクト用のルールを定義するときは、そのルールと一致するほかのRIAの実行を間違って許可しないように注意してください。

  • デプロイメント・ルールでは、互換性を確保する必要がある場合にRIAが古いバージョンのJREで実行されることを許可しますが、古いバージョンにはセキュリティに関する既知の問題が含まれている可能性があります。可能なかぎり最新のJREを使用し、version属性をSECUREまたはSECURE-versionに設定します。古いバージョンのJREを使用する必要がある場合は、古いバージョンを要求するルールをできるだけ限定的なものにすることで、そのルールと一致し、古いバージョンで実行されるRIAを制限してください。この場合は、識別子location、title、およびcertificate hashをすべて使用することをお薦めします。

  • runというアクションを持つルールがRIA用に存在する場合、そのRIAは、RIAの署名に使われた証明書の有効期限が切れている場合でも実行されます。

デプロイメント・ルールを使用してアプリケーションの実行をブロックまたは許可する方法を示すために、サンプル・デプロイメント・ルール・セットが提供されています。

例10-1 単一の場所からのRIAの実行

この例では、https://host.example.com/からのすべてのRIAがセキュリティ・プロンプトなしで実行されることを許可します。ほかの場所からのRIAはそのルールと一致しないため、デフォルトの処理が使用され、該当する場合はセキュリティ・プロンプトが表示されます。

<ruleset version="1.0+">
  <rule>
    <id location="https://host.example.com" />
    <action permission="run" />
  </rule>
</ruleset>

例10-2 一致しないすべてのRIAのブロック

ルール・セットによってすべてのRIAが確実に処理されるように、前のルールで一致しなかったすべてのRIAと一致する最終ルールを指定できます。このルールのアクションは、blockまたはdefaultのどちらかにする必要があります。この例では、https://host.example.com:8080からのすべてのRIAがセキュリティ・プロンプトなしで実行されることを許可し、他のすべてのRIAをブロックします。カスタム・メッセージは指定されないため、RIAがブロックされると、デフォルトのメッセージが表示されます。

<ruleset version="1.0+">
  <rule>
    <id location="https://host.example.com:8080" />
    <action permission="run" />
  </rule>

  <rule>
    <id />
    <action permission="block" />
  </rule>
</ruleset>

例10-3 ルールの順序は重要

ルールは、それらがルール・セットに表示される順序で処理されます。一致ルールに複雑なパターンを定義するには、それらのルールを正しい順序で並べます。この例では、https://host.example.comからのRIAには、セキュアなバージョンのJava 1.7プラットフォームを使用してセキュリティ・プロンプトなしで実行されることを許可しますが、https://host.example.com/gamesからのRIAには、適用可能なセキュリティ・プロンプトが表示されるデフォルトの処理を使用します。ほかの場所からのRIAはどちらのルールとも一致しないため、デフォルトの処理が使用されます。

<ruleset version="1.0+">
  <rule>
    <id location="https://host.example.com/games" />
    <action permission="default" />
  </rule>

  <rule>
    <id location="https://host.example.com" />
    <action permission="run" version="SECURE-1.7" />
  </rule>
</ruleset>

例10-4 特定のRIAの管理

この例では、例10-3のルール・セットを変更し、デフォルトの処理で実行するにはhttps://host.example.com/gamesからのSolitaireという名前のRIAのみを必要とします。https://host.example.comからのほかのRIAは、セキュアなバージョンのJava 1.7プラットフォームを使用してセキュリティ・プロンプトなしで実行されることが許可されます。ほかのすべてのRIAはブロックされ、カスタム・メッセージが表示されます。

<ruleset version="1.0+">
  <rule>
    <id title="Solitaire" location="https://host.example.com/games" />
    <action permission="default" />
  </rule>

  <rule>
    <id location="https://host.example.com" />
    <action permission="run" version="SECURE-1.7" />
  </rule>

  <rule>
    <id /> 
    <action permission="block">
      <message>Blocked by corporate. Contact J. Smith, smith@host.example.com, if you need to run this app.</message>
    </action>
  </rule>
</ruleset>

例10-5 署名証明書に基づいたRIAの管理

複数の場所からの複数のRIAの実行を許可し、すべてのRIAが同じ証明書で署名されるようにするには、場所とタイトルごとにルールを作成するかわりに、certificate要素を使用して1つのルールでそれらのRIAを識別できます。この例では、Oracleが使用する証明書で署名されているすべてのRIAが、セキュアなバージョンのJavaプラットフォームを使用してセキュリティ・プロンプトなしで実行されることを許可します。example.comで終わるホストからのRIAは、デフォルトの処理で実行されることが許可されます。ほかのすべてのRIAはブロックされ、カスタム・メッセージが表示されます。

<ruleset version="1.0+">
  <rule> <!-- allow anything signed with company's public cert --> 
    <id>
      <certificate hash="794F53C746E2AA77D84B843BE942CAB4309F258FD946D62A6C4CCEAB8E1DB2C6" />
    </id>
    <action permission="run" version="SECURE" />
  </rule>

  <rule>
    <id location="*.example.com" />
    <action permission="default" />
  </rule>

  <rule>
    <id />
    <action permission="block">
      <message>Blocked by corporate. Contact J. Smith, smith@host.example.com, if you need to run this app.</message>
    </action>
  </rule>
</ruleset> 

例10-6 特定のJREの使用を強制

特定のJREを強制的に使用するには、action要素のforce属性を使用します。この属性は、デプロイメント・ルール・セットの1.1バージョンで導入されました。この例では、https://host.example.com/appsからのRIAがバージョン1.8_20のJREを使用してセキュリティ・プロンプトなしで実行されることを許可します。RIAによって要求されたバージョンは無視されます。バージョン1.8_20を使用できない場合、RIAはブロックされます。ほかのすべてのRIAはブロックされ、カスタム・メッセージが表示されます。

<ruleset version="1.1+">
  <rule>
    <id location="https://host.example.com/apps" />
    <action permission="run" version="1.8_20" force="true" />
  </rule>

  <rule>
    <id />
    <action permission="block">
      <message>Blocked by corporate. Contact J. Smith, smith@host.example.com, if you need to run this app.</message>
    </action>
  </rule>
</ruleset> 

例10-7 ルール・セットに顧客データを含める

customer要素を使用すると、コメント、デバッグ情報、またはルールおよびルール・セットに関するその他のデータを提供できます。デプロイメント・ルール・セット1.2以降では、この情報は、デプロイメント・トレース・ファイルおよびJavaコンソールが有効な場合はそれらに書き込まれます。この例は、ルール・セットおよび2つのルールに対する顧客情報を示しています。customer要素で使用されているXML要素は説明のためのものであり、任意の有効なXMLを使用できます。

<ruleset version="1.2+">
  <rule>
    <id location="https://host.example.com/verified-apps" />
    <action permission="run" />
    <customer>Allowing applications from https://host.example.com, which has been validated as a secure site</customer>
  </rule>

  <customer>
     <warning font=bold>Run rule not matched.</warning>
     <text>Application will either be blocked or will show security dialogs.</text>
  </customer>

  <rule>
    <id location="*.example.com" />
    <action permission="default" />
  </rule>

  <rule>
    <id /> 
    <action permission="block">
      <message>Blocked by corporate. Contact J. Smith, smith@host.example.com, if you need to run this app.</message>
    </action>
    <customer>
       <warning font=bold>Blocked</warning>
       <text>No rule matched, application blocked by final rule.</text>
    </customer>
  </rule>
</ruleset>

Javaデプロイメント・ルール・セットのDTD

次の例は、デプロイメント・ルール・セットのバージョン1.3のDTDを示しています。バージョン1.3は、8u72以上でサポートされています。バージョン1.2は、JRE 8u60以上でサポートされています。バージョン1.1は、JRE 8u20以上でサポートされています。バージョン1.0は、JRE 7u40以上でサポートされています。バージョン1.0の後で導入されたアイテムが記載されます。

<!ELEMENT ruleset (rule*, customer*)>
<!ATTLIST ruleset version CDATA #REQUIRED>
 
<!ELEMENT rule (id, action, customer*)>
 
<!-- checksum introduced in 1.2, jnlp-checksum introduced in 1.3 -->
<!ELEMENT id (certificate?, checksum?, jnlp-checksum*)>
<!ATTLIST id title CDATA #IMPLIED>
<!ATTLIST id location CDATA #IMPLIED>
 
<!-- jnlp-checksum introduced in 1.3 -->
<!ELEMENT jnlp-checksum EMPTY>
<!ATTLIST jnlp-checksum hash CDATA #REQUIRED>
 
<!ELEMENT certificate EMPTY>
<!ATTLIST certificate algorithm CDATA #IMPLIED>
<!ATTLIST certificate hash CDATA #REQUIRED>
 
<!-- checksum introduced in 1.2 -->
<!ELEMENT checksum EMPTY>
<!ATTLIST checksum algorithm CDATA #IMPLIED>
<!ATTLIST checksum hash CDATA #REQUIRED>
 
<!ELEMENT action (message?)>
<!ATTLIST action permission (run | block | default) #REQUIRED>
<!ATTLIST action version CDATA #IMPLIED>
<!ATTLIST action force (true|false) "false">  <!-- force introduced in 1.1 -->
 
<!ELEMENT message (#PCDATA)>
<!ATTLIST message locale CDATA #IMPLIED>

<!ELEMENT customer ANY>