Логи приложения (application logs)

С 30.05.2025 год стал точкой перелома: ст. 13.11 КоАП расширилась до 18 частей, а ст. 272.1 УК РФ ввела уголовную ответственность за незаконное хранение компьютерной информации с ПДн. Для CISO application logs — уже не технический артефакт, а предмет регуляторного контроля. В этом материале: что считается ПДн в логах, как определить уровень защищённости ИСПДн, какие меры ФСТЭК обязательны, как обезличить данные для ML и что делать с облачными хранилищами и мультиарендной SaaS.

Когда логи приложения становятся персональными данными?

Логи приложения фиксируют действия пользователей: IP-адреса, идентификаторы сессий, user-агенты, временны́е метки, ошибки с трассировкой стека, параметры запросов. Каждый из этих элементов в отдельности может не идентифицировать человека. Но в совокупности — идентифицирует. Роскомнадзор последовательно применяет расширительный подход: IP-адрес в связке с датой и временем признаётся персональными данными по ст. 3 ФЗ-152.

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

Биометрические ПДн в логах — отдельный сценарий. Если приложение использует распознавание лиц или голосовую биометрию и пишет результаты верификации в лог, это подпадает под ст. 11 ФЗ-152 и ч. 16–17 ст. 13.11 КоАП (штраф за утечку биометрии — 15–20 млн ₽).

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

Как определить уровень защищённости ИСПДн для системы логирования?

Уровень защищённости (УЗ-1 — УЗ-4) устанавливается по ПП РФ №1119 от 01.11.2012. Система логирования — это часть информационной системы персональных данных (ИСПДн). Если логи хранятся в отдельном кластере (Elasticsearch, Loki, Splunk), этот кластер сам по себе является ИСПДн и требует собственного определения УЗ.

Алгоритм по ПП РФ №1119:

• Категория ПДн: общие (имя, контакты, IP), специальные (здоровье, биометрия) или иные — каждая требует своей матрицы.
• Тип актуальных угроз: угрозы 1-го типа (НДВ в системном ПО), 2-го типа (НДВ в прикладном ПО), 3-го типа (отсутствие НДВ). Для большинства коммерческих систем — тип 3.
• Число субъектов: порог 100 000 — выше или ниже. Системы логирования enterprise-класса легко пересекают порог.

Типовая конфигурация: SaaS с общими ПДн, угрозы 3-го типа, более 100 000 субъектов → УЗ-3. Если в логах есть специальные ПДн при угрозах 3-го типа — УЗ-2 независимо от числа субъектов. Наличие угроз 1-го типа сразу переводит в УЗ-1.

Для SaaS с мультиарендностью (несколько клиентов-операторов, один инфраструктурный стек) применяется принцип наивысшего УЗ среди всех арендаторов. Если хотя бы один клиент обрабатывает специальные ПДн — весь кластер логов должен соответствовать их уровню.

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

Приказ ФСТЭК №21 от 18.02.2013 определяет состав мер защиты в 15 функциональных группах. Для системы логирования критичны несколько групп.

РСБ (регистрация событий безопасности) — базовая группа для любой системы логирования. Требует фиксации событий доступа, изменений конфигурации, ошибок аутентификации. Меры РСБ входят в базовый набор для всех УЗ.

УПД (управление правами доступа) — определяет, кто может читать, изменять и удалять логи. Для УЗ-3 и выше обязательна ролевая модель с принципом минимальных привилегий. Инженер DevOps не должен иметь права на удаление записей аудита.

ЗНИ (защита носителей информации) — распространяется на хранилища логов. При размещении в объектном хранилище (S3-совместимом) требуется шифрование данных в покое для УЗ-1 и УЗ-2.

СОВ (система обнаружения вторжений) — для УЗ-1 и УЗ-2 СОВ обязательна. Для УЗ-3 и УЗ-4 — компенсирующие меры.

АНЗ (анализ защищённости) — периодический анализ конфигураций. Для системы логирования это означает регулярный аудит правил ротации, срока хранения и прав доступа.

Часто встречаемая ошибка: логи хранятся без ограничения срока, доступ открыт всей команде разработки, ротация не настроена. При проверке РКН это фиксируется как нарушение ст. 19 ФЗ-152 в совокупности с Приказом №21.

