Обеспечение отказоустойчивости и катастрофоустойчивости систем выпуска ЦФА

Информационная система, в которой ведётся реестр прав на цифровые финансовые активы, должна быть доступна без перебоев. Утрата данных или длительный простой означают невозможность проведения сделок, выплаты купонов и погашения — то есть нарушение обязательств перед инвесторами. Банк России предъявляет к операторам строгие требования по обеспечению отказоустойчивости и катастрофоустойчивости.

Чем отказоустойчивость отличается от катастрофоустойчивости

Отказоустойчивость (fault tolerance) — способность системы продолжать работу при выходе из строя отдельных компонентов: серверов, сетевых каналов, дисков. Достижение отказоустойчивости — задача архитектуры. Отказ одного компонента не должен приводить к остановке всей системы.

Катастрофоустойчивость (disaster recovery) — способность восстановить работу после масштабного сбоя, затрагивающего весь дата-центр или несколько компонентов одновременно: пожар, наводнение, кибератака на уровне дата-центра, отказ электроснабжения, человеческий фактор (ошибка администратора).

Требования ЦБ РФ к операторам

Положение Банка России об операторах информационных систем ЦФА устанавливает, что оператор обязан:

• обеспечить доступность информационной системы не менее 99,9 % времени в месяц (допустимый простой — не более 43 минут);
• создать резервную копию реестра и хранить её в географически удалённом месте;
• иметь план восстановления работоспособности (Disaster Recovery Plan, DRP) с тестированием не реже одного раза в квартал;
• предусмотреть возможность оперативного переключения на резервную площадку (RTO — Recovery Time Objective);
• обеспечить защиту от несанкционированного доступа, включая кибератаки DDoS;
• вести журнал инцидентов и предоставлять его по запросу ЦБ.

Требования во многом аналогичны тем, что предъявляются к платежным системам и депозитариям.

Отдельные операторы публикуют собственные SLA для клиентов: в них фиксируется целевая доступность, порядок уведомления об инцидентах и компенсационные механизмы. Перед крупным размещением имеет смысл изучить публичный SLA платформы — это документ, на который можно ссылаться при претензиях.

Метрики восстановления: RTO и RPO

За двумя аббревиатурами стоит конкретика восстановления. RTO (Recovery Time Objective) — целевое время, за которое система должна вернуться в работу после аварии; для операторов ЦФА это минуты, а не часы, поскольку купонные выплаты и расчёты по сделкам идут по жёсткому календарю. RPO (Recovery Point Objective) — допустимый объём потерянных данных, измеряемый временем до последней резервной копии. При репликации в реальном времени RPO стремится к нулю: последняя подтверждённая транзакция не теряется вовсе.

Эти показатели закрепляются во внутреннем регламенте оператора и проверяются при тестировании DRP. Для инвестора метрики означают простую вещь: даже при аварии дата-центра записи о правах восстанавливаются до последней совершённой сделки, а не до «вчерашнего вечера».

Архитектурные решения

Геораспределённый реестр

Крупнейшие операторы (Сбер, Атомайз, Лайтхаус) используют геораспределённую архитектуру: основные ноды (узлы) расположены в нескольких дата-центрах в разных регионах — как минимум в двух разных временных зонах. Транзакция считается подтверждённой после записи на большинстве узлов (механизм консенсуса).

Если один дата-центр выходит из строя, остальные узлы продолжают работу. Новые транзакции подтверждаются, и система функционирует без перебоев.

Резервное копирование

Резервное копирование реестра ЦФА организуется по схеме 3-2-1:

• 3 копии данных (основная и две резервных);
• на 2 разных типах носителей (SSD + магнитная лента или объектное хранилище);
• 1 копия в удалённом хранилище (в другом городе или регионе).

Резервные копии шифруются по стандартам ГОСТ или AES-256 и подписываются квалифицированной электронной подписью оператора для обеспечения целостности. Периодичность резервного копирования — как минимум один раз в час (для крупных операторов — в реальном времени, с использованием репликации).

Балансировщики нагрузки и DDoS-защита

Операторы используют геораспределённые балансировщики и фильтрацию трафика для защиты от DDoS-атак. Платформы обмена ЦФА подключаются к услугам анти-DDoS-провайдеров. Сеть CDN (Content Delivery Network) используется для статических ресурсов (документация, интерфейс).

Тестирование отказоустойчивости

Оператор обязан проводить регулярные тесты:

• Chaos engineering — намеренное отключение компонентов для проверки реакции системы.
• Фолловер-тесты — переключение на резервный дата-центр.
• Восстановление из бэкапа — проверка полноты и скорости восстановления.

Результаты тестов документируются и предоставляются ЦБ при надзорных проверках.

Практические инциденты

За время существования рынка ЦФА (с 2021 года) зафиксированы инциденты разного масштаба:

• Кратковременные сбои при аномальной нагрузке на платформы обмена (во время размещения популярных выпусков ЦФА на металлы).
• Задержки в проведении сделок из-за проблем с сетевой связью между нодами.
• Ошибки в смарт-контрактах, потребовавшие экстренного обновления (не влияли на реестр прав, но блокировали новые выпуски).
• Отказы при массовой идентификации клиентов через ЕСИА (Госуслуги).

Ни один из инцидентов не привёл к утрате данных реестра, что подтверждает работоспособность архитектурных решений. Открытость операторов в описании инцидентов — косвенный признак зрелости процессов: публичные разборы аварий означают, что DRP реально тестируется, а не остаётся формальным документом.

Что делать инвестору во время сбоя

1. Не повторять заявку на сделку многократно — после восстановления возникает риск дублей.
2. Зафиксировать время начала сбоя и скриншоты с текстами ошибок.
3. Проверить официальные каналы оператора: телеграм-канал, раздел статуса системы.
4. Не вводить учётные данные на сторонних сайтах-«зеркалах» — на фоне сбоя активизируются фишеры.
5. Если сбой сорвал срок обязательной операции (например, оплату по графику), сохранить переписку с поддержкой — она пригодится для претензии.

Алгоритм действий при инцидентах разного типа — в инструкции о том, что делать инвестору при технических проблемах на платформе.

Как устойчивость платформы связана с сохранностью активов

Запись о праве на ЦФА существует в реестре информационной системы, поэтому физическая целостность данных — это и есть сохранность актива. Пока реестр цел, актив цел: даже при длительном простое владелец не теряет токены, а лишь ждёт возобновления операций. Иная ситуация возникает при банкротстве или отзыве лицензии у оператора — здесь вопросы переходят из технической плоскости в юридическую. Что происходит с записями и деньгами в таком сценарии, описано в материале о банкротстве платформы ЦФА и судьбе активов инвесторов.

Общая система защиты записей — криптография, электронные подписи, контроль доступа — описана в обзоре безопасности ЦФА.

Источники

• Федеральный закон № 259-ФЗ — «О цифровых финансовых активах, цифровой валюте и о внесении изменений в отдельные законодательные акты Российской Федерации»
• Федеральный закон № 187-ФЗ — о безопасности критической информационной инфраструктуры
• Информация ЦБ РФ — требования к операторам информационных систем

Материал носит справочный характер и не является индивидуальной инвестиционной рекомендацией.