Запечатывание и распечатывание

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

Распечатывание — это процесс получения открытого root-ключа, необходимого для чтения ключа расшифровки. До распечатывания доступны только операции распечатывания Stronghold и проверки статуса сервера.

Зачем это нужно?

Stronghold шифрует данные ключом шифрования (в keyring) и сохраняет их в бэкенде хранения. Чтобы защитить этот ключ шифрования, Stronghold шифрует его другим ключом — root-ключом — и хранит вместе с данными.

Чтобы расшифровать данные, Stronghold нужен root-ключ: с его помощью расшифровывается ключ шифрования. Распечатывание — это получение доступа к этому root-ключу. Stronghold шифрует root-ключ с помощью unseal-ключа и хранит его вместе с остальными данными Stronghold.

Итого: большинство данных Stronghold шифрует ключом шифрования из keyring. Чтобы получить keyring, Stronghold расшифровывает его root-ключом. Сам root-ключ расшифровывается unseal-ключом.

Seal на основе Shamir

Вместо передачи оператору одного целого unseal-ключа конфигурация Stronghold по умолчанию использует алгоритм Shamir’s Secret Sharing, который разделяет ключ на доли (shares).

Для восстановления unseal-ключа Stronghold требует определённый порог (threshold) долей. Операторы добавляют доли по одной в любом порядке, пока Stronghold не наберёт достаточно долей для восстановления ключа. Затем Stronghold использует unseal-ключ для расшифровки root-ключа. Это и есть процесс распечатывания Stronghold.

Распечатывание

Процесс распечатывания можно выполнить командой d8 stronghold operator unseal или через API. Процесс распечатывания сохраняет состояние: каждую долю можно ввести разными способами с разных клиентских машин. Так каждая доля root-ключа может храниться на отдельной клиентской машине — это повышает безопасность.

При использовании Shamir seal в кластере с несколькими узлами каждый узел нужно распечатать отдельно, набрав требуемый порог долей. Stronghold не распространяет частично распечатанное состояние узлов по кластеру.

Исключение — механизм seal "inner-cluster": распечатанные узлы кластера могут распечатывать другие узлы, указанные в конфигурации.

После распечатывания узел Stronghold остаётся распечатанным, пока не произойдёт одно из следующего:

1. Вы запечатаете его через API.
2. Вы перезапустите сервер.
3. Слой хранения Stronghold столкнётся с неустранимой ошибкой.

Распечатывание узлов усложняет автоматизацию установки Stronghold. Автоматизированные инструменты легко устанавливают, настраивают и запускают Stronghold, но распечатывание через Shamir seal без дополнительной автоматизации — ручной процесс. Для большинства пользователей удобнее автоматическое распечатывание через внешний KMS или HSM либо встроенный механизм inner-cluster.

Запечатывание

При запечатывании через API Stronghold удаляет root-ключ из памяти, и для его восстановления снова требуется распечатывание. Для запечатывания Stronghold достаточно одного оператора с root-привилегиями.

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

Автоматическое распечатывание

Автоматическое распечатывание (auto unseal) снижает операционную сложность безопасного хранения unseal-ключа. В Stronghold доступны два подхода:

1. Внешний доверенный сервис или устройство (KMS, HSM): при запуске Stronghold подключается к нему и запрашивает расшифровку root-ключа из хранилища.
2. Встроенный гибридный механизм seal "inner-cluster": узлы кластера распечатывают друг друга на основе Shamir, без внешнего KMS.

Помимо распечатывания есть операции Stronghold, для которых нужен кворум пользователей — например, генерация root-токена. При использовании Shamir seal для авторизации таких операций нужны unseal-ключи. При автоматическом распечатывании через внешний KMS или HSM для этих операций требуются recovery-ключи.

Как инициализация Shamir seal выдаёт unseal-ключи, так инициализация с auto unseal на базе внешнего KMS или HSM выдаёт recovery-ключи.

