Oracle® Fusion Middleware Oracle WebLogic Serverロールおよびポリシーによるリソースの保護 12c (12.2.1.1.0) E77284-01 |
|
前 |
次 |
この章の内容は以下のとおりです。
管理リソースのポリシーでは、ファイルのアップロード(デプロイ中に使用)、ドメインおよびサーバーのログの表示、アカウントからロックアウトされたユーザーのロック解除といった作業を誰が実施できるのかが決定されます。
こうしたセキュリティに厳しいタスクでは多くの場合、はじめに別のJMXリソースのセキュリティ・ポリシーでユーザーが認可されている必要があります(図3-1を参照)。JMXリソースと、複数のリソースによって保護されるアクティビティのロールおよびポリシーの設計方法の詳細は、「JMXリソース」を参照してください
表3-1で、管理リソースによって保護される管理アクティビティについて説明します。また、これらのアクティビティの一部は別のJMXリソースによっても保護されます。複数のリソースによって保護されるアクティビティの場合、JMXリソースのデフォルトのポリシーが管理リソースの保護と重複します。
表3-1 管理リソースにおけるアクティビティとデフォルトのポリシー
管理アクティビティ | デフォルトのポリシーで許可されるロール | JMXリソースにも保護されているか |
---|---|---|
デプロイメント用のファイルのアップロード。 |
|
いいえ |
ファイル・ダウンロード・サーブレットの以下のメソッドに対する制御アクセス。
注意: ファイル・ダウンロード・サーブレットはWebLogic Serverで内部的に使用されます。ファイル・ダウンロード・サーブレットのメソッドに対するデフォルトのポリシーは変更しないことを推奨します。ここでは、構成全体を網羅するために表示されています。 |
|
いいえ |
アプリケーションでのIDアサーションの有効化。 このアクティビティのデフォルトのポリシーでは、 Oracle WebLogic Server Java APIリファレンスの |
Admin |
いいえ |
WebLogic Server管理コンソールでのドメイン・ログとサーバー・ログの表示。 |
|
はい |
アカウントからロックアウトされたユーザーのロック解除。 |
Admin |
はい |
アプリケーション・リソースは、エンタープライズ・アプリケーション、Webアプリケーション、またはスタンドアロンのアプリケーションとしてデプロイされるその他のJava EEモジュールです(たとえば、WebサービスやJDBCモジュールをスタンドアロンのアプリケーションとしてデプロイできます)。アプリケーションを構成するすべてのリソースを保護する場合には、アプリケーション・リソースを保護します。たとえば、エンタープライズ・アプリケーションを保護することによって、そのアプリケーション内のすべてのWebLogicリソースへのアクセスが保護されます。(図3-2を参照)
「リソースの階層の保護」を参照してください
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 (Enterprise JavaBeans)リソースは、EJBデプロイメント・モジュール(JAR)、個々のEJB、またはEJBの個々のメソッドです。EJBリソースはリソースの階層内に存在し、階層の最上位がアプリケーション・リソースです。「リソースの階層の保護」を参照してください
Java EEプラットフォームはデプロイメント記述子でEJBのセキュリティを標準化しているので、WebLogic Serverではこの標準メカニズムがWebLogicセキュリティ・サービスに統合され、EJBリソースを保護する方法を選択できるようになっています。詳細は、「WebアプリケーションおよびEJBリソースの保護のオプション」を参照してください。
EISリソースは、システム・レベルのソフトウェア・ドライバであり、WebLogic Serverなどのアプリケーション・サーバーでエンタープライズ情報システム(EIS)に接続するために使用されます。Oracleでは、EISベンダーおよびサード・パーティのアプリケーション開発者によって開発されたリソース・アダプタをサポートしています。リソース・アダプタは、適切なJava EEプラットフォーム仕様をサポートしているアプリケーション・サーバーであればどのサーバーにもデプロイできます。リソース・アダプタには、Javaコードに加えて、必要な場合にはEISとの対話に必要なネイティブ・コンポーネントが含まれます。
EISへのアクセスを保護するには、グループとしてすべてのリソース・アダプタに対して、または個々のリソース・アダプタに対してセキュリティ・ポリシーとセキュリティ・ロールを作成します。これらのリソースはリソースの階層内に存在し、階層の最上位がアプリケーション・リソースです。「リソースの階層の保護」を参照してください
関連情報は、『Oracle WebLogic Serverリソース・アダプタの開発』のセキュリティに関する項を参照してください。
Java DataBase Connectivity (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)リソースは、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)リソースは、サーバーのJNDIツリーのノードです。JNDIリソースのポリシーでは、JNDIを通じてWebLogic Serverのエンティティおよびアクションに誰がアクセスできるのかが決定されます。ポリシーは、JNDIツリーのルート・ノードまたは個々のノードに作成できます。
JNDIノードごとに、すべての操作または以下の操作のいずれかに対してポリシーを作成できます。
modify
- アプリケーションでJNDIツリーを何らかの方法で修正(つまり追加、削除、変更)するときには、現在のユーザーに必ず修正のパーミッションが必要です。bind()
、rebind()
、createSubContext()
、destroySubContext()
、およびunbind()
の各メソッドが含まれています。
lookup
- アプリケーションでJNDIツリーのオブジェクトをルックアップするときには、現在のユーザーにルックアップのパーミッションが必要です。lookup()
メソッドおよびlookupLink()
メソッドが含まれています。
list
- アプリケーションでJNDIのコンテキストの内容をリストするときには、現在のユーザーにリスト操作を実行するパーミッションが必要です。list()
メソッドおよびlistBindings()
メソッドが含まれています。
JMXリソースは、MBean属性またはMBean操作です。JMXリソースのポリシーでは、MBean属性の読み取りまたは書き込み、または操作の呼出しを誰が実施できるのかが決定されます。
WebLogic Serverの管理システム実装では、管理対象Bean (MBean)が使用されます。ほとんどすべての管理アクティビティで、MBeanの操作の呼出しやMBean属性の変更が必要になります。これにはJava Management Extensions (JMX)クライアントを使用します。JMXクライアントの例としてWebLogic Server管理コンソールがあります。WebLogic Server管理コンソールを使用してサーバーのリスニング・ポートの値を変更すると、対応する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を参照)。
エンティティやアクションを保護するのに使用されるすべてのリソースのグループ、グローバル・ロール、セキュリティ・ポリシーのデフォルト構成によって、一貫性のあるセキュリティ方式が作成されます。しかし、変更を行うことで、意図しないアクセス制限が発生する場合があります。デフォルトのセキュリティ設定に対する変更が、JMXリソースと別のリソースの両方のリソース・タイプによるユーザーの認可を妨げないことを確認してください。セキュリティ・ポリシーを作成または変更する際には、以下のことを検討します。
サーバー・リソースのポリシーに、常にAdmin
グローバル・ロールとOperator
グローバル・ロールを含めます。
Operator
グローバル・ロール、またはこのデフォルト・グローバル・ロール内にネストされたセキュリティ・ロールが使用できない場合、WebLogicセキュリティ・サービスで矛盾した動作が発生する場合があります。
Webアプリケーション、EJBモジュール、コネクタ・モジュール、起動/停止クラスなどのデプロイ可能リソースのセキュリティ・ポリシーでは、Deployer
グローバル・ロールを使用します。
サーバー・リソースのポリシーでは、WebLogic Serverのサーバー・インスタンスの状態を誰が制御できるのかが決定されます。
ユーザーが直接Javaコマンドでweblogic.Server
クラスを呼び出してサーバー・インスタンスを起動する場合、サーバー・リソースのポリシーによるセキュリティ・チェックのみが実施されます。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インスタンス(管理サーバーまたは管理対象サーバー)への追加ログイン(特権のある管理アクション以外を目的としたログイン)を禁止しようとするユーザーには、そのためのパーミッションが必要です。このアクションは通常、WebLogic Server管理コンソールから開始します。
resume
- 動作中のWebLogic Serverインスタンス(管理サーバーまたは管理対象サーバー)への特権のないログインを再び有効にしようとするユーザーには、そのためのパーミッションが必要です。このアクションは通常、WebLogic Server管理コンソールから開始します。
すべてのサーバー・リソースには、グローバル・セキュリティ・ロールAdmin
およびOperator
にパーミッションを付与するデフォルト・セキュリティ・ポリシーが継承されます。
注意:
ドメイン全体の管理ポートを有効にする場合、Admin
ロールのみがWebLogic Serverサーバー・インスタンスの状態を制御できます(Operator
では制御できません)。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのドメイン全体の管理ポートの構成に関する項を参照してください。
注意:
デフォルト・セキュリティ・ポリシーからはロールを削除しないでください。既存のセキュリティ・ロールの一部を削除すると、WebLogic Serverの動作に悪影響を与えることがあります。ただし、必要に応じて、デフォルト・セキュリティ・ポリシーにより多くを含めることはできます(たとえば、新しいセキュリティ・ロールを追加するなど)。「一貫性のあるセキュリティ方式の維持」を参照してください
WebLogic Serverインスタンス(サーバー)を起動および停止するには、weblogic.Server
コマンドを使用する方法とノード・マネージャを使用する方法があります。weblogic.Server
コマンドとノード・マネージャでは基底のコンポーネントが異なるため、これら2つのコマンドでは異なる認可方法が使用されます。
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リソースは、Webアプリケーションの特定のURLまたはURLパターンです。特定のURLまたはURLパターンのすべてのHTTPメソッドを保護するURLリソースに対して、または特定のHTTPメソッドのみを保護するURLリソースに対してポリシーを作成できます。これらのリソースはリソースの階層内に存在し、階層の最上位がアプリケーション・リソースです。「リソースの階層の保護」を参照してください
Java EEプラットフォームはデプロイメント記述子でWebアプリケーションのセキュリティを標準化しているので、WebLogic Serverではこの標準メカニズムがWebLogicセキュリティ・サービスに統合され、Webアプリケーション・リソースを保護する方法を選択できるようになっています。詳細は、「WebアプリケーションおよびEJBリソースの保護のオプション」を参照してください。
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を参照)。
JavaアノテーションによるWebサービスの保護については、『Oracle WebLogic Server WebLogic Webサービスの保護』のメッセージ・レベルのセキュリティに関する項を参照してください。
Java EEの開発者はワーク・コンテキストを使用すると、プロパティをリモート呼出しに含めずに定義して渡すことが可能です。ワーク・コンテキスト・リソースは、プロパティの作成、削除、読み取り、または変更を行う操作です。特定のプロパティのすべての操作に対して1つのワーク・コンテキスト・リソースを使用できます。また、操作ごとに個々のリソースを作成することもできます。
詳細は、『Oracle WebLogic Server RMIアプリケーションの開発』のアプリケーション設計のベストプラクティスに関する項を参照してください。
Coherenceリソースにより、分散型のメモリー内キャッシュ機能およびデータ・グリッド処理がアプリケーションで使用できるようになります。ロールとポリシーは、次の2つのタイプのCoherenceリソースに適用できます。
キャッシュ: 1つのクラスタ内に、任意の数のキャッシュが含まれます。これらのキャッシュは、すべてのクラスタ・メンバーが共有します。アプリケーションは、データの格納や取得に、これらのキャッシュを使用します。
サービス: 1つのクラスタ内に、任意の数のサービスが含まれます。これらのサービスは、すべてのクラスタ・メンバーが共有します。これらのサービスには、接続サービス、キャッシュ・サービス、処理サービスなどが含まれます。各クラスタ・メンバーでは、このようなサービスの提供や利用が可能です。
デフォルトの認可ポリシーでは、誰でもすべてのCoherenceリソースにアクセスできます。キャッシュやサービスにポリシーとロールを定義するには、そのキャッシュやサービスの名前を知っている必要があります。Coherenceグリッド・アーカイブ(GAR)モジュール内のキャッシュ構成ファイルを調べることで、キャッシュ名やサービス名が見つかる場合もあります。ただし、アプリケーションが同一のキャッシュを異なる名前で参照できるようにしている構成もあります。アプリケーションが使用するキャッシュ名とサービス名を確認する場合は、必ずアプリケーションの開発者または設計者に問い合せてください。