Seal wrap — это механизм дополнительного шифрования чувствительных данных поверх обычного криптографического барьера хранилища. В документации Stronghold его можно рассматривать как двойное шифрование: данные сначала защищаются встроенным барьером Stronghold, а затем дополнительно оборачиваются через используемый seal-механизм.
Такой подход особенно полезен в сценариях с повышенными требованиями к защите ключевого материала, а также в инфраструктурах, где используются внешние KMS- или HSM-устройства.
Что даёт seal wrap
Дополнительный слой шифрования может быть полезен для:
- повышения защищённости критически важных параметров;
- соответствия внутренним требованиям безопасности и регуляторным политикам;
- сценариев, где корневой материал и наиболее чувствительные значения должны дополнительно защищаться внешним
seal-механизмом; - интеграции Stronghold в инфраструктуры с KMS или HSM.
Как это работает
При использовании seal wrap Stronghold сохраняет часть данных не только в зашифрованном виде внутри хранилища, но и с дополнительной обёрткой через поддерживаемый seal.
Это означает:
- root key и другие критические параметры получают дополнительный уровень защиты;
- часть значений в механизмах аутентификации и секретных движках может храниться в seal-wrapped виде;
- сама логика репликации и хранения для клиента остаётся прозрачной, но операции чтения и записи таких значений могут становиться дороже по времени.
Какие данные обычно seal-wrapped
Двойное шифрование применяется прежде всего к критическим security-параметрам внутри core Stronghold, включая:
- root key;
- keyring;
- recovery key и связанные с распечатыванием данные;
- другие внутренние критические параметры Stronghold.
Кроме того, поддерживающие backend-ы и плагины могут использовать seal wrap для хранения отдельных чувствительных значений.
LDAPPKIдля ключей и issuer-данных;SSHдля ключей CA;Transitдля ключей и их политик;
Включение и отключение
Для поддерживаемых seal-механизмов seal wrap в Vault включён по умолчанию. В Stronghold отключить дополнительное шифрование для данных, кроме root key, можно параметром:
disable_sealwrap = trueЭтот параметр описан в настройке Standalone-конфигурации.
Важно учитывать:
- отключение
seal wrapне отключает защиту root key черезseal; - изменение
disable_sealwrapдействует постепенно, по мере чтения и перезаписи данных; - повторное включение также происходит постепенно, а не мгновенно для всего хранилища.
Sealwrap rewrap
При изменении конфигурации seal Stronghold должен заново обернуть все seal-wrapped значения, чтобы они соответствовали актуальной конфигурации шифрования. Этот процесс называется seal rewrap.
Rewrap особенно полезен:
- после миграции на новый
seal; - после изменения параметров
seal-конфигурации; - после ротации ключевого материала во внешнем KMS или HSM.
Для работы с процессом rewrap в API Stronghold доступны endpoint-ы:
| Метод | Путь |
|---|---|
GET | /sys/sealwrap/rewrap |
POST | /sys/sealwrap/rewrap |
GET /sys/sealwrap/rewrapвозвращает статус процесса и счётчики обработанных записей;POST /sys/sealwrap/rewrapзапускает процесс rewrap, если он ещё не выполняется.
Пример запроса:
curl \
--header "X-Vault-Token: ${VAULT_TOKEN}" \
--request POST \
"${VAULT_ADDR}/v1/sys/sealwrap/rewrap"Во время rewrap:
- процесс выполняется в фоне;
- прогресс удобно отслеживать через
GET /sys/sealwrap/rewrapи логи сервера; - в период выполнения не стоит вносить новые изменения в
seal-конфигурацию.
Длительность rewrap зависит от числа seal-wrapped записей и характеристик внешнего seal-backend-а.
Ограничения и особенности эксплуатации
seal wrapработает только при использованииseal, который поддерживает эту возможность;- если используется внешний HSM или удалённый KMS, операции с seal-wrapped значениями могут быть заметно медленнее обычных;
- на практике это особенно важно для write-heavy сценариев и для инфраструктур с нестабильной связностью до HSM/KMS;
- если внешний
sealнедоступен во время работы, это может повлиять на часть операций Stronghold.
Seal wrap и репликация
Механизм seal wrap находится ниже уровня логики репликации. Это означает, что:
- репликация передаёт данные и признак необходимости
seal wrap; - конкретная реализация дополнительного шифрования выполняется локальным
seal-механизмом на каждой стороне; - разные кластеры могут использовать разные локальные ключи KMS или HSM, сохраняя общую модель защиты.
Практические рекомендации
- Используйте
seal wrap, если у вас есть требования к дополнительной защите ключевого материала. - Перед включением в production учитывайте влияние на производительность.
- Для HSM-интеграций заранее проверяйте стабильность доступа к устройству.
- Изменение
disable_sealwrapлучше выполнять контролируемо и с пониманием, что перешифровка происходит постепенно.