Метод 4: перемешивание

Роскомнадзор утвердил методы обезличивания в рамках реализации ст. 13.1 ФЗ-152 (введена ФЗ-233 от 08.08.2024). Метод перемешивания — четвёртый в перечне. Он применим в ситуациях, когда задача состоит в отвязке атрибута от субъекта, а не в уничтожении значения. Это делает его востребованным в аналитике, обучении ML-моделей и тестовых средах SaaS. Однако применение метода требует понимания его ограничений: перемешивание не устраняет риск повторной идентификации при малых выборках и не освобождает от требований Приказа ФСТЭК №21 автоматически.

Что такое метод перемешивания и как он работает в ИСПДн?

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

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

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

Как метод перемешивания соотносится с уровнями защищённости УЗ-1..4?

ПП РФ №1119 привязывает уровень защищённости к трём параметрам: категории ПДн, типу угроз и числу субъектов (порог — 100 000). После корректного обезличивания данные выходят из-под действия ст. 10 ФЗ-152 (специальные категории) или снижают категорию до общих ПДн. Это позволяет пересмотреть необходимый УЗ и сократить перечень обязательных мер по Приказу ФСТЭК №21.

Однако снижение УЗ наступает только при двух условиях. Первое: метод применён ко всем атрибутам, по которым возможна идентификация. Второе: оператор документально подтвердил, что совокупность оставшихся данных не позволяет однозначно установить личность субъекта. На практике для ML-моделей, обученных на корпоративных данных с малой выборкой (менее 1 000 записей), перемешивание само по себе не обеспечивает необратимость обезличивания.

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

Где метод перемешивания применим для обезличивания ML-данных?

Метод перемешивания наиболее оправдан в следующих сценариях: формирование тестовых датасетов из производственных данных, построение синтетических выборок для обучения классификаторов, передача данных внешнему подрядчику по договору поручения обработки (п. 3 ст. 6 ФЗ-152), а также аналитические задачи, где важна статистика распределения, но не конкретные пары «субъект — значение».

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

Типовые ситуации применения метода перемешивания

Ситуация 1. SaaS-платформа передаёт обезличенные данные аналитическому подрядчику. IT-компания (Сибирский ФО, 2025) применила перемешивание атрибутов в экспортируемом датасете, однако не задокументировала процедуру и не включила условие об обезличивании в договор поручения. При внеплановой проверке РКН установил, что переданные данные не имеют статуса обезличенных по ч. 3 ст. 13.1 ФЗ-152 — документальное подтверждение отсутствовало. Компании выставлено предписание об устранении и возбуждено дело по ч. 1 ст. 13.11 КоАП. Регламент обезличивания разработан и согласован в рамках сопровождения; дело прекращено в связи с устранением нарушения.

Ситуация 2. Мультиарендная платформа с агрегированной аналитикой. B2B-SaaS (Центральный ФО, 2026) хранил ПДн арендаторов в общей базе для формирования сводной отчётности. Перемешивание применялось на уровне отдельного tenant, но не для агрегированных таблиц. Аудит выявил, что аналитические таблицы содержат ПДн суммарно более 100 000 субъектов без применения утверждённого метода обезличивания. Пересмотрена архитектура хранилища, сформирован регламент, заключены отдельные договоры поручения с каждым арендатором-оператором. УЗ снижен с УЗ-3 до УЗ-4 по ПП РФ №1119 после подтверждения обезличивания.

Ситуация 3. Логирование как источник ПДн при обезличенном основном датасете. Техническая команда облачного сервиса (Северо-Западный ФО, 2025) корректно применила перемешивание к продуктовым данным, однако системные логи содержали IP-адреса, user-agent и идентификаторы сессий в виде открытого текста. По позиции РКН, IP-адрес в сочетании с поведенческими метками — это ПДн (косвенная идентификация). Логирование как ПДн вывело систему на УЗ-3, хотя продуктовый датасет был корректно обезличен. После псевдонимизации логов и введения политики retention (30 дней) требования приведены в соответствие.

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

• Аудит соответствия 152-ФЗ — проверка методов обезличивания, УЗ, ОРД и договоров поручения по чек-листу из 38 пунктов.
• DPIA (оценка воздействия) — оценка рисков для ML-конвейеров и мультиарендных SaaS.
• Комплект ОРД под ключ — регламент обезличивания, договоры поручения, политика retention логов.

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

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

Уровень защищённости определяется по матрице ПП РФ №1119: категория ПДн × тип угроз × число субъектов. Для типовой B2B-SaaS с общими ПДн (не спецкатегория) и угрозами 3-го типа — УЗ-3 при числе субъектов более 100 000, УЗ-4 при меньшем числе. После корректного обезличивания методом перемешивания и документального подтверждения — возможен пересчёт УЗ. Мультиарендность не снижает УЗ автоматически: если агрегированная база превышает 100 000 субъектов, уровень считается по совокупности.

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

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

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

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

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

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

5. Какие СЗИ обязательны по Приказу ФСТЭК №21?

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

Итог

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

DATUM сопровождает IT-команды в формировании регламентов обезличивания, пересчёте УЗ по ПП РФ №1119, подготовке договоров поручения для ML-подрядчиков и прохождении проверок РКН. Практика по 152-ФЗ с 2014 года.