Как да спазим изискванията на 152-ФЗ, да защитим личните данни на нашите клиенти и да не стъпим на нашите грабли.  

Според руския закон, всяка компания, която работи с личните данни на потребителите си в Русия, става оператор на ПДн, независимо дали иска или не. Това налага на нея редица формални и процедурни задължения, които не всеки бизнес може или иска да носи сам.

Както показва практиката – напълно оправдано не иска, защото тази област е толкова нова и недобре проучена, че трудности и въпроси възникват дори при професионалистите. Днес ще разкажем как реализирахме проект за съхранение на лични данни за нашия клиент и с какви неопределени затруднения се сблъскахме.

Как помогнахме да защитим данните по 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. Извършени са настройки на системите за защита и криптиране на данни.

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

Източник: habr.com