Отравление обучающих данных

Материал из MachineLearning.

(Различия между версиями)
Перейти к: навигация, поиск
(→Backdoor-атаки)
 
Строка 80: Строка 80:
противника, знающего её механизм: атаки типа clean-label специально конструируются, чтобы
противника, знающего её механизм: атаки типа clean-label специально конструируются, чтобы
проходить фильтры, основанные на согласованности метки и содержимого.
проходить фильтры, основанные на согласованности метки и содержимого.
 +
 +
== Отравление как атака на цепочку поставок ==
 +
 +
Отравление обучающих данных удобно рассматривать как атаку на '''цепочку поставок'''
 +
(''supply chain''), аналогичную внедрению вредоносного кода в стороннюю программную
 +
зависимость. В обоих случаях противник не взламывает целевую систему напрямую, а внедряет
 +
вредоносный компонент выше по течению — в пакет-зависимость либо в обучающую выборку, — и
 +
тот попадает в конечный продукт штатным путём сборки, минуя защиту периметра.
 +
 +
В инженерии безопасной разработки (DevSecOps) происхождение и целостность программных
 +
артефактов контролируют на каждом шаге конвейера: состав зависимостей фиксируют в виде
 +
'''ведомости состава ПО''' (''Software Bill of Materials'', SBOM), автоматически
 +
проверяют его на известные уязвимости, а готовые артефакты '''криптографически подписывают''',
 +
чтобы гарантировать, что в развёртывание попадёт именно проверенная сборка, а не подменённая.
 +
Так известная уязвимость в зависимости сопоставляется с записью в публичной базе (CVE) и
 +
блокирует сборку до её устранения.
 +
 +
Для обучающих данных требуется симметричный, но пока менее зрелый контроль:
 +
* '''происхождение данных''' (''data provenance'') — фиксация источников каждой части
 +
выборки и цепочки её преобразований;
 +
* '''версионирование и контроль целостности''' датасетов — воспроизводимость обучения и
 +
возможность отследить, какие данные попали в конкретную версию модели;
 +
* '''проверка источников''' при сборе из открытых каналов (пользовательская разметка,
 +
веб-краулинг, федеративное обучение), где внесение отравленных примеров не требует доступа
 +
к инфраструктуре.
 +
 +
Принципиальное отличие двух задач в следующем. Скомпрометированную зависимость можно
 +
сопоставить с '''сигнатурой''' известной уязвимости и отклонить автоматически. Отравленный
 +
объект такой сигнатуры не имеет: по отдельности он выглядит как обычный обучающий пример, а
 +
его вредоносность проявляется не в самом объекте, а лишь в '''поведении обученной на нём
 +
модели'''. Поэтому перенос практик безопасности цепочки поставок на машинное обучение
 +
требует не только контроля происхождения данных, но и отдельного класса проверок самой
 +
