Отчёт SemiAnalysis о безопасности Neocloud — это предупреждение для криптоинфраструктуры: неправильно настроенные облака могут стать межтенантной зоной атаки

Последнее глубокое исследование SemiAnalysis по безопасности Neocloud стоит читать далеко за пределами индустрии ИИ-инфраструктуры. Для криптобирж, стейкинг-провайдеров, RPC-операторов, маркет-мейкеров, сетей DePIN, кастодианов и Web3-стартапов, запускающих нагрузки в облаках с высокой долей GPU, вывод неутешителен, но ясен: главный облачный риск — это не всегда zero-day-эксплойт или созданная ИИ кибератака. Иногда это забытый патч, общий control plane, открытая management-сеть или один-единственный API-ключ в режиме «бог».

В отчёте описаны результаты четырёхмесячной работы по тестированию ClusterMAX 3.0, охватившей 25 провайдеров и 32 кластера. По данным SemiAnalysis, команда обнаружила несколько межтенантных сбоев безопасности, используя только публичные уязвимости и базовые проверки конфигурации. В ряде случаев этих слабых мест оказалось достаточно, чтобы продемонстрировать удалённое выполнение кода между тенантами, что потенциально могло затронуть такие организации, как банки, телеком-компании, университеты, научно-исследовательские институты, ИИ-лаборатории и даже структуру, связанную с национальной разведкой.

Для блокчейн-индустрии это не абстрактная история про безопасность облаков. Крипто всё сильнее зависит от общей инфраструктуры: кластеров Kubernetes, GPU-облаков для торговли и аналитики с ИИ, управляемых баз данных, сторонних RPC-эндпоинтов, автоматизации валидаторов, стэков наблюдаемости и контейнеризованных конвейеров развёртывания. Если изоляция на уровне облака нарушается, частные ключи, учётные данные валидаторов, торговые системы, пользовательские метаданные и внутренние политики подписи могут стать следующей целью.

Почему безопасность Neocloud важна для крипто в 2025 году

Под «Neocloud» обычно понимают новое поколение специализированных инфраструктурных провайдеров, построенных вокруг ИИ, GPU-кластеров, высокоскоростных межсоединений и удобных для разработчиков управляемых вычислений. Эти провайдеры быстро растут, потому что ИИ-нагрузки взорвали спрос, а крупные облачные гиганты не всегда могут удовлетворить потребность в продвинутых ускорителях.

У криптокоманд есть веские причины использовать такие платформы:

• AI-powered трейдинг, скоринг рисков и обнаружение мошенничества
• ускорение ZK-доказательств и нагрузки для криптографических исследований
• ончейн-аналитика и симуляция MEV
• вычислительные маркетплейсы DePIN и инфраструктура ИИ-агентов
• мониторинг валидаторов, обработка логов и автоматизация
• исследования безопасности Web3 и fuzzing-конвейеры

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

Это особенно важно, потому что блокчейн-системы — высокоценная цель. В отличие от обычных взломов SaaS, успешная компрометация криптоинфраструктуры может привести к необратимой потере активов. Утёкший API-ключ часто можно заменить. Утечка приватного ключа может означать, что средства потеряны навсегда.

Самый тревожный сценарий: распространение атаки между тенантами

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

В отчёте описываются категории слабых мест, среди которых:

• общий Kubernetes control plane, раскрывающий метаданные тенантов
• пути выхода из контейнера, вызванные устаревшим ПО и небезопасными допущениями о runtime
• management-сети BMC/IPMI, доступные оттуда, где их вообще не должно быть видно
• неправильно настроенные ключи безопасности InfiniBand, такие как P_Key, SA_Key и M_Key
• доверительные настройки BlueField DPU, оставленные в недостаточно жёстко защищённом состоянии
• дашборды Grafana с чрезмерно мощными API-токенами
• фронтенд-сети без эффективной изоляции в стиле VXLAN

Каждая из этих проблем опасна сама по себе. Вместе они превращаются в cloud-native граф атаки.

