Статья Threat Modeling для LLM-приложений: Применение STRIDE и DFD к новым угрозам

1. Введение: LLM Threat Landscape​

Большие языковые модели (LLM) быстро перешли из разряда игрушек в слой реальных бизнес-процессов — от поддержки пользователей до обработки чувствительных данных. Вместе с пользой пришли и практичные риски. Прежде чем рассматривать тему подробнее, надо определить ключевые термины:

Под LLM Attack Surface понимается всё, через что на модель можно надавить, обмануть или подтолкнуть в нужную атакующему сторону. Это не только API и плагины: LLM можно атаковать словами, поэтому в поверхность атаки входят промпты, контекст, данные из RAG, обучающие выборки и пайплайны дообучения. Эксплуатация идёт не через баг в коде, а через баг в интерпретации смысла.

LLM Threat Landscape — это карта того, «что именно может пойти не так»: от prompt injection и data exfiltration до data poisoning, model inversion и атак на цепочку поставки. Attack Surface отвечает на вопрос «где нас могут зацепить», а Threat Landscape — «как именно это сделают». Игнорировать любую из этих частей — строить защиту вслепую, и это плохо заканчивается.

1.1. Рост LLM-приложений в 2025​

В 2025 году LLM стали применять гораздо чаще и шире: их интегрируют в сотни миллионов приложений, где каждое четвертое мобильное или веб-приложение использует эти модели для живого общения, автоматизации задач и генерации контента. Бизнесы по всему миру внедрили генеративный ИИ в процессы, от чат-ботов и кодинга до аналитики данных и переводов, делая LLM неотъемлемой частью повседневной работы.

На начало 2025 года глобальная база уникальных ежедневных активных пользователей (DAU) инструментов генеративного ИИ оценивается в диапазоне от 115 до 180 миллионов человек — точная цифра сложна из-за несогласованных стандартов отчетности и ограничений опросов, но данные платформ, исследований и аналитики дают надежную основу. Доминирует ChatGPT от OpenAI с 400 миллионами еженедельных активных пользователей (WAU), а рост подпитывают быстрые циклы принятия среди молодежи и профессионалов (маркетинг, IT), плюс глубокая интеграция в рабочие платформы вроде Microsoft 365 и Google Workspace.

По данным Market Growth Reports – Worldwide Market Research Report, Analysis & Consulting Размер рынка больших языковых моделей (LLM) в 2025 году составил 19 116,82 миллиона долларов США и ожидается, что к 2034 году он достигнет 111 304,46 миллиона долларов США, растя с CAGR 21,63% в период с 2025 по 2034 год.

1.2. OWASP LLM Top 10: обзор​

Если хочется реально понимать, как ломают LLM, стоит открыть OWASP LLM Top 10 за 2025), а не откладывать «на потом». Если вы уже внедряете LLM и при этом не смотрели этот список — у вас не просто пробел, а вполне рабочая зона для атак. Там описаны не теоретические страшилки, а конкретные уязвимости, которые уже эксплуатируются: от prompt injection, спокойно обходящего любые guardrails, до data poisoning, способного незаметно превратить модель в инструмент атакующего. Виды угроз можно представить в виде таблицы:

CWE‑LLM ID	Краткое описание угрозы
LLM01: Prompt Injection	LLM можно скомпрометировать специально составленным промптом, прямым или косвенным (через внешние данные). Модель может игнорировать системные инструкции и генерировать произвольный вывод, а надёжная 100‑% защита пока невозможна из‑за вероятностной природы модели.
LLM02: Sensitive Information Disclosure	Модель случайно или по запросу может раскрывать PII, исходный код, коммерческую тайну или фрагменты обучающего набора, в том числе через инверсионные атаки; защита опирается на очистку данных, маскирование и дифференциальную приватность.
LLM03: Supply Chain Vulnerabilities	Уязвимости проникают через третьесторонние датасеты, предобученные модели и MLOps‑пайплайны; защита строится на проверке поставщиков, SBOM, подписях моделей и усиленном мониторинге.
LLM04: Data and Model Poisoning	Внедрение «отравленных» данных или бэкдоров в обучении смещает поведение модели и создаёт скрытые уязвимости; защита включает трассировку происхождения данных, верификацию источников и regular AI Red Teaming.
LLM05: Improper Output Handling	Невалидированный вывод LLM может содержать код, SQL‑инъекции, XSS или фишинговые ссылки; к нему стоит относиться как к вводу от недоверенного источника, с фильтрацией, кодированием и проверкой.
LLM06: Excessive Agency	Слишком широкие привилегии и неподконтрольные плагины позволяют LLM инициировать опасные действия; безопасность строится на минимизации прав, human‑in‑the‑loop и строгой авторизации конечных систем.
LLM07: System Prompt Leakage	Раскрытие системных промптов даёт злоумышленнику «инструкцию к эксплуатации» и может включать секреты; критические данные и логику следует выносить из промптов во внешние, верифицируемые системы.
LLM08: Vector and Embedding Weaknesses	В RAG‑системах слабости векторных баз данных ведут к утечкам, инверсионным атакам и отравлению хранилища; нужен жёсткий контроль доступа, сегментация и регулярный аудит векторных БД.
LLM09: Misinformation	LLM склонны генерировать правдоподобные, но неверные ответы (галлюцинации); риск снижают RAG, fine‑tuning, cross‑checking и явное обозначение неопределённости в интерфейсе.
LLM10: Unbounded Consumption	Нет лимитов на запросы и длину контекста — ресурсы быстро истощаются, а расходы взлетают; требуются rate limiting, тайм‑ауты, sandboxing и мониторинг аномального потребления.

2. DFD для LLM-систем​

2.1. Компоненты: User → API → LLM → RAG → DB​

Любая LLM-система на практике — это не «одна магическая модель», а вполне приземлённый конвейер. Пользователь (User) отправляет запрос через API (application programming interface), где обычно живут аутентификация, rate limiting и первые попытки не пустить откровенный мусор внутрь. Дальше запрос уходит в LLM (large language model) на этапе inference (инференс — выполнение модели на входных данных), но всё чаще перед этим или параллельно подключается RAG (retrieval-augmented generation — генерация с извлечением), который достаёт релевантный контекст из vector database (векторная база данных) через embeddings (векторные представления текста).

Важно понимать, что RAG — это не «опция», а полноценный участник data flow. Он тянет данные из DB (database), которые могут быть как тщательно вычищенными, так и «как получилось». В результате итоговый ответ — это смесь пользовательского prompt, извлечённого retrieval-контекста и внутреннего состояния модели. С точки зрения безопасности это уже не один источник истины, а маленький хор, где любой участник может фальшивить — иногда очень убедительно.

2.2. Trust boundaries: user input, retrieval, model​

В классическом DFD всё крутится вокруг границ доверия (trust boundaries), и в LLM-системах их минимум три. Первая — user input boundary: всё, что приходит от пользователя, по определению недоверенное, даже если это «добрый» внутренний сотрудник. Именно здесь живёт prompt injection, который по сути и есть попытка выдать вредоносные инструкции за легитимные.

Вторая граница — retrieval boundary: данные, приходящие из RAG, внешних API или плагинов. Формально они выглядят «своими», потому что система сама их подтянула, но по факту это тот же untrusted input в более коварной форме. Третья — model boundary: сама LLM как чёрный ящик с вероятностной логикой. Мы не контролируем, как именно она смешивает источники, и это создаёт почву для data leakage и неожиданных эффектов, когда модель уверенно нарушает все ваши implicit security assumptions.

2.3. Data flows: training, inference, fine-tuning​

Чтобы не путаться, полезно разделять три разных потока данных (data flows). Первый — training (обучение): сюда попадают training data (обучающие данные), и именно здесь возникает риск data poisoning (отравление данных), когда атакующий заранее закладывает вредоносные паттерны. Второй — fine-tuning (дообучение): более точечная настройка модели под задачу, но с тем же риском supply chain-компрометации, особенно если используются внешние датасеты или сторонние пайплайны.

