[FINAL] Deckhouse Stronghold - Master Presentation - v3.2

1.

Совершенно секретно,
или Не всё тайное становится явным

2.

Безопасное хранение
секретов
и управление их жизненным циклом

3.

Как пользоваться презентацией
Навигационный слайд
Не использовать данный
слайд в презентациях
1.
Эта презентация — конструктор, из которого вы можете собрать презентацию под конкретную
встречу или просто взять несколько слайдов для выступления на конференции.
2.
В комментариях к каждому слайду вы найдёте дополнительную информацию:
a.
Рекомендации его применимости для той или иной ситуации.
b.
Опорный текст для рассказа.
c.
Информацию об актуальности контента и владельце слайда, к которому можно обратиться
за актуализацией, если это необходимо.
3.
Для работы с презентацией сделайте её копию.
4.
Пожалуйста, доносите в #team-product-marketing любой фидбек по презентации: если вам не
хватило каких-то слайдов или клиент задавал вопросы, на которые не получилось дать
внятный ответ на основании слайдов.
5.
Чтобы при выгрузке в PDF не попадали скрытые слайды, делайте так: меню File -> пункт Print
preview -> отмените выбор Include skipped slides -> нажмите Download as PDF.

4.

СОДЕРЖАНИЕ
01
О компании
02
Проблематика хранения секретов
03
Описание продукта (для бизнес-аудитории)
04
Описание продукта (для технической аудитории)
05
Технические сценарии использования продукта
06
Безопасность продукта
07
Варианты инсталляции
08
Системные требования
09
Сравнение с конкурентами
10
Планы по развитию
11
ФСТЭК-редакция
12
Лицензирование, поддержка и обучение
Навигационный слайд

5.

01
Навигационный слайд
Не использовать данный
слайд в презентациях
О компании
Вернуться к содержанию

6.

О вендоре Deckhouse
17+
С 2017
№1
лет опыта
в Open Source
года используем
Kubernetes в production
контрибьютор в проекты
CNCF из России
500+
>260
В топе
сотрудников
Реестр
российского ПО
компаний-пользователей
Лицензии и сертификаты
ФСТЭК России
АРПП «Отечественный
софт»
вендоров ИТ-решений для банков *
и промышленности **
* Рейтинг «Крупнейшие ИТ-вендоры в банках», TAdviser, 2024 год
** Рейтинг «Крупнейшие ИТ-вендоры в промышленности», TAdviser, 2024 год

7.

Экосистема
продуктов Deckhouse
Каталог продуктов*
Управление кластерами
Платформа мониторинга
● Все продукты экосистемы — в реестре
российского ПО
Платформа виртуализации
Платформа разработки
● Единый канал технической поддержки
по всем продуктам
● Высокая доступность и отказоустойчивость
всех компонентов «из коробки»
Платформа контейнеризации
● Глубокая интеграция продуктов экосистемы
между собой
● Централизация управления, мониторинга
и контроля над всей экосистемой
через единый UI
● Сквозное применение лучших практик
DevSecOps на всех этапах процесса
непрерывной поставки ценности
Хранение секретов
Управление исходным кодом
Реестр образов контейнеров*
Доставка приложений*
* Продукт находится в активной фазе разработки, готовится выход
релизной версии

8.

02
Навигационный слайд
Не использовать данный
слайд в презентациях
Проблематика
для ИТ-менеджеров
Вернуться к содержанию

9.

Что такое секреты
и почему их важно
защищать

10.

Что можно считать
секретами?
Пароли
Сертификаты
Ключи API
Токены
SSH-ключи

11.

Секреты могут быть:
Пользовательскими
Человек
Инфраструктурными
Приложение
Приложение
Приложение

12.

Использование
секретов становится
более массовым
Основные тренды, влияющие
на рост количества секретов:
01
Контейнеризация
02
Гибридные и мультиоблака
03
DevOps, DevSecOps, MLOps,
CI/CD и автоматизация
04
Технологии Zero Trust

13.

Количество секретов непрерывно растёт
С ростом сложности цифровых
цепочек поставок разрастание
секретов становится ахиллесовой
пятой для организаций любого
размера и уровня безопасности*
Количество новых секретов,
обнаруженных на GitHub (млн)
15
12.8
10
10
6
5
3
0
2020
* По данным отчёта The State Of Secrets Sprawl 2024
компании GitGuardian
2021
2023
2024
Год

14.

Не все компании хранят секреты безопасно*
Интересный факт
Более 90 %
скомпрометированных
секретов остаются валидными
в течение 5 дней**
* По данным отчёта Secrets Management: The Next
Big Security Threat For Businesses компании
1Password
** По данным отчёта The State Of Secrets Sprawl
2024 компании GitGuardian
80 %
65 %
ИТ/DevOps-команд
не обеспечивают
безопасного хранения
секретов
уверены, что в их
инфраструктуре более
500 секретов
60 %
25 %
сталкивались
с утечками секретов
хранят секреты более
чем на 10 ресурсах
и обмениваются ими

15.

Недавние кейсы
Код и пароли Binance были
доступны на GitHub в течение
нескольких месяцев
Исходные коды MercedesBenz утекли из-за случайно
раскрытого токена GitHub
В публичных репозиториях
GitLab оказалось более
17 000 секретов
Источник: securitylab.ru
Источник: xakep.ru
Источник: bleepingcomputer.com

16.

Ручное управление секретами — дорого и долго
Из-за утечки секретов компании несут
не только репутационные, но и финансовые
потери — средний ущерб от одной утечки
оценивается в 11,5 млн руб.*
80 % отметили, что слишком заняты,
чтобы уделять должное внимание
секретам**
61 % DevOps-команд признались,
что разработка продуктов ведётся
с задержкой в связи с низким качеством
процессов управления секретами**
25 минут в день тратит один сотрудник
ИТ- и DevOps-команд на ручное управление
секретами, что приводит к большим
годовым издержкам**
* По данным отчёта «Оценка ущерба от утечек информации и затрат
на ликвидацию последствий» группы ЦИРКОН и ГК Infowatch
** По данным отчёта Secrets Management: The Next Big Security
Threat For Businesses компании 1Password

17.

Ручное управление секретами — это дорого и долго
Количество секретов
1–100
100–500
Более 500
Количество сотрудников, чел.
1
2
4
Общие трудозатраты в день, ч.
0,25
2
8
Общие трудозатраты в год, ч.
62
496
1984
Издержки в год, руб.
124 000
992 000
3 968 000

18.

Защита секретов
входит в топ-5
направлений
развития ИБ
Какие направления
наиболее приоритетны
для вашей стратегии
кибербезопасности?
По данным отчёта The State of Secrets
Management 2024 компании Akeyless
45 %
42 %
Облачная безопасность
Безопасность API
36 %
34 %
Безопасность эндпоинтов
Разведка угроз
33 %
30 %
Управление секретами
Управление привилегированным доступом (PAM)
25 %
23 %
Наём ИТ-персонала
Сетевой доступ с нулевым
доверием (ZTNA)
22 %
2%
Реагирование на инциденты
Другое

19.

Безопасность
Защита секретов входит
в топ-5 направлений
развития ИБ
33 %*
респондентов считают безопасность
секретов одним из важнейших приоритетов
* По данным отчёта The State of Secrets Management 2024 компании Akeyless

20.

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

21.

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

22.

03
Навигационный слайд
Не использовать данный
слайд в презентациях
Описание продукта и сценарии
использования
для ИТ-менеджеров
Вернуться к содержанию

23.

Что такое
Deckhouse Stronghold

24.

Ручное управление секретами
Фрагментация секретов
Секреты организации хранятся
хаотично и в небезопасных местах
1
2
3
PC
Code
Docs
Отсутствие контроля
?
ИТ-отделы и DevOps-команды
не могут их контролировать
Риск утечки
Появляются уязвимости, возрастает
риск компрометации и утечки секретов
?
?
?

25.

Хранение секретов с помощью
Deckhouse Stronghold
Централизованное
решение
для безопасного хранения секретов
1
2
3
PC
Code
Docs
1
2
3
Лёгкое управление
жизненным циклом секретов
и ролями доступа к ним
Полное шифрование данных
даже если кто-то украдёт физический
сервер, он не сможет получить доступ
к секретам

26.

Какие задачи мы помогаем решать
Выполнить требования НПА
(ФЗ-152, ФЗ-149, ФЗ-187)
Выполнить требования
ГОСТ Р 56939-2024
Сформировать единый подход
к управлению секретами
Реализовать переход
на отечественное ПО
Изменить структуру расходов
на управление секретами (↓OPEX)
Компенсировать нехватку
экспертизы и ресурсов персонала

27.

Выполнение требований законодательства
по защите конфиденциальной информации
Ситуация
Проблемы
Решение
Законодательство по защите
КИ непрерывно развивается,
появляются новые
требования
Как разобраться в законах
и выполнить необходимые
требования?
Deckhouse Stronghold соответствует
всем необходимым требованиям
законодательства (ФЗ-152, ФЗ-149, ФЗ187 )

28.

Переход на российское ПО
Ситуация
Проблемы
Решение
Западные вендоры ушли,
оставив без поддержки
Какое ПО выбрать на замену?
Какому вендору довериться?
Deckhouse Stronghold находится
в реестре отечественного ПО (№ 22339
от 24.04.2024), полностью соответствует
требованиям Минцифры России и имеет
надёжную техническую поддержку
от вендора

29.

Отсутствие контроля и единого подхода
Ситуация
Проблемы
Решение
Бизнес развивается, вместе
с тем растёт и количество
секретов
Где хранятся секреты?
Надёжно ли они защищены?
Не случится ли утечка?
Deckhouse Stronghold хранит
все секреты в едином месте
в зашифрованном виде, благодаря чему
даже физическое хищение серверов
не позволит злоумышленникам получить
к ним доступ

30.

Оптимизация трудозатрат персонала
Ситуация
Проблемы
Решение
Сотрудники тратят слишком
много рабочего времени
на ручное управление
секретами
Как оптимизировать ресурсы
и сфокусироваться на более
профильных задачах?
Deckhouse Stronghold автоматизирует
процессы хранения секретов
и управления ими — это экономит
в среднем 105 рабочих дней персонала
в год

31.

Deckhouse Stronghold
помогает
Вы получаете
Исключить риски утечек
конфиденциальной информации
Защиту бизнеса от финансовых
и репутационных потерь
Оптимизировать трудозатраты персонала
(команды DevOps и DevSecOps, сотрудники ИБ,
разработчики)
Возможность фокусироваться
на более профильных задачах
Сократить Time to Market и время интеграции
при разработке собственных продуктов
и сервисов
Своевременный запуск
продуктов, соответствующих
требованиям ИБ
Снизить издержки, возникающие вследствие
ручного управления секретами
Уменьшение операционных
расходов (OPEX) на ИБ

32.

Основные возможности продукта
Хранение секретов
как key-value
Отказоустойчивость
«из коробки»
Доступ к хранилищу
через API и UI
Совместимость с API
HashiCorp Vault
Хранение данных
в зашифрованном виде
Полная наблюдаемость
жизненного цикла секретов
Разграничение доступа
с помощью гибкого набора
политик
Интеграция с внутренними
и внешними сервисами

33.

Как работает Stronghold
Клиент
● Клиент через Stronghold или внешнюю
систему подтверждает, что обращается
именно он
Авторизация
Предоставление доступа
Шифрование

34.

Как работает Stronghold
Клиент
● Клиент через Stronghold или внешнюю
систему подтверждает, что обращается
именно он
● Stronghold анализирует, можно
ли предоставить доступ к запрошенному
секрету
Авторизация
Предоставление доступа
Шифрование

35.

