Руководство администратора

Список обозначений

Система - развернутое и работающее в сети заказчика решение "Vulns.io Enterprise VM"
Актив - компьютер, сервер, виртуальная машина, гипервизор или сетевое устройство, мониторинг которого ведется с помощью Системы.
Агент - программа, устанавливаемая на Актив, для обеспечения его сканирования в агентном режиме.
Кабинет - основной web-интерфейс системы для работы пользователей.
Лицензия - право на использование продукта на заданный срок с оговоренными ограничениями и функционалом.
Ключ лицензии - буквенно-цифровой код для идентификации активированной лицензии.
БДУ - база данных уязвимостей, на основе которой производится сканирование Активов.

Архитектура решения

Архитектурно Vulns.io Enterprise VM является on-premise решением на физическом или виртуальном сервере, работающим в сети и на мощностях заказчика:

Система в сети заказчика

Компоненты системы

Сервисы, работающие в Системе:

основная БД - хранение информации об активах, результатах сканирования, БДУ и пр.,
кэширующая БД - ускорение выполнения задач аудита,
воркеры - выполнение всех типов задач в Системе,
реверс-прокси - поддержка SSL, ограничение сетевого доступа,
сервис обновления БДУ - обновление базы данных уязвимостей,
web-socket сервер - поддержка двусторонней связи с Агентами,
утилита командной строки - выполнения базовых операций с сервисами Системы.

Сервисы и службы, работающие на активах заказчика:

агент для linux-систем - выполнение всех типов задач на linux-активах,
агент для windows-систем - выполнение всех типов задач на windows-активах.

Web-сервисы, работающие на стороне вендора Vulns.io:

облачное API - для получения списка файлов обновлений,
сервер обновлений - для скачивания файлов обновлений БД уязвимостей,
сервер лицензирования - для проверки лицензии Системы,
реестр docker-контейнеров - для получения обновлений docker-контейнеров.

Схема взаимодействия компонентов Системы

Требования к серверу и ОС

физический сервер или виртуальная машина,
любой linux-дистрибутив, поддерживающий Docker 19.03.13+ и Docker-compose 1.29.0 - 2.0.0,
доступ в Интернет.

Конфигурация сервера

Количество активов	Количество ядер	Объем памяти	Тип хранилища
до 100	6	24 ГБ	HDD
100 - 500	8	32 ГБ	HDD
500 - 2000	12	48 ГБ	SSD
2000 - 5000	16	64 ГБ	SSD
5000 - 10000	32	128 ГБ	SSD
10000+	*	*	*

^* Для инфраструктур с количеством активов 10000+ разворачивание системы рекомендуется производить на нескольких серверах с оркестрацией контейнеров Docker Swarm или Kubernetes (для получении рекомендаций и помощи обратитесь в техподдержку).

Разворачивание системы в Kubernetes позволяет организовать автоматическое масштабирование ключевых компонентов системы для ускорения сканирования больших инфраструктур.

Конфигурация хранилища

Ниже приведены примеры ориентировочных объемов хранилища для разных вариантов частоты сканирования (каждого актива тремя типами задач) и глубины хранения:

Вариант 1 - ежедневное сканирование, хранение истории 30 дней.
Вариант 2 - ежедневное сканирование, хранение истории 180 дней.
Вариант 3 - еженедельное сканирование, хранение истории 1 год.
Вариант 4 - еженедельное сканирование, хранение истории 3 года.

Количество активов	Вариант 1	Вариант 2	Вариант 3	Вариант 4
до 100	36 ГБ	40 ГБ	37 ГБ	40 ГБ
100 - 500	40 ГБ	60 ГБ	42 ГБ	55 ГБ
500 - 2000	55 ГБ	130 ГБ	65 ГБ	120 ГБ
2000 - 5000	75 ГБ	270 ГБ	105 ГБ	240 ГБ
5000 - 10000	112 ГБ	500 ГБ	170 ГБ	440 ГБ

Приведенные объемы хранилища определены условно и будут зависеть от инфраструктуры, в которой развернута система.

Сетевые доступы

В интернет

Для установки и дальнейшего обновления решения серверу Системы требуется ряд сетевых доступов в сеть Интернет:

