Данные клиентов должны лежать в РФ: как это выглядит в архитектуре приложения

MAATRIX

Требование хранить и обрабатывать данные россиян на территории РФ юристы объяснят в двух абзацах, а вот как оно бьётся об реальную архитектуру приложения — вопрос, который обычно всплывает уже после того, как продукт собран из десятка внешних сервисов. Аналитика, письма, CRM, логи, бэкапы — каждый из них может незаметно увезти персональные данные за границу, даже если основная база честно стоит в российском дата-центре. Разберём это не с юридической, а с инженерной стороны: что конкретно должно физически лежать в РФ, как спроектировать систему так, чтобы не тащить туда всё приложение целиком, и как проверить, что вы уже не нарушаете требование, сами того не заметив.

Что физически обязано стоять в РФ

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

Что попадает под это требование в вашей схеме:

• Основная СУБД с таблицами пользователей, заказов, контактов, платёжных реквизитов, любых полей, идентифицирующих человека.
• Реплики и снимки этой БД, если в них остаются персональные данные, а не анонимизированная выборка.
• Файловые хранилища с документами, где фигурируют ФИО, паспортные данные, медицинские карты, фото людей.
• Поисковый индекс, если в нём проиндексированы персональные поля (например, Elasticsearch с полем email или full_name).

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

Как разделить данные, чтобы не тащить всё приложение в РФ

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

Практический приём — разнести персональные и обезличенные данные по разным хранилищам с внутренним идентификатором вместо прямой связи. Пример структуры:

-- в РФ: таблица с персональными данными, доступ строго ограничен
CREATE TABLE users_pii (
    user_id     UUID PRIMARY KEY,
    full_name   TEXT NOT NULL,
    phone       TEXT NOT NULL,
    email       TEXT NOT NULL,
    address     TEXT
);

-- может быть где угодно: только внутренний id, никакой идентификации человека
CREATE TABLE user_events (
    event_id    BIGSERIAL PRIMARY KEY,
    user_id     UUID NOT NULL,      -- ссылается на users_pii, но само по себе не PII
    event_type  TEXT NOT NULL,
    occurred_at TIMESTAMPTZ NOT NULL,
    payload     JSONB
);

Ключевой момент: user_id в таблице user_events сам по себе — случайный UUID, не привязанный ни к чему извне. Пока эта таблица не хранится рядом с таблицей, где UUID сопоставлен с ФИО и телефоном, вынесенный в отдельный контур сервис аналитики физически не может восстановить личность по одним только событиям. Это не юридическая гарантия сама по себе, но архитектурный барьер, который резко снижает риск и объём того, что вообще нужно локализовывать.

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

Типичные архитектурные ошибки: куда данные утекают незаметно

Даже когда основная БД честно стоит в российском дата-центре, персональные данные обычно утекают через интеграции, о которых никто не подумал как об «утечке за границу» — их подключали ради удобства, а не ради обхода закона.

Аналитика и веб-трекеры. Google Analytics, Mixpanel, Amplitude и похожие SaaS-платформы по умолчанию хранят события на серверах за пределами РФ. Если в событие попадает email, телефон или полное имя (а это случается сплошь и рядом — разработчик добавляет user_email в свойства события для отладки и забывает убрать), персональные данные уезжают за границу вместе с обычной аналитикой клика по кнопке. Практическое решение — либо использовать аналитику с российским размещением данных (например, Яндекс.Метрику для веб-аналитики), либо жёстко фильтровать свойства событий перед отправкой во внешний трекер, оставляя только обезличенный user_id.

Error-tracking и APM. Sentry, Bugsnag и подобные системы по умолчанию захватывают тело HTTP-запроса и заголовки — а там сплошь и рядом лежат email, токены, адреса. Достаточно необработанного исключения на форме регистрации, чтобы вся форма с персональными данными улетела в облако error-tracking-сервиса за рубежом. Нужна явная настройка beforeSend-хука, вырезающего чувствительные поля, до того как событие уйдёт с сервера. Похожая проблема разобрана в статье про токены и персональные данные в логах — принцип тот же: то, что должно логироваться для отладки, часто без всякого умысла превращается в канал утечки.

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

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

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

Резервные копии и репликация — отдельная головная боль

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

# неправильно: бэкап российской БД с ПДн уезжает в зарубежный бакет
pg_dump maindb | gzip | aws s3 cp - s3://backups-eu-west-1/maindb.sql.gz

# правильно: шифрование + хранение в российском объектном хранилище
pg_dump maindb | gzip | gpg --encrypt -r backup@yourcompany.ru \
  | rclone rcat ru-storage:backups/maindb-$(date +%F).sql.gz.gpg

То же касается репликации для отказоустойчивости: если вы поднимаете standby-реплику PostgreSQL в другом регионе ради географической избыточности, а в этой реплике остаются персональные данные, это тоже физическое хранение за пределами РФ — просто через другой канал, чем основная запись. Решение — либо держать все реплики с PDn внутри РФ (несколько дата-центров внутри страны вместо межстрановой репликации), либо реплицировать только обезличенную часть данных.

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

Как провести аудит: где данные лежат на самом деле

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

1. Инвентаризация исходящих соединений. На проде смотрят, куда вообще ходит трафик приложения:

ss -tnp | grep ESTAB | awk '{print $5}' | sort -u

Каждый внешний IP или домен из этого списка — кандидат на проверку: что именно туда уходит и есть ли там персональные данные.

2. Поиск PII-полей в коде интеграций. Грепом по кодовой базе ищут места, где персональные поля передаются во внешние SDK:

grep -rnE "email|phone|full_name|passport|address" \
  --include="*.js" --include="*.py" --include="*.go" \
  src/analytics/ src/integrations/ src/notifications/

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

3. Список используемых SaaS и их регионов. Собирают полный перечень внешних сервисов (аналитика, error-tracking, email, SMS, CRM, поддержка, платежи, ML-API) и для каждого фиксируют, в каком регионе физически хранятся данные, которые вы туда отправляете. Часть провайдеров прямо публикует регион хранения в настройках аккаунта — это стоит зафиксировать документально, а не оставлять предположением.

4. Проверка конфигурации бэкапов и репликации. Смотрят реальные крон-задания и конфиги бэкап-агентов на сервере, а не то, что написано в README:

crontab -l | grep -i backup
cat /etc/rclone.conf   # или аналогичный конфиг используемого инструмента

5. Проверка кеша и CDN-правил. Проверяют, какие URL-маски CDN кеширует и не подпадают ли под них страницы с персональными данными — личный кабинет, история заказов, профиль.

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

Практическая схема на VPS/выделенном сервере

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

Такая схема не требует переносить весь стек в одну юрисдикцию и не мешает держать инфраструктуру под зарубежную аудиторию там, где для неё быстрее и дешевле. Она требует дисциплины на уровне кода: не тащить персональные поля туда, где они не нужны, и явно помечать в схеме БД и в переменных окружения, какие таблицы и сервисы — «контур PII», а какие — нет.

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