Managing Security in SAP CPQ

SAP CPQ complies with SAP software security policies and guidelines and is a trusted tool for safely maintaining products, pricing rules, customers, and quotes.

There are application parameters and features that allow administrators to enhance the security of the system according to their business requirements and models.

The features available for enhancing the security of data and access to the system include the following:

• Automatic Data Deletion
• Personally Identifiable Information
• WSDL and Certificate Management
• Access Rights
• DKIM Support for Outbound Emails
• Content Security Policy in SAP CPQ
• WSDL and Certificate Management
• Credential Management

SAP CPQ doesn't have a retention framework for keeping and managing access to customer data after the business purpose for keeping the customer data in the system has expired. SAP CPQ has a data deletion functionality to delete customers from SAP CPQ once the business purpose has expired. SAP CPQ is used in integrations with CRM software and back office systems (ERP) and acts as the single source of customer data. For this reason, no retention policy has been developed. The data is only replicated into SAP CPQ and must be deleted after there's no longer any business purpose.

The data deletion functionality allows the setting of a data deletion policy and the management of an account's storage space. You can set a time where the system automatically and permanently deletes the data. There's also an option to keep quotes, users, and business partners from being deleted. It's recommended that only data protection officers in cooperation with administrators use this feature and define a data retention policy.

The following data can be permanently deleted:

• Quotes
• Users
• Business Partners
• User actions
• Administrator actions

Personally identifiable information (PII) about SAP CPQ users and customers can be exported after the requester's identity is verified.

Personally identifiable information is any information that could potentially be used to identify an individual such as their full name, home address, e-mail address, telephone number, and login details.

Certain information can be marked as Personally Identifiable Information to make the processes of managing and filtering PII easier.

The following SAP CPQ objects contain Personally Identifiable Information:

• User standard and custom fields
• Business Partner custom fields

The following objects aren't flagged as Personally Identifiable Information by default. There's an option to flag them, if necessary:

• Quote custom fields
• Quote item custom fields
• Attributes
• Custom tables
• Quote tables

Data can be flagged as PII by selecting the Contains Personally Identifiable Information checkbox for the above-mentioned objects. Changes made to all data categorized as PII are logged in a dedicated personal data log, which enables data protection officers to filter and monitor changes.

Some personally identifiable information requires more protection than others, such as social security numbers and drivers licence numbers. Administrators can prevent logging of old and new values for these objects in the audit trail by enabling the Suppress Information Logging toggle switch next to the object in question.

Certificates provide a more secure communication between two systems than password protection. Certificates provide complex encryption capabilities intended for a particular recipient. Certificates can also be used for authentication of system users in external systems, which is useful in integration scenarios. These features are used for establishing efficient and secure API communication between two different servers. WDLS Management gives administrators the ability to upload and store WSDL files for interpreting secured SOAP messages sent from third-party Web services to SAP CPQ. WSDL files are used for describing a SOAP-based Web service and creating a link between two distinct servers. WSDL files added to SAP CPQ need to be connected to a URL of the Web service endpoint.

Not all administrators require access to every setup section in CPQ. Access rights of administrators need to be managed to allow access to specific sections and entities that are relevant to their work. Administrators can be provided with complete access or read-only access to specific sections. Access rights for sections and entities are managed in the Setup Sections and Setup Section Entities menus. Administrators can also manage access rights for user-side elements, such as the Formula Debugger, Developer Console, and Script Workbench.

Access rights can be assigned to individual administrators or to permission groups to which the administrators belong. For example, consider an administrator who belongs to the permission groups Sales and Sales Manager. If the right to access the fields, calculations, and layout sections of the Setup is assigned to either of the administrator's permission groups, the administrator is automatically able to access the sections. However, if the permission group Sales Manager has full access to these sections, but the permission group Sales has read-only access to that section. However, if the permission group Sales Manager has full access to these sections, but the permission group Sales has read-only access to that section administrator will have full access to the section.

E-mail also has security protocols. The Domain Key Identified Mail (DKIM) authentication standard adds an encrypted digital signature to outbound e-mail messages sent on company's behalf. As a result, e-mail recipients with implemented DKIM on their side are reassured that the messages come from SAP CPQ and haven't been modified.

