DNS-провайдер и ПДн

С января 2025 года Роскомнадзор включил журналы DNS-запросов в перечень данных, которые могут классифицироваться как персональные при возможности идентификации пользователя. Для CTO это означает конкретную задачу: пересмотреть архитектуру логирования, модель угроз и договоры с DNS-провайдерами. Настоящий материал разбирает правовой статус DNS-данных, обязанности по уровням защищённости УЗ-1..4, требования к облачным компонентам и специфику мультиарендных SaaS-решений.

Являются ли DNS-запросы персональными данными?

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

Для DNS-провайдера или оператора собственного DNS-резолвера это означает следующее. Если журналы запросов хранятся дольше сессии и позволяют сопоставить запрос с учётной записью или устройством пользователя — это обработка ПДн. Обработка требует правового основания по ст. 6 ФЗ-152: согласия субъекта, договора с ним или законного интереса. Отсутствие основания — состав по ч. 1 ст. 13.11 КоАП, штраф 150 000–300 000 ₽ для юрлица.

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

Как DNS-данные влияют на выбор уровня защищённости УЗ-1..4?

Уровень защищённости информационной системы ПДн определяется по матрице ПП РФ №1119 от 01.11.2012. Параметры: категория ПДн (общие, специальные, биометрические), тип угроз (1–3) и количество субъектов (порог 100 000). DNS-данные в большинстве случаев квалифицируются как иные ПДн (не специальные и не биометрические), что соответствует базовой категории.

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

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

Обязанности DNS-провайдера как обработчика ПДн по поручению

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

Оператор при этом несёт ответственность за действия обработчика перед субъектами ПДн. Это подтверждает и позиция судов: при утечке данных через подрядчика ответственность возлагается на оператора. Договор поручения не снимает обязанностей оператора — он лишь распределяет функции реализации мер.

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

Можно ли использовать иностранные облака и DNS-сервисы после 01.07.2025?

Ч. 5 ст. 18 ФЗ-152 обязывает записывать, систематизировать, накапливать, хранить, уточнять и извлекать ПДн граждан РФ исключительно в базах данных, расположенных на территории России. Это требование локализации действует с 01.09.2015; с 01.07.2025 в связи с поправками ФЗ-233 его применение ужесточено: первичная запись ПДн допускается только в российской инфраструктуре.

Для DNS-инфраструктуры это означает: если DNS-резолвер в иностранном облаке (AWS Route 53, Cloudflare, Google Cloud DNS) обрабатывает запросы российских пользователей с логированием — возможна квалификация как нарушение локализации. Штраф по ч. 8 ст. 13.11 КоАП — от 1 до 6 млн ₽; повторно — от 6 до 18 млн ₽ (ч. 9).

Практический ответ для CTO: использование зарубежного CDN или DNS-провайдера допустимо при условии, что ПДн российских пользователей не логируются на зарубежных серверах или немедленно реплицируются в российский кластер без первичного хранения за рубежом. Точную границу допустимости для конкретной архитектуры устанавливает DPIA — оценка воздействия на права субъектов.

Обезличивание DNS-данных для ML: требования и методы

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

Важно: обезличивание должно исключать возможность обратной идентификации с разумными усилиями. Псевдонимизация (замена IP на hash без соли) не равнозначна обезличиванию — при наличии исходной базы обратная идентификация тривиальна. РКН вправе проверить применённый метод на соответствие требованиям приказа. Нарушение метода обезличивания госорганом квалифицируется по ч. 7 ст. 13.11 КоАП; для коммерческих операторов риск возникает при передаче таких данных в ЕИП НСУД или партнёрам по аналитике.

Мультиарендная SaaS: кто оператор и как распределяется ответственность?

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

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

Для SaaS это означает практическую задачу: разграничить инстансы логирования по целям, задокументировать правовые основания для каждого и включить эти сведения в уведомление РКН по ст. 22 ФЗ-152. Неполное уведомление при проверке — штраф по ч. 10 ст. 13.11 КоАП, 100 000–300 000 ₽.

Типовые сценарии: что происходит при проверке или инциденте

Сценарий 1. Корпоративный DNS с LDAP-интеграцией без ОРД. CTO компании (Центральный ФО, осень 2025) выявил при внутреннем аудите, что DNS-сервер с интеграцией в Active Directory хранит полные журналы запросов сотрудников в течение 180 дней. Политика обработки ПДн не упоминала этот вид обработки; договор с вендором ПО отсутствовал. При плановой проверке РКН инспектор запросил перечень ИСПДн и правовые основания. Компания получила предписание об устранении нарушений по ч. 1 ст. 13.11 КоАП и штраф в диапазоне 150 000–300 000 ₽. После подключения юридической команды политика была дополнена, договор поручения заключён, срок хранения сокращён до 30 дней с обоснованием в модели угроз.

Сценарий 2. SaaS-платформа с DNS-логированием и иностранным облаком. В деле о нарушении локализации (Северо-Западный ФО, начало 2026) SaaS-оператор использовал Cloudflare Workers для DNS-резолвинга с логированием в европейский кластер. РКН квалифицировал это как нарушение ч. 5 ст. 18 ФЗ-152 и возбудил дело по ч. 8 ст. 13.11 КоАП (штраф для юрлица 1–6 млн ₽). Компания переориентировала первичное логирование на российский CDN-узел, направила актуализированное уведомление в РКН и в арбитраже добилась снижения штрафа, представив доказательства оперативных технических мер. Примечание: конкретный номер дела и точную сумму менеджер уточняет при публикации.

Сценарий 3. Инцидент с DNS-логами и уведомление за 24 часа. Утечка DNS-журналов у SaaS-провайдера (Сибирский ФО, весна 2025) затронула данные 12 000 пользователей (IP, история запросов). CISO зафиксировал инцидент в течение 3 часов, первичное уведомление в РКН по Приказу РКН №187 направлено через 21 час. Через 70 часов представлен отчёт о расследовании. Неуведомление в 24-часовой срок не зафиксировано; РКН в рамках расследования предъявил вопросы по составу ОРД. Оператор предоставил пакет документации, дело прекращено без штрафа по ч. 11 ст. 13.11 КоАП.

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

DNS-данные с возможностью идентификации пользователя — это ПДн, требующие оснований обработки, договора поручения с провайдером, соответствующего уровня защищённости ИСПДн и включения в уведомление РКН. Локализация после 01.07.2025 закрывает возможность первичного хранения DNS-журналов российских пользователей в зарубежных облаках без риска штрафа 1–6 млн ₽.

DATUM сопровождает IT-компании и SaaS-операторов в вопросах технической стороны 152-ФЗ: модели угроз, выбор УЗ, ОРД для инфраструктурных компонентов, договоры поручения с провайдерами, DPIA для облачных архитектур.

14 января 2029 года