アプリケーションロールとアクセスグループ

アクセスロールは、アプリケーションに定義された職位または責任を識別します。 たとえば、アクセスロールは、LoanOfficerやCallCenterSupervisorの権限を定義できます。 使用中のアクセスグループから取得したアクセスロールに基づき、特定クラスのインスタンスを変更するなどの権限をユーザーに付与します。

アプリケーションにアクセスロールを作成する前に、アプリケーションのロールベースのアクセス制御の必要性を評価し、必要な個別のアクセスロール数を決定してください。 また、各アクセスロールの名前を決定し、各グラントに対する権限も記述します。 アクセスロールは、その保有者がアプリケーションで実行する権限を持つ対象を定義します。

たとえば、アクセスロールは、管理者、フルフィルメントオペレーター、事務員、監査人が実行する権限を持つアクションを表します。 1人のユーザーが同時に複数のアクセスロールを保有することもできます。 ユーザーが一度に保有するアクセスロールのコレクションは、権限のグループとして機能し、そのユーザーが実行を許可されているアクションのセットを表します。 たとえば、フルフィルメントオペレーターは顧客の注文レコードを開くことができ、一方でマネージャーは顧客の注文レコードを開いて修正できるという場合もあります。

Orderingアプリケーションの例では、リードシステムアーキテクト（LSA）がフルフィルメントオペレーターとマネージャーのアクセス制御のニーズを満たすには、以下の3つのアクセスロール設計のいずれかを選択できると考えてください。

オプション1：

オプション2：

オプション3：

LSAが選択すべきオプションに関する設計上の考慮事項は、管理者のアクセス制御ニーズがほぼ常にフルフィルメントオペレーターのアクセス制御ニーズの上に「構築」されるか（またはそのスーパーセットであるか）どうかです。

オプション1では、各ペルソナ（ユーザーロール）のアクセス制御のニーズが互いに独立して進化し、一部のアクセス制御設定が各アクセスロール間で重複するという、保守性のオーバーヘッドが発生します。

オプション2では、FulfillmentOperatorアクセスロールから返される許可は、たとえManagerアクセスロールがアクセスを拒否しても、Managersアクセスグループにアクセスを付与するには十分であるため、Managerのアクセス制御ニーズが常にFulfillment Operatorのスーパーセットになることが必要です。

オプション3では、FulfillmentOperatorアクセスロールに基づくManagerのアクセス制御ニーズを許可する一方で、ManagerアクセスロールがManager固有の設定を導入し、依存するフFulfillmentOperatorアクセスロールで指定された設定の上書きを許可します。

ソリューション：オプション3は通常、AROが最小で重複度が最も低い、想定どおりの権限設計を実現します。 このオプションは、保守しやすく理解しやすいソリューションを促進し、ジャーニーの追加により以前のリリースで達成された権限決定の一部が必然的に無効となった場合でも柔軟に対応できます。

New Applicationウィザードで作成されたアプリケーションには、次のように3つの基本アクセスロールがあります。

• ＜ApplicationName＞:User
• ＜ApplicationName＞:Manager
• ＜ApplicationName＞:Administrator

従属ロールを導入する場合は、アプリケーション固有のアクセスロールを作成し、依存関係にある基本アクセスロールを指定することがベストプラクティスです。

アクセスロールの命名規則は＜ApplicationName＞:＜RoleName＞であり、RoleNameは単数形になります。

Roles for Accessランディングページ（Dev Studio > Configure > Org & Security > Tools > Security > Role Names）を使用して、新しいアプリケーション固有のロールを作成します。

Access of Role to Objectを使用して、指定されたクラスのオブジェクト（インスタンス）に対してはアクセス許可、ロールに対しては名前付き権限を付与します。 アクセス許可と名前付き権限は、1～5の間で指定された本番レベルまで（1：実験中、2：開発中、3：QA中、4：ステージング中、5：本番中）、またはAccess Whenルールを伴う条件付きで付与できます。

Access Role Nameに指定するAROのセットを検討するときは、次のことを考慮してください。

