PAM для enterprise: контроль привилегированного доступа, запись сессий и аудит

Содержание

Что такое PAM и почему пароля администратора недостаточно
Чем PAM отличается от IAM и SSO
Кого контролирует PAM: администраторы и подрядчики
Ключевые возможности PAM
Just-in-Time доступ: сокращение поверхности атаки
Запись и аудит сессий: что и сколько хранить
Архитектура PAM-решения
Импортозамещение: отечественные PAM-решения
Интеграция PAM в Java-контур
Внедрение: этапы и риски
FAQ

Вопрос из корпоративного чата сисадминов звучит обыденно: «чем опасен пользователь домена с правами локального администратора на своей машине? Я не вижу проблемы». Ответ в том же треде ставит всё на места — в одной конторе развернули PAM, и софт перехватывал каждый запрос UAC, требующий админских прав, отправляя в поддержку push с полной информацией о том, что пользователь пытается сделать. «Это открывало глаза на то, что пользователи обычно делали с локальным администратором». Привилегированный доступ опасен не потому, что им обязательно злоупотребляют, а потому, что без контроля вы просто не знаете, что за ним происходит.

Эта статья — практический разбор PAM (Privileged Access Management): что это за класс решений, чем он отличается от привычного IAM и SSO, какие возможности действительно нужны enterprise, как устроены запись и аудит сессий, что требует регулятор и как встроить PAM в корпоративный контур на Java/Kotlin — стек, с которым мы в Новакоме работаем чаще всего.

Что такое PAM и почему пароля администратора недостаточно

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

PAM — это подмножество IAM, ориентированное на контроль учётных записей с повышенными привилегиями — тех, что имеют право вносить изменения в устройства и приложения. Цель PAM — реализовать принцип наименьших привилегий (least privilege): доступ выдаётся ровно под конкретную задачу и ровно на то время, что она занимает.

Почему обычной аутентификации недостаточно? Возьмём типичную привилегированную учётную запись. В неделе 168 часов, и формально учётка с правами действует все 24/7. Но за неделю она реально используется, бывает, единицы минут для продуктивной работы — всё остальное время это просто открытая дверь с постоянным паролем, лежащим где-то в голове администратора или в текстовом файле. Именно желание, во-первых, отделить управление привилегированными учётными записями от управления всеми остальными и, во-вторых, управлять доступом во времени — и породило отдельный класс решений PAM.

Добавьте сюда историю про Intel AMT, где «сложный» дефолтный пароль к расширению BIOS оказался строкой admin, и достаточно нажать Ctrl+P при загрузке, чтобы получить админский доступ. Привилегированные точки входа есть везде, и пароль сам по себе их не защищает.

Чем PAM отличается от IAM и SSO

Понятия IAM, SSO и PAM тесно связаны, но не совпадают. Проще всего развести их по объекту контроля.

IAM (Identity and Access Management) следит за рабочими учётными записями — массой обычных сотрудников. Его задача — чтобы у каждого была надёжная цифровая идентификация и корректный набор прав, как правило на основе ролей (RBAC), а доступ к службе каталогов шёл по LDAP поверх Active Directory, FreeIPA или их аналогов.

SSO — это единая точка входа поверх IAM: пользователь логинится один раз и переходит между приложениями без повторного ввода пароля. Мы подробно разбирали, как это строится на Keycloak + Spring Boot и на Apereo CAS с MFA.

PAM же следит не за всеми, а за немногими — теми, у кого повышенные права, — и делает то, чего IAM/SSO не делают в принципе: брокерит доступ к целевым ресурсам, прячет от человека сам пароль привилегированной учётки, записывает каждое действие в сессии и даёт ИБ возможность одобрять или прерывать подключение в реальном времени.

Критерий	IAM / SSO	PAM
Объект контроля	Все рабочие учётные записи	Привилегированные учётные записи и сессии
Главная задача	Аутентификация, единый вход, роли	Принцип наименьших привилегий, контроль действий
Пароль целевого ресурса	Знает пользователь	Хранится в PAM, человек его не видит
Время доступа	Постоянное (учётка активна 24/7)	Just-in-Time, выдаётся под задачу
Запись действий	События входа (кто и когда вошёл)	Полная запись сессии: команды, видео, файлы
Типовой вопрос	«Кто имеет доступ?»	«Что именно он сделал на сервере?»

Ключевая мысль: PAM не заменяет IAM, а надстраивается над ним. Аутентификация и жизненный цикл рабочих учётных записей остаются на стороне IAM, а PAM берёт на себя брокеринг привилегированных сессий и контроль действий внутри них.

Кого контролирует PAM: администраторы и подрядчики

На практике выделяются два класса пользователей, ради которых внедряют PAM.

Первый — собственные системные администраторы. Люди, которые владеют инфраструктурой и в силу своих повышенных прав требуют повышенного контроля. Здесь работает не презумпция вины, а гигиена: если администратор что-то сделал на конечном ресурсе, PAM это зафиксирует — пишутся логи, пишутся все его действия. Это защита и компании (от ошибки или инсайдера), и самого администратора (доказуемость того, что инцидент произошёл не по его вине).

Второй — внешние подрядчики. Те, кто, как правило, удалённо выполняет работу в вашей инфраструктуре, нередко на её критичных компонентах. Удалённый доступ внешнего исполнителя к продуктивным системам — один из самых частых векторов компрометации, и без PAM вы выдаёте подрядчику постоянный пароль и надеетесь на лучшее.

Отдельный режим, важный именно для подрядчиков, — «четыре глаза»: PAM позволяет подключить администратора безопасности, который, во-первых, одобряет адресованные ему заявки на доступ, а во-вторых, в реальном времени контролирует действия внешнего администратора внутри сессии и может прервать её. Заявку на подключение при этом удобно увязывать с соответствующим тикетом на работы — доступ открывается под конкретную задачу, а не «вообще».

В корпоративной практике это перекликается с темой, которую регулярно поднимают на ИБ-вебинарах: при смене подрядчика или передаче администрирования нужно либо менять администратора, либо заключать формальное соглашение об администрировании. PAM делает такое соглашение технически исполнимым и проверяемым.

Ключевые возможности PAM

Класс PAM объединяет несколько подсистем, у каждой своё назначение.

Хранилище секретов (Password Vault / PASM). Управление паролями и их жизненным циклом для привилегированных учётных записей: пароли хранятся в зашифрованном виде, человек их не видит, подключение к ресурсу подставляет учётные данные за него. Сюда же — управление API-ключами и паролями приложений и скриптов.
Поиск и взятие под контроль. PAM умеет инвентаризировать ресурс и находить неучтённые локальные учётные записи, забирая их под свой контроль. Добавили Windows-ресурс через соответствующий коннектор, проверили соединение, выполнили поиск — и обнаруженные локальные учётки становятся управляемыми.
Ротация паролей. После каждой сессии (или по расписанию) пароль привилегированной учётки автоматически меняется. Важная деталь архитектуры: у самого администратора не должно быть прав на смену пароля целевой учётки в обход PAM — иначе ломается вся модель. PAM управляет паролями, администратор работает на ресурсе, но не управляет паролями.
Брокер сессий (PSM — Privileged Session Management). Контроль привилегированных RDP/SSH-сессий: PAM встаёт посредником между администратором и целевым сервером. Пользователь не получает прямого сетевого доступа и не знает пароля — он работает через брокер.
Запись действий. Логи команд, видео/скриншоты сессии, перехват передаваемых файлов. Всё, что администратор делал на конечном ресурсе, видно и воспроизводимо.
Управление привилегиями приложений (PEDM) и супервизорскими учётками — отдельные подклассы для контроля прав приложений и суперпользователей.
Гибкая ролевая модель и поведенческий анализ. Администраторов внутри самого PAM имеет смысл разделить по ролям: один выдаёт разрешения, другой только просматривает сессии. Система настраивается политиками и ролями под конкретную инфраструктуру, а накопленные записи сессий служат базой для поведенческого анализа (выявление аномалий в действиях привилегированных пользователей).

