Псевдонимизация логов: подходы

Псевдонимизация логов — один из немногих технических приёмов, который одновременно снижает регуляторные риски по ФЗ-152 и даёт операционный выигрыш: меньший объём данных, защищённых жёсткими требованиями ФСТЭК. Для CISO в SaaS-компании это особенно актуально: мультиарендные системы обрабатывают логи десятков клиентов-операторов, а правило поручения обработки по ст. 6 ФЗ-152 делает вас обработчиком с полной ответственностью за технические меры. В этом материале — четыре практических подхода, привязка к УЗ-1..4, требования ФСТЭК и алгоритм выбора метода под конкретную архитектуру.

Почему логи — это персональные данные и при каком УЗ хранить?

По позиции РКН и устойчивой правоприменительной практике, IP-адрес, user_id, session_id в связке с временной меткой и действием пользователя квалифицируются как ПДн: они позволяют идентифицировать физическое лицо прямо или косвенно (ст. 3 ФЗ-152). Логи приложения, содержащие эти поля, становятся информационной системой персональных данных (ИСПДн), а значит, попадают под Постановление Правительства №1119 и Приказ ФСТЭК №21.

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

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

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

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

Подход 1. Детерминированное хеширование (HMAC-SHA256 с секретным ключом). Каждый идентификатор хешируется с HMAC-ключом, который хранится в отдельном HSM или KMS. На выходе — стабильный псевдоним: одному user_id всегда соответствует один токен. Преимущество — возможность связывать события одного пользователя внутри сессионного окна без раскрытия оригинала. Ограничение — при компрометации ключа все псевдонимы раскрываемы, поэтому ротация ключа обязательна (рекомендуется ежегодно или при инциденте). По классификации Приказа РКН о методах обезличивания — ближайший аналог «введения идентификаторов».

Подход 2. Токенизация с таблицей соответствия. Оригинальный идентификатор заменяется случайным UUID; таблица соответствия хранится в изолированной БД с отдельным контролем доступа (УПД-группа мер по Приказу ФСТЭК №21). Обратное разрешение возможно только через авторизованный API. Этот подход даёт наилучший результат с точки зрения классификации данных: при физической изоляции таблицы лог-хранилище формально не содержит прямых ПДн. Недостаток — операционная сложность: нужен отдельный сервис токенизации с высокой доступностью.

Подход 3. Агрегация и генерализация перед записью. Вместо хранения точного IP записывается /24-подсеть; вместо точной временной метки — 15-минутный интервал. Подход применим для аналитических логов, где точность идентификации не требуется. По методологии обезличивания РКН — «обобщение». Для ML-задач (аномалии поведения, воронки конверсии) метод достаточен. Для расследования инцидентов безопасности — недостаточен: точная атрибуция теряется.

Подход 4. Дифференциальная приватность (Differential Privacy) при записи в аналитическое хранилище. Шум добавляется к числовым агрегатам на этапе сброса в BI-систему или Data Lake. Метод актуален для обезличивания ML-датасетов (обезличивание для ML): модели обучаются на зашумлённых данных, что соответствует духу ст. 13.1 ФЗ-152 о регулировании обезличенных ПДн. Технически сложен; применяется в компаниях с развитой data-инженерией.

Как псевдонимизация логов встраивается в требования ФСТЭК и КИИ?

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

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

Для субъектов КИИ (187-ФЗ) ситуация жёстче: значимые объекты КИИ обязаны выполнять требования Приказа ФСТЭК №239. Псевдонимизация логов не снимает обязательств по непрерывному мониторингу событий безопасности (подключение к НКЦКИ), но снижает класс опасности утечки лог-данных как отдельного вектора атаки.

Облако в РФ: размещение хранилища логов у российского облачного провайдера (Yandex Cloud, VK Cloud, SberCloud) само по себе не выполняет требования локализации по ч. 5 ст. 18 ФЗ-152, если исходные ПДн первично собираются за рубежом. С ужесточением локализации с 01.07.2025 (ФЗ-233) первичная запись, систематизация, накопление, хранение и извлечение ПДн граждан РФ должны происходить исключительно в базах на территории РФ. Лог-сервис, работающий на иностранном облаке, создаёт риск по ч. 8 ст. 13.11 (1–6 млн ₽).

Мультиарендность SaaS: кто оператор и кто несёт ответственность за логи?

В мультиарендной SaaS-архитектуре логи технически общие: один кластер ELK или ClickHouse обрабатывает события всех клиентов. Вопрос о роли SaaS-вендора — оператор или обработчик по поручению (ст. 6 ФЗ-152) — определяет, на кого распространяются требования УЗ и ФСТЭК.

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

