Тренды импортозамещения на рынке IDM

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

• предоставление и отзыв доступа на основании кадровых событий (userprovisioning);
• предоставление и отзыв доступа по заявкам (workflow);
• аудит учетных записей и прав доступа в информационных системах (reconciliation).

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

На российском рынке IDM-системы появились больше 10 лет назад, преимущественно это были иностранные решения от крупных ИТ-производителей, таких как Sun, Oracle, IBM и Microsoft. В силу сложного внедрения и высокой стоимости они в основном подходили крупным организациям. Первыми заказчиками подобных систем стали ведущие компании нефтяной, телекоммуникационной и банковской отрасли. Также ряд проектов был запущен в федеральных государственных организациях. Безусловно, ранний опыт внедрения IDM был очень неоднородным. Для многих заказчиков реализация проектов по управлению доступом завершалась еще на пилотном этапе, кому-то удалось автоматизировать только базовые процессы управления учетными записями в ограниченном числе информационных систем, и лишь совсем немногие приблизились к первоначальной цели, как правило, существенно превысив планируемые затраты. Впрочем, следует отметить, что несмотря на все трудности внедрения, достаточное количество крупнейших российских компаний и государственных организаций по сей день эксплуатируют результаты IDM-проектов того времени, ежегодно расходуя значительные бюджеты на их сопровождение. Среди таких организаций есть компании с полностью частным капиталом. Современные реалии российской геополитики могут затрагивать и их интересы, например, когда санкции распространяются на сферу деятельности организации или физическое лицо, являющееся крупным акционером или учредителем. Поэтому тренд импортозамещения имеет не только законодательную базу и государственный вектор, но и реальную инициативу со стороны крупных частных компаний. Из личного опыта могу сказать, что только за последний год к нам обратилось не менее пяти таких компаний и организаций с запросом на импортозамещение IDM, что составляет немалый процент среди общего числа клиентов, длительное время эксплуатирующих IDM-решения от иностранных производителей, в частности от Oracle или IBM.

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

Миграция IDM

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

Условно сам процесс миграции на современные IDM-платформы можно разделить на две составляющие: миграцию функционала и миграцию данных. Под миграцией функционала подразумевается перенос основных 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-системе.

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

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