Dictated in part by legislative and regulatory norms, an increasing number of organisations wish to manage and assign all access privileges across the network in a structured way. This is possible through the use of Role-Based Access Control (RBAC) software. So how can companies achieve an adequate implementation of RBAC across their entire organisation?
Organisations are faced with two pitfalls when it comes to assigning and revoking access privileges. To assign privileges, 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, organisations do not pay sufficient attention to revoking privileges 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 privileges. Dictated by standards, IT auditors and unnecessary licensing costs for suites including Microsoft Visio, Projects and Adobe CS, organisations have come to acknowledge the importance of a responsible handling of authorisations. RBAC may just be the solution for them.
Role-based access control: what?
RBAC is a technique for implementing authorisation management across organisations. This technique involves assigning privileges on the basis of RBAC roles rather than assigning access privileges to individual users. These roles in turn comprise the department, function, location and cost centre associated with an employee. Although organisations 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% of the staff could be moulded into a single RBAC role. More often than not, there are as many functions in an organisation 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 authorisation 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. An RBAC specialist will be able to show you which approach will prove most successful.
Role-based access control: how?
Tools4ever uses a bottom-up and stacked approach to RBAC. 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 privileges on the organisational 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.
Using the HRM system as a basis
The HRM system is an excellent source for determining these combinations. This will pave the way for a role model on the organisational level. As an example, a hospital in Dorset has a Surgery department that includes the functional role of Nurse. The organisational role can be created on the basis of the function; department and location found in the HRM system (see Figure 1). These are ‘Nurse’, ‘Nurse in Dorset’ and ‘Surgery nurse’, respectively. After ‘Nurse’ and ‘Surgery’ have been defined, a nurse in the Surgery department will automatically be identified as ‘Nurse + Surgery’ and assigned the stacked roles.
Using this method, it becomes very easy to populate over 80% of the RBAC table. A major benefit of this approach is that new employees can start working on their first day while time is liberated for the assignment of specific privileges on an application and system level.
A subsequent step is to translate these organisational roles into application or system roles, which will comprise the remaining 20% of the RBAC table. The basis for this is already present and now further stacking will take place. The assignment of the system roles can easily be handled by the relevant manager.
After all, managers rather than HR are responsible for the access privileges of their employees. On the basis of a special workflow, the relevant manager will be prompted by an e-mail notification and/or web form to specify the access privileges and applications for the employee concerned. The RBAC software can subsequently record the manager’s choices to further populate the empty sections of the RBAC table and eventually achieve a fully populated table. This means it is possible to have a manager handle all the translations of roles within their department, with an option to delegate tasks to a colleague.
An action triggered by the manager may also result in a workflow notification to a licence manager. This allows managers to exactly determine and manage what happens within their department or cost centre.
Detailed access privileges
Because the system and application roles contain the detailed access privileges for the application in question, the role can be implemented. The responsibility for the actual provision of network access lies within IT as well as functional/technical application management (see Figure 1). It is also possible to automate this part of the process (provisioning) with the help of identity management software.
The major advantage of implementing RBAC in this way is the speed of implementation. Where it takes other vendors a year, Tools4ever is able to create a first standard for organisations within two months. Added to this, customers can easily achieve SoD (Segregation of Duty), e.g. by refusing certain access privileges in case of forbidden combinations of roles and departments. In case of downsizing initiatives, it will not be necessary to recreate the RBAC table from scratch. The only thing that will have to be modified, is the first, ‘Who are you’ section of Figure 1, and this can be conveniently done in the HRM system. By taking the HRM system as the basis and continuously polling it, managers are ensured of the most up-to-date information and have a populated dashboard at their disposal with the function, department, location and cost centre for all their staff.
This requires a direct link with the HRM system, since that is the source of all the information. Tools4ever is able to achieve this through its UMRA solution.
Role-based access control: UMRA
As long as the relation between the function/department/role and resources within the organisations are known, RBAC can be used as the basis for the provisioning process. Through its User Management Resource Administrator (UMRA) solution, Tools4ever allows customers to achieve a quick and targeted RBAC implementation. UMRA offers a unique toolset that ensures a practical RBAC implementation, provides immediate results and creates the basis for a further population of the RBAC table.
UMRA and RBAC
UMRA is able to handle RBAC data in various ways. UMRA offers users various options for processing empty, partially and completely populated RBAC tables to allow them organisations to achieve a quick and result-oriented RBAC implementation.
Empty RBAC matrix: If the RBAC matrix is empty, in many cases privileges and applications will be copied from a template or existing user. One of the drawbacks of this approach is that there is insufficient control over pollution and employees will eventually end up with far too many network privileges. Nevertheless, the objective is often to use the first method, copy user or template, during the first phase of the UMRA implementation to ensure a fast implementation as the dependency of an RBAC project can delay IDM implementations for months or years on end. In any case, accounts are created more uniformly, and a starting point is established for collecting the information required to populate the empty RBAC matrix.
Partially populated RBAC matrix: Although it can be difficult to populate the RBAC matrix completely, it is very simple to populate it partially to the department level. In many cases it is also feasible to populate the matrix easily for a large group of employees. An RBAC matrix populated this way offers a major advantage in the user management process. After all, for new employees, it is possible to assign all groups at the organisational level (login, word processing, email) and departmental level (access to departmental shares and applications) directly.
This means new employees can start working immediately. More time is freed up for assigning more specific privileges. If UMRA detects an unpopulated section of the RBAC matrix, the manager of the employee in question will automatically receive email notification and will get an UMRA form asking for the specific privileges and applications required for the employee. The manager’s choices will be recorded in UMRA. This information can be used for further definition of empty sections in the RBAC matrix.
Completely populated RBAC matrix: Although it can be difficult to populate an RBAC matrix fully, it will prove to be the ideal tool for assigning and storing the right privileges and applications for every employee. Using the RBAC matrix, UMRA can regulate the assignment of privileges and applications to new employees and handle changes occurring when roles and/or job titles of employees change or employees change departments. More complex scenarios are also supported, e.g. cases where an employee works part-time for two different departments or when transferred employees remain active in their previous department, etc. It is also possible to store RBAC information in UMRA, or to have UMRA retrieve RBAC information from a database or third-party software application.
Conclusion
RBAC currently attracts the attention of many organisations because this access methodology allows them to assign and revoke access privileges in an efficient, transparent and controllable way. An RBAC implementation does not necessarily have to be complex. We recommend organisations to use a stacked approach to RBAC and to automate the assignment of access privileges on an organisational and departmental level (through their HRM system), focusing on the top fifty combinations of functions and departments. This should enable a quick and convenient population up to 80% of the RBAC table. The detailed access rights of the remaining 20% cause organisations a great many headaches. To handle these remaining 20% in a pragmatic way using the RBAC model, we advise organisations to have their managers handle the assignment of access privileges to employees. The managers will be able to determine and modify the detailed access privileges for their team.
Pyramid
It is possible to catch this method in a pyramid running from the top to the bottom of the organisation, via the department, location and function down to individual employees (basic layer). The top layer (organisation and location) will exclusively include access privileges that apply to all employees. This section can be populated right away. Our advice to organisations is to stop populating the RBAC table at the department/function level.
The remaining details will be handled on an ad hoc basis, e.g. through a workflow. They will subsequently be able to further populate the pyramid and thus the RBAC table. Over time, the RBAC model will allow organisations to collect more and more information on the choices and selections made during the assignment of access privileges. After a review cycle by the security officer, this information can be used to further enrich the RBAC table and to increase the 80% to perhaps 100%.
For more information go to www.tools4ever.co.uk
Tools4ever is the market leader in identity & access management. It offers an end-to-end portfolio of identity & access management solutions that include consultancy services and strategic applications in the field of user provisioning, password management, single sign-on (SSO), self-service & workflow management, RBAC and auditing & compliance.
© Technews Publishing (Pty) Ltd. | All Rights Reserved.
printer friendly version