A short Salesforce-led video discussion (Trusted Enterprise Security series) focused on access controls and enforcing the principle of least privilege. Rachel Beard (security architect) and Purva Kaushal (security product manager) explain data classification, object/profile/permission-set and field-level controls, sharing rules, org-level controls, and audit trails as ways to limit data exposure and manage access drift.
We know data is more valuable than ever, but granting users too much access to that data could leave you overexposed in the event of an attack. Welcome back to our Trusted Enterprise Security series. I'm Rachel Beard, a security architect here at Salesforce, and I'm joined by Purva Kaushal, a security product manager here at Salesforce. In the last video, we talked about the configurables, the security controls included in your Salesforce license. Today, we're going to continue with those configurables, expanding into access controls, because we know that following the principle of least privilege is a priority for businesses everywhere. Across every industry.
Exactly. Customers often ask us how to prevent data loss that happened by accident or theft. Beyond SSO and mfa, enforcing least privilege is one of the best ways to manage access control. Users and AI agents should only have as much access as they need to do their jobs, nothing more. In the case of a social engineering attack, for example, you can reduce the surface of risk of what can be viewed, damaged, or exported by enforcing least privilege access.
Yes, and least privilege access starts with knowing your data. What's considered sensitive, competitive, or confidential in your environment. When you know what data you have and where it lives, you can then apply measures to protect that data, like data classification, which is built right into standard and custom field properties for all Salesforce customers. With data classification, you can apply compliance categories, sensitivity levels, data owners, and more.
Right. And after classifying your data, I then suggest to customers to think about their users. What will their job functions be? What data access do they need to be effective? What access can be removed? Once I have an understanding of my data and my users, we have lots of layers of access controls to manage what users can do and what they view once they are logged into Salesforce. Rachel, can you walk us through how Salesforce access controls work together?
Yeah. Let's start at the organization level. We have controls here that govern access to the environment. We discussed some of those in the prior video. Then, at the object level, profiles and permission sets can be used to grant access to create or read or update or delete records of that object type. So if there are some objects a user just doesn't need to interact with, you can make sure they don't have access to them. Profiles and permission sets also control what a user is allowed to do in Salesforce, and these permissions can be set to expire after a certain amount of time. So, for example, a user with temporary permission to install a connected app can automatically have that perm removed at the end of the day and at the record level, Uruguay defaults at the baseline Private Public Read Only or Public Read Write Setting an object to private means only the record owner and those above them in the role hierarchy can see it. For other objects you might open them up to Public Read only or Public Read write depending on the sensitivity of the data and how broadly it needs to be shared. Next, we can use sharing rules to share horizontally. For example, all support agents assigned to a particular product might get edit access to any corresponding case related to that product, or maybe everyone in a given region should have access. Depending on a customer's support model, you can easily set up criteria based sharing rules to cover these types of scenarios. And finally, field level security can be applied to make data invisible or or read only to users who don't need to view or edit that data. This is a very granular access control that applies everywhere the user might encounter that data, meaning that the data will not be shown on a page layout, on a list view, in a report via the API, wherever this control closes off backdoors where sensitive data might accidentally surface.
Exactly. But let's be honest here, even if you've set everything up properly at the start we we know access can drift over time. We have some customers who have orgs that are 20 plus years old, new permissions get added, policies change, people get off boarded. Customers need a way to keep track of it all. Our out of the box setup audit trail enables customers to monitor for changes to profiles, permission sets, password policies, session settings, SAML configuration, salesforce certificates, you name it. You can easily download 6 months of audit history records within literally a few clicks.
Yeah, you got to love a paper trail. Or I guess in this case a digital trail. Porvoo we just talked about a lot and the last thing I want to add here is that customers everywhere can increase their own awareness and training around social engineering and the increasing sophistication of evolving threats. We have a ton of really useful trails to help you and your employees can skill up in our security Trail mix linked here. And in the next video we'll talk about some of our popular security add ons for customers who require additional levels of security and compliance. Thanks for joining us and we'll see you next time.