Just-in-Time доступ: сокращение поверхности атаки

Главная идея, отличающая зрелый PAM от простого хранилища паролей, — управление доступом во времени. Вместо постоянно активной привилегированной учётки доступ выдаётся точечно: администратор оформляет заявку (в идеале привязанную к тикету), она проходит проверку подлинности через двух- или многофакторную аутентификацию и одобрение, после чего доступ открывается на ограниченное окно и закрывается по его истечении.

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

Та же логика лежит в основе сценария с перехватом UAC из чата сисадминов: запрос на повышение прав не выдаётся автоматически, а уходит на одобрение с полным контекстом. Обратная сторона — масштаб: когда у вас тысячи конечных точек, ручное одобрение каждого запроса физически невозможно. Поэтому Just-in-Time в enterprise строится не на ручном клике дежурного, а на политиках: автоматическое одобрение для рутинных низкорисковых операций, ручное и режим «четыре глаза» — для критичных ресурсов и внешних подрядчиков.

Запись и аудит сессий: что и сколько хранить

Запись сессий — то, ради чего PAM нередко и покупают. Она закрывает два вопроса службы ИБ: «что именно сделали на сервере» постфактум и «что делают прямо сейчас» в реальном времени.

Что обычно пишется:

Метаданные сессии — кто, когда, к какому ресурсу, по какому тикету, через какую учётную запись.
Команды и текстовый поток для SSH — полный лог введённых команд и вывода, по которому сессию можно искать и индексировать.
Видео/скриншоты экрана для графических RDP-сессий — визуальная запись действий.
Переданные файлы — что было загружено на сервер или скачано с него.

Важный архитектурный момент: запись должна быть невозможна к подделке или удалению самим администратором — иначе аудит бессмысленен. Поэтому хранилище записей выносится из-под контроля тех, чьи действия оно фиксирует.

Сроки хранения. Для значимых объектов записи сессий и журналы привилегированного доступа обычно хранят от 1 до 2 лет — конкретный срок задаётся внутренней политикой ИБ и применимыми требованиями (приказы ФСТЭК по защите информации, отраслевые стандарты, требования регулятора для КИИ и финсектора). Это сразу ставит инженерный вопрос объёма: видеозапись RDP-сессий по тысячам подключений — это терабайты, которые надо где-то держать, индексировать и быстро поднимать при расследовании. Поэтому хранение записей обычно проектируют как отдельную подсистему с дешёвым объёмным хранилищем, дедупликацией и понятным регламентом ретенции.

Регуляторное давление здесь только растёт: в корпоративных каналах отмечают, что при проверках уже просят предоставить список используемого ПО и смотрят даже на исполнение требований лицензий. Аудит привилегированного доступа — часть той же картины: важно не только хранить записи, но и уметь показать, что процесс контролируем.

Архитектура PAM-решения

Типовая архитектура современного PAM строится вокруг центрального сервера, который управляет логикой работы и взаимодействием модулей. Упрощённо компоненты такие:

PAM-сервер — ядро, отвечающее за оркестрацию.
Модуль политик и разрешений — связывает три сущности: сотрудника, целевой ресурс и привилегированную учётную запись в единое разрешение. Именно здесь описывается, кто, к чему и под какой учёткой может подключаться.
Хранилище секретов — зашифрованные пароли и ключи.
Брокер сессий с коннекторами под конкретные протоколы и платформы (Windows-коннектор для RDP, SSH-коннектор для Unix-систем).
Модуль записи и аудита с отдельным хранилищем.
Консоль администратора — для настройки системы, выдачи и ограничения доступа.
Консоль (портал) пользователя — рабочее место сотрудника, через которое он запрашивает и получает доступ к ресурсам.

Развёртывание у зрелых решений идёт из Docker-контейнеров, что позволяет ставить систему на любой Linux, в том числе на сертифицированные отечественные дистрибутивы (Astra Linux, РЕД ОС и аналоги). Контейнеризация здесь не модный атрибут, а требование к воспроизводимости и совместимости с импортозамещённой инфраструктурой.

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

