Nvidia расследует инцидент на облачной платформе Brev, где с 4 по 20 октября фиксировалась несанкционированная активность. Утечка SSH-ключей, созданных Brev для доступа к клиентским виртуальным машинам, потенциально давала злоумышленникам путь к инфраструктуре пользователей; для команд, которые держат в облаке ML-окружения и секреты, это повод проверить доступы, а не ждать итогового пресс-релиза.
Компания уведомила затронутых клиентов, что данные из сети Brev могли попасть посторонним лицам. Среди них — SSH-ключ, настроенный сервисом. Nvidia уже отозвала и заменила затронутые ключи, а также обновила клиентские инстансы новыми. При этом компания заявила, что не нашла подтверждений неправомерного использования ключей. Об инциденте сообщает Tom's Hardware.
Формулировка Nvidia оставляет слишком много важных пробелов. Компания не раскрыла, каким способом атакующие проникли на платформу, пытались ли они применять полученную информацию и были ли доступны данные клиентов либо их рабочие нагрузки. Отсутствие доказательств злоупотребления — хорошая новость, но не равнозначно доказательству, что его не было: расследование могло не иметь полного набора журналов, а доступ через ключ мог быть коротким и точечным.
SSH-ключ в такой схеме — не пароль от личного кабинета, который можно быстро сменить и забыть. Это криптографический способ аутентификации для подключения к удалённой машине: через него разработчики и администраторы запускают команды, обслуживают серверы и передают файлы. Если приватная часть ключа скомпрометирована и ключ всё ещё доверен виртуальной машиной, атакующий может подключиться от имени легитимного пользователя. Реальный масштаб ущерба зависит от прав ключа, сетевых ограничений, MFA для сопутствующих систем и того, какие секреты лежали на самой ВМ.
Ротация ключа закрывает дверь, но не отменяет проверку
Nvidia выполнила базовую и необходимую меру — ротацию. Однако для пользователей Brev этого недостаточно, если в период с 4 по 20 октября на инстансе уже успели закрепиться: добавить собственный ключ в authorized_keys, создать сервис, изменить задачу планировщика или скопировать токены из переменных окружения. Особенно неприятен этот сценарий для ML-разработки: на временной GPU-машине часто оказываются ключи от репозиториев, Docker Registry, облачных хранилищ, API-провайдеров моделей и продовых сервисов. Временной обычно бывает только машина, а не ценность лежащих на ней учётных данных.
Практический минимум для затронутых команд — изолировать инстансы, работавшие в окно инцидента, и проверить историю SSH-входов, список доверенных ключей, пользователей, процессы автозапуска, задачи cron и systemd-сервисы. Затем стоит отозвать и перевыпустить все секреты, к которым машина имела доступ: облачные ключи, токены CI/CD, Git-ключи, API-ключи провайдеров ИИ и активные сессии. Такой порядок действий рекомендовал и аналитик threat intelligence в RH-ISAC Брэдфорд Реджески, говоря о похожих инцидентах с компрометацией SSH-доступа. Проверять нужно не только сам ключ Brev: если атакующий успел забрать токен из окружения, замена SSH-ключа уже не решает главную проблему.
AI-платформы становятся удобной целью для охоты за секретами
Случай Brev укладывается в неприятную картину октября для сервисов разработки ИИ. Исследователи Wiz в обзоре «Black October» перечислили как минимум девять платформ, затронутых инцидентами за месяц, включая Zeabur, Fireworks AI, Lightning AI, Opencode, Warp и Northflank. Общий мотив публично описанных атак — поиск сохранённых переменных окружения, прежде всего тех, что открывают доступ к AI-сервисам. Это логично с точки зрения атакующего: один найденный токен может дать и вычислительные ресурсы, и возможность выставить владельцу счёт.
Wiz привела два примера с скомпрометированными учётными данными Amazon Bedrock: в одном случае через них сделали около 800 тысяч API-вызовов за 30 часов, в другом — примерно 1,7 млн вызовов за 13 часов. Совокупная стоимость такого использования по прайс-листу оценивалась примерно в 100 тысяч долларов. Эти эпизоды не доказывают, что нечто подобное произошло в Brev, но хорошо показывают, почему утечка SSH-ключей на платформе для разработки — риск не только для одной виртуальной машины. За доступом к ней могут стоять данные, вычисления, репозитории и платёжные аккаунты.
Для бизнеса вывод довольно приземлённый: облачную среду разработки нельзя считать безопасной лишь потому, что инстанс короткоживущий и нужен «только для эксперимента». Секреты стоит выдавать с минимальными правами и ограниченным сроком жизни, доступ к ВМ — сегментировать, а логи аутентификации и сетевой активности — выводить за пределы самого инстанса. Если Brev использовался в компании в указанный период, утечка SSH-ключей должна быть обработана как потенциальная компрометация хоста, даже при отсутствии публично подтверждённого ущерба.
Главный открытый вопрос — как именно атакующие получили доступ к Brev и насколько полными оказались журналы расследования Nvidia. Пока компания не ответит на него и не уточнит, затрагивались ли пользовательские данные или нагрузки, клиентам остаётся действовать по консервативному сценарию: считать доверие к инстансам в окне инцидента нарушенным и искать следы уже после ротации ключей.