Третий — inference runtime: то, что происходит «здесь и сейчас» при обработке запроса. Именно тут сходятся prompt injection, RAG context и внутренняя логика модели. В отличие от training, где атака закладывается заранее, здесь всё происходит в реальном времени, и последствия могут быть мгновенными — от утечек до выполнения нежелательных действий. Хорошая новость: этот слой проще всего контролировать. Плохая — атакующий тоже это знает.

3. STRIDE для LLM​

3.1. Spoofing → Prompt Injection (direct/indirect)​

В классическом STRIDE spoofing — это подмена идентичности, но в мире LLM всё чуть интереснее: здесь подменяют не пользователя, а «голос авторитета». Prompt injection (инъекция подсказки) делает именно это — маскирует вредоносные инструкции под легитимные. Direct injection — когда пользователь напрямую пишет что-то вроде «игнорируй все предыдущие инструкции», и модель, как послушный стажёр, начинает импровизировать вне политики.

Indirect injection — более изящная атака: вредоносный prompt прячется в retrieval-контексте (RAG), например в документе или веб-странице. Модель воспринимает этот текст как доверенный источник и сама «убеждает себя» выполнить атаку. В терминах spoofing это подмена доверенного источника, только без логинов и паролей — достаточно убедительного текста.

3.2. Tampering → Model Poisoning, Data Poisoning​

Tampering — это изменение данных или логики системы, и в LLM это чаще всего происходит задолго до runtime. Data poisoning (отравление данных) внедряет вредоносные паттерны в training data, из-за чего модель начинает вести себя «как надо» атакующему в определённых сценариях. Это может быть незаметно до момента эксплуатации — классическая закладка.

Model poisoning — следующий уровень: компрометация fine-tuning pipeline. Если атакующий влияет на дообучение, он фактически переписывает поведение модели под свои цели. Отдельный бонус-трек — RAG poisoning, где подсовываются «грязные» документы в vector database. Формально модель не изменена, но её ответы уже скомпрометированы через retrieval.

3.3. Repudiation → Audit logging для AI​

Repudiation — это «я этого не делал», и с LLM это звучит почти как встроенная функция. Без audit logging (журналирование действий) невозможно понять, какой prompt привёл к какому ответу, какая версия модели использовалась и откуда пришёл retrieval-контекст. В итоге любое расследование превращается в гадание по логам… если они вообще есть.

Решение — traceability (трассируемость): хранение prompt history, версий модели, источников данных (provenance). Это особенно важно для систем с RAG, где ответ может зависеть от конкретного документа. Без этого LLM становится идеальным инструментом для «правдоподобного отрицания» — система что-то выдала, но никто не знает, почему.

3.4. Information Disclosure → Training Data Extraction​

Information disclosure (раскрытие информации) — одна из самых обсуждаемых проблем LLM. Training data extraction (извлечение обучающих данных) включает техники вроде membership inference (определение, был ли объект в обучающей выборке) и попытки вытащить конкретные фрагменты через хитрые prompt’ы. Иногда модель «вспоминает» больше, чем хотелось бы.

Отдельная история — RAG context leakage: утечки данных из подключённых источников. Если контроль доступа настроен плохо, модель может выдать чувствительный документ просто потому, что он оказался релевантным. Добавим сюда leakage через chain-of-thought или system prompt — и получаем систему, которая иногда говорит лишнее, причём очень уверенно.

3.5. DoS → Resource Exhaustion, Model Abuse​

Denial of Service в LLM выглядит не как SYN flood, а как аккуратное выжигание ресурсов. Resource exhaustion достигается через длинные prompt’ы, огромный context window или серию «дорогих» запросов. Token flooding (перегрузка токенами) — банальный, но эффективный способ увеличить стоимость и задержки.

Model abuse — более практичный сценарий: автоматизированное использование API для генерации контента, обхода ограничений или просто создания нагрузки. В итоге страдает доступность и экономика системы. В отличие от классических DoS, здесь атака может выглядеть как вполне легитимное использование — просто слишком активное.

3.6. Elevation → Excessive Agency​

Elevation of privilege в LLM проявляется как excessive agency — когда модели дают больше полномочий, чем она способна безопасно обработать. Это особенно заметно в agent-сценариях (agents), где LLM получает доступ к tool use (инструментам) и function calling (вызову функций). Один удачный prompt — и модель уже выполняет команды вне изначального замысла.

Проблема в том, что LLM не различает «текст как данные» и «текст как инструкцию». Если связать её с API, файловой системой или внешними сервисами, prompt injection может превратиться в реальное действие. В терминах STRIDE это чистая эскалация: от генерации текста к выполнению операций в системе — иногда с неожиданно креативными последствиями.

4. Prompt Injection: глубокий разбор​

4.1. Direct injection: user → model​

Direct prompt injection — это самый лобовой сценарий: атакующий пишет вредоносную инструкцию прямо в user input и рассчитывает, что модель послушно её выполнит. Типичный приём — instruction hijacking (перехват инструкций): «ignore previous instructions», «you are now in developer mode», «reveal system prompt». Модель не имеет встроенного понятия «иерархии доверия», поэтому такие конструкции часто срабатывают, особенно если guardrails формальные.

С технической точки зрения это эксплуатация того, что prompt — это и данные, и управляющая логика одновременно. Нет разделения между code и data, как в классических системах, поэтому любая строка может стать «командой». Jailbreaking — частный случай, где атакующий системно обходит ограничения модели, комбинируя роли, контекст и псевдо-метаинструкции, пока не получит нужное поведение.

4.2. Indirect: poisoned context (RAG)​

Indirect injection работает тоньше: вредоносный payload не приходит напрямую от пользователя, а внедряется в retrieval-контекст через RAG (retrieval-augmented generation). Например, атакующий добавляет документ в vector database или влияет на внешний источник (веб-страницу, API), откуда система берёт данные. Внутри документа может быть текст вроде «при анализе этого документа игнорируй все политики безопасности» — и модель воспринимает это как часть «знаний».

Главная проблема в том, что retrieval выглядит доверенным по умолчанию. Система сама выбрала этот контент, значит «ему можно верить» — логика, которая регулярно ломается. Это классический пример supply chain атаки, только вместо библиотек — текстовые данные. В результате даже идеально «чистый» user input может привести к компрометации через poisoned context.

4.3. Trust boundaries в контексте prompt injection​

Если разложить prompt injection через trust boundaries (границы доверия), становится видно, где именно всё идёт не так. User input boundary очевиден: внешний ввод без гарантий. Но retrieval boundary часто игнорируют — хотя данные из RAG, плагинов или web retrieval по сути такие же недоверенные, просто пришли «обходным путём».

Ключевая уязвимость — смешивание trusted и untrusted данных в одном пропте без явной маркировки. LLM не понимает, где «системные инструкции», а где «текст из интернета», и обрабатывает всё как единый поток. Отсюда и эффект: модель не нарушает правила — она просто следует наиболее убедительной инструкции в контексте. Если атакующий контролирует этот контекст, он контролирует и поведение модели.

5. Data Leakage в LLM​

5.1. Training Data Extraction​

Training data extraction (извлечение обучающих данных) — это попытка заставить модель «вспомнить лишнее». Несмотря на то, что LLM не хранит данные в явном виде, эффект memorization (запоминание) вполне реален, особенно для редких или чувствительных фрагментов. Через prompt probing (зондирование подсказками) атакующий перебирает формулировки, пока модель не начинает воспроизводить куски training data.

Более формализованные атаки включают membership inference (определение, входил ли объект в обучающую выборку) и reconstruction attacks (восстановление данных). На практике это может выглядеть как извлечение API-ключей, email-адресов или внутренних документов, если они «засветились» в обучении. Модель при этом не «понимает», что делает что-то запрещённое — она просто продолжает вероятностный текст.

5.2. RAG Context Leakage​

Если в системе есть RAG , появляется более приземлённый и часто более опасный вектор — утечка через retrieval. RAG context leakage возникает, когда модель получает доступ к чувствительным данным в vector database и без лишних вопросов включает их в ответ. Это особенно критично в multi-tenant системах, где возможен cross-tenant leakage (утечка между пользователями).

Проблема обычно не в самой модели, а в access control (контроль доступа) вокруг retrieval. Если фильтрация документов работает «на глазок» или вообще отсутствует, LLM становится удобным интерфейсом для обхода ограничений. Запрос выглядит невинно, но retrieval подтягивает лишнее — и модель честно всё это пересказывает.

5.3. Leakage через inference​

Даже без RAG утечки возможны на уровне inference runtime. Один из частых сценариев — system prompt leakage (утечка системных инструкций), когда пользователь через хитрые формулировки вытаскивает скрытые правила поведения модели. Это не всегда критично, но даёт атакующему карту того, как именно обойти ограничения.

Другой вектор — exposure скрытых механизмов: internal policies, chain-of-thought или служебные подсказки. Хотя современные системы стараются это маскировать, prompt injection часто комбинируется с попытками «разговорить» модель. В итоге leakage здесь — это не один баг, а побочный эффект всей архитектуры, где граница между внутренним и внешним довольно условна.

6. Защитные механизмы​

6.1. Input guardrails​

Input guardrails (ограничители входа) — это первая линия обороны, которая пытается отфильтровать или переписать user input до того, как он попадёт в LLM. Сюда входят prompt sanitization (очистка подсказок), injection detection (обнаружение инъекций) и policy enforcement (применение политик). На практике это либо набор правил и регулярных выражений, либо отдельные модели-классификаторы, которые решают, «опасный» ли запрос.

Проблема в том, что prompt injection редко выглядит как «вредоносный код». Это обычный текст, часто вежливый и логичный. Поэтому guardrails либо пропускают атаки, либо начинают блокировать нормальные запросы (false positives). В итоге это не серебряная пуля, а скорее фильтр грубой очистки — полезный, но легко обходится при достаточной изобретательности атакующего.

6.2. NeMo Guardrails​

NeMo Guardrails — это более структурированный подход, где поведение LLM описывается через declarative policies (декларативные политики) и сценарии диалога. Вместо попыток угадать «плохой» prompt система задаёт рамки: что модель может говорить, какие темы разрешены, как использовать tool use (инструменты) и function calling (вызов функций).

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

6.3. Output filtering​

Output filtering (фильтрация вывода) — это последний шанс поймать проблему перед тем, как ответ уйдёт пользователю. Здесь используются content filtering (фильтрация контента), DLP (data loss prevention — предотвращение утечек данных) и response validation (проверка ответа). Например, можно пытаться детектировать секреты, PII или признаки того, что модель «сболтнула лишнего».

Однако этот слой работает уже постфактум. Если модель сгенерировала чувствительные данные, значит, где-то раньше уже произошёл сбой — в retrieval, access control или prompt handling. Кроме того, как и в случае с input guardrails, фильтры легко обходятся через перефразирование или постепенное извлечение данных. Это полезный safety net, но не основная защита.

6.4. Архитектурные меры​

Самые надёжные меры лежат не в prompt-магии, а в архитектуре. Изоляция между компонентами снижает влияние компрометации одного слоя на другие. Secure RAG подразумевает строгий контроль источников, фильтрацию retrieval и явное разделение trusted и untrusted данных. Least privilege (принцип наименьших привилегий) для доступа к инструментарию ограничивает, что именно LLM может сделать даже при успешной атаке.

