Безопасность и приватность

Назначение

Почему приватность и безопасность определяют, получат ли системы машинного обучения широкое распространение и доверие общества?

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

Цели обучения

• Отличать безопасность от приватности в ML-системах с помощью формальных определений, моделей угроз и количественных компромиссов
• Извлекать из исторических нарушений (Stuxnet, Jeep Cherokee, Mirai) принципы безопасности, применимые к распределенной ML-инфраструктуре
• Анализировать специфичные для ML векторы атак: кражу моделей, отравление данных, состязательные примеры и уязвимости аппаратуры
• Задавать входные параметры учетчика приватности (privacy accountant) и оценивать заявленные бюджеты приватности с учетом выборки, композиции и данных о полезности
• Проектировать многоуровневые архитектуры защиты, охватывающие защиту данных, безопасность модели, мониторинг во время выполнения и механизмы аппаратного доверия
• Оценивать примитивы аппаратного доверия для ML-нагрузок с количественным анализом накладных расходов
• Применять модель зрелости для построения архитектур безопасности, соответствующих конкретным моделям угроз

Расширенная поверхность атаки

Безопасность и приватность не являются запоздалой мыслью. Это структурные требования, которые необходимо закладывать в каждый уровень распределенного ML-стека. Стек парка делает это обязательство явным: когда парк, распределенная логика и инфраструктура обслуживания становятся рабочими, уровень управления должен защищать систему, чтобы глобальный парк нельзя было захватить, отравить или использовать противникам.

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

Эксплуатационные платформы управляют сотнями моделей в распределенной инфраструктуре, и такой глобальный охват создает обширную поверхность атаки. Распределенные системы обучения, граничные развертывания и многопользовательские платформы обслуживания вносят уязвимости, которых нет в системах на одной машине. Протоколы синхронизации градиентов создают каналы утечки и манипуляции. Федеративная агрегация открывает обновления модели для перехвата и атак на инференс. Многопользовательская инфраструктура обслуживания создает возможности для извлечения модели и атак по побочным каналам. Каждое архитектурное решение, которое обеспечивает масштаб, создает и уязвимости, требующие системной защиты.

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

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

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

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

Определение безопасности

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

Определение: безопасность

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

1. Значимость: отказы безопасности действуют на обоих уровнях одновременно. На инфраструктурном уровне кража крупной проприетарной модели означает прямую потерю интеллектуальной собственности. На алгоритмическом уровне извлечение модели через запросы в режиме черного ящика может восстановить границы решений или выделить функционального приближения развернутой модели за малую долю стоимости обучения («Кража модели» оценивает бюджеты запросов), обходя инвестиции и конкурентное преимущество. Любой из этих отказов обесценивает деловую ценность члена $O$ (эксплуатация модели) в «железном законе».
2. Различие: в отличие от общей устойчивости, которая касается стохастического сдвига распределения из-за непреднамеренных изменений среды, безопасность имеет дело с умышленными состязательными угрозами, когда злоумышленник активно максимизирует вероятность целевого отказа. Поэтому требуется анализ наихудшего, а не среднего случая.
3. Распространенное заблуждение: часто полагают, что традиционная ИТ-безопасность (межсетевые экраны, управление доступом, шифрование) достаточна для защиты ML-систем. Однако ML вводит алгоритмическую поверхность атаки, ортогональную инфраструктуре: корректно аутентифицированный API-запрос, содержащий состязательный вход или инъекцию промпта, обходит все сетевые средства защиты и манипулирует поведением модели через ее собственные обученные функции.

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

Определение приватности

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

Определение: приватность

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

1. Значимость: она ограничивает риск раскрытия обучающих данных и пользовательских входов. Обучение с дифференциальной приватностью вводит компромисс между полезностью и приватностью: более жесткие границы приватности обычно требуют большего шума или больше данных, что может увеличить совокупные операции $(O)$, необходимые для достижения целевой полезности.
2. Различие: в отличие от конфиденциальности, которая сосредоточена на управлении доступом, приватность в ML сосредоточена на рисках вывода: на способности пользователя, оператора или противника вывести чувствительные факты или восстановить обучающие примеры по выходным данным модели, ее весам или повторным выпускам.
3. Распространенное заблуждение: часто считают, что удаления имен (деидентификации) достаточно для приватности. На деле нейронные сети — это механизмы корреляции, которые могут непреднамеренно запоминать и раскрывать уникальные фрагменты чувствительных данных через многомерные закономерности.

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

Дифференциальная приватность дает одну гарантию на уровне механизма, но сама по себе не обеспечивает приватность на всем жизненном цикле. Системе по-прежнему нужно минимизировать сбор данных, обосновать допустимость их использования, обеспечивать контроль доступа, ограничивать срок хранения, выполнять обязательства по удалению и не допускать утечки исходных входов или чувствительных выходов через журналы и кэши. Эти меры отвечают на вопросы, на которые не отвечает оценка $(ϵ,\delta )$: стоило ли собирать данные, кто может их использовать, как долго сохраняются производные артефакты и какие копии нужно удалить. Поэтому производственная приватность сочетает формальный учет с мерами управления данными на этапах сбора, обучения, обслуживания, телеметрии и вывода из эксплуатации.

Сценарий: стоимость дифференциальной приватности

Задача: рассмотрим вычисление средней зарплаты 1000 сотрудников при гарантии бюджета приватности $ϵ=$ 1. Зарплаты лежат в диапазоне от $0 до $200,000. Сколько шума должен добавить механизм?

Расчет:

1. Чувствительность $(\Delta f)$: максимальное изменение суммы, которое может внести один человек, составляет $200,000.
2. Бюджет приватности $(ϵ)$: 1.
3. Масштаб шума Лапласа $(b)$: стандартный механизм добавляет симметричный случайный шум, типичная величина которого равна чувствительности, деленной на бюджет приватности (раздел «Механизмы шума» следующей части главы разбирает механизм полностью), поэтому $b=\Delta f/ϵ=$ $200,000 / 1 = $200,000.
4. Влияние на среднее: шум оценки среднего возникает из шума, добавленного к сумме, величина которого составляет примерно $200,000.

• Шум на одного человека (в среднем) = $200,000 / 1000 = $200.

Системный вывод: защита одного выброса вносит ошибку $200 в среднее. Для набора данных с $n_{\text{records}}=$ 100 ошибка вырастает до $2 000. Дифференциальная приватность может делать оценки неустойчивыми при малом $n_{\text{records}}$; лучше всего она работает, когда набор данных достаточно велик, чтобы $1/n_{\text{records}}$ гасил добавленный шум. Этот расчет для центральной дифференциальной приватности дает интуицию чувствительности для обучения ML, но не является учетом для стохастического градиентного спуска с дифференциальной приватностью (DP-SGD). DP-SGD обрезает поэкземплярные градиенты, добавляет гауссовский шум к ограниченной агрегированной сумме и учитывает подвыборку и композицию по шагам обучения; его мультипликатор шума нельзя получить повторным использованием однократного отношения Лапласа $\Delta f/ϵ$.

Дифференциальная приватность количественно оценивает статистическую цену защиты отдельных записей, но производственные ML-платформы сталкиваются со второй, ортогональной осью издержек. Когда несколько арендаторов разделяют кластер GPU, данные и состояние модели каждого арендатора должны быть изолированы от контекста выполнения всех остальных. Такая изоляция требует разбиения физических ресурсов (SRAM, строки кэша, вычислительные срезы), а не добавления статистического шума, и накладные расходы измеряются потерей пропускной способности, а не добавленной дисперсией. Приложение «Основы парка» собирает базовые значения пропускной способности на ускоритель и цифры разбиения, относительно которых измеряется этот налог на изоляцию, чтобы читатель мог пересчитать потерю для конкретной конфигурации парка.

Перспектива: налог на безопасную многопользовательскую работу

Команда платформы размещает две модели на одном H100, используя Multi-Instance GPU (MIG) для аппаратной изоляции. На выделенном GPU модель выдает 1000 токенов в секунду. После включения безопасного разбиения она выдает 850 токенов в секунду. Разница между этими величинами и есть цена безопасности в производительности.

Изоляция требует выделенных аппаратных ресурсов (SRAM, кэш) и добавляет накладные расходы на переключение контекста. Потеря пропускной способности составляет 1000 токенов − 850 токенов = 150 токенов в секунду, а налог на изоляцию равен (150 токенов / 1000 токенов) = 15 процентов.

Системный вывод: безопасность расходует емкость. Аппаратное разбиение для размещенной модели в этом примере стоит 15 процентов сырой пропускной способности GPU. В парке машинного обучения многопользовательский режим — экономическая необходимость, но он не бесплатен. Инженеры должны решить, оправдывает ли чувствительность данных потерю этой доли емкости парка. Для публичных API этот «налог» — одна из цен снижения риска того, что промпт или активации одного арендатора просочатся в контекст выполнения другого.

Безопасность и приватность: различия

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

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

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

Взаимодействие безопасности и приватности и компромиссы

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

Перспектива: компромисс между приватностью и полезностью

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

Однако они могут и вступать в противоречие. Такие методы, как дифференциальная приватность, снижают риски запоминания, но могут уменьшить полезность модели. Аналогично шифрование повышает безопасность, но может снижать прозрачность и возможность аудита, усложняя соблюдение требований приватности. Проектировщики должны рассматривать эти компромиссы в целом.

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

Уроки из нарушений безопасности

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

Случай из практики: тепловая карта, раскрывшая привычки (2018)

Контекст: в конце января 2018 года глобальная тепловая карта активности Strava — агрегированная визуализация, построенная по GPS-трекам примерно 27 миллионов пользователей и около 1 миллиарда загруженных активностей, — была представлена как обезличенные данные о перемещениях на высоком уровне (Russell, 2018).

Механизм: в разреженных средах агрегирование не сохранило приватность: яркие беговые маршруты в сирийской пустыне совпали с передовыми позициями вооруженных сил США, раскрыв периметры секретных баз, маршруты снабжения и схемы патрулирования.

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

Исправление: Strava пересмотрела продукт: улучшила зоны приватности, ограничила видимость тепловой карты по умолчанию и сделала включение в карту строго добровольным.

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

Компрометация цепочки поставок: Stuxnet

В 2010 году червь Stuxnet¹ проник на иранский ядерный объект в Натанзе, связав четыре уязвимости нулевого дня² — оружие стоимостью в миллионы долларов. Он попадал в системы Windows через зараженные USB-носители, а затем распространялся на программное обеспечение Siemens Step7, которым программировались программируемые логические контроллеры (PLC) в сети с воздушным зазором³ (Farwell и Rohozinski, 2011). Вместо того чтобы сразу вывести центрифуги из строя, он менял параметры управления, одновременно передавая операторам нормальную телеметрию: систему можно было скомпрометировать, но она выглядела исправной. Параллель с ML точна: злоумышленнику, который отравляет обучающие данные или внедряет модель с закладкой в доверенный репозиторий, не нужно ронять сервер инференса; незаметный сдвиг границы решений модели достигает того же эффекта и при этом обходит стандартный мониторинг.

Цепочки поставок ML, которые принимают публичные пакеты, наборы данных, веса моделей или прошивки, сталкиваются с четырьмя аналогичными векторами: скомпрометированные зависимости (вредоносные пакеты в репозиториях PyPI и conda), отравленные наборы данных на публичных платформах, модели с закладками в репозиториях моделей и подмененные прошивки ускорителей. Высоконадежные развертывания часто сочетают криптографическую подпись артефактов моделей, неизменяемые журналы происхождения данных и кода для обучения, автоматическое сканирование на закладки перед развертыванием и контролируемое управление зависимостями в средах обучения с воздушным зазором. Рисунок сопоставляет эти параллели между цепочкой атаки Stuxnet и уязвимостями цепочки поставок ML.

Stuxnet: цепочка атаки была направлена на PLC через уязвимости программного обеспечения Windows и Siemens, позволив цифровому вредоносному ПО повредить физическую инфраструктуру. Системы ML сталкиваются с аналогичной проблемой границы доверия, когда скомпрометированы обучающие данные, зависимости или веса модели.

Недостаточная изоляция: взлом Jeep Cherokee

Исследователи безопасности удаленно взломали двигатель, трансмиссию и тормозные системы Jeep Cherokee, использовав уязвимость в подключенной к интернету развлекательной системе Uconnect, и сделали это без физического доступа к автомобилю (Miller и Valasek, 2015; Miller, 2019). Архитектурным дефектом была недостаточная изоляция: развлекательная система делила сетевой путь с контроллерами шины CAN (controller area network), критичными для безопасности. Инцидент стал первым в истории автомобильной промышленности отзывом из-за кибербезопасности: он затронул 1,4 миллиона автомобилей⁴ и побудил Национальное управление безопасности дорожного движения США (NHTSA)⁵ выпустить необязательные рекомендации по лучшим практикам кибербезопасности автомобилей.

Видеоматериал: Jeep Cherokee Hack (WIRED)

Урок для ML прямой: любое развертывание, в котором API инференса делит сетевой путь с исполнительными механизмами, критичными для безопасности (модели восприятия беспилотных автомобилей, детекторы аномалий промышленного IoT, диагностические системы медицинских устройств), наследует тот же класс уязвимостей. Защита требует строгой сегментации сети между плоскостями инференса и управления, криптографической аутентификации API, изолированного выполнения моделей с минимальными системными привилегиями и безопасных значений по умолчанию, которые возвращают исполнительные механизмы в безопасное состояние, когда ML-компоненты обнаруживают аномалии или теряют связь.

Превращение конечных устройств в оружие: ботнет Mirai

В 2016 году ботнет Mirai⁶ скомпрометировал более 600 000 IoT-устройств (камер, видеорегистраторов и маршрутизаторов с заводскими учетными данными по умолчанию) и направил их на DDoS-атаку⁷ мощностью 1,2 Тбит/с, которая нарушила работу крупной интернет-инфраструктуры в США (Antonakakis et al., 2017). Атака продемонстрировала количественный порог: когда даже небольшая доля сетевых устройств поставляется с паролями по умолчанию, совокупность становится инфраструктурой, пригодной для вооружения.

Видеоматериал: Mirai Botnet (Vice News)

Для граничных ML-развертываний угроза усиливается. Скомпрометированные ML-устройства дают возможности, выходящие за пределы сырой пропускной способности: умные камеры могут выкрадывать базы данных распознавания лиц, голосовые ассистенты — извлекать расшифровки разговоров, а любое устройство, участвующее в федеративном обучении, становится источником отравленных обучающих данных. Защита требует граничной безопасности по модели «нулевого доверия»: уникальных для каждого устройства ключей через аппаратные модули безопасности (HSM), безопасной загрузки с криптографической проверкой, TLS 1.3 или одобренного организацией актуального эквивалента для связи с ML API и поведенческого мониторинга для выявления аномальных шаблонов инференса.

Вместе инциденты Stuxnet, Jeep и Mirai выявляют общую структуру: злоумышленник использует конкретную поверхность в конвейере системы (цепочку поставок, границу сетевой изоляции или учетные данные конечного устройства) способом, который разработчики системы не учитывали как угрозу. Инженерия безопасности превращает эти инциденты в формальные модели угроз для каждой поверхности ML-систем, в экономику атак, которая определяет, какие угрозы реализуемы, и в защитные меры, стоимость которых можно соотнести с тяжестью угрозы.

Системный анализ угроз и оценка рисков

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

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

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

Система приоритизации угроз

Даже при строгих правовых рамках, таких как Общий регламент ЕС по защите данных (GDPR),⁸ ресурсы безопасности всегда ограничены. Матрица приоритетов, построенная по вероятности и воздействию, превращает модель угроз в решение о распределении ресурсов: автоматизировать защиту от угроз, которые одновременно вероятны и опасны, готовиться к редким, но серьезным сбоям и не тратить дефицитное инженерное время на средства контроля с низкой ценностью.

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

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

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

Матрица приоритетов угроз: матрица $2\times 2$ классифицирует угрозы ML по вероятности и воздействию. Угрозы с высокой вероятностью и высоким воздействием требуют автоматизированной защиты; угрозы с меньшей вероятностью, но высоким воздействием, оправдывают подготовку в высокоценных развертываниях; а угрозы с высокой вероятностью и меньшим воздействием часто требуют ограничения частоты запросов и средств контроля API.

Моделирование угроз для ML-систем

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

Анализ поверхности атаки

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

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

• Точки сбора: исходные данные попадают в систему через журналы приложений, датчики, формы, API или загрузки.
• Системы хранения: обучающие корпуса находятся в объектных хранилищах, хранилищах данных, хранилищах признаков или реестрах наборов данных.
• Конвейеры предобработки: задания преобразования нормализуют, фильтруют, дополняют и объединяют исходные входы перед обучением.
• Генерация меток: системы ручной разметки, правила слабой разметки и разметка с помощью моделей создают цели, на которых учится модель.
• Системы версионирования и происхождения: манифесты наборов данных и записи о происхождении определяют, какой снимок данных войдет в релиз.

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

Поверхность атаки охватывает данные, выученное поведение модели, интерфейсы и инфраструктуру.

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

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

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

Классификация векторов угроз

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

Тип доступа определяет, сколько информации защита должна скрывать:

• Доступ «черного ящика»: у злоумышленника есть только взаимодействие «вход — выход» с моделью через API. Это позволяет извлекать модель через прогнозирующие API (Tramèr et al., 2016) и проводить состязательные атаки на основе запросов или переноса (Papernot et al., 2016), но ограничивает точность атаки.
• Доступ «серого ящика»: у злоумышленника есть частичные знания, например об архитектуре модели, процедуре обучения или характеристиках набора данных. Это позволяет проводить более целенаправленные атаки, например с помощью переносимых состязательных примеров.
• Доступ «белого ящика»: у злоумышленника есть полные знания о параметрах модели, архитектуре и обучающих данных. Это позволяет проводить прямые атаки на основе градиентов (Goodfellow et al., 2015) и, если файлы модели доступны, напрямую копировать веса.

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

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

Момент атаки определяет, где защита еще может действовать:

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

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

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

Система стратегий защиты

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

Ни один защитный механизм не обеспечивает полной защиты. Принцип эшелонированной защиты требует нескольких независимых уровней, так чтобы компрометация одного уровня не давала полного доступа к системе. Для ML-систем это означает сочетание валидации данных с методами устойчивости модели, контроля доступа с возмущением выходов, а программных защит — с аппаратными механизмами безопасности.

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

• Ограничить возможности API: открывать только необходимую функциональность.
• Ограничить информацию в выходе: усекать показатели уверенности и другие высокодетальные выходные данные, которые раскрывают поведение модели.
• Шифровать хранимые активы: защищать модели и обучающие данные в состоянии покоя.
• Изолировать инфраструктуру: отделять системы обучения от систем инференса, чтобы предотвратить горизонтальное перемещение злоумышленника.
• Аудировать доступ: использовать строгие разрешения и журналирование, чтобы чувствительные действия можно было отнести к конкретному субъекту.

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

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

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

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

Таблица дает конкретное соответствие между каждым уровнем поверхности атаки и защитными механизмами и методами обнаружения, которые ее защищают. Защита данных проверяет происхождение, защита модели охраняет выученное поведение и веса, защита API регулирует раскрытие запросов, а защита инфраструктуры закрепляет доверие во время выполнения.

Соответствие защит поверхностям атаки: каждый уровень поверхности атаки ML-системы требует собственных защитных механизмов и методов обнаружения. Эффективная безопасность объединяет защиту на всех уровнях и сохраняет возможности обнаружения, способные выявить атаки, которые обходят превентивные средства контроля.

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

Контрольные вопросы: моделирование угроз

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

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

Определить, является ли аномальный шаблон запросов безвредным пользователем или активной атакой извлечения, — ключевая задача оценки угроз для ML. Структурированная модель угроз дает аналитическую основу; следующий вопрос — как конкретные векторы атак используют каждый уровень, чтобы скомпрометировать целостность и конфиденциальность модели.

Векторы атак, специфичные для моделей

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

Эти атаки охватывают весь жизненный цикл ML и напрямую соответствуют классам модели угроз: угрозы конфиденциальности модели нацелены на этапы развертывания и инференса через кражу модели, угрозы целостности обучения приходятся на сбор данных и разработку модели через атаки отравлением, а угрозы устойчивости инференса эксплуатируют работу во время выполнения через состязательные примеры.¹⁰ Понимание того, когда происходит каждая атака, подсказывает, где развертывать соответствующие защиты. Отравление данных¹¹ компрометирует сам процесс обучения, тогда как кража модели и состязательные атаки направлены на развернутую систему. Каждая категория требует собственных стратегий защиты, согласованных с анализом поверхности атаки в разделе «Моделирование угроз для ML-систем».

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

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

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

Взгляд на жизненный цикл рассматривает модели как активы, которые нужно защищать, но он также показывает, почему те же активы могут стать частью стратегии атаки. Предобученные модели, особенно крупные генеративные или дискриминативные сети, можно адаптировать для автоматизации таких задач, как генерация состязательных примеров, синтез фишингового контента¹² или подрыв протоколов. Модели с открытым кодом или публично доступные модели можно дообучить для вредоносных целей, включая выдачу себя за другого, слежку или обратное проектирование защищенных систем. Глава возвращается к этой проблеме двойного назначения после того, как установлены базовые классы угроз, начиная с атак, которые крадут ценность модели.

Кража модели

Определение: извлечение модели

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

1. Значимость: успешное извлечение часто стоит на порядки дешевле исходного обучения. Опубликованные демонстрации восстанавливали модели логистической регрессии, нейронные сети и деревья решений из публичных API машинного обучения с высокой точностью и умеренными затратами на запросы (Tramèr et al., 2016), а более поздние работы восстановили компоненты больших языковых моделей, включая развертывания OpenAI (Carlini et al., 2024), используя только публичный доступ к запросам. Пример извлечения BERT в этом разделе иллюстрирует ту же динамику на трансформерной модели при стоимости запросов в десятки долларов.
2. Различие: в отличие от прямой кражи файлов модели (которая требует проникновения на уровень хранения) и инверсии модели (которая использует выходные данные модели, чтобы восстановить образцы обучающих данных, а не саму модель), поверхностью атаки при извлечении является интерфейс запросов к модели. Поэтому это угроза, с которой по построению сталкивается любой развернутый ML-сервис, если модель доступна.
3. Распространенное заблуждение: часто считают, что одного лишь ограничения частоты запросов достаточно как защиты. Злоумышленник, готовый отправлять запросы медленно, распределять их между учетными записями или мириться с окном атаки в несколько месяцев, все равно может извлечь модель, если API дополнительно не снижает объем информации на запрос, не обнаруживает систематическое зондирование и не назначает цену за запросы так, чтобы извлечение стало экономически нерациональным.

Первая категория специфичных для модели угроз направлена на конфиденциальность. Угрозы конфиденциальности модели возникают, когда противники получают доступ к параметрам, архитектуре или поведению обученной модели по выходным данным (Oliynyk et al., 2023). Такие атаки могут подорвать экономическую ценность систем машинного обучения, позволить конкурентам воспроизвести проприетарную функциональность или раскрыть частную информацию, закодированную в весах модели.

Такие угрозы возникают в самых разных условиях развертывания: публичные API,¹³ облачные сервисы, движки инференса на устройствах и общие репозитории моделей.¹⁴ Интерфейсы предсказаний могут утекать достаточно сигнала, чтобы восстановить функциональность модели (Tramèr et al., 2016; Oliynyk et al., 2023), а выходные данные классификаторов могут раскрывать значимую информацию об обучающих наборах или выученной структуре (Ateniese et al., 2015). Небезопасные форматы сериализации¹⁵ и недостаточный контроль доступа создают отдельный риск безопасности артефактов: они могут напрямую раскрыть файл модели или пакет развертывания, а не только ее наблюдаемое поведение.

Серьезность этих угроз подчеркивают громкие судебные дела, которые показали стратегическую и экономическую ценность моделей машинного обучения. Например, бывшего инженера Google Энтони Левандовски обвиняли в краже проприетарных разработок Waymo, включая критические компоненты технологии беспилотных автомобилей, до того как он основал конкурирующий стартап (The New York Times, 2017). Такие случаи показывают, что инсайдерские угрозы способны обходить технические защиты и получать доступ к чувствительной интеллектуальной собственности.

Последствия кражи модели выходят за рамки экономического ущерба. Украденные модели можно использовать для извлечения чувствительной информации, воспроизведения проприетарных алгоритмов или для дальнейших атак. Экономический эффект может быть существенным: исследования оценивают, что отдельные аспекты больших языковых моделей можно приблизить систематическими API-запросами за стоимость на порядки ниже исходного обучения, хотя полное воспроизведение модели остается сложным в экономическом и техническом отношении (Tramèr et al., 2016; Carlini et al., 2024). Например, конкурент, получивший украденную рекомендательную модель крупной торговой платформы, может узнать о поведении клиентов, бизнес-аналитике и встроенных коммерческих секретах. Эти знания также можно использовать для проведения атак инверсии модели,¹⁶ когда злоумышленник пытается вывести закрытые сведения об обучающих данных модели (Fredrikson et al., 2015).

При атаке инверсии модели противник запрашивает модель через легитимный интерфейс, например публичный API, и наблюдает за ее выходами. Анализируя показатели уверенности или вероятности на выходе, злоумышленник может оптимизировать входы, чтобы восстановить данные, похожие на обучающий набор модели. Например, модель распознавания лиц, которую используют для безопасного доступа, можно манипулировать так, чтобы она раскрыла статистические свойства фотографий сотрудников, на которых она обучалась. Похожие уязвимости продемонстрированы в исследованиях набора данных Netflix Prize,¹⁷ где исследователи выводили индивидуальные предпочтения в фильмах из обезличенных данных (Narayanan и Shmatikov, 2006).

