Дмитрий Бондарь: Скепсиса в отношении российских IGA-решений больше нет

Дмитрий Бондарь, руководитель продуктового направления Identity Management компании Ростелеком-Solar, рассказал Anti-Malware.ru о том, от чего зависит успешность внедрения IGA, как правильно оценивать его рентабельность, а также порассуждал о настоящем и будущем IdM и IGA в России.

Какие ключевые тенденции можно выделить в развитии IdM в России?

Д. Б.: Прежде всего — развитие отечественных решений из класса IdM (Identity Management) до уровня IGA (Identity Governance and Administration). Вендоры расширяют функциональность решений, и если раньше они могли предложить заказчикам только предоставление прав доступа к ИТ-системам, то сейчас такие системы обеспечивают управление жизненным циклом пользователей и ролей, управление заявками, пересмотр полномочий сотрудников, аудит, отчетность и аналитику по правам доступа.

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

Скептическое отношение к IGA российской разработки все еще присутствует на рынке?

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

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

Преимущества российских решений перед западными — легкая кастомизация и более привлекательная цена — также продолжают работать на нас.

Но куда более важно, на мой взгляд, именно изменение отношения. Когда мы только выходили на рынок, скепсис со стороны заказчиков вызывал тревогу. Люди привыкли пользоваться западными решениями — они хороши, про них все известно, а тут какие-то неизвестные российские ребята предлагают свой продукт.

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

Однако российский рынок IGA все еще значительно уступает западному по объему. В чем могут быть причины?

Д. Б.: Успешность и эффективность внедрения IGA зависит не только от самого продукта, но и от компетенций интегратора. И здесь ситуация пока очень разнородна. Тема IGA в России достаточно молодая, еще не сложились общепризнанные стандарты, «рельсы», по которым бы все ездили, поэтому каждый интегратор действует по-своему. В результате проекты по внедрению слишком сильно различаются. Порой они настолько не похожи друг на друга, будто это вообще разные темы. Где-то внедрение занимает несколько месяцев, где-то — несколько лет. Заказчики, в свою очередь, требуют конкретики в отношении стоимости и длительности проекта. Сюда накладывается и тот факт, что наши потенциальные клиенты гораздо больше экономят бюджеты, чем 5 лет назад.

C другой стороны, тема сложна сама по себе. Чтобы IGA работал эффективно, в компании должен быть определенный уровень зрелости процессов. IGA интегрируется с имеющимися у заказчика разнородными информационными системами и автоматизирует сложившиеся процессы. Зачастую это не такая простая задача — собрать информацию о том, как эти процессы функционируют. Часто даже представление самого заказчика о них не соответствует действительности. В таких случаях требуется детальный аудит, обследование, формализация и согласование описания бизнес-процессов, а это отдельный длительный этап.

В результате проекты могут буксовать, не достигать своих целей. Все это создает вокруг тематики IGA ауру тяжеловесности, сложности, нереализуемости, дороговизны.

По каким критериям можно понять, что пора задуматься о внедрении IGA?

Д. Б.: В первую очередь, это экономическая целесообразность внедрения. Она наступает при определенном объеме операционной деятельности. На мой взгляд, о внедрении IGA можно говорить, когда в штате организации 2000 и больше IT-пользователей.

Второй фактор — количество информационных систем, которыми пользуются все или большинство сотрудников. Например, есть компании, где инфраструктура построена вокруг Active Directory. У них может быть 10-15 бизнес-систем, но все они настроены на AD. В таком случае IGA, пожалуй, не нужна. А вот если в компании 5-10 разрозненных бизнес-систем, можно задуматься об автоматизации прав доступа.

Возможно ли более-менее точно оценить стоимость конкретного проекта и его сложность?

 Д. Б.: Нам поступает много запросов из разряда «сколько стоит IGA на тысячу пользователей». При этом заказчики не всегда могут ответить на дополнительные вопросы, тогда как именно детали очень сильно влияют на конечную стоимость проекта. Разница может быть плюс-минус 5 миллионов и даже больше.

Когда заказчики присылают RFP проекта (request for proposal — запрос на коммерческое предложение), часто он содержит только общие требования к продукту, например, возможность построения отчетов. При этом не сказано, какие именно отчеты нужны заказчику, как часто и в каком количестве их будут делать. Наш продукт поддерживает генерацию отчетов, но вывод в них какой-то специфической информации может потребовать дополнительной доработки, что опять-таки повлияет на конечную стоимость.

Как же заказчику предусмотреть все пункты, которые могут повлиять на стоимость и длительность проекта?

