Как выбрать IAM-систему для Enterprise
Выбор IAM-системы (Identity and Access Management) для крупного бизнеса редко сводится к сравнению чекбоксов в презентации. На практике важны модель идентификации, политики MFA, жизненный цикл учётных записей, интеграции с кадровыми системами и способность работать в доверенном контуре — on-prem или в суверенном облаке.
Ниже — рабочий чеклист для CIO, CISO и архитекторов, которые запускают пилот или программу импортозамещения зарубежных IAM/IDM.
Зачем Enterprise нужна зрелая IAM
В холдинге доступ размазан по десяткам приложений: порталы, ERP, отраслевые системы, внутренние API. Без централизованной идентификации появляются локальные учётки, «вечные» права подрядчиков и ручной отзыв доступа при увольнении. Это прямой риск для ИБ и операционной эффективности.
Класс IAM закрывает единый вход (SSO), многофакторную аутентификацию (MFA), выдачу и отзыв прав, аудит и журналирование. IDM-часть отвечает за процессы жизненного цикла: кто, когда и почему получил доступ.
Ключевые критерии выбора
1. Централизованная аутентификация и SSO
- Единый вход в корпоративные приложения без размножения паролей
- Поддержка протоколов и сценариев, принятых в вашем ландшафте (SAML/OIDC и др. — по требованиям архитектуры)
- Возможность поэтапного подключения приложений, а не «большого взрыва»
2. Политики доступа и MFA
- Обязательная MFA для привилегированных и удалённых пользователей
- Гибкие политики: по роли, контуру, риску операции
- Согласованность с внутренними стандартами ИБ и регламентами холдинга
3. Жизненный цикл учётных записей
- Автоматическая или полуавтоматическая выдача доступа при найме и смене роли
- Быстрый отзыв при увольнении и ротации подрядчиков
- Прозрачная модель владельцев прав (business owner / IT owner)
4. Аудит и соответствие
- Журналы событий аутентификации и изменения прав
- Отчёты для внутренних проверок и внешних аудитов
- Возможность расследовать инцидент: кто получил доступ и когда
5. Контур развёртывания
- On-prem или доверенное российское облако
- Контроль данных идентификации внутри периметра
- Понятная модель обновлений и сопровождения без обязательного публичного SaaS
Типовые ошибки на старте
- Выбрать «красивый SSO» без жизненного цикла. Единый вход без отзыва прав усиливает риск, а не снижает его.
- Игнорировать кадровую интеграцию. Без HR-событий IAM быстро превращается в ручной каталог.
- Не зафиксировать scope пилота. Пилот на 3–5 критичных приложениях даёт измеримый результат быстрее, чем «подключить всё».
- Оценить только UI. Для Enterprise важнее API, журналы, политики и модель развёртывания.
Что проверить до пилота
Перед стартом зафиксируйте:
- список приложений первой волны и владельцев;
- требования к MFA и исключениям;
- сценарии найма, перевода и увольнения;
- требования к журналированию и срокам хранения;
- критерии успеха пилота (время отзыва доступа, доля SSO-покрытия, снижение локальных учёток).
Как оценить результат пилота
Полезные метрики:
- доля приложений с единым входом в scope пилота;
- среднее время отзыва доступа после HR-события;
- число локальных учёток, выведенных из эксплуатации;
- полнота журналов для выбранных сценариев расследования.
Практический вывод
IAM для Enterprise — это не «ещё один логин», а управляемая модель доверия к доступу. Смотрите на SSO и MFA вместе с жизненным циклом, аудитом и контуром развёртывания. Так пилот быстрее превращается в программу, а не в локальный эксперимент одной команды.
Технические детали API и схемы развёртывания смотрите в открытом портале документации.