7 Javaセキュリティ機能を使用したWebLogicリソースの保護

WebLogicリソースを保護するために、Oracle WebLogic Serverでは、Jakarta Security、Javaセキュリティ・マネージャ、Jakarta AuthorizationなどのJavaセキュリティ・アーティファクトの使用がサポートされています。

Jakarta Securityを使用したWebLogicリソースの保護

Jakarta Securityを使用して、URL (Web)、EJBおよびコネクタ・コンポーネントを保護できます。さらに、WebLogic Serverでは、デプロイメント記述子内の追加のセキュリティ・ポリシーを指定するコネクタ・モデルが、URLおよびEJBのコンポーネントに拡張されています。

コネクタ仕様では、すでに次の例のように<security-permission>タグを使用して追加セキュリティ・ポリシーを指定するデプロイメント記述子に対応しています(例7-1を参照):

例7-1 security-permissionタグのサンプル

<security-permission>
<description> Optional explanation goes here </description>
<security-permission-spec>
<!--
A single grant statement following the syntax of http://xmlns.jcp.org/j2se/1.4.2/docs/guide/security/PolicyFiles.html#FileSyntax
without the "codebase" and "signedBy" clauses goes here. For example:
-->
grant {
permission java.net.SocketPermission "*", "resolve";
};
</security-permission-spec>
</security-permission>

rar.xmlファイルでの<security-permission>タグのサポートに加えて、WebLogic Serverではweblogic.xmlファイルとweblogic-ejb-jar.xmlファイルに<security-permission>タグを追加しています。これは、コネクタ・モデルを他の2つのアプリケーション・タイプ(WebアプリケーションとEJB)に拡張し、すべてのコンポーネント・タイプでセキュリティ・ポリシーへのインタフェースを統一するとともに、将来のJakarta EE仕様の変更に備えるためのものです。

ノート:

Jakarta EEには、Jakarta Connector Architecture仕様と同様に、様々なアプリケーション・タイプに対するJavaセキュリティ・デフォルト権限の要件があります(Jakarta EE仕様を参照)。

Javaセキュリティ・マネージャを使用したWebLogicリソースの保護

WebLogic Serverと一緒に使用するようにJavaセキュリティ・マネージャを設定して、Java仮想マシン(JVM)内で実行されているリソースの保護を強化できます。また、Javaセキュリティ・マネージャの拡張であるセキュリティ・マネージャのプリントも使用することができます。

ノート:

Javaセキュリティ・マネージャはJDK 17で非推奨となり、将来のリリースで削除されます。Javaセキュリティ・マネージャを有効にしてサーバーを起動すると、WebLogic Serverに警告が表示されます。

Javaセキュリティ・マネージャは、JDKから削除された後はWebLogic Serverでサポートされなくなります。

Javaセキュリティ・マネージャは、任意のセキュリティ・ステップです。以下の節では、WebLogic ServerでJavaセキュリティ・マネージャを使用する方法について説明します。

Javaセキュリティ・マネージャの詳細は、http://docs.oracle.com/javase/8/docs/technotes/guides/security/index.htmlでJavaセキュリティに関するWebページを参照してください。

Javaセキュリティ・マネージャの設定

WebLogic Serverを実行する場合、WebLogic ServerはJavaセキュリティ・マネージャを使用して、信頼性のないコードがJavaセキュリティ・ポリシー・ファイルによって制限されているアクションを実行しないようにできます。

Java仮想マシン(JVM)には、Javaセキュリティ・ポリシー・ファイルでコードに制約を設定するセキュリティ・メカニズムが組み込まれています。Javaセキュリティ・マネージャは、Javaセキュリティ・ポリシー・ファイルを使用して一連の許可をクラスに強制的に付与します。これらの許可を使用すると、JVMのインスタンスで実行される指定されたクラスに特定の実行時処理を許可するかどうかを設定できます。多くの場合、脅威モデルでは悪意あるコードがJVMで実行されることを想定していないため、Javaセキュリティ・マネージャは必要ありません。しかし、信頼されていないサード・パーティがWebLogic Serverを使用し、信頼されていないクラスが実行される場合、Javaセキュリティ・マネージャが役立ちます。

