На этой странице описано, чему Stronghold доверяет, от чего защищают его механизмы и какие риски остаются за администратором. Модель угроз совместима с моделью HashiCorp Vault. Устройство компонентов описано на странице «Обзор архитектуры».
Защищаемые активы
Stronghold защищает следующие активы:
- Секреты и ключи, которые хранят и выдают механизмы секретов (KV, PKI, Transit, SSH, базы данных и другие).
- Связка ключей барьера и root-ключ.
- Ключи распечатывания (доли Shamir), ключи восстановления и root-токены.
- Токены клиентов и учётные данные методов аутентификации.
- Журналы аудита.
Границы доверия
На схеме показаны границы доверия установки Stronghold:
- Клиенты и сеть не считаются доверенными. Каждый запрос должен пройти TLS, проверку токена и политик.
- Бэкенд хранения не считается доверенным: он видит только шифртекст. То же относится к снимкам Raft, трафику Raft между узлами и потоку репликации.
- Процесс Stronghold в распечатанном состоянии — доверенная зона. В его памяти находятся связка ключей, root-ключ и открытые данные.
- Seal — внешняя доверенная зона: держатели долей Shamir, HSM или KMS, которые защищают root-ключ.
- Операционная среда — сервер, ОС, гипервизор, а в Deckhouse Platform (DP) — кластер Kubernetes и узлы, на которых хранятся данные Stronghold (по умолчанию master-узлы) — считается доверенной. Её компрометация равна компрометации Stronghold.
От чего защищают механизмы Stronghold
| Угроза | Механизм | Результат |
|---|---|---|
| Кража диска, директории данных или снимка Raft | Криптографический барьер AES-256-GCM | Без ключей распечатывания или доступа к seal данные не расшифровать. |
| Изменение данных в хранилище | Аутентифицированное шифрование AES-GCM | Изменение шифртекста обнаруживается при чтении. |
| Перехват трафика клиентов, между узлами и между кластерами | TLS на listener и кластерном порту, шифрование барьером | Данные передаются по TLS, а в Raft и репликации — ещё и в виде шифртекста. |
| Компрометация одного держателя ключа распечатывания | Shamir’s Secret Sharing, порог -key-threshold | Одной доли недостаточно для распечатывания и генерации root-токена. |
| Кража root-ключа из хранилища | Seal: Shamir, HSM (pkcs11, Stronghold EE), Yandex Cloud KMS (Stronghold EE) | Root-ключ хранится зашифрованным, ключ seal не покидает HSM или KMS. |
| Расшифровка ключевого материала при компрометации связки ключей барьера | Seal wrap (Stronghold EE) | Root-ключ, связка ключей, ключ восстановления и отдельные значения PKI, SSH, Transit, LDAP дополнительно зашифрованы через seal. |
| Доступ клиента к чужим секретам | Токены и политики ACL, запрет по умолчанию | Клиент получает только пути и операции, разрешённые его политиками. |
| Длительное использование утёкших учётных данных | Аренды и TTL, отзыв токенов и аренд | Динамические секреты и токены истекают и отзываются, в том числе каскадно. |
| Утечка секретов через журналы аудита | Хеширование HMAC-SHA256 с солью аудит-устройства | Чувствительные значения не попадают в журнал в открытом виде. |
| Выгрузка памяти процесса в swap | mlock | Страницы памяти не попадают на диск, если mlock не отключён параметром disable_mlock. В модуле DP disable_mlock = true, поэтому эта защита там не действует. |
От чего механизмы не защищают
| Угроза | Почему не защищает | Как снизить риск |
|---|---|---|
| Компрометация root-токена или токена с широкими политиками | Барьер и seal не участвуют в авторизации: токен даёт всё, что разрешают его политики. | В standalone-установке не храните root-токен после первичной настройки, выдавайте его через operator generate-root по кворуму. В DP в режиме Automatic root-токен нужен автоконфигуратору stronghold-automatic, поэтому его не отзывают; следуйте мерам из угрозы компрометации кластера DP ниже. Назначайте минимальные политики, короткие TTL, MFA, привязку токенов к CIDR. |
| Компрометация распечатанного узла (root на сервере, дамп памяти, отладчик) | Связка ключей и открытые данные находятся в памяти процесса. | Изолируйте серверы Stronghold, ограничьте доступ root и отладку, не отключайте mlock при наличии незашифрованного swap. |
| Сговор или компрометация кворума держателей ключей распечатывания или восстановления | Кворум по определению может распечатать хранилище и сгенерировать root-токен. | Распределите доли между независимыми людьми, храните их раздельно, выполняйте rekey при смене держателей. |
| Администратор HSM или KMS вместе с копией хранилища | Кто управляет ключом seal и имеет данные, тот может распечатать копию. | Разделите роли администраторов HSM/KMS и хранилища, защищайте снимки отдельно. |
Компрометация кластера DP (режим Automatic) | В режиме Automatic секрет stronghold-keys в неймспейсе d8-stronghold содержит root-токен и ключ распечатывания; компрометация секрета даёт административный доступ ко всему хранилищу. В режиме Manual секрета stronghold-keys нет. Данные лежат на узлах, где хранятся данные Stronghold (по умолчанию master-узлы). | Ограничьте RBAC к неймспейсу d8-stronghold и доступ к узлам, запретите нецелевые exec и чтение томов, включите Kubernetes audit. Затем выберите один из вариантов: забрать ключи и удалить секрет stronghold-keys из кластера; забрать ключи и выполнить ротацию ключа распечатывания и root-токена; либо использовать режим Manual. Храните ключи вне кластера в защищённом контуре. Подробнее — на странице «Развёртывание в DP». |
Подмена IP клиента через listener 8500 (DP, инлеты Ingress и GatewayAPI) | Listener на порту 8500 требует клиентский сертификат (mTLS), но доверяет X-Forwarded-For от любого адреса (x_forwarded_for_authorized_addrs = "0.0.0.0/0"). При компрометации mTLS-клиента или неверной модели доверия к proxy IP клиента можно подменить, что влияет на токены с привязкой к CIDR и на аудит. | Ограничьте доступ к порту 8500 доверенными сетями (NetworkPolicy, межсетевой экран) и используйте X-Forwarded-For только при строго определённой цепочке proxy. |
| Секреты после выдачи клиенту | Stronghold не контролирует, что приложение делает с полученными данными. | Используйте динамические секреты с короткими TTL, обёртывание ответа, Stronghold Agent. |
| Потеря или удаление ключа seal | Ключи восстановления не расшифровывают root-ключ. Без механизма seal кластер не восстановить даже из резервной копии. | Строго контролируйте управление ключами HSM и KMS, выполняйте миграцию seal до вывода ключа из эксплуатации. |
| Отказ в обслуживании | Потеря кворума Raft или блокирующее аудит-устройство останавливают обработку запросов. | Используйте не менее трёх узлов, несколько аудит-устройств, резервное копирование и DR-репликацию. |
| Действия легитимного администратора | Администратор с широкими политиками может изменить конфигурацию и политики. | Включите аудит сразу после инициализации, передавайте журналы во внешнюю систему, используйте GitOps с кворумом подписей для изменения конфигурации (Stronghold EE). |
Меры защиты
Чтобы снизить описанные выше риски, примите следующие меры:
- Выпускайте для listener сертификаты доверенного CA и проверяйте их на клиентах. Параметры TLS и ГОСТ-шифров описаны в разделе «Криптография».
- Разрешайте только необходимые соединения по таблицам на странице «Сетевые порты».
- Используйте автоматическое распечатывание через HSM или Yandex Cloud KMS, если нужно исключить ручную работу с долями ключей, и включайте seal wrap для ключевого материала.
- Настраивайте доступ через методы аутентификации и политики с минимальными правами, а не через общие токены.
- Включите не менее двух аудит-устройств.
- Храните резервные копии вне защищаемой системы и защищайте их так же, как само хранилище.