Структурированные vs неструктурированные логи

С 30.05.2025 за утечку ПДн из лог-систем оператор-юрлицо платит от 3 до 15 млн ₽ по ч. 12–14 ст. 13.11 КоАП, а при повторности — оборотный штраф до 500 млн ₽ по ч. 15. Для CISO это означает: архитектура логирования перестала быть исключительно технической задачей и стала юридическим риском. В этом материале — разбор того, как формат логов соотносится с требованиями ФЗ-152, Приказа ФСТЭК №21 и нормами обезличивания для ML.

Что такое структурированные и неструктурированные логи с точки зрения 152-ФЗ?

Лог — это запись о событии в информационной системе. Если запись содержит идентификатор физического лица (логин, email, IP-адрес, cookie-идентификатор, номер телефона), она подпадает под определение персональных данных по ст. 3 ФЗ-152. Форматный признак — структурированность или нет — не меняет правовой статус данных.

Структурированные логи (JSON, CEF, LEEF, syslog RFC 5424) содержат поля с явными именами: user_id, ip, action, timestamp. Это делает их машиночитаемыми, удобными для SIEM и одновременно — легко идентифицируемыми как ПДн при инциденте. Неструктурированные логи (plaintext, произвольный формат) труднее парсить, но факт наличия ПДн внутри строки от регулятора не скрывает.

Практическое следствие для CISO: при проверке РКН инспектор оценивает не формат, а наличие идентификаторов. Если в plaintext-логе есть email пользователя — это обработка ПДн без явного технического контроля.

Как формат логов влияет на уровень защищённости по ПП РФ №1119?

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

Порог в 100 000 субъектов — критичен: при его превышении система автоматически смещается на уровень выше. В мультиарендной SaaS логи всех арендаторов хранятся в единой инфраструктуре. Это означает, что совокупное число субъектов считается по всем арендаторам — и небольшой продукт с 50 клиентами-организациями по 2 000 пользователей каждый уже пересекает порог 100 000.

Структурированные логи упрощают выполнение технических мер: автоматическое маскирование полей ПДн, контроль доступа к конкретным атрибутам, экспорт в SIEM с фильтрацией. Неструктурированные логи требуют регулярных выражений или ML-парсеров для той же цели — и это дополнительная точка риска, если парсер ошибается.

Требования Приказа ФСТЭК №21: что обязательно для лог-систем?

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

Ключевой вопрос для структурированных логов — контроль состава полей. Если в JSON-схеме присутствует поле personal_email или full_name, оно должно либо не попадать в лог вовсе, либо маскироваться до записи. Для неструктурированных логов аналогичная задача решается на уровне препроцессора или log-shipper с правилами замены чувствительных паттернов.

Можно ли использовать логи с ПДн для обучения ML-моделей?

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

Для лог-данных наиболее применимы два метода. Первый — введение идентификаторов: замена реального user_id на псевдоним с сохранением ссылочной целостности внутри датасета. Второй — обобщение: замена точного IP-адреса на /24-подсеть, замена точного timestamp на часовой интервал. После применения методов данные должны утратить свойство идентифицируемости — это проверяется формально.

Критическая ошибка в ML-практике — обучение модели на «почти обезличенных» логах, где поле user_id заменено, но комбинация device_fingerprint + geolocation + session_duration позволяет реидентифицировать субъекта. Такой датасет юридически остаётся ПДн. Приказ РКН о методах обезличивания требует верификации необратимости — это должен подтверждать документ об оценке риска реидентификации.

Кто является оператором в мультиарендной SaaS: практические сценарии

Сценарий 1. SaaS-провайдер хранит логи арендатора в своём облаке. Ситуация: провайдер собирает application logs, включая действия пользователей арендатора. Юридически это поручение обработки по ст. 6 ч. 3 ФЗ-152 — провайдер действует как лицо, осуществляющее обработку по поручению. Оператором остаётся арендатор. Доказательства: договор с явной формулировкой поручения, перечнем ПДн и требованиями к защите. Без такого договора провайдер рискует быть признан самостоятельным оператором. Вероятный исход при проверке без договора: штраф по ч. 1 ст. 13.11 КоАП (150–300 тыс. ₽) за обработку без надлежащего основания. Стратегия: заключить договор поручения по ст. 6 ч. 3, включить в него требования к техническим мерам защиты лог-данных.

