Securing a public facing application

From PegaWiki
Deploying a Public Facing Application / This is the approved revision of this page, as well as being the most recent.
Jump to navigation Jump to search

Securing a public facing application

Description Securing a public facing application
Version as of 8.4
Application Pega Platform
Capability/Industry Area Security

The security checklist

Security is critical in all applications, especially in applications accessed by external operators –customers and prospective customers – who are not your employees. Inadequate security can prevent your application from being deployed.

The Security Checklist:

  • Provides Pega’s leading practices for securely deploying applications.
  • Must be completed to ensure the confidentiality, integrity, and availability of your application in production.
  • Recommends when each task should be performed: At or near the beginning of development, on an ongoing basis, or just before deployment. Follow these recommendations to avoid expensive rework late in your development process.

Unless otherwise noted, these recommendations apply to all deployment environments, including Pega Cloud Services®. The most important security requirement for all Pega Platform applications is to maintain guardrail-compliance because Pega Platform security features cannot always be successfully enforced in custom code.

You can secure applications by configuring only the built-in features in Pega Platform, without relying on custom code built by developers who are not security experts. For more information, see the Security Checklist.

Pega Platform shows the overall completion of the Security Checklist on the Dev Studio home page, and provides tools to track the status of each task. For more information, see Preparing your application for secure deployment.

Authenticating public users

Unauthenticated individuals should not have access to or be able to modify the application or its data. It is critical to verify the identity of application users. This generally involves one of the following three use cases.

There is a special type of Authentication Service designed for each, and these should always be used:

A user is initially anonymous (identity unknown). The users may register themselves or have their identity verified partway through a session. Example: Online shopping, where unauthenticated users can browse and add items to a shopping cart, and then either create an account or enter their credentials to check-out. For such applications, you should define an Anonymous type Authentication Service rule.

You will specify an access group for all such users, and of course this access group should be strongly limited to access only data and applications functions that should be publicly available and are not in any way confidential (such as the product catalog and shopping cart information mentioned above).

Use the Re-Authentication gadget to challenge the user to enter login credentials and change their context and access group information, rather than writing custom code. For more information, see Configuring an application to use an anonymous authentication service

A user’s credentials must be verified during login using an external data store or database, such as a Customer Master file.

In this case, user credentials are verified at the start of a session, but those credentials are stored outside Pega. For such applications, you should define a Basic Credentials type Authentication Service rule, choose the option to Verify credentials using an external identity store, and define a data page to access the external data store. For more information, see Configuring a basic authentication service.

The user is authenticated through their credentials on a social media site like Google. For more information, see Creating a Google authentication service.

For other options to authenticate users, see Authentication in Pega Platform.

Protecting sensitive client data

Never deploy a public-facing application that creates or stores personally identifiable information (PII), such as social security numbers, account numbers, health data, date of birth, addresses, phone numbers, or any other sensitive data that could be used to identify an individual, without protecting it from unauthorized access.

Follow these steps to encrypt sensitive property values:

  • Set up a master key in an external Key Management System.
  • Define a Keystore rule instance that references the master key.
  • On the Data Encryption landing page in Dev Studio, reference the Keystore rule that accesses the master key.
  • Define PropertyEncrypt access control policies and list the properties to be encrypted.
  • Define PropertyRead access control policies to conditionally mask or obfuscate these property values for operators who should not be able to view them.

For more information, see:

Exposure of information to users during logins

You should set up a “vanity” URL or custom domain name that does not unnecessarily expose server information to users.

For more information on how to do this on Pega Cloud, see Requesting a custom domain name.