Защита ИИ: обзор угроз и мер их предотвращения

Несмотря на то, что системы ИИ начали внедряться достаточно давно (первые экспертные системы относят к 1970-1980 годам), вопросы обеспечения информационной безопасности при работе с ними оставались, скорее, областью научных исследований. Но волна интереса к системам ИИ, вызванная появлением доступных массовому пользователю моделей генеративного ИИ, привлекла к ним внимание и злоумышленников, и, соответственно, людей, занимающихся защитой информации. Стали появляться попытки как систематизации угроз информационной безопасности, так и создания инструментов обеспечения информационной безопасности при работе с системами ИИ.

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

Аспекты информационной безопасности в системах ИИ

В системах ИИ, как и в более традиционных системах, выделяют три аспекта информационной безопасности:

• конфиденциальность;
• целостность;
• доступность.

В англоязычной литературе иногда вместо термина confidentiality в контексте систем ИИ используется термин privacy, чтобы подчеркнуть тот факт, что конфиденциальной информацией в контексте систем ИИ являются не только параметры самой модели, но также и данные пользователей или организаций, использованные при обучении модели, или доступные ей через RAG и MCP-серверы.

Также, в отличие от более традиционных систем, для систем ИИ, в первую очередь генеративного, в качестве аспекта информационной безопасности, выделяют технические ограничения использования (системный промпт и RLHF-выравнивание), устанавливаемые разработчиком системы, обход которых может быть целью злоумышленников.

Имеющиеся классификации угроз информационной безопасности

Существует несколько классификаций угроз информационной безопасности, связанных с системами ИИ.
Например, в России в Банке данных угроз безопасности информации ФСТЭК РФ приведено краткое описание угроз и классификация способов их реализации. ФСТЭК РФ классифицирует угрозы по принадлежности инфраструктуры («разработчика программного обеспечения технологий ИИ» или «оператора системы ИИ») и по тому, какому из аспектов информационной безопасности они угрожают.

NIST в своей таксономии атак классифицирует угрозы по типу системы (предиктивный ИИ или генеративный) и по аспекту информационной безопасности, которому они угрожают.

Помимо ФСТЭК РФ и NIST есть и другие классификации угроз, как от производителей систем ИИ или средств защиты таких систем, так и от различных некоммерческих объединений и организаций.

Среди них можно выделить матрицу угроз от The Mitre Corporation – MITRE ATLAS, похожую по структуре на аналогичную матрицу для более традиционных информационных систем – MITRE ATT&CK, а также списки наиболее критичных угроз от OWASP – Top 10 for LLM Applications и Top 10 for Agentic Applications.

Сценарии использования систем ИИ в корпоративных окружениях

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

• использование публичных сервисов ИИ – использование сотрудниками публичных сервисов только в формате чатов. К этому сценарию отнесем также и «теневой ИИ» - несанкционированное использование систем ИИ сотрудниками организации без контроля со стороны служб ИТ и ИБ;
• использование RAG-систем – использование сотрудниками публичных сервисов ИИ с обогащением контекста взаимодействия документами корпоративных баз знаний;
• использование публичных сервисов с MCP-подключением к корпоративным системам;
• использование агентских приложений;
• использование частных систем ИИ – сюда относятся как варианты создания собственной модели, так и варианты использования известных моделей ИИ (таких как DeepSeek-V4, LLaMA 4, Qwen 3.6 и т.п.) с дообучением.

Использование публичных сервисов ИИ

В этом сценарии сотрудники используют публичные сервисы ИИ в формате чатов как санкционированно, когда политика информационной безопасности организации позволяет работать с подобными инструментами, так и несанкционированно. В последнем случае такое использование называется «теневым» ИИ, по аналогии с «теневой» ИТ-инфраструктурой.

Наиболее очевидной угрозой в таком случае является передача конфиденциальной информации компании или сотрудников, как минимум, оператору системы ИИ, а, как максимум, «неограниченному кругу лиц», в случае, утечки данных из сервиса.

Информация может быть передана пользователем напрямую в виде промпта или загружаемых пользователями файлов.

Масштаб такой угрозы – значительный, например, LayerX сообщает, что 40% всех файлов, загруженных пользователями организаций в чат-боты в 2025 году, содержали персональные данные или платежную информацию. Check Point в своем отчете за 2025 год упоминает, что примерно 7,5% промптов в чат-ботах содержали конфиденциальную информацию.

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

• инвентаризация используемых систем ИИ;
• предотвращение утечек конфиденциальной информации;
• блокировка каналов потенциального воздействия систем ИИ на инфраструктуру организации.

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

• межсетевые экраны следующего поколения (NGFW) для обнаружения взаимодействия систем ИИ в интернет-трафике организации;
• средства обеспечения безопасности конечных устройств: EPP/EDR для контроля установленного и запускаемого программного обеспечения на компьютерах пользователей, MDM-системы – для контроля мобильных устройств пользователей.

Предотвращение утечек конфиденциальной информации достигается применением DLP-систем и повышением грамотности пользователей в части использования систем ИИ (prompt hygiene).

