Identity Governance and Administration: как построить зрелую систему управления доступом

IGA помогает разобраться с доступами в компании: убрать лишние права, навести порядок в учётках и закрыть уязвимости, которые часто копятся годами. В результате доступы становятся понятными и контролируемыми, без «вечных» пользователей и лишних привилегий.

 

 

 

 

 

 

1. 1. Введение
2. 2. Что такое IGA и чем она отличается от IAM и PAM
3. 3. Этапы построения зрелой модели IGA
   
   1. 3.1. Этап 1. Аудит текущего состояния и инвентаризация
   2. 3.2. Этап 2. Автоматизация базовых операций
   3. 3.3. Этап 3. Формализация ролей
   4. 3.4. Этап 4. Сертификация доступа
   5. 3.5. Этап 5. Интеграция с другими системами
   6. 3.6. Этап 6. Аналитика и управление рисками
4. 4. Типичные ошибки внедрения IGA
   
   1. 4.1. Ошибка 1. Ставка на технологию вместо процессов
   2. 4.2. Ошибка 2. Отсутствие стратегии
   3. 4.3. Ошибка 3. Игнорирование сервисных и технических учётных записей
   4. 4.4. Ошибка 4. Недостаточная интеграция
   5. 4.5. Ошибка 5. Отсутствие вовлечённости бизнеса
5. 5. Мониторинг и оценка зрелости IGA
6. 6. Выводы

Введение

Учётные записи остаются самым быстрым и удобным входом в корпоративную инфраструктуру — именно с них начинаются многие атаки. По данным BI.ZONE, почти 40 % киберинцидентов в 2025 году так или иначе были связаны с привилегированными учётными записями, а в большинстве случаев злоумышленники просто входили под действующими данными. Наибольшую угрозу создают незаблокированные аккаунты уволенных сотрудников, отсутствие автоматизации и бесконтрольные сервисные учётные записи.

Identity Governance and Administration (IGA) — это комплексный подход к управлению жизненным циклом доступа. Он включает ролевую модель, политики безопасности, аудит действий пользователей, сертификацию доступа к корпоративным системам и контроль соответствия регуляторным требованиям. В отличие от IDM (Identity Management), который автоматизирует только создание и удаление аккаунтов, IGA помогает регулярно проверять, нужны ли сотруднику его права, следить за разделением обязанностей и делать все операции с доступом прозрачными.

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

Что такое IGA и чем она отличается от IAM и PAM

Термины IGA, IAM и PAM часто упоминают рядом, но использовать их как взаимозаменяемые нельзя — это разные классы решений, которые закрывают разные задачи в управлении доступом.

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

PAM (Privileged Access Management) работает с привилегированными учётными записями — администраторами, разработчиками, сервисными аккаунтами. PAM хранит пароли в защищённом хранилище, контролирует сессии, автоматически меняет пароли и выдаёт временные права по принципу «точно в срок» (Just-in-Time, JIT). Если IAM отвечает за то, кто входит, то PAM контролирует, как используются расширенные права.

IGA (Identity Governance and Administration) следит за тем, чтобы доступы соответствовали политике компании и требованиям регуляторов. Она управляет жизненным циклом учётных записей: создаёт их при приёме, корректирует права при переводах, блокирует при увольнении.

IGA регулярно проверяет, кто и к чему имеет доступ, контролирует разделение обязанностей (Segregation of Duties, SoD), использует RBAC (управление доступом на основе ролей) или ABAC (модель на основе атрибутов) и анализирует возможные риски.

В отличие от базового IDM, IGA работает не только с людьми, но и с сервисными аккаунтами, API-ключами и машинными идентичностями.

 

Рисунок 1. Как работает система управления идентификацией и доступом (источник: Evolveum)

 

Ключевая разница в том, что IAM отвечает за доступ «прямо сейчас», PAM снижает риски от использования расширенных прав, а IGA отвечает за долгосрочный порядок и прозрачность. Попытка заменить одно другим оставляет дыры в безопасности.

• IAM без IGA — права назначаются вручную и быстро устаревают.
• PAM без IGA — непонятно, какие права есть у обычных сотрудников и зачем.
• IGA без IAM и PAM — не работает, потому что нет аутентификации и защиты привилегированных учётных записей.

