Sipas ligjeve ruse, çdo kompani që punon me të dhënat personale të përdoruesve të saj në Rusi bëhet operator i PDn, qoftë kjo me dëshirë apo jo. Kjo i imponon asaj një sërë detyrimesh formale dhe procedurale, të cilat nuk është e lehtë t'i përballojë çdo biznes.
Siç tregon praktika - është plotësisht e arsyeshme të mos dëshirohet, pasi kjo fushë njohurish është ende aq e re dhe e paprovuar që vështirësitë dhe pyetjet shfaqen edhe te profesionistët. Sot do t'ju tregojmë si realizuam një projekt për ruajtjen e të dhënave personale për klientin tonë dhe me cilat vështirësi të papritura u përballëm.
Si e ndihmuam për të mbrojtur të dhënat sipas 152-FZ
Në fillim të vitit 2019, na kontaktoi kompania LLC 'Smart-Service', zhvilluesi i një platforme për menaxhimin e shërbimeve dhe një aplikacion për shkëmbimin e kontakteve .
Â
Zgjidhja e parĂ« lejon automatizimin e procesit tĂ« shĂ«rbimit tĂ« pajisjeve nĂ« fusha tĂ« ndryshme â nga konfigurimi i makinave tĂ« kafesĂ« dhe klimave nĂ« zyra deri te riparimi i turbinave me gaz. E dyta â njĂ« ndĂ«rtues online pĂ«r krijimin e vizitave elektronike mbi bazĂ«n e QR-kodit.Â
Vizitë online myQRcards.
Të dy sistemet ruajnë dhe përpunojnë të dhëna të përdoruesve që klasifikohen si 'personale' sipas 152-FZ. Në këtë rast, ligji imponon një sërë kufizimesh për sistemet për ruajtjen e këtyre të dhënave personale për të siguruar nivelin e kërkuar të mbrojtjes së tyre dhe për të eliminuar rrezikun e aksesit të paautorizuar me qëllim vjedhjen ose përdorimin e papërshtatshëm.
Â
Duhet të respektohet ligji, por 'Smart-Service' nuk planifikoi të zhvillonte brenda vetes kompetenca për mbrojtjen e PDn. Prandaj, shërbimet dhe të dhënat që ndanin përdoruesit e tyre 'u transferuan' në Linxdatacenter. 'Smart-Service' transferoi burimet serverike të mjedisit të punës në një zonë të veçantë të mbrojtur të qendrës sonë të të dhënave, të certifikuar sipas kërkesave të shpallura në 152-FZ - e njohur si 'Reja e Mbrojtur'.
Â
SI FUNKSIONON REJA E MBROJTUR
Ădo sistem informatik qĂ« pĂ«rpunon tĂ« dhĂ«na personale duhet tĂ« plotĂ«sojĂ« tre kĂ«rkesa kryesore:Â
- akseset në serverët e ruajtjes dhe përpunimit të të dhënave duhet të realizohen përmes një kanali VPN me enkriptim sipas GOST;
- serverët e ruajtjes dhe përpunimit të të dhënave duhet të jenë nën mbikëqyrje të vazhdueshme të mbrojtjes antivirus për të kontrolluar pushimet për çdo vulnerabilitet;
- Sistemi i ruajtjes duhet tĂ« vendoset nĂ« rrjeta tĂ« izoluara.Â
Ne vendosim burimet serverike të klientëve në zona të vecanta që plotësojnë kërkesat e 152-FZ dhe ndihmojmë për të siguruar një konfirmim për përputhjen.
Arkitektura e infrastrukturës virtuale të mbrojtur për LLC 'Smart Service'.
Procesi i punës
Fillimisht, miratimi i punëve u bë në qershor 2019, që mund të quhet data e fillimit të projektit. Të gjitha punët duhet të realizoheshin në një mjedis 'të gjallë' me mijëra kërkesa në ditë. Sigurisht, kërkohej të përfundonim projektin pa ndërprerë funksionimin normal të të dy sistemi.
Prandaj, u hartua dhe u miratua një plan veprimi i qartë, i ndarë në 4 etapa:
- përgatitja,
- migruarja,
- testimi dhe kontrolli në kushte reale,
- përfshirja e sistemeve të mbikëqyrjes dhe kufizimit të aksesit.
PĂ«r çdo rast, ne parashikuam njĂ« procedurĂ« pĂ«r rikuperim nĂ« rast situatash tĂ« paparashikuara (DRP). Sipas planit fillestar, punĂ«t nuk do tĂ« merrnin shumĂ« kohĂ« dhe burime dhe do tĂ« duhej tĂ« pĂ«rfundonin nĂ« korrik 2019. Ădo njĂ« nga etapat parashikonte nĂ« fund njĂ« testim tĂ« plotĂ« tĂ« aksesit rrjet dhe funksionalitetit tĂ« sistemeve.
Etapa më e komplikuar, në të cilën mund të ndodhte 'diçka', ishte migraje. Fillimisht, ne planifikuam të bënte migrimin duke transferuar të gjitha makinat virtuale. Kjo ishte opsioni më logjik, pasi nuk kërkonte angazhimin e burimeve shtesë për rikonfigurimin. Duket se çfarë mund të ishte më e lehtë se vMotion.
 Â
