3 ポリシーで保護できるリソースのタイプ

この章では、WebLogic Serverのポリシーを使用して保護できるリソースのタイプについて説明します。

この章の内容は以下のとおりです。

管理リソース
アプリケーション・リソース
COMリソース
EJBリソース
エンタープライズ情報システム(EIS)リソース
Java DataBase Connectivity (JDBC)リソース
Java Messaging Service (JMS)リソース
Java Naming and Directory Interface (JNDI)リソース
JMXリソース
サーバー・リソース
URLリソース
Webサービス・リソース
ワーク・コンテキスト・リソース
Coherenceリソース

管理リソース

管理リソースのポリシーでは、ファイルのアップロード(デプロイ中に使用)、ドメインおよびサーバーのログの表示、アカウントからロックアウトされたユーザーのロック解除といった作業を誰が実施できるのかが決定されます。

こうしたセキュリティに厳しいタスクでは多くの場合、はじめに別のJMXリソースのセキュリティ・ポリシーでユーザーが認可されている必要があります(図3-1を参照)。JMXリソースと、複数のリソースによって保護されるアクティビティのロールおよびポリシーの設計方法の詳細は、「JMXリソース」を参照してください。

図3-1 一部のポリシーの重なり

「図3-1 一部のポリシーの重なり」の説明

表3-1で、管理リソースによって保護される管理アクティビティについて説明します。また、これらのアクティビティの一部は別のJMXリソースによっても保護されます。複数のリソースによって保護されるアクティビティの場合、JMXリソースのデフォルトのポリシーが管理リソースの保護と重複します。

表3-1 管理リソースにおけるアクティビティとデフォルトのポリシー

管理アクティビティ	デフォルトのポリシーで許可されるロール	JMXリソースにも保護されているか
デプロイメント用のファイルのアップロード。	`Admin`、`Deployer`	いいえ
ファイル・ダウンロード・サーブレットの以下のメソッドに対する制御アクセス。すべてのメソッド `wl_component_request` `wl_ear_resource_request` `ear_request` `wl_xml_entity_request` `wl_jsp_refresh_request` `file` `wl_init_replica_request` `wl_file_realm_request` `wl_managed_server_independence_request` 注意: ファイル・ダウンロード・サーブレットはWebLogic Serverで内部的に使用されます。ファイル・ダウンロード・サーブレットのメソッドに対するデフォルトのポリシーは変更しないことを推奨します。ここでは、構成全体を網羅するために表示されています。	`Admin`、`Operator`	いいえ
アプリケーションでのIDアサーションの有効化。このアクティビティのデフォルトのポリシーでは、`Admin`ロールのユーザーが正常に`Authentication.assertIdentity()` APIを呼び出すには、アプリケーションでそのユーザーにあらかじめ資格証明を提供する必要があります。 Oracle WebLogic Server Java APIリファレンスの`weblogic.security.services.Authentication`を参照してください。	Admin	いいえ
管理コンソールでのドメイン・ログとサーバー・ログの表示。	`Admin`、`Deployer`、`Operator`、`Monitor`	はい
アカウントからロックアウトされたユーザーのロック解除。	Admin	はい

アプリケーション・リソース

アプリケーション・リソースは、エンタープライズ・アプリケーション、Webアプリケーション、またはスタンドアロンのアプリケーションとしてデプロイされるその他のJava EEモジュールです(たとえば、WebサービスやJDBCモジュールをスタンドアロンのアプリケーションとしてデプロイできます)。アプリケーションを構成するすべてのリソースを保護する場合には、アプリケーション・リソースを保護します。たとえば、エンタープライズ・アプリケーションを保護することによって、そのアプリケーション内のすべてのWebLogicリソースへのアクセスが保護されます。(図3-2を参照)

図3-2 アプリケーション・リソースによるすべてのリソースの保護

「図3-2 アプリケーション・リソースによるすべてのリソースの保護」の説明

「リソースの階層の保護」を参照してください。

COMリソース

