Атаки на извлечение обучающих данных. Почему нейросеть может «проболтаться» о том, чему её учили

Атаки на извлечение обучающих данных. Почему нейросеть может «проболтаться» о том, чему её учили

Компании всё активнее внедряют модели машинного обучения (ML) и большие языковые модели (LLM), обучая их на внутренних данных — ​от клиентских баз до переписок и коммерческих договоров. При этом мало кто задумывается о том, что обученная модель — ​это не «чёрный ящик», скрывающий свои источники, а полноценный актив, из которого при определённых условиях можно восстановить фрагменты исходных данных. Разберёмся, как это работает и что с этим делать.

Общее представление о машинном обучении звучит примерно так: модель обобщает данные и изучает закономерности, а сами исходные примеры бесследно «размазываются» в миллионах параметров. На практике это не совсем так. Если модель переобучена (overfitting), обучена на небольшом или недостаточно разнообразном датасете, либо в её обучающей выборке есть часто повторяющиеся или уникальные записи, она может буквально «запомнить» их и воспроизвести при определённых условиях.

Эта угроза для классических ML-моделей (классификаторов, рекомендательных систем) известна научному сообществу уже более десяти лет. Она получила название Membership Inference Attack (атака на определение принадлежности данных к обучающей выборке). Злоумышленник, не имея прямого доступа к датасету, подаёт модели тестовые примеры, а затем по её поведению (уверенности предсказания, вероятностям на выходе) определяет, участвовала ли конкретная запись в обучении. Казалось бы, безобидный приём. Но если модель обучалась на данных пациентов больницы, сам факт присутствия конкретного человека в обучающей выборке уже технически является утечкой чувствительной информации.

С приходом больших языковых моделей проблема вышла на новый уровень. LLM обучаются на огромных корпусах текстов, включающих код, документы, переписку, а нередко и данные, случайно попавшие в выборку без разрешения правообладателей и должной фильтрации. Исследователи неоднократно демонстрировали, что при определённых запросах модель способна дословно воспроизвести фрагменты обучающих текстов: персональные данные, номера телефонов, приватный код или отрывки авторских произведений. Это и есть атака на извлечение обучающих данных (Training Data Extraction).

Отдельно стоит упомянуть Model Extraction (иногда её называют Model Stealing). Эта атака близка по механике, но направлена не на данные, а на саму модель как продукт. Злоумышленник массово опрашивает публичный API целевой модели и на основе пар «запрос — ​ответ» обучает собственную модель-клон, которая с приемлемой точностью воспроизводит поведение оригинала. Формально никакие данные при этом не «крадутся» — ​присваивается результат многолетней работы команды аналитиков, стоимость сбора и разметки датасета, вычислительные ресурсы, потраченные на обучение, и, по сути, вся конкурентная ценность модели как актива. Самым ярким примером является создание дистиллятов на основе моделей от Anthropic.

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

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

Извлечение обучающих данных нельзя рассматривать исключительно как техническую особенность нейронных сетей. Для организации атака может иметь те же последствия, что и компрометация информационной системы. Помимо раскрытия персональных сведений возможна утечка данных компании. Внутренние документы, код и переписки, использованные для дообучения корпоративного ассистента, потенциально могут быть извлечены пользователем через тщательно сформулированные запросы. А если модель обучал внешний подрядчик и использовал для этого закрытые данные заказчика, вопрос о том, кто несёт ответственность за возможную утечку через готовую модель, требует отдельной проработки в договоре и соглашении о неразглашении (Non-Disclosure Agreement, NDA). Очевидно, что само по себе NDA от подобной атаки не защищает.

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

На этапе подготовки данных:

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

На этапе обучения:

• применять техники Differential Privacy — ​добавление контролируемого шума в процесс обучения. Это математически ограничивает влияние отдельной записи на итоговую модель и снижает риск как атак на членство, так и извлечения данных;
• контролировать степень переобучения модели — ​ранняя остановка обучения снижает склонность модели «запоминать» отдельные примеры.

На этапе эксплуатации:

• ограничивать доступ к модели: закрытые API, аутентификация, лимиты на количество и частоту запросов — ​большинство атак на этом этапе требует множества итераций;
• внедрять мониторинг аномального поведения пользователей API. Резкие всплески похожих по структуре запросов или множественные попытки «продолжить» фрагменты текста могут быть признаком атаки на извлечение;
• фильтровать и модерировать ответы модели на предмет случайного раскрытия персональных данных, номеров карт, ключей и прочих чувствительных паттернов (по аналогии с Data Loss Prevention (DLP)-системами, но применительно к выходу модели);
• регулярно проводить Red Team тестирование собственных моделей на предмет извлечения обучающих данных (так же, как пентест инфраструктуры).

На организационном уровне:

• закреплять в договорах с подрядчиками, обучающими или дообучающими модели на данных заказчика, требования по их безопасной обработке и порядок ответственности за утечки;
• включать оценку рисков извлечения данных в процесс приёмки ML/LLM-решений наравне с традиционными ИБ-проверками (статический анализ (Static Application Security Testing, SAST), динамический анализ (Dynamic Application Security Testing, DAST) безопасности приложений, анализ состава ПО (Software Composition Analysis, SCA)) — ​по аналогии с подходом, применяемым для обычного ПО.

Атаки на извлечение обучающих данных — ​пока не самая обсуждаемая, но вполне реальная угроза, которая становится тем актуальнее, чем активнее бизнес использует собственные сведения для обучения и дообучения моделей. Обученная модель — ​не «чёрный ящик» в смысле безопасности, а ещё один носитель информации, который нуждается в оценке рисков, контроле доступа и мониторинге так же, как и любая база данных или файловое хранилище. Компаниям, работающим с ML/LLM, стоит уже сейчас включать этот риск в модель угроз своих ИИ-систем до того, как ее продемонстрирует кто-то извне.