Логи DNS-запросов

Логирование DNS-запросов — стандартная практика для мониторинга сети, отладки, обнаружения угроз и расследования инцидентов. Однако с 30.05.2025 правовая цена ошибки в этой области резко выросла: ст. 13.11 КоАП расширена до 18 частей (ФЗ-420 от 30.11.2024), оборотный штраф достигает 500 млн ₽. В этом материале разбираем, когда DNS-лог становится персональными данными, какой уровень защищённости применить, как обезличивать данные для ML-анализа и что проверить в контексте KII по 187-ФЗ.

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

Персональные данные по ст. 3 ФЗ-152 — любая информация, относящаяся к прямо или косвенно определённому физическому лицу. DNS-лог в типовом виде содержит: IP-адрес клиента, запрошенное доменное имя, временную метку, тип записи. Сам по себе IP-адрес в корпоративной сети чаще всего привязан к конкретному устройству, а то устройство — к конкретному сотруднику. Это достаточно для признания записи персональными данными.

Позиция Роскомнадзора в части IP-адресов устойчива: динамический IP в сочетании с временной меткой и идентификатором провайдера позволяет идентифицировать абонента. В корпоративной среде ситуация проще — DHCP-таблица или Active Directory однозначно связывают IP с пользователем. Следовательно, DNS-логи корпоративной инфраструктуры — это персональные данные работников.

В SaaS-среде с мультиарендностью ситуация сложнее. DNS-запросы с IP-адресов арендаторов могут содержать данные как самих арендаторов-юрлиц, так и конечных пользователей их систем. Оператором в отношении данных конечных пользователей выступает арендатор; SaaS-провайдер, обрабатывающий эти логи, занимает позицию лица, осуществляющего обработку по поручению (п. 3 ст. 6 ФЗ-152). Без договора поручения обработки фиксация и хранение DNS-логов конечных пользователей является нарушением.

Какой уровень защищённости применить к системе DNS-логирования?

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

• УЗ-4 — общие ПДн, угрозы 3-го типа (НДВ в прикладном ПО не актуальны), субъектов менее 100 000. Типовой случай для корпоративных DNS-логов среднего предприятия.
• УЗ-3 — общие ПДн, угрозы 2-го типа (НДВ в системном ПО), или общие ПДн более 100 000 субъектов. Применимо к крупным корпоративным сетям и операторам связи.
• УЗ-2 — специальные или биометрические ПДн плюс угрозы 2-го типа, либо общие ПДн при угрозах 1-го типа. Для DNS-логов — редкий случай, если лог связан с системой биометрической аутентификации.
• УЗ-1 — специальные или биометрические ПДн при угрозах 1-го типа (НДВ в системном ПО актуальны). Критическая инфраструктура, государственные информационные системы.

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

Как обезличить DNS-логи для ML-анализа?

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

Пять методов обезличивания, применимые к DNS-логам:

• Введение идентификаторов — замена IP-адреса псевдонимом (hash-значением или последовательным ID). При необходимости деанонимизация возможна через отдельно хранимый ключ. Это наиболее распространённый метод для систем мониторинга безопасности.
• Изменение состава и семантики — удаление части октетов IP (например, обнуление последнего) или усечение доменного имени до второго уровня. Снижает точность, но сохраняет сигнал об активности.
• Декомпозиция — разделение лога на несколько таблиц, каждая из которых по отдельности не позволяет идентифицировать субъекта. IP-адрес, временная метка и доменное имя хранятся раздельно.
• Перемешивание — замена реальных значений произвольными из того же домена (например, подмена IP-адреса случайным из RFC 1918). Применяется для тестовых наборов данных.
• Обобщение и агрегация — замена точных временных меток временными интервалами, агрегирование запросов по подсетям. Подходит для обучения статистических ML-моделей.

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

Как DNS-логи связаны с КИИ и 187-ФЗ?

