WebLogic リソースのセキュリティ
|
 |
 |
|
WebLogic リソースとは、WebLogic Security サービスで基底の WebLogic Server エンティティを表すため、またそのエンティティに誰がアクセスできるかを決定するために作成されるものです。一連の条件下でリソースにアクセスできるユーザ、グループ、またはロールを指定するには、セキュリティ ポリシーを作成します。
以下の節では、WebLogic Server Administration Console を使用して保護できるリソースのタイプについて説明します。
WebLogic リソース用の API については、『WebLogic Server API リファレンス』で weblogic.security.service パッケージを参照してください。
管理リソースでは、ファイルのアップロード (デプロイ中に使用)、ドメインおよびサーバのログの表示、アカウントからロックアウトされたユーザのロック解除、またサーバ、クラスタ、マシン、およびドメインのコンフィグレーション ドキュメント (config.xml) に定義されている他のコンポーネントのコンフィグレーションの変更といった作業を、誰が実施できるのかが決定されます。
こうしたタスクでは多くの場合、はじめに MBean セキュリティ レイヤという別のセキュリティ レイヤでユーザが認可されている必要があります (図 3-1 を参照)。
図 3-1 管理リソースと 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 について」を参照してください。
MBean へのアクセスを保護するためには、JMX クライアントが 4 つのデフォルト グローバル ロール (Anonymous、Admin、Deployer、Operator) のどれかに含まれている必要があります (「デフォルト グローバル ロール」を参照)。ほとんどの場合 MBean 属性を変更できるのは Admin ロールのみですが、例外もあります。WebLogic Server MBean を変更できるロールの種類の詳細については、『WebLogic Server MBean Reference』の「Security Roles for MBeans」を参照してください。MBean のセキュリティ要件は不変です。MBean のオペレーションの呼び出しや属性の変更を行うロールを変更することはできません。
JMX クライアントで、管理リソースでも保護されているオペレーションを呼び出したり属性を変更したりする場合、クライアントは管理リソースに定義されているポリシーにも合致している必要があります (図 3-2 を参照)。
図 3-2 MBean セキュリティ レイヤによるチェックと Security サービス (必要な場合)
表 3-1 で、管理リソースによって保護される管理アクティビティについて説明します。一部の保護は、MBean セキュリティ レイヤでの保護と重複しています。重複している場合、管理リソースのデフォルトのポリシーが単に MBean セキュリティ レイヤで保護された上に適用されます。
|
|
||
|
|
||
|
|
MBean セキュリティ レイヤと、管理リソースおよびサーバ リソースのグループ、グローバル ロール、セキュリティ ポリシーのデフォルト コンフィグレーションとの連携によって、一貫性のあるセキュリティ方式が作成されます。しかし、変更を行うことで、意図しないアクセス制限が発生する場合があります。デフォルトのセキュリティ設定を変更する場合は、MBean セキュリティ レイヤと、管理リソースおよびサーバ リソースのポリシーの両方によるユーザの認可を妨げないように注意してください。
MBean の保護とセキュリティ ポリシーを同期させるには、セキュリティ ポリシーの作成時または変更時に以下のアクションを実施することを検討します。
Admin グローバル ロールと Operator グローバル ロールを含める。Operator グローバル ロール、またはこのデフォルト グローバル ロール内にネストされたセキュリティ ロールが使用できない場合、WebLogic Security サービスで矛盾した動作が発生する場合があります。
Deployer グローバル ロールを使用する。
アプリケーション リソースは、EAR (エンタープライズ アーカイブ) としてパッケージ化されるエンタープライズ アプリケーションを表す WebLogic リソースです。Web アプリケーション リソースと同様に (「Web アプリケーション リソース」を参照)、アプリケーション リソースの階層はタイプ別の階層ではなく、格納のメカニズムです。EAR を構成する複数の WebLogic リソース (Web アプリケーション、EJB、Web サービス リソースなど) を保護する場合に、アプリケーション リソースを保護します。つまり、エンタープライズ アプリケーションを保護することによって、そのアプリケーション内のすべての WebLogic リソースでそのセキュリティ コンフィグレーションが継承されます。
EAR を構成する WebLogic リソースを個別に保護することもできます。両方の手段でリソースを保護すると、個別のセキュリティ コンフィグレーションによって、その WebLogic リソースのエンタープライズ アプリケーションから継承したセキュリティ コンフィグレーションがオーバーライドされます。
WebLogic jCOM は、WebLogic Server でデプロイされる Java/J2EE オブジェクトと、Microsoft Office 製品ファミリ、Visual Basic オブジェクトおよび C++ オブジェクト、その他のコンポーネント オブジェクト モデル/分散コンポーネント オブジェクト モデル (COM/DCOM 準拠) 環境で使用できる Microsoft ActiveX コンポーネントとの間で双方向アクセスを可能にするソフトウェア ブリッジです。
COM リソースは、Microsoft のフレームワークに準拠してプログラム コンポーネント オブジェクトとして設計されている、特定の WebLogic リソースのタイプです。BEA の双方向型 COM-Java (jCOM) ブリッジング ツールを介してアクセスされる COM コンポーネントを保護するには、複数の COM クラスを含むパッケージに対して、または個々の COM クラスに対してセキュリティ ロールとセキュリティ ポリシーを作成します。
関連する情報については、『WebLogic jCOM プログラマーズ ガイド』の「アクセス制御のコンフィグレーション」を参照してください。
EIS リソースは、システム レベルのソフトウェア ドライバであり、WebLogic Server などのアプリケーション サーバでエンタープライズ情報システム (EIS) に接続するために使用されます。BEA では、EIS ベンダおよびサードパーティのアプリケーション開発者によって開発されたリソース アダプタをサポートしています。リソース アダプタは、適切な Sun Microsystems の J2EE プラットフォーム仕様をサポートしているアプリケーション サーバであればどのサーバにもデプロイできます。リソース アダプタには、Java コードに加えて、必要な場合には EIS との対話に必要なネイティブ コンポーネントが含まれます。
EIS へのアクセスを保護するには、グループとしてすべてのリソース アダプタに対して、または個々のリソース アダプタに対してセキュリティ ポリシーとセキュリティ ロールを作成します。
関連する情報については、『WebLogic リソース アダプタ プログラマーズ ガイド』の「セキュリティ」を参照してください。
EJB (エンタープライズ JavaBean) リソースは、EJB に関連する特定の WebLogic リソースのタイプです。EJB を保護するには、EJB のデプロイメント モジュール、個々の EJB、または EJB の個々のメソッドに対してセキュリティ ポリシーとセキュリティ ロールを作成します。
J2EE プラットフォームはデプロイメント記述子で EJB のセキュリティを標準化しているので、WebLogic Server ではこの標準メカニズムが WebLogic Security サービスに統合され、EJB リソースを保護する方法を選択できるようになっています。詳細については、「Web アプリケーションおよび EJB リソースの保護のオプション」を参照してください。
Java Database Connectivity (JDBC) リソースは、JDBC に関連する特定の WebLogic リソースのタイプです。サービスまたはアプリケーションとしてデプロイされている JDBC リソースを保護できます。JDBC データベースへのアクセスを保護するには、グループとしてすべてのデータ ソース、個々のデータ ソース、および複数のデータ ソースに対してセキュリティ ポリシーとセキュリティ ロールを作成できます。
個々のデータ ソースを保護する場合、すべてのオペレーションを保護するか、または以下のオペレーション群のうち 1 つを保護するかを選択できます。
admin - JDBCDataSourceRuntimeMBean の clearStatementCache、suspend、forceSuspend、resume、shutdown、forceShutdown、forceSuspend、getProperties、および poolExists の各メソッドは管理オペレーションとして呼び出されます。 reserve - アプリケーションでは、データ ソースをルックアップしてから getConnection を呼び出すことにより、データソース内で接続を予約します。注意 : reserve パーミッションを与えるとユーザはベンダ固有のオペレーションを実行できるようになります。データベース ベンダによっては、こうしたオペレーションの一部がデータベースのセキュリティに影響する場合があります。
shrink - データ ソースの接続数を現在予約される接続の最大数または初期サイズに縮小します。reset - すべての物理的なデータベース接続を停止し、再確立することで、データソースの接続をリセットします。また、それぞれの接続のステートメント キャッシュをクリアします。リセットできるデータ ソースの接続は、正常に動作しているものに限られます。注意 : セキュリティ ポリシーでマルチ データ ソース内の接続へのアクセスを制御している場合は、アクセス チェックが JDBC リソース階層の両方のレベルで行われます (まずマルチ データ ソース レベルで行われ、次に個々のデータ ソース レベルで行われます)。すべてのタイプの WebLogic リソースと同じように、こうした二重チェックを行うことで、セキュリティ ポリシーによる最も厳しいアクセス制御を確実に行うことができます。
注意 : Oracle データベースを使用している場合、Oracle 仮想プライベート データベース (Oracle Virtual Private Database : VPD) を使用しても JDBC リソースへのアクセスを制御できます。詳細については、「WebLogic Server でのサードパーティ ドライバの使い方」の「Oracle 仮想プライベート データベースを使用したプログラミング」を参照してください。
Java Messaging Service (JMS) リソースは、JMS に関連する特定の WebLogic リソースのタイプです。サービスまたはアプリケーションとしてデプロイされている 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 メソッドのために必要です。 送り先に対するオペレーションを保護するには、ポリシー条件の作成時に以下のいずれかを行います。
送り先の send、receive、および browse メソッドについてリソースを保護するには、次の手順を行います。
注意 : このページで [プロバイダ] と [ポリシー条件] の更新が必要なこともあります。『WebLogic リソースのセキュリティ』の「セキュリティ ポリシー」を参照してください。
ユーザが送り先の send、receive、および browse メソッドにアクセスできるポリシー条件を作成する場合は、[ALL] のメソッドを選択します。ポリシー条件の作成時に、[ALL] のメソッドと個々のメソッドを混在させることはできません。ポリシー条件の作成時に [ALL] のメソッドの保護と個々のメソッドの保護を混在させた場合、[ALL] のメソッドに関連付けられているユーザはポリシー条件が作成された際に無視されます。
送り先の send、receive、または browse メソッドについてリソースを保護するには、次の手順を行います。
注意 : このページで [プロバイダ] と [ポリシー条件] の更新が必要なこともあります。『WebLogic リソースのセキュリティ』の「セキュリティ ポリシー」を参照してください。
送り先に send、receive、または browse メソッドを個別に関連付けるポリシー条件を作成する場合、[send]、[receive]、または [browse] の各メソッドを選択します。ポリシー条件の作成時に、[ALL] のメソッドと個々のメソッドを混在させることはできません。ポリシー条件の作成時に [ALL] のメソッドの保護と個々のメソッドの保護を混在させた場合、[ALL] のメソッドに関連付けられているユーザはポリシー条件が作成された際に無視されます。
Java Naming and Directory Interface (JNDI) リソースは、業界標準の JNDI SPI を使用して、異種のエンタープライズ ネーミング サービスおよびディレクトリ サービスに接続できるようにする特定の WebLogic リソースのタイプです。
JNDI により、Lightweight Directory Access Protocol (LDAP) や Domain Name System (DNS) など、既存のさまざまなネーミング サービスに対する共通インタフェースが提供されます。これらのネーミング サービスでは、バインディングのセットが管理されます。バインディングによって名前がオブジェクトに関連付けられるので、オブジェクトを名前でルックアップできるようになります。したがって、JNDI を使用すると、分散アプリケーションのコンポーネントが互いを検索できます。
JNDI は、特定のネーミング サービスまたはディレクトリ サービスの実装とは無関係です。JNDI では、複数の方法で、さまざまな新しいサービスや既存のサービスにアクセスできます。このサポートでは、標準サービス プロバイダ インタフェース (SPI) 規約を使用して JNDI フレームワークに任意のサービス プロバイダ実装をプラグインできます。
JNDI ツリーへのアクセスを保護するには、JNDI ツリー全体に対して、またはそのツリーの個々のブランチに対してセキュリティ ポリシーとセキュリティ ロールを作成します。すべての操作を保護するか、以下の操作群の 1 つを保護することができます。
modify - アプリケーションで JNDI ツリーを何らかの方法で修正 (つまり追加、削除、変更) するときには、現在のユーザに必ず修正のパーミッションが必要です。bind()、rebind()、createSubContext()、destroySubContext()、および unbind() の各メソッドが含まれています。lookup - アプリケーションで JNDI ツリーのオブジェクトをルックアップするときには、現在のユーザにルックアップのパーミッションが必要です。lookup() メソッドおよび lookupLink() メソッドが含まれています。 list - アプリケーションで JNDI のコンテキストの内容をリストするときには、現在のユーザにリスト操作を実行するパーミッションが必要です。list() メソッドおよび listBindings() メソッドが含まれています。
サーバ リソースでは、WebLogic Server のサーバ インスタンスの状態を誰が制御するのかが決定されます。
ユーザが直接 Java コマンドで weblogic.Server クラスを呼び出してサーバ インスタンスを起動する場合、サーバ リソースのポリシーによるセキュリティ チェックのみが実施されます。WebLogic Server インスタンスの状態を変更する他のタスクでは、すべて Administration Console、WebLogic Scripting Tool、ノード マネージャ、または他の JMX クライアントを使用する必要があります。したがって、ユーザがはじめに MBean セキュリティ レイヤという別のセキュリティ レイヤで認可されている必要があります。「MBean セキュリティ レイヤ」を参照してください。
ドメイン内のすべての 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 コマンド リファレンス』の「weblogic.Server コマンドライン リファレンス」を参照してください。
ノード マネージャを使用すると、MBean とサーバ リソースのセキュリティ ポリシーの両方を使用してリモート サーバを起動できます。
リモート WebLogic Server インスタンスのホスト マシン上にノード マネージャがコンフィグレーションされている場合、デフォルトで Admin グローバル ロールまたは Operator グローバル ロールに属するユーザはノード マネージャを使用してリモート サーバを起動できます。
詳細については、『サーバの起動と停止の管理』の「ノード マネージャを使用したサーバの制御」を参照してください。
WebLogic Server インスタンスの停止においても MBean とサーバ リソースのセキュリティ ポリシーの両方が関与します。ユーザが停止コマンドを発行すると、サーバではまず、MBean セキュリティ レイヤによってそのユーザに Admin または Operator グローバル ロールが付与されているかどうかが確認されます。続いて、MBean 操作の実行後、サーバ リソースのセキュリティ ポリシーによって、そのユーザがサーバを停止する権限を持っているかどうかが判別されます。
WebLogic Server インスタンス停止の詳細については、『サーバの起動と停止の管理』の「サーバの起動と停止 : クイック リファレンス」を参照してください。
Web アプリケーション リソースは、Web ブラウザで URL を使用してアクセスされる特定の WebLogic リソースのタイプです。Web アプリケーションを保護するには、スタンドアロンの Web アプリケーション、EAR 内の Web アプリケーションを表す URL、または Web アプリケーションの個々のコンポーネントに対して、セキュリティ ポリシーおよびセキュリティ ロールを作成します。URL リソースの特定の HTTP メソッドを保護することもできます。
J2EE プラットフォームはデプロイメント記述子で Web アプリケーションのセキュリティを標準化しているので、WebLogic Server ではこの標準メカニズムが WebLogic Security サービスに統合され、Web アプリケーション リソースを保護する方法を選択できるようになっています。詳細については、「Web アプリケーションおよび EJB リソースの保護のオプション」を参照してください。
Web サービス リソースは、Web サービスに関連する特定の WebLogic リソースのタイプです。Web サービスを保護する場合、以下に対してセキュリティ ロールとセキュリティ ポリシーを作成できます。
Web サービスが Java クラスを使用して実装されている場合、Web アプリケーションの WAR ファイルには Java クラス ファイルが格納されます。
Web サービスがステートレス セッション EJB を使用して実装されている場合、エンタープライズ アプリケーション EAR ファイルには対応する EJB JAR ファイルが格納されます。
注意 : Web サービスが Java クラスのみを使用して実装されている場合、Web サービスはスタンドアロンの Web アプリケーション WAR ファイルとしてもパッケージ化できます。ただし、Web サービスのこのタイプのパッケージ化はまれです。通常 Web サービスは EAR ファイルとしてパッケージ化されます。
詳細については、『WebLogic Web サービス プログラマーズ ガイド』の「セキュリティのコンフィグレーション」を参照してください。
J2EE の開発者はワーク コンテキストを使用すると、プロパティをアプリケーションのコンテキストとして定義できます。アプリケーションのコンテキストは複数のリモート リクエストに渡って暗黙的にフローされ、これによって下流工程のコンポーネントが呼び出し側のクライアントのコンテキストで作業できるようになります。ワーク コンテキストの使用により、プロパティをリモート呼び出しに含めずに渡すことが可能です。ワーク コンテキストは各リモート呼び出しで伝播されるので、呼び出されたコンポーネントではワーク コンテキストに定義されたプロパティを追加したり変更したりできます。同様に、呼び出し側のコンポーネントでもワーク コンテキストにアクセスして、新しいプロパティや更新されたプロパティを取得できます。
詳細については、『WebLogic RMI プログラマーズ ガイド』の「アプリケーション設計のベスト プラクティス」を参照してください。
Administration Console を使用して、ワーク コンテキスト リソースへのパスを指定したり、read、create、modify、delete の各アクションを保護したりできます。
|
|
|