Контроль действий администраторов: SIEM, PAM или аудит

Что такое контроль действий администраторов простыми словами

Администратор - это не просто сотрудник с «доступом в систему». Это привилегированный пользователь: человек (или сервисная учетная запись), который может менять настройки, выдавать права, просматривать чувствительные данные, отключать защиту и удалять следы. Контроль действий администраторов нужен не из недоверия, а потому что цена ошибки или злоупотребления здесь самая высокая.

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

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

На практике процесс чаще всего ломается в четырех местах:

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

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

Какие требования обычно предъявляют регуляторы и внутренний аудит

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

Минимальные ожидания чаще всего такие:

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

Отдельный блок требований почти всегда связан с разделением полномочий. Тот, кто администрирует систему, не должен единолично назначать себе доступ и одновременно быть тем, кто «принимает работу» по журналам. Обычно разделяют роли: кто запрашивает доступ, кто утверждает, кто выдает, кто просматривает логи и кто проводит расследование.

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

Чтобы требования не стали сюрпризом на приемке, их лучше заранее согласовать коротким документом между ИБ, ИТ и комплаенсом:

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

Какие данные нужны для расследований и проверок

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

Важно заранее договориться, что вы считаете «следом». Проверки и расследования ищут ответы на простые вопросы: кто вошел, откуда, что именно поменял, и можно ли подтвердить, что действие выполнял конкретный человек.

Какие события почти всегда критичны

Почти всегда упираются в несколько групп событий:

• входы и неудачные попытки входа (включая RDP/SSH/консоли), смена паролей
• эскалация прав: добавление в админ-группы, выдача ролей, использование sudo/runas
• изменения политик и конфигураций: GPO, правила фаервола, маршруты, настройки гипервизора
• операции с учетками: создание, удаление, разблокировка, отключение MFA
• попытки «ослепить» контроль: отключение аудита, очистка журналов, остановка агентов

Лог события и доказательство действия - не одно и то же

Запись «успешный вход» показывает, что сессия началась. Но она не доказывает, что именно делали внутри. Для доказательности важны привязки по времени и идентификаторам (учетка, хост, источник), а иногда и запись сессии (команды, экран) или детальные журналы изменения конфигурации.

Если часть систем плохо логирует, не стоит пытаться «выжать» из них идеальную детализацию. Лучше выбрать компенсацию: включить максимально доступный аудит, добавить промежуточную точку контроля (например, админ-доступ только через jump-host) и обеспечить централизованное хранение логов с неизменяемостью и достаточным сроком хранения.

SIEM: плюсы и ограничения для контроля действий администраторов

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

Сильная сторона SIEM - расследования по времени и взаимосвязям. При подозрении на изменения прав, отключение журналов или вход не по регламенту SIEM помогает быстро собрать цепочку событий из разных источников: AD, серверов, сетевых устройств, приложений. Он удобен для отчетов регулятору и внутреннему аудиту, потому что дает единое хранилище, поиск и правила оповещений.

Обычно SIEM хорошо закрывает:

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

Ограничения начинаются там, где нужен «смысл действия». Например, интерактивная сессия по SSH или RDP: SIEM увидит вход, иногда запуск процесса, но не всегда увидит команды и фактические изменения в конфигурации. Еще одна слабая зона - контекст: почему действие выполнено, по какой заявке, с чьего разрешения. Без этого контроль превращается в поток сигналов, который трудно доказательно трактовать.

SIEM также зависит от качества источников. Если на части серверов не включен аудит, время на узлах расходится, а события не нормализованы (разные форматы, разные поля «пользователь»), расследование может дать ложные выводы.

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

PAM: где он незаменим и что может не покрыть

PAM (Privileged Access Management) нужен там, где важно не просто собирать логи, а управлять самим фактом выдачи привилегий. Он отвечает на практичный вопрос: кто получил доступ администратора, на какой срок, по какой причине и что делал во время сессии. Для контроля действий администраторов это часто самый проверяемый слой.

Что PAM закрывает лучше всего

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

PAM особенно полезен, когда:

• админы работают с критичными системами (AD, базы данных, виртуализация, сетевое оборудование)
• есть подрядчики и временные сотрудники, которым нужен доступ на ограниченное время
• нужен экстренный доступ (break-glass) с усиленным контролем и последующей проверкой
• нужно централизованно управлять привилегиями в разных сегментах

Пример: подрядчику дают доступ к серверу на 2 часа для обновления. Через PAM он получает временные учетные данные, сессия записывается, а после окна доступа права закрываются. Если потом приходит вопрос от аудитора или регулятора, вы показываете: кто запрашивал, кто согласовал, когда заходил и что делал.

