Shield Platform Encryption

While studying for the Integration Architect exam, I looked into different aspects of securing an integration. One particular element I wanted to explore deeper was the Shield Platform Encryption.

A Shield Platform Encryption Overview

Shield Platform can encrypt files and attachments stored in Salesforce, search indexes, standard and custom fields – but not all. This encryption mostly works in the Salesforce user interface, APIs, and business processes. Shield Platform Encryption provides a layer of security while preserving critical platform functionality. Data is encrypted at rest as well as when transmitted over a network. 

The process of data encryption used is to apply a cryptographic function to unencrypted data that results in a ciphertext. Cryptography is the science of secret writing (as ancient as writing – think Hieroglyphs). 

Courtesy of Gary Kessler’s website: www.garykessler.net:

Shield Platform Encryption uses symmetric key encryption which uses a single key for encryption and decryption. It is “a 256-bit Advanced Encryption Standard (AES) algorithm using CBC mode, and a randomized 128-bit initialization vector to encrypt data stored on the Salesforce Platform. Both data encryption and decryption occur on the application servers.” (quote from Salesforce Shield Platform Encryption Implementation Guide). It is deterministic encryption as the same ciphertext is used. The data is encrypted at rest – AKA those fields that are stored in the database, in files, contents, and libraries, etc.

An example of the types of standard fields that Shield Platform Encryption can encrypt are (from Accounts), the Account Name, Account Site, Address fields (on both ordinary Accounts and Person Accounts), Phone fields, Email, Website or Fax fields. Note that standard fields that Shield Platform Encryption does encrypt include specific standard fields in CPQ, Health Cloud, Financial Services Cloud, Sales Cloud, Service Cloud, and Workplace Command Center. The main takeaway from this is that some but not all fields can be encrypted.

Note when the Account Name or Contact Name fields are encrypted, searching for duplicate accounts or contacts to merge does not return any results.

The following types of custom fields can be encrypted:

• Date and Date/Time
• Email
• Phone
• Text (Text, Text Area, Long Text and Rich Text)
• URL

The following custom field types cannot be encrypted:

• External Data Object fields
• Account Contact Relation fields
• Data translation enabled fields 
• Rich Text Area fields on Knowledge Articles.

Currency and number fields are not encrypted as if they were encrypted they would cause disruption to reports. It is recommended to keep data of this type encrypted in other supported field types (eg text).

When a Name field is encrypted a one-way change occurs – enhanced lookups are enabled. This changes the way the lookup works by only searching through records that have been enhanced recently. If you want to return to standard lookups – and have the ability to search all existing records – it is not possible – even if the encryption is disabled.

Interestingly, an encrypted field cannot be created using Schema Builder. I suspect that it is also the case with the tool to create a custom object from a spreadsheet. I have not found the answer to that at this point.

When creating a custom field, there is a check box for Encrypted. Tick it to encrypt the contents of that field. Once encrypted, this field will not be available for use in criteria-based sharing rules.

An email confirming the change is sent:

Note see Probabilistic vs Deterministic encryption below.

Before selecting which fields to encrypt it is best practice to define a threat model for the Salesforce Org and use the results from the threat model exercise to inform decisions about what data to encrypt. Not all data is sensitive. Encrypting data can impact functionality and performance. The rule of thumb should be, where data is necessary for compliance, privacy, regulatory or security then that data should be classified as requiring encryption. 

However, where out-of-the-box security tools can be used such as field-level security, profiles, page layouts, and sharing rules – use these over encryption where it is possible.

Steps to carry out prior to encryption include testing in a sandbox rather than production (encryption policy settings can be deployed in Change Sets). Test both the current org configuration as well as any third-party apps that you have or intend to add to your Salesforce org. Also, check any violations that may be uncovered. Violations can occur when code (particularly SOQL queries) reference encrypted fields.

To encrypt custom fields in a managed package, go to Platform Encryption / Advanced Settings and enable Encrypt Custom Fields in Managed Packages.

It is also possible from Platform Encryption / Advanced Settings to enable the encryption of field history and feed tracking values during synchronisation by turning on Encrypt Field History and Feed Tracking Values.

The following types of files are encrypted with file encryption (note that this list is not exhaustive and as Salesforce develops, is subject to change):

• Files attached to emails, feeds and records. As well as files attached to Chatter posts, and Chatter Comments
• Images in Rich Text fields
• Files managed with Salesforce Files Sync, and files on the Content, files and Libraries tabs.
• Knowledge article fields
• Quote PDFs
• Notes body text (in the new Notes tool)
• Files

Files that cannot be encrypted include:

• Documents
• Chatter group and profile photos
• Notes in the old Notes tool
• Note Previews for both old and new notes.

There are some key considerations to take into account when encrypting fields and they are listed in this Salesforce Article. A few I found interesting to highlight are here around emails:

• Pardot supports email addresses that have been encrypted provided the Pardot instance allows multiple prospects with the same email address (AMPSEA). However, if in the connector settings, the “If records don’t have a CRM ID to match when syncing, use email address to match” setting is enabled and Shield Platform Encryption is used to encrypt the Lead or Contact email field, the Pardot sync stops working.
• Email Bounce Handling does not support encrypted email addresses. If this is required, do not encrypt the standard field – manage with field level security or similar.
• Although Web to Case is supported, the Web fields (Company, Email, Name and Phone) are not encrypted at rest.

Ensure that only those who need to manage Encryption Keys do. Create a permission set with ‘Customise Application and Manage Encryption Keys’, and strictly manage the assignment of the permission set. Key Management activities are logged in the setup audit trail. It is possible to use this permission set to assist with locking down Encryption Policy Setting management. This can be done in Platform Encryption / Advanced Settings. Turn on Restrict Access to Encryption Policy Settings:

