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