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

Rich Internet Application の開発および配備 > デプロイメントルールセット

このページでは、次のトピックについて説明します。

概要
ルールセットの作成
ルールセットのパッケージ化とインストール
セキュリティーの考慮事項
例

概要

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

Java アプレットと Java Web Start アプリケーションは、まとめて Rich Internet Application (RIA) として知られており、ブラウザを通じて Web サーバーからアクセスされます。ユーザーを保護し、RIA が損なわれる可能性を最小限に抑えるために、RIA の起動時にセキュリティーチェックが行われ、ユーザーに RIA の実行を許可するよう求めるプロンプトが表示されます。デプロイメントルールセット機能を使用すると、企業は既知のアプリケーションのホワイトリストを作成できます。ホワイトリスト上のアプリケーションは、ほとんどのセキュリティープロンプトを表示せずに実行できますが、次のプロンプトは抑止されません。

HTTPS のセキュリティー警告
ユーザーに資格証明を入力して接続するよう要求する認証ダイアログ
ショートカットや関連付けの作成といったアクションを実行する署名なしの Java Web Start アプリケーションからのセキュリティー警告

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

システムにインストールされているアクティブなルールセットは、Java コントロールパネルの「セキュリティ」タブから参照できます。詳細は、「Java コントロールパネル」の「セキュリティー」セクションを参照してください。

デプロイメントルールセット機能には、新しい Java Plug-in (Java SE 6 Update 10 以降入手可能) が必要です。古い Java Plug-in の使用はサポートされていません。デプロイメントルールセットがインストールされている場合は、すべての RIA で古いプラグインの使用がブロックされます。

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

ルールセットの作成

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

ルールを定義する

所属組織内で RIA を実行またはブロックするために必要なルールを定義します。ルールセットの構文については、「Java デプロイメントルールセットの DTD」を参照してください。不明な要素または属性は無視されます。有効な要素については、次の表で説明します。

