Локализация персональных данных на серверы РФ: как перенести и не сломать

Что такое требование локализации ПД

Локализация персональных данных — это юридическая норма, которая обязывает оператора выполнять определённые операции с ПД граждан России только на серверах, физически расположенных в Российской Федерации. Норма закреплена в части 5 статьи 18 152-ФЗ и действует с 1 сентября 2015 года. С 2024 года, после принятия 266-ФЗ и связанных подзаконных актов, толкование стало жёстче, а проверки — массовее.

Раньше я часто видел такие диалоги: «У нас сайт на Vercel» — «А база где?» — «В Supabase, кажется во Франкфурте». Это автоматически — нарушение ст. 18 ч. 5 152-ФЗ. Без вариантов, без исключений, без отговорок про «это же не настоящий бизнес, это просто лендинг». Если на сайт заходят россияне, оставляют форму обратной связи, регистрируются — все эти данные должны попадать сначала в российский ЦОД, а уже потом, при необходимости, могут реплицироваться куда угодно.

Ключевое слово — «первичный сбор». В законе перечислены операции, которые должны быть локализованы: сбор, запись, систематизация, накопление, хранение, уточнение (обновление, изменение), извлечение. То есть в момент, когда пользователь нажимает «Отправить» на форме, данные должны лететь на российский сервер — а не на американский с последующей репликацией в Москву. Очерёдность операций критична.

Норма родилась как ответ на ситуацию с глобальными платформами: до 2015 года российские пользователи Facebook, Google, LinkedIn хранились на западных серверах, и российское государство не имело никакого юридического рычага в случае утечек или запросов. После принятия закона часть платформ ушла, часть локализовалась (Booking, Aviasales и десятки B2C), часть была заблокирована (LinkedIn — самый известный кейс 2016 года).

В 2026 году нормы применения сильно ужесточились. Главрадиочастотный центр сканирует сайты автоматически: проверяет, на каком хостинге работает домен, куда уходят POST-запросы с форм, какие IP-адреса в SSL-сертификатах. Если результат — зарубежный CDN с зарубежными бэкенд-серверами, это автоматический повод для административного производства.

Кто обязан локализовать данные

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

Российские операторы

Тут всё прямолинейно. Юрлицо или ИП, зарегистрированные в РФ, обрабатывающие ПД любых субъектов — обязаны локализовать первичный сбор на российских серверах. Даже если ваш клиент — иностранец, оставивший заявку на русскоязычном сайте, его данные сначала должны попасть в РФ. Дальше можно реплицировать, передавать в трансграничном порядке, обрабатывать где угодно — но первая запись только в РФ.

Иностранные операторы

Здесь возникает основная путаница. До 2024 года иностранные компании активно спорили: «мы не российский бизнес, у нас офис в Кипре/Германии/США, российский закон на нас не распространяется». РКН и суды последовательно отвечали: распространяется, если есть хотя бы один из признаков ориентации сервиса на российский рынок.

Признаки, по которым иностранный оператор попадает под 152-ФЗ:

• домен в зоне .ru, .рф, .su;
• интерфейс на русском языке (хотя бы как одна из доступных опций);
• возможность оплаты в рублях;
• таргетированная реклама на россиян (Яндекс.Директ, ВК Реклама, ранее Google Ads с гео-таргетом «Россия»);
• прямые договоры с российскими контрагентами для обслуживания российских пользователей;
• физическое присутствие — офис, представительство, ДЗ;
• заключение договоров с российскими юр- или физлицами с использованием рублёвых расчётов.

Достаточно одного признака. Например, если ваш SaaS — английский интерфейс, но среди клиентов есть россияне, оплачивающие картой Мир, — вы оператор по 152-ФЗ. Booking.com — классический кейс: международный сервис, но за счёт рублёвых платежей и русскоязычного интерфейса они с 2016 года держат данные в РФ.

Какие данные подпадают под локализацию