В зрелой модели все 3 компонента работают вместе: IAM обеспечивает доступ, PAM контролирует привилегии, а IGA управляет политиками и соответствием. При этом уровень зрелости процессов IGA в России пока низкий. По данным «Информзащиты», на 2025 год IAM-решения внедрены лишь в 4 % промышленных организаций.

 

Таблица 1. Сравнение IAM, PAM, IGA

 

Этапы построения зрелой модели IGA

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

Этап 1. Аудит текущего состояния и инвентаризация

На этом этапе компания подключает источник идентичностей (identity source), обычно HR-систему с данными о сотрудниках и подрядчиках. В единый перечень добавляются сервисные учётные записи, API-ключи и машинные идентичности. Из этих данных формируется каталог прав (entitlement catalog) — основа для всех последующих процессов управления доступом.

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

Создаётся взаимосвязанная модель данных, где каждый объект (человек, сервис, ключ, машина) имеет уникальный идентификатор и набор атрибутов.

Этап 2. Автоматизация базовых операций

Создание и удаление учётных записей переводится из ручного режима в автоматический через механизм автоматического предоставления и отзыва прав (provisioning). Коннекторы связывают IGA с Active Directory (AD), корпоративными приложениями и облачными сервисами. При каждом кадровом событии (приём, перевод, увольнение) запускается цепочка операций.

Технически процесс выглядит так: HR-система как источник идентичностей (identity source) фиксирует событие о новом сотруднике. Механизм автоматического предоставления прав инициирует автоматическое создание учётных записей в AD, почтовой системе и внутренних порталах.

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

Например, ВТБ в рамках импортозамещения перешёл с Oracle Identity Management на российскую платформу Solar inRights. Система интегрирована с 22 информационными системами, автоматически управляет жизненным циклом учётных записей и ежемесячно обрабатывает более 340 000 задач — от создания учётной записи при приёме до блокировки при увольнении.

Бренд «Добрый» (8 500 сотрудников) внедрил IdM/IGA-решение Ankey IDM. До автоматизации права выдавались вручную — по звонкам и заявкам, без единого каталога. Новый сотрудник ждал доступа до 48 часов. После внедрения время выдачи базовых прав сократилось с 1–2 дней до 1–2 часов, 75–85 % типовых заявок обрабатываются автоматически, нагрузка на администраторов снизилась на 30–50 %.

Этап 3. Формализация ролей

Когда автоматизация базовых операций налажена, компания переходит к структурированию доступа. Здесь работает слой управления доступом (access governance), который отвечает за ролевую модель, политики и правила разделения полномочий (SoD). Права перестают назначаться вручную — сотрудники получают их по должности, функции или контексту. В основе лежат подходы RBAC и ABAC.

RBAC (Role-Based Access Control) — управление доступом на основе ролей. Каждая должность или функция соответствует заранее определённому набору прав. Модель проста в реализации и хорошо подходит для компаний со стабильной структурой, но плохо масштабируется: при росте числа ролей система становится громоздкой и требует значительных усилий для поддержки.

ABAC (Attribute-Based Access Control) — управление доступом на основе атрибутов. Решение о предоставлении прав принимается с учётом дополнительных параметров: подразделения, проекта, местоположения, времени или контекста. Модель гибкая и точная, но требует развитой инфраструктуры и строгого управления атрибутами.

Обычно компании начинают с RBAC как более понятной и быстрой модели, а затем переходят к гибридным схемам, где роли дополняются атрибутами.

Этап 4. Сертификация доступа

После формализации ролей компания переходит к регулярной проверке актуальности прав. За это отвечает механизм сертификации (certification engine). Он запускает кампании проверки доступа, рассылает запросы руководителям и владельцам систем, собирает подтверждения и формирует отчётность. Сертификация становится обязательным процессом: руководитель в несколько кликов подтверждает или отзывает права подчинённого.

Такой механизм позволяет выявлять избыточные привилегии, устранять конфликты полномочий (SoD), соответствовать требованиям регуляторов и снижать риски инсайдерских угроз. Компания уходит от модели «назначили и забыли» и переходит к постоянному контролю актуальности прав.

