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
Terminology
Components Involved in Deriving Keys
Classic vs Platform Encryption
Key Material Storage
Shield Encryption Flow
Search Index Encryption Flow
Sandbox
Why BYOK?
Masked Data
Hyperforce
Deployment
Set Up Your Encryption Policy
Filter Encrypted Data with Deterministic Encryption
Key Management and Rotation
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

Behind the Scenes: The Search Index Encryption Process

The Salesforce search engine is built on the open-source enterprise search platform software Apache Solr. The search index, which stores tokens of record data with links back to the original records stored in the database, is housed within Solr. Partitions divide the search index into segments so that Salesforce can scale operations. Apache Lucene is used for its core library.
Available in both Lightning Experience and Salesforce Classic (not available in all orgs).
Available as an add-on subscription in: Enterprise, Performance, and Unlimited Editions. Requires purchasing Salesforce Shield. Available in Developer Edition at no charge.

Using Shield Platform Encryption’s HSM-based key derivation architecture, metadata, and configurations, search index encryption runs when Shield Platform Encryption is in use. The solution applies strong encryption on an org-specific search index (.fdt, .tim, and .tip file types) using an org-specific AES-256 bit encryption key. The search index is encrypted at the search index segment level, and all search index operations require index blocks to be encrypted in memory.

The only way to access the search index or the key cache is through programmatic APIs.

For orgs that use the updated search index framework, search index encryption starts after an admin turns on the option on the Encryption Settings page in Setup. Salesforce creates a root key and DEK. As soon as the DEK is active, search index encryption starts. The admin can turn off search index encryption, generate a new root key, or generate a new DEK. There’s no need to configure an encryption policy, because all indexes for all fields are encrypted.

In orgs that don't yet use the updated search index framework, a Salesforce security administrator can turn on Search Index Encryption from Setup. The administrator first creates a tenant secret of the Search Index type, then they turn on Encryption for Search Indexes. The admin configures their encryption policy by selecting fields and files to encrypt. An org-specific HSM-derived key is derived from the tenant secret on demand. The key material is passed to the search engine’s cache on a secure channel.

If Salesforce admins disable encryption on a field, all index segments that were encrypted are unencrypted and the key ID is set to null. This process can take up to seven days.

Note

Process when a user creates or edits records

  1. The core application determines whether the search index segment should be encrypted, based on metadata.
  2. If the search index segment requires encryption, the encryption service checks for the matching search encryption key ID in the cached memory.
  3. The encryption service determines whether the key exists in the cache.
    • If the key exists in the cache, the encryption service uses the key for encryption.
    • If the key doesn’t exist in the cache, the service sends a request to the core application, which in turn sends an authenticated derivation request to a key derivation server. The key derivation server then returns the key to the core application server.
  4. After retrieving the key, the encryption service generates a random initialization vector (IV) and encrypts the data using NSS or JCE’s AES-256 implementation.
  5. The key ID (identifier of the key being used to encrypt the index segment) and IV are saved in the search index.

Process when a user searches for encrypted data

  1. When a user searches for a term, the term is passed to the search index, along with which Salesforce objects to search.
  2. When the search index executes the search, the encryption service opens the relevant segment of the search index in memory and reads the key ID and IV.
  3. Steps 3 through 5 of the process when a user creates or edits records are repeated.
  4. The search index processes the search and returns the results to the user.