FAQ

Общие вопросы

Можно ли восстановить доступ без сервисного аккаунта, обычным пользователем?

Да, в упрощённом ручном виде: администратор создаёт обычного пользователя, фиксирует его мастер-пароль и делит его на доли самостоятельно через passwork-cli shamir split, а при восстановлении собирает пароль обратно и вручную выдаёт доступ. Автоматизированных команд create-service-account/grant-admin этот вариант не использует — подробности в разделе Упрощённый вариант без сервисных аккаунтов.

Нужна ли отдельная лицензия для этой схемы?

Для автоматизированного варианта на сервисном аккаунте — да, нужна лицензия с поддержкой сервисных аккаунтов (флаг «Сервисные аккаунты», обычно Расширенная редакция). Без неё passwork-cli users create-service-account завершится с кодом 10. Упрощённый вариант на обычном пользователе лицензии не требует.

Обязательно ли включать клиентское шифрование?

Да. Схема имеет смысл только при включённом Zero-Knowledge — иначе сервер и так может выдать доступ штатными средствами администрирования. При выключенном клиентском шифровании настройка (create-service-account --m/--n) завершится с кодом 7, а recovery grant-admin — с кодом 7 при выявлении на сервере.

Настройка

Что если забыть указать --m/--n при создании сервисного аккаунта?

Команда создаст обычный сервисный аккаунт и выведет его мастер-ключ прямо в терминал (с предупреждением) — без деления на доли. Для схемы Шамира всегда указывайте оба флага.

Кто выпускает API-токен сервисного аккаунта?

passwork-cli этого не делает. Токен выпускается в веб-интерфейсе — в карточке пользователя-сервисного аккаунта, во вкладке API-токены. Подробности — в разделе Настройка.

Обязательно ли шифровать доли под RSA-ключи держателей?

Нет, но рекомендуется. Без --holder-pubkey-dir доли записываются в открытом виде — тогда безопасность канала передачи каждому держателю целиком лежит на вас. С шифрованием под RSA держателя доля бесполезна для всех, кроме владельца соответствующего приватного ключа.

Покрытие сейфов

Сейф создан до настройки схемы — он получит доступ автоматически?

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

Как проверить, что покрытие настроено правильно?

Отдельной команды проверки нет. Откройте сейф в веб-интерфейсе и убедитесь, что сервисный аккаунт есть в списке администраторов, либо проведите тестовое восстановление на некритичном сейфе того же типа.

Можно ли использовать разные аккаунты восстановления для разных типов сейфов и несколько аккаунтов на один тип?

Да, оба варианта поддерживаются: поле Администраторы политики доступа — это список, поэтому один аккаунт восстановления можно подключить сразу к нескольким типам, а к одному типу — подключить несколько независимых аккаунтов восстановления (например, с разными порогами M из N). Подробности — в разделе Политики доступа к сейфам.

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

Что если долей меньше порога M?

recovery grant-admin завершится с кодом 6 («доли несовместимы или их недостаточно»). Сервер не изменяется, доступ никому не выдаётся.

Что если кто-то подделал или подменил долю?

Реконструкция даст неверный секрет, который не пройдёт проверку на сервере — команда завершится с кодом 8 («ошибка аутентификации, расшифровки или сейфа»), и сервер не изменяется.

Можно ли запустить recovery grant-admin повторно, если уже выполняли его для этого сейфа и пользователя?

Да, безопасно. Если целевой пользователь уже администратор сейфа, повторный запуск завершается успешно как no-op — но добавляет новую запись и в продуктовую Историю действий, и в локальный журнал восстановления.

Что если долей записано не по одной на строку в файле?

Проверьте файл кворума: shares-file должен содержать ровно одну долю на строку. Склейка файлов через cat share1 share2 без перевода строки между ними даёт одну длинную строку и приводит к коду завершения 6. Используйте printf '%s\n' "$(cat share1)" "$(cat share2)".

Аудит

Где посмотреть, кто и когда запускал восстановление?

Локальный журнал passwork-cli (по умолчанию ~/.passwork/recovery-audit.log) содержит детали церемонии — порог, количество использованных долей, результат. Продуктовая История действий содержит факт выдачи доступа от имени сервисного аккаунта. Оба журнала связаны через activity_log_correlation_id. Подробности — в разделе Аудит и коды завершения.

Для упрощённого варианта на обычном пользователе такого локального журнала нет — см. примечание в разделе Аудит и коды завершения.

Что будет, если журнал восстановления недоступен для записи?

Операция не выполнится вовсе: recovery grant-admin завершится с кодом 9 до попытки выдать доступ. Это намеренное ограничение — операция без следа в аудите не выполняется.

Ротация и компрометация

Держатель доли уволился или скомпрометирован — что делать?

Лёгкой замены отдельного держателя в v1 нет. Нужно создать новый сервисный аккаунт восстановления с новым набором держателей, подключить его к администраторам типа, убедиться в полном покрытии, а затем вывести старый аккаунт из администраторов и удалить его. Подробнее — в разделе Модель безопасности и рекомендации.

Можно ли добавить одному держателю сразу несколько долей?

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

Модель угроз

Защищает ли схема от сговора держателей?

Нет, и это не баг. Модель безопасности схемы — «доверие M из N держателей»: если M легитимных держателей объединяются, они могут инициировать восстановление к любому сейфу, покрытому политикой. Это ожидаемое, штатное поведение порогового восстановления — если ваша модель угроз требует защиты и от сговора кворума, нужен дополнительный контроль сверх самой схемы Шамира. Подробный разбор — в разделе Модель безопасности и рекомендации.

Версия для LLM