Cloudflare и российские пользователи

Cloudflare используют тысячи российских и зарубежных продуктов с российской аудиторией: как CDN, WAF, DDoS-защита, Tunnel, Workers. Во всех случаях трафик пользователей проходит через серверы в юрисдикции США. С 2024–2025 года регуляторное давление на такую архитектуру резко возросло: ФЗ-420 ввёл оборотные штрафы, ч. 5 ст. 18 ФЗ-152 стала применяться на практике, а РКН усилил мониторинг трансграничных потоков данных. В этом материале — анализ правовых рисков, технические развилки и стратегия управления соответствием для IT-команды.

Какие данные Cloudflare собирает о российских пользователях и являются ли они ПДн?

Cloudflare в базовой конфигурации видит и обрабатывает: IP-адрес клиента, HTTP-заголовки (User-Agent, Referer, Accept-Language), cookies, геолокацию по IP, TLS-fingerprint и метаданные запросов. По позиции РКН и сложившейся практике, IP-адрес в совокупности с иными данными — идентификатор физического лица, то есть персональные данные по ст. 3 ФЗ-152.

Продвинутые функции Cloudflare расширяют объём обрабатываемых ПДн. Workers и Pages получают доступ к телу запроса — а значит, к логинам, email, номерам телефонов в форм-постах. Cloudflare Access логирует идентификаторы сессий. Bot Management строит профиль поведения пользователя. Каждый из этих сценариев — отдельное основание обработки ПДн по ст. 6 ФЗ-152 с отдельными требованиями к согласию и локализации.

Таким образом, если Cloudflare является первым узлом, где данные записываются или систематизируются (например, в Workers KV, R2, Cloudflare D1), это нарушение ч. 5 ст. 18 ФЗ-152 — независимо от того, реплицируются ли данные потом в Россию. Именно первичность записи стала ключевым критерием в практике РКН после 2022 года.

Как требования УЗ-1..4 и Приказ ФСТЭК №21 применяются к архитектуре с Cloudflare?

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

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

Можно ли легально использовать Cloudflare при обработке ПДн российских пользователей?

Ответ зависит от роли Cloudflare в архитектуре и функций, которые он выполняет. Существует несколько рабочих конфигураций с разным уровнем правового риска.

Конфигурация 1 — только транзит без хранения. Cloudflare используется как транзитный прокси (режим «Full» или «Full Strict» без Workers, без KV, без R2, без D1, без Access). Данные через него проходят, но не записываются. Правовой риск — средний: формально первичной записи нет, но РКН может оспорить тезис о том, что логирование на edge-нодах не является «хранением» по ст. 3 ФЗ-152. Позиция регулятора по этому вопросу не закреплена нормативно.

Конфигурация 2 — Cloudflare как обработчик по поручению. По п. 3 ч. 1 ст. 6 ФЗ-152 оператор вправе поручить обработку ПДн третьему лицу на основании договора. Cloudflare предоставляет DPA (Data Processing Agreement) в рамках GDPR. Однако DPA по GDPR не эквивалентен поручению по ст. 6 ФЗ-152: российский закон требует, чтобы обработчик соблюдал принципы ФЗ-152 и обеспечивал конфиденциальность. При этом Cloudflare — американская компания, подпадающая под Cloud Act, что означает потенциальный доступ властей США к данным. РКН при проверке это учтёт.

Конфигурация 3 — Workers с хранением данных. Cloudflare Workers + KV/R2/D1 фактически создают базу данных за пределами РФ. Это прямое нарушение ч. 5 ст. 18 ФЗ-152 с риском штрафа 1–6 млн ₽ по ч. 8 ст. 13.11 КоАП при первом выявлении и 6–18 млн ₽ при повторном (ч. 9).

Что такое обезличивание для ML и как оно снижает риски при использовании Cloudflare?

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

С 2025 года методы обезличивания закреплены нормативно. Действует пять методов: введение идентификаторов (псевдонимизация), изменение состава или семантики, декомпозиция набора данных, перемешивание записей, обобщение и агрегация. Для ML-задач наиболее применимы псевдонимизация (замена прямых идентификаторов суррогатными ключами) и агрегация (передача статистических срезов вместо индивидуальных записей).