Именно здесь появляется реальная устойчивость: когда даже успешный prompt injection не приводит к катастрофе. LLM в этом случае рассматривается как недоверенный интерпретатор, а не как источник истины. Это менее удобно, зато гораздо ближе к реальности — особенно если учитывать, насколько креативно модель умеет ошибаться.

7. Workshop: Threat Model за 2 часа​

7.1. Scope и assets​

Первый шаг — не «рисовать стрелочки», а договориться, что именно мы защищаем. Scope (границы анализа) для LLM-систем быстро расползается, потому что сюда входят не только сама модель, но и RAG, API, внешние источники и даже tool use. Поэтому лучше сразу зафиксировать: рассматриваем ли мы только inference runtime или захватываем training и fine-tuning pipeline тоже.

Дальше — assets (активы): model weights (веса модели), training data (обучающие данные), prompts (запросы пользователей), retrieval-контекст, API-ключи и доступ к инструментам. Типичная ошибка — забыть, что prompt тоже актив, особенно если он содержит чувствительную информацию. После этого определяются threat actors (нарушители): от случайных пользователей до целенаправленного adversary, который знает, как работает prompt injection и RAG.

7.2. DFD construction​

Теперь можно строить DFD (data flow diagram — диаграмма потоков данных), но без фанатизма: достаточно уровня, на котором видны User → API → LLM → RAG → DB. Важно не количество блоков, а корректно отмеченные data flows (потоки данных): где проходит user input, как подключается retrieval, и где происходит inference.

Ключевой момент — явно отметить trust boundaries (границы доверия). Обычно их как минимум три: user input, retrieval и сама модель. Если на схеме всё выглядит «внутренним и безопасным», значит, границы просто не нарисованы. Хороший DFD для LLM — это тот, где сразу видно, откуда может прийти untrusted data и куда он дальше течёт без контроля.

7.3. STRIDE analysis​

Когда схема готова, начинается самое интересное — прогон по STRIDE. Здесь не нужно изобретать новые угрозы, достаточно честно применить категории: где возможен spoofing (обычно prompt injection), где tampering (poisoning), где information disclosure (leakage через training или RAG), и так далее.

Практический трюк — делать mapping угроз к конкретным компонентам: не «в системе возможен prompt injection», а «на границе user input → API возможен direct injection, на retrieval → LLM — indirect injection». После этого появляется возможность приоритизации рисков: какие атаки реально достижимы, какие имеют наибольший impact, и где защитные механизмы отсутствуют или носят декоративный характер.

8. Template и deliverables​

8.1. Что должно получиться​

Результат threat modeling для LLM — это не абстрактные «риски высокого уровня», а вполне осязаемый набор артефактов. В первую очередь это DFD схема (data flow diagram), где явно показаны компоненты вроде User, API, LLM, RAG и DB, а также размечены trust boundaries и ключевые data flows (training, fine-tuning, inference). Если на этой схеме не видно, откуда может прийти untrusted input — значит, она декоративная.

Дальше формируется таблица STRIDE угроз с привязкой к конкретным узлам и потокам: где возможен prompt injection (direct/indirect), где возникает model poisoning или data leakage, и какие сценарии ведут к excessive agency. К этому добавляется список mitigations (мер снижения риска) — от guardrails до архитектурных ограничений — и security checklist для LLM, который можно использовать как быстрый sanity check перед релизом или аудитом.

8.2. Форматы​

Чтобы всё это не осталось «разовой активностью», важно упаковать результат в воспроизводимые форматы. Самый удобный вариант — Markdown template, где уже есть заготовки под DFD, STRIDE-таблицу, перечень активов и trust boundaries. Это снижает порог входа и убирает соблазн каждый раз «изобретать threat model с нуля».

Поверх этого собирается threat model report — документ, который можно показать архитекторам, безопасникам и менеджменту без необходимости устного перевода с «языка стрелочек». Финальный слой — архитектурные рекомендации: конкретные изменения в системе (secure RAG, isolation, least privilege, guardrails), которые напрямую вытекают из анализа. Если их нет, значит threat modeling превратился в упражнение ради галочки.