Что на самом деле останавливает транзакцию
У любого продукта для хранения есть страница возможностей со списком средств контроля: белые списки, лимиты расходов, временные блокировки, маршруты согласования, ограничения по IP. Все они настоящие и все полезные. Но они не одного рода, и обращение с ними как со взаимозаменяемыми — это путь, на котором организации получают модель безопасности слабее той, что подразумевал маркетинг.
Есть вопрос, который разделяет их начисто: если бы каждый кусок софта в системе был ошибочным или враждебным, устояло бы это средство контроля?
Для большей части списка ответ — нет. Ровно для одного — да. Эта статья о том, как их различать.
Три слоя, а не один
Между желанием сдвинуть средства и фактическим их движением у SSP Enterprise три разных барьера. Они отказывают по-разному, и понимание, какой есть какой, — это и есть весь смысл.
Слои упорядочены не по полезности. Они упорядочены по тому, что нужно, чтобы их преодолеть.
Слой 1: слой координации
Это движок политик, и именно там живёт большинство возможностей. SSP Enterprise поддерживает белые списки адресов, ограничения по типу назначения, временные блокировки, задерживающие транзакции выше порога суммы, правила, требующие одобрения администратора начиная с определённой суммы, и ограничения по IP на доступ к организации. Шаблоны политик дают разумные предустановки, которые затем материализуются в реальные, редактируемые правила.
Эти вещи делают настоящую работу. Белый список не даёт адресу с опечаткой даже стать предложением. Временная блокировка даёт казначейской команде окно, чтобы заметить неладное. Правило одобрения превращает крупный перевод в разговор двоих, а не в вечер одного человека.
Чем они не являются — так это обеспечением хранения. Эти правила живут в софте SSP и вычисляются серверами SSP. Они не входят в адрес хранилища, и блокчейн о них никогда не слышал. Если бы движок политик обошли — из-за ошибки, скомпрометированного сервера или враждебного оператора, — правила попросту не сработали бы.
Мы говорим это прямо, потому что альтернатива хуже. Команда, которая считает свой белый список гарантией хранения, подберёт порог соответственно, а это ровно та ошибка, что превращает переживаемый инцидент в непереживаемый.
Слой 2: ваши устройства
Второй барьер — пара устройств у каждого подписанта, и он сильнее первого в важном отношении: он не доверяет и SSP.
Когда предложение доходит до подписанта, его устройства локально декодируют сырые байты транзакции и сверяют результат с тем, что показывается. Получатель, сумма, токен — прочитаны из байтов, а не взяты из описания сервера. В Solana это сравнение явное и непреклонное: если декодированные байты противоречат отображаемому, подпись жёстко блокируется, а не сопровождается предупреждением, потому что расхождение там указывает на активную атаку, а не на сбой отрисовки.
Устройства также применяют собственный независимый потолок на возмещение комиссий. Relay предлагает комиссию; кошелёк отказывается подписывать её выше жёстко зашитого максимума, что бы relay ни утверждал, и это ограничивает любой отток через комиссии, даже если relay полностью враждебен. Симуляция тоже выполняется до одобрения, исполняя предложение на текущем состоянии сети, чтобы экран проверки мог показать, что транзакция сделала бы на самом деле; это пришло вместе с симуляцией транзакций и предупреждениями о рисках.
Этот слой побеждает скомпрометированный сервер. Чего он победить не может — так это скомпрометированного устройства или подписанта, который одобряет не читая. Он также требует обоих устройств подписанта, и именно поэтому важна схема 2-из-2 на человека: слой 2 силён настолько, насколько слабее из двух устройств, а они намеренно относятся к разным классам оборудования.
Слой 3: сеть
Третий барьер — единственный, который держится, когда всё остальное отказало.
Адрес хранилища выводится из набора подписантов и порога одобрения. Транзакция, не несущая нужного числа действительных подписей, — не отклонённая транзакция, а недействительная. Каждый узел сети независимо приходит к тому же выводу, и никакая степень доступа к инфраструктуре SSP этой арифметики не меняет.
Поэтому порог — то число, которое при создании хранилища заслуживает наибольших раздумий, и поэтому его нельзя отредактировать позже. Настройка вашего первого корпоративного хранилища разбирает механику; 2-из-2 против 2-из-3 и m-из-n разбирает выбор самого числа.
Где отказывает каждый слой
Если выложить режимы отказа рядом, задача проектирования становится очевидной.
| Сценарий | Слой координации | Ваши устройства | Сеть |
|---|---|---|---|
| Подписант ошибается в адресе | Останавливает | Останавливает, если он читает | Ей всё равно |
| Подписанта фишингом склонили одобрить | Останавливает, если адреса нет в белом списке | Показывает правду; он всё равно может одобрить | Ей всё равно |
| Relay SSP скомпрометирован | Отказывает | Держит — байты декодируются локально | Держит |
| В движке политик SSP есть ошибка | Отказывает | Держит | Держит |
| Ноутбук подписанта скомпрометирован | Не рассчитан на это | Частично — телефон всё ещё проверяет | Держит |
| У злоумышленника меньше M подписантов | Не рассчитан на это | Держит | Держит |
| У злоумышленника M подписантов или больше | Отказывает | Отказывает | Отказывает |
Последняя строка — честное дно модели. Мультиподпись защищает от компрометации меньшинства ваших подписантов. От большинства она не защищает, и ни один продукт не может утверждать обратное, не солгав. Именно поэтому порог и независимость ваших подписантов значат больше любого списка возможностей.
Что это значит для того, как вы всё настраиваете
Проектируйте хранилище так, чтобы оно было безопасно с одним лишь слоем 3. Выбирайте порог и набор подписантов так, будто движка политик не существует. Если ответ вас смущает, лечение — другой порог или другие подписанты, а не больше политик.
Затем добавляйте политики ради того, в чём политики хороши. Белые списки ловят человеческую ошибку. Временные блокировки покупают время на реакцию. Правила одобрения создают вторую пару глаз на крупных суммах. Это улучшения процесса, и они действительно снижают число инцидентов; просто они не то, что стоит между злоумышленником и вашей казной.
Держите подписантов по-настоящему независимыми. Двое подписантов на одном ноутбуке, в одном здании, с одинаковой схемой восстановления ближе к одному подписанту, чем к двум. Сила слоя 3 берётся из трудности скомпрометировать M отдельных людей с M отдельными парами устройств.
Добейтесь, чтобы подписанты действительно читали экран проверки. Слой 2 — единственный барьер, способный поймать предложение, выглядящее законным, но ошибочное, и работает он только если человек вникает в то, что декодировало его устройство. Отрепетированный круг при создании хранилища помогает выработать эту привычку, пока ничего не поставлено на карту.
Задайте тот же вопрос другим поставщикам хранения. Пользуетесь вы SSP или нет, эта рамка переносима: по каждому пункту на странице возможностей спросите, переживёт ли он ошибку в софте самого поставщика. Ответы часто поучительны, а поставщик, отвечающий ясно, сообщает вам кое-что хорошее о том, как он думает.
О способах, которыми многоключевую схему подрывают на практике, режимы отказа мультиподписи и как SSP их смягчает проходит по ним один за другим, а SSP Enterprise: мультиподписные хранилища для команд — обзор того, как складываются части.
