IGA vs IAM: в чём разница и когда нужен governance доступа
IAM (Identity and Access Management) отвечает на вопрос «кто и как входит»: аутентификация, единый вход (SSO), многофакторность (MFA), управление учётными записями и базовый провижининг. IGA (Identity Governance and Administration) надстраивается сверху и отвечает на вопрос «кто и почему имеет доступ»: ролевые модели, аттестация прав, контроль конфликтов полномочий (SoD), аудит и отчётность, управление жизненным циклом доступа. **Если коротко:** IAM даёт вход, IGA даёт управляемость и доказуемость прав. Малому бизнесу часто достаточно IAM. Как только появляются десятки систем, аудиты, требования регуляторов и текучка персонала, ручное управление доступом перестаёт масштабироваться — и тогда нужен governance. Ниже — чем именно различаются классы, по каким триггерам пора внедрять IGA и как оценить свою готовность. Сравнить поставщиков по подтверждённым сигналам можно в [рейтинге IGA-систем](/rating/identity-governance-iga).
Визуальный контекст исследования
Изображение помогает быстро считать тему материала: инфраструктура, данные, доступы и контрольные точки, которые важно проверить перед выбором решения.
Рейтинги подрядчиков по теме исследования
Если после чтения нужен короткий список исполнителей, начните с профильных рейтингов cyber-index.ru: в них видны компании, кейсы, интервью, категории экспертизы и доверительный индекс.
Как проверять выводы исследования
Используйте материал как основу для shortlist: сопоставьте выводы с профилями компаний, связанными рейтингами, кейсами, интервью клиентов и источниками. Если в статье есть список источников, начинайте проверку с него; если источников мало, дополнительно запросите у подрядчика методику, baseline и примеры работ.
Что делает IAM: вход и базовое управление доступом
IAM — это фундамент управления идентификацией. Его задача — обеспечить, чтобы нужный человек попадал в нужную систему предсказуемым и защищённым способом. Базовый контур IAM:
- **Аутентификация и единый вход (SSO).** Один набор учётных данных на множество приложений, централизованная точка входа. - **Многофакторная аутентификация (MFA).** Дополнительный фактор подтверждения личности — снижает риск компрометации пароля. - **Каталог идентификаций.** Единый источник правды о пользователях (часто на базе каталога предприятия) и синхронизация атрибутов. - **Базовый провижининг.** Создание и блокировка учётных записей в подключённых системах, выдача стартового набора доступов.
IAM хорошо отвечает на вопрос «как пустить пользователя внутрь». Но он, как правило, не отвечает на вопрос «правильный ли это набор прав и кто за него ответил» — а именно это становится критичным с ростом компании.
Что добавляет IGA: governance, аттестация и ролевые модели
IGA не заменяет IAM, а надстраивается над ним и добавляет управляемость прав на всём их жизненном цикле. Governance доступа отвечает на вопросы «кто, почему и на каком основании имеет это право, и кто это подтвердил». Ключевые функции IGA:
- **Ролевые модели (RBAC).** Доступ выдаётся не вручную по заявке, а через роли, привязанные к должности и подразделению, — это снижает хаос «исторически накопленных» прав. - **Аттестация (ресертификация) прав.** Периодический пересмотр: руководители и владельцы систем подтверждают или отзывают доступы подчинённых — основа доказуемости для аудита. - **Контроль конфликтов полномочий (SoD).** Выявление токсичных сочетаний прав (например, «создаёт платёж» и «утверждает платёж» у одного человека). - **Аудит и отчётность.** Кто, когда и кем получил доступ; полная история изменений и готовые отчёты под проверки. - **Управление жизненным циклом (joiner-mover-leaver).** Автоматическая перенастройка прав при найме, переводе и увольнении — без «осиротевших» учёток и накопленных привилегий.
Именно эти функции отличают governance от простого управления входом и делают доступ не только удобным, но и доказуемым.
IAM и IGA: коротко в цифрах
Аутентификация, SSO, MFA, провижининг
Роли, аттестация, SoD, аудит, lifecycle
Внешняя проверка прав или масштаб систем
Зависит от критичности систем и требований
IAM vs IGA: ключевые различия
Ниже — ориентир по различиям классов. Это не рейтинг продуктов: места, баллы и подтверждённые сигналы смотрите в [рейтинге IGA-систем](/rating/identity-governance-iga). Цель таблицы — показать, где заканчивается зона IAM и начинается зона governance.
| Аспект | IAM | IGA |
|---|---|---|
| Главный фокус | Доступ и вход (кто входит) | Governance прав (кто и почему имеет доступ) |
| Ключевые функции | SSO, MFA, аутентификация, провижининг | Роли, аттестация, SoD, аудит, lifecycle |
| Ответ на вопрос аудита | «как пускаем» | «кто подтвердил и на каком основании» |
| Кому достаточно | SMB, простой ИТ-ландшафт | Средний и крупный бизнес, регулируемые отрасли |
| Что закрывает | удобство и защиту входа | доказуемость, минимизацию избыточных прав |
Когда компании пора внедрять IGA
IAM закрывает базовые потребности, но в определённый момент ручное и точечное управление правами перестаёт справляться. Типичные триггеры перехода к governance:
- **Рост числа систем и пользователей.** Когда доступы выдаются в десятки приложений вручную, неизбежно копятся избыточные и «осиротевшие» права. - **Внешние и внутренние аудиты.** Проверяющие требуют доказать, кто, почему и кем подтверждён доступ; без аттестации это превращается в ручной аврал. - **Регуляторика и комплаенс.** Требования к разграничению доступа, его пересмотру и доказуемости подталкивают к формализации governance. - **Высокая текучка и частые переводы.** Без автоматического lifecycle при увольнениях и переводах остаются активные права уже не работающих или сменивших роль сотрудников. - **Инциденты из-за избыточных прав.** Если расследования показывают, что у пользователей было «слишком много», это прямой сигнал о нехватке контроля SoD и аттестации.
Зрелость функций governance доступа
Усреднённая редакционная оценка востребованности и проработанности функций класса IGA по открытым данным. Это не вендорский бенчмарк и не заменяет пилот в вашей инфраструктуре.
Чек-лист готовности к IGA
Путь от IAM к IGA: 5 шагов
-
01
Базовый IAM
Наведите порядок во входе: единый каталог, SSO, MFA, базовый провижининг и блокировка учёток.
-
02
Инвентаризация и очистка прав
Соберите фактические доступы, уберите явно избыточные и «осиротевшие» учётки.
-
03
Ролевая модель
Перейдите от ручных заявок к ролям, привязанным к должностям и подразделениям (RBAC).
-
04
Аттестация и SoD
Запустите периодический пересмотр прав и контроль конфликтов полномочий в критичных системах.
-
05
Автоматизация lifecycle и аудит
Свяжите кадровые события с правами и поставьте отчётность для проверок на поток.
Как мы оцениваем поставщиков
cyber-index.ru не продаёт места в рейтинге. Поставщики сравниваются по проверяемым сигналам: подтверждённые внедрения и кейсы, отзывы и интервью клиентов, внешняя репутация, специализация, прозрачность и свежесть данных. Поэтому статью стоит читать в связке с [рейтингом IGA-систем](/rating/identity-governance-iga): здесь — различия классов и критерии, там — сравнение конкретных компаний по подтверждённым фактам.
Следующий шаг
Разобрались в различиях IAM и IGA — переходите к сравнению поставщиков: **[рейтинг IGA-систем →](/rating/identity-governance-iga)**. Полезно прочитать рядом: [аттестация и ресертификация прав доступа](/research/attestaciya-prav-dostupa) и [рейтинг IGA-систем 2026](/research/rejting-iga-sistem-2026).
Частые вопросы
Чем IGA отличается от IAM простыми словами?
IAM управляет входом: кто, как и с какими факторами попадает в систему (аутентификация, SSO, MFA, провижининг). IGA управляет governance прав: кто, почему и на каком основании имеет доступ, кто это подтвердил и как часто пересматривает. IAM даёт вход, IGA — управляемость и доказуемость прав.
Можно ли обойтись только IAM без IGA?
Для небольшой компании с простым ИТ-ландшафтом базового IAM часто достаточно. Но как только появляются десятки систем, аудиты, требования регуляторов и заметная текучка персонала, ручное управление правами перестаёт масштабироваться — и тогда нужен governance.
Что такое аттестация прав доступа и зачем она нужна?
Аттестация (ресертификация) — это периодический пересмотр, когда руководители и владельцы систем подтверждают или отзывают доступы сотрудников. Она убирает накопленные избыточные права и даёт аудиту доказательство, что доступ актуален и кем-то подтверждён.
Зачем нужны ролевые модели (RBAC)?
Ролевая модель привязывает права к должности и подразделению, а не выдаёт их вручную по каждой заявке. Это снижает хаос «исторически накопленных» прав, ускоряет онбординг и делает доступ предсказуемым и проверяемым.
Где сравнить конкретных вендоров IGA между собой?
В рейтинге IGA-систем — там компании ранжированы по подтверждённым сигналам, а не по рекламе.
Источники и метод проверки
IAM (Identity and Access Management) отвечает на вопрос «кто и как входит»: аутентификация, единый вход (SSO), многофакторность (MFA), управление учётными записями и базовый провижининг. IGA (Identity Governance and Administration) надстраивается сверху и отвечает на вопрос «кто и почему имеет доступ»: ролевые модели, аттестация прав, контроль конфликтов полномочий (SoD), аудит и отчётность, управление жизненным циклом доступа. **Если коротко:** IAM даёт вход, IGA даёт управляемость и доказуемость прав. Малому бизнесу часто достаточно IAM. Как только появляются десятки систем, аудиты, требования регуляторов и текучка персонала, ручное управление доступом перестаёт масштабироваться — и тогда нужен governance. Ниже — чем именно различаются классы, по каким триггерам пора внедрять IGA и как оценить свою готовность. Сравнить поставщиков по подтверждённым сигналам можно в [рейтинге IGA-систем](/rating/identity-governance-iga).