Role-based access control (RBAC) is a fundamentally flawed methodology for managing user identities and access permissions in an organization (see the previous blog post on this subject). RBAC’s inherent weakness lies in its unwieldy nature, reliance on manual input, and its constant need for maintenance. All of these factors combine to create risky and porous systems.
The solution to the mess caused by RBAC is a policy-based access control system (PBAC). According to a paper by the National Institute of Standards and Technology (NIST), entitled A Survey of Access Control Models: “PBAC is an emerging model that seeks to help enterprises address the need to implement concrete access controls based on abstract policy and governance requirements.”
The problem with RBAC is that it is not an automatic process, meaning that it needs to be managed manually. By nature, roles are a static connection to authorization objects, and so any changes that need to be made (adding, removing, and updating a user’s access rights) must be done by IT managers. Keeping on top of who should have access to which resources can be a complicated and confusing process. So when a user requests new permissions, the IT manager has to check to make sure that the user is allowed that access. The danger is that whenever the “human element” is involved, errors are easily introduced.
The guiding principle of PBAC is that by setting policies, user profiles and environmental conditions simply have to match the criteria for allowing access. Because PBAC supports runtime authorization, it is dynamic, and has the ability to allow changes to be made in real-time. There is no need to maintain repositories of constantly changing user roles, to add or remove individual users from specific groups, or to constantly maintain authorization to resources when employee statuses and responsibilities in the company change. Because PBAC is an automatic process, the risks involved with manual intervention are mitigated.
As companies scale, their identity management systems need to scale with them. New products, projects, and departments in a company necessitate adding more and more roles and more and more layers of permissions. But managing these roles soon becomes impossible. You need to define roles for every project and the resources within those projects, and then apply them to the relevant people. Then you need to make sure always to keep the roles relevant and up-to-date, taking into consideration changes to employee responsibilities, new employees joining the company, and outgoing employees. With so many moving parts, errors and omissions are bound to occur.
Coping with the role-explosion phenomenon can be overwhelming. Sometimes it’s just easier to ignore company security policies and industry standards because of the inordinate amount of time and effort required to maintain a clean identity management system in an RBAC environment.
Managing identities is straightforward with PBAC. Authorization to access a resource, or a particular record within the resource, is moderated based on specific traits—attributes. The attributes that PBAC is interested in are those of the user who is attempting to access the resource (the subject), the resource itself (the object), and the time and place where the object is being accessed (the environment):
Viewed holistically, these attributes can be used to set the policy requirements that would enable access to data and resources.
Under PBAC, the issue of scalability becomes moot because the number of actions needed to enforce access controls is substantially reduced, and it is all automatic. Blanket policies can be set using instructions such as “Only auditors can view the sensitive data associated with their assigned projects” – a policy easy to apply and manage in terms of handling large numbers of users and stores of data which automatically fit the policy.
Security-fatigued IT departments often purposely bypass the layers of logins, passwords and other security features that build up over time in ever-increasingly complicated systems. To prevent this “insider creep,” where an employee has had different roles and access levels in an organization, companies must enable automatically applied policies. This ensures that the correct access policies are assigned and never bypassed because PBAC policies are automatically applied to every user.
PBAC supports environmental conditions as part of access policies, something lacking in RBAC. For instance, the policy might restrict highly sensitive files to be viewed only on desktop computers from within the corporate network. Furthermore, RBAC requires IT managers to remove permissions for each role - just removing the user is not enough. This is not necessary for PBAC systems, so IT managers don’t need to invest time removing these permissions. PBAC also eliminates the risk of IT managers ignoring the process completely because it is a time-consuming and user-unfriendly task.
RBAC is inherently complex, and so the specter of role explosion in an RBAC environment looms large as a serious security and management problem. A robust PBAC approach protects your organization from many types of risk and helps you to easily comply with government requirements.
The PBAC methodology also makes it effortless to comply with governance, risk management and compliance (GRC) requirements for identity management including segregating data, access management, preventing unauthorized users from accessing sensitive data, controlling access creep, and preventing authorized users from accessing sensitive data in a risky manner.
Maintaining an RBAC system for managing user-authorization and access is unsustainable, manual process that does not scale. On the other hand, PBAC systems take advantage of the benefits of RBAC and build upon them to create an advanced paradigm that uses policies and automatic processes to manage identities and access rights in growing companies.
Ask for a demo to see how PlainID can leverage your existing RBAC system using a comprehensive PBAC approach.
© All Rights Reserved 2024 PlainID