аналитика 28 апреля 2029 По состоянию на 28 апреля 2029

Метод 1: введение идентификаторов

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

Для IT-команды, разрабатывающей SaaS или обучающей ML-модели на реальных данных: с 01.09.2025 некорректное обезличивание означает не просто технический долг, а нарушение ч. 13 ст. 13.1 ФЗ-152 и риск штрафа по ст. 13.11 КоАП, начиная от 150 000 ₽.

→ Если CTO строит пайплайн обработки ПДн или готовит SaaS к уровню защищённости, — ниже разобраны нормы, архитектурные сценарии и точки риска.

С 01.09.2025 обезличивание в России перестало быть добровольным инструментом. Приказ РКН закрепил пять методов и требования к их применению; метод введения идентификаторов — базовый и наиболее распространённый. Для технических директоров, которые строят SaaS-платформы, аналитические пайплайны или мультиарендную инфраструктуру, этот метод одновременно является рабочим инструментом и источником compliance-рисков, если реализован неправильно.

Что такое введение идентификаторов и чем оно отличается от шифрования?

Введение идентификаторов — это замена прямых персональных атрибутов (ФИО, email, номер телефона, ИНН) на условные псевдонимы: числовые последовательности, UUID, хэши или иные символьные обозначения, не раскрывающие личность субъекта напрямую. Соответствие «псевдоним — реальная личность» хранится в отдельной таблице сопоставления, доступ к которой ограничен.

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

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

Для ML-пайплайна это означает следующее: аналитики и дата-инженеры получают датасет с псевдонимами и работают с ним как с не-ПДн. Таблица сопоставления остаётся у оператора или ответственного за обработку и в обучающий контур не передаётся. Нарушение этого разделения делает весь датасет персональными данными независимо от наличия UUID вместо ФИО.

Как метод соотносится с Приказом РКН и ПП РФ № 1119: что обязан сделать CTO?

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

«ПП РФ № 1119: УЗ-3 обязателен при обработке иных (общих) ПДн более 100 000 субъектов при угрозах 3-го типа. УЗ-2 — при специальных категориях более 100 000 субъектов. УЗ-1 — при угрозах 1-го типа независимо от объёма.»

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

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

Готовите ML-пайплайн или SaaS с обработкой ПДн — уровень защищённости определён?

Если CTO строит аналитическую инфраструктуру и не уверен, правильно ли разграничены обезличенный и персональный слои, — проверка займёт несколько часов, но ошибка в архитектуре обнаруживается при проверке РКН уже как факт нарушения. Некорректная классификация ИСПДн означает применение недостаточных технических мер по Приказу ФСТЭК № 21, что само по себе образует состав по ч. 1 ст. 13.11 КоАП.

Заказать аудит 152-ФЗ

Ответим за 2 часа · +7 (983) 510-38-76 · info@vitveteam.ru

Какие архитектурные ошибки делают введение идентификаторов юридически недействительным?

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

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

Второй: передача таблицы сопоставления подрядчику. В мультиарендной SaaS таблица сопоставления нередко передаётся аналитическому подрядчику «для поддержки». Это поручение обработки по ст. 6 ФЗ-152 — с оформлением договора, перечнем действий и указанием цели. Без договора поручения — нарушение по ч. 1 ст. 13.11 КоАП.

Третий: логи приложения содержат прямые ПДн. Логирование как ПДн — распространённый пробел. Если application logs содержат email, IP-адреса или сессионные токены, привязанные к субъекту, — они являются персональными данными. Обезличенный датасет при этом не исправляет ситуацию, поскольку у атакующего или у регулятора есть второй путь к идентификации через логи.

«Ст. 6 ФЗ-152, п. 3: обработка ПДн по поручению оператора допускается на основании договора. Поручение должно содержать перечень действий, цель, обязательство по конфиденциальности. Нарушение — основание для штрафа по ч. 1 ст. 13.11 КоАП (150 000 — 300 000 ₽).»

Что проверить перед внедрением метода

Таблица сопоставления хранится в отдельной базе с отдельной политикой доступа и журналом обращений.
Аналитический слой (ML-среда, BI, хранилище) не имеет прямого доступа к таблице сопоставления — ни через сервисные аккаунты, ни через join-запросы.
Логи приложения проверены на наличие прямых идентификаторов; при необходимости применено маскирование или ротация токенов.
Алгоритм псевдонимизации задокументирован в составе ОРД по ст. 18.1 ФЗ-152; документ утверждён приказом и включён в политику обработки ПДн.
Подрядчики, получающие обезличенные данные, работают по договору поручения обработки с перечнем допустимых действий.

