セキュリティのベストプラクティス

ユーザーがWork-Perform権限を必要とすることが確実でない場合は、念のため、WorkMgr4などの許容的なアクセスロールは早い段階で割り当てないでください。 たとえば、特定のレポートを表示すると、ケースワーカーの生産性が向上する可能性がありますが、そのためには、アクセスロールWorkMgr4を定義し、マネージャーポータルへのアクセスを許可することによって、ケースワーカーにマネージャーポータルを割り当てる必要があります。 その代わりに、専用のケースワーカーポータルにダッシュボードを追加できます。

Rule-Access-Role-Object（Access of Role to Object、略してARO）ルールはバージョン管理の対象外です。 別のルールセット内でAROルールをオーバーライドすることはできません。 キーpyAccessRoleとpyAccessToClassに基づくAROルールのインスタンスは1つだけです。

Perform権限をデフォルトとして削除するようWork-AROを更新するのとは対照的に、FSG-Booking-Workをはじめとしたワークプールクラスなど、より具体的なクラスを追加できます。 その新しいARO内でPerform権限を削除できます。 次に、マネージャーが監視している一連のケースタイプにPerform特権を付与できます。

URLの難読化は、URLが攻撃者によって解読されないことの保証ではありません。URLがシステムによって保護されていないと、閲覧を許可してはならない情報に攻撃者がアクセスできるようになり、さらに悪いことには、攻撃者がシステムの情報を変更できるようになります。

情報を隠したからといって、セキュリティが確保されるわけではありません。 特定のワークグループのメンバーまたは特定のプライマリアクセスロールを持つユーザーがケースタイプの作成を許可されるべきでない場合は、そのアクセスを明示的に禁止する認可ポリシーを定義する必要があります。 Whenルールを使用してData-Portal pyPortalNavInnerセクション内のpyCreateCaseMenuを非表示にすることは、解決策の一部にはなり得ても、適切な解決策ではありません。 このことは、Whenルールが権限をチェックするかどうかにかかわらず当てはまります。

真のセキュリティが（適切な認可を介して）実装されていない限り、QueryString （?pyActivity=doUIAction&action=createNewWork&className=）を活用でき、かつケースを作成できるユーザーであれば誰でもURLを定義できます。

または、開発者はWhenルールを使用して、ユーザーが特定のアクセスロールまたは権限を持っているかどうかを確認できます。 セキュリティチェック用のWhenルールは、それよりも適切な施行手段がない場合に役立ち、ユーザーエクスペリエンスを向上させるための適切な認可と組み合わせて使用できます。

施行が必要な状況でWhenルールを適用しなければならなくなる事態は避ける必要があります。 それを行うことは、if/elseロジックを含んだコードを記述することと同じです。つまり、新しい「else」値が発明されるたびに、if/elseロジックの更新が必要となります。 セキュリティを強化するオブジェクト指向の方法は、オブジェクトに到達するすべてのパスを保護するのではなく、最終的にアクセスされるオブジェクトを保護することです。

例:

あるオペレーターがケースへの読み取りアクセス権を持っているが、実行アクセス権は持っていないとします。 このユーザーは次のようなURLを発行できます。

エラーメッセージは表示されません。 代わりに、画面に「NoID」と表示され、「Open in Review」というボタンが表示されます。

このユーザーが現在の所有者またはケースを最後に更新したユーザーでない限り、このユーザーによるレビューモードでのケースの表示を禁止したいとします。 この場合、アサインメントへのアクセスを防ぐだけでは十分ではありません。 「Assign- Read access = canPerform」によって防げるのはアサインメントの実行だけであり、 関連するケースが開かれるのを防げるわけではありません。 また、アクセスの禁止または許可をケースレベルで行うことも必要です。

FSG-Booking-Workの以下のRBA設定に注目してください。 pxRelatedToMe Access Whenルールでは、現在のオペレーターが最後に更新または完了したケース、または現在のオペレーターが現在管理しているケースのみを開くことができます。 同僚がケースを開くことは許可されていません。

Bookingアプリケーションでは、営業担当者の主要なアクセスロールをPegaRULES:User4からクローンするか、さらにはそれに依存する必要があります。 次の図は、SalesExecutive2@Booking によって所有されている変更後のケースをSalesExecutive1@Booking が開こうとしたときに何が起こるかを示しています。

「Bulk Actions」オプションは、ケースワーカーおよびケースマネージャーポータルのオペレーターメニューにあります。 施設コーディネーターにイベントケースの作成を許可しないことが要件であり、かつ、適切な認可ポリシーが設定されていない場合、施設コーディネーターはバルクアクションを使用してケースを次のように作成できます。

ステップ 1:

ステップ2：

アプリケーションを本番環境にデプロイする前に確認しておくべき複数の領域があります。 各Deployment Managerパイプラインには、アーキテクトにこの重要なタスクを思い出させるためのセキュリティレビューステップが含まれています。 セキュリティガイドラインは、アプリケーションルールのDocumentation タブから起動できるpxApplicationSecurityChecklist アプリケーションガイドルールに含まれています。

詳細については、セキュリティチェックリストを確認してください。

セキュリティ設計の詳細については、セキュリティエクセレンスに関するウェビナーをご覧ください。