Практический вывод: SaaS-вендор, хранящий логи мультиарендной платформы без изоляции данных по клиентам и без псевдонимизации идентификаторов конечных пользователей, фактически обрабатывает ПДн в интересах нескольких операторов одновременно. При утечке риск квалификации по ч. 14 ст. 13.11 КоАП (более 100 000 субъектов) многократно возрастает — сумма записей по всем арендаторам складывается.

Типовые ситуации: как псевдонимизация влияет на риск и исход

Ситуация 1. Утечка ELK-индекса с сырыми логами. ИСПДн обрабатывает логи 200 000 пользователей SaaS-платформы. Логи содержат IP и user_id в открытом виде, хранятся 180 дней. Хакерская группа получает доступ к Kibana без аутентификации. Факт утечки фиксируется командой ИБ. Применимые нормы: ч. 14 ст. 13.11 КоАП (более 100 000 субъектов) — штраф 10–15 млн ₽; ч. 11 ст. 13.11 — штраф 1–3 млн ₽ за неуведомление РКН в 24 часа (ч. 3.1 ст. 21 ФЗ-152). Стратегия: внедрить псевдонимизацию до инцидента снижает ценность похищенных данных и даёт аргумент для смягчения по ст. 4.1 КоАП.

Ситуация 2. Передача логов в иностранный SIEM. CISO использует облачный SIEM-сервис (США) для корреляции событий. В логи попадают IP и user_id российских пользователей. С 01.07.2025 это нарушение ч. 5 ст. 18 ФЗ-152 (локализация) — штраф по ч. 8 ст. 13.11 от 1 млн ₽. Псевдонимизация на уровне сборщика (Fluentd/Vector) до отправки в SIEM — технически снимает прямую привязку к субъекту. Оценка: снижает риск локализации, но требует юридического оформления как трансграничной передачи с уведомлением РКН по ст. 12 ФЗ-152, если SIEM обрабатывает даже псевдонимизированные данные, которые могут быть раскрыты при наличии ключа.

Ситуация 3. ML-модель обучается на производственных логах. Data-команда запрашивает выгрузку логов для обучения модели предсказания оттока. Логи содержат поведенческие паттерны с user_id. Прямая передача — обработка ПДн для новой цели без отдельного правового основания (нарушение принципа ограничения цели, ст. 5 ФЗ-152). Применение DP-обезличивания или агрегации (подход 3–4) переводит датасет в категорию обезличенных данных по ст. 13.1 ФЗ-152, что снимает требование правового основания для ML-использования. Документировать — методом обезличивания согласно Приказу РКН о методах обезличивания.

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

Кейс 1. Финтех-компания (Центральный ФО, осень 2025) обрабатывала логи мобильного банка: 450 000 пользователей, user_id и IP в открытом виде, хранение 12 месяцев. После планового аудита выявлено несоответствие УЗ-3 (не реализованы меры РСБ.3 и ЗИС.3 по Приказу ФСТЭК №21). CISO внедрил HMAC-псевдонимизацию на уровне log-шиппера, изолировал ключ в Yandex KMS, сократил срок хранения до 90 дней. Повторный аудит подтвердил соответствие. Уведомление РКН обновлено с учётом изменения состава ИСПДн. Штрафных производств не возникло.

Кейс 2. SaaS-вендор (Северо-Западный ФО, начало 2026) хранил общий ELK-кластер для 30 клиентов-операторов: суммарно более 200 000 конечных субъектов. Договор поручения обработки отсутствовал. РКН провёл внеплановую проверку по обращению одного из клиентов. Выдано предписание по ч. 1 ст. 13.11 КоАП, параллельно — требование представить договор поручения в течение 10 рабочих дней. Компания оперативно ввела токенизацию идентификаторов по клиентам, заключила договоры поручения и устранила нарушение. Арбитражный суд региона учёл оперативность устранения при определении размера санкции. ⚠️ Конкретный номер дела и точная сумма — менеджер уточняет при публикации.

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

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

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

2. Можно ли использовать иностранные облака для хранения логов с ПДн?

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

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

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

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

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

5. Какие СЗИ обязательны для ИСПДн с логами при УЗ-3?

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

Итог

Псевдонимизация логов — не самоцель, а инструмент снижения класса ИСПДн и уменьшения ценности данных при утечке. Выбор метода (HMAC, токенизация, агрегация, DP) определяется требованиями к воспроизводимости инцидентов, пригодностью для ML и уровнем изоляции ключевого материала. При числе субъектов свыше 100 000 вопрос перестаёт быть техническим: ч. 14 ст. 13.11 КоАП (10–15 млн ₽) и оборотный штраф по ч. 15 делают его бюджетным.

DATUM сопровождает IT-компании и SaaS-вендоров в выстраивании технической архитектуры обработки ПДн, соответствующей ФЗ-152, ПП РФ №1119 и Приказу ФСТЭК №21: от определения УЗ и модели угроз до договоров поручения обработки с клиентами-операторами.

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

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