Centralized Access Management

The access management processes defined in IdentityPROCESS+ allow organizations to control the granting of access rights while ensuring that they do not violate any security and compliance policies such as segregation of duties.

When identities have been created by the identity lifecycle management processes new employees or employees moving around the organization will have the access rights they need to perform their day-to-day job duties. Over time, employees may need to extend access rights to a system because they have been assigned to a new department or region, or because they get promoted and require access to additional functionality in applications they already use. Similarly, new applications may be introduced as the business develops that employees need to request access to use.

Traditionally, IT departments used to keep track of access rights in spreadsheets to document their process to auditors. The problem with this traditional way of handling the process is that it is very time-consuming, prone to errors, and may violate internal policies or external regulations. Documentation used for audits may be fragmented as reasons for granting access are not properly logged and employees may accumulate access over time because they are not revoked when they move department or stop working on a project.

The access management processes defined in IdentityPROCESS+ allow organizations to control the granting of access rights while ensuring that they do not violate any security and compliance policies such as segregation of duties. Also, the definition of self-service access requests means that the processes reduce the amount of work required by the IT department as processes associated with granting access are automated and delegated. The processes also describe how to set end-dates to ensure access is removed when it is no longer required by the user.

Why Access Management is important:

Access management consists of three process groups including request access rights, which simply describes how users can request access, evaluate and act – which includes processes for approval and removal of access as well as delegation of access rights, and finally the provisioning group that looks at how to grant access to less-used systems that are not connected to the IGA system.

The process groups in the process area ‘Access Management’:

1. Request access rights
   • Access request
2. Evaluate and approve
   • Approval of access requests
   • Delegate access
   • Remove access
3. Provisioning
   • Manual provisioning

Request Access Rights

Automates access requests enabling end users to provide the right information so that access can be granted quickly without introducing security and compliance violations.

Access Requests

Over time, users need to request more access to systems as they progress through their employment. It is important that they are granted the right level of access and the reasons for access are properly documented for auditing purposes.

Process Description. When the request access process is initiated, the user is prompted to fill in the business justification for the new access rights. The process then triggers the approval of access request process during which the manager will either approve or reject the request. If approved, the access is automatically provisioned, and the user will have the new access. Requests can be made on behalf of other people so that a manager can request access for a contractor or employee who is not as familiar with the system.

Best practice IGA system functionality. The user makes the access request directly in the IGA system and can only submit the request once a business justification, as well as information on business context (department, project, or cost center), is provided. Upon submission, the access request approval process is initiated. A segregation of duty policy check is executed automatically to ensure that the new access will not grant a toxic combination of access for the user. An approval log is created for each requested resource task, enabling approvers to see the identity and the reasoning for the approval.

An approval history is maintained for each requested resource assignment. The history is accessible to the approvers in the process and enables them to see who previously approved the request when and why.

Technical process flow:

1. In the access request process, the user is notified if request will result in an SoD.
2. The approver is notified if request will result in an SoD. Up to 9 layers of approval can be configured.
3. After the business requirement for the access has been approved, a compensating control process starts in case of an SoD. The compensation control is defined by the business and can vary depending on the type of SoD.
4. The access is provisioned, and in case of an SoD, the risk of the SoD has been mitigated according to business specifications.

Evaluate and Act

Manages the routing of self-service access requests for approval, automates removal of access rights that are no longer needed, and processes the delegation of access rights to cover an employee leaving or an extended absence.

Video: Omada & ServiceNow

Approval of Access Requests

Before a user access request can be granted, it needs to be checked to ensure that it is not in violation of conflict policies such as segregation of duty, and then approved or rejected by the business system owner.

Process description. The approval of access requests process is closely linked to the request access process and starts when a user has requested access.

The process includes four tasks:
1. The request is received by the designated approver, typically the business system owner or manager, who can grant or reject access after reviewing the request
2. A segregation of duty (SoD) policy check is carried out to ensure that granting the request does not give the user access to carry out activities which contravene company policies
3. A log showing the history of what has been approved, when, and why is maintained. This log helps the approver assess the suitability of access requests in the context of what has been granted or rejected previously and documents the process for auditing purposes
4. Access is granted if the request is approved and does not violate any predefined business policies

