Обзор Deckhouse Stronghold 1.16 для безопасного управления жизненным циклом секретов

1. 1. Введение
2. 2. Функциональные возможности Deckhouse Stronghold 1.16
   1. 2.1. Ролевая модель доступа
   2. 2.2. Базовые возможности
   3. 2.3. Возможности уровня HashiCorp Vault Enterprise
      1. 2.3.1. Пространство имён (namespaces)
      2. 2.3.2. Шифрование данных с помощью HSM (в том числе и с алгоритмами ГОСТ)
      3. 2.3.3. ГОСТ TLS
      4. 2.3.4. Автоматические бэкапы
      5. 2.3.5. Репликация данных
      6. 2.3.6. Динамические секреты
   4. 2.4. Использование Deckhouse Stronghold для выполнения требований ГОСТ 56939-2024
   5. 2.5. Обеспечение безопасности
3. 3. Архитектура Deckhouse Stronghold 1.16
4. 4. Системные требования Deckhouse Stronghold 1.16
5. 5. Лицензирование Deckhouse Stronghold 1.16
6. 6. Сценарии использования Deckhouse Stronghold 1.16
   1. 6.1. Примеры кейсов использования
   2. 6.2. Особенности миграции с HashiCorp Vault на Deckhouse Stronghold
7. 7. Выводы

Введение

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

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

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

Неправильное обращение с данными оборачивается не только утечками и взломами, но и значительными финансовыми и репутационными потерями. По данным ЭАЦ InfoWatch, средний ущерб от утечки информации достигает в среднем 11,5 млн рублей, а по максимальным оценкам пострадавших организаций — более 41 млн.

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

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

Наиболее безопасным подходом считается использование отдельного хранилища секретов, централизованно управляющего их жизненным циклом. Компания «Флант» переосмыслила концепцию хранения секретов и предоставила удобный и безопасный инструмент для современных российских DevOps- и ИТ-инфраструктур — Deckhouse Stronghold. Решение защищает пароли, ключи API, сертификаты, SSH-ключи, токены и другие конфиденциальные данные от утечек и обеспечивает безопасную доставку секретов в приложения.

ПО Deckhouse Stronghold включено в реестр российского ПО (№ 22339 от 24.04.2024), сертифицировано ФСТЭК России (№ 5038 от 10.02.2026).

Функциональные возможности Deckhouse Stronghold 1.16

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

• Клиент (приложение, сервис, пользователь) через Stronghold или внешнюю систему подтверждает, что обращается именно он.
• Система анализирует запрос, можно ли предоставить доступ к запрошенному секрету.
• Если доступ есть, операция по чтению или записи секрета разрешается.
• Если доступа нет — операция отклоняется.

Рисунок 1. Принцип работы Deckhouse Stronghold

Управление Deckhouse Stronghold осуществляется через API, Stronghold CLI и веб-интерфейс. Веб-интерфейс поддерживает светлую и тёмную темы, русский и английский языки. Руководство пользователя и другая техническая документация по продукту не встроена в систему.

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

Ролевая модель доступа

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

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

Рисунок 2. Создание политики на чтение и просмотр данных

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

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

При необходимости восстановление административного доступа может быть реализовано через механизм кворума. При инициализации Deckhouse Stronghold создаёт зашифрованное хранилище, а ключ шифрования разделяется на несколько частей. Для повторного выпуска административного токена требуется собрать установленный кворум recovery-ключей или shamir-ключей. Они хранятся у разных ответственных лиц, что исключает возможность компрометации или изменения политик одним человеком и снижает риски при утечке отдельных административных секретов.

Базовые возможности

В России Vault доступен только в редакции Community Edition (CE) и распространяется по проприетарной лицензии Business Source License (BSL), что существенно ограничивает допустимые сценарии его использования. Во всех редакциях Deckhouse Stronghold, включая бесплатную, реализованы базовые возможности Vault CE, которых достаточно для решения типовых задач управления секретами:

• безопасное управление жизненным циклом секрета (хранение, создание, передача, отзыв и ротация);
• резервное копирование;
• поддержка и настройка разных методов аутентификации;
• автоматическое распечатывание хранилища;
• шифрование данных с помощью AES-256 и др.

В Deckhouse Stronghold реализован API (Application Programming Interface), совместимый с API HashiCorp Vault.

