Место IDM в инфраструктуре и точки соприкосновения с системами

Вместо введения

Недавно, я стал участником одного диалога, по мотивам которого мне и пришло в голову написать данную статью. Диалог происходил в одной достаточно крупной компании, в которой работает порядка тысячи сотрудников. И выглядел он примерно так:
(Администратор ИС) — Простите, можно мне вставить свои пять копеек? Я слышал вы тут об IDM что-то говорите.

(Вендор) — Да, конечно.

(Администратор ИС) — А зачем нам IDM? Мы же можем перенести все свои системы на AD-аутентификацию.

(Вендор) — Можете?

(Администратор ИС) — Ну, потребуются определенные доработки тех систем, что написаны под нас (около 5 ИС), но в целом, я полагаю, что разработчики этих систем любезно согласятся нам помочь. У нас же так уже сделано с системой Х. Все остальные промышленные ИС, такую функцию поддерживают по умолчанию.

(Вендор) — Т. е. вы считаете, что вместо внедрения IDM, проще договориться с 3-мя компаниями разработчиками, которые написали для вас 5 ИС, и попросить их переделать процессы аутентификации?

(Администратор ИС) — Да, именно так.

(Вендор) — Не могу с этим спорить. А как быть с управлением правами?

(Администратор ИС) — В смысле?

(Вендор) — Ну в смысле, ваша система Х, о которой вы сейчас говорили, она действительно использует AD-аутентификацию. Учетки у пользователей там AD-шные. Но вот управление правами там осуществляется независимо от AD. На уровне приложения всем пользователям назначаются какие-то права, и AD об этом ничего не знает. Да и не все промышленные системы, которые вы упомянули, могут полностью работать и рулить доступом на базе AD групп.

(Администратор ИС) — Да, именно так, я это понимаю.

(Вендор) — И как вы предлагаете управлять правами в таких системах, в свете того, что принято решение о централизации этого процесса?

(Администратор ИС) — Ну, мы можем попросить разработчиков системы Х, доработать и этот функционал, и сделать так, чтобы права раздавались на основе включения в те или иные группы в AD.

(Вендор) — Отлично! С остальными 5-ю системами поступим так же?

(Администратор ИС) — Ну… Да, а почему нет?

(Директор ИТ) — Погодите, доработать такой функционал в шести ИС? И сколько это будет нам стоить?

(Администратор ИС) — Я не знаю, в принципе, доработка системы Х под доменную аутентификацию стоила не очень дорого, и по времени заняла порядка 3 месяцев.

(Директор ИТ) — Т. е. если предположить аналогичные затраты, то проект по переходу полностью на централизованное AD-шное управление правами может нам обойтись (считает в уме)… и по времени это (закатывает глаза)… за год справимся?

(Администратор ИС) — Не факт, надо спрашивать. За два года точно все переведем.

(Вендор) — Коллеги, подождите. Вы действительно считаете, что сможете все свои системы и права в них перенести в AD?

(Администратор ИС) — Не вижу в этом какой-то неразрешимой проблемы.

(Вендор) — А сколько прав сейчас в системе Y? Сколько там групп/привелегий и т. п.

(Администратор ИС) — Порядка тысячи, если мне не изменяет память.

(Вендор) — И вы создадите в AD под эту систему тысячу групп? И под остальные свои системы еще по тысяче групп?

(Администратор ИС) — Ну, согласен, коряво как-то.

(Вендор) — Вы не думали, как такой «прекрасный» контроллер домена с десятком тысяч групп и порядка тысячи пользователей потом администрировать? Как вы себе представляете вашу админскую оснастку?

(Директор ИТ) — Мне кажется мы тут обсуждаем, как нам заново изобрести велосипед.

(Вендор) — Именно.

(Директор ИТ) — Вернемся к деталям, что вы говорили про коннекторы, долго их разрабатывать?
…



Безусловно, многие знают, что такое IDM-система и для чего она нужна, но далеко не все понимают ее место в инфраструктуре компании. Поэтому, я попробую в рамках данного материала описать основные моменты, а так же рассказать подробнее о точках соприкосновения (коннекторах) IDM с информационными системами организации.

Отделять мух от котлет

Для многих, особенно для специалистов ИТ, управление доступом — довольно простой и понятный процесс. Но часто, как в примере из диалога в начале статьи, на фоне простоты процесса, происходит «замыливание глаз» и отсюда вытекают неправильные суждения, касательно природы и назначения IDM-систем.

Первое, и одно из самых распространенных заблуждений это то, что IDM якобы заменяет существующую модель аутентификации на некую новую, свою. На самом деле это не так, аутентификацией как таковой IDM-система не занимается и никак ее не заменяет. IDM отвечает за управление правами пользователей. Именно слово «управление» тут является ключевым, т.к. именно IDM предоставляет администраторам единый интерфейс управления правами во всех их ИС. После внедрения IDM администраторам не придется больше заходить в администраторские консоли различных приложений, чтобы создать там учетную запись пользователя и назначить ему необходимые для работы права. Эти операции будут автоматизированы.

Второе распространенное заблуждение — отношение к IDM, как к еще одной системе, которую точно так же придется администрировать, как и остальные ИС и головной боли станет только больше. Безусловно, система IDM, нуждается в администрировании и настройке, более того, ее нужно будет настраивать не один раз в ходе внедрения, с этой системой нужно будет жить. Но факт остается фактом, уровень автоматизации, который можно достичь при помощи IDM, не идет ни в какое сравнение с теми дополнительными административными задачами, которые повлечет за собой ее внедрение. Одна только функция автоматического создания учетных записей пользователя во всех необходимых ИС, позволит разгрузить администраторов от огромного кол-ва ручной работы. А если посмотреть на механизмы самообслуживания пользователей, которые предоставляет IDM, то плюсов становится на несколько порядков больше, нежели минусов.

