Защита данных РФ: пошаговый алгоритм локализации баз

18 152-ФЗ: запись, систематизация, накопление, хранение, уточнение и извлечение персональных данных граждан России нельзя выполнять с использованием баз данных за пределами РФ.

Проблема в том, что нарушение обычно живёт не в основной PostgreSQL-кластере. Оно сидит в резервной копии в зарубежном S3-бакете, в CRM с глобальным tenant’ом, в облачной CDP, в сервисе рассылок или в журнале событий, куда по привычке пишут email, телефон и IP. Архитектура может выглядеть локализованной на презентации. На уровне реального data flow она часто не проходит требования к хранению персональных данных в России.

Штраф для юридического лица за первое нарушение составляет от 1 до 6 млн рублей. Повторное — от 6 до 18 млн. Отдельный контур риска — ограничение доступа к ресурсу со стороны Роскомнадзора. Поэтому локализация баз данных РФ — не задача юриста, отправившего уведомление. Это инвентаризация, миграция, контроль репликаций и дисциплина деплоя.

Что изменилось в 152-ФЗ с 1 июля 2025 года

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

Новая редакция ч. 5 ст. 18 152-ФЗ прямо запрещает использовать зарубежные базы данных для следующих операций с персональными данными граждан РФ:

• записи;
• систематизации;
• накопления;
• хранения;
• уточнения;
• извлечения.

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

Это меняет типовой SaaS-ландшафт. Раньше бизнес мог подключить зарубежную CRM, форму, продуктовую аналитику и helpdesk, затем выгружать данные в локальную базу. Теперь последовательность должна быть обратной: российская база выступает источником истины, а любое дальнейшее взаимодействие с внешними системами строится через контролируемый слой передачи.

Локализация — это не география интерфейса SaaS. Это география операций над актуальной базой данных.

Под персональными данными в этой модели не стоит понимать только паспорт или телефон. В обработку могут попасть связки идентификаторов: email, номер заказа, IP-адрес, cookie-ID, user ID, геолокация, параметры устройства, записи обращений в поддержку. Отдельное поле может казаться техническим. В связке с аккаунтом оно становится идентификатором субъекта.

Требования закона о локализации данных РФ применимы не к конкретному типу СУБД, а к фактическому процессу обработки. Не имеет значения, работает ли приложение на PostgreSQL, MySQL, ClickHouse, MongoDB или managed database провайдера. Вопрос один: где физически находится база и где выполняются операции с данными граждан РФ.

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

Самая частая ошибка — называть российскую базу master, хотя она является read-replica зарубежного контура. Если запись вначале идёт в базу за границей, а российский экземпляр получает изменения через репликацию, требования не соблюдены. Локальная база должна быть актуальной мастер-базой, а не витриной для отчётности или кэшем.

Технически это означает смену направления потока:

1. Пользователь отправляет форму или запрос в API.

2. Приложение записывает данные в базу в РФ.

3. Российский контур назначает внутренний идентификатор субъекта.

4. Во внешнюю систему, если она нужна, уходит минимальный набор данных по утверждённому маршруту.

5. Результат внешней обработки возвращается и связывается с записью в российской базе.

Второй критический узел — бэкапы. Резервная копия не становится «небазой» от того, что лежит в холодном хранилище и открывается раз в год. Роскомнадзор рассматривает резервные копии как самостоятельные базы данных. Значит, выгрузка дампов в зарубежное объектное хранилище — нарушение, если в них содержатся персональные данные граждан РФ.

Не спасают и привычные формулировки:

• «Это лишь архив на случай аварии». Архив содержит те же данные.
• «Бакет зашифрован». Шифрование снижает риск утечки, но не меняет место хранения.
• «Доступ есть только у SRE-команды». Ограничение доступа не превращает зарубежную инфраструктуру в российскую.
• «У нас там только реплика для аналитики». Реплика с ПДн остаётся базой данных.
• «Выгрузка автоматическая, мы её не используем». Автоматизация не исключает факт хранения.

Ниже — типовые архитектурные решения и их статус.

