Миграция персональных данных на новый хостинг: как соблюсти 152-ФЗ при переносе сервера

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

Почему смена хостинга — это риск с точки зрения 152-ФЗ?

В момент миграции персональные данные существуют одновременно в двух местах: на старом сервере и на новом. Это увеличивает так называемую поверхность атаки — количество точек, через которые данные потенциально могут утечь. Кроме того, при переносе часто используют промежуточные каналы связи, временные хранилища, архивы — и если хотя бы одно из этих звеньев не защищено, компания рискует получить инцидент прямо в процессе законного, казалось бы, действия.

Закон формально не требует уведомлять никого о факте миграции как таковом, но требует, чтобы на всех этапах обработки — включая перенос — сохранялась конфиденциальность, целостность и доступность данных. То есть ответственность оператора не приостанавливается на время переезда.

Нужно ли уведомлять Роскомнадзор о смене сервера?

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

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

Как перенести данные, чтобы не случилось утечки в процессе?

Есть несколько базовых принципов безопасного переноса:

• Передавать данные только по зашифрованным каналам связи, а не по открытому FTP или обычной почте;
• Минимизировать время, когда данные существуют в незашифрованном виде на промежуточных носителях;
• Ограничить круг сотрудников, имеющих доступ к процессу миграции, — чем меньше людей видит данные «в пути», тем ниже риск;
• Проверять целостность данных после переноса, чтобы убедиться, что ничего не потерялось и не исказилось;
• Вести журнал действий на всех этапах — кто, когда и что переносил.

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

Что делать со старым сервером после переноса?

Это один из самых частых источников проблем. Компании успешно переносят данные на новый хостинг, но забывают об старом — а там остаются резервные копии, логи, кэшированные файлы с персональными данными. Формально данные там уже «неактуальны», но фактически они всё ещё доступны, и если старый сервер попадёт не в те руки (например, при перепродаже оборудования провайдером), это будет считаться утечкой.

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

Нужно ли переоформлять договор с провайдером при миграции?

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

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

Какие риски несёт бизнес при неправильной миграции?

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

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

Как проверить, что новый хостинг подходит под требования 152-ФЗ?

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

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