Identity Management - Account Management Fundamentals

    Today we will begin the discussion of Identity Management class systems. As many of you know, on July 1 the deadline for the entry into force of the federal law of the Russian Federation of July 27, 2006 No. 152-ФЗ On Personal Data expired .

    Accordingly, large companies will be forced to introduce specialized IDM class systems to manage personal data in IT managing information about users of their corporate systems. If before there was a certain shortage of qualified personnel in this area, now this deficit will take on a catastrophic scale, as thunder has struck, and the peasant is supposed to begin to be baptized.

    The shortage of personnel in this specialized field is due to the fact that an IDM specialist must have several IT skills at once - he must be well versed in the design of various information security systems, have practical experience in system administration, be a good programmer for writing adapters and data processing scripts, and be able to Describe and set business processes. And at the same time, he should not rave about the huge amount of routine work on reconciling personal data. I can almost with absolute certainty say that such people do not exist in nature. Related to this fact is the eternal headache of HR employees, who generally vaguely imagine our specifics, and then they have to deal with such an explosive mixture of incompatible skills.

    The only way out of the situation is to divide the work into at least two. One can program security system connectors, configure internal workflows, write scripts, and deploy. The second is to work with user data, describe business processes, document and promote IDM ideas in the IT masses.

    I hasten to disappoint fellow programmers. In this series of articles, emphasis will be placed on the business and production part of the implementation of IDM, as well as on practical techniques for implementing and working with user data. Because we have few intelligent programmers, but you can find. But people who understand why all this is being done can be counted on the fingers in Moscow.

    I sincerely hope that after reading this material, my colleagues will increase clarity on this issue, and many programmers or system administrators will be able to go to the IDM business intelligence camp to compete with the few "stars" working in this field.

    What is Identity Management?

    Identity is a person. Everything that makes up information about a real person is Identity: his name, gender, position, year of birth, attributes of his accounts in systems. In certain combinations, information about a person is subject to federal laws and should be managed. Processes and systems for managing personal data are called Identity Management, or IDM.

    Where is personal information about company employees stored? Of course, in the personnel system. And also in the Active Directory, in the user cards 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 will guarantee that he is registered in them equally and correctly.

    One of the main tasks of IDM is the creation of a single and relevant catalog of personal information as the basis for the further development of management processes.

    IDM, IAM, RM - WTF?

    User accounts and their attributes (for example, access groups) are the same part of personal information as mail addresses, names and positions. Active Directory experts will confirm that this is all stored in the system database in a similar way. Accordingly, it would be logical to include access management to information systems (Access Management) in the framework of the IDM process. Often, IDM is understood as Identity and Access Management (IAM), just the acronym IDM people like more.

    The results of the successful implementation of IDM can be divided into “static” and “dynamic”. The first are the results of "what has become?" And the second is “And how does it work?” The

    static result of the successful implementation of IDM is the order in user accounts, which is as follows:
    • All accounts in all systems are distributed by specific people, including technological ("records" of processes and systems) and system ("admin accounts")
    • All account attributes are consistent with each other (for example, the surname 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 hiring new employees, transferring employees to other positions, dismissing employees, the attributes of their accounts in information systems change in parallel and consistently
    • Accounts for new employees are automatically generated according to predefined rules (including the launch of various magic scripts and other dances with a tambourine). A new employee can get to work almost immediately after registration in frames, if he was given a computer, of course.
    • The accounts of dismissed or unreliable employees are blocked simultaneously in all systems with which they worked. Thus, the damage from the “offended” will be minimized.
    • Each employee at each moment of time has only that set of privileges that he needs to perform official duties. Extra privileges are missing.

    In the whole described good picture, one small but very important component is missing. An attentive reader may notice that we have learned to start and block accounts, synchronize directories, but we still have no answer to the question: “ Where , in fact, do you need to allow this or that user and what rights do he need to work?” Search for an answer to this the issue often accounts for most of the work of the IDM implementation project.

    The rights (privileges) of the user in various systems depend solely and exclusively on his official duties. And the more diverse his responsibilities, the more difficult it is to determine the principles for assigning 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 for mass interchangeable positions - various operators, call center employees, conveyor line workers, etc.

    The task is complicated when an employee's duties 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 visits once a quarter, presses three buttons there and forgets about it for the next three months. And such users are in every department. Similar headaches are also presented by accountants of large companies, which, as you know, often specialize in different fields and use different systems, while being in the same position.

    An even more complicated case is when the company has internal projects or other irregular activities that require temporary groupings of employees on one or another basis. For example, an ERP system is being introduced, and all members of the working group get temporary access to the test site. Or the company is working on a new presentation template, and key employees were admitted to the portal marketing services to evaluate the design layouts. But you never know what else could be! Giving the necessary authority in such a situation is still half the battle. Try to recall them in time and on time! In 90% of companies, user credentials are never revoked. Long-working employees are gradually gaining access, like ships in shells. After two or three years, no one can really tell where they got so many privileges from. If the accounts themselves are still somehow controlled by the application administrators in terms of number and intended owners, then within the framework of one account the devil will break his leg.

    To assess 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 systems. Thus, on average, for each user, for example, there are 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 privilege assignments to users. Each assignment of privileges was made at one time not just like that, but with meaning. And the meaning has the property of disappearing over time.

    To understand all of this, as you understand, you need to do some serious work. In manual mode, you can manage with a small number of systems and iron discipline. But if there are too many entities for an ordinary person, you have to think about the automation of the process and the use of role-based access control elements(Role Management). RM is now an extremely fashionable and popular trend in the field of middleware. For an outside observer, it costs inconceivable money and it is not clear what it is doing. Systems of this class are competed by leading software giants such as Oracle (aka Sun), IBM, and Microsoft. Many copies are broken in senseless disputes about the advantages of a particular platform. From experience, I can say that all systems will be equally stupid if we do not pay due attention to putting things in 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 proprietary engine and not in the programming language used, but in the correct formation of role models and in the fine tuning of business rules. The quality of a particular system is determined by the convenience of forming a role model and the flexibility in setting up business rules. All leading manufacturers are trying to optimize precisely these parameters of their developments, along with the expansion of the number of ready-made connectors and a general increase in the reliability of the engine.

    In the case of the introduction of IDM, it is not necessary, as is customary for us, to immediately rush to install software in the hope that the cart will pull the horse along with it. A miracle, as usual, will not happen, but you’ll break firewood for years to come. After all, IDM systems are being implemented in the “our everything” system administrators - in user authentication. Fallen IDM can paralyze the work of the entire company. The crooked engine will lead to the fact that the previous “hemorrhoids” with prescribing a new user manually will seem to administrators a good tale. Needless to say, everyone around you will then receive you and your system.

    As an example, I can cite a funny glitch in the conflict resolution algorithm when forming accounts of namesakes, which led to the automatic generation of hundreds of accounts at once. Imagine now the delight of the customer who pays the license for each account in the system he purchased. Only by miracle did they manage to hush up the scandal. But spoons were found, but 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 cleaning and inventory of accounts, no one combes the privileges of users with a small comb, especially among high-ranking employees. Also, often there is no order with official, 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 the employees of the information security departments are sitting on a time bomb because they don’t know the answer to the auditor’s basic question: “Who and on what basis has access to a particular system?” And what will they have to face all this more and more often, there is a fact established by science. The answer to it at any time (and not just after a month of manual reconciliation of privileges) will help IDM class systems with the additional functionality of role-based access control.

    In the following publications, we will address the organization of the IDM implementation project, as well as various practical approaches to creating role models.

    PS Changed the name of the topic so that it better reflects its essence.
    Was: Identity Management - the basics of personal data management
    Now: Identity Management - The Basics of Account Management

    Also popular now: