以下のシナリオでは、詳細な管理セキュリティーの使用、特に新規のデプロイメント・ロールについて説明します。
以下のシナリオでは、以下の表に示すように、サーバー 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 環境で便利です。
以下のシナリオでは、アプリケーションのグループで 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 つを示しています。
以下の図は、このようなシステムのリソースをグループ化して、管理者を互いに分離する方法を示しています。
ノードはどの許可グループにも属していないことに注意してください。 このため、取引アプリケーション管理者はどのノード上のサーバーも停止できず、旅行アプリケーションを停止することもできません。
このシステムは、以下に示すように構成することもできます。
以下の図は、このようなシステムのリソースをグループ化して、管理者を互いに分離する方法を示しています。