Мультисиг-кошелёк (multisig) - это схема, при которой для отправки средств требуется несколько независимых подписей, а не один приватный ключ. Это снижает риск кражи при компрометации одного участника и помогает формализовать совместное управление активами. Безопасность мультисиг зависит от правильного выбора M-of-N, хранения ключей и процедур согласования.
Основные положения безопасности мультисиг-кошельков
- Мультисиг уменьшает риск "одной точки отказа", но добавляет риски координации и человеческих ошибок.
- Безопасность определяется не только криптографией, но и тем, как распределены роли, устройства и каналы связи.
- Выбор M-of-N должен учитывать сценарии потери доступа, доступность подписантов и допустимую задержку операций.
- Ключи нельзя держать в одном доверенном контуре: разделяйте устройства, локации и провайдеров.
- Процедуры экстренного реагирования важнее "идеальной схемы": заранее решайте, что делать при компрометации и увольнении.
Быстрые практические советы (до настройки и в первые недели)
- Сделайте отдельный "тренировочный" кошелёк с небольшой суммой и прогоните полный цикл: создание, пополнение, расход, восстановление, ротация подписанта.
- Запретите подтверждение транзакций по скриншотам и пересланным адресам: сверка реквизитов - только из доверенного источника (например, из вашей системы заявок) и на устройстве подписанта.
- Разведите роли: инициатор платежа не должен быть единственным подписантом; как минимум один подписант - вне операционной команды.
- Сразу определите, где хранится "истина" по политике (M-of-N, список подписантов, правила лимитов) и кто имеет право её менять.
Принцип работы мультисиг: распределение ролей и подписей
Мультисиг-кошелёк задаёт правило авторизации трат: транзакция считается действительной, только если её подпишет минимум M участников из N. В зависимости от сети и типа кошелька это может быть классический on-chain multisig (правило проверяется на уровне протокола) или схема на базе смарт-контракта (правило реализовано кодом контракта).
На практике важно отличать криптографический мультисиг от "мультиюзерного доступа" в одном приложении. Если несколько людей входят в один аккаунт/сид-фразу, это не мультисиг, а общий ключ с повышенным операционным риском. Безопасный мультисиг подразумевает независимые ключи и независимые среды хранения.
Роли обычно разделяют так: инициатор формирует платёж (черновик), подписанты проверяют параметры (получатель, сумма, комиссия, сеть/контракт) и добавляют подписи, а наблюдатель/аудитор сверяет соответствие политике (лимиты, назначение платежа, подтверждающие документы). Чем понятнее роли, тем меньше вероятность "подписали не глядя".
Угрозы и векторы атак, специфичные для мультисиг-конфигураций
Мультисиг устраняет классическую кражу через компрометацию одного ключа, но открывает новые классы атак: на координацию, на интерфейсы подтверждения и на процесс принятия решений. Уязвимость чаще возникает не в криптографии, а в том, как люди подтверждают транзакции и как они получают данные для проверки.
- Социальная инженерия на подписантов: злоумышленник добивается "быстрого подтверждения" через срочность, подмену реквизитов, фишинговые домены, поддельные тикеты на оплату.
- Подмена данных на устройстве инициатора: инициатор формирует транзакцию в заражённой среде, где адрес получателя подменяется до того, как черновик попадёт подписантам.
- Атака на коммуникации: перехват/подмена сообщения с параметрами платежа (например, в мессенджере) и дальнейшее "легитимное" подписание.
- Компрометация двух и более ключей через одинаковый контур: ключи у разных людей, но хранятся на одинаковых устройствах, в одном облаке, с одной моделью резервирования.
- Сговор или злоупотребление полномочиями: M подписантов могут провести несанкционированный платёж, если политика не подкреплена лимитами и внешним контролем.
- Риски смарт-контракта/модуля: если мультисиг реализован контрактом или модулем, уязвимость в логике может обойти M-of-N или позволить сменить владельцев.
Технические mitigations обычно сводятся к двум принципам: (1) независимость контуров хранения ключей и (2) независимость источников истины для проверки реквизитов. Чем больше подтверждение опирается на "внешний" проверяемый контур (тикет-система, бухгалтерия, allowlist адресов), тем меньше эффект от фишинга.
Выбор схемы M-of-N: критерии риска и удобства
Схема M-of-N выбирается не "по моде", а по балансу между устойчивостью к компрометации и доступностью операций. Чем выше M, тем сложнее злоумышленнику собрать подписи, но тем выше риск блокировки средств из‑за отпусков, увольнений, потери ключа или задержек коммуникаций.
Типичные применения, где выбор M-of-N существенно меняет риск-профиль:
- Казначейство компании: регулярные платежи, нужен предсказуемый SLA - часто выбирают схему, устойчивую к отсутствию одного подписанта.
- Инвестклуб/пул частных лиц: выше риск конфликтов и споров - полезны более строгие правила и журналирование решений.
- Фонд/грантовая программа: важна прозрачность и минимизация злоупотреблений - добавляют независимого подписанта/наблюдателя.
- Холодное хранение резерва: низкая частота операций - можно повышать M и усложнять доступ, добавляя паузы и офлайн-подписи.
- Проект с подрядчиками: критична сменяемость участников - нужен процесс ротации ключей без остановки деятельности.
| Схема | Что хорошо защищает | Типичный операционный риск | Когда уместна |
|---|---|---|---|
| 2-of-2 | Любая трата требует согласия обоих | Блокировка средств при потере/недоступности одного подписанта | Партнёрство с редкими операциями и высокой дисциплиной |
| 2-of-3 | Компрометация одного ключа не критична | Нужно поддерживать актуальность состава трёх подписантов | Малые команды, казначейство с умеренной частотой платежей |
| 3-of-5 | Сильнее защита от компрометации/сговора меньшинства | Сложнее координация, выше задержки и требования к процессам | Совместное управление в нескольких отделах, распределённые команды |
Практическое правило: сначала смоделируйте "плохой день" (один ключ утерян, один подписант недоступен, один канал связи под атакой) и убедитесь, что бизнес-процесс всё ещё работоспособен. Если без человека невозможно оплатить критичный счёт, вы выбрали слишком жёсткую доступность.
Практики хранения и защиты приватных ключей участников
Ключи подписантов должны быть независимыми по устройствам, резервированию и физическому доступу. Если все используют один и тот же тип кошелька на одинаковых телефонах с одинаковой схемой бэкапа, компрометация поставщика, массовый эксплойт или ошибка политики резервирования может затронуть сразу несколько ключей.
Что делать (минимальный базис)
- Использовать аппаратные кошельки или изолированные среды подписи там, где риск кражи критичен.
- Разнести ключи по устройствам и локациям; не хранить резервные фразы/ключи всех участников в одном сейфе/облаке.
- Зафиксировать стандарты: обновления прошивок, проверка адреса на экране доверенного устройства, запрет установки непроверенного ПО.
- Организовать резервирование так, чтобы восстановление требовало контролируемого процесса (например, участие ответственного и журналирование).
Чего избегать (типовые провалы)
- Хранить seed-фразы нескольких подписантов в одном менеджере паролей, одном облаке или в одном корпоративном хранилище без разделения доступа.
- Подписывать транзакции на устройствах "для всего", где одновременно почта, мессенджеры и рабочие документы без изоляции.
- Делать "общий запасной ключ команды", который знают несколько людей: это превращает мультисиг в условный single-sig.
- Доверять адресу получателя из чата без независимой сверки по заявке/контракту/allowlist.
Процедуры координации транзакций и реагирования на инциденты
Мультисиг безопасен ровно настолько, насколько безопасен процесс вокруг него. Наиболее частые инциденты происходят из‑за того, что подписанты не имеют стандарта проверки и не понимают, что именно они подтверждают. Второй распространённый класс проблем - отсутствие заранее определённого плана действий при компрометации одного ключа.
- Ошибка: подтверждение "по просьбе коллеги". Митигирование: правило: подпись только по заявке из системы учёта с обязательными полями (получатель, сеть, назначение, подтверждающий документ).
- Ошибка: нет двухканальной сверки реквизитов. Митигирование: адреса получателей - через allowlist, изменения allowlist - отдельной процедурой и отдельным мультисиг-событием.
- Миф: "мультисиг сам по себе защищает от фишинга". Реальность: фишинг может собрать M подписей, если люди подтверждают без проверки на доверенном экране.
- Ошибка: нет плана ротации подписантов. Митигирование: заранее описать триггеры ротации (увольнение, смена роли, подозрение на компрометацию) и тестовый прогон процедуры.
- Ошибка: нет сценария аварийной заморозки/изоляции. Митигирование: определить, кто инициирует паузу операций и как быстро переводить средства на резервный кошелёк при подозрении на утечку.
Аудит, комплаенс и интеграция мультисиг в корпоративные процессы
Для компании мультисиг - это не только техника подписи, а управляемый контроль: кто имеет право инициировать, кто утверждает, где хранится обоснование платежа и как это проверяется постфактум. Хорошая интеграция - когда транзакция в блокчейне однозначно сопоставляется с внутренней заявкой и набором согласований.
Мини-кейс: оплата подрядчику с проверяемой трассировкой
Процесс можно упростить до связки: заявка на оплату → формирование черновика транзакции → подписи → публикация → сверка и архивирование. Важно, чтобы у подписантов был неизменяемый идентификатор заявки, который они видят при подтверждении (в комментарии/метаданных, если это поддерживается, или в сопроводительном пакете).
if ticket.status != "APPROVED":
reject("Нет утверждённой заявки")
draft = build_tx(to=ticket.payee_address, amount=ticket.amount, chain=ticket.chain)
signers = collect_signatures(draft, policy="2-of-3")
if not verify_allowlist(ticket.payee_address):
reject("Адрес не в allowlist")
broadcast(draft, signers)
archive(ticket_id=ticket.id, tx_hash=draft.hash, signers=signers)Мини-процедура внедрения мультисиг в команде
- Описать роли и матрицу прав: кто инициирует, кто подписывает, кто контролирует соответствие политике.
- Выбрать M-of-N и смоделировать сбои (потеря ключа, недоступность подписанта, компрометация устройства).
- Настроить хранение ключей и резервирование с независимыми контурами и регулярной проверкой восстановления.
- Ввести процесс заявок и независимую сверку реквизитов (allowlist, подтверждающие документы, журналирование).
- Провести тестовый цикл на небольших суммах и зафиксировать регламент реагирования на инциденты и ротацию.
Чек-лист самопроверки перед запуском в прод
- Мы можем провести критичный платёж, если один подписант недоступен, и можем заблокировать операции при подозрении на компрометацию.
- Ключи подписантов хранятся в независимых средах, а резервирование не сводит всё к одному месту/аккаунту.
- Подписанты проверяют реквизиты по доверенному источнику и на доверенном экране, а не по пересланным данным.
- Ротация подписантов и восстановление доступа протестированы на тренировочном кошельке и описаны в регламенте.
Ответы на типичные практические вопросы о мультисиг
Можно ли считать мультисигом доступ нескольких людей к одному seed?
Нет. Это общий ключ и общая зона риска: утечка или конфликт мгновенно компрометируют средства. Мультисиг подразумевает независимые ключи у разных участников.
Что безопаснее: 2-of-3 или 3-of-5?
3-of-5 обычно устойчивее к компрометации меньшинства, но сложнее в координации и повышает риск задержек. Выбор делайте через моделирование сбоев и требований к доступности операций.
Как защититься от подмены адреса получателя при мультисиге?
Используйте allowlist адресов и отдельную процедуру её изменения. Подписанты должны сверять адрес на доверенном устройстве и по независимому источнику (заявка/договор), а не по сообщению в чате.
Нужен ли отдельный подписант-аудитор, который не участвует в операционке?
Часто да: независимый подписант снижает риск "коллективной ошибки" и давления срочности. Это особенно полезно для казначейства и фондов, где важна дисциплина контроля.
Что делать при подозрении на компрометацию одного ключа подписанта?
Остановить операции, запустить заранее описанную ротацию состава подписантов и перенос средств на новый адрес/контракт при необходимости. Важно действовать по регламенту, а не импровизировать в моменте.
Как часто нужно тестировать восстановление и ротацию?
Регулярно и обязательно после изменений состава команды или устройств. Минимально - каждый подписант должен уметь восстановить свой доступ в контролируемом сценарии на тренировочной среде.
