Внедрение IAM-системы похоже на цунами: ошибки внедрения
Июнь, 2026
Быстрый запуск типового IAM — не гарантия успеха: сложность накапливается незаметно, и проект выходит из-под контроля. Автор — Алексей Хмельницкий, генеральный директор RooX, компании, специализирующейся на разработке и внедрении систем управления доступом.
Компании с собственным отделом разработки часто начинают решать задачи аутентификации и авторизации на open-source инструментах — для старта это рациональный выбор. Однако экспертиза собственных разработчиков обычно сфокусирована на ключевых бизнес-функциях, и в области управления доступом её недостаточно.
IAM как цунами
-
Сначала — полное спокойствие: готовое open-source решение за несколько дней разворачивается в продакшене, подключает пару приложений по стандартным протоколам (OIDC, SAML), добавляет MFA через TOTP. В отчётах появляется галочка “IAM внедрён”.
-
Первая “рябь на воде”: следующее приложение “почти” поддерживает стандарт — приходится написать плагин к IAM, но никто не воспринимает это как проблему.
-
“Вода начинает уходить от берега”: находится написанное подрядчиком 10 лет назад приложение, которое вообще не поддерживает SSO, — и им пользуется большинство сотрудников. Приложение решают не трогать.
-
Тёмная линия на горизонте: сотрудники “в полях” отказываются от второго фактора, появляются исключения; пользователей начинает разлогинивать в неожиданные моменты. Разбор занимает недели — специалистов по IAM нет, документация ограничена; обновление требует доработок, доработки ломаются при обновлении. Технический долг растёт быстрее системы.
-
Удар: бизнес задаёт прямой вопрос “Почему за полгода IAM так и не внедрён?” — подключена только четверть систем (без самой популярной), двухфакторка не работает у половины сотрудников.
-
После удара система уже фрагментирована: часть доступов выдана вручную, часть приложений живёт вне контура, каждая новая интеграция увеличивает риск. Остаётся угроза следующей “волны”: фундамент так и не был перестроен.
Просто это было не внедрение
Реальный потенциальный клиент: “Начали работать с Keycloak. Набьём шишки, тогда пойдём к вам”. Пройдя этот этап, компания гораздо точнее понимает свои требования к функциональности, безопасности, масштабируемости и управляемости IAM-системы — и почему эти задачи становятся отдельной зоной экспертизы. Переход к промышленному IAM-решению становится логичным продолжением пути: чем раньше появляется понимание, что аутентификация — критический слой архитектуры, а не вспомогательная функция, тем спокойнее проходит переход.
Аналитика перед внедрением
Чтобы обойтись без “шишек”, требования к IAM стоит сформировать заранее:
-
определить приоритетные бизнес-цели (снижение операционных издержек, минимизация рисков несанкционированного доступа, соответствие регуляторным требованиям, улучшение UX) — ответ “нужно всё” нерабочий;
-
определить типы пользователей, которым необходима централизованная аутентификация;
-
составить список подключаемых систем и их технических особенностей интеграции;
-
проработать сквозные сценарии получения пользователями доступа к приложениям;
-
посчитать реальный бюджет, включая интеграцию и поддержку пользователей.
Рекомендуется сначала проработать по этому списку весь ИТ-ландшафт и только после этого выделять ядро первого этапа внедрения — это быстрее приводит к рабочей архитектуре IAM и позволяет избежать типовых ошибок, которые обычно выявляются уже в процессе эксплуатации.
Это краткая аннотация статьи, полную версию читайте в первоисточнике.
Первоисточник: GlobalCIO, 08.06.2026
Эксперт: Алексей Хмельницкий, RooX