Как работает Stronghold
Клиент
● Клиент через Stronghold или внешнюю
систему подтверждает, что обращается
именно он
● Stronghold анализирует, можно
ли предоставить доступ к запрошенному
секрету
Авторизация
● Если доступ есть, то операция по чтению
или записи секрета разрешается
Предоставление доступа
Шифрование

36.

Как работает Stronghold
Клиент
● Клиент через Stronghold или внешнюю
систему подтверждает, что обращается
именно он
● Stronghold анализирует, можно
ли предоставить доступ к запрошенному
секрету
Авторизация
● Если доступ есть, то операция по чтению
или записи секрета разрешается.
● Если доступа нет — операция отклоняется
Предоставление доступа
Шифрование

37.

04
Навигационный слайд
Не использовать данный
слайд в презентациях
Описание продукта
для технических специалистов
Вернуться к содержанию

38.

Способы хранения секретов
01
Хранение в репозитории
● Секреты хранятся внутри репозитория
вместе с кодом
● Секреты хранятся внутри репозитория
с кодом в виде CI/CD-переменных
● Секреты могут быть хешированы
или обёрнуты в Base64
● Секреты хранятся
в зашифрованном виде
● Секреты подкладываются в переменные
окружения или конфигурационный файл
при запуске или деплое приложения
● Секреты могут маскироваться.
Их видимость может фильтроваться
по веткам и тегам
Kubernetes
API
Очень просто
Изменения видны в коммитах
Небезопасно, так как секреты
передаются в открытом виде
Доступ к секретам есть у всех,
кто имеет доступ в репозиторий
Кластер

39.

Способы хранения секретов
01
Хранение в репозитории
● Секреты хранятся внутри репозитория
вместе с кодом
● Секреты хранятся внутри репозитория
с кодом в виде CI/CD-переменных
● Секреты могут быть хешированы
или обернуты в Base64
● Секреты хранятся
в зашифрованном виде
● Секреты подкладываются в переменные
окружения или конфигурационный файл
при запуске или деплое приложения
● Секреты могут маскироваться.
Их видимость может фильтроваться
по веткам и тегам
Kubernetes
API
Очень просто
Очень просто
Изменения видны в коммитах
Доступ есть у всех, кто имеет
доступ уровня maintainer
в репозиторий,
и у администраторов
хранилища кода
Небезопасно, так как секреты
передаются в открытом виде
Доступ к секретам есть у всех,
кто имеет доступ в репозиторий
Кластер

40.

Способы хранения секретов
01
Хранение в репозитории
● Секреты хранятся внутри репозитория
вместе с кодом
● Секреты хранятся внутри репозитория
с кодом в виде CI/CD-переменных
● Секреты могут быть хешированы
или обернуты в Base64
● Секреты хранятся
в зашифрованном виде
● Секреты подкладываются в переменные
окружения или конфигурационный файл
при запуске или деплое приложения
● Секреты могут маскироваться.
Их видимость может фильтроваться
по веткам и тегам
Kubernetes
API
Выводы
● В обоих случаях реализована доставка при деплое в кластер
в виде секрета Kubernetes
● Etcd, в котором хранится состояние Kubernetes API,
может быть зашифровано, но возникает вопрос, где хранить ключ
● Любой, у кого есть широкий доступ к API, получит доступ
к секрету
Кластер

41.

Способы хранения секретов
02 Использование хранилища секретов
● Секреты хранятся внутри
хранилища секретов
● Хранятся в зашифрованном виде
● Возможна доставка несколькими
безопасными способами
Все секреты хранятся в одном месте
Управление жизненным циклом секретов
и доступом к ним на единых принципах
Доставка секретов безопасна на всех этапах
и не требует разработки «особых» механизмов
Кластер

42.

Что такое Deckhouse Stronghold
Решение для централизованного управления жизненным циклом секретов.
Защищает пароли, ключи API, сертификаты, SSH-ключи, токены и другие
конфиденциальные данные от утечек, а также обеспечивает безопасную
доставку секретов в приложения.
HashiCorp Vault
1.14.8
Deckhouse
Stronghold
Мы не копируем
HashiCorp Vault,
мы переосмысливаем
хранилище секретов
и создаём стандарт
для российского рынка

43.

Преимущества Stronghold
Механизм namespaces
Репликация KV1/KV2
для создания пространств имён и делегирования
прав на управление ими
на архитектуре master-slave
с применением pull-модели
Auto unseal
Усиленная защита данных
автоматическое распечатывание хранилища
без использования внешних KMS
за счёт поддержки двойного шифрования
данных с помощью HSM
Различные методы аутентификации
Модуль secrets-store-integration
поддержка различных методов аутентификации и гибкая
настройка авторизации и политик доступа к хранилищу
и секретам
несколько безопасных способов автоматизированной
доставки секретов в приложение
Автоматическое резервное
копирование данных
по заданному расписанию
Удобный и русифицированный вебинтерфейс
Только один бинарный файл
минимум векторов атаки
Управление через единый API
совместимый с API HashiCorp Vault

44.

Как работает Stronghold
● Администратор (с правами на управление)
через внешнюю систему аутентификации
запрашивает доступ к данным
Внешние ресурсы
Кластер
Аутентификация
Защищённый
кластер
Системы
аутентификации
Кластер
Запрос доступа
Администраторы
и пользователи
Кластер

45.

Как работает Stronghold
● Администратор (с правами на управление)
через внешнюю систему аутентификации
запрашивает доступ к данным
● Stronghold анализирует запрос
и подтверждает либо отклоняет его
Внешние ресурсы
Кластер
Подтверждение
Защищённый
кластер
Системы
аутентификации
Кластер
Доступ к данным
Администраторы
и пользователи
Кластер

46.

Как работает Stronghold
● Администратор (с правами на управление)
через внешнюю систему аутентификации
запрашивает доступ к данным
● Stronghold анализирует запрос
и подтверждает либо отклоняет его
● Администратор настраивает политики
доступа для пользователей (запись, чтение,
изменение и т. д.). Пользователь получает
доступ к данным через систему
аутентификации
Внешние ресурсы
Кластер
Аутентификация
Защищённый
кластер
Системы
аутентификации
Кластер
Запрос доступа
Администраторы
и пользователи
Кластер

47.

Как работает Stronghold
● Администратор (с правами на управление)
через внешнюю систему аутентификации
запрашивает доступ к данным
● Stronghold анализирует запрос
и подтверждает либо отклоняет его
● Администратор настраивает политики
доступа для пользователей (запись, чтение,
изменение и т. д.). Пользователь получает
доступ к данным через систему
аутентификации
Внешние ресурсы
Кластер
Подтверждение
Защищённый
кластер
Системы
аутентификации
Кластер
Доступ к данным
Администраторы
и пользователи
Кластер

48.

Как работает Stronghold
● Администратор (с правами на управление)
через внешнюю систему аутентификации
запрашивает доступ к данным
● Stronghold анализирует запрос
и подтверждает либо отклоняет его
● Администратор настраивает политики
доступа для пользователей (запись, чтение,
изменение и т. д.). Пользователь получает
доступ к данным через систему
аутентификации
Внешние ресурсы
Кластер
Защищённый
кластер
Системы
аутентификации
Аутентификация
JSON Web Token
Кластер
Администраторы
и пользователи
Кластер
● Приложение аутентифицируется
в Stronghold с помощью JSON Web Token
(для этого используется ServiceAccount
пода)

49.

Как работает Stronghold
● Администратор (с правами на управление)
через внешнюю систему аутентификации
запрашивает доступ к данным
● Stronghold анализирует запрос
и подтверждает либо отклоняет его
● Администратор настраивает политики
доступа для пользователей (запись, чтение,
изменение и т. д.). Пользователь получает
доступ к данным через систему
аутентификации
Внешние ресурсы
Кластер
Защищённый
кластер
Системы
аутентификации
Получение токена
Кластер
Администраторы
и пользователи
Кластер
● Приложение аутентифицируется
в Stronghold с помощью JSON Web Token
(для этого используется ServiceAccount
пода)
● Stronghold предоставляет приложению
токен, необходимый для запроса секрета

50.

Как работает Stronghold
● Администратор (с правами на управление)
через внешнюю систему аутентификации
запрашивает доступ к данным
● Stronghold анализирует запрос
и подтверждает либо отклоняет его
● Администратор настраивает политики
доступа для пользователей (запись, чтение,
изменение и т. д.). Пользователь получает
доступ к данным через систему
аутентификации
Внешние ресурсы
Кластер
Защищённый
кластер
Системы
аутентификации
Запрос секрета
Кластер
● Приложение аутентифицируется
в Stronghold с помощью JSON Web Token
(для этого используется ServiceAccount
пода)
● Stronghold предоставляет приложению
токен, необходимый для запроса секрета
● Используя полученный токен, приложение
запрашивает необходимый секрет
Администраторы
и пользователи
Кластер

51.

Как работает Stronghold
● Администратор (с правами на управление)
через внешнюю систему аутентификации
запрашивает доступ к данным
● Stronghold анализирует запрос
и подтверждает либо отклоняет его
● Администратор настраивает политики
доступа для пользователей (запись, чтение,
изменение и т. д.). Пользователь получает
доступ к данным через систему
аутентификации
Внешние ресурсы
Кластер
Защищённый
кластер
Системы
аутентификации
Получение данных
Кластер
● Приложение аутентифицируется
в Stronghold с помощью JSON Web Token
(для этого используется ServiceAccount
пода)
● Stronghold предоставляет приложению
токен, необходимый для запроса секрета
● Используя полученный токен, приложение
запрашивает необходимый секрет
Администраторы
и пользователи
Кластер
● Если доступ есть, операция по чтению
секрета разрешается. Если доступа нет —
операция отклоняется

52.

Как работает Stronghold
● Администратор (с правами на управление)
через внешнюю систему аутентификации
запрашивает доступ к данным
● Stronghold анализирует запрос
и подтверждает либо отклоняет его
Внешние ресурсы
Доступ к внешним ресурсам
с использованием секрета
Кластер
Защищённый
кластер
Системы
аутентификации
Кластер
● Администратор настраивает политики
доступа для пользователей (запись, чтение,
изменение и т. д.). Пользователь получает
доступ к данным через систему
аутентификации
● Приложение аутентифицируется
в Stronghold с помощью JSON Web Token
(для этого используется ServiceAccount
пода)
● Stronghold предоставляет приложению
токен, необходимый для запроса секрета
● Используя полученный токен, приложение
запрашивает необходимый секрет
Администраторы
и пользователи
Кластер
● Если доступ есть, операция по чтению
секрета разрешается. Если доступа нет —
операция отклоняется
● Используя полученный секрет, приложение
получает доступ к внешним ресурсам

53.

Компоненты Stronghold
API
Управление хранилищем и секретами
(аутентификация, работа с политиками
и ролями, чтение и запись секретов)
производится через API. Для получения доступа
к этим операциям применяются токены,
которые передаются в заголовках запросов
HTTP/HTTPS API
Auto Init
Auto Unseal
Core
Хранилище токенов
Хранилище политик
Маршрутизация
System
Backend
System
Engine
Метод
аутентификации
Storage Backend
Файловая
система
Etcd
База данных
(MSSQL,PostgreSQL,
MySQL,Redis и т. д.)
In-Memory
Файловая
система
по Raft

54.

Компоненты Stronghold
API
Управление хранилищем и секретами
(аутентификация, работа с политиками
и ролями, чтение и запись секретов)
производятся через API. Для получения доступа
к этим операциям применяются токены,
которые передаются в заголовках запросов
HTTP/HTTPS API
Auto Init
Auto Unseal
Core
Хранилище токенов
Хранилище политик
Маршрутизация
System
Backend
System
Engine
Метод
аутентификации
Storage Backend
Файловая
система
Etcd
База данных
(MSSQL,PostgreSQL,
MySQL,Redis и т. д.)
In-Memory
Файловая
система
по Raft
Core
В ядре Stronghold реализованы механизмы
шифрования секретов и управления
хранилищем (инициализация, запечатывание,
распечатывание), обработки поступающих
от API запросов и т. д. Предусмотрен
функционал автоматического распечатывания
(auto unseal) кластера Stronghold (требуется
не менее 3 узлов)

