前のトピック: Role-Based Access Control次のトピック: デフォルト ユーザおよびグループ


RBAC の概要

RBAC は、CA AppLogic® の役割ベースのアクセス制御システムです。 RBAC により、どのユーザがグリッド上のどのオブジェクトに対してどのアクションを実行できるかを詳細に制御できます。 RBAC の一般的な目的は、他のユーザを妨害することなく、複数のユーザが単一のグリッド上で作業できるようにすることです。 RBAC の目的はマルチテナント機能を提供することではありません。 たとえば、Linux ユーザがアクセス権限のないファイルを一覧表示できるのと同じように、すべてのユーザがすべてのアプリケーションを一覧表示できます。 (オブジェクト名スペースは分離されません。)

RBAC では、ユーザおよびグループの両方に対して、ユーザ アクションを許可できます。 グループには、ユーザまたは他のグループをメンバとして含めることができます。 特定のグリッドに固有のユーザおよびグループは CA AppLogic® コマンド ライン インターフェース(CLI)を使用して作成できます。 ユーザとグループの情報は、グリッド コントローラに付随するディレクトリ サービスで管理されます。

RBAC は、Microsoft® Windows® Active Directory® のような外部ディレクトリ サービスを任意で使用することもサポートしています。 この場合、外部ディレクトリ サービスでのユーザの認証時に、このサービスからユーザグループの情報が取得されます。

CA AppLogic® では、グリッドに固有のユーザおよびグループは「ローカル」と呼ばれます。 外部ディレクトリ サービスで管理されているユーザおよびグループは「グローバル」と呼ばれます。 対応するディレクトリ サービスもローカルまたはグローバルとして識別されます。 グリッドは、ローカルのユーザとグループのみを使用するか、またはローカルおよびグローバルの両方のユーザとグループを使用するかを設定できます。

ユーザおよびグループは、プリンシパルとしても参照されます。 プリンシパルを一意に識別するため、各プリンシパルには固有の識別子またはプリンシパル ID が割り当てられます。 プリンシパルがユーザの場合、通常、プリンシパル ID はユーザ ID になります。 同様に、プリンシパルがグループの場合、通常、プリンシパル ID はグループ ID になります。 プリンシパル ID はプリンシパルのスコープ、タイプ、名前などを確認するために使用できます。 プリンシパルのスコープは、プリンシパルがローカルまたはグローバルのどちらであるかを示します。 プリンシパルのタイプは、プリンシパルがユーザまたはグループのどちらであるかを示します。 プリンシパルの名前は、一般的に人名として使用される名前です。 たとえば、ローカル ユーザであるジョンの場合、スコープはローカル、タイプはユーザ、名前はジョンのプリンシパルです。

RBAC の主な機能はユーザに許可を与えることです。 この許可を与えるために、RBAC はアクセス制御リスト(ACL)を使用します。 ACL が関連付けられるグリッド オブジェクトには、アプリケーション、グローバル カタログ、グリッド自体の 3 つのタイプがあります。 ACL は所有者およびエントリのリストで構成されます。 所有者はプリンシパルで、ACL を変更する暗黙の権限があります。 各エントリは、プリンシパルと対応するアクセス レベルで構成されます。アクセス レベルによって、プリンシパルがオブジェクトに対して実行できるアクションが制御されます。 アクセス レベルは、権限のコレクションに名前を付けたものです。 たとえば、グリッド オブジェクトに grid_administrator という名前のアクセス レベルがあり、このアクセス レベルに含まれる権限の 1 つがグリッドにログインする権限になります。 固有のプリンシパル ID は、ACL 内の各プリンシパルを表します。

ACL 概要

RBAC は、グリッド管理者のアクセス権は排除しません。 管理者が実行する操作は、許可の対象になりません。

ACL は、オブジェクトへのアクセス許可の方法がすべて含まれているリストです。 このリストには、個人用とグループ用の許可レベルが含まれます。 ユーザは、個人としても、1 つ以上のグループのメンバとしてもリストできます。 そのため、オブジェクトへのアクセスを許可する処理では、関連する ACL エントリが 1 つずつ評価されます。 ユーザには、グループのメンバまたはリストされた個人として、最大限のアクセス権限が許可されます。 最大限のアクセス権限によって、オブジェクトに必要な権限が付与されれば、許可チェックは成功です。

グループのメンバシップは再帰的に評価されます。 そのため、ユーザがグループのメンバとして判断される状況は 2 つあります。

再帰的なグループ メンバシップは、グループ内のグループのネスト レベル数だけ繰り返されます。

例: グリッド ACL 上でグループおよび個人としてアクセス権限を持つユーザ

ジャンは、グリッド ACL 上の financial_operators グループのメンバですこのグループには、グリッド オブジェクトに対する grid_user アクセス レベルが割り当てられています。 このアクセス レベルには、アプリケーションをプロビジョニングする権限が含まれています。 このアクセス レベルには、ローカル ユーザを作成する権限は含まれていません。

ジャンは、グリッド ACL に個人エントリとしてもリストされています。 この個人エントリには、グリッド オブジェクトに対する grid_administrator アクセス レベルが割り当てられています。 このアクセス レベルには、ローカル ユーザを作成する権限が含まれています。 このアクセス レベルには、アプリケーションをプロビジョニングする権限は含まれていません。

ジャンがグリッドにログオンします。 このセッション中、ジャンはローカル ユーザを作成し、アプリケーションをプロビジョニングしたいと考えています。 許可チェックでは、ジャンに両方のアクションの実行が許可されます。 グループ メンバシップにより、ジャンにはアプリケーションをプロビジョニングする権限があります。 個別の ACL エントリにより、ジャンにはローカル ユーザを作成する権限があります。

例: 再帰的なグループ メンバシップ

ロビンは、グリッドからローカル ユーザを削除したいと考えています。 ローカル ユーザを削除する権限があるのは、grid_administrators グループのメンバだけです。 ロビンは、grid_administrators グループのメンバに含まれていません。 しかし、ロビンは al_senior_admins グループのメンバです。 このグループは、grid_administrators グループのメンバとしてリストされています。 これにより、ロビンは grid_administrators グループのメンバであると判断されます。 ロビンにはローカル ユーザを削除する権限があります。