Контроль целостности на практике: как устроен Parus Integrity Monitoring

В прошлой статье мы разбирали требования к контролю целостности: приказы ФСТЭК России № 117, № 21 и № 239, ГОСТ Р 57580.1, PCI DSS. Там же был вывод, к которому мы регулярно приходим на аудитах. Модуль контроля целостности в СЗИ от НСД обычно настроен на небольшой набор системных файлов рабочих станций, а конфигурации серверов, сетевого оборудования и гипервизоров не контролирует никто.

Теперь посмотрим, как эту задачу решает специализированная система. Пример — Parus Integrity Monitoring (PIM) компании «Стайл Телеком», продукт из реестра российского ПО (запись № 24210 от 04.10.2024). Разберём, как он устроен, что умеет и на что смотреть при выборе FIM-решения вообще.

Что контролируется на хостах

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

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

Агенты есть для Windows (от рабочих станций до серверов) и для Linux: Astra Linux, ALT Linux, РЕД ОС, Debian, Ubuntu, RHEL, CentOS, Alma. Если вы сейчас переводите серверы на российские ОС, проверьте этот пункт заранее: контроль должен переехать вместе с серверами, иначе после миграции он останется только на старом сегменте.

Устройства без агента и конструктор SSH

Отдельная задача — оборудование, на которое агент не поставить. Это коммутаторы, маршрутизаторы, межсетевые экраны, гипервизоры, СХД, а также программно-аппаратные комплексы, производитель которых запрещает устанавливать сторонний софт и снимает за это устройство с поддержки.

Для сетевого оборудования в PIM уже был безагентский режим со списком поддерживаемых производителей: Cisco, Check Point, Palo Alto, Fortinet, UserGate, Eltex, Qtech и другие. Работает он так: по расписанию система подключается к устройству, выполняет заданные команды, сохраняет вывод и сравнивает его с предыдущим снимком. Если снимки отличаются, создаётся событие, такое же, как события с агентов.

Недостаток понятен: устройство не из списка остаётся без контроля. А такие находятся почти в любой инфраструктуре: гипервизоры, СХД, ИБП с сетевой картой управления, коммутатор редкого производителя в технологическом сегменте.

В третьем квартале 2026 года в PIM появился конструктор подключений по SSH, и это ограничение снято. Если устройство доступно по SSH и умеет выводить свои настройки командой в консоли, его можно подключить. В конструкторе задаются параметры подключения, набор команд и периодичность опроса. После этого PIM работает с устройством так же, как с оборудованием из штатного списка: снимает вывод, сравнивает с эталоном, создаёт события.

Что можно поставить на контроль таким способом:

• гипервизоры. На хостах KVM, на которых построены многие отечественные платформы виртуализации, это, например, вывод virsh dumpxml по каждой виртуальной машине (состав и настройки её виртуального оборудования) и virsh net-dumpxml по виртуальным сетям; на VMware ESXi — esxcli system settings advanced list и esxcli network vswitch standard list;
• сетевое оборудование, которого нет в списке поддерживаемых: show running-config, display current-configuration и аналоги у других производителей;
• Linux-серверы и программно-аппаратные комплексы, где агента ставить нельзя: содержимое ключевых конфигурационных файлов, список локальных пользователей, правила фильтрации трафика, контрольные суммы исполняемых файлов.

Отдельно про чёрный список команд. Система подключается к рабочему оборудованию под учётной записью с правами и выполняет там команды, поэтому ошибка в задании может обойтись дорого. Это может быть опечатка, неудачно скопированная строка или попытка злоумышленника использовать PIM как удобную точку для запуска команд сразу на всём парке устройств. Команды из чёрного списка система не выполняет, что бы ни было написано в задании. Туда разумно внести всё, что меняет состояние устройства: перезагрузку, сохранение и стирание конфигурации, переход в режим настройки, удаление файлов.

Несколько рекомендаций из практики, которые сэкономят время на пилоте:

1. Заведите для PIM отдельную учётную запись с правами только на чтение и разрешите вход под ней только с адресов серверов PIM. Чёрный список страхует от ошибок, но правильные права он не заменяет.
2. Подбирайте команды так, чтобы в выводе не было строк, которые меняются сами по себе. Например, show version содержит время работы устройства, а show interfaces — счётчики пакетов, и при каждом опросе вывод будет другим. Для сравнения нужны команды, которые показывают конфигурацию, а не текущее состояние. На старых версиях Cisco IOS сюрприз может принести даже running-config: строка ntp clock-period меняется без участия администратора. Если такие строки попадают в сравнение, событие возникает при каждом опросе, и через пару недель их перестают читать.
3. Периодичность опроса выбирайте по критичности. Межсетевые экраны на периметре и гипервизоры с важными виртуальными машинами стоит опрашивать часто, коммутаторам доступа обычно хватает одного раза в сутки. Для гипервизоров в ГИС нижнюю границу задаёт регулятор: мера ЗСВ.2 из методического документа к приказу № 117 требует проверки не реже раза в неделю.

Эталоны, события, инциденты

Логика работы у PIM стандартная для FIM. При подключении агент получает от сервера задание: что контролировать, что исключить, с каких объектов снять эталон. Затем проводит первичное сканирование и сохраняет контрольные суммы и атрибуты в локальную базу. Дальше объекты проверяются по расписанию или в реальном времени, каждое изменение превращается в событие и отправляется на сервер.

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