• 適用するアクセスロールは、従属ロールから権限を継承しているか？ 継承している場合は、アクセスロールに必要なAROは、その従属ロールから派生した、権限の結果を変更するものに限定できます。
• アクセスロールは権限の継承を利用しているか？ 利用していない場合は、スーパークラスAROの一部の権限は、同じアクセスロール内のサブクラスAROに再指定する必要が生じることもあります。
• AROで設定を空白にすると、Pegaはその設定の権限の決定をスーパークラスAROと従属ロールに委ねることになります。 これは権限を設定するうえで合理的なオブジェクト指向のアプローチですが、設計が必要です。
• アクセスロールは、アクセスが明示的に許可または拒否されてから、アクセスロールをテストする「短絡」アクセスグループで使用されているか? 使用されている場合は、どちらでも明示的にアクセスを拒否できる2つの設定値（Access Whenルールまたは本番レベル番号）を構成するか、設定を空白にするか（アクセスグループのスーパークラスARO、従属ロールまたはそれ以降のロールに権限の結果を委ねる）に注意してください。

Access Denyルールを使用して、同じクラスとアクセスロールの対応するAROが同じアクションへのアクセスを付与するかどうかを評価する前に、明示的に権限を拒否します。

Access Denyルールのみを含むアクセスロールを定義し、これらのアクセスロールをアクセスグループ上のリストの前方に配置して、「Stop access checking once a relevant Access of Role to Object instance explicitly denies or grants access」オプションを有効にすると、アクセスグループ上のリストのそれよりも後方に配置されたアクセスロールによってアクセスグループに対して付与される権限を制限しやすくなります。 Access Denyルールのみを含むロールは、Access-Deny-Onlyアクセスロールといいます。

ルールレゾリューションは、Access Denyルールには適用されません。 システムには、Applies Toクラスとロール名の組み合わせごとに、最大で1つのAccess Denyルールを含めることができます。 クラス継承は適用されません。 影響を受ける各クラスにAccess Denyルールを作成します。

一般的なユースケースとして挙げられるのは、既存のペルソナ（ユーザーロール）のサブセットに非常に近い権限を持つペルソナ（ユーザーロール）が必要になった場合です。 たとえば、（Ordering:Manager Access Roleを使用する）既存のManagerペルソナを持つOrderingアプリケーションには、Associate Managerペルソナ（ユーザーロール）が必要です。その権限における唯一の違いは、開くことが許可されている注文の値です。 Access Denyルールを使った実装には、次のような方法が考えられます。

1. Ordering:AssociateManagerDenyというAccess-Deny-onlyアクセスロールを作成する
2. ビジネスルールで要求されるしきい値と注文値を比較するAccess WhenルールをOrderクラスで作成する
3. Orderクラスに新しいアクセスロールのAccess Denyルールを作成し、新しいAccess Whenルールを読み取りインスタンス設定として適用する

4. Ordering:AssociateManagersアクセスグループを作成し、以下のAccess Rolesを追加します。

   1. Ordering:AssociateManagerDeny - ビジネスルールに従って、Open Orderアクセスを拒否する
   2. Ordering:Manager – Managerのマネージャーが持っている権限と同じ権限を付与する

5. Ordering:AssociateManagersアクセスグループで「Stop access checking once a relevant Access of Role to Object instance explicitly denies or grants access」設定を選択します。

アクセスグループは、オペレーターIDレコードを通じてユーザーに関連付けられます。 アクセスグループは、アクセスグループ内のユーザーが持つアクセスロールを決定します。その集合体が、そのユーザーによる実行が許可されているアクションになります。 アクセスグループの命名規則は、アプリケーション名、コロン（:）、ユーザーグループです。

アクセスロールの命名規則は＜ApplicationName＞:＜GroupsName＞であり、GroupsNameは複数形になります（例：Customers）。

特定の権限に特化したアクセスロールを持っていると、複数のペルソナ（ユーザーロール）が、それぞれに違う主な責任に加えて、同じ責任を担う場合に便利です。 たとえば、HRアプリケーションのユーザーロールが、従業員、人事ゼネラリスト、人事マネージャー、役員だとします。 人事マネージャーも役員も、委任されたルールを更新できます。 この場合は、＜ApplicationName＞:DelegatedRulesAdminというアクセスロールを追加で作成します。 このアクセスロールは、人事マネージャーと役員のアクセスグループに追加することで、それぞれの主な責任に加え、委任されたルールを更新できるようになります。