Версия: 7.0

Модель безопасности и рекомендации

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

Активы и доверительные границы

Актив	Где существует	Кто/что доверено
Секрет аккаунта восстановления (мастер-ключ сервисного аккаунта или мастер-пароль пользователя)	Только в момент деления и в момент восстановления, в памяти процесса `passwork-cli`	Оператор настройки / оператор восстановления, кратковременно
Доли (share) секрета, N штук	Файлы у держателей, при передаче — зашифрованы RSA держателя	Каждый держатель — только свою долю
Приватный RSA-ключ держателя	Локально у держателя	Только сам держатель
API-токен сервисного аккаунта (только для варианта на сервисном аккаунте)	Файл у оператора восстановления	Оператор восстановления
Ключи сейфов (продуктовая криптография Пассворка)	На сервере в зашифрованном виде, в открытом — только на клиенте в момент операции	Сервер не видит открытый ключ сейфа никогда
Локальный журнал восстановления (JSONL)	Файл на машине оператора	Оператор, экспорт в SIEM
История действий (Activity Log)	На сервере Пассворка	Администраторы с доступом к аудиту

Доверительная граница проходит между сервером Пассворка (не видит открытые ключи и секреты — модель Zero-Knowledge) и клиентскими машинами держателей и операторов, где секреты кратковременно существуют в открытом виде. Схема Шамира добавляет вторую границу — ни один держатель по отдельности не пересекает порог доверия, необходимый для реконструкции.

Модель угроз (STRIDE)

Категория	Угроза	Как обрабатывается в схеме	Остаточный риск
Spoofing (подмена личности)	Злоумышленник выдаёт себя за держателя и присылает произвольную долю	`shamir recover` проверяет совместимость всех долей (общие M, N) — заведомо неверная доля вызывает код 6, а не тихую подмену секрета	Доля от настоящего, но недобросовестного держателя неотличима от честной — подлинность держателя схема не проверяет, это организационный контроль (личная передача, известный канал)
Spoofing	Злоумышленник получает API-токен сервисного аккаунта (только вариант на сервисном аккаунте)	Токен один не даёт доступа к данным — нужен ещё реконструированный мастер-ключ	Токен — предпосылка атаки при последующей утечке долей; храните как критичный секрет (см. рекомендации)
Tampering (модификация)	Подмена содержимого файла доли на диске или при передаче	Доли, зашифрованные под RSA держателя, при подмене не расшифруются или дадут доли, несовместимые между собой (код 6)	Незашифрованные доли (без `--holder-pubkey-dir`) подмену содержимого не обнаруживают — используйте RSA-шифрование долей везде, где это возможно
Tampering	Модификация локального журнала восстановления оператором постфактум	Журнал append-only, `0600`, отклоняет запись через символическую ссылку	Нет криптографической защиты от подмены (нет подписи записей, нет WORM-хранилища) — оператор физически может отредактировать файл на своей машине; единственная защита — экспорт в независимый SIEM в момент операции
Repudiation (отказ от авторства)	Держатель заявляет, что не передавал свою долю, либо оператор отрицает участие в церемонии	Локальный журнал фиксирует `operator_identity`, время, состав кворума (по числу, не поимённо)	Журнал не фиксирует личности держателей пофамильно — только количество использованных долей; для юридически значимого разбора нужен отдельный организационный протокол передачи долей (акт, подписи)
Information disclosure (утечка)	Компрометация одной доли	Одной доли принципиально недостаточно для реконструкции секрета при M ≥ 2 — это математическое свойство схемы, а не эвристика	Компрометация M и более долей эквивалентна полной компрометации секрета; чем ниже M относительно N, тем быстрее достигается этот порог
Information disclosure	Секрет виден в открытом виде на машине оператора в момент split/recover	Файлы секрета и восстановленного значения имеют права `0600`, не логируются, не запрашиваются флагом `--stdout` по умолчанию	Присутствие в памяти процесса и файловой системе на короткое время неустранимо принципиально; для варианта на обычном пользователе окно риска больше — секрет пригоден для интерактивного входа (см. ниже)
Denial of service	Held M − 1 или меньше держателей отказываются или недоступны	Схема допускает недоступность до N − M держателей без потери работоспособности	Если недоступно больше держателей, чем допускает порог, восстановление невозможно никем — это заложенное свойство схемы (нет мастер-обхода), а не баг; выбор M и N — компромисс между устойчивостью к недоступности и устойчивостью к компрометации
Denial of service	Журнал восстановления недоступен для записи (диск полон, права нарушены)	`recovery grant-admin` работает fail-closed: код 9, доступ не выдаётся	Намеренный побочный эффект — недоступность аудита блокирует операцию восстановления даже при легитимном кворуме; держите резервный путь для `--audit-file` на случай проблем с основным
Elevation of privilege (повышение привилегий)	Сервисный аккаунт получает больше прав, чем нужно для восстановления	Роль сервисного аккаунта настраивается администратором отдельно от механизма Шамира	Схема не ограничивает права роли сама по себе — если роли выданы избыточно (например, права администратора всей системы), компрометация контура восстановления даёт значительно больше, чем предполагалось
Elevation of privilege	M держателей сговариваются и восстанавливают доступ к сейфу, к которому не должны иметь отношения	Не предотвращается — это штатный, ожидаемый режим работы схемы	Модель безопасности схемы — «доверие M из N держателей», а не «защита от M держателей». Если ваша модель угроз требует защиты и от сговора кворума, схема Шамира сама по себе не подходит — нужен дополнительный контроль (например, обязательное подтверждение вторым независимым процессом до применения восстановленного доступа)

