Как да спазвате изискванията на 152-FZ, да защитите личните данни на клиентите си и да не стъпите на нашия рейк  

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

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

Как помогнахме за защитата на данните съгласно 152-FZ

В началото на 2019 г. с нас се свърза Smart-Service LLC, разработчик на платформа за управление на услуги HubEx и приложения за споделяне на контакти myQRcards.
 
Първото решение ви позволява да автоматизирате процеса на поддръжка на оборудването в различни области - от настройка на кафе машини и климатици в офис помещения до ремонт на газови турбини. Вторият е онлайн дизайнер за създаване на електронни визитки на базата на QR кодове. 

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

И двете системи съхраняват и обработват потребителски данни, които попадат в класификацията на „лични“ в съответствие с 152-FZ. В този случай законът диктува редица ограничения върху системите за съхранение на такива лични данни, за да се гарантира необходимото ниво на сигурност и да се елиминира рискът от неоторизиран достъп с цел кражба или злоупотреба.
 
Законът трябва да се спазва, но Smart Service не е планирал да развие в себе си компетентност за защита на личните данни. Следователно услугите и данните, споделени от техните потребители, се „преместиха“ в Linxdatacenter. “Smart Service” прехвърли сървърния капацитет на работната среда в отделна защитена мрежова зона на нашия център за данни, сертифицирана в съответствие с изискванията, посочени в 152-FZ - така наречения “Secure Cloud”.
 

КАК СЕ ПРОЕКТИРА ЕДИН СИГУРЕН ОБЛАК?

Всяка информационна система, обработваща лични данни, трябва да отговаря на три основни изисквания: 

• достъпът до сървърите за съхранение и обработка на данни трябва да се осъществява чрез VPN канал с криптиране в съответствие с GOST;
• сървърите за съхранение и обработка на данни трябва да бъдат постоянно наблюдавани от антивирусна защита за уязвимости;
• Системата за съхранение трябва да бъде разположена в изолирани мрежи. 

Ние поставяме сървърния капацитет на клиента в отделни зони, които отговарят на изискванията на 152-FZ и помагат да се получи заключение за съответствие.

Архитектура на защитена виртуална инфраструктура за Smart Service LLC.

напредък на работата

Първоначалното одобрение на работата беше извършено през юни 2019 г., което може да се счита за начална дата на проекта. Цялата работа трябва да се извършва в „жива“ среда с хиляди заявки на ден. Естествено, беше необходимо проектът да бъде завършен, без да се прекъсва нормалната работа на двете системи.

Затова беше изготвен и съгласуван ясен план за действие, разделен на 4 етапа:

• Подготовка,
• миграция,
• тестване и тестване в реални условия,
• активиране на системи за наблюдение и ограничения на достъпа.

За по-голяма сигурност сме включили процедура за възстановяване след бедствие (DRP). Според първоначалния план работата не отне много време и ресурси и трябваше да приключи през юли 2019 г. Всеки етап включваше накрая пълен тест на наличността на мрежата и функционалността на системите.

Най-трудният етап, в който „нещо може да се обърка“, беше миграцията. Първоначално планирахме да извършим миграцията чрез прехвърляне на цели виртуални машини. Това беше най-логичният вариант, тъй като не изискваше включването на допълнителни ресурси за преконфигуриране. Изглежда, че vMotion може да бъде по-прост.
  

Неочаквано

Въпреки това, както обикновено се случва при проекти в сравнително нова област, се случи нещо неочаквано.

Тъй като всяка виртуална машина заема 500 - 1 GB, копирането на такива томове дори в рамките на един център за данни отнема около 000-3 часа на машина. В резултат на това не изпълнихме определения времеви прозорец. Това се случи поради физически ограничения на дисковата подсистема при прехвърляне на данни към vCloud.

Грешка в използваната vCloud версия не позволяваше Storage vMotion да бъде организиран за виртуална машина с различни типове дискове, така че дисковете трябваше да бъдат сменени. В резултат беше възможно прехвърлянето на виртуалните машини, но отне повече време от планираното. 
 
Втората точка, която не предвидихме, са ограниченията за преместване на клъстера на базата данни (Failover Cluster MS SQLServer). В резултат на това беше необходимо да превключите клъстера да работи с един възел и да го оставите извън защитената зона. 

Трябва да се отбележи: по все още неясна причина, в резултат на прехвърлянето на виртуални машини, клъстерът на приложенията се разпадна и трябваше да бъде сглобен отново.

В резултат на първия опит получихме незадоволително състояние на системите и бяхме принудени да започнем отново да планираме и разработваме опции.
 

Опит №2

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

В резултат на това, когато клъстерите в защитената зона бяха напълно дублирани, миграцията премина без проблеми.

След това беше необходимо само да се разделят мрежите от защитени и незащитени зони. Тук имаше няколко незначителни прекъсвания. Етапът на тестване на цялата система в защитена зона без никаква защита успя да започне в нормален режим. След като събрахме положителна статистика за работата на системата в този режим, преминахме към последния етап: стартиране на системи за защита и ограничаване на достъпа.
 

Ефективен резултат и полезен урок

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

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

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

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