The Monster Called RBAC

Dean Wiech (Profile)
Wednesday, September 26th 2012

In the world of identity and access management, Role Based Access Control (RBAC) is gradually becoming a frequently used term. Dictated in part by legislative and regulatory norms, an increasing number of organizations wish to manage and assign all access privileges across the network in a structured way. This is possible through the use of RBAC software. So how can companies achieve an adequate implementation of RBAC across their entire organization?

Organizations are faced with two pitfalls when it comes to assigning and revoking access rights. To assign rights, they often create a copy of a colleague’s account, also known as “template user.” This creates the risk that new employees are provided with unwarranted access to business applications and systems.

Added to which, organizations do not pay sufficient attention to revoking access rights when they create copies of existing user accounts. After all, their most important consideration is enabling new employees to do their job rather than checking for excess access rights. Dictated by standards, IT auditors and unnecessary licensing costs for suites including Microsoft Visio, Projects and Adobe CS, organizations have come to acknowledge the importance of a responsible handling of authorizations.

HR System as Basis

RBAC is a technique for implementing authorization management across organizations. This technique involves assigning rights on the basis of RBAC roles rather than assigning access rights to individual users. These roles in turn comprise the department, function, location and cost center associated with an employee.

Although organizations acknowledge the importance of RBAC, they are cautious about implementing this technique. RBAC has undeservedly gained the reputation that it involves a large effort – particularly in terms of management overhead – as well as lengthy and complex implementation cycles. In fact, RBAC is viewed as a monstrous entity. This misunderstanding is the result of an incorrect approach to its implementation.

In the past, the people who have been responsible for RBAC implementations were under the illusion that 100 percent of the staff could be molded into a single RBAC role. More often than not, there are as many functions in an organization as there are employees. This results in an endless list of roles in relation to resources, so that assigning an RBAC role to each employee becomes a lengthy process. Another question is whether everybody and everything has to be included
in RBAC. Isn’t RBAC exclusively needed for user groups, which require a careful authorization set-up from the point of view of risk management, regulations and efficiency?

In any case, RBAC can be handled differently -- quicker and with less complexity.

RBAC as Lego Blocks

The advice for RBAC is to use a bottom-up and stacked approach. This approach involves the creation of a foundation that can be expanded at a later stage. After all, the majority of employees need access to standard applications such as Microsoft Office and Outlook. For a large number of employees, access rights on the organizational level (logging in, word processing, e-mail) and departmental level (access to the department share and departmental applications) can be assigned right away. In this context it is important to determine the top 50 combinations of department and function for active employees.