COMリソースは、1つまたは複数のjCOMクラスを含むパッケージです。jCOMは、WebLogic ServerでデプロイされるJava/Java EEオブジェクトと、Microsoft Office製品ファミリ、Visual BasicオブジェクトおよびC++オブジェクト、その他のコンポーネント・オブジェクト・モデル/分散コンポーネント・オブジェクト・モデル(COM/DCOM準拠)環境で使用できるMicrosoft ActiveXコンポーネントとの間で双方向アクセスを可能にするソフトウェア・ブリッジです。

COMリソースのポリシーによって、パッケージ内のすべてのjCOMオブジェクトへのアクセスは保護されます。

関連情報は、『Oracle WebLogic Server JCOMアプリケーションの開発』のアクセス・コントロールに関する項を参照してください。

EJBリソース

EJB (Enterprise JavaBean)リソースは、EJBデプロイメント・モジュール(JAR)、個々のEJB、またはEJBの個々のメソッドです。EJBリソースはリソースの階層内に存在し、階層の最上位がアプリケーション・リソースです。付録2「リソースの階層の保護」を参照してください。

Java EEプラットフォームはデプロイメント記述子でEJBのセキュリティを標準化しているので、WebLogic Serverではこの標準メカニズムがWebLogicセキュリティ・サービスに統合され、EJBリソースを保護する方法を選択できるようになっています。詳細は、第4章「WebアプリケーションおよびEJBリソースの保護のオプション」を参照してください。

エンタープライズ情報システム(EIS)リソース

EISリソースは、システム・レベルのソフトウェア・ドライバであり、WebLogic Serverなどのアプリケーション・サーバーでエンタープライズ情報システム(EIS)に接続するために使用されます。Oracleでは、EISベンダーおよびサード・パーティのアプリケーション開発者によって開発されたリソース・アダプタをサポートしています。リソース・アダプタは、適切なJava EEプラットフォーム仕様をサポートしているアプリケーション・サーバーであればどのサーバーにもデプロイできます。リソース・アダプタには、Javaコードに加えて、必要な場合にはEISとの対話に必要なネイティブ・コンポーネントが含まれます。

EISへのアクセスを保護するには、グループとしてすべてのリソース・アダプタに対して、または個々のリソース・アダプタに対してセキュリティ・ポリシーとセキュリティ・ロールを作成します。これらのリソースはリソースの階層内に存在し、階層の最上位がアプリケーション・リソースです。「リソースの階層の保護」を参照してください。

関連情報は、『Oracle WebLogic Serverリソース・アダプタの開発』のセキュリティに関する項を参照してください。

Java DataBase Connectivity (JDBC)リソース

Java DataBase Connectivity (JDBC)リソースは、JDBCシステム・リソース、アプリケーションの一部となるJDBCモジュール、JDBCデータ・リソース、またはデータ・ソース内の特定のメソッドです。JDBCモジュールをスタンドアロンのアプリケーションとしてデプロイする場合、アプリケーションはアプリケーション・リソースによって表されます(「アプリケーション・リソース」を参照)。

JDBCリソースはリソースの階層内に存在し、階層の最上位がアプリケーション・リソースです。「リソースの階層の保護」を参照してください。

JDBC操作

個々のデータ・ソースを保護する場合、以下に示す1つまたは複数の管理者用メソッドを使用してJDBC操作を保護するかどうかを選択できます。

admin - JDBCDataSourceRuntimeMBeanのclearStatementCache、suspend、forceSuspend、resume、shutdown、forceShutdown、start、getProperties、およびpoolExistsの各メソッドはadmin操作として呼び出されます。

reserve - アプリケーションでは、データ・ソースをルックアップしてからgetConnectionを呼び出すことにより、データ・ソース内で接続を予約します。

注意:

reserveパーミッションを与えるとユーザーはベンダー固有の操作を実行できるようになります。データベース・ベンダーによっては、こうした操作の一部がデータベースのセキュリティに影響する場合があります。

shrink - データ・ソースの接続数を現在予約される接続の最大数または初期サイズに縮小します。
reset - すべての物理的なデータベース接続を停止し、再確立することで、データ・ソースの接続をリセットします。また、それぞれの接続の文キャッシュをクリアします。リセットできるデータ・ソースの接続は、正常に動作しているものに限られます。

All - 個々のデータ・ソースは、管理者用メソッドAdmin、reserve、shrink、およびresetの結合によって保護されます。

