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