Вступ
Сектор блокчейну має особливу одержимість виявленням вразливостей у коді смарт-контрактів. Інвестиції команд розробників спрямовуються на аудити, конкурси з пошуку багів, інструменти фузінгу та методи формальної верифікації, оскільки існує переконання, що виявлення всіх цих остаточних багів у коді забезпечить безпеку.
Цей метод є важливим, але не враховує один з найстрашніших фактів, який став відомим у 2024 році. Найбільш катастрофічним шляхом атаки, який наразі загрожує протоколам криптовалют, є не складні ланцюжки експлойтів чи приховані вразливості коду. Натомість, це значно глибша і навіть менш обговорювана загроза, яка домінувала в ландшафті загроз протягом останніх років.
Компрометація приватних ключів домінує в ландшафті загроз
Дослідження 2024 року надає тривожну статистику, яка змусить нас переглянути підхід до безпеки блокчейну. Частка всіх викрадених криптовалютних коштів за рік, які були скомпрометовані через приватний ключ, становить 43,8%, що робить цей тип атак найуспішнішим.
Слабкі місця архітектурного контролю доступу зазвичай не повідомляються традиційними аудиторськими фірмами, що спеціалізуються на блокчейні, як офіційні висновки, а конкурентні аудиторські платформи явно не заохочують подання, що зосереджуються на таких системних проблемах.
Таке цілеспрямоване мислення різко контрастує з найкращими практиками аудиту безпеки в інших галузях, де підвищення привілеїв та проектування контролю доступу є основними питаннями, які необхідно враховувати на ранніх етапах циклу розробки, коли часто вже запізно змінювати загальну природу проблем контролю доступу в системі.
Щоб уявити вплив дизайнерських рішень на вразливість до атак на приватні ключі, розглянемо наступний теоретичний протокол надзабезпеченого кредитування. Однак для виконання декількох важливих операцій необхідний привілейований доступ до таких систем:
- •Внесення до списку та виключення зі списку підтримуваних активів
- •Налаштування параметрів ризику та процентних ставок
- •Збір протокольних зборів
- •Аварійні паузи та оновлення розробки смарт-контрактів
Це визначає загальну стійкість такого протоколу до компрометації приватного ключа.
Рівень 1: Повна експозиція з контролем в одній точці
Найнижчий рівень — це рівень, на якому розробник має єдиний зовнішній контрольований обліковий запис з повними адміністративними правами на всі функції протоколу. Ця архітектура є найбільш вразливою конфігурацією, в якій порушення одного приватного ключа надасть зловмисникам миттєвий і повний доступ до системи, яка може існувати у вигляді програмних гаманців, підключених до Інтернету.
Загроза зради є величезною, а її наслідки — руйнівними та безпосередніми.
Рівень 2: Просте управління ризиками за допомогою розподілених ключів
Наступним рівнем зрілості є передача адміністративних повноважень до гаманця з багаторазовим підписом, який потребуватиме застави від декількох власників ключів для виконання оновлення. Це може лише зменшити ймовірність компрометації та не обмежує ступінь, в якому протокол може бути пошкоджений, але все ж є покращенням.
Це набагато краще, ніж контроль за допомогою одного ключа з точки зору безпеки, оскільки для захоплення протоколу більше не потрібно достатнього доступу з компрометацією одного ключа підписувача. Проте, незважаючи на поліпшення, все ще існують високі ризики:
- •Швидкість виконання є важливим питанням, оскільки зловмисні дії можуть бути здійснені до вжиття заходів безпеки
- •Хоча точки відмови розподілені між ключами, структура управління залишається централізованою
- •Навіть добре захищені системи з багаторазовим підписом можуть бути порушені за допомогою просунутих методів соціальної інженерії
Рівень 3: Покращений захист за допомогою розділення за часом та ролями
Для досягнення значного підвищення зрілості необхідно впровадити два критично важливі механізми контролю: часові обмеження та принцип мінімальних привілеїв.
Таймлоки встановлюють затримку між затвердженням транзакції та її виконанням, що дає час для ретельного вивчення транзакції та реагування на інциденти. Принцип мінімальних привілеїв полягає у розділенні ролей та обов'язків таким чином, щоб кожна роль мала лише мінімальний обсяг дозволів, необхідних для виконання конкретної функції.
Цей рівень стосується фундаментальних недоліків простіших методів:
- •Не дозволяє негайного виконання
- •Розподіляє контроль між декількома спеціалізаціями
- •Дає час командам з безпеки перевірити несподівані транзакції
- •Дозволяє здійснювати проактивне втручання, а не реагувати на вже завдані збитки
Рівень 4: Найвищий рівень безпеки
Найвищий рівень зрілості базується на повній відмові від адміністративних дій і є найбільш радикальною формою прихильності ідеї децентралізації та мінімізації довіри. Така стратегія категорично виключає контроль доступу як частину моделі загроз протоколу.
Щоб досягти цього рівня, необхідні підходи, які повністю відрізняються від усіх інших рівнів:
- •Можливість оновлення контрактів повинна бути скасована - смарт-контракти стають повністю незмінними
- •Перелік активів стає бездозвільним - самодостатні ринки розгортаються незалежно
- •Параметри ризику закріплені назавжди - адміністративне управління неможливе
- •Екстрене втручання неможливе - системи не можна налаштовувати після впровадження
У випадку систем надзабезпечених кредитів необхідно врахувати кілька критично важливих елементів:
- •Нові функції, розгорнуті в абсолютно різних розгортаннях з ручною міграцією користувачів
- •Ринки, сформовані як незалежні протокольні інстанції для конкретних активів
- •Параметри ризику відповідають алгоритмічним рекомендаціям або постійним налаштуванням розгортання
Ця цифра в п'ять разів перевищує будь-які інші підтверджені типи атак, але екосистема безпеки блокчейну в основному не готова до боротьби з такою загрозою.
Захистіть свій протокол вже сьогодні
Не чекайте на компроміс. Впровадьте належний контроль доступу вже зараз.
Структура розділення ролей
| Тип ролі | Обов'язки | Вимоги до безпеки | Тривалість блокування |
|---|---|---|---|
| Основна система | Оновлення контракту | Високі пороги мультипідпису | Тривалі затримки |
| Операції | Повсякденна настройка протоколу | Помірні вимоги до безпеки | Середні затримки |
| Пауза Guardian | Призупинення дії протоколу надзвичайних ситуацій | Можливість негайних дій | Без затримок |
| Скасувати Guardian | Скасуйте зловмисні затвердження | Орган швидкого реагування | Без затримок |
Команди з безпеки тепер можуть активно втручатися у випадки, а не просто реагувати на шкоду, коли вона вже завдана, але це супроводжується новими ризиками, такими як можливі помилки в системах управління ролями.
Хоча ця парадигма проектування не має жодного ризику контролю доступу, вона має значні недоліки, включаючи неможливість втручання в екстрених випадках та величезні початкові витрати на перевірку.
Створення стійких систем з першого дня
Вразливість приватного ключа, яка стала причиною майже половини всіх крадіжок криптовалюти в 2024 році, є проблемою, яку не можна ігнорувати через вибір архітектури контролю доступу, зроблений на початку процесу проектування. Хоча традиційне виявлення вразливостей все ще є необхідним, фундаментальні проектні рішення доведеться розглядати набагато раніше в циклі розробки.
Реальні заходи, які можна вжити для підвищення безпеки, включають:
- •Щирий аналіз поточного стану зрілості протоколу
- •Впровадження контрактів з часовим обмеженням на адміністративні функції
- •Адекватні системи моніторингу для адміністративних режимів з високим рівнем ризику
- •Відображення привілейованих функцій та поділ на логічні ролі
- •Застосування принципів мінімальних привілеїв
- •Ідентифікація елементів дизайну, придатних для незмінних шаблонів
Розробники можуть створювати інноваційні та надійні протоколи, якщо розуміють рамки зрілості та свідомо обирають шаблони проектування, які не покладаються на довіру та не допускають поширення компромісів.
Це вимагає інвестицій в оперативну стійкість на перших етапах розробки, щоб протоколи були стійкими не тільки до технічних втручань, але й до людських факторів, які роблять компрометацію приватного ключа таким успішним джерелом загрози.