Практический алгоритм для SaaS с Cloudflare Workers: события аналитики (клики, сессии, воронки) формируются в российской базе, где идентификаторы пользователей заменяются суррогатными ключами по методу введения идентификаторов. Только обезличенные события передаются в Workers для агрегации и ML-инференса. Исходная таблица соответствия хранится исключительно в российской ИСПДн. При такой архитектуре данные в Cloudflare формально не являются ПДн и не подпадают под ч. 5 ст. 18 ФЗ-152.

Типовые сценарии: как ошибки в архитектуре превращаются в протоколы РКН

Сценарий 1. SaaS-продукт с Cloudflare Access и Workers KV. Компания (Уральский ФО, весна 2025) использовала Cloudflare Access для SSO сотрудников и клиентов. Логи сессий — email, IP, метки времени — хранились в Cloudflare Audit Log (за пределами РФ). Workers KV использовался для кеширования пользовательских профилей. На плановой проверке РКН установил, что первичная запись email и идентификаторов сессий происходит на американских серверах Cloudflare. Возбуждено дело по ч. 8 ст. 13.11 КоАП. Штраф — в диапазоне нескольких миллионов рублей. Компании потребовалась срочная миграция на российский IdP и отключение KV.

Сценарий 2. Утечка через скомпрометированный Workers-скрипт. E-commerce платформа (Центральный ФО, лето 2025) хранила корзины и контакты пользователей в Cloudflare D1. Уязвимость в Workers-скрипте позволила получить доступ к данным около 15 000 пользователей. Оператор не уведомил РКН в течение 24 часов по ч. 3.1 ст. 21 ФЗ-152 — уведомление было направлено на пятый день. В результате предъявлены требования сразу по трём составам: ч. 8 (локализация), ч. 11 (нарушение срока уведомления, 1–3 млн ₽) и ч. 13 (утечка 10 000–100 000 субъектов, 5–10 млн ₽). Совокупная нагрузка — в десятки миллионов рублей.

Сценарий 3. Корректная архитектура: Cloudflare как транзитный WAF. IT-компания (Северо-Западный ФО, осень 2024) провела аудит до запуска. Cloudflare настроен в режиме транзитного WAF без хранения данных: Workers отключены, KV/R2/D1 не используются, Cloudflare Logs не активированы, Cloudflare Access заменён на российский IdP. DPA подписан, в уведомлении РКН указана трансграничная передача (транзит) с описанием мер защиты. За два года проверок замечаний по данному направлению не поступало.

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

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

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

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

По ч. 5 ст. 18 ФЗ-152 первичная запись ПДн граждан РФ должна происходить в базах на территории России. Хранение в иностранном облаке (AWS, GCP, Azure, Cloudflare R2) является нарушением даже при последующей репликации в РФ. Исключение — обезличенные данные: они не подпадают под требование локализации. Для необезличенных данных единственный легальный вариант — российский облачный провайдер или собственная инфраструктура в РФ.

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

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

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

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

5. Какие СЗИ обязательны при УЗ-3 и можно ли использовать несертифицированные зарубежные решения?

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

Итог

Cloudflare в стандартной конфигурации создаёт три самостоятельных правовых риска для оператора с российской аудиторией: нарушение локализации по ч. 5 ст. 18 ФЗ-152, несоответствие требованиям уровня защищённости по ПП РФ №1119 и Приказу ФСТЭК №21, а при активации Workers с хранилищами — прямое основание для штрафа 1–18 млн ₽ по ч. 8–9 ст. 13.11 КоАП. Снизить риски можно архитектурно: транзитный режим без хранения, обезличивание перед передачей в edge, российский IdP вместо Cloudflare Access.

Юристы и технические эксперты DATUM сопровождают IT-команды от расчёта УЗ и построения модели угроз до оценки воздействия (DPIA) и подготовки ОРД под конкретную архитектуру — включая гибридные схемы с зарубежными CDN и облаками.

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

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

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