Возможности уровня HashiCorp Vault Enterprise

В Deckhouse Stronghold реализованы возможности уровня HashiCorp Vault Enterprise.

Пространство имён (namespaces)

Каждое пространство имён работает как отдельный виртуальный Stronghold, при этом все namespaces управляются одним экземпляром Stronghold-сервера.

Рисунок 3. Схема пространства имён в Deckhouse Stronghold 1.16

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

Рисунок 4. Пространство имён

Рисунок 5. Управление дочерним рабочим пространством demo-ns

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

Из родительских пространств имён можно получить доступ к дочерним, но не наоборот.

Шифрование данных с помощью HSM (в том числе и с алгоритмами ГОСТ)

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

Рисунок 6. Добавление механизма управления секретами в Deckhouse Stronghold 1.16

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

Рисунок 7. Поддержка HSM и двойное шифрование данных

В качестве внешнего контроллера используется аппаратное устройство Рутокен, подключаемое к компьютеру.

Рисунок 8. Двойное шифрование в Deckhouse Stronghold 1.16

Шифрование в хранилище выполняется алгоритмом AES-256, а дополнительное шифрование через внешний криптоконтроллер реализовано с использованием алгоритма ГОСТ «Кузнечик».

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

Рисунок 9. Пример отображения обычного секрета

При попытке доступа к секрету без подключённого токена чтение невозможно, и возникает ошибка доступа.

Рисунок 10. Вид секрета при отключённом криптоконтроллере

Аналогичная ситуация будет и при генерации PKI-сертификатов.

Рисунок 11. Генерация сертификата при отключённом криптоконтроллере

При отсутствии HSM, например в облачной инфраструктуре заказчика, поддерживается режим двойного шифрования с использованием отдельного экземпляра Stronghold. Данный подход реализуется через механизм транзитного шифрования (transit).

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

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

Рисунок 12. Создание ключа шифрования

ГОСТ TLS

Deckhouse Stronghold поддерживает ГОСТ TLS, что позволяет клиентской части подключаться к серверной с использованием ГОСТ-сертификатов, например выданных через Минцифры, и проверять их подлинность. TLS-соединение устанавливается непосредственно приложением: выполняется проверка сертификатов, согласование параметров шифрования и генерация сессионных ключей. Для этого не требуются дополнительные компоненты или прокси, что обеспечивает полноценное шифрование и защиту канала передачи данных между компонентами системы.

Автоматические бэкапы

Система резервного копирования встроена в продукт компании «Флант»: используется Integrated Raft Storage в качестве бэкенда хранения. В отличие от классических снапшотов сторонних приложений, которые требуют предоставления внешнему сервису доступа к хранилищу и сетевой связанности, здесь процесс резервного копирования выполняется непосредственно в системе.

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

Чтобы делать бэкапы, например, раз в один час и сохранять их за один день в надёжном S3 внутри облака «Флант» с кастомным TLS-сертификатом, нужно выполнить команду, указанную на рисунке ниже.

Рисунок 13. Команда бэкапа для ввода в консоли

Вендор расширил функциональность Vault EE в своём продукте. В HashiCorp максимум, что можно сделать для работы с S3 с внутренним Certificate Authority, — это использовать ключ aws_s3_disable_tls. В Stronghold же можно указать свой CA. Описанная функция даёт возможность посмотреть статус каждого конкретного инстанса расписания или список всех установленных расписаний.

В части User Interface (UI) разработчик добавил возможность управления расписанием бэкапов и мониторинга их статуса в веб-интерфейсе.

Рисунок 14. Создание расписания бэкапов в веб-интерфейсе Deckhouse Stronghold 1.16

Рисунок 15. Статус расписания бэкапа

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

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

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

Репликация данных

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

При проектировании решения компания «Флант» проанализировала существующие подходы к репликации в HashiCorp Vault Community Edition и сопутствующие сложности:

• необходимость обязательного использования TLS для межкластерного взаимодействия и последующего сопровождения сертификатов;
• ограничение права ServiceAccount только необходимыми секретами;
• поддержку инфраструктурного кода (IaC) для описания политик и др.

Такие требования существенно усложняют эксплуатацию и повышают риск ошибок конфигурации. Поэтому вендор реализовал репликацию для хранилищ KV1 / KV2 путём импорта данных KV одного кластера в другой по HTTPS / REST.

