Обзор StarVault 1.2, системы управления секретами и защиты доступа

1. Введение
2. Функциональные возможности StarVault 1.2
   1. 2.1. Управление секретами и их хранение
   2. 2.2. Управление сертификатами
   3. 2.3. Аутентификация пользователей
3. Архитектура StarVault 1.2
4. Системные требования StarVault 1.2
   1. 4.1. Требования к серверам StarVault с хранилищем на базе алгоритма Raft
   2. 4.2. Варианты развёртывания
5. Лицензирование StarVault 1.2
6. Сценарии использования StarVault 1.2
   1. 6.1. Миграция с HashiCorp Vault
   2. 6.2. Кейсы — основные причины перехода на StarVault
7. Выводы

Введение

Согласно оценкам компании «СТРИМ Консалтинг», объём российского ИТ-рынка по итогам 2024 года увеличился на 15%. Этот рост во многом связан с масштабированием инфраструктуры организаций, что напрямую влияет на рост количества так называемых «секретов» — различных учётных данных, необходимых для функционирования систем и приложений. К числу таких секретов относятся логины и пароли, ключи программных интерфейсов (API), ключи сертификатов серверов и клиентских сертификатов, а также ключи, используемые для подписи мобильных приложений.

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

Для решения перечисленных задач российская компания Orion soft разработала платформу StarVault — первый полноценный аналог иностранного решения HashiCorp Vault. Основой для её разработки послужила версия HashiCorp Vault 1.14.8, что позволило сохранить все возможности исходного продукта.

До августа 2023 года в составе продукта Nova Container Platform в качестве хранилища секретов вендор применял HashiCorp Vault. Однако после смены политики лицензирования компанией HashiCorp использование версий Vault, выпущенных после 1.14.8, стало недопустимо в продуктах, приносящих коммерческую выгоду. Это потребовало пересмотра архитектурных решений. В результате Orion soft принял решение о выделении StarVault в отдельный компонент. Сейчас вендор развивает его как самостоятельный продукт с учётом специфики российского рынка и требований заказчиков. 

StarVault соответствует требованиям по безопасному управлению секретами, изложенным в пункте 5.15 ГОСТ 56939-2024 («Разработка безопасного программного обеспечения»). Он легко интегрируется с GitLab / GitFlic и встраивается в существующие конвейеры CI / CD.

Таблица 1. StarVault в рамках ГОСТ Р 56939-2024

Система включена в реестр отечественного ПО (№ 22639 от 24.05.2024), как часть Nova Container Platform Special Edition имеет сертификат ФСТЭК России, а как отдельный продукт — на момент публикации обзора проходит такую сертификацию.

Функциональные возможности StarVault 1.2

StarVault — это отечественная система, ориентированная на использование в инфраструктурах с повышенными требованиями к контролю доступа и защите конфиденциальной информации. Она предназначена для централизованного безопасного хранения секретов, управления доступом к ним и ведения аудита. Поддерживается взаимодействие через графический пользовательский интерфейс, командную строку (CLI) и прикладной программный интерфейс (HTTP API).

Рабочий процесс взаимодействия с системой включает четыре последовательных этапа:

1. Аутентификация. Клиент инициирует запрос на аутентификацию, передавая идентификационные данные через один из поддерживаемых методов. На этом этапе StarVault определяет соответствие заявленной идентичности — проверяет подлинность, по результатам которой генерирует токен доступа. Полученный токен привязывается к политике, соответствующей заявленной идентичности.
2. Проверка. В качестве доверенных источников, на основе которых осуществляется проверка клиента, могут использоваться внешние системы — например, GitHub, LDAP, AppRole и другие. 
3. Авторизация. Каждый клиент ассоциируется с конкретной политикой безопасности, описывающей разрешённые действия и области доступа. Политики реализуют декларативный подход к управлению доступом, определяя, какие операции и на каких путях допустимы для конкретного токена. 
4. Доступ. После успешной авторизации клиент получает доступ к секретам, ключам и возможностям шифрования. Свой токен клиент может использовать и для будущих операций.

Продукт Orion soft решает задачи замещения HashiCorp Vault на отечественную разработку без потери функциональности.

