Conform legilor din Rusia, orice companie care lucrează cu datele personale ale utilizatorilor săi în Rusia devine operator de date cu caracter personal, indiferent dacă își dorește sau nu. Aceasta impune o serie de obligații formale și procedurale, pe care nu fiecare afacere le poate sau le dorește să le îndeplinească pe cont propriu.
Așa cum arată practica, este complet corect să nu dorești, pentru că acest domeniu de cunoștințe este atât de nou și neexperimentat, încât dificultăți și întrebări apar chiar și la profesioniști. Astăzi, vom vorbi despre cum am realizat un proiect pentru stocarea datelor personale pentru clientul nostru și cu ce dificultăți neașteptate ne-am confruntat.
Cum am ajutat la protejarea datelor conform legii 152-FZ
La începutul anului 2019, ne-a contactat compania SRL „Smart-Service”, dezvoltator al unei platforme pentru gestionarea serviciilor de întreținere și a unei aplicații pentru schimbul de contacte .
Prima soluție permite automatizarea procesului de întreținere a echipamentelor în diverse domenii – de la configurarea aparatelor de cafea și a air conditionerelor în birouri până la repararea turbinelor cu gaz. A doua – un constructor online pentru crearea de cărți de vizită electronice pe baza codurilor QR.
Carte de vizită online myQRcards.
Ambele sisteme stochează și procesează datele utilizatorilor care intră în categoria „personale” conform legii 152-FZ. În acest caz, legea impune o serie de restricții asupra sistemelor de stocare a acestor date personale pentru a asigura nivelul necesar de protecție și a exclude riscul accesului neautorizat în scopul furtului sau utilizării necorespunzătoare.
Legea trebuie respectată, dar „Smart-Service” nu intenționa să dezvolte competențe interne în protejarea datelor cu caracter personal. Prin urmare, serviciile și datele pe care le împărtășeau utilizatorii lor au fost „mutate” în Linxdatacenter. „Smart-Service” a transferat capacitățile serverului mediului de lucru într-o zonă de rețea protejată separată a centrului nostru de date, acreditată conform cerințelor stipulate în legea 152-FZ – așa-numita „Cloud Protejat”.
CUM ESTE STRUCTURAT CLOUDUL PROTEJAT
Orice sistem informațional care procesează date personale trebuie să îndeplinească trei cerințe de bază:
- Accesul la serverele de stocare și procesare a datelor trebuie să se efectueze printr-un canal VPN cu criptare conform GOST;
- Serverele de stocare și procesare a datelor trebuie să fie monitorizate constant cu protecție antivirus pentru a identifica vulnerabilitățile;
- Sistemul de stocare a datelor trebuie să fie amplasat în rețele izolate.
Noi plasăm capacitățile serverului clientului în zone separate, care respectă cerințele legii 152-FZ, și ajutăm la obținerea unei concluzii de conformitate.
Arhitectura infrastructurii virtuale securizate pentru LLC „Smart Service”.
Stadiul lucrărilor
Aprobat inițial, lucrările au fost convenite în iunie 2019, ceea ce poate fi considerată data de început a proiectului. Toate lucrările trebuie să se desfășoare într-un mediu „live” cu mii de solicitări pe zi. Este evident că era necesar să se finalizeze proiectul fără a întrerupe modul normal de funcționare al ambelor sisteme.
Prin urmare, a fost elaborat și convenit un plan clar de acțiune, împărțit în 4 etape:
- pregătire,
- migrare,
- testare și verificare în condiții reale,
- includerea sistemelor de monitorizare și restricționarea accesului.
Pentru orice eventualitate, am prevăzut o procedură de recuperare în cazul unei situații neprevăzute (DRP). Conform planului inițial, lucrările nu au durat mult timp și resurse și ar trebui să se finalizate în iulie 2019. Fiecare dintre etape prevedea la final testarea completă a accesibilității rețelei și funcționalității sistemelor.
Cea mai dificilă etapă, în care ceva „ar putea să nu meargă bine”, a fost migrarea. Inițial, am planificat să realizăm migrarea prin transferul întregului sistem virtual. Acesta era cea mai logică opțiune, deoarece nu necesita implicarea de resurse suplimentare pentru reconfigurare. Se părea că nu poate fi mai simplu decât vMotion.
Surprinzător
Cu toate acestea, așa cum se întâmplă de obicei în proiectele dintr-un domeniu relativ nou, s-a întâmplat ceea ce nu ne așteptam.
Deoarece fiecare mașină virtuală ocupă între 500 și 1 000 GB, copierea unor astfel de volume chiar și în cadrul unui singur centru de date a durat aproximativ 3-4 ore pentru fiecare mașină. Ca rezultat, nu ne-am încadra în fereastra de timp alocată. Acest lucru s-a întâmplat din cauza restricțiilor fizice ale subsistemului de stocare în timpul transferului de date în vCloud.
Un bug al versiunii utilizate a vCloud a împiedicat organizarea Storage vMotion pentru o mașină virtuală cu tipuri diferite de discuri, așa că discurile au fost necesare a fi schimbate. Ca rezultat, mașinile virtuale au fost transferate, dar a durat mai mult decât era planificat.
Un alt aspect pe care nu l-am prevăzut au fost restricțiile privind mutarea clusterului de baze de date (Failover Cluster MS SQLServer). Drept urmare, a fost necesar să mutăm clusterul în modul de lucru cu un singur nod și să-l lăsăm în afara zonei protejate.
Este remarcabil faptul că, dintr-o cauză încă neclară, în urma transferului mașinilor virtuale, clusterul aplicațiilor s-a dezmembrat și a trebuit să fie reconstruit.
În urma primei încercări, am obținut o stare nesatisfăcătoare a sistemelor și a fost necesar să ne reîntoarcem la planificare și elaborarea opțiunilor.
Încercarea nr. 2
După analiza greșelilor, echipa a realizat că ar fi mai bine să dublăm infrastructura în zona protejată și să copiem doar fișierele cu date. S-a decis să nu cerem clientului o plată suplimentară pentru capacitățile serverului care au trebuit să fie desfășurate pentru a finaliza migrarea.
Ca rezultat, când cluster-ele din zona protejată au fost complet duplicate, migrarea s-a desfășurat fără probleme.
Apoi a fost necesar doar să separăm rețelele din zona protejată și cea neprotejată. Aici s-a manifestat doar câteva sincope neimportante în funcționare. Faza de testare a întregului sistem în zona protejată fără nicio protecție a fost inițiată în mod normal. După ce am obținut statistici pozitive ale funcționării sistemului în acest mod, am trecut la ultima etapă: activarea sistemelor de protecție și limitarea accesului.
Un rezultat pozitiv și o lecție utilă
În cele din urmă, împreună cu clientul, am reușit să aducem modificări semnificative în infrastructura serverului existent, ceea ce a permis îmbunătățirea fiabilității și a securității stocării datelor personale, reducând semnificativ riscurile accesului neautorizat la acestea, și a obținut un certificat de conformitate cu cerințele de stocare — o realizare pe care nu toți dezvoltatorii de software similar au reușit să o atingă.
Rezultatul final al muncii proiectului arăta astfel:
- A fost organizată o subrețea dedicată;
- În total, au fost migrate două clustere compuse din cinci mașini virtuale: cluster de failover pentru baze de date (două mașini virtuale), cluster Service Fabric pentru aplicații (trei mașini virtuale);
- Au fost efectuate setările sistemelor de protecție și criptare a datelor.
Pare să fie totul clar și logic. În practică, însă, se dovedește a fi puțin mai complicat. Ne-am convins încă o dată că, în lucru cu fiecare sarcină de acest tip, este necesar un nivel extrem de ridicat de atenție la „detalii”, care se dovedesc a fi de fapt factori determinanți pentru succesul întregului proiect.
Sursa: habr.com
