CDN и география: как случайно не увезти данные пользователей

MAATRIX

«У нас сервер в России, с локализацией всё в порядке» — частая фраза, которая перестаёт быть точной в тот момент, когда перед сервером появляется CDN. Сеть доставки контента физически состоит из десятков и сотен узлов по всему миру, и если вы не выбирали её узлы вручную, часть запросов ваших пользователей вполне может обрабатываться на сервере в другой стране — вместе с их IP-адресом, куками сессии и иногда содержимым персонализированных страниц. Разберём, как это происходит технически и что с этим делать, не отказываясь от CDN совсем.

Почему сервер в РФ не значит, что дальше него данные никуда не уходят

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

CDN здесь — самый частый и самый незаметный случай: подключают его обычно ради скорости и защиты от DDoS, а не ради архитектуры хранения данных, и про него легко забыть, когда речь заходит о том, «где у нас лежат персональные данные». Формально база как была в РФ, так и осталась. Но запрос — включая заголовки, куки, иногда содержимое персонализированного ответа — может пройти через edge-узел CDN в другой юрисдикции, и на этом узле неизбежно что-то осядет: как минимум запись в логе доступа.

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

Как устроен CDN изнутри: origin, edge-узлы, кеш

У CDN есть origin — ваш настоящий сервер, где живёт приложение и база, — и сеть edge-узлов (PoP, points of presence), разбросанных географически. Когда пользователь обращается к домену, DNS CDN направляет его не на origin напрямую, а на ближайший по сетевой метрике провайдера edge-узел.

Дальше два сценария. Кеш-хит: если на edge уже есть закешированная копия ответа (статика, а иногда и целые HTML-страницы), узел отдаёт её сам, вообще не обращаясь к origin — сервер в РФ в обработке запроса не участвует, весь ответ уходит с узла, который может стоять где угодно. Кеш-промах: узел запрашивает origin, получает ответ, при необходимости кеширует его (если разрешено заголовками) и передаёт пользователю — origin в РФ отработал, но edge всё равно временно держал трафик в памяти и, как правило, залогировал его: IP пользователя и иногда заголовки с идентифицирующей информацией.

Подробнее про эту механику — отдельный разбор «Что такое CDN изнутри: где на самом деле лежит ваша картинка». Вывод здесь один: даже когда origin физически в РФ, edge-узел CDN — самостоятельная точка обработки запроса, а не прозрачный провод. Он видит трафик, что-то с ним делает (маршрутизация, TLS-терминация, иногда WAF) и обычно что-то из этого записывает.

Что именно может утечь через edge-узел, помимо самого контента

Здесь два разных риска, и лечатся они по-разному.

Риск первый: персонализированный контент попадает в общий кеш. Классический и самый опасный сценарий — когда CDN кеширует не статику, а целиком HTML-страницу личного кабинета, которая должна быть уникальной для каждого пользователя, и по ошибке (неверные заголовки Cache-Control или отсутствующий Vary) отдаёт её следующему посетителю, запросившему тот же URL. Персональные данные одного пользователя физически оказываются в памяти edge-узла и могут быть показаны другому — это уже не вопрос географии, а прямая утечка. Разбор одного такого инцидента — в материале «CDN закешировал страницу вместе с чужой сессией», там же показано, какие заголовки закрыли проблему.

Риск второй: метаданные запроса оседают в логах CDN. Даже если ответ не персонализирован и кешируется штатно (картинка товара, JS-бандл), запрос к нему всё равно содержит IP пользователя, User-Agent, иногда referrer с параметрами, а если CDN проксирует и API-запросы (что случается сплошь и рядом, когда он подключён «на весь домен», а не только под статику) — то и куки сессии, и заголовки авторизации. Эти данные оседают в access-логах на стороне CDN не потому, что провайдер что-то делает специально с персональными данными, а потому что логирование запросов на edge — стандартная часть эксплуатации: без логов невозможны ни биллинг по трафику, ни диагностика, ни защита от abuse.

IP-адрес сам по себе — предмет споров, считать ли его персональными данными в конкретном контексте, но в связке с логами конкретных URL (например, /user/12345/profile) вопрос становится куда менее спорным. И если эти логи физически хранятся на серверах CDN за пределами России — формально это уже обработка данных, связанных с личностью пользователя, за пределами страны, даже если origin от начала до конца оставался в РФ.

На что смотреть при выборе CDN: география узлов и логи

При выборе или аудите CDN важны не только скорость и цена, но и два инфраструктурных параметра, которые обычно не в фокусе при первом знакомстве с продуктом.

География edge-узлов, реально обслуживающих вашу аудиторию. У глобального CDN десятки точек присутствия, но для трафика из России и СНГ используется обычно небольшое подмножество — ближайшие по маршрутизации узлы, не обязательно физически в РФ или даже в дружественной юрисдикции. Стоит узнать у провайдера, через какие именно точки присутствия обычно идёт трафик из региона аудитории, а не полагаться на общий список городов из маркетинговых материалов.

Где физически хранятся логи запросов на стороне CDN и как долго. Это отдельный вопрос от того, где стоят обслуживающие трафик edge-узлы: провайдер может кешировать контент близко к пользователю, а логи со всех узлов свозить централизованно в один регион, который не совпадает ни с локацией edge, ни с локацией origin. У серьёзных провайдеров это описано в документации по обработке данных или уточняется в поддержке: где хранятся логи, какие поля туда попадают (полный IP или маскированный, есть ли заголовки авторизации), срок хранения и кто имеет доступ.

Параметры, которые стоит проверить перед подключением CDN, если через него пойдёт трафик с персональными данными:

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