Рисунок 16. Репликация KV1 / KV2

Репликация построена по архитектуре master-slave с использованием pull-модели, при которой подчинённые узлы самостоятельно опрашивают master-узел и забирают изменения. Это позволяет обеспечить более безопасный и удобный доступ к секретам в крупных компаниях с геораспределённой структурой.

Параметры репликации задаются дополнительными настройками при монтировании нового KV-хранилища. После завершения настройки локальное хранилище автоматически переводится в режим «только чтение», что гарантирует проведение всех изменений исключительно в исходном хранилище. Секреты в исходном и целевом хранилищах совпадают с точностью до версии, реплицируются в том числе и deleted-статусы промежуточных версий. Если планируется высокая нагрузка на чтение из KV, репликацию можно использовать для создания Performance-реплик KV.

Динамические секреты

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

Deckhouse Stronghold решает эту проблему, расширяя концепцию управления секретами за пределы статических данных. Помимо хранения традиционных статических секретов, система способна генерировать динамические, короткоживущие учётные данные для доступа к внешним сервисам — базам данных, SSH-серверам или брокерам сообщений. Эти временные секреты автоматически создаются по запросу приложения, используются строго ограниченное время (например, несколько минут), а затем бесследно аннулируются.

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

Рисунок 17. Запрос учётных данных для роли в Deckhouse Stronghold 1.16

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

Рисунок 18. Предоставление временных учётных данных

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

Рисунок 19. Создание временной учётной записи

Рассмотрим пример работы с серверами Linux через SSH. Администратор или пользователь с соответствующими правами может предоставить новому сотруднику временный доступ к серверу.

Для начала на локальной машине генерируется SSH-ключ: создаются публичный и приватный ключи, причём последний остаётся у пользователя и никуда не передаётся. После генерации публичный ключ подписывается в хранилище с помощью операции подписи. В запросе указываются principals — разрешённые для подключения учётные записи. На выходе формируется подписанный публичный ключ, который можно использовать для доступа к серверу в течение ограниченного времени.

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

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

Использование Deckhouse Stronghold для выполнения требований ГОСТ 56939-2024

Для компаний, которые планируют сертифицироваться по ГОСТ Р 56939-2024 «Безопасная разработка программного обеспечения», продукт помогает закрывать требования пункта 5.15 «Безопасность используемых секретов», в котором, в том числе, указано, что для хранения, управления и предоставления секретов необходимо использовать систему управления секретами.

Deckhouse Stronghold позволяет определить:

• порядок предоставления доступа к секретам;
• типы секретов, сроки их эксплуатации, действия при компрометации;
• порядок формирования, хранения и ротации секретов;
• требования к системам хранения секретов.

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

Обеспечение безопасности

Контейнерная архитектура решения предусматривает запуск приложений в Deckhouse Stronghold только в distroless-контейнерах (минималистичных образах Docker, содержащих только приложение и его зависимости) под управлением пользователей с непривилегированным доступом, при этом корневая файловая система контейнера (rootfs) доступна только для чтения.

В платформенном исполнении реализуется автоматическая настройка SSO (Single Sign-On), которая обеспечивает доступ к хранилищу через платформенный Identity Provider (IDP).

Продукт «Фланта» поддерживает как локальные учётные записи, так и интеграцию с внешними системами аутентификации, включая OpenID Connect (OIDC), Lightweight Directory Access Protocol (LDAP), Keycloak и др.

Рисунок 20. Вход в Kubernetes через Stronghold

Рисунок 21. Вход в Stronghold через OIDC-провайдера

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

Компания «Флант» выстраивает процессы безопасной разработки ПО Deckhouse Stronghold в соответствии с ГОСТ Р 56939–2024. Продукт проходит комплексную проверку защищённости различными методами тестирования: статический и динамический анализы, тестирование на проникновение, фазинг-тестирование. Регулярно осуществляется постоянный мониторинг CVE и оперативное устранение найденных уязвимостей.

Архитектура Deckhouse Stronghold 1.16

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

API. Управление хранилищем и секретами (аутентификация, работа с политиками и ролями, чтение и запись секретов) производится через API. Для получения доступа к этим операциям применяются токены, передающиеся в заголовках запросов.

