Overview of Data SecurityExplain the importance of giving the right people access to the right data. List the four levels at which you can control data access. Describe a typical scenario for limiting data access at each of the four levels.
- One of the key decisions that affects org/app security is which data set each user/user group can see.
- Can specify in detail which users can view, create, edit, or delete any record or field in the app.
- Its necessary to balance security of the data with the convenience to the user.
- Levels of Access:
- Organization - list of authorized users
- Object - prevent group of users from viewing/editing/deleting any records of that object
- Fields - salary could be hidden, for example
- Records - can allow users to view/edit their own entries, but not any one else’s
- Role hierarchies - access for users higher in the hierarchy can have access to all records owned by users below them.
- Organization-wide defaults - can apply restrictive defaults and then selectively give access to other users.
Control Access to the OrgCreate, view, and manage users. Set password policies. Limit the IP addresses from which users can log in. Limit the times at which users can log in.
- Users are identified by username, password, and a profile.
- View and manage users: Setup » Quick Find » “Users”
- Cannot delete users, but can deactivate an account so a user can’t log in. Do this by clearing the Active checkbox. Can also Freeze a user.
- Access password policies via: Setup » Quick Find » “Password Policies”
- Specify trusted IP ranges via: Setup » Quick Find » “Network Access”
- Restrict login access by IP address via: Setup » Quick Find » “Profiles”
- Restrict login access by time: Setup » Quick Find » “Profiles”
Control Access to ObjectsView existing profiles and create new ones. Modify access to objects using profiles. View all assigned users in a profile. Create new permission sets. Assign permission sets to single and multiple users.
- Users have one profile and many permission sets. The profile determines the objects they can access, permission sets grant additional permissions.
- The platform includes a set of standard profiles, such as “Standard Usecr,” “Marketing User.” Standard profiles can’t be edited, but they can be cloned and then edited.
- Access profiles via: Setup » Quick Find » “profiles”
- A permission set is a collection of settings and permissions that give users access to various to different tools and functions.
- Two primarily purposes:
- Granting access to custom objects or apps, and
- Granting permissions to specific fields.
- Manage permission sets via: Setup » Quick Find » Permission Sets
Generally, use profiles for types of users with clearly-defined job functions. For example, Recruiters and Standard Employees. Use permission sets for employees who need a special privilege on top of their normal user access. For example, there could be a hiring manager permission set that applied to standard employees who need to hire someone to work on their team.
Control Access to FieldsList reasons to limit access to specific fields. View and edit field-level security settings.
- Defining field-level security is the second line of defense in security behind controlling object-level access.
- Field-level security controls the visibility of fields in any part of the app, including related lists, list views, reports, and search results.
Note: Its necessary to turn on the Enhanced Profile User Interface for some of these steps, via:
Setup » Quick Find » Enhanced Profile User Interface
- Profiles restrict a user’s general access. Permission sets expand it.
- Edit Profiles via: Setup » Profiles » select a user » Object Settings » select an object
- Edit Permission Sets via: Setup » Permission Sets » select a permission set
Control Access to RecordsList the four ways to control access to records. Describe situations in which to use each of the four record-level security controls. Explain how the different record controls interact with each other. Set org-wide sharing defaults to control access to records.
Data access can be controlled precisely on the record level. To determine which individual records users can view and edit in each object, answer the following:
- Should your users have open access to every record, or just a subset?
- If it’s a subset, what rules should determine whether the user can access them?
Permissions on a record are always evaluated by a combination of object-level, field-level, and record-level permissions. When object-level permissions conflict with record-level permissions, the most restrictive settings win.
Four ways of controlling record-level access, listed in order of increasing access:
- Org-Wide Defaults: most restrictive baseline access level
- Role Hierarchies: ensure managers have the same access as their subordinates
- Sharing Rules: automatic exceptions for particular groups of users
- Manual Sharing: record owners can give read and edit permissions to users who wouldn’t have access to the records any other way
Org-Wide Sharing Options:
- Private: Only record owner and users above that role in hierarchy can view, edit, and report on those records
- Public Read Only: All users can view and report on records, but only owner and users above that role in hierarchy can edit
- Public Read/Write: All users can view, edit, and report on all records
- Controlled by Parent: A user can view, edit, or delete a record if she can perform that same action on the record it belongs to.
Set Org-Wide Sharing Defaults via: Setup » Quick Search » Sharing Settings
Create a Role HierarchyExplain how a role hierarchy is different from an org chart. View and modify a role hierarchy. Create and assign roles to simplify access to records.
Role hierarchies are not the same as org charts. Each role in the hierarchy represents a level of data access that a user or group of users need:
- Managers have access to the same data as their employees, regardless of org-wide defaults.
- Users who need access to the same types of records can be grouped together.
Control sharing access using hierarchies for any custom object via:
Settings » Quick Find » Sharing Settings
Implement role hierarchies via: Settings » Quick Find » Roles
Define Sharing RulesUse sharing rules to extend access beyond the role hierarchy structure. Create a public group that includes users with different profiles and roles.
Sharing rules are a means of making automatic exceptions to org-wide sharing settings for selected users. Each sharing rule has three parts:
- Records: the set of records is determined by criteria-based sharing rules or by the user that owns them.
- Users: can be determined by groups of users, including role, territory, or public group.
- A public group is set up by admins to simplify creation of sharing rules.
- Kind of Access: Read-Only or Read/Write
Define public groups via: Setup » Quick Find » Public Groups
Define a sharing rule via: Setup » Quick Find » Sharing Settings