AI-шлюзы становятся новой поверхностью атаки в облаке

Вопрос, который каждый руководитель платформы, использующей генеративный AI, должен задать своему вице-президенту по инженерии на этой неделе, — не в том, уместен ли LiteLLM в продакшене, а в том, кто владеет IAM-ролью, привязанной к нему, и кто санкционировал его сетевую доступность. Один скомпрометированный экземпляр прокси может сжечь облачный бюджет на чужом кошельке Monero и, что хуже, открыть атакующим путь в Bedrock. Это больше не проблема исследовательской лаборатории — это вопрос для ревью архитектуры в третьем квартале.

Раскрытие информации Darktrace о взломанном AWS EC2-инстансе под управлением LiteLLM — небольшой инцидент с масштабным посланием: промежуточный слой, который команды поспешно запустили в продакшен между своими приложениями и фундаментальными моделями, теперь является полноценной поверхностью атаки. Большинство директоров по информационной безопасности не заложили на это бюджет. Большинство платформенных команд не могут сказать, кто его патчит.

Ключевые детали

12 июня 2026 года, как сообщил CyberSecurityNews, Darktrace обнаружил активный криптомайнинг, исходящий от AWS EC2-инстанса с именем «LiteLLM-Proxy». Хост работал как AI-шлюз, подключённый к Amazon Bedrock через IAM-роль, и занимал именно ту позицию, где AI-шлюзы обычно и находятся: между пользователями, бизнес-приложениями и большими языковыми моделями — управляя аутентификацией, маршрутизацией моделей, логированием, политиками и доступом к фундаментальным моделям.

Первоначальный вектор проникновения был банальным. SSH был открыт на инстансе и принимал входящий трафик с любого IP-адреса. Darktrace зафиксировал большое количество кратковременных попыток SSH-соединения, включая трафик с адреса 145.241.123[.]102. Следователи не смогли подтвердить успешный вход, однако открытый сервис и паттерн брутфорса сделали SSH наиболее вероятной точкой входа.

Поведение после компрометации следовало стандартному сценарию криптоджекинга. Инстанс загрузил полезную нагрузку по незашифрованному HTTP с адреса 185.62.1[.]8 — ZIP-архив, содержащий XMRig, широко используемый опенсорсный майнер Monero. Затем он открыл повторяющиеся HTTPS-сессии к pool.hasvault[.]pro — известному пулу криптомайнинга. Оборачивание трафика пула в TLS на стандартных портах делало потоки неприметными в изоляции, однако назначение и ритмичность активировали поведенческое обнаружение. Активность чётко соответствует MITRE ATT&CK T1496 — захват ресурсов.

На следующий день, 13 июня, IAM-пользователь в том же аккаунте аутентифицировался через AWS CLI с вьетнамского IP-адреса, который Darktrace отметил как нетипичный для данного аккаунта. Сессия предпринимала попытки вызовов GetSendQuota, ListFoundationModels, InvokeModel и CreateUser. Вызовы Bedrock (ListFoundationModels, InvokeModel) завершились ошибкой. Darktrace не смог однозначно связать IAM-активность со скомпрометированным шлюзом, однако последовательность — разведка моделей, попытки вызова и CreateUser с привкусом закрепления — это именно то, чего следует ожидать от атакующего, проверяющего, что украденные учётные данные AI-шлюза могут открыть.

Почему это важно для команд безопасности

Криптомайнинг — это шум, а не сигнал. Сигнал — это то, до чего может дотянуться IAM-роль AI-шлюза.

Подумайте о профиле доверия этих компонентов. AI-шлюз хранит долговременные облачные учётные данные с разрешениями на вызов фундаментальных моделей, чтение промптов и ответов в транзите, пересылку контекста из внутренних приложений и нередко запись логов в S3 или CloudWatch. Его компрометация обходится вам не только вычислительными циклами. Она потенциально раскрывает каждый промпт, который ваши продуктовые команды отправляют в Bedrock (что для регулируемого fintech, iGaming или healthtech означает персональные данные, данные сессий и бизнес-логику), каждый приходящий ответ и IAM-поверхность, пришитую к роли. Атакующий, попытавшийся вызвать InvokeModel, понимал это. Он пришёл не за Monero — он пришёл за доступом к модели. Майнинг был монетизацией начального уровня, пока он разбирался с потенциальной выгодой.

Это переосмысливает экономику инцидента. Один среднеразмерный EC2-инстанс под XMRig может стоить несколько сотен долларов в месяц впустую. Утечка пути вызова Bedrock или, что хуже, украденный корпус промптов с данными клиентов — это уже разговор с главным юрисконсультом и финансовым директором. Именно здесь я призываю каждого руководителя по безопасности: перестаньте оценивать такие инциденты по счёту за майнинг и начните оценивать их по радиусу поражения IAM-роли, привязанной к машине.

