аналитика 14 февраля 2029 По состоянию на 14 февраля 2029

User-Agent в логах

User-Agent в составе HTTP-логов — это персональные данные, если позволяет идентифицировать пользователя в связке с IP, сессией или cookie.

Роскомнадзор квалифицирует User-Agent как элемент составного идентификатора. Несоответствие уровню защищённости ИСПДн (УЗ-1..4 по ПП РФ №1119) и требованиям Приказа ФСТЭК №21 влечёт штраф по ч. 1 ст. 13.11 КоАП от 150 000 до 300 000 ₽ и риск включения в план проверок РКН.

→ Если вы CISO и ваши лог-хранилища не проходили оценку на предмет ПДн — читайте ниже: нормы, сценарии, меры.

С 30.05.2025 штрафная сетка по ст. 13.11 КоАП насчитывает 18 частей. Повторная утечка из логов с User-Agent-записями более 100 000 субъектов квалифицируется по ч. 14 (10–15 млн ₽) или, при повторности, — по ч. 15 (оборотный: 1–3% годовой выручки, не менее 20 млн ₽, не более 500 млн ₽). Для IT-команды это означает необходимость разобраться с тремя вопросами: является ли User-Agent ПДн в конкретной системе, какой уровень защищённости (УЗ) применяется, и что нужно сделать с логами до следующей проверки.

Является ли User-Agent персональными данными?

По ст. 3 ФЗ-152 персональные данные — любая информация, позволяющая прямо или косвенно идентифицировать физическое лицо. User-Agent сам по себе (строка браузера, ОС, версия) не идентифицирует человека. Проблема возникает при агрегации: IP-адрес + User-Agent + временная метка + cookie-идентификатор сессии образуют составной идентификатор, однозначно привязывающий запрос к конкретному субъекту.

Позиция РКН, выраженная в разъяснениях по cookie-файлам, прямо указывает: технические идентификаторы, в совокупности позволяющие выделить конкретного пользователя из группы, признаются ПДн. Аналогичная логика распространяется на HTTP-логи. Если лог-запись хранится в системе, где существует возможность связать User-Agent с зарегистрированным пользователем — запись является ПДн.

«Ст. 3 ФЗ-152: персональные данные — любая информация, относящаяся к прямо или косвенно определённому или определяемому физическому лицу (субъекту персональных данных).»

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

Ваши лог-хранилища уже попадали в фокус РКН?

Если CISO не проводил оценку HTTP-логов на предмет ПДн — риск штрафа по ч. 1 ст. 13.11 КоАП реален при ближайшей плановой или внеплановой проверке. До проверки есть время зафиксировать состав обрабатываемых данных и устранить расхождения. Юристы DATUM проведут аудит обработки ПДн по чек-листу из 38 пунктов и выдадут отчёт с приоритизированным планом устранения нарушений.

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

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

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

Уровень защищённости информационной системы персональных данных (ИСПДн) определяется по трём параметрам: категория ПДн, тип актуальных угроз и количество субъектов. Нормативная основа — ПП РФ №1119 от 01.11.2012.

Для большинства IT-систем, где логируется User-Agent авторизованных пользователей, применимы следующие варианты:

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

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

«ПП РФ №1119: уровень защищённости ИСПДн определяется по сочетанию категории ПДн, типа угроз (1–3) и порогового числа субъектов (100 000). Для каждого УЗ определён обязательный набор мер.»

Что требует Приказ ФСТЭК №21 для лог-систем?

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

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

Для SaaS с мультиарендной архитектурой критично требование изоляции данных арендаторов (ЗИС — защита информационной системы). Логи разных тенантов не должны пересекаться. Нарушение этого требования создаёт риск квалификации как несанкционированного доступа по ст. 272 УК РФ.

Что подготовить для соответствия по логированию ПДн

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

Обезличивание для ML: как убрать User-Agent из обучающих данных?

Использование логов с User-Agent для обучения ML-моделей создаёт отдельный правовой риск. Если модель обучается на реальных ПДн пользователей без обезличивания — оператор нарушает принцип ограничения цели обработки (ст. 5 ФЗ-152): данные, собранные для обеспечения работы сервиса, не могут использоваться для обучения модели без отдельного правового основания или согласия.

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

Обобщение — замена точной строки User-Agent на категорию: «мобильный браузер», «десктопный Chrome», «API-клиент». Теряется уникальность — идентификация субъекта становится невозможной.
Введение идентификаторов — замена реального User-Agent на псевдоним (хэш с солью, ротируемый по сессии). Псевдонимизация сохраняет аналитическую ценность, но разрывает связь с субъектом. Важно: соль и таблица соответствия хранятся отдельно и не передаются вместе с данными для ML.

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

Если CISO использует логи для обучения моделей без задокументированного обезличивания — это нарушение ст. 5 ФЗ-152, которое выявляется на первом же аудите РКН. Юристы DATUM проведут DPIA и зафиксируют методы обезличивания в ОРД.

Провести DPIA

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

В мультиарендной SaaS (multi-tenant) User-Agent логируется на уровне инфраструктуры провайдера и на уровне приложения каждого тенанта. Это создаёт двойственность: кто является оператором ПДн — провайдер платформы или компания-клиент?

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

Проблема: провайдер SaaS также логирует User-Agent для собственных нужд (мониторинг, безопасность, отладка). В этой части он выступает самостоятельным оператором. Следовательно, политика конфиденциальности провайдера должна раскрывать логирование технических данных как отдельную цель, а договор с клиентом — чётко разграничивать обработку «по поручению» и «в собственных целях».

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