Локализация требуется для тех данных, которые однозначно идентифицируют гражданина РФ или относятся к нему. Это шире, чем кажется. Ниже — практический разбор по типам.

Безусловно подлежат локализации

• Идентификационные данные: ФИО, паспортные данные, СНИЛС, ИНН, дата рождения, адрес регистрации.
• Контактные данные: телефон, email, мессенджеры, физический адрес доставки.
• Платёжные данные: номера карт (даже маскированные), банковские реквизиты, история транзакций.
• Биометрические данные: фотографии лица, отпечатки пальцев, голос, видеозаписи.
• Профильные данные: заполненные анкеты, резюме, история заказов с идентификацией.
• Поведенческие cookie с идентификатором: Яндекс.Метрика с включённым Webvisor, пиксели ВК, любые fingerprint-системы.

Условно подлежат — зависит от контекста

• IP-адрес. Сам по себе — спорно. Но в связке с другими данными (логи действий пользователя в личном кабинете) — однозначно ПД, требует локализации.
• Cookie без идентификатора. Технические сессионные cookie, не позволяющие идентифицировать пользователя, под 152-ФЗ не подпадают.
• Email в обезличенной выгрузке. Если email отдельно, без других данных — формально ПД. Но если используется только в обезличенной аналитике (например, хешированный) — допустима трансграничная передача без локализации.

НЕ подлежит локализации

• Полностью обезличенные данные (без возможности восстановить связь с субъектом).
• Агрегированная статистика (количество посетителей, средние показатели по группам).
• Технические логи без идентификации пользователя.
• Контент, созданный самим пользователем для публичного доступа (посты, комментарии — но не его учётная запись и контакты).
• Кэшированная статика (картинки, JS, CSS) — даже если она лежит на зарубежном CDN.

Что считается «сервером в РФ»

Закон сформулирован неточно — «сервер на территории Российской Федерации». Что считать сервером, и где проходит граница территории, не уточнено. На практике РКН и судебная практика выработали несколько критериев. Если соблюдены все — претензий не будет.

Физическое расположение ЦОДа

Дата-центр, где стоит сервер с базой данных, должен находиться внутри границ РФ. Не Калининград (он внутри, всё ок), не Крым (тоже внутри, никаких сомнений), но и не Алматы, не Минск, не Ереван — даже если хостинг-провайдер «российский по душе». Граница чёткая: физическая территория, признанная Российской Федерацией.

Юрисдикция оператора ЦОДа

Желательно, чтобы компания, владеющая ЦОДом, была зарегистрирована в РФ. Это не строгое требование закона, но в случае проверки облегчает доказательство. Кейс из практики: компания арендовала «российский ЦОД» у литовского провайдера. ЦОД физически в Москве, но юрлицо в ЕС. РКН на проверке потребовал договор с подтверждением физического расположения — пришлось доказывать письменно, с инспекцией.

Возможность проверки

Оператор должен быть готов предоставить РКН по запросу: договор аренды/услуг с ЦОДом, акт ввода серверов в эксплуатацию (если свои), документы на оборудование. На практике на проверках просят: «Покажите, где физически лежат ваши данные». Если ответа нет — это уже плохо. Если ответ «у нас на серверах AWS в Москве» — это нормально, но нужно подтвердить.

Российский AWS-регион — да или нет?

У многих остаётся вопрос: AWS закрыл регионы в РФ ещё в 2014, но что насчёт «российского облака» через VPN, бастион-хост или гибридные схемы? Ответ простой: если первичная запись происходит за границей — нарушение. Любые костыли в виде «прокси через российский сервер» не работают: РКН смотрит, где физически лежит база. Прокси-уровень не считается сервером ПД.

Российские хостинги в 2026: сравнение

В 2026 рынок российского облачного хостинга наконец стал зрелым. Основные игроки: Yandex Cloud, VK Cloud (бывший Mail.ru Cloud Solutions), Selectel, Timeweb Cloud, RuVDS, Reg.ru, и из enterprise-уровня — Cloud.ru (бывший SberCloud), MTS Cloud. Ниже — сравнение для бизнеса.

