Access Control Models Role-based Access Control
If you plan on taking the Security+ exam you should have a good understanding of the various access control models including role-based access control list (RBAC). These controls restrict access to the logical network as opposed to restricting access to the physical areas of a building or physical access to devices within the network.
This blog is an excerpt from the CompTIA Security+: Get Certified Get Ahead: SY0-301 Study Guide.
Role-based access control (RBAC) uses roles to manage rights and permissions for users. This is useful for users within a specific department that perform the same job functions. An administrator creates the roles and then assigns specific rights and permissions to the roles (instead of to the users). When an administrator adds a user to a role, the user has all the rights and permissions of that role.
The RBAC model uses roles (often implemented as groups) to grant access by placing users into roles based on their assigned jobs, functions, or tasks. A user account is placed into a role, inheriting the rights and permissions of the role. Rule-based access control is based on a set of approved instructions, such as an access control list.
Using Role-based Access Control Based on Jobs and Functions
An example of the RBAC model is Microsoft’s Project Server. The Project Server can host multiple projects managed by different project managers. It includes the following roles:
- Administrators. Administrators have complete access and control over everything on the server, including all of the projects.
- Executives. Executives can access data from any project held on the server but don’t have access to modify system settings on the server.
- Project Managers. Project managers have full control over their own projects but do not have any control over projects owned by other project managers.
- Team Members. Team members can typically report on work they are assigned and complete, but they have little access outside the scope of their assignments.
Microsoft’s Project Server includes more roles, but you can see the point with these four. Each of these roles has rights and permissions assigned to it, and to give someone the associated privileges, you’d simply add the user’s account to the role.
RBAC 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 Role-based Access Control with Groups as Roles
Access is established in the RBAC model based on role membership, and roles are often implemented as groups. Each role has rights and permissions assigned, and you simply add the user to the role to grant appropriate access. Access based on roles, or groups, simplifies user administration.
One implementation of the RBAC model is Microsoft’s built-in groups, and specially created groups that are available in both workstations and domains. For example, if you wanted to grant Sally full and complete control to a local system, you could add Sally’s user account to the Administrators group. All the appropriate rights and permissions are already granted to the Administrators group, so by adding Sally as a member of the group, she has the same rights and permissions. Similarly, you can grant other users the rights and permissions to perform backups and restores by adding their user account to the Backup Operators group.
Built-in groups (like the Administrators group and the Backup Operators group) have rights and permissions already assigned. It’s also possible to make changes to the built-in groups, giving this model some flexibility. More often, additional groups are created that can be used to meet specific needs. For example, to separate the backup and restore responsibilities, you can create one group that can only back up data and another group that can only restore data.
Without using groups, you would have to individually assign all the specific rights and permissions for every user. This may work for one or two users but quickly becomes unmanageable with any significant number of users.
In Windows domains, groups are often created to correspond to departments of an organization. For example, the following figure shows how you can do this for users in the sales department. The users are added to the sales department, and then rights and permissions are assigned to the group. Any user added to this group will have the same rights and permissions assigned to the group. If you remove the user from the group, the user no longer has these rights and permissions.
Administrators can use group membership to manage user accounts for any department. When a new employee is hired for a department, administrators create the account and place the account in the appropriate group. The new employee instantly has the appropriate level of access based on the rights and permissions assigned to the group.
The use of roles, or groups, greatly simplifies user administration. Groups make it easier to grant appropriate permissions to new users, and they help enforce least privilege. The RBAC model can use user account templates to enforce the principle of least privilege. This ensures that new users are granted the access they need, and no more.
In contrast, if you assign permissions to users directly, they can be very difficult to manage. Imagine that people within the sales department need access to ten different resources (such as files, folders, and printers) within a network. When a new salesperson is hired, you need to manually assign permissions to these ten different resources requiring ten different administrative tasks. If you assigned the permissions to the sales group, you only need to add the user to the group once.
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 rights and permissions from that group. However, if you’re not using groups and assign permissions to users directly, you probably won’t remember what 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.
Here are some links to more resources to help you pass the Security+ exam the first time you take it.