Identity Management - basic account management
Today we will start a conversation about systems of the class Identity Management. As many of you know, July 1, the expiration date of the delay of the entry into force of the Federal Law of the Russian Federation of July 27, 2006 No. 152- “On Personal Data” expired
Accordingly, for the management of personal data in IT, large companies will have to implement specialized IDM systems to manage information about the users of their corporate systems. If earlier there was a certain shortage of qualified personnel in this area, now this deficit will take on a catastrophic scale, as thunder struck, and the peasant was supposed to begin to be baptized.
The lack of personnel in this specialized area is due to the fact that an IDM specialist should possess several IT skills at once - he should be well versed in the design of various information security systems, have practical system administration experience, be a good programmer for writing adapters and data processing scripts, be able to describe and set up business processes. And while he should not be mad about the huge amount of routine work on the reconciliation of personal data. I can say with almost absolute certainty that such people in nature do not exist. This fact is connected with the eternal headache of HR employees, who generally vaguely imagine our specifics, and here they also have to deal with such an explosive mixture of incompatible skills.
')
The only way out of the situation is the division of work for at least two. One can program connectors to security systems, customize internal workflow, write scripts and do deployment. The second must work with user data, describe business processes, engage in documenting and promoting the idea of ​​IDM in the IT of the masses.
I hasten to disappoint fellow programmers. In this series of articles, emphasis will be placed on the business and production part of IDM implementation, as well as on practical techniques for implementing and working with user data. Because we have few intelligent programmers, but you can find it. But people who understand why all this is being done can be counted on fingers in Moscow.
I sincerely hope that after reading this material, colleagues will gain clarity on this issue, and many programmers or system administrators will be able to go to the IDM business analyst camp to compete with the few “stars” working in this field.
Identity is a personality. All that constitutes information about a real person is Identity: his name, gender, position, year of birth, attributes of his accounts in the systems. In certain combinations, information about a person is subject to the protection of federal laws and should be managed. Processes and personal data management systems are called Identity Management, or IDM.
Where is the personal information about the employees of the company? Of course, in the personnel system. And also - in the Active Directory, in the cards of users of several dozen application systems, in the data of mail programs, in client management systems, in billing systems, in service desk systems ... Often this information is not consistent. One and the same person can be registered in a dozen systems at the same time, and no one can guarantee that he is registered in them equally and correctly.
One of the main tasks of IDM is to create a single and up-to-date catalog of personal information as a basis for the further development of management processes.
User accounts and their attributes (for example, access groups) are the same piece of personal information as postal addresses, names, and positions. Active Directory specialists will confirm that this is all stored in the system database in a similar way. Accordingly, it would be logical to include in the framework of the IDM process at the same time access control to information systems (Access Management). Often, IDM is understood to mean Identity and Access Management (IAM), just an abbreviation of IDM, people like more.
The results of a successful IDM implementation can be divided into “static” and “dynamic”. The first are the results of “what happened?”. And the second "And how does it work?"
The static result of a successful IDM implementation is order in user accounts, which is as follows:
The dynamic component of a successful implementation is, in fact, an account management process that works like a clock. Here is an example of the criteria for such a process:
In the entire described blissful picture one small but very important component is missing. An attentive reader may notice that we have learned how to start and block accounts, synchronize directories, but we still do not have an answer to the question: “ Where , in fact, should one or another user be allowed and what rights does he need to work?” Search for an answer to this The issue is often the largest part of all the work in an IDM implementation project.
The rights (privileges) of a user in different systems depend only and exclusively on his official duties. And the more diverse his responsibilities, the more difficult it is to determine the principles for the assignment of these privileges.
In the simplest case, the user's rights are determined by his position, and the physical location of his workplace. This is typical of massive interchangeable positions - various operators, call center employees, conveyor line workers, etc.
The task is complicated when the duties of the employee include additional activities that are not characteristic of his colleagues. For example, an employee is responsible for ordering office supplies for his entire department. To do this, he is given access to a certain system, where he comes in once a quarter, presses three buttons there and forgets about it for the next three months. And there are such users in every department. Accountants of large companies, who are known to often specialize in different areas and use different systems while being in the same position, also present a similar headache.
An even more difficult case is when the company has internal projects or other irregular activities that require temporary groupings of employees for various reasons. For example, an ERP system is being introduced, and all members of the working group receive temporary access to the test site. Or the company is working on a new presentation template, and key employees have been admitted to the marketing portal to evaluate design layouts. But you never know what else could be! Writing the necessary powers in such a situation is still half the battle. Try to recall them correctly and in time! In 90% of companies, the authority is never revoked. Long-time employees are gradually acquiring accesses, like ships with shells. After two or three years, no one can really tell where their number of privileges comes from. If the accounts themselves are still somehow controlled by the application administrators by number and intended owners, then within one account the devil himself will break his leg.
To estimate the scale of the disaster I will give some figures. Suppose a company has 1000 users, 10 systems, and each system has 10 different privileges. Some systems are tied, for example, to Active Directory, and some have their own authentication system. Thus, on average, for each user, there are, for example, 3 accounts. Total we have 3000 accounts. Each user has an average of 5-7 privileges in their systems. Total we have 15 -20 thousand assignments of privileges to users. Each assignment of privileges was made in due time not just like that, but with meaning. And the meaning tends to disappear with time.
To understand all this, as you understand, you need to do serious work. In manual mode, you can cope with a small number of systems and iron discipline. But if entities become too much for the average person, you have to think about automating the process and applying elements of role-based access control (Role Management). RM is now an extremely fashionable and popular area in the field of middleware. For an outside observer, it costs unthinkable money and it is not clear what it does. Systems of this class are offered in vain by leading software giants such as Oracle (aka Sun), IBM, Microsoft. Many copies are broken in meaningless debates about the benefits of a particular platform. From experience, I can say that all systems will be equally stupid if we do not pay due attention to restoring order in business processes.
Generally speaking, the mechanics of these systems are of little interest to me, since the success of the implementation lies not in the original engine and not in the programming language used, but in the correct formation of role models and in fine-tuning the business rules. The quality of a particular system is determined by the convenience of forming a role model and flexibility in setting up business rules. All leading manufacturers are trying to optimize precisely these parameters of their development, along with an increase in the number of ready-made connectors and a general increase in the reliability of the engine.
In the case of IDM implementation, it is not necessary, as is customary in our country, to immediately rush to install software in the hope that the cart will pull the horse along. Miracle, as usual, does not happen, and you break wood for years to come. After all, IDM systems are being introduced into the “our all” system administrators - user authentication. Fallen IDM can paralyze the work of the entire company. A crookedly tuned engine will lead to the fact that the old “hemorrhoids” with prescription of a new user manually will seem to the admins a good tale. Needless to say, how everything around you will perceive you and your system.
As an example, I can cite a funny glitch in the algorithm for resolving conflicts when forming the namesakes of namesakes, which led to the automatic generation of hundreds of accounts at once. Imagine now the delight of the customer who pays a license for each account in the system they bought. Only by a miracle was it possible to hush up the scandal. But the spoons were found, and the sediment remained.
Russian realities are such that even in the most developed and progressive companies, the mess in user privileges is incredible. Despite the periodic stripping and inventory of accounts, nobody combines the privileges of users with a fine comb, especially with high-ranking employees. Also, there is often no order with service, guest and administrative accounts, since they are not associated with specific people and it is generally not clear what to do with them.
It turns out that information security officers are sitting on a time bomb, as they do not know the answer to the auditor’s basic question: “Who has access to this or that system on what basis?” And that they will have to deal with this issue more and more often, there is a fact established by science. Responding to it at any time (and not only after a month of manual reconciliation of privileges) will help the IDM class system with additional functionality of role-based access control.
In the following publications we will address the organization of the project implementation of IDM, as well as various practical approaches to creating role models.
PS Changed the name of the topic to better reflect its essence.
Was: Identity Management - the basics of personal data management
It became: Identity Management - the basics of account management
Accordingly, for the management of personal data in IT, large companies will have to implement specialized IDM systems to manage information about the users of their corporate systems. If earlier there was a certain shortage of qualified personnel in this area, now this deficit will take on a catastrophic scale, as thunder struck, and the peasant was supposed to begin to be baptized.
The lack of personnel in this specialized area is due to the fact that an IDM specialist should possess several IT skills at once - he should be well versed in the design of various information security systems, have practical system administration experience, be a good programmer for writing adapters and data processing scripts, be able to describe and set up business processes. And while he should not be mad about the huge amount of routine work on the reconciliation of personal data. I can say with almost absolute certainty that such people in nature do not exist. This fact is connected with the eternal headache of HR employees, who generally vaguely imagine our specifics, and here they also have to deal with such an explosive mixture of incompatible skills.
')
The only way out of the situation is the division of work for at least two. One can program connectors to security systems, customize internal workflow, write scripts and do deployment. The second must work with user data, describe business processes, engage in documenting and promoting the idea of ​​IDM in the IT of the masses.
I hasten to disappoint fellow programmers. In this series of articles, emphasis will be placed on the business and production part of IDM implementation, as well as on practical techniques for implementing and working with user data. Because we have few intelligent programmers, but you can find it. But people who understand why all this is being done can be counted on fingers in Moscow.
I sincerely hope that after reading this material, colleagues will gain clarity on this issue, and many programmers or system administrators will be able to go to the IDM business analyst camp to compete with the few “stars” working in this field.
What is Identity Management?
Identity is a personality. All that constitutes information about a real person is Identity: his name, gender, position, year of birth, attributes of his accounts in the systems. In certain combinations, information about a person is subject to the protection of federal laws and should be managed. Processes and personal data management systems are called Identity Management, or IDM.
Where is the personal information about the employees of the company? Of course, in the personnel system. And also - in the Active Directory, in the cards of users of several dozen application systems, in the data of mail programs, in client management systems, in billing systems, in service desk systems ... Often this information is not consistent. One and the same person can be registered in a dozen systems at the same time, and no one can guarantee that he is registered in them equally and correctly.
One of the main tasks of IDM is to create a single and up-to-date catalog of personal information as a basis for the further development of management processes.
IDM, IAM, RM - WTF?
User accounts and their attributes (for example, access groups) are the same piece of personal information as postal addresses, names, and positions. Active Directory specialists will confirm that this is all stored in the system database in a similar way. Accordingly, it would be logical to include in the framework of the IDM process at the same time access control to information systems (Access Management). Often, IDM is understood to mean Identity and Access Management (IAM), just an abbreviation of IDM, people like more.
The results of a successful IDM implementation can be divided into “static” and “dynamic”. The first are the results of “what happened?”. And the second "And how does it work?"
The static result of a successful IDM implementation is order in user accounts, which is as follows:
- All accounts in all systems are distributed to specific people, including technological ("uchetka" processes and systems) and system ("admin uchetki")
- All account attributes are consistent with each other (for example, the last name and corporate phone number are the same everywhere)
- We know exactly what rights in which systems each employee has
The dynamic component of a successful implementation is, in fact, an account management process that works like a clock. Here is an example of the criteria for such a process:
- When recruiting new employees, transferring employees to other positions, dismissing employees, the attributes of their accounts in information systems change simultaneously and consistently.
- Accounts for new employees are automatically created according to predetermined rules (including the launch of various magic scripts and other dances with a tambourine). The new employee can start work almost immediately after registration in frames, if he was given a computer, of course.
- Accounts of dismissed or unreliable employees are blocked simultaneously in all systems with which they worked. Thus, the damage from "offended" will be minimized.
- Each employee has at each moment of time only that set of privileges which is necessary for him for performance of official duties. Extra privileges are missing.
In the entire described blissful picture one small but very important component is missing. An attentive reader may notice that we have learned how to start and block accounts, synchronize directories, but we still do not have an answer to the question: “ Where , in fact, should one or another user be allowed and what rights does he need to work?” Search for an answer to this The issue is often the largest part of all the work in an IDM implementation project.
The rights (privileges) of a user in different systems depend only and exclusively on his official duties. And the more diverse his responsibilities, the more difficult it is to determine the principles for the assignment of these privileges.
In the simplest case, the user's rights are determined by his position, and the physical location of his workplace. This is typical of massive interchangeable positions - various operators, call center employees, conveyor line workers, etc.
The task is complicated when the duties of the employee include additional activities that are not characteristic of his colleagues. For example, an employee is responsible for ordering office supplies for his entire department. To do this, he is given access to a certain system, where he comes in once a quarter, presses three buttons there and forgets about it for the next three months. And there are such users in every department. Accountants of large companies, who are known to often specialize in different areas and use different systems while being in the same position, also present a similar headache.
An even more difficult case is when the company has internal projects or other irregular activities that require temporary groupings of employees for various reasons. For example, an ERP system is being introduced, and all members of the working group receive temporary access to the test site. Or the company is working on a new presentation template, and key employees have been admitted to the marketing portal to evaluate design layouts. But you never know what else could be! Writing the necessary powers in such a situation is still half the battle. Try to recall them correctly and in time! In 90% of companies, the authority is never revoked. Long-time employees are gradually acquiring accesses, like ships with shells. After two or three years, no one can really tell where their number of privileges comes from. If the accounts themselves are still somehow controlled by the application administrators by number and intended owners, then within one account the devil himself will break his leg.
To estimate the scale of the disaster I will give some figures. Suppose a company has 1000 users, 10 systems, and each system has 10 different privileges. Some systems are tied, for example, to Active Directory, and some have their own authentication system. Thus, on average, for each user, there are, for example, 3 accounts. Total we have 3000 accounts. Each user has an average of 5-7 privileges in their systems. Total we have 15 -20 thousand assignments of privileges to users. Each assignment of privileges was made in due time not just like that, but with meaning. And the meaning tends to disappear with time.
To understand all this, as you understand, you need to do serious work. In manual mode, you can cope with a small number of systems and iron discipline. But if entities become too much for the average person, you have to think about automating the process and applying elements of role-based access control (Role Management). RM is now an extremely fashionable and popular area in the field of middleware. For an outside observer, it costs unthinkable money and it is not clear what it does. Systems of this class are offered in vain by leading software giants such as Oracle (aka Sun), IBM, Microsoft. Many copies are broken in meaningless debates about the benefits of a particular platform. From experience, I can say that all systems will be equally stupid if we do not pay due attention to restoring order in business processes.
Generally speaking, the mechanics of these systems are of little interest to me, since the success of the implementation lies not in the original engine and not in the programming language used, but in the correct formation of role models and in fine-tuning the business rules. The quality of a particular system is determined by the convenience of forming a role model and flexibility in setting up business rules. All leading manufacturers are trying to optimize precisely these parameters of their development, along with an increase in the number of ready-made connectors and a general increase in the reliability of the engine.
In the case of IDM implementation, it is not necessary, as is customary in our country, to immediately rush to install software in the hope that the cart will pull the horse along. Miracle, as usual, does not happen, and you break wood for years to come. After all, IDM systems are being introduced into the “our all” system administrators - user authentication. Fallen IDM can paralyze the work of the entire company. A crookedly tuned engine will lead to the fact that the old “hemorrhoids” with prescription of a new user manually will seem to the admins a good tale. Needless to say, how everything around you will perceive you and your system.
As an example, I can cite a funny glitch in the algorithm for resolving conflicts when forming the namesakes of namesakes, which led to the automatic generation of hundreds of accounts at once. Imagine now the delight of the customer who pays a license for each account in the system they bought. Only by a miracle was it possible to hush up the scandal. But the spoons were found, and the sediment remained.
Russian realities are such that even in the most developed and progressive companies, the mess in user privileges is incredible. Despite the periodic stripping and inventory of accounts, nobody combines the privileges of users with a fine comb, especially with high-ranking employees. Also, there is often no order with service, guest and administrative accounts, since they are not associated with specific people and it is generally not clear what to do with them.
It turns out that information security officers are sitting on a time bomb, as they do not know the answer to the auditor’s basic question: “Who has access to this or that system on what basis?” And that they will have to deal with this issue more and more often, there is a fact established by science. Responding to it at any time (and not only after a month of manual reconciliation of privileges) will help the IDM class system with additional functionality of role-based access control.
In the following publications we will address the organization of the project implementation of IDM, as well as various practical approaches to creating role models.
PS Changed the name of the topic to better reflect its essence.
Was: Identity Management - the basics of personal data management
It became: Identity Management - the basics of account management
Source: https://habr.com/ru/post/123428/
All Articles