Во многих сценариях развертывания Deckhouse Stronghold клиенты напрямую обращаются к Stronghold и используют возвращаемые секреты. Однако в некоторых ситуациях может быть целесообразнее разделить привилегии таким образом, чтобы одна доверенная сторона отвечала за взаимодействие с большей частью API Stronghold и передавала секреты конечному потребителю.

Чем больше посредников задействовано в передаче секрета, тем выше риск случайного раскрытия, особенно если секрет передаётся в открытом виде. Например, если необходимо доставить закрытый TLS-ключ на машину, где по политике безопасности нельзя хранить ключ дешифрования в постоянном хранилище. В этом случае невозможно зашифровать ключ перед передачей.

Для решения подобных задач в Stronghold предусмотрена функция обёртывания ответа(response wrapping). Вместо того чтобы сразу вернуть ответ HTTP-клиенту, Stronghold сохраняет его в cubbyhole. Доступ к содержимому есть только у одноразового токена, который Stronghold возвращает клиенту.

С логической точки зрения, ответ оборачивается токеном, который нужно распаковать, чтобы получить доступ к данным. С функциональной точки зрения, токен авторизует доступ к «ключнице» Stronghold и позволяет расшифровать данные.

Этот метод обеспечивает надёжный механизм обмена информацией в разнообразных средах. Обёртывание ответа решает три ключевые задачи:

  • Скрытие секретной информации. Передаваемое по сети значение не является самим секретом, а лишь токеном доступа к нему. Даже если данные перехвачены или попали в логи, они не содержат конфиденциальной информации.
  • Обнаружение злоупотреблений. Токен можно распаковать только одна сторона. Если клиент получил токен, который не распаковывается, это повод инициировать инцидент безопасности. Перед распаковкой клиент может проверить происхождение токена через Stronghold.
  • Ограничение срока действия. У токена есть своё время жизни (TTL), отдельное от TTL секрета (и часто гораздо короче). Если клиент не распакует токен вовремя, срок его действия истечёт.

Токены обёртывания ответа

При обёртывании исходный ответ Stronghold на API-запрос не возвращается напрямую. Вместо этого клиент получает следующий набор данных о токене:

  • TTL — срок жизни токена;
  • токен — значение токена;
  • время создания — момент генерации токена;
  • путь создания — API-эндпойнт, вызвавший генерацию ответа;
  • идентификатор обёрнутого токена — указывает на обёрнутый токен (например, при аутентификации или создании нового токена). Это полезно, например, для систем оркестрации (таких как Nomad), поскольку позволяет управлять сроком действия токена без его раскрытия.

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

Даже если злоумышленник перенаправит клиента на поддельный сервер, он сможет подменить открытый ключ подписи. В теории можно кешировать ранее действительный ключ, но в этом случае нужно кешировать и ранее действительный адрес (в большинстве случаев адрес Stronghold не изменится или будет установлен с помощью механизма обнаружения сервисов).

Таким образом, Stronghold опирается на сам факт того, что токен не содержит чувствительных данных и потому не требует подписи.

Операции с токенами обёртывания

Через путь sys/wrapping/ доступны следующие операции с токенами обёртывания:

  • Поиск (sys/wrapping/lookup) — возвращает время создания токена, путь и TTL. Путь не требует аутентификации. Держатель токена всегда может запросить свойства токена по этому пути.
  • Распаковка (sys/wrapping/unwrap) — распаковывает токен, возвращая хранящийся внутри ответ в исходном API-формате.
  • Повторное обёртывание (sys/wrapping/rewrap) — позволяет заново обернуть уже обёрнутые данные в новый токен. Это полезно для секретных данных с длительным сроком жизни. Например, в случае, если организация хочет (или обязана — в случае требований безопасности), чтобы ключ корневого центра сертификации бэкэнда pki возвращался в долгоживущем токене, тем самым исключая раскрытие ключа (что легко проверить, выполнив поиск по токену), но также хочет иметь доступ к ключу для подписи CRL на случай, если они изменят или потеряют pki-монтирование. Часто требования безопасности обязывают соблюдать ротацию секретов, и эта операция позволяет выполнить ротацию без риска раскрытия данных.
  • Обёртывание (sys/wrapping/wrap) — возвращает данные в виде токена обёртывания.

    Даже при ограничении доступа к этому пути обёртывание данных возможно через другие API-методы Stronghold.

Создание токена обёртывания

Обёртывание ответа выполняется для каждого запроса отдельно и запускается путем указания желаемого TTL. TTL задаётся клиентом с помощью заголовка X-Vault-Wrap-TTL и может быть целым числом (в секундах) или строкой (15s, 20m, 25h). В Stronghold CLI для этого используется параметр -wrap-ttl. В Go API за это отвечает функция SetWrappingLookupFunc, которая сообщает API условия, при которых следует запрашивать обёртывание, путем сопоставления операции и пути с желаемым TTL.

Процесс обёртывания:

  1. Исходный HTTP-ответ сериализуется.
  2. Генерируется одноразовый токен с TTL, заданным клиентом.
  3. Ответ сохраняется в cubbyhole, связанный с токеном.
  4. Генерируется новый ответ с дополнительным полем, содержащем информацию о токене (ID, TTL и путь).
  5. Новый ответ возвращается клиенту.

Минимальный и максимальный TTL токенов обёртывания регулируется политиками.

Проверка токена обёртывания

Чтобы снизить риски злоупотреблений, рекомендуется проверять токены обёртывания согласно следующей процедуре:

  1. Если клиент ожидал токен, но он не поступил, есть вероятность того, что токен был перехвачен злоумышленником. Начните расследование инцидента.
  2. Выполните поиск токена. Если токен истёк или был отозван, это не всегда значит утечку (например, клиент слишком долго запускался). Однако, расследование всё равно требуется. Используя журнал аудита Stronghold, проверьте, распаковывался ли токен.
  3. Сверьте путь создания токена с ожидаемым. Если вы ожидали после распаковки получить TLS-ключ или сертификат, скорее всего путь должен быть следующим: pki/issue/.... Несоответствие пути может означать подмену токена обёртывания (наиболее вероятно, если путь начинается с cubbyhole или sys/wrapping/wrap).

    Уделите особое внимание механизму секретов kv. Если вы ожидаете, что секрет будет поступать из secret/foo, а злоумышленник передаёт токен с путём secret/bar, проверки префикса secret/ будет недостаточно.

  4. После проверки префикса распакуйте токен. Если распаковка невозможна, это повод начать расследование инцидента.

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