Управление секретами и их хранение 

StarVault обеспечивает централизованное управление секретами в различных типах инфраструктур: локальных, облачных и гибридных. 

Секреты хранятся во встроенном хранилище, не зависящем от сторонних систем. Хранилище реализовано в отказоустойчивой конфигурации, поддерживает процессы резервного копирования и восстановления, а также шифрование данных с использованием алгоритма Advanced Encryption Standard (AES) с длиной ключа 256 бит.

Рисунок 1. Хранение секретов в StarVault 1.2

Рисунок 2. Конфигурации секретов в StarVault 1.2

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

Рисунок 3. Raft-хранилище в StarVault 1.2

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

Рисунок 4. Добавление механизма управления секретами в StarVault 1.2

Механизм Key-Value (KV) обеспечивает хранение произвольных секретов. KV версии 1 не поддерживает версионирование: хранит только одно значение для ключа. KV версии 2 поддерживает хранение нескольких версий ключа, их количество можно настраивать.

Рисунок 5. Выбор версии Key-Value в StarVault 1.2

Механизм PKI используется для генерации динамических сертификатов X.509. Он позволяет службам получать сертификаты без выполнения стандартной процедуры: самостоятельной генерации закрытого ключа, подготовки запроса на сертификат (CSR), отправки его в центр сертификации и ожидания результата подписания. 

Рисунок 6. Добавление механизма PKI в StarVault 1.2

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

Рисунок 7. Добавление механизма SSH в StarVault 1.2

Механизм Transit выполняет криптографические функции для данных в процессе передачи — шифрование / дешифрование данных без сохранения. Механизм также может подписывать и проверять данные, генерировать хэши и HMAC данных и выступать как источник случайных байтов.

Рисунок 8. Добавление механизма Transit в StarVault 1.2

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

Рисунок 9. Добавление механизма TOTP в StarVault 1.2

Механизм Kubernetes генерирует токены сервисных аккаунтов Kubernetes, создаёт сервисные аккаунты, привязки ролей и роли. Сгенерированные токены сервисных аккаунтов имеют настраиваемое время жизни, а все созданные объекты автоматически удаляются при истечении срока аренды в StarVault.

Рисунок 10. Добавление механизма Kubernetes в StarVault 1.2

StarVault поддерживает подключаемые бэкенды для генерации секретов по требованию. Такие механизмы могут взаимодействовать с внешними системами, включая PostgreSQL, RabbitMQ и другие базы данных и брокеры сообщений. По запросу они формируют учётные данные, необходимые для подключения, без хранения этих данных в статическом виде.

Управление сертификатами

Продукт Orion soft предоставляет инструменты для автоматизации процессов генерации и хранения SSL / TLS-сертификатов, ранее выполнявшихся вручную с использованием OpenSSL или специализированных фреймворков.

Рисунок 11. StarVault Browser CLI 

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

Рисунок 12. Редактирование политики в StarVault 1.2

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

Аутентификация пользователей

StarVault обеспечивает аутентификацию как часть обработки запроса. В большинстве случаев система делегирует администрирование и принятие решений об аутентификации соответствующему настроенному внешнему методу аутентификации — GitHub, Kubernetes, LDAP и другим системам.

Рисунок 13. Поддерживаемые StarVault 1.2 методы аутентификации

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

Рисунок 14. Настройка многофакторной аутентификации в StarVault 1.2

Рисунок 15. Настройка дополнительного уровня безопасности поверх существующих методов

Одно из последних обновлений — метод аутентификации «userpass-advanced», который позволяет пользователям аутентифицироваться, используя комбинацию имени пользователя и пароля. Он поддерживает:

• смену пользователем собственного пароля;
• установку флага принудительной смены пароля администратором;
• генерацию пароля по политике.

Методы аутентификации можно включать, отключать, настраивать и перемещать с помощью CLI, API или пользовательского интерфейса (UI): Kerberos доступен только через CLI и API, все остальное доступно и через UI в том числе.

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

Архитектура StarVault 1.2

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

Рисунок 16. Архитектура StarVault 1.2

Ключевым компонентом архитектуры является модуль шифрования, называемый барьером. Он обеспечивает шифрование всех данных, поступающих во внутреннее хранилище. Поскольку хранилище расположено вне зоны доверия (за барьером), шифрование применяется до момента записи, исключая возможность получения доступа к данным без их расшифровки StarVault. Таким образом, даже при компрометации хранилища его содержимое остаётся недоступным.

Инициализация сервера StarVault сопровождается переходом в запечатанное состояние (sealed state). В таком режиме операции невозможны до тех пор, пока система не будет распечатана (unsealed) — для этого необходимо предоставить ключи распечатки (unseal key).

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

Запросы к системе обрабатываются через HTTP API и направляются в ядро StarVault. Ядро отвечает за маршрутизацию, проверку прав доступа по спискам контроля доступа (Access Control List, ACL) и регистрацию операций в журнале аудита. До выполнения запросов клиент должен пройти процесс аутентификации.

Успешно прошедшему аутентификацию клиенту назначается набор политик — именованных правил ACL. Каждая политика определяет доступ к определённым путям в системе. Принцип работы основан на явном разрешении: отсутствие политики, явно разрешающей действие, трактуется как запрет. Политики централизованно хранятся и управляются через внутренний системный бэкенд, доступный по адресу «sys/».

На основании политик создаётся клиентский токен, используемый для выполнения последующих запросов. Токен может иметь срок действия, управляемый системой аренды. Если аренда не продлевается, соответствующие данные и доступы автоматически аннулируются. Этот механизм обеспечивает автоматическую ротацию и отзыв секретов без участия пользователя.

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

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

Системные требования StarVault 1.2

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

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

Требования к серверам StarVault с хранилищем на базе алгоритма Raft 

Рекомендации приведены для двух типовых размеров кластера. Малые (тестовые) кластеры подходят для большинства первоначальных производственных развёртываний или для сред разработки и тестирования. Большие (продуктивные) кластеры предназначены для производственных сред с постоянной высокой рабочей нагрузкой — большое число транзакций, секретов или их комбинаций.

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

Таблица 2. Требования к кластерам для одного узла (ноды)

Производительность ЦП, памяти и хранилища зависит от профиля использования: типов и частоты запросов, объёма данных в памяти. При использовании встроенного хранилища серверы StarVault должны иметь высокопроизводительную систему. Вендор рекомендует настраивать StarVault с включённым журналом аудита.

Задержка сети не должна превышать 8 мс для корректной синхронизации узлов кластера. Требования к пропускной способности зависят от характера нагрузки.

Таблица 3. Требования к сетевым подключениям

Весь связанный с StarVault сетевой трафик должен быть зашифрован на каждом сегменте. От клиентских машин к балансировщику нагрузки и от балансировщика нагрузки к серверам StarVault можно использовать стандартное шифрование HTTPS TLS. Для связи между серверами StarVault (порт 8201 по умолчанию), включая обмен информацией Raft, репликацию данных и пересылку запросов, StarVault автоматически согласовывает соединение mTLS через порт API (по умолчанию 8200) при добавлении новых серверов к кластеру.

Варианты развёртывания

Для развёртывания StarVault требуется операционная система семейства Linux (РЕД ОС, Astra Linux, AlmaLinux). Поддерживаются варианты установки в среде контейнерной оркестровки Kubernetes, в режиме высокой доступности (High Availability), а также установка в контейнерной среде и тестовом режиме.

Развернуть StarVault в Kubernetes можно при помощи официального Helm-чарта. Helm Charts не совместим с Helm 2, поэтому необходимо использовать Helm 3.6+ для работы с Helm Charts. Helm-чарт предоставляет возможность развёртывания StarVault в нескольких конфигурациях в зависимости от целей и среды эксплуатации:

• Dev — одиночный сервер StarVault, работающий в оперативной памяти. Используется для тестирования и ознакомления с функциональностью.
• Standalone — одиночный сервер StarVault, который сохраняет данные при помощи бэкенда хранилища (по умолчанию).
• High-Availability (HA) — кластерная конфигурация StarVault с использованием бэкенда хранения высокой доступности, к примеру Integrated Storage (Raft) (по умолчанию).

