Интеграции

Введение

Vulns.io Enterprise VM поддерживает интеграции с внешними системами по нескольким независимым направлениям. Каждое из них решает собственную задачу и настраивается отдельно, поэтому направления можно подключать по мере необходимости — в зависимости от того, какие процессы и инструменты уже используются в организации.

Направления интеграции

Кратко о каждом направлении:

• AD/LDAP — импорт активов и авторизация пользователей. Один и тот же тип сервера авторизации используется как для периодического импорта узлов из контроллера домена, так и для входа пользователей в Кабинет.
• САЗ «СканерВС» — импорт активов, учётных записей и пользователей из СканерВС в Систему Vulns.io VM. Система поддерживает автоматический импорт информации об активах, учётных записях и пользователях со стороннего сканера уязвимостей СканерВС.
• САЗ «RedCheck» — импорт активов, учётных записей и пользователей из RedCheck в Систему Vulns.io VM. Как и в случае со СканерВС, поддерживается автоматический импорт данных об активах, учётных записях и пользователях со стороннего сканера уязвимостей RedCheck.
• SGRC Securitm — обогащение реестра активов в Securitm информацией о программном обеспечении, пользователях, группах, маршрутах и сетевых интерфейсах, а также обогащение модуля VM информацией о технических уязвимостях на внешнем периметре.
• VMware vSphere — импорт активов из VMware vSphere в Систему Vulns.io VM.
• Внешние тикет-системы — контроль устранения уязвимостей и других задач через тикеты (заявки), с возможностью использовать как встроенную локальную, так и внешнюю тикет-систему.
• Docker Registry — сканирование образов контейнеров непосредственно в реестре.
• CI/CD-системы (GitLab/Jenkins) — сканирование образов на этапе сборки в пайплайне, до попадания образа в продуктивный реестр.
• REST API — программный доступ к данным и функциям Системы для построения собственных интеграций заказчика.

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

AD/LDAP: импорт активов и авторизация пользователей

Vulns.io Enterprise VM использует сервер авторизации Active Directory / LDAP в трёх независимых сценариях. Все они опираются на один и тот же тип сервера, но решают разные задачи и настраиваются отдельно друг от друга.

Три сценария использования

1. Импорт и синхронизация активов. Периодический импорт узлов из контроллера домена с привязкой учётных записей SSH/WinRM для дальнейшего безагентного сканирования. Этот сценарий позволяет наполнять список активов автоматически, опираясь на инвентаризацию, которая уже ведётся в домене, и одновременно закреплять за узлами доменные учётные данные для безагентного доступа.
2. Авторизация пользователей Кабинета. Вход пользователей AD/LDAP-каталога напрямую в Систему по доменным учётным данным. В этом режиме доменные пользователи создаются в Системе как пользователи типа Active Directory — учётные записи каталога AD, которые могут авторизовываться в Кабинете.
3. SSO (Single Sign-On). Авторизация пользователей организации через сервис единого входа (SAML/OIDC) на стороне контроллера домена, без хранения пароля в Системе. Такой подход исключает хранение пользовательских паролей на стороне Vulns.io VM и передаёт проверку подлинности на сторону доменного провайдера.

Сводка по сценариям

Важно: один сервер — разные независимые сущности

Для импорта активов и для авторизации пользователей используется один и тот же добавленный сервер авторизации, однако настраиваются эти функции как разные, независимые сущности:

• импорт активов — настраивается через задачу «Импорт активов / Синхронизация»;
• авторизация — настраивается через привязку пользователя или организации к серверу авторизации.

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

Подробнее об импорте активов из AD/LDAP — в разделе «Импорт активов из контроллера домена AD/LDAP».

Миграция со сторонних сканеров уязвимостей (САЗ «СканерВС» и «RedCheck»)

Vulns.io Enterprise VM поддерживает автоматический импорт информации об активах, учётных записях и пользователях со сторонних сканеров уязвимостей — Сканер ВС и RedCheck. Это направление ориентировано на организации, которые переходят на Vulns.io VM с ранее используемых средств анализа защищённости (САЗ).

Общий принцип работы

Импорт из обеих систем реализован как источник в единой задаче «Импорт активов / Синхронизация». По механике запуска этот сценарий аналогичен импорту из AD/LDAP и VMware vSphere, но использует собственный набор импортируемых данных. Схема работы выглядит следующим образом:

