Настройка сервисного аккаунта
Этот раздел описывает автоматизированный вариант на сервисном аккаунте — он требует лицензии с флагом «Сервисные аккаунты». Если у вас другая редакция, см. Упрощённый вариант без сервисных аккаунтов.
Что понадобится
passwork-cliустановлен у оператора настройки (см. установку).- Сессия администратора или владельца с включённым клиентским шифрованием:
PASSWORK_HOST,PASSWORK_TOKEN,PASSWORK_REFRESH_TOKEN,PASSWORK_MASTER_KEY— это ключи оператора, а не будущего сервисного аккаунта. - Список из N человек, которые станут держателями долей.
- Лицензия с поддержкой сервисных аккаунтов.
Шаг 1. Держатели создают RSA-ключи
Каждый держатель генерирует себе пару RSA-ключей на 4096 бит — это отдельные ключи только для шифрования долей, не путать с криптографией самого Пассворка (разница объяснена здесь).
passwork-cli rsa gen-keys --out-dir holders/alice --label alice
passwork-cli rsa gen-keys --out-dir holders/bob --label bob
passwork-cli rsa gen-keys --out-dir holders/carol --label carol
Каждая команда создаёт пару файлов <label>.pub.pem и <label>.priv.pem. Приватный ключ (*.priv.pem) держатель оставляет только у себя. Публичные ключи всех держателей собираются в один катал ог для следующего шага:
mkdir pubkeys
cp holders/*/*.pub.pem pubkeys/
--bits по умолчанию равен 4096 — уменьшать не стоит, CLI не примет доли, шифрование которых недостаточно надёжно для этой роли.
Шаг 2. Роль сервисного аккаунта
Рекомендуем создать в веб-интерфейсе отдельную роль с минимальным набором прав — только то, что нужно для выдачи доступа к сейфам типа и чтения его структуры. Не используйте для сервисного аккаунта восстановления роль администратора всей системы: минимизация прав ограничивает ущерб, если API-токен когда-нибудь скомпрометируют.
Шаг 3. Создание сервисного аккаунта с делением мастер-ключа
passwork-cli users create-service-account \
--login recovery-sa \
--role "$ROLE_ID" \
--m 3 --n 5 \
--holder-pubkey-dir pubkeys/ \
--out-dir shares/
| Флаг | Обязателен | Описание |
|---|---|---|
--login | да | логин сервисного аккаунта |
--role | нет | идентификатор роли (см. шаг 2) |
--m, --n | вместе | порог и число долей (2 ≤ M ≤ N ≤ 16) |
--holder-pubkey-dir | нет | каталог с публичными ключами держателей — доли будут зашифрованы под них |
--out-dir | нужен один из двух* | каталог для файлов долей (права 0600, каталог 0700) |
--stdout | нужен один из двух* | вывод долей в терминал — не используйте с --holder-pubkey-dir |
--audit-file, --syslog | нет | локальный журнал операции создания |
* Если задан --holder-pubkey-dir, обязателен и --out-dir.
Что происходит внутри:
- CLI проверяет, что клиентское шифрование включено — иначе команда завершится с кодом 7.
- Генерируется мастер-ключ сервисного аккаунта и его RSA-пара (2048 бит, стандартная для Пассворка).
- Сервисный аккаунт создаётся на сервере (
POST /v1/users/create-service-account). - Мастер-ключ делится на N долей по схеме Шамира.
- Если указан
--holder-pubkey-dir, каждая доля шифруется под публичный ключ соответствующего держателя (share_1.enc.b64…share_N.enc.b64); без него доли пишутся в открытом виде (share_1.b64…). - Сам мастер-ключ нигде не выводится и не сохраняется — только доли.
--m/--nБез --m и --n команда выведет мастер-ключ сервисного аккаунта напрямую в терминал (с предупреждением) — это обычный режим создания сервисного аккаунта, не сценарий порогового восстановления. Для настройки схемы Шамира всегда указывайте оба флага.
Шаг 4. Выпуск API-токена сервисного аккаунта
passwork-cli не выпускает API-токен — это делается в ве б-интерфейсе, как для любого сервисного аккаунта: откройте карточку пользователя recovery-sa и в разделе API-токены сгенерируйте токен. Сохраните его в отдельный файл с правами 0600 — он понадобится оператору восстановления на шаге выдачи доступа, но не оператору настройки.
Здесь будет скриншот: карточка пользователя-сервисного аккаунта, вкладка API-токены, кнопка выпуска нового токена.
Шаг 5. Раздача долей и хранение секретов
- Передайте каждому держателю только его файл доли (
share_N.b64илиshare_N.enc.b64) — не весь каталогshares/. - Если доли зашифрованы под RSA держателя, передавать их можно даже по не самому доверенному каналу: расшифровать сможет только владелец соответствующего приватного ключа.
- Файл с API-токеном сервисного аккаунта храните отдельно от долей — в защищённом хранилище секретов, доступном оператору восстановления, а не держателям.
- Каталоги и файлы, которые создаёт CLI, уже имеют права 0700/0600 — не расширяйте их и не копируйте в общие сетевые папки.
После этого шага сервисный аккаунт существует, но пока не имеет доступа ни к одному сейфу — следующий шаг подключает его к типу сейфа.