要素	説明	属性
`ruleset`	そのポリシーファイルの最上位の要素。`version` 属性が必須です。有効な子要素は `rule` です。	`version` - このファイルの処理に必要なデプロイメントルールセット仕様の最小バージョン。それ以降のバージョンも使用できることを示すには、プラス記号 (+) を使用します (例: `1.0+`) 。7u40 リリース以降、デプロイメントルールセットのバージョンは 1.0 です。
`rule`	RIA または RIA のセットおよび実行されるアクションを識別します。`rule` 要素には、`id` 要素と `action` 要素が 1 つずつ含まれています。ルールは、1 つのルールが一致するまで順次に処理されます。一致するものが見つかると、それ以上のルールは処理されません。一致するルールがない場合は、デフォルトの処理が使用され、関連するセキュリティープロンプトまたは警告がすべて表示されます。有効な子要素は `id` および `action` です。 RIA に、別の証明書で署名されているか、別の場所にあるアーティファクトが含まれている場合は、ルールセットにその RIA のすべてのアーティファクトのルールが必ず含まれるようにしてください。混合コードのケース (異なる権限レベルを持つ JAR ファイル間の呼び出しや、JavaScript コードから特権付き Java コードへの呼び出し) では、その詳細について「混合コード用のルールの設定」を参照してください。有効な親要素は `ruleset` です。有効な子要素は `id` および `action` です。	なし
`id`	ルールが適用される RIA または RIA のセットを識別します。一致と見なされるには、RIA が、存在しているすべての属性および子要素と一致する必要があります。属性または子要素が存在しない場合、ルールはすべての RIA と一致します。ルールのアクションが `run` の場合は、少なくとも 1 つの属性または子要素が存在する必要があります。有効な親要素は `rule` です。有効な子要素は `certificate` です。	`location` - RIA のソースの URL。JNLP を使用する RIA の場合、この値は JNLP ファイルの場所と一致し、JNLP ファイルが存在しない場合は、RIA の正規ホームと一致します。JNLP 拡張の場合、この値は main アーティファクトの resource 要素に含まれる extension 要素の場所と一致します。JNLP を使用しない RIA の場合、この値は HTML ファイルの URL と一致します。パスは大文字と小文字が区別され、UTF-8 エンコーディングが使用されるものとします。潜在的な man-in-the-middle 攻撃を回避するために、HTTPS プロトコルの使用を強くお勧めします。場所の一致は、次のガイドラインに基づいて行われます。指定する場合は、それらのプロトコルが完全に一致している必要があります。ホスト名はアスタリスク + ドット (.) で始めることができ、そのドットのあとに指定された文字列で終わるどのホストとも一致します。たとえば、`.example.com` は `host.example.com` および `host.test.example.com` と一致します。ホスト名をアスタリスクのみにすることはできません。指定する場合は、それらのポート番号が完全に一致している必要があります。指定する場合は、それらのパスの先頭が完全に一致している必要があります。`location` 属性にパスが含まれていない場合は、そのホストからのすべてのパスが一致しているものと見なされます。たとえば、`host.example.com/samples` は `host.example.com/samples` および `host.example.com/samples/test` と一致しますが、`host.example.com/test` とは一致しません。しかし、`host.example.com` は `host.example.com/samples`、`host.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`	RIA の署名に使われた証明書を識別します。`hash` 属性が必須です。有効な親要素は `id` です。`certificate` 要素には子要素がありません。	`algorithm` - `hash` 属性の値の生成に使用されるハッシュアルゴリズムを定義する文字列。現時点では、セキュリティーハッシュアルゴリズム SHA-256 のみがサポートされています。その値が null の場合は、SHA-256 が使用されます。 `hash` - コード署名証明書のハッシュ値を表す 16 進数の文字列。この値は、`algorithm` 属性に指定されたハッシュアルゴリズムに基づいています。使用する値の取得方法については、「証明書のハッシュを取得する」を参照してください。
`action`	そのルールと一致するすべての RIA に対して実行されるアクションを定義します。有効な親要素は `rule` です。有効な子要素は `message` です。	`permission` - 実行されるアクション。次の値が有効です。 `run` - プロンプトを表示しないで RIA が実行されます。証明書失効チェックなどのセキュリティーチェックが引き続き行われ、セキュリティーの問題が見つかった場合は、アプリケーションがブロックされて、メッセージが表示されます。 `block` - RIA は実行されません。メッセージがユーザーに表示されます。カスタムメッセージを表示するには、`message` 要素を含めます。 `default` - デフォルトの処理を使って RIA が実行され、適用可能ないずれかのセキュリティープロンプトが表示されます。 `version` - RIA の実行に使用する JRE のバージョンを識別する文字列。この属性は、`permission` 属性の値が `run` である場合にのみ適用されます。特定の RIA との互換性を確保するために古い JRE が必要な場合に、`version` 属性を使用します。`version` 属性が存在しない場合、RIA は入手可能な最新の JRE で実行されます。次の値が有効です。プラットフォームバージョン (1.6、1.6+、1.7 など)。プラットフォームバージョンは、指定されたプラットフォーム (バージョンのあとにプラス記号 (+) が続く場合は指定されたプラットフォームまたはそれ以降) のいずれかのバージョンの使用をリクエストします。実装バージョン (1.6.0_60、1.7.0_40 など)。実装バージョンは、特定のバージョンの使用をリクエストします。 `SECURE`。`SECURE` キーワードは、いずれかのセキュアなバージョンの使用をリクエストします。 `SECURE-version`。ここで、`version` は有効なプラットフォームバージョンです (`SECURE-1.7` など)。`SECURE-version` キーワードは、指定されたプラットフォーム (プラットフォームのあとにプラス記号 (+) が続く場合は指定されたプラットフォームまたはそれ以降) のいずれかのセキュアなバージョンの使用をリクエストします。使用される JRE のバージョンは、次の優先順位によって決まります。 JRE の現在のバージョンが入手可能で、`version` 属性と、RIA によってリクエストされたバージョンの両方と一致する場合は、それが使用されます。入手可能な JRE の最新バージョンが `version` 属性と、RIA によってリクエストされたバージョンの両方と一致する場合は、それが使用されます。 JRE の現在のバージョンが入手可能で、`version` 属性と一致する場合は、それが使用されます。入手可能な JRE の最新バージョンが `version` 属性と一致する場合は、それが使用されます。それらの基準を満たすバージョンが入手できない場合、その RIA はブロックされ、メッセージがユーザーに表示されます。カスタムメッセージを表示するには、`message` 要素を含めます。
`message`	RIA がブロックされた場合にユーザーに表示されるメッセージ。そのメッセージにはプレーンテキストのみを使用してください。HTML タグやその他の特殊フォーマットはサポートされていません。この要素が存在しない場合は、デフォルトのメッセージが表示されます。複数のロケールをサポートするには、ロケールごとに `message` 要素を含めます。 `locale` 属性を指定しない場合は、`message` 要素が指定されていないすべてロケールに対してそのメッセージが使用されます。ユーザーのロケール用の `message` 要素が指定されず、ロケールのない `message` 要素も存在しない場合は、デフォルトのメッセージが表示されます。メッセージが表示されるダイアログボックスが画面に収まるようにするには、メッセージを 1024 文字未満に保ち、指定されたすべてのロケールをテストします。有効な親要素は `action` です。`message` 要素には子要素がありません。	`locale` - メッセージが適用されるロケール。

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

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

