Според българските закони всяка компания, която работи с личните данни на своите потребители в Русия, става оператор на ПДн, независимо дали иска или не. Това налага редица формални и процедурни задължения, които не всеки бизнес може или иска да поеме самостоятелно.
Както показва практиката – напълно правилно не иска, защото тази област на знание е достатъчно нова и неизпитана на практика, че трудности и въпроси възникват дори и при професионалисти. Днес ще разкажем как реализирахме проект за съхранение на лични данни за нашия клиент и с какви неочевидни трудности се сблъскахме.
Как помагахме за защита на данните съгласно закон 152-ФЗ
В началото на 2019 година до нас се обърна компанията ООД „Смарт-Сервис“, разработчик на платформа за управление на сервизното обслужване. и приложение за обмен на контакти .
Першото решение позволява автоматизиране на процеса на обслужване на оборудването в най-различни области – от настройка на кафемашини и климатици в офисни помещения до ремонт на газови турбини. Второто – онлайн конструктор за създаване на електронни визитни картички на база 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
След анализ на грешките, екипът осъзна, че по-правилно би било да дублира инфраструктурата в защитената зона и да копира само файловете с данни. Беше взето решение да не изискваме от клиента доплащане за допълнителните сървърни мощности, които трябваше да бъдат инсталирани за завършване на миграцията.
В резултат, когато клъстерите в защитената зона бяха напълно дублирани, миграцията премина без проблеми.
Следваше единствено да се разделят мрежите на защитената и незащитената зона. Тук се получиха само няколко незначителни прекъсвания в работата. Етапът на тестване на цялата система в защитената зона без никаква защита успяхме да стартираме в нормален режим. След като събрахме положителна статистика за работата на системата в този режим, преминахме към последния етап: стартиране на защитните системи и ограничаване на достъпа.
Резултатен изход и полезен урок
В крайна сметка, с общи усилия заедно с клиента, успяхме да внесем значителни промени в съществуващата сървърна инфраструктура, което повиши надеждността и защитеността на съхранението на лични данни, значително намали рисковете от несанкциониран достъп до тях и получихме сертификат за изпълнение на изискванията за съхранение — постижение, до което не са достигнали още всички разработчици на подобен софтуер.
В резюме, комплексът от работи по проекта изглеждаше така:
- Организирана е отделна подсеть;
- Общо мигрираны два клъстера, съставени от пет виртуални машини: Failover клъстер на бази данни (две виртуални машини), Service Fabric клъстер на приложения (три виртуални машини);
- Извършени са настройки на системи за защита и криптиране на данни.
Изглежда всичко е ясно и логично. В практиката обаче всичко е малко по-сложно. Още веднъж се уверихме, че при работа с всяка отделна задача от такъв тип е необходимо изключително внимание към "дреболии", които в крайна сметка се оказват важни фактори за успеха на целия проект.
Източник: habr.com