Что PAM может не покрыть

PAM не отменяет организационные сложности. Внедрение затрагивает процессы и привычки админов: кто утверждает заявки, как оформлять экстренный доступ, что считать «критичной системой».

Есть и технические ограничения. Не все протоколы и старые системы одинаково хорошо поддерживают проксирование и запись, часть действий может уходить мимо PAM (локальные консоли, редкие интерфейсы управления, «теневые» учетные записи). Поэтому PAM почти всегда дополняют журналированием на системах и сбором событий в SIEM, чтобы картина расследования была полной.

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

Иногда контроль действий администраторов строят без PAM, опираясь на аудит ОС, сетевые точки контроля и хранение доказательств. Это может быть осознанный вариант, если нужно быстро закрыть конкретное требование или вы пока не готовы менять процесс доступа.

На практике чаще всего используют:

• бастион-хост с записью сессий (RDP/SSH) и командами
• расширенный аудит ОС и приложений (Windows/Linux), включая изменения прав, служб, реестра, планировщика
• EDR на серверах и рабочих местах администраторов для фиксации запуска инструментов, скриптов и подозрительных цепочек
• централизованное журналирование с долгим хранением
• WORM-хранилище (или режим неизменяемости), чтобы записи нельзя было тихо подправить

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

Риски у «аудита без PAM» заметные. Данные разъезжаются по разным местам: часть в логах ОС, часть в EDR, часть в записи сессий, и все это приходится сводить по времени и учеткам. Расследования идут дольше, потому что нет единого ответа «кто получил доступ, кто одобрил, через что вошел, что сделал». Плюс человеческий фактор: правила обходят (подключаются не через бастион, используют общую учетку, отключают аудит на узле).

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

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

Пример: если админ ночью изменил группу прав на файловом сервере и удалил следы, без PAM придется вручную собирать цепочку из событий ОС, телеметрии EDR и записей удаленного доступа. Если один элемент отсутствует (например, сессия не записалась), картина может остаться неполной.

Как выбрать архитектуру: пошаговый алгоритм

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

Практичный порядок действий:

• сформулируйте цели в измеримых терминах: на какие вопросы вы отвечаете (кто заходил, что менял, по чьему запросу, за какой период) и какие сроки хранения требуются
• соберите матрицу привилегий: какие админ-учетки есть, к каким системам имеют доступ, где лежат критичные данные (AD, виртуализация, базы, финансовые системы, сетевое оборудование)
• определите, что нужно фиксировать: факты входа, действия (команды, изменения конфигурации, операции с учетными записями), а для самых важных контуров - сессию целиком
• выберите точки контроля: на целевых системах (логи ОС и приложений), на шлюзе привилегированного доступа, при необходимости на сети
• продумайте хранение и разбор: кто имеет право смотреть записи, как защищается целостность, как запускается расследование и как выглядит цепочка согласований

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

Типовые архитектуры и когда какую выбирать

Выбор архитектуры обычно упирается в два вопроса: вы хотите видеть только факты (кто и что сделал) или еще и доказательства (как это делалось в сессии)? И второй - сколько у вас администраторов и насколько критичны системы.

Четыре рабочих варианта

На практике чаще всего встречаются такие схемы:

• Вариант A: SIEM как центр мониторинга. Подходит, если качественное журналирование уже настроено на ОС, СУБД, AD, сетевых устройствах и приложениях, и логи полно и быстро попадают в SIEM. Хорош для расследований по событиям, но хуже отвечает на вопрос «что именно делали в консоли».
• Вариант B: PAM для доступа + SIEM для корреляции и отчетов. Привилегии выдаются через PAM, есть ограничения и согласования, а SIEM собирает события и помогает видеть цепочки действий. Часто лучший выбор для регуляторов и внутренних проверок.
• Вариант C: бастион (jump host) с записью сессий + SIEM для событий. Удобно, когда нужно быстро закрыть доступ к критичным сегментам и получить запись экрана/команд. Важно заранее решить, где и сколько хранить записи.
• Вариант D: гибрид. PAM и/или запись сессий ставят на самые критичные системы (финансы, госданные, клинические системы), а для остального оставляют усиленный аудит и сбор логов в SIEM. Это снижает стоимость и нагрузку на команду.

Как выбрать под размер команды и число админов

Если админов 2-5 и инфраструктура небольшая, часто хватает варианта A или C для самых важных серверов. Когда админов 10+ или много подрядчиков, без PAM обычно растет хаос с учетками и исключениями.

Проверьте себя по нескольким критериям:

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

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

Пример: как проходит расследование подозрительных действий админа

