6 Common Role Based Access Control (RBAC) Implementation Pitfalls

Role Based Access Control (RBAC) Implementation Pitfalls

Role based access control (RBAC) has been around for a long time, but that doesn’t mean it’s easy to implement. People prefer to talk about the benefits of this access control model, so today we are going to be contrarian and talk about six common RBAC implementation pitfalls. To learn more about this topic, you can access our 45-minute webinar on-demand: How to Effectively Use Role Based Access Control in the Real World.

Here are the 6 Common RBAC Implementation Pitfalls:

1. RBAC Absolutism 

This occurs when an organization tries to provision almost all user access through an RBAC model. Trying to do everything in a single model is nearly impossible and leads to an explosion in the number of roles. Ironically, this makes roles no better than managing access at the user level.

We recommend following the 80/20 rule and using roles in the following scenarios: 1) there are a large number of users that need access to the system / application, 2) there is a high turnover of users in the business role, or 3) the system or application is sensitive. Consider alternatives to manage access for the 20% of applications that don’t fit well into the RBAC model.

 

2. Auto-Magic Role Mining

Vendors may try to tell you that their product can analyze user data and spit out a mature role model, but the truth is there is no product on the market that can generate a truly useful, ready to use set of roles. There is no magic algorithm. The very best solutions provide useful insight into the current access assignments that people have and can suggest candidate roles. The biggest challenge is the underlying data quality, which has a severe impact to both automated and manual analysis. The key takeaway here is designing and implementing a role model that works for your organization will require manual analysis.

 

3. Implementing an inappropriate role model

If there’s no magic, then organizations have to come up with that role model on their own and there are definitely pitfalls in doing that. Implementing an inappropriate role model will cost money and frustrate efforts at implementation. Every organization is unique. There is no single best practice and every role model is a trade off of where organizations manage the complexity.

 

4. One and Done Role Engineering 

Change is constant both in organizational structures and IT systems. Creating, modifying, and removing roles is an ongoing effort to ensure the health of your RBAC solution. As the organization changes, new systems are added or removed, the role models have to be reviewed and updated to match. Organizations must plan for this ongoing effort and staff appropriately.

 

5. Implementing roles, but doing 100% permission-based access reviews anyway

Why use roles if they are not going to make your life easier? Organizations should separate the governance of role membership (who gets the role?) from the governance of role permissions (what access is granted by the role?). Then, focus efforts on minimizing the number of access management exceptions. Periodically ask, “Can we add a role for these users? Can we add access to a role? Do we have duplicate roles? Can we build a different role?” instead of doing direct-to-user assignments. With the direct-to-user assignments remaining, review them separately. Review the access exceptions, but not every assignment. Some of the more mature solutions on the market track what has changed (e.g. new role permissions, new users added to role) so that reviews can be more efficient.

 

6. Implementing roles without first having a solid IDM/IGA foundation

Without the processes, policies, and systems in place to manage identities well, a role implementation is not going to help much. Poor data quality, which is a result of an immature IDM/IGA system, will also doom RBAC efforts as will a lack of controls on how administrators manage user access.

Organizations can build the best RBAC solution in the world, but if they allow administrators to change group memberships and entitlements directly in Active Directory (outside of the IGA/ RBAC system), then there will be chaos for their users. Without the proper controls it’s the Wild West out there for your admins and end users! 

 

effectively use role based access control real world idenhaus consulting

Learn more about How to Effectively Use Role Based Access Control in the Real World in our newest 45-minute, on-demand webinar. In this session, we discuss the 6 common RBAC implementation pitfalls in depth, share recommendations, and highlight the following themes:

  • RBAC requires a disciplined approach and begins with detailed analysis of user access
  • Role mining is not the magic solution to all your access problems, it is simply one tool you have to help build roles
  • Governance and change management are key to defining standards, updating processes, and paving the way for a successful RBAC project

Click now to access “How to Effectively Use Role Based Access Control in the Real World”

 


An IAM Assessment is a quick, expert evaluation of your environment that identifies and addresses the most common issues organizations face when implementing a solution.

This is ideal for organizations that:

  • Are struggling to get their IAM solutions deployed
  • Have a misalignment between their processes and technology
  • Have an immature IAM solution with too many workarounds
  • Companies that want to accelerate their IAM programs

Click here to learn more about the IAM Assessment.

 

Follow @Idenhaus on Twitter and subscribe to our biweekly newsletter.

 


By going to work quickly to solve the most challenging cybersecurity and identity management problems, Idenhaus takes the pain out of securing corporate information and assets for companies that aspire to maximize their potential in this digital age. Click here to contact us

Share

Leave a Reply

Your email address will not be published. Required fields are marked *