30 Jan Modernising data access from RBAC to ABAC
One of the main concerns over data expansions is security. Mark Semenenko, Director, Solutions Architecture at Immuta, looks at how data access can be modernised.
Many enterprises are focused on building data-driven digital-first businesses. Yet problems around data control and access, paired with the difficulty when integrating technological innovations, has meant that in many instances that transition has been a slow and painful one.
That was one of the many findings of a recent Immuta-sponsored IDC InfoBrief into data uses among enterprises. The report outlined the positive – that almost nine in 10 CEOs want to make their business a data-driven ‘intelligent organisation’ within the next three to four years.
Yet it also highlighted how data access issues remain the most frequent and tangible bottleneck to achieving this target – with two-thirds struggling to leverage their data because they lack the right kind of data access governance.
In particular one of the main breaks on data expansions is security. Enterprises work against a backdrop of ever increasing concerns about how data is harvested and used, especially in the Middle East and Europe. What’s required are management systems rooted in ethical data structures that have both privacy and security at their core.
Too often companies tend to be excited about the potential of data and forget to think holistically about how it needs to be used. If executive teams forget about the management of data upfront they can be creating all kinds of issues in the future.
Is RBAC a universal solution?
Of those who have looked at data management systems, the key issue has been their reliance on RBAC (Role-Based Access Control). RBAC, invented in the ‘70s, is a static system that requires pre-computed decisions regarding roles. Updates to the policy must be manually input into the system to account for its existence, as well as removed when it no longer applies.
Data teams managing access through RBAC implicitly predetermine what the users have access to by adding them to a role, then explicitly determine the privilege associated with each role.
While RBAC can work efficiently for smaller projects, as they scale they soon begin to understand its limitations. It is a person-intensive system that needs to be constantly reviewed. Different people within enterprises need access to data for different reasons, and while it may be appropriate for them to have access to some data, privacy and security concerns ought to mean that they shouldn’t have access to other data.
The reality is that execs can put in a request for data and then are at the mercy of the data management teams as to when they are to receive it. Deadlines can be missed and opportunities lost.
It sounds complex, and it can be. Say you wanted a policy to restrict access to a specific region for each role in your organisation. If you had 50 regions, you would have to write 50 policies — one for each — and also maintain 50 roles for each policy. Also if any users had access to more than one region, you would need to create a policy for those scenarios. On top of that, if any of your regions changed, you would need to modify all roles related to those regions! Now you can see how RBAC can be hugely inefficient and cumbersome.
Trust nothing by default
There is also the growing awareness of the concept of zero trust in companies. This functions under the premise of ‘trust nothing by default’ – in other words, access to one entrance should not include access to all entrances, and access at a certain time should not automatically guarantee access at a later time.
Under zero-trust, verifications, such as through authentication (proof of identity) and authorisation (rights granted), are performed continuously. Users’ credentials are checked for validity at every entry point and each time they request entry, even if they have been trusted at that point or others in the past.
Zero trust has been part of the inspiration behind another method of data access – ABAC or (Attribute-Based Access Control). ABAC is a dynamic runtime decision system that decouples user metadata from the policy decision.
ABAC employs a query-time decision to identify attributes at the moment of execution, rather than relying on pre-computed role configurations. It empowers organisations to move from a default ‘no’ to a default ‘yes,’ enabling more teams to gain value from their data faster, while still adhering to zero trust principals.
This gives the system a significant advantage over RBAC in that data access is given only for the correct purpose by the correct person.
Creating an ABAC-led system
Setting up ABAC-based systems requires data teams to think carefully about their data and who should be able to access it. It drives them back to the first base of what data is, how it should be used and what security and privacy concerns there are.
There are several different types of attributes that businesses will need to define to enable the evolution from RBAC to ABAC systems. These include:
- User attributes: information about a data user, including name, title, department, and permission level.
- Object attributes: information about the data itself, including creator, type, creation date, and reason for sensitivity.
- Action attributes: information about what is being done to the data by the subject, including reading, editing, approving, and deleting.
There may also be environmental attributes to bear in mind, namely contextual information about the data, including location, purpose, date of access, and level of organisational threat.
To define ABAC more concretely, let’s revisit our regions example. Rather than having to build 50 policies and roles — or more, depending on whether users have access to more than one region — you can instead treat attributes as dynamic variables. This means with ABAC, you can replace those 50 roles with a single policy, like so: “only show rows where region IN (@user-attribute:region)”, where @user-attribute:region is the dynamic attribute that contains their list of regions. If a new region is added, the policy remains unchanged, granting access to a new region is as simple as granting a new attribute to the users or groups who should have access.
The list of variables at your fingertips allows data managers to separate who the user is, what they are doing, and what policy should be dynamically applied at runtime, rather than predefining all policy up front by conflating who has access to what based on roles, as with RBAC.
Migration to ABAC
I think one concern that organisations using RBAC have is that the migration to ABAC could be costly and time-consuming, whilst requiring a fundamental overhaul of their data management system. But this really isn’t the case. You do not have to throw away existing roles to switch to ABAC. You can simply leverage them in a new and more powerful way — dynamically.
Crucially, modernising to ABAC does not require a massive shift in how you tag users with metadata. With ABAC you already have all the roles, but you are now empowered to build policy separated from the roles in a dynamic and variable-based way.
Ultimately data teams will need to invest time in setting ABAC systems up. But once they are operational they are markedly easier to maintain, and more scalable, than RBAC ones.
Setting ABAC systems up enables organisations to anticipate data security needs. Working with legal and compliance teams to understand regulations and enacting plans to address regulations like HIPAA compliance (in the US) and GDPR compliance (in Europe), as well as contractual obligations and industry standards, among other considerations.
While legal and compliance teams can provide guidance on the substance of these requirements, ABAC can bridge the gap between company policy and the data teams who implement safe and consistent protection measures.
Ultimately, ABAC not only gives organisations a competitive advantage in accessing and utilising their data, it also delivers the building bricks of the data management systems of the future.
Sorry, the comment form is closed at this time.