Почему уязвимости безопасности LLM-платформ опаснее сложных атак?

Уязвимости безопасности LLM‑платформ и риски инфраструктурных ошибок: простые дыры ломают быстрее сложных атак

Один открытый Docker Remote API на порту 2375 — и платформа под контролем за минуты. Это результат аудита, а не теория. Такой кейс ломает ожидание, что главные угрозы — «умные» атаки на модели. На практике решают базовые ошибки: открытые сервисы, дефолтные секреты, ключи в открытом виде и отсутствие сегментации.

Когда админ‑панель, прокси и аналитика живут в одной сети, одна настройка рушит весь стек — от LangChain до GPU‑нод на RunPods. Сложные техники вроде SSRF‑цепочек или prompt injection могут не сработать, а открытый порт даёт ключи сразу. Вывод практический: сначала проверяйте сеть и секреты, потом — защиту моделей. Далее — где именно возникают такие дыры и как их находить.

Почему фокус на «умных» атаках сбивает с курса

Принято считать, что главный риск — атаки на сами модели: prompt injection, сложные SSRF и уязвимости пайплайна. Поэтому команды усиливают фильтры промптов и детекторы атак.

Аудит показал обратное. За 14 дней найдено 27 уязвимостей. Критическая — открытый Docker Remote API на порту 2375 без аутентификации. Один HTTP‑запрос дал доступ ко всем API‑ключам, причём за 5 минут. Попытки добыть ключи через сложные техники результата не дали. Дефолтный JWT‑секрет позволял подделать admin‑токен.

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

Как возникают быстрые компрометации

Как устроена платформа

LLM‑платформа — это сеть сервисов и секретов. Модель — по сути HTTP‑клиент с дорогими ключами. В продакшене рядом: LangChain, Flask‑сервисы, фронтенд на Next.js, контейнеры в Docker Swarm. Часто админ‑панель, прокси и аналитика в одной зоне. Одна ошибка даёт прямой канал ключам.

Причина и механизм

Открытый Docker API на 2375 без аутентификации — прямой вход. Один запрос — и видны контейнеры и смонтированные секреты. Доступ ключам получен за 5 минут. Дефолтный JWT даёт подделку admin‑токена и доступ к данным. При этом prompt injection, SSRF‑цепочки и HTTP smuggling не помогли. Цепочка проста: неверная конфигурация → доступ к секретам → контроль над LLM.

Практики, которые закрывают вектор

• Закрыть Docker API: отключить 2375, включить TLS и сокет unix (/var/run/docker.sock), доступ только через bastion/VPN и списки разрешённых IP.

• Секреты вне кода и БД: использовать хранилища секретов (например, HashiCorp Vault, AWS Secrets Manager), включить ротацию и короткий TTL.

• Сегментация сети: разнести админ‑панель, прокси и аналитику по разным подсетям и политикам, минимальные права по принципу least privilege.

• Egress‑фильтрация: разрешать исходящие соединения только к нужным адресам; блокировать произвольные хосты, чтобы SSRF не работал.

К чему это приводит

Если ключи лежат в базе в открытом виде, а DMARC стоит p=none, риски складываются: фишинг снаружи + дыра внутри = полный компромисс. В системе было >10 LLM‑нод и GPU‑нод на RunPods, значит масштаб утечки велик. Защита промптов здесь не помогает — атака идёт ключам.

Вывод

Без дисциплины в инфраструктуре защита LLM — косметика. Закрываете простые дыры — резко сокращаете реальный риск.

Типовые сценарии и как их закрыть

Открытый Docker «для удобства»

Контейнеры настроили быстро и дали доступ по внутреннему IP. Порт 2375 оказался доступен. Один HTTP‑запрос — и видны контейнеры и секреты. Итог: ключи получены за минуты, дальше — компрометация нод и платежей. Как предотвратить:

• закрыть 2375, включить TLS и доступ только через VPN;

• ограничить доступ списками IP и ролями.

Дефолтный секрет в продакшене

JWT‑секрет не сменили после теста. Токен подделали и получили админ‑доступ. Итог: контроль над кластером и данными, возможна подмена ответов. Как предотвратить:

• хранить секреты в Vault/Secrets Manager и ротировать;

• запретить дефолтные значения в CI, проверка на деплое.

Всё на одном хосте

Фронт, прокси и аналитика на одном сервере. Утечка в одном сервисе дала доступ к другим. Итог: доступ к >10 LLM‑нодам и GPU‑ресурсам, быстрый рост ущерба. Как предотвратить:

• сегментировать сеть и разнести сервисы по зонам;

• включить egress‑политики и минимальные права доступа.

Бизнес‑эффект: где теряются деньги и время

Инфраструктурные дыры сокращают атаку до прямого доступа ключам. Это значит быстрые и дорогие инциденты.

Что это даёт на практике:

• простой сервисов и простой команды из‑за компрометации;

• прямые расходы: утекшие API‑ключи оплачивают чужие запросы;

• утечка данных пользователей и репутационные потери;

• масштабирование ущерба на все ноды (>10 LLM и GPU).

Инвестиции в фильтры промптов не покрывают эти риски. Пока сеть не разделена и секреты не управляются централизованно, точка входа остаётся короткой.

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

Что делать в первую очередь

Проблема не в «магических» атаках. За 14 дней нашли 27 уязвимостей, и одна настройка — открытый Docker API на 2375 — дала ключи за 5 минут. Дефолтный JWT и ключи в открытом виде обнуляют защиту на уровне моделей.

Приоритеты действий:

• закрыть 2375, включить TLS и доступ через VPN/списки IP;

• убрать хранение секретов в открытом виде, перейти на Vault/Secrets Manager и ротацию;

• сегментировать сеть: разнести админ‑панель, прокси и аналитику, ввести least privilege;

• включить egress‑фильтрацию и DMARC с режимом enforcement.

Почему это работает: закрываете короткие пути ключам — атака становится сложнее и заметнее. Риск падает.

Финальный вывод: защищать LLM нужно снизу вверх. Без инфраструктурной дисциплины остальные меры мало что меняют.

Вопросы по защите LLM‑платформ