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

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

Аккаунт заблокирован

10000

16

Аккаунт активен

1000000000

512

Пароль истек

100000000000000000000000

8388608

Для определения увольнения (т. е. отключения аккаунта) мы использовали бинарное умножение с двоичным 10.

Доступы

Я уже рассказывал о том, что такое доступ в Simple IDM, но повторюсь. Доступ – это связка из трех элементов:

● информационная система (например, 1С, сетевой диск, CRM);

● область (например, конкретная база в 1С, папка на файловом сервере);

● роль (например, оператор, чтение, запись).

Вот пример такой связки:

● система – 1С ЗУП;

● область – база данных “Москва”;

● роль – главный бухгалтер.

Форма подачи заявки на доступ выглядит так:

В системе ведется реестр всех доступов, включающий информацию:

● кто и когда получил доступ;

● на какой срок;

● к каким ресурсам;

● кто согласовал доступ;

● информация об отзыве (при наличии).

После того, как мы настроили предоставление доступа и его контроль, набор функциональных возможностей нашего программного решения уже стал “минимально необходимым” для того, чтобы оно могло называться IdM-системой. Следующий шаг – контроль соответствия согласованного набора прав и фактического. 

Для этого планируем использовать атрибут MemberOf AD. Он содержит список групп, в которые входит учетная запись. Но в этом поле нет информации о вложенных группах, поэтому придется параллельно загружать иерархию групп. Это будет уже другая история, о которой я расскажу в следующей статье.

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


  1. DmitryI
    06.10.2026 07:59

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