Отдельно нужно проверить observability-контур. Логи приложений, APM, error tracking, записи сессий, аналитические события и тикеты поддержки часто утекают мимо основной модели данных. Разработчик добавил в лог email, backend отправил exception в внешний мониторинг, саппорт приложил экспорт обращения в зарубежную систему. Все три эпизода создают новые места хранения.

В зрелой системе персональные данные не должны попадать в логи вовсе. Email и телефон маскируются на уровне middleware. Токены, cookies, заголовки авторизации и тела запросов исключаются из трассировок. Для расследований инцидентов используется внутренний ID, а расшифровка доступна только в российском защищённом контуре.

Инвентаризация: сначала карта данных, затем миграция

Миграцию нельзя начинать с покупки нового облака. Сначала нужно установить фактическую топологию. Не заявленную в документации, а фактическую: с job scheduler, ETL, интеграциями, тестовыми стендами и забытыми бакетами бывшего подрядчика.

Инвентаризация должна охватывать не только production. Типовая утечка контроля возникает на staging и development: туда выгружают production snapshot для отладки, после чего копия оказывается в зарубежном облаке или на ноутбуке команды.

Для каждой системы нужен реестр с минимально необходимыми полями:

• название сервиса и владелец со стороны бизнеса и ИТ;
• назначение обработки;
• категории субъектов: клиенты, кандидаты, сотрудники, контрагенты;
• категории данных: контактные, платёжные, поведенческие, технические;
• физическое размещение основной базы, реплик и объектного хранилища;
• маршруты поступления данных;
• маршруты выгрузки и интеграции;
• резервные копии, срок их хранения, регион бакета;
• доступы подрядчиков и администраторов;
• наличие трансграничной передачи;
• подтверждающие документы от провайдера.

Работать лучше от точки входа. Берётся каждая форма, endpoint, интеграционный webhook и канал поддержки. Затем команда проходит маршрут записи до физического хранилища. Если маршрут нельзя доказать конфигурацией, контрактом, логами и настройками провайдера, он не должен считаться локализованным.

Что искать в конфигурациях и пайплайнах

Инфраструктурный аудит быстро выявляет следы старой архитектуры. В зоне внимания:

• переменные окружения с endpoint’ами глобальных облаков;
• настройки регионов в Terraform, Helm chart и CI/CD;
• URL объектных хранилищ в backup job;
• сторонние SDK аналитики и мониторинга;
• экспорт CRM в CSV по расписанию;
• коннекторы BI и ETL, которые читают production-базу;
• сервисные аккаунты, имеющие доступ к бэкапам;
• очереди сообщений и dead-letter queue;
• почтовые ящики, куда отправляются отчёты с персональными данными;
• тестовые базы, созданные из production snapshot.

Особенно неприятная зона — асинхронные очереди. Команда переносит PostgreSQL в российский регион, но оставляет message broker в зарубежном managed-сервисе. Если в payload есть телефон, email, ФИО или идентификатор, данные продолжают обрабатываться вне РФ. Псевдонимизация должна происходить до постановки сообщения в такую очередь, а не после неё.

База локализована ровно настолько, насколько локализован её самый забытый экспорт.

Алгоритм миграции мастер-баз в российский контур

После инвентаризации появляется предметный план. Он должен описывать не только перенос данных, но и момент переключения записи. Именно на этом этапе обычно возникают дубли, потерянные изменения и параллельная жизнь двух мастер-баз.

1. Зафиксировать целевую спецификацию

Определите, какая система становится system of record для каждой категории данных. В одном бизнесе может быть несколько таких систем: отдельная база клиентов, кадровый контур, сервис поддержки, биллинг. Это нормально. Ненормально, когда за актуальную запись одновременно отвечают российская ERP и зарубежная CRM.

Для каждого домена фиксируются:

• российский провайдер и регион размещения;
• тип хранилища: реляционная БД, объектное хранилище, очередь, поисковый индекс;
• RPO и RTO для восстановления;
• схема резервного копирования;
• шифрование на хранении и при передаче;
• роли доступа и порядок выдачи привилегий;
• срок хранения и правила удаления;
• разрешённые интеграционные маршруты.

Спецификация нужна не ради документа. Она даёт критерий для инфраструктурного коммита: изменяет ли он approved data flow или нет.

2. Подготовить российскую инфраструктуру