Д. Б.: Мы рекомендуем перед покупкой и развертыванием IGA запустить отдельный проект по сбору требований и проектированию внедрения. Такие услуги предлагают консалтинговые компании и системные интеграторы.

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

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

Еще один путь — самостоятельная подготовка к проекту, но он очень трудозатратный. Во-первых, требуется человек, который более-менее разбирается в теме. Во-вторых, нужно провести большую внутреннюю работу: побеседовать со службами IT, ИБ, бизнес-пользователями.

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

Какие изменения на уровне бизнес-процессов требуются при внедрении IGA?

Д. Б.: Непосредственно изменений бизнес-процессов не требуется. Если они уже как-то выстроены, их просто переносят в IGA. Например, если пользователи запрашивают и согласуют доступ в системе электронной почты или через ITSM, после внедрения IGA этот процесс переходит туда. Здесь меняется не сам процесс, а, скорее, инструменты для его выполнения.

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

Каковы наиболее частые причины того, что купленный когда-то IGA так и не заработал? 

Д. Б.: Есть ряд случаев, когда лицензии на систему IGA компания получила в рамках крупной поставки, она «прилагалась» к соглашению по доступу к софту. Какое-то время эти лицензии лежат на балансе. После ввода системы в эксплуатацию может оказаться, что софт не подходит для решения задач данной компании. В таком случае IGA будет выполнять минимум функций, не автоматизируя полный цикл процессов управления доступом. В итоге полноценного внедрения нет и заменить софт практически невозможно, ведь формально в компании уже установлена IGA.

Я сталкивался и с такими случаями, когда IGA внедряли малокомпетентные организации. Получалось как в первом примере: система работает, но реализует лишь 10% своих возможностей.

Часто причина неудачного проекта состоит в распределении зон ответственности в самой компании. Иногда за IGA отвечает служба ИТ, иногда ИБ. Случается, что одна служба выбирает систему под себя, не учитывая интересы другой. На российском рынке есть пример очень крупной организации, где внедрение инициировала одна служба, бюджет дали другой, и она выбрала систему, которая была ей ближе. В итоге внедрением недовольны, оно не решило задачи, которые закладывались в проект.

Насколько часто и по каким причинам заказчикам приходится менять уже внедренную IGA-систему и начинать все сначала?

Д. Б.: Такое бывает достаточно часто. Если посмотреть пресс-релизы, можно увидеть, что одни и те же компании два или три раза внедряли разные IGA-решения. Как правило, причины перехода на новую систему те же, что и в целом причины неуспеха IGA.

Но бывает и по-другому. У нас есть заказчик, достаточно крупная компания. До Solar inRights там на протяжении 1,5-2 лет пытались внедрить систему другого отечественного вендора. По словам заказчика, в компании были недовольны качеством самого софта. Он мог предложить только базовые функции IGA, и любое отклонение от них требовало от вендора доработок. Выпуск патчей занимал по 4-6 месяцев, и каждый из них разваливал настройку, которую удалось создать к тому моменту.

Как правильно оценивать рентабельность проектов по внедрению IGA?

Д. Б.: Во-первых, рентабельность внедрения можно оценить по объемам операционной деятельности, которую автоматизирует IGA, и рабочего времени, которое экономят сотрудники. Например, система автоматизирует операции по исполнению заявок на доступ, значит, компания экономит на этом человеческие ресурсы. Рентабельность легко подсчитать, зная, сколько заявок поступает в день и сколько времени нужно сотрудникам на их исполнение.

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

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

IGA как услуга по модели SaaS имеет шансы в России в обозримом будущем? Каковы, на ваш взгляд, перспективы развития российского IGA?

Д. Б.: На российском рынке IGA в последнее время все чаще возникают разговоры о движении к облачной модели. Это соответствует общемировой практике — большинство ключевых игроков западного рынка уже предлагают SaaS-решения класса IGA.

На мой взгляд, пока рынок IGA не дозреет до типовых проектов, эта идея останется достаточно утопичной. Я уже говорил о незрелости рынка и о том, что внедрение IGA — это большой проект, где нужно интегрироваться с информационными системами заказчика, автоматизировать, а иногда менять и даже создавать с нуля его бизнес-процессы. Если в этом смысле ничего не изменится, концепция IGA в облаке окажется не SaaS, а просто колокейшн. То есть IGA будет стоять в облаке, а вся тяжесть интеграционного процесса останется на плечах заказчика или интегратора.

Еще одна проблема — недоверие к облачным сервисам, в частности, у крупных компаний, которые и являются основными заказчиками IGA.

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

Получается, пока к переходу в облака и технологии, и заказчики не готовы.

Спасибо за интервью! Желаем успехов.