IP-адрес в логах: ПДн или нет

Вопрос о природе IP-адреса в логах не академический: от ответа зависит, нужно ли включать лог-хранилище в состав ИСПДн, применять требования Приказа ФСТЭК №21, уведомлять Роскомнадзор и определять уровень защищённости. По итогам 2024 года РКН зафиксировал более 710 млн скомпрометированных записей — значительная часть утечек проходила через незащищённые лог-системы. С 30.05.2025 штраф за утечку от 10 000 до 100 000 субъектов составляет 5–10 млн ₽ (ч. 13 ст. 13.11 КоАП), а при повторности — до 500 млн ₽ оборотного штрафа.

Когда IP-адрес признаётся персональными данными?

Статья 3 ФЗ-152 определяет ПДн как любую информацию, относящуюся прямо или косвенно к определённому или определяемому физическому лицу. Ключевое слово — «определяемому». IP-адрес сам по себе не называет имени, но в сочетании с провайдерской базой, куки-файлом, User-Agent или записью в БД пользователей он позволяет установить личность конкретного человека.

Роскомнадзор в правоприменительной практике исходит из принципа: если у оператора есть техническая возможность связать IP-адрес с конкретной учётной записью или сессией авторизованного пользователя — IP является ПДн. Это затрагивает три наиболее распространённых сценария в IT-инфраструктуре.

Сценарий 1. Авторизованные сессии. В логах Nginx или Apache строка запроса содержит IP источника рядом с session_id или JWT-токеном, который привязан к записи пользователя в БД. Связь прямая — IP-адрес идентифицирует субъекта без дополнительных усилий. Это ПДн без каких-либо оговорок.

Сценарий 2. Анонимные посетители сайта. IP динамический, провайдерской базы у оператора нет, куки отсутствуют. Здесь идентификация не является «разумно достижимой» — связь косвенная и требует ресурсов, которых у оператора нет. Позиция РКН: даже в этом случае следует исходить из более осторожной квалификации, поскольку IP-адрес может быть передан третьим лицам (CDN, аналитика), у которых средства идентификации есть.

Сценарий 3. Корпоративные пользователи. IP-адрес принадлежит организации, а не физическому лицу. Формально это не ПДн гражданина — но если за IP стоит конкретный сотрудник (DHCP-лиз привязан к рабочей станции конкретного человека), данные снова становятся персональными.

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

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

IP-адреса без привязки к специальным категориям (здоровье, биометрия, судимость) относятся к «иным» ПДн. При числе субъектов до 100 000 и угрозах 3-го типа (НДВ в системном ПО не актуальны) стандартная лог-система получит УЗ-4. Однако если в тех же логах хранятся медицинские данные (API-запросы к МИС) или биометрические идентификаторы сессий — уровень поднимается до УЗ-2 или УЗ-1.

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

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

Как обезличить IP-адреса для ML и аналитики?

Обезличивание — единственный законный способ использовать исторические логи с IP-адресами в ML-конвейерах без соблюдения полного режима ИСПДн. Согласно ст. 3 ФЗ-152, обезличенные данные перестают быть персональными при условии, что их нельзя деобезличить без несоразмерных усилий.

С 2025 года методы обезличивания регулируются подзаконным актом Роскомнадзора. Применительно к IP-адресам практически применимы три метода из пяти.

Введение идентификаторов. IP-адрес заменяется псевдонимом (UUID, хэш с солью). Исходный IP хранится в отдельной таблице с ограниченным доступом. Для ML-модели передаётся только псевдоним — связь с конкретным лицом разрывается на уровне технического процесса. Это наиболее распространённый метод для систем аналитики.

Обобщение (агрегация). Вместо конкретного IP — подсеть /24 или /16. Географическую принадлежность сохраняет, личность не раскрывает. Подходит для построения поведенческих моделей, где нужна геолокация, но не уникальный идентификатор.

Изменение состава. Усечение последнего октета IPv4 (маскирование) или первых 64 бит IPv6. Метод прост в реализации и не требует отдельного ключевого хранилища.

Важно: хэширование IP без соли не является надёжным обезличиванием — радужные таблицы для IPv4-пространства (4,2 млрд адресов) строятся за минуты. РКН при проверке оценивает реальную невозможность деобезличивания, а не наличие формального «хэша».

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

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

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

Для объектов КИИ (критической информационной инфраструктуры) по ФЗ-187 применяются дополнительные требования к хранению и обработке данных на российских мощностях. Если SaaS-платформа обслуживает субъекты КИИ, логи с IP-адресами могут подпадать под двойное регулирование — 152-ФЗ и 187-ФЗ одновременно.

Практика: как это применяется в реальных ситуациях

Кейс 1. IT-компания (Сибирский федеральный округ, осень 2025) предоставляла SaaS-платформу с мультиарендной архитектурой. Логи всех тенантов хранились в единой Elasticsearch-кластере в облаке иностранного провайдера без российского региона. После внеплановой проверки РКН по жалобе одного из клиентов компании выдано предписание об устранении нарушений ч. 5 ст. 18 ФЗ-152 и ч. 1 ст. 13.11 КоАП (нарушение условий обработки ПДн). Параллельно выявлено отсутствие договора поручения с провайдером. Арбитражный суд округа подтвердил обоснованность предписания. Штраф — в диапазоне сотен тысяч рублей. DATUM сопровождал компанию при переговорах с РКН и помог разделить лог-кластер по тенантам с выделением российского региона хранения. ⚠️ Конкретный номер дела и точная сумма — менеджер уточняет при публикации.

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

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

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

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

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

Стартовая точка — УЗ-4, если в логах только «иные» ПДн (не специальные, не биометрические), субъектов менее 100 000 и угрозы 3-го типа актуальны. При наличии у хотя бы одного тенанта медицинских или биометрических данных в тех же лог-потоках — УЗ поднимается до УЗ-2 или выше. Определение УЗ закрепляется приказом руководителя на основании модели угроз по методике ФСТЭК. Ошибка в сторону занижения — нарушение ст. 19 ФЗ-152 и Приказа ФСТЭК №21.

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

Нет, если речь идёт о первичном хранении ПДн граждан РФ. Ч. 5 ст. 18 ФЗ-152 требует, чтобы запись, систематизация, накопление, хранение, уточнение и извлечение ПДн граждан РФ осуществлялись в базах данных на территории России. Иностранное облако без российского региона — нарушение. Допустимая конфигурация: основное хранение в российском регионе (например, Yandex Cloud, VK Cloud, облако на Beget) с последующей репликацией за рубеж для глобальной CDN — но первичная запись должна быть в РФ.

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

Обезличивание по ст. 3 ФЗ-152 — это действия, после которых невозможно без дополнительной информации определить принадлежность данных конкретному субъекту. Ключевое слово — «без дополнительной информации»: ключ деобезличивания существует, но хранится отдельно и с ограниченным доступом. Анонимизация — необратимый процесс, после которого данные перестают быть ПДн полностью. Для ML практичнее обезличивание: оно позволяет при необходимости связать прогноз модели с конкретным субъектом для выполнения его прав (ст. 14–21 ФЗ-152), тогда как анонимизированные данные этого уже не допускают.

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

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

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

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

Итог

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

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