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

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

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

В общих чертах интеграция IDM и СЭД/SD выглядит как автоматизированная передача согласованной заявки из внешней системы управления заявками на исполнение в IDM. Но, несмотря на первичную простоту данной задачи, схема интеграции имеет свои особенности и разные исполнения, в зависимости от требований заказчика и возможностей интеграции. Схему интеграции IDM и СЭД/SD можно условно разделить на 2 варианта: с односторонней и с обратной связью. В случае с односторонней связью, после согласования заявки она в установленном виде «попадает» в IDM. Технически здесь возможны различные реализации: простой файл excel согласованного образца, шина данных с обменом через xml, веб-сервисы и т. п., многое зависит от идеологии ИТ-инфраструктуры заказчика. После того, как IDM «увидел» согласованную заявку, он исполняет ее, а именно назначает сотруднику запрашиваемую роль и вносит соответствующие изменения в права доступа в целевой системе, отправляет уведомление по электронной почте инициатору заявки. В случае варианта с обратной связью, после назначения роли сотруднику, IDM отправляет необходимое уведомление обратно в СЭД/SD о том, что заявка выполнена. Это особенно важно для системы Service Desk, где статус о выполнении ИТ-заявки необходим для ее закрытия.

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

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

Безусловно, каждая интеграция IDM с СЭД или SD требует отдельной проработки, и здесь не может быть общего «лекарства». Главное, чтобы трудозатраты на реализацию интеграционного проекта не превышали возможные «потери» от внедрения отдельной консоли по управления заявками на доступ, и присутствовала техническая возможность такой интеграции, а именно наличие со стороны IDM-системы и СЭД/SD необходимого программного интерфейса, позволяющего обмениваться заявкам, их параметрами, статусами, а также проводить регулярную синхронизацию доступных для запроса информационных ресурсов и прав доступа.

Олег Губка, директор департамента по работе с клиентами компании Аванпост