Контроль привилегированных пользователей: как исключить нарушение регламентов доступа

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

Что происходит на практике:

• доступы выдаются «временно», но остаются навсегда
• действия администраторов не контролируются в моменте
• аудит происходит постфактум (когда инцидент уже случился)
• регламенты есть, но в реальности не работают

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

Современный PAM — это не просто менеджер паролей. Обычно речь идёт о комплексе компонентов, которые работают вместе:

• управление политиками доступа и разрешениями
• журнал событий для аудита всех действий
• консоль администратора и консоль пользователя
• модуль AAPM для предоставления учётных записей в скрипты и приложения
• медиахранилище для видеозаписей, скриншотов и файлов

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

Что должно получиться в итоге внедрения

При внедрении PAM-решения важно решить сразу несколько задач:

• исключить ситуацию, когда «временные» доступы остаются навсегда
• начать контролировать действия администраторов в моменте, а не постфактум
• перевести контроль привилегий из формальной плоскости в техническую
• обеспечить соответствие требованиям регуляторов
• сохранить управляемость инфраструктуры при работе с подрядчиками

Именно эти задачи формируют основу любого проекта по управлению привилегированными доступами.

Центральным элементом системы является сервер управления PAM. Он управляет логикой работы и отвечает за взаимодействие между различными компонентами.

Что входит в сервер управления:

• политики доступа и разрешения — объединяют сотрудника, целевой ресурс и привилегированную учётную запись в единое разрешение
• журнал событий — отображает все происходящие события
• консоль администратора и консоль пользователя — два веб-приложения для настройки и для работы

Для хранения данных используются сертифицированные базы данных. В базе хранится информация о логинах и паролях от привилегированных учётных записей, а также текстовые логи сессий. Вся хранимая информация шифруется с использованием алгоритма AES-256.

Медиахранилище — выделенное сетевое хранилище для долгосрочного хранения видеозаписей, скриншотов и передаваемых в сессиях файлов.

Сервер доступа — через него проходит основной трафик с рабочего места сотрудника до целевого ресурса. Он поддерживает различные типы подключений:

• RDP до Windows-ресурсов
• SSH до Unix, Linux и сетевого оборудования
• доступ к опубликованным веб- или десктоп-приложениям
• подключения к базам данных (Microsoft SQL, PostgreSQL)

Важно: существуют собственные сервера доступа на базе Linux, которые не требуют дополнительных лицензий. Их можно развернуть на любом Linux, включая сертифицированные дистрибутивы (Astra Linux, Redos), и использовать все представленные протоколы.

Варианты развёртывания

Систему можно разворачивать на двух типах дистрибутивов — Windows или Linux.
При развёртывании на Linux (с использованием Docker-контейнеров) пользователям доступны:

• работа с опубликованными веб-приложениями в веб-браузере
• RDP- или XRDP-подключения до Windows или Linux-машин
• SSH до Unix, Linux и сетевого оборудования
• подключения к базам данных Microsoft SQL и PostgreSQL без публикации приложений (через SQL Proxy)

Если требуется работа с толстыми или тонкими клиентами, в схему добавляется сервер Windows с ролью RDS.

Пользователь со своего рабочего места подключается к консоли пользователя и производит аутентификацию.

Аутентификация может происходить несколькими способами:

• стандартный встроенный второй фактор — TOTP (регистрация при первом входе)
• интеграция по RADIUS (Push, Telegram, SMS)
• аутентификация по X.509 сертификатам
• интеграция со сторонними Identity-провайдерами по OpenID Connect

После успешной аутентификации:
1. Пользователь видит перечень доступных ему разрешений
2. Выбирает нужное и скачивает RDP-файл (или копирует команду для SSH/SQL)
3. Запускает сессию до сервера доступа
4. На сервере доступа происходит проверка разрешений
5. Открывается сессия до целевого ресурса

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

Консоль администратора: управление доступом и политиками

В консоли администратора доступен дашборд с информацией:

• количество активных сессий
• состояние серверов
• количество сессий за определённое время
• информация об учётных записях (с ошибками, без ротации паролей)
• информация об используемой лицензии

Управление пользователями.

Администратор может видеть пользователей из стороннего каталога (Active Directory) и из внутреннего каталога PAM. Внутренние учётные записи удобны для подрядных сотрудников — они создаются с ограниченным сроком службы, не требуют создания записей в основном каталоге.

Управление ресурсами.

Ресурсы можно добавлять из домена, вручную, при помощи CSV-файла или консольной утилиты. Их можно объединять в группы и подразделения, назначая права конкретному администратору на каждый контейнер.

Управление привилегированными учётными записями.

После добавления ресурса к нему прикрепляется привилегированная учётная запись (доменная или локальная). Настраивается сервисное подключение для поиска учётных записей на ресурсе, работы с паролями (сброс, проверка) и получения групп безопасности.

Поддерживаются коннекторы к ресурсам:

Windows, Unix-дистрибутивы, Cisco IOS, Inspur BMC. Для других систем предусмотрен функционал произвольного типа сервисного подключения — его можно написать по инструкции или с помощью техподдержки.