Core. В ядре системы реализованы механизмы шифрования секретов и управления хранилищем (инициализация, запечатывание, распечатывание), обработки поступающих от API запросов и т. д. Предусмотрена возможность автоматического распечатывания (auto unseal) кластера Stronghold (требуется не менее 3 узлов).

Storage Backend. Представляет собой файл, БД, in-memory storage и т. п. Все данные хранятся в зашифрованном виде (ключи шифрования также последовательно зашифрованы).

Рисунок 22. Компоненты Deckhouse Stronghold 1.16

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

Все данные, которые Stronghold хранит в персистентном хранилище (PostgreSQL, etcd или Raft Storage), шифруются и подписываются мастер-ключом (AES256-GCM). Это обеспечивает конфиденциальность и целостность информации: данные невозможно прочитать или изменить без соответствующего ключа, даже при прямом доступе к хранилищу.

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

Системные требования Deckhouse Stronghold 1.16

Решение компании «Флант» поставляется в следующих вариантах исполнения: в контейнерном виде для развёртывания в контейнерной инфраструктуре и в standalone-формате для автономной установки без использования контейнерных платформ.

При запуске Deckhouse Stronghold в платформенном исполнении (в кластере DKP) пользователю доступны различные полезные функции платформы:

• автоконфигурирование кластера;
• встроенная балансировка трафика;
• автоматическое обновление версий;
• сквозная интеграция с модулем secrets-store-integration, который обеспечивает несколько способов автоматизированной и безопасной доставки секретов в приложения, запущенные в кластере Kubernetes.

Рисунок 23. Stronghold в контейнерном исполнении

Для Standalone-исполнения (запуск в ОС Linux на VM / bare metal) требуется самостоятельная настройка балансировки трафика и мониторинга, а также опыт написания политик доступа.

Рисунок 24. Stronghold в standalone-исполнении

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

Таблица 1. Описание кластеров

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

Таблица 2. Системные требования Deckhouse Stronghold 1.16

Контейнерное исполнение требует повышенного количества системных ресурсов (CPU, RAM) для запуска по сравнению с Standalone в связи с развёртыванием платформы Deckhouse Kubernetes Platform как исполняемой среды для работы Deckhouse Stronghold.

Продукт поддерживает ОС: РЕД ОС 7.3, 8.0, РОСА Сервер 7.9, 12.4, 12.5.1, ALT Linux p10, 10.0, 10.1, 10.2, 11, Astra Linux Special Edition 1.7.2, 1.7.3, 1.7.4, 1.7.5, 1.8, CentOS 7, 8, 9, Debian 10, 11, 12, Ubuntu 18.04, 20.04, 22.04, 24.04.

Рисунок 25. Поддерживаемые «из коробки» интеграции

Зарубежные системы аутентификации, такие как AliCloud, Microsoft Azure, GCP и AWS, система не поддерживает.

Лицензирование Deckhouse Stronghold 1.16

Вендор предлагает два типа лицензий: срочные (12, 24 или 36 месяцев) и бессрочные. Все виды лицензий включают гарантийную техническую поддержку, дающую право на получение обновлений и новых версий, а также доступ к обучающим курсам Deckhouse Academy. Срок гарантийной технической поддержки в срочных лицензиях равен сроку действия лицензии. Для бессрочных лицензий доступны различные периоды гарантийной поддержки (12, 24, 36 или 60 месяцев). По истечении выбранного срока приобретается отдельная лицензия на продление гарантийной технической поддержки.

Решение лицензируется по совокупности двух метрик:

• числу инсталляций Deckhouse Stronghold, развёрнутых в инфраструктуре конечного пользователя;
• количеству клиентов, использующих Deckhouse Stronghold для аутентификации.

Под инсталляцией (установкой) понимается экземпляр программного обеспечения Deckhouse Stronghold, установленный в инфраструктуре конечного пользователя. Одна инсталляция может использоваться для обслуживания множества кластеров Kubernetes. Дополнительные инсталляции могут потребоваться, например, для реализации хранилища секретов в катастрофоустойчивом исполнении с размещением инсталляций в нескольких ЦОД.

