Salesforce Security Guide

Clouds with binary code floating aboveCloud with binary code floating above

No Results

Search Tips:

  • Please consider misspellings
  • Try different search keywords
Salesforce Security Guide
Salesforce Security Basics
Authenticate Users
Give Users Access to Data
Share Objects and Fields
Strengthen Your Data’s Security with Shield Platform Encryption
What You Can Encrypt
Platform Encryption Q&A
How Encryption Works
Set Up Your Encryption Policy
Filter Encrypted Data with Deterministic Encryption
Key Management and Rotation
Work with Salesforce Key Material
Get Statistics About Your Encryption Coverage
Synchronize Your Data Encryption
Work with External Key Material
Bring Your Own Key (BYOK)
External Key Management
How Salesforce Shield EKM Works
EKM Prerequisites
Key Coordination Policy Setup
EKM Considerations
Connect Salesforce to AWS KMS and Create a Data Encryption Key
Key Maintenance and Auditing for EKM
EKM in a Sandbox Org
Cache-Only Key Service
Configure Your Cache-Only Key Callout Connection
Shield Platform Encryption Customizations
Encryption Trade-Offs
Audit and Monitor Your Organization’s Security
Real-Time Event Monitoring
Security Guidelines for Apex and Visualforce Development
API End-of-Life Policy
PDF

How Salesforce Shield EKM Works

For EKM, Shield Platform Encryption relies on the customer’s external KMS to generate and secure the data encryption keys (DEKs) used by the Shield Platform encryption service. These DEKs reside with the Shield Platform encrypted key cache in a wrapped state. When encryption or decryption operations are needed, the Shield Platform service passes the wrapped DEK to the customer’s external key service to be unwrapped. The customer key service unwraps the DEK and sends it securely back to the Shield Platform encryption service.
Available in both Lightning Experience and Salesforce Classic (not available in all orgs).
Available in: Enterprise, Performance, Unlimited, and Developer Editions. Requires purchasing Salesforce Shield or Shield Platform Encryption, and either the EKM Service or the Cache-Only Key Service.

User Permissions Needed
To generate, destroy, export, import, upload, and configure Shield Platform Encryption key material: Manage Encryption Keys

The process begins when you create a root key in the customer KMS. You create a policy which gives Salesforce’s regional KMS some important permissions.

  • Permission to request the customer key service to generate and wrap a DEK by using the root key
  • Permission to request the customer key service to unwrap the DEK by using the customer root key

You use this policy to create an EKM DEK in Setup. Then the Shield Platform encryption service requests the customer KMS to generate a DEK by using the root key. The customer KMS creates a DEK, wraps it, and sends it to the Shield Platform encryption service over a secure channel. This is the only copy of the DEK that exists. Shield Platform Encryption stores the DEK, still wrapped by the root key, in the TenantSecret database. Here’s the process, step by step:

  1. The customer KMS admin creates a root key.
  2. The Salesforce admin creates a key policy and copies it to the customer KMS.
  3. With the policy in place, the Salesforce encryption service requests a DEK for local storage.
  4. The customer KMS uses the root key to create and wrap the new DEK, which it sends back via a secure channel.
  5. The encryption service stores the wrapped DEK in the TenantSecret table.
Corresponding diagram of information

When the Shield Platform encryption service detects encryption operations that require the EKM DEK, it checks its encrypted key cache for it. If the unwrapped DEK isn’t present in the cache, the Shield Platform encryption service requests that the key service unwrap the DEK. The key service unwraps the DEK and sends it back to the Shield Platform encryption service over a secure channel (TLS(Awskms-SFKMS)/mTls). Then the Shield Platform encryption service adds the unwrapped key to the encrypted key cache.

  1. A user accesses or saves encrypted data.
  2. The Shield Platform encryption service gets the DEK from the TenantSecret table.
  3. The encryption service sends the wrapped key to the customer KMS over a secure channel to be unwrapped.
  4. The customer KMS uses the root key to unwrap the DEK and sends it back to the encryption service.
  5. The encryption service stores the unwrapped key in the encrypted key cache for immediate use.
Corresponding diagram of information

If the unwrapped DEK is present in the cache, the Shield Platform encryption service uses it for encryption and decryption of customer data.

Because EKM DEKs bypass the key-derivation process, they’re used to directly encrypt and decrypt your data.

As a core offering of the Shield KMS, enhanced cache controls ensure that key material is stored securely while in the cache. The Shield KMS encrypts the fetched key material with an org-specific AES 256-bit cache encryption key and stores the encrypted key material in the cache for encrypt and decrypt operations. HSM-protected keys secure the cache encryption key in the cache, and the cache encryption key is rotated along with key lifecycle events such as key destruction and rotation.

The enhanced cache controls provide a single source of truth for key material that’s used to encrypt and decrypt your data. Subsequent encryption and decryption requests go through the encrypted key cache. They are unwrapped by the customer KMS until the DEK is revoked or rotated or when the cache is flushed. After the cache is flushed, the EKM service again fetches the DEK from your specified key service. The cache is flushed regularly every 72 hours. Certain Salesforce operations flush the cache, on average, every 24 hours. Destroying a DEK invalidates the corresponding DEK that’s stored in the cache.