Checklist: how to choose a model of an access rights management system and not miscalculate

Every year the park of information systems of companies is growing more and more, along with it the tasks of managing, controlling and delimiting the access rights of employees to information resources are proportionally complicated. The presence on the market of solutions partially overlapping each other’s functionality provides fertile ground for new and new debates. How should the access control system be implemented - through integration with ITSM or the introduction of a separate IGA solution?



There are several reasons for the debate. First, IT has traditionally managed access to corporate systems in companies, but with the increase in the number of employees and information security maturity, new risks are opened up for the company. Among them are the provision of redundant access rights and the cost of interrupting business processes caused by untimely granting access. As a result, it is not always obvious who should solve these problems: IT or IS?

Secondly, even if the company does not have a division into IT and information security services, it is often often not clear which solution can close the functionality that the company needs, which will be more convenient for administrators and ordinary employees.

So, there are two approaches to solving the problem:

1. expand the ITSM toolkit and use its application system in conjunction with IGA;
2. Use IGA as a single solution and employee self-service portal.

There is no single answer to the question which is better. When making a decision, it is worthwhile to understand that typical IGA / IdM specialize in automating access to key information resources of the company and perform a number of related functions. Conversely, the ITSM toolkit fulfills a wide range of requests for manual servicing of system users, but does not have the ability to perform IGA functions. We will talk about the advantages and pitfalls of each of the options and try to help you sort out what is right for your company.

Integration approach

When talking about the integration approach, it should be immediately explained that in general there are two schemes for integrating IGA and ITSM:

• ITSM system as frontend.
• IGA system as frontend.

ITSM system as frontend

Business task: a single entry point for any user requests for IT.
It is implemented by embedding the form for generating applications for access to the ITSM system.
ITSM system development (form development) and the availability of API (SOAP web-service or REST) ​​in the IGA system are required.

Possible implementation options:

• Free text input form with clarification of the application by the administrator directly in the IGA system. It does not require serious improvements, but it is extremely inconvenient to use.
• Formation of a full-fledged application in ITSM with subsequent coordination in IGA.
  Pros - automation of the formation of an application in IGA.
  Cons - full integration with swapping directories and obtaining application status from IGA is required for display in ITSM. Coordination is done in the IGA, and therefore ITSM is not a single entry point for negotiators. They have to use frontend IdM for negotiation.
• Formation and approval of an application in ITSM with subsequent execution in IGA.
  Pros - ease of implementation, a single entry point for all users (including and matching).
  Cons - difficulties in implementing coordination related to the content of the application. It is necessary to build a route based on information in ITSM, which may not be there.
• The ITSM implements the formation of the application, after which the application is imported into the IGA, and there the approval route is formed. In ITSM, reconciliation tasks are initiated and reconciliation / rejection / delegation operations are initiated in the ITSM interface, but are actually performed in the IGA via the API. The most difficult to integrate, but the most user-friendly option.

IGA system as frontend

Business objectives:

• In some organizations, according to internal regulations, all changes in the IT infrastructure should be reflected as tasks in the ITSM system.
• Use ITSM to implement additional stages of application execution (for example, preparing a workplace) and to control access to systems for which it is not planned to develop a connector - at this stage or in general (due to the small number of users, lack of expediency, etc.).
  
  • The IGA becomes the single entry point for any access control application.
  • A gradual increase in the number of systems connected to IGA is provided, while the application system is introduced immediately for everyone.
  • The IGA stores information about user access in all company systems, even for those whose connection at this stage is not performed or is not planned at all.
  • Timely termination of user access in unmanaged systems is ensured when a user is fired or goes on vacation.

Implementation

Applications are generated and agreed in the IGA system, after which the generated requests for changes in access permissions are exported to the ITSM system. They can be grouped into one ticket containing several requests.

Requests that can be performed by the connector are executed, after which the tickets in ITSM are closed.

Requests that cannot be executed by the connector (or there is no connector) are awaiting execution by administrators in ITSM. When the ticket status changes in ITSM, the request is automatically closed in IGA. The administrator can enter important information in the ticket fields when it is closed, which means the need for reverse synchronization in IGA.

With all this, the development of functionality will require changes in the two systems.

In addition, ITSM class systems have some fundamental limitations:

• The inability to see the entire business process, including HR events (important when conducting an audit and investigating information security incidents).
• The complexity of determining the real-time execution of an access provisioning business process.
• Limited ability to determine the basis for the granting of certain rights to company employees.
• Lack of audit capability.

You need to understand that in the case of implementing an integration solution it will be much more difficult to maintain or change, because there will be a need to engage two development teams, which means coordinating two TK, synchronizing their work, and budgeting work in both teams. When making a decision, this side of the question cannot be overlooked.

