К содержимому
RU
Запросить доступ
Разделы документацииБиблиотека
Статус доступа
БИБЛИОТЕКА ЗАЩИТЫ ИИ

🌐 Защита LLM-шлюзов и AI-API: безопасность периметра от denial of wallet, инъекции и утечек

Целевая аудитория: Команды, эксплуатирующие LLM-шлюз или AI-API на периметре — прокси и gateway перед моделями (LiteLLM-подобные), endpoint'ы инференса, продуктовые AI-API, мультитенантные платформы модели-как-сервис.

LLM-шлюз — это место, где впервые приземляется недоверенный ввод и где сходятся все деньги, ключи и тенанты. В отличие от отдельного бота или агента, шлюз агрегирует риск: одна квота на всех, один набор апстрим-ключей, один кэш на несколько арендаторов. Поэтому атаки здесь специфичны для периметра: опустошение бюджета потокенным флудом (denial of wallet), инъекция на самом входе, утечка системного промпта и данных на границе, кража ключей и confused deputy через passthrough токенов, извлечение модели через инференс-API и пробои мультитенантной изоляции. Уязвимости реальны и эксплуатируются: в популярных шлюзах находили pre-auth SQL-инъекцию в проверке API-ключа и неограниченное потребление ресурсов. Когда стоит задача обеспечить безопасность LLM-шлюза и защиту AI-API, защищать нужно сам периметр: вход, выход, бюджет и границу между арендаторами.

Защитный слой Spectorn встаёт перед шлюзом как gateway/прокси (режим Shield DMZ) и инспектирует содержимое запросов и ответов: распознаёт инъекцию во входящем потоке, контролирует потребление и денежный флуд, находит утечку секретов и PII в содержимом и ведёт хеш-связанный журнал решений с разбивкой по тенантам. Это инспекция контента на шлюзе, а не сетевой egress-фильтр. Защитный слой работает в составе платформы Spectorn.

Эта страница разбирает атаки на LLM-шлюзы в терминах OWASP Top 10 для LLM-приложений (2025) и техник MITRE ATLAS — и показывает, какие движки Spectorn прикрывают каждый вектор.

🛑 Ключевые риски и что Spectorn с ними делает

1. Опустошение бюджета и абуз квот (Denial of Wallet)

Риск: Атакующий гонит потокенный флуд, рекурсивно раздувает контекст или шлёт дорогие запросы в метрируемый endpoint, чтобы накрутить счёт оператора или исчерпать квоту. Это не классический DoS — цель финансовая: опустошить бюджет на апстрим-провайдере. Уязвимости неограниченного потребления реальны (например, CVE-2024-8984 в LiteLLM — некорректная multipart-граница вызывала неограниченный расход ресурсов и недоступность сервиса).

OWASP LLM10:2025 Unbounded Consumption · MITRE ATLAS AML.T0034 (Cost Harvesting), AML.T0029 (Denial of ML Service).

Защита Spectorn:

  • Движки/компоненты: resource_exhaustion, корреляция в вашей SIEM.
  • resource_exhaustion распознаёт паттерны аномального потребления — сверхдлинный контекст, рекурсивное раздувание, всплеск частоты или объёма от одного источника — на самом периметре.
  • Связки «всплеск дорогих запросов от одного клиента/ключа» растянуты на много событий: ловите их правилом в вашей SIEM, а тротлинг ставьте на свой API-шлюз.

Что Spectorn честно НЕ заменяет: жёсткие rate-limit, потокенные квоты и бюджетные cap'ы на стороне самого шлюза и биллинга. Это обязательный базовый слой. Spectorn детектирует поведенческий паттерн denial of wallet и коррелирует его, но не подменяет лимитер и бюджетные алерты вашего gateway.

2. Инъекция и джейлбрейк на периметре (Perimeter Prompt Injection)

