Role-driven lifecycle management – Automating the joiner, mover, leaver process

Without well-defined automated processes, HR and IT departments often struggle efficiently managing an employee’s lifecycle.

At ProofID we take a simple yet effective stance to identity lifecycle management. If you follow and implement our recommendations you’ll immediately improve your security posture with the added benefit of increased productivity.

What is role-based access control (RBAC)

Role-based access control (RBAC) is an identity management approach that assigns and authorises access to resources and information to users within your organization based on their role.

These roles are assigned to users based on a number of factors such as the user’s job function within your organization or third parties such as customers and business partners.

For RBAC to work efficiently it is important to define a set of roles that aligns with the business, the user populations, the resources available as well as defining the rules for users to be assigned to a role. These tasks are normally referred to as “role modelling”.

Once a role model is defined, access to resources and information is assigned to each user based on that role. Once you have achieved tight adherence to access requirements established for each role, access management becomes much easier, more controlled and regulated.

The challenge with implementing RBAC is defining a role model for your organization that covers all the possible combinations without introducing toxic combinations. An issue which, in large organizations particularly, can become a project in itself.

Modern RBAC and our approach

However, there is another way. A more “simplified” role model is available which retains all the benefits and advantages of RBAC, but delivers it in a shorter time frame. This method divides roles into three main categories:

• Birthright Roles: Based on the highest classification of users such as employee, contractor or partner.
• Business Roles: Based on a department or job function (e.g. HR, Account Executive, Account Manager, Operations Manager, IT Administrator etc.). These roles are normally associated with a set of resources that are relevant to that specific role function. For example, granting access to a CRM platform rather than a HR system.
• Optional Roles: These roles are normally not assigned based on the user profile but rather on requests from either the user themselves or by another user (e.g. a Project Manager) on their behalf (e.g. Project No xyz member, Temporary Reviewer, etc.). These roles are associated with resources needed to potentially any user but without an easy to describe rule. For example, users assigned to a specific project, or users who are temporary assigned to a task or a working group. Optional Roles requested by the user, or by someone else on their behalf, often require approval by one or more administrators before being granted.

By working within this principle, any organization can then adopt a successful user provisioning service for all Joiners, Movers and Leaver’s. Below are some examples of each and the benefits of adopting the RBAC model to your organization.

Joiners

When a user joins the organization a HR record is created, and a role granted for the new starter. This would trigger the automation, of the creation, of the birthright resources and access for the user’s role within the organization. A simple automated workflow joining HR and IT.

Birthright and Business Roles and resources are normally assigned automatically to users depending on information that originates in an authoritative source such as the HR system.

In this example, birthright roles and resources are assigned when a user joins the organization and will be granted access to a set of resources based on their defined role; examples of resources that are normally classified as birthright are the employee badge, an account in Active Directory, email account, access to the corporate intranet and so forth.

Movers

Quite often users change roles within an organization, bringing with them access to resources they no longer need.

For example, an IT support engineer may change roles or be promoted, let’s say, to an internal IT Administrator. In their current support role, they have access to the support portal and remote access to other business partners systems. In their new role, they may not require this access anymore as he is purely an internal IT Administrator. By defining these two roles, as ‘Support Engineer’ and ‘IT Administrator’, in the RBAC model, the user can be moved to the IT Administrator role while the Support Engineer role is removed, revoking access to previously allowed systems.

Leavers

When a user leaves, access to all systems should be revoked at the end of their final day. By adopting a RBAC model, this can be a simple task, enabling you to disable the account and access to systems based on their previous role.

However, if the organization has not yet implemented the RBAC model, this can become problematic. Organizations, invariably, have little idea about any user’s previously accumulated access. Take our example of the Support Engineer. If there was no RBAC in place, the Support Engineer would have added IT Administrator privileges to their access, they could have requested additional access. Or, as an IT Administrator, granted it to themselves as optional roles. Access may be revoked for their last current role but not for the previously granted Support resources and remote access to their business partners systems or additional accesses.

Keeping control

In a classic RBAC model, access is strictly controlled by a role and this makes it relatively easy to have an accurate picture of who has access and to what. However, how do you deny users access that they should no longer have?

A recommended approach, and one favoured by auditors, is to schedule periodic access reviews or re-certification campaigns. Here, administrators are able to review each user and confirm or remediate which resources the user has access to or even disable the user account.

In addition to keeping users’ access to a minimum, reviews offer auditor reports with up-to-date resource access for each user.

In summary

Implementing RBAC does not need to be a lengthy and difficult project. Organizations that follow recommended practices, that use Identity Governance & Administration software and depend on RBAC, are better equipped to secure their sensitive data and critical applications.

Implementation can be achieved with limited disruption, enabling users to remain productive from day one, with access to email and other systems. Users can change roles safely without building and gaining unrequired access and can then be successfully de-provisioned once they leave.