55.

Компоненты Stronghold
API
Управление хранилищем и секретами
(аутентификация, работа с политиками
и ролями, чтение и запись секретов)
производятся через API. Для получения доступа
к этим операциям применяются токены,
которые передаются в заголовках запросов
HTTP/HTTPS API
Auto Init
Auto Unseal
Core
Хранилище токенов
Хранилище политик
Маршрутизация
System
Backend
System
Engine
Метод
аутентификации
Storage Backend
Файловая
система
Etcd
База данных
(MSSQL,PostgreSQL,
MySQL,Redis и т. д.)
Core
В ядре Stronghold реализованы механизмы
шифрования секретов и управления
хранилищем (инициализация, запечатывание,
распечатывание), обработки поступающих
от API запросов и т. д. Предусмотрен
функционал автоматического распечатывания
(auto unseal) кластера Stronghold (требуется
не менее 3 узлов)
Storage Backend
In-Memory
Файловая
система
по Raft
Представляет собой файл, БД, in-memory
storage и т. д. Все данные хранятся
в зашифрованном виде (ключи шифрования
также последовательно зашифрованы)

56.

Отказоустойчивость Stronghold
Кластер Deckhouse Kubernetes Platform
auto unseal
Узел 1
Узел 2
auto unseal
Узел 3
API кластера
Automatic
● Любой активный узел Stronghold
в кластере обнаруживает
и автоматически распечатывает
остальные узлы при условии, что у них
валидный сертификат (ключ хранится
только в памяти Stronghold)

57.

Отказоустойчивость Stronghold
● Любой активный узел Stronghold
в кластере обнаруживает
и автоматически распечатывает
остальные узлы при условии, что у них
валидный сертификат (ключ хранится
только в памяти Stronghold)
Кластер Deckhouse Kubernetes Platform
auto unseal
Узел 1
Узел 2
Узел 3
auto unseal
API кластера
Automatic

58.

Отказоустойчивость Stronghold
Кластер Deckhouse Kubernetes Platform
Узел 1
Узел 2
auto unseal
Узел 3
auto unseal
API кластера
Automatic
● Любой активный узел Stronghold
в кластере обнаруживает
и автоматически распечатывает
остальные узлы при условии, что у них
валидный сертификат (ключ хранится
только в памяти Stronghold)

59.

Отказоустойчивость Stronghold
● Любой активный узел Stronghold
в кластере обнаруживает
и автоматически распечатывает
остальные узлы при условии, что у них
валидный сертификат (ключ хранится
только в памяти Stronghold)
Кластер Deckhouse Kubernetes Platform
Узел 1
Узел 2
Репликация (Raft)
API кластера
Automatic
Узел 3
● Для репликации данных
и отказоустойчивой работы Stronghold
используется алгоритм Raft

60.

Отказоустойчивость Stronghold
Кластер Deckhouse Kubernetes Platform
auto unseal
Узел 2
Узел 1
Репликация (Raft)
auto unseal
API кластера
Automatic
auto unseal
Узел 3
● Любой активный узел Stronghold
в кластере обнаруживает
и автоматически распечатывает
остальные узлы при условии, что у них
валидный сертификат (ключ хранится
только в памяти Stronghold)
● Для репликации данных
и отказоустойчивой работы Stronghold
используется алгоритм Raft
● Компонент Stronghold Automatic
отвечает за настройку
аутентификации, создание групп
и ролей администраторов

61.

Автоматическое распечатывание
● Любой активный узел Stronghold
в кластере обнаруживает
и автоматически распечатывает
остальные узлы при условии, что
у них валидный сертификат
(ключ хранится только
в памяти Stronghold)
● Для репликации данных
и отказоустойчивой работы
Stronghold используется
алгоритм Raft
Кластер
auto unseal
Узел 1
auto unseal
Репликация (Raft)
Узел 2
Узел 3
auto unseal

62.

05
Навигационный слайд
Не использовать данный
слайд в презентациях
Сценарии использования
для технических специалистов
Вернуться к содержанию

63.

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

64.

Возможные
сценарии
использования
Управление ЖЦ
секретов
Аутентификация
и авторизация
● Создание, хранение, доставка,
отзыв и ротация секретов
● Подключение через внешние и
внутренние методы аутентификации,
чтобы управлять доступом
централизованно, а не настраивать его в
каждом приложении отдельно
● Безопасная выдача секретов
приложениям и сервисам по
политике доступа, с возможностью
контроля, кто и когда получил
нужные данные
● Шифрование «из коробки»
Управление
инфраструктурой
открытых ключей (PKI)
Для кого полезно
Команды DevOps и DevSecOps
Сотрудники подразделений ИБ
Разработчики
● Хранение сертификатов и ключей,
включая списки отзыва, и
управление их жизненным циклом
Управление
динамическими секретами
● Создание временных учётных данных
для доступа разработчиков и приложений
к базам данных PostgreSQL, MySQL
и MongoDB
● Гибкая модель авторизации по ролям и
политикам, позволяющая выдавать доступ
только к нужным секретам, ресурсам и
операциям
Секреты
для CI/CD
● Безопасная передача секретов
в пайплайны сборки и деплоя,
чтобы не хранить их в переменных
окружения, репозиториях
или конфигурационных файлах
● Удобная интеграция с процессами
автоматической сборки и доставки
ПО, где пайплайны получают только
те секреты, которые нужны им
в конкретный момент

65.

01
Авторизация SSH-доступа
на компоненты
инфраструктуры
IdP
Кластер
SAML
или
OIDC
Bare-metal-кластер
● Пользователь аутентифицируется
в Stronghold, используя
корпоративный сервер
аутентификации

66.

01
Авторизация SSH-доступа
на компоненты
инфраструктуры
● Пользователь аутентифицируется
в Stronghold, используя
корпоративный сервер
аутентификации
● Stronghold подписывает сертификат
SSH на ограниченный срок (например,
на 24 часа)
IdP
Кластер
Bare-metal-кластер

67.

01
Авторизация SSH-доступа
на компоненты
инфраструктуры
● Пользователь аутентифицируется
в Stronghold, используя
корпоративный сервер
аутентификации
● Stronghold подписывает сертификат
SSH на ограниченный срок (например,
на 24 часа)
SSH
Кластер
IdP
SSH
SSH
Bare-metal-кластер
SSH
● Используя подписанный SSH-ключ,
пользователь авторизуется
на компонентах инфраструктуры.
На стороне сервера подпись ключа
проверяется с помощью
предварительно доставленного
из Stronghold сертификата CA
(Certificate Authority)

68.

02
Динамические секреты в базах
с помощью Stronghold и IdP
IdP
SAML
или
OIDC
Помещение УЗ
и адреса БД
● Администратор аутентифицируется
и помещает в Stronghold адрес БД и учётную
запись, которая может создавать другие
учётные записи в БД

69.

02
Динамические секреты в базах
с помощью Stronghold и IdP
IdP
Создание роли
и политики доступа
● Администратор аутентифицируется
и помещает в Stronghold адрес БД и учётную
запись, которая может создавать другие
учётные записи в БД
● Администратор создаёт роль,
при обращении к которой Stronghold будет
создавать в БД временного пользователя,
а также политику, разрешающую
обращаться к этому объекту (роли)

70.

02
Динамические секреты в базах
с помощью Stronghold и IdP
● Администратор аутентифицируется
и помещает в Stronghold адрес БД и учётную
запись, которая может создавать другие
учётные записи в БД
● Администратор создаёт роль,
при обращении к которой Stronghold будет
создавать в БД временного пользователя,
а также политику, разрешающую
обращаться к этому объекту (роли)
IdP
● Пользователь аутентифицируется
в Stronghold, используя IdP, и производит
чтение объекта (роли)
SAML
или
OIDC
Чтение
объекта

71.

02
Динамические секреты в базах
с помощью Stronghold и IdP
● Администратор аутентифицируется
и помещает в Stronghold адрес БД и учётную
запись, которая может создавать другие
учётные записи в БД
● Администратор создаёт роль,
при обращении к которой Stronghold будет
создавать в БД временного пользователя,
а также политику, разрешающую
обращаться к этому объекту (роли)
IdP
● Пользователь аутентифицируется
в Stronghold, используя IdP, и производит
чтение объекта (роли)
● Stronghold генерирует логин и пароль, после
чего обращается в БД и создаёт временного
пользователя (который будет удалён по TTL
или отзыву токена)
Создание временного
пользователя

72.

02
Динамические секреты в базах
с помощью Stronghold и IdP
● Администратор аутентифицируется
и помещает в Stronghold адрес БД и учётную
запись, которая может создавать другие
учётные записи в БД
● Администратор создаёт роль,
при обращении к которой Stronghold будет
создавать в БД временного пользователя,
а также политику, разрешающую
обращаться к этому объекту (роли)
IdP
● Пользователь аутентифицируется
в Stronghold, используя IdP, и производит
чтение объекта (роли)
Передача
реквизитов
для доступа к БД
● Stronghold генерирует логин и пароль, после
чего обращается в БД и создаёт временного
пользователя (который будет удалён по TTL
или отзыву токена)
● Созданные логин и пароль передаются
пользователю

73.

02
Динамические секреты в базах
с помощью Stronghold и IdP
● Администратор аутентифицируется
и помещает в Stronghold адрес БД и учётную
запись, которая может создавать другие
учётные записи в БД
● Администратор создаёт роль,
при обращении к которой Stronghold будет
создавать в БД временного пользователя,
а также политику, разрешающую
обращаться к этому объекту (роли)
IdP
Обращение к БД
с использованием
пары «логин/пароль»
● Пользователь аутентифицируется
в Stronghold, используя IdP, и производит
чтение объекта (роли)
● Stronghold генерирует логин и пароль, после
чего обращается в БД и создаёт временного
пользователя (который будет удалён по TTL
или отзыву токена)
● Созданные логин и пароль передаются
пользователю
● Пользователь подключается к БД, используя
полученную пару «логин/пароль»

74.

03.1
Доставка секретов
в приложения
с помощью модуля secrets-store-integration
(mutating-webhook)
Кластер Deckhouse Kubernetes Platform
NS application-production
Развёртывание
приложения
Kubernetes API
NS d8-stronghold
Модуль
secrets-storeintegration
● CI-система обращается в Kubernetes API
для создания приложения

75.

03.1
Доставка секретов
в приложения
с помощью модуля secrets-store-integration
(mutating-webhook)
Кластер Deckhouse Kubernetes Platform
NS application-production
Application backend (deployment)
Kubernetes API
NS d8-stronghold
Модуль
secrets-storeintegration
● CI-система обращается в Kubernetes API
для создания приложения
● В Kubernetes создаётся шаблон приложения

76.

03.1
Доставка секретов
в приложения
с помощью модуля secrets-store-integration
(mutating-webhook)
Кластер Deckhouse Kubernetes Platform
NS application-production
Application backend (deployment)
Kubernetes API
NS d8-stronghold
Модуль
secrets-storeintegration
Application backend (pod)
● CI-система обращается в Kubernetes API
для создания приложения
● В Kubernetes создаётся шаблон приложения
● Из шаблона создаётся экземпляр
приложения

77.

03.1
Доставка секретов
в приложения
с помощью модуля secrets-store-integration
(mutating-webhook)
Кластер Deckhouse Kubernetes Platform
NS application-production
Application backend (deployment)
Kubernetes API
Application backend (pod)
init-container
NS d8-stronghold
Модуль
secrets-storeintegration
emptyDir
(in-memory volume)
● CI-система обращается в Kubernetes API
для создания приложения
● В Kubernetes создаётся шаблон приложения
● Из шаблона создаётся экземпляр
приложения
● Модуль secrets-store-integration определяет,
что приложению необходимо получить
секреты, и добавляет в под приложения
дополнительный контейнер, содержащий
бинарный файл инжектора (init-container)