注意:

セキュリティ・ポリシーでマルチ・データ・ソース内の接続へのアクセスを制御している場合は、アクセス・チェックがJDBCリソース階層の両方のレベルで行われます(まずマルチ・データ・ソース・レベルで行われ、次に個々のデータ・ソース・レベルで行われます)。すべてのタイプのWebLogicリソースと同じように、こうした二重チェックを行うことで、セキュリティ・ポリシーによる最も限定したアクセス制御を確実に行うことができます。

Java Messaging Service (JMS)リソース

Java Messaging Service (JMS)リソースは、JMSシステム・リソース、アプリケーションの一部となるJMSモジュール、JMS宛先、または宛先内の操作です。グループとしてすべての宛先(JMSキューおよびJMSトピック)に対して、またはJMSサーバー上の個々の宛先(JMSキューおよびJMSトピック)に対してセキュリティ・ポリシーとセキュリティ・ロールを作成できます。

これらのリソースはリソースの階層内に存在し、階層の最上位がアプリケーション・リソースです。「リソースの階層の保護」を参照してください。

JMS操作

JMSサーバーの特定の宛先を保護する場合、その宛先の操作を保護できます。デフォルトでは宛先は保護されていません。つまり、WebLogic Serverインスタンスの有効なユーザーであれば、誰でも宛先に対してメッセージの送受信や参照ができることになります。ポリシー条件に定義されているユーザーのみが宛先のアクセスを制御できます。有効な保護対象の操作は以下のとおりです。

send - キューまたはトピックにメッセージを送信するために必要です。メッセージング・ブリッジだけでなく、MessageProducer.send()、QueueSender.send()、およびTopicPublisher.publish()の各メソッドの呼出しも含まれています。
receive - キューまたはトピックでコンシューマを作成するために必要です。メッセージング・ブリッジおよびメッセージドリブンBeanに加えて、Session.createConsumer()、Session.createDurableSubscriber()、QueueSession.createReceiver()、TopicSession.createSubscriber()、TopicSession.createDurableSubscriber()、Connection.createConnectionConsumer()、Connection.createDurableConnectionConsumer()、QueueConnection.createConnectionConsumer()、TopicConnection.createConnectionConsumer()、およびTopicConnection.createDurableConnectionConsumer()の各メソッドの呼出しも含まれています。
browse - QueueBrowserインタフェースを使用してキューのメッセージを表示するために必要です。
All - 宛先のsend、receive、およびbrowseメソッドのために必要です。

Java Naming and Directory Interface (JNDI)リソース

Java Naming and Directory Interface (JNDI)リソースは、サーバーのJNDIツリーのノードです。JNDIリソースのポリシーでは、JNDIを通じてWebLogic Serverのエンティティおよびアクションに誰がアクセスできるのかが決定されます。ポリシーは、JNDIツリーのルート・ノードまたは個々のノードに作成できます。

JNDI操作

JNDIノードごとに、すべての操作または以下の操作のいずれかに対してポリシーを作成できます。

modify - アプリケーションでJNDIツリーを何らかの方法で修正(つまり追加、削除、変更)するときには、現在のユーザーに必ず修正のパーミッションが必要です。bind()、rebind()、createSubContext()、destroySubContext()、およびunbind()の各メソッドが含まれています。
lookup - アプリケーションでJNDIツリーのオブジェクトをルックアップするときには、現在のユーザーにルックアップのパーミッションが必要です。lookup()メソッドおよびlookupLink()メソッドが含まれています。
list - アプリケーションでJNDIのコンテキストの内容をリストするときには、現在のユーザーにリスト操作を実行するパーミッションが必要です。list()メソッドおよびlistBindings()メソッドが含まれています。

JMXリソース

JMXリソースは、MBean属性またはMBean操作です。JMXリソースのポリシーでは、MBean属性の読み取りまたは書き込み、または操作の呼出しを誰が実施できるのかが決定されます。

