Java 2 セキュリティー・ポリシーのマイグレーション

このトピックは、Java™ 2 セキュリティー・ポリシーのマイグレーションに関するガイダンスとして使用してください。

このタスクについて

旧リリースの WebSphere® Application Server

WebSphere Application Server では、Java 2 セキュリティー・マネージャーをサーバー・ランタイムに使用して、エンタープライズ・アプリケーションが System.exit および System.setSecurityManager メソッドを呼び出さないように設定されています。 これら 2 つの Java アプリケーション・プログラミング・インターフェース (API) は、エンタープライズ・アプリケーションによって呼び出された場合、望ましくない結果をもたらします。 例えば、System.exit API は 、Java 仮想マシン (アプリケーション・サーバー・プロセス) が早期に終了する原因となります。これは、アプリケーション・サーバーにとっては、望ましくない操作です。

Java 2 セキュリティーを正しくサポートするには、すべてのサーバーのランタイムは、privileged とマークされ (適切な位置に doPrivileged API 呼び出しが挿入されます)、デフォルトの許可セットまたはポリシーを識別する必要があります。 アプリケーション・コードは特権を保持せず、ポリシー・ファイルで定義された許可に従います。doPrivileged の装備は重要であり、Java 2 セキュリティーをサポートするために必要です。 これがない場合、アプリケーション・コードは、 サーバー・ランタイムに必要な許可を与えられていなければなりません。この状態は、許可検査を実行するために Java 2 セキュリティーによって使用される設計とアルゴリズムによるものです。Java 2 セキュリティー検査の許可アルゴリズムを参照してください。

以下に示す 2 つの許可は、WebSphere Application Server の Java 2 セキュリティー・マネージャー (ハードコーディングされています) によって強制されます。
  • java.lang.RuntimePermission(exitVM)
  • java.lang.RuntimePermission(setSecurityManager)

Java 2 セキュリティー・ポリシーの種類に関係なく、アプリケーション・コードは、これらの許可へのアクセスを拒否されます。 ただし、サーバーのランタイムには、これらの許可が付与されています。これ以外のすべての 許可検査は、実行されません。

2 つの許可のみがサポートされています。
  • java.net.SocketPermission
  • java.net.NetPermission

ただ、すべての製品サーバー・ランタイムが特権ありとして適切にマークされているわけではありません。アプリケーション・コードには、先にリストした 2 つのほかに、すべての許可を与える必要があります。 これを行わないと、エンタープライズ・アプリケーションが実行できない場合があります。エンタープライズ・ アプリケーションに対するこの Java 2 セキュリティー・ポリシーは、非常に柔軟です。

変更内容

Java 2 セキュリティーは、WebSphere Application Server では完全にサポートされており、すべての許可が実行されます。エンタープライズ・アプリケーションに対するデフォルトの Java 2 セキュリティー・ポリシーは、Java Platform, Enterprise Edition (Java EE) バージョン 1.4 仕様で定義されている推奨許可セットです。 エンタープライズ・アプリケーションに許可されているデフォルトの Java 2 セキュリティー・ポリシーについては、profile_root/config/cells/cell_name/nodes/node_name/app.policy ファイルを参照してください。 このポリシーは、前のリリースと比較すると、 はるかに厳格です。

すべてのポリシーは、宣言により施行されます。製品のセキュリティー・マネージャーは、 ポリシー・ファイルで宣言されるすべてのポリシーに従います。この規則には 1 つの例外があり、 エンタープライズ・アプリケーションは、profile_root/config/cells/cell_name/filter.policy ファイルで宣言された許可へのアクセスを拒否されます。

注: エンタープライズ・アプリケーションのデフォルトの Java 2 セキュリティー・ポリシーははるかに厳格で、WebSphere Application Server バージョン 9.0 ではすべての許可が施行されます。アプリケーション・コードに必要な許可が付与されていないため、セキュリティー・ポリシーは失敗する可能性がありますが、システム・リソース (例えばファイル入出力) には方針に基づいてアクセスすることができ、許可チェックを受けるようになりました。

