Руководство администратора
Список обозначений
- Система - развернутое и работающее в сети заказчика решение "Vulns.io Enterprise VM"
- Актив - компьютер, сервер, виртуальная машина, гипервизор или сетевое устройство, мониторинг которого ведется с помощью Системы.
- Агент - программа, устанавливаемая на Актив, для обеспечения его сканирования в агентном режиме.
- Кабинет - основной web-интерфейс системы для работы пользователей.
- Лицензия - право на использование продукта на заданный срок с оговоренными ограничениями и функционалом.
- Ключ лицензии - буквенно-цифровой код для идентификации активированной лицензии.
- БДУ - база данных уязвимостей, на основе которой производится сканирование Активов.
Архитектура решения
Архитектурно Vulns.io Enterprise VM является on-premise решением на физическом или виртуальном сервере, работающим в сети и на мощностях заказчика:
Система в сети заказчика
Компоненты системы
Описание компонентов Системы в соответствие элементам, указанным на схеме взаимодействия.
Сервисы, работающие в Системе:
- mongodb - Main DB - хранение информации об активах, результатах сканирования, БДУ и пр.,
- redisdb - Cache DB - очередь задач,
- worker-main - Workers - выполнение задач аудита и инвентаризации активов в Системе,
- worker-images-scanner - Workers - выполнение задач аудита и инвентаризации docker-образов (на хостах и в docker registry),
- worker-reports - Workers - генерация отчетов,
- logrotate - Workers - менеджер лог-файлов всех компонентов системы,
- data-updater - Updater - запрос обновлений БДУ с Vulns.io Cloud и обновление локальной БДУ,
- nginx - Reverse proxy - поддержка SSL, ограничение сетевого доступа,
- centrifugo - Websocket server - поддержка двусторонней связи с Агентами,
- cli - vio-cli - утилита командной строки, хранение исполняемого файла vio-cli и docker-сompose, используется при установке системы и обновлении на новую версию,
- vault - Vault - хранилище учетных записей,
- vault-init - Vault - инициализация хранилища в системе (подключение к vault),
- frontend - Не указан как явный компонент - хранилище статистических файлов веб-интерфейса Системы,
- api-server - Не указан как явный компонент - менеджер API-запросов, создает задачи для соответствующих воркеров на основе входящих запросов.
Представление активов заказчика в качестве компонентов Системы:
- Asset with Agent - целевой актив с установленным агентом (физический/виртуальный хост)
- vulns.io_agent - Agent - выполнение всех соответствующих типов задач на linux-активах/windows-активах,
- Asset without Agent - целевой актив без агента (хост, сетевое устройство).
Web-сервисы, работающие на стороне вендора Vulns.io:
- облачное API - для получения списка файлов обновлений,
- сервер обновлений - для скачивания файлов обновлений БД уязвимостей,
- сервер лицензирования - для проверки лицензии Системы,
- реестр docker-контейнеров - для получения обновлений docker-контейнеров.
Схема взаимодействия компонентов Системы
Требования к серверу и ОС
- физический сервер или виртуальная машина с поддержкой AVX-инструкций,
- любой linux-дистрибутив, поддерживающий:
- Docker 19.03.13+,
- Docker Compose V1 1.29.0+ или Docker Compose V2 2.8.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 | Количество хранимых ранее использованных пользователем паролей для проверки их уникальности |
| jwt_secret | JWT-ключ |
| ssh_timeout | Таймаут SSH-сокета (с) |
| ssh_ready_timeout | Таймаут завершения SSH handshake (при подключении) (с) |
| ssh_connection_retry_delay | Период ожидания между попытками подключения (с) |
| winrm_timeout | Таймаут при подключении по WinRM (с) |
| pdf_render_timeout | Таймаут рендеринга PDF (с) |
| api_key_salt | Соль API ключа |
| user_task_timeout | Таймаут выполения задачи пользователя (мс) |
| agent_queue_job_timeout | Таймаут ожидания задачи агента в очереди (мс) |
| task_sentinel_cron | Период проверки статусов пользовательских задач |
| [log] | |
| level | Уровень системного логирования (для логов в /opt/vulns.io/onpremise/logs/*): info|verbose|debug |
| [log.file] | |
| enabled | Включена/отключена запись в файл (true/false) |
| level | Уровень логирования сообщений в файл: info|verbose|debug |
| [log.db] | |
| enabled | Флаг включения логирования сообщений приложения в БД (true/false) |
| [log.db.system] | |
| level | Уровень логирования системных сообщений приложения в БД: info|verbose|debug |
| [log.db.task] | |
| level | Уровень логирования задач приложения в БД: info|verbose|debug |
| [log.db.user] | |
| level | Уровень логирования действий пользователей приложения в БД: info|verbose|debug |
| [data-updater.scheduler] | |
| cron | Расписание проверки каналов обновлений (в формате CRON) |
| cron_type | Тип механизма периодической проверки: cron |
| [data-updater.subscriptions] | |
| channels | Каналы обновления |
| [data-updater.other] | |
| mongodb_bulkwrite_size | Обновлять данные в БД пачками по |
| disable_mongodb_index_creation | Флаг отключения создания индексов в MongoDb для обновления данных (true/false) |
| disable_agent_channel | Флаг отключения канала обновления агентов (true/false) |
| [smtp.sender] | |
| name | Имя отправителя в исходящих письмах |
| 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") см. полный список |
| [http.client] | |
| request_logging | Включает логирование запросов |
| response_logging | Включает логирование ответов |
| request_timeout | Таймаут запроса к почтовому серверу |
| tls_reject_unauthorized | Разрешить/запретить отклонять неавторизованные запросы (true/false) |
| [mongodb] | |
| mongodb_ip | Адрес подключения к MongoDB |
| mongodb_port | Порт подключения к MongoDB |
| mongodb_auth_database | Имя базы данных аутентификации MongoDB |
| mongodb_user | Имя пользователя Mongodb |
| mongodb_password | Пароль для подключения к Mongodb |
| [redis] | |
| redis_password | Пароль для подключения к Redis |
| redis_ip | Адрес подключения к Redis |
| redis_port | Порт подключения к Redis |
| [centrifugo.api] | |
| protocol | Протокол Centrifugo API |
| host | Адрес подключения к хосту Centrifugo API |
| port | Порт подключения к хосту Centrifugo API |
| apiKey | API-ключ подключения к Centrifugo |
После изменения параметров в конфигурационном файле необходимо перезапустить Систему командой:
/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 накопителей.
- увеличение количества ядер CPU сервера и количества воркеров
-
Горизонтальное масштабирование:
- запуск Системы на нескольких серверах с помощью оркестрации 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иvault-initявляется нормальным состоянием для этих сервисов.
Возможные статусы сервисов:
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
stats mongodb
Отображает размера частей БД, составляющих архивные данные, логи и итоговый размер:
vio-cli stats mongodb
clear logs [--type, --date]
Удаляет данные логов из БД:
- запуск без параметров удаляет данные логов задач старше 24 часов,
- --type указывает, какой тип логов необходимо удалить (по умолчанию task):
- task - логи, созданные при выполнения задач,
- system - прочие логи, созданные Системой,
- --date указывает момент времени, до которого необходимо удалить логи.
vio-cli clear logs —date 2024-01-01T00:00:00Z —type task
backup
Создает бэкап основной БД и/или конфигурационных файлов c последующим созданием архива /opt/vulns.io/onpremise/backup_YYYY-MM-DD.tar.gz.
mongodb
Процесс бэкапа происходит без полной остановки контейнера mongodb. Возможно потеря некоторых "свежих" данных.
С помощью mongodump создается бэкап основной БД MongoDB (без индексов, БДУ и системной Auth БД). Файл бэкапа сохраняется как /opt/vulns.io/onpremise/backup/mongodb/backup_onprem_YYYY-MM-DD.gzip.
vio-cli backup mongodb
configs
Архивируется и сжимается директория /opt/vulns.io/onpremise/config и лежащие в ней файлы. Файл бэкапа сохраняется как /opt/vulns.io/onpremise/backup/configs/configs_YYYY-MM-DD.tar.gz.
vio-cli backup configs
all
Запускается процесс бэкапа всех выше перечисленных сервисов и файлов.
vio-cli backup all
restore backup
Восстанавливает бэкап из переданного файла.
Аргумент file_path может быть общим бэкапом (backup_*.tar.gz), бэкапом основной БД (backup_onprem_*.gzip) или бэкапом конфигурационных файлов (configs_*.tar.gz).
vio-cli backup restore ./backup_2024-08-08.tar.gz
Важные примечания:
- Процесс восстановления любого вида бэкапа полностью останавливает все сервисы продукта Vulns.io Enterprise VM.
- Если в архиве найдется бэкап основной БД, то бэкап полностью перезапишет текущую основую БД.
- Если в архиве найдется бэкап конфигурационных файлов, то бэкап полностю перезапишет текущую директорию
/opt/vulns.io/onpremise/config, но сохранит текущие учетные записи и пароли (credentials) текущих сервисов, текущую лицензию.
ПРИЛОЖЕНИЕ 1. Ролевая модель: матрица прав доступа
Для пользовательских ролей Системы определены следующие правила:
- разрешительные действия пользователей с ролью "Суперадминистратор" (super_admin) применимы к любой сущности любой организации,
- разрешительные действия пользователей с ролями "Администратор организации" (account_admin), "Пользователь организации" (user) и "Пользователь организации (чтение)" (reader) применимы только к сущностям организации, членами которой они являются.
Матрица прав доступа
| Сущность и действие |
Супер администратор (super_admin) |
Администратор организации (account_admin) |
Пользователь организации (user) |
Пользователь организации (reader) |
|---|---|---|---|---|
| Организации | ||||
| создание | + | - | - | - |
| просмотр | + | + | + | + |
| изменение | + | + | - | - |
| удаление | + | + | - | - |
| просмотр списка | + | - | - | - |
| Пользователи | ||||
| создание | + | + | - | - |
| просмотр | + | + | +1 | +1 |
| изменение | + | + | +1 | +1 |
| удаление/деактивация | + | + | - | - |
| изменение пароля | + | + | +1 | +1 |
| просмотр списка | + | + | - | - |
| Активы | ||||
| создание | + | + | + | - |
| просмотр | + | + | + | + |
| изменение | + | + | + | - |
| удаление | + | + | +2 | - |
| просмотр списка | + | + | + | + |
| просмотр истории аудитов |
+ | + | + | + |
| просмотр истории инвентаризаций |
+ | + | + | + |
| Группы активов | ||||
| создание | + | + | + | - |
| просмотр | + | + | + | + |
| изменение | + | + | + | - |
| удаление | + | + | +2 | - |
| просмотр списка | + | + | + | + |
| Результат аудита | ||||
| просмотр | + | + | + | + |
| удаление | + | + | - | - |
| просмотр списка | + | + | + | + |
| просмотр изменений | + | + | + | + |
| Результат инвентаризации |
||||
| просмотр | + | + | + | + |
| удаление | + | + | - | - |
| просмотр списка | + | + | + | + |
| просмотр изменений | + | + | + | + |
| Артефакт в задаче | ||||
| просмотр | + | + | + | + |
| удаление | + | + | - | - |
| просмотр списка | + | + | + | + |
| Задача | ||||
| создание | + | + | +3 | +4 |
| просмотр | + | + | + | + |
| изменение | + | + | +2 | - |
| удаление | + | + | +2 | - |
| просмотр списка | + | + | + | + |
| Результат задачи | ||||
| просмотр | + | + | + | + |
| удаление | + | + | +2 | - |
| просмотр списка | + | + | + | + |
| Результат действия в задаче |
||||
| просмотр | + | + | + | + |
| удаление | + | + | +2 | - |
| просмотр списка | + | + | + | + |
| Учетная запись | ||||
| создание | + | + | + | - |
| просмотр | + | + | + | + |
| изменение | + | + | +2 | - |
| удаление | + | + | +2 | - |
| просмотр списка | + | + | + | - |
| проверка | + | + | + | - |
| Хранилище учетных записей |
||||
| создание | + | + | - | - |
| просмотр | + | + | + | - |
| удаление | + | + | - | - |
| просмотр списка | + | + | + | - |
| Реестр образов | ||||
| создание | + | + | + | - |
| просмотр | + | + | + | + |
| изменение | + | + | +2 | - |
| удаление | + | + | +2 | - |
| просмотр списка | + | + | + | + |
| API-токен | ||||
| создание | + | + | - | - |
| просмотр | + | + | - | - |
| изменение | + | + | - | - |
| удаление | + | + | - | - |
| просмотр списка | + | + | - | - |
| Сервер авторизации | ||||
| создание | + | + | - | - |
| просмотр | + | + | - | - |
| изменение | + | + | - | - |
| удаление | + | + | - | - |
| просмотр списка | + | + | - | - |
| Список исключений | ||||
| создание | + | + | + | - |
| просмотр | + | + | + | + |
| изменение | + | + | +2 | - |
| удаление | + | + | +2 | - |
| просмотр списка | + | + | + | + |
| Теги | ||||
| создание | + | + | + | - |
| просмотр | + | + | + | + |
| изменение | + | + | + | - |
| удаление | + | + | + | - |
| просмотр списка | + | + | + | + |
| Статус системы | ||||
| просмотр | + | + | + | + |
| Статус обновлений | ||||
| просмотр | + | + | + | + |
| Конфигурация системы | ||||
| просмотр | + | - | - | - |
| изменение | + | - | - | - |
| перезагрузка | + | - | - | - |
- 1 - действие разрешается только с данными самого пользователя.
- 2 - действие разрешается только с сущностями, созданными самим пользователем.
- 3 - кроме задач на обновление Агентов на Активах.
- 4 - кроме задач на обновление Агентов на Активах и установки обновлений на Активы.