Until recently, the most popular approach to Authorization was Role-Based Access Control (RBAC). This solution involves creating a set of roles that define all job descriptions and functions within an organization and then assigning users roles which determine what they can access (e.g., file, network, application, a field on web page), and which operations they can perform.
When using RBAC, system administrators control what users can do with specific IT resources, and which areas they have access to. It is simple to implement since there are only three basic principles to keep in mind; roles are based on a “Role Assignment”, “Role Authorization”, and “Permission Authorization”. However, RBAC is not without its issues and limitations. One of the main problems is that it is not an automatic process, meaning that it needs to be painstakingly managed and often involves significant manual intervention.
For example, let’s imagine your organization chart has been finalized along with your list of employees and their titles, and you’re all set to roll out your RBAC plans. You have all the roles laid out in front of you, and you’re confident that they are well defined and mapped out with correct reporting lines and spans of control. Suddenly, the VP of Marketing mentions that there are people in their department that need access to certain resources, shared folders, and specialized apps that are only available for roles in other departments. You can’t say no to the VP, so you check your mappings and try to find an additional set of roles that meet the requirements. But it’s not that simple, as there’s no exact match. So what do you do? Create an additional role and just apply it to all employees with similar needs? Often, this may be your only alternative as the cannibalization of existing roles may be strictly forbidden under internal security policy, as doing so dilutes the effectiveness of the RBAC model.
RBAC is a fundamentally flawed methodology for managing user identities and access permissions. Its inherent weakness lies in its unwieldy nature, reliance on manual input, and its constant need for maintenance. Dynamic organizations need dynamic access controls. All of these factors combine to create an insecure IAM structure.
"Most role-based access control projects fail due to [a] lack of laying the groundwork," says Christopher Paidhrin of PeaceHealth. "Each organization needs to evaluate whether they're ready for role-based access. A lot of work goes into effective role-based access management, and a lot more needs to go into the analysis process... before management can be effective [sic]."
If VP of Marketing access request scenario sounds familiar, it is because it happens all too often. Role Explosion happens when the level of granularity needed for your access control is too detailed. Role Explosion is difficult and costly to manage and makes access control confusing and complicated,reducing the access control effectiveness. Additionally, there are several other issues created that need to be monitored carefully when adding more roles to your access control deployment. One of these problems occurs when a user has too many roles assigned to them and then changes jobs or responsibilities within the company. IT system administrators either forget, or even make a conscious decision to leave old roles in place. The quantity of roles can lead to security holes that are often too difficult to find and close.
As a system administrator, it is important to understand the risks to your system. Conducting a security risk analysis with a proactive risk prevention plan is essential for RBAC deployment. RBAC is data focused; data is categorized relevant to the organizational structure and that leads to access control role definition. If your organization is reactive to security risks, RBAC may not be the optimal way of securing access to your network data. RBAC requires that you have intimate knowledge of the security layout of your company and of how permissions are being granted before deployment. Once deployed, it is hard to react to changing security threats and risks. So be careful and “measure twice, and cut once” with your RBAC policies. In an era of increased scrutiny of security effectiveness due to changing data privacy and protection regulations, this dilution of the security model significantly increases the residual risk of data breach, with significant consequences both financial and reputational.
Yes, at the start of your RBAC deployment, you knew exactly what roles you needed to define, and who they needed to be assigned to. But, it’s now a year later and the organization has grown. More people have joined the company and in the rush of onboarding all the new people, the organization charts and job definitions have not been updated or clearly defined.
This is where RBAC will become difficult to maintain and manage. These “dead ends” limit your deployment’s scalability and may require a redesign to get back on track. Even worse, with potential time pressures, you may need to implement a “work around” solution that in the long run can contribute to the problem rather than rectify it. Almost like a game of IAM whac-a-mole, you’re constantly addressing new problems.
This more often than not is cycle of major rework every 2-3 years, if at all, to remediate a lack of incremental management of the role taxonomy in-line with the changing needs of the organization’s structure, which remains dynamic and reactive, as it must, to react to customers’ needs and more agile business models in a digital world.
Your company has been using computers and collecting data for a long time but has never really needed any kind of access control as part of the organization security policy. If you need to plug the holes and decide that RBAC is the way to go, you may find the need for the duplication of servers and other infrastructures which support RBAC cost prohibitive and adding complexity. You will also need to consider cost and risk with migrating users to the new systems while phasing out the older ones. Most of the time migrations have a variety of difficulties and unforeseen challenges, and resulting in security holes in both systems along with other costly defects, such as unplanned downtime and data loss.
RBAC alone is a great way of managing access to your data and system resources, if you never plan on reassigning an employee or working with partners. However, no organization structure remains static, making RBAC methodologies cumbersome in a dynamic business environment. We often see companies setting up integrations between their HR system, Active Directory and IGA for syncronized role creation and ongoing lifecycle management of roles. These integrations can not only be expensive, but fragile, difficult to maintain, and ultimately not generating the desired outcomes.
But not all hope is lost. Integrating RBAC with other types of access control methodologies allows you to create a robust, fine-grained access control policy. Contact us for more information about how PlainID can help you implement a more granular form of access control.