Локализация баз ПДн: что означает требование хранить в России

MAATRIX

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

Что означает требование локализации своими словами

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

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

Это отличает требование от многих привычных архитектурных решений, где физическое расположение сервера воспринимается как деталь производительности (ближе к пользователю — меньше пинг), а не как юридически значимый параметр. Здесь расположение базы данных становится жёстким ограничением само по себе, независимо от того, откуда быстрее обслуживать трафик.

Кого это затрагивает на практике

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

• Таблицы пользователей (регистрация, логин, email, телефон).
• Данные оформления заказов (ФИО, адрес доставки, телефон).
• CRM с карточками клиентов.
• Формы обратной связи, если данные сохраняются, а не просто пересылаются письмом.
• Платёжные и биллинговые записи, привязанные к личности.

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

Это существенно снижает масштаб задачи: вместо миграции всего стека речь чаще идёт о выделении одной БД или даже одной группы таблиц под отдельный контур.

Гибридная архитектура на практике: разбор схемы

Типовая схема для интернет-магазина или сервиса с международной и российской аудиторией одновременно выглядит примерно так:

                    ┌─────────────────────────┐
   Пользователи      │   Основной сервер (UK/US) │
   по всему миру ───▶│  веб-приложение, каталог, │
                    │  статика, кэш, CDN        │
                    └───────────┬───────────────┘
                                │ API-вызов только
                                │ при работе с ПДн
                                ▼
                    ┌─────────────────────────┐
                    │   Сервер в России (RU)    │
                    │  сервис регистрации/заказов│
                    │  + база персональных данных│
                    └─────────────────────────┘

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

С точки зрения конфигурации это означает как минимум:

• Отдельный сервер (VPS или выделенный) в датацентре на территории РФ под этот сервис и его СУБД.
• Сетевое взаимодействие между двумя серверами по защищённому каналу — TLS для API-вызовов либо VPN/WireGuard между площадками, если нужен более широкий доступ (например, для админки, которая должна видеть оба контура).
• Разделение прав доступа: основной сервер за рубежом не должен иметь прямой доступ на чтение к сырым персональным данным сверх того, что нужно для интерфейса (например, только маскированный email вместо полного, если это возможно по логике приложения).
• Мониторинг доступности обоих серверов отдельно — если российский сервис недоступен, у приложения должна быть внятная деградация (например, временная невозможность регистрации), а не тихая запись данных мимо требуемого контура.

Если объём операций с персональными данными большой (например, интернет-магазин с высокой конверсией), стоит рассчитывать российский сервер по нагрузке отдельно от основного — это не «маленький довесок», а полноценный продовый компонент со своими требованиями к бэкапам и отказоустойчивости.

Частые технические грабли

Задержка сети между площадками. Каждый вызов из-за рубежа в российский сервис — это RTT через границу, и в зависимости от маршрута он может быть заметным. Если API вызывается синхронно на каждый чих (например, на каждое обновление профиля), пользователь это почувствует. Стоит проектировать так, чтобы обращений к российскому контуру было минимально необходимое количество, а не на каждое действие в интерфейсе.

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

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

Забытые вторичные копии. Бэкапы, логи с полными данными запроса, экспортные CSV для аналитики, кэш в Redis с персональными полями — все эти вторичные хранилища тоже физически где-то лежат, и если основной сервис перенесён в РФ, а бэкапы льются на зарубежное хранилище по старой привычке, требование по факту не выполняется, просто это не всегда сразу заметно. Стоит явно пройтись по всем местам, куда персональные данные копируются, а не только по основной таблице.

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

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