Java 2 セキュリティー

Java™ 2 セキュリティーは、ポリシー・ベースの細分化されたアクセス制御メカニズムを提供します。このメカニズムは、特定の保護システム・リソースへのアクセスを許可する前にアクセス権を検査することにより、システム全体の保全性を向上させます。 Java 2 セキュリティーにより、ファイル入出力、ソケット、およびプロパティーなどのシステム・リソースへのアクセスが保護されます。 Java 2 Platform, Enterprise Edition (J2EE) セキュリティーは、サーブレット、 JavaServer Pages (JSP) ファイル、および Enterprise JavaBeans (EJB) メソッドなどの Web リソースへのアクセスを保護します。

Java 2 セキュリティーは比較的新しいため、Java 2 セキュリティーが適用できる非常に細分化されたアクセス制御プログラミング・モデルのために、多くの既存アプリケーションまたは新規アプリケーションが準備されていない可能性があります。 管理者は、アプリケーションが Java 2 セキュリティー用に準備されていない場合に、Java 2 セキュリティーを使用可能にすることによって生じる可能性のある結果を理解する必要があります。 Java 2 セキュリティーでは、アプリケーション開発者および管理者にいくつかの新しい要件があります。

[IBM i]重要: Java 2 セキュリティーは、Java 2 セキュリティーが有効になっている Java 仮想マシンで実行される Java プログラムのみを制限します。 Java 2 セキュリティーが使用不可の場合、またはシステム・リソースが他のプログラムまたはコマンドからアクセスされる場合、システム・リソースは保護されません。 このため、システム・リソースを保護したい場合には、オペレーティング・システム・セキュリティーを使用する必要があります。
問題の回避: アプリケーション・サーバーは、カスタム Java セキュリティー・マネージャー実装をサポートしません。

デプロイヤーおよび管理者のための Java 2 セキュリティー

Java 2 セキュリティーはサポートされていますが、デフォルトでは無効になっています。 Java 2 セキュリティーと管理セキュリティーは、互いに独立して構成できます。 管理セキュリティーを無効にしても、Java 2 セキュリティーは自動的に無効になりません。 Java 2 セキュリティーは明示的に使用不可にする必要があります。

アプリケーションまたはサード・パーティー・ライブラリーの準備ができていない場合は、Java 2 セキュリティーを有効にすると問題が発生します。 これらの問題は、システム・ログまたはトレース・ファイルで Java 2 セキュリティー AccessControl例外として識別できます。 アプリケーションの Java 2 セキュリティーの作動可能性について確信が持てない場合は、最初に Java 2 セキュリティーを無効にして、アプリケーションをインストールし、正しく動作していることを確認してください。

WebSphere® Application Serverで Java 2 セキュリティーが有効になっている場合、 WebSphere クラス・ローダーのいずれかによってクラスがロードされると、そのクラスに関連付けられた Java 2 セキュリティー権限のセットが作成されます。 WebSphere 以外のクラス・ローダーには、 WebSphere Application Server ポリシー・ファイルからのこの Java 許可セットはありません。 アクセス制御があり、アクションを実行しているこれらのクラス・ローダーに関連付けられたコードは、そのコードの周囲に Java 2 セキュリティー doPrivileged ブロックを必要とします。

製品には必要な Java 2 セキュリティー doPrivileged API が配置されていない可能性があるため、これらのポリシー・ファイルによって具体化されたポリシーをさらに制限することはできません。 デフォルト・ポリシーが制限的なポリシーとなります。 追加の許可を付与することはできますが、 AccessControl例外例外は WebSphere Application Server内から生成されるため、デフォルトをより制限的なものにすることはできません。 この製品では、 上記で示したポリシー・ファイルで定義されたデフォルト・ポリシーよりもさらに制限的なポリシーはサポートしていません。

WebSphere Application Serverで Java 2 セキュリティーが有効になっている場合、 WebSphere クラス・ローダーの 1 つによってクラスがロードされるときに、そのクラスに関連付けられた Java 2 セキュリティー許可のセットが作成されます。 WebSphere 以外のクラス・ローダーには、 WebSphere Application Server ポリシー・ファイルからのこの Java 許可セットはありません。 アクセス制御があり、アクションを実行しているこれらのクラス・ローダーに関連付けられたコードは、そのコードの周囲に Java 2 セキュリティー doPrivileged ブロックを必要とします。 この状況について詳しくは、以下を参照してください。

