Миграция по закону. Как безопасно перенести персональные данные в виртуализированную среду

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

О тонкостях процесса миграции нам рассказал Владимир Лебедев, директор по развитию бизнеса Stack Group.

Требования законодательства

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

По закону бизнес обязан собирать, хранить и обрабатывать персональные данные на территории РФ. Все требования совершенно одинаковы как для российских, так и для зарубежных компаний, если их деятельность направлена на территорию России. При этом передавать персональные данные за пределы страны можно, но они должны быть неизменяемыми, и их объем не должен превышать объем в российских базах данных.

WWW

Федеральный закон о персональных данных
Роскомнадзор

Для кого закон?

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

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

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

Виртуализация

Переехать в облачную среду менее затратно, чем покупать и монтировать оборудование. В конце 2014 года цены на российские облака были в среднем на 15–30% выше, чем на европейские, а в конце 2015 года, наоборот, наши цены стали на 20–30% ниже: изменился валютный курс и относительная стоимость размещения в российских дата-центрах.

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

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

Риски, возникающие при миграции систем хранения данных

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

Этапы миграции в облако

Общие принципы миграции сервиса, то есть переноса операционных систем, отвечающих за работу этого сервиса, в виртуализированную среду, рассмотрим на примере решения VMware vSphere.

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

Далее необходим аудит информационных систем. На этом этапе определяется состав сервисов (какие ОС относятся к тому или иному сервису), а также их связность. Главная сложность заключается в многообразии исходных ОС и физической архитектуры серверов, на которых они работают. На основе этой информации составляется план миграции с учетом текущих бизнес-процессов: определяются требования к связности физической и виртуальной инфраструктур, порядок миграции, задаются допустимые «окна миграции». Важно помнить, что нельзя во время миграции обновлять версии программных продуктов или операционных систем. Одновременно с миграцией допускается только пересмотр вычислительных ресурсов (CPU, RAM, HDD).

Как правило, для миграции используется утилита VMware converter, которая эффективно работает при переносе ОС семейства Microsoft Windows (но у миграции работающих в этих ОС служб есть свои нюансы). А вот из-за особенностей файловых систем Linux примерно в 40% случаев после окончания работы VMware converter виртуальная машина может не запуститься. Если в Linux используется LVM, то надо развернуть в виртуальной среде новый экземпляр ОС из шаблона провайдера и затем перенести данные, программные продукты и внутренние службы.

Для любого типа ОС есть общие условия, затрудняющие миграцию: во-первых, способ хранения данных, из-за которого прямая миграция невозможна, — это динамические диски в Windows или LVM в Linux, а во-вторых, сложности из-за использования программных и аппаратных массивов RAID. Так, даже точный перенос данных сам по себе не гарантирует, что виртуальная машина успешно запустится. На физическом сервере работу виртуальных машин обеспечивает гипервизор — ОС, разделяющая физический сервер на несколько виртуальных машин, которые могут работать одновременно и использовать одни и те же физические ресурсы. Естественно, что набор виртуального оборудования у гипервизора не совпадает с оборудованием физического сервера, на котором работала ОС до миграции. Соответственно, из-за разницы драйверов возникает множество отличий доступа к этому оборудованию.

Миграция ADDS и MS SQL без остановки сервисов

Практически всегда для бизнеса необходимо, чтобы ряд сервисов оставался доступным в ходе миграции. При этом зачастую миграция без остановки сервиса рекомендуется как самая надежная. Поэтому рассмотрим особенности миграции без остановки наиболее популярных служб ОС Microsoft: Active Directory Domain Services (ADDS или AD) и Microsoft SQL (MS SQL). Для миграции Active Directory без остановки службы применяется следующий алгоритм:

• Формируется сетевая связность между физическим оборудованием и виртуализированной средой. Как правило, это site-to-site VPN — он создает логическую сеть поверх другой сети. При этом трафик может быть защищен шифрованием по протоколам IPsec.
• В облаке разворачиваем новые виртуальные машины из шаблона, где настраиваем контроллеры домена AD с добавлением их в лес.
• Базу данных Active Directory реплицируем по сети через VPN с работающих контроллеров на стороне физического оборудования в облачные.
• После репликации данных переназначаем мастеры ролей операций на облачные контроллеры и убираем роли контроллеров домена с серверов.
• Затем проверяем работу сервисов и отключаем учетные записи старых контроллеров и физическое оборудование.

