RBAC: How to Determine Roles and Access Requirements

The concept behind Role-based Access Control is one that is so simplistic in theory that it would seem to provide the exact answer to many security challenges organizations face. Essentially, RBAC is a method of regulating access to computer systems or network resources based on roles of individual users within an enterprise. This allows for an easier way to deploy a universal policy across and organization by basic distinctions such as “contractor,” “manager,” or “user.”

The concept, which was first defined as a formal methodology in 1992 by David Ferraiolo and Richard Kuhn from the National Institute of Standards and Technology, is that the privileges that are outlined for each defined role within an organization’s hierarchy is directly mapped to the systems used for accessing the IT resources they need to do their jobs. Since that time, role-based access control has become the standard requirement for many government controlled compliance regulations, including HIPAA, Sarbanes-Oxley,

How-to-define_user-rolesAt the core, there are two key principles of role-based access control:

Access if Granted Based on the User’s Role Rather Than Their Individual Identity

Roles Define Access Rights and Privileges based on job authority and responsibilities within a job function.

Sounds great, right? Well, yes. But much more goes into determining how various roles and their associated permissions should be defined than one would think. It is an extraordinarily complex process that requires planning and knowledge on how various aspects of a business should work in connection with one another. In this blog post, we will take some time to share some insight we have gained on how to define access roles within your organization.

How to Determine User Roles and Access Requirements: What You Should Do First

Plan First

Before attempting to define users or roles within your organization, you need to take a step back. Think about how you want Role-Based Access Control to function within your organization.

When planning your RBAC, basic things to consider are:

  • Which IT resources will be accessed using RBAC
  • Which Users will be using RBAC once the process is implemented

Start With Governance

Once you have a clear idea of what you want the project to accomplish, identify the key stakeholders and their respective responsibilities will be throughout the project. In most organizations, these stakeholders will include: human resources, IT, departmental managers, executive leadership, and legal. This governance team will be responsible for many aspects of the RBAC creation and will be essential in determining user roles and requirements.

Collaborate about Role Definition and Creation

When it comes to access control, almost every organization has difficulty with assigning responsibility to any one group of people or department. Yet, having a thorough collaboration process to gather both a high-level and granular look at role needs across the organization is an absolutely must. One of the easiest ways to create any technical or security policy that gets ignored upon implementation is to ignore the needs of the end users.

Analyze How your Company Already Operates

You should check wither or not any role or access definitions are already in place within your organization. If you don’t currently have any access controls, a great place to start would be a human resources database. This would allow you to gather information tied to employee name, job function, department, and functions.

How to Determine User Roles and Access Requirements: The Practice of the “Least Privileged”

When restricting permissions, the principle of least privilege is an important design consideration. The idea is that a user should only be able to access the specific information they need in order to do their job. Essentially, The Principle of Least Privilege states that every module of a system, such as a process, user, or application, should have the least authority possible to be able to perform its job.

While this may seem like an overreaction, it in fact is the best way to limit access. Consider each of the items listed above as a threat to your organization. Now, understanding that possible liability, what information do you want them to have?

With this in mind, as you proceed with determining user roles and permissions, you will likely have to ask yourself several times if something that a user or group of users has access to now is something that they actually need.

How to Determine User Roles and Access Requirements: Role Engineering

Role Mining

Manually determining a set of roles for an organization is an extremely labor intensive project. When you are looking at an organization that is very heterogeneous with thousands of users, identifying individual permission gaps can be nearly impossible. When you are looking to define roles for the first time or refresh definitions that already exist, role mining can be extremely beneficial. Role mining allows IT admins to understand the complexity of roles that are already in place within the organization and the hierarchy that applies roles to individual users.

Gather Requirements

Each member of the governance team that we outlined above should put thought into all of the processes and systems that need to be mapped out in order to determine the different roles that will be defined. Interviews should be conducted with the different departments to understand what information they need access to, who they use the data, and how their processes currently operate.

Role Engineering:

Role Engineering is the process of taking the data that you gathered in the interviews with various users and role mining and creating role definitions from that data.

In order to this effectively, sometimes it can be helpful to actually sit and map how to determine user roles on a whiteboard or Excel sheet. While this is overly simplistic, we suggest you follow this process:


  1. Map out the IT Resources you wish to include in RBAC
    1. Define the specific security needs of that system
      1. Does it contain sensitive information/ PII?
      2. Will it need to be accessed remotely?
    2. Define the specific use cases of that system
  2. Map out Tasks and Scenarios as they would happen to determine what systems, and users, and processes are included to complete the business task
  3. Map Roles to Resources and Operations
  4. Look for potential ways to consolidate role definitions
    1. Does the user role for accounting and hr have the same basic requirements?
    2. How about marketing and pr? Are their systems and needs the same?
  5. Assign Roles to the Users


Limit the Number of Roles: How to Avoid Role Sprawl

Remember that once this is deployed someone will have to manage it. That means every role and every rule has to be tracked. Attempt to limit the number and types of users as much as possible. Role sprawl – or an alarming number of new roles created for very limited number of use cases – is a leading reason why RBAC policies become too difficult to manage. As the number of roles increases, the overall implementation will become more difficult to manage and have a higher likelihood of producing errors.

If you are finding yourself struggling with whether or not to create a new role for a use case, consider asking yourself these questions:

Is this new role necessary?

Can an existing role be modified to encompass this new use case?


Orion’s Suggestion?

Don’t Feel Like You Have to Include Every IT Asset in the RBAC – There are some IT assets that are so limited and controlled, adding them to the resources list for an RBAC program would only complicate your role definitions. For this reason, we suggest determining what those systems are, and opting to leave them out of the overall RBAC policy. Several outliers exist in all organizations would be a great example of this.

Example: A Legacy IT System – A Legacy IT System such as a server would only need to be accessed by a IT Admin or group. So, an IT Admin, who would have very similar permissions as another business manager, would need this where as the other departments would not.

So just remember, if you are getting hung up on one application that is not fitting within the constraints of role definition you are working out, consider if it would be a good candidate for being left out of the RBAC system.

By | 2017-03-24T13:47:43-04:00 November 19th, 2015|Security|

About the Author: