SalesForce Training in Kalyan Nagar

Salesforce Security Best Practices

For years, security concerns have been the leading reason why organizations hesitated to adopt cloud services. Much of this trust can be attributed to the efforts leading cloud service providers like Salesforce have put towards securing their customers’ data and providing robust features that are required by enterprises.

Auditing

Salesforce keeps track of all login attempts for the past six months, including the location of the login attempt and the IP address. Administrators can also turn on field history tracking (though with some limitations) to give visibility into field value changes and the user who performed the change.

Controlling user access to Salesforce

Salesforce has a robust system to control access and authenticate user identity that include:

Two-factor authentication – Administrators can turn on company-wide 2-factor authentication. Salesforce also lets admins create IP restrictions that would prevent access to Salesforce from untrusted IPs (or IP ranges). Admins can also set login restrictions based on the time of the day and the location from which the login attempt originates. When accessing Salesforce via an API, users are required to add a security token at the end of their password.

Custom login flows – One of the more innovative access control features of Salesforce is the ability to create custom login flows. As an example, if a user attempts to log into Salesforce from a restricted IP or during restricted hours, admins can implement a flow that would still allow the user to access Salesforce, but only after they’ve gone through several steps of authentication beyond 2-factor. In this way, an organization can meet their security requirements while also being able to perform business-critical activities within Salesforce.

Object-level permissions – Salesforce provides several layers of control over which records or the data stored in those records are visible/editable by which users or groups of users. Admins can set organization-wide sharing rules which sets the baseline minimum level of access, which can be configured separately for each object in Salesforce.

Role hierarchy – Organization-wide rules can then be extended using the role hierarchy. Role hierarchy lets admins configure how data is visible/editable to users, their subordinates and their superiors. Role hierarchy does not determine which fields are available to users, but rather which records, reports, and dashboards can be accessed. In general, roles are a reflection of the organizations internal human resource structure, where the CEO would have the highest role in Salesforce, therefore have the broadest visibility to data (though some organizations might place the Salesforce Administrator at the highest level).

Exceptions – Some organizations need more flexibility beyond what organization-wide rules and hierarchy provides. In this case, sharing rules can be employed to further increase data access to those users who are considered an exception.

Field-level permissions – Profiles allow admins to give finer grain access or apply restrictions to individual fields within a record of an object. When creating a new field, admins are given the option to make the field read-only or read/write or completely invisible to each profile. Every user in Salesforce must be associated to only one profile.

Permission sets – Permission sets are yet another way that Salesforce allows admins to customize data access control. With permission sets, admins can create a fine-tuned set of permissions that only a subset of users need. When a user is added to a permission set, any restriction that their profile applies will be removed if the permission set allows it.

Public groups – A public group, which is a grouping of Salesforce users, can be used by Salesforce users to share content and knowledge. Users can specify, for example, which public group should be able to see a specific leads view within the lead object. There are many other uses for public groups.

Encryption – Salesforce provides what is now known as “Classic Encryption.” Admins can encrypt custom fields with 128-bit Advanced Encryption Standard (AES) using this feature, which comes out of the box. There are several limitations with this, including the fact that it only applies to custom text-fields that can’t be more than 175 characters long.

Salesforce Shield

Salesforce introduced Shield in 2015 to provide customers with three additional layers of security: event monitoring, audit trails, and platform encryption.

Event monitoring

• Salesforce Shield’s event monitoring feature gives administrators and security professionals visibility into user behavior and application performance. Logs are generated and delivered the next day to customers via SOAP API and REST API.
• Event monitoring works best if organizations use Salesforce’s Analytics Cloud to visualize the events or a third-party tool that combines event logs from Salesforce and other services to analyze potential insider threats. Event monitoring can also be used to increase Salesforce use and drive adoption.

Audit trails

• Though Salesforce includes a certain level of field history tracking available by default, Salesforce Shield dramatically expands tracking. Organizations can track field history going back up to 10 years across custom objects, accounts, cases, contacts, leads, and opportunities for 60 fields per object.
• This can be especially useful for highly regulated industries such as healthcare, financial services, and government agencies who need to maintain extended audit trails.

Platform encryption

• Platform encryption in Salesforce Shild is much more comprehensive and feature rich than Salesforce’s classic encryption. Here, organizations can encrypt data that’s at rest, including data stored in fields as well as files being uploaded to Salesforce.
• Salesforce employs probabilistic encryption using 256-bit AES. Though Salesforce has given the customer control over the lifecycle of managing the key, it’s still stored in Salesforce’s environment.