78.

03.1
Доставка секретов
в приложения
● CI-система обращается в Kubernetes API
для создания приложения
с помощью модуля secrets-store-integration
(mutating-webhook)
● В Kubernetes создаётся шаблон приложения
● Из шаблона создаётся экземпляр
приложения
● Модуль secrets-store-integration определяет,
что приложению необходимо получить
секреты, и добавляет в под приложения
дополнительный контейнер, содержащий
бинарный файл инжектора (init-container)
Кластер Deckhouse Kubernetes Platform
NS application-production
Application backend (deployment)
Kubernetes API
Application backend (pod)
init-container
NS d8-stronghold
Модуль
secrets-storeintegration
Копирование
инжектора
emptyDir
(in-memory volume)
● Бинарный файл копирует сам себя
из контейнер-образа во временное
хранилище в поде

79.

03.1
Доставка секретов
в приложения
● CI-система обращается в Kubernetes API
для создания приложения
с помощью модуля secrets-store-integration
(mutating-webhook)
● В Kubernetes создаётся шаблон приложения
● Из шаблона создаётся экземпляр
приложения
● Модуль secrets-store-integration определяет,
что приложению необходимо получить
секреты, и добавляет в под приложения
дополнительный контейнер, содержащий
бинарный файл инжектора (init-container)
Кластер Deckhouse Kubernetes Platform
NS application-production
Application backend (deployment)
Kubernetes API
Application backend (pod)
container
NS d8-stronghold
Модуль
secrets-storeintegration
In running application
- name: MYSQL_PWD
value: “spCPR4QDPVhPXhdGvzTKvejf”
Замена
entrypoint
Монтирование
injector
emptyDir
(in-memory
volume)
● Бинарный файл копирует сам себя
из контейнер-образа во временное
хранилище в поде
● Вместо запуска основного приложения
запускается инжектор

80.

03.1
Доставка секретов
в приложения
● CI-система обращается в Kubernetes API
для создания приложения
с помощью модуля secrets-store-integration
(mutating-webhook)
● В Kubernetes создаётся шаблон приложения
● Из шаблона создаётся экземпляр
приложения
● Модуль secrets-store-integration определяет,
что приложению необходимо получить
секреты, и добавляет в под приложения
дополнительный контейнер, содержащий
бинарный файл инжектора (init-container)
Кластер Deckhouse Kubernetes Platform
NS application-production
Application backend (deployment)
Kubernetes API
Application backend (pod)
container
NS d8-stronghold
Модуль
secrets-storeintegration
In running application
- name: MYSQL_PWD
value: “spCPR4QDPVhPXhdGvzTKvejf”
entrypoint
injector
emptyDir
(in-memory
volume)
● Бинарный файл копирует сам себя
из контейнер-образа во временное
хранилище в поде
● Вместо запуска основного приложения
запускается инжектор
● Инжектор, используя ServiceAccount
приложения, получает необходимые секреты
из Stronghold

81.

03.1
Доставка секретов
в приложения
● CI-система обращается в Kubernetes API
для создания приложения
● В Kubernetes создаётся шаблон приложения
с помощью модуля secrets-store-integration
(mutating-webhook)
● Из шаблона создаётся экземпляр
приложения
● Модуль secrets-store-integration определяет,
что приложению необходимо получить
секреты, и добавляет в под приложения
дополнительный контейнер, содержащий
бинарный файл инжектора (init-container)
Кластер Deckhouse Kubernetes Platform
NS application-production
● Бинарный файл копирует сам себя
из контейнер-образа во временное
хранилище в поде
Application backend (deployment)
Kubernetes API
Application backend (pod)
container
NS d8-stronghold
Модуль
secrets-storeintegration
In running application
- name: MYSQL_PWD
value: “spCPR4QDPVhPXhdGvzTKvejf”
entrypoint
injector
emptyDir
(in-memory
volume)
● Вместо запуска основного приложения
запускается инжектор
exec
● Инжектор, используя ServiceAccount
приложения, получает необходимые секреты
из Stronghold
● Инжектор запускает основное приложение,
используя execve

82.

03.2
Доставка секретов
в приложения
● CI-система обращается в Kubernetes API
для создания приложения. Необходимые
для подключения секреты описываются
в ресурсе SecretsStoreImport
с помощью модуля
secrets-store-integration (CSI)
Кластер Deckhouse Kubernetes Platform
Узел
Развёртывание
приложения
pod
Kubernetes API
Манифест
SecretsStorelmport
container1
CSI-driver
Описывает, в какой
файл поместить секрет
CSI-provider
container2
in-memory
volume

83.

03.2
Доставка секретов
в приложения
● CI-система обращается в Kubernetes API
для создания приложения. Необходимые
для подключения секреты описываются
в ресурсе SecretsStoreImport
с помощью модуля
secrets-store-integration (CSI)
● В манифесте пода описывается
подключение Volume с использованием
драйвера secrets-store.csi.deckhouse.io
Кластер Deckhouse Kubernetes Platform
Kubelet
создаёт
контейнеры
Kubernetes API
Манифест
SecretsStorelmport
Узел
pod
container1
CSI-driver
Описывает, в какой
файл поместить секрет
CSI-provider
container2
in-memory
volume

84.

03.2
Доставка секретов
в приложения
● CI-система обращается в Kubernetes API
для создания приложения. Необходимые
для подключения секреты описываются
в ресурсе SecretsStoreImport
с помощью модуля
secrets-store-integration (CSI)
● В манифесте пода описывается
подключение Volume с использованием
драйвера secrets-store.csi.deckhouse.io
● При запуске пода на узле происходит
подключение Volume
Кластер Deckhouse Kubernetes Platform
Узел
pod
Kubernetes API
Манифест
SecretsStorelmport
container1
container2
Запрашивает
подключение Volume
CSI-driver
Описывает, в какой
файл поместить секрет
CSI-provider
in-memory
volume

85.

03.2
Доставка секретов
в приложения
● CI-система обращается в Kubernetes API
для создания приложения. Необходимые
для подключения секреты описываются
в ресурсе SecretsStoreImport
с помощью модуля
secrets-store-integration (CSI)
● В манифесте пода описывается
подключение Volume с использованием
драйвера secrets-store.csi.deckhouse.io
● При запуске пода на узле происходит
подключение Volume:
Кластер Deckhouse Kubernetes Platform
● Драйвер читает ресурс SecretsStoreImport
и получает список необходимых секретов
Узел
pod
Kubernetes API
Манифест
SecretsStorelmport
container1
Запрашивает
подключение Volume
CSI-driver
Описывает, в какой
файл поместить секрет
Опрашивает
манифест
container2
CSI-provider
in-memory
volume

86.

03.2
Доставка секретов
в приложения
● CI-система обращается в Kubernetes API
для создания приложения. Необходимые
для подключения секреты описываются
в ресурсе SecretsStoreImport
с помощью модуля
secrets-store-integration (CSI)
● В манифесте пода описывается
подключение Volume с использованием
драйвера secrets-store.csi.deckhouse.io
● При запуске пода на узле происходит
подключение Volume:
Кластер Deckhouse Kubernetes Platform
● Драйвер читает ресурс SecretsStoreImport
и получает список необходимых секретов
Узел
● Используя ServiceAccount приложения, драйвер
получает секреты из Stronghold
pod
Kubernetes API
Манифест
SecretsStorelmport
Описывает, в какой
файл поместить секрет
Запрашивает/получает
секреты (HTTPS)
container1
container2
Запрашивает
подключение Volume
CSI-driver
in-memory
volume
Запрашивает/получает
секреты (socket)
CSI-provider

87.

03.2
Доставка секретов
в приложения
● CI-система обращается в Kubernetes API
для создания приложения. Необходимые
для подключения секреты описываются
в ресурсе SecretsStoreImport
с помощью модуля
secrets-store-integration (CSI)
● В манифесте пода описывается
подключение Volume с использованием
драйвера secrets-store.csi.deckhouse.io
● При запуске пода на узле происходит
подключение Volume:
Кластер Deckhouse Kubernetes Platform
● Драйвер читает ресурс SecretsStoreImport
и получает список необходимых секретов
Узел
● Используя ServiceAccount приложения, драйвер
получает секреты из Stronghold
pod
Kubernetes API
Манифест
SecretsStorelmport
Описывает, в какой
файл поместить секрет
container1
container2
Запрашивает
подключение Volume
CSI-driver
in-memory
volume
Создаёт файлы
с секретами
CSI-provider
● Драйвер создаёт в памяти на узле tmpfs,
который помещает в файлы значения секретов

88.

03.2
Доставка секретов
в приложения
● CI-система обращается в Kubernetes API
для создания приложения. Необходимые
для подключения секреты описываются
в ресурсе SecretsStoreImport
с помощью модуля
secrets-store-integration (CSI)
● В манифесте пода описывается
подключение Volume с использованием
драйвера secrets-store.csi.deckhouse.io
● При запуске пода на узле происходит
подключение Volume:
Кластер Deckhouse Kubernetes Platform
● Драйвер читает ресурс SecretsStoreImport
и получает список необходимых секретов
Узел
● Используя ServiceAccount приложения, драйвер
получает секреты из Stronghold
pod
Kubernetes API
Манифест
SecretsStorelmport
container1
container2
Подключение
CSI-driver
Описывает, в какой
файл поместить секрет
CSI-provider
in-memory
volume
● Драйвер создаёт в памяти на узле tmpfs,
который помещает в файлы значения секретов
● Volume подключается в контейнер

89.

03.2
Доставка секретов
в приложения
● CI-система обращается в Kubernetes API
для создания приложения. Необходимые
для подключения секреты описываются
в ресурсе SecretsStoreImport
с помощью модуля
secrets-store-integration (CSI)
● В манифесте пода описывается
подключение Volume с использованием
драйвера secrets-store.csi.deckhouse.io
● При запуске пода на узле происходит
подключение Volume:
Кластер Deckhouse Kubernetes Platform
● Драйвер читает ресурс SecretsStoreImport
и получает список необходимых секретов
Узел
● Используя ServiceAccount приложения, драйвер
получает секреты из Stronghold
pod
Kubernetes API
Манифест
SecretsStorelmport
Описывает, в какой
файл поместить секрет
Запрашивает/получает
секреты (HTTPS)
container1
container2
Создаёт файлы с
секретами
CSI-driver
in-memory
volume
Запрашивает/получает
секреты (socket)
CSI-provider
● Драйвер создаёт в памяти на узле tmpfs,
который помещает в файлы значения секретов
● Volume подключается в контейнер
● CSI-драйвер осуществляет периодический
опрос Stronghold на предмет изменения
секретов и при необходимости обновляет
значения секретов в Volume

90.

03.2
Доставка секретов
в приложения
● CI-система обращается в Kubernetes API
для создания приложения. Необходимые
для подключения секреты описываются
в ресурсе SecretsStoreImport
с помощью модуля
secrets-store-integration (CSI)
● В манифесте пода описывается
подключение Volume с использованием
драйвера secrets-store.csi.deckhouse.io
● При запуске пода на узле происходит
подключение Volume:
Кластер Deckhouse Kubernetes Platform
● Драйвер читает ресурс SecretsStoreImport
и получает список необходимых секретов
Узел
● Используя ServiceAccount приложения, драйвер
получает секреты из Stronghold
pod
Kubernetes API
Манифест
SecretsStorelmport
container1
container2
Читает
из Volume
CSI-driver
Описывает, в какой
файл поместить секрет
CSI-provider
in-memory
volume
● Драйвер создаёт в памяти на узле tmpfs,
который помещает в файлы значения секретов
● Volume подключается в контейнер
● CSI-драйвер осуществляет периодический
опрос Stronghold на предмет изменения
секретов и при необходимости обновляет
значения секретов в Volume
● Для приложения секреты выглядят
как файлы на диске, список которых
перечислен в ресурсе SecretsStoreImport

