Role-based Access Control: Why it’s often not enough to manage the APPocalypse/App Assignment Process

This article will help you understand the basics of RBAC and how it can help your team better manage access across your company resources and applications. You’ll learn more about the basics, the benefits, and the challenges of RBAC. You’ll also find out the difference between RBAC, ACL, and ABAC, what's possible, and how to implement a successful RBAC strategy for your organization.

IT teams worldwide use RBAC to secure their company information. In a nutshell, RBAC limits or restricts employee access to specific parts of the company network, such as apps, tools, files, or data. It’s one of four types of access control that companies use to manage employee access and permissions. The other three types are mandatory, discretionary, and rule-based. RBAC is a popular choice because of its simplistic approach. In theory, RBAC prevents employees from accessing anything that isn’t relevant to their jobs. That’s why it’s “role-based.”

Think about it this way: A sales representative may need access to certain bits of information to get the job done, but not others. For example, IT departments can create a “sales representative” role that designates which apps and permissions the person has and limits access to everything else. Then, any time a new sales rep is hired, that person is assigned the predefined role and the access privileges that go along with it. Simple, right? Maybe. But we’ll get to that later.

RBAC is an easy way to manage the thousands of apps, documents, programs, and tools that companies use. RBAC is based on three types of access control: Role assignment, role-based authorization, and permission authorization. First, IT determines the resources and actions a person needs to do their job. Second, they use that information to create a role. Third, they set standard permissions, either technical or administrative, underneath that role that are automatically assigned to anyone with that position.
‍
Those permissions grant access to system functions, documents, and other information employees need. When employees are hired, they are assigned one of the IT-created roles, giving them access to the pre-defined list of privileges. Tools, such as Microsoft Azure AD and OneLogin, allow IT teams to set RBAC privileges for the organization.

RBAC sets a standard for all users rather than taking a person-by-person approach, making it both replicable and scalable as the organization changes or grows. This predefined method means employees get access to the tools they need faster and with less effort from IT. In addition to helping employees become productive faster, RBAC ensures least privilege access. Least privilege means that employees only have access to what they need when they need it–and nothing more. As soon as their role within the company changes or they separate from service, their access to various tools is revoked.

RBAC differs from attribute-based access control (ABAC) because it’s based on employee roles rather than user characteristics, such as environment, action types, and more. ABAC attributes tend to fall into four categories: subject, action, object, and contextual. These attributes cover things like age, clearance, and department as well as the action being taken, the object being accessed, and other relevant environmental attributes.

ACL, or access-control list, technology is a user-specific list of permissions that determines which users have access to specific files, systems, processes, and resources. An ACL also determines which actions that user can take. Unlike RBAC, which clusters users together and determines access privilege based on their role, ACL is done at the user and resource  level. Typically, ACL works better for individual users while RBAC works better on a company level.

RBAC is an incredible tool to enact company-wide security and compliance. However, more users, more roles, and more apps all make setting up and maintaining RBAC more complex. To ensure compliance, IT teams have to ensure the least privilege access is maintained, even when users change roles or leave–and that is no small task. When IT teams can’t keep up with the changes it results in overprovisioning. This means employees keep access to tools or permissions long after they stop using the app, which can create huge security issues.  

In addition to overprovisioning concerns, RBAC also has its limitations. For example,  it can’t grant one-time permissions if exceptions need to be made. And, even with workflow automation and provisioning tools, like Okta or BetterCloud, RBAC doesn’t eliminate IT tickets for access requests.

Setting up an RBAC system for your organization takes time–but it can be well worth the effort. First, take inventory of all company apps, resources, documents, and tools that require access permissions. Next, group your users into roles that make sense for your company. For example, sales representative, customer service, and human resources are all great starts–and you can create more granular roles, if needed. When creating roles think about what level of access a user would need in a particular role. From there you can set permissions for each role and then group your users into the roles you created. Even after initial setup, be sure to go back and periodically audit both the roles and permissions because those will likely change as the company grows.