Контроль привилегированных пользователей: запись сессий, временные права и PAM без дорогого продукта

Привилегированный пользователь — это человек, который может сделать с системой всё: прочитать любые данные, поменять любую настройку, стереть любой журнал. Доверие к нему необходимо, но доверие без контроля — хрупкая вещь: если его учётную запись украдут, злоумышленник получит те же возможности и оставит ровно столько следов, сколько захочет. Системы класса PAM (Privileged Access Management) решают три задачи: ограничивают доступ к привилегиям, выдают их только на время и записывают всё, что происходит. Коммерческие продукты дороги, но базовую часть можно собрать из открытых компонентов. Ниже рабочая схема для Linux и Windows, расчёт охвата и порядок разбора записей.

Предварительно настройте минимальные права sudo: sudo и sudoers. Отдельные учётные записи администраторов: уровни администрирования. Доступ третьих лиц: изолированный шлюз.

Что должна делать система контроля

Шаг 1. Запись команд sudo с выводом

Sudo умеет записывать не только факт запуска, но и всё, что видел и вводил пользователь в сессии. Включается в отдельном файле в sudoers.d:

# /etc/sudoers.d/10-iolog (править через visudo -f)
Defaults log_input, log_output
Defaults iolog_dir=/var/log/sudo-io
Defaults!/usr/bin/sudoreplay !log_output
Defaults use_pty

sudo visudo -c
sudo -i                                 # откройте оболочку root и выполните пару команд, затем выйдите
sudo sudoreplay -l | tail -n 5          # список записанных сессий
sudo sudoreplay -d /var/log/sudo-io СЕССИЯ_ИЗ_СПИСКА

Ожидаемо: в списке появляется сессия с пользователем, временем и командой; sudoreplay воспроизводит её как запись терминала. Записи хранятся в /var/log/sudo-io: каталог доступен только root, но администратор, владеющий root, может их удалить. Поэтому важна отправка копий на отдельный сервер: сбор логов, а размер каталога следует ограничить ротацией. Предупреждение пользователей о записи оформляется в правилах и политике (баннер при входе): запись без уведомления создаёт юридические риски.

Шаг 2. Запись терминальных сессий (SSH)

Sudo пишет то, что выполнено через него, но администратор работает и в обычном SSH-сеансе. Для записи любых терминальных сессий в Linux используют tlog: он подменяет оболочку и пишет сессию в журнал, откуда её можно воспроизвести. Пример для узла RHEL-семейства:

sudo dnf install -y tlog
sudo usermod -s /usr/bin/tlog-rec-session adm1       # оболочка пользователя заменяется на запись
sudo journalctl -o json-pretty -u sshd | head

После входа пользователя adm1 по SSH его сессия попадает в журнал systemd с меткой записи. Воспроизведение: sudo tlog-play -r journal -M TLOG_REC=ИДЕНТИФИКАТОР. Параметры и формат зависят от версии, поэтому сверьтесь с документацией вашего дистрибутива и сначала проверьте на тестовой учётной записи. При использовании каталога FreeIPA запись включается централизованно через SSSD (session_recording) для групп пользователей. Риск: подмена оболочки ломает вход, если tlog-rec-session не установлен или заблокирован политикой, поэтому держите открытой вторую сессию.

Шаг 3. Временное повышение прав

Постоянные административные права — самая большая слабость. Если права нужны на два часа, выдавайте их на два часа. Простой механизм на сервере без каталога: группа sudo-temp с правилом sudo и скрипт, который добавляет пользователя и сам же отзывает права.

#!/usr/bin/env bash
# /usr/local/sbin/grant-admin.sh ПОЛЬЗОВАТЕЛЬ ЧАСОВ ЗАЯВКА
set -euo pipefail
user="$1"; hours="$2"; ticket="$3"
getent passwd "$user" >/dev/null || { echo "нет такого пользователя" >&2; exit 1; }

usermod -aG sudo-temp "$user"
echo "gpasswd -d $user sudo-temp; logger -t grant-admin 'снято: $user, заявка $ticket'" | at now + "$hours" hours
logger -t grant-admin "выдано: $user на $hours ч, заявка $ticket, выдал ${SUDO_USER:-root}"
echo "Права выданы пользователю $user на $hours ч"

# /etc/sudoers.d/20-temp-admin
%sudo-temp ALL=(ALL) ALL

Ожидаемо: пользователь получает права, в журнале запись о выдаче и номер заявки; по истечении срока запускается отзыв, и в журнале появляется вторая запись. Номер заявки — обязательный параметр, он связывает повышение прав с согласованием. Для Windows аналогично используются временные членства в группах (в версиях Windows Server с поддержкой привилегированного доступа на время) или скрипт, добавляющий и снимающий участника по расписанию. Не забывайте проверять, что отзыв действительно сработал: раз в неделю выгружайте членов группы sudo-temp, она должна быть пустой.