Për të papritur
Megjithatë, siç ndodh zakonisht në projektet në një fushë relativisht të re, ndodhi ajo që nuk e prisnim.
Duke qenë se çdo makinë virtuale zinte 500 - 1,000 GB, kopjimi i këtyre volumeteve madje brenda një qendre të të dhënave zgjati rreth 3-4 orë për çdo makinë. Si rezultat, ne nuk arritëm ta përfundonim brenda afatit të caktuar. Kjo ndodhi për shkak të kufizimeve fizike të nën-sistemit të diskut gjatë transferimit të të dhënave në vCloud.
NjĂ« defekt nĂ« versionin vCloud nuk lejojĂ« organizimin e Storage vMotion pĂ«r njĂ« makinĂ« virtuale me tipe disku tĂ« ndryshĂ«m, prandaj disqet duhej tĂ« ndryshoheshin. Si rezultat, arritĂ«m tĂ« transferonim makinat virtuale, por kjo mori mĂ« shumĂ« kohĂ« sesa ishte planifikuar.Â
Â
Momenti i dytĂ« qĂ« nuk e kishim parashikuar ishte kufizimet e lĂ«vizjes sĂ« klasĂ«s sĂ« DB (Failover Cluster MS SQLServer). Si rezultat, duhej tĂ« kalonim klasĂ«n nĂ« operim me njĂ« nod dhe ta lĂ«mĂ« atĂ« jashtĂ« zonĂ«s sĂ« mbrojtur.Â
E veçantë: për arsye që ende nuk janë të qarta, gjatë transferimit të makinave virtuale, klasteri i aplikacioneve u shpërbë, dhe duhej të ribëhej nga e para.
Si rezultat i përpjekjes së parë, morëm një gjendje të pakënaqshme të sistemeve dhe u detyruam të rifillojmë planifikimin dhe shqyrtimin e varianteve.
Â
PĂ«rpjekja nr. 2
Pas punës mbi gabimet, ekipi kuptoi se do të ishte më e arsyeshme të dyfishohej infrastruktura në zonën e mbrojtur dhe të kopjoheshin vetëm skedarët me të dhëna. U vendos që të mos kërkohej pagesë e shtuar nga klienti për kapacitetet shtesë të serverëve që duhej të zhvilloheshin për të përfunduar migrimin.
Si rezultat, kur klasët në zonën e mbrojtur ishin plotësisht të dyfishuara, migrimi kaloi pa probleme.
Pastaj duhej vetëm të ndaheshin rrjetet e zonës së mbrojtur dhe të mbrojtur. Këtu kaluam me disa ndërprerje të vogla në funksionim. Faza e testimit të gjithë sistemit në zonën e mbrojtur pa ndonjë mbrojtje u arrit të niste normalisht. Pas mbledhjes së statistikave pozitive të funksionimit të sistemit në këtë mënyrë, kaluam në fazën e fundit: aktivizimin e sistemeve të mbrojtjes dhe kufizimin e qasjes.
Â
Rezultati pozitiv dhe mësimi i dobishëm
Â
NĂ« pĂ«rfundim, me pĂ«rpjekje tĂ« pĂ«rbashkĂ«ta me klientin, arritĂ«m tĂ« bĂ«nim ndryshime tĂ« rĂ«ndĂ«sishme nĂ« infrastrukturĂ«n ekzistuese tĂ« serverit, duke rritur kĂ«shtu besueshmĂ«rinĂ« dhe sigurinĂ« e ruajtjes sĂ« tĂ« dhĂ«nave personale, duke ulur ndjeshĂ«m rreziqet e qasjes sĂ« paautorizuar ndaj tyre, dhe duke marrĂ« njĂ« certifikatĂ« pĂ«r pĂ«rmbushjen e kĂ«rkesave pĂ«r ruajtje â njĂ« arritje qĂ« ende nuk e kanĂ« arritur tĂ« gjithĂ« zhvilluesit e programeve tĂ« ngjashme.
Â
Në përmbledhje, kompleksi i punëve për projektin dukej kështu:
Â
- U organizua një subnet i dedikuar;
- Në total u migruan dy klastere, që përbëheshin nga pesë makina virtuale: klasteri i të dhënave (dy makina virtuale), klasteri i aplikacioneve Service Fabric (tre makina virtuale);
- U realizuan konfigurimet e sistemeve të mbrojtjes dhe enkriptimit të të dhënave.
Duket se gjithçka Ă«shtĂ« e qartĂ« dhe logjike. NĂ« praktikĂ«, megjithatĂ«, gjithçka del tĂ« jetĂ« pak mĂ« e komplikuar. Ne sĂ«rish u bindĂ«m se gjatĂ« punĂ«s me çdo detyrĂ« tĂ« tillĂ«, kĂ«rkohet njĂ« nivel maksimal vĂ«mendjeje ndaj "detajeve", tĂ« cilat, nĂ« fund tĂ« fundit, nuk janĂ« detaje, por faktorĂ« pĂ«rcaktues tĂ« suksesit tĂ« gjithĂ« projektit.Â
Burimi: habr.com
