Как настроить уведомления о движении средств и разграничить доступ

Уведомления о движении средств настраиваются в три приёма. Наблюдательный кошелёк получает расширенный публичный ключ и видит поступления со списаниями. Служба оповещений получает правило вида «адрес, событие, адресат». Право менять это правило остаётся у одного человека и фиксируется в журнале. Разграничить доступ значит развести три роли: читатель ленты событий, редактор набора отслеживаемых адресов, подписант траты. Последняя роль к первым двум не примыкает никогда.

В обращениях читателей повторяется один сюжет. Деньги ушли, оповещение не пришло, человек выясняет, что месяц назад адресата в правиле подменили. Ключи целы. Подпись не тронута. Скомпрометирована была не подпись, а административная панель сервиса, где настройку и правили.

Под какой сценарий подбирается кошелёк и схема оповещений

Схема зависит от того, сколько людей имеет отношение к хранилищу. Одиночный держатель обходится одним правилом и одним адресатом. Семейный или командный контур требует разделения: кто-то обязан видеть события, но не обязан иметь возможность изменить набор адресов под наблюдением. Для такого контура полезно заранее понять, как настроить мультисиг-хранилище для семьи или небольшой команды: разделение на уровне подписи и разделение на уровне наблюдения проектируются вместе.

Отсюда вытекает неочевидное следствие. Административное право на конфигурацию — самостоятельный актив. Денег его кража не даёт. Она даёт тишину, а тишина даёт время: пока оповещение отключено или переадресовано, подписант не узнает о списании, не поднимет тревогу и не успеет вывести остаток на свежий счёт, пока ключ ещё под его контролем.

Сравнение ролей: что меняется для пользователя

Разводить роли проще, когда понятно, что именно отдаётся наружу. Наблюдение строится на расширенном публичном ключе: по стандарту BIP-32 аудитор получает все публичные ключи счёта и видит движение, не имея возможности подписать трату. У того же стандарта есть оговорка, которую пропускают: знание родительского расширенного публичного ключа вместе с любым неужесточённым дочерним приватным ключом равносильно знанию родительского приватного ключа — то есть всего кошелька. Разбор, как устроен расширенный публичный ключ в мультиподписи, стоит прочесть до выдачи ключа сервису.

Настройка шаг за шагом

1. Составьте опись ролей на бумаге: имя человека, что он видит, что вправе изменить. Опись датируйте — она станет точкой сверки через полгода.
2. Выгрузите из устройства расширенный публичный ключ нужного счёта и отдайте сервису наблюдения только его. Приватные ключи и фраза восстановления из устройства не выходят.
3. Создайте правило оповещения: адрес или дескриптор, тип события, канал доставки, адресат. Отдельным правилом закройте исходящие — списание важнее поступления.
4. Снимите у читателей право правки: в сервисе это отдельная роль или отдельный аккаунт, а не галочка в том же профиле.
5. Включите журнал изменений конфигурации и настройте оповещение на само изменение правила. Правка настройки должна приходить тем же каналом, что и движение средств.
6. Проверьте результат чужими руками: попросите читателя изменить адресата. Отказ сервиса и запись в журнале — критерий приёмки.

Резервная копия и проверка восстановления

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

Проверка выглядит так. Берётся второй, чистый экземпляр сервиса или второй аккаунт, и по бумажной описи в него заводятся ровно те же правила — без доработок по памяти, иначе проверяться будет не опись, а ваша память. Затем на тестовый адрес счёта отправляется минимальная сумма. Оба контура обязаны сработать одинаково. Расхождение означает, что опись неполна.

Канал доставки отдельно заслуживает скепсиса. Национальный институт стандартов и технологий США в публикации SP 800-63B (июнь 2017 года, правки от 2 марта 2020 года) относит проверку через телефонную сеть общего пользования к ограниченным способам и прямо называет индикаторы риска: подмена устройства, замена SIM-карты, перенос номера. Для оповещений вывод тот же: канал на номере телефона нельзя считать единственным.

Типовые ошибки, которые стоят денег

Вторая ошибка — наблюдение по списку адресов вместо дескриптора. Кошелёк выдаёт новые адреса для сдачи, список устаревает, часть списаний проходит мимо правила, и владелец месяцами живёт с ощущением полного покрытия, которого у него нет. Третья ошибка грубее. Оповещение настроено только о поступлениях. Такая настройка радует и не защищает.

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

Отдельно о передаче ключей. Выдавая сервису расширенный публичный ключ, вы отдаёте историю и будущие адреса счёта безвозвратно: отозвать публикацию нельзя. Решение — отдельный счёт под наблюдение. Ответственность за такой выбор целиком на владельце, и понимание того, что такое самостоятельное хранение и какую ответственность оно даёт, здесь первично.

Что делать при утере доступа

Сначала разделите две потери. Потерян доступ к сервису оповещений — деньги целы, восстанавливается конфигурация. Потерян доступ к ключам — оповещения вторичны, и работает процедура восстановления кошелька, в которой порядок шагов важнее скорости: сперва проверка резервной копии на чистом устройстве, затем перевод средств. Разница принципиальна.

1. Проверьте по журналу, были ли изменения правил за последние недели. Неизвестная правка означает компрометацию панели, а не забытый пароль.
2. Создайте новый контур наблюдения на новом аккаунте и с новым адресатом, не восстанавливая старый.
3. Старый расширенный публичный ключ считайте раскрытым: переведите средства на счёт с другим путём вывода.
4. Перепроверьте опись ролей и подпишите её заново. Документ без даты через год бесполезен.

Чек-лист

• Опись ролей на бумаге, с датой и подписями участников
• Сервису отдан расширенный публичный ключ отдельного счёта, не основного
• Правила заведены на дескриптор, а не на перечень адресов
• Исходящие события оповещаются отдельным правилом
• Право правки конфигурации отделено от права чтения
• Журнал изменений включён, правка правила приходит оповещением
• Канал доставки не сводится к номеру телефона
• Копия конфигурации лежит вне сервиса и проверена восстановлением

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

Частые вопросы

Источники: спецификация BIP-32 о расширенных публичных ключах и публикация NIST SP 800-63B о каналах подтверждения.