Java プロセスのセキュリティー・ポリシーを定義するために、いくつかの ポリシー・ファイル が使用されます。 これらのポリシー・ファイルは静的で (コード・ベースはポリシー・ファイルで定義されます)、 IBM® Developer Kit, Java Technology Edition によって提供されるデフォルト・ポリシー・フォーマットです。 エンタープライズ・アプリケーション・リソースおよびユーティリティー・ライブラリーの場合、 WebSphere Application Server は動的ポリシー・サポートを提供します。 コード・ベースはデプロイメント情報を基にして動的に計算され、 許可は実行時にテンプレートのポリシー・ファイルに基づいて認可されます。

ポリシー・ファイルに構文エラーがあると、アプリケーション・サーバー・プロセスが失敗するので、これらのポリシー・ファイルの編集には注意が必要です。

[IBM i]注: IBM Developer Kit, Java Technology Edition が提供する ポリシー・ツール を使用して、これらのポリシー・ファイルを編集してください。

アプリケーションが Java 2 セキュリティー用に準備されていない場合、アプリケーション・プロバイダーがアプリケーションの一部として was.policy ファイルを提供しない場合、またはアプリケーション・プロバイダーが期待される許可を通信しない場合、アプリケーションは実行時に Java 2 セキュリティー・アクセス制御例外を引き起こす可能性があります。 アプリケーションが Java 2 セキュリティー用に準備されていないことは明らかでない可能性があります。 アクセス制御例外が発生するアプリケーションのトラブルシューティングに役立つ、いくつ かのランタイム・デバッグ援助機能があります。 詳しくは、Java 2 セキュリティー・デバッグ・エイドを参照してください。 このようなアプリケーションの処理に関する情報および戦略については、 Java 2 セキュリティー対応でないアプリケーションの処理 を参照してください。

管理セキュリティー設定で Java セキュリティーが有効になっている場合、インストールされているセキュリティー・マネージャーは現在、非システム・スレッドの modifyThread および modifyThreadグループの許可を検査しないことに注意する必要があります。 Web および Enterprise JavaBeans (EJB) アプリケーション・コードがスレッドを作成または変更できるようにすると、コンテナーの他のコンポーネントに悪影響を及ぼす可能性があり、エンタープライズ Bean のライフサイクルおよびトランザクションを管理するコンテナーの機能に影響を与える可能性があります。

アプリケーション開発者のための Java 2 セキュリティー

アプリケーション開発者は、デフォルトの WebSphere ポリシーで付与される許可と、追加の許可が必要かどうかを知るためにアプリケーションが呼び出す SDK API の許可要件を理解する必要があります。 リソース・セクションの「Java 2 SDK のアクセス権」リファレンスに、どの API がどのアクセス権を必要とするかが記載されています。

アプリケーション・プロバイダーにより、アプリケーションは 前述のデフォルト・ポリシーで与えられたアクセス権を保持していると想定されます。 デフォルトの WebSphere ポリシーでカバーされていないリソースにアクセスするアプリケーションは、追加の Java 2 セキュリティー権限をアプリケーションに付与する必要があります。

他の動的 WebSphere ポリシー・ファイルの 1 つ、または従来の java.policy 静的ポリシー・ファイルの 1 つでアプリケーションに追加の許可を付与することは可能ですが、EAR ファイルに組み込まれている was.policy ファイルにより、追加の許可の有効範囲が、それらを必要とする正確なアプリケーションに限定されます。 アクセス権の有効範囲をそのアクセス権を必要とするアプリケーション・コード以外にも定義すると、 本来ならアクセス権を持っていないコードが、特定のリソースにアクセスできるようになります。

実際に複数の .ear ファイルに含まれている可能性があるライブラリーのように、アプリケーション・コンポーネントが開発されている場合、ライブラリー開発者は、アプリケーション・アセンブラーに必要な Java 2 許可を文書化する必要があります。 ライブラリー・タイプ・コンポーネント用の was.policy ファイルは、存在しません。 開発者は、アプリケーション・プログラミング・インターフェース (API) 文書またはその他の外部文書を介して必須のアクセス権を伝達する必要があります。

