OPEN DEMO BASIS VIRTUAL SECURITY 4.1. ОТВЕТЫ НА ВОПРОСЫ

Насколько мандатный контроль целостности дисков ВМ влияет на нагрузку? Какой оверхед для большого кластра (100+ узлов) и какой механизм работы? Влияет ли профиль нагрузки в самой ВМ (например транзакционная БД под биллингом)?

Минимальные требования в эксплуатационной документации к аппаратным ресурсам принципиально не изменились. Контроль целостности реализован на нескольких уровнях: для конфигурации ВМ проверяются контрольные суммы XML-описания виртуального оборудования при каждом запуске; для файловой системы гостевых ОС рассчитываются контрольные суммы файлов и каталогов согласно политикам; для вычислительных узлов контролируется целостность конфигурации оборудования и ФС. Эталонные значения хранятся в БД BVS, при несоответствии запуск блокируется и событие фиксируется в журнале безопасности. Фактическая нагрузка зависит от количества проверяемых файлов, частоты проверок и профиля нагрузки ВМ. Важно отметить, что для кластеров 100+ узлов рекомендуется пилотное тестирование на конкретной конфигурации.

Для детального ответа, применительно к конкретной инфраструктуре свяжитесь с нами для проработки кейса: support@basis.ru в теме письма укажите Open Demo BVS 4.1

VNF игнорируют квоты ресурсных групп. Умеет ли BVS 4.1 контролировать ресурсы VNF device?

Ресурсы VNF возможно контролировать на стороне DXE. Со стороны BVS необходима доработка для поддержки механизмов контроля целостности конфигурации ВМ с vyos.

Запрос на изменение можно направить: support@basis.ru в теме письма укажите Open Demo BVS 4.1

Разве проверка целостности конфигураций и контейнеров не выполняется средствами Basis Digital Energy? Или этот функционал переносится в BVS 4.1?

Проверка целостности конфигураций и контейнеров поддерживается в обоих продуктах. В рамках проектирования необходимо определить, в каком продукте будет выполняться контроль.

Проверка КЦ это проверка yaml-манифестов? Можно раскрыть подробнее этот момент?

Да, в части спецификации подов. В части контроля изменений ресурсов выполняется перехват вызовов к API k8s с применением политики через механизм mutate.

Подскажите пожалуйста когда планируется сертификация?

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

Будет ли возможность обновления с 4.0.1 до 4.1?

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

Если Kyverno уже есть в кластере, то при подключении к вашему продукту отобразятся ли существующие политики Kyverno и в каком они режиме находятся (аудит/энфорс)?

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

Какой механизм используется для проверки целостности?

Контроль целостности в BVS реализован на нескольких уровнях. Для конфигурации виртуальных машин проверяются контрольные суммы XML-описания виртуального оборудования (диски, сетевые интерфейсы, параметры CPU/RAM и т.д.) при каждом запуске ВМ. Для файловой системы гостевых ОС рассчитываются контрольные суммы файлов и каталогов согласно заданным политикам целостности. Для вычислительных узлов контролируется целостность конфигурации оборудования и файловой системы. Эталонные значения хранятся в базе данных BVS, при несоответствии запуск блокируется, а событие фиксируется в журнале безопасности.

Вы перенесли функционал Basis Digital Energy в BVS?

Функционал не переносился, а поддерживается в обоих продуктах, так как оба продукта удовлетворяют требованиям приказа ФСТЭК по защите средств контейнеризации. При совместном использовании продуктов в рамках проектирования необходимо определить, в каком продукте будет выполняться контроль.

Расскажите про самые логичные сценарии применения Basis Dynamix и BVS? На чем лучше сконцентрироваться при применении в первую очередь?

Наиболее логичными сценариями для Basis Dynamix являются управление жизненным циклом ВМ, в том числе создание, миграция, клонирование, управление дисками и образами, работа с ресурсными группами и квотами. Продукт ориентирован на администраторов виртуализации. Для Basis Virtual Security — обеспечение информационной безопасности виртуальной инфраструктуры, в том числе аутентификация (включая 2FA), разграничение доступа, доверенная загрузка и контроль целостности конфигураций ВМ и гостевых ФС, сетевая фильтрация, регистрация событий безопасности, соответствие требованиям регуляторов. При совместном применении Basis Dynamix предоставляет функциональность управления жизненным циклом виртуальных машин и данных, которые ВМ обрабатывают, а BVS — защиту этой функциональности и контроль соблюдения политик безопасности.

Что из BVS может упростить жизнь команде эксплуатации? (Что-то нужно настроить?) Чем станет легче?

