Лучшее из двух миров: интеграция IDM-системы и системы Service Desk

Задача управления учётными записями и доступом

Во многих процессных моделях, описывающих управление информационными технологиями, отдельно выделяется процесс управления заявками (обращениями пользователей). К примеру, в библиотеке ITIL такой процесс называется Request Fulfillment (исполнение запросов); он является самостоятельным. Объект управления данного процесса – заявки пользователей ИТ-услуг, во многих компаниях обладающие следующими важными свойствами.

Во-первых, число поступающих заявок бывает достаточно велико. Консервативная «среднетемпературная» оценка их количества может находиться в диапазоне 1,0…1,4 запроса на одного пользователя ИТ-услуг в месяц, в зависимости от отрасли. Однако в моей проектной практике встречались случаи, когда действительным коэффициентом можно было считать 2,2…2,5.

Во-вторых, заявки пользователей достаточно разнообразны: консультация по использованию ИТ-систем, сообщение о неработоспособности, запрос документации, согласование каких-либо работ и многое другое – при проектировании служб поддержки пользователей и разработке каталогов ИТ-услуг хорошей практикой является выделение и типизация возможных запросов пользователей. Среди прочего, в число поступающих обращений входят заявки, связанные с доступом к информационным ресурсам (предоставление прав, отзыв прав), а также учётными записями в различных ИТ-системах (создание, блокировка, сброс пароля и прочее).

Запросы, связанные с учётными записями и доступом, могут составлять существенную часть всех поступающих обращений пользователей, а значит – требовать приличных расходов в операционном ИТ-бюджете. Так, у одного клиента Cleverics при поступающих в среднем 800 запросах на изменение доступа в месяц и среднем времени обработки запроса 25 минут только на зарплату сотрудников, занятых в обработке таких заявок, требуется 1,6 млн. руб. в год (с учётом налогов и отчислений в фонды).

Большое число заявок, связанных с доступом, может объясняться особенностями отдельных организаций. К примеру, территориально-распределённые компании, обслуживающие большое количество клиентов (банки, специализирующиеся на работе с физическими лицами, розничные торговые сети федерального и регионального масштабов, страховые компании), традиционно имеют большую естественную текучку кадров. Относительно высокое среднее время выполнения заявки на доступ может объясняться большим количеством используемых ИТ-систем (десятки и сотни), каждая из которых имеет свои особенности, ролевые модели, права и привилегии, администраторов и группы поддержки. Кроме того, существенное увеличение числа заявок, связанных с доступом, может возникать при постепенной миграции на новые ИТ-системы, а также при присоединении других организаций (при слияниях и поглощениях).

Все эти тысячи заявок на доступ требуют регистрации, классификации, согласования, контроля исполнения, определения плановых и фиксирования фактических сроков – всего того, что принято называть управлением заявками. Традиционно управление заявками на доступ автоматизируется в обычных системах класса Service Desk, коих на рынке представлено великое множество. Однако для управления доступом применяются и специализированные программные продукты.

Специализированные решения по управлению доступом

В настоящее время на рынке Российской Федерации представлено несколько программных продуктов, позволяющих построить эффективное управление учётными записями и доступом; такое программное обеспечение принято называть IDM-системами (от англ. Identity Management).

Довольно широко применяется Oracle Identity Manager; некоторые компании увлечены внедрением и использованием Microsoft Forefront Identity Manager (несколько раз менявшим своё название и вскоре меняющим его вновь); отдельные организации сделали свой выбор в пользу IBM Tivoli Identity Manager. Из приведённого списка можно сделать вывод, что каждый уважающий себя производитель программного обеспечения уровня предприятия просто обязан иметь в своём портфеле что-то про управление доступом, при этом в названии обязательно должны присутствовать слова «identity» и «manager».

Помимо крупных универсальных игроков, на рынке России также присутствуют специализированные нишевые решения, такие как DELL One Identity Manager (бывш. Quest) и SailPoint IdentityIQ; есть и отечественная разработка – Avanpost IDM¹.

В специализированных IDM-системах обычно встречается следующая функциональность:

• построение ролевой модели и управление ею, включая выявление ролей (role mining), визуализацию и анализ модели, хранение истории её модификаций и версий и так далее;
• интеграция с системой учёта кадров для получения информации об изменениях в организации (приём сотрудников, увольнение, перевод на другие должности или в другие подразделения, краткосрочные и длительные отпуска, замещение должностей и так далее);
• портал самообслуживания для приёма заявок на дополнительный доступ, отмену доступа, сброса паролей и выполнения иных действий, а также предоставления информации о статусе заявки и истории обращений;
• механизм согласования принятых заявок и их движения по процессу изменения прав доступа (workflow);
• интеграция с управляемыми ИТ-системами, в которых предоставляется или отзывается доступ по информации из кадровой системы (автоматически) или в соответствии с согласованными заявками (вручную), включая контроль актуальных прав в управляемых ИТ-системах по сравнению с заданной ролевой моделью и автоматическое исправление выявленных несоответствий;
• механизмы контроля, аудита, журналирования операций, ресертификации прав доступа, а также поддержания актуальности ролевой модели.

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