コンポーネント・ライブラリーを複数のエンタープライズ・アプリケーションで共有する場合は 、app.policy ファイルで、ノード上のすべてのエンタープライズ・アプリケーションに アクセス権を与えることができます。
注: app.policy ファイルへの更新は、 app.policy ファイルが属するノード上のエンタープライズ・アプリケーションにのみ適用されます。

アクセス権がコンポーネント・ライブラリーにより内部でしか使用されず、 そのアクセス権によって保護されるリソースへのアクセス許可がアプリケーションには付与されない場合、そのコードに特権があることを示す必要があります。 詳しくは、「 AccessControl例外 」トピックを参照してください。 ただし、doPrivileged 呼び出しの挿入が不適切な場合に、セキュリティー・ホールが開く恐れがあります。 doPrivileged 呼び出しの影響を理解し、適切に判断してください。

Java 2 セキュリティー・ポリシー・ファイル の動的ポリシー・ファイルに関するセクションでは、 was.policy ファイル内のアクセス権が実行時にどのように付与されるかについて説明しています。

Java 2 セキュリティーで使用するアプリケーションを開発することは、新しいスキルである可能性があり、以前はアプリケーション開発者には必要とされなかったセキュリティー認識を課すことになります。 Java 2 セキュリティー・モデルおよびアプリケーション開発への影響については、このセクションでは説明しません。 使用を開始するには、URL https://docs.oracle.com/javase/1.5.0/docs/guide/security/index.htmlを参照してください。

デバッグ援助機能

WebSphere Application Server SYSOUT ファイルと com.ibm.websphere.java2secman.norethrow プロパティーは、デバッグのための 2 つの主な援助機能です。

WebSphere システム・ログまたはトレース・ファイル

システム・ログまたはトレース・ファイルに 記録される AccessControl 例外には、この例外の原因であるアクセス権違反、例外呼び出しスタック、 および各スタック・フレームに与えられたアクセス権についての情報が含まれます。 通常、この情報だけで、不足しているアクセス権およびアクセス権を必要としているコードを判別できます。

com.ibm.websphere.java2secman.norethrow プロパティー

WebSphere Application Serverで Java 2 セキュリティーが有効になっている場合、セキュリティー・マネージャー・コンポーネントは java.security.AccessControl 例外。 この例外は、例外処理が行われていない場合には、ランタイム障害の原因になることがよくあります。 この例外も SYSOUT ファイルに記録されます。

ただし、Java 仮想マシンの com.ibm.websphere.java2secman.norethrow プロパティーが設定されていて、その値が trueである場合、セキュリティー・マネージャーは AccessControl 例外を作成しません。 この情報はログに記録されます。

このプロパティーは、セキュリティー・マネージャーに AccessControl 例外を生成しないように指示するので、サンドボックスまたはデバッグ環境を対象としています。 Java 2 セキュリティーは実施されません。 このプロパティーは、Java 2 セキュリティー環境の緩和により、Java 2 セキュリティーが生成する保全性が低下する実稼働環境では使用しないでください。

このプロパティーは、 アプリケーションを徹底的にテストすることが可能で、システム・ログまたはトレース・ファイルに AccessControl 例外が 記述されているかどうかを検査することのできるサンドボックスまたはテスト環境で非常に役に立ちます。 このプロパティーは AccessControl 例外を作成しないので、呼び出しスタックを伝搬せず、障害の原因にもなりません。 このプロパティーを指定しない場合、AccessControl 例外を見つけて、1 つずつそれを修正する必要があります。

Java 2 セキュリティーに対応していないアプリケーションの取り扱い

Java 2 セキュリティーが提供するシステム保全性の向上が重要である場合は、アプリケーション・プロバイダーに連絡して、アプリケーションが Java 2 セキュリティーをサポートするように依頼するか、少なくとも、付与する必要があるデフォルトの WebSphere Application Server ポリシー以外の必要な追加権限を伝達してください。

