Membership inference атаки на модель

Осень 2025 года: на российский рынок вышли первые коммерческие инструменты аудита ML-моделей на предмет утечки информации. Регулятор пока не предъявляет отдельных требований к архитектуре нейронных сетей, но правовая рамка ФЗ-152 распространяется на любую обработку ПДн — включая обучение моделей. CTO, который не оценил риск membership inference, подставляет компанию под штрафы по ст. 13.11 КоАП и уголовное преследование по ст. 272.1 УК.

Что такое membership inference и почему это проблема для CTO?

Membership inference attack (атака на принадлежность к обучающей выборке) строится на наблюдении: модель, обученная с переобучением, возвращает более уверенные предсказания на данные из обучающей выборки, чем на новые данные. Злоумышленник или исследователь безопасности подаёт запрос к модели и по разнице в уверенности вывода определяет, присутствовал ли конкретный пример в тренировочном наборе.

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

Атака реализуется в трёх сценариях: атака на доступ к интерфейсу модели (black-box), атака при наличии частичного доступа к весам (gray-box) и атака исследователя с полным доступом к весам (white-box). В SaaS-мультиарендных средах наиболее актуален black-box сценарий: арендатор одного тенанта через API потенциально извлекает информацию о данных другого тенанта, которые попали в общую модель.

Как membership inference соотносится с требованиями УЗ-1..УЗ-4 и Приказом ФСТЭК №21?

Уровень защищённости ИСПДн определяется по матрице ПП РФ №1119: категория ПДн (общедоступные / специальные / биометрические) × тип актуальной угрозы (1–3) × число субъектов (порог 100 000). Обучающий датасет медицинской или финансовой информации при числе субъектов свыше 100 000 чаще всего попадает в УЗ-2 или УЗ-3.

Приказ ФСТЭК №21 содержит группу мер РСБ (регистрация событий безопасности) и группу АНЗ (анализ защищённости). Для УЗ-3 базовый набор требует реализации мер РСБ.1–РСБ.3 (сбор и хранение логов) и АНЗ.1 (выявление уязвимостей). Membership inference прямо в методологии ФСТЭК не упомянут, но подпадает под угрозы НСД к ПДн — и значит, должен быть закрыт техническими мерами из базового набора по соответствующему УЗ.

На практике типичная ошибка CTO — определить УЗ-3 для боевой ИСПДн, но не распространить режим защищённости на тестовые среды и пайплайны обучения модели. При этом обучающая выборка формируется именно в dev/staging окружении, которое остаётся за пределами периметра сертифицированных СЗИ. Именно там membership inference наиболее реален.

Что считается обезличиванием для ML и какие методы допускает регулятор?

Обезличивание ПДн для задач машинного обучения — устранение прямых и косвенных идентификаторов из датасета способом, исключающим обратное восстановление личности субъекта без дополнительной информации. С 2025 года применяются 5 методов, закреплённых в подзаконном акте РКН: введение идентификаторов (псевдонимизация), изменение состава и семантики, декомпозиция, перемешивание, обобщение и агрегация.

Membership inference атака на псевдонимизированный датасет остаётся актуальной: если модель обучена на записях с заменёнными идентификаторами, но сохранившейся структурой редких признаков (возраст + диагноз + регион), атака может установить факт участия субъекта в выборке даже без знания имени. Регулятор не формулирует прямого запрета на такую обработку, но ст. 5 ФЗ-152 требует, чтобы объём и состав ПДн соответствовали целям обработки. Использование обогащённых датасетов с редкими признаками для обучения общей коммерческой модели — потенциальная претензия при проверке РКН.

Технически допустимый минимум для ML-пайплайна: применить хотя бы два метода из пяти (например, псевдонимизацию + обобщение числовых признаков), задокументировать методологию в рамках поручения обработки по ст. 6 ФЗ-152 и зафиксировать результат в отчёте DPIA. Логирование запросов к модели в production — отдельное требование, поскольку сами запросы могут содержать ПДн и тоже подлежат защите.

Типовые сценарии: как membership inference превращается в правовой риск

Сценарий 1. Общая рекомендательная модель SaaS-платформы. Платформа обучает единую рекомендательную модель на поведенческих данных всех тенантов. Один из тенантов через adversarial запросы к inference API устанавливает, что пользователи конкурента присутствуют в обучающей выборке. Квалификация: несанкционированный доступ к ПДн по ст. 272 УК и нарушение условий поручения обработки (ст. 6 ФЗ-152). Стратегия: разделить модели по тенантам или применить технику дифференциальной приватности; задокументировать поручение с явным запретом перекрёстного использования данных.

Сценарий 2. Датасет медицинских записей без достаточного обезличивания. Клиника передала агрегатор-стартапу обучающую выборку с псевдонимизированными записями пациентов (диагнозы, возраст, регион). Membership inference на готовой модели позволяет установить факт участия конкретного пациента с редким диагнозом. Квалификация: обработка специальной категории ПДн без надлежащего согласия (ч. 2 ст. 13.11 КоАП, штраф 300 000–700 000 ₽), при повторности — ч. 2.1, штраф 1–1,5 млн ₽. При наличии умысла и масштабе — ст. 272.1 УК. Стратегия: перед передачей применить обобщение редких категорий до уровня, при котором k-анонимность соблюдается, задокументировать в DPIA.

Сценарий 3. Утечка через открытый inference endpoint. Стартап опубликовал demo-версию модели с открытым API без ограничений на частоту запросов. Исследователь за 10 000 запросов восстановил состав ~15 000 субъектов из обучающей выборки и опубликовал результат. Квалификация: утечка ПДн от 10 000 до 100 000 субъектов — ч. 13 ст. 13.11 КоАП, штраф 5–10 млн ₽; неуведомление РКН в 24 часа — ч. 11, штраф 1–3 млн ₽. При повторности — оборотный по ч. 15. Стратегия: rate limiting, authentication, мониторинг аномалий на inference endpoint; регламент реагирования на утечку с 24-часовым таймером.

Как это применяется на практике

Кейс 1. IT-компания (Северо-Западный ФО, весна 2026) обнаружила, что исследователь безопасности через публичный inference API её рекомендательного сервиса восстановил факт участия около 12 000 пользователей в обучающей выборке и направил уведомление об уязвимости. Технический директор в течение 20 часов с момента получения уведомления направил первичное сообщение в РКН, через 68 часов — отчёт о расследовании с описанием мер устранения. Компания задокументировала применение трёх методов обезличивания, инвестиции в доработку архитектуры составили более 0,1% выручки за три года. При рассмотрении дела в суде штраф по ч. 13 ст. 13.11 КоАП был снижен до нижней границы диапазона с учётом добросовестного реагирования и применения ст. 4.1 КоАП о смягчающих обстоятельствах.

Кейс 2. Медицинский стартап (Центральный ФО, лето 2025) передал обучающую выборку с псевдонимизированными данными 8 400 пациентов подрядчику ML-разработки без договора поручения обработки. После проверки РКН компания получила протокол по ч. 2 ст. 13.11 КоАП (обработка без надлежащего правового основания) со штрафом в диапазоне нескольких сотен тысяч рублей. Договор поручения обработки и документация DPIA, подготовленные после инцидента, позволили обжаловать постановление и добиться снижения штрафа в судебном порядке.

Частые вопросы

1. Какой УЗ выбрать для SaaS?

Уровень защищённости определяется по матрице ПП РФ №1119 от 01.11.2012: категория ПДн (общедоступные, специальные, биометрические), тип актуальной угрозы (1–3) и число субъектов. Для многопользовательской SaaS-платформы с обработкой общедоступных ПДн более 100 000 субъектов и угрозами 2-го типа — как правило, УЗ-3. При наличии специальных категорий (здоровье, биометрия) — УЗ-2 или УЗ-1. Определение УЗ нужно закрепить в акте классификации ИСПДн и согласовать с ответственным за обработку ПДн по ст. 22.1 ФЗ-152.

