Platform Encryption with Salesforce

Introduction  

In this blog, I am going to explain the platform encryption and its architecture. It is common practice today to encrypt data Prevent from the unauthorized access. Salesforce Platform encryption are allowed to today to encrypt data at rest, that is, data stored on servers with the Salesforce platform encryption.  Data stored in many standard and custom fields and in files and attachments are encrypted using an advanced HSM-based key derivation system, so it is protected even when other lines of defense have been compromised.Your data encryption key is never saved or shared across organizations. Instead, it is derived on demand from a master secret and your organization-specific tenant secret, and cached on an application server.

Benefits of Encrypting Data at Rest

First and foremost, encrypting data at rest protects the organization from the physical theft of the file system storage devices (which is why end-user mobile devices from laptops to cell phones should always be encrypted). While this might sound unlikely, the physical disk devices are only as secure as the data center where they are located. Encrypting data at rest can protect the organization from unauthorized access to data when computer hardware is sent for repair or discarded.

What can you encrypt?

Salesforce platform Encryption allows you to encrypt fields, files, and attachments and Custom field as shown in this image.

Which User Permissions Does Shield Platform Encryption Require?

Assign permissions to your users according to their roles regarding encryption. Some users need the “View Encrypted Data” permission, while some need other combinations of permissions to select data for encryption or work with encryption keys. You can enable these permissions just like you would any other user permission.

How Platform Encryption Works

Shield Platform Encryption relies on a unique tenant secret that you control and a master secret that’s maintained by Salesforce. We combine these secrets to create your unique data encryption key. We use that key to encrypt data that your users put into Salesforce and to decrypt data when your authorized users need it. Encrypting files, fields, and attachments has no effect on your organization’s storage limits.

When users submit data, the application server looks for the org-specific data encryption key in its cache. If it isn’t there, the application server gets the encrypted tenant secret from the database and asks the key derivation server to derive the key. The encryption service that encrypts the data on the application server.

Take the time to identify the most likely threats to your organization. This will help you distinguish data that needs encryption from data that doesn’t so that you can encrypt only what you need to. Make sure your tenant secret and keys are backed up, and be careful who you allow managing your secrets and keys.

Before data is encrypted, a Salesforce administrator must enable encryption and generate a tenant secret. For each field, file, and attachment on which encryption is enabled, the corresponding metadata in the UDD is updated to reflect the new encryption setting. Users must have the “View Encrypted Data” permission to view encrypted field data.

  1. When a Salesforce user saves encrypted data, the runtime engine determines from metadata whether the field, file, or attachment should be encrypted before storing it in the database.
  2. If so, the encryption service checks for the matching data encryption key in cached memory.
  3. The encryption service determines if the key exists. a. If so, the encryption service retrieves the key. b. Otherwise, the service sends a derivation request to a key derivation server and returns it to the encryption service running on the App Cloud.
  4. After retrieving or deriving the key, the encryption service generates a random initialization vector (IV) and encrypts the data using JCE’s AES-256 implementation.
  5. The ciphertext is saved in the database or file storage. The IV and corresponding ID of the tenant secret used to derive the data encryption key are saved in the database.