Аудит криптосервиса начинают с определения его функций, юрисдикций и точек доступа к активам клиентов. Затем проверяющие сопоставляют документы с реальными процессами: регистрацией пользователей, движением средств, хранением ключей, обработкой инцидентов. Главный принцип прост: каждое заявленное правило должно подтверждаться записью, настройкой системы или ответственным сотрудником.
Как определить границы и цели аудита?
Сначала нужно зафиксировать, какие компании, продукты и операции войдут в периметр. Без этого проверка быстро расползается: команда изучает интерфейс обменника, но не замечает отдельного платёжного модуля или подрядчика, управляющего инфраструктурой.
Описание сервиса должно показывать путь клиента и активов от регистрации до вывода средств. Отдельно отмечают используемые блокчейны, фиатные расчёты, административные панели, мобильные приложения, API и внешние интеграции. Если часть операций выполняет контрагент, это не всегда снимает риск с владельца продукта.
Цель также формулируют заранее. Юридическая оценка отвечает на вопросы о применимых требованиях и договорах. AML-аудит изучает противодействие отмыванию денег и контроль транзакций. Техническая часть охватывает инфраструктуру, ключи, права доступа и устойчивость сервиса. Обычно эти направления пересекаются, но требуют разных доказательств.
Какие материалы подготовить для проверяющих?
Нужен единый реестр документов с владельцами, версиями и датами пересмотра. Передавать хаотичную папку файлов нежелательно: старый регламент может противоречить действующим настройкам, а проверяющий потратит время на выяснение актуальной версии.
- Схема юридических лиц, продуктов, юрисдикций и ответственных подразделений.
- Пользовательские условия, политика конфиденциальности и правила обработки обращений.
- Регламенты KYC — идентификации клиента — и AML-контроля, включая порядок эскалации случаев.
- Описание хранения криптоактивов, управления ключами и разграничения доступа.
- Журналы изменений, инцидентов, резервного копирования и восстановления.
- Договоры с критичными провайдерами и результаты их внутренней оценки.
Каждый документ полезно связать с доказательствами исполнения. Например, регламент блокировки подозрительной операции подкрепляют обезличенным примером решения, журналом действий и перечнем ролей. Конфиденциальные данные при этом передают через согласованный защищённый канал, а доступ ограничивают по необходимости.
Какие зоны риска проверять в первую очередь?
Приоритет получают процессы, где ошибка может привести к потере активов, несанкционированному доступу или пропуску рискованной операции. Глубина оценки зависит от модели сервиса: некастодиальная платформа и оператор, хранящий ключи клиентов, имеют разный профиль угроз.
| Зона | Что проверяют | Признак проблемы |
|---|---|---|
| Доступ | Роли, многофакторную аутентификацию, отзыв прав | Общие учётные записи или лишние привилегии |
| Ключи | Создание, хранение, резервирование и замену | Неописанная ответственность за операции |
| KYC и AML | Сценарии контроля, решения и журналирование | Правила существуют только в документах |
| Инциденты | Оповещение, локализацию и восстановление | Нет тренировок и назначенных владельцев |
| Подрядчики | Доступ к данным, инфраструктуре и активам | Договор не отражает фактические полномочия |
Особое внимание требуется административным операциям. Изменение адреса вывода, отключение защитного правила или выдача расширенной роли должны оставлять различимый след в журнале. Когда запись можно удалить теми же правами, что и создать, контроль становится слабым.
Как провести внутреннюю репетицию аудита?
До визита проверяющих полезно выбрать несколько операций и проследить их от начала до конца. Такая выборка показывает разрыв между инструкцией и практикой быстрее, чем чтение десятков политик.
Можно взять регистрацию клиента, изменение его уровня риска, ввод актива, ручную проверку транзакции и восстановление доступа. Для каждого случая команда собирает подтверждения: запись в системе, решение сотрудника, уведомление и временные отметки. Иногда уже на этом этапе обнаруживается, что названия ролей различаются в регламенте и панели управления.
Затем проводят короткие интервью с владельцами процессов. Сотрудник должен объяснить не только обычный сценарий, но и исключение: что произойдёт при недоступности провайдера, ошибке мониторинга или компрометации учётной записи. Ответ «это делает система» недостаточен, если неизвестны условия срабатывания и порядок ручного контроля.
Как оформить найденные недостатки?
Каждое замечание описывают через факт, риск, доказательство и корректирующее действие. Формулировка «усилить безопасность» бесполезна; понятная задача указывает конкретный доступ, требуемое изменение, владельца и способ повторной проверки.
Критичность лучше определять по возможному ущербу и вероятности сценария, а не по числу нарушенных внутренних пунктов. Сначала закрывают доступ к активам и данным, затем устраняют системные пробелы в контроле, после — редакционные расхождения в документах.
Хорошо подготовленный сервис не выглядит безупречным: у него видны ограничения, принятые решения и сроки исправлений. Самый убедительный результат — не гладкая папка политик, а цепочка проверяемых действий, где от нажатия кнопки до записи в журнале не остаётся тёмного участка.