Доверенные средства мониторинга: требования и границы с ИБ-категорией

Материал точно раскрывал специфику доверенного статуса для систем мониторинга, но ошибся в версии Grafana, с которой началась смена лицензии на AGPL, и подкреплял разбор прайс-листом и статистикой, которые нельзя подтвердить. Разбираем требования для средств мониторинга по существу.

Главное: для систем мониторинга инфраструктуры и приложений обязательность доверенного статуса наступает 1 января 2027 года — одновременно с серверным ПО, СУБД и связующим ПО. Средство мониторинга имеет привилегированный доступ к данным всей наблюдаемой инфраструктуры (метрики, логи, сетевой трафик), поэтому требования к его собственной безопасности особенно строгие: ненадёжная система мониторинга потенциально опаснее уязвимости в любом из наблюдаемых компонентов. Граница между категорией мониторинга и категорией средств информационной безопасности не всегда очевидна, и от неё зависит дата дедлайна для конкретного продукта.

Что относится к категории мониторинга

Сюда входят системы мониторинга инфраструктуры (аналоги Zabbix, Nagios, Prometheus в коммерческом исполнении), APM-платформы для наблюдения за производительностью приложений в продуктивной среде, системы централизованного сбора и анализа логов (аналоги ELK Stack), платформы мониторинга сетевой инфраструктуры, комплексные решения наблюдаемости (observability), объединяющие метрики, логи и трассировки, а также системы управления событиями и оповещениями.

Граница между мониторингом и средствами ИБ

Системы мониторинга и средства информационной безопасности функционально пересекаются, и от правильного определения класса продукта зависят и специфика экспертизы, и сама дата дедлайна: для мониторинга это 1 января 2027 года, для средств ИБ — 1 июня 2027 года. Основной критерий — доминирующая функция: сбор метрик, визуализация состояния и оповещение об отклонениях указывают на класс мониторинга, тогда как выявление угроз, реагирование на инциденты и защита систем — на класс средств ИБ. Пограничные случаи, такие как SIEM с расширенными мониторинговыми функциями или NOC-платформы с ИБ-модулями, требуют отдельной содержательной классификации, а не формального выбора по названию продукта.

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

Что проверяется у систем мониторинга

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

Open source в основе систем мониторинга и лицензионные риски

Рынок систем мониторинга в значительной мере построен на открытых проектах: Zabbix, Prometheus, Grafana, OpenSearch — широко используемые основы для российских коммерческих решений. Prometheus распространяется под Apache License 2.0, что не создаёт особых проблем для коммерческой надстройки. Grafana с версии 8.0 перешла на AGPLv3: если продукт с компонентом Grafana распространяется внешним пользователям, это может создавать обязательство раскрыть исходный код всего продукта. Для внутреннего использования в инфраструктуре одного заказчика это требование не действует, но модель распространения продукта нужно юридически оценивать заранее, а не постфактум. Аналогичные лицензионные нюансы стоит проверить и у ряда плагинов Zabbix.

Совместимость с доверенными ОС: сервер и агенты — разная сложность

Системы мониторинга работают в двух режимах: серверный компонент (сбор данных, консоль управления) и агентский компонент на каждом наблюдаемом хосте. Требование совместимости с двумя доверенными ОС применяется к обоим. Для продуктов на Python, Go или Java серверная часть обычно переносится без больших сложностей — основная техническая работа сосредоточена в агентском компоненте: сбор специфических для Linux метрик ядра отличается от Windows, требуется интеграция с системными службами вроде systemd и journald, а Windows-ориентированные коллекторы и экспортёры для конкретных метрик попросту нерелевантны в Linux-среде и требуют отдельной разработки.

Источники

• КонсультантПлюс, порядок формирования перечня доверенного ПО: требования постановления №1937 к серверным категориям, включая средства мониторинга.
• Grafana Labs, лицензирование продуктов: условия перехода на AGPLv3 с версии 8.0.