認証モデル
認証モデルは、Pega Platform™の特定の機能に対するユーザーのアクセスを定義します。 たとえば、実行時にクラスの特定のインスタンスでデータを閲覧したり特定のアクションを実行するエンドユーザーの機能を制限できます。 設計時にルールを作成、更新、または削除することを制限したり、ClipboardツールやTracerツールなどの特定のアプリケーション開発ツールへのアクセスを決定したりする、ビジネスアーキテクトやシステムアーキテクトの機能を制限できます。
Pega Platformには、ロールベースのアクセス制御(RBAC)と属性ベースのアクセス制御(ABAC)という、種類は異なるものの補完関係にある2つの認証モデルが用意されています。 ロールベースのアクセス制御と属性ベースのアクセス制御は共存しています。
ロールベースのアクセス制御(RBAC)
Pegaアプリケーションでは、通常、多くのペルソナ(ユーザーロール)が一堂に会して作業を行います。 ロールには、顧客、コールセンター従業員、マネージャー、管理者などがあります。 ほとんどのユーザーは、特定のアプリケーションに適用可能なロールのいずれかを満たしています。 RBACは、あるロールが、次に示すクラスごとに実行することを許可されたアクションを定義します。
- クラス全体のアクション:アクティビティの実行、レポートの実行
- レコードレベルのアクション:開く、変更(作成と更新)、削除
- 権限によって規定されるルール固有のアクション
ロールベースのアクセス制御(RBAC)のルールタイプのレビュー
すべてのアプリケーションには、認証の基礎となる明確なロールがあります。 次のルールタイプを使用してRBACを設定します。
- Access group:1つのペルソナ(ロール)に対して、ロールベースのアクセス制御ポートフォリオを形成する、アクセスロールのコレクション。
- Access role:アクセスロールを割り当てられたユーザーに許可(および拒否)するアクセス権を規定するすべてのロールベースのアクセス制御設定を定義する、Access of Role to ObjectルールとAccess Denyルールのコレクション。
- Access of Role to Object(ARO):アクセスロールと、そのアクセスロールの保有者がオブジェクト(クラスインスタンスなど)で実行することを許可または拒否される操作との関連付け。
- Privilege:特定のルール(の一部)を実行することを許可されたユーザーの認証を行うルールタイプ(またはその一部)に付けられるルール。 下記のような例があります。
- ApprovePR権限の保有者のみが、Approve Purchase Requestフローアクションを実行できます。
- ShowPR権限の保有者のみが、Navigationルール内で設定された「Show Purchase Requests」メニュー項目を表示できます。
- Class:認証の対象となるデータのタイプ。
- Access Whenルール:通常は認証の対象となるクラスの1つ以上のプロパティを評価する、条件付きアクセス制御を定義するルール(通常のWhen Ruleなど)。 この意図は、Access Whenルールから得られるアクセス制御結果が、同じクラスの異なるインスタンス間で変化することです。 下記のような例があります。
- Purchase Requestケースは、現在Approvalステージにありますか?
- 従業員の給与は50,000米国ドルを超えていますか?
- Access Denyルール:アクセスロールと、そのアクセスロールの保有者がオブジェクトで実行することを許可または拒否される操作との関連付け。
最近のRBAC機能
Pega Platformの最近のリリースでは、ロールベースのアクセス制御にさらに影響を与える次の機能が登場しています。 それぞれの例については、後のモジュールで説明します。
- 依存関係にあるロール:アクセスロールの依存関係の階層に基づいて、アクセスロールを設定し、実行時に完了できるようにします。
- 権限の継承:あるアクセスロール(そのAROによって)のクラスに付与された権限に、同じアクセスロール内にあるそのスーパークラスのAROで指定された権限を含めることができるようにします。
- 短絡アクセスチェック:明示的な許可または拒否の結果を導くアクセスロールのうち、特に明示的な許可の場合に、アクセスグループの後続のアクセスロールをチェックせずに、アクセス制御をアクセス許可と決定する最終結果を直ちに返すことができるアクセスロール
- App Studio管理下の認証:App Studioには、Dev Studioで提供されるRBAC基盤を補完する基本的な認可設定機能が用意されています。 シチズンデベロッパーがアクセスロールを管理できるようにするには、アクセスグループの「App Studioでページアクセス設定を有効にする」チェックボックスを選択します。
権限の重要性
権限は、個々のルールまたは個々のルールの一部へのアクセスを制御するために使用することができるため、セキュリティ品質を向上させます。
権限は、特定のルールの実行の明示的な認証を行う機会を提供するため、認証戦略に欠かせない要素です。「必要なものを、必要なだけ、必要なときに。」権限は、クラスバージョンやルールセットバージョン全体ではなく、特定のルールへのアクセスを制限することにより、アクセスロールや権限リストで提供されるセキュリティーとアクセス制御の機能を補完します。 アプリケーション内の異なるグループのユーザーの機能を差別化するために、権限を使用します。 権限によって、アプリケーションの予期せぬ利用目的で、意図しないルールを実行しないようにすることができます。
ランタイムロールの解決と権限の継承
クラスベースでAccess of Role to Object(ARO)ルールを定義すると、Pegaはクラス階層を誘導し、そのロールのオブジェクトのクラスに関連する最も具体的なAROを決定します。 そのロールのクラス階層にある、具体性の乏しいAROは無視されます。 実行される操作は、最も具体的なAROでその操作が許可されている場合に許可されます。 オペレーター(Operator)に複数のロールが付与されている場合は、各ロールに応じて最も具体的なAROルールが決定されます。 Pega Platformは、最も具体的なAROのいずれかで操作が許可されている場合に、その操作を実行します。
前述のとおり、権限は個々のルールで定義されるため、きめ細やかなセキュリティが得られます。 たとえば、権限で保護されたフローアクションを実行するには、ユーザーに権限が付与されている必要があります。 権限は、オブジェクトのClassに対する最も具体的なAROを通して付与されます。 ただし、クラス階層で定義されたARO内の権限を継承するためのロールにオプションがあります。 このオプションを選択すると、オブジェクトのクラス階層内のクラス向けに定義されたAROによって付与されるすべての権限がオペレーターに付与されます。
次の例では、ロールに権限を継承するオプションが選択されています。 ユーザーがExpense Reportケースで作業する場合、アクセス権限は太字で強調表示された行で定義されます。 追加の権限は、クラス階層(TGB-HRApps-WorkおよびWork-)から継承されます。
アクセス クラス |
読み取り インスタンス |
書き込み インスタンス |
削除 インスタンス |
読み取り ルール |
書き込み ルール |
削除 ルール |
実行 ルール |
実行 アクティビティ |
権限 |
---|---|---|---|---|---|---|---|---|---|
Work- | 5 | 5 | 5 | 5 | 5 | AllFlows(5) AllFlowActions(5) |
|||
TGB-HRApps-Work | 5 | 5 | 5 | 5 | 5 | ManagerReports(5) | |||
TGB-HRApps-Work-ExpenseReport |
5 |
5 |
5 |
5 |
|
|
5 |
5 |
SubmitExpenseReport(5) |
属性ベースのアクセス制御(ABAC)
ABACは、、アプリケーション(画面上やレポート内)のどこでその属性が使用されているかにかかわらず、アクセス制御ポリシーがレコードの特定の属性へのアクセスを制御できるようにすることにより(RBACによりレコードへのアクセスが許可されている場合)、RBACを補完します。 また、ABACを使用して、(RBACに追加して)レコードレベルのアクセス制御を定義することもできます。この場合、オペレーターがアプリケーションに果たすロールによって、それらのレコードにアクセスする条件が決定されるわけではありません。
RBAC | ABAC | |
---|---|---|
ルール | 前のセクションのRBAC図参照 |
Access Control Policy (ACP) Access Control Policy Conditions (ACPC) Access when |
コントロール |
Open instances Modify instances インスタンスを削除 ルールを開く ルールを変更 Delete rules |
Read Discover Update Delete Property Read Property Encrypt |
ABACはオプションで、RBACと組み合わせて使用します。 ABACは、ユーザー情報とケースデータを行単位または列単位で比較します。 アクセスの種類を指定するアクセス制御ポリシールールと、クリップボード上のユーザープロパティやその他の情報を制限付きクラスのプロパティと比較する一連のポリシー条件を定義するアクセス制御ポリシー条件ルールを使用して、ABACを設定します。
Assign-、 Data-、Work-から継承したクラスにアクセス制御ポリシーを定義し、Pega Platformの完全な継承機能を使用します。 アクセス制御ポリシーの条件は、継承パスに同一タイプの複数のアクセス制御ポリシーが異なる名前で存在する場合、AND演算と結合します。 アクセス制御ポリシーの条件がすべて満たされた場合にのみアクセスが許可されます。
次の例では、HR Application(人事アプリケーション)のユーザーが購入ケースの更新を希望する場合、クラス階層で定義されたアクセス制御ポリシーの条件がANDと結合します。 ユーザーは、WorkUpdate、HRUpdate、およびHRPurchaseUpdateをtrueと評価する場合のみ、購入ケースを更新するためのアクセスが許可されます。
アクセスクラス | Read | Update | Delete | Discover | PropertyRead | PropertyEncrypt |
---|---|---|---|---|---|---|
Work- | WorkRead | WorkUpdate | WorkDiscover | |||
TGB-HR-Work | HRUpdate | HRDelete | HRDiscover | HRPropRead | ||
TGB-HR-Work-Purchase | HRPurchaseRead | HRPurchaseUpdate | HRPurchasePropRead | HRPurhcasePropEncrypt |
過去にABACを無効にしていた場合は、次のDynamic System Settingsを更新してABACを有効化できます:
短い説明:属性ベースのセキュリティを有効にする
ルールセットの所有:Pega-RulesEngine
設定目的:EnableAttributeBasedSecurity
値:true
RS:Pega-ProcessCommander
クライアントベースのアクセス制御(CBAC)
Pegaのもう1つのアクセス制御機能は、クライアントベースのアクセス制御(CBAC)です。 この機能は、EUのGDPR(および類似の)規制で必要な、Pegaアプリケーション全体で保持されている個人的な顧客データの閲覧、更新、または削除の要求を追跡し、処理することに重点を置いています。 Pegaアプリケーションの設計時にリードシステムアーキテクトの認証上の考慮事項には影響しないため、このモジュールでの説明は以上になります。
CBACに関する詳細については、Pega Communityの記事、「Defining client-based access control rules」をご覧ください。
このトピックは、下記のモジュールにも含まれています。
- 承認スキームの定義 v3