Salesforce Developer Security Storingsendatasobject

salesforce-developer-security

// Salesforce - Developer - Security - Storing Sensitive Data - sObject:

Secrets often require protections or access restrictions that differ from normal 
information. Our goal is to make sure that secrets are accessible by the fewest 
number of people possible. Consider the following scenarios:

1. A user accidentally downloads malware and has their Salesforce session 
   compromised.  

2. An internal employee becomes curious, loses their employment, becomes 
   disgruntled, or any combination of these.

3. A communities user who discovers they have API access.

In each of these scenarios, an improperly protected secret might become visible 
to someone who should not have access to it. For these reasons, we consider all 
of the following  to be potential parties from which secrets should be 
protected:

1. Standard users - Users with normal Salesforce licenses and average 
   permissions.

2, External users - Users with reduced permissions, potentially using a 
   communities license or viewing data through a Force.com Site.

3. Administrator users - Users with normal Salesforce licences but above 
   average permissions, up to Modify All Data.

4. Attackers - Attackers can be any of the above, possibly due to compromised 
   accounts or insider threat. 

A common question in regards to secret storage is why secrets need to be 
protected from administrators. Administrators tend to be in positions of 
greater trust due to their privilege and a little more privilege may seem 
harmless. Here are a couple of points to consider:

1. If a stored secret is the password to an external service, the Salesforce 
   administrator might not be supposed to have direct access to this service.

2. The stored secret might be an encryption key that is not meant for anyone, 
   including the administrator.

3. Even if an administrator can have access to the secret, an attacker might 
   compromise the administrator's account and following our secret storage 
   guidelines can prevent further compromise. 

Secret protection can be broken down into two primary categories, and both will 
be addressed:

1. Securely storing the secret.
2. Securely using the secret.

Salesforce has a number of methods for storing data that can potentially be used 
for storing secrets. Some common methods that we will cover are:

1. Storing secrets in sObject fields (unencrypted or encrypted).

2. Storing secrets in custom settings (protected, unprotected, unmanaged, and 
   managed).

3. Storing secrets Named Credentials

Each of these methods has a variety of critical properties that will define 
their strength as a secret storage medium. Later in this module we will cover 
the strengths and weaknesses of each so you can properly build a solution for 
any secret storage requirement you encounter.

Having a location to store secrets is only half the problem. Many secrets, 
like passwords and encryption keys, need to be used! The level of protection 
placed on a secret can only be considered as strong as the weakest point in 
it's lifecycle. Putting this into another housing metaphor, locking your front 
door is great, but not as secure as it could be if you leave the back door and 
all the windows unlocked. Because of this we have to consider all the following 
scenarios:

1. Is the secret leaked to the debug logs?
2. How is the secret set?
3. Can the secret be updated?

Fields are the standard place for storing information in Salesforce, and often 
times they are the first thought for storing secrets. There are two primary 
options for secret storage in an sObject field:

1. Standard Text Field
2. Encrypted Text Field

Access to these fields can be set through field-level security, CRUD, and 
sharing. 

Custom text fields are often a common consideration for storing secrets. 
Field-level security, CRUD, and Sharing offer attractive controls to restrict 
access to information. Consider the following setup, which is considered the 
"most restrictive" way to configure access to a custom field:

Most Restrictive Setup:

1. Organization-wide default sharing is configured to private.

2. CRUD access is not enabled for any user for the object upon which the secret 
   field resides.

3. Read & write abilities to the secret field are not granted via field-level 
   security to any user.

4. Access to the secret is handled by Apex only, in system mode.

Benefits:

1. The standard authorization access controls only require clicks to configure 
   in the most restrictive setting.

2. Standard users in the org will be unable to access the secret in any 
   capacity.

Drawbacks:

1. Anyone with the ability to modify CRUD and field-level security can grant 
   themselves access to the secret. The permissions required for this are 
   "Manage Profiles and Permission Sets" and "Customize Application." 
   Generally administrators will be the only users with this level of access, 
   but this can vary by environment.

2. Any user with the "Author Apex" permission can create and deploy Apex code 
   that can be crafted to expose a secret to an industrious user / attacker. 
   Generally administrators will be the only users with this permission, but 
   this can vary by environment.

3. Any user with the ability to deploy an AppExchange package can gain access 
   to the secret. Since any user with a free developer account can create a 
   managed package, code could be crafted to expose a secret to an industrious 
   user / attacker. Generally administrators will be the only users with the 
   "Download AppExchange Packages" permission but this can vary by environment.

4. Any user with the "View All Data" permission can employ the developer 
   console and debug logs to view the secret when it is used by Apex. This is 
   done by enabling the "finest" granularity in Apex debugging.