Импортозамещение: отечественные PAM-решения

Для российского enterprise PAM — одна из тех областей, где импортозамещение идёт активно и осмысленно. Причина понятна: система контроля привилегированного доступа сама по себе обладает максимальными правами в инфраструктуре, и зависеть здесь от зарубежного вендора, который может отозвать лицензию или прекратить поддержку, — недопустимый риск.

На рынке есть отечественные PAM, разработанные в России с нуля, без иностранного кода в продукте, — что критично для объектов КИИ и госсектора, где происхождение ПО проверяется. Такие решения изначально проектируются под сертифицированные ОС, разворачиваются в закрытом контуре и не требуют обращения к внешним облакам.

PAM логично вписывается в общую стратегию импортозамещения ПО:

весь привилегированный доступ, записи сессий и секреты остаются внутри периметра под контролем организации;
второй фактор для входа в PAM можно строить на отечественных носителях (Рутокен MFA и аналоги);
нет привязки к зарубежному вендору как к единой точке отказа в критичном для безопасности компоненте.

Спрос подтверждается и кадровым рынком: крупные промышленные холдинги (вплоть до объединённых корпораций оборонного и авиастроительного профиля) открывают позиции руководителей проектов внедрения именно таких информационных систем — PAM регулярно входит в их периметр.

Интеграция PAM в Java-контур

Большинство enterprise-приложений на Java/Kotlin сталкиваются с PAM в двух точках: как потребители секретов и как источники событий для аудита.

Получение секретов вместо хардкода. Самый частый антипаттерн — пароль от БД или API-ключ в application.yml или переменной окружения, которые потом утекают в git и логи. PAM (или совместимый secret manager вроде HashiCorp Vault / отечественных аналогов) отдаёт секрет приложению по запросу, с коротким TTL и аудитом обращения. На стороне Spring Boot это выглядит как обращение к хранилищу при старте или, лучше, динамическое получение короткоживущих учётных данных:

@Component
class VaultSecretProvider(
    private val webClient: WebClient,
    @Value("\${pam.base-url}") private val baseUrl: String,
) {
    /**
     * Запрашивает короткоживущие учётные данные к целевому ресурсу.
     * Пароль не хранится в конфиге приложения и ротируется на стороне PAM.
     */
    fun leaseDbCredentials(role: String): DbCredentials =
        webClient.get()
            .uri("$baseUrl/v1/database/creds/$role")
            .header("X-Vault-Token", currentToken())
            .retrieve()
            .bodyToMono(DbCredentials::class.java)
            .block() ?: error("PAM: не удалось получить учётные данные для роли $role")
}

data class DbCredentials(
    val username: String,
    val password: String,
    val leaseDurationSeconds: Long,
)

Ключевой принцип: приложение получает учётные данные на время и не знает «вечного» пароля. Когда lease истекает, PAM отзывает учётку — даже если секрет утёк, окно его полезности минимально.

Сервисные доступы и CI/CD. Пайплайны, скрипты деплоя и фоновые джобы — это тоже привилегированный доступ. Их учётные данные (api-ключи, токены) выводятся в хранилище PAM, а не лежат в секретах CI открытым текстом бессрочно.

Аудит на стороне приложения. События доступа из приложения имеет смысл писать в том же формате и контуре, что и PAM-аудит, чтобы расследование было сквозным. Если часть сервисов работает на собственных сессиях, а часть — на токенах, полезно заранее определиться с моделью, как мы разбирали в материале про JWT против сессий в Spring Security.

Граница ответственности проста: инфраструктурный привилегированный доступ (вход администратора на сервер по RDP/SSH) закрывает сам PAM как брокер сессий, а доступ приложения к ресурсам — через выдачу короткоживущих секретов. Дублировать логику PAM внутри приложения не нужно.

Внедрение: этапы и риски

PAM — проект, который легко превратить в долгострой, если зайти сразу «накрыть всё колпаком». Рабочая последовательность другая.

