Что такое IdM: система управления идентификацией и доступом

IdM (Identity Management) — класс систем, которые управляют учётными записями и правами доступа пользователей на протяжении всего их жизненного цикла в организации: от создания аккаунта при найме до блокировки при увольнении. В русскоязычной практике термин чаще всего используют как синоним более широкого понятия IAM (Identity and Access Management) — управление идентификацией и доступом: строго говоря, IAM — зонтичная категория, куда помимо собственно управления учётными записями (IdM) входят и смежные функции вроде единого входа или многофакторной аутентификации, но на практике вендоры и заказчики почти всегда говорят об одном и том же классе средств, называя его то IdM, то IAM.

Расширенную версию класса иногда обозначают отдельной аббревиатурой IGA (Identity Governance and Administration) — управление идентификацией с усиленным governance-контуром: помимо провижининга и ролевой модели такая система умеет периодически перепроверять уже выданные права (рецертификация) и находить конфликтные комбинации полномочий (SoD, о них ниже). На российском рынке грань между «просто IdM» и «IdM/IGA» часто размыта — большинство зрелых платформ включают обе группы функций в одном продукте.

Суть системы — не в самом факте входа пользователя в приложение, а в вопросе «кто и какие права должен иметь и почему». Без централизованного управления это решается вручную: администратор заводит учётку по заявке в почте или тикете, права накапливаются при переводах между отделами и часто не отзываются, а учётные записи уволенных сотрудников остаются активными неделями. IdM переводит этот процесс в автоматизированный и проверяемый workflow.

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

• Provisioning (создание). При появлении сотрудника в кадровой (HR) системе IdM автоматически создаёт для него учётные записи в нужных информационных системах и назначает типовой набор прав, привязанный к должности или подразделению — без ручной заявки в каждую систему по отдельности.
• Изменение прав. При переводе сотрудника на другую должность или в другое подразделение система пересчитывает набор прав: часть отзывается, часть добавляется — вместо того чтобы новые права просто накапливались поверх старых.
• Ролевая модель (RBAC, Role-Based Access Control). Права назначаются не конкретному человеку вручную, а через роль, привязанную к должности или функции. Это делает процесс предсказуемым и проверяемым: понятно, какой набор доступа у роли «бухгалтер» или «системный администратор», а не только у конкретного Иванова.
• Deprovisioning (блокировка). При увольнении или окончании срочного доступа IdM блокирует все учётные записи сотрудника разом — это закрывает типичный риск «мёртвых душ»: активных аккаунтов бывших сотрудников, о которых забыли вручную сообщить в ИТ.

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

IdM (IAM), PAM и SSO — три смежных, но разных класса управления доступом: они нередко продаются как модули одной Identity-платформы одного вендора, но закрывают разные задачи и разных пользователей. Путаница между ними — частая причина того, что компания покупает не тот продукт под свою задачу.

↔ таблицу можно прокрутить вбок

Разница особенно заметна на уровне конкретных продуктов одного вендора: например, у «Аванпоста» это отдельные Avanpost IDM (управление учётными записями) и Avanpost FAM (единый вход) — разные продукты с разными сертификатами ФСТЭК, а не один продукт под двумя названиями. Компании, которой нужно решить «как сотруднику не вводить пароль в каждое приложение по отдельности», нужен SSO; компании, которой нужно решить «кто и почему имеет доступ к конкретной системе и как быстро закрыть его при увольнении», нужен IdM — и часто со временем нужны оба класса вместе.

Помимо базового цикла provisioning → deprovisioning, зрелая IdM-платформа закрывает ещё несколько функций, без которых управление доступом в крупной организации быстро превращается в хаос из ручных заявок.

• Централизованное управление учётными записями. Единая точка правды о том, какие учётные записи и права есть у каждого сотрудника во всех подключённых системах — вместо разрозненных списков доступа, которые ведёт каждый администратор по отдельности.
• Автоматизация provisioning. Создание, изменение и блокировка учётных записей по событиям из кадровой системы, без ручного вмешательства ИТ-администратора на каждом шаге.
• Согласование заявок на доступ (workflow). Запрос на доступ к конкретной системе проходит цепочку согласования — руководитель, владелец ресурса, служба ИБ, — а не выдаётся по устной договорённости.
• Рецертификация. Периодическая (например, ежеквартальная) проверка уже выданных прав: актуальны ли они всё ещё для текущей должности сотрудника, — функция, которую чаще относят к расширенному контуру IGA.
• Разделение полномочий (SoD, Segregation of Duties). Выявление конфликтных комбинаций прав — например, ситуации, когда один и тот же сотрудник может и создать платёж, и подтвердить его: это прямой риск мошенничества и типичное требование внутреннего аудита в финансовых организациях.
• Аудит доступа. Журнал того, кто, когда и на каком основании получил или лишился конкретного права — материал для внутренних проверок и для регуляторных проверок соответствия.

Без централизованного управления учётными записями у организации накапливается два типовых риска: избыточные права, которые никто вовремя не отозвал, и активные учётные записи уволенных сотрудников — оба риска IdM закрывает автоматизацией жизненного цикла доступа.

Второй мотив — соответствие регуляторным требованиям. Приказы ФСТЭК, которыми регулируется защита государственных информационных систем (приказ №117, заменивший приказ №17) и значимых объектов критической информационной инфраструктуры (приказ №239), включают отдельную группу мер по идентификации, аутентификации и управлению доступом — то, что технически и автоматизирует IdM-система. Для финансовых организаций схожие требования к процессам управления учётными записями и правами доступа задаёт ГОСТ Р 57580 Банка России.

Отдельно с 20 декабря 2024 года действует профильный национальный стандарт ГОСТ Р 71753-2024 «Системы автоматизированного управления учётными записями и правами доступа. Общие требования» (утверждён приказом Росстандарта №1558-ст от 30.10.2024) — первый добровольный отраслевой ориентир именно для функциональности класса IdM/IGA, отдельного профиля защиты ФСТЭК под этот класс при этом не существует.

На практике это означает, что IdM закрывает не только операционную задачу (быстрее выдать/отозвать доступ), но и часть доказательной базы при проверке регулятором или внутреннем аудите: журнал того, кто и на каком основании получил конкретное право, — готовый ответ на вопрос проверяющего.

В Реестре российского ПО зарегистрировано 225 продуктов с меткой класса 03.12 «Управление доступом» — это широкая категория, объединяющая IdM, PAM, SSO, MFA и другие смежные средства, а не отдельный код именно под IdM/IGA. Специализированных IdM-платформ среди них — заметное меньшинство: большинство записей относится к более узким продуктам вроде SSO- или MFA-решений, которые формально тоже попадают под общую метку класса.

Среди специализированных IdM/IGA-платформ на рынке — Solar inRights (группа РТК-Солар), Avanpost IDM (Аванпост) и Ankey IDM (Газинформсервис); есть и более нишевые продукты для отдельных сегментов, включая решения на отечественном стеке 1С:Предприятие. Часть из них сертифицирована ФСТЭК по требованиям доверия (обычно уровень 4), но не все и не всегда — у части продуктов класса сертификат может быть просрочен или отсутствовать вовсе, поэтому актуальный статус конкретного продукта стоит проверять напрямую в реестре сертифицированных СЗИ ФСТЭК перед закупкой для КИИ или ГИС, а не полагаться на маркетинговые материалы вендора.

Подробное сравнение конкретных российских IdM/IGA-продуктов — с номерами сертификатов ФСТЭК, сроками их действия и сопоставлением с зарубежными аналогами вроде SailPoint IdentityIQ или Oracle Identity Governance — собрано на странице класса.