2. Можно ли использовать иностранные облака?

С 01.07.2025 требование локализации по ч. 5 ст. 18 ФЗ-152 распространяется на первичный сбор и запись ПДн граждан РФ: эти операции допустимы только в базах данных, физически расположенных в России. Хранение и последующая трансграничная передача возможны при соблюдении требований ст. 12 ФЗ-152 — с предварительным уведомлением РКН. Использование иностранного облака (AWS, GCP, Azure) для хранения обучающих датасетов с ПДн российских пользователей без российской копии — нарушение ч. 8 ст. 13.11 КоАП (штраф 1–6 млн ₽). Обучение модели на иностранной инфраструктуре при наличии локализованной копии — в правовой серой зоне; позиция РКН формируется.

3. Что такое обезличивание для ML?

Обезличивание для ML — это применение методов из перечня РКН (введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение) к обучающему датасету таким образом, чтобы модель не «запоминала» атрибуты конкретных субъектов. Простая псевдонимизация (замена имени на токен) недостаточна: membership inference атака успешна на псевдонимизированных данных с редкими признаками. Технически более надёжны методы дифференциальной приватности (differential privacy), однако российский регулятор пока не признаёт их явно. Минимальный комплаенс: документировать применённые методы по перечню РКН и включить оценку остаточного риска в DPIA.

4. Кто оператор в мультиарендной SaaS?

В мультиарендной SaaS-архитектуре оператором по отношению к конечным пользователям-субъектам выступает, как правило, тенант (клиент платформы), который определяет цели и способы обработки. Платформа действует как лицо, осуществляющее обработку по поручению оператора (ст. 6 ч. 3 ФЗ-152), и обязана заключить договор поручения с каждым тенантом. Если платформа самостоятельно определяет, как использовать агрегированные данные тенантов (например, для обучения общей модели), она становится самостоятельным оператором в этой части и несёт полную ответственность по ФЗ-152 без возможности сослаться на поручение.

5. Какие СЗИ обязательны?

Конкретный набор средств защиты информации определяется базовым набором мер для установленного УЗ по Приказу ФСТЭК №21. Для УЗ-3 к обязательным относятся: средства идентификации и аутентификации (группа ИАФ), разграничение прав доступа (УПД), регистрация событий безопасности (РСБ), защита от вредоносного ПО (АВЗ), анализ защищённости (АНЗ), защита информационной системы (ЗИС). СЗИ должны быть сертифицированы ФСТЭК для УЗ-3 и выше. Для ML-инфраструктуры отдельных обязательных СЗИ не установлено, однако пайплайн обучения должен быть включён в периметр защищённой ИСПДн.

Итог

Membership inference атака — это точка пересечения ML-инженерии и правового регулирования ПДн. Модель, обученная с переобучением на реальных пользовательских данных без надлежащего обезличивания, превращается в вектор утечки — даже если оригинальный датасет физически уничтожен. Правовая рамка ФЗ-152 не делает исключения для ML-пайплайнов: требования УЗ по ПП РФ №1119, меры защиты по Приказу ФСТЭК №21 и обязанность уведомить РКН об утечке за 24 часа применяются вне зависимости от того, как именно были скомпрометированы данные.

DATUM сопровождает IT-компании и SaaS-платформы в оценке рисков ML-систем по ФЗ-152: определение УЗ, DPIA с учётом membership inference угроз, документирование методов обезличивания, договоры поручения обработки для мультиарендных архитектур.

Услуги DATUM по теме

• DPIA (оценка воздействия) — оценка рисков ML-системы с учётом membership inference и требований ФСТЭК
• Аудит соответствия 152-ФЗ — проверка пайплайна обучения, определение УЗ, чек-лист из 38 пунктов
• Комплект ОРД под ключ — договоры поручения обработки, регламент реагирования, журналы логирования

14 января 2029 года