Узел Stronghold по-прежнему можно запечатать через API. После вызова API Stronghold остаётся запечатанным, пока вы не перезапустите его или не используете API распечатывания. Для auto unseal через KMS или HSM нужны фрагменты recovery-ключа вместо фрагментов unseal-ключа, которые даёт Shamir seal. Сам процесс тот же.

Примеры и поддерживаемые провайдеры внешнего auto unseal см. в разделе KMS и HSM.

Автоматическое распечатывание через inner-cluster

В редакциях Enterprise Edition (EE) и Certified Security Edition (CSE) Stronghold поддерживает встроенное автоматическое распечатывание кластера без внешних сервисов и KMS.

Механизм seal "inner-cluster" — гибридный: он опирается на Shamir, но распечатанные узлы кластера распечатывают другие узлы, перечисленные в конфигурации. Если узел распечатан, то он будет периодически опрашивать указанные в конфигурации ноды и вводить в них части Shamir-ключа.

Конфигурация

Чтобы включить механизм, задайте в конфигурационном файле секцию seal "inner-cluster". Внутри неё опишите узлы, которые участвуют в распечатывании, в блоках node.

Параметры блока node:

Пример конфигурации:

seal "inner-cluster" {
  node {
    name            = "stronghold-1"
    address         = "http://127.0.0.1:8200"
    token           = ""
    tls_ca_cert     = ""
    tls_skip_verify = true
  }
  node {
    name            = "stronghold-2"
    address         = "http://127.0.0.2:8200"
    token           = ""
    tls_ca_cert     = ""
    tls_skip_verify = true
  }
  node {
    name            = "stronghold-3"
    address         = "http://127.0.0.3:8200"
    token           = ""
    tls_ca_cert     = ""
    tls_skip_verify = true
  }
}

Recovery-ключ

При инициализации Stronghold с HSM или KMS оператору возвращаются recovery-ключи, а не unseal-ключи. Stronghold генерирует recovery-ключи из внутреннего recovery-ключа, разделённого через Shamir’s Secret Sharing — так же, как обрабатываются unseal-ключи без HSM или KMS.

При выполнении операций вроде generate-root, которые используют recovery-ключи, Stronghold автоматически выбирает recovery-ключи для этой цели, а не unseal-ключи барьера.

Инициализация

При инициализации Stronghold разделяет ключ согласно следующим флагам CLI и их аналогам в API-эндпоинте /sys/init:

• recovery-shares — число долей, на которые делится recovery-ключ. Эквивалентно значению recovery_shares в API.
• recovery-threshold — порог долей, необходимый для восстановления recovery-ключа. Эквивалентно значению recovery_threshold в API.
• recovery-pgp-keys — PGP-ключи для шифрования возвращаемых долей recovery-ключа. Эквивалентно значению recovery_pgp_keys в API; как и у pgp_keys, в API это массив, а не строка.

Если эти параметры не заданы, Stronghold не инициализируется и не генерирует ключи. Подробнее см. в разделе HSM.

Смена ключей (rekey)

Unseal-ключ

Unseal-ключи Stronghold можно сменить операцией d8 stronghold operator rekey из CLI или соответствующими вызовами API. Операция rekey авторизуется при наборе порога recovery-ключей. После rekey Stronghold шифрует новый ключ барьера настроенным HSM или KMS и сохраняет его в бэкенде хранения.

Recovery-ключ

Recovery-ключ можно сменить, чтобы изменить число долей или порог либо передать доли другим держателям с другими PGP-ключами. В CLI Stronghold rekey выполняется флагом -target=recovery у команды d8 stronghold operator rekey.

Через API rekey выполняется с теми же параметрами, что и обычный эндпоинт /sys/rekey; однако префикс API для rekey recovery-ключа — /sys/rekey-recovery-key, а не /sys/rekey.

Миграция seal

Миграцию seal нельзя выполнить без простоя. Из‑за технических особенностей реализаций seal на время процесса нужно кратко остановить весь кластер. Простой может быть неизбежен, но смена seal — редкое событие, и кратковременный простой обычно приемлем.

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

Во время миграции должны быть доступны и старый, и новый seal. Например, при миграции с auto unseal на Shamir сервис, обеспечивающий auto unseal, должен быть доступен на время миграции.

