Раздел C — Сегменты применения (C.1-C.4)

Раздел C — Сегменты применения#

C.0. Введение#

Настоящий раздел определяет применимость требований Раздела B (8 доменов) к каждому из 4 сегментов рынка криптоактивов. Применимость отражена матрицей M / R / N/A (обязательно / рекомендуется / не применимо) в каждом разделе домена B (см. блок «Сводная таблица применимости» в конце B.1 — B.8) и сведена в настоящем разделе.

Сегменты:

• C.1 — Кастодиальные кошельки и кастодианы
• C.2 — Некастодиальные кошельки (программное обеспечение поставщика кошелька)
• C.3 — Криптобиржи (CEX и DEX-фронтенды)
• C.4 — Эмитенты стейблкоинов, RWA-токенов и фиатных токенов

C.1. Кастодиальные кошельки и кастодианы#

C.1.1. Определение сегмента#

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

• Централизованные кошельки бирж (кастодиальная часть)
• Специализированные кастодианы (Coinbase Custody, Anchorage, BitGo, Fireblocks Vault и аналоги)
• Банковские крипто-кошельки в рамках операторов ЦФА
• Кастодиальные услуги под чужим брендом

C.1.2. Применимость доменов CCSA для C.1#

Все 8 доменов обязательны для C.1. Это самый строгий сегмент применения.

C.1.3. Конкретные требования по уровням для C.1#

---

C.2. Некастодиальные кошельки#

C.2.1. Определение сегмента#

ПО или устройства, обеспечивающие пользователю самостоятельный контроль над приватными ключами:

• Кошельки — расширения браузера (MetaMask, Rabby и аналоги)
• Мобильные кошельки (Trust Wallet, Phantom и аналоги)
• Кошельки для компьютеров (Electrum, Sparrow и аналоги)
• Аппаратные кошельки (Ledger, Trezor, Tangem и аналоги)
• Смарт-кошельки / кошельки с абстракцией учётной записи

Субъект сертификации в C.2: поставщик программного обеспечения или производитель аппаратного кошелька. Конечный пользователь сертификации не подлежит и не является субъектом аудита.

C.2.2. Две области применения C.2#

Для C.2 требования стандарта применяются в двух разных контекстах:

• Область поставщика — требования к организации-разработчику кошелька: её сотрудникам, процессам и инфраструктуре. Включает предоставление и отзыв доступа, разделение обязанностей, проверку персонала, безопасность инфраструктуры сборки и управление выпусками.
• Область устройства — требования к архитектуре ПО кошелька на устройстве конечного пользователя: энтропия на устройстве, защищённое хранение в Secure Enclave / StrongBox, процедура подписания в доверенной среде и интерфейс восстановления.

Ни одна из этих областей не применяется к самому конечному пользователю. Пользователь самостоятельно принимает решения о своих CCM, например о частоте смены мнемонической фразы и использовании мультиподписи; поставщик обязан предоставить механизмы и документацию, но не навязывать пользователю правила.

C.2.3. Применимость доменов CCSA для C.2#

C.2.4. Уникальные требования для C.2#

Безопасность кода:

• Открытый исходный код предпочтителен для проверки сообществом и анализа кода
• Воспроизводимые сборки для выпусков в App Store / Play Store
• Подписание кода с подтверждённой идентификацией разработчика
• Обфускация закрытых частей кода (если применимо)

Защита от извлечения:

• Меры защиты от несанкционированного изменения
• Защита от снимков экрана при отображении мнемонической фразы
• Обнаружение jailbreak / root с ограничением функциональности мобильного приложения
• Меры против отладки

Обучение пользователей защите CCM:

• Предупреждения в приложении о безопасности мнемонической фразы
• Меры против фишинга (моделирование транзакций, адресная книга с проверенными контактами)
• Руководство по восстановлению, доступное без подключения к интернету

C.2.5. Конкретные требования по уровням для C.2#

---

C.3. Криптобиржи (CEX и DEX-фронтенды)#

C.3.1. Определение сегмента#

Торговые платформы для криптоактивов в части защиты CCM их custody-инфраструктуры:

• Централизованные биржи (CEX) — кастодиальная часть
• DEX-фронтенды — управление ключами подписи административных функций
• OTC платформы — горячее, тёплое и холодное кастодиальное хранение

Замечание об области применения: сегмент C.3 охватывает только защиту CCM биржевой инфраструктуры. Целостность торгового движка, предотвращение рыночных манипуляций, безопасность книги заявок, стандарты листинга и справедливый доступ относятся к бизнес-процессам и целостности рынка и не входят в область CCSA (раздел 0.2.2).

C.3.2. Применимость доменов CCSA для C.3#

Все 8 доменов обязательны для C.3, как и для C.1.

C.3.3. Уникальные требования для C.3 в части CCM#

Пользовательские кошельки (кастодиальная часть):

