Introduction
In this topic, I will talk about Salesforce Shield – primarily focusing on the Platform Encryption module. I will talk about the details and limitations, competing architectures and will touch upon Event Monitoring.
Up front, I’d like to make a disclaimer that Shield is regularly being updated by Salesforce. Do look at the latest documentation provided by Salesforce before proceeding with a purchasing or architecture decision. This article is meant to provide some color on implementation considerations with an unbiased look at pros and cons of using Shield for Encryption.
Why does this matter?
As transactions and data exchange happen electronically, there is an increased concern about securing data stored in both Cloud as well as On-Prem systems. With a large number of high profile instances where companies have lost customer data, people are increasing asking questions like – Who has my Data? Who are they sharing my data with? What exactly is being stored? How can I make sure that the data I share is being protected?
Increasingly – governments around the world are strengthening customer rights and laws like GDPR and the upcoming California Consumer Protection Act(CCPA), (scheduled to be in force starting January, 2020) are being brought in to ensure that companies protect data and ensure transparency to the consumer. Regardless of these laws, companies do have a fundamental ethical responsibility to secure data entrusted to them.
How does Encryption fit in?
Encryption is one way to help secure the data. Ideally, one would want to encrypt the data at rest in every system it is stored and ensure it is also encrypted in transit between systems. Up front I would like to point out that;
Simply implementing encryption is not enough. Encryption needs to work in concert with strong controls on system access, a monitoring system, a robust system of maintaining and rotating keys and an independent audit process to ensure that rules are being followed . Common sense also plays a role here – having a strong password is meaningless if your admin writes it down on a post-it and puts it on his/her monitor for easy access.
Encryption ensures that if someone gets access to your system or if there is a data breach, the unauthorized person will not be able to view your data.
What is Shield?
Shield currently consists of 3 modules:
Platform Encryption – which handles Encryption at Rest. Unlike Classic Encryption – which can only be applied to a custom text field – Platform encryption can encrypt a vastly larger set of data and can also encrypt files stored on Salesforce. However – and this is an important distinction – it does NOT provide any kind of UI masking. Also, accessing the data via an API will return the data UNENCRYPTED. This is by design.
Event Monitoring – which gives very detailed logging of the application including a very granular record of things like record access, api calls, login history, report access etc. This would allow detailed logging on who exactly is accessing your data.
Field Audit Trail- Increases the amount of field history you can track and increases the duration to which you can store the history of changes.
Limitations of Shield
Shield plays an important role in securing organizational data. However, as mentioned before, it does not provide any UI level masking. Generally, the assumption is that data access will be controlled via Field level security. Some requirements require UI level masking e.g. hiding of SSN numbers or credit card numbers or hiding of PII data to satisfy regulation. For these, Platform Encryption needs to be complemented with some kind of other solution. (e.g. a custom masking algorithm.)
Data accessed via the API is also not encrypted so any calls into the application via the API would have access to the underlying data and would need to be secured. (Note, however, all calls to the Salesforce APIs need to have TLS encryption so there will be some amount of encryption in transit BETWEEN the calling system and Salesforce. Once the data reaches the calling system, however, all bets are off and you need to work out a way to secure the data in that system )
Implementation Considerations
Effect on Code and Configuration
I would advice referring to the latest documentation from Salesforce on Field level limitations as the guidelines do change over time – https://help.salesforce.com/articleView?id=security_pe_considerations_general.htm&type=5. In general, when encrypting a field, be careful on how the field is used in code, search criteria and formula fields and also be aware of implications to 3rd party applications. Thorough testing in a Sandbox is essential.
Key Rotation and securing your Key
You have a couple of options in generating an encryption key – you can either Bring your Own Key (BYOK) or have Salesforce generate one. Access to the tenant secret and management of the secret is controlled via permissions and can be strengthened using 2 factor authentication.
A couple of notes;
- If you accidentally destroy a tenant secret, Salesforce has no way to get it back so it is important to have a secure location to store the secret.
- Keys should be rotated frequently.
Sandboxes
Refreshing a Sandbox copies the tenant secret down to the Sandbox. The best practice is to immediately rotate the keys on sandbox creation to ensure no unauthorized access
Alternatives to Shield Platform Encryption
If the limitations of Shield Platform Encryption are not acceptable, there are a number of third party applications which offer alternatives. A viable alternative is the CASB based architecture provided by products like CipherCloud. These work by acting as a go between between third parties and Saleforce ensuring that data is encrypted prior to storage in Salesforce.
Final Thoughts
Before closing, I would like repeat my disclaimer that Shield is regularly being updated by Salesforce. Do look at the latest documentation provided by Salesforce before proceeding with a purchasing or architecture decision.
Implementing any Encryption solution is not a one and done deal and requires some thought on behavior and an evaluation of threat and what the organizational needs are. I hope this article helps inform your decision.