Shield Platform Encryption: Deterministic encryption scheme considerations

Shield Platform Encryption offers several types of encryption. Users never see encrypted data because it is encrypted immediately prior to database insertion and decrypted immediately following a database query.

• Probabilistic Encryption: Offers randomized encryption of data, where the same plaintext input does not always produce the same ciphertext output. This randomness enhances security but makes searching and querying encrypted data more challenging compared to deterministic encryption.
• Format Preserving Encryption (FPE): Preserves the format or structure of the original plaintext data while encrypting it. For example, a 16-digit credit card number would still be a 16-digit encrypted value. This is useful when encryption and decryption need to maintain data format requirements.
• Deterministic Encryption: Provides consistent encryption of data, ensuring that the same plaintext input always results in the same ciphertext output. This type of encryption is useful for searching and querying encrypted data while preserving the ability to perform equality and inequality comparisons.
  • Case-Sensitive Deterministic Encryption: A variant of deterministic encryption that considers case sensitivity in the encryption process. It ensures that “abc” and “ABC” will encrypt differently, providing case-sensitive encryption for fields like names or codes.
  • Case-Insensitive Deterministic Encryption: Similar to case-sensitive deterministic encryption but disregards case sensitivity during encryption. “abc” and “ABC” would encrypt to the same ciphertext, allowing for case-insensitive searches and comparisons.

These encryption types offer varying levels of security and functionality, allowing organizations to choose the most suitable encryption approach based on their specific requirements and use cases.

Below are the considerations that apply to data encrypted with Shield Platform Encryption’s deterministic encryption scheme. Some considerations manifest differently depending on whether data is encrypted with the case-sensitive or case-insensitive deterministic encryption scheme.

1. Key Rotation and Filter Availability:
   1. Synchronize data when rotating key material or changing encryption schemes.
   2. Without syncing, filtering and queries on unique attributes may be inaccurate.

Example: Update existing data to apply new encryption schemes using the Encryption Statistics and Data Sync page in Setup.

2. Available Fields and Other Data:
   1. Custom URL, email, phone, text, and text area fields support deterministic encryption.
   2. Not available for certain data types like date, Chatter, files, and attachments.

3. Filter Operators:
   1. Limited operators are supported, such as “equals” and “not equal to.”
   2. Unsupported operators like “contains” or “starts with” don’t return exact matches.

4. Formulas:
   1. Fields encrypted with deterministic encryption can’t be referenced in SOQL WHERE queries.

Example: Unable to use encrypted fields in WHERE clauses for database queries.

5. Case Sensitivity:
   1. Results are case-sensitive with case-sensitive deterministic encryption.

Example: “Jones” is distinct from “jones” or “JONES” in encrypted queries.

6. Custom Field Allocations:
   1. Case-insensitive queries require storing lowercase duplicates, impacting custom field counts.

7. API Options to Identify Filterable Fields:
   1. Use isFilterable() method to determine encryption scheme of a field.

8. External ID:
   1. Supports Text and Email external ID custom fields for certain encryption schemes.

9. Compound Fields:
   1. Searches may not work for concatenated values with case-sensitive encryption.

Example: Querying encrypted compound names like “William Jones.”

10. Filter Records by Strings:
    1. Commas in strings act as OR statements.

Example: Using quotation marks to search for strings containing commas.

11. SOQL GROUP BY, LIKE, STARTS WITH, ORDER BY Statements:
    1. Limited support or not supported for certain operations with deterministic encryption.

Example: Inability to use GROUP BY or LIKE statements with encrypted data.

12. Indexes:
    1. Support for different types of indexes varies based on encryption scheme.

Example: Using single-column indexes with case-sensitive deterministic encryption.

13. Next Best Action Recommendations:
    1. Load conditions only support equals or not equals operators with encrypted fields.

Example: Configuring recommendation systems with supported operators.

14. Chat:
    1. Case-sensitive encryption recommended for certain fields in chat systems.

Example: Encrypting actor names for privacy in chat conversations.

15. Converting Account and Contact Records to Person Accounts:
    1. Data synchronization required after conversion to maintain filtering capabilities.

References:

https://developer.salesforce.com/docs/atlas.en-us.securityImplGuide.meta/securityImplGuide/security_pe_considerations_general.htm

https://resources.docs.salesforce.com/latest/latest/en-us/sfdc/pdf/salesforce_platform_encryption_implementation_guide.pdf

https://help.salesforce.com/s/articleView?id=sf.security_pe_formulas.htm&type=5

https://help.salesforce.com/s/articleView?id=sf.security_pe_deterministic_considerations.htm&type=5