Общая процедура миграции

Следующие шаги общие для миграций между поддерживаемыми типами seal и для любого бэкенда хранения.

1. Остановите standby-узел и обновите конфигурацию seal.

   • Если миграция с Shamir seal на auto seal — добавьте в конфигурацию блок нового auto seal.
   • Если миграция с auto seal на Shamir seal — добавьте disabled = true в блок старого seal.
   • Если миграция с auto seal на другой auto seal — добавьте disabled = true в блок старого seal и добавьте блок нового auto seal.

   Затем поднимите standby-узел и выполните команду unseal для каждого ключа с флагом -migrate.

   • Передайте Shamir unseal-ключи, если старый seal был Shamir: они мигрируют как recovery-ключи для auto seal.
   • Передайте recovery-ключи, если старый seal был auto seal: они мигрируют как recovery-ключи нового auto seal либо как Shamir unseal-ключи, если новый seal — Shamir.

2. Выполните шаг 1 для всех standby-узлов по одному. Каждый остановленный standby-узел нужно вернуть в строй до перехода к следующему, особенно при интегрированном хранилище — так сохраняется кворум.

3. Передайте лидерство с активного узла. Один из standby-узлов станет новым активным. При интегрированном хранилище убедитесь, что Stronghold набрал кворум и выбрал лидера.

4. Новый активный узел выполняет миграцию. Следите за логами сервера на активном узле, чтобы увидеть завершение миграции seal. При интегрированном хранилище немного подождите репликации сведений о миграции на все узлы. В Enterprise-редакциях смена auto seal означает повторную обёртку (rewrap) seal-wrapped записей хранилища. Следите за логами и дождитесь завершения. Ищите в логах seal re-wrap completed.

1. Миграция seal завершена. Остановите старый активный узел, обновите его конфигурацию так, чтобы в ней остались только блоки нового seal (без сведений о старом типе), и поднимите узел снова. При новом auto seal он распечатается автоматически; при Shamir потребуются unseal-ключи.

2. Теперь можно обновить конфигурационные файлы всех узлов так, чтобы в них была только информация о новом seal. Standby-узлы можно перезапустить сразу; активный узел — после смены лидерства.

Миграция: дополнительные сценарии

Миграция с Shamir на auto unseal

Чтобы мигрировать с ключей Shamir на auto unseal, остановите кластер серверов и обновите seal соответствующей конфигурацией. Поднимите сервер, остальные узлы в multi-server режиме оставьте офлайн, затем выполните распечатывание с флагом -migrate и поднимите остальной кластер.

Во всех командах unseal должен быть указан флаг -migrate. После ввода требуемого порога unseal-ключей Stronghold мигрирует unseal-ключи в recovery-ключи.

d8 stronghold operator unseal -migrate

Миграция с auto unseal на Shamir

Чтобы мигрировать с auto unseal на ключи Shamir, остановите кластер серверов и обновите конфигурацию seal, добавив disabled = true в блок seal. Этот флаг позволяет миграции использовать эти сведения для расшифровки ключа, но не распечатывает Stronghold.

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

Миграция с auto unseal на auto unseal

Чтобы мигрировать с auto unseal на другую конфигурацию auto unseal, остановите кластер серверов, обновите существующую конфигурацию seal и добавьте disabled = true в блок seal. Затем добавьте ещё один блок seal с описанием нового seal.

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

Миграция с интегрированным хранилищем

Интегрированное хранилище использует протокол Raft, которому нужен кворум онлайн-серверов, прежде чем кластер станет работоспособным. Поэтому поочерёдный подъём узлов кластера с обновлённой конфигурацией seal в этом случае не подходит.

Следуйте тем же шагам для каждого вида миграции, описанным выше, с одним исключением: после остановки кластера обновите конфигурации seal на всех узлах и поднимите их все сразу. Когда кворум узлов снова онлайн, Raft выбирает лидера, и лидер выполняет миграцию. Сведения о миграции реплицируются всем пирам кластера. Когда пир позже становится лидером, миграция на нём повторно не выполняется.