How Shield Platform Encryption Works

Shield Platform Encryption meets the security requirements of customers while preserving functionality and performance in our multitenant environment. To make this happen, we provide encryption features in two separate tiers: in the application tier with FLE and in the transactional data tier with Database Encryption.

The platform’s object-relational mapping model includes metadata that describes exactly which data is encrypted. Encrypted data is stored with additional information that uses strong, nondeterministic cryptography supported by the Java Cryptographic Extension (JCE). Encryption and decryption occur in the platform’s application layer as application components are materialized by the runtime engine, ensuring that encrypted data doesn’t persist in plaintext.

Application Tier Encryption

For application tier features such as FLE, the platform’s object-relational mapping model includes metadata that describes exactly which data is encrypted. Encrypted data is stored with additional information that uses strong, nondeterministic cryptography supported by the JCE. Encryption and decryption occur in the platform’s application layer as application components are materialized by the runtime engine, ensuring that encrypted data doesn’t persist in plaintext. The Shield Key Management Service derives keys on demand from key material generated by HSMs. These derived keys are never persisted.

Database Encryption

Every write operation to the transactional database is encrypted by using a database tenant secret, a per-fragment Database Encryption salt, and a per-fragment random 12-byte nonce. Database Encryption uses strong, nondeterministic cryptography supported by the JCE. Encryption and decryption occur in the platform’s transactional database layer. Every database write is encrypted, and every data read is decrypted.

Encryption Keys

The Shield Key Management Service derives keys on demand from key material generated by Hardware Security Modules (HSMs). These derived keys are never persisted. For Field-Level Encryption, you can opt out of key derivation and supply a final data encryption key. You can choose to store keys in the tenant database, where they’re wrapped by a tenant wrapping key. (For Database Encryption BYOK, you must provide a full data encryption key, so there is no need to opt out of derivation.) Alternatively, for FLE, you can choose to bypass storage and add the key directly to the encrypted key cache, where it’s wrapped by the cache key encryption key. The architecture supports the simultaneous use of multiple encryption keys, enabling customers to quickly rotate and archive keys without losing access to their data. Rotated FLE keys are archived unless you destroy them. Database tenant secret keys are archived but can’t be destroyed. With EKM, we support key material generated and wrapped by root keys generated by external KMSs.

• Application Feature Encryption Happens in the Application Tier
  The Lightning Platform’s foundation for FLE is a metadata-driven software architecture that enables multitenant applications.
• Database Encryption Happens in the Data Tier
  The Lightning Platform’s foundation for Database Encryption is a fragment-driven architecture that supports multitenant transactional operations. It encrypts within the data tier.
• Application Tier Encryption and Database Encryption Work Together
  Even if you’re using Database Encryption, you can still use application tier encryption like FLE on as required for security and compliance.
• Special Database Encryption Considerations
  Certain aspects of transactional databases require delays before keys are used and before data can be encrypted.
• Data Encryption Keys (DEKs)
  The Shield Platform Encryption services can use three types of DEK: derived, root key created, or customer supplied. All have AES-256 bit strength. Derived DEKs and DEKs supplied by the customer aren’t persisted, but exist only in the encrypted key cache. Root key created DEKs are wrapped by the root key and stored in the database and unwrapped by the same root key when needed.
• Data Encryption Keys for Database Encryption
  Similar to FLE, DEKs for Database Encryption are either generated or supplied by the customer.
• Storing Encrypted Payloads for Application Tier Encryption
  For FLE and other application tier features, encrypted data is stored in the database with its metadata.
• Storing Encrypted Data for Database Encryption
  For Database Encryption, encrypted data is stored in a database fragment along with the IV and database tenant secret key ID.
• Shield Platform Encryption Process Flow for Application Tier Encryption
  Before data is encrypted, a Salesforce administrator must enable encryption and generate or supply key material. For the each field, file, attachment, and data element on which encryption is enabled in the application tier, the corresponding metadata in the UDD is updated to reflect the new encryption setting.
• Search Encryption at Rest Process Flow
  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 to allow Salesforce to scale operations. Apache Lucene is used for its core library. Because of this, the Search content is technically outside of the application tier and has its own process flow.
• Database Encryption Process Flow
  For Database Encryption, encryption and decryption happens at the fragment level.
• Key Management for Application Tier Encryption
  With Shield Platform Encryption, Salesforce administrators can manage the lifecycle of their data encryption keys while protecting those keys from unauthorized access. To ensure this level of protection, data encryption keys are never persisted in plain text. If a customer has opted out of key derivation, then a wrapped DEK is persisted, but must be unwrapped by the regional Shield KMS or external KMS.
• Key Management for Database Encryption
  Database Encryption provides you with the ability to rotate your database tenant secret after it’s listed on the Key Management page. Deleting database tenant secrets isn’t permitted.