В PIM для этого есть политики безопасности: событие проверяется по правилам, и инцидент создаётся, только если правило сработало. Сейчас политики доступны в режиме превью, так что пробовать их можно, но строить на них всю обработку событий мы бы пока не стали. Второй путь — отдавать события в SIEM по syslog и разбирать их там. Если SIEM уже есть, так обычно удобнее: события PIM оказываются рядом с журналами остальных средств защиты, и правило можно построить, например, на изменении конфигурации межсетевого экрана в нерабочее время или сразу после входа на него под учётной записью, которой там работать не положено. Правила в SIEM под события PIM мы помогаем настроить при внедрении. Уведомления PIM отправляет по почте и в Telegram.

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

Ещё PIM собирает инвентаризацию: сетевые настройки, установленное ПО, открытые порты, процессы, оборудование; есть встроенный сканер сети. Это помогает в той же задаче, потому что лишнее проще найти, когда есть полный список того, что должно быть.

Архитектура и отказоустойчивость

Схема клиент-серверная: веб-консоль управления, сервер PIM, отдельный сервер БД и node-серверы для удалённых площадок. На node-серверы можно вынести приём и анализ событий, чтобы не гонять весь поток через каналы связи с филиалами. Есть кластер primary/secondary: если основной сервер недоступен, агенты переключаются на резервный примерно за 10 секунд. У распределённых организаций это один из первых вопросов к любому поставщику FIM: что происходит с контролем, когда падает сам сервер контроля.

Из того, что пригодится при внедрении: маскирование путей в конфигурациях, интеграция с Active Directory для доступа к консоли, настройки безопасности самой консоли (требования к паролям, блокировки, тайм-ауты сессий). Сервер FIM знает, где лежат самые важные файлы, а с появлением конструктора SSH хранит ещё и учётные данные для доступа к сетевому оборудованию и гипервизорам. Защищать его нужно на уровне контроллера домена.

Какие требования это закрывает

Вернёмся к требованиям из первой статьи.

Для значимых объектов КИИ (приказ № 239) основная мера — ОЦЛ.1, контроль целостности программного обеспечения. Она входит в базовый набор для всех трёх категорий значимости. С конструктором SSH к этому добавляется контроль конфигураций сетевого оборудования и гипервизоров, который раньше на многих объектах приходилось вести вручную.

Для ИСПДн по приказу № 21 это мера ОЦЛ.1, контроль целостности программного обеспечения, включая ПО средств защиты информации, а если ИСПДн работает в виртуальной среде, ещё и ЗСВ.7, контроль целостности виртуальной инфраструктуры и её конфигураций. Обе меры входят в базовый набор только для первого и второго уровней защищённости; для третьего и четвёртого они появляются, если их добавили при адаптации набора мер под актуальные угрозы. ЗСВ.7 обычно закрывали отдельными средствами защиты виртуализации, теперь контроль конфигураций гипервизоров можно вести и через конструктор SSH.

Для ГИС с 1 марта 2026 года действует приказ № 117. Контроль конфигураций в нём вынесен в пункт 37: нужно исключать несанкционированные изменения состава программных и программно-аппаратных средств, их настроек и конфигураций, обнаруживать такие изменения и выяснять их причины, опираясь на результаты учёта ИТ-активов. Здесь пригодятся обе функции PIM: контроль изменений и инвентаризация. Без специализированного средства это требование обычно выполняется только на бумаге.

Для виртуализации в апреле 2026 года ФСТЭК выпустила к приказу № 117 методический документ с мерой ЗСВ.2, контролем целостности средств виртуализации и виртуальных машин. Базовая часть меры (не реже раза в неделю проверять состав и настройки виртуального оборудования работающих ВМ) реализуется встроенными механизмами самих средств виртуализации. А усиление для классов К2 и К1 — контроль исполняемых файлов и параметров настройки хостовой ОС и гипервизора — как раз задача для агента PIM или конструктора SSH.

Для финансовых организаций это соответствующие меры ГОСТ Р 57580.1, а для тех, кто работает с платёжными картами, ещё и требование 11.5.2 PCI DSS о механизме обнаружения изменений критичных файлов.

С чего начинать внедрение

Порядок, который мы используем на FIM-проектах:

1. Начните с небольшого набора критичных объектов: системные каталоги контроллеров домена и ключевых серверов, конфигурации периметровых межсетевых экранов, файлы ДБО или другой основной бизнес-системы. Сюда же через конструктор SSH стоит добавить гипервизоры, на которых работают критичные виртуальные машины.
2. Две-три недели поработайте с этим набором: вынесите в исключения то, что меняется штатно и даёт шум, при необходимости настройте фильтрацию в SIEM.
3. После этого расширяйте охват.

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

Лицензии PIM считаются по числу контролируемых сетевых устройств, серверов и АРМ, бывают срочные и бессрочные.

---

Внедрение средств защиты. Подберём решение контроля целостности под вашу инфраструктуру, проведём пилот, настроим обработку событий в SIEM и введём систему в эксплуатацию. От 300 000 ₽. Подробнее об услуге. После внедрения разбор событий и поддержку правил можно передать нам в рамках сопровождения СЗИ.