Разрешение — это связка: кому → к какому ресурсу → от имени какой учётной записи.

При создании разрешения администратор может настроить:

• ограничение времени действия (например, до конца месяца)
• расписание доступа (только рабочие часы, конкретные дни)
• возможность просмотра или изменения учётных данных пользователем
• разрешённые источники подключения (IP-адреса, группы адресов, маски сети)
• безопасное повышение привилегий в SSH-сессиях (команда PAMSU)

Важно: если разрешённые источники не указаны, пользователь увидит разрешение в своей консоли, но подключиться не сможет.

RDP-подключение

Пользователь открывает сессию через веб-терминал. Сессия открывается от имени доменной учётной записи администратора — пользователь не вводит никаких данных.

Глазами администратора: в консоли администратора в разделе «Активные сессии» видна сессия.

Доступны:

• просмотр в реальном времени (стрим)
• снимки экрана (минимальный интервал — 1 минута)
• текстовый лог (активные окна, запускаемые процессы, клавиатурный ввод) — требуется агент на целевом ресурсе

Администратор может прервать сессию в любой момент.

SSH-подключение

Поддерживаются несколько вариантов: копирование команды для любого клиента (PuTTY, MOBA, XTERM) или веб-терминал.

Дополнительные возможности, настраиваемые политиками:

• требование указать причину для подключения
• открытие сессии только после подтверждения администратором (запрос появляется в консоли, можно настроить уведомления на почту)
• чёрный и белый список команд (реакция: сброс команды или сброс с завершением сессии)
• безопасное повышение привилегий через команду PAMSU (с вводом пароля и второго фактора)
• передача данных по SCP или SFTP с настройкой направлений

Подключение к базам данных

• Для Microsoft SQL и PostgreSQL поддерживаются:
• строки подключения для использования в любом клиенте
• команда для прямого подключения из консоли
• полноценный клиент (например, через PGAdmin)

На данный момент доступен текстовый лог отправляемых команд в сторону БД.

Пользовательские веб- и десктоп-приложения

Два варианта работы:
1. На базе Linux — подключение к тонким клиентам или веб-браузеру. Реализована аутентификация через SSO-агент: пользователь аутентифицируется от своей учётной записи, даже при попытке выйти агент возвращает сессию.
2. На базе Windows RDS — работа с толстыми клиентами через технологию Remote Application. Поддерживаются видеологирование и снимки экрана.

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

Что настраивается в политиках:

• необходимость указания причины подключения
• подтверждение администратором перед открытием сессии
• виды логирования (стрим, снимки, текстовый лог)
• отправка событий по Syslog в форматах CEF и LEEF (можно фильтровать по ключевым словам)
• включение/отключение команды PAMSU
• чёрный и белый список команд с выбором реакции
• передача данных по SCP/SFTP

В системе предусмотрено два вида лицензирования:

1. по пользователям — ограниченное количество пользователей открывает неограниченное количество одновременных сессий
2. по одновременным сессиям — неограниченное количество пользователей открывает ограниченное количество конкурентных сессий

Минимальный порог — 5 (либо от 5 пользователей, либо от 5 сессий). Лицензии нельзя совмещать — в рамках системы используется только один тип.

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

Ротация паролей может происходить:

• по расписанию (раз в определённое количество дней/месяцев)
• по завершению сессии (даже если пользователь изменил пароль на ресурсе, после сессии он становится неактуальным)
• администратором вручную

Просмотр пароля возможен, если администратор включил эту опцию.

При этом:

• все действия фиксируются в журнале
• можно настроить запрос на подтверждение перед просмотром
• после просмотра можно настроить автоматическую ротацию пароля

Можно ли публиковать веб-интерфейс PAM без VPN?

Да, такой вариант возможен — часть компонентов выносится в DMZ. Но рекомендуется использовать VPN: пользователь подключается через VPN в DMZ-контур, где у него есть доступ только к консоли PAM, а уже через PAM — к целевым ресурсам.

Можно ли ограничить буфер обмена?

Ограничить можно, но сделать его однонаправленным пока нельзя (кроме SSH-подключений). Для RDP этот функционал в разработке.

Можно ли использовать бесплатные TOTP-приложения?

Да, Яндекс. Ключ, Google Authenticator и другие подходят. При первом входе пользователю показывается QR-код для сканирования.

Можно ли задать конкретного согласующего для группы хостов?

Да, при помощи подразделений. Ресурсы выделяются в отдельный контейнер, и администратору через роли ограничивается доступ только к этому подразделению.

Поддерживаются ли SSH-ключи формата ED25519?

Да, поддерживаются.

Выдача прав на основании групп Active Directory возможна?

Да, система маппится с группами в каталоге. При добавлении пользователя в группу в AD разрешение появляется автоматически, при удалении — отзывается.

Можно ли включить OTP для всех сотрудников?

Да, администратор может включить второй фактор глобально для всех, отключить глобально или настроить точечно.

Внедрение PAM — это не просто установка менеджера паролей и не замена одного инструмента на другой.

Это:

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

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