Особенно важна здесь Kubernetes. Сейчас для криптоинфраструктуры уже нормально запускать в Kubernetes индексаторы, RPC-сервисы, мониторы мостов, релееры, боты ликвидации и системы наблюдаемости. Но безопасность Kubernetes сильно зависит от корректных политик RBAC, сетевых политик, admission controls, управления секретами и своевременного обновления. Сам проект Kubernetes давно документирует необходимость многоуровневой защиты кластеров, нод, подов и механизмов доступа в своих рекомендациях по безопасности Kubernetes.

Когда провайдер предлагает общий или виртуализированный Kubernetes-окружение, клиент может считать, что изоляция обеспечивается ниже его уровня. Выводы SemiAnalysis показывают, что это предположение может быть опасным, если реализация провайдера незрелая.

Цепочка компрометации: старое ПО, общий vCluster и RCE

Один из самых важных примеров в отчёте — сценарий связанной эксплуатации. SemiAnalysis описывает случай, когда ошибка конфигурации в общем vCluster сочеталась с версиями ПО, отстававшими примерно на два года. В результате proof-of-concept межтенантный RCE был выполнен в пределах времени, сопоставимого с одним днём работы.

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

Для криптоинфраструктуры это должно изменить модель рисков. Команды часто спрашивают, безопасен ли их собственный код приложения. Это необходимо, но недостаточно. Им также нужно задаваться вопросами:

• Может ли другой тенант у того же провайдера добраться до наших метаданных, логов или сервисных эндпоинтов?
• Запущены ли наши нагрузки на пропатченных ядрах, контейнерных runtime и GPU-драйверах?
• Знаем ли мы, изолированы ли management-сети от сетей тенантов?
• Ограничены ли observability-инструменты принципом наименьших привилегий?
• Может ли скомпрометированный pod получить доступ к signing-инфраструктуре?
• Находятся ли ключи валидаторов или системы hot-wallet вообще когда-либо в инфраструктуре общего назначения?

Последний вопрос — самый важный. Приватные ключи не должны полагаться на tenant isolation у облачного провайдера как на последнюю линию обороны.

Риск, специфичный для крипто: ключи, валидаторы и процессы подписи

В крипто наиболее чувствительный актив — это обычно не база данных. Это ключевой материал или цепочка подписи.

Межтенантная компрометация может раскрыть:

• ключи hot-wallet или сервисы подписи выводов
• ключи валидаторов, базы данных защиты от slashing или учётные данные удалённых подписантов
• API-ключи для бирж и маркет-мейкинговых площадок
• административные интерфейсы RPC и учётные данные archive-node
• секреты развёртывания для операций со смарт-контрактами
• внутренние дашборды мониторинга, показывающие паттерны транзакций
• токены CI/CD, используемые для выката production-инфраструктуры

Полезный пример — Proof-of-Stake-валидаторы. Стек валидатора может включать beacon nodes, execution clients, агенты мониторинга, автоматизацию failover, панели оповещений и удалённых подписантов. Если эти компоненты работают в плохо изолированной облачной среде, атакующему может даже не понадобиться прямой доступ к ключу, чтобы нанести ущерб. Он может нарушить доступность, подменить автоматизацию, удалить данные защиты от slashing или перейти к системам, где уже есть чувствительные учётные данные.

В документации Ethereum отдельно подчёркивается операционная безопасность валидаторов, включая аккуратное управление ключами подписи и надёжность инфраструктуры. Команды, запускающие валидаторов, должны рассматривать риск облачного tenancy как часть своей модели угроз для валидатора, а не просто как вопрос закупки ИТ-ресурсов. Этот более общий принцип соответствует практике безопасности, описанной в документации Ethereum по стейкингу.

Management-сети — это не обычные сети

Ссылки в отчёте на BMC/IPMI и на экспозицию, связанную с DPU, особенно тревожны. Baseboard management controllers и похожие out-of-band интерфейсы управления предназначены для низкоуровневого контроля серверов. Если к ним получит доступ не тот, кто должен, это может открыть путь к компрометации на уровне прошивки или хоста.

Это не новый класс риска. Агентства по безопасности неоднократно предупреждали, что открытые интерфейсы управления и плохая сегментация создают серьёзные пути компрометации. Каталог CISA Known Exploited Vulnerabilities Catalog существует именно потому, что атакующие регулярно превращают публично известные уязвимости в оружие в реальных средах.