Any information stored in a custom text field will be available to several 
types of privileged users (listed in the above drawbacks). Based on the number 
of user type with access to all custom text fields, custom text fields are not 
advised for secrets like passwords, oauth tokens, or encryption keys.  A better 
option for custom text fields is the storage of standard sensitive information 
like customer or employee PII (name, address, email).

Encrypted Custom Text Fields:

Encrypted custom text fields are the most commonly used storage location in 
Salesforce for storing secrets. Field-level security, CRUD, and Sharing offer 
attractive controls to restrict access to information, and the encryption adds 
an additional layer of protection. Encryption is seamless and handled by the 
platform, so there is little additional difficulty involved using an encrypted 
custom text field over a standard custom text field. Consider the following 
setup, which is considered the "most restrictive" way to configure access to a 
custom field:

Most Restrictive Setup:

1. Encryption is enabled, and value of the field is fully masked.

2. No users have the "View Encrypted Data" permission.

3. Organization-wide default sharing is configured to private.

4. CRUD access is not enabled for any user for the object upon which the secret 
   field resides.

5. Read & write abilities to the secret field are not granted via field-level 
   security to any user.

6. Access to the secret is handled by Apex only, in system mode.

Benefits:

1. The standard authorization access controls only require clicks to configure 
   in the most restrictive setting.

2. Standard users in the org will be unable to access the secret in any capacity.

3. The encryption is handled seamlessly by the platform, making it easy to use.

4. Encrypted fields have flexible masking options that can be used to obscure 
   all but the last four digits of a government ID number for example.

5. Encrypted fields allow the secret value to be encrypted at rest. This can 
   help an organization meet regulatory requirments placed on them.

Drawbacks:

1. The "View Encrypted Data" permission is global, and not field specific. If 
   this permission is required by anyone in your organization, they will be able 
   to see the unencrypted secret if they have access to the field. 

2. Anyone with the ability to modify profiles can grant themselves access to the 
   unencrypted secret by modifying CRUD, field-level security, and the "View 
   Encrypted Data" permission for their profile. The permissions required for 
   this are "Manage Profiles and Permission Sets" and "Customize Application." 
   Generally administrators will be the only users with this level of access, 
   but this can vary by environment.

3. Any user with the "Author Apex" permission can create and deploy Apex code 
   that can be crafted to expose the unencrypted secret to an industrious 
   user / attacker. Generally administrators will be the only users with this 
   permission, but this can vary by environment.

4. Any user with the ability to deploy an AppExchange package can gain access to 
   the unencrypted secret. Since any user with a free developer account can 
   create a managed package, code could be crafted to expose a secret to an 
   industrious user / attacker. Generally administrators will be the only users 
   with the "Download AppExchange Packages" permission but this can vary by 
   environment

Any information stored in an encrypted custom text field will be available to 
several types of privileged users (listed in the above drawbacks). Based on the 
number of user type with access to all encrypted custom text fields, encrypted 
custom text fields are not advised for secrets like passwords, oauth tokens, or 
encryption keys.  A better option for encrypted custom text fields is the 
storage of sensitive information that must be masked or encrypted at rest, 
like social security numbers or other forms of government ID numbers.

To give ourselves access to secret fields:

1. Setup -> Manage Users -> Profiles -> System Administrator 

2. Edit the SecretObject__c field-level security to give yourself 
   read access on the value__c and encrypted_value__c fields. 

3. If you query the SecretObject__c object in Workbench now, you will see that 
   the value__c is visible, and encrypted_value__c is visible but masked.

4. To unmask the encrypted_value__c data, Apex can be used. This is because Apex 
   can always see contents of encrypted fields in unencrypted form. There is a 
   URL on the Visualforce page that reloads the page with the showsecret=true 
   URL parameter. Click it, and invoke the Apex code that unmasks the encrypted 
   text.

You have now seen the primary ways in which sObjects are used to store secrets. 
Here for your reference are the pros and cons of these options:

1. sObject Encrypted Text Fields

   a. Pros: Encrypted at rest, Using CRUD, FLS, and sharing will obscure from 
      majority of users. Easy to setup.

   b. Cons: Not hidden from Modify All Data, Download AppExchange Packages, 
      Deploy Apex, View Encrypted Data

2. sObject Text Fields:

   a. Pros: Using CRUD, FLS, and sharing will obscure from majority of users. 
      Easy to setup.

   b. Cons: Modify All Data, Download AppExchange Packages, Deploy Apex, Manage 
      Profiles and Permission Sets, Customize Application, and View All Data

Taking into account the strengths and weaknesses above, sObjects are appropriate 
for storing sensitive information but not secrets. Encrypted fields in 
particular are excellent at meeting regulatory requirements for encryption at 
rest, even if not suitable for passwords or encryption keys.
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License