Риск: Шлюз — первое место, куда приходит адверсариальный ввод. Если авторизация решений завязана на инструкции модели, а не на проверяемые claim'ы токена, инъекция или джейлбрейк на границе обходят политику ещё до того, как запрос дойдёт до бизнес-логики.

OWASP LLM01:2025 Prompt Injection · MITRE ATLAS AML.T0051 (LLM Prompt Injection), AML.T0054 (LLM Jailbreak).

Защита Spectorn:

  • Движки: injection, jailbreak, meta_framing.
  • injection инспектирует входящий поток на встроенные инструкции и попытки переопределить системные указания на самом периметре, до маршрутизации к модели.
  • jailbreak распознаёт техники обхода ограничений; meta_framing ловит мета-обёртки («представь, что ты в режиме разработчика»), которыми инъекцию маскируют под легитимный запрос.

3. Утечка системного промпта и данных на границе (Boundary Leakage)

Риск: Ответ на границе утекает системным промптом, внутренней конфигурацией маршрутизации/тенанта или данными другого пользователя. Известный класс — кросс-тенантный сайд-канал через общий KV-кэш (исследование «I Know What You Asked», NDSS 2025): общие префиксы кэша утекают промпт другого арендатора по тайммингу Time-To-First-Token.

OWASP LLM07:2025 System Prompt Leakage, LLM02:2025 Sensitive Information Disclosure · MITRE ATLAS AML.T0024 (Exfiltration via AI Inference API).

Защита Spectorn:

  • Движки: output_scanner, pii, secret_scanner.
  • output_scanner инспектирует ответ на границе на фрагменты системного промпта, служебной конфигурации и разметки — обнаруженное блокируется до выдачи клиенту.
  • pii находит персональные данные в исходящем ответе; secret_scanner находит ключи и токены до выхода за периметр.

Граница ответственности: изоляцию KV-кэша между арендаторами и корректную сегментацию префиксов обеспечивает сам движок инференса/шлюза. Spectorn контролирует содержимое ответа на границе, но не управляет внутренней реализацией кэша модели.

4. Кража ключей и confused deputy через passthrough (API Key Theft)

Риск: Украденные или утёкшие ключи шлюза дают атакующему доступ к модели; passthrough-конфигурация позволяет малодоверенному вызывающему «одолжить» апстрим-кредами шлюза (confused deputy). Уязвимости реальны: в LiteLLM находили pre-auth SQL-инъекцию в проверке API-ключа прокси через подделанный заголовок Authorization — без аутентификации и активно эксплуатируемую.

OWASP LLM02:2025 Sensitive Information Disclosure, LLM06:2025 Excessive Agency, LLM03:2025 Supply Chain · MITRE ATLAS AML.T0040 (AI Model Inference API Access), AML.T0048 (External Harms).

Защита Spectorn:

  • Движки/компоненты: secret_scanner, injection, exfiltration, output_scanner.
  • secret_scanner находит ключи и токены в полезной нагрузке (включая попытки увести их через параметры/заголовки) до того, как они попадут в ответ.
  • injection распознаёт попытки внедрить нагрузку через заголовки/параметры запроса; exfiltration ловит выгрузку кредов в содержимом запросов и ответов. output_scanner инспектирует ответ модели и блокирует или редактирует утечку секретов скомпрометированного ключа до возврата клиенту.

Что Spectorn честно НЕ заменяет: ротацию ключей, узкие scope'ы апстрим-кредов, корректную настройку OAuth/passthrough и параметризованные запросы в коде самого шлюза. Spectorn — слой обнаружения на границе, а не статический анализатор кода и не система управления секретами.

5. DoS модели и исчерпание ресурсов (Model Resource Exhaustion)

Риск: Сконструированные сверхдлинные или патологические запросы исчерпывают GPU/память и деградируют доступность для всех арендаторов. Вектор пересекается с denial of wallet, но фокус здесь на доступности, а не на счёте: цель — положить или замедлить сервис.

OWASP LLM10:2025 Unbounded Consumption · MITRE ATLAS AML.T0029 (Denial of ML Service).

Защита Spectorn:

  • Движки: resource_exhaustion, model_containment.
  • resource_exhaustion распознаёт патологические по размеру и структуре запросы на периметре и помечает их до того, как они займут ресурсы инференса.
  • model_containment удерживает модель в безопасных границах исполнения, не давая запросу вывести её в ресурсо-разрушительное состояние.

6. Извлечение модели через инференс-API (Model Extraction)

Риск: Систематический опрос реконструирует функциональную копию модели или её интеллектуальную собственность через публичный endpoint инференса. Атакующий не «взламывает» веса — он выкачивает поведение модели массой запросов.

OWASP LLM10:2025 Unbounded Consumption, LLM02:2025 Sensitive Information Disclosure · MITRE ATLAS AML.T0024 (Exfiltration via AI Inference API — Extract AI Model), AML.T0040 (AI Model Inference API Access).

Защита Spectorn:

  • Движки/компоненты: resource_exhaustion, intent_revelation, корреляция в вашей SIEM.
  • resource_exhaustion ловит аномальный объём и регулярность запросов, характерные для систематического выкачивания; intent_revelation помечает паттерны зондирования модели.
  • Связка «высокообъёмное систематическое зондирование от одного источника» растянута на много событий: ловите её правилом в вашей SIEM, а тротлинг ставьте на свой API-шлюз.

7. Пробои мультитенантной изоляции (Multi-Tenant Isolation Breaks)

Риск: Коллизии ключей кэша, ошибки маршрутизации/failover, общий KV-кэш или некорректная изоляция сессий утекают данные между арендаторами. Исследования показывают, что мультитенантность усиливает кросс-тенантную эксфильтрацию и эффект отравления базы знаний — общая инфраструктура множит радиус поражения.

OWASP LLM02:2025 Sensitive Information Disclosure, LLM08:2025 Vector and Embedding Weaknesses, LLM04:2025 Data and Model Poisoning · MITRE ATLAS AML.T0024 (Exfiltration via AI Inference API).

Защита Spectorn:

  • Движки/компоненты: pii, exfiltration, Decision Logger.
  • pii и exfiltration распознают утечку данных в содержимом запросов и ответов; Decision Logger ведёт хеш-связанный журнал с разбивкой по тенантам — видно, чьи данные и в каком запросе фигурировали.

Граница ответственности: саму архитектуру изоляции арендаторов — раздельные namespace, сегментацию кэша, scoped-ключи, фильтрацию «до извлечения, а не после» — обеспечивает ваша платформа. Векторно-эмбеддинговую часть мультитенантного RAG разбирает Безопасность RAG-приложений как поверхности. Spectorn контролирует утечку на границе и даёт аудит, но не подменяет архитектурную изоляцию.

🛠️ Настройка политики

Файла конфигурации, который нужно развернуть, нет: политику вашего тенанта по запросу задаёт оператор платформы, включая режим проверки (блокировка или наблюдение, при котором видно, что было бы заблокировано), списки разрешений и запретов, порог блокировки и веса категорий. Для этой отрасли важнее всего движки: injection, jailbreak, meta_framing, resource_exhaustion, model_containment, intent_revelation, output_scanner, pii, exfiltration. Начните с режима наблюдения на своём трафике, посмотрите, что было бы заблокировано, и затем включите блокировку. Маскирование персональных данных в облачных контурах не включено: запрос с персональными данными блокируется или отмечается, а не переписывается.

🚨 Корреляция в вашей SIEM

