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

28.1 ルール・セットの作成

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

28.1.1.9 <customer>

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

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など)にインストールします。

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

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

アクティブなルール・セットを表示するには、Javaコントロール・パネルの「セキュリティ」タブにアクセスします。 このタブの詳細は、20.4項「セキュリティ」を参照してください。

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

デプロイメント・ルール・セット機能を使用すると、ユーザーに潜在的なセキュリティ・リスクを通知せずに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の署名に使われた証明書の有効期限が切れている場合でも実行されます。

28.4 例

例28-1では、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のどちらかにする必要があります。 例28-2では、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>

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

例28-4では、前のルール・セットを変更し、デフォルトの処理で実行するには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>

複数の場所からの複数のRIAの実行を許可し、すべてのRIAが同じ証明書で署名されるようにするには、場所とタイトルごとにルールを作成するかわりに、certificate要素を使用して1つのルールでそれらのRIAを識別できます。 例28-5では、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> 

特定のJREを強制的に使用するには、アクションelementのforce属性を使用します。 この属性は、デプロイメント・ルール・セットの1.1バージョンで導入されました。 例28-6では、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> 

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

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

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