このようなアプリケーションを処理する最も簡単な方法は、 WebSphere Application Serverで Java 2 セキュリティーを無効にすることです。 ただし、この方法では、このソリューションがシステム全体に適用されるために、 システムの保全性が本来の強度を保持できなくなってしまいます。 組織のセキュリティー・ポリシーまたはリスク許容度によっては、Java 2 セキュリティーを無効にすることが許容されない場合があります。

もう 1 つの方法は、Java 2 セキュリティーを有効なままにして、十分な追加権限を付与するか、問題のあるアプリケーションのみにすべての権限を付与することです。 ただし、アクセス権を与えるということは、些細 (ささい) な問題ではありません。 アプリケーション・プロバイダーが何らかの方法で必要なアクセス権を伝達していない場合、 必要なアクセス権が何であるかを判別することが困難であり、 すべてのアクセス権を与えざるを得ないことがあります。 このリスクは、このアプリケーションを異なるノードに置くことによって最小化され、 これによってアプリケーションを特定のリソースから隔離させるのに役立つ場合があります。 アプリケーションの .ear ファイルに組み込まれている was.policy ファイルで、 java.security.AllPermission 許可を付与します。以下に例を示します。
grant codeBase "file:${application}" {
            permission java.security.AllPermission;
        };

server.policy ファイル

[AIX Solaris HP-UX Linux Windows][z/OS] server.policy ファイルは、 app_server_root/properties/ ディレクトリーにあります。

[IBM i] server.policy ファイルは、 profile_root/properties ディレクトリーにあります。

このポリシーは、 WebSphere Application Server クラスのポリシーを定義します。 現時点で、 同じインストール・システム上のすべてのサーバー・プロセスは、 同じ server.policy ファイルを共有しています。 ただし、各サーバー・プロセスが別々の server.policy ファイルを持つように、 このファイルを構成することができます。 ポリシー・ファイルを java.security.policy Java システム・プロパティーの値として定義します。 Java システム・プロパティーの定義方法について詳しくは、「アプリケーション・サーバーの管理」ファイルの「プロセス定義」セクションを参照してください。

server.policy ファ イルは、リポジトリーおよびファイル複製サービスによって管理される構成ファイルではありません。 このファイルへの変更はローカルで行われ、他のマシンへ複製されることはありません。 server.policy ファイルを使用して、サーバー・リソースの Java 2 セキュリティー・ポリシーを定義します。 app.policy ファイル (ノードごと) または was.policy ファイル (エンタープライズ・アプリケーションごと) を使用して、エンタープライズ・アプリケーション・リソースの Java 2 セキュリティー・ポリシーを定義します。
注: app.policy ファイルへの更新は、 app.policy ファイルが属するノード上のエンタープライズ・アプリケーションにのみ適用されます。

java.policy ファイル

このファイルは、 すべてのクラスに与えられるデフォルトのアクセス権を表します。 このファイルのポリシーは、 WebSphere Application Serverで Java 仮想マシンによって起動されるすべてのプロセスに適用されます。

[AIX Solaris HP-UX Linux Windows][z/OS] java.policy ファイルは、 app_server_root/java/lib/security ディレクトリーにあります。

[IBM i]java.policy ファイルは、${java.home}/lib/security/ ディレクトリーにあります。 ${java.home} は、使用している Software Development Kit (SDK) のパスです。 このポリシー・ファイルは、オペレーティング・システム全体で使用されます。 java.policy ファイルは編集しないでください。

トラブルシューティング

エラー・メッセージ CWSCJ0314E

症状:

Error message CWSCJ0314E: 現行 ® Java 2 セキュリティー・ポリシーが、Java 2 セキュリティー権限の潜在的な違反を報告しました。 詳しくは、「問題判別ガイド」を参照してください。{0}許可 \:{1}コード \:{2}{3}スタック・トレース \:{4}コード・ベース・ロケーション \:{5} 現在の Java 2 セキュリティー・ポリシーが Java 2 セキュリティー許可違反の可能性を報告しました。 詳細については、問題判別ガイドを参照してください。{0} 許可¥:{1} コード¥:{2}{3} スタック・トレース¥:{4} コード・ベースのロケーション¥:{5}

