С 1 сентября 2015 года действует поправка к 152-ФЗ, которая обязала операторов хранить персональные данные граждан РФ в базах, расположенных на территории России. Закон работает почти год, Роскомнадзор уже провёл первые проверки и завёл реестр нарушителей – блокировку LinkedIn в этом списке обсуждают все. Вопрос «надо ли переносить базы» закрыт. Открытый вопрос – как перенести их так, чтобы не сломать рабочие процессы и пройти проверку без замечаний.

Что требует закон на самом деле

Ключевая норма – статья 18 части 5: при сборе персональных данных оператор обязан обеспечить запись, систематизацию, накопление, хранение, уточнение и извлечение ПДн граждан РФ в базах на территории России. Слово «первичная» здесь принципиально. Закон не запрещает трансграничную передачу – он требует, чтобы первичная база-источник физически находилась в РФ. Зарубежная копия допустима как вторичная, если российская остаётся актуальной и полной.

Роскомнадзор при проверке смотрит три вещи: где физически стоит сервер с первичной базой, кто владеет этим оборудованием или ЦОДом, и подтверждено ли это документально – договором аренды стойки, актом о размещении, схемой потоков данных. Устных заверений недостаточно. Если вы пользуетесь облаком зарубежного провайдера без российского ЦОДа – это нарушение, даже когда юрлицо российское.

Где разместить базы

Практических вариантов три, и выбор зависит от масштаба и критичности данных.

Собственный или арендованный ЦОД в РФ. Подходит госсектору и крупным операторам с жёсткими требованиями к контролю. Дороже, но даёт полный контроль над оборудованием и упрощает аттестацию ИСПДн по приказам ФСТЭК.

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

Гибрид. Первичная база ПДн – в России, аналитика и обезличенные витрины – где удобно. Такой подход хорошо сочетается с разделением слоёв через API-first архитектуру: сервис ПДн изолируется за чётким контрактом, а внешние системы получают только то, что им разрешено. Если вы строите ML-модели в продакшене, обучайте их на обезличенных или агрегированных данных – тогда требование о локализации не парализует аналитику.

Что делать с уже работающей системой

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

Отдельно стоит выбирать платформу с прицелом на госконтракты. ПО из реестра отечественного софта снимает часть вопросов при работе с государственными заказчиками и упрощает закупки. Защиту самой ИСПДн – шифрование каналов, разграничение доступа, журналирование – закладывайте на этапе переноса, а не после. Этот контур проще выстраивать целостно, от аудита потоков ПДн до аттестации систем по требованиям регуляторов, а не латать по частям после первой проверки.

Вывод

Локализация – это не про географию серверов ради галочки, а про управляемые потоки данных. Первичная база в РФ, документально подтверждённая локация, изоляция слоёв через API и работа с обезличенными данными для аналитики – этого достаточно, чтобы пройти проверку Роскомнадзора и не потерять гибкость. Начните с инвентаризации потоков: пока вы не знаете, где и какие ПДн собираете, любой перенос – стрельба вслепую.