What is Role Based Access Control (RBAC)?
Role Based Access Control (RBAC) is an approach to controlling access to various resources based on a person’s role within the organization. Rather than granting access to ten different systems based on the work profile, a set of access privileges is granted to the distinct “Roles”; depending on the work profile, a person is tagged to one or more “Roles”. Conceptually, RBAC is very much intuitive and easy to understand.
From the Access Administration point of view, RBAC provided one of the most cost-effective access models. Several organizations have operationalized their Access Administration Operations by adopting the RBAC model. RBAC also provides a powerful option for implementing the least privilege principle, which is key to achieving optimal security.
In theory, Role Based Access Control (RBAC) seems like the perfect access model that can represent an ideal organization. But, in practice, organizations are fluid and must undergo changes to be competitive, survive, and thrive. This is where we start to see practical challenges in keeping a tight grip over the model as the organization starts to evolve. Key practical challenges with RBAC are:
Roles keep evolving: To remain competitive in the global market, the Organization needs to constantly refine its products and service offerings. This evolution heavily impacts operational processes supporting the products and services. This in turn needs constant org-re-org of the Operational organization. As the organization changes, new roles evolve and the redundant roles disappear. Hence, roles are never constant in an organization. Although RBAC is scalable in theory, the amount of changes is difficult to manage and maintain. Forcing the model on the organization is not viable for a business to operate. It would then be the model adjusting to the business. The unabated roles’ expansion leads to the “Tail Wagging the Dog” kind of operational nightmare. Thus, fitting a model with a set of roles is a point in time endeavour, requiring ongoing efforts to keep the lights on.
RBAC lacks contextuality: We have moved out of brick and mortar kind of office set up to more of a hybrid set-up. Apart from job function, other considerations determine a person’s access to the system. For example, two sales executives under a team leader might have the same role based on their job function. But, based on the territory they serve, access levels might need to be more than just the role consideration. One salesperson serving Mumbai can’t be given access to potential customer data for Bengaluru and vice-versa. Hence, pureplay RABC becomes very hard to implement in such a scenario. Another example: a team that gets the work assignment based on job rotation. A person assuming the maker role could be a checker tomorrow and vice versa. To fit in this business scenario, we might end up granting both maker and checker access to the whole team. This violates the basic rule of security, i.e. the least privilege principle. Hence, bringing context to the access decisions is very important from practical business aspects.
Limited scalability: In theory, RBAC is scalable. As the organization launches new products and services, we can go on adding new roles. But, in practice, it is easier said than done. New IT applications launched to support new products and services might not support RBAC. When we try to force-fit the model, we end up in heavy customizations leading to technical debt. Even if the new applications support RBAC, scalability is not automatic. It requires operational adjustments and constant amends to the access model impacting the economies of scale.
No access model is foolproof. RBAC is one of the most tried and tested access models. The knowledge worker work set-up is slowly moving away from brick and mortar to hybrid set-up; technology changes are no more breaking news, rather a routine; cloud adoption is catching up fast. All these ongoing changes impact access management considerations. Hence, it is time to rethink how well can we make the best of already made investments without ignoring the vulnerabilities getting introduced due to the suboptimal access model. As the thought process is moving to the Zero Trust concept, contextuality becomes extremely important. Hence, RBAC needs refinement.
Commenti