91.

Способы
взаимодействия
со Stronghold

92.

Способы взаимодействия
со Stronghold
01
Пользователь взаимодействует
со Stronghold через UI
HTTPS
UI

93.

Способы взаимодействия
со Stronghold
02
Пользователь или приложение
взаимодействуют с API Stronghold напрямую
HTTPS
AP
I

94.

Способы взаимодействия
со Stronghold
03
Пользователь или приложение
взаимодействуют с API Stronghold, используя
консольный клиент Stronghold или HCP Vault
Console → HTTPS
AP
I

95.

Способы взаимодействия
со Stronghold
04
Подразделение, управляющее
инфраструктурой с применением подхода
IaC, использует хранилище кода
для хранения ролей Ansible и вручную
запускает их для настройки интеграции баз
данных и модуля динамических секретов,
управления сертификатами в модуле PKI
и управления секретами в kv-модуле
AP
I

96.

Способы взаимодействия
со Stronghold
05
Подразделение, управляющее
инфраструктурой с применением подхода
IaC, хранит описание политик, ролей и других
объектов Stronghold в хранилище кода
и осуществляет изменения автоматически
или вручную
AP
I

97.

06
Навигационный слайд
Не использовать данный
слайд в презентациях
Безопасность
ФСТЭК и ГОСТ Р 56939-2024
Вернуться к содержанию

98.

Безопасность Stronghold
Stronghold проходит комплексную проверку
защищённости различными методами
тестирования:
Статический анализ
Динамический анализ
Тестирование на проникновение
Фаззинг-тестирование
АО «Флант» выстраивает
процессы безопасной
разработки ПО согласно
ГОСТ Р 56939-2024

99.

Stronghold для выполнения
требований ГОСТ Р 56939-2024
В соответствии с пунктом 5.15 Cтандарта
при разработке программного
обеспечения необходимо обеспечить
безопасность использования секретов
Использование Deckhouse Stronghold
позволяет выполнить требования
ГОСТ Р 56939-2024
Deckhouse Stronghold
позволяет определить:
01
Порядок предоставления доступа к секретам
02
Типы секретов, сроки их эксплуатации,
действия при компрометации
03
Порядок формирования, хранения
и ротации секретов
04
Требования к системам хранения секретов

100.

Шифрование ГОСТ
Актуально для защиты информации
На значимых объектах КИИ
В ГИС
В ИСПДн
В АСУ
Нормативная база
● Приказ ФСБ России от 18 марта 2025 года № 117
● Приказ ФСБ России от 10 июля 2014 года № 378
● Приказ ФСБ России от 9 февраля 2005 года № 66
● Р 1323565.1.020-2020
● Р 1323565.1.030-2020
В Deckhouse Stronghold поддержка
ГОСТ-шифрования реализуется
по четырём ключевым направлениям
01
Sealwrap
02
TLS
03
PKI с поддержкой ГОСТ
04
Transit Secrets Engine с поддержкой ГОСТ

101.

Шифрование ГОСТ

102.

07
Навигационный слайд
Не использовать данный
слайд в презентациях
Варианты инсталляции
Вернуться к содержанию

103.

Варианты
инсталляции

104.

Варианты инсталляции
Кластер DKP
01
02
03
04
Доступно только для коммерческих редакций DKP
(Basic Edition, Standard Edition, Enterprise Edition и Certified Security Edition)
Кластер DKP уже развёрнут
и используется
Кластер DKP развёрнут,
но для Stronghold нужен
отдельный
Кластер DKP не развёрнут
Используются другие
технологии, но нужно
отдельное хранилище
секретов

105.

Варианты инсталляции
Кластер DKP
01
02
03
04
Доступно только для коммерческих редакций DKP
(Basic Edition, Standard Edition, Enterprise Edition и Certified Security Edition)
Кластер DKP уже развёрнут
и используется
Кластер DKP развёрнут,
но для Stronghold нужен
отдельный
Кластер DKP не развёрнут
Используются другие
технологии, но нужно
отдельное хранилище
секретов

106.

Варианты инсталляции
Кластер DKP
01
02
03
04
Кластер DKP уже развёрнут
и используется
Кластер DKP развёрнут,
но для Stronghold нужен
отдельный
Кластер DKP не развёрнут
Используются другие
технологии, но нужно
отдельное хранилище
секретов

107.

Варианты инсталляции
Кластер DKP
Кластер DKP
01
02
03
04
Кластер DKP уже развёрнут
и используется
Кластер DKP развёрнут,
но для Stronghold нужен
отдельный
Кластер DKP не развёрнут
Используются другие
технологии, но нужно
отдельное хранилище
секретов

108.

Варианты инсталляции
Кластер DKP
01
02
03
04
Кластер DKP уже развёрнут
и используется
Кластер DKP развёрнут,
но для Stronghold нужен
отдельный
Кластер DKP не развёрнут
Используются другие
технологии, но нужно
отдельное хранилище
секретов

109.

Варианты инсталляции
Кластер Vanilla K8s
Серверы / виртуальные машины
01
02
03
Кластер DKP уже развёрнут
и используется
Кластер DKP развёрнут,
но для Stronghold нужен
отдельный
Кластер DKP не развёрнут
CI/CD-системы
04
Используются другие
технологии, но нужно
отдельное хранилище
секретов

110.

Варианты инсталляции
01
Кластер Vanilla K8s
Серверы / виртуальные машины
Кластер DKP
02
03
Кластер DKP уже развёрнут
и используется
Кластер DKP развёрнут,
но для Stronghold нужен
отдельный
Кластер DKP не развёрнут
CI/CD-системы
04
Используются другие
технологии, но нужно
отдельное хранилище
секретов

111.

Приложение и Stronghold в одном кластере
Кластер Deckhouse Kubernetes Platform

112.

Stronghold в отдельном защищённом кластере
Защищённый кластер Deckhouse Kubernetes Platform
Продуктивный кластер
Продуктивный кластер
Продуктивный кластер

113.

Stronghold в контейнерном исполнении
Кластер DKP
Зона 1
Зона 2
Геораспределённый кластер Deckhouse Kubernetes Platform
Зона 3
Кластер Vanilla K8s
Серверы / виртуальные машины
CI/CD-системы

114.

Stronghold в standalone-исполнении
Кластер DKP
Зона 1
Зона 2
Зона 3
Кластер Vanilla K8s
Кластер
ОС Linux
ОС Linux
ОС Linux
Серверы / виртуальные машины
CI/CD-системы

115.

08
Навигационный слайд
Не использовать данный
слайд в презентациях
Системные требования
Вернуться к содержанию

116.

Требуемые ресурсы
Минимальные требования к виртуальной инфраструктуре для развёртывания
Deckhouse Stronghold в кластере Deckhouse Kubernetes Platform
Кол-во
Назначение узла и особенности
OS
vCPU
RAM (GB)
Storage (GB)
● Windows 10+
● macOS 10.15+
● Linux (Ubuntu
18.04+, Fedora 35+)
2
4
50 GB SSD
4
12
50 GB SSD
Bootstrap host — ПК, с которого производится установка:
1х
Установленный Docker для запуска инсталлятора Deckhouse (инструкции
для Ubuntu, macOS, Windows)
HTTPS-доступ до хранилища образов контейнеров registry.deckhouse.io
(установка также возможна и в закрытом окружении)
SSH-доступ по ключу до узла, который будет master-узлом будущего
кластера
Master host — узел под control plane кластера:
3х
Отказоустойчивая конфигурация — 3 master-узла. Для непродуктивных
конфигураций допускается сетап с одним master-узлом
HTTPS-доступ до хранилища образов контейнеров registry.deckhouse.io
(установка также возможна и в закрытом окружении)
SSH-доступ от bootstrap-узла по ключу
На узле не должно быть установлено пакетов container runtime, например
containerd или Docker
Перечень
поддерживаемых ОС
При использовании
Cilium требуется
использовать ядро 5.7+

117.

09
Навигационный слайд
Не использовать данный
слайд в презентациях
Сравнение с конкурентами
Вернуться к содержанию

118.

Сравнение с конкурентами
Stronghold EE
Пространства имён (namespaces)
Межкластерная репликация данных
Автоматическое резервное копирование
данных по заданному расписанию
Поддержка внешних HSM
для двойного шифрования данных
Безопасный auto unseal
без использования внешних KMS
Управление AppRole, OIDC/JWT Role в UI
Встроенная безопасная доставка
секретов в приложения
Сертификация ФСТЭК России
Vault EE
Vault CE
Аналог Vault 1
Аналог Vault 2

119.

Детальное сравнение
с HashiСorp Vault CE

120.

Сравнение Stronghold
с HashiСorp Vault CE
01
Пространства имён
Функционал пространств имён (namespaces), максимально
совместимый с возможностями HashiCorp Vault EE
по возможностям и методам API. Позволяет создавать
дочерние пространства имён и делегировать права
на управление ими
01
Пространства имён
02
Автоматическое
распечатывание (auto unseal)
03
Репликация KV1/KV2
04
Управление AppRole,
OIDC/JWT Role в UI
05
Резервное копирование
данных
06
Поддержка HSM
07
Централизованное управление
кластером
08
Автоконфигурирование
кластера Stronghold
09
Балансировка трафика
10
Доставка секретов
в приложения
11
Автоматическое обновление
версий

121.

Пространства имён
в Vault CE
● Можно гранулярно управлять
доступом к секретам
● Нельзя гранулярно управлять
выдачей прав
Root
namespace

122.

Пространства имён
в Stronghold
Root
namespace
● Можно разделить секреты по разным
пространствам имён
NS: Dept. 2
NS: Dept. 1
Secrets
secrets-team3
secrets-project4
NS: team-1
NS: team-2
Secrets
Secrets
Secrets-team1
Secrets-team2

123.

Пространства имён
в Stronghold
Root
namespace
Userpass
● Можно разделить секреты по разным
пространствам имён
LDAP
NS: Dept. 2
NS: Dept. 1
● В каждом пространстве имён могут
быть свои методы аутентификации
Secrets
Userpass
Userpass
NS: team-1
NS: team-2
Secrets
Secrets
Secrets-team1
Secrets-team2
secrets-team3
secrets-project4

124.

Пространства имён
в Stronghold
Root
namespace
Userpass
● Можно разделить секреты по разным
пространствам имён
LDAP
NS: Dept. 2
NS: Dept. 1
● В каждом пространстве имён могут
быть свои методы аутентификации
Secrets
Userpass
● Можно выдать права на управление
политиками только внутри
пространства имён
Userpass
NS: team-1
NS: team-2
Secrets
Secrets
Secrets-team1
Secrets-team2
Policy 1
Policy 2
secrets-team3
secrets-project4

125.

Пространства имён
в Stronghold
Root
namespace
● Можно разделить секреты по разным
пространствам имён
NS: Dept. 2
NS: Dept. 1
● В каждом пространстве имён могут
быть свои методы аутентификации
Secrets
secrets-team3
● Можно выдать права на управление
политиками только внутри
пространства имён
● Из родительских пространств имён
можно получить доступ к дочерним,
но не наоборот
secrets-project4
NS: team-1
NS: team-2
Secrets
Secrets
Secrets-team1
Secrets-team2
Policy 1
Policy 2

126.

