We will be discussing in this article how as a salesforce customer, one can secure his or her organisations data in salesforce. Securing our orgs data includes securing it from both extruders and unauthorized access by insiders. With all the ‘Mission Impossible’ like buildings with bullet proof walls, concrete vehicle barriers, CC TVs, round the clock guards, we can be pretty sure that no Single individual will be able to physically destroy salesforce data centres. With the SPI(Stateful packet inspection), Bastion hosts(Special purpose computers designed to withstand attacks), two factor authentication process and END to END TLS/SSL encryptions makes sure that no intruders, malwares or rogue employees cause harm to your data.
Salesforce uses a multi-tenant platform which separate your organization’s data from other organizations. One of the core features of a multi-tenant platform is the use of a single pool of computing resources to service the needs of many different customers. Salesforce protects your organization’s data from all other customer organizations by using a unique organization identifier, which is associated with each user’s session. Once you log in to your organization, your subsequent requests are associated with your organization, using this identifier.
These measures and others has helped salesforce achieve l SAS 70 Type II, Systrust and ISO 27001 certifications – all without losing performance. In short Sales force does its job of securing our data in the best way possible.
But these measures may not be sufficient, as we also need to take special care in protecting the data at our end. Salesforce has lot of inbuilt features to prevent unauthorized access. Unauthorized access can include phishing, malware etc. or intentional or accidental access by employees as well.
- Salesforce has proposed few guidelines on how to secure your organisation against phishing or other malwares. These are
Modify your Salesforce implementation to activate IP range restrictions. This will allow users to access Salesforce only from your corporate network or VPN, thus providing a second factor of authentication
- Educate your employees not to open suspect emails and to be vigilant in guarding against phishing attempts.
- Use security solutions from leading vendors to deploy spam filtering and malware protection.
- Designate a security contact within your organization so that Salesforce can more effectively communicate with you. Contact your Salesforce representative with this information.
- Consider using two-factor authentication techniques, such as RSA tokens, to restrict access to your network.
- Session security
Salesforce has a unique username and password for each employee of your organisations. You can implement password policies for users such as specifying an amount of time before all users’ passwords expire, the level of complexity required for passwords, and so on.
Salesforce provides its own system of user authentication, but some companies prefer to use an existing single sign-on capability to simplify and standardize their user authentication. In case you are using SSO capability, you have two options—federated authentication using Security Assertion Mark-up Language (SAML) or delegated authentication.
You can implement your own SSO using SAML which authenticates user using a token instead of password or use your own LDAP server. This improves the security in multiple ways such as:
- Using a stronger type of user authentication, such as integration with a secure identity provider
- Making your login page private and accessible only behind a corporate firewall
- Differentiating your organization from all other companies that use Salesforce in order to reduce phishing attacks
- Using IDP’s
Object-level permissions determines what actions (Create, Read, Edit, and Delete) a user can perform on records of each object.
In order to create a record of that object type, the user only needs the “Create” object-level permission.
In order to perform an action on an existing record, the user needs the corresponding object-level permissions and record-level permissions (see below).
There are 3 tiers of record-level permissions:
- Read Only
- Full Access
“Read only” and “Read/Write” access can be granted through a variety of means (org-wide defaults, sharing rules, etc.). Users with the object-level permission “View All” (pictured unchecked above) are granted “Read only” record-level permissions to all records of that object.
“Full Access” is granted to:
- The record owner.
- Users higher in the role hierarchy than the record owner (when “Grant Access Using Hierarchies” is enabled).
- Users with “Modify All” object-level permission (this includes system administrators).
- Members of a queue to all records owned by the queue.
It is not possible to share “Full Access” via sharing rules or other mechanisms at this time.
Scenario: A user must be able to delete an opportunity record owned by another user.
Demystifying Record Deletion within Salesforce
“Full Access” is typically granted to the record owner, users higher in the role hierarchy, and system administrators. As shown in example 4 above, “Full Access” record-level permission and “Delete” object-level permission are required in order to delete a record.
This explains why some users may not be able to delete records, even when granted “Read/Write” record access via sharing rules or org-wide defaults.
- Important Notes:
- Not all objects will adhere exactly to the above rules (e.g. products, which do not have a record owner).
- If a user can edit (but not delete) a record and has the “Transfer Record” permission, they may be able to transfer the record to become its owner. They may be able to then delete the record.
Field-level permissions determines which fields a user can view and edit on records of an object. Field-level permissions have 2 settings: