WebLogic リソースのセキュリティ
|
 |
 |
|
以下の節では、WebLogic Server Administration Console を使用して保護できるリソースのタイプについて説明します。
WebLogic リソースは、サーバ、サービス、アプリケーション、アプリケーション アーティファクトなどのあらゆるソフトウェア コンポーネントを表しています。このマニュアルでは、WebLogic リソースをセキュリティ ロールおよびポリシーを使用して保護できるあらゆるタイプのリソースとします。WebLogic リソースは階層化されています。セキュリティ ロールとセキュリティ ポリシーは自由なレベルで定義できます。たとえば、エンタープライズ アプリケーション (EAR) 全体、複数の EJB を含むエンタープライズ JavaBean (EJB) JAR、その JAR 内の特定の EJB、その EJB 内の単一のメソッドなどに対してセキュリティ ロールとセキュリティ ポリシーを定義できます。
WebLogic リソースの 1 タイプである管理リソースを使用することで、ユーザは管理タスクを実行できます。管理リソースの例としては、WebLogic Server Administration Console、WebLogic Scripting Tool (WLST)、MBean API などがあります。
共に、セキュリティ ポリシーと MBean の保護の組み合わせによる階層化されたセキュリティ方式で制御されるという点で、管理リソースはサーバ リソースと似ています。「サーバ リソースの階層化されたセキュリティ方式」を参照してください。
管理リソースを保護する場合、レルムが WebLogic Server の AdminResource オブジェクトに定義されている任意またはすべての操作カテゴリを保護するように選択できます。これについて、表 3-1 で説明します。
|
|
||
|
|
||
詳細については、「デフォルト グループ」および「デフォルト グローバル ロール」を参照してください。
アプリケーション リソースは、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 プログラマーズ ガイド』の「Configuring Access Control」を参照してください。
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 リソースを保護する方法を選択できるようになっています。詳細については、「EJB および Web アプリケーション リソースの保護のオプション」を参照してください。
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 リソースへのアクセスも制御できます。詳細については、「Using Third-Party Drivers with WebLogic Server」の「Programming with Oracle Virtual Private Databases」を参照してください。
Java Messaging Service (JMS) リソースは、JMS に関連する特定の WebLogic リソースのタイプです。サービスまたはアプリケーションとしてデプロイされている JMS リソースを保護できます。JMS 送り先を保護するには、グループとしてすべての送り先 (JMS キューおよび JMS トピック) に対して、または JMS サーバ上の個々の送り先 (JMS キューおよび JMS トピック) に対してセキュリティ ロールとセキュリティ ポリシーを作成します。
JMS サーバ上の特定の送り先を保護する場合は、その送り先のすべての操作を保護するか、以下の操作群の 1 つを保護できます。
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 インタフェースを使用してキューのメッセージを表示するために必要です。
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 サーバ インスタンスの状態を制御するために使用される特定の WebLogic リソースのタイプです。サーバ リソースを保護するには、グループとしてすべての WebLogic Server インスタンス、または個々のサーバに対してセキュリティ ポリシーおよびセキュリティ ロールを作成します。
WebLogic サーバを保護する前には、階層化されたセキュリティ方式について理解しておく必要があります。「サーバ リソースの階層化されたセキュリティ方式」を参照してください。
特定のサーバを保護する場合は、そのサーバのすべての操作を保護するか、以下の操作群のうち 1 つを保護できます。
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 から開始します。 WebLogic でのサーバ リソースの保護方式は、セキュリティ ポリシーと MBean の保護という 2 つの部分 (階層) から成っています。
他のタイプの WebLogic リソースと同じように、サーバ リソースへのアクセスは WebLogic Server Administration Console で作成するセキュリティ ポリシーで制御されます。
すべてのサーバ リソースには、デフォルト グローバル セキュリティ ロール Admin および Operator に基づくデフォルト セキュリティ ポリシーが継承されます。「デフォルト グローバル ロール」で説明されているように、グローバル ロール Admin および Operator には、管理者が Administration Console、WLST ユーティリティなどの管理インタフェースと対話するために必要な一連の特有の特権が与えられています。これらのデフォルト グローバル ロールは、デフォルト グループに基づいています (「デフォルト グループ」を参照)。そのため、サーバ リソースへのアクセスが必要な管理者は、デフォルト グループ Administrators または Operators のどちらかのメンバーでなければなりません。
注意 : WebLogic Server では 4 つのデフォルト グローバル ロールが 4 つのデフォルト グループに付与されているので、これらのグループのいずれかにユーザを追加すると、そのユーザにはグローバル ロールが自動的に付与されます。
ドメイン全体の管理ポートが有効な場合、Administrators のメンバー (かつ Operators のメンバー以外) のみが保護可能なサーバ操作にアクセスできます。「サーバ操作」および Administration Console オンライン ヘルプの「ドメイン全体の管理ポートのコンフィグレーション」を参照してください。
警告 : サーバ リソースのデフォルト セキュリティ ポリシーを変更して、それらの制約をさらに厳しくしないでください。既存のセキュリティ ロールの一部を削除すると、WebLogic Server の動作に悪影響を与えることがあります。ただし、必要に応じて、デフォルト セキュリティ ポリシーにより多くを含めることはできます (たとえば、新しいセキュリティ ロールを追加するなど)。
各タイプの WebLogic リソース (サーバ リソースを含む) では、weblogic.security.spi.Resource インタフェース (サーバ リソースでは weblogic.security.service.ServerResource クラス) の独自の実装を通じてその操作が公開されます。そのため、ServerResource クラスは、「サーバ リソースのデフォルト セキュリティ ポリシー」で説明されているセキュリティ ポリシーによって実際に保護されるエンティティです。
WebLogic Server では、サーバ リソースのコンフィグレーションは MBean のセットを通じて公開されます。したがって、ServerResource クラスが保護するアクションは基底 MBean の属性および操作に対応しています。たとえば、Resource インタフェースの start() メソッドは、ServerRuntime MBean の start 操作に直接マップされます。
サーバ リソースのコンフィグレーションを公開する MBean は、4 つのデフォルト グローバル ロールのうちの 1 つを使用して保護されます。これは、そのサーバ リソースのセキュリティ ポリシーとは別のものであり、WebLogic Security サービスで提供されているコンフィグレーションできない保護です。そのため、サーバ リソースを保護するための独自のグローバル ロールを作成できるだけでなく、いずれかのデフォルト グローバル ロールが付与されているユーザのみがサーバのコンフィグレーションを表示または変更できます。
ユーザがサーバ リソースと対話しようとすると、WebLogic Security サービスでは以下のことが行われます。
したがって、要求を正常に実行するには、これらの両方のセキュリティ方式に合格する必要があります。図 3-1 に、サーバ リソースのセキュリティ ポリシーが基底の MBean のセキュリティ ロールベースの保護と相互に作用するしくみを示します。
MBean の保護で与えられた特権は不変なので、セキュリティ ポリシーをある程度一貫性のあるように保つ必要があります。
グループ、グローバル ロール、サーバ リソースのセキュリティ ポリシー、および MBean の保護は、WebLogic Server のデフォルトのコンフィグレーションでは、相互に連携して一貫性のあるセキュリティ方式を確立しています。しかし、変更を行うことで、意図しないアクセス制限が発生する場合があります。デフォルトのセキュリティ設定を変更する場合は、MBean の保護およびサーバ リソースのセキュリティ ポリシーの両方によるユーザの認証を妨げないように注意します。
たとえば、WebLogic Server Administration Console を使用して、あるユーザを (サーバ リソースのデフォルト ポリシーの 1 つではない) Operator グローバル ロールに追加したが、サーバ リソースに定義されているセキュリティ ポリシーに Operator グローバル ロールを追加できない場合、そのユーザは起動および停止シーケンスで使用する MBean 操作を呼び出すことはできますが、サーバを起動または停止するためのサーバ リソースの操作は使用できません。
同様に、Administration Console を使用して、サーバ リソースのセキュリティ ポリシーから Operator グローバル ロールを削除した場合、Operator グローバル ロールを付与されたユーザは MBean の操作を呼び出すことはできますが、サーバ リソースを呼び出すことはできません。デフォルト グローバル ロールによる MBean の保護は WebLogic Security サービスの一部であり、現在はコンフィグレーション不可であるため、このような結果になります。
MBean の保護とセキュリティ ポリシーを同期させるには、セキュリティ ポリシーの作成時または変更時に以下のアクションを実施することを考慮します。
Admin グローバル ロールのアクセス権をサーバ リソースに付与する。Operator グローバル ロールを使用する。 Operator グローバル ロール、またはこのデフォルト グローバル ロール内にネストされたセキュリティ ロールが使用できない場合、WebLogic Security サービスで矛盾した動作が発生する場合があります。
Deployer グローバル ロールを使用する。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 Command-Line Reference」を参照してください。
ノード マネージャを使用すると、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 アプリケーション リソースを保護する方法を選択できるようになっています。詳細については、「EJB および Web アプリケーション リソースの保護のオプション」を参照してください。
Web サービス リソースは、Web サービスに関連する特定の WebLogic リソースのタイプです。Web サービスを保護する場合、以下に対してセキュリティ ロールとセキュリティ ポリシーを作成できます。
Web サービスが Java クラスを使用して実装されている場合、Web アプリケーションの WAR ファイルには Java クラス ファイルが格納されます。
Web サービスがステートレス セッション EJB を使用して実装されている場合、エンタープライズ アプリケーション EAR ファイルには対応する EJB JAR ファイルが格納されます。
注意 : Web サービスが Java クラスのみを使用して実装されている場合、Web サービスはスタンドアロンの Web アプリケーション WAR ファイルとしてもパッケージ化できます。ただし、Web サービスのこのタイプのパッケージ化はまれです。通常 Web サービスは EAR ファイルとしてパッケージ化されます。
詳細については、『WebLogic Web サービス プログラマーズ ガイド』の「Configuring Security」を参照してください。
J2EE の開発者はワーク コンテキストを使用すると、プロパティをアプリケーションのコンテキストとして定義できます。アプリケーションのコンテキストは複数のリモート要求に渡って暗黙的にフローされ、これによって下流工程のコンポーネントが呼び出し側のクライアントのコンテキストで作業できるようになります。ワーク コンテキストの使用により、プロパティをリモート呼び出しに含めずに渡すことが可能です。ワーク コンテキストは各リモート呼び出しで伝播されるので、呼び出されたコンポーネントではワーク コンテキストに定義されたプロパティを追加したり変更したりできます。同様に、呼び出し側のコンポーネントでもワーク コンテキストにアクセスして、新しいプロパティや更新されたプロパティを取得できます。
詳細については、『WebLogic RMI プログラマーズ ガイド』の「Best Practices for Application Design」を参照してください。
Administration Console を使用して、ワーク コンテキスト リソースへのパスを指定したり、read、create、modify、delete の各アクションを保護したりできます。
Administration Console でのリソースへのアクセス方法は、そのリソースのデプロイされた方法によってさまざまです。リソースへのアクセスに加えて、Administration Console の [ドメイン構造] ではリソースのセキュリティ ロールおよびセキュリティ ポリシーにアクセスでき、[ロールとポリシー] テーブルでは一元的な管理を行えます。詳細については、Administration Console オンライン ヘルプの「スコープ指定セキュリティ ロールの作成」および「セキュリティ ポリシーの作成」を参照してください。
|
|
|