Role-based access control (RBAC) is a method of restricting network access based on the roles of individual users within an enterprise. RBAC ensures employees access only information they need to do their jobs and prevents them from accessing information that doesn't pertain to them.
A role in RBAC language typically refers to a group of people that share certain characteristics, such as:
Departments
Locations
Seniority levels
Work duties
With a role defined, you can assign permissions. Those might involve:
Access. What can the person see?
Operations. What can the person read? What can the person write? Can the person create or delete files?
Sessions. How long can the person stay in the system? When will the login work? When will the login expire?
All RBAC systems work like this. But the National Institute of Standards and Technology defines four subtypes of RBAC in case you need a bit more flexibility.
Flat: All employees have at least one role that defines permissions, but some have more than one.
Hierarchical: Seniority levels define how roles work together. Senior executives have their own permissions, but they also have those attained by their underlings.
Constrained: Separation of duties is added, and several people work on one task together. This helps to ensure security and prevent fraudulent activities.
Symmetrical: Role permissions are reviewed frequently, and permissions change as the result of that review.
These roles build upon one another, and they can be arranged by security level.
Level 1, Flat: This is the least complex form of RBAC. Employees use roles to gain permissions.
Level 2, Hierarchical: This builds on the Flat RBAC rules, and it adds role hierarchy.
Level 3, Constrained: This builds on Hierarchical RBAC, and it adds separation of duties.
Level 4, Symmetrical: This builds on the Constrained RBAC model, and it adds permission reviews.
An employee's role in an organization determines the permissions that individual is granted and ensures lower-level employees can't access sensitive information or perform high-level tasks.
In the role-based access control data model, roles are based on several factors, including authorization, responsibility and job competency. As such, companies can designate whether a user is an end user, an administrator or a specialist user. In addition, access to computer resources can be limited to specific tasks, such as the ability to view, create or modify files.
Limiting network access is important for organizations that have many workers, employ contractors or permit access to third parties, like customers and vendors, which makes it difficult to monitor network access effectively. Companies that depend on RBAC are better able to secure their sensitive data and critical applications.
Types of RBAC
The NIST model for role-based access control defines the following RBAC categories:
Flat RBAC: Each employee is assigned at least one role, but some can have more than one. If someone wants access to a new file/resource/server, they need to first obtain a new role.
Hierarchical RBAC: Roles are defined based on seniority levels. In addition to their own privileges, senior employees also possess those of their subordinates.
Constrained RBAC: This model introduces separation of duties (SOD). SOD spreads the authority of performing a task, across multiple users, reducing the risk of fraudulent and/or risky activities. E.g., if a developer wants to decommission a server, they need approval from not only their direct manager, but also the head of infrastructure. This gives the infrastructure head a change to deny risky and/or unnecessary requests.
Symmetric RBAC: All organizational roles are reviewed regularly. As a result of these reviews, privileges may get assigned or revoked, and roles may get added or removed.
Implementing Role-Based Access Control
Role-based access control allows organizations to improve their security posture and comply with security regulations. However, implementing role-based access control across an entire organization can be complex and may result in pushback from stakeholders. To succeed in your move to RBAC, you should treat the implementation process as a series of steps:
Understanding your business needs—before you move to RBAC, you should run a comprehensive needs analysis to examine job functions, supporting business processes and technologies. You should also consider any regulatory or audit requirements and assess the current security posture of your organization. You may also benefit from other types of access control.
Planning the scope of implementation—identify the scope of your RBAC requirements and plan the implementation to align with the organization’s needs. Narrow your scope to focus on systems or applications that store sensitive data. This will also help your organization manage the transition.
Defining roles—it will be easier to define your roles once you have performed the needs analysis and understand how individuals perform their tasks. Watch out for common role design pitfalls like excessive or insufficient granularity, role overlap, and granting too many exceptions for RBAC permissions.
Implementation—the final phase involves rolling out the RBAC. Do this in stages, to avoid an overwhelming workload and reduce disruption to the business. First, address a core group of users. Start with coarse-grained access control before increasing granularity. Collect feedback from users and monitor your environment to plan the next stages of implementation.
Benefits of RBAC
There are multiple benefits to using RBAC, including:
Improving operational efficiency. With RBAC, companies can decrease the need for paperwork and password changes when they hire new employees or switch the roles of existing employees. RBAC lets organizations quickly add and change roles, as well as implement them across platforms, operating systems (OSes) and applications. It also cuts down on the potential for error when assigning user permissions. Additionally, with RBAC, companies can more easily integrate third-party users into their networks by giving them predefined roles.
Enhancing compliance. Every organization must comply with local, state and federal regulations. Companies generally prefer to 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.
Giving administrators increased visibility. RBAC gives network administrators and managers more visibility and oversight into the business, while also guaranteeing authorized users and guests on the system are only given access to what they need to do their jobs.
Reducing costs. By not allowing user access to certain processes and applications, companies may conserve or more cost-effectively use resources, such as network bandwidth, memory and storage.
Decreasing risk of breaches and data leakage. Implementing RBAC means restricting access to sensitive information, thus reducing the potential for data breaches or data leakage.
Best Practices for Implementing RBAC
Implementing a RBAC into your organization shouldn’t happen without a great deal of consideration. There are a series of broad steps to bring the team onboard without causing unnecessary confusion and possible workplace irritations. Here are a few things to map out first.
Current Status: Create a list of every software, hardware and app that has some sort of security. For most of these things, it will be a password. However, you may also want to list server rooms that are under lock and key. Physical security can be a vital part of data protection. Also, list the status of who has access to all of these programs and areas. This will give you a snapshot of your current data scenario.
Current Roles: Even if you do not have a formal roster and list of roles, determining what each individual team member does may only take a little discussion. Try to organize the team in such a way that it doesn’t stifle creativity and the current culture (if enjoyed).
Write a Policy: Any changes made need to be written for all current and future employees to see. Even with the use of a RBAC tool, a document clearly articulating your new system will help avoid potential issues.
Make Changes: Once the current security status and roles are understood (not to mention a policy is written), it’s time to make the changes.
Continually Adapt: It’s likely that the first iteration of RBAC will require some tweaking. Early on, you should evaluate your roles and security status frequently. Assess first, how well the creative/production process is working and secondly, how secure your process happens to be.
Types of Access Control: RBAC Alternatives
Other access control mechanisms could serve as alternatives to role-based access control.
1. Access Control List (ACL)
An access control list (ACL) is a table listing the permissions attached to computing resources. It tells the operating system which users can access an object, and which actions they can carry out. There is an entry for each user, which is linked to the security attributes of each object. ACL is commonly used for traditional DAC systems.
2. RBAC vs ACL
For most business applications, RBAC is superior to ACL in terms of security and administrative overhead. ACL is better suited for implementing security at the individual user level and for low-level data, while RBAC better serves a company-wide security system with an overseeing administrator. An ACL can, for example, grant write access to a specific file, but it cannot determine how a user might change the file.
3. Attribute-Based Access Control (ABAC)
ABAC evaluates a set of rules and policies to manage access rights according to specific attributes, such as environmental, system, object, or user information. It applies boolean logic to grant or deny access to users based on a complex evaluation of atomic or set-valued attributes and the relationship between them.
Difference Between RBAC and ABAC
RBAC | ABAC |
An Access control approach provides access rights depending in the user roles | An Access control method that grants access rights to the suer by sing a combination of attributes together |
Consider the role to access rights | Consider user, resource and environment attributes to grant access rights |
RBAC tends to not scale well because as more people and resources are added, more roles are created to define more detailed permissions. | If you work at a big company, ABAC is probably the right move. Yes, it’s more complex to set up, but in the long run, it’ll be easier to maintain. |
If you have less complex form of access control then you will need to RBAC | If you need more detailed permissions or to look at variables that fall outside of roles (like device type, location, or time), you’ll need to use ABAC. |
The Tech Platform