|
|
以下の節では、ポリシーを使用して保護できるリソースのタイプについて説明します。
管理リソースのポリシーでは、ファイルのアップロード (デプロイ中に使用)、ドメインおよびサーバのログの表示、アカウントからロックアウトされたユーザのロック解除といった作業を誰が実施できるのかが決定されます。
こうしたセキュリティに厳しいタスクでは多くの場合、はじめに別の JMX リソースのセキュリティ ポリシーでユーザが認可されている必要があります (図 3-1 を参照)。JMX リソースと、複数のリソースによって保護されるアクティビティのロールおよびポリシーの設計方法の詳細については、「JMX リソース」を参照してください。
表 3-1 で、管理リソースによって保護される管理アクティビティについて説明します。また、これらのアクティビティの一部は別の JMX リソースによっても保護されます。複数のリソースによって保護されるアクティビティの場合、JMX リソースのデフォルトのポリシーが管理リソースの保護と重複します。
|
||||
Admin ロールのユーザが正常に Authentication.assertIdentity() API を呼び出すには、アプリケーションでそのユーザにあらかじめ資格を提供する必要がある。
weblogic.security.services.Authentication」を参照。
|
||||
アプリケーション リソースは、エンタープライズ アプリケーション、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 オブジェクトへのアクセスは保護されます。
関連する情報については、『WebLogic jCOM プログラマーズ ガイド』の「アクセス制御のコンフィグレーション」を参照してください。
EJB (エンタープライズ JavaBean) リソースは、EJB デプロイメント モジュール (JAR)、個々の EJB、または EJB の個々のメソッドです。EJB リソースはリソースの階層内に存在し、階層の最上位がアプリケーション リソースです。「リソースの階層を保護する」を参照してください。
Java EE プラットフォームはデプロイメント記述子で EJB のセキュリティを標準化しているので、WebLogic Server ではこの標準メカニズムが WebLogic Security サービスに統合され、EJB リソースを保護する方法を選択できるようになっています。詳細については、「Web アプリケーションおよび EJB リソースの保護のオプション」を参照してください。
EIS リソースは、システム レベルのソフトウェア ドライバであり、WebLogic Server などのアプリケーション サーバでエンタープライズ情報システム (EIS) に接続するために使用されます。Oracle では、EIS ベンダおよびサード パーティのアプリケーション開発者によって開発されたリソース アダプタをサポートしています。リソース アダプタは、適切な Sun Microsystems の Java EE プラットフォーム仕様をサポートしているアプリケーション サーバであればどのサーバにもデプロイできます。リソース アダプタには、Java コードに加えて、必要な場合には EIS との対話に必要なネイティブ コンポーネントが含まれます。
EIS へのアクセスを保護するには、グループとしてすべてのリソース アダプタに対して、または個々のリソース アダプタに対してセキュリティ ポリシーとセキュリティ ロールを作成します。これらのリソースはリソースの階層内に存在し、階層の最上位がアプリケーション リソースです。「リソースの階層を保護する」を参照してください。
関連する情報については、『WebLogic リソース アダプタ プログラマーズ ガイド』の「セキュリティ」を参照してください。
Java DataBase Connectivity (JDBC) リソースは、JDBC システム リソース、アプリケーションの一部となる JDBC モジュール、JDBC データ リソース、またはデータ ソース内の特定のメソッドです。JDBC モジュールをスタンドアロンのアプリケーションとしてデプロイする場合、アプリケーションはアプリケーション リソースによって表されます (「アプリケーション リソース」を参照)。
JDBC リソースはリソースの階層内に存在し、階層の最上位がアプリケーション リソースです。「リソースの階層を保護する」を参照してください。
個々のデータ ソースを保護する場合、以下に示す 1 つまたは複数の管理者用メソッドを使用して JDBC オペレーションを保護するかどうかを選択できます。
| 注意 : | reserve パーミッションを与えるとユーザはベンダ固有のオペレーションを実行できるようになります。データベース ベンダによっては、こうしたオペレーションの一部がデータベースのセキュリティに影響する場合があります。 |
| 注意 : | セキュリティ ポリシーでマルチ データ ソース内の接続へのアクセスを制御している場合は、アクセス チェックが JDBC リソース階層の両方のレベルで行われます (まずマルチ データ ソース レベルで行われ、次に個々のデータ ソース レベルで行われます)。すべてのタイプの WebLogic リソースと同じように、こうした二重チェックを行うことで、セキュリティ ポリシーによる最も限定したアクセス制御を確実に行うことができます。 |
| 注意 : | Oracle データベースを使用している場合、Oracle 仮想プライベート データベース (Oracle Virtual Private Database : VPD) を使用しても JDBC リソースへのアクセスを制御できます。詳細については、『WebLogic JDBC プログラマーズ ガイド』の「Oracle 仮想プライベート データベースを使用したプログラミング」を参照してください。 |
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 インタフェースを使用してキューのメッセージを表示するために必要です。 すべて - 送り先の 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 クライアントの例として Administration Console があります。Administration Console を使用してサーバのリスン ポートの値を変更すると、対応する MBean 属性の値が Administration Console によって変更されます。また、WebLogic Scripting Tool も JMX クライアントです。詳細については、『JMX によるカスタム管理ユーティリティの開発』の「WebLogic Server MBean について」を参照してください。
WebLogic Server MBean を保護するための JMX リソースのデフォルト セットが用意されています (『WebLogic Server MBean リファレンス』の「Default Security Policies for MBeans」を参照)。特に重要なデータやアクションを表す MBean の属性とオペレーションの場合、別のリソース タイプも使用してアクセスを保護します。たとえば、ServerLifeCycleRuntimeMBean の shutdown() オペレーションは JMX リソースとサーバ リソースによって保護されます。
JMX クライアントで、JMX リソースと他のリソース タイプで保護されているオペレーションを呼び出したり属性を変更したりする場合、クライアントは両方のリソースに定義されているポリシーに合致している必要があります (図 3-3 を参照)。
エンティティやアクションを保護するのに使用されるすべてのリソースのグループ、グローバル ロール、セキュリティ ポリシーのデフォルト コンフィグレーションによって、一貫性のあるセキュリティ方式が作成されます。しかし、変更を行うことで、意図しないアクセス制限が発生する場合があります。デフォルトのセキュリティ設定に対する変更が、JMX リソースと別のリソースの両方のリソース タイプによるユーザの認可を妨げないことを確認してください。セキュリティ ポリシーを作成または変更する際には、以下のことを検討します。
サーバ リソースのポリシーでは、WebLogic Server のサーバ インスタンスの状態を誰が制御できるのかが決定されます。
ユーザが直接 Java コマンドで weblogic.Server クラスを呼び出してサーバ インスタンスを起動する場合、サーバ リソースのポリシーによるセキュリティ チェックのみが実施されます。WebLogic Server インスタンスの状態を変更する他のタスクでは、すべて Administration Console、WebLogic Scripting Tool、ノード マネージャ、または他の JMX クライアントを使用する必要があります。したがって、ユーザがはじめに別の JMX リソースで認可されている必要があります。「JMX リソース」を参照してください。
ドメイン内のすべての WebLogic Server インスタンスに適用するセキュリティ ポリシーや、個々のサーバに適用するセキュリティ ポリシーを作成できます。個々のサーバに対するポリシーを定義する場合、そのサーバのライフ サイクル全般に渡るすべてのオペレーションを保護することも、以下の各オペレーションに対して個別にポリシーを定義することもできます。
boot - WebLogic Server インスタンス (管理サーバまたは管理対象サーバ) を起動しようとするユーザには、そのためのパーミッションが必要です。このアクションは通常、コマンドラインでの java weblogic.Server コマンドの呼び出し、コンフィグレーションされている起動スクリプト (java weblogic.Server コマンドを呼び出す)、またはノード マネージャの WebLogic Server をリモートで起動できる機能を通じて開始します。shutdown - 動作中の WebLogic Server インスタンス (管理サーバまたは管理対象サーバ) を停止しようとするユーザには、そのためのパーミッションが必要です。このアクションは通常、WebLogic Server Administration Console、または WLST SHUTDOWN コマンドか FORCESHUTDOWN コマンドを通じて開始します。suspend - 動作中の WebLogic Server インスタンス (管理サーバまたは管理対象サーバ) への追加ログイン (特権のある管理アクション以外を目的としたログイン) を禁止しようとするユーザには、そのためのパーミッションが必要です。このアクションは通常 Administration Console から開始します。resume - 動作中の WebLogic Server インスタンス (管理サーバまたは管理対象サーバ) への特権のないログインを再び有効にしようとするユーザには、そのためのパーミッションが必要です。このアクションは通常 Administration Console から開始します。
すべてのサーバ リソースには、グローバル セキュリティ ロール Admin および Operator にパーミッションを付与するデフォルト セキュリティ ポリシーが継承されます。
| 注意 : | ドメイン全体の管理ポートを有効にする場合、Admin ロールのみが WebLogic Server サーバ インスタンスの状態を制御できます (Operator では制御できません)。Administration Console オンライン ヘルプの「ドメイン全体の管理ポートのコンフィグレーション」を参照してください。 |
| 警告 : | デフォルト セキュリティ ポリシーからはロールを削除しないでください。既存のセキュリティ ロールの一部を削除すると、WebLogic Server の動作に悪影響を与えることがあります。ただし、必要に応じて、デフォルト セキュリティ ポリシーにより多くを含めることはできます (たとえば、新しいセキュリティ ロールを追加するなど)。「一貫性のあるセキュリティ方式の維持」を参照してください。 |
WebLogic Server インスタンス (サーバ) を起動および停止するには、weblogic.Server コマンドを使用する方法とノード マネージャを使用する方法があります。weblogic.Server コマンドとノード マネージャでは基底のコンポーネントが異なるため、これら 2 つのコマンドでは異なる認可方法が使用されます。
weblogic.Server コマンド (管理サーバと管理対象サーバの両方の起動に使用可能) では、サーバ リソースのセキュリティ ポリシーで保護されたメソッドが呼び出されます。このコマンドを使用するには、サーバ リソースのセキュリティ ポリシーの要件を満たす必要があります。
weblogic.Server の引数の中には MBean の属性を設定するものもあります。ただし、これらの引数ではサーバが実行中の状態 (RUNNING) になる前に MBean を変更するので、MBean の保護ではなく、サーバ リソースのセキュリティ ポリシーによって認可されます。たとえば、Operator グローバル ロールに属するユーザは -Dweblogic.ListenPort 引数を使用してサーバのデフォルトのリスン ポートを変更できますが、WebLogic Server インスタンスが実行中の状態になると、このユーザはリスン ポートの値を変更できません。
weblogic.Server の詳細については、『コマンド リファレンス』の「weblogic.Server コマンドライン リファレンス」を参照してください。
ノード マネージャを使用すると、MBean とサーバ リソースのセキュリティ ポリシーの両方を使用してリモート サーバを起動できます。
リモート WebLogic Server インスタンスのホスト マシン上にノード マネージャがコンフィグレーションされている場合、デフォルトで Admin グローバル ロールまたは Operator グローバル ロールに属するユーザはノード マネージャを使用してリモート サーバを起動できます。
詳細については、『ノード マネージャ管理者ガイド』の「ノード マネージャの概要」を参照してください。
WebLogic Server インスタンスの停止においても MBean とサーバ リソースのセキュリティ ポリシーの両方が関与します。ユーザが停止コマンドを発行すると、サーバではまず、MBean セキュリティ レイヤによってそのユーザに Admin または Operator グローバル ロールが付与されているかどうかが確認されます。続いて、MBean 操作の実行後、サーバ リソースのセキュリティ ポリシーによって、そのユーザがサーバを停止する権限を持っているかどうかが判別されます。
WebLogic Server インスタンス停止の詳細については、『サーバの起動と停止の管理』の「サーバの起動と停止 : クイック リファレンス」を参照してください。
URL リソースは、Web アプリケーションの特定の URL または URL パターンです。特定の URL または URL パターンのすべての HTTP メソッドを保護する URL リソースに対して、または特定の HTTP メソッドのみを保護する URL リソースに対してポリシーを作成できます。これらのリソースはリソースの階層内に存在し、階層の最上位がアプリケーション リソースです。「リソースの階層を保護する」を参照してください。
Java EE プラットフォームはデプロイメント記述子で Web アプリケーションのセキュリティを標準化しているので、WebLogic Server ではこの標準メカニズムが WebLogic Security サービスに統合され、Web アプリケーション リソースを保護する方法を選択できるようになっています。詳細については、「Web アプリケーションおよび EJB リソースの保護のオプション」を参照してください。
Web サービス リソースは、Web サービス モジュール (WAR や JAR)、または Web サービス モジュールのオペレーションです。Web サービスは以下のリソースの階層によって保護されます。
EJB を使用して Web サービスを実装する場合、アプリケーション レベルでポリシーを作成することをお勧めします。Web サービス モジュールおよび Web サービス オペレーションに対するポリシーは、Web サービス クライアントにのみ適用されます。EJB クライアントは、RMI または JNDI を使用して、Web サービス モジュールを経由せずに EJB オペレーションを直接呼び出すことができます (図 3-4 を参照)。
Java アノテーションによる Web サービスの保護については、『WebLogic Web サービスのセキュリティ』の「メッセージレベルのセキュリティのコンフィグレーション」を参照してください。
Java EE の開発者はワーク コンテキストを使用すると、プロパティをリモート呼び出しに含めずに定義して渡すことが可能です。ワーク コンテキスト リソースは、プロパティの作成、削除、読み取り、または変更を行うオペレーションです。特定のプロパティのすべてのオペレーションに対して 1 つのワーク コンテキスト リソースを使用できます。また、オペレーションごとに個々のリソースを作成することもできます。
詳細については、『WebLogic RMI プログラマーズ ガイド』の「アプリケーション設計のベスト プラクティス」を参照してください。
  
|