Шаг 4. Журнал действий администраторов в Windows

Полноценной записи экрана без отдельного средства в Windows нет, но две групповые политики дают контроль над действиями в PowerShell и командной строке: журналирование блоков сценариев и запись транскриптов. Путь: Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell.

• Turn on PowerShell Script Block Logging: события 4104 в журнале Microsoft-Windows-PowerShell/Operational содержат текст выполненных сценариев.
• Turn on PowerShell Transcription с указанием каталога на сервере (OutputDirectory): каждая сессия записывается в текстовый файл с вводом и выводом. Каталог должен быть доступен на запись всем, а на чтение — только ИБ.
• Включите аудит создания процессов с командной строкой (событие 4688): Audit Process Creation и параметр «Include command line in process creation events».

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-PowerShell/Operational'; Id=4104} -MaxEvents 3 |
  Select-Object TimeCreated, @{n='Сценарий';e={$_.Message.Substring(0, [Math]::Min(120, $_.Message.Length))}}

Ожидаемо: последние записанные блоки сценариев. Для RDP-сессий используйте шлюз с записью экрана: Guacamole. Все эти события отправляйте в SIEM: аномалии доступа в Wazuh.

Шаг 5. Сейф для общих секретов

Некоторые учётные записи нельзя сделать именными: root на устройствах, служебные пароли, аварийные записи. Их хранят в сейфе с политикой доступа: кто может прочитать, как долго, и с обязательной сменой после использования. Принцип «выдать на время, затем сменить» можно реализовать в Vault: Vault: хранение секретов и политики доступа. Для небольших сред допустим парольный менеджер с журналом доступа, где у каждого секрета есть владелец. Главное правило: секрет, который кто-то видел, считается скомпрометированным и меняется.

Охват: все ли критичные системы под контролем

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

ansible all -b -m shell -a "grep -l 'log_output' /etc/sudoers /etc/sudoers.d/* 2>/dev/null | wc -l" -o
ansible all -b -m shell -a "getent group sudo-temp | cut -d: -f4" -o

Ожидаемо: у каждого узла первое значение больше нуля (запись включена), а второе — пусто (нет забытых временных прав). Узлы, не прошедшие проверку, заносятся в список к исправлению. Охват = число узлов с включённым контролем к числу узлов в реестре активов. Для узлов, где запись невозможна (устройства, закрытые системы), оформляйте исключение и применяйте компенсирующие меры: шлюз и запись на нём.

Выборочный просмотр записей

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

1. Раз в месяц ИБ выбирает несколько сессий (например, 5–10% или три на каждого администратора) и смотрит их.
2. Особое внимание: сессии вне рабочего времени, на критичных системах, с командами управления учётными записями и логами.
3. Результат записывается: дата, кто смотрел, какая сессия, замечания. Замечания разбираются с администратором.
4. Если администратор и проверяющий — один человек, записи просматривает руководитель или другой сотрудник.

Записи содержат всё, что показывал экран: пароли, персональные данные. Храните их в каталоге с ограниченным доступом, сократите срок хранения до необходимого (обычно 6–12 месяцев) и включите в перечень систем обработки персональных данных, если они там оказываются.

Какие артефакты хранить

Диагностика

Где это в модели зрелости

Материал относится к направлению «Управление доступом» (хаб: управление доступом, карта: карта зрелости). На третьем уровне внедрена автоматизированная система контроля привилегированных пользователей, которая журналирует действия, ограничивает доступ к учётным данным и командам для критичных систем, с полным покрытием критичных систем; на четвёртом покрытие распространяется на все серверы. Набор из открытых компонентов закрывает базовые требования; при росте и усложнении стоит оценить готовый продукт.

Как проверить

1. Сессия тестового администратора на сервере записана и воспроизводится (sudoreplay или tlog-play).
2. Выданные временные права снимаются сами по истечении срока, в журнале обе записи.
3. Скрипт охвата показывает полное покрытие критичных систем.
4. Журналы PowerShell на тестовом Windows-сервере содержат тестовую команду.
5. Есть протокол выборочного просмотра записей за последний месяц.

Источники

• sudo, журналирование ввода и вывода: sudo.ws.
• tlog, запись терминальных сессий: github.com/Scribery/tlog.
• Microsoft Learn, журналирование Windows PowerShell: learn.microsoft.com.
• CIS Control 5, управление учётными записями, и Control 6, управление контролем доступа: cisecurity.org/controls.