Алгоритм миграции MS SQL более сложен, так как MS SQL обычно применятся в многоуровневом сервисе в качестве бэкенда. В записях DNS в приложениях, использующих базы данных (в клиентах MS SQL), приходится вручную указывать новое расположение базы данных. Поэтому совсем исключить простой нельзя, но его можно свести к минимуму. Существуют механизмы и безостановочной миграции MS SQL, к ним относятся Mirroring и AlwaysOn, но их применение не всегда оправданно. AlwaysOn доступен только в дорогих редакциях Enterprise-уровня, а Mirroring должен поддерживаться клиентами MS SQL. К тому же для применения механизмов Mirroring нужна дополнительная настройка всех клиентов MS SQL.
Рассмотрим наиболее частый вариант миграции MS SQL в облако:

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

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

Информационная безопасность

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

В перечне документов, определяющих требования и описывающих меры, необходимые для защиты информационных систем, на первом месте находится, разумеется, сам закон, который устанавливает общие требования. Конкретные действия регламентируются постановлениями Правительства РФ и нормативными документами ФСТЭК (Федеральная служба по техническому и экспортному контролю) и ФСБ (Федеральная служба безопасности).

Требования к хранению персональных данных

Требования к технической защите конфиденциальной информации и предоставлению услуг по защите информации достаточно четко сформулированы. Инструменты их реализации многообразны. В частности, это могут быть сетевые экраны, системы обнаружения вторжений, средства анализа защищенности, антивирусной защиты, средства защиты сред виртуализации. На рынке представлен широкий спектр средств защиты информации — и российских, и зарубежных вендоров. Есть уже правоприменительная практика, так как закон действует с 2007 года. В целом подход к регулированию в России отличается от, например, европейского подхода. Так, в России неисполнение предписанных требований по информационной безопасности ведет к возникновению ответственности. А на Западе компания может самостоятельно определять, каким способом выполнять требования, и ответственность наступает, только если совершены неправомерные действия с персональными данными.

Требования к инфраструктуре

Определенные требования регуляторы предъявляют и к инфраструктуре. Например, существует аттестация построенных автоматизированных систем, обеспечивающих защиту информации. Аттестат выдается независимой лабораторией, которая подтверждает, что инфраструктура готова и соответствует всем требованиям по защищенности информационных систем. Этот аттестат необязателен для коммерческих организаций, но дает возможность понять, что дата-центр имеет необходимую защиту и способен обеспечить безопасность данных компании.

Также есть международные стандарты ISO, регламентирующие построение системы управления информационной безопасностью (комплекс стандартов ISO 2700х). Многие иностранные компании соответствуют этим стандартам.

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

INFO

В Китае полная копия персональных данных должна храниться на территории страны, а любые банковские данные вообще запрещено передавать за ее пределы.

Прогноз на перенос

Довольно сложно подсчитать, сколько точно данных подлежат переносу в Россию, но, исходя из заполняемости рынка ЦОД, можно сказать, что мощностей вполне достаточно для локализации данных в соответствии с законом. Например, на рынке Московского региона наблюдается переизбыток мощностей: общая емкость составляет около 27 тысяч стоек, и почти 40% из них свободны. Многие дата-центры имеют площади высокой степени готовности. Нужно учесть и что плотность данных в одной стойке может различаться в зависимости от оборудования. Сегодня один юнит серверной стойки обрабатывает значительно больше информации, чем несколько лет назад.

При этом спрос неравномерен: год назад был достаточно серьезный подъем, сейчас число обращений от зарубежных компаний снизилось. Часть компаний уже переехала и соответствует требованиям, а часть ждет, например результатов проверок регуляторов (они повлияют на формирование второй волны).

WWW

Подробная техническая информация по продуктам VMware
Миграция ADDS
Обзор технологии AlwaysON)
Настройка репликации для AlwaysON