Кейс: контроль передачи данных в публичные ИИ-сервисы на медиапроизводственном объекте

Технический разбор проекта ЗИКС: постановка задачи, архитектура, состав работ, ограничения

Контекст

Заказчик — крупный медиапроизводственный объект с выстроенной системой информационной безопасности: действует политика конфиденциальности, разграничены уровни доступа, сотрудники знакомы с правилами работы с данными и понимают, какие материалы допустимо передавать во внешние сервисы.

Нейросети при этом используются в рабочих процессах — как и в большинстве компаний сегодня. Это не отклонение и не результат отсутствия регламента: генеративные модели объективно ускоряют подготовку текстов, разбор документации, перевод, работу с кодом. Руководители подразделений, отвечающие за скорость решений, используют их осознанно и не откажутся от инструмента, который даёт преимущество.

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

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

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

Объекты защиты, определённые на старте:

• персональные данные (ФИО, адрес электронной почты, телефон);
• рабочая и проектная документация;
• инженерные схемы и чертежи;
• сетевая топология, IP-адреса, DNS-имена, домены организации;
• конфигурационные файлы.

Базовый стек: InfoWatch Traffic Monitor (DLP) в связке с InfoWatch Device Monitor (перехват на конечных устройствах), модуль IW DD+Vision для сканирования ресурсов.

Архитектура решения

1. Идентификация канала

Первая задача — научить систему отличать обмен данными с ИИ-сервисом от обычного веб-трафика.

Использован двухуровневый подход.

Список известных сервисов. Явное перечисление доменов и адресов популярных чат-ботов: ChatGPT, DeepSeek, Grok, Copilot, Telegram-боты, сервисы на базе YandexGPT. Работает точно, но быстро устаревает: новые площадки появляются постоянно, старые меняют инфраструктуру.

Эвристическое распознавание по паттерну страницы. Система анализирует структуру HTML: наличие поля ввода, характерных элементов интерфейса, кнопок вызова. По совпадению паттерна делается вывод об обмене данными с генеративным ИИ.

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

2. Расшифровка трафика

Без этого этапа контроль содержимого невозможен в принципе. Отраслевой стандарт — установка доверенных сертификатов на клиентские машины с последующим перехватом.

Реализовано через InfoWatch Device Monitor. Параллельно в тестовом режиме прорабатывается перехват по протоколу ICAP — как более масштабируемый и не требующий агентской установки на каждое устройство.

Разделение важно понимать архитектурно: Device Monitor даёт перехват на уровне хоста, ICAP — на уровне прокси. Первый точнее и устойчивее к обходам, второй проще в развёртывании и обслуживании. Для объектов с большим парком и разнородной инфраструктурой оптимальна гибридная схема, но ICAP предъявляет более высокие требования к пропускной способности и настройке прокси.

3. Очистка от служебного шума

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

Совместно с аналитиком вендора составлены правила выделения полезной нагрузки и отсечения служебной части. Результат — сокращение объёма избыточных событий и снижение нагрузки на систему.

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

Состав настроенных политик

Контроль направлений

Фиксируется как исходящий трафик — то, что сотрудник отправляет в ИИ-сервис, так и ответы, которые система возвращает пользователю. Ответ модели — тоже данные, попадающие в корпоративную среду.

Объекты защиты и события

Сетевая идентификация. Ввод или копирование IP-адресов, DNS-имён, доменов организации в чат-бот. Политики созданы, ведётся доработка и тестирование совместно с аналитиком.

Персональные данные. Объект защиты «Базы данных»: ФИО, имя и фамилия, адрес электронной почты, номер телефона. Политика выстроена с охватом всех каналов, кроме электронной почты.

Инженерные схемы. Настроена индексация событий по передаче схем во внешнюю среду. Статус — частично выполнен: требуются ВКС и включение OCR, по оценке для адаптации под объект потребуется участие лингвиста.

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

Корпоративное облако (WebDAV). Выявлена потенциальная точка утечки: файл можно выгрузить с рабочего компьютера и скачать с личного устройства. Настроено сканирование ресурса модулем IW DD, ведётся проработка с техподдержкой вендора.

