CDN и ПДн пользователей

CDN появился в архитектуре большинства российских продуктов как инструмент ускорения раздачи контента. Но с тех пор как Роскомнадзор закрепил позицию, что IP-адрес — персональные данные, а ФЗ-420 от 30.11.2024 поднял штрафные санкции до уровня, при котором однократная крупная утечка способна перекрыть годовую EBITDA, вопрос «как CDN взаимодействует с ПДн» перестал быть абстрактным. Эта статья разбирает три блока: какие именно данные CDN обрабатывает, как это соотносится с требованиями ФЗ-152 и Приказа ФСТЭК №21, и что должен сделать технический директор, чтобы использование CDN не создавало правовых рисков.

Какие данные CDN обрабатывает и почему это персональные данные?

CDN фиксирует минимум три категории данных при каждом запросе. Первая — сетевые идентификаторы: IP-адрес клиента, порт источника, геолокация по IP. Вторая — заголовки HTTP: User-Agent, Referer, Accept-Language, куки (Cookie-заголовок), токены авторизации в URL. Третья — метаданные сессии: время обращения, длительность соединения, объём переданных данных, идентификатор ноды PoP.

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

Важно понимать: CDN не просто проксирует трафик. Он хранит логи запросов (как правило, от 7 до 30 суток по умолчанию), кэширует ответы (в которых могут быть персонализированные фрагменты страниц), терминирует TLS-соединение (то есть видит расшифрованный контент до повторного шифрования). Всё это — обработка персональных данных по ст. 3 ФЗ-152: сбор, хранение, систематизация, извлечение.

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

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

Уровень защищённости (УЗ) определяется по ПП РФ №1119 от 01.11.2012. Матрица строится из трёх параметров: категория обрабатываемых ПДн (общие, специальные, биометрические), тип актуальных угроз (1, 2, 3) и число субъектов (порог 100 000). CDN влияет на эту матрицу сразу в двух измерениях.

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

Второе: тип актуальной угрозы зависит от наличия недекларированных возможностей в программном обеспечении, используемом при обработке. Мультиарендный CDN — это угрозы типа 2 (недекларированные возможности в прикладном ПО) как минимум. Если у провайдера нет сертифицированного ПО по требованиям ФСТЭК — оператор должен самостоятельно нейтрализовать этот тип угрозы организационными мерами или использовать наложенные средства защиты информации.

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

Что требует Приказ ФСТЭК №21 применительно к CDN-инфраструктуре?

Приказ ФСТЭК №21 формализует 109 мер защиты в 15 группах. Применительно к CDN критически важны четыре группы.

РСБ — регистрация событий безопасности. Оператор обязан обеспечить сбор и хранение логов о доступе к ПДн. CDN-провайдер генерирует access-логи, но их формат, срок хранения и порядок передачи оператору по умолчанию не соответствуют требованиям РСБ. В договоре поручения необходимо зафиксировать: какие события фиксируются, в каком формате, на каком сроке хранятся, как передаются оператору при запросе РКН или в рамках расследования инцидента по Приказу РКН №187.

ЗИС — защита информационной (автоматизированной) системы и её компонентов. Для УЗ-2 и выше обязательны меры по защите каналов передачи данных. TLS-терминация на CDN-ноде означает, что данные на участке между нодой и origin-сервером передаются в расшифрованном виде внутри инфраструктуры провайдера. Это допустимо только если провайдер выполняет требования ЗИС и это подтверждено договором поручения или актом оценки соответствия.

УПД — управление правами доступа. Инженеры CDN-провайдера имеют административный доступ к инфраструктуре, через которую проходят ПДн. Ст. 18.1 ФЗ-152 требует определить круг лиц, получающих доступ к ПДн. Поимённый перечень сотрудников провайдера, обеспечивающих обслуживание, — необходимый элемент договора поручения для соответствия УПД.

АНЗ — анализ защищённости. Для УЗ-2 обязательна периодическая оценка уязвимостей. Если CDN-провайдер не проходит независимый аудит безопасности и не предоставляет отчёты оператору — оператор должен компенсировать этот риск собственными инструментами: WAF, сканеры уязвимостей на уровне origin, мониторинг аномалий в трафике.

Иностранный CDN и локализация: что изменилось с 01.07.2025?

Норма ч. 5 ст. 18 ФЗ-152 обязывает оператора при сборе, систематизации, накоплении, хранении, уточнении и извлечении ПДн граждан России использовать базы данных, расположенные в Российской Федерации. Формально это требование действует с 01.09.2015, но с 01.07.2025 (ФЗ-233 от 08.08.2024) контроль ужесточился: РКН получил дополнительные полномочия по внеплановым проверкам именно в части локализации.

Для CDN это создаёт следующую коллизию. Если иностранный CDN-провайдер хранит логи запросов российских пользователей на серверах за пределами России — это нарушение требования локализации. Штраф по ч. 8 ст. 13.11 КоАП — 1 000 000–6 000 000 ₽. При повторном нарушении — ч. 9, 6 000 000–18 000 000 ₽.

