Encrypt Data through Platform Encryption

If you have worked on projects subject to regulatory compliance requirements, you would understand how important is the security (and tracking) aspects of the application.

It is typical of those implementations to ensure data security through standard encryption mechanisms. For e.g. Personal Identifiable Information and Personal Health Information are typically encrypted and stored.

The encryption is transparent to the authorized user viewing data through the application. The application provides the right data access and ensures tracking of data operations - thereby completing the entire circle of right access with the right traceability of user actions on sensitive data.

Salesforce has provided encrypted text fields for sometime now.  Just hit “new field” for any object and you will see this option.

You will be fine using these fields for your encryption needs. But, unfortunately that does not address all your needs -

• Only specific fields are encrypted. These have to be of “Text” data type and cannot exceed 175 characters
• Search on encrypted fields is not supported. If you are required to encrypt email addresses and make it searchable, you will not appreciate this
• There are limitations on how you can use these fields in workflows

Either you used Salesforce application with these limitations, raised an exception with your compliance team and hope for the best, or just move away from SFDC for the time being.

Not anymore. Platform encryption is here (at least if “here” = “EU”).

What is Platform Encryption? #

Platform encryption brings better encryption capabilities for your org. It enables you to encrypt stored data (“at rest”) using 256-bit AES algorithm. You define and manage the keys and encrypt any data in salesforce application (see considerations below before you go crazy). The encryption works at the hardware level and is transparent to the user.

Use cases for platform encryption may include the previously defined scenarios requiring regulatory compliance and any contractual obligations that require sensitive data storage to be encrypted.

Enable Platform Encryption by navigating to Security Controls | Platform Encryption.

You can encrypt -

• “Select” standard fields
• Custom fields
• Files and attachments

You can encrypt following field types - Text, Text Area (Long), Phone, Email and URL.

Don’t see the option to enable encryption? Either switch to EU servers (select the country in EU), or create a new DE! Specify a tenant key using “Create Tenant Secret” magic button. This will generate a key that is used along with the master key for encrypting data.

You can choose to enable the encryption for specific standard fields (not a whole lot in there - a dozen fields in Contact and Account). Or, you can enable encryption for custom fields by turning on a flag for the field.

Encryption happens using a master key controlled by salesforce and the tenant secret key that you have generated. You can change the tenant secret key anytime by recreating the tenant secret (“Generate New Tenant Secret”). This will -

• Start encrypting new data with the new key
• The older key is archived and is used to decrypt records created before the new key was activated
• All data will be re-encrypted with the new key on data changes

You can also destroy the tenant secret, but I could not find use cases for doing that - unless you are trying to cleanup temporary keys that are not used. Destroying keys will render any data encrypted using that key useless.

Considerations for Platform Encryption #

First and foremost  aspect to consider - only encrypt when needed.

After all said and done, encryption introduces additional layers to perform the encryption/decryption and this takes time (may be visible to your users) and processing power(invisible).

• You cannot change the field types once you encrypt a field!

• Values in encrypted fields are visible to users with “View Encrypted Data” permission. They are masked for all other users and you cannot control how many characters are masked and the mask characters

• Encrypted fields remain editable by default to users without the “view encrypted data” permission. You would have to take appropriate action to prevent that

• Encrypted fields are searchable and available to APIs. However, records cannot be sorted based on those fields
  

• Files and attachments are encrypted when enabled, but are viewable to all users regardless of “view encrypted data” permission. A status indicates “This field is encrypted” when viewing the file

• Encrypted fields come with their limitations. They cannot be used in following -

  • ‘where’ clause of SOQL queries
  • criteria-based sharing rules
  • Formula fields
  • Account and Contact Names cannot be encrypted when using Person Accounts
  • Standard fields cannot be encrypted if you are using (or proposed to use) Communities

It is absolutely important to test all your managed/unmanaged packages with the encrypted fields!

Working with Platform Encryption #

Here are a few things that will interest a typical developer -

• Changing tenant keys will use those keys for the new records. The older data will continue to exist with the previously used keys and would have to be re-encrypted so that all records use the same encryption key
• When you enable encryption on fields, the older values do not automatically get encrypted. You can mass encrypt records by triggering an update on those records
• You can use Change Sets to deploy platform encryption
• You need to rotate the “tenant secret” once you have a sandbox refreshed. Do not destroy the secret key unless you want to render the encrypted fields useless
• When migrating data across sandboxes, be aware that the encrypted key can be ignored or considered depending on the encryption configuration in the target environment
• Managed/unmanaged packages ignore encrypted field attribute in deployment

In Summary #

Platform encryption brings a good solution to enable organizations to encrypt sensitive data. But, this is no “flick of a switch”. Be careful about how you test the functionality, any changes to encrypted fields and keys, and have adequate backups to rely on in case of catastrophic failures.

Also see -

• Architecture for platform encryption
• Differences between the older (“classic”) encryption vs. platform encryption