詳細な管理セキュリティー
WebSphere® Application Server バージョン 6.1 より前のリリースでは、管理ロールを付与されたユーザーは、セルの下のすべてのリソースを管理できました。 現在、WebSphere Application Server の設定はより詳細になり、リソースごとに各ユーザーにアクセス権が付与されます。
このインスタンス・ベースのセキュリティー、つまり詳細なセキュリティーを実現するには、 同じ特権を必要とするリソースを、管理許可グループまたは許可グループと呼ばれるグループに入れます。ユーザーに必要な管理ロールを割り当てることによって、許可グループへのアクセス権を付与できます。
詳細な管理セキュリティーは、単一サーバー環境でも使用できます。 単一サーバー内の各種アプリケーションをグループ化して、さまざまな許可グループに入れることができます。 したがって、アプリケーションが異なる場合は、許可制約も異なります。 シングル・サーバー環境では、サーバー自体を許可グループの一部にすることはできないので注意してください。
wsadmin スクリプトおよび管理コンソールを使用して、ユーザーおよびグループをセル・レベルの adminsecuritymanager ロールに割り当てることができます。 adminsecuritymanager ロールを使用して、ユーザーおよびグループを、管理ユーザー・ロールおよび管理グループ・ロールに割り当てることができます。
詳細な管理セキュリティーが使用されている場合、adminsecuritymanager ロールを付与されたユーザーは、許可グループを管理することができます。 すべての管理ロールの詳細な説明については、 管理ロールとネーミング・サービスの許可を参照してください。
管理者は、ユーザーおよびグループを、adminsecuritymanager ロールを含む管理ユーザー・ロールおよび管理グループ・ロールに割り当てることはできません。 詳しくは、管理ロール を参照してください。
- 新規許可グループの作成:
$AdminTask createAuthorizationGroup {-authorizationGroupName authGroup1}
- 許可グループの削除:
$AdminTask deleteAuthorizationGroup {-authorizationGroupName groupName}
- 許可グループへのリソースの追加:
$AdminTask addResourceToAuthorizationGroup {-authorizationGroupName groupName -resourceName Application=app1}
- 許可グループからのリソースの除去:
$AdminTask removeResourceFromAuthorizationGroup {-authorizationGroupName groupName -resourceName Application=app1}
- 許可グループ内のロールへのユーザー ID の追加:
$AdminTask mapUsersToAdminRole {-authorizationGroupName groupName -roleName administrator -userids user1}
- 許可グループ内のロールへのグループ ID の追加:
$AdminTask mapGroupsToAdminRole {-authorizationGroupName groupName -roleName administrator -groupids group1}
- 許可グループ内のロールからのユーザー ID の除去:
AdminTask removeUsersFromAdminRole {-authorizationGroupName groupName -roleName administrator -userids user1}
- 許可グループ内のロールからのグループ ID の除去:
$AdminTask removeGroupsFromAdminRole {-authorizationGroupName groupName -roleName administrator -groupids group1}
許可グループに追加できるリソース
- セル
- ノード
- ServerCluster
- サーバー
- アプリケーション
- ノード・グループ
リソースが前述のリストにあるタイプのいずれでもない場合は、その親リソースが使用されます。
1 つのリソースは、1 つの許可グループにのみ属します。ただし、リソース間には包含関係があります。親リソースが子リソースの許可グループとは異なる許可グループに属している場合、子リソースは、暗黙的に複数の許可グループに属すことになります。同じリソースを複数の許可グループに追加することはできません。
次の図は、リソース間の包含関係を示しています。
- 管理リソースの許可グループ。ユーザーに許可グループへのアクセス権が付与されている場合は、そのグループ内のすべてのリソースが含まれます。
- リソース・インスタンスの包含関係。ユーザーに親リソースへのアクセス権が付与されている場合は、すべての子リソースが含まれます。
鍵ストア管理は、セル・レベル管理権限を持つユーザーによって行う必要があります。これは、権限がセル・レベルで作成され、管理されるためです。 特定リソースに対する詳細なセキュリティー・アクセス権では、関連付けられた鍵ストアの管理を行うことはできません。
リソース | アクション | 必要なロール |
---|---|---|
サーバー | 開始、停止、ランタイム操作 | サーバー・オペレーター、ノード・オペレーター、セル・オペレーター |
サーバー | 新規作成、削除 | ノード・コンフィギュレーター、セル・コンフィギュレーター |
サーバー | 構成の編集 | サーバー・コンフィギュレーター、ノード・コンフィギュレーター、セル・コンフィギュレーター |
サーバー | 構成、ランタイムの状況の表示 | サーバー・モニター、ノード・モニター、セル・モニター |
ノード | 再始動、停止、同期 | ノード・オペレーター、セル・オペレーター |
ノード | 追加、削除 | セル・コンフィギュレーター |
ノード | 構成の編集 | ノード・コンフィギュレーター、セル・コンフィギュレーター |
ノード | 構成、ランタイムの状況の表示 | ノード・モニター、セル・モニター |
クラスター | 開始、停止、ランタイム操作 | クラスター・オペレーター、セル・オペレーター |
クラスター | 新規作成、削除 | セル・コンフィギュレーター |
クラスター | 構成の編集 | クラスター・コンフィギュレーター、セル・コンフィギュレーター |
クラスター | 構成、ランタイムの状況の表示 | クラスター・モニター、セル・モニター |
クラスター・メンバー | 開始、停止、ランタイム操作 | サーバー・オペレーター、クラスター・オペレーター、ノード・オペレーター、セル・オペレーター |
クラスター・メンバー | 新規作成、削除 | ノード・コンフィギュレーター、セル・コンフィギュレーター |
クラスター・メンバー | 構成の編集 | サーバー・コンフィギュレーター、クラスター・コンフィギュレーター、ノード・コンフィギュレーター、セル・コンフィギュレーター |
クラスター・メンバー | 構成、ランタイムの状況の表示 | サーバー・モニター、クラスター・モニター、ノード・モニター、セル・モニター |
アプリケーション | すべての操作 | 管理ロールの 『デプロイヤーのロール (Deployer roles)』のセクションを参照してください。 |
ノード、クラスター | 追加、削除 | セル・コンフィギュレーター |
サーバー・オペレーター・ロールは、サーバー・インスタンスが一部を構成する許可グループのオペレーター・ロールです。同様に、ノード・オペレーター・ロールは、ノード・インスタンスが一部を構成する許可グループのオペレーター・ロールです。
管理コンソールできめ細かい管理セキュリティーを使用するには、ユーザーに最低限、セル・レベルでのモニター・ロールが付与されている必要があります。しかし、wsadmin を使用してログインする場合は、 ユーザーに、許可グループに対するモニター・ロールが付与されている必要があります。
例: きめ細かいセキュリティーの使用
以下のシナリオでは、詳細な管理セキュリティーの使用、特に新規のデプロイメント・ロールについて説明します。
デプロイメント・ロールのシナリオ 1。以下のシナリオでは、以下の表に示すように、サーバー S1 上で 4 つのアプリケーションが構成されています。 各アプリケーションを分離して、1 つのアプリケーションの管理者が別のアプリケーションを変更できないようにする必要があります。 アプリケーション A1 は user1 のみ、アプリケーション A2 と A3 は user2、アプリケーション A4 は user3 のみが管理できるとします。
例の 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 によるサービスを受けるために料金を支払っているアプリケーションのみが含まれます。
構成リポジトリーを更新する場合は、デプロイメント・マネージャー側から管理スクリプトが実行される際に、きめ細かい管理セキュリティー・ルールが有効になるように、デプロイメント・マネージャーから管理スクリプトを実行してください。
以下の図では、2 つの別のタイプのアプリケーションを持つ 2 つの別のカスタマーが存在し、それぞれのアプリケーションを管理することができるというシナリオを示します。 ただし、アプリケーションを実行中のサーバーおよびノードは、それぞれのカスタマーから分離されています。 これらのサーバーおよびノードを保守できるのは、内部管理者のみです。 また、カスタマーが別のサーバー上にある所有アプリケーションをターゲットとすることはできません。 これを実行できるのは、内部管理者か内部デプロイヤーのみです。

このシナリオでは、カスタマーは大規模なグローバル企業です。 会社のノードおよびサーバーは、異なる地域 (または異なる基幹業務) に対してアプリケーションのサービスを提供できるように編成されています。 ここでは、異なる地域に関連するノードおよびサーバーをモニターおよび管理するために、その地域の担当者を必要としています。 ただし、その地域の担当者が、別の地域に関連するノードおよびサーバーに影響を与えることができないようにする必要があります。
各地域の担当者の管理許可グループには、その地域に関連するノード、サーバー、クラスター、およびアプリケーションが含まれています。
例えば、クレジット・カード口座、証券取引口座、銀行口座、旅行口座などのサービスを提供する金融機関など、複数のサービスを提供する企業を考えてみます。 これらのサービスはそれぞれ別のアプリケーションとすることができ、各アプリケーションの管理者もまた別々である必要があります。 以下の図は、このようなシステムを構成する方法の 1 つを示しています。

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

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

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