Работа с событиями и точностью срабатываний

Отдельный блок проекта — не настройка «поймать», а настройка «поймать нужное».

Исключение ложных событий из индексирования. Выполнено совместно с аналитиком вендора.

Исключение «мусорных» событий веб-активности. Часть событий находилась в серой зоне: из-за отсутствия модуля Activity Monitor их аналитика была невозможна, при этом они создавали избыточную нагрузку. Исключены.

Файлообменники. Устранена ситуация, когда при загрузке и выгрузке файлов события либо не формировались, либо не попадали под политику. Вопрос решён совместно с ЗИКС и вендором в ходе выезда аналитика.

Сохранение событий IW DD. Настроено только по политикам — сокращает объём хранимых данных и делает хранилище пригодным для расследования.

Ограничения и открытые вопросы

Технический разбор невозможен без перечисления того, что не решается в рамках текущей архитектуры.

Агентский и безгентовый перехват дают разное покрытие. Без ICAP часть сценариев — в частности, работа с облачным ресурсом по WebDAV — остаётся вне полного контроля. Это ожидаемо и учтено в плане развития.

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

Распознавание по паттерну страницы имеет ограничения. Сервис без выраженного поля ввода — встроенный в другое приложение или реализованный через API — может не определяться эвристикой. Компенсируется списком доменов и требует периодического пересмотра правил.

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

Ложные срабатывания полностью не устраняются. Задача оптимизации — снизить их до уровня, при котором служба безопасности работает с событиями, а не с шумом. Это процесс, а не разовый результат.

Итог проекта

Почему это важно

Канал существует независимо от того, признаёт его компания или нет. Сотрудники используют нейросети, потому что это эффективно. Вопрос не в том, запрещать или разрешать, а в том, видит ли компания, что уходит наружу.

Стандартный DLP не настроен под ИИ-канал из коробки. Требуется отдельная работа: идентификация сервисов, расшифровка, правила выделения полезной нагрузки, политики по специфическим объектам защиты. Простая установка решения результата не даёт.

Качество важнее охвата. Основной объём трудозатрат ушёл не на расширение перечня политик, а на очистку событий и точность срабатываний. Система, которая «видит всё», на практике не используется.

Перечень объектов защиты специфичен для инфраструктурных объектов. Сетевая топология, IP-адреса, DNS-имена и конфигурационные файлы — категории, которые типовые DLP-шаблоны часто не покрывают, хотя для производственных и медиаобъектов они критичны.

Контроль даёт основу для работы с причинами. Когда видно, какие подразделения и какие категории данных чаще попадают в события, становится понятно, где правило сформулировано недостаточно ясно, а где сотруднику не хватает разрешённого внутреннего инструмента. Это позволяет корректировать политику точечно вместо тотальных запретов.

Практические выводы для похожих проектов

1. Начинать с перечня защищаемых данных, а не с настройки политик. Без письменно зафиксированного списка объектов защиты проект превращается в бесконечную настройку «на всё».
2. Не ставить целью запрет. Он вытесняет использование в теневую зону и лишает компанию информации о происходящем.
3. Не полагаться только на реестр доменов. Эвристика по паттерну страницы расширяет покрытие и снижает зависимость от обновлений списка.
4. Планировать очистку от служебного трафика отдельным этапом с собственным бюджетом времени.Это не «доработка после внедрения», а обязательная часть.
5. Оценивать ICAP заранее. Если нужен контроль облачных ресурсов и безагентовые сценарии — закладывать переход в основной план, а не как «будущий проект».
6. Закладывать взаимодействие с вендором в сроки. Часть требуемого функционала может отсутствовать на момент старта.
7. Учитывать потребность в OCR и отраслевой адаптации правил. Схемы и чертежи требуют дополнительной настройки, иногда — участия лингвиста.
8. Не забывать организационную часть. Политика использования ИИ, уведомление сотрудников, регламент реагирования на инциденты. Технический контроль без этого создаёт риски для самой компании.

Проект выполнен Компанией ЗИКС. Название объекта и заказчика не раскрываются.