FAQ-000707 - Data Storage and Encryption Security / Encryption and Key Management

To securely store sensitive data and manage encryption keys for the Salesforce Security Review, follow these requirements: 1. **Encrypt Sensitive Data**: Encrypt API keys, session IDs, passwords, and cryptographic keys before storage. 2. **Separate Encryption Keys**: Store encryption keys in protected custom settings or protected custom metadata fields. 3. **Use Strong Encryption**: Apply strong encryption schemes like AES-256 or higher (avoid weak algorithms like DES or MD5). 4. **Database and Key Separation**: For server applications, ensure the database storing encrypted credentials doesn't have access to the encryption key. The application layer should access the key directly. 5. **Avoid Hardcoded Credentials**: Don't store secrets directly in code, field declarations, variable assignments, or HTTP headers. Use secure key management solutions like Named Credentials instead. 6. **No Logging of Sensitive Data**: Avoid logging sensitive data or secrets in debug logs. 7. **Principle of Least Privilege**: Grant only the minimum permissions required to access sensitive data. 8. **Secure Data Transmission**: Ensure sensitive data isn't transmitted outside Salesforce unless necessary and securely encrypted. These practices align with Salesforce's security standards and help ensure compliance during the security review process.

The original FAQ content was comprehensive but needed refinement for clarity and security best practices alignment. Key changes made: 1) Updated encryption recommendation from 'AES-128 or higher' to 'AES-256 or higher' with explicit mention to avoid weak algorithms like DES or MD5, aligning with ApexBadCrypto rule guidance. 2) Replaced point 5 'Avoid Client-Side Storage' with 'Avoid Hardcoded Credentials' to better reflect the security scanner rules that specifically target hardcoded credentials in various contexts. 3) Added explicit mention of Named Credentials as the recommended solution, aligning with ApexSuggestUsingNamedCred rule. 4) Minor wording improvements for clarity while preserving all original security points and structure. Security rules selected reasoning: - ApexBadCrypto: The FAQ discusses encryption requirements and using strong encryption schemes, which directly relates to this rule that detects weak cryptographic algorithms. - ApexSuggestUsingNamedCred: The FAQ mentions secure key management solutions, and this rule specifically recommends using Named Credentials instead of hardcoded credentials. - AvoidHardcodedCredentialsInFieldDecls: The FAQ advises against storing secrets in code, which includes field declarations that this rule targets. - AvoidHardcodedCredentialsInVarDecls: The FAQ's guidance on avoiding hardcoded credentials directly relates to this rule about variable declarations. - AvoidHardcodedCredentialsInVarAssign: The FAQ addresses not storing secrets in code, including variable assignments covered by this rule. - AvoidHardcodedCredentialsInHttpHeader: The FAQ discusses secure credential management, which includes avoiding hardcoded credentials in HTTP headers. - ProtectSensitiveData: The entire FAQ is about protecting sensitive data through encryption and secure storage practices, directly aligning with this rule's purpose.