Локализация ПДн: как мы переносили CRM-базу в Россию под плановые проверки РКН

Роскомнадзор объявил, что плановые проверки соответствия 152-ФЗ в части локализации персональных данных в 2018 году будут проводиться систематически. Это не первое такое заявление, но тональность изменилась: раньше звучало «будем проверять», теперь звучит «проверяем по плану». Для компаний, у которых базы ПДн до сих пор лежат на зарубежных площадках, это конкретный сигнал к действию, а не повод положить задачу в бэклог на следующий квартал.

Мы как раз заканчиваем проект именно такого рода - перенос CRM-базы заказчика с хостинга в Нидерландах на российский ЦОД. Расскажем как это устроено технически и почему юридическая часть оказалась не менее трудоёмкой.

Откуда взялась задача

Заказчик - средний бизнес, CRM на PostgreSQL, несколько десятков тысяч записей о клиентах с ФИО, контактами и историей заказов. База исторически оказалась на голландском хостинге - в своё время так сложилось, потому что там была удобная инфраструктура, а требований про локализацию тогда никто особо не читал.

152-ФЗ в части обязательной локализации ПДн граждан РФ действует с сентября 2015 года. Многие компании это знают, но реальное движение у большинства началось только тогда, когда РКН стал составлять реестры нарушителей и блокировать ресурсы - как это было с Linkedin в 2016. После того как в начале года заработали новые методики проверок и начали приходить письма о плановых визитах, заказчик решил что пора.

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

Техника: логическая репликация PostgreSQL

На зарубежном хостинге стоял PostgreSQL 10 - нам повезло, потому что именно в десятой версии логическая репликация вошла в ядро как стабильная фича. Мы её уже обкатывали на другом проекте, схема знакома.

Подняли PostgreSQL 10 на российской площадке, создали схему, применили дамп структуры. Дальше:

• На источнике создали PUBLICATION на таблицы с данными клиентов и историей заказов.
• На приёмнике создали SUBSCRIPTION - он сам вытянул начальные данные через COPY и встал в поток изменений.
• Пока репликация догоняла лаг, CRM продолжала работать в штатном режиме на источнике.
• Когда лаг упал до нуля, переключили приложение на новую базу. Окно переключения - меньше минуты.

Нюанс, который надо держать в голове: DDL не реплицируется. Если во время репликации прилетает миграция схемы - её надо применить на обеих базах скоординированно, иначе репликация встанет с ошибкой несоответствия структуры. У заказчика за время переноса как раз была одна такая миграция - добавляли поле в таблицу контактов. Остановили репликацию, применили миграцию на источнике и приёмнике, возобновили. Ничего страшного, но надо планировать заранее.

После переключения зарубежный инстанс ещё неделю работал в режиме read-only как резервный, потом выключили.

Юридика: оферта и политика

Технически всё решается за пару дней работы. Юридически - дольше.

Первое - обновление политики обработки персональных данных. В политике должно быть явно указано где хранятся данные. Если раньше там было написано что-то вроде «на серверах оператора», надо добавить что серверы находятся на территории РФ и назвать конкретный ЦОД. Это звучит формально, но РКН при проверке смотрит именно на это.

Второе - оферта и пользовательское соглашение. Если в них была ссылка на зарубежный реестр или указано иностранное юрисдикционное право для споров по персональным данным - надо привести в соответствие. У нашего заказчика в оферте был абзац про трансграничную передачу данных, который теперь потерял смысл и создавал лишние вопросы. Убрали.

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

Всё это делали совместно с юристами заказчика - мы закрывали техническую часть и давали им требования к формулировкам, они финализировали тексты. Такой раздел ответственности нормально работает.

Что сейчас

База работает в российском ЦОД уже месяц. Производительность - на том же уровне, задержки даже чуть ниже для пользователей из России. CRM работает штатно.

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

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

Если у вас похожая ситуация - зарубежный хостинг с данными российских клиентов и приближающийся дедлайн - интеграцию мы делаем с учётом таких ограничений.