ロールの従属（依存）関係の階層

Pega Platform™では、アクセスロールの依存関係階層を定義することで、特定の権限が必要なユースケース向けにアクセス制御をカスタマイズしながら、標準のアクセスロールから継承された権限を保持できます。 ロールの従属（依存）関係という考え方は、クライアントがロールを「クローン」してカスタマイズするのではなく、製品に同梱されているPegaロールをベース（依存先）とする新しいロールを作成することです。 クライアントの新しいロールは、カスタマイズされたロールが提供する権限を持つだけでなく、従属ロールが提供する権限も継承します。

従属ロールを使用すると、アプリケーション間の権限を標準化し、アクセス制御モデルの保守性を向上できます。

たとえば、アクセスロールMyApp:Userは、Pega Platform™のアクセスロールPegaRULES:User4,に依存するよう構成でき、MyApp:Userに対して明示的にAccess of Role to Object（ARO）レコードを定義しなくても従属ロールで利用できるすべての権限を継承できます。 これは、「Manage dependent roles」をクリックすると定義できます。

「Manage dependent roles」ダイアログボックスの「Dependent roles」フィールドに、ユーザーロールを入力または選択します。

この例では、MyApp:Userアクセスロールを含むアクセスグループは、それ自体のAccess Role to Object（ARO）レコードを持っていなくても、あらゆるケースタイプのインスタンスの読み取りと書き込みが許可されたままです。 その理由は、次のとおりです。

• MyApp:UserアクセスロールにAROレコードがないということは、このアクセスロールがアクセスを許可も拒否もしないということです。 アクセスロールだけでは、何の権限の結果も生じません。
• MyApp:UserはPegaRULES:User4に依存しているので、未解決の権限チェックはPegaRULES:User4に委ねられ、そのアクセスロールが結果を出すかどうかを判断します。
• PegaRULES:User4では、MyAppアプリケーションに固有のケースタイプに対してAROが定義されていないため、ロールベースアクセスコントロール（RBAC）アルゴリズムは、そのケースタイプのクラスの継承階層を調べて、このチェックに関連するAROを検索します。PegaRULES:User4では、Work-（MyAppのケースタイプのスーパークラス）のAROを定義しています。これは、MyAppのケースタイプのインスタンスに最も具体的に一致するAROです。
• 設定5ではケースタイプへの読み取りと書き込みのアクセスが明示的に許可されているため、PegaRULES:User4から得られたこの結果は、MyApp:Userアクセスロールの同じ権限チェックの結果としても伝搬されます。

ユーザーは、複数の従属ロールを入力することもできます。 その場合、アクセスロールはOR操作で結合され、各アクセスロールに対して最も具体的なAROのうち1つだけがアクセスを許可され、操作できるようにする必要があります。

アクセスロールが既存のアクセスロールの権限の結果をほぼ尊重しつつ、特定のシナリオで結果を上書きする必要がある場合には、従属ロールを使用して新しいアクセスロールのAROのみを構成し、従属ロールから得られる結果を上書きすることもできます。 最上位ロールで指定されていない権限の結果は、その従属ロールに結果を委ね続けます。

たとえば、Pega Platformのユーザーに通常与えられているその他のアクセス権をすべて維持したまま、解決済みでない場合にのみすべてのケースタイプを更新するようMyAppユーザーを制限する必要がある場合について考えてみます。 従属ロールを使用すると、これはMyApp:Userの1つのAROを使用して実装でき、これにより必要な制限を指定します（アプリケーション固有のAccess Whenルールを使用）。

AROの他の設定をすべて未指定にすることで、他の権限チェック（例：読み取りアクセス）は従属ロール（この例では、PegaRULES:User4）に委ねられます。 最上位ロールの設定が読み取りアクセスを上書きしないため、読み取りアクセスは従属ロールによって引き続き許可されます。

従属ロール階層を使用するメリットは、次のとおりです。

1. アプリケーション固有のアクセスロールのAROの重複がなくなる。上記の例では、MyAppが再利用可能なベースラインを変更するために必要な設定は1つだけでしたが、従属ロールを使用しない場合は、ARO（および他のARO）の他のすべての設定をMyApp:Userアクセスロールに重複させる必要があります。
2. アクセスロールを階層化できる。汎用的なアクセスロールを作成することで、同様のユーザーロールを使用するアプリケーション固有のアクセスロールの権限の基盤とすることができます。 アプリケーション固有のアクセスロールは、汎用的なアクセスロールに依存関係を設定でき（これによりPega Platformのアクセスロールにも依存する場合があります）、アプリケーションレイヤーとその依存するレイヤー間で異なる動作のみの設定を段階的に追加していくことができます。
3. 複数の依存関係を設定する。アクセスロールは、複数の従属アクセスロールを持つように構成できます。複数の従属関係を設定することで、異なるアクセスロールの集合体に基づいて権限の結果を達成できるようになります。 多くの場合、一部の例外ユーザーは、同時に複数のユーザーロールの責任を担っています。 これらのユーザーのためにアクセスロールを作成し、その依存先に同じアプリケーションの複数の兄弟アクセスロールを設定することで、この結果を達成できます。
4. Pega PlatformまたはPegaアプリケーションの権限を再利用する。多くの場合、エンドユーザー、マネージャー、システム管理者などの一般的なユーザーロール用にPega Platform（または構築中のPegaアプリケーション）に常駐するアクセスロールは、必要な権限の結果のほとんどを実現します。 アプリケーション固有のアクセスロールを対応するPega Platformアクセスロールに従属する形で導入することにより、AROを重複させることなく、有効な権限のベースラインを提供できます。
5. 保守性。アプリケーション固有のアクセスロールに固有の権限要件のみを設定し、残りはその依存ロールに委ねることで、アプリケーションの保守担当者に対し、アプリケーション固有の権限がより一般的に理解される基盤からどの程度逸脱しているかを明示できるようになります。 従属ロールを使用せずにRBACを構成すると、アプリケーションレベルでAROの数が増え、その多くはPegaが提供するアクセスロールのクローンをわずかに修正したものになります。 わずかな修正では、分離が難しくなる場合もあります。
6. アップデートの容易性。重複するAROを削除し、代わりに従属ロールで指定されたAROに委ねることで、Pega PlatformやPegaアプリケーションのアップデートによって、アップデートで提供される権限の変更を即時にアプリケーションの権限に反映させることができるように改善されます。

従属ロールを使用しない場合は、アプリケーション固有のアクセスロールには、新規または更新されたPegaアクセスロールへのリンクがないため、次のような影響が生じます。

• アプリケーション固有のアクセスロールは、アップデートされたアクセスロールでPegaの認証モデルへの変更をマスクします。
• Pegaのアップデートで提供される新機能は、アプリケーション固有のアクセスロールがマスクする、アップデートされたアクセスロールの権限に依存する場合があります。