Эволюция систем IGA (Identity Governance and Administration)

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

Введение

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

Этой статьей я хотел бы продолжить историю развития IDM-технологий, делая акцент в большей степени на функциональности систем данного класса, нежели на отечественной действительности. Вообще, хотя термин IDM (identity management) плотно закрепился за данной областью по крайней мере в России, более современное название IGA (identity governance and administration) лучше отражает функциональность решений, представленных на рынке в настоящее время. Поэтому предметом данной статьи по сути будет эволюция IDM-решений в IGA.

«Кривая» успешности 

Ранее я уже использовал для анализа этапов развития IDM кривую Hype Cycle, введенную аналитической компанией Gartner. Этот вид исследования позволяет представить процесс развития технологий с момента появления до стабильного успеха в контексте реакции рынка.  Популярное сейчас слово «хайп» (hype) как нельзя лучше отражает суть модели (типичный график представлен на рисунке ниже). На нём жизненный цикл любой технологии делится на следующие этапы. Первый этап — это бурный рост ожиданий, когда новая технология появляется на рынке и пробуждает большой интерес. За ним следует этап разочарования, когда происходит спад ожиданий, связанный чаще всего с неудачами попыток практического использования технологии. Для технологий, переживших этот этап, со временем наступает этап «просветления» и выход на плато продуктивности, когда технология по сути формирует свою нишу на рынке и стабильно развивается.

Рисунок. «Кривая» Hype Cycle от компании Gartner

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

От User provisioning к IDM 

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

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

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

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

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

От IDM к IGA 

Провести четкую временную грань, которая бы отделяла IGA от IDM достаточно сложно. Можно сказать, что первые IGA-инструменты стали появляться около 10 лет назад, но только через 5 лет термин IGA прочно закрепился за рынком управления доступом, сменив термины IDM и IAM (identity and access management). Давайте теперь подробнее рассмотрим, какие функциональные особенности отличают IGA от IDM.

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

Еще одним важным процессом в IGA является выявление и предотвращение конфликтных полномочий или SOD-конфликтов (segregation of duties). Этот процесс необходим для обеспечения принципа разделения ответственности, когда один человек не может обладать набором полномочий, позволяющим единолично выполнить критичную для бизнеса операцию. Иными словами, такую задачу должны выполнять два человека или более. Классический пример SOD – это запрет совмещения должностей операциониста и контроллера при проведении банковской операции.

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

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

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

Перспективы IGA 

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

1. Специально спроектированные облачные IGA-сервисы с использованием архитектуры современных облачных приложений. В основном подходят организациям, которым достаточно базового и среднего функционала для интеграции с приложениями on-premises (установленными и эксплуатируемыми на «территории» заказчика). Основные преимущества – быстрое время внедрения, «бесшовная» интеграция, частые апдейты и быстрое наращивание функционала. Недостатки – отсутствие возможности кастомизации и слабые возможности управления доступом в облачных сервисах.

2. Классические IGA-решения, размещаемые в облаке. Востребованы организациями с высокими требованиями к функционалу IGA для управления доступом в приложениях on-premises. Преимущества – передача инфраструктуры и обновлений на сторону сервис-провайдера. Есть возможность кастомизации и использования API, но все изменения должны быть согласованы с сервис-провайдером и спланированы.

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

Также Gartner отмечает, что пока на рынке отсутствуют универсальные решения по модели «as a service», которые были бы способны предоставлять полный IGA-функционал как для on-premises приложений, так и для облачных сервисов.

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

Особенности IGA в России 

Справедливости ради надо отметить, что представленная информация относительно развития IDM-технологий более актуальна для мирового рынка и ориентирована на опыт европейских стран и США. В России наблюдается и вполне понятное отставание, и свои особенности. Можно сказать, что некоторые этапы развития рынка IDM мы просто пропустили, а этап разочарования наступил у нас достаточно быстро. Но оживление рынка, наблюдающееся последние 5 лет, коррелирует не только с ростом спроса на IDM, но и с развитием IGA-функционала. Не будет преувеличением сказать, что современному российскому потребителю уже недостаточно классического IDM, а необходима комплексная система, отвечающая требованиям общепризнанных стандартов в сфере IGA. Да, пока системы рассматриваются только in-house, но это не особенность рынка IDM, а проявление общей тенденции недоверия к SaaS со стороны крупных и средних российских организаций и слабого развития рынка корпоративных SaaS-сервисов.

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

Выводы 

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

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