WebSphere Application Server - Express, Version 6.0.x   
             オペレーティング・システム: AIX , HP-UX, Linux, Solaris, Windows

             目次と検索結果のパーソナライズ化

例: きめ細かいセキュリティーの使用

以下のシナリオでは、詳細な管理セキュリティーの使用、特に新規のデプロイメント・ロールについて説明します。

デプロイメント・ロールのシナリオ 1

以下のシナリオでは、以下の表に示すように、サーバー S1 上で 4 つのアプリケーションが構成されています。 各アプリケーションを分離して、1 つのアプリケーションの管理者が別のアプリケーションを変更できないようにする必要があります。 アプリケーション A1 は user1 のみ、アプリケーション A2 と A3 は user2、アプリケーション A4 は user3 のみが管理できるとします。

注: アプリケーションを 1 つのグループに配置し、そのターゲット・サーバーを別のグループに配置することは推奨されません。 ただし、これが常に可能であるとは限りません。 通常、多数のアプリケーションを 1 つのサーバー上に配置します。 場合によっては、同じサーバーで実行中のアプリケーションの管理を分離する必要があります。

例の 1 つに、アプリケーション・サービス・プロバイダー (ASP) があります。ここでは、単一のアプリケーション・サーバーが複数のベンダー・アプリケーションを持つことができます。 この例では、サーバーの管理者がすべてのベンダー・アプリケーションのインストールを担当します。 アプリケーションがインストールされると、各ベンダーは、他のベンダーのアプリケーションに干渉することなく、そのアプリケーションを管理できます。

アプリケーション サーバー ノード
A1 S1 N1
A2 S1 N1
A3 S1 N1
A4 S1 N1

以下の図に示すように許可グループを構成できます。

この図では、アプリケーション A1 が 許可グループ G1 に、アプリケーション A2 と A3 が許可グループ G2 に、アプリケーション A4 が許可グループ G3 にあります。

デプロイヤー・ロールが許可グループ G1 から user1 へ、許可グループ G2 から user2 へ、許可グループ G3 から user3 へとそれぞれ割り当てられます。

その結果、user1 はアプリケーション A1 で、user2 はアプリケーション A2 と A3 で、user3 はアプリケーション A4 ですべての操作を実行できます。 すべてのアプリケーションが同じサーバーを共用しているため、同じサーバーをすべての許可グループに配置することはできません。 アプリケーションをインストールできるのは、セル・レベル管理者だけです。 アプリケーションのインストールが完了すると、各アプリケーションのデプロイヤーがそれぞれのアプリケーションを変更できます。 サーバーを始動して停止するには、セル・レベル管理権限が必要です。 このタイプのシナリオは、ASP 環境で便利です。

デプロイメント・ロールのシナリオ 2

以下のシナリオでは、アプリケーションのグループで 1 つのサーバーへの同じ管理の役割が必要です。 この例では、アプリケーション A1 と A2 は関連アプリケーションであり、1 つのセットの管理者で管理できます。 これらは、同じサーバー (S1) で実行されています。 アプリケーション A3 と A4 では別のセットの管理者が必要であり、それぞれサーバー S2 と S3 で実行されています。

アプリケーション サーバー ノード
A1 S1 N1
A2 S1 N1
A3 S2 N2
A4 S3 N3

カスタマー環境に直接適用できるシナリオ

各開発者は、それぞれのサーバーの構成を変更し、それぞれのアプリケーションをそのサーバーにインストールできる必要があります。 また、サーバーのアプリケーションと同じく、サーバーも始動して停止できる必要があります。

開発者は、サーバーを構成して、発生した問題をデバッグできる必要もあります。 開発するアプリケーションを更新または変更できる必要があります。 この開発者の管理許可グループには、少なくとも 1 つのサーバーと、開発者がそのサーバーにインストールするすべてのアプリケーションが含まれます。