WebLogic ServerでJavaセキュリティ・マネージャを使用するには、WebLogic Serverの起動時に-Djava.security.policy引数と-Djava.security.manager引数を指定します。-Djava.security.policy引数は、Javaセキュリティ・ポリシーを格納するファイル名を、相対パス名または絶対パス名で指定します。WebLogic ServerでJavaセキュリティ・マネージャを使用している場合、java weblogic.Serverコマンドを使用してコマンド・ラインからWebLogic Serverを起動する際に、-Dweblogic.Name引数も指定する必要があります。たとえば:

java -Dweblogic.Name=server-name 
      -Djava.security.manager
      -Djava.security.policy[=]=filename
      weblogic.Server

WebLogic Serverは、WL_HOME\server\lib\weblogic.policyにサンプルのJavaセキュリティ・ポリシー・ファイルを提供します。このファイルは、パッチ・セット更新(PSU)によって上書きされる可能性があるため、編集しないでください。かわりに、独自のセキュリティ・ポリシー・ファイルを作成するモデルとして使用してください。サンプルweblogic.policyファイルとカスタム・セキュリティ・ポリシー・ファイルを連結して、PSUで提供される更新を自動的に取得することを検討してください。

ノート:

このサンプル・ポリシー・ファイルは完全なものではなく、修正を加えないとWebLogic Serverを起動できません。独自のカスタム・ポリシー・ファイルを作成する場合は、WebLogic Serverおよびすべてのアプリケーションが適切に動作するように、構成に基づいて様々な権限を追加してください。

パッチを適用する際、特に注意してください。システム権限のコードが含まれるパッチを適用する場合、使用するカスタムJavaポリシー・ファイルに対して、関連する変更を行う必要が生じる場合があります。

たとえば、WebLogic Serverを正常に起動し、WebLogicリモート・コンソールを使用してアプリケーションをデプロイするには、カスタム・ポリシー・ファイルに次のように権限を追加する必要があります:

permission java.util.PropertyPermission '*', 'read'; 
permission java.lang.RuntimePermission '*'; 
permission java.io.FilePermission ' <<ALL FILES>>', 'read,write'; 
permission javax.management.MBeanPermission '*', '*';

セキュリティ・ポリシー・ファイルを指定しないでJavaセキュリティ・マネージャを有効にする場合、Javaセキュリティ・マネージャでは、$JAVA_HOME\jre\lib\securityディレクトリのjava.policyファイルに定義されるデフォルトのセキュリティ・ポリシーを使用します。

Javaセキュリティ・マネージャのセキュリティ・ポリシーは、以下のいずれかの方法で定義します。

一般的な使用のためのカスタム・ポリシー・ファイルの変更

WebLogic ServerデプロイメントでJavaセキュリティ・マネージャのセキュリティ・ポリシー・ファイルを使用するには、WebLogic Serverの起動時にJavaセキュリティ・マネージャにカスタム・ポリシー・ファイルの場所を指定する必要があります。これを行うには、サーバーの起動に使用するJavaコマンド・ラインで次の引数を設定します:

  • java.security.managerは、JVMにJavaセキュリティ・ポリシー・ファイルを使用するよう指示します。

  • java.security.policyは、JVMに使用するJavaセキュリティ・ポリシー・ファイルの場所を指示します。この引数は、Javaセキュリティ・ポリシー(ここではexample.policy)の完全修飾名です。

たとえば:

java...-Djava.security.manager \
   -Djava.security.policy==C:\weblogic\example.policy

ノート:

java.security.policy引数を指定するときには、Javaセキュリティ・マネージャによってexample.policyファイルのみが使用されるよう、=のかわりに==を使用します。==を使用すると、example.policyファイルはデフォルトのセキュリティ・ポリシーをオーバーライドします。1つの等号(=)では、example.policyファイルが既存のセキュリティ・ポリシーに追加されます。