Доменное имя	Порт	Тип ресурса	Предназначение
api.vulns.io	443	API	Получение списка файлов обновлений
data.vulns.io	443	Сервер обновлений	Получение файлов обновлений БДУ
hub.vulns.io cr.yandex storage.yandexcloud.net	443	Реестр docker-контейнеров	Получение обновлений docker-контейнеров

Опционально может потребоваться доступ к следующим сайтам для установки Docker и Docker-compose:

Внутри инфраструктуры

Источник	Назначение	Порт	Описание трафика
Рабочее место пользователя Системы	Система	80,443 / TCP	HTTP-трафик Кабинета
Актив с Агентом	Система	443 / TCP	Подключение Агентов к серверу Системы
Система	linux-активы без Агента	22 / TCP	Подключение к linux-активам
Система	windows-активы без Агента	135,137-139, 445 / TCP/UDP	Подключение к windows-активам
Система	сетевое оборудование *	22,23 / TCP, 162 / UDP	Подключение к сетевым устр-вам
Система	почтовый сервер	25 / TCP	Отправка сообщений на email
Система	реестры контейнеров	443 / TCP	Подключение к реестрам контейнеров для сканирования образов

^* сетевые доступы будут зависеть от конкрентного оборудования.

Требования к учетной записи

С привилегиями sudo (или root)

Рекомендуется выполнять установку и обновление под пользователем root или пользователем с привилегиями sudo (возможностью выполнять действия с правами администратора).

В этом случае у пользователя будут все необходимые права для:

запуска docker-контейнеров,
записи в папку /opt,
создании символической ссылки в /usr/local/bin/vio-cli.

Без привилегий sudo

Если у пользователя нет административных прав, то необходимо выполнение следующих условий:

у пользователя есть права на запись в папку /opt,
пользователь находится в группе docker (см. документацию Docker),
после установки необходимо выполнить команду:

sudo ln -s /opt/vulns.io/onpremise/cli/vio-cli /usr/local/bin/vio-cli

Защищенное взаимодействие

В зависимости от компонентов Системы и направления взаимодействия применяются следующие механизмы защиты этого взаимодействия.

Запросы Системы к web-сервисам, работающим на стороне вендора:

к API сервера обновлений, серверу лицензирования:
- уникальный для конкретного экземпляра Системы ключ API для аутентификации,
- шифрование по протоколу SSL,
при скачивании файлов с сервера обновлений:
- уникальный временный подписанный URL с временем жизни не более 2 часов для аутентификации,
- шифрование по протоколу SSL,
при доступе к реестру docker-контейнеров:
- уникальная временная учетная запись с временем жизни не более 24 часов для аутентификации,
- шифрование по протоколу SSL.

Запросы Системы к Активам при безагентном сканировании:

linux-активы и сетевые устройства:
- логин/пароль или сертификаты для аутентификации,
- шифрование по протоколу SSH,
windows-активы:
- логин/пароль или сертификаты для аутентификации,
- шифрование по протоколу SSL.

Запросы Агентов к Системе:

Агенты для linux- и windows-активов:
- уникальный для каждого Агента ключ API для аутентификации,
- шифрование по протоколу SSL.

Взаимодействие сервисов, работающих в Системе, между собой:

уникальные для конкретного экземпляра Системы учетные записи сервисов, генерируемые в процессе установки Системы.

Пользователи

Организация - обособленная сущность для объединения группы пользователей и активов. Пользователи Организации могут работать только с Активами своей организации.

Такой подход позволяет сегментировать Активы в компаниях со сложной структурой:

Организация 1
- Пользователь 1
- Пользователь 2
Организация 2
- Пользователь 3
- Пользователь 4
Организация 3...

Управление организациями и пользователями

Добавление, редактирование и удаление пользователей и организаций осуществляется в разделе Кабинета "Система / Пользователи".

Статусы и типы пользователей

Статусы:

Активен - может авторизовываться и работать в Кабинете.
Не активен - не может авторизовываться в Кабинете.

Типы:

Системный - пользователь, который создается при установке Системы. Данный пользователь не может быть удалён.
Пользовательский - пользователи, созданные администраторами Системы.
Active Directory - пользователи каталога AD, которые могут авторизоваться в Кабинете Системы.
LDAP - пользователи каталога LDAP, которые могут авторизоваться в Кабинете Системы.

Роли пользователей

