Фича-флаги и сегментация: ПДн

С 30.05.2025 вступила в силу новая редакция ст. 13.11 КоАП — 18 частей вместо прежних семи. Для технических директоров это означает, что риск возник не только в «базах клиентов», но и в инструментах разработки: системах управления фича-флагами, сегментационных движках, конфигурациях A/B-тестирования. В этом материале разбираем, как квалифицировать такую обработку, какой уровень защищённости нужен, когда обезличивание снимает риск и что проверить в мультиарендной SaaS-архитектуре перед аудитом РКН.

Когда фича-флаг становится обработкой персональных данных?

Фича-флаг в технической реализации — это запись вида «пользователь X видит функцию Y». Если X — это user_id, привязанный к конкретному физическому лицу (имя, email, телефон, cookie-идентификатор, IP-адрес), то запись представляет собой обработку ПДн по ст. 3 ФЗ-152: как минимум «систематизацию» и «использование» сведений о субъекте.

Сегментация пользователей создаёт тот же риск в ещё большем масштабе: движок сегментации систематизирует поведение (клики, сессии, покупки) и присваивает субъекту атрибуты. Само по себе это законно при наличии правового основания — например, договора с пользователем по п. 5 ч. 1 ст. 6 ФЗ-152. Проблема возникает в трёх точках:

• данные хранятся или обрабатываются первично в инфраструктуре за пределами РФ — нарушение ч. 5 ст. 18 ФЗ-152;
• правовое основание не определено или не совпадает с фактическими действиями — нарушение ст. 6 ФЗ-152;
• поручение обработки подрядчику (LaunchDarkly, Optimizely, собственный облачный сервис) оформлено без договора поручения по п. 3 ст. 6 ФЗ-152.

Трафик через зарубежный SaaS-провайдер фича-флагов (LaunchDarkly, Unleash в облаке AWS eu-west) означает, что первичная запись и систематизация происходит не в РФ. С 01.07.2025 правоприменение по ч. 5 ст. 18 усилилось: РКН включил проверку локализации в перечень автоматических индикаторов риска при плановых проверках.

Какой уровень защищённости применим к системам сегментации?

Уровень защищённости информационной системы персональных данных (ИСПДн) определяется пересечением трёх параметров по ПП РФ №1119 от 01.11.2012: категория обрабатываемых ПДн, тип актуальных угроз и количество субъектов относительно порога 100 000.

Для типичной продуктовой SaaS с сегментацией пользователей расчёт выглядит так:

• Категория ПДн — как правило, «иные» (общие): имя, email, cookie, поведенческие метки. Если сегментация включает данные о здоровье, политических взглядах или судимости — категория повышается до специальных по ст. 10 ФЗ-152.
• Тип угроз — угрозы 3-го типа (отсутствие недекларированных возможностей в прикладном ПО) типичны для коммерческой SaaS. При наличии элементов КИИ по 187-ФЗ актуальность угроз 1–2-го типа возрастает.
• Число субъектов — порог 100 000 в российской пользовательской базе: до порога — УЗ-3, выше порога при угрозах 3-го типа — тоже УЗ-3, но с расширенным базовым набором мер ФСТЭК.

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

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

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

С 2025 года действует регулирование обезличенных ПДн (ст. 13.1 ФЗ-152, введена ФЗ-233 от 08.08.2024). Методы обезличивания установлены подзаконным актом РКН. Для задач сегментации и обучения ML применимы следующие методы:

• Введение идентификаторов — замена прямых идентификаторов (email, телефон) на технические псевдонимы без обратного маппинга. Применимо для feature store ML-пайплайна.
• Обобщение и агрегация — группировка пользователей в когорты вместо работы с индивидуальными профилями. Когортная сегментация (10+ субъектов в группе) не создаёт риска идентификации конкретного лица.
• Декомпозиция — разделение записей так, чтобы ни один фрагмент сам по себе не идентифицировал субъекта. Применимо при хранении фича-векторов отдельно от идентификаторов.

Важное ограничение: обезличивание должно быть необратимым в рамках доступных оператору вычислительных ресурсов. Если в производственной системе хранится маппинг-таблица «псевдоним → реальный ID», обезличивания в правовом смысле нет. Это частая ошибка в feature store: разработчики хранят mapping для возможности дебаггинга, создавая тем самым полноценную ИСПДн.

Логирование действий пользователей для ML-обучения также квалифицируется как обработка ПДн — логирование как ПДн. Строки лога с user_id, timestamp и action — это персональные данные в системе. Срок хранения логов должен быть закреплён в политике обработки ПДн; бессрочное хранение нарушает принцип «не дольше необходимого» по ст. 5 ФЗ-152.

