Как бизнесу обезопасить себя в эпоху генеративного ИИ
8 мин
147
6
В основе популярных чат-ботов, таких как ChatGPT, лежат большие языковые модели (LLM). Они не только обрабатывают массивы данных, но и удерживают в памяти контекст. Модели, работающие как внешние облачные сервисы, становятся новым неконтролируемым каналом обмена данными между корпоративной инфраструктурой и внешней средой. В итоге ИИ‑сервисы создают двусторонний контур рисков: как изнутри, так и извне корпоративного периметра. На этот тренд накладывается взрывной рост облачных сервисов, API и микросервисных архитектур, что делает границы ИТ‑инфраструктуры всё более размытыми. Когда сотрудники взаимодействуют с внешними ИИ-платформами напрямую из браузера, без прохождения через внутренние шлюзы безопасности, традиционные механизмы защиты теряют эффективность.
Утечки через ИИ
Внутренние риски. Если раньше внимание специалистов по ИБ было сосредоточено на защите почтовых систем, мессенджеров и файловых хранилищ, то сегодня всё чаще в зоне риска оказываются обращения сотрудников к публичным нейросервисам. Эти запросы выполняются за пределами корпоративного периметра и нередко остаются вне поля зрения служб безопасности. В погоне за удобством и эффективностью, стремясь получить быстрый ответ, пользователи зачастую не задумываются о последствиях загрузки служебной информации в нейросети. Любая отправка текста, документа или кода в LLM-сервис становится потенциальным инцидентом, ведь неизвестно, где и как эти данные будут обработаны, сохранены и в какой форме могут быть возвращены в ответы другим пользователям.
Результатом может стать:
- утечка интеллектуальной собственности или исходных кодов через открытые API;
- раскрытие персональных данных клиентов и сотрудников третьим лицам;
- попадание коммерческой информации в обучающие выборки внешних моделей;
- нарушение комплаенс-требований (GDPR, 152-ФЗб ISO 27001 и др.).
Фактически без централизованного контроля веб‑трафика обращения к LLM становятся альтернативным каналом утечки данных и новым типом теневых ИТ‑активностей (shadow IT). Такие сценарии практически не отслеживаются стандартными DLP‑ или антивирусными решениями.
Внешние риски. Одновременно генеративные модели становятся новым инструментом злоумышленников против компаний. Современные LLM-инструменты позволяют им быстро и правдоподобно генерировать вредоносные сценарии. Например:
- фишинговые письма и сайты, визуально неотличимые от оригиналов;
- вредоносные скрипты и инъекции, написанные в «один клик»;
- динамические ловушки, где сгенерированные коды подменяются в ответах на пользовательские запросы;
- LLM-инъекции (prompt injection), позволяющие обходить фильтры и выполнять нежелательные команды в чат-интерфейсах компании.
Всё это формирует новую категорию угроз — ИИ‑генерируемые атаки, отличающиеся высокой скоростью, автоматизацией и достоверностью подделок. Они подрывают доверие пользователей и усложняют обнаружение, поскольку вредоносный контент маскируется под безобидные ответы ИИ-ассистентов.
Как ИИ меняет задачи кибербезопасности
Новая реальность в корне меняет парадигму управления киберрисками. Современным средствам ИБ приходится адаптироваться и переходить:
- от классического периметрального контроля к интеллектуальному анализу контента трафика;
- от статических списков доменов к гибким политикам категоризации и выявлению признаков утечек на уровне смыслов;
- от защиты от вредоносного кода к мониторингу аномальных сценариев поведения пользователей и ИИ-сервисов.
В условиях стремительной интеграции LLM‑инструментов в бизнес‑процессы ключевой задачей систем безопасности становится контроль обращений к ИИ‑сервисам. Сегодня критически важно не просто ограничивать доступ к определённым ресурсам, а понимать контекст и содержимое взаимодействия — какая именно информация передаётся, в каком виде и что возвращается в ответ.
Эффективная ИБ-инфраструктура должна уметь:
- распознавать обращения к LLM-платформам, включая скрытые поддомены и API-интерфейсы;
- анализировать исходящие запросы на наличие признаков конфиденциальной информации;
- проверять входящие ответы на предмет внедрённого кода, вредоносных скриптов или подозрительных ссылок;
- применять гибкие политики фильтрации и категоризации, регулирующие допустимые сценарии взаимодействия с нейросервисами.
В таких условиях современные SWG-решения становятся полноценным элементом стратегии защиты данных. Это, например, Solar webProxy, Zscaler Internet Access, Cisco Umbrella, Netskope, Kaspersky Web Traffic Security. Они способны контролировать не только направление запроса, но и содержимое взаимодействия, включая файлы, текстовые фрагменты и семантические паттерны обращений. Например, Solar webProxy — по сути веб-шлюз, который сочетает функции SWG и DLP в рамках одного продукта.
Функциональность подобных решений эволюционирует в сторону «умного периметра» — промежуточного уровня между классическим шлюзом и DLP-системой. SWG берёт на себя функции первичной контент-инспекции и выявления рисков утечки на ранней стадии. Он анализирует смысловую составляющую передаваемых данных, определяет наличие потенциально конфиденциальной информации, блокирует подозрительные загрузки и автоматизированно реагирует на аномальные сценарии взаимодействия с внешними сервисами.
Как именно ИИ создаёт риски для бизнеса и как им противостоять? Разберём на примерах применения Solar webProxy.
Тихие утечки: внутренний контур риска
Отчёт для проверки. Обычная ситуация: сотрудник загружает в DeepSeek, ChatGPT или Preplexity внутренний аналитический отчёт, чтобы получить «упрощённую версию» для презентации или перевода. В документе есть конфиденциальные финансовые показатели, имена контрагентов и внутренние KPI.
Задача: предотвратить передачу во внешние нейросервисы документов, содержащих признаки финансовых или клиентских данных.
Действие: Solar webProxy выполняет контент-инспекцию исходящего запроса, проверяя при этом принадлежность домена к запрещённым ресурсам ИИ-ассистентов. Он анализирует:
- расширение и MIME-тип файла (например, офисные документы);
- наличие паттернов финансовых метрик (%, KPI, client_id и других из заранее сформированного списка ключевых слов);
- числовые последовательности, характерные для ИНН, счетов, телефонов.
При совпадении с эталонным шаблоном метаданных или DLP-паттернов запрос блокируется с уведомлением пользователя (шаблоны блокировки).
Помощь с кодом. Разработчик копирует в чат с ИИ-ассистентом фрагмент внутреннего исходного кода с комментариями и названиями модулей, чтобы получить помощь в оптимизации. Код содержит бизнес-логику продукта и уникальные идентификаторы систем.
Задача: защитить исходный код и внутренние алгоритмы от утечки через публичные API-интерфейсы.
Действие: Solar webProxy проводит семантический анализ текстового содержимого запроса, проверяя при этом принадлежность домена к запрещённым ресурсам ИИ-ассистентов:
- обнаружение фрагментов кода (ключевые слова, синтаксис, служебные конструкции);
- выделение внутренних namespace, имен функций, URL внутренних API.
При подтверждении условий правила «Исходный код» запрос блокируется, а пользователь получает уведомление об этом.
Проверка клиентского письма. Менеджер отдела продаж просит нейросеть переписать письмо клиенту «более вежливо». Он добавляет в запрос имя клиента, номер договора и условия сделки.
Задача: исключить передачу персональных и коммерческих данных клиентов в публичные ИИ-ассистенты.
Действие: Solar webProxy выполняет лексико-семантический анализ тела запроса, проверяя при этом принадлежность домена к запрещённым ресурсам ИИ-ассистентов:
- поиск маркеров персональных данных (согласно заранее созданным характерным справочникам ключевых слов);
- обнаружение шаблонов коммерческих условий;
- распознавание расширения вложений и проверка MIME-типов.
При выявлении запрос блокируется с уведомлением пользователя.
Обработка внутренних коммуникации. HR-специалист копирует в ИИ-ассистент фрагмент переписки из корпоративного мессенджера, чтобы получить совет по управлению конфликтной ситуацией. В тексте присутствуют персональные данные сотрудников и упоминания внутренних ролей.
Задача: предотвратить передачу фрагментов внутренних коммуникаций, содержащих персональные данные и служебные сведения.
Действие: Solar webProxy анализирует текстовые поля запроса, проверяя при этом принадлежность домена к запрещённым ресурсам ИИ-ассистентов, на наличие:
- обращений к персоналиям, email-доменов корпоративного формата;
- упоминаний внутренних подразделений или ролей;
- контекстных связок по типу «жалоба», «увольнение», «зарплата» и т.д.
При совпадении с корпоративными словарями запрос блокируется.
Интеллектуальный помощник для тендера. Сотрудник загружает в Preplexity или Claude тендерную документацию для автоматического извлечения ключевых требований и подготовки коммерческого предложения. Документ содержит цены, сроки, технические условия и сведения о поставщиках.
Задача: защитить коммерческие тендерные данные от несанкционированной обработки внешними сервисами.
Действие: Solar webProxy проверяет принадлежность домена к запрещённым ресурсам ИИ-ассистентов. Он также:
- распознаёт расширение вложения и MIME-тип файла (например, офисные документы);
- распознаёт ключевые слова вложения, характерные для тематики кейса (на основе справочников ключевых слов);
- анализирует контекст текста на наличие коммерческих числовых диапазонов и терминов по заранее созданному списку;
- контекстных связок по типу «жалоба», «увольнение», «зарплата».
При совпадении со справочником «Тендерные документы» запрос блокируется.
Сценарий интеграции с API ChatGPT. В отделе маркетинга или разработки создаётся внутренний скрипт для обращения к ChatGPT API. Цель — автоматическая генерация текстов для публикаций или отзывов. Разработчик для удобства вставляет в код реальный API-ключ и параметры, взятые из внутренней конфигурации. Запрос идёт напрямую через прокси. Таким образом, Solar webProxy может перехватывать и анализировать его содержимое.
Во внешний сервис могут быть переданы:
- токены и ключи доступа к корпоративным системам;
- внутренние URL-адреса (URL-адреса внутренних сред разработки и тестирования);
- идентификаторы, описывающие внутренние объекты (user_id, project_id, secret_key и др.);
- фрагменты конфигураций и credentials.
Задача: автоматически определять запросы к API нейросервисов и выявлять в них конфиденциальные элементы, относящиеся к категории служебных данных.
Действие: Solar webProxy может:
- определить, что запрос направлен к внешнему ИИ-сервису (категория «ИИ-ассистенты» или явно обозначенные домены назначения);
- проверять HTTP-заголовки на предмет наличия ключей и токенов (справочник ключевых HTTP-заголовков и их значений);
- проводить инспекцию тела запроса на наличие параметров JSON (по заранее сформированному списку). Для повышения точности можно использовать регулярные выражения в поиске ключевых слов в теле запроса;
- проводить логическую корреляцию признаков. Это проверка на удовлетворение условиям правила — если одновременно есть обращение к LLM-домену, токен в заголовке и упоминание внутреннего URL в теле запроса, то запрос блокируется.
Дополнительно в правиле можно настроить проверки:
- POST запросов с Content-Type: application/json или multipart/form-data;
- объём тела запроса;
- на список источников, кому запрещено/разрешено использовать API нейросервисов в целях R&D.
При совпадении со справочником «Тендерные документы» запрос блокируется.
Незаметные атаки: внешний контур риска
Фишинговые вложения, возвращаемые LLM (Office с макросами). Внешний LLM/интегратор возвращает пользователю ответ, в котором есть вложение (или ссылка на вложение) с офисным документом (.docx/.docm/.xlsm/.xlsx). Пользователь скачивает и открывает — в документе есть макросы. Результат загрузки заражённого документа (VBA-макросы) — компрометация рабочего места.
Задача: отлов и блокировка потенциально опасных офисных вложений в ответах LLM до выдачи пользователю.
Действие: для решения задачи необходимо при фильтрации ответов:
- определить, что запрос относится к внешним ИИ‑сервисам (официальные домены и категория «ИИ‑ассистенты»);
- проверить файлы по типу, имени (включая шаблоны на основе регулярных выражений) и контрольным хешам, если используются IOC‑списки;
- проверить размер файлов. Например, офисные файлы более 10 KB;
- проверить критичные для кейса типы файлов;
- проверить ответы на наличие ключевых слов из заранее сформированного справочника, который также содержит такие примеры, как AutoOpen, Document-Open, cmd.exe, macro, enable macros и др.;
- реагировать с помощью действий. Базовые варианты — блокировать запрос либо разрешить его без дальнейшей проверки, при этом уведомить оператора системы. Дополнительно можно настроить только уведомление и автоматическое добавление маркера в журнал событий.
Система отслеживает подозрительные вложения по их расширению и признакам вшитых макросов. Жёсткая блокировка любого такого файла может парализовать нормальную работу, поэтому альтернативный вариант реагирования — пропускать трафик, но оперативно уведомлять администраторов и при необходимости со временем ужесточать политику до полного блокирования.
Встраиваемые двоичные или скриптовые объекты: ответ содержит вложение с исполнителем (exe/ps1/js). Интеграция LLM возвращает ответ, который приходит в браузер как файл для скачивания (через Content-Disposition: attachment; filename=...) или как бинарный ответ (Content-Type: application/octet-stream / application/x-msdownload / и др.). Известны метаданные ответа: заголовки, имя файла, размер и хеш. Риск здесь: скачивание или сохранение исполняемых файлов (.exe, ps1, .bat, .js и т. п.) приводит к запуску вредоносного кода на рабочей станции.
Задача: на уровне прокси блокировать выдачу ответов, которые содержат прикреплённый файл, явно относящийся к исполняемым форматам, или совпадающий с известными IOC-хешами, или превышающий допустимый размер.
Действие: для решения задачи необходимо при фильтрации ответов:
- определить, что запрос относится к внешним ИИ‑сервисам (официальные домены и категория «ИИ‑ассистенты»);
- проверить файлы по типу, имени (включая шаблоны на основе регулярных выражений) и контрольным хешам, если используются IOC‑списки;
- проверить размер файлов. Любое приложение, файл более 1 KB следует проверять;
- проверить критичные для кейса типы файлов (например, application/octet-stream / application/x-msdownload и др.);
- проверить ответы на наличие характерных ключевых слов из заранее подготовленного словаря (например, powershell, invoke-expression, cmd.exe, msiexec, install и др.), используя их как дополнительные индикаторы риска, в том числе в сопровождающем тексте ответа;
- реагировать с помощью действий. Для правила с точными хешами IOC основное действие — блокировать, дополнительное — уведомить и добавить маркер в журнал. Действие для правила без хешей — на старте можно разрешать трафик, но уведомлять администраторов. При необходимости политику можно ужесточить и перевести в режим «Блокировать и уведомлять».
Инлайновый исполняемый контент: ответ возвращает файл типа script/js (MIME) или Content-Disposition с .js/.vbs. Ответ LLM приходит с Content-Type: application/javascript или как вложение с именем *.js / *.vbs / *.hta. Это может быть benign, но также и попытка доставки вредоносного скрипта. Риск: автоматическое встраивание/исполнение скрипта в клиенте (встраиваемый виджет, расширение) приведёт к выполнению вредоносного JS/HTA/WSH.
Задача: блокировать ответы с MIME-типом, указывающим на скриптовый исполняемый контент.
Действие: для решения задачи необходимо при фильтрации ответов:
- определить, что запрос относится к внешним ИИ‑сервисам (официальные домены и категория «ИИ‑ассистенты»);
- проверить файлы по типу, имени (включая шаблоны на основе регулярных выражений) и контрольным хешам, если используются IOC‑списки;
- проверить размер файлов;
- проверить критичные для кейса типы файлов (например, application/javascript, text/javascript, application/x-javascript, text/x-python и др.);
- проверить ответы на наличие характерных ключевых слов из заранее подготовленного словаря. Помимо прочих, он должен включать следующие примеры: eval(, document.write, innerHTML, XMLHttpRequest и др. Их следует использовать как дополнительные индикаторы риска, в том числе в сопровождающем тексте ответа;
- реагировать с помощью действий. На старте можно настроить режим, при котором доступ разрешается без дальнейшей проверки, но при этом событие фиксируется и по нему отправляется уведомление. При необходимости этот режим можно изменить на блокировку доступа с одновременной отправкой уведомления. Также можно создать правило-исключение для разрешённых персон или групп (например, ИТ или ИБ).
Клонирование: фишинговые AI-страницы, запрашивающие токены, ключи. Пользователь переходит на страницу, визуально похожую на официальный интерфейс LLM, где форма просит вставить API-ключ. Прокси видит URL (Host) и тело страницы HTML, но не имеет возможности выполнять сложную семантику — он может сверять домен и ключевые слова. В результате пользователь вводит токены, после чего происходит утечка учётных данных.
Задача: блокировать загрузку страницы, если Host не совпадает с allowlist официальных доменов, а в теле страницы есть брендовые упоминания и поля для ввода ключей.
Действие:
- при обработке ответов нужно учитывать любое назначение ресурсов, но при этом автоматически отсекать результаты, относящиеся к уже известным крупным LLM‑платформам и популярным ИИ‑ассистентам;
- проверить критичные для кейса типы файлов: text/html;
- ответы следует проверять на наличие ключевых слов и признаков, описанных в заранее подготовленном справочнике. Туда входят названия брендов, текстовые призывы ввести данные, элементы для ввода паролей, логинов и API‑ключей, а также явные атрибуты HTML‑форм, задаваемые в виде регулярных выражений;
- при срабатывании такого события система должна блокировать доступ и уведомить пользователя. Также можно настроить правило‑исключение для определённых пользователей или групп (например, сотрудников ИТ или ИБ).
Внешний ответ содержит внутренние адреса, токены, конфигурационные имена (показ служебной информации). LLM или сторонняя платформа в ответах отображает внутренние endpoint’ы (dev., staging., intra., localhost, 10.x.x.x) или токеноподобные строки (ключи), что свидетельствует о потенциальной утечке/перемешивании служебных данных. Угроза — раскрытие внутренних адресов и токенов снижает барьер для сканирования, SSRF/SSIS атак и дальнейшей компрометации.
Задача: блокировать ответы, содержащие внутренние домены, IP-адреса из приватных диапазонов и/или токеноподобные строки.
Параметры правил в SWP:
- проверить назначение ресурса (домен или категорию): к ним относятся домены LLM-интеграторов, такие как api.openai.com, chat.openai.com, perplexity.ai, deepseek.ai, а также ресурсы, отнесённые к категории «ИИ-ассистенты»;
- проверить критичные для кейса файлы через тип идентификации / имя / регулярное выражение (например, (?i).*config.*\.json$ или (?i).*credentials.*\.(json|txt)$ — это усилитель в случае, если есть вложение);
- проверить размер файлов, если есть вложение с вышеуказанными наименованиями файлов;
- проверить критичные для кейса типы файлов. Например, text/html, text/plain, application/json;
- проверить содержимое ответов по заранее сформированному справочнику ключевых слов с использованием RegEx. Например: внутренние домены/поддомены, приватные IP-адреса, токеноподобные строки;
- реагировать с помощью действий. Основное — блокировать. Дополнительные — добавить маркер (их нужно заранее внести в справочник) и отправить уведомление.