Инвентаризация привилегий. Собрать список критичных ресурсов, привилегированных учётных записей (включая забытые локальные и сервисные) и того, кто ими сейчас пользуется. Часто именно здесь обнаруживаются неучтённые учётки и постоянные пароли подрядчиков.
Накрыть критичные активы первыми. Не пытаться охватить всю инфраструктуру разом — взять под контроль самые чувствительные ресурсы (домен-контроллеры, БД с ПДн, продакшен), завести их в PAM, подключить хранилище секретов и брокер сессий.
Включить запись и ротацию. Настроить запись сессий и автоматическую смену паролей после подключений. Убедиться, что у администраторов нет обходного пути смены пароля целевой учётки.
Перевести подрядчиков на PAM. Внешний доступ — приоритет: заявки по тикетам, режим «четыре глаза» для критичных работ, ограниченные окна доступа.
Настроить ретенцию и расследование. Определить срок хранения записей (1–2 года), объём хранилища, регламент доступа к записям и кто имеет право их смотреть.

Риски, которые стоит закрыть заранее:

PAM как единая точка отказа. Если брокер лежит, в инцидент никто не попадёт на серверы. Нужны кластеризация и регламентированная «break-glass»-процедура аварийного доступа.
Обход системы. Прямой сетевой доступ к целевым ресурсам в обход PAM должен быть закрыт на уровне сети — иначе администраторы продолжат ходить «как раньше», а PAM станет витриной.
Сопротивление администраторов. Контроль воспринимается как недоверие. Помогает честная коммуникация: запись защищает и самого администратора, снимая с него подозрения при разборе инцидентов.
Объём записей. Видео RDP по тысячам сессий — это терабайты. Хранилище и ретенцию надо проектировать заранее, а не упираться в диск через полгода.
Ручное одобрение не масштабируется. На тысячах конечных точек одобрять каждый запрос руками невозможно — нужны политики автоматического одобрения для рутинных операций.

PAM — это не разовая установка, а инфраструктурный слой контроля, который потом несёт на себе аудит, расследование инцидентов и Zero Trust. Поэтому его стоит внедрять руками команды, которая понимает и продакшен-эксплуатацию, и интеграцию с приложениями.

FAQ

Чем PAM отличается от обычного менеджера паролей? Менеджер паролей хранит секреты и отдаёт их человеку. PAM прячет пароль от человека вовсе: он брокерит подключение, подставляет учётные данные сам, записывает всю сессию и ротирует пароль после неё. Плюс управление доступом во времени (Just-in-Time) и контроль действий в реальном времени — чего у обычного менеджера паролей нет.

Нужен ли PAM, если уже есть SSO и MFA? Да. SSO/MFA отвечают на вопрос «кто вошёл», PAM — на вопрос «что именно он сделал на сервере и под какой привилегированной учёткой». Это разные слои: PAM надстраивается над IAM/SSO, а не заменяет их.

Сколько хранить записи сессий? Обычно от 1 до 2 лет — точный срок задают внутренняя политика ИБ и требования регулятора (ФСТЭК, отраслевые стандарты, требования для КИИ и финсектора). Закладывайте отдельное объёмное хранилище: видеозаписи RDP по множеству сессий быстро вырастают в терабайты.

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

Есть ли отечественные PAM для импортозамещения? Да, на рынке есть российские PAM, написанные с нуля без иностранного кода, разворачиваемые из контейнеров на сертифицированных ОС (Astra Linux, РЕД ОС). Для КИИ и госсектора это снимает риск отзыва лицензии зарубежным вендором и проверяемо по происхождению ПО.

Если вы планируете контроль привилегированного доступа в корпоративном контуре — от выбора и внедрения PAM до интеграции с приложениями на Java/Kotlin и выстраивания аудита — мы в Новакоме проектируем такие решения под конкретную инфраструктуру и требования регулятора. Посмотрите наши услуги по разработке на Spring и аутстаффингу Java-команд или напишите нам с описанием вашего контура и парка привилегированных учётных записей.