You are here:
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.
Application components, such as Salesforce objects, aren’t modeled directly in our underlying relational database. Instead, when customers interact with their data in a Salesforce application, the platform’s runtime engine materializes the data by using metadata stored separately in the Lightning Platform’s Universal Data Dictionary (UDD).
This way, each tenant’s data is kept secure in the shared database, and tenants can customize their schema in real time without affecting other tenants’ data. Also, the application’s code base can be patched or upgraded without breaking tenant-specific customizations. See Platform Multitenant Architecture for details.
The UDD includes metadata that determines which data is encrypted at runtime. The encryption service works in the Lightning Platform’s application layer. That is, data is encrypted directly before it’s stored in the database. The resulting encrypted payload is stored with metadata about the specific key used to encrypt it. For decryption, data is decrypted as it’s materialized. It’s then pushed up through the application pipeline and appears in plaintext to the user who requested it.
By embedding the encryption metadata in the UDD, the Shield Platform Encryption architecture gives customers the option to choose what data to encrypt. The Shield Platform Encryption engine strictly manages the flow of encrypted data from the application layer to the database and vice versa. The relevant code path is run through the UDD before data is read or stored.
Cryptographic Library and Algorithms
For all Application tier features, Shield Platform Encryption uses the JCE to encrypt and decrypt data. Specifically, Shield Platform Encryption uses the Advanced Encryption Standard (AES- 256) in CBC mode with, by default, a random IV. Deterministic encryption uses a field-specific static IV, which is a hash of the entity ID, field ID, and key ID. This method makes the static IV unique to each customer and field per org. Upon key rotation, a new static IV is generated for each field.
KMS Encrypted Key Cache
Salesforce has taken steps to reduce access to encryption key material across the servers where encrypted keys are available for the application servers. Rather than holding data encryption keys on the application server, they’re temporarily held in an encrypted key cache on a regional KMS. This feature is a central service that all application servers in a particular region can access. When the customer accesses encrypted data on the application server, the server uses a DEK for a short time to perform encryption and decryption operations. After this transaction is complete, related memory containing the DEK is freed. The DEKs are never persisted on the application server, and they’re only available in the KMS cache that serves the application server’s region.
