Локализация ПДн на практике: три миграции после первых штрафов по 242-ФЗ

Когда в сентябре 2015 заработал 242-ФЗ, многие операторы решили подождать: ну, заработал и заработал, посмотрим что будет. Посмотрели. В начале 2016 РКН провёл первые проверки именно по факту локализации, появились административные протоколы и, говорят, уже первые реальные штрафы - не огромные, но неприятные. После этого у нескольких клиентов сложился стойкий рефлекс «пора разбираться».

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

Сначала - найти, где данные на самом деле

Стандартная картина: клиент уверен, что у него «всё в порядке» и ПДн хранятся на серверах в Москве. После двух часов разговора с разработчиками и DevOps выясняется:

• CRM на SaaS - американский провайдер, данные в регионе us-east. Туда уходят ФИО, телефоны, email, история обращений.
• Backup в AWS S3 или аналоге - дамп prod-базы с ПДн улетает в зарубежное ведро «потому что дёшево и надёжно». Об этом нередко знает только один человек.
• Аналитика и BI - данные синхронизируются в Google BigQuery или похожий инструмент для отчётов. С ПДн в сыром виде.
• Email-маркетинг - рассылочный сервис иностранный, хранит адресную книгу с ФИО подписчиков.
• Логи в облаке - Papertrail, Loggly или аналог, куда попадают в том числе запросы с ПДн в URL или теле.

Вот это - shadow-копии. Формально первичная база может быть в России, но данные дублируются в пяти местах за рубежом, и это нарушение в том же объёме. Инспектору РКН достаточно попросить схему потоков данных, а если её нет - посмотреть DNS и сетевые запросы.

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

Технический план миграции

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

Перенос CRM на российскую или on-premise систему - самое болезненное. У одного из клиентов это AmoCRM с кастомными интеграциями, переход занял бы несколько месяцев и лежал за пределами нашего scope - обозначили риск, приоритизировали как критичный, передали клиенту с чётким описанием что именно нужно сделать.

С бэкапами проще. Типовое решение: S3-совместимое хранилище у российского провайдера (Selectel, российские IaaS-провайдеры с object storage). Бэкап-скрипты переключаются за день, данные за рубежом удаляются с подтверждением.

Аналитика - тут чаще всего помогает не перенос хранилища, а анонимизация или псевдонимизация на этапе выгрузки. Если отчётам нужны срезы по городам и категориям, а не конкретные Ивановы - убираем прямые идентификаторы до выгрузки в BI. Это технически несложно, зато снимает проблему целиком.

Email-рассылки - российские сервисы есть, переключение занимает день, данные экспортируются и удаляются у иностранного провайдера. Единственная сложность - история и статистика прошлых кампаний остаётся там, если не потащить её через API.

Документальная часть

Миграция без бумаги - только половина работы. РКН при проверке смотрит не только на то, где данные, но и на документы: политика обработки ПДн, согласия субъектов, договоры с третьими лицами, которым передаются ПДн. Если данные теперь хранятся у российского облачного провайдера - нужен договор с поручением обработки и соответствующим разделом про обязательства оператора. Без этого технически правильная инфраструктура юридически дырявая.

У двух из трёх клиентов политика обработки ПДн на сайте не была обновлена после того, как они добавили новые сервисы. Там до сих пор значился список систем двухлетней давности.

Что успели

К концу апреля у всех трёх клиентов закрыты самые критичные точки: бэкапы переехали в Россию, shadow-копии в зарубежных логгерах убраны или изолированы. CRM-миграция у двоих - в процессе планирования, это месяцы работы, не недели. Документация обновлена под текущее состояние.

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

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