ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic Serverロールおよびポリシーによるリソースの保護
11gリリース1 (10.3.6)
B55556-04
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次

前
 
次
 

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

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

管理リソース

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

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

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

図3-1の説明が続きます
「図3-1 一部のポリシーの重なり」の説明

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

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

管理アクティビティ デフォルトのポリシーで許可されるロール JMXリソースにも保護されているか

デプロイメント用のファイルのアップロード。

AdminDeployer

いいえ

ファイル・ダウンロード・サーブレットの以下のメソッドに対する制御アクセス。

  • すべてのメソッド

  • 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で内部的に使用されます。ファイル・ダウンロード・サーブレットのメソッドに対するデフォルトのポリシーは変更しないことを推奨します。ここでは、構成全体を網羅するために表示されています。

AdminOperator

いいえ

アプリケーションでのIDアサーションの有効化。

このアクティビティのデフォルトのポリシーでは、Adminロールのユーザーが正常にAuthentication.assertIdentity() APIを呼び出すには、アプリケーションでそのユーザーにあらかじめ資格証明を提供する必要があります。

Oracle WebLogic Server APIリファレンスweblogic.security.services.Authenticationに関する項を参照してください。

Admin

いいえ

管理コンソールでのドメイン・ログとサーバー・ログの表示。

AdminDeployerOperatorMonitor

はい

アカウントからロックアウトされたユーザーのロック解除。

Admin

はい


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

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

図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 JavaBeans)リソースは、EJBデプロイメント・モジュール(JAR)、個々のEJB、またはEJBの個々のメソッドです。EJBリソースはリソースの階層内に存在し、階層の最上位がアプリケーション・リソースです。「リソースの階層の保護」を参照してください。

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 - JDBCDataSourceRuntimeMBeanclearStatementCachesuspendforceSuspendresumeshutdownforceShutdownstartgetProperties、およびpoolExistsの各メソッドはadmin操作として呼び出されます。

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


    注意:

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

  • shrink - データ・ソースの接続数を現在予約される接続の最大数または初期サイズに縮小します。

  • reset - すべての物理的なデータベース接続を停止し、再確立することで、データ・ソースの接続をリセットします。また、それぞれの接続の文キャッシュをクリアします。リセットできるデータ・ソースの接続は、正常に動作しているものに限られます。

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


    注意:

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

    • Oracleデータベースを使用している場合、Oracle仮想プライベート・データベース(Oracle Virtual Private Database : VPD)を使用してもJDBCリソースへのアクセスを制御できます。詳細は、『Oracle WebLogic Server JDBCのプログラミング』のOracle仮想プライベート・データベースを使用したプログラミングに関する項を参照してください。


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 - 宛先のsendreceive、および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 MBeanに関する項を参照してください。

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

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

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

図3-3の説明が続きます
「図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インスタンスに適用するセキュリティ・ポリシーや、個々のサーバーに適用するセキュリティ・ポリシーを作成できます。個々のサーバーに対するポリシーを定義する場合、そのサーバーのライフ・サイクル全般に渡るすべての操作を保護することも、以下の各操作に対して個別にポリシーを定義することもできます。

すべてのサーバー・リソースには、グローバル・セキュリティ・ロール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サービスは以下のリソースの階層によって保護されます。

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

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

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

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

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

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

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