I’ve made a very good living implementing RBAC solutions over the years and preaching the virtues of role-based security. In fact, I wrote an extensive white paper on best practices for RBAC implementation just a couple of years ago. However, I’m slowly coming to the painful conclusion that RBAC no longer meets the business needs of the modern enterprise.
I know this is a controversial position that will likely attract some fire from some of my peers in the IAM geek-space, so allow me to explain.
Role based security is a concept almost as old as the microprocessor itself. The basic principle of RBAC is simple enough. By aggregating entitlements into meaningful roles, the complexity of user-permission relationships is theoretically abstracted from the business.
There’s one major flaw with that theory. By design, role compositions and assignments tend to be static, but we now live in a world where privilege needs are not.
The current standard for RBAC has remained mostly unchanged since it was first introduced by Ferraiolo and Kuhn in 1992. While there have been several enhancements to that model over the years, such as the unified NIST standard in 2000 and support for attribute-based roles in 2010, most modern RBAC implementations look exactly the same as they did twenty years ago.
RBAC was conceived in an era when user-system interactions were predictable and I.T. environments were homogeneous. In those days, we mostly used corporate-owned devices to access systems behind a corporate firewall. You knew with a measure of certainty that you would need to access the same systems in the same way with the same device every day. But that paradigm doesn’t describe a world of mobile devices, “anywhere/anytime” connectivity, identity convergence and hybrid cloud systems.
Another issue we’ve seen with roles over the years is with the complexity of role hierarchies in increasingly heterogeneous I.T. environments. Inheritance is a great theoretical concept, but in large dynamic organizations where privilege needs are constantly in flux, it can create an enormous operational burden. The impact of every role change, whether the change impacts membership or composition, must be carefully evaluated to avoid unpredictable effects on end users.
Even in the most successful RBAC implementations, it is rare for more than 70% of user-permission relationships to be covered by roles. Maintaining a reasonable level of coverage requires strict operational governance in order to avoid role explosion while keeping pace with organizational changes, the introduction of new systems and updates to existing systems. Put another way, RBAC does not lend itself to agility, which is a major problem for large organizations with complex I.T. infrastructures and dynamic user populations.
For these reasons, I’ve come to the conclusion that RBAC as we know it must be killed in order to save it.
I know what you’re thinking. This is going to be a pitch for ABAC. Well yeah, kinda sorta, but it’s more complex than that. I don’t view the ABAC vs. RBAC question as an either/or proposition. In fact, I believe that if properly designed, the two models can be complimentary rather than exclusive. In order to save RBAC, we must therefore enhance it with the characteristics of ABAC.
ABAC provides the ability to grant permissions by evaluating not only static identity attributes such as job title, but contextual factors such as location, device and risk. This feature alone makes ABAC far more dynamic than RBAC, since privilege assignments become dynamic rather than static. When you log into the corporate network using your company laptop in the home office, you may get a completely different set of privileges than when you log in from your personal iPad in a coffee shop.
Another major advantage of ABAC is the ability to confer negative permissions, which is to say that access to a system or operation can be denied based on the evaluation of static and contextual attributes.
The XACML standard offers a universal syntax for expressing ABAC policies. The lack of a corresponding standard for RBAC means that every IAM product implements roles in a slightly different way. Some products support session-aware roles, others don’t. Some products support attribute-based roles, others don’t. Some products support constrained hierarchies, others don’t. This means role modelers and engineers are often restricted by the features of whatever IAM solution their company has decided to buy.
Does this mean there is no longer any place for roles? No, far from it. What I am suggesting is that we abandon complex role hierarchies and limit automatic role assignments to coarse-grained birthright privileges such as “Employee” and “Contractor”. Elsewhere, roles can still be used to represent bundles of entitlements where those entitlement groupings are known to be stable, but instead of statically assigning roles to users, assignment should be driven by context-aware ABAC rules.
Rethinking RBAC to incorporate the contextual features of ABAC is, in my view, the only way to save it.
So what does this all mean in practice? Let’s take the example of a system administrator working at a large corporation. As an employee, he automatically gets a birthright role of “Employee”. This grants him access to the corporate network, the email system and the employee intranet. That doesn’t need to change. In the RBAC model, however, he also has a “Production Support” role that allows him to access a bunch of production servers. Because that role is statically assigned, he can access those servers with any device from any location at any time. In the new world, we can create an XACML policy that only grants him the “Production Support” role if he is using a company-owned device, is within the United States and is working off-shift. So when he tries to make changes to a production server while using his iPad in a Paris coffee shop in the middle of the day, he will be blocked.
Right now, surprisingly few IAM offerings support XACML although I expect this to change as more organizations gravitate towards more dynamic ABAC frameworks for entitlements management. Fortunately, very few organizations have successfully implemented RBAC, which lowers the barrier for adoption of a hybrid ABAC/RBAC model.
No comments:
Post a Comment