Я уже рассказывал на Хабре, как наша команда из “ЛАНИТ-Интеграции” автоматизировала процесс управления доступами для крупного заказчика, который имеет несколько десятков офисов по всей стране.В этой статье я чуть подробнее опишу, как из прототипа мы стали развивать полноценную IdM-систему. Читать далее
Время на прочтение3 мин
Охват и читатели7.8K
Я уже рассказывал на Хабре, как наша команда из «ЛАНИТ‑Интеграции» автоматизировала процесс управления доступами для крупного заказчика, который имеет несколько десятков офисов по всей стране.
В этой статье я чуть подробнее опишу, как из прототипа мы стали развивать полноценную IdM‑систему.

Что имели на старте
То, что в ходе проекта был создан прототип IdM‑системы (Identity Management, централизованное управление учетными записями сотрудников и их правами доступа к информационным ресурсам компании), мы осознали не сразу. Универсальность архитектуры решения и процедур автоматизации заказа доступа вместе с возможностями используемой платформы подтолкнули нашу команду к развитию наработок в полноценное программное решение.
Для начала мы сравнили то, что было реализовано у нас, с функциями, которые такое решение должно иметь.
IdM‑система должна автоматизировать:
● процедуру запроса доступов;
● согласование доступов;
● предоставление доступа (как минимум, к самым распространенным информационным системам);
● контроль соответствия фактического и согласованного доступа;
● своевременный отзыв временных и устаревших прав.
Все это снижает риски потери информации и увеличивает эффективность бизнес‑процессов.
Анализ показал, что нам не хватало автоматизации предоставления доступа и контроля.
Интеграция с Active Directory
Обычно IdM‑системы имеют коннекторы к целому ряду систем (Active Directory от Microsoft, 1C). Мы начали интеграцию с Active Directory (AD), поскольку во многих компаниях AD является основным инструментом управления правами.
В качестве механизма мы решили использовать PowerShell скрипты и MID‑сервер SimpleOne, поскольку уже были наработки по скриптам.
Архитектурно решение выглядит так:

SimpleOne работает под управлением Linux, PowerShell работает под Windows. Поэтому используется отдельный сервер, так называемый MID‑server (Maintenance‑ Integration‑Discovery). На этом сервере располагаются PowerShell‑скрипты.
Cервер SimpleOne инициирует запуск скриптов с нужными параметрами и получает ответ о результате операции. Например, чтобы включить учетную запись в группу AD, вызывается скрипт, у которого в качестве параметров указываются название группы и учетная запись. После исполнения скрипта скрипт выдает ответ «успешно».
Здесь есть небольшая тонкость: PowerSell‑скрипт исполняется не мгновенно. Если сразу же после запуска скрипта ожидать ответ, рабочий процесс может выйти в ошибку. Поэтому мы добавили отдельный блок с ожиданием результата.

Для автоматического отзыва временного доступа мы использовали механизм событий SimpleOne, который позволяет запланировать исполнение какого‑либо действия в определенное время, то есть при исполнении заявки на временный доступ мы заранее формируем задачу на отзыв доступа в нужный день.
Для отслеживания увольнения пользователя мы используем флаг User account Control в AD. Этот флаг представляет собой слово, каждый разряд которого отвечает за определенный атрибут. Например:
Значение | Двоичное значение | Десятичное значение |
Аккаунт отключен | 10 | 2 |
Аккаунт заблокирован | 10 000 | 16 |
Аккаунт активен | 1 000 000 000 | 512 |
Пароль истек | 100 000 000 000 000 000 000 000 | 8 388 608 |
Для определения увольнения (то есть отключения аккаунта) мы использовали бинарное умножение с двоичным 10.
Доступы
Я уже рассказывал о том, что такое доступ в Simple IDM, но повторюсь. Доступ — это связка из трех элементов:
● информационная система (например, 1С, сетевой диск, CRM);
● область (например, конкретная база в 1С, папка на файловом сервере);
● роль (например, оператор, чтение, запись).

Вот пример такой связки:
● система — 1С ЗУП;
● область — база данных «Москва»;
● роль — главный бухгалтер.
Форма подачи заявки на доступ выглядит так:

В системе ведется реестр всех доступов, включающий информацию:
● кто и когда получил доступ;
● на какой срок;
● к каким ресурсам;
● кто согласовал доступ;
● информация об отзыве (при наличии).

После того, как мы настроили предоставление доступа и его контроль, набор функциональных возможностей нашего программного решения уже стал «минимально необходимым» для того, чтобы оно могло называться IdM‑системой. Следующий шаг — контроль соответствия согласованного набора прав и фактического.
Для этого планируем использовать атрибут MemberOf AD. Он содержит список групп, в которые входит учетная запись. Но в этом поле нет информации о вложенных группах, поэтому придется параллельно загружать иерархию групп. Это будет уже другая история, о которой я расскажу в следующей статье.
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | IDM на максималках: как управлять доступами к 1500 систем Яндекса и не стать бутылочным горлышком | 0 | 8.32 | 04-09-2026 |
| 2 | Как перейти на Infrastructure as Code и выжить | 0 | 8.04 | 17-09-2026 |
| 3 | Автоматизация матчмейкинга: как я знакомлю полезных друг другу лидов | 0 | 5.62 | 01-10-2026 |
| 4 | Инвентаризация активов ИТ‑инфраструктуры для ИБ: как собрать перечень и поддерживать его в актуальном состоянии? | 0 | 8.36 | 24-09-2026 |
| 5 | RuntimeNodes: как мы, ML‑щики, стали писать рантайм | 0 | 7.74 | 24-09-2026 |
| 6 | От Excel‑макроса до RapidTag: как электрик с помощью ИИ собрал инструмент для маркировки проводов | 0 | 7.46 | 28-09-2026 |
| 7 | «Индид»: российский рынок защиты учетных данных и контроля доступа достиг 17 млрд рублей | 0 | 13.18 | 07-10-2026 |
| 8 | Windows Incident Response: системный подход. Часть 1 | 0 | 7.78 | 24-09-2026 |
| 9 | Путь к ИИ‑сингулярности | 0 | 8.46 | 28-09-2026 |