Spectorn отправляет каждую находку в указанную вами SIEM как JSON-событие по HTTPS (spectorn.ai-finding.v1) с правилом, категорией, серьёзностью и verdict_id. Многошаговые правила для этой отрасли стройте там, например: аномальный объём дорогих запросов от одного ключа/источника, признак опустошения бюджета или DoS модели; инъекция или джейлбрейк на границе, за которыми следует утечка системного промпта или данных. Собственная корреляция SOC в Spectorn (GoMCP) в облачных контурах RU и Global не развёрнута.

❓ Частые вопросы (FAQ)

Что такое denial of wallet и как защитить LLM-шлюз от опустошения бюджета? Denial of wallet — это атака на счёт: потокенный флуд, рекурсивное раздувание контекста или дорогие запросы накручивают расход на апстрим-провайдере, а не кладут сервис. Spectorn детектирует поведенческий паттерн движком resource_exhaustion. Но базовый слой — жёсткие rate-limit, потокенные квоты и бюджетные cap'ы на самом шлюзе; Spectorn их дополняет, а не подменяет.

Почему инъекцию надо ловить на периметре шлюза, а не только в приложении? Шлюз — первое место, куда приземляется недоверенный ввод. Если авторизация завязана на инструкции модели, а не на claim'ы токена, инъекция или джейлбрейк на границе обходят политику ещё до бизнес-логики. Spectorn инспектирует входящий поток движками injection, jailbreak и meta_framing на самом периметре, до маршрутизации к модели.

Как защититься от кражи API-ключей и confused deputy на шлюзе? Spectorn находит ключи и токены в полезной нагрузке движком secret_scanner (включая попытки увести их через заголовки/параметры), ловит выгрузку кредов в содержимом запросов и ответов движком exfiltration и блокирует или редактирует утечку секретов в ответе модели движком output_scanner. Но ротация ключей, узкие scope'ы апстрим-кредов, корректный OAuth/passthrough и параметризованные запросы в коде шлюза — задача вашей платформы; Spectorn это не заменяет.

Может ли Spectorn предотвратить извлечение модели через API? Spectorn ловит аномальный объём и регулярность запросов, характерные для систематического выкачивания модели, движком resource_exhaustion и помечает зондирование движком intent_revelation; серию запросов ловит правило в вашей SIEM. Это поднимает стоимость атаки извлечения, но архитектурные меры (watermarking, ограничение детальности вывода) остаются на стороне платформы.

Как Spectorn помогает с мультитенантной изоляцией? На границе Spectorn ловит утечку данных между арендаторами движками pii и exfiltration, а Decision Logger ведёт журнал с разбивкой по тенантам — видно, чьи данные и в каком запросе пересекли границу. Но саму изоляцию — раздельные namespace, сегментацию KV-кэша, scoped-ключи, фильтрацию «до извлечения, а не после» — обеспечивает ваша архитектура. Векторную часть мультитенантного RAG разбирает Безопасность RAG-приложений как поверхности.

Чем кросс-тенантный сайд-канал через KV-кэш опасен и прикрывает ли его Spectorn? Общие префиксы KV-кэша могут утечь промпт другого арендатора по тайммингу Time-To-First-Token (исследование NDSS 2025). Spectorn контролирует содержимое ответа на границе движком output_scanner и фиксирует пересечение границы в Decision Logger, но саму изоляцию кэша и сегментацию префиксов обеспечивает движок инференса — это его зона ответственности.

Чем защита шлюза отличается от защиты отдельного бота или агента? Шлюз агрегирует риск: одна квота, один набор апстрим-ключей, один кэш на несколько арендаторов — поэтому фокус на бюджете (denial of wallet), границе (утечки, кросс-тенант) и ключах. Поведение конкретного бота разбирает Защита клиентских AI-чат-ботов, а автономного агента с инструментами — Безопасность автономных AI-агентов.

📚 Источники

Внутренние материалы: OWASP Top 10 для LLM (2025) · Безопасность RAG-приложений как поверхности · Защита клиентских AI-чат-ботов · Безопасность автономных AI-агентов.

Безопасность LLM-шлюзов и AI API | Spectorn