Как метод применяется в SaaS с мультиарендностью и облаком в РФ?

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

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

Требование локализации по ч. 5 ст. 18 ФЗ-152 распространяется на запись, систематизацию, накопление, хранение, уточнение и извлечение ПДн граждан РФ. Таблица сопоставления содержит реальные персональные данные — она обязана находиться на серверах в Российской Федерации. Обезличенный датасет (без таблицы сопоставления) может обрабатываться за рубежом без нарушения ч. 5 ст. 18 — это одно из ключевых практических преимуществ метода для международных команд.

«Ч. 5 ст. 18 ФЗ-152: запись, систематизация, накопление, хранение, уточнение, извлечение ПДн граждан РФ осуществляются с использованием баз данных, расположенных на территории РФ. Нарушение — ч. 8 ст. 13.11 КоАП: штраф 1 000 000 — 6 000 000 ₽; повторное — ч. 9: 6 000 000 — 18 000 000 ₽.»

Для систем, попадающих под КИИ по ФЗ-187, введение идентификаторов не снимает требований по категорированию объекта и обеспечению безопасности. Обезличенные данные в значимом объекте КИИ требуют оценки в рамках категорирования независимо от применённого метода обезличивания.

Если CTO переносит аналитику в облако или передаёт данные зарубежному подрядчику — проверьте, где хранится таблица сопоставления. Нарушение локализации по ч. 8 ст. 13.11 КоАП начинается от 1 000 000 ₽, повторное — от 6 000 000 ₽. Юристы DATUM проведут DPIA и укажут точки несоответствия.

Провести DPIA

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

Кейс 1. FinTech-компания (Центральный ФО, осень 2025): технический директор внедрил UUID-псевдонимизацию для ML-модели скоринга. Таблица сопоставления осталась в той же PostgreSQL-схеме, к которой имели доступ дата-сайентисты. При плановой проверке РКН установил, что аналитическая среда имеет прямой доступ к ПДн через join. Компании выставили предписание и составили протокол по ч. 1 ст. 13.11 КоАП; штраф составил несколько сотен тысяч рублей. После разделения схем и оформления договора поручения нарушение устранено.

Кейс 2. SaaS-платформа для HR (Сибирский ФО, начало 2026): провайдер хранил единую таблицу сопоставления для всех клиентов-арендаторов в облаке иностранного провайдера с репликацией в европейский регион. Проверка РКН по жалобе арендатора выявила нарушение ч. 5 ст. 18 ФЗ-152 (локализация). Дополнительно установлено отсутствие договоров поручения с частью арендаторов. По совокупности протоколов штраф составил несколько миллионов рублей. Таблица сопоставления перенесена в облако российского провайдера; договоры поручения переоформлены.

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

DPIA (оценка воздействия) — оценка рисков обезличивания для конкретной архитектуры
Аудит соответствия 152-ФЗ — проверка ИСПДн, уровней защищённости, ОРД
Комплект ОРД под ключ — документирование метода обезличивания по требованиям РКН

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

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

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

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

Обезличенный датасет (без таблицы сопоставления) формально не является персональными данными при корректно применённом методе введения идентификаторов — его обработка в иностранном облаке не нарушает ч. 5 ст. 18 ФЗ-152. Таблица сопоставления и операционные базы с реальными ПДн граждан РФ обязаны храниться на серверах в РФ. Нарушение — ч. 8 ст. 13.11 КоАП: штраф от 1 000 000 до 6 000 000 ₽. Трансграничная передача обезличенных данных уведомления РКН по ст. 12 ФЗ-152 не требует.

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

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

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

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

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

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

Итог

Введение идентификаторов — практически применимый метод снижения объёма персональных данных в аналитическом слое, при условии архитектурного разделения таблицы сопоставления и документирования алгоритма. Без этих двух условий псевдонимизация не создаёт юридически значимого обезличивания и не снижает требования по ФЗ-152 и Приказу ФСТЭК № 21.

Практика DATUM включает аудит ИСПДн по ПП РФ № 1119, оценку архитектуры обезличивания для ML-пайплайнов и SaaS, а также оформление договоров поручения обработки для мультиарендных систем.

АГ

Антон Громов

Аналитик · Технологии и ИБ

Аналитик DATUM по технологиям и информационной безопасности. Специализация — УЗ-1..4 (ПП РФ № 1119), Приказ ФСТЭК № 21, обезличивание ПДн для ML, логирование и A/B-тесты, защита SaaS-инфраструктуры, реагирование на утечки за 24/72 часа, ст. 272.1 УК.