CLASSPATHに追加のディレクトリがある場合、または追加のディレクトリにアプリケーションをデプロイしている場合は、それらのディレクトリに対する特定の権限をexample.policyファイルに追加します。

ポリシー・ファイルを使用する際は、次のような注意事項を考慮することをお薦めします:

  • 後続のパッチ・セット更新(PSU)によって変更が上書きされるため、WL_HOME\server\lib\weblogic.policyファイルを直接変更しないでください。かわりに、WL_HOME\server\lib\weblogic.policyに基づいてカスタム・ポリシー・ファイルを作成し、カスタム・ポリシー・ファイルに変更を適用します。PSUから自動的に変更を取得できるように、WL_HOME\server\lib\weblogic.policyの内容を自動的に取り込むようにカスタム・ポリシー・ファイルを構成することを検討してください。

  • カスタム・ポリシー・ファイルのバックアップ・コピーを作成し、バックアップ・コピーを安全な場所に保管します。

  • オペレーティング・システムを介してカスタム・ポリシー・ファイルの権限を設定し、WebLogic Serverデプロイメントの管理者は書込みおよび読取り権限を持ち、他のユーザーはファイルにアクセスできないようにします。

    ノート:

    Javaセキュリティ・マネージャは、管理サーバーと管理対象サーバーの起動時に部分的に無効にされます。起動シーケンス中は、現在のJavaセキュリティ・マネージャが無効化され、checkRead()メソッドが無効化されたJavaセキュリティ・マネージャに置き換えられます。このメソッドを無効化した場合、起動シーケンスのパフォーマンスは飛躍的に向上しますが、セキュリティは最低レベルに下がります。WebLogic Serverのスタート・アップ・クラスは、この部分的に無効にされたJavaセキュリティ・マネージャと一緒に実行されます。このため、スタート・アップ・クラスを十分にチェックして、セキュリティ(ファイルの読取りなど)を検討する必要があります。

