CA AppLogic の使用 › グリッド管理ガイド › Role-Based Access Control › シナリオ例

シナリオ例

CA AppLogic は、あらかじめ定義されたグループおよびユーザに対して包括的なスキームは提供しません。 そのため、グリッド管理者は特定の状況に応じてユーザ、グループおよびオブジェクトのアクセスを設定することができます。 一般に、グリッド管理者は以下の手順に従います。

• ローカル ユーザを作成します。
• ローカル グループを 1 セット作成します。 これらのグループを使用して、業務の種類、ビジネス構造、その他実用的な区分でユーザを分離することができます。たとえば、グリッド管理、アプリケーション開発、QA などの業務別、または部門やビジネス ユニットなどの構造別に分離して異なるグループのユーザが開発作業でグリッドを共有できるようにします。 グローバル グループの場合も同様の効果が得られます。同じセットアップを複数のグリッドに使用する場合は特に有用です。
• 必要に応じて、ユーザをグループに追加したり、グループをグループに追加したりします。
• グループ固有のアクセス レベル権限を割り当てるため、オブジェクト ACL を変更します。

以下のシナリオは、このプロセスを使用してユーザ アクセスを効果的に制御するための方法例を具体的に示したものです。

Ace Starships Incorporated （ASI）は宇宙船を開発しています。 各宇宙船には、多くのソフトウェア システムが備わっていますが、そのなかに生命維持装置と推進装置用のシステムがあります。 これらの 2 つのソフトウェア システムは、大規模な共有 CA AppLogic グリッド上で開発されてから、実際の宇宙船で実稼働グリッドに展開されます。 このグリッド上の開発プロセスには、以下の関係者が関与します。

• 生命維持装置（Life Support）開発チーム
• 推進装置（Propulsion）開発チーム
• サードパーティ - ミドルウェア アプライアンス開発の専門家（共通アプライアンス）
• 監査担当者 - 開発への非破壊的アクセスを必要とする ASI 社員
• QA - 開発チームおよびサードパーティの両方の製品をテストする品質保証担当

さらに、以下のユーザも関与します。

• グローバル ユーザ john_adams （グリッド管理者） - グリッド管理の責任を担う担当者
• グローバル ユーザ jane_osprey （グリッド オペレータ） - グリッド管理者が休憩中にグリッドの責任を担う担当者

また、以下の点も考慮します。

• ASI は、一元化されたユーザおよびグループ管理のために、全社的な LDAP ベース ディレクトリ サービスを使用しています。 サードパーティ以外の誰でもこのシステムにアカウントを持っています。
• 推進装置開発チームは、生命維持装置開発チームによって作成されたいくつかのアプリケーションを使用しますが、これらのアプリケーションのアーキテクチャを変更することはしません。
• 両方のチームは、サードパーティによって開発されたアプライアンスを使用しますが、これらのアプライアンスを変更することはしません。
• それぞれの開発業務（生命維持、推進、サードパーティ）に固有のアプライアンスが含まれるグローバル カタログがあります。

このシナリオで決定すべき最初の項目の 1 つは、全社的なディレクトリを使用してグループ メンバシップを管理するかどうか、またはローカル グループを使用してこのメンバシップを管理するかどうか、ということです。 この例は前者の方法を使用します。

• ASI の全社的ディレクトリを使用して、life_support、propulsion、QA、auditors というグループを作成し、対応するユーザをグループに含めます。 この操作は CA AppLogic の外部で実行されます。

次に、CA AppLogic 初期ユーザ（ローカル グループ admin のメンバ）は、ユーザおよびグループのセットアップを以下の手順で行います。

• サードパーティの各メンバ用にローカル ユーザ アカウントを作成します。
• 以下のローカル グループを作成します。
  • outsiders
  • grid_operators
  • app_developers
• グループ メンバシップを設定します。
  • 作成したローカル ユーザをローカル グループ outsiders に追加します。
  • グローバル グループ life_support、propulsion、QA を app_developers グループに追加します。
  • ローカル グループ outsiders を app_developers グループに追加します。
  • グローバル ユーザ john_adams を admin グループに追加します。
  • グローバル ユーザ jane_osprey を grid_operators グループに追加します。
• オブジェクト ACL を変更してオブジェクト アクセスを設定します。
  • グリッド ACL を以下のように変更します。
    • grid_operator アクセス レベル権限をローカル グループ grid_operators に付与します。
    • app_developer アクセス レベル権限をローカル グループ app_developers に付与します。
    • monitor アクセス レベル権限をグローバル グループ auditors に付与します。
  • グローバル カタログ ACL を以下のように変更します。
    • life_support カタログ上でグローバル グループ life_support にfull アクセス権限を付与し、同じ権限を propulsion カタログ上でグローバル グループ propulsion に、outsiders カタログ上でローカル グループ outsiders に付与します。
    • outsiders カタログ上でローカル グループ app_developers に configure アクセス レベル権限、life_support カタログ上でグローバル グループ propulsion に同じ権限を付与します。

以下の表は、このシナリオ内のグループ メンバシップについて示しています。

以下の表は、このシナリオ内の各オブジェクトのプリンシパルに付与されたアクセス レベル権限を示しています。

ユーザおよびグループの初期セットアップが完了しました。 この時点で、グローバル グループ life_support、propulsion、QA、auditors に属するグローバル ユーザはすべてグリッドにログインできます。各ユーザには、それぞれの作業を実行するために必要なアクセス レベル権限が自動的に提供されます。

グローバル カタログへのアクセスも設定され、アプライアンスは必要に応じてアクセス可能です。ただし、カタログ上で full アクセス レベル権限があるグループのメンバのみが、そのカタログ上で破壊的操作を実行できます。

ユーザが新しいアプリケーションを作成すると、そのユーザはアプリケーションの所有者になり、そのアプリケーション上で full アクセス レベル権限が付与されます。 ある時点で、このユーザは、アプリケーション ACL を変更し、同じ開発チームまたは他のチームのメンバにアプリケーションへのアクセスを提供するとします。 例：

• 生命維持装置開発チームのメンバは、ローカル グループ life_support に、アプリケーションへの full アクセス レベル権限を付与できるため、他のチーム メンバはアプリケーションを自由に変更することができます。
• 生命維持装置開発チームのメンバは、ローカル グループ propulsion に、アプリケーションへの configure アクセス レベル権限を付与できるため、このグループのメンバは、アプリケーションを設定または使用できますが、そのアーキテクチャを変更することはできません。
• 生命維持装置開発チームのメンバは、グローバル グループ QA に、アプリケーションをテストするために必要なあらゆるアクセス レベル権限を付与できます。たとえば、個別テスト目的でアプリケーションをコピーするための read アクセス権限、アーキテクチャを変更せずにアプリケーションを使用するための configure アクセス権限、などです。