“Российский рынок IDM увеличится за пять лет в десять раз”

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

О состоянии российского рынка IDM, о его готовности к происходящим в организации ИТ изменениям, связанным с переходом к облакам и сервисным моделям предоставления ИТ-ресурcов, с масштабным проникновением ИТ в повседневную жизнь, научному редактору PC Week/RE Валерию Васильеву рассказывает Андрей Конусов, генеральный директор российской компании Avanpost, разрабатывающей и продвигающей одноименный программный комплекс IDM.

PC Week: Как можно охарактеризовать состояние и динамику российского рынка IDM? Есть ли у нас здесь “национальные” особенности?

Андрей Конусов: Аналитических отчетов о нынешнем состоянии российского рынка IDM, которые выполнили бы специализированные исследовательские компании, увы, нет. Что же касается мирового рынка, то, по данным Gartner, его объем увеличится с 9,9 млрд. долл. в 2010 г. до 12 млрд. долл. в 2013-м.

Исследования, проведенные непосредственно нашей компанией, показывают, что российский рынок IDM по сравнению с мировым мал и никак не превышает 1%. В то же время наша компания поставила перед собой амбициозную задачу за ближайшие пять лет увеличить этот объем в десять раз. Эти планы мы увязываем с продвижением своего продукта Avanpost, ориентированного на специфику российского спроса на решения IDM.

Замечу, что комплексные промышленные, хорошо проработанные платформенные решения для задач IDM и сегодня неплохо представлены в нашей стране. Однако это зарубежные разработки вроде Oracle IDM. Они дороги даже для компаний среднего масштаба, не говоря уже о малых предприятиях. И даже для заказчиков уровня Enterprise такие системы сложны при внедрении и эксплуатации. Думаю, при численности менее 2 тыс. пользователей браться за их внедрение нерентабельно.

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

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

К тому же нередко внедрение IDM-систем крупных зарубежных вендоров не дает ожидаемого заказчиком результата. Дело тут в том, что такая система, в силу своего ключевого положения в обеспечении ИБ, обязана стыковаться практически со всеми бизнес-приложениями, среди которых в российских компаниях довольно часто встречаются отечественные разработки, в том числе и самописные. Ожидать, что крупные иностранные разработчики будут создавать коннекторы под российскую “самобытность”, не приходится.

К коммерческой нецелесообразности (с позиций крупных вендоров) таких разработок нужно добавить сложные, затяжные процедуры принятия решений (в том числе и об открытии проекта), характерные для крупных структур. В результате полноценная увязка ядра системы IDM с внешними приложениями порой растягивается на годы.

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

PC Week: Как же объяснить возникновение в России таких широких ножниц между спросом на взвешенный функционал IDM и отсутствием промышленных, хорошо масштабируемых под разные размеры бизнеса заказчика, IDM-систем?

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

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

PC Week: В том числе и с учетом происходящего сейчас облачного и мобильного размытия периметра защиты?

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

Поддержка виртуализации (которая вошла в повседневность раньше облаков) в системах IDM (во всяком случае в нашем продукте) уже реализована. Что касается облаков, то они представляют для IDM большую сложность, поскольку в этой архитектуре неочевидно, кто должен реализовывать функционал IDM. Логично, если эти задачи возьмет на себя хозяин инфраструктуры, на которой облако построено, — владелец ЦОДа или системы ЦОДов, или SaaS-провайдер, если он арендует инфраструктуру. Он может развернуть IDM-систему, регламентирующую доступ как между корпоративными клиентами облака, так и между пользователями каждого клиента.

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

Концептуальное понимание направления развития нашего собственного продукта предполагает появление в 2013 г. прототипа решения, чтобы на нём демонстрировать основные возможности облачного IDM-решения.

Мне представляется, что в долгосрочной перспективе (лет через пятнадцать) развития рынка IDM основными потребителями IDM-услуг станут физические лица, и услуги эти будут “зашиты” во все интернет-ресурсы, в том числе и в социальные сети.

PC Week: Как при этом будет соблюдаться баланс между желанием интернет-пользователей сохранять анонимность и авторизованным доступом к интернет-ресурсам, который тоже востребован?

А. К.: Тут нет никаких противоречий: сегодня можно авторизоваться и получить доступ, используя логины и пароли, и оставаться при этом анонимным.

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

PC Week: А разве уже сейчас страна не нуждается в унифицированных аутентификаторах, например, для Единой системы идентификации и аутентификации (ЕСИА), которую создает Минкомсвязи в рамках инфраструктуры электронного правительства?

А. К.: ЕСИА должна была войти в эксплуатацию только в апреле этого года, о полноценной ее работе еще рано говорить. Должно пройти больше времени, чтобы можно было оценить ее работу. Однако то, что в ней заложена поддержка принципа единственной подписи (SSO) и начался ввод ее в эксплуатацию, является хорошим заделом на пути к удобному сервису для граждан в сфере госуслуг. По крайней мере хочется в это верить. ЕСИА позволит зарегистрированному пользователю авторизовываться единожды как на портале госуслуг (gosuslugi.ru), так и на порталах других ведомств. В ней в качестве единого идентификатора (т. е. логина) решили использовать страховой номер индивидуального лицевого счета (СНИЛС). Успех этого проекта будет зависеть, конечно, от качества исполнения и применяемых технологий.

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

В то же время следует иметь ввиду, что сегодня получить реальную и, самое главное, “законченную” услугу в рамках портала госуслуг нельзя, так как почти всегда нас просят подтвердить вводимые данные, принеся в соответствующее ведомство подтверждающие их документы. По-моему, для пользователя данные сервисы не опасны, поскольку не несут в себе серьезных рисков с точки зрения финансовых или моральных потерь.

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

PC Week: При эксплуатации системы IDM представляется существенной юридическая значимость результатов ее функционирования. А насколько она реализуема?

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

PC Week: Насколько уязвимы сами IDM-системы? Ваша компания применяет технологии безопасной разработки программных кодов?

А. К.: Мы как разработчик ПО обеспечиваем безопасность своего программного кода комплексом мероприятий. К ним относятся и автоматизированные средства контроля исходных кодов. Кроме того, в программные средства внедряются функции самоконтроля, проверки целостности и правомочности исполнения. В частности, применяются ключи HASP, электронная подпись исполняемого кода. Проводится сертификация продукта на предмет корректности встраивания криптографических функций и отсутствия недекларированных возможностей, а также обфускация модулей нашего программного комплекса Avanpost. Важно отметить, что регулярно производится ревизия и рефакторинг написанного ранее исходного кода. Потенциальные уязвимости мы стараемся выявлять еще на этапе проектирования и написания технического задания.

PC Week: Благодарю за беседу.