Требования клиентов к процессу управления доступом

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

Следующий большой блок требований клиентов связан с функциональностью подачи заявок на изменение доступа через портал самообслуживания. Вот встречавшиеся мне примеры:

• в одной заявке может быть запрос на несколько пользователей сразу;
• в одной заявке может быть запрос на несколько ИТ-систем (управляемых и нет), в каждой из них свои роли;
• к каждой роли в каждой ИТ-системе для каждого сотрудника может требоваться указывать отдельное обоснование, в том числе с приложением отдельного документа;
• роли могут запрашиваться в виде произвольного текста, а не выбором из преднастроенной ролевой модели;
• заявки могут поступать не только на доступ: часто используются универсальные большие формы (например, перемещение рабочих мест), только часть работ из которых – предоставление доступа;
• при подаче заявки желательно отображать уже имеющиеся у данного сотрудника или сотрудников роли;
• при подаче заявки желательно отображать только доступные сотруднику роли;
• должна быть возможность взять одну из старых заявок (обработанных, скажем, год назад), внести в неё изменения и подать заново; система при этом должна понимать, что часть ИТ-ресурсов и ролей уже неактуальны, и для них доступ предоставлять не требуется;
• должна быть возможность подать заново отклонённые заявки без полного повторного заполнения длинной формы;
• для некоторых ИТ-систем есть необходимость указывать не только требуемую роль, но и дополнительные параметры доступа (к каким областям или модулям, какая видимость данных и так далее) – как выбором из списка, так и вводом произвольного сопроводительного текста для данной ИТ-системы, данного сотрудника и данной роли.

Не менее внушительным может выглядеть список требований клиентов к механизму согласования заявок на доступ, вот основные примеры:

• механизм согласования должен позволять назначать и использовать условия и ветвления, как то:
  • заявка на себя или на своего подчинённого;
  • заявка от уровня в иерархии компании;
  • заявка на обычную роль (права), или особенные (VIP);
  • заявка на обычную систему или критичную;
  • из какого территориального филиала заявка;
  • из какого подразделения компании заявка;
  • какие роли уже выданы ранее;
• от перечисленных условий может зависеть не только путь движения и согласования заявки (workflow), но и результат: какие права в итоге выдаются, какие уведомления и кому отправляются;
• механизм согласования должен позволять выстраивать различные последовательности и маршруты: последовательно, параллельно, при этом на любом этапе после любого условия (ветвления);
• должна быть возможность графического отображения процесса согласования с отметкой, где находится данная заявка в настоящий момент времени, доступного как администратору системы, так и обычному пользователю (заявителю);
• должна быть возможность частичного согласования: роли, которые одобрены – выдать, остальные – нет;
• механизм согласования должен допускать использование предсогласованных ролей: на часть ролей из заявки согласование не требуется;
• согласующее лицо может быть:
  • конкретным сотрудником;
  • должностью в определённом подразделении;
  • сотрудником определённого отдела;
  • ролью в процессе управления ИТ;
• должна быть возможность при необходимости отправить заявку на согласование руководителя, для чего система должна знать иерархию компании (у кого кто руководитель).

Компании, где уже выстроен и работает современный процесс управления заявками, также предъявляют стандартные требования к возможностям контроля и оптимизации работы процесса управления доступом, например: автоматическая иерархическая эскалация при срыве сроков, подробный отчёт об объёме и сроках обработки заявок в разбивке по типам, ответственным, ИТ-системам, дням недели, времени дня и так далее.

Не будет являться преувеличением утверждение, что далеко не все IDM-системы, включая самые серьёзные, продвинутые и именитые, могут реализовать перечисленные выше требования без существенной доработки или дополнительного программирования. Действительно, основное назначение IDM-системы – управлять доступом, а не заявками.

В то же время в хороших системах класса Service Desk (например, OMNITRACKER CleverENGINE) указанные требования реализуются достаточно несложно, что связано с самой сутью современной системы Service Desk уровня предприятия – управлять объектами с помощью универсального и полнофункционального workflow-механизма.

