Controlling access to an organization’s data, applications and other IT resources is a vital and complex task. It’s essential to ensure that each user can access the resources they require to do their job, but that no one can access any data or system that they do not have a legitimate need for.
This article explores two popular models for access control, role-based access control (RBAC) and attribute-based access control (ABAC) and offers guidance for choosing the more appropriate option for your organization.
What is Role-Based Access Control?
In the RBAC model, employees and other users are granted access rights based on the role or roles that they hold in the organization. That is, administrators define a set of roles, grant appropriate access permissions to each of those roles, and then assign each user one or more roles — the roles that a person is assigned determine their access rights to IT resources.
Examples of RBAC
Here are some examples of roles and some of the access rights they might be granted:
- Chief Technology Officer — Access all the company’s servers
- Software engineer — Access particular application servers
- Helpdesk technician — Reset user passwords and unlock user accounts
Benefits of RBAC
Implementing RBAC simplifies access management. When a new employee joins the organization, administrators do not have to grant them a whole host of permissions one at a time; they can simply assign the new hire the relevant roles and they immediately have all the related access rights. Similarly, when an employee changes teams or departments, granting them the appropriate new access rights (and, importantly, removing ones they no longer need) is as simple as changing their role assignments.
Many enterprise systems offer role-based access control. Here is an overview of how Microsoft Entra (formerly Azure), Active Directory and SharePoint use RBAC.
RBAC in Microsoft Entra
Role-based access control in Microsoft Entra helps administrators manage access to cloud resources. For example, you can use RBAC to:
- Enable one set of users to manage virtual networks and another group to manage virtual machines.
- Empower database administrators to manage SQL databases.
- Allow a designated group of users to manage certain websites.
- Allow an application to access all resources in a resource group.
RBAC in Active Directory
In Active Directory, security groups function as roles. Each group is granted access to certain resources, and all members of the group inherit those rights. AD include a set of default security groups and administrators can create additional groups.
Here are some of the built-in security groups and their permissions:
- Backup Operators — Members can restore and replace files on a computer irrespective of the permissions required to access those files.
- Remote Desktop Users — Members can connect to an RD Session Host server remotely.
- Domain Admins — Members have extensive rights in a particular AD domain. For instance, they can update the membership of all groups and control access to domain controllers.
- Enterprise Admins — Members can make forest-wide changes, such as adding child domains.
- Schema Admins — Schema Admins can modify the Active Directory schema.
SharePoint also has predefined roles with permissions that members inherit. These roles include:
- End Users: Members can work with content in list items and document libraries but cannot configure or manage sites.
- Power Users: Members can interact with certain site components, like lists, web pages, libraries, etc.
- Site Owners: Members have control over the entire SharePoint site, including sub-site creation, design and permissions management.
- Site Collection Admins: Members have control over the sites in a site collection.
- SharePoint Farm Admins: These top-level administrators have complete control over the SharePoint farm, such as maintenance, storage, web apps and site collections.
RBAC in Exchange
Microsoft Exchange also follows an RBAC model. Some of the built-in management roles are as follows:
- Recipient Management — Members can create or update Exchange Server recipients within the Exchange Server organization.
- Helpdesk — Members can view and update user attributes like addresses, phone numbers and display names.
- Server Management — Members can configure server-specific features, such as certificates, client access protocols and virtual directories.
- Organization Management — Members have top-level access to the Exchange Server organization, which means that they can perform almost all the tasks for an Exchange object.
- Hygiene Management — Members can configure anti-spam and anti-malware features in Exchange.
What is Attribute-based Access Control?
ABAC grants access privileges according to a user’s attributes, either instead of or in addition to their roles. Examples of attributes include:
- User attributes: Job title, seniority level, department, job role
- Resource attributes: Type of file, owner of the file, sensitivity level of the file
- Environment: Network, geolocation, date, time of day
This is how it works:
- Administrators define policies that specify which combination of attributes is required to perform an action on a resource.
- When a user requests access to a resource, ABAC checks that user’s attributes. If they meet the defined policies, access is granted; otherwise, the request is denied.
Examples of ABAC
Here are two examples of ABAC policies:
- In order to access to payroll information, the user must be a member of the HR department. In addition, the access request must be during normal business hours, and the user can access only data for their own branch of the company.
- In order to access sales leads and related sensitive data, the user must be a sales representative and be in the United States region.
Benefits of ABAC
Using attributes instead of roles enables a more granular approach to access control. However, ABAC can be more complicated than RBAC.
ABAC in Microsoft Entra
As we have seen, Microsoft Entra allows for assignment of permissions based on roles. But it also enables administrators to add conditions for certain actions, which illustrates how ABAC can be considered an extension to RBAC. For example, you can add a condition that in order for a user to read a certain object, the user must have a given role and the object must have a specific metadata tag.
Attribute-Based Access Control vs Role-Based Access Control : A Comparison
The tables below show the pros and cons of both role-based access control (RBAC) and attributed-based access control (ABAC):
| Pros of RBAC | Cons of RBAC |
| RBAC works well for small to medium-sized organizations. | Large organizations can require so many roles that managing them becomes unwieldy. |
| You can easily model the organizational hierarchy. For example, you can automatically grant managers all the permissions of their direct reports. | Defining the rights of a large number of roles can be time-consuming and complicated. |
| The costs required to implement RBAC are relatively low. | Ensuring that each user has all the rights they need can require frequent creation of new roles. |
| Pros of ABAC | Cons of ABAC |
| ABAC can work better for large organizations. | RBAC implementation can be complex and time-consuming. |
| To add or remove permissions, admins can simply update a user’s attributes, which is much easier than defining new roles. | Recovering from errors during implementation can be difficult due to the complexity of ABAC. |
RBAC vs ABAC: Which One to Choose?
Choosing RBAC and ABAC requires understanding your organization’s structure, budget, size and security requirements. In some scenarios, ABAC turns out to be the winner and in others, it’s better to use RBAC.
Choose RBAC when you:
- Have a small or medium-sized organization
- Do not expect a huge influx of new users
- Have well-defined groups of users
- Are short on budget, resources or time
Choose ABAC when you:
- Have a large organization
- Expect your user base to expand significantly
- Have enough budget and resources
- Want a highly customizable and flexible access control policy
Access Control via Netwrix GroupID
Netwrix GroupID is a robust identity and access management (IAM) solution that follows the RBAC model. It includes the following predefined roles:
- Administrator — Can perform all Netwrix GroupID functions on an identity store
- Helpdesk — Can update directory information, reset account passwords and unlock accounts on behalf of other users
- User — Can create groups, manage their groups, and manage their own directory profile and passwords
You can create additional roles and assign appropriate permissions to them. For example, you can create roles to enable members of the role to:
- Create and manage groups
- Manage user profiles
- Manage scheduled jobs
Policies in Netwrix GroupID
Netwrix GroupID policies refine and strengthen role-based access. For each role, you can define the following policies:
- Group Ownership Enforcement policy — Prevents creation of a group without a primary owner and restricts the number of additional owners that a group can have
- Group Name Prefixes policy —Requires use of a prefix in the group name during group creation
- New Object policy — Limits creation of new objects to a specific organizational unit (OU) in the directory
- Search policy — Limits object search to a specific OU
- Authentication policy — Requires use of specific authentication methods (such as SMS or Windows Hello) to sign into Netwrix GroupID
- Password policy — Specifies password rules and validation checks
- Helpdesk policy — Implements restrictions on helpdesk technicians when they reset user passwords and unlock user accounts
Conclusion
Access control is essential for protecting data and IT systems. Choosing role-based access control vs attribute-based access control requires a careful assessment of your organization’s structure, security and compliance requirements, and growth projections.
Netwrix GroupID makes access management easier to comprehend, implement and oversee by providing adaptable role permissions and policies suitable for all organizations regardless of size or sector.
FAQ
What is the difference between RBAC and ABAC?
RBAC assigns access based on a user’s roles, such as their job and department. ABAC enables more granular control by granting access based on attributes like a user’s seniority level, the sensitivity level of the data, and the date or time of the access request.
Is ABAC better than RBAC?
At a high level, ABAC and RBAC serve the same goal: helping ensure that access to data and other IT resources is properly constrained. Which one is better depends on factors such as the organization’s size, structure, and security and compliance requirements.
In general, ABAC is considered more flexible and granular, making it suitable for large organizations with complex access control needs. RBAC, on the other hand, is simpler and often preferred by small to medium-sized organizations with well-defined groups and limited resources.
What is the difference between policy-based access control (PBAC) and ABAC?
PBAC controls access using policies based on criteria like conditions, rules or roles. ABAC grants access based on user, resource and environmental attributes.
What is the difference between context-based access control (CBAC) and ABAC?
ABAC grants access based on user, resource and environmental attributes. CBAC considers the broader context in which access is being requested, such as the state of a session or the risk level of a transaction.