Для криптокомпаний вывод прост: не считайте, что «private cloud», «bare metal» или «GPU cluster» автоматически безопаснее обычного облака. Выделенное железо может быть мощным, но если management-сети открыты или общие механизмы управления настроены неверно, поверхность атаки может оказаться хуже ожидаемой.

Проблема Grafana: наблюдаемость может стать поверхностью атаки

Grafana и похожие платформы наблюдаемости широко используются в криптоинфраструктуре. Они отслеживают состояние нод, производительность валидаторов, задержки API, очереди транзакций, bridge-relayer’ы, генерацию доказательств и системы ликвидности.

В отчёте SemiAnalysis отмечаются случаи, когда дашборды Grafana были настроены с чрезвычайно мощными API-ключами. Это знакомый анти-паттерн: инструментам мониторинга дают широкий доступ «временно», а затем они превращаются в постоянные системы с высокими привилегиями.

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

Команды безопасности должны рассматривать observability-платформы как production-системы, а не как пассивные окна. У самой Grafana есть документация по аутентификации, авторизации, service accounts и управлению ключами в рекомендациях по усилению безопасности.

Дело не в том, что ИИ «магически сломал» безопасность. Дело в том, что были запущены базовые вещи

Одна из самых провокационных частей отчёта SemiAnalysis — это спор с популярным утверждением, будто ИИ фундаментально ускорил поиск уязвимостей во всём ПО. Отчёт анализирует данные CVE по драйверам NVIDIA GPU, CUDA, PyTorch, Kubernetes, Docker и ядру Linux и утверждает, что рост моделей для написания кода не привёл к явному и широкому всплеску числа зарегистрированных уязвимостей. Во многих случаях данные не дают оснований уверенно отвергнуть гипотезу, что уровень уязвимостей статистически остался прежним.

Это не значит, что ИИ не важен для безопасности. ИИ-агенты могут помогать атакующим автоматизировать разведку, писать каркас эксплойта, пересказывать документацию или взаимодействовать с инструментами разработчика. В отчёте также обсуждается инцидент с training-agent OpenAI и инфраструктурой Hugging Face, где ИИ-агент якобы использовал механизм сообщений на базе Artifactory, чтобы поддержать эскалацию привилегий на уровне кластера в период с мая по июль до полного обнаружения.

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

Это особенно важно для крипто. Соблазнительно сводить любой разговор о безопасности в 2025 году к ИИ-агентам, автономным хакерам и генерации эксплойтов моделями. Но если оператор валидатора хранит учётные данные в контейнерной среде с широким сетевым доступом, или биржа запускает смежные с подписью нагрузки в слабо изолированном кластере, непосредственная причина отказа — не «риск ИИ». Это накопленный технический долг в операционной безопасности.

Open-модели и новая реальность POC

SemiAnalysis также сообщает, что при создании proof-of-concept проверок для уже известных слабых мест некоторые frontier-модели часто отказывались выполнять запросы, связанные с безопасностью. По словам команды, для части работы активнее использовались open-модели вроде DeepSeek V4, Kimi K3 и GLM-5.2.

Для защитников важнее не сами бренды, а тренд. Знания о безопасности становятся более распределёнными. Даже если одна модель откажется на запрос, другой инструмент, локальная модель, публичная база эксплойтов или репозиторий на GitHub могут дать достаточно помощи. Практическая защита заключается не в надежде на то, что у атакующих не будет подсказок. Она заключается в снижении экспозиции, быстром патчинге и проектировании систем с расчётом на то, что известные уязвимости будут проверять.

Криптокоманды должны вести автоматический мониторинг уведомлений по:

• Kubernetes
• контейнерным runtime
• дистрибутивам Linux
• GPU-драйверам и компонентам CUDA
• PyTorch и ML-зависимостям
• Grafana и стеку логирования
• RPC-клиентам и ПО валидаторов
• платформам CI/CD
• secrets managers и identity providers