Федеральный закон № 187-ФЗ «О безопасности критической информационной инфраструктуры» обязывает субъектов КИИ обеспечивать защиту значимых объектов, реагировать на компьютерные инциденты и взаимодействовать с ГосСОПКА. DNS-логи в системах субъектов КИИ — это не просто ПДн, но и источник данных об инцидентах, которые подлежат направлению в НКЦКИ.

Пересечение требований 187-ФЗ и 152-ФЗ создаёт двойную нагрузку: DNS-логи одновременно являются источником сведений об инцидентах для ГосСОПКА и персональными данными работников, которые надо защищать по ПП РФ № 1119. На практике это означает, что передача DNS-логов в ГосСОПКА или SOC-партнёру без договора поручения обработки создаёт нарушение ст. 6 ФЗ-152, даже если эта передача технически обоснована требованиями 187-ФЗ.

Субъекты КИИ должны проверить, включены ли DNS-системы в перечень объектов КИИ, и при необходимости провести категорирование по Приказу ФСТЭК № 236. Требования к защите значимых объектов КИИ (Приказ ФСТЭК № 239) накладываются поверх требований ПП РФ № 1119 и, как правило, более строгие.

Облако, мультиарендность и поручение обработки: кто оператор DNS-логов?

В архитектуре SaaS с мультиарендностью вопрос о том, кто является оператором DNS-логов, решается через анализ фактических полномочий и целей обработки. Типичная схема: арендатор (B2B-клиент) использует SaaS-платформу для своих сотрудников и клиентов. DNS-запросы конечных пользователей проходят через инфраструктуру SaaS-провайдера.

• Если SaaS-провайдер фиксирует DNS-логи для обеспечения функциональности сервиса (диагностика, SLA-мониторинг) в интересах арендатора — он является лицом, осуществляющим обработку по поручению (ст. 6 ФЗ-152).
• Если SaaS-провайдер использует DNS-логи для собственных целей (аналитика, обучение ML-моделей, продажа агрегированных данных) — он самостоятельный оператор, обязанный иметь собственное правовое основание обработки.
• Если DNS-логи арендаторов смешиваются в единой SIEM-системе без разграничения по арендаторам — это нарушение принципа недопустимости объединения баз ПДн с несовместимыми целями (ст. 5 ФЗ-152).

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

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

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

Кейс 2. SaaS-провайдер (Центральный ФО, начало 2026) обнаружил, что DNS-логи арендаторов хранятся в общей базе без разграничения и используются для обучения ML-модели классификации трафика. Правовое основание для такой обработки отсутствовало. После юридического анализа введено обезличивание методом введения идентификаторов, данные разграничены по арендаторам, с каждым арендатором заключено дополнительное соглашение к договору об условиях поручения обработки. Уведомление РКН актуализировано по ст. 22 ФЗ-152. Нарушение устранено до получения предписания регулятора.

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

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

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

1. Какой УЗ выбрать для SaaS-платформы, обрабатывающей DNS-логи?

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

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

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

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

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

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

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

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

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

Итог

DNS-логи в корпоративной и SaaS-среде — персональные данные по умолчанию, если IP-адрес или совокупность полей позволяют идентифицировать физическое лицо. Требования к их защите определяются ПП РФ № 1119 (уровень УЗ-3 или УЗ-4) и Приказом ФСТЭК № 21. Обработка в иностранном облаке нарушает ч. 5 ст. 18 ФЗ-152 и влечёт штраф 1–6 млн ₽ по ч. 8 ст. 13.11 КоАП. Обезличивание методом введения идентификаторов позволяет использовать DNS-логи для ML-аналитики без утраты сигнала при соблюдении требований ст. 13.1 ФЗ-152.

Аналитики DATUM сопровождают IT-команды при классификации ИСПДн, подборе мер ФСТЭК, оценке воздействия для облачных переносов и разработке договоров поручения обработки для SaaS-архитектур с мультиарендностью.