BVS упрощает эксплуатацию за счёт: централизованного управления правилами сетевой фильтрации для всех ВМ и хостов из одного интерфейса; единого окна для контроля целостности конфигураций ВМ и гостевых ФС с возможностью принятия эталонных значений; централизованного аудита событий безопасности (все события собираются в OpenSearch); автоматического контроля конфигураций Kubernetes (в v4.1) — политики Kyverno и контроль целостности узлов/подов без ручной проверки; интеграции с внешними системами аутентификации (LDAP, OIDC, ЕСИА) — не нужно заводить пользователей в каждом продукте отдельно.

Каким образом настраиваются политики безопасности и разграничения доступа внутри виртуальной среды? На уровне виртуальных машин и виртуальных сетей?

BVS обеспечивает разграничение доступа на уровне управления виртуальной инфраструктурой: назначение ролей пользователям (администратор безопасности, администратор системы, пользователь), настройку сетевых фильтров и политик целостности. Внутри гостевых ОС разграничение доступа реализуется средствами самой ОС. Сетевая фильтрация применяется на уровне гипервизора (nwfilter, Open vSwitch) и управляется через UI BVS. Все настройки выполняются в едином веб-интерфейсе с ролевой моделью.

Что такое Kyverno, который вы все называете?

Kyverno — это контроллер для k8s, который позволяет управлять конфигурацией и безопасностью кластера через политики как код.

Поддерживается ли проверка DaemonSet/Deployment? Какие registry поддерживаются?

Нет, в версии 4.1 контроль указанных объектов не поддерживаются, но это в планах на следующий релиз. В плане поддерживаемых регистри - BVS работает с любыми OCI-compliant registry.

Расскажите про функционал виртуальной сетевой фильтрации (виртуальные МЭ на уровне гипервизора), изоляции виртуальных сетей и применения политик безопасности, которые предотвращают утечку или несанкционированный доступ к данным между изолированными сегментами.

Стоит сразу отметить, что BVS не позиционируется как система предотвращения вторжений, а выступает в качестве системы управления правилами межсетевого экранирования и системы контроля целостности ВМ, хостов и ресурсов kubernetes. Правила сетевой фильтрации настраиваются в UI, их назначение возможно на хосты, ВМ или группы указанных объектов. Правила применяются без необходимости перезапуска ВМ или узлов. Детальнее процесс описан в документации.

Насколько увеличились требования по RAM и CPU в новой версии?

Базовые требования не изменились. Но крупные проекты и масштабные инсталляции требует архитектурной проработки. Если у Вас планируется сотни гипервизоров и значительное количество виртуальных машин, то рекомендуем обратиться в пресейл или Professional Services компании "Базис" за консультацией: support@basis.ru в теме письма укажите Open Demo BVS 4.1

SBOM собирается? Можно ли его посмотреть в интерфейсе?

Отчёт об уязвимостях создаётся для всех образов в реестре. Формирование полноценного SBOM (Software Bill of Materials) в явном виде сейчас продуктом не формируется. Возможно, что данная функциональность появится в следующем году.

Сколько ресурсов может контролировать одна инсталляция BVS, со включенными параметрами безопасности КЦ?

Фактические требования к ресурсам могут отличаться в зависимости от количества задач и объёма проверяемых данных в проверках КЦ, особенно для контроля гостевой ФС. Требования к ресурсам агента и контроллера BVS указаны в руководстве по установке в разделе 3.2 "Минимальные требования к аппаратному обеспечению для функционирования программного модуля «Basis Virtual Security»".

Кто будет постоянно кликать "принять конфигурацию или изменения" для сотен подов в кубовом кластере, где постоянно меняются ресурсы, их метаданные?

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

Для соответствия Digital Energy формуляру ФСТЭК обязательно наличие BVS в окружении?

Basis Digital Energy и Basis Virtual Security сертифицированы как отдельные продукты. Для соответствия формуляру ФСТЭК на Digital Energy наличие BVS в окружении не обязательно — Digital Energy имеет собственный сертификат и встроенные механизмы безопасности (RBAC, SSO, валидация политик, управление сертификатами). Однако при совместном использовании BVS обеспечивает дополнительный уровень защиты виртуальной инфраструктуры, на которой развёрнут Digital Energy. Для аттестации конкретной информационной системы необходимо руководствоваться требованиями к классу защищённости и моделью угроз конкретного объекта.

Как отрабатывает целостность при горизонтальном масштабировании кластера, например, при добавлении "воркер ноды" в существующий кластер?

В политиках Kyverno возможно назначение на кластер. В политиках целостности назначение только на узел.

Совмещение узлов (BVS + DX) и, следственно, эксплуатационных отделов это плохая или хорошая практика? Использование на виртуальных машинах в том же кластере хороший подход?