модели — например, поиска [[#Backdoor-атаки|закладок]] и оценки устойчивости после обучения.
== См. также ==
== См. также ==

Текущая версия

Статья написана с использованием LLM Claude Opus 4.8 и проверена участником Zarina Sibgatullina 18:35, 18 июля 2026 (MSD)


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

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

Содержание

Модель угрозы

Возможности противника характеризуются долей отравленных объектов и степенью контроля над ними:

  • контроль над меткой (label flipping) — атакующий может менять только метки части

объектов;

  • контроль над признаками — можно внедрять произвольно сконструированные объекты

(clean-label-атаки сохраняют визуально корректную метку, что затрудняет обнаружение);

  • доля отравления — обычно единицы процентов выборки; сильные атаки достигают цели при

доле менее 1 %.

По цели различают:

  • атаки доступности (availability) — общая деградация качества модели;
  • целевые атаки (targeted) — ошибка на конкретных объектах при сохранении общего

качества;

  • backdoor-атаки (закладки) — модель работает штатно, но выдаёт нужный атакующему

ответ при появлении заранее выбранного триггера.

Формальная постановка

Пусть модель обучается минимизацией эмпирического риска на выборке D:

\theta^*(D) = \arg\min_{\theta}\; \sum_{(x,y)\in D} \mathcal{L}\big(f_\theta(x),\, y\big).

Противник добавляет к чистой выборке D_{\text{clean}} множество отравленных объектов D_p ограниченного размера и стремится максимизировать свою цель \mathcal{A} (например, потери на целевом объекте или на отложенной выборке):

(1)
\max_{D_p:\, |D_p| \le \varepsilon |D_{\text{clean}}|}\; \mathcal{A}\Big(\theta^*\big(D_{\text{clean}} \cup D_p\big)\Big).

Это двухуровневая (bilevel) задача оптимизации: внутренний уровень — обучение модели на отравленной выборке, внешний — подбор отравления D_p. Её вложенная структура делает точное решение вычислительно трудным, поэтому на практике применяют приближения: атаки на основе градиента по внесённым объектам, влияние-функции (influence functions), градиентное сопоставление (gradient matching).

Backdoor-атаки

Наиболее исследованный частный случай — внедрение закладки. Атакующий добавляет в обучение объекты с фиксированным триггером t (например, небольшой узор в углу изображения), помеченные целевым классом y_t. Обученная модель связывает триггер с целевым классом:

f_\theta(x) = y_{\text{true}}, \qquad f_\theta(x \oplus t) = y_t,

где \oplus — наложение триггера. На чистых данных модель показывает нормальное качество, поэтому закладка не выявляется обычной проверкой на отложенной выборке. Активирует её только знание триггера, которым владеет атакующий.

Защита

Универсальной защиты нет; применяют несколько дополняющих подходов:

  • фильтрация данных — выявление аномальных или влиятельных объектов до обучения

(например, по спектральным сигнатурам скрытых представлений, по активациям);

  • робастное обучение — методы, устойчивые к части испорченных меток

(робастные функции потерь, обрезка по влиянию);

  • дифференциальная приватность как побочная защита — ограничивает влияние отдельного

объекта на модель, что затрудняет и отравление;

  • контроль происхождения данных (data provenance) — организационная мера:

отслеживание источников обучающих данных и цепочки их поставки.

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

Отравление как атака на цепочку поставок

Отравление обучающих данных удобно рассматривать как атаку на цепочку поставок (supply chain), аналогичную внедрению вредоносного кода в стороннюю программную зависимость. В обоих случаях противник не взламывает целевую систему напрямую, а внедряет вредоносный компонент выше по течению — в пакет-зависимость либо в обучающую выборку, — и тот попадает в конечный продукт штатным путём сборки, минуя защиту периметра.

В инженерии безопасной разработки (DevSecOps) происхождение и целостность программных артефактов контролируют на каждом шаге конвейера: состав зависимостей фиксируют в виде ведомости состава ПО (Software Bill of Materials, SBOM), автоматически проверяют его на известные уязвимости, а готовые артефакты криптографически подписывают, чтобы гарантировать, что в развёртывание попадёт именно проверенная сборка, а не подменённая. Так известная уязвимость в зависимости сопоставляется с записью в публичной базе (CVE) и блокирует сборку до её устранения.

Для обучающих данных требуется симметричный, но пока менее зрелый контроль:

  • происхождение данных (data provenance) — фиксация источников каждой части

выборки и цепочки её преобразований;

  • версионирование и контроль целостности датасетов — воспроизводимость обучения и

возможность отследить, какие данные попали в конкретную версию модели;

  • проверка источников при сборе из открытых каналов (пользовательская разметка,

веб-краулинг, федеративное обучение), где внесение отравленных примеров не требует доступа к инфраструктуре.

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

См. также

Литература

  • Biggio B., Nelson B., Laskov P. Poisoning Attacks against Support Vector Machines // ICML. — 2012. — arXiv:1206.6389.
  • Gu T., Dolan-Gavitt B., Garg S. BadNets: Identifying Vulnerabilities in the Machine Learning Model Supply Chain. — 2017. — arXiv:1708.06733.
  • Shafahi A. et al. Poison Frogs! Targeted Clean-Label Poisoning Attacks on Neural Networks // NeurIPS. — 2018. — arXiv:1804.00792.
  • Chen X. et al. Targeted Backdoor Attacks on Deep Learning Systems Using Data Poisoning. — 2017. — arXiv:1712.05526.
  • Steinhardt J., Koh P.W., Liang P. Certified Defenses for Data Poisoning Attacks // NeurIPS. — 2017. — arXiv:1706.03691.
Источник — «http://www.machinelearning.ru/wiki/index.php?title=%D0%9E%D1%82%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BE%D0%B1%D1%83%D1%87%D0%B0%D1%8E%D1%89%D0%B8%D1%85_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85»
Личные инструменты