ロールベースのアクセス制御
アプリケーションとデータのセキュリティーは、データ侵害による顧客の喪失、法的処罰や罰金が生じるリスクがあるため、大きな関心事となっています。 アプリケーションの機能へのユーザーのアクセスを制御することで、一般的なセキュリティー要件を満たすことができます。
補足： 機能へのアクセスを保護することは、開発サイクルの最後ではなく、各機能の開発時に行われます。
ロール
ロール（役割）は、ユーザーがアプリケーションとやり取りする方法、表示されるユーザーインターフェイス、そしてユーザーができる作業とできない作業を定義します。 特定のロールに割り当てると、ユーザーはケース処理中に作業できるようになります。 ロールの例としては、顧客、ケースワーカー、マネージャー、監査者などが挙げられます。 デベロッパー、管理者、マネージャーにも、それぞれの作業を実行するためのロールがあります。 ユーザーをロールに割り当て、アプリケーションとやり取りする方法を指定します。
たとえば、医療アプリケーションでは、患者と医師は異なるタスクを実行可能にする必要があります。 患者は記録を確認し、アポイントメントをスケジュールできます。 医師は、患者の診療記録を確認し、処方箋を記録し、検診後にフォローアップ コメントを追加できます。 適切なロールを指定された患者と医師が、正しいユーザーインターフェイスを表示し、適切なアプリケーション機能にアクセスできるように、異なるロールを定義します。
アプリケーションを作成すると、デフォルトで4つのロールが作成されます。この4つとは、管理者（Admin）、作成者（Author）、ユーザー、マネージャーです。 ユーザーインターフェイス、ページ権限、ルーティングの固有の組み合わせが必要な場合には、別のロールを作成します。 Pega Platform™では、ユーザーインターフェイスはチャネルインターフェイスとも呼ばれます。 作業はワークキューにルーティングされます。ワークキューとは、ユーザーのグループのすべてのオープンアサインメントのリストです。 アサインメントとは、ユーザーが実行するタスクです。 新しく作成された各ロールには専用のワークキュー、チャネル、権限のセットがあります。
たとえば、「Author」ロールには、App Studioのインターフェイスが表示されます。 「User」ロールには、「Case Worker」インターフェイスが表示されます。 作成者のロールには、新しいユーザーとロールを作成する権限があるため、作成者のロールのユーザーは、ユーザーインターフェイスでそれらのアクションを表示できます。 ユーザーのロールを持つユーザーはケースを作成し処理します。アプリケーションを変更することはできません。
ロールをStudioチャネル（App Studio、Admin Studio、Dev Studio）およびウェブチャネルインターフェイス（ケースマネージャーやケースワーカーなど）に関連付けることができます。
ロールベースのアクセス制御モデル
従業員の昇給を承認するためのアサインメントを含む、従業員レビューのプロセスを検討します。 アサインメントは人事部のすべてのメンバーがアクセスできる共通のワークキューにルーティングされます。 プライバシーの問題から、昇給案に対するアクセスは給与情報にアクセスできる人事部のメンバーのみに制限したいと考えています。 人事部の特定のメンバーに権限を付与することで、個人識別情報（PII）への不正アクセスの可能性を減らすことができます。
PIIへのアクセスを制限する要件を満たすために、ロールベースのアクセスコントロール（RBAC）を実装できます。 RBACは、ユーザーをロールごとに組織し、各ロールに適切な権限を割り当てて制御するアクセスコントロールモデルです。 RBACでは、給与情報にアクセスできる人事部のメンバーに対してロールを作成し、そのロールに従業員の昇給を承認する権限を付与することができます。 権限を付与されていない他のロールのユーザーは、昇給を承認することはできません。
Pega Platform™でのロールベースのアクセスコントロールは、認証と承認という2つの要素に基づいて実装されます。
- Authentication（認証）は、ユーザー名やパスワードなどのログイン情報を検証することで、ユーザーの身元を確認します。 Pega Platformでは、ユーザーを認証するために必要な情報がオペレーターIDに含まれています。
- Authorization（承認）は、ユーザーが実行できるアクションや閲覧できる情報など、ユーザーがアクセスできるアプリケーションを決定します。 Pega Platformでは、アクセスグループのレコードには、アクセスグループのメンバーに割り当てられた承認済みのアプリケーションとロールが一覧表示されます。
指定されたユーザーがサインインすると、Pega Platform™ではユーザーのデフォルトアクセスグループが識別され、指定されたポータルに対応するアプリケーションが開かれます。 ユーザーは複数のアクセスグループに所属できますが、一度にアクティブにできるアクセスグループは1つに限られます。
補足： 次の例では、OOTB認証について説明しています。 ただし、SSO認証が最も一般的な実装になります。 詳細については、「Single sign-on (SSO)」を参照してください。
次の図の「+」アイコンをクリックすると、Pega Platformで認証と承認を使用して、ユーザーログイン時にオープンする適切なアプリケーションとポータルを識別する方法について確認できます。
アクセスロール
アクセスロールは、ユーザーを各ユーザーの職務権限に従って分類します。 各アクセスロールは、一連のユーザーがケースの作成や処理のためにアプリケーションとやり取りする方法を表します。 たとえば、購入リクエストを管理するアプリケーションで、ユーザーは購入リクエストを送信できますが、購入リクエストを承認できるのは管理者だけです。
各アクセスグループは、1つ以上のアクセスロールを参照します。 Pega Platformのアクセスグループから複数のロールを参照できるようにすることで、モジュラーアプリケーションのきめ細かいロールを組み合わせたセキュリティーモデルを設計でき、複雑なセキュリティーのニーズにも対応できます。
アクセスロールごとに、ユーザーが作成または変更できるケースのタイプなど、特定クラスのインスタンスに対するアクションを制御するアクセス権限を設定します。 アクセスグループが参照するロールのアクセスコントロール設定が競合している場合、Pega Platformではすべてのロールで最も寛容な設定が適用されます。 次の例では、マネージャーはUserとManagerの両方のアクセスロールを含むアクセスグループに属しています。 マネージャーアクセスロールがあるユーザーは休暇リクエストの承認と送信を行うことができますが、ユーザーアクセスロールでは、承認および送信のアクションが禁止されています。 マネージャーアクセスグループは両方のロールを参照するため、このアクセスグループのメンバーは休暇リクエストを承認して送信できます。
次の問題に答えて、理解度をチェックしましょう。
ロールベースのアクセスコントロールのレコードタイプ
RBACモデルにより、アクセスコントロールのニーズを満たす動作の設定に使用されるいくつかのタイプのレコードが提供されます。 次の画像で「+」のアイコンをクリックすると、各タイプのアクセスコントロールレコードについて学習できます。
Access of Role to Object
RBACモデルの基盤となるのは、Access of Role to Object（ARO）レコードです。 AROレコードを使用すると、特定のクラスのインスタンスに対するアクセスコントロール設定を定義できます。 各AROでは、指定されたクラスのインスタンスに対してロールで実行できるアクションが識別されます。 たとえば、購入リクエストケースを記述するクラスに関連付けられたPurchaseRequest:Administratorsという名前のAROでは、ユーザーがケースを開くことはできても、レポートを実行することはできません。
AROはそれぞれアクセスロールとクラスの固有の組み合わせに対応します。 これにより、Pega Platformでは、AROで設定された権限を特定のロールのユーザーに適用できます。
AROでは、0～5のスケールで権限が付与されます。0に設定すると、アクションを実行する権限が拒否されます。 1～5では、同じかそれより低い本番レベルのシステムで権限が付与されます。
- アクセスがありません
- 実験/サンドボックス
- 開発
- テスト/品質保証
- プリプロダクション/ステージング
- 本番稼働
たとえば、権限を5に設定すると、ユーザーは本番システムと同じかそれよりも低いレベルのシステムでケースを表示できます。 権限を3に設定すると、ユーザーは開発システムやテストシステムでケースを表示できるものの、ステージングシステムや本番システムでは表示できなくなります。
アクセス拒否
規制やポリシーで特定の機能へのアクセスを明示的に拒否する必要がある場合は、アクセス拒否レコードを設定できます。
アクセス拒否レコードはAROと同じように機能します。 AROと同様、アクセス拒否レコードはロールとクラスの固有の組み合わせにそれぞれ対応します。 アクセス拒否レコードを使用する場合、0～5のスケールでアクション権限の拒否を指定できます。0はアクションの許可を示します。 1～5は、本番レベルの同じかそれ以上のシステムでアクションを拒否することを示します。
たとえば、アクセス拒否レコードで購入リクエストケースタイプのインスタンスのケース履歴を表示するアクセス権限を5に設定している場合、本番システムでアクションが拒否されます。
補足： 同じロールとクラスの組み合わせに対してAROとアクセス拒否レコードが定義されている場合、AROの設定よりアクセス拒否レコードの設定が優先されます。
Privilege
権限レコードは、特定のルールに対するアクセスを制御するために使用します。 ほとんどのルールでは、必要な権限がルールフォームのSecurity タブに表示されています。 フロールールに必要な権限はProcess タブに表示されています。 ルールには複数の権限を含めることができます。 ルールに含まれる権限のいずれかをユーザーに付与すると、ユーザーはルールを実行できるようになります。
権限レコードはトークンとして機能します。 ルールを実行するのに権限が必要な場合、ルールを実行できるのはその権限を付与されたユーザーに限られます。 ロールに権限を付与するには、権限レコードを適切なAROに追加します。
ルールレゾリューションの処理中には権限が考慮されますが、候補ルールがルールキャッシュに追加された後に限られます。 必要な権限のないユーザーがルールを実行しようとした場合、アプリケーションによりエラーが返され、別のバージョンのルールの試行は行われません。
次の問題に答えて、理解度をチェックしましょう。
If you are having problems with your training, please review the Pega Academy Support FAQs.