При этом сам факт прохождения трафика через иностранные ноды CDN — не нарушение локализации. Нарушение возникает, когда ПДн российских пользователей записываются, систематизируются или хранятся в базе данных вне России. Граница проходит по тому, где физически хранятся логи и кэшированные ответы с персонализированным содержимым.

Практическое решение для иностранного CDN: настроить географическую сегрегацию хранения логов (GeoLog Routing) — логи с российских IP-адресов должны писаться только в российские PoP или передаваться в origin в России без сохранения на иностранных нодах. Если провайдер не поддерживает такую конфигурацию технически — использование его услуг для российской аудитории создаёт неустранимый правовой риск по ч. 8 ст. 13.11.

Трансграничная передача ПДн (ст. 12 ФЗ-152) возникает как отдельный вопрос, если логи всё же записываются за рубежом. До передачи в страну без адекватного уровня защиты оператор обязан уведомить РКН. Перечень стран с адекватной защитой утверждён отдельным актом РКН; США, большинство азиатских юрисдикций в этот перечень не входят.

Обезличивание для ML и CDN: как данные из логов не стать нарушителем?

Многие продуктовые команды используют CDN-логи как источник для обучения ML-моделей: анализ поведения пользователей, детектирование аномалий, персонализация. С 2025 года это регулируется отдельно: ст. 13.1 ФЗ-152 (введена ФЗ-233) ввела требования к обезличиванию, Роскомнадзор утвердил пять методов обезличивания — введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение и агрегация.

Применительно к CDN-логам: «сырой» лог с IP-адресом, временной меткой и User-Agent — это ПДн. Замена IP на хэш без соли — псевдонимизация, а не обезличивание: хэш обратим при наличии исходной таблицы. Для соответствия методу введения идентификаторов необходима замена IP на идентификатор, не позволяющий восстановить исходное значение даже при наличии вспомогательной информации в распоряжении оператора.