Тактические провалы негламурны. SSH, открытый для 0.0.0.0/0 в 2026 году на компоненте, который стоит перед доступом к фундаментальным моделям, — это сбой конфигурации, который не прошёл бы нормального платформенного ревью. Долговременные учётные данные в IAM-роли с бо́льшими разрешениями Bedrock, чем реально нужно рабочей нагрузке, — это сбой принципа минимальных привилегий. Загрузка полезных нагрузок по HTTP с произвольного IP — это сбой контроля исходящего трафика. Каждый из них по отдельности можно пережить. В сочетании на компоненте, который управляет вашим AI-трафиком, — это анонс следующей волны отчётов об облачных взломах.

Влияние на отрасль

Дискуссия «создать или купить» вокруг AI-шлюзов теперь является разговором о безопасности, а не только о задержке и стоимости. За последние восемнадцать месяцев инженерные команды в fintech и iGaming тянулись к LiteLLM, опенсорсным прокси и самодельным слоям маршрутизации, потому что коммерческие предложения AI-шлюзов от облачных провайдеров и стартапов либо не существовали, стоили слишком много за токен, либо не обеспечивали нужного охвата моделей. В то время это было рационально. На следующем аудите это будет выглядеть менее рационально.

Вот где важна организационная структура. Кто владеет AI-шлюзом внутри вашей компании? В большинстве fintech-компаний серии B, которые я вижу, ответ — «команда ML-платформы» или «тот старший инженер, который его поднял». Эта команда — не та, что защищает ваш продакшен Kubernetes, мониторит исходящий трафик или проверяет IAM-политики. Они оптимизируют скорость разработки и охват моделей. Положение дел с безопасностью — побочная задача. Когда шлюз становится единственной точкой перехвата AI-трафика, этот пробел в ответственности и становится уязвимостью.

Регулируемые отрасли чувствуют это острее. Оператор iGaming, использующий Bedrock для суммаризации обращений игроков в поддержку, передаёт персонально идентифицируемые промпты через этот шлюз. Fintech-компания, выполняющая дополнение KYC, отправляет извлечённые данные документов. Если шлюз скомпрометирован и IAM-роль разрешает запись логов в общий бакет, канал эксфильтрации выстраивается сам собой. Регуляторы в Великобритании, на Мальте и в ЕС не примут ответ «мы думали, что LiteLLM — просто роутер» в ходе проверки по Section 166 или DORA.

Влияние на рынок найма тоже реально. Инженеры по облачной безопасности, которые разбираются как в IAM, так и в паттернах AI-рабочих нагрузок, — крайне малочисленный кадровый резерв. Ожидайте, что компенсация за этот специфический гибридный набор навыков резко пойдёт вверх во второй половине 2026 года по мере выхода новых раскрытий.

За чем следить

Три сигнала для отслеживания в ближайшие 90 дней. Первый: выпустят ли AWS и другие гипермасштабщики собственные продукты AI-шлюзов с защищёнными настройками по умолчанию, или сделают ставку на расширение Bedrock IAM для ограничения возможностей скомпрометированного прокси (политики вызовов с ограниченной областью, ARN ресурсов по отдельным моделям, подпись запросов на уровне SDK). Второй: ответит ли опенсорсная экосистема AI-шлюзов (LiteLLM и его аналоги) релизами, ориентированными на безопасность, шаблонами развёртывания с чёткими рекомендациями и эталонными IAM-политиками. Третий: увидим ли мы первое подтверждённое раскрытие, при котором компрометация AI-шлюза приводит к эксфильтрации данных промптов или ответов, а не только к криптомайнингу. Этот третий сценарий — ещё не случившееся, и когда он произойдёт, это изменит то, как советы директоров думают о расходах на генеративный AI.

Руководитель платформы в любой компании, эксплуатирующей AI-шлюз в продакшене, должен на этой неделе спросить у своего руководителя по безопасности: какова точная IAM-политика, привязанная к этому прокси, каков список разрешённых исходящих соединений на инстансе и когда в последний раз ротировались долгосрочные ключи, спрятанные в его окружении. Если на эти три вопроса нет ответов в тот же день — у вас есть собственный LiteLLM-Proxy, ожидающий, когда его найдут.

Ключевые выводы

• Слой AI-шлюза (LiteLLM, кастомные прокси, роутеры моделей) теперь является самостоятельной поверхностью атаки с облачными учётными данными, которые стоят больше, чем вычислительные ресурсы, на которых он работает.
• Инцидент Darktrace начался с SSH, открытого в интернет, и закончился попытками вызова Bedrock InvokeModel с вьетнамского IP: криптомайнинг — это потеря-лидер, доступ к модели — это приз.
• Минимально привилегированный IAM на роли шлюза — единственный наиболее применяемый контроль. Ограничьте разрешения Bedrock конкретными ARN моделей и полностью исключите разрешения, смежные с CreateUser.
• Неопределённость ответственности между командами ML-платформы и облачной безопасности — вот где живут эти взломы. Исправьте организационную структуру прежде, чем исправлять конфигурацию.
• Регулируемые операторы fintech и iGaming должны считать промпты и ответы, проходящие через AI-шлюз, данными, входящими в область действия их режима соответствия, и соответственно проектировать контроль исходящего трафика.