WebSphere Application Server for i5/OS, Version 6.1   
             オペレーティング・システム: i5/OS

             目次と検索結果のパーソナライズ化

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 2 Platform, Enterprise Edition (J2EE) バージョン 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 バージョン 6.0.x 以降ではすべての許可が施行されます。 アプリケーション・コードに必要な許可が付与されていないため、セキュリティー・ポリシーは失敗する可能性がありますが、システム・リソース (例えばファイル入出力) には方針に基づいてアクセスすることができ、許可チェックを受けるようになりました。

アプリケーション・コードで、セキュリティー・マネージャーを設定するために 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 セキュリティー・ポリシーは、 WebSphere Application Server バージョン 6.0.x に マイグレーションします。Java 2 セキュリティー・ポリシーのマイグレーションについては 、『Java 2 セキュリティー・ポリシーのマイグレーション』のステップを参照してください。
  • enableJava2Security。Java 2 セキュリティーを使用可能にするために使用されます (処置は必要ありません)。このシステム・プロパティーは使用すべきではありません。Java 2 セキュリティーを 使用可能にするかどうかを制御するために、WebSphere 構成アプリケーション・プログラミング・インターフェース (API) の フラグが使用されます。このオプションは、 管理コンソールから使用可能にします。
  • was.home。 WebSphere Application Server のインストール・ディレクトリーに 展開されます (処置が必要な場合があります)。このシステム・プロパティーは使用すべきではありません。${user.install.root} および ${was.install.root} プロパティーに置き換えられます。ディレクトリーにインスタンス固有のデータが含まれている場合は、 ${user.install.root} が使用されます。それ以外の場合は、${was.install.root} が使用されます。これらのプロパティーは、WebSphere Application Server または Network Deployment 環境で交互に使用できます。Java 2 セキュリティー・ポリシーの マイグレーションのステップを参照してください。

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

Java ポリシー・ファイルを WebSphere Application Server バージョン 6.0.x 以降に 自動的にマイグレーションする簡単な方法はありません。これは、同じポリシー・ファイル内に、システム許可とアプリケーション許可が混在しているためです。 エンタープライズ・アプリケーションの 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) および製品サーバー・ランタイムに与えられている許可) が含まれています。

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、コネクター、 またはユーティリティー 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 ファイルの内容を確認することもできます。詳しくは、 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 セキュリティーを使用可能にする前に使用するエンタープライズ・アプリケーションを検討して、 追加の許可が必要でないかどうか調べる必要があります。エンタープライズ・アプリケーションに必要な許可が与えられていないと、 その実行は失敗します。



関連概念
アセンブリー・ツール
関連タスク
was.policy ファイルの構成
システム・リソースおよび API の保護 (Java 2 セキュリティー)
タスク・トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 5:46:14 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.base.iseries.doc/info/iseries/ae/tsec_migratejava2sec.html