Considerations and Best Practices before enabling Salesforce Shield Platform Encryption

Best practices and things to consider before rolling out Shield Platform Encryption for your customer

Salesforce Shield Platform Encryption

Its been more than a year since launch of platform encryption solution by Salesforce named Shield. Even though its one of most costly offerings by Salesforce however momentum of adaption amongst financial and healthcare industry are very high. I have already implemented platform encryption for few of my clients within a year. In this post, I will share some of my learning and best practices around rolling out platform shield to customers.

First question to ask customer before going with Platform encryption is, “Which security threat customer trying to solve” ?

If answer is security from internal Salesforce users then unfortunately shield is not an answer. We can leverage OWD, sharing rules, profiles, FLS to set security for Salesforce internal users.

If answer from customer is – compliance, security at database and data center level then Shield is a way to go to solve security issue.

Comparing Shield with existing encryption solutions

There are many offerings on AppExchange to solve encryption problems. I have used couple of them either for POC or client. All of them introduces intermediate system mostly reverse proxy. Communication with Salesforce needs to happen with custom URL provided by vendor. All integrations, data loading etc needs to tunnel through those servers.

Advantages of encryption solutions from AppExchange
  • Cost effective
  • Complete control over encryption key life cycle management
  • Server can be established within company infrastructure meeting security requirements
Downside of AppExchange solutions
  • Introducing intermediate system between end user and Salesforce can cause possible network issues and slow performace
  • In existing Salesforce implementation, all integrations needs to re-modify to point new URL provided by vendor
  • As data is encrypted at Rest and decrypted during transmission, getting away from vendor is painful. In future, lets say if we decide not to encrypt data, we need to get decrypted data in files and load it again in Salesforce in decrypted format.

Three products included in Shield

  • Encryption
  • Field Audit
  • Event Monitoring

Considerations and Best practices of Shield Platform Encryption

  • Picklist, Multipicklist, Number, Percent, Geolocation and Currency data types not yet supported
  • Classic encrypted fields and Shield platform encrypted fields uses different technology under hood. Read more in detail here.
  • Some standard objects like Lead, Activities not supported yet. There are many ideas around this to vote on.
  • Process builder and Flows are not yet supported, however these are on roadmap and I can assure you Shield product team is working day and night ti bring as much as features possible
  • Shield is FedRamp approved
  • Encrypted fields cannot be referred in formula fields
  • Data will be encrypted after shield is enabled in Org. For existing data, we need to create a case in Salesforce to run background job for existing records so that those can be encrypted. Other solution is to update existing data using API or Dataloader.
  • If you are planning to use AppExchange or in case of existing Salesforce instance, make sure to talk to vendor and confirm if they are shield ready. Not many Appexchange products are shield compatible.
  • We cannot use encrypted field in where clause of SOQL in Apex
  • Encrypted fields cannot be referred in report and List view filter criteria
  • Make sure not to grant login access to anyone if use has view encrypted data permission. This is more of end user training issue. Even for Salesforce support, instead of giving them login access, share your screen.
  • Make sure even System administrators does not has Manage Encryption Key permission. If Salesforce instance has many System admins and someone accidentally deleted existing tenant secret then there is no way to go back and decipher data.
  • Come up with process and very few user acting as Security Admin. This user will have permission to play with tenant secrets.
  • Right now, there is no approval process on deletion of tenant secret however it wouldn’t hurt to create an Idea and spread words to vote on it
  • Technically we can generate tenant secret every 24 hours on production and 4 hours in Sandbox. As per best practices, when we generate new tenant secret, create a Salesforce ticket to encrypt all existing data with new tenant secret. Its not necessary but important for performance. Imagine , you are running report and records returned by report needs to be decrypted using 10+ tenant secrets.
  • If legacy portal is enabled in your Salesforce instance then standard fields cannot be encrypted. Communities however are supported.
  • Encryption not extended to other clouds like Pardot, Marketing cloud, SalesforceIQ, Heroku and Thunder.
  • Trial orgs are not supported for encryption.
  • KMIP not yet supported.
  • Trailhead modules to get your hands dirty with product
  • Read in more detail from Shield platform encryption implementation guide

 

Related posts

Leave a Reply

Your email address will not be published. Required fields are marked *