Kuidas täita 152-FZ nõudeid, kaitsta oma klientide isikuandmeid ja mitte astuda meie ämbrite külge.  

Venemaa seaduste kohaselt muutub iga ettevõte, mis tegeleb oma kasutajate isikuandmete töötlemisega Venemaal, isikuandmete operaatoriks, olenemata soovist. See seab talle mitmeid formaalseid ja protseduurilisi kohustusi, mida mitte iga ettevõte ei suuda või ei soovi üksi kanda.

Praktika näitab, et see on täiesti õigustatud, kuna see valdkond on veel nii uus ja praktikas katsetamata, et raskusi ja küsimusi tekib isegi professionaalide seas. Täna räägime sellest, kuidas me realiseerisime isikuandmete säilitamise projekti meie kliendile ja milliste mitteilmselgete raskustega me silmitsi seisime.

Kuidas me aitasime andmeid kaitsta 152-FZ kohaselt

2019. aasta alguses pöördus meie poole ettevõte OÜ „Smart-Service”, kes arendab teenindushalduse platvormi. HubEx ja rakendust kontaktide vahetamiseks myQRcards.
 
Esimene lahendus võimaldab automatiseerida seadmete hooldusprotsessi väga erinevates valdkondades – alates kohvimasinate ja kliimaseadmete seadistamisest kontorites kuni gaasturbinate remondini. Teine - veebipõhine konstruktor elektrooniliste visiitkaartide loomiseks QR-koodide põhjal. 

Veebivisiitkaart myQRcards.

Mõlemad süsteemid salvestavad ja töötlevad kasutajate andmeid, mis kuuluvad 152-FZ kohaselt „isiklike” andmete klassifikatsiooni. Sel juhul sätestab seadus mitmeid piiranguid selliste isiklike andmete hoidmise süsteemidele, et tagada nõutav kaitsetase ja välistada volitamata juurdepääsu risk varguse või väärkasutamise eesmärgil.
 
Seadusest tuleb kinni pidada, kuid „Smart-Service” ei kavatsenud arendada oma sisemisi pädevusi isikuandmete kaitsmisel. Seetõttu „kolisid” teenused ja andmed, millega jagasid nende kasutajad, Linxdatacenterisse. „Smart-Service” kolis oma töökeskkonna serverivõimsused meie andmekeskuse eraldi kaitstud võrgupiirkonda, mis on sertifitseeritud vastavalt 152-FZ nõuetele – nii nimetatud „Kaitstud pilv”.
 

KUIDAS ON KAITSTUD PILV KONSTRUEERITUD

Iga infosüsteem, mis töötleb isikuandmeid, peab vastama kolmele peamisele nõudele: 

• Andmete salvestamise ja töötlemise serveritele juurdepääs peab toimuma VPN-kanali kaudu, millel on krüpteerimine vastavalt GOST-ile;
• Andmete salvestamise ja töötlemise serverid peavad olema pideva viirusetõrje мониторинги all, et avastada haavatavusi;
• Salvestusseade peab olema paigutatud isoleeritud võrkudesse. 

Me paigaldame klientide serverivõimsused eraldi tsoonidesse, mis vastavad 152-FZ nõuetele, ja aitame saada vastavushindamise tõendi.

Kaitstud virtuaalinfrastruktuuri arhitektuur OÜ „Smart Service“ jaoks.

Tööde käik

Esmane tööde kooskõlastamine toimus juuni 2019, mida võib pidada projekti alguskuuks. Kõik tööd peavad toimuma «elavas» keskkonnas, kus on tuhandeid päringuid päevas. Loomulikult tuli projekt teostada, katkestamata mõlema süsteemi tavapärast töörežiimi.

Seetõttu koostati ja kooskõlastati selge tegevusplaan, mis jaguneb neljaks etapiks:

• ettevalmistus,
• migratsioon,
• testimine ja kontroll reaalses keskkonnas,
• süsteemide jälgimise ja juurdepääsu piirangute käivitamine.

Iga juhuks olime ette näinud taastamisprotseduuri ettenägematute sündmuste korral (DRP). Algse plaani kohaselt ei võtnud tööd palju aega ega ressursse ja pidid lõppema juulis 2019. Iga etapi lõpus oli ette nähtud täielik võrgu kättesaadavuse ja süsteemide funktsionaalsuse testimine.

