Я уже рассказывал на Хабре, как наша команда из “ЛАНИТ-Интеграции” автоматизировала процесс управления доступами для крупного заказчика, который имеет несколько десятков офисов по всей стране.
В этой статье я чуть подробнее опишу, как из прототипа мы стали развивать полноценную 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. Он содержит список групп, в которые входит учетная запись. Но в этом поле нет информации о вложенных группах, поэтому придется параллельно загружать иерархию групп. Это будет уже другая история, о которой я расскажу в следующей статье.
DmitryI
А можно ли с помощью той же системы при каких-то событиях с учетной записью (создание, отключение и т.п.) дернуть внешний API, чтобы сообщить об этом, передав все необходимые параметры, например, ФИО, учетка и другие?