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 セキュリティーでは、アプリケーション開発者および管理者にいくつかの新しい要件があります。
デプロイヤーおよび管理者のための 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内から生成されるため、デフォルトをより制限的なものにすることはできません。 この製品では、 上記で示したポリシー・ファイルで定義されたデフォルト・ポリシーよりもさらに制限的なポリシーはサポートしていません。
Java プロセスのセキュリティー・ポリシーを定義するために、いくつかの ポリシー・ファイル が使用されます。 これらのポリシー・ファイルは静的で (コード・ベースはポリシー・ファイルで定義されます)、 IBM® Developer Kit, Java Technology Edition によって提供されるデフォルト・ポリシー・フォーマットです。 エンタープライズ・アプリケーション・リソースおよびユーティリティー・ライブラリーの場合、 WebSphere Application Server は動的ポリシー・サポートを提供します。 コード・ベースはデプロイメント情報を基にして動的に計算され、 許可は実行時にテンプレートのポリシー・ファイルに基づいて認可されます。
ポリシー・ファイルに構文エラーがあると、アプリケーション・サーバー・プロセスが失敗するので、これらのポリシー・ファイルの編集には注意が必要です。
アプリケーションが 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) 文書またはその他の外部文書を介して必須のアクセス権を伝達する必要があります。
アクセス権がコンポーネント・ライブラリーにより内部でしか使用されず、 そのアクセス権によって保護されるリソースへのアクセス許可がアプリケーションには付与されない場合、そのコードに特権があることを示す必要があります。 詳しくは、「 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 セキュリティーを無効にすることが許容されない場合があります。
grant codeBase "file:${application}" {
permission java.security.AllPermission;
};
server.policy ファイル
server.policy ファイルは、 app_server_root/properties/ ディレクトリーにあります。
server.policy ファイルは、 profile_root/properties ディレクトリーにあります。
このポリシーは、 WebSphere Application Server クラスのポリシーを定義します。 現時点で、 同じインストール・システム上のすべてのサーバー・プロセスは、 同じ server.policy ファイルを共有しています。 ただし、各サーバー・プロセスが別々の server.policy ファイルを持つように、 このファイルを構成することができます。 ポリシー・ファイルを java.security.policy Java システム・プロパティーの値として定義します。 Java システム・プロパティーの定義方法について詳しくは、「アプリケーション・サーバーの管理」ファイルの「プロセス定義」セクションを参照してください。
java.policy ファイル
このファイルは、 すべてのクラスに与えられるデフォルトのアクセス権を表します。 このファイルのポリシーは、 WebSphere Application Serverで Java 仮想マシンによって起動されるすべてのプロセスに適用されます。
java.policy ファイルは、 app_server_root/java/lib/security ディレクトリーにあります。
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}
問題: コード・ベース場所の判別中に、予期しない例外がキャッチされました。