Role-based access control (RBAC) is best suited for coarse-grained authorization. This is often used for many of the assets in an organization that should be secured but are not highly sensitive, are not considered a core asset, and do not pose a compliance risk. They generally have to be accessed by many people or only by members of a specific department. There may even be highly sensitive assets but those that require access to them can be grouped into roles and do not have strict requirements on where, when, how, or why they can access them.
You don’t need the flexibility of attribute-based access control (ABAC), or policy-based access control (PBAC) as it’s also known, role-based access will suffice. If, however, authorization requirements become more complex with many conditions and objects, you have to look beyond RBAC and implement policy-driven authorization.
What is a role in RBAC?
A role is a selection of permissions that determine the access a user is granted based on their duties in an organization. In its simplest form, it can be connected to a role, a department, a region, etc. RBAC enables role subsets to be created when, for instance, different people within the same employer roles need to access different information.
The intuitive RBAC Model
The RBAC model is simple and intuitive at a base level. Let’s consider a corporate accounting department in the UK with the roles of Clerks, Accountants, and Account Managers. Three roles that can access different types and levels of data. Using RBAC, this would mean:
- UK Clerks – can view level 1 UK data.
- UK Accountants – can view and edit level 1 and 2 UK data.
- UK Account Managers – can view, edit, and approve level 1, 2 and 3 UK data.
Ever-expanding Roles
Role requirements expand quickly when using RBAC. Continuing with our example, every country with a corporate accounting department will have the same situation. If it’s 20 countries we will have 60 roles.
If the US office is the headquarters they may need access to all country data as well as the US, therefore we need to create new roles:
- US Clerks – can view level 1 data in all countries.
- US Accountants – can view and edit level 1 and 2 data in all countries.
- US Account Managers – can view, edit, and approve level 1,2 and 3 data in all countries.
So far so good. If...
If level 1 data includes employee corporate card expenditure. Department managers will need to sign off on their employees’ transactions. If there are 20 departments in each country with corporate cards. 20 individual roles per country have to be created to authorize this action.
- Department Manager X – can view and approve department X’s corporate card transactions.
- Department Manager Y – can view and approve department Y’s corporate card transactions.
That’s 20 x 20 new roles, equaling 400. It’s easy to see how the number of roles can quickly expand and get out of control, resulting in role explosion.
As the number of roles grows exponentially in an organization when using role-based access control it’s not uncommon to experience segregation of duty (SoD) failures resulting in toxic combinations. In such a case, department managers, for instance, may be able to approve their own corporate card transactions.
Combining RBAC and ABAC
With many companies utilizing RBAC in some form, combining it with ABAC can provide the optimal solution for database security. Role-based access control can handle coarse-grained authorization, where roles can be directly linked to data and purpose of use. For more fine-grained requirements, attribute-based access control can be used. When applied, this hybrid solution will provide a much more dynamic approach, based on corporate policies.
For example:
- Department Manager X can view and approve department X’s corporate card transactions, except their own, which must be approved by a Senior Manager.
- US Clerks can view level 1 data, during office hours, in all countries except General Data Protection Regulation (GDPR) related content from EU countries.
Key considerations for implementing RBAC
If you are thinking of implementing role-based access control and don’t require a dynamic approach, RBAC is ideal as long as you remain aware that, as authorization complexities grow, you may need to evolve from RBAC to ABAC.
- Analyze how much sensitive data you have and map who needs access to it and why. Some people want access to information even though they don’t need it. Many times, people have access to information that they don’t know about. A thorough analysis will enable you to clean up entitlements, start from scratch, and get it right.
- Involve those concerned. Don’t second guess who needs to access data, speak to the people who are involved, and assign role ownership to staff members. You may be surprised by what data employees need to access in their roles. Always double-check with somebody else in the organization before assigning access rights – see analyze.
- Clean up your data as well as the entitlements. You may have sensitive data that you don’t require. Take the opportunity to remove it.
- Use familiar roles when naming. You may be the person implementing RBAC but you won’t be the one auditing it, and you may not be updating it or overseeing a transition to ABAC later down the line. Make it intuitive where possible for administrators.
- Test the roles to make sure there is no segregation of duty, toxic combinations, or compliance issues. Also, to ensure people can get to the data they need to work, collaborate and innovate.
- Follow-up. Authorization is a constantly moving target. New data is constantly being created, stored, and shared. New roles are also being created and people are moving, joining, and leaving the organization. Make sure you review entitlements regularly.
Axiomatics and RBAC
Axiomatics extends RBAC with ABAC providing a fine-grained approach to authorization. With Axiomatics' solutions, organizations can achieve a fine balance between security and usability, effectively mitigating risks associated with unauthorized access and data breaches.