Типичные сценарии нарушений и их последствия

Сценарий 1. Логи в зарубежном облаке без уведомления РКН. IT-команда разворачивает ELK Stack или Splunk в AWS/GCP. Логи с User-Agent авторизованных пользователей (граждан РФ) записываются, систематизируются и хранятся на серверах за рубежом. Это нарушение ч. 5 ст. 18 ФЗ-152 (требование локализации). Дополнительно — необходимо уведомление РКН о трансграничной передаче по ст. 12 ФЗ-152. При выявлении: штраф по ч. 8 ст. 13.11 КоАП от 1 до 6 млн ₽. При повторности — ч. 9, от 6 до 18 млн ₽. Стратегия: перевод лог-хранилища в российское облако или собственную инфраструктуру, документирование поручения обработки с провайдером.

Сценарий 2. ML-обучение на сырых логах без обезличивания. Data Science команда получает дамп access-логов (IP + User-Agent + путь + временная метка) для обучения рекомендательной модели. Данные обрабатываются за пределами исходной ИСПДн, передаются в аналитическую систему без документированного поручения. Нарушения: обработка ПДн в целях, не указанных в уведомлении РКН (ч. 1 ст. 13.11, штраф 150–300 тыс. ₽); отсутствие поручения обработки (ч. 1 ст. 13.11); нарушение ст. 13.1 ФЗ-152 при передаче в ЕИП НСУД по требованию Минцифры. Стратегия: обезличивание методом обобщения или введения идентификаторов перед передачей, фиксация в ОРД.

Сценарий 3. Утечка логов через уязвимость в API. Через незакрытую уязвимость (IDOR или SQLi) хакер получает доступ к лог-хранилищу с User-Agent, IP и токенами сессий. Затронуто более 10 000 субъектов. У оператора 24 часа на первичное уведомление РКН (ч. 3.1 ст. 21 ФЗ-152, Приказ РКН №187) и 72 часа на отчёт о расследовании. Неуведомление — штраф 1–3 млн ₽ по ч. 11 ст. 13.11. Сама утечка от 10 000 до 100 000 субъектов — штраф 5–10 млн ₽ по ч. 13. При повторности — ч. 15, оборотный. Уголовная ответственность по ст. 272.1 УК РФ (введена ФЗ-421 от 30.11.2024) не исключена при наличии умысла на стороне инсайдера.

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

Кейс 1. IT-компания (Северо-Западный ФО, весна 2025), оказывающая SaaS-услуги в сфере кадрового учёта, в ходе внутреннего аудита выявила, что access-логи с User-Agent, IP и идентификаторами сессий авторизованных пользователей хранятся в облаке финского провайдера. Классификация ИСПДн по ПП РФ №1119 не проводилась. CISO инициировал перевод логов на российскую облачную платформу, оформил договор-поручение с провайдером, подал уведомление о трансграничной передаче в РКН до начала проверки. По итогам плановой проверки РКН замечания по данному пункту сняты; предписание касалось только отдельных позиций ОРД.

Кейс 2. Компания в сфере EdTech (Приволжский ФО, осень 2025) передала дамп лог-файлов (более 50 000 строк с User-Agent и токенами сессий студентов) сторонней дата-команде без договора поручения и без обезличивания. РКН возбудил дело по ч. 1 ст. 13.11 КоАП. Штраф составил сумму в нижней части диапазона (150 000 ₽), поскольку нарушение было первичным и компания устранила его до вынесения постановления. Одновременно возник вопрос о соответствии УЗ-3 (более 100 000 субъектов в базе пользователей платформы), что повлекло дополнительное предписание об устранении.

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

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

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

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

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

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

По общему правилу — нельзя, если логи содержат ПДн граждан РФ. Часть 5 ст. 18 ФЗ-152 требует, чтобы запись, систематизация, накопление, хранение, уточнение и извлечение таких данных осуществлялись в базах, расположенных на территории РФ. Хранить логи за рубежом допустимо только как зеркало после первичной записи в российской системе, с надлежащим уведомлением РКН о трансграничной передаче по ст. 12 ФЗ-152.

3. Что такое обезличивание для ML и как его применить к User-Agent?

Обезличивание по ст. 13.1 ФЗ-152 — это действия, в результате которых определить принадлежность данных конкретному субъекту становится невозможным без несоразмерных усилий. Для User-Agent применяются методы обобщения (строка заменяется категорией: «Android / Chrome 124») или введения идентификаторов (хэш с ротируемой солью вместо реальной строки). После обезличивания данные допустимо передавать для ML без ограничений режима ПДн — при условии раздельного хранения таблицы соответствия.

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

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

5. Какие СЗИ обязательны при хранении User-Agent как ПДн?

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

Итог

User-Agent в логах — это персональные данные в контексте большинства IT-систем с авторизованными пользователями. Уровень защищённости ИСПДн, требования Приказа ФСТЭК №21, локализация хранилища и оформление поручения обработки — базовый минимум для CISO. Использование логов для ML без обезличивания и хранение в зарубежном облаке — два наиболее частых нарушения, выявляемых при проверках РКН.

DATUM сопровождает IT-компании при классификации ИСПДн, оценке воздействия (DPIA) и подготовке ОРД для лог-систем и SaaS-платформ с мультиарендной архитектурой.

АГ

Антон Громов

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

Аналитик DATUM по технологиям и ИБ. Специализация: УЗ-1..4 (ПП РФ №1119), Приказ ФСТЭК №21, обезличивание для ML, логирование, SaaS-архитектура, реагирование на утечки, ст. 272.1 УК.

14 февраля 2029 года