On the other side of the scale lies the problem for the user: when choosing the appropriate integration option, he now needs to go into at least 2 systems or more (as a rule, the company also has a corporate EDMS). For company executives, this becomes quite a big headache. Users and IT staff constantly ask: “Why is this needed? Let's do all the new functionality in ITSM! ” At the same time, in many companies, applications are accepted by mail / through a call center, and a fairly low percentage of users work with ITSM directly through the interface.

In our practice, there have been companies where there is no own IGA interface, there is functionality as an engine, and it really is tied to application systems. However, the possibilities for changing the BP (for example, calculating matching non-obvious algorithms) in ITSM are very limited.

IGA as a single solution

The obvious advantage of using only IGA to build a user rights management system is that it automatically saves us from all the difficulties that inevitably arise when integrating with an external system.

The presence of an integrated workflow greatly facilitates the audit and allows you to see in a single window the grounds for granting certain rights. This allows you to reduce the costs of searching and preparing information for audits and internal investigations of information security incidents, providing a holistic picture of rights in a single interface.

If the classic IdM functionality can be successfully implemented in conjunction with ITSM, then integration with IGA (in particular, the implementation of functionality to change resource management processes and organizational structures) will require so much labor that it is actually on the verge of economic feasibility.

In fact, with the introduction of IGA in the company there are a number of new processes. When using the system, not only the possibility of requesting authority should be available, but also a variety of additional services should be provided, such as:

Role	Services
Employee	Current / Historical Access Reports Access request functionality “like that guy” Temporary Access Applications Group applications Functionality SoD
Matching	Ability to coordinate all applications with one click or split them into parts Convenient analytical tools
Information Security Officer	Ability to suspend / revoke access Obtaining the necessary historical data for official investigation

On the one hand, all of these interfaces are not very complex. On the other hand, in the classic ITSM you can implement fairly simple operations, but gluing or splitting applications in ITSM is already quite difficult to implement. What options are there?

• We are engaged in the substitution of concepts and, speaking of integration, we simply forward the interfaces to approximately the same ITSM console. But such an approach can hardly be called full integration.
• If we start full-fledged integration, we are faced with a number of such complex tasks as expanding the database in ITSM itself, customizing processes, etc. At the output, we get integration with IGA at the level of execution and expectation of answers, because the mechanisms themselves remain in the IGA. In addition, these works will have to be carried out in two information systems.

At the same time, business users are increasingly found who, although far from the IT world, take advantage of the IGA capabilities, build dynamics and use analytical tools. This means that sooner or later people will have to be allowed into another interface.

So, is it possible to create applications in ITSM? Yes, you can, and it's simple enough. But any advanced functionality, including approval of applications, is best implemented in an IGA system designed to solve these problems.

I’ll try to draw parallels with our real life: imagine that you are a student, study and work. To keep up with everything, you ride around the city on your own motorcycle. This is really great, you are completely satisfied with this type of transport - quickly, easily and economically. Time passes, and yesterday’s student grew up and got married, a child appears, and the question arises: how to move with the new composition? Of course, you can purchase a motorcycle stroller and close the requirement to transport a child, but you must admit that such a solution can hardly be called optimal. So, you need to purchase a car of the corresponding class.

Look from the side of information security

It is also worth reflecting the view on the dilemma from the point of view of IS employees:

• Any IGA-system allows you to compare the access rights that are agreed upon and actually available for an employee. Transferring this functionality to ITSM is extremely difficult. How will this end up looking for a security guard? In one system, he will have to look where the employee has access, and in another - who, when and on what basis issued this access.
• The use of an additional integration corporate system may be associated with the risks of data substitution / distortion, unauthorized access.
• IGA is a closed program in itself, to which certain requirements can be made for integrity, limited access to the database, encryption, etc. These requirements can be extremely complex and not applicable to ITSM.

So, a small checklist instead of a conclusion:

Integration approach

Centralized IGA System

✓ Static, established organizational structure of the company. ✓ The classic IdM solution has already been implemented. ✓ Available resources for the implementation and support of the integration solution. ✓ Company regulations require the display of all changes in the IT infrastructure as tasks in the ITSM system. ✓ A single entry point is required for any user requests for IT.

✓ A dynamic company, a changing OSH (you need to be able to painlessly reflect or change any approval schemes for applications). ✓ A functionality is required that is typical for IGA class systems (resource management processes and OSH, SoD). ✓ It is important to have convenient analytical tools. ✓ Frequent audits. ✓ There are requirements for system integrity. ✓ The company has control over the deadlines for the execution of applications.