Сценарий 2. Логи уходят в SIEM, развёрнутый за рубежом. Ситуация: компания использует SIEM-SaaS (например, hosted в ЕС) и направляет туда лог-потоки с ПДн пользователей. Это трансграничная передача по ст. 12 ФЗ-152. До передачи в страну без адекватной защиты требуется уведомление РКН. Одновременно нарушается требование локализации ч. 5 ст. 18 ФЗ-152: запись и накопление ПДн граждан РФ должны происходить в базах на территории РФ. Вероятный исход: штраф по ч. 8 ст. 13.11 за нарушение локализации — 1–6 млн ₽; при повторности по ч. 9 — 6–18 млн ₽. Стратегия: перенести накопление логов в инфраструктуру, физически расположенную в РФ (облако в РФ по требованию ч. 5 ст. 18), а за рубеж — только обезличенные агрегаты.

Сценарий 3. Инцидент: утечка лог-файлов с ПДн пользователей. Ситуация: неструктурированные plaintext-логи без маскирования попали к злоумышленнику. В логах — email и IP-адреса 15 000 пользователей. Это утечка более 10 000 субъектов — квалификация по ч. 13 ст. 13.11 КоАП (штраф 5–10 млн ₽). У CISO — 24 часа на первичное уведомление РКН по ч. 3.1 ст. 21 ФЗ-152 и Приказу РКН №187, 72 часа — на отчёт о результатах расследования. Срок не восстанавливается. Неуведомление добавляет штраф по ч. 11 ст. 13.11 — ещё 1–3 млн ₽. Стратегия: иметь заранее подготовленный playbook реагирования с шаблоном уведомления и процедурой оценки масштаба утечки — это единственный способ уложиться в 24 часа.

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

Кейс 1. IT-компания (Северо-Западный ФО, осень 2025) разрабатывала SaaS-продукт для HR-автоматизации. Логи приложения собирались в ELK-стек, развёрнутый на арендованных серверах европейского провайдера. В логах содержались email и логины пользователей (арендаторов). При внеплановой проверке РКН установил факт накопления ПДн граждан РФ за пределами территории России. Компания получила предписание и протокол по ч. 8 ст. 13.11 КоАП (нарушение локализации). По итогам переговоров инфраструктура была перенесена в российское облако, что позволило применить смягчающие обстоятельства при рассмотрении дела.

Кейс 2. Финтех-компания (Центральный ФО, лето 2025) использовала неструктурированные логи транзакционного сервиса без маскирования номеров карт и email. После хакерской атаки данные около 12 000 субъектов оказались в открытом доступе. CISO направил первичное уведомление в РКН за 21 час. Структура неструктурированных логов не позволила автоматически подсчитать число затронутых субъектов — это заняло дополнительные 4 часа. Отчёт по итогам расследования был подан в срок 72 часа. Штраф по ч. 13 ст. 13.11 составил сумму в нижней части диапазона с учётом оперативности уведомления и отсутствия предшествующих нарушений.

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

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

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

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

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

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

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

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

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

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

Оператором, как правило, является арендатор (клиент SaaS), определяющий цели и состав обработки ПДн своих пользователей. Провайдер SaaS действует как лицо, осуществляющее обработку по поручению оператора, согласно ст. 6 ч. 3 ФЗ-152. Для легализации этой схемы необходим договор поручения с перечнем ПДн, описанием действий и требованиями к защите. Без договора провайдер рискует быть признан самостоятельным оператором и нести ответственность по ст. 13.11 КоАП напрямую.

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

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

Итог

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

Практика DATUM по технической стороне 152-ФЗ охватывает определение применимого УЗ для SaaS-инфраструктур, разработку политик логирования, оценку воздействия (DPIA) для ML-датасетов из лог-данных и сопровождение при проверках РКН в IT-компаниях.