Ситуация простая и неприятная: в Active Directory кому-то резко расширили права (например, добавили учетку в Domain Admins), а на одном из ключевых серверов почти одновременно отключилось журналирование. Утром это замечает служба ИБ или внутренний аудит и просит объяснения.

Разбор начинается не с инструментов, а с вопросов. Важно быстро собрать факты:

• кто именно вошел под привилегированной учетной записью (персональной или общей)
• с какого устройства или сервера выполнялись действия (имя хоста, IP, VPN, jump-сервер)
• каким способом заходили (RDP, PowerShell, консоль, удаленное администрирование)
• какое было основание (заявка, авария, регламентные работы) и кто согласовал
• что изменили конкретно: состав групп, GPO, локальные политики, настройки аудита

Если настроен SIEM, расследование часто начинается с временной линии. Аналитик находит событие добавления в привилегированную группу в логах контроллера домена, затем смотрит соседние события: успешная аутентификация, выдача Kerberos-билета, запуск административных инструментов, подключение по RDP, смена политики аудита. В итоге получается цепочка «вход -> повышение прав -> доступ к серверу -> отключение логов». Это помогает понять последовательность и масштаб, но SIEM обычно показывает факты из журналов, а не то, что человек делал внутри сессии.

PAM дает другой ракурс. Если привилегированный доступ проходит через PAM, можно поднять: была ли заявка, кто ее согласовал, какие учетные данные выдавались (или проксировались), какая была сессия и ее запись, какие команды вводились. Тогда спор «я не делал» превращается в проверяемый набор артефактов: запрос, время, цель, действия в сессии.

Чтобы расследование заняло часы, а не недели, подготовьтесь заранее:

• разведите персональные и привилегированные учетные записи и запретите общие админские логины
• централизуйте сбор логов и защитите их от удаления (раздельные права, неизменяемое хранение по политике)
• обязуйте вход админов через контролируемую точку (jump-сервер или PAM), а не напрямую
• синхронизируйте время на серверах и системах безопасности, иначе временная линия развалится
• закрепите процесс оснований: заявки, аварийные процедуры, кто и как согласует доступ

Частые ошибки и ловушки при внедрении контроля

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

Ошибка 1: SIEM есть, а данных нет

SIEM бесполезен, если события приходят неполными, с разным временем или без нужных полей. Например, есть факт входа на сервер, но нет привязки к конкретному админ-аккаунту или невозможно понять, что именно менялось.

Минимум, который стоит проверить:

• единое время (NTP) на системах и источниках логов
• список критичных систем и событий, которые обязаны попадать в сбор
• понятные правила нормализации (кто, куда, что сделал)
• тестовые кейсы: можете ли вы найти цепочку действий за 10 минут

Ошибка 2: PAM купили, процессы не изменили

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

Типичный провал: админ заходит через PAM, а потом использует старый локальный аккаунт на сервере. В результате часть действий не записывается, и картина расследования рвется.

Ошибка 3: логи хранят, но не защищают

Журналирование и хранение логов важно, но без контроля целостности это слабое место. Если администратор может удалить или подменить записи, на проверке это выглядит хуже, чем отсутствие логов. Также часто нет четких сроков хранения: сегодня держат 7 дней, завтра 30, а аудит и регулятор ждут предсказуемости.

Ошибка 4: слишком широкий доступ к логам и записям

Доступ к SIEM и к записям сессий PAM нередко дают слишком многим: ИТ, безопасности, подрядчикам. В итоге растут риски утечек, давления на расследование и «подчистки» следов.

Ошибка 5: команду не тренируют на реальных кейсах

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

Быстрый чек-лист готовности и следующие шаги

Если цель - не просто «собирать логи», а реально проводить расследования и проходить проверки, проверьте базовые вещи:

• есть полный список привилегированных учетных записей (включая сервисные), понятны владельцы систем и ответственные за доступ
• определены источники данных и минимальный набор событий: входы и попытки входа, повышение прав, изменение политик, доступ к критичным данным, операции с журналами
• разделены роли и обязанности: кто выдает доступ, кто администрирует, кто расследует, кто утверждает исключения
• понятны сроки и место хранения логов и записей сессий: где лежит «истина», у кого доступ, как защищено от удаления и подмены
• запланирован пилот на 1-2 критичных контура (например, домен/AD и ключевая бизнес-система) с критериями успеха: какие кейсы должны разбираться за 1 день, какие отчеты нужны аудитору

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

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

Если нужна помощь с проектированием и внедрением, имеет смысл подключать интегратора, который берет на себя архитектуру и стыковку процессов. Например, GSE.kz как системный интегратор может помочь собрать целевой контур SIEM и PAM, продумать неизменяемое хранение доказательств и разделение ролей под требования регуляторов и внутреннего аудита.