Designing User Security and Visibility in Salesforce

Trust and security are at the top of Salesforce's priority list. The platform has everything you need if you're looking to construct a robust user security paradigm. However, this security approach has flaws that an attacker can exploit to gain access to your data. The Salesforce Architect has the duty to ensure that these features are set up correctly.

Design security in Salesforce is an architecture that is scalable and maintainable while ensuring that users can only access what they need to complete their work. This article discusses what works and how you can define your security system.

When most people think of security they think of authentication, or gaining access to a system. This is a critical part to the system security, but it is just the start. Furthermore, it is essential to note that Objects, Fields, and records are all types of data in Salesforce. A comprehensive Salesforce security data model is required to protect the many individuals and data that are in the system.

Data access

Presently, there are four degrees of data access:

• Organizational or system-level security.

• Object-level security.

• Field-level security.

• Record-level security.

  

1. Organizational or system-level security

Salesforce's highest degree of security is its system level, where you keep a list of allowed users, password regulations, login IP ranges, limiting login access to specific hours, Session Security, Login Flows, and Network Access restrictions.

2. Object-level Security

A profile or permission set based approach to Object Security in Salesforce involves assigning permissions to specific objects such as Accounts, Contacts, or Opportunities. You can grant the user access to editing, creating, deleting, or viewing records in that object.

3. Field-level security

In Salesforce, field-level security is a setting that allows administrators to control who has access to certain organizational information. The administrator can choose which profiles or permission sets have access to view, update, and save data in specific fields. Everyone in the organization does not always have access to all of Salesforce's data. Depending on the users that require it, certain data must be kept confidential. This is also a great way to simplify a user's view by removing visibility to fields that they don't need for their job. You can also take fields off of page layouts and other views, but then the user may still see these fields when creating reports or list views.

4. Record-level Security

In Salesforce, when you have to allow access to specific records within the object, it is done with the assistance of Record-level security. For example, object-level security says a User can see Contacts, but record-level security controls whether or not they can see the record for John Doe. Record-level security is affected by the most things - profiles, permission sets, sharing settings, sharing rules, role hierarchy, and even apex and manual record sharing. Record-level security cannot override object-level or field-level security, so if someone doesn't have permission to Opportunities at the object-level, it doesn't matter if you setup a sharing rule to share certain Opportunities with them.

Creating a security model

When creating a security model, you may want to think about the following steps:

• Creating personas.
• Creating base profiles.
• Adding permission sets.
• Defining the sharing model.
• Accounting for certain access kinds.

1. Creating Identities.

A persona/identity represents a group of users who access the platform in the same way. First, you need to create an exhaustive list of these personalities. This will assist define the scope of the security model and guarantee that there are no holes in the system's protection.

Human users are the initial type of persona. In most cases, these users log in using a user interface and an authentication method like identifier/password or single sign-on (SSO). An internal or external user can be referred to as a "human" here. Internal users include business users, the platform, and administrative users.

The second kind of persona is the non-human persona. Technical operations such as integration, registration, or record ownership use these kinds of user accounts. Logging in to the platform with one of these accounts is optional.

2. Lockdown your base profiles

Profiles and permissions sets are the most common methods for granting access to various resources. As a result, Salesforce does not recommend relying on profiles for permission management. Instead, it would be best to utilize permission sets and set groups for everything other than base profile settings.

However, presently, profiles are the only way to use these settings:

• Page layouts
• Default record type
• IP ranges and logs in hours

Also, remember that only one type of user license can be issued per profile because permits are granted through profiles. So if you need a profile with the same permissions for two types of licenses you will need two profiles.

Technically, profiles and permission sets are usable, but as many basic profiles as feasible should be avoided. The only capabilities for which base profiles should be used are those not included in permission sets, such as authorized IP ranges. Permission sets should be used for any remaining permissions.

3. Extend Permission sets and permission set groups

Create a set of access permissions relevant to your business for each persona. You can then create one or more permission sets based on the access rights you've granted. The permission sets are then divided into permission set groups, each corresponding to a specific persona in the system. Permission sets can be assigned to multiple personas, and it's simple to keep track of each user's access privileges.

It's a good idea to establish permission sets that encompass data access rights (objects and fields), assigned applications, and access to technical components (including Apex, Visualforce pages, flows, custom metadata types, and custom settings).

System-level rights, such as Lightning users' access or session settings, can also be specified with specific permission sets. Permission sets would grant admin and developer access in non-production environments such as sandboxes.

4. Set up your sharing model

To implement record-level access controls, you must first determine which objects and fields require which types of access. Access to all objects should be restricted as much as possible without hindering system usage, both to simplify the user experience and to avoid unnecessary data access that could pose a security risk.

After the profiles and permission sets have given users access to the correct objects and fields, we recommend the following steps to evaluate your record-level sharing:

• Setup your default sharing settings. Starting with public read/write is the easiest for small companies, but think about what data should be Private or Public Read Only to start, especially in complex organizations.
• Then review the role hierarchy, this is the easiest way to share records with managers or supervisors
• Setup sharing rules to share records across a role hierarchy, for example sharing Opportunities owned by Sales People with the Operations team.
• For admins, adjust their profiles so they should have View All or Modify All permissions to certain objects on their profile or a permission set.
• Finally, if this doesn't handle all of your sharing needs, look into a custom solution using Apex sharing records (requires code).

5. Account for certain access types

Some objects managed exclusively at the profile or permission set level should also be treated as part of the security model. Access to these items should be allowed by permission settings as stated above:

• External objects
• Custom settings and custom metadata types
• Apex classes and Visualforce Pages
• Apps, including related apps

Conclusion

Complex security models are more challenging to maintain and more prone to security vulnerabilities. In large enterprises, the performance of a platform can be negatively impacted by complex security approaches. The best thing to avoid this security loophole is to work with a solid governance system. You can develop a workable security model over time.

Feel free to check the apps that CloudAnswers developed to help Salesforce users work easier, and faster.