Я уже рассказывал на Хабре, как наша команда из «ЛАНИТ‑Интеграции» автоматизировала процесс управления доступами для крупного заказчика, который имеет несколько десятков офисов по всей стране.

В этой статье я чуть подробнее опишу, как из прототипа мы стали развивать полноценную 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. Он содержит список групп, в которые входит учетная запись. Но в этом поле нет информации о вложенных группах, поэтому придется параллельно загружать иерархию групп. Это будет уже другая история, о которой я расскажу в следующей статье.

Комментарии (2)


  1. DmitryI
    06.10.2026 07:59

    А можно ли с помощью той же системы при каких-то событиях с учетной записью (создание, отключение и т.п.) дернуть внешний API, чтобы сообщить об этом, передав все необходимые параметры, например, ФИО, учетка и другие?


    1. Alejanders Автор
      06.10.2026 07:59

      Конечно!
      Сейчас мы отслеживаем деактивацию учетной записи в Active Directory, и организуем отзыв доступов, уведомления о деактивации согласующих.
      Можно и во внешнюю систему дополнительное уведомление отправить.