アプリケーション・コードで、セキュリティー・マネージャーを設定するために setSecurityManager アクセス権を使用しないでください。アプリケーションが setSecurityManager アクセス権を使用すると、WebSphere Application Server 内の内部セキュリティー・マネージャーと競合します。RMI のためにアプリケーションでセキュリティー・マネージャーを設定する必要がある場合、WebSphere Application Server 管理コンソール内の「グローバル・セキュリティー」ページで「Java 2 セキュリティーを使用してアプリケーションのアクセスをローカル・リソースに制限する」オプションを使用可能にする必要もあります。その後、WebSphere Application Server はセキュリティー・マネージャーを登録します。アプリケーション・コードでは、 このセキュリティー・マネージャーが System.getSecurityManager() アプリ ケーション・プログラミング・インターフェース (API) を使用して登録され ていることを確認することができます。

システム・プロパティーのマイグレーション

前のリリースでは、Java 2 セキュリティーに関して、以下のシステム・プロパティーが使用されました。
  • java.security.policy。 ポリシー・ファイルの絶対パス (処置が必要です)。このシステム・プロパティーには、システム許可 (許可が Java 仮想マシン (JVM) および製品サーバー・ランタイムに与えられている) とエンタープライズ・アプリケーション許可の両方が含まれています。 エンタープライズ・アプリケーションの Java 2 セキュリティー・ポリシーを バージョン 9.0 に マイグレーションします。Java 2 セキュリティー・ポリシーのマイグレーションについては、Java 2 セキュリティー・ポリシーのマイグレーションのステップを参照してください。
  • enableJava2Security。Java 2 セキュリティーを使用可能にするために使用されます (処置は必要ありません)。 このシステム・プロパティーは非推奨です。Java 2 セキュリティーを使用可能にするかどうかを制御するために、WebSphere 構成アプリケーション・プログラミング・インターフェース (API) でフラグが使用されます。 このオプションは、 管理コンソールから使用可能にします。
  • was.homeWebSphere Application Server のインストール・ディレクトリーに展開されます (処置が必要な場合があります)。このシステム・プロパティーは使用すべきではありません。${user.install.root} および ${was.install.root} プロパティーに置き換えられます。ディレクトリーにインスタンス固有のデータが含まれている場合は、 ${user.install.root} が使用されます。それ以外の場合は、${was.install.root} が使用されます。これらのプロパティーは、WebSphere Application Server または WebSphere Application Server Network Deployment 環境で交互に使用します。Java 2 セキュリティー・ポリシーのマイグレーションのステップを参照してください。

Java 2 セキュリティー・ポリシーのマイグレーション

Java ポリシー・ファイルを バージョン 9.0 に自動的にマイグレーションする簡単な方法はありません。これは、同じポリシー・ファイル内に、システム許可とアプリケーション許可が混在しているためです。エンタープライズ・アプリケーションの Java 2 セキュリティー・ポリシーを手動で was.policy または app.policy ファイルにコピーします。 ただし、Java 2 セキュリティー・ポリシーを was.policy ファイルにマイグレーションすることを推奨します。これは、絶対コード・ベースの代わりにシンボルまたは相対コード・ベースが使用されるためです。 このプロセスには多くの利点があります。app.policy ファイル内の許可は、app.policy ファイルの所属するノード上で実行するすべてのエンタープライズ・アプリケーションに適用されますが、was.policy で定義された許可は、特定のエンタープライズ・アプリケーションのみに付与します。

ポリシー管理に関する詳細は、Java 2 セキュリティー・ポリシー・ファイルのトピックを参照してください。

次の例は、前のリリースからの Java 2 セキュリティー・ポリシーのマイグレーションを示します。 ここには、app1.ear エンタープライズ・アプリケーションの Java 2 セキュリティー・ポリシー・ファイル、およびシステム 許可 (Java 仮想マシン (JVM) および製品サーバー・ランタイムに与えられている許可) が含まれています。

[AIX Solaris HP-UX Linux Windows][z/OS]Java 2 セキュリティー・ポリシー・ファイルのデフォルトのロケーションは、profile_root/properties/java.policy です。デフォルトの許可は、 分かりやすいよう省略されています。

[IBM i]Java 2 セキュリティー・ポリシー・ファイルのデフォルトのロケーションは、profile_root/properties/java.policy です。デフォルトの許可は、 分かりやすいよう省略されています。

// For product Samples
   grant codeBase "file:${app_server_root}/installedApps/app1.ear/-" {
     permission java.security.SecurityPermission "printIdentity";
     permission java.io.FilePermission "${app_server_root}${/}temp${/}somefile.txt",
       "read";
   };

図をわかりやすくするため、この例では、すべての許可がアプリケーション・レベル許可としてマイグレーションされています。ただし、コンポーネント・レベル (Web、エンタープライズ Bean、コネクター、またはユーティリティー Java アーカイブ (JAR) コンポーネント・レベル) で、より細分化されたレベルの許可を与えることができます。または、特定のコンポーネントに許可を与えることができます。

手順

  1. Java 2 セキュリティーがアプリケーション・サーバー上で使用不可になっていることを確認します。
  2. was.policy ファイルが存在していない場合は、新たにそのファイルを作成するか、あるいは構成リポジトリー内のマイグレーション済みアプリケーションの was.policy ファイルを以下の内容を用いて更新します。
    grant codeBase "file:${application}" {
         permission java.security.SecurityPermission "printIdentity";
         permission java.io.FilePermission "
                 ${user.install.root}${/}temp${/}somefile.txt", "read";
       };

    上記のコード・サンプルの 3 行目と 4 行目は、説明の都合上 2 行で表示されています。

    was.policy ファイルは、profile_root/config/cells/cell_name/applications/app.ear/deployments/app/META-INF/ ディレクトリーにあります。

  3. アセンブリー・ツールを使用して、 was.policy ファイルをエンタープライズ・アーカイブ (EAR) ファイルに付加します。

    また、 アセンブリー・ツールを使用して、was.policy ファイルの内容を確認することもできます。詳しくは、Java 2 セキュリティー用の was.policy ファイルの構成を参照してください。

  4. 妥当性検査を行って、エンタープライズ・アプリケーションが、マイグレーション済み Java 2 セキュリティー権限、および ${user.install.root}/config/cells/cell_name/nodes/node_name/app.policy ファイル内で宣言されたデフォルトの許可セット以外に追加の許可を必要としないことを確認します。この妥当性検査には、コード検討、コード検査、アプリケーション文書検討、および実動前の環境において Java 2 セキュリティーが使用可能になっているマイグレーション済みエンタープライズ・アプリケーションのサンドボックス・テストが必要となります。 Java 2 セキュリティーによって保護される API についての詳細は 、『Java 2 セキュリティーによって保護される Developer Kit API』を参照してください。サード・パーティーの ライブラリーを使用する場合は、Java 2 セキュリティーによって保護される API のベンダー資料を参照してください。必要な許可がすべてアプリケーションに与えられていることを確認してください。これが与えられていない場合には、Java 2 セキュリティーが使用可能になった時点で、 アプリケーションの実行が失敗することがあります。
  5. Java 2 セキュリティーを使用可能にした状態で、マイグレーション済みエンタープライズ・アプリケーションの実動前テストを実行します。 トレース・ストリング com.ibm.ws.security.core.SecurityManager=all=enabled を使用して、実動前テスト環境で WebSphere Application Server Java 2 セキュリティー・マネージャーのトレースを使用可能にします。 このトレース機能は、 アプリケーションが必要な許可を与えられていないか、一部のシステム・コードが特権ありとして適切にマークされていない場合に、 作成される AccessControlException 例外をデバッグするのに役立ちます。 このトレースは、例外が作成されると、スタック・トレース、 およびクラスに与えられた許可を呼び出しスタック上にダンプします。

    詳しくは、Java 2 セキュリティーのアクセス制御例外を参照してください。

    注: Java 2 セキュリティー・ポリシーは前のリリースと比べるとはるかに厳格なので、管理者またはデプロイヤーは、Java 2 セキュリティーを使用可能にする前に、使用するエンタープライズ・アプリケーションを検討し、追加の許可が必要かどうかを調べる必要があります。エンタープライズ・アプリケーションに必要な許可が与えられていないと、 その実行は失敗します。

トピックのタイプを示すアイコン タスク・トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tsec_migratejava2sec
ファイル名:tsec_migratejava2sec.html