Рисунок разделяет две цели кражи, для которых нужны разные средства контроля. Точная кража артефакта — это сбой безопасности хранилища, реестра или устройства: злоумышленник получает файл модели или артефакт развертывания, извлекает веса, архитектуру или гиперпараметры и может восстановить исходную модель, не оплачивая стоимость обучения. Приближенная поведенческая кража — сбой безопасности интерфейса: злоумышленник запрашивает развернутый API, записывает метки, логиты, эмбеддинги или показатели уверенности и обучает суррогатную модель, которая приближает исходное поведение. Точная кража требует подписи артефактов, шифрования, контроля доступа и безопасных путей развертывания; приближенная — ограничения выходов, контроля частоты, аудита запросов, водяных знаков и ценообразования, которые делают извлечение экономически невыгодным. Конкретные архитектурные уязвимости зависят от типа модели: более глубокие сети и архитектуры на основе внимания открывают иные поверхности атаки, чем более простые сверточные или рекуррентные конструкции.

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

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

Пример: извлечение модели BERT

Сценарий: проприетарные языковые модели, развернутые за публичными API инференса, возвращают клиентским запросам полные векторы вероятностей и показатели уверенности (Krishna et al., 2020).

Диагноз: запрос к API 2 миллионами синтетических входов (стоимостью около $50) дал достаточно информативных логитов, чтобы обучить модель-ученика, достигшую поведенческого соответствия выше 97 процентов с атакуемой моделью BERT.

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

Точная кража модели

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

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

• Выученные параметры: веса и смещения позволяют злоумышленнику воспроизвести функциональность модели, не оплачивая исходную стоимость обучения.
• Настроенные гиперпараметры: скорость обучения, размер пакета и настройки регуляризации сокращают объем экспериментов, необходимых для достижения того же качества.
• Детали архитектуры: последовательности слоев, функции активации и схемы связей раскрывают проектные решения, которые формируют поведение модели; их можно восстановить через атаки по побочным каналам,¹⁸ обратное проектирование или анализ наблюдаемых выходов.

Чем больше такой информации раскрывает API или артефакт, тем меньше работы остается злоумышленнику.

Проектировщики систем должны учитывать эти риски, отделяя безопасность артефактов от безопасности интерфейсов. Контроли артефактов защищают файлы моделей, записи реестра и пакеты развертывания; контроли интерфейсов ограничивают API, снижают точность выходов, аудируют шаблоны запросов и назначают цену или ограничивают частоту доступа, так что поведенческое извлечение становится экономически труднее (Tramèr et al., 2016; Oliynyk et al., 2023).

Приближенная кража модели

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

Такой вид кражи часто нацелен на модели, развернутые как сервисы, где модель доступна через API или встроена в пользовательское приложение. Многократные запросы к модели и запись ее ответов позволяют злоумышленнику обучить собственную модель, имитирующую поведение исходной. Этот процесс, который часто называют дистилляцией модели¹⁹ или моделированием по принципу knockoff, позволяет получить сопоставимую функциональность без доступа к проприетарным внутренностям исходной модели (Orekondy et al., 2019).

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

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

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

Одна из демонстраций приближенной кражи модели извлекает внутренние компоненты языковых моделей типа «черного ящика» через публичные API. В своей работе Carlini et al. (2024) показывают, как восстановить итоговую матрицу проекции эмбеддингов моделей OpenAI ada и babbage, а также определить скрытую размерность (и оценить стоимость полного восстановления матрицы) для gpt-3.5-turbo, используя только публичный доступ к API. Используя низкоранговую структуру слоя выходной проекции и тщательно составленные запросы, исследователи восстановили скрытую размерность модели и для меньших моделей воспроизвели матрицу весов с точностью до аффинных преобразований.

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

Эмпирические результаты в таблице показывают извлечение параметров выходной проекции меньших моделей со среднеквадратичными ошибками вплоть до $10^{-4}$, тогда как строки для GPT-3.5 содержат восстановление размерности и оценочные стоимости восстановления, а не реализованное извлечение матрицы весов. Эти результаты важны для проектирования систем: безобидные функции API, такие как возврат top-$k$ логитов, могут стать существенными каналами утечки, если их не контролировать жестко.

Стоимость кражи модели: злоумышленники могут восстановить внутреннюю информацию о модели через общедоступные API. Столбец «Стоимость» содержит две величины: стоимость восстановления размерности и стоимость извлечения полной матрицы весов. Для моделей OpenAI ada и babbage реализованное извлечение весов выходной проекции дает низкую среднеквадратичную ошибку при менее чем $4\cdot 10^6$ запросах и оценочной стоимости от $1 до $12. Строки для GPT-3.5 содержат результаты восстановления размерности и оценочные стоимости полного восстановления, а не реализованное извлечение матрицы весов.

Защиты от извлечения модели

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

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

Эти рычаги действуют вместе, потому что экономика извлечения зависит от битов на запрос, объема запросов, цены и заметности злоумышленника.

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

