Has complexity and the Cloud killed Role Based Access Control finally?
Opinions expressed are solely my own and do not express the views or opinions of my employer
Remember when computers were simple — like really simple? I don’t, but my dad used to tell me stories of how in them days, he’d a’ been glad to have a laptop, all he had were mechanical calculators and the painstaking task of punching IBM punch cards.
“But you try and tell the young people today that… and they won’t believe ya’.” Monty Python, Four Yorkshiremen
Back then, access control was also simple — whoever had physical access, could essentially do whatever they liked, but only one person at a time could do anything useful, as punch cards were entered sequentially. Essentially that person only had one function — punch card operator.
It’s all CRUD anyway
Seemingly inevitably the amount of data being processed on computers increased exponentially, computers themselves have become more complex, and the number of simultaneous users have increased hundredfold — as a result, access control lists (ACL) were implemented to address the increased complexity of multiple users sharing a computer and potentially interacting with the same data. ACL’s are a form of digital access control that allows or disallows the ability to create, read, update or delete (CRUD) data based on the user’s identity. At its most basic, the intent of ACL’s is to prevent someone reading or modifying someone else’s data.
Everyone has a role
Eventually, as applications became more complex and more applications were developed capable of doing an enormous variety of tasks simultaneously, it became apparent that more complex access control was needed to allow users to do certain things but not other things based on a business need or role. This became particularly important as workflows became digitized. As a result, a new model of access control referred to as Role Based Access Control (RBAC) was developed.
The use of roles to indicate authorization allowed users to be allocated to different groups with specific access rights based on their needs. Typically this involved creating a comprehensive set of standard roles based on job descriptions and functions within an organization and assigning users to those roles.
“Is it a boy or a girl?,” asks the new mother…To which the obstetrician answers: “I think it’s a bit early to start imposing roles on it, don’t you?” Monty Python, the Meaning of Life
This is actually quite challenging to get right as you a) want to reduce the number of roles assigned to users (Note this is intended to be a many-to-many relationship) b) ensure they effectively manage segregation of duties (SoD) and c) still maintain the principle of least privilege. This becomes increasingly hard to maintain as organizations change all the time. As a result most roles are seldom updated promptly, if at all and where they are, the temptation is always to simply add a little more into existing roles; rather than redesign the roles completely.
“It’s only a wafer-thin mint, sir…” Monty Python, the Meaning of Life
If you do get the roles right, then RBAC is pretty easy to implement, particularly for developers as they only need to determine the user’s role when authorizing access. As a result, RBAC has been the goal for many organizations for over 15 years.
Unfortunately in that time, applications and the amount of data has continued to increase exponentially, and the need to protect data, micro-services, and APIs has evolved, particularly with the increasing use of the cloud. On the other side, the default limit on the number of roles that can be assigned within AWS is limited to 1000 per account. This exponential growth in complexity, externally imposed limit on roles and the inevitable change within every organization, has made the number of roles and tradeoffs required to control the seemingly infinite number of privileges across an organization unmanageable.
So, is RBAC dead?
Today’s access control requirements are frequently too complex to meet using only a single data point of role membership. For example, there may be cases where we want to provide access to an approved identity, but only where approved privacy consent is in place, where certain security posture requirements are met (for example: the device posture for a user or non-interactive settings for service account and source IP address) and where an approved support ticket is in place…. Yeah — just a bit more complex than just checking whether the identity is assigned to a role. This need for increased complexity in making authorization decisions is especially true in heavily regulated industries (Banking, Healthcare, Government) that process a lot of Personally Identifiable Information or PII, but also specifically when managing cloud infrastructure.
These types of fine-grained access control requirements (i.e. based on more than someone’s role membership(s)) are simply too complex for RBAC and as a result many have argued that RBAC is indeed dead.
‘E’s not pinin’! ‘E’s passed on! He has ceased to be! ‘E’s expired and gone to meet ‘is maker! Monty Python, Dead Parrot
It is firstly worthwhile to remember that most technologies never truly die — they tend to simply end up as legacy because it may simply be too costly to implement and maintain newer approaches, than the current approach.
But as the best framework for managing access management across an entire organization, it is obvious that RBAC is dead! It just isn’t scalable or manageable enough on its own to be used successfully in a modern organization.
I believe there is still a role (pun intended) for roles — particularly where accounts can be grouped into mutually exclusive and easily understandable roles, and particularly where they can be used to cleanly enforce segregation of duties and least privilege policies. As a result, I anticipate that RBAC will not disappear completely nor end up as part of a legacy stack of technology, but steadily become only one of many different user, activity, resources and data attributes controlling access being utilized to control access.
Attributes are already there
Unlike RBAC models, you should be maturing your access control models to be able to utilise additional information or attributes that can be determined without further human intervention. This could include information and attributes about the identity, pre-existing manually defined roles, the account in use, actions performed by the identity in the past, context (such as time, device and location), resources (such as a record’s sensitivity), the data subject (such as privacy consent) and much more. One of the attributes I’m particularly interested in seeing gain more prominence is determining whether a user has performed a similar action previously.
The use of multiple pre-existing and up-to-date attributes (particularly whether an action was performed historically or when last it was performed) allows fine grained authorization decisions to be made on the privilege, rather than solely on the access level. This significantly reduces the risk of assigning users into over privileged roles when they only need to perform a single task. The externalized authorization and policy engine required to make this effective, also allows more dynamic changes to be made to the access model when needed without fundamentally redesigning the roles and applications.
Is it that simple?
Nothing about identity and access management is ever simple, but what the evolution of access control over time teaches us is that things change.
As a result, my view is that the best access models is one which can be kept updated easily and dynamically change as more information comes available, particularly information about previous actions.
Regardless of how you adapt your access controls going forward, hopefully this post has at least convinced you to look at your implementation of RBAC and the roles. Hidden away in those roles is undoubtably one role or machine account with enough excess privilege to bring your company to its knees.
Check in again soon for another blog post specifically focused on overprivileged machine accounts particularly in the cloud.
