Перейти к основному содержимому
Версия: 7.0

Настройка сервисного аккаунта

Вариант для Расширенной редакции

Этот раздел описывает автоматизированный вариант на сервисном аккаунте — он требует лицензии с флагом «Сервисные аккаунты». Если у вас другая редакция, см. Упрощённый вариант без сервисных аккаунтов.

Что понадобится

  • 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.

Что происходит внутри:

  1. CLI проверяет, что клиентское шифрование включено — иначе команда завершится с кодом 7.
  2. Генерируется мастер-ключ сервисного аккаунта и его RSA-пара (2048 бит, стандартная для Пассворка).
  3. Сервисный аккаунт создаётся на сервере (POST /v1/users/create-service-account).
  4. Мастер-ключ делится на N долей по схеме Шамира.
  5. Если указан --holder-pubkey-dir, каждая доля шифруется под публичный ключ соответствующего держателя (share_1.enc.b64share_N.enc.b64); без него доли пишутся в открытом виде (share_1.b64 …).
  6. Сам мастер-ключ нигде не выводится и не сохраняется — только доли.
Не пропускайте --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 — не расширяйте их и не копируйте в общие сетевые папки.

После этого шага сервисный аккаунт существует, но пока не имеет доступа ни к одному сейфу — следующий шаг подключает его к типу сейфа.