The Permission Set will enable the full Platform Encryption menu to be available:

On the subject of permissions, ensure that only those who need login as another user should have that ability. If someone logs in as a user who can view the encrypted fields data – they will be able to use it. Note, this includes enabling Salesforce Customer Support to have access to your org. 

Once Shield Platform Encryption has been enabled and a Tenant Secret Key has been created (from Key Management), fields can be selected for encryption from the Encryption Policy under Platform Encryption in Setup. 

The Tenant Secret, or Key, can be generated from Key Management by either clicking on Generate Tenant Secret, or Bring Your Own Key (to use your own key). An option in Platform Encryption/ Advanced Settings, lets you disable Salesforce’s key derivation process and allows you to use uploaded keys as the final data encryption key. It is called “Allow BYOK to Opt-Out of Key Derivation”.

Note, you can only have up to 50 active and archived tenant secrets if each type (Salesforce or Customer-generated). This does mean that if you need to create a new tenant secret but the limit has been reached, an existing key needs to be destroyed. If it is, ensure any data that would have used that key is encrypted with an active key. 

There are three Tenant Secret Types: 

• Data in Salesforce
• Event Bus
• Search Index

Data is not automatically encrypted when Shield Platform Encryption is turned on. An update needs to be performed on the records that hold the fields you wish to encrypt. File data however is encrypted by a background encryption process. In order to encrypt existing files, raise a case with Salesforce. Where a key is changed and data is already encrypted with a previous key, the data will be encrypted with the new tenant secret. Raise a case with Salesforce for help with the re-encryption of data.

Unless the option to encrypt change data capture events and platform events is ticked under Platform Events / Encryption Policy, Change Data Capture and Platform Events are not encrypted and remain plain text. 

The Encryption Policy identifies what will be encrypted:

Clicking on Encrypt Field Link will take you to the Encrypt Standard Fields feature:

Note: There are Tradeoffs / Limitations for enabling Platform Encryption. Read more here.

Further items in the Advanced Settings for Platform Encryption not covered in these notes so far follow: 

Deterministic Encryption

Above, when I enabled a custom field by ticking Encrypted for the field I received an email notifying me that the field was using probabilistic encryption. So what is 1) probabilistic encryption and 2) Deterministic Encryption and why do we have this setting in Advanced Settings.

1. Probabilistic Encryption (in Salesforce symmetric key encryption context only):
   This is the default shield encryption for Salesforce. When encrypting the same message or text several times, it will generally yield different ciphertexts. There is an element of randomness in the encryption algorithm. Therefore it is not possible to filter on the data in this field as it has become random and patternless strings. Encryption does not impact users who are authorised to view the data.
   
2. Deterministic Encryption (again in Salesforce symmetric key encryption as my context):
   To be able to use filters with encrypted fields there needs to be some patterns in the data. In deterministic encryption there is a static Initialisation Vector (IV) which means that encrypted data can be matched to a particular field value. Each IV is unique for a particular field in that org and can only be decrypted with the same org’s encryption key. Although a system cannot read the encrypted data, it can know how to retrieve the cyphertext for that specific data because of that static IV. It is a field by field cyphertext, so if a hacker was to determine one cyphertext for a field – they would have to seek a different one for each remaining encrypted field.

Key sources for Deterministic vs Probabilistic Encryption is from the RevCult blog and Salesforce Security Guide.

Enabling deterministic encryption in Platform Encryption / Advanced Settings enables a further Tenant Secret Type in Key Management: Data in Salesforce (Deterministic). A further key (different from the other Tenant Secret Types) can be created. It is possible to mix and match the two different types of encryption. 

When encrypting fields, there is the option to choose between: probabilistic, deterministic (case-sensitive), and deterministic (case-insensitive). This can be done through the Encryption Policies:

Or at field level:

Encrypting a field can take some time with deterministic encryption when there is already a large number of records for that object as the enablement of the encryption also processes field indexes.

Cache-Only options in Advanced Settings:

In Advanced Settings there are two Cache-only options:

• Allow Cache-Only Keys with BYOK (store encryption keys at an endpoint we provide)
• Enable Replay Detection for Cache-Only Keys (protects from replay attacks using a nonce embedded in a callout. A nonce is a word or phrase that can only be used once.)

Shield Platform Encryption has a cache-only key service. This cache-only key service allows for different ways to generate, store and secure key material. So a cloud-based key service or an on-premises key service can equally be used. The flow to fetch the keys on demand is the same regardless of which service is being used. When someone accesses or adds to encrypted data, the cache-only key service calls out to the key service. The key material is returned wrapped in JSON web encryption format through a secure authenticated channel. The authentication uses Mutual TLS, OAuth, or Basic Authentication. This is high level, and more about cache-only key services can be found here in the Salesforce Security Guide.

Encryption Statistics

Once everything is set up, Encryption Statistics provides an overview of the data encrypted with Shield Platform Encryption and how much with an active key material. This is useful for collecting information about objects and fields and for key maintenance tasks (such as rotation actions). The Object will be shown with a percentage of how much data is encrypted, the percentage for how many use the active key, and a Yes / No or whether a Synchronisation is needed. There is a button called Gather Statistics – once pressed it goes and fetches the latest information about encryption in your org.

Credit for Title Card image goes to Wkicommons: https://commons.wikimedia.org/wiki/File:Egypte_louvre_225_hieroglyphes.jpg