Руководство по снижению рисков в DeFi 04: Практики безопасности для команд DeFi-проектов

Эта серия статей, основанная на материалах "Специального выпуска о безопасности 05", подготовленного совместно OKX Web3 и BlockSec, посвящена вопросам безопасности, с которыми сталкиваются пользователи DeFi и команды DeFi-проектов.

Q1: С какими типами рисков сталкиваются DeFi-проекты и как их можно устранить?

Команда безопасности BlockSec: DeFi-проекты сталкиваются с несколькими типами рисков, включая риски безопасности кода, риски операционной безопасности и риски, связанные с внешними зависимостями.

Во-первых, риски безопасности кода относятся к потенциальным уязвимостям на уровне программного кода DeFi-проектов. Для DeFi-проектов смарт-контракты являются ядром бизнес-логики (передний интерфейс и логика серверной обработки относятся к традиционной разработке ПО и являются относительно зрелыми), поэтому именно они находятся в центре нашего внимания и обсуждения, включая:

• 1. С точки зрения разработки необходимо следовать признанным в отрасли практикам безопасного программирования смарт-контрактов, таким как паттерн Checks-Effects-Interactions, используемый для предотвращения уязвимостей повторного входа (reentrancy); также стандартные функциональные возможности следует реализовывать с использованием надежных сторонних библиотек, чтобы избежать неизвестных рисков при «изобретении велосипеда».
• 2. Во-вторых, необходимо тщательное внутреннее тестирование. Тестирование — это важная часть разработки ПО, которая помогает обнаружить многие проблемы. Однако для DeFi-проектов одного локального тестирования недостаточно для выявления всех неполадок; требуется дополнительное тестирование в среде, близкой к реальному развертыванию.
• 3. И наконец, после завершения тестирования следует привлечь авторитетные сторонние аудиторские компании. Хотя аудит не может гарантировать 100% отсутствие проблем, систематические проверки могут значительно помочь проектным командам выявить распространенные уязвимости — области, которые разработчики часто упускают из виду из-за особенностей мышления или отсутствия опыта. Конечно, поскольку квалификация и специализация аудиторских фирм различаются, при наличии бюджета рекомендуется привлечь две или более аудиторские компании.

Во-вторых, риски операционной безопасности возникают после запуска и включают как потенциальные, невыявленные уязвимости в коде (даже после тщательной разработки, тестирования и аудита), так и проблемы после развертывания, такие как утечки закрытых ключей и неправильная настройка системных параметров. Это может привести к серьезным последствиям и значительным убыткам. Рекомендуемые стратегии снижения этих рисков включают:

• 1. Создание надежной системы управления закрытыми ключами, например, использование надежных аппаратных кошельков или решений на базе MPC.
• 2. Мониторинг операционного состояния в режиме реального времени для отслеживания привилегированных операций и статуса безопасности проекта.
• 3. Создание автоматизированного механизма реагирования на риски, такого как BlockSec Phalcon, который может автоматически блокировать действия при обнаружении атаки, предотвращая тем самым дальнейшие потери.
• 4. Избегание единых точек отказа при выполнении привилегированных операций, например, использование мультисиг-кошелька Safe{Wallet}.

В-третьих, риски внешних зависимостей относятся к рискам, привносимым внешними компонентами проекта, например, зависимость от ценовых оракулов, предоставляемых другими DeFi-протоколами. Если в работе оракула возникают проблемы, это приводит к некорректным расчетам цен. Рекомендации по устранению рисков внешних зависимостей включают:

• 1. Выбор надежных внешних партнеров, таких как признанные топовые протоколы в отрасли.
• 2. Мониторинг операционного состояния (аналогично рискам операционной безопасности), но в данном случае объектом мониторинга являются внешние зависимости.
• 3. Создание автоматизированного механизма реагирования на риски (аналогично рискам операционной безопасности), однако методы реагирования могут отличаться, например, переключение на резервные зависимости вместо прямой остановки работы всего протокола.

Кроме того, для проектных команд, желающих создать возможности мониторинга, мы предлагаем следующие рекомендации:

• 1. Точная настройка точек контроля: определите, какие ключевые состояния (переменные) протокола требуют отслеживания и где именно проводить мониторинг — это первый шаг к построению возможностей мониторинга. Однако охватить все точки контроля комплексно сложно, особенно в задачах мониторинга атак, поэтому рекомендуется использовать внешний профессиональный сторонний движок обнаружения атак, протестированный в реальных условиях.