Мультиарендность и поручение обработки: кто оператор в SaaS?

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

Типичная конфигурация: компания-заказчик (клиент SaaS) является оператором ПДн своих пользователей, а SaaS-провайдер — лицом, осуществляющим обработку по поручению. Фича-флаги, настраиваемые заказчиком под свою базу пользователей, технически обрабатываются инфраструктурой провайдера. Риски этой схемы:

• Отсутствие договора поручения — SaaS-провайдер де-факто является самостоятельным оператором без уведомления РКН (нарушение ст. 22 ФЗ-152, штраф по ч. 10 ст. 13.11: 100–300 тыс. ₽).
• Данные хранятся в едином тенанте без разграничения — при утечке у одного клиента данные других клиентов потенциально скомпрометированы; каждый пострадавший оператор несёт ответственность за собственных субъектов.
• Провайдер не раскрывает местоположение серверов — оператор-заказчик не может подтвердить соблюдение локализации по ч. 5 ст. 18.

Для SaaS-провайдера, самостоятельно обрабатывающего ПДн пользователей (например, аналитическая платформа с собственной пользовательской базой), классификация иная: провайдер — оператор, уведомление в РКН обязательно, локализация обязательна, облако должно быть в РФ.

Практические сценарии: три ситуации CTO

Сценарий 1. Иностранный SaaS фича-флагов, пользователи из РФ. CTO подключил LaunchDarkly (серверы в США) для управления флагами на 500 000 российских пользователей. Ситуация: первичная запись user_id и флагов происходит в инфраструктуре за пределами РФ. Доказательства нарушения: DNS-запись, договор с провайдером, технический аудит трафика. Вероятный исход: штраф 1–6 млн ₽ по ч. 8 ст. 13.11 КоАП за нарушение ч. 5 ст. 18 ФЗ-152. При повторном нарушении — 6–18 млн ₽ по ч. 9. Стратегия: миграция на self-hosted решение (Unleash, Flagsmith) в российском облаке или специализированный российский провайдер; оформление поручения обработки с облачным провайдером.

Сценарий 2. ML-сегментация с псевдонимизацией без удаления маппинга. CTO реализовал обезличивание для обучения рекомендательной модели: заменил email на UUID, но таблица соответствия UUID→email хранится в том же кластере БД. Ситуация: данные юридически остаются персональными, ИСПДн не обезличена. Доказательства нарушения: схема БД с маппинг-таблицей. Вероятный исход: при проверке РКН — предписание об устранении нарушения требований к обезличиванию; при отказе — штраф. Стратегия: разделение хранилищ (маппинг-таблица — в изолированной ИСПДн с ограниченным доступом и отдельным журналом доступа; ML feature store — в отдельной инфраструктуре без прямого доступа к маппингу).

Сценарий 3. Мультиарендная SaaS без договора поручения. CTO SaaS-платформы для ретейла обрабатывает ПДн пользователей клиентов-ретейлеров в едином кластере. Договоры с клиентами содержат пункт об обработке данных, но формально договора поручения по ст. 6 ФЗ-152 нет. Ситуация: провайдер фактически является оператором без уведомления РКН. Доказательства нарушения: договоры, архитектура БД, отсутствие в реестре РКН. Вероятный исход: штраф по ч. 1 ст. 13.11 (150–300 тыс. ₽) + штраф по ч. 10 за отсутствие уведомления (100–300 тыс. ₽) + предписание об оформлении поручений. Стратегия: классификация роли (оператор или обработчик по поручению), уведомление РКН, типовой договор поручения для всех клиентов, логическое разграничение данных по тенантам.

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

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

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

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

Для первичного сбора, систематизации и хранения ПДн граждан РФ — нет. Ч. 5 ст. 18 ФЗ-152 требует, чтобы эти операции выполнялись в базах данных на территории России. Последующая трансграничная передача обезличенных данных или передача по иным правовым основаниям (ст. 12 ФЗ-152) возможна с соблюдением требований: уведомление РКН, адекватная защита в стране-получателе или договорные гарантии. Использование AWS, GCP, Azure для хранения ПДн граждан РФ требует выбора дата-центра в РФ или выделенной российской инфраструктуры.

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

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

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

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

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

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

Итог

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

DATUM сопровождает IT-команды и CTO в части технического комплаенса 152-ФЗ: от определения УЗ и состава мер ФСТЭК до оценки архитектуры обезличивания ML-пайплайна и оформления договоров поручения с облачными провайдерами.

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

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

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