Системы мониторинга инфраструктуры занимают особое место в IT-архитектуре государственных заказчиков: они видят всё. Метрики серверов, логи приложений, сетевой трафик, события безопасности — средство мониторинга имеет привилегированный доступ к данным всей наблюдаемой среды. Именно поэтому к доверенному статусу для этой категории предъявляются особые требования по безопасности: ненадёжная система мониторинга потенциально опаснее, чем уязвимость в любом из наблюдаемых компонентов. Дедлайн для средств мониторинга — 1 января 2027 года, и он совпадает с серверным ПО, СУБД и связующим ПО. Разработчики, которые не учли конкурентного давления этого периода, рискуют столкнуться с очередями в центрах тестирования именно тогда, когда время на счету.
Что относится к средствам мониторинга по классификатору Минцифры
Категория средств мониторинга включает широкий спектр продуктов — от агентов сбора метрик до полноценных платформ наблюдаемости. Точная классификация продукта до начала процедуры важна: граница между мониторингом и средствами ИБ нередко размыта, и от правильного выбора класса зависит дата дедлайна и специфика экспертизы.
📊 Системы мониторинга инфраструктуры
Платформы для сбора и визуализации метрик серверов, сетевого оборудования, хранилищ. Российские аналоги Zabbix, Nagios, Prometheus в коммерческом исполнении.
📱 APM — мониторинг производительности приложений
Системы наблюдения за поведением и производительностью приложений в продуктивной среде. Трассировка запросов, профилирование, анализ узких мест.
📝 Платформы централизованного сбора логов
Системы агрегации, хранения и анализа журналов событий. Российские аналоги ELK Stack в коммерческом исполнении для государственного сегмента.
🌐 Системы мониторинга сети
Платформы для наблюдения за состоянием сетевой инфраструктуры, анализа трафика, выявления аномалий в сетевом взаимодействии.
☁️ Платформы наблюдаемости (observability)
Комплексные решения для работы с метриками, логами и трассировками одновременно. Современный подход к мониторингу сложных распределённых систем.
⚠️ Системы управления событиями и оповещениями
Платформы для корреляции событий, управления инцидентами и оповещения ответственных лиц. Часть более широких платформ ITSM в части мониторинга.
Граница между мониторингом и ИБ: как не ошибиться с классом
Один из практических вопросов, с которым мы сталкиваемся при работе с разработчиками этой категории — правильное определение класса продукта. Системы мониторинга и средства информационной безопасности имеют значительное функциональное пересечение, и от того, в какой класс попадёт продукт, зависит дата дедлайна и специфика экспертизы.
Характеристика продукта Скорее средство мониторинга Скорее средство ИБ Основная функция Сбор метрик, визуализация состояния, оповещение об отклонениях Выявление угроз, реагирование на инциденты, защита систем Дедлайн 1 января 2027 года 1 июня 2027 года Примеры Zabbix-аналоги, APM, log management SIEM, IDS/IPS, антивирусы, сканеры уязвимостей Пограничные случаи SIEM с мониторинговыми функциями, NOC-платформы с ИБ-модулями — требуют отдельной классификации
Если продукт совмещает функции мониторинга и информационной безопасности, правильный класс определяется основной функциональностью. В спорных случаях — позицией регулятора. Мы помогаем с классификацией на этапе первичного аудита, чтобы исключить ситуацию, когда продукт проходит экспертизу как средство мониторинга, а заказчики воспринимают его как ИБ-инструмент.
Что проверяет центр тестирования в системах мониторинга
Привилегированное положение систем мониторинга в IT-инфраструктуре определяет специфику экспертизы. Центр тестирования работает с несколькими ключевыми блоками.
🔐
Защита собранных данных
Система мониторинга агрегирует чувствительные данные об инфраструктуре заказчика. Проверяется шифрование хранимых метрик и логов, разграничение доступа к данным мониторинга, защита каналов передачи между агентами и сервером сбора. Применение российской криптографии по ГОСТ для защиты данных — стандартное требование.
🕵️
Контроль действий агентов
Агенты мониторинга работают на всех наблюдаемых хостах с расширенными правами. Центр тестирования детально проверяет, какие именно данные собирает агент, есть ли у него возможность выполнять произвольные команды и передавать данные за пределы периметра заказчика.
🔒
Разграничение доступа к панели управления
Консоль мониторинга предоставляет видимость всей инфраструктуры. Проверяются ролевая модель доступа, многофакторная аутентификация, аудит действий администраторов и операторов. Несанкционированный доступ к консоли мониторинга эквивалентен доступу к описанию всей IT-инфраструктуры заказчика.
📡
Отсутствие внешних коммуникаций
Системы мониторинга не должны передавать данные о наблюдаемой инфраструктуре за периметр без явного разрешения. Проверяется сетевая активность продукта, наличие телеметрии в сторону разработчика, коммуникации с внешними сервисами.
Специфика open source основы в системах мониторинга
Рынок систем мониторинга в значительной мере построен на open source фундаменте. Zabbix, Prometheus, Grafana, OpenSearch — широко используемые основы для российских коммерческих решений. Это создаёт стандартные вопросы по правам и лицензиям, но у мониторинговых продуктов есть своя специфика.
Grafana, например, перешла с Apache License на AGPL в версии 7.0 и выше. Для коммерческих продуктов, использующих Grafana как компонент визуализации, это означает потенциальное обязательство по раскрытию кода продукта, если он распространяется внешним пользователям. Аналогичная ситуация с рядом плагинов Zabbix. Такие лицензионные вопросы нужно выявлять и прорабатывать до подачи заявления — они влияют как на правовую позицию при экспертизе, так и на структуру продукта в целом.
Prometheus и Grafana: лицензионный нюанс
Prometheus распространяется под Apache License 2.0 — это не создаёт проблем для коммерческой надстройки. Grafana с версии 7.0 перешла на AGPL v3, что означает: если вы распространяете продукт с компонентом Grafana внешним пользователям — весь исходный код вашего продукта подпадает под требование раскрытия по AGPL. Для внутреннего использования в инфраструктуре заказчика это требование не действует. При получении доверенного статуса этот вопрос требует юридической проработки в зависимости от модели распространения продукта.
Совместимость с доверенными ОС для систем мониторинга
Системы мониторинга работают в двух режимах: серверный компонент (сервер сбора данных, консоль управления) и агентский компонент (устанавливается на наблюдаемые хосты). Требование совместимости с двумя доверенными ОС применяется к обоим компонентам, и здесь важно понимать разницу в сложности.
Компонент Что проверяется Типичные проблемы Серверная часть Полноценная работа сервера сбора данных на доверенных ОС, web-консоль через доверенный браузер Windows-зависимости в серверном компоненте, специфика работы с базой данных метрик Агент мониторинга Корректный сбор метрик на хостах под управлением доверенных ОС Сбор специфических метрик Linux отличается от Windows; системные вызовы, метрики ядра Коллекторы и экспортёры Корректная работа специализированных коллекторов для наблюдаемых компонентов Коллекторы для Windows-специфичных метрик нерелевантны; нужны Linux-коллекторы
Для систем мониторинга на Python, Go или Java серверная часть обычно хорошо переносится на доверенные ОС. Основная техническая работа — в агентском компоненте: сбор метрик ядра Linux, интеграция с системными службами, корректное отображение специфики Astra Linux в панели мониторинга.
Как выстраивается подготовка к экспертизе
1
Классификация и аудит архитектуры
Подтверждаем правильный класс продукта по классификатору Минцифры. Анализируем архитектуру с точки зрения требований безопасности: что собирают агенты, куда передают данные, какова сетевая активность продукта. Проверяем лицензионную чистоту всех компонентов, включая Grafana, Prometheus и другие open source зависимости. Срок: 5–10 рабочих дней.
2
Юридическая проверка прав
Анализируем права на коммерческую часть продукта: надстройка над open source, собственные плагины, интерфейс управления. Для продуктов с историческими подрядными командами — проверяем договоры на предмет условий об отчуждении прав. Отдельно оцениваем лицензионные риски компонентов под AGPL.
3
Тестирование совместимости с доверенными ОС
Проверяем серверный компонент и агенты на Astra Linux SE и РЕД ОС. Для агентов — тестируем сбор системных метрик, работу с journald, интеграцию с systemd. Web-консоль — через Яндекс Браузер и другие доверенные браузеры. Фиксируем несовместимости и передаём в команду разработки.
4
Подготовка документации
Готовим архитектурную документацию, описание механизмов защиты данных, перечень собираемых метрик и каналов их передачи, модель угроз. Для систем мониторинга ключевой документ — детальное описание того, что именно делает агент на наблюдаемом хосте и какие данные передаёт серверу.
5
Сопровождение экспертизы и получение отметки
Подбираем центр тестирования, координируем взаимодействие в ходе экспертизы. После положительного заключения сопровождаем направление в правительственную комиссию по цифровому развитию до получения отметки о доверенном ПО в реестровой записи ФГИС.
Стоимость и сроки для средств мониторинга
Статья расходов Стоимость Срок Технический и юридический аудит от 50 000 ₽ 5–10 рабочих дней Сопровождение под ключ от 190 000 ₽ весь проект Экспертиза центра тестирования от 400 000 до 650 000 ₽ до 30 рабочих дней Доработка совместимости с ОС индивидуально 2–8 недель в зависимости от стека Полный бюджет без доработки от 590 000 до 840 000 ₽ 4–5 месяцев
Вопросы разработчиков систем мониторинга
Наша платформа использует Grafana для визуализации. Создаёт ли AGPL-лицензия Grafana проблемы при экспертизе?
AGPL-лицензия Grafana создаёт не столько проблему при экспертизе, сколько юридическую позицию, которую нужно проработать заранее. Если продукт распространяется внешним заказчикам с Grafana в составе — AGPL требует раскрытия исходного кода всего производного произведения. Для SaaS-модели или внутреннего развёртывания без передачи копий продукта это требование не возникает. Конкретное решение зависит от модели распространения. Варианты — использование Grafana Enterprise с коммерческой лицензией, замена на альтернативный компонент визуализации или перестройка архитектуры. Это нужно решать до подачи заявления.
Агент нашей системы мониторинга работает с правами root. Будет ли это проблемой при экспертизе?
Работа с правами root сама по себе не является основанием для отказа — многие мониторинговые агенты требуют привилегированного доступа для сбора системных метрик. Но это означает повышенное внимание центра тестирования к тому, что именно делает агент с этими правами. Нужно чётко задокументировать каждое действие агента и обосновать необходимость именно такого уровня привилегий. Если часть функций можно выполнять с меньшими правами — лучше реализовать это до экспертизы.
Наша система собирает метрики с облачных ресурсов через API публичных облаков. Это влияет на статус доверенного ПО?
Интеграция с публичными облаками через API проверяется с точки зрения безопасности данных. Центр тестирования смотрит: какие данные передаются наружу, шифруется ли канал, есть ли возможность отключить эту интеграцию. Если коллектор для публичного облака — опциональный модуль, который не используется при работе в периметре государственного заказчика, риски минимальны. Если без подключения к внешним API продукт не функционирует — это более серьёзный вопрос.
Конкуренция за экспертизу в январе 2027 будет высокой. Стоит ли начинать прямо сейчас?
Да, и именно поэтому. Три категории с одним дедлайном — серверное ПО, СУБД, связующее ПО и мониторинг — создадут пиковую нагрузку на центры тестирования во второй половине 2026 года. Компании, которые подадут заявления в первом квартале 2026 года, получат экспертизу в спокойный период с предсказуемыми сроками. Компании, которые придут в сентябре-октябре 2026 — попадут в очередь, и гарантировать прохождение до дедлайна будет значительно сложнее.
Мы мониторим не только инфраструктуру, но и события безопасности. Нужно получать два статуса — как для мониторинга и как для ИБ?
Нет, продукт получает один статус по основному классу. Если платформа классифицирована как средство мониторинга — она проходит одну процедуру с дедлайном января 2027 года. Дополнительная ИБ-функциональность учитывается в рамках единой экспертизы. Если продукт по существу является SIEM с мониторинговым модулем — он, вероятно, попадёт в класс средств ИБ с дедлайном июня 2027 года. Правильная классификация на старте исключает неожиданности в середине процедуры.
Системы мониторинга — один из наиболее технически готовых сегментов
По нашей практике разработчики систем мониторинга на современных кросс-платформенных стеках нередко находятся в лучшей стартовой позиции по совместимости с доверенными ОС, чем разработчики других серверных категорий. Основные риски — в лицензионной чистоте open source компонентов и в безопасности агентского слоя. Предварительный аудит позволяет точно оценить объём работ и спланировать процедуру с запасом до дедлайна.
1 янв. 2027 — дедлайн для средств мониторинга 4–5 мес. реальный срок процедуры от 400 000 ₽ стоимость экспертизы в центре тестирования 95% успешных включений с первого раза
Обсудить получение доверенного статуса для вашей системы мониторинга
Расскажите о продукте: тип платформы, open source основа, модель агентов, текущий статус в реестре. Проведём аудит и составим план с учётом дедлайна января 2027 года и конкурентного давления этого периода.
Телефон / WhatsApp / Telegram: +7 920-898-17-18
Email: reestrgarant@mail.ru
Первичная консультация бесплатная в рабочее время.
Оригинальная статья
Полная версия статьи на нашем сайте: https://vnesenie-v-reestr.ru/news/doverennye-sredstva-monitoringa-poluchenie-statusa-doverennogo-po-dlya-sistem-nablyudeniya
Мы занимаемся включением в реестр Минпромторга
📞 Телефон: +7 920-898-17-18
✉️ Email: reestrgarant@mail.ru