SAP CPQ uses its own e-mail servers that are configured per environment. DKIM keys are configured per a tenant. Each tenant in the environment needs to be configured separately.

The following conditions determine whether an e-mail message has a DKIM signature:

• If the sender's email is defined in Setup → Application Parameters → General Parameters → Sender Email Address and the DKIM signature has been set up for the sender's email domain, the email is signed with the DKIM signature set for the sender's email domain.
• If neither the sender nor the From (user) email domain match any available DKIM settings, the email is not signed.

Activating the DKIM Key and Updating the DNS:

The newly created DKIM key is inactive by default. Activate the DKIM key by enabling the toggle switch in the Active column. However, before activating the DKIM key, you need to add the public key to the DNS record.

When adding the public key to the DNS, use the following format of the name of the TXT record: selector._domainkey.domain.com. The value in the TXT record is the following format: v=DKIM1; k=rsa; p=MIIBIjANBgkqhki. The value after p= is the public key.

To add another layer of security in SAP CPQ and prevent unwanted breaches, define secure sources of JavaScript files, CSS sheets, images, and others.

By defining which sources are secure, content from unsecure URLs is restricted, providing one more level of protection for files coming from outside SAP CPQ.

There's a set of application parameters in Application Parameters Security in which secure sources need to be defined:

• Permitted sources for JavaScript: add URLs to secure sources from which JavaScript files can be used in SAP CPQ.
• Permitted sources for stylesheets or CSS: add URLs to secure sources from which stylesheets and CSS files can be used in SAP CPQ.
• Permitted sources for images: add URLs to secure sources from which images can be used in SAP CPQ.
• Permitted sources for font resources: add URLs to secure sources from which font resources can be used in SAP CPQ.
• Permitted sources that can be used as an HTML < form > action: add URLs to secure sources that can be used in SAP CPQ as an HTML <form> action.

The parameters are empty in all tenants created after the 2008 release. Only files from within SAP CPQ are considered secure.

Don't leave the parameters empty and don't add a * (asterisk) into additional security for the content in your tenant. Check your implementations, make a note of the sources from which you use JavaScript and CSS files, images, and fonts, and add those sources in the parameters separated by space.

The Credential Management page contains the credentials currently stored in the environment. When you store a credential entry, you can cite its name in the script sent to an external system to perform user authentication rather than using more complex authentication methods.

A single credential entry consists of a name, identifier, and a password or a client secret. Access to the Credential Management section can be restricted with the Access Rights feature, if needed.

The AuthorizedRestClient Scripting Helper can be used with a credential entry name to make basic authentication calls, or for requesting access tokens from external systems (currently, only OAuth2 and Client Credential grants are supported).

SAP CPQ supports server to server authentication using the OAuth 2.0 standard, offering different grant types to meet various authentication needs. To use Authorization Code Grant, JWT Assertion Grant, or SAML Assertion Grant, a Trusted Application must be configured in SAP CPQ.

On the Password Policy page, administrators can configure the rules governing user password creation within SAP CPQ. The password policy includes several fields:

• Minimum Length: Sets the minimum password length (default minimum is 8).
• Maximum Length: Sets the maximum password length (default maximum is 50).
• Number of Passwords in History to check: Specifies how many previous passwords are stored and cannot be reused (minimum: 5, maximum: 20).
• Password Creation Token Validity Period: Defines the token validity period (in hours) for password creation emails.
• Password Expiration in Days: Controls the number of days before the password expires.
• Password Expiration Warning Period: Defines the number of days before expiration when users will see a warning after login.
• Maximum Number of Login Attempts: Sets the maximum failed login attempts before the user is blocked.
• Include Lower Case: Requires at least one lowercase letter in the password.
• Include Upper Case: Requires at least one uppercase letter in the password.
• Include Number: Requires at least one number (0-9) in the password.
• Include Special Character: Requires at least one special character (for example: $, @, !, %, *, #, ?, &).
• Allow Temporary Password: Allows administrators to create temporary passwords for users. It's recommended to keep this setting as FALSE to avoid security risks.
• Allow Mail Notification on Password Change: Sends an email to users after their password is changed.

All configurations made on the Password Policy page is applied globally across SAP CPQ wherever password rules are enforced.