Логи и ст. 18.1 ч. 2 152-ФЗ

Логи — один из наиболее уязвимых классов данных в инфраструктуре: хранятся долго, доступны широкому кругу сотрудников, редко включаются в модель угроз. Между тем IP-адрес, user-agent, идентификатор пользователя и временная метка в совокупности — персональные данные по ст. 3 152-ФЗ. Ст. 18.1 ч. 2 обязывает оператора отразить в политике обработки ПДн перечень конкретных мер, в том числе технических. Приказ ФСТЭК №21 и ПП РФ №1119 устанавливают, какие именно меры обязательны в зависимости от уровня защищённости ИСПДн (УЗ-1..УЗ-4). В этой статье — разбор для CISO: как квалифицировать логи, какой уровень защищённости выбрать для SaaS, что требует ФСТЭК и как не получить штраф по ст. 13.11 из-за логов.

Являются ли логи персональными данными по 152-ФЗ?

Персональными данными признаётся любая информация, относящаяся прямо или косвенно к определённому или определяемому физическому лицу (ст. 3 152-ФЗ). Логи приложения, как правило, содержат: идентификатор пользователя или сессии, IP-адрес, дату и время события, тип операции, user-agent браузера. Каждый из этих элементов в отдельности может быть анонимным. В связке они идентифицируют конкретного человека — и значит, являются ПДн.

Позиция Роскомнадзора по IP-адресам как ПДн остаётся неизменной с 2013 года: если IP позволяет установить личность с разумными усилиями оператора, он относится к персональным данным. Для SaaS-сервиса, где в базе есть таблица пользователей с теми же IP — это безусловно ПДн.

Из этого следует практическое требование: если логи содержат ПДн, они должны быть отражены в политике обработки в разделе «технические меры защиты». Отсутствие упоминания — формальное нарушение ч. 2 ст. 18.1, за которое с 30.05.2025 предусмотрен штраф по ч. 3 ст. 13.11 КоАП: 30 000–60 000 ₽ для юридического лица. Это административный минимум, но протокол фиксируется — и создаёт «первичность», после которой следующее нарушение считается повторным.

Какой уровень защищённости (УЗ) применяется к логам и как его определить?

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

На практике разграничение выглядит так:

• УЗ-4 — иные ПДн (не специальные), угрозы 3-го типа, число субъектов менее 100 000. Типично для небольшого SaaS с ограниченной базой.
• УЗ-3 — иные ПДн, угрозы 3-го типа, более 100 000 субъектов, либо угрозы 2-го типа при меньшей базе. Большинство средних SaaS-сервисов.
• УЗ-2 — специальные ПДн или угрозы 1-го типа при иных категориях. Медицинские сервисы, HR-платформы с медданными.
• УЗ-1 — специальные ПДн при угрозах 1–2-го типа более 100 000 субъектов. Редко, но встречается в крупных медицинских и госИС.

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

Что требует Приказ ФСТЭК №21 при логировании в ИСПДн?

Приказ ФСТЭК №21 выделяет 15 групп мер защиты. Для логирования непосредственно релевантны две: регистрация событий безопасности (РСБ) и аудит безопасности (АНЗ). Состав мер в каждой группе зависит от уровня защищённости — от базового до усиленного.

Для УЗ-3 и УЗ-4 Приказ №21 требует:

• Регистрацию событий входа/выхода пользователей, изменений конфигурации, попыток несанкционированного доступа.
• Защиту журналов регистрации от несанкционированного изменения и удаления.
• Хранение журналов в течение срока, определённого политикой оператора (но не менее срока, достаточного для расследования инцидента).
• Доступ к журналам — только по принципу наименьших привилегий (группа УПД — управление правами доступа).

Для УЗ-1 и УЗ-2 добавляются: централизованный сбор событий (SIEM), мониторинг в реальном времени, реагирование на аномалии. Это уже требования группы СОВ (системы обнаружения вторжений).

На практике CISO сталкивается с типичной проблемой: логи пишутся, но хранятся в той же базе, что и данные приложения, — без разграничения прав, без подписи целостности, без выгрузки на защищённый SIEM. Такая конфигурация формально нарушает меры РСБ и ЗНИ (защита носителей информации) по Приказу №21, даже если сама ИСПДн задокументирована корректно.