Kõige keerulisem etapp, kus «midagi võis valesti minna», oli migratsioon. Alguses plaanisime migratsiooni teostada virtuaalsete masinate täieliku üleviimisega. See oli kõige loogilisem variant, kuna see ei nõudnud täiendavate ressursside kaasamist ümberkonfigureerimiseks. Tundus, et vMotioni kasutamine ei oleks olnud tõesti keeruline.
  

Üllatuslikult

Kuid nagu see tavaliselt projektides uues valdkonnas juhtub, juhtus see, mida ei oodatud.

Kuna iga virtuaalne masin hõlmab 500 — 1 000 GB, võttis selliste mahtude kopeerimine isegi ühe andmekeskuse piires aega umbes 3-4 tundi iga masina kohta. Lõpptulemusena ei jõudnud me ette nähtud ajavahemikku. See juhtus andmekandjate füüsiliste piirangute tõttu andmete üleviimisel vCloudi.

Kasutatava vCloud versiooni viga ei võimaldanud korraldada Storage vMotion'i virtuaalse masina osas, millel olid erinevat tüüpi kettad, seetõttu tuli kettad vahetada. Lõpuks õnnestus virtuaalsed masinad üle kanda, kuid see võttis rohkem aega, kui oli plaanitud. 
 
Teine punkt, mida me ei arvestanud, on piirangud andmebaasi klastrite (Failover Cluster MS SQLServer) liigutamisel. Seetõttu tuli klaster viia tööle ühe sõlmega ja jätta see kaitstud tsooni välisse. 

Märkimisväärne on see, et siiani arusaamatul põhjusel lagunes virtuaalsete masinate ülekande tulemusena rakenduste klaster ja tuli uuesti kokku panna.

Esimese katse tulemusena saime rahuldava seisundi süsteemidest ja olime sunnitud uuesti tegelema planeerimise ja variandi väljatöötamisega.
 

Katse #2

Pärast vigade analüüsi mõistis meeskond, et oleks mõistlikum dubleerida infrastruktuur kaitstud tsoonis ja kopeerida ainult andmefailid. Otsustati, et tellijalt ei nõuta täiendavat tasu täiendavate serverivõimsuste eest, mis tuli migreerimise lõpuleviimiseks rakendada.

Seetõttu, kui kaitstud tsoonis klastrid olid täielikult dubleeritud, möödus migreerimine probleemideta.

Edasi tuli eraldada kaitstud ja avatud ala võrgud. Siin möödus see mõne väikese katkestusega. Terve süsteemi testimise etapp kaitstud tsoonis ilma igasuguse kaitseta õnnestus käivitada normaalses režiimis. Positiivsete tulemuste kogumisega sellises režiimis läksime viimasele etapile: kaitsesüsteemide käivitamisele ja juurdepääsu piiramisele.
 

Edukas lõpptulemus ja väärtuslik õppetund

 
Kokkuvõttes õnnestus koos tellijaga teha märkimisväärseid muudatusi olemasolevas serveri infrastruktuuris, mis tõstis isikuandmete kaitse usaldusväärsust ja turvalisust, vähendas oluliselt ebaseadusliku juurdepääsu riske ning saadi sertifikaat nõuete täitmise kohta – saavutus, mida pole veel saavutatud paljudel sarnaste tarkvarade arendajatel.
 
Kokkuvõttes nägi projekti tööde kogum välja nii:
 

1. Organiseeritud on eraldi alamvõrk;
2. Kokku on migreeritud kaks klastrit, mis koosnevad viiest virtuaalsest masinast: andmebaaside failover klaster (kaks virtuaalset masinat), rakenduste Service Fabric klaster (kolm virtuaalset masinat);
3. Teostatud on andmete kaitse ja krüpteerimise süsteemide seadistamine.

Tundub, et kõik on selge ja loogiline. Kuid praktikas osutub kõik veidi keerulisemaks. Oleme veel kord veendunud, et iga sellise ülesande puhul on vajalik äärmuslik tähelepanu «pisiasjadele», mis osutuvad kaugeltki mitte pisiasjadeks, vaid kogu projekti eduks määravateks teguriteks. 

Allikas: habr.com