Javaセキュリティ・マネージャの詳細は、java.lang.SecurityManagerクラスのJavadoc (http://docs.oracle.com/javase/8/docs/api/java/lang/SecurityManager.html)を参照してください。

アプリケーション型のセキュリティ・ポリシーの設定

サーブレット、EJBおよびJakarta Connector Architectureリソース・アダプタのデフォルト・セキュリティ・ポリシーを、Javaセキュリティ・ポリシー・ファイルで設定します。サーブレット、EJBおよびリソース・アダプタのデフォルト・セキュリティ・ポリシーは、次のコード・ベースでJavaセキュリティ・ポリシーに定義します。

  • サーブレット - "file:/weblogic/application/defaults/Web"

  • EJB - "file:/weblogic/application/defaults/EJB"

  • リソース・アダプタ - "file:/weblogic/application/defaults/Connector"

    ノート:

    これらのセキュリティ・ポリシーは、WebLogic Serverの特定のインスタンスにデプロイされるすべてのサーブレット、EJBおよびリソース・アダプタに適用されます。

アプリケーション固有のセキュリティ・ポリシーの設定

特定のサーブレット、EJBまたはリソース・アダプタのセキュリティ・ポリシーを設定するには、セキュリティ・ポリシーをそれらのデプロイメント記述子に追加します。デプロイメント記述子は、以下のファイルに定義されます。

  • サーブレット - weblogic.xml

  • EJB - weblogic-ejb-jar.xml

  • リソース・アダプタ - rar.xml

    ノート:

    リソース・アダプタのセキュリティ・ポリシーはJakarta EE標準に準拠します。サーブレットおよびEJBのセキュリティ・ポリシーはJakarta EE標準に対するWebLogic Server拡張に準拠します。

例7-2は、セキュリティ・ポリシーをデプロイメント記述子に追加するための構文です:

ノート:

現時点では、<security-permission-spec>タグはweblogic-application.xmlファイルに追加できません。このタグを使用できるのは、weblogic-ejb-jar.xml、rar.xml、またはweblogic.xmlファイルの中だけです。また、<security-permission-spec>属性では変数はサポートされていません。

例7-2 セキュリティ・ポリシーの構文

<security-permission>
 <description>
  Allow getting the J2EEJ2SETest4 property
 </description>
 <security-permission-spec>
  grant {
    permission java.util.PropertyPermission "welcome.J2EEJ2SETest4","read";
  };
 </security-permission-spec>
</security-permission>

セキュリティ・マネージャのプリントの使用

セキュリティ・マネージャのプリントは、Javaセキュリティ・マネージャの拡張です。セキュリティ・マネージャをプリントすることにより、Javaセキュリティ・マネージャで実行しているJavaアプリケーションに対して必要となる許可のすべてを識別するために使用できます。一度に1つずつ必要な許可を識別するJavaセキュリティ・マネージャと異なり、セキュリティ・マネージャのプリントによって、介入せずに必要な許可のすべてを識別することができます。

Javaセキュリティ・マネージャの詳細は、http://docs.oracle.com/javase/8/docs/technotes/guides/security/overview/jsoverview.htmlでJavaセキュリティに関するWebページを参照してください。

ノート:

本番環境でセキュリティ・マネージャのプリントを使用しないでください。不足している許可を識別するための開発のみを目的としています。

信頼性のないコードの処理は防止されません。

セキュリティ・マネージャのプリントの起動引数

WebLogic ServerでJavaセキュリティ・マネージャを使用するには、WebLogic Serverの起動時に次の2つの引数を指定します。

  • -Djava.security.manager=weblogic.security.psm.PrintingSecurityManager

    -Djava.security.manager引数は、どのJavaセキュリティ・マネージャを起動するかをWebLogic Serverに指示します。この場合、セキュリティ・マネージャのプリントを使用します。

  • -Djava.security.policy

    -Djava.security.policy引数は、Java セキュリティ・ポリシーを格納するファイル名を、相対パス名または絶対パス名で指定します。WebLogic Serverは、WL_HOME\server\lib\weblogic.policyにサンプルのJavaセキュリティ・ポリシー・ファイルを提供します。このファイルは、パッチ・セット更新(PSU)によって上書きされる可能性があるため、直接使用しないでください。かわりに、独自のセキュリティ・ポリシー・ファイルを作成するモデルとして使用してください。サンプルweblogic.policyファイルとカスタム・セキュリティ・ポリシー・ファイルを連結して、PSUで提供される更新を自動的に取得することを検討してください。

    デフォルトでは、startWebLogicスクリプトには、WL_HOME/server/lib/weblogic.policyに設定された-Djava.security.policyプロパティがすでに含まれています。-Djava.security.policyを更新して、カスタム・ポリシー・ファイルのファイルの場所を指定します。

ノート:

WL_HOME\server\lib\weblogic.policyのサンプル・ポリシー・ファイルは完全なものではなく、修正を加えてからでないとWebLogic Serverを起動することはできません。独自のカスタム・ポリシー・ファイルを作成する場合は、WebLogic Serverおよびすべてのアプリケーションが適切に動作するように、構成に基づいて様々な権限を追加してください。

次の項を参照してください。

セキュリティ・マネージャのプリントを使用するWebLogic Serverの起動

セキュリティ・マネージャのプリントを使用するWebLogic ServerをUNIXシェルから起動するには、DOMAIN_HOMEにおけるstartWebLogic.shスクリプトに次の引数を渡します。この例は、startWeblogic.shからのデフォルトweblogic.policyのJavaポリシー・ファイルを使用します。

startWeblogic.sh
-Djava.security.manager=weblogic.security.psm.PrintingSecurityManager

UNIXシェルなしWindowsシステムのためにまず、JAVA_OPTIONSに起動オプションを設定し、DOMAIN_HOMEstartWebLogic.cmdスクリプトを使用して、WebLogic Serverを起動します。この例は、startWeblogic.cmdからのデフォルトのweblogic.policyのJavaポリシー・ファイルを使用します。

$ set JAVA_OPTIONS=-Djava.security.manager=weblogic.security.psm.PrintingSecurityManager

$ DOMAIN_HOME\startWeblogic.cmd
出力ファイルの書込み

セキュリティ・マネージャのプリントは、コード・ソースおよびそれに関する許可をリストする出力を生成します。また、ポリシー・ファイルにコピー・アンド・ペーストするためのアクセスを付与するポリシーも発生します。

デフォルトで、System.outに出力します。次の2つの引数で出力ファイルを構成することができます。

  • -Doracle.weblogic.security.manager.printing.file=psm_perms.txt

  • -Doracle.weblogic.security.manager.printing.generated.grants.file=psm_grants.txt

最初のシステム引数の値は、セキュリティ・マネージャをプリントすることにより、不足している許可のメッセージのすべてを書き込むファイルです。2番目の引数の値は、セキュリティ・マネージャをプリントすることにより、不足しているポリシー付与を書き込むファイルです。

たとえば、UNIXシェルなしWindowsシステムのために、引数をJAVA_OPTIONSに追加します。

$ set JAVA_OPTIONS=-Djava.security.manager=weblogic.security.psm.PrintingSecurityManager
-Doracle.weblogic.security.manager.printing.file=psm_perms.txt

$ startWeblogic.cmd

出力ファイルのフルパスを指定しない場合、DOMAIN_HOMEに作成されます。

Jakarta Authorizationの使用

Jakarta Authorizationは、WebLogic Serverドメイン内のEJBおよびサーブレット・コンテナに代替認可メカニズムを提供します。特定のシステム・プロパティと値のペアを指定することで、WebLogic JACCプロバイダを使用可能にできます。

Jakarta Authorization仕様は、Jakarta EEプラットフォームの一部です。Jakarta Authorizationは、Java権限ベースのセキュリティ・モデルをEJBとサーブレットに拡張します。Jakarta Authorizationはhttps://jakarta.ee/specifications/authorization/に定義されています。Jakarta Authorizationは、以前はJava Authorization Contract for Containers(JACC)と呼ばれていました。

表7-2に示すように、Jakarta Authorizationが構成されていると、WebLogicセキュリティ・フレームワークのアクセス決定、裁決、およびロール・マッピング機能は、EJBおよびサーブレットの認可判定には使用されません。

WebLogic ServerはJakarta Authorizationプロバイダを実装していますが、これはJakarta Authorization仕様に完全に準拠しているものの、WebLogic認可プロバイダほど最適化されていません。アクセス決定にはJakarta Authorizationクラスが使用されます。Jakarta Authorization仕様ではロール・マッピングの対処方法が定義されていないため、WebLogic JACCクラスがロールからプリンシパルのマッピングに使用されます。

ノート:

WebLogic Serverで使用されるJakarta Authorizationクラスには、決定を下すためのポリシー・オブジェクトの実装は含まれません。かわりに、java.security.Policyオブジェクトに依存します(Java SEおよびJDK API仕様を参照)。

この節では、以下のトピックを取り上げます。

表7-2には、JACCを有効にした場合に、どのプロバイダがロール・マッピングに使用されるかを示します。

表7-1 Jakarta Authorizationが有効になっている場合

ステータス EJB/サーブレットの認可とロール・マッピングに使用されるプロバイダ その他のすべての認可とロール・マッピングに使用されるプロバイダ EJB/サーブレットのロールとポリシーをWebLogicリモート・コンソールで表示および変更できるかどうか

Jakarta Authorizationが有効です

JACCプロバイダ

WebLogicセキュリティ・フレームワーク・プロバイダ

いいえ

Jakarta Authorizationが有効ではありません

WebLogicセキュリティ・フレームワーク・プロバイダ

WebLogicセキュリティ・フレームワーク・プロバイダ

設定によっては、はい

ノート:

ドメインでは、すべてのサーバーに対してJakarta Authorizationを有効にするか、どのサーバーに対しても有効にしないかのいずれかにしてください。これは、WebLogicセキュリティ・フレームワークがレルム/ドメイン固有であるのに対し、Jakarta Authorizationはサーバー固有であるためです。WebLogic JACCプロバイダを使用するか、独自のJakarta Authorizationプロバイダを作成(こちらを推奨)してJakarta Authorizationを有効にする場合、EJBとサーブレットの認可ポリシーをドメイン全体で同期させる必要があります。たとえば、アプリケーションは、サーバーを起動するたびに再デプロイされます。Jakarta Authorizationが構成されたサーバーを、コマンド・ラインでJakarta Authorizationオプションを指定せずに起動すると、EJBやサーブレットのロール・マッピングおよび認可判定にデフォルトのWebLogic認可プロバイダが使用されます。

WebLogic JACCプロバイダとWebLogic認可プロバイダの比較

WebLogic JACCプロバイダは、Jakarta Authorization仕様に完全に準拠していますが、動的ロール・マッピングをサポートしておらず、EJBおよびサーブレット以外のリソースの認可判定は行いません。セキュリティ機能のパフォーマンスと柔軟性を向上させるため、SSPIベースのプロバイダを使用することをお薦めします。

表7-2では、WebLogic JACCプロバイダとWebLogic認可プロバイダの機能を比較します。

表7-2 WebLogic JACCプロバイダとWebLogic認可プロバイダの比較

WebLogic JACCプロバイダ WebLogic認可プロバイダ

Jakarta Authorization仕様を実装します

付加価値の高いセキュリティ・フレームワーク

EJBおよびサーブレットのみデプロイメント/認可判定を行います

デプロイメント/認可判定を行います

java.security.Policyオブジェクトを判定に使用します

複数の認可/ロール・プロバイダで使用可能です

デプロイメント時の静的ロール・マッピング

動的ロール・マッピング

Jakarta EE権限制御アクセス

資格エンジンでアクセスを制御します

ロール・マッピングおよびロール/プリンシパル・マッピングは、デプロイメント記述子でのみ変更可能です

ロールおよびロール/プリンシパル・マッピングは、デプロイメント記述子およびWebLogicリモート・コンソールで変更可能です

WebLogic JACCプロバイダの有効化

WebLogic Serverを起動するコマンドに、次のシステム・プロパティと値のペアを指定して、WebLogic JACCプロバイダを有効化できます。

  • プロパティ:

    jakarta.security.jacc.PolicyConfigurationFactory.provider

    値:

    weblogic.security.jacc.simpleprovider.PolicyConfigurationFactoryImpl

  • プロパティ:

    jakarta.security.jacc.policy.provider

    値:

    weblogic.security.jacc.simpleprovider.SimpleJACCPolicy

  • プロパティ:

    weblogic.security.jacc.RoleMapperFactory.provider

    値:

    weblogic.security.jacc.simpleprovider.RoleMapperFactoryImpl

ノート:

システム・プロパティ-Djakarta.security.jacc.PolicyConfigurationFactory.providerおよび-Djakarta.security.jacc.policy.providerが指定されている場合、WebLogic Serverでは、自動的にデフォルトのRoleMapperFactoryプロパティを初期化します。したがって、weblogic.security.jacc.RoleMapperFactory.providerシステム・プロパティを指定して、WebLogic JACCプロバイダを有効化する必要はありません。

たとえば、適切に構成されたweblogic.policyファイルがあれば、次のコマンド・ラインでWebLogic JACCプロバイダが有効になります。

# ./startWebLogic.sh -Djakarta.security.jacc.policy.provider=\
weblogic.security.jacc.simpleprovider.SimpleJACCPolicy \
-Djakarta.security.jacc.PolicyConfigurationFactory.provider=\
weblogic.security.jacc.simpleprovider.PolicyConfigurationFactoryImpl \