Практические рекомендации

Раздел Модель безопасности и рекомендации описывает угрозы и общие принципы. Здесь — три типовых профиля организаций с конкретными параметрами: вариантом схемы, порогом M из N, составом держателей и сегментацией политик. Это отправные точки, а не жёсткие правила — адаптируйте под свою структуру.

Обзор

	Небольшая команда	Средняя компания	Крупная организация
Вариант	Упрощённый (пользователь)	Автоматизированный (SA)	Автоматизированный (SA)
Порог	2 из 3	3 из 5	5 из 9
Контуров восстановления	Один общий	По одному на критичную политику	По одному на критичную политику + резервный
Держатели	Один общий круг	Из разных отделов	Из разных офисов/юрисдикций
Аудит	Ручная запись в тикет	Экспорт в SIEM	Экспорт в SIEM + алерты

Небольшая команда

Например, 5–20 человек, один офис, отдельной службы безопасности нет.

• Вариант. Лицензии на сервисные аккаунты обычно нет, а масштаб не оправдывает автоматизацию — подходит упрощённый вариант на обычном пользователе.
• Порог — 2 из 3. Меньше троих доверенных держателей в такой команде обычно физически не набрать, а порог 2 из 3 уже даёт кворум больше одного человека.
• Держатели. Например, два совладельца или руководителя и один доверенный сотрудник ИТ, не входящий в число первых двух — так что ни у кого нет единоличного контроля.
• Политики доступа. Одна общая политика на все критичные сейфы с одним аккаунтом восстановления — сегментация на несколько контуров при таком масштабе усложняет схему без ощутимой пользы.
• Аудит. Полноценный SIEM избыточен — фиксируйте факт и параметры церемонии в общей тикет-системе или журнале инцидентов сразу после восстановления.
• Проверка. Тестовая церемония на некритичном сейфе раз в полгода — этого достаточно, чтобы держатели помнили процедуру.

Средняя компания

Например, 50–300 сотрудников, есть выделенный ИТ- или security-специалист, несколько отделов уже разведены по разным типам сейфов.

• Вариант. Лицензия обычно оправдана масштабом — используйте автоматизированный вариант на сервисном аккаунте: меньше ручных операций и есть fail-closed аудит.
• Порог — 3 из 5. Устойчив к недоступности до двух держателей одновременно, не требуя собирать больше пяти человек.
• Держатели. Берите из разных отделов и уровней иерархии — например, руководитель ИТ, security-специалист, HR-директор, второй администратор и CTO/CEO. Так держатели не смогут сговориться без выхода за пределы одного отдела.
• Политики доступа. Заведите отдельный аккаунт восстановления на каждую критичную политику (например, «Production», «Финансы») — не покрывайте всё одним контуром: компрометация одного не должна давать доступ ко всему сразу. Как это настроить — в разделе Политики доступа к сейфам.
• Аудит. Направляйте локальный журнал passwork-cli во внешний лог-агрегатор или SIEM — без этого продуктовая История действий не покажет деталей церемонии (подробности — в разделе Аудит и коды завершения).
• Проверка и ротация. Тестовое восстановление раз в квартал; пересматривайте состав держателей при любой смене ролей или увольнении, не реже раза в год.

Крупная организация с повышенными требованиями к безопасности

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

• Вариант. Автоматизированный на сервисном аккаунте — обязателен fail-closed аудит и минимальная поверхность атаки на постоянный секрет (см. Модель безопасности).
• Несколько независимых контуров. По одному аккаунту восстановления на каждую критичную политику, а для самых чувствительных — дополнительный резервный аккаунт с отдельным составом держателей на случай, если основной контур недоступен (см. Несколько аккаунтов восстановления).
• Порог — выше, например 5 из 9 для самых критичных контуров. Выбирайте держателей из разных офисов или юрисдикций, чтобы кворум физически не мог собраться в одной комнате без участия хотя бы одного удалённого держателя.
• Разделение обязанностей. Оператор настройки, оператор восстановления и держатели — разные люди. Никто не должен одновременно знать API-токен сервисного аккаунта и держать более одной доли.
• Хранение секретов. Токен сервисного аккаунта — только в secret manager или HSM с отдельным логированием доступа к самому секрету, а не только к операциям passwork-cli.
• Аудит. Обязательный экспорт локального журнала в SIEM с алертом на сам факт запуска recovery grant-admin — реагировать нужно даже на легитимный запуск, если он не был запланирован заранее.
• Формальный runbook. Процедура восстановления — не «знание в голове» одного администратора, а документированный, утверждённый порядок действий с чек-листом, который можно поднять в момент инцидента без импровизации.
• Проверка и ротация. Тестовое восстановление не реже раза в квартал на некритичном сейфе; формальная процедура ротации при любом кадровом изменении среди держателей или операторов — независимо от того, есть ли подозрение на утечку.

Общее правило масштабирования

Чем выше цена ошибки, тем более распределённым должен быть кворум и тем строже — разделение обязанностей и аудит. Начинать со схемы для небольшой команды и донастраивать по мере роста — нормальная траектория; двигаться в обратную сторону (упрощать контроли по мере роста рисков) не стоит.

Версия для LLM