Клиент — приложение, сервис или пользователь, использующий уникальные учётные данные (тип аутентификационных данных и метод аутентификации) для доступа к секретам. Реплики одного сервиса или приложения (либо сервиса или приложения, использующего тот же набор секретов) считаются за один сервис или приложение. При миграции с HashiCorp Vault допустимо подсчитать количество Entities. Данная метрика аналогична количеству клиентов в Deckhouse Stronghold.

Каждая лицензия на метрику «Установка» уже включает 50 клиентов. Если необходимо большее число клиентов, можно приобрести лицензию на расширение их количества. Доступны пакеты на 50, 100, 200 и 1000 клиентов.

Тарифы техподдержки. «Стандарт» подразумевает: 

• рабочие дни — будние дни с 10:00 до 19:00 (МСК);
• ответы на критические запросы — в течение 25 минут в рабочее время;
• оказание помощи при развёртывании и настройке продукта;
• возможность оставить предложения по доработке продуктов Deckhouse и документации.

«Стандарт Плюс» включает возможности тарифа «Стандарт». Отличия:

• круглосуточная поддержка без выходных;
• ответы на критические запросы — в течение 25 минут круглосуточно;
• выделенный архитектор для проекта.

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

Предусмотрена возможность запросить доступ к 30-дневной пробной версии продукта.

Сценарии использования Deckhouse Stronghold 1.16

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

Своим клиентам вендор предлагает бесплатные обучающие материалы по Deckhouse Stronghold:

• Ознакомительный видеотренинг, где объясняются базовые аспекты работы с секретами, преимущества продукта, политика лицензирования.
• Технический курс по установке продукта, его включению и подготовке. Также здесь поднимаются вопросы о возможностях работы с секретами, доставке секретов в приложения, работе с SSH.

Ниже приведены прикладные задачи, которые решаются с использованием Deckhouse Stronghold:

Таблица 3. Примеры использования Deckhouse Stronghold

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

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

Таблица 4. Кейсы внедрения Deckhouse Stronghold

Особенности миграции с HashiCorp Vault на Deckhouse Stronghold

Отдельное направление применения продукта компании «Флант» связано с импортозамещением и переходом на отечественное программное обеспечение. 

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

В отличие от других решений, которые поддерживают миграцию только с Vault CE, переход на Deckhouse Stronghold с HashiCorp Vault (включая Enterprise Edition) возможен путём замены приложения без изменения его конфигурации и структуры базы данных. Поддерживается механизм безопасного переноса секретов через API напрямую из хранилища в хранилище (end-to-end): чувствительные данные не попадают на промежуточные и потенциально незащищённые узлы.

Выводы

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

Продукт компании «Флант» позволяет организациям не только централизованно управлять жизненным циклом секретов, но и выполнять ключевые требования нормативных правовых актов и стандартов: ФЗ‑152, ФЗ‑149, ФЗ‑187, ГОСТ Р 56939‑2024.

Преимущества:

• Пространства имён, совместимые с HashiCorp Vault Enterprise по возможностям и методам API.
• Автоматические бэкапы по расписанию.
• Межкластерная репликация данных.
• Встроенное безопасное автоматическое распечатывание хранилища.
• Поддержка аппаратных модулей безопасности.
• Автоматизированная доставка секретов в приложения.
• Управление через единый API, совместимый с API HashiCorp Vault.
• Базовые возможности управления жизненным циклом секретов доступны во всех редакциях продукта, включая бесплатную версию продукта.
• В коммерческих редакциях продукта реализованы улучшенные функциональные возможности уровня HashiCorp Vault Enterprise.
• Имеет сертификат соответствия требованиям Приказа ФСТЭК России № 76 от 2 июня 2020 г. по 4-му уровню доверия и техническим условиям.
• Вендор реализует отдельный трек по поддержке в продукте российских криптографических алгоритмов (ГОСТ).
• Включён в реестр отечественного ПО.

Недостатки:

• Для Standalone-исполнения требуется самостоятельная настройка балансировки трафика и мониторинга, а также опыт написания политик доступа.
• Контейнерное исполнение требует повышенного количества системных ресурсов (CPU, RAM) для запуска по сравнению с Standalone в связи с развёртыванием платформы Deckhouse Kubernetes Platform как исполняемой среды для работы Deckhouse Stronghold.
• Не поддерживает зарубежные системы аутентификации, такие как AliCloud, Microsoft Azure, GCP и AWS.