Для ИТ-поддержки удалённый доступ — рабочий инструмент: подключиться к компьютеру пользователя, разобраться, поправить настройки и отключиться. Сессия закрыта, заявка тоже.
Для ИБ это выглядит несколько иначе.
Каждое удалённое подключение потенциально оставляет набор событий: кто подключился, к какому устройству, когда началась сессия, какие права использовались, какие действия выполнялись, передавались ли файлы, какие изменения произошли после этого.
Если эти события связать между собой, система удалённого доступа становится дополнительным источником телеметрии для расследования инцидентов.
Разберём это на примере RuDesktop — от простого кейса с пропавшим файлом до корреляции событий в SIEM.
Начнём с инцидента
Представим обычную ситуацию.
Пользователь обращается в Service Desk: на рабочей станции не открывается приложение. Специалист подключается удалённо, что-то проверяет, меняет настройки и завершает сессию.
Через час пользователь сообщает:
«После подключения поддержки у меня пропал важный файл».
Начинается классическая ситуация «слово против слова».
Пользователь утверждает, что файл был. Специалист говорит, что ничего не удалял.
Если в системе сохранилась только запись:
support03 connected to WS-184
она мало что даёт.
Нам нужно восстановить последовательность событий:
И чем больше элементов этой цепочки мы можем подтвердить из независимых источников, тем меньше расследование зависит от объяснений участников.
Какие данные нужны для расследования
В случае с удалённым доступом полезно связать несколько типов событий:
историю подключений;
данные авторизации;
запись удалённой сессии;
аудит действий;
файловые операции;
административные политики;
изменения аппаратной и программной конфигурации;
события из других средств защиты через SIEM.
В RuDesktop эти данные можно использовать как единую временную линию расследования.
1. Определяем, кто подключался
Первый вопрос — кто вообще имел доступ к устройству.
Например:
14:03 — пользователь создал обращение 14:08 — support03 подключился к WS-184 14:21 — сессия завершена 15:10 — пользователь сообщил о пропаже файла
У нас уже есть временная связь между обращением и удалённой сессией.
Но пока нельзя утверждать, что файл удалил именно оператор.
Для этого нужны следующие источники.
2. Смотрим, что происходило во время сессии
Журнал подключения отвечает на вопрос «кто подключался», но не обязательно отвечает на вопрос «что он делал».
Здесь помогает запись удалённой сессии.
Например:
14:10 — открыт проводник 14:12 — изменён конфигурационный файл 14:15 — перезапущена служба
В серверной версии RuDesktop запись может выполняться централизованно и храниться на сервере.
Это позволяет после завершения подключения вернуться к сессии и посмотреть последовательность действий оператора.
При этом запись экрана сама по себе не является полноценным forensic-инструментом и не заменяет EDR или DLP. Это ещё один источник данных, который нужно сопоставлять с остальными событиями.
3. Проверяем файловые операции
Следующий уровень — события работы с файлами.
14:08:32 — session started 14:14:07 — file transfer opened 14:14:51 — report.xlsx deleted 14:21:10 — session finished
Теперь у нас есть связь:
support03 → WS-184 → сессия 14:08–14:21 → операция с report.xlsx
Это уже гораздо более полезная информация для расследования.
Но здесь есть принципиальное ограничение: журнал фиксирует операцию, а не создаёт резервную копию файла. Если report.xlsx был удалён, из самого события нельзя восстановить его содержимое.
Поэтому журнал файловых операций и резервное копирование решают разные задачи.
4. Проверяем административные действия
Не все изменения происходят непосредственно внутри интерактивной удалённой сессии.
Администратор может централизованно запустить политику, которая изменит конфигурацию, установит ПО или применится сразу к группе устройств.
Например:
03:12 — admin02 авторизовался 03:14 — запущена Policy-27 03:17 — политика применена к группе Finance 03:25 — на устройствах появились ошибки
В этом случае поиск причины только по удалённым подключениям ничего не даст.
Нужен аудит действий самой системы управления.
Это особенно важно в больших инфраструктурах: одна административная операция может изменить состояние сотен или тысяч устройств.
Инвентаризация тоже является источником событий
Обычно инвентаризацию рассматривают как справочную информацию: какое железо и ПО установлено на компьютере.
Для расследования это тоже может быть полезным источником событий.
Допустим, вчера на рабочей станции присутствовал определённый компонент оборудования, а сегодня его уже нет.
Само по себе это ничего не доказывает. Компонент могли заменить штатно.
Но если одновременно обнаруживается:
изменение оборудования + удалённое подключение + необычная учётная запись
появляется основание для дополнительной проверки.
То же самое относится к установленному ПО.
Если программа появилась на машине между двумя точками инвентаризации, это событие можно сопоставить с административной политикой или удалённой сессией.
Когда событий становится много, нужен SIEM
На десятке компьютеров ещё можно открыть журналы вручную.
На тысячах устройств — уже нет.
Поэтому события удалённого доступа имеет смысл передавать в SIEM и использовать в корреляционных правилах.
В RuDesktop для этого можно экспортировать события через Syslog.
Например, простое правило может выглядеть так:
несколько failed login → successful login → административная политика → массовое изменение устройств
Другой сценарий:
удалённое подключение → файловая операция → изменение конфигурации → обращение пользователя
А дальше эти события можно сопоставить с данными других систем:
Удалённый доступ в таком случае не становится SIEM или EDR. Он становится ещё одним источником телеметрии, которого может не хватать для восстановления полной картины инцидента.
Полное расследование исходного кейса
Вернёмся к report.xlsx.
Пользователь сообщает, что после работы поддержки файл исчез.
Расследование может выглядеть так:
Определяем устройство — WS-184.
Находим удалённую сессию — support03, 14:08–14:21.
Проверяем запись сессии — выясняем, какие действия выполнялись.
Проверяем файловые события — находим report.xlsx deleted.
Проверяем авторизацию — кто использовал support03, откуда была выполнена авторизация и не было ли подозрительной активности до подключения.
Проверяем события в SIEM — сопоставляем полученную временную линию с событиями EDR, DLP, AD и других систем.
Вместо «Я файл не удалял» получаем последовательность событий, которую можно проверять по нескольким источникам.
Это и есть основная ценность аудита удалённого доступа для ИБ.
А если инцидент происходит прямо сейчас?
Аудит отвечает прежде всего на вопрос: «Что произошло?»
Но при активной сессии возникает другой вопрос: «Что делать прямо сейчас?»
Если в системе видна подозрительная активная сессия, администратор может принудительно её завершить и уже после этого перейти к расследованию.
Получается простая последовательность:
обнаружение → реакция → сбор событий → расследование
Для ИБ это существенно полезнее, чем просто хранить историю подключений.
Тот же механизм можно использовать для Service Desk
Есть ещё один сценарий, который напрямую связан с аудитом.
Запись сессий позволяет оценивать не только инциденты, но и работу технических специалистов.
Например, пользователь сообщает, что после обновления перестало запускаться корпоративное приложение.
По записи реальной сессии можно посмотреть:
с чего специалист начал диагностику;
какие команды и настройки использовал;
требовались ли ему административные права;
какие изменения он внёс;
решил ли проблему;
сколько времени заняло решение.
Это отличается от обычного тестирования знаний.
Тест показывает, знает ли сотрудник правильную последовательность действий.
Запись реальной сессии показывает, как он действует на настоящей рабочей станции.
Особенно полезно это при адаптации новых сотрудников Service Desk.
Аудит не должен превращаться в слежку
Техническая возможность записывать действия сотрудника ещё не означает, что нужно постоянно наблюдать за каждым оператором.
До включения такого контроля организация должна определить:
какие события собираются;
для каких целей;
кто имеет к ним доступ;
сколько они хранятся;
при каких условиях записи просматриваются;
какие события требуют расследования.
То есть запись должна быть частью понятного процесса ИБ, а не просто включённой функцией.
Логирование не заменяет разграничение прав
Можно идеально записывать действия администратора, но если у каждого сотрудника есть права суперпользователя, аудит будет только фиксировать последствия слишком широкого доступа.
Поэтому логирование должно сочетаться с принципом least privilege.
Например:
Service Desk → пользовательские рабочие станции System Administrator → определённые группы устройств и административные политики ИБ → аудит и события расследования Super Admin → максимальные права, минимальное количество учётных записей
Тогда система решает сразу две задачи:
ограничивает потенциально опасные действия;
позволяет расследовать те действия, которые всё-таки были выполнены.
Отдельный случай — внешние специалисты
Подрядчику иногда нужен доступ к конкретному устройству всего на несколько часов.
Создавать для этого постоянную учётную запись с широкими правами — плохая практика.
Безопаснее ограничить доступ по нескольким параметрам:
устройство: APP-SRV-02 права: удалённое управление время: 10:00–18:00 использований: 1
После завершения работ доступ автоматически перестаёт быть пригодным для повторного использования.
В этом случае временный доступ и аудит работают вместе: мы не только ограничиваем канал, но и сохраняем информацию о том, как он использовался.
Что в итоге получает ИБ
Удалённый доступ сам по себе создаёт дополнительный риск: специалист может управлять устройством независимо от своего физического местоположения.
Но тот же канал можно использовать для получения данных о происходящем в инфраструктуре.
Если система фиксирует подключения, учётные записи, права, действия в сессии, файловые операции, административные операции, изменения конфигурации и состояние устройств, то удалённый доступ становится ещё одним источником событий для SOC и расследований.
И здесь полезно смотреть не на отдельные логи, а на связь между ними:
КТО ↓ К КАКОМУ УСТРОЙСТВУ ↓ КОГДА ↓ С КАКИМИ ПРАВАМИ ↓ ЧТО СДЕЛАЛ ↓ ЧТО ИЗМЕНИЛОСЬ ПОСЛЕ ЭТОГО
Чем больше этих звеньев можно подтвердить из журналов разных систем, тем полнее получается временная линия инцидента.
Поэтому защищённый удалённый доступ — это не только шифрование соединения и контроль авторизации. Для ИБ не менее важен аудируемый след действий, который можно использовать для обнаружения, реагирования и последующего расследования.