Но давайте вернемся к вопросу о месте IDM в инфраструктуре компании и о тех самых точках сопряжения (коннекторах).

Архитектура «на пальцах»

Любая IDM представляет собой отдельно стоящую систему, которая с одной стороны взаимодействует с доверенным источником информации (чаще всего это кадровая система компании), а с другой стороны с управляемыми ИС (к ним относятся все ИС, в которых IDM создает пользователей и управляет их правами). Нужно отметить, что IDM не является какой-то надстройкой над кадровой системой предприятия или даже надстройкой над структурой AD — это совершенно автономная система.

IDM взаимодействует с окружающими ИС в инфраструктуре посредством коннекторов. И данные коннекторы, в общем случае, следует разделять на две группы — коннекторы к доверенным источникам информации и коннекторы к управляемым ИС. Первая группа отвечает за то, чтобы система IDM своевременно получала информацию о сотрудниках, их должностях и о структуре подразделений. Вторая же группа отвечает непосредственно за управление учетными записями и правами пользователей в конечных ИС. Простыми словами назначение у групп этих коннекторов абсолютно разное.

Откровенно говоря, именно коннекторы являются одним из ключевых компонентов любой IDM. Именно коннекторы являются тем ключевым компонентом, который не позволяет говорить о системе IDM как о некоем «коробочном решении». Нельзя положить в «коробку» тысячу коннекторов к любой конфигурации ИС для Заказчика. И вопрос этот скорее концептуальный, поэтому, когда я слышу заявления в стиле «мы разработали коробочный IDM», это вызывает у меня лишь чувство глубокого разочарования. Ведь, либо говорящий не понимает что такое IDM, либо он понимает и осознанно вводит всех в заблуждение.

Коннекторы

Конечно, внутреннее устройство коннекторов заслуживает как минимум отдельной статьи. Мы же попробуем поговорить о них, скажем так, на функциональном уровне.

К первой группе мы отнесли коннекторы к кадровым системам, или коннекторы к доверенным источникам информации. Их главной функциональной особенностью является то, что они, как правило, никак не воздействуют на доверенную или кадровую ИС. В их задачу входит лишь получение информации из источника и правильной ее интерпретации. Так, например, коннектор к кадровой системе должен позволять либо в онлайн режиме, либо с заданным интервалом времени проводить «опрос» кадровой базы и получать информацию о сотрудниках, их должностях, статусах (уволен / не уволен, в отпуске или нет), об организационных единицах и т. п. После получения данной информации, уже сама IDM запускает определенные процедуры, которые в свою очередь вызывают дальнейшие события, определенные регламентов компании. Так, например, если сотрудник Иванов ушел в отпуск и данное событие отражено в кадровой системе, то коннектор должен считать дату выхода в отпуск данного сотрудника и записать ее в базу данных IDM. Дальше на эти события начинает реагировать система в зависимости от текущих настроек бизнес-процессов. К примеру, происходить оповещение администратора безопасности о том, что Иванов уходит в отпуск, назначение вместо Иванова (если он являлся согласующим лицом при назначении доступа в какие-либо ИС) его заместителя, и возможно запрос на временную блокировку всех учетных записей для данного сотрудника, если это предусмотрено регламентом. Другими словами, кадровые коннекторы никак не влияют на работу кадровой ИС, они нужны лишь для получения информации в одностороннем порядке.

Ко второй группе мы отнесли коннекторы к управляемым ИС или, как их еще называют, коннекторы к целевым ИС. Данные коннекторы призваны непосредственно выполнять те процедуры, что вызываются в IDM на основании данных из кадровой системы. Так, например, если вернутся к нашему сотруднику Иванову, ушедшему в отпуск, то коннекторы к целевой системе, могут, например, временно заблокировать его учетную запись в AD, CRM или какой-то базе данных. Вот перечень основных функции, которые реализуются в данных коннекторах:

• Создание / удаление учетной записи пользователя;
• Назначение / отбор прав и привилегий для учетной записи пользователя;
• Блокировка / разблокировка учетной записи пользователя;

Переименование учетной записи пользователя.

Для реализации этих основных функций, IDM система, фактически, имитирует действия администратора. Т. е. под своей служебной учетной записью с административными правами (ее необходимо создать для нужд IDM в каждой управляемой ИС), IDM вызывает внутренние функции и процедуры, заложенные в ИС для выполнения тех или иных действий с учетными записями пользователей. Вот тут как раз есть очень важный момент с точки зрения разработки коннекторов — наличие описания этих самых внутренних процедур и функций.

На моей практике, в каждом проекте приходится писать какой-то новый коннектор, а то и сразу несколько. И как раз наличие адекватно описанного API у ИС способствует быстрой разработке коннектора к подобной системе. Т. е. если обратиться к диалогу, указанному в начале данной статьи, то можно сказать, что если к системе Х был бы нормально описанный API и он позволял бы понять какие функции необходимо вызывать для тех или иных операций с учетными записями, то Заказчик получил бы полноценное управление не через 3 месяца, а скажем через 2 недели. На мой взгляд, это явная экономия средств и времени.

Вместо заключения

Конечно, писать об архитектуре и коннекторах можно было бы еще очень долго. Но это уже материал для совершенного другого формата документа, и в данному случае основной акцент, как мне кажется отражен. Надеюсь, что данная краткая статья позволит вам лучше понимать принципы работы систем класса IDM. И возможно развеет те частые заблуждения и сомнения в эффективности подобных решений.

Александр Санин, коммерческий директор компании Аванпост