Чтобы исключить несанкционированное воздействие систем ИИ на корпоративную инфраструктуру, следует реализовать комплекс мер: выявлять и останавливать запуск агентских приложений на устройствах пользователей (с помощью EPP/EDR и MDM), а также внедрить обязательное использование PAM-систем, которые не допустят прямое автоматизированное подключение с этих устройств к интерфейсам администрирования.

Дальнейшими шагами по повышению безопасности может быть внедрение специфических средств безопасности при работе с ИИ (guardrails, LLM Firewall), которые обеспечивают дополнительный слой защиты за счёт фильтрации промптов пользователей и выводов моделей, дополняя механизмы безопасности публичных сервисов. Отдельно стоит отметить, что эти средства безопасности также могут контролировать лимиты использования публичных ИИ сервисов и не допустить перерасход средств.

В качестве примера таких решений можно привести INFERA AI.Firewall, AppSec.AIGate, из зарубежных – Lakera Guard, Palo Alto Prisma AIRS, Cisco AI Defence, Radware LLM Firewall, Fortinet FortiAIGate. Кроме того, доступен ряд open-source-решений.

Использование RAG-систем

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

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

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

• DLP-системы;
• повышение грамотности пользователей в части использования систем ИИ.

Дополнительно, для усиления безопасности чувствительных данных, они могут быть маскированы на этапе предобработки перед помещением в векторную базу данных – персональные данные, платежная информация могут быть заменены на рандомизированные строки, по которым нельзя будет восстановить исходные данные. Как правило, для этого используются фреймворки типа Microsoft Presidio или scrubadub. Для определения (но не маскирования) чувствительной информации может также применяться Lakera Guard.

Для контроля доступа сотрудников к обработанным документам применяются встроенные средства контроля векторных баз данных – многие из них имеют средства контроля доступа на уровне отдельных строк, например, Weaviate, Qdrant, pgvector (расширение для PostgreSQL). Дополнительно необходима реализация аутентификации и авторизации в публичных сервисах (как правило, доступны на корпоративных планах использования) с помощью корпоративных учетных записей с использованием протокола OAuth 2.0.

Ещё одна специфичная угроза для RAG-систем – атаки типа «отравление данных» – злоумышленник помещает в хранилище, используемое для RAG документ, содержащий специальные инструкции для системы ИИ. При запросе такого документа система выдаст ответ, не соответствующий запросу, или выполнит другие, заложенные злоумышленником инструкции.

Такая атака необязательно требует доступа к внутренним документам – для RAG-контекста могут быть использованы e-mail, получаемые сотрудниками, сообщения из мессенджеров, данные из внешних систем и т.п. В качестве примера можно привести инцидент со Slack AI или атаку EchoLeak на Microsoft 365 Copilot.

Для подобных сценариев применяются статические или динамические системы фильтрации контента, например, INFERA AI.Firewall, AppSec.AIGate, Lakera Guard, Palo Alto Prisma AIRS, Cisco AI Defence, Radware LLM Firewall, Fortinet FortiAIGate и т.д.

Использование публичных сервисов с MCP-подключением к корпоративным системам

В отличие от RAG-систем использование MCP-серверов для подключения к внутренним информационным системам организации дает возможность модели ИИ не только запрашивать для работы данные из информационных систем организации, но и менять их, удалять, добавлять новые, позволяя автоматизировать рутинные операции сотрудников.

В таком сценарии, как и в случае с RAG-системами, есть угроза реализации атаки типа «отравление данных», при этом, учитывая динамическую природу данных, доступных модели через MCP-сервер, предобработка данных (фильтрация и маскирование), как правило, становится недоступной.
Другая угроза в таком сценарии – модель получает возможность внесения изменений в инфраструктуру или данные организации.

Кроме того, сами MCP-серверы увеличивают поверхность атаки за счет наличия уязвимостей в ПО, ошибок в конфигурировании или заложенной в них вредоносности.

Для устранения специфических угроз этого сценария применяют решения класса MCP gateway, обеспечивающие управление вызовами MCP-серверов со стороны системы ИИ: фильтрацию по настраиваемым политикам, маскирование чувствительных данных, отслеживание попыток внедрения опасных инструкций. Примером такого решения могут быть Lasso MCP Gateway, Bitfrost AI Gateway.

Использование агентских приложений

При такой схеме сотрудники организации используют в своей работе агентские приложения – системы, в которых модель ИИ не просто отвечает на вопросы, но автономно выполняет многошаговые задачи: вызывает внешние инструменты, читает и записывает файлы, выполняет код, взаимодействует с веб-сервисами и корпоративными системами. Агентские приложения чаще всего строятся на базе публичных API (OpenAI, Anthropic и др.) и запускаются как на пользовательских устройствах, так и на серверах организации.

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

Для этого сценария характерна расширенная поверхность утечки данных, т.к. агент в процессе работы агрегирует данные из множества источников — файловой системы, баз данных, электронной почты, корпоративных API. Вся эта информация проходит через публичный сервис ИИ, существенно расширяя объём данных, потенциально доступных оператору сервиса или утекающих при его компрометации.

Другой угрозой, как и в случае с предыдущим сценарием, является возможность агента внести несанкционированные изменения в объекты, к которым он имеет доступ. При этом, в отличие от подключения модели через MCP-сервер, агент, будучи, например, запущен на устройстве пользователя может иметь встроенные средства для модификации файлов на устройстве пользователя, открытия каналов подключения к различным корпоративным системам в обход MCP-gateway с привилегиями пользователя, его запустившего.

Для мультиагентных систем также возможно распространение атаки от одного агента к другим.

Меры защиты при использовании агентских приложений включают как обнаружение и блокирование несанкционированной установки и запуска агентских приложений, как при «теневом» ИИ, так и меры, направленные на контроль использования разрешённых к использованию агентов:

• отслеживание активности агентов – может осуществляться как внешними средствами (EDR на конечных узлах, NGFW, NTA в сети, SIEM), так и встроенными средствами агентов (агенты должны быть построены с использованием фреймворков с соответствующими возможностями, например, Rein, Sentry SDK, LangChain, Arize и т.п.). В некоторых случаях, например, при использовании Rein или для OpenClaw-агентов есть возможность не только пассивно отслеживать, но и блокировать недопустимые действия;
• обязательная идентификация, аутентификация и авторизация агентов при подключении к информационным системам организации;
• безопасное хранение учётных данных агентов и периодическая их смена (например, Hashicorp Vault);
• фильтрацию поступающих к агенту из внешних систем данных с помощью систем динамической фильтрации (guardrails), таких как INFERA AI.Firewall, AppSec.AIGate, Lakera Guard, Palo Alto Prisma AIRS, Cisco AI Defence, Radware LLM Firewall, Fortinet FortiAIGate и т.д.;
• обязательное подтверждение пользователем критичных действий (HITL – Human-in-the-loop) – модификации или удаления данных (агенты должны быть построены с учетом такой возможности).

Использование частных систем ИИ

В этом варианте организация использует собственные модели ИИ, либо самостоятельно разработанные, либо представляющие собой дообученные на собственных данных известные модели типа DeepSeek-V4, LLaMA 4, Qwen 3.6 и т.п.

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

Кроме того, значимыми угрозами становятся уязвимости платформ и фреймворков для запуска моделей, ошибки конфигурирования и закладки в моделях и LoRA-адаптерах.

Ещё одна специфичная угроза – дообучение моделей вызывает деградацию выравнивания базовой модели, что может привести к недопустимым ответам пользователю, особенно внешнему.

Меры защиты в таком сценарии должны включать в себя:

• статический анализ моделей и адаптеров, используемых организацией, на предмет наличия паттернов атак (например, при помощи PEFTGuard, AppSec.GenAI, HiddenLayer Model Scanner, Palo Alto Prisma AIRS);
• маскирование чувствительных данных при использовании их для обучения (например, с помощью Microsoft Presidio или Cleanlab);
• использование методов обучения, обеспечивающих конфиденциальность обучающих данных, такие как differential privacy;
• фильтрацию данных, используемых для обучения, для удаления потенциально вредоносных данных;
• тестирование моделей на уязвимость к атакам (red teaming) – например, при помощи INFERA AI.Firewall, AppSec.GenAI, IBM ART, NVDIA Garak;
• контроль конфигурации платформы запуска моделей и адаптеров, оценка соответствия конфигурации политикам безопасности;
• контроль наличия уязвимостей платформ запуска моделей и адаптеров;
• обязательная аутентификация и авторизация пользователей;
• использование API-шлюзов, таких как, например, LiteLLM или Bitfrost, для ограничения скорости поступления запросов для предотвращения DoS-атак;
• использование систем фильтрации промптов и ответов моделей (guardrails), таких как INFERA AI.Firewall, AppSec.AIGate, Lakera Guard, Palo Alto Prisma AIRS, Cisco AI Defence, Radware LLM Firewall, Fortinet FortiAIGate и т.д.

Заключение

Угрозы информационной безопасности при работе с системами ИИ растут вместе с глубиной их интеграции в инфраструктуру организации: при использовании публичных чат-сервисов главная угроза — утечка данных, в RAG-системах к ней добавляются нарушение разграничения доступа и отравление данных. При подключении через MCP и в агентских приложениях появляется возможность несанкционированного изменения данных и инфраструктуры. Частные модели добавляют угрозы, связанные с самими моделями.

При этом основой защиты остаются классические меры: инвентаризация, DLP, управление доступом и минимальные привилегии, защита учётных данных, мониторинг. Специализированные средства — guardrails, MCP-шлюзы, сканеры моделей — не заменяют эти меры, а дополняют их, поэтому организациям стоит начинать с инвентаризации и политики использования ИИ, а затем постепенно наращивать защиту по мере углубления интеграции и регулярно пересматривать принятые меры.


Источник: CISOCLUB