Мои рекомендации по сценариям:

• Стартап, MVP, лендинг с формой: Timeweb Cloud или Selectel. Хорошее соотношение цены и DevOps-удобства, есть managed-БД, managed-K8s, S3-совместимое хранилище.
• Средний бизнес, SaaS, e-commerce: Yandex Cloud или Selectel. Yandex стабильнее по сети и SLA, Selectel дешевле на 20-30%.
• Enterprise, госконтракты, повышенные требования к безопасности: Cloud.ru или Yandex Cloud. У первого преимущество — наличие аттестации по ФСТЭК, что критично для работы с банками и госзаказчиками.
• Проекты с AI/ML и интенсивной обработкой: VK Cloud (GigaChat) или Yandex Cloud (YandexGPT). Тут зависит от того, какая модель ближе к вашей задаче.
• Минимальный бюджет, VPS под небольшой сайт: RuVDS, Reg.ru — достаточно для небольшого Django/Node, баз до 50 ГБ. Не для нагруженных проектов.

Подводный камень — миграция между российскими облаками тоже непростая. У каждого провайдера свои API, свои особенности образов, свои инструменты резервирования. Поэтому выбирайте сразу с прицелом на 2-3 года вперёд. Менять Yandex Cloud на VK Cloud через год — это снова неделя работы.

Технический план миграции с AWS/GCP/Azure

Перенос с AWS на Yandex Cloud — это не «запушил Terraform и пошёл пить кофе». Это минимум неделя работы для проекта с реальной нагрузкой. Расскажу что я обычно делаю шаг за шагом. План универсальный, подходит для миграции с любого западного облака на любое российское.

Этап 1. Подготовка и инвентаризация (1-2 дня)

Прежде чем что-либо переносить, нужно понять, что именно у вас есть. Часто оказывается, что компания думала «у нас 5 сервисов на AWS», а после инвентаризации выясняется — 17 сервисов, 4 разных аккаунта, плюс что-то в DigitalOcean от стажёра 2020 года.

1. Составьте полный список всех сервисов: EC2, RDS, S3, Lambda, ElastiCache, CloudFront, Route53. Каждый — с указанием размера, нагрузки, версии ПО.
2. Определите, какие из них содержат ПД, а какие — нет. ПД содержат: базы пользователей, логи, бэкапы баз, S3-бакеты с пользовательскими файлами, поисковые индексы по пользователям.
3. Замерьте текущие метрики: RPS, latency, размер БД, количество соединений. Без этого после переезда вы не поймёте, стало хуже или нормально.
4. Подготовьте список зависимостей: что от чего зависит, какие сервисы общаются между собой, какие внешние API используются.
5. Сделайте полные бэкапы всего. Не «снапшоты в EBS», а реальные дампы, скачанные локально или в новое облако заранее.

Этап 2. Развёртывание целевой инфраструктуры (2-3 дня)

Поднимаете в Yandex Cloud / VK Cloud аналоги ваших сервисов:

• EC2 → Yandex Compute Cloud (виртуальные машины)
• RDS PostgreSQL → Managed Service for PostgreSQL
• RDS MySQL → Managed Service for MySQL
• S3 → Object Storage (S3-совместимый, можно использовать те же библиотеки)
• ElastiCache (Redis) → Managed Service for Redis
• Lambda → Cloud Functions
• CloudFront → Yandex CDN (или Selectel CDN)
• Route53 → Yandex Cloud DNS
• SES → SMTP через любого российского провайдера (Unisender, Sendsay)

Тут важно: одновременно с развёртыванием настройте мониторинг (Yandex Monitoring или Prometheus+Grafana), бэкапы (автоматические в Object Storage), и сеть (VPC, security groups, NAT).

Этап 3. Миграция БД (1-2 дня)

Самый рискованный этап. Варианты:

