Role-based access control (role-BAC) uses roles to manage rights and permissions for users. This is useful for users within a specific department who perform the same job functions. If you’re planning to take the SY0-501 exam, you should have a basic understanding of implementing identity and access management controls such as role-based access control.
For example, can you answer this practice test question?
Q. Developers are planning to develop an application using role-based access control. Which of the following would they MOST likely include in their planning?
A. A listing of labels reflecting classification levels
B. A requirements list identifying need to know
C. A listing of owners
D. A matrix of functions matched with their required privileges
More, do you know why the correct answer is correct and the incorrect answers are incorrect? The answer and explanation are available at the end of this post.
Documenting Roles with a Matrix
Think about the developers of Microsoft Project Server. They didn’t just start creating roles. Instead, they did some planning and identified the roles they envisioned in the application. Next, they identified the privileges each of these roles required. It’s common to document role-based permissions with a matrix listing all of the job titles and the privileges for each role.
Role-BAC is also called hierarchy-based or job-based:
- Hierarchy-based. In the Project Server example, you can see how top-level roles, such as the Administrators role, have significantly more permissions than lower-level roles, such as the Team Members role. Roles may mimic the hierarchy of an organization.
- Job-, task-, or function-based. The Project Server example also shows how the roles are centered on jobs or functions that users need to perform.
Establishing Access with Group-Based Privileges
Administrators commonly grant access in the role-BAC model using roles, and they often implement roles as groups. Windows systems refer to these as security groups. They assign rights and permissions (privileges) to groups and then add user accounts to the appropriate group. This type of group-based access control, where access is based on roles or groups, simplifies user administration.
One implementation of the role-BAC model is the Microsoft built-in security groups and specially created security groups that administrators create on workstations, servers, and within domains.
The Administrators group is an example of a built-in security group. For example, the Administrators group on a local computer includes all of the rights and permissions on that computer. If you want to grant Marge full and complete control to a computer, you could add Marge’s user account to the Administrators group on that computer. Once Marge is a member of the Administrators group, she has all the rights and permissions of the group.
Similarly, you can grant other users the ability to back up and restore data by adding their user accounts to the Backup Operators group. Although the built-in groups are very useful, they don’t meet all the requirements in most organizations. For example, if your organization wants to separate backup and restore responsibilities, you can create one group that can only back up data and another group that can only restore data.
In Windows domains, administrators often create groups that correspond to the departments of an organization. For example, imagine that Homer, Marge, and Bart work in the Sales department and need to access data stored in a shared folder named Sales on a network server. An administrator would simplify administration with the following steps, as shown in the figure:
- Create a Sales group and add each of the user accounts to the Sales group.
- Add the Sales group to the Sales folder.
- Assign appropriate permissions to the Sales group for the Sales group.
If the company adds new salespeople, the administrator creates accounts for them and places their accounts into the Sales group. These new salespeople now have access to everything assigned to this group. If any users change jobs within the company and leave the Sales department, the administrator removes them from the Sales group. This automatically prevents them from accessing any resources granted to the Sales group. This example shows how to use a group for the Sales department, but you can apply the same steps to any department or group of users.
Without groups, you would use user-assigned privileges. In other words, you would assign all the specific rights and permissions for every user individually. This might work for one or two users, but quickly becomes unmanageable with more users.
As an example, imagine that people within the Sales department need access to 10 different resources (such as files, folders, and printers) within a network. When the company hires a new salesperson, you’d need to assign permissions to these 10 different resources manually, requiring 10 different administrative tasks. If you assign the permissions to the Sales group, you only need to add the new user to one group and you’re done.
Groups provide another security benefit. Imagine that a user is promoted out of the Sales department and now works in Marketing. If you have a Marketing group, you can place this user account into the Marketing group and remove the account from the Sales group. Removing the user from the Sales group instantly removes all the user rights and permissions applied from that group. However, if you’re not using groups and assign permissions to users directly, you probably won’t remember which resources were assigned to the user as a member of the Sales department. Instead, the user will continue to have access to this sales data, violating the principle of least privilege.
Q. Developers are planning to develop an application using role-based access control. Which of the following would they MOST likely include in their planning?
A. A listing of labels reflecting classification levels
B. A requirements list identifying need to know
C. A listing of owners
D. A matrix of functions matched with their required privileges
Answer is D. A matrix of functions, roles, or job titles matched with the required access privileges for each of the functions, roles, or job titles is a common planning document for a role- based access control (role-BAC) model.
The mandatory access control (MAC) model uses sensitivity labels and classification levels. MAC is effective at restricting access based on a need to know.
The discretionary access control (DAC) model specifies that every object has an owner and it might identify owners in a list.
See Chapter 2 of the CompTIA Security+: Get Certified Get Ahead: SY0-501 Study Guide for more information on access control models.