1. Подключение к исходной системе по URL, логину и паролю; у исходной системы запрашиваются списки хостов, пользователей и учётных записей.
2. Сопоставление и выбор данных для импорта в форме задачи — пользователь указывает, что именно импортировать:
   • конкретные хосты — с привязкой к учётной записи и группе активов;
   • учётные записи — создаются заново, аналогично исходным;
   • пользователей.
3. Проверка на дубликаты — по IP-адресу и доменному имени, чтобы исключить повторное добавление уже имеющихся активов.
4. Автоматическая установка Агента (опционально) — Агент может быть развёрнут на импортированные linux/windows-активы сразу после импорта.

Отметим, что учётные записи в Системе действительно создаются как отдельные сущности разных типов (в частности, ssh — для безагентного сканирования linux-активов и сетевых устройств, winrm — для windows-активов), а установленный Агент самостоятельно соединяется с Системой и переходит в режим ожидания команд.

САЗ «СканерВС»

Направление обеспечивает импорт активов, учётных записей и пользователей из СканерВС.

Ограничение: поддерживается только версия 6 и версия 7 СканерВС.

Подробнее — в разделе «Импорт данных из САЗ Сканер-ВС».

САЗ «RedCheck»

Направление обеспечивает импорт активов, учётных записей и пользователей из RedCheck — по той же механике, что и импорт из СканерВС (единая задача «Импорт активов / Синхронизация», сопоставление данных, проверка на дубликаты, опциональная установка Агента).

Подробнее — в разделе «Импорт данных из САЗ RedCheck».

Ценность направления

Интеграция со сторонними сканерами снижает порог перехода заказчиков на Vulns.io VM: при миграции переносятся не только активы, но и структура учётных записей и пользователей, а при необходимости на импортированные узлы сразу разворачиваются агенты. Это позволяет воспроизвести привычную структуру инвентаризации и доступа в новой Системе без ручного пересоздания и заметно ускоряет ввод Vulns.io VM в эксплуатацию.

VMware vSphere

Назначение

Направление обеспечивает импорт информации об активах (виртуальных машинах) из VMware vSphere в Систему. Импорт выполняется через ту же задачу «Импорт активов / Синхронизация», что и другие источники (AD/LDAP, СканерВС, RedCheck), и включает следующие шаги:

1. Подключение к VMware vSphere по URL, логину и паролю.
2. Выбор хостов для импорта с привязкой к учётной записи и группе активов.
3. Проверка на дубликаты — чтобы исключить повторное добавление уже имеющихся активов.
4. Опциональная установка агентов на импортированные активы.

Отметим, что после установки на актив Агент самостоятельно соединяется с Системой и переходит в режим ожидания команд.

Отличие от импорта из СканерВС / RedCheck

В отличие от миграции со сторонних сканеров уязвимостей, при импорте из VMware vSphere переносятся только хосты — без импорта учётных записей и пользователей.

Это ключевое различие определяет область применения направления: VMware vSphere используется как источник инвентаризации виртуальных машин, тогда как импорт из СканерВС и RedCheck переносит ещё и структуру учётных записей и пользователей.

Практическая рекомендация. Поскольку из vSphere переносятся только хосты, для последующего сканирования импортированных активов потребуется отдельно обеспечить доступ к ним — например, привязав учётную запись при выборе хостов или установив Агент в ходе импорта.

Подробнее — в разделе «Импорт из VMware vSphere».

Импорт активов из CSV-файла

Импорт из CSV-файла стоит несколько особняком: строго говоря, это не интеграция с внешней системой, однако его логично рассматривать рядом с прочими направлениями, поскольку он реализован в той же задаче «Импорт активов / Синхронизация», что и импорт из AD/LDAP, СканерВС, RedCheck и VMware vSphere.

Источник «Файл»

В задаче импорта доступен источник «Файл», который позволяет загрузить подготовленный CSV-файл (по шаблону) и импортировать активы из него — без подключения к внешней системе. Это удобно, когда список активов уже сформирован вне Системы и достаточно однократно перенести его в Vulns.io VM.

Подробнее — в разделе «Импорт активов из CSV-файла».

SGRC Securitm

Это направление принципиально отличается от остальных, описанных в статье. Здесь интеграция обратная по направлению реализации: она выполнена и поддерживается на стороне вендора Securitm.

Это важно учитывать при планировании: настройка и сопровождение интеграции ведутся средствами Securitm, а Vulns.io VM в данном сценарии выступает источником данных для платформы Securitm.