Сравнение Stronghold
с HashiСorp Vault CE
02
Автоматическое распечатывание
(auto unseal)
Узлы кластера распечатывают своих соседей. Unseal-ключи
хранятся только в памяти каждого узла, поэтому если будут
выключены все узлы кластера Stronghold, то нужно будет
произвести ручное распечатывание
01
Пространства имён
02
Автоматическое
распечатывание (auto unseal)
03
Репликация KV1/KV2
04
Управление AppRole,
OIDC/JWT Role в UI
05
Резервное копирование
данных
06
Поддержка HSM
07
Централизованное управление
кластером
08
Автоконфигурирование
кластера Stronghold
09
Балансировка трафика
10
Доставка секретов
в приложения
11
Автоматическое обновление
версий

127.

Сравнение Stronghold
с HashiСorp Vault CE
03
Репликация KV1/KV2
Репликация построена на архитектуре master-slave
с применением pull-модели получения данных — подчинённые
slave-узлы сами опрашивают master-узел
01
Пространства имён
02
Автоматическое
распечатывание (auto unseal)
03
Репликация KV1/KV2
04
Управление AppRole,
OIDC/JWT Role в UI
05
Резервное копирование
данных
06
Поддержка HSM
07
Централизованное управление
кластером
08
Автоконфигурирование
кластера Stronghold
09
Балансировка трафика
10
Доставка секретов
в приложения
11
Автоматическое обновление
версий

128.

Репликация
KV1/KV2
Центральный офис
Редактирование секретов
master_mount
Cluster
HashiCorp
Vault
Региональное отделение
key:Value
secret_path 1
key:Value
secret_path 2
key:Value
secret_path 3
key:Value
replication
key:Value
key:Value
Региональное отделение
key:Value
local_mount
Server
replication
Районное отделение
secret_path 1
key:Value
secret_path 2
key:Value
secret_path 3
key:Value
key:Value
local_mount
Server
secret_path 1
key:Value
secret_path 2
key:Value
secret_path 3
key:Value
key:Value
key:Value
key:Value
key:Value

129.

Репликация KV1/KV2
Построение системы
централизованного
хранения, доставки
и обновления секретов
Резервирование
секретов
Горизонтальное
масштабирование

130.

Сравнение Stronghold
с HashiСorp Vault CE
04
Управление AppRole,
OIDC/JWT Role в UI
Просмотр, удаление, добавление и изменение настроек
для AppRole, OIDC/JWT Role в веб-интерфейсе
01
Пространства имён
02
Автоматическое
распечатывание (auto unseal)
03
Репликация KV1/KV2
04
Управление AppRole,
OIDC/JWT Role в UI
05
Резервное копирование
данных
06
Поддержка HSM
07
Централизованное управление
кластером
08
Автоконфигурирование
кластера Stronghold
09
Балансировка трафика
10
Доставка секретов
в приложения
11
Автоматическое обновление
версий

131.

Управление AppRole, OIDC/JWT Role в UI

132.

Сравнение Stronghold
с HashiСorp Vault CE
05
Резервное копирование данных
В Stronghold администратор через API может задавать
расписание резервного копирования. Копии выполняются
в виде снапшотов и сохраняются как файлы и в S3.
При переносе настроек конфигурация резервного копирования
сохраняется внутри резервных копий
01
Пространства имён
02
Автоматическое
распечатывание (auto unseal)
03
Репликация KV1/KV2
04
Управление AppRole,
OIDC/JWT Role в UI
05
Резервное копирование
данных
06
Поддержка HSM
07
Централизованное управление
кластером
08
Автоконфигурирование
кластера Stronghold
09
Балансировка трафика
10
Доставка секретов
в приложения
11
Автоматическое обновление
версий

133.

Резервное копирование в Vault CE
● Администратор настраивает
скрипты и запускает их
для выполнения резервного
копирования
Скрипты
Администратор
● Внешний сервис-планировщик
вызывает скрипты по расписанию
snapshot
API-запрос
● Скрипты обращаются в Vault
через API и выполняют снапшоты
● Скрипты сохраняют снапшоты
в виде файлов или в S3
Внешний сервиспланировщик
Backups
Backups
Vault
FIle Storage
S3 Storage

134.

Резервное копирование в Stronghold
● Администратор задаёт через API
расписание создания резервных
копий
Метрики состояния,
алерты об ошибках
выполнения резервных
копий
API
Администратор
● Резервное копирование
производится в виде снапшотов
● Данные сохраняются в виде
файлов и в S3
● При переносе настроек файлы
конфигурации сохраняются
внутри резервных копий
Backups
Backups
FIle Storage
S3 Storage

135.

Сравнение Stronghold
с HashiСorp Vault CE
06
Поддержка HSM
В Deckhouse Stronghold реализована поддержка внешних
аппаратных модулей безопасности для шифрования root-ключа
и обеспечения двойного шифрования данных (RSA, AES, ГОСТ)
01
Пространства имён
02
Автоматическое
распечатывание (auto unseal)
03
Репликация KV1/KV2
04
Управление AppRole,
OIDC/JWT Role в UI
05
Резервное копирование
данных
06
Поддержка HSM
07
Централизованное управление
кластером
08
Автоконфигурирование
кластера Stronghold
09
Балансировка трафика
10
Доставка секретов
в приложения
11
Автоматическое обновление
версий

136.

Поддержка HSM и двойное шифрование данных
Кластер
Storage
HSM. Ключ
создан
снаружи
и записан
на токен
Шифрование HSM
(RSA, AES, GOST)
Данные
Двойное
шифрование
(AES + HSM)
Storage
Зашифрованный
через HSM ключ
HSM. Ключ
создан
снаружи
и записан
на токен
Шифрование HSM
(RSA, AES, GOST)
Данные
Двойное
шифрование
(AES + HSM)
Storage
Зашифрованный
через HSM ключ
HSM. Ключ
создан
снаружи
и записан
на токен
Шифрование HSM
(RSA, AES, GOST)
Данные
Двойное
шифрование
(AES + HSM)
Зашифрованный
через HSM ключ

137.

Поддержка HSM и двойное шифрование данных
Кластер 1
Кластер 2
Storage
HSM.
Ключ 1
Данные
Storage
Зашифрованный
через HSM ключ
Репликация
HSM.
Ключ 2
Данные
Один кластер импортирует
данные KV из другого
по HTTPS/REST
Шифрование HSM
(RSA, AES, GOST)
Двойное
шифрование
(AES + HSM)
Шифрование HSM
(RSA, AES, GOST)
Двойное
шифрование
(AES + HSM)
Зашифрованный
через HSM ключ

138.

Сравнение Stronghold
с HashiСorp Vault CE
07
Централизованное
управление кластером
Deckhouse Stronghold функционирует на базе Deckhouse
Kubernetes Platform, что обеспечивает централизованное
управление хранилищем секретов как единым сервисом,
а не множеством обособленных компонентов
01
Пространства имён
02
Автоматическое
распечатывание (auto unseal)
03
Репликация KV1/KV2
04
Управление AppRole,
OIDC/JWT Role в UI
05
Резервное копирование
данных
06
Поддержка HSM
07
Централизованное управление
кластером
08
Автоконфигурирование
кластера Stronghold
09
Балансировка трафика
10
Доставка секретов
в приложения
11
Автоматическое обновление
версий

139.

Сравнение Stronghold
с HashiСorp Vault CE
08
Автоконфигурирование
кластера Stronghold
Генерация конфигурации, сертификатов, сетевых настроек,
auto-discovery сервисов
01
Пространства имён
02
Автоматическое
распечатывание (auto unseal)
03
Репликация KV1/KV2
04
Управление AppRole,
OIDC/JWT Role в UI
05
Резервное копирование
данных
06
Поддержка HSM
07
Централизованное управление
кластером
08
Автоконфигурирование
кластера Stronghold
09
Балансировка трафика
10
Доставка секретов
в приложения
11
Автоматическое обновление
версий

140.

Сравнение Stronghold
с HashiСorp Vault CE
09
Балансировка трафика
DKP имеет встроенные балансировщики L2, L3 и L7.
В зависимости от сценариев можно выбрать,
каким образом будет реализована балансировка трафика —
через ingress-controller или loadbalancer.
Эти компоненты также имеют встроенный мониторинг
01
Пространства имён
02
Автоматическое
распечатывание (auto unseal)
03
Репликация KV1/KV2
04
Управление AppRole,
OIDC/JWT Role в UI
05
Резервное копирование
данных
06
Поддержка HSM
07
Централизованное управление
кластером
08
Автоконфигурирование
кластера Stronghold
09
Балансировка трафика
10
Доставка секретов
в приложения
11
Автоматическое обновление
версий

141.

Сравнение Stronghold
с HashiСorp Vault CE
10
Доставка секретов в приложения
Сквозная интеграция с модулем secrets-store-integration,
разработанным для доставки секретов в приложения,
запущенные в кластере Kubernetes
01
Пространства имён
02
Автоматическое
распечатывание (auto unseal)
03
Репликация KV1/KV2
04
Управление AppRole,
OIDC/JWT Role в UI
05
Резервное копирование
данных
06
Поддержка HSM
07
Централизованное управление
кластером
08
Автоконфигурирование
кластера Stronghold
09
Балансировка трафика
10
Доставка секретов
в приложения
11
Автоматическое обновление
версий

142.

Сравнение Stronghold
с HashiСorp Vault CE
11
Автоматическое обновление версий
DKP поддерживает автоматическое обновление, в том числе
обновление Stronghold. При необходимости обновление можно
перевести в ручной режим
01
Пространства имён
02
Автоматическое
распечатывание (auto unseal)
03
Репликация KV1/KV2
04
Управление AppRole,
OIDC/JWT Role в UI
05
Резервное копирование
данных
06
Поддержка HSM
07
Централизованное управление
кластером
08
Автоконфигурирование
кластера Stronghold
09
Балансировка трафика
10
Доставка секретов
в приложения
11
Автоматическое обновление
версий

143.

10
Навигационный слайд
Не использовать данный
слайд в презентациях
Планы по развитию
Вернуться к содержанию

144.

Roadmap 2026
h1
01
02
03
04
Реализация PKI
с поддержкой ГОСТ
(шифрование
и сертификаты)
Реализация Transit
Secrets Engine
с поддержкой ГОСТ
Доставка секретов
вне платформы
контейнеризации
Performanceрепликация
05
06
07
Поддержка ГОСТ
(КриптоПро CSP,
TLS) в Deckhouse
Stronghold CSE
Оценка влияния
среды
функционирования
в соответствии
с требованиями
ПКЗ-2005
Миграция вебинтерфейса
с Ember.js на Vue
h2

145.

Дорожная карта 2026
04
Performance-репликация
Создание активных геораспределённых кластеров
для ускорения чтения секретов внутри локальных
дата-центров
01
ГОСТ-шифрование
Применение российских криптографических
алгоритмов для Seal wrap, PKI, TLS и Transit
Secrets Engine
02
Беспарольная аутентификация
Поддержка WebAuthn для беспарольной
аутентификации с помощью FIDO2-совместимых
аутентификаторов и Passkeys
03
Управляемые ключи (Managed Keys)
Выполнение операций шифрования
и расшифровки root key с использованием
внешней инфраструктуры управления ключами
05
Миграция UI с Ember.js на Vue
Удобный веб-интерфейс для работы
пользователей, позволяющий, в том числе
работать с legacy-секретами
06
Оценка влияния среды функционирования
Оценка влияния среды функционирования
в соответствии с требованиями ПКЗ-2005,
направленная на проверку того, как компоненты
встроенного средства криптографической защиты
информации (СКЗИ) взаимодействуют
с компонентами Deckhouse Stronghold

146.

Интеграции «из коробки»
CI/CD, инфраструктура
и мониторинг
Базы
данных
Системы
аутентификации
GitLab
Jenkins
MySQL
MSSQL
JWT
LDAP
Ansible
Nexus
Redis
InfluxDB
K8s
AppRole
Kubernetes/OpenShift
MongoDB
Dynatrace
Zabbix
Elasticsearch
Prometheus
ELK
PostgreSQL
Multifactor
OIDC
Userpass