Этап 5. Интеграция с другими системами

IGA становится частью единого контура безопасности только при тесной связке с ключевыми корпоративными системами. Здесь работает слой интеграции (integration layer), который обеспечивает двусторонний обмен данными через коннекторы и API с использованием стандартных протоколов (SCIM, LDAP, REST).

IGA получает кадровые события из HRM-системы, автоматически обновляя атрибуты сотрудников. Логи событий доступа передаются в SIEM (Security Information and Event Management) для корреляции и расследований. Интеграция с PAM синхронизирует привилегированные учётные записи и обеспечивает контроль над высокорисковыми действиями, позволяя, например, автоматически отзывать права администратора при увольнении.

Этап 6. Аналитика и управление рисками

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

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

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

 

Рисунок 2. Архитектура IGA-системы (источник: Evolveum)

 

Типичные ошибки внедрения IGA

Даже при наличии платформы компании часто сталкиваются с тем, что управление доступом остаётся хаотичным и малоэффективным. Ниже — ключевые просчёты, которые мешают построить зрелую модель IGA.

Ошибка 1. Ставка на технологию вместо процессов

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

Ошибка 2. Отсутствие стратегии

IGA невозможно внедрить стихийно. Если нет дорожной карты — от инвентаризации до интеграции с PAM и SIEM, проект быстро теряет динамику. В итоге появляются наполовину реализованные решения, которым не доверяют ни пользователи, ни аудиторы.

Ошибка 3. Игнорирование сервисных и технических учётных записей

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

Ошибка 4. Недостаточная интеграция

IGA, работающая в изоляции, не обеспечивает единого контура безопасности. Без связки с HRM права не отзываются вовремя, без PAM остаются уязвимыми привилегированные учётные записи, а без SIEM теряется аналитика событий. Зрелость невозможна без интеграции.

Ошибка 5. Отсутствие вовлечённости бизнеса

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

Мониторинг и оценка зрелости IGA

Зрелость IGA нельзя определить только по факту внедрения платформы. Даже самая дорогая система не работает без процессов, регулярного контроля и вовлечённости бизнеса. Поэтому компании используют мониторинг и набор показателей, которые позволяют оценить реальное состояние управления доступом.

Что мониторят:

1. Жизненный цикл учётных записей — скорость создания учётных записей и базовых прав при приёме, своевременность изменения прав при переводе, время блокировки аккаунта после увольнения.
2. Сертификация доступа — доля завершённых кампаний и количество выявленных избыточных прав.
3. Ролевая модель — процент сотрудников, получающих доступы через роли, а не вручную.
4. Сервисные аккаунты — сколько технических учётных записей находится под управлением IGA и проходят ли они регулярные проверки.
5. Интеграция — связка с HRM, SIEM, PAM, скорость синхронизации событий и отзыва прав.
6. Аналитика рисков — число выявленных конфликтов полномочий, отчёты по аномалиям и результаты внешних аудитов.

TechVision Research выделяет 5 уровней зрелости — от ручного хаотичного управления до полностью автономных процессов на базе ИИ. Модель опирается на конкретные метрики каждого уровня: соглашение об уровне обслуживания (Service Level Agreement, SLA) по созданию учётной записи (например, создание за 5–15 минут вместо часов или дней), долю избыточных прав после сертификации, процент автоматизированных назначений через роли, скорость блокировки учётной записи после увольнения, частоту и полноту кампаний сертификации, долю сервисных аккаунтов под управлением IGA и количество устранённых конфликтов полномочий.

Эти показатели позволяют объективно оценить текущее состояние и сформировать реалистичную дорожную карту развития IGA.

Выводы

Зрелая IGA — это не просто внедрение платформы и не формальное выполнение требований. Хорошо выстроенная модель управления доступом делает процессы предсказуемыми. Новый сотрудник получает все необходимые права в первый рабочий день, финансовый отдел точно знает, кто имеет доступ к конфиденциальным данным, а служба безопасности может доказать аудиторам, что контроль действительно работает. При увольнении доступ блокируется сразу, а не остаётся активным неделями или месяцами.

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