• Полный дамп + восстановление. Подходит для проектов с возможностью простоя 1-4 часа. Делаете pg_dump, переносите файл, восстанавливаете на новой БД. Простой = время восстановления.
• Логическая репликация. Поднимаете на новой БД pglogical, реплицируете данные с минимальной задержкой. В момент переключения — несколько секунд простоя. Подходит для проектов 24/7.
• Постепенная миграция через двойную запись. Приложение пишет одновременно в старую и новую БД, читает из старой. Через неделю проверки данных — переключается на чтение из новой. Самый безопасный, но трудоёмкий вариант.

Этап 4. Перенос статики и файлов (параллельно с этапом 3)

S3 → Object Storage. Самый простой инструмент — rclone: указываете оба провайдера, запускаете rclone sync. Для больших объёмов (>500 ГБ) лучше использовать многопоточную копию или специализированные инструменты Yandex Data Transfer. Время — от часа до суток в зависимости от объёма и канала.

Параллельно — обновляете в коде приложения URL для статики, пути к S3-бакетам, креды. Если используете подписанные URL, обновляете подписи на новые ключи.

Этап 5. Тестирование на изолированной копии (1-2 дня)

Перед переключением — поднимаете полную копию приложения на новой инфраструктуре, без боевого трафика. Прогоняете:

• функциональные тесты — все ключевые сценарии (регистрация, оплата, выгрузка отчётов);
• нагрузочные тесты — k6, Locust или yandex-tank — на ту же нагрузку, что в проде;
• проверку всех интеграций — платёжные системы, рассылки, аналитика;
• проверку резервных копий — действительно ли создаются, действительно ли восстанавливаются.

Этап 6. Переключение DNS (1 день)

Делаете в час минимальной нагрузки (для русскоязычной аудитории — обычно 4-6 утра по Москве). Шаги:

1. За 24 часа до переключения снижаете TTL DNS-записей до 60 секунд.
2. Проводите финальную синхронизацию БД (последняя дельта).
3. Переводите старое приложение в режим только-для-чтения.
4. Меняете A-запись DNS на новый IP.
5. Ждёте 5-10 минут, проверяете, что трафик идёт на новые серверы.
6. Снимаете режим только-для-чтения на новой инфраструктуре.

Этап 7. Мониторинг и фолбэк (минимум неделя)

Не выключайте старую инфраструктуру сразу. Минимум неделю держите её в готовом состоянии, чтобы в случае проблем можно было быстро откатиться. Активно мониторите:

• метрики приложения (latency, RPS, ошибки 5xx);
• метрики БД (медленные запросы, размер коннекшен-пула, IOPS);
• уведомления о падении сервисов (Telegram-бот, Slack, что угодно);
• бизнес-метрики (количество регистраций, оплат, обращений в поддержку).

Если за неделю всё ок — отключаете старую инфраструктуру, не забыв сохранить бэкапы данных на 1-3 месяца на холодное хранение.

Гибридные схемы: что можно держать за границей

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

Можно за границей (легально)

• CDN со статикой: CSS, JS, изображения, видео — не содержат ПД. Cloudflare, Fastly, BunnyCDN — допустимо. Главное: не передавать через CDN cookie с идентификаторами.
• Обезличенные бэкапы: если делаете дополнительную копию для географической надёжности — можно. Но: бэкап должен быть зашифрован, ключ хранится в РФ, и это вторичная копия (первичный бэкап обязан быть в РФ).
• Агрегированная аналитика: Mixpanel, Amplitude (если ещё работают), Plausible — допустимо, если передаёте только агрегаты, без ID пользователей.
• Технические сервисы без ПД: Sentry для ошибок (если конфигурируете без user IP и user ID), GitHub для кода, npm для зависимостей.
• Платёжные сервисы за рубежом для зарубежных платежей: Stripe — если принимаете от иностранцев. Российские карты только через российские эквайринги.

НЕЛЬЗЯ за границей

• Основная база пользователей: любые БД с ФИО, email, телефоном, паспортами.
• Логи действий пользователей с идентификацией (например, audit-логи в S3 с user_id).
• Файлы пользователей: аватары, документы, фото профиля — если они привязаны к конкретному пользователю.
• Email-сервисы для российских пользователей: Mailchimp, SendGrid — нельзя. Только Unisender, Sendsay, российские SMTP.
• Чаты и поддержка: Intercom, Zendesk с историей переписки — нет. Только российские аналоги (Carrot Quest, Help Crunch с локализацией).
• CRM: HubSpot, Salesforce — нет. Битрикс24, AmoCRM — да.
• BI-системы с детализацией: если в Tableau льёте данные с user_id — нет. Только агрегаты.

Штрафы за нарушение локализации

Прямая ответственность — ст. 13.11 ч. 8 КоАП «Невыполнение оператором обязанности по обеспечению записи, систематизации, накопления, хранения, уточнения, извлечения персональных данных граждан Российской Федерации с использованием баз данных, находящихся на территории Российской Федерации».

Это только прямой штраф. Дополнительные последствия:

• Блокировка сайта. По ст. 15.5 149-ФЗ РКН может через суд требовать блокировки сайта-нарушителя. Самый известный кейс — LinkedIn в 2016. По состоянию на 2026 эта мера применяется регулярно, особенно к зарубежным сервисам.
• Внесение в реестр нарушителей. Публичная база, которая навсегда остаётся в открытом доступе. Видна банкам, контрагентам, тендерным площадкам.
• Невозможность работы с госзаказчиками и крупными корпоративными клиентами — все требуют подтверждения соответствия 152-ФЗ.
• Гражданские иски от пользователей. Если из-за нарушения локализации произошла утечка — каждый пострадавший может подать иск. Средние суммы компенсаций морального вреда — 5-50 тыс ₽ за человека, для крупной утечки это легко сотни миллионов.

Самопроверка: где сейчас лежат ваши данные

Прежде чем начинать миграцию, полезно понять масштаб проблемы. Самопроверка на 30 минут:

Шаг 1. Проверьте свой хостинг

Откройте терминал и выполните:

dig +short yourdomain.ru
whois yourdomain.ru | grep -i country
nslookup yourdomain.ru

Получите IP-адрес. Дальше — определяете, кому он принадлежит. Самый простой способ — whois <IP> или сервис ipinfo.io/<IP>. Если в результате «AWS», «Google Cloud», «Microsoft Azure», «Cloudflare» (если не CDN-режим), «DigitalOcean», «Hetzner», «OVH» — у вас зарубежный хостинг.

Шаг 2. Проверьте куда уходят формы

Откройте сайт, F12 → Network → XHR/Fetch. Заполните любую форму. Посмотрите на куда уходит POST-запрос:

• Если на ваш домен или поддомен — проверяйте по шагу 1.
• Если на сторонний сервис (api.tilda.cc, formspree.io, getform.io, mailchi.mp) — посмотрите, где он хостится. Например, у Tilda CMS форм-API расположен в России (требует уточнения по конкретному тарифу), а Formspree — в США.

Шаг 3. Проверьте сторонние сервисы

Составьте полный список всех сервисов, которые получают ваших пользователей:

• CRM — где хостится? Битрикс24 в РФ, HubSpot в США.
• Email-рассылка — Unisender (РФ) или Mailchimp (США)?
• Чат на сайте — JivoSite (РФ) или Intercom (США)?
• Аналитика — Яндекс.Метрика (РФ) или Google Analytics (США)?
• Хостинг файлов — Yandex Object Storage (РФ) или AWS S3 (за рубежом)?
• Pixel-аналитика — Вконтакте Pixel (РФ) или Facebook Pixel (США)?

Шаг 4. Проверьте бэкапы

Спросите DevOps или провайдера: куда лично уходят бэкапы базы? Часто оказывается, что приложение в Yandex Cloud, а бэкапы — на AWS S3 «потому что у меня там лежали ещё со старого проекта». Это нарушение.

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