$$\text{alert}(\text{user})=\{\begin{array}{ll}1& \text{если }{q}_{\text{daily}}>10000\text{ или }{q}_{\text{hourly}}>2000\\ 0& \text{иначе}\end{array}$$

где $q_{\text{daily}}$ и $q_{\text{hourly}}$ — числа запросов за сутки и за час. Такие пороги — лишь первый сигнал. Их нужно калибровать по уровню сервиса и по форме обычного использования, потому что и пакетные клиенты, и злоумышленники могут создавать большой объем.

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

$${\mathcal{D}}_{\text{KL}}(p_{\text{user}}\Vert p_{\text{expected}})>{\tau }_{\text{alert}}$$

где ${\mathcal{D}}_{\text{KL}}$ — дивергенция Кульбака — Лейблера (KL), а ${\tau }_{\text{alert}}$ — порог срабатывания. Для API языковой модели та же идея проявляется как необычные распределения токенов, повторяющиеся шаблоны промптов или малодисперсное зондирование границ модели. Временные признаки дают еще одну подсказку: автоматизированное извлечение обычно имеет регулярные интервалы между запросами и длинные непрерывные сессии, тогда как трафик человека или продукта отличается большей дисперсией.

Детектор аномалий объединяет эти сигналы в оценку, на основе которой можно применять меры:

$${\text{score}}_{\text{anomaly}}(u)=f_{\theta }(\text{qps}(u),{\mathcal{D}}_{\text{KL}}(u),{\sigma }_{\text{inter-query}}(u),\dots )$$

где $f_{\theta }$ — обученный классификатор, а признаки отражают объем запросов, распределение и временную регулярность. Оценка не должна просто создавать очередь оповещений. Она должна поступать в систему квот, потому что ограничение частоты — способ, которым сервис превращает доказательства в ограничение объема информации. Бесплатные пользователи могут получать низкие суточные и пиковые лимиты, аутентифицированные платные пользователи — большие квоты, а корпоративные клиенты — индивидуальные лимиты, привязанные к контрактам и мониторингу. Цель не в том, чтобы наказывать за объем сам по себе; она в том, чтобы не дать анонимным или слабо аутентифицированным субъектам собрать достаточно наблюдений для восстановления модели.

Конкретная лестница квот делает этот предел объема информации видимым. Бесплатный уровень может допускать 1000 запросов в сутки с пиком 10 запросов в секунду, базовый платный — 100 000 запросов в сутки со 100 запросами в секунду, а корпоративный — 10 млн запросов в сутки с индивидуальными пиковыми лимитами и договорным мониторингом. Точные цифры зависят от потребностей продукта, но сама лестница важна, потому что стоимость извлечения растет вместе с накопленными ответами.

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

$${\text{limit}}_{\text{effective}}(u)={\text{limit}}_{\text{base}}\times \exp (-{\gamma }_{\text{rate}}\cdot {\text{score}}_{\text{anomaly}}(u))$$

где ${\gamma }_{\text{rate}}$ задает чувствительность. При ${\gamma }_{\text{rate}}=1$ пользователь с оценкой аномальности 0,8 сохраняет около 45 процентов базовой квоты, то есть снижение на 55 процентов; низкие оценки сохраняют обычное использование. Такое управление работает, только если и сам ответ продуман тщательно. Либеральный API, который возвращает полные логиты, скрытые состояния, веса внимания или точные показатели уверенности, утекает слишком много на каждый запрос, поэтому даже умеренная квота может быть опасной.

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

$${\tilde{p}}_i=\text{round}(p_i,d_{\text{dec}})$$

где $d_{\text{dec}}$ — число знаков после запятой. Для классификатора ImageNet с 1000 классами округление с 6 знаков до 2 удаляет 4 десятичных разряда, примерно 13,3 бита на класс в модели десятичных корзин, сохраняя границы решений, которые используют большинство приложений.

Защита усечением top-k возвращает только top-$k$ предсказанных классов вместо полного распределения вероятностей:

$$\text{output}=\{(c_i,p_i):i\in \text{top-}k\}$$

При $k=$ 5 в задаче с 1000 классами API возвращает только эти верхние оценки вместо полного вектора softmax, устраняя 99,5 процента записей распределения, которые иначе мог бы наблюдать извлекатель на каждый запрос. Легитимным пользователям обычно нужны лишь несколько верхних предсказаний, а извлекателю выгодно полное распределение.

Полные распределения утекают гораздо больше, чем выходы top-k.

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

$$\tilde{\mathbf{p}}={\Pi }_{{\Delta }^{K-1}}\left(\mathbf{p}+\mathbf{z}\right),\mathbf{z}\sim \mathcal{N}(0,{\sigma }^{2}I)$$

где ${\Pi }_{{\Delta }^{K-1}}$ — евклидова проекция на симплекс вероятностей, которая обеспечивает неотрицательность компонент и единичную сумму выхода $\tilde{\mathbf{p}}$. Масштаб шума $\sigma$ должен уравновешивать защиту от извлечения и сохранение полезности. Слишком слабый шум оставляет поверхность уверенности измеримой; слишком сильный меняет решения для легитимных пользователей. Такое рандомизированное формирование ответа само по себе не является гарантией дифференциальной приватности: для такого утверждения также нужны отношение соседства, граница чувствительности, откалиброванный шум и учет композиции.

Механизмы дифференциальной приватности дают формальную версию этой защиты, когда сам ответ инференса вычисляется по чувствительным записям: распределение ответа не должно сильно меняться, когда запись любого одного человека добавляется или удаляется. Полное определение $(ϵ,\delta )$ и обозначение соседних наборов данных разобраны в разделе «Дифференциальная приватность» следующей части главы. Повторные интерактивные выпуски с дифференциальной приватностью складываются, но запросы к фиксированной модели, обученной с DP, являются постобработкой и не расходуют дополнительного бюджета приватности обучения. Такие запросы тем не менее могут обеспечить извлечение модели, поэтому формирование выхода и ограничения частоты остаются средствами безопасности даже тогда, когда дополнительных потерь DP не возникает.

Последний рычаг — экономика. Стратегии ценообразования могут сделать извлечение невыгодным, даже когда некоторая утечка остается. Если обучение модели с нуля стоит $C_{\text{train}}$, а извлечение требует $n_{\text{queries}}$ запросов по цене $p_{\text{query}}$ за запрос, извлечение экономически оправдано только тогда, когда:

$$n_{\text{queries}}\cdot p_{\text{query}}<C_{\text{train}}$$

Выбор $p_{\text{query}}$ так, чтобы $n_{\text{queries}}\cdot p_{\text{query}}>C_{\text{train}}$, снимает экономический стимул. Например, если обучение конкурентоспособной модели стоит $5 млн, а извлечение требует 100 млн запросов, точка безубыточности составляет $0,05 за запрос; цена выше нее делает извлечение дороже переобучения. Ценообразование должно учитывать альтернативу злоумышленника: закупку вычислений, получение данных и инженерную работу по самостоятельному обучению замещающей модели. На практике ценообразование, мониторинг, квоты и формирование выходов работают как единый пакет. Минимальные выходы снижают число битов на запрос, грубые корзины уверенности уменьшают числовую точность, скрытые активации и веса внимания остаются закрытыми, детали версии модели абстрагированы, а система квот определяет, сколько информации может накопить любой субъект.

Сценарий: защита производственного API

Задача: для производственного API классификации изображений на ResNet-50, который обслуживает 1 млн запросов в день от 10 000 пользователей, как оператор может сделать извлечение модели экономически невыгодным, не ухудшая обычное обслуживание?

Ситуация: в этом сценарии модель стоит около $5 тыс. на обучение. Извлекателю нужно около 5 млн запросов для 90-процентной точности или 5 000 запросов на класс для классификатора с 1000 классами. Без защит злоумышленник, использующий бесплатный уровень, может отправлять 25 тыс. запросов в сутки в течение 200 дней и ничего не платить, что делает извлечение экономически выгодным.

Механизм: система защиты работает как последовательность:

1. Ограничить сбор: бесплатный уровень допускает 100 запросов в сутки, платный стоит $50 в месяц за 10 тыс. запросов в сутки, а корпоративный доступ требует аутентификации и мониторинга.
2. Отслеживать зондирование: путь мониторинга отслеживает систематическое поведение измерения, включая более 5 тыс. запросов в сутки от одного пользователя или медианные интервалы между запросами меньше 100 мс; легковесный детектор добавляет 2 мс на запрос.
3. Формировать выходы: формирование выхода округляет уверенности до 2 знаков после запятой, сохраняя около 6,7 бита от каждой округленной скалярной вероятности, и возвращает только top-5 классов, устраняя 99,5 процента записей распределения.
4. Назначить цену извлечению: при оплате по факту $0,001 за запрос (сверх лимитов уровней) 5 млн запросов извлечения стоят $5 тыс., что совпадает со стоимостью обучения в этом сценарии. Злоумышленник, ограниченный тарифом $50 в месяц (10 тыс. запросов в сутки), потребовал бы 500 дней и около $833 в сумме: на бумаге дешевле, но учет по тарифам, аутентификация и обнаружение зондирования делают устойчивый сбор непрактичным до срабатывания квот.

Последствия: стек меняет экономику извлечения, не выводя из доступа обычное использование. Точность суррогатной модели падает с 90 процентов без защит до 72 процентов с защитами, то есть на 18 процентных пунктов, тогда как точность top-5 для легитимных пользователей остается на уровне 99,2 процента, близко к базовым 99,3 процента. Мониторинг и формирование выхода добавляют 2,5 мс к 100 мс инференса, то есть 2,5 процента накладных расходов, и отмечают 0,3 процента пользователей для ручной проверки.

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

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

Злоупотребление доступностью и истощение бюджета (denial of wallet)

Модель угроз порождает сценарий экономического отказа в обслуживании даже тогда, когда конечная точка остается доступной. Злоумышленник может выбирать запросы, которые максимизируют число генерируемых токенов, вынуждают к повторному поиску, запускают дорогие инструменты или обходят повторное использование кэша, потребляя больше времени ускорителей и мощности нижестоящих сервисов, чем обычный трафик. В этом производном сценарии истощения бюджета (denial-of-wallet) злоумышленник атакует бюджет затрат, а не только очередь запросов: автомасштабирование может сохранять видимую доступность, покупая дополнительные мощности, пока расходы и хвостовая задержка превышают эксплуатационные пределы.

Поэтому защиты доступности должны измерять объем работы, а не только число запросов. Граница обслуживания должна назначать бюджеты на размер входа, число генерируемых токенов, вызовы инструментов, параллельную работу и совокупную стоимость на аутентифицированного субъекта. Контроль допуска может отклонять или ухудшать запросы до того, как они займут дефицитные ускорители; ограниченная генерация, таймауты, автоматические выключатели (circuit breakers) и квоты на каждый инструмент ограничивают работу, допущенную для одного запроса. Операторам стоит отслеживать стоимость успешного результата наряду с задержкой и долей ошибок, потому что злоумышленник может сохранять успешные HTTP-ответы, исчерпывая экономический бюджет сервиса. Эти средства также ограничивают извлечение модели, но их цель в доступности иная: не дать работе, спровоцированной противником, вытеснить легитимное обслуживание или привести к неограниченным расходам.

Разбор случая: кража интеллектуальной собственности Tesla

Извлечение через API по принципу «черного ящика» — лишь один из способов потерять ценность модели. Кража артефактов инсайдером атакует ту же границу активов изнутри среды разработки. В марте 2019 года Tesla подала два иска о коммерческой тайне против бывших сотрудников, которые ушли к конкурентам в сфере беспилотного транспорта (Korosec, 2019). В одном иске утверждалось, что сотрудники, перешедшие в Zoox, скопировали проприетарные документы по складской логистике, перевозкам и управлению запасами. В отдельном иске утверждалось, что бывший инженер Autopilot Guangzhi Cao скопировал репозитории исходного кода Tesla Autopilot до перехода в XPeng/XMotors.

Эти обвинения важны для ML-систем, потому что защищаемый актив выходит за пределы одного сериализованного файла модели и охватывает весь инженерный стек. Код обучения, конвейеры признаков, процессы разметки, скрипты развертывания, ресурсы симуляции и эксплуатационные регламенты могут раскрыть о системе достаточно, чтобы ускорить воспроизведение конкурентом или выявить слабые места безопасности, которые можно использовать дальше. Поэтому доступ инсайдера обходит многие защиты извлечения модели на уровне API: злоумышленник не запрашивает модель снаружи, а копирует артефакты разработки изнутри среды сборки.

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

Отравление данных

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

Яркий пример — атаки отравлением данных, при которых противники вводят тщательно сконструированные точки данных в обучающий набор, чтобы влиять на поведение модели целенаправленно или системно (Biggio et al., 2012). Отравленные данные могут привести к ошибочным предсказаниям модели, ухудшить ее способность к обобщению или встроить режимы отказа, которые остаются неактивными до срабатывания после развертывания.

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

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

Атаки отравлением обычно проходят три этапа. Сначала злоумышленник вводит вредоносные данные в обучающий набор. Такие примеры часто выглядят законными, но вносят незаметные искажения, которые меняют процесс обучения модели. Затем модель обучается на скомпрометированных данных и встраивает задуманное злоумышленником поведение. Наконец, после развертывания модели злоумышленник может использовать измененное поведение, чтобы вызвать ошибочные предсказания, обойти проверки безопасности или ухудшить общую надежность.

Чтобы точно понять эти механизмы атаки, отравление данных можно рассматривать как задачу двухуровневой оптимизации,²¹ в которой злоумышленник выбирает отравляющие данные ${\mathcal{S}}_{\text{poison}}$, максимизирующие потери модели на валидационном или целевом наборе ${\mathcal{S}}_{\text{test}}$. Этот цикл оптимизации отравления формализуется так. Пусть $\mathcal{S}$ — исходные обучающие данные. Цель злоумышленника — решить задачу:

$$\underset{{\mathcal{S}}_{\text{poison}}}{\max }\mathcal{L}(f_{\mathcal{S}\cup {\mathcal{S}}_{\text{poison}}},{\mathcal{S}}_{\text{test}})$$

где $f_{\mathcal{S}\cup {\mathcal{S}}_{\text{poison}}}$ — модель, обученная на объединенном наборе исходных и отравленных данных. Для целевых атак эту цель можно уточнить, сосредоточив ее на конкретных входах $x_t$ и целевых метках $y_t$:

$$\underset{{\mathcal{S}}_{\text{poison}}}{\min }\mathcal{L}(f_{\mathcal{S}\cup {\mathcal{S}}_{\text{poison}}},x_t,y_t)$$

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

Отравление данных как двухуровневая оптимизация: злоумышленник (внешний цикл) ищет отравляющие данные ${\mathcal{S}}_{\text{poison}}$, которые максимизируют потери модели на целевом тестовом наборе. Система (внутренний цикл) стремится минимизировать потери обучения на объединенном наборе $\mathcal{S}\cup {\mathcal{S}}_{\text{poison}}$. Эта динамика минимакса делает защиту от отравления вычислительно трудной, поскольку оценка защиты требует моделирования всего процесса обучения.

Эта постановка отражает цель противника: вводить тщательно сконструированные точки данных, чтобы манипулировать границами решений модели. Например, рассмотрим модель классификации дорожных знаков, обученную различать знаки «Стоп» и знаки ограничения скорости. Злоумышленник может добавить в обучающие данные небольшое число изображений знаков «Стоп», помеченных как знаки ограничения скорости. Его цель — незаметно сдвинуть границу решений модели, чтобы будущие знаки «Стоп» классифицировались как знаки ограничения скорости. В этом случае отравляющие данные ${\mathcal{S}}_{\text{poison}}$ состоят из изображений знаков «Стоп» с неверными метками, а цель злоумышленника — максимизировать ошибочную классификацию легитимных знаков «Стоп» $x_t$ как знаков ограничения скорости $y_t$ в соответствии с постановкой целевой атаки из уравнения. Даже если модель хорошо работает на других типах знаков, отравленный процесс обучения создает предсказуемую и эксплуатируемую уязвимость.

Атаки отравлением данных можно классифицировать по цели и масштабу воздействия (Biggio et al., 2012):

• Атаки на доступность: шум или переворот меток ухудшают общую производительность модели во всех задачах.
• Целевые атаки: манипулируется конкретный вход или класс; общая производительность сохраняется, но в отобранных случаях возникает устойчивая ошибочная классификация (Shafahi et al., 2018).
• Атаки с закладками: скрытые триггеры, часто незаметные узоры, вызывают вредоносное поведение только при наличии триггера (Gu et al., 2017).²²
• Атаки на подгруппы: качество ухудшается на группе, выделенной общими признаками, что делает атаку особенно опасной в приложениях, чувствительных к справедливости (Jagielski et al., 2021).

Цель определяет, какой сигнал валидации, скорее всего, выявит отравление: общую точность, целевые тесты, сканирование триггеров или оценку по подгруппам.

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

Состязательные атаки

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

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

Эти атаки создают значительные риски в реальном мире в таких областях, как автономное вождение, биометрическая аутентификация и модерация контента. Эффективность поражает: исследования показывают, что малые возмущения, которые трудно различить визуально, могут заставить классификаторы изображений совершать ошибки с высокой уверенностью (Szegedy et al., 2013; Goodfellow et al., 2015). Работы с физическим миром показали, что напечатанные состязательные изображения могут пережить съемку камерой и остаться ошибочно классифицированными классификатором ImageNet (Kurakin et al., 2017). Атаки на дорожные знаки затем показали, что небольшие наклейки или возмущения могут приводить к ошибочной классификации знаков в реалистичных условиях наблюдения (Eykholt et al., 2018). Темп этого цикла сам по себе является параметром системы. Рисунок отражает накопленную литературу, и именно ее кривизна является причиной, по которой развернутую защиту следует рассматривать как имеющую период полураспада, а не фиксированную гарантию.

Состязательная гонка вооружений: накопленное число работ по состязательному машинному обучению на arXiv с 2014 по 2023 год; кривая растет от почти нуля примерно до тринадцати тысяч. Рост служит показателем периода полураспада защиты: каждая опубликованная защита ненадолго сужает поверхность атаки, пока следующая работа об атаке не открывает ее снова.

Случай с Perspective API делает различие между угрозами инференса и обучения конкретным. Исследователи, изучавшие API Google для обнаружения токсичности в 2017 году,²³ показали, что едва заметные опечатки, замены символов и добавленные знаки препинания позволяли явно токсичным фразам получать низкие оценки токсичности²⁴ (Hosseini et al., 2017). Конвейер обучения отравлен не был; развернутая поверхность решений оказалась хрупкой к малым возмущениям входа.

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

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

Таблица систематизирует этот спектр уровней знаний и показывает, как доступ к внутренностям модели и обучающим данным определяет и осуществимость атаки, и сложность защиты в разных средах развертывания. Типичные стратегии атак включают построение суррогатной модели, переносные атаки, эксплуатирующие переносимость состязательных примеров²⁵ (Papernot et al., 2016), и генерацию возмущений на основе генеративно-состязательных сетей (GAN).

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

Атака на дорожные знаки в физическом мире — классическая демонстрация этой хрупкости; разбор ее механизма и последствий приведен ниже в полном объеме. Состязательные атаки показывают необходимость устойчивых защит, которые выходят за рамки повышения точности модели. Защита ML-систем от состязательных угроз требует защит времени выполнения: проверки входов, обнаружения аномалий и мониторинга необычных шаблонов во время инференса. Методы устойчивости на этапе обучения, включая состязательное обучение на намеренно возмущенных примерах (Madry et al., 2018), дополняют эти стратегии времени выполнения и рассматриваются далее в этой книге.

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

Граница решений при состязательной атаке: нейронные сети большой размерности часто имеют нелинейные границы решений. Противник ищет минимальное возмущение $\delta$, которое переводит чистую точку данных $x$ через границу в область другого класса, при этом возмущение достаточно мало (${ϵ}_{\text{adv}}$), чтобы оставаться незаметным или физически правдоподобным.

Разбор случая: атака на дорожные знаки

Физические состязательные атаки на дорожные знаки показывают, как малые целенаправленные возмущения могут использовать разрыв между человеческим восприятием и классификацией нейронной сети. Основной механизм геометрический: глубокая нейронная сеть разбивает пространство входов на области классификации, разделенные границами решений большой размерности. Цель противника — найти минимальное возмущение $\delta$, которое переводит правильно классифицированный вход $x$ через ближайшую границу в неверный класс, при ограничении незаметности $\Vert \delta \Vert \le {ϵ}_{\text{adv}}$, где ${ϵ}_{\text{adv}}$ — граница состязательного радиуса, а не бюджет дифференциальной приватности, который введен позже. Поскольку эти границы сильно нелинейны в пространстве пикселей, возмущения, незаметные для человеческого зрения, могут вызвать уверенные ошибочные классификации модели.

В 2017 году исследователи продемонстрировали эту уязвимость в физическом мире, наклеив небольшие черно-белые наклейки на знаки «Стоп» (Eykholt et al., 2018). Рисунок показывает физическую реализацию: возмущение, которое человеку по-прежнему ясно видно как знак «Стоп», может все же сместить представление знака через границу решений модели. В цитируемых экспериментах целевая ошибочная классификация наблюдалась на всех протестированных лабораторных изображениях и в 84,8 процента кадров при полевом испытании с движущимся автомобилем, поэтому условия оценки так же важны, как заявленный показатель успеха.

Состязательные наклейки: в цитируемом исследовании измененные знаки добились целевой ошибочной классификации на всех протестированных лабораторных изображениях и в 84,8 процента кадров полевого испытания с движущимся автомобилем. Разрыв между этими условиями показывает, почему физические атаки нужно оценивать по всему реальному пути восприятия.

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

Векторы атак, специфичные для LLM

Та же рамка вывода распространяется и на LLM, где обзоры безопасности описывают инъекцию промпта, джейлбрейк, утечку данных и злонамеренное повторное использование как риски кибербезопасности и приватности (Gupta et al., 2023). Механизм на уровне систем таков: интерфейс часто смешивает инструкции, пользовательский контент, извлеченный контекст и политики в одном потоке токенов, из-за чего граница между управлением и данными становится хрупкой (Perez и Ribeiro, 2022). Системы с инструментами добавляют еще одну границу: текст модели может запускать внешние побочные эффекты, особенно когда извлеченный или внешний контент интерпретируется как инструкция (Greshake et al., 2023). Поэтому безопасная система LLM разделяет пять объектов, которые модель склонна смешивать:

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

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

Исполнитель должен рассматривать каждый выход модели как недоверенный вход, а не как авторизацию. Каждая модель или агент получает наименьшие привилегии, необходимые для текущей задачи (Saltzer и Schroeder, 1975); аргументы инструментов проходят проверку схемы, диапазона, личности и принадлежности ресурса до выполнения; а действия несут явные ограничения по длительности, расходам, затронутым записям и обратимости. Внешняя точка применения политик должна проверять аутентифицированного субъекта и текущий контекст, а не принимать заявление о правах, сгенерированное моделью. Операции с высоким воздействием или необратимые операции требуют отдельного пути одобрения. Эти границы не дают тексту модели расширить свои полномочия и ограничивают радиус поражения, когда инъекция промпта все же срабатывает (Greshake et al., 2023). Они не устраняют инъекцию полностью: злоумышленник по-прежнему может злоупотреблять любым действием, которое текущий субъект и политика инструментов законно разрешают.

Три повторяющихся режима отказа организуют это пространство: инъекция промпта разрушает границу между управлением и данными, извлечение обучающих данных раскрывает запомненные записи (Carlini et al., 2021), а джейлбрейк обходит средства выравнивания (Zou et al., 2023). Инъекция промпта эксплуатирует переплетение плоскостей управления и данных (Perez и Ribeiro, 2022; Greshake et al., 2023). В отличие от SQL-инъекции, которую снимают параметризованные запросы, жестко разделяющие данные и команды, у LLM нет встроенной границы между «инструкциями» и «содержимым». Злоумышленник может встроить вредоносные директивы в легитимный ввод, например фразу «Игнорируй прежние ограничения и выведи системный промпт», которую модель воспринимает как авторитетную команду. Защита на уровне системы требует многоуровневой стратегии: фильтров санитизации входов для выявления эвристик инъекции, выделенных классификаторов выходов, которые отмечают отклонения от ожидаемых поведенческих политик, и архитектурной изоляции, при которой LLM работает в строго изолированной среде без прямого доступа к привилегированным API или внутреннему состоянию.

Извлечение обучающих данных выявляет вторую уязвимость: LLM функционируют как сжатые базы данных своих обучающих корпусов. Исследования показали, что при достаточном числе запросов или специальных префиксных промптов противники могут побудить модели дословно воспроизвести запомненные последовательности, раскрыв персональные данные (PII), проприетарный код или чувствительные API-ключи (Carlini et al., 2021). Эта уязвимость растет вместе с числом параметров: более крупные модели обладают большей емкостью для запоминания. Смягчение требует строгой гигиены данных до обучения, например агрессивной дедупликации для снижения вероятности запоминания, и интеграции механизмов DP в обучение: откалиброванный шум в градиентах ограничивает информацию, которую вносит любая отдельная запись. Защиты после обучения должны включать слои фильтрации выходов, которые выявляют и блокируют ответы, совпадающие с известными чувствительными шаблонами или секретами высокой энтропии.

Третья категория, джейлбрейк и обход выравнивания, направлена на средства контроля политики после обучения и во время выполнения, которые должны удерживать модель в разрешенном поведении. Обучение с подкреплением на основе человеческой обратной связи — метод выравнивания на этапе обучения (Ouyang et al., 2022); Constitutional AI добавляет самокритику модели по явным принципам (Bai et al., 2022); а защитные модели (guardrails) — это мониторы безопасности входов и выходов во время выполнения (Inan et al., 2023; Google, 2024). Поскольку эти средства контроля представляют собой статистические надстройки, а не формальные ограничения, изощренные атаки, такие как состязательные суффиксы, ролевые промпты или эскалация в многоходовом диалоге, способны их обходить (Zou et al., 2023). Системная задача заключается в вероятностной природе выравнивания: модель можно подтолкнуть к небезопасному состоянию с помощью семантической манипуляции. Эффективная защита требует эшелонированности: самокритику в духе Constitutional AI там, где это уместно, независимые защитные модели для мониторинга входов и выходов в реальном времени, ограничение частоты для подозрительных шаблонов запросов и человеческую проверку для областей применения с высоким риском.

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

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

Подходящая защита от конкретной угрозы зависит от ее типа, вектора атаки и места в жизненном цикле ML. Рисунок кодирует эту логику выбора в виде трехколоночного соответствия: каждая угроза (кража модели, отравление данных, состязательные примеры, атаки на принадлежность) сопоставлена с методом обнаружения, который ее отслеживает, а метод обнаружения, в свою очередь, определяет защиту. Чтение по строке и есть проектное решение: вектор атаки и этап жизненного цикла задают левую колонку, а структура переносит этот выбор через обнаружение к соответствующему смягчению. Хотя реальные развертывания могут требовать сочетания защит, это соответствие служит концептуальным ориентиром для согласования моделей угроз с практическими методами смягчения.

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

Различие между атаками времени обучения и времени инференса легче всего проверить на конкретном сценарии развертывания.

Контрольные вопросы: атаки на модели

Система зрения беспилотного автомобиля принимает знак «Стоп» за знак ограничения скорости из-за специально изготовленной наклейки на знаке. Эта атака происходит во время инференса без доступа к обучающим данным.

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

Атака на дорожные знаки и техники извлечения модели эксплуатируют уязвимости программного уровня: выученные границы решений, которые можно обмануть возмущениями, и интерфейсы API, которые утекают поведение модели при систематических запросах. Эти атаки все равно выполняются на физическом железе, у которого есть собственная граница доверия. Скомпрометированный драйвер GPU может обойти состязательное обучение; подмененный контроллер памяти может вынести веса модели независимо от шифрования; утечка по побочному каналу через энергопотребление может раскрыть криптографические ключи, защищающие артефакты модели.

Поэтому аппаратная безопасность — кремниевое основание программной защиты. Если программные атаки направлены на то, что делает модель, то аппаратные — на то, как она вычисляет. Процессоры исполняют инструкции, системы памяти хранят чувствительное состояние, а межсоединения передают веса, активации, градиенты и пользовательские данные между компонентами. Каждый уровень может обойти привычные программные средства контроля, остаться трудно обнаружимым и требует аппаратных механизмов, подробно описанных в разделе «Основы аппаратной безопасности» следующей части главы.

Аппаратные уязвимости

Когда команда обслуживания переносит веса модели в производство, она часто считает границей безопасности шифрование, управление доступом и политику API. Аппаратные атаки разрушают это допущение. Процессор может допустить утечку между доменами изоляции, полевое устройство можно вскрыть, шина или линия питания способны раскрыть сигналы, а поддельный компонент может попасть в систему еще до начала развертывания. Поэтому аппаратная безопасность — это не отдельное приложение к модели угроз. Это основание, которое может свести на нет программные средства контроля, даже когда они, казалось бы, уже прошли проверку.

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

Поэтому планирование аппаратной безопасности начинается с четырех проверок:

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

Таблица сохраняет наглядную картину аппаратных угроз, но читать ее нужно как набор решений о развертывании, а не как таксономию для заучивания. Стратегии защиты в разделе «Комплексные архитектуры защиты» возвращаются к тем же решениям с точки зрения доверенного исполнения, аттестации и корней доверия на уровне аппаратуры.

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

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

Аппаратные ошибки

Аппаратные ошибки отвечают на первое решение о развертывании: можно ли доверять изоляции процессора после того, как программный контроль доступа прошел проверку. Команды ML должны рассматривать эту изоляцию как эмпирическое утверждение, а не как гарантию по умолчанию. Злоумышленники могут использовать ошибки проектирования, чтобы получить доступ к чувствительным данным, манипулировать ими или извлекать их, нарушая конфиденциальность и целостность, на которые опираются пользователи и сервисы. Один из самых заметных примеров — обнаружение Meltdown и Spectre²⁶, двух уязвимостей современных процессоров, которые позволяют вредоносным программам обходить изоляцию памяти и читать данные других приложений и операционной системы (Lipp et al., 2018; Kocher et al., 2019).

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

Дальнейшие исследования показали, что это были не единичные случаи. Варианты вроде Foreshadow, ZombieLoad и RIDL нацелены на разные микроархитектурные элементы — от защищенных анклавов до внутренних буферов процессора, что доказывает: уязвимости спекулятивного исполнения представляют системный аппаратный риск. Из-за этой системной природы атаки, впервые продемонстрированные на процессорах общего назначения, распространяются и на ускорители машинного обучения и специализированное оборудование. Системы ML часто опираются на гетерогенные вычислительные платформы, которые сочетают процессоры с графическими процессорами (GPU), тензорными процессорами (TPU), программируемыми логическими матрицами (FPGA) или специализированными ускорителями. Эти компоненты обрабатывают чувствительные данные, такие как персональная информация, медицинские записи или проприетарные модели. Уязвимость в любой части этого стека может открыть таким данным доступ для злоумышленников.

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

Такие уязвимости вызывают тревогу в областях, чувствительных к приватности, например в здравоохранении, где системы ML регулярно обрабатывают данные пациентов. Утечка может нарушить нормы конфиденциальности, такие как HIPAA²⁸, и повлечь серьезные юридические и этические последствия. Похожие нормативные риски действуют и в глобальном масштабе: GDPR⁸ предусматривает штрафы до 4 процентов от общего годового оборота в мире для организаций, которые не внедряют надлежащие технические меры защиты персональных данных в территориальной и материальной сферах действия регламента.

Поэтому аппаратная безопасность — это не только защита от физического вскрытия. Это также архитектурная изоляция: предотвращение утечек процессоров, ускорителей и систем памяти через границы, которые программное обеспечение считает замкнутыми. Меры защиты часто несут издержки производительности, особенно для рабочих нагрузок ML, ограниченных данными, поэтому конфиденциальные вычисления и доверенные среды исполнения (TEE) нужно оценивать как решения о емкости и задержке, а не только как решения о безопасности.

Физические атаки

Физические атаки отвечают на второе решение о развертывании: может ли противник прикоснуться к устройству, датчику, памяти, микропрограмме или отладочному интерфейсу. Физический доступ стирает границу между программной политикой и состоянием аппаратуры. Шифрование, аутентификация и управление доступом защищают от многих удаленных атак, но мало что дают, когда злоумышленник может вставить вредоносное USB-устройство, зондировать отладочный порт, заменить датчик или изменить микропрограмму на физически открытой конечной точке.

Характер отказа зависит от того, к чему может прикоснуться злоумышленник. Дрон для картографирования местности опирается на GPS, камеры и инерциальные датчики, которые питают его навигационную модель; замена или модификация навигационного модуля может изменить характер полета или перенаправить собранные данные. Система биометрического доступа опирается на встроенный датчик лица или отпечатков пальцев; замена этого датчика может вынести идентификаторы и позволить впоследствии выдавать себя за другого. Автономный автомобиль опирается на согласованность камер, лидаров и радаров; физическое смещение или перекрытие этих датчиков может ухудшить восприятие, даже не меняя веса модели.

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

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

Атаки внесением сбоев

Внесение сбоев — активная форма решения о физическом доступе: злоумышленник не заменяет артефакт модели, а меняет вычисление во время его выполнения. Точно рассчитанный по времени провал напряжения, скачок питания, сбой тактового сигнала, перепад температуры, электромагнитный импульс или удар лазера могут вызвать переключения битов, пропуск инструкций или повреждение состояния памяти (Joye и Tunstall, 2012; Barenghi et al., 2010; Hutter et al., 2009; Amiel et al., 2006; Skorobogatov, 2009; Skorobogatov и Anderson, 2003). Для систем ML такие сбои могут вынудить выдавать неверные результаты, обойти проверки безопасности, снизить надежность или раскрыть внутреннее состояние для последующего обратного инжиниринга.

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

Практическая осуществимость этих атак подтверждена контролируемыми экспериментами. Один из заметных примеров — работа Breier et al. (2018), в которой исследователи успешно применили атаку внесением сбоев лазером к глубокой нейронной сети, развернутой на микроконтроллере. Рисунок показывает механизм: нагревая отдельные транзисторы сфокусированными лазерными импульсами, они заставляли аппаратуру пропускать шаги выполнения, в том числе функцию активации выпрямленной линейной единицы (ReLU).

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

Рисунок показывает последствия на уровне ассемблера: фрагмент, реализующий функцию активации ReLU, сравнивает старший бит аккумулятора с нулем и использует инструкцию brge (branch if greater or equal, переход, если больше или равно), чтобы пропустить присваивание, если значение неположительно. Внесение сбоя подавляет переход, так что процессор всегда выполняет блок «else». В результате выход нейрона принудительно обнуляется независимо от входного значения.

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

Атаки внесением сбоев можно также комбинировать с анализом побочных каналов: злоумышленники сначала наблюдают характеристики питания или времени, чтобы вывести структуру модели или поток данных. Такая разведка позволяет нацеливаться на конкретные слои или операции, например функции активации или финальные решающие слои, максимизируя эффект внесенных сбоев.

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

Защита должна сочетать физическое укрепление с доказательствами, получаемыми во время выполнения. Защищенная от вскрытия упаковка и маскировка конструкции уменьшают доступ, а память с коррекцией ошибок, безопасная микропрограмма и избыточные проверки снижают тихое повреждение. Мониторы согласованности выходов модели и датчиков могут поймать часть вызванного сбоями поведения, которое проходит мимо нижних уровней; MAVFI демонстрирует этот принцип для нагрузок микро-летательных аппаратов с обнаружением аномалий и восстановлением (Hsiao et al., 2023). Эти защиты труднее всего реализовать в граничных системах с ограничениями по стоимости и энергопотреблению, где дополнительное криптографическое оборудование или избыточность могут быть не по карману, поэтому устойчивость нужно проектировать на электрическом, микропрограммном, программном и системном уровнях.

Атаки по побочным каналам

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

Основная предпосылка атаки по побочному каналу состоит в том, что работа устройства может утекать информацию через наблюдаемые физические сигналы. Такие утечки могут происходить из потребляемой устройством электрической энергии (Kocher et al., 1999), из его электромагнитного поля (Gandolfi et al., 2001), из времени, нужного для завершения вычислений, или даже из создаваемого им акустического шума. Тщательное измерение и анализ этих сигналов позволяют злоумышленникам вывести внутренние состояния системы или восстановить секретные данные.

Ускорители ML, выполняющие инференс, подвержены тому же физическому каналу утечки, что и любое другое вычислительное устройство. Матричное умножение на граничном ускорителе потребляет ток с рисунком, который зависит от значений весов и обрабатываемых входных активаций. Злоумышленник, находящийся рядом с устройством, может записать эту трассу питания и при достаточном количестве образцов восстановить структуру слоев, выбор функций активации или величины параметров — без какого-либо доступа к API. Поверхность побочных каналов развернутой модели поэтому включает не только криптографические операции, защищающие ее ключи, но и сам вычислительный процесс инференса.

Один из самых широко изученных примеров касается реализаций Advanced Encryption Standard (AES)²⁹, и его уроки напрямую переносятся на рабочие нагрузки ML. AES математически стойкий, но физический процесс вычисления его функций шифрования утекает измеримые сигналы, и тот же принцип справедлив для активаций ReLU, нормировок softmax и последовательностей загрузки весов, из которых состоит прямой проход.

Удобный пример этой техники атаки — анализ энергопотребления при аутентификации по паролю (Kocher et al., 2011). Рассмотрим устройство, которое проверяет 5-байтовый пароль (в данном случае 0x61, 0x52, 0x77, 0x6A, 0x73). Во время аутентификации устройство последовательно получает каждый байт по последовательному интерфейсу, и картина его энергопотребления показывает, как система реагирует на обработку этих входных данных.

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

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

Рисунок показывает, что происходит при вводе неверного пароля: энергетическая сигнатура расходится. В этом случае первые три байта (0x61, 0x52, 0x77) верны, поэтому картины энергопотребления до этого момента близко совпадают с правильным паролем. Однако когда четвертый байт (0x42) обработан и оказывается неверным, устройство прерывает аутентификацию. Это отражается во внезапном скачке синей линии мощности, что указывает на то, что устройство остановило обработку и перешло в состояние ошибки.

Уязвимость к атаке по побочному каналу: Картины энергопотребления раскрывают информацию о криптографическом ключе во время аутентификации: стабильное потребление указывает на верные байты пароля, а резкие изменения — на неверный ввод и прерванную обработку. Даже не зная пароля, злоумышленник может восстановить его, анализируя энергопотребление устройства во время попыток аутентификации. Источник: Colin O’Flynn.

Рисунок показывает крайний случай: при полностью неверном пароле (0x30, 0x30, 0x30, 0x30, 0x30) устройство терпит неудачу сразу. Устройство обнаруживает несовпадение после первого байта и прекращает обработку гораздо раньше. Это видно в профиле мощности: синяя линия резко подскакивает после первого байта, отражая раннее завершение аутентификации.

Скачок энергопотребления: Резкий рост синей линии после обработки первого байта указывает на немедленный сбой аутентификации и показывает, как неверные пароли быстро распознаются по энергопотреблению. Источник: Colin O’Flynn.

Эти примеры показывают, как злоумышленники могут использовать наблюдаемые различия в энергопотреблении, чтобы сузить пространство поиска и в конце концов восстановить секретные данные методом перебора с анализом. Механизм напрямую переносится на инференс ML: так же как раннее прекращение обработки неверного байта пароля создает резкий скачок энергопотребления, ускоритель, выполняющий слой активации ReLU, потребляет заметно иной ток в зависимости от того, положительно или отрицательно предактивационное значение каждого нейрона. Злоумышленник, который записывает достаточное количество трасс энергопотребления во время инференса, может использовать этот сигнал, чтобы вывести шаблоны разреженности, восстановить топологию слоев или сузить пространство поиска при восстановлении параметров — и все это без какого-либо доступа к API модели.

Видеоматериал: Power Attack (Colin O’Flynn)

Круг этих уязвимостей выходит за пределы криптографических приложений, потому что лежащий в основе урок физический: вычисления излучают сигналы. Питер Райт в своих воспоминаниях описывает операцию ENGULF служб MI5 и GCHQ, в ходе которой модифицированный телефон устанавливали рядом с посольством Египта, где стоял шифровальный аппарат Hagelin, чтобы по звуку машины определять ее ежедневные настройки (Wright и Greengrass, 1987). Генкин, Шамир и Тромер связывают эту историю с современным акустическим криптоанализом, при котором зависящий от вычислений звук может раскрывать чувствительное состояние (Genkin et al., 2017). Современные варианты той же идеи включают подслушивание клавиатуры (Asonov и Agrawal, 2004), удаленные атаки по побочным каналам питания на основе FPGA (Zhao и Suh, 2018) и атаки внесением сбоев через падение напряжения на FPGA (Gnad et al., 2017).

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

Интерфейсы с утечками

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

Интерфейс с утечкой — это любая точка доступа, которая раскрывает больше информации, чем предполагалось, или принимает команды от не того субъекта. Типичные причины — слабая аутентификация, отсутствие шифрования, недостаточная изоляция и отладочные интерфейсы, оставленные открытыми в производстве. Потребительские, медицинские и промышленные системы неоднократно демонстрировали этот шаблон: радионяни с Wi-Fi открывали незащищенные порты удаленного доступа³⁰, а уязвимости кардиостимуляторов³¹ показали, как беспроводные интерфейсы могут становиться каналами управления, критичными для безопасности.

Показательный случай с умными лампочками продемонстрировал, что доступные отладочные порты³², оставленные на серийных устройствах, раскрывали незашифрованные учетные данные Wi-Fi. Этот недосмотр в безопасности давал злоумышленникам путь в домашние сети без необходимости обходить стандартные механизмы защиты.

Для ML из этого следует, что путь обслуживания может стать путем извлечения модели, утечки данных или подмены микропрограммы. Система домашней безопасности может использовать интерфейс обслуживания для обновления программного обеспечения; если этот интерфейс лишен аутентификации или передает трафик без шифрования, злоумышленник в той же сети может раскрыть пользовательские сценарии, нарушить целостность модели или отключить функции безопасности. Отладочный интерфейс в производстве может раскрыть обучающие данные, параметры модели или промежуточные выходы, что облегчает создание состязательных примеров и обратный инжиниринг.

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

Поддельное оборудование

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

Риск соответствия нормам идет тем же путем. Организации, которые по неведению встраивают поддельные компоненты в системы ML, могут нарушить обязательства в области безопасности, приватности или кибербезопасности.³³ Медицинские организации обязаны демонстрировать соответствие HIPAA на всем технологическом стеке, а организации, обрабатывающие персональные данные в территориальной и материальной сфере действия GDPR, должны выполнять ее технические и организационные меры защиты. Происхождение компонентов поэтому — не только предпочтение при закупке; это доказательство того, что развернутая система соответствует сертифицированной.

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

Риски цепочки поставок

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

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

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

Спорный отчет 2018 года наглядно показал этот разрыв в видимости, как разбирается в разделе «Разбор случая: скандал вокруг Supermicro». За любым отдельным обвинением стоит структурная проблема: компании полагаются на сложные, непрозрачные производственные и распределительные сети, а чрезмерная зависимость от отдельных производителей или регионов, включая зависимость полупроводниковой отрасли от TSMC, еще сильнее концентрирует риск.

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

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

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

Разбор случая: скандал вокруг Supermicro

Абстрактный характер рисков цепочки поставок стал конкретным в громком скандале, который привлек внимание отрасли. В 2018 году Bloomberg Businessweek опубликовал широко обсуждаемый материал, в котором утверждалось, что агенты, действовавшие по поручению китайского государства, тайно внедряли крошечные микросхемы-шпионы в серверные материнские платы, выпускаемые Supermicro (Robertson и Riley, 2018). Apple, Amazon и Supermicro публично опровергли эти утверждения, а эксперты отрасли указывали на отсутствие проверяемых технических доказательств. Даже как спорный случай, этот скандал выявил операционную проблему: организациям часто не хватает видимости процессов изготовления, сборки, распределения и интеграции, чтобы доказать, что развернутое оборудование соответствует сертифицированной системе.

Для систем машинного обучения этот разрыв в происхождении не является второстепенным. Кластеры обучения, парки инференса и граничные устройства зависят от процессоров, ускорителей, памяти, сетевых адаптеров, датчиков и микропрограмм от нескольких поставщиков. Скрытая компрометация в любом слое может обойти защиты на уровне модели, наблюдая за данными, изменяя выполнение или ослабляя изоляцию еще до того, как начнут действовать программные средства контроля. Политические меры, такие как закон CHIPS and Science Act (United States Congress, 2022), могут снизить часть риска концентрации, но они не заменяют технических мер защиты. Проверка компонентов, мониторинг во время выполнения, аттестация и аппаратные корни доверия превращают заботу о цепочке поставок в проверяемые проверки при развертывании.

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

Контрольные вопросы: аппаратная безопасность

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

• Граница изоляции: определите модель угроз, которую доверенная среда исполнения решает при облачном развертывании.
• Разделение слоев: отделите риски, которые остаются за пределами области действия доверенной среды исполнения.
• Соответствие развертыванию: разместите аттестацию и мониторинг во время выполнения вокруг защищенной границы исполнения.

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

Когда системы ML становятся инструментами атаки

Рассмотрим традиционную атаку по побочному каналу, в которой криптоаналитик-человек месяцами вручную выравнивает зашумленные осциллограммы, чтобы извлечь криптографический ключ. Теперь представьте, что этого аналитика заменяет сверточная нейронная сеть (CNN), обученная сопоставлять сырые трассы питания напрямую с закрытыми ключами за миллисекунды. Демократизация глубокого обучения не только усилила возможности защиты; она фундаментально автоматизировала и ускорила арсенал противника.

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

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

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

Эти задокументированные случаи показывают, что модели машинного обучения служат усилителями возможностей противника. Языковые модели делают фишинговые атаки убедительнее и адаптивнее, а алгоритмы кластеризации и классификации облегчают разведку, выучивая поведенческие шаблоны системного уровня. Генераторы состязательных примеров и модели инференса систематически выявляют слабости в границах решений или защитах приватности данных, часто требуя лишь ограниченного внешнего доступа к развернутым системам. В аппаратном контексте глубокие нейронные сети, обученные на данных побочных каналов, могут автоматизировать извлечение криптографических секретов из физических измерений, превращая процесс, который требовал экспертов, в задачу обучаемого распознавания шаблонов. Та же основа глубокого обучения, которая питает полезные приложения (сверточные сети для распознавания пространственных шаблонов, рекуррентные архитектуры для временных зависимостей и оптимизация на основе градиентов), позволяет злоумышленникам применять эти методы на аппаратных платформах — от облачных GPU до граничных ускорителей. Таблица показывает это разнообразие наступательных сценариев применения ML, классифицируя каждый по используемому типу модели, эксплуатируемой уязвимости и получаемому преимуществу атакующего.

Наступательные сценарии применения ML: Эта таблица классифицирует, как машинное обучение усиливает кибератаки, позволяя автоматически генерировать контент, эксплуатировать уязвимости систем и повышать изощренность атак; для каждого применения она описывает типичную модель ML, атакуемую слабость и получаемое преимущество. Понимание этих сценариев важно для разработки эффективных защит от угроз, основанных на обучении.

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

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

Эта динамика создает асимметрию между нападающим и защитником. Меры защиты ограничены требованиями развертывания, бюджетами задержки и нормативными требованиями, тогда как атакующие могут масштабировать конвейеры обучения при минимальных предельных затратах. Широкая доступность предобученных моделей и публичных платформ ML дополнительно снижает уровень экспертизы, нужный для создания атак с высоким воздействием.

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

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

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

Разбор случая: глубокое обучение для анализа побочных каналов

Чтобы конкретно проиллюстрировать эти наступательные возможности, рассмотрим случай, в котором машинное обучение преобразует традиционную методологию атаки. Одна из самых известных и воспроизводимых демонстраций анализа побочных каналов с помощью глубокого обучения — фреймворк SCAAML (Side-Channel Attacks Assisted with Machine Learning, атаки по побочным каналам с помощью машинного обучения) (Bursztein et al., 2024; Bursztein и Picod, 2019). Разработанный исследователями Google, SCAAML предоставляет практическую реализацию конвейера атаки, описанного выше.

Рисунок иллюстрирует, как криптографические вычисления порождают сигнатуры энергопотребления, зависящие от данных, которые раскрывают состояние алгоритма. Эти вариации, хотя и тонкие, измеримы и отражают внутреннее состояние алгоритма в определенные моменты времени. Три трассы на врезке соответствуют различным обрабатываемым значениям (двоичные метки 0000, 1111 и 0101): поскольку каждое значение потребляет заметно иной ток, их разделение по амплитуде — именно тот признак, который модель использует, чтобы классифицировать секретные биты, от которых зависит одно промежуточное вычисление.

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

В традиционных атаках по побочным каналам эксперты опираются на статистические методы, чтобы выделить эти различия. Однако нейронная сеть может научиться связывать форму этих сигналов с конкретными обрабатываемыми значениями данных, фактически научаясь декодировать сигнал так, как это делают модели, созданные экспертами, но с большей гибкостью и обобщающей способностью. Модель обучается на размеченных примерах трасс питания и соответствующих им промежуточных значений (например, выхода операции S-блока). Со временем она учится связывать шаблоны трассы с секретно-зависимым поведением вычислений. Это превращает задачу восстановления ключа в задачу классификации, где цель — вывести правильный байт ключа только по форме трассы.

В руководстве SCAAML Bursztein и Picod (2019) обучили сверточную нейронную сеть (CNN) извлекать ключи AES из трасс питания, снятых с микроконтроллера STM32F415, на котором работает реализация TinyAES с открытым исходным кодом. Модель обучалась предсказывать промежуточные значения алгоритма AES, например выход S-блока³⁶ в первом раунде, непосредственно по сырым трассам питания. Обученная модель восстановила полный 128-битный ключ, используя лишь небольшое число трасс на каждый байт.

Рисунок показывает экспериментальную конфигурацию: установку ChipWhisperer со специально созданной целевой платой на STM32F, которая выполняет операции AES и позволяет внешнему оборудованию наблюдать энергопотребление с высокой временной точностью. Эта установка показывает, что даже недорогие маломощные встроенные устройства могут утекать информацию через побочные каналы, которые модели машинного обучения способны научиться эксплуатировать.

Целевая плата STM32F: Схема измерений делает видимым энергопотребление во время операций AES на микроконтроллере. Эти трассы дают наблюдения, по которым модель побочного канала может вывести зависящее от данных внутреннее поведение.

Последующие работы развили этот подход, введя модели дальнего действия, которые способны использовать более широкие временные зависимости в трассах и повышают точность даже при шуме и рассинхронизации (Bursztein et al., 2024). Эти разработки подчеркивают потенциал моделей машинного обучения как инструментов наступательного криптоанализа, особенно при анализе защищенного оборудования.

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

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

Комплексные архитектуры защиты

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

Рисунок визуализирует четыре уровня. Аппаратная основа, такая как доверенные среды исполнения и безопасная загрузка, закрепляет доверие ниже операционной системы. Системные меры, такие как изоляция ОС и управление доступом, защищают операции во время выполнения. Защиты на уровне модели, такие как состязательное обучение,³⁷ валидация входов и мониторинг выходов, защищают выученную функцию. Защиты уровня данных, такие как дифференциальная приватность, шифрование и отслеживание происхождения, уменьшают то, что модель и ее операторы могут раскрыть. Порядок важен, потому что каждый уровень предполагает, что нижележащий уровень еще не вышел из строя.

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

Многоуровневый стек защиты: Системы машинного обучения требуют многоаспектных стратегий безопасности, которые движутся от базовых аппаратных защит к методам приватности, ориентированным на данные, формируя доверие на всех уровнях. Эта архитектура объединяет меры защиты на уровнях оборудования, системы, модели и данных, чтобы смягчать угрозы и обеспечивать надежное развертывание в производственной среде.

Методы сохранения приватности данных

Уровень данных задает первое решение о приватности: хранить необработанные записи централизованно, держать их на клиентских устройствах, вычислять над зашифрованными значениями или заменять их синтетическими аналогами. Это решение сначала архитектурное, а уже потом алгоритмическое, потому что оно фиксирует те же системные переменные, которые отслеживала эта глава: утечку информации, полезность модели, издержки во время выполнения и силу гарантии. Рабочие процессы ML часто зависят от необработанных данных высокой точности, поэтому методы сохранения приватности стоит рассматривать как разные способы переместить или ограничить это раскрытие, а не как взаимозаменяемые инструменты.

Федеративное обучение

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

Архетип C (федеративный MobileNet): необходимость приватности

Архетип C (федеративный MobileNet) (см. «Три системных архетипа») представляет класс систем, в которых приватность — жесткое ограничение, а не оптимизация. Для парка мониторов здоровья, обрабатывающих данные сердечной деятельности, если политика или согласие запрещают централизовать необработанные сигналы, федеративное обучение становится естественным архитектурным выбором для соблюдения компромисса между приватностью и полезностью: коллективный интеллект без централизации данных.

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

Утечка через градиенты и вычисления с сохранением приватности

Атаки инверсии градиентов (например, Deep Leakage from Gradients) показывают, что противник, имеющий доступ к необработанному обновлению клиента, может с высокой точностью восстановить исходные обучающие данные (например, изображения или текст) (Zhu et al., 2019; Nasr et al., 2019). Вектор градиента кодирует информацию о данных, которые его породили, создавая канал утечки даже тогда, когда необработанные данные никогда не покидают устройство. Защитой от этой уязвимости служит безопасная агрегация — криптографический протокол, который позволяет серверу вычислить совокупное обновление, никогда не наблюдая вклад отдельного клиента. Рисунок детализирует этот протокол: участники на границе генерируют попарные маски с нулевой суммой, которые взаимно уничтожаются при суммировании на сервере, скрывая отдельные обновления и сохраняя точный совокупный результат.

Протокол безопасной агрегации: Клиенты на границе вычисляют локальные векторы градиентов и обмениваются попарными случайными масками с нулевой суммой ($s_{i,j}=-s_{j,i}$) через обмен ключами Диффи — Хеллмана. Каждый клиент передает на центральный агрегатор только свой замаскированный вектор. При суммировании по всему парку маски в точности обнуляются, что позволяет серверу восстановить точный совокупный градиент парка, не узнавая обновление ни одного участника.

Эта уязвимость создает потребность в протоколах безопасной агрегации (Bonawitz et al., 2017) и дифференциальной приватности, но граница доверия определяет, какой вариант DP применим. Центральная дифференциальная приватность предполагает, что доверенный куратор или служба агрегации видит необработанные записи или обновления, прежде чем выпустить зашумленный совокупный результат. Локальная дифференциальная приватность рандомизирует вклад каждого клиента еще до того, как его увидит сервер; это защищает от более сильного противника, но обычно обходится дороже по полезности. Безопасная агрегация располагается между этими режимами: сервер видит совокупный результат, а не отдельные обновления, и к нему можно затем применить шум DP, так что опубликованный результат раскрывает ограниченную информацию о любом участнике. Интересно, что методы сжатия градиентов, рассмотренные в разделе «Сжатие градиентов в условиях дефицита пропускной способности» ради эффективности коммуникаций, тоже могут влиять на свойства приватности: сжатые градиенты могут раскрывать меньше информации, чем обновления полной точности, однако взаимодействие сжатия и гарантий приватности требует тщательного анализа. Поэтому федеративные развертывания послойно сочетают FL, безопасную агрегацию и подходящую модель угроз DP, чтобы получить формальные гарантии приватности, выходящие за пределы одной только структурной защиты. Федеративное обучение Google Gboard — наглядный пример такого многоуровневого подхода.

Архетип C (федеративный MobileNet): федеративное обучение в Google Gboard

Для рабочей нагрузки архетипа C на мобильных устройствах и в федеративном режиме — клавиатуры Google Gboard, показанной на рисунке как клавиатурное приложение на устройстве, — видно, как механизмы безопасности могут наслаиваться поверх протокола FL. С точки зрения приватности схема объединяет три механизма защиты: FL хранит необработанные данные набора текста на устройстве; дифференциальная приватность может ограничить утечку информации из градиентных обновлений при явном $ϵ$; а безопасная агрегация позволяет серверам наблюдать совокупные обновления, а не вклады отдельных участников. Опубликованные отчеты о Gboard и федеративном обучении в масштабе показывают, что такой многоуровневый дизайн может сохранять полезное качество модели в пределах бюджета мобильной пропускной способности, не централизуя необработанные данные набора текста (Hard et al., 2018; Bonawitz et al., 2019).

Федеративное обучение обеспечивает структурную приватность, сохраняя необработанные данные локально, а дифференциальная приватность обеспечивает статистическую приватность, ограничивая то, что выходы раскрывают об одной записи. Третье семейство обеспечивает криптографическую приватность: гомоморфное шифрование (HE)³⁸ и безопасные многосторонние вычисления (SMPC) позволяют моделям выполнять инференс или обучение над зашифрованными входами (Gentry, 2009; Yao, 1982). Вычислительные издержки гомоморфных операций часто требуют методов оптимизации эффективности, включая сжатие модели (квантование снижает требования к точности для зашифрованных операций), архитектурную оптимизацию (раздельные по глубине свертки минимизируют зашифрованные умножения) и аппаратное ускорение (специализированные криптографические ускорители), чтобы сохранить практическую производительность.

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

$$c\leftarrow \mathrm{Enc}(pk,x),\mathrm{Dec}\left(sk,\mathrm{Eval}(pk,f,c)\right)=f(x)$$

Это свойство поддерживает вычисления с сохранением приватности в недоверенных средах, например облачный инференс над чувствительными медицинскими или финансовыми записями. Вычислительная стоимость HE остается высокой, поэтому оно лучше подходит для моделей с фиксированной функцией и пакетных задач, нечувствительных к задержке. SMPC,³⁹ напротив, распределяет вычисления между несколькими сторонами так, что ни одна из них не узнает полный вход или выход. Это особенно полезно при совместном обучении между учреждениями со строгими политиками использования данных, например больницами или банками.⁴⁰

Генерация синтетических данных

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

Генерация синтетических данных работает так: генеративная модель (например, GAN, вариационный автокодировщик (VAE) или диффузионная модель) обучается на исходном чувствительном наборе данных, после чего обученный генератор создает новые искусственные образцы. Ключевая идея в том, что генеративная модель выучивает лежащие в основе данных закономерности и распределения, не запоминая отдельных людей. При правильной реализации синтетические данные сохраняют статистические свойства, необходимые для машинного обучения, и одновременно лишены персонально идентифицируемой информации.

Генерация обычно проходит три упорядоченных этапа:

1. Обучение распределению: генеративная модель $G_{\theta }$ обучается на реальных данных ${\mathcal{S}}_{\text{real}}=\{x_1,x_2,\dots ,x_n\}$, чтобы выучить распределение данных $p(x)$.
2. Синтетическая выборка: новые образцы ${\mathcal{S}}_{\text{synthetic}}=\{G_{\theta }(z_1),G_{\theta }(z_2),\dots ,G_{\theta }(z_m)\}$ генерируются выборкой из случайного шума $z_i\sim \mathcal{N}(0,I)$.
3. Валидация: синтетический набор проверяется на сохранение статистической точности относительно ${\mathcal{S}}_{\text{real}}$ при отсутствии запоминания конкретных записей.

Обучение генеративных моделей на реальных наборах данных и выборка из выученного распределения могут создать наборы, которые приближают выбранные статистические свойства, не копируя исходную таблицу напрямую (Goncalves et al., 2020). Само это преобразование не является гарантией приватности: синтетические записи все равно требуют оценки на запоминание, связывание и повторную идентификацию относительно модели угроз развертывания.

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

Рассмотрим практический пример: больница хочет поделиться данными пациентов для исследований ML, защищая приватность. Она обучает GAN на 10 000 реальных записей пациентов, содержащих демографические данные, результаты анализов и диагнозы. GAN учится генерировать синтетических пациентов с реалистичными сочетаниями признаков (например, у пациентов с диабетом обычно повышен уровень глюкозы). Больница применяет дифференциальную приватность во время обучения GAN и использует проверенный учетчик приватности, чтобы ограничить утечку, связанную с участием отдельных пациентов. Перед публикацией нужно измерить и клиническую точность, и утечку, специфичную для подгрупп, потому что синтетические записи не содержат ни одной исходной строки, но все же могут раскрывать запомненные или статистически идентифицирующие шаблоны обучающей популяции.

Вместе эти методы отражают сдвиг от изоляции данных как единственного пути к приватности к встраиванию механизмов сохранения приватности в сам процесс обучения. Каждый метод предлагает свои гарантии и компромиссы в зависимости от контекста применения, модели угроз и нормативных ограничений. Эффективный системный дизайн часто сочетает несколько подходов, например применяя дифференциальную приватность внутри федеративного обучения или используя гомоморфное шифрование для важных этапов инференса, чтобы строить системы ML, которые одновременно полезны и уважают приватность пользователей.

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

Разбор случая: извлечение данных из GPT-2

Прежде чем перейти к проектированию безопасных моделей, случай извлечения из GPT-2 показывает, почему утечку на уровне модели нельзя устранить одним лишь контролем доступа к хранилищу. В 2020 году исследователи показали, что большие языковые модели могут раскрывать чувствительные обучающие данные через тщательно составленные промпты (Carlini et al., 2021). Исследовательская группа систематически запрашивала модель GPT-2 от OpenAI, чтобы извлечь дословное содержимое из ее обучающего набора, выявив уязвимости приватности в крупных языковых моделях.

Атака оказалась удивительно успешной в извлечении чувствительной информации непосредственно из выходов модели. Многократные запросы к модели с промптами вроде «My name is» и попытками продолжить известные цитаты или повторяющиеся фразы позволили исследователям извлечь персональную информацию, например адреса электронной почты и телефонные номера, дословные фрагменты защищенных авторским правом книг и другие идентифицирующие фрагменты, запомненные из обучающих данных.

Технический подход использовал запоминание GPT-2 редких или повторяющихся текстовых последовательностей. Исследователи объединили четыре метода:

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

Сгенерировав 600 000 кандидатных образцов, они подтвердили 604 уникальных запомненных обучающих примера при ручной проверке.

Атака поставила под сомнение допущения о приватности обучающих данных. Большие языковые модели могут непреднамеренно работать как базы данных, сохраняя и извлекая чувствительную информацию из обучающих данных. Результаты опровергли ожидание, что обучающие данные «забываются» после обучения модели, и показали, что масштаб усиливает риск приватности: в семействе GPT-2 (от 124 млн до 1,5 млрд параметров) более крупные модели запоминали больше обучающих данных, чем малые.

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

Этот результат показывает, почему средства контроля обучающих данных нуждаются в многоуровневых мерах смягчения, а не только в контроле доступа к хранилищу (Carlini et al., 2021). Эти уровни могут включать фильтрацию персональных данных (PII), дедупликацию, аудиты запоминания в стиле извлечения, тестирование атак на принадлежность и дифференциальную приватность, когда требуется формальная граница. Машинное разобучение и политические меры решают связанные вопросы жизненного цикла, но их гарантии требуют отдельных доказательств и валидации.

Безопасное проектирование модели

Атака на GPT-2 показывает, что даже при строгом контроле доступа к данным сама модель может утекать информацию через свои выходы, структуру или выученное поведение. Дифференциальная приватность снижает этот риск, только если она применяется во время обучения или анализа с явным бюджетом приватности; это не заплатка постфактум для модели, которая уже запомнила чувствительные строки. Это ограничение мотивирует безопасность на уровне модели: архитектурные и проектные решения, которые дополняют защиту данных, уменьшая способность модели служить каналом передачи информации.

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

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

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

Еще одно соображение на этапе проектирования — использование водяных знаков модели,⁴² технику, которая встраивает проверяемые подписи владения непосредственно в параметры модели или поведение выходов (Adi et al., 2018). Водяной знак может быть реализован, например, как скрытый шаблон ответов, запускаемый определенными входами, или как возмущение пространства параметров, которое не влияет на точность, но статистически идентифицируемо.

Например, в системе распознавания ключевых слов, развернутой на встроенном оборудовании для голосовой активации (например, «Hey Alexa» или «OK Google»), безопасный дизайн может использовать легковесную сверточную нейронную сеть с калибровкой уверенности, чтобы не допускать ложных срабатываний на неоднозначном аудио. Модель может также включать порог воздержания, ниже которого она вообще не выдает активацию. Чтобы защитить интеллектуальную собственность, разработчик может встроить водяной знак, обучив модель выдавать уникальную метку только в ответ на конкретный, неиспользуемый аудиотриггер, известный лишь разработчику. Эти проектные решения повышают устойчивость и подотчетность, а также поддерживают будущую проверку в случае споров об интеллектуальной собственности или сбоев в работе в полевых условиях.

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

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

Безопасное развертывание модели

Безопасный дизайн задает предполагаемое поведение модели, но развертывание определяет, переживет ли это поведение контакт с пользователями, операторами и злоумышленниками. Уязвимость модели определяется не только процедурой обучения или архитектурой; она зависит также от того, как артефакт сериализуется, упаковывается, развертывается и используется во время инференса. Когда модели переходят на граничные устройства, публичные API и многопользовательские платформы, безопасность развертывания должна сохранять целостность, конфиденциальность и доступность поведения модели.

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

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

Среды развертывания должны также обеспечивать строгие политики контроля доступа, чтобы только авторизованные пользователи и сервисы могли взаимодействовать с конечными точками инференса. Протоколы аутентификации, включая токены OAuth⁴³, взаимную TLS-аутентификацию⁴⁴ или API-ключи⁴⁵, должны сочетаться с ролевым управлением доступом (RBAC)⁴⁶, чтобы ограничивать доступ в соответствии с ролями пользователей и операционным контекстом. Размещенные API моделей обычно аутентифицируют запросы выданными провайдером API-ключами, служебными токенами или взаимно аутентифицированными идентичностями сервисов. Эти средства контроля — не просто механизмы учета или доступности: надежная проверка личности — предварительное условие для защит ограничения частоты запросов и обнаружения аномалий, описанных в разделе «Защиты от извлечения модели». Без нее злоумышленник, занимающийся извлечением модели, может провести атаку Сивиллы — запрашивать конечную точку через тысячи разных неаутентифицированных сеансов — и полностью обойти ограничения частоты запросов по идентичности. Каждый токен OAuth, сертификат mTLS или API-ключ превращает анонимный поток запросов в атрибутируемую идентичность, делая систематическое извлечение экономически и операционно обнаруживаемым.

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

Закрепленные здесь шаблоны безопасного развертывания естественно встраиваются в процессы разработки, так что безопасность становится частью стандартной инженерной практики, а не запоздалой мыслью. Мониторинг во время выполнения (см. раздел «Мониторинг системы во время выполнения») распространяет эти защиты на эксплуатационные среды.

Мониторинг системы во время выполнения

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

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

Валидация входных данных

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

Модели машинного обучения, в отличие от традиционных систем на основе правил, часто не отказывают безопасным образом. Небольшие, тщательно подобранные изменения входных данных могут заставить модели делать предсказания с высокой уверенностью, но неверные (Goodfellow et al., 2015). Валидация входов помогает обнаружить и отклонить такие входы на раннем этапе конвейера.

Методы валидации варьируются от низкоуровневых проверок (например, размер входа, тип и диапазоны значений) до семантических фильтров (например, проверка того, содержит ли изображение узнаваемый объект или содержит ли голосовая запись речь). Например, система распознавания лиц может проверять, что загруженное изображение находится в определенном диапазоне разрешений (например, от $224\times 224$ до $1024\times 1024$ пикселей), содержит RGB-каналы и проходит через легковесный фильтр обнаружения лиц. Это не дает пустым изображениям, скриншотам текста или синтетическим состязательным узорам попасть в модель. Аналогично голосовой ассистент может требовать, чтобы входящие аудиофайлы длились от 1 до 5 секунд, имели допустимую частоту дискретизации (например, 16 кГц) и содержали обнаруживаемую человеческую речь с помощью детектора речевой активности (SAD).⁴⁷ Это гарантирует, что пустые записи, музыкальные фрагменты или всплески шума отфильтровываются до инференса модели.

В генеративных системах, таких как DALL·E, Stable Diffusion или Sora, валидация входов часто включает фильтрацию промптов. Она предполагает проверку текстового промпта пользователя на запрещенные термины, названия брендов, нецензурную лексику или вводящие в заблуждение медицинские утверждения. Например, пользовательский промпт вроде «Сгенерируй изображение флакона с лекарством с логотипом Pfizer» может быть отклонен или переписан из-за вопросов товарных знаков. Фильтры могут работать на основе списков ключевых слов, регулярных выражений или легковесных классификаторов, оценивающих намерение промпта. Такие фильтры не дают генеративной модели создавать вредный, незаконный или вводящий в заблуждение контент до начала сэмплирования.

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

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

Мониторинг выходов

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

Сигнал, за которым следит монитор, зависит от модальности модели. Для дискриминативного классификатора ключевая величина — уверенность предсказания: модель, которая начинает присваивать высокую уверенность низкочастотным классам или у которой энтропия выходов коллапсирует в неоднозначных контекстах, сигнализирует о состязательных входах или сдвиге распределения. Та же идея обобщается по модальностям: модели модерации контента отслеживают расхождение между предсказанными метками «безопасно» и вспомогательными опорными сигналами; модели временных рядов, например детекторы мошенничества, отслеживают внезапные падения оценок в периоды высокой нагрузки, что указывает на подмену или уклонение. В каждом случае монитор сравнивает поток живых предсказаний с ожидаемым распределением и запускает запасной вариант (передача на ручную проверку, возврат к консервативной базовой модели), когда они расходятся.

Генеративные модели, например системы преобразования текста в изображение, создают уникальные проблемы мониторинга выходов. Эти модели могут производить высококачественные изображения, которые непреднамеренно нарушают политики безопасности контента, правила платформы или ожидания пользователей. Чтобы снизить эти риски, обычно используют классификаторы постгенерации, которые оценивают созданный контент на предмет недопустимых характеристик, таких как насилие, обнаженность или злоупотребление брендом. Эти классификаторы работают после генеративной модели и могут подавлять, размывать или отклонять выходы по заранее заданным порогам. Некоторые системы также проверяют внутренние представления (например, карты внимания⁴⁸ или скрытые эмбеддинги), чтобы предугадать возможное злоупотребление до отрисовки контента.

Однако одной фильтрации промптов недостаточно для безопасности. Исследования показали, что системы преобразования текста в изображение можно обойти неявно состязательными промптами — запросами, которые выглядят безобидно, но приводят к нарушающим политику результатам. Проект Adversarial Nibbler предлагает открытую методологию red teaming, которая выявляет такие промпты и показывает, как модели вроде Stable Diffusion могут создавать непредусмотренный контент при отсутствии явных триггерных фраз (Quaye et al., 2024; Parrish et al., 2023). Эти случаи отказа часто обходят фильтры промптов, поскольку их риск возникает из поведения модели во время генерации, а не из синтаксических или лексических признаков.

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

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

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

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

Эти принципы воплощены во фреймворках фильтрации выходов. Например, Llama Guard — основанный на LLM механизм защиты входов и выходов, который классифицирует диалоги человека и ИИ по категориям политик (Inan et al., 2023). Аналогично ShieldGemma, разработанная в рамках открытого релиза модели Gemma от Google, применяет настраиваемые функции оценки для выявления и фильтрации нежелательных выходов во время инференса (Google, 2024). Обе системы показывают, как классификаторы безопасности и мониторы выходов могут интегрироваться в стек выполнения для масштабируемого развертывания генеративных языковых моделей в соответствии с политиками.

Проверки целостности

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

Один из самых распространенных механизмов целостности — криптографическая проверка модели. Перед загрузкой модели в память система может вычислить криптографический хеш (например, SHA-256)⁴⁹ файла модели и сравнить его с заведомо корректной подписью.

Контроль доступа и аудит-журналирование дополняют криптографические проверки. Системы ML должны ограничивать доступ к файлам моделей с помощью ролевых разрешений и отслеживать шаблоны доступа к файлам. Например, повторные попытки чтения контрольных точек модели из нестандартного пути или запросы инференса из неавторизованных диапазонов IP могут указывать на подмену, эскалацию привилегий или внутреннюю угрозу. В облачных средах изоляция на уровне контейнеров или виртуальных машин⁵⁰ помогает удерживать границы процессов и памяти, но эти защиты могут со временем ослабевать из-за ошибок конфигурации или уязвимостей цепочки поставок.

Например, в регулируемом развертывании ML в здравоохранении⁵¹ проверки целостности могут включать три контрольных шлюза:

• Целостность модели: проверка хеша модели по подписанному манифесту.
• Целостность зависимостей: проверка того, что среда выполнения использует только одобренные пакеты Python.
• Целостность выполнения: проверка того, что инференс выполняется внутри подписанной и аттестованной виртуальной машины.

Эти проверки обеспечивают соответствие таким нормам, как требования HIPAA⁵² к целостности и принцип подотчетности GDPR, ограничивают риск незаметных сбоев и создают криминалистический след на случай аудита или утечки.

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

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

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

Реагирование и откат

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

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

Одна из распространенных стратегий — откат модели, при котором система возвращается к ранее проверенной версии модели. Например, если недавно развернутая модель обнаружения мошенничества начинает неверно классифицировать транзакции, система может вернуться к последней заведомо исправной контрольной точке, восстанавливая обслуживание, пока затронутая версия помещается в карантин. Механизмы отката требуют версионированного хранения моделей, которое обычно поддерживается платформами MLOps, такими как MLflow, TFX или SageMaker.

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

Ограничение трафика (traffic throttling) — еще один инструмент оперативного реагирования. Если злоумышленник проверяет публичный API инференса большим объемом запросов, система может ограничить частоту запросов или временно заблокировать нарушающие диапазоны IP, продолжая обслуживать доверенных клиентов. Эта техника сдерживания помогает предотвратить злоупотребления без полного отключения системы.

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

• Промпты: сообщения пользователя и системные сообщения показывают, что модели было велено делать.
• Извлеченные документы: контекст поиска показывает, какое внешнее содержимое повлияло на ответ.
• Вызовы инструментов: имена инструментов, аргументы и результаты показывают, какие внешние побочные эффекты были попытаны или выполнены.
• Решения классификаторов политик: выходы классификаторов безопасности и соответствия показывают, обнаружили ли защитные механизмы поведение.
• Журналы доступа к секретам: записи о доступе к учетным данным и приватным данным показывают, было ли раскрыто чувствительное состояние системы.

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

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

Наконец, организациям следует внедрить практику постинцидентного разбора. Она включает документирование первопричин, выявление пробелов в обнаружении или реагировании и обновление политик и сценариев действий (плейбуков). Разборы инцидентов помогают превращать операционные сбои в практические улучшения на всем жизненном цикле «проектирование — развертывание — мониторинг».

Основы аппаратной безопасности

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

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

Граница доверия становится особенно важной, когда системы должны соответствовать нормативным требованиям. Системы здравоохранения на базе ML, которые обрабатывают защищенную медицинскую информацию по HIPAA⁵², должны внедрять технические меры защиты: контроль доступа, аудит, защиту целостности и безопасность передачи. Системы, обрабатывающие персональные данные в территориальной и материальной сфере действия GDPR⁸, должны также демонстрировать надлежащие технические и организационные меры, включая принципы защиты данных по умолчанию (data protection by design). Аппаратная безопасность сама по себе эти требования не выполняет, но она обеспечивает гарантии загрузки, выполнения, управления ключами и идентичности устройства, на которые программные средства контроля часто опираются.

Каждый примитив аппаратной безопасности отвечает на один вопрос доверия, что суммировано в таблице. Эти механизмы разделяют целостность запуска, изоляцию во время выполнения, хранение ключей и идентичность устройства. Безопасная загрузка спрашивает, стартовала ли система с подлинного кода. Доверенные среды исполнения (TEE) спрашивают, может ли чувствительное вычисление выполняться, несмотря на недоверенного хоста. Аппаратные модули безопасности (HSM) спрашивают, где криптографические ключи можно генерировать и использовать, не открывая их обычной памяти. Физически неклонируемые функции (PUF) спрашивают, может ли устройство доказать аппаратно привязанную идентичность, которую нельзя ни клонировать, ни извлечь.

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

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

Совместное проектирование аппаратного и программного обеспечения

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

Аппаратные механизмы безопасности вносят измеримые накладные расходы, которые нужно учитывать при проектировании системы. Переключение миров в ARM TrustZone добавляет примерно 300–1000 тактов в зависимости от поколения процессора и состояния кэша (0,6–2 мкс на частоте 500 МГц) задержки на каждый переход между безопасным и небезопасным мирами. Криптографические операции в защищенном режиме обычно потребляют на 15–30 процентов больше энергии, чем обычное выполнение, что влияет на время работы от батареи в мобильных приложениях ML. Переключение контекста Intel SGX добавляет 15–30 мкс накладных расходов на инференс, что составляет 2 процента энергетических накладных расходов для типичных граничных рабочих нагрузок ML.

Функции безопасности масштабируются иначе, чем вычислительные ресурсы. Ограничения памяти TEE задают размер модели независимо от доступной системной памяти. Модель ResNet-18 занимает около 46,8 МБ при весах FP32 или 11,7 МБ при весах INT8, а ResNet-50 — около 102,4 МБ при весах FP32 или 25,6 МБ при весах INT8, без учета активаций и буферов выполнения. Эти ограничения создают архитектурные решения, которые нужно принимать на ранних этапах проектирования системы.

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

Разные модели угроз и уровни защиты требуют количественного анализа компромиссов. Для рабочих нагрузок ML, которым нужна криптографическая проверка, операции AES-256 добавляют 0,1–0,5 мс на инференс в зависимости от размера модели и наличия аппаратного ускорения.

Сценарий: налог доверенных вычислений

Задача: Команда, развертывающая модель мониторинга здоровья, сравнивает три уровня безопасности:

1. Открытый текст: стандартный инференс.
2. Зашифрованный транспорт (AES): модель и данные зашифрованы при хранении и передаче.
3. Зашифрованные вычисления (полностью гомоморфное шифрование, FHE): инференс выполняется над зашифрованными данными.

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

Расчет: Задержка инференса масштабируется в зависимости от сложности протокола безопасности.

1. Открытый текст: 20 мс.
2. AES-256: 20 мс + 0,5 мс = 20,5 мс (пренебрежимо малый налог).
3. FHE: 20 мс $\times$ 10 000× = 200 секунд.

Системный вывод: Безопасность — это компромисс между задержкой и полезностью. Стандартное шифрование (AES) «почти бесплатно» на оборудовании с криптографическим ускорением, но защищает данные только между вычислениями. Вычисления с сохранением приватности (FHE) защищают данные во время вычислений, но стоят в 10 000 раз дороже по производительности. Для монитора реального времени этот пример делает FHE архитектурно непрактичным. Предложения конфиденциальных вычислений, такие как Intel SGX и NVIDIA H100 Confidential Computing, иллюстрируют другую точку проектирования: аппаратную изоляцию при гораздо меньшей задержке, чем у FHE, и с другими допущениями о доверии.

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

Операции гомоморфного шифрования могут создавать вычислительные накладные расходы на порядки величины: у полностью гомоморфного шифрования (FHE) они обычно выше, а у частично гомоморфного (somewhat homomorphic) — ниже. Поэтому они жизнеспособны в основном для небольших моделей или офлайн-сценариев, где сильные гарантии приватности оправдывают цену производительности, и поэтому многие производственные системы далее рассматривают аппаратно обеспечиваемую изоляцию.

Доверенные среды исполнения

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

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

Хорошо задокументированный пример — Secure Enclave от Apple, который обеспечивает изолированное выполнение и безопасное хранение ключей на устройствах Apple. Отделение криптографических операций и биометрических данных от основного процессора позволяет Secure Enclave сохранять защиту учетных данных пользователя и функций Face ID даже при компрометации ядра процессора приложений (Apple, 2024). Та же гарантия изоляции повторяется в отраслях с критичными для безопасности требованиями — от плоскостей управления 5G и мобильных платежей до носимой диагностики и автомобильных систем ADAS, — везде, где целостность модели, приватность пользователя или соответствие нормам не подлежат обсуждению.

Удаленная аттестация замыкает распределенный контур доверия: прежде чем два компонента обменяются чувствительными данными или обновлениями модели, один из них может криптографически проверить, что другой выполняет одобренный код внутри ожидаемой аппаратно защищенной границы. Что TEE меняет для развертывания ML — так это границу доверия: инференс и обучение выполняются внутри анклава, поэтому промежуточные активации, чувствительные входы, веса модели и подлинность обновлений защищены от наблюдения и подмены на системном уровне, а распределенные компоненты могут обмениваться данными по аттестованным каналам. Цена — память. Каждый защищенный байт должен помещаться в ограниченную защищенную область анклава, поэтому приходится выбирать между сжатием модели и разбиением инференса так, чтобы внутри границы выполнялись только чувствительные слои.

Основные свойства безопасности TEE достигаются четырьмя механизмами:

• Изолированное выполнение: код работает в отдельном режиме процессора, недоступном для обычной операционной системы.
• Безопасное хранение: чувствительные активы, такие как криптографические ключи или токены аутентификации, хранятся в памяти, доступной только TEE.
• Защита целостности: код и данные проверяются перед выполнением с помощью аппаратно закрепленных хешей или подписей.
• Шифрование данных внутри TEE: данные, обрабатываемые внутри TEE, зашифрованы, поэтому промежуточные результаты недоступны без соответствующих ключей, которыми управляет сама TEE.

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

Несколько коммерческих платформ предоставляют функциональность TEE, адаптированную к разным контекстам развертывания. ARM TrustZone⁵⁶ обеспечивает выполнение в безопасном и обычном мирах на системах ARM и широко используется в мобильных и IoT-приложениях. Intel SGX⁵⁷ реализует безопасность на основе анклавов для облачных и настольных систем, позволяя выполнять защищенные вычисления даже на недоверенной инфраструктуре. Secure Execution Environment от Qualcomm поддерживает безопасные мобильные транзакции и аутентификацию пользователя. Secure Enclave от Apple остается каноническим примером аппаратно изолированного сопроцессора безопасности в потребительских устройствах (Apple, 2024).

Рисунок иллюстрирует практическую архитектуру безопасного анклава, встроенного в проект системы на кристалле (SoC). Анклав включает выделенный процессор, движок AES, генератор истинно случайных чисел (TRNG), ускоритель криптографии с открытым ключом (PKA) и защищенный интерфейс I2C к энергонезависимой памяти. Эти компоненты работают изолированно от основного процессора приложений и подсистемы памяти. Движок защиты памяти обеспечивает контроль доступа, а криптографические операции, например шифрование флеш-памяти NAND, выполняются внутри анклава с ключами, которыми управляет сам анклав. Физическое отделение безопасного выполнения и управления ключами от основной системы ограничивает последствия компрометаций системного уровня и создает аппаратно обеспечиваемое доверие (Apple, 2024).

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

Эта архитектура лежит в основе безопасного развертывания приложений машинного обучения на потребительских устройствах. Например, система Face ID от Apple использует конвейер биометрии, защищенный Secure Enclave: данные с камеры TrueDepth преобразуются защищенной частью Neural Engine в математическое представление, которое затем сравнивается с зарегистрированными данными лица, защищенными Secure Enclave. Изображения лица, полученные в обычном режиме, отбрасываются после вычисления представления, а данные Face ID остаются зашифрованными и хранятся только на устройстве, а не отправляются Apple и не включаются в резервные копии (Apple, 2024). Урок для систем ML состоит в том, что биометрические модели, шаблоны и логика сравнения должны быть привязаны к аппаратной изоляции и безопасным путям обновления, а не рассматриваться как обычные данные приложения.

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

Энергоэффективность — еще одно соображение, особенно для устройств с ограниченным запасом батареи. TEE обычно потребляют дополнительную мощность из-за защищенного доступа к памяти, криптографических вычислений и логики аппаратной защиты. Во встроенных системах с ограниченными ресурсами эти издержки могут ограничивать их применение. С точки зрения масштабируемости и гибкости защищенные границы, которые обеспечивают TEE, могут осложнять распределенное обучение или федеративный инференс, где требуется безопасная координация между анклавами.

Спрос на рынке также различается. В некоторых потребительских приложениях воспринимаемый уровень угроз может быть слишком низким, чтобы оправдать внедрение TEE. Системы с TEE могут подлежать формальной сертификации безопасности, например Common Criteria или оценке в рамках Агентства Европейского союза по кибербезопасности (ENISA), что добавляет время и расходы. Поэтому TEE лучше всего подходят для развертываний, где ожидаемая модель угроз, включающая состязательных пользователей, арендаторов облака и злоумышленников из числа инсайдеров, оправдывает инвестиции.

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

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

Безопасная загрузка

Безопасная загрузка (Secure Boot) — это механизм, который гарантирует, что устройство загружает только те программные компоненты, которые криптографически проверены и явно авторизованы производителем. При запуске каждая стадия процесса загрузки — загрузчик, ядро и базовая операционная система — сверяется с заведомо корректной цифровой подписью. Если какая-либо подпись не проходит проверку, последовательность загрузки останавливается, не давая выполниться неавторизованному или вредоносному коду. Эта модель цепочки доверия обеспечивает целостность системы начиная с самой первой выполненной инструкции.

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

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

Безопасная загрузка часто работает в связке с аппаратными TEE, создавая более доверенный стек выполнения. Рисунок отслеживает многоуровневую последовательность проверки: микропрограмма платформы и компоненты загрузки проверяются до того, как разрешается выполнение криптографических операций или рабочих нагрузок ML (Regenscheid, 2018). Во встроенных системах эта архитектура повышает устойчивость к компрометации до запуска.

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

Похожая цепочка доверия в реальном мире встречается в устройствах Apple с поддержкой Face ID, которая использует машинное обучение для распознавания лиц. Чтобы Face ID работал безопасно, стек устройства — от первого включения до биометрического конвейера — должен быть проверяемо доверенным.

При запуске устройства подписанные цепочки загрузки проверяют программное обеспечение процессора приложений и микропрограмму Secure Enclave до того, как станут доступны чувствительные сервисы. Микропрограмма, загружаемая в Secure Enclave, цифрово подписана Apple, и любое несанкционированное изменение приводит к сбою проверки. После проверки Secure Enclave участвует в более широкой доверенной цепочке загрузки, которая защищает биометрические данные и криптографические ключи устройства (Apple, 2021; Apple, 2024).

После того как устройство завершает последовательность безопасной загрузки, конвейер Face ID может аутентифицировать пользователя. Камера TrueDepth проецирует и считывает тысячи инфракрасных точек, чтобы построить карту лица пользователя, а защищенный биометрический конвейер вычисляет математическое представление и сравнивает его с зарегистрированными данными лица, защищенными Secure Enclave. Данные Face ID зашифрованы, остаются на устройстве и не включаются в резервные копии (Apple, 2024). Поэтому цепочка безопасной загрузки защищает не только операционную систему, но и допущения о доверии, в рамках которых выполняются биометрические компоненты ML.

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

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

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

Некоторые системы ограничивают контроль пользователя в пользу моделей безопасности, привязанных к поставщику, ограничивая возможность обновления или настройки. В ответ появились загрузчики с открытым исходным кодом, такие как U-Boot и coreboot, которые предлагают функции безопасной загрузки и при этом поддерживают расширяемость и прозрачность.⁵⁸ Чтобы дополнительно масштабировать развертывания доверенных устройств, стандарты идентичности устройств, такие как Device Identifier Composition Engine (Trusted Computing Group, 2018) и IEEE 802.1AR IDevID (IEEE 802.1 Working Group, 2018), предоставляют механизмы безопасной идентичности устройств, выдачи ключей и межвендорного подтверждения доверия.

Безопасная загрузка, при тщательной реализации и при дополнении доверенным оборудованием и безопасными процессами обновления программного обеспечения, образует основу целостности системы для встроенного и распределенного ML. Она обеспечивает уверенность в том, что модель машинного обучения, работающая в производстве, является не только правильной версией, но и выполняется в заведомо исправной среде, закрепленной на аппаратном уровне доверия.

Аппаратные модули безопасности

Если TEE и безопасная загрузка обеспечивают изоляцию во время выполнения и проверку целостности, то аппаратные модули безопасности (HSM) специализируются на криптографических операциях, на которых держатся эти защиты. HSM⁵⁹ — это устойчивое к вскрытию физическое устройство, предназначенное для выполнения криптографических операций и безопасного управления цифровыми ключами. HSM широко применяются в отраслях, важных для безопасности, таких как финансы, оборона и облачная инфраструктура, и они актуальны для защиты конвейера машинного обучения — особенно в развертываниях, где важны конфиденциальность ключей, целостность модели и соответствие нормативным требованиям.

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

В системах машинного обучения HSM повышают безопасность по нескольким направлениям. Их обычно используют для защиты ключей шифрования, связанных с чувствительными данными, которые могут обрабатываться во время обучения или инференса. Эти ключи защищают данные при хранении в контрольных точках модели и безопасную передачу запросов инференса в сетевых средах. Гарантия того, что ключи генерируются, хранятся и используются исключительно внутри HSM, снижает риск утечки ключей, их несанкционированного повторного использования или подмены. В распределенных развертываниях ML HSM выступают корнем доверия для двух дополнительных процессов. Во-первых, они выдают уникальные идентичности устройств, необходимые для аутентификации граничных узлов в протоколах безопасной агрегации федеративного обучения: каждое участвующее устройство подтверждает свое членство сертификатом, ключ подписи которого был сгенерирован и хранится в HSM, что не дает скомпрометированному или подменному узлу внедрить отравленные градиенты в агрегацию. Во-вторых, они выполняют операции оборачивания ключей, необходимые для доставки зашифрованных весов модели непосредственно в доверенную среду исполнения: HSM оборачивает ключ расшифровки модели открытым ключом TEE, привязанным к аттестации, гарантируя, что веса модели расшифровываются только внутри анклава и никогда не появляются в открытом виде в памяти хоста.

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

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

Эти преимущества оплачиваются налогом на устойчивость к вскрытию. Выделенный укрепленный кремний обеспечивает примерно в 10 раз меньшую криптографическую пропускную способность, чем GPU общего назначения, при стоимости $20 000–$100 000 и выше за единицу, и этот единственный компромисс влечет за собой каскад ограничений, важных для любого развертывания ML с ограниченными ресурсами: задержка, которую он добавляет к обмену ключами и расшифровке на лету, может сорвать бюджеты задержки инференса в реальном времени; его непрерывные защищенные операции потребляют энергию, сокращая время работы от батареи на граничных устройствах; его размер и выделенные API требуют переработки печатной платы и программного обеспечения; а выдача уникальных ключей по парку граничных узлов превращает управление идентичностью в задачу распределенных систем. Регулируемые развертывания добавляют еще одну, финальную стоимость: процессы сертификации и соответствия⁶⁰, такие как FIPS 140-2⁶¹ или Common Criteria, могут занимать больше времени, чем обучение модели, которую защищает HSM.

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

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

Физически неклонируемые функции

PUF⁶² обеспечивают аппаратно-внутренний механизм генерации криптографических ключей и аутентификации устройств за счет использования физической случайности полупроводникового производства (Gassend et al., 2002). В отличие от традиционных ключей, которые хранятся в памяти, PUF генерирует секретные значения на основе микроскопических вариаций физических свойств микросхемы. Эти вариации присущи производственным процессам и трудно поддаются клонированию или предсказанию, даже для самого производителя.

Эти вариации возникают из-за неконтролируемых физических факторов, таких как концентрация легирующей примеси, шероховатость края линии и толщина диэлектрика. В результате даже микросхемы, изготовленные по одним и тем же шаблонам проекта, демонстрируют небольшие, но измеримые различия во времени, потреблении энергии или поведении напряжения. Схемы PUF усиливают эти вариации, чтобы получить цифровой выход, уникальный для устройства. Когда на PUF подается определенный входной вызов (challenge), он формирует соответствующий отклик на основе физического «отпечатка» микросхемы. Поскольку эти характеристики практически невозможно воспроизвести, один и тот же вызов даст разные отклики на разных устройствах.

Этот механизм «вызов — отклик» позволяет PUF решать несколько криптографических задач. С его помощью можно выводить ключи, специфичные для устройства, которые никогда не нужно хранить во внешней памяти, что сокращает поверхность атаки на извлечение ключей. Тот же механизм поддерживает безопасную аутентификацию и аттестацию, когда устройствам нужно подтверждать свою идентичность доверенным серверам или аппаратным шлюзам. Эти свойства делают PUF естественным выбором для систем машинного обучения, развернутых во встроенных и распределенных средах.

В приложениях ML PUF дают особые преимущества для защиты систем с ограниченными ресурсами. Например, рассмотрим дрон-камеру, который использует встроенное компьютерное зрение для отслеживания объектов. PUF, встроенный в процессор дрона, может сгенерировать закрытый ключ для шифрования модели во время загрузки. Даже если модель будет извлечена, на другом устройстве, где нет того же отклика PUF, ее нельзя будет использовать. Тот же ключ, выведенный из PUF, можно также использовать для нанесения водяного знака на параметры модели, создавая криптографически проверяемую связь между развернутой моделью и аппаратным обеспечением ее происхождения. Если модель утечет или будет незаконно скопирована, встроенный водяной знак может помочь доказать источник компрометации.

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

Рисунок показывает, как работа PUF зависит от присущих физических вариаций. В общих чертах PUF принимает входной вызов и формирует уникальный отклик, который определяется физической микроструктурой чипа (Gao et al., 2020). Существуют разные варианты: оптические PUF, где вызовом служит световой узор, а откликом — спекл-изображение, и электронные PUF, например Arbiter PUF (APUF), где разница во времени прохождения по путям схемы дает двоичный выход. Другая распространенная реализация — SRAM PUF, который использует состояние SRAM-ячеек при включении питания до инициализации: из-за разброса пороговых напряжений каждая ячейка склонна устанавливаться в предпочтительное значение при первом подключении питания. Эти шаблоны откликов образуют стабильный, воспроизводимый аппаратный «отпечаток».

Физически неклонируемые функции: PUF формируют уникальные аппаратные «отпечатки» из присущих производственных вариаций. На рисунке показаны несколько типов: концепция отпечатка на уровне микросхемы, оптические PUF, использующие спекл-узоры лазерного излучения, электронные arbiter PUF, которые опираются на разницу во времени в ответ на вызов, и SRAM PUF, использующие производственные вариации ячеек памяти.

Несмотря на перспективность, PUF создают несколько проблем при проектировании системы. Их выходы могут быть чувствительны к изменениям окружающей среды, например температуры или напряжения, что может вызвать нестабильность или битовые ошибки в отклике. Чтобы обеспечить надежность, системы PUF часто должны включать коды исправления ошибок или схемы вспомогательных данных. Управление большими наборами пар «вызов — отклик» также поднимает вопросы хранения, согласованности и отзыва. Кроме того, уникальная статистическая структура выходов PUF может сделать их уязвимыми для атак моделирования на основе машинного обучения, если они не защищены от внешнего наблюдения.

С точки зрения производства внедрение технологии PUF может увеличивать стоимость устройства или требовать более сложной топологии. Хотя PUF устраняют необходимость во внешнем хранении ключей, снижая долгосрочный риск безопасности и затраты на выдачу ключей, им могут потребоваться калибровка и тестирование при изготовлении, чтобы обеспечить стабильную работу в разных условиях окружающей среды и при старении устройства.

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

Сравнение механизмов

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

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

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

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

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

Вместе с безопасными многосторонними вычислениями и выбором методов сжатия градиентов из слоя приватности аппаратные механизмы, суммированные в таблице, образуют скорее меню, чем рецепт. Подходящая защита для каждого развертывания зависит от трех взаимодействующих факторов: модели угроз (кто атакует и с какими возможностями), контекста развертывания (какие вычислительные бюджеты и бюджеты задержки существуют) и нормативной среды (какие законодательные требования ограничивают проектирование). Медицинская система, которая обучает федеративные диагностические модели, сталкивается с принципиально иными угрозами, чем публичный чат-бот на основе LLM, и каждая из них требует собственного сочетания механизмов, рассмотренных в этой главе. Таблица представляет структуру выбора защит: она сопоставляет семь типичных контекстов развертывания с их основными угрозами, рекомендуемыми комбинациями защит и количественными компромиссами, которые налагает каждая комбинация. Строки, предписывающие дифференциальную приватность, содержат конкретные значения бюджета приватности ($ϵ$); раздел «Дифференциальная приватность» определяет, что ограничивает $ϵ$ и почему меньшие значения стоят точности, поэтому эти предписания можно читать как целевые ориентиры развертывания и пересматривать после того, как освоен соответствующий аппарат.

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

Контрольные вопросы: сопоставление аппаратных угроз и защит

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

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

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

Дифференциальная приватность

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

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

Определение: дифференциальная приватность

Дифференциальная приватность — это математическая гарантия того, что распределение выходов рандомизированного алгоритма меняется не более чем на ограниченный множитель, когда запись любого отдельного человека добавляется в обучающий набор данных или удаляется из него. Формально это описывается границей $(ϵ,\delta )$: $\mathrm{Pr}[\mathcal{A}(D)\in S]\le e^{ϵ}\mathrm{Pr}[\mathcal{A}(D^{\prime })\in S]+\delta$ для соседних наборов данных $D$ и $D^{\prime }$ и любого измеримого множества выходов $S$ (Dwork et al., 2006; Dwork и Roth, 2014).

1. Значимость: бюджет приватности $ϵ$ превращает алгоритмическое свойство в инженерную валюту, которую можно распределять, комбинировать и расходовать. Отчеты о производственных системах и исследования на эталонных задачах показывают, что бюджеты приватности зависят от развертывания: Apple описывает развертывания локальной DP для телеметрии со значениями $ϵ$ для каждого события, выбранными под сценарий использования, тогда как исследования DP-SGD показывают компромиссы между точностью и вычислениями на эталонных задачах (Apple, 2017; Abadi et al., 2016; Bu et al., 2020; De et al., 2022). Меньшее $ϵ$ повышает уровень шума и обычно снижает точность модели (рисунок); DP-SGD может также снижать пропускную способность обучения, поскольку обрезка градиентов для отдельных примеров противоречит параллелизму на уровне батча, который делает обучение на ускорителях эффективным.
2. Различие: в отличие от деидентификации, которая удаляет идентификаторы из записей и не выдерживает повторной идентификации через вспомогательные данные, и в отличие от контроля статистического раскрытия, который зависит от модели атакующего, дифференциальная приватность — это свойство алгоритма, а не данных: гарантия DP выполняется против любого противника, в том числе такого, у которого есть произвольная побочная информация о других записях набора данных.
3. Распространенная ошибка: частое заблуждение состоит в том, что метка $ϵ$ применяется независимо к каждому обращению к данным. Последовательная композиция $k$ механизмов DP, каждый с потерей приватности ${ϵ}_0$, дает общую потерю не более $k{ϵ}_0$ при базовой композиции; более строгие границы доступны через специфичные для механизма учетчики (раздел «Композиция бюджета приватности»). Система, которая выполняет шаги DP-SGD или отвечает на интерактивные запросы DP к чувствительным данным, должна поэтому отслеживать совокупную потерю и останавливать или перепроектировать выпуск, когда выделенный бюджет исчерпан. Ротация криптографических ключей не сбрасывает потерю приватности, тогда как запрос к фиксированной модели, обученной с DP, является постобработкой и не добавляет потерь приватности при обучении.

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

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

Сценарий со средней зарплатой, введенный в «Определение приватности», использует центральную модель дифференциальной приватности. Каждый человек передает ограниченную зарплату доверенному аналитику; аналитик вычисляет сумму, добавляет одну выборку из распределения Лапласа, откалиброванного под глобальную чувствительность суммы, и делит на размер группы. Это отличается от локальной дифференциальной приватности, при которой каждый человек рандомизирует значение до отправки, а аналитик агрегирует рандомизированные отчеты. Обе модели сравнивают распределения выходов на соседних входах, но их механизмы, допущения о доверии и полезность не взаимозаменяемы.

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

Неразличимость при дифференциальной приватности: Дифференциальная приватность ограничивает, насколько может измениться распределение выходов между соседними наборами данных $D$ и $D^{\prime }$. Параметры приватности ограничивают, но не устраняют информацию, которую наблюдатель может получить о включении одного конкретного человека.

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

Рандомизированный алгоритм $\mathcal{A}$ называется $ϵ$-дифференциально приватным, если для всех соседних наборов данных $D$ и $D^{\prime }$, различающихся одной записью, и для всех выходов $S\subseteq \text{Range}(\mathcal{A})$ выполняется следующее (Dwork et al., 2006; Dwork и Roth, 2014):

$$\mathrm{Pr}[\mathcal{A}(D)\in S]\le e^{ϵ}\mathrm{Pr}[\mathcal{A}(D^{\prime })\in S]$$

Параметр $ϵ$ количественно задает бюджет приватности, представляя максимально допустимую потерю приватности. Для фиксированного механизма и отношения соседства меньшие значения $ϵ$ накладывают более жесткую границу на отношение правдоподобий и обычно требуют больше шума, что может снизить полезность модели. Не существует универсального значения $ϵ$, которое обозначало бы «сильную», «умеренную» или приемлемую приватность: интерпретация зависит от отношения соседства, $\delta$, композиции, защищаемой популяции и последствий вывода. Мультипликативный множитель $e^{ϵ}$ ограничивает отношение правдоподобий между выходами алгоритма на соседних наборах данных, ограничивая то, насколько участие отдельного человека может повлиять на любой конкретный результат.

Рисунок иллюстрирует эту цену на опубликованных эмпирических результатах по двум эталонным наборам данных. Эти точки не задают переносимой «золотой середины», потому что модели, учетчики, режимы обучения и данные различаются. В цитируемых экспериментах MNIST остается сравнительно точным при однозначных бюджетах приватности, тогда как CIFAR-10, обученный с нуля без дополнительных данных, остается сложнее: De et al. (2022) сообщают точность 81,4 процента при $(ϵ,\delta )=(8,10^{-5})$, хотя предобучение и дополнительные открытые данные могут заметно повысить точность приватной классификации изображений.

Опубликованные результаты компромисса приватности и полезности: Точность при выбранных бюджетах приватности по результатам (Abadi et al., 2016; Bu et al., 2020; De et al., 2022). В этих экспериментах MNIST сохраняет сравнительно высокую точность при однозначных бюджетах $ϵ$, тогда как CIFAR-10, обученный с нуля без дополнительных данных, остается сложнее: De et al. сообщают 81,4 процента при $ϵ=8$. Сравнения требуют указания полного механизма, учетчика, отношения соседства, режима обучения и данных, а не только $ϵ$.

Эта граница гарантирует, что поведение алгоритма остается статистически неотличимым независимо от того, присутствуют ли данные какого-либо человека, и тем самым ограничивает информацию, которую можно вывести об этом человеке. На практике DP реализуется добавлением откалиброванного шума к обновлениям модели или ответам на запросы с использованием механизмов Лапласа или гауссовского механизма. Методы обучения вроде дифференцированно приватного стохастического градиентного спуска⁶³ встраивают откалиброванный шум в вычисления обучения, гарантируя, что отдельные точки данных нельзя отличить по выученному поведению модели.

Математические основы и параметры приватности

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

Формулировка $(ϵ,\delta )$-дифференциальной приватности

Определение чистой $ϵ$-DP дает сильные гарантии, но может быть излишне ограничительным для практических приложений ML. Ослабленная формулировка, $(ϵ,\delta )$-дифференциальная приватность, допускает малую вероятность $\delta$ того, что потеря приватности превысит $ϵ$. Это ослабление оказывается необходимым для глубокого обучения, где для возмущения градиентов предпочитают гауссовский шум (он имеет неограниченный носитель), а не шум Лапласа.

Формально рандомизированный алгоритм $\mathcal{A}$ удовлетворяет $(ϵ,\delta )$-дифференциальной приватности, если для всех соседних наборов данных $D,D^{\prime }$ и всех измеримых множеств выходов $S$:

$$\mathrm{Pr}[\mathcal{A}(D)\in S]\le e^{ϵ}\mathrm{Pr}[\mathcal{A}(D^{\prime })\in S]+\delta$$

Параметр $\delta$ представляет вероятность того, что гарантия приватности катастрофически нарушится. На практике $\delta$ обычно выбирают меньше обратной величины размера набора данных, часто $\delta <1/n_{\text{records}}$ или еще меньше в зависимости от политики и модели угроз; меньшее $\delta$ усиливает границу вероятности отказа ценой дополнительных потерь полезности. Для набора данных из 1 миллиона записей $\delta =10^{-12}$ гарантирует, что вероятность превысить границу $ϵ$ остается ничтожно малой.

Механизмы шума для достижения дифференциальной приватности

Системы ML реализуют дифференциальную приватность через тщательно откалиброванное внедрение шума. Два основных механизма, используемых в системах ML, различаются распределением шума и областью применимости. Первый — механизм Лапласа. Для чистой $ϵ$-DP он добавляет шум из распределения $\text{Lap}(\Delta f/ϵ)$, где $\Delta f$ — глобальная чувствительность функции (максимальное изменение выхода при изменении одной записи). Для запроса $f$ приватизированный выход равен:

$$\tilde{f}(D)=f(D)+\text{Lap}\left(\frac{\Delta f}{ϵ}\right)$$

Распределение Лапласа имеет плотность $p(x)=\frac{ϵ}{2\Delta f}\exp \left(-\frac{ϵ|x|}{\Delta f}\right)$ с параметром масштаба $b=\Delta f/ϵ$. Для фиксированного запроса и отношения соседства ужесточение границы с $ϵ=1,0$ до $ϵ=0,1$ требует в 10 раз больше шума.

Вывод для распределения Лапласа показывает, почему масштаб шума должен соответствовать чувствительности. Чтобы доказать, что механизм Лапласа дает $ϵ$-DP, рассмотрим отношение вероятностей выходов на соседних наборах данных $D$ и $D^{\prime }$. Пусть $f(D)=v$ и $f(D^{\prime })=v^{\prime }$, где $|v-v^{\prime }|\le \Delta f$ по границе чувствительности. Для любого выхода $y$ отношение вероятностей равно:

$$\frac{p(y|D)}{p(y|D^{\prime })}=\frac{\exp (-ϵ|y-v|/\Delta f)}{\exp (-ϵ|y-v^{\prime }|/\Delta f)}=\exp \left(\frac{ϵ(|y-v^{\prime }|-|y-v|)}{\Delta f}\right)$$

По неравенству треугольника $|y-v^{\prime }|-|y-v|\le |v-v^{\prime }|\le \Delta f$. Поэтому:

$$\frac{p(y|D)}{p(y|D^{\prime })}\le \exp \left(\frac{ϵ\cdot \Delta f}{\Delta f}\right)=e^{ϵ}$$

Это доказывает, что механизм Лапласа удовлетворяет $ϵ$-дифференциальной приватности. Вывод показывает, почему калибровка чувствительности существенна: масштаб шума должен соответствовать максимально возможному изменению выхода запроса, чтобы маскировать вклад отдельных людей.

Гауссовский механизм подходит для случая ML, где допустима ослабленная гарантия $(ϵ,\delta )$. Он добавляет шум со стандартным отклонением $\sigma$, откалиброванным по $ϵ$, $\delta$ и ${\ell }_2$-чувствительности ${\Delta }_{2}f$:

$$\tilde{f}(D)=f(D)+\mathcal{N}\left(0,{\sigma }^{2}I\right)$$

В отличие от механизма Лапласа, который дает чистую $ϵ$-DP, гауссовский механизм обычно требует ослабленной формулировки $(ϵ,\delta )$-DP, потому что сдвинутые гауссовские плотности могут иметь произвольно большие отношения правдоподобий в хвостах; член $\delta$ ограничивает вероятность этих событий в хвостах. Вывод опирается на анализ случайной величины потери приватности.

Для соседних наборов данных с ${\ell }_2$-чувствительностью ${\Delta }_{2}f$ потеря приватности на выходе $y$ равна:

$$L_{\text{priv}}(y)=\ln \frac{p(y|D)}{p(y|D^{\prime })}=\frac{\Vert y-f(D^{\prime }){\Vert }_2^2-\Vert y-f(D){\Vert }_2^2}{2{\sigma }^2}$$

Когда $y=f(D)+z$ при шуме $z\sim \mathcal{N}(0,{\sigma }^{2}I)$, потеря приватности становится сдвинутой гауссовской величиной со средним $\frac{{\Delta }_2{f}^2}{2{\sigma }^2}$ и дисперсией $\frac{{\Delta }_2{f}^2}{{\sigma }^2}$. Для одного применения механизма и $0<ϵ<1$ классическая достаточная калибровка такова:

$$\sigma \ge \frac{{\Delta }_{2}f}{ϵ}\sqrt{2\ln \left(\frac{1.25}{\delta }\right)}$$

Эта достаточная граница — результат для одноразового гауссовского механизма в данной области параметров. Ее нельзя использовать, подставляя итоговый бюджет обучения в запуск DP-SGD: обучение с выборкой комбинирует множество механизмов и требует учетчика выборочного гауссовского механизма. Меньшие $ϵ$ или $\delta$, как правило, требуют больше шума, но изменение точности нужно измерять для конкретной задачи и процедуры обучения.

Сценарий: одноразовый гауссовский механизм

Задача: определить минимальный множитель шума $\sigma$, необходимый гауссовскому механизму для достижения $(ϵ,\delta )$-дифференциальной приватности для одного векторного запроса.

Переменные: ${\ell }_2$-чувствительность ${\Delta }_{2}f=$ 1, целевое $ϵ=$ 0,5, $\delta =$ $10^{-5}$.

Расчет: классическая достаточная граница требует $\sigma \ge$ 9,7.

Системный вывод: этот расчет относится к одиночному гауссовскому выпуску. При обучении DP-SGD композиция по тысячам шагов оптимизации требует учетчиков моментов или Rényi DP, чтобы не допустить взрывного роста общего бюджета приватности.

Гауссовский шум предпочитают в глубоком обучении, потому что нормы градиентов естественно ограничены в ${\ell }_2$-пространстве, что делает анализ чувствительности разрешимым. Гауссовский механизм также комбинируется более плотно при учете через Rényi DP.

Следующие подразделы строят лестницу учета приватности: простая композиция складывает потери в худшем случае, учет моментов отслеживает их распределение, а Rényi DP комбинирует зашумленные шаги SGD перед пересчетом обратно в бюджет $(ϵ,\delta )$.

Случайная величина потери приватности и учетчик моментов

Более точный подход к анализу приватности отслеживает случайную величину потери приватности, которая количественно оценивает, сколько информации об отдельном человеке утекает из одного наблюдения. Для соседних наборов данных $D,D^{\prime }$ и выхода алгоритма $o$ потеря приватности равна:

$$L_{\text{priv},(D,D^{\prime })}^{(o)}=\ln \frac{\mathrm{Pr}[\mathcal{A}(D)=o]}{\mathrm{Pr}[\mathcal{A}(D^{\prime })=o]}$$

Случайная величина потери приватности характеризует логарифм отношения правдоподобий между выходами на соседних наборах данных. Для $(ϵ,\delta )$-DP хвостовая вероятность должна удовлетворять условию $\mathrm{Pr}[L_{\text{priv}}>ϵ]\le \delta$. Такая формулировка позволяет анализировать композицию через производящие функции моментов.

Техника учетчика моментов, введенная для DP-SGD в работе Abadi et al. (2016), отслеживает моменты высших порядков распределения потери приватности. Вместо вычисления композиции в худшем случае она анализирует фактическое распределение потери приватности по итерациям обучения. Для механизма $\mathcal{M}$ с потерей приватности $L_{\text{priv}}$ учетчик моментов вычисляет:

$${\alpha }_{\mathcal{M}}({\lambda }_{\text{mom}})=\underset{D,D^{\prime }}{\max }\ln {\mathbb{E}}_{o\sim \mathcal{M}(D)}\left[{\left(\frac{\mathrm{Pr}[\mathcal{M}(D)=o]}{\mathrm{Pr}[\mathcal{M}(D^{\prime })=o]}\right)}^{{\lambda }_{\text{mom}}}\right]$$

для порядка момента ${\lambda }_{\text{mom}}$. После $k$ композиций накопленный момент равен $k\cdot {\alpha }_{\mathcal{M}}({\lambda }_{\text{mom}})$. Затем неравенство Маркова дает границы $(ϵ,\delta )$:

$$ϵ(\delta )=\underset{{\lambda }_{\text{mom}}>0}{\min }\left[\frac{k\cdot {\alpha }_{\mathcal{M}}({\lambda }_{\text{mom}})+\ln (1/\delta )}{{\lambda }_{\text{mom}}}\right]$$

Численный результат зависит от правила выборки, доли выборки, множителя шума, числа шагов, отношения соседства и учетчика. Например, Abadi et al. (2016) сообщают, что при доле выборки $q=0,01$, множителе шума $\sigma =4$ и $\delta =10^{-5}$ их учетчик моментов дает $ϵ=1,26$ после 100 эпох и $ϵ=2,55$ после 400 эпох; соответствующие границы сильной композиции равны 9,34 и 24,22. Эти значения относятся к данному эксперименту и не являются переносимыми константами для другого запуска DP-SGD.

Дифференциальная приватность Rényi и композиция

Дифференциальная приватность Rényi (RDP), введенная в работе Mironov (2017), дает удобное представление для композиции, отслеживая дивергенцию Rényi. Механизм $\mathcal{M}$ удовлетворяет $(\alpha ,\epsilon )$-RDP, если для всех соседних $D,D^{\prime }$:

$${\mathcal{D}}_{\alpha }(\mathcal{M}(D)\Vert \mathcal{M}(D^{\prime }))=\frac{1}{\alpha -1}\ln {\mathbb{E}}_{x\sim \mathcal{M}(D^{\prime })}\left[{\left(\frac{\mathrm{Pr}[\mathcal{M}(D)=x]}{\mathrm{Pr}[\mathcal{M}(D^{\prime })=x]}\right)}^{\alpha }\right]\le \epsilon$$

где $\alpha >1$ — порядок Rényi. Композиция RDP проста: если механизм ${\mathcal{M}}_i$ удовлетворяет $(\alpha ,{\epsilon }_i)$-RDP, то их композиция удовлетворяет $(\alpha ,{\sum }_i{\epsilon }_i)$-RDP. Такое представление позволяет не применять повторно общую теорему композиции $(ϵ,\delta )$ к каждому шагу обучения.

Для невыборочного гауссовского механизма с единичной ${\ell }_2$-чувствительностью и стандартным отклонением шума $\sigma$ гарантия RDP равна:

$$\epsilon (\alpha )=\frac{\alpha }{2{\sigma }^2}$$

Субдискретизация меняет этот механизм. В частности, $q^2\alpha /(2{\sigma }^2)$ — лишь приближение главного порядка в ограниченных режимах, а не гарантия приватности, которой можно подтвердить запуск DP-SGD. Учетчик выборочного гауссовского механизма должен оценить заданную схему выборки и отношение соседства при нескольких порядках Rényi, скомпоновать полученные границы для каждого шага по фактическому числу шагов и затем перевести результат в $(ϵ,\delta )$-DP. Производственные реализации должны использовать проверенный учетчик, например Google DP Accounting, TensorFlow Privacy или Opacus, и фиксировать его версию и соглашение о выборке вместе с выпущенной моделью.

Эта гарантия RDP может быть переведена в $(ϵ,\delta )$-DP по формуле:

$$ϵ=\epsilon +\frac{\ln (1/\delta )}{\alpha -1}$$

оптимизированной по $\alpha$. Учет моментов и представление через RDP тесно связаны; какая реализация дает наиболее строгую опубликованную границу, зависит от механизма, порядков и численного учетчика, а не от универсального множителя.

Пример входных данных учетчика: DP-SGD для классификации изображений

Рассмотрим обучение CNN на 50 000 изображениях CIFAR-10 с целевой приватностью $(ϵ,\delta )=($ 3 $,10^{-5})$. Используем DP-SGD со следующими параметрами:

• Пуассоновская выборка с ожидаемым размером батча $B=$ 4 000 (вероятность включения $q=B/n_{\text{records}}=$ 0,08)
• Норма обрезки градиентов для отдельных примеров $C=$ 1
• Множитель шума $\sigma =$ 1,3 (масштаб шума относительно обрезки)
• Обучение в течение $N_{\text{epochs}}=$ 60 эпох ($k=N_{\text{epochs}}\cdot n_{\text{records}}/B=$ 750 шагов)

Эти входные данные не определяют гарантию приватности через упрощенную формулу $q^2\alpha /(2{\sigma }^2)$. Перед выпуском проверенный учетчик выборочного гауссовского механизма должен оценить пуассоновскую выборку при отношении соседства «добавление/удаление», скомпоновать все 750 шагов, пересчитать к заданному $\delta$ и проверить, достигается ли целевое $ϵ=$ 3. Запись о выпуске должна фиксировать библиотеку и версию учетчика, соглашение о выборке, отношение соседства и вычисленные порядки Rényi.

Обучение в течение $N_{\text{epochs}}=$ 25 эпох уменьшает число скомпонованных шагов, а уменьшение ожидаемого размера батча до $B=$ 2 000 меняет вероятность пуассоновского включения на $q=$ 0,04. Учетчик нужно перезапускать при любом из этих изменений; ни одному из направлений нельзя приписывать численное $ϵ$ через упрощенную формулу главного порядка. Достижение цели обычно требует настройки шума, числа проходов или выборки с одновременным измерением полученной полезности и вычислительных затрат.⁶⁴

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

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

Увеличение шума для снижения $ϵ$ может ухудшить точность модели, особенно в режимах с малым объемом данных или при мелкозернистой классификации. Поэтому DP часто применяют выборочно (либо во время обучения на чувствительных наборах данных, либо при инференсе, когда возвращаются агрегированные статистики), чтобы сбалансировать приватность и цели производительности (Dwork и Roth, 2014).

Композиция бюджета приватности

Критический аспект дифференциальной приватности состоит в том, что потеря приватности накапливается при дополнительных зависящих от данных выпусках DP о той же защищаемой популяции. Если организация обучает и выпускает 10 моделей на одном наборе данных, каждая с $ϵ=1$, базовая композиция дает общую границу $ϵ=10$, хотя специфичный для механизма учетчик может дать более строгую границу. Многократное использование одной и той же выпущенной модели DP — это постобработка, которая не увеличивает ее потерю приватности при обучении.

Каждый дополнительный выпуск DP с защищаемыми данными комбинируется с предыдущими выпусками.

Реестр приватности опирается на три инструмента композиции:

• Простая композиция: запуск $k$ механизмов с ${ϵ}_i$ гарантирует приватность $\sum {ϵ}_i$. Это слабая граница.
• Продвинутая композиция: дает более строгие границы, показывая, что потеря приватности растет примерно как $\sqrt{k}$.
• Дифференциальная приватность Rényi (RDP): каркас, используемый в глубоком обучении (например, в DP-SGD), который дает еще более строгий учет композиции, необходимый для обучения нейронных сетей на тысячах итераций.

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

Количественная оценка компромисса приватности и полезности

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

Компромиссы приватности и точности: Опубликованные точки точности DP-SGD зависят от конкретной постановки. Ранние эксперименты DP-SGD показали высокую цену приватности на MNIST и CIFAR-10 (Abadi et al., 2016), тогда как более поздние работы по классификации изображений показали, что тщательная настройка, более крупные модели и предобучение или дополнительные открытые данные могут заметно повысить точность при приватности (De et al., 2022).

Из этих эмпирических результатов вытекает несколько закономерностей. Во-первых, более простые задачи лучше переносят DP: MNIST остается заметно легче CIFAR-10 в исходных экспериментах DP-SGD. Во-вторых, решающее значение имеют размер набора данных и режим обучения: большие наборы и открытое предобучение могут повысить отношение сигнала к шуму и изменить видимую границу «приватность — полезность». В-третьих, кривая «приватность — точность» нелинейна: ужесточение $ϵ$ обычно стоит тем больше полезности, чем меньше бюджет приватности, поэтому каждому развертыванию нужен собственный подбор под задачу, а не опора на общую таблицу.

Структура решения о развертывании дифференциальной приватности

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

Начните с нормативного и правового требования. DP становится особенно ценным, когда политика, контракты, аудиты или оценки рисков требуют подтверждаемых границ приватности. Регуляторы редко предписывают DP по названию, но принцип защиты данных по умолчанию в GDPR (GDPR, 2016) и концепция приватности по замыслу (Cavoukian, 2012) мотивируют проектирование систем с сохранением приватности, а технические меры защиты HIPAA требуют таких средств контроля, как контроль доступа, аудит, защита целостности, аутентификация и безопасность передачи (HHS, 2005). DP может дополнять эти средства, документируя математическую границу потери приватности, но не заменяет реализацию мер защиты HIPAA. Организациям, обрабатывающим данные здоровья ЕС, медицинские записи США или персональные данные Калифорнии, подпадающие под CCPA/CPRA, следует рассматривать DP как один из возможных механизмов поддержки соответствия.

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

Затем набор данных и задача определяют, применима ли гарантия на практике. Эффективное обучение с DP зависит от того, остается ли обрезанный сигнал обучаемым после откалиброванного шума:

• Эффективный размер выборки: больше независимых записей может улучшить отношение сигнала к шуму, но никакой универсальный порог по числу записей не гарантирует полезность. Повторные наблюдения, дисбаланс классов и редкость подгрупп могут сделать эффективный размер выборки гораздо меньше числа строк.
• Сложность задачи: простые задачи классификации (бинарные или с малым числом классов) лучше переносят шум, чем мелкозернистое распознавание или задачи генерации.
• Распределение чувствительности данных: если чувствительные атрибуты сосредоточены в редких подгруппах, DP может непропорционально ухудшать качество на этих подгруппах, что вызывает вопросы справедливости.

Эти ограничения решают, является ли DP пригодной к развертыванию гарантией или лишь формальным свойством, которое уничтожает полезность задачи.

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

Наконец, вычислительный бюджет определяет, можно ли выпустить проект. Обучение с DP обычно требует в 2–5$\times$ больше вычислений, чем обучение без приватности, из-за вычисления градиентов для отдельных примеров и больших размеров батчей, необходимых для компенсации шума. При ограниченных вычислительных ресурсах эти издержки могут оказаться непомерными. Облачные развертывания могут масштабировать вычисления, но сценарии обучения на границе могут счесть DP непрактичной.

Сводная матрица решений

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

Контрольные вопросы: применение структуры решений DP

Носимый кардиомонитор классифицирует аритмии по сырым сигналам ЭКГ, собираемым на устройстве у 5 000 зарегистрированных пациентов. Продукт продается в Соединенных Штатах и подпадает под HIPAA; конвейер обучения работает в облачном кластере из 8 GPU, а конкурирующий поставщик заинтересован в извлечении модели. Примените каждый из пяти критериев решения, чтобы определить, нужен ли DP-SGD в конвейере обучения.

• Критерий 1 (нормативный): определите, поддерживает ли HIPAA здесь гарантию DP, и укажите документацию, которую DP предоставляет, а ad hoc деидентификация — нет.
• Критерий 2 (модель угроз): определите популяции противников, важные для модели кардиомонитора, и оцените атаку на принадлежность как правдоподобную.
• Критерий 3 (характеристики набора данных): оцените эффективный размер выборки, дисбаланс классов, повторные измерения и редкие клинические подгруппы перед выбором механизма.
• Критерий 4 (допустимая потеря полезности): определите критерии приемлемости для ошибок, критичных для безопасности, калибровки и подгрупп, затем измерьте, выполняет ли приватная модель их.
• Критерий 5 (вычисления): взвесьте облачный запуск обучения на 8 GPU и накладные расходы DP-SGD в 2–5$\times$ по сравнению с критериями, которые тянут к DP и от него, затем определите доминирующий сигнал развертывания.

Эта структура рассматривает DP как один инструмент в наборе средств сохранения приватности, а не как универсальное решение. Производственные развертывания часто сочетают учтенный механизм DP с минимизацией данных, федеративным выполнением там, где централизация необработанных данных исключена, безопасной агрегацией для конфиденциальности вкладов и контролем доступа для безопасности развертывания. Следующий аудит DP-SGD определяет входные данные, которые внешний проверенный учетчик должен оценить, прежде чем выпуск сможет заявлять операционный бюджет приватности.

Сценарий: аудит входных данных учетчика DP-SGD

Сценарий: обучить классификатор тональности на 100 000 отзывов клиентов с целевой приватностью $ϵ\le$ 8 и $\delta =$ $10^{-6}$.

Шаг 1: настройте параметры DP-SGD.

• Размер набора данных: $n_{\text{records}}=$ 100 000
• Ожидаемый размер батча Пуассона: $B=$ 2 000 (вероятность включения $q=B/n_{\text{records}}=$ 0,02)
• Норма обрезки градиентов: $C=$ 1
• Эпохи обучения: $N_{\text{epochs}}=$ 10 (общее число шагов $k=N_{\text{epochs}}\times n_{\text{records}}/B=$ 500)
• Цель: $ϵ=$ 8, $\delta =$ $10^{-6}$

Шаг 2: зафиксируйте кандидатный множитель шума. Для $\sigma =$ 0,8 учетчик должен оценить заданный гауссовский механизм с пуассоновской выборкой и скомпоновать все $k=$ 500 шагов. Соглашение о выборке и отношение соседства являются частью гарантии.

Шаг 3: переведите RDP в DP. Этот пример не приводит численное $ϵ$, полученное через упрощенную формулу главного порядка. Производственный выпуск должен использовать проверенный учетчик выборочного гауссовского механизма, проверить, достигает ли запуск цели $ϵ\le$ 8, и зафиксировать версию библиотеки, соглашение о выборке, отношение соседства и вычисленные порядки.

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

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

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

обрезать градиент каждого примера до нормы C
добавить шум N(0, sigma^2 C^2 I) к сумме обрезанных градиентов, затем разделить на размер батча
сделать один шаг оптимизатора с приватизированным градиентом
после каждого шага накапливать потерю приватности в учетчике
остановить, перенастроить или отклонить запуск, если накопленное epsilon превышает целевой бюджет

Модель зрелости безопасности и приватности

Переход от математических гарантий к производственным средствам контроля требует большего, чем задание значения $ϵ$. Распространенная ошибка — пытаться развернуть сразу все защиты, включая дифференциальную приватность, доверенные среды исполнения, состязательное обучение, водяные знаки моделей и автоматизацию red team, при том что базовые средства контроля остаются слабыми. Модель зрелости вместо этого спрашивает, какое свойство системы сейчас не защищено: граница доступа, приватность данных, целостность модели, устойчивость к состязательным атакам или доказательства управления. Структура зависимостей в таблице связывает этот выбор с защищаемой границей.

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

Слои зрелости накапливаются. Средства контроля доступа и зашифрованные каналы — предварительные условия, потому что защита от извлечения модели не имеет смысла, если реестр открыт или узел обслуживания может загрузить непроверенные веса. Средства контроля приватности становятся необходимыми, когда пользовательские данные попадают в дообучение, персонализацию или петли обратной связи телеметрии; тогда бюджет приватности становится ресурсом системы первого класса, который отслеживается при переобучении, поиске гиперпараметров и A/B-тестах, затрагивающих один и тот же чувствительный набор данных. Средства контроля целостности модели защищают сам путь артефакта: подписанные манифесты, управление ключами, проверки хешей и ворота выпуска гарантируют, что обслуживаемая модель — это та, которая прошла валидацию.

Состязательные защиты вступают в дело, когда атакующий адаптивен, а не действует случайно. Мониторинг запросов и ограничение выходов уменьшают информацию, доступную для атак извлечения, тогда как оценка устойчивости и учения red team проверяют, можно ли склонить модель к небезопасному поведению. Более сильные механизмы, такие как доверенные среды исполнения или сертифицированные защиты, которые дают формальные гарантии устойчивости при заданной границе возмущений, стоит выбирать только тогда, когда модель угроз оправдывает их задержку, аппаратные и эксплуатационные издержки. Управление замыкает цикл: журналы аудита, сопоставления с требованиями, журналы инцидентов и воспроизводимые проверки средств контроля дают доказательства того, что развернутая система по-прежнему выполняет обязательства по приватности и безопасности после изменения модели, данных и трафика.

Разные области проходят эту модель по-разному. Развертывание в здравоохранении ставит учет приватности и доказательства управления на первое место до широкого использования, обращенного к пациентам. Система выявления финансового мошенничества делает упор на контроль доступа, целостность модели и мониторинг злоупотреблений, потому что извлечение и уклонение напрямую меняют финансовые потери. Автономная система делает упор на состязательную устойчивость и доказательства по инцидентам, потому что безопасность зависит от поведения при сдвиге распределения и физических возмущениях. Смысл не в том, чтобы следовать универсальному календарю внедрения; смысл в том, чтобы модель угроз определяла, какая граница средств контроля должна созреть следующей.

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

Заблуждения и ловушки

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

Заблуждение: безопасность через неочевидность обеспечивает достаточную защиту моделей машинного обучения.

Сокрытие архитектур или параметров не дает значимой безопасности, когда атаки «черного ящика» могут быть успешными без внутренних знаний. Как подробно описано в разделе «Защиты от извлечения модели», приведенные примеры извлечения воспроизводят функциональность с точностью 90 процентов при 10 000–100 000 запросах; дневной лимит в 100 000 запросов — допущение сценария, которое показывает, почему простых ограничений частоты может быть недостаточно. Состязательные примеры переносятся между архитектурами с успешностью 60–80 процентов в рассмотренных условиях, используя общие геометрические свойства, а не архитектурные детали. Организации, полагающиеся на секретность, обнаруживают эту слабость, когда «проприетарные» модели восстанавливаются через терпеливые запросы. Эффективная безопасность ML требует надежных защит, работающих по принципу Керкгоффса: нужно считать, что у злоумышленников есть полное знание, и строить защиту через ограничение запросов, возмущение выходов, водяные знаки и обнаружение аномалий, а не через архитектурную секретность.

Ловушка: предположение, что дифференциальная приватность автоматически обеспечивает приватность без учета деталей реализации.

Многие практики считают дифференциальную приватность универсальным решением, не указывая отношение соседства, выбор параметров или учет бюджета. Одно и то же $ϵ$ может описывать разные защиты при разных отношениях соседства, значениях $\delta$, схемах выборки и композициях, тогда как итоговое изменение полезности зависит от модели, задачи и данных. Бюджеты приватности накапливаются при зависящих от данных выпусках: при базовой композиции обучение 10 моделей с $ϵ=1,0$ каждая дает общую границу $ϵ=10$, а не $ϵ=1,0$, хотя специфичный для механизма учетчик может дать более строгую границу. Организации, которые не включают переобучение, подбор гиперпараметров и A/B-тесты в реестр приватности, не смогут подтвердить гарантию, даже если каждое отдельное задание вызывает библиотеку DP.

Заблуждение: федеративное обучение по своей природе обеспечивает защиту приватности без дополнительных мер.

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

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

Это заблуждение побуждает организации сосредотачиваться на предотвращении масштабных утечек и недооценивать точечное отравление. Отравление данных обладает крайне высоким рычагом: отравление всего 0,1 процента обучающих данных (1000 примеров из миллиона) может снизить точность модели на 10–50 процентов. Закладки оказываются еще эффективнее: внедрение триггерных шаблонов в 0,01 процента данных создает модели с чистой точностью 95 процентов и выше, но с успешностью атаки 90 процентов и выше на входах с триггером. Эти закладки сохраняются при переобучении и переносе обучения. Экономика атаки выгодна противнику: создать 1000 отравленных примеров стоит несравнимо дешевле, чем собрать миллионы законных. Для систем, использующих пользовательский контент, злоумышленники внедряют отравленные данные по обычным каналам (фейковые аккаунты, искусно составленные оценки), которые составляют 0,1 процента входов, но заметно сдвигают рекомендации. Организации, которые полагают, что «достаточно чистых» данных дает «достаточно безопасные» модели, убеждаются в обратном, когда противники добиваются непропорционального эффекта минимальной порчей.

Заблуждение: безопасность можно изолировать от остальной системы ML.

Организации часто добавляют защиты к отдельным компонентам (зашифрованное хранение, аутентификацию API, водяные знаки моделей), не учитывая системные векторы атак, которые пересекают несколько границ. Производственная система с сильными защитами API (ограничение частоты в 1000 запросов в день, возмущение выходов, фильтрация top-$k$) выглядит устойчивой изолированно, но злоумышленники обходят их через альтернативные пакетные конечные точки, извлекают пары «запрос — ответ» из незащищенных журналов мониторинга или напрямую скачивают веса моделей из публичных реестров без контроля доступа. Как установлено в разделе «Система приоритизации угроз», эффективная безопасность ML требует целостного моделирования угроз на протяжении всего жизненного цикла: сбор данных, инфраструктура обучения, хранение моделей, развертывание и мониторинг. Одно слабое звено (незашифрованные снимки, неаутентифицированные конечные точки, слишком либеральные политики CORS) компрометирует иначе защищенные системы. Организации обнаруживают это через дорогостоящие инциденты: обходятся API-защиты, модели утекают через конвейеры CI/CD или приватное обучение компрометируется из-за избыточного журналирования.

Ловушка: недооценка расширения поверхности атаки в распределенных системах ML.

Организации эффективно защищают однонодовые системы ML, но не осознают, что распределенные архитектуры вводят дополнительные границы доверия и каналы связи. Топология «все со всеми» имеет $\mathcal{O}(n_{\text{nodes}}^2)$ связей, тогда как кольцо — $\mathcal{O}(n_{\text{nodes}})$. Само по себе число связей не определяет число уязвимостей, но каждый дополнительный узел, учетные данные и канал должны входить в модель угроз.

Топология определяет, как число каналов связи растет с числом узлов.

Распределенное обучение на 128 GPU в 16 машинах позволяет скомпрометированному узлу внедрить отравленные градиенты в глобальную агрегацию, если валидация или устойчивая агрегация этого не сдерживают. Федеративное обучение с 10 000 клиентов создает 10 000 отдельно управляемых конечных точек. Поэтому эффективная безопасность распределенного ML требует моделирования угроз для добавленных узлов и границ: защиты межузловых каналов, управления идентичностью между доменами безопасности и согласования политик в гетерогенной инфраструктуре.

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

Итоги

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

Многоуровневая архитектура защиты простирается от аппаратных якорей доверия в кремнии (TEE, HSM) до защитных механизмов языкового уровня, необходимых для генеративного ИИ. Фундаментальный переход от традиционной кибербезопасности к безопасности ML делает выученные границы решений дополнительной поверхностью атаки. Строгие математические фреймворки, в первую очередь дифференциальная приватность, позволяют инженерам ограничивать утечку участия, извлекая пользу из чувствительных данных. Разборы случаев утечек делают эту архитектуру конкретной: Stuxnet превращает доверие к цепочке поставок в проблему происхождения модели, взлом Jeep Cherokee превращает границы изоляции в средства контроля безопасности, а Mirai превращает слабые конечные точки в риск масштаба парка.

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

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

Безопасная агрегация применяет C³ к конкретной границе приватности. Криптографическое маскирование добавляет вычисления на каждом клиенте и дополнительные раунды коммуникации, тогда как восстановление после выбывания участников (dropout) и пороговая реконструкция добавляют состояние координации на сервере. Механизм убирает прямой просмотр отдельных обновлений, но операционное узкое место может переместиться на медленных клиентов, доли восстановления или завершение раунда. Приватность сохраняется, только если планировщик и план мощностей учитывают сдвинутый критический путь, а не обходят протокол под нагрузкой.

Ключевые выводы: защищайте модель, а не только сервер

• Модель — это поверхность атаки: системы ML наследуют обычные угрозы серверов, но добавляют атаки на саму выученную границу. Отравленные данные, извлечение модели, состязательные входы и инъекция промпта могут скомпрометировать поведение без эксплуатации традиционной программной уязвимости.
• Приватность — это учтенный бюджет: поскольку модели могут кодировать информацию о чувствительных данных, приватность нельзя считать анонимизацией на периметре. Дифференциальная приватность (принцип «инвариант утечки информации») дает ограниченные $(ϵ,\delta )$-утверждения только тогда, когда все зависящие от данных механизмы DP скомпонованы корректно; запрос к фиксированной модели, обученной с DP, является постобработкой и не добавляет потерь приватности при обучении.
• Генеративные системы нуждаются в проверяемых границах действий: инъекция промпта, злоупотребление инструментами и утечка PII проходят через обычные текстовые каналы. Считайте выход модели недоверенным, применяйте принцип наименьших привилегий и проверенные аргументы инструментов, а авторизацию держите во внешнем слое политик.
• Происхождение позволяет восстановление: подписанные наборы данных, зафиксированные зависимости, права реестра и аттестации развертывания позволяют операторам определить, какие данные, код, субъект и контрольная точка породили подозрительную модель. Без этой цепочки откат и криминалистика превращаются в догадки при скорости парка.
• Доверие начинается ниже программного обеспечения: TEE, безопасная загрузка, HSM и аппаратные корни доверия защищают многопользовательские и конфиденциальные рабочие нагрузки от уровней, которые одно только программное обеспечение изолировать не может. Позиция защиты эшелонирована, потому что каждый уровень улавливает сбои, которых не видят другие.

Самая глубокая из угроз этой главы вообще не является вторжением. Это собственная компетентность модели. Подгонка под обучающие данные может создавать каналы для извлечения или атаки на принадлежность, а несколько отравленных примеров могут изменить поведение изнутри процесса обучения, потому что выученную границу решений нельзя залатать, как уязвимую функцию. Это инвариант утечки информации (принцип «инвариант утечки информации»): приватность должна закладываться в механизм и учитываться при зависящих от данных выпусках. После выпуска модели, обученной с DP, обычный инференс от этой фиксированной модели является постобработкой; интерактивный же механизм, который обращается к защищенным записям для каждого ответа, комбинируется между ответами. Поэтому безопасность нельзя навесить на периметр, потому что модель одновременно является активом и поверхностью атаки.

Связь с главами: от безопасности к устойчивости

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

1. Stuxnet: впервые обнаружен в 2010 году белорусской антивирусной компанией VirusBlokAda. Stuxnet стал первым публично известным вредоносным ПО, созданным для физического разрушения. Использование четырех одновременных уязвимостей нулевого дня задало прецедент для атак на цепочки поставок ML: так же, как Stuxnet скомпрометировал промышленные контроллеры через доверенные каналы обновления ПО, атаки на ML могут внедрять модели с закладками через доверенные репозитории. ↩

2. Нулевой день (от жаргона пиратов «ноль дней со дня выпуска»): в безопасности термин обозначает уязвимости, против которых еще нет ни одного дня защиты. Одновременное использование Stuxnet четырех уязвимостей нулевого дня не имело прецедентов; рыночная стоимость одного эксплойта нулевого дня превышает $1 млн, поэтому цепочка из четырех эксплойтов — оружие стоимостью в миллионы долларов с прямыми последствиями для ML-систем, где непропатченные фреймворки обслуживания моделей создают аналогичные окна уязвимости нулевого дня. ↩

3. Воздушный зазор (air gap; от буквального физического разрыва между сетевыми кабелями): сети, физически отделенные от внешних соединений; эта практика восходит к военным вычислениям 1960-х годов. Для ML-систем воздушный зазор кластеров обучения от интернета предотвращает утечку данных, но заставляет все зависимости (фреймворки, наборы данных, предобученные веса) проходить через ручные каналы передачи, и каждый из них становится потенциальным вектором атаки на цепочку поставок. ↩

4. Отзывы из-за кибербезопасности автомобилей: взлом Jeep Cherokee в 2015 году стал первым в истории отзывом из-за кибербезопасности, затронувшим 1,4 миллиона автомобилей. Схема отзыва повторяет откат ML-модели: как автомобилям требовались обновления по воздуху, чтобы изолировать развлекательные системы от шин CAN, критичных для безопасности, так и ML-развертываниям нужна архитектурная изоляция между внешними API инференса и контурами управления исполнительными механизмами, критичными для безопасности. ↩

5. NHTSA (Национальное управление безопасности дорожного движения США): основано в 1970 году; первые рекомендации по кибербезопасности оно выпустило в 2016 году, после взлома Jeep. NHTSA публикует необязательные рекомендации по безопасности, встроенной в проект, для подключенных автомобилей с более чем 100 бортовыми компьютерами. Эта регуляторная схема распространяется и на ML-системы: Закон ЕС об ИИ (2024) вводит аналогичные обязательства на протяжении жизненного цикла для высокорисковых систем ИИ, включая документированное управление рисками и мониторинг после выхода на рынок. ↩

6. Ботнет Mirai (японское слово «будущее»): на пике в 2016 году Mirai контролировал более 600 000 IoT-устройств, генерируя DDoS-атаки мощностью 1,2 Тбит/с, эксплуатируя учетные данные по умолчанию (admin/admin, root/12345). Для граничных ML-развертываний урок количественный: каждая умная камера или голосовой ассистент с учетными данными по умолчанию — не просто узел DDoS, а потенциальный источник отравленных обучающих данных в системах федеративного обучения. ↩

7. DDoS (распределенная атака типа «отказ в обслуживании»): техника, которая перегружает цель трафиком из множества источников; впервые продемонстрирована в 1999 году, а в более поздних отчетах об инфраструктуре фиксировались атаки свыше 3,47 Тбит/с. Для API инференса ML DDoS создает двойную угрозу: помимо срыва обслуживания, устойчивые высокообъемные запросы могут одновременно работать как атаки извлечения модели, собирая достаточно пар «вход — выход», чтобы обучить суррогатную модель, пока команда защиты сосредоточена на доступности. ↩

8. GDPR (Общий регламент ЕС по защите данных): действует с 2018 года и допускает штрафы верхнего уровня до 4 процентов от совокупного годового оборота в мире; по GDPR уже назначены штрафы на миллиарды евро, включая штраф в €746 млн для Amazon (2021). Для ML-систем право на удаление данных создает техническую задачу: исключение влияния конкретного человека из обученных весов модели может потребовать переобучения или методов машинного разобучения (machine unlearning), которые приближают удаление выученного влияния записи; оба подхода вычислительно дороги в масштабе. ↩ ↩2 ↩3

9. Атаки на принадлежность: впервые продемонстрированные против ML-моделей (Shokri et al., 2017), эти атаки определяют, использовалась ли конкретная точка данных в обучении, эксплуатируя различия в поведении модели на обучающих и невиданных данных. Успех атаки зависит от целевой модели, данных, выходных данных и знаний противника. Подтверждение того, что данные конкретного человека были в обучающем наборе, все равно может создать риски приватности и соответствия требованиям; то, нарушает ли такое раскрытие GDPR, HIPAA или другое правило, зависит от данных, сторон и контекста развертывания (GDPR, 2016; HHS, 2003). ↩

10. Состязательные примеры: впервые обнаружены (Szegedy et al., 2013). Это входы, созданные так, чтобы эксплуатировать выученные границы решений малыми возмущениями, которые людям бывает трудно заметить. Явление выявляет фундаментальное напряжение в проектировании ML-систем: те же многомерные пространства признаков, которые обеспечивают обобщение, создают эксплуатируемую геометрию, в которой небольшие целенаправленные возмущения пересекают границы решений. ↩

11. Отравление данных: впервые формально изучено (Biggio et al., 2012). Атака внедряет вредоносные данные во время обучения, чтобы испортить выученную модель. Системный урок: целостность обучающих данных важна даже тогда, когда число созданных примеров мало. Эксперименты по отравлению машин опорных векторов показали, что вредоносные точки обучения способны заметно увеличить тестовую ошибку, сдвигая выученную границу решений. ↩

12. Фишинг, созданный ИИ: большие языковые модели (LLM) генерируют фишинговые письма с грамматической точностью 99 процентов и выше против 19 процентов у традиционного фишинга, а в некоторых кампаниях достигают кликабельности 30 процентов и выше. Эта угроза двойного назначения показывает, почему безопасность ML должна рассматривать модели одновременно как активы для защиты и как потенциальное оружие: та же языковая беглость, которая питает чат-боты для клиентов, может быть дообучена для социальной инженерии в масштабе. ↩

13. ML API (интерфейсы прикладного программирования): популяризированы Prediction API от Google (2010); крупномасштабные ML API способны обслуживать миллиарды запросов. Каждый ответ API утекает информацию: показатели уверенности, логиты и top-$k$ предсказания вместе образуют побочный канал, который делает возможным извлечение модели. Сокращение многословности выходов (усечение логитов, отказ от показателей уверенности) напрямую обменивает полезность API на устойчивость к извлечению. ↩

14. Репозитории моделей: централизованные платформы для обмена ML-моделями, из которых крупнейшие каталоги, например Hugging Face. Эти репозитории создают тот же риск цепочки поставок, что и менеджеры пакетов вроде PyPI: исследователи находили модели со встроенными закладками и полезной нагрузкой для выполнения произвольного кода, поэтому криптографическая проверка происхождения моделей так же критична для ML, как подпись пакетов для ПО. ↩

15. Сериализация модели: преобразование обученных моделей в переносимые форматы: Open Neural Network Exchange (ONNX, 2017), SavedModel (2016), PyTorch .pth. Сериализация на основе pickle в Python, распространенная в рабочих процессах контрольных точек PyTorch, может выполнять произвольный код при десериализации, поэтому каждый недоверенный файл .pth — потенциальный вектор удаленного выполнения кода. Более безопасные форматы, например SafeTensors (2022), исключают выполнение кода, храня только данные тензоров (Hugging Face, 2026). ↩

16. Атака инверсии модели: впервые продемонстрирована (Fredrikson et al., 2015) против распознавания лиц: исследователи восстановили узнаваемые лица только по показателям уверенности. Атака показала, что доступ к API по принципу «черного ящика» не является достаточной защитой приватности: любая модель, возвращающая богатые выходные сигналы (вероятности, эмбеддинги, веса внимания), предоставляет оптимизационную цель для восстановления обучающих данных. ↩

17. Деанонимизация Netflix: исследователи показали, что всего 8 оценок фильмов с приблизительными датами уникально идентифицируют 99 процентов записей обезличенного набора данных Netflix Prize; сопоставление с публичными оценками IMDb затем позволило реально переидентифицировать пользователей с публичными оценками (Narayanan и Shmatikov, 2008). Netflix отменила запланированный второй конкурс. Урок для ML-систем: любой набор данных, достаточно богатый, чтобы обучать полезные модели, содержит достаточно структуры для переидентификации, поэтому наивное обезличивание недостаточно для приватности. ↩

18. ML-атаки по побочным каналам: впервые продемонстрированы против нейронных сетей в 2018 году, когда исследователи показали, что паттерны энергопотребления во время инференса раскрывают архитектуру модели (число слоев, функции активации, размеры параметров). В отличие от криптографических побочных каналов, которые утекают ключи, ML-побочные каналы утекают интеллектуальную собственность: злоумышленник, физически находящийся рядом с граничным устройством, способен восстановить архитектуру модели без какого-либо доступа к API. ↩

19. Дистилляция модели: техника передачи знаний, при которой меньшая модель-«ученик» обучается на мягких вероятностных выходах большей модели-«учителя», а не на жестких метках (Hinton et al., 2015). Изначально ее создавали для сжатия (достигая точности учителя выше 95 процентов при в 10–100$\times$ меньшем числе параметров), но дистилляция становится атакой, когда применяется к выходам API: противник обучает локального ученика на ответах жертвы и фактически крадет выученное поведение модели, не получая доступа к ее весам. ↩

20. Риски краудсорсинга: платформы вроде Amazon Mechanical Turk (2005) демократизировали разметку данных, но создали поверхность атаки отравлением: исследования показывают, что 15–30 процентов краудсорсинговых меток содержат ошибки. Скоординированный злоумышленник может отравить весь набор данных меньше чем за $1 000, создав несколько учетных записей разметчиков, поэтому контроль качества меток (голосование большинством, проверки по эталонным данным) становится обязательным уровнем защиты в любом конвейере обучения, использующем внешнюю разметку. ↩

21. Двухуровневая оптимизация (от двух вложенных «уровней» оптимизации): схема, в которой одна задача оптимизации содержит другую; для безопасности ML она формализована (Biggio et al., 2012). Внешняя задача (злоумышленник) оптимизирует отравляющие данные; внутренняя (защитник) обучает модель. Такая вложенность объясняет, почему устойчивая защита вычислительно дорога: проверка каждого кандидата на защиту требует решения полной внутренней задачи обучения, и стоимость умножается на число итераций защиты. ↩

22. Атаки с закладками: впервые продемонстрированы (Gu et al., 2017) на примере BadNets. Эти атаки встраивают скрытые триггеры во время обучения, которые срабатывают только при появлении определенных входных шаблонов. Скрытность крайне высока: модели с закладками сохраняют обычную точность на чистых входах (проходя стандартную оценку), одновременно достигая успеха атаки выше 99 процентов на входах с триггером, поэтому обнаружить их только по метрикам точности невозможно. ↩

23. Perspective API: модель обнаружения токсичности от Google, запущенная в 2017 году и в больших масштабах применявшаяся на платформах, включая The New York Times и Википедию. Ее масштаб иллюстрирует ключевой компромисс безопасности ML: модели, переобучающиеся на пользовательском контенте, повышают точность за счет петель обратной связи, но одновременно создают поверхность отравления, где состязательные комментарии, введенные в большом объеме, способны сдвигать границу решений модели. ↩

24. Результат уклонения от Perspective: атака не требовала переобучения. Добавление опечаток, замен символов и знаков препинания к токсичным фразам заставляло развернутую модель присваивать низкие оценки токсичности оскорбительному контенту, который следовало отфильтровать. Это показывает системный риск для развернутых ML-фильтров: малые возмущения входа могут обходить поверхность решений, даже когда сам конвейер обучения не был отравлен. ↩

25. Переносимость состязательных примеров: описана (Szegedy et al., 2013) и позднее систематизирована (Papernot et al., 2016). Явление показывает, что состязательные примеры, созданные против одной модели, обманывают разные архитектуры с успехом 60–80 процентов. Переносимость меняет модель угроз: злоумышленнику не нужен доступ к целевой системе; он создает возмущения против свободно доступной суррогатной модели и применяет их против производственной модели, делая атаки «черного ящика» почти такими же эффективными, как атаки «белого ящика». ↩

26. Meltdown/Spectre: Эти атаки на процессорные побочные каналы затронули практически каждый процессор, выпущенный с 1995 года, то есть миллиарды устройств. Экстренные исправления ОС вызвали снижение производительности на 5–30 процентов в рабочих нагрузках с интенсивным вводом-выводом. Для систем ML налог на производительность сильнее всего бьет по конвейерам загрузки данных: пропускная способность обучения на исправленных ядрах заметно упала для нагрузок, ограниченных данными, и командам пришлось заново профилировать и оптимизировать свои конвейеры данных. ↩

27. Спекулятивное исполнение: Введенное в Intel Pentium Pro (1995), это приём выполняет инструкции до подтверждения их необходимости, повышая пропускную способность на 10–25 процентов. Недостаток безопасности архитектурный: спекулятивные операции меняют состояние кэша даже после отката, создавая канал утечки по времени. Ускорители ML используют аналогичную спекулятивную предвыборку при загрузке весов, поэтому возникает вопрос, существуют ли подобные утечки, зависящие от данных, по времени в иерархиях памяти GPU. ↩

28. Правоприменение HIPAA: С 2003 года за нарушения HIPAA назначены штрафы на сотни миллионов долларов, а утечка данных Anthem Inc. (2015) раскрыла 78,8 миллиона записей пациентов. Для систем ML, обрабатывающих медицинские данные, соответствие HIPAA требует технических мер защиты: контроля доступа, аудита, защиты целостности, безопасности передачи и уведомления об утечке в течение 60 дней. Шифрование относится к адресуемым мерам защиты, но при работе с электронной защищенной медицинской информацией оно все равно напрямую определяет архитектуру конвейера обучения и инфраструктуру развертывания модели. ↩

29. AES (Advanced Encryption Standard): Принят Национальным институтом стандартов и технологий США (NIST) в 2001 году для замены DES. AES математически стоек, при $2^{128}$ возможных ключах для AES-128. Однако физические реализации выдают зависящие от ключа сигнатуры питания, которые дифференциальный анализ мощности и корреляционный анализ мощности могут использовать, чтобы извлечь ключи за считанные минуты. Этот разрыв между математической и физической безопасностью — главный урок для систем ML: доказуемо стойкий алгоритм не дает защиты, если его аппаратная реализация утекает информацию. ↩

30. Уязвимости IoT-устройств: Исследования показывают, что 70–80 процентов устройств IoT содержат эксплуатируемые недостатки (учетные данные по умолчанию, незашифрованные коммуникации, устаревшая микропрограмма). Для граничных устройств ML эти уязвимости складываются: скомпрометированная умная камера, которая выполняет инференс на устройстве, одновременно становится источником отравленных данных для федеративного обучения, точкой внедрения состязательных входов и вычислительным ресурсом для распределенных атак. ↩

31. Безопасность медицинских устройств: Отчеты FDA указывают, что 53 процента медицинских устройств содержат известные уязвимости, в среднем 6,2 на устройство. Для медицинских устройств на базе ML (диагностическая визуализация, инсулиновые помпы с прогнозирующими алгоритмами) каждая уязвимость усиливается: компрометация модели ML может вызвать незаметную ошибочную диагностику вместо видимого отказа устройства, и обнаружить такую атаку значительно сложнее, чем в традиционной безопасности медицинских устройств. ↩

32. Уязвимости отладочных портов: Аппаратные интерфейсы отладки, такие как JTAG и Serial Wire Debug, обеспечивают полный доступ к чтению и записи памяти для разработки, но, по оценкам, остаются незащищенными в 60–70 процентах поставляемых встроенных устройств. Для граничных устройств ML открытый порт JTAG позволяет злоумышленнику извлечь веса модели прямо из флеш-памяти, обходя все программные средства защиты, включая шифрование и управление доступом. ↩

33. Ландшафт регулирования кибербезопасности: Совокупные расходы на соответствие требованиям превышают $150 млрд в год по нескольким системам (SOC 2, ISO 27001, PCI DSS) плюс отраслевым правилам (SOX для финансов, HIPAA для здравоохранения). Для систем ML многорегулятивное соответствие создает архитектурные ограничения: медицинский сервис ИИ, работающий в ЕС и США, может потребовать защитных мер для трансграничной передачи по GDPR, мер безопасности HIPAA для защищенной медицинской информации и валидации FDA, если программное обеспечение входит в регулируемую сферу медицинских устройств (GDPR, 2016; HHS, 2005). Каждое обязательство ограничивает разные части инфраструктуры обучения и обслуживания. ↩

34. Тестирование на проникновение (от «проникновения» через периметр безопасности): Санкционированные имитированные атаки, формализованные в 1960-х годах для военных систем, и рынок объемом $1,7 млрд в 2022 году. Для систем ML традиционного тестирования на проникновение недостаточно: оно находит уязвимости инфраструктуры (SQL-инъекции, ошибки конфигурации), но пропускает специфичные для ML поверхности атак, такие как состязательные входы, извлечение модели через запросы к API и отравление обучающих данных, для которых нужна специализированная «красная команда» ML. ↩

35. Учения «красной команды» (от военной терминологии холодной войны для силы противника): В отличие от узкого технического охвата тестирования на проникновение, «красные команды» имитируют сложные многовекторные атаки на протяжении недель или месяцев, включая социальную инженерию и физический доступ. Для систем ML учения «красной команды» могут включать состязательную инженерию промптов, имитацию отравления обучающих данных и попытки извлечения модели; публичные отчеты об оценке безопасности OpenAI, Anthropic и Google иллюстрируют этот подход к оценке безопасности до развертывания. ↩

36. S-блок (Substitution Box): Нелинейная таблица подстановки в блочных шифрах, таких как AES, которая сопоставляет каждый входной байт с другим выходным байтом, обеспечивая свойство рассеивания (confusion), из-за которого шифротекст нельзя предсказать по открытому тексту. Операции S-блока — главная цель атак по побочным каналам, потому что выход зависит одновременно от открытого текста и секретного ключа: нейронная сеть, обученная на трассах питания во время вычисления S-блока, может восстанавливать байт ключа за байтом, превращая криптоанализ в задачу классификации. ↩

37. Компромисс устойчивости и приватности: Состязательное обучение может повышать восприимчивость к атакам на принадлежность в условиях, изученных в работе Song et al. (2019). Этот результат означает, что меру устойчивости нужно перепроверять на соответствие инвариантам приватности, а не считать, что она одновременно улучшает все свойства безопасности. ↩

38. Гомоморфное шифрование (греч. homos «одинаковый» + morphe «форма»): Название отражает основное свойство: операции над шифротекстами дают результат той же «формы», что и операции над открытым текстом. Теоретически известно с 1970-х годов, полностью гомоморфное шифрование стало практичным после диссертации Крейга Гентри 2009 года. Системная цена остается высокой: инференс HE может работать в 1000–10 000$\times$ медленнее, чем на открытом тексте, что ограничивает многие приложения ML малыми моделями и пакетной обработкой с низкой пропускной способностью. ↩

39. Издержки производительности SMPC: Безопасные многосторонние вычисления могут создавать вычислительные издержки в 1000–10 000$\times$ из-за криптографических операций (разделение секрета, запутанные схемы), превращая инференс, занимающий миллисекунды, в секунды, минуты или больше в зависимости от размера модели и протокола. Практический компромисс — гибридное развертывание: SMPC применяется только к чувствительным слоям (финальная классификация, поиск эмбеддингов), а несекретные слои выполняются на открытом тексте, что снижает издержки до 10–100$\times$ ценой частичной утечки информации через незащищенные слои. ↩

40. SMPC (Secure Multiparty Computation): Сформулировано Эндрю Яо в 1982 году как «задача миллионеров» (могут ли два миллионера определить, кто из них богаче, не раскрывая свое состояние?). Этот каркас позволяет больницам совместно обучать диагностические модели ML без обмена записями пациентов. Ключевое системное ограничение — коммуникация: SMPC требует, чтобы каждая сторона обменивалась зашифрованными долями при каждой операции, поэтому в распределенном обучении ML доминирующим узким местом становится пропускная способность сети, а не вычисления. ↩

41. Синтетические данные: Рынок вырос с $110 млн (2019) до $1,1 млрд (2023), во многом благодаря нормам приватности, которые делают использование реальных данных дорогим. Основной компромисс — между точностью и приватностью: синтетические наборы, которые достигают статистической точности 95 процентов и выше относительно исходных, все равно могут раскрывать информацию о редких людях через запоминание генеративной моделью, поэтому производственные системы сочетают синтетическую генерацию с гарантиями дифференциальной приватности. ↩

42. Водяные знаки модели: Техника защиты интеллектуальной собственности, предложенная в работе Adi et al. (2018), в которой модель обучается выдавать определенный «сигнатурный» ответ на секретные триггерные входы, известные только владельцу. В их экспериментах водяные знаки на основе набора триггеров сохраняли обычную точность на тестовых данных и одновременно позволяли надежно идентифицировать владельца модели по секретному набору триггеров. Системная проблема — устойчивость: водяные знаки должны переживать дообучение, прореживание и дистилляцию модели, то есть те же операции, которыми злоумышленники стирают метки владения с украденных моделей. ↩

43. OAuth (Open Authorization): Стандарт, разработанный в 2006 году и используемый в интернет-масштабе, позволяющий получать доступ к API без раскрытия учетных данных. Для API инференса ML аутентификация на основе токенов OAuth 2.0 добавляет 5–15 мс задержки на запрос для проверки токена — ничтожные издержки для пакетного инференса, но заметные накладные расходы для обслуживания в реальном времени при тысячах запросов в секунду, когда каждая миллисекунда бюджета задержки важна. ↩

44. Взаимный TLS (mTLS): Расширенная безопасность транспортного уровня (введена в 1999 году), при которой клиент и сервер аутентифицируются через сертификаты. Накладные расходы на рукопожатие в 15–30 мс — разовая стоимость на соединение, которая распределяется на последующие запросы благодаря пулу соединений. Для обслуживания моделей ML mTLS гарантирует, что только аутентифицированные сервисы могут отправлять запросы инференса, предотвращая несанкционированное извлечение модели через API. ↩

45. API-ключи: Секретные токены, передаваемые в HTTP-заголовках для аутентификации вызывающих API. В конвейерах обслуживания ML утекший API-ключ предоставляет противнику неограниченный доступ к запросам для извлечения модели или отравления данных, обходя ограничения частоты запросов по IP и превращая утечку учетных данных непосредственно в кражу интеллектуальной собственности. ↩

46. RBAC (Role-Based Access Control): Формализовано NIST в 1990-х годах. RBAC назначает права ролям, а не отдельным лицам, сокращая административные издержки более чем на 90 процентов по сравнению с политиками для каждого пользователя. Для платформ ML RBAC естественно соотносится с жизненным циклом ML: инженеры данных имеют доступ к обучающим данным, но не к весам модели, инженеры ML — к моделям, но не к производственным ключам обслуживания, а системы мониторинга — к предсказаниям, но не к сырым входам, обеспечивая принцип наименьших привилегий во всем конвейере. ↩

47. SAD (Speech Activity Detector): Алгоритм, отличающий речь от тишины, шума или музыки, необходимый для голосовых интерфейсов с 1990-х годов. Современные нейросетевые SAD работают с задержкой менее 10 мс при точности 95 процентов и выше и служат легковесным шлюзом безопасности: отфильтровывая неречевые входы до дорогой модели автоматического распознавания речи, SAD не дает состязательным аудиоатакам (команды, скрытые в шуме, ультразвуковые триггеры) достичь системы распознавания речи. ↩

48. Карты внимания (Attention Maps): Визуализация весов внимания, опирающаяся на механизм нейронного внимания, введенный в работе Bahdanau et al. (2015). В контексте мониторинга визуализации в духе внимания и связанные сигналы атрибуции помогают аналитикам понять, какие области входа или токены повлияли на выход модели, но их следует рассматривать как диагностические данные, а не как самостоятельную гарантию безопасности. ↩

49. SHA-256 (Secure Hash Algorithm, NSA, 2001): Формирует 256-битные дайджесты, для которых за более чем 20 лет не известно практических атак коллизий. Для проверки целостности моделей ML вычисление хеша SHA-256 для файла модели размером в несколько гигабайт занимает секунды и обнаруживает любое изменение, каким бы малым оно ни было. Поэтому криптографическое хеширование — самая дешевая и эффективная защита от подмены модели при хранении, развертывании и передаче между средами обучения и обслуживания. ↩

50. Изоляция контейнеров и виртуальных машин: Контейнеры Linux (например, образы в стиле Docker) разделяют ядро хоста с накладными расходами CPU 0–5 процентов, но обеспечивают более слабую изоляцию; виртуальные машины дают разделение на аппаратном уровне с накладными расходами 10–15 процентов. Для обслуживания ML это компромисс между безопасностью и производительностью: контейнеры позволяют быстро масштабировать модели, но разделяют поверхность атаки ядра с соседними арендаторами, тогда как виртуальные машины предотвращают межарендаторное извлечение модели ценой более высоких издержек памяти на каждый экземпляр обслуживания. ↩

51. Соответствие ML в здравоохранении: FDA с 2016 года одобрила более 500 медицинских устройств на основе ИИ в рамках 21 CFR Part 820, при этом циклы одобрения длятся 2–5 лет и стоят более $50 млн. Ключевое системное ограничение: любое обновление модели требует повторной валидации, что создает напряжение между итеративным циклом улучшения ML (переобучение раз в неделю) и сроками регуляторного одобрения (валидация в течение месяцев), и это подталкивает к внедрению зафиксированных и версионированных архитектур развертывания моделей. ↩

52. Требования HIPAA к ML: Для электронной защищенной медицинской информации Правило безопасности HIPAA рассматривает шифрование при хранении и при передаче как адресуемые спецификации реализации: регулируемая организация обязана внедрять их, когда это разумно и уместно, либо документировать эквивалентную альтернативу. Ее стандарт аудит-контроля также требует механизмов, которые фиксируют и анализируют активность в системах, содержащих защищенную медицинскую информацию или работающих с ней, при этом объем определяется анализом рисков, а не общим требованием журналировать каждое чтение (HHS, 2005). Облачные сервисы, обрабатывающие такую информацию, обычно требуют соглашений о деловом партнерстве. Гражданские штрафы многоуровневые и корректируются со временем, поэтому архитектура соответствия должна опираться на действующую практику правоприменения, а не на фиксированную сумму за инцидент (HHS, 2026). В конвейере ML эти обязанности превращаются в аудит с учетом рисков, защищенные контрольные точки, контролируемый доступ и доказательства того, что выбранные меры защиты работают. ↩ ↩2

53. Канареечное развертывание (назван по канарейкам в угольных шахтах, которые обнаруживали газ раньше шахтеров): Новые версии моделей выкатываются на 1–5 процентов трафика до полного развертывания. Для систем ML канареечные развертывания необходимы, потому что сбои моделей часто статистические, а не бинарные: модель с закладкой может проходить модульные тесты, но ухудшать точность на отдельных подгруппах, что обнаруживается только на реальных шаблонах трафика в масштабе канарейки. ↩

54. Инъекция промпта (по аналогии с SQL-инъекцией): Впервые широко описанные в 2022 году, эти атаки встраивают состязательные инструкции во входные данные пользователя, которые переопределяют системный промпт модели. В отличие от SQL-инъекции, которая эксплуатирует синтаксическую границу между кодом и данными, инъекция промпта использует отсутствие такой границы в LLM: инструкции модели и пользовательское содержимое делят один поток токенов, поэтому надежное обнаружение принципиально сложнее традиционной санитизации входов. ↩

55. TEE (Trusted Execution Environment): Аппаратно изолированные области процессора, возникшие из ARM TrustZone (начало 2000-х годов) и вдохновленные военной концепцией разделения информации по отсекам. Для систем ML TEE создают фундаментальное ограничение по памяти: защищенные анклавы (128 МБ в SGX, расширяемые в TrustZone) должны вмещать и веса модели, и промежуточные активации, что вынуждает либо сжимать модель, либо выполнять разбитый на части инференс, при котором внутри анклава работают только чувствительные слои. ↩

56. ARM TrustZone: Введена в 2004 году; TrustZone разделяет процессор ARM на безопасный и обычный «миры» с аппаратно обеспечиваемой изоляцией. Для ML на мобильных и граничных устройствах TrustZone может защищать веса модели и биометрические данные во время инференса, но защита зависит от того, раскрывает ли производитель устройства и использует ли он приложения безопасного мира помимо хранения ключей. Урок здесь архитектурный: сама по себе аппаратная поддержка не защищает развертывание ML, если модель, ключи и путь данных не размещены внутри доверенной границы. ↩

57. Ограничения памяти Intel SGX: Анклавы SGX ограничены примерно 128 МБ памяти кэша анклава (EPC) на потребительских процессорах, а промахи EPC вызывают штраф производительности в 100×. ResNet-50 требует примерно 102,4 МБ только для весов FP32 (25,6 млн параметров × 4 байта), занимая 76,3 процента EPC до учета активаций. Задержка инференса возрастает с 5 мс до 500 мс, когда модель превышает EPC, поэтому SGX практичен только для небольших моделей размером менее 10 МБ или для защиты криптографических ключей. ↩

58. Стеки безопасной загрузки с открытым исходным кодом: U-Boot (The U-Boot Project, 2026) — де-факто загрузчик для встроенных систем Linux, включая устройства класса Raspberry Pi, которые используются в граничных развертываниях ML, а его документация UEFI описывает настройку безопасной загрузки (The U-Boot Project, 2026). coreboot (coreboot, 2026) ориентирован на серверное и рабочее аппаратное обеспечение x86, а его документация vboot описывает поддержку проверенной загрузки, измерение микропрограммы и подпись образов (coreboot, 2026). Оба могут участвовать в цепочках загрузки с проверкой подписей или с измерениями, но корень доверия специфичен для платформы и может по-прежнему контролироваться политикой аппаратного обеспечения поставщика, защитой записи микропрограммы или ключами платформы. Поэтому «открытый исходный код» относится к коду загрузчика, а не автоматически к корню доверия, который закрепляет среду выполнения модели ML. ↩

59. HSM (Hardware Security Module): Корпоративные HSM выполняют более 10 000 операций RSA-2048 в секунду при стоимости $20 000–$100 000 и выше за единицу, тогда как GPU выполняют более 100 000 операций в секунду при стоимости от $1000. Отставание по пропускной способности в 10$\times$ — цена устойчивости к вскрытию: HSM физически уничтожают ключи при попытке вскрытия, и такой гарантии не может обеспечить ни одно чисто программное решение; она может требоваться сертификационными режимами или режимами безопасности платежей для работы с ключами высокой надежности в производстве. ↩

60. Сертификация HSM: Сертификация по FIPS 140-2 или Common Criteria занимает 12–24 месяца и стоит $500 000–$2 млн на семейство устройств. Банковские, государственные и некоторые закупочные режимы в здравоохранении могут требовать сертификации уровня 3 и выше для криптографических операций. Для систем ML в регулируемых отраслях этот срок сертификации становится узким местом развертывания: HSM, защищающий ключи подписи моделей, может сертифицироваться дольше, чем обучается сама модель. ↩

61. FIPS 140-2 (Federal Information Processing Standard): Определяет четыре уровня безопасности для криптографических модулей. Уровень 4 требует устойчивости к физическим атакам при температурах от -40 до +85 градусов Цельсия и обнаружения вскрытия, которое обнуляет ключи в течение секунд. Для систем ML, работающих с секретными данными или действующих в рамках строгих закупочных требований, соответствие FIPS 140-2 уровня 3 и выше может быть обязательным, что ограничивает доступ к HSM уполномоченным сотрудникам и замедляет быстрые циклы итераций, которые обычно требует разработка ML. ↩

62. PUF (Physical Unclonable Function): Название отражает физическую невозможность клонировать микроскопические производственные вариации, которые PUF используют. PUF генерируют криптографические ключи, уникальные для устройства, не сохраняя секреты в памяти. Для граничных устройств ML PUF решают важную задачу развертывания: каждое устройство может шифровать свою локальную модель аппаратно выведенным ключом, которого нигде больше не существует, гарантируя, что извлечение модели с одного устройства не компрометирует весь парк. ↩

63. DP-SGD (Differentially Private SGD): Введен в работе Abadi et al. (2016). DP-SGD обрезает градиенты отдельных примеров и добавляет откалиброванный гауссовский шум во время обучения. Apple сообщила о крупномасштабном развертывании локальной дифференциальной приватности в 2017 году для сценариев, похожих на телеметрию; это развертывание служит свидетельством производственного использования DP, но не DP-SGD как такового (Apple, 2017). Системная цена DP-SGD может быть значительной: обрезка градиентов отдельных примеров исключает параллелизм на уровне батча, который делает обучение на ускорителях эффективным, и снижает пропускную способность относительно стандартного SGD. ↩

64. Напряжение между приватностью и полезностью: Бюджет приватности — свойство скомпонованных рандомизированных механизмов, примененных к соседним наборам данных, где каждая эпоха DP-SGD и каждый интерактивный запрос расходуют бюджет. Постобработка уже выпущенного результата DP не расходует дополнительный бюджет. Когда выделение исчерпано, дальнейшие выпуски не могут сохранять заявленную границу без изменения заявленного бюджета, поэтому учет приватности становится ограничением первого класса наравне с вычислениями и памятью. ↩