Совмещение BVS и DX на одних узлах — архитектурный антипаттерн с точки зрения ИБ по следующим причинам: средство защиты (BVS) размещается в том же контуре, который оно должно защищать; администратор платформы (DX) получает потенциальную возможность повлиять на работу средства защиты; нарушается принцип разделения зон ответственности. Рекомендуемая архитектура (в порядке убывания предпочтительности): 1) отдельные физические узлы для контроллеров BVS; 2) контроллеры BVS в виде ВМ вне контролируемого контура виртуализации; 3) контроллеры BVS в виде ВМ на контроллерных нодах DX (допустимо, но менее предпочтительно); 4) контроллеры BVS как нативные сервисы на контроллерах DXE (крайне не рекомендуется); 5) контроллеры BVS в виде ВМ на контролируемой платформе виртуализации (недопустимо).

Basis Virtual Security поддерживает OpenID Connect и LDAP, можно ли им заменить KeyCloack для организации SSO для uStor?

Да, в BVS поддерживаются стандарты OIDC и LDAP. Интеграция возможна, но вопрос требует тестирования c конкретной версией uStor.

Когда BVS 4.1 выйдет на рынок, когда можно получить его дистрибутив?

31 октября 2026.

Правильно понимаю, что происходит проверка audit log подключаемого кластера? К каким кластерам можно подключаться (ваниль / коммерческие / microk8s)?

BVS не выполняет проверку audit log кластера Kubernetes в классическом понимании (журналы аудита API-сервера). Вместо этого BVS отслеживает состояние, метаданные и спецификации узлов и подов кластера через Kubernetes API, контролирует соответствие конфигурации эталонному состоянию, управляет политиками Kyverno, которые применяются к ресурсам кластера, осуществляет сканирование реестров и образов контейнеров на уязвимости. Подключение к кластерам выполняется через аутентификацию на основе сертификатов X.509. Поддерживаются любые OCI-compliant реестры.

Будет ли добавлена установка из интерактивной формы образа VCore на один узел (не в кластерном исполнении)?

Установка vCore на один узел уже поддерживается в режиме демонстрационной инсталляции, описанная в "Руководстве по установке vCore", а дистрибутив BVS предоставляется в оффлайн ISO-образе vCore Hyper, включающем компоненты управляющей и вычислительной части Basis Virtual Security. Для продуктивного использования в режиме без высокой доступности данная возможность также доступна, однако для промышленной эксплуатации крайне рекомендуется кластерная конфигурация (минимум 3 узла) для обеспечения отказоустойчивости. Упрощение процедуры установки в рамках одного хоста через интерактивный интерфейс vCore не рассматривается в ближайщих релизах.

С какими версиями vCore совместим BVS 4.1? И как проходит процесс обновления со старых версий? Поддерживается ли ОС Астра SE?

BVS 4.1 в части vCore совместим только с версией 2.1. Возможно пакетное обновление на уровне vCore. Для Astra Linux Special Edition версии не ниже 1.7.11; Astra Linux Special Edition версии не ниже 1.8.6; Альт 8 СП (релиз 10) версии не ниже 10.2.2.

Какие изменения в BVS 4.1 Вы считаете действительно прорывными, а какие скорее эволюционными? Кратко.

Прорывные изменения: поддержка контроля Kubernetes — BVS 4.1 впервые позволяет управлять безопасностью контейнерной инфраструктуры (кластеры, узлы, поды, политики Kyverno, реестры образов) из единого окна; контроль целостности конфигураций Kubernetes — автоматическое отслеживание изменений в узлах и подах с возможностью принятия эталона.

Эволюционные изменения: расширение поддержки контроля целостности для SDS (DES, vfStorage); улучшения в существующих механизмах аутентификации и разграничения доступа.

Какая установка больше приветствуется: совмещённая на управляющих узлах DX или же BVS kexit разворачивать на отдельные ВМ или же на отдельную железку в случае аппаратного исполнения?

В порядке убывания предпочтительного способа развертывания и в порядке возрастания рисков: 1) отдельные физические узлы для контроллеров BVS; 2) контроллеры BVS в виде ВМ вне контролируемого им контура ПВ; 3) контроллеры BVS в виде ВМ на контроллерных нодах DX; 4) контроллеры BVS как нативные сервисы на контроллерах DXE (внеплатформенные ВМ) с автозапуском; 5) контроллеры BVS в виде ВМ на контролируемой ПВ.

Планируется ли упрощение установки BVS из образа VCore в кластерном исполнении?

Инсталляция через конфигуратор vCore представляет самый простой способ развертывания кластера BVS в режиме высокой доступности. В следующих релизах vCore Configurator планируется упрощение процедуры обновления уже развёрнутого кластера BVS и другие административные операции над кластером для упрощения администрирования и сопровождения жизненного цикла управляющих узлов.