1. У меня лендинг на Tilda — нужна ли мне локализация?

Tilda хостится в России (по официальному заявлению — на серверах в Москве). Если используете встроенные формы Tilda и стандартный приём заявок — данные хранятся в РФ. Если интегрировали внешний сервис (Mailchimp, HubSpot) — данные уходят за границу, нарушение. Решение — встроенная CRM Tilda или интеграция с российскими сервисами через Webhook.

2. WordPress на иностранном хостинге, переехать дорого. Что делать?

Дешевле и быстрее всего — переехать на Beget или Timeweb, для WordPress это занимает 1-2 часа через стандартные миграционные инструменты. Если очень не хочется — можно вынести только базу: поднять PostgreSQL/MySQL на Yandex Cloud, настроить WordPress на удалённое подключение. Но это технически сложнее и сильнее влияет на производительность.

3. Можно ли использовать Cloudflare как CDN?

Можно, если используете его в режиме DNS Only (серые облачка), без проксирования. Тогда Cloudflare видит только DNS-запросы, не пользовательский трафик. Если включён proxy (оранжевые облачка), Cloudflare становится посредником между пользователем и вашим сервером — это спорная зона. РКН пока активно не штрафует за это, но риск есть. Безопаснее — Yandex CDN или BunnyCDN с настройкой только статики (без cookies).

4. Нужно ли локализовать данные иностранных пользователей?

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

5. У меня SaaS, клиенты — другие компании. Чьи данные локализовать?

Двойной слой. Ваши собственные пользователи системы (сотрудники клиентов, которые логинятся в ваш SaaS) — это ПД, должны быть в РФ. Данные конечных клиентов ваших клиентов (например, вы — CRM, и клиент завёл туда базу контактов) — клиент сам является оператором этих данных, и в договоре с ним вы должны заявить, что вы — обработчик, и где находится сервер. Если сервер в РФ — клиенту хорошо. Если за границей — клиент тоже нарушает закон.

6. Есть ли упрощённая процедура для маленького бизнеса?

Нет. Закон не делает разницы между Газпромом и ИП с лендингом. Хорошая новость: и техническое решение для маленького бизнеса достижимо за 5-15 тыс ₽/мес на Timeweb или Reg.ru. Большинство ИП сейчас обходятся именно такими бюджетами.

7. Считается ли поглощение/слияние с переходом данных нарушением?

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

8. Можно ли мне как фрилансеру держать клиентскую базу в Notion/Google Docs?

Notion — серверы в США, нельзя. Google Docs — серверы в США, нельзя. Альтернативы: Яндекс.Документы (российские серверы), Р7-Офис, МойОфис. Для CRM — Битрикс24 бесплатный тариф.

Выводы

Локализация ПД — это не «галочка для отвода глаз», а реальное техническое требование, которое РКН активно проверяет. С 2025 года появились автоматические сканы сайтов, штрафы выросли в разы, и судебная практика стабилизировалась — суды принимают сторону регулятора в 95% случаев.

Хорошая новость: российский облачный рынок в 2026 году достаточно зрелый. Yandex Cloud, VK Cloud, Selectel дают enterprise-функционал, сопоставимый с AWS базового уровня. Цены — на 20-40% ниже, поддержка на русском, юридическая чистота гарантирована.

Что делать прямо сейчас:

1. Сегодня: сделайте самопроверку (шаги выше) — выясните, где у вас лежат данные.
2. На этой неделе: если есть нарушения, оцените масштаб миграции. Маленький лендинг — 1-3 дня. Средний SaaS — 1-3 недели. Крупный enterprise — 1-3 месяца.
3. В этом месяце: запланируйте миграцию. Выберите хостинг под ваш профиль, составьте план по схеме из этой статьи.
4. Параллельно: обновите политику ПД, переподайте уведомление в РКН с актуальными адресами серверов (если меняли страну хранения). Подача через pd.rkn.gov.ru.