ファイルが読み取り不可です。
ファイルの構造が無効です。
ルールが適切に定義されていません。
run というアクションを持つルールに選択条件が指定されていないため、そのルールがすべての RIA と一致します。
JAR ファイルが有効な証明書で正しく署名されていません。

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

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 進数の文字列を取得する必要があります。次の手順を実行します。

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

SHA256 識別子に続くテキストには、コロンで区切られた 32 ペアの 16 進数が含まれています。
SHA256 識別子に続く文字列をテキストエディタにコピーし、コロンを削除します。

コロンを削除して作成した文字列が、certificate 要素の hash 属性に使用するハッシュ値です。

ルールセットのパッケージ化とインストール

ruleset.xml ファイルに定義されているルールセットを、DeploymentRuleSet.jar という名前の署名付き JAR ファイルにパッケージ化する必要があります。この JAR ファイルは、信頼できる認証局からの有効な証明書で署名されている必要があります。JAR ファイルの作成と署名については、「Java チュートリアル」の「Packaging Programs in JAR Files」レッスンを参照してください。

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

Windows プラットフォームでは、そのファイルを <Windows-directory>\Sun\Java\Deployment ディレクトリ (c:\Windows\Sun\Java\Deployment など) にインストールします。
Mac OS X および UNIX プラットフォームでは、そのファイルを /etc/.java/deployment ディレクトリにインストールします。

アクティブなルールセットを表示するには、「Java コントロールパネル」の「セキュリティー」セクションを参照してください。

セキュリティーの考慮事項

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

id 要素の location 属性が、次のファイルの場所と比較されます。
- HTML ファイル (JNLP を使用しないアプレットの場合)
- JNLP ファイル (JNLP を使用する Java Web Start アプリケーションおよびアプレットの場合)
一致した場合は、HTML ファイルまたは JNLP ファイル内のすべてのコンテンツが信頼できるものと見なされます。ただし、そのファイルをホストする Web サイトがクロスサイトスクリプティング攻撃に脆弱である場合は、悪意のあるコンテンツが HTML ファイルや JNLP ファイルに注入される可能性があります。
JNLP を使用するアプレットの場合、HTML ファイルの場所がチェックされないため、アプレットがどこからでも起動される可能性があります。
ルールを RIA と一致させるために location 属性を使用しない場合は、RIA の起動に使用される HTML ファイルまたは JNLP ファイルが損なわれる可能性があります。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 の署名に使われた証明書の有効期限が切れている場合でも実行されます。

例

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

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

ルールセットによってすべての RIA が確実に処理されるように、前のルールで一致しなかったすべての RIA と一致する最終ルールを指定できます。このルールのアクションは、block または default のどちらかにする必要があります。次のルールセットでは、https://host.example.com:8080 からのすべての 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>

ルールは、それらがルールセットに表示される順序で処理されます。一致ルールに複雑なパターンを定義するには、それらのルールを正しい順序で並べます。次のルールセットでは、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>

次のルールセットでは、前のルールセットを変更し、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" />
  </rule>
</ruleset>

複数の場所からの複数の 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>

連絡先