🤔 MultiSig для blockchain: реальный кейс

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

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

Задача: необходимо обеспечить безопасность 800+ BTC в день проходящих через криптопул. Без seed phrase на одном устройстве, без единой точки отказа, без возможности вывести всё одной скомпрометированной подписью.

Как устроена транзакция

BTC на адресе всегда тратится целиком — разбивается на несколько исходящих адресов, остаток уходит на новый адрес (change output), разница между входящей и исходящей суммой — комиссия. Адрес содержит хеш в цепи и позволяет разрешить трату конкретных coin. Мультиподпись меняет этот хеш: вместо «одна подпись» становится «M из N подписей»

Схемы M-of-N

• 2/3 — горячий кошелёк биржи. Биржа держит один ключ, второй резервный, третий — у команды кибербезопасности. Для подтверждения транзакции нужно минимум два. Security-команда подписывает только после проверки на AML и kill-switch
• 3/5 — кошелёк с низким уровнем доверия. Тратить могут любые трое из пяти владельцев. Инициировать перевод может любой, но исполнить — только при достижении необходимого количества подписей. Снижает одновременно три риска: растрату одним участником, взлом, потерю доступа
• 2/3 — эскроу схема. Покупатель, продавец, арбитр. В норме сделка закрывается подписями двух сторон без арбитра. При споре — арбитр подписывает в пользу одной из сторон. Платформа физически не может забрать деньги в одностороннем порядке

Решение для кейса — как это реализовано на практике?

• Схема подписи: 2/3 с разделением ролей — автоматический сервис подписывает рутинные выплаты, security-ключ изолирован и подключается только для нестандартных операций или крупных выводов выше порога AML
• Проверки перед подписанием: валидация адреса получателя по whitelist, проверка суммы, проверка что change output возвращается на наш контролируемый адрес, а не уходит куда-то третьему
• Хранение ключей: hot key в HSM на сервере, backup key offline в физически изолированном хранилище, security key у команды ИБ с hardware token PKCS#11 (на то время). Никаких seed phrase в plaintext, никаких ключей в ENV переменных
• Мониторинг: каждая подписанная транзакция логируется с метаданными — кто подписал, в какое время, сумма, адрес получателя. Алерт при подписании выше порога и иные проверки AML

Почему это важнее чем кажется?

• Большинство взломов — это не взлом блокчейна, а компрометация одного ключа: утечка из ENV, взлом сервера, инсайдер и тд. Поэтому Multisig переводит вопрос в плоскость скомпрометируй M из N одновременно — это принципиально другой уровень атаки
• Для финтех-продуктов это ещё и архитектурный аргумент: если платформа физически не может подписать транзакцию в одностороннем порядке — это не только безопаснее, но и юридически чище в плане ответственности

Итого (полный кейс с разбором транзакций и схемами почитай тут)

• Multisig — не фича, а архитектурный принцип: M из N владельцев должны согласовать операцию
• 2/3 — минимальный разумный порог для горячего кошелька с реальными деньгами
• 5/7 - рекомендуемый порог для холодного хранения и распределения средств с нод
• Разделение ролей, как автоматический сервис/ security/ backup снижает и операционный, и риски ИБ одновременно
• Whitelist адресов с пороговыми проверками, подключенными к мониторингу являются независимыми слоями поверх самой мультиподписи
• Скомпрометировать один ключ при схеме 2/3, а особенно Эскроу - проблематично

Сноска

• Хеш адреса (locking script) — каждый непотраченный выход транзакции защищён условием
• M-of-N (пороговая подпись) — схема где N — общее количество участников с ключами, M — минимальное количество подписей для совершения операции
• Эскроу (escrow) — механизм условного хранения: средства блокируются у нейтральной третьей стороны до выполнения условий сделки

#devsecops #pmi #reco #research #pmcases #techsolution #term

🛠 Understand-Anything граф знаний AppSec

Салют,
Сегодня хочу поделиться инфой о интересном проекте, который позволяет разобрать проект в понятной картинке для тебя. Итого, это Understand-Anything — плагин для Claude Code, который через LLM строит интерактивный knowledge graph: узлы, связи, архитектурные слои и гайд-тур по кодовой базе проекта.

По сути, это прикольная фишка, где ты можешь поставил плагин, прогнать и получить вот это:

• Скан репо с определением языков, фреймворков, импортов
• Семантические батчи
• Собирать граф: узлы (файлы, функции, классы, конфиги, сервисы, схемы) и связи (imports, calls, depends_on, deploys, tested_by)
• Раскладывает по архитектурным слоям, строит тур гид (смотри обрезом в .mmd), то есть на выходе knowledge-graph.json, из которого можно собрать High level Arhitecture всей системы
• Поднимает локальный дашборд для визуализации и навигации

Зачем в AppSec?

• Быстрое обследование кодовой базы — за минуты видишь точки входа, потоки данных, внешние интеграции и все внешние вызовы без ручного grep
• Готовый onboarding для нового человека на security review
• .understandignore — сразу выкидываешь секреты, lock-файлы и мусор из анализа (ну мы же знаем, что лучше воткнуть в Vault)
• knowledge-graph.json коммитится в репо — любой следующий аудитор получает карту сразу после git clone
• HTTP-связи фронта и бэка в граф не попадают: видит статические импорты, не сетевые вызовы

Команды:

# Node ≥22 и pnpm, далее собрать ядро
npm install -g pnpm
cd ~/.understand-anything/repo/understand-anything-plugin
pnpm install && pnpm --filter @understand-anything/core build

# Построить граф
/understand --language ru

# Поднять интерактивный дашборд
/understand-dashboard

# флаги:

--full (полный пересбор) 
--review (LLM-ревью графа)

Итого:

• Не серебряная пуля, но как карта местности для незнакомого кода — очень бодро
• Граф и в .mmd для архитектуры или security самое то, когда надо вьехать сразу, ну а дальше, по старинке, уже ручки и голова
• Attack surface mapping с нуля (API endpoints, webhooks, очереди), внешние интеграции, публичные vs внутренние интерфейсы.
• Scope для пентеста. Из графа сразу видно что тестировать: все внешние API-вызовы, все обработчики входящих данных, все места где user input попадает в систему
• Буквально guided walkthrough по архитектуре
• Видишь границы доверия

#appsec #devsecops #toolсhain #techsolution #reco #reserch

Так, я хочу поделиться своими парнями дипломниками с ИУ-10, которые прошли защиту диплома и выпустились во взрослый мир.

Три человека прошли защиту на отлично, гордость и просто красавцы 🙏🫶 математическая модель, которая так всех волновала, а самое главное конкретный софт на выходе - сделаны на ура совместно, горжусь ребятками

С кайфом в ИБ 🙃

#course #specialty