Отечественный PAM с JIT-доступом в финансовом секторе: что внедрили и где обожглись

Рынок отечественных PAM-решений в 2025 году наконец перестал выглядеть как «есть, но лучше не надо». Несколько продуктов прошли через достаточное количество внедрений, чтобы закрыть базовые дыры в документации, а функция JIT-доступа (Just-in-Time provisioning - выдача прав на время сессии вместо постоянного доступа) из маркетингового bullet-point превратилась во что-то рабочее. Мы как раз завершили проект у клиента из финансового сектора - небольшой банк, субъект КИИ - и накопилось достаточно наблюдений, чтобы их зафиксировать.

Задача была стандартной по формулировке и нестандартной по объёму сложностей: внедрить PAM с JIT-доступом для привилегированных пользователей, интегрировать с Active Directory, настроить логирование сессий и вписаться в требования аудита безопасности по периметру КИИ. Выбрали продукт российского вендора - называть не будем, это не сравнительный тест, а разбор конкретного внедрения.

Интеграция с Active Directory: где документация врёт

Первое, что выяснилось на практике: интеграция с Active Directory в режиме JIT - это не то же самое, что просто «подключить LDAP». В классическом PAM без JIT схема простая: пользователь запрашивает доступ, PAM выдаёт ему сессию с готовой учёткой, которая уже существует в целевой системе. JIT предполагает другое: учётка создаётся (или права добавляются к ней) на момент сессии и убираются после. И вот здесь AD начинает ерепениться.

Тайминг репликации. AD в банке был развёрнут с несколькими контроллерами домена, и стандартное время репликации между ними составляло от 15 секунд до нескольких минут в зависимости от нагрузки. PAM создаёт учётку на одном DC, пользователь пытается зайти через другой, который ещё не получил изменение - и получает отказ. Решили через привязку JIT-операций к конкретному DC и настройку явного ожидания репликации. Неизящно, но работает.

Конфликты с групповыми политиками. При добавлении пользователя в привилегированную группу AD некоторые GPO срабатывали мгновенно и меняли настройки рабочей сессии так, что она становилась нерабочей. Пришлось совместно с командой клиента выявлять и перенастраивать конфликтующие политики. Это заняло дольше, чем сама интеграция.

Вложенные группы. Клиент исторически строил права через многоуровневые группы - «группа входит в группу входит в группу». PAM это ел не целиком: JIT-механизм корректно работал только с прямым членством в целевой группе. Пришлось частично реструктурировать группы AD - работа, которую никто не закладывал в план.

Логирование сессий: что это значит на практике

«Логирование сессий» в маркетинговых материалах звучит просто. На практике это значит следующее: PAM проксирует RDP и SSH-соединения, пишет видеозапись экрана или keystroke log (или и то, и другое), и сохраняет это всё в защищённое хранилище. Звучит понятно. Подводные камни начинаются с объёма.

Клиент недооценил дисковое потребление примерно в три раза. Видеозапись RDP-сессии привилегированного администратора, который работает восемь часов, - это десятки гигабайт в день даже со сжатием. Умножаем на количество администраторов и на требуемый срок хранения (по требованиям регулятора - не менее года), получаем объём, который никто не посчитал заранее. Пришлось оперативно расширять хранилище и вводить дифференцированную политику: видео только для сессий на критичных системах, keystroke log - для остальных.

Отдельная история с SSH-сессиями в нестандартных терминальных приложениях: часть администраторов использует кастомные утилиты, которые передают данные в бинарном формате поверх SSH. Keystroke log в этом случае пишет нечитаемый мусор, а видео не помогает - экран черный. Для этих случаев пришлось настраивать логирование через аудит командной оболочки на самих серверах - параллельный механизм, который добавляет сложности в сопровождение.

Зато интеграция с MaxPatrol SIEM через syslog прошла относительно гладко: события о запросе доступа, выдаче JIT-привилегий и окончании сессии пошли в SIEM без дополнительных плясок. Корреляционные правила под PAM-события пришлось писать с нуля, готовых не было, но это ожидаемо.

JIT-доступ в реальной эксплуатации

Здесь самое интересное - реакция пользователей. Администраторы в банке привыкли работать с постоянными привилегиями. JIT-модель требует явно запрашивать доступ перед каждой сессией, ждать подтверждения (если настроен approval workflow) и знать, что через N минут доступ закроется.

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

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

Через месяц количество инцидентов упало до приемлемого уровня. К декабрю PAM работает в штатном режиме, JIT-доступ на критичных системах - норма, не исключение.

Что оказалось сложнее, чем мы думали

Если коротко: не техника, а периметр. Технические проблемы - репликация AD, объём хранилища, keystroke log для бинарных протоколов - решаемы, просто требуют времени. Сложнее оказались две вещи.

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

Согласование approval workflow. Кто должен одобрять запросы на JIT-доступ? Звучит просто, но за этим вопросом стоят полтора месяца согласований внутри банка: ИБ говорит одно, служба ИТ - другое, бизнес-подразделения - третье. В итоге пришли к матрице: для каждого класса систем свой маршрут одобрения, с временными окнами, когда действует упрощённый режим. Документ на шесть страниц. Без него PAM технически работал бы, но организационно - нет.

Продукт в целом справился с задачей. Отечественный PAM с JIT - это больше не история «нам объяснили, как это должно работать, но оно не работает». Но это и не история «поставил и забыл». Глубина проработки интеграций у лидирующих российских продуктов достаточная для реального внедрения, хотя узкие места ещё есть. А вот про Zero Trust в части сетевого доступа мы писали отдельно - PAM хорошо дополняет эту историю, но не заменяет её.