За даними CertiK, які наводить Cointelegraph, у першій половині 2025 року через компрометацію гаманців у 34 інцидентах викрали понад $1,7 млрд. Це змінює підхід до пошуку найкращих захищених гаманців: важливо не те, який пристрій здається найбезпечнішим, а що має отримати зловмисник, перш ніж ваша інфраструктура створить чинний підпис.
Для установи відновлення та підзвітність є частиною того самого рішення. Архітектура гаманця має протистояти крадіжці, працювати за недоступності підписувачів і залишати фінансовій команді та команді з відповідності достатньо доказів для пояснення кожного переказу.
Зміст
- Де насправді відбуваються втрати з гаманців
- Коротке порівняння захищених гаманців за сценарієм
- Порівняння seed-фраз, апаратних гаманців і підписання MPC
- Компроміси відновлення, які пропускають рейтинги
- Критерії оцінювання для бірж і фінтех-гаманців
- Як установити операційні контролі, що обмежують масштаб шкоди
- Поширені запитання про захищені гаманці
- Оберіть і впровадьте архітектуру гаманця
- Записи відповідності та докази звірки
Де насправді відбуваються втрати з гаманців
За даними Chainalysis, у 2024 році криптовалютні злами спричинили крадіжку приблизно $2,2 млрд, що на 21,07% більше, ніж у 2023 році, а кількість інцидентів зросла з 282 до 303. Той самий аналіз пов’язує 43,8% викраденої у 2024 році криптовалюти з компрометацією приватних ключів. Серед прикладів — втрата DMM Bitcoin приблизно $305 млн у травні 2024 року та WazirX приблизно $234,9 млн у липні 2024 року.
Це глобальні дані про централізовані сервіси й екосистеми децентралізованих фінансів, а не частота відмов конкретного гаманця. Проте вони вказують на корисний інженерний пріоритет: захищайте повноваження на підписання, а не лише доступ до облікового запису.
Загроза — це зловмисник, який отримує чинний підпис для переказу, якого ваша компанія не планувала. Шляхи можуть бути різними:
- Вилучення ключового матеріалу. Викрадення seed-фрази, відкритого приватного ключа або достатньої кількості незалежно збережених часток для подолання порога.
- Компрометація точки підписання. Зміна транзакції, яку готує застосунок, або використання компонента з правом підпису.
- Маніпуляція особою, що схвалює. Фішинг або видавання себе за іншу особу, щоб переконати законного оператора дозволити неправильний переказ.
Чинний підпис не доводить бізнес-намір
За даними Chainalysis, які наводить The Block, у 2024 році компрометації особистих гаманців становили 44% загальної вартості викраденої криптовалюти, порівняно з 7,3% у 2022 році. Окремо CertiK пов’язав із фішингом понад $1 млрд втрат криптовалюти у 296 інцидентах 2024 року, як повідомляє Cointelegraph.
Ізоляція ключа протидіє його вилученню. Вона не доводить, що адреса призначення належить потрібному одержувачу або що працівник схвалив справжню, а не сфабриковану інструкцію.
Оцініть ризик, з’ясувавши, хто має ключовий матеріал, скільки сторін повинні схвалити операцію, що бачить особа, яка схвалює, і що фіксується. Вимагайте конкретних відповідей, зокрема щодо службових облікових записів і аварійних процедур, замість схеми лише нормального шляху.
Практичний висновок: гаманець настільки сильний, наскільки сильне правило, яке треба виконати до появи підпису.
Коротке порівняння захищених гаманців за сценарієм
| Сценарій | Модель безпеки | Чому підходить | Основний недолік |
|---|---|---|---|
| Приватний власник, помірний баланс | Апаратний гаманець із записаною seed-фразою | Ключі залишаються офлайн; пристрій показує деталі транзакції | Одна резервна seed-фраза; немає політики схвалення |
| Приватний власник, велика сума | Апаратний гаманець із багаточастковою резервною копією або мультипідписом | Розподіляє матеріал відновлення чи повноваження підписання | Складне відновлення, яке треба відпрацьовувати |
| Мала команда або казначейство | Мультипідпис M-з-N з апаратними підписувачами | Кілька осіб мають погодитися до руху коштів | Затримка на координацію підписувачів |
| Виплати фінтеху або біржі | MPC 2-з-3 з контрольованим клієнтом Co-Signer | Повний ключ не відновлюється; політика виконується до підпису | Якість політики й залежність від постачальника |
| Програмний гаманець із seed-фразою користувача | Seed-фраза в програмі | Низька вартість і швидкий старт | Шкідливе ПЗ на пристрої може прочитати фразу або підписати |
| Гаманець без seed-фрази або на ключах доступу | Відновлення ключа за допомогою пристрою чи хмари | Менше перешкод під час підключення | Безпека постачальника відновлення та пристрою |
Сприймайте це як карту розгортання, а не універсальний рейтинг. Вартість транзакції, кількість осіб, що схвалюють, і частота підписання визначають прийнятний компроміс.
Казначейство з рідкісними переказами може дозволити собі ретельну координацію підписувачів. Сервіс виплат потребує автоматизованих рішень, але автоматизація не повинна давати одному застосунку необмежену владу над усім балансом.
Узгодьте модель з операційним навантаженням
Для приватної особи апаратний гаманець корисно відокремлює підключений до інтернету застосунок від ключа підписання. Для бізнесу той самий пристрій може стати операційним вузьким місцем, якщо його тримає один працівник і ніхто не відпрацьовував заміну.
Так само багаточасткова резервна копія й мультипідпис не є взаємозамінними. Перша розподіляє матеріал відновлення, другий — повноваження. Власнику значної суми можуть знадобитися обидва, але він має розуміти призначення кожного.
Підключення без seed-фрази усуває потребу працювати з фразою відновлення у звичайному шляху користувача. Воно не усуває потреби перевірити відновлення облікового запису, заміну пристрою, доступність постачальника чи адміністративні способи обходу.
Жодна модель не перемагає за всіма критеріями. Обирайте ту, залишкові ризики якої команда справді здатна контролювати.
Рекомендації таблиці припускають правильну реалізацію. Формально розподілена схема не є незалежною, якщо всі підписувачі використовують той самий адміністраторський обліковий запис, пристрій або канал відновлення.
Порівняння seed-фраз, апаратних гаманців і підписання MPC
| Критерій | Seed-фраза в програмі | Апаратний гаманець | MPC 2-з-3 з Co-Signer |
|---|---|---|---|
| Ключовий матеріал у стані спокою | Повна seed-фраза на пристрої чи в резервній копії | Seed-фраза під захистом пристрою; захищений елемент, якщо реалізовано | Розподілені частки; повний ключ не відновлюється під час підписання |
| Що має отримати зловмисник | Seed-фразу або контроль над уповноваженим програмним підписувачем | Робочий доступ до пристрою, seed-фразу або вразливість шляху підписання | Достатньо незалежних учасників для виконання порога |
| Перевірка транзакції | Екран комп’ютера чи телефона | Екран пристрою з підтримуваним зрозумілим підписанням | Перевірки політики та схвалення контрольованим клієнтом Co-Signer |
| Один скомпрометований компонент | Може відкрити повноваження підписання гаманця | Результат залежить від компонента й захисту пристрою | Одна частка не дозволяє транзакцію |
| Аудиторський слід | Залежить від застосунку | Зазвичай без журналу бізнес-схвалень на пристрої | Потребує пов’язаних операційних записів запитів і схвалень |
У програмному підписанні зловмисник може атакувати seed-фразу або процес, уповноважений її використовувати. Шифрування резервної копії не захищає транзакцію після того, як шкідливе ПЗ отримало контроль над активним застосунком підписання. Для операційного використання ця модель потребує особливо суворих лімітів балансу й контролю кінцевих пристроїв.
В апаратному підписанні зловмисник має подолати захист пристрою, отримати резервну копію або домогтися дозволеного підпису. Фізична стійкість і можливість незалежної перевірки — різні критерії: порівняння апаратних гаманців Spark розглядає захищений елемент і відкритість прошивки окремо, зокрема Infineon OPTIGA Trust M у Trezor Safe 3 та закриту прошивку захищеного елемента Ledger.
Порогова схема захищає лише визначену межу
Для підписання MPC зловмисник має скомпрометувати достатню кількість незалежних учасників або маніпулювати їхніми шляхами авторизації. Вступ NIST до порогової криптографії розрізняє поріг участі — сторони, потрібні для операції, — і поріг компрометації — кількість зловмисних сторін, яку система витримує. У правильно реалізованій схемі 2-з-3 одна скомпрометована частка не може дозволити транзакцію, а решта учасників підтримують доступність, коли один недоступний.
Ця гарантія передбачає справжнє розділення. Спільні облікові дані, спільний контроль розгортання чи обхід політики можуть зруйнувати незалежність, обіцяну схемою.
BroSettlement надає інфраструктуру зберігання MPC і вбудовані гаманці з Co-Signer під контролем клієнта. Наше порівняння MPC та мультипідпису допомагає відрізнити порогове підписання від схем, що потребують кількох видимих у блокчейні підписів.
Для людського схвалення вимагайте зрозумілого підписання: адреса одержувача, мережа, сума та дія контракту мають бути зрозумілими на довіреному екрані. Блокуйте схвалення, якщо система не може надійно показати дію, замість пропозиції оператору схвалити непрозоре навантаження.
Захищений елемент ускладнює фізичне вилучення. Відкрита прошивка підтримує незалежну перевірку. Жоден із них не замінює політики транзакцій, тому оцінюйте необхідні кроки зловмисника й реальну видимість для особи, що схвалює, а не лише сертифікати.
Компроміси відновлення, які пропускають рейтинги
Сильніша ізоляція не обов’язково безпечніша, якщо законний власник не може відновити доступ. Академічне опитування 331 користувача у 2025 році показало перевагу зберігання ключів на особистих пристроях і копій на кількох пристроях заради зручності. Надмірність підвищує доступність, але погано захищені копії створюють додаткові шляхи крадіжки.
| Сценарій | Лише seed-фраза | Shamir 3-з-5 | MPC 2-з-3 |
|---|---|---|---|
| Втрачено один пристрій | Відновлення можливе, якщо резервна seed-фраза ціла | Відновлення з будь-яких трьох часток | Два учасники, що залишилися, можуть підписати |
| Резервну копію викрадено чи сфотографовано | Повну фразу розкрито; кошти під загрозою | Дві частки не розкривають достатньо даних | Одна частка не може підписати сама |
| Втрачено дві одиниці відновлення | Повна втрата, якщо не лишилося придатної копії чи підписувача | Три частки, що лишилися, дають відновлення | Підписання заблоковано; потрібне задокументоване відновлення або зміна ключів |
| Втрачено три одиниці відновлення | Повна втрата, якщо не лишилося придатної копії чи підписувача | Незворотна втрата без іншого шляху | Підписання заблоковано; допоможе лише заздалегідь створений шлях відновлення |
| Навчання без руху коштів | Відновити тестовий гаманець і порівняти адресу | Відновити тестовий гаманець офлайн | Імітувати заміну підписувача в тестовому середовищі |
Приклад Shamir використовує порогову механіку з посібника Ledger із вибору апаратного гаманця: три з п’яти часток можуть відновити гаманець, тоді як дві не розкривають достатньо інформації. Втрата трьох залишає замало часток для відновлення.
Відновлення має працювати без окремих людей
Безперервність MPC і аварійне відновлення — різні речі. Решта учасників може працювати в межах порога, але зміна ключів не є чарівним виходом після втрати надто багатьох часток. Життєздатна процедура заміни чи аварійного доступу має існувати заздалегідь.
Задокументуйте розташування часток, названих зберігачів, процедури успадкування й реагування, заміну підписувачів і відповідального за ескалацію. Наш посібник про доступ до приватного ключа та відновлення корисний для розмежування експортованих секретів і доступу до підписання.
Відпрацьовуйте процес на окремому тестовому гаманці, а не вводьте seed-фразу робочого гаманця у звичайний комп’ютер. Порівняйте похідну адресу, завершіть процес схвалення та заміни й зафіксуйте тривалість відновлення як операційний показник.
Критерії оцінювання для бірж і фінтех-гаманців
Оцінюйте кожного кандидата відповіддю так або ні на основі показаної поведінки, а не обіцянок у плані розвитку. До кожної позитивної відповіді додайте результат тесту, експорт конфігурації або приклад запису.
- Зберігання ключів: жодна сторона чи пристрій не може відновити повний ключ самостійно.
- Політика підписання: кожен запит до підпису проходить примусові ліміти гаманця, правила адрес призначення та вимоги схвалення.
- Попередній перегляд: кожна особа, що схвалює, бачить однакові дані одержувача, мережі, активу й суми. Транзакції, які неможливо показати, блокуються.
- Записи: незмінний запис пов’язує запит, результат перевірки, схвалення й остаточний ідентифікатор транзакції.
- Дані Travel Rule: потрібна інформація про відправника й одержувача безпечно отримується, зберігається та передається у відповідному процесі до підписання виплати.
- Події та ідемпотентність: операційна команда отримує події депозиту, підтвердження й виведення; повтор виплати не може створити інший переказ.
- Контроль доступу: застосовуються рольові дозволи, списки дозволених IP, ключі API з обмеженням на гаманець і дію та автентифіковані запити із захистом від повторення.
- Перевірка випусків: доступні підписані випуски й задокументовані процедури оновлення прошивки чи ПЗ.
- Тестування відновлення: навчання з вимірюванням часу демонструє відновлення й заміну підписувача.
- Реагування на інциденти: перевірений шлях заморожування має названу відповідальну особу.
Операційні докази важливіші за кількість функцій
Рекомендації FATF щодо віртуальних активів вимагають від охоплених установ негайно й безпечно отримувати, зберігати та передавати визначену інформацію про відправника й одержувача, а також визначають USD/EUR 1 000 як поріг належної перевірки клієнта для разової транзакції у контексті віртуальних активів. Застосовуйте реалізацію відповідної юрисдикції, а не вважайте міжнародні рекомендації повним місцевим правовим аналізом.
Для автоматизованих виплат надавайте найбільшу вагу політиці підписання, записам та обробці Travel Rule. Нездатність показати транзакцію або пройти тест відновлення вважайте підставою для відмови незалежно від загальної оцінки.
BroLabel надає операційний журнал гаманців і транзакцій для звірки та аудиту. Ваш приймальний тест усе одно має довести, що інтеграція пов’язує ці записи з власними системами одержувачів, схвалення й обліку.
Для проходження переліку потрібні докази, які команда може відтворити, а не неперевірене «так» постачальника.
Як установити операційні контролі, що обмежують масштаб шкоди
ФБР оцінило заявлені втрати від шахрайства з криптовалютними інвестиціями у 2024 році в понад $5,8 млрд, а на людей віком 60 років і старше припало приблизно $2,8 млрд ширших втрат від криптовалютного шахрайства, за повідомленням Міністерства юстиції США. Ці втрати підкреслюють операційну загрозу: уповноваженою людиною маніпулюють для схвалення шахрайського переказу або скомпрометований пристрій має надмірні повноваження.
Обмежте ризик кожного схвалення
- Класифікуйте гаманці за вартістю та ініціатором. Розділіть казначейство, виплати клієнтам і дії агентів, щоб компрометація застосунку не успадкувала повноваження казначейства.
- Установіть ліміти транзакції й дня. Обмежте можливу втрату до необхідності нового рішення.
- Ведіть перевірену адресну книгу. Незалежно перевіряйте нових одержувачів замість копіювання адрес із чатів.
- Вимагайте незалежного схвалення понад поріг. Використовуйте іншу особу й пристрій, а не ще один сеанс на комп’ютері ініціатора.
- Затримуйте перші перекази на нові адреси. Дайте моніторингу й операторам час оскаржити маніпульовану інструкцію.
- Перевіряйте на власному екрані особи, що схвалює. Зіставляйте підписану транзакцію зі схваленим бізнес-запитом.
- Підпишіться на події виведення та політик. Сповіщайте про незвичні адреси, відхилені запити чи неочікувані шаблони.
- Відпрацьовуйте заморожування й ротацію ключів щонайменше щокварталу. Повторюйте після суттєвих змін архітектури.
- Виконуйте щоденну звірку до наступного циклу виплат. Розслідуйте невідповідні доручення, відправлення в мережу й записи журналу, а не переносьте розбіжності далі.
Обмежуйте також повноваження машин
Для автономних процесів корисний контекст дає матеріал Agntz про надмірні дозволи облікових даних AI-агентів. Надавайте агенту право запитувати обмежену дію, а не необмежене право підписання.
Клієнт повинен захищати облікові дані та контрольовані ним матеріали підписання, виконувати чинні вимоги автентифікації й негайно повідомляти про підозру на компрометацію чи несанкціонований доступ. Ліміти та незалежні схвалення зменшують вартість однієї відмови лише за умови щоденного виконання операторами.
Поширені запитання про захищені гаманці
Питання зберігання активів для бізнесу
Чи достатньо бізнесу апаратного гаманця?
Один апаратний підписувач захищає ключ, а не політику схвалення організації. Скористайтеся умовами проходження в розділі Критерії оцінювання для бірж і фінтех-гаманців, щоб знайти прогалини врядування. Перевірте переказ, який оператор не повинен мати змоги схвалити самостійно.
Чи означає MPC 2-з-3, що постачальник може перемістити мої кошти?
Сам поріг не визначає, хто контролює кожного учасника та які комбінації можуть підписувати. Контрольований клієнтом Co-Signer має бути обов’язковою вимогою в запланованому робочому шляху, а не необов’язковою перевіркою. Перевірте топологію та виконайте тест відмови в підписанні.
Питання відновлення та схвалення
Скільки копій для відновлення слід зберігати?
Оберіть достатню кількість незалежно захищеного матеріалу для виконання вимог доступності без створення некерованих копій. Розділ Компроміси відновлення, які пропускають рейтинги розрізняє дублікати seed-фраз і порогові частки. Призначте зберігачів і відпрацюйте відновлення до поповнення гаманця.
Чи важливий захист від фішингу, якщо ключ у безпеці?
Так. Втрати від фішингу з розділу Де насправді відбуваються втрати з гаманців показують, чому захист секретів не підтверджує законність одержувача. Законний підписувач усе одно може схвалити транзакцію зловмисника. Перевірте, чи незнайома адреса запускає перевірку до схвалення.
Оберіть і впровадьте архітектуру гаманця
Впроваджуйте архітектуру як операційну систему для переказів, а не лише інтеграцію гаманця. Шлях запуску має створювати докази безпечної відмови так само, як успішного платежу.
- Визначте ризик. Зафіксуйте суму під ризиком для кожного гаманця й кожну людину, застосунок або агента, здатних ініціювати переказ.
- Оберіть модель безпеки. Зіставте таблицю сценаріїв із потрібною частотою транзакцій і доступними особами, що схвалюють.
- Опишіть політику до написання коду. Визначте ліміти, списки дозволених адрес, вимоги схвалення й затримки нових адрес.
- Перевірте тестове середовище. Підтвердьте потрібні мережі та випробуйте некоректні транзакції, відмову в підписанні, повтори й недоступних учасників.
- Виміряйте відновлення. Задокументуйте заміну частки чи учасника й потрібні повноваження.
- Запускайте з операційним власником. Призначте названим командам моніторинг подій, щоденну звірку та рішення про заморожування.
Відокремлюйте доступну інфраструктуру від запланованих інтерфейсів
BroSettlement надає інфраструктуру зберігання MPC і вбудовані гаманці, зокрема контрольований клієнтом Co-Signer. Наші інженери допомагають спроєктувати гаманці, записи журналу, політики підписання та події від початку до кінця.
BroWallet заплановано для Telegram, вебу й мобільних пристроїв, а AI Agent Wallets перебувають у розробці. Їх не слід вважати доступними зараз функціями BroSettlement; коли продукти стануть доступними, діятимуть окремі умови.
Для інтеграцій агентів будуйте запити навколо ключів API з вузькими дозволами й тієї самої примусової політики підписання, що застосовується до інших ініціаторів. Події WebSocket живлять моніторинг; реалізуйте й перевірте ключі ідемпотентності, щоб повтори не дублювали виплати, і пов’язуйте записи журналу зі схваленнями. Наші засоби інтеграції включають REST API, автентифікацію Ed25519 і події WebSocket.
Межа запуску: клієнт відповідає за адреси, вибір мережі й активу, суми, дані одержувача, транзакційні інструкції та власні рішення щодо відповідності вимогам і ризику. Блокчейн-транзакції можуть бути незворотними.
Оцініть короткий список за переліком, випробуйте тестове середовище й перевірте результати з операційною командою та командою з відповідності до ввімкнення робочих переказів. Переконайтеся, що кожен заявлений контроль існує в договірному розгортанні, а не лише в запропонованій архітектурі.
Записи відповідності та докази звірки
Хеш транзакції доводить існування блокчейн-транзакції. Він не визначає, хто запитав переказ, яку інформацію про одержувача перевірили, чи було схвалення чинним і як фінансова команда облікувала рух.
FATF повідомляє, що 99 юрисдикцій ухвалили або ухвалюють законодавство для реалізації Travel Rule, за даними цільового оновлення щодо віртуальних активів. Це робить записи прозорості платежів архітектурним питанням, хоча точні обов’язки залежать від застосовного права.
Побудуйте ланцюг доказів навколо переказу
| Запис | Докази для збереження | Операційна мета |
|---|---|---|
| Доручення на переказ | Ідентифікатор запиту, ініціатор, посилання на одержувача | Установити заплановану дію |
| Рішення політики | Результат перевірки, версія політики, причина | Пояснити схвалення або відмову |
| Авторизація | Особа, що схвалила, і схвалені деталі транзакції | Довести дозволені повноваження |
| Відправлення | Мережа, ідентифікатор транзакції, статус відправлення | Відстежити виконання |
| Звірка | Записи журналу, комісії, винятки, рішення | Пояснити бухгалтерську обробку |
Зберігайте конфіденційні дані одержувача за належними контролями доступу. Аудиторський слід не повинен перетворюватися на загальнодоступне сховище персональних даних чи секретів підписання.
Наш посібник із процесу аудиту допомагає структурувати передавання між операційною, фінансовою командами та рецензентами. Призначте власника кожному винятку й зберігайте рішення замість перезапису початкової події.
Події не замінюють довговічних записів
Події WebSocket дають операторам змогу швидко реагувати, але споживачі повинні обробляти розриви, повторну доставку й затримки. Звірка має спиратися на довговічні записи та явні стани транзакцій, а не припускати, що отримання події означає завершення виплати.
Для підтвердження контролів корисний посібник Foo Guard про повторне використання доказів SOC 2 для сертифікації ISO, коли потрібно впорядкувати запити доказів, що перетинаються. Повторно використовуйте доречні матеріали, не припускаючи, що одна оцінка автоматично задовольняє іншу систему.
До запуску перевірте пропущені події, дубльовані запити, відхилені схвалення та непідтверджені відправлення. Заморожування може зупинити майбутнє підписання під вашим контролем, але не здатне надійно скасувати вже виконану в блокчейні транзакцію.
BroLabel пропонує інфраструктуру MPC-гаманців, контрольоване клієнтом спільне підписання, операційні журнали та підтримку інтеграції для команд, що будують керовані процеси переказів. Відвідайте BroLabel, щоб перевірити архітектуру гаманця та запланувати тестове середовище для випробування політики підписання, відновлення й звірки до запуску в робочому режимі. Bro has your back!