Что даёт интеграция

Интеграция обеспечивает обогащение данных в Securitm информацией из Vulns.io VM по двум направлениям:

1. Обогащение реестра активов в Securitm данными из Vulns.io VM о:
   • программном обеспечении;
   • пользователях;
   • группах;
   • маршрутах;
   • сетевых интерфейсах.

2. Обогащение VM-модуля Securitm информацией о технических уязвимостях на внешнем периметре (данные от Vulns.io VM).

Практический смысл. Интеграция позволяет использовать инвентаризационные данные и результаты анализа защищённости Vulns.io VM непосредственно в платформе Securitm (как для наполнения реестра активов, так и для работы с уязвимостями внешнего периметра в VM-модуле), не перенося эти данные вручную.

Настройка

Поскольку интеграция реализована на стороне Securitm, её настройка описана не в документации Vulns.io, а в справке Securitm.

Подробнее — в инструкции Securitm.

Внешние тикет-системы: контроль устранения уязвимостей

Назначение

Интеграция с тикет-системами предназначена для контроля устранения уязвимостей и других задач через тикеты (заявки). При этом Vulns.io Enterprise VM позволяет работать в двух режимах: использовать встроенную локальную тикет-систему или подключить внешнюю.

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

Поддерживаемые системы

Перечень поддерживаемых внешних систем:

• Jira (Data Center/Cloud),
• Yandex Tracker,
• Redmine,
• IntraService,
• Itilium,
• GLPI.

Что даёт интеграция

Интеграция с внешней тикет-системой обеспечивает:

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

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

Подробнее о настройке интеграции с конкретной тикет-системой — в разделе «Тикет-системы».

Docker Registry: сканирование образов в реестре

Назначение

Интеграция с реестрами образов предназначена для сканирования образов контейнеров непосредственно в реестре, без необходимости предварительно разворачивать образы на хостах. Это позволяет оценивать защищённость контейнерных образов ещё на этапе их хранения, не запуская их в рабочей среде.

Поддерживаемые протоколы и реестры

Поддерживаются Docker Registry HTTP API V2 и GitLab Container Registry API.

Принцип работы

Сканирование реестра выполняется по следующей схеме:

1. Подключение к реестру с заранее заданной учётной записью типа container_registry.
2. Сбор списка репозиториев и тегов доступных образов.
3. Скачивание и сканирование образов без запуска контейнеров.
4. Удаление образов из хранилища Системы после завершения сканирования.

О каждом обнаруженном docker-образе собирается и отправляется в Систему информация об операционной системе образа (название дистрибутива, версия), список установленного ПО с версиями, размер, архитектура и идентификатор образа (sha256), а также список слоёв. Полученные данные анализируются по имеющейся в Системе базе данных уязвимостей, после чего формируется результат сканирования: список уязвимого ПО, доступных обновлений, найденных уязвимостей, а также сопутствующая метаинформация (дата и время сканирования, CVSS-метрики, критичность по методике ФСТЭК и прочее).

Практическая рекомендация с точки зрения безопасности. Анализ образов выполняется без их запуска, поэтому сканирование не создаёт риска выполнения непроверенного кода из образа. Кроме того, образы удаляются из хранилища Системы после сканирования — это исключает избыточное накопление данных в хранилище.

Вебхуки

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

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

Подробнее — в разделе «Образы контейнеров / Реестры образов».

CI/CD (GitLab, Jenkins): сканирование образов на этапе сборки

Назначение

Интеграция с CI/CD-системами предназначена для сканирования образов на этапе сборки в пайплайне, до попадания образа в продуктивный реестр. Такой подход позволяет выявлять уязвимости в контейнерных образах ещё до их публикации и развёртывания, то есть смещает контроль защищённости «влево», к моменту сборки.

Принцип работы

Схема работы интеграции выглядит следующим образом:

1. В пайплайн встраивается специальный образ-компаньон, содержащий необходимый инструментарий для сканирования образов.
2. Образ-компаньон анализирует целевой образ без его запуска.
3. Собранные данные отправляются в Vulns.io Common API.
4. По результатам анализа формируется отчёт об уязвимостях как артефакт задачи CI/CD.

Практическая рекомендация с точки зрения безопасности. Анализ целевого образа выполняется без его запуска, поэтому встраивание сканирования в пайплайн не создаёт риска выполнения непроверенного кода из образа в сборочной среде.