Суперадминистратор (super_admin) - полные права на работу с данными всех организаций, создание организаций, управление любыми пользователями, конфигурирование и обновление системы.
Администратор организации (account_admin) - полные права на работу с данными конкретной организации (активы, пользователи, отчеты), запуск задач.
Пользователь организации (user) - имеет доступ только в рамках своей организации: добавление активов, создание задач, генерация отчетов, работа с белыми списками.
Пользователь организации (только чтение) (reader) - имеет доступ только в рамках своей организации: просмотр состояния инфраструктуры, создание задач (аудит, инвентаризация, генерация отчетов)

Подробное описание прав доступа каждой из ролей указано в ПРИЛОЖЕНИИ 1. "Ролевая модель: матрица прав доступа".

Серверы авторизации

Для того, чтобы пользователи каталога AD/LDAP могли авторизоваться в Кабинете и работать в Системе, необходимо предварительно создать соответствующий сервер авторизации. Затем указать этот сервер при создании пользователя Системы.

Управление серверами авторизации осуществляется в разделе Кабинета "Система / Пользователи / Серверы авторизации".

При добавлении сервера авторизации необходимо указать:

тип сервера: ldap или activedirectory,
имя сервера,
URL в формате ldap://192.168.1.100,
Base DN в формате dc=vulns,dc=example,dc=com,
описание сервера (опционально).

Двухфакторная авторизация

Любой пользователь Системы может настроить себе двухфакторную авторизацию (2FA). Рекомендуется сделать это для усиления защиты доступа к данным.

После включения 2FA для входа в Систему потребуются:

данные учетной записи пользователя (логин и пароль),
уникальный код, который генерируется специальным приложением для одноразовых паролей (Google Authenticator, Яндекс.Ключ и подобные).

Двухфакторная авторизация включается в профиле пользователя:

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

Следующий вход в Кабинет Системы потребует ввода одноразового пароля из приложения.

Отключение двухфакторной авторизации также производится в профиле пользователя:

Откройте форму редактирование профиля.
Переведите переключатель "Двухфакторная аутентификация (2fa)" в положение "Выключено".

Журналирование действий

Любые действия пользователей Системы, связанные с созданием/удалением сущностей, внесением изменений в существующие сущности, а также события, связанные с авторизацией в Системе, сменой пароля и прочие, сохраняются в журнал "Действия пользователей", который доступен в разделе "Система / Журналы".

Для каждого события сохраняются:

дата и время события,
идентификатор пользователя, который его совершил,
подробное описание события с идентификаторами задействованных сущностей.

Конфигурирование

Конфигурационный файл config.ini

Основной конфигурационный файл Системы: /opt/vulns.io/onpremise/config/main/config.ini

Пример содержимого:

[cloud.api]
url = https://api.vulns.io/onprem/v1
key = 1234567890987654321234567890

[docker.registry]
type = primary

[api]
use_cache = true
debug_mode = false
agent_access_token_expiration = 259200
access_token_expiration = 300
user_password_max_age = 90
user_max_unsuccessful_login_attempts = 4
user_used_passwords_max_number = 3

[log]
level = info

[data-updater.scheduler]
cron = 0 * * * *
cron_type = cron