Развёртывание StarVault в режиме высокой доступности с использованием встроенного хранилища Raft требует наличия как минимум трёх серверов. При меньшем количестве узлов невозможно обеспечить кворум, что делает работу с хранилищем недоступной. 

StarVault использует встроенный механизм хранения Integrated Storage на базе алгоритма консенсуса Raft, обеспечивая синхронизацию состояния между узлами. Это гарантирует согласованность секретов и конфигураций даже в случае отказа одного из компонентов. При недоступности основного узла выполняется автоматическое переключение на резервный, без необходимости вмешательства администратора. 

Предварительные требования:

• На каждом сервере установлена поддерживаемая ОС.
• Пакет с дистрибутива StarVault скопирован на сервер.
• Для всех узлов Raft-кластера подготовлены сертификаты, а также сертификаты корневого центра сертификации.

Рисунок 17. HA-кластер StarVault

При установке в среде выполнения контейнеров (Docker, Podman) в зависимости от конкретной используемой среды необходимо установить соответствующий инструмент для управления многоконтейнерными приложениями — Docker Compose или Podman Compose.

Для запуска StarVault в тестовом режиме необходимо использовать команду «starvault server -dev». Сервер запустится без необходимости предварительной настройки. Локальный клиент StarVault CLI уже автоматически будет аутентифицирован и сможет взаимодействовать с сервером. Такой режим подходит для разработки, отладки и экспериментов. Использовать тестовый режим в продуктивной среде нельзя. В этом случае данные хранятся только в оперативной памяти и полностью удаляются при перезапуске.

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

Лицензирование StarVault основано на учёте количества клиентов, которые подразделяются на сущности и не-сущности. Сущности — это объекты с уникальной аутентификацией, такие как пользователи, сервисы, Kubernetes-кластеры и виртуальные машины с постоянным доступом. Не-сущности представляют подключения без явной аутентификации, включая временные токены, анонимные запросы и фоновые процессы. Рекомендуется регистрировать клиентов как сущности для повышения безопасности, упрощения аудита и более точного контроля лицензионных ограничений.

Предусмотрены лицензии на 100, 500, 1 000, 5 000 и 10 000 клиентов. Вендор рекомендует брать «с запасом» (до 20 %) для будущего масштабирования.

Бессрочная лицензия StarVault обеспечивает полную лицензионную чистоту и юридическую ответственность вендора перед заказчиками, как в России, так и за рубежом. Компания предоставляет техническую поддержку (расширенная — 24×7, базовая — 9×5, приобретается отдельно), гарантирует регулярное развитие продукта и выпуск обновлений, что позволяет безопасно размещать StarVault в продуктивных контурах. Клиенты имеют возможность влиять на развитие продукта: предложения пользователей анализируются и по мере возможности включаются в дорожную карту.

Сценарии использования StarVault 1.2

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

Рисунок 18. Сценарии использования StarVault

Интеграция с инфраструктурой каталогов. Рассмотрим на примере Active Directory. StarVault интегрируется с AD по протоколу LDAP, что позволяет синхронизировать пользователей и группы из домена со StarVault. Например, если все пользователи уже заведены в Active Directory, их учётные записи и структура могут быть перенесены в Vault. После настройки ролей и политик, при добавлении нового пользователя в AD, StarVault автоматически создаёт для него учётную запись, обеспечивая непрерывность управления доступом.

Интеграция с серверами приложений. Интеграция с серверами приложений в StarVault может быть реализована через механизм AppRole или путём использования токенов. Такой подход позволяет избежать хранения статических учётных данных в коде или конфигурационных файлах, снижая риск их компрометации. Дополнительно StarVault поддерживает динамическую генерацию временных учётных данных для систем управления базами данных, а также автоматическое обновление сертификатов для приложений с использованием PKI-модуля.

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

Аутентификация. В рамках модели аутентификации пользователи получают доступ к сервисам посредством StarVault. Все секреты централизованно хранятся в StarVault и выдаются в соответствии с назначенными ролями и политиками доступа. Процесс включает авторизацию пользователя через LDAP, после чего он получает токен доступа. Этот токен используется для получения необходимых секретов из StarVault, которые затем применяются для авторизации в целевых сервисах.