Как обезличить логи для ML и какие методы признаёт РКН?

Передача логов с ПДн в ML-пайплайн без обезличивания — это передача ПДн третьему лицу без правового основания. Либо это поручение обработки по ст. 6 ч. 3 ФЗ-152 (с договором и перечнем операций), либо — нарушение, влекущее штраф по ч. 1 ст. 13.11 КоАП (150–300 тыс. ₽) и риск квалификации по ст. 272.1 УК.

РКН признаёт пять методов обезличивания (Приказ РКН о методах обезличивания, действует с 01.09.2025):

• Введение идентификаторов — замена прямых идентификаторов (email, user_id) на псевдонимы. Псевдонимизация не обезличивание в полном смысле, если таблица соответствия хранится доступно.
• Изменение состава или семантики — удаление или замена атрибутов, позволяющих идентификацию (точный IP заменяется сетью /24).
• Декомпозиция — разделение данных на независимые части, каждая из которых не позволяет идентификацию.
• Перемешивание — нарушение связей между записями при сохранении статистических свойств.
• Обобщение и агрегация — замена точных значений диапазонами; применяется для временны́х меток (точная секунда → час).

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

Облако в РФ, SaaS с мультиарендностью и КИИ: три сценария для CISO

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

Сценарий 2. SaaS с мультиарендностью — кто оператор? Ситуация: SaaS-платформа предоставляет услуги B2B; каждый клиент является оператором ПДн своих пользователей. Логи платформы содержат данные пользователей всех клиентов вперемешку. Доказательства: договоры с клиентами, настройки мультиарендности, архитектурная документация. Вероятный исход при отсутствии договоров поручения: платформа является самостоятельным оператором без правового основания по ст. 6 ФЗ-152. РКН квалифицирует как обработку в целях, не совместимых с заявленными. Стратегия: оформить договоры поручения обработки по ст. 6 ч. 3 ФЗ-152 с каждым клиентом-оператором; разграничить логи по арендаторам на уровне хранилища; в уведомлении РКН указать роль «лица, осуществляющего обработку по поручению».

Сценарий 3. Система логирования в инфраструктуре КИИ. Ситуация: SIEM-система обрабатывает логи объектов критической информационной инфраструктуры (ФЗ-187). В логах — ПДн операторов и администраторов КИИ. Доказательства: категорирование объектов КИИ, реестр ГосСОПКА. Вероятный исход: одновременные требования 152-ФЗ (защита ПДн), ФЗ-187 (защита КИИ), Приказа ФСТЭК №239. Неисполнение любого образует самостоятельный состав нарушения. Стратегия: провести совместную оценку требований; разработать модель угроз с учётом обоих регуляторных контекстов; обеспечить приоритет требований КИИ там, где они строже.

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

Кейс 1. IT-компания (Северо-Западный ФО, осень 2025): CISO обнаружил, что система централизованного логирования (self-hosted ELK) содержит IP-адреса, идентификаторы сессий и фрагменты запросов с email-адресами пользователей — более 120 000 субъектов. Хранилище находилось в сегменте без шифрования в покое, права доступа не разграничены между командами DevOps и InfoSec. После аудита DATUM выявлено несоответствие УЗ-3 (базовый набор по Приказу №21 не реализован: отсутствовали меры группы РСБ и УПД), отсутствие договора поручения с провайдером SIEM. Предписание РКН удалось оспорить частично — суд применил смягчающие обстоятельства в связи с оперативным устранением нарушений до вынесения постановления.

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

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

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

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

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

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

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

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

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

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

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

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

5. Какие СЗИ обязательны для системы логирования?

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

Итог

Логи приложения — полноправный объект регулирования 152-ФЗ и Приказа ФСТЭК №21. Уровень защищённости, состав мер, порядок обезличивания для ML и условия поручения обработки — это не абстрактные требования, а конкретные основания для штрафов от 150 тыс. до 500 млн ₽ и уголовной ответственности по ст. 272.1 УК. Ошибка в определении УЗ или хранение логов в иностранном облаке — два наиболее частых нарушения, которые фиксируются при проверках РКН в IT-компаниях с 2025 года.

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