There are two ways to build a role model in an information system.
First approach
Roles are developed based on a functional model . This approach is possible when the organization has a special department of technologists, let's call it "Organizational technological department (OTO)". In our bank, such a department was part of the IT department. The department will translate the business needs described in the functional model into the IT language: the language of rights / options / powers that must be provided in the system to perform a specific functionality.
This approach is also good when a new system is put into operation and role models are formed from scratch. First, you need to figure out, together with the IT manager of the system, how the rights are granted, whether there are any internal roles or groups in the system. Then, together with the heads of business units and technologists of general relativity, you need to develop roles, including the necessary rights in them. Then the created roles must be coordinated with the system owner from the business , since he is responsible for the execution of business processes, with the internal control department to avoid cross-system conflicts and with the security departmentso that the approved security policy of the company is not violated. After that, the system can be put into operation and assigned rights in accordance with the approved role model.
Second approach
Roles are formed from existing rights already granted to employees. In most cases, this is exactly what you need to do. systems have been in operation for a long time and it is necessary to sort out the mess in user rights that has accumulated over many years of operation. There are some peculiarities here.
If the system is not very large and there are few different rights in it, then it is not difficult to identify common overlapping rights among employees of the same position. From them, you can compose a role, and then send it for approval and approval to the head, the owner of the resource and further along the chain, as in the first case. If the system has a lot of rights (powers), and it is used by a large number of employees from different departments, then the task becomes more complicated. In this case, specialized utilities come to the rescue, calledRole mining that make the task easier. They collect the matching entitlements for a specific job into a standard role that is reviewed and approved by stakeholders.
Building a role model using the second approach
In our large financial company, we built a role model using the second approach to bring order to already working systems. For those of them in which users had few rights, we took a cleared sample (only active users). We have developed a template for filling in the role matrix for each system: recall that the role matrix is roles (a set of rights) in relation to company departments and positions in them. The template was sent to the owners of these systems for completion. Those, in turn, collected information from the departments in which the system was used, and returned the already completed template for further coordination with the information security and internal control services. The completed template, namely the role matrix, is then used in granting role-based access as well as inclusion in a future automation project.
Unfortunately, there are no such matrices and such systems where all rights can be unambiguously divided into roles and roles are tied to positions. Because in this case you will either get some fairly universal roles, where some of the rights will be redundant. Or, on the contrary, there are too many roles, and this will no longer be role-based, but personal access based on the discretionary method, which we wrote about in the first part. Often in large organizations, roles may not be needed for a position, but for a specific functionality. For example, several employees may occupy the same position but perform different functions. Therefore, it makes sense to add part of the same functionality to the basic roles that will be assigned by default. And leave some of the unique functions of the employee for registration of rights for individual requests,which are sent for approval in accordance with the procedure established by the company.
Example template for filling out role matrices
Our template looked like this. On the first sheet on the left (vertically) positions and divisions were listed, and on top (horizontally) the roles. At the intersection, it was necessary to set a marker indicating which department needed which role / roles. We marked with a colored fill: green - roles that should be provided by default, upon appointment to a position; yellow - roles that can be requested for a specific position or department on a separate additional request.
On the second sheet, we placed a guide that showed the filling of roles with individual rights (powers).
The third sheet contains a matrix of SOD conflicts (prohibition on a possible combination of roles).
I must say right away that we approached the topic of SOD conflicts in the first approximation, since it is a separate large activity with its own process. The prohibition on the combination of certain powers can be established both within the framework of a separate role, and between roles, and in cross-system interactions. In addition, it is important to set up the process of working with SOD conflicts and develop scenarios for responding to them. This is a topic for separate consideration.
For systems with many users and a fairly diverse rights structure, it is very difficult to create a matrix manually. For these purposes, we used specialized tools for building a role model Role mining... These tools can differ greatly in the logic of work, cost, usability and other characteristics. But the principle of operation and goals they have in common is collecting information about the current rights of an employee in information systems, analyzing the repetition of these rights for employees with the same attributes, combining these rights into roles and, ultimately, building a certain basic role model that reflects the current status.
Now, with the passage of time and working for a company that develops software for access control, I realize that there are more effective methods of building role models in large systems. The sooner an organization adopts automated tidying tools, the smoother and more painless the role model building process will be. In this case, the automated system will be an assistant or help in building roles. Implementation of automated access control systems (IdM / IGA) should start with connecting personnel sources and target systems for uploading data and their mapping and analysis. By using specialized tools built into access control solutions, you can effectively build the necessary processes based on automation from the very beginning.This will significantly reduce labor costs and eliminate shock therapy in the future. For example, the process of working with accounts will go much faster and more efficiently, namely at the first stage:
- blocking found illegitimate accounts,
- identification of orphan accounts,
- identifying and registering external employee accounts, etc.
- automation of the creation of accounts when hiring an employee and blocking of accounts upon dismissal.
And already at the second stage, the use of automated access control systems makes it possible to increase the efficiency of working with user rights and build a role model, in particular:
- apply different methods of comparing rights for different users,
- carry out automated Role mining and identification of matching rights for certain categories of users with subsequent analysis and approval. This makes it much faster and easier to create the necessary access rights matrices.
We are implementing a new regulation of access rights
We got to the point where the company can begin to live according to the new access control regulations: grant access, modify and revoke, taking into account its new structure. What should be in this regulation:
- Access rights are determined by the presence / absence of a role model for a specific information system. As mentioned above, it is simply impossible to build role matrices for all ISs at once, you need to act gradually, in accordance with the approved plan.
- If there is no approved role model in the system yet, then the rights, at least, should be agreed with the head of the department and the owner of the resource.
- If the role model is developed and approved, then the rights are assigned / changed based on it.
- , .
. , , , .
. -, .
-, , , . IdM/IGA-, , . , , . , . , , . - . , .. , , . , , . . , .
The role model cannot be static. She, like a living organism, must adapt to the changes taking place in the organization. What is the reason for correcting it?
The first is a change in the organizational and staff structure.In large organizations, I was convinced of this from my own experience, such changes can occur almost daily. Changes are often associated with the renaming of departments and positions. At the same time, the functionality remains the same, but, nevertheless, these changes should be reflected in the role model and all adjustments should be made in a timely manner. When there is a merger of departments or, conversely, division into separate groups / departments, the changes are more global. They affect the functionality of employees, which needs to be revised, to update the functional model and, on its basis, make changes to existing roles. Or, design and implement new roles in the role model.
The second is a change in the company's business processes.Business cannot be static: new processes and mechanisms are being introduced that allow improving the work of each division. This improves customer service, increases sales, and helps to achieve strategic goals. The introduction of each new business process must be factored into the role model. New roles will appear, or the existing ones will have to be improved, and they will need to include new options and rights.
The third is changing the system architecture.Enterprises periodically decommission old systems and put new ones into operation. Let's say the old system is being decommissioned and the functionality that employees performed in it should be transferred to the new system. To do this, you will have to revise all the roles of the old system and their relevance, analyze the created roles of the new system and make a comparison matrix of old and new roles. It is quite possible that for some transitional period these roles will exist in parallel until all the necessary functionality is transferred to the new system and the role model is refined. Then the use of the roles of the old system can be stopped, user access can be revoked, and the data of the old system can be sent to the archive.
All of the changes we've seen suggest that a separate process is needed to keep the role model up to date. It should take into account all the activities of the organization related to access to information resources. It should include a process for updating the role model, which is planned in advance so that all necessary changes are made in time. This is the initiation of an application for changing the role / roles in automatic or manual mode, and the coordination and approval of changes and their commissioning with the updating of related processes. All this should be recorded in the regulations for maintaining and updating the role model, where it is also necessary to indicate who is responsible for each step of the process.
In addition to changes in the role model based on the above reasons, a systematic and planned revision of rights is needed. In particular, for financial companies, such regular reviews are required by supervisors. Revisions help identify gaps in the existing rights model and improve control over user rights. The solution to this problem is greatly simplified by IGA / IdM systems, which allow automating the process of revision (recertification) with a specified frequency.
Let's sum up
Access control using a role-based model increases the level of information security of the company, since access becomes more transparent, managed and controlled. It also reduces the burden on the IT department in terms of its administration. What can be done easier with role-based access control?
- You will be able to grant the same rights to many employees in the same position or working in the same department. It is enough to give them the same role.
- You can change the rights for employees of one position quickly, in a few clicks. It is enough to add or remove rights as part of a common role.
- You will be able to build a hierarchy of roles and set rules for inheriting authority, which simplifies the access structure.
- You will be able to enter the division of authority (SOD) - a prohibition on the combination of one role with another.
However, building a role model alone does not resolve the issue of high-quality and effective access control in a large company - this is only one of the steps. If you build a role model and calm down on this, after some time it will become outdated, and the great work done will be absolutely useless. Why?
- - , , - .
- - , -.
- .
- C .
- , , , .
- .
All of these reasons indicate that it is the set of measures for access control that is important. We need automation tools, working processes and mechanisms, their support, development, updating and scaling in accordance with the life cycle of the company.
Author: Lyudmila Sevastyanova, Promotion Manager, Solar inRights