WebLogic Serverの管理システム実装では、管理対象Bean (MBean)が使用されます。ほとんどすべての管理アクティビティで、MBeanの操作の呼出しやMBean属性の変更が必要になります。これにはJava Management Extensions (JMX)クライアントを使用します。JMXクライアントの例として管理コンソールがあります。管理コンソールを使用してサーバーのリスニング・ポートの値を変更すると、対応するMBean属性の値が管理コンソールによって変更されます。また、WebLogic Scripting ToolもJMXクライアントです。詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のWebLogic Server MBeansの理解に関する項を参照してください。

WebLogic Server MBeanを保護するためのJMXリソースのデフォルト・セットが用意されています。(Oracle WebLogic Server MBeanリファレンスのMBeanのデフォルトのセキュリティ・ポリシーに関する項を参照。)特に重要なデータやアクションを表すMBeanの属性と操作の場合、別のリソース・タイプも使用してアクセスを保護します。たとえば、ServerLifeCycleRuntimeMBeanのshutdown()操作はJMXリソースとサーバー・リソースによって保護されます。

JMXクライアントで、JMXリソースと他のリソース・タイプで保護されている操作を呼び出したり属性を変更したりする場合、クライアントは両方のリソースに定義されているポリシーに合致している必要があります(図3-3を参照)。

図3-3 MBeanサーバーの両方のリソースによる検証

「図3-3 MBeanサーバーの両方のリソースによる検証」の説明

一貫性のあるセキュリティ方式の維持

エンティティやアクションを保護するのに使用されるすべてのリソースのグループ、グローバル・ロール、セキュリティ・ポリシーのデフォルト構成によって、一貫性のあるセキュリティ方式が作成されます。しかし、変更を行うことで、意図しないアクセス制限が発生する場合があります。デフォルトのセキュリティ設定に対する変更が、JMXリソースと別のリソースの両方のリソース・タイプによるユーザーの認可を妨げないことを確認してください。セキュリティ・ポリシーを作成または変更する際には、以下のことを検討します。

サーバー・リソースのポリシーに、常にAdminグローバル・ロールとOperatorグローバル・ロールを含めます。

Operatorグローバル・ロール、またはこのデフォルト・グローバル・ロール内にネストされたセキュリティ・ロールが使用できない場合、WebLogicセキュリティ・サービスで矛盾した動作が発生する場合があります。
Webアプリケーション、EJBモジュール、コネクタ・モジュール、起動/停止クラスなどのデプロイ可能リソースのセキュリティ・ポリシーでは、Deployerグローバル・ロールを使用します。

サーバー・リソース

サーバー・リソースのポリシーでは、WebLogic Serverのサーバー・インスタンスの状態を誰が制御できるのかが決定されます。

ユーザーが直接Javaコマンドでweblogic.Serverクラスを呼び出してサーバー・インスタンスを起動する場合、サーバー・リソースのポリシーによるセキュリティ・チェックのみが実施されます。WebLogic Serverインスタンスの状態を変更する他のすべてのタスクは、管理コンソール、WebLogic Scripting Tool、ノード・マネージャ、または他のJMXクライアントを使用する必要があります。したがって、ユーザーが最初に別のJMXリソースで認可されている必要があります。「JMXリソース」を参照してください。

ドメイン内のすべてのWebLogic Serverインスタンスに適用するセキュリティ・ポリシーや、個々のサーバーに適用するセキュリティ・ポリシーを作成できます。個々のサーバーに対するポリシーを定義する場合、そのサーバーのライフ・サイクル全般に渡るすべての操作を保護することも、以下の各操作に対して個別にポリシーを定義することもできます。

boot - WebLogic Serverインスタンス(管理サーバーまたは管理対象サーバー)を起動しようとするユーザーには、そのためのパーミッションが必要です。このアクションは通常、コマンド・ラインでのjava weblogic.Serverコマンドの呼び出し、構成されている起動スクリプト(java weblogic.Serverコマンドを呼び出す)、またはノード・マネージャのWebLogic Serverをリモートで起動できる機能を通じて開始します。
shutdown - 動作中のWebLogic Serverインスタンス(管理サーバーまたは管理対象サーバー)を停止しようとするユーザーには、そのためのパーミッションが必要です。このアクションは通常、WebLogic Server管理コンソール、またはWLST SHUTDOWNコマンドかFORCESHUTDOWNコマンドを通じて開始します。
suspend - 動作中のWebLogic Serverインスタンス(管理サーバーまたは管理対象サーバー)への追加ログイン(特権のある管理アクション以外を目的としたログイン)を禁止しようとするユーザーには、そのためのパーミッションが必要です。このアクションは通常、管理コンソールから開始します。
resume - 動作中のWebLogic Serverインスタンス(管理サーバーまたは管理対象サーバー)への特権のないログインを再び有効にしようとするユーザーには、そのためのパーミッションが必要です。このアクションは通常、管理コンソールから開始します。

