Which access control model that uses access based on a users job function with an organization?

Role-based access control is defined as a set of rules that govern and restrict user access to operations and objects based on their identity, intent, and session attributes. With the access control market growing to $12.8 billion by 2025, this technology will be increasingly important for enterprise security. This article explains the meaning of role-based access control with examples, breaks down its key components, and recommends best practices for implementation. 

What Is Role-Based Access Control?

Role-based access control (RBAC) is a set of rules that govern and restrict user access to operations and objects based on their identity, intent, and session attributes. According to the U.S. National Institute of Standards and Technology (NIST), the concept was formalized in 1992 by information security researchers David F. Ferraiolo and D. Richard Kuhn. Today, role-based access control is among the most popular access control mechanisms due to its cost advantages, versatility, and efficiency. 

The global access control market is expected to be worth $12.8 billion by 2025, according to ResearchAndMarkets, and RBAC forms a major part of this. 

Examples of role-based access control from major vendors 

To understand how role-based access control works, let us look at a few examples of the access control mechanism adopted by large industry providers and security vendors. 

• Microsoft Azure: Azure RBAC is built on the Azure resource manager offering. It lets you assign a role to a user, user group, service, or managed identity, including built-in roles and custom ones. For example, Azure RBAC has common roles like the owner, contributor, and reader pre-built into the system. You can limit what a role can do by defining a scope of actions. Azure also supports “deny assignments,” which means you can specify what a role cannot do in addition to what it can. 
• IBM Spectrum Protect Plus: IBM offers role-based access control as part of its cloud security solution. You can define users, roles, and resources (e.g., a virtual machine) that have permission to access a set of services. IBM lets you choose from various services like applications, identity management rights, new role creation, backup activities, etc., that RBAC can protect. 
• Google Cloud: Google provides RBAC for its Kubernetes engine. You can define a role or a cluster of resources that can be given permission to access different objects and operations. This capability is based on the Google Kubernetes Engine, and you will need to write code for assigning roles, unlike IBM Spectrum Protect Plus, which has a graphic user interface (GUI) RBAC feature. 
• Amazon Web Services (AWS): AWS has a different take on RBAC. It opts for attribute-based access control (ABAC) instead of traditional RBAC. Every user and session is assigned a tag that acts as an attribute. Permissions are given based on the attributes of a user instead of a role, which allows different users and different roles to access different operations and objects depending on their specific session context. 
• Auth0: Secure access provider, Auth0, offers two services for implementing RBAC: authorization core and authorization extension. There are subtle differences between the two – the former supports permission fetching via application programming interfaces (APIs), while the latter supports role-assignment for groups. Auth0 lets you create a scalable and reusable RBAC architecture. 

These examples illustrate the many ways you can give and deny users access to enterprise resources, assets, and operations in a dynamic manner. 

See More: What Is Network Access Control? Definition, Key Components, and Best Practices

Key benefits for enterprises 

There are several reasons why role-based access control has emerged as a popular methodology for permissioned security. In fact, users, IT administrators, and the organization gain from implementing RBAC. 

• Key benefits of role-based access control for users: It makes logging into and accessing enterprise resources a much more convenient experience: 
• Users don’t have to request permission or wait for approvals every time they require access. 
• The user experience (UX) is more intuitive as one does not need to navigate through systems irrelevant to one’s role. 
• Users do not risk non-compliance by inadvertently accessing (or worse, sharing) sensitive information. 
• Key benefits of role-based access control for IT: Daily efforts and compliance workloads for IT administrators are reduced when you implement RBAC: 
• IT personnel do not have to respond to numerous access requests originating across the company. 
• As daily iterative workloads are reduced, there is less risk that IT will make a mistake when assigning permissions. As a result, complex or exceptional access requests are handled more effectively. 
• Role-based access control logs user access and generates an audit trail, which significantly reduces month-end and year-end workloads for IT. 
• Key benefits of role-based access control for the organization: Role-based access control follows a dynamic architecture that isn’t limited by static user identity: 
• The organization can scale fast as the RBAC model adapts to new organizational structures, more employees, etc. 
• RBAC is based on reusable business rules, which translates into major cost benefits. A seminal report by NIST found that RBAC could lead to an annual operating benefit of $43.71 per employee.
• The organization can generate an audit trail and stay compliant, avoiding regulatory fines and penalties. 

In other words, role-based access control is a key pillar of enterprise security. It ensures that only authorized users can use your information, resources, processes, and security mechanisms dynamically adapt as new years are onboarded. 

See More: What Is Privileged Access Management (PAM)? Definition, Components and Best Practices

Key Components of Role-Based Access Control

Role-based access control is based on key components that will determine the interactions between users and the resource or process they are trying to access. While the list of components will vary across organizations, here are the six foundational ones you need to remember: 

Key Components of Role-Based Access Control

1. Users

The user is the entity asking for access. The user may or may not proactively request access – for example, an access request may be initiated the moment a user logs in. Also, users aren’t necessarily human individuals. For RBAC, services and computing entities like a virtual machine or an end-device can also be considered as a user. In a scenario where the device tries to rewrite its registry contents as part of an upgrade, the device is considered a user and requires RBAC-approved privileges. 

2. Roles

Roles are what determine which privileges and permissions can be assigned to a user. Roles typically exist in hierarchies, where a superior role is associated with more privileges than a lower role in the hierarchical structure. For example, a document owner might be able to do whatever they want with a document (edit, share, save offline, etc.), while a contributor may edit without the right to share the document. In this scenario, the owner role is superior to the contributor role. 

In the context of RBAC, roles are an aggregate function of multiple user traits – their job designation, session attributes like the device from which they are logged in, their login credentials, and so on. RBAC solutions can include pre-built roles that you can assign to your users and support custom ones. 

3. Operations

Users can request access for two things – operations and objects. 

Operations refer to any activity or process carried out in a computing environment. For example, changing system configurations and closing active processes are two of the most common operations we perform in a typical computing environment. Depending on the IT landscape, operations can be highly complex with significant security fallouts, requiring powerful protection. 

4. Objects

As mentioned, users can also ask to access an object, a static file, a data set, a website, or any other asset. There is a key difference between operations and objects: while performing an operation changes the system state, object access does not. This makes unauthorized object access more difficult to detect, which is why you need role-based access control. RBAC ensures that the user’s role is relevant to the object in question and that the user is authorized to access it. It also maintains access logs, including the date and time of the last access. 

5. Permissions

Permissions are at the heart of role-based access control, without which it would not be able to operate. It is a set of business rules that specify which operations and objects a role can access. For example, if a person with employee ID A12 is the user and is assigned the contributor’s role, permissions refer to the list of actions that the user can perform in that role. As a contributor, they may be able to access the document (an object) and modify the contents (an operation) but not be allowed to open embedded links (objects) or delete the document (an operation). 

In other words, permissions define the relationship between a role and the relevant operations and objects. 

6. Sessions

Sessions refer to the duration for which a role’s interaction with operations and objects will last. RBAC is triggered right at the beginning of a session and remains functional until the session ends. If a user opens a browser on the company network and tries to access a page on the intranet, the session begins as soon as they open the browser. The RBAC system will check the user’s role, grant access based on permissions, monitor the operations and objects accessed, and maintain a log until the user closes the browser. This entire period of interaction is called a session. 

See More: Why Identity Orchestration Remains the Missing Piece in the Access Management Puzzle

Top 10 Best Practices for RBAC Implementation and Management in 2021

As enterprises adopt new digital technologies, role-based access control will be crucial. Here are ten best practices to guide RBAC implementation and strengthen security as you scale. 

Top 10 Best Practices for RBAC Implementation and Management in 2021

1. Start with an end-to-end IT inventory

You can’t protect what you can’t see. An end-to-end IT inventory will reveal the full extent of hardware and software systems at your enterprise, their relationships and dependencies, and the roles to which they are most relevant. As an enterprise matures and legacy systems are modernized, IT components are often left hidden in the sprawl. These pose a security risk and may be accessed by unauthorized entities. Therefore, an inventory is the first step to RBAC implementation and must be conducted at regular intervals. Also, make sure to assess your systems after a major organizational change like a merger. 

2. Have an identity and access management system in place

While identity and access management (IAM) isn’t a prerequisite for RBAC, it makes implementation much easier. RBAC will have a ready directory of identities from which to fetch user role information. IAM also streamlines user management as new employees enter the organization, existing employees exit, and partner landscape changes. RBAC can be integrated with IAM so that there is a single pane of visibility and access logs are mapped to user identities. 

3. Use the least-privilege principle to define roles

The principle of least privilege indicates that a user will access the bare minimum of functionalities (both operations and objects) from the minute they enter a computing environment. To take a simple example, least privilege on a PC desktop would mean that a user can only move the cursor around and select different elements without opening any files, executing applications, or changing settings. Every operation and object access beyond the least privilege has to be granted permissions by RBAC. Every role can have its own unique baseline for least privilege – for instance, least privilege will differ from an IT admin role and an IT process user role. 

4. Design a custom RBAC model for your organization

