JIT-доступ через отечественный PAM: минус 80% постоянных привилегий и список систем вне охвата

Несколько отечественных PAM-вендоров за последние месяцы добавили JIT (just-in-time) доступ в свои продукты - кто как штатный модуль, кто как beta-функцию. На фоне того, что методрекомендации ФСТЭК по КИИ теперь явно требуют контроль привилегированного доступа, тема PAM у заказчиков резко потеплела. Мы как раз завершили внедрение у одного из них - есть что рассказать.

Что было до

Типичная картина на старте: Linux-серверы с постоянными sudo-группами, где состав участников никто не ревьювил последние полтора года. Windows-среда с несколькими «временными» учётками с правами локального администратора, которые прижились на пять лет. База данных Oracle с полудюжиной учёток уровня DBA, выданных для разных проектов - проекты завершены, учётки живут.

Мы это увидели на аудите - стандартная аудиторская находка, ничего экзотического. Но заказчик первый раз видел это в виде сводной картины, и цифра постоянно открытых привилегированных доступов неприятно удивила.

Почему JIT, а не просто PAM

PAM без JIT - это по сути записная книжка паролей с видеозаписью сессий. Пароль к root-аккаунту лежит в хранилище, оператор его запрашивает, получает, работает. Хранилище знает, кто запросил и когда. Это лучше, чем ничего, но постоянная привилегия никуда не делась - она просто стала чуть сложнее в получении.

JIT меняет модель: привилегия не существует в постоянном виде. Оператор подаёт заявку, указывает задачу и окно времени. PAM создаёт временную учётку или временно добавляет в группу - на час, на два, на рабочую смену. По истечении окна привилегия автоматически отзывается. Если оператор не успел - подаёт повторную заявку.

Это уже не просто логирование, это изменение поверхности атаки. Украденные долгоживущие креды теряют ценность, если привилегия действует четыре часа.

Как мы это собрали

Заказчик выбрал один из отечественных PAM-продуктов с модулем JIT - называть не будем, это не обзор вендора. Архитектура получилась трёхслойная.

[Оператор]
    |
    v
[PAM-портал] --> [Заявка + согласование (опционально)]
    |
    v
[JIT-движок] --> создаёт временный доступ на целевой системе
    |
[Audit log + запись сессии]

Первый слой - портал заявок. Оператор выбирает целевую систему из каталога, указывает причину, выбирает шаблон доступа (читай - набор прав). Для критичных систем - автоматическая маршрутизация на согласование руководителю или дежурному офицеру ИБ. Для плановых регламентных операций - преавторизованные шаблоны без ожидания.

Второй слой - JIT-движок. После одобрения заявки движок идёт на целевую систему и создаёт временный доступ. Реализация зависит от целевой платформы - и здесь начинается самое интересное.

Третий слой - запись сессии. Всё, что делает оператор, пишется. Не только факт входа - именно действия в сессии. На Linux это перехват PTY через SSH-прокси, на Windows - запись RDP-сессии.

Как это выглядит по целевым системам

Linux. Работает хорошо. PAM создаёт временного пользователя с нужными sudo-правами, добавляет SSH-ключ на время сессии, по истечении - удаляет пользователя и ключ. Интеграция через Ansible-плейбуки, которые PAM вызывает по API. Overhead на создание пользователя - секунды.

Windows (domain-joined). Работает, но требует аккуратной настройки. JIT-движок работает через AD - временно добавляет аккаунт в нужную локальную или доменную группу. Проблема, с которой мы столкнулись: групповые политики иногда применяются с задержкой, и оператор может войти в систему до того, как права фактически применились. Решается настройкой немедленного gpupdate после изменения членства - не элегантно, но работает.

PostgreSQL и другие СУБД. Временный пользователь с нужными ролями создаётся в базе, после окончания - DROP USER. Всё хорошо, пока база это поддерживает. С Oracle Enterprise потребовалась кастомная интеграция через API PAM - штатный коннектор у этого вендора не поддерживал Oracle нужной нам версии.

Что осталось за бортом

Честный список того, что JIT через этот PAM не закрывает:

• Сетевое оборудование (Cisco, H3C, отечественные вендоры). Коннекторов нет или они в состоянии «beta, не для продакшна». Управление по SSH с привилегированными учётками осталось за пределами JIT. Логирование через TACACS+ есть, но это не JIT.

• SCADA и промышленные контроллеры. Здесь PAM физически не может создавать временных пользователей - модель доступа у большинства таких систем не предполагает API-управления учётками. Компенсирующая мера - бастион-хост перед сегментом АСУ ТП с записью сессий.

• Сервисные учётки приложений. JIT хорошо работает для интерактивного доступа людей. Машина-к-машине - отдельная история. Ротация сервисных паролей через PAM-хранилище есть, но это не JIT, это другой механизм.

• Локальные учётки на хостах вне домена. Несколько серверов у заказчика работают в изолированных сегментах без возможности достучаться до PAM-сервера. Для них сделали отдельный lightweight-агент с локальным кешем заявок - решение нишевое и требует поддержки.

Итого по цифрам

После внедрения количество постоянно существующих привилегированных учёток на целевых системах, покрытых PAM, сократилось примерно на 80%. Оставшиеся 20% - это как раз системы из списка выше плюс несколько legacy-приложений, которые не умеют работать без локального суперпользователя.

80% - хорошая цифра, но важно понимать: 20% зачастую самые неудобные. Сетевое оборудование, SCADA, legacy - именно там, куда атакующий особенно хотел бы попасть.

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

Если хотите разобраться, какой охват JIT реально достижим в вашей инфраструктуре - это хорошо укладывается в рамки предварительного аудита.