アプリケーションをセキュリティ保護するための要件
組織内のアプリケーションセキュリティ担当者を探し、プロジェクトの開始時から当該担当者を巻き込んで、特定の要件、基準、およびどのレベルのペネトレーションテストが行われているかを確認します。
ルール
以下のタスクを実行します。
- プロパティが正しいタイプであることを確認します(単なるテキストではなく、整数、日付)。
- Rule Security Analyserを実行し、問題を修正します。
- Guardrailレポートでセキュリティ問題を修正します。
ルールセット
開発環境からアプリケーションを移行する前に、プロダクションルールセットを除く各ルールセットバージョンをロックします。 また、ルールセットレコードのセキュリティタブに3つの異なるパスワードを入力することで、バージョンの追加、バージョンの更新、およびルールセットルール自体の更新を行う機能をセキュリティ保護します。
関連文書
アプリケーションにドキュメントをアップロードできる場合は、以下のタスクを実行します。
- アップロード可能なファイルを適用するために、ウイルスチェッカーがインストールされていることを確認してください。 CallVirusCheckアクティビティの拡張ポイントを使用して、ウイルスチェッカーがインストールされていることを確認できます。
- ドキュメントタイプが許可されているかどうかを評価するために、SetAttachmentPropertiesアクティビティにWhen Ruleまたはデシジョンテーブルを追加することで、ファイルタイプが制限されていることを確認します。
承認
承認スキームが実装され、要件を満たすために広範にテストされていることを確認します。 SystemレコードでProduction Levelが適切な値に設定されていることを確認してください。 本番環境のProduction Levelを5に設定します。 Production Levelの値は、Rule-Access-Role-ObjルールとRule-Access-Deny-Objルールに影響を与えます。 これらのルールは、アクセスロールを持つリクエスターが読み取りおよび更新できるクラスを制御します。 この設定がユーザーの有効なニーズに干渉する場合は、Production Levelを下げる代わりに、アクセスを許可する優先Rule-Access-Role-Objルールを追加します。
認証
セキュリティポリシー(Dev Studio > Configure > Org & Security > Authentication > Security Policies)を有効にします。 セキュリティポリシーは、以下の認証タイプに対応しています。
- Basic Credentials
- SAML 2.0
- OpenID Connect
コンピューターセキュリティポリシーで追加の制限が必要な場合は、バリデートルールを追加します。 アプリケーションサーバーレベル、リクエスターレベル、アクセスグループレベルで、適切な長さのタイムアウトを設定します。
統合
アプリケーションセキュリティチームや外部システムチームと連携し、コネクターやサービスが適切な方法で保護されていることを確認します。
オペレーターとアクセスグループ
Pega Platformがセキュアモードでデプロイされている場合、デフォルトではout-of-the-boxユーザーが無効になります。 プラットフォームがセキュアモードでデプロイされていない場合、使用されていないユーザーを無効にします。 オペレーターパスワード、アクセスグループ、およびアプリケーションルールの変更に対するセキュリティ監査を有効にします。
Unauthenticatedアクセスグループのレビューを行い、ルールに必要な最小限のアクセス権があることを確認します。
Dynamic System Settings
本番環境では、セキュリティチェックリストに記述されているとおりにDynamic System Settingsを設定します。
デプロイメント
アプリケーションを開発環境以外にデプロイする場合は、特定の機能を制限またはブロックし、不要なリソースを削除します。 デフォルトの設定では、侵入者に既知の開始点を提供するため、アプリケーションをリスクにさらします。 デフォルトを排除することで、全体的なリスクを大幅に減らすことができます。
以下のとおりデフォルトの設定を変更します。
- prweb.warを必要とするノードにのみ名前を変更してデプロイします。 prweb.warのフォルダーとコンテンツを把握すると、アプリケーションにアクセスできるようになるため、セキュリティ上のリスクが高まります。
- 不要なリソースやサーブレットをweb.xmlから削除します。 特にPRServletやPRAuthなど、必要に応じてデフォルトのサーブレットの名前を変更します。
- prhelp.warの名前を変更し、環境ごとに1つのノードにデプロイします。
データベース
prconfig.xml.でデータベースを設定するのではなく、アプリケーションサーバー経由のJDBC接続プール方式を使用してシステムを設定していることを確認してください。
開発以外の環境でPegaRULESデータベースアカウントに利用可能な機能とロールを制限し、テーブルの切り捨て、テーブルの作成または削除、その他のスキーマの変更などの追加機能を削減します。 これにより機能やロールが制限されていると、「Database Schemaツールの表示または変更」が読み取り専用モードで実行される場合があります。
このトピックは、下記のモジュールにも含まれています。
- セキュリティリスクの低減 v3