Common API: локально или в облаке

Vulns.io Common API доступен также в облаке Vulns.io — этот вариант не требует развёртывания Системы, необходимо только получить токен.

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

Глубина интеграции с GitLab по тарифным планам

Глубина интеграции с GitLab различается в зависимости от тарифного плана — от базового отчёта в артефактах до полноценной интеграции с Security-дашбордом проекта:

Практическая рекомендация. Если требуется, чтобы результаты сканирования отображались непосредственно в Security-дашборде проекта GitLab, необходим план Premium или Ultimate. На плане Free результаты доступны в виде отчёта-артефакта пайплайна — этого достаточно для ручного анализа результатов, но встроенная визуализация в дашборде проекта недоступна.

Подробнее о шаблонах и настройке — в разделе «Образы контейнеров / Сканирование в CI/CD».

REST API: программный доступ к данным и функциям Системы

Назначение

В Системе реализован REST API, предназначенный для программного доступа к данным и функциям Системы и построения собственных интеграций заказчика. Это наиболее гибкий способ взаимодействия: он позволяет решать задачи, выходящие за рамки готовых интеграций, и встраивать данные Системы в произвольные внешние процессы и инструменты.

Примеры сценариев использования

REST API покрывает, в частности, следующие сценарии:

• отправка данных в системы управления инцидентами;
• безагентный аудит на основе данных систем инвентаризации заказчика;
• обогащение событий в SOC (Центрах информационной безопасности);
• обогащение собственных дашбордов и панелей визуализации — анализа и визуализации информации;
• экспорт результатов аудита/инвентаризации, метрик, статусов — практически любых данных, доступных в Кабинете.

Отметим, что с API Системы может работать и бесплатный продукт Vulns.io Linux Scanner — консольная Linux-программа с псевдографическим интерфейсом для проведения аудита уязвимостей Linux-дистрибутивов.

Управление доступом

Доступ к API осуществляется с использованием специальных API-токенов и может быть ограничен по нескольким измерениям:

Практическая рекомендация. Для каждой интеграции целесообразно выпускать отдельный токен с минимально необходимым набором прав (принцип наименьших привилегий): ограничивать его перечнем методов, кругом активов/групп активов, организациями и списком доверенных IP-адресов. Такой подход снижает последствия возможной компрометации отдельного токена и упрощает отзыв доступа для конкретной интеграции без влияния на остальные.

Учтите также, что любой актив, добавленный в Систему с помощью API, учитывается в лимите лицензии; при достижении лимита добавление новых активов прекращает работать, а ранее добавленные активы и накопленные результаты остаются доступны.

Подробнее об управлении токенами — в разделе «Управление API-токенами».

Сводная таблица интеграций

Заключение

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

• Получение данных об активах, учётных записях и пользователях — через AD/LDAP, САЗ «СканерВС», САЗ «RedCheck» и VMware vSphere. Эти источники реализованы в единой задаче «Импорт активов / Синхронизация» и позволяют наполнять Систему как отдельными хостами, так и полной структурой учётных записей и пользователей.
• Сканирование на разных этапах — образов в реестрах (Docker Registry) и на этапе сборки в пайплайне (CI/CD, GitLab/Jenkins).
• Контроль устранения найденных проблем — через встроенную локальную или внешнюю тикет-систему.
• Обогащение данных в смежных системах заказчика — интеграция с SGRC Securitm, реализованная на стороне Securitm, наполняет её реестр активов и VM-модуль данными из Vulns.io VM.
• Произвольная выгрузка данных вовне — через REST API для построения собственных интеграций заказчика.

Такой набор направлений позволяет встроить Систему в уже существующие процессы и инструменты заказчика, а не заменять их с нуля. Отдельно стоит выделить сценарий миграции с ранее использовавшихся сканеров уязвимостей (СканерВС, RedCheck): при переходе переносятся не только активы, но и структура учётных записей и пользователей, а при необходимости на импортированные узлы сразу разворачиваются агенты, что снижает порог перехода на Vulns.io VM.

Практический вывод. Направления интеграции независимы и подключаются по мере необходимости, поэтому Систему можно внедрять поэтапно: начать с наиболее приоритетного контура (например, импорта активов и сканирования), а затем последовательно подключать контроль устранения через тикет-системы, обогащение смежных систем и собственные интеграции через REST API. Детали настройки каждого направления приведены в профильных разделах руководства.