Упрощённый вариант без сервисных аккаунтов

Когда применять этот вариант

Лицензия с флагом «Сервисные аккаунты» не нужна — этот вариант работает на любой редакции. Плата за доступность — ручная работа на каждом шаге и заметно более высокая цена ошибки оператора (см. предупреждения ниже и Модель безопасности). Если сервисные аккаунты доступны, предпочтителен автоматизированный вариант из раздела Настройка сервисного аккаунта.

Идея

Офлайн-примитивы passwork-cli shamir split/recover и rsa gen-keys/encrypt/decrypt не привязаны к сервисным аккаунтам — это самостоятельные инструменты, которые делят на доли любую base64-строку. В автоматизированном варианте ими делится мастер-ключ сервисного аккаунта, а create-service-account/grant-admin берут на себя всё остальное — обращения к API, аутентификацию, выдачу прав. В этом варианте те же примитивы делят мастер-пароль обычного пользователя, а всё остальное администратор выполняет вручную, штатными средствами продукта.

Шаг 1. Держатели создают RSA-ключи

Точно так же, как в автоматизированном варианте — см. Шаг 1 раздела «Настройка сервисного аккаунта». Эти ключи не зависят от выбранного варианта.

Шаг 2. Создание учётной записи восстановления

Создайте обычного пользователя через веб-интерфейс или API — так же, как любого другого сотрудника, но с одним отличием: мастер-пароль для него должен сгенерировать и сразу зафиксировать администратор, а не сам будущий владелец при первом входе.

Мастер-пароль виден только один раз

Если Пассворк генерирует пароль автоматически при создании, он показывается один раз в момент создания и не хранится нигде в открытом виде — ни на сервере, ни в интерфейсе повторно. Если вы его не запишете сразу, придётся создавать учётную запись заново.

Полученный мастер-пароль временно сохраните в файл — он нужен только для следующего шага и должен быть удалён сразу после:

printf '%s' "$MASTER_PASSWORD" | base64 > secret.b64

shamir split принимает секрет в base64, поэтому пароль (произвольная строка) нужно закодировать явно — в отличие от create-service-account, где кодированием мастер-ключа занимается сама команда.

Мастер-ключ вместо мастер-пароля

Если вместо пароля хотите зафиксировать сам производный мастер-ключ (по аналогии с сервисным аккаунтом), получите его через Python SDK функцией деривации ключа из пароля и передайте в shamir split тем же образом. Это не обязательно: восстановление пароля достаточно для входа, а мастер-ключ Пассворк всё равно выведет из него на клиенте при следующем входе.

Шаг 3. Деление секрета на доли

passwork-cli shamir split \
  --key-file secret.b64 \
  --m 3 --n 5 \
  --holder-pubkey-dir pubkeys/ \
  --out-dir shares/

Флаги те же, что и в автоматизированном варианте (см. таблицу флагов) — команда не различает, чей секрет делится. После выполнения:

shred -u secret.b64        # или rm -P / аналог на вашей ОС

Секрет-файл и переменная MASTER_PASSWORD должны быть удалены из окружения оператора сразу после деления — дальше единственная копия пароля существует только в виде M-из-N долей у держателей.

Шаг 4. Подключение к политике доступа

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

Раздача долей

Как и в автоматизированном варианте — каждому держателю только его файл доли, хранение отдельно от учётных данных самого пользователя-аккаунта восстановления. См. Шаг 5 раздела «Настройка сервисного аккаунта».

Восстановление при инциденте

Держатели расшифровывают и передают доли оператору восстановления так же, как в Шаге 1–2 автоматизированного варианта. Дальше — отличие: вместо recovery grant-admin оператор восстанавливает секрет напрямую и входит под ним:

passwork-cli shamir recover \
  --shares-file quorum.txt \
  --out-file recovered-secret.b64

base64 -d recovered-secret.b64   # получить исходный мастер-пароль в виде текста

Дальше — обычный вход в продукт:

1. Оператор входит в веб-интерфейс (или через SDK) под логином и восстановленным паролем учётной записи восстановления.
2. Под этой учётной записью, уже имеющей права администратора в нужной политике доступа, выдаёт доступ уровня Администратор к целевому сейфу целевому пользователю штатным способом продукта (через UI или API) — так же, как обычный администратор выдаёт доступ вручную.
3. Немедленно после выдачи доступа оператор выходит из-под учётной записи восстановления и удаляет восстановленный пароль (recovered-secret.b64, переменные окружения, буфер обмена).

Восстановленный пароль — это полноценные учётные данные

В отличие от сервисного аккаунта, у этой учётной записи есть обычный интерактивный вход. Пока восстановленный пароль существует в открытом виде (в файле, буфере обмена, истории команд), он равнозначен полной компрометации контура восстановления — тот, кто им завладеет, может войти под этой учётной записью так же, как оператор. Обращайтесь с ним как с любой другой раскрытой учётной записью администратора: минимальное время жизни в открытом виде, немедленная зачистка после использования. Подробнее — в Модели безопасности.

Аудит

CLI не пишет автоматический локальный журнал для этого варианта — команды shamir split/recover не принимают --audit-file/--syslog, эти флаги есть только у create-service-account и grant-admin. Фиксируйте факт и параметры церемонии (дату, состав кворума, целевой сейф и пользователя) отдельно — вручную или скриптом-обвязкой поверх shamir split/recover. Подробнее о том, что при этом видно в продукте — в разделе Аудит и коды завершения.

Версия для LLM