Механизмы Stronghold помогают выполнить типовые требования информационной безопасности. В таблицах ниже для каждой группы требований указаны механизм, редакция, в которой он доступен, и страница с его настройкой. Используйте их при подготовке модели угроз, технического задания или комплекта документов для аттестации.
Соответствие информационной системы требованиям регуляторов определяется всей системой в целом: архитектурой, организационными мерами и настройками всех компонентов. Наличие механизма в Stronghold не означает, что требование выполнено автоматически.
Сертификация и реестры
| Документ | Сведения | Редакция |
|---|---|---|
| Сертификат ФСТЭК России | Сертификат №5038 от 10.02.2026 на ПО Deckhouse Stronghold (версия 1.16). Соответствие требованиям Приказа ФСТЭК России №76 по 4 уровню доверия | Stronghold CSE |
| Единый реестр российских программ | Запись №22339 от 24.04.2024 | — |
Сведения о сертификате и реестре приведены также в истории изменений и на странице «Редакции».
Сопоставление требований и механизмов
| Группа требований | Механизм Stronghold | Редакция | Где настроить |
|---|---|---|---|
| Идентификация и аутентификация пользователей и сервисов | Методы аутентификации LDAP, OIDC, JWT, Kubernetes, AppRole, userpass, token, WebAuthn | Все | Методы аутентификации |
| Аутентификация через внешний SAML 2.0 IdP | Stronghold EE | SAML | |
| Многофакторная аутентификация (TOTP, Multifactor) | Все | MFA | |
Блокировка учётной записи после неудачных попыток входа (user_lockout) | Все | Секция user_lockout | |
| Единая сущность пользователя для нескольких методов входа | Все | Идентификационные данные (Identity) | |
| Управление доступом | ACL-политики с запретом по умолчанию, явный deny с наивысшим приоритетом | Все | Политики |
| Токены с ограниченным сроком действия и отзывом | Все | Токены | |
| Изоляция конфигурации и секретов между подразделениями, блокировка Namespace API | Stronghold EE | Пространства имён | |
| Выдача прав администраторам по группам IdP в Deckhouse Platform (DP) | Все | Управление доступами | |
| Регистрация событий безопасности | Журнал аудита всех запросов к API и ответов (устройства file, syslog, socket) | Все | Аудит |
| Хеширование чувствительных данных в журнале (HMAC-SHA256) | Все | Схема записей журнала аудита | |
| Фильтрация записей и исключение полей | Все | Фильтрация, исключение полей | |
| Криптографическая защита данных при хранении | Криптографический барьер AES-256-GCM | Все | Криптоалгоритмы |
| Защита root-ключа в HSM (PKCS #11) или Yandex Cloud KMS | HSM — Stronghold EE | HSM, Yandex Cloud KMS | |
| Дополнительное шифрование критичных данных (seal wrap) | Stronghold EE | Двойное шифрование | |
| Разделение ключа распечатывания (Shamir), смена ключей (rekey) | Все | Seal и unseal | |
| Криптографическая защита данных при передаче | TLS 1.2/1.3, проверка клиентских сертификатов (mTLS) | Все | Криптоалгоритмы, секция listener |
TLS 1.3 с ГОСТ-шифрованием, ГОСТ-алгоритмы в PKI и Transit | Stronghold EE | ГОСТ-алгоритмы | |
| Управление ключами и сертификатами | Выпуск сертификатов, шифрование и подпись как сервис, управляемые ключи во внешних системах | PKI, Transit — все; Managed Keys — Stronghold EE | PKI, Transit, Managed Keys |
| Управление жизненным циклом секретов | Динамические учётные данные с ограниченным сроком жизни, ротация и отзыв | Все | Аренды, механизмы секретов баз данных |
| Политики сложности генерируемых паролей | Все | Политика паролей | |
| Целостность | Контроль целостности данных барьером AES-GCM | Все | Криптоалгоритмы |
| Проверка SHA256 бинарных файлов внешних плагинов | Все | Плагины | |
| Изменение конфигурации только по кворуму подписей Git-коммитов | Stronghold EE | Механизм секретов GitOps | |
| Проверка консистентности снимков | Все | Проверка снимка | |
| Резервное копирование и восстановление | Ручные снимки Raft-хранилища | Все | Создание снимка, восстановление |
| Снимки по расписанию в локальное или S3-совместимое хранилище | Stronghold EE | Автоматические снимки | |
| Доступность и отказоустойчивость | HA-кластер на integrated Raft | Все | Установка |
| Performance standby, performance-репликация (PR) и репликация для аварийного восстановления (DR) | Stronghold EE | Репликация | |
| Восстановление при потере кворума Raft | Все | Standalone, DP |
Требования российского законодательства
Ниже перечислены нормативные документы, которые обычно учитывают при внедрении систем управления секретами. Применимость и конкретные меры определяются для вашей системы отдельно.
| Нормативный документ | Как Stronghold помогает выполнить требования |
|---|---|
| Приказ ФСТЭК России №76 (требования по безопасности информации, устанавливающие уровни доверия) | Stronghold CSE сертифицирован по 4 уровню доверия (сертификат №5038) |
| Федеральный закон №152-ФЗ «О персональных данных» и требования к защите ПДн | |
| Федеральный закон №187-ФЗ «О безопасности КИИ» | |
| Требования к ГИС (Приказ ФСТЭК России №17) | |
| Использование отечественного ПО | Запись в Едином реестре российских программ №22339 |
| Криптографическая защита по ГОСТ | Stronghold EE поддерживает ГОСТ-алгоритмы в TLS, PKI и Transit. В Stronghold CSE ГОСТ-алгоритмы для PKI/Transit не поддерживаются. Сравнение редакций приведено на странице «Редакции». |
Настройки безопасности
Чтобы снизить риск компрометации, примените следующие настройки Stronghold:
- Включите как минимум два аудит-устройства и передавайте журналы в SIEM.
- Ограничьте минимальную версию TLS значением
tls12. - Храните ключи распечатывания и восстановления раздельно у нескольких ответственных лиц.
- Используйте короткий срок жизни токенов и динамические секреты вместо статических.
- Настройте автоматические снимки с хранением вне защищаемого кластера и регулярно проверяйте восстановление.
- Не используйте root-токен для повседневной работы: выполняйте администрирование под учётными записями с назначенными политиками.