Best practice IGA system functionality. Once the request access process is executed, the IGA system automatically creates a task for the relevant approver. An SoD policy check and other configured conflict process checks are executed and the information log is updated with relevant information. The IGA system determines what needs to be provisioned to satisfy the request and sends this information for provisioning. An approval history is maintained for each requested resource assignment. The history is accessible to the approvers in the process and enables them to see who previously approved the request when and why.

Technical process flow:
1. The incoming access request is either approved or rejected
2. Role and policy calculations are triggered including SoD violations evaluation
3. Provisioning to target systems is executed

Delegate Access

Occasionally, it may be necessary for a user to assign his/her system access rights to a colleague, for example during holiday periods. A manager may want to delegate their access rights to a personal assistant or project coordinator for a longer period. This type of access delegation is temporary and therefore the overall access rights remain with the delegator to ensure ongoing compliance.

Process description. The delegate access process allows users to temporarily assign their access to other users. The process contains several procedures ensuring that the transfers do not leave an organization open to unnecessary security risk. One of the procedures ensures that if the delegated access rights are withdrawn from the delegator, then they are also immediately removed from the employee they have been delegated to. Another ensures segregation of duty (SoD) policies are checked for toxic combinations during the delegate access process. Finally, it is possible and best practice to limit the delegation to a defined period such as the length of time the delegator is on holiday or the estimated time they will be on leave. This ensures that the increased access level is not forgotten, so a user will not accumulate excessive access over time.

Best practice IGA system functionality. To execute the delegate access process in the IGA system, the delegator chooses the access rights they want to delegate, the user they want to delegate access to,
and the validity period. The system automatically assesses if any policies are violated and either rejects the request or provisions the access.

Technical process flow:
1. The user chooses an identity that they want to delegate the access rights to
2. The user chooses the access rights to be delegated and fills the Valid from and Valid to fields
3. The user submits the request
4. Roles and policies are calculated for the identity
5. The delegated access rights are provisioned

Remove Access

To maintain a high level of compliance and security, organizations need to remove user access that is no longer needed when employees or contractors leave, move to a different department, or get promoted.

Process description. The remove access process ensures that access rights are removed when they are no longer needed and is triggered when:
1. An identity removes its own direct access
2. A manager removes direct access for one of their direct reports
3. A system or resource owner removes direct access to a system or resource he / she manages
4. A previously granted access right meets a preset expiry date
5. A data administrator can always determine to remove direct access of any identity

Best practice IGA system functionality. A user or manager logs into the IGA system and selects the access to be removed. Once selected and confirmed the access is removed and deprovisioned in the target system. If the process is triggered by an expiry date the same steps are executed automatically.

Technical process flow:
1. The user logs in to the IGA solution and opens the overview for the identity that he/she wants to remove access to
2. The user selects the desired access and confirms
3. Access is deprovisioned

Provisioning

Manages the recording and logging of access rights provisioning for business systems that cannot be automated in the IGA system.

Manual Provisioning

While it may not be possible or desirable to connect all business systems in an organization to the IGA system, it is still necessary to enable access and log activities for compliance purposes.

Process description. One of the key benefits of an IGA system is that the process of provisioning or assigning access rights for a user in the target business system is automated. The manual provisioning process ensures that you can provision to systems not connected to the IGA system and still monitor and log activities within the IGA solution to meet auditing and compliance requirements. The request is done in the IGA system and the provisioner, the user or user group responsible for handling the request, gets a notification to carry out the task which is done manually. Both the requester and provisioner logs relevant information in the IGA system.

Best practice IGA system functionality. The requester makes the request directly in the IGA system and the provisioner is sent a manual provisioning task. The provisioner manually performs the actions required to create the assignment between the identity and the resource in the target system and confirms in the IGA system that the task is completed.

Technical process flow:
1. The IGA system determines that an access assignment requires manual provisioning as it does not have an actual desired state
2. The IGA system creates a manual provision task
3. An e-mail notification is sent to each person responsible for the manual provisioning who will access the target system and provision access manually
4. The manual provisioning is confirmed in the IGA solution by the provisioner
5. The IGA system updates the actual provisioning claim as being unconfirmed (i.e. the system has not confirmed the actual state itself)

Process Stakeholders

The access management processes are mainly end-user focused. This means that the tasks associated with these processes are all post-implementation and only involve end users and their line managers. HR, the IGA team, and business system owners have no direct involvement in these processes.

1. IGA Team
   • None.
2. Line Managers
   • Line managers respond to the request access process by either approving or rejecting the request. Line managers can also remove access from one of their direct reports if necessary
