Почему внедрение IAM-системы похоже на цунами: ошибки внедрения

Быстрый запуск типового IAM – не гарантия успеха. Показываем, как накапливается сложность и что делать, чтобы проект не вышел из-под контроля. Алексей Хмельницкий, генеральный директор RooX

Мы специализируемся на разработке и внедрении систем управления доступом и наблюдаем, как некоторые компании на определенном этапе пробуют самостоятельно решать задачи аутентификации и авторизации на базе open-source инструментов. Для старта это часто выглядит рациональным выбором, если есть свой отдел разработки.

Однако часто экспертиза собственных разработчиков сфокусирована на развитии ключевых бизнес-функций и в области управления доступом ее недостаточно. И тогда внедрение IAM можно сравнить с цунами.

IAM как цунами

Сначала – полное спокойствие. Ровная вода, ясный горизонт. Компания берет готовое решение, чаще всего open source. За несколько дней разворачивает его в продакшене, подключает пару приложений по стандартным протоколам вроде OIDC или SAML, добавляет MFA через TOTP. Всё работает. Демонстрация проходит успешно. В отчетах появляется галочка: «IAM внедрен».

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

Потом «вода начинает уходить от берега». Дело доходит до приложения, которое написал подрядчик 10 лет назад и оно не поддерживает SSO вообще. Как на грех, им пользуется большинство сотрудников. Это уже системная аномалия, но пока она воспринимается как частная экзотика. Полюбовавшись на диковинку, приложение решают не трогать: слишком сложно.

На горизонте появляется тёмная линия. Сначала кажется, что это просто очередная волна. Часть сотрудников «в полях» отказывается использовать второй фактор – у кого-то мало места, кому-то неудобно, у кого-то принципы. Приходится делать исключения. Кроме того пользователей начинает разлогинивать в неожиданные моменты. Разбор занимает недели: специалистов по IAM внутри компании нет, документация ограничена. Наконец, проблема оказывается известным багом. Обновление требует доработок, доработки ломаются при обновлении. Технический долг начинает расти быстрее, чем система.

И вот удар. Бизнес задаёт прямой вопрос: «Почему за полгода IAM так и не внедрён?» И это правда: из всех систем к IAM подключены только четверть, причем без самой популярной, двухфакторка у половины сотрудников не работает, пользователи жалуются, что их внезапно разлогинивает.

После удара кажется, что худшее позади, но это иллюзия. Система уже фрагментирована: часть доступов выдана вручную, часть – через IAM, часть приложений живёт вне контура. Любое изменение требует всё больше усилий, а каждая новая интеграция увеличивает риск. Пользовательский опыт остаётся нестабильным, бизнес – недоволен, команда – перегружена.

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

Просто это было не внедрение

Реальный потенциальный клиент: «Начали работать с Keycloak. Набьем шишки, тогда пойдем к вам».

В таких случаях мы предпочитаем рассматривать «набивание шишек» как способ сформировать осознанный запрос. Пройдя этот этап, компания гораздо точнее понимает свои требования к функциональности, безопасности, масштабируемости и управляемости IAM-системы, и почему эти задачи становятся отдельной зоной экспертизы.

Переход к промышленному IAM-решению обычно становится логичным продолжением этого пути. И чем раньше появляется понимание, что аутентификация – это не вспомогательная функция, а критический слой архитектуры, тем спокойнее проходит этот переход.

Аналитика перед внедрением

В работе с нашими заказчиками мы стараемся обойтись без «шишек»: помогаем сформировать требования к IAM-системе заранее, опираясь на накопленную практику внедрений и реальные сценарии использования.

1. Определяем приоритетные бизнес-цели заказчика. Звучит банально, но именно это часто и является проблемой. Снижение операционных издержек, минимизация рисков несанкционированного доступа, соответствие регуляторным требованиям, улучшение UX для клиентов вашего сервиса, что-то другое? Ответ «нужно все» нерабочий, добиваемся расставления приоритетов.
2. Определяем типы пользователей, для которых необходимо организовать централизованную аутентификацию в IAM.
3. Составляем список систем, которые нужно подключить к IAM. Определяем их технические особенности в части интеграции с IAM.
4. Прорабатываем сквозные сценарии того, как выбранные типы пользователи получают доступ к выбранным приложениям.
5. Считаем реальный бюджет на внедрение IAM, включая интеграцию и поддержку пользователей.

Мы рекомендуем сначала проработать по этому списку весь ИТ-ландшафт и только после этого выделять ядро для первого этапа внедрения. Это позволяет быстрее прийти к рабочей архитектуре IAM-системы и избежать типовых ошибок, которые обычно выявляются уже в процессе эксплуатации.