問題:

Java セキュリティー・マネージャーの checkPermission メソッドが、デバッグ情報を含むサブジェクト許可に関するセキュリティー例外を報告しました。 報告される情報は、 システム構成に関しては異なる可能性があります。 このレポートは、Reliability Availability Service Ability (RAS) トレースをデバッグ・モードに構成するか、Java プロパティーを指定することによって使用可能になります。

デバッグ・モードで RAS トレースを構成する方法については、 トレースの使用可能化 を参照してください。

管理コンソールから「JVM 設定」パネル内にプロパティー java.security.debug を指定します。 有効な値には、次のものが含まれます。
アクセス
必要な許可、コード、スタック、およびコード・ベースの場所を含む、 すべてのデバッグ情報を出力します。
stack
デバッグ情報 (必要な許可、コード、スタックなど) を出力します。
failure
デバッグ情報 (必要な許可、コードなど) を出力します。

推奨される対応:

報告された例外は、セキュア・システムにとって重大な場合があります。 セキュリティー・トレースをオンにして、 セキュリティー・ポリシーを違反した可能性のあるコードを判別してください。 違反コードが判別された後、適用可能なすべての Java 2 セキュリティー・ポリシー・ファイルとアプリケーション・コードを調べて、試行された操作が Java 2 セキュリティーに関して許可されているかどうかを確認してください。

アプリケーションが Java Mail を使用して実行されている場合、このメッセージは無害である可能性があります。 was.policy ファイルを更新して、以下のアクセス 権をアプリケーションに付与することができます。
permission java.io.FilePermission "${user.home}${/}.mailcap", "read"; 
permission java.io.FilePermission "${user.home}${/}.mime.types", "read"; 
permission java.io.FilePermission "${java.home}${/}lib${/}mailcap", "read"; 
permission java.io.FilePermission "${java.home}${/}lib${/}mime.types", "read";
SecurityException - アクセスは拒否されました

症状:

Java セキュリティーが有効になっていて、 jaxm.properties ファイルを読み取る許可が付与されていない場合、 javax.xml.soap.SOAPFactory.newInstance() への呼び出しによって SOAPFactory インスタンスが作成されるとき、または MessageFactoryへの呼び出しによって MessageFactory インスタンスが作成されるときに、例外例外が発生します。newInstance()
Permission:

      /opt/IBM/WebSphere/AppServer/java/jre/lib/jaxm.properties : access denied 
(java.io.FilePermission /opt/IBM/WebSphere/AppServer/java/jre/lib/jaxm.properties
read)

コード:

     com.ibm.ws.wsfvt.test.binding.addr1.binder.AddressBinder  
in  {file:/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/
ahp6405Node01Cell/DataBinding.ear/address1.war/WEB-INF/lib
/addressbinder1.jar}

Stack Trace:

java.security.AccessControlException: access denied (java.io.FilePermission
/opt/IBM/WebSphere/AppServer/java/jre/lib/jaxm.properties read)
.

問題:

Java 2 セキュリティー・ポリシーは、Java 2 セキュリティー権限の潜在的な違反を報告します。

推奨される対応:

SOAPFactory は、この例外を無視して、ロードする実装を判断する次の手段で続けます。 つまり、このセキュリティー例外のログ・エントリーは無視できます。

本製品は、他の Web サービス・テクノロジー (WS-Addressing (WS-A)、WS-Atomic Transaction (WS-AT)、WS-Notification など) をサポートするために SOAPFactory を使用するため、Java セキュリティーが有効になっているすべての Web サービス・アプリケーションでこの SecurityException を無視できます。

メッセージ

メッセージ: CWSCJ0313E: Java 2 セキュリティー・マネージャーのデバッグ・メッセージ・フラグが初期化されています \: TrDebug: {0}、アクセス: {1}、スタック: {2}、失敗: {3}

問題: セキュリティー・マネージャーに対して有効なデバッグ・メッセージ・フラグの値を構成しました。

メッセージ: CWSCJ0307E: コード・ベースのロケーションを判別しようとしているときに、予期しない例外をキャッチしました。 例外: {0}

問題: コード・ベース場所の判別中に、予期しない例外がキャッチされました。