Различия модели угроз между вариантами

	Сервисный аккаунт (Расширенная редакция)	Обычный пользователь (упрощённый вариант)
Поверхность атаки на секрет	Только через реконструкцию долей — у аккаунта нет интерактивного входа, скомпрометированный пароль отдельно похитить негде	Мастер-пароль пригоден для обычного входа — фишинг, подбор, повторное использование пароля становятся релевантными векторами в дополнение к атаке на доли
Окно жизни открытого секрета	Только внутри процесса `grant-admin`, секунды	От момента `shamir recover` до входа в продукт и завершения выдачи доступа — операция полностью ручная, окно больше и зависит от дисциплины оператора
Fail-closed аудит	Есть (`recovery grant-admin`, код 9 при недоступности журнала)	Нет — `shamir split`/`recover` не проверяют журналирование, ответственность за аудит целиком на процессе организации
Частичное покрытие сейфов	Требует ручного вмешательства Владельца — сервисный аккаунт не может подтвердить запрос доступа сам	Пользователь технически может подтвердить запрос сам после восстановления пароля, но до инцидента доступа к учётной записи ни у кого нет — риск на практике тот же
Минимизация прав роли	Возможна без побочных эффектов — аккаунт не используется ни для чего, кроме восстановления	Аналогично, но учтите: минимизация роли не отменяет того, что учётная запись обладает обычным паролем, годным для входа

Для критичных инсталляций предпочитайте вариант на сервисном аккаунте именно из-за меньшей поверхности атаки на постоянно существующий секрет (нет интерактивного входа) и наличия fail-closed аудита. Упрощённый вариант обоснован только там, где лицензия не позволяет иначе.

Ограничения схемы

Не защищает от сговора кворума. M легитимных держателей, договорившихся между собой, могут инициировать восстановление к любому сейфу, покрытому политикой — это ожидаемое поведение, а не уязвимость, но модель угроз должна это учитывать при выборе держателей и порога.
Ротация в v1 — только через полное переразвёртывание. Заменить одного скомпрометированного держателя без создания нового аккаунта восстановления и нового деления секрета нельзя (подробности — ниже).
Аутентичность держателя не проверяется криптографически. Схема проверяет математическую совместимость долей, а не то, что доля действительно пришла от заявленного человека — это организационный, а не технический контроль.
Локальный журнал не защищён от подмены той же машиной, что его ведёт. Целостность журнала гарантируется только до тех пор, пока оператор ему не противодействует; для независимого аудита нужен внешний сток (SIEM/syslog).
Продуктовая История действий не видит деталей церемонии. Она фиксирует только итоговую выдачу доступа — без локального журнала расследование инцидента постфактум невозможно восстановить в деталях.
Упрощённый вариант расширяет поверхность атаки за счёт интерактивного входа — см. таблицу выше.

Что остаётся на вашей стороне

API-токен сервисного аккаунта — постоянный секрет

Токен сам по себе не даёт доступа к данным сейфов: без реконструированного мастер-ключа сервер не отдаст расшифровываемые ключи. Но токен всё равно стоит защищать как критичный секрет:

храните его в хранилище секретов (secret manager, HSM), а не в почте или общем диске;
давайте роли сервисного аккаунта только права, необходимые для выдачи доступа и чтения структуры сейфов политики — не полные права администратора системы;
ограничьте круг людей, знающих, где лежит токен, отдельно от круга держателей долей;
если в вашей редакции доступны ограничения входа по ролям (IP-allowlist, обязательный SSO и т.п.), примените их к роли сервисного аккаунта — лишний барьер не помешает, даже если у роли и так нет интерактивного входа.

Нет продуктового аудита самой церемонии

История действий видит только итоговую выдачу доступа, а не то, кто был держателем и сколько долей собрано. Обязательно настройте локальный журнал passwork-cli (см. Аудит и коды завершения) и направляйте его во внешнюю систему мониторинга — это единственный способ восстановить картину инцидента постфактум.

Ротация долей в v1 — только через переразвёртывание

Лёгкой замены отдельного держателя без перевыпуска всей схемы нет. Если держатель скомпрометирован или покидает организацию, процедура такая:

Создать новый аккаунт восстановления с новым набором держателей и новым делением секрета (настройка сервисного аккаунта или упрощённый вариант).
Подключить новый аккаунт к администраторам политики и убедиться, что покрытие полное (покрытие сейфов).
Удалить старый аккаунт восстановления из администраторов политики и затем удалить сам аккаунт (для упрощённого варианта — дополнительно сменить или деактивировать мастер-пароль старой учётной записи).

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

Частичное покрытие сейфов

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

Активы и доверительные границы​

Модель угроз (STRIDE)​

Различия модели угроз между вариантами​

Ограничения схемы​

Что остаётся на вашей стороне​

API-токен сервисного аккаунта — постоянный секрет​

Нет продуктового аудита самой церемонии​

Ротация долей в v1 — только через переразвёртывание​

Частичное покрытие сейфов​

Рекомендации по эксплуатации​