Role Based Access Control (RBAC)

Role-based access control (RBAC) is an approach to access security that relies on a person's role within an organization to determine what access they have. A role is a collection of permissions, and users receive permissions through the roles they have been assigned. Permissions or access in this definition can mean many things, such as the ability to perform certain tasks, permission to view, edit, or create files, or holding superuser privileges on sensitive applications, to give just a few examples. This allows roles within an organization to remain relatively stable while users and permissions can change rapidly.

One of the main goals of RBAC is to grant employees only the access they need to do their jobs, and to prevent them from having access that is not relevant to them. A well-designed RBAC system also simplifies and streamlines the administration of access, by grouping sets of access in a logical and intuitive way, based on things like department, job function or title, region, or manager level. Grouping access permissions into roles provides a secure and efficient way of managing access, and helps keep things simple for administrators, certifiers, and the users requesting access.

Full versus Partial RBAC

RBAC is often talked about as a comprehensive system, but in actual practice it can be implemented as a partial solution. As you plan your organization's RBAC strategy, don't get too caught up in the idea that all access must be managed only through roles. A partial RBAC solution that manages some but not all access through roles can still provide a great deal of value. Trying to achieve 100% coverage for all access can easily result in a proliferation of roles, including the creation of roles which may have only one person in them. This can ultimately undercut the goal of making access easier and more efficient to manage.

Some job profiles are particularly well suited to an RBAC approach, such as jobs that involve a high degree of standardization, high turnover, seasonal employment, or a need for particularly rapid onboarding. Other job profiles, such as those in an IT department that involve highly privileged and specialized access, may not be good candidates for RBAC.

Implementing RBAC in IdentityIQ

IdentityIQ provides many features and tools that support implementation of RBAC: role editing and modeling, role mining, entitlement analysis, certifications for role membership and role composition, and workflows for governing changes.

Here are some key IdentityIQ concepts you should be familiar with as you plan your implementation of RBAC:

Maintaining Roles

An RBAC system is successful only to the extent that the roles it relies on are current, relevant, and appropriately scoped. In addition to monitoring who has a role, you have to monitor what is in a role. Within your organization, the types of available access can change, job descriptions can change, new applications can get added, etc. People in your organization must have confidence that roles are meaningful and current, or they may stop using them.

IdentityIQ offers some features to help you maintain your roles.

  • The Role Editor Page supports creating and editing roles. You can configure roles such that a change or edit to the role will trigger a workflow for approvals and notifications before the role is promoted into production.

  • The Role Composition Certification allows the role owner (or others) to review the access that makes up the role. This certification is an essential part of a role program, for keeping roles accurate and current. See How to Perform a Role Composition Access Review.

Best Practices for Defining and Creating Roles for RBAC

As you set about defining the roles for RBAC, you need a clear picture of the business roles in your organization, and of the entitlements. Part of this exercise is determining where to start implementing RBAC. It may not be realistic to try to set up RBAC for your entire organization all at once, and where you start will depend a lot on your type of business and your organization.

Here are some best practices for defining and creating roles:

  • Include business experts in the planning. It's essential to work with your organization's subject matter experts – managers, IT and security teams, human resources, application owners, et cetera, who have a clear idea of what their team members do and how people use various applications – to help you determine which segments of your organization are most in need of RBAC. These business experts can also help identify patterns of access, define job responsibilities, and evaluate access options.

  • Monitor the big picture. In addition to the business experts who will provide input on the needs of specific departments or applications, you also need someone with oversight over the entire role hierarchy to spot organization-wide patterns and see the big picture, in order to help you avoid role proliferation or duplication. There may be some overlap of access needs among disparate teams, so in order to avoid duplication of roles, you will need someone keeping track of the overall, top-level view of your role model.

  • Familiarize yourself with IdentityIQ's tools for role development. IdentityIQ provides a number of tools to help with role creation: Entitlement Analysis , Role Mining for Business and IT Roles, and Role Modeling all support analysis of the data which has been onboarded into IdentityIQ, and can create roles based on that analysis. You can export role mining data and ad hoc queries into a report format for your analysts to evaluate.

  • Work with a meaningful entitlement catalog. Before developing your roles in IdentityIQ, it helps to have a meaningful entitlement catalog from which to build roles. The Entitlement Analysis feature is one of the most useful ways of identifying patterns of access and spotting "red flags" or outliers with singular access assignments. The usefulness of the analysis depends on an entitlement catalog that completely and correctly represents the access you want to manage.

  • Use meaningful names and descriptions for business roles. When you create business roles, keep in mind that it's important to use meaningful names and descriptions for the roles. These are available to people requesting and reviewing access and can be very valuable information to help users understand what each business role is for, and what it includes.

  • Define your IdentityIQ team appropriately. The people who analyze and define the roles and the access that goes with them do not have to be the same people who work in IdentityIQ to set roles up. Choose the right team of people for working on the role model in IdentityIQ so that your definition and implementation efforts are secure and efficient.

  • Create a process to approve role creation. Plan for an approval process for role creation. Roles can be set up to trigger workflows for approval and notification. Putting new roles, or changes to roles, through an approval process protects against role proliferation/duplication.

RBAC Project Tips

Here are some pointers based on the experience of customers, partners, and SailPoint solution architects who have implemented RBAC in the field. While your own project requirements may vary and will depend on your business needs, these are things to consider as you plan your RBAC strategy:

  • Take a pragmatic approach. Think of RBAC as an ongoing program, not a project. Don't expect to achieve 100% coverage of all access via RBAC as you implement it. A comprehensive RBAC solution could take months or even years to complete. It is realistic and acceptable to implement RBAC in steps or phases.

  • Know what you're trying to accomplish. Are you trying to make certifications easier? If so, your primary focus will be on evaluating and organizing current access. Is your goal to make access requests easier? In that case, you may want to focus on the Lifecycle Manager side of IdentityIQ, using roles to help users more easily find and select the roles they want to request.

  • Look for groupings of role types. Use the IdentityIQ features such as Role Mining and Entitlement Analysis to identify patterns and groupings of access and role types. This will help you avoid role proliferation.

  • Enforce least privilege. Define roles so that you don't give people access they don't need. Setting up roles for the least privilege is a best practice for reducing security risk, both from malicious intent and from user errors.

  • Expect exceptions to RBAC. In most enterprises, it is difficult or impossible to entirely avoid individual entitlements, especially in areas of highly specialized access needs, such as an IT department. Don't assume you have to force all entitlements and all access models into roles.

  • Make roles reusable. If only one person in the whole organization has some particular role, maybe that access shouldn't be managed via a role. Make sure the roles you define are applicable to groups of people; otherwise your role model will be unwieldy and will not deliver the goals of efficiency and simplification.

  • Involve the business experts. People within your organization who know the business are often the best resource for what the access patterns are and how should you structure your roles.

  • Test and verify your roles. Roles need as much testing and verification as other functionality – maybe more. If you define roles sub-optimally at the outset and put them into production, you can end up with a lot of users who lack the access they need or who have more access than they should. There can be a big cleanup effort if you roll out a role structure that has not been set up and tested properly.

  • Develop processes for role maintenance. Roles evolve, and you need to keep them up to date. Plan for periodic review and certification of your roles to make sure they're still current and accurate. You should also plan for how to retire roles when they are no longer needed. Regular certification of role composition and role membership should be part of your ongoing RBAC strategy.