• Токены сессий защищаются как CCM категории D (раздел B.1.1)
• Обязательная двухфакторная аутентификация для подписания (раздел B.4.3)
• Дополнительная аутентификация для операций на крупные суммы (раздел B.4.3, уровень 2 и выше)

Внутренние операции:

• Временная блокировка вывода (раздел B.6.4)
• Список разрешённых адресов для институциональных счетов (раздел B.6.5)
• Мониторинг всех горячих и тёплых кошельков в режиме только для наблюдения в реальном времени (раздел B.7.3)

C.3.4. Конкретные требования по уровням для C.3#

---

C.4. Эмитенты стейблкоинов, RWA-токенов и фиатных токенов#

C.4.1. Определение сегмента#

Организации, выпускающие токены на блокчейне, в части защиты CCM их эмиссионной инфраструктуры:

• Стейблкоины (USDT, USDC, DAI и аналоги)
• RWA-токены (токены реальных активов)
• Фиатные токены (токены, обеспеченные валютой)
• Инвестиционные токены

Замечание об области применения: сегмент C.4 охватывает только защиту ключей эмиссии и сжигания и связанных CCM. Политика состава резервов, аудит и подтверждение резервов, процессы управления, раскрытие информации регулятору и права держателей токенов относятся к финансам, корпоративному управлению и соблюдению нормативных требований и не входят в область CCSA (раздел 0.2.2).

C.4.2. Применимость доменов CCSA для C.4#

C.4.3. Уникальные требования для C.4 в части CCM#

Защита ключей эмиссии и сжигания:

• Мультиподпись обязательна для эмиссии и сжигания (раздел B.6.1) независимо от рыночной капитализации
• Мониторинг всех событий эмиссии в режиме только для наблюдения (раздел B.6.2)
• Временная блокировка эмиссии выше порога (раздел B.6.4)
• Обнаружение компрометации при несанкционированной эмиссии (раздел B.7.3)

Что не покрывает CCSA для эмитентов:

• Политика состава резервов и проверенные резервы — отдельная область соответствия
• Права держателей токенов и процедуры погашения — корпоративное управление
• Аудит смарт-контракта эмиссии — безопасность кода, отдельная область
• Раскрытие информации регулятору — соблюдение нормативных требований

C.4.4. Конкретные требования по уровням для C.4#

---

C.5. Кросс-сегментные правила#

C.5.1. Организации с несколькими сегментами#

Если организация работает в нескольких сегментах одновременно (например, биржа + кастодиан + эмитент), применяются требования всех применимых сегментов:

• Соблюдаются все обязательные требования в совокупности
• Требования к общей инфраструктуре проверяются один раз
• Единый ROC с разделением по сегментам

C.5.2. Сегменты подразделений#

Если различные подразделения одной организации работают в разных сегментах, возможна сертификация по сегментам:

• Каждое подразделение может иметь свой уровень и AOC
• Требования к общей инфраструктуре CCM проверяются один раз
• Отдельная отчётность по каждому сегменту

Правило определения общего уровня организации. Если организация сертифицируется как единое целое, а не по сегментам, и разные сегменты дают разные уровни (например, C.1 — L2 по AUM, C.3 — L3 по дневному объёму), общий уровень организации равен максимальному из уровней сегментов. Это применяется и к разным показателям одного сегмента (AUM и объём транзакций): выбирается самый строгий уровень. При сертификации по сегментам каждое подразделение оформляется отдельно со своим уровнем.

C.5.3. Зачёт при наличии нескольких сегментов#

При наличии сертификатов по базовым стандартам (раздел A) зачёт применяется к каждому требованию, а не к сегменту. Один и тот же базовый стандарт (например, PCI DSS Level 1) может одновременно покрывать общие инфраструктурные требования B.4.4 о привилегированном доступе и B.7.1 о журналировании для всех сегментов организации.

C.5.4. Критические требования при наличии нескольких сегментов#

Для всех восьми критических требований (B.1.1, B.1.2, B.2.1, B.3.1, B.4.1, B.5.2, B.7.3, B.8.1 — раздел D.2.5) зачёт не применяется ни в одном сегменте (раздел A.0.3). Организация с несколькими сегментами должна пройти полную проверку CCSA по процедурам стандартного подхода для каждого сегмента в области оценки. Индивидуальный подход к критическим требованиям запрещён (раздел 0.7.2); компенсирующие меры для четырёх требований (B.1.1, B.1.2, B.5.2, B.7.3) запрещены полностью (раздел 0.8.2), а для остальных четырёх (B.2.1, B.3.1, B.4.1, B.8.1) допустимы только на уровне 1 с одобрения Совета (раздел 0.8.3).

Связанные#

• B.8 — Персонал и контроль доступа — предыдущий раздел B
• 12 — Раздел D — Уровни сертификации — следующий раздел

Источники#

См. нормативные ссылки в разделе 0.4 вводной части.