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 start
from -
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 tells us about violations and SoD conflicts?
- A system that will build role models by itself?
- Manage access?
- To control everything?
- Provide physical and logical user access 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 user's request or without it),
- built-in rights and roles in each system.
I wrote about
the maturity model in the last article for a reason. It’s impossible to create an ideal process in the blink of an eye, but with well-planned work, the desired result described above can be achieved 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's take as an example the process of providing 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 process steps
- 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 with us:
- 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 process, we need only these characters.
Now we define the field of action. At first for us the process 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 easy, 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 your next 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 tell you how to fill out an application correctly - ask the manager, call the resource owner or administrator, write a letter to 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 must also 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 route coordination. 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 route coordination should also be taken into account. Several methods of reconciliation can 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 matching. Therefore, we consider here a single interface for all coordinators.
Next, consider the
options for execution .
From 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 execution is a person who is in some cases irreplaceable, because can analyze the situation and, making adjustments, give 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 execution saves from human errors, but has its limitations. In some cases (especially if we are talking about non-system automation of a number 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.Suppose we build the process as follows:
With this configuration, users who are accustomed to communicating by mail will find out the procedure and format of the correct application for the required access rights. As a result, they will be able to choose how it is more convenient for them to form an application - on paper or via e-mail. The request will be coordinated via mail, and the administrator will manually execute the request.
This process has the right to life if there are no other, more modern means. However: how long will the whole chain of actions take, and how to envisage escalation in the absence of a coordinating reaction?
Process 2.Choose another configuration:
Here we see that an employee calls the resource owner to compile a correct request, and then forms an application in the SED or Service Desk. In the same application will be agreed. Execution will depend on what is requested - manually by the administrator or scripts.
In the ERMS and Service Desk, as a rule, it is possible to configure escalation in the case of a prolonged failure to make a decision by the coordinators, or in the absence of a coordinator for one reason or another.
The process looks more convenient and faster than the first one we reviewed. Nevertheless, the question arises: is the application formalized?
If the user writes “
I want access to the system like Ivanov’s, ” then the execution can be only manually.
If the application is formalized (i.e. there are some limited number of options to choose from), we can talk about automation capabilities. At the same time, it is necessary to look again at how automation will be implemented - by whom, with what quality and how it will be supported.
Process 3.Consider the IdM option:
In this case, the user can find out what access he needs from a manager or simply by looking in the request form (in the IdM role directory, you can display business roles or roles with a clear description for the convenience of users).
The request for rights and roles occurs in IdM, as well as the coordination of applications.
The rights will be granted by IdM automatically upon completion of the approval procedure for those systems that are connected for management via IdM. Since not all systems need to be connected for control (you can connect for control in data acquisition mode), the executor will receive a clear task for execution. In this case, in the event of an administrator’s error, the system will identify the discrepancy between the application and the access granted and inform the interested parties (for example, the information security officer and the system administrator).
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 relocation (increase, linear relocation, 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 be collisions 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,
- will we be able to 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: