Role-Based Access Control (RBAC) is a security paradigm whereby users are granted access to resources based on their role in the company. RBAC, if implemented correctly, can be an effective way of enforcing the principle of least privilege.
The basic principle of Role-Based Access Control is simple: the Finance department can’t see HR data and vice versa.
Get the Free Pen Testing Active Directory Environments EBook
When implemented correctly, RBAC will be transparent to the users. Role assignment happens behind the scenes, and each user has access to the applications and data that they need to do their job.
In this guide, we’ll explain what RBAC is in more detail, and show you when and how you can use this paradigm.
Role-Based Access Control: The Basics
Most RBAC systems are based on the application of three basic principles. How these are applied in individual organizations can vary, but these principles remain invariable:
- Role assignment: A subject can exercise a permission only if the subject has selected or been assigned a role.
- Role authorization: A subject’s active role must be authorized. That is, I can’t just assign myself to a role. I need authorization.
- Permission authorization: A subject can exercise a permission only if the permission is authorized for the subject’s active role. With rules 1 and 2, this rule ensures that users can only exercise permissions for which they are authorized.
RBAC is important for cybersecurity because statistics on data breaches indicate that granting inappropriate levels of access to staff members is a leading cause of data loss and data theft. Without a system for deciding who can access data, some data can be left exposed.
In October 2019, cybersecurity researchers Diachenko and Troia found a trove of data exposed and easily accessible to the public on an unsecured server, which contained 4 terabytes of PII, or about 4 billion records. A total count of unique people across all datasets reached more than 1.2 billion people, making this one of the largest data leaks from a single source organization in history.
The leaked data contained names, email addresses, phone numbers, LinkedIn, and Facebook profile information. The discovered ElasticSearch server containing all of the information was unprotected and accessible via a web browser. No password or authentication of any kind was needed to access or download all of the data because the organizations that were holding the data (two distinct, unnamed data enrichment firms) hadn’t taken steps to limit access to them.
This is an extreme example: the data in question had no access controls imposed at all. It might appear that your organization would never make such a mistake. In practice, however, it’s easy to make mistakes–especially when critical information is stored in many places with varying access control systems and easy end-user sharing features.
Implementing an RBAC paradigm can be difficult, largely because it requires you to define – in detail – all of the roles in your organization, and decide which resources employees in that role should be granted. In large organizations with many moving parts and interconnected teams, even sketching an organizational map of this kind can be a major undertaking.
In some cases, this means that the decisions that underpin RBAC can become almost “philosophical” questions.
- Do assistants, working on behalf of their managers, need the same level of access?
- Should a legal team member become part of the finance role in order to access a subset of files temporarily?
- Do security staff need access to all the data they are attempting to secure?
- If a staff member is promoted, do they inherit access permissions from a previous role?
- Or do junior staff need more access than the managers they report to?
The answers to these questions can be extremely complicated because they pertain to the fundamental way in which your organization works. And as a security architect, you are unlikely to be able to have this kind of pan-organizational oversight.
For this reason, here at Varonis, we recommend that you don’t attempt to implement a “pure” RBAC system. Instead, we suggest that you use a hybrid approach that incorporates RBAC principles but does not rely on these completely.
The Benefits of Role-Based Access Control
At the broadest level, RBAC helps maximize operational efficiency, protects your data from being leaked or stolen, reduces admin and IT support work, and makes it easier to meet audit requirements.
While RBAC isn’t perfect, it’s a much better model than arbitrarily deciding who should get access to which resources. If you have a good RBAC implemented, the hackers will get stonewalled as soon as they try to get outside the bubble of their hacked user’s role. This can drastically reduce the impact of an account compromise–especially in the case of ransomware.
Even if the affected user is in HR and has access to personally identifiable information (PII), the hacker won’t be able to encrypt or steal the Finance team’s or Executive team’s data.
RBAC also reduces IT and administrative load across the organization and increases the productivity of the users. IT doesn’t have to manage personalized permissions for every user, and it’s easier for the right users to get to the right data.
Managing new users or guest users can be time-consuming and difficult, but if you have RBAC that defines these roles before a user joins the network, it’s a fire and forget situation. Guests and new users join the network, and their access is pre-defined.
Implementing RBAC is proven to save lots of dollars for your company. RTI published a report in 2010, “The Economic Impact of Role-Based Access Control” which indicates there is a substantial return on investment in an RBAC system. For a hypothetical financial services firm of 10,000 employees, RTI estimates that RBAC will save IT $24,000 in labor, and employee downtime will save the company $300,000 per year. Automating the user access process will save you even more than that in IT labor reduction alone.
Lastly, companies can implement RBAC systems to meet the regulatory and statutory requirements for confidentiality and privacy because executives and IT departments can more effectively manage how the data is accessed and used. This is particularly important for financial institutions and healthcare companies that manage sensitive data and need to comply with privacy-by-design.
At the end of the implementation, your network will be vastly more secure than it was, and your data will be much safer from theft. And you get the other benefits of increased productivity for your users and IT staff. It’s a no-brainer if you ask us.
5 Steps to Implement Role-Based Access Control
The following steps are required to implement RBAC:
- Define the resources and services you provide to your users (e.g., email, CRM, file shares, cloud apps) .
- Create a mapping of roles to resources from step 1 such that each function can access resources needed to complete their job.
- Create security groups that represent each role.
- Assign users to defined roles by adding them to the relevant role-based groups.
- Apply groups to access control lists on the resources (e.g., folders, mailboxes, sites) that contain data
The good news is that you can largely take the guesswork out of this process. Varonis DatAdvantage provides insight into who actively uses data regularly, and who doesn’t, which can help inform role creation and assignment. You can also designate a data owner for any security group (i.e., role) or dataset to reduce the burden on IT.
This data owner, who has more context about their data than IT does, is responsible for access to their data in the long term, and can easily approve or deny access requests from the Varonis DataPrivilege interface. Varonis also provides modeling capabilities as you are assigning roles, so that you can see what happens if you revoke access to a folder from this role, before committing.
Once implementation is done, it’s imperative to keep the system clean. No user should be assigned privileges outside of their role permanently. DataPrivilege allows for temporary access to file shares on a per request basis, which doesn’t break the first rule. It will be necessary, however, to have a change process in place to adjust roles as needed.
And of course, you want to have regular auditing and monitoring on all of these critical resources. You need to know if a user is trying to access data outside of their assigned seat, or if permission gets added to a user outside of their role.
Examples of Role-Based Access Control
When looking to implement an RBAC system, it’s useful to have a basic example to guide you. Though RBAC can seem like a complicated approach, in reality, you encounter RBAC in many commonly used systems.
Perhaps the most obvious example of this is the hierarchy of a WordPress CMS set of user roles. In default WordPress systems, basic user roles are defined as:
- Super Admin: has all of the access of the other roles as well as site administration capabilities
- Administrator: has access to the administrative capabilities of a single WordPress site
- Editor: has access to publish and edit posts, including those of other users
- Author: has access to publish their own posts
- Contributor: can write their own posts, but can’t publish
- Subscriber: can only read posts
In other words, the WordPress user system ensures that all users have a role that does not grant them excessive rights, and protects data from being accessed by those users who don’t need this for their role. Though WordPress does not refer to this system as an “RBAC” system, it is precisely that.
Azure RBAC
Azure role-based access control (Azure RBAC) is an RBAC implementation for Azure. Azure Resource Manager enables you to implement the basics of Azure RBAC, and customize the system to your own needs.
Here are some examples of what you can do with Azure RBAC (source):
- Allow one user to manage virtual machines in a subscription and another user to manage virtual networks
- Allow a DBA group to manage SQL databases in a subscription
- Allow a user to manage all resources in a resource group, such as virtual machines, websites, and subnets
- Allow an application to access all resources in a resource group
Though Azure RBAC is a popular way for network admins to implement RBAC within their organizations, it is not the only option available. Here at Varonis, we generally recommend a hybrid approach that uses some elements of Azure RBAC but incorporates these into a broader security strategy.
Alternatives to RBAC
RBAC is just one approach to managing access for your networks, and it is not a replacement for a thorough and robust security policy. You could always use Access Control Lists, but those are typically difficult to manage and don’t scale well with large environments.
Attribute-Based Access Control
NIST defines Attribute-Based Access Control alongside RBAC as a potential solution for granting access rights. In short, ABAC seeks to match characteristics about the user (job function, job title) with the resources that the user needs to do their job.
So far, this system hasn’t gained much traction due to the challenges and setup required to implement this system on a wide scale. It sounds great in theory, but still lays a large part of the burden on IT to manage.
Our Approach
For many organizations, RBAC does not offer sufficient granularity to support data protection and regulatory requirements.
For example, cross-departmental data, shared by a small subset of users from multiple business groups should only be accessible to specific users in each role. RBAC limits the ability to achieve this outcome because you can’t grant access to only a selected number of people from multiple business roles. Applying a role-based group to a dataset would violate the principle of least privilege.
Numerous approaches have been adopted to resolve this issue, however with little success. In most cases, the attempts to work around RBAC’s insufficient granularity leaves the resource’s permissions in a state of over-permissive access, rendering it impossible to maintain and recertify for compliance.
For data that requires more granular protection, our philosophy is that permission management should be based on the content of the data and not the functional role of the users requiring access. Data-specific security groups should be created for these folders and direct permissions should be avoided.
For example, a services firm may have sensitive customer data that should only be accessible to specific individuals. Once the folders that contain this data are identified, permissions should be granted only to individuals in a content-specific group. Departmental groups should not be assigned permissions on the folder.
You can take this approach even further and create data-specific groups based on the level of access needed:
- SOX_ReadOnly
- SOX_Modify
The consumers of this Sarbanes-Oxley (SOX) data might include a select few users from the legal, finance, and compliance teams. Even fewer users have the need to modify the data. By creating resource-specific groups you reduce complexity, facilitate recertification, and can much more easily ensure a least privilege model.
A Final Word
RBAC is a powerful paradigm for controlling access to critical data and resources, and if implemented correctly can dramatically increase the security of your systems.
Keep in mind, though, that RBAC is not a panacea for cybersecurity. There are several methods bad actors will use to gain unauthorized access, and you should not rely solely on preventative controls like RBAC to protect your data. Detective controls such as a user-behavior analytics platform can help alert on unusual access behavior–even if it is authorized for a role–and prevent data breaches.
