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

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

Как мы помогали защитить данные по 152-ФЗ

В начале 2019 года к нам обратилась компания ООО «Смарт-Сервис», разработчик платформы для управления сервисным обслуживанием HubEx и приложения для обмена контактами myQRcards.
 
Первое решение позволяет автоматизировать процесс обслуживания оборудования в самых разных областях – от настройки кофемашин и кондиционеров в офисных помещениях до ремонта газовых турбин. Второе – онлайн-конструктор для создания электронных визитных карточек на базе QR-кодов. 


Онлайн-визитка myQRcards.

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

КАК УСТРОЕНО ЗАЩИЩЕННОЕ ОБЛАКО

Любая информационная система, обрабатывающая персональные данные, должна удовлетворять трем основным требованиям: 

• доступ к серверам хранения и обработки данных должен производиться через VPN-канал с шифрованием согласно ГОСТ;
  
• серверы хранения и обработки данных должны находиться под постоянным мониторингом антивирусной защитой на отсутствие уязвимостей;
  
• СХД должен быть расположен в изолированных сетях. 
  

Мы размещаем серверные мощности заказчика в отдельных зонах, удовлетворяющих требованиям 152-ФЗ, и помогаем получить заключение о соответствии.


Архитектура защищенной виртуальной инфраструктуры для ООО «Смарт Сервис».

Ход работ

Первично согласование работ было произведено в июне 2019 года, что можно считать датой начала проекта. Все работы должны быть производиться на «живом» окружении с тысячами запросов в день. Естественно, требовалось выполнить проект, не прерывая штатный режим работы обеих систем.

Поэтому был составлен и согласован четкий план действий, разделенный на 4 этапа:

• подготовка,
  
• миграция,
  
• тестирование и проверка в реальных условиях,
  
• включение систем мониторинга и ограничения доступа.
  

На всякий случай мы предусмотрели процедуру восстановления в случае непредвиденной ситуации (DRP). По первоначальному плану работы не занимали много времени и ресурсов и должны были завершиться в июле 2019. Каждый из этапов предусматривал в конце полное тестирование сетевой доступности и функциональности систем.

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

Нежданно-негаданно

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

Поскольку каждая виртуальная машина занимает 500 — 1 000 ГБ, копирование таких объемов даже в рамках одного дата-центра заняло около 3-4 часов на каждую машину. Как итог, мы не уложились в отведенное временное окно. Это произошло по причине физических ограничений дисковой подсистемы при переносе данных в vCloud.

Баг используемой версии vCloud не позволил организовать Storage vMotion в отношении виртуальной машины с разными типами дисков, поэтому диски пришлось менять. В результате перенести виртуальные машины получилось, но это заняло больше времени, чем планировалось. 
 
Второй момент, который мы не предусмотрели, — ограничения по перемещению кластера БД (Failover Cluster MS SQLServer). В результате пришлось перевести кластер в работу с одним узлом и оставить его за рамками защищенной зоны. 

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

В результате первой попытки мы получили неудовлетворительное состояние систем и вынуждены были заново браться за планирование и проработку вариантов.
 

Попытка №2

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

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

Далее требовалось лишь разделить сети защищенной и незащищенной зон. Здесь обошлось несколькими незначительными перебоями в работе. Этап тестирования всей системы в защищенной зоне без какой-либо защиты удалось запустить в штатном режиме. Собрав положительную статистику работы системы в таком режиме, мы перешли к последнему этапу: запуску систем защиты и ограничению доступа.
 

Результативный исход и полезный урок

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

1. Организована выделенная подсеть;
2. Суммарно мигрировано два кластера, состоящих из пяти виртуальных машин: Failover кластер баз данных (две виртуальные машины), Service Fabric кластер приложений (три виртуальные машины);
3. Произведены настройки систем защиты и шифрования данных.

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