Таким образом можно сделать вывод, что раз каждая система хороша в своей основной области, то наилучшее решение – грамотная интеграция IDM-системы с системой Service Desk, что позволит не подменять функциональность одной системы в другой, а использовать лучшее в каждой из них.

Рассмотрим, какой такая интеграция могла бы быть.

Интеграция IDM-системы и системы Service Desk

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

Очевидно, что ролевая модель (п.1) должна быть представлена в каждой из двух систем. При этом важно отметить, что ни одна из них не будет иметь полной ролевой модели организации (см. рисунок ниже): IDM-система будет хранить часть ролевой модели, относящуюся к ИТ-системам, управляемым через IDM-систему, а система Service Desk будет хранить часть ролевой модели по всем остальным ИТ-системам. Частично данные ролевые модели будут пересекаться, так как необходимо обеспечить возможность запроса через Service Desk дополнительных прав доступа к ИТ-системам, управляемым через IDM-систему; это потребует специфичной интеграции, о которой будет сказано чуть ниже.

Интеграция с системой учёта кадров (п.2) и автоматическая обработка событий, связанных с персоналом – традиционная сильная сторона IDM-решений. Представляется, что возможность автоматизации такой рутины может служить очень сильным мотивирующим фактором для расширения области охвата IDM-системы и подключения к ней всё новых ИТ-систем.

Портал самообслуживания (п.3) и механизм согласования заявок (п.4) наиболее функционально реализуются в специализированных системах Service Desk, особенно построенных на универсальных workflow-платформах. Как уже упоминалось выше, все требования пользователей по регистрации, обработке, согласованию и контролю заявок могут быть реализованы в современной системе Service Desk с минимальными трудозатратами.

Интеграция с управляемыми ИТ-системами (п.5) и механизмы контроля и аудита (п.6) реализуются через интерфейсы сопряжения (коннекторы), которые входят в поставку IDM-системы. Таким образом, существенная часть работ по созданию учётных записей, равно как предоставление/отзыв прав доступа может быть автоматизирована.

Принципиальная схема интеграции IDM-системы и системы Service Desk приведена ниже:

Можно выделить три ключевых точки построения взаимодействия систем.

Во-первых, интеграция должна позволять построить обмен информацией о ролевой модели: структуры, справочники, бизнес-правила. Как минимум, такая информация должна регулярно поступать от IDM-системы в систему Service Desk, чтобы при приёме и обработке заявок пользователей можно было, к примеру, отобразить доступные для данного пользователя роли, имеющиеся уже у данного пользователя роли и так далее.

Во-вторых, интеграция должна позволять «передавать работы» из Service Desk в IDM-систему: когда заявка принята и согласована, необходимо поставить задание IDM-системе на изменение прав доступа (назначение роли, отзыв роли, блокировка учётной записи и так далее). Затем необходимо получить ответ от IDM-системы о результатах выполнения задания, чтобы перейти к следующим шагам процесса управления доступом, например уведомление заявителя и закрытие заявки.

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

Перечисленные три точки интеграции позволяют эффективно закрыть подавляющее большинство вопросов, связанных с управлением учётными записями и доступом во всех ИТ-системах организации.

Заключение и выводы

Мы увидели, что задача управления учётными записями и доступом – важная составляющая оптимального построения работы ИТ-департамента, позволяющая экономить ресурсы. Для её решения принято рассматривать и внедрять специализированные IDM-системы. В то же время, такие системы не обладают важными свойствами и возможностями, к которым уже привыкли те, кто выстраивал процессы управления ИТ.

Такие свойства и возможности, тем не менее, присутствуют в современных системах класса Service Desk. Объединяя с помощью грамотной интеграции лучшее из двух миров, можно получить достаточно эффективную систему управления доступом.

Следует отметить, что рынок систем Service Desk в настоящее время является достаточно зрелым. Первые системы такого класса появились ещё в 80-х годах прошлого века, и эволюция прошедших лет вывела на рынок, в том числе российский, очень достойные программные продукты. Многие компании в России уже прошли через один или даже два проекта миграции, когда использовавшаяся ранее устаревшая система Service Desk менялась на новую, более современную.

По сравнению с этим рынок IDM-систем в России только проходит этап становления: известных публике крупных успешных проектов построения управления доступом крайне мало, а IDM-системы, за редким исключением, предлагаются достаточно дорогие как по стоимости программного обеспечения, так и по расходам на внедрение².

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

Сноски

1. Приятно отметить, что российская компания Аванпост не стала следовать традиции выбора безликих названий для программных продуктов.
2. За исключением российских разработок, принципиально отличающихся по цене, таких как Avanpost IDM.

Автор: Олег Скрынник