すべてのサーバー・リソースには、グローバル・セキュリティ・ロールAdminおよびOperatorにパーミッションを付与するデフォルト・セキュリティ・ポリシーが継承されます。

注意:

ドメイン全体の管理ポートを有効にする場合、AdminロールのみがWebLogic Serverサーバー・インスタンスの状態を制御できます(Operatorでは制御できません)。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのドメイン全体の管理ポートの構成に関する項を参照してください。

警告:

デフォルト・セキュリティ・ポリシーからはロールを削除しないでください。既存のセキュリティ・ロールの一部を削除すると、WebLogic Serverの動作に悪影響を与えることがあります。ただし、必要に応じて、デフォルト・セキュリティ・ポリシーにより多くを含めることはできます(たとえば、新しいセキュリティ・ロールを追加するなど)。「一貫性のあるセキュリティ方式の維持」を参照してください。

weblogic.Serverコマンド、ノード・マネージャのパーミッション

WebLogic Serverインスタンス(サーバー)を起動および停止するには、weblogic.Serverコマンドを使用する方法とノード・マネージャを使用する方法があります。weblogic.Serverコマンドとノード・マネージャでは基底のコンポーネントが異なるため、これら2つのコマンドでは異なる認可方法が使用されます。

weblogic.Serverコマンドを使用したパーミッション

weblogic.Serverコマンド(管理サーバーと管理対象サーバーの両方の起動に使用可能)では、サーバー・リソースのセキュリティ・ポリシーで保護されたメソッドが呼び出されます。このコマンドを使用するには、サーバー・リソースのセキュリティ・ポリシーの要件を満たす必要があります。

weblogic.Serverの引数の中にはMBeanの属性を設定するものもあります。ただし、これらの引数ではサーバーが実行中の状態(RUNNING)になる前にMBeanを変更するので、MBeanの保護ではなく、サーバー・リソースのセキュリティ・ポリシーによって認可されます。たとえば、Operatorグローバル・ロールに属するユーザーは-Dweblogic.ListenPort引数を使用してサーバーのデフォルトのリスニング・ポートを変更できますが、WebLogic Serverインスタンスが実行中の状態になると、このユーザーはリスニング・ポートの値を変更できません。

weblogic.Serverの詳細は、『Oracle WebLogic Serverコマンド・リファレンス』のweblogic.Serverコマンドライン・リファレンスに関する項を参照してください。

ノード・マネージャを使用したパーミッション

ノード・マネージャを使用すると、MBeanとサーバー・リソースのセキュリティ・ポリシーの両方を使用してリモート・サーバーを起動できます。

リモートWebLogic Serverインスタンスのホスト・マシン上にノード・マネージャが構成されている場合、デフォルトでAdminグローバル・ロールまたはOperatorグローバル・ロールに属するユーザーはノード・マネージャを使用してリモート・サーバーを起動できます。

詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャの概要に関する項を参照してください。

WebLogic Serverインスタンスの停止においてもMBeanとサーバー・リソースのセキュリティ・ポリシーの両方が関与します。ユーザーが停止コマンドを発行すると、サーバーではまず、MBeanセキュリティ・レイヤーによってそのユーザーにAdminまたはOperatorグローバル・ロールが付与されているかどうかが確認されます。続いて、MBean操作の実行後、サーバー・リソースのセキュリティ・ポリシーによって、そのユーザーがサーバーを停止する権限を持っているかどうかが判別されます。

WebLogic Serverインスタンスのシャットダウンの詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバーの起動と停止: クイック・リファレンスに関する項を参照してください。

URLリソース

URLリソースは、Webアプリケーションの特定のURLまたはURLパターンです。特定のURLまたはURLパターンのすべてのHTTPメソッドを保護するURLリソースに対して、または特定のHTTPメソッドのみを保護するURLリソースに対してポリシーを作成できます。これらのリソースはリソースの階層内に存在し、階層の最上位がアプリケーション・リソースです。「リソースの階層の保護」を参照してください。

Java EEプラットフォームはデプロイメント記述子でWebアプリケーションのセキュリティを標準化しているので、WebLogic Serverではこの標準メカニズムがWebLogicセキュリティ・サービスに統合され、Webアプリケーション・リソースを保護する方法を選択できるようになっています。詳細は、第4章「WebアプリケーションおよびEJBリソースの保護のオプション」を参照してください。

Webサービス・リソース

Webサービス・リソースは、Webサービス・モジュール(WARやJAR)、またはWebサービス・モジュールの操作です。Webサービスは以下のリソースの階層によって保護されます。

親アプリケーションのアプリケーション・リソース
Webサービス・モジュール(WARまたはJAR)のWebサービス・リソース
各Webサービス操作の個々のWebサービス・リソース

Webサービスが標準Javaオブジェクトを使用して実装されている場合、上記のいずれかのリソースによってJavaオブジェクトは保護されます。

WebサービスがEJBを使用して実装されている場合、上記のいずれかのリソースまたは以下のいずれかのリソースによってEJB実装は保護されます。
- EJBのEJBリソース
- EJBメソッドの個々のEJBリソース

EJBを使用してWebサービスを実装する場合、アプリケーション・レベルでポリシーを作成することをお薦めします。Webサービス・モジュールおよびWebサービス操作に対するポリシーは、Webサービス・クライアントにのみ適用されます。EJBクライアントは、RMIまたはJNDIを使用して、Webサービス・モジュールを経由せずにEJB操作を直接呼び出すことができます(図3-4を参照)。

図3-4 EJB実装を使用したWebサービス・リソースの階層

「図3-4 EJB実装を使用したWebサービス・リソースの階層」の説明

JavaアノテーションによるWebサービスの保護については、『Oracle WebLogic Server WebLogic Webサービスの保護』のメッセージ・レベルのセキュリティに関する項を参照してください。

ワーク・コンテキスト・リソース

Java EEの開発者はワーク・コンテキストを使用すると、プロパティをリモート呼出しに含めずに定義して渡すことが可能です。ワーク・コンテキスト・リソースは、プロパティの作成、削除、読み取り、または変更を行う操作です。特定のプロパティのすべての操作に対して1つのワーク・コンテキスト・リソースを使用できます。また、操作ごとに個々のリソースを作成することもできます。

詳細は、『Oracle WebLogic Server RMIアプリケーションの開発』のアプリケーション設計のベストプラクティスに関する項を参照してください。

Coherenceリソース

Coherenceリソースにより、分散型のメモリー内キャッシュ機能およびデータ・グリッド処理がアプリケーションで使用できるようになります。ロールとポリシーは、次の2つのタイプのCoherenceリソースに適用できます。

キャッシュ: 1つのクラスタ内に、任意の数のキャッシュが含まれます。これらのキャッシュは、すべてのクラスタ・メンバーが共有します。アプリケーションは、データの格納や取得に、これらのキャッシュを使用します。
サービス: 1つのクラスタ内に、任意の数のサービスが含まれます。これらのサービスは、すべてのクラスタ・メンバーが共有します。これらのサービスには、接続サービス、キャッシュ・サービス、処理サービスなどが含まれます。各クラスタ・メンバーでは、このようなサービスの提供や利用が可能です。

デフォルトの認可ポリシーでは、誰でもすべてのCoherenceリソースにアクセスできます。キャッシュやサービスにポリシーとロールを定義するには、そのキャッシュやサービスの名前を知っている必要があります。Coherenceグリッド・アーカイブ(GAR)モジュール内のキャッシュ構成ファイルを調べることで、キャッシュ名やサービス名が見つかる場合もあります。ただし、アプリケーションが同一のキャッシュを異なる名前で参照できるようにしている構成もあります。アプリケーションが使用するキャッシュ名とサービス名を確認する場合は、必ずアプリケーションの開発者または設計者に問い合せてください。