Salesforce Encryption Principles

To balance security demands with customers’ functional requirements, Salesforce defined a set of principles that drove our solution design and architecture decisions. We focused on the problems that we wanted to solve, clearly defined the boundaries of our solution, and identified the implications and tradeoffs of the design.

Encrypt data at rest

The Salesforce Shield Platform Encryption solution encrypts data at rest when stored on our servers, in the database, in search index files, and in the file system. To encrypt data at rest and preserve functionality, we built the encryption services natively into the Salesforce Platform.

Natively integrate encryption at rest with key Salesforce features

One of the things that makes the Lightning Platform so remarkable is that it’s driven by metadata. Shield Platform Encryption uses that metadata to tell the other platform features which data is encrypted. This way, we can prevent those features from inadvertently exposing plaintext or ciphertext. And we can ensure that critical business functionality, like partial search, continues to work even when data is encrypted.

Note If your org is running on Hyperforce, Salesforce can apply Database Encryption to the transactional database.

Use strong, flexible encryption

The Shield Platform Encryption solution provides two features that approach data encryption in different ways: application tier encryption (such as with Field-Level Encryption, FLE) and data tier encryption (such as with Database Encryption).

• The Shield Platform Encryption FLE encryption-at-rest solution runs on the application tier. It uses strong, probabilistic encryption by default. FLE uses the Advanced Encryption Standard (AES) with 256-bit keys by using Cipher Block Chaining (CBC) mode and a random initialization vector (IV). This type of encryption results in a loss of some functionality, such as filtering operations.

  However, we recognize that in some cases, business requirements depend on preserving more functionality, which can influence what data customers decide to encrypt. In those cases, we offer deterministic encryption for FLE. Deterministic encryption also uses AES 256-bit CBC keys, but it uses a field-specific static IV. Because the ciphertext for each field includes bits that associate it with a specific field, customer queries return encrypted values in that field. In this way, deterministic encryption only decreases encryption strength as much as is necessary to allow filtering.

• The Database Encryption encryption-at-rest solution runs on the transactional data tier, so all encryption operations occur within the database. It stores your tenant data as immutable tenant-specific fragments. Each fragment is encrypted using its own unique DEK. The DEK for each fragment is derived using a HKDF function taking in the Salesforce Database Tenant Secret based seed key that you manage as one of the inputs alongside fragment and tenant specific metadata. This ensures a robust encryption solution using AES GCM across all your org's data in the Transactional Database. Application persisted data is encrypted at the Database layer on its way from the Database's memory layer into persistence. Decryption happens similarly on the way out from persistence into the DB's memory layer. As a result, your data that is protected using Database Encryption is amenable to sorting and filtering operations and other limitations that come with Field Level Encryption.

Let customers drive the key lifecycle

We built a key management framework that scales to our multitenant model and gives you complete control over the key management lifecycle. Because the encryption service is built natively into the Salesforce Platform, the encryption keys can reside in the Salesforce environment. Or, when accessible by the Salesforce Shield Key Management Service, keys can reside in an external key store. Adhering to the principle that customers must have complete control over the key lifecycle, we built key management functionality into the Setup UI and API. Customers decide when to generate, supply, rotate, import, export, and destroy keys. Customers also determine who performs these tasks. With Bring Your Own Keys (BYOK), you can generate and store key material outside of Salesforce using your own crypto libraries, enterprise key management systems, or hardware security modules. As with all administration tasks, everything is audited.

Note You can archive and destroy FLE key material. Database Encryption key material can be archived as part of key rotation. But you can’t destroy Database Encryption key material.

Protect keys from unauthorized access

A primary consideration when designing our key management infrastructure was making encryption keys available to the encryption service while preventing privileged Salesforce employees, such as DBAs, from inappropriately accessing them. This consideration led us to incorporate these key security concepts in Shield Platform Encryption.

• We use a hardware security module (HSM), a High Assurance Virtual Ceremony (HAVC), and the Salesforce Shield Key Management Service to generate and secure tenant cryptographic key material.
• The Salesforce Shield Key Management Service includes a primary Key Management Server (KMS), a Key Escrow Server. and secondary regional KMSs, which securely distribute key material as needed. Each regional KMS includes a key broker that securely controls the transfer of key material from the Key Escrow Server. For some Shield features, such as EKM, we work with both Salesforce-controlled and supported external KMS servers.
• Derived data encryption keys (DEKs) used to encrypt and decrypt customer data are never stored in plaintext. They’re derived from multiple key material components, including a per-release secret (KDF seed), a per-release initialization vector (KDF salt), and a tenant secret.
• A DEK separately generated for use with a root key is wrapped by that root key and stored in the database. Before the DEK can be used, it must be unwrapped by the same root key.
• DEKs supplied by the customer by way of EKM, BYOK, or Cache-Only Keys aren’t persisted. They are either stored within a regional Salesforce KMS, or fetched on demand.
• Key material components that are persisted outside of an encrypted key cache are always wrapped and hashed or signed using HSM-generated wrapping and signing keys.
• With FLE, for final encryption and decryption of data, an encrypted key cache temporarily stores the key material in use. All keys in the encrypted key cache are wrapped by a cache key encryption key, which is specific to each customer.

The result is a shared key management service that secures all key material at every stage. Keys, secrets, and key components are inaccessible to Salesforce employees and, by extension, to malicious external attackers.

Encrypt the optimal amount of data

Our design gives customers control over what data they encrypt. As the administrator, you choose whether to turn on encryption for standard fields, custom fields, files, attachments, and more. You also choose which specific fields to encrypt at rest. The driving principle is to use the appropriate encryption features to preserve functionality while keeping private, sensitive, confidential, and regulated data safe.

Note Due to platform optimizations, there’s a limit of 80 encrypted fields during org migrations. If you set up your encryption strategy with 80 or more encrypted fields, you must do a phased rollout of org migrations.