BlockSec Phalcon — единственная в мире платформа для мониторинга и блокировки атак с подтвержденной эффективностью. Она помогла спасти активы на сумму более 20 миллионов долларов в ходе более чем 20 операций по спасению активов "белыми хакерами". Узнайте больше по ссылке 👇

https://blocksec.com/blog/lead-in-phalcon-s-hack-blocking-saga

• 2. Обеспечение точности и своевременности мониторинга: точность означает минимальное количество ложноположительных (FP) и ложноотрицательных (FN) срабатываний. Неточная система мониторинга фактически бесполезна; своевременность — это предварительное условие для реакции (например, возможность обнаружения до того, как подозрительный контракт будет развернут или транзакция атаки попадет в блокчейн). В противном случае систему можно использовать только для последующего анализа, что предъявляет высокие требования к производительности и стабильности системы мониторинга.
• 3. Необходимость автоматизированного реагирования: основываясь на точном мониторинге в реальном времени, можно построить систему автоматического реагирования, включающую остановку протокола для блокировки атак и т. д. Здесь необходим настраиваемый и надежный фреймворк автоматизированного реагирования, поддерживающий гибкую настройку стратегий в соответствии с потребностями проекта и автоматическое выполнение действий.

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

Команда безопасности OKX Web3 Wallet: Команды DeFi-проектов сталкиваются с разнообразными рисками, включая следующие основные категории:

• 1. Технические риски: в основном включают уязвимости смарт-контрактов и кибератаки. Меры защиты включают принятие стандартов безопасной разработки, наем профессиональных сторонних аудиторских компаний для комплексного аудита смарт-контрактов, запуск программ поиска уязвимостей (bug bounty) для поощрения «белых хакеров» и изоляцию активов для повышения сохранности средств.
• 2. Рыночные риски: включают колебания цен, риски ликвидности, манипулирование рынком и риски комбинаторности протоколов. Меры защиты включают использование стейблкоинов и хеджирование для защиты от ценовых колебаний; использование майнинга ликвидности и механизмов динамических комиссий для решения проблем ликвидности; строгую проверку типов активов, поддерживаемых протоколами DeFi, и использование децентрализованных оракулов для предотвращения манипуляций рынком; а также постоянное обновление и оптимизацию функций протокола для борьбы с конкурентными рисками.
• 3. Операционные риски: в основном включают человеческие ошибки и риски механизмов управления. Меры защиты включают создание строгих внутренних контролей и операционных процессов для минимизации человеческих ошибок; использование автоматизированных инструментов для повышения эффективности работы; и разработку устойчивых механизмов управления для баланса между децентрализацией и безопасностью, например, введение задержек голосования и мультиподписных механизмов. Также необходимо следить за уже запущенными проектами и иметь планы экстренных действий для немедленного реагирования и минимизации убытков в случае сбоев.
• 4. Регуляторные риски: в основном включают требования по соблюдению законодательства и обязанности в рамках борьбы с отмыванием денег (AML) и процедур «Знай своего клиента» (KYC). Меры защиты включают наем юридических консультантов для обеспечения соответствия проекта законодательным и регуляторным требованиям, создание прозрачных политик соответствия и активное внедрение мер AML и KYC для повышения доверия пользователей и регулирующих органов.

Q2: Как DeFi-проектам оценивать и выбирать авторитетную аудиторскую фирму?

Команда безопасности BlockSec: Вот несколько простых стандартов для справки:

• 1. Проводила ли фирма аудит известных проектов: это указывает на то, что компания признана серьезными игроками.
• 2. Подвергались ли аудированные ими проекты атакам: хотя теоретически аудит не может гарантировать 100% безопасность, практический опыт показывает, что большинство проектов, прошедших аудит у авторитетных компаний, не подвергались атакам.
• 3. Оценка качества аудита по историческим отчетам: отчет об аудите является важным показателем профессионализма компании, особенно если можно сравнить аудит одного и того же проекта или аналогичной сферы. Основное внимание следует уделить качеству (критичности) и количеству найденных уязвимостей, а также тому, принимаются ли рекомендации аудиторов проектной командой.
• 4. Профессионализм персонала: состав сотрудников аудиторской фирмы, включая их образование и профессиональный бэкграунд, систематическое обучение и опыт работы в индустрии, играют важную роль в обеспечении качества аудита.