Миграция с HashiCorp Vault

Одним из ключевых сценариев внедрения StarVault является миграция с HashiCorp Vault. Поскольку ядро StarVault построено на базе HashiCorp Vault, процесс перехода упрощён и может быть реализован несколькими способами.

Полный перенос хранилища (Filesystem Storage Backend). С помощью встроенных возможностей Vault можно мигрировать весь бэкенд, включая секреты и конфигурации, без потери данных и необходимости их переформатирования.

Использование встроенного хранилища на основе алгоритма консенсуса Raft (Integrated Storage (Raft) Backend). Система Orion soft поддерживает создание снимков (снапшотов), что удобно при использовании бэкенда Raft. Пользователь создает снимок текущего состояния HashiCorp Vault и восстанавливает его в StarVault. Также предусмотрена интеграция с существующими базами данных, такими как PostgreSQL, что позволяет использовать встроенные средства миграции СУБД для минимизации простоя и обеспечения бесшовного перехода.

StarVault Shuttle. Для упрощения и ускорения процесса миграции вендором разработан специализированный модуль — StarVault Shuttle. Он позволяет переносить секреты из исходного хранилища в StarVault за считанные секунды. Например, миграция 100+ секретов занимает две секунды. Миграцию через StarVault Shuttle можно осуществлять как через командную строку (CLI), так и через веб-интерфейс. 

Модуль обеспечивает экспорт секретов из исходного Vault и их последующий импорт в StarVault с сохранением целостности данных. Встроенные механизмы обработки ошибок и ведения журналов повышают надёжность процесса миграции, а использование защищённого протокола HTTPS гарантирует безопасность передачи данных.

Рисунок 19. Завершение миграции секретов при помощи StarVault Shuttle

Кейсы — основные причины перехода на StarVault

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

Импортозамещение в нефтегазохимическом секторе. К вендору обратилась крупная нефтегазохимическая компания со следующим запросом — заменить HashiCorp Vault в рамках политики импортозамещения. Переход на отечественное решение был выполнен за три недели и без потерь в функциональности. Все используемые ранее возможности были сохранены, но уже в рамках российского продукта. Продукт Orion soft предоставил необходимую функциональность, сопоставимую с возможностями зарубежного решения, что обеспечило непрерывность процессов и сохранность механизмов управления доступом и защитой данных.

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

StarVault позволил полностью устранить лицензионные риски, обеспечив выполнение всех требований по лицензионной чистоте, при этом сохранив необходимый уровень функциональности для управления секретами в масштабной распределённой инфраструктуре.

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

Выводы

StarVault 1.2 реализует комплексное управление секретами и доступом к ним с учётом требований нормативных документов, включая пункт 5.15 ГОСТ 56939-2024. Продукт обеспечивает отказоустойчивость и масштабируемость, а также интегрируется с существующими системами и инфраструктурами. Для обеспечения безопасности системы вендор использует комплекс мер безопасной разработки: анализ исходного кода, антивирусная проверка дистрибутивов, регулярный поиск уязвимостей.

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

Достоинства:

• Поддержка популярных ядер обработки секретов (secrets engines).
• Организация PKI.
• Поддержка OIDC и прочих методов аутентификации.
• Упрощённая миграция с HashiCorp Vault.
• Миграция 100+ секретов за две секунды.
• Поддержка конфигурации высокой доступности. При недоступности основного узла выполняется автоматическое переключение на резервный, без необходимости вмешательства администратора. 
• Бессрочная лицензия.
• Расширенная техническая поддержка в круглосуточном и ежедневном режиме.
• Возможность влияния на дорожную карту развития продукта.
• Входит в реестр отечественного ПО.

Недостатки:

• Использовать тестовый режим в продуктивной среде нельзя. 
• Для развёртывания поддерживаются только ОС семейства Linux.
• Не сертифицирован ФСТЭК России (сертификат находится в процессе получения, ожидается в первой половине 2026 г.). На данный момент можно приобрести Nova Container Platform Special Edition, в которую встроен StarVault; эта платформа имеет сертификат ФСТЭК России.