Обобщение по методу агрегации: вместо лога «IP x.x.x.x обратился к /api/user/123 в 14:35:22» — «в период 14:00–15:00 к /api/user/* обратилось N запросов из диапазона /24». Такой агрегированный лог при правильной реализации перестаёт быть ПДн и может использоваться для обучения моделей без ограничений по ФЗ-152.

Важный нюанс для SaaS с мультиарендностью: если CDN-логи содержат идентификаторы клиентов-арендаторов (tenant_id) и под каждым — физические лица, комбинация «tenant + user_action + timestamp» может быть персональными данными даже без IP. Модель угроз должна это учитывать.

Типовые сценарии: CDN и правовые риски CTO

Сценарий 1. SaaS-платформа на иностранном CDN с дефолтными настройками логирования. Ситуация: CDN-провайдер хранит access-логи 30 суток на серверах в ЕС. Договор поручения не заключён. Аудитория — 150 000 российских пользователей. Доказательства нарушения: скриншот панели управления CDN с указанием региона хранения, выгрузка образца лога с IP российских пользователей. Вероятный исход: нарушение ч. 5 ст. 18 ФЗ-152 (локализация) → ч. 8 ст. 13.11 КоАП, штраф 1–6 млн ₽; дополнительно — ч. 1 ст. 13.11 за отсутствие договора поручения, 150–300 тыс. ₽. Стратегия: переключить регион хранения логов на российские ноды или перейти к российскому CDN; заключить DPA с провайдером в течение 30 дней.

Сценарий 2. Мультиарендный SaaS: кто оператор, кто обработчик? Ситуация: B2B SaaS-платформа предоставляет инструмент корпоративным клиентам, которые собирают ПДн своих пользователей. CDN стоит перед приложением. Корпоративный клиент настаивает, что SaaS-вендор — обработчик, а не оператор. Доказательная база: договор между вендором и корпоративным клиентом; технические условия — кто определяет цели и способы обработки. Вероятный исход: если вендор самостоятельно определяет технические параметры обработки (в том числе настройки CDN) — он сооператор по ст. 3 ФЗ-152, несёт солидарную ответственность. Стратегия: зафиксировать в договоре с корпоративным клиентом статус каждой стороны; разработать DPA с клиентом и сублицензионный договор поручения с CDN-провайдером по цепочке.

Сценарий 3. Инцидент через CDN: утечка логов провайдера. Ситуация: иностранный CDN-провайдер сообщил об инциденте — несанкционированный доступ к access-логам. Затронуто 25 000 уникальных российских пользователей по IP и User-Agent. Оператор узнал через 6 часов после объявления провайдером. Вероятный исход: 24-часовой срок уведомления РКН по ч. 3.1 ст. 21 ФЗ-152 начинает течь с момента, когда оператор узнал об инциденте. Если в течение 24 часов уведомление не направлено — ч. 11 ст. 13.11 КоАП, штраф 1–3 млн ₽. Утечка 25 000 субъектов — ч. 13 ст. 13.11, 5–10 млн ₽. Стратегия: регламент реагирования на инциденты должен включать автоматический триггер при получении уведомления от CDN-провайдера; дежурный CISO/CTO обязан получить уведомление немедленно, а не через тикет-систему.

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

Кейс 1. IT-компания (Центральный ФО, осень 2025) — SaaS-продукт для управления командами, аудитория около 80 000 российских пользователей. CDN-провайдер — европейский, логи хранились на серверах в Германии. Договора поручения не было. При плановой проверке РКН инспектор запросил документацию по технической инфраструктуре. Компания получила предписание об устранении нарушений и административный протокол по ч. 1 и ч. 8 ст. 13.11 КоАП. Суммарный штраф составил сотни тысяч рублей. После привлечения юристов и переноса хранения логов в российский регион повторных нарушений не выявлено. Примечание: конкретный номер дела и точная сумма — менеджер уточняет при публикации.

Кейс 2. Финтех-платформа (Северо-Западный ФО, начало 2026) — мобильное приложение с CDN для доставки статики, аудитория свыше 200 000 пользователей. Технический директор инициировал DPIA (оценку воздействия) до масштабирования. Аудит выявил: CDN-провайдер хранил персонализированные кэш-ответы с фрагментами профилей пользователей. Уровень защищённости был неверно определён как УЗ-3 вместо УЗ-2. После переконфигурации CDN (отключение кэширования авторизованных ответов, локализация логов), заключения DPA и доработки ОРД компания прошла последующую проверку РКН без замечаний.

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

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

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

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

Уровень защищённости определяется по матрице ПП РФ №1119: категория ПДн × тип актуальных угроз × число субъектов. Для SaaS с аудиторией более 100 000 пользователей и мультиарендным CDN типовая комбинация — общие категории ПДн + угрозы типа 2 = УЗ-2. Если обрабатываются специальные категории (состояние здоровья, финансовые данные при определённых условиях) — может потребоваться УЗ-1. Ключевой параметр, который влияет на вывод, — правильно составленная модель угроз с учётом CDN как элемента ИСПДн. Модель угроз стоит разработать до выбора набора мер, а не после.

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

Использование иностранного CDN не запрещено само по себе. Запрещено хранение ПДн российских граждан в базах данных вне РФ (ч. 5 ст. 18 ФЗ-152). Если провайдер технически обеспечивает хранение логов только в российском регионе и отсутствуют иные элементы обработки за рубежом — формальных нарушений нет. Проблема большинства иностранных CDN — дефолтная конфигурация хранит логи в ближайшем датацентре, который для российского трафика нередко оказывается в Финляндии, Германии или Нидерландах. Конфигурация требует явного действия CTO, а не доверия умолчаниям.

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

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

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

Вопрос решается через анализ того, кто определяет цели и способы обработки (ст. 3 ФЗ-152). Если SaaS-вендор самостоятельно выбирает CDN-провайдера, настраивает логирование и определяет технические параметры обработки — он оператор или сооператор, даже если по договору с корпоративным клиентом позиционирует себя как обработчик. Для корректного разграничения необходим трёхсторонний документ: договор между вендором и корпоративным клиентом с разграничением ролей + субдоговор поручения с CDN-провайдером. Ответственность перед субъектами ПДн при отсутствии надлежащей цепочки документов несёт тот, у кого есть фактический контроль над инфраструктурой.

5. Какие СЗИ обязательны для ИСПДн с CDN при УЗ-2?

Приказ ФСТЭК №21 для УЗ-2 требует реализации базового набора мер. Применительно к CDN: регистрация событий безопасности (РСБ) — обязательно, CDN-провайдер должен предоставлять структурированные логи доступа; защита от несанкционированного доступа к каналам передачи (ЗИС) — TLS 1.2+ обязателен на всех участках, включая CDN-to-origin; обнаружение вторжений (СОВ) — WAF перед origin или встроенный в CDN, с возможностью анализа событий оператором; антивирусная защита (АВЗ) — на уровне origin-серверов, поскольку CDN не является самостоятельным объектом сертификации. Применение несертифицированных СЗИ при УЗ-2 допустимо в части мер, не требующих сертификации, — конкретный перечень определяется моделью угроз.

Итог

CDN-инфраструктура — полноправный элемент ИСПДн, а не нейтральный транзитный канал. Логи с IP-адресами, заголовки HTTP и идентификаторы сессий — ПДн по ст. 3 ФЗ-152; их передача CDN-провайдеру без договора поручения — нарушение ст. 6; их хранение на иностранных серверах — нарушение ч. 5 ст. 18 с штрафом до 6 млн ₽ по ч. 8 ст. 13.11 КоАП. Правовая чистота конфигурации CDN требует трёх элементов: правильно определённого УЗ с учётом CDN в периметре ИСПДн, договора поручения с провайдером, регламента управления логами.

Практика DATUM включает аудит CDN-конфигураций в рамках полного аудита соответствия 152-ФЗ, разработку DPIA для облачных и CDN-сценариев, формирование договорной цепочки «оператор — CDN-провайдер» в соответствии с требованиями Роскомнадзора.