Разделение персонализированного и статического контента как базовая мера

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

Технически это разделение трафика на уровне маршрутизации:

• Статика (картинки, CSS, JS, шрифты, публичный контент без персонализации) — идёт через CDN как есть, кешируется на edge: это и есть сценарий, ради которого CDN подключают, и он не требует передачи персональных данных, потому что контент одинаков для всех.
• Персонализированные страницы и API (личный кабинет, оформление заказа, авторизация, эндпоинты с куками сессии) — либо не проходят через CDN вообще (домен API исключён из проксирования на уровне DNS), либо проходят с явным запретом кеширования (Cache-Control: private, no-store и корректный Vary), при этом само прохождение через edge для TLS-терминации и защиты от DDoS может остаться — но логирование трафика на edge никуда не девается.

Практичный выход — не «убрать CDN совсем», а сузить его периметр до статики, а всё, что связано с персональными данными, направить напрямую на origin в РФ или через отдельный маршрут с явным контролем узлов. Про антипаттерн, когда персонализированные страницы кешируются целиком без такого разделения, — в материале «Антипаттерн: кешировать персональные страницы целиком», там же показано, как это тестировать до продакшена, а не после инцидента.

Отдельно стоит проверить, не проксирует ли CDN «по умолчанию» весь домен, включая /api/* и /account/* — частая ситуация, когда CDN подключали давно ради ускорения главной страницы и статики, а личный кабинет и API появились позже и унаследовали проксирование автоматически, просто оказавшись на том же домене.

Альтернативы: CDN с присутствием в РФ и локальное кеширование

Если задача — не отказаться от преимуществ CDN (устойчивость к нагрузке, защита от DDoS, скорость для распределённой аудитории), а именно не выводить обработку персональных данных за пределы нужной юрисдикции, есть несколько практических направлений.

CDN с точками присутствия и хранением логов в РФ. На рынке есть провайдеры, ориентированные конкретно на российский рынок, у которых edge-узлы и инфраструктура логирования физически расположены в России. Это снимает вопрос географии обработки для трафика через такой CDN — но проверять стоит оба параметра из таблицы выше, а не полагаться на факт «российский CDN» как готовый ответ: часть инфраструктуры у отдельных провайдеров может быть распределена шире, чем кажется по названию бренда. Мы намеренно не называем здесь конкретных провайдеров — рынок быстро меняется, и на конец августа 2026 года список игроков стоит уточнять напрямую у каждого кандидата.

Собственный кеширующий узел вместо коммерческого CDN. Если аудитория сконцентрирована в одном регионе, аргумент «нужен CDN ради глобальной скорости» часто не работает — ближе к делу может быть один дополнительный сервер с reverse-proxy кешем (nginx, Varnish) в том же дата-центре, что и origin. Весь стек тогда физически остаётся в контролируемой юрисдикции, а задержка для целевой аудитории и так минимальна без глобальной сети edge-узлов. Экономику такой замены разбирали в материале «Свой кеширующий узел вместо коммерческого CDN».

Гибрид: глобальный CDN для международной аудитории, локальный маршрут для аудитории из РФ. Рабочая схема — маршрутизация на уровне DNS или балансировщика: пользователи из РФ обслуживаются напрямую origin-сервером без прохождения через глобальный CDN, для остальной аудитории CDN подключён как обычно. Это требует чуть более сложной настройки (GeoDNS или geo-routing на балансировщике), но снимает компромисс «либо теряем скорость для одних, либо рискуем данными других».

Ни один из вариантов не бесплатен: свой узел кеширования — это сервер на обслуживании без защиты от DDoS уровня крупных CDN-сетей, локальный CDN может уступать в зрелости инструментов, а geo-routing добавляет сложности. Выбор — компромисс между удобством, устойчивостью к нагрузке и контролем над географией данных.

Практическая проверка: как понять, где сейчас летают ваши данные

Прежде чем менять архитектуру, полезно посмотреть, что происходит прямо сейчас — часто оказывается, что риска либо нет вовсе, либо он куда шире, чем предполагалось.

1. Проверить, какие пути реально проксируются через CDN. В панели CDN или в конфигурации DNS посмотреть текущие правила: весь домен под CDN или только выбранные пути/поддомены. Отдельно проверить /api/*, /account/*, /cart/*, /checkout/* — типичные персонализированные разделы.
2. Сделать тестовый запрос к персонализированной странице и посмотреть заголовки ответа. Наличие X-Cache: HIT (или аналогичного заголовка конкретного провайдера) на ответе с личными данными — сигнал, что страница кешируется на edge, и это стоит чинить через Cache-Control независимо от вопроса географии.

curl -sI https://example.com/account/profile | grep -i -E "x-cache|cache-control|cf-cache|age:"

1. Узнать у провайдера CDN, где физически хранятся access-логи. Либо есть в документации по обработке данных, либо запросить у поддержки напрямую — прямой вопрос «в какой юрисдикции хранятся логи запросов к моему домену и как долго» обычно получает конкретный ответ.
2. Проверить, есть ли отдельный маршрут для API и личного кабинета, минующий внешний CDN. Если такого маршрута нет, а персонализированные запросы идут через CDN «просто потому что весь домен через него настроен» — это первая точка, которую стоит вынести из-под CDN.
3. Задокументировать результат — какие типы запросов проходят через CDN, где физически edge-узлы для основной аудитории, где хранятся логи. Это не юридическое заключение, а инфраструктурная карта, без которой юридическая оценка попросту не на чем строится.

Этот аудит не требует останавливать прод и обычно занимает несколько часов.

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