Role-based access control can become more of a hindrance than a convenience if improperly executed. User role and access requirements in a healthcare organization will be different from a bank or a school. Within the education sector, a local administrative board and a community college will have different IT landscapes. Therefore, tailor the role-based access control model as per your industry, scale, and necessary regulations. The configurations for all six components that we discussed (i.e., users, roles, operations, objects, permissions, and sessions) must be customized accordingly. 

5. Outline a framework for role inheritance in a group

Managing roles for heterogeneous user groups can be a complex affair. For example, you can have a group called marketing which includes another group called design, which, in turn, has users across different levels of privileges. If a user from this group tries to access an operation or object, which takes precedence: the user level permissions or the group level permissions? These questions must be answered through a detailed framework for role inheritance, where the relationship between the multiple layers of role levels is defined. 

Also Read: Top 10 Privileged Access Management Solutions in 2021

6. Prepare for overlapping and conflicting roles

Similar to vertical role inheritance, you can have horizontal overlaps in roles. A user can be assigned multiple roles depending on the business scenario and the session context. These roles can have overlapping or even conflicting permissions and privileges. In case of overlap, there is a risk that the user will end up with more permissions than intended, causing a security vulnerability. Role conflicts will prevent the user from doing their job and create exceptions that add to IT workloads. You can address this by properly configuring the RBAC, denying permissions as needed, and enforcing separation of duties. 

7. Rigorously test before implementing

Errors and gaps in your RBAC can have severe fallouts for the enterprise. At the very least, improperly configured permissions could hold back access for even authorized users and interrupt business processes. Over-provisioning of privileges, on the other hand, could lead to a security vulnerability. That’s why it is crucial to test role-based access control before implementation. Set up a small-scale replica of your actual IT environment with a representative mock-up for every user, role, operation, object, and permission set. Run through every possible session scenario to check if RBAC is working as expected. 

8. Define ownership for user lifecycle management

User roles in a typical enterprise will constantly evolve in response to organizational changes, new and completed projects, changes in the vendor landscape, and similar business scenarios. An owner will ensure that user roles are not only created when necessary but are duly retired and decommissioned once the need for the role has ended. This best practice is crucial as it prevents the misuse of obsolete but existing user roles that were simply overlooked by IT. 

9. Update roles as the organization evolves

As your organization evolves, elements of your IT infrastructure (in this context, operations, and services) will also change. As a result, user roles must be revisited at regular intervals. Static roles will cause problems for end-users as they try to access newly introduced IT resources but find that they do not have the requisite permissions. As per least privilege principles, users are barred from any access unless stated otherwise. Ensure that you state otherwise and explicitly mention new permissions when updating roles so that your IT infrastructure isn’t underutilized. 

10. Once mature, explore cutting-edge technologies like AI and blockchain

This best practice applies specifically to organizations with a mature role-based access control system. Emerging technologies like artificial intelligence (AI) and blockchain could transform RBAC by making it more adaptive and even more efficient. 

Companies like SailPoint already use AI for access modeling, so you can easily update your roles to meet changing business requirements. And the last few years have also seen a lot of research on blockchains for role-based access control, such as the paper titled User authentication using blockchain-based smart contract in role-based access control by researchers from the Indian Institute of Technology (IIT) and another one titled Context-Aware and Dynamic Role-Based Access Control Using Blockchain from the University of Pisa. These mark the next frontier in the evolution of access control. 

See More: Why Adaptive Authentication Should Be a Core Component of Zero Trust Networks

Key Takeaways

Role-based access control has emerged as the preferred alternative to discretionary access control (where only specific human individuals enjoyed access privileges) and mandatory access control (where a security clearance was needed for access to all systems at a specific level). RBAC is adaptive, scalable, and cost-effective in the long term. Here are the key takeaways to remember from this article: 

• Role-based access control maintains enterprise security by governing users, roles, operations, objects, permissions and sessions. 
• It benefits users, IT administrators, and the organization, saving you an estimated $43.71 per year per employee. 
• An IT inventory is a must-have before implementation, and IAM is also highly recommended.
• Role-based access control will vary depending on your industry, scale, and regulatory jurisdiction. 
• Without testing, unclear ownership, and regular role updates, you could risk a patchy user experience and severe security vulnerabilities.
• AI and blockchain could revolutionize role-based access control in the next few years. 

As digital transformation accelerates, role-based access control can help organizations to keep up in a changing environment without having to constantly overhaul their access protocols from scratch. 

What are your thoughts on the rise of role-based access control as a security staple? Tell us on LinkedIn, Twitter, or Facebook. We would love to hear from you!

Which access control model that uses access based on a users job function within an organization?

Which type of access control depends on the job function of the user?

Which access control model provides access based on the position an individual holds in an organization select one?

Which access control model uses the function of a subject in an organization?