Этой статьей я хотел бы продолжить историю развития IDM-технологий, делая акцент в большей степени на функциональности систем данного класса, нежели на отечественной действительности. Вообще, хотя термин IDM (identity management) плотно закрепился за данной областью по крайней мере в России, более современное название IGA (identity governance and administration) лучше отражает функциональность решений, представленных на рынке в настоящее время. Поэтому предметом данной статьи по сути будет эволюция IDM-решений в IGA.
«Кривая» успешности
Рисунок. «Кривая» Hype Cycle от компании Gartner
Если IDM поместить на эту кривую, то можно однозначно сказать, что данные технологии уже пережили этапы роста и спада ожиданий и сейчас находятся на плато продуктивности, правда уже под названием IGA. Давайте теперь подробнее рассмотрим, с какими препятствиями столкнулся рынок IDM на разных этапах своего «жизненного» пути и каким образом трансформировался в IGA.
От User provisioning к IDM
Первые IDM-решения появились в начале 2000-х годов и обеспечивали набор функций, который принято называть user provisioning. Чтобы вышеперечисленные операции можно было автоматизировать, архитектура IDM предполагала интеграцию с кадровыми системами как с источниками информации о пользователях, а также с т. н. «целевыми» (управляемыми) информационными системами — для автоматизированного применения к ним операций по настройке доступа. Также объектная модель IDM должна была содержать роли, связывающие конкретный набор полномочий в информационной системе с должностью и подразделением пользователя. С такой функциональностью IDM-решения обеспечили минимальный набор базовых сценариев: автоматическое создание учетной записи и предоставление прав в системе при приеме на работу (заведении сотрудника в кадровой системе), изменение прав при переводе на другую должность, отзыв прав и блокирование учетных записей при увольнении.
Надо признать, что функциональности user provisioning было далеко недостаточно. Для обеспечения автоматического выполнения операций по доступу, необходимо было разработать ролевую модель, где каждой должности соответствовали бы роли, включающие в себя конкретный перечень полномочий в целевой системе. Даже если оставить в стороне вопросы трудоемкости создания ролевой модели, оказалось, что в большинстве организаций это попросту невозможно. В реальной жизни сотрудники, находящиеся на одинаковых (по названию) должностях, могли выполнять разные должностные обязанности, предполагающие существенно разные полномочия по доступу к информационным ресурсам. Возникал и ряд других проблем, связанных с предоставлением прав в обход IDM системы, отсутствием самообслуживания и возможности гибкого построения отчетов.
В результате произошла первая трансформация IDM, когда в составе этих решений появились модули управления заявками и самообслуживания, реконсиляции и построения отчетов. Теперь, чтобы обеспечить предоставление разных полномочий сотрудникам на одинаковых должностях, можно было использовать комбинированную ролевую модель, где автоматически по должности предоставлялись только базовые роли, а все остальные полномочия запрашивались по заявке сотрудником или его руководителем. При этом функционал workflow (управление заявками) позволял гибко настроить бизнес-процесс согласования полномочий в зависимости от организационной структуры, роли или ресурса. На мой взгляд это уже был первый шаг в сторону IGA, поскольку в процесс управления доступом стал вовлекаться бизнес (как сторона, согласующая доступ в роли непосредственного руководителя пользователя или владельца информационного ресурса/роли). Для обеспечения аудита изменений по доступу в целевых системах в составе IDM также появился модуль реконсиляции, обеспечивающий сравнение перечня учетных записей и их полномочий, предоставленных или сертифицированных (одобренных) через IDM, с фактическими учетными записями в целевой системе. Если в процессе реконсиляции обнаруживаются расхождения (например, неизвестная учетная запись, лишнее или недостающее право, отличающиеся свойства учетной записи), — это сигнал о том, что изменения, приведшие к выявленным расхождениям, были выполнены в обход IDM.
С такой функциональностью IDM-решения просуществовали достаточно долго, но с развитием технологий автоматизации бизнеса, а также ростом киберугроз и внутреннего фрода стало понятно, что IDM должен не только оптимизировать деятельность ИТ и отвечать требованиям бизнеса, но и соответствовать актуальным вызовам информационной безопасности и требованиям регуляторов.
От IDM к IGA
В первую очередь это появление гибких процессов сертификации и ресертификация/аттестации доступа. Сертификацией доступа — это процесс, «узаконивающий» полномочия пользователя, полученные до внедрения IDM. Т.е. когда мы вносим пользователя уже с существующими учетными записями и правами в IDM, мы должны определить и подтвердить через процесс согласования какие его полномочия действительно необходимы ему, а какие нет. Несогласованные полномочия автоматически отзываются. Таким образом, мы как бы подводим черту, что с момента внесения пользователя в IDM все изменения в его полномочиях однозначно идентифицируются с корпоративными правилами, ролевой моделью и ответственными за их согласование. Аттестация или ресертификация доступа это процесс, который также необходим, чтобы проверить и согласовать текущие полномочия пользователя, но осуществляется он при наступлении определенных событий, например, при переводе по должности, или на регулярной основе — в соответствии с настроенными политиками. Как правило, аттестация доступа осуществляется раз в год владельцем ресурса, для которого автоматически формируются задачи на согласование полномочий доступа по его ресурсу. Несогласованные полномочия также отзываются.
Еще одним важным процессом в IGA является выявление и предотвращение конфликтных полномочий или SOD-конфликтов (segregation of duties). Этот процесс необходим для обеспечения принципа разделения ответственности, когда один человек не может обладать набором полномочий, позволяющим единолично выполнить критичную для бизнеса операцию. Иными словами, такую задачу должны выполнять два человека или более. Классический пример SOD – это запрет совмещения должностей операциониста и контроллера при проведении банковской операции.
Для осуществления подобного контроля в IGA настраивается матрица конфликтных полномочий, где указываются какие роли не должны быть совмещены. Конфликтовать могут как роли, настраиваемые в IGA, так и конкретные права на уровне целевой системы. Как правило, контроль SOD-конфликтов осуществляется при сертификации доступа, при запросе доступа через workflow и при назначении ролей. При этом реагирование на обнаруженные конфликты может быть разным. Например, при выявлении конфликта полномочий в ходе формирования заявки на доступ система может попросить отредактировать заявку или направить ее на дополнительное согласование. Также конфликтному набору прав может быть повышен уровень риска, что потребует более частого прохождения процедуры ресертификации.
Следующее значительное дополнение в IGA — это скоринг рисков. Уже по названию легко догадаться, что это процесс подсчета рисков. По сути, IGA предоставляет риск-ориентированную модель управления доступом. Для каждого права, роли и ресурса определяется риск — в зависимости от степени их критичности. Например, высокий риск может быть присвоен правам доступа к информации с высоким грифом конфиденциальности или привилегированным полномочиям. Далее, для каждого пользователя и должности автоматически (с использованием встроенной математической модели) осуществляется оценка рисков в зависимости от совокупности полномочий. При этом подсчет осуществляется динамически в момент сертификации доступа, запроса полномочий или назначения ролей. Компенсация полученных рисков (так же, как и для SOD) может осуществляться разными способами — в зависимости от уровня риска. Это может быть простое предупреждение, дополнительные этапы согласования, отказ в выдаче доступа, отзыв прав при сертификации и отдельные политики ресертификации доступа.
Вот такие новые функциональные блоки появились в IGA. Но и в классическом функционале IDM есть изменения, затронувшие процессы аудита, мониторинга и отчетности, а также управления ролевой моделью и workflow. Так, если в IDM основной акцент делался на автоматизации конечных операций с помощью заранее настроенной ролевой модели, то в IGA на первый план вышло развитие процессов, где в большей степени участвует сам пользователь. Ролевая модель все больше трансформируется в набор полномочий по доступу к ресурсам, формируемый непосредственно бизнесом. Это позволяет повысить его ответственность за решения по управлению доступом и его осведомленность в этих вопросах, а также ускорить запуск системы IGA в эксплуатацию.
Перспективы IGA
Специально спроектированные облачные IGA-сервисы с использованием архитектуры современных облачных приложений. В основном подходят организациям, которым достаточно базового и среднего функционала для интеграции с приложениями on-premises (установленными и эксплуатируемыми на «территории» заказчика). Основные преимущества – быстрое время внедрения, «бесшовная» интеграция, частые апдейты и быстрое наращивание функционала. Недостатки – отсутствие возможности кастомизации и слабые возможности управления доступом в облачных сервисах.
Классические IGA-решения, размещаемые в облаке. Востребованы организациями с высокими требованиями к функционалу IGA для управления доступом в приложениях on-premises. Преимущества – передача инфраструктуры и обновлений на сторону сервис-провайдера. Есть возможность кастомизации и использования API, но все изменения должны быть согласованы с сервис-провайдером и спланированы.
Решения по SSO-аутентификации и авторизации в облачных сервисах с ограниченным набором IGA-функционала. Подходят организациям, делающим акцент на управлении аутентификацией и авторизацией в основном в облачных приложениях, при этом требования к IGA не сильно востребованы и будут расти постепенно.
Также Gartner отмечает, что пока на рынке отсутствуют универсальные решения по модели «as a service», которые были бы способны предоставлять полный IGA-функционал как для on-premises приложений, так и для облачных сервисов.
В качестве еще одного перспективного тренда можно отметить применение в IGA-системах технологии машинного обучения. Этот тренд актуален в целом для ИТ-отрасли и хорошо укладывается в концепцию управления доступом, так как позволяет, используя риск-ориентированную модель, эффективнее выстроить такие процессы как согласование доступа, сертификация и отчетность.
Особенности IGA в России
И хотя наличие IGA-инструментов уже является важной характеристикой при выборе IDM-решения отечественными потребителями, с практикой применения этих инструментов дела обстоят несколько хуже. Но я уверен, что появление и развитие российских IGA-решений в самом скором времени изменят ситуацию в лучшую сторону.
Выводы
Олег Губка, директор по развитию Аванпост
Автоматизация процессов управления доступом и жизненным циклом учетных записей, которую обеспечивают классические IDM-системы, приносит большую пользу организации: устраняет задержки между кадровыми событиями и их адекватным отражением в настройках доступа инфраструктурного и прикладного ПО, позволяет проводить аудиты ИБ, разгружает ИБ-персонал от рутинной работы, делает невозможными многие виды компьютерных преступлений.
Активное развитие сферы электронных услуг и электронного документооборота, происходящее в последние годы, несомненно увеличило объемы мошенничества. Потребовалось законодательное усиление соответствующих мер защиты, одна из которых — подтверждение подлинности получателя услуги или участника документооборота с помощью электронной подписи (ЭП).