以下の例では、許可グループ G1 の開発者に新しいアプリケーション (A11) があります。 この新しいアプリケーションのインストールおよびターゲットは、許可グループ G1 内のサーバーでのみ実行できます。 また、この新しいアプリケーションを許可グループ (G1) 内に配置することもできます。

ASP 環境のシナリオ

このシナリオでは、カスタマーが ASP です。 これらのカスタマーには、アプリケーション・サービス提供機能を提供する独自のカスタマーが存在します。 カスタマーがそれぞれのアプリケーションを管理およびモニターできるようにしる一方で、別のカスタマーのアプリケーションはモニターおよび管理できないようにする必要があります。 ただし、この例では、ASP にサーバーの保守を担当する内部スタッフ管理者が存在します。

この内部 ASP スタッフ管理者は、アプリケーションをあるサーバーから別のサーバーに移動して、アプリケーションが引き続き使用可能になるように必要がある場合があります。 内部 ASP スタッフ管理者は、サーバーを始動および停止させ、それらの構成を変更できる必要があります。

これに対して、ASP カスタマー管理者は、サーバーを始動および停止できないようにする必要があります。 ただし、ASP カスタマー管理者は、それぞれのサーバーで実行されているアプリケーションを更新できる必要があります。 内部 ASP 管理者の管理許可グループは、セル全体か、サーバー、ノード、クラスター、およびアプリケーションのサブセットを含むことができます。 カスタマー管理者の管理許可グループには、カスタマーがこの ASP によるサービスを受けるために料金を支払っているアプリケーションのみが含まれます。

構成リポジトリーを更新する場合は、デプロイメント・マネージャー側から管理スクリプトが実行される際に、きめ細かい管理セキュリティー・ルールが有効になるように、デプロイメント・マネージャーから管理スクリプトを実行してください。

以下の図では、2 つの別のタイプのアプリケーションを持つ 2 つの別のカスタマーが存在し、それぞれのアプリケーションを管理することができるというシナリオを示します。 ただし、アプリケーションを実行中のサーバーおよびノードは、それぞれのカスタマーから分離されています。 これらのサーバーおよびノードを保守できるのは、内部管理者のみです。 また、カスタマーが別のサーバー上にある所有アプリケーションをターゲットとすることはできません。 これを実行できるのは、内部管理者か内部デプロイヤーのみです。

地域の組織のシナリオ

このシナリオでは、カスタマーは大規模なグローバル企業です。 会社のノードおよびサーバーは、異なる地域 (または異なる基幹業務) に対してアプリケーションのサービスを提供できるように編成されています。 ここでは、異なる地域に関連するノードおよびサーバーをモニターおよび管理するために、その地域の担当者を必要としています。 ただし、その地域の担当者が、別の地域に関連するノードおよびサーバーに影響を与えることができないようにする必要があります。

各地域の担当者の管理許可グループには、その地域に関連するノード、サーバー、クラスター、およびアプリケーションが含まれています。

例えば、クレジット・カード口座、証券取引口座、銀行口座、旅行口座などのサービスを提供する金融機関など、複数のサービスを提供する企業を考えてみます。 これらのサービスはそれぞれ別のアプリケーションとすることができ、各アプリケーションの管理者もまた別々である必要があります。 以下の図は、このようなシステムを構成する方法の 1 つを示しています。

以下の図は、このようなシステムのリソースをグループ化して、管理者を互いに分離する方法を示しています。

ノードはどの許可グループにも属していないことに注意してください。 このため、取引アプリケーション管理者はどのノード上のサーバーも停止できず、旅行アプリケーションを停止することもできません。

このシステムは、以下に示すように構成することもできます。

以下の図は、このようなシステムのリソースをグループ化して、管理者を互いに分離する方法を示しています。




関連概念
役割ベースの許可
関連タスク
すべてのアプリケーション・サーバーのセキュリティーの使用可能化
関連資料
管理の役割
参照トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 11:31:28 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/rsec_fineg_scenarios.html