Как обезличить логи для использования в ML без нарушения 152-ФЗ?

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

Для логов применение обезличивания на практике выглядит так:

• Введение идентификаторов — замена реального user_id на псевдоним или хэш без сохранения исходной таблицы соответствия в той же системе.
• Агрегация — замена точных временных меток и IP на временные диапазоны и подсети (/24), если для ML-задачи точность не критична.
• Изменение состава — удаление из лог-строки полей, не нужных для обучения модели: user-agent, геолокация, cookie-значения.

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

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

Какие риски создаёт SaaS-мультиаренда и поручение обработки?

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

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

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

Типовые сценарии нарушений и стратегии защиты

Сценарий 1. Утечка из централизованного лог-агрегатора. SaaS-платформа использует ELK-стек с открытым Kibana без аутентификации. Исследователь безопасности обнаруживает индекс с логами API, содержащими user_id и IP 40 000 пользователей. РКН возбуждает дело по ч. 13 ст. 13.11 КоАП (утечка от 10 000 до 100 000 субъектов). Штраф для юридического лица — 5–10 млн ₽. Параллельно — штраф по ч. 11 ст. 13.11 за неуведомление об утечке в 24 часа: 1–3 млн ₽. Стратегия защиты: закрытый доступ к SIEM/Kibana, аутентификация, шифрование данных в транзите и на хранении, документированный SLA уведомления об инциденте.

Сценарий 2. Логи без договора поручения. IT-компания (Центральный ФО, начало 2026) хранила логи своего корпоративного CRM в облаке подрядчика без письменного договора поручения. При плановой проверке РКН установил отсутствие договора и обработку ПДн третьим лицом сверх правовых оснований. Дело по ч. 1 ст. 13.11 КоАП. Штраф в диапазоне 150 000–300 000 ₽. Стратегия: каждый подрядчик, имеющий доступ к логам с ПДн, должен иметь письменный договор поручения по ст. 6 ч. 3 152-ФЗ с перечнем допустимых действий.

Сценарий 3. ML-обучение на необезличенных логах. Команда data science использовала production-логи для обучения модели рекомендаций. Логи содержали user_id, сессионные токены и поведенческие события. Модель передана облачному сервису за рубежом без уведомления РКН о трансграничной передаче (ст. 12 152-ФЗ). Это трансграничная передача ПДн в страну без адекватной защиты. Одновременно — нарушение ч. 5 ст. 18 (локализация). Стратегия: обезличивание по методам ст. 13.1 перед выгрузкой в ML-конвейер, облако в РФ или уведомление РКН о трансграничной передаче.

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

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

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

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

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

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

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

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

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

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

Оператором ПДн конечных пользователей является арендатор (клиент SaaS), а не провайдер платформы. SaaS-провайдер — лицо, осуществляющее обработку по поручению оператора (ст. 6 ч. 3 152-ФЗ). Это означает: все требования ст. 19 и ст. 18.1 в части мер защиты распространяются на провайдера через договор поручения. Если логи содержат ПДн клиентов арендатора и провайдер их хранит без договора поручения — возникает самостоятельное основание для штрафа по ч. 1 ст. 13.11 КоАП.

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

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

Итог

Логи — часть ИСПДн, а не техническая деталь за периметром 152-ФЗ. Ст. 18.1 ч. 2 обязывает отразить их в политике; Приказ ФСТЭК №21 — реализовать конкретные меры РСБ и ЗНИ; ч. 5 ст. 18 — хранить только в российских базах данных. SaaS-мультиаренда добавляет требования к договорам поручения, а ML-использование логов требует полноценного обезличивания, а не псевдонимизации.

DATUM сопровождает IT-компании и SaaS-провайдеров в построении системы защиты ПДн: от классификации ИСПДн по ПП РФ №1119 до аудита договоров поручения и DPIA для ML-конвейеров. Практика ведётся с 2014 года в рамках сети «Ветров и партнёры».

21 апреля 2029 года