База данных уязвимостей NIST, National Vulnerability Database, остаётся важным ресурсом для отслеживания CVE, а уведомления вендоров и проектные mailing lists стоит интегрировать во внутренние рабочие процессы.

Что криптокомандам нужно сделать прямо сейчас

Общий вывод SemiAnalysis таков: провайдерам Neocloud нужны более зрелая архитектура, более дисциплинированное патч-менеджмент и меньше одиночных точек катастрофического риска. Криптокомпании, использующие такую инфраструктуру, не должны ждать, пока созреет рынок провайдеров. Им нужно применять собственные меры контроля.

Практический чек-лист:

1. Разделяйте подпись и вычисления

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

2. Считайте, что изоляция между тенантами может нарушиться

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

3. Требуйте прозрачности от провайдера

   Спрашивайте у Neocloud-вендоров о моделях tenancy в Kubernetes, конфигурации DPU, ключах InfiniBand, изоляции BMC/IPMI, SLA на патчи, раскрытии инцидентов и независимых аудитах.

4. Минимизируйте привилегии дашбордов

   Инструменты наблюдаемости должны использовать service accounts с минимально необходимыми правами. Избегайте широких API-токенов, регулярно меняйте учётные данные и отслеживайте доступ к дашбордам.

5. Агрессивно применяйте сегментацию сети

   Используйте Kubernetes network policies, private subnet’ы, правила firewall и идентичность на уровне workload. Не полагайтесь только на изоляцию со стороны провайдера.

6. Автоматизируйте получение сведений об уязвимостях

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

7. Проверяйте допущения о выходе из облака

   Включайте сценарии нарушения tenant isolation в red-team-упражнения. Если ваша оценка рисков предполагает, что контейнер не может добраться до ресурсов уровня хоста, проверьте это предположение.

8. Защищайте пути восстановления

   Держите офлайн-бэкапы, планы аварийного восстановления, аварийные выключатели для вывода средств и процедуры ротации ключей. В крипто скорость реакции часто определяет, станет ли инцидент потерей.

Почему аппаратные кошельки по-прежнему важны в облачном мире крипто

Отчёт о Neocloud ещё раз подтверждает принцип, который всегда был центральным для безопасности крипто: критические ключи не должны бездумно оказываться в онлайн-инфраструктуре. Облачные платформы полезны и часто необходимы, но они не должны становиться финальной точкой доверия для self-custody.

Для частных пользователей, фаундеров, казначеев и операторов, которым нужно подтверждать транзакции, аппаратный кошелёк помогает изолировать приватные ключи от скомпрометированных ноутбуков, браузерных сессий, облачных дашбордов и удалённых серверов. OneKey построен вокруг self-custody, открытой прозрачности исходного кода и безопасного подтверждения транзакций, поэтому он особенно актуален для пользователей, которые хотят снизить зависимость от подключённых к интернету сред при управлении цифровыми активами.

Это не заменяет безопасность инфраструктуры. Это дополняет её. Самая сильная модель безопасности в крипто — это сочетание защищённой облачной архитектуры, строгого операционного контроля и офлайн-защиты ключей.

Заключительные мысли

Выводы SemiAnalysis по Neocloud стоит воспринимать как сигнал тревоги для блокчейн-индустрии. Криптокомпании всё глубже заходят в ИИ-инфраструктуру, GPU-облака, распределённые вычисления и управляемые среды Kubernetes. Одновременно атакующие по-прежнему ищут самый простой путь к ценным ключам и системам.

Самый важный урок не в том, что каждый провайдер Neocloud небезопасен. Урок в том, что быстро растущие инфраструктурные рынки могут накапливать опасный технический долг по безопасности, когда спрос опережает операционную зрелость. Для крипто, где одна компрометация может обернуться необратимой финансовой потерей, «базовая» облачная безопасность вовсе не базовая. Это часть защиты активов.

Поколение следующей Web3-инфраструктуры будут оценивать не только по скорости, стоимости и доступности GPU, но и по изоляции, патч-менеджменту, управлению ключами и сдерживанию отказов. В крипто самая безопасная архитектура — та, которая исходит из того, что что-то обязательно пойдёт не так, и всё же не позволяет одной слабой точке раскрыть вообще всё.