[data-updater.subscriptions]
channels = linux/*, bulletins, windows/*

[data-updater.other]
mongodb_bulkwrite_size = 10000

[smtp.sender]
name = Test name
email = mail@client.com

[smtp.transport.auth]
user = example@yandex.ru
password = 123123

[smtp.transport.smtp]
host = smtp.yandex.ru
port = 25
secure = true

#[smtp.transport]
#service = Yandex

Параметры конфигурационного файла

Параметр	Описание
[cloud.api]
url	URL облачного API Vulns.io
key	Ключ API Vulns.io
[cloud.api.proxy]
protocol	Протокол прокси для запросов к облачному API Vulns.io
host	Hostname/IP прокси для запросов к облачному API Vulns.io
port	Номер порта прокси для запросов к облачному API Vulns.io
[cloud.api.proxy.auth]
username	Пользователь прокси для запросов к облачному API Vulns.io
password	Пароль пользователя прокси для запросов к облачному API Vulns.io
[docker.registry]
type	Реестр контейнеров для обновления системы: `primary`
[api]
use_cache	Использовать кэш при аудите уязвимостей (ускоряет процесс аудита)
debug_mode	Режим DEBUG аудита уязвимостей (в логах появится расширенная информация о метриках процесса аудита)
agent_access_token_expiration	Время жизни токена доступа Агентов
access_token_expiration	Время жизни токена доступа в Кабинете
user_password_max_age	Время жизни пользовательских паролей в днях (после истечения потребуется смена)
user_max_unsuccessful_login_attempts	Количество попыток ввода пользовательского пароля до показа капчи
user_used_passwords_max_number	Количество хранимых ранее использованных пользователем паролей для проверки их уникальности
[log]
level	Уровень системного логирования (для логов в /opt/vulns.io/onpremise/logs/*): `info`\|`verbose`\|`debug`
[data-updater.scheduler]
cron	Расписание проверки каналов обновлений (в формате CRON)
cron_type	Тип механизма периодической проверки: `cron`
[data-updater.subscriptions]
channels	Каналы обновления
[data-updater.other]
mongodb_bulkwrite_size	Обновлять данные в БД пачками по
[smtp.sender]
name	Имя отправителя в исходящих письмах
email	Email отправителя в исходящих письмах
[smtp.transport.auth]
user	Имя пользователя для подключению к SMTP-серверу
password	Пароль пользователя для подключению к SMTP-серверу
[smtp.transport.smtp]
host	Hostname или ip-адрес SMTP-сервера
port	Порт SMTP-сервера
secure	SSL (true/false)
[smtp.transport]	[Альтернативно настройкам smtp.transport.smtp]
service	Сервис почтовой службы (например: "Yandex", "Mail.ru", "Gmail") см. полный список

После изменения параметров в конфигурационном файле необходимо перезапустить Систему командой:

/opt/vulns.io/onpremise/cli/vio-cli restart

Доменное имя

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

Откройте конфигурационный файл: /opt/vulns.io/onpremise/config/nginx/api.conf
Укажите новое доменное имя в директиве server_name
Перезапустите сервис Nginx командой:

/opt/vulns.io/onpremise/cli/vio-cli restart nginx

Важно: если Система настроена на использование SSL-соединения, необходимо перевыпустить сертификат на новое доменное имя!

SSL-сертификаты

Установка сертификата от Certificate Authority

Используемый для SSL-соединения сертификат должен храниться в каталоге /opt/vulns.io/onpremise/config/ssl/.

Подготовьте SSL-сертификат и секретный ключ в формате PEM.
Назовите их api.crt и api.key и поместите в каталог /opt/vulns.io/onpremise/config/ssl/.
Раскомментируйте или добавьте в конфигурационный файл /opt/vulns.io/onpremise/config/nginx/api.conf настройки SSL:

listen 443 ssl;

if ($scheme = http) { return 307 https://$host$request_uri; }
ssl_protocols TLSv1.2 TLSv1.3;
ssl_certificate /opt/vulns.io/onpremise/config/ssl/api.crt;
ssl_certificate_key /opt/vulns.io/onpremise/config/ssl/api.key;

Перезапустите Nginx командой:

/opt/vulns.io/onpremise/cli/vio-cli restart nginx

Откройте в браузере адрес Кабинета и проверьте правильность настройки сертификата.

Установка самоподписанного сертификата

Используемый для SSL-соединения сертификат должен храниться в каталоге /opt/vulns.io/onpremise/config/ssl/.

Выполните команду генерации сертификата (параметр '-days' определяет срок действия сертификата):

openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
-keyout /opt/vulns.io/onpremise/config/ssl/api.key \
-out /opt/vulns.io/onpremise/config/ssl/api.crt

В процессе выполнения команды введите запрашиваемую информацию, в том числе доменное имя сервиса (например, vulns.company.local).

В каталоге /opt/vulns.io/onpremise/config/ssl/ появятся файлы сертификата и секретного ключа: api.crt и api.key.

Раскомментируйте или добавьте в конфигурационный файл /opt/vulns.io/onpremise/config/nginx/api.conf настройки SSL:

listen 443 ssl;

if ($scheme = http) { return 307 https://$host$request_uri; }
ssl_protocols TLSv1.2 TLSv1.3;
ssl_certificate /opt/vulns.io/onpremise/config/ssl/api.crt;
ssl_certificate_key /opt/vulns.io/onpremise/config/ssl/api.key;

Перезапустите Nginx командой:

/opt/vulns.io/onpremise/cli/vio-cli restart nginx

Откройте в браузере адрес Кабинета и проверьте правильность настройки сертификата.

Ограничение доступа по IP-адресам

По умолчанию доступ к Системе и API Системы открыт для любых сетевых адресов.

Для того, чтобы ограничить/открыть доступ на сетевом уровне, выполните следующие шаги:

Откройте конфигурационный файл /opt/vulns.io/onpremise/config/nginx/api.conf
С помощью директив allow и deny определите необходимые доступы.
Перезапустите Nginx командой /opt/vulns.io/onpremise/cli/vio-cli restart nginx

Примеры:

allow 192.168.30.88; ## разрешает доступ с ip-адреса
deny 192.168.42.0/24; ## запрещает доступ из сети 192.168.42.0/255.255.255.0
deny all; ## запрещает доступ

Проксирование HTTP/HTTPS запросов

Проксирование запросов к реестру образов Docker

В процессе установки / обновления продукта происходят запросы к реестру образов Docker.

Документация по настройке прокси Docker

Проксирование запросов к облачному API Vulns.io

В процессе работы продукта происходят регулярные запросы к облачному API Vulns.io

Чтобы настроить прокси нужно добавить в главный конфигурацинный файл /opt/vulns.io/onpremise/config/main/config.ini следующие секции:


[cloud.api.proxy]
protocol = https
host = 127.0.0.1
port=9000

[cloud.api.proxy.auth]
username = foo
password = bar

Сохранить изменения конфигурационного файла и перерестартовать сервисы worker-main и data-updater:

vio-cli restart worker-main data-updater

Управление API-токенами

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

по списку организаций,
по списку активов или групп активов (в т.ч. сетевых устройств или docker-образов),
по списку конкретных методов API,
по списку ip-адресов, с которых будет вызываться API Системы.

Управление токенами доступно в разделе "Настройки / API-токены".

При создании токена необходимо указать:

название,
описание,
список ограничений.

Важно: API-токен нельзя изменить! При необходимости удалите токен и создайте новый.

Токен необходимо передавать в http-заголовке x-api-key.

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

curl -H "x-api-key: <API_KEY>"\
https://<HOSTNAME>/integration/v1/webhooks/container-registries/<REGISTRY_ID>

wget --header "x-api-key: <API_KEY>"\
https://<HOSTNAME>/integration/v1/webhooks/container-registries/<REGISTRY_ID>

Логирование

Компоненты Системы пишут логи в своих папках в /opt/vulns.io/onpremise/logs:

/opt/vulns.io/onpremise/logs/cli - логи утилиты командной строки vio-cli,
/opt/vulns.io/onpremise/logs/data-updater - логи системы обновления БД уязвимостей,
/opt/vulns.io/onpremise/logs/nginx - логи реверс-прокси сервера Nginx,
/opt/vulns.io/onpremise/logs/worker-main - логи воркеров.

Уровень логирования можно изменить в конфигурационном файле /opt/vulns.io/onpremise/config/main/config.ini (см. раздел "Конфигурирование").

Ротация и срок хранения логов

Ротация лог-файлов происходит каждые сутки автоматически, хранятся последние 10 файлов.

Обновление БД уязвимостей

Каналы обновлений

Канал обновления - условное понятие для определения потока обновлений различных разделов БД уязвимостей или Системы.

Каналы обновлений бывают:

системные - включены в поставку Системы, не зависят от Лицензии и не могут быть отключены пользователем,
лицензионные - подхватываются Системой из Лицензии, могут быть отключены пользователем.

Системные

Канал agent/* - бинарные файлы Агентов для различных операционных систем и разрядностей.
Канал service/* - метаданные базы уязвимостей, вспомогательные данные для проведения аудита уязвимостей.
Канал bulletins - база бюллетеней безопасности.

Лицензионные

Канал linux/* - уязвимости для всех поддерживаемых Vulns.io linux-дистрибутивов,
Канал windows/* - уязвимости для всех поддерживаемых Vulns.io версий ОС Windows и ПО для Windows.

Обновление по расписанию

Все активные каналы обновляются автоматически в соответствии с настроенным расписанием (см. раздел "Конфигурирование / Параметры конфигурационного файла").

Ручное обновление

Чтобы принудительно запустить обновление БД уязвимостей, необходимо перезапустить сервис data-updater командой:

/opt/vulns.io/onpremise/cli/vio-cli restart data-updater

Контроль целостности обновлений

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

Загрузка файлов обновлений БДУ и бинарных файлов Агентов осуществляется по защищенному каналу связи с использованием протокола SSL.

Обновление установленных агентов

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

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

В целом процедура обновления Агента состоит из следующих шагов:

Система автоматически по заданному расписанию получает новые бинарные файлы Агентов по каналу обновления agent/* (см. раздел "Обновление БД уязвимостей / Каналы обновлений")
Агент, получив от Системы команду на обновление (в рамках выполнения соответствующей задачи), скачивает с сервера Системы новую версию бинарного файла.
Агент самостоятельно выполняет обновление до новой версии.
(Опционально) В случае неудачного обновления Агент самостоятельно производит откат на предыдущую рабочую версию.

Таким образом, регламентные работы по обновлению Агентов на Активах производятся непосредственно из Кабинета Системы ручным или автоматическим способом без использования сторонних средств администрирования.

Текущую версию установленного на Активе Агента можно узнать на детальной странице Актива.

Ручное обновление

Для ручного обновления Агентов необходимо запустить задачу типа "Активы / Обновление агентов":

Перейти на страницу "Аудит / Задачи" -> кнопка "Создать задачу"
Выбрать:
- тип задачи: "Активы",
- время запуска: "Сейчас" или "В заданное время",
- список активов, на которых необходимо обновить Агентов,
- действие: "Обновление агентов"
Нажать кнопку "Создать задачу"

Задача будет запущена сразу или в заданное время. Агентам будет отправлена команда на обновление, а результат обновления Агентов будет отражен на детальной странице запуска задачи.

Автоматическое обновление по расписанию

Для автоматического обновления Агентов по расписанию необходимо создать периодическую задачу типа "Активы / Обновление агентов" (см. "Ручное обновление ") с временем запуска "По Cron'у", задав нужное расписание запуска в формате CRON.

Лицензирование

Как лицензируется продукт

Лицензия "Vulns.io Enterprise VM" определяет:

максимальное количество Активов, которое можно зарегистрировать в Системе,
доступные каналы обновления БД уязвимостей,
срок действия работы Системы.

Лицензия является именной, имеет уникальный Ключ и поставляется в активированном виде в специальном файле license.txt, наличие которого является обязательным для установки и эксплуатации Системы.

Вместе с файлом лицензии заказчик получает ключ к облачному API Vulns.io, посредством которого Система получает обновления. Действие ключа API синхронизировано со сроком действия лицензии.

Лимит активов

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

Каналы обновлений

Система может получать обновления БД уязвимостей только для каналов, указанных в Лицензии.

Подробнее о каналах обновлений смотри в разделе "Обновление БД уязвимостей / Каналы обновлений"

Срок лицензии

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

Продление лицензии

Для продления лицензии необходимо:

Получить новый файл лицензии license.txt.
Заменить им существующий файл /opt/vulns.io/onpremise/config/main/license.txt
Перезапустить сервисы командой:

/opt/vulns.io/onpremise/cli/vio-cli restart data-updater worker-main

Апгрейд лицензии

Процедура апгрейда Лицензии полностью повторяет процедуру продления (см. выше).

Защита файла лицензии

Лицензионный файл содержит специальную цифровую подпись, которая защищает его от изменений. В процессе установки и функционирования Системы производится контроль целостности лицензионного файла путем проверки данной подписи.

Производительность

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

производительности базы данных (сервис mongodb),
количества сервисов worker-main (воркеров), обрабатывающих задачи сканирования,
количества других параллельно выполняемых задач: генерации отчетов, обновления БД и прочих.

Возможны следующие способы увеличения производительности Системы:

Вертикальное масштабирование:
- увеличение количества ядер CPU сервера и количества воркеров worker-main,
- использование высокоскоростных NVMe накопителей.
Горизонтальное масштабирование:
- запуск Системы на нескольких серверах с помощью оркестрации Docker Swarm или Kubernetes.

Один сервер: увеличение количества воркеров

В случае, если Система запущена на единственном сервере, рекомендуется определить количество воркеров worker-main по следующей схеме:

по одному ядру выделить на сервисы: mongodb, redisdb, nginx, centrifugo, data-updater,
одно ядро выделить на работу операционной системы,
остальные ядра выделить на сервисы worker-main.

Для того, чтобы изменить количество запускаемых сервисов worker-main, необходимо:

В файле /opt/vulns.io/onpremise/config/manage/docker-compose.yml изменить параметр services.worker-main.deploy.replicas (по умолчанию: 4).
Пересоздать сервисы worker-main командой:

/opt/vulns.io/onpremise/cli/vio-cli recreate worker-main

Запуск в режиме Docker Swarm или в Kubernetes

Для получении рекомендаций и помощи по развертыванию Системы в режиме Docker Swarm или в инфраструктуре Kubernetes обратитесь в техподдержку компании "Фродекс": support@frodex.ru

Регламентные работы

Обновление системы

Обновление Системы осуществляется с помощью команды:

/opt/vulns.io/onpremise/cli/vio-cli update

Скачивание обновленных образов контейнеров займет какое-то время, затем они будут автоматически перезапущены.

Контроль целостности обновлений Системы

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

Данная проверка осуществляется при установке/обновлении Системы штатными средствами Системы: инсталлера vio-installer или утилитой командной строки vio-cli update

Загрузка обновлений Системы осуществляется по защищенному каналу связи с использованием протокола SSL.

Мониторинг дискового пространства

Основные каталоги дискового хранилища, которые необходимо мониторить:

/opt/vulns.io/onpremise/data/mongodb/ - основная база данных Системы (активы, результаты сканирования, уязвимости и пр.), растет по мере добавления Активов и выполнения задач по их сканированию,
/opt/vulns.io/onpremise/data/artifacts/ - хранилище сгенерированных файлов отчетов, растет по мере выполнения задач генерации отчетов,
/opt/vulns.io/onpremise/logs/ - хранилище логов сервисов Системы, ротируется согласно внутренним настройкам (см. раздел "Логирование"),
/var/lib/docker/volumes/manage_agents-volume/ - хранилище бинарных файлов Агентов для разных операционных систем и разрядностей, растет по мере скачивания Системой новых версий Агентов с сервера обновлений Vulns.io.

Интерфейс командной строки (vio-cli)

Утилита командной строки vio-cli входит в состав Системы и предназначена для выполнения базовых операций с сервисами Системы: мониторинг состояния, обновление, перезапуск и пр.

Расположение утилиты: /opt/vulns.io/onpremise/cli/vio-cli

Общий синтаксис выполнения команд:

vio-cli [options] [COMMAND] [SUBCOMMAND]

Параметры утилиты:

Параметр	Назначение параметра
-V, --version	Выводит текущую версию утилиты
-h, --help	Выводит описание команд утилиты

status

Отображает статус состояния сервисов Системы:

vio-cli status

Пример вывода для нормально функционирующей Системы:

✔ Getting status from services ...
    Name                  Command               State                     Ports
-----------------------------------------------------------------------------------
centrifugo     centrifugo -c config.json        Up       0.0.0.0:8000->8000/tcp
cli            node /cli-entrypoint.bundl ...   Exit 0
data-updater   docker-entrypoint.sh /app/ ...   Up
frontend       /entrypoint.sh                   Exit 0
manage_api_1   /app/api                         Up       0.0.0.0:49169->3000/tcp
manage_api_2   /app/api                         Up       0.0.0.0:49170->3000/tcp
mongodb        docker-entrypoint.sh mongod      Up       0.0.0.0:27017->27017/tcp
nginx          /docker-entrypoint.sh ngin ...   Up       0.0.0.0:443->443/tcp
redisdb        docker-entrypoint.sh redis ...   Up       0.0.0.0:6379->6379/tcp

Важно: Статус "Exit 0" у сервисов cli и frontend является нормальным состоянием для этих сервисов.

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

Restarting - сервис в процессе перезапуска,
Up - сервис запущен и успешно работает,
Paused - сервис остановлен,
Exit (code) - сервис был запущен, а затем завершен с указанным кодом

update [services...]

Обновляет Систему полностью или только указанные сервисы:

vio-cli update

Важно: процесс обновления вызывает остановку всех сервисов Системы, в том числе прерывает работу Кабинета и API.

enter <service>

Позволяет получить терминальный доступ к конкретному сервису:

vio-cli enter mongodb

start [services...]

Выполняет запуск Системы или конкретных сервисов:

vio-cli start

stop [services...]

Выполняет остановку Системы или конкретных сервисов:

vio-cli stop

restart [services...]

Выполняет перезапуск Системы или конкретных сервисов:

vio-cli restart nginx

recreate [services...]

Пересоздает все или выбранные контейнеры сервисов Системы (hard restart, данные не уничтожаются):

vio-cli recreate nginx

remove [services...]

Останавливает работу всех или выбранных сервисов Системы и удаляет соответствующие контейнеры (данные не уничтожаются):

vio-cli remove nginx

ПРИЛОЖЕНИЕ 1. Ролевая модель: матрица прав доступа

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

разрешительные действия пользователей с ролью "Суперадминистратор" (super_admin) применимы к любой сущности любой организации,
разрешительные действия пользователей с ролями "Администратор организации" (account_admin), "Пользователь организации" (user) и "Пользователь организации (чтение)" (reader) применимы только к сущностям организации, членами которой они являются.

Матрица прав доступа

Сущность и действие	Супер администратор (super_admin)	Администратор организации (account_admin)	Пользователь организации (user)	Пользователь организации (reader)
Организации
создание	+	-	-	-
просмотр	+	+	+	+
изменение	+	+	-	-
удаление	+	+	-	-
просмотр списка	+	-	-	-
Пользователи
создание	+	+	-	-
просмотр	+	+	+¹	+¹
изменение	+	+	+¹	+¹
удаление/деактивация	+	+	-	-
изменение пароля	+	+	+¹	+¹
просмотр списка	+	+	-	-
Активы
создание	+	+	+	-
просмотр	+	+	+	+
изменение	+	+	+	-
удаление	+	+	+²	-
просмотр списка	+	+	+	+
просмотр истории аудитов	+	+	+	+
просмотр истории инвентаризаций	+	+	+	+
Группы активов
создание	+	+	+	-
просмотр	+	+	+	+
изменение	+	+	+	-
удаление	+	+	+²	-
просмотр списка	+	+	+	+
Результат аудита
просмотр	+	+	+	+
удаление	+	+	-	-
просмотр списка	+	+	+	+
просмотр изменений	+	+	+	+
Результат инвентаризации
просмотр	+	+	+	+
удаление	+	+	-	-
просмотр списка	+	+	+	+
просмотр изменений	+	+	+	+
Артефакт в задаче
просмотр	+	+	+	+
удаление	+	+	-	-
просмотр списка	+	+	+	+
Задача
создание	+	+	+³	+⁴
просмотр	+	+	+	+
изменение	+	+	+²	-
удаление	+	+	+²	-
просмотр списка	+	+	+	+
Результат задачи
просмотр	+	+	+	+
удаление	+	+	+²	-
просмотр списка	+	+	+	+
Результат действия в задаче
просмотр	+	+	+	+
удаление	+	+	+²	-
просмотр списка	+	+	+	+
Учетная запись
создание	+	+	+	-
просмотр	+	+	+	+
изменение	+	+	+²	-
удаление	+	+	+²	-
просмотр списка	+	+	+	-
проверка	+	+	+	-
Хранилище учетных записей
создание	+	+	-	-
просмотр	+	+	+	-
удаление	+	+	-	-
просмотр списка	+	+	+	-
Реестр образов
создание	+	+	+	-
просмотр	+	+	+	+
изменение	+	+	+²	-
удаление	+	+	+²	-
просмотр списка	+	+	+	+
API-токен
создание	+	+	-	-
просмотр	+	+	-	-
изменение	+	+	-	-
удаление	+	+	-	-
просмотр списка	+	+	-	-
Сервер авторизации
создание	+	+	-	-
просмотр	+	+	-	-
изменение	+	+	-	-
удаление	+	+	-	-
просмотр списка	+	+	-	-
Список исключений
создание	+	+	+	-
просмотр	+	+	+	+
изменение	+	+	+²	-
удаление	+	+	+²	-
просмотр списка	+	+	+	+
Теги
создание	+	+	+	-
просмотр	+	+	+	+
изменение	+	+	+	-
удаление	+	+	+	-
просмотр списка	+	+	+	+
Статус системы
просмотр	+	+	+	+
Статус обновлений
просмотр	+	+	+	+
Конфигурация системы
просмотр	+	-	-	-
изменение	+	-	-	-
перезагрузка	+	-	-	-

¹ - действие разрешается только с данными самого пользователя.
² - действие разрешается только с сущностями, созданными самим пользователем.
³ - кроме задач на обновление Агентов на Активах.
⁴ - кроме задач на обновление Агентов на Активах и установки обновлений на Активы.