3. End Users
   • End users request new access rights if they feel they need to access new business systems to carry out their work. End users may also select to delegate their access rights if they are to be out of the office for a period.
4. Business System Owners
   • Business system owners need to approve access requests.

Key Best Practice Recommendations

Below are a set of key best practice recommendations that should be taken into consideration when implementing the access management processes in IdentityPROCESS+.

Access Rights

Determine if some users can request access rights for others

It may be appropriate for certain users to request access rights on behalf of other employees. For example, an organization may allow managers to request access to business systems for their direct reports, or personal assistants may need to request access for their managers.

Allowing some users to request access on behalf of others will help increase overall efficiency and speed up operations, but measures need to be put in place to minimize misuse. The circumstances where individuals are permitted to request access for others should be documented in a written IGA policy document.

Determine who can remove access rights from individuals

The removal of access rights could result in preventing an employee from performing their day-to-day job function. However, there may be certain times where access rights need to be removed such as when a security breach is suspected, where there is a segregation of duty violation, or where the organization suspects that the user is in violation of its information technology usage policy.

Organizations need to ensure that employees with the ability to remove access rights understand the business implications of doing so. The circumstances where individuals are permitted to remove access should be documented in a written IGA policy document.

Approvals

Determine if an approver can modify requests

It may be appropriate for an approver to be allowed to modify a request. For example, if the approver feels that the ‘valid to’ date does not meet with compliance
guidelines. Allowing changes to be made will speed up the approval process but needs to be managed carefully to ensure that changes are in line with organizational guidelines. If changes are permitted, the process should be explained in a written IGA policy document.

Determine whether an implicit or explicit model for granting user access should be adopted

To improve efficiency, some organizations give a certain level of access rights – often referred to as birth rights – to users based on a set of predefined rules. However, other organizations that are more risk averse enforce an explicit approval step in each case.

Both options have their merits but also their drawbacks – organizations need to determine which is most appropriate to meet their needs. Implicit granting of access is efficient because it does not need a manager to approve basic access rights that all new employees will be granted based on their basic job role requirements (e.g. e-mail, Active Directory, and expenses application). However, to implicitly grant access, role definitions need to be in place.

For explicit approval, there are fewer upfront steps needed as no roles need to be defined ahead of time, however, access rights need to be approved for each new employee.

It is recommended that, where possible, organizations should use predefined rules to assign access rights as this reduces the workload of the approving managers and reduces the time taken to grant access rights to users.

Use line managers for access rights approvals

It is important that line managers know what access their direct reports have been granted. For this reason, it is recommended that all approval processes are routed through line managers. If appropriate, approvals could also be required by data or application owners, but this should only be considered for sensitive applications as it will add additional steps which will slow down the approval process.

Compliance

Enforce validity periods for external users

To improve compliance, external users such as contractors and third-party business partners should only be granted access for a limited period such as three or six months depending on the sensitivity of the resource, they are being granted access to and the level of access required. While this introduces an extra task for the approving manager on a regular basis, it also introduces a level of compliance which ensures that short-term workers are not left with access after they leave the company.

Increase compliance using resource classification

To increase efficiency when managing compliance requirements, it is recommended that resources are classified using tags. Classifying different resources based on the type of data they process, makes it easier to establish how they need to be managed and therefore which access policies need to be enforced based on regulatory requirements such as GDPR.

Miscellaneous

Ensure that business continuity is taken into consideration

Organizations need to identify if there are business critical applications that the company depends on where granting only one individual access rights could result in problems with business continuity. For example, an organization would face challenges if the only employee who has access to the server backup software is out of the office when data needs to be restored.

Use notifications sparingly

As managers are often overwhelmed with e-mail notifications, they are likely to overlook and miss important updates. It is recommended that organizations consider whether users need to be notified about every event in the IGA system. Instead, organizations should consider requesting that line managers log into the IGA system and process their task lists on a regular basis which ensures that they will not miss any important actions they need to perform.

Summary

Access management contains all of the processes to manage user requests starting with a user requesting access to a system which is then approved by managers or business system owners through to the removal of access when it is no longer needed by the employee.

Access management also allows for the delegation of access rights to other employees either on a short-term or long-term basis.

A mature IGA solution allows users to request access to the business systems or applications they require, automatically routes the request to relevant approvers and performs checks to ensure that any granted access does not violate segregation of duty or other policies.