Выбор российского провайдера не исчерпывается галочкой «серверы в РФ». Нужны подтверждение размещения, условия обработки данных, описание резервного контура и понятный процесс предоставления документов для оператора.

Проверьте, где находятся:

• production-узлы;
• managed database;
• объектное хранилище;
• бэкапные репозитории;
• disaster recovery площадка;
• служебные журналы и snapshots;
• ключи шифрования и сервис управления ключами.

Если провайдер подтверждает локализацию compute, но не раскрывает регион резервного хранения, вопрос остаётся открытым. Для защиты данных РФ это не деталь договора, а архитектурное ограничение.

3. Очистить данные до переноса

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

На этом шаге полезно:

1. удалить устаревшие и неактуальные записи по утверждённым срокам хранения;

2. объединить дубли субъектов;

3. отделить технические идентификаторы от прямых ПДн;

4. убрать персональные данные из полей свободного текста, если они там не нужны;

5. проверить, не попали ли в базу секреты: пароли, токены, сканы документов без необходимого основания;

6. сформировать контролируемый экспорт с журналом операций.

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

4. Перенести данные и переключить запись

При малом объёме возможна короткая остановка записи: финальный экспорт, импорт, валидация, переключение DNS или connection string. При высокой нагрузке нужен поэтапный сценарий с репликацией изменений до cutover.

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

Минимальный набор проверок после переключения:

• приложение пишет новые записи в российскую БД;
• фоновые задачи используют новые endpoint’ы;
• очереди не содержат прямых ПДн вне РФ;
• полнотекстовый поиск индексирует данные в российском окружении;
• новые резервные копии создаются в российском хранилище;
• старые экспортные задания отключены;
• мониторинг не получает тела запросов с ПДн;
• доступ к прежнему окружению ограничен и имеет дату закрытия.

5. Уничтожить или обезличить старый контур

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

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

Полезно провести проверку через 30–60 дней после миграции. К этому времени всплывают cron-задачи, давно неиспользуемые интеграции и ручные выгрузки отдела продаж.

6. Обновить организационный контур

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

Юридическая часть не заменяет техническую. Но без неё технический контур остаётся недоказуемым при проверке.

Как работать с зарубежным SaaS после локализации

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

На практике для SaaS есть три модели.

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

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

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

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

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

Цена ошибки: штрафы, блокировка и операционный ущерб

Административный штраф — измеримая часть риска. Для юридических лиц первое нарушение требований локализации влечёт штраф от 1 до 6 млн рублей по ч. 8 ст. 13.11 КоАП РФ. За повторное нарушение — от 6 до 18 млн по ч. 9 той же статьи. Для должностных лиц санкции также возрастают, при повторном нарушении — до 800 тыс. рублей.

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

Локализация не решает все задачи ИБ. Российский сервер без сегментации сети, MFA, контроля привилегий и тестируемого восстановления — всё ещё слабая система. Хранение персональных данных в России отвечает на вопрос географии. Защита отвечает на другой вопрос: кто, каким способом и с какими последствиями получает доступ.

Поэтому после миграции следует проверить базовый минимум:

• MFA включена для административных аккаунтов, VPN, облачной консоли и CI/CD;
• прямой доступ к production-базам ограничен и журналируется;
• сервисные учётные записи имеют минимальные привилегии;
• секреты не лежат в репозиториях, переменных общего доступа и тикетах;
• резервные копии шифруются, размещаются в РФ и регулярно восстанавливаются на тестовом контуре;
• удаление данных распространяется на индексы, кэши, очереди и бэкапы в рамках утверждённого жизненного цикла;
• новые SaaS-интеграции проходят архитектурное согласование до деплоя;
• команда знает, какие поля запрещено писать в логи и передавать в внешние сервисы.

Локализация баз данных РФ не является разовой миграцией. Это ограничение на всю последующую архитектуру. Один новый SDK, один экспорт в объектное хранилище, один «временный» foreign tenant способны отменить результат проекта.

Правильная модель выглядит сухо: российская master-база, российские резервные копии, контролируемые маршруты, минимизация передачи, доказуемая конфигурация. Всё остальное — надежда, что фактический data flow никто не будет разбирать.