IdM implementation. Procedures and facilities - from basic to IdM

Published on May 31, 2018

IdM implementation. Procedures and facilities - from basic to IdM

    Last time, we looked at approaches to building an access model . Now you need to think about the procedures and technical means: how to build processes that will help control access, and how this can be implemented.

    First of all, it is worth thinking about what you will build on - from what is , or from what you want . The result will depend strongly on the starting point. Each approach has its pros and cons, and it is worth considering both to understand the perspectives and realities.


    Let's go from the desired. What do we want?

    • A system that itself will tell us about violations and SoD-conflicts?
    • A system that will build role models by itself?
    • Manage access?
    • To control everything?
    • Provide physical and logical access for users with biometric authentication, etc.?

    Here you can think of a lot more, and all this can even be realizable. But (!) With a high probability it will be an individual development, long and expensive.

    And what do we have?

    • Access Policies
    • the process of providing access (at the request of the user or without it),
    • built-in rights and roles in each system.

    I wrote about the model of maturity for a reason . It’s impossible to create an ideal process in the blink of an eye, but with well-planned work you can achieve the desired result described above if it is in demand in your company.

    When designing processes, it is worth remembering: the simpler and more transparent the system, the easier it is to control it . The more different conditions and branches of the manual process, the more often errors will occur.

    Let us take as an example the process of granting access, in which the user needs new rights in the system to perform a certain task.

    What factors need to be considered when creating such a business process?

    • convenience for users, coordinators and performers,
    • time
      • spent on each of the stages of the process
      • the cumulative time of the process,
    • the cost of implementation of each step,
    • influence on the next steps

    First, we will determine who participates in this process:

    • the user himself requests access rights
    • his manager - coordinates the request, confirming the production need,
    • Information Security Officer - coordinates access by tracking conflicts of authority (not all companies have this, but suppose ...),
    • information system administrator - executes the application.

    In the process there may be many more participants, for example: the owner of the resource, an additional controller from IT, etc. In the meantime, to parse the construction of the process we have enough of these characters.

    Now we define the field of action. At first, the process for us looks like this: The

    employee requests access rights, their manager agrees, then the information security officer agrees, after which the system administrator executes the request.


    This is a simple linear process, it looks simple, but still let's deal with the details. I ask you to take the following as an example of reasoning when building a process. For your company and users, the significance of individual factors — convenience, time, speed, and impact on future steps — may differ.

    How does the employee know what access he needs and what exactly to request? Sometimes it is possible to contact a person who can suggest how to fill out an application correctly - ask the manager, call the owner of the resource or administrator, write a letter to the technical support. Sometimes it helps the form itself request access, which offers clear options to choose from, or there is a field to describe the situation.

    All the described options are usually available, but it takes some time. So, you need to choose the fastest and most user-friendly options. (We strive to provide quality services to the business.) You can leave 1-2 options relevant, or you can - everything. At this stage, it is important to simply compare the available options for identifying the necessary access rights by the parameters selected earlier.


    The next step is the interface for requesting permissions . How can a user request access rights?

    Among the options that come to mind are: telephone, mail, EDMS (electronic document management system), Service Desk, IdM interface or just a paper application. It is important that the application method is simple and understandable for the user.

    Again, you need to take into account the time factor: is it faster to write a letter or press a couple of buttons in the Service Desk? It must be remembered that in the next step the application will be coordinated, and this also needs to be done promptly.


    After selecting the interface for requesting access rights, consider the negotiation interface .
    Options: on paper (we originally laid this option), by mail, via EDMS or Service Desk, IdM interface.

    It is worth considering the complexity of the reconciliation route. We are now considering a linear process with 2 steps of matching. But in life everything is usually more complicated, and differs depending on the systems to which access is requested. Accordingly, all parameters related to the routes of coordination should also be taken into account. Several methods of reconciliation may be combined, and such cases require increased attention and support. For example: the manager will coordinate the application on paper, putting his signature, and the information security officer will work with the application scan in SED. This adds complexity and inconvenience to both the user and the coordinator. Therefore, we consider here a single interface for all coordinators.


    Next, consider the options for execution .
    Of the options - manual execution or automated.

    In this case, automatic execution in some cases can be achieved not only with the help of IdM embedding, but also performed, say, with the help of scripts.

    The advantage of manual performance is a person who in some cases is irreplaceable, because can analyze the situation and, by making adjustments, grant the user the necessary rights. However, this makes the process vulnerable: after all, a person may be mistaken or forget to document what has been done.

    Automatic executionsaves from human error, but has its limitations. In some cases (especially if we are talking about non-system automation of a series of actions by scripts), the administrator will still have to either set some parameters or control the execution. IdM in this case can operate with the parameters that were set during the design of the processes during the system implementation and the attributes of the application (if we use IdM as the application system for access).


    We have done some work with each element of the process separately. Now we need to evaluate what we can do if the selected steps are compatible, just like a puzzle is assembled.

    First, let's look at the options for this process:


    The number of links is fair. It is important to choose combinations at which the time and cost will be minimal, and the convenience of users (including coordinators and performers) will be greatest. It should be borne in mind that the "cost" of the transition from step to step depends on the features of the selected steps.

    Consider for example three processes.

    Process 1.
    Допустим, мы построим процесс следующим образом:


    При такой конфигурации пользователи, которые привыкли коммуницировать по почте, выяснят процедуру и формат правильной заявки по требуемым правам доступа. В результате они смогут выбрать, как именно им удобнее формировать заявку – на бумаге или посредством электронной почты. Согласовываться заявка будет через почту, а исполнение запроса произведёт администратор вручную.

    Этот процесс имеет право на жизнь, если нет других, более современных средств. Однако: сколько времени займёт вся цепочка действий, и как предусмотреть эскалацию при отсутствии реакции согласующего?

    Process 2.
    Выберем другую конфигурацию:


    Здесь мы видим, что сотрудник для составления корректного запроса звонит владельцу ресурса, после чего формирует заявку в СЭД'е или Service Desk’е. Там же заявка будет согласована. Исполнение будет зависеть от того, что именно запрошено – вручную администратором или скриптами.

    В СЭД и Service Desk, как правило, можно настроить эскалацию в случае длительного непринятия решения согласующим, или в случае отсутствия согласующего по той или иной причине.

    Процесс выглядит более удобным и быстрым, чем первый рассмотренный нами. Тем не менее, возникает вопрос: формализована ли заявка?

    Если пользователь пишет «хочу доступ к системе как у Иванова», то исполнение может быть только вручную.

    Если заявка формализована (т.е. есть некоторое ограниченное количество вариантов на выбор), мы можем говорить о возможностях автоматизации. При этом снова нужно смотреть, как будет реализована автоматизация – кем, с каким качеством и как будет поддерживаться.

    Process 3.
    Рассмотрим вариант с IdM:


    В данном случае пользователь может узнать о том, какой доступ ему необходим, у руководителя или — просто посмотрев в форму запроса (в каталоге ролей IdM можно для удобства пользователей выводить бизнес-роли или роли с понятным описанием).

    Запрос прав и ролей происходит в IdM’е, равно как и согласование заявок.

    Предоставление прав будет осуществлено IdM’ом автоматически по завершении процедуры согласования для тех систем, что подключены для управления через IdM. Поскольку не все системы необходимо подключать для управления (можно подключить для контроля в режиме получения данных), исполнитель получит чёткое задание на исполнение. При этом, в случае ошибки администратора, система выявит расхождение между заявкой и предоставленным доступом и сообщит об этом заинтересованным лицам (например, офицеру ИБ и администратору системы).

    For each of the processes can be assumed and the cost of support .
    At the same time, we should not forget that, in addition to building the process of granting access rights, which we have chosen for ease of consideration, processes are also needed for optimal performance:

    • revision of access rights for personnel movement (increase, linear movement, transfer from one holding company to another),
    • revision of access rights on a schedule (as required in your company - quarterly, annually),
    • revocation of rights when dismissing an employee and blocking accounts,
    • audit, etc.

    Therefore, in the decision-making process, it is necessary to “step back again in order to look at the entire system of access control processes .

    With this approach, you can evaluate the use of each organizational and technical solutions:

    • How does it affect the company's business processes?
    • Is it convenient for users
    • whether the downtime of the staff will not increase due to unavailable access on time,
    • will not affect the simple profit of the company,
    • Will there not be a collision process as a result of such a set of processes?
    • will we be able to audit access rights,
    • Do we have enough information documented to use it in disputable situations or when investigating an incident,
    • can we revise employee access rights, etc.

    Assessing the emerging mosaic of access control processes, you can more easily choose organizational measures and technical solutions.

    Other articles of the cycle: