Перейти к содержимому

Системы управления уязвимостями (VM)

Система управления уязвимостями (VM) ведёт весь цикл: собирает список активов, находит на них уязвимости, расставляет очерёдность устранения, передаёт задачи ИТ и проверяет результат. В каталоге — платформы такого класса, а не разовые сканеры. Выбирают по охвату активов, источникам данных и связке с трекером задач.

Найдено сервисов: 0

В подкатегории «Системы управления уязвимостями (VM)» пока нет сервисов.

Часто задаваемые вопросы

Чем VM-платформа отличается от сканера уязвимостей?
Сканер — инструмент одного шага: он проверяет узлы или приложение и отдаёт список находок. Платформа управления уязвимостями строится вокруг процесса: она ведёт перечень активов и их владельцев, копит историю проверок, отбирает то, что действительно применимо к вашим системам, ставит задачи в трекер ИТ и следит за сроками, а после установки обновления перепроверяет узел. Сканер отвечает на вопрос «что найдено», платформа — «что из этого чинится первым и закрыто ли уже». Разовые инструменты собраны в соседнем разделе каталога.
Из каких шагов состоит процесс управления уязвимостями?
Обычно его описывают как повторяющийся цикл. Сначала инвентаризация: без списка активов непонятно, что вообще проверять. Затем выявление уязвимостей — сканированием, агентами или сопоставлением версий программ с базами. Дальше оценка применимости и опасности именно для вашей инфраструктуры и определение очерёдности. Потом устранение: обновление, изменение настроек либо компенсирующая мера, если обновиться нельзя. Замыкает цикл контроль — перепроверка и отчёт. Такую последовательность закрепляет и методический документ ФСТЭК России об организации этого процесса.
Откуда платформы берут сведения об уязвимостях?
Источников несколько, и платформы обычно сводят их вместе. Банк данных угроз безопасности информации ФСТЭК России удобен для отечественного программного обеспечения и для отчётности перед регулятором. Международные базы записей об уязвимостях дают широкое покрытие зарубежных продуктов. Бюллетени самих производителей и рассылки разработчиков операционных систем нередко выходят раньше баз. Отдельно ценят сведения о том, есть ли для уязвимости работающий эксплойт и встречается ли она в реальных атаках, — на это опирается расстановка очерёдности.
Почему нельзя просто чинить всё подряд по уровню критичности?
Потому что общая оценка опасности говорит о свойствах самой уязвимости, а не о вашей инфраструктуре. Одна и та же запись означает разное на сервере, открытом из интернета, и на стенде без внешнего доступа. При расстановке очерёдности смотрят ещё на ценность и роль актива, доступность узла извне, наличие готового эксплойта, вышло ли обновление и чем грозит перезапуск сервиса. Часть находок закрывают не обновлением, а изменением настроек или ограничением доступа — это фиксируют как принятое решение, чтобы к нему можно было вернуться.
Кому хватит сканера с таблицей, а кому нужна платформа?
Если активов немного, они на виду и обновлениями занимается один человек, связка «сканер плюс таблица» какое-то время работает. Отдельная платформа становится оправданной, когда активов сотни и тысячи, отвечают за них разные команды, появляются сроки устранения и внешние требования к отчётности, а вопрос «закрыли или нет» перестаёт решаться по памяти. Промежуточный вариант — управляемая услуга: подрядчик ведёт цикл на своей платформе и отдаёт отчёты. Такие компании тоже встречаются среди карточек этого раздела.

Как выбрать систему управления уязвимостями (VM)

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

Из чего складывается цикл

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

Чем платформы различаются между собой

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

Что уточнить до внедрения

Как считается лицензия — по узлам, по адресам или по агентам, и что произойдёт при росте инфраструктуры. Есть ли вариант установки в закрытом контуре без выхода в интернет и как тогда доставляются обновления баз. Насколько подробно платформа объясняет находку и способ устранения: от этого зависит, сколько времени уйдёт у администраторов. И самое приземлённое — кто со стороны компании будет вести процесс. Платформа без ответственного рискует превратиться в панель, которую никто не открывает.

Каталог обновлён: август 2026