147.

Интеграции «из коробки»
CI/CD,
инфраструктура
и мониторинг
Базы
данных
Системы
аутентификации
Российские
решения
GitLab
Jenkins
MySQL
MSSQL
JWT
LDAP
Multifactor
Рутокен
Ansible
Nexus
Redis
InfluxDB
OIDC
AppRole
RuBackup
Directum
K8s
Pachca
Blitz IdP
Kubernetes/OpenShift
MongoDB
Userpass
Dynatrace
Zabbix
PostgreSQL
MFASoft SAS
Prometheus
ELK
Elasticsearch
PostgresPro
Yandex KMS

148.

Принцип построения любой
интеграции для Stronghold
Внешние ресурсы
Запрос
по HTTPS
● Внешнее приложение, сервис
или пользователь отправляет запрос
по HTTPS для получения доступа к секрету.
Взаимодействие со Stronghold происходит
через API, совместимый с HashiCorp Vault
API. Библиотеки для работы с этим API
существуют для всех языков
программирования

149.

Принцип построения любой
интеграции для Stronghold
Внешние ресурсы
Аутентификация
Запрос
по HTTP/HTTPS
● Внешнее приложение, сервис
или пользователь отправляет запрос
по HTTPS для получения доступа к секрету.
Взаимодействие со Stronghold происходит
через API, совместимый с HashiCorp Vault
API. Библиотеки для работы с этим API
существуют для всех языков
программирования
● Первый тип запроса — аутентификация.
Поддерживаются как встроенные методы
аутентификации (AppRole, Userpass),
так внешние (LDAP, Keycloak, AD и т. д.)

150.

Принцип построения любой
интеграции для Stronghold
Внешние ресурсы
Аутентификация
Запрос
по HTTP/HTTPS
Авторизация
● Внешнее приложение, сервис
или пользователь отправляет запрос
по HTTPS для получения доступа к секрету.
Взаимодействие со Stronghold происходит
через API, совместимый с HashiCorp Vault
API. Библиотеки для работы с этим API
существуют для всех языков
программирования
● Первый тип запроса — аутентификация.
Поддерживаются как встроенные методы
аутентификации (AppRole, Userpass),
так внешние (LDAP, Keycloak, AD и т. д.)
● Второй тип запроса — работа с секретом
(запись, чтение, изменение). Stronghold
предоставляет доступ к секретам
на основании правил, хранящихся
внутри системы

151.

Принцип построения любой
интеграции для Stronghold
Внешние ресурсы
Аутентификация
Запрос
по HTTP/HTTPS
Авторизация
Зашифрованные
AES-256 секреты
● Внешнее приложение, сервис
или пользователь отправляет запрос
по HTTPS для получения доступа к секрету.
Взаимодействие со Stronghold происходит
через API, совместимый с HashiCorp Vault
API. Библиотеки для работы с этим API
существуют для всех языков
программирования
● Первый тип запроса — аутентификация.
Поддерживаются как встроенные методы
аутентификации (AppRole, Userpass),
так внешние (LDAP, Keycloak, AD и т.д.)
● Второй тип запроса — работа с секретом
(запись, чтение, изменение). Stronghold
предоставляет доступ к секретам
на основании правил, хранящихся
внутри системы
● Для повышения безопасности данных
секреты хранятся в зашифрованном виде
с применением криптостойкого алгоритма
AES-256

152.

07
Навигационный слайд
Не использовать данный
слайд в презентациях
ФСТЭК-редакция
Вернуться к содержанию

153.

Deckhouse Stronghold CSE
Безопасность без компромиссов

154.

Сертификат ФСТЭК России
№ 5038 от 10 февраля 2026 г.
● Соответствие требованиям по безопасности информации,
устанавливающим уровни доверия к средствам
технической защиты информации и средствам
обеспечения безопасности информационных технологий
(утверждены приказом ФСТЭК России № 76 от 2 июня
2020 г.
), — по 4-му уровню доверия
● Cоответствие техническим условиям RU.86432418.0000201 ТУ 02

155.

Позволяет обеспечить:
01
Безопасность информации на значимых объектах
критической информационной инфраструктуры
до 1-й категории значимости включительно
02
Безопасность персональных данных
в информационных системах до 1-го уровня
защищённости включительно
03
Безопасность информации в государственных
информационных системах до 1-го класса
защищённости включительно
04 Безопасность информации в автоматизированных
Сертифицированное
ФСТЭК России решение
для безопасного управления
жизненным циклом секретов
системах управления производственными
и технологическими процессами на критически
важных объектах, потенциально опасных объектах,
а также объектах, представляющих повышенную
опасность для жизни и здоровья людей
и для окружающей природной среды,
до 1-го класса защищённости включительно

156.

Защита информации на значимых объектах КИИ *
●Здравоохранени
е
●Наука
●Транспорт
●Связь
Энергетика
Металлургия
Атомная энергетика
Банковский сектор
и финансы
Химическая
промышленность
Оборонная
и ракетно-космическая
промышленность
Топливноэнергетический
комплекс
Горнодобывающая
промышленность
* До 1-й категории значимости включительно согласно приказу ФСТЭК России № 239 от 25 декабря 2017 г. «Об утверждении требований по обеспечению безопасности
значимых объектов критической информационной инфраструктуры Российской Федерации». Список отраслей регламентирован в пункте 8 статьи 2 Федерального закона
от 26 июля 2017 г. № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»

157.

Защита ПДн, обрабатываемых операторами *
Операторы
сотовой связи
●Банки и финансовые
учреждения
●Центры верификации
данных
●Медицинские
и образовательные
учреждения
Государственные
и муниципальные
органы власти
Интернет-провайдеры
Транспортные компании
Ретейл и e-commerce
Страховые компании
* В ИС до 1-го уровня защищённости включительно согласно приказу ФСТЭК России № 21 от 18 февраля 2013 г. «Об утверждении состава и содержания организационных
и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»

158.

Защита информации в ГИСах *
Федеральные и региональные
органы исполнительной власти
Органы государственной
власти субъектов Российской
Федерации
Министерства и ведомства
Органы местного
самоуправления и другие
* До 1-го класса защищённости включительно согласно приказу ФСТЭК России № 17 от 11 февраля 2013 г. «Об утверждении требований о защите информации,
не составляющей государственную тайну, содержащейся в государственных информационных системах» и методическому документу от 11 февраля 2014 г.
«Меры защиты информации в государственных информационных системах»

159.

Защита информации в автоматизированных
системах управления *
Топливноэнергетический
комплекс
●Химическая
промышленность
Транспортные системы
Системы водоснабжения
Коммунальные службы
Металлургия
Добыча природных
ресурсов
Атомная энергетика
Здравоохранение
* До 1-го класса защищённости включительно согласно приказу ФСТЭК России от 14 марта 2014 г. № 31 «Об утверждении Требований к обеспечению защиты информации
в автоматизированных системах управления производственными и технологическими процессами на критически важных объектах, потенциально опасных объектах,
а также объектах, представляющих повышенную опасность для жизни и здоровья людей и для окружающей природной среды»

160.

Дорожная карта
H1’2026
H2’2026-2027
Дополнить сертифицированную версию Deckhouse
Stronghold функцией шифрования ГОСТ в части seal
wrap с использованием внешнего криптопровайдера
(КриптоПро CSP) и в части TLS
Провести оценку влияния среды функционирования
в соответствии с требованиями ПКЗ-2005, направленную
на проверку того, как компоненты встроенного средства
криптографической защиты информации (СКЗИ)
взаимодействуют с компонентами Deckhouse Stronghold
Результат:
Результат:
Реализована возможность использовать российские
криптографические алгоритмы для шифрования
секретов, а также обеспечивать зашифрованный
обмен данными между сервером и клиентом
Получено положительное заключение испытательной
лаборатории и переданы материалы в ФСБ России
для оформления заключения о признании решения
соответствующим требованиям по эксплуатации СКЗИ

161.

Внесение изменений
и обновления Deckhouse
Stronghold CSE
01
Новые версии Deckhouse Stronghold CSE выпускаем
примерно раз в полгода. Информацию о новых
версиях Deckhouse Stronghold CSE, а также
инструкции по обновлению размещаем
на нашем сайте
02
Внесение изменений в Deckhouse Stronghold CSE,
связанных с добавлением новых функций
безопасности информации, или изменений
в имеющиеся функции безопасности информации
проводим с привлечением испытательной
лаборатории
03
При внесении в Deckhouse Stronghold CSE
изменений, не связанных с функциями безопасности,
испытания проводим самостоятельно
04 Находимся в процессе получения сертификата
соответствия процедурам разработки безопасного
программного обеспечения (РБПО). Сертификат
позволит проводить все испытания самостоятельно

162.

Процесс устранения
уязвимостей Deckhouse
Stronghold CSE
01
В случае обнаружения недостатков (уязвимостей)
в Deckhouse Stronghold CSE в течение 48 часов
разрабатываем компенсирующие меры по защите
информации или ограничения по применению
Deckhouse Stronghold CSE, направленные
на снижение возможности эксплуатации выявленных
недостатков (уязвимостей)
02
Доработка Deckhouse Stronghold CSE, в том числе
разработка обновлений или разработка мер
по защите информации, нейтрализующих
недостаток, выполняется в течение 60 дней
с момента выявления недостатка
03
Сообщить об уязвимости в Deckhouse Stronghold
CSE можно через форму на сайте по адресу:
deckhouse.ru/report-request

163.

Вебинар
Подтверждённая
безопасность секретов:
Deckhouse Stronghold получил
сертификат ФСТЭК России
Вебинар
Владимир Девятайкин
Ильдар Гарипов
Менеджер продукта
Deckhouse Stronghold
Руководитель отдела
информационной безопасности

164.

Документ
Перечень угроз ИБ
и соответствующих им функций ИБ СЗИ
Deckhouse Stronghold CSE
Документ

165.

Документ
Меры по обеспечению
безопасности для ЗО КИИ
и соответствие реализации данных мер
в Deckhouse Stronghold CSE
Документ

166.

Формат поставки
Компонент
Вид поставки
Дистрибутив ПО
В электронном виде на USB-накопителе
Формуляр
На бумаге
Технические условия
В электронном виде на USB-накопителе
Руководство администратора
В электронном виде на USB-накопителе
Руководство пользователя
В электронном виде на USB-накопителе

167.

Ответы на часто
задаваемые
вопросы
01
Какие среды исполнения поддерживаются?
Deckhouse Stronghold CSE можно запустить в различных
сертифицированных средах (платформа контейнеризации:
Deckhouse Kubernetes Platform CSE; операционные системы:
РЕД ОС, ALT Linux, Astra Linux Special Edition).
02
Как происходит миграция с Deckhouse
Stronghold EE на Deckhouse Stronghold CSE?
На сайте опубликована документация
по переходу
с Deckhouse Stronghold EE на Deckhouse Stronghold CSE.
Процедура перехода между редакциями отработана.
Вам необходимо обратиться к нам в сервисную поддержку.
Сервисная команда отработает по каждому конкретному запросу.
Далее по стандартной инструкции запускается процесс миграции.
Переключение происходит практически без прерываний.

168.

Ответы на часто
задаваемые
вопросы
03
Как перейти с HashiCorp Vault на Deckhouse
Stronghold CSE?
Написать ответ
04
Чем отличаются редакции Enterprise Edition
и Certified Security Edition?
С точки зрения функциональных возможностей обе редакции
практически идентичны. Есть два критерия, по которым они
отличаются. Deckhouse Stronghold CSE:
● имеет сертификат соответствия требованиям приказа ФСТЭК
России № 76 по 4-му уровню доверия;
● имеет более ограниченный перечень поддерживаемых ОС.
Поддерживаются: РЕД ОС, ALT Linux, Astra Linux Special Edition.
Не поддерживается: РОСА Сервер. Точный перечень
поддерживаемых ОС указан в формуляре на продукт.

169.

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

170.

Лицензирование,
поддержка
и обучение

171.

Формирование предложения
Полные правила лицензирования
доступны по ссылке
Параметры
Метрики
Гарантийная ТП
Тип лицензии
● Количество Установок
Бессрочная
● Количество Клиентов
Право на получение
обновлений и доступ
к обучению
Срочная (12, 24, 36 мес.)
Редакции
Enterprise Edition
Certified Security Edition
Техподдержка**
Стандарт (8/5)
Стандарт+ (24/7)
Включена в лицензии:
● Срочная/бессрочная
лицензия
на инсталляции
● Дополнительная
лицензия
на обновления
(для бессрочных
лицензий)
** В соответствии с единым
регламентом ТП для всех
продуктов Deckhouse

172.

Метрики лицензирования
Доступ к внешним
ресурсам
Продукт лицензируется
по совокупности двух метрик
● Количество Установок
Deckhouse Stronghold,
развёрнутых в инфраструктуре
конечного пользователя
Пользователи
Приложение
Аутентификация
Аутентификация
Сервис 1
Для редакций:
Enterprise Edition
Certified Security Edition
Сервис 2

173.

Метрики лицензирования
Доступ к внешним
ресурсам
Продукт лицензируется
по совокупности двух метрик
● Количество Установок
Deckhouse Stronghold,
развёрнутых в инфраструктуре
конечного пользователя
● Количество Клиентов,
использующих Deckhouse
Stronghold для аутентификации
Пользователи
Приложение
Аутентификация
Аутентификация
Сервис 1
Для редакций:
Enterprise Edition
Certified Security Edition
Сервис 2

174.

Deckhouse Stronghold
Инсталляция 2
Entity 1
Entity 2
Deckhouse Stronghold
Login/pass
Инсталляция 1
Entity 1
Login/pass
Entity 99
Entity 2
Write
Entity 3
Read
Secret 1
Kubernetes 1
Entity 10
Entity 6
JWT
Subject: e-mail
Entity 11
Entity 4
Entity 5
Entity …
Entity 7
Entity 8
Kubernetes 2
Kubernetes Cluster 1
Kubernetes Cluster 2
Service Account
Service Account
JWT
Subject: project
Entity 9
AppRoles
Service Account
AppRole 1
AppRole 2

175.

Как правильно посчитать метрики
● Клиент — приложение, сервис или
пользователь, для которых назначен
уникальный набор прав на доступ к секретам
Deckhouse Stronghold
● Клиентов разных типов лучше считать
отдельно
● Количество Vault Entities = количество
клиентов в Stronghold
● Реплики одного приложения используют
один Service Account и всегда считаются
за 1 клиента
Entity 1
Entity 2
Deckhouse Stronghold
Login/pass
Login/pass
● Клиентом считается «сущность»
с уникальными credentials.
Если 2 приложения обращаются в Stronghold
с одними кредами / аутентифицируются
одинаковым методом, они идентифицируются
как 1 приложение
Инсталляция 1
Entity 1
Entity 99
Entity 2
Write
Entity 3
Read
Secret 1
Kubernetes 1
Entity …
Entity 10
Entity 6
JWT
Subject: e-mail
Entity 11
Entity 4
Entity 5
● Если пользователь заходит под OIDC
и заходит под LDAP, то по умолчанию их надо
считать как отдельных клиентов.
Но технически их можно объединить в alias,
если допускается один и тот же набор прав
Инсталляция 2
Entity 7
Entity 8
Kubernetes 2
Kubernetes Cluster 1
Kubernetes Cluster 2
Service Account
Service Account
JWT
Subject: project
Entity 9
AppRoles
Service Account
AppRole 1
AppRole 2

176.

Техническая поддержка.
Гарантийная
Единый стандарт обслуживания
лицензий продуктов экосистемы
Deckhouse: постоянный доступ
к обновлениям Deckhouse и Kubernetes
Предоставляется совместно
со всеми видами лицензий:
Доступ к новому функционалу
В рамках новых релизов
Исправление выявленных уязвимостей
и ошибок
В рамках еженедельных релизов
Срочные лицензии
Связь с командой Deckhouse
Включено на весь срок действия
лицензии
Личный кабинет с возможностью предложить улучшения
Deckhouse и/или сообщить об ошибках в работе
Бессрочные лицензии
Включено в стоимость
лицензии на заданный период
с возможностью продления
(в формате дополнительной
лицензии)
Доступ к обучающим материалам
Неограниченный доступ к курсам для быстрого освоения
продуктов Deckhouse

177.

Техническая поддержка.
Стандарт
Предоставляется при наличии действующей
гарантийной технической поддержки
● Помощь при развёртывании и первоначальной настройке
● Консультации по вопросам эксплуатации
Необходима помощь при развёртывании
и эксплуатации на основе практического
опыта
● Инженеры поддержки — DevOps'ы с многолетним
практическим опытом поддержки кластеров наших клиентов
Необходима поддержка продуктивных
окружений
● Помощь в поиске обходных решений и устранении ошибок
Прямой контакт с опытными DevOpsинженерами
● Консультации и поддержка — 8/5
● 4 уровня критичности для обращений
● SLA на время ответа
От 1 рабочего часа (для критичных обращений) до 48 часов
Для редакций:
Enterprise Edition
Certified Security Edition

178.

Техническая поддержка.
Стандарт+
Предоставляется при наличии действующей
гарантийной технической поддержки
● Помощь при развёртывании и первоначальной настройке
● Консультации по вопросам эксплуатации
Необходима помощь при развёртывании
и эксплуатации на основе практического
опыта
● Инженеры поддержки — DevOps'ы с многолетним
практическим опытом поддержки кластеров наших клиентов
Необходима поддержка продуктивных
окружений
● Помощь в поиске обходных решений и устранении ошибок
Поддержка критичных приложений
● Консультации и поддержка — 24/7
24/7 прямой контакт с опытными DevOpsинженерами
● 4 уровня критичности для обращений
● SLA на время ответа
От 1 часа (для критичных обращений) до 8 часов
Для редакций:
Enterprise Edition
● Наличие выделенного архитектора
Certified Security Edition

179.

Формирование спецификации
для первой покупки
01
02
03
04
05
06
Выбрать редакцию
Stronghold
Выбрать тип
лицензии
Выбрать срок
лицензии или доступа
к обновлениям (ГТП)*
Выбрать количество
инсталляций
Выбрать количество
клиентов
Выбрать вариант
технической
поддержки
EE
Срочная
12–36 мес.
CSE
Бессрочная
12–60 мес.
Доп. бессрочная
* Срочные лицензии
доступны в вариантах
на 12, 24 и 36 мес.
Для бессрочных
лицензий при первой
покупке можно
выбрать срок доступа
к обновлениям (ГТП)
в диапазоне 12–
60 мес.
1–…
50
Стандарт
100
Стандарт+
200
500
1000

180.

Формирование спецификации
для первой покупки
Состав итоговой спецификации
Лицензия на инсталляцию
Deckhouse Stronghold
Лицензия на количество
клиентов
Количество лицензий = количество
инсталляций*
Пакеты клиентов
1–…
* 1 инсталляция включает
50 клиентов
Техническая поддержка
SLA по регламенту
ВАЖНО!
50
100
200
500
1000
Сертификаты технической
поддержки должны покрывать
всех приобретённых клиентов
Оказание ТП может быть
приостановлено, если
сертификаты ТП не покрывают
всех клиентов

181.

Формирование спецификации
для расширения числа клиентов
01
02
03
04
05
06
Выбрать редакцию
Stronghold
Выбрать тип
лицензии
Выбрать срок
лицензии или доступа
к обновлениям (ГТП)*
Выбрать количество
инсталляций
Выбрать количество
клиентов
Выбрать вариант
технической
поддержки
EE
Срочная
12–36 мес.
CSE
Бессрочная
12–60 мес.
Доп. бессрочная
* Срочные лицензии
доступны в вариантах
на 12, 24 и 36 мес.
Для бессрочных
лицензий при первой
покупке можно
выбрать срок доступа
к обновлениям
в диапазоне 12–
60 мес.
1-…
50
Стандарт
100
Стандарт+
200
500
1000

182.

Формирование спецификации
для расширения числа клиентов
Состав итоговой спецификации
Лицензия на инсталляцию
Deckhouse Stronghold
Лицензия на количество
клиентов
Количество лицензий = количество
инсталляций*
Пакеты клиентов
1–…
* 1 инсталляция включает
50 клиентов
Техническая поддержка
SLA по регламенту
ВАЖНО!
50
100
200
500
1000
Необходимо докупать
сертификаты ТП в зависимости
от количества приобретаемых
клиентов

183.

Формирование спецификации
для доступа к обновлениям
01
02
03
04
05
06
Выбрать редакцию
Stronghold
Выбрать тип
лицензии
Выбрать срок
лицензии или доступа
к обновлениям (ГТП)*
Выбрать количество
инсталляций
Выбрать количество
клиентов
Выбрать вариант
технической
поддержки
EE
Срочная
12–36 мес.
CSE
Бессрочная
12 мес.
Доп. бессрочная
* Срочные лицензии
доступны в вариантах
на 12, 24 и 36 мес.
Продление доступа
к обновлениям
для ранее купленных
бессрочных лицензий
возможно только
на 12 мес. за одну
покупку
1–…
50
Стандарт
100
Стандарт+
200
500
1000

184.

Формирование спецификации
для доступа к обновлениям
Состав итоговой спецификации
Лицензия на инсталляцию
Deckhouse Stronghold
Лицензия на количество
клиентов
Количество лицензий = количество
инсталляций*
Пакеты клиентов
1–…
* 1 инсталляция включает
50 клиентов
Техническая поддержка
SLA по регламенту
ВАЖНО!
100
Оказание ТП может
быть приостановлено,
если завершился срок
действия ГО
200
Можно не продлевать ТП
и остаться только на ГТП
50
500
1000

185.

Deckhouse Академия
deckhouse.ru/academy
Программа бесплатного ознакомительного
видеотренинга Deckhouse Stronghold
Знакомство с Deckhouse
Stronghold
● Что такое секреты и почему их важно защищать
Базовые аспекты работы с секретами,
преимущества продукта, политика
лицензирования
● Основные возможности продукта и его преимущества
● Целевые клиенты
● Политика лицензирования
Бесплатно
Программа бесплатного технического
курса Deckhouse Stronghold
Установка и настройка
Deckhouse Stronghold
● Включение и подготовка Deckhouse Stronghold
Включение и подготовка, возможности работы
с секретами, доставка секретов в приложения,
работа с SSH
● Возможности работы с секретами
● Доставка секретов в приложение
● Возможности работы с SSH
Бесплатно
По запросу
Посмотреть курс

186.

Мы умеем хранить
секреты!
Telegram
contact@deckhouse.ru
+7 (495) 721-10-27
deckhouse.ru
RuTube
Блог

187.

Отказ от ответственности
Информация, изложенная в настоящем материале/презентации, представлена
в ознакомительных целях и не является ни основанием для принятия коммерчески
значимых решений, ни персональным либо публичным предложением к заключению
каких-либо соглашений или договоров.
В связи с тем, что планы и решения касаемо возможностей осуществления процесса
разработки и релиза указанных программных продуктов и/или их отдельных модулей
остаются на усмотрение АО «Флант», настоящим мы не предоставляем каких-либо
явных и/или подразумеваемых заверений об обстоятельствах либо гарантий
касаемо, в том числе, но не ограничиваясь, функциональных характеристик,
описания, коммерческих условий и возможности разработки, релиза
и распространения программных продуктов.

188.

12
Навигационный слайд
Не использовать данный
слайд в презентациях
Архив слайдов
Вернуться к содержанию