IdM-системы давно стали привычным элементом корпоративной ИТ-инфраструктуры. Рынок развивается уже не первое десятилетие: у заказчиков есть сформированные ожидания, у вендоров зрелые продукты, у команд ИБ и ИТ — накопленная практика внедрения и эксплуатации.

Яков Фишелев, соучредитель Octopus Identity

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

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

Антон Фроловский, руководитель команды разработки Octopus Identity

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

Graph как новые «мозги» IdM

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

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

Именно здесь появляются графовые технологии. Переход на графовые структуры (Identity Graph) радикально меняет архитектуру систем управления доступом. Graph-подход позволяет смотреть на инфраструктуру айдентити не как на набор отдельных записей, а как на комплекс взаимосвязей: кто к чему имеет доступ, через какие группы он его получил, какие права наследуются, где появляются аномалии, какие связи создают избыточные риски.

Фактически Idenity Graph становится новыми «мозгами» IdM. При таком подходе данные не просто хранятся, а помогают системе находить закономерности, выявлять скрытые зависимости, подсказывать решения и быстрее отвечать на сложные вопросы. Например, аналитик может увидеть, почему у сотрудника появился доступ к критичной системе, какие промежуточные связи к этому привели и насколько такой доступ соответствует его текущей роли. Руководитель может быстрее оценить риски по подразделению. Специалист ИБ — найти нетипичные полномочия или потенциально опасные комбинации прав.

Для IdM-систем это серьезный шаг в развитии: система перестает быть только инструментом исполнения заранее заданных процессов и становится аналитической платформой, которая помогает понимать реальное состояние доступа в компании.

От последовательных процессов к политикам

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

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

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

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

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

Новое взаимодействие с IdM: от сложного UI к вербальным задачам

Еще одно заметное направление эволюции — изменение пользовательского опыта. Исторически IdM-системы опирались на сложные интерфейсы. Это было логично: чтобы управлять доступом, заявками, согласованиями, отчетами, ролями, правами и интеграциями, нужно было создать множество экранов, форм, фильтров и настроек.

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

Появление больших языковых моделей (LLM) начинает менять этот сценарий. Взаимодействие с IdM постепенно может перейти от сложных интерфейсов к естественным формулировкам задач. Пользователь сможет не искать нужный раздел в интерфейсе, а просто сформулировать текстовый запрос: проанализировать сотрудника на наличие рискованных полномочий, подготовить отчет по доступам за определенный период, показать нетипичные права в подразделении, объяснить причину выдачи доступа или предложить изменения в политике.

Такое взаимодействие можно назвать identity-взаимодействием нового типа: когда система понимает задачу на естественном языке и помогает решать ее без глубокого знания внутренней логики IdM. Это применимо не только к аналитике и отчетности. Потенциально через вербальные формулировки можно будет ставить и более инженерные задачи: создавать новые политики, описывать коннекторы, проверять корректность правил, моделировать последствия изменений.

Для бизнеса это означает снижение порога входа. Руководители, аналитики ИБ, владельцы систем и специалисты по рискам смогут работать с IdM напрямую, не превращая каждую задачу в отдельный запрос к администраторам или разработчикам.

Неодушевленные identity и AI-агенты: новый вызов для IdM

Отдельно стоит выделить рост неодушевленных identity. Раньше основной объект управления в IdM был понятен: сотрудник, подрядчик, внешний пользователь. Сегодня к ним добавляются сервисные учетные записи, API-ключи, токены, приложения, роботы, интеграционные аккаунты и AI-агенты.

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

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

Здесь декларативный подход и динамическая авторизация на основе политик являются ключевыми. Вместо описания всех возможных шагов система может задавать рамки: какие действия допустимы, в каком контексте, с какими ресурсами, при каких условиях и с каким уровнем контроля.

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

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

IdM как архитектурное решение на годы вперед

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

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

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

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

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

Значит ли это, что классические IdM исчезнут?

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

Главный вопрос будет не в том, добавил ли вендор AI-модуль или новый маркетинговый термин в описание продукта. А в том, позволяет ли архитектура системы работать с новой реальностью: графовыми связями, динамическими политиками, контекстной авторизацией, естественным языком взаимодействия, неодушевленными identity и AI-агентами.

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

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

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