Hell with accounts - why in one company of users was 3 times more, than employees
Prydstoriya . There were about two dozen (!) Personnel bases in one production company. These are the bases of separate subdivisions, and in each of them there are several hundred people. Only about 10 thousand employees. The system administrator works literate, there is a working MS Active Directory.
The quest began at the moment when the security men asked to check a certain Petrov. According to their feelings, he had more rights than he was given on applications from the units. The administrator had to pick up all these paper documents from the archive and bypass half of the company's divisions. For the sake of one employee. While he walked for about two weeks, they decided to check the whole department.
At the same time, the admin realized another terrible thing: the company actually employs about three times fewer people than the accounts in his system. Why? Yes, everything is simple: registrations were opened by written requests, and when leaving and transferring, they often forgot to update their status.
')
At this point, we started working on the implementation of a common solution for managing accounts and access rights, IdM . To begin with, we had to get rid of fragmentation and reduce all personnel bases into one intermediate personnel system. She was tied to Active Directory through a new repository center. Then the rest of the business systems were connected to the repository like this:
Then we removed all unnecessary registrations, left only actual employees (at the same time we saw a couple of dismissed, but actively logged in). Then they found a couple of very strange people ...
For example, there were the accounts of A. M. Ivanov and A. M. Ivanov (visually - one employee, but the second has a in the English surname: either an error, or someone “cloned” him specifically).
Then they automatized the process of assigning rights to personnel documents. We made a self-service portal where employees could request access where needed. And no longer the admin, but the head of the relevant department confirmed it. It took two months to audit and understand the processes, two more to finish the software and tests, the last one was to introduce and train IT specialists.
That's about it. This story is generally real, but I specifically changed some details so as not to reveal the customer. The most interesting thing about it is that very few people, it turns out, even understood how IdM systems work. Therefore, I am writing this topic.
Usually in a large company, at some point real hell begins with user accounts. One employee will have at least 3-4 different accounts. Manage them from a single center does not work. When transferring from department to department, you need to do a bunch of things with your hands. Plus, there are legal requirements for the protection of personal data , a security policy for each account, and so on.
You can live with this by increasing the number of manual operations, and you can configure IdM, an identity and access rights management system.
What does this look like? Pretty nice: for example, with all the same transfer of an employee from one department to another, you update his data in one repository. Then, for example, in 1C the rights change, in the corporate telephone directory the position changes, in the business application the account is updated, in the workflow system there are new links on business processes. And so on.
So, if your company is big enough, then there are three options for the development of the situation:
- There is some chaos with the records . For example, when an employee comes to work, he needs to be given access to many information systems. For the first couple of days, he may not use corporate resources at all, or sit back with his predecessor's account, which is not very good. Secondly, if everything is done manually, there will be errors, such as redundant rights in a number of systems. Thirdly, if there is no exact process, much will be tied to specific people, with the increase or the care of which will have to re-restore the access control system. When such calls appear, it is, strictly speaking, an occasion to reflect on the implementation of IdM.
- You have full order, but a lot of actions are done by hand . IdM will help automate this. The more vendors of corporate systems, the more “joints” can be built through IdM.
- You have one vendor system (when IdM is simply not needed, everything is done through one account), or there is IdM in one form or another. I saw, for example, that in single-end systems there is agreement on applications (yes, even by mail, if business processes are debugged), and everything works. So everything is simple.
Each employee of the company corresponds to a user of the IdM system, created on the basis of personnel data received from a trusted system (for example, an HR system). The accounts in the target information systems are created only with the help of the IdM system and are linked to a specific employee. Thus, any account in the information system always corresponds to its owner — an employee of the company.
It must be said that the introduction of IdM in a complex multivendor environment with many different systems and still geographically separated units is not a trivial task. And difficult to manage. The principle is usually - “don't touch while it works”, so you need to think about such things either in advance, when it is still easy to implement the system, or look for reasons. And here are your best friends be safe. Because they certainly know what only one account can cost. And what's more, for sure they have examples of very unpleasant situations for the company, the repetition of which they would not really want. And you can help them.
There are two ways: based on rules that are configured in the system (for example, to all security personnel — such resources are available, to all heads of departments — such-and-so and so on). And by request. For example, someone from the purchase wants more data about the product and he needs to get access to 1C. He sends a request, the system keeps track of the hierarchy, sends it, for example, to the financial director. If he confirms the application, the person gets access.
The first stage is a mandatory survey. Based on the results of this audit, we determine the existing business processes related to the management of credentials and access. And second, we draw a target picture in which the system must be implemented, and we propose a technical solution with which this idea, in general, can be realized again.
An audit is required to be included in the survey phase - a check of the technical infrastructure. The point is that one system can store identification data, for example, in a database, the other system - in a flat file. We also examine the interfaces through which these systems can communicate in the future with IdM (interface and protocols) in order to understand the possibility in general and the complexity of integration.
Here, the main thing, without excessive fanaticism. You know, as it happens - "spent 5 hours writing an algorithm that solves a problem in 5 seconds, which I would consider manually 3 hours." So, there are systems that do not need to be fully integrated. For example, the company has a thousand employees and in one of the systems only 50 people work. And this is one department, and the turnover of this department is very small. Perhaps there is an economic need not to integrate this system with the IBT manager, but to cross it with IdM in manual mode. That is, if necessary, a letter will be sent to the administrator of this system with a request to issue access rights to one or another employee. Such options are also possible. We, in particular, had an example in a company for 10 thousand people, when the personnel system, in which 5 people work, had technical limitations, and we invited the customer to consider just such an option. In the end, did so.
Connectors are being developed for integration - small software modules that allow you to take data from systems and, conversely, provide these data to systems. Usually done or the revision of standard connectors or development from scratch (most often for domestic systems: Americans usually have everything at once out of the box sharpened for the needs of big business).
For users to work according to the usual patterns, most of the events can be duplicated in the mail. As previously confirmed by the financial director, access by letter, and can continue - only now a letter is written to him by a robot from IdM and asks just to click on the link "yes" or "no."
When everything is ready, it turns out a scheme where every person in the company has rights. And this is real happiness for the entire security department and financial director. Comprehensive reporting and holistic vision appear. For example, before the introduction of the system, an understanding of who has what rights, it was a whole quest with a detour of all units. After implementation - a couple of clicks. Two favorite questions at this stage are: “how far are the issued rights correspond to the rights requested in the applications,” “how much do they correspond to business need and corporate security policies”. The answers are exhaustive and often unexpected for those who only estimated the level of errors before the introduction of the system.
In parallel, the second part of the mathematical problem appears - the calculation of optimal rights. Yes, yes, we do some Data Mining (although, loudly said for most of the cases). And we show how you can optimally divide rights. Identify some things that should not be in a normal structure, which can lead to increased risks associated with access.
Another feature: every change of rights has a basis. For example, when the admin used to hand a new employee right — this was always at his own risk. Now the system works on the basis of: an order to receive a person, confirmation of a request from a manager, and so on. Just take and change the data in the corporate directory will not work: the data from HR managers are considered more trusted.
Very pleased with the convenience of updating the rights. IdM systems can monitor situations where rights are granted, but the person is no longer needed. For example, the employee does not perform work that requires access to the company's financial reports, but he has such access. The system can detect this pattern and issue a recommendation to remove these rights.
Then users become happy. They have one entry system, when it is enough to log in once at the workplace and automatically get access within their authority. No papers with passwords with a bunch of applications and services - you only need to remember your input, (note, this is a broader SSO task, IdM systems do not always solve it).
After implementation, when the whole company looked askance at the "inventors" from the IT department, changing the usual way of things, you can relax and start having fun. Changes from one place, a convenient picture of rights, scripted actions, such as creating a box for a new employee after updating documents with personnel officers, and so on, are a thrill. The employee clears the password for himself, his manager unlocks his manager, and the IT department has a log of actions if it is necessary to find the cause of the problem. True, it will take some time to sweat with a painstaking adjustment (there will be a period of rather lengthy “finishing”), but it's worth it.
Yes, you understood correctly that IdM is very nervous. The fact is that applications for access are no longer sent to the system administrator, but to the person who must confirm such access. The head of the department, the financial director, the security officers - in general, those who are directly responsible for the question. And this means that if earlier, when something was wrong, the admin was to blame, but now it is clearly understood who gave what and to whom. And the admin only provided the protocol.
For them there are special words that like music caress the ear of the whole department. These include a decrease in the total cost of implementation, a decrease in the cost of ownership, a reduction in the required technical resources, a clear architecture, a reduction in the cost of servicing and operating the solution, and a phased implementation of the solution without affecting the continuity of the company's processes . Phew In general, this is both refactoring and optimization immediately.
In the United States and Europe, such systems have long been, and many are used to them. It would be strange if in our country there were no peculiarities of the mentality associated with access rights. The main problem - the power of attorney sources. For example, personnel officers in many places just love to add all the data backdated to the system, already at the time of dismissal. This is a professional shift, because the workbook is filled in fact at this very moment.
Often there are situations when you need to make special privileges to the leadership. That is, some rule is introduced, but in fact the tops are not followed. When the rule is automated, bosses can expect a surprise - for example, automatic unloading of cell phones into the general directory of company contacts. It is clear that after a couple of calls from clients immediately to the director, we have finalized this rule in practice.
Licenses are expensive. There are a lot of conditions, but usually it turns out to be tens to several hundred dollars per employee. Directly, due to the time saved, the system pays off in 3-4 years, but usually the assessment is based on the benefits of security personnel and transparent reporting. Another feature is that when a company is audited, for example, before selling (merging) or certifying, such systems are perceived very positively.
Initially, there were no access control repositories alone. The task was to understand "who and where has the right to go." Modules were connected to all points of the login, which simply fixed who entered. The access map was slowly lined up, which was reported. On the other hand, the centers for issuing uniform rights, which formed such a map, developed in parallel. As a result, symbiotic solutions have now appeared: first, they operate in read-only mode and collect relevant data on rights, then transfer module by module to active management, and then allow global automation to be done. And this is all calm, smoothly and smoothly for users.
PS If you have questions about a specific configuration for your case or you cannot ask a question in the comments, write directly to me at AZaikin@croc.ru.
The quest began at the moment when the security men asked to check a certain Petrov. According to their feelings, he had more rights than he was given on applications from the units. The administrator had to pick up all these paper documents from the archive and bypass half of the company's divisions. For the sake of one employee. While he walked for about two weeks, they decided to check the whole department.
At the same time, the admin realized another terrible thing: the company actually employs about three times fewer people than the accounts in his system. Why? Yes, everything is simple: registrations were opened by written requests, and when leaving and transferring, they often forgot to update their status.
')
At this point, we started working on the implementation of a common solution for managing accounts and access rights, IdM . To begin with, we had to get rid of fragmentation and reduce all personnel bases into one intermediate personnel system. She was tied to Active Directory through a new repository center. Then the rest of the business systems were connected to the repository like this:
Then we removed all unnecessary registrations, left only actual employees (at the same time we saw a couple of dismissed, but actively logged in). Then they found a couple of very strange people ...
For example, there were the accounts of A. M. Ivanov and A. M. Ivanov (visually - one employee, but the second has a in the English surname: either an error, or someone “cloned” him specifically).
Then they automatized the process of assigning rights to personnel documents. We made a self-service portal where employees could request access where needed. And no longer the admin, but the head of the relevant department confirmed it. It took two months to audit and understand the processes, two more to finish the software and tests, the last one was to introduce and train IT specialists.
That's about it. This story is generally real, but I specifically changed some details so as not to reveal the customer. The most interesting thing about it is that very few people, it turns out, even understood how IdM systems work. Therefore, I am writing this topic.
General about IdM
Usually in a large company, at some point real hell begins with user accounts. One employee will have at least 3-4 different accounts. Manage them from a single center does not work. When transferring from department to department, you need to do a bunch of things with your hands. Plus, there are legal requirements for the protection of personal data , a security policy for each account, and so on.
You can live with this by increasing the number of manual operations, and you can configure IdM, an identity and access rights management system.
What does this look like? Pretty nice: for example, with all the same transfer of an employee from one department to another, you update his data in one repository. Then, for example, in 1C the rights change, in the corporate telephone directory the position changes, in the business application the account is updated, in the workflow system there are new links on business processes. And so on.
So, if your company is big enough, then there are three options for the development of the situation:
- There is some chaos with the records . For example, when an employee comes to work, he needs to be given access to many information systems. For the first couple of days, he may not use corporate resources at all, or sit back with his predecessor's account, which is not very good. Secondly, if everything is done manually, there will be errors, such as redundant rights in a number of systems. Thirdly, if there is no exact process, much will be tied to specific people, with the increase or the care of which will have to re-restore the access control system. When such calls appear, it is, strictly speaking, an occasion to reflect on the implementation of IdM.
- You have full order, but a lot of actions are done by hand . IdM will help automate this. The more vendors of corporate systems, the more “joints” can be built through IdM.
- You have one vendor system (when IdM is simply not needed, everything is done through one account), or there is IdM in one form or another. I saw, for example, that in single-end systems there is agreement on applications (yes, even by mail, if business processes are debugged), and everything works. So everything is simple.
Each employee of the company corresponds to a user of the IdM system, created on the basis of personnel data received from a trusted system (for example, an HR system). The accounts in the target information systems are created only with the help of the IdM system and are linked to a specific employee. Thus, any account in the information system always corresponds to its owner — an employee of the company.
It must be said that the introduction of IdM in a complex multivendor environment with many different systems and still geographically separated units is not a trivial task. And difficult to manage. The principle is usually - “don't touch while it works”, so you need to think about such things either in advance, when it is still easy to implement the system, or look for reasons. And here are your best friends be safe. Because they certainly know what only one account can cost. And what's more, for sure they have examples of very unpleasant situations for the company, the repetition of which they would not really want. And you can help them.
How does the system issue rights?
There are two ways: based on rules that are configured in the system (for example, to all security personnel — such resources are available, to all heads of departments — such-and-so and so on). And by request. For example, someone from the purchase wants more data about the product and he needs to get access to 1C. He sends a request, the system keeps track of the hierarchy, sends it, for example, to the financial director. If he confirms the application, the person gets access.
How is the introduction
The first stage is a mandatory survey. Based on the results of this audit, we determine the existing business processes related to the management of credentials and access. And second, we draw a target picture in which the system must be implemented, and we propose a technical solution with which this idea, in general, can be realized again.
An audit is required to be included in the survey phase - a check of the technical infrastructure. The point is that one system can store identification data, for example, in a database, the other system - in a flat file. We also examine the interfaces through which these systems can communicate in the future with IdM (interface and protocols) in order to understand the possibility in general and the complexity of integration.
Here, the main thing, without excessive fanaticism. You know, as it happens - "spent 5 hours writing an algorithm that solves a problem in 5 seconds, which I would consider manually 3 hours." So, there are systems that do not need to be fully integrated. For example, the company has a thousand employees and in one of the systems only 50 people work. And this is one department, and the turnover of this department is very small. Perhaps there is an economic need not to integrate this system with the IBT manager, but to cross it with IdM in manual mode. That is, if necessary, a letter will be sent to the administrator of this system with a request to issue access rights to one or another employee. Such options are also possible. We, in particular, had an example in a company for 10 thousand people, when the personnel system, in which 5 people work, had technical limitations, and we invited the customer to consider just such an option. In the end, did so.
Connectors are being developed for integration - small software modules that allow you to take data from systems and, conversely, provide these data to systems. Usually done or the revision of standard connectors or development from scratch (most often for domestic systems: Americans usually have everything at once out of the box sharpened for the needs of big business).
For users to work according to the usual patterns, most of the events can be duplicated in the mail. As previously confirmed by the financial director, access by letter, and can continue - only now a letter is written to him by a robot from IdM and asks just to click on the link "yes" or "no."
The happiness of the security men
When everything is ready, it turns out a scheme where every person in the company has rights. And this is real happiness for the entire security department and financial director. Comprehensive reporting and holistic vision appear. For example, before the introduction of the system, an understanding of who has what rights, it was a whole quest with a detour of all units. After implementation - a couple of clicks. Two favorite questions at this stage are: “how far are the issued rights correspond to the rights requested in the applications,” “how much do they correspond to business need and corporate security policies”. The answers are exhaustive and often unexpected for those who only estimated the level of errors before the introduction of the system.
In parallel, the second part of the mathematical problem appears - the calculation of optimal rights. Yes, yes, we do some Data Mining (although, loudly said for most of the cases). And we show how you can optimally divide rights. Identify some things that should not be in a normal structure, which can lead to increased risks associated with access.
Another feature: every change of rights has a basis. For example, when the admin used to hand a new employee right — this was always at his own risk. Now the system works on the basis of: an order to receive a person, confirmation of a request from a manager, and so on. Just take and change the data in the corporate directory will not work: the data from HR managers are considered more trusted.
Very pleased with the convenience of updating the rights. IdM systems can monitor situations where rights are granted, but the person is no longer needed. For example, the employee does not perform work that requires access to the company's financial reports, but he has such access. The system can detect this pattern and issue a recommendation to remove these rights.
User happiness
Then users become happy. They have one entry system, when it is enough to log in once at the workplace and automatically get access within their authority. No papers with passwords with a bunch of applications and services - you only need to remember your input, (note, this is a broader SSO task, IdM systems do not always solve it).
The happiness of the IT department
After implementation, when the whole company looked askance at the "inventors" from the IT department, changing the usual way of things, you can relax and start having fun. Changes from one place, a convenient picture of rights, scripted actions, such as creating a box for a new employee after updating documents with personnel officers, and so on, are a thrill. The employee clears the password for himself, his manager unlocks his manager, and the IT department has a log of actions if it is necessary to find the cause of the problem. True, it will take some time to sweat with a painstaking adjustment (there will be a period of rather lengthy “finishing”), but it's worth it.
Yes, you understood correctly that IdM is very nervous. The fact is that applications for access are no longer sent to the system administrator, but to the person who must confirm such access. The head of the department, the financial director, the security officers - in general, those who are directly responsible for the question. And this means that if earlier, when something was wrong, the admin was to blame, but now it is clearly understood who gave what and to whom. And the admin only provided the protocol.
Accounting is also happy
For them there are special words that like music caress the ear of the whole department. These include a decrease in the total cost of implementation, a decrease in the cost of ownership, a reduction in the required technical resources, a clear architecture, a reduction in the cost of servicing and operating the solution, and a phased implementation of the solution without affecting the continuity of the company's processes . Phew In general, this is both refactoring and optimization immediately.
Ideology
In the United States and Europe, such systems have long been, and many are used to them. It would be strange if in our country there were no peculiarities of the mentality associated with access rights. The main problem - the power of attorney sources. For example, personnel officers in many places just love to add all the data backdated to the system, already at the time of dismissal. This is a professional shift, because the workbook is filled in fact at this very moment.
Often there are situations when you need to make special privileges to the leadership. That is, some rule is introduced, but in fact the tops are not followed. When the rule is automated, bosses can expect a surprise - for example, automatic unloading of cell phones into the general directory of company contacts. It is clear that after a couple of calls from clients immediately to the director, we have finalized this rule in practice.
Money
Licenses are expensive. There are a lot of conditions, but usually it turns out to be tens to several hundred dollars per employee. Directly, due to the time saved, the system pays off in 3-4 years, but usually the assessment is based on the benefits of security personnel and transparent reporting. Another feature is that when a company is audited, for example, before selling (merging) or certifying, such systems are perceived very positively.
Evolution
Initially, there were no access control repositories alone. The task was to understand "who and where has the right to go." Modules were connected to all points of the login, which simply fixed who entered. The access map was slowly lined up, which was reported. On the other hand, the centers for issuing uniform rights, which formed such a map, developed in parallel. As a result, symbiotic solutions have now appeared: first, they operate in read-only mode and collect relevant data on rights, then transfer module by module to active management, and then allow global automation to be done. And this is all calm, smoothly and smoothly for users.
PS If you have questions about